2. Dapat mengedit data jika ada perubahan data tim yang bersangkutan.
3. Dapat melakukan pencetakan barcode.
4. Dapat mencetak bukti pembayaran.
5. Dapat melakukan proses pelaporan.
4.2.3 Analisis Resiko
Beberapa resiko yang akan dihadapi dalam perancangan aplikasi ini diantaranya yaitu:
1. Waktu Pengerjaan Dalam Pembuatan Aplikasi.
2. Perancangan Database, Tampilan, Input, Output dan Laporan
Pembayaran. 3.
Komponen perangkat keras tidak sesuai yang dibutuhkan dalam menjalankan aplikasi.
4. Pengelola belum memahami penggunaan aplikasi.
4.2.4 Perekayasaan
4.2.4.1 Kebutuhan Umum Sistem
Kebutuhan umum yang diperlukan pada sistem sebagai berikut: 1.
Mampu mengidentifikasi kartu barcode pada saat diScan, apakah sesuai dengan database yang sudah dibuat.
2. Mampu menampilkan data dari tim ketika kartu barcode berhasil di
scan. 3.
Dapat melakukan pengeditan data.
4. Dapat melakukan rekapitulasi data.
4.2.4.2 Pengembangan Sistem
Pengembangan sistem yang digunakan untuk membangun aplikasi terdiri dari perangkat lunak Software dan perangkat keras
Hadware. Untuk perangkat lunak dan spesifikasi perangkat keras sudah dibahas pada perencanaan.
4.2.4.3 Perancangan Sistem Baru
Perancangan sistem yang baru pada aplikasi ini menggunakan model UML Unified Modeling Language, yaitu dengan membuat use
case diagram, sequence diagram, dan class diagram. Penulis dalam merancang model UML ini dengan menggunakan Software Microsoft
Visio 2003 sebagai alat bantunya.
4.2.4.3.1 Use Case
Use Case yang dipakai terdiri dari Use Case Login, Use Case Daftar Tim, Use Case Cetak Barcode, Use Case Cetak Pembayaran.
4.2.4.3.1.1 Spesifikasi Use Case
Berikut spesifikasi use case tersebut :
1. Login
Use Case Login
Actor Admin Staff Pengelola
Brief Description
AdminStaff Pengelola login terhadap sistem dengan menginput use name dan password, maka sistem akan memvalidasi use
name dan password tersebut. Basic Flow
1 Tampilan Form Login
2 Admin Staff Pengelola menginput user name
3 Admin Staff Pengelola menginput password
4 Admin Staff Pengelola mengirimkan user name dan
password yang sudah di input dengan mengclick OK, agar sistem memvalidasi user name dan password yang di input
5 Sistem memvalidasi user name dan password
6 Sistem menampilkan menu pada sistem yang sudah dibuka
jika user name dan password benar, jika user name dan password maka harus menginput kembali user name dan
password yang benar. Alternate Flow
Jika dalam penginputan user name dan password salah maka sistem meminta input kembali user name dan password
Pre condition AdminStaff Pengelola harus mengetahui user name dan
password Post Condition
Tampil Form menu utama
2. Daftar Tim
Use Case Menu Master Tim
Actor Admin Staff Pengelola
Brief Description
AdminStaff Pengelola memasukkan data suatu tim berdasarkan yang ada pada master tim
Basic Flow 1
Tampilan Form Data Tim 2
Admin Staff Pengelola menginput kode tim, barcode, nama tim, hari main, jam awal, jam akhir, perwakilan tim,
No. HP, alamat. 3
Jika sudah diisi semua di simpan. Alternate Flow
Jika dalam pengisian salah maka akan mempilkan error dan harus diulang kembali
Pre condition AdminStaff Pengelola harus masuk menu master tim sebelum
mengisi data tim. Post Condition
Data tim telah tersimpan
3. Cetak Barcode
Use Case Mencetak Barcode
Actor Admin Staff Pengelola
Brief Description
AdminStaff Pengelola memasukkan kode Barcode tiap-tiap tim dan berbeda satu dengan yang lainnya.
Basic Flow 1
Diisi ketika pertama kali mendaftar menjadi member 2
Barcode yang diberikan harus berbeda 3
Lihat tampilan kartu barcode Alternate Flow
Jika ada barcode yang sama akan menimbulkan kata error
Pre condition AdminStaff Pengelola harus mengisi barcode jika tim menjadi
member. Post Condition
Barcode dicetak
4. Cetak Pembayaran
Use Case Pembayaran
Actor Admin Staff Pengelola
Brief Description
AdminStaff Pengelola menscan kartu barcode yang telah diberikan kepada tim.
Basic Flow 1
Tampilan pembayaran 2
Admin Staff Pengelola menscan Barcode tim 3
Barcode terbaca, menampilkan data tim dan harga pembayaran
Alternate Flow Jika barcode tidak terbaca, maka harus discan kembali
Pre condition AdminStaff Pengelola tahu cara menggunakan scan barcode
Post Condition Mencetak bukti pembayaran
4.2.4.3.1.2 Use Case Diagram
Pada Use Case diagram ini menjelaskan apa yang akan dilakukan oleh sistem yang akan dibangun dan siapa yang akan
berinteraksi dengan sistem. Use Case diagram menjadi dokumen kesepakatan antara costumer, user, dan developer.
Beberapa Use Case diagram yang terdapat pada aplikasi ini, yaitu antara lain:
1. Use Case Diagram Administrasi Tim
Gambar 4.1 Use Case Diagram Administrasi Tim
2. Use Case Diagram Pembayaran
3.
Gambar 4.2 Use Case Diagram Pembayaran
4.2.4.3.2 Squence Diagram
Squence Diagram digunakan untuk menggambarkan perilaku pada sebuah scenario. Diagram ini menunjukkan sejumlah
contoh obyek dan message pesan yang diletakkan diantara obyek- obyek ini di dalam use case. Dalam merancang perangkat lunak ini
menggunakan beberapa Squence Diagram, antara lain:
1. Squence Diagram Login
Dalam Squence Diagram ini menjelaskan bagaimana seorang actorpengelola ingin berinteraksi dengan sistem agar
actor dapat melakukan proses login dan menggunakan aplikasi. Langkah squence diagram Login dapat dilihat pada gambar
dibawah ini:
Gambar 4.3 Sequence Diagram Login
2. Squence Diagram Daftar
Didalam Squence Diagram daftar ini menjelaskan bagaimana proses pendaftaran untuk bergabung menjadi member.
Langkah-langkah untuk mendaftar menjadi member dapat dilihat pada gambar dibawah ini:
Gambar 4.4 Squence Diagram Daftar
3. Squence Diagram Pembayaran
Pada Squence Diagram pembayaran ini menjelaskan tahapan untuk melakukan pembayaran bagi yang sudah menjadi
member. Untuk langkah squence diagramnya dapat dilihat pada gambar dibawah ini:
Gambar 4.5 Squence Diagram Pembayaran
4.2.4.3.3 Class Diagram
Gambar 4.6 Class Diagram
4.2.4.4 Perancangan Database
Setelah melakukan perancangan sistem, selanjutnya dilakukan perancangan database yang bertujuan untuk menggambarkan
hubungan antar entity. Database merupakan kumpulan file-file yang saling berkaitan. Pada model data relational hubungan antar file
direlasikan dengan kunci relasi relation key, yang merupakan kunci utama dari masing-masing file. Perancangan database yang dibuat
penulis terdiri dari normalisasi dan ERD. Fungsional depedensi diagram awal aplikasi ini dapat dilihat
pada gambar dibawah ini:
Gambar 4.7 Fungsional Dependensi Diagram Awal Database Aplikasi
Berikut akan diterangkan langkah-langkah dalam menormalisasikan FDD di atas sehingga menjadi suatu ERD dan tabel
yang ternormalisasi.
Normalisasi
Pada tahap normalisasi terbagi dalam beberapa tahapan, yaitu:
A. Unnormalized Form Tidak Normal
Bentuk tidak normal merupakan bentuk database yang didalamnya masih sesuai yang di dapat ketika
melakukan penelitian di lapangan yang didalamnya masih terdapat duplikasi data.
Bentuk tidak normal dapat dilihat pada tabel dibawah ini:
46
Tabel Pembayaran
Id_tim Barcode
Nm_tim Wakil_tim
No_hp Alamat
Is_aktif Tgl_transaksi
Hari_main 001
Milan FC Pirlo
081356784412 Jl. Kancil Senin
Jam_main1 Jam_main2 Banyak_jam Total_harga Kd_jenis_tarif
Jenis tarif Id_hari
Nm_hari 09.00 10.00
50.000 01 Harian
101 Senin
Id_jam Jam1 Jam2 Id_tarif Rp_tarif
201 08.00 13.00
301 50.000 202 13.00
18.00 302 65.000
203 18.00 00.00
303 75.000
Tabel 4.1 Tabel Kondisi Unnormalized Tidak Normal
B. First Normal Form 1NF
Pada First Normal Form data yang didapat pada tidak normal dengan melakukan penghilangan duplikasi kolom tabel yang sama dan membuat tabel terpisah untuk setiap grup dari data yang berhubungan dan
mengidentifikasikan setiap baris dengan kolom yang unik atau menentukan primary key. Bentuk 1NF dapat dilihat pada tabel berikut:
Tabel Pembayaran
Id_tim Barcode
Nm_tim Wakil_tim
No_hp Alamat
Is_aktif Tgl_transaksi
Hari_main 001
Milan FC Pirlo
081356784412 Jl. Kancil Senin
Banyak_jam Total_harga 2 50.000
Tabel Tarif
Kd_jenis_tarif Jenis tarif
Id_hari Nm_hari Id_jam Id_tarif Rp_tarif
01 Harian 101 Senin 201 301
50.000 01 Harian
101 Senin 202 302 65.000
01 Harian 101 Senin 203 303
75.000
Tabel 4.2 Tabel Kondisi Pada First Normal 1NF
C. Second Normal Form 2NF
Bentuk normal kedua mempunyai syarat, yaitu bentuk data telah memenuhi kriteria bentuk normal kesatu. Atribut yang bukan kunci haruslah bergantung secara fungsi kepada primary key. Sehingga untuk membentuk
normal kedua haruslah sudah ditentukan kunci-kunci field. Kunci field haruslah unik dan dapat mewakili atribut lain yang menjadi anggotanya..
Bentuk tabel 2NF dapat dilihat pada tabel berikut:
Tabel Pembayaran
Id_tim Barcode
Nm_tim Wakil_tim
No_hp Alamat
Is_aktif Tgl_transaksi
Hari_main 001
Milan FC Pirlo
081356784412 Jl. Kancil Senin
Banyak_jam Total_harga 1 50.000
Tabel Jenis Tarif Tabel Hari
Kd_jenis_tarif Jenis tarif
01 Harian Id_hari Nm_hari
101 Senin 101 Senin
101 Senin
Tabel Tarif Tabel Jam
Id_tarif Rp_tarif Id_jam Jam1 Jam2
201 08.00 13.00
202 13.00 18.00
203 18.00 00.00
301 50.000 302 65.000
303 75.000
Tabel Tim
Id_tim Barcode
Nm_tim Wakil_tim
No_hp Alamat
Is_aktif 001
Milan FC Pirlo
081356784412 Jl. Kancil
Tabel 4.3 Tabel Kondisi Second Normal 2NF
D. Third Normal Form 3NF
Setelah dilakukan normal kedua, selanjutnya merubah ke normal ketiga 3NF yang mempunyai syarat setiap tabel tidak mempunyai field yang bergantungan transitif, harus bergantung penuh pada kunci utama.
Bentuk tabel ketiga 3NF dapat dilihat pada gambar dibawah ini:
Tabel Jenis Tarif
Kd_jenis_tarif Jenis tarif
Id_hari Nm_hari Id_jam Id_tarif Rp_tarif
01 Harian 101
Senin 201 301
50.000 01 Harian
101 Senin
202 302 65.000
01 Harian 101
Senin 203 303
75.000
Tabel Hari Tabel Jenis Tarif
Id_hari Nm_hari Kd_jenis_tarif Jenis
tariff 01 Harian
101 Senin 101 Senin
101 Senin
Tabel Tarif
Id_tarif Rp_tarif
Tabel Jam
Id_jam Jam1 Jam2 201 08.00
13.00 202 13.00
18.00 203 18.00
00.00 301 50.000
302 65.000 303 75.000
Id_tim Barcode
Nm_tim Wakil_tim
No_hp Alamat
Is_aktif 001
Milan FC Pirlo
081356784412 Jl. Kancil
Id_tim Id_tarif
Tgl_transaksi Hari_main
Jam_main1 Jam_main2 Banyak_jam Total_harga 001 301
Senin 09.00
10.00 50.000
Tabel 4.4 Tabel Kondisi Third Normal 3NF
Tabel Pembayaran Tabel Tim
4.2.4.5 Perancangan Antarmuka
