SERVER
DAN MVC (
MODEL-VIEW-CONTROLLER
) UNTUK MEMBANGUN
APLIKASI ADMINISTRASI SEKOLAH
(STUDI KASUS: SMK AVERUS JAKARTA)
Skripsi
Oleh:
Yulianti
2009140661
PROGRAM STUDI TEKNIK INFORMATIKA
FAKULTAS TEKNIK
UNIVERSITAS PAMULANG
SERVER
DAN MVC (
MODEL-VIEW-CONTROLLER
) 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
ii
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 (MODEL-VIEW-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
iii
LEMBAR PERSETUJUAN
NIM : 2009140661
Nama : YULIANTI
Program Studi : TEKNIK INFORMATIKA
Fakultas : TEKNIK
Jenjang Pendidikan : STRATA 1
Judul Skripsi : IMPLEMENTASI ARSITEKTUR CLIENT-SERVER DAN MVC (MODEL-VIEW-CONTROLLER) UNTUK MEMBANGUN APLIKASI ADMINISTRASI
SEKOLAH (STUDI KASUS: SMK AVERUS JAKARTA)
iv
LEMBAR PENGESAHAN
NIM : 2009140661
Nama : YULIANTI
Program Studi : TEKNIK INFORMATIKA
Fakultas : TEKNIK
Jenjang Pendidikan : STRATA 1
Judul Skripsi : 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.
v
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
vi
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)
vii
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)
viii
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
ix
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
x
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 ANALISA DAN PERANCANGAN ... 56
3.1 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 IMPLEMENTASI DAN PENGUJIAN ... 109
4.1 Implemantasi ... 109
4.1.1 Implementasi Basis Data ... 109
xi
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
xii
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
xiii
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
xiv
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
xv
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
xvi
DAFTAR SIMBOL
No. Simbol Nama Simbol Keterangan
1 Boundary Untuk menggambarkan
sistem atau aplikasi.
2 Actor Untuk menggambarkan
pengguna (user) sistem/aplikasi
3 Use Case Untuk menggambarkan apa
yang dilakukan actor
terhadap sistem
4 Assosiation Garis lurus untuk
menunjukkan hubungan
actor dengan use case
5 Generalization Garis dengan ujung
berbentuk panah,
menunjukan use case sumber (source) adalah penjabaran (detil) dari use case yang ditunjuk panah (destination)
6 Include Garis putus-putus dengan
ujung berbentuk panah, menunjukan use case sumber (source) akan selalu
xvii
No. Simbol Nama Simbol Keterangan
7 Package Digunakan untuk
menggambarkan diagram paket, yang berfungsi untuk mengelompokkan use case diagram atau class diagram
8 Trace Menggambarkan bahwa
sumber (source) berhubungan dengan sebagian/seluluh dalam tujuan (destination)
9 Class Untuk menggambarkan class
yang memiliki attribute dan
method.
10 Import Untuk menggambarkan
bahwa package sumber (source) diimport oleh anggota dari package tujuan (destination)
11 Initial Untuk menggambarkan awal
activity (aktivitas)
12 Final Untuk menggambarkan akhir
activity (aktivitas)
13 Activity Untuk menggambarkan
xviii
No. Simbol Nama Simbol Keterangan
14 Decission Untuk menggambarkan
percabangan activity
(aktivitas)
15 Fork/Join Untuk menunjukkan proses
yang berjalan secara paralel
16 Boundary Untuk menggambarkan class
antarmuka (view) pada
sequence diagram
17 Control Untuk menggambarkan class
proses (controller) pada
sequence diagram
18 Entity Untuk menggambarkan class
entitas (model) pada
sequence diagram
act Activ ity
ac...
act Activ ity
sd Interaction
Boundary
sd Interaction
Control
sd Interaction
xix
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
1
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 murid-muridnya. 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).
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
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.
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.
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-View-Controller) agar penyusunan aplikasi lebih rapi, dan mudah dikembangkan sesuai kebutuhan di masa depan.
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
7
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).
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 cara-cara 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.
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
E.Administrasi Perlengkapan atau Barang
Administrasi perlengkapan atau barang memiliki tugas dalam perencanaan, pengadaan, penyimpanan dan 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
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
Server Network
Client
Client
Client
Printer
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)
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)
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)
2.5.2 Transformasi ERD ke LRS
LRS (Logical Record Structure) adalah representasi dari struktur record-record 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
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).
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:
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 ketidak-konsistenan data.
c. Proses pembaharuan data tidak efisien.
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 non-identifying 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)
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:
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.
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 permasalahan-permasalahan 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
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
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
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
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.
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
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.
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
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
