Yogyakarta, 10 Mei Edhy Sutanta. iii. Dengan ini saya menyatakan bahwa dalam Tesis ini tidak terdapat karya yang

ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE Sebuah Kritisi Rancangan Struktur Tabel Database Hasil-Hasil Penelitian Pada Sistem Informasi Akademik

TESIS Untuk Memenuhi Sebagian Persyaratan Mencapai Derajat Sarjana Strata-2 Program Studi Ilmu Komputer Jurusan Ilmu-Ilmu Matematika & Pengetahuan Alam Fakultas Matematika & IPA Universitas Gadjah Mada

Diajukan oleh:

Edhy Sutanta

20867/I-4/1648/03

SEKOLAH PASCASARJANA UNIVERSITAS GADJAH MADA YOGYAKARTA 2006 i

ii

PERNYATAAN

Dengan ini saya menyatakan bahwa dalam Tesis ini tidak terdapat karya yang pernah diajukan untuk memperoleh gelar kesarjanaan di suatu Perguruan Tinggi, dan sepanjang pengetahuan saya tidak terdapat karya atau pendapat yang pernah ditulis atau diterbitkan oleh orang lain, kecuali yang secara tertulis diacu dalam naskah ini dan disebutkan di dalam Daftar Pustaka.

Yogyakarta, 10 Mei 2006

Edhy Sutanta

iii

Kupersembahkan untuk : istriku: retno widiastuti, s.t.,

terima kasih atas segala perhatian, pengertian, dan dukungannya;

kedua putriku:

safira maharani redhyndaputri, ashifa nareswari redhyndaputri, kalian adalah sumber harapan, sumber inspirasi, dan sumber sukacita;

kedua orangtuaku dan segenap anggota keluarga; almamater.

iv

KATA PENGANTAR Alhamdulillahirabbil’alamin, puji dan syukur ke hadirat Allah SWT, Tuhan Yang Maha Esa, atas limpahan rahmat, nikmat, dan hidayah yang telah diberikan-Nya,

sehingga

kami

masih

diberi

kesempatan

untuk

dapat

menyelesaikan Tesis ini. Mengenang semua pengalaman hidup ini, sekali lagi kami panjatkan syukur kepada-Mu ya Allah SWT, Tuhan Yang Maha Pengasih dan Penyayang, Tuhan Yang Maha Pemurah, Penguasa Alam Semesta. Ucapan terima kasih pertama-tama kami sampaikan kepada Drs. Retantyo Wardoyo, M.Sc., Ph.D., selaku Pembimbing Utama Tesis ini yang dengan sistematis telah memaksa kami harus belajar dan terus belajar dengan serius. Beliau adalah salah seorang Dosen Terbaik yang pernah kami jumpai, yang selalu ingin melihat mahasiswanya menemukan dan mencapai hal yang terbaik, kesediaannya untuk meluangkan waktu, tenaga, pikiran untuk membimbing, dan kesediaannya untuk selalu membantu mahasiswanya akan selalu membekas dalam ingatan kami. Di luar ruang kelas, Beliau juga telah menjadi Ayah yang sangat baik dan penuh perhatian bagi kami. Ucapan terima kasih juga kami sampaikan kepada Drs. Retantyo Wardoyo, M.Sc., Ph.D., Dr. Ahmad Ashari, M.Kom., Drs. Agus Harjoko, M.Sc., Ph.D., Dra. Sri Hartati, M.Sc., Ph.D., selaku Penguji pada Ujian Tesis yang telah banyak memberi masukan penting untuk peningkatan kualitas Tesis ini. Cecaran pertanyaan mematikan yang diberikan selama ujian Tesis ini telah membuat kami

v

menyadari dengan segenap hati bahwa banyak hal besar yang harus kami pelajari dan tidak bisa ditunda-tunda lagi. Ucapan terima kasih juga kami sampaikan kepada para Dosen di Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM yang telah memberikan bekal ilmu pengetahuan dan pengalaman yang berharga kepada kami. Mereka itu antara lain adalah Drs. Widodo Prijodiprojo, M.Sc. EE., Drs. Retantyo Wardoyo, M.Sc., Ph.D., Drs. GP. Daliyo, Dipl. Com., Dr. Ahmad Ashari, M.Kom., Drs. Agus Harjoko, M.Sc., Ph.D., Dra. Sri Hartati, M.Sc., Ph.D., Drs. Jazi Eko Istiyanto, M.Sc., Ph.D., Drs. Heri Pratomo, M.Kom. (almarhum). Mereka itu adalah kelompok Dosen yang inspiratif. Keberadaan mereka telah membuat kami memahami kualitas seorang Sarjana Stata-2 pada Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM. Keberadaan mereka membuat kami yakin bahwa kualitas pendidikan Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA di UGM akan terus mengalami peningkatan. Ucapan terima kasih juga kami sampaikan kepada segenap Pimpinan dan Staf di lingkungan Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM yang berperan besar terhadap kelancaran studi selama kami menempuh studi jenjang Srata-2. Ucapan terima kasih juga kami sampaikan kepada kedua Orangtua kami, atas segala doa, dukungan, dan perjuangan dalam membesarkan, mendidik, dan membimbing kami di tengah berbagai kesulitan yang harus dihadapinya. Kepada segenap anggota keluarga, kami sampaikan ucapan terima kasih atas dukungan yang diberikan selama ini.

vi

Untuk teman-teman seangkatan di Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM, kami sampaikan terima kasih atas dukungan dan kerjasama yang diberikan semasa menempuh studi Strata-2. Secara khusus, ucapan terima kasih kami sampaikan kepada I Wayan Candra Winetra, S.Kom., M.Kom. atas kesempatan yang diberikan untuk secara terus-menerus dapat berdiskusi dan berbagi ilmu pengetahuan. Kehadirannya sangatlah lengkap dan mengagumkan, selama menempuh studi Strata-1 ia telah hadir sebagai mahasiswa terbaik yang pantas kami banggakan, dan selama menempuh studi S2 ia telah menjadi adik yang menyenangkan, guru dalam menulis program, dan sahabat. Akhirnya, ucapan terima kasih kami sampaikan kepada istri tercinta Retno Widiastuti, S.T. atas segala perhatian, pengertian, dan dukungan yang diberikan. Kehadirannya telah membuat kami semakin mengerti tentang makna hidup sebagai hamba Allah SWT dan pengikut Rasulullah Muhammad SAW. Semoga kebahagiaan selalu menyertai setiap waktu. Untuk kedua putri kami, Safira Maharani Redhyndaputri dan Ashifa Nareswari Redhyndaputri, sungguh kalian telah menjadi sumber harapan, inspirasi, dan sukacita. Semoga kalian bahagia selalu. Yogyakarta, 10 Mei 2006 Edhy Sutanta

vii

DAFTAR ISI Halaman Judul Halaman Pengesahan Halaman Pernyataan Halaman Persembahan Kata Pengantar Daftar Isi Daftar Tabel Daftar Gambar Daftar Lampiran INTISARI ABSTRACT

Hal: i ii iii iv v viii xi xiii xvii xx xxi

BAB I. PENDAHULUAN 1.1. Latar Belakang Masalah 1.2. Rumusan Masalah 1.3. Batasan Masalah 1.4. Tujuan Penelitian 1.5. Manfaat Penelitian 1.6. Keaslian Penelitian 1.7. Organisasi Laporan Penelitian

1 1 4 5 5 6 6 7

BAB II. LANDASAN TEORI 2.1. Tinjauan Tentang Konsep SIM 2.1.1. Definisi SIM 2.1.2. Tinjauan Tentang SIM 2.1.3. Tujuan SIM 2.1.4. Pengolahan Data Dalam SIM 2.1.5. Unsur-Unsur Penting Agar SIM Efektif 2.1.6. Bentuk Anatomi SIM 2.1.7. Jaringan Kerja SIM 2.1.8. Karakteristik Kebutuhan Informasi Dalam SIM 2.1.9. Metodologi Pengembangan SIM 2.1.10. Perancangan Sistem Dalam SIM 2.1.11. Kriteria Keberhasilan SIM 2.2. Tinjauan Tentang Konsep Database 2.2.1. Definisi Database 2.2.2. Tujuan Database 2.2.3. Keuntungan Database 2.2.4. Kendala Dalam Database 2.2.5. Pandangan Terhadap Database 2.2.6. Model Data 2.2.7. Relational Database Model/RDBM 2.3. Pandangan Tentang Kerjasama Sistem Informasi Akademik

8 8 8 12 16 18 21 21 22 23 28 39 46 46 46 48 49 49 51 53 53 61

viii

2.4. Database dan SIM 2.5. Perancangan Database Untuk SIM 2.6. Verifikasi Struktur Database 2.7. Schema Database Universal 2.8. Fleksibilitas Rancangan Struktur Tabel Database 2.9. Pendekatan dalam Pengukuran Kualitas Informasi 2.10. Acuan Dalam Penilaian

65 65 76 77 80 82 83

BAB III. METODOLOGI PENELITIAN 3.1. Sumber Data Penelitian 3.2. Data Penelitian 3.2.1. Data Penelitian Kelompok Pertama 3.2.2. Data Penelitian Kelompok Kedua 3.2.3. Data Penelitian Kelompok Ketiga 3.3. Metode Pengumpulan Data 3.4. Langkah Penelitian

86 86 87 87 89 91 92 93

BAB IV. ANALISIS DAN PEMBAHASAN 4.1. Analisis 4.1.1. SIM di Perguruan Tinggi (SIPT) 4.1.2. Sistem Informasi Akademik (SIAKAD) di Perguruan Tinggi 4.1.3. Kebutuhan Informasi (dan Data) dan Nilai Rinci Data Untuk SIAKAD 4.1.4. Perubahan Kebutuhan Informasi (dan Data) Untuk SIAKAD 4.1.5. Langkah Analisis Fleksibilitas Rancangan Struktur Tabel Database 4.1.6. Data Yang Dianalisis 4.1.7. Penilaian Untuk Analisis Fleksibilitas Rancangan Struktur Tabel Database 4.1.8. Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database 4.2. Pembahasan 4.2.1. Statistik Tingkat Fleksibilitas Rancangan Struktur Tabel Database 4.2.2. Identifikasi Penyebab Rancangan Struktur Tabel Database Tidak Fleksibel 4.2.3. Kerangka Rancangan Struktur Tabel Database Yang Relatif Fleksibel Untuk SIAKAD 4.2.4. Usulan Panduan Perancangan Struktur Tabel Database Yang Fleksibel

99 99 99 128 153

BAB V. PERANCANGAN DAN IMPLEMENTASI SISTEM 5.1. Perancangan Sistem 5.1.1. Perancangan Model Sistem 5.1.2. Perancangan Model Data 5.1.3. Perancangan Database

251 251 251 282 291

ix

178 183 186 194 197 198 198 203 226 243

5.1.4. Perancangan HIPO (Hierarchy and Input-Process-Output) 5.1.5. Perancangan Dialog Layar Menu 5.1.6. Perancangan Input 5.1.7. Perancangan Output 5.1.8. Perancangan Teknologi 5.2. Implementasi Sistem 5.2.1. Implementasi Program Aplikasi 5.2.2. Implementasi Dialog Layar 5.2.3. Implementasi Input 5.2.4. Implementasi Output 5.2.5. Implementasi Teknologi 5.2.6. Pengujian Sistem 5.2.7. Kelemahan Sistem

308 312 318 325 336 337 337 337 345 351 353 354 355

BAB VI. KESIMPULAN DAN SARAN 6.1. Kesimpulan 6.2. Saran

356 356 360

DAFTAR PUSTAKA LAMPIRAN-LAMPIRAN

361 370

x

DAFTAR TABEL Tabel 2.1: Kebutuhan informasi menurut kategori keputusan Tabel 2.2: Perbedaan jenis keputusan pada tiga tingkat kegiatan manajemen Tabel 2.3: Kerangka Kerja Zachman Tabel 2.4: Istilah-istilah dalam terminologi RDBM Tabel 2.5: Aspek-aspek kualitas schema database berorientasi obyek yang sesuai untuk dilakukan pengukuran Tabel 2.6: Aspek-aspek kualitas schema database berorientasi obyek yang tidak sesuai untuk dilakukan pengukuran Tabel 4.1: Rambu-rambu Penyusunan Portofolio Tabel 4.2: Komponen Evaluasi Diri sebagai dimensi penilaian yang digunakan dalam Akreditasi Program Studi Tabel 4.3: Kebutuhan informasi (dan data) untuk penyusunan borang Tabel 4.4: Matrik penilaian Portofolio Akreditasi Institusi Perguruan Tinggi Tabel 4.5: Kebutuhan rinci data untuk SIAKAD Tabel 4.6: Perubahan pada nilai-nilai rinci data dalam SIAKAD Tabel 4.7: Mata_Kuliah (Medi, 2002, hal: 42) Tabel 4.8: Dosen (Medi, 2002, hal: 42-43) Tabel 4.9: Mahasiswa (Medi, 2002, hal: 43-44) Tabel 4.10: Mengajar (Medi, 2002, hal: 43) Tabel 4.11: Medis (Medi, 2002, hal: 44-45) Tabel 4.12: Pustaka (Medi, 2002, hal: 45) Tabel 4.13: Keamanan (Medi, 2002, hal: 45) Tabel 4.14: Beasiswa (Medi, 2002, hal: 45-46) Tabel 4.15: UPT (Medi, 2002, hal: 46) Tabel 4.16: Koperasi (Medi, 2002, hal: 46) Tabel 4.17: Mhs (Rahayuningsih, 2000, hal: 14) Tabel 4.18: Dosen (Rahayuningsih, 2000, hal: 15) Tabel 4.19: Makul (Rahayuningsih, 2000, hal: 15) Tabel 4.20: Krs (Rahayuningsih, 2000, hal: 15) Tabel 4.21: Bidang (Rahayuningsih, 2000, hal: 16) Tabel 4.22: Jurusan (Rahayuningsih, 2000, hal: 16) Tabel 4.23: FMHS (Yulia, 2000, hal: 38) Tabel 4.24: FJURUSAN (Yulia, 2000, hal: 39) Tabel 4.25: FDOSEN (Yulia, 2000, hal: 39) Tabel 4.26: FMTKDOSEN (Yulia, 2000, hal: 39) Tabel 4.27: FMTKULIAH (Yulia, 2000, hal: 39) Tabel 4.28: FPAKET (Yulia, 2000, hal: 40) Tabel 4.29: FKRS (Yulia, 2000, hal: 40) Tabel 4.30: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_09_001 Tabel 4.31: Daftar hasil analisis fleksibilitas rancangan struktur tabel database keseluruhan Tabel 4.32: Statistik hasil analisis fleksibilitas rancangan struktur tabel xi

Hal: 27 27 38 54 75 76 111 120 124 148 174 178 188 188 188 189 189 189 189 190 190 190 191 191 191 192 192 192 193 193 193 194 194 194 194 195 197 198

database berdasarkan tingkat fleksibilitas Tabel 4.33: Statistik hasil analisis fleksibilitas rancangan struktur tabel database berdasarkan pendidikan perancang Tabel 4.34: Statistik hasil analisis fleksibilitas rancangan struktur tabel database rekapitulasi keseluruhan Tabel 4.35: Daftar faktor rancangan struktur tabel tidak fleksibel pada setiap data yang dianalisis Tabel 4.36: Faktor umum penyebab rancangan struktur tabel fleksibel tidak fleksibel Tabel 4.37: Kerangka rancangan struktur tabel database yang relatif fleksibel untuk SIAKAD Tabel 5.1: TblUser.DB Tabel 5.2: TblPendidikan.DB Tabel 5.3: TblFleksibilitas.DB Tabel 5.4: TblData.DB Tabel 5.5: TblDataTabel.DB Tabel 5.6: TblDataAtribut.DB Tabel 5.7: TblHasil.DB Tabel 5.8: TblHasilDetail.DB Tabel 5.9: Diagram terinci (detailed diagram) HIPO untuk sistem

xii

200 201 205 223 230 306 306 306 307 307 307 307 308 311

DAFTAR GAMBAR Gambar 2.1: SIM sebagai integrasi organisasi, teknologi, dan manajemen Gambar 2.2: Pendekatan secara kontemporer pada SIM Gambar 2.3: Bentuk pengolahan data sentralisasi Gambar 2.4: Bentuk pengolahan data desentralisasi Gambar 2.5: Bentuk anatomi SIM Gambar 2.6: Hirarkhi pengendalian dalam jaringan kerja SIM Gambar 2.7: Beberapa fungsi organisatoris dalam organisasi Gambar 2.8: Kebutuhan informasi bagi manajemen berdasarkan sumbernya Gambar 2.9: Kebutuhan informasi bagi manajemen berdasarkan luasnya Gambar 2.10: Kebutuhan informasi bagi manajemen berdasarkan bentuknya Gambar 2.11: Kebutuhan informasi bagi manajemen berdasarkan horison waktu Gambar 2.12: Kebutuhan informasi bagi manajemen berdasarkan keadaan waktu Gambar 2.13: Kebutuhan informasi bagi manajemen berdasarkan tingkat kecermatan Gambar 2.14: Kebutuhan informasi bagi manajemen berdasarkan frekuensi pemakaian Gambar 2.15: Kebutuhan informasi bagi manajemen berdasarkan tingkat rincian Gambar 2.16: Karakteristik kebutuhan informasi Gambar 2.17: Paradigma prototyping Gambar 2.18: Rekayasa perangkat lunak SIM menggunakan model spiral Gambar 2.19: Aktivitas utama dalam model spiral Gambar 2.20: Kombinasi beberapa paradigma rekayasa perangkat lunak SIM Gambar 2.21: Simbol external entity Gambar 2.22: Simbol repeated external entity Gambar 2.23: Simbol data flow Gambar 2.24: Simbol process Gambar 2.25: Simbol data storage Gambar 2.26: Simbol repeated data storage Gambar 2.27: Pandangan terhadap database Gambar 2.28: Subsistem dalam gagasan kerjasama Sistem Informasi Akademik Gambar 2.29: Model database untuk kerjasama Sistem Informasi Akademik Gambar 2.30: File konvensional versus database Gambar 4.1: Analisis Sistemik mengenai komponen Evaluasi Diri Gambar 4.2: Alur kegiatan Sub Bidang Akademik di Perguruan Tinggi Gambar 5.1: Model logikal sistem dalam bentuk DFD level 0 atau konteks Gambar 5.2: Model logikal sistem dalam bentuk DFD level 1 Gambar 5.3: Model logikal sistem dalam bentuk DFD level 2 untuk Proses 1 Gambar 5.4: Model logikal sistem dalam bentuk DFD level 2 untuk Proses 2 Gambar 5.5: Model logikal sistem dalam bentuk DFD level 2 untuk Proses 3 xiii

Hal: 15 16 19 20 21 22 23 23 24 24 25 25 26 26 27 28 36 37 37 39 41 41 42 42 43 44 52 63 64 70 118 151 255 265 270 273 277

Gambar 5.6: Model logikal sistem dalam bentuk DFD level 2 untuk Proses 4 Gambar 5.7: Model logikal data untuk sistem dalam bentuk ER_D Gambar 5.8: Diagram Kerelasian Antar Relasi Hasil Transfromasi ER_D ke LRS Gambar 5.9: Visual Table of Contents HIPO sistem yang akan dikembangkan Gambar 5.10: Diagram ringkas (overview diagram) HIPO untuk sistem Gambar 5.11: Rancangan tampilan login ke sistem Gambar 5.12: Rancangan tampilan menu utama dengan login sebagai User Gambar 5.13: Rancangan tampilan sub menu Rancangan Struktur Tabel Database untuk pemakai dengan login sebagai User Gambar 5.14: Rancangan tampilan sub menu Laporan untuk pemakai dengan login sebagai User Gambar 5.15: Rancangan tampilan sub menu Informasi untuk pemakai dengan login sebagai User Gambar 5.16: Rancangan tampilan menu utama untuk pemakai dengan login sebagai Pakar Gambar 5.17: Rancangan tampilan sub menu Setup Data untuk pemakai dengan login sebagai Pakar Gambar 5.18: Rancangan tampilan sub menu Rancangan Sruktur Tabel Database untuk pemakai dengan login sebagai Pakar Gambar 5.19: Rancangan tampilan sub menu Laporan untuk pemakai dengan login sebagai Pakar Gambar 5.20: Rancangan tampilan sub menu Informasi untuk pemakai dengan login sebagai Pakar Gambar 5.21: Rancangan tampilan input data rancangan struktur tabel database untuk pemakai dengan login sebagai User Gambar 5.22: Rancangan tampilan input setup data tingkat fleksibilitas untuk pemakai dengan login sebagai Pakar Gambar 5.23: Rancangan tampilan input setup data pendidikan untuk pemakai dengan login sebagai Pakar Gambar 5.24: Rancangan tampilan input setup data User untuk pemakai dengan login sebagai Pakar Gambar 5.25: Rancangan tampilan input data rancangan struktur tabel database untuk pemakai dengan login sebagai Pakar Gambar 5.26: Rancangan tampilan input penilaian untuk pemakai dengan login sebagai Pakar Gambar 5.27: Daftar Rancangan Struktur Tabel Database Pendidikan Perancang S3 Gambar 5.28: Daftar Rancangan Struktur Tabel Database Pendidikan Perancang S2 Gambar 5.29: Daftar Rancangan Struktur Tabel Database Pendidikan Perancang S1 Gambar 5.30: Daftar Rancangan Struktur Tabel Database Pendidikan Perancang D3 Gambar 5.31: Daftar Rancangan Struktur Tabel Database Keseluruhan Gambar 5.32: Hasil Analisis Per Rancangan

xiv

282 291 297 309 310 312 314 314 315 315 316 317 317 318 318 320 321 322 322 324 325 326 327 327 327 328 328

Gambar 5.33: Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas SANGAT BAIK Gambar 5.34: Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas BAIK Gambar 5.35: Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas SEDANG Gambar 5.36: Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas BURUK Gambar 5.37: Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas SANGAT BURUK Gambar 5.38: Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Daftar Berdasarkan Pendidikan Perancang S3 Gambar 5.39: Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Daftar Berdasarkan Pendidikan Perancang S2 Gambar 5.40: Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Daftar Berdasarkan Pendidikan Perancang S1 Gambar 5.41: Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Daftar Berdasarkan Pendidikan Perancang D3 Gambar 5.42: Hasil Analisis Fleksibilitas Rancangan Struktur Tabel DatabaseDaftar Hasil Analisis Keseluruhan Gambar 5.43: Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Statistik Berdasarkan Tingkat Fleksibilitas Gambar 5.44: Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Statistik Berdasarkan Pendidikan Perancang Gambar 5.45: Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Statistik Rekapitulasi Keseluruhan Gambar 5.46: Implementasi tampilan login ke sistem Gambar 5.47: Implementasi tampilan menu utama dengan login sebagai User Gambar 5.48: Implementasi tampilan sub menu Rancangan Struktur Tabel Database untuk pemakai dengan login sebagai User Gambar 5.49: Implementasi tampilan sub menu Laporan untuk pemakai dengan login sebagai User Gambar 5.50: Implementasi tampilan sub menu Informasi untuk pemakai dengan login sebagai User Gambar 5.51: Implementasi tampilan menu utama untuk pemakai dengan login sebagai Pakar Gambar 5.52: Implementasi tampilan sub menu Setup Data untuk pemakai dengan login sebagai Pakar Gambar 5.53: Implementasi tampilan sub menu Implementasi Sruktur Tabel Database untuk pemakai dengan login sebagai Pakar Gambar 5.54: Implementasi tampilan sub menu Laporan untuk pemakai dengan login sebagai Pakar Gambar 5.55: Implementasi tampilan sub menu Informasi untuk pemakai dengan login sebagai Pakar

xv

329 330 330 331 331 332 332 333 333 334 334 335 335 337 338 339 339 340 341 342 343 344 345

Gambar 5.56: Implementasi tampilan input data rancangan struktur tabel database untuk pemakai dengan login sebagai User Gambar 5.57: Implementasi tampilan input setup data tingkat fleksibilitas untuk pemakai dengan login sebagai Pakar Gambar 5.58: Implementasi tampilan input setup data pendidikan untuk pemakai dengan login sebagai Pakar Gambar 5.59: Implementasi tampilan input setup data User untuk pemakai dengan login sebagai Pakar Gambar 5.60: Implementasi tampilan input data implementasi struktur tabel database untuk pemakai dengan login sebagai Pakar Gambar 5.61: Implementasi tampilan input penilaian untuk pemakai dengan login sebagai Pakar

xvi

346 347 348 349 350 351

DAFTAR LAMPIRAN Lampiran 1: DATA_09_002 Lampiran 2: DATA_09_003 Lampiran 3: DATA_09_004 Lampiran 4: DATA_09_005 Lampiran 5: DATA_09_006 Lampiran 6: DATA_09_007 Lampiran 7: DATA_09_008 Lampiran 8: DATA_09_009 Lampiran 9: DATA_09_010 Lampiran 10: DATA_08_002 Lampiran 11: DATA_08_003 Lampiran 12: DATA_08_004 Lampiran 13: DATA_08_005 Lampiran 14: DATA_08_006 Lampiran 15: DATA_08_007 Lampiran 16: DATA_08_008 Lampiran 17: DATA_08_009 Lampiran 18: DATA_08_010 Lampiran 19: DATA_06_002 Lampiran 20: DATA_06_003 Lampiran 21: DATA_06_004 Lampiran 22: DATA_06_005 Lampiran 23: DATA_06_006 Lampiran 24: DATA_06_007 Lampiran 25: DATA_06_008 Lampiran 26: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_09_002 Lampiran 27: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_09_003 Lampiran 28: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_09_004 Lampiran 29: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_09_005 Lampiran 30: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_09_006 Lampiran 31: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_09_007 Lampiran 32: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_09_008 Lampiran 33: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_09_009 Lampiran 34: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_09_010 xvii

Hal: 370 377 381 386 388 390 392 401 403 405 407 409 411 412 413 414 416 419 421 423 424 426 428 430 433 434 442 447 452 453 455 457 468 470

Lampiran 35: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_08_001 Lampiran 36: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_08_002 Lampiran 37: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_08_003 Lampiran 38: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_08_004 Lampiran 39: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_08_005 Lampiran 40: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_08_006 Lampiran 41: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_08_007 Lampiran 42: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_08_008 Lampiran 43: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_08_009 Lampiran 44: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_08_010 Lampiran 45: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_06_001 Lampiran 46: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_06_002 Lampiran 47: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_06_003 Lampiran 48: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_06_004 Lampiran 49: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_06_005 Lampiran 50: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_06_006 Lampiran 51: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_06_007 Lampiran 52: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_06_008 Lampiran 53: Contoh Output Daftar Rancangan Struktur Tabel Database Keseluruhan Lampiran 54: Contoh Output Daftar Rancangan Struktur Tabel Database berdasarkan Pendidikan Perancang S2 Lampiran 55: Contoh Output Daftar Rancangan Struktur Tabel Database berdasarkan Pendidikan Perancang S1 Lampiran 56: Contoh Output Daftar Rancangan Struktur Tabel Database berdasarkan Pendidikan Perancang D3 Lampiran 57: Contoh Output Hasil Analisis Fleksibilitas Rancangan Struktur

xviii

472 473 475 477 479 480 481 482 484 487 489 490 492 493 494 496 498 500 501 504 506 508 509

Tabel Database Per Rancangan Lampiran 58: Contoh Output Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas Lampiran 59: Contoh Output Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Daftar Berdasarkan Pendidikan Perancang Lampiran 60: Contoh Output Daftar Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Keseluruhan (Teringkas) Lampiran 61: Contoh Output Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Statistik Berdasarkan Tingkat Fleksibilitas Lampiran 62: Contoh Output Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Statistik Berdasarkan Pendidikan Perancang Lampiran 63: Contoh Output Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Rekapitulasi Keseluruhan

xix

513 514 515 516 517 518

INTISARI Fleksiblitas rancangan struktur tabel database merupakan salah satu faktor penentu kualitas SIM. Berdasarkan pada rancangan struktur logikal tabel database, penelitian ini bertujuan untuk melakukan analisis fleksibilitas rancangan struktur tabel database, menemukan faktor umum penyebab rancangan struktur tabel database tidak fleksibel, mengembangkan kerangka rancangan struktur tabel database yang fleksibel untuk SIAKAD, serta mengembangkan panduan perancangan struktur tabel database yang fleksibel. Penelitian dilakukan pada 28 rancangan yang terdiri atas 10 hasil Penelitian Tesis, 10 hasil Penelitian Skripsi, dan 8 hasil Penelitian Tugas Akhir, di dalamnya memuat 262 tabel dan 1.906 atribut. Analisis fleksibilitas rancangan struktur tabel database dilaukan dengan menggunakan pendekatan intuitive, dan selanjutnya tingkat fleksibilitas ditentukan berdasarkan pendekatan Penilaian Acuan Pokok/PAP. Berdasarkan hasil penelitian diketahui bahwa 3 rancangan termasuk SANGAT BAIK, memuat 49 tabel dan 443 atribut, terdiri atas 371 (=83,75%) atribut fleksibel dan 72 (=16,25%) atribut tidak fleksibel; 15 rancangan termasuk BAIK, memuat 119 tabel dan 664 atribut, terdiri atas 464 (=69,88%) atribut fleksibel dan 200 (=30,12%) atribut tidak fleksibel; 8 rancangan termasuk SEDANG, memuat 78 tabel dan 621 atribut, terdiri atas 316 (=50,89%) atribut fleksibel dan 305 (=49,11%) atribut tidak fleksibel; 1 rancangan termasuk BURUK, memuat 10 tabel dan 137 atribut, terdiri atas 49 (=35,77%) atribut fleksibel dan 88 (=64,23%) atribut tidak fleksibel; tidak ada rancangan yang termasuk kategori SANGAT BURUK; 1 rancangan tidak dapat dianalisis. Berdasarkan tingkat pendidikan perancang, 9 rancangan S2 yang memuat 126 tabel dan 1166 atribut, terdapat 735 (=63,04%) atribut fleksibel dan 431 (=36,96%) atribut tidak fleksibel, serta 1 rancangan tidak dapat dianalisis; 10 rancangan S1 yang memuat 65 tabel dan 383 atribut, terdapat 38 (=62,14%) atribut fleksibel dan 145 (=37,86%) atribut tidak fleksibel; 8 rancangan D3 yang memuat 65 tabel dan 316 atribut, terdapat 222 (=70,25%) atribut fleksibel dan 94 (=29,75%) atribut tidak fleksibel. Secara umum, rancangan struktur tabel database tidak fleksibel diakibatkan oleh faktor-faktor yang terkait dengan batasan/lingkup sistem, orientasi database, standarisasi data, kelengkapan data, pengelompokan data, penggunaan kode, penggunaan Primary Key/PK, serta penggunaan tabel logik. Kerangka rancangan struktur tabel database yang fleksibel untuk SIAKAD dapat dirancang dengan melibatkan beberapa sub sistem. Struktur tabel database yang fleksibel dapat diperoleh melalui 4 tahapan utama, yaitu 1) Analisis kebutuhan; 2) Perancangan; 3) Pengujian; dan 4) Implementasi. Kata-kata kunci: database, perancangan database, fleksibilitas, Sistem Informasi Akademik.

xx

ABSTRACT The flexibility of database structure design is one of decisive factor of MIS quality. Based on logical database structure, this research aim to do flexibility analyzes; finding the general factors that cause inflexible; developing the flexible database framework for Academic Information Systems; and developing guidance to get the flexible database structure. This research conducted 28 databases that consist of 10 theses, 10 scripts, and 8 final tasks, that contain 262 tables and 1906 attributes. The flexibility analyzes done by using intuitive approach, furthermore flexibility level grouped into 5 levels by using Criterion Reference Evaluation (PAP) approach. Base on research known, there are 3 database are VERY GOOD, it contain 49 tables and 443 attributes, consist of 371 (=83,75%) flexible attributes and 72 (=16,25%) inflexible attributes; 15 database are GOOD, it contain 119 tables and 664 attributes, consist of 464 (=69,88%) flexible attributes and 200 (=30,12%) inflexible attributes; 8 database are AVERAGE, it contain 78 tables and 621 attributes, consist of 316 (=50,89%) flexible attributes and 305 (=49,11%) inflexible attributes; 1 database is BAD, it contain 10 tables and 137 attributes, consist of 49 (=35,77%) flexible attributes and 88 (=64,23%) inflexible attributes; there is neither VERY BAD; and 1 database can’t be analyzed. Base on designer educational, 9 database of MA degree that contain 126 tables and 1166 attributes are consist of 735 (=63,04%) flexible attributes and 431 (=39,996%) inflexible attributes, and 1 design can’t be analyzed; 10 database of BA degree that contain 65 tables and 383 attributes are consist of 38 (=62,75%) flexible attributes and 145 (=37,*6%) inflexible attributes; and 8 database of diploma degree that contain 65 tables and 316 attributes are consist of 222 (=70,25%) flexible attributes and 94 (=29,75%) inflexible attributes. In generally, database structure is not flexible caused by many factors that related to system boundary; data orientation; data standardization, data completeness, data group arrangement, code utilizing, primary key determining, and logic table utilizing. The framework of flexible database for Academic Information Systems can be design with involves any sub systems. The flexible database structure can obtain by 4 major stages, i.e. 1) Requirement analyzes; 2) Design; 3) Testing; and 4) Implementation. Keywords: database, database design, flexibility, Academic Information System.

xxi

BAB I PENDAHULUAN

1.1. Latar Belakang Masalah Perkembangan teknologi informasi-komputer saat ini sudah mencapai pada tahap di mana ukurannya semakin kecil, kecepatannya semakin tinggi, namun harganya semakin murah dibandingkan dengan kemampuan kerjanya. Kondisi ini mendorong masyarakat berlomba-lomba memanfaatkan komputer sebagai alat bantu pengolahan data dengan cara membangun sistem pengolahan data terkomputerisasi untuk penyajian informasi, baik untuk keperluan pribadi maupun organisasinya. Sekalipun kurang tepat, sistem pengolahan data terkomputerisasi untuk penyajian informasi dalam suatu organisasi sering disebut sebagai Sistem Informasi Manajemen (SIM). Menurut Leavitt dan Whisler (dalam Davis dan Olson, 1987) suatu sistem organisasi terbentuk atas empat komponen atau subsistem yang saling berkaitan. Komponen-komponen yang dimaksud adalah tujuan, teknologi, struktur, serta sumberdaya manusia. Keempat komponen tersebut terintegrasi di dalam sebuah sistem yang disebut organisasi. Perubahan terhadap sebuah atau lebih komponen organisasi akan memerlukan perubahan pada komponen yang lain, dan pada gilirannya akan mempengaruhi seluruh organisasi. Kenyataan di lapangan menunjukkan, bahwa tidak semua organisasi berhasil mengimplementasikan SIM dengan baik. Eko Nugroho (1991) telah meneliti pengaruh struktur organisasi dan sumber daya manusia terhadap keberhasilan implementasi SIM dalam organisasi dalam penelitian tesisnya. Hasil

1

2

penelitian tersebut membuktikan, bahwa rata-rata persentase tingkat keberhasilan implementasi SIM, khususnya di DIY relatif rendah, hanya sekitar 60%. Penelitian tersebut juga telah membuktikan bahwa sumberdaya manusia (para teknisi sistem informasi, misalnya operator, analis sistem komputer, manajer unit pemrosesan data dan lain-lain, dan para pengguna sistem informasi) merupakan faktor penting yang mempengaruhi keberhasilan implementasi SIM. Selanjutnya, penelitian tersebut menyarankan adanya penelitian lebih lanjut pada aspek-aspek lain yang mempengaruhi keberhasilan implementasi SIM dalam organisasi, yaitu aspek organisasi, manajemen, perilaku, atau teknologi yang meliputi perangkat keras, perangkat lunak, rekayasa sistem, database. Dalam sumber referensi yang lain, Richardus Eko Indrajit (2000) menyatakan bahwa salah satu hasil audit pada implementasi SIM di Indonesia menunjukkan bahwa yang paling sering dijumpai adalah suatu kenyataan terjadinya fenomena “tambal sulam“ aplikasi SIM akibat terjadinya perubahan kebutuhan informasi (dan data) untuk memenuhi kepentingan manajemen. Dan menurut Zainal A. Hasibuan (2004) keberhasilan implementasi SIM di dunia hanya berkisar antara 20-30 % saja, dan khusus untuk Indonesia kemungkinan lebih kecil dari 20%. Organisasi yang mengimplementasikan SIM dapat bergerak dalam bidang apa saja, baik yang bergerak dalam bidang produksi barang maupun jasa, profit maupun non-profit, berskala kecil, menengah, maupun besar. Salah satu contoh organisasi yang telah mengimplementasikan SIM adalah Perguruan Tinggi (PT). Implementasi SIM dalam lingkungan PT utamanya digunakan untuk pengolahan data akademik yang sering dikenal dengan sebutan Sistem Informasi Akademik

3

(SIAKAD). Kegagalan implementasi SIM dan fenomena “tambal sulam” aplikasi SIM ternyata juga dapat terjadi dalam SIAKAD. Hal ini dapat dibuktikan dengan masih adanya PT yang telah melakukan pengembangan dan implementasi SIAKAD lebih dari satu dekade lamanya, namun hasilnya belum memuaskan hingga saat ini. Dalam suatu implementasi SIM, dapat dipahami bahwa kebutuhan informasi (dan data) bagi para pengguna untuk dapat dipastikan akan mengalami perubahan. Perubahan kebutuhan informasi (dan data) tersebut akan memerlukan penyesuaian pada komponen SIM lainnya, termasuk database. Perubahan kebutuhan informasi (dan data) terebut dapat terjadi, baik akibat perubahan yang terencana maupun yang tidak terencana sebelumnya. Perubahan kebutuhan informasi (dan data) akan memerlukan perubahan pada program aplikasi, nilainilai rinci data (data items) yang perlu disimpan dalam database atau bahkan perubahan pada struktur tabel database. Pada umumnya perubahan pada program aplikasi diperlukan karena adanya tuntutan kebutuhan tampilan keluaran yang lebih baik dan lebih menarik. Perubahan pada nilai-nilai rinci data (data items) dalam database dapat dilakukan dengan cara menambahkan atau menyesuaikan atribut dan/atau nilai-nilai rinci data (data items) dalam tabel database. Sedangkan perubahan rancangan struktur tabel database akan relatif mahal, lama, dan hanya dapat dilakukan dengan cara membongkar kembali definisi struktur tabel database, kerelasian antar data dalam database, batasan-batasan nilai pada atribut dan/atau nilai-nilai rinci data, dan sekaligus perubahan program aplikasi.

4

Salah satu peran database, yaitu sebagai sumber informasi bagi SIM, mengimplikasikan bahwa database yang digunakan harus mampu memenuhi kebutuhan berbagai informasi (dan data) bagi para penggunanya, baik untuk saat ini maupun mendatang. Tanpa mengabaikan sumber daya informasi yang lainnya, aspek rekayasa sistem, khususnya rancangan struktur tabel database akan sangat mempengaruhi keberhasilan implementasi SIM dalam organisasi. Rancangan struktur tabel database yang fleksibel akan meningkatkan kwalitas SIM, sebaliknya rancangan struktur tabel database yang kurang fleksibel akan berpotensi menimbulkan banyak masalah dan kegagalan implementasi SIM pada suatu organisasi, termasuk Perguruan Tinggi. Dengan demikian, maka struktur tabel database seharusnya dirancang sedemikian rupa sehingga memiliki sifat fleksibel terhadap perubahan kebutuhan informasi (dan data) untuk memenuhi kebutuhan kepentingan manajemen.

1.2. Rumusan Masalah Berdasarkan latar belakang permasalahan di atas, dapat dipahami bahwa fleksibilitas rancangan struktur tabel database untuk suatu SIM merupakan permasalahan penting. Oleh karena itu, maka rumusan masalah dalam penelitian ini adalah: (1) bagaimana melakukan analisis fleksibilitas rancangan struktur tabel database; (2) faktor-faktor apakah yang menjadi penyebab rancangan struktur tabel database tidak fleksibel; (3) seperti apakah kerangka rancangan struktur tabel database yang fleksibel; (4) bagaimana seharusnya merancang struktur tabel database agar diperoleh rancangan yang fleksibel.

5

1.3. Batasan Masalah Analisis dalam penelitian ini difokuskan pada aspek fleksibilitas rancangan struktur tabel database yang digunakan dalam SIAKAD, dengan batasan sebagai berikut: 1. Analisis dilakukan pada rancangan struktur tabel database hasil-hasil penelitian untuk SIAKAD yang pernah dilakukan dalam penelitian Tesis jenjang S2, Skripsi jenjang S1, dan Tugas Akhir jenjang D3. 2. Analisis dilakukan pada rancangan logikal, bukan implementasi pada DBMS, teknologi perangkat keras yang digunakan, maupun aplikasi. 3. Analisis dilakukan pada rancangan struktur tabel database untuk fungsi dan business rule yang berlaku secara umum dalam SIAKAD. 4. Program aplikasi akan dikembangkan untuk memberikan dukungan dalam proses analisis dalam penelitian ini.

1.4. Tujuan Penelitian Penelitian ini dilakukan dengan tujuan sebagai berikut: 1. Melakukan analisis fleksibilitas rancangan struktur tabel database terhadap berbagai kemungkinan perubahan kebutuhan informasi (dan data) bagi para pengguna pada hasil-hasil penelitian yang pernah dilakukan sebelumnya untuk implementasi dalam suatu SIAKAD. 2. Menemukan faktor-faktor yang menjadi penyebab rancangan struktur tabel database tidak fleksibel.

6

3. Mengembangkan sebuah kerangka rancangan struktur tabel database untuk SIAKAD yang relatif fleksibel dengan business rules yang umum digunakan di institusi Perguruan Tinggi. 4. Mengembangkan panduan perancangan struktur tabel database agar diperoleh rancangan yang fleksibel.

1.5. Manfaat Penelitian Penelitian ini memberikan informasi berupa hasil analisis fleksibilitas pada rancangan struktur tabel database untuk SIAKAD; faktor-faktor umum yang menjadi penyebab rancangan struktur tabel database tidak fleksibel; kerangka rancangan struktur tabel database yang fleksibel; usulan panduan umum perancangan struktur tabel database yang fleksibel. Hasil penelitian ini diharapkan menimbulkan kesadaran khususnya bagi para pengembang SIM, perancang database, dan organisasi yang akan mengubah metode pengolahan datanya dari manual atau elektromekanikal ke sistem yang berbasis komputer, agar terhindar dari kegagalan implementasi SIM.

1.6. Keaslian Penelitian Sejauh ini rancangan struktur tabel database (dan program aplikasi) untuk SIAKAD yang dihasilkan dalam penelitian-penelitian sebelumnya, dikembangkan dengan tujuan utama untuk membuktikan bahwa teknik dan metode yang diteliti dapat berjalan dengan benar untuk suatu fungsi yang spesifik. Rancangan struktur tabel

database

dalam

penelitian-penelitian

sebelumnya

dikembangkan

7

menggunakan

teknik

normalisasi,

Entity_Relationship

Model,

ataupun

berorientasi obyek, tanpa disertai analisis tentang aspek fleksibilitas rancangan struktur tabel database terhadap berbagai kemungkinan perubahan kebutuhan informasi (dan data) para pengguna. Analisis fleksibilitas rancangan struktur tabel database belum pernah dilakukan dalam penelitian sebelumnya.

1.7. Organisasi Laporan Penelitian Laporan penelitian ini disusun menjadi 5 (lima) bab yaitu: BAB I Pendahuluan, bagian ini berisi penjelasan tentang latar belakang permasalahan, rumusan permasalahan, batasan permasalahan, tujuan penelitian, manfaat penelitian, keaslian penelitian, serta organisasi Laporan Penelitian. BAB II Landasan Teori, bagian ini berisi penjelasan tentang landasan teori dan kajian pustaka yang melandasi penelitian ini. BAB III Metodologi Penelitian, bagian ini berisi penjelasan tentang sumber data penelitian, data penelitian, metode pengumpulan data, langkah penelitian. BAB IV Analisis dan Pembahasan, bagian ini berisi analisis fleksibilitas rancangan struktur tabel database untuk SIAKAD yang berhasil dikumpulkan dan pembahasannya. BAB V Perancangan dan Implementasi Sistem, bagian ini berisi penjelasan tentang perancangan dan implementasi sistem/program aplikasi yang dikembangkan. BAB VI Kesimpulan dan Saran, bagian ini berisi kesimpulan hasil penelitian dan saran yang terkait dengan hasil penelitian. Daftar Pustaka Lampiran

BAB II LANDASAN TEORI

2.1. Tinjauan Tentang Konsep SIM Menurut Raymond McLeod dan George Schell (2001), istilah Sistem Informasi Manajemen (SIM) telah populer dalam dunia bisnis sejak tahun 1964. Perkembangan teknologi komputer pada saat itu telah memberikan kesadaran baru bahwa aplikasi komputer harus diterapkan untuk tujuan utama menghasilkan informasi untuk pengambilan keputusan manajemen. Sejak itu, konsep SIM terus berkembang seiring perkembangan dan penggunaan teknologi komputer.

2.1.1. Definisi SIM Dalam lingkungan pengolahan data menggunakan komputer, sistem pengolahan data terkomputerisasi untuk penyajian informasi bagi keperluan manajemen dalam organisasi sering disebut sebagai “Sistem Informasi Manajemen/SIM” (Management Informations Systems/MIS), walaupun tidak semua orang menyetujui penggunaan istilah SIM tersebut. Istilah SIM telah didefinisikan oleh para pakar dengan cara yang berbeda-beda. Sebagian orang menyebutnya sebagai “Sistem Informasi” saja, dan sebagian yang lain menyebutnya sebagai “Pengolahan Data Elektronik/PDE” (Electronic Data Processing/EDP). Namun demikian menurut Eko Nugroho (1991), pada umumnya SIM merupakan istilah yang paling banyak dipergunakan. Gordon B. Davis (1987) mendefinisikan SIM sebagai integrasi sistem manusia-mesin yang menyediakan informasi untuk mendukung fungsi-fungsi

8

9

operasi, manajemen, dan pengambilan keputusan dalam sebuah organisasi. SIM menggunakan hardware dan software komputer; prosedur manual; model untuk analisis, perencanaan, kendali dan pembuatan keputusan; database. Dalam referensi yang lain, Raymond McLeod dan George Schell (2001) mendefinisikan SIM sebagai sistem berbasis komputer (Computer Based Information Systems/CBIS) yang menyediakan informasi kepada pengguna yang memiliki kebutuhan yang sama. SIM menyediakan informasi tentang masa lampau, saat ini, dan mendatang. Kesamaan kebutuhan dapat dipandang pada aspek area fungsional, tingkat kegiatan manajemen, dan manajer dan nonmanajer. Pengguna SIM terdiri atas entitas formal organisasi. Sedangkan menurut Efraim Turban dan Jay E. Aronson (2001), SIM mengumpulkan, memproses, menyimpan, menganalisis, dan menyebarkan informasi untuk kebutuhan khusus. SIM menerima input dan memproses data untuk menyediakan informasi untuk para pengambil keputusan dan membantu para pengambil keputusan dalam mengkomunikasikan hasil yang diperolehnya. Pengambil keputusan dapat bersifat individual atau kelompok individu. Konsep SIM terus berkembang sesuai dengan perkembangan teknologi komputer, dan kemudian dikenal sebagai evolusi CBIS (McLeod dan Schell, 2001). Evolusi CBIS bermula dari konsep pengolahan data tradisional-manual. Konsep ini mengalami perubahan dengan populernya istilah SIM pada tahun 1964. Pada saat itu perusahaan IBM telah mempromosikan konsep disk file penjualan dan terminal. Produk IBM tersebut mendorong munculnya istilah Otomatisasi Perkantoran (Office Automation/OA). Pada tahun 1971 lahir konsep

10

baru yang disebut Sistem Pendukung Pengambilan Keputusan/SPPK (Decision Support Systems/DSS). Buku-buku teks yang beredar saat itu juga telah membedakan antara istilah MIS dan DSS, dimana SIM digunakan untuk memenuhi keperluan organisasi/grup, sedangkan DSS untuk memenuhi keperluan individual yang bersifat spesifik. Dan, sejak tahun 1990-an berkembang konsep Kecerdasan Buatan (Artificial Intelligence/AI) dan Sistem Pakar (Expert Systems/ES). AI dan ES merupakan investasi besar dalam dunia bisnis. SIM dalam organisasi memiliki kemampuan untuk menyediakan informasi tentang masa lampau, saat ini, dan mendatang. Informasi tersebut ditampilkan dalam bentuk laporan periodik, laporan khusus, dan laporan simulasi. SIM menyediakan informasi untuk suatu area fungsional dalam organisasi. Menurut Raymmond McLeod dan George Shell (2001), pengguna informasi dapat meliputi para manajer, para personal non manajer, serta para personal dan organisasi dalam lingkungan perusahaan. Manajer memiliki tugas mengelola seluruh sumber daya yang ada dengan cara yang paling efektif, yaitu sumber daya fisik yang terdiri atas personal, material, mesin (termasuk fasilitas dan energi), dan uang; sumber daya konseptual berupa informasi (dan data) (McLeod dan Schell, 2001). Para manajer membutuhkan informasi (dan data) untuk melaksanakan tugas-tugasnya. Informasi (dan data) telah menjadi bagian sumber daya penting dan strategis, sehingga perlu dikelola dengan baik sebagaimana sumber daya fisik lainnya. Perhatian khusus pada pengelolaan informasi diperlukan karena adanya dua pengaruh, yaitu kompleksitas kegiatan bisnis yang semakin meningkat; kemampuan komputer yang semakin meningkat (McLeod dan Schell, 2001).

11

Pengelolaan informasi sebenarnya telah ada sejak lama, yang relatif baru adalah kemudahan memperoleh informasi yang mutakhir, akurat, dan tepat waktu. Teknologi komputer memungkinkan untuk memenuhi kebutuhan tersebut. SIM sebagai sebuah model memuat dua bagian utama, yaitu database dan Sistem Informasi Interorganisasi (Interorganizational Information Systems/IOS). Database dalam SIM menyediakan informasi (dan data) yang terkait dengan seluruh transaksi yang terjadi dalam organisasi. Sedangkan IOS menyediakan informasi yang terkait dengan lingkungan organisasi, misal pemasok, pelanggan, dan lain-lain (McLeod dan Schell, 2001). Contoh IOS adalah Sistem Informasi Eksekutif (Executive Information Systems/EIS), Sistem Informasi Pemasaran (Marketing Information Systems), Sistem Informasi Pabrikasi (Manufacturing Information Systems), dan lain-lain. EIS disediakan bagi para manajer pada tingkat perencanaan strategis. Sistem Informasi Pemasaran menyediakan informasi untuk penyelesaian masalah-masalah pemasaran, misal riset pasar, promosi, penentuan harga, dan lainnya. Sistem Informasi Pabrikasi menyediakan informasi untuk memecahkan masalah-masalah pabrikasi, misal teknik industri, produksi, persediaan, kualitas, beaya, dan lainnya. Secara fungsional, SIM dikembangkan untuk memenuhi kebutuhankebutuhan informasi dengan menekankan pada area fungsional penggunanya. Penyediaan informasi ini ditangani oleh software penyusun laporan (report writing software) yang mampu mencetak laporan-laporan periodik, khusus, dan perbedaan. Laporan periodik dibuat secara berkala dan terjadwal, laporan khusus

12

dibuat untuk kepentingan tertentu, sedangkan laporan perbedaan dibuat apabila terjadi sesuatu penyimpangan (McLeod dan Schell, 2001). Cara lain untuk memahami definisi SIM adalah dengan memahami dan menggabungkan tiga istilah penyusun SIM, yaitu sistem, informasi, dan manajemen. Dengan menggabungkan ketiga istilah tersebut, maka SIM dapat dipahami sebagai sekumpulan subsistem yang saling berhubungan; berkumpul bersama-sama dan membentuk satu kesatuan; saling berinteraksi dan bekerjasama antara bagian satu dengan yang lainnya dengan cara-cara tertentu untuk melakukan fungsi pengolahan data, menerima masukan (input) berupa data, mengolahnya (processing), dan menghasilkan keluaran (output) berupa informasi sebagai dasar pengambilan keputusan yang berguna dan mempunyai nilai nyata yang dapat dirasakan akibatnya baik pada saat itu juga maupun di masa mendatang; mendukung kegiatan operasional, manajerial, dan strategis; dengan memanfaatkan sumber daya yang ada guna mencapai tujuan.

2.1.2. Tinjauan Tentang SIM Menurut Gordon B Davis (1987), selain dengan meggunakan definisi, SIM dapat dijelaskan dengan menjelaskannya berdasarkan komponen fisik, fungsi pengolahan, dan fungsi keluaran. Berdasarkan komponen fisik, SIM terdiri atas komponen berikut (Davis, 1987): 1. Perangkat keras (hardware), meliputi piranti-piranti yang digunakan oleh sistem komputer untuk masukan dan keluaran (input/output device), penyimpan (memory), pengolah (processor), modem, dan lainnya.

13

2. Perangkat lunak (software), meliputi program-program komputer yang terdiri atas

sistem

operasi

(Operating

System/OS),

bahasa

pemrograman

(programming language), dan program aplikasi (application). 3. Berkas (file), merupakan sekumpulan data yang disimpan dengan cara-cara tertentu dalam media penyimpan sekunder (storage) sehingga dapat digunakan/ditampilkan kembali dengan mudah dan cepat. 4. Prosedur (procedure), meliputi prosedur pengoperasian SIM, manual, dan dokumen-dokumen prosedur lainnya. 5. Manusia (brainware), meliputi operator, programmer, system analyst, manajer sistem informasi, manajer pada tingkat operasional, manajer pada tingkat manajerial, manajer pada tingkat strategis, teknisi, serta personal lain yang terlibat di dalam SIM. Komponen pengolah dalam SIM mempunyai tugas utama melakukan transformasi data menjadi informasi, yaitu menerima data masukan, mengolah data masukan sesuai dengan aturan bisnis (business rule) yang digunakan, dan menghasilkan keluaran berupa informasi. Berdasarkan fungsi pengolahan, SIM mempunyai fungsi sebagai berikut (Davis, 1987): 1. Mengolah transaksi, yaitu mengolah data transaksi yang terjadi dalam sistem. Contoh transaksi adalah pemesanan, pengiringan pesanan, pembayaran, penjualan, pembelian, pengembalian (return) barang, dan lainnya. 2. Memelihara file histori, file histori memuat rekaman data transaksi yang telah terjadi pada masa lampau. File histori perlu dipelihara untuk memenuhi kebutuhan informasi di masa mendatang. File histori umumnya diperlukan

14

untuk

mengetahui

trend

data,

peramalan

(forecasting),

perencanaan

(planning), dan lainnya. Pemeliharaan file histori memerlukan suatu mekanisme tersistem yang mampu melindungi rekaman data agar terhindar dari kerusakan atau kehilangan, dan agar dapat diakses dengan cepat dan mudah saat diperlukan. 3. Menghasilkan keluaran, unit pengolah dalam SIM menghasilkan informasiinformasi penting yang dibutuhkan para pengguna. Keluaran sistem dapat ditampilkan dalam bentuk softcopy di layar monitor komputer, maupun dalam bentuk hardcopy yang dicetak di atas kertas atau media lainnya. Keluaran SIM dapat berupa dokumen, laporan, atau jawaban atas pertanyaan yang ditampilkan secara rutin maupun adhoc. 4. Interaksi user-pengolah, merupakan mekanisme yang memungkinkan user berinteraksi dengan sistem. Interaksi user-pengolah dapat berupa tampilan dialog, dimana dalam dialog itu user dapat menjawab pertanyaan, memilih proses, atau aktivitas lain selama mengoperasikan sistem. Berdasarkan fungsi keluaran, SIM menghasilkan keluaran berupa (Davis, 1987): 1. Dokumen transaksi, yaitu dokumen yang dihasilkan sebagai bukti transaksi, misal faktur pemesanan, nota penjualan, nota pembelian, kuitansi pembayaran, bukti pengiriman barang, dan lainnya. 2. Laporan rutin, yaitu laporan yang dicetak secara rutin, misal laporan pembelian, penjualan, atau lainnya.

15

3. Jawaban atas pertanyaan rutin, yaitu jawaban atas pertanyaan rutin yang diperlukan oleh para pengguna, baik berupa informasi singkat yang ditampilkan di layar atau lainnya, misal jumlah stok barang yang ditampilkan secara periodik, atau lainnya. 4. Laporan adhoc, yaitu laporan-laporan yang disajikan pada waktu yang tidak tertentu, misal laporan pembelian perlu dicetak saat ada inspeksi pimpinan. 5. Jawaban atas pertanyaan adhoc, yaitu jawaban atas berbagai pertanyaan yang disajikan pada setiap saat diperlukan. 6. Dialog user-machine, yaitu sarana yang memungkinkan user berinteraksi dengan peralatan yang digunakan oleh sistem, dapat berupa tampilan di layar yang menunjukkan pesan peringatan atau progress sistem, misal pesan “printer belum siap”, “kertas habis”, dan lainnnya. Dalam referensi yang lain, Loudon Loudon (2004) menyatakan bahwa SIM merupakan integrasi dari tiga buah komponen, yaitu organisasi, teknologi, dan manajemen, seperti digambarkan pada Gambar 2.1.

Gambar 2.1: SIM sebagai integrasi organisasi, teknologi, dan manajemen Loudon Loudon (2004) juga menyatakan bahwa pendekatan secara kontemporer untuk menjelaskan SIM dapat ditinjau dari sisi teknik dan sisi

16

perilaku. Pendekatan sisi teknik pada SIM dapat ditinjau dari aspek ilmu manajemen, ilmu komputer, dan riset operasi. Sedangkan pendekatan dari sisi perilaku pada SIM dapat ditinjau dari aspek psikologi, ekonomi, dan sosiologi. Gambaran pendekatan kontemporer pada SIM ini ditunjukkan pada Gambar 2.2.

Gambar 2.2: Pendekatan secara kontemporer pada SIM

2.1.3. Tujuan SIM Suatu SIM dikembangkan untuk tujuan-tujuan tertentu sesuai dengan kebutuhan organisasi. SIM yang sederhana dikembangkan dengan tujuan untuk memenuhi kebutuhan informasi (dan data) unit-unit fungsional organisasi. SIM seperti ini mendukung pengolahan transaksi pada tingkat operasional dan sedikit dukungan pada tingkat manajerial. SIM yang lebih kompleks menangani pengolahan data transaksi pada tingkat operasional dan penekanan pada tingkat manajerial. SIM seperti ini terdiri atas modul-modul yang masing-masing menangani pengolahan data pada unit fungsional tertentu. Sedangkan SIM yang kompleks dikembangkan untuk menangani kebutuhan informasi (dan data) untuk semua pengguna pada semua tingkat kegiatan manajemen, pada semua unit fungsional yang ada. Oleh karena itu, maka setiap SIM yang dikembangkan oleh

17

organisasi dapat mempunyai tujuan yang spesifik. Namun demikian, menurut Charles S. Parker (1989), secara umum SIM mempunyai tujuan sebagai berikut: 1. Efisiensi operasional (operational efficiency). SIM mengerjakan pekerjaan rutin secara lebih cepat dan mudah. Efisiensi dicapai berkat prestasi Sistem Pengolahan Transaksi (Transaction Processing Systems/TPS), misal Sistem Produksi, Sistem Pemasaran, Sistem Persediaan, dan lain-lain. 2. Efektifitas fungsional (functional effectiveness). Efektifitas merupakan target dari SPPK (DSS). SPPK memberikan informasi khusus yang tersaring dan model untuk simulasi yang ditampilkan secara adhoc setiap kali dibutuhkan. SPPK membantu manajer agar dapat mengambil keputusan secara efektif. 3. Perbaikan pelayanan (better service). Perbaikan pelayanan dapat dilakukan, misal penggunaan mesin ATM, Sistem Reservasi, dan lain-lain. 4. Peningkatan kreasi dan produk (product creation and improvement). SIM mengintegrasikan

keseluruhan

informasi

dalam

organisasi

sehingga

mendukung kreasi dan peningkatan produk, misal bank melebarkan usahanya pada bidang asuransi, pelayanan ONH, travel agency, dan lain-lain. 5. Mengubah basis persaingan (altering the basis of competition). SIM memudahkan perolehan informasi akurat secara cepat dan mudah, sehingga manajer dapat mengetahui kondisi lingkungan pesaing dan pasar potensial, dan dapat mengalihkan basis persaingannya kepada pasar potensial. 6. Spotting

and

taking

advantage

of

opportunities.

Keberadaan

SIM

memungkinkan untuk melakukan pemusatan perhatian untuk memperoleh keuntungan dari kesempatan-kesempatan yang ada.

18

7. Client lock in- competitor lock out. Dengan SIM maka kualitas layanan kepada konsumen dapat ditingkatkan, sehingga konsumen merasa enggan untuk berpindah ke organisasi lain.

2.1.4. Pengolahan Data Dalam SIM Menurut Gordon B. Davis (1987), pengolahan data adalah serangkaian operasi atas informasi yang direncanakan. Proses pengolahan data dapat meliputi sebagian atau seluruh unsur pengolahan data, yaitu pengumpulan data (data capturing);

pembacaan

(reading);

pemeriksaan

(verifying);

perekaman

(recording); pengklasifikasian (classifying); pengurutan (sorting); peringkasan (sumarizing); perhitungan (calculating); perbandingan (comparing); pemindahan (transmitting); penampilan kembali (retrieving); penggandaan (reproduction); penyebarluasan (distribution). Menurut Gordon B. Davis (1987), metode pengolahan data dalam SIM dapat dibedakan menjadi empat kategori, yaitu metode manual; metode elektromekanikal (electromechanical); metode sistem warkat (punched-card equipment); metode elektronik komputer (electronic computer). Oleh karena itu, analyst system perlu menetapkan metode pengolahan data yang tepat bagi organisasi agar mampu memenuhi persyaratan pengolahan dan kemampuan mencapai hasil yang diinginkan. Pemilihan metode pengolahan data perlu mempertimbangkan volume unsur data yang dimuat; kompleksitas operasi pengolahan data; batasan waktu pengolahan; tuntutan perhitungan.

19

Menurut Gordon B. Davis (1987), bentuk implementasi sistem pengolahan data dalam struktur organisasi dapat dibedakan menjadi tiga, yaitu sentralisasi, desentralisasi, dan terdistribusi. Dalam pengolahan data sentralisasi, operasi pengolahan data dilaksanakan oleh suatu bagian terpisah dalam struktur organisasi yang sering disebut Pengolahan Data Elektronik/PDE/EDP, atau dapat juga dilakukan oleh suatu biro jasa atau perusahaan di luar organisasi yang memberikan layanan pengolahan data; fasilitas pembagian waktu bersama (timesharing) yang dibeli/disewa dari perusahaan lain; suatu susunan manajemen fasilitas dimana suatu perusahan mengambil alih pelaksanaan operasi pengolahan data dalam suatu organisasi. Sentralisasi pengolahan data mempunyai keuntungan antara lain penghematan hardware dan pengadaan personalia; penghematan karena meniadakan pengembangan sistem yang ganda; manfaat karena standarisasi; manfaat karena sistem yang seragam (Davis, 1987). Bentuk pengolahan data sentralisasi ditunjukkan oleh Gambar 2.3.

Perencanaan strategis Perencanaan taktis & pengendalian manajemen Perencanaan & pengendalian operasional Produksi

Pemasaran

...

Personalia

Departemen Pengolahan Data Elektronik

Gambar 2.3: Bentuk pengolahan data sentralisasi

20

Dalam bentuk pengolahan data terdesentralisasi, operasi pengolahan data dilakukan oleh bagian organisasi yang bersifat fungsional otonom, misal akuntansi, keuangan, personalia, dan lainnya. Faktor pendukung desentralisasi pengolahan data antara lain adalah pelayanan yang semakin baik karena kepekaan terhadap kondisi lokasi; kebijakan desentralisasi dalam manajemen; kelangkaan kesamaan fungsi di antara unit organisasi mempersulit standarisasi (Davis, 1987). Bentuk pengolahan data desentralisasi ditunjukkan oleh Gambar 2.4.

Perencanaan strategis Perencanaan taktis & pengendalian manajemen Perencanaan & pengendalian operasional Unit pengolah data Unit pengolah data … Unit pengolah data Bagian Produksi Bagian Pemasaran Bagian Personalia

Gambar 2.4: Bentuk pengolahan data desentralisasi 1. Dalam bentuk pengolahan data terdistribusi data-data disebar dan diolah oleh bagian-bagian yang terpisah, dimana bagian-bagian tersebut secara logik disatukan kembali dan diawasi oleh bagian yang lebih tinggi. Keuntungan bentuk pengolahan data terdistribusi antara lain adalah dapat meminimalkan beaya-beaya; mempersingkat waktu respon untuk memperoleh data-data; pengontrolan pada data-data kritis secara lebih cermat; kemampuan back up data yang efektif (Davis, 1987).

21

2.1.5. Unsur-Unsur Penting Agar SIM Efektif Agar SIM dalam organisasi dapat beroperasi secara efektif, maka proses pengembangan SIM perlu memperhatikan unsur penting, meliputi data yang dibutuhkan; kapan data dibutuhkan; siapa yang membutuhkan; di mana data dibutuhkan; dalam bentuk apa data dibutuhkan; prioritas yang diberikan dari bermacam data; prosedur/mekanisme yang digunakan untuk memproses data; bagaimana pengaturan umpan balik; mekanisme evaluasi yang digunakan.

2.1.6. Bentuk Anatomi SIM Bentuk anatomi SIM dapat digambarkan seperti ditunjukkan pada Gambar 2.5 (Davis, 1987). Pada gambar tersebut, contoh data masukan adalah data bahan baku, harga produk, beaya tenaga kerja, dan lain-lain. Contoh data operasi adalah angka produksi, beaya mesin, pekerjaan proses, dan lain-lain. Sedangkan contoh data keluaran adalah tingkat investasi, tanggal pengiriman, dan lainnya. Manajemen (Keputusan/Kontrol)

Rencana Standar (Analisis)

Data masukan

Data operasi

Data keluaran

Pencatat data

Pencatat data

Pencatat data

Pengolahan

Gambar 2.5: Bentuk anatomi SIM

22

2.1.7. Jaringan Kerja SIM SIM bekerja sebagai sebuah jaringan kerja yang tersusun atas sejumlah bagian, masing-masing tersusun atas perencanaan strategi dan pengendalian manajemen; fungsi operasional; unit fungsional (Davis, 1987). Hirarkhi pengendalian dalam jaringan kerja SIM ditunjukkan oleh Gambar 2.6. Perencanaan Strategis & Pengendalian Manajemen

Fungsi Operasional Pengendalian manajemen atas fungsi

Fungsi Operasional Pengendalian manajemen atas fungsi

Fungsi Operasional Pengendalian manajemen atas fungsi

Pengendalian operasional

Pusat keputusan Pusat kegiatan

Pusat keputusan Pusat kegiatan

Pusat keputusan Pusat kegiatan

Gambar 2.6: Hirarkhi pengendalian dalam jaringan kerja SIM Konsep jaringan kerja SIM memberikan implikasi, antara lain SIM didesain untuk menyediakan informasi bagi setiap unit fungsional; SIM untuk unit fungsional yang saling berhubungan dapat dikelompokkan ke dalam suatu subsistem fungsi operasional yang melayani kelompok itu; hubungan antar unit fungsional dapat disederhanakan dengan pemakaian hubungan informasi antar kelompok dan pemakaian file penyangga (Davis, 1987). Pada kenyataannya, fungsi-fungsi organisatoris pada organisasi tidak pernah seragam, namun umumnya meliputi fungsi keuangan, SDM, layanan informasi, pabrikasi, dan pemasaran. Fungsi-fungsi organisatoris yang bersifat umum tersebut ditunjukkan oleh Gambar 2.7 (McLeod dan Schell, 2001).

23

Gambar 2.7: Beberapa fungsi organisatoris dalam organisasi

2.1.8. Karakteristik Kebutuhan Informasi dalam SIM Pada hakekatnya, kebutuhan informasi pada setiap setiap tingkat manajemen adalah berbeda-beda, yaitu tergantung pada fungsi operasional, kegiatan manajemen, dan pembuatan keputusan (McLeod dan Schell, 2001). Gambar 2.8 menampilkan perbedaan informasi yang dibutuhkan pada setiap tingkat manajemen berdasarkan sumbernya. Tingkat manajemen yang lebih tinggi lebih banyak menggunakan informasi yang bersumber dari lingkungan, sebaliknya tingkat yang lebih rendah lebih banyak menggunakan informasi yang bersumber dari internal organisasi (McLeod dan Schell, 2001).

Gambar 2.8: Kebutuhan informasi bagi manajemen berdasarkan sumbernya

24

Gambar 2.9 menampilkan perbedaan informasi yang dibutuhkan pada setiap tingkat manajemen berdasarkan luasnya. Tingkat manajemen yang lebih tinggi lebih banyak menggunakan informasi yang luas, sebaliknya tingkat yang lebih rendah lebih banyak menggunakan informasi yang sangat jelas dan sempit (McLeod dan Schell, 2001).

Gambar 2.9: Kebutuhan informasi bagi manajemen berdasarkan luasnya Gambar 2.10 menampilkan perbedaan informasi yang dibutuhkan oleh setiap tingkat manajemen berdasarkan bentuknya. Tingkat manajemen yang lebih tinggi lebih banyak menggunakan informasi teringkas, sebaliknya tingkat yang lebih rendah lebih banyak menggunakan informasi terinci (McLeod dan Schell, 2001).

Gambar 2.10: Kebutuhan informasi bagi manajemen berdasarkan bentuknya Gambar 2.11 menampilkan perbedaan informasi yang dibutuhkan pada setiap tingkat manajemen berdasarkan horison waktu. Tingkat manajemen yang lebih

25

tinggi lebih banyak menggunakan informasi terkait dengan masa depan, sebaliknya tingkat yang lebih rendah lebih banyak menggunakan informasi histori (McLeod dan Schell, 2001).

Gambar 2.11: Kebutuhan informasi bagi manajemen berdasarkan horison waktu Gambar 2.12 menampilkan perbedaan informasi yang dibutuhkan oleh setiap tingkat manajemen berdasarkan keadaan waktu. Tingkat manajemen yang lebih tinggi lebih banyak menggunakan informasi yang terkait dengan keadaan waktu yang lama, sebaliknya tingkat yang lebih rendah lebih banyak menggunakan informasi yang sangat baru (McLeod dan Schell, 2001).

Gambar 2.12: Kebutuhan informasi bagi manajemen berdasarkan keadaan waktu Gambar 2.13 menampilkan perbedaan informasi yang dibutuhkan oleh setiap tingkat manajemen berdasarkan tingkat kecermatannya. Tingkat manajemen yang lebih tinggi lebih banyak menggunakan informasi dengan tingkat kecermatan

26

yang rendah, sebaliknya tingkat yang lebih rendah lebih banyak menggunakan informasi dengan tingkat kecermatan tinggi (McLeod dan Schell, 2001).

Gambar 2.13: Kebutuhan informasi bagi manajemen berdasarkan tingkat kecermatan Gambar 2.14 menampilkan perbedaan informasi yang dibutuhkan oleh masing-masing tingkat manajemen berdasarkan frekuensi pemakaian. Tingkat manajemen yang lebih tinggi jarang menggunakan informasi yang sama, sebaliknya tingkat yang lebih rendah lebih sering menggunakan informasi yang sama (McLeod dan Schell, 2001).

Gambar 2.14: Kebutuhan informasi bagi manajemen berdasarkan frekuensi pemakaian Gambar 2.15 menampilkan perbedaan informasi yang dibutuhkan oleh masing-masing tingkat manajemen berdasarkan tingkat rincian. Tingkat manajemen yang lebih tinggi lebih banyak menggunakan informasi teringkas,

27

sebaliknya tingkat yang lebih rendah lebih banyak menggunakan informasi terinci (McLeod dan Schell, 2001).

Gambar 2.15: Kebutuhan informasi bagi manajemen berdasarkan tingkat rincian Secara ringkas, kebutuhan informasi menurut kategori keputusan ditunjukkan oleh Tabel 2.1, sedangkan Tabel 2.2 menunjukkan perbedaan jenis keputusan pada tiga tingkat kegiatan manajemen (Davis, 1987). Tabel 2.1: Kebutuhan informasi menurut kategori keputusan Perencanaan & pengendalian operasional Sumber Sebagian besar internal Luasnya Sangat jelas, sempit Tingkat agregasi Sangat terinci Horison waktu Historis Keadaan waktu Sangat baru Kecermatan Tinggi Frek. pemakaian Sangat tinggi Sumber: Gordon B. Davis, 1987 Ciri Informasi

Perencanaan taktis & pengendalian manajemen

Perencanaan strategis Eksternal Sangat luas Agregat Masa depan Agak lama Rendah Tidak sering

Tabel 2.2: Perbedaan jenis keputusan pada tiga tingkat kegiatan manajemen Tingkat Perencanaan strategis

Catatan Penetapan tujuan, definisi sasaran, kebijakan, pedoman umum, yang mengarahkan alur untuk organisasi, misal: bidang usaha, strategi pasar. Perencanaan taktis & Perolehan sumber daya, taktik perolehan, lokasi, produk baru, pemakaian pengendalian manajemen anggaran, laporan perbedaan (variance) Perencanaan & Pendayagunaan fasilitas & sumber daya yang ada untuk menyelenggarakan pengendalian operasional kegiatan Sumber: Gordon B. Davis, 1987

Dalam sumber referensi yang lain, David Wilson (1993) mendeskripsikan karakteristik kebutuhan informasi seperti digambarkan pada Gambar 2.16.

28

Manajer Tertinggi

Manajer Menengah

Manajer Terrendah

Eskternal

Eskternal & Eksternal

Iinternal

Jarang

Kadang-kadang

Jarang

Lama bertahun-tahun

Sedang minggu/bulan

Singkat hari/jam

Horison waktu

Masa depan

Masa depan & histori

Histori

Lingkup

Tak terbatasi

Terbatasi

Sangat terbatas

Tidak terstruktur

Terstruktur

Sangat terstruktur

Sumber informasi Frekuensi penggunaan Skala waktu

Hakikat keputusan

Gambar 2.16: Karakteristik kebutuhan informasi

2.1.9. Metodologi Pengembangan SIM Menurut J. L. Whitten dan L. D. Bentley (1998), metodologi merupakan proses yang digunakan untuk pengembangan sistem. Seluruh metodologi pengembangan SIM diarahkan dari sebuah sistem logik proses pemecahan masalah yang sering disebut siklus hidup pengembangan sistem (system development life cycle/SDLC), kadang-kadang juga disebut siklus hidup pengembangan aplikasi (application development life cycle). SDLC merupakan proses logik membangun SIM dan aplikasi-aplikasi komputer untuk memecahkan masalah yang dilakukan oleh systems analyst, software engineer, programmer, dan end-user. Sebuah metodologi adalah implementasi fisik pada siklus hidup logik yang menggabungkan langkah demi langkah aktivitas untuk setiap tahapan; perseorangan dan kelompok yang menjadi pelaku dalam setiap aktivitas; kemampuan menghasikan dan standard kwalitas untuk setiap aktivitas; penggunaan alat-alat dan teknik-teknik untuk setiap aktivitas (Whitten dan

29

Bentley, 1998). Metodologi yang benar akan memberikan arah pada SDLC. Selanjutnya, J. L. Whitten & L. D. Bentley (1998) menyampaikan delapan prinsip pengembangan sistem, yaitu: 1. Prinsip 1: Libatkan owner dan user semaksimal mungkin. 2. Prinsip 2: Gunakan pendekatan penyelesaian masalah. 3. Prinsip 3: Susun tahapan dan aktivitas. 4. Prinsip 4: Susun standard untuk konsistensi pengembangan dan dokumentasi. 5. Prinsip 5: Tetapkan sistem sebagai investasi modal. 6. Prinsip 6: Jangan takut membatalkan atau merevisi lingkup sistem. 7. Prinsip 7: Sistem dipecah-pecah agar lebih mudah dikuasai. 8. Prinsip 8: Sistem dirancang untuk dapat tumbuh dan berubah. Menurut J. L. Whitten dan L. D. Bentley (1998), pendekatan penyelesaian masalah, baik untuk analisis pada sistem manual, sistem terkomputerisasi, maupun aplikasi, dapat mengunakan sebuah kerangka kerja PIECES, yaitu meliputi (Whitten dan Bentley, 1998): 1. Permasalahan kinerja (Performace=P), yaitu: a. Throughput, merupakan jumlah pekerjaan yang dapat diselesaikan dalam periode waktu tertentu; b. Response time, merupakan rata-rata penundaan yang terjadi antara saat permintaan transaksi dan respon yang diberikan terhadap transaksi. 2. Permasalahan informasi (Information=I) (dan data), yaitu: a. Output, meliputi: (1) Kekurangan pada beberapa informasi, (2) Kekurangan pada informasi penting; (3) Kekurangan pada informasi yang relevan; (4)

30

Terlalu banyak informasi (information overload); (5) Informasi dalam format yang tidak berguna; (6) Informasi tidak akurat; (7) Informasi yang sulit diproduksi; (8) Informasi tidak sesuai urutan waktu penggunaan. b. Input, meliputi: (1) Data tidak tertangkap; (2) Data tidak ditangkap pada waktu yang tepat; (3) Data ditangkap secara tidak akurat, memuat kesalahan; (4) Data sulit ditangkap; (5) Data ditangkap secara berulang; (6) Terlalu banyak data yang ditangkap; (7) Data tidak sah ikut ditangkap. c. Penyimpanan data, meliputi: (1) Data disimpan berulang dalam beberapa file dan/atau database; (2) Data disimpan tidak akurat; (3) Data disimpan secara tidak aman; (4) Data tidak diorganisasi dengan baik; (5) Data tidak fleksibel, sulit menemukan kebutuhan informasi baru dari data yang tersimpan; (6) Data tidak dapat diakses. 2. Permasalahan ekonomis (Economic=E), yaitu: a. Beaya-beaya, meliputi: (1) Beaya tidak terduga; (2) Beaya di luar kemampuan sumber daya yang tersedia; (3) Beaya terlalu tinggi. b. Keuntungan, meliputi: (1) Pangsa pasar baru dapat dieksplorasi; (2) Pasar yang ada saat ini dapat ditingkatkan; (3) Order dapat ditingkatkan. 3. Permasalahan kontrol (Control=C) dan keamanan, yaitu: a. Keamanan atau kontrol terlalu minim, yaitu: (1) Data input tidak diedit cukup memadai; (2) Pelanggaran etika pada data atau informasi; (3) Data yang disimpan secara berulang tidak konsisten pada file-file atau database yang berbeda; (4) Kebijakan privacy data dilanggar; (5) Kesalahan proses (baik karena manusia, mesin, atau software); (6) Kesalahan pengambilan

31

keputusan. b. Keamanan atau kontrol terlalu banyak, yaitu: (1) Birokrasi memperlambat sistem; (2) Kontrol membuat para pelanggan atau karyawan. (3) Kontrol yang ketat menyebabkan penundaan proses. 4. Permasalahan efisiensi (Eficiency=E), yaitu: a. Pemborosan waktu pada orang, mesin, atau komputer, meliputi: (1) Data dinputkan atau di-copy secara berulang; (2) Data diproses secara berulang; (3) Informasi di-generate secara berulang. b. Pemborosan material dan suplai pada orang, mesin, atau komputer. c. Terlalu banyak upaya untuk tugas-tugas. d. Material terlalu banyak diperlukan untuk tugas-tugas. 5. Permasalahan pelayanan (Service=S), yaitu: a. Sistem memberikan hasil yang tidak akurat; b. Sistem memberikan hasil yang tidak konsisten; c. Sistem memberikan hasil yang tidak dapat dipercaya (unreliable); d. Sistem sulit dipelajari; e. Sistem sulit digunakan; f. Sistem janggal digunakan; g. Sistem tidak fleksibel untuk hal-hal atau situasi-situasi baru; h. Sistem tidak fleksibel untuk perubahan; i. Sistem tidak kompatibel dengan sistem lain; j. Sistem tidak dikoordinasikan dengan sistem-sistem lain.

2.1.9.1. System Development Life Cycle/SDLC Metodologi pengembangan sistem menurut J. L. Whitten dan L. D. Bentley (1998), meliputi 8 (delapan) tahap, yaitu: 1. Tahap survey, tahap ini memiliki tiga kegunaan, yaitu:

32

a. Menjawab pertanyaan apakah proyek memiliki nilai; b. Mendefinisikan lingkup proyek dan permasalahan, peluang, dan arah yang ingin dicapai; c. Menentukan tim dan peserta, anggaran, dan jadwal untuk proyek. 2. Tahap study, tahap ini memiliki tiga kegunaan, yaitu: a. Pemahaman kembali permasalahan bisnis oleh tim proyek; b. Menentukan permasalahan dipecahkan dengan cara terbaik; c. Menentukan sistem dapat dikembangkan dengan cara terbaik. 3. Tahap definition, tahap ini berguna untuk mengidentifikasi data, proses, antarmuka, dan kebutuhan geografis untuk pengguna sistem baru. 4. Tahap targeting, tahap ini berguna untuk mengidentifikasi kandidat solusi, menganalisis kandidat solusi, dan merekomendasikan solusi yang ditargetkan akan dirancang dan diimplementasikan. 5. Tahap purchasing, tahap ini berguna untuk riset pasar teknologi informasi, mengumpulkan proposal dari penjual, dan merekomendasikan proposal yang memenuhi kebutuhan bisnis dan teknologi informasi ke manajemen. 6. Tahap design, tahap ini berguna untuk mentransformasikan kebutuhan bisnis yang diperoleh pada tahap definisi ke dalam bentuk rancangan teknis. 7. Tahap construction, tahap ini berguna untuk membangun dan menguji fungsional sistem yang memenuhi kebutuhan bisnis dan perancangan, dan untuk mengimplementasikan antarmuka antara sistem lama dan baru. 8. Tahap delivery, tahap ini berguna untuk meng-install, menyebar, dan menempatkan sistem baru ke dalam operasi atau produksi.

33

Dalam sumber referensi yang lain, Raymond McLeod, Jr. dan George Schell (2001) menjelaskan bahwa dalam siklus hidup sistem (Systems Life Cycle/SLC), metodologi diartikan sebagai cara yang direkomendasikan untuk melakukan sesuatu hal. Dalam aplikasi, pendekatan pada tugas pengembangan sistem dengan menggunakan sistem berbasis komputer seringkali disebut pendekatan “air terjun” (waterfall) yang meliputi: (1) Perencanaan (planning); (2) Analisis (analysis); (3) Perancangan (design); (4) Implementasi (implementation); (5) Penggunaan (use). SDLC adalah ungkapan yang mencakup perencanaan, analisis, perancangan, dan implementasi tahapan pada siklus hidup sistem. Personal yang terlibat dalam SDLC meliputi para personal dalam SIM, pengguna, dan spesialis yang dapat memberikan konsultasi. Dalam pendekatan tradisional, para spesialis bekerjasama dengan para pengguna, sedangkan dalam pendekatan baru menggunakan strategi outsourcing. Tahap perencanaan memberikan beberapa keuntungan, antara lain: definisi lingkup proyek; perhatian pada permasalahan potensial; menyusun tugas-tugas dalam urutan; memberikan dasar untuk kontrol. Tahap perencanaan meliputi: (1) Pengakuan permasalahan; (2) Definisi permasalahan; (3) Menetapkan himpunan sasaran; (4) Identifikasi batasan; (5) Mengarahkan studi kelayakan (teknik, ekonomi, hukum dan etika, operasional, jadwal); (6) Menyiapkan proposal studi proyek; (7) Menyetujui atau menolak dilanjutkan atau tidak dilanjutkan; (8) Memberikan mekanisme kontrol. Tahap analisis meliputi: (1) Mempublikasikan; (2) Mengorganisasikan tim proyek; (3) Mendefinisikan kebutuhan informasi; (4) Mendefinisikan kriteria kinerja sistem; (5) Menyiapkan proposal perancangan

34

(dibandingkan dengan proposal studi); (6) Menyetujui atau menolak ke perancangan proyek. Tahap parancangan meliputi: (1) Menyiapkan detail rancangan; (2) Mengidentifikasi konfigurasi alternatif sistem; (3) Evaluasi konfigurasi; (4) Memilih konfigurasi terbaik; (5) Mempersiapkan proposal implementasi; (6) Menyetujui atau menolak melanjutkan ke implementasi sistem. Tahap implementasi meliputi: (1) Perencanaan implementasi; (2) Mengumumkan; (3) Menjelaskan sumber daya hardware; (4) Menjelaskan sumber daya software; (5) Menyiapkan database; (6) Menyiapkan fasilitas fisik; (7) Mendidik para personal yang terlibat dan pengguna; (8) Menyiapkan proposal cutover; (9) Menyetujui atau menolak melanjutkan ke penggunaan sistem baru; (10) Cutover ke sistem baru. Tahap penggunaan meliputi: (1) Penggunaan; (2) Audit; (3) Pemeliharaan; (4) Menyiapkan proposal rekayasa ulang; (5) Menyetujui atau menolak rekayasa ulang. Dalam sumber referensi yang lain, Avison dan Fitzgerald (1995) menyatakan, bahwa metodologi memuat fase-fase, masing-masing fase memuat sejumlah sub fase, yang menjadi petunjuk bagi pengembang sistem dalam memilih teknik yang tepat pada setiap tahapan pada proyek dan membantu perencanaan, pengelolaan, kontrol, dan evaluasi proyek Sistem Informasi. Menurut Avison dan Fitzgerald (1995) ada ribuan metodologi pengembangan SI yang sudah pernah dipakai, dan setiap metodologi memiliki perbedaan satu sama lain karena adanya perbedaan penekanan, misal penekanan terhadap dimensi manusianya; pendekatan keilmiahannya; pendekatan yang pragmatis; pendekatan yang otomatis.

35

Niv Ahituv, Seev Neumann, dan Moshe Zviran (2002) telah melakukan penelitian mengenai pengembangan sistem Enterprise Resources Planning (ERP). Menurut para peneliti tersebut, saat ini pendekatan konvensional sudah tidak bisa diandalkan lagi. Selanjutnya para peneliti tersebut mengusulkan suatu metodologi pengembangan ERP dengan memperhatikan 9 karakteristik ERP, yaitu: (1) Kompleksitas sistem; (2) Kepentingan strategi sistem; (3) Fleksibilitas sistem; (4) Lingkup aplikasi; (5) Infrastruktur teknologi; (6) Perubahan proses organisasional; (7) Kekuatan pada hubungan dengan vendor; (8) Konsultan ketenagakerjaan; (9) Keterlibatan pengguna. Berdasarkan karakteristik tersebut Niv Ahituv, Seev Neumann,

dan

Moshe

Zviran

(2002)

mengajukan

suatu

metodologi

pengembangan sistem ERP yang tahapannya meliputi: (1) Seleksi; (2) Definisi paralel pengembangan dan implementasi; (3) Operasi.

2.1.9.2. Teknik Prototyping Menurut Roger S. Pressman (1997), prototyping baik digunakan jika pengguna belum siap dengan persyaratan software secara lengkap. Prototyping digunakan untuk menunjukkan model software SIM yang dapat terdiri atas: (1) Model “kertas”, diperlukan agar pengguna mengerti tentang interaksi antara pengguna dan software; (2) Model kerja, diperlukan untuk mengimplementasikan beberapa fungsi/modul dalam software; (3) Program, dikembangkan setelah sebagian atau semua fungsi/modul dalam software yang akan digunakan dalam SIM telah diimplementasikan. Roger S. Pressman (1997) menggambarkan paradigma prototyping seperti ditunjukkan Gambar 2.17.

36

Gambar 2.17: Paradigma prototyping Prototype bukan merupakan software yang sesungguhnya. Teknik prototyping melibatkan suatu proses iterasi yang berfokus pada penyempurnaan prototype yang didasarkan pada persyaratan yang diminta oleh pengguna. Dalam hal ini, pengguna harus terlibat secara aktif/intensif selama proses rekayasa perangkat lunak SIM. Penggunaan teknik prototyping untuk rekayasa perangkat lunak SIM menghadapi permasalahan, antara lain: (1) Ketidaksadaran pengguna bahwa prototype hanyalah suatu model, bukan hasil akhir yang diharapkan; (2) Umumnya pengguna tidak sabar menunggu software yang sebenarnya; (3) Pengembang sering menggunakan teknik dan tools yang tidak optimal pada prototype dan tetap digunakan pada software yang sebenarnya (Pressman, 1997).

2.1.9.3. Model Spiral Menurut Roger S. Pressman (1997), model spiral menggabungkan keuntungan pada model air terjun dan prototyping, dan memasukkan aktivitas analisis resiko (risk analysis). Model spiral melibatkan proses iterasi, dimana setiap iterasi bekerja pada satu ‘level produk’ dimulai dari prototype awal sampai

37

pada software SIM yang diinginkan, setiap perpindahan level didahului oleh analisis resiko. Satu-satunya permasalahan yang dihadapi dalam penggunaan model spiral adalah tuntutan keahlian analisis resiko. Gambar 2.18 menunjukkan rekayasa perangkat lunak SIM menggunakan model spiral (Pressman,1987).

Gambar 2.18: Rekayasa perangkat lunak SIM menggunakan model spiral Rekayasa perangkat lunak SIM menggunakan model spiral terdiri atas aktivitas utama berikut: (1) Perencanaan, meliputi: penentuan sasaran, alternatif solusi, dan hambatan; (2) Analisis resiko, meliputi analisis alternatif solusi dan identifikasi resiko; (3) Rekayasa, merupakan pengembangan produk pada level berikutnya; (4) Evaluasi oleh pengguna, diterapkan pada hasil proses rekayasa. Gambar 2.19 menunjukkan aktivitas utama dalam model spiral (Pressman,1987). Requirements gethering ‘Design’ strategy Implementation using 4 GL Testing

Gambar 2.19: Aktivitas utama dalam model spiral

38

2.1.9.4. Kerangka Kerja Zachman Dalam artikelnya, Brian Mullen (2005) menyatakan bahwa pengembangan SIM dapat dilakukan dengan menggunakan Kerangka Kerja Zachman yang mengilustrasikan posisi setiap tipe metode perancangan atau representasi yang dapat digunakan. Kerangka Kerja Zachman dapat ditunjukkan seperti Tabel 2.3. Setiap baris dalam tabel tersebut merepresentasikan deskripsi sistem pada tingkat selanjutnya, dan motivasi bisnis ditempatkan pada kolom pertama untuk mengarahkan aktivitas-aktivitas lainnya dalam mendefinisikan sistem. Tabel 2.3: Kerangka Kerja Zachman Revisi Kerangka Kerja untuk Rekayasa Sistem Informasi Level pada abstraksi

Motivasi (mengapa?)

Personel (siapa?)

Waktu (kapan?)

Data (apa?)

Fungsi Jaringan (bagaimana?) (dimana?)

1.Sasaran dan Lingkup

Daftar tujuan bisnis/ strategis

Daftar pada organisasi

Daftar kegiatan bisnis/siklus

Daftar data penting organisasi

Daftar proses yg disediakan oleh fungsi

Daftar lokasi operasi

2.Model Bisnis

Rencana bsnis

Diagram organisasi & aturannya

Master jadwal, matrik respon kegiatan

ER_D, Object diagram

Aliran proses bisnis, Diagram interaksi

Lokasi, matrik distribusi proses & data

3.Model Sistem Informasi

Aturan bisnis

Arsitektur human interface (aturan, akses)

Diagram ketergantungan, sejaraj siklus hidup entitas

Data model, ER_M, Object type model

DFD, Use Case Arsitektur sistem terdistribusi

4.Model Teknologi

Aturan pelaksanaan

User interface (bagaimana sistem akan bereaksi?)

Control flow diagram

Skema arsitektur data (tabel & kolom)

Bagan struktur, Pseudo Code

Arsitektur sistem (hardware, software tool)

5.Detail Representasi

Aturan server & logik

Arsitektur keamanan (siapa dapat melihat apa)

Interrupt dan siklus mesin

Perancangan data, Perancangan storage

Detail perancangan program

Arsitektur jaringan

6.Memfungsikan Sistem

Sistem dijalankan/difungsikan

Sumber: http://www2.cstudies.ubc.ca/~mullen/IEDBS.html#GeneralTables

39

2.1.9.5. Kombinasi Beberapa Paradigma Kombinasi beberapa paradigma dalam rekayasa perangkat lunak SIM dimaksudkan untuk mengambil kelebihan masing-masing metodologi. Roger S. Presmaan (1987) menggambarkan kombinasi paradigma air terjun, prototyping, dan spiral seperti ditampilkan oleh Gambar 2.20. Preliminary requirements gathering

Requirements Analisys

Prototyping

Spiral model

4 GT

Design Design Prototyping nth iteration

4 GT

Coding Spiral model nth iteration 4 GT Testing Operastional system

Maintenance

Gambar 2.20: Kombinasi beberapa paradigma rekayasa perangkat lunak SIM

2.1.10. Perancangan Sistem Dalam SIM Perancangan sistem (system design) merupakan tahapan setelah analisis sistem (system analysis) yang dapat dikelompokkan dalam dua bagian, yaitu perancangan sistem secara umum (general system design) atau perancangan konseptual (conseptual design) atau perancangan sistem logika (logical design) dan perancangan sistem secara terinci (detail system design) atau perancangan sistem secara fisik (physical system design) atau perancangan internal (internal design). Tahap perancangan sistem mempunyai dua tujuan utama, yaitu untuk memenuhi kebutuhan pengguna sistem dan untuk memberikan gambaran yang

40

jelas dan tentang rancang bangun yang lengkap kepada pemrogram (programmer) dan ahli teknik lain yang terlibat. Sehingga seorang analisis sistem harus dapat mencapai sasaran, yaitu rancangan sistem harus: (1) Berguna, mudah dipahami, dan mudah digunakan; (2) Mendukung tujuan utama perusahaan sesuai dengan yang telah didefinisikan pada tahap studi yang dilanjutkan pada analisa sistem; (3) Efektif dan efisien untuk mendukung pengolahan transaksi, pelaporan manajemen, dan keputusan yang akan dilakukan oleh manajemen, termasuk tugas lain yang dilakukan oleh komputer; (4) Dapat mempersiapkan rancang bangun yang terinci untuk masing-masing komponen SIM yang meliputi data dan informasi, metode, prosedur, orang, perangkat keras/lunak, dan pengendalian sistem (Whitten dan Bentley, 1998). Kebutuhan-kebutuhan

sistem

(system

requirement)

yang

harus

diperhatikan dalam merancang SIM meliputi: (1) Keandalan (reability); (2) Ketersediaan (availability); (3) Keluwesan (fleksibility); (4) Jadwal instalasi (installation schedule); (5) Umur yang diharapkan (life expentancy) dan potensi pertumbuhan (growth potencial); (6) Kemudahan dipelihara (maintainability). Model sistem secara fisik dapat digambarkan dengan bagan alir dokumen, sedangkan model sistem secara logika dapat digambarkan dengan Diagram Arus Data/DAD (Data Flow Diagram/DFD). DFD menggambarkan secara rinci uruturutan langkah dari masing-masing proses yang digambarkan dalam diagram arus data. Terdapat beberapa metodologi menggambar DFD yang dapat digunakan dalam pemodelan sistem, salah satu diantaranya adalah SSADM (Structured System Analysis and Design Methodology) yaitu metode analisis dan desain

41

sistem secara terstruktur. Dalam metode Gane dan Sarson, DAD digambarkan dengan menggunakan simbol, yaitu sebagai berikut (Whitten dan Bentley, 1998): 1.

External entity, merupakan kesatuan di lingkungan luar sistem yang akan mempengaruhi sistem, dengan memberikan input atau menerima output dari sistem. External entity dapat berupa: orang atau sekelompok orang dalam organisasi tetapi di luar sistem yang sedang dikembangkan; organisasi atau orang yang berada di luar organisasi; kantor atau divisi dalam perusahaan tetapi di luar sistem yang sedang dikembangkan; sistem informasi lain di luar sistem yang sedang dikembangkan; sumber asli dari suatu transaksi; penerima akhir dari suatu laporan yang dihasilkan oleh sistem. External entity digambarkan dengan simbol seperti Gambar 2.21.

Nama external entity

Gambar 2.21: Simbol external entity 2.

Repeated external entity, untuk menghindari keruwetan diagram, karena banyaknya garis penghubung antara external entity, proses, maupun data store yang saling berpotongan, maka external entity dapat digambarkan lebih dari satu kali untuk satu nama yang disebut repeated external entity. Repeated external entity digambarkan dengan simbol seperti Gambar 2.22. Nama external entity

Nama external entity

Gambar 2.22: Simbol repeated external entity

42

3.

Data flow, disimbolkan dengan tanda panah dimana arah panah menunjukkan arah mengalirnya data. Data flow mengalir menuju proses atau meninggalkan proses. Data flow yang meninggalkan external entity selalu menuju ke proses. Arus data dapat berupa masukan untuk sistem atau hasil dari proses sistem dan dapat berbentuk formulir atau dokumen yang digunakan sistem; laporan tercetak yang dihasilkan sistem; masukan untuk komputer; output ke layar monitor; data yang dibaca dari suatu file atau yang direkam ke suatu file; komunikasi ucapan; surat atau memo; suatu isian yang dicatat pada buku agenda. Arus data diberi nama yang jelas dan bermakna (meaningful) yang dapat mewakili data yang mengalir. Arus data adalah arus yang mengalir menuju proses atau arus yang mengalir dari proses atau arus yang mengalir dari proses menuju proses lain, sehingga jika arus data tidak seperti ketentuan tersebut maka dipastikan bahwa DFD tersebut salah. Data flow digambarkan dengan simbol seperti Gambar 2.23. Nama data flow

Gambar 2.23: Simbol data flow 4.

Process, adalah kegiatan yang dilakukan oleh orang, mesin, atau komputer dari hasil suatu arus data yang masuk ke proses dan akan dihasilkan arus data yang keluar dari proses. Process digambarkan dengan simbol seperti Gambar 2.24. 1 Nama proses

Gambar 2.24: Simbol process

43

Kesalahan yang sering terjadi dalam DFD adalah: (1) Proses mempunyai input tetapi tidak menghasilkan output. Kesalahan ini disebut blackhole, yaitu data masuk ke proses dan lenyap tidak berbekas; (2) Proses menghasilkan output tetapi tidak pernah menerima input. Kesalahan ini disebut miracle (ajaib), karena sistem menghasilkan output secara ajaib tanpa pernah menerima output. 5.

Data storage, merupakan simpanan dari data yang dapat berupa File atau database di sistem komputer; Arsip atau catatan manual; Kotak tempat data di meja seseorang; Tabel acuan buku; Suatu agenda atau buku. Data storage digambarkan dengan simbol seperti Gambar 2.25. D1

Mahasiswa

Gambar 2.25: Simbol data storage Pengambaran data storage perlu memperhatikan hal-hal berikut: (1) Data storage hanya berhubungan dengan proses, karena yang menggunakan atau merubah data di data storage adalah suatu proses; (2) Arus data dari proses menuju ke data storage menunjukkan proses update data dalam data storage. Update data dapat berupa proses menambah atau menyimpan record atau dokumen baru ke dalam data storage, menghapus record atau dokumen dalam data storage, atau merubah record atau dokumen dalam data storage; (3) Arus data dari data storage menuju ke proses dapat diartikan sebagai proses menggunakan data dalam data storage untuk dilihat

44

isinya; (4) Suatu proses dapat melakukan keduanya, yaitu menggunakan dan meng-update data dalam data storage. 6.

Repeated Data Storage, untuk menghindari keruwetan diagram, karena banyaknya garis penghubung antar data storage, external entity, process, maupun data storage yang saling berpotongan, maka data storage dapat digambarkan lebih dari satu buah untuk satu nama yang disebut repeated data storage. Repeated Data storage digambarkan dengan simbol seperti Gambar 2.26. D1

Nama data storege

D1

Nama data storege

Gambar 2.26: Simbol repeated data storage Pedoman menggambar DFD, adalah (Whitten dan Bentley, 1998): 1. Identifikasikan semua external entity sistem yang terlibat; 2. Identisikasikan semua input dan output yang terlibat dengan external entity; 3. Gambarlah terlebih dahulu suatu diagram konteks atau diagram induk untuk garis besar, kemudian dipecah untuk level-level berikutnya; 4. Gambarlah bagan berjenjang (hirarchy chart) untuk semua proses yang ada di sistem untuk mempersiapkan penggambaran DFD level berikutnya; 5. Gambarlah sketsa DFD untuk overview diagram (level 0) berdasarkan proses bagan berjenjang; 6. Gambarlah DFD untuk level-level berikutnya, yaitu level 1, kemudian dipecah dalam level 2, dan seterusnya; 7. Setelah semua level DFD digambarkan, selanjutnya adalah menggambar DFD untuk pelaporan manajemen yang digambarkan secara terpisah; 8. Semua level DFD yang telah digambar termasuk DFD untuk pelaporan manajemen digabung dalam satu diagram. Salah satu alat dokumentasi yang banyak digunakan dalam perancangan sistem adalah diagram HIPO. Menurut Al-Bahra bin Ladjamudin (2005), HIPO untuk sistem dapat ditunjukkan dalam tiga jenis, yaitu:

45

1. Diagram isi tabel visual (Visual Table of Contents/VTOC), merupakan diagram pertama HIPO yang terdiri atas satu atau lebih diagram hirarkhi. VTOC berisi nama dan nomor identifikasi dari semua program untuk Diagram ringkas (Overview Diagram) dan Diagram detail (Detailed Diagram) secara terstruktur. VTOC juga menunjukkan struktur paket diagram dan hubungan fungsi

dalam

bentuk

hirarkhi.

Level

paling

tinggi

pada

VTOC

mengidentifikasikan fungsi sistem secara keseluruhan. Level berikutnya, memecah fungsi sistem ke dalam sub fungsi logika. 2. Diagram ringkas (Overview Diagram), merupakan diagram yang menjelaskan fungsi dan referensi utama yang diperlukan oleh program detail untuk memperluas fungsi sehingga cukup detail. Diagram ringkas menerangkan input, proses, dan output dari sistem secara garis besar, yaitu nama file/record input atau output). Input berisikan item-item data yang dipakai oleh proses, termasuk semua item input utama yang digunakan oleh diagram pada level yang lebih rendah. Proses berisikan urutan langkah yang menerangkan fungsi yang sedang dilaksanakan. Item input dihubungkan dengan suatu proses dengan simbol anak panah. Output berisikan item data yang dibentuk atau dimodifikasi oleh proses, termasuk semua item output utama yang ditampilkan oleh diagram pada level yang lebih rendah. Item output dihubungkan dengan suatu proses dengan simbol anak panah. 3. Diagram detail (Detailed Diagram), berisikan elemen-elemen dasar sistem; menerangkan fungsi-fungsi khusus; menampilkan item-item input dan output secara detail (yaitu nama field input yang diperlukan dan output yang

46

dihasilkan); memberikan referensi terhadap diagram HIPO yang lain, seperti diagram alir (flowchart) dan tabel keputusan dari logika yang rumit. Diagram detail juga berisi deskripsi yang menjelaskan langkah proses dan dapat mereferensikan terhadap diagram HIPO. Jumlah level diagram detail HIPO tergantung pada jumlah fungsi yang terkait, kerumitan pengolahan, dan jumlah infomasi yang akan didokumentasikan.

2.1.11. Kriteria Keberhasilan SIM Menurut Zainal A. Hasibuan (2004), dengan menggunakan suatu metodologi pengembangan SI yang sistematis, maka dapat diukur tingkat kesuksesan suatu SIM dengan menggunakan kriteria berikut: 1. Apakah penggunaan komputer sudah optimal ? 2. Apakah dokumentasinya mudah dipahami ? 3. Apakah harganya yang paling murah ? 4. Apakah waktu implementasinya singkat ? 5. Apakah mudah beradaptasi ? 6. Apakah penggunaan teknik dan tools sudah optimal ? 7. Apakah sistemnya disukai oleh pengguna ?

2.2.

Tinjauan Tentang Konsep Database

2.2.1. Definisi Database Hingga saat ini, istilah database telah didefinisikan dalam cara yang berbeda-beda. Sebuah definisi database yang telah cukup lama, namun cukup lengkap dan masih relevan telah diberikan oleh James Martin (1975), yaitu

47

sekumpulan data terhubung (interrelated data) yang disimpan secara bersamasama pada suatu media tanpa “mengatap” satu sama lain atau tidak perlu suatu kerangkapan data, kalaupun terjadi kerangkapan maka kerangkapan tersebut harus seminimal mungkin dan terkontrol (controlled redundancy); data disimpan dengan cara-cara tertentu sehingga mudah untuk digunakan atau ditampilkan kembali; data dapat digunakan oleh satu atau lebih program aplikasi secara optimal; data disimpan tanpa mengalami ketergantungan dengan program yang akan menggunakannya; data disimpan sedemikian rupa sehingga proses penambahan, pengambilan, dan modifikasi data dapat dilakukan dengan mudah dan terkontrol. C.J. Date (1995) mendefinisikan database sebagai beberapa kumpulan data yang akan tetap tersimpan, digunakan oleh sistem-sistem aplikasi yang diberikan oleh organisasi. J. L. Whitten & L. D. Bentley (1998) mendefinisikan database sebagai sekumpulan data dalam file yang saling terhubung (interrelated file), record dalam file harus mengijinkan adanya kerelesaian (dapat dibayangkan sebagai pointer) ke record-record lain dalam file yang lain. Raghu Ramakrishnan (1998) mendefinisikan database sebagai sekumpulan data yang saling berhubungan yang menjelaskan aktifitas-aktifitas pada sebuah organisasi. Abraham Silberschatz, Henry F. Korth, dan S. Sudarshan (2001) mendefinisikan database sebagai sekumpulan data yang saling berhubungan dan menjadi bagian dari DBMS. Sedangkan Raymond McLeod dan George Schell (2001) mendefinisikan database sebagai keseluruhan data yang disimpan dalam sistem komputer yang menjadi sumber daya organisasi.

48

2.2.2. Tujuan Database James Martin (1975) mengelompokkan tujuan database menjadi dua kelompok, yaitu tujuan primer dan tujuan sekunder. Tujuan primer merupakan tujuan utama yang ingin dicapai dalam perancangan dan pengembangan database. Tujuan primer database adalah: (1) Data-data dalam database dapat digunakan oleh banyak pengguna; (2) Menjaga investasi intelektual; (3) Penekanan biaya; (4) Menghilangkan proliferasi; (5) Kinerja (performance); (6) Kejelasan (clarity); (7) Kemudahan pemakaian; (8) Fleksibilitas (flexibility); (9) Kebutuhan data yang tidak terantisipasi dapat dipenuhi dengan cepat; (10) Perubahan yang mudah; (11) Akurasi (accuracy) dan konsistensi (consistency); (12) Privasi (privacy); (13) Keamanan (security); (14) Ketersediaan (availability) (Martin, 1975). Tujuan sekunder database merupakan tujuan tambahan yang diperlukan untuk mencapai tujuan primer, yaitu: (1) Kebebasan data secara fisik (physical data independency); (2) Kebebasan data secara logik (logical data independency); (3) Pengendalian atau minimalisasi kerangkapan (data redundancy); (4) Kecepatan akses; (5) Kecepatan pencarian; (6) Standarisasi data; (7) Tersedianya kamus data; (8) Antarmuka pemrogram tingkat tinggi; (9) Bahasa end-user; (10) Pengendalian integritas (integrity); (11) Kecepatan pemulihan kembali dari kerusakan (fast recovery from failuries); (12) Kemampuan perubahan untuk penyesuaian (tuning); (13) Perancangan dan pengawasan alat-alat; (14) Pengorganisasian kembali atau migrasi data dapat dilakukan secara otomatis (Martin, 1975).

49

2.2.3. Keuntungan Database Penyusunan

database

digunakan

untuk

mengatasi

permasalahan-

permasalahan pada saat pengolahan data. Kamran Parsaye, Mark Chignell, Setrag Khoshafian, dan Harry Wong (1989), menyatakan bahwa database memberikan keuntungan sebagai berikut: (1) Akses bersama data untuk pengguna-pengguna yang berbeda; (2) Keamanan data; (3) Meningkatkan kemudahan dan efisiensi dalam update untuk pemelihaan data. Dalam referensi yang lain, C.J. Date (1995) menyatakan bahwa pengolahan data dengan pendekatan database memberikan keuntungan berikut: (1) Kerangkapan data dapat diminimalkan; (2) Inkonsistensi data dapat dihindari; (3) Data dalam database dapat digunakan secara bersama (multiuser); (4) Standarisasi data dapat dilakukan; (5) Pembatasan untuk keamanan data dapat diterapkan; (6) Integritas data dapat terpelihara; (7) Perbedaan kebutuhan data dapat diseimbangkan. Sedangkan Raymond McLeod Jr. dan George Schell (2001), menyatakan bahwa database memberikan keuntungan sebagai berikut: (1) Mengurangi kerangkapan data; (2) Menghindari ketergantungan data; (3) Memungkinkan integrasi data dari banyak file; (4) Pemanggilan data dan informasi lebih cepat; (5) Meningkatkan keamanan data.

2.2.4. Kendala Dalam Database Untuk memenuhi batasan/kriteria sebagaimana definisi database, mka suatu proses perancangan database memiliki beberapa kendala atau aturan yang harus ditaati, yaitu terkait dengan aspek berikut (Martin, 1975):

50

1. Kerangkapan data (data redundancy), adalah munculnya data-data secara berlimpah/berulang pada file database yang semestinya tidak diperlukan. Umumnya, kerangkapan data dalam database terjadi akibat penyusunan database tidak memperhatikan batasan/kriteria database atau akibat penyusunan database dilakukan dalam selang waktu yang lama. 2. Inkonsistensi data (data inconsistency), adalah munculnya data tidak konsisten pada medan/kolom yang sama dalam satu atau lebih file yang berhubungan. 3. Data terisolasi, disebabkan oleh pemakaian beberapa file database dimana tedapat data yang tidak memiliki kerelasian dengan data yang lain, sehingga program aplikasi tidak dapat mengakses data tersebut, kecuali jika program aplikasi diubah/ditambah. Data terisolasi harus dihindari karena informasi yang dihasilkan dari pengolahan data dalam database tidak akurat/lengkap. 4. Keamanan (security), merupakan aspek kritis dalam database. Data dalam database merupakan sumber informasi yang penting. Oleh karena itu harus dijaga dari berbagai hal yang mungkin dapat merusak data. Aspek keamanan database meliputi: Recovery, Integrity, Concurency, Privacy dan Security. 5. Integrity, cara terbaik untuk menjaga integritas database adalah meyakinkan nilai-nilai data adalah benar sejak pertama kali dimasukkan. Integritas data dalam database, terkait dengan dua aspek, yaitu: Domain integrity dan Key constraints (meliputi aspek entity integrity dan referential integrity). Abraham Silberschatz, Henry F. Korth, dan S. Sudarshan (2001) database mampu mengatasi semua permasalahan yang terkait kendala di atas.

51

2.2.5. Pandangan Terhadap Database Sebuah database dapat dipandang dari dua sisi, yaitu sisi pengguna dan sisi perancang. Pengguna database adalah orang atau program aplikasi yang mengakses database, baik sendiri maupun secara bersamaan. Sedangkan perancang adalah personal yang berperan sebagai perancang dan pengelola database. Seorang perancang dapat memiliki dua pandangan yang berbeda, yaitu secara konseptual dan secara fisis. Pandangan-pandangan tersebut menunjukkan level abstraksi database yang sering disebut sebagai arsitektur database atau abstraksi database. Dalam hal ini terdapat beberapa penyebutan yang berbeda untuk setiap level abstraksi database. James Martin (1975) menjelaskan bahwa abstraksi database terdiri atas tiga level, yaitu application programmer logical file atau user view, global logical data atau level konseptual (conceptual view), dan physical view atau level internal. Jeffrey D. Ullman (1988) menyebutkan bahwa tiga level abstraksi database adalah meliputi: level pandangan (view level), level database konseptual (conceptual database level), dan level database fisik (physical database level). Raghu Ramakrishnan (1998) membedakan level abstraksi database menjadi tiga, yaitu: skema eksternal (external schema), skema konseptual (conceptual schema), dan skema fisik (physical schema). Abraham Silberschatz, Henry F. Korth, dan S. Sudarshan (2001) membedakan level abstraksi database menjadi tiga, yaitu: pandangan eksternal (externalview) atau pandangan pengguna (user view), pandangan konseptual (conceptual view) atau pandangan komunitas pengguna (community user view), dan pandangan internal (internal view) atau pandangan

52

media penyimpan sekunder (storage view). Abraham Silberschatz, Henry F. Korth, dan S. Sudarshan (2001) dan penulis buku database lainnya, umumnya menggambarkan arsitektur database seperti ditunjukkan oleh Gambar 2.27.

Gambar 2.27: Pandangan terhadap database Level user view merupakan pandangan para pengguna database dimana masing-masing dapat memiliki pandangan yang berbeda tergantung pada macam data apa saja yang tersedia. Pengguna tidak perlu mengetahui teknis penyimpanan database dalam media penyimpan. User view dijelaskan oleh schema dan subschema database, sedangkan nilai aktual data ditunjukkan oleh instance schema. Level conceptual view merupakan pandangan perancang database yang berkaitan dengan data apa saja yang perlu disimpan dan penjelasan mengenai hubungan antara data yang satu dengan lainya. Global logical data ditunjukkan oleh definisi struktur tabel database menggunakan bahasa deskripsi data (Data Definition Language/DDL). Sedangkan physical view merupakan implementasi conceptual view, yaitu pandangan yang berkaitan dengan teknik penyimpanan data ke dalam fisik media penyimpanan data yang digunakan, meliputi metoda penyimpanan dan metoda akses data dalam media penyimpan sekunder (storage device).

53

2.2.6. Model Data Model data (data model) merupakan suatu cara untuk menjelaskan tentang data-data yang tersimpan dalam database dan bagaimana hubungan antar data tersebut

untuk

pengguna

(user)

secara

logik.

James

Martin

(1975)

mengelompokkan model data sebagai berikut: (1) Object Based Data Model/OBDM, merupakan model data yang didasarkan pada obyek; (2) Record Based Data Model/RBDM, merupakan suatu model yang didasarkan pada record/rekaman. Model ini terdiri atas: Hierarchycal model, Network model, dan Relational data base model/RDBM; (3) Physical based data model, model ini didasarkan pada teknis penyimpanan record dalam database.

2.2.7. Relational Database Model/RDBM Menurut Paul Litwin (2003) RDBM diperkenalkan pertama kali oleh E.F. Codd pada tahun 1969 yang kemudian menjadi salah seorang peneliti di perusahaan IBM (http://r937.com/relational.html). Menurut James Martin (1975), RDBM merupakan salah satu model data yang menjelaskan tentang hubungan logik antar data dalam database kepada pengguna dengan merepresentasikannya dalam bentuk tabel datar (flat file) yang terdiri atas sejumlah baris yang menunjukkan record dan kolom yang menunjukkan atribut. Berkaitan dengan penggunaan istilah, RDBM memiliki terminologi yang berbeda dengan model data lainnya. Beberapa istilah khusus dalam RDBM, ditunjukkan pada Tabel 2.4.

54

Tabel 2.4: Istilah-istilah dalam terminologi RDBM Istilah formal

Istilah non formal Elemen data (data element), rinci data (data item), entri (entry) Atribut (attribute) Kolom, medan data, medan, field Record/tuple Baris/rekaman Relasi (relation) Tabel Derajat (degree) Aritas (arity) Kardinalitas (cardinality) Kerelasian (relationship) Unary relation Binary relation Ternary relation n-ary relation Key Candidate Key/CK Primary Key/PK Alternate Key/AK Foreign Key/FK

Kunci tamu /kunci asing

Domain Schema Subschema

Keterangan

Sekelompok rinci data yang mempunyai arti. Atribut memiliki tipe, ukuran, dan domain yang sama Sekumpulan atribut yang mempunyai hubungan terhadap obyek tertentu Sekumpulan record yang sejenis secara relasi Jumlah atribut dalam sebuah relasi Jumlah record dalam sebuah relasi Hubungan antar relasi Relasi yang tersusun oleh satu atribut Relasi yang tersusun oleh dua atribut Relasi yang tersusun oleh tiga atribut Relasi yang tersusun oleh n atribut Satu atau gabungan atribut bersifat unik yang digunakan untuk mengidentifikasi setiap record dalam relasi Satu atau gabungan minimal atribut bersifat unik yang dapat digunakan untuk mengidentifikasi setiap record dalam relasi Bagian dari CK yang dipilih/digunakan sebagai kunci utama dalam relasi Bagian dari CK yang tidak dipilih/digunakan sebagai kunci utama dalam relasi Satu atau gabungan sembarang atribut yang menjadi PK dalam relasi lain yang mempunyai hubungan secara logik Himpunan nilai yang memenuhi syarat Deskripsi hubungan logik secara global, termasuk di dalamnya nama dan deskripsi tipe dan ukuran atribut dan hubungan logik antar relasi database dalam lingkup sebuah sistem Deskripsi hubungan logik secara terpisah, termasuk di dalamnya nama dan deskripsi tipe dan ukuran atribut dan hubungan logik antar relasi database dalam lingkup sebuah sub sistem aplikasi database

Sumber: James Martin, 1975

Dalam RDBM, kunci relasi diperlukan untuk pengaksesan data dalam relasi atau untuk menyusun kerelasian antar relasi. Kunci relasi merupakan satu atau gabungan atribut yang bersifat unik dan dapat digunakan untuk mengidentifikasi setiap record dalam relasi. Sifat unik tersebut diartikan bahwa nilai-nilai elemen data/entri dalam atribut yang digunakan sebagai kunci relasi tidak boleh ada yang sama untuk seluruh record dalam relasi.

55

Berdasarkan jumlah atribut penyusunnya, kunci relasi dapat dibedakan menjadi dua jenis, yaitu: (1) Kunci sederhana (simple key), yaitu kunci yang tersusun atas sebuah atribut; (2) Kunci komposit (composite key), yaitu kunci yang tersusun atas gabungan atribut. Sedangkan berdasarkan macamnya, kunci relasi terdiri atas: (1) Kunci kandidat (Candidate Key/CK), yaitu satu atau gabungan minimal atribut unik yang dapat digunakan untuk mengidentifikasi setiap record dalam relasi; (2) Kunci primer (Primary Key/PK), yaitu bagian dari CK yang dipilih sebagai kunci utama untuk mengidentifikasi/membedakan setiap record dalam relasi; (3) Kunci alternatif (Alternate Key/AK), yaitu bagian dari CK yang tidak digunakan sebagai PK; (4) Kunci penghubung/kunci tamu/kunci asing (Foreign Key/FK), yaitu satu atau gabungan atribut yang menjadi PK dalam relasi lain yang mempunyai hubungan secara logik (Martin, 1975). Pemilihan kunci relasi memiliki beberapa aturan (rules), yaitu: (1) Integritas kesatuan/integritas entitas (entity integrity), aturan ini memberikan batasan bahwa secara kesatuan nilai-nilai elemen data/entri pada atribut yang dipilih/digunakan sebagai PK tidak boleh null; (2) Integritas referensial (referential integrity), aturan ini membatasi bahwa di dalam kerelasian antar dua atau lebih relasi dalam database yang dihubungkan dengan suatu kunci penghubung (foreign key/FK), maka hubungan antar relasi tersebut harus menjamin bahwa setiap nilai elemen data/entri pada FK dalam relasi anak harus ada record dengan nilai elemen data/entri yang sama pada relasi induk yang menjadi referensi (Martin, 1975).

56

Relasi RDBM mempunyai beberapa karakteristik yang harus dipenuhi, yaitu: (1) Semua elemen data/entri pada suatu relasi harus mempunyai nilai tunggal (single value), bukan suatu larik atau grup perulangan dan harus berupa nilai yang tidak dapat dibagi lagi (atomic value); (2) Semua elemen data/entri pada suatu atribut tertentu dalam sebuah relasi harus mempunyai tipe dan ukuran yang sama; (3) Masing-masing atribut dalam sebuah relasi mempunyai nama yang unik; (4) Pada sebuah relasi tidak ada dua record data yang identik (Martin, 1975). Setiap relasi RDBM tersusun atas dua komponen, yaitu: (1) Intension, meliputi struktur penamaan (naming structure) relasi dan batasan integritas (integrity contraint) yaitu batasan integritas kesatuan (entity integrity) dan batasan integritas referensial (referential integrity); (2) Extension, menunjukkan nilai-nilai aktual elemen data/entri yang tersimpan dalam relasi pada suatu saat tertentu (Martin, 1975). Perancangan database utamanya dimaksudkan untuk menghindari munculnya permasalahan pada operasi pengolahan data. Umumnya permasalahan ini merupakan penyimpangan (anomaly) yang harus dihindari yang muncul akibat kerangkapan

data

dalam

database.

Menurut

Gio

Wiederhold

(1988),

penyimpangan itu meliputi: (1) Penyimpangan penghapusan (delete anomally); (2) Penyimpangan penyisipan (insert anomally); (3) Penyimpangan pembaharuan (update anomally) (Martin, 1975). Penyimpangan dalam pengolahan data juga dapat terjadi akibat ketergantungan antar nilai rinci data. Ketergantungan antar nilai rinci data menjabarkan hubungan antara atribut-atribut dalam hal bagaimana suatu nilai menentukan nilai yang lain. Umumnya, yang paling baik dilakukan

57

adalah jika struktur relasi dirancang sedemikian rupa sehingga atribut-atribut non kunci hanya bergantung pada PK dan tidak memiliki ketergantungan pada atribut lainnya. Jenis-jenis ketergantungan antar nilai rinci data adalah (Martin, 1975): 1. Ketergantungan

fungsional

(Functionally

Dependence/FD),

atribut

Y

dikatakan bergantung secara fungsional pada atribut X jika setiap nilai X berkaitan dengan sebuah nilai Y, dan untuk setiap record yang memiliki sembarang nilai X selalu berhubungan dengan nilai Y yang sama. Notasi: FD: R.X →R.Y Keterangan: FD : Functionally Dependence R : nama relasi X : atribut penentu (determines) Y : atribut yang bergantung (dependent)

2. Ketergantungan fungsional penuh (Full Functionally Dependency/FFD), atribut Y mempunyai ketergantungan fungsional penuh pada atribut X jika Y functional dependency pada X, dan Y tidak functional dependency pada bagian tertentu dari X. Notasi: FFD: R.X →R.Y Keterangan: FFD : Full Functionally Dependency R : nama relasi X : atribut penentu (determines) Y : atribut yang bergantung (dependent)

3. Ketergantungan transitif (Transitive Dependency/TDF), atribut Z dikatakan mengalami ketergantungan transitif pada X, jika Y functional dependency pada X dan Z functionally dependency pada Y. Notasi: TDF: R.X →R.Y→R.Z Keterangan: TDF : Trancitive Dependency R : nama relasi X : atribut penentu (determines) Y : atribut yang bergantung (dependent) terhadap X dan sekaligus penentu terhadap Z Z : atribut yang bergantung (dependent) terhadap Y dan sekaligus bergantung pada X

58

4. Ketergantungan total (Total Dependency/TD), atribut Y dikatakan mengalami ketergantungan total, jika Y functionally dependency pada X dan X functionally dependency pada Y. Notasi: TD: R.X ↔R.Y Keterangan: TD : Total Dependency R : nama relasi X : atribut penentu (determines), sekaligus bergantung pada Y Y : atribut yang bergantung (dependent) sekaligus penentu pada X

Untuk memenuhi batasan/kriteria database, maka setiap rancangan relasi perlu diuji untuk menentukan apakah setiap relasi yang dirancang telah berada dalam kondisi optimal dan tidak menimbulkan permasalahan (anomalies) saat pengolahan data. Jika relasi belum optimal, maka perlu dilakukan proses normalisasi, yaitu suatu teknik yang menstrukturkan data dalam cara-cara tertentu untuk mencegah timbulnya permasalahan pengolahan data dalam database (Martin, 1975). Dalam sumber referensi yang lain, normalisasi diartikan sebagai proses menempatkan beberapa data ke dalam tabel-tabel database anak yang dihubungkan dengan sebuah induknya (mungkin sekaligus menjadi anak bagi dirinya sendiri) yang memuat sebagian data ke yang mana direlasikan (http://www.goverpub.com/pdf/pidms2.pdf). Normalisasi akan menghasilkan relasi yang optimal, yaitu: (1) Memiliki struktur record yang konsisten secara logik; (2) Memiliki struktur record yang mudah untuk dimengerti; (3) Memiliki struktur record yang sederhanaa dalam pemeliharaan; (4) Memiliki struktur record yang mudah untuk ditampilkan kembali; (5) Minimalisasi kerangkapan data guna meningkatkan kinerja sistem (Martin, 1975).

59

Dalam sumber referensi yang lain Abraham Silberschatz, Henry F. Korth, dan S. Sudarshan (2001) menyatakan bahwa normalisasi bertujuan untuk memperoleh relasi-relasi dalam bentuk yang “baik”. Jika sebuah relasi R memiliki bentuk yang “tidak baik”, maka relasi tersebut dipecah menjadi sejumlah relasi {R1, R2, ..., Rn} dimana setiap relasi memiliki bentuk yang “baik” dan pemecahan dilakukan tanpa terjadi kehilangan informasi saat digabungkan kembali (losslessjoin). Teori normalisasi didasarkan pada ketergantungan fungsional (functinonally dependency/FD dan ketergantungan pada banyak nilai (multivalue dependency). Bentuk-bentuk normal yang dikenal hingga saat ini adalah (Martin, 1975): 1. Bentuk tidak normal (Unnormalized Form/UNF). Relasi UNF terjadi jika: (1) Relasi mempunyai bentuk non flat file; (2) Relasi memuat set atribut berulang (non single value); (3) Relasi memuat atribut non atomic value. 2. Bentuk 1NF. Kriteria relasi 1NF adalah: (1) Jika seluruh atribut dalam relasi bernilai atomik (atomic value); (2) Jika seluruh atribut dalam relasi bernilai tunggal (single value); (3) Jika relasi tidak memuat set atribut berulang; (4) Jika semua record mempunyai sejumlah atribut yang sama. 1. Bentuk 2NF. Kriteria relasi 2NF adalah: (1) Jika memenuhi kriteria 1 NF; (2) Jika semua atribut non kunci FD pada PK. 2. Bentuk 3NF. Kriteria relasi 3NF adalah: (1) Jika memenuhi kriteria 2NF; (2) Jika setiap atribut non kunci tidak TDF terhadap PK. 3. Bentuk BCNF. Kriteria relasi BCNF adalah: (1) Jika memenuhi kriteria 3NF; (2) Jika semua atribut penentu (determinan) merupakan CK.

60

4. Bentuk 4NF. Kriteria relasi 4NF adalah: (1) Jika memenuhi kriteria BCNF; (2) Jika setiap atribut tidak mengalami ketergantungan pada banyak nilai. 5. Bentuk 5NF. Kriteria relasi 3NF adalah jika kerelasian antar data dalam relasi tersebut tidak dapat direkonstruksi dari struktur relasi yang memuat atribut yang lebih sedikit. 6. Bentuk DKNF. Kriteria relasi DKNF adalah jika setiap batasan dapat disimpulkan secara sederhanaa dengan mengetahui sekumpulan nama atribut dan domainnya selama menggunakan sekumpuan atribut pada kuncinya. Menurut

James

Martin

(1975),

penerapan

normalisasi

dapat

mengakibatkakn efek samping yang tidak diharapkan, yaitu: (1) Munculnya duplikasi rinci data pada atribut FK; (2) Kemungkinan tidak terpenuhinya integritas referensial (referential integrity); (3) Inefisiensi proses menampilkan kembali data-data dari dalam database; (4) Batasan penerapan pada DBMS. Kerelasian antar data yang disimpan dalam database sangatlah kompleks. Suatu schema dan subschema diperlukan untuk mendeskripsikan hubungan logik antar data dalam database. Schema memberikan deskripsi hubungan logik antar data dalam database secara lengkap, termasuk di dalamnya nama dan deskripsi dari semua atribut, record, dan batasan nilai untuk semua aplikasi yang menggunakannya. Sedangkan subschema merupakan deskripsi terpisah dari atribut, record, dan batasan nilai yang akan digunakan oleh sebuah program aplikasi. Dengan demikian, dari sebuah schema dapat diturunkan ke dalam beberapa subschema. Suatu schema menunjukkan pandangan konseptual seorang

61

perancang, sedangkan subschema menunjukkan pandangan seorang application programer terhadap data yang digunakannya. Raymond McLeod dan George Schell (2001) menyatakan bahwa schema memuat deskripsi yang meliputi: (1) Nama field data; (2) Alias (nama lain yang digunakan untuk field data yang sama); (3) Tipe data (numerik atau alphabet); (4) Jumlah digit pada posisi angka; (5) Jumlah digit pada posisi desimal; (6) Sejumlah aturan integritas. Sebuah relasi RDBM direpresentasikan sebagai sebuah tabel datar yang memuat beberapa keterangan, yaitu: (1) Nama relasi; (2) Kunci-kunci relasi (tidak selalu dituliskan); (3) Kunci-kunci indeks (tidak selalu dituliskan); (4) Sejumlah record (elemen data/entri dalam bentuk baris-baris data); (5) Namanama atribut. Notasi untuk schema dan subschema adalah sebagai berikut: namarelasi_schema : (namaatribut1 tipe[ukuran]1, namaatribut2 tipe[ukuran]2, ...., namaatributn tipe[ukuran]n, foreign key (namaatributfk) references namarelasiinduk, primary key (namaatributpk))

Keterangan: namarelasi : menyatakan nama relasi schema : menyatakan schema (bisa juga subschema) namaatribut1, .. N : menyatakan nama-nama atribut dalam relasi yang dituliskan secara berurutan dari kiri ke kanan tipe[ukuran]1, ..N : menyatakan batasan domain pada setiap atribut yang dituliskan secara berurutan dari kiri ke kanan sesuai urutan nama atribut dalam relasi foreign key : menyatakan foreign key namaatributFK : menyatakan nama atribut yang digunakan sebagai FK untuk menghubungkan dengan relasi induknya references : menyatakan mereferensi ke namarelasiinduk : menyatakan nama relasi induk yang direferensi primary Key : menyatakan primary key namaatributPK : menyatakan nama atribut yang digunakan sebagai PK dalam relasi

2.3. Pandangan Tentang Kerjasama Sistem Informasi Akademik Contoh-contoh implementasi SIAKAD di beberapa PT di atas, memberikan gambaran bahwa secara garis besar fungsi pengolahan dan fungsi keluaran dalam SIAKAD hampir sama. SIAKAD memiliki fungsi mengolah

62

transaksi terkait dengan kegiatan akademik, memelihara file histori akademik, menghasilkan keluaran untuk keperluan di bidang akademik, dan menyediakan interaksi user-pengolah. SIAKAD memiliki fungsi keluaran menghasilkan berbagai dokumen transaksi, laporan rutin, jawaban atas pertanyaan rutin, laporan adhoc, jawaban atas pertanyaan adhoc, serta dialog user-machine, yang terkait dengan kegiatan akademik. Pada sisi lain, harapan masyarakat terhadap informasi dalam website perguruan tinggi pada dasarnya juga hampir sama, yaitu meliputi informasi jurnal, laporan penelitian, karya ilmiah, organisasi, perkembangan studi mahasiswa, serta kegiatan non-akademis. Pemahaman

seperti

ini

memunculkan

sebuah

gagasan

tentang

kemungkinan dikembangkannya kerjasama pengembangan dan penggunaan SIAKAD antar PT yang dapat diimplementasikan dengan memanfaatkan jaringan internal AI3-Indonesia. Tujuan yang ingin dicapai adalah memanfaatkan jaringan internal AI3-Indonesia, menghemat biaya pengembangan aplikasi SIAKAD, dan menjadi basis penyajian informasi lembaga, dimana informasi akademik unik lembaga ada dalam SIAKAD. Gagasan kerjasama SIAKAD ini meliputi lima subsistem, yaitu: Ujian Seleksi Masuk, Rencana Studi, Dosen, Perkuliahan, serta Lulusan, seperti ditunjukkan pada Gambar 2.28.

63

Gambar 2.28: Subsistem dalam gagasan kerjasama Sistem Informasi Akademik Subsistem Ujian Seleksi Masuk dapat menggunakan contoh pada UMTPN (sekarang SPMB). Bentuk kerjasama yang dapat dilakukan meliputi pengelolaan admistrasi bersama, sharing database peserta, ujian on-line, serta bank soal untuk Ujian Seleksi Masuk. Kerjasama pada Subsistem Rencana Studi diharapkan dapat memenuhi kebutuhan masyarakat memperoleh informasi tentang bidang studi tertentu secara cepat tidak berdasarkan kelembagaan. Untuk menyajikan informasi ini dapat memanfaatkan data yang sudah ada di DIKTI dan KOPERTIS. Subsistem ini menekankan pada penyajian informasi yang informatif bagi calon konsumen, sehingga bersifat search-able. Kerjasama pada Subsistem Dosen menekankan pada penyajian informasi pengembangan Dosen dalam aspek Pendidikan dan Pengajaran dan Karya Ilmiah. Dalam hal ini Dosen adalah sebagai pribadi yang berkarya, bukan Lembaga yang mempekerjakan Dosen. Kerjasama pada Subsistem Perkuliahan dapat dilakukan pada beberapa hal, antara lain administrasi kegiatan perkuliahan on-line, bahan kuliah on-line, tugas on-line, serta nilai on-line. Kerjasama pada Subsistem Lulusan terkait dengan dua hal,

64

yaitu lulusan-wisudawan merupakan tenaga kerja segar, dan alumni memerlukan pengakuan almamater. Hal penting dalam subsistem ini adalah bahwa atribut dalam record database untuk mahasiswa, wisudawan, dan alumni hanya berbeda pada status_lulus (= True/False). Keputusan akhir gagasan ini masih menunggu kebulatan kebijakan dan gerilya dalam teknis menyusun database bersama. Strategi pengembangan yang perlu diperhatikan dalam pengembangan kerjasama Sistem Informasi Akademik ini meliputi dua aspek penting, yaitu teknologi informasi bersifat independen (terdefinisi, standard) dan berbasis web (web-based) dan kebijakan mengenai brainware ditetapkan berdasarkan kebutuhan teknis. Model database untuk kerjasama Sistem Informasi Akademik ini dapat digambarkan seperti ditunjukkan pada Gambar 2.29.

WEB Gateway

PTS-B

PTS-C

Network AI3-Indonesia

PTS-A

Internet

Pelaporan, Akreditasi

DIKTI, KOPERTIS

Gambar 2.29: Model database untuk kerjasama Sistem Informasi Akademik Pada akhirnya realisasi dari gagasan kerjasama Sistem Informasi Akademik ini diharapkan akan memberikan tiga kesimpulan penting, yaitu publikasi dari data mentah Sistem Informasi Akademik bersifat independen terhadap kebijakan lembaga, penyusunan modul-modul Sistem Informasi

65

Akademik bersifat applicable di semua lembaga Perguruan Tinggi, dan pengakuan terhadap integritas dan keberadaan pribadi dosen dan mahasiswa (http://home.unpar.ac.id/~gatut/makalah/sia-ai3-1.ppt).

2.4. Database dan SIM Dalam konsep SIM, Gordon B. Davis (1987) menyatakan bahwa salah satu bagian penting dalam SIM adalah masukan (input), yaitu berupa data yang kemudian akan disimpan sebagai database. Gordon B. Davis (1987) juga menyatakan bahwa berdasarkan komponen fisik penyusunnya, SIM terdiri atas sejumlah komponen, salah satunya adalah berkas (file), yaitu sekumpulan data yang disimpan dengan cara-cara tertentu dalam media penyimpan sekunder (storage) sehingga dapat digunakan/ditampilkan kembali dengan cepat dan mudah. Terkait dengan elemen operasional fungsi pengolahan SIM, Gordon B. Davis (1987) menyatakan bahwa salah satu fungsi pengolahan pada SIM adalah pemeliharaan file historis yaitu data masa lampau dalam database. Sementara itu, Raymond McLeod Jr. dan George Shell (2001) menyatakan bahwa salah satu sumber daya konseptual informasi dalam organisasi adalah berupa database. Dapat dipahami bahwa database merupakan sumber daya penting dalam SIM.

2.5. Perancangan Database Untuk SIM Menurut Brian Mullen (2005), penyusunan database merupakan tugas multidisipliner. Pada satu sisi, perancang database sebagai bagian staf teknik memahami konsep database dengan baik, tetapi sering tidak mengetahui

66

bagaimana membuat data relevan bagi orang lain dalam organisasi, atau bagaimana data dapat disimpan dan diakses secara cepat. Pada sisi lain, para pengguna mengetahui data apa yang dibutuhkannya, tetapi jarang yang dapat mengkomunikasikannya dengan baik kepada perancang database, dan para pengguna tidak mengetahui permasalahan-permasalahan yang ditimbulkan oleh kebutuhannya. Pertemuan antara staf teknik dan para pengguna merupakan kegiatan penting untuk mendapatkan kesamaan persepsi database untuk sistem dalam organisasi (http://www.gowerpub.com/pdf/pidmc2.pdf). Brian Mullen (2005) juga menyatakan, bahwa rancangan database yang benar akan memberikan landasan yang solid untuk SIM. Menurut Jan L. Harrington (2004), suatu rancangan database yang buruk akan mengakibatkan efek negatif, antara lain: (1) Munculnya kerangkapan data; (2) Munculnya inkonsistensi data; (3) Munculnya permasalahan pada penyisipan data; (3) Munculnya permasalahan pada penghapusan data; (4) Pengunaan namanama yang sulit dipahami (tidak bermakna) pada subyek data akan menyulitkan pada

saat

perubahan

(http://www.utexas.edu/academic/cit/howto/resources

/database/relational.answers.pdf). Dalam referensi yang lain, Abraham Silberschatz, Henry F. Korth, dan S. Sudarshan (2001) menyatakan bahwa perancangan database relasional diperlukan untuk mendapatkan sekumpulan schema relasi yang baik. Rancangan yang buruk akan mengakibatkan perulangan informasi dan tidak dapat menampilkan kembali informasi tertentu. Tujuan utama perancangan database adalah: (1) Menghindari kerangkapan data; (2) Menjamin bahwa kerelasian antar atribut dapat

67

direpresentasikan; (3) Memberikan fasilitas pengecekan batasan integritas pada proses update. Sementara itu, J. L. Whitten & L. D. Bentley (1998), menyatakan bahwa tujuan dan prasyarat perancangan database adalah: (1) Database harus memberikan efisiensi media penyimpan (storage), update, dan penampilan kembali data-data; (2) Database harus andal, yaitu memiliki integritas tinggi yang memberikan kepercayaan bagi para pengguna terhadap data; (3) Database harus dapat beradaptasi (adaptable) dan dapat berkembang (scaleable) untuk memenuhi kebutuhan-kebutuhan baru dan aplikasi-aplikasi. Untuk memperoleh SIM yang baik, maka pengembang SIM perlu memahami metode perancangan database yang baik, yaitu: (1) Mengidentifikasi kebutuhan informasi pada sebuah bisnis; (2) Merancang database relasional yang didasarkan pada kebutuhan bisnis; (3) Membuat dokumentasi database; (4) Meningkatkan fleksibilitas database untuk mengantisipasi perubahan; (5) Menyederhanakan database dengan jumlah tabel; (6) Membangun database relasional dan menyesuaikannya untuk memperoleh kinerja yang optimal; (7) Meningkatkan kinerja database dengan indexing dan mengkontrol kerangkapan; (8)

Mengurangi

beaya

pengembangan

software

dengan

generalisasi

(http://www2.cstudies. ubc.ca/~mullen/IEDBS.html). Menurut Jan L. Harrington (2004), sebagian besar software alat bantu rekayasa berbantuan komputer (Computer-Aided Software Engineering/CASE) menyediakan fasilitas untuk membuat dokumentasi rancangan database, yaitu: (1) Kamus data (Data Dictionary/DD); (2) Kebutuhan pengguna; (3) Diagram Aliran

68

Data/DAD (Data Flow Diagram/DFD); (4) Bagan struktur (structure chart); (5) Model data (data model); (6) Prototipe tampilan layar; (7) Model keadaan (state model); (8) Diagram tugas (task diagram); (9) Diagram kelas (class diagram); (10) Diagram obyek (object diagram) (http://www.utexas.edu/academic/cit/howto /resources/database/relational.answers.pdf). Dalam referensi yang lain, Raymond McLeod dan George Schell (2001) menyatakan bahwa penyusunan database dapat dilakukan dengan menggunakan dua pendekatan, yaitu: (1) Pendekatan berorientasi proses (pendekatan pemecahan permasalahan); (2) Pendekatan model perusahaan. Selanjutnya, penyusunan database dilakukan melalui tiga langkah utama, yaitu: (1) Mendeskripsikan data; (2) Memasukkkan data; (3) Menggunakan database (menggunakan bahasa query, QBE, atau DML). Menurut Jan L. Harrington (2004), sebuah entitas dalam database relasional tidak dapat memiliki atribut banyak nilai (multivalued attribute), solusinya adalah dengan membuat sebuah entitas baru untuk menyimpan nilainilai tersebut. Entitas baru tersebut menyimpan instan yang memiliki banyak nilai dan yang lain untuk menyimpan atribut-atributnya. Selanjutnya, indeks dapat digunakan untuk meningkatkan kinerja database. Keuntungan penggunaan indeks adalah mempercepat akses nilai-nilai data dalam satu atau gabungan beberapa kolom. Indeks memuat sebuah daftar kunci yang memungkinkan DBMS mengecek record dalam database secara langsung, tidak harus berurutan mulai dari awal. Sekalipun demikian, penggunaan indeks memiliki kelemahan, yaitu memerlukan tambahan tempat (space) dalam database. Database juga harus

69

selalu disusun kembali setiap kali dilakukan operasi data (insert, modify, atau delete), sehingga kinerjanya menjadi lebih lambat (http://www.utexas.edu /academic/cit/howto/resources/database/relational.answers.pdf). Berdasarkan penelitian yang dilakukan oleh Brian Mullen (2005), diketahui bahwa perbedaan tingkat kepakaran perancang database dan perbedaan kebutuhan para pengguna merupakan penyebab utama rancangan database tidak dapat bersifat fleksibel. Rancangan database yang tidak fleksibel akan memberikan dampak pada dana dan waktu untuk pemeliharaan database. Normalisasi database akan menghasilkan struktur database yang sangat banyak dan

kompleks.

Meskipun

demikian,

sedapat

mungkin

database

harus

dinormalisasi. Jika dua buah data dapat direlasikan ke sebuah data lain, maka untuk memperoleh fleksibilitas struktur database, akan lebih baik menyimpan data dalam beberapa file daripada menyimpannya di dalam sebuah file dalam database (http://www.gowerpub.com/pdf/pidmc2.pdf). Berikut adalah saran umum yang diberikan oleh Brian Mullen (2005) untuk memperoleh rancangan struktur tabel database yang fleksibel, yaitu: (1) Meningkatkan fleksibilitas database dimana kebutuhan-kebutuhan baru dapat diakomodasi dengan tabel-tabel database yang ada; (2) Mengurangi beaya pembuatan dan pemeliharaan aplikasi-aplikasi; (3) Meningkatkan penggunaan kembali dan penggunaan bersama antar aplikasi; (4) Mengurangi software yang dibutuhkan untuk membuat aplikasi; (5)Mengurangi duplikasi dan inkonsistensi informasi (http://www2.cstudies.ubc.ca/~mullen/IEDBS.html#General Tables).

70

Menurut J. L. Whitten & L. D. Bentley (1998), perancangan database untuk CBIS berbeda dengan perancangan database konvensional (berkas). Dalam berkas file-file database dibuat untuk masing-masing aplikasi, sedangkan dalam database sistem-sistem aplikasi dibuat dengan memanfaatkan sebuah database, seperti ditunjukkan pada Gambar 2.30.

Information System File

File

Information System

File

Information System

Database (consolidated & integrated data from files)

Information System

File Information System

Gambar 2.30: File konvensional versus database J. L. Whitten & L. D. Bentley (1998) juga menyatakan bahwa keuntungan maksimal dari database hanya bisa dicapai jika database dirancang dengan baik dan benar. Hasil akhir sebuah rancangan database disebut sebagai schema, yaitu sebuah blueprint untuk database. Perancangan database adalah menterjemahkan model data yang dikembangkan pada tahap definisi ke dalam struktur tabel database yang didukung oleh teknologi database (bahasa dan alat bantu) yang dipilih. Database menyediakan entitas dan kerelasian antar entitas untuk implementasi teknik. Dengan demikian, data merupakan bagian dari sumber daya yang harus dikontrol dan dikelola dengan baik.

71

Selanjutnya, J. L. Whitten & L. D. Bentley (1998) menyatakan bahwa prototipe bukanlah merupakan alternatif yang baik untuk menyusun schema database, dan saat schema telah lengkap, maka suatu prototipe database biasanya dapat dibangkitkan (generate) sangat cepat. Sebagian besar DBMS modern telah menyediakan fasilitas yang lengkap berupa database menu-driven yang secara otomatis akan membuat DDL dan prototipe database dari DDL tersebut. Kemudian database dapat diuji menggunakan data-data pengujian, baik untuk menguji prototype, input, output, tampilan layar, dan komponen sistem lainnya. Menurut Paul Litwin (2003), perancangan database lebih merupakan suatu seni daripada suatu ilmu pengetahuan. Sekalipun tidak mengungkap seluruh tahapan dalam proses perancangan, Paul Litwin memberikan sebuah kerangka kerja yang sesuai digunakan dalam perancangan database, yaitu sebagai berikut (http://r937.com/relational.html): 1. Pelajarilah proses bisnis dan proses lain dalam organisasi untuk mencoba membuat model. 2. Tulislah pernyataan mendasar atau misi yang harus dilakukan oleh sistem. Kemudian dilanjutkan dengan membuat daftar kebutuhan pada sistem. 3. Mulailah membuat form entri data. Jika aturan-aturan dalam sistem memerlukan lay out berbentuk tabel, tambahkan tabel yang diperlukan tersebut. Jika sistem yang ada belum terkomputerisasi, maka gunakan sistem manual yang ada sebagai dasar perancangan tabel (umumnya tabel dalam sistem manual berada dalam bentuk tidak normal). Jika sistem telah terkomputerisasi, maka gunakan tabel-tabel database yang ada sebagai acuan.

72

Sekalipun tabel-tabel database belum normal, ini akan lebih memudahkan daripada dalam sistem manual. Kemudian cetaklah schema, tabel, dan form entri data yang ada untuk digunakan dalam proses perancangan. 4. Berdasarkan form tersebut, rancanglah tabel-tabel database dengan sekaligus mencoba menerapkan teori normalisasi. Setiap tabel hanya digunakan untuk mendeskripsikan sebuah entitas. 5. Perhatikan seluruh laporan yang tercetak pada kertas atau komputer. 6. Pastikan bahwa setiap data dalam laporan tersedia di dalam tabel. Jika data belum tersedia, tambahkan data tersebut dalam tabel-tabel yang ada atau buatlah tabel baru. 7. Tambahkan dan isikan beberapa baris data pada setiap tabel. 8. Mulailah melakukan proses normalisasi. Pertama, identifikasikan CK untuk setiap tabel, dan kemudian pilihlah PK. Pilihlah PK yang minimal, stabil, sederhanaa, dan familier. Pastikan bahwa nilai dalam PK tidak akan pernah muncul berulang. 9. Jika diperlukan, tambahkan FK untuk merelasikan antar tabel. Gambarlah kerelasian antar tabel. Jika kerelasian berjenis many-to-many, maka buatlah tabel penghubung. 10. Pastikan bahwa tabel memenuhi 1NF, yaitu seluruh atribut bernilai atomik dan tidak memuat grup perulangan. Jika diperlukan, pecahlah tabel untuk memperoleh 1NF. 11. Pastikan

bahwa

tabel

memenuhi

2NF,

yaitu

setiap

tabel

hanya

mendeskripsikan sebuah entitas dan semua atribut non-key bergantung

73

sepenuhnya (FFD) pada PK. Jika diperlukan, pecahlah tabel untuk memperoleh 2NF. Jika tabel memiliki PK berupa kunci komposit, maka pecahlah PK menjadi atribut-atribut yang seluruhnya ditempatkan pada tabel itu juga. 12. Pastikan bahwa tabel memenuhi 3NF, yaitu hilangkan atribut yang nilainya dapat dihitung dan hilangkan atribut yang bersifat mutual dependent dengan cara membuat tabel lookup. 13. Gambarkan kembali kerelasian antar tabel hasil normaliasi. 14. Buatlah tabel menggunakan alat bantu yang dipilih (misal, menggunakan Microsoft Access atau lainnya). Isikan contoh-contoh data dalam tabel. 15. Buatlah prototipe query, form, dan report. Tahap ini mungkin perlu mendefinisikan ulang agar sesuai dengan kebutuhan. 16. Berikan kepada para pengguna agar dievaluasi. Jika diperlukan, ulangi kembali tahap 8-12. 17. Kembali ke rancangan tabel dan aturan bisnis. 18. Buatlah form, report, dan query final. Kembangkan program aplikasi. Jika diperlukan, ulangi kembali perancangan yang telah dibuat. 19. Pengujian oleh para pengguna. Jika diperlukan, ulangi kembali seluruh tahapan perancangan yang telah dilakukan. 20. Serahkan hasil final. Paul Litwin (2003) juga menyatakan bahwa penggunaan model RDBM dalam perancangan database akan memberikan beberapa keuntungan, antara lain: (1) Entri data, update, dan penghapusan data akan lebih efisien; (2) Penampilan

74

kembali, peringkasan, dan pelaporan data akan lebih efisien; (3) Jika database dirancang dengan menggunakan model yang diformulasikan dengan baik, maka perilakunya akan dapat diprediksi; (4) Jika informasi disimpan dalam database (bukan dalam program aplikasi) maka database memiliki dokumentasi tersendiri; (5) Perubahan pada schema database dapat dilakukan dengan lebih mudah. Dalam referensi yang lain, Jun Yang (1999) menyatakan bahwa penyusunan database dapat dilakukan melalui empat tahapan, yaitu: (1) Memahami domain dunia nyata yang akan ditangkap; (2) Menspesifikasikan domain dunia nyata tersebut dengan menggunakan model data (menggunakan ER_M atau Object Definition Language/ODL); (3) Menterjemahkan spesifikasi ke model database (relasional, ODL); (4) Membuat schema DBMS dan mengisi data (http://www-db.stanford.edu/~ullman/fcdb/spr99/lec2.pdf). Dengan menggunakan meta model, penelitian Olaf Herden (2001) telah berhasil mendefinisikan dan mengukur aspek-aspek kualitas schema berorientasi obyek (object oriented) suatu database, dan mengusulkan sebuah proses untuk melakukan tinjauan dan pengukuran aspek kualitas schema berorientasi obyek suatu database. Aspek yang relevan untuk pengukuran kualitas schema berorientasi obyek suatu database yang dimaksud ditampilkan dalam Tabel 2.5. Sedangkan aspek-aspek relevan yang lain namun tidak sesuai untuk diukur ditampilkan dalam Tabel 2.6. Menurut Olaf Herden (2001), pengukuran pada aspek-aspek dimaksud tidak dapat dilakukan secara otomatis. Di sisi lain, pengukuran harus dilakukan secara obyektif. Dalam hal ini, diasumsikan bahwa reviewer memiliki kedalaman pengetahuan dan tidak melakukan penilaian hanya

75

berdasarkan anggapan saja (prejudice). (http://www.iro.umontreal.ca/~sahraouh /qaoose01/Herden.PDF). Tabel 2.5: Aspek-aspek kualitas schema database berorientasi obyek yang sesuai untuk dilakukan pengukuran Kriteria Kebenaran (correctness) Konsistensi (consistency)

Relavansi (relevance)

Jangkauan (scope)

Tingkat detail (level of detail) Kelengkapan (completeness) Minimalitas (minimality) Kemampuan untuk diintegrasikan (ability of integration)

Kemampuan untuk dibaca (readability) Sumber: Olaf Herden (2001)

Deskripsi Merupakan aspek teknik, apakah semua aspek dimodelkan secara benar sesuai dengan kebutuhan dan batasan sistem. Aspek ini dapat digunakan untuk mengukur semua schema. Pengukuran dilakukan menggunakan kepakaran dengan meninjau tingkat kedalaman pengetahuan pada seluruh aspek teknik. Merupakan aspek teknik, apakah semua aspek dalam model terbebas dari kontradiksi. Aspek konsistensi dan kebenaran sangat penting untuk mengukur apakah schema diterima oleh pengguna atau tidak. Pengukuran dilakukan menggunakan kepakaran teknik dengan menganalisis konsistensi setiap aspek teknik pada model dan membandingkannya dengan aspek teknik berikutnya. Merupakan aspek teknik, apakah aspek-aspek teknik pada schema relevan digunakan. Aspek ini penting untuk mengetahui apakah schema diterima oleh pengguna atau tidak. Pengukuran dilakukan menggunakan kepakaran teknik untuk menentukan seluruh aspek yang relevan dan membandingkannya dengan schema. Apakah jangkauan schema telah sesuai dengan kebutuhan pengguna. Aspek ini penting untuk mengetahui apakah schema diterima oleh pengguna atau tidak. Lingkup schema bersifat relatif mengacu pada tujuan proyek. Pengukuran dilakukan menggunakan kepakaran untuk menentukan seluruh kebutuhan proyek dan membandingkannya dengan schema. Apakah tingkat detail schema telah sesuai. Aspek ini penting untuk mengetahui apakah schema diterima oleh pengguna atau tidak. Pengukuran dilakukan menggunakan kepakaran teknik untuk menentukan tingkat detail yang diinginkan dan membandingkannya dengan schema. Apakah schema telah lengkap (dengan mengacu pada kebutuhan). Aspek ini penting untuk mengetahui apakah schema dapat diterima oleh pengguna atau tidak. Pengukuran dapat dilakukan dari aspek jangkauan dan tingkat detail (sebelumnya). Apakah schema dimodelkan secara kompak dan tidak ada perulangan. Aspek ini penting karena schema konseptual harus tepat. Pengukuran dilakukan mengunakan kepakaran teknik untuk mengecek apakah terdapat aspek-aspek yang dimodelkan secara berulang. Apakah schema telah disesuaikan untuk standarisasi dalam organisasi secara menyeluruh atau pemodelan. Aspek ini tergantung pada konteks proyek atau organisasi, yaitu apakah lebih banyak terlibat pada asosiasi ekonomi atau berorientasi internasional, tetapi yang lebih relevan jika memiliki kemampuan untuk diiintegrasikan. Pengukuran dilakukan untuk menentukan apakah penggunaan nama-nama hanya dapat digunakan untuk cabang atau dapat diterima secara internasional. Apakah semua istilah dalam schema dijelaskan atau tidak. Aspek ini penting, khususnya untuk dialog dengan staf teknik dan orang yang datang belakangan. Pengukuran dilakukan dengan meninjau dokumen untuk menentukan apakah setiap aspek mudah dipahami.

76

Tabel 2.6: Aspek-aspek kualitas schema database berorientasi obyek yang tidak sesuai untuk dilakukan pengukuran Kriteria Kemampuan diperluas (extensibility) (Dapatkah kebutuhan baru dapat diintegrasikan ke dalam schema secara mudah?) Kemampuan digunakan kembali (reusability) (Dapatkah bagian-bagian schema digunakan untuk schema baru?) Pengelolaan schema (Apakah adminsitrasi, penggunaaan, dan update mungkin dilakukan pada schema?) Kemampuan dirubah (transformability) (Mungkinkah untuk mengubah schema ke lapis logik?) Normalisasi (normalisation) (Apakah schema memenuhi aturan normalisasi?)

Alasan ketidaksesuaian Sangat sesuai untuk setiap schema, karena 80% beaya SIM digunakan untuk pemeliharaan. Namun orientasi obyek sebagai model data untuk level konseptual baik digunakan untuk dapat diperluas. Meskipun sangat penting untuk menjaga kemungkinan di kemudian hari, namun tidak sesuai untuk ditinjau. Mirip pada kemampuan diperluas, orientasi obyek sebagai model data level konseptual baik digunakan untuk dapat digunakan kembali. Pengelolaan schema sangat relevan, khususnya mengacu pada pengembangan menyeluruh. Ini harus menyediakan alat bantu model atau tersimpan. Tinjauan hanya dapat dicek pada sejumlah versi. Kemampuan diubah penting karena schema konseptual hanya membuat definisi saat perubahan. Algoritma perubahan khusus harus mendasari metodologi perubahan. Kriteria ini sangat relevan dalam RDBM, sehingga penggunaan ER_M atau perluasannya sebagai model konseptual pengecekan aturan normalisasi harus menjadi bagian yang ditinjau. Tetapi tidak relevan untuk schema orientasi obyek, karena tidak ada bentuk normal yang diterima untuk schema orientasi obyek.

Sumber: Olaf Herden (2001)

2.6. Verifikasi Struktur Database Verifikasi struktur database adalah suatu proses memverifikasi lay out database apakah benar dan tepat sesuai dengan situasi-keadaannya. Verifikasi database melibatkan pengecekan rancangan database mengikuti praktek terbaik yang diusulkan oleh para pakar industri dan kebutuhan-kebutuhan khusus yang meyakinkan organisasi atau proyek; serta memberikan jaminan bahwa struktur database tidak diubah secara tidak terduga. Lebih khusus, verifikasi struktur database adalah proses untuk mengecek bahwa item-item diindeks dengan tepat; nilai-nilai disimpan dalam tipe data yang tepat; hubungan antar tabel-tabel diekspresikan dengan semestinya; dan seterusnya. Jika struktur database dibuat

77

mengikuti praktek yang terbaik, maka beberapa permasalahan yang terkait dengan database akan dapat dihindari. Sebagai contoh adalah: (1) Indeks yang tepat akan mempercepat kecepatan query (khususnya database berukuran besar); (2) Normalisasi database sesuai digunakan untuk menyederhanakan tabel-tabel pada saat perancangan (namun akan menambah jumlah tabel dan akan mengurangi integritas referensial); (3) Statemen SQL merupakan fasilitas untuk penamaan, pembentukan, dan pencegahan kesalahan tabel dan field logik selama pengujian, debugging, dan pemeliharaan; (4) Tipe dan ukuran data yang tepat akan menghindari kemungkinan kehilangan dan kesalahan nilai-nilai data; (5) Namanama tabel dan field yang berbeda dengan kata-kata kunci tercadang (reserved keywords) mencegah permasalahan fungsionalitas aplikasi. Perancangan struktur database memerlukan waktu yang lama dan upayaupaya perencanaan yang baik, yaitu bagaimana mengorganisasikan data ke dalam tabel-tabel; bagaimana merelasikan antar tabel; serta field mana yang akan diindek, disimpan, dan diakses. Jika struktur tabel perlu diubah secara tiba-tiba dan perubahan itu tidak terdeteksi sebelumnya, maka permasalahan ini dapat lebih mudah ditangani (http://www.parasoft.com/jsp/home.jsp).

2.7. Schema Database Universal Perancangan schema database yang bersifat universal untuk memenuhi berbagai macam kebutuhan para pengguna telah dilakukan dalam sebuah diskusi di Internet (http://www.webservertalk.com/message1055091-2.html). Diskusi diawali oleh pernyataan yang tidak mempercayai bahwa seseorang mampu

78

membangun tabel/view database yang multiguna dan tidak memerlukan perancangan ulang saat terjadi perubahan kebutuhan dari para pengguna ("Chris"
Contoh di atas memerlukan inventarisasi kembali seluruh aspek penanganan database pada alat bantu yang digunakan. Aspek kedua, terkait dengan penggunaan pendekatan dalam struktur data. Penggunaan XML (yang merupakan pendekatan tidak/semi terstruktur dimana sebuah file dapat memuat berbagai macam nilai yang dituliskan di antara tanda tag) akan menemui permasalahan jika file memuat tag yang tidak dikenali oleh aplikasi. Sehingga di kemudian hari perlu invetarisasi kembali konteks data dan sekaligus menjadi alasan mengapa sebaiknya kembali ke data terstruktur menggunakan tabel. Hal ini menjadi alasan, bahwa RDBM merupakan pendekatan paling umum untuk perancangan schema database. Selanjutnya diberikan dua contoh definisi tabel database, yaitu: DB1: create table Customer (cust_id integer primary key, cust_name varchar(30), voice_phone varchar(20), fax_phone varchar(20))

DB2:

create table Customer (cust_id integer primary key, cust_name varchar(30)) create table CustPhone (phone_id integer primary key, cust_id integer references Customer, phone_number_type char(5), phone_number varchar(20))

79

Dalam contoh tersebut, DB2 lebih fleksibel daripada DB1 dan schema tidak harus diubah apabila terjadi suatu saat terdapat tipe baru pada nomor telepon. Pada sisi yang lain, DB1 lebih sesuai digunakan dan lebih mudah diakses (menggunakan query) apabila aturan yang berlaku adalah customer hanya memiliki sebuah nomor telepon. Fleksibilitas akan mengurangi kebutuhan perubahan schema, program-program aplikasi, dan membuat schema menjadi lebih komunikatif. Aspek ketiga adalah terkait dengan penggunaan tipe data dalam schema tabel database. Permasalahannya adalah apakah semua tipe data harus didefinisikan secara eksplisit dalam struktur tabel atau dapat disembunyikan. Berikut adalah contoh yang relevan untuk dipikirkan, yaitu: DB1: create table Picture (pict_id integer primary key, pict_name varchar(30), .. dan seterusnya ... picture image)

DB2: create table Picture (pict_id integer primary key, pict_name varchar(30), .. dan seterusnya ...) create table Pixel (pict_id integer, pixel_id integer, pixel_color integer, primary key(pict_id, pixel_id))

Dalam DB1 kerumitan disembunyikan dari tipe data gambar, sedangkan dalam DB2 tipe data dituliskan secara eksplisit. Dalam sebagian besar kasus, pendekatan pada DB1 lebih disarankan. Pada sisi lain, tidak baik menyembunyikan tipe data untuk kasus seperti berikut: create table Customer cust_id integer primary key, cust_details cust_detail_datatype) select cust_details.getName() from Customer where cust_id=1

80

Sebenarnya, sah-sah saja menyembunyikan definisi tipe data, namun demikian untuk kasus terakhir ini bukan merupakan sebuah rancangan yang baik ([email protected]). Pendapat

tersebut

disanggah

oleh

Kenneth

Downs

(Ken)nneth@(Sec)ure(Dat)a(.com)), menurutnya pendekatan yang dipilih adalah tergantung pada permasalahan mana yang ingin diatasi. Schema tidak fleksibel dan tidak dapat memenuhi segala kebutuhan karena jenis kebutuhan apa yang akan terjadi di masa mendatang dan harus disiapkan dalam schema tidak diketahui. Sebuah pendekatan dapat digunakan, yaitu schema dirancang sesuai dengan kebutuhan dalam sistem dan mengungkapkan kelemahan-kelemahan yang terkait dengan struktur tabel untuk kebutuhan dalam jangka panjang. Fleksibilitas struktur

database

merupakan

sebuah

pilihan

yang

perlu

memikirkan

keseimbangan antara beban kerja, beaya, dan waktu yang diperlukan.

2.8. Fleksibilitas Rancangan Struktur Tabel Database Di dalam penelitiannya, Bo P. Weidema (2004) menyatakan bahwa perancangan struktur database yang fleksibel merupakan kriteria penting untuk memperoleh data yang berkualitas. Database biasanya dirancang untuk kebutuhan yang spesifik, namun akan digunakan untuk keperluan yang berbeda-beda. Pada saat menghubungkan antar unit proses, tidak dapat dihindari bagaimana menentukan kebutuhan input untuk sebuah unit proses yang diperoleh dari output unit proses lain, dan versi-versi yang berbeda. Menghubungkan input dan output pada unit-unit proses ini akan mengimplikasikan bagaimana masing-masing unit

81

proses saling terkait satu sama lain, sebagai aliran supplay dan demand antar proses. Apabila struktur tabel database yang digunakan untuk menyimpan data tidak memiliki struktur yang fleksibel, maka data tidak akan dapat digunakan untuk berbagai keperluan yang berbeda. Sebenarnya, dimungkinkan untuk mengkombinasikan berbagai proses dalam sistem tergantung pada pemahaman pada skenario dan kondisi relevan yang tepat. Terdapat dua persyaratan penting untuk memperoleh rancangan struktur tabel database yang fleksibel, yaitu: 1. Seluruh unit proses harus direpresentasikan dalam database, sehingga pilihan di antara unit proses yang men-supplay dan perubahan perilaku model dan perluasan sistem harus dapat ditangani. Dalam prakteknya, hal ini akan memerlukan kelengkapan data dalam database, database tidak hanya dapat digunakan oleh sebuah unit yang dikembangkan, namun dapat digunakan oleh unit-unit proses lainnya, sehingga keputusan-keputusan dapat diambil berdasarkan informasi yang lengkap. 2. Unit-unit proses tidak harus disatukan, tetapi harus dipelihara dimana hubungan antar unit proses dapat diubah sesuai kebutuhan para pengguna (http://www.lcafood.dk/processes/energyconversion/market.pdf). Sementara itu Bradley V. Stone (1998) menyatakan bahwa perencanaan dan pemikiran lebih lanjut dari perencanaan merupakan elemen penting dalam perancangan database untuk memudahkan perluasan database di kemudian hari. Menyatukan aspek kelayakan dan kemampuan suatu database merupakan hal yang sulit dikerjakan oleh perancang database. Pemikiran yang mendalam harus dilakukan selama perancangan untuk menjamin rancangan database mudah untuk

82

digunakan dan mudah untuk diperluas di kemudian hari. Selanjutnya, Bradley V. Stone (1998) memberikan arahan tentang perancangan database agar bersifat fleksibel untuk memenuhi kebutuhan di masa mendatang, yaitu: (1) Memecah database ke dalam unit-unit yang dapat dikelola; (2) Penggunaan file induk (master); (3) Penggunaan kunci dalam file; (4) Penggunaan field referensi untuk kemudahan pemeliharaan; (5) Penggunaan file logik terbatas; (6) Perubahan file fisik (http://www.mcpressonline.com/[email protected] @.21d093f8).

2.9. Pendekatan Dalam Pengukuran Kualitas Informasi Dalam beberapa literatur, istilah kualitas data dan kualitas informasi sering ditemukan dan digunakan sebagai sinonim. Definisi baku mengenai istilah kualitas informasi belum ditemukan, tetapi umumnya kualitas informasi dipandang sebagai konsep multidimensional dan bertingkat (Te’eni (1993), Wang, Reddy and Kon (1995), Eppler and Wittig (2000)). Dalam hal ini terdapat tiga macam pendekatan yang berbeda yang dapat digunakan untuk menspesifikasikan kualitas

informasi,

yaitu

(Klesse,

Herrmann,

Brändli,

Mügeli,

Maier,

http://wotan.liu.edu/docis/dbl/iqiqiq/2004_418 _CIPACS.htm): 1. Pendekatan intuitif (intuitive approach), pendekatan ini mengusulkan atributatribut kualitas informasi yang didasarkan pada wawasan/pengetahuan subyektif seseorang. Pendekatan ini telah digunakan dalam penelitian yang dilakukan oleh R.Y. Wang, M.P. Reddy, dan H.B. Kon (1995), H. Miller, (1996), T.C. Redman (1996), L.P. English (1999).

83

2. Pendekatan empiris (empirical approach), pendekatan ini bersifat kuantitatif yang diperoleh dari hasil survei. Pendekatan ini telah digunakan dalam penelitian yang dilakukan oleh R.Y. Wang, dan D.M. Strong, (1996), M. Helfert, G. Zellner, dan C. Sousa (2002). 3. Pendekatan teoritis (theoretical approach), pendekatan ini berusaha memunculkan usulan teori baru didasarkan pada teori-teori yang sudah ada. Pendekatan ini telah digunakan dalam penelitian yang dilakukan oleh D.P. Ballou, dan H.L. Pazer (1985), D. Te'eni (1993), Y. Wand, dan R.Y. Wang (1996), L. Liu dan L.N. Chi (2002), M. Klesse, C. Herrmann, P. Brändli, T. Mügeli, D. Maier (2005). Kelemahan utama pendekatan intuitif dan empiris adalah pengaruh tingkat pengetahuan peneliti terhadap penilaian yang diberikan. Sedangkan kelemahan pendekatan teoritis adalah kemungkinan terjadinya kesalahan pada teori baru yang diusulkan (Klesse, Herrmann, Brändli, Mügeli, Maier, http://wotan.liu.edu/docis /dbl/iqiqiq/2004_418_CIPACS.htm).

2.10. Acuan Dalam Penilaian Penilaian adalah suatu kegiatan membandingkan hasil pengukuran (skor) prestasi suatu obyek dengan acuan yang relevan. Dalam penilaian sifat suatu obyek, penggunaan bahan pembanding menjadi sangat penting. Bahan pembanding ini disebut acuan penilaian. Acuan penilaian yang dipakai dalam suatu penilaian dibedakan menjadi tiga, yaitu (diadopsi dari Blue Sheep® Ltd, www.bluesheep.com/cgi/news /show.php4?f=010102):

84

1. Penilaian Acuan Pokok (PAP) (Criterion Reference Evaluation) PAP adalah suatu penilaian yang membandingkan prestasi hasil pengukuran (skor) sifat suatu obyek dengan suatu patokan yang telah ditetapkan sebelumnya, yaitu suatu prestasi yang seharusnya dicapai. Dengan demikian PAP berorientasi pada suatu patokan atau batas yang sifatnya pasti atau absolut. Oleh karena itu penilaian patokan ini disebut juga Penilaian Acuan Mutlak (PAM) atau Penilaian Acuan Absolut (PAA). Berikut adalah skor dan peringkat yang umum digunakan dalam PAP, yaitu: Skor

Peringkat

80 – 100 70 – 79 60 – 69 50 – 59 0 – 49

Sangat Baik Baik Sedang / Cukup / Rata-rata Buruk Sangat Buruk

2. Penialaian Acuan Normal (PAN) (Normal Norm Reference Evaluation) Penilaian Acuan Normal (PAN) adalah suatu penilaian yang membandingkan prestasi hasil pengukuran (skor) sifat suatu obyek terhadap prestasi obyek lain dalam kelompoknya. Jadi dalam PAN suatu prestasi yang dapat dicapai oleh suatu obyek dalam kelompoknya baru dapat ditetapkan setelah suatu pengukuran dilakukan. Dengan demikian, PAN berorientasi pada prestasi real yang dapat dicapai oleh kelompok yang dinyatakan dalam rata-rata kelompok atau Mean (=M) berserta deviasi standarnya (=S) pada kurva normal. Prestasi rata-rata kelompok beserta deviasi standar pada kurva normal dipakai sebagai dasar untuk menentukan batas dan skor-skor lain berikut peringkatnya. Dengan demikian, PAN sangat bergantung pada M dan S. Prestasi rata-rata

85

kelompok (=M) dan deviasi standar sifatnya tidak pasti atau relatif. Oleh karena itu, penilaian ini sering disebut juga Penilaian Acuan Relatif (PAR). Dalam penggunaan PAN sebagai patokan penilaian, pertama-tama harus dicari rata-rata kelompok (=M) dan deviasi standar (=S), baru kemudian ditentukan rentangan konversi skor berdasarkan patokan berikut: Skor

Peringkat

Di atas M + 1.5 S Antara M + 0.5 S dan M + 1.5 S Antara M – 0.5 S dan M + 0.5 S Antara M – 1.5 S dan M – 0.5 S Di bawah M – 1.5 S

Sangat Baik Baik Sedang / Cukup /Rata-rata Buruk Sangat Buruk

3. Penilaian Acuan Kombinasi (PAK) PAK adalah suatu penilaian yang membandingkan prestasi hasil pengukuran (skor) sifat suatu obyek dengan memperhatikan prestasi prestasi minimal yang seharusnya dicapai suatu obyek dan memperhatikan prestasi yang dapat dicapai oleh kelompoknya. Dalam penggunaan PAK perlu ditentukan batas minimal prestasi dan batas nilai-nilai lainnya, yaitu: a. Batas minimal prestasi. Batas minimal prestasi dalam PAK terletak di antara M dan batas minimal prestasi yang seharusnya dicapai. Batas minimal prestasi akan ditentukan lebih tepat dengan memperhatikan perbedaan frekuensi mencolok antara M dan prestasi minimal yang seharusnya dicapai dalam suatu distribusi frekuensi skor. b. Batas nilai-nilai lainnya. Setelah batas minimal prestasi ditentukan, maka dapat ditentukan batas nilai-nilai lain di atas dan di bawah batas minimal prestasi dengan memperhatikan besar deviasi standar.

BAB III METODOLOGI PENELITIAN

3.1. Sumber Data Penelitian Sumber data dalam penelitian ini dikelompokkan menjadi 3 (tiga), yaitu: 1. Rancangan struktur database untuk SIAKAD kelompok Pertama, yaitu berupa rancangan struktur tabel database yang diperoleh dari hasil Penelitian Tesis mahasiswa Program Pasca Sarjana, Program Studi Ilmu Komputer, Jurusan Matematika dan Ilmu-ilmu Pengetahuan Alam, Fakultas Matematika dan Ilmu Pengetahuan Alam, Universitas Gadjah Mada, Yogyakarta. Jumlah data rancangan struktur tabel database kelompok ini sebanyak 10 (sepuluh) buah. 2. Rancangan struktur database untuk SIAKAD kelompok Kedua, yaitu berupa rancangan struktur tabel database yang diperoleh dari hasil Penelitian Skripsi mahasiswa Program Sarjana, Program Studi Teknik Infomatika, Institut Sains & Teknologi AKPRIND, Yogyakarta. Jumlah data rancangan struktur tabel database kelompok ini sebanyak 10 (sepuluh) buah. 3. Rancangan struktur database untuk SIAKAD kelompok Ketiga, yaitu berupa rancangan struktur tabel database yang diperoleh dari hasil Penelitian Tugas Akhir mahasiswa Program Studi Manajemen Infomatika & Teknik Komputer, Institut Sains & Teknologi AKPRIND, Yogyakarta. Jumlah data rancangan struktur tabel database kelompok ini sebanyak 8 (delapan) buah.

86

87

3.2. Data Penelitian 3.2.1. Data Penelitian Kelompok Pertama Berdasarkan Daftar Penelitian Tesis pada Program Studi Ilmu Komputer, Fakultas Matematika & Ilmu Pengetahuan Alam, Universitas Gadjah Mada, Yogyakarta, hingga tanggal 31 Desember 2005, sedikitnya terdapat 12 (dua belas) judul penelitian Tesis yang terkait dengan topik SIAKAD. Rancangan struktur tabel database Kelompok Pertama yang akan dianalisis dalam penelitian ini sebanyak 10 (sepuluh) buah, yaitu: 1. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Medi (2002) berjudul Rancangan Web Akademik dengan Basisdata Terdistribusi, selanjutnya disebut DATA_09_001. 2. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Asti Dwi Irfianti (2003) berjudul Rancang Bangun Sistem Informasi Akademik Menggunakan ORACLE Tools Berbasis Web dan WAP (Studi Kasus: STIKOM Surabaya), selanjutnya disebut DATA_09_002. 3. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Jatmika (2003) berjudul Perbandingan Analisis dan Desain Database Sistem Informasi Akademik Menggunakan Model Relasi Entitas dengan Model Berorientasi Obyek, selanjutnya disebut DATA_09_003. 4. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Muhamad

Rifai

Pengembangan DATA_09_004.

Katili Sistem

(2003) Infomasi

berjudul

Database

Akademik,

Terpadu

selanjutnya

untuk disebut

88

5. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Lanto Ningrayati Amali (2003) berjudul Sistem Informasi Jadwal Kuliah di PT dengan Pendekatan Berorientasi Obyek (Studi Kasus di IKIP Negeri Gorontalo), selanjutnya disebut DATA_09_005. 6. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Yuniansyah (2003) berjudul Sistem Informasi Akademik Berbasis Three-tier pada STMIK SIGMA Palembang, selanjutnya disebut DATA_09_006. 7. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Susi Erlinda (2003) berjudul Sistem Informasi Penmaru Berbasis Web pada STMIK-AMIK Riau Pekanbaru, selanjutnya disebut DATA_09_007. 8. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Suhirman (2004) berjudul Sistem Informasi Penilaian Akreditasi Program Studi Strata-1, selanjutnya disebut DATA_09_008. 9. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Murni (2004) berjudul Sistem Manajemen Informasi Berbasis Web untuk Pengelolaan Data Alumni STMIK Indonesia Padang, selanjutnya disebut DATA_09_009. 10. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Nana Katyadi Kurdi (2005) berjudul Rancang Bangun Sistem Informasi Administrasi Akademik (SIAKAD-2000) Berbasis Intranet untuk Universitas Lampung, selanjutnya disebut DATA_09_010.

89

3.2.2. Data Penelitian Kelompok Kedua Rancangan struktur tabel database untuk SIAKAD Kelompok Kedua diperoleh dari hasil penelitian Skripsi yang pernah dilakukan oleh mahasiswa Program Sarjana, Program Studi Teknik Infomatika, Institut Sains & Teknologi AKPRIND, Yogyakarta. Rancangan struktur tabel database Kelompok Kedua yang akan dianalisis dalam penelitian ini sebanyak 10 (sepuluh) buah, yaitu: 1. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Retno Rahayuningsih (2000) berjudul Rekayasa Komputerisasi KRS dan KHS Universitas X, selanjutnya disebut DATA_08_001. 2. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Suhendro Yudi S. (2000) berjudul Sistem Pengolahan Data Her-Registerasi Mahasiswa

pada

IST

AKPRIND

Yogyakarta,

selanjutnya

disebut

DATA_08_002. 3. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Oktavian Eka Saputra (2001) berjudul Perancangan Sistem Informasi Data Kebutuhan

Mahasiswa

Jurusan

Teknik

Informatika

IST

AKPRIND

Yogyakarta, selanjutnya disebut DATA_08_003. 4. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Zaini (2002) berjudul Perancangan Sistem Pendaftaran Mahasiswa Baru IST AKPRIND Yogyakarta Melalui Internet selanjutnya disebut DATA_08_04. 5. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Muhammad Suhud Baital (2003) berjudul Aplikasi Client/Server Pengolahan

90

Data Pendaftaran Praktikum pada Laboratorium Komputer 1-2 IST AKPRIND Yogyakarta, selanjutnya disebut DATA_08_005. 6. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Sudarto (2003) berjudul Sistem Pengolahan Data Penyelenggaraan Praktikum di Laboratorium Penelitian Operasional IST AKPRIND Yogyakarta, selanjutnya disebut DATA_08_006. 7. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh I Gusti Nyoman Rai Astawa (2003) berjudul Implementasi Wap pada Sistem Informasi Akademik Online (Studi kasus di Jurusan Teknik Informatika IST AKPRIND Yogyakarta), selanjutnya disebut DATA_08_007. 8. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Dewi Setya Handayani (2004) berjudul Analisis dan Perancangan Sistem Client/Server Pendaftaran Praktikum Laboratorium Komputer IV Institut Sains & Teknologi AKPRIND Yogyakarta dengan Menggunakan Visual Basic 6.0 dan MySql, selanjutnya disebut DATA_08_008. 9. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Yan Sophian (2004) berjudul Sistem Pendaftaran Mahasiswa Baru di IST AKPRIND Yogyakarta Secara Online, selanjutnya disebut DATA_08_009. 10. Rancangan struktur tabel database dalam penelitian yang dilakukan oleh Ninin Daniati (2005) berjudul Perancangan Sistem Informasi Pendaftaran Mahasiswa

Baru IST AKPRIND Yogyakarta Secara Online, selanjutnya disebut DATA_08_010.

91

3.2.3. Data Penelitian Kelompok Ketiga Rancangan struktur tabel database untuk SIAKAD Kelompok Ketiga diperoleh dari hasil penelitian Tugas Akhir yang pernah dilakukan oleh mahasiswa Program Diploma-3, Program Studi Manajemen Infomatika & Teknik Komputer, Institut Sains & Teknologi AKPRIND, Yogyakarta. Rancangan struktur tabel database Kelompok Ketiga yang akan dianalisis dalam penelitian ini sebanyak 8 (delapan) buah, yaitu: 1. Rancangan struktur tabel database dari penelitian yang dilakukan oleh Elfi Yulia (2000) berjudul Sistem Komputerisasi Pengolahan Data Penerimaan Mahasiswa di STT Komp. “TAKASINDO” Yogyakarta, selanjutnya disebut DATA_06_001. 2. Rancangan struktur tabel database dari penelitian yang dilakukan oleh Zainab Immawati Rufaidah (2002) berjudul Website Informasi Jurusan Manajemen Informatika & Teknik Komputer Program D-3 IST AKPRIND Yogyakarta, selanjutnya disebut DATA_06_002. 3. Rancangan struktur tabel database dari penelitian yang dilakukan oleh Ari Susilowati (2003) berjudul Perancangan Sistem Penyeleksian Mahasiswa Baru IST AKPRIND Yogyakarta Menggunakan Aplikasi Visual Basic 6.0, selanjutnya disebut DATA_06_003. 4. Rancangan struktur tabel database dari penelitian yang dilakukan oleh Orasafati Mendrofa (2003) berjudul Komputerisasi Data KRS Mahasiswa pada IAIN Sunan Kalijaga Yogyakarta, selanjutnya disebut DATA_06_004.

92

5. Rancangan struktur tabel database dari penelitian yang dilakukan oleh Ganda Gamaliel Soritua Sinaga (2005) berjudul Sistem Kegiatan Praktikum Berbasis Client Server di Laboratorium Komputer 1-2 IST AKPRIND Menggunakan Delphi 7.0 dan MySql, selanjutnya disebut DATA_06_005. 6. Rancangan struktur tabel database dari penelitian yang dilakukan oleh M. Riza Baihaqie (2003) berjudul Implementasi Midlet Java Sebagai Media Informasi Akademik Kampus IST AKPRIND, selanjutnya disebut DATA_06_006. 7. Rancangan struktur tabel database dari penelitian yang dilakukan oleh Muhtarom Ismani (2005) berjudul Entry KRS Melalui SMS, selanjutnya disebut DATA_06_007. 8. Rancangan struktur tabel database dari penelitian yang dilakukan oleh Puji Widodo (2005) berjudul Sistem Informasi Asisten Dosen Laboratorium Keperawatan

AKPER

Muhammadiyah

Klaten,

selanjutnya

disebut

DATA_06_008.

3.3. Metode Pengumpulan Data Pengumpulan data dalam penelitian ini dilakukan dengan menggunakan metode studi pustaka, yaitu dengan cara mempelajari dokumen bahan-bahan sumber pustaka yang terkait dengan penelitian dan masalah yang diteliti. Metode studi pustaka dilakukan untuk memperoleh petunjuk teori yang berhubungan dengan penelitian dan masalah yang diteliti dan data penelitian berupa data-data rancangan struktur tabel database untuk SIAKAD yang dikembangkan dalam penelitian-penelitian sebelumnya yang akan dianalisis.

93

3.4. Langkah Penelitian Penelitian ini dilaksanakan dengan langkah sebagai berikut: 1. Studi pendahuluan. Pada langkah ini dilakukan pengkajian teori/konsep SIM, SIAKAD, SIAKAD dalam peraturan perundang-undangan, database, perancangan database, serta fleksibilitas database. Pengkajian teori/konsep ini dilakukan sebagai dasar analisis fleksibilitas rancangan struktur tabel database untuk SIAKAD pada data penelitian. 2. Pengumpulan data. Pada langkah ini dilakukan pengumpulan data rancangan struktur tabel database untuk SIAKAD dengan menggunakan metode yang telah ditetapkan. 3. Identifikasi kebutuhan informasi (dan data) untuk SIAKAD. Pada langkah ini dilakukan identifikasi berbagai kebutuhan informasi (dan data) dalam SIAKAD, baik untuk kebutuhan internal maupun eksternal, untuk para pengguna pada seluruh tingkat kegiatan manajemen. 4. Identifikasi perubahan kebutuhan informasi (dan data) untuk SIAKAD. Pada langkah ini dilakukan identifikasi berbagai kemungkinan perubahan kebutuhan informasi (dan data) yang bersifat umum untuk SIAKAD, baik perubahan untuk kebutuhan internal maupun eksternal. Hasil pada tahap ini akan digunakan sebagai dasar untuk melakukan analisis fleksibilitas rancangan struktur tabel database untuk SIAKAD.

94

5. Analisis fleksibilitas rancangan struktur tabel database. Pada langkah ini dilakukan analisis fleksibilitas rancangan struktur tabel database untuk SIAKAD pada data penelitian yang berhasil dikumpulkan. Dalam penelitian ini, analisis fleksibilitas rancangan struktur tabel database dilakukan dengan menggunakan pendekatan intuitif (intuitive approach), yaitu penilaian yang didasarkan pada pengalaman atau pemahaman subyektif seseorang tentang fleksibilitas rancangan struktur tabel database (Klesse, Herrmann, Brändli, Mügeli, Maier, http://wotan.liu.edu/docis/dbl/iqiqiq /2004_418_CIPACS.htm). Analisis fleksibilitas rancangan struktur tabel database dilakukan oleh seorang Pakar dengan memberikan penilaian pada setiap atribut dalam seluruh rancangan struktur tabel yang dianalisis. Analisis fleksibilitas pada atribut dilakukan dengan langkah sebagai berikut: a. Tentukan apakah nilai elemen data yang disimpan dalam atribut memiliki kemungkinan terjadi perubahan format nilai rinci data pada atribut ataupun perubahan nilai rinci data pada atribut yang berpengaruh terhadap nilai rinci data pada atribut yang lain, baik yang terencana maupun tidak terencana, dalam jangka pendek maupun jangka panjang. Jika nilai elemen data yang disimpan dalam atribut memiliki kemungkinan terjadi perubahan diberikan nilai YA (=Y). Sebaliknya, jika nilai elemen data yang disimpan dalam atribut tidak memiliki kemungkinan terjadi perubahan diberikan nilai TIDAK (=T).

95

b. Berikan penilaian fleksibilitas apakah rancangan atribut yang dianalisis dapat memenuhi perubahan tersebut secara efisien/mudah. Jika atribut bersifat fleksibel, yaitu dapat diubah secara efisien/mudah, maka sifat fleksibel pada atribut diberikan nilai YA (=Y). Sebaliknya, jika atribut tidak dapat diubah secara efisien/mudah, maka maka sifat fleksibel pada atribut diberikan nilai TIDAK (=T). Selanjutnya, jika atribut diberikan nilai TIDAK (=T), maka berikan penjelasan mengapa atribut tersebut tidak fleksibel. c. Ulangi langkah a dan b hingga seluruh atribut dalam seluruh rancangan struktur tabel database selesai diberikan penilaian. Selanjutnya, berdasarkan penilaian tersebut, tingkat fleksibilitas rancangan struktur tabel database ditentukan secara kuantitatif (Klesse, Herrmann, Brändli, Mügeli, Maier, http://wotan.liu.edu/docis/dbl/iqiqiq/2004_418 _CIPACS.htm) dengan langkah sebagai berikut: a. Hitung

cacah

seluruh

atribut

(=JUMLAH_ATRIBUT)

dalam

rancangan struktur tabel database, cacah atribut yang memenuhi kriteria fleksibel yaitu yang memiliki penilaian YA (=CACAH_Y) dan cacah atribut yang tidak memenuhi kriteria fleksibel yaitu yang memiliki penilaian TIDAK (=CACAH_T). b. Hitung presentase atribut yang bersifat fleksibel (=PERSEN_Y). Perhitungan dilakukan dengan cara membagi cacah atribut yang memenuhi kriteria fleksibel (=CACAH_Y) dengan cacah seluruh atribut dalam seluruh tabel dalam sebuah rancangan struktur tabel

96

database (=JUMLAH_ATRIBUT). Hasilnya kemudian dikalikan dengan 100%. Formula yang digunakan adalah sebagai berikut: PERSEN_Y = (CACAH_Y / JUMLAH_ATRIBUT) * 100% c. Hitung presentase atribut yang bersifat tidak fleksibel (=PERSEN_T). Perhitungan dilakukan dengan cara membagi cacah atribut yang tidak memenuhi kriteria fleksibel (=CACAH_T) dengan cacah seluruh atribut dalam seluruh tabel dalam sebuah rancangan struktur tabel database (=JUMLAH_ATRIBUT). Hasilnya kemudian dikalikan dengan 100%. Formula yang digunakan adalah sebagai berikut: PERSEN_T = (CACAH_T / JUMLAH_ATRIBUT) * 100% d. Tetapkan tingkat fleksibilitas rancangan struktur tabel database. Dalam penelitian ini, tingkat fleksibilitas rancangan struktur tabel database ditentukan dengan menggunakan acuan Penilaian Acuan Pokok (=PAP), yaitu berorientasi pada suatu patokan nilai yang sifatnya pasti atau absolut. Dalam penelitian ini, tingkat fleksibilitas rancangan struktur tabel database ditentukan berdasarkan persentase cacah atribut yang memenuhi kriteria fleksibel (=PERSEN_Y), dengan membandingkan persentase cacah atribut yang memenuhi kriteria fleksibel (=PERSEN_Y) dengan suatu patokan yang telah ditetapkan sebelumnya, yaitu suatu tingkat fleksibilitas yang seharusnya dicapai oleh suatu rancangan tabel database. Idealnya, tingkat fleksibilitas yang seharusnya dicapai oleh suatu rancangan tabel database adalah 100% untuk nilai PERSEN_Y.

97

6. Perancangan usulan kerangka struktur tabel database untuk SIAKAD. Pada langkah ini disusun sebuah usulan kerangka rancangan struktur tabel database untuk SIAKAD yang relatif fleksibel terhadap perubahan kebutuhan informasi (dan data) untuk business rule yang bersifat umum di Perguruan Tinggi. Kerangka rancangan struktur tabel database yang diusulkan ini dirancang sedemikian rupa sehingga memenuhi kriteria database yang baik, yaitu berada dalam bentuk yang optimal, konsisten secara logik, sederhana dalam pemeliharaan, serta memenuhi karakteristik RDBM. 7. Penyusunan panduan perancangan struktur tabel database yang fleksibel. Pada langkah ini disusun suatu usulan kerangka kerja perancangan struktur tabel database yang bersifat umum, untuk memperoleh rancangan struktur tabel database yang bersifat fleksibel. 8. Perancangan, pengembangan, dan pengujian program aplikasi Pada langkah ini dilakukan perancangan dan pengembangan program aplikasi yang mendukung proses analisis fleksibilitas rancangan struktur tabel database. Selanjutnya program aplikasi diuji dengan menggunakan data-data penelitian yang berhasil dikumpulkan. Program aplikasi disebut benar jika output hasil program aplikasi sama dengan hasil analisis secara manual yang telah dilakukan sebelumnya. 9. Penyusunan dokumentasi. Pada langkah ini disusun dokumentasi laporan penelitian sesuai organisasi laporan penelitian yang direncanakan. Kriteria fleksibel untuk sebuah atribut adalah sebagai berikut:

98

1. Jika nilai elemen data dalam atribut mempunyai kemungkinan berubah [=Y], maka atribut disebut fleksibel jika memenuhi kondisi berikut; a. Jika atribut berupa kode, telah dilengkapi dengan tabel referensi b. Jika atribut berupa kode blok, setiap komponen dalam kode blok telah dipisahkan dan dilengkapi dengan tabel referensi 2. Jika nilai elemen data dalam atribut tidak mempunyai kemungkinan berubah [T], maka atribut disebut fleksibel jika memenuhi seluruh kondisi berikut; a. Jika atribut bernilai atomic, b. Jika atribut bernilai single value, c. Jika atribut disusun non repeated group, d. Jika atribut tidak terjadi redundancy, e. Jika atribut disusun dalam bentuk flat file, f. Jika atribut berupa nilai-nilai yang dapat dikodekan, telah dikodekan dan dilengkapi dengan tabel referensi sehingga tidak perlu penulisan kembali secara berulang, g. Jika atribut digunakan sebagai FK, telah distandarisasi, dan h. Jika atribut telah dikelompokkan secara tepat sesuai kelompoknya. Ketentuan tingkat fleksibilitas yang digunakan adalah sebagai berikut (diadopsi dari Blue Sheep® Ltd, www.bluesheep.com/cgi/news/show.php4?f =010102): SANGAT BAIK : jika 80
BAB IV ANALISIS DAN PEMBAHASAN

4.1. Analisis 4.1.1. SIM di Perguruan Tinggi (SIPT) 4.1.1.1. Kebutuhan SIM di Perguruan Tinggi (SIPT) Kebutuhan SIM di Perguruan Tinggi (SIPT) dapat berbeda antara Perguruan Tinggi satu dengan yang lainnya. Perbedaan ini utamanya dipengaruhi oleh 3 (tiga) hal, yaitu perbedaan aturan bisnis (business rule), perbedaaan ukuran organisasi, dan perbedaan area fungsional dalam organisasi Perguruan Tinggi. Perbedaan aturan bisnis terjadi karena perbedaan peraturan dan kebijakan yang digunakan, perbedaan ukuran organisasi terjadi karena perbedaan jumlah Fakultas, Jurusan, dan Program Studi yang diselenggarakan, serta jumlah mahasiwa, sedangkan perbedaan area fungsional dalam organisasi terjadi karena perbedaan kompleksitas pengolahan dan struktur organisasi. Oleh karena itu, kebutuhan SIPT di masing-masing Perguruan Tinggi dapat memiliki fungsi, tujuan, lingkup, definisi, serta implementasi yang berbeda-beda. SIPT dapat berupa sebuah aplikasi terintegrasi ataupun sekumpulan aplikasi yang bersifat otonom. Namun, di dalamnya hanya ada sebuah database yang digunakan. Berdasarkan hasil identifikasi yang dilakukan, maka SIPT dapat tersusun atas sejumlah sub sistem berikut:

99

100

1. Sub Sistem Informasi Akademik (SIAKAD) Sub sistem ini berfungsi untuk mengolah data Penmaru, heregisterasi, perwalian, KRS, perkuliahan, praktikum, Kerja Praktek, Tugas Akhir, KKN, yudisium kelulusan, wisuda, serta alumni 2. Sub Sistem Informasi Perpustakaan (SIPERPUSTAKAAN) Sub sistem ini berfungsi untuk mengolah data buku, anggota, transaksi peminjaman, transaksi pengembalian, denda keterlambatan, dan lain-lain 3. Sub Sistem Informasi Keuangan (SIKEUANGAN) Sub sistem ini berfungsi untuk mengolah data anggaran, pemasukan dana (SPP, DPP, dan lain-lain), pengeluaran dana (gaji, pengembangan, dan lainnya), akuntansi, pelaporan, dan lain-lain 4. Sub Sistem Informasi Kepegawaian (SIPEGAWAI) Sub sistem ini berfungsi untuk mengolah data kepangkatan, pendidikan dan pelatihan, prestasi, dan lain-lain 5. Sub Sistem Informasi Penggajian (SIGAJI) Sub sistem ini berfungsi untuk mengolah data gaji dosen, staf administrasi, sopir, staf keamanan, dan lain-lain 6. Sub Sistem Informasi Inventaris (SIINVENTARIS) Sub sistem ini berfungsi untuk mengolah data inventaris, inventori, kendaraan, dan lain-lain 7. Sub Sistem Informasi Kemahasiswaan (SIKEMAHASISWAAN) Sub sistem ini berfungsi untuk mengolah data kegiatan kemahasiswaan, ekstrakurikuler, beasiswa, prestasi mahasiswa, dan lain-lain

101

8. Sub Sistem Informasi Kerjasama dan Kehumasan (SIKEHUMAS). Sub sistem ini berfungsi untuk mengolah data-data kegiatan kerjasama, kehumasan, dan lain-lain 9. Sub Sistem Informasi Penelitian (SIPENELITIAN) Sub sistem ini berfungsi untuk mengolah data-data kegiatan penelitian dosen, prestasi penelitian dosen, dan lain-lain 10. Sub Sistem Informasi Pengabdian Kepada Masyarakat (SIPENGABDIAN). Sub sistem ini berfungsi untuk mengolah data-data kegiatan Pengabdian Kepada Masyarakat yang dilakukan oleh dosen, Pengabdian Kepada Masyarakat yang dilakukan oleh dosen, dan lain-lain 11. Sub Sistem Informasi Lainnya yang dikembangkan sesuai dengan kebutuhan pada masing-masing institusi Sekalipun SIPT tersusun atas sejumlah sub sistem, namun sesuai dengan konsep database, maka setiap sub sistem dalam SIPT akan mengakses ke sebuah database yang sama, yaitu database Perguruan Tinggi. Database Perguruan Tinggi ini akan melayani berbagai kebutuhan pengolahan data dan penyajian informasi untuk seluruh pengguna pada seluruh level manajemen dan seluruh sub sistem di sebuah Perguruan Tinggi.

4.1.1.2. Pengguna SIM di Perguruan Tinggi (SIPT) Berdasarkan konsep SIM, pengguna SIM dapat berupa orang-orang atau program-program aplikasi. Pada suatu Perguruan tinggi, orang-orang yang menggunakan SIPT dapat berupa perseorangan atau sekelompok orang yang

102

berada di dalam maupun di luar struktur organisasi Perguruan Tinggi. Dalam SIPT, personil pengguna di dalam struktur organisasi Perguruan Tinggi dapat dikelompokkan menjadi 3 (tiga), yaitu: 1. Para pengguna pada tingkat manajemen tertinggi (perencanaan strategis), misal Rektor pada Universitas atau Institut, Ketua pada Sekolah Tinggi, Direktur pada Akademi, para Pembantu Rektor (Warek/Purek/PR) pada Universitas atau Institut, para Pembantu Ketua pada Sekolah Tinggi, para Pembantu Direktur pada Akademi, para Pejabat di tingkat Yayasan pada Perguruan Tinggi Swasta, dan Pejabat lain yang setingkat 2. Para pengguna pada tingkat manajemen menengah (perencanaan taktis dan pengendalian manajemen), misal para Dekan, para Pembantu Dekan (Pudek/PD), dan Pejabat lain yang setingkat 3. Para pengguna pada tingkat manajemen terendah (perencanaan dan pengendalian operasional), misal para Ketua Jurusan, para Sekretaris Jurusan, para Ketua Program Studi, staf administrasi, dan Pejabat lain yang setingkat Sedangkan personil atau institusi pengguna yang berada di luar struktur organisasi Perguruan Tinggi dapat terdiri atas: 1. Dosen 2. Mahasiswa 3. Alumni 4. Masyarakat pengguna lulusan 5. Pemerintah (DIKTI/DIKNAS/BAN-PT) 6. Penyandang dana (Yayasan pada Perguruan Tinggi Swasta)

103

7. Orang tua/wali mahasiswa 8. Masyarakat umum Selanjutnya, berdasarkan konsep database, maka pengguna SIPT juga dapat berupa program-program aplikasi yang mengakses data-data dari dalam database. Program-program aplikasi juga dapat mengakses data-data dalam database pada saat bersamaan ataupun berselang waktu. Program-program aplikasi

dapat

hanya

yang

mengakses

database

untuk

kemudian

menampilkannya atau memanipulasi (insert, delete, update) data-data dari dalam database.

4.1.1.3. Kebutuhan Informasi (dan Data) untuk SIPT Berdasarkan hasil identifikasi sub sistem informasi dalam SIPT pada bagian sebelumnya, maka secara garis besar kebutuhan informasi (dan data) dalam SIPT dapat meliputi: 1. Informasi (dan data) terinci, baik insidentil maupun rutin, dalam bentuk teks, tabel maupun grafis, yang terkait dengan sub sistem berikut: a. Sub Sistem Informasi Akademik (SIAKAD) b. Sub Sistem Informasi Perpustakaan (SIPERPUSTAKAAN) c. Sub Sistem Informasi Keuangan (SIKEUANGAN) d. Sub Sistem Informasi Pegawai (SIPEGAWAI) e. Sub Sistem Informasi Penggajian (SIGAJI) f. Sub Sistem Informasi Inventaris (SIINVENTARIS) g. Sub Sistem Informasi Kemahasiswaan (SIKEMAHASISWAAN)

104

h. Sub Sistem Informasi Kerjasama dan Kehumasan (SIKEHUMAS) i. Sub Sistem Informasi Penelitian (SIPENELITIAN) j. Sub Sistem Informasi Pengabdian kepada Masyarakat Dosen (SIPENGABDIAN) k. Sub Sistem Informasi lainnya 2. Informasi (dan data) teringkas, baik insidentil maupun rutin, dalam bentuk teks, tabel maupun grafis, yang terkait dengan sub sistem berikut: a. Sub Sistem Informasi Akademik (SIAKAD) b. Sub Sistem Informasi Perpustakaan (SIPERPUSTAKAAN) c. Sub Sistem Informasi Keuangan (SIKEUANGAN) d. Sub Sistem Informasi Pegawai (SIPEGAWAI) e. Sub Sistem Informasi Penggajian (SIGAJI) f. Sub Sistem Informasi Inventaris (SIINVENTARIS) g. Sub Sistem Informasi Kemahasiswaan (SIKEMAHASISWAAN) h. Sub Sistem Informasi Kerjasama dan Kehumasan (SIKEHUMAS) i. Sub Sistem Informasi Penelitian (SIPENELITIAN) j. Sub Sistem Informasi Pengabdian kepada Masyarakat Dosen (SIPENGABDIAN) k. Sub Sistem Informasi lainnya 3. Informasi (dan data) spesifik, baik insidentil maupun rutin, dalam bentuk teks, tabel maupun grafis, yang terkait dengan sub sistem berikut: a. Sub Sistem Informasi Akademik (SIAKAD) b. Sub Sistem Informasi Perpustakaan (SIPERPUSTAKAAN)

105

c. Sub Sistem Informasi Keuangan (SIKEUANGAN) d. Sub Sistem Informasi Pegawai (SIPEGAWAI) e. Sub Sistem Informasi Penggajian (SIGAJI) f. Sub Sistem Informasi Inventaris (SIINVENTARIS) g. Sub Sistem Informasi Kemahasiswaan (SIKEMAHASISWAAN) h. Sub Sistem Informasi Kerjasama dan Kehumasan (SIKEHUMAS) i. Sub Sistem Informasi Penelitian (SIPENELITIAN) j. Sub Sistem Informasi Pengabdian kepada Masyarakat Dosen (SIPENGABDIAN) k. Sub Sistem Informasi lainnya

4.1.1.3.1. Kebutuhan Informasi (dan Data) untuk Penyusunan Portofolio Kebutuhan informasi (dan data) untuk penyusunan Portofolio Institusi Perguruan Tinggi dapat diidentifikasikan berdasarkan Pedoman Penyusunan Portofolio Institusi Perguruan Tinggi. Portofolio adalah dokumen yang menggambarkan proses perkembangan dan rencana pencapaian visi di masa yang akan datang. Dalam hal akreditasi, Portofolio digunakan sebagai instrumen penilaian yang bersifat terbuka (open-ended) dan multipurpose. Portofolio harus disusun berdasarkan evaluasi diri melalui suatu analisis kekuatan, kelemahan, peluang, dan tantangan (SWOT analysis) serta mencakup informasi komprehensif tentang

indikator

kinerja

kunci

yang

dinilai

(dalam

hal

ini

adalah

penyelenggaraan, aset fisik, aset finansial, aset sumberdaya manusia, dan aset informasi).

106

4.1.1.3.1.1. Persyaratan Batas Ambang dan Standar Kinerja Normatif Kunci Rancangan Borang dibuat didasarkan pada tingkat sumber informasi yang diperlukan untuk mengisi Borang. Artinya, rancangan Borang harus membedakan akreditasi tingkat Program Studi (PS) dan akreditasi tingkat institusi (universitas/sekolah tinggi/institut/dll). Akreditasi tingkat PS merupakan evaluasi kualitas proses pembelajaran ditinjau dari aspek masukan, proses, dan keluaran (seperti tercermin dalam kisi-kisi Borang PS). Sedangkan akreditasi tingkat institusi adalah evaluasi terhadap pemenuhan standar minimal kriteria kelayakan (threshold) yang meliputi 5 (lima) indikator kinerja kunci. Indikator kinerja kunci dimaksud meliputi pengelolaan/manajemen: 1. Penyelenggaraan (governance) program pendidikan tinggi seperti sistem dan mekanisme kerja 2. Infrastruktur (physical infrastructure) seperti tanah, gedung, peralatan, dan fasilitas lainnya 3. Finansial

(financial)

seperti

struktur

pemasukan,

pengeluaran,

dan

penggunaan dana 4. Aset sumberdaya manusia (human resource) seperti sistem rekruitmen mahasiswa, rekruitmen dan pengembangan staf pengajar serta staf pendukung 5. Informasi (information) seperti on-line internal connectivity melalui sistem manajemen informasi yang baik Di samping persyaratan batas ambang berdasarkan indikator kinerja kunci di atas, akreditasi tingkat institusi juga perlu memperhatikan kriteria normatif

107

(benchmark) yang dijabarkan dari kriteria nyata tersebut. Benchmarking terutama harus menunjukkan dimensi berikut: 1. Kelayakan (appropriateness) 2. Kecukupan (adequacy) 3. Relevansi/kesesuaian (relevancy) 4. Suasana akademik (academic atmosphere) 5. Efisiensi (efficiency) 6. Keberlanjutan (sustainability) 7. Selektivitas (selectivity) 8. Produktivitas (productivity) 9. Efektivitas (effectiveness) Seluruh dimensi tersebut di atas menunjukkan kualitas komprehensif dari suatu penyelenggaraan program untuk menghasilkan keluaran yang berkualitas tinggi, sesuai dengan bidang ilmu masing-masing. Hubungan seluruh dimensi tersebut di atas mewujudkan prinsip RAISE (Relevance, Academic Atmosphere, Institutional Commitment, Sustainability, and Efficiency), yaitu sebagai berikut: 1. Kelayakan (appropriateness) merupakan tingkat ketepatan unsur masukan, proses, hasil/keluaran, maupun tujuan program ditinjau dari ukuran ideal secara normatif 2. Kecukupan (adequacy) menunjukkan tingkat ketercapaian persyaratan ambang yang diperlukan untuk penyelenggaraan suatu program

108

3. Relevansi/kesesuaian (relevancy) merupakan tingkat keterkaitan tujuan maupun hasil/keluaran program pendidikan dengan kebutuhan masyarakat di lingkungannya maupun secara global 4. Suasana akademik (academic atmosphere) merujuk pada iklim yang mendukung interaksi antara dosen dan mahasiswa, antara sesama mahasiswa, maupun antara sesama dosen untuk mengoptimalkan proses pembelajaran 5. Efisiensi

(efficiency)

merujuk

pada

tingkat

pemanfaatan

masukan

(sumberdaya) yang digunakan untuk proses pembelajaran 6. Keberlanjutan

(sustainability)

menggambarkan

keberlangsungan

penyelenggaraan program yang mencakup ketersediaan masukan, aktivitas pembelajaran, maupun pencapaian hasil yang optimal 7. Selektivitas (selectivity) menunjukkan bagaimana penyelenggara program memilih unsur masukan, aktivitas proses pembelajaran, maupun penentuan prioritas hasil/keluaran berdasarkan pertimbangan kemampuan/kapasitas yang dimiliki 8. Produktivitas (productivity) menunjukkan tingkat keberhasilan proses pembelajaran yang dilakukan dalam memanfaatkan masukan 9. Efektivitas (effectiveness) adalah tingkat ketercapaian tujuan program yang telah ditetapkan yang diukur dari hasil/keluaran program

4.1.1.3.1.2. Portofolio Penilaian yang bersifat kualitatif sangat berbeda hakikatnya dengan penilaian yang bersifat kuantitatif, karena bertolak dari asumsi yang berbeda.

109

Asumsi penilaian kualitatif adalah bahwa spektrum penampilan profesional merupakan proses yang bersifat jamak dan divergen (tidak tunggal). Hubungan antar berbagai komponen dilandasi oleh kerangka acuan yang bersifat holistik yang inter-relasinya ditandai oleh konteks yang bermakna, jadi tidak fragmentaris, dan juga tidak merupakan korelasi statistik dari berbagai variabel independen ataupun yang diturunkan dari hukum positivistis. Penilaian kualitatif seperti ini diantaranya dapat dilakukan melalui Portofolio.

4.1.1.3.1.3. Penyusunan Portofolio Akreditasi Tingkat Institusi Informasi untuk akreditasi tingkat institusi pada prinsipnya harus meliputi aspek masukan, proses, dan keluaran. Informasi aspek input mencakup data mengenai indikator kunci strategi penyelenggaraan, aset infrastruktur, aset finansial, aset sumberdaya manusia, dan aset informasi. Sedangkan informasi mengenai proses berfokus pada rancangan kebijakan institusi tentang hal-hal yang akan dijadikan landasan dalam pengelolaan dan pelaksanaan proses belajar mengajar (PBM) pada tingkat PS. Informasi mengenai keluaran terutama untuk melihat hasil PT yang dikaitkan dengan pencapaian visi dan relevansinya dengan tuntutan stakeholders (pihak yang berkepentingan), serta kecenderungan perkembangan IPTEK, dan globalisasi. Stakeholders antara lain meliputi dosen, mahasiswa, alumni, masyarakat pengguna lulusan, masyarakat keilmuan, pemerintah, penyandang dana, dan masyarakat pada umumnya. Uraian informasi dalam Portofolio harus menjawab isu yang berkaitan dengan pencapaian batas ambang (threshold) dan standar kinerja normatif

110

(benchmark). Secara terinci, Portofolio tersebut harus menjawab pertanyaanpertanyaan dalam Tabel 4.1. Untuk dapat menjawab pertanyaan-pertanyaan tersebut, penyusunan Portofolio harus didahului oleh proses evaluasi diri melalui SWOT (Strengths, Weaknesses, Opportunities, and Threats) analysis yang dilakukan oleh suatu Tim yang terdiri dari perwakilan Rektorat, Fakultas, dan Program Studi. Uraian SWOT analysis harus mencakup aspek-aspek berikut: 1. Visi, misi, dan tujuan PS 2. Rancangan, substansi, implementasi, dan evaluasi kurikulum 3. Sistem instruksional: belajar, mengajar, dan evaluasi hasil belajar 4. Evaluasi kemajuan dan pencapaian hasil belajar 5. Bimbingan dan konseling untuk mahasiswa 6. Sumberdaya pendukung Tridharma PT 7. Suasana akademis 8. Penelitian, publikasi, pengabdian kepada masyarakat 9. Pengelolaan penyelenggaraan institusi, serta pemenuhan dan peningkatan kualitas Dengan demikian, bahan penilaian akreditasi tingkat institusi adalah intisari hasil SWOT analysisdan portofolio. Secara ringkas, rambu-rambu penyusunan Portofolio yang dapat menunjukkan kebutuhan informasi (dan data) untuk penyusunan Portofolio ditampilkan pada Tabel 4.1 (BAN PT Depdiknas, 2001).

111

Tabel 4.1: Rambu-rambu Penyusunan Portofolio Indikator Kinerja Kunci 1. Penyelenggaraan

Aspek Utama 1.1. Visi, Misi, dan Tujuan

1.2. Sistem*

2. Infrastruktur

2.1.Ketersediaan Prasarana tanah/gedung, dll.

Batas Ambang ƒ Apakah visi, misi dan tujuan sudah realistis dan berorientasi ke masa depan yang lebih baik, serta konsisten dengan perkembangan sejarah, budaya, dan nilai-nilai pendidikan tinggi? ƒ Apakah visi, misi, dan tujuan sudah dijadikan acuan dalam perencanaan kerja? ƒ Apakah sistem sudah dipahami oleh staf di lingkungan institusi Anda? ƒ Apakah sistem sudah dapat menciptakan suasana akademis yang kondusif?

ƒ Apakah sistem pemerolehan prasarana menjamin keberlanjutan (sustainability) dari ketersediaan? ƒ Bagaimana rasio ketersediaan prasarana: mahasiswa/ dosen

Standar Kinerja Normatif ƒ Apakah visi, misi, dan tujuan dipahami oleh seluruh staf di lingkungan institusi Anda? ƒ Apakah visi, misi dan tujuan sudah mencerminkan standar keunggulan cita-cita tinggi serta dorongan, semangat, dan komitmen sivitas akademika dalam upaya mewujudkan perubahan tersebut? ƒ Apakah sistem mendukung pencapaian visi, misi dan tujuan yang telah ditetapkan? ƒ Apakah sistem sudah dijalankan secara transparan? ƒ Apakah sistem didukung oleh peraturan yang jelas tentang pengembangan kemampuan, keterampilan, sikap, dan kepedulian pengelola dalam melaksanakan tugas? ƒ Apakah PT mempunyai unit kendali mutu yang berfungsi untuk mengkaji dan mengendalikan kualitas semua PS, sehingga konsisten dengan visi dan misi institusi? ƒ Apakah sistem pemerolehan prasarana sudah memadai untuk pencapaian visi, misi dan tujuan institusi? ƒ Bagaiman tingkat kelayakan dan kesesuaian prasarana yang ada untuk mendukung PBM dalam rangka melaksanakan misi dan mencapai visi? ƒ Apakah PS memiliki akses yg tinggi terhadap prasarana yg menunjukan pelaksanaan PBM maupun Tridharma PT? ƒ Apakah PT memiliki aturan yang jelas mengenai pemanfaatan bersama sarana di lingkungan PT, maupun kerjasama untuk memanfaatkan prasarana di luar lingkungan PT?

112

3. Finansial

4.Sumberdaya Manusia

2.2.Ketersediaan sarana/ fasilitas/ peralatan utama

ƒ Apakah sistem pemerolehan sarana menjamin keberlanjutan (sustainability) dari ketersediaan? ƒ Bagaimana rasio ketersediaan sarana : mahasiswa/dosen

3.1. Struktur penerimaan dan pengeluaran (revenue and expenditure structure)

ƒ Bagaimana cara pemerolehan dana yang dibutuhkan?

4.1. Dosen dan karyawan

ƒ Bagaimana struktur penerimaan dan pengeluaran tahunan?

ƒ Bagaimana kelayakan sistem dan strategi rekruitmen dan pembinaan karir profesi dosen ƒ Bagaimana sistem dan strategi pemberian kesejahteraan dan sanksi (reward and punishment) bagi dosen dan karyawan

ƒ Apakah PS memiliki akses yang tinggi terhadap sarana yang menunjukan pelaksanaan PBM maupun Tridharma PT? ƒ Apakah PT memiliki aturan yang jelas mengenai pemanfaatan bersama sarana di lingkungan PT? ƒ Apakah PT memiliki aturan yang jelas mengenai pemanfaatan bersama prasarana di lingkungan PT, maupun kerjasama untuk memanfaatkan sarana di luar lingkungan PT? ƒ Bagaimana tingkat keberlanjutan (sustainability) sumber penerimaan? ƒ Bagaiman tingkat kelayakan struktur dana yang ada untuk mendukung PBM dalam rangka melaksanakan misi dan mencapai visi? ƒ Bagaiman tingkat kelayakan dan kesesuaian prioritas dan efisiensi pendanaan untuk mendukung PBM dalam rangka melaksanakan misi dan mencapai visi? ƒ Bagaimana relevansi dan efektivitas strategi investasi dengan upaya pencapaian visi? ƒ Bagaimana kesesuaian sistem, strategi, pelaksanaan rekruitmen, serta pembinaan dosen & karyawan untuk mendukung PBM dalam rangka pelaksanaan misi dan pencapaian visi? ƒ Bagaimana kesesuaian sistem, strategi, dan pelaksanaan pemberian kesejahteraan dan sanksi untuk mendukung PBM dalam rangka pelaksanaan misi dan pencapaian visi? ƒ Bagaimana kesesuaian profil kompetensi SDM yang ada untuk mendukung PBM dalam rangka pelaksanaan misi dan pencapaian visi? ƒ Rasio dosen berpendidikan S3:S2:S1?

113

4.2 Mahasiswa

ƒ Bagaimana sistem dan strategi rekruitmen mahasiswa? ƒ Bagaimana kecende-rungan jumlah pene-rimaan mahasiswa (shift intake)

4.3. Kualitas Lulusan

ƒ Berapa IPK rata-rata lulusan, dan berapa persentase lulusan dengan IPK ≥ 2,75? ƒ Bagaimana gambaran mengenai lama studi ratarata?

4.4. Kualitas hasil penelitian dan pengabdian kepada masyarakat

ƒ Bagaimana batasan ruang lingkup kegiatan penelitian dan pengabdian masyarakat? ƒ Berapa jumlah hasil penelitian dan pengabdian kepada masyarakat yang berhasil dipublikasikan dalam majalah ilmiah?

ƒ Bagaimana kesesuaian sistem dan strategi rekruitmen mahasiswa dengan target mahasiswa yang diinginkan? ƒ Bagaimana kesesuaian karakteristik mahasiswa yang diterima dengan target keluaran yang di-visi-kan? ƒ Adakah dan bagaimanakah peraturan prosedur pelaksanaan bimbingan akademis dan nonakademis kepada mahasiswa? ƒ Bagaimana kesesuaian dan efisiensi rasio dosen:mahasiswa untuk mendukung PBM dalam rangka melaksanakan misi dan mencapai visi ƒ Bagaimana pencapaian tingkat kelulusan ideal (completion/ graduation rate)? ƒ Bagaimana kesesuaian kemampuan dan keterampilan lulusan dengan kecenderungan perkembangan IPTEK dan globalisasi? ƒ Adakah rancangan dan program penelusuran alumni? ƒ Bagaimana kesesuaian kemampuan dan keterampilan lulusan dengan tuntutan dunia kerja (misalnya, bagaimana daya saing lulusan di pasar kerja)? ƒ Bagaimana kesesuaian topik penelitian dan pengabdian kepada masyarakat untuk mendukung PBM dalam rangka melaksanakan misi dan mencapai visi ƒ Bagaimana relevansi hasil penelitian dan pengabdian kepada masyarakat dengan kecenderungan perkembangan IPTEK, dan tuntutan dunia kerja serta globalisasi ƒ Berapa jumlah HAKI/Hak PATEN yang berhasil diperoleh? ƒ Berapa dana ekternal yang berhasil dihimpun untuk kegiatan penelitian dan pengabdian kepada masyarakat?

114

5. Sistem Informasi

5.1.Ketersediaan SIM yang menghubung-kan unitunit dalam kampus (oncampus connectivity) dan jaringan informasi eksternal (Internet)

ƒ Bagaimana pemenuhan kebutuhan sarana informasi dalam lingkungan kampus? ƒ Bagaimana sistem penghimpunan, penyimpanan, dan pengambilan data dilakukan?

5.2. Rancangan dan kebijakan Proses diseminasi informasi /kebijakan pimpinan pusat institusi

ƒ Adakah sistem dan strategi diseminasi kebijakan untuk menciptakan suasana kondusif untuk kegiatan akademis?

ƒ Bagaimana kelayakan sistem informasi yang ada untuk mendukung PBM dalam rangka melaksanakan misi dan mencapai visi? ƒ Bagaimana transparansi informasi untuk pengambilan keputusan dan peningkatan kualitas proses pembelajaran ƒ Bagaimana? kesesuaian strategi pengembangan sistem informasi dengan kecenderungan perkembangan IPTEK dan globalisasi? ƒ Bagaimana efisiensi dan efektivitas pemanfaatan informasi oleh unit-unit terkait? ƒ Bagaimana strategi pengembangan sistem informasi jangka panjang? ƒ Bagaimana sistem dan strategi diseminasi kebijakan untuk menciptakan suasana kondusif untuk kegiatan akademis? ƒ Bagaimana kesesuaian kebijakan, strategi, dan pelaksanaan operasional untuk mendukung PBM dalam rangka pelaksanaan misi dan pencapaian visi institusi?

* Termasuk struktur organisasi, mekanisme kerja, mekanisme koordinasi antara rektorat dan fakultas/jurusan/Program Studi, mekanisme pengambilan keputusan, kepemimpinan, mekanisme penentuan kebijakan, dan mekanisme monitoring serta evaluasi dari seluruh kegiatan penyelenggaraan pendidikan tinggi.

115

4.1.1.3.2. Kebutuhan

Informasi

(dan

Data)

untuk

Peningkatan

Mutu

Pendidikan Tinggi Perkembangan teknologi informasi dan komunikasi saat ini memicu globalisasi di berbagai aspek kehidupan. Globalisasi ekonomi memacu PT untuk melakukan internasionalisasi, kerjasama, serta kompetisi dalam berbagai aspek pendidikan. Agar dapat berhasil dalam kompetisi, maka mutu harus merupakan fokus pengembangan. Aspek mutu dalam paradigma baru Pendidikan Tinggi meliputi: 1. Otonomi, yaitu mandiri di berbagai aspek 2. Akuntabilitas, yaitu terukur dengan indikator 3. Akreditasi, yaitu dapat disetarakan 4. Evaluasi, yaitu selalu melakukan evaluasi diri Pendidikan Tinggi dikatakan bermutu jika mampu menghasilkan lulusan yang bermutu, yaitu (Suwardi, 2003): 1. Cepat lulus 2. Lulus dengan nilai tinggi 3. Cepat bekerja 4. Dapat diterima di banyak bidang 5. Gaji tinggi Peningkatan Mutu Pendidikan Tinggi dilakukan dengan RAISE++, yaitu (BAN PT Depdiknas, 2001): 1. Relevance 2. Academic Atmosphere

116

3. Internal management and Organization 4. Sustainability 5. Efficiency and Productivity 6. + Access Equity 7. + Leadership Mutu lulusan Pendidikan Tinggi dapat diukur dengan indikator kinerja. Penyusunan indikator kinerja dapat dilakukan dengan Evaluasi Diri. Evaluasi Diri dapat disusun dengan baik jika tersedia data yang lengkap dan akurat. Data-data dasar yang perlu dianalisis sebelum penyusunan laporan Evaluasi Diri untuk keperluan peningkatan mutu Pendidikan Tinggi meliputi (BAN PT Depdiknas, 2001): 1. IPK Lulusan 2. Waktu Tunggu Lulusan 3. Lama Studi Mahasiswa 4. Lama Skripsi Mahasiswa 5. Status Mahasiswa 6. Potret IPK Mahasiswa 7. English Proficiency Test Mahasiswa 8. Proses Pendidikan 9. Keketatan, Score dan NEM Mahasiswa Baru 10. Asal Propinsi Mahasiswa Baru 11. Asal Kodya/Kabupaten Mahasiswa Baru 12. Asal Pendaftar/Pemilih

117

13. Kerjasama 14. Pendidikan dan Umur Dosen 15. Dosen Full/Part Time dan Studi 16. SKS Dosen 17. Pendidikan dan Umur Staf Administrasi 18. Luas Gedung/Ruang 19. Kapasitas Ruang Kuliah 20. Laboratorium dan pemanfaatnya 21. Umur Koleksi di Perpustakaan 22. Koleksi untuk Mata Kuliah di Perpustakaan 23. Transaksi di Perpustakaan 24. Fasilitas 25. Anggaran dan Belanja

4.1.1.3.3. Kebutuhan Informasi (dan Data) untuk Penyusunan Evaluasi Diri Kebutuhan informasi (dan data) untuk penyusunan Evaluasi Diri dapat diidentifikasikan berdasarkan Pedoman Evaluasi Diri Program Studi (BAN PT Depdiknas, 2001). Evaluasi Diri adalah penilaian, telaah, dan analisis keseluruhan sistem Program Studi/lembaga perguruan tinggi, yang mencakup masukan, proses, dan keluaran berdasarkan data, informasi dan bukti-bukti lainnya yang berkenaan dengan komponen-komponen sistemik dari penyelenggaraan Program Studi seperti dibagankan pada Gambar 4.1.

118

Gambar 4.1: Analisis sistemik mengenai komponen Evaluasi Diri Berdasarkan analisis tersebut, maka dapat dijabarkan dimensi penilaian yang digunakan dalam akreditasi Program Studi yang secara garis besar terdiri atas komponen-komponen berikut (BAN PT Depdiknas, 2001): A. Masukan, mencakup komponen berikut: 1. Visi dan misi Program Studi 2. Sasaran dan tujuan 3. Mahasiswa 4. Dosen dan tenaga pendukung 5. Kurikulum 6. Sarana dan prasarana 7. Biaya dan sumber dana (pendanaan) B. Proses, mencakup komponen berikut: 8.

Tata pamong (governance)

119

9.

Pengelolaan program

10. Proses pembelajaran 11. Suasana Akademik 12. Penelitian dan skripsi 13. Pengabdian kepada masyarakat C. Keluaran/Hasil, mencakup komponen berikut: 14. Lulusan 15. Keluaran lainnya: publikasi hasil penelitian dan atau produk penelitian dalam bentuk paten, rancang bangun, prototipe, perangkat lunak, lainnya D. Balikan dan tindak lanjut, mencakup komponen berikut: 16. Sistem informasi 17. Sistem peningkatan dan pengendalian mutu Untuk keperluan penyusunan laporan hasil Evaluasi Diri, maka komponenkomponen itu ditata sebagaimana ditampilkan dalam Tabel 4.2 (BAN PT Depdiknas, 2001).

120

Tabel 4.2: Komponen Evaluasi Diri sebagai dimensi penilaian yang digunakan dalam Akreditasi Program Studi Komponen A

Isi Komponen Jatidiri, Visi, Misi, Sasaran, dan Tujuan

B

Kemahasiswaan

1. 2. 3. 4. 5. 1. 2. 3. 4. 5. 6.

C

D

Dosen dan Tenaga Pendukung

Kurikulum

1. 2. 3. 4. 5. 6. 7. 1. 2. 3. 4. 5. 6. 7. 8.

Komponen Rumusan jatidiri Program Studi, termasuk identitas fisik, legalitas, dan perkembangannya Rumusan visi Program Studi yang konsisten dengan visi lembaga Rumusan misi Program Studi yang diturunkan dari misi lembaga Rumusan sasaran Program Studi yang relevan dengan misinya Rumusan tujuan Program Studi yang merujuk tujuan lembaga & merupakan turunan misi Sistem rekrutmen dan seleksi calon mahasiswa Profil mahasiswa: akademik, sosio-ekonomi, pribadi (termasuk kemandirian & kreativitas) Keterlibatan mahasiswa dalam berbagai komisi yang relevan Kegiatan ekstra-kurikuler Keberlanjutan penerimaan mahasiswa (minat calon mahasiswa dan kebutuhan akan lulusan Program Studi) Pelayanan untuk mahasiswa: a. Bantuan tutorial yang bersifat akademik b. Informasi dan bimbingan karir c. Konseling pribadi dan sosial Sistem rekrutmen dan seleksi dosen dan tenaga pendukung Pengelolaan dosen dan tenaga pendukung Profil dosen dan tenaga pendukung: mutu, kualifikasi, pengalaman, ketersediaan (kecukupan, kesesuaian, dan rasio dosen-mahasiswa) Karya akademik dosen (hasil penelitian, karya lainnya) Peraturan kerja dan kode etik Pengembangan staf Keberlanjutan pengadaan dan pemanfaatannya Kesesuaian dengan visi, misi, sasaran, dan tujuan Relevansi dengan tuntutan dan kebutuhan stakeholders Struktur dan isi kurikulum (keluasan, kedalaman, koherensi, penataan/ organisasi) Kompetensi dan etika lulusan yang diharapkan Derajat integrasi materi pembelajaran (intra dan antar disiplin ilmu) Kurikulum lokal yang sesuai dengan kebutuhan masyarakat terdekat dan kepentingan internal lembaga Mata kuliah pilihan yang merujuk pada harapan/kebutuhan mahasiswa secara individual/kelompok mahasiswa tertentu Peluang bagi mahasiswa untuk mengembangkan diri: melanjutkan studi, mengembangkan

Sumber Informasi Statuta, Renstra, direktori Program Studi, kurikulum, peraturan perundangundangan terkait Buku pedoman rekrutmen dan seleksi calon mahasiswa, pedoman layanan mahasiswa, hasil studi pelacakan, peraturan perundangundangan terkait

Buku pedoman rekrutmen dan seleksi calon dosen dan tenaga pendukung, direktori Program Studi, program pengembangan staf, laporan tahunan pimpinan perguruan tinggi/Program Studi, peraturan perundangundangan terkait Buku pedoman pengembangan kurikulum, hasil studi pelacakan, statuta, Renstra, kebijakan pimpinan, peraturan perundang-undangan terkait

121

E

Sarana dan Prasarana

F

Pendanaan

G

Tata Pamong (Governance)

1. 2. 3. 4. 5. 1. 2. 3. 4. 1. 2. 3. 4. 5.

H

Pengelolaan Program

1. 2. 3. 4. 5.

pribadi, memperoleh pengetahuan dan pemahaman materi khusus sesuai dengan bidang studinya, mengembangkan keterampilan yang dapat dialihkan (transferable skills), terorientasikan ke arah karir, dan pemerolehan pekerjaan Pengelolaan, pemanfaatan, dan pemeliharaan sarana dan prasarana. Ketersediaan dan kualitas gedung, ruang kuliah, laboratorium, perpustakaan, dll Fasilitas komputer dan pendukung pembelajaran dan penelitian Kesesuaian dan kecukupan sarana dan prasarana Keberlanjutan pengadaan, pemeliharaan dan pemanfaatannya Sumber dana Sistem alokasi dana Pengelolaan dan akuntabilitas penggunaan dana Keberlanjutan pengadaan dan pemanfaatannya Sistem nilai Sistem pengeloaan Sistem kepemimpinan, dan pengalihan (deputizing) serta akuntabilitas pelaksanaan tugas Partisipasi civitas academica dalam pengembangan kebijakan, serta pengelolaan dan koordinasi pelaksanaan program Perencanaan program jangka panjang (Renstra) dan monitoring pelaksanaannya sesuai dengan visi, misi, sasaran dan tujuan program Efisiensi dan efektivitas kepemimpinan Evaluasi program dan pelacakan lulusan Perencanaan dan pengembangan program, dengan memanfaatkan hasil evaluasi internal dan eksternal Kerjasama dan kemitraan Dampak hasil evaluasi program terhadap pengalaman dan mutu pembelajaran mahasiswa

Renstra, rencana pengembangan lembaga, peraturan perundangundangan terkait Laporan keuangan tahunan, peraturan perundangundangan terkait Renstra, statuta, laporan tahunan, risalah rapat pimpinan, peraturan perundang-undangan terkait

Hasil studi pelacakan, rencana pengembangan program, Renstra, statuta, peraturan perundang-undangan terkait

122

I

Proses Pembelajaran

J

Suasana Akademik

K

Sistem Informasi

1. Misi pembelajaran a. Pengembangan/pelatihan kompetensi yang diharapkan b. Efisiensi internal dan eksternal 2. Mengajar: a. Kesesuaian strategi dan metode dengan tujuan b. Kesesuaian materi pembelajaran dengan tujuan mata kuliah c. Efisiensi dan produktivitas. d. Struktur dan rentang kegiatan mengajar e. Penggunaan teknologi informasi 3. Belajar: a. Keterlibatan mahasiswa b. Bimbingan skripsi c. Peluang bagi mahasiswa untuk mengembangkan: 1) pengetahuan dan pemahaman materi khusus sesuai bidangnya 2) keterampilan umum dan yang dapat dialihkan (transferable) 3) pemahaman dan pemanfaatan kemampuannya sendiri 4) kemampuan belajar mandiri 5) nilai, motivasi dan sikap 4. Penilaian kemajuan dan keberhasilan belajar: a. Peraturan mengenai penilaian kemajuan dan penyelesaian studi mahasiswa. b. Strategi dan metode penilaian kemajuan dan keberhasilan mahasiswa c. Penentuan yudisium (pernyataan kualitatif dari hasil belajar seorang mahasiswa pada akhir jenjang pendidikan). d. Penelaahan mengenai kepuasan mahasiswa. 1. Sarana yang tersedia untuk memelihara interaksi dosen-mahasiswa, baik di dalam maupun di luar kampus, dan untuk menciptakan iklim yang mendorong perkembangan dan kegiatan akademik/profesional 2. Mutu & kuantitas interaksi kegiatan akademik dosen, mhs & civitas academica lainnya 3. Rancangan menyeluruh untuk mengembangkan suasana akademik yang kondusif untuk pembelajaran, penelitian, dan pengabdian kepada masyarakat 4. Keikutsertaan civitas academica dalam kegiatan akademik (seminar, simposium, diskusi, eksibisi) di kampus 5. Pengembangan kepribadian ilmiah 1. Rancangan pengembangan sistem informasi 2. Kecukupan dan kesesuaian sumber daya, sarana dan prasarana pendukung untuk

Kebijakan-kebijakan mengenai pembelajaran, pedoman evaluasi hasil pembelajaran, pedoman pembelajaran, peraturan perundangundangan terkait

Hasil pengamatan, laporan tahunan, peraturan akademik yang berlaku, peraturan perundang-undangan terkait

Laporan tahunan, laporan khusus unit pelayanan

123

L

Sistem Jaminan Mutu

M

Lulusan

N

Penelitian, Publikasi, Skripsi, Pengabdian kepada Masyarakat, dan hasil lainnya

pemberdayaan sistem informasi Efisiensi dan efektivitas pemanfaatan sistem informasi Keberadaan dan pemanfaatan on-campus connectivity devices (intranet Keberadaan dan pemanfaatan global connectivity devices (internet) Pengelolaan mutu secara internal pada tingkat Program Studi (misalnya kajian kurikulum, monitoring dan mekanisme balikan bagi mahasiswa, dosen dan penguji eksternal) 2. Hubungan dengan penjaminan mutu pada tingkat lembaga 3. Dampak proses penjaminan mutu terhadap pengalaman dan mutu hasil belajar mahasiswa 4. Metodologi baku mutu (benchmarking) 5. Pengembangan dan penilaian pranata kelembagaan 6. Evaluasi internal yang berkelanjutan 7. Pemanfaatan hasil evaluasi internal dan eksternal/akreditasi dalam perbaikan dan pengembangan program 8. Kerjasama dan kemitraan instansi terkait dalam pengendalian mutu 1. Hasil pembelajaran: a. Kompetensi yang dicapai dibandingkan dengan yang diharapkan b. Kesesuaian kompetensi yg dicapai dgn tuntutan & kebutuhan pemanfaat lulusan c. Data tentang kemajuan, keberhasilan, dan kurun waktu penyelesaian studi mahasiswa (termasuk IPK dan yudisium lulusan) d. Kepuasan lulusan 2. Kepuasan pemanfaat lulusan dan keberlanjutan penyerapan lulusan 1. Kualitas, produktivitas, relevansi sasaran, dan efisiensi pemanfaatan dana penelitian dan pengabdian kepada masyarakat 2. Agenda, keberlanjutan, diseminasi hasil penelitian dan pengabdian kepada masyarakat 3. Kegiatan penelitian dan pengabdian kepada masyarakat bersama dosen dan mahasiswa 4. Banyak dan kualitas kegiatan penelitian dan pengabdian kepada masyarakat yang dilakukan oleh mahasiswa 5. Hubungan antara pengajaran, penelitian dan pengabdian kepada masyarakat 6. Banyak dan kualitas kegiatan penelitian dan publikasi dosen. 7. Hubungan kerjasama dan kemitraan penelitian dengan lembaga dalam dan luar negeri 8. Kualitas & kurun waktu penyelesaian skripsi (termasuk proses penulisan skripsi & pembimbingannya) 9. Publikasi hasil penelitian, karya inovatif, dan rangkuman skripsi. 10. Produk Program Studi berupa model-model, hak paten, hasil pengembangan prosedur kerja, produk fisik sebagai hasil penelitian 3. 4. 5. 1.

informasi, pengamatan pemanfaatan sistem informasi, peraturan perundangundangan terkait Hasil evaluasi internal, hasil akreditasi, pedoman pelaksanaan penjaminan mutu internal, peraturan perundangundangan terkait

Laporan wisuda tahunan/tengah tahunan, transkrip hasil belajar para lulusan, direktori lulusan Program Studi, hasil studi pelacakan, peraturan perundang-undangan yg terkait Rancangan penelitian dan pengabdian kepada masyarakat, Renstra, daftar tugas pembimbingan mahasiswa, catatan mengenai penyelesaian skripsi, daftar skripsi, peraturan perundangundangan terkait

124

4.1.1.3.4. Kebutuhan Informasi (dan Data) untuk Penyusunan Borang Kebutuhan informasi (dan data) untuk penyusunan Borang Akreditasi Program Studi dapat diidentifikasikan berdasarkan Panduan Pengisian Borang Akreditasi Program Studi S1. Secara ringkas, kebutuhan informasi (dan data) untuk penyusunan Borang Akreditasi Program Studi ditampilkan pada Tabel 4.3 (BAN PT Depdiknas, 2001). Tabel 4.3: Kebutuhan informasi (dan data) untuk penyusunan borang No. Butir

No. Kolom Identitas Program Studi dan pengisi borang

1

(1) - (4) (5) – (12) (13) (14) Lampiran 2 Lampiran 3

2a

(1) – (5) (7) (8) (9) (10) - (11)

2b

(1) – (5) (7) (8)

Kebutuhan Informasi (dan Data) Program Studi (PS) Jurusan Fakultas Perguruan Tinggi Bulan & Tahun Penyelenggaraan PS Pertama Kali Nomor SK Pendirian PS Tanggal SK Pejabat Penandatangan SK Visi Program Studi Misi Program Studi Tujuan Program Studi Nomor mata kuliah, nama mata kuliah, kelompok mata kuliah Status mata kuliah: (wajib, pilihan; KURNAS, lokal; beban sks perkuliahan, praktikum, total) Nama jurusan/fakultas/universitas pembina setiap mata kuliah yang digunakan oleh PS Nama dosen penanggung jawab dan keahlian dosen yang menangani mata kuliah Nomor, semester, kode mata kuliah, dan nama mata kuliah pilihan yang diselenggarakan dalam tiga tahun terakhir, bobot sks setiap mata kuliah, jurusan/fakultas yang membina mata kuliah, dan nama dosen yang mengajar Nama mata kuliah praktikum dan atau praktek, pokok masalah dan jumlah jam praktikum per semester untuk setiap judul praktikum, serta tempat pelaksanaan praktek/praktikum Nama lengkap dosen tetap (tidak disingkat, gelar di belakang nama) berserta tempat dan tanggal lahir, tuliskan nomor identitas dosen, pendidikan S1, S2 dan S3 dan asal universitas, jabatan fungsional akademik Bidang keahlian dosen berdasarkan SK jabatan atau pendidikan tertinggi. Bidang mata kuliah yang diajarkan dosen Jumlah sks yang diajarkan dosen pada mahasiswa tahun pertama Jumlah sks yang diajarkan dosen per semester pada PS yang bersangkutan pada semester ganjil dan genap untuk 3 tahun terakhir Nama lengkap dosen tidak tetap (tidak disingkat, gelar di belakang nama) berserta tempat dan tanggal lahir, nomor identitas dosen, pendidikan S1, S2 dan S3 dan asal universitas, jabatan fungsional akademik Bidang keahlian dosen berdasarkan SK jabatan atau pendidikan tertinggi bidang mata kuliah yang diajarkan dosen • • • • • • • • • • •

125

3

(9) (10) (1) – (6) (7)

4

5a

(1) (2) (3) (4) (5) (6) (7)- (9) (10) – (12)

5b

(2) (3)

(4) (5)

(6)

(7)

(8)

Jumlah sks yang diajarkan dosen pada mahasiswa tahun pertama Jumlah rata-rata sks yang diajarkan dosen per semester untuk 5 tahun terakhir Jumlah karyawan menurut kualifikasinya Unit kerja adalah jenis tenaga penunjang yang mempunyai akses pada Program Studi yang bersangkutan baik di Fakultas dan PS Suasana akademis yang kondusif adalah iklim yang mendorong interaksi positif antara dosen dan dosen, dosen-mahasiswa, serta mahasiswa-mahasiswa. Jenis dan mekanisme pelaksanaan upaya untuk mewujudkan suasana akademis (dalam lingkup pendidikan pengajaran, penelitian, dan pengabdian pada masayarakat) TS adalah tahun akademik utuh terakhir sebelum saat pengisian Borang Jumlah mahasiswa yang berminat/mendaftar pada setiap tahun pendaftaran Daya tampung nyata PS sesuai dengan kapasitas fasilitas yang ada untuk menerima mahasiswa baru untuk setiap tahun pendaftaran Jumlah mahasiswa yang lulus seleksi dan diterima menjadi peserta PS pada setiap tahun pendaftaran Jumlah mahasiswa yang telah diterima yang benar-benar melakukan registrasi (mendaftar) untuk mengikuti kegiatan perkuliahan Jumlah lulusan tahun yang bersangkutan ƒ IPK minimal yang dicapai mahasiswa yang lulus pada tahun yang bersangkutan ƒ IPK rata-rata yang dicapai mahasiswa yang lulus pada tahun yang bersangkutan ƒ IPK maksimal yang dicapai mahasiswa yang lulus pada tahun yang bersangkutan ƒ Jumlah lulusan pada tiap tahun kelulusan yang memperoleh IPK < 2,75 ƒ Jumlah lulusan pada tiap tahun kelulusan yang memperoleh IPK antara 2,75 - 3,50 ƒ Jumlah lulusan pada setiap tahun kelulusan yang memperoleh IPK > 3,50 Jumlah mahasiswa yang mendaftar pertama kali pada tahun TS-8 Jumlah mahasiswa yang mendaftar pertama kali pada tahun: ƒ TS-8 yang masih teregistrasi pada tahun TS-7 ƒ TS - 7 Jumlah mahasiswa yang mendaftar pertama kali pada tahun: ƒ TS-8 yang masih teregistrasi pada tahun TS-6 ƒ TS-7 yang masih teregistrasi pada tahun TS-6 ƒ TS – 6 Jumlah mahasiswa yang mendaftar pertama kali pada tahun: ƒ TS-8 yang masih teregistrasi pada tahun TS-5 ƒ TS-7 yang masih teregistrasi pada tahun TS-5 ƒ TS-6 yang masih teregistrasi pada tahun TS-5 ƒ TS -5 ƒ TS-8 yang masih teregistrasi pada tahun TS-4 ƒ TS-7 yang masih teregistrasi pada tahun TS-4 ƒ TS-6 yang masih teregistrasi pada tahun TS-4 ƒ TS-5 yang masih teregistrasi pada tahun TS-4 ƒ TS -4 ƒ TS-8 yang masih teregistrasi pada tahun TS-3 ƒ TS-7 yang masih teregistrasi pada tahun TS-3 ƒ TS-6 yang masih teregistrasi pada tahun TS-3 ƒ TS-5 yang masih teregistrasi pada tahun TS-3 ƒ TS-4 yang masih teregistrasi pada tahun TS-3 ƒ TS -3 ƒ TS-8 yang masih teregistrasi pada tahun TS-2 ƒ TS-7 yang masih teregistrasi pada tahun TS-2

126

(9)

(10)

(11) 6

(1) – (2)

(3) (4) (5) – (6) (7) 7 8a 8b 9a

(2) - (3) (4) - (5) (1) – (2) Lampiran (1) - (3) (4) – ( 10) (11) - (12)

9b-e 10a

ƒ TS-6 yang masih teregistrasi pada tahun TS-2 ƒ TS-5 yang masih teregistrasi pada tahun TS-2 ƒ TS-4 yang masih teregistrasi pada tahun TS-2 ƒ TS-3 yang masih teregistrasi pada tahun TS-2 ƒ TS -2 ƒ TS-8 yang masih teregistrasi pada tahun TS-1 ƒ TS-7 yang masih teregistrasi pada tahun TS-1 ƒ TS-6 yang masih teregistrasi pada tahun TS-1 ƒ TS-5 yang masih teregistrasi pada tahun TS-1 ƒ TS-4 yang masih teregistrasi pada tahun TS-1 ƒ TS-3 yang masih teregistrasi pada tahun TS-1 ƒ TS-2 yang masih teregistrasi pada tahun TS-1 ƒ TS -1 ƒ TS-8 yang masih teregistrasi pada tahun TS-0 ƒ TS-7 yang masih teregistrasi pada tahun TS-0 ƒ TS-6 yang masih teregistrasi pada tahun TS-0 ƒ TS-5 yang masih teregistrasi pada tahun TS-0 ƒ TS-4 yang masih teregistrasi pada tahun TS-0 ƒ TS-3 yang masih teregistrasi pada tahun TS-0 ƒ TS-2 yang masih teregistrasi pada tahun TS-0 ƒ TS-1 yang masih teregistrasi pada tahun TS-0 ƒ TS -0 Jumlah lulusan total dari mahasiswa untuk setiap angkatan berdasarkan tahun masuk sampai tahun TS Jenis fasilitas/peralatan utama yang digunakan dalam proses perkuliahan yang terkait dengan mata kuliah MKK, tidak termasuk ATK (Alat Tulis Kantor) habis pakai berdasarkan kelompok jenis fasilitasnya (Prasarana atau Sarana). Prasarana adalah fasilitas yang berupa asset infrastruktur (tidak bergerak) seperti tanah, gedung, ruang perkuliahan, ruang laboratorium, ladang/lahan kebun percobaan, dll. Sarana adalah fasilitas/peralatan (bergerak) yang digunakan dalam proses pembelajaran seperti komputer, alat-alat laboratorium, media belajar, mesin-mesin, dll. Rasio masing-masing prasarana/sarana dengan mahasiswa pemakai Kondisi kelayakan penggunaan (rusak, tidak rusak) Kepemilikan fasilitas (milik sendiri/disewa) Jumlah jam penggunaan fasilitas rata-rata per minggu dalam satu semester, oleh bidang studi yang bersangkutan yang terkait dengan pelaksanaan Tridharma PT. Jumlah dan luas ruang kerja bagi dosen tetap Jumlah dan luas ruang kerja bagi dosen tidak tetap/luar biasa Rekapitulasi jumlah ketersediaan pustaka yang relevan Judul, penulis/penerbit, dan tahun penerbitan pustaka, serta jumlah eksemplar/copy per judul yang dimiliki oleh perpustakaan di lingkungan kampus Nama perpustakaan di luar PT yang dapat diakses Daftar nama Mata kuliah kelompok MKK, MKDK, dan MKP dan bobot sks Jumlah jam rata-rata per minggu yang dialokasikan untuk masing-masing kegiatan untuk setiap mata kuliah SAP dan modul Mekanisme monitoring, penelaahan, dan evaluasi untuk melihat apakah kegiatan-kegiatan yang telah direncanakan pada butir 9a dilaksanakan atau tidak Jenis kegiatan dalam lingkup pendidikan dan penelitian dan pengabdian masyarakat yang melibatkan dosen dan mahasiswa di luar kegiatan kuliah selama 3 tahun terakhir yang

127

10 b 11a 11b 11c 12a1

(1) - (4)

12a2

(1) - (6)

12a3

(1) - (5)

12b 13

(1) – (6)

14 15

(1) - (4) (1) – (4)

16

(1)

17 a. 17 b. 18a

-

(2) - (3) (4) (2) - (4) (5) - (7) (2) - (4) (5) - (7) (2) - (4) (5) - (7)

18 b 18c

(2) - (4) (5) - (7)

18d 19 a 19 b 20

memungkinkan dosen dan mahasiswa berinteraksi Kontribusi kegiatan pada butir 10.a. terhadap peningkatan kualitas proses pembelajaran Panduan Jumlah rata-rata mahasiswa per dosen PA Jumlah pertemuan rata-rata pembimbingan per mahasiswa per dosen per semester Nama dosen tamu/tenaga ahli, tugas dan lama tugas dosen tamu, serta tugas dan lama tugas tenaga ahli Nama dosen yang diberi tugas belajar, tempat tugas belajar (nama institusi dan negara), jenjang studi, bidang studi, dan tahun mulai tugas belajar Nama dosen yang mengikuti kegiatan, tempat, dan waktu kegiatan, sebagai penyaji atau sebagai peserta Tujuan, kriteria keberhasilan dan kemanfaatan upaya dalam butir 12a. Jenis evaluasi kesiapan awal kuliah adalah jenis penilaian yang bertujuan untuk menentukan kemampuan awal mahasiswa pada awal perkuliahan Jumlah dosen tetap yang mengikuti kegiatan Rata-rata beban kerja per semester dosen di PT sendiri dan di luar PT, dalam satuan sks dosen (berdasarkan SK Dirjen DIKTI No. 48 Th. 1983) ƒ Kode etik akademik umum adalah suatu pedoman yang memberikan rambu-rambu etika ilmiah dalam pelaksanaan Tridharma PT, seperti rambu-rambu information sharing, komitmen terhadap pelaksanaan tugas, akuntabilitas pelaksanaan tugas, dll. ƒ Plagiat adalah pengakuan hasil kerja/karya ilmiah orang lain sebagai hasil karya sendiri. Misalnya, mencuplik konsep, gagasan, hubungan kesejawatan, pemikiran mengenai suatu topik secara 100% sama (persis) tanpa menyebutkan sumber aslinya. Kepemilkan pedoman yang tertera Metode sosialisasi pedoman yang ada, cara penanganan kasus pelanggaran Jumlah karya ilmiah dosen tetap yang sesuai dengan bidang 3 tahun terakhir Jumlah karya ilmiah dosen tetap yang tidak sesuai dengan bidang 3 tahun terakhir Jumlah karya ilmiah dosen tetap maupun tidak tetap yang sesuai dalam 3 tahun terakhir Jumlah seluruh karya ilmiah dosen tetap maupun tidak tetap yang tidak sesuai dalam 3 tahun terakhir Jumlah penelitian dosen tetap yang sesuai dalam 3 tahun terakhir Jumlah penelitian dosen tetap yang tidak sesuai Jumlah dana penelitian dari luar PT, di luar dana penelitian skripsi, yang diberi sebagai bagian dari beasiswa Jumlah kegiatan pengabdian kepada masyarakat dosen tetap yang sesuai dalam 3 tahun terakhir Jumlah kegiatan pengabdian kepada masyarakat dosen tetap yang tidak sesuai Jumlah dana pengabdian kepada masyarakat dari luar PT berdasarkan sumber dana Metode pelaksanaan kegiatan yang digunakan, serta informasi terkait. Contoh profil akademis lulusan, kuesioner pelacakan alumni, bukti pertemuan dengan calon pengguna lulusan, dll Upaya pemanfaatan umpan balik bagi peningkatan PS Kerjasama/kemitraan adalah bentuk kerjasama antar-institusi baik di dalam maupun di luar negeri dalam pelaksanaan aspek-aspek Tridharma PT, misal penelitian bersama, tukar menukar dosen dan mahasiswa, penyelenggaraan seminar bersama, dll

128

4.1.2. Sistem Informasi Akademik (SIAKAD) di Perguruan Tinggi 4.1.2.1. Implementasi Sistem Informasi Akademik 4.1.2.1.1. Sistem Informasi Akademik di UGM Yogyakarta Penjelasan tentang Sistem Informasi Akademik di Universitas Gadjah Mada (UGM) Yogyakarta dapat ditemukan dalam beberapa sumber referensi, yaitu Rencana Strategis UGM tahun 2003-2007, SK Rektor UGM Nomor 259/P/SK/HT/2004, website PPTI UGM, dan website Panduan Sistem Informasi Akademik Fakultas Pertanian UGM. Rencana Strategis UGM tahun 2003-2007 yang disahkan oleh Majelis Wali Amanat UGM pada tanggal 25 April 2004 memuat penjelasan tentang beberapa hal terkait Sistem Informasi Akademik di UGM. Sasaran SIM UGM adalah terselenggaranya SIM yang menjamin terlaksananya perencanaan dan manajemen keuangan, SDM, sarana prasarana secara efektif dan efisien, yang meliputi subsistem sebagai berikut: (1) Sistem Akuntansi UGM (SISKUNGAMA) dan Sistem Informasi Kepegawaian UGM (SIMPEGAMA); (2) Sistem Informasi Akademik UGM (SIAGAMA) dan Sistem Informasi Gedung dan Ruang (SIMGERU); (3) Sistem Informasi Alumni UGM (SILUGAMA) dan Kemahasiswaan (SIMAWA); (4) Sistem Informasi Perpustakaan UGM merupakan bagian terpisah. Dalam sumber referensi yang lain, Bambang N. Prastowo (2004) menjelaskan, bahwa penggunaan komputer untuk Sistem Informasi Akademik (SIA) di UGM mengalami perubahan sejalan dengan perubahan teknologi informasi. Awalnya SIA menggunakan mainframe dengan tujuan utama untuk registrasi/herregistrasi, pendaftaran KRS, dan pencetakan presensi kuliah dan ujian yang

129

dilaksanakan terpusat di mainframe. Penggunaan mainframe yang terpusat dirasa kurang fleksibel dalam pemenuhan kebutuhan lokal fakultas dan menyebabkan antrian panjang pada pencetakan dokumen masal. Dengan hadirnya PC, manajemen akademik dilaksanakan tersebar di masing-masing fakultas/jurusan. Penggunaan PC yang dapat berdiri sendiri memberikan fleksibilitas tinggi dalam pelayanan kebutuhan lokal pada masing-masing unit. Namun, kastemisasi yang berlebihan di tingkat fakultas/jurusan menyulitkan proses integrasi di tingkat Universitas dan validitas kode mata kuliah, NIP dosen, dan NIU/NIF mahasiswa tidak bisa secara langsung terkontrol. Kehadiran jaringan komunikasi data kampus membuka jalan untuk mengimplementasikan SIA terpadu yang dapat mengakomodasikan fleksibilitas pelayanan kebutuhan lokal dan sekaligus kontrol validitas data secara terpusat. UPT PUSKOM UGM telah mengembangkan SIA terpadu yang dipersiapkan untuk bisa dioperasikan Fakultas/Jurusan/Program studi dengan kontrol validitas dan pelaporan data secara terpadu di Universitas. Sistem ini telah diujicobakan di Fakultas Peternakan, Fakultas Kedokteran Gigi dan program D3 Agro Industri Fakultas Teknologi Pertanian, sedangkan Fakultas Hukum dan Isipol sedang dalam proses migrasi dan validasi data (http://www.ppti.ugm.ac.id/). Sementara itu, Fakultas Pertanian (FAPERTA) UGM Yogyakarta, telah mengimplementasikan SIA untuk lingkup Fakultas. SIA FAPERTA menyediakan layanan untuk KRS baru, Perubahan KRS, Lihat KRS, Lihat KHS, serta Transkrip (http://www.faperta.ugm.ac.id/akademik/manual.pdf).

130

4.1.2.1.2. Sistem Informasi Akademik di UI Jakarta Situs Sistem Informasi Akademik Universitas Indonesia (UI) Jakarta menyediakan layanan khusus untuk mahasiswa UI yang masih aktif. Setiap mahasiswa mempunyai account (nama dan kata kunci/password) yang digunakan untuk mengakses situs web ini. Bila login berhasil, maka mahasiswa akan masuk ke halaman utama Sistem Informasi Akademis Mahasiswa (SIAK). Data-data di situs ini hanya salinan dari data di server utama SIAK, sehingga ada rentang waktu antara perubahan data di server utama SIAK dengan penyalinan data ke situs ini (https://www.akademik.ui.ac.id/). Selanjutnya, AAG. Indra Pramana, Cipto Asido Sidabalok, Jefri C. Sormin, dan Minnarto Djojo (2001) melalui perusahaannya Arcle Technologies menawarkan proyek Perancangan Software Sistem Informasi Akademik Fakultas Teknik Universitas Indonesia (FTUI). Software yang ditawarkan berfungsi untuk memberikan informasi tentang segala sesuatu yang berkaitan dengan seminar/skripsi di Jurusan Elektro FTUI. Software ini ditujukan untuk staf karyawan administrasi jurusan Elektro FTUI dan mahasiswa yang ingin menggunakan informasi tersebut untuk setiap kegiatan yang berkaitan dengan seminar/skripsi sehingga dapat membantu

memudahkan

(http://www.arcle.net/).

mahasiswa

dalam

mengurus

seminar/skripsi

131

4.1.2.1.3. Sistem Informasi Akademik di UAJ Jakarta Pihak Yayasan dan Universitas Katolik Atma Jaya (UAJ) Jakarta sejak tahun 2003 sudah mencanangkan proyek komputerisasi Atma Jaya yang dikenal dengan Amadeus yang akan berlangsung sampai tahun 2007. Tujuan dari proyek Amadeus adalah untuk memanfaatkan sebesar-besarnya teknologi informasi untuk membantu proses kegiatan belajar-mengajar, administrasi, dan pengambilan keputusan. Prosesproses yang bersifat rutin dan bersifat manual akan diotomatisasi sehingga bisa mempersingkat waktu yang diperlukan untuk menyelesaikan pekerjaan-pekerjaan tersebut. Sistem Informasi yang dibangun mencakup Sistem Informasi Akademik, Sistem Perpustakaan, Sistem Sumber Daya Manusia, Sistem Keuangan, dan Sistem eLearning. Semua sistem informasi yang dibangun saling terintegrasi sehingga informasi bisa mengalir ke seluruh bagian kampus secara real-time dan akurat. Dengan teknologi berbasis web setiap sivitas akademika baik dosen, mahasiswa, maupun karyawan bisa on-line ke sistem dan melakukan pekerjaannya dengan memanfaatkan sebesar-besarnya teknologi informasi. Situs Sistem Informasi Akademik UAJ Jakarta juga telah dikembangkan untuk memberikan layanan informasi bagi sivitas akademika dan masayarakat umum dengan menyediakan infromasi yang dikemas dalam empat pilihan yaitu, pilihan Info Atma Jaya, Program Sarjana, Program Pascasarjana, Lembaga, serta Katalog. Situs ini juga menyediakan informasi tentang Mahasiswa, Alumni, Dosen, Peneliti, Lustrum IX, Atma Jaya Peduli. UAJ Jakarta juga memberikan layanan lain dalam situs ini, yaitu: (1) Sintesis, untuk memberikan layanan Sistem Informasi Interaktif

132

Mahasiswa; (2) Sintedos, untuk memberikan layanan Sistem Informasi Interaktif Dosen; (3) User Support, untuk memberikan layanan khusus bagi user di Atma Jaya yang mengalami kesulitan/masalah tentang komputer, e-mail, network, atau aplikasi (http://www.atmajaya.ac.id/).

4.1.2.1.4. Sistem Informasi Akademik di UIN Syarif Hidayatullah Jakarta Situs Sistem Informasi Perguruan Tinggi UIN (SIMPERTI-UIN) Syarif Hidayatullah Jakarta merupakan aplikasi terpadu di lingkungan UIN Syarif Hidayatullah. Situs ini

mulai di-launching pada tahun 2004 dengan menyediakan enam pilihan menu, yaitu Home, Fakultas, Lembaga Pendukung, Akademik, Kemahasiswaan, serta Kontak. Pilihan menu Akademik menyediakan informasi Pedoman Akademik, meliputi Pendaftaran Calon Mahasiswa; Biaya Pendidikan; Sistem Kredit Semester (SKS); Program Pendidikan, Beban Studi, dan Bobot Kredit; Penulisan Makalah, Skripsi, Tesis, dan Disertasi; Pengabdian pada Masyarakat; Struktur Kurikulum; Beban Studi Setiap Semester; Mahasiswa Pendengar (Mustami'); Mahasiswa Program Sisipan (Sandwich Program); Program Gelar Ganda (Double Degree) Bagi Program S-1; Program Double Degree Bagi Program Magister; Program Gelar Double Degree Bagi Program Doktor; Program Doctor By Research; Ketentuan Umum Konversi Mata Kuliah dan Nilai; Evaluasi, Ujian, Penilaian, Indeks Prestasi dan Predikat Kelulusan; Sanksi Pendidikan; Penasehat Akademik; Prosedur Administrasi dan Pelayanan Akademik; serta Sanksi Akademik dan Non Akademik. Selain itu, situs ini menyediakan informasi umum, yaitu Tentang UIN, Organisasi, Fasilitas, Kerjasama,

133

Jurnal, serta Favourite Links. Halaman utama situs ini juga menyediakan empat buah link terkait, yaitu Pedoman akademik, Kalender akadmeik, Info SPMB 2004 (S.1), serta Info SPMB 2004 Pascasarajana (S.2/S.3). Bagi Mahasiswa, Alumni, Dosen, Staf/Karyawan serta orang tua/wali Mahasiswa diberikan akses khusus untuk mengakses layanan yang disediakan oleh SIMPERTI-UIN, caranya adalah dengan melakukan registrasi secara on-line untuk mendapatkan kode akses. Layanan on-line yang telah dibuka adalah layanan akademik yang terkait dengan perkuliahan mahasiswa, antara lain Kurikulum Pendidikan, Dosen Pengajar, KRS, KHS, dan Status Pembayaran Mahasiswa. Untuk sementara SIMPERTI-UIN baru dapat melayani Mahasiswa Pascasarjana Program S.2 dan S.3, sedangkan SIMPERTI-UIN untuk mahasiswa Program S.1 masih dalam proses pengembangan (http://www.uinjkt.ac.id/).

4.1.2.1.5. Sistem Informasi Akademik di UII Yogyakarta Situs Sistem Informasi Akademik Universitas Islam Indonesia (UII) Yogyakarta menyediakan dua pilihan bahasa, yaitu Inggris dan Indonesia yang masing-masing menyajikan 13 pilihan menu, yaitu Sekilas UII, Program Studi, Akademik,

Layanan,

Beasiswa/Santunan

Bagi

Sumber Mahasiswa

Daya, Aceh

Kemahasiswaan, yang

terkena

Alumni Musibah,

FAQ, Jurnal, UII webmail, Warta-Kegiatan, Alumni Career Center, serta QuestBook. Selain itu, situs ini juga menampilkan informasi berita-berita terbaru pada pilihan Warta dan informasi kegiatan pada pilihan Kegiatan.

134

Pilihan menu Akademik menyajikan sebanyak 15 macam informasi seputar kegiatan akademik, yaitu Visi dan Misi, Jurusan dan Bagian, Fasilitas, Organisasi, Staf Pengajar, Sejarah, Proyeksi Perkembangan, Kurikulum, Perkuliahan dan Praktikum, Ketentuan dan Prosedur, Sistem Pendidikan, Rencana Kuliah, Evaluasi dan Penilaian, Penyelenggaraan Ujian, serta Tugas Akhir. Kalangan sivitas akademika dapat mengakses Layanan Informasi Akademik (LIA) yang disediakan oleh Sistem Informasi Akademik (SIMAK) setelah berhasil login ke sistem (http://www.uii.ac.id/).

4.1.2.1.6. Sistem Informasi Akademik di UMY Yogyakarta Universitas Muhammadiyah Yogyakarta (UMY) telah bekerja sama dengan beberapa pihak untuk mengembangkan sistem informasi yang menyediakan layanan sistem informasi terpadu, meliputi: (1) Situs Resmi UMY, memuat informasi tentang situs, maksud dan tujuan pengembangan situs, fitur dan fasilitas dalam situs, serta Site Credit; (2) Sistem Informasi Penmaru, memuat informasi tentang Sistem Infomasi Penmaru UMY, Maksud dan tujuan, serta Fungsi dan Fasilitas; (3) Sistem Informasi Akademik, memuat informasi tentang Sistem Informasi Akademik (SIA), Pendaftaran, Informasi cara pendaftaran dalam SIA, Aksesabilitas, serta Syarat dan Kondisi; (4) Sistem Informasi Manajemen Keuangan, memuat informasi tentang SIM Keuangan, Fungsi dan Fasilitas SIM Keuangan, serta Review Kinerja; (5) Sistem Informasi Manajemen Kepegawaian, memuat informasi tentang SIM Kepegawaian, Fasilitas dan Fungsi, Implementasi, serta Penerapan SIM Kepegawaian; (6) Sistem

135

Informasi Manajemen Perpustakaan, memuat informasi tentang SIM Perpustakaan, Fasilitas peminjaman, Fasilitas yang disediakan dalam SIM Perpustakaan, Katalog, serta Katalog buku (http://www.umy.ac.id/).

4.1.2.1.7. Sistem Informasi Akademik di UII ISTA Institut Sains & Teknologi AKPRIND (ISTA) Yogyakarta bekerjasama dengan Ikatan Keluarga Alumni (IKA-ISTA) berhasil mengembangkan website yang telah di-launching sejak tahun 2002. Situs ini menyediakan layanan informasi meliputi Warta kampus, Profil Kampus, Penerimaan MABA, Sarana dan Prasarana, Program Studi, Kegiatan Mahasiswa, Riset dan Pengabdian, Inovasi Teknologi, Alumni, Warnet serta BatistaNet. Situs ini juga menyajikan informasi tentang hasil Akreditasi, Kalender Akademik, Buku Tamu, dan Kontak. Pada bagian yang lain, situs ini menyediakan informasi lowongan kerja bagi alumni, serta fasilitas Penmaru on-line. Dan sejak tahun 2004, ISTA menyediakan layanan informasi Pengumuman Hasil Seleksi Penmaru melalui SMS dengan tarip khusus (http://www.akprind.ac.id/). Jaringan

intranet

yang

menghubungkan

tiga

lokasi

kampus,

yaitu

Laboratorium Pusat di Kotabaru, Kampus I di Balapan, dan Kampus II di Bimasakti, disediakan untuk mendukung penerapan Sistem Informasi Akademik (SIA) di ISTA. SIA ini dapat diakses oleh segenap sivitas akademika setelah berhasil melewati proses login. SIA menyediakan beberapa layanan antara lain, penawaran matakuliah, penjadwalan kuliah, Pra-KRS, KRS, perubahan KRS, KHS, yudisium, transkrip. Sementara itu, apliaksi-aplikasi untuk penggajian, kepegawaian, perpustakaan,

136

praktikum, Penmaru, heregistrasi, SPP-DPP, KKN, PKN-KP-Merencana-TA-Skripsi, dan beberapa aplikasi kecil pendukung evaluasi kinerja telah dikembangkan dan diimplementasikan secara terpisah dari SIA. Dalam dokumen Evaluasi Diri Program Studi Teknik Informatika ISTA tahun 2002, dijelaskan bahwa SIM di ISTA memiliki dua macam tujuan, yang pertama adalah untuk memenuhi kebutuhan administrasi umum, keuangan, dan administrasi akademik, seperti pengolahan data mahasiswa, dosen, lulusan, nilai ujian, transkip akademik, ijasah, arsip, dan laporan; dan yang kedua adalah untuk memenuhi kebutuhan data statistik yang diperlukan dalam pengelolaan Program Studi. Dalam sumber referensi yang lain, yaitu Portofolio ISTA tahun 2002, dalam Bab V tentang Sistem Informasi dijelaskan bahwa untuk menunjang sistem informasi yang handal, diadakanlah prasarana untuk komputerisasi yang antara lain berupa jaringan komputer berbasis LAN, server, Internet, printer, modem, router, HUB, dan UPS. Pemanfaatan fasilitas tersebut di samping ditujukan untuk kegiatan praktikum, penelitian, dan pengabdian masyarakat, juga dimanfaatkan untuk sistem administrasi dengan jaringan terpadu.

4.1.2.1.8. Sistem Informasi Akademik di Pascasarjana STSI Surakarta Situs Sistem Informasi Akademik Program Master Pascasarjana STSI Surakarta dikembangkan untuk melengkapi sistem informasi manual yang dalam batas tertentu masih tetap digunakan. Website ini menyediakan informasi umum tentang Program Master Pascasarjana, Program Studi yang diselenggarakan,

137

Kurikulum, Fasilitas dan Infrastruktur, Dosen, Beaya kuliah, Syarat menjadi mahasiswa, Waktu pendaftaran, Bentuk seleksi masuk, Pengumuman hasil seleksi, Kegiatan seminar dan workshop, Ujian Tugas Akhir, Jurnal, Terbitan buku, serta kegiatan akademik yang dipandang perlu. Untuk keperluan efektifitas bimbingan Tugas Akhir serta korespondensi antar Mahasiswa, Dosen, serta masyarakat yang berkeinginan untuk berhubungan dengan Program Master Pascasarjana disediakan email khusus dengan alamat [email protected]. Sebuah workstation khusus di ruang Perpustakaan Pascasarjana disediakan bagi sivitas akademika Pascasarjana STSI Surakarta untuk dapat mengakses dengan cepat seluruh informasi tersebut. Sistem informasi yang telah dikembangkan itu pada dasarnya cukup memadai dan merupakan sebuah kekuatan yang dimiliki oleh Program Master Pascasarjana STSI Surakarta. Kelemahan yang tampak saat ini adalah belum seluruh sivitas akademika memanfaatkan situs tersebut secara maksimal. Situasi demikian terjadi akibat kesenjangan pemahaman sebagian sivitas akademika terhadap sistem informasi yang berbasis teknologi informasi, serta masih terbatasnya tenaga teknis yang memiliki kemampuan untuk memasukkan berbagai informasi dalam kemasan yang menarik.

Hambatan

ini

perlu

segera

mendapat

perhatian

secara

serius

(http://www.stsi-ska.ac.id/pasca/sisteminformasi.htm).

4.1.2.1.9. Sistem Informasi Akademik di UNIBRAW Malang Situs Sistem Informasi Akademik Universitas Brawijaya (SIAKAD.UB) Malang dikembangkan oleh Unit Pengkajian dan Penerapan Teknologi Informasi

138

(UPPTI) UNIBRAW. SIAKAD.UB memiliki enam modul, yaitu: (1) SIAKAD (Sistem Informasi Akademik), yaitu untuk menangani dan mengolah data akademik secara terpadu; (2) SIREGI WEB (Sistem Registrasi Online), menyediakan layanan pengaturan besar pembayaran dan status aktif pada registrasi mahasiswa; (3) SIMPEL (Pelaporan Registrasi Online), menyediakan laporan hasil registrasi secara cepat dan efisien, khusus bagi Pejabat rektorat atau fakultas, (4) SIAM (Sistem Informasi Mahasiswa

Online),

memungkinkan

Mahasiswa

melakukan

KRS

online,

menyediakan informasi akademik dan registerasi; (5) SIUDA (Sistem Wisuda Online), memungkinkan fakultas melakukan pendaftaran wisuda; (6) SMS Akademik, memungkinkan Mahasiswa mengakses informasi IP, IPK, SKS, dan Daftar Ulang melalui SMS. Dalam penjelasan yang lebih lanjut, SIAKAD.UB memiliki beberapa fitur, yaitu: integrasi dengan jaringan komputer, standarisasi aturan akademik, sinkronisasi data yang terdistribusi, analisa data secara akurat, pencadangan (backup) data, layanan online melalui web, tingkat keamanan data tinggi, kemudahan pengembangan lanjutan, serta adaptasi pada perubahan kurikulum (http://www.siakad.brawijaya. ac.id/).

4.1.2.1.10. Sistem Informasi Akademik di Universitas Negeri Jember UNEJ pada tahun 1983 membentuk Pusat Komputer dan pada tahun 1984 mendapat bantuan satu perangkat mini komputer (Mini G Honeywell Bull). Pada tahun 1986 didirikan gedung Pusat Komputer yang bertujuan untuk mengelola dan merawat fasilitas penunjang kegiatan pembinaan Tri Dharma Perguruan Tinggi.

139

Tahun 1994, fasilitas komputer selain dipergunakan sebagai sarana penunjang teknis dalam penerapan Tri Dharma Perguruan Tinggi, juga dipergunakan dalam mengembangkan SIM Perguruan Tinggi, dengan harapan mampu menghasilkan informasi dalam waktu yang singkat, mempermudah pekerjaan rutin, serta membuat artificial integency bagi pekerjaan yang dikerjakan oleh tenaga dengan kemampuan yang relatif rendah jika dibandingkan dengan kriteria tenaga yang dibutuhkan oleh pekerjaan tersebut. Pengembangan komputer dalam informasi global juga telah dikembangkan pada tahun 2000, pemasangan VSAT guna komunikasi global (Internet) dan sudah berakhir pada tahun 2002. Visi UNEJ adalah menerapkan dan mengembangkan teknologi informasi untuk mewujudkan UNEJ sebagai Cyber Campus and Cyber Community. Sedangkan misi yang diemban adalah: (1) Memberikan layanan kepada sivitas academika dalam pemanfaatan Teknologi Informasi untuk melaksanakan program Tri Dharma Perguruan Tinggi; (2) Mewujudkan Sistem Informasi Manajemen di UNEJ untuk mendukung kegiatan akademik dan administrasi serta pengambilan keputusan baik di tingkat Universitas maupun level manajemen di bawahnya; (3) Mengembangkan budaya masyarakat informasi di lingkungan kampus UNEJ dan masyarakat Indonesia pada umumnya; (4) Berpartisipasi dalam mengembangkan jaringan kerjasama antara UNEJ dengan pihak-pihak luar, khususnya

dalam

penerapan

(http://www.unej.ac.id/upt/ti/).

serta

pengembangan

teknologi

informasi

140

4.1.2.1.11. Sistem Informasi Akademik di UNAIR Surabaya Situs Sistem Informasi Akademik Universitas Airlangga Surabaya dikembangkan oleh UPT Puskom UNAIR. Situs ini menyajikan informasi dalam dua pilihan bahasa, yaitu Inggris dan Indonesia, dengan enam menu pilihan, yaitu: (1) UNAIR, memiliki submenu Sejarah, Visi, Misi, Pimpinan, serta Fakultas; (2) Akademik, memiliki submenu Kalender pendidikan, Aturan, Matakuliah, Evaluasi, serta Mutasi; (3) PMB, memiliki submenu PMDK dan SPMB; (4) Beasiswa, memiliki submenu Peluang dan Beasiswa UNAIR; (5) Kolom Pembaca, memiliki submenu Surat Pembaca dan Pembaca Menulis; (6) Perpustakaan, memiliki submenu e-Library, Catalog online, ADLN, Automation, Psycho Corner, serta American Corner. Situs ini juga menyediakan empat pilihan informasi yaitu Informasi, Lembaga, Berita, dan Profil. Pilihan Informasi memuat informasi tentang Akademik, Pegawai, Alumni, Guru Besar, Warta Online, serta e-Mail. Pilihan Lembaga memuat informasi tentang lembaga-lembaga di UNAIR, yaitu LPPM, Puskom, Haki, Pinlab’s, TDC, JPC, serta MKU. Pilihan Berita memuat informasi seputar kegiatan di UNAIR, sedangkan pilihan Profil menyajikan profil personal di lingkungan UNAIR (http://www.unair.ac.id/).

4.1.2.1.12. Sistem Informasi Akademik di MMT-ITS Surabaya Situs Sistem Informasi Akademik Magister Manajemen Teknologi ITS (MMT-ITS) telah di-launching pertama kali pada tahun 2001. Situs ini menyajikan informasi umum, meliputi: (1) Pendaftaran mahasiswa baru, menyediakan forum

141

diskusi dan tanya jawab seputar program pendidikan yang ditawarkan oleh MMTITS, mekanisme pendaftaran mahasiswa dan fasilitas yang disediakan di MMT-ITS; (2) Agenda kegiatan MMT-ITS, menyediakan informasi jadwal agenda kegiatan yang diadakan MMT-ITS seperti Seminar, Kuliah Tamu, Wisuda, dan kegiatan lain; (3) Manajemen Teknologi Lingkungan, menyediakan forum diskusi dan perbincangan tentang dibukanya bidang keahlian baru Manajemen Teknologi Lingkungan di MMTITS. Situs ini juga menyediakan informasi akademik, administrasi keuangan yang forum tanya jawab masalah administrasi keuangan seperti SPP, Denda Mengulang, Keterlambatan Tesis, Komplain data, dan sebagainya. SIM Akademik dan Keuangan di MT-ITS disediakan khusus bagi para mahasiswa. Untuk bisa mengakses SIM Akademik dan Keuangan harus melewati proses login sistem. Situs ini menyediakan tujuh pilihan proses, yaitu FAQ, Search, Member, Group, Daftar, Data Pribadi, serta Login (http://www.mmt.its.ac.id).

4.1.2.1.13. Sistem Informasi Akademik di UNHAS Makasar Situs Sistem Informasi Akademik (Academic Information System/AIS) Universitas Hasanuddin (UNHAS) Makassar dibuat untuk memberikan informasi di lingkungan UNHAS maupun yang membutuhkan data/informasi/kegiatan akademik di UNHAS. Kegiatan belajar mengajar dapat dilakukan di sini, dosen membuat kelas pembelajaran menurut mata kuliah yang diajarkan dan meng-upload bahan kuliahnya, sementara itu mahasiswa peserta mata kuliah tersebut dapat mengikuti kuliah dan membaca bahan kuliah yang tersedia. AIS menyediakan Tampilan data seluruh Dosen,

142

Tampilan data seluruh Mahasiswa, Pencarian data (Dosen, Mahasiswa, Pegawai, Alumni, Jurusan, Pemakai kelas, Ruangan, serta Mata kuliah), Pimpinan, dan lainlain. Fasilitas lainnya dan sedang diusahakan tersedia adalah e-Learning secara online dengan pembuatan kelas virtual (http://www.unhas.ac.id/~ais/).

4.1.2.1.14. Sistem Informasi Akademik di Universitas Islam Sumut Situs Sistem Informasi Akademik Universitas Islam Sumatra Utara (UISU) merupakan website yang dibangun oleh Biro Informasi dan Perencanaan UISU bekerja sama dengan Program Studi Teknik Informatika UISU. Website ini memfokuskan pada penyajian pelayanan Sistem Informasi Akademik, yang menyajikan informasi Profil, Informasi Akademik, Pustaka, dan Alumni. Pada tanggal 8 Juni 2005, kondisi website ini masih mengandung beberapa link kosong, dan masih dilengkapi secara bertahap. Layanan Informasi Akademik bagi para mahasiswa UISU diberikan melalui Anjungan Informasi, yaitu berupa PC yang didesain sedemikian rupa sehingga mudah dioperasikan. Anjungan Informasi berjumlah 3 unit masing-masing diletakkan di Biro Rektor, halaman depan ruang Yayasan, dan halaman depan Biro Fakultas Hukum. Anjungan Informasi tersebut dalam waktu dekat direncanakan berjumlah 7 unit. Selain itu, Informasi Akademik juga dapat dilihat melalui website, melalui proses login dengan cara memasukkan NPM dan password. Password default sama dengan NPM dan dapat dirubah setelah mahasiswa berhasil masuk ke sistem setelah melalui proses login. Website ini sedang dipersiapkan untuk prosedur penggunaan e-

143

mail bagi seluruh sivitas akademika UISU. Nantinya, setiap sivitas akademika dapat memiliki

e-mail

secara

cuma-cuma

dengan

nama

[email protected]

(http://www.uisu.ac.id/).

4.1.2.2. Sistem Informasi Akademik dalam Peraturan Perundangan 4.1.2.2.1. Sistem Informasi Akademik dalam UU SISDIKNAS Peraturan

perundang-undangan

tentang

Sistem

Pendidikan

Nasional

(SISDIKNAS) di Indonesia tercantum dalam Undang-Undang (UU) Nomor 20 tahun 2003 tentang Sistem Pendidikan Nasional Republik Indonesia (UU SISDIKNAS) yang disahkan di Jakarta tanggal 8 Juli 2003 oleh Presiden Republik Indonesia Megawati Soekarnoputri. Sebenarnya UU SISDIKNAS tidak secara eksplisit mencantumkan aturan tentang Sistem Informasi Akademik, namun aturan-aturan yang tercantum didalamnya memiliki implikasi terhadap Sistem Informasi Akademik pada institusi Pendidikan Tinggi.

4.1.2.2.2. Sistem Informasi Akademik dalam Peraturan Pemerintah Peraturan tentang Pendidikan Tinggi (DIKTI) di Indonesia tercantum dalam Peraturan Pemerintah (PP) Republik Indonesia Nomor 60 tahun 1999 tentang Pendidikan Tinggi yang ditetapkan di Jakarta pada tanggal 24 Juni 1999 oleh Presiden Republik Indonesia Bacharuddin Jusuf Habibie. Sebenarnya PP tersebut tidak secara eksplisit mencantumkan aturan tentang Sistem Informasi Akademik,

144

namun demikian aturan-aturan yang tercantum didalamnya memiliki implikasi terhadap Sistem Informasi Akademik pada institusi Pendidikan Tinggi.

4.1.2.2.3. Sistem Informasi Akademik dalam KPPTJP Kerangka Pengembangan Pendidikan Tinggi Jangka Panjang (KPPTJP) 19962005 tidak secara eksplisit mencantumkan aturan tentang Sistem Informasi Akademik, namun demikian keterangan yang tercantum didalamnya memiliki implikasi terhadap Sistem Informasi Akademik pada institusi Pendidikan Tinggi. Dalam Program Utama nomor A.2.3. tentang Peningkatan Peran Perguruan Tinggi dalam Perencanaan Pengembangannya dijelaskan bahwa Program Utama Peningkatan Peran Perguruan Tinggi Dalam Perencanaan Pengembangannya mempunyai tujuan meningkatkan kemampuan untuk: 1. Menetapkan tujuan dan sasaran; 2. Mengupayakan dan meningkatkan kelaikan memperoleh sumberdaya; 3. Merencanakan dan melaksanakan proses pencapaian tujuan. Tolok ukur pencapaian tujuan tersebut adalah adanya Unit Kerja Tetap untuk perencanaan pengembangan di masing-masing Perguruan Tinggi yang ditunjang oleh Sistem Informasi Manajemen yang efektif. Dalam Program Utama nomor A.3.1 tentang Pengembangan Pengelolaan Sumberdaya

Terpadu

di

Perguruan

Tinggi,

dijelaskan

bahwa

melalui

terselenggaranya sistem Penganggaran Belanja Terpadu yang menjadi bagian dari Sistem Informasi Manajemen, Pimpinan Perguruan Tinggi dapat merencanakan dan

145

melaksanakan manajemen sumberdaya yang efisien dan efektif. Tolok ukur pencapaian tujuan tersebut adalah adanya tata buku aliran sumberdaya terpadu di Perguruan Tinggi dan adanya manajemen sumberdaya yang efisien dan efektif. Dalam Program Utama nomor A.4.2 tentang Peningkatan Kesiapan PTN dan PTS Terhadap Fungsi dan Pelaksanaan Fungsi BAN dijelaskan bahwa suatu sistem informasi manajemen yang baik, yang mengandung unsur-unsur pengelolaan sumberdaya terpadu akan membantu kelancaran proses akreditasi oleh BAN terhadap Perguruan Tinggi yang bersangkutan. Di samping itu hasil evaluasi-diri Perguruan Tinggi yang bersangkutan dapat digunakan sebagai titik tolak proses akreditasi tersebut. Bagi Perguruan Tinggi yang bersangkutan, hasil proses akreditasi, menjadi acuan untuk merancang dan merencanakan program-program peningkatan kwalitas kinerja. Tolok ukur pencapaian tujuan tersebut adalah tersedianya data, informasi dan laporan evaluasi-diri di Perguruan Tinggi yang dapat digunakan sebagai titik tolak proses akreditasi (http://www.dikti.org).

4.1.2.2.4. Sistem Informasi Akademik dalam Naskah Akademik Sistem Akreditasi Terkait dengan Akreditasi Instistusi Perguruan Tinggi, Badan Akrediktasi Nasional Perguruan Tinggi Departemen Pendidikan Nasional Republik Indonesia telah menerbitkan naskah Buku I tentang Naskah Akademik Sistem Akreditasi Pendidikan Tinggi pada tahun 2002. Naskah ini tidak secara eksplisit mencantumkan aturan tentang Sistem Informasi Akademik, namun demikian keterangan-keterangan

146

yang tercantum didalamnya memiliki implikasi terhadap Sistem Informasi Akademik pada institusi Pendidikan Tinggi. Keterangan-keterangan yang dimaksud tercantum pada Bagian B tentang Standar Akreditasi Institusi dan Program Studi. Dalam naskah tersebut dijelaskan bahwa standar akreditasi institusi dan program studi terdiri atas:1). Standar Akreditasi Institusi Peguruan Tinggi (IPT); (2) Standar Akreditasi Program Studi. Standar yang digunakan untuk menggambarkan komitmen inti kapasitas Institusi Perguruan Tinggi, meliputi: (1) Integritas; (2) Visi, misi, tujuan dan sasaran; (3) Tata pamong (governance); (4) Sumberdaya manusia; (5) Sarana dan prasarana; (6) Keuangan; (7) Sistem informasi; (8) Keberlanjutan. Standar yang digunakan untuk menggambarkan komitmen inti terhadap efektivitas pendidikan Perguruan Tinggi, meliputi: (9) Mahasiswa; (10) Kurikulum; (11) Sistem pembelajaran; (12) Penelitian dan Pengabdian kepada masyarakat; (13) Sistem penjaminan mutu; (14) Sistem pengelolaan; (15) Suasana akademik; (16) Program studi. Standar tentang Sistem Informasi memiliki enam parameter, yaitu: (1) Sistem iformasi yang telah terlembaga; (2) Implementasi rencana pengembangan sistem informasi; (3) Kemudahan penggunaan, meliputi akses bagi mahasiswa, akses bagi staf, dan akses dari luar kampus; (4) Penggunaan sebagai sarana informasi baik internal (local) maupun eksternal (global); (5) Pelatihan penggunaan IT untuk sivitas akademika dan karyawan; (6) Sarana, yang meliputi: kecukupan, yaitu rasio mahasiswa/terminal,

rasio

dosen/terminal,

bandwidth,

serta

mahasiswa/bandwidth; efisiensi penggunaan; kesesuaian, kemutakhiran.

rasio

147

4.1.2.2.5. Sistem Informasi Akademik dalam Portofolio Akreditasi Terkait dengan Akreditasi Instistusi Perguruan Tinggi, Badan Akrediktasi Nasional Perguruan Tinggi Departemen Pendidikan Nasional Republik Indonesia telah menerbitkan naskah Buku II tentang Pedoman Penyusunan Portofolio Akreditasi Institusi Perguruan Tinggi pada tahun 2003. Naskah ini tidak secara eksplisit mencantumkan aturan tentang Sistem Informasi Akademik, namun demikian keterangan-keterangan yang tercantum didalamnya memiliki implikasi terhadap Sistem Informasi Akademik pada institusi Pendidikan Tinggi. Dalam naskah ini dijelaskan secara singkat bagaimana memberikan penjelasan pada bagian Sistem Informasi dalam penyusunan Portofolio Akreditasi Institusi Perguruan Tinggi, yaitu memuat uraian mengenai hal-hal berikut: 1. Sistem informasi manajemen untuk mendukung kegiatan akademik dan nonakademik, meliputi: Pengelolaan sistem informasi; Jenis informasi yang disediakan; Ketersediaan perangkat keras, perangkat lunak dan sumber daya manusia; Keberadaan dan pemanfaatan jaringan lokal (LAN), serta Keberadaan dan pemanfaatan jaringan luas (WAN) 2. Jenis informasi yang disediakan 3. Kemudahan penggunaan (akses) bagi dosen, mahasiswa, dan orang luar 4. Pemanfaatan informasi oleh pimpinan, dosen, mahasiswa, dan masyarakat 5. Kecukupan

sarana

informasi,

yaitu

rasio

mahasiswa/terminal,

dosen/terminal, bandwidth, serta rasio mahasiswa/bandwidth 6. Kesesuaian dengan kebutuhan

rasio

148

7. Kemutakhiran 8. Pelatihan penggunaan

4.1.2.2.6. Sistem Informasi Akademik dalam Penilaian Portofolio Akreditasi Terkait dengan Akreditasi Instistusi Perguruan Tinggi, Badan Akrediktasi Nasional Perguruan Tinggi Departemen Pendidikan Nasional Republik Indonesia telah menerbitkan naskah Buku V tentang Matrik Penilaian Portofolio Akreditasi Institusi Perguruan Tinggi pada tahun 2003. Dalam naskah ini dijelaskan bagaimana penilaian Portofolio Akreditasi Institusi Perguruan Tinggi dalam bentuk matrik sebagaimana ditampilkan dalam Tabel 4.4. Tabel 4.4: Matrik penilaian Portofolio Akreditasi Institusi Perguruan Tinggi KOMPONEN/ PARAMETER 7.1. Pengelolaan Sistem Informasi

7.2. Perangkat Keras (Hardware)

SANGAT BAIK 5 • Memiliki organisasi pengelola sistem informasi yang sangat lengkap • Memiliki tata cara pengumpulan, analisis dan penyajian informasi yang sangat akurat

BAIK 4 • Memiliki organisasi pengelola sistem informasi yang lengkap • Memiliki tata cara pengumpulan, analisis dan penyajian informasi yang akurat

• Memiliki perangkat keras yang mendukung seluruh kegiatan program akademik dan administratif di institusi • Memiliki perangkat keras yang menyediakan konektivitas (internal dan eksternal) bagi seluruh program studi dan unit-unit yang ada di institusi • Rasio terminal terhadap terhadap mahasiswa, > 1:20

• Memiliki perangkat keras yang mendukung sebagian besar kegiatan program akademik dan administratif di institusi • Memiliki perangkat keras yang menyediakan konektivitas (internal & eksternal) bagi sebagian besar program studi & unit yang ada di institusi • Rasio terminal terhadap terhadap mahasiswa, 1:20 sampai 1: 30 • Memiliki perangkat lunak yang mendukung sebagian besar kegiatan program akademik dan administratif di institusi • Memiliki Sumber Daya Manusia (Brainware) profesional yang cukup lengkap (System Analyst, dan Programmer) dalam bidang IT • Informasi yang tersedia dalam sistem informasi lengkap

7.3. Perangkat Lunak (Software)

• Memiliki perangkat lunak yang mendukung seluruh kegiatan program akademik dan administratif di institusi

7.4. Sumber Daya Manusia (Brainware) pendukung Sistem Informasi

• Memiliki Sumber Daya Manusia (Brainware) profesional yang lengkap (System Engineer, System Analyst, dan Programmer) dalam bidang IT • Informasi yang tersedia dalam sistem informasi sangat lengkap

7.5. Jenis Infomasi yang disediakan: Kemahasiswaan, SDM, Prasarana dan sarana, Program akademik, Organisasi, Keuangan

HARKAT DAN PERINGKAT MEMUASKAN 3 • Memiliki organisasi pengelola sistem informasi yg cukup lengkap • Memiliki tata cara pengumpulan, analisis dan penyajian informasi yang cukup akurat • Memiliki perangkat keras yang mendukung sebagian kegiatan program akademik dan administratif di institusi • Memiliki perangkat keras yang menyediakan konektivitas (internal dan eksternal) bagi sebagian program studi dan unitunit yang ada di institusi • Rasio terminal terhadap terhadap mahasiswa, 1:30 sampai 1: 40 • Memiliki perangkat lunak yang mendukung sebagian kegiatan program akademik dan administratif di institusi • Memiliki Sumber Daya Manusia (Brainware) profesional yang kurang lengkap (Programmer) dalam bidang IT • Informasi yang tersedia dalam sistem informasi cukup lengkap

KURANG 2 • Memiliki organisasi pengelola sistem informasi yg kurang lengkap • Memiliki tata cara pengumpulan, analisis & penyajian informasi yg kurang akurat • Memiliki perangkat keras yang mendukung sebagian kecil kegiatan program akademik dan administratif di institusi • Memiliki perangkat keras yang menyediakan konektivitas (internal &eksternal) bagi sebagian kecil program studi & unitunit yang ada di institusi • Rasio terminal terhadap terhadap mahasiswa, < 1: 40 • Memiliki perangkat lunak yang mendukung seabgian kecil sebagian program akademik dan administratif di institusi • Memiliki Sumber Daya Manusia (Brainware) yang bukan professional dalam bidang IT • Informasi yang tersedia dalam sistem informasi kurang lengkap

SANGAT KURANG 1 • Tidak memiliki organisasi pengelola sistem informasi • Memiliki tata cara pengumpulan, analisis dan penyajian informasi • Tidak memiliki perangkat keras yang mendukung sebagian kecil kegiatan program akademik dan administratif di institusi • Tidak memiliki perangkat keras yang menyediakan konektivitas (internal dan eksternal) • Tidak ada terminal untuk mahasiswa • • Tidak memiliki perangkat lunak yang mendukung seluruh kegiatan program akademik dan administratif di institusi • Tidak memiliki Sumber Daya Manusia (Brainware) dalam bidang Teknologi Informasi • Tidak ada sistem informasi

149

7.6. Kemudahan penggunaan fasilitas informasi Paramater: - Adanya aturan penggunaan fasilitas sistem informasi - Kemudahaan akses fasilitas - Akesibilitas fasilitas sistem informasi

7.7. Pelatihan

• Memiliki aturan tertulis yang sangat jelas dalam mengatur penggunaan fasilitas informasi (baik LAN maupun WAN). • Sivitas akademika dan masyarakat luas dapat mengakses informasi dengan sangat mudah dan bebas • Fasilitas sistem informasi internal dapat digunakan selama 24 jam sehari

• Memiliki aturan tertulis yang jelas dalam mengatur penggunaan fasilitas informasi (baik LAN maupun WAN). • Sivitas akademika dan masyarakat luas dapat mengakses informasi dengan mudah dan bebas • Fasilitas sistem informasi internal dapat digunakan selama 18 jam sehari

• Memiliki program pelatihan bagi pengguna yang diimplementasikan secara rutin berkesinambungan

• Memiliki program pelatihan bagi pengguna yang diimplementasikan secara periodik

• Memiliki aturan tertulis yang cukup jelas dalam mengatur penggunaan fasilitas informasi (baik LAN maupun WAN). • Sivitas akademika dan masyarakat luas dapat mengakses informasi dengan cukup mudah dan bebas • Fasilitas sistem informasi internal dapat digunakan selama 12 jam sehari • Memiliki program pelatihan bagi pengguna yang dilakukan secara insidental

• Memiliki aturan tertulis yang kurang jelas dalam mengatur penggunaan fasilitas informasi (baik LAN maupun WAN). • Sivitas akademika dan masyarakat luas sulit mengakses informasi • Fasilitas sistem informasi internal dapat digunakan selama 6 jam sehari • Memiliki program pelatihan bagi pengguna, namun tidak terimplementasikan

• Tidak memiliki aturan tertulis dalam mengatur penggunaan fasilitas informasi (baik LAN maupun WAN). • Sivitas akademika dan masyarakat luas tidak dapat mengakses informasi • Tidak tersedia fasilitas sistem informasi internal yang dapat digunakan • Tidak memiliki program pelatihan.

Sumber: BAN PT Depdiknas RI, 2003

4.1.2.3. Kebutuhan Sistem Informasi Akademik di Perguruan Tinggi Sebagaimana terjadi dalam SIPT, Sub Sistem Informasi Akademik (SIAKAD) sebagai bagian dari SIPT juga dapat berbeda di antara Perguruan Tinggi satu dengan yang lainnya. Kondisi seperti ini menunjukkan bahwa fungsi, tujuan, lingkup, definisi, serta implementasi SIAKAD pada masing-masing institusi Perguruan Tinggi tidaklah seragam. SIAKAD sebagai bagian dari SIPT dapat diintegrasikan dengan sub sistem lain dalam SIPT ataupun berupa sebuah aplikasi yang bersifat otonom. Sebagian besar SIAKAD menangani tugas-tugas yang terkait dengan proses perkuliahan saja. Sebagian yang lain, SIAKAD juga menangani tugas-tugas lainnya, misal Penmaru, heregisterasi, perkuliahan, evaluasi, hingga alumni.

4.1.2.3.1. Ruang Lingkup Sub Sistem Informasi Akademik (SIAKAD) Dalam penelitian ini, SIAKAD dimaksudkan sebagai sistem yang berfungsi menerima data masukan (input), mengolahnya, dan kemudian menyajikan informasi yang relevan dengan bidang tugas dan tanggung jawab pejabat pada Sub Bidang Akademik. Sedangkan berbagai kegiatan yang menyangkut keuangan, misal

150

pembayaran SPP, DPP, dan lainnya merupakan beban tugas dan tanggungjawab yang ditangani oleh Sub Sistem Informasi Keuangan (SIKEUANGAN). SIAKAD dapat memiliki sejumlah unit fungsional yang merupakan sub sistem dalam SIAKAD, dan SIAKAD sendiri merupakan sub sistem dari SIPT. Salah satu cara untuk menentukan lingkup SIAKAD pada institusi Perguruan Tinggi adalah didasarkan pada beban tugas dan tanggungjawab yang diemban oleh Pejabat Pimpinan pada Sub Bidang Akademik pada Perguruan Tinggi. Pada tingkat tertinggi, Pejabat Pimpinan pada Sub Bidang Akademik adalah Wakil/Pembantu Rektor (Warek/Purek/PR) Bidang Akademik pada Universitas atau Institut, Pembantu Ketua (Puket) Bidang Akademik pada Sekolah Tinggi. Pada beberapa Perguruan Tinggi, Warek/Purek/PR, atau Puket tersebut juga dibantu oleh pejabat pada tingkat yang lebih rendah, misal Pembantu Dekan (Pudek/PD) di tingkat Fakultas. Dan secara struktural, Sub Bidang Akademik juga dapat dibantu oleh beberapa Unit Kerja pendukung, misal Direktorat, Subdirektorat, Biro, Bagian, Biro Administrasi Akademik (BAA), Biro Kemahasiswaan dan Alumni, atau lainnya. Berdasarkan identifikasi beban tugas dan tanggungjawab Sub Bidang Akademik, selanjutnya dapat diidentifikasikan proses atau alur kegiatan dalam SIAKAD. Secara umum SIAKAD terdiri atas sejumlah sub sistem, yaitu: 1. Sub Sistem Informasi Penerimaan Mahasiswa Baru (SIPENMARU) 2. Sub Sistem Informasi Heregisterasi (SIHEREGISTERASI) 3. Sub Sistem Informasi Perwalian, Pra-KRS, KRS, Perubahan KRS (SIKRS) 4. Sub Sistem Informasi Perkuliahan (SIKULIAH)

151

5. Sub Sistem Informasi Praktikum (SIPRAKTIKUM) 6. Sub Sistem Informasi Kerja Praktek (SIKP) 7. Sub Sistem Informasi Tugas Akhir (SITA) 8. Sub Sistem Informasi KKN (SIKKN) 9. Sub Sistem Informasi Yudisium Kelulusan (SIYUDISIUM) 10. Sub Sistem Informasi Wisuda (SIWISUDA) 11. Sub Sistem Informasi Alumni (SIALUMNI) Gambar 4.2 menunjukkan proses atau alur kegiatan dalam SIAKAD. 1. Penmaru (SIPENMARU) ⇓ 2. Herregisterasi (SIHEREGISTERASI) ⇓ 3. Perwalian, Pra-KRS, perubahan KRS (SIKRS) 4. Perkuliahan (SIKULIAH) 5. Praktikum (SIPRAKTIKUM) 6. KP (SIKP) 7. KKN (SIKKN) 8. Tugas Akhir (SITA) ⇓ 9. Yudisium (SIYUDISIUM) ⇓ 10. Wisuda (SIWISUDA) ⇓ 11. Alumni (SIALUMNI) Gambar 4.2: Alur kegiatan Sub Bidang Akademik di Perguruan Tinggi

152

4.1.2.3.2. Pengguna Sistem Informasi Akademik (SIAKAD) Sebagaimana SIPT, orang-orang yang menggunakan SIAKAD dapat perseorangan atau sekelompok orang di dalam maupun di luar struktur organisasi Perguruan Tinggi. Dalam SIAKAD, personil-personil pengguna di dalam struktur organisasi Perguruan Tinggi dapat dikelompokkan menjadi 3 (tiga), yaitu: 1. Para pengguna pada tingkat manajemen tertinggi (perencanaan strategis), misal Rektor pada Universitas atau Institut, Ketua pada Sekolah Tinggi, Direktur pada Akademi, para Pembantu Rektor (Warek/Purek/PR) pada Universitas atau Institut, para Pembantu Ketua pada Sekolah Tinggi, para Pembantu Direktur pada Akademi, para Pejabat di tingkat Yayasan pada Perguruan Tinggi Swasta, dan Pejabat lain yang setingkat 2. Para pengguna pada tingkat manajemen menengah (perencanaan taktis dan pengendalian manajemen), misal para Dekan, para Pembantu Dekan (Pudek/PD), dan Pejabat lain yang setingkat 3. Para pengguna pada tingkat manajemen terendah (perencanaan dan pengendalian operasional), misal para Ketua Jurusan, para Sekretaris Jurusan, para Ketua Program Studi, para staf administrasi, dan Pejabat lain yang setingkat Sedangkan personil atau institusi pengguna yang berada di luar struktur organisasi Perguruan Tinggi dapat terdiri atas: 1. Dosen 2. Mahasiswa 3. Alumni

153

4. Masyarakat pengguna lulusan 5. Pemerintah (DIKTI/DIKNAS/BAN-PT) 6. Penyandang dana (Yayasan pada Perguruan Tinggi Saswa) 7. Orang tua/wali mahasiswa 8. Masyarakat umum Selanjutnya, berdasarkan konsep database, maka pengguna SIPT juga dapat berupa program-program aplikasi yang mengakses data-data dari dalam database. Program-program aplikasi ini juga dapat mengakses data-data dalam database pada saat bersamaan ataupun berselang waktu. Program-program aplikasi dapat mengakses data-data dalam database untuk kemudian menampilkan, ataupun memanipulasi (insert, delete, update) data-data dari dalam database.

4.1.3. Kebutuhan Informasi (dan Data) dan Nilai Rinci Data Untuk SIAKAD Berdasarkan hasil identifikasi sub sistem informasi dalam SIAKAD pada bagian sebelumnya, maka secara garis besar kebutuhan informasi (dan data) dan nilai rinci data untuk SIAKAD meliputi: 1. Informasi (dan data) dan nilai rinci data secara terinci, baik insidentil maupun rutin, dalam bentuk teks, tabel maupun grafis, yang terkait dan sub sistem berikut: a. Sub Sistem Informasi Penerimaan Mahasiswa Baru (SIPENMARU) b. Sub Sistem Informasi Heregisterasi (SIHEREGISTERASI) c. Sub Sistem Informasi Perwalian, Pra-KRS, KRS, Perubahan KRS (SIKRS) d. Sub Sistem Informasi Perkuliahan (SIKULIAH)

154

e. Sub Sistem Informasi Praktikum (SIPRAKTIKUM) f. Sub Sistem Informasi Kerja Praktek (SIKP) g. Sub Sistem Informasi Tugas Akhir (SITA) h. Sub Sistem Informasi KKN (SIKKN) i. Sub Sistem Informasi Yudisium Kelulusan (SIYUDISIUM) j.

Sub Sistem Informasi Wisuda (SIWISUDA)

k. Sub Sistem Informasi Alumni (SIALUMNI) 2. Informasi (dan data) dan nilai rinci data secara teringkas, baik insidentil maupun rutin, dalam bentuk teks, tabel dan grafis, yang terkait dengan sub sistem berikut: a. Sub Sistem Informasi Penerimaan Mahasiswa Baru (SIPENMARU) b. Sub Sistem Informasi Heregisterasi (SIHEREGISTERASI) c. Sub Sistem Informasi Perwalian, Pra-KRS, KRS, Perubahan KRS (SIKRS) d. Sub Sistem Informasi Perkuliahan (SIKULIAH) e. Sub Sistem Informasi Praktikum (SIPRAKTIKUM) f. Sub Sistem Informasi Kerja Praktek (SIKP) g. Sub Sistem Informasi Tugas Akhir (SITA) h. Sub Sistem Informasi KKN (SIKKN) i. Sub Sistem Informasi Yudisium Kelulusan (SIYUDISIUM) j.

Sub Sistem Informasi Wisuda (SIWISUDA)

k. Sub Sistem Informasi Alumni (SIALUMNI) 3. Informasi (dan data) dan nilai rinci data secara spesifik, baik insidentil maupun rutin, dalam bentuk teks, tabel dan grafis, yang terkait dengan sub sistem berikut:

155

a. Sub Sistem Informasi Penerimaan Mahasiswa Baru (SIPENMARU) b. Sub Sistem Informasi Heregisterasi (SIHEREGISTERASI) c. Sub Sistem Informasi Perwalian, Pra-KRS, KRS, Perubahan KRS (SIKRS) d. Sub Sistem Informasi Perkuliahan (SIKULIAH) e. Sub Sistem Informasi Praktikum (SIPRAKTIKUM) f. Sub Sistem Informasi Kerja Praktek (SIKP) g. Sub Sistem Informasi Tugas Akhir (SITA) h. Sub Sistem Informasi KKN (SIKKN) i. Sub Sistem Informasi Yudisium Kelulusan (SIYUDISIUM) j.

Sub Sistem Informasi Wisuda (SIWISUDA)

k. Sub Sistem Informasi Alumni (SIALUMNI)

4.1.3.1. Kebutuhan Informasi (dan Data) Untuk Setiap Sub Sistem SIAKAD Kebutuhan informasi (dan data) untuk SIAKAD meliputi informasi (dan data) terinci dan informasi (dan data) teringkas. Kebutuhan informasi (dan data) teringkas pada dasarnya merupakan hasil proses pengolahan dari data terinci. Dengan demikian, maka kebutuhan informasi (dan data) secara terinci dan informasi (dan data) secara teringkas diperoleh dari sumber database yang sama. Perbedaan di antara keduanya hanyalah terletak pada proses pengolahan dan penyajian informasi. Berdasarkan hasil identifikasi kebutuhan informasi (dan data) untuk setiap Sub Sistem Informasi dalam SIAKAD, maka selanjutnya dapat diidentifikasikan kebutuhan rinci data untuk setiap Sub Sistem Informasi dalam SIAKAD. Identifikasi

156

kebutuhan informasi (dan data) dilakukan dengan asumsi bahwa SIAKAD adalah sub sistem dari SIPT yang merupakan sistem informasi berbasis komputer (Computer Based Information Systems/CBIS).

4.1.3.1.1. Sub Sistem Informasi Penmaru (SIPENMARU) Sub Sistem Informasi Penerimaan Mahasiswa Baru (SIPENMARU) ini dimaksudkan untuk menangani kegiatan Penerimaan Mahasiswa Baru. Kebutuhan informasi (dan data) dan nilai rinci data untuk SIPENMARU dapat diidentifikasikan berdasarkan kebutuhan informasi (dan data) dan nilai rinci data untuk keperluan penyusunan Portofolio, peningkatan mutu, evaluasi diri, borang, perencanaan strategis, perencanaan taktis dan pengendalian manajemen, serta perencanaan dan pengendalian operasional. Hasil identifikasi kebutuhan informasi (dan data) untuk SIPENMARU adalah sebagai berikut: 1. Daftar pembeli formulir pendaftaran keseluruhan 2. Daftar pembeli formulir pendaftaran berdasarkan tanggal 3. Daftar pembeli formulir yang tidak mendaftar keseluruhan 4. Daftar pembeli formulir yang tidak mendaftar berdasarkan Program Studi 5. Daftar pembeli formulir yang tidak mendaftar berdasarkan jalur pendaftaran 6. Daftar pembeli formulir yang tidak mendaftar berdasarkan tanggal pendaftaran 7. Daftar pembeli formulir yang tidak mendaftar berdasarkan gelombang pendaftaran 8. Daftar rincian nilai ujian pendaftar keseluruhan

157

9. Daftar nilai ujian pendaftar berdasarkan mata ujian 10. Rekapitulasi pembeli formulir berdasarkan Program Studi 11. Rekapitulasi pembeli formulir berdasarkan jalur pendaftaran 12. Rekapitulasi pembeli formulir berdasarkan gelombang pendaftaran 13. Rekapitulasi jumlah pembeli formulir berdasarkan asal Propinsi 14. Rekapitulasi jumlah pembeli formulir berdasarkan asal Kabupaten/Kodya 15. Rekapitulasi jumlah pembeli formulir berdasarkan jalur pendaftaran 16. Rekapitulasi jumlah pembeli formulir berdasarkan jenis kelamin 17. Rekapitulasi jumlah pembeli formulir berdasarkan usia 18. Rekapitulasi jumlah pembeli formulir berdasarkan NEM 19. Rekapitulasi jumlah pembeli formulir berdasarkan pekerjaan orang tua 20. Rekapitulasi jumlah pembeli formulir berdasarkan penghasilan orang tua 21. Daftar pendaftar keseluruhan 22. Daftar pendaftar berdasarkan Program Studi 23. Daftar pendaftar berdasarkan jalur pendaftaran 24. Daftar pendaftar berdasarkan tanggal pendaftaran 25. Daftar pendaftar berdasarkan gelombang pendaftaran 26. Rekapitulasi pendaftar berdasarkan Program Studi 27. Rekapitulasi pendaftar berdasarkan jalur pendaftaran 28. Rekapitulasi pendaftar berdasarkan gelombang pendaftaran 29. Rekapitulasi jumlah pendaftar berdasarkan asal Propinsi 30. Rekapitulasi jumlah pendaftar berdasarkan asal Kabupaten/Kodya

158

31. Rekapitulasi jumlah pendaftar berdasarkan jalur pendaftaran 32. Rekapitulasi jumlah pendaftar berdasarkan jenis kelamin 33. Rekapitulasi jumlah pendaftar berdasarkan usia 34. Rekapitulasi jumlah pendaftar berdasarkan NEM 35. Rekapitulasi jumlah pendaftar berdasarkan nilai ujian Bahasa Inggris 36. Rekapitulasi jumlah pendaftar berdasarkan rata-rata nilai ujian 37. Rekapitulasi jumlah pendaftar berdasarkan pekerjaan orang tua 38. Rekapitulasi jumlah pendaftar berdasarkan penghasilan orang tua 39. Daftar pendaftar yang tidak hadir ujian masuk keseluruhan 40. Daftar pendaftar yang tidak hadir ujian masuk berdasarkan Program Studi 41. Daftar pendaftar yang tidak hadir ujian masuk berdasarkan gelombang pendaftaran 42. Daftar pendaftar diterima keseluruhan 43. Daftar pendaftar diterima berdasarkan Program Studi 44. Daftar pendaftar diterima berdasarkan jalur pendaftaran 45. Daftar pendaftar diterima berdasarkan gelombang pendaftaran 46. Rekapitulasi jumlah pendaftar diterima berdasarkan Program Studi 47. Rekapitulasi jumlah pendaftar diterima berdasarkan jalur pendaftaran 48. Rekapitulasi jumlah pendaftar diterima berdasarkan gelombang pendaftaran 49. Rekapitulasi jumlah pendaftar diterima berdasarkan asal Propinsi 50. Rekapitulasi jumlah pendaftar diterima berdasarkan asal Kabupaten/Kodya 51. Rekapitulasi jumlah pendaftar diterima berdasarkan jalur pendaftaran

159

52. Rekapitulasi jumlah pendaftar diterima berdasarkan jenis kelamin 53. Rekapitulasi jumlah pendaftar diterima berdasarkan usia 54. Rekapitulasi jumlah pendaftar diterima berdasarkan NEM 55. Rekapitulasi jumlah pendaftar diterima berdasarkan nilai ujian Bahasa Inggris 56. Rekapitulasi jumlah pendaftar diterima berdasarkan rata-rata nilai ujian 57. Rekapitulasi jumlah pendaftar diterima berdasarkan pekerjaan orang tua 58. Rekapitulasi jumlah pendaftar diterima berdasarkan penghasilan orang tua 59. Daftar pendaftar diterima yang tidak heregisterasi keseluruhan 60. Daftar pendaftar diterima yang tidak heregisterasi berdasarkan Program Studi 61. Daftar pendaftar diterima yang tidak heregisterasi berdasarkan gelombang pendaftaran 62. Daftar mahasiswa baru keseluruhan 63. Daftar mahasiswa baru berdasarkan Program Studi 64. Daftar mahasiswa baru berdasarkan jalur pendaftaran 65. Daftar mahasiswa baru berdasarkan gelombang pendaftaran 66. Rekapitulasi mahasiswa baru berdasarkan Program Studi 67. Rekapitulasi mahasiswa baru berdasarkan jalur pendaftaran 68. Rekapitulasi mahasiswa baru berdasarkan gelombang pendaftaran 69. Rekapitulasi mahasiswa baru berdasarkan asal Propinsi 70. Rekapitulasi mahasiswa baru berdasarkan asal Kabupaten/Kodya 71. Rekapitulasi mahasiswa baru berdasarkan jalur pendaftaran 72. Rekapitulasi mahasiswa baru berdasarkan jenis kelamin

160

73. Rekapitulasi mahasiswa baru berdasarkan usia 74. Rekapitulasi mahasiswa baru berdasarkan NEM 75. Rekapitulasi mahasiswa baru berdasarkan nilai ujian Bahasa Inggris 76. Rekapitulasi mahasiswa baru berdasarkan rata-rata nilai ujian 77. Rekapitulasi mahasiswa baru berdasarkan pekerjaan orang tua 78. Rekapitulasi mahasiswa baru berdasarkan penghasilan orang tua 79. Tingkat keketatan persaingan pendaftaran 80. Tingkat keberhasilan Penmaru

4.1.3.1.2. Sub Sistem Informasi Heregisterasi (SIHEREGISTERASI) Sub Sistem Informasi Heregisterasi (SIHEREGISTERASI) ini dimaksudkan untuk menangani kegiatan heregisterasi khusus untuk mahasiswa lama (selain mahasiswa baru). Kebutuhan informasi (dan data) dan nilai rinci data untuk SIHEREGISTERASI dapat diidentifikasikan berdasarkan kebutuhan informasi (dan data) dan nilai rinci data untuk keperluan penyusunan Portofolio, peningkatan mutu, evaluasi diri, borang, perencanaan strategis, perencanaan taktis dan pengendalian manajemen, serta perencanaan dan pengendalian operasional. Hasil identifikasi kebutuhan informasi (dan data) untuk SIHEREGISTERASI adalah sebagai berikut: 1. Daftar mahasiswa heregisterasi keseluruhan 2. Daftar mahasiswa heregisterasi berdasarkan Program Studi 3. Daftar mahasiswa heregisterasi berdasarkan tahun angkatan 4. Daftar mahasiswa heregisterasi berdasarkan tanggal

161

5. Daftar mahasiswa tidak heregisterasi keseluruhan 6. Daftar mahasiswa tidak heregisterasi berdasarkan Program Studi 7. Daftar mahasiswa tidak heregisterasi berdasarkan tahun angkatan 8. Daftar mahasiswa cuti keseluruhan 9. Daftar mahasiswa cuti berdasarkan Program Studi 10. Daftar mahasiswa cuti berdasarkan tahun angkatan 11. Rekapitulasi mahasiswa heregisterasi berdasarkan Program Studi 12. Rekapitulasi mahasiswa heregisterasi berdasarkan tahun angkatan 13. Rekapitulasi mahasiswa heregisterasi berdasarkan jenis kelamin 14. Tingkat keberhasilan mahasiswa heregisterasi

4.1.3.1.3. Sub Sistem Informasi KRS (SIKRS) Sub Sistem Informasi KRS (SIKRS) ini dimaksudkan untuk menangani kegiatan Perwalian, Pra-KRS, KRS, dan perubahan KRS untuk seluruh mahasiwa. Kebutuhan informasi (dan data) dan nilai rinci data untuk SIKRS dapat diidentifikasikan berdasarkan kebutuhan informasi (dan data) dan nilai rinci data untuk keperluan penyusunan perencanaan taktis dan pengendalian manajemen, serta perencanaan dan pengendalian operasional. Hasil identifikasi kebutuhan informasi (dan data) untuk SIKRS adalah sebagai berikut: 1. Daftar Dosen Wali keseluruhan 2. Jadwal bimbingan Dosen Wali keseluruhan 3. Rekapitulasi pembimbingan oleh Dosen Wali berdasarkan Program Studi

162

4. Rekapitulasi beban bimbingan Dosen Wali berdasarkan Program Studi 5. Kalender Akademik 6. Daftar mata kuliah dan prasyarat keseluruhan 7. Daftar mata kuliah berdasarkan kelompok mata kuliah wajib 8. Daftar mata kuliah berdasarkan kelompok mata kuliah peminatan 9. Daftar mata kuliah berdasarkan kelompok mata kuliah pilihan 10. Daftar ruangan dan kapasitas ruangan kuliah dan laboratorium keseluruhan 11. Daftar penawaran mata kuliah dan praktikum 12. Jadwal kuliah dan praktikum keseluruhan 13. Jadwal kuliah dan praktikum berdasarkan Program Studi 14. Jadwal kuliah berdasarkan dosen pengampu mata kuliah 15. Jadwal praktikum berdasarkan laboratorium 16. Daftar mahasiswa tidak ikut Pra-KRS keseluruhan 17. Daftar mahasiswa tidak ikut Pra-KRS berdasarkan Program Studi 18. Daftar mahasiswa tidak ikut Pra-KRS berdasarkan Dosen Wali 19. Daftar mahasiswa peserta kuliah berdasarkan kelas mata kuliah 20. Daftar mahasiswa heregisterasi habis teori berdasarkan Program Studi 21. Daftar mahasiswa heregisterasi habis teori berdasarkan tahun angkatan 22. Daftar mahasiswa peserta KP berdasarkan Program Studi 23. Daftar mahasiswa peserta KP berdasarkan tahun angkatan 24. Daftar mahasiswa peserta KKN berdasarkan Program Studi 25. Daftar mahasiswa peserta KKN berdasarkan tahun angkatan

163

26. Daftar mahasiswa peserta TA berdasarkan Program Studi 27. Daftar mahasiswa peserta TA berdasarkan tahun angkatan 28. Jadwal kuliah berdasarkan ruangan kuliah 29. Daftar beban SKS dosen dan asisten dosen keseluruhan 30. Daftar beban SKS dosen dan asisten dosen berdasarkan Program Studi 31. Rekapitulasi beban SKS dosen dan asisten dosen keseluruhan 32. Rekapitulasi beban SKS dosen dan asisten dosen berdasarkan Program Studi 33. Rekapitulasi tingkat keberhasilan PRA-KRS keseluruhan 34. Rekapitulasi tingkat keberhasilan PRA-KRS berdasarkan Program Studi 35. Rekapitulasi tingkat keberhasilan KRS keseluruhan 36. Rekapitulasi tingkat keberhasilan KRS berdasarkan Program Studi

4.1.3.1.4. Sub Sistem Informasi Perkuliahan (SIKULIAH) Sub Sistem Informasi Perkuliahan (SIKULIAH) ini dimaksudkan untuk menangani kegiatan perkuliahan teori untuk seluruh mahasiswa. Kebutuhan informasi (dan data) dan nilai rinci data untuk SIKULIAH dapat diidentifikasikan berdasarkan kebutuhan informasi (dan data) untuk keperluan penyusunan Portofolio, peningkatan mutu, evaluasi diri, borang, perencanaan strategis, perencanaan taktis dan pengendalian manajemen, serta perencanaan dan pengendalian operasional. Hasil identifikasi kebutuhan informasi (dan data) untuk SIKULIAH adalah sebagai berikut: 1. Daftar dosen keseluruhan 2. Daftar dosen tetap

164

3. Daftar dosen tidak tetap 4. Daftar kehadiran mengajar dosen sebelum UTS keseluruhan 5. Daftar kehadiran mengajar dosen sebelum UTS berdasarkan Program Studi 6. Daftar dosen hadir mengajar <5 kali sebelum UTS keseluruhan 7. Daftar dosen hadir mengajar <5 kali sebelum UTS berdasarkan Program Studi 8. Jadwal UTS berdasarkan Program Studi 9. Daftar Hadir mahasiswa peserta UTS berdasarkan mata kuliah 10. Daftar nilai UTS berdasarkan mata kuliah 11. Daftar kehadiran mengajar dosen sebelum UAS keseluruhan 12. Daftar kehadiran mengajar dosen sebelum UAS berdasarkan Program Studi 13. Daftar dosen hadir mengajar <10 kali sebelum UAS keseluruhan 14. Daftar dosen hadir mengajar <10 kali sebelum UAS berdasarkan Program Studi 15. Daftar jumlah kehadiran kuliah mahasiswa berdasarkan mata kuliah 16. Daftar mahasiswa hadir kuliah <75% sebelum UAS berdasarkan mata kuliah 17. Jadwal UAS berdasarkan Program Studi 18. Daftar Hadir mahasiswa peserta UAS berdasarkan mata kuliah 19. Daftar rincian nilai akhir kuliah berdasarkan mata kuliah 20. Daftar rincian evaluasi prestasi akhir dosen mengajar keseluruhan 21. Daftar rincian evaluasi prestasi akhir dosen mengajar berdasarkan Program Studi 22. Daftar IPK dan batas SKS mahasiswa bimbingan berdasarkan Dosen Wali 23. Daftar mahasiswa tidak memenuhi syarat IPK 2,0 pada 2 semester awal keseluruhan

165

24. Daftar mahasiswa tidak memenuhi syarat IPK 2,0 pada 2 semester awal berdasarkan Program Studi 25. Daftar mahasiswa tidak memenuhi syarat IPK 2,0 pada 2 semester awal berdasarkan tahun angkatan 26. Daftar mahasiswa tidak memenuhi syarat IPK 2,0 pada 4 semester awal keseluruhan 27. Daftar mahasiswa tidak memenuhi syarat IPK 2,0 pada 4 semester awal berdasarkan Program Studi 28. Daftar mahasiswa tidak memenuhi syarat IPK 2,0 pada 4 semester awal berdasarkan tahun angkatan 29. Daftar mahasiswa tidak memenuhi syarat IPK 2,0 pada 8 semester awal keseluruhan 30. Daftar mahasiswa tidak memenuhi syarat IPK 2,0 pada 8 semester awal berdasarkan Program Studi 31. Daftar mahasiswa tidak memenuhi syarat IPK 2,0 pada 8 semester awal berdasarkan tahun angkatan 32. Daftar prediksi peserta kuliah berdasarkan mata kuliah 33. Daftar prediksi peserta praktikum berdasarkan mata praktikum 34. Daftar prediksi peserta kuliah berdasarkan Program Studi 35. Daftar prediksi peserta praktikum berdasarkan Program Studi 36. Daftar nama Pengawas keseluruhan 37. Daftar materi kuliah dosen berdasarkan mata kuliah

166

38. Rekapitulasi kehadiran Pengawas UTS 39. Rekapitulasi kehadiran Pengawas UAS 40. Rekapitulasi kehadiran dosen sebelum UTS 41. Rekapitulasi kehadiran dosen sebelum UAS 42. Rekapitulasi kehadiran dosen pada akhir kuliah keseluruhan 43. Rekapitulasi kehadiran dosen pada akhir kuliah berdasarkan Program Studi 44. Rekapitulasi nilai UTS 45. Rekapitulasi Nilai Akhir mata kuliah 46. Rekapitulasi evaluasi prestasi akhir dosen mengajar keseluruhan 47. Rekapitulasi evaluasi prestasi akhir dosen mengajar berdasarkan Program Studi 48. Rekapitulasi penggunaan ruangan kuliah

4.1.3.1.5. Sub Sistem Informasi Praktikum (SIPRAKTIKUM) Sub Sistem Informasi Praktikum (SIPRAKTIKUM) ini dimaksudkan untuk menangani kegiatan praktikum untuk seluruh mahasiswa. Kebutuhan informasi (dan data) dan nilai rinci data untuk SIPRAKTIKUM dapat diidentifikasikan berdasarkan kebutuhan informasi (dan data) dan nilai rinci data untuk keperluan penyusunan Portofolio, peningkatan mutu, evaluasi diri, borang, perencanaan strategis, perencanaan taktis dan pengendalian manajemen, serta perencanaan dan pengendalian operasional. Hasil identifikasi kebutuhan informasi (dan data) untuk SIPRAKTIKUM adalah sebagai berikut: 1. Kurikulum dan silabus praktikum

167

2. Ketersediaan dan isi Modul Pratikum 3. Daftar Asisten praktikum keseluruhan 4. Jadwal praktikum berdasarkan laboratorium 5. Jadwal praktikum berdasarkan Program Studi 6. Daftar Hadir Pre-Test mahasiswa peserta praktikum berdasarkan mata praktikum 7. Daftar Hadir mahasiswa peserta praktikum berdasarkan mata praktikum 8. Daftar jumlah kehadiran praktikum mahasiswa berdasarkan mata praktikum 9. Daftar mahasiswa hadir praktikum <75% sebelum responsi berdasarkan mata praktikum 10. Jadwal responsi praktikum berdasarkan mata praktikum 11. Daftar Hadir mahasiswa peserta responsi berdasarkan mata praktikum 12. Daftar rincian nilai akhir praktikum berdasarkan mata praktikum 13. Daftar kehadiran asisten praktikum keseluruhan 14. Daftar kehadiran asisten praktikum berdasarkan mata praktikum 15. Daftar materi praktikum berdasarkan mata praktikum 16. Rekapitulasi kehadiran asisten praktikum berdasarkan laboratorium 17. Rekapitulasi Nilai Akhir praktikum 18. Rekapitulasi penggunaan laboratorium

4.1.3.1.6. Sub Sistem Informasi Kerja Praktek (SIKP) Sub Sistem Informasi Kerja Praktek (SIKP) ini dimaksudkan untuk menangani kegiatan Kerja Praktek untuk seluruh mahasiswa. Kebutuhan informasi

168

(dan data) dan nilai rinci data untuk SIKP dapat diidentifikasikan berdasarkan kebutuhan informasi (dan data) dan nilai rinci data untuk keperluan penyusunan perencanaan taktis dan pengendalian manajemen, serta perencanaan dan pengendalian operasional. Hasil identifikasi kebutuhan informasi (dan data) untuk SIKP adalah sebagai berikut: 1. Daftar Pembimbing KP keseluruhan 2. Daftar Pembimbing KP berdasarkan Program Studi 3. Daftar rincian KP berdasarkan Dosen Pembimbing KP 4. Daftar rincian KP berdasarkan Program Studi 5. Daftar KP berdasarkan lokasi obyek penelitian 6. Daftar KP berdasarkan topik-tema KP dan Program Studi 7. Daftar KP berdasarkan jenis penelitian KP dan Program Studi 8. Daftar KP lamanya waktu penyelesaian KP 9. Daftar KP yang waktu penyelesaiannya melewati >1 tahun 10. Rekapitulasi jumlah bimbingan KP berdasarkan Dosen Pembimbing KP 11. Rekapitulasi KP berdasarkan lokasi obyek penelitian 12. Rekapitulasi KP berdasarkan topik-tema KP 13. Rekapitulasi Nilai Akhir KP

4.1.3.1.7. Sub Sistem Informasi Kuliah Kerja Nyata (SIKKN) Sub Sistem Informasi Kuliah Kerja Nyata (SIKKN) ini dimaksudkan untuk menangani kegiatan Kuliah Kerja Nyata untuk seluruh mahasiswa (S-1). Kebutuhan

169

informasi (dan data) dan nilai rinci data untuk SIKKN dapat diidentifikasikan berdasarkan kebutuhan informasi (dan data) dan nilai rinci data untuk keperluan penyusunan perencanaan taktis dan pengendalian manajemen, serta perencanaan dan pengendalian operasional. Hasil identifikasi kebutuhan informasi (dan data) untuk SIKKN adalah sebagai berikut: 1. Daftar Dosen Pembimbing KKN keseluruhan 2. Daftar Dosen Pembimbing KKN berdasarkan Program Studi 3. Daftar mahasiswa peserta KKN berdasarkan Program Studi 4. Daftar mahasiswa peserta KKN berdasarkan kelompok KKN 5. Daftar mahasiswa peserta KKN berdasarkan tahun angkatan 6. Daftar rincian nilai KKN keseluruhan 7. Daftar rincian nilai KKN berdasarkan Program Studi 8. Daftar rincian nilai KKN berdasarkan kelompok KKN 9. Rekapitulasi jumlah peserta KKN berdasarkan Program Studi 10. Rekapitulasi jumlah peserta KKN berdasarkan kelompok KKN 11. Rekapitulasi jumlah peserta KKN berdasarkan tahun angkatan 12. Rekapitulasi Nilai Akhir KKN

4.1.3.1.8. Sub Sistem Informasi Tugas Akhir (SITA) Sub Sistem Informasi Tugas Akhir (SITA) ini dimaksudkan untuk menangani kegiatan Tugas Akhir/Skripsi untuk mahasiswa (S-1). Kebutuhan informasi (dan data) dan nilai rinci data untuk SITA dapat diidentifikasikan berdasarkan kebutuhan

170

informasi (dan data) dan nilai rinci data untuk keperluan penyusunan Portofolio, peningkatan mutu, evaluasi diri, borang, perencanaan strategis, perencanaan taktis dan pengendalian manajemen, serta perencanaan dan pengendalian operasional. Hasil identifikasi kebutuhan informasi (dan data) untuk SITA adalah sebagai berikut: 1. Daftar Pembimbing TA keseluruhan 2. Daftar Pembimbing TA berdasarkan Program Studi 3. Daftar rincian TA berdasarkan Dosen Pembimbing TA 4. Daftar rincian TA berdasarkan Program Studi 5. Daftar TA berdasarkan lokasi obyek penelitian 6. Daftar TA berdasarkan topik-tema TA dan Program Studi 7. Daftar TA berdasarkan lamanya waktu penyelesaian TA 8. Daftar TA yang waktu penyelesaiannya >1 tahun 9. Rekapitulasi jumlah bimbingan TA berdasarkan Dosen Pembimbing TA 10. Rekapitulasi TA berdasarkan lokasi obyek penelitian 11. Rekapitulasi TA berdasarkan topik-tema TA 12. Rekapitulasi Nilai Akhir TA

4.1.3.1.9. Sub Sistem Informasi Yudisium Kelulusan (SIYUDISIUM) Sub Sistem Informasi Yudisium (SIYUDISIUM) ini dimaksudkan untuk menangani kegiatan Yudisium kelulusan mahasiswa (S-1). Kebutuhan informasi (dan data) dan nilai rinci data untuk SIYUDISIUM dapat diidentifikasikan berdasarkan kebutuhan informasi (dan data) dan nilai rinci data untuk keperluan penyusunan

171

perencanaan taktis dan pengendalian manajemen, serta perencanaan dan pengendalian operasional. Hasil identifikasi kebutuhan informasi (dan data) untuk SIYUDISIUM adalah sebagai berikut: 1. Daftar mahasiswa peserta yudisium keseluruhan 2. Daftar mahasiswa peserta yudisium berdasarkan Program Studi 3. Daftar mahasiswa peserta yudisium berdasarkan tahun angkatan 4. Rekapitulasi mahasiswa peserta yudisium berdasarkan Program Studi 5. Rekapitulasi mahasiswa peserta yudisium berdasarkan tahun angkatan 6. Rekapitulasi mahasiswa peserta yudisium berdasarkan lama masa Studi 7. Rekapitulasi mahasiswa peserta yudisium berdasarkan kelompok IPK

4.1.3.1.10. Sub Sistem Informasi Wisuda (SIWISUDA) Sub Sistem Informasi Wisuda (SIWISUDA) ini dimaksudkan untuk menangani kegiatan wisuda mahasiswa (S-1) yang dinyatakan lulus dalam yudisium. Kebutuhan informasi (dan data) dan nilai rinci data untuk SIWISUDA dapat diidentifikasikan berdasarkan kebutuhan informasi (dan data) dan nilai rinci data untuk keperluan penyusunan perencanaan taktis dan pengendalian manajemen, serta perencanaan dan pengendalian operasional. Hasil identifikasi kebutuhan informasi (dan data) untuk SIWISUDA adalah sebagai berikut: 1. Daftar mahasiswa peserta wisuda keseluruhan 2. Daftar mahasiswa peserta wisuda berdasarkan Program Studi 3. Daftar mahasiswa peserta wisuda berdasarkan tahun angkatan

172

4. Daftar mahasiswa peserta wisuda berdasarkan periode yudisium 5. Rekapitulasi mahasiswa peserta wisuda berdasarkan Program Studi 6. Rekapitulasi mahasiswa peserta wisuda berdasarkan tahun angkatan 7. Rekapitulasi mahasiswa peserta wisuda berdasarkan lama masa Studi 8. Rekapitulasi mahasiswa peserta wisuda berdasarkan kelompok IPK

4.1.3.1.11. Sub Sistem Informasi Alumni (SIALUMNI) Sub Sistem Informasi Alumni (SIALUMNI) ini dimaksudkan untuk menangani pendataan alumni. Kebutuhan informasi (dan data) dan nilai rinci data untuk SIALUMNI dapat diidentifikasikan berdasarkan kebutuhan informasi (dan data) dan nilai rinci data untuk keperluan penyusunan perencanaan taktis dan pengendalian manajemen, serta perencanaan dan pengendalian operasional. Hasil identifikasi kebutuhan informasi (dan data) untuk SIALUMNI adalah sebagai berikut: 1. Daftar alumni keseluruhan 2. Daftar alumni berdasarkan Program Studi 3. Daftar alumni berdasarkan tahun angkatan 4. Daftar alumni berdasarkan periode yudisium 5. Daftar alumni berdasarkan periode wisuda 6. Daftar alumni berdasarkan propinsi 7. Daftar alumni berdasarkan lama waktu tunggu pekerjaan pertama 8. Daftar alumni berdasarkan tingkatan jabatan pekerjaan 9. Daftar alumni berdasarkan kelompok jumlah penghasilan

173

10. Daftar alumni berdasarkan kelompok bidang pekerjaan 11. Rekapitulasi alumni berdasarkan Program Studi 12. Rekapitulasi alumni berdasarkan tahun angkatan 13. Rekapitulasi alumni berdasarkan periode yudisium 14. Rekapitulasi alumni berdasarkan periode wisuda 15. Rekapitulasi alumni berdasarkan propinsi 16. Rekapitulasi alumni berdasarkan lama waktu tunggu pekerjaan pertama 17. Rekapitulasi alumni berdasarkan tingkatan jabatan pekerjaan 18. Rekapitulasi alumni berdasarkan kelompok jumlah penghasilan 19. Rekapitulasi alumni berdasarkan kelompok bidang pekerjaan

4.1.3.2. Kebutuhan Nilai Rinci Data untuk Setiap Sub Sistem dalam SIAKAD Berdasarkan hasil identifikasi kebutuhan informasi (dan data) untuk setiap Sub Sistem Informasi dalam SIAKAD, maka selanjutnya dapat diidentifikasikan kebutuhan nilai rinci data untuk setiap Sub Sistem dalam SIAKAD. Identifikasi kebutuhan informasi (dan data) dilakukan dengan asumsi bahwa SIAKAD adalah sub sistem dari SIPT yang merupakan sistem informasi berbasis komputer (Computer Based Information Systems/CBIS) yang terintegrasi. Hasil identifikasi kebutuhan nilai-nilai rinci data untuk memenuhi seluruh kebutuhan informasi (dan data) seluruh sub sistem infomasi dalam SIAKAD ditunjukkan pada Tabel 4.5.

174

Tabel 4.5: Kebutuhan rinci data untuk SIAKAD No 1

Kebutuhan Informasi dan (data) Bank_Soal_Penmaru_Check_Point

2 3 4

Bank_Soal_Penmaru_Essay Mata_UJian Jalur_Penmaru

5

Program_Studi

6

Jurusan

7

Fakultas

8 9 10 11 12 13 14 15 16 17 18 19

Program Jenjang_Pendidikan Jenis_Pendidikan Agama Kecamatan Kabupaten Propinsi Kode_Pos Status_Program_Studi SPP DPP Angsuran_SPP

20

Angsuran_DPP

21 22

Pekerjaan Penjualan_Formulir

23

Pendaftar_Mahasiswa_Baru

24

Ayah_Pendaftar

25

Ibu_Pendaftar

26

Wali_Pendaftar

Kebutuhan rinci data Mata_Ujian, Nomor_Soal, Soal, Kunci_Jawaban, Jawab_A, Jawab_B, Jawab_C, Jawab_D, Jawab_E, Skor Mata_Ujian, Nomor_Soal, Soal, Kunci_Jawaban, Skor Mata_Ujian, Nama_Mata_Ujian Jalur_Pendaftaran, Nama_Jalur_Pendaftaran, Beaya_Pendaftaran Program_Studi, Nama_Program_Studi, Tanggal_Berdiri, Tanggal_SK, Nomor_SK, Status_Program_Studi, Jurusan Jurusan, Nama_Jurusan, Tanggal_Berdiri, Tanggal_SK, Nomor_SK, Fakultas Fakultas, Nama_Fakultas, Tanggal_Berdiri, Tanggal_SK, Nomor_SK Program, Nama_Program Jenjang_Pendidikan, Nama_Jenjang_Pendidikan, Keterangan Jenis_Pendidikan, Nama_Jenis_Pendidikan Agama, Nama_Agama Kecamatan, Nama_Kecamatan, Kabupaten Kabupaten, Nama_Kabupaten, Propinsi Propinsi, Nama_Propinsi Kode_Pos, Nama_Kota Status_Program_Studi, Nama_Status_Program_Studi Tahun, Periode, Gelombang_Pendaftaran, Jumlah_SPP Tahun, Periode, Gelombang_Pendaftaran, Jumlah_DPP Tahun, Periode, Gelombang_Pendaftaran, SPP, Angsuran_ke, Jumlah_Angsuran Tahun, Periode, Gelombang_Pendaftaran, DPP, Angsuran_ke, Jumlah_Angsuran Pekerjaan, Nama_Pekerjaan Tahun, Periode, Gelombang_Pendaftaran, Jalur_Pendaftaran, Tanggal_Jual, Nomor_Urut_Formulir Nomor_Urut_Formulir, Nomor_Pendaftaran, Tahun, Periode, Gelombang_Pendaftaran, Jalur_Pendaftaran, Tanggal_Pendaftaran, Nama_Pendaftar, Jenjang_Pendidikan, Jenis_Pendidikan, Agama, Nilai_Bahasa_Inggris, Nilai_Matematika, Jumlah_NEM, Jumlah_Mata_Pelajaran_NEM, Jumlah_Nilai_STTB, Jumlah_Mata_Pelajaran_STTB, Agama, Kewarganegaraan, Alamat, Kecamatan, Kode_Pos, SLTA Nomor_Pendaftaran, Tahun, Periode, Gelombang_Pendaftaran, Jalur_Pendaftaran, Nama_Ayah, Jenjang_Pendidikan, Pekerjaan, Agama, Alamat, Kecamatan, Kode_Pos, Telepon, Penghasilan Nomor_Pendaftaran, Tahun, Periode, Gelombang_Pendaftaran, Jalur_Pendaftaran, Nama_Ibu, Jenjang_Pendidikan, Pekerjaan, Agama, Alamat, Kecamatan, Kode_Pos, Telepon, Penghasilan Nomor_Pendaftaran, Tahun, Periode, Gelombang_Pendaftaran, Jalur_Pendaftaran, Nama_Wali, Jenjang_Pendidikan, Pekerjaan, Agama, Alamat, Kecamatan, Kode_Pos, Telepon, Penghasilan

175

27

Pilihan_Pendaftaran_Mahasiswa

28

Jawaban_Ujian_Check_Point _Penmaru

29

Jawaban_Ujian_Essay_Penmaru

30

Kapasitas_Program_Studi

31

Batas_ Nilai_Pendaftar_Diterima

32

Pendaftar_Diterima

33

Pendaftar_Pindahan_Alih_Jalur

34

Konversi_Nilai_Pendaftar _Pindahan_Alih_Jalur

35

Heregisterasi_Mahasiswa_Baru

36

Heregisterasi_Mahasiswa_Lama

37 38

Status_Beaya_Mahasiswa Dosen_Wali_Mahasiswa

39 40

Jadwal_Bimbingan_Dosen_Wali Pembimbingan_Mahasiswa

41 42

Kalender_Akademik Kurikulum

43

Konversi_Kurikulum

44

Mata_Kuliah

45 46 47

Kelompok_Mata_Kuliah Status_Mata_Kuliah Jenis_Mata_Kuliah

Nomor_Pendaftaran, Tahun, Periode, Gelombang_Pendaftaran, Jalur_Pendaftaran, Program_Studi, Jenjang_Pendidikan, Program, Pilihan_Ke, Jumlah_Kesanggupan_DPP Mata_Ujian, Nomor_Pendaftaran, Tahun, Periode, Gelombang_Pendaftaran, Jalur_Pendaftaran, Program_Studi, Jenjang_Pendidikan, Program, Nomor_Soal, Jawaban, Skor Mata_Ujian, Nomor_Pendaftaran, Tahun, Periode, Gelombang_Pendaftaran, Jalur_Pendaftaran, Program_Studi, Jenjang_Pendidikan, Program, Nomor_Soal, Skor Tahun, Periode, Gelombang_Pendaftaran, Program_Studi, Jenjang_Pendidikan, Program, Kapasitas Tahun, Periode, Gelombang_Pendaftaran, Program_Studi, Jenjang_Pendidikan, Program, Batas_Nilai_Minimal_Diterima Nomor_Pendaftaran, Tahun, Periode, Gelombang_Pendaftaran, Jalur_Pendaftaran, Tanggal_Yudisium, Program_Studi, Jenjang_Pendidikan, Program Nomor_Pendaftaran, Tahun, Periode, Gelombang_Pendaftaran, Jalur_Pendaftaran, Program_Studi, Jenjang_Pendidikan, Program, SKS_Diakui, SKS_Ditempuh, PT_Asal, Program_Studi_Asal, Status_Program_Studi_Asal Nomor_Pendaftaran, Tahun, Periode, Gelombang_Pendaftaran, Jalur_Pendaftaran, Program_Studi, Jenjang_Pendidikan, Program, Kode_Mata_Kuliah, SKS, Nilai Nomor_Pendaftaran, Tahun, Periode, Gelombang_Pendaftaran, Jalur_Pendaftaran, Program_Studi, Jenjang_Pendidikan, Nomor, Tanggal_Heregisterasi Tahun, Jenjang_Pendidikan, Program_Studi, Program, Nomor, Tanggal_Registerasi, Status_Beaya_Mahasiswa Status_Beaya_Mahasiswa, Nama_Status_Mahasiswa Tahun, Jenjang_Pendidikan, Program_Studi, Program, Nomor, Tahun_Akademik, Semester, Kode_Dosen Kode_Dosen, Hari, Jam_Mulai, Jam_Usai, Ruang Tahun, Jenjang_Pendidikan, Program_Studi, Program, Nomor, Kode_Dosen, Tanggal, Keterangan Tanggal_Mulai, Tanggal_Akhir, Kegiatan Kurikulum, Jenjang_Pendidikan, Program_Studi, Program, Tanggal_SK_Kurikulum, Nomor_SK_Kurikulum, Jumlah_SKS_Wajib, Jumlah_SKS_Konsentrasi_Minat, Jumlah_SKS_Pilihan, Jumlah_SKS_Total_Minimal, Tanggal_Mulai, Syarat_IPK_Lulus, Syarat_Nilai_D_Maksimal Jenjang_Pendidikan, Program_Studi, Program, Kode_Mata_Kuliah_Lama, Kurikulum_Lama, Kode_Mata_Kuliah_Baru, Kurikulum_Baru Kode_Mata_Kuliah, Jenjang_Pendidikan, Program_Studi, Program, Nama_Mata_Kuliah, SKS, Semester, Kelompok_Mata_Kuliah, Status_Mata_Kuliah, Jenis_Mata_Kuliah, Kurikulum Kelompok_Mata_Kuliah, Nama_Kelompok_Mata_Kuliah Status_Mata_Kuliah, Nama_Status_Mata_Kuliah Jenis_Mata_Kuliah, Nama_Jenis_Mata_Kuliah, Jam_Per_SKS

176

48 49

Prasyarat_Mata_Kuliah Jadwal_Kuliah

50

Dosen_Mengajar

51

Asisten_Praktikum

52 53 54

Ruang_Dan_Laboratorium Waktu Pra_KRS

55

Kelompok_Praktikum

56

Perubahan_KRS

57

Dosen_Tetap

58

Dosen_Tidak_Tetap

59

Materi_Dosen_Mengajar

60

Presensi_Mahasiswa_Kuliah

61

Perolehan_Nilai_Kuliah

62

Bobot_Nilai_Kuliah

63

Kerja_Praktek

64

Periode_KKN

Kode_Mata_Kuliah_Prasyarat, Kode_Mata_Kuliah Jenjang_Pendidikan, Program_Studi, Program, Kode_Mata_Kuliah, Tahun, Semester, Kode_Dosen, Ruang, Kelas, Waktu Kode_Dosen, Jenjang_Pendidikan, Program_Studi, Program, Kode_Mata_Kuliah, Tahun_Akademik, Semester, Status_Mengajar Kode_Asisten, Jenjang_Pendidikan, Program_Studi, Program, Kode_Mata_Kuliah, Tahun_Akademik, Semester, Kelas, Kelompok_Praktikum Ruang, Kapasitas, Ukuran_Luas, Keterangan Waktu, Hari, Jam_Mulai Tahun, Jenjang_Pendidikan, Program_Studi, Program, Nomor, Tahun_Akademik, Semester, Kode_Mata_Kuliah, Kelas Tahun, Jenjang_Pendidikan, Program_Studi, Program, Nomor, Tahun_Akademik, Semester, Kode_Mata_Kuliah, Kelas, Kelompok Tahun, Jenjang_Pendidikan, Program_Studi, Program, Nomor, Tahun_Akademik, Semester, Kode_Mata_Kuliah_Dirubah, Kode_Mata_Kuliah_Baru, Kelas Kode_Dosen, NIK, Nama_Dosen, Gelar_Depan, Gelar_Belakang, Tanggal_Masuk, Nomor_SK, Bidang, Agama, Alamat, Kecamatan, Kode_Pos, Agama, Telepon, Email Kode_Dosen, NIK, Nama_Dosen, Alamat, Kecamatan, Kode_Pos, Jenjang_Pendidikan, Bidang, Agama, Golongan, Ruang, Jabatan_Akademik, Telepon, Instansi_Asal, Alamat_Kantor, Kecamatan_Kantor, Telepon_Kantor, Faximili_Kantor, Email Kode_Dosen, Jenjang_Pendidikan, Program_Studi, Program, Kode_Mata_Kuliah, Tahun_Akademik, Semester, Status_Mengajar, Pertemuan_ke, Tanggal_Kuliah, Jam_Masuk, Jam_Keluar, Pokok_Bahasan, Sub_Pokok_Bahasan, Ringkasan_Materi Tahun, Jenjang_Pendidikan, Program_Studi, Program, Nomor, Kode_Mata_Kuliah, Tahun_Akademik, Semester, Tanggal_Kuliah, Status_Presensi Tahun, Jenjang_Pendidikan, Program_Studi, Program, Nomor, Kode_Mata_Kuliah, Tahun_Akademik, Semester, Skor_Presensi, Skor_Kuis, Skor_Tugas, Skor_UTS, Skor_UAS, Nilai Tahun, Tanggal_SK, Nomor_SK, Bobot_Presensi, Bobot_Kuis, Bobot _Tugas, Bobot _UTS, Bobot _UAS Tahun, Jenjang_Pendidikan, Program_Studi, Program, Nomor, Nomor_SK_KP, Tanggal_SK_KP, Kode_Dosen, Judul_KP, Tema_Topik, Perusahaan, Alamat, Kecamatan, Kode_Pos, Telepon, Faksimili, Email, Jenis_Penelitian, Tanggal_Seminar, Jumlah_Peserta_Seminar, Catatan_Berita_Acara_Seminar, Nilai Tahun, Periode, Nomor_SK, Tanggal_SK, Tanggal_Mulai, Tanggal_Akhir, Jumlah_Kelompok, Jumlah_Dusun, Jumlah_Desa, Jumah_Kecamatan_Jumlah_Kabupaten, Jumlah_Propinsi, Jumlah_DPL

177

65

Bobot_Nilai_KKN

66

Mahasiswa_KKN

67

Mahasiswa_KKN_Magang

68

Tugas_Akhir

69 70

Tema_Topik_Penelitian Nilai

71

Jabatan_Panitia_KKN

72

Jabatan_Panitia_KKN_Dosen

73

Jabatan_Panitia_KKN_Karyawan

74 75

78 79 80 81

Batas_Pengambilan_SKS Sejarah_Pendidikan _Dosen_Tetap Sejarah_Jabatan_Akademik _Dosen_Tetap Sejarah_Golongan_Ruang _Dosen_Tetap Bidang Golongan_Ruang Jenjang_Pendidikan Jabatan_Akademik

82

SD

83

SLTP

84

SLTA

85

Perguruan_Tinggi

76 77

Tahun, Periode, Bobot_Nilai_Presensi, Bobot_ Nilai_Pembekalan, Bobot_ Nilai_Bhakti_Kampus, Bobot_ Nilai_Pelaksanaan, Bobot_ Nilai_Laporan, Bobot_ Nilai_Dusun, Bobot_ Nilai_Tim_Evaluasi, Bobot_ Nilai_Koordinator_DPL, Bobot_ Nilai_Antar_Mahasiswa Tahun, Jenjang_Pendidikan, Program_Studi, Program, Nomor, Periode, Kelompok, Desa, Kode_Dosen, Skor_Presensi, Skor_Pembekalan, Skor_Bhakti_Kampus, Skor_Pelaksanaan, Skor_Laporan, Skor_Dusun, Skor_Tim_Evaluasi, Skor_Koordinator_DPL, Skor_Antar_Mahasiswa, Nilai Tahun, Jenjang_Pendidikan, Program_Studi, Program, Nomor, Perusahaan, Nomor_SK, Tanggal_SK, Tanggal_Mulai, Tanggal_Akhir, Kode_Dosen, Nama_Pembimbing_Lapangan, Nilai_Dosen_Pembimbing, Nilai_Pembimbing_Lapangan, Nilai Tahun, Jenjang_Pendidikan, Program_Studi, Program, Nomor, Nomor_SK_TA, Tanggal_SK_TA, Kode_Dosen_1, Kode_Dosen_2, Judul, Judul_Inggris, Tema_Topik, Jenis_Penelitian, Nomor_Berita_Acara, Tanggal_Pendadaran, Judul_TA_Inggris, Kode_Dosen_1, Kode_Dosen_2, Kode_Dosen_3, Skor_Dosen_1, Skor_Dosen_2, Skor_Dosen_3, Nilai Tema_Topik, Nama_Tema_Topik Nilai, Batas_Minimal_Skor, Batas_Maksimal_Skor, Mutu, Predikat Tahun, Periode, Jabatan_Panitia_KKN, Nama_Jabatan_Panitia_KKN Tahun, Periode, Kode_Dosen, Jabatan_Panitia_KKN, Tanggal_SK, Nomor_SK Tahun, Periode, Kode_Karyawan, Jabatan_Panitia_KKN, Tanggal_SK, Nomor_SK IPK_Minimal, IPK_Maksimal, Minimal_SKS, Maksimal_SKS Kode_Dosen, Jenjang_Pendidikan, Kode_Sekolah, Tanggal_Lulus, Nomor_Ijazah Kode_Dosen, Tanggal_SK, Nomor_SK, Jabatan_Akademik, Angka_Kredit Kode_Dosen, Tanggal_SK, Nomor_SK, Golongan, Ruang Bidang, Nama_Bidang Golongan, Ruang, Pangkat, Gaji_Pokok Jenjang_Pendidikan, Nama_Jenjang_Pendidikan Tanggal_SK, Nomor_SK, Jabatan_Akademik, Nama_Jabatan_Akademik, Angka_Kredit_Minimum SD, Nama_SD, Jenis_Pendidikan, Alamat, Kecamatan, Kode_Pos, Telepon, Faksimili, Email SLTP, Nama_SLTP, Jenis_Pendidikan, Alamat, Kecamatan, Kode_Pos, Telepon, Faksimili, Email SLTA, Nama_SLTA, Jenis_SLTA, Bidang, Alamat, Kecamatan, Kode_Pos, Telepon, Faksimili, Email PT, Nama_PT, Jenis_Pendidikan, Alamat, Kecamatan, Kode_Pos, Telepon, Faksimili

178

86

Perusahaan

87 88

Jenis_Penelitian Jabatan_Struktural_PT

89

Pejabat_Struktural_Dosen

90

Pejabat_Struktural_Karyawan

91

Yudisium_Lulus_Mahasiswa

92

Predikat_Kelulusan

93

Pekerjaan_Alumni

94 95

Jabatan_Kerja_Perusahaan Jenis_Usaha_Perusahaan

4.1.4.

Perusahaan, Nama_Perusahaan, Alamat_Perusahaan, Kecamatan, Kode_Pos, Jenis_Usaha, Faksimili, Email Jenis_Penelitian, Nama_Jenis_Penelitian Tanggal_SK, Nomor_SK, Jabatan_Struktural, Nama_Jabatan_Struktural, Tingkat_Jabatan_Struktural, Tunjangan_Jabatan_Struktural, Masa_Jabatan_Struktural, Keterangan Tanggal_SK, Nomor_SK, Jabatan_Struktural, Kode_Dosen, Tanggal_Mulai_SK, Tanggal_Akhir_SK, Keterangan Tanggal_SK, Nomor_SK, Jabatan_Struktural, Kode_Karyawan, Tanggal_Mulai_SK, Tanggal_Akhir_SK, Keterangan Tahun, Jenjang_Pendidikan, Program_Studi, Jenjang_Pendidikan, Program, Nomor, Tanggal_Yudisium, Tanggal_Wisuda, Nomor_Anggota_Alumni Predikat_Lulus, Nama_Predikat_Lulus, IPK_Minimal, IPK_Maksimal, Jumlah_Semester_Masa_Studi_Maksimal Nomor_Anggota_Alumni, Alamat_Kerja, Kecamatan Kode_Pos, Telepon, Email, Tanggal_Mulai_Kerja, Perusahaan, Jabatan_Kerja, Gaji Jabatan_Kerja, Nama_Jabatan_Kerja, Tingkat_Jabatan_Kerja Jenis_Usaha, Nama_Jenis_Usaha

Perubahan Kebutuhan Informasi (dan Data) Untuk SIAKAD Berdasarkan hasil identifikasi kebutuhan informasi (dan data) dan kebutuhan

nilai rinci data untuk SIAKAD, maka selanjutnya dapat diidentifikasikan kebutuhan nilai-nilai rinci data yang memiliki kemungkinan perubahan di kelak kemudian hari dan perlu diantisipasi dalam rancangan struktur tabel database. Hasil identifikasi nilai-nilai rinci data dalam SIAKAD yang memiliki kemungkinan perubahan adalah ditampilkan dalam Tabel 4.6. Tabel 4.6: Perubahan pada nilai-nilai rinci data dalam SIAKAD No 1

Nilai rinci data Mata_Ujian

2

Skor

3

Periode

4

Gelombang

Keterangan perubahan Mata ujian Penmaru dapat berubah Skor nilai ujian Penmaru dapat berubah Periode Penmaru dapat berubah dari 1 tahun 1x menjadi 2x Gelombang Penmaru dapat

Alternatif solusi Dikodekan dan dibuat tabel referensi Perlu disimpan pada setiap nomor soal Periode perlu disimpan pada setiap Penmaru dan dibuat tabel referensi Gelombang perlu disimpan pada

179

5

Jalur_Pendaftaran

6

Program_Studi

7

Program

8

Jenjang_Pendidikan

9

Alamat

10

Kabupaten

11

Propinsi

12

Status_Program_Studi

13

Jumlah_SPP

14

Jumlah_DPP

15

Angsuran_ke

16

Pekerjaan

17

Jumlah_NEM

berubah dari 1 periode 3x menjadi 4x atau lebih Jalur pendaftaran Penmaru dapat berubah dengan pemilihan calon berprestasi tanpa ujian masuk Program Studi yang ditawarkan oleh PT dapat bertambah atau berkurang Program dapat berubah dengan penyelenggaraan program baru, misal program ekstensi Jenjang pendidikan yang ditawarkan oleh PT dapat berubah dengan penyelenggaraan jenjang pendidikan lain yang baru Alamat dapat berubah, perubahan ini akan mengubah hubungan alamat dengan kecamatan, kabupaten dan propinsi Kabupaten dapat berubah, perubahan ini akan mengubah hubungan kabupaten dengan kecamatan dan propinsi Propinsi dapat berubah, perubahan ini akan mengubah hubungan propinsi dengan alamat, kecamatan, dan kabupaten Status Program Studi dapat berubah (khususnya untuk PTS) dari Terdaftar-Diakui-Disamakan menjadi Terakreditasi A-B-C-Tidak Terakeaditasi Jumlah nominal SPP dapat berubah untuk setiap tahun angkatan Jumlah nominal DPP dapat berubah untuk setiap tahun angkatan Jumlah frekuensi dan nominal angsuran SPP dan DPP dapat berubah untuk setiap Tahun, Periode, dan Gelombang Penmaru Pekerjaan orang tua-wali mahasiswa dapat berubah dengan pengelompokkan pekerjaan baru Jumlah NEM dapat berubah, bahkan saat ini sudah tidak berlaku pada SLTA. Sekalipun demikian, data ini tetap diperlukan untuk penyusunan porfolio,

setiap Penmaru dan dibuat tabel referensi Dikodekan dan dibuat tabel referensi Dikodekan dan dibuat tabel referensi Dikodekan dan dibuat tabel referensi Dikodekan dan dibuat tabel referensi Kecamatan, kabupaten, dan propinsi perlu dikodekan dan dibuat tabel referensi Kabupaten perlu dikodekan dan dibuat tabel referensi Propinsi perlu dikodekan dan dibuat tabel referensi Status Program Studi perlu dikodekan dan dibuat tabel referensi Jumlah nominal SPP perlu disimpan pada setiap Penmaru Jumlah nominal DPP perlu disimpan pada setiap Penmaru Jumlah frekuensi dan nominal angsuran SPP dan DPP perlu disimpan pada setiap Tahun, Periode, dan Gelombang Penmaru Pekerjaan perlu dikodekan dan dibuat tabel referensi Jumlah NEM perlu disimpan, dan pada saat NEM tidak ada lagi, nilainya bisa disubstitusikan oleh nilai mata pelajaran yang setara

180

18

Jumlah_Mata_Pelajaran _NEM

19

Mata_Ujian

20

Kapasitas

21

Batas_Nilai_Minimal _Diterima

22

SKS_Diakui

23

SKS_Ditempuh

24

Kode_Mata_Kuliah

25

SKS

26

Nilai

27

Kode_Dosen

28

Kurikulum

29

Kode_Mata_Kuliah

evaluasi diri, dan borang Jumlah Mata Pelajaran NEM dapat berubah untuk setiap bidang pendidikan di SLTA Mata Ujian Penmaru dapat berubah dengan penambahan mata ujian baru Kapasitas mahasiswa Prgram Studi dapat berubah pada setiap Tahun, Periode, dan Gelombang Penmaru Batas Nilai Minimal Diterima Penmaru dapat berubah pada setiap Tahun, Periode, dan Gelombang Penmaru SKS Diakui bagi mahasiswa baru alih jalur atau pindahan dapat berubah, tergantung pada kesesuaian mata kuliah, SKS, dan kebijakan SKS Ditempuh bagi pendaftar pada jalur alih jalur atau pindahan dapat berubah, tergantung pada kesesuaian mata kuliah SKS, dan kebijakan Kode Mata Kuliah bagi pendaftar pada jalur alih jalur atau pindahan dapat berubah, tergantung pada kesesuaian mata kuliah SKS, dan kebijakan SKS mata kuliah bagi pendaftar pada jalur alih jalur atau pindahan dapat berubah, tergantung pada mata kuliah SKS, dan kebijakan Nilai mata kuliah yang diakui bagi pendaftar pada jalur alih jalur atau pindahan dapat berubah, tergantung pada mata kuliah SKS, dan kebijakan Kode Dosen-Wali mahasiswa dapat berubah karena dosen sedang studi lanjut sehingga harus dialihkan Kurikulum dapat berubah, misal kebijakan perubahan kurikulum dan silabus sebagai hasil evaluasi rutin Kode Mata Kuliah dapat berubah,

Jumlah Mata Pelajaran NEM perlu disimpan untuk keperluan perhitungan selanjutnya, misal Rata-rata NEM Mata Ujian Penmaru perlu dikodekan dan dibuat tabel referensi Kapasitas perlu disimpan pada setiap Tahun, Periode, dan Gelombang Penmaru Batas Nilai Minimal Diterima perlu disimpan pada setiap Tahun, Periode, dan Gelombang Penmaru SKS Diakui perlu disimpan pada setiap pendaftar

SKS Ditempuh perlu disimpan pada setiap pendaftar pada jalur

Kode Mata Kuliah yang diakui perlu disimpan pada setiap pendaftar pada jalur alih jalur atau pindahan Kode Mata Kuliah yang diakui perlu disimpan pada setiap pendaftar pada jalur alih jalur atau pindahan Nilai yang diakui perlu disimpan pada setiap pendaftar pada jalur alih jalur atau pindahan Kode_Dosen pada dosen wali perlu dikodekan dan dibuat tabel referensi Kurikulum perlu disimpan pada setiap perubahan kurikulum berikut konversi mata kuliah lama dengan mata kuliah dalam kurikulum baru Kode Mata Kuliah perlu disimpan

181

30

Kelompok_Mata_Kuliah

31

Status_Mata_Kuliah

32

Jenis_Mata_Kuliah

33

TIU

34

TIK

35

Silabus

36

GBPP

37

SAP

38

Kode_Mata_Kuliah_Prasyarat

39

Ruang

40

Status_Mengajar

41

Waktu

42

Jam_Mulai

misal kebijakan perubahan kurikulum dan silabus sebagai hasil evaluasi rutin Kelompok mata kuliah dalam kurikulum dapat berubah, misal akibat perubahan peraturan pemerintah Status mata kuliah dalam kurikulum dapat berubah, misal akibat perubahan peraturan pemerintah dan kebijakan Jenis mata kuliah dalam kurikulum dapat berubah, misal akibat perubahan peraturan pemerintah dan kebijakan TIU mata kuliah dalam kurikulum dapat berubah, misal akibat perubahan peraturan pemerintah dan kebijakan TIK mata kuliah dalam kurikulum dapat berubah, misal akibat perubahan peraturan pemerintah dan kebijakan Silabus mata kuliah dalam kurikulum dapat berubah, misal akibat perubahan peraturan pemerintah dan kebijakan GBPP mata kuliah dalam kurikulum dapat berubah, misal akibat perubahan peraturan pemerintah dan kebijakan SAP mata kuliah dalam kurikulum dapat berubah, misal akibat perubahan peraturan pemerintah dan kebijakan Kode Mata Kuliah Prasyarat setiap mata kuliah dapat berubah, misal akibat perubahan kurikulum Ruang kuliah dapat berubah, misal pembangunan ruang kuliah baru Status mengajar dosen dapat berubah, misal akibat perubahan kebijakan Waktu kuliah dapat berubah, misal akibat perubahan kebijakan kuliah bisa sampai malam hari atau Sabtu-Minggu pada program ekstensi Jam mulai kuliah dapat berubah, misal akibat perubahan kebijakan

pada setiap perubahan kurikulum Kelompok mata kuliah perlu disimpan pada setiap perubahan kurikulum Status mata kuliah perlu disimpan pada setiap perubahan kurikulum Jenis mata kuliah perlu disimpan pada setiap perubahan kurikulum TIU mata kuliah perlu disimpan pada setiap perubahan kurikulum TIK mata kuliah perlu disimpan pada setiap perubahan kurikulum Silabus mata kuliah perlu disimpan pada setiap perubahan kurikulum GBPP mata kuliah perlu disimpan pada setiap perubahan kurikulum SAP mata kuliah perlu disimpan pada setiap perubahan kurikulum Kode Mata Kuliah Prasyarat setiap mata kuliah perlu disimpan pada setiap perubahan kurikulum Kode ruang kuliah perlu dikodekan dan dibuat tabel referensi Statusmengajar dosen perlu dikodekan dan dibuat tabel referensi Waktu kuliah perlu dikodekan dan dibuat tabel referensi

Jam kuliah perlu disimpan pada setiap jadwal kuliah-praktikum

182

43

Nilai

44

Bobot_Presensi

45

Bobot_Kuis

46

Bobot _Tugas

47

Bobot _UTS

48

Bobot _UAS

49

Tema_Topik

50

Jenis_Penelitian

51

Bobot_Nilai_Presensi

52

Bobot_ Nilai_Pembekalan

53

Bobot_ Nilai_Bhakti_Kampus

54

Bobot_ Nilai_Pelaksanaan

55

Bobot_ Nilai_Laporan

56

Bobot_ Nilai_Dusun

57

Bobot_ Nilai_Tim_Evaluasi

58

Bobot_ Nilai_Koordinator_DPL

59

Bobot_

sesi kuliah-praktikum Nilai akhir mata kuliah-praktikumKP-KKN-TA dapat berubah, misal akibat perubahan kebijakan Bobot presensi untuk penilaian mata kuliah dapat berubah, misal akibat perubahan kebijakan Bobot kuis untuk penilaian mata kuliah dapat berubah, misal akibat perubahan kebijakan Bobot tugas untuk penilaian mata kuliah dapat berubah, misal akibat perubahan kebijakan Bobot UTS untuk penilaian mata kuliah dapat berubah, misal akibat perubahan kebijakan Bobot UAS untuk penilaian mata kuliah dapat berubah, misal akibat perubahan kebijakan Tema-Topik penelitian mahasiswa KP-TA dan dosen dapat berubah, misal akibat munculnya tema baru Jenis penelitian mahasiswa KP-TA dan dosen dapat berubah, misal akibat perubahan kebijakan Bobot Nilai Presensi KKN dapat berubah, misal akibat perubahan kebijakan Bobot Nilai Pembekalan KKN dapat berubah, misal akibat perubahan kebijakan Bobot Nilai Bhakti Kampus KKN dapat berubah, misal akibat perubahan kebijakan Bobot Nilai Pelaksanaan KKN dapat berubah, misal akibat perubahan kebijakan Bobot Nilai Laporan KKN dapat berubah, misal akibat perubahan kebijakan Bobot Nilai Dusun KKN dapat berubah, misal akibat perubahan kebijakan Bobot Nilai Tim Evaluasi KKN dapat berubah, misal akibat perubahan kebijakan Bobot Nilai Koordinator DPL KKN dapat berubah, misal akibat perubahan kebijakan Bobot Nilai Antar Mahasiswa KKN

Nilai perlu dikodekan dan dibuat tabel referensi Bobot presensi perlu disimpan pada setiap perolehan nilai mata kuliah Bobot kuis perlu disimpan pada setiap perolehan nilai mata kuliah Bobot tugas perlu disimpan pada setiap perolehan nilai mata kuliah Bobot UTS perlu disimpan pada setiap perolehan nilai mata kuliah Bobot UAS perlu disimpan pada setiap perolehan nilai mata kuliah Tema-Topik perlu dikodekan dan dibuat tabel referensi Jensis penelitian perlu dikodekan dan dibuat tabel referensi Bobot Nilai Presensi KKN perlu disimpan pada setiap Tahun dan Periode KKN Bobot Nilai Pembekalan KKN perlu disimpan pada setiap Tahun dan Periode KKN Bobot Nilai Bhakti Kampus KKN perlu disimpan pada setiap Tahun dan Periode KKN Bobot Nilai Pelaksanaan KKN perlu disimpan pada setiap Tahun dan Periode KKN Bobot Nilai Laporan KKN perlu disimpan pada setiap Tahun dan Periode KKN Bobot Nilai Dusun KKN perlu disimpan pada setiap Tahun dan Periode KKN Bobot Nilai Tim Evaluasi KKN perlu disimpan pada setiap Tahun dan Periode KKN Bobot Nilai Koordinator DPL KKN perlu disimpan pada setiap Tahun dan Periode KKN Bobot Nilai Antar Mahasiswa KKN

183

Nilai_Antar_Mahasiswa 60

Jabatan_Panitia_KKN

61

Minimal_SKS

62

Minimal_SKS

63

Jabatan_Akademik

64

Bidang

65

Gaji_Pokok

66

Jenis_Usaha

67

Jabatan_Struktural

68

Predikat_Lulus

69

Jabatan_Kerja

4.1.5.

dapat berubah, misal akibat perubahan kebijakan Jabatan Panitia KKN dosenkaryawan dapat berubah, misal akibat perubahan kebijakan atau SK panitia pada setiap Tahun dan Periode KKN Minimal SKS pengambilan mata kuliah yang boleh ditempuh oleh mahasiswa dapat berubah, misal karena perubahan kebijakan Maksimal SKS pengambilan mata kuliah yang boleh ditempuh oleh mahasiswa dapat berubah, misal karena perubahan kebijakan Jabatan Akademik Dosen dapat berubah, misal akibat perubahan peraturan pemerintah Bidang ilmu dosen-pendaftar mahasiswa baru alih jalurpindahan dapat berubah, misal akibat munculnya pengelompokkan bidang ilmu baru Gaji Pokok Golongan Ruang Gaji Dosen-Karyawan dapat berubah, misal akibat perubahan kebijakan Jenis Usaha perusahaan tempat KP-TA-KKN-kerja alumni dapat berubah, misal akibat perubahan kebijakan atau pasar baru Jabatan Struktural DosenKaryawan pada PT dapat berubah, misal akibat perubahan kebijakan Predikat Lulus yudisium kelulusan mahasiswa dapat berubah, misal akibat perubahan kebijakan Jabatan Kerja alumni di perusahaan dapat berubah, misal akibat kebijakan pengelompokkan jabatan kerja baru

perlu disimpan pada setiap Tahun dan Periode KKN Jabatan Panitia KKN dosenkaryawan perlu dikodekan dan dibuat tabel referensi Minimal SKS perlu disimpan pada setiap perubahan kebijakan Maksimal SKS perlu disimpan pada setiap perubahan kebijakan Jabatan Akademik Dosen perlu dikodekan dan dibuat tabel referensi Bidang ilmu perlu dikodekan dan dibuat tabel referensi

Gaji Pokok Golongan Ruang Gaji Dosen-Karyawan perlu disimpan pada setiap perubahan kebijakan Jenis Usaha perusahaan tempat KP-TA-KKN-kerja alumni perlu dikodekan dan dibuat tabel referensi Jabatan Struktural DosenKaryawan perlu dikodekan dan dibuat tabel referensi Predikat Lulus yudisium kelulusan mahasiswa perlu dikodekan dan dibuat tabel referensi Jabatan Kerja alumni di perusahaan perlu dikodekan dan dibuat tabel referensi

Langkah Analisis Fleksibilitas Rancangan Struktur Tabel Database Analisis fleksibilitas rancangan struktur tabel database untuk SIAKAD akan

dilakukan terhadap data rancangan struktur tabel database yang berhasil

184

dikumpulkan. Analisis fleksibilitas rancangan struktur tabel database untuk SIAKAD akan dilakukan sesuai dengan langkah dalam metodologi penelitian, yaitu: 1. Tentukan apakah nilai elemen data yang disimpan dalam atribut memiliki kemungkinan terjadi perubahan format nilai rinci data pada atribut ataupun perubahan nilai rinci data pada atribut yang berpengaruh terhadap nilai rinci data pada atribut yang lain, baik yang terencana maupun tidak terencana, dalam jangka pendek maupun jangka panjang. Langkah ini dilakukan dengan mengisi Y/T pada kolom Kemungkinan Berubah [Y/T] dalam tabel analisis. 2. Berikan penilaian fleksibilitas apakah rancangan atribut yang dinilai dapat memenuhi perubahan tersebut secara efisien/mudah. Jika atribut bersifat fleksibel, yaitu dapat diubah secara efisien/mudah, maka sifat fleksibel pada atribut diberikan nilai YA (=Y). Sebaliknya, jika atribut tidak dapat diubah secara efisien/mudah, maka maka sifat fleksibel pada atribut diberikan nilai TIDAK (=T). Selanjutnya, jika atribut diberikan nilai TIDAK (=T), maka berikan penjelasan mengapa atribut tersebut tidak fleksibel. Langkah ini dilakukan dengan mengisi Y/T pada kolom Fleksibel [Y/T] dalam tabel analisis. 3. Ulangi langkah a dan b tersebut hingga seluruh atribut dalam seluruh rancangan struktur tabel database selesai diberikan penilaian. Selanjutnya, berdasarkan penilaian tersebut, maka tingkat fleksibilitas suatu rancangan struktur tabel database ditentukan dengan langkah sebagai berikut (Klesse, Herrmann, Brändli, Mügeli, Maier, http://wotan.liu.edu/docis/dbl/iqiqiq /2004_418_CIPACS.htm):

185

a. Hitung cacah seluruh atribut (=JUMLAH_ATRIBUT) dalam rancangan struktur tabel database. b. Hitung cacah atribut yang memenuhi kriteria fleksibel yaitu yang memiliki penilaian YA (=CACAH_Y) dan jumlah atribut yang tidak memenuhi

kriteria

fleksibel

yang

memiliki

penilaian

TIDAK

(=CACAH_T) pada kolom Fleksibel [Y/T] dalam tabel analisis. c. Hitung presentase atribut yang bersifat fleksibel (=PERSEN_Y). Perhitungan dilakukan dengan cara membagi cacah atribut yang memenuhi kriteria fleksibel (=CACAH_Y) dengan cacah seluruh atribut dalam seluruh tabel dalam sebuah rancangan struktur tabel database (=JUMLAH_ATRIBUT). Hasilnya kemudian dikalikan dengan 100%. Formula yang digunakan adalah sebagai berikut: PERSEN_Y = (CACAH_Y / JUMLAH_ATRIBUT) * 100% d. Hitung presentase atribut yang bersifat tidak fleksibel (=PERSEN_T). Perhitungan dilakukan dengan cara membagi cacah atribut yang tidak memenuhi kriteria fleksibel (=CACAH_T) dengan cacah seluruh atribut dalam seluruh tabel dalam sebuah rancangan struktur tabel database (=JUMLAH_ATRIBUT). Hasilnya kemudian dikalikan dengan 100%. Formula yang digunakan adalah sebagai berikut: PERSEN_T = (CACAH_T / JUMLAH_ATRIBUT) * 100% e. Tetapkan tingkat fleksibilitas rancangan struktur tabel database. Dalam penelitian ini, tingkat fleksibilitas rancangan struktur tabel database

186

ditentukan dengan menggunakan pendekatan Penilaian Acuan Pokok (=PAP), yaitu berorientasi pada suatu patokan nilai yang sifatnya pasti atau absolut. Tingkat fleksibilitas rancangan struktur tabel database ditentukan berdasarkan persentase cacah atribut yang memenuhi kriteria fleksibel (=PERSEN_Y), dengan membandingkan persentase cacah atribut yang memenuhi kriteria fleksibel (=PERSEN_Y) dengan suatu patokan yang telah ditetapkan sebelumnya, yaitu suatu tingkat fleksibilitas yang seharusnya dicapai oleh suatu rancangan tabel database. Idealnya, tingkat fleksibilitas yang seharusnya dicapai oleh suatu rancangan tabel database adalah 100% untuk nilai PERSEN_Y. Ketentuan tingkat fleksibilitas yang digunakan adalah sebagai berikut (diadopsi dari Blue Sheep® Ltd, www.bluesheep.com/cgi/news /show.php4?f=010102):

4.1.6.

SANGAT BAIK

: jika 80
BAIK

: jika 60
SEDANG

: jika 40
BURUK

: jika 20
SANGAT BURUK

: jika 0
Data Yang Dianalisis Data yang dianalisis dalam penelitian ini dikelompokkan menjadi 3 (tiga),

yaitu sebagai berikut: 1. Rancangan struktur database untuk SIAKAD Kelompok Pertama, yaitu berupa rancangan struktur tabel database yang diperoleh dari hasil Penelitian Tesis

187

mahasiswa Program Pasca Sarjana, Program Studi Ilmu Komputer, Fakultas Matematika & Ilmu Pengetahuan Alam, Universitas Gadjah Mada, Yogyakarta. Jumlah sampel rancangan struktur tabel database kelompok ini sebanyak 10 (sepuluh) buah rancangan. 2. Rancangan struktur database untuk SIAKAD Kelompok Kedua, yaitu berupa rancangan struktur tabel database yang diperoleh dari hasil Penelitian Skripsi mahasiswa Program Sarjana, Program Studi Teknik Infomatika, Institut Sains & Teknologi AKPRIND, Yogyakarta. Jumlah sampel rancangan struktur tabel database kelompok ini sebanyak 10 (sepuluh) buah rancangan. 3. Rancangan struktur database untuk SIAKAD Kelompok Ketiga, yaitu berupa rancangan struktur tabel database yang diperoleh dari hasil Penelitian Tugas Akhir mahasiswa Program Studi Manajemen Infomatika & Teknik Komputer, Institut Sains & Teknologi AKPRIND, Yogyakarta. Jumlah sampel rancangan struktur tabel database kelompok ini sebanyak 8 (delapan) buah rancangan.

4.1.6.1. Data Penelitian Kelompok Pertama Berdasarkan Daftar Penelitian Tesis pada Program Studi Ilmu Komputer, Jurusan Matematika dan Ilmu-ilmu Pengetahuan Alam, Fakultas Matematika dan Ilmu Pengetahuan Alam, Universitas Gadjah Mada, Yogyakarta, hingga tanggal 15 April 2005, sedikitnya terdapat 12 (dua belas) judul penelitian Tesis yang terkait dengan topik SIAKAD. Rancangan struktur tabel database Kelompok Pertama yang akan dianalisis dalam penelitian ini sebanyak 10 (sepuluh) buah rancangan.

188

Data rancangan struktur tabel database pertama yang dianalisis, adalah hasil penelitian yang dilakukan oleh Medi (2002) berjudul Rancangan Web Akademik dengan Basisdata Terdistribusi, selanjutnya disebut DATA_09_001, dengan detail sebagai berikut: Nama peneliti Judul penelitian Tahun Kode referensi Jumlah tabel database Jumlah atibut Pada halaman

: Medi : Rancangan Web Akademik Dengan Basisdata Terdistribusi : 2002 : T IK 29 : 10 : 68 : 42-46

Desain struktur tabel database yang dihasilkan secara berturut-turut ditampilkan dalam Tabel 4.7 hingga Tabel 4.16. Tabel 4.7: Mata_Kuliah (Medi, 2002, hal: 42) Field Num 1. 2. 3. 4.

Field name Kode Nm_kuliah Sks Referensi

Data type Char Char Char VarChar

Width 8 30 1 200

Key PK

Null

Default

Yes

Null

Null

Default

Yes Yes Yes Yes

Null Null Null Null

Key PK

Null

Default

Yes Yes Yes

Null Null Null

Tabel 4.8: Dosen (Medi, 2002, hal: 42-43) Field Num 1. 2. 3. 4. 5. 6. 7. 8.

Field name NIP_dosen Nama Tanggal_lahir Tempat_lahir Alamat Bidang Foto Pendidikan

Data type Char Char Date Char Char Char Char Char

Width 9 20 8 30 30 25 12 15

Key PK

Tabel 4.9: Mahasiswa (Medi, 2002, hal: 43-44) Field Num 1. 2. 3. 4. 5. 6. 7.

Field name No_mahasiswa Tahun_angkatan Fakultas Nama Nama_ayah Nama_ibu Nama_wali

Data type Char Char Char Char Char Char Char

Width 5 4 15 30 30 30 30

189

8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.

Program_studi Nip_dosen_wali Jurusan Alamat_jogja Alamat_asal Jml_sks_ditempuh Jml_sks_diambil IP_komulatif Jenis_kelamin Tanggal_lahir Tempat_lahir Agama Golongan_darah Telepon Hobi

Char Char Char Char Char Num Num Num Logic Date Char Char Char Char VarChar

10 9 10 20 20 3 2 4,2 1 8 20 10 2 15 30

Yes Yes

Null Null

Yes

Null

Yes Yes

Null Null

Tabel 4.10: Mengajar (Medi, 2002, hal: 43) Field Num 1. 2. 3.

Field name NIP_dosen Kode_kuliah Semester

Data type Char Char Char

Width 20 8 1

Key PK PK

Null

Default

Yes

Null

Key PK

Null

Default

Yes Yes Yes Yes Yes

Null Null Null Null Null

Tabel 4.11: Medis (Medi, 2002, hal: 44-45) Field Num 1. 2. 3. 4. 5. 6. 7. 8. 9.

Field name No_mahasiswa Penyakit_1 Penyakit_2 Penyakit_3 Penyakit_4 Penyakit_5 Opname Dokter_pribadi Rumah_sakit_rujukan

Data type Char Char Char Char Char Char Logic Char Char

Width 5 15 15 15 15 15 1 15 20

Tabel 4.12: Pustaka (Medi, 2002, hal: 45) Field Num 1. 2. 3. 4. 5. 6. 7.

Field name No_mahasiswa Kode_buku Judul_buku Pengarang Tanggal_pinjam Tanggal_kembali Petugas

Data type Char Char Char Char Date Date Char

Width 5 15 50 30 8 8 15

Key PK

Null

Default

Yes Yes Yes Yes Yes

Null Null Null Null Null

Null

Default

Tabel 4.13: Keamanan (Medi, 2002, hal: 45) Field Num 1. 2.

Field name No_mahasiswa No_masalah

Data type Char Char

Width 5 15

Key PK PK

190

3. 4.

Kriteria_masalah Sangsi

Char Char

15 15

Yes Yes

Null Null

Null

Default

Yes Yes

Null Null

Null

Default

Yes Yes

Null Null

Null

Default

Yes

Null

Tabel 4.14: Beasiswa (Medi, 2002, hal: 45-46) Field Num 1. 2. 3. 4.

Field name No_mahasiswa Kode_beasiswa Tahun Nama_beasiswa

Data type Char Char Date Char

Width 5 15 8 15

Key PK PK

Width 5 15 15 15

Key PK PK

Tabel 4.15: UPT (Medi, 2002, hal: 46) Field Num 1. 2. 3. 4.

Field name No_mahasiswa Kode_layanan Jenis_layanan Keterangan

Data type Char Char Char Char

Tabel 4.16: Koperasi (Medi, 2002, hal: 46) Field Num 1. 2. 3.

Field name No_mahasiswa Kode_angota Jumlah_pinjam

Data type Char Char Num

Width 5 6 10

Key PK PK

Selanjutnya, secara berturut-turut data rancangan struktur tabel database yang dianalisis, adalah ditunjukkan dalam Lampiran 1 hingga Lampiran 9.

4.1.6.2.

Data Penelitian Kelompok Kedua Rancangan struktur tabel database untuk SIAKAD Kelompok Kedua

diperoleh dari hasil penelitian Skripsi yang pernah dilakukan oleh mahasiswa Program Sarjana, Program Studi Teknik Infomatika, Institut Sains & Teknologi AKPRIND, Yogyakarta. Rancangan struktur tabel database Kelompok Kedua yang akan dianalisis dalam penelitian ini sebanyak 10 (sepuluh) buah rancangan.

191

Data rancangan struktur tabel database pertama yang dianalisis, adalah hasil penelitian yang dilakukan oleh Retno Rahayuningsih (2000) berjudul Rekayasa Komputerisasi KRS dan KHS Universitas X, selanjutnya disebut DATA_08_001, dengan detail sebagai berikut: Nama peneliti Judul Penelitian Tahun Jumlah tabel database Jumlah atribut Pada halaman

: Retno Rahayuningsih : Rekayasa Komputerisasi KRS dan KHS Universitas X : 2000 :6 : 31 : 14 - 16

Desain struktur tabel database yang dihasilkan secara berturut-turut ditampilkan dalam Tabel 4.17 hingga Tabel 4.22. Tabel 4.17: Mhs (Rahayuningsih, 2000, hal: 14) No. 1 2 3 4 5 6 7 8 9 10 11

Field No_Mhs Nama Tp_Lahir Tgl_Lahir Alamat_1 Alamat_2 Angkatan Kd_jurusan Kd_Dosen Telepon_1 Telepon_2

Type Alpha Alpha Alpha Date Alpha Alpha Alpha Alpha Alpha Alpha Alpha

Width 10 30 10 8 30 30 10 5 5 15 15

Keterangan Nomor induk mahasiswa Nama mahasiwa Tempat lahir Tanggal lahir Alamat tinggal Alamat asal Angkatan Kode jurusan Kode dosen Telepon kos Telepon asal

Tabel 4.18: Dosen (Rahayuningsih, 2000, hal: 15) No. 1 2 3 4 5

Field Kd_Dosen Nm_Dosen Alamat Golongan Telepon

Type Alpha Alpha Alpha Alpha Alpha

Width 5 30 30 4 15

Keterangan Kode dosen Nama dosen Alamat Golongan Telepon

Key PK

Tabel 4.19: Makul (Rahayuningsih, 2000, hal: 15) No. 1 2 3 4 5

Field Kode_Mtk Nama_Mtk Smt Sks Jenis

Type Alpha Alpha Num Num Alpha

Width 7 30 2 2 30

Keterangan Kode mata kuliah Nama mata kuliah Semester SKS Jenis mata kuliah

Key PK

Key PK

192

6

Kd_Jurusan

Alpha

5

Kode jurusan

Tabel 4.20: Krs (Rahayuningsih, 2000, hal: 15) No. 1 2 3 4 5

Field No_Mhs Smt Kode_Mtk Nilai Huruf

Type Alpha Num Alpha Num Alpha

Width 10 2 7 3 1

Keterangan Nomor induk mahasiswa Semester Kode mata kuliah Nilai angka Nilai huruf

Key PK

Tabel 4.21: Bidang (Rahayuningsih, 2000, hal: 16) No. 1 2

Field Kd_Dosen Kode_Mtk

Type Alpha Alpha

Width 5 7

Keterangan Kode dosen Kode mata kuliah

Key PK

Tabel 4.22: Jurusan (Rahayuningsih, 2000, hal: 16) No. 1 2

Field Kd_Jurusan Jurusan

Type Alpha Alpha

Width 6 30

Keterangan Kode jurusan Kode mata kuliah

Key PK

Selanjutnya, secara berturut-turut data rancangan struktur tabel database yang dianalisis, adalah ditunjukkan dalam Lampiran 10 hingga Lampiran 18.

4.1.6.3.

Data Penelitian Kelompok Ketiga Rancangan struktur tabel database untuk SIAKAD Kelompok Ketiga

diperoleh dari hasil penelitian Tugas Akhir yang pernah dilakukan oleh mahasiswa Program Diploma-3, Program Studi Manajemen Infomatika & Teknik Komputer, Institut Sains & Teknologi AKPRIND, Yogyakarta. Rancangan struktur tabel database Kelompok Ketiga yang akan dianalisis dalam penelitian ini sebanyak 8 (delapan) buah rancangan. Data rancangan struktur tabel database pertama yang dianalisis, adalah hasil penelitian yang dilakukan oleh Elfi Yulia (2000) berjudul Sistem Komputerisasi

193

Pengolahan Data Penerimaan Mahasiswa di STT Komp. “TAKASINDO” Yogyakarta, selanjutnya disebut DATA_06_001, dengan detail sebagai berikut: Nama peneliti Judul Penelitian Tahun Jumlah tabel database Jumlah atribut Pada halaman

: Elfi Yulia : Sistem Komputerisasi Pengolahan Data Penerimaan Mahasiswa di STT Komp. “TAKASINDO” Yogyakarta : 2000 :7 : 32 : 38 - 40

Desain struktur tabel database yang dihasilkan secara berturut-turut ditampilkan dalam Tabel 4.23 hingga Tabel 4.29. Tabel 4.23: FMHS (Yulia, 2000, hal: 38) No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Field NIM Nama Jkel Agama TpLahir TglLahir AsalSkl AlamatSkl Ayah Alm1 Ibu Alm2 Wali Alm3 AlmSkr KDJ

Type Char Char Char Char Char Date Char Char Char Char Char Char Char Char Char Char

Width 12 24 1 1 20 8 24 60 24 1 24 1 24 1 30 2

Keterangan Nomor mahasiswa Nama mahasiswa Jenis kelamin Agama Tempat lahir Tanggal lahir Asal sekolah Alamat asal sekolah Nama ayah Alamat ayah Nama ibu Alamat ibu Nama wali Alamat wali Alamat sekarang Kode jurusan

Tabel 4.24: FJURUSAN (Yulia, 2000, hal: 39) No. 1 2

Field KDJ NmJur

Type Char Char

Width 2 25

Keterangan Kode jurusan Nama jurusan

Key PK

Tabel 4.25: FDOSEN (Yulia, 2000, hal: 39) No. 1 2 3

Field KDDosen Nama KDJ

Type Char Char Char

Width 3 24 2

Keterangan Kode dosen Nama dosen Kode jurusan

Key PK PK

Key PK

PK

194

Tabel 4.26: FMTKDOSEN (Yulia, 2000, hal: 39) No. 1 2

Field KDDosen KDM

Type Char Char

Width 3 6

Keterangan Kode dosen Kode mata kuliah

Key PK PK

Tabel 4.27: FMTKULIAH (Yulia, 2000, hal: 39) No. 1 2 3 4

Field KDM Mkuliah SKS Semester

Type Char Char Num Num

Width 3 25 1 1

Keterangan Kode mata kuliah Nama mata kuliah SKS Semester

Key PK

Tabel 4.28: FPAKET (Yulia, 2000, hal: 40) No. 1 2

Field KDJ KDM

Type Char Char

Width 2 3

Keterangan Kode jurusan Kode mata kuliah

Key PK PK

Tabel 4.29: FKRS (Yulia, 2000, hal: 40) No. 1 2 3

Field NIM KDM Nilai

Type Char Char Char

Width 12 3 1

Keterangan Nomor mahasiswa Kode mata kuliah Nilai

Key PK PK

Selanjutnya, secara berturut-turut data rancangan struktur tabel database yang dianalisis, adalah ditunjukkan dalam Lampiran 19 hingga Lampiran 25.

4.1.7. Penilaian Untuk Analisis Fleksibilitas Rancangan Struktur Tabel Database Analisis fleksibilitas rancangan struktur tabel database untuk SIAKAD dilakukan sesuai dengan metodologi penelitian yang telah ditetapkan. Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_09_001 ditunjukkan pada Tabel 4.30. Selanjutnya, secara berturut-turut penilaian untuk analisis fleksibilitas rancangan struktur tabel database ditunjukkan dalam Lampiran 26 hingga Lampiran 52.

195

Tabel 4.30: Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_09_001 No

Tabel

Atribut

Tipe-Ukuran

Key

1.

Mata_Kuliah

Dosen

Char(8) Char(30) Char(1) VarChar(200) Char(9) Char(20) Date(8) Char(30) Char(30) Char(25) Char(12) Char(15) Char(5) Char(4) Char(15) Char(30) Char(30) Char(30) Char(30) Char(10) Char(9) Char(10) Char(20) Char(20) Num(3) Num(2) Num(4,2) Logic(1) Date(8) Char(20) Char(10) Char(2)

PK

2.

Kode Nm_kuliah Sks Referensi NIP_Dosen Nama Tanggal_lahir Tempat_lahir Alamat Bidang Foto Pendidikan No_mahasiswa Tahun_angkatan Fakultas Nama Nama_ayah Nama_ibu Nama_wali Program_studi Nip_dosen_wali Jurusan Alamat_jogja Alamat_asal Jml_sks_ditempuh Jml_sks_diambil IP_komulatif Jenis_kelamin Tanggal_lahir Tempat_lahir Agama Golongan_darah

3.

Mahasiswa

Null

Yes

Default

Null

PK Yes Yes Yes Yes

Null Null Null Null

PK

Yes Yes Yes

Null Null Null

Yes Yes

Null Null

Yes

Null

Kemungkinan Fleksibel Berubah [Y/T] [Y/T] Y T T Y T Y Y T T Y T Y T Y T Y Y T Y T T Y Y T Y T T Y Y T T Y T Y T Y T Y Y T T Y T T Y T Y T T T T T T T T Y T Y T Y T T T Y

Penjelasan ƒ Nilai-nilai kode dalam Kode perlu dipisah dan dibuat tabel referensi ƒ Referensi perlu dikodekan dan dibuat tabel referensi, jika Referensi > 1 perlu disimpan dalam tabel terpisah • • •

• • • • • • • • • • •

Kecamatan, Kabupaten, Propinsi dalam Alamat perlu dikodekan dan dibuat tabel referensi Bidang perlu dikodekan dan dibuat tabel referensi Pendidikan perlu dikodekan dan dibuat tabel referensi

Nilai-nilai kode dalam No_mahasiswa perlu dipisah dan dibuat tabel referensi Fakultas perlu dikodekan dan dibuat tabel referensi Program_studi perlu dikodekan dan dibuat tabel referensi Jurusan perlu dikodekan dan dibuat tabel referensi Kecamatan, Kabupaten, Propinsi dalam Alamat_asal perlu dikodekan dan dibuat tabel referensi Kecamatan, Kabupaten dalam Alamat_jogja perlu dikodekan dan dibuat tabel referensi Jml_sks_ditempuh perlu disimpan dalam tabel terpisah Jml_sks_diambil perlu disimpan dalam tabel terpisah IP_komulatif tidak perlu disimpan, perlu tabel transaksi perolehan nilai mata kuliah Agama perlu dikodekan dan dibuat tabel referensi Hobi perlu dikodekan dan dibuat tabel referensi

196

4.

Mengajar

5.

Medis

6.

7.

8.

9.

10.

Pustaka

Keamanan

Beasiswa

UPT

Koperasi

Telepon Hobi NIP_Dosen Kode_kuliah Semester No_mahasiswa Penyakit_1 Penyakit_2 Penyakit_3 Penyakit_4 Penyakit_5 Opname Dokter_pribadi Rumah_sakit_rujukan

Char(15) VarChar(30) Char(20) Char(8) Char(1) Char(5) Char(15) Char(15) Char(15) Char(15) Char(15) Logic(1) Char(15) Char(20)

Yes Yes

No_mahasiswa Kode_buku Judul_buku Pengarang Tanggal_pinjam Tanggal_kembali Petugas No_mahasiswa No_masalah Kriteria_masalah Sangsi No_mahasiswa Kode_beasiswa Tahun Nama_beasiswa

Char(5) Char(15) Char(50) Char(30) Date(8) Date(8) Char(15) Char(5) Char(15) Char(15) Char(15) Char(5) Char(15) Date(8) Char(15)

PK

No_mahasiswa Kode_layanan Jenis_layanan Keterangan No_mahasiswa Kode_angota Jumlah_pinjam

Char(5) Char(15) Char(15) Char(15) Char(5) Char(6) Num(10)

PK PK

Null Null

PK PK Yes

Null

PK

Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

Null Null Null Null Null Null Null Null Null Null

PK PK Yes Yes

Null Null

PK PK Yes Yes

Yes Yes

Null Null

Null Null

PK PK Yes

Null

T T T Y T T T T T T T T T T

Y T Y T Y T Y T T T T Y Y T

Y Y T T T T T Y T Y Y Y Y T Y

Y Y Y Y Y Y T

•

Nilai-nilai kode dalam Kode_kuliah perlu dipisah dan dibuat tabel referensi

• • • • • •

Nilai-nilai kode dalam No_mahasiswa perlu dipisah dan dibuat tabel referensi Rumah_sakit_rujukan perlu dikodekan dan dibuat tabel referensi Struktur Penyakit_2 perlu dirubah menjadi vertikal Struktur Penyakit_3 perlu dirubah menjadi vertikal Struktur Penyakit_4 perlu dirubah menjadi vertikal Struktur Penyakit_5 perlu dirubah menjadi vertikal

T T Y T Y Y T T Y T Y T T Y T

• • • • •

Nilai-nilai kode dalam No_mahasiswa perlu dipisah dan dibuat tabel referensi Nilai-nilai kode dalam Kode_buku perlu dipisah dan dibuat tabel referensi Judul_buku perlu disimpan dalam tabel terpisah Pengarang perlu dikodekan dan dibuat tabel referensi Petugas perlu dikodekan dan dibuat tabel referensi

• •

Nilai-nilai kode dalam No_mahasiswa perlu dipisah dan dibuat tabel referensi Kriteria_masalah perlu dikodekan dan dibuat tabel referensi

• • •

Nilai-nilai kode dalam No_mahasiswa perlu dipisah dan dibuat tabel referensi Kode_beasiswa perlu tabel referensi Nama_beasiswa perlu dikodekan dan dibuat tabel referensi

T T T Y T T Y

• • •

Nilai-nilai kode dalam No_mahasiswa perlu dipisah dan dibuat tabel referensi Kode_layanan perlu tabel referensi Jenis_layanan perlu tabel referensi

• •

Nilai-nilai kode dalam No_mahasiswa perlu dipisah dan dibuat tabel referensi Nilai-nilai kode dalam No_anggota perlu dipisah dan dibuat tabel referensi

197

4.1.8.

Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Berdasarkan penilaian-penilaian yang telah diberikan sebagaimana

ditunjukkan Tabel 4.30 dan Lampiran 26 hingga Lampiran 52, selanjutnya dengan menggunakan pendekatan Penilaian Acuan Pokok (=PAP), diperoleh informasi tingkat fleksibilitas untuk setiap rancangan struktur tabel database yang dianalisis sebagaimana ditampilkan dalam Tabel 4.31. Tabel 4.31: Daftar hasil analisis fleksibilitas rancangan struktur tabel database keseluruhan No

Data

Jumlah Tabel

Keseluruhan

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

Data_09_001 Data_09_002 Data_09_003 Data_09_004 Data_09_005 Data_09_006 Data_09_007 Data_09_008 Data_09_010 Data_08_001 Data_08_002 Data_08_003 Data_08_004 Data_08_005 Data_08_006 Data_08_007 Data_08_008 Data_08_009 Data_08_010 Data_06_001 Data_06_002 Data_06_003 Data_06_004 Data_06_005 Data_06_006 Data_06_007 Data_06_008 JUMLAH:

10 19 10 24 8 8 5 34 8 6 4 9 5 6 5 5 10 10 5 7 7 6 7 12 9 14 3 256

68 259 137 162 28 66 44 351 51 31 67 36 37 28 18 22 33 68 43 32 38 22 31 53 51 62 27 1.865

Jumlah Atribut Tidak Fleksibel Jumlah % 35 51,47% 49 18,92% 89 64,96% 17 10,49% 6 21,43% 21 31,82% 17 38,64% 186 52,99% 11 21,57% 11 35,48% 20 29,85% 15 41,67% 18 48,65% 13 46,43% 7 38,89% 8 36,36% 8 24,24% 25 36,76% 20 46,51% 9 28,13% 9 23,68% 3 13,64% 8 25,81% 18 33,96% 16 31,37% 19 30,65% 12 44,44% 670

Fleksibel Jumlah % 33 48,53% 210 81,08% 48 35,04% 145 89,51% 22 78,57% 45 68,18% 27 61,36% 165 47,01% 40 78,43% 20 64,52% 47 70,15% 21 58,33% 19 51,35% 15 53,57% 11 61,11% 14 63,64% 25 75,76% 43 63,24% 23 53,49% 23 71,88% 29 76,32% 19 86,36% 23 74,19% 35 66,04% 35 68,63% 43 69,35% 15 55,56% 1.195

Tingkat Fleksibilitas Sedang Sangat Baik Buruk Sangat Baik Baik Baik Baik Sedang Baik Baik Baik Sedang Sedang Sedang Baik Baik Baik Baik Sedang Baik Baik Sangat Baik Baik Baik Baik Baik Sedang

198

4.2. Pembahasan 4.2.1. Statistik Tingkat Fleksibilitas Rancangan Struktur Tabel Database Berdasarkan informasi yang diperoleh dalam Tabel 4.31, dapat diketahui statistik hasil analisis fleksibilitas rancangan struktur tabel database berdasarkan tingkat fleksibilitas seperti ditampilkan dalam Tabel 4.32. Tabel 4.32: Statistik hasil analisis fleksibilitas rancangan struktur tabel database berdasarkan tingkat fleksibilitas No

Tingkat Fleksibilitas

Data Rancangan

Tabel

Atribut

3 16 7 1 0 27

49 125 72 10 0 256

443 695 590 137 0 1.865

1 Sangat Baik 2 Baik 3 Sedang 4 Buruk 5 Sangat Buruk JUMLAH:

Jumlah Atribut Tidak Fleksibel Jumlah % 69 15,58 213 30,65 299 50,68 89 64,96 0 0 670

Atribut Fleksibel Jumlah % 374 84,42 482 69,35 291 49,32 48 35,04 0 0 1.195

Berdasarkan informasi dalam Tabel 4.32, dapat diketahui tentang beberapa hal, yaitu jumlah rancangan struktur tabel database yang dianalisis adalah sebanyak 28 (dua puluh delapan), terdiri atas: 1. Jumlah rancangan struktur tabel database yang memiliki tingkat fleksibilitas SANGAT BAIK sebanyak 3 (tiga) buah rancangan, memiliki: a. Jumlah tabel

: 49

b. Jumlah atribut

: 443

1). Jumlah atribut tidak fleksibel

: 69 (=15,58%)

2). Jumlah atribut fleksibel

: 374 (=84,42%)

2. Jumlah rancangan struktur tabel database yang memiliki tingkat fleksibilitas BAIK sebanyak 16 (enam belas) buah rancangan, memiliki:

199

a. Jumlah tabel

: 125

b. Jumlah atribut

: 695

1). Jumlah atribut tidak fleksibel

: 213 (=30,65%)

2). Jumlah atribut fleksibel

: 482 (=69,35%)

3. Jumlah rancangan struktur tabel database yang memiliki tingkat fleksibilitas SEDANG sebanyak 7 (tujuh) buah rancangan, memiliki: a. Jumlah tabel

: 72

b. Jumlah atribut

: 590

1). Jumlah atribut tidak fleksibel

: 299 (=50,68%)

2). Jumlah atribut fleksibel

: 291 (=49,32%)

4. Jumlah rancangan struktur tabel database yang memiliki tingkat fleksibilitas BURUK sebanyak 1 (satu) buah rancangan, memiliki: a. Jumlah tabel

: 10

b. Jumlah atribut

: 137

1). Jumlah atribut tidak fleksibel

: 89 (=64,96%)

2). Jumlah atribut fleksibel

: 48 (=35,04%)

5. Tidak ada rancangan struktur tabel database yang memiliki tingkat fleksibilitas SANGAT BURUK. 6. Terdapat sebanyak 1 (satu) buah rancangan yang tidak dapat dianalisis, karena tidak ada detail keterangan tentang isi atribut dalam rancangan struktur tabel database, yaitu DATA_09_009, memiliki jumlah tabel sebanyak 6 (enam) buah, dan jumlah atribut sebanyak 41 buah.

200

Sedangkan, statistik hasil analisis fleksibilitas rancangan struktur tabel database berdasarkan pendidikan perancang ditampilkan dalam Tabel 4.33. Tabel 4.33: Statistik hasil analisis fleksibilitas rancangan struktur tabel database berdasarkan pendidikan perancang No

Pendidikan Perancang

1 2 3 4 JUMLAH:

Data Rancangan

Tabel

Atribut

0 9 10 8 27

0 126 65 65 256

0 1166 383 316 1.865

S3 S2 S1 D3

Jumlah Atribut Tidak Fleksibel Jumlah % 0 0,0 431 36,96 145 37,86 94 29,75 670

Atribut Fleksibel Jumlah % 0 0,00 735 63,04 238 62,14 222 70,25 1.195

Berdasarkan informasi dalam Tabel 4.33, dapat diketahui tentang beberapa hal, yaitu jumlah rancangan struktur tabel database yang dianalisis adalah sebanyak 28 (dua puluh delapan), terdiri atas: 1. Tidak ada rancangan struktur tabel database yang dirancang oleh perancang dengan pendidikan S3. 2. Jumlah rancangan struktur tabel database yang dirancang oleh perancang dengan pendidikan S2 sebanyak 10 (sepuluh) buah rancangan, memiliki: a. Jumlah tabel

: 132

b. Jumlah atribut

: 1207

c. Tidak dapat dianalisis

: 6 tabel, 41 atribut

1). Jumlah atribut tidak fleksibel

: 431 (=36,96%)

2). Jumlah atribut fleksibel

: 735 (=63,04%)

3. Jumlah rancangan struktur tabel database yang dirancang oleh perancang dengan pendidikan S1 sebanyak 10 (sepuluh) buah rancangan, memiliki: a. Jumlah tabel

: 65

b. Jumlah atribut

: 383

201

1). Jumlah atribut tidak fleksibel

: 145 (=37,86%)

2). Jumlah atribut fleksibel

: 238 (=62,14%)

4. Jumlah rancangan struktur tabel database yang dirancang oleh perancang dengan pendidikan D3 sebanyak 8 (delapan) buah rancangan, memiliki: a. Jumlah tabel

: 65

b. Jumlah atribut

: 316

1). Jumlah atribut tidak fleksibel

: 94 (=29,75%)

2). Jumlah atribut fleksibel

: 222 (=70,25%)

Akhirnya, statistik hasil analisis fleksibilitas rancangan struktur tabel database dalam bentuk rekapitulasi keseluruhan ditunjukkan pada Tabel 4.34. Tabel 4.34: Statistik hasil analisis fleksibilitas rancangan struktur tabel database rekapitulasi keseluruhan No 1 2 3 4

Pendidikan Perancang S3 S2 S1 D3 JUMLAH:

Jumlah Data Rancangan 0 9 10 8 27

Sangat Baik Jumlah % 0 0 2 22,22 0 0 1 12,50 3

Baik Jumlah % 0 0 4 44,44 6 60,00 6 75,00 16

Tingkat Fleksibilitas Sedang Buruk Jumlah % Jumlah % 0 0 0 0 2 22,22 1 11,11 4 40,00 0 0 1 12,50 0 0 7 1

Sangat Buruk Jumlah % 0 0 0 0 0 0 0 0 0

Berdasarkan informasi dalam Tabel 4.34, dapat diketahui tentang beberapa hal, yaitu jumlah rancangan struktur tabel database yang dapat dianalisis adalah sebanyak 28 (dua puluh delapan), terdiri atas: 1. Jumlah rancangan struktur tabel database yang dirancang oleh perancang dengan pendidikan S2 sebanyak 10 (sepuluh) buah rancangan, dengan tingkat fleksibilitas sebagai berikut: a. Jumlah tingkat fleksibilitas SANGAT BAIK

: 2 (=22,22%)

b. Jumlah tingkat fleksibilitas BAIK

: 4 (=44,44%)

202

c. Jumlah tingkat fleksibilitas SEDANG

: 2 (=22,22%)

d. Jumlah tingkat fleksibilitas BURUK

: 1 (=11,11%)

e. Jumlah tingkat fleksibilitas SANGAT BURUK : 0 (=0,00%) f. Tidak dapat dianalisis

:1

2. Jumlah rancangan struktur tabel database yang dirancang oleh perancang dengan pendidikan S1 sebanyak 10 (sepuluh) buah rancangan, dengan tingkat fleksibilitas sebagai berikut: a. Jumlah tingkat fleksibilitas SANGAT BAIK

: 0 (=0,00%)

b. Jumlah tingkat fleksibilitas BAIK

: 4 (=40,00%)

c. Jumlah tingkat fleksibilitas SEDANG

: 6 (=60,00%)

d. Jumlah tingkat fleksibilitas BURUK

: 0 (=0,00%)

e. Jumlah tingkat fleksibilitas SANGAT BURUK : 0 (=0,00%) 3. Jumlah rancangan struktur tabel database yang dirancang oleh perancang dengan pendidikan D3 sebanyak 8 (delapan) buah rancangan, dengan tingkat fleksibilitas sebagai berikut: a. Jumlah tingkat fleksibilitas SANGAT BAIK

: 1 (=12,50%)

b. Jumlah tingkat fleksibilitas BAIK

: 6 (=75,00%)

c. Jumlah tingkat fleksibilitas SEDANG

: 1 (=12,50%)

d. Jumlah tingkat fleksibilitas BURUK

: 0 (=0,00%)

e. Jumlah tingkat fleksibilitas SANGAT BURUK : 0 (=0,00%)

203

4.2.2. Identifikasi Penyebab Rancangan Struktur Tabel Database Tidak Fleksibel Mengacu pada hasil penelitian yang dilakukan oleh Brian Mullen (2005), diketahui bahwa perbedaan tingkat kepakaran perancang database dan perbedaan kebutuhan para pengguna merupakan penyebab utama rancangan database tidak dapat bersifat fleksibel. Rancangan database yang tidak fleksibel akan memberikan dampak pada dana dan waktu untuk pemeliharaan database. Jika rancangan struktur database tidak baik, tetapi tidak dirasakan adanya permasalahan, maka yang terbaik dilakukan adalah segera memulai merencanakan untuk merubah struktur database. Sebuah rancangan struktur tabel database sebagai hasil buah pikir manusia (perancang) tentu tidak akan mampu mengatasi semua permasalahan, terbebas dari adanya kelemahan, dan memenuhi semua bentuk perubahan kebutuhan informasi (dan data) untuk jangka kurun waktu yang tak terbatas. Sebuah rancangan database dibuat untuk semaksimal mungkin memenuhi kebutuhan seluruh pengguna pada semua level manajemen dan pada semua unit fungsional untuk jangka waktu yang panjang, hingga puluhan tahun. Dalam kenyataannya, kebutuhan informasi (dan data) untuk para pengguna akan berubah, sehingga fleksibilitas rancangan struktur tabel database merupakan aspek yang penting. Lauri Pietarinen ([email protected]) menyebutkan, bahwa fleksibilitas struktur database terkait dengan 3 (tiga) aspek, yaitu: 1. Isolasi data dalam database, yaitu kopel antar tabel dalam database.

204

2. Penggunaan pendekatan dalam struktur data. Penggunaan XML (yang merupakan pendekatan tidak terstruktur atau semi-terstruktur dimana sebuah file dapat memuat berbagai macam nilai yang dituliskan di antara tanda tag) akan menemui permasalahan jika file memuat tag tidak dikenali oleh aplikasi. Sehingga di kemudian hari perlu menginvetarisasi kembali tentang konteks data dan sekaligus menjadi alasan mengapa sebaiknya kembali saja ke data terstruktur menggunakan tabel. Hal ini merupakan sebuah alasan, bahwa RDBM merupakan pendekatan paling umum untuk perancangan schema suatu database. 3. Penggunaan tipe data dalam schema tabel database. Permasalahannya adalah apakah semua tipe data harus didefinisikan secara eksplisit dalam struktur tabel atau dapat disembunyikan. Analisis lebih lanjut dalam penelitian ini akan dilakukan untuk mengidentifikasi faktor-faktor penyebab rancangan struktur tabel database tidak fleksibel terhadap perubahan kebutuhan informasi (dan data). Daftar faktor penyebab rancangan struktur tabel database tidak fleksibel pada setiap data yang dianalisis dalam kondisi telah diurutkan berdasarkan abjad paling awal dan dihilangkan faktor-faktor yang persis sama ditampilkan pada Tabel 4.35.

205

Tabel 4.35: Daftar faktor penyebab rancangan struktur tabel database tidak fleksibel pada setiap data yang dianalisis No 1.

Tabel DATA_09_001

Penjelasan Agama perlu dikodekan dan dibuat tabel referensi • Bidang perlu dikodekan dan dibuat tabel referensi • Fakultas perlu dikodekan dan dibuat tabel referensi • Hobi perlu dikodekan dan dibuat tabel referensi • IP_komulatif tidak perlu disimpan, perlu tabel transaksi perolehan nilai mata kuliah • Jenis_layanan perlu tabel referensi • Jml_sks_diambil perlu disimpan dalam tabel terpisah • Jml_sks_ditempuh perlu disimpan dalam tabel terpisah • Jurusan perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten dalam Alamat_jogja perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam Alamat perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam Alamat_asal perlu dikodekan dan dibuat tabel referensi • Kode_beasiswa perlu tabel referensi • Kode_layanan perlu tabel referensi • Kriteria_masalah perlu dikodekan dan dibuat tabel referensi • Nama_beasiswa perlu dikodekan dan dibuat tabel referensi • Nilai-nilai kode dalam Kode perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Kode_buku perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Kode_kuliah perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam No_anggota perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam No_mahasiswa perlu dipisah dan dibuat tabel referensi • Pendidikan perlu dikodekan dan dibuat tabel referensi • Pengarang perlu dikodekan dan dibuat tabel referensi • Petugas perlu dikodekan dan dibuat tabel referensi • Program_studi perlu dikodekan dan dibuat tabel referensi • Referensi perlu dikodekan dan dibuat tabel referensi, jika Referensi > 1 perlu disimpan dalam tabel terpisah • Rumah_sakit_rujukan perlu dikodekan dan dibuat tabel referensi • Struktur Penyakit_2 perlu dirubah menjadi vertikal • Struktur Penyakit_3 perlu dirubah menjadi vertikal • Struktur Penyakit_4 perlu dirubah menjadi vertikal •

206

• Struktur Penyakit_5 perlu dirubah menjadi vertikal

2.

DATA_09_002

• AGAMA perlu tabel referensi • BAGIAN perlu tabel referensi • DOSEN_WL perlu tabel referensi • GOL_AYAH perlu tabel referensi • GOL_IBU perlu tabel referensi • JALUR_MASUK perlu tabel referensi • JBT_AYAH perlu tabel referensi • JBT_IBU perlu tabel referensi • JENIS kota perlu tabel referensi • JENIS_LNG perlu tabel referensi • JURUSAN perlu tabel referensi • KARY_TYPE perlu tabel referensi • Kecamatan, Kabupaten, Propinsi dalam ALAMAT perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam ALAMAT_2 perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam ALMT_INST_AYAH perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam ALMT_INST_IBU perlu dikodekan dan dibuat tabel referensi • KELOMPOK perlu dikodekan dan dibuat tabel referensi • KERJA_AYAH perlu tabel referensi • KERJA_IBU perlu tabel referensi • KET perlu tabel referensi • KODE_SIE perlu tabel referensi • Nilai-nilai kode dalam ID perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam MHS_NIM perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam NIM perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam NO_TEST perlu dipisah dan dibuat tabel referensi • PDK_AYAH perlu tabel referensi • PDK_IBU perlu tabel referensi • PRASYARAT cukup menggunakan ID mata kuliah • RUANG_ID perlu tabel referensi • STATUS perlu tabel referensi • STS_HADIR perlu dikodekan dan dibuat tabel referensi

207

• STS_MK perlu tabel referensi • STS_PNG perlu tabel referensi • STS_UJIAN perlu tabel referensi

3.

DATA_09_003

• Agama

mengalami redudansi dengan tabel CalonMhs perlu dikodekan dan dibuat tabel referensi • Agama mengalami redudansi dengan tabel CalonMhs • Agama mengalami redudansi dengan tabel CalonMhs dan Mhs • Alamat mengalami redudansi dengan tabel CalonMhs • Alamat mengalami redudansi dengan tabel CalonMhs dan Mhs • Alamat_ot mengalami redudansi dengan tabel CalonMhs • Alamat_SMA mengalami redudansi dengan tabel CalonMhs • Alm_biaya mengalami redudansi dengan tabel CalonMhs • Asal_biaya mengalami redudansi dengan tabel CalonMhs • Asal_biaya perlu tabel referensi • Bangsa mengalami redudansi dengan tabel CalonMhs • Bangsa perlu tabel referensi • J_kelamin mengalami redudansi dengan tabel CalonMhs • J_kelamin perlu tabel referensi • Jabatan perlu tabel referensi • Jenis_SMA mengalami redudansi dengan tabel CalonMhs • Jenis_SMA mengalami redudansi dengan tabel CalonMhs dan Mhs • Jenis_SMA perlu tabel referensi • Jurusan mengalami redudansi dengan tabel CalonMhs • Jurusan perlu dikodekan dan dibuat tabel referensi • Kab_kodya mengalami redudansi dengan tabel CalonMhs • Kab_kodya perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten dalam Alamat perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten dalam Alamat_ot perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam Alamat_SMA perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam Alm_biaya perlu dikodekan dan dibuat tabel referensi • Nama mengalami redudansi dengan tabel CalonMhs • Nama mengalami redudansi dengan tabel CalonMhs dan Mhs • Agama

208

• NamaAyah mengalami redudansi dengan tabel CalonMhs • NamaIbu mengalami redudansi dengan tabel CalonMhs • NEM_SMA mengalami redudansi dengan tabel CalonMhs • Nilai-nilai kode dalam No_calon perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam No_mhs perlu dipisah dan dibuat tabel referensi • No_Ijz_SMA mengalami redudansi dengan tabel CalonMhs • Pekerjaan mengalami redudansi dengan tabel CalonMhs • Pekerjaan perlu tabel referensi • Penasehat perlu dikodekan dan dibuat tabel referensi • Prop_SMA mengalami redudansi dengan tabel CalonMhs • Prop_SMA perlu dikodekan dan dibuat tabel referensi • Propinsi mengalami redudansi dengan tabel CalonMhs • Propinsi mengalami redudansi dengan tabel CalonMhs dan Mhs • Propinsi perlu dikodekan dan dibuat tabel referensi • SMA_asal mengalami redudansi dengan tabel CalonMhs • SMA_asal mengalami redudansi dengan tabel CalonMhs dan Mhs • SMA_asal perlu dikodekan dan dibuat tabel referensi • Status_akad perlu dikodekan dan dibuat tabel referensi • Status_daft perlu dikodekan dan dibuat tabel referens • Suku mengalami redudansi dengan tabel CalonMhs • Suku perlu tabel referensi • Tgl_lahir mengalami redudansi dengan tabel CalonMhs • Tgl_lahir mengalami redudansi dengan tabel CalonMhs dan Mhs • Thn_Ijz_SMA mengalami redudansi dengan tabel CalonMhs • Tmp_lahir mengalami redudansi dengan tabel CalonMhs • Tmp_lahir mengalami redudansi dengan tabel CalonMhs dan Mhs

4.

DATA_09_004

• jenis perlu tabel referensi • kategori_id perlu tabel referensi • kelp perlu dikodekan dan dibuat tabel referensi • kode_prop perlu tabel referensi • kode_prop2 perlu tabel referensi • kota cukup menggunakan FK

209

• Nilai-nilai kode dalam no_anggota perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam nomhs perlu dipisah dan dibuat tabel referensi • penerbit perlu tabel referensi • pengarang perlu dikodekan dan dibuat tabel referensi • st_anggota perlu tabel referensi • sumber perlu dikodekan dan dibuat tabel referensi

5.

DATA_09_005

• Gol perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam Alamat perlu dikodekan dan dibuat tabel referensi • LokasiKuliah_id perlu tabel referensi • Nilai-nilai kode dalam KodeMataKuliah perlu dipisah dan dibuat tabel referensi

6.

DATA_09_006

• Agama perlu dikodekan dan dibuat tabel referensi • Asal_sekolah perlu dikodekan dan dibuat tabel referensi • Golongan_darah perlu dikodekan • Jabatan perlu dikodekan dan dibuat tabel referensi • Jenis_kelamin perlu dikodekan • Kecamatan, Kabupaten, Propinsi dalam Alamat perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam Alamat_ortu dikodekan dan dibuat tabel referensi • Kelompok perlu dikodekan dan dibuat tabel referensi • LokasiKuliah_id perlu tabel referensi • Nilai-nilai kode dalam Kode_matakuliah perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam NIIM perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Prasyarat perlu dipisah dan dibuat tabel referensi • Pangkat perlu dikodekan dan dibuat tabel referensi • Pekerjaan_ortu perlu dikodekan dan dibuat tabel referensi • Pendidikan perlu dikodekan dan dibuat tabel referensi • Status perlu dikodekan dan dibuat tabel referensi • Status_Dosen perlu dikodekan dan dibuat tabel referensi

7.

DATA_09_007

• agama perlu dikodekan dan dibuat tabel referensi • Jenis_kel perlu dikodekan • jur_sekasal perlu dikodekan dan dibuat tabel referensi • jurusan perlu dikodekan dan dibuat tabel referensi

210

• Kecamatan, Kabupaten dalam alam_yk perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam alam_asal perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam alam_ot perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam alam_sekasal perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam alamat perlu dikodekan dan dibuat tabel referensi • ket perlu tabel referensi • Nilai-nilai kode dalam NIM perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam no_daft perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam no_kunj perlu dipisah dan dibuat tabel referensi • peker_ay perlu dikodekan dan dibuat tabel referensi • peker_ib perlu dikodekan dan dibuat tabel referensi • sek_asal perlu dikodekan dan dibuat tabel referensi • status perlu dikodekan dan dibuat tabel referensi

8.

DATA_09_008

• A1 perlu dirubah menjadi vertikal • A2 perlu dirubah menjadi vertikal • AsalPT perlu tabel referensi • B10a perlu dirubah menjadi vertikal • B10b perlu dirubah menjadi vertikal • B11a perlu dirubah menjadi vertikal • B11b perlu dirubah menjadi vertikal • B11c perlu dirubah menjadi vertikal • B12a1 perlu dirubah menjadi vertikal • B12a2 perlu dirubah menjadi vertikal • B12a3 perlu dirubah menjadi vertikal • B13 perlu dirubah menjadi vertikal • B14 perlu dirubah menjadi vertikal • B15 perlu dirubah menjadi vertikal • B16 perlu dirubah menjadi vertikal • B17a perlu dirubah menjadi vertikal • B17b perlu dirubah menjadi vertikal • B18a perlu dirubah menjadi vertikal

211

• B18b perlu dirubah menjadi vertikal • B18c perlu dirubah menjadi vertikal • B18d perlu dirubah menjadi vertikal • B19a perlu dirubah menjadi vertikal • B19b perlu dirubah menjadi vertikal • B1a perlu dirubah menjadi vertikal • B1b perlu dirubah menjadi vertikal • B1c perlu dirubah menjadi vertikal • B1d perlu dirubah menjadi vertikal • B20 perlu dirubah menjadi vertikal • B20b perlu dirubah menjadi vertikal • B2a perlu dirubah menjadi vertikal • B2b perlu dirubah menjadi vertikal • B3 perlu dirubah menjadi vertikal • B5a1 perlu dirubah menjadi vertikal • B5a2 perlu dirubah menjadi vertikal • B5b1 perlu dirubah menjadi vertikal • B5b2 perlu dirubah menjadi vertikal • B6 perlu dirubah menjadi vertikal • B7 perlu dirubah menjadi vertikal • B8a perlu dirubah menjadi vertikal • B8b perlu dirubah menjadi vertikal • B9a1 perlu dirubah menjadi vertikal • B9a2 perlu dirubah menjadi vertikal • B9b perlu dirubah menjadi vertikal • B9c perlu dirubah menjadi vertikal • B9d perlu dirubah menjadi vertikal • B9e perlu dirubah menjadi vertikal • bb4 perlu dirubah menjadi vertikal • Be perlu dirubah menjadi vertikal • Be perlu dirubah menjadi vertikal • Bidang perlu dikodekan dan dibuat tabel referensi

212

• Ddk_Akhr perlu tabel referensi • ED1 perlu dirubah menjadi vertikal • ED2 perlu dirubah menjadi vertikal • ED3 perlu dirubah menjadi vertikal • ED4 perlu dirubah menjadi vertikal • ED5 perlu dirubah menjadi vertikal • ED6 perlu dirubah menjadi vertikal • ED7 perlu dirubah menjadi vertikal • ED8 perlu dirubah menjadi vertikal • Fakultas perlu dikodekan dan dibuat tabel referensi • Instansi perlu dikodekan dan dibuat tabel referensi • Jabat_Akd perlu dikodekan dan dibuat tabel referensi • Jabatan1 perlu dikodekan dan dibuat tabel referensi • Jabatan2 perlu dikodekan dan dibuat tabel referensi • Jabatan3 perlu dikodekan dan dibuat tabel referensi • Jenis perlu dikodekan dan dibuat tabel referensi • Jenjang perlu dikodekan dan dibuat tabel referensi • JmlRuang2 perlu dirubah menjadi vertikal • Jurusan perlu dikodekan dan dibuat tabel referensi • Keahlian perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam Alamat perlu dikodekan dan dibuat tabel referensi • Kegiatan perlu dikodekan dan dibuat tabel referensi • Kelompok perlu dikodekan dan dibuat tabel referensi • KodePS rangkap dengan tabel Identitas_Program_Studi • Komponen perlu dikodekan dan dibuat tabel referensi • Leader perlu dirubah menjadi vertikal • Luas2 perlu dirubah menjadi vertikal • N10a perlu dirubah menjadi vertikal • N10b perlu dirubah menjadi vertikal • N11a perlu dirubah menjadi vertikal • N11c perlu dirubah menjadi vertikal • N12a1 perlu dirubah menjadi vertikal

213

• N12a2 perlu dirubah menjadi vertikal • N12a3 perlu dirubah menjadi vertikal • N13 perlu dirubah menjadi vertikal • N14 perlu dirubah menjadi vertikal • N15 perlu dirubah menjadi vertikal • N16 perlu dirubah menjadi vertikal • N17a perlu dirubah menjadi vertikal • N17b perlu dirubah menjadi vertikal • N18a perlu dirubah menjadi vertikal • N18b perlu dirubah menjadi vertikal • N18c perlu dirubah menjadi vertikal • N18d perlu dirubah menjadi vertikal • N19a perlu dirubah menjadi vertikal • N19b perlu dirubah menjadi vertikal • N1a perlu dirubah menjadi vertikal • N1b perlu dirubah menjadi vertikal • N1b perlu dirubah menjadi vertikal • N1c perlu dirubah menjadi vertikal • N1d perlu dirubah menjadi vertikal • N20 perlu dirubah menjadi vertikal • N20b perlu dirubah menjadi vertikal • N2a perlu dirubah menjadi vertikal • N2b perlu dirubah menjadi vertikal • N3 perlu dirubah menjadi vertikal • N4 perlu dirubah menjadi vertikal • N5a1 perlu dirubah menjadi vertikal • N5a2 perlu dirubah menjadi vertikal • N5b1 perlu dirubah menjadi vertikal • N5b2 perlu dirubah menjadi vertikal • N6 perlu dirubah menjadi vertikal • N7 perlu dirubah menjadi vertikal • N8a perlu dirubah menjadi vertikal

214

• N8b perlu dirubah menjadi vertikal • N9a1 perlu dirubah menjadi vertikal • N9a2 perlu dirubah menjadi vertikal • N9b perlu dirubah menjadi vertikal • N9c perlu dirubah menjadi vertikal • N9d perlu dirubah menjadi vertikal • N9e perlu dirubah menjadi vertikal • Nama perlu dikodekan dan dibuat tabel referensi • Nama1 cukup menggunakan FK • Nama2 tidak perlu disimpan • Nama3 tidak perlu disimpan • NamaPS rangkap dengan tabel Identitas_Program_Studi • P11 perlu dirubah menjadi vertikal • P12 perlu dirubah menjadi vertikal • P21 perlu dirubah menjadi vertikal • P22 perlu dirubah menjadi vertikal • P23 perlu dirubah menjadi vertikal • P31 perlu dirubah menjadi vertikal • P41 perlu dirubah menjadi vertikal • P42 perlu dirubah menjadi vertikal • P43 perlu dirubah menjadi vertikal • P44perlu dirubah menjadi vertikal • P51perlu dirubah menjadi vertikal • P52 perlu dirubah menjadi vertikal • Pembina perlu dikodekan dan dibuat tabel referensi, atau menggunakan FK • PT perlu dipisah • Sifat perlu tabel referensi • Status perlu tabel referensi • STS1 perlu dirubah menjadi vertikal • STS1_S perlu dirubah menjadi vertikal • STS2 perlu dirubah menjadi vertikal • Subkomponen perlu tabel referensi

215

• Sustain perlu dirubah menjadi vertikal • Tempat perlu dikodekan dan dibuat tabel referensi • Tingkat perlu dikodekan dan dibuat tabel referensi • TriDharma perlu tabel referensi • TS1 perlu dirubah menjadi vertikal • TS2 perlu dirubah menjadi vertikal • TS3 perlu dirubah menjadi vertikal • TS4 perlu dirubah menjadi vertikal • TS5 perlu dirubah menjadi vertikal • TS6 perlu dirubah menjadi vertikal • TS7 perlu dirubah menjadi vertikal • TS8 perlu dirubah menjadi vertikal • TTS1 perlu dirubah menjadi vertikal • TTS1_S perlu dirubah menjadi vertikal • TTS2 perlu dirubah menjadi vertikal • TTS2_S perlu dirubah menjadi vertikal

9. 10.

DATA_09_009 DATA_09_010

• Tidak dapat dianalisis karena tidak ada detail rancangan struktur tabel database • Agama

perlu tabel referensi

• HM tidak perlu disimpan • Jenis_Slta perlu dikodekan dan dibuat tabel referensi • Kecataman, Kabupaten, Propinsi dalam Alm_Mhs_Kota perlu dikodekan dan dibuat tabel referensi • Kecataman, Kabupaten, Propinsi dalam Alm_Tua_Kota perlu dikodekan dan dibuat tabel referensi • Krd_Hm tidak perlu disimpan • Kredit tidak perlu disimpan • Nilai-nilai kode dalam Nmpm perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode pada Nomor_Test perlu dipisah dan dibuat tabel referensi • PMKA perlu tabel referensi • Strata perlu tabel referensi

11.

DATA_08_001

• Golongan perlu tabel referensi • Jenis perlu tabel referensi • Kecamatan, Kabupaten, Propinsi dalam Alamat perlu dikodekan dan dibuat tabel referensi

216

• Kecamatan, Kabupaten, Propinsi dalam Alamat_1 perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam Alamat_2 perlu dikodekan dan dibuat tabel referensi • Nilai-nilai kode dalam Kode_Dosen perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Kode_Mtk perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam No_Mhs perlu dipisah dan dibuat tabel referensi

12.

DATA_08_002

• Agm perlu tabel referensi • Fak perlu tabel referensi • JenjStd perlu tabel referensi • Jur perlu tabel referensi • Kecamatan, Kabupaten dalam AlmYgjMhs perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam AlmAslMhs perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam AlmAyah perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam AlmIbu perlu dikodekan dan dibuat tabel referensi • KrjAyh perlu dikodekan dan dibuat tabel referensi • KrjIbu perlu dikodekan dan dibuat tabel referensi • NmBank perlu dikodekan dan dibuat tabel referensi • NmPtgBagKeu perlu dikodekan dan dibuat tabel referensi • PndAkhrAyh perlu dikodekan dan dibuat tabel referensi • PndAkhrIbu perlu dikodekan dan dibuat tabel referensi • StsKulh perlu tabel referensi • StsMhs perlu tabel referensi • WNANeg perlu tabel referensi • WNIKtrn perlu tabel referensi • WNISk perlu tabel referensi

13.

DATA_08_003

• Dosen1 perlu dikodekan dan dibuat tabel referensi • Dosen2 perlu dikodekan dan dibuat tabel referensi • Dosen3 perlu dikodekan dan dibuat tabel referensi • JenisTA perlu tabel referensi • Kecamatan,Kabupaten, Propinsi dalam Alamat perlu dikodekan dandibuat tabel referensi • Kota perlu dikodekan dan dibuat tabel referensi • MKD perlu disimpan dalam tabel terpisah • NamaD perlu dikodekan dan dibuat tabel referensi

217

• NamaTA tidak perlu disimpian • Nilai-nilai kode dalam KodeMK perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam NoMHS perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam NoMhsTA perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam NoMKS perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Semester perlu dipisah dan dibuat tabel referensi • Syarat cukup menggunakan FK • Syarat cukupmenggunakan FK

14.

DATA_08_004

• Agama

perlu dikodekan dan dibuat tabel referensi

• Fakultas perlu dikodekan dan dibuat tabel referensi • Gelombang perlu dikodekan dan dibuat tabel referensi • Id_Jalur perlu dikodekan dan dibuat rabel referensi • J_Kelamin perlu dikodekan • Jenis_SMA perlu dipisah dan dibuat tabel referensi • Jur_SMA perlu dipisah dan dibuat tabel referensi • Jurusan perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten dalam Alamat_Yogya perlu dikodekan dan dibuat table referensi • Kecamatan, Kabupaten, Propinsi dalam Alamat_SMA perlu dipisah dan dibuat tabel referensi • Kelulusan perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Kode perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Kode_Jurusan perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam No_Pendaftaran perlu dipisah dan dibuat tabel referensi • Pek_Mhs perlu dikodekan dan dibuat tabelreferensi • Status perlu dikodekan dan dibuat tabelreferensi

15.

DATA_08_005

• Jurusan perlu dikodekan dan dibuat tabelreferensi • Kd_Hari terlalu lebar • Nilai-nilai kode dalam Kd_Asisten perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Kd_Prak perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Nim perlu dipisah dan dibuat tabel referensi • Status perlu dikodekan dan dibuat tabelreferensi

16.

DATA_08_006

• Kecamatan, Kabupaten, Propinsi dalam Alamat perlu dikodekan dan dibuat tabel referensi • Kode_asisten perlu dikodekan dan dibuat tabel referensi

218

• Lulusan perlu dikodekan dan dibuat tabel referensi • Nilai_huruf perlu dipecah, dan dibuat tabel referensi • Nilai-nilai kode dalam Nim perlu dipisah dan dibuat tabel referensi • Nim perlu dipecah, dan nilai-nilai kode dalam setiap Nim perlu dipisah dan dibuat tabel referensi • Sex perlu dikodekan

17.

DATA_08_007

• Hari perlu dikodekan • Nilai-nilai kode dalam Kode_mk perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Nim perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Th_Ajar perlu dipisah • Semester perlu dikodekan dan dibuat tabel referensi

18.

DATA_08_008

• Nilai-nilai kode dalam Id_Jdwl perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Nim perlu dipisah dan dibuat tabel referensi • Semester perlu dikodekan

19.

DATA_08_009

• Bank perlu tabel referensi • Besar_uang perlu tabel referensi • Daftar_gel_2 perlu dirubah menjadi vertikal • Daftar_gel_2_2 perlu dirubah menjadi vertikal • Daftar_gel_3 perlu dirubah menjadi vertikal • Daftar_gel_3_2 perlu dirubah menjadi vertikal • Her_gel_2 perlu dirubah menjadi vertikal • Her_gel_2_2 perlu dirubah menjadi vertikal • Her_gel_3 perlu dirubah menjadi vertikal • Her_gel_3_2 perlu dirubah menjadi vertikal • Kecamatan dalam Alamat_Yogya perlu dikodekan dan dibuat tabel referensi • Kecamatan dalam Ortu_alamat perlu dikodekan dan dibuat tabel referensi • Kecamatan dalam Slta_alamat perlu dikodekan dan dibuat tabel referensi • Nem perlu dipecah, dan setiap nilai Nem perlu disimpan dalam tabel terpisah • Nilai-nilai kode dalam Camaba_Id perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Daftar_camaba_Id perlu dipisah dan dibuat tabel referensi • Ortu_kabupaten perlu dikodekan dan dibuat tabel referensi • Ortu_propinsi perlu dikodekan dan dibuat tabel referensi • Pengumuman_gel_2 perlu dirubah menjadi vertikal

219

• Pengumuman_gel_3 perlu dirubah menjadi vertikal • Slta_jurusan perlu tabel referensi • Slta_kabupaten perlu dikodekan dan dibuat tabel referensi • Slta_propinsi perlu dikodekan dan dibuat tabel referensi • Tes_gel_2 perlu dirubah menjadi vertikal • Tes_gel_3 perlu dirubah menjadi vertikal

20.

DATA_08_010

• Agama perlu tabel referensi • Alamat_SLTA tidak perlu disimpan • Hasil perlu dikodekan dan dibuat tabel referensi • Jenis_SLTA perlu tabel referensi • Jenjang perlu tabel referensi • Jurusan_SLTA perlu tabel referensi • Kecamatan, Kabupaten, dalam Almt_Ortu perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, dalam Almt_SLTA perlu dikodekan dan dibuat tabel referensi • Kode_Fak tidak standard • Kode_Jurusan tidak standard • Kota perlu dikodekan dan dibuat tabel referensi • Kota_Ortu perlu dikodekan dan dibuat tabel referensi • Nama_SLTA perlu dikodekan dan dibuat tabel referensi • Nilai-nilai kode dalam No_Slip perlu dipisah dan dibuat tabel referensi • Pekerjaan perlu tabel referensi • Pilihan1 tidak standard • Pilihan2 tidak standard • SLTA_Asal perlu tabel referensi • Status perlu tabel referensi

21.

DATA_06_001

• Agama

perlu tabel referensi

• AsalSkl perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam AlamatSkl perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam Alm1 perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam Alm2 perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam Alm3 perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam AlmSkr perlu dikodekan dan dibuat tabel referensi

220

• Nilai perlu tabel referensi • Nilai-nilai kode dalam NIM perlu dipisah dan dibuat tabel referensi

22.

DATA_06_02

• Karya perlu dikodekan dan dibuat tabel referensi • Kecamatan,Kabupaten, Propinsi dalam Alamat perlu dikodekan dan dibuat tabel referensi • Nilai-nilai kode dalam KodeMK perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Nomhs perlu dipisah dan dibuat tabel referensi • Pekerjaan perlu dikodekan dan dibuat tabel referensi • Pendidikan perlu dikodekan dan dibuat tabel referensi • Penelitian perlu dikodekan dan dibuat tabel referensi • Tema perlu dikodekan dan dibuat tabel referensi

23.

DATA_06_03

• Kecamatan, Kabupaten dalam Alamat_Asal perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten dalam Alamat_Yogya dikodekan dan dibuat tabel referensi • KodeGlb perlu tabel referensi

24.

DATA_06_04

• Kecamatan,Kabupaten, Propinsi dalam Alamat perlu dikodekan dan dibuat tabel referensi • Nilai-nilai kode dalam Kd_MTK perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam No_Mhs perlu dipisah dan dibuat tabel referensi

25.

DATA_06_05

• Hari perlu dikodekan • Jenjang perlu tabel referensi • Kd_JadAss perlu dikodekan dan dibuat tabel referensi • Nilai-nilai kode dalam Kd_CaPrak perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Kd_JadHari perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Kd_JadPrak perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Kd_MtPrak perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam Kd_Soal perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam NIM perlu dipisah dan dibuat tabel referensi • Status perlu dikodekan dan dibuat tabel referensi • Thn_Ajaran perlu dikodekan

26.

DATA_06_06

• Agama perlu dikodekan dan dibuat tabel referensi • Hari perlu dikodekan • Jenis perlu dikodekan dan dibuat tabel referensi • Kd_jur perlu dikodekan dan dibuat tabel referensi • Kecamatan, Kabupaten dalam Alamat perlu dibuat tabel referensi

221

• Kecamatan, Kabupaten dalam Alamat_baru perlu dibuat tabel referensi • Kecamatan, Kabupaten, Propinsi dalam Alamat_asal perlu dibuat tabel referensi • Kelompok perlu dikodekan dan dibuat tabel referensi • Nilai-nilai kode dalam Kd_mtk perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam No_mhs perlu dipisah dan dibuat tabel referensi • Pekerjaan perlu dikodekan dan dibuat tabel referensi

27.

DATA_06_07

• Agama perlu dikodekan dan dibuat tabel referensi • Bdg_ilmu perlu dikodekan dan dibuat tabel referensi • Jenis_kel perlu dikodekan • Kd_bayar perlu dikodekan dan dibuat tabel referensi • Kd_matakuliah perlu dipisah ke dalam rinci data Kd_matakuliah • Kecamatan, Kabupaten, Propinsi dalam Al_mahasiswa perlu dikodekan dan dibuat tabel referensi • Kredit tidak perlu disimpan • Nama_mata_kuliah diganti Kd_matakuliah • Nilai-nilai kode dalam Kd_matakuliah perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam NIM perlu dipisah dan dibuat tabel referensi • Nilai-nilai kode dalam T_akademik perlu dipisah dan dibuat tabel referensi • Smt perlu dikodekan • Status perlu dikodekan dan dibuat tabel referensi

28.

DATA_06_08

• Hari perlu dikodekan • Hari tidak perlu disimpan • Jam_Keluar tidak perlu disimpan • Jam_Masuk tidak perlu disimpan • Kecamatan, Kabupaten, Propinsi dalam Alamat perlu dikodekan dan dibuat tabel referensi • Mt_Prak perlu dikodekan dan dibuat tabel referensi • Mt_Prak tidak perlu disimpan • Nm_Ass tidak perlu disimpan • Pend perlu dikodekan dan dibuat tabel referensi • Pend tidak perlu disimpan • Uang_Hnr perlu tabel referensi • Uang_Mkn perlu tabel referensi

222

Berdasarkan Tabel 4.35, maka dapat didentifikasikan faktor-faktor penyebab rancangan struktur tabel database tidak fleksibel pada data rancangan struktur tabel database yang dianalisis, yaitu: 1. Penggunaan kode pada nilai data tidak fleksibel karena tidak dilengkapi dengan tabel referensi. 2. Penggunaan kode eksternal berupa kode blok secara langsung sebagai PK tidak fleksibel, karena bagian-bagian kode blok dapat mengalami perubahan makna/arti, format, dan struktur, sedangkan kode blok database tidak dilengkapi dengan tabel referensi. 3. Nilai-nilai data yang dapat dikodekan tidak fleksibel karena disimpan secara langsung (tidak dikodekan) ke dalam tabel database, sehingga memerlukan penulisan kembali nilai-nilai data yang sama secara berulang yang bisa jadi mengakibatkan terjadinya inkonsistensi data. 4. Nilai-nilai data yang disimpan secara berulang (mengalami kerangkapan data) tidak fleksibel, karena perubahan terhadap 1 (satu) buah nilai data harus dilakukan berulangkali sejumlah perulangan nilai data. Jika ada nilai data yang terlewatkan dari perubahan tersebut, maka akan mengakibatkan inkonsistensi data. 5. Penyusunan set atribut berulang (repeated group) dalam tabel secara horisontal tidak memenuhi karakteristik tabel relasional dan tidak fleksibel, karena jumlah perulangan set atribut berulang bersifat dinamis, sehingga penyusunan secara horisontal akan menyulitkan apabila terjadi

223

perubahan. Bisa jadi jumlah set atribut berulang yang disediakan terlalu sedikit untuk sebagian data, atau kurang untuk sebagian data yang lain. Selanjutnya untuk menemukan faktor-faktor yang lebih bersifat umum penyebab rancangan struktur tabel database tidak fleksibel, masing-masing faktor dalam Tabel 4.35 akan dikelompokkan ke dalam kelompok-kelompok faktor yang sejenis. Hasil pengelompokkan ini menunjukkan faktor umum penyebab rancangan struktur tabel database tidak fleksibel. Hasil pengelompokkan yang dimaksud ditampilkan pada Tabel 4.36. Tabel 4.36: Faktor umum penyebab rancangan struktur tabel database tidak fleksibel No 1

2

Faktor Umum Batasan lingkup sistem

Orientasi data

Faktor Rincian Kebutuhan lingkup sistem minimal

o

Pandangan perancang terhadap database

o

Penggunaan bersama database

o

Kebutuhan orientasi database

o

Kerangkapan data (data redundancy)

o

Inkonsistensi data (data inconsistency)

o

Penjelasan Pandangan terhadap lingkup sistem akan menentukan hasil rancangan tabel database. Pandangan lingkup sistem minimal untuk membuat rancangan struktur tabel yang fleksibel adalah sebuah organisasi secara utuh, bukan pada sub organisasi. Pandangan perancang terhadap database harus berada dalam level conceptual view bukan pada level user view. Hal ini akan memberikan fleksibilitas yang lebih baik, karena rancangan struktur tabel database akan dapat digunakan oleh banyak pengguna (program aplikasi, query, maupun orang-orang dalam seluruh sub sistem dan seluruh level manajemen). Database dirancang untuk dapat digunakan oleh banyak pengguna (orang maupun aplikasi), baik pada level operasional, taktis, maupun strategis, pada seluruh unit fungsional dalam organisasi. Rancangan struktur tabel database akan bersifat fleksibel jika antar tabel database saling memiliki kerelasian. Faktor ini berarti bahwa rancangan struktur tabel database tidak dapat dibuat sebelum dapat diidentifikasikan seluruh pengguna database-nya. Rancangan struktur tabel database akan memberikan fleksibilitas yang lebih baik jika bersifat data oriented, bukan program oriented. Dalam hal ini, keberhasilan program pengolah database bukan menjadi tujuan utamanya. Untuk memudahkan pembuatan program aplikasi, seringkali data-data disimpan secara berulang di beberapa tabel. Hal ini akan mengakibatkan permasalahan pada saat pengolahan data, yaitu insert anomally, delete anomally, dan update anomally. Kesalahan paling fatal dalam sebuah database adalah jika terjadi inkonsistensi data. Hal ini bisa dihindari jika

224

3

Standarisasi data

Kebutuhan standarisasi data

o

4

Kelengkapan data

Kebutuhan kelengkapan data

o

Penambahan kebutuhan baru

o

Kebutuhan pengelompokan data

o

Kebutuhan tabel induk (master)

o

Kebutuhan tabel transaksi

o

Kebutuhan kunci asing (Foreign Key /FK)

o

5

Pengelompokan data

database terbebas dari kerangkapan data, atau paling tidak jika terjadi kerangkapan data, maka kerangkapan itu harus terkontrol. Rancangan struktur tabel database akan bersifat fleksibel jika ada standarisasi pada setiap nilai data. Standarisasi data ini terkait dengan tipe data, ukuran data, dan range data yang akan digunakan oleh seluruh bagian dalam organisasi. Standar data harus didefinisikan sebelum perancangan struktur tabel database dilakukan. Keputusan-keputusan manajemen hanya dapat diambil dengan baik jika didasarkan pada informasi yang lengkap. Selain itu, kebutuhan informasi (dan data) untuk kebutuhan manajemen akan selalu berubah dan berkembang. Oleh karena itu, di dalam sebuah database setiap tabel database harus memuat sekelompok atribut yang lengkap untuk menjelaskan tentang obyek datanya sejak pertama kali dirancang. Perubahan dan penambahan atribut baru setelah sistem dioperasionalkan akan menurunkan tingkat fleksibilitas rancangan struktur tabel database. Database yang lengkap juga memungkinkan untuk digunakan oleh sub sistem-sub sistem baru tanpa harus mengubah rancangan struktur tabel database, karena kebutuhan-kebutuhan baru tersebut dapat dipenuhi dengan cara menambahkan rancangan struktur tabel database baru (tidak perlu mengubah rancangan struktur tabel database yang sudah ada), dan kemudian menghubungkannya dengan tabel-tabel database yang diperlukan yang telah ada. Data-data dalam database akan bersifat fleksibel jika setiap tabel hanya menyimpan nilai-nilai data yang benar-benar menjadi kelompoknya. Nilai-nilai data yang bersifat statis perlu dipisahkan dengan nilai-nilai data yang bersifat dinamis. Data-data dalam database akan bersifat fleksibel jika datadata induk dipisahkan dengan data-data transaksi. Datadata dalam tabel induk digunakan untuk menyimpan datadata yang bersifat statis yang akan menjadi referensi bagi data-data dalam tabel transaksi. Tabel induk akan menjadi dasar untuk keseluruhan file dalam sebuah database. Tabel induk juga digunakan untuk menyimpan definisi setiap kode yang digunakan dalam database. Data-data dalam database akan bersifat fleksibel jika datadata dalam tabel transaksi hanya memuat catatan transaksi atau hubungan yang terjadi di antara data dalam tabel-tabel induk. Untuk memperoleh rancangan struktur tabel database yang fleksibel, maka FK hanya dipasang dalam tabel-tabel anak (secara reatif) yang mengacu ke tabel induknya pada jenis kerelasian one-to-many, dan pada tabel-tabel transaksi yang menghubungkan antar tabel master pada jenis kerelasian many-to-many.

225

6

Penggunaan kode pada data

Kebutuhan penggunaan kode pada data

o

o o

o

o o

Penggunaan kode blok (block code)

o

o

7

Penggunaan kunci primer (Primary Key/PK)

Pembangkitan kode

o

Kebutuhan PK dalam tabel

o

o

o Penggunaan kode eksternal (user defined code) sebagai PK

o

o

Penggunaan kode pada data merupakan salah satu bagian upaya optimalisasi database. Penggunaan kode yang mencirikan data akan memudahkan pengolahan data dalam database, meningkatkan efisiensi memori, menjaga fleksibilitas data terhadap perubahan. Kode umumnya disebut baik jika urut, singkat, dan dapat dibangkitkan oleh sistem secara otomatis. Penggunaan kode pada data harus dirancang sekaligus saat membuat rancangan struktur tabel database dan akan memerlukan dokumentasi yang jelas, pengendalian integritas data secara tersistem (pada operasi insert, delete, dan uIpdate). Penggunaan kode pada data hanya digunakan dalam basis data, sedangkan pada tampilan monitor, kertas, media lainnya tetap menampilkan nilai sesungguhnya (kecuali untuk kode yang telah lazim digunakan). Penggunaan kode pada data tidak harus harus selalu diketahui oleh para pengguna akhir (end user). Penggunaan kode pada data akan memerlukan tabel referensi untuk memudahkan perubahan arti/makna kode di kelak kemudian hari, kecuali untuk arti/makna nilai data yang pasti tidak akan berubah selamanya maka artikulasiya dapat dilakukan oleh program aplikasi (misal jenis kelamin). Selain kode sequential dan mnemonic, kode blok banyak digunakan dalam database. Kode blok disusun membentuk blok kode dengan menggunakan format tertentu (umumnya tersusun atas gabungan angka dan character). Kode blok akan bersifat fleksibel jika blok-blok kode dipisahkan ke dalam atribut-atribut tersendiri dan masingmasing dilengkapi dengan tabel referensi. Hal ini akan memudahkan pengolahan di kemudian hari apabila terjadi pergeseran penempatan urutan blok kode atau perubahan arti/makna kode. Kode-kode dalam database sedapat mungkin dapat dibangkitkan secara otomatis oleh sistem/program aplikasi, sehingga pengguna tidak harus mengetikkan kode saat melakukan entry data. Hal ini akan meminimalkan terjadinya kesalahan akibat human error. Setiap struktur tabel database harus memiliki PK, hal ini diperlukan untuk memberikan jaminan bahwa setiap record tabel tersebut dapat diidentifikasikan berdaasrkan kunci yang unik. PK dalam sebuah tabel database dapat berupa kunci sederhana (simple key) yaitu kunci yang tersusun atas sebuah atribut, atau berupa kunci komposite (composite key) yaitu kunci yang tersusun atas gabungan atribut. PK dapat dipilih dari atribut-atribut yang telah ada atau berupa atribut baru yang dirancang sendiri. Kode eksternal merupakan kode yang disusun oleh pengguna awam (end user), mewakili kode yang lazim digunakan secara terbuka, telah dikenal baik oleh pengguna, dan umumnya telah digunakan dalam keseharian. Kode eksternal dapat digunakan sebagai PK jika bersifat unik dan tidak akan terjadi perubahan selamanya.

226

Penggunaan kode internal (systems code) sebagai PK

o

o

o o

8

Penggunaan tabel logik

Kebutuhan tabel logik

o

Penggunaan tabel logik

o

Umumnya perubahan kode eksternal akan terjadi pada saat bisnis semakin maju, organisasi semakin besar, dan pengolahan data semakin kompleks. Hal ini berarti penggunaan kode eksternal sebagai PK secara langsung akan mengandung resiko dan memiliki fleksibilitas yang rendah. Kode internal adalah kode-kode yang disusun oleh perancang database, mewakili kode-kode baru yang dirancang dengan tujuan untuk meningkatkan efisiensi penggunaan media penyimpan data. Perancangan kode internal ini diusahakan agar cukup mudah dipahami oleh para pemakai. Khusus untuk kode internal berupa nomor urutan (Autoincrement), maka kode seperti ini memenuhi sifat unik, sehingga dapat dipakai sebagai PK dan memiliki fleksibilitas yang tinggi. Pada kasus tertentu (misal penggabungan 2 (dua) institusi dan tetap mempertahankan kode pada masingmasing institusi), kode internal seperti ini juga lebih sesuai digunakan Permasalahanya adalah kode internal seperti ini tidak memiliki hubungan nilai secara langsung dengan nilai-nilai dalam yang disimpan, sehingga memerlukan mekanisme tersendiri untuk menguji integritas referensial dengan tabeltabel yang lain. Selain itu, kode internal seperti ini akan menambah ukuran media penyimpan yang diperlukan. Tabel logik biasanya hanya memuat data-data tertentu yang bersumber dari beberapa tabel database. Penggunaan tabel logik bermanfaat apabila diperlukan laporan yang memerlukan informasi dari sumber tabel database yang berjumlah sangat banyak. Daripada harus mengakses dari banyak tabel, maka laporan akan lebih mudah diperoleh jika menggunakan tabel logik ini (misal dengan perintah query). Penggunaan tabel logik mengandung resiko adanya perulangan penyimpanan data. Akibatnya, bisa jadi mengakibatkan inkonsistensi data dan nilai-nilai data di dalamnya menjadi tidak fleksbel.

4.2.3. Kerangka Rancangan Struktur Tabel Database Yang Relatif Fleksibel Untuk SIAKAD Untuk menyusun sebuah kerangka rancangan struktur tabel database yang fleksibel untuk SIAKAD, maka diperlukan adanya asumsi-asumsi. Asumsi yang digunakan dalam penelitian ini adalah sebagai berikut:

227

1. SIPT merupakan sistem informasi berbasis komputer yang terintegrasi untuk seluruh sub unit fungsional yang ada pada Perguruan Tinggi 2. SIPT melayani kebutuhan informasi bagi para pemakai dengan kebutuhan yang serupa, utamanya pada level operasional dan manajerial 3. Perguruan Tinggi menyelenggarakan beberapa Fakultas yang membawahi beberapa Jurusan, masing-masing Jurusan dapat menyelenggarakan beberapa Program Studi. Perguruan Tinggi dapat mengembangkan Fakultas, Jurusan, dan Program Studi baru 4. Perguruan Tinggi hanya menyelenggarakan pendidikan jenjang S1 5. SIAKAD merupakan bagian dari SIPT yang menangani pengolahan data untuk proses pengolahan data khusus bidang akademik, mulai dari pendaftaran mahasiwa baru hingga lulus dan menjadi alumni 6. SIPT terdiri atas sub-sub sistem, yaitu: a. Sub Sistem Informasi Akademik (SIAKAD) b. Sub Sistem Informasi Perpustakaan (SIPERPUSTAKAAN) c. Sub Sistem Informasi Keuangan (SIKEUANGAN) d. Sub Sistem Informasi Kepegawaian (SIPEGAWAI) e. Sub Sistem Informasi Penggajian (SIGAJI) f. Sub Sistem Informasi Inventaris (SIINVENTARIS) g. Sub Sistem Informasi Kemahasiswaan (SIKEMAHASISWAAN) h. Sub Sistem Informasi Kerjasama dan Humas (SIKEHUMAS) i. Sub Sistem Informasi Penelitian (SIPENELITIAN) j. Sub Sistem Informasi Pengabdian Pada Masyarakat (SIPENGABDIAN)

228

k. Sub Sistem Informasi lainnya sesuai kebutuhan institusi 7. SIAKAD terdiri atas serangkaian proses kegiatan yang merupakan sub sistem dari SIAKAD, meliputi: a. Penerimaan Mahasiswa Baru (SIPENMARU) b. Herregisterasi (SIHEREGISTERASI) c. Perwalian mahasiswa (SIWALI) d. Pra-KRS, KRS, dan perubahan KRS (SIKRS) e. Perkuliahan (SIKULIAH) f. Praktikum (SIPRAKTIKUM) g. KP (SIKP) h. KKN (SIKKN) i. Tugas Akhir (SITA) j. Yudisium (SIYUDISIUM) k. Wisuda (SIWISUDA) l. Alumni (SIALUMNI) Untuk setiap sub sistem dalam SIAKAD memerlukan database yang terkait dengan tiga hal, yaitu: 1.

Proses pendataan awal, diperlukan untuk menyimpan data-data awal yang diperlukan untuk proses pengolahan data transaksi dan penyajian informasi

2.

Proses pengolahan data transaksi, diperlukan untuk mengolah dan menyimpan data-data yang diperlukan untuk proses transaksi

229

3.

Proses penyajian informasi, diperlukan untuk mengolah database dan kemudian menampilkannya ke dalam bentuk dan format yang disesuaikan dengan kebutuhan seluruh pengguna Setiap rancangan struktur tabel database yang dibuat harus dapat

digunakan oleh seluruh pengguna, baik perseorangan, kelompok orang maupun program aplikasi-program aplikasi yang menjadi sub sistem dalam SIPT (SIPERPUSTAKAAN,

SIKEUANGAN,

SIPEGAWAI,

SIGAJI,

SIINVENTARIS, SIKEMAHASISWAAN, SIKEHUMAS, SIPENELITIAN, SIPENGABDIAN, serta Sub Sistem Informasi lainnya yang dikembangkan sesuai dengan kebutuhan pada masing-masing institusi Perguruan Tinggi), bukan hanya untuk SIAKAD saja. Berdasarkan hasil identifikasi kebutuhan informasi (dan data) untuk SIPT yaitu meliputi kebutuhan-kebutuhan untuk penyusunan portofolio, peningkatan mutu Pendidikan Tinggi, penyusunan evaluasi diri, penyusunan borang akreditasi, kebutuhan rinci data untuk setiap sub sistem dalam SIAKAD, serta perubahan kebutuhan informasi (dan data) untuk SIAKAD, maka selanjutnya dapat dibuat sebuah kerangka rancangan struktur tabel database untuk SIAKAD yang relatif fleksibel untuk aturan bisnis yang umum digunakan oleh Perguruan Tinggi. Implementasi teknis terhadap kerangka rancangan struktur tabel database untuk SIAKAD dapat berbeda-beda, nama-nama tabel dan nama-nama atribut dapat dimodifikasi disesuaikan dengan kebutuhan, sedangkan tipe dan ukuran atribut dapat berbeda-beda tergantung pada DBMS yang digunakan. Selain itu, arsitektur sistem aplikasi geografi dari database juga dapat berbeda-

230

beda sesuai dengan infrastruktur yang tersedia. Kerangka rancangan struktur tabel database untuk SIAKAD yang diusulkan dalam penelitian ini secara lebih detail ditampilkan pada Tabel 4.37. Tabel 4.37: Kerangka rancangan struktur tabel database yang relatif fleksibel untuk SIAKAD No 1

2

3

Nama Tabel Bank_Soal_Penmaru _Check_Point

Bank_Soal_Penmaru _Essay

Kalender_Akademik

4

Jalur_Penmaru

5

Beaya_Pendaftaran

6

Program_Studi

7

8

Jurusan

Fakultas

Nama Atribut Kode_soal No_Soal Soal Skor Kunci_Jawaban Jawab_A Jawab_B Jawab_C Jawab_D Jawab_E Kode_soal No_Soal Soal Skor Kunci_Jawaban Tahun_Akademik Kegiatan Tanggal_Mulai Tanggal_Akhir Jalur_Pendaftaran Nama_Jalur_Pendaftaran Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Jalur_Pendaftaran Beaya_Pendaftaran Program_Studi Nama_Program_Studi Tanggal_Berdiri Tanggal_SK No_SK Status_Program_Studi Jurusan Jurusan Nama_Jurusan Tanggal_Berdiri Tanggal_SK No_SK Status_Program_Studi Fakultas Fakultas Nama_Fakultas

Tipe Char Num Memo Num Char Memo Memo Memo Memo Memo Char Num Memo Num Memo Char Char Char Date Char Char Char Char Char Char Num Char Char Date Date Char Char Char Char Char Date Date Char Char Char Char Char

Ukuran 4 8

PK PK PK

2 1

4 8

PK PK

2 4 1 1 1 50 4 1 1 1 6 2 50

50 1 2 2 20

50 1 1 2 20

PK PK PK PK PK PK PK PK

PK

PK

Null? No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No

231

9

Program

10

Jenjang_Pendidikan

11

Jenis_Pendidikan

12

Agama

13

Kecamatan

14

Kabupaten

15

Propinsi

16

Kode_Pos

17

Status_Program_Studi

18

Pekerjaan

19

Kewarganegaraan

20

Jenis_SLTA

21

SPP

22

DPP

23

Angsuran_SPP

Tanggal_Berdiri Tanggal_SK No_SK Program Nama_Program Jenjang_Pendidikan Nama_Jenjang_Pendidikan Keterangan Jenis_Pendidikan Nama_Jenis_Pendidikan Agama Nama_Agama Kecamatan Nama_Kecamatan Kabupaten Kabupaten Nama_Kabupaten Propinsi Propinsi Nama_Propinsi Kode_Pos Nama_Wilayah Status_Program_Studi Nama_Status_Program_Studi Pekerjaan Nama_Pekerjaan Kewarganegaraan Nama_Kewarganegaraan Jenis_SLTA Nama_Jenis_SLTA Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Program Jenjang_Pendidikan Jenis_Pendidikan Jumlah_SPP_Tetap Jumlah_SPP_Variabel Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Program Jenjang Jenis_Pendidikan Jumlah_DPP_Minimal Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Program Jenjang_Pendidikan Jenis_Pendidikan Angsuran_ke

Date Date Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Num Num Char Char Char Char Char Char Num Char Char Char Char Char Char Num

50 1 20 2 6 12 1 20 1 10 4 50 2 4 50 2 2 50 5 50 1 50 2 50 1 50 1 50 4 1 1 1 2 1 8 8 4 1 1 1 2 1 8 4 1 1 1 2 1 1

PK PK

PK PK PK

PK

PK PK PK PK PK PK PK PK PK PK PK PK

PK PK PK PK PK PK PK PK PK PK PK PK PK

No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No Yes No No No No No No No No No No No No No No

232

24

Angsuran_DPP

25

SLTA

26

27

Pendaftar_Mahasiswa _Baru

Ayah_Pendaftar

Jumlah_Angsuran Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Program Jenjang Jenis_Pendidikan Angsuran_ke Jumlah_Angsuran SLTA Nama_SLTA Jenis_SLTA Alamat Kecamatan Kode_Pos Telepon No_Pendaftaran Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Program Jenjang_Pendidikan Jenis_Pendidikan Jalur_Pendaftaran Tanggal_Pendaftaran Nama_Pendaftar Agama Nilai_Bahasa_Inggris Nilai_Matematika Jumlah_NEM Jumlah_Mata_Pelajaran_NEM Jumlah_Nilai_STTB Jumlah_Mata_Pelajaran_STTB Agama Kewarganegaraan Alamat Kode_Pos Kecamatan SLTA No_Pendaftaran Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Jalur_Pendaftaran Nama_Ayah Jenjang_Pendidikan Pekerjaan Agama Alamat Kode_Pos Kecamatan Telepon

Num Char Char Char Char Char Char Num Num Char Memo Char Memo Char Char Char Num Char Char Char Char Char Char Char Date Char Char Num Num Num Num Num Num Char Char Memo Char Char Char Num Char Char Char Char Char Char Char Char Memo Char Char Char

8 4 1 1 1 2 1 1 8 6

PK PK PK PK PK PK PK PK

1 4 5 12 7 4 1 1 1 2 1 1

PK PK PK PK PK PK PK PK

50 1 1:1 1:1 2:2 1 2:2 1 1 1 5 4 6 7 4 1 1 1 50 2 2 1 5 4 12

PK PK PK PK PK

No No No No No No No No No No No No No No No Yes No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No Yes

233

28

29

Ibu_Pendaftar

Wali_Pendaftar

30

Pilihan_Pendaftaran _Mahasiswa

31

Jawaban_Tes_Check _Point_Penmaru

32

Jawaban_Tes_Essay _Penmaru

Penghasilan No_Pendaftaran Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Jalur_Pendaftaran Nama_Ibu Jenjang_Pendidikan Pekerjaan Agama Alamat Kode_Pos Kecamatan Telepon Penghasilan No_Pendaftaran Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Jalur_Pendaftaran Nama_Wali Jenjang_Pendidikan Pekerjaan Agama Alamat Kode_Pos Kecamatan Telepon Penghasilan No_Pendaftaran Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Jalur_Pendaftaran Jenjang_Pendidikan Program Pilihan_Ke Program_Studi Jumlah_Kesanggupan_DPP No_Pendaftaran Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Kode_soal No_Soal Jawaban Skore No_Pendaftaran Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Kode_soal No_Soal

Num Num Char Char Char Char Char Char Char Char Memo Char Char Char Num Num Char Char Char Char Char Char Char Char Memo Char Char Char Num Num Char Char Char Char Char Char Char Char Num Num Char Char Char Char Num Char Num Num Char Char Char Char Num

9 7 4 1 1 1 50 2 2 1 5 4 12 9 7 4 1 1 1 50 2 2 1 5 4 12 9 7 4 4 1 1 2 1 1 2 8 7 4 1 1 4 8 1 1 7 4 1 1 4 8

PK PK PK PK PK

PK PK PK PK PK

PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK

No No No No No No No No No No No No No Yes No No No No No No No No No No No No No Yes No No No No No No No No No No No No No No No No No No No No No No No No No

234

33

Kapasitas_Program _Studi

34

Batas_Nilai_Pendaftar _Diterima

35

Pendaftar_Diterima

36

Status_Diterima

37

Pendaftar_Pindahan _Alih_Jalur

38

Konversi_Nilai_Pendaftar _Pindahan_Alih_Jalur

39

Registerasi_Mahasiswa _Baru

Jawaban_Essay Skore Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Program_Studi Jenjang_Pendidikan Program Kapasitas Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Program_Studi Jenjang_Pendidikan Program Batas_Nilai_Min_Diterima No_Pendaftaran Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Jalur_Pendaftaran Program_Studi Jenjang_Pendidikan Program Tanggal_Yudisium Status_Diterima Status_Diterima Nama_Status_Diterima No_Pendaftaran Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Jalur_Pendaftaran Program_Studi Jenjang_Pendidikan Program SKS_Diakui SKS_Ditempuh No_Pendaftaran Tahun_Akademik Periode_Pendaftaran Gelombang_Pendaftaran Jalur_Pendaftaran Program_Studi Jenjang_Pendidikan Program Kode_Mata_Kuliah_Awal Kode_Mata_Kuliah_Akhir SKS Nilai No_Pendaftaran Tahun_Akademik Periode_Pendaftaran

Memo Num Char Char Char Char Char Char Num Char Char Char Char Char Char Num Num Char Char Char Char Char Char Char Date Char Char Char Num Char Char Char Char Char Char Char Num Num Num Char Char Char Char Char Char Char Char Char Num Char Num Char Char

2 2 4 1 1 2 2 1 3 1 1 1 2 2 1 2:2 7 4 1 1 1 2 2 1 1 1 20 7 4 1 1 1 2 2 1 3 3 7 4 1 1 1 2 2 1 4 4 3 1 7 4 1

PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK

Yes No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No

235

40

Registerasi_Mahasiswa _Lama

41

Status_Mahasiswa

42

Dosen_Tetap

43

Sejarah_Pendidikan _Dosen_Tetap

44

Sejarah_Jabatan _Akademik _Dosen_Tetap

45

Sejarah_Golongan _Ruang_Dosen _Tetap

46

Dosen_Tidak_Tetap

Gelombang_Pendaftaran Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Tanggal_Registerasi Status_Mahasiswa Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Tanggal_Registerasi Status_Mahasiswa Status_Mahasiswa Nama_Status_Mahasiswa Kode_Dosen NIK Nama_Dosen Tanggal_Masuk Bidang Agama Alamat Kode_Pos Kecamatan Agama Telepon E_mail Kode_Dosen Jenjang_Pendidikan Kode_Sekolah Tanggal_Lulus No_Ijazah Kode_Dosen Jabatan_Akademik Tanggal_SK No_SK Kode_Dosen Golongan Ruang Tanggal_SK No_SK Kode_Dosen NIP Nama_Dosen Alamat Kecamatan Kode_Pos Jenjang_Pendidikan Bidang Agama Golongan

Char Char Char Char Char Char Date Char Char Char Char Char Char Date Char Char Char Char Char Char Date Char Char Memo Char Char Char Char Char Char Char Char Date Char Char Char Date Char Char Char Char Date Char Char Char Char Memo Char Char Char Char Char Char

1 4 2 2 1 4 1 4 2 2 1 4 1 4 12 4 8 100

PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK

2 1 5 4 1 12 20 4 2 8 18 4 2 18 4 3 1 18 4 20 100 4 5 2 2 1 3

PK PK PK PK PK PK PK PK PK PK

No No No No No No No No No No No No No No No No No No No No No No No No No No No Yes Yes No No No No No No No No No No No No No No No No No No No No No No No No

236

47

Bidang

48

Golongan_Ruang

49

Jabatan_Akademik

50

Jabatan_Struktural

51

Pejabat_Struktural

52

Jenis_PT

53

SD

54

55

SLTP

PT

Ruang Jabatan_Akademik Telepon E_mail Instansi_Asal Alamat_Kantor Kecamatan_Kantor Telepon_Kantor Faximili_Kantor Bidang Nama_Bidang Golongan Ruang Nama_Golongan Masa_Kerja_Minimal Gaji_Pokok Jabatan_Akademik Nama_Jabatan_Akademik Angka_Kredit_Min Jabatan_Struktural Nama Jabatan_Struktural Level_Jabatan_Struktural Tunjangan_Jabatan_Struktural Keterangan Jabatan_Struktural Kode_Dosen Tanggal_SK No_SK Tanggal_Mulai_SK Tanggal_Akhir_SK Keterangan Jenis_PT Nama_Jenis_PT Kode_Sekolah Nama_SD Jenis_SD Alamat Kecamatan Kode_Pos Telepon Faximili E-mail Kode_Sekolah Nama_SLTP Jenis_SLTP Alamat Kecamatan Kode_Pos Telepon Faximili E-mail Kode_Sekolah Nama_PT

Char Char Char Char Char Memo Char Char Char Char Char Char Char Char Num Num Char Char Num Char Char Char Num Memo Char Char Date Char Date Date Memo Char Char Char Memo Char Memo Char Char Char Char Char Char Memo Char Memo Char Char Char Char Char Char Memo

1 1 12 20 50 4 12 12 2 50 3 1 50 2 8 1 50 4 2 50 10 9 2 8

PK PK PK

PK PK

PK PK PK

50

1 20 8

PK PK

1 4 5 12 12 20 8

PK

1 4 5 12 12 20 8

PK

No No Yes Yes No No No Yes Yes No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No Yes Yes Yes No No No No No No Yes Yes Yes No No

237

56

Kurikulum

57

Komposisi_Kurikulum

58

Konversi_Kurikulum

59

Mata_Kuliah

60 61 62 63

Program _Mata_Kuliah Kelompok _Mata_Kuliah Status _Mata_Kuliah Jenis _Mata_Kuliah

Jenis_PT Alamat Kecamatan Kode_Pos Telepon Faximili E-mail Tahun_Kurikulum Jenjang_Pendidikan Program_Studi Program Tanggal_SK_Kurikulum Nomor_SK_Kurikulum Tanggal_Mulai_Berlaku SKS_Total_Minimal Tahun_Kurikulum Status_Mata_Kuliah SKS_Minimal Jenjang_Pendidikan Program_Studi Program Kode_Mata_Kuliah_Awal_1 Kode_Mata_Kuliah_Akhir_1 Tahun_Kurikulum_1 Status_Mata_Kuliah_1 Kode_Mata_Kuliah_Awal_2 Kode_Mata_Kuliah_Akhir_2 Tahun_Kurikulum_2 Status_Mata_Kuliah_2 Kode_Mata_Kuliah_Awal Kode_Mata_Kuliah_Akhir Jenjang_Pendidikan Program_Studi Program Nama_Mata_Kuliah Nama_Mata_Kuliah_Inggris SKS Semester Program_Mata_Kuliah Kelompok_Mata_Kuliah Status_Mata_Kuliah Jenis_Mata_Kuliah Bidang_Mata_Kuliah Tahun_Kurikulum Program_Mata_Kuliah Nama_Program_Mata_Kuliah Kelompok_Mata_Kuliah Nama_Kelompok_Mata_Kuliah Status_Mata_Kuliah Nama_Status_Mata_Kuliah Jenis_Mata_Kuliah Nama_Jenis_Mata_Kuliah Jam_Per_SKS

Char Memo Char Char Char Char Char Char Char Char Char Date Char Date Num Char Char Num Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Num Num Char Char Char Char Char Char Char Char Char Char Char Char Char Char Num

1 4 5 12 12 20 4 2 2 1 50 8 3 4 1 3 2 2 1 4 4 4 1 4 4 4 1 4 4 2 2 1 50 50 1 1 1 1 1 1 1 4 1 20 1 50 1 50 1 20 3

PK PK PK PK

PK PK PK PK PK PK PK PK PK

PK PK PK PK PK

PK PK PK PK PK PK PK PK PK PK

No No No No Yes Yes Yes No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No

238

64 65

Bidang _Mata_Kuliah Prasyarat _Mata_Kuliah

66

Nilai

67

Ruang

68

Fasilitas

69

Kondisi_Fasilitas

70

Jadwal

71

Dosen_Mengajar

72

Materi_Dosen _Mengajar

Bidang_Mata_Kuliah Nama_Bidang_Mata_Kuliah Program_Studi Jenjang_Pendidikan Program Kode_Mata_Kuliah_Awal_Bersyarat Kode_Mata_Kuliah_Akhir_Bersyarat Tahun_Kurikulum Kode_Mata_Kuliah_Awal_Prasyarat Kode_Mata_Kuliah_Akhir_Prasyarat Nilai Mutu Predikat Ruang Kapasitas Ukuran_Luas Fasilitas Kondisi_Fasilitas Keterangan Fasilitas Nama_Fasilitas KondisiFasilitas Nama_Kondisi_Fasilitas Program_Studi Jenjang_Pendidikan Program Kode_Mata_Kuliah_Awal Kode_Mata_Kuliah_Akhir Tahun_Akademik Semester Kode_Dosen Kode_Ruang Kelas Hari Jam_Mulai Jam_Selesai Kode_Dosen Kode_Mata_Kuliah_Awal Kode_Mata_Kuliah_Akhir Tahun_Akademik Semester Program_Studi Program Jenjang_Pendidikan Tanggal_SK No_SK Status_Mengajar Kode_Dosen Kode_Mata_Kuliah_Awal Kode_Mata_Kuliah_Akhir Tahun_Akademik Semester Program_Studi

Char Char Char Char Char Char Char Char Char Char Char Num Char Char Num Num Char Char Memo Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Time Time Char Char Char Char Char Char Char Char Date Char Char Char Char Char Char Char Char

1 50 2 2 1 4 4 4 8 4 1 1 15 3 3 3 2 1 2 50 1 50 2 2 1 4 4 4 1 4 3 1 1 6 6 4 4 4 4 1 2 1 2 50 1 4 4 4 4 1 2

PK PK PK PK PK PK

PK PK

PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK

No No No No No No No No No No No No No No No No Yes Yes No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No

239

73

KRS

74

Presensi_Mahasiswa

75

Perolehan_Nilai _Kuliah_Teori

76

Perolehan_Nilai _Kuliah_Praktikum

Program Jenjang_Pendidikan Pertemuan_ke Tanggal_Kuliah Jam_Masuk Jam_Keluar Ringkasan_Materi Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Kode_Mata_Kuliah_Awal Kode_Mata_Kuliah_Akhir Tahun_Akademik Semester Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Kode_Mata_Kuliah_Awal Kode_Mata_Kuliah_Akhir Tahun_Akademik Semester Tanggal_Kuliah_Presensi Status_Presensi Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Kode_Mata_Kuliah_Awal Kode_Mata_Kuliah_Akhir Tahun_Akademik Semester Skore_Presensi Skore_Kuis Skore_Tugas Skore_Mid Skore_UAS Nilai Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Kode_Mata_Kuliah_Awal Kode_Mata_Kuliah_Akhir Tahun_Akademik Semester Skore_Presensi Skore_Pretest

Char Char Char Date Time Time Memo Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Date Char Char Char Char Char Char Char Char Char Char Num Num Num Num Num Char Char Char Char Char Char Char Char Char Char Num Num

1 2 1 8 4 4

PK PK PK

4 2 2 1 4 4 4 5 1 4 2 2 1 4 4 4 4 1 8 1 4 2 2 1 4 4 4 4 1 2:1 2:1 2:1 2:1 2:1 1 4 2 2 1 4 4 4 4 1 2:1 2:1

PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK

PK PK PK PK PK PK PK PK PK

No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No

240

77

Batas_SKS_IPK

78

Dosen_Wali _Akademik

79

Kerja_Praktek

80

Jenis_Penelitian

81

Nilai_Kerja_Praktek

82

Periode_KKN

83

Komponen_Nilai_KKN _Magang

Skore_Harian Skore_Tugas Skore_Responsi Nilai IPK_Min IPK_Max Minimal_SKS Maksimal_SKS Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Tahun_Akademik Semester Kode_Dosen Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Tanggal_SK No_SK Kode_Dosen Judul_KP Perusahaan Jenis_Penelitian Jenis_Penelitian Nama_Jenis_Penelitian Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Tanggal_Seminar Jumlah_Perserta_Seminar Catatan_Berita_Acara_Seminar Nilai Tahun_Akademik Periode Jumlah_Kelompok Jumlah_Dusun Jumlah_Desa Jumlah_Kecamatan Jumlah_Propinsi Jumlah_DPL Jumlah_Tim_Pendamping Batas_Min_Nilai_A Batas_Min_Nilai_B Batas_Min_Nilai_C Batas_Min_Nilai_D Komponen Nama_Komponen_Nilai_KKN

Num Num Num Char Num Num Num Num Char Char Char Char Char Char Char Char Char Char Char Char Char Date Char Memo Memo Char Char Char Char Char Char Char Char Char Date Num Memo Char Char Char Num Num Num Num Num Num Num Num Num Num Num Char Char

2:1 2:1 2:1 1 1:2 1:2 2 2 4 2 2 1 4 4 1 4 4 2 2 1 4 50 4 2 2 20 4 2 2 1 4

PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK

PK PK PK PK PK PK

2 1 4 1 3 3 2 2 2 3 3 3:2 3:2 3:2 3:2 2 50

PK PK

PK

No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No

241

84

Bobot_Komponen _Nilai_KKN _Magang

85

Jabatan_Panitia_KKN

86

Jabatan_Panitia _KKN _Dosen

87

Jabatan_Mahasiswa _KKN

88

Kelompok_KKN

89

Peserta_KKN

90

Nilai_Peserta_KKN

91

Peserta_KKN_Magang

Tahun_Akademik Periode Komponen Bobot_ Komponen_Nilai_KKN Tahun_Akademik Periode Jabatan_Panitia_KKN Nama_Jabatan_Panitia Tahun_Akademik Periode Kode_Dosen Jabatan_Panitia_KKN Tahun_Akademik Periode Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Jabatan_Panitia_KKN Tahun_Akademik Periode Kelompok Dusun Desa Kecamatan Kode_Dosen Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Tahun_Akademik Periode Kelompok Kode_Dosen Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Komponen Skore Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Perusahaan Nomor_SK Tanggal_SK Tanggal_Mulai Tanggal_Akhir Kode_Dosen

Char Char Char Num Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Num Char Num Char Char Char Char Char Char Char Date Date Date Char

4 1 2 2:2 4 1 2 50 4 1 4 2 4 1 4 2 2 1 4 2 4 1 3 50 50 4 4 4 2 2 1 4 4 1 3 4 2 2 1 4 2 3 4 2 2 1 4 4 50

4

PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK

PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK PK

No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No

242

92

Perusahaan

93

Jenis_Perusahaan

94

Nilai_Peserta_KKN _Magang

95

SKRIPSI_S1

96

97

98

Pembimbing_Skripsi

Nilai_SKRIPSI_S1

Yudisium_Lulus _Mahasiswa

Nama_Pembimbing_Lapangan Perusahaan Nama_Perusahaan Jenis_Perusahaan Alamat Kecamatan Kode_Pos Telepon Faximili E-mail Contact_Person Jenis_Perusahaan Nama_Jenis_Perusahaan Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Komponen Skore Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM No_SK_TA Tanggal_SK_TA Judul_Skripsi Judul_Skripsi_Inggris Jenis_Penelitian Perusahaan Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM No_SK_TA Tanggal_SK_TA Pembimbing_Ke Kode_Dosen Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Nomor_Berita_Acara Tanggal_Pendadaran Penguji_ke Kode_Dosen Skore_Dosen Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM

Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Num Char Char Char Char Char Char Date Memo Memo Char Char Char Char Char Char Char Char Date Char Char Char Char Char Char Char Char Date Char Char Num Char Char Char

50 4 50 1 4 4 5 12 12 2 50 1 50 4 2 2 1 4 2 3 4 2 2 1 4 20

2 4 4 2 2 1 4 20 1 4 4 2 2 1 4 25 1 4 3 4 2 2

PK

PK PK PK PK PK PK PK PK PK PK PK PK

PK PK PK PK PK

PK PK PK PK PK

PK PK PK

No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No Yes No No No No No No No No No No No No No No No No No No No No No No

243

99

Predikat_Lulus

100 Wisuda

101 Alumni

102 Sejarah_Kerja_Alumni

103 Jabatan_Alumni _Di_Perusahaan

Program_NIM Nomor_NIM Tanggal_Yudisium Nomor_Berita_Acara Lama_Masa_Studi IPK SKS Predikat_Lulus Predikat_Lulus Nama_Predikat_Lulus IPK_Min Masa_Studi_Semester_Max Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Tanggal_Wisuda Tahun_NIM Jenjang_Pendidikan_NIM Program_Studi_NIM Program_NIM Nomor_NIM Nomor_Anggota_Alumni Alamat_Tinggal Kecamatan Kode_Pos Telepon Faximili E_mail Nomor_Anggota_Alumni Perusahaan Tanggal_Mulai_Kerja Level_Jabatan_Kerja Gaji Level_Jabatan_Kerja Nama_Level_Jabatan_Kerja

Char Char Date Char Num Num Num Char Char Char Num Num Char Char Char Char Char Date Char Char Char Char Char Char Char Char Char Char Char Char Char Char Date Char Num Char Char

1 4 20 2 1:2 3 20 20 16 1:2 1 4 2 2 1 4 4 2 2 1 4 10 50 4 5 12 20 20 10 8 1 8 1 50

PK PK

PK

PK PK PK PK PK PK PK PK PK PK

PK PK

No No No No No No No No No No No No No No No No No No No No No No No No No No No Yes Yes Yes No No No No No No No

4.2.4. Usulan Panduan Perancangan Struktur Tabel Database Yang Fleksibel Berdasarkan tinjauan tentang konsep perancangan database dan hasil identifikasi faktor-faktor umum penyebab rancangan struktur tabel database yang tidak fleksibel, maka sekalipun menggunakan bahasa yang berbeda, beberapa ahli (antara lain Bradley V. Stone (1998); J. L. Whitten & L. D. Bentley (1998); Jun Yang (1999); Abraham Silberschatz, Henry F. Korth, dan S. Sudarshan (2001);

244

Raymond McLeod dan George Schell (2001); Paul Litwin (2003) yang telah menyampaikan kerangka kerja perancangan database secara terinci; Bo P. Weidema (2003); Jan L. Harrington (2004); Brian Mullen (2005)) menyatakan bahwa fleksibilitas rancangan database dipengaruhi oleh aspek berikut: 1. Kesesuaian dengan model bisnis 2. Penyederhanaan tabel/normalisasi 3. Dokumentasi rancangan database 4. Kemampuan untuk beradaptasi (adaptable) 5. Kemampuan untuk berkembang (scaleable) Selanjutnya, maka rancangan struktur tabel database yang fleksibel akan diperoleh dengan mengikuti serangkaian langkah dengan panduan sebagai berikut: 1. Langkah analisis kebutuhan, meliputi: a. Analisis kebutuhan batasan/ruang lingkup sistem b. Analisis kebutuhan model bisnis c. Analisis keterkaitan antar unit fungsional dalam sistem d. Analisis kebutuhan data dan informasi dalam sistem e. Analisis kemungkinan perubahan situasi/kondisi/kebijakan yang terkait dengan kebutuhan data dan informasi dalam sistem 2. Langkah perancangan, meliputi: a. Perancangan tahap awal, meliputi: 1). Pengelompokan data berdasarkan obyek data 2). Standarisasi nama-nama atribut 3). Standarisasi penggunaan kode data pada atribut

245

4). Perancangan struktur tabel database awal 5). Normalisasi struktur tabel database awal 6). Penentuan PK, FK dan kerelasian antar struktur tabel hasil normalisasi b. Perancangan tahap lanjutan, meliputi: 1). Standarisasi data, yaitu: a). Standarisasi nama-nama atribut b). Standarisasi penggunaan kode data pada atribut yang digunakan antar unit fungsional dalam sistem 2). Pengkodean nilai-nilai data yang digunakan secara berulang pada record, yaitu: a). Untuk nilai-nilai data yang mutlak tidak akan mengalami perubahan di kemudian hari, maka nilai-nilai data perlu dikodekan. Hal ini bertujuan untuk efisiensi penggunaan memori dan menjaga konsistensi data. Misal: i). Data

jenis

kelamin

disimpan

sebagai

L

(untuk

mengkodekan nilai data jenis kelamin Laki-laki) dan P (untuk mengkodekan nilai data jenis kelamin Perempuan) ii). Data

status

marital

disimpan

sebagai

M

(untuk

mengkodekan nilai data status marital Menikah) dan B (untuk mengkodekan nilai data status marital Belum Menikah)

246

iii). Data status aktif disimpan sebagai A (untuk mengkodekan nilai data status Aktif) dan T (untuk mengkodekan nilai data status Tidak Aktif) b). Untuk nilai-nilai data yang memiliki kemungkinan mengalami perubahan di kemudian hari, maka nilai-nilai data perlu dikodekan dan kemudian dirancang tabel referensi. Hal ini bertujuan konsistensi

untuk data,

efisiensi

penggunaan

minimalisasi

memori,

kerangkapan

menjaga

data,

serta

kemudahan pemeliharaan data. Misal: i). Data agama yang dianut seseorang disimpan ke dalam kode-kode data agama, yaitu I (untuk menyatakan agama Islam), K (untuk menyatakan agama Kristen-Katholik), P (untuk menyatakan agama Kristen-Protestan), H (untuk menyatakan agama Hindu), dan B (untuk menyatakan agama Budha). Kemudian dirancang sebuah tabel referensi, yaitu tabel AGAMA. ii). Data kelompok mata kuliah disimpan ke dalam kode-kode kelompok mata kuliah, yaitu W (untuk menyatakan kelompok mata kuliah Wajib), M (untuk menyatakan kelompok mata kuliah Wajib Minat), dan P (untuk menyatakan kelompok mata kuliah Pilihan). Kemudian dirancang

sebuah

tabel

referensi,

KELOMPOK_MATA_KULIAH.

yaitu

tabel

247

iii). Data alamat seseorang disimpan ke dalam kode-kode data alamat, sehingga menjadi tersusun atas 4 (empat) atribut, yaitu Alamat (untuk menyimpan nilai data alamat), Kode_Kecamatan

(untuk

mengkodekan

nilai

data

Kecamatan), Kode_Kabupaten (untuk mengkodekan nilai data Kabupaten), dan Kode_Propinsi (untuk mengkodekan nilai data Propinsi). Kemudian dirancang 3 (tiga) buah tabel referensi, yaitu tabel KECAMATAN, KABUPATEN, dan PROPINSI. c). Untuk kode data berupa kode blok, maka nilai-nilai kode data dalam kode blok perlu dipisahkan, dan kemudian dirancang tabel referensi. Hal ini bertujuan untuk kemudahan perubahan format, urutan, dan perubahan lainnya pada kode blok. Misal: i). Data NIM mahasiswa yang memiliki 4 (empat) komponen dengan

format

Angkatan-Jenjang-Prodi-NomorUrut,

disimpan ke dalam 4 (empat) buah atribut, yaitu Angkatan, Jenjang, Prodi, serta NomorUrut. Kemudian dirancang 3 (tiga) buah tabel referensi, yaitu ANGKATAN, JENJANG, dan PRODI. ii). Data NIK dosen yang memiliki 4 (empat) komponen dengan

format

NomorUrut-BulanTahunLahir-

KelompokDosen, disimpan ke dalam 2 (dua) buah atribut, yaitu

NomorUrut

dan

KelompokDosen.

Sedangkan

248

komponen BulanTahunLahir dapat diperoleh dari atribut Tanggal_Lahir_Dosen. Kemudian dirancang 1 (satu) buah tabel referensi, yaitu KELOMPOK_DOSEN. 3). Perancangan keamanan data, yaitu: a). Keamanan data dari kemungkinan terjadinya kehilangan, kerusakan, kegagalan, atau permasalahan lainnya pada fisik memori, serta mekanisme backup dan restore data secara tersistem maupun manual b). Keamanan data dari kemungkinan akses

secara illegal,

pembatasan kewenangan akses, dan permasalahan lainnya pada akses data 3. Langkah pengujian, meliputi: a. Pengujian kelengkapan data dalam rancangan struktur tabel database. Pengujian dilakukan dengan cara mengecek kembali semua formulir isian data, dan semua keluaran/laporan yang digunakan/diperlukan oleh semua unit fungsional dalam sistem. b. Pengujian kerangkapan data dalam rancangan struktur tabel database. Pengujian dilakukan dengan cara mengecek kembali semua rancangan struktur tabel database menggunakan semua kemungkinan nilai data. c. Pengujian kemungkinan terjadinya inkonsistensi data dalam rancangan struktur tabel database. Pengujian dilakukan dengan cara mengecek kembali semua rancangan struktur tabel database menggunakan semua kemungkinan nilai data.

249

d. Pengujian untuk penggunaan bersama oleh para pemakai/aplikasi dalam unit fungsional lain dalam sistem. Pengujian dilakukan dengan cara mengecek kembali semua rancangan struktur tabel database dari semua sudut pandang unit fungsional dalam sistem. e. Pengujian fleksibilitas rancangan struktur tabel database untuk perubahan nilai-nilai data di kemudian hari. Pengujian dilakukan dengan cara mengecek kembali semua rancangan struktur tabel database berdasarkan kemungkinan terjadinya perubahan nilai-nilai data dan kemudahan perubahan rancangan struktur tabel database sesuai perubahan tersebut. f. Pengujian fleksibilitas rancangan struktur tabel database untuk kebutuhan-kebutuhan pemakai/aplikasi baru. Pengujian dilakukan dengan cara mengecek kembali semua rancangan struktur tabel database berdasarkan kemungkinan terjadinya penambahan kebutuhan baru dan kemudahan perubahan rancangan struktur tabel database sesuai perubahan tersebut. 4. Langkah implementasi, meliputi: a. Pemilihan DBMS yang sesuai dengan kebutuhan dan kemampuan institusi, dengan mempertimbangkan kemudahan untuk melakukan perubahan, pengembangan, dan migrasi data di masa mendatang b. Pendefinisian rancangan struktur tabel database

250

c. Pengisian data dalam rancangan struktur tabel database, dapat menggunakan program aplikasi, query, atau fasilitas lain yang tersedia dalam DBMS d. Penggunaan database, dapat menggunakan program aplikasi, query, atau fasilitas lain yang tersedia dalam DBMS e. Dokumentasi rancangan struktur tabel database f. Pemeliharaan database

BAB V PERANCANGAN DAN IMPLEMENTASI SISTEM

5.1. Perancangan Sistem 5.1.1. Perancangan Model Sistem Sistem yang dikembangkan dalam penelitian ini memiliki tujuan untuk membantu seorang Pakar yang akan melakukan analisis fleksibilitas rancangan struktur tabel database untuk SIAKAD. Model sistem secara logikal dapat ditunjukkan dengan menggunakan sebuah diagram yang disebut Diagram Aliran Data/DAD (Data Flow Diagram/DFD), dimulai dari level 0 atau konteks dan kemudian semakin mendetail ke level-level yang lebih rendah.

5.1.1.1. Diagram Aliran Data/DAD (Data Flow Diagram/DFD) Level 0 Untuk dapat menggambarkan DFD level 0 atau konteks, maka perlu diidentifikasikan komponen penyusun DFD, yaitu: 1. Kesatuan luar (external entity) 2. Proses (process) 3. Aliran data (data flow) Hasil identifikasi komponen DFD level 0 atau konteks, adalah sebagai berikut: 1. Kesatuan luar (external entity) Kesatuan luar yang terlibat di dalam DFD level 0 atau konteks adalah sebanyak 2 (dua) buah, yaitu sebagai berikut:

251

252

a. User User merupakan komponen kesatuan luar yang berperan utama sebagai sumber data dengan memasukkan rancangan struktur tabel database yang akan dianalisis. User adalah perancang struktur tabel database. Selain itu, User juga berperan sebagai penerima informasi hasil analisis fleksibilitas rancangan struktur tabel database dengan memberikan masukan kriteria informasi yang diinginkannya. b. Pakar Pakar merupakan komponen kesatuan luar yang berperan utama melakukan analisis dengan cara memberikan penilaian terhadap fleksibilitas rancangan struktur tabel database. Pakar adalah orang yang memiliki kecakapan yang memadai tentang konsep dan perancangan database. Pakar juga berhak melakukan inisialisasi data yang diperlukan pada proses analisis. Selain itu, Pakar juga berperan sebagai penerima informasi hasil analisis fleksibilitas rancangan struktur tabel database dengan memberikan masukan kriteria informasi yang diinginkannya. 2. Proses (process) Proses utama pada sistem dikembangkan sebagai sebuah perangkat lunak program aplikasi yang diberi nama Analisis Fleksibilitas Rancangan Struktur Tabel Database.

253

3. Aliran data (data flow) Aliran data yang terlibat di dalam DFD level 0 atau konteks adalah sebanyak 7 (tujuh) buah, yaitu sebagai berikut: a. Setup data Setup data merupakan inisialisasi nilai untuk sistem untuk melakukan proses analisis fleksibilitas rancangan struktur tabel database yang diberikan oleh seorang Pakar, mengalir dari kesatuan luar Pakar ke proses Analisis Fleksibilitas Rancangan Struktur Tabel Database (Proses 0). Setup data meliputi 3 (tiga) macam data, yaitu: 1). Data user, digunakan untuk inisialiasi data-data user yang berhak mengakses sistem. 2). Data pendidikan, digunakan untuk inisialiasi data-data jenjang pendidikan Perancang rancangan struktur tabel database. 3). Data tingkat fleksibilitas, digunakan untuk inisialiasi data-data Tingkat Fleksibilitas pada hasil analisis rancangan struktur tabel database. b. Rancangan struktur tabel database Rancangan struktur tabel database merupakan data rancangan struktur tabel database yang akan dianalisis oleh Pakar, mengalir dari kesatuan luar User ke proses Analisis Fleksibilitas Rancangan Struktur Tabel Database (Proses 0).

254

c. Penilaian Penilaian merupakan penilaian atas fleksibilitas rancangan struktur tabel database yang diberikan oleh seorang Pakar, mengalir dari kesatuan luar Pakar ke proses Analisis Fleksibilitas Rancangan Struktur Tabel Database (Proses 0). d. Kriteria informasi Kriteria informasi merupakan jenis pilihan informasi hasil analisis fleksibilitas rancangan struktur tabel database yang diinginkan oleh User, mengalir dari proses Laporan hasil analisis (Proses 0) ke kesatuan luar User. e. Kriteria informasi Kriteria informasi merupakan jenis pilihan informasi hasil analisis fleksibilitas rancangan struktur tabel database yang diinginkan oleh Pakar, mengalir dari proses Laporan hasil analisis (Proses 0) ke kesatuan luar Pakar. f. Informasi hasil analisis Informasi hasil analisis merupakan informasi hasil analisis fleksibilitas rancangan struktur tabel database, mengalir dari proses Analisis Fleksibilitas Rancangan Struktur Tabel Database (Proses 0) ke kesatuan luar Pakar. g. Informasi hasil analisis Informasi hasil analisis merupakan informasi hasil analisis fleksibilitas rancangan struktur tabel database, mengalir dari proses Analisis

255

Fleksibilitas Rancangan Struktur Tabel Database (Proses 0) ke kesatuan luar Pakar. Berdasarkan hasil identifikasi komponen penyusun DFD tersebut, selanjutnya dapat digambarkan model logikal dalam bentuk DFD level 0 atau konteks untuk sistem yang akan dikembangkan. DFD level 0 yang melibatkan komponen kesatuan luar, proses, dan aliran data ditampilkan dalam Gambar 5.1.

Rancangan struktur tabel database

User

Kriteria informasi Informasi hasil analisis

0 Analisis fleksibilitas rancangan struktur tabel database

Setup data Penilaian Kriteria informasi

Pakar

Informasi hasil analisis

Gambar 5.1: Model logikal sistem dalam bentuk DFD level 0 atau konteks

5.1.1.2. Diagram Aliran Data/DAD (Data Flow Diagram/DFD) Level 1 Sebagaimana dalam penggambaran DFD level 0 atau konteks, untuk dapat menggambarkan DFD level 1, maka perlu diidentifikasikan kembali tentang detail komponen proses, dan detail komponen aliran data. Sedangkan komponen kesatuan luar tetap sama seperti dalam DFD level 0 atau konteks. Selain itu, juga perlu diidentifikasikan komponen simpanan data yang terlibat dalam sistem. Hasil identifikasi komponen DFD untuk level 1, adalah sebagai berikut: 1. Kesatuan luar (external entity) Kesatuan luar yang terlibat dalam DFD level 1 adalah sama dengan kesatuan luar yang terlibat dalam DFD level 0 atau konteks, sebanyak 2 (dua) buah, yaitu:

256

a. User User merupakan komponen kesatuan luar yang berperan utama sebagai sumber data dengan memasukkan rancangan struktur tabel database yang akan dianalisis. User adalah perancang struktur tabel database. Selain itu, User juga berperan sebagai penerima informasi hasil analisis fleksibilitas rancangan struktur tabel database dengan memberikan masukan kriteria informasi yang diinginkannya. b. Pakar Pakar merupakan komponen kesatuan luar yang berperan utama melakukan analisis dengan cara memberikan penilaian terhadap fleksibilitas rancangan struktur tabel database. Pakar adalah orang yang memiliki kecakapan yang memadai tentang konsep dan perancangan database. Pakar juga berhak melakukan setup/inisialisasi data yang diperlukan pada proses analisis. Selain itu, Pakar juga berperan sebagai penerima informasi hasil analisis fleksibilitas rancangan struktur tabel database dengan memberikan masukan kriteria informasi yang diinginkannya. 2. Proses (process) Proses untuk Analisis Fleksibilitas Rancangan Struktur Tabel Database terdiri atas 4 (empat) bagian proses, yaitu sebagai berikut: a. Setup data (Proses 1) Setup data merupakan bagian proses untuk inisialisasi data-data awal yang diperlukan oleh sistem. Setup data ini dilakukan melalui

257

keyboard dengan menggunakan form input pada layar/monitor. Selanjutnya, inisialisasi data yang dimasukkan ini akan disimpan dalam 3 (tiga) buah simpanan data, yaitu TblUser (D1), TblPendidikan (D2) dan TblFleksibilitas (D3). b. Input rancangan struktur tabel database (Proses 2) Input rancangan struktur tabel database merupakan bagian proses untuk memasukkan data rancangan, data detail rancangan struktur tabel database yang akan dianalisis, dan analisis rancangan struktur tabel database. Pemasukkan data rancangan dan data detail rancangan struktur tabel database ini dilakukan melalui keyboard dengan menggunakan form input pada layar/monitor. Selanjutnya, data rancangan dan data detail rancangan struktur tabel database yang dimasukkan ini akan disimpan dalam 3 (dua) buah simpanan data, yaitu TblData (D4), TblDataTabel (D5), dan TblDataAtribut (D6). c. Penilaian rancangan struktur tabel database (Proses 3) Penilaian rancangan struktur tabel database merupakan bagian proses untuk melakukan analisis fleksibilitas terhadap detail rancangan struktur tabel database. Proses analisis fleksibilitas rancangan struktur tabel database ini dilakukan oleh Pakar dengan cara memberikan penilaian terhadap rancangan struktur tabel database berdasarkan kepakarannya. Dengan demikian, penilaian yang diberikan akan memiliki sifat yang subyektif, tergantung tingkat kepakaran Pakar.

258

Selanjutnya, hasil analisis tersebut akan disimpan dalam 2 (dua) buah simpanan data, yaitu TblHasil (D7) dan TblHasilDetail (D8). d. Laporan hasil analisis rancangan struktur tabel database (Proses 4) Laporan hasil analisis rancangan struktur tabel database merupakan bagian proses untuk menampilkan informasi hasil analisis fleksibilitas rancangan struktur tabel database. Output informasi berupa laporan hasil analisis fleksibilitas rancangan struktur tabel database ini ditujukan kepada kesatuan luar User dan Pakar. 3. Aliran data (data flow) Aliran data yang terlibat di dalam DFD level 1 adalah sebanyak 23 (dua puluh tiga) buah, yaitu sebagai berikut: a. Setup data user, pendidikan, tingkat fleksibilitas Setup data user, pendidikan, tingkat fleksibilitas merupakan data inisilisasi yang diperlukan oleh sistem, mengalir dari kesatuan luar Pakar ke proses Setup data (Proses 1). b. Record User Record User merupakan record data User yang diinisialisasikan oleh Pakar, mengalir dari proses Setup data (Proses 1) ke simpanan data TblUser (D1). c. Record pendidikan Record

pendidikan

merupakan

record

data

pendidikan

yang

diinisialisasikan oleh Pakar, mengalir dari proses Setup data (Proses 1) ke simpanan data TblPendidikan (D2).

259

d. Record tingkat fleksibilitas Record tingkat fleksibilitas merupakan record data tingkat fleksibilitas yang diinisialisasikan oleh Pakar, mengalir dari proses Setup data (Proses 1) ke simpanan data TblFleksibilitas (D3). e. Rancangan struktur tabel database Rancangan struktur tabel database merupakan data rancangan struktur tabel database, mengalir dari kesatuan luar User ke proses Input rancangan struktur tabel database (Proses 2). f. Record data Record data merupakan record data rancangan struktur tabel database, mengalir dari proses Input rancangan struktur tabel database (Proses 2) ke simpanan data TblData (D4). g. Record data tabel Record data tabel merupakan record data tabel rancangan struktur tabel database, mengalir dari proses Input rancangan struktur tabel database (Proses 2) ke simpanan data TblDataTabel (D5). h. Record data atribut Record data atribut merupakan record data nam-nama atribut dan keterangan terkait dengan atribut pada rancangan struktur tabel database, mengalir dari proses Input rancangan struktur tabel database (Proses 2) ke simpanan data TblDataAtribut (D6).

260

i. Record data tabel Record data tabel merupakan record data nama-nama tabel rancangan struktur tabel database, mengalir dari simpanan data TblDataTabel (D5) ke proses Analisis rancangan struktur tabel database (Proses 3). j. Record data atribut Record data atribut merupakan record data nama-nama atribut dan keterangan terkait dengan atribut pada rancangan struktur tabel database, mengalir dari simpanan data TblDataAtribut (D6) ke proses Analisis rancangan struktur tabel database (Proses 3). k. Record data Record data merupakan record data rancangan struktur tabel database, mengalir dari simpanan data TblData (D4) ke proses Analisis rancangan struktur tabel database (Proses 3). l. Record tingkat fleksibilitas Record tingkat fleksibilitas merupakan record data tingkat fleksibilitas, mengalir dari simpanan data TblFleksibilitas (D3) ke proses Analisis rancangan struktur tabel database (Proses 3). m. Record pendidikan Record pendidikan merupakan record data pendidikan, mengalir dari simpanan data TblPendidikan (D2) ke proses Analisis rancangan struktur tabel database (Proses 3).

261

n. Record user Record User merupakan record data User, mengalir dari simpanan data TblUser (D1) ke proses Analisis rancangan struktur tabel database (Proses 3). o. Penilaian Penilaian merupakan penilaian terhadap rancangan struktur tabel database, mengalir dari kesatuan luar Pakar ke proses Analisis rancangan struktur tabel database (Proses 3). p. Record hasil Record hasil merupakan record data hasil analisis terhadap rancangan struktur tabel database, mengalir dari proses Analisis rancangan struktur tabel database (Proses 3) ke simpanan data TblHasil (D7). q. Record hasil detail hasil Record hasil detail merupakan record data detail hasil analisis terhadap rancangan struktur tabel database, mengalir dari proses Analisis rancangan struktur tabel database (Proses 3) ke simpanan data TblHasilDetail (D8). r. Record hasil Record hasil merupakan record data hasil analisis terhadap rancangan struktur tabel database, mengalir dari simpanan data TblHasil (D7) ke proses Laporan hasil analisis (Proses 4).

262

s. Record hasil detail Record hasil detail merupakan record data detail hasil analisis terhadap rancangan struktur tabel database, mengalir dari simpanan data TblHasilDetail (D8) ke proses Laporan hasil analisis (Proses 4). t. Kriteria informasi Kriteria informasi merupakan jenis pilihan informasi hasil analisis fleksibilitas rancangan struktur tabel database yang diinginkan oleh User, mengalir dari proses Laporan hasil analisis (Proses 4) ke kesatuan luar User. u. Kriteria informasi Kriteria informasi merupakan jenis pilihan informasi hasil analisis fleksibilitas rancangan struktur tabel database yang diinginkan oleh Pakar, mengalir dari proses Laporan hasil analisis (Proses 4) ke kesatuan luar Pakar. v. Informasi hasil analisis Informasi hasil analisis merupakan informasi hasil analisis fleksibilitas rancangan struktur tabel database, mengalir dari proses Laporan hasil analisis (Proses 4) ke kesatuan luar User. w. Informasi hasil analisis Informasi hasil analisis merupakan informasi hasil analisis fleksibilitas rancangan struktur tabel database, mengalir dari proses Laporan hasil analisis (Proses 4) ke kesatuan luar Pakar.

263

4. Simpanan data (data store) Komponen simpanan data yang terlibat dalam sistem adalah sebanyak 7 (tujuh) buah, yaitu sebagai berikut: a. TblUser (D1) TblUser merupakan komponen simpanan data yang berfungsi untuk menyimpan record data User yang diinputkan oleh kesatuan luar Pakar melalui proses Setup data (Proses 1) sebagai inisialisasi User sistem. b. TblPendidikan (D2) TblPendidikan

merupakan

komponen

simpanan

data

yang

berfungsi untuk menyimpan record data pendidikan yang diinputkan oleh kesatuan luar Pakar melalui proses Setup data (Proses 1) sebagai inisialisasi untuk proses analisis feksibilitas rancangan struktur database. c. TblFleksibilitas (D3) TblFleksibilitas merupakan komponen simpanan data yang berfungsi untuk menyimpan record data tingkat fleksibilitas yang diinputkan oleh kesatuan luar Pakar melalui proses Setup data (Proses 1) sebagai inisialisasi untuk proses analisis feksibilitas rancangan struktur database. d. TblData (D4) TblData merupakan komponen simpanan data yang berfungsi untuk menyimpan record data yang bersifat umum tentang

264

rancangan struktur tabel database yang diinputkan oleh kesatuan luar User dan akan dianalisis oleh Pakar. e. TblDataTabel (D5) TblDataTabel merupakan komponen simpanan data yang berfungsi untuk menyimpan record data nama-nama tabel rancangan struktur tabel database yang telah diinputkan oleh kesatuan luar User dan akan dianalisis oleh Pakar. f. TblDataAtribut (D6) TblDataAtribut merupakan komponen simpanan data yang berfungsi untuk menyimpan record data nama-nama atribut dan keterangan terkait dengan atribut pada rancangan struktur tabel database yang telah diinputkan oleh kesatuan luar User dan akan dianalisis oleh Pakar. g. TblHasil (D8) TblHasil merupakan komponen simpanan data yang berfungsi untuk menyimpan record data hasil analisis fleksibilitas rancangan struktur database yang telah diberikan oleh Pakar. h. TblHasilDetail (D8) TblHasilDetail

merupakan

komponen

simpanan

data yang

berfungsi untuk menyimpan record data detail hasil analisis fleksibilitas rancangan struktur database yang telah diberikan oleh Pakar.

265

Berdasarkan hasil identifikasi komponen penyusun DFD untuk level 1 tersebut, selanjutnya dapat digambarkan model logikal dalam bentuk DFD level 1 untuk sistem yang akan dikembangkan, yaitu seperti ditampilkan dalam Gambar 5.2.

Setup data user, pendidikan, tingkat fleksibilitas

Record user

1 Setup data

D1 TblUser

Record pendidikan

D2 TblPendidikan

Record tingkat fleksibilitas

D3 TblFleksibilitas

Rancangan struktur tabel database

User

2 Input rancangan struktur tabel database

Record data

D4 TblData

Record data tabel

D5 TblDataTabel Record data atribut

D6 TblDataAtribut

Record data atribut

3 Proses analisis rancangan struktur tabel database Record hasil

Record hasil detail

Record data tabel Record data Record tingkat fleksibilitas Record pendidikan Record User Penilaian

Pakar D7 TblHasil

D8 TblHasilDetail

Record hasil

Record hasil detail

Kriteria informasi

4 Laporan hasil analisis

Kriteria informasi Informasi hasil analisis

Gambar 5.2: Model logikal sistem dalam bentuk DFD level 1

266

5.1.1.3. Diagram Aliran Data/DAD (Data Flow Diagram/DFD) Level 2 Sebagaimana penggambaran DFD level 0 atau konteks dan DFD level 1, untuk dapat menggambarkan DFD level 2, maka perlu diidentifikasikan kembali tentang detail komponen proses, detail komponen aliran data, komponen kesatuan luar, dan komponen simpanan data yang terlibat untuk setiap bagian proses.

5.1.1.3.1. Diagram Aliran Data/DAD (Data Flow Diagram/DFD) Level 2 Proses 1 Proses 1 dalam Analisis Fleksibilitas Rancangan Struktur Tabel Database adalah Setup data. Hasil identifikasi komponen DFD level 2 untuk Proses 1, adalah sebagai berikut: 1. Kesatuan luar (external entity) Kesatuan luar yang terlibat dalam DFD level 2 untuk Proses 1 adalah sebanyak 1 (satu) buah, yaitu Pakar. Kesatuan luar Pakar berperan sebagai sumber data dengan memasukkan inisialisasi data-data User, pendidikan, dan tingkat fleksibilitas. Pakar adalah seseorang yang akan menganalisis fleksibilitas rancangan struktur tabel database. 2. Proses (process) Proses 1 terdiri atas 3 (tiga) bagian proses, yaitu sebagai berikut: a. Setup data User (Proses 1.1) Setup data User merupakan inisialisasi data User sistem, mengalir dari kesatuan luar Pakar menuju proses Setup data User (Proses

267

1.1). Data inisialisasi ini kemudian akan disimpan ke dalam simpanan data TblUser (D1). b. Setup data pendidikan (Proses 1.2) Setup data pendidikan merupakan bagian proses untuk inisialisasi data jenjang pendidikan yang akan digunakan pada data Perancang rancangan struktur tabel database. Data inisialisasi ini kemudian akan disimpan ke dalam simpanan data TblPendidikan (D2). c. Setup data tingkat fleksibilitas (Proses 1.3) Setup data tingkat fleksibilitas merupakan bagian proses untuk inisialisasi data tingkat fleksibilitas yang akan digunakan untuk analisis rancangan struktur tabel database. Data inisialisasi ini kemudian akan disimpan ke dalam simpanan data TblFleksibilitas (D3). 3. Aliran data (data flow) Aliran data (data flow) yang terlibat di dalam DFD level 2 untuk Proses 1 adalah sebanyak 6 (enam) buah, yaitu sebagai berikut: a. Setup data User Setup data User merupakan inisialisasi data User sistem, mengalir dari kesatuan luar Pakar menuju proses Setup data User (Proses 1.1). Data inisialisasi ini kemudian akan disimpan ke dalam simpanan data TblUser (D1).

268

b. Setup data pendidikan Setup data pendidikan merupakan inisialisasi data jenjang pendidikan yang akan digunakan pada data Perancang struktur tabel database, mengalir dari kesatuan luar Pakar menuju proses Setup data pendidikan (Proses 1.2). Data pendidikan kemudian akan disimpan ke dalam simpanan data TblPendidikan (D2). c. Setup data tingkat fleksibilitas (Proses 1.3) Setup data tingkat fleksibilitas merupakan inisialisasi data tingkat fleksibilitas yang akan digunakan untuk analisis rancangan struktur tabel database, mengalir dari kesatuan luar Pakar menuju proses Setup data tingkat fleksibilitas (Proses 1.3). Data inisialisasi ini kemudian akan disimpan ke dalam simpanan data TblFleksibilitas (D3). d. Record user Record user merupakan record hasil inisialisasi data User yang diinputkan oleh Pakar, mengalir dari proses Setup data User (Proses 1.1) menuju ke simpanan data TblUser (D1). e. Record pendidikan Record pendidikan merupakan record hasil inisialisasi data pendidikan yang diinputkan oleh Pakar, mengalir dari proses Setup data pendidikan (Proses TblPendidikan (D2).

1.2) menuju ke

simpanan

data

269

f. Record tingkat fleksibilitas Record tingkat fleksibilitas merupakan record hasil inisialisasi data tingkat fleksibilitas yang diinputkan oleh Pakar, mengalir dari proses Setup data tingkat fleksibilitas (Proses 1.3) menuju ke simpanan data TblFleksibilitas (D3). 4. Simpanan data (data store) Komponen simpanan data (data store) yang terlibat dalam Proses 1 adalah sebanyak 3 (tiga) buah, yaitu sebagai berikut: a. TblUser (D1) TblUser merupakan komponen simpanan data yang berfungsi untuk menyimpan record data User yang diinputkan oleh kesatuan luar Pakar. b. TblPendidikan (D2) TblPendidikan

merupakan

komponen

simpanan

data

yang

berfungsi untuk menyimpan record data pendidikan yang diinputkan oleh kesatuan luar Pakar. c. TblFleksibilitas (D3) TblFleksibilitas merupakan komponen simpanan data yang berfungsi untuk menyimpan record data tingkat fleksibilitas yang diinputkan oleh kesatuan luar Pakar. Berdasarkan hasil identifikasi komponen penyusun DFD tersebut, selanjutnya dapat digambarkan model logikal dalam bentuk DFD level 2 untuk Proses 1 yang akan dikembangkan, yaitu sebagaimana ditampilkan pada Gambar 5.3.

270

Pakar

Setup data User

Setup data pendidikan

Setup data tingkat fleksibilitas

1.1 Setup data User

1.2 Setup data pendidikan

1.3 Setup data tingkat fleksibilitas

Record user

Record pendidikan

Record tingkat fleksibilitas

D1 TblUser

D2 TblPendidiikan

D3 TblFleksibilitas

Gambar 5.3: Model logikal sistem dalam bentuk DFD level 2 untuk Proses 1

5.1.1.3.2. Diagram Aliran Data/DAD (Data Flow Diagram/DFD) Level 2 Proses 2 Proses 2 dalam Analisis Fleksibilitas Rancangan Struktur Tabel Database adalah Input rancangan struktur tabel database. Hasil identifikasi komponen DFD level 2 untuk Proses 2, adalah sebagai berikut: 1. Kesatuan luar (external entity) Kesatuan luar yang terlibat dalam DFD level 2 untuk Proses 1 adalah sebanyak 1 (satu) buah, yaitu User. Kesatuan luar User berperan sebagai sumber data dengan memasukkan rancangan struktur tabel database yang akan dianalisis. User adalah perancang struktur tabel database. 2. Proses (process) Proses 1 terdiri atas 1 (satu) bagian proses, yaitu:

271

a. Input rancangan struktur tabel database (Proses 2.1) Input rancangan struktur tabel database merupakan bagian proses untuk memasukkan data rancangan struktur tabel database yang akan dianalisis, yang disimpan ke dalam 3 (tiga) buah simpanan data, yaitu TblData (D4), TblDataTabel (D5), dan TblDataAtribut (D6). 3. Aliran data (data flow) Aliran data (data flow) yang terlibat di dalam DFD level 2 untuk Proses 2 adalah sebanyak 4 (empat) buah, yaitu sebagai berikut: a. Rancangan struktur tabel database Rancangan struktur tabel database merupakan data rancangan struktur tabel database, mengalir dari kesatuan luar User ke proses Input rancangan struktur tabel database (Proses 2.1). b. Record data Record data merupakan record data rancangan struktur tabel database, mengalir dari proses Input rancangan struktur tabel database (Proses 2.1) ke simpanan data TblData (D4). c. Record data tabel Record data tabel merupakan record data nama-nama tabel dalam rancangan struktur tabel database, mengalir dari proses Input rancangan struktur tabel database (Proses 2.1) ke simpanan data TblDataTabel (D5).

272

d. Record data atribut Record data atribut merupakan record data nama-nama atribut dan keterangan yang terkait dengan atribut dalam rancangan struktur tabel database, mengalir dari proses Input rancangan struktur tabel database (Proses 2.1) ke simpanan data TblDataAtribut (D6). 4. Simpanan data (data store) Komponen simpanan data (data store) yang terlibat dalam DFD level 2 untuk Proses 2 adalah sebanyak 3 (tiga) buah, yaitu sebagai berikut: a. TblData (D4) TblData merupakan komponen simpanan data yang berfungsi untuk menyimpan record data yang bersifat umum tentang rancangan struktur tabel database yang diinputkan oleh kesatuan luar User. b. TblDataTabel (D5) TblDetailData

merupakan

komponen

simpanan

data

yang

berfungsi untuk menyimpan record data nama-nama tabel dalam rancangan struktur tabel database yang diinputkan oleh kesatuan luar User. c. TblDataAtribut (D5) TblDataAtribut merupakan komponen simpanan data yang berfungsi untuk menyimpan record data nama-nama atribut dan keterangan yang terkait dengan atribut dalam rancangan struktur tabel database yang diinputkan oleh kesatuan luar User.

273

Berdasarkan hasil identifikasi komponen penyusun DFD tersebut, selanjutnya dapat digambarkan model logikal dalam bentuk DFD level 2 untuk Proses 2 yang akan dikembangkan, yaitu sebagaimana ditampilkan pada Gambar 5.4. Record data

User

Rancangan struktur tabel database

2.1 Input rancangan struktur tabel database

Record data tabel

D4 TblData D5 TblDataTabel

Record data atribut

D6 TblDataAtribut

Gambar 5.4: Model logikal sistem dalam bentuk DFD level 2 untuk Proses 2

5.1.1.3.3. Diagram Aliran Data/DAD (Data Flow Diagram/DFD) Level 2 Proses 3 Proses 3 dalam Analisis Fleksibilitas Rancangan Struktur Tabel Database adalah Proses analisis rancangan struktur tabel database. Hasil identifikasi komponen DFD level 2 untuk Proses 3, adalah sebagai berikut: 1. Kesatuan luar (external entity) Kesatuan luar yang terlibat dalam DFD level 2 untuk Proses 3 adalah sebanyak 1 (satu) buah, yaitu Pakar. Kesatuan luar Pakar berperan melakukan analisis dengan cara memberikan penilaian terhadap fleksibilitas rancangan struktur tabel database. Pakar adalah orang yang memiliki kecakapan yang memadai tentang konsep dan perancangan database. 2. Proses (process) Proses 3 terdiri atas 1 (satu) bagian proses, yaitu:

274

a. Proses analisis rancangan struktur tabel database (Proses 3.1) Proses analisis rancangan struktur tabel database merupakan bagian proses untuk menganalisis data rancangan dan data detail rancangan struktur tabel database yang akan dianalisis. Proses analisis rancangan struktur tabel database adalah berupa penilaian yang diberikan oleh Pakar. 3. Aliran data (data flow) Aliran data yang terlibat di dalam DFD level 2 untuk Proses 3 adalah sebanyak 5 (lima) buah, yaitu sebagai berikut: a. Record rancangan struktur tabel database Record rancangan struktur tabel database merupakan record data rancangan struktur tabel database, mengalir dari simpanan data TblData (D4) ke Proses analisis rancangan struktur tabel database (Proses 3.1). b. Record data tabel Record data tabel merupakan record data nama-nama tabel dalam rancangan struktur tabel database, mengalir dari simpanan data TblDataTabel (D5) ke Proses analisis rancangan struktur tabel database (Proses 3.1). c. Record data atribut Record data atribut merupakan record data nama-nama atribut dan keterangan terkait dengan atribut dalam rancangan struktur tabel

275

database, mengalir dari simpanan data TblDataAtribut (D6) ke Proses analisis rancangan struktur tabel database (Proses 3.1). d. Penilaian Penilaian merupakan penilaian terhadap rancangan struktur tabel database, mengalir dari kesatuan luar Pakar ke Proses analisis rancangan struktur tabel database (Proses 3.1). e. Record hasil Record hasil merupakan record data hasil analisis rancangan struktur tabel database, mengalir dari Proses analisis rancangan struktur tabel database (Proses 3.1) ke simpanan data TblHasil (D7). f. Record hasil detail Record hasil detail merupakan record data detail hasil analisis rancangan struktur tabel database, mengalir dari Proses analisis rancangan struktur tabel database (Proses 3.1) ke simpanan data TblHasilDetail (D8). 4. Simpanan data (data store) Komponen simpanan data yang terlibat dalam DFD level 2 untuk Proses 3 adalah sebanyak 4 (empat) buah, yaitu sebagai berikut: a. TblData (D4) TblData merupakan komponen simpanan data yang berfungsi sebagai sumber data, mengalir dari simpanan data TblData (D4) ke Proses analisis rancangan struktur tabel database (Proses 3.1).

276

b. TblDetailData (D5) TblDetailData

merupakan

komponen

simpanan

data

yang

berfungsi sebagai sumber data, mengalir dari simpanan data TblDetailData (D5) ke Proses analisis rancangan struktur tabel database (Proses 3.1). c. TblHasil (D7) TblHasil merupakan komponen simpanan data yang berfungsi untuk menyimpan record data hasil analisis fleksibilitas pada rancangan struktur database, mengalir dari Proses analisis rancangan struktur tabel database (Proses 3.1) ke simpanan data TblHasil (D7). d. TblHasilDetail (D8) TblHasilDetail

merupakan

komponen

simpanan

data yang

berfungsi untuk menyimpan record data detail hasil analisis fleksibilitas pada rancangan struktur database, mengalir dari Proses analisis rancangan struktur tabel database (Proses 3.1) ke simpanan data TblHasilDetail (D8). Berdasarkan hasil identifikasi komponen penyusun DFD tersebut, selanjutnya dapat digambarkan model logikal dalam bentuk DFD level 2 untuk Proses 3 yang akan dikembangkan, yaitu sebagaimana ditampilkan pada Gambar 5.5.

277

D4 TblData

Record data

D5 TblDataTabel

Record data tabel

D6 TblDataAtribut

3.1 Proses analisis rancangan struktur tabel database

Record data atribut

Record hasil

D7 TblHasil

Penilaian

Pakar

Record hasil detail

D7 8TblHasilDetail

Gambar 5.5: Model logikal sistem dalam bentuk DFD level 2 untuk Proses 3

5.1.1.3.4. Diagram Aliran Data/DAD (Data Flow Diagram/DFD) Level 2 Proses 4 Proses 3 dalam Analisis Fleksibilitas Rancangan Struktur Tabel Database adalah Laporan hasil analisis rancangan struktur tabel database. Hasil identifikasi komponen DFD level 2 untuk Proses 4, adalah sebagai berikut: 1. Kesatuan luar (external entity) Kesatuan luar yang terlibat dalam DFD level 2 untuk Proses 4 adalah sama dengan kesatuan luar yang terlibat dalam DFD level 0 atau konteks, sebanyak 2 (dua) buah, yaitu: a. User User merupakan kesatuan luar yang berperan sebagai penerima informasi hasil analisis fleksibilitas rancangan struktur tabel database. b. Pakar Pakar merupakan kesatuan luar yang berperan sebagai penerima informasi hasil analisis fleksibilitas rancangan struktur tabel database.

278

2. Proses (process) Proses dalam DFD level 2 untuk Proses 4 terdiri atas 1 (satu) bagian proses, yaitu sebagai berikut: a. Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1) Tampilkan hasil analisis rancangan struktur tabel database merupakan bagian proses untuk menampilkkan hasil analisis terhadap rancangan dan detail rancangan struktur tabel database. 3. Aliran data (data flow) Aliran data yang terlibat di dalam DFD level 2 untuk Proses 4 adalah sebanyak 11 (sebelas) buah, yaitu sebagai berikut: a. Record pendidikan Record pendidikan merupakan record data pendidikan, mengalir dari simpanan data TblPendidikan (D2) ke proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1). b. Record fleksibilitas Record fleksibilitas merupakan record data tingkat fleksibilitas, mengalir dari simpanan data TblFleksibilitas (D3) ke proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1).

279

c. Record data Record data merupakan record data rancangan struktur tabel database, mengalir dari simpanan data TblData (D4) ke proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1). d. Record data tabel Record data tabel merupakan record data nama-nama tabeldalam rancangan struktur tabel database, mengalir dari simpanan data TblDataTabel (D5) ke proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1). e. Record data atribut Record data atribut merupakan record data nama-nama atribut dan keterangan yang terkait dengan atribut dalam rancangan struktur tabel database, mengalir dari simpanan data TblDataAtribut (D6) ke proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1). f. Kriteria informasi Kriteria informasi merupakan kriteria pilihan informasi hasil analisis fleksibilitas rancangan struktur tabel database yang diinginkan oleh User, mengalir dari kesatuan luar User ke proses Baca kriteria informasi (Proses 4.1). g. Kriteria informasi Kriteria informasi merupakan jenis pilihan informasi hasil analisis fleksibilitas rancangan struktur tabel database yang diinginkan oleh

280

Pakar, mengalir dari kesatuan luar Pakar ke proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1). h. Record hasil Record hasil merupakan record data hasil analisis terhadap rancangan struktur tabel database, mengalir dari simpanan data TblHasil (D7) ke proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1). i. Record hasil detail Record hasil detail merupakan record data detail hasil analisis terhadap rancangan struktur tabel database, mengalir dari simpanan data TblHasilDetail (D8) ke proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1). j. Informasi hasil analisis Informasi hasil analisis merupakan informasi hasil analisis fleksibilitas rancangan struktur tabel database, mengalir dari proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1) ke kesatuan luar User. k. Informasi hasil analisis Informasi hasil analisis merupakan informasi hasil analisis fleksibilitas rancangan struktur tabel database, mengalir dari proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1) ke kesatuan luar Pakar.

281

4. Simpanan data (data store) Komponen simpanan data yang terlibat dalam DFD level 2 untuk Proses 4 adalah sebanyak 7 (tujuh) buah, yaitu sebagai berikut: a. TblPendidikan (D2) TblPendidikan merupakan sumber data untuk proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1). b. TblFleksibilitas (D3) TblFleksibilitas merupakan sumber data untuk proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1). c. TblData (D4) TblData merupakan sumber data untuk proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1). d. TblDataTabel (D5) TblDataTabel merupakan sumber data untuk proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1). e. TblDataAtribut (D6) TblDataAtribut merupakan sumber data untuk proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1). f. TblHasil (D7) TblHasil merupakan sumber data untuk proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1).

282

g. TblHasilDetail (D8) TblHasilDetail merupakan sumber data untuk proses Tampilkan hasil analisis rancangan struktur tabel database (Proses 4.1). Berdasarkan hasil identifikasi komponen penyusun DFD tersebut, selanjutnya dapat digambarkan model logikal dalam bentuk DFD level 2 untuk Proses 4 yang akan dikembangkan, yaitu sebagaimana ditampilkan pada Gambar 5.6. D4 TblData

D3 TblFleksibilitas

D2 TblPendidikan

D5 TblDataTabel D6 TblDataAtribut

D7 TblHasil Record tingkat fleksibilitas

Record data Kriteria informasi

User

D8 TblHasilDetail

Record hasil detail

Record data atribut Record data tabel

Record pendidikan

4.1 Tampilkan hasil analisis struktur tabel database

Informasi hasil analisis

Record hasil

Kriteria informasi Informasi hasil analisis

Pakar

1

Gambar 5.6: Model logikal sistem dalam bentuk DFD level 2 untuk Proses 4

5.1.2. Perancangan Model Data Model data merupakan suatu cara untuk menjelaskan tentang data-data yang tersimpan dalam database dan bagaimana hubungan antar data tersebut untuk pengguna (User) secara logikal. Model data juga dapat digunakan sebagai dasar untuk perancangan struktur tabel database. Salah satu model data yang banyak digunakan dalam adalah Model kerelasian antar entitas (Entity

283

Relationship Model/ER_M). ER_M ditunjukkan pada bentuk sebuah diagram yang

disebut

diagram

kerelasian

antar

entitas

(Entity

Relationship

Diagram/ER_D). Untuk dapat menggambarkan ER_D perlu diidentifikasikan komponen-komponen penyusun ER_D, yaitu entitas (entity), atribut (attribute), dan kerelasian (relationship) antar entitas. Berdasarkan model logikal sistem yang digambarkan dalam bentuk DFD (level 0 atau konteks, level 1, dan level 2), selanjutnya dapat diidentifikasi komponen ER_D untuk sistem yang akan dikembangkan dalam penelitian ini, yaitu sebagai berikut: 1. Entitas (entity) Entitas yang terlibat dalam sistem adalah sebanyak 7 (tujuh) buah, yaitu sebagai berikut: a. User User merupakan entitas tentang obyek berupa orang yang akan mengakses sistem, baik sebagai User yang merancang dan menginputkan rancangan struktur tabel database maupun Pakar yang akan melakukan analisis terhadap data rancangan struktur tabel database. b. Pendidikan Pendidikan merupakan entitas tentang obyek berupa hal jenjang pendidikan yang akan digunakan pada obyek Perancang rancangan struktur tabel database.

284

c. Tingkat fleksibilitas Tingkat fleksibilitas merupakan entitas tentang obyek berupa hal tingkat fleksibilitas yang akan digunakan untuk menentukan kriteria tingkatan fleksibilitas data rancangan struktur tabel database. d. Data Data merupakan entitas tentang obyek berupa data rancangan struktur tabel database secara umum yang akan dianalisis. e. Data Tabel Data Tabel merupakan entitas tentang obyek berupa data tabel dalam rancangan struktur tabel database yang akan dianalisis. f. Data Atribut Data Atribut merupakan entitas tentang obyek berupa data atribut dalam rancangan struktur tabel database yang akan dianalisis. g. Hasil Hasil merupakan entitas tentang obyek berupa data hasil analisis rancangan struktur tabel database secara umum. h. Hasil detail Hasil detail merupakan entitas tentang obyek berupa data detail hasil analisis rancangan struktur tabel database. 2. Atribut (attribute) Atribut untuk setiap entitas yang terlibat dalam sistem adalah sebagai berikut:

285

a. Entitas User, melibatkan 3 (tiga) buah atribut yaitu: 1). Nama_User 2). Password 3). Status b. Entitas Pendidikan, melibatkan 2 (dua) buah atribut yaitu: 1). Pendidikan 2). Nama_Pendidikan c. Entitas Fleksibilitas, melibatkan 4 (empat) buah atribut yaitu: 1). Tingkat_Fleksibilitas 2). Nama_Tkt_Fleksibilitas 3). Batas_Bawah 4). Batas_Atas d. Entitas Data, melibatkan 8 (delapan) buah atribut yaitu: 1). Data_Rancangan_Ke 2). Data_Rancangan 3). Nama_Perancang 4). Pendidikan 5). Tanggal_Rancangan 6). Judul 7). Jumlah_Tabel 8). Jumlah_Atribut e. Entitas DataTabel, melibatkan 4 (empat) buah atribut yaitu: 1). Data_Rancangan_Ke

286

2). Nama_Tabel_Ke 3). Nama_Tabel 4). Jumlah_Atribut f. Entitas DataAtribut, melibatkan 6 (enam) buah atribut yaitu: 1). Data_Rancangan_Ke 2). Nama_Tabel_Ke 3). Nama_Atribut_Ke 4). Nama_Atribut 5). Tipe_Atribut 6). Ukuran_Atribut 7). Keterangan_Atribut g. Entitas Hasil, melibatkan 3 (tiga) buah atribut yaitu: 1). Data_Rancangan_Ke 2). Tanggal_Analisis 3). Tingkat_Fleksibilitas h. Entitas HasilDetail, melibatkan 5 (lima) buah atribut yaitu: 1). Data_Rancangan_Ke 2). Nama_Tabel_Ke 3). Nama_Atribut_Ke 4). Sifat_Fleksibel_Atribut 5). Penjelasan

287

3. Kerelasian (relationship) antar entitas Kerelasian antar entitas dalam sistem adalah sebanyak 6 (enam) buah, yaitu sebagai berikut: a. Merancang Merancang merupakan nama kerelasian antara entitas Data dan entitas Pendidikan. Kerelasian antara kedua entitas ini ditunjukkan menggunakan kunci asing (Foreign Key/FK) berupa kunci sederhana, yaitu Pendidikan yang diletakkan dalam entitas Data. Kerelasian ini memiliki jenis many-to-one, yaitu lebih dari satu nilai data Pendidikan pada entitas Data hanya dapat mempunyai kerelasian ke satu nilai data Pendidikan pada entitas Pendidikan. b. Mempunyai Mempunyai merupakan nama kerelasian antara entitas DataTabel dan entitas Data. Kerelasian antara kedua entitas ini ditunjukkan menggunakan kunci asing (Foreign Key/FK) berupa kunci sederhana, yaitu Data_Rancangan_Ke yang diletakkan dalam entitas DataTabel. Kerelasian ini memiliki jenis many-to-one, yaitu lebih dari satu nilai data Data_Rancangan_Ke pada entitas DataTabel hanya dapat mempunyai kerelasian ke satu nilai data Data_Rancangan_Ke pada entitas Data. c. Mempunyai Mempunyai merupakan nama kerelasian antara entitas DataAtribut dan entitas Data. Kerelasian antara kedua entitas ini ditunjukkan

288

menggunakan kunci asing (Foreign Key/FK) berupa kunci sederhana, yaitu Data_Rancangan_Ke yang diletakkan dalam entitas DataAtribut. Kerelasian ini memiliki jenis many-to-one, yaitu lebih dari satu nilai data Data_Rancangan_Ke pada entitas DataAtribut hanya dapat mempunyai kerelasian ke satu nilai data Data_Rancangan_Ke pada entitas Data. d. Mempunyai Mempunyai merupakan nama kerelasian antara entitas DataAtribut dan entitas DataTabel. Kerelasian antara kedua entitas ini ditunjukkan menggunakan kunci asing (Foreign Key/FK) berupa kunci sederhana, yaitu Nama_Tabel_Ke yang diletakkan dalam entitas DataAtribut. Kerelasian ini memiliki jenis many-to-one, yaitu lebih dari satu nilai data Nama_Tabel_Ke pada entitas DataAtribut hanya dapat mempunyai kerelasian ke satu nilai data Nama_Tabel_Ke pada entitas DataTabel. e. Mempunyai Mempunyai merupakan kerelasian antara entitas Hasil dan entitas Data. Kerelasian antara kedua entitas ini ditunjukkan menggunakan kunci asing (Foreign Key/FK) berupa kunci sederhana, yaitu Data_Rancangan_Ke

yang

diletakkan

dalam

entitas

Hasil.

Kerelasian ini memiliki jenis one-to-one, yaitu satu nilai data Data_Rancangan_Ke pada entitas Hasil hanya dapat mempunyai

289

kerelasian ke satu nilai data Data_Rancangan_Ke pada entitas Data. f. Mempunyai Mempunyai merupakan kerelasian antara entitas Hasil dan entitas Fleksibilitas. Kerelasian antara kedua entitas ini ditunjukkan menggunakan kunci asing (Foreign Key/FK) berupa kunci sederhana, yaitu Tingkat_Fleksibilitas yang diletakkan dalam entitas Hasil. Kerelasian ini memiliki jenis many-to-one, yaitu lebih dari satu nilai data Tingkat_Fleksibilitas pada entitas Hasil hanya

dapat

mempunyai

kerelasian

ke

satu

nilai

data

Tingkat_Fleksibilitas pada entitas Fleksibilitas. g. Mempunyai Mempunyai merupakan kerelasian antara entitas Hasil dan entitas HasilDetail. Kerelasian antara kedua entitas ini ditunjukkan menggunakan kunci asing (Foreign Key/FK) berupa kunci sederhana, yaitu Data_Rancangan_Ke yang diletakkan dalam entitas HasilDetail. Kerelasian ini memiliki jenis many-to-one, yaitu lebih dari satu nilai data Data_Rancangan_Ke pada entitas HasilDetail hanya dapat mempunyai kerelasian ke satu nilai data Data_Rancangan_Ke pada entitas HasilDetail. h. Mempunyai Mempunyai merupakan kerelasian antara entitas HasilDetail dan entitas DataTabel. Kerelasian antara kedua entitas ini ditunjukkan

290

menggunakan kunci asing (Foreign Key/FK) berupa kunci sederhana, yaitu Nama_Tabel_Ke yang diletakkan dalam entitas HasilDetail. Kerelasian ini memiliki jenis many-to-one, yaitu lebih dari satu nilai data Nama_Tabel_Ke pada entitas HasilDetail hanya dapat mempunyai kerelasian ke satu nilai data Nama_Tabel_Ke pada entitas DataTabel. i. Mempunyai Mempunyai merupakan kerelasian antara entitas HasilDetail dan entitas DataAtribut. Kerelasian antara kedua entitas ini ditunjukkan menggunakan kunci asing (Foreign Key/FK) berupa kunci sederhana, yaitu Nama_Atribut_Ke yang diletakkan dalam entitas HasilDetail. Kerelasian ini memiliki jenis many-to-one, yaitu lebih dari satu nilai data Nama_Atribut_Ke pada entitas HasilDetail hanya

dapat

mempunyai

kerelasian

ke

satu

nilai

data

Nama_Atribut_Ke pada entitas DataAtribut. Berdasarkan hasil identifikasi komponen penyusun ER_D tersebut, selanjutnya dapat digambarkan model data dalam bentuk ER_D. Mengingat keterbatasan media yang tersedia, maka ER_D hanya memuat hubungan antar entitas saja, tanpa dilengkapi komponen atribut pada setiap entitas. model data dalam bentuk ER_D (tanpa komponen atribut pada setiap entitas) untuk sistem yang akan dikembangkan ditampilkan dalam Gambar 5.7.

291

Pendidikan

Fleksibilitas

1

1

merancang

mempunyai

N Data 1

N 1

1

mempunyai

Hasil

1

1

mempunyai

mempunyai

N DataTabel

mempunyai

N 1

mempunyai

N

1

HasilDetail 1

mempunyai 1

N DataAtribut

mempunyai

1

Gambar 5.7: Model logikal data untuk sistem dalam bentuk ER_D

5.1.3. Perancangan Database 5.1.3.1. Transformasi ER_D ke Bentuk Logical Record Structure (LRS) Struktur

record

secara

logikal

(Logical

Record

Structure/LRS)

menunjukkan kerelasian antar record dalam database secara logikal. LRS merupakan hasil transformasi dari model data logikal yang digambarkan dalam bentuk ER_D. LRS dapat ditunjukkan pada bentuk sebuah diagram yang sering dikenal sebagai Diagram Kerelasian Antar Relasi. Untuk dapat menggambarkan Diagram Kerelasian Antar Relasi perlu diidentifikasikan beberapa komponen

292

diagram, yaitu relasi (relation) yang diperlukan dalam sistem, kunci primer (Primary Key/PK) pada setiap relasi, kunci asing (Foreign Key/FK) pada setiap relasi (jika ada), serta jenis kerelasian antar relasi. Berdasarkan model data logikal, selanjutnya dapat diidentifikasi komponen penyusun Diagram Kerelasian Antar Relasi, yaitu sebagai berikut: 1. Relasi (relation) Relasi yang diperlukan dalam sistem adalah sebanyak 8 (delapan) buah, yaitu: a. Relasi TblUser b. Relasi TblPendidikan c. Relasi TblFleksibilitas d. Relasi TblData e. Relasi TblDataTabel f. Relasi TblDataAtribut g. Relasi TblHasil h. Relasi TblHasilDetail 2. Kunci primer (Primary Key/PK) Kunci primer (Primary Key/PK) pada relasi dapat berupa kunci sederhana (simple key) atau kunci komposit (composite key). Kunci primer termasuk sebagai kunci sederhana jika tersusun atas sebuah atribut, sedangkan kunci primer termasuk kunci komposit jika tersusun atas gabungan atribut. Persyaratan pemilihan atribut atau gabungan atribut sebagai kunci primer relasi adalah bersifat unik, dan tidak diijinkan adanya nilai null. Kunci primer untuk setiap relasi yang diperlukan dalam sistem adalah sebagai berikut:

293

a. Relasi TblUser memiliki kunci primer berupa kunci komposit, yaitu gabungan dari 2 (dua) atribut yang terdiri atas Nama_User dan Password. b. Relasi TblPendidikan memiliki kunci primer berupa kunci sederhana, yaitu Pendidikan. c. Relasi TblFleksibilitas memiliki kunci primer berupa kunci sederhana, yaitu Tingkat_Fleksibilitas. d. Relasi TblData memiliki kunci primer berupa kunci sederhana, yaitu Data_Rancangan_Ke. e. Relasi TblDataTabel memiliki kunci primer berupa kunci komposit, yaitu gabungan dari 2 (dua) atribut yang terdiri atas Data_Rancangan_Ke dan Nama_Tabel_Ke. f. Relasi TblDataAtribut memiliki kunci primer berupa kunci komposit, yaitu gabungan dari 3 (tiga) atribut yang terdiri atas Data_Rancangan_Ke, Nama_Tabel_Ke, dan Nama_Atribut_Ke. g. Relasi TblHasil memiliki kunci primer berupa kunci sederhana, yaitu Data_Rancangan_Ke. h. Relasi TblHasilDetail memiliki kunci primer berupa kunci komposit, yaitu gabungan dari 3 (tiga) atribut yang terdiri atas Data_Rancangan_Ke, Nama_Tabel_Ke, dan Nama_Atribut_Ke. 3. Kunci asing (Foreign Key/FK) pada setiap relasi Kunci asing (Foreign Key/FK) adalah sembarang atribut atau gabungan atribut yang menjadi kunci primer dalam relasi lain yang memiliki kerelasian. Kunci asing pada relasi juga dapat berupa kunci sederhana (simple key) atau kunci

294

komposit (composite key). Kunci asing untuk setiap relasi yang diperlukan dalam sistem yang akan dikembangkan adalah sebagai berikut: a. Relasi TblData memiliki kunci asing sebanyak 1 (satu) buah, berupa kunci sederhana, yaitu Pendidikan yang digunakan untuk menghubungkan dengan relasi TblPendidikan. b. Relasi TblDataTabel memiliki kunci asing sebanyak 1 (satu) buah, berupa kunci sederhana, yaitu Data_Rancangan_Ke yang digunakan untuk menghubungkan dengan relasi TblData. c. Relasi TblDataAtribut memiliki kunci asing sebanyak 2 (dua) buah, yaitu: 1). Kunci asing berupa kunci sederhana, yaitu Data_Rancangan_Ke yang digunakan untuk menghubungkan dengan relasi TblData. 2). Kunci asing berupa kunci sederhana, yaitu Nama_Tabel_Ke yang digunakan untuk menghubungkan dengan relasi TblDataTabel. d. Relasi TblHasil memiliki kunci asing sebanyak 2 (dua) buah, yaitu: 1). Kunci asing berupa kunci sederhana, yaitu Data_Rancangan_Ke yang digunakan untuk menghubungkan dengan relasi TblData. 2). Kunci asing berupa kunci sederhana, yaitu Tingkat_Fleksibilitas yang

digunakan

untuk

menghubungkan

dengan

relasi

TblFleksibilitas. e. Relasi TblHasilDetail memiliki 3 (tiga) buah kunci asing, yaitu: 1). Kunci asing berupa kunci sederhana, yaitu Data_Rancangan_Ke yang digunakan untuk menghubungkan dengan relasi TblHasil.

295

2). Kunci asing berupa kunci sederhana, yaitu Nama_Tabel_Ke yang digunakan untuk menghubungkan dengan relasi TblDataTabel. 3). Kunci asing berupa kunci sederhana, yaitu Nama_Atribut_Ke yang digunakan untuk menghubungkan dengan relasi TblDataAtribut. 4. Jenis kerelasian (relationship) antar relasi a. Kerelasian antara relasi TblData dan TblPendidikan memiliki jenis manyto-one, yaitu lebih dari satu nilai data Pendidikan pada relasi TblData dapat mempunyai kerelasian ke satu nilai data Pendidikan pada relasi TblData. b. Kerelasian antara relasi TblDataTabel dan TblData memiliki jenis manyto-one, yaitu lebih dari satu nilai data Data_Rancangan_Ke pada relasi TblDataTabel

dapat

mempunyai

kerelasian

ke

satu

nilai

data

Data_Rancangan_Ke pada relasi TblData. c. Kerelasian antara relasi TblDataAtribut dan TblData memiliki jenis manyto-one, yaitu lebih dari satu nilai data Data_Rancangan_Ke pada relasi TblDataAtribut dapat

mempunyai kerelasian ke satu nilai data

Data_Rancangan_Ke pada relasi TblData. d. Kerelasian antara relasi TblDataAtribut dan TblDataTabel memiliki jenis many-to-one, yaitu lebih dari satu nilai data Data_Rancangan_Ke pada relasi TblDataAtribut dapat mempunyai kerelasian ke satu nilai data Data_Rancangan_Ke pada relasi TblDataTabel. e. Kerelasian antara relasi TblHasil dan TblData memiliki jenis one-to-one, yaitu satu nilai data Data_Rancangan_Ke pada relasi TblHasil hanya dapat

296

mempunyai kerelasian ke satu nilai data Data_Rancangan_Ke pada relasi TblData. f. Kerelasian antara relasi TblHasil dan TblFleksibilitas memiliki jenis many-to-one, yaitu satu nilai data Tingkat_Fleksibilitas pada relasi TblHasil dapat mempunyai kerelasian ke lebih dari satu nilai data Tingkat_Fleksibilitas pada relasi TblFleksibilitas. g. Kerelasian antara relasi TblHasilDetail dan TblHasil memiliki jenis manyto-one, yaitu lebih dari satu nilai data Data_Rancangan_Ke pada relasi TblHasilDetail hanya dapat mempunyai kerelasian ke satu nilai data Data_Rancangan_Ke pada relasi TblHasil. h. Kerelasian antara relasi TblHasilDetail dan TblDataAtribut memiliki jenis one-to-one, yaitu satu nilai data Nama_Atribut_Ke pada relasi TblHasilDetail hanya dapat mempunyai kerelasian satu nilai data Nama_Atribut_Ke pada relasi TblDataAtribut. Berdasarkan hasil identifikasi komponen Diagram Kerelasian Antar Relasi tersebut, selanjutnya dapat digambarkan hasil transformasi ER_D ke LRS dalam bentuk Diagram Kerelasian Antar Relasi untuk sistem yang akan dikembangkan, yaitu sebagaimana ditampilkan pada Gambar 5.8.

297

TblDataAtribut Data_Rancangan_Ke Nama_Tabel_Ke Nama_Atribut_Ke Nama_Atribut Tipe_Atribut Ukuran_Atribut Keterangan_Atribut TblDataTabel Data_Rancangan_Ke Nama_Tabel_Ke Nama_Tabel Jumlah_Atribut TblData Data_Rancangan_Ke Data_Rancangan Nama_Perancang Pendidikan Tanggal_Rancangan Judul Jumlah_Tabel Jumlah_Atribut TblPendidikan Pendidikan Nama_Pendidikan

TblHasilDetail Data_Rancangan_Ke Nama_Tabel_Ke Nama_Atribut_Ke Sifat_Fleksibel_Atribut Penjelasan TblHasil Data_Rancangan_Ke Tanggal_Analisis Tingkat_Fleksibilitas TblFleksibilitas Tingkat_Fleksibilitas Nama_Tkt_Fleksibilitas Batas_Bawah Batas_Atas TblUser Nama_User Password Status

Gambar 5.8: Diagram Kerelasian Antar Relasi Hasil Transfromasi ER_D ke LRS

5.1.3.2. Pengujian Normalisasi Relasi Uji normalisasi diperlukan untuk menguji apakah relas-relasi yang dirancang sudah mencapai bentuk yang optimal atau masih perlu didekomposisi kembali. Pada umumnya rancangan relasi database telah mencapai bentuk yang optimal apabila memenuhi krtiteria bentuk normal ketiga (3NF). Berikut ini adalah pengujian normalisasi untuk setiap relasi yang diperlukan dalam sistem. 1. Relasi bentuk awal/bentuk tidak normal (Unormalized Form/UNF) a. Relasi TblUser: (Nama_User, Password, Status) b. Relasi TblPendidikan: (Pendidikan, Nama_Pendidikan)

298

c. Relasi TblFleksibilitas: (Tingkat_Fleksibilitas, Nama_Tkt_Fleksibilitas, Batas_Bawah, Batas_Atas) d. Relasi TblData: (Data_Rancangan_Ke, Data_Rancangan, Nama_Perancang, Pendidikan, Tanggal_Rancangan, Judul, Jumlah_Tabel, Jumlah_Atribut) e. Relasi TblDataTabel: (Data_Rancangan_Ke, Nama_Tabel_Ke, Nama_Tabel, Jumlah_Atribut) f. Relasi TblDataAtribut: (Data_Rancangan_Ke, Nama_Tabel_Ke, Nama_Atribut_Ke, Nama_Atribut, Tipe_Atribut, Ukuran_Atribut, Keterangan_Atribut) g. Relasi TblHasil: (Data_Rancangan_ke, Tanggal_Analisis, Tingkat_Fleksibilitas) h. Relasi TblHasilDetail: (Data_Rancangan_Ke, Nama_Tabel_Ke, Nama_Atribut_Ke, Sifat_Fleksibel_Atribut, Keterangan) 2. Pengujian Bentuk Normalisasi Relasi a. Pengujian relasi bentuk normal kesatu (First Norm Form/1NF) 1). Relasi TblUser Semua atribut dalam struktur relasi TblUser adalah bernilai atomic dan tidak ada elemen data yang berupa grup perulangan, dengan demikian struktur relasi TblUser telah memenuhi kriteria 1NF. 2). Relasi TblPendidikan Semua atribut dalam struktur relasi TblPendidikan adalah bernilai atomic dan tidak ada elemen data yang berupa grup perulangan,

299

dengan demikian struktur relasi TblPendidikan telah memenuhi kriteria 1NF. 3). Relasi TblFleksibilitas Semua atribut dalam struktur relasi TblFleksibilitas adalah bernilai atomic dan tidak ada elemen data yang berupa grup perulangan, dengan demikian struktur relasi TblFleksibilitas telah memenuhi kriteria 1NF. 4). Relasi TblData Semua atribut dalam struktur relasi TblData adalah bernilai atomic dan tidak ada elemen data yang berupa grup perulangan, dengan demikian struktur relasi TblData telah memenuhi kriteria 1NF. 5). Relasi TblDataTabel Semua atribut dalam struktur relasi TblDataTabel adalah bernilai atomic dan tidak ada elemen data yang berupa grup perulangan, dengan demikian struktur relasi TblDataTabel telah memenuhi kriteria 1NF. 6). Relasi TblDataAtribut Semua atribut dalam struktur relasi TblDataAtribut adalah bernilai atomic dan tidak ada elemen data yang berupa grup perulangan, dengan demikian struktur relasi TblDataAtribut telah memenuhi kriteria 1NF.

300

7). Relasi TblHasil Semua Atribut dalam struktur relasi TblHasil adalah bernilai atomic dan tidak ada elemen data yang berupa grup perulangan, dengan demikian struktur relasi TblHasil telah memenuhi kriteria 1NF. 8). Relasi TblHasilDetail Semua Atribut dalam struktur relasi TblHasilDetail adalah bernilai atomic dan tidak ada elemen data yang berupa grup perulangan, dengan demikian struktur relasi TblHasilDetail telah memenuhi kriteria 1NF. b. Pengujian relasi bentuk normal kedua (Second Norm Form/2NF) 1). Relasi TblUser Relasi TblUser memenuhi kriteria 1NF dan semua atribut selain kunci primer bergantung secara fungsional (Functionally DependencyFD) pada kunci primer (Nama_User+Password), dengan demikian struktur relasi TblUser telah memenuhi kriteria 2NF. 2). Relasi TblPendidikan Relasi TblPendidikan memenuhi kriteria 1NF dan semua atribut selain kunci

primer

bergantung

secara

fungsional

(Functionally

DependencyFD) pada kunci primer (Pendidikan), dengan demikian struktur relasi TblPendidikan telah memenuhi kriteria 2NF. 3). Relasi TblFleksibilitas Relasi TblFleksibilitas memenuhi kriteria 1NF dan semua atribut selain kunci primer bergantung secara fungsional (Functionally

301

DependencyFD) pada kunci primer (Tingkat_Fleksibilitas), dengan demikian struktur relasi TblFleksibilitas telah memenuhi kriteria 2NF. 4). Relasi TblData Relasi TblData memenuhi kriteria 1NF dan semua atribut selain kunci primer bergantung secara fungsional (Functionally DependencyFD) pada kunci primer (Data_Rancangan_Ke), dengan demikian struktur relasi TblData telah memenuhi kriteria 2NF. 5). Relasi TblDataTabel Relasi TblDataTabel memenuhi kriteria 1NF dan semua atribut selain kunci

primer

bergantung

DependencyFD)

secara

fungsional

pada

kunci

(Functionally primer

(Data_Rancangan_Ke+Nama_Tabel_Ke), dengan demikian struktur relasi TblDataTabel telah memenuhi kriteria 2NF. 6). Relasi TblDataAtribut Relasi TblDataAtibut memenuhi kriteria 1NF dan semua atribut selain kunci

primer

DependencyFD)

bergantung pada

secara

kunci

fungsional

primer

(Functionally

(Data_Rancangan_Ke

+Nama_Tabel_Ke+Nama_Atribut_Ke), dengan demikian struktur relasi TblDataTabel telah memenuhi kriteria 2NF. 7). Relasi TblHasil Relasi TblHasil memenuhi kriteria 1NF dan semua atribut selain kunci primer bergantung secara fungsional (Functionally Dependency/FD)

302

pada kunci primer (Data_Rancangan_Ke), dengan demikian struktur relasi TblHasil telah memenuhi kriteria 2NF. 8). Relasi TblHasilDetail Relasi TblHasilDetail memenuhi kriteria 1NF dan semua atribut selain kunci

primer

Dependency/FD)

bergantung pada

secara

kunci

fungsional

primer

(Functionally

(Data_Rancangan_Ke

+Nama_Tabel_Ke+Nama_Atribut_Ke), dengan demikian struktur relasi TblHasilDetail telah memenuhi kriteria 2NF. c. Pengujian relasi bentuk normal ketiga (Third Norm Form/3NF) 1). Relasi TblUser Relasi TblUser memenuhi kriteria 2NF dan semua atribut selain kunci primer tidak mengalami ketergantungan secara transitif (Transitive Dependency/TFD) pada kunci primer (Nama_User+Password), dengan demikian struktur relasi TblUser telah memenuhi kriteria 3NF. Functionall Dependency (FD) pada relasi TblUser adalah: FD = (TblUser.Nama_User, TblUser.Password) Æ (TblUser.Status) 2). Relasi TblPendidikan Relasi TblPendidikan memenuhi kriteria 2NF dan semua atribut selain kunci primer tidak mengalami ketergantungan secara transitif (Transitive Dependency/TFD) pada kunci primer (Pendidikan), dengan demikian struktur relasi TblPendidikan telah memenuhi kriteria 3NF. Functionall Dependency (FD) pada relasi TblPendidikan adalah: FD = (TblPendidikan.Pendidikan) Æ (TblPendidikan.Nama_Pendidikan)

303

3). Relasi TblFleksibilitas Relasi TblFleksibilitas memenuhi kriteria 2NF dan semua atribut selain kunci primer tidak mengalami ketergantungan secara transitif (Transitive

Dependency/TFD)

(Tingkat_Fleksibilitas),

dengan

pada demikian

kunci struktur

primer relasi

TblFleksibilitas telah memenuhi kriteria 3NF. Functionall Dependency (FD) pada relasi TblFleksibilitas adalah: FD = (TblFleksibilitas.Tingkat_Fleksibilitas) Æ (TblFleksibilitas.Nama_Tkt_Fleksibilitas, TblFleksibilitas.Batas_Bawah, TblFleksibilitas.Batas_Atas) 4). Relasi TblData Relasi TblData memenuhi kriteria 2NF dan semua atribut selain kunci primer tidak mengalami ketergantungan secara transitif (Transitive Dependency/TFD) pada kunci primer (Data_Rancangan_Ke), dengan demikian struktur relasi TblData telah memenuhi kriteria 3NF. Functionall Dependency (FD) pada relasi TblData adalah: FD = (TblData.Data_Rancangan_Ke) Æ (TblData.Data_Rancangan, TblData.Nama_Perancang, TblData.Pendidikan, TblData.Tanggal_Rancangan, TblData.Judul, TblData.Jumlah_Tabel, TblData.Jumlah_Atribut) 5). Relasi TblDataTabel Relasi TblDataTabel memenuhi kriteria 2NF dan semua atribut selain kunci primer tidak mengalami ketergantungan secara transitif

304

(Transitive

Dependency/TFD)

pada

kunci

primer

(Data_Rancangan_Ke+Nama_Tabel_Ke), dengan demikian struktur relasi TblDataTabel telah memenuhi kriteria 3NF. Functionall Dependency (FD) pada relasi TblDataTabel adalah: FD = (TblDataTabel.Data_Rancangan_Ke, TblDataTabel.Nama_Tabel_Ke Æ (TblDataTabel.Nama_Tabel, TblDataTabel.Jumlah_Atribut) 6). Relasi TblDataAtribut Relasi TblDataAtribut memenuhi kriteria 2NF dan semua atribut selain kunci primer tidak mengalami ketergantungan secara transitif (Transitive

Dependency/TFD)

pada

kunci

primer

(Data_Rancangan_Ke+Nama_Tabel_Ke+Nama_Atribut_Ke), dengan demikian struktur relasi TblDataAtribut telah memenuhi kriteria 3NF. Functionall Dependency (FD) pada relasi TblDataAtribut adalah: FD = (TblDataAtribut.Data_Rancangan_Ke, TblDataAtribut.Nama_Tabel_Ke, TblDataAtribut.Nama_Atribut_Ke Æ (TblDataAtribut.Nama_Atribut, TblDataAtribut.Tipe_Atribut, TblDataAtribut.Ukuran_Atribut, TblDataAtribut.Keterangan_Atribut) 7). Relasi TblHasil Relasi TblHasil memenuhi kriteria 2NF dan semua atribut selain kunci primer tidak mengalami ketergantungan secara transitif (Transitive Dependency/TFD) pada kunci primer (Data_Rancangan), dengan demikian struktur relasi TblHasil telah memenuhi kriteria 3NF. Functionall Dependency (FD) pada relasi TblHasil adalah:

305

FD = (TblHasil.Data_Rancangan_Ke) Æ (TblHasil.Tanggal_Analisis, TblHasil.Tingkat_Fleksibilitas) 7). Relasi TblHasilDetail Relasi TblHasilDetail memenuhi kriteria 2NF dan semua atribut selain kunci primer tidak mengalami ketergantungan secara transitif (Transitive

Dependency/TFD)

pada

(Data_Rancangan+Nama_Tabel+Nama_Atribut), struktur

relasi

TblHasilDetail

telah

kunci dengan

memenuhi

primer demikian

kriteria

3NF.

Functionall Dependency (FD) pada relasi TblHasilDetail adalah: FD = (TblHasilDetail.Data_Rancangan_Ke, TblHasilDetail.Nama_Tabel_Ke, TblHasilDetail.Nama_Atribut_Ke) Æ (TblHasilDetail.Sifat_Fleksibel_Atribut, TblHasilDetail.Penjelasan)

5.1.3.3. Perancangan Spesifikasi Struktur Relasi Aplikasi sistem Analisis Fleksibilitas Rancangan Struktur Tabel Database untuk SIAKAD yang dikembangkan dalam penelitian ini memerlukan 8 (tujuh) buah relasi database, yaitu: 1. Relasi TblUser 2. Relasi TblPendidikan 3. Relasi TblFleksibilitas 4. Relasi TblData 5. Relasi TblDataTabel 6. Relasi TblDataAtribut

306

7. Relasi TblHasil 8. Relasi TblHasilDetail Berdasarkan hasil pengujian normalisasi relasi, setiap relasi yang dirancang tersebut telah memenuhi kriteria relasi bentuk 3NF, sehingga telah mencapai bentuk yang optimal. Detail spesifikasi struktur relasi database tersebut secara berturut-turut adalah TblUser ditunjukkan pada Tabel 5.1, TblPendidikan ditunjukkan pada Tabel 5.2, TblFleksibilitas ditunjukkan pada Tabel 5.3, TblData ditunjukkan pada Tabel 5.4, TblDataTabel ditunjukkan pada Tabel 5.5, TblDataAtribut ditunjukkan pada Tabel 5.6, TblHasil ditunjukkan pada Tabel 5.7, serta TblHasilDetail ditunjukkan pada Tabel 5.8. Tabel 5.1: TblUser.DB Primary key Nama field Tipe Nama_User Alpha Password Alpha Status Alpha

No 1 2 3

: Nama_User+Password Ukuran Null ? Key 50 No PK 10 No PK 1 No -

Min

Max

-

-

Keterangan Nama User Passsword Status User P:Pakar, U:User

Tabel 5.2: TblPendidikan.DB No 1 2

Primary key Nama field Pendidikan Nama_Pendidikan

: Pendidikan Tipe Ukuran Alpha 2 Alpha 50

Null ? No No

Key PK -

Min -

Max -

Keterangan Kode jenjang pendidikan Nama jenjang pendidikan

Tabel 5.3: TblFleksibilitas.DB No 1 2 3 4

Primary key Nama field Tingkat_Fleksibilitas Nama_Tkt_Fleksibilitas Batas_Bawah Batas_Atas

: Tingkat_Fleksibilitas Tipe Ukuran Short Alpha 25 Number 2:2 Number 3:2

Null ? No No No No

Key PK -

Min 1 0,00 19,99

Max 5 79,99 100,00

Keterangan Kode tingkat fleksibilitas Nama tingkat fleksibilitas % batas bawah % batas atas

307

Tabel 5.4: TblData.DB No 1 2 3 4 5 6 7 8

Primary key Foreign key Nama field Data_Rancangan_Ke Data_Rancangan Nama_Perancang Pendidikan Tanggal_Rancangan Judul Jumlah_Tabel Jumlah_Atribut

: Data_Rancangan_Ke : Pendidikan Referensi TblPendidikan Tipe Ukuran Null ? Key Min Short No PK 1 Alpha 11 No Alpha 50 No Alpha 2 No FK Date No Alpha 200 No Short No 1 Short No 1

Max 100 100 100

Keterangan Nomor urut data rancangan Kode data rancangan Nama perancang Kode jenjang pendidikan perancang Tanggal waktu perancangan Judul rancangan Jumlah tabel rancangan Jumlah atribut dalam rancangan

Tabel 5.5: TblDataTabel.DB No 1 2 3 4

Primary key Foreign key Nama field Data_Rancangan_Ke Nama_ Tabel_Ke Nama_ Tabel Jumlah_Atribut

: Data_Rancangan_Ke+Nama_Tabel_Ke : Data_Rancangan_Ke Referensi TblData Tipe Ukuran Null ? Key Min Short No PK/FK 1 Short No PK 1 Alpha 50 No Short No 1

Max 100 100 100

Keterangan Nomor urut data rancangan Nomor urut tabel Nama tabel rancangan Jumlah atribut dalam tabel

Tabel 5.6: TblDataAtribut.DB Primary key Foreign key No 1 2 3 4 5 6 7

Nama field Data_Rancangan_Ke Nama_ Tabel_Ke Nama_Atribut_Ke Nama_Atribut Tipe_Atribut Ukuran_Atribut Keterangan_Atribut

: Data_Rancangan_Ke+Nama_Tabel_Ke+Nama_Atribut_Ke : Data_Rancangan_Ke Referensi TblData Nama_Tabel_Ke Referensi TblDataTabel Tipe Ukuran Null ? Key Min Max Keterangan Nomor urut data rancangan Short No PK/FK 1 100 Nomor urut tabel Short No PK/FK 1 100 Nomor urut atribut Short No PK 1 100 Nama atribut rancangan Alpha 50 No Tipe data atribut rancangan Alpha 10 No Ukuran atribut rancangan Short No 1 100 Keterangan atribut Alpha 255 Yes -

Tabel 5.7: TblHasil.DB Primary key Foreign key No 1 2 3

Nama field Data_Rancangan_Ke Tanggal_Analisis Tingkat_Fleksibilitas

: Data_Rancangan_Ke : Data_Rancangan_Ke Referensi TblData Tingkat_Fleksibilitas Referensi TblFleksibilitas Tipe Ukuran Null ? Key Min Max Short No PK/FK 1 100 Date No Short No FK 1 5

Keterangan Nomor urut data rancangan Tanggal dilakukan analisis Tingkat fleksibilitas rancangan

308

Tabel 5.8: TblHasilDetail.DB Primary key Foreign key No 1 2 3 4 5

: Data_Rancangan+Nama_Tabel+Nama_Atribut : Data_Rancangan_Ke Referensi TblData Nama_Tabel_Ke Referensi TblDataTabel Nama_Atribut_Ke Referensi TblDataAtribut Tipe Ukuran Null ? Key Min Short No PK/FK 1 Short No PK/FK 1 Short No PK/FK 1 Logical No Alpha 255 Yes

Nama field Data_Rancangan_Ke Nama_ Tabel_Ke Nama_Atribut_Ke Sifat_Fleksibel_Atribut Penjelasan

Max 100 100 100 -

Keterangan Nomor urut data rancangan Nomor urut tabel Nomor urut atribut Sifat fleksibel atribut Penjelasan tidak fleksibel

5.1.4. Perancangan HIPO (Hierarchy and Input-Process-Output) Berdasarkan model logikal sistem dalam bentuk DFD dan model logikal data dalam bentuk ER_D pada bagian sebelumnya, dapat digunakan sebagai dasar perancangan HIPO (VTOC, Overview Diagram, dan Detailed Diagram).

5.1.4.1. Perancangan

Diagram

Isi

Visual

Tabel

(Visual

Table

of

Contents/VTOC) Diagram

isi

visual

tabel

(Visual

Table

of

Contents/VTOC)

menggambarkan hubungan dari modul-modul dalam suatu sistem secara berjenjang. VTOC untuk sistem yang akan dikembangkan dalam penelitian ini ditunjukkan pada Gambar 5.9.

309

Analisis fleksibilitas rancangan struktur tabel database

1 Setup data

1.1 Setup data User

1.2 Setup data Pendidikan

2 Input rancangan struktur tabel database

1.3 Setup data Tingkat Fleksibilitas

2.1 Input rancangan struktur tabel database

3 Proses analisis rancangan struktur tabel database

3.1 Proses analisis rancangan struktur tabel database

4 Laporan hasil analisis

4.1 Tampilkan hasil analisis rancangan struktur tabel database

Gambar 5.9: Visual Table of Contents HIPO sistem yang akan dikembangkan

5.1.4.2. Perancangan Diagram Ringkas (Overview Diagram) Diagram ringkas (overview diagram) menggambarkan hubungan dari input, proses, dan output. Input merupakan item-item data yang akan digunakan oleh bagian proses. Proses adalah langkah-langkah yang menggambarkan fungsi atau modul. Sedangkan output merupakan hasil pemrosesan data. Diagram ringkas untuk sistem yang akan dikembangkan dalam penelitian ini ditunjukkan pada Gambar 5.10.

310

Input

Output

Proses

1. User 2. Pendidikan 3. Tingkat fleksibilitas

1. Setup data

1. TblUser 2. TblPendidikan 3. TblFleksibilitas

1. Rancangan struktur tabel database 2. Detail rancangan struktur tabel database

2. Input rancangan struktur tabel database

1. TblData 2. TblDataTabel 3. TabelDataAtribut

1. TblUser 2. TblPendidikan 3. TblFleksibilitas 4. TblData 5. TblDataTabel 6. TblDataAtribut 7. Penilaian

3. Proses analisis rancangan struktur tabel database

1. TblHasil 2. TblHasilDetail

1. TblPendidikan 2. TblFleksibilitas 3. TblData 4. TblDataTabel 5. TblDataAtribut 6. TblHasil 7. TblHasilDetail

4. Laporan hasil analisis

1.1. Setup data User 1.2. Setup data pendidikan 1.3. Setup data tingkat fleksibilitas

2.1. Baca rancangan struktur tabel database 2.2. Simpan rancangan struktur tabel database

3.1. Tampilkan rancangan struktur tabel database 3.2. Proses analisis rancangan struktur tabel database 3.3. Simpan hasil analisis rancangan struktur tabel database

4.1. Baca kriteria informasi 4.2. Baca hasil analisis rancangan struktur tabel databse 4.3. Tampilkan hasil analisis fleksibilitas rancangan struktur tabel databse

1. Informasi hasil analisis

Gambar 5.10: Diagram ringkas (overview diagram) HIPO untuk sistem

5.1.4.3. Perancangan Diagram Detail (Detailed Diagram) Diagram terinci (detailed diagram) menggambarkan elemen-elemen dasar dari HIPO secara terinci. Diagram terinci untuk sistem yang akan dikembangkan dalam penelitian ini ditunjukkan pada Tabel 5.9.

311

Tabel 5.9: Diagram terinci (detailed diagram) HIPO untuk sistem Input 1. Data User

o Nama_User o Password o Status

2. Data Pendidikan

o Pendidikan o Nama_Pendidikan

3. Data Tingkat Fleksibilitas Tingkat_Fleksibilitas Nama_Tkt_Fleksibilitas Batas_Bawah Batas_Atas

o o o o

1. Data rancangan struktur tabel database o o o o o o o o

Data_Rancangan_Ke Data_Rancangan Nama_Perancang Pendidikan Tanggal_Rancangan Judul Jumlah_Tabel Jumlah_Atribut

2. Data tabel o o o o

Data_Rancangan_Ke Nama_Tabel_Ke Nama_ Tabel Jumlah_Atribut

Proses 1. Setup data 1.1. Setup data User o Baca data o Simpan data

1.2. Setup data pendidikan o Baca data o Simpan data

1.3. Setup data tingkat fleksibilitas o Baca data o Simpan data

2. Input rancangan struktur tabel database 2.1. Baca data rancangan o Baca data rancangan o Simpan data rancangan

2.2. Baca data tabel

o Baca data tabel o Simpan data tabel

Output 1. Tampilan menu utama

1.1. Tampilan submenu Setup data User o Form input Setup data User o Kembali ke submenu setup data 1.2. Tampilan submenu Setup data pendidikan o Form input Setup data pendidikan o Kembali ke submenu setup data 1.3. Submenu setup data tingkat fleksibilitas o Form input setup data tingkat fleksibilitas o Kembali ke submenu setup data

2. Kembali ke tampilan menu utama 2. Tampilan menu utama

2.1. Tampilan submenu input rancangan struktur tabel database o Form input rancangan struktur tabel database o Form input detail data 2.2. Kembali ke tampilan submenu input rancangan struktur tabel database

2.3. Baca data atribut

2.3. Kembali ke tampilan menu utama

3. Proses analisis rancangan struktur tabel database

3. Tampilan menu utama 3.1. Tampilan submenu proses analisis rancangan struktur tabel database o Form penilaian rancangan struktur tabel database 3.2. Kembali ke tampilan submenu proses analisis rancangan struktur tabel database 3.3. Kembali ke tampilan menu utama

o Baca data atribut o Simpan data atribut

3. Data atribut o o o o o o o

Data_Rancangan_Ke Nama_Tabel_Ke Nama_Atribut_Ke Nama_Atribut Tipe_Atribut Ukuran_Atribut Keterangan_Atribut

1. Data User

o Nama_User o Password o Status

2. Data Pendidikan

o Pendidikan o Nama_Pendidikan

3. Data Tingkat Fleksibilitas o o o o

Tingkat_Fleksibilitas Nama_Tkt_Fleksibilitas Batas_Bawah Batas_Atas

4. Data rancangan struktur tabel database o o o o o o o o

Data_Rancangan_Ke Data_Rancangan Nama_Perancang Pendidikan Tanggal_Rancangan Judul Jumlah_Tabel Jumlah_Atribut

3.1. Tampilkan rancangan struktur tabel database o Baca TblData o Baca TblDataTabel o Baca TblAtribut o Tampilkan TblData o Tampilkan TblDataTabel o Tampilkan TblDataAtribut 3.2. Proses analisis rancangan struktur tabel database 2.2.1. Baca penilaian 2.2.2. Konfirmasi penilaian 3.3. Simpan hasil analisis rancangan struktur tabel database 2.3.1. Simpan hasil 2.3.2. Simpan hasil detail

312

5. Data tabel o Data_Rancangan_Ke o Nama_Tabel_Ke o Nama_ Tabel o Jumlah_Atribut 6. Data atribut o Data_Rancangan_Ke o Nama_Tabel_Ke o Nama_Atribut_Ke o Nama_Atribut o Tipe_Atribut o Ukuran_Atribut o Keterangan_Atribut 7. Penilaian o Data_Rancangan_Ke o Nama_Tabel_Ke o Nama_Atribut_Ke o Tanggal_Analisis o Sifat_Fleksibel_Atribut o Penjelasan 1. Kriteria informasi 2. Hasil analisis o Data_Rancangan_Ke o Tanggal_Analisis o Tingkat_Fleksibilitas 3. Detail hasil analisis o Data_Rancangan_Ke o Nama_Tabel_Ke o Nama_Atribut_Ke o Sifat_Fleksibel_Atribut o Penjelasan

4. Laporan 4.1. Baca kriteria informasi 4.2. Baca hasil analisis rancangan struktur tabel database 4.3. Baca detail hasil analisis 4.4. Tampilkan hasil analisis rancangan struktur tabel database

4. Tampilan menu utama 4.1. Tampilan submenu Laporan o Form pilihan kriteria informasi o Form hasil analisis o Konfirmasi preview-cetak-tutup tampilan informasi 4.2. Kembali ke submenu Laporan 4.3. Kembali ke tampilan menu utama

5.1.5. Perancangan Dialog Layar Menu Dialog layar berfungsi untuk antarmuka proses komunikasi antara pemakai dan sistem. Dialog layar untuk sistem yang akan dikembangkan dalam penelitian ini dapat dikelompokkan menjadi 3 (tiga), yaitu Login User, Menu User, dan Menu Pakar.

5.1.5.1. Perancangan Dialog Layar Menu Login User Dialog layar Menu Login User berfungsi untuk melakukan verifikasi User sistem yang dapat berperan sebagai User atau Pakar. Rancangan tampilan login ke sistem ditunjukkan pada Gambar 5.11.

313

Analisis Fleksibilitas Rancangan Struktur Tabel Database Nama User Password

Login

Keluar

Gambar 5.11: Rancangan tampilan login ke sistem

5.1.5.2. Perancangan Dialog Layar Menu User Jika pemakai melakukan login sebagai User, maka hanya diijinkan untuk melakukan proses, sebagai berikut: 1.

Input rancangan struktur tabel database

2.

Menampilkan output, meliputi: a. Daftar rancangan struktur tabel database b. Hasil analisis-Per Rancangan c. Hasil analisis-Daftar d. Hasil analisis -Statistik Dialog layar menu User yang akan dikembangkan dalam penelitian ini

dirancang sebanyak 4 (empat) buah, yaitu sebagai berikut: 1. Tampilan menu utama untuk pemakai dengan login sebagai User Rancangan tampilan menu utama untuk pemakai dengan login sebagai User ditunjukkan pada Gambar 5.12.

314

Rancangan Struktur Tabel Database

Laporan

Informasi

Keluar

Gambar 5.12: Rancangan tampilan menu utama dengan login sebagai User 2. Tampilan sub menu Rancangan Struktur Tabel Database untuk pemakai dengan login sebagai User. Rancangan tampilan sub menu Rancangan Struktur Tabel Database untuk pemakai dengan login sebagai User ditunjukkan pada Gambar 5.13.

Rancangan Struktur Tabel Database

Laporan

Informasi

Input

Keluar

Gambar 5.13: Rancangan tampilan sub menu Rancangan Struktur Tabel Database untuk pemakai dengan login sebagai User 3. Tampilan sub menu Laporan untuk pemakai dengan login sebagai User. Rancangan tampilan sub menu Laporan untuk pemakai dengan login sebagai User ditunjukkan pada Gambar 5.14.

315

Rancangan Struktur Tabel Database

Laporan

Informasi

Daftar Rancangan Hasil Æ Per Hasil Æ Daftar Hasil Æ Statistik Keluar

Gambar 5.14: Rancangan tampilan sub menu Laporan untuk pemakai dengan login sebagai User 4. Tampilan sub menu Informasi untuk pemakai dengan login sebagai User. Rancangan tampilan sub menu Informasi untuk pemakai dengan login sebagai User ditunjukkan pada Gambar 5.15. Rancangan Struktur Tabel Database

Laporan

Informasi Bantuan Pembuat Program

Keluar

Gambar 5.15: Rancangan tampilan sub menu Informasi untuk pemakai dengan login sebagai User 5.1.5.3. Perancangan Dialog Layar Menu Pakar Jika pemakai melakukan login sebagai Pakar, maka diijinkan untuk melakukan proses, sebagai berikut: 1.

Setup data, meliputi: a. Setup User b. Setup pendidikan

316

c. Setup data tingkat fleksibilitas 2.

Input rancangan struktur tabel database

3.

Proses analisis rancangan struktur tabel database

4.

Menampilkan output, meliputi: a. Daftar rancangan struktur tabel database b. Hasil analisis-Per Rancangan c. Hasil analisis-Daftar d. Hasil analisis-Statistik

Dialog layar menu Pakar yang akan dikembangkan dalam penelitian ini dirancang sebanyak 5 (lima) buah, yaitu sebagai berikut: 1. Tampilan menu utama untuk pemakai dengan login sebagai Pakar. Rancangan tampilan menu utama untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.16. Setup Data

Rancangan Struktur Tabel Database

Laporan

Informasi

Keluar

Gambar 5.16: Rancangan tampilan menu utama untuk pemakai dengan login sebagai Pakar 2. Tampilan sub menu Setup Data untuk pemakai dengan login sebagai Pakar. Rancangan tampilan sub menu Setup Data untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.17.

317

Setup Data

Rancangan Struktur Tabel Database

Laporan

Informasi

Tingkat Fleksibilitas Pendidikan User

Keluar

Gambar 5.17: Rancangan tampilan sub menu Setup Data untuk pemakai dengan login sebagai Pakar 3. Tampilan sub menu Rancangan Struktur Tabel Database untuk pemakai dengan login sebagai Pakar. Rancangan tampilan sub menu Rancangan Struktur Tabel Database untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.18.

Setup Data

Rancangan Struktur Tabel Database

Laporan

Informasi

Input Penilaian

Keluar

Gambar 5.18: Rancangan tampilan sub menu Rancangan Struktur Tabel Database untuk pemakai dengan login sebagai Pakar 4. Tampilan sub menu Laporan untuk pemakai dengan login sebagai Pakar. Rancangan tampilan sub menu Laporan untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.19.

318

Setup Data

Rancangan Struktur Tabel Database

Laporan

Informasi

Daftar Rancangan Hasil Æ Per Hasil Æ Daftar Hasil Æ Statistik Keluar

Gambar 5.19: Rancangan tampilan sub menu Laporan untuk pemakai dengan login sebagai Pakar 5. Tampilan sub menu Informasi untuk pemakai dengan login sebagai Pakar. Rancangan tampilan sub menu Informasi untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.20.

Setup Data

Rancangan Struktur Tabel Database

Laporan

Informasi Bantuan Pembuat Program

Keluar

Gambar 5.20: Rancangan tampilan sub menu Informasi untuk pemakai dengan login sebagai Pakar 5.1.6. Perancangan Input 5.1.6.1. Perancangan Input Pada Menu User Input pada menu User untuk sistem yang akan dikembangkan dalam penelitian ini hanya sebanyak 1 (satu) buah, yaitu Input data rancangan struktur

319

tabel database yang berfungsi untuk meng-input-kan data-data umum dan detail rancangan struktur tabel database, meliputi: 1. Data_Rancangan_Ke 2. Data_Rancangan 3. Nama_Perancang 4. Pendidikan 5. Tanggal_Rancangan 6. Judul 7. Jumlah Tabel 8. Jumlah_Atribut 9. Nama_Tabel_Ke 10. Nama_Tabel 11. Jumlah_Atribut 12. Nama_Atibut_Ke 13. Nama_Atribut 14. Tipe_Atribut 15. Ukuran_Atribut 16. Keterangan_Atribut Rancangan tampilan input data rancangan struktur tabel database pada menu User ditunjukkan pada Gambar 5.21.

320

Gambar 5.21: Rancangan tampilan input data rancangan struktur tabel database untuk pemakai dengan login sebagai User 5.1.6.2. Perancangan Input Pada Menu Pakar Input pada menu Pakar untuk sistem yang akan dikembangkan dalam penelitian ini adalah sebanyak 6 (enam) buah, yaitu: 1. Input setup data Tingkat Fleksibilitas Input setup data tingkat fleksibilitas berfungsi untuk meng-input-kan data-data tingkat fleksibilitas yang akan digunakan untuk menentukan kriteria tingkatan fleksibilitas pada analisis rancangan struktur tabel database yang meliputi: a. Tingkat_Fleksibilitas b. Nama_Tkt_Fleksibilitas c. Batas_Bawah d. Batas_Atas

321

Rancangan tampilan input setup data tingkat fleksibilitas untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.22.

Gambar 5.22: Rancangan tampilan input setup data tingkat fleksibilitas untuk pemakai dengan login sebagai Pakar 2. Input setup data Pendidikan Input setup data pendidikan berfungsi untuk meng-input-kan data-data jenjang pendidikan yang akan digunakan untuk input data Perancang struktur tabel database yang meliputi: a. Pendidikan b. Nama_Pendidikan Rancangan tampilan input setup data pendidikan untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.23.

322

Gambar 5.23: Rancangan tampilan input setup data pendidikan untuk pemakai dengan login sebagai Pakar 3. Input setup data User Input setup data User berfungsi untuk meng-input-kan data-data User yang meliputi: a. Nama_User b. Password c. Status Rancangan tampilan input Setup data User untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.24.

Gambar 5.24: Rancangan tampilan input setup data User untuk pemakai dengan login sebagai Pakar

323

4. Input data rancangan struktur tabel database. Input data rancangan struktur tabel database berfungsi untuk meng-input-kan data umum dan detail tentang rancangan struktur tabel database, meliputi: a. Data_Rancangan_Ke b. Data_Rancangan c. Nama_Perancang d. Pendidikan e. Tanggal_Rancangan f. Judul g. Jumlah Tabel h. Jumlah_Atribut i. Nama_Tabel_Ke j. Nama_Tabel k. Jumlah_Atribut l. Nama_Atibut_Ke m. Nama_Atribut n. Tipe_Atribut o. Ukuran_Atribut p. Keterangan_Atribut Rancangan tampilan input data rancangan struktur tabel database untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.25.

324

Gambar 5.25: Rancangan tampilan input data rancangan struktur tabel database untuk pemakai dengan login sebagai Pakar

5. Input penilaian rancangan struktur tabel database Input penilaian rancangan struktur tabel database berfungsi untuk meng-inputkan nilai-nilai yang diberikan oleh Pakar terhadap aspek fleksibilitas rancangan struktur tabel database yang dianalisis, meliputi: a. Data_Rancangan_Ke b. Nama_Tabel_Ke c. Nama_Atribut_Ke d. Tanggal_Analisis e. Sifat_Fleksibel_Atribut f. Penjelasan

325

Rancangan tampilan input penilaian untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.26.

Gambar 5.26: Rancangan tampilan input penilaian untuk pemakai dengan login sebagai Pakar 5.1.7. Perancangan Output Sistem yang akan dikembangkan dalam penelitian ini dirancang untuk dapat menghasilkan output berupa laporan-laporan yang ditujukan bagi para pemakai, baik sebagai User maupun Pakar, masing-masing diberikan pilihan untuk Preview dan Cetak ke media hardcopy berupa kertas melalui printer. Dalam penelitian ini, tampilan output untuk pemakai sebagai User maupun Pakar dirancang dalam bentuk dan format yang sama, meliputi:

326

1. Daftar Rancangan Struktur Tabel Database Output Daftar Rancangan Struktur Tabel Database dirancang dalam format Lanscape, terdiri atas 5 (lima) macam yang dapat dipilih, yaitu: a. Daftar Rancangan Struktur Tabel Database Pendidikan Perancang S3 b. Daftar Rancangan Struktur Tabel Database Pendidikan Perancang S2 c. Daftar Rancangan Struktur Tabel Database Pendidikan Perancang S1 d. Daftar Rancangan Struktur Tabel Database Pendidikan Perancang D3 e. Daftar Rancangan Struktur Tabel Database Keseluruhan Rancangan tampilan Daftar Rancangan Struktur Tabel Database Pendidikan Perancang S3 ditunjukkan pada Gambar 5.27. DAFTAR RANCANGAN STRUKTUR TABEL DATABASE PENDIDIKAN PERANCANG S3 No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

Halaman: Jumlah Atribut

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.27: Daftar Rancangan Struktur Tabel Database Pendidikan Perancang S3 Rancangan tampilan Daftar Rancangan Struktur Tabel Database Pendidikan Perancang S2 ditunjukkan pada Gambar 5.28.

327

DAFTAR RANCANGAN STRUKTUR TABEL DATABASE PENDIDIKAN PERANCANG S2 No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

Halaman: Jumlah Atribut

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.28: Daftar Rancangan Struktur Tabel Database Pendidikan Perancang S2 Rancangan tampilan Daftar Rancangan Struktur Tabel Database Pendidikan Perancang S1 ditunjukkan pada Gambar 5.29. DAFTAR RANCANGAN STRUKTUR TABEL DATABASE PENDIDIKAN PERANCANG S1 No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

Halaman: Jumlah Atribut

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.29: Daftar Rancangan Struktur Tabel Database Pendidikan Perancang S1 Rancangan tampilan Daftar Rancangan Struktur Tabel Database Pendidikan Perancang D3 ditunjukkan pada Gambar 5.30. DAFTAR RANCANGAN STRUKTUR TABEL DATABASE PENDIDIKAN PERANCANG D3 No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.30: Daftar Rancangan Struktur Tabel Database Pendidikan Perancang D3

Halaman: Jumlah Atribut

328

Rancangan tampilan Daftar Rancangan Struktur Tabel Database Pendidikan Perancang Keseluruhan ditunjukkan pada Gambar 5.31. DAFTAR RANCANGAN STRUKTUR TABEL DATABASE KESELURUHAN No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

Halaman: Jumlah Atribut

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.31: Daftar Rancangan Struktur Tabel Database Keseluruhan 2. Hasil Analisis Per Rancangan Output Hasil Analisis Per Rancangan, merupakan laporan detail hasil analisis fleksibilitas rancangan struktur tabel database yang dirancang dalam format Portrait. Output ini terdiri atas 1 (satu) macam. Rancangan tampilan Hasil Analisis Per Rancangan ditunjukkan pada Gambar 5.32. HASIL ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE PER RANCANGAN Data Rancangan Nama Perancang Pendidikan Perancang Tanggal Rancangan Jumlah Tabel Jumlah Atribut Judul Tabel ke : No Nama Atribut

: : : : : : :

Tanggal Analisis Jumlah Atribut Tidak Fleksibel Jumlah Atribut Fleksibel Tingkat Fleksibilitas

Nama Tabel : Tipe Atribut Ukuran Atribut

Fleksibel [Y/T]

DicetakÆ Tgl/Jam

Gambar 5.32: Hasil Analisis Per Rancangan

Halaman: : : …. =….% : …. =….% :

Penjelasan

329

3. Daftar Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Output Daftar Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database dirancang dalam format Lanscape, terdiri atas 3 (tiga) kelompok, yaitu: a. Daftar Hasil Analisis Berdasarkan Tingkat Fleksibilitas, meliputi: 1). Daftar Berdasarkan Tingkat Fleksibilitas SANGAT BAIK Rancangan tampilan Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas SANGAT BAIK ditunjukkan pada Gambar 5.33.

HASIL ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE DAFTAR BERDASARKAN TINGKAT FLEKSIBILITAS SANGAT BAIK No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

Atribut Tidak Fleksibel Jumlah %

Halaman: Pendidikan Atribut Fleksibel Perancang Jumlah %

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.33: Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas SANGAT BAIK 2). Daftar Berdasarkan Tingkat Fleksibilitas BAIK Rancangan tampilan Hasil Analisis Fleksibilitas Rancangan Tabel Database

Daftar

Berdasarkan

ditunjukkan pada Gambar 5.34.

Tingkat

Fleksibilitas

BAIK

330

HASIL ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE DAFTAR BERDASARKAN TINGKAT FLEKSIBILITAS BAIK No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

Atribut Tidak Fleksibel Jumlah %

Halaman: Pendidikan Atribut Fleksibel Perancang Jumlah %

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.34: Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas BAIK 3). Daftar Berdasarkan Tingkat Fleksibilitas SEDANG Rancangan tampilan Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas SEDANG ditunjukkan pada Gambar 5.35. HASIL ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE DAFTAR BERDASARKAN TINGKAT FLEKSIBILITAS SEDANG No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

Atribut Tidak Fleksibel Jumlah %

Halaman: Pendidikan Atribut Fleksibel Perancang Jumlah %

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.35: Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas SEDANG 4). Daftar Berdasarkan Tingkat Fleksibilitas BURUK Rancangan tampilan Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas BURUK ditunjukkan pada Gambar 5.36.

331

HASIL ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE DAFTAR BERDASARKAN TINGKAT FLEKSIBILITAS BURUK No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

Halaman: Pendidikan Atribut Fleksibel Perancang Jumlah %

Atribut Tidak Fleksibel Jumlah %

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.36: Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas BURUK 5). Daftar Berdasarkan Tingkat Fleksibilitas SANGAT BURUK Rancangan tampilan Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas SANGAT BURUK ditunjukkan pada Gambar 5.37. HASIL ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE DAFTAR BERDASARKAN TINGKAT FLEKSIBILITAS SANGAT BURUK No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

Halaman: Pendidikan Atribut Fleksibel Perancang Jumlah %

Atribut Tidak Fleksibel Jumlah %

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.37: Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Berdasarkan Tingkat Fleksibilitas SANGAT BURUK b. Daftar Hasil Analisis Berdasarkan Pendidikan Perancang 1). Daftar Hasil Analisis Berdasarkan Pendidikan Perancang S3 Rancangan tampilan Hasil Analisis Fleksibilitas Rancangan Tabel Database

Daftar

Berdasarkan

ditunjukkan pada Gambar 5.38.

Pendidikan

Perancang

S3

332

HASIL ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE DAFTAR BERDASARKAN PENDIDIKAN PERANCANG S3 No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

Atribut Tidak Fleksibel Jumlah %

Halaman: Tingkat Atribut Fleksibel FLeksibilitas Jumlah %

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.38: Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Berdasarkan Pendidikan Perancang S3 2). Daftar Hasil Analisis Berdasarkan Pendidikan Perancang S2 Rancangan tampilan Hasil Analisis Fleksibilitas Rancangan Tabel Database

Daftar

Berdasarkan

Pendidikan

Perancang

S2

ditunjukkan pada Gambar 5.39. HASIL ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE DAFTAR BERDASARKAN PENDIDIKAN PERANCANG S2 No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

Atribut Tidak Fleksibel Jumlah %

Halaman: Tingkat Atribut Fleksibel FLeksibilitas Jumlah %

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.39: Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Berdasarkan Pendidikan Perancang S2 3). Daftar Hasil Analisis Berdasarkan Pendidikan Perancang S1 Rancangan tampilan Hasil Analisis Fleksibilitas Rancangan Tabel Database

Daftar

Berdasarkan

ditunjukkan pada Gambar 5.40.

Pendidikan

Perancang

S1

333

HASIL ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE DAFTAR BERDASARKAN PENDIDIKAN PERANCANG S1 No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

Atribut Tidak Fleksibel Jumlah %

Halaman: Tingkat Atribut Fleksibel FLeksibilitas Jumlah %

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.40: Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Berdasarkan Pendidikan Perancang S1 4). Daftar Hasil Analisis Berdasarkan Pendidikan Perancang D3 Rancangan tampilan Hasil Analisis Fleksibilitas Rancangan Tabel Database

Daftar

Berdasarkan

Pendidikan

Perancang

D3

ditunjukkan pada Gambar 5.41. HASIL ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE DAFTAR BERDASARKAN PENDIDIKAN PERANCANG D3 No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

Atribut Tidak Fleksibel Jumlah %

Halaman: Tingkat Atribut Fleksibel FLeksibilitas Jumlah %

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.41: Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Berdasarkan Pendidikan Perancang D3 c. Daftar Hasil Analisis Keseluruhan Rancangan tampilan Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Hasil Analisis Keseluruhan ditunjukkan pada Gambar 5.42.

334

HASIL ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE KESELURUHAN No

Data Rancangan

Nama Perancang

Tanggal Rancangan

Judul

Jumlah Tabel

Atribut Tidak Fleksibel Jumlah %

Atribut Fleksibel Jumlah %

Halaman: Tingkat Pendidikan FLeksibilitas Perancang

JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.42: Hasil Analisis Fleksibilitas Rancangan Tabel Database Daftar Hasil Analisis Keseluruhan 4. Hasil Statistik Analisis Fleksibilitas Rancangan Struktur Tabel Database Output Statistik Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database dirancang dalam format Portrait. Output ini terdiri atas 3 (tiga) macam, yaitu: a. Statistik Hasil Analisis Berdasarkan Tingkat Fleksibilitas Rancangan tampilan Hasil Analisis Fleksibilitas Rancangan Tabel Database Statistik Berdasarkan Tingkat Fleksibilitas ditunjukkan pada Gambar 5.43. HASIL ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE STATISTIK BERDASARKAN TINGKAT FLEKSIBILITAS Halaman: No

Pendidikan Perancang

Data Rancangan

Tabel

Atribut

Jumlah Atribut Tidak Fleksibel Jumlah %

Atribut Fleksibel Jumlah %

1 Sangat Baik 2 Baik 3 Sedang 4 Buruk 5 Sangat Buruk JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.43: Hasil Analisis Fleksibilitas Rancangan Tabel Database Statistik Berdasarkan Tingkat Fleksibilitas

335

b. Statistik Hasil Analisis Berdasarkan Pendidikan Perancang Rancangan tampilan Hasil Analisis Fleksibilitas Rancangan Tabel Database Statistik Berdasarkan Pendidikan Perancang ditunjukkan pada Gambar 5.44. HASIL ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE STATISTIK BERDASARKAN PENDIDIKAN PERANCANG No

Pendidikan Perancang

Data Rancangan

Tabel

Atribut

Jumlah Atribut Tidak Fleksibel Jumlah %

Halaman:

Atribut Fleksibel Jumlah %

1 S3 2 S2 3 S1 4 D3 JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.44: Hasil Analisis Fleksibilitas Rancangan Tabel Database Statistik Berdasarkan Pendidikan Perancang c. Statistik Rekapitulasi Keseluruhan Rancangan tampilan Statistik Rekapitulasi Keseluruhan ditunjukkan pada Gambar 5.45. HASIL ANALISIS FLEKSIBILITAS RANCANGAN STRUKTUR TABEL DATABASE REKAPITULASI KESELURUHAN No

Pendidikan Perancang

Jumlah Data Rancangan

Sangat Baik Jumlah %

Tingkat Fleksibilitas Baik Sedang Buruk Jumlah % Jumlah % Jumlah %

Halaman:

Sangat Buruk Jumlah %

1 2 3 4

S3 S2 S1 D3 JUMLAH: DicetakÆ Tgl/Jam

Gambar 5.45: Hasil Analisis Fleksibilitas Rancangan Tabel Database Statistik Rekapitulasi Keseluruhan

336

5.1.8. Perancangan Teknologi Perancangan teknologi yang digunakan untuk mengembangkan sistem aplikasi dalam penelitian ini adalah sebagai berikut: 1. Hardware, spesifikasi hardware yang digunakan dalam penelitian ini adalah sebagai berikut: a. Processor Mobile Intel® Pentium 4 ® 2,30 GHz b. RAM 256 MB 2. Software, spesifikasi software yang digunakan dalam penelitian ini adalah sebagai berikut: a. Operating Systems Microsoft Windows XP Home Edition version 2002 Sevice Pack 1 b. Borland Delphi Enterprise version 6.0 c. Database Desktop version 7.0 3. Arsitektur aplikasi, aplikasi yang dikembangkan dalam penelitian ini bersifat stand alone, dengan alasan apliaksi lebih ditekankan untuk membantu proses penilaian dan penyajian informasi hasil penilaian fleksibilitas rancangan struktur tabel database.

337

5.2. Implementasi Sistem 5.2.1. Implementasi Program Aplikasi Program aplikasi untuk Analisis Fleksibilitas Rancangan Struktur tabel Database dalam peneitian ini diimplementasikan dengan menggunakan bahasa pemrograman Borland Delphi Enterprise version 6.0. Program utama aplikasi adalah berupa sebuah proyek yang diberi nama PTesis.dpr.

5.2.2. Implementasi Dialog Layar 5.2.1.1. Implementasi Dialog Layar Menu Login User Dialog layar Menu Login User berfungsi untuk melakukan verifikasi User sistem yang dapat berperan sebagai User atau Pakar yang diimplementasikan dalam sebuah unit yang diberi nama LoginUser.pas. Implementasi tampilan login ke sistem ditunjukkan pada Gambar 5.46.

Gambar 5.46: Implementasi tampilan login ke sistem

338

5.2.1.2. Implementasi Dialog Layar Menu User Dialog layar menu User terdiri atas 4 (empat) macam, yaitu: 1. Tampilan menu utama untuk pemakai dengan login sebagai User Dialog layar menu User diimplementasikan dalam unit yang diberi nama UtamaUser.pas. Implementasi tampilan menu utama untuk pemakai dengan login sebagai User ditunjukkan pada Gambar 5.47.

Gambar 5.47: Implementasi tampilan menu utama dengan login sebagai User 2. Tampilan sub menu Rancangan Struktur Tabel Database untuk pemakai dengan login sebagai User. Implementasi tampilan sub menu Rancangan Struktur Tabel Database untuk pemakai dengan login sebagai User ditunjukkan pada Gambar 5.48.

339

Gambar 5.48: Implementasi tampilan sub menu Rancangan Struktur Tabel Database untuk pemakai dengan login sebagai User 3. Tampilan sub menu Laporan untuk pemakai dengan login sebagai User. Implementasi tampilan sub menu Laporan untuk pemakai dengan login sebagai User ditunjukkan pada Gambar 5.49.

Gambar 5.49: Implementasi tampilan sub menu Laporan untuk pemakai dengan login sebagai User

340

4. Tampilan sub menu Informasi untuk pemakai dengan login sebagai User. Implementasi tampilan sub menu Informasi untuk pemakai dengan login sebagai User ditunjukkan pada Gambar 5.50.

Gambar 5.50: Implementasi tampilan sub menu Informasi untuk pemakai dengan login sebagai User 5.2.1.3. Implementasi Dialog Layar Menu Pakar Pemakai dengan login sebagai Pakar, disediakan pilihan menu sebagai berikut: 1.

Setup data, meliputi: a. Setup User b. Setup pendidikan c. Setup data tingkat fleksibilitas

2.

Input implementasi struktur tabel database.

3.

Proses analisis implementasi struktur tabel database

341

4.

Menampilkan output, meliputi: a. Daftar implementasi struktur tabel database. b. Hasil analisis-Per Implementasi. c. Hasil analisis-Daftar. d. Hasil analisis-Statistik.

Dialog layar menu Pakar diimplementasikan dalam unit yang diberi nama UtamaPakar.pas. Dialog layar menu Pakar terdiri atas: 1. Tampilan menu utama untuk pemakai dengan login sebagai Pakar. Implementasi tampilan menu utama untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.51.

Gambar 5.51: Implementasi tampilan menu utama untuk pemakai dengan login sebagai Pakar

342

2. Tampilan sub menu Setup Data untuk pemakai dengan login sebagai Pakar. Implementasi tampilan sub menu Setup Data untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.52.

Gambar 5.52: Implementasi tampilan sub menu Setup Data untuk pemakai dengan login sebagai Pakar 3. Tampilan sub menu Implementasi Struktur Tabel Database untuk pemakai dengan login sebagai Pakar. Implementasi tampilan sub menu Implementasi Struktur Tabel Database untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.53.

343

Gambar 5.53: Implementasi tampilan sub menu Implementasi Struktur Tabel Database untuk pemakai dengan login sebagai Pakar 4. Tampilan sub menu Laporan untuk pemakai dengan login sebagai Pakar. Implementasi tampilan sub menu Laporan untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.54.

344

Gambar 5.54: Implementasi tampilan sub menu Laporan untuk pemakai dengan login sebagai Pakar 5. Tampilan sub menu Informasi untuk pemakai dengan login sebagai Pakar. Implementasi tampilan sub menu Informasi untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.55.

345

Gambar 5.55: Implementasi tampilan sub menu Informasi untuk pemakai dengan login sebagai Pakar 5.2.3. Implementasi Input 5.2.3.1. Implementasi Input Pada Menu User Input data rancangan struktur tabel database berfungsi untuk meng-inputkan data-data umum dan detail rancangan struktur tabel database yang diimplementasikan dalam unit yang diberi nama InputData.pas. Implementasi tampilan input data implementasi struktur tabel database pada menu User ditunjukkan pada Gambar 5.56.

346

Gambar 5.56: Implementasi tampilan input data rancangan struktur tabel database untuk pemakai dengan login sebagai User 5.2.3.2. Implementasi Input Pada Menu Pakar Input pada menu Pakar adalah sebanyak 6 (enam) buah, yaitu: 1. Input setup data Tingkat Fleksibilitas Input setup data Tingkat Fleksibilitas berfungsi untuk meng-input-kan datadata Tingkat Fleksibilitas yang akan digunakan untuk menentukan kriteria tingkatan fleksibilitas pada analisis rancangan struktur tabel database yang diimplementasikan

dalam

unit

yang

diberi

nama

Fleksibilitas.pas.

Implementasi tampilan input setup data tingkat fleksibilitas untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.57.

347

Gambar 5.57: Implementasi tampilan input setup data tingkat fleksibilitas untuk pemakai dengan login sebagai Pakar 2. Input setup data Pendidikan Input setup data pendidikan berfungsi untuk meng-input-kan data-data jenjang pendidikan yang akan digunakan untuk input data Perancang struktur tabel database

yang

diimplementasikan

dalam

unit

yang

diberi

nama

Pendidikan.pas. Implementasi tampilan input setup data pendidikan untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.58.

348

Gambar 5.58: Implementasi tampilan input setup data pendidikan untuk pemakai dengan login sebagai Pakar 3. Input setup data User Input setup data User berfungsi untuk meng-input-kan data-data User yang diimplementasikan dalam unit yang diberi nama User.pas. Implementasi tampilan input Setup data User untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.59.

349

Gambar 5.59: Implementasi tampilan input setup data User untuk pemakai dengan login sebagai Pakar 4. Input data rancangan struktur tabel database. Input data implementasi struktur tabel database berfungsi untuk meng-inputkan data umum dan detail tentang implementasi struktur tabel database yang diimplementasikan

dalam

unit

yang

diberi

nama

InputData.pas.

Implementasi tampilan input data implementasi struktur tabel database untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.60.

350

Gambar 5.60: Implementasi tampilan input data implementasi struktur tabel database untuk pemakai dengan login sebagai Pakar 5. Input penilaian implementasi struktur tabel database Input penilaian implementasi struktur tabel database berfungsi untuk menginput-kan nilai-nilai yang diberikan oleh Pakar terhadap aspek fleksibilitas implementasi struktur tabel database yang dianalisis yang diimplementasikan dalam unit yang diberi nama InputPenilaian.pas. Implementasi tampilan input penilaian untuk pemakai dengan login sebagai Pakar ditunjukkan pada Gambar 5.61.

351

Gambar 5.61: Implementasi tampilan input penilaian untuk pemakai dengan login sebagai Pakar 5.2.4. Implementasi Output Output yang dihasilkan oleh program aplikasi adalah laporan-laporan yang ditujukan bagi para pemakai, baik sebagai User maupun Pakar, dimana untuk masing-masing laporan diberikan pilihan untuk Preview dan Cetak ke media hardcopy berupa kertas melalui printer. Dalam penelitian ini, tampilan output untuk pemakai sebagai User maupun Pakar dirancang dalam bentuk dan format yang sama, meliputi:

352

1. Daftar Rancangan Struktur Tabel Database Output Daftar Rancangan Struktur Tabel Database diimplementasikan dalam sebuah unit yang diberi nama DaftarRancangan.pas. Contoh implementasi tampilan Daftar Rancangan Struktur Tabel Database secara keseluruhan ditunjukkan pada Lampiran 53, berdasarkan Pendidikan Perancang S2 ditunjukkan pada Lampiran 54, berdasarkan Pendidikan Perancang S1 ditunjukkan pada Lampiran 55, berdasarkan Pendidikan Perancang D3 ditunjukkan pada Lampiran 56. 2. Hasil Analisis Per Rancangan Output

Hasil

Analisis

diimplementasikan

Per

dalam

Rancangan sebuah

unit

Struktur

Tabel

yang

Database

diberi

nama

HasilPerRancangan.pas. Contoh implementasi tampilan Hasil Analisis Per Rancangan ditunjukkan pada Lampiran 57. 3. Daftar Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database Output Daftar Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database diimplementasikan dalam sebuah unit yang diberi nama HasilDaftar.pas. Contoh implementasi tampilan Daftar Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database berdasarkan tingkat fleksibilitas ditunjukkan pada Lampiran 58, berdasarkan Pendidikan Perancang ditunjukkan pada Lampiran 59, dan secara keseluruhan ditunjukkan pada Lampiran 60. 4. Hasil Statistik Analisis Fleksibilitas Implementasi Struktur Tabel Database Output Statistik Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database

diimplementasikan

dalam

sebuah

unit

yang

diberi

nama

353

HasilStatistik.pas. Contoh implementasi tampilan Statistik Hasil Analisis Fleksibilitas Rancangan Struktur Tabel Database berdasarkan tingkat fleksibilitas ditunjukkan pada Lampiran 61, berdasarkan Pendidikan Perancang ditunjukkan pada Lampiran 62, dan secara keseluruhan ditunjukkan pada Lampiran 63.

5.2.5. Implementasi Teknologi Implementasi teknologi yang digunakan untuk menjalankan sistem aplikasi dalam penelitian ini sama dengan yang direncanakan, yaitu: 1. Hardware, spesifikasi hardware yang digunakan adalah sebagai berikut: a. Processor Mobile Intel® Pentium 4 ® 2,30 GHz b. RAM 256 MB 2. Software, spesifikasi software yang digunakan adalah sebagai berikut: a. OS- MS Windows XP Home Edition version 2002 Sevice Pack 1 b. Borland Delphi Enterprise version 6.0 c. Database Desktop version 7.0 3. Arsitektur Aplikasi, aplikasi yang dikembangkan dalam penelitian ini bersifat stand alone.

354

5.2.6. Pengujian Sistem Pengujian terhadap sistem yang dikembangkan dalam penelitian ini dilakukan dengan beberapa cara, yaitu sebagai berikut: 1. Pengujian validasi input data. Hasil pengujian menunjukkan bahwa kesalahankesalahan input data telah dapat diantisipasi, yaitu dengan memberikan pesanpesan kesalahan. 2. Pengujian validasi proses pengolahan data. Sebelum pengujian proses pengolahan data dilakukan, maka telah dilakukan proses pengolahan data secara manual. Hasil pengolahan data secara manual ini dijadikan referensi untuk pengujian hasil yang diberikan oleh sistem. Dalam hal ini, pengujian dilakukan dengan cara membandingkan hasil pengolahan secara manual dengan hasil pengolahan yang diberikan oleh sistem. Hasil pengujian menunjukkan bahwa hasil pengolahan data yang diberikan oleh sistem telah sesuai dengan referensi. Hal ini berarti bahwa sistem telah beroperasi dengan benar. 3. Pengujian validasi output. Hasil pengujian menunjukkan bahwa hasil pengolahan data yang diberikan oleh sistem telah sesuai dengan referensi. Hal ini berarti bahwa sistem telah beroperasi dengan benar. 4. Pengujian setiap unit dalam program aplikasi. Hasil pengujian menunjukkan bahwa setiap unit yang dikembangkan telah beroperasi sesuai dengan fungsinya.

355

5. Pengujian integrasi seluruh unit dalam program aplikasi. Hasil pengujian menunjukkan bahwa hasil integrasi seluruh unit yang dikembangkan telah beroperasi sesuai dengan fungsinya.

5.2.7. Kelemahan Sistem Sekalipun sistem telah beroperasi dengan benar, sesuai dengan tujuan yang ditetapkan, sistem yang dikembangkan dalam penelitian ini masih memiliki kelemahan, antara lain: 1. Setiap rancangan struktur tabel database yang akan dianalisis tetap harus diinputkan kembali secara manual. Hal ini dikarenakan setiap DBMS memiliki karakteristik, aturan, dan format data yang berbeda dalam mendefinisikan rancangan struktur tabel database. 2. Pada saat penilaian, Pakar masih harus melakukan interpretasi terhadap setiap definisi nama, tipe, ukuran, dan nilai entry pada atribut. 3. Sistem yang dikembangkan dalam penelitian ini belum dapat beroperasi secara “cerdas”, belum mampu menginterpretasikan setiap definisi atribut yang diberikan oleh perancang. Hal ini dikarenakan setiap perancang memiliki gaya yang berbeda dalam mendefinisikan nama-nama atribut.

BAB VI KESIMPULAN DAN SARAN

6.1. Kesimpulan Fleksibilitas rancangan struktur tabel database merupakan salah satu faktor yang menentukan kwalitas dan keberhasilan implementasi SIM pada suatu organisasi. Sesuai dengan rumusan, batasan, dan tujuan yang ditetapkan dalam penelitian ini, maka berdasarkan hasil analisis fleksibilitas data rancangan struktur tabel database pada hasil-hasil penelitian untuk SIAKAD; perancangan, implementasi, dan pengujian program aplikasi, maka diketahui dan dapat disimpulkan sebagai berikut ini. Berdasarkan hasil analisis fleksibilitas rancangan struktur tabel database pada 28 data rancangan yang memuat sebanyak 262 tabel dan 1906 atribut, diketahui bahwa berdasarkan tingkat fleksibilitas, terdapat 3 rancangan termasuk SANGAT BAIK, di dalamnya memuat sebanyak 49 tabel dan 443 atribut yang terdiri atas 371 (=83,75%) atribut bersifat fleksibel dan 72 (=16,25%) atribut tidak fleksibel; 15 rancangan termasuk BAIK, di dalamnya memuat 119 tabel dan 664 atribut yang terdiri atas 464 (=69,88%) atribut bersifat fleksibel dan 200 (=30,12%) atribut tidak fleksibel; 8 rancangan termasuk SEDANG, di dalamnya memuat sebanyak 78 tabel dan 621 atribut yang terdiri atas 316 (=50,89%) atribut bersifat fleksibel dan 305 (=49,11%) atribut tidak fleksibel; 1 rancangan termasuk BURUK, di dalamnya memuat sebanyak 10 tabel dan 137 atribut yang terdiri atas 49 (=35,77%) atribut bersifat fleksibel dan 88 (=64,23%) atribut tidak fleksibel;

356

357

tidak ada rancangan yang termasuk kategori SANGAT BURUK; 1 rancangan tidak dapat dianalisis. Berdasarkan tingkat pendidikan perancang, maka dapat diketahui bahwa 9 rancangan S2 yang di dalamnya memuat sebanyak 126 tabel dan 1166 atribut, terdapat sebanyak 735 (=63,04%) atribut bersifat fleksibel dan 431 (=36,96%) atribut tidak fleksibel, serta 1 rancangan tidak dapat dianalisis; 10 rancangan S1 yang di dalamnya memuat sebanyak 65 tabel dan 383 atribut, terdapat sebanyak 238 (=62,14%) atribut bersifat fleksibel dan 145 (=37,86%) atribut tidak fleksibel; 8 rancangan D3 yang di dalamnya memuat sebanyak 65 tabel dan 316 atribut, terdapat sebanyak 222 (=70,25%) atribut bersifat fleksibel dan 94 (=29,75%) atribut tidak fleksibel. Secara keseluruhan, dari 10 rancangan yang dirancang oleh perancang dengan pendidikan S2, terdapat 2 (=22,22%) termasuk tingkatan SANGAT BAIK, 4 (=44,44%) termasuk tingkatan BAIK, 2 (=22,22%) termasuk tingkatan SEDANG, 1 (=11,11%) termasuk tingkatan BURUK, tidak ada rancangan yang termasuk tingkatan SANGAT BURUK, serta 1 rancangan tidak dapat dianalisis; dari 10 rancangan yang dirancang oleh perancang dengan pendidikan S1, 6 (=60,00%) termasuk tingkatan BAIK, 4 (=40,00%) termasuk tingkatan SEDANG, tidak ada rancangan yang termasuk tingkatan SANGAT BAIK, BURUK maupun SANGAT BURUK; dari 8 rancangan yang dirancang oleh perancang dengan pendidikan D3, terdapat 1 (=12,50%) termasuk tingkatan SANGAT BAIK, 6 (=75,00%) termasuk tingkatan BAIK, 1 (=12,50%) termasuk tingkatan SEDANG, tidak ada rancangan yang termasuk tingkatan BURUK dan SANGAT BURUK.

358

Berdasarkan hasil identifikasi, dapat diketahui bahwa rancangan struktur tabel database yang tidak fleksibel terjadi karena faktor-faktor sebagai berikut: (1) Penggunaan kode pada nilai data tidak dilengkapi dengan tabel referensi penggunaan kode eksternal berupa kode blok tidak dilengkapi dengan tabel referensi; (2) nilai-nilai data yang semestinya perlu dikodekan disimpan secara langsung sehingga memerlukan penulisan kembali nilai-nilai data yang sama secara berulang yang dapat mengakibatkan inkonsistensi data; (3) Nilai-nilai data disimpan secara berulang/rangkap; (4) Penyusunan set atribut secara berulang (repeated group) dalam tabel secara horisontal tidak memenuhi karakteristik tabel relasional dan tidak fleksibel, karena jumlah perulangan set atribut secara berulang tidak dapat bersifat dinamis, sehingga penyusunan secara horisontal tersebut akan menimbulkan kesulitan apabila terjadi perubahan. Secara umum faktor yang menjadi penyebab rancangan struktur tabel database tidak fleksibel adalah: (1) Batasan lingkup sistem yang tidak tepat; (2) Data-data disimpan bersifat program oriented; (3) Tidak ada standarisasi nilai rinci data; (4) Data tidak lengkap; (5) Pengelompokan data tidak tepat; (6) Penggunaan kode pada data yang tidak dilengkapi dengan referensi atau data yang seharusnya dikodekan disimpan secara langsung; (7) Penggunaan kunci primer (Primary Key) yang tidak tepat; (8) Penggunaan tabel logik yang tidak terkontrol dengan baik. Alternatif kerangka rancangan struktur tabel database yang fleksibel untuk SIAKAD dengan business rules yang umum digunakan di institusi Perguruan Tinggi melibatkan 12 sub sistem pengolahan data, meliputi SIPENMARU,

359

SIHEREGISTERASI, SIWALI, SIKRS, SIKULIAH, SIPRAKTIKUM, SIKP, SIKKN, SITA, SIYUDISIUM, SIWISUDA, serta SIALUMNI. Untuk mendapatkan rancangan struktur tabel database yang fleksibel, dapat dilakukan dengan empat langkah, yaitu: (1) Analisis kebutuhan, (2) Perancangan, (3) Pengujian, dan (4) Implementasi. Langkah Analisis Kebutuhan, meliputi analisis kebutuhan berikut: (1) Batasan/ruang lingkup; (2) Model bisnis; (3) Keterkaitan antar unit fungsional; (4) Informasi dan data; (5) Perubahan kebutuhan informasi (dan data). Langkah Perancangan, meliputi: (1) Perancangan Tahap Awal; (2) Perancangan Tahap Lanjutan. Perancangan Tahap Awal meliputi: (1) Pengelompokan data; (2) Standarisasi nilai rinci data, standarisasi kode data pada atribut; (3) perancangan awal; (4) normalisasi; (5) Penetapan kunci relasi. Perancangan tahap lanjutan meliputi: (1) Standarisasi data (meliputi nama atribut dan kode data); (2) Pengkodean nilai-nilai data yang digunakan secara berulang (pengkodean untuk nilai-nilai data yang mutlak tidak akan mengalami perubahan di kemudian hari; (3) Penggunaan kode berupa kode blok; (4) Pengkodean untuk nilai-nilai data yang memiliki kemungkinan mengalami perubahan di kemudian hari; (5) Perancangan keamanan data (meliputi keamanan fisik dan non fisik). Langkah Pengujian meliputi pengujian pada aspek berikut: (1) Kelengkapan data; (2) Kerangkapan data; (3) Inkonsistensi data; (4) Penggunaan bersama; (5) Fleksibilitas struktur tabel terhadap perubahan nilainilai data maupun kebutuhan baru. Langkah Implementasi meliputi: (1) Pemilihan DBMS; (2) Definisi struktur tabel database; (3) pengisian database; (4) penggunaan database; (5) dokumentasi; (6) Pemeliharaan.

360

6.2. Saran Untuk penelitian selanjutnya, dapat dilakukan untuk menganalisis permasalahan-permasalahan yang terkait dengan standarisasi nilai rinci data dalam database, penggunaan kode data dalam database, dan integrasi antar database untuk sistem informasi berskala luas-nasional.

DAFTAR PUSTAKA Ahituv, N., Neumann, S., and Zviran, M., 2002, A System Development Methodology for ERP Systems, The Journal of Computer Information Systems, pp. 42 AMULET Development Corp, 2004, How To Modify Database Structure, eCriteria, Web Hosted Databse for Business Avison and Fitzgerald, 1995, Information Systems Development: Methodologies, Techniques, and Tools, McGraw Hill, New York Badan Akreditasi Nasional Perguruan Tinggi Departemen Pendidikan Nasional, 2001, Pedoman Evaluasi Diri Program Studi, Jakarta Badan Akreditasi Nasional Perguruan Tinggi Departemen Pendidikan Nasional, 2001, Pedoman Penyusunan Portofolio Akreditasi Program Studi, Jakarta Badan Akreditasi Nasional Perguruan Tinggi Departemen Pendidikan Nasional, 2001, Panduan Pengisian Borang Akreditasi Program Studi S1, Jakarta Ballou, D.P. and Pazer, H.L., 1985, Modeling Data and Process Quality in MultiInput, Multi-Output Information Systems, Journal of Management Science, vol. 31, pp. 150-162 Date, C.J., 1995, An Introduction To Database Systems, Adisson Wesley Publishing, Co., Inc. Davis, G.B. and Margrethe, 1987, Management Information Systems, Conceptual Foundations, Structure and Development, McGraw-Hill, Tokyo Departemen Pendidikan Nasional, 1999, Peraturan Pemerintah Nomor 60 Tahun 1999 Tentang Pendidikan Tinggi, Jakarta Direktur Jenderal Pendidikan Tinggi, 1996, Kerangka Pengembangan Jangka Panjang 1996-2005, Jakarta English, L.P., 1999, Improving Data Warehouse and Business Information Quality: Methods for Reducing Costs and Increasing Profits. New York, NY: Wiley, 1999 Eppler, M.J. and Wittig, D., 2000, Conceptualizing Information Quality: A Review of Information Quality Frameworks from the Last Ten Years,

361

362

presented at 5th International Conference on Information Quality (ICIQ 2000), Cambridge, MA Garvin, D.A., 1987, Competing on the Eight Dimensions of Quality, Harvard Business Review, (November-December 1987), pp. 108-109 Hasibuan, Z.A., 2004, Pendekatan Menyeluruh dalam Pengembangan Sistem Informasi (A Holistic Approaches to Information Systems Development), disampaikan pada Seminar Kuliah Perdana Program Magister Ilmu Komputer dan Manajemen Informasi UGM, Yogyakarta Helfert, M., Zellner, G. and Sousa, C., 2002, Data Quality Problems and Proactive Data Quality Management in Data-Warehouse-Systems, presented at BITWorld 2002, Guyaquil, Ecuador Indrajit, R.E., 2000, Manajemen Sistem Informasi dan Teknologi Informasi, PT. Elex Media Komputindo, Jakarta IST AKPRIND, 2002, Portofolio IST AKPRIND, Yogyakarta Liu, L. and Chi, L.N., 2002, Evolutional Data Quality: A Theory-Specific View, presented at 7th International Conference on Information Quality (ICIQ 2002), Cambridge, MA Loudon Loudon, 2004, Management Information Systems 8/e, Prentice Hall Martin, J., 1975, Computer Database Organizations, parth I, New Jersey, Prentice-Hall, Inc. Martin, J., 1976, Computer Database Organizations, parth II, New Jersey, Prentice-Hall, Inc. McLeod, R. and Schell, G., 2001, Management Information Systems, 8th edition, Prentice Hall Miller, H., 1996, The Multiple Dimensions of Information Quality, Information Systems Management, vol. 13, pp. 79-82 Nugroho, E., 1991, Pengaruh Struktur Organisasi dan Sumber Daya Manusia Terhadap Keberhasilan Implementasi Sistem Informasi Manajemen dalam Organisasi, Tesis, Program Magister Sains, Prodi Akuntansi, F akultas Ekonomi, UGM, Yogyakarta Parsaye, K., Chignell, M., Khoshafian, S., and Wong, H., 1989, Intelligent Databases, Jhon Wiley & Sons Inc., Canada

363

Paul, R.J., 2002, Is Information Systems Intellectual Subject, European Journal of Information Systems,, pp. 174-177 Pressman, R.S., 2001, Software Engineering A Practitioner’s Approach, 5th edition, McGraw-Hill, Inc., New York Program Studi Teknik Informatika FTI ISTA, 2002, Evaluasi Diri Program Studi Teknik Informatika FTI, IST AKPRIND, Yogyakarta Ramakrishnan, R., 1998, Database Management Systems, International edition, McGraw- Hill International, Singapore Redman, T.C., 1996, Data Quality for the Information Age, Boston, MA: Artech House References: OS/400 DB2/400 Database-An Overview (SC41-3700-00, CD-ROM QBKAUB01), OS/400 DDS Reference (SC41-3712-00, CD-ROM QBKAUI01) Senn, J.A, 1987, Information Systems in Management, Wadsworth Publishing Company, Belmont, California Silberschatz, A., Korth, H.F., and Sudarshan, S., 2001, Database System Concepts, 4th edition Suwardi, 2003, Penyusunan Indikator Kinerja dalam Quality Assurance, Makalah Pelatihan, Disampaikan pada Pelatihan Quality Assurance di IST AKPRIND Yogyakarta tanggal 24 Oktober 2003, Yogyakarta, Departemen Tanah, Fakultas Pertanian, IPB Te'eni, D., 1993, Behavioral Aspects of Data Production and Their Impact on Data Quality, Journal of Database Management, vol. 4, pp. 30-38 Turban, E. and Aronson, J.E., 2001, Decision Support Systems and Intelligent Systems, 6th edition, Prentice Hall, Upper Saddle River, New Jersey Wand, Y. and Wang, R.Y., 1996, Anchoring Data Quality Dimensions in Ontological Foundations, Journal of Communications of the ACM, vol. 39, pp. 86-95 Wang, R.Y. and Strong, D.M., 1996, Beyond Accuracy: What Data Quality Means to Data Consumers, Journal of Management of Information Systems, vol. 12, pp. 5-33 Wang, R.Y., Reddy, M.P. and Kon, H.B., 1995, Toward Quality Data: An Attribute-Based Approach, Decision Support Systems, vol. 13, pp. 349-372

364

Whitten, J.L. and Bentley, L.D., 1998, Systems Analysis & Design Methods, 4th edition, Irwin/McGraw-Hill International Co., New York Wiederhold, G., 1988, Database Design, 2nd edition, Singapore, Mc.Graw-Hill International, Co. Sumber Pustaka dari Internet: ……, Database Schema for Universal Usage, http://www.webservertalk.com /message1055091-2.html, diakses pada tanggal 01-08-2005 ……, Kerjasama Sistem Informasi Akademik, http://home.unpar.ac.id/~gatut /makalah/sia-ai3-1.ppt, diakses pada tanggal 01-08-2005 Blue Sheep Ltd., Data Quality Audit, September 2001, Blue Sheep® Limited, www.bluesheep.com/cgi/news/show.php4?f=010102, diakses pada tanggal 01-08-2005 Harrington, J.L., Relational Database Design, relational.answers, http://www.utexas.edu/academic/cit/howto/resources/database/relational. answers.pdf, diakses pada tanggal 01-08-2005 Herden, O., 2001, Measuring Quality of Database Schemas by ReviewingConcept, Criteria and Tool, http://www.iro.umontreal.ca/~sahraouh /qaoose01/Herden.PDF, diakses pada tanggal 01-08-2005 Institut Teknologi Sepuluh Nopember Surabaya, http://www.mmt.its.ac.id/, diakses pada tanggal 06-08-2005 Klesse, M., Herrmann, C., Brändli, P., Mügeli, T., Maier, D., 2005, Information Quality And The Raising Demands Of Regulators: Reengineering The Customer Investigation Process At Credit Suisse, http://wotan.liu.edu/docis/dbl /iqiqiq/2004_418_CIPACS.htm, diakses pada tanggal 11-08-2005 Litwin, P., 2003, Fundamentals of Relational Database Design, September 7th, 2003, http://r937.com/relational.html, diakses pada tanggal 11-08-2005 Miller, H., 2004, The Multiple Dimensions Of Information Quality, Muhlenberg College Allentown, PA 18104, September 2004, www.muhlenberg.edu /depts/abe/business/miller/mdiqual.html, diakses pada tanggal 11-08-2005 Mullen, B., 2005, Generalized Table Suggestions, http://www2.cstudies.ubc.ca /~mullen/IEDBS.html#GeneralTables, diakses pada tanggal 11-08-2005

365

Mullen, B., 2005, Information Engineering and Database Systems, UBC Robson Square, June 6-July 11, 2005, http://www2.cstudies.ubc.ca/~mullen /IEDBS.html, diakses pada tanggal 11-08-2005 Mullen, B., 2005, The Database And Its Structure, http://www.gowerpub.com /pdf/pidmc2.pdf, diakses pada tanggal 11-08-2005 Pramana, AAG.I., Sidabalok, C.A., Sormin, J.C. dan Minnarto Djojo, 2001, Perancangan Software Sistem Informasi Akademik FTUI, Arcle Technologies, http://www.arcle.net, diakses pada tanggal 11-08-2005 Prastowo, B.N., 2004, Memadukan Sistem Informasi Manajemen Akademik, http://www.ppti.ugm.ac.id, diakses pada tanggal 11-08-2005 Sistem Informasi Interaktif Mahasiswa, SINTESISTM, http://www.atmajaya.ac.id: 8080/Sintesis/main/sintesis.html, diakses pada tanggal 11-08-2005 Stone, B.V., Database Design Flexibility for the Future, http://www. mcpressonline.com/[email protected]@.21d093f8, diakses pada tanggal 11-08-2005 STSI Surakarta, http://www.stsi-ska.ac.id/pasca/sisteminformasi.htm, diakses pada tanggal 06-08-2005 Unibraw Brawijaya Malang, http://siakad.brawijaya.ac.id/, diakses pada tanggal 06-08-2005 Universitas Airlangga Surabaya, http://www.unair.ac.id/, diakses pada tanggal 06-08-2005 Universitas Atma Jaya Jakarta, http://www.atmajaya.ac.id/, diakses pada tanggal 06-08-2005 Universitas Gadjah Mada Yogyakarta, http://www.faperta.ugm.ac.id/akademik /manual.pdf, diakses pada tanggal 06-08-2005 Universitas Hasannudin Makasar, http://www.unhas.ac.id/~ais/, diakses pada tanggal 06-08-2005 Universitas Indonesia Jakarta, https://www.akademik.ui.ac.id/, diakses pada tanggal 06-08-2005 Universitas Islam Indonesia Yogyakarta, http://www.uii.ac.id/, diakses pada tanggal 06-08-2005

366

Universitas Islam Negeri Syarif Hidayatullah Jakarta, http://www.uinjkt.ac.id/, diakses pada tanggal 06-08-2005 Universitas Islam Sumatera Utara (UISU), http://www.uisu.ac.id/, diakses pada tanggal 15-08-2005 Universitas Kristen Pradnya Paramitha, http://www.pradnya-paramitha.ac.id/, diakses pada tanggal 15-08-2005 Universitas Muhammadiyah Yogyakarta, http://www.umy.ac.id/, diakses pada tanggal 15-08-2005 Universitas Negeri Jember, http://www.unej.ac.id/upt/ti/about_me.html, diakses pada tanggal 15-08-2005 Weidema, B.P., 2003, Market modelling in LCA. København: Danish Environmental Protection Agency. Environmental project. Currently available as Final draft manuscript from http://www.lcafood.dk/processes /energyconversion/market.pdf, diakses pada tanggal 15-08-2005 Weidema, B.P., 2004, Flexibility for Application Market Modelling in LCI Databases, LCA Consultants, www.lca-net.com, diakses pada tanggal 1508-2005 Sumber Pustaka dari Laporan Penelitian/Tesis: Amali, L.N., 2003, Sistem Informasi Jadwal Kuliah di PT dengan Pendekatan Berorientasi Obyek (Studi Kasus di IKIP Negeri Gorontalo), Tesis, Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM, Yogyakarta Erlinda, S., 2003, Sistem Informasi Penmaru Berbasis Web pada STMIK-AMIK Riau Pekanbaru, Tesis, Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM, Yogyakarta Irfianti, A.D., 2003, Rancang Bangun Sistem Informasi Akademik Menggunakan ORACLE Tools Berbasis Web dan WAP (Studi Kasus: STIKOM Surabaya), Tesis, Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM, Yogyakarta Jatmika, 2003, Perbandingan Analisis dan Desain Database Sistem Informasi Akademik Menggunakan Model Relasi Entitas dengan Model Berorientasi Obyek, Tesis, Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM, Yogyakarta

367

Katili, M.R., 2003, Database Terpadu untuk Pengembangan Sistem Infomasi Akademik, Tesis, Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM, Yogyakarta, Tesis, Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM, Yogyakarta Kurdi, N.K., 2005, Rancang Bangun Sistem Informasi Administrasi Akademik (SIAKAD-2000) Berbasis Intranet untuk Universitas Lampung, Tesis, Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM, Yogyakarta Medi, 2002, Rancangan WEB Akademik dengan Basisdata Terdistribusi, Tesis, Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM, Yogyakarta Murni, 2004, Sistem Manajemen Informasi Berbasis Web untuk Pengelolaan Data Alumni STMIK Indonesia Padang, Tesis, Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM, Yogyakarta Suhirman, 2004, Sistem Informasi Penilaian Akreditasi Program Studi Strata-1, Tesis, Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM, Yogyakarta Yuniansyah, 2003, Sistem Informasi Akademik Berbasis Three-Tier pada STMIK SIGMA Palembang, Tesis, Sekolah Pascasarjana, Program Studi Ilmu Komputer, FMIPA, UGM, Yogyakarta Sumber Pustaka dari Laporan Penelitian/Skripsi: Astawa, I.G.N.R., 2003, Implementasi Wap pada Sistem Informasi Akademik Online (Studi kasus di Jurusan Teknik Informatika IST AKPRIND Yogyakarta), Skripsi, Program S-1, Program Studi Teknik Informatika, FTI, IST AKPRIND, Yogyakarta Baital, M.S., 2003, Aplikasi Client/Server Pengolahan Data Pendaftaran Praktikum pada Laboratorium Komputer 1-2 IST AKPRIND Yogyakarta, Skripsi, Program S-1, Program Studi Teknik Informatika, FTI, IST AKPRIND, Yogyakarta Daniati, N., 2005, Perancangan Sistem Informasi Pendaftaran Mahasiswa Baru IST AKPRIND Yogyakarta Secara Online, Skripsi, Program S-1, Program Studi Teknik Informatika, FTI, IST AKPRIND, Yogyakarta Handayani, D.S., 2004, Analisis dan Perancangan Sistem Client/ Server Pendaftaran Praktikum Laboratorium Komputer 4 IST AKPRIND Yogyakarta Menggunakan Visual Basic 6.0 dan MySql, Skripsi, Program S-1, Program Studi Teknik Informatika, FTI, IST AKPRIND, Yogyakarta

368

Rahayuningsih, R., 2000, Rekayasa Komputerisasi KRS dan KHS Universitas X, Skripsi, Program S-1, Program Studi Teknik Informatika, FTI, IST AKPRIND, Yogyakarta Saputra, O.E., 2001, Perancangan Sistem Informasi Data Kebutuhan Mahasiswa Jurusan Teknik Informatika IST AKPRIND Yogyakarta, Skripsi, Program S-1, Program Studi Teknik Informatika, FTI, IST AKPRIND, Yogyakarta Sophian, Y., 2004, Sistem Pendaftaran Mahasiswa Baru di IST AKPRIND Yogyakarta Secara Online, Skripsi, Program S-1, Program Studi Teknik Informatika, FTI, IST AKPRIND, Yogyakarta Sudarto, 2003, Sistem Pengolahan Data Penyelenggaraan Praktikum di Laboratorium Penelitian Operasional IST AKPRIND Yogyakarta, Skripsi, Program S-1, Program Studi Teknik Informatika, FTI, IST AKPRIND, Yogyakarta Yudi S, S., 2000, Sistem Pengolahan Data Her-Registerasi Mahasiswa pada IST AKPRIND Yogyakarta, Skripsi, Program S-1, Program Studi Teknik Informatika, FTI, IST AKPRIND, Yogyakarta Zaini, 2002, Perancangan Sistem Pendaftaran Mahasiswa Baru IST AKPRIND Yogyakarta Melalui Internet, Skripsi, Program S-1, Program Studi Teknik Informatika, FTI, IST AKPRIND, Yogyakarta Sumber dari Laporan Penelitian/Tugas Akhir: Baihaqie, M.R., 2005, Implementasi Midlet Java Sebagai Media Informasi Akademik Kampus IST AKPRIND, Tugas Akhir, Program D-3, Program Studi Manajemen Informatika & Teknik Komputer, FTI, IST AKPRIND, Yogyakarta Ismani, M., 2005, Entry KRS Melalui SMS, Tugas Akhir, Program D-3, Program Studi Manajemen Informatika & Teknik Komputer, FTI, IST AKPRIND, Yogyakarta Mendrofa, O., Komputerisasi Data KRS Mahasiswa pada IAIN Sunan Kalijaga Yogyakarta, Tugas Akhir, Program D-3, Program Studi Manajemen Informatika & Teknik Komputer, FTI, IST AKPRIND, Yogyakarta Rufaidah, Z.I., 2002, Website Informasi Jurusan Manajemen Informatika & Teknik Komputer Program D-3 IST AKPRIND Yogyakarta, Tugas Akhir, Program D-3, Program Studi Manajemen Informatika & Teknik Komputer, FTI, IST AKPRIND, Yogyakarta

369

Sinaga, G.G.S., 2005, Sistem Kegiatan Praktikum Berbasis Client Server di Laboratorium Komputer 1-2 IST AKPRIND Menggunakan Delphi 7.0 dan MySql, Tugas Akhir, Program D-3, Program Studi Manajemen Informatika & Teknik Komputer, FTI, IST AKPRIND, Yogyakarta Susilowati, A., 2003, Perancangan Sistem Penyeleksian Mahasiswa Baru IST AKPRIND Yogyakarta Menggunakan Aplikasi Visual Basic 6.0, Tugas Akhir, Program D-3, Program Studi Manajemen Informatika & Teknik Komputer, FTI, IST AKPRIND, Yogyakarta Widodo, P., 2005, Sistem Informasi Asisten Dosen Laboratorium Keperawatan AKPER Muhammadiyah Klaten, Tugas Akhir, Program D-3, Program Studi Manajemen Informatika & Teknik Komputer, FTI, IST AKPRIND, Yogyakarta Yulia, E., 2000, Sistem Komputerisasi Pengolahan Data Penerimaan Mahasiswa di STT Komputer TAKASINDO Yogyakarta, Tugas Akhir, Program D-3, Program Studi Manajemen Informatika & Teknik Komputer, FTI, IST AKPRIND, Yogyakarta

370

DATA_09_002

LAMPIRAN 1

Nama peneliti Judul penelitian

: Asti Dwi Irfianti : Rancang Bangun Sistem Informasi Akademik dengan Menggunakan ORACLE Tools Berbasis Web & WAP (Studi Kasus:STIKOM Surabaya) Tahun : 2003 Kode referensi : T IK 71 Jumlah tabel database : 19 Jumlah atibut : 259 Pada halaman : 73 - 78 Desain struktur tabel database yang digunakan adalah sebagai berikut: FAKULTAS (Irfianti, 2003, hal: 73) Field number Field name 1. ID 2. NAMA 3. STATUS

Data type Varchar(5) Varchar(50) Varchar(1)

Key PK

Null Not null Not null Not null

KOTA (Irfianti, 2003, hal: 73) Field number Field name 1. ID 2. NAMA 3. JENIS

Data type Varchar(4) Varchar(30) Varchar(1)

Key PK

Null Not null Not null

SMU_MHS (Irfianti, 2003, hal: 73) Field number Field name 1. ID 2. NAMA 3. ALAMAT 4. STATUS 5. KOTA_ID 6. KODE_POS 7. KET

Data type Varchar(7) Varchar(50) Varchar(50) Varchar(1) Varchar(4) Varchar(10) Varchar(1)

Key PK

Null Not null Not null

MAHASISWA (Irfianti, 2003, hal: 73) Field number Field name 1. NIM 2. NIRM 3. NAMA 4. ALAMAT 5. STS_RUMAH 6. SEX 7. GOL_DARAH 8. STS_MARITAL 9. WN 10. KOTA_LAHIR 11. STS_PRESENSI 12. TGL_LAHIR 13. JALUR_MASUK 14. KELAS 15. PIN 16. KOTA_ID 17. DOSEN_WL 18. AGAMA

Data type Varchar(11) Varchar(20) Varchar(50) Varchar(200) Number(1) Number(1) Number(1) Number(1) Number(1) Varchar(4) Varchar(1) Date Number(1) Number(1) Varchar(6) Varchar(4) Varchar(6) Number (1)

Key PK/FK

Not null

Null Not null Not null Not null Not null

Not null FK

Not null Not null

500

LAMPIRAN 52

No

Tabel

Atribut

1

Identitas

2

Jaga

Kd_Ass Nm_Ass Alamat Jenkel Pend Tgl_Lahir Telpon Tgl_Masuk Tanggal Kd_Masuk Kd_Ass Nm_Ass Hari Jam_Masuk Jam_Keluar Mt_Prak

3

Honor

Tanggal Kd_Ass Kd_Masuk Hari Jam_Masuk Jam_Keluar Mt_Prak Pend Uang_Mkn Uang_Hnr Hnr_Total

Penilaian untuk analisis fleksibilitas rancangan struktur tabel database pada DATA_06_008 Tipe-Ukuran Key Kemungkinan Fleksibel Penjelasan berubah [Y/T] [Y/T] Alpha(3) PK Y Y o Kecamatan, Kabupaten, Propinsi dalam Alamat perlu dikodekan dan dibuat tabel referensi o Pend perlu dikodekan dan dibuat tabel referensi Alpha(40) T Y Alpha(50) Y T Alpha(1) T Y Alpha(9) Y T Date T Y Alpha(15) T Y Date T Y Date T Y Alpha(3) PK T Y o Nm_Ass tidak perlu disimpan o Hari perlu dikodekan Alpha(3) PK/FK Y Y o Mt_Prak perlu dikodekan dan dibuat tabel referensi Alpha(40) T T Alpha(7) T T Alpha(10) T Y Alpha(10) T Y Alpha(20) Y T Date PK T Y o Hari tidak perlu disimpan Alpha(3) PK Y Y o Jam_Masuk tidak perlu disimpan Alpha(3) PK T Y o Jam_Keluar tidak perlu disimpan Alpha(7) T T o Mt_Prak tidak perlu disimpan Alpha(10) T T o Pend tidak perlu disimpan Alpha(10) T T o Uang_Mkn perlu tabel referensi Alpha(20) Y T o Uang_Hnr perlu tabel referensi Alpha(9) Num Num Num

Y Y Y Y

T T T Y

501

LAMPIRAN 53

518

LAMPIRAN 63