IMPLEMENTASI ARSITEKTUR CLIENTSERVER DAN MVC (MODEL-VIEWCONTROLLER) UNTUK MEMBANGUN APLIKASI ADMINISTRASI SEKOLAH (STUDI KASUS: SMK AVERUS JAKARTA) Skripsi
Oleh: Yulianti 2009140661
PROGRAM STUDI TEKNIK INFORMATIKA
FAKULTAS TEKNIK
UNIVERSITAS PAMULANG JAKARTA 2013
IMPLEMENTASI ARSITEKTUR CLIENTSERVER DAN MVC (MODEL-VIEWCONTROLLER) UNTUK MEMBANGUN APLIKASI ADMINISTRASI SEKOLAH (STUDI KASUS: SMK AVERUS JAKARTA) Skripsi Diajukan Untuk Melengkapi Salah Satu Syarat Memperoleh Gelar Sarjana Komputer
Oleh: Yulianti 2009140661
PROGRAM STUDI TEKNIK INFORMATIKA
FAKULTAS TEKNIK
UNIVERSITAS PAMULANG JAKARTA 2013
LEMBAR PERNYATAAN
Yang bertanda tangan di bawah ini: Nama : YULIANTI NIM : 2009140661 Program Studi : Teknik Informatika Fakultas : Teknik Jenjang Pendidikan : Strata 1 Menyatakan bahwa skripsi yang saya buat dengan judul: IMPLEMENTASI ARSITEKTUR CLIENT-SERVER DAN MVC (MODELVIEW-CONTROLLER) UNTUK MEMBANGUN APLIKASI ADMINISTRASI SEKOLAH (STUDI KASUS: SMK AVERUS JAKARTA) 1. Merupakan hasil karya tulis ilmiah sendiri, bukan merupakan karya yang pernah diajukan untuk memperoleh gelar akademik oleh pihak lain, dan bukan merupakan hasil plagiat. 2. Saya ijinkan untuk dikelola oleh Universitas Pamulang sesuai dengan norma hukum dan etika yang berlaku. Pernyataan ini saya buat dengan penuh tanggung jawab dan saya bersedia menerima konsekuensi apapun sesuai aturan yang berlaku apabila di kemudian hari pernyataan ini tidak benar.
Pamulang, 16 September 2013
( Yulianti )
ii
LEMBAR PERSETUJUAN
NIM Nama Program Studi Fakultas Jenjang Pendidikan Judul Skripsi
: : : : : :
2009140661 YULIANTI TEKNIK INFORMATIKA TEKNIK STRATA 1 IMPLEMENTASI ARSITEKTUR CLIENT-SERVER DAN MVC (MODEL-VIEW-CONTROLLER) UNTUK MEMBANGUN APLIKASI ADMINISTRASI SEKOLAH (STUDI KASUS: SMK AVERUS JAKARTA)
Skripsi ini telah diperiksa dan disetujui. Pamulang, 26 Agustus 2013
iii
LEMBAR PENGESAHAN
NIM Nama Program Studi Fakultas Jenjang Pendidikan Judul Skripsi
: : : : : :
2009140661 YULIANTI TEKNIK INFORMATIKA TEKNIK STRATA 1 IMPLEMENTASI ARSITEKTUR CLIENT-SERVER DAN MVC (MODEL-VIEW-CONTROLLER) UNTUK MEMBANGUN APLIKASI ADMINISTRASI SEKOLAH (STUDI KASUS: SMK AVERUS JAKARTA)
Skripsi ini telah dipertahankan di hadapan dewan penguji ujian skripsi fakultas Teknik, program studi Teknik Informatika dan dinyatakan LULUS. Pamulang, 13 September 2013
iv
KATA PENGANTAR Puji dan syukur saya panjatkan kepada Allah SWT, karena atas berkah dan rahmat-Nya, Maka skripsi yang berjudul ‘‘IMPLEMENTASI ARSITEKTUR CLIENT-SERVER DAN MVC (MODEL-VIEW-CONTROLLER) UNTUK MEMBANGUN APLIKASI ADMINISTRASI SEKOLAH (STUDI KASUS: SMK AVERUS JAKARTA)’’ dapat terselesaikan dengan baik. Dalam penulisan Skripsi ini, banyak hambatan dan kesulitan yang penulis hadapi, akan tetapi atas bantuan dan dorongan dari berbagai pihak, maka akhirnya penulis dapat menyelesaikan skripsi ini. Untuk itu, pada kesempatan ini penulis ingin menyampaikan rasa terima kasih yang sebesar-besarnya kepada: 1. Bapak Dr. H. Dayat Hidayat, M.M., selaku Rektor Universitas Pamulang. 2. Bapak Ir. Sewaka, M.M., selaku Dekan Fakultas Teknik Universitas Pamulang. 3. Bapak Achmad Hindasyah, S.Si., M.Si., selaku Kepala Program Studi Teknik Informatika Universitas Pamulang. 4. Ibu Normalisa, S.Kom., M.Kom., selaku dosen pembimbing, yang memberikan bimbingan dengan baik, serta motivasi untuk segera menyelesaikan skripsi ini. 5. Bapak Drs. H. A. Syarif AM, M.Pd., selaku kepala SMK (Sekolah Menengah Kejuruan) Averus Jakarta, yang telah membantu memberikan data-data yang diperlukan dalam menyelesaikan skripsi ini. 6. Kedua orang tua tersayang yang selalu memberi dorongan dan semangat sehingga anakmu yang manja ini dapat menyelesaikan skripsi ini dengan baik. 7. Suami tercinta yang selalu memberi dorongan dan semangat sehingga istrimu tersayang ini dapat menyelesaikan skripsi ini dengan baik. 8. Seluruh pihak yang memberikan bantuan secara langsung maupun tidak langsung yang tidak saya sebutkan satu-persatu. Akhirnya dengan kerendahan hati, penulis menyadari bahwa banyak kekurangan yang terdapat dalam penyusunan ini, sehingga masih jauh dari sempurna yang disebabkan oleh beberapa keterbatasan dalam diri penulis. Oleh kerena itu, penulis terbuka terhadap berbagai kritik dan saran yang bersifat membangun bagi kesempurnaan skripsi ini. Pamulang, 16 September 2013
Penulis
v
ABSTRACT Not many schools are implementing information technology to support administrative processing. SMK (vocational high school) located AVERUS Jakarta Pondok Pinang, South Jakarta is one of the educational institutions that do not use information technology effectively and efficiently in administrative data processing, administration partly because the data are recorded and processed manually, although there has been recorded and processed using computer applications using Microsoft Excel. This causes some problems such as, much duplication of data, because each saved document has its own corresponding importance of master data. The papers are not organized very well because the data and stored according to the interests of each staff responsible jawab.Pembuatan reports from administrative data tend to be slow, because it has not been well integrated. Good application should be easily adapted to the needs in the future. To solve these problems, the school administration application built using a client server architecture and MVC (Model View Controller). Because to build a good system should use a good model. Client-server architecture can be used to build a centralized application that can reduce the duplication of data / documents and be able to improve organizational documents. Client-server architecture divides the application into two parts, the server associated with database management, and related client user interface. While the MVC architecture to facilitate the development of applications in accordance with the requirements in the future, and can reduce the amount of source code. Administrative applications created using client server architecture and MVC can solve the problems that exist. These applications can reduce the duplication of data, organizations can improve data / documents, can accelerate the creation of required reports, and can improve the efficiency and effectiveness of application development.
Keywords: School Administration, Client-Server, MVC (Model-View-Controller) xvi+120 pages; 79 figures; 17 tables; attachments; technical documentation Bibliography: 32 (1994-2012)
vi
ABSTRAK Belum banyak sekolah yang mengimplementasikan teknologi informasi untuk menunjang pengolahan administrasinya. SMK (Sekolah Menengah Kejuruan) AVERUS JAKARTA yang terletak Pondok Pinang, Jakarta Selatan merupakan salah satu institusi pendidikan yang belum menggunakan teknologi informasi secara efektif dan efisien dalam pengolahan data administrasinya, karena data administrasinya sebagian dicatat dan diolah secara manual, walaupun sudah ada yang dicatat dan diolah menggunakan aplikasi komputer menggunakan Microsoft Excel. Hal ini menyebabkan beberapa masalah seperti, banyak terjadi duplikasi data, karena setiap dokumen yang disimpan memiliki master data tersendiri sesuai kepentingannya. Dokumen-dokumennya tidak teroganisir dengan baik karena disimpan sesuai kepentingan datanya dan masing-masing staf yang bertanggung jawab.Pembuatan laporan-laporan dari data-data administrasi cenderung lambat, karena belum terintegrasi dengan baik. Aplikasi yang baik harus mudah disesuaikan dengan kebutuhan di masa yang depan. Untuk menyelesaikan permasalahan tersebut, maka dibangun aplikasi administrasi sekolah menggunakan arsitektur client server dan MVC (Model View Controller). Karena untuk membangun sistem yang baik harus menggunakan model yang baik. Arsitektur client-server dapat digunakan untuk membangun aplikasi terpusat yang dapat mengurangi duplikasi data/dokumen dan dapat memperbaiki organisasi dokumen. Arsitektur client-server membagi aplikasi dalam dua bagian, yaitu server yang berhubungan dengan pengelolaan basis data, dan client yang berhubungan dengan antarmuka user. Sedangkan arsitektur MVC dapat mempermudah pengembangan aplikasi sesuai dengan kebutuhan di masa depan, dan dapat mengurangi jumlah source code. Aplikasi administrasi yang dibuat menggunakan arsitektur client server dan MVC dapat menyelesaikan permasalahan-permasalahan yang ada. Aplikasi ini dapat mengurangi duplikasi data, dapat memperbaiki organisasi data/dokumen, dapat mempercepat pembuatan laporan yang diperlukan, dan dapat meningkatkan efisiensi dan efektifitas pengembangan aplikasi.
Kata kunci: Administrasi Sekolah, Client-Server, MVC (Model-View-Controller)
xvi+120 halaman; 79 gambar; 17 tabel; lampiran; 1 dokumentasi teknis Daftar acuan: 32 (1994-2012)
vii
DAFTAR ISI HALAMAN JUDUL ...................................................................................... i LEMBAR PERNYATAAN .......................................................................... ii LEMBAR PERSETUJUAN ......................................................................... iii LEMBAR PENGESAHAN .......................................................................... iv KATA PENGANTAR ................................................................................... v ABSTRACT ................................................................................................... vi ABSTRAK................................................................................................... vii DAFTAR ISI .............................................................................................. viii DAFTAR GAMBAR ................................................................................... xii DAFTAR TABEL ....................................................................................... xv DAFTAR SIMBOL .................................................................................... xvi DAFTAR LAMPIRAN .............................................................................. xix BAB I
PENDAHULUAN ......................................................................... 1
1.1
Latar Belakang............................................................................... 1
1.2
Identifikasi Masalah ...................................................................... 3
1.3
Tujuan ............................................................................................ 4
1.4
Batasan .......................................................................................... 4
1.5
Manfaat .......................................................................................... 4
1.6
Metodologi .................................................................................... 5
1.7
Sistematika Penulisan .................................................................... 6
BAB II
LANDASAN TEORI .................................................................... 7
2.1
Implementasi ................................................................................. 7
2.2
Membangun Aplikasi .................................................................... 7
2.3
Administrasi Sekolah..................................................................... 8
2.3.1 Administrasi ............................................................................... 8 viii
2.3.2 Administrasi Sekolah ................................................................. 9 2.4
Arsitektur Client-Server .............................................................. 10
2.4.1 Kelebihan Client-Server .......................................................... 12 2.4.2 Kekurangan Client-Server ....................................................... 12 2.5
Basis Data (Database) ................................................................. 12
2.5.1 ERD (Entity Relationship Diagram)........................................ 13 2.5.2 Transformasi ERD ke LRS ...................................................... 15 2.5.3 Normalisasi .............................................................................. 16 2.6
Pengembangan Aplikasi .............................................................. 21
2.6.1 Siklus Hidup Pengembangan Aplikasi .................................... 22 2.6.2 Model Pengembangan Aplikasi ............................................... 24 2.7
Pemrograman Berorientasi Objek ............................................... 31
2.7.1 Prinsip-prinsip Pemrograman Berorientasi Objek ................... 32 2.7.2 Bahasa Pemrograman Berorientasi Objek ............................... 33 2.7.3 Desain Pemrograman Berorientasi Objek................................ 34 2.8
MVC (Model-View-Controller)................................................... 39
2.9
Pengujian (Testing)...................................................................... 41
2.9.1 Tujuan Pengujian ..................................................................... 41 2.9.2 Jenis Pengujian ........................................................................ 42 2.9.2.1 Pengujian Black Box ......................................................... 42 2.9.2.2 Pengujian White Box ......................................................... 45 2.10
Aplikasi Pendukung..................................................................... 46
2.10.1 Java ........................................................................................ 46 2.10.1.1 Karakteristik Java............................................................ 46 2.10.1.2 Sistem Kerja Java ............................................................ 48 2.10.1.3 Teknologi Java ................................................................ 49
ix
2.10.2 NetBeans ................................................................................ 51 2.10.3 MySQL .................................................................................. 51 2.10.3.1 Kelebihan MySQL .......................................................... 52 2.10.3.2 Kekurangan MySQL ....................................................... 55 BAB III 3.1
ANALISA DAN PERANCANGAN ....................................... 56 Analisa ......................................................................................... 56
3.1.1 Analisa Sistem Saat Ini ............................................................ 56 3.1.2 Analisa Data/Dokumen ............................................................ 57 3.1.3 Analisa Kebutuhan................................................................... 58 3.2
Perancangan................................................................................. 58
3.2.1 Perancangan Database (Basis Data) ........................................ 59 3.2.1.1 ERD (Entity Relationship Diagram) ................................. 59 3.2.1.2 ERD ke LRS ..................................................................... 61 3.2.1.3 LRS (Logical Record Structure) ....................................... 62 3.2.1.4 Normalisasi ....................................................................... 63 3.2.1.5 Spesifikasi Basis Data ....................................................... 63 3.2.2 Perancangan Aplikasi .............................................................. 68 3.2.2.1 Use Case Diagram ............................................................ 68 3.2.2.2 Sequence Diagram ............................................................ 72 3.2.2.3 Activity Diagram ............................................................... 83 3.2.2.4 Class Diagram ................................................................ 105 3.2.2.5 User Interface (Antarmuka Pengguna) ........................... 106 BAB IV 4.1
IMPLEMENTASI DAN PENGUJIAN ................................. 109 Implemantasi ............................................................................. 109
4.1.1 Implementasi Basis Data ....................................................... 109 4.1.2 Implementasi Aplikasi ........................................................... 111
x
4.2
Pengujian ................................................................................... 118
4.2.1 Pengujian Black Box .............................................................. 118 4.2.2 Pengujian White Box ............................................................. 120 4.3
Analisa ....................................................................................... 123
BAB V
PENUTUP ................................................................................. 125
5.1
Kesimpulan ................................................................................ 125
5.2
Saran .......................................................................................... 125
DAFTAR PUSTAKA ................................................................................ 126
xi
DAFTAR GAMBAR
Gambar 2. 1 Hubungan antara client dengan server ................................... 12 Gambar 2. 2 Jenis diagram resmi UML 2.................................................... 35 Gambar 2. 3 Model MVC (Model View Controller) ................................... 40 Gambar 2. 4 Proses dari sebuah Program Java ............................................ 48 Gambar 2. 5 Java Cross-platform atau Multi-platform ............................... 49 Gambar 3. 1 Diagram activity sistem saat ini .............................................. 57 Gambar 3. 2 ERD basis data administrasi sekolah ...................................... 60 Gambar 3. 3 ERD ke LRS basis data administrasi sekolah ......................... 61 Gambar 3. 4 LRS basis data administrasi sekolah....................................... 62 Gambar 3. 5 Use case diagram aplikasi administrasi sekolah .................... 69 Gambar 3. 6 Paket use case diagram akses aplikasi ................................... 70 Gambar 3. 7 Paket use case diagram master data ....................................... 70 Gambar 3. 8 Paket use case diagram transaksi ........................................... 71 Gambar 3. 9 Paket use case diagram laporan ............................................. 71 Gambar 3. 10 Sequence diagram login........................................................ 72 Gambar 3. 11 Sequence diagram logout...................................................... 72 Gambar 3. 12 Sequence diagram mengelola jenis persyaratan ................... 73 Gambar 3. 13 Sequence diagram mengelola jenis pembayaran .................. 73 Gambar 3. 14 Sequence diagram mengelola data staf administrasi ............ 74 Gambar 3. 15 Sequence diagram mengelola data guru ............................... 74 Gambar 3. 16 Sequence diagram mengelola data siswa ............................. 75 Gambar 3. 17 Sequence diagram mengelola kelompok mata pelajaran...... 75 Gambar 3. 18 Sequence diagram mengelola mata pelajaran....................... 76 Gambar 3. 19 Sequence diagram mengelola data jam ................................ 76 Gambar 3. 20 Sequence diagram mengelola data jurusan........................... 77 Gambar 3. 21 Sequence diagram mengelola data kelas .............................. 77 Gambar 3. 22 Sequence diagram mengelola data kelas siswa .................... 78 Gambar 3. 23 Sequence diagram mengelola data pendaftaran.................... 78 Gambar 3. 24 Sequence diagram diagram proses penerimaan siswa .......... 79
xii
Gambar 3. 25 Sequence diagram mengelola data pembayaran ................... 79 Gambar 3. 26 Sequence diagram mengelola jadwal ................................... 80 Gambar 3. 27 Sequence diagram mengelola data nilai ............................... 81 Gambar 3. 28 Sequence diagram mencetak laporan penerimaan siswa ...... 82 Gambar 3. 29 Sequence diagram mencetak laporan pembayaran ............... 82 Gambar 3. 30 Sequence diagram mencetak laporan nilai ........................... 83 Gambar 3. 31 Sequence diagram mencetak laporan jadwal ........................ 83 Gambar 3. 32 Activity diagram login .......................................................... 84 Gambar 3. 33 Activity diagram logout ........................................................ 84 Gambar 3. 34 Activity diagram mengelola jenis persyaratan ...................... 85 Gambar 3. 35 Activity diagram mengelola jenis pembayaran ..................... 86 Gambar 3. 36 Activity diagram mengelola data staf administrasi ............... 87 Gambar 3. 37 Activity diagram mengelola data guru .................................. 88 Gambar 3. 38 Activity diagram mengelola data siswa ................................ 89 Gambar 3. 39 Activity diagram mengelola kelompok mata pelajaran......... 90 Gambar 3. 40 Activity diagram mengelola mata pelajaran.......................... 91 Gambar 3. 41 Activity diagram mengelola data jam ................................... 92 Gambar 3. 42 Activity diagram mengelola data jurusan ............................. 93 Gambar 3. 43 Activity diagram mengelola data kelas ................................. 94 Gambar 3. 44 Activity diagram mengelola data kelas siswa ....................... 95 Gambar 3. 45 Activity diagram mengelola data pendaftaran ...................... 96 Gambar 3. 46 Activity diagram proses penerimaan siswa ........................... 97 Gambar 3. 47 Activity diagram mengelola data pembayaran ...................... 98 Gambar 3. 48 Activity diagram mengelola jadwal ...................................... 99 Gambar 3. 49 Activity diagram mengelola data nilai ................................ 100 Gambar 3. 50 Activity diagram mencetak laporan penerimaan siswa ....... 101 Gambar 3. 51 Activity diagram mencetak laporan pembayaran ................ 102 Gambar 3. 52 Activity diagram mencetak laporan nilai ............................ 103 Gambar 3. 53 Activity diagram mencetak laporan jadwal ......................... 104 Gambar 3. 54 Class diagram aplikasi administrasi sekolah ...................... 105 Gambar 3. 55 Desain antarmuka form utama ............................................ 106 Gambar 3. 56 Desain antarmuka form login ............................................. 106
xiii
Gambar 3. 57 Desain antarmuka informasi aplikasi.................................. 107 Gambar 3. 58 Desain antarmuka master data jenis persyaratan ................ 107 Gambar 3. 59 Desain antarmuka master data jenis pembayaran ............... 108 Gambar 4. 1 Diagram relasi basis data administrasi sekolah .................... 110 Gambar 4. 2 Tampilan form deskripsi ....................................................... 111 Gambar 4. 3 Tampilan form login ............................................................. 111 Gambar 4. 4 Tampilan form utama............................................................ 112 Gambar 4. 5 Tampilan form siswa ............................................................ 112 Gambar 4. 6 Tampilan form guru .............................................................. 113 Gambar 4. 7 Tampilan form staf administrasi ........................................... 113 Gambar 4. 8 Tampilan form pendaftaran .................................................. 114 Gambar 4. 9 Tampilan form penerimaan siswa ......................................... 114 Gambar 4. 10 Tampilan form pembayaran ................................................ 115 Gambar 4. 11 Tampilan form jadwal......................................................... 115 Gambar 4. 12 Tampilan form nilai ............................................................ 116 Gambar 4. 13 Tampilan form laporan penerimaan siswa .......................... 116 Gambar 4. 14 Tampilan form laporan nilai ............................................... 117 Gambar 4. 15 Tampilan form laporan pembayaran ................................... 117 Gambar 4. 16 Tampilan form laporan jadwal ............................................ 118 Gambar 4. 17 Membuat test (pengujian) unit (white box) ......................... 120 Gambar 4. 18 Menentukan test (pengujian) unit (white box) .................... 121 Gambar 4. 19 Melakukan test (pengujian) unit (white box) ...................... 122 Gambar 4. 20 Hasil test (pengujian) unit (white box)................................ 122 Gambar 4. 21 Hasil test (pengujian) empat unit/modul unit (white box) .. 123
xiv
DAFTAR TABEL
Tabel 2. 1 Tahapan pembuatan program java .............................................. 49 Tabel 3. 1 Tabel jenis persyaratan ............................................................... 63 Tabel 3. 2 Tabel jenis pembayaran .............................................................. 63 Tabel 3. 3 Tabel persyaratan ........................................................................ 63 Tabel 3. 4 Tabel pembayaran....................................................................... 64 Tabel 3. 5 Tabel detil pembayaran .............................................................. 64 Tabel 3. 6 Tabel calon siswa........................................................................ 64 Tabel 3. 7 Tabel siswa ................................................................................. 65 Tabel 3. 8 Tabel staf administrasi ................................................................ 65 Tabel 3. 9 Tabel guru ................................................................................... 65 Tabel 3. 10 Tabel jurusan ............................................................................ 66 Tabel 3. 11 Tabel kelas ................................................................................ 66 Tabel 3. 12 Tabel kelas siswa ...................................................................... 66 Tabel 3. 13 Tabel kelompok mata pelajaran ................................................ 66 Tabel 3. 14 Tabel mata pelajaran................................................................. 67 Tabel 3. 15 Tabel jadwal ............................................................................. 67 Tabel 3. 16 Tabel jam .................................................................................. 67 Tabel 3. 17 Tabel nilai ................................................................................. 68 Tabel 4. 1 Pengujian fungsionalitas (functional testing) ........................... 119
xv
DAFTAR SIMBOL
No. 1
Simbol uc Use Case Model
Nama Simbol Boundary
uc Use Ca...
Untuk menggambarkan sistem atau aplikasi.
Aplikasi
2
Keterangan
Actor
Untuk menggambarkan pengguna (user) sistem/aplikasi
Actor
3
uc Use Case Model
Use Case
Untuk menggambarkan apa yang dilakukan actor
Use Case
terhadap sistem 4
Assosiation
uc Use Case Model
Garis lurus untuk menunjukkan hubungan actor dengan use case
5
uc Use Case Model
Generalization
Garis dengan ujung berbentuk panah, menunjukan use case sumber (source) adalah penjabaran (detil) dari use case yang ditunjuk panah (destination)
6
Include
uc Use Case Model
Garis putus-putus dengan ujung berbentuk panah,
«include»
menunjukan use case sumber (source) akan selalu dilakukan jika use case yang ditunjuk panah (destination) dilakukan
xvi
No. 7
Simbol
Nama Simbol Package
uc Use Case Model
Keterangan Digunakan untuk
Package
menggambarkan diagram paket, yang berfungsi untuk mengelompokkan use case diagram atau class diagram
8
Trace
uc Use Case Model
Menggambarkan bahwa
Package
sumber (source)
«trace»
berhubungan dengan sebagian/seluluh dalam tujuan (destination) 9
Class
class Class Model
Untuk menggambarkan class yang memiliki attribute dan
Class
10
-
attribute: int
+
method() : void
uc Use Case Model Package
Package
method.
Import
Untuk menggambarkan
«import»
bahwa package sumber (source) diimport oleh anggota dari package tujuan (destination)
11
act A...
Initial
Untuk menggambarkan awal activity (aktivitas)
12
act A...
Final
Untuk menggambarkan akhir activity (aktivitas)
13
Activity
act Activ ity
Untuk menggambarkan
Activ ity
activity (aktivitas) yang dilakukan
xvii
No.
Simbol
14
act Activ ity
Nama Simbol Decission
Keterangan Untuk menggambarkan percabangan activity (aktivitas)
15
Fork/Join
ac...
Untuk menunjukkan proses
act Activ ity
yang berjalan secara paralel 16
sd Interaction
Boundary
Untuk menggambarkan class antarmuka (view) pada
Boundary
17
sd Interaction
sequence diagram Control
Untuk menggambarkan class proses (controller) pada
Control
18
sd Interaction
sequence diagram Entity
Untuk menggambarkan class entitas (model) pada
Entity
sequence diagram
xviii
DAFTAR LAMPIRAN
Lampiran 1 Formulir data pribadi calon siswa baru .................................. 129 Lampiran 2 Bidang keahlian bisnis dan manajemen SMK AVERUS ..... 131 Lampiran 3 Jadwal mengajar SMK Averus............................................... 132 Lampiran 4 Kwitansi SMK AVERUS ....................................................... 133 Lampiran 5 Kartu tanda bukti pembayaran SMK AVERUS..................... 134 Lampiran 6 Kartu hasil studi (KHS) SMK AVERUS ............................... 136 Lampiran 7 Kartu konsultasi mahasiswa ................................................... 138
xix
BAB I PENDAHULUAN
1.1
Latar Belakang Pengolahan data administrasi dalam sebuah institusi pendidikan merupakan
kegiatan utama yang dilaksanakan secara periodik ataupun setiap saat, data-data tersebut selalu berubah setiap bulan atau setiap tahun, penambahan siswa, maupun perubahan kebijakan pemerintah menyebabkan data-data tersebut selalu berubah. Sedangkan informasi yang dihasilkan dituntut untuk selalu aktual, sehingga dibutuhkan suatu sistem yang dapat mengolah data-data administrasi secara efisien dan efektif. Saat ini media komputer telah menempati peranan penting dalam dunia pendidikan (Sulindawaty & Calam, 2011). Sudah banyak sekolah-sekolah yang memiliki komputer dan mengajarkan tentang teknologi informasi kepada muridmuridnya. Tetapi teknologi informasi di sekolah masih sebatas ilmu yang diajarkan di SMP, SMU, dan SMK sesuai kurikulum nasional (Kristanti & Redita, 2012). Belum banyak sekolah yang mengimplementasikan teknologi informasi untuk menunjang pengolahan administrasinya. Komputerisasi administrasi merupakan hal yang penting dalam lembaga pendidikan, karena dapat mempermudah petugas administrasi dalam mengerjakan tugas-tugasnya (Antonio & Safriadi, 2012). SMK (Sekolah Menengah Kejuruan) AVERUS JAKARTA yang terletak Pondok Pinang, Jakarta Selatan merupakan salah satu institusi pendidikan yang belum menggunakan teknologi informasi secara efektif dan efisien dalam pengolahan data administrasinya, karena data administrasinya sebagian dicatat dan diolah secara manual, walaupun sudah ada yang dicatat dan diolah menggunakan aplikasi komputer menggunakan Microsoft Excel. SMK AVERUS JAKARTA belum menggunakan sistem terintegrasi dan terotomatisasi dalam pengolahan administrasinya. Data-data administrasinya dicatat di dalam file-file Microsoft Excel yang terpisah-pisah dalam folder sesuai kepentingan datanya pada masing-masing komputer petugasnya.
1
2
Dengan melihat dan mengamati sistem yang sedang berjalan pada SMK AVERUS JAKARTA, terlihat banyak duplikasi data, karena setiap petugas memiliki master data sendiri-sendiri di dalam komputernya. Data-datanya tidak mudah untuk dilakukan pembaharuan (update), karena
jika
dilakukan
pembaharuan (update) di salah satu komputer, maka data-data di komputer lain tidak ikut diperbaharui. Sehingga harus dilakukan pembaharuan (update) data pada setiap komputer.
Dokumen-dokumennya tidak teroganisir dengan baik,
karena disimpan oleh masing-masing petugas dalam folder dan file sesuai kepentingannya, jika ada petugas yang tidak hadir, maka petugas lain kesulitan untuk menggantikan tugasnya karena tidak tahu lokasi penyimpanannya. Selain itu juga kesulitan untuk mengevaluasi data pembayaran, data prestasi siswa, dan lain-lain, karena data-datanya harus dikumpulkan, diperbaharui, dan diolah setiap dilakukan evaluasi. Membangun aplikasi administrasi sekolah merupakan salah satu solusi pengolahan data secara komputerisasi, sehingga informasi yang dihasilkan efektif dan efisien. Aplikasi yang baik harus didukung oleh model data yang baik, yaitu model data yang fleksibel dan dapat disesuaikan dengan kebutuhan masa depan (Widhyaestoeti, 2011), sehingga jika di masa depan ada kebutuhan baru, maka dapat dengan mudah untuk ditambahkan atau diperbaharui. Sesuai dengan permasalahan di atas, agar tidak terjadi duplikasi data/dokumen, dan tidak harus memperbaharui data di semua komputer jika ada perubahan, maka perlu dibuat aplikasi yang menggunakan satu basis data dan dapat diakses oleh semua komputer. Arsitektur yang dapat digunakan adalah client-server, arsitektur ini membagi proses/aktivitas menjadi dua, yaitu proses/aktivitas yang berhubungan dengan interaksi dengan pengguna (user) dilakukan oleh client, sedangkan proses yang berhubungan dengan pengolahan basis data dilakukan di dalam server (Prasetyo, 2004). Dengan adanya pembagian proses/aktivitas ini, maka beban pada sistem komunikasi (jaringan komputer) dapat dikurangi, sehingga ketika jumlah client cukup banyak tidak terlalu berpengaruh pada kinerja sistem (Alam, 2005). Client-server masih merupakan arsitektur yang dominan dalam industri komputer karena memiliki keunggulan dalam hal fleksibilitas, interoperabilitas, kinerja, ketahanan, distribusi dan
3
skalabilitas dibandingkan komputer stand-alone maupun mainframe (Vlugt & Sambasivam, 2005). Selain infrastruktur dan kinerjanya harus efektif dan efisien, pengembangan aplikasinya pun harus efektif dan efisien juga. Arsitektur MVC (Model - View Controller) merupakan arsitektur terbaik untuk aplikasi desktop (Qureshi & Sabir, 2013). MVC merupakan arsitektur yang memisahkan dengan jelas antara data (model) dengan user interface (view), dan telah terbukti sangat efektif (Widiyanto, 2010). Penggunaan MVC memungkinkan penyusunan source code (kode sumber) aplikasi menjadi lebih rapi karena terjadi pemisahan dengan jelas antara business logic (logika bisnis) dengan user interface (antarmuka pengguna), sehingga dapat mengurangi kompleksitas source code (kode sumber), meningkatkan fleksibilitas dan modularitas perangkat lunak ('Uyun & Ma'arif, 2010). Selain itu juga dapat mempermudah perawatannya di masa yang akan datang (Utpatadevi, Sudana, & Cahyawan, 2012). Dengan menggunakan MVC, alur aplikasi lebih mudah dibaca, dan lebih mudah ditelusuri jika terjadi kesalahan (Martha, Harianto, & Asfi, 2010). Berdasarkan hal-hal yang telah diuraikan di atas, maka penulis akan membuat karya ilmiah dengan judul “IMPLEMENTASI ARSITEKTUR CLIENT-SERVER DAN MVC (MODEL-VIEW-CONTROLLER) UNTUK MEMBANGUN APLIKASI ADMINISTRASI SEKOLAH (STUDI KASUS: SMK AVERUS JAKARTA)”.
1.2
Identifikasi Masalah Berdasarkan latar belakang yang telah diuraikan sebelumnya, permasalahan-
permasalahan yang akan dibahas dan dicari solusinya antara lain: a. Banyak terjadi duplikasi data, karena setiap dokumen yang disimpan memiliki master data tersendiri sesuai kepentingannya. b. Dokumen-dokumennya tidak teroganisir dengan baik karena disimpan sesuai kepentingan datanya dan masing-masing staf yang bertanggung jawab. c. Pembuatan laporan-laporan dari data-data administrasi cenderung lambat, karena belum terintegrasi dengan baik.
4
d. Aplikasi yang baik harus mudah disesuaikan dengan kebutuhan di masa depan.
1.3
Tujuan Tujuan dari pembuatan karya ilmiah ini antara lain: a. Merancang dan membangun aplikasi administrasi sekolah dengan arsitektur client-server untuk mengurangi duplikasi data. b. Merancang dan membangun aplikasi administrasi sekolah untuk memperbaiki pengorganisasian dokumen-dokumen di sekolah. c. Merancang dan membangun aplikasi administrasi sekolah untuk mempercepat pembuatan laporan-laporan yang diperlukan dari data-data administrasi. d. Mengimplementasikan arsitektur MVC (Model-View-Controller) agar aplikasi lebih rapi dan mudah disesuaikan dengan kebutuhan di masa depan.
1.4
Batasan Agar pembahasan dalam pembuatan karya ilmiah ini tidak melebar dan
dapat mencapai tujuan yang telah ditetapkan, maka pada pembahasan karya ilmiah ini dibatasi dengan hanya membahas administrasi kesiswaan mulai dari penerimaan siswa, proses belajar mengajar, sampai kelulusan. Data-data yang akan dimasukkan dalam pembahasan yaitu biodata siswa, data keuangan, dan data nilai.
1.5
Manfaat Adapun manfaat-manfaat yang dapat diperoleh dari karya ilmiah ini antara
lain: a. Meningkatkan kinerja administrasi sekolah. b. Mempermudah pengelolaan data-data siswa, pembayaran, dan nilai. c. Mempermudah evaluasi terhadap proses belajar-mengajar.
5
1.6
Metodologi Metode-metode yang digunakan dalam penyusunan karya ilmiah ini antara
lain: A. Metode pengumpulan data Pengumpulan data-data yang diperlukan dilakukan dengan beberapa cara, yaitu: a. Studi pustaka Dilakukan dengan cara membaca referensi yang berkaitan dengan masalah administrasi sekolah, arsitektur client-server, pemrograman berorientasi objek, perancangan dan pembuatan basis data, dan pengembangan
aplikasi
menggunakan
MVC
(Model-View-
Controller). b. Studi lapangan (observasi) Dilakukan dengan cara pengamatan langsung terhadap kegiatan yang berhubungan dengan administrasi sekolah di SMK AVERUS JAKARTA.
Kegiatan
administrasi
yang
diamati
mulai
dari
administrasi pendaftaran, administrasi pembayaran, administrasi proses belajar-mengajar, sampai kelulusan. c. Wawancara/Interview Pengumpulan data dilakukan dengan cara bertatap muka langsung dan melakukan tanya-jawab pada staf administrasi, guru, dan siswa.
B. Metode pengembangan aplikasi Pengembangan aplikasi dibuat dengan arsitektur MVC (Model-ViewController)
agar
penyusunan
aplikasi
lebih
rapi,
dan
mudah
dikembangkan sesuai kebutuhan di masa depan. Sedangkan model yang digunakan dalam pengembangan aplikasi menggunakan model spiral, karena model ini merupakan gabungan antara model prototype dan model waterfall. Model spiral digunakan untuk mengembangkan aplikasi berukuran besar dan untuk mengurangi potensi kesalahan dalam pengembangan aplikasi. Sehingga model spiral
6
dirasa cocok dengan pengembangan aplikasi administrasi sekolah yang akan dibuat.
1.7
Sistematika Penulisan Dalam penyusunan karya ilmiah ini dilakukan pemisahan pembahasan
dalam bentuk bab dan subbab agar mudah dipelajari dan dipahami. Adapun susunan penulisan karya ilmiah ini adalah sebagai berikut: BAB I
PENDAHULUAN
Pada bab pendahuluan berisi latar belakang, identifikasi masalah, tujuan penelitian, batasan penelitian, manfaat penelitian, metodologi penelitian, dan sistematika penulisan. BAB II
LANDASAN TEORI
Bab ini berisi tentang teori-teori yang mendukung pembuatan karya ilmiah ini. Teori-teori yang dibahas mulai dari sistem administrasi sekolah, metode pemrograman berorientasi objek, pembuatan rancangan aplikasi, arsitektur client-server, arsitektur MVC, dan aplikasi-aplikasi pendukung perancangan dan pembuatan aplikasi administrasi sekolah. BAB III ANALISA DAN PERANCANGAN Pada bab ini dilakukan analisa terhadap data/dokumen dan kegiatan/proses yang ada dalam kegiatan administrasi sekolah di SMK AVERUS JAKARTA. Kemudian dilakukan perancangan basis data dan aplikasi administrasi sekolah yang akan dibuat. BAB IV IMPLEMENTASI DAN PENGUJIAN Berisi hasil implementasi dari perancangan aplikasi yang telah dibuat pada bab III, dan berisi hasi pengujian terhadap aplikasi untuk mengetahui kesiapan aplikasi untuk diimplementasi di SMK AVERUS JAKARTA. BAB V
PENUTUP
Pada bab penutup berisi kesimpulan dari hasil analisa dan pembahasan, serta berisi saran-saran untuk perbaikan terhadap aplikasi yang telah dibuat agar lebih baik.
BAB II LANDASAN TEORI
2.1
Implementasi Dalam Kamus Besar Bahasa Indonesia (KBBI), implementasi berarti
penerapan/pelaksanaan (Depdiknas, 2013). Implementasi dapat diartikan sebagai suatu tindakan atau pelaksanaan dari sebuah rencana yang sudah disusun secara matang dan terperinci. Implementasi biasanya dilakukan setelah perencanaaan selesai dilakukan dan sudah dianggap final. Jika dihubungkan dengan aplikasi, implementasi adalah penerapan dari sebuah desain aplikasi yang telah dirancang dengan lengkap pada sebuah pemrograman komputer. Dari implementasi ini akan dihasilkan sebuah aplikasi komputer yang dapat berjalan sesuai rancangan yang telah dibuat.
2.2
Membangun Aplikasi Aplikasi adalah penggunaan atau penerapan suatu konsep yang menjadi
pokok pembahasan. Aplikasi dapat diartikan juga sebagai program komputer yang dibuat untuk menolong manusia dalam melaksanakan tugas tertentu. Aplikasi software yang dirancang untuk penggunaan praktisi khusus, klasifikasi luas ini dapat dibagi menjadi 2 (dua) yaitu: a. Aplikasi software spesialis, program dengan dokumentasi tergabung yang dirancang untuk menjalankan tugas tertentu. b. Aplikasi paket, suatu program dengan dokumentasi tergabung yang dirancang untuk jenis masalah tertentu.
Dalam Kamus Besar Bahasa Indonesia (KBBI), membangun berarti mendirikan, mengadakan, atau memperbaiki (Depdiknas, 2013). Jadi membangun aplikasi berarti membuat, mengadakan, atau memperbaiki program komputer untuk membantu/mempermudah manusia dalam mengerjakan tugas tertentu.
7
8
2.3
Administrasi Sekolah
2.3.1 Administrasi Dalam Kamus Besar Bahasa Indonesia (KBBI), administrasi dapat diartikan sebagai usaha dan kegiatan yang meliputi penetapan tujuan serta penetapan caracara penyelenggaraan pembinaan organisasi, usaha dan kegiatan yang berkaitan dengan penyelenggaraan kebijakan untuk mencapai tujuan, kegiatan yang berkaitan dengan penyelenggaraan pemerintahan, atau kegiatan kantor dan tata usaha (Depdiknas, 2013). Administrasi adalah ilmu yang mempelajari proses kegiatan kerjasama untuk mencapai tujuan yang telah ditentukan. Kegiatan kerjasama itu sendiri merupakan gejala yang sifatnya universal dan memerlukan suatu proses pergerakan yang disebut dengan manajemen. Dengan demikian, untuk mencapai tujuannya administrasi perlu membentuk suatu manajemen dalam suatu organisasi sebagai wadah, kerangka, atau struktur untuk menjalin suatu kerjasama yang baik. Administrasi adalah keseluruhan proses kerjasama antara dua orang manusia atau lebih yang didasarkan atas rasionalitas tertentu untuk mencapai tujuan yang telah ditentukan sebelumnya (Antonio & Safriadi, 2012). Secara etimologis administrasi berasal dari bahasa latin yang terdiri dari kata ad yang berarti intensif dan ministraire yang berarti melayani. Literatur lain menjelaskan bahwa administrasi merupakan terjemahan dari bahasa Inggris yaitu administration yang bentuk infinitifnya adalah to administer. Atau administrasi berasal dari bahasa Belanda, yaitu administratie yang meliputi kegiatan pembukaan ringan, mencatat, menyurat, mengetik, agenda dan sebagainya yang bersifat teknis ketatausahaan. Berdasarkan uraian di atas dapat diambil kesimpulan bahwa administrasi adalah kegiatan penyusunan dan pencatatan data secara sistematis dengan maksud untuk menyediakan informasi serta memudahkan memperolehnya kembali secara keseluruhan.
9
2.3.2 Administrasi Sekolah Administrasi
sekolah
meliputi
administrasi
program
pengajaran,
administrasi kesiswaan, administrasi kepegawaian, administrasi keuangan dan administrasi perlengkapan atau barang. A. Administrasi program pengajaran Administrasi program pengajaran dilakukan dengan tujuan memudahkan kepala sekolah dalam menyelenggarakan administrasi sekolah. Kegiatan yang
dilakukan
meliputi
menyusun
jadwal
pelajaran,
program
pengajaran, pencatatan nilai dan pelaporan hasil belajar B. Administrasi kesiswaan Dalam adminstrasi kesiswaan selama satu tahun pelajaran dibagi dalam 3 tahap waktu dan dalam tiap tahapan waktu terdapat beberapa jenis kegiatan, yaitu : a. Awal tahun pelajaran Penerimaan siswa baru b. Selama tahun ajaran - Penyusun data pribadi siswa - Keadaan siswa awal tahun - Kehadiran siswa c. Akhir tahun pelajaran - Pelaksanaaan ujian nasional - Kenaikan kelas C. Administrasi Kepegawaian Administrasi kepegawaian menguraikan kegiatan yang berkaitan dengan pengaturan kepegawaian, tugas dan tanggung jawab pengelolaan satuan pendidikan dan peningkatan tata usaha kepegawaian di sekolah. D. Administrasi Keuangan Administrasi keuangan bertugas dan bertanggung jawab dalam pengelolaan keuangan sekolah.
10
E. Administrasi Perlengkapan atau Barang Administrasi
perlengkapan
atau
barang
memiliki
perencanaan, pengadaan, penyimpanan dan
tugas
dalam
pemeliharaan semua
perlengkapan atau barang yang ada di sekolah.
Administrasi program pengajaran, kesiswaan, kepegawaian dibentuk ke dalam satu divisi yaitu divisi tata usaha, sedangkan untuk administrasi keuangan dibentuk secara khusus ke dalam divisi keuangan.
2.4
Arsitektur Client-Server Arsitektur client-server merupakan arsitektur yang paling baik untuk
digunakan, sistem ini mampu menghasilkan aplikasi basis data yang tangguh dalam hal sekuritas, serta mampu mengurangi kepadatan lalu-lintas jaringan (Prasetyo, 2004). Dalam arsitektur client-server terdapat dua mesin yang berfungsi sebagai server dan client. Secara
umum
arsitektur
client-server
merupakan
sebuah
aplikasi
terdistribusi yang bertugas untuk mempartisi atau membagi pekerjaan antara server (penyedia layanan) dan client. Client dan server sering juga beroperasi menggunakan jaringan komputer pada hardware yang terpisah. Server adalah sebuah mesin yang memiliki performa tinggi dan menjalankan satu atau lebih program untuk memberikan data-data yang diminta oleh client (Prasetyo, 2004). Sebuah client tidak mempunyai sumber daya apapun, namun meminta server untuk menyediakan sumber daya yang diperlukan. Oleh karena itu client-lah yang terlebih dahulu memulai sesi komunikasi dengan server yang menunggu request (permintaan) dari client. Arsitektur client-server merupakan model konektivitas pada jaringan yang membedakan fungsi komputer sebagai client dan server. Pendek kata, arsitektur client-server membagi beban kerja antara client dan server (Alam, 2005). Arsitektur ini menempatkan sebuah komputer sebagai server, yang bertugas memberikan pelayanan kepada terminal-terminal lainnya yang terhubung dalam sistem jaringan atau yang disebut client. Server juga dapat bertugas untuk
11
memberikan layanan berbagi pakai berkas (file server), printer (printer server), jalur komunikasi (communication server). Pada arsitektur ini, client tidak dapat berfungsi sebagai server, tetapi server dapat berfungsi menjadi client (server non-dedicated). Prinsip kerja pada arsitektur ini sangat sederhana, di mana server akan menunggu permintaan dari client, memproses dan memberikan hasil kepada client. Sedangkan client akan mengirimkan permintaan ke server, menunggu proses dan melihat visualisasi hasil prosesnya. Server menurut bahasa inggris berasal dari kata serve yang berarti melayani, dengan kata lain server bisa disebut juga dengan pelayan. Hal ini memang sesuai tugas utama dari server adalah melayani, entah melayani permintaan atau pengiriman. Server dalam ilmu komputer adalah sebuah komputer (workstation) yang difungsikan untuk melayani beberapa permintaan-permintaan tertentu. Server dalam ilmu komputer juga terdapat beberapa jenis dan macamnya, semisal proxy server yang bertugas sebagai pelayan proxy, SQL server yang bertugas sebagai pelayan atau penyedia database, DHCP server yang melayani/menyediakan IP address untuk client-nya, mail server yang melayani keluar masuk surat elektronik (e-mail), web server yang melayani permintaan atau akses menuju web yang berada pada server tersebut. Server komputer berbeda dengan server manusia (pelayan, buruh). Dalam kehidupan manusia, pelayan (baca: server) cenderung menempati posisi jabatan yang paling rendah atau bisa dibilang sering tertindas oleh majikanya, ini berbanding terbalik dengan server versi komputer yang menempati posisi jabatan yang paling tinggi karena rata-rata komputer yang dijadikan sebagai server memiliki spesifikasi hardware yang mumpuni daripada komputer client biasa, karena memang tugasnya yang harus melayani client dengan jumlah yang tidak sedikit. Client-server adalah suatu hubungan antara pelayan dan yang dilayani, seperti yang sudah saya jelaskan di atas bahwa server tugasnya adalah melayani client, berikut ini ilustrasi hubungan client dengan server:
12
Client
Network
Server
Client
Printer Client
Gambar 2. 1 Hubungan antara client dengan server
2.4.1 Kelebihan Client-Server Aplikasi client-server memiliki beberapa kelebihan, antara lain: a. Lebih aman b. Semua data dapat di-backup pada satu lokasi sentral c. Kecepatan akses lebih tinggi karena penyediaan fasilitas jaringan dan pengelolaannya dilakukan secara khusus oleh satu komputer (server) yang tidak dibebani dengan tugas lain sebagai workstation
2.4.2 Kekurangan Client-Server Selain memiliki kelebihan, client-server juga memiliki kekurangan, yaitu: a. Membutuhkan administrator yang handal b. Pelaksanannya mahal c. Jika server mati maka komputer client akan mati juga
2.5
Basis Data (Database) Pengertian basis data (database) merupakan sekumpulan informasi yang
saling berkaitan pada suatu objek tertentu pada tujuan tertentu pula. Basis data adalah susunan record data operasional lengkap dari suatu organisasi atau perusahaan
yang
terorgansir
dan
disimpan
secara
terintegrasi
dengan
13
menggunakan metode tertentu dalam komputer sehingga mampu memenuhi informasi yang optimal yang dibutuhkan oleh para pengguna. Basis data dalam bahasa inggris “database” adalah kumpulan informasi yang disimpan di dalam komputer secara sistematik sehingga dapat diperiksa menggunakan program komputer (software) untuk memperoleh informasi dari basis data tersebut. Perangkat lunak yang digunakan untuk mengelola dan memanggil query basis data disebut sistem manajemen basis data (Database Management System atau disingkat DBMS). Istilah “basis data” berawal dari ilmu komputer. Meskipun kemudian artinya semakin luas, memasukkan hal-hal di luar bidang elektronika. Catatan yang mirip dengan basis data sebenarnya sudah ada sebelum revolusi industri yaitu dalam bentuk buku besar, kuitansi dan kumpulan data yang berhubungan dengan bisnis. Konsep dasar dari basis data adalah kumpulan dari catatan-catatan atau potongan dari pengetahuan. Untuk membuat basis data dapat dilakukan melalui beberapa tahap perancangan, yaitu: a. Membuat ERD (Entity Relationship Diagram) b. Membuat ERD (Entity Relationship Diagram) ke LRS (Logical Record Structure) c. Membuat LRS (Logical Record Structure) d. Melakukan normalisasi
2.5.1 ERD (Entity Relationship Diagram) Model E-R (Entity Relationship) adalah suatu model yang digunakan untuk menggambarkan data dalam bentuk entitas, atribut, dan hubungan antarentitas (Kadir, 2009). Karena model E-R dinyatakan dalam bentuk diagram, maka sering disebut sebagai diagram E-R, atau dalam bahasa inggris disebut ERD (Entity Relationship Diagram). ERD (Entity Relationship Diagram) merupakan jaringan yang menggunakan susunan data yang disimpan pada sistem secara abstrak, tabeltabel ditunjukkan sebagai entitas atau relasi yang diimplementasikan melalui kolom-kolom biasa dalam dua atau lebih tabel, menggunakan atribut yang dikenal sebagai primary key dan foreign key (Widhyaestoeti, 2011). ERD hanya berfokus
14
pada data dan hubungan yang mengatur data tersebut (Kristanti & Redita, 2012). ERD digunakan untuk memodelkan struktur data dan hubungan antardata, untuk menggambarkannya digunakan beberapa notasi dan simbol. Pada dasarnya ada tiga simbol yang digunakan, yaitu: A. Entiti Entiti merupakan objek yang mewakili sesuatu yang nyata dan dapat dibedakan dari sesuatu yang lain. Simbol dari entiti ini biasanya digambarkan dengan persegi panjang. B. Atribut Setiap entitas pasti mempunyai elemen yang disebut atribut yang berfungsi untuk mendeskripsikan karakteristik dari entitas tersebut. Isi dari atribut mempunyai sesuatu yang dapat mengidentifikasikan isi elemen satu dengan yang lain. Gambar atribut diwakili oleh simbol elips. C. Hubungan/Relasi Hubungan antara sejumlah entitas yang berasal dari himpunan entitas yang berbeda. Relasi dapat digambarkan sebagai berikut :
Relasi yang terjadi di antara dua himpunan entitas (misalnya A dan B) dalam satu basis data yaitu: a. Satu ke satu (One to one) Hubungan relasi satu ke satu yaitu setiap entitas pada himpunan entitas A berhubungan paling banyak dengan satu entitas pada himpunan entitas B. b. Satu ke banyak (One to many) Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B, tetapi setiap entitas pada entitas B dapat berhubungan dengan satu entitas pada himpunan entitas A. c. Banyak ke banyak (Many to many) Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B.
15
2.5.2 Transformasi ERD ke LRS LRS (Logical Record Structure) adalah representasi dari struktur recordrecord pada tabel-tabel yang terbentuk dari hasil antarhimpunan entitas. Transformasi diagram ERD (Entity Relationship Diagram) ke LRS (Logical Record Structure) merupakan suatu kegiatan untuk membentuk data-data dari diagram hubungan entitas ke suatu LRS. Entitas dibedakan menjadi tipe entitas kuat dan tipe entitas lemah (Kadir, 2009). Tipe entitas kuat adalah tipe entitas yang keberadaannya tidak bergantung pada tipe entitas lain. Tipe entitas kuat dinyatakan dengan tanda kotak. Ada perlakuan berbeda dalam melakukan transformasi tipe entitas kuat ke dalam relasi. Penentunya adalah jenis atribut, yaitu atribut sederhana, atribut komposit, atribut bernilai banyak, ataupun atribut turunan, berikut ini adalah penjelasannya: a. Atribut sederhana Suatu atribut sederhana ditransformasikan ke dalam relasi menjadi atribut dalam relasi dengan cara sebagai berikut: - Membentuk relasi dengan nama yang sama dengan nama dalam tipe entitas. - Meletakkan semua atribut dalam diagram E-R ke dalam relasi. - Membentuk kunci primer relasi berupa atribut yang menjadi kunci primer dalam tipe entitas. b. Atribut komposit Atribut komposit tidak perlu dimasukkan ke dalam relasi, karena bisa diwakili oleh atribut sederhana yang menyusun atribut komposit tersebut. Misalnya atribut alamat merupakan atribut komposit yang disusun oleh atribut nama jalan, kota, dan kode pos, maka atribut alamat tidak perlu dimasukkan, karena sudah terwakili oleh atribut nama jalan, kota, dan kode pos. c. Atribut bernilai banyak Jika ada atribut bernilai banyak, maka dibuat relasi tambahan dengan nama yang mencerminkan nama atribut tersebut. Kunci primer yang digunakan berupa kunci primer dari tipe entitas ditambah dengan atribut
16
yang bernilai banyak. Misalnya entitas mahasiswa memiliki atribut hobi, sedangkan atribut hobi dapat bernilai banyak, maka perlu dibuat relasi hoby yang memiliki kunci primer NIM dan id_hobi. d. Atribut turunan Jika terdapat atribut turunan atau atribut gabungan, secara prinsip dapat dilakukan transformasi menggunakan prinsip-prinsip yang telah dibahas. Misalnya ada entitas karyawan memiliki atribut tanggal mulai bekerja, maka tidak perlu ada atribut masa kerja, karena masa kerja dapat dihitung berdasarkan atribut tanggal mulai bekerja.
2.5.3 Normalisasi Desain basis data memengang peranan yang sangat penting dalam sistem basis data, dan selayaknya dilakukan setelah adanya analisi sistem dan permasalahan di tempat basis data diterapkan (Wahana Komputer, 2010). Desain basis data perlu dilakukan secara cermat agar dihasilkan basis data yang efisien dalam penggunaan ruang penyimpanan, cepat dalam pengaksesan, dan mudah dalam manipulasi data. Salah satu cara yang dapat dilakukan dalam merancang basis data seperti ini adalah dengan melakukan normalisasi. Normalisasi adalah proses menata ulang basis data ke dalam bentuk standar (normal) yang bertujuan untuk mencegah adanya anomali (Stephens R. , 2009). Normalisasi juga didefinisikan sebagai suatu proses yang digunakan untuk menentukan pengelompokan atribut-atribut dalam sebuah relasi sehingga diperoleh relasi yang berstruktur baik, yaitu struktur yang mengandung redundansi sesedikit mungkin, dan memungkinkan baris-baris dalam relasi disisipkan, dimodifikasi, dan dihapus tanpa menimbulkan kesalahan atau ketidakkonsistenan (Kadir, 2009). Proses normalisasi merupakan dasar untuk pemodelan dan desain basis data relasional dengan tujuan untuk menghilangkan redundansi data, menghindari data anomali yang dapat terjadi dalam basis data unnormalized (basis data yang belum dinormalisasi), dan untuk menyederhanakan penegakan kendala integritas (Stephens & Plew, 2001). Berbeda dengan kebiasaan, biasanya teori ditemukan terlebih dahulu sebelum diterapkan dalam praktik. Teori normalisasi dibangun atau dibentuk
17
menurut konsep level normalisasi. Level normalisasi atau sering disebut sebagai bentuk normal suatu relasi, dijelaskan berdasarkan kriteria tertentu pada bentuk normal. Setidaknya terdapat dua pendekatan untuk normalisasi, yaitu bekerja dari Entity Relationship Diagram (ERD), atau menggunakan konsep-konsep teoritis di balik desain yang baik untuk membuat relasi (Harrington, 2009). Bentuk normal yang dikenal hingga saat ini meliputi bentuk 1NF (First Normalized Form), 2NF (Second Normalized Form), 3NF (Third Normalized Form), BCNF (Boyce-Codd Normalized Form/BCNF), 4NF (Forth Normalized Form), 5NF (Fifth Normalized Form), dan DKNF (Domain Key Normalized Form). Secara berturut-turut masing-masing level normal tersebut akan dibahas dari bentuk tidak normal, berikut ini penjelasan dari masing-masing level: A. Relasi bentuk tidak normal (Un-Normalized Form/UNF) Relasi bentuk tidak normal adalah relasi-relasi yang dirancang tanpa mengindahkan batasan dalam definisi basis data dan karakteristik RDBMS (Relational Database Management System). Pada bentuk ini semua data pada tiap entity (diambil atributnya) dan ditampung dalam tabel besar, sehingga masih ada kemungkinan terjadi redudansi atau kosong (Wahana Komputer, 2010). Bentuk ini harus dihindari dalam perancangan relasi dalam basis data. Relasi UNF mempunyai kriteria sebagai berikut: a. Jika relasi mempunyai bentuk nonflat file (dapat terjadi akibat data disimpan sesuai dengan kedatangannya, tidak memiliki struktur tertentu, terjadi duplikasi atau tidak lengkap) b. Jika relasi memuat set atribut berulang (nonsingle value) c. Jika relasi memuat atribut nonatomic value
B. Relasi bentuk normal pertama (First Normalized Form/1NF) Suatu relasi dapat disebut dengan 1NF apabila memenuhi kriteria sebagai berikut: a. Jika seluruh atribut dalam relasi bernilai atomic (atomic value) b. Jika seluruh atribut dalam relasi bernilai tunggal (single value) c. Jika relasi tidak memuat set atribut berulang
18
d. Jika semua record mempunyai sejumlah atribut yang sama
Dengan kata lain bentuk normal pertama adalah sebuah model data yang setiap atribut yang dimilikinya memiliki satu dan hanya satu nilai. Apabila ada atribut yang memiliki nilai lebih dari satu, atribut tersebut adalah kandidat untuk menjadi entitas tersendiri. Permasalahan dalam 1NF adalah sebagai berikut: a. Tidak dapat menyisipkan informasi persial b. Terhapusnya informasi ketika menghapus sebuah record c. Pembaharuan atribut nonkunci mengkibatkan sejumlah record harus diperbaharui
Mengubah relasi UNF
menjadi 1NF dapat dilakukan dengan cara
sebagai berikut: a. Melengkapi nila-nilai dalam atribut b. Mengubah struktur relasi
C. Bentuk normal kedua (Second Normalized Form/2NF) Relasi disebut 2NF jika memenuhi kriteria sebagai berikut: a. Jika memenuhi kriteria 1NF b. Jika semua atribut nonkunci ketergantungan fungsional (functionally defedency/FD) pada PK (Primary Key)
Sebuah model data memenuhi bentuk normal kedua apabila memenuhi bentuk normal pertama dan setiap atribut non-identifier sebuah entitas bergantung sepenuhnya hanya pada semua identifier entitas tersebut. Pemasalahan dalam 2NF adalah sebagai berikut: a. Kerangkapan data. b. Pembaharuan yang tidak benar dapat menimbulkan ketidakkonsistenan data. c. Proses pembaharuan data tidak efisien. d. Permasalahan pada saat penyisipan, penghapusan, dan pembaharuan.
19
Mengubah relasi 1NF menjadi bentuk 2NF dapat dilakukan dengan mengubah struktur relasi dengan cara: a. Identifikasi
FD relasi
1NF (jika perlu gambarkan diagram
ketergantungan datanya) b. Berdasarkan informasi tersebut, dekomposisi relasi 1NF menjadi relasi-relasi baru sesuai FD-nya. Jika menggunakan diagram maka simpul-simpul yang berada pada puncak diagram ketergantungan data bertindak sebagai PK pada relasi baru.
D. Bentuk normal ketika (Third Normalized Form/3NF) Suatu relasi disebut sebagai 3NF jika memenuhi kriteria sebagai berikut: a. Jika memenuhi kriteria 2NF b. Jika setiap atribut nonkunci tidak bergantung transitif (non transitive dependency) terhadap PK.
Sebuah model data memenuhi bentuk normal ketiga apabila memenuhi bentuk normal kedua dan tidak ada satupun atribut non-identifying (bukan pengidentifikasi unik) yang bergantung pada atribut nonidentifying lain. Apabila ada, pisahkan salah satu atribut tersebut menjadi entitas baru, dan atribut yang bergantung padanya menjadi atribut entitas baru tersebut. Mengubah relasi 2NF menjasi bentuk 3NF dapat dilakukan dengan mengubah struktur relasi dengan cara sebagai berikut: a. Identifikasi kebergantungan transitif pada relasi 2NF (jika perlu gambarkan diagram ketergantungan datanya) b. Berdasarkan informasi tersebut, dekomposisi relasi 2NF menjadi relasi-relasi
baru
sesuai
kebergantungan
transitifnya.
Jika
menggunakan diagram maka simpul-simpul yang berada pada puncak diagram ketergantungan data bertindak sebagai PK pada relasi baru.
20
Misalkan, terhadap relasi R dengan sifat sebagai berikut: a. R=(A, B, C) dengan PK=A b. FD: R.B→R.C
Maka relasi R perlu didekomposisi menjasi relasi-relasi R1 dan R2, yaitu: a. R1=(B, C) b. R2=(A, B), FK: B references R1
E. Bentuk normal Boyce-Codd (Boyce-Codd Normalized Form/BCNF) Bentuk normal BCNF dikemukakan oleh R. F. Boyce dan E. F. Codd. Suatu relasi disebut dengan BCNF jika memenuhi kriteria sebagai berikut: a. Jika memenuhi kriteria 3NF b. Jika semua atribut penentu (determinan) merupakan CK (Candidate Key)
F. Bentuk normal keempat (Forth Normalized Form/4NF) Relasi disebut sebagai 4NF jika memenuhi kriteria senagai berikut: a. Jika memenuhi kriteria BCNF b. Jika setiap atribut di dalamnya tidak mengalami ketergantungan pada banyak nilai. Atau dengan kalimat lain, bahwa semua atribut yang mengalami ketergantungan pada banyak nilai adalah bergantung secara fungsional (functionally dependency).
G. Bentuk normal kelima (Fifth Normalized Form/5NF) Suatu relasi memenuhi kriteria 5NF kerelasian antardata dalam relasi tersebut tidak dapat direkonstruksi dari struktur relasi yang sederhana. Relasi 5NF memiliki kriteria sebagai berikut: a. Kerelasian antardata dalam relasi tersebut tidak dapat direkonstruksi dari struktur relasi yang memuat atribut yang lebih sedikit.
21
b. Bentuk normal 5NF terpenuhi jika tidak dapat memiliki sebuah lossless decomposition menjadi tabel-tabel yang lebih kecil. c. Jika 4 bentuk normal sebelumnya dibentuk berdasarkan functional dependency, 5NF dibentuk berdasarkan konsep join dependence, yakni apabila sebuah tabel telah didekomposisi menjadi tabel-tabel lebih kecil, harus bisa digabungkan lagi (join) untuk membentuk tabel semula
H. Bentuk normal kunci domain (Domain Key Normalized Form/DKNF) Suatu relasi disebut sebagai DKNF jika setiap batasan dapat disimpulkan secara sederhana dengan mengetahui sekumpulan nama atribut dan domainnya selama menggunakan sekumpulan atribut pada kuncinya. Bentuk DKNF ini dikemukakan oleh R. Fagin pada 1981 dan bersifat sangat spesifik, artinya tidak semua relasi dapat mencapai level ini.
2.6
Pengembangan Aplikasi Pengembangan aplikasi (software) adalah usaha/proses sistematik, disiplin,
pendekatan kuantitatif untuk pengembangan, operasi dan pemeliharaan dari aplikasi (software). Dengan kata lain, pengembangan aplikasi (software) merupakan sebuah metodologi yang membahas semua aspek produksi aplikasi (software), mulai dari tahap awal spesifikasi aplikasi (software) hingga pada tahap pemeliharaan aplikasi (software) setelah digunakan dengan tujuan untuk membuat aplikasi (software) yang tepat dengan metode yang tepat. Untuk meningkatkan fungsionalitas dan efisiensi aplikasi, dan juga kemudahan dan efisiensi dalam pengembangan aplikasi dapat menggunakan teknik rekayasa perangkat lunak (Simarmata, 2010). Rekayasa perangkat lunak adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat lunak termasuk pembuatan, pemeliharaan, manajemen organisasi pengembangan perangkat lunak, dan sebagainya.
22
2.6.1 Siklus Hidup Pengembangan Aplikasi Pengembangan aplikasi (software) merupakan tugas kompleks yang membutuhkan banyak sumber daya dan dapat memakan waktu berbulan-bulan bahkan bertahun-tahun untuk menyelesaikannya. Proses pengembangan aplikasi (software) melewati beberapa tahapan, dari mulai aplikasi (software) itu direncanakan, diterapkan, dioperasikan, sampai pemeliharaan. Bila operasi aplikasi (software) yang sudah dikembangkan masih timbul permasalahanpermasalahan kritis serta tidak dapat diatasi dalam tahap pemeliharaan aplikasi (software), maka perlu dikembangkan kembali suatu aplikasi (software) untuk mengatasinya dan proses ini kembali ke tahap yang pertama, yaitu tahap perencanaan sistem. Siklus hidup pengembangan aplikasi/sistem (Systems Development Life Cycle disingkat SDLC) adalah proses memahami bagaimana sistem informasi dapat mendukung kebutuhan bisnis, merancang sistem, membangun, dan memberikan ke pengguna (Dennis, Wixom, & Roth, 2009). Siklus hidup pengembangan aplikasi (software) merupakan pendekatan melalui beberapa tahap untuk menganalisis dan merancang sistem yang di mana sistem tersebut telah dikembangkan dengan sangat baik melalui penggunaan siklus kegiatan penganalisis dan pemakai secara spesifik, siklus itu antara lain: a. Pengumpulan data (data gathering) Jika sudah ada sistem yang berjalan sebelumnya maka perlu dilakukan pengumpulan data dan informasi yang dihasilkan dari sistem yang ada. Pengumpulan laporan (report), cetakan (print-out), dan sebagainya, baik yang sudah ada maupun yang diharapkan untuk ada pada sistem yang baru. Interview dan kuesioner terhadap orang-orang yang terlibat dalam sistem juga mungkin perlu dilakukan. Apabila sistem yang akan dikembangkan
benar-benar
baru
(belum
ada
sistem
informasi
sebelumnya) maka pada tahapan ini pengembang bisa lebih menekankan kepada studi kelayakan dan definisi sistem. b. Analisa sistem Jika tahapan pengumpulan data dilakukan dengan melibatkan klien atau pengguna sistem informasi, maka mulai dari tahapan analisa lebih
23
banyak dilakukan oleh pihak pengembang sendiri. Analisa terhadap sistem yang sedang berjalan dan sistem yang akan dikembangkan. Mendefinisikan objek-objek yang terlibat dalam sistem dan batasan sistem. c. Perancangan sistem (design) Merancang alir kerja (workflow) dari sistem dalam bentuk diagram alir (flowchart) atau Data Flow Diagram (DFD). Merancang basis data (database) dalam bentuk Entity Relationship Diagram (ERD) bisa juga sekalian membuat basis data secara fisik. Merancang input dan ouput, antarmuka (interface), dan menentukan form-form dari setiap modul yang ada. Merancang arsitektur aplikasi dan jika diperlukan menentukan juga kerangka kerja (framework) aplikasi. Pada tahapan ini atau sebelumnya sudah ditentukan teknologi dan tools (peralatan) yang akan digunakan baik selama tahap pengembangan (development) maupun pada saat implementasi (deployment). d. Penulisan kode program (coding) Programming
(desktop
application)
atau
Scripting
(web-based
application) hanyalah salah satu tahapan dari siklus hidup pengembangan sistem. Tahapan ini dilakukan oleh satu atau lebih programmer. Jika tahapan analisa dan perancangan sistem telah dilakukan dengan baik, maka porsi tahapan coding (pengkodean) tidaklah besar. e. Testing Biasanya tahapan ini dilakukan oleh Quality Assurance (QA) dari pihak pengembang untuk memastikan bahwa software yang dibangun telah berjalan sesuai dengan yang diharapkan. Salah satu metodenya bisa dengan meng-input sejumlah data pada sistem baru dan membandingkan hasilnya dengan sistem lama. Apabila diperlukan maka tahapan ini bisa dibagi menjadi dua yaitu testing oleh pihak pengembang (alpha testing) dan testing oleh pihak pengguna (beta testing). f. Instalasi Pada pengembangan aplikasi client-server, umumnya terdapat server untuk development, testing, dan production. Server development berada
24
di tempat pengembang dan dipergunakan selama pengembangan dan bisa juga setelahnya untuk perbaikan aplikasi secara terus menerus (continuous improvements). Server testing berada di tempat pengembang dan bisa juga di tempat pengguna apabila diperlukan beta testing. Setelah aplikasi dirasa siap untuk dipergunakan maka digunakanlah server production yang berada di tempat pengguna. Pada prakteknya di tempat pengembang juga bisa terdapat server production yaitu server yang memiliki spesifikasi hardware dan software yang sama dengan server di tempat pengguna. Hal ini dimaksudkan agar apabila ditemukan error atau bug pada aplikasi di tempat pengguna maka pengembang dapat mudah mencari penyebabnya pada server production mereka. g. Pelatihan Pihak pengembang memberikan training bagi para pengguna program aplikasi sistem informasi ini. Apabila sebelumnya tidak dilakukan beta testing maka pada tahapan ini juga bisa dilangsungkan User Acceptance Test (UAT). h. Pemeliharaan Maintenance bertujuan untuk memastikan bahwa sistem yang digunakan oleh pihak pengguna benar-benar telah stabil dan terbebas dari error dan bug. Pemeliharaan ini biasanya berkaitan dengan masa garansi yang diberikan oleh pihak pengembang sesuai dengan perjanjian dengan pihak pengguna. Lamanya waktu pemeliharaan sangat bervariasi. Namun pada umumnya sistem informasi yang kompleks membutuhkan masa pemeliharaan dari enam bulan hingga seumur hidup program aplikasi.
2.6.2 Model Pengembangan Aplikasi System Development Life Cycle (SDLC) memberikan landasan pada proses yang digunakan untuk mengembangkan sistem informasi (Dennis, Wixom, & Roth, 2009). Ada beberapa model pengembangan aplikasi/sistem yang dapat digunakan, berikut ini beberapa model pengembangan aplikasi (software):
25
A. Model sekuensial linier (waterfall) Model sekuensial linier sering disebut model air terjun (waterfall) merupakan paradigma rekayasa perangkat lunak yang paling tua dan paling banyak dipakai. Model ini memungkinkan pemecahan misi pengembangan yang rumit menjadi beberapa langkah logis (Simarmata, 2010), yaitu dengan mengusulkan sebuah pendekatan perkembangan perangkat lunak yang sistematik dan sekunsial yang dimulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian, dan pemeliharaan. Model sekunsial linier mengikuti aktivitas-aktivitas berikut ini: a. Rekayasa dan pemodelan sistem/informasi Karena perangkat lunak merupakan bagian dari suatu sistem maka langkah pertama dimulai dengan membangun syarat semua elemen sistem
dan
mengalokasikan
ke
perangkat
lunak
dengan
memeperhatiakn hubungannya dengan manusia, perangkat keras dan basis data. b. Analisis kebutuhan perangkat lunak Proses menganalisis dan pengumpulan kebutuhan sistem yang sesuai dengan domain informasi tingkah laku, unjuk kerja, dan antar muka (interface)
yang
diperlukan.
Kebutuhan-kebutuhan
tersebut
didokumentasikan dan dilihat lagi dengan pelanggan. c. Desain Proses desain akan menerjemahkan syarat kebutuhan ke sebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat coding. Proses ini berfokus pada struktur data, arsitektur perangkat lunak, representasi interface, dan detil algoritma prosedural. d. Pengkodeaan (coding) Pengkodean merupakan proses menerjemahkan desain ke dalam suatu bahasa yang bisa dimengerti oleh komputer. e. Pengujian Proses pengujian dilakukan pada logika internal untuk memastikan semua pernyataan sudah diuji. Pengujian eksternal fungsional untuk
26
menemukan kesalahan-kesalahan dan memastikan bahwa input akan memberikan hasil yang aktual sesuai yang dibutuhkan. f. Pemeliharaan Perangkat lunak yang sudah disampaikan kepada pelanggan pasti akan mengalami perubahan. Perubahan tersebut bisa karena mengalami kesalahan karena perangkat lunak harus menyesuaikan dengan lingkungan (periperal atau sistem operasi baru) baru, atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja.
Sebelum menggunakan model sekuensial linier (waterfall), dapat mempertimbangkan kelebihan dan kekurangannya. Kelebihan dari model sekuensial linier (waterfall) adalah: a. Mudah aplikasikan. b. Memberikan template tentang metode analisis, desain, pengkodean, pengujian, dan pemeliharaan.
Kekurangan dari model sekuensial linier (waterfall) adalah: a. Jarang sekali proyek riil mengikuti aliran sekuensial yang dianjurkan model karena model ini bisa melakukan itersi tidak langsung . Hal ini berakibat ada perubahan yang diragukan pada saat proyek berjalan. b. Pelanggan sulit untuk menyatakan kebutuhan secara eksplisit sehingga sulit untuk megakomodasi ketidakpastian pada saat awal proyek. c. Pelanggan harus bersikap sabar karena harus menunggu sampai akhir proyek dilalui. Sebuah kesalahan jika tidak diketahui dari awal akan menjadi masalah besar karena harus mengulang dari awal. d. Pengembang sering malakukan penundaan yang tidak perlu karena anggota tim proyek harus menunggu tim lain untuk melengkapi tugas karena memiliki ketergantungan hal ini menyebabkan penggunaan waktu tidak efesien.
27
B. Prototipe (Prototype) Prototyping merupakan salah satu metode pengembangan perangat lunak yang banyak digunakan. Dengan metode prototyping ini pengembang dan pelanggan dapat saling berinteraksi selama proses pembuatan sistem. Sering terjadi seorang pelanggan hanya mendefinisikan secara umum apa yang dikehendakinya tanpa menyebutkan secara detil output apa saja yang dibutuhkan, pemrosesan dalam aplikasi, dan data-data apa saja yang dibutuhkan. Sebaliknya di sisi pengembang kurang memperhatikan efesiensi algoritma, kemampuan sistem operasi dan interface yang menghubungkan manusia dengan komputer. Untuk mengatasi ketidakserasian antara pelanggan dan pengembang, maka dibutuhkan kerjasama yanga baik di antara keduanya sehingga pengembang akan mengetahui dengan benar apa yang diinginkan pelanggan dengan tidak mengesampingkan segi-segi teknis, dan pelanggan akan mengetahui proses-proses dalam menyelesaikan sistem yang diinginkan. Dengan demikian akan menghasilkan sistem sesuai dengan jadwal waktu penyelesaian yang telah ditentukan. Kunci agar model prototype ini berhasil dengan baik adalah dengan mendefinisikan aturan-aturannya pada saat awal, yaitu pelanggan dan pengembang
harus
setuju
bahwa
prototype
dibangun
untuk
mendefinisikan kebutuhan. Prototype akan dihilangkan sebagian atau seluruhnya, dan perangkat lunak aktual direkayasa dengan kualitas dan implementasi yang sudah ditentukan. Tahapan-tahapan dalam model prototyping adalah sebagai berikut: a. Pengumpulan kebutuhan Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat. b. Membangun prototyping Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output).
28
c. Evaluasi protoptyping Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang dibangun sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai maka dilanjutkan langkah “d”. Jika tidak prototyping direvisi dengan mengulangi langkah “a”, “b” , dan “c”. d. Mengkodekan sistem Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai. e. Menguji sistem Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus diuji dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain. f. Evaluasi Sistem Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan. Jika ya, langkah “g” dilakukan; jika tidak, ulangi langkah ”d” dan “e”. g. Menggunakan sistem Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.
Keunggulan model prototyping adalah: a. Adanya komunikasi yang baik antara pengembang dan pelanggan. b. Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan. c. Pelanggan berperan aktif dalam pengembangan sistem. d. Lebih menghemat waktu dalam pengembangan sistem. e. Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.
29
Kelemahan prototyping adalah: a. Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangka waktu lama. b. Pengembang biasanya ingin cepat menyelesaikan proyek, sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan cetak biru sistem. c. Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik.
Prototyping bekerja dengan baik pada penerapan-penerapan yang berciri sebagai berikut: a. Resiko tinggi, yaitu untuk masalah-masalah yang tidak terstruktur dengan baik, ada perubahan yang besar dari waktu ke waktu, dan adanya persyaratan data yang tidak menentu. b. Interaksi pemakai penting. Sistem harus menyediakan dialog online antara pelanggan dan komputer. c. Perlunya penyelesaian yang cepat. d. Perilaku pemakai yang sulit ditebak. e. Sitem yang inovatif. Sistem tersebut membutuhkan cara penyelesaian masalah dan penggunaan perangkat keras yang mutakhir. f. Perkiraan tahap penggunaan sistem yang pendek.
C. Incremental Pembuatan sofware dengan model incremental merupakan proses yang terpecah menjadi beberapa bagian. Model ini mengandalkan prioritas dan sistematika, jadi software yang paling penting dan yang paling berpengaruh pada software lain yang harus dikerjakan terlebih dahulu. Diumpakan seperti menjahit baju, pertama-tama yang harus dilakukan
30
adalah menggambar pola, menggunting kain, dan menjahitnya. Menggunting kain tidak dapat dilakukan sebelum menggambar pola, dan baju tak dapat dijahit sebelum kainnya digunting. Seperti itulah ilustrasi model incremental. Kelebihan model incremental: a. Personil bekerja optimal. b. Pihak konsumen dapat langsung menggunakan dahulu bagian-bagian yang telah selesai dibangun. c. Mengurangi trauma karena perubahan sistem. Klien dibiasakan perlahan-lahan menggunakan produknya bagian per bagian.
Kekurangan model incremental: a. Ada kemungkinan tiap bagian tidak dapat diintegrasikan. b. Diperlukan kemampuan untuk selalu melakukan perubahan tanpa menurunkan kualitas. c. Memungkinkan penambahan staf.
D. Spiral Merupakan gabungan
model
prototyping
dan
waterfall. Proses
pembuatannya mulai dari customer communication, planning, risk analysis, engineering, construction and release, customer evaluation. Proses ini akan terus berulang demi pemenuhan kebutuhan pelanggan, walaupun perangkat lunak telah selesai. Kelebihan model spiral: a. Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar b. Dapat digunakan dalam waktu sangat lama karena perubahan terus dilakukan c. Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi resiko sebelum menjadi permasalahan yang serius
31
Kelemahan model spiral: a. Sulit untuk mengontrol perubahan yang ingin dilakukan karena jangka panjang b. Sulit meyakinkan pelanggan mengenai pendekatan evolusioner c. Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yangserius jika resiko mayor tidak ditemukan dan diatur. d. Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolut.
2.7
Pemrograman Berorientasi Objek Pemrograman berorientasi objek merupakan paradigma baru dalam rekayasa
software yang didasarkan pada objek dan kelas. Diakui para ahli bahwa pemrograman berorientasi objek merupakan metodologi terbaik yang ada saat ini dalam rekayasa software. Pemrograman berorientasi objek menggantikan pemrograman terstruktur karena
mempunyai
banyak keunggulan dalam
menangani proyek yang luar biasa kompleks (Hariyanto, 2007). Pemrograman berorientasi objek memandang software bagian per bagian, dan menggambarkan satu bagian tersebut dalam satu objek. Satu objek dalam sebuah model merupakan suatu fokus selama dalam proses analisis, perancangan dan implementasi dengan menekankan pada state, perilaku (behavior) dan interaksi objek dalam model tersebut. Pemrograman berorientasi objek merupakan suatu konsep yang banyak digunakan oleh pengembang software, karena menawarkan kemudahan dalam desain, pengembangan, dan perawatan, sehingga merupakan pendekatan yang efektif untuk membangun perangkat lunak yang fleksibel. Teknologi pemodelan dan pemrograman berorientasi objek memudahkan dalam pengembangan software, baik pengubahan, menambah, dan memperbaiki arsitektur software (Sumarta, Siswoyo, & Juhana, 2004). Pemrograman berorientasi objek adalah sebuah konsep pemrograman untuk membuat kode program yang lebih terstruktur, terkelompok, berdasarkan objekobjek yang terlibat sehingga bagian-bagiannya dapat digunakan untuk pembuatan aplikasi lain. Pemrograman berorientasi objek membagi-bagi kode program
32
aplikasi menjadi kumpulan bungkusan benda/objek dipandang dari sudut pandang aplikasi komputer dan proses yang dilakukan dalam aplikasi.
2.7.1 Prinsip-prinsip Pemrograman Berorientasi Objek Ada tujuh prinsip pengembangan berorientasi objek yang terdiri dari empat prinsip utama, yaitu abstraksi (abstraction), enkapsulasi (encapsulation), modularitas (modularity), hirarki (hierarchy)], dan tiga prinsip tambahan, yaitu mengetik (typing), konkurensi (concurrency), dan ketekunan (persistence) (Booch, 1994). Jika ada prinsip utama yang tidak terpenuhi, maka tidak dapat dianggap berorientasi objek. Sedangkan prinsip tambahan berguna untuk kemudahan, tetapi tetap dapat dianggap berorientasi objek walaupun tidak ada. Berikut ini adalah penjelasan dari empat prinsip utama dari pemrograman berorientasi objek: a. Abstraksi Memfokuskan perhatian pada karakteristik objek yang paling penting dan paling dominan yang bisa digunakan untuk membedakan objek tersebut dari objek lainnya. Dengan abstraksi ini pengembang bisa menerapkan konsep KIS (Keep It Simple) pada objek di dunia nyata yang memiliki tingkat kerumitan yang tinggi. b. Enkapsulasi Menyembunyikan banyak hal yang terdapat dalam objek yang tidak perlu diketahui oleh objek lain. Dalam praktek pemrograman enkapsulasi diwujudkan dengan membuat suatu kelas interface yang akan dipanggil oleh objek lain, sementara di dalam objek yang dipanggil terdapat kelas lain yang mengimplementasikan apa yang terdapat dalam kelas interface. Objek lain hanya tahu dia perlu memanggil kelas interface tanpa perlu tahu proses apa saja yang dilakukan di dalam kelas implementasinya, dan untuk menuntaskan proses tersebut perlu berhubungan dengan objek mana saja. Dengan demikian bila terjadi proses perubahan pada proses implementasi maka objek pemanggil tidak akan terpengaruhi secara langsung.
33
c. Modularitas Membagi sistem yang rumit menjadi bagian-bagian yang lebih kecil yang bisa mempermudah pengembang memahami dan mengelola objek tersebut. Contohnya adalah sistem akademis yang bisa dibagi menjadi kemahasiswaan, daftar mata kuliah, pembayaran uang kuliah, dan lainlain. d. Hirarki Hirarki berhubungan dengan abstraksi dan modularitas, yaitu pembagian berdasarkan urutan dan pengelompokan tertentu. Misalnya untuk menentukan objek mana yang berada pada kelompok yang sama, objek mana yang merupakan komponen dari objek yang memiliki hirarki lebih tinggi. Semakin rendah hirarki objek berarti semakin jauh abstraksi dilakukan terhadap suatu objek.
Keempat prinsip dasar ini merupakan hal yang mendasari teknologi objek yang perlu ditanamkan dalam cara berpikir pengembang berorientasi objek.
2.7.2 Bahasa Pemrograman Berorientasi Objek Sebuah bahasa berorientasi objek bukan hanya yang berbasis obyek, tetapi juga menyediakan dukungan untuk pewarisan dan polimorfisme (Booch, 1994). Jadi, sebuah bahasa pemrograman dinyatakan mendukung pemrograman berorientasi objek jika bahasa itu mendukung syarat-syarat pemrograman berorientasi objek sebagai berikut: a. Enkapsulasi (encapsulation) Mampu membungkus atribut-atribut dan metode-metode dalam sebuah kelas, dan dapat mencegah pengaksesan langsung terhadap atribut-atribut dan metode-metode yang diinginkan di dalam sebuah kelas. b. Pewarisan (inheritance) Memungkinkan adanya pendefinisian kelas baru yang memiliki sifat-sifat keturunan dari kelas lain.
34
c. Polimorfisme (polymorphism) Memungkinkan pembuatan pengaksesan metode-metode dengan nama yang sama namun berbeda parameter masukan atau berbeda kelas.
2.7.3 Desain Pemrograman Berorientasi Objek UML (Unified Modelling Language) adalah salah satu alat bantu yang sangat handal di dunia pengembangan sistem berorientasi objek karena menyediakan bahasa pemodelan visual yang memungkinkan pengembang membuat cetak biru atas visi mereka dalam bentuk baku, mudah dimengerti, serta dilengkapi
mekanisme
yang
efektif
untuk
berbagi
(sharing)
dan
mengkomunikasikan rancangan dengan pihak lain (Munawar, 2005). Sejak tahun 1997, UML telah dijadikan sebagai standar pengembangan berorientasi objek (Dennis, Wixom, & Roth, 2009), juga sebagai standar bahasa grafis dan notasi untuk menggambarkan model berorientasi objek (Gomaa, 2011). Pemodelan dengan UML dapat menghasilkan gambaran yang jelas dan memberikan
kemudahan
dalam
menganalisa,
mendesain,
dan
mengimplementasikannya (Sumarta, Siswoyo, & Juhana, 2004). UML (Unified Modelling Language) merupakan metodologi kolaborasi antara metode-metode Booch, OMT (Object Modeling Technique), serta OOSE (Object Oriented Software Engineering) dan beberapa metode lainnya, merupakan metode yang paling sering digunakan saat ini untuk analisis dan perancangan sistem dengan metode berorientasi objek (Nugroho, 2009). UML 2 digambarkan dalam 13 jenis diagram resmi (Fowler, 2003) yang dapat dilihat pada gambar di bawah ini:
35
Class Diagram Component Diagram Composite Structure Diagram Deployment Diagram
Structure Diagram Object Diagram
Package Diagram Diagram Activity Diagram Use Case Diagram Behavior Diagram State Machine Diagram Sequence Diagram Interaction Diagram
Communication Diagram Interaction Overview Diagram Timing Diagram
Gambar 2. 2 Jenis diagram resmi UML 2
Berikut ini adalah penjelasan diagram-diagram dari gambar 3.1 di atas: A. Class Diagram Diagram kelas (Class Diagram) juga merupakan salah satu diagram yang ada pada UML. Diagram kelas (class diagram) menggambarkan struktur aplikasi berorientasi objek dari segi pendefinisian kelas-kelas yang akan dibuat untuk membangun aplikasi. Kelas memiliki apa yang disebut aribut dan metode/operasi. Atribut merupakan variabel-variabel yang
36
dimiliki oleh suatu kelas. Operasi/metode adalah fungsi-fungsi yang dimiliki oleh suatu kelas. B. Component Diagram Component diagram merupakan diagram UML yang menampilkan komponen dalam sistem dan hubungan antara mereka. Component diagram adalah diagram yang digunakan untuk menggambarkan organisasi
dan
ketergantungan
komponen-komponen
software.
Component diagram berguna untuk memodelkan komponen objek. Pada component view, akan difokuskan pada organisasi fisik sistem. Pertama, diputuskan bagaimana kelas-kelas akan diorganisasikan menjadi kode pustaka. Kemudian akan dilihat bagaimana perbedaan antara berkas eksekusi, berkas Dynamic Link Library (DDL), dan berkas runtime lainnya dalam sistem. C. Composite Structure Diagram Composite structure diagram adalah diagram untuk menunjukkan dekomposisi secara hierarkis sebuah class ke sebuah struktur internal. Hal ini memungkinkan untuk memecah objek yang kompleks menjadi bagian-bagian yang kecil. D. Deployment Diagram Deployment diagram menunjukkan tata letak sebuah sistem secara fisik, menampakkan bagian-bagian software yang berjalan pada bagian-bagian hardware yang digunakan untuk mengimplementasikan sebuah sistem dan keterhubungan antara komponen-komponen hardware tersebut. Deployment diagram dapat digunakan pada bagian-bagian awal proses perancangan sistem untuk mendokumentasikan arsitektur fisik sebuah sistem. E. Object Diagram Object diagram merupakan sebuah gambaran tentang objek-objek dalam sebuah sistem pada satu titik waktu. Karena lebih menonjolkan perintahperintah daripada class, object diagram lebih sering disebut sebagai sebuah diagram perintah.
37
F. Package Diagram Package
diagram
adalah
sebuah
memungkinkan untuk mengambil
bentuk
pengelompokan
setiap bentuk di
yang
UML dan
mengelompokkan elemen-elemen dalam tingkatan unit yang lebih tinggi. Kegunaan package yang paling umum adalah untuk mengelompokkan class. G. Activity Diagram Activity diagram digunakan untuk mendokumentasikan alur kerja pada sebuah sistem, yang dimulai dari pandangan business level hingga ke operational level. Pada dasarnya, activity diagram merupakan variasi dari state machine diagram. Activity diagram mempunyai peran seperti halnya flowchart, akan tetapi perbedaannya dengan flowchart adalah activity diagram bisa mendukung perilaku paralel sedangkan flowchart tidak bisa. H. Use Case Diagram Use case diagram adalah salah satu diagram yang ada dalam UML (Unified Modeling Language). Use case diagram merupakan merupakan pemodelan untuk kelakuan (behavior) aplikasi perangkat lunak yang akan dibuat. Use case diagram mendeskripsikan interaksi antara satu atau lebih aktor dengan aplikasi yang akan dibuat. Secara kasar, use case diagram digunakan untuk mengetahui fungsi/proses apa saja yang ada di dalam sebuah aplikasi dan siapa saja yang berhak menggunakan fungsifungsi atau proses-proses itu. Ada dua hal utama pada use case diagram yaitu pendefinisian apa yang disebut aktor dan use case, berikut ini penjelasannya: a. Aktor merupakan orang, proses, atau aplikasi lain yang berinteraksi dengan aplikasi yang akan dibuat diluar aplikasi itu sendiri, jadi walaupun simbol dari aktor adalah gambar orang tapi aktor belum tentu merupakan orang. b. Use case merupakan fungsi-fungsi/proses-proses yang disediakan aplikasi sebagai unit-unit yang saling bertukar pesan/berinteraksi antar
38
unit/proses atau aktor. Syarat penamaan pada use case adalah nama didefinisikan sesimpel mungkin dan dapat dipahami. I. State Machine Diagram State machine diagram digunakan untuk menelusuri individu-individu objek melalui keseluruhan daur hidupnya, menspesifikasi semua urutan yang mungkin dari pesan-pesan yang akan diterima objek tersebut bersama-sama dengan tanggapan atas pesan-pesan tersebut. Diagram state menggambarkan transisi dan perubahan keadaan suatu objek dalam sistem sebagai akibat dari stimuli yang diterima. Pada umumnya diagram ini menggambarkan class tertentu. State diagram membantu analis, perancang dan pengembang untuk memahami perilaku objek dalam sistem. J. Sequence Diagram Sequence
diagram
adalah
diagram
mendokumentasikan komunikasi/interaksi
yang
digunakan
untuk
antarkelas. Diagram
ini
menunjukkan sejumlah objek dan message (pesan) yang diletakkan diantara objek-objek di dalam use case. Perlu diingat bahwa di dalam diagram ini, kelas-kelas dan aktor-aktor diletakkan di bagian atas diagram dengan urutan dari kiri ke kanan dengan garis lifeline yang diletakkan secara vertikal terhadap kelas dan aktor. K. Communication Diagram Communication
diagram
atau
collaboration
diagram
juga
menggambarkan interaksi antarobjek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message (pesan). Setiap message memiliki sequence number, di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama. L. Interaction Overview Diagram Interaction overview diagram adalah pencangkokan secara bersama antara activity diagram dengan sequence diagram. Interaction overview diagram dapat dianggap sebagai activity diagram di mana semua aktivitas diganti dengan sedikit sequence diagram, atau bisa juga
39
dianggap sebagai sequence diagram yang dirincikan dengan notasi activity diagram yang digunakan untuk menunjukkan aliran pengawasan. M. Timing Diagram Timing diagram adalah bentuk lain dari interaction diagram, di mana fokus utamanya lebih ke waktu. Timing diagram sangat berdaya guna dalam menunjukkan faktor pembatas waktu di antara perubahan state pada objek yang berbeda.
2.8
MVC (Model-View-Controller) Model-View-Controller (MVC) adalah pola desain atau arsitektur yang
digunakan dalam rekayasa perangkat lunak, di mana terjadi pemisahan yang jelas antara data (model), dengan user interface (view) (Widiyanto, 2010). MVC adalah metode untuk membuat aplikasi dengan memisahkan data (model) dari tampilan (view) dan bagaimana memprosesnya (controller) (Utpatadevi, Sudana, & Cahyawan, 2012). Jadi MVC merupakan metode dalam pemrograman yang memisahkan suatu program menjadi beberapa bagian, yaitu bagian model, bagian view, dan bagian controller. Biasanya bagian model diisi dengan fungsionalitas program tersebut, bagian view berisi tentang user interface dari program, dan bagian controller berisi tentang penanganan event dari program tersebut. Alasan utama mengapa setiap orang yang mencoba membuat user interface (antarmuka pengguna) dengan bahasa-bahasa pemrograman berorientasi objek, misalnya Java dengan Abstract Window Toolkits (AWT) dan Java Foundation Class (JFC), cukup menemui kesulitan berarti. Dalam hal ini, IDE (Integrated Development Environment) java terbaru misalnya NetBeans dan Eclipse, yang memuat plugin visual editor, bisa memuat interface yang lebih mudah dengan fitur drag and drop. Namun, hasil perancangan pada umumnya masih terasa sulit untuk dipelihara, untuk dilacak kesalahannya, dan sering tidak dapat digunakan ulang. Sementara itu, kita akan mendapatkan keuntungan ketika kita dapat memisahkan komponen-komponen antarmuka berbasis Graphical User Interface (GUI) dengan logika bisnisnya. Untuk itu kita gunakan model Model-View-
40
Controller (MVC), yang memisahkan komponen-komponen persentasi suatu aplikasi dengan komponen-komponen logika bisnisnya. Arsitektur MVC ini memungkinkan adanya perubahan dalam domain model tanpa harus mengubah kode untuk menampilkan domain model tersebut. Hal ini sangat bermanfaat ketika aplikasi mempunyai domain model dan view komponen sangat besar dan kompleks.
Gambar 2. 3 Model MVC (Model View Controller)
Beberapa alasan pokok mengapa model MVC menjadi sangat bermanfaat yaitu: a. penggunaan ulang komponen-komponen antarmuka pengguna b. kemampuan
untuk
mengembangkan
aplikasi
dengan
antarmuka
pengguna secara terpisah c. kemampuan untuk melakukan pewarisan dari berbagai bagian yang berbeda pada suatu hierarki kelas d. kemampuan untuk mendefinisikan kelas-kelas pengaturan tampilan yang menyediakan fitur-fitur umum secara terpisah dengan bagimana fiturfitur itu akan ditampilkan oleh aplikasi yang kita kembangkan
41
2.9
Pengujian (Testing) Pengujian (testing) adalah tindakan untuk memeriksa/membuktikan bahwa
kualitas software telah terpenuhi, dan pengimplementasian software telah benar sesuai dengan syarat/kebutuhan (O’Regan, 2011). Ada beberapa tipe pengujian (testing), yaitu pengujian unit (unit testing), pengujian integrasi (integration testing), pengujian sistem (system testing), pengujian daya guna (performance testing), dan pengujian penerimaan pengguna (user acceptance testing). Tujuan akhir dari pengujian (testing) adalah untuk memastikan bahwa sistem bekerja/berjalan sesuai dengan perencanaan, dan secara umum untuk memastikan agar dapat memenuhi kebutuhan pengguna (Davis & Yen, 1998). Lebih khusus, pengujian (testing) adalah proses mencoba meletakkan sistem dan beserta komponen pendukungnya, mengamati, dan memperbaiki kesalahan atau cacat yang timbul. Pengujian perangkat lunak (software testing) berperan dalam memastikan bahwa produk perangkat lunak telah berkualitas tinggi dan sesuai dengan kualitas yang diharapan oleh pelanggan (O’Regan, 2011).
2.9.1 Tujuan Pengujian Pengujian merupakan bagian yang bersifat integral dalam pengembangan perangkat lunak, dan lebih dari 50% waktu pengembangan dihabiskan untuk pengujian (Simarmata, 2010). Adapun tujuan dari pengujian adalah: a. Untuk meningkatkan kualitas Software berkualitas adalah software yang tidak memiliki cacat, dan sesuai dengan kebutuhan. Bug dapat menyebabkan kerugian yang besar, menghancurkan, dan menyebabkan masalah. Debugging sering dilakukan untuk
mengetahui
perancangan
yang
cacat
dari
pemrograman.
Menemukan masalah dan memperbaikinya adalah tujuan dari debugging di dalam tahapan pemrograman. b. Untuk verifikasi dan validasi Pengujian software juga bertujuan untuk memvalidasi dan memverifikasi software (perangkat lunak), yaitu apakah software yang dikembangkan telah memenuhi persyaratan bisnis dan teknis (sesuai dengan desain dan
42
pengembangan yang direncanakan), apakah sudah bekerja seperti yang diharapkan, dan dapat diimplementasikan dengan karakteristik yang sama. c. Untuk keandalan estimasi Pengujian dapat digunakan untuk memperoleh data statistik yang dapat digunakan untuk mengetahui kegagalan, atau estimasi keandalan perangkat lunak. Keandalan perangkat lunak merupakan hal yang penting karena memiliki hubungan dengan berbagai aspek dari perangkat lunak, termasuk struktur.
2.9.2 Jenis Pengujian 2.9.2.1 Pengujian Black Box Pengujian black box mencakup beberapa pengujian (Simarmata, 2010), yaitu: a. Pengujian fungsionalitas (functional testing) Pengujian fungsional dilakukan untuk menguji persyaratan fungsional, yaitu dilakukan dalam bentuk tertulis untuk memeriksa apakah aplikasi berjalan seperti yang diharapkan. Pengujian fungsional meliputi seberapa baik system melaksanakan fungsinya, termasuk perintah-perintah pengguna, manipulasi data, pencarian dan proses bisnis, pengguna layar, dan integrasi. b. Pengujian tegangan (stress testing) Pengujian tegangan ditujukan untuk menguji kualitas aplikasi dalam lingkungannya. Pengujiannya dilakukan dengan menjalankan aplikasi dengan menuntut untuk melakukan melebihi beban normal. Ini adalah pengujian yang cukup sulit, cukup komplek, dan memerlukan upaya bersama dari semua tim. c. Pengujian beban (load testing) Pengujian ini dilakukan dengan memberikan beban berat, seperti pada pengujian situs web, dengan tujuan untuk mengetahui apakah kinerja aplikasi akan mengalami penurunan atau tidak.
43
d. Pengujian khusus (ad-hoc testing) Pengujian ini dilakukan tanpa membuat rencana pengujian (test plan) atau kasus pengujian (test case). Pengujian ini dilakukan untuk membantu penguji mempelajari aplikasi sebelum melakukan pengujian dengan metode pengujian lain. Pengujian ini kadang dilakukan untuk membantu dalam mempelajari aplikasi jika dokumentasi sulit dimengerti. e. Pengujian penyelidikan (exploratory testing) Pengujian penyelidikan mirip dengan pengujian khusu dan dilakukan untuk mempelajari aplikasi. Pengujian ini merupakan pendekatan yang menyenangkan untuk pengujian. f. Pengujian usabilitas (usability testing) Pengujian ini disebut juga sebagai pengujian untuk keakraban pengguna (testing for user-friendliness). Pengujian ini dilakukan jika antarmuka pengguna dari aplikasi dianggap penting dan harus spesifik untuk jenis pengguna tertentu. Pengujian ini ditujukan untuk menghilangkan kesulitan pengguna dalam menggunakan aplikasi. g. “Pengujian asap” (smoke testing) Pengujian ini disebut juga pengujian kenormalan (sanity testing). Pengujian ini dilakukan untuk memeriksa apakah aplikasi telah siap untuk dilakukan pengujian yang lebih besar dan bekerja sampai tingkat yang diharapkan. h. Pengujian pemulihan (recovery testing) Pengujian pemulihan (recovery testing) pada dasarnya dilakukan untuk memeriksa seberapa cepat dan baiknya aplikasi bias dipulihkan terhadap semua jenis crash atau kegagalan hardware, masalah bencana, dan lainlain. Jenis atau taraf pemulihan ditetapkan dalam persyaratan spesifikasi. i. Pengujian volume (volume testing) Pengujian volume dilakukan terhadap efisiensi dari aplikasi. Jumlah data yang besar diproses melalui aplikasi (yang sedang diuji) untuk memeriksa keterbatasan ekstrem dari aplikasi. Pengujian volume ditujukan untuk memastikan batas-batas fisik dan logis untuk kapasitas
44
sistem, dan memastikan apakah batasan dapat diterima untuk memenuhi proyeksi kapasitas dari pengolahan bisnis organisasi. j. Pengujian domain (domain testing) Pengujian domain merupakan pengujian yang paling sering dijelaskan dalam teknik pengujian. Pengujian dilakukan dengan mengambil ruang pengujian dari variabel individu dan membaginya dalam subset (dalam beberapa cara) yang sama, kemudian menguji perwakilan dari masingmasing subset. k. Pengujian skenario (scenario testing) Pengujian skenario merupakan definisi dari serangkaian kasus uji atau skrip tes dan urutan di mana mereka dieksekusi. Pengujian skenario merupakan
pengujian
yang
realistis,
kredibel,
dan
memotivasi
stakeholder, tantangan untuk program dan mempermudah penguji untuk melakukan evaluasi. l. Pengujian regresi (regression testing) Pengujian regresi adalah gaya pengujian yang berfokus pada pengujian ulang (retesting) setelah ada perubahan. Pada pengujian regresi berorientasi risiko (risk-oriented regression testing), daerah yang sama yang sudah diuji, akan kita uji lagi dengan pengujian yang berbeda (semakin kompleks). m. Penerimaan pengguna (user acceptance) Pada jenis pengujian ini, perangkat lunak akan diserahkan kepada pengguna untuk mengetahui apakah perangkat lunak memenuhi harapan pengguna dan bekerja seperti yang diharapkan. n. Pengujian alfa (alpha testing) Pada jenis pengujian ini, pengguna
akan diundang ke pusat
pengembangan. Pengguna akan menggunakan aplikasi dan pengembang mencatat setiap masukan atau tindakan yang dilakukan oleh pengguna. o. Pengujian beta (beta testing) Pada jenis pengujian ini, perangkat lunak didistribusikan sebagai sebuah versi beta dengan pengguna yang menguji aplikasi di situs mereka. Pengecualian/cacat yang terjadi akan dilaporkan kepada pengembang.
45
2.9.2.2 Pengujian White Box Sedangkan pengujian white box mencakup beberapa pengujian (Simarmata, 2010), antara lain: a. Pengujian unit (unit testing) Pengujian unit bertujuan untuk memeriksa apakah modul tertentu atau kode unit bekerja dengan baik. Pengujian unit berada pada tingkat yang sangat dasar seperti ketika unit dikembangkan atau fungsi tertentu dibangun. Pengujian unit berkaitan dengan unit secara keseluruhan, hal ini akan menguji interaksi antara berbagai fungsi, tetapi membatasi pengujian dalam satu unit. Lingkup yang tepat dari unit ditinggalkan kepada interpretasi, pendukung kode pengujian, kadang-kadang disebut perancah (scaffolding), mungkin diperlukan untuk mendukung setiap pengujian.
Pengujian
ini
digerakkan
oleh
tim
arsitektur
dan
implementator. b. Analisis statis dan dinamis (static and dynamic analysis) Analisis statis dilibatkan melalui kode untuk mengetahui segala kemungkinan cacat dalam kode, sedangkan analisis dinamis akan melibatkan pelaksanaan kode dan penganalisisan hasilnya. c. Cakupan pernyataan (statement coverage) Pengujian pernyataan dilakukan dengan menjalankan minimal sekali untuk setiap pernyataan dalam aplikasi. Pengujian ini untuk memastikan bahwa setiap pernyataan tidak memiliki efek samping yang belum diprediksi. d. Cakupan cabang (branch coverage) Pengujian cakupan cabang ditujukan untuk membantu memvalidasi setiap percabangan, dan memastikan bahwa tidak ada cabang yang mengarah ke perilaku abnormal dari aplikasi. e. Pengujian mutasi (mutation testing) Pengujian ini dilakukan untuk menguji kode yang telah dimodifikasi setelah memperbaiki bug (cacat) tertentu. Hal ini juga membantu dalam menemukan mana kode dan strategi pengkodean yang dapat membantu dalam mengembangkan fungsi tersebut secara efektif.
46
2.10 Aplikasi Pendukung 2.10.1 Java Java merupakan sebuah bahasa pemrograman berorientasi objek yang dapat berjalan pada platform yang berbeda, baik di Windows, Linux, serta sistem informasi lainnya (Supriyanto, 2010). Jadi sebuah source code aplikasi yang sama dapat di-compile dan dijalankan di berbagai platform. Hal ini dapat mempermudah pendistribusiannya.
2.10.1.1 Karakteristik Java Java memiliki karakteristik yang berlebih dibanding bahasa pemrograman lain (Utomo, 2009), yaitu: a. Sederhana Bahasa pemrograman Java menggunakan sintaks mirip dengan C++ namun
sintaks
pada
Java
telah
banyak
diperbaiki
terutama
menghilangkan penggunaan pointer yang rumit dan multiple inheritance. Java juga menggunakan automatic memory allocation dan memory garbage collection. b. Berorientasi objek (object oriented) Java mengunakan pemrograman berorientasi objek yang membuat program dapat dibuat secara modular dan dapat dipergunakan kembali. Pemrograman berorientasi objek memodelkan dunia nyata ke dalam objek dan melakukan interaksi antar objek-objek tersebut. c. Dapat didistribusi dengan mudah Java dibuat untuk membuat aplikasi terdistribusi secara mudah dengan adanya libraries networking yang terintegrasi pada Java. d. Interpreter Program Java dijalankan menggunakan interpreter yaitu Java Virtual Machine (JVM). Hal ini menyebabkan source code Java yang telah dikompilasi menjadi Java bytecodes dapat dijalankan pada platform yang berbeda-beda.
47
e. Robust Java mempuyai reliabilitas yang tinggi. Compiler pada Java mempunyai kemampuan mendeteksi error secara lebih teliti dibandingkan bahasa pemrograman lain. Java mempunyai runtime-Exception handling untuk membantu mengatasi error pada pemrograman. f. Aman Sebagai bahasa pemrograman untuk aplikasi internet dan terdistribusi, Java memiliki beberapa mekanisme keamanan untuk menjaga aplikasi tidak digunakan untuk merusak sistem komputer yang menjalankan aplikasi tersebut. g. Arsitektur netral Program Java merupakan platform independent. Program cukup mempunyai satu buah versi yang dapat dijalankan pada platform yang berbeda dengan Java Virtual Machine (JVM). h. Portabel Source code maupun program Java dapat dengan mudah dibawa ke platform yang berbeda-beda tanpa harus dikompilasi ulang. i. Performance Performance pada Java sering dikatakan kurang tinggi. Namun performance Java dapat ditingkatkan menggunakan kompilasi Java lain seperti buatan Inprise, Microsoft ataupun Symantec yang menggunakan Just In Time Compilers (JIT). j. Multithreaded Java mempunyai kemampuan untuk membuat suatu program yang dapat melakukan beberapa pekerjaan secara sekaligus dan simultan. k. Dinamis Java didesain untuk dapat dijalankan pada lingkungan yang dinamis. Perubahan pada suatu class dengan menambahkan properties ataupun method dapat dilakukan tanpa menggangu program yang menggunakan class tersebut.
48
2.10.1.2 Sistem Kerja Java Java merupakan bahasa pemrograman yang terdiri dari compiler dan interpreter (Utomo, 2009), compiler menerjemahkan kode sumber program java menjadi bytecode. Untuk menjalankan bytecode hasil compiler diperlukan java interpreter, sehingga menjadikan java dapat dijalankan di berbagai platform. Java interpreter dapat dijalankan langsung dari command prompt; atau applet viewer atau web browser (untuk applet). Kelemahan adalah kecepatan eksekusi program akan lebih lambat dari program biasa karena program bytecode harus diterjemahkan terlebih dahulu oleh interpreter, kemudian dijalankan pada hardware. Gambar di bawah ini menjelaskan aliran proses kompilasi dan eksekusi sebuah program Java :
Gambar 2. 4 Proses dari sebuah Program Java
Langkah pertama dalam membuat sebuah program berbasis Java adalah menuliskan kode program pada text editor. Contoh text editor yang dapat digunakan antara lain, notepad, vi, emacs dan lain sebagainya. Kode program yang dibuat kemudian disimpan dalam sebuah berkas berekstensi .java. Setelah membuat dan menyimpan kode program, kompilasi file yang berisi kode program tersebut dengan menggunakan Java Compiler. Hasil dari kompilasi berupa berkas bytecode dengan ekstensi .class. Berkas yang mengandung bytecode tersebut kemudian akan dikonversikan oleh Java Interpreter menjadi bahasa mesin sesuai dengan jenis dan platform yang digunakan.
49
Tabel 2. 1 Tahapan pembuatan program java Proses Menulis kode program Kompilasi program Java Menjalankan program Java
Tool Hasil Text editor Berkas berekstensi .java Compiler Berkas berekstensi .class (Java Bytecodes) Interpreter Program Output
Program java bersifat cross-platform digambarkan pada gambar 2.4, sebuah source code java dapat di-compile dan dijalankan pada berberapa platform, tanpa mengubah kode program. Hal ini dapat mengefisienkan waktu pengembangan jika akan diimplementasikan pada beberapa platform.
Gambar 2. 5 Java Cross-platform atau Multi-platform
2.10.1.3 Teknologi Java Teknologi
java
merupakan
sebuah
bahasa
pemrograman
yang
multiplatform. Bahasa pemrograman java merupakan bahasa tingkat tinggi yang memiliki berbagai karakteristik seperti yang telah dijelaskan sebelumnya. Platform adalah lingkungan perangkat keras atau lunak di mana program berjalan. Kita sudah mengenal beberapa platform yang paling populer seperti Microsoft Windows, Linux, Solaris OS, dan Mac OS. Kebanyakan platform dapat
50
digambarkan sebagai kombinasi dari sistem operasi dan perangkat keras yang mendasarinya. Platform Java berbeda dari platform lainnya, karena hanya merupakan platform perangkat lunak yang berjalan di atas platform hardware lainnya. Java platform terdiri dari dua komponen, yaitu Java Virtual Machine (JVM) dan Aplication Programming Interface (API). Secara garis besar teknologi Java terbagai menjadi beberapa bagian (Utomo, 2009), yaitu seperti di bawah ini: a. J2SE (2 Platform Standard Edition) Teknologi Java ini dirancang untuk membuat aplikasi yang berjalan pada PC dan workstation yang berada pada platform Windows, Linux, Macintos. J2SE terbagi menjadi dua bagian besar yaitu J2SE Core dan J2SE Desktop. J2SE Core digunakan untuk teknologi security, debugging, database dan sebagainya. Sedangkan teknologi J2SE Desktop meliputi beberapa teknologi yaitu JRE (Java Runtime Environment), JFC (Java Foundation Classes), Java Sound API dan sebagainya. b. J2EE (2 Platform Enterprise Edition) Teknologi Java ini digunakan untuk pengembangan aplikasi-aplikasi enterprise, meliputi beberapa teknologi yaitu JSP (Java Server Pages), Java Servlet, CORBA (untuk aplikasi terdistribusi) dan sebagainya. c. J2ME (Java 2 Platform Micro Edition) Teknologi Java ini digunakan untuk pengembangan sistem mikro dan sistem embedded seperti handphone, PDA dan lain sebagainya. Meliputi dua bagian besar yaitu CLDC (MIDP, BlueTooth dan lainnya) dan CDC Technology (JDBC/teknologi database dan RMI). d. Java Web Services Merupakan aplikasi web berbasis enterprise dengan standar XML dan protokol tertentu untuk bertukar data dengan klien. Teknologi ini meliputi beberapa API yang dirancang untuk bekerja dengan XML seperti Java API for XML Based RPC (JAX-RPC), Java API for XML Based Messaging (JAXM), Java API for XML Processing (JAXP) dan Java API for XML Binding (JAXB).
51
2.10.2 NetBeans Editor NetBeans cukup luar biasa untuk membuat aplikasi java, karena didukung fasilitas drag and drop komponen, yaitu dukungan rapid application development (pemrograman berbasis visual) (Huda & Komputer, 2009). NetBeans IDE
(Integrated
Development
Environment)
adalah
sebuah
lingkungan
pengembangan terintegrasi yang tersedia untuk Windows, Mac, Linux, dan Solaris. NetBeans adalah salah satu aplikasi IDE yang digunakan programmer untuk menulis, meng-compile, mencari kesalahan, dan menyebarkan program. Proyek NetBeans terdiri dari open-source IDE dan platform aplikasi, yang memungkinkan pengembang untuk secara cepat membuat web, enterprise, desktop, dan aplikasi mobile menggunakan platform Java, serta JavaFX, PHP, JavaScript dan Ajax, Ruby dan Ruby on Rails, Groovy dan Grails, dan C/C++. NetBeans menyajikan alat pemrograman GUI (Graphical User Interface) dan berbagai wizard yang sangat memudahkan dalam membangun program java (Wijono, Suharto, & Wijono, 2007). NetBeans ditulis dalam bahasa java namun dapat juga mendukung bahasa pemrogramman lain. Program ini bersifat kode terbuka (open source) dan bebas (free) untuk penggunaan komersial dan nonkomersial. Kode sumber tersedia untuk guna ulang dengan lisensi Common Development and Distribution License (CDDL). Proyek NetBeans didukung oleh komunitas pengembang yang ekstensif dan menawarkan dokumentasi dan sumber daya pelatihan serta beragam pilihan plugin dari pihak ketiga.
2.10.3 MySQL MySQL adalah sebuah perangkat lunak sistem manajemen basis data SQL atau DBMS yang multi-thread dan multi-user. MySQL adalah Relation Database Management System (RDBMS) yang didistribusikan secara gratis di bawah lisensi General Public License (GPL), sehingga setiap orang bebas untuk menggunakan MySQL (Supriyanto, 2010). MySQL (My Structured Query Language) merupakan sebuah program pembuat database yang bersifat open source, artinya semua orang dapat menggunakan dan dapat dijalankan pada semua platform baik windows maupun
52
LINUX/UNIX. Suatu database relationship menyimpan data dalam tabel yang terpisah. Tabel-tabel tersebut terhubungkan oleh suatu relasi terdefinisi yang memungkinkan user memperoleh kombinasi data dari beberapa tabel dalam suatu permintaan. MySQL sebenarnya merupakan Database Management System (DBMS) yang dikembangkan dari bahasa SQL (Structured Query Language) (Prasetyo, 2004). SQL adalah bahasa terstruktur yang digunakan untuk query, meng-update, dan memanipulasi database (Alam, 2005). SQL adalah sebuah konsep pengoperasian database, terutama untuk pemilihan atau seleksi dan pemasukan data, yang memungkinkan pengoperasian data dikerjakan dengan mudah secara otomatis. Keandalan suatu sistem database (DBMS) dapat diketahui dari cara kerja optimizer-nya dalam melakukan proses perintah-perintah SQL, yang dibuat oleh user maupun program-program aplikasinya. Sebagai
database
server,
MySQL
dapat
dikatakan lebih
unggul
dibandingkan database server lainnya dalam query data. Hal ini terbukti untuk query yang dilakukan oleh single user, kecepatan query MySQL bisa sepuluh kali lebih cepat dari PostgreSQL dan lima kali lebih cepat dibandingkan Interbase Sebenarnya MySQL adalah produk yang berjalan pada platform Linux. Karena sifatnya yang open source, dia dapat dijalankan pada semua platform baik Windows maupun Linux. Selain itu, MySQL juga merupakan program pengakses database yang bersifat jaringan sehingga dapat digunakan untuk aplikasi multi user (banyak pengguna). Saat ini database MySQL telah digunakan hampir oleh semua programmer database. Agar aplikasi java yang dibuat dapat mengakses DBMS MySQL, maka diperlukan driver untuk menjembataninya (Huda & Komputer, 2009).
2.10.3.1 Kelebihan MySQL Kelebihan lain dari MySQL adalah menggunakan bahasa query standar yang dimiliki SQL (Structured Query Language). SQL adalah suatu bahasa permintaan yang terstruktur yang telah distandarkan oleh semua program pengakses database seperti Oracle, Posgres SQL, SQL Server, dan lain-lain.
53
Keuntungan-keuntungan yang dapat diperoleh jika menggunakan MySQL adalah sebagai berikut: a. Bebas untuk di-download dan didistribusikan b. Source code-nya bebas untuk dimodifikasi c. Cepat dan sederhana d. Stabil dan tangguh e. Fleksibel dengan berbagai bahasa pemrograman f. Mempunyai keamanan yang baik g. Mendapatkan dukungan dari banyak komunitas h. Kemudahan dalam melakukan manajemen basis data i. Mendukung banyak transaksi j. Perkembangan software yang cukup begitu cepat k. Bagus untuk basis data berbasis web dan bisnis kecil
Selain itu MySQL juga memiliki beberapa keistimewaan yang antara lain: a. Portability MySQL dapat berjalan stabil pada berbagai sistem operasi seperti Windows, Linux, FreeBSD, Mac OS X Server, Solaris, Amiga dan lainlain. b. Open source MySQL didistribusikan secara open source di bawah lisensi GPL, sehingga dapat digunakan secara gratis. c. Multiuser MySQL dapat digunakan oleh beberapa user dalam waktu yang bersamaan tanpa mengalami masalah atau konflik. d. Performance tuning MySQL memiliki kecepatan yang menakjubkan dalam menangani query sederhana, dengan kata lain dapat memproses lebih banyak SQL per satuan waktu.
54
e. Jenis kolom MySQL
memiliki
tipe
kolom
yang
sangat
kompleks,
seperti
signed/unsigned integer, float, double, char, text, date, timestamp dan lain-lain. f. Perintah dan fungsi MySQL memiliki operator dan fungsi secara penuh yang mendukung perintah SELECT dan WHERE dalam perintah (query). g. Keamanan MySQL memiliki beberapa lapisan keamanan seperti level subnetmask, nama host, dan izin akses user dengan sistem perizinan yang mendetil serta password terenkripsi. h. Skalabilitas dan pembatasan MySQL mampu menangani basis data dalam skala besar, dengan jumlah rekaman (records) lebih dari 50 juta dan 60 ribu tabel serta 5 milyar baris. Selain itu batas indeks yang dapat ditampung mencapai 32 indeks pada tiap tabelnya. i. Konektivitas MySQL dapat melakukan koneksi dengan client menggunakan protokol TCP/IP, Unix soket (UNIX), atau Named Pipes (NT). j. Lokalisasi MySQL dapat mendeteksi pesan kesalahan pada client dengan menggunakan lebih dari dua puluh bahasa. k. Antarmuka MySQL memiliki antarmuka terhadap berbagai aplikasi dan bahasa pemrograman
dengan
menggunakan
fungsi
API
(Application
Programming Interface). l. Klien dan peralatan MySQL dilengkapi dengan berbagai peralatan (tool) yang dapat digunakan untuk administrasi basis data, dan pada setiap peralatan yang ada disertakan petunjuk online.
55
m. Struktur tabel MySQL memiliki struktur tabel yang lebih fleksibel dalam menangani ALTER TABLE, dibandingkan basis data lainnya semacam PostgreSQL ataupun Oracle.
2.10.3.2 Kekurangan MySQL Kekurangan-kekurangan dari DBMS MySQL adalah: a. Tidak cocok untuk menangani data dengan jumlah yang besar, baik untuk menyimpan data maupun untuk memproses data. b. Memiliki keterbatasan kemampuan kinerja pada server ketika data yang disimpan telah melebihi batas maksimal kemampuan daya tampung server karena tidak menerapkan konsep technology cluster server.
BAB III ANALISA DAN PERANCANGAN
3.1
Analisa Analisa atau analisis adalah kajian yang dilaksanakan terhadap sebuah
permasalahan guna meneliti struktur masalah secara mendalam dengan cara memecah-mecah masalah tersebut menjadi bagian-bagian kecil yang lebih mudah dipelajari, kemudian mempelajarinya dan mengambil kesimpulan.
3.1.1 Analisa Sistem Saat Ini Pendaftaran calon siswa dilakukan pada tiap awal tahun ajaran baru. Calon siswa yang ingin mendaftar mendatangi tempat pendaftaran, kemudian mengambil formulir pendaftaran. Formulir pendaftaran yang telah diambil diisi selengkap mungkin. Formulir yang telah diisi dan persyaratan lainnya diserahkan kembali ke bagian pendaftaran. Setelah pendaftaran ditutup, selanjutnya panitia penerimaan siswa baru melakukan seleksi terhadap calon siswa yang telah mendaftar dengan mengikuti ketentuan yang telah ditetapkan. Cara melakukan seleksi calon siswa yaitu dengan mengurutkan calon siswa berdasarkan nilai ujian nasional, kemudian diambil yang tertinggi sesuai daya tampung kelas yang tersedia. Hasil dari seleksi calon siswa kemudian diumumkan di papan pengumuman. Calon siswa yang dinyatakan diterima kemudian melakukan pendaftaran ulang. Pembayaran dilakukan di ruang TU (tata usaha) sesuai jadwal yang telah ditentukan. Ada beberapa jenis pembayaran yang harus dilakukan oleh siswa, yaitu uang gedung, SPP (Sumbangan Pengembangan Pendidikan), biaya ujian tengah semester, biaya ujian akhir semester, dan lain-lain. Setiap akhir semester dibuat laporan nilai hasil belajar siswa berupa raport untuk orang tua atau wali murid siswa. Nilai dikelola oleh guru masing-masing mata pelajaran dan diserahkan ke wali kelas untuk ditulis ke dalam raport di akhir semester. Nilai dihitung berdasarkan nilai tugas, nilai ulangan, nilai ujian tengah semester, dan nilai ujian akhir semester.
56
57
Proses (aktivitas) dari sistem yang berjalan saat ini dapat digambarkan dalam diagram activity (aktivitas) sebagai berikut: act Business Process Model
Start
Guru mengolah dan membuat rekap nilai sisw a
Calon sisw a melakukan pendaftaran
Calon sisw a mengisi form dan melengkapi persyaratan
Calon sisw a menyerahkan form pendaftaran dan melengkapi persyaratan
Staf administrasi mengecek formulir dan persyaratan
Data sisw a di-input dan diolah menggunakan Ms. Excel untuk menetapkan calon sisw a yang diterima
Sisw a melakukan pembayaran
Membuat j adw al belaj ar/mengaj ar
Guru menetapkan kelulusan sisw a
Data pembayaran dicatat dalam buku j urnal pembayaran Meng-input dan mengolahnya menggunakan Ms. Excel Data pembayaran direkap dan dimasukkan ke dalam buku besar
Data pembayaran di-input dan diolah menggunakan Ms. Excel untuk membuat laporan
Guru menulis ke dalam raport sisw a
Mencetak dan mengumumkan
Raport diberikan kepada orang tua atau w ali sisw a Calon sisw a yang diterima diumumkan
Selesai
Gambar 3. 1 Diagram activity (aktivitas) sistem saat ini
3.1.2 Analisa Data/Dokumen Data-data yang dicatat dalam form pendaftaran adalah biodata calon siswa, nilai ujian nasional, peminatan/jurusan yang dipilih, dan lain-lain. Biodata calon siswa antara lain no. pendaftaran, nama lengkap, alamat, tempat dan tanggal lahir, asal sekolah, tahun lulus, dan lain-lain.
58
Sedangkan data-data yang dicatat ketika melakukan pembayaran antara lain jenis pembayaran, besar pembayaran, dan tanggal pembayaran. Untuk aplikasi yang akan dibuat, akan ditambahkan petugas/staf TU (Tata Usaha) yang menerima pembayaran. Pada pencatatan nilai, data-data yang dicatat adalah rincian dari penilaian siswa, yaitu nilai tugas, nilai ulangan, nilai ujian tengah semester, dan nilai ujian akhir semester.
3.1.3 Analisa Kebutuhan Analisa kebutuhan merupakan langkah awal untuk menentukan gambaran perangkat lunak yang akan dihasilkan ketika pengembang melaksanakan sebuah proyek pembuatan perangkat lunak. Analisa kebutuhan adalah sebuah proses untuk mendapatkan informasi, model, spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna. Pada pengembangan aplikasi administrasi sekolah ini, spesifikasi dari perangkat lunak yang akan dibuat adalah: a. Aplikasi dikembangkan menggunakan arsitektur client-server agar dapat digunakan oleh beberapa pengguna secara bersamaan sehingga dapat mempercepat pekerjaan. b. Aplikasi dikembangkan menggunakan arsitektur MVC (Model View Controller) agar di masa depan mudah untuk dikembangkan kembali jika ada kebutuhan tambahan. c. Aplikasi yang dikembangkan mencakup administrasi pendaftaran siswa, seleksi/penerimaan
siswa,
pembayaran,
administrasi
nilai,
dan
pengaturan hak akses pengguna.
3.2
Perancangan Setelah dilakukan analisa
terhadap kebutuhan
dan
data/dokumen,
selanjutnya dibuat perancangan basis data dan perancangan aplikasi.
59
3.2.1 Perancangan Database (Basis Data) Perancangan basis data dilakukan dengan membuat beberapa diagram, yaitu ERD, transformasi ERD ke LRS, dan diagram LRS.
3.2.1.1 ERD (Entity Relationship Diagram) Berdasarkan analisa kebutuhan yang telah dilakukan, maka dibuat ERD seperti berikut ini:
60
* kd_jpers Nm_jpers Stn_pers Jmlh_pers
* kd_cs * kd_jpers M
Memiliki
* kd _jpem nm _jpem bsr_pem Bts_pem
Jenis Persyaratan
* no_pem * kd_jpem
M
Jenis Pembayaran
terdiri
M Calon Siswa * no_pem nis wkt_pem no_ peg
M * no_peg nm_peg almt_peg tmp_lhr_peg tgl_lhr_peg Pass_peg
* kd_cs nm_cs almt_cs tmp_lhr_cs tgl_lhr_cs asl_sklh_cs thn_lls_cs nli_ujn_nsnl_cs
Staf Administrasi
Menerima
1
M
M Pembayaran M
* nis nm_sis almt_sis tmp_lhr_sis tgl_lhr_sis asl_sklh_sis thn_lls_sis nli_ujn_nsnl_sisl thn_msk_sis
1
Siswa M
Melakukan
M
Memilih
1
M 1
Jurusan
M
Untuk
* nig nm_gru almt_gru tmp_lhr_gru tgl_lhr_gru pass_gru
Mendapat
Menempati
M 1
Mengajar
M
Jadwal M
Jam
Sesuai 1
* kd_jm ktrngn mlai slsai
* kd_kls nm_kls dy_tmpng
Kelas 1
* kd_jrsn Nm_jrsn
Guru
* nis * kd_mtpel tgs ulngn uts uas
Menempati
* nis * kd_kls
* kd_klmpk Nm_klmpk
M
Untuk 1
* kd_jdwl hri kd_jm kd_matpel nig
Kelompok Mata Pelajaran
M
Mata Pelajaran * kd_matpel nm_matpel kd_klmpk nli_kkm
M
Termasuk 1
Gambar 3. 2 ERD basis data administrasi sekolah
61
3.2.1.2 ERD ke LRS Hasil perancangan basis data berupa ERD (Entity Relationship Diagram) kemudian ditransformasi ke bentuk LRS (Logical Record Structure) sebagai berikut: * kd_jpers Nm_jpers Stn_pers Jmlh_pers
* kd_cs * kd_jpers M
Memiliki
* kd _jpem nm _jpem bsr_pem Bts_pem
Jenis Persyaratan
Jenis Pembayaran
* no_pem * kd_jpem
M
terdiri
M Calon Siswa * no_pem nis wkt_pem no_ peg
M * no_peg nm_peg almt_peg Staf Administrasi tmp_lhr_peg tgl_lhr_peg Pass_peg
* kd_cs nm_cs almt_cs tmp_lhr_cs tgl_lhr_cs asl_sklh_cs thn_lls_cs nli_ujn_nsnl_cs
* nis nm_sis almt_sis tmp_lhr_sis tgl_lhr_sis asl_sklh_sis thn_lls_sis nli_ujn_nsnl_sisl thn_msk_sis
Menerima
1
M
M Pembayaran M
1
Siswa M
Melakukan
M
Memilih * nis * kd_kls
1
M
Jurusan
1
M
Untuk
* nis * kd_mtpel tgs ulngn uts uas
Menempati
* kd_kls nm_kls dy_tmpng
Kelas
Mendapat
1
* kd_jrsn Nm_jrsn
Menempati
M M
Mengajar * nig nm_gru almt_gru tmp_lhr_gru tgl_lhr_gru pass_gru
Jadwal M
Sesuai
1
M
Untuk 1
* kd_jdwl hri kd_jm kd_matpel nig
M
Mata Pelajaran M
* kd_matpel nm_matpel kd_klmpk nli_kkm
Guru
Jam 1 * kd_jm ktrngn mlai slsai
Termasuk
* kd_klmpk Nm_klmpkl
Kelompok Mata Pelajaran
1
Gambar 3. 3 ERD ke LRS basis data administrasi sekolah
62
3.2.1.3 LRS (Logical Record Structure) Setelah proses transformasi dari ERD ke LRS maka diperoleh diagram relasi seperti gambar berikut ini: Jenis Persyaratan
Persyaratan * kd_cs * kd_jpers
M
* kd_jpers
Jenis Pembayaran
* kd_jpers Nm_jpers Stn_pers Jmlh_pers
1
stts
* kd_jpem * nm_jpem bsr_pem bts_pem
M
M * kd_jpem 1
Pembayaran
* kd_cs * no_peg M
1
Calon Siswa
1
* kd_cs nm_cs almt_cs tmp_lhr_cs tgl_lhr_cs asl_sklh_cs thn_lls_cs nli_ujn_nsnl_cs * kd_jrsn
Staf Administrasi
* no_pem * nis wkt_pem * no_peg
* no_pem
Detil Pembayaran
1
* no_pem * kd_jpem
M
M * nis 1
* no_peg nm_peg almt_peg tmp_lhr_peg tgl_lhr_peg Pass_peg
Siswa Kelas Siswa
* kd_kls
* kd_jrsn
1
1
Kelas
Jurusan *kd_jrsn
1
M
Jam * kd_jm ktrngn mlai slsai
M
1 * kd_jm
M
1
* nis M
Nilai
1 * kd_kls
* nis * kd_mtpel tgs ulngn uts uas
Jadwal * kd_jdwl * kd_kls hri * kd_jm * kd_matpel * nig
* nis nm_sis almt_sis tmp_lhr_sis tgl_lhr_sis asl_sklh_sis thn_lls_sis nli_ujn_nsnl_sisl thn_msk_sis 1
* kd_kls * kd_jrsn nm_kls dy_tmpng
M
Guru * nig nm_gru almt_gru tmp_lhr_gru tgl_lhr_gru pass_gru
* nis
M
M
* kd_jrsn Nm_jrsn
M
1 * nis * kd_kls
M * kd_matpel M
1
* kd_matpel
* nig
1 Mata Pelajaran Kelompok Mata Pelajaran 1 * kd_klmpk Nm_klmpk_matpel
* kd_klmpk M
Gambar 3. 4 LRS basis data administrasi sekolah
* kd_matpel nm_matpel nli_kkm * kd_klmpk
63
3.2.1.4 Normalisasi Normalisasi diperlukan jika tabel-tabel yang dibuat belum normal. Karena tabel-tabel yang dihasilkan dari transformasi ERD pada gambar 3.3 telah memenuhi syarat normal ke-3 (3NF), maka tabel-tabel tersebut tidak perlu dinormalisasi lagi.
3.2.1.5 Spesifikasi Basis Data Spesifikasi basis data ditampilkan pada tabel-tabel berikut ini:
Tabel 3. 1 Tabel jenis persyaratan No
Nama Field
Tipe Field
Ukuran
1
kd_jpers
Varchar
2
2
nm_jpers
Varchar
30
3
stn_pers
Varchar
10
4
jmlh_pers
Int
Indeks Primary
Tabel 3. 2 Tabel jenis pembayaran No
Nama Field
Tipe Field
Ukuran
Indeks Primary
1
kd_jpem
Varchar
5
2
nm_jpem
Varchar
30
3
bsr_pem
Int
4
bts_pem
Date
Tabel 3. 3 Tabel persyaratan No
Nama Field
Tipe Field
Ukuran
Indeks
1
kd_cs
Varchar
9
Primary
2
kd-jpers
Varchar
2
Primary
64
Tabel 3. 4 Tabel pembayaran No
Nama Field
Tipe Field
Ukuran
1
no_pem
Varchar
12
2
nis
Varchar
9
3
wkt_pem
Datetime
4
no_peg
Varchar
Indeks Primary
9
Tabel 3. 5 Tabel detil pembayaran No
Nama Field
Tipe
Ukuran
Indeks
Field 1
no_pem
Varchar
12
Primary
3
kd_jpem
Varchar
5
Primary
Tabel 3. 6 Tabel calon siswa No
Nama Field
Tipe Field
Ukuran
1
kd_cs
Varchar
9
2
nm_cs
Varchar
30
3
almt_cs
Varchar
100
4
tmp_lhr_cs
Varchar
40
5
tgl_lhr_cs
Date
6
asl_sklh_cs
Varchar
7
thn_lls_cs
Smallint
8
nli_ujn_nsnl_cs
Double
60
Indeks Primary
65
Tabel 3. 7 Tabel siswa No
Nama Field
Tipe Field
Ukuran
1
nis
Varchar
9
2
nm_sis
Varchar
30
3
almt_sis
Varchar
100
4
tmp_lhr_sis
Varchar
40
5
tgl_lhr_sis
Date
6
asl_sklh_sis
Varchar
7
thn_lls_sis
Smallint
8
nli_ujn_nsnl_sis
Double
9
thn_msk
Smallint
Indeks Primary
60
Tabel 3. 8 Tabel staf administrasi No
Nama Field
Tipe Field
Ukuran
1
no_peg
Varchar
9
2
nm_peg
Varchar
30
3
almt_peg
Varchar
120
4
tmp_lhr_peg
Varchar
40
5
tgl_lhr_peg
Date
6
pass_peg
Varchar
Indeks Primary
32
Tabel 3. 9 Tabel guru No
Nama Field
Tipe Field
Ukuran
1
nig
Varchar
9
2
nm_gru
Varchar
30
3
almt_gru
Varchar
120
4
tmpt_lhr_gru
Varchar
40
5
tgl_lhr_gru
Date
6
pass_gru
Varchar
32
Indeks Primary
66
Tabel 3. 10 Tabel jurusan No
Nama Field
Tipe Field
Ukuran
1
kd_jrsn
Varchar
2
2
nm_jrsn
Varchar
30
Indeks Primary
Tabel 3. 11 Tabel kelas No
Nama Field
Tipe Field
Ukuran
1
kd_kls
Varchar
9
2
nm_kls
Varchar
15
3
kd_jrsn
Varchar
2
4
dy_tmpng
Tinyint
Indeks Primary
Tabel 3. 12 Tabel kelas siswa No
Nama Field
Tipe Field
Ukuran
Indeks
1
nig
Varchar
9
Primary
2
kd_kls
Varchar
9
Primary
Tabel 3. 13 Tabel kelompok mata pelajaran No
Nama Field
Tipe Field
Ukuran
1
kd_klmpk_matpel
Varchar
1
2
nm_klmpk_matpel
Varchar
25
Indeks Primary
67
Tabel 3. 14 Tabel mata pelajaran No
Nama Field
Tipe Field
Ukuran
1
kd_matpel
Varchar
5
2
nm_matpel
Varchar
25
3
kd_klmpk_matpel
Varchar
1
4
nli_kkm
Double
Indeks Primary
Tabel 3. 15 Tabel jadwal No
Nama Field
Tipe Field
Ukuran
1
kd_jdwl
Varchar
5
2
kd_kls
Varchar
9
3
hri
Tinyint
4
kd_jm
Varchar
2
5
kd_matpel
Varchar
5
6
nig
Varchar
9
Indeks Primary
Tabel 3. 16 Tabel jam No
Nama Field
Tipe Field
Ukuran
1
kd_jm
Varchar
2
2
ktrngn
Varchar
15
3
mlai
Time
4
slsai
Time
Indeks Primary
68
Tabel 3. 17 Tabel nilai No
Nama Field
Tipe Field
Ukuran
Indeks
1
kd_matpel_nli
Varchar
5
Primary
2
nis
Varchar
9
Primary
3
tgs
Double
4
ulngn
Double
5
uts
Double
6
uas
Double
3.2.2 Perancangan Aplikasi 3.2.2.1 Use Case Diagram Aplikasi administrasi yang akan dibuat dirancang menggunakan use case diagram seperti pada gambar 3.4. Use diagram yang dibuat menggunakan package diagram karena jumlah use case-nya terlalu banyak. Jika tidak menggunakan package diagram, relasi (hubungan) antara use case dengan actor maupun antara use case dengan use case lain akan banyak yang bersilangan, hal ini akan sulit dibaca/dipelajari. Pada gambar (diagram) selanjutnya akan digambarkan detil masing-masing package.
69
Gambar 3. 5 Use case diagram aplikasi administrasi sekolah
70
uc Akses Aplikasi
Login
Staf
Guru (from Use Case Model)
(from Use Case Model) Logout
Gambar 3. 6 Paket use case diagram akses aplikasi
uc Master Data
Mengelola Jenis Pembayaran
Mengelola Jenis Persyaratan
Mengelola Data Staf Administrasi
Mengelola Data Sisw a
Mengelola Data Guru
Mengelola Data Jam
Staf (from Use Case Model)
Mengelola Data Jurusan
Mengelola Data Kelas Sisw a
Mengelola Data Kelompok Mata Pelaj aran
Mengelola Data Kelas
Mengelola Data Mata Pelaj aran
Gambar 3. 7 Paket use case diagram master data
71
uc Transaksi
Mengelola Data Pendaftaran
Memproses Penerimaan Sisw a Staf (from Use Case Model) Mengelola Data Pembayaran
Mengelola Jadw al
Guru (from Use Case Model) Mengelola Data Nilai
Gambar 3. 8 Paket use case diagram transaksi
uc Laporan
Mencetak Laporan Penerimaan Sisw a
Mencetak Laporan Pembayaran
Staf (from Use Case Model)
Mencetak Nilai
Guru Mencetak Jadw al
(from Use Case Model)
Gambar 3. 9 Paket use case diagram laporan
72
3.2.2.2 Sequence Diagram Setelah dibuat use case diagram, selanjutnya masing-masing use case dibuatkan sequence diagram-nya sebagai berikut: A. Sequence diagram login sd Interaction
Staf
Guru
FormLogin
LoginController
Staf
Guru
inputUserId()
inputPassword()
klikLoginButton()
inputNig()
inputPassword()
klikLoginButton()
prosesLogin()
baca(userId, password) :boolean
baca(nig, password) :boolean
(from Use Case Model)
(from Use Case Model)
Gambar 3. 10 Sequence diagram login
B. Sequence diagram logout sd Interaction
Staf
Guru
FormUtama
LogoutController
klikLogoutButton()
klikLogoutButton()
prosesLogout()
(from Use Case Model)
(from Use Case Model)
Gambar 3. 11 Sequence diagram logout
73
C. Sequence diagram mengelola jenis persyaratan sd Interaction
Staf
FormJenisPersyaratan
FormDaftarJenisPersyaratan
JenisPersyaratanController
JenisPersyaratan
inputKodePersyaratan()
inputDataPersyaratan()
klikSimpanButton() simpan() simpan()
klikHapusButton() hapus() hapus(kodeJenisPersyaratan)
klikDaftarButton() tampilkanDaftar() bacaData()
tampilkanData()
(from Use Case Model)
Gambar 3. 12 Sequence diagram mengelola jenis persyaratan
D. Sequence diagram mengelola jenis pembayaran sd Interaction
Staf
FormJenisPembayaran
FormDaftarJenisPembayaran
JenisPembayaranController
JenisPembayaran
inputKodePembayaran()
inputDataPembayaran()
klikSimpanButton() simpan() simpan() klikHapusButton() hapus(kodeJenisPembayaran) hapus(kodeJenisPembayaran)
klikDaftarButton() tampilkanDaftar() bacaData()
tampilkanData()
(from Use Case Model)
Gambar 3. 13 Sequence diagram mengelola jenis pembayaran
74
E. Sequence diagram mengelola data staf administrasi sd Interaction
Staf
FormStafAdministrasi
FormDaftarStafAdministrasi
StafAdministrasiController
StafAdministrasi
inputNoPegawai()
inputDataPegawai()
klikSimpanButton() simpan() simpan()
klikHapusButton() hapus(noPegawai) hapus(noPegawai)
klikDaftarButton() tampilkanDaftar() bacaData() tampilkanData()
(from Use Case Model)
Gambar 3. 14 Sequence diagram mengelola data staf administrasi
F. Sequence diagram mengelola data guru sd Interaction
Staf
Guru
FormGuru
FormDaftarGuru
GuruController
Guru
inputNig() inputNig() inpuDataGuru() inputDataGuru() klikSimpanButton() klikSimpanButton() simpan()
simpan()
klikHapusButton() klikHapusButton() hapus(nig) hapus(nig)
klikDaftarButton() klikDaftarButton() tampilkanDaftar() bacaData() tampilkanData()
(from Use Case Model) (from Use Case Model)
Gambar 3. 15 Sequence diagram mengelola data guru
75
G. Sequence diagram mengelola data siswa sd Interaction
Staf
FormSiswa
FormDaftarSiswa
SiswaController
Siswa
inputNis()
inputDataSiswa()
klikSimpanButton() simpan() simpan()
klikHapusButton() haspu(nis) hapus(nis)
klikDaftarButton()
tampilkanDaftar() bacaData() tampilkanData()
(from Use Case Model)
Gambar 3. 16 Sequence diagram mengelola data siswa
H. Sequence diagram mengelola kelompok mata pelajaran sd Interaction
Staf
FormKelompokMataKuliah
FormDaftarKelompokMataKuliah
KelompokMataKuliahController
KelompokMataKuliah
inputKodeKelompokMataKuliah()
inputDataKelompokMataKuliah()
klikSimpanButton() simpan() simpan()
klikHapusButton() hapus(kodeKelompokMataKuliah) hapus(kodeKelompokMataKuliah)
klikDaftarButton() tampilkanDaftar() bacaData() tampilkanData()
(from Use Case Model)
Gambar 3. 17 Sequence diagram mengelola kelompok mata pelajaran
76
I. Sequence diagram mengelola mata pelajaran sd Interaction
Staf
FormMataPelajaran
FormDaftarMataPelajaran
MataPelajaranController
MataPelajaran
inputKodeMataPelajaran()
inputDataMataPelajaran()
klikSimpanButton() simpan() simpan()
klikHapusButton() hapus(kodeMataPelajaran) hapus(kodeMataPelejaran)
klikDaftarButton() tampilkanDaftar() bacaData() tampilkanData()
(from Use Case Model)
Gambar 3. 18 Sequence diagram mengelola mata pelajaran
J. Sequence diagram mengelola data jam sd Interaction
Staf
FormJam
FormDaftarJam
JamController
Jam
inputKodeJam() inputDataJam() klikSimpanButton() simpan() simpan()
klikHapusButton() hapus(kodeJam) hapus(kodeJam)
klikDaftarButton() tampilkanDaftarJam() bacaData() tampilkanData()
(from Use Case Model)
Gambar 3. 19 Sequence diagram mengelola data jam
77
K. Sequence diagram mengelola data jurusan sd Interaction
Staf
FormJurusan FormDaftarJurusan
JurusanController
Jurusan
inputKodeJurusan()
inputDataJurusan() klikSimpanButton() simpan() simpan()
klikHapusButton() hapus(kodeJurusan) hapus(kodeJurusan)
klikDaftarButton() tampilkanDaftar() bacaData() tampilkanData()
(from Use Case Model)
Gambar 3. 20 Sequence diagram mengelola data jurusan
L. Sequence diagram mengelola data kelas sd Interaction
Staf
FormKelas
FormDaftarKelas
KelasController
Kelas
inputDataKelas()
klikSimpanButton() simpan() simpan()
klikHapusButton() hapus() hapus()
klikDaftarButton() tampilkanDaftar() bacaData() tampilkanData()
(from Use Case Model)
Gambar 3. 21 Sequence diagram mengelola data kelas
78
M. Sequence diagram mengelola data kelas siswa sd Interaction
Staf
FormKelasSiswa FormDaftarKelasSiswa
KelasSiswaController
KelasSiswa
inputDataKelasSiswa()
klikSimpanButton() simpan() simpan()
klikHapusButton() hapus() hapus()
klikDaftarButton() tampilkanDaftar() bacaData() tampilkanData()
(from Use Case Model)
Gambar 3. 22 Sequence diagram mengelola data kelas siswa
N. Sequence diagram mengelola data pendaftaran sd Interaction
Staf
FormPendaftaran
PendaftaranController
inputNoPendaftaran() inputDataCalonSiswa() inputKelengkapanPersyaratan()
klikSimpanButton() simpan() simpan()
klikHapusButton() hapus() hapus()
klikDaftarButton() tampilkanDaftarCalonSiswa() bacaData() tampilkanData()
(from Use Case Model)
Gambar 3. 23 Sequence diagram mengelola data pendaftaran
CalonSiswa
79
O. Sequence diagram diagram proses penerimaan siswa sd Interaction
Staf
FormPenerimaanSiswa
PenerimaanSiswaController CalonSiswa Siswa KelasSiswa
inputTahunAjaran() hitungJumlahCalonSiswa() bacaData() setJumlahCalonSiswa()
klikProsesPenerimaanSiswaButton() prosesPenerimaanSiswa() bacaData() setJumlahDiterima()
klikSimpanButton() simpan() bacaData()
simpan() simpan()
(from Use Case Model)
Gambar 3. 24 Sequence diagram diagram proses penerimaan siswa
P. Sequence diagram mengelola data pembayaran sd Interaction
Staf
FormPembayaran
PembayaranController JenisPembayaran
Pembayaran
inputNoPembayaran() klikBaruButton() noPembayaranBaru() bacaNoPembayaranTerakhir() setNoPembayaran()
inputDataPembayaran() tampilkanDataPembayaran() baca() setNamaPembayaran() setBesarPembayaran()
klikSimpanButton() simpan() simpan() simpan()
klikHapusButton() hapus(noPembayaran) hapus(noPembayaran) hapus(noPembayaran)
klikDaftarButton() tampilkanDaftarPembayaran() bacaData() tampilkanData()
(from Use Case Model)
Gambar 3. 25 Sequence diagram mengelola data pembayaran
DetilPembayaran
80
Q. Sequence diagram mengelola jadwal sd Interaction
Staf
FormJadwal FormDaftarJadwal
JadwalController
Jadwal Kelas MataPelajaran Guru
bukaForm() aturTampilanAwal() bacaData() setItemKelasComboBox() bacaData() setItemMataPelajaranComboBox() bacaData() setItemGuruComboBox() bacaData() setItemJamComboBox()
inputKodeJadwal() cari(kodeJadwal) baca(kodeJadwal) tampilkanDataJadwal()
klikDaftarButton() tampilkanDaftarJadwal() bacaData() tampilkanData()
klikPilihButton() tampilkanDataJadwal() baca(kodeDipilih) tampilkanDataJadwal()
klikSimpanButton() simpan() simpan()
klikHapusButton() hapus(kodeJadwal) hapus(kodeJadwal)
(from Use Case Model)
Gambar 3. 26 Sequence diagram mengelola jadwal
Jam
81
R. Sequence diagram mengelola data nilai sd Interaction
Guru
FormNilai
FormDaftarJadwal
NilaiController
Nilai Jadwal KelasSiswa MataPelajaran Siswa
inputKodeJadwal() cariDataJadwal() baca() tampilkanDataJadwal() baca() tampilkanDataKelasSiswa() baca() tampilkanNamaMataPelajaran() baca() tampilkanDataSiswa() baca() tampilkanNilaiSiswa()
klikDaftarButton() tampilkanDaftarJadwal() bacaData() tampilkanData() klikPilihButton()
tampilkanDataJadwal() baca() tampilkanDataKelasSiswa() baca() tampilkanNamaMataPelajaran() baca() tampilkanDataSiswa() baca() tampilkanNilaiSiswa()
inputDataNilai()
klikSimpanButton() simpan() simpan()
(from Use Case Model)
Gambar 3. 27 Sequence diagram mengelola data nilai
82
S. Sequence diagram mencetak laporan penerimaan siswa sd Interaction
Staf
FormLaporanPenerimaanSiswa
PenerimaanSiswaController
Siswa
inputTahunAjaran()
klikCetakButton()
cetakPenerimaanSiswa(tahunAjaran)
cetakSiswaBaru(tahunAjaran)
(from Use Case Model)
Gambar 3. 28 Sequence diagram mencetak laporan penerimaan siswa
T. Sequence diagram mencetak laporan pembayaran sd Interaction
Staf
FormLaporanPembayaran
Pembayaran
Siswa
klikCetakButton()
cetakPembayaran()
cetak()
(from Use Case Model)
Gambar 3. 29 Sequence diagram mencetak laporan pembayaran
83
U. Sequence diagram mencetak laporan nilai sd Interaction
Staf
Guru
FormLaporanNilai
NilaiController
Nilai
klikCetakButton() cetakNilai() cetak()
klikCetakButton() cetakNilai() cetak()
(from Use Case Model) (from Use Case Model)
Gambar 3. 30 Sequence diagram mencetak laporan nilai
V. Sequence diagram mencetak laporan jadwal sd Interaction
Staf
Guru
FormLaporanJadwal
JadwalController
Jadwal
klikCetakButton() cetakJadwal() cetak()
klikCetakButton() cetakJadwal() cetak()
(from Use Case Model)(from Use Case Model)
Gambar 3. 31 Sequence diagram mencetak laporan jadwal
3.2.2.3 Activity Diagram Masing-masing
use
menunjukkan alur prosesnya.
case
juga
dibuatkan
activity
diagram
untuk
84
A. Activity diagram login act Activ ity
Mulai
Input User ID (atau NIG) dan passw ord
valid? [Ya]
Masuk ke dalam sistem/aplikasi dan aktifkan menu sesuai hak aksesnya
[Tidak]
Selesai
Gambar 3. 32 Activity diagram login
B. Activity diagram logout act Activ ity
Mulai
Klik tombol Logout
Disable semua menu
Selesai
Gambar 3. 33 Activity diagram logout
85
C. Activity diagram mengelola jenis persyaratan act Activ ity
Mulai
Input kode j enis persyaratan, nama persyaratan, j umlah, dan satuan
Klik tombol daftar
Tampilkan daftar j enis persyaratan
Klik tombol simpan
Klik tombol hapus Ada yang dipilih? [Tidak]
Simpan data (update/insert) j enis persyaratan
Hapus data j enis persyaratan
[Ya]
Tampilkan data j enis persyaratan yang dipilih
Selesai
Gambar 3. 34 Activity diagram mengelola jenis persyaratan
86
D. Activity diagram mengelola jenis pembayaran act Activ ity
Mulai
Input kode j enis pembayaran, nama pembayaran, j angka, dan satuan
Klik tombol daftar
Tampilkan daftar j enis pembayaran
Klik tombol simpan
Klik tombol hapus Ada yang dipilih? [Tidak]
Simpan data (update/insert) j enis pembayaran
Hapus data j enis pembayaran
[Ya]
Tampilkan data j enis pembayaran yang dipilih
Selesai
Gambar 3. 35 Activity diagram mengelola jenis pembayaran
87
E. Activity diagram mengelola data staf administrasi act Activ ity
Mulai
Input no. pegaw ai, nama, alamat, tempat lahir, tanggal lahir, dan passw ord
Klik tombol daftar
Tampilkan daftar staf administrasi
Klik tombol simpan
Klik tombol hapus Ada yang dipilih? [Tidak]
Simpan data (update/insert) staf administrasi
Hapus data staf administrasi
[Ya]
Tampilkan data staf administrasi yang dipilih
Selesai
Gambar 3. 36 Activity diagram mengelola data staf administrasi
88
F. Activity diagram mengelola data guru act Activ ity
Mulai
Input NIG, nama, alamat, tempat lahir, tanggal lahir, dan passw ord
Klik tombol daftar
Tampilkan daftar guru
Klik tombol simpan
Klik tombol hapus Ada yang dipilih? [Tidak]
Simpan data (update/insert) guru
Hapus data guru [Ya]
Tampilkan data guru yang dipilih
Selesai
Gambar 3. 37 Activity diagram mengelola data guru
89
G. Activity diagram mengelola data siswa act Activ ity
Mulai
Input no. pegaw ai, nama, alamat, tempat lahir, tanggal lahir, asal sekolah, tahun lulus, dan nilai uj ian nasional
Klik tombol daftar
Tampilkan daftar sisw a
Klik tombol simpan
Klik tombol hapus Ada yang dipilih? [Tidak]
Simpan data (update/insert) sisw a
Hapus data sisw a [Ya]
Tampilkan data sisw a yang dipilih
Selesai
Gambar 3. 38 Activity diagram mengelola data siswa
90
H. Activity diagram mengelola kelompok mata pelajaran act Activ ity
Mulai
Input kode kelompok, dan nama kelompok
Klik tombol daftar
Tampilkan daftar kelompok mata pelaj aran
Klik tombol simpan
Klik tombol hapus Ada yang dipilih? [Tidak]
Simpan (update/insert) data kelompok mata pelaj aran
Hapus data kelompok mata pelaj aran
[Ya]
Tampilkan data kelompok mata pelaj aran yang dipilih
Selesai
Gambar 3. 39 Activity diagram mengelola kelompok mata pelajaran
91
I. Activity diagram mengelola mata pelajaran act Activ ity
Mulai
Input kode mata pelaj aran, dan nama mata pelaj aran
Klik tombol daftar
Tampilkan daftar mata pelaj aran
Klik tombol simpan
Klik tombol hapus
Ada yang dipilih? [Tidak] Simpan data (update/insert) mata pelaj aran
Hapus data mata pelaj aran
[Ya]
Tampilkan data mata pelaj aran yang dipilih
Selesai
Gambar 3. 40 Activity diagram mengelola mata pelajaran
92
J. Activity diagram mengelola data jam act Activ ity
Mulai
Input kode j am, keterangan, mulai, dan selesai
Klik tombol daftar
Tampilkan daftar j am
Klik tombol simpan
Klik tombol hapus Ada yang dipilih? [Tidak]
Simpan (update/insert) data j am
Hapus data j am [Ya]
Tampilkan data j am yang dipilih
Selesai
Gambar 3. 41 Activity diagram mengelola data jam
93
K. Activity diagram mengelola data jurusan act Activ ity
Mulai
Input kode j urusan, dan nama j urusan
Klik tombol daftar
Tampilkan daftar j urusan
Klik tombol simpan
Klik tombol hapus Ada yang dipilih? [Tidak]
Simpan (update/insert) data j urusan
Hapus data j urusan [Ya]
Tampilkan data j urusan yang dipilih
Selesai
Gambar 3. 42 Activity diagram mengelola data jurusan
94
L. Activity diagram mengelola data kelas act Activ ity
Mulai
Input tahun aj aran, semester, tingkat, kode j urusan, urutan kelas, dan daya tampung
Klik tombol daftar
Tampilkan daftar kelas
Klik tombol simpan
Klik tombol hapus
[Tidak] Simpan (update/insert) data kelas
Ada yang dipilih?
Hapus data kelas [Ya]
Tampilkan data kelas yang dipilih
Selesai
Gambar 3. 43 Activity diagram mengelola data kelas
95
M. Activity diagram mengelola data kelas siswa act Activ ity
Mulai
Input tahun aj aran, semester, tingkat, kode j urusan, urutan kelas, dan nis
Klik tombol daftar
Tampilkan daftar kelas sisw a
Klik tombol simpan
Klik tombol hapus Ada yang dipilih?
Simpan (update/insert) data kelas sisw a
Hapus data kelas sisw a [Ya] [Tidak]
Tampilkan data kelas sisw a yang dipilih
Selesai
Gambar 3. 44 Activity diagram mengelola data kelas siswa
96
N. Activity diagram mengelola data pendaftaran act Activ ity
Mulai
Input tahun aj aran, no. pendaftaran, data sisw a, dan data kelengkapan persyaratan
Klik tombol daftar klik tombol no. pendaftaran baru Tampilkan daftar calon sisw a
Klik tombol simpan
Klik tombol hapus Ada yang dipilih? [Tidak]
Simpan (update/insert) data calon sisw a
tampilkan no. pendaftaran baru
Hapus data calon sisw a [Ya]
Tampilkan data calon sisw a yang dipilih
Selesai
Gambar 3. 45 Activity diagram mengelola data pendaftaran
97
O. Activity diagram proses penerimaan siswa act Activ ity
Mulai
Tampilkan j umlah calon sisw a, dan daya tampung
Klik tombol proses penerimaan
Klik tombol simpan
Urutkan calon sisw a berdasarkan j urusan yang dipilih, nilai uj ian nasional (desc), tahun lulus (desc), dan no pendaftaran.
Simpan semua data calon sisw a yang telah dialokasikan ke dalam tabel sisw a
Alokasikan calon sisw a dalam kelas sesuai daya tampung
Selesai
Gambar 3. 46 Activity diagram proses penerimaan siswa
98
P. Activity diagram mengelola data pembayaran act Activ ity
Mulai
Input no. pembayaran, data sisw a, dan data pembayaran
Klik tombol daftar klik tombol no. pembayaran baru Tampilkan daftar pembayaran
Klik tombol simpan
Klik tombol hapus Ada yang dipilih? [Tidak]
Simpan (update/insert) data pembayaran
tampilkan no. pembayaran baru
Hapus data pembayaran [Ya]
Tampilkan data pembayaran yang dipilih
Selesai
Gambar 3. 47 Activity diagram mengelola data pembayaran
99
Q. Activity diagram mengelola jadwal act Activ ity
Mulai
Input data nilai
Klik tombol daftar Input kode Jadw al
Tampilkan daftar j adw al Klik tombol simpan
Simpan data nilai
Ada yang dipilih?
[Tidak]
[Ya]
Tampilkan data j adw al yang dipilih
Tampilkan data sisw a dan nilainya
Selesai
Gambar 3. 48 Activity diagram mengelola jadwal
100
R. Activity diagram mengelola data nilai act Activ ity
Mulai
Klik tombol daftar Input nilai sisw a
Tampilkan daftar j adw al Klik tombol simpan
Ada yang dipilih? [Tidak] Simpan data nilai sisw a
[Ya]
Tampilkan data sisw a sesuai j adw al yang dipilih
Selesai
Gambar 3. 49 Activity diagram mengelola data nilai
101
S. Activity diagram mencetak laporan penerimaan siswa act Activ ity
Mulai
Input tahun aj aran
Tombol cetak diklik
Tombol tutup diklik
Cetak data penerimaan sisw a sesuai tahun aj aran yang diinput
Tutup form
Selesai
Gambar 3. 50 Activity diagram mencetak laporan penerimaan siswa
102
T. Activity diagram mencetak laporan pembayaran act Activ ity
Mulai
Tampilkan pilihan data pembayaran yang akan dicetak
Tombol cetak diklik
Tombol tutup diklik
Cetak data pembayaran
Tutup form
Selesai
Gambar 3. 51 Activity diagram mencetak laporan pembayaran
103
U. Activity diagram mencetak laporan nilai act Activ ity
Mulai
Tampilkan pilihan Nilai yang akan dicetak
Tombol cetak diklik
Tombol tutup diklik
Cetak nilai
Tutup form
Selesai
Gambar 3. 52 Activity diagram mencetak laporan nilai
104
V. Activity diagram mencetak laporan jadwal act Activ ity
Mulai
Tampilkan pilihan j adw al yang akan dicetak
Tombol cetak diklik
Tombol tutup diklik
Cetak data j adw al
Tutup form
Selesai
Gambar 3. 53 Activity diagram mencetak laporan jadwal
105
3.2.2.4 Class Diagram Rancangan hubungan antar-class dibuat dalam diagram class sebagai berikut:
Gambar 3. 54 Class diagram aplikasi administrasi sekolah
106
3.2.2.5 User Interface (Antarmuka Pengguna) Antarmuka pengguna dibuat seperti gambar-gambar di bawah ini: A. Desain antarmuka form utama
Gambar 3. 55 Desain antarmuka form utama
B. Desain antarmuka form login custom Aplikasi Form Login
User ID Password Status
Staf Administrasi
Login
Batal
Gambar 3. 56 Desain antarmuka form login
107
C. Desain antarmuka informasi aplikasi custom Aplikasi Informasi Aplikasi
Aplikasi Administrasi Sekolah SMK AVERUS JAKARTA Oleh: Yulianti NIM: 2009140661 Universitas Pamulang 2013
Gambar 3. 57 Desain antarmuka informasi aplikasi
D. Desain antarmuka master data jenis persyaratan custom Master Data Master Data Jenis Persyaratan
Kode Persyaratan
Daftar
Nama Persyaratan Satuan Jumlah
Simpan
Hapus
Tutup
Gambar 3. 58 Desain antarmuka master data jenis persyaratan
108
E. Desain antarmuka master data jenis pembayaran custom Master Data Master Data Jenis Pembayaran
Daftar
Kode Jenis Pembayaran Nama Jenis Pembayaran Jumlah Pembayaran Jangka Waktu Satuan
Simpan
Hapus
Tutup
Gambar 3. 59 Desain antarmuka master data jenis pembayaran
BAB IV IMPLEMENTASI DAN PENGUJIAN
4.1
Implemantasi
4.1.1 Implementasi Basis Data Rancangan
basis
data
diimplementasikan
pada
DBMS
(Database
Management System) MySQL dan dihasilkan diagram relasi sebagai berikut:
109
110
Gambar 4. 1 Diagram relasi basis data administrasi sekolah
111
4.1.2 Implementasi Aplikasi Rancangan yang telah dibuat pada bab III diimplementasikan menggunakan bahasa
pemrograman Java
menggunakan IDE
(Integrated Development
Environment) NetBeans, sehingga dihasilkan seperti berikut ini: A. Tampilan form deskripsi
Gambar 4. 2 Tampilan form deskripsi
B. Tampilan form login
Gambar 4. 3 Tampilan form login
112
C. Tampilan form utama
Gambar 4. 4 Tampilan form utama
D. Tampilan form siswa
Gambar 4. 5 Tampilan form siswa
113
E. Tampilan form guru
Gambar 4. 6 Tampilan form guru
F. Tampilan form staf administrasi
Gambar 4. 7 Tampilan form staf administrasi
114
G. Tampilan form pendaftaran
Gambar 4. 8 Tampilan form pendaftaran
H. Tampilan form penerimaan siswa
Gambar 4. 9 Tampilan form penerimaan siswa
115
I. Tampilan form pembayaran
Gambar 4. 10 Tampilan form pembayaran
J. Tampilan form jadwal
Gambar 4. 11 Tampilan form jadwal
116
K. Tampilan form nilai
Gambar 4. 12 Tampilan form nilai
L. Tampilan form laporan penerimaan siswa
Gambar 4. 13 Tampilan form laporan penerimaan siswa
117
M. Tampilan form laporan nilai
Gambar 4. 14 Tampilan form laporan nilai
N. Tampilan form laporan pembayaran
Gambar 4. 15 Tampilan form laporan pembayaran
118
O. Tampilan form laporan jadwal
Gambar 4. 16 Tampilan form laporan jadwal
4.2
Pengujian Pengujian telah dilakukan menggunakan metode black box dan white box
selama pengembangan aplikasi, pengujian dilakukan untuk memastikan bahwa rancangan algoritma dan implementasi pada source code program telah sesuai dengan tujuan yang telah ditentukan. Pengujian telah dilakukan baik per blok source code program maupun per modul. Bug (cacat) yang ditemukan pada aplikasi langsung diperbaiki agar sesuai dengan proses yang diinginkan.
4.2.1 Pengujian Black Box Pengujian black box dilakukan dengan menguji fungsionalitas (functional testing) aplikasi. Pengujian dilakukan dengan mengecek fungsionalitas pada bagian tertentu sesuai tabel berikut ini:
119
Tabel 4. 1 Pengujian fungsionalitas (functional testing) No
Skenario pengujian
Test case
. 1 Memilih (mengklik)
Hasil yang
Hasil
diharapkan
pengujian
Klik menu item
Menampilkan
Sesuai
login
form login
harapan
Jabatan dipilih
Menampilkan
Sesuai
login, kemudian
staf
keterangan
harapan
mengklik button
administrasi, no.
no. pegawai
login
pegawai kosong, harus diisi
menu login 2 Mengosongkan form
Kesimpulan
valid
valid
password kosong 3 Melakukan login
Jabatan dipilih
Berhasil login
Sesuai
dengan memilih
staf
dan menu
harapan
jabatan staf dengan
administrasi, no.
untuk staf
data yang benar
pegawai diisi
administrasi
ADMIN, dan
diaktifkan
valid
password diisi ADMIN 4 Mengosongkan kode persyaratan pada
Kode
Aplikasi
Sesuai
persyaratan = ””
menampilkan
harapan
form master data
pesan “Kode
jenis persyaratan,
persyaratan
kemudian mengklik
tidak boleh
tombol simpan
kosong”
5 Mengosongkan kode persyaratan pada
Kode
Aplikasi
Sesuai
persyaratan = ””
menampilkan
harapan
form master data
pesan “Kode
jenis persyaratan,
persyaratan
kemudian mengklik
tidak boleh
tombol hapus
kosong”
Valid
Valid
120
4.2.2 Pengujian White Box Pengujian white box dilakukan dengan menguji unit (unit testing) untuk memastikan bahwa modul/unit dapat bekerja sesuai harapan. Pengujian dilakukan menggunakan fasilitas yang tersedia pada IDE NetBeans sebagai berikut: A. Membuat test (pengujian)
Gambar 4. 17 Membuat test (pengujian) unit (white box)
121
B. Menentukan test (pengujian)
Gambar 4. 18 Menentukan test (pengujian) unit (white box)
C. Mengubah kondisi test (pengujian) @Test public void testGetKodePersyaratan() { System.out.println("getKodePersyaratan"); JenisPersyaratan instance = new JenisPersyaratan(); String expResult = null; String result = instance.getKodePersyaratan(); assertEquals(expResult, result); // TODO review the generated test code and remove the default call to fail. //fail("The test case is a prototype."); }
Variabel expResult diisi dengan nilai yang diharapkan setelah metode diproses, sedangkan variabel result adalah nilai setelah metode diproses. Jika kedua variabel bernilai sama, maka dianggap metodenya benar (sesuai yang diharapkan).
122
D. Melakukan test (pengujian)
Gambar 4. 19 Melakukan test (pengujian) unit (white box)
E. Menampilkan hasil test (pengujian) Jika hasil pengujian tidak menampilkan kesalahan seperti pada gambar 4.20 di bawah ini berarti unit/metode yang diuji tidak ada kesalahan.
Gambar 4. 20 Hasil test (pengujian) unit (white box)
123
Berikut ini hasil test (pengujian) untuk empat unit/modul:
Gambar 4. 21 Hasil test (pengujian) empat unit/modul unit (white box)
4.3
Analisa Setelah aplikasi yang dibuat diimplementasikan pada jaringan LAN (Local
Area Network) menggunakan satu server basis data, yaitu MySQL, aplikasi dapat digunakan secara bersamaan, dapat yang tersimpan dapat digunakan secara bersamaan, sehingga ketika meng-input data dapat lebih cepat. Aplikasi yang telah dibuat menggunakan arsitektur MVC (Model-ViewController) dapat memperpendek source code program, karena beberapa modul (metode atau class) dapat digunakan modul lain tanpa mengetik ulang. Misalnya, jika tidak menggunakan arsitektur MVC, maka source code untuk membaca atau menampilkan data siswa harus diketik di modul form siswa dan modul form pembayaran. Tetapi jika menggunakan arsitektur MVC, maka source code
124
tersebut cukup diketik di satu modul, kemudian modul lain tinggal memanggil nama metodenya. Jika menggunakan arsitektur MVC, ketika melakukan perubahan source code pada modul user interface (antarmuka pengguna) tidak harus mengubah bagian model (modul yang berhubungan dengan database). Hal ini dapat mempermudah untuk menyesuaikan dengan kebutuhan di masa depan.
BAB V PENUTUP
5.1
Kesimpulan Dari hasil implementasi dan analisa pada bab sebelumnya, dapat diambil
kesimpulan sebagai berikut: a. Aplikasi administrasi sekolah yang dibangun dengan arsitektur clientserver dapat mengurangi duplikasi data, karena semua data disimpan dalam basis data yang terpusat dan digunakan dengan sistem berbagi. b. Aplikasi administrasi sekolah yang telah dibuat dapat memperbaiki pengorganisasian dokumen-dokumen di sekolah, semua data disimpan dalam basis data terpusat, data/dokumen yang diperlukan dapat dilihat, dan dianalisa tanpa harus dicetak. c. Aplikasi administrasi sekolah dapat mempercepat pembuatan laporanlaporan yang diperlukan dari data-data administrasi, karena untuk membuat laporan, tinggal memilih menu laporan yang diinginkan, dan spesifikasi laporan yang akan dicetak. d. Aplikasi yang dibuat dengan arsitektur MVC (Model-View-Controller) menjadi lebih rapi, dapat memperpendek source code aplikasi, dan mudah disesuaikan dengan kebutuhan di masa depan. Jika ada perubahan pada tampilan antarmuka, maka tidak perlu mengubah source code yang berhubungan dengan basis data.
5.2
Saran Aplikasi administrasi sekolah yang telah dibuat hanya mencakup
administrasi pendaftaran, pembayaran, jadwal, dan nilai. Agar aplikasi lebih baik dan lengkap, dapat dikembangkan lebih lanjut, yaitu: a. Ditambahkan administrasi absensi siswa, kegiatan ekstrakulikuler. b. Ditambahkan data-data siswa seperti, data kontak, hobi, data orangtua, dan data wali murid. c. Meningkatkan keamanan data dengan menggunakan arsitektur multitier.
125
DAFTAR PUSTAKA
Alam, M. A. (2005). Belajar Sendiri Pemrograman Database Lokal dan Server. Jakarta: Elex Media Komputindo. Antonio, H., & Safriadi, N. (2012). Rancang Bangun Sistem Informasi Administrasi Informatika. Jurnal ELKHA, 12-14. Booch, G. (1994). Object-Oriented Analysis and Design (Second ed.). California: Addison Wesley. Davis, W. S., & Yen, D. C. (1998). The Information System Consultant's Handbook: Systems Analysis and Design. CRC Press. Dennis, A., Wixom, B. H., & Roth, R. M. (2009). System Analysis and Design (Fourth ed.). New Jersey: Wiley. Depdiknas. (2013, 05 24). Kamus Besar Bahasa Indonesia. Diambil kembali dari Departemen
Pendidikan
Nasional:
http://pusatbahasa.kemdiknas.go.id/kbbi/ Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling
Language
(Third
Edition).
Boston:
Addison-Wesley
Professional. Gomaa, H. (2011). Software Modeling and Design. New York: Cambridge. Hariyanto, B. (2007). Esensi-esensi Bahasa Pemrograman Java. Bandung: Informatika Bandung. Harrington, J. L. (2009). Relational database design and implementation: clearly explained (3rd ed.). Burlington: Morgan Kaufmann. Huda, M., & Komputer, B. (2009). Membuat Aplikasi Rental dengan Java dan MySQL. Jakarta: Elex Media Komputindo. Kadir, A. (2009). Dasar Perancangan dan Implementasi Database Relasional. Yogyakarta: Andi. Kristanti, T., & Redita, N. G. (2012). Sistem Informasi Nilai SMPN 14 Bandung. Jurnal Sistem Informasi, 85-94.
126
127
Martha, D., Harianto, C., & Asfi, M. (2010). Metode MVC untuk Perancangan Sistem Berorientasi Objek pada Ujian Saringan Masuk Penerimaan Mahasiswa Baru di STMIK CIC Cirebon. Jurnal Informatika, 145 - 160. Munawar. (2005). Pemodelan Visual Dengan UML. Yogyakarta: Graha Ilmu. Nugroho, A. (2009). Rekayasa Perangkat Lunak Menggunakan UML dan Java. Yogyakarta: Andi. O’Regan, G. (2011). Introduction to Software Process Improvement. London: Springer. Prasetyo, D. D. (2004). Belajar Sendiri Aplikasi Database Client/Server Menggunakan Delphi dan MySQL. Jakarta: Elex Media Komputindo. Qureshi, M. R., & Sabir, F. (2013). A Comparison of Model View Controller and Model View Presenter. The Science International (Lahore), 7-9. Simarmata, J. (2010). Rekayasa Perangkat Lunak. Yogyakarta: Andi. Stephens, R. (2009). Beginning Database Design Solutions. Indianapolis: Wiley. Stephens, R. K., & Plew, R. R. (2001). Database Design. Indianapolis: Sams. Sulindawaty, & Calam, A. (2011). Sistem Informasi Pengolahan Nilai Siswa Pada SMP Swasta Bakti Medan. Jurnal SAINTIKOM, 53-69. Sumarta, T., Siswoyo, B., & Juhana, N. (2004). Perancangan Model Berorientasi Objek
Menggunakan
Unified
Modeling
Language
(UML).
JBPTUNIKOMPP, 1-8. Supriyanto. (2010). Pemrograman Database Menggunakan Java dan MySQL untuk Pemula. Jakarta: Mediakita. Utomo, E. P. (2009). Panduan Mudah Mengenal Bahasa Java. Bandung: Yrama Widya. Utpatadevi, N. L., Sudana, A. A., & Cahyawan, A. A. (2012). Implementation of MVC (Model-View-Controller) Architectural to Academic Management Information System with Android Platform Base. International Journal of Computer Applications, 1-6. 'Uyun, S., & Ma'arif, M. R. (2010). Implementation of Model View Controller (MVC) Architecture on Building Web-based Information System. Seminar Nasional Aplikasi Teknologi Informasi 2010 (SNATI 2010), E-47 - E-50.
128
Vlugt, M. v., & Sambasivam, S. (2005). Redesign of Stand-Alone Applications into Thin-Client/Server Architecture. Issues in Informing Science and Information Technology, 723-742. Wahana Komputer. (2010). Shortcourse SQL Server 2008 Express. Yogyakarta: Andi. Widhyaestoeti, D. (2011). Rancang Bangun Database Nilai Siswa Tingkat Sekolah Menengah. Jurnal Ilmiah Teknologi dan Informasi Volume 2, 118. Widiyanto, N. (2010). Membangun Aplikasi Java Enterprise dengan Arsitektur Model View Controller (MVC). Yogyakarta: Andi. Wijono, G. S., Suharto, B. H., & Wijono, M. S. (2007). Pemrograman Java Servlet dan JSP dengan NetBeans. Yogyakarta: Andi.
129
Lampiran 1 Formulir data pribadi calon siswa baru
130
131
Lampiran 2 Bidang keahlian bisnis dan manajemen SMK AVERUS
132
Lampiran 3 Jadwal mengajar SMK Averus
133
Lampiran 4 Kwitansi SMK AVERUS
134
Lampiran 5 Kartu tanda bukti pembayaran SMK AVERUS
135
136
Lampiran 6 Kartu hasil studi (KHS) SMK AVERUS
137
138
Lampiran 7 Kartu konsultasi mahasiswa
