BAB III ANALISIS SISTEM LAMA Pada Bab 3 ini memberikan gambaran dan penjelasan mengenai fungsi-fungsi yang ada di sistem lama beserta basisdata yang digunakan. Aspek-aspek apa saja yang menjadi masalah sehingga suatu sistem perlu direkayasa ulang, terutama pada basisdatanya. Metode analisa yang digunakan adalah dengan melakukan observasi kebutuhan sistem secara keseluruhan.
Spesifikasi kebutuhan perangkat lunak menjadi suatu hal yang penting dalam pembangunan sebuah sistem. Kebutuhan perangkat lunak dapat dibagi 2 kategori besar yaitu kebutuhan fungsional dan kebutuhan non fungsional. Kebutuhan fungsional meliputi kegiatan atau proses bisnis yang harus diimplementasikan di dalam perangkat lunak, sedangkan kebutuhan non fungsional meliputi semua komponen yang mendukung proses bisnis tersebut, seperti perangkat lunak akan menggunakan DBMS berbasis opensource yaitu MySQL. Untuk mendapatkan informasi kebutuhan fungsional dan non fungsional tersebut dilakukan dengan beberapa cara, yaitu: 1. Wawancara; 2. Observasi. Seiring dengan kemajuan teknologi dan adanya peningkatan kebutuhan perangkat lunak, maka sebuah sistem perangkat lunak diharapkan mampu untuk direkayasa ulang, baik dari sisi program, data dan dokumentasi. Perekayasaan ulang perangkat
lunak
membutuhkan
pendekatan-pendekatan
khusus,
karena
menyangkut sistem yang lama (legacy system) dengan sistem yang baru.
III.1 Fitur Perangkat Lunak Sistem informasi akademik Fakultas Ilmu Komputer Universitas Sriwijaya (Simak Fasilkom Unsri) ini menggunakan basis data berjenis indexed file based dengan ekstensi dBase file (.dbf) dan berusaha mengikuti kaidah pendekatan relasional.
33
Secara umum Simak memiliki fungsionalitas yang hampir sama dengan sistem informasi perguruan tinggi lainnya. Simak ini melayani beberapa kegiatan administrasi akademik antara lain yaitu: 1. Pendataan identitas mahasiswa melalui scanner OMR. Pada kegiatan ini mahasiswa baru akan diberi formulir isian biodatanya dengan menghitamkan bulatan yang disediakan di formulir. Formulir isian yang telah diisi akan diproses dengan mengambil hasilnya melalui scanner OMR, kemudian informasi yang di dalam file akan diubah formatnya dengan program dan langsung dimasukkan ke dalam file basis data. File biodata mahasiswa akan dipisahkan menjadi per jurusan. 2. Pendataan mata kuliah secara manual. 3. Pengisian Kartu Rencana Studi (KRS) dan kartu Perubahan Rencana Studi (KPRS) melalui scanner OMR. 4. Penerbitan Kartu Studi Mahasiswa (KSM). 5. Pengolahan nilai akademik mahasiswa. 6. Penerbitan Kartu Hasil Studi (KHS). 7. Penerbitan Daftar Kumpulan Nilai (DKN). 8. Penerbitan Transkrip Nilai Akhir (TNA). Dari hasil pengamatan dan analisa di Simak, ditemukan beberapa tabel yang digunakan (lihat Tabel III-1). Tabel III-1 Daftar tabel di Simak
No
Nama File
Jumlah Deskripsi kolom 3 Data master Dosen 2 Data master Mahasiswa 6 Data master Matakuliah 18 Data isian KRS mahasiswa per semester
1
Dosen_D3.dbf
2
Mhs_XXX.dbf
3
MK_XXX.dbf
4
KRS_XXX.dbf
5
KHS_XXX.dbf
121
6
Transkrip_XXX.dbf
707
Data KHS mahasiswa per semester Data kumpulan nilai mahasiswa keseluruhan semester
34
Keterangan Berisikan informasi mengenai data dosen Berisikan informasi mengenai data mahasiswa Berisikan data mengenai matakuliah Berisikan matakuliah apa saja yang diambil mahasiswa dalam satu semester Berisikan nilai-nilai matakuliah setiap mahasiswa per semester Berisikan kumpulan nilai mahasiswa selama ia studi di jurusan itu.
Beberapa tabel yang ada di Simak dibuat per semester, data yang diperoleh per semester tersebut disimpan dalam satu file, sehingga aksesnya pun dilakukan terhadap file di semester tersebut saja. Di dalam penyebutan nama tabel diberikan simbol XXX, hal ini dikarenakan setiap data dibagi menjadi per semester dan per program studi. Di dalam Tabel III-1 itu pun terlihat ada beberapa tabel yang memiliki kolom yang dianggap telah melampaui batas jumlah kolom sebuah tabel. Kalau mengacu ke kaidah basisdata relasional, maka jumlah kolom yang dipakai seharusnya tidak terlalu banyak. Hal merupakan masalah pertama yang ditemukan di dalam Simak ini. Namun karena ke-fleksibel-annya, Simak ini dapat menyimpan kegiatan akademik dalam cakupan universitas. Untuk lebih melihat struktur data yang lebih lengkap dapat dilihat di Lampiran A.
III.2 Proses Bisnis Terdapat tiga role (peran) yang ada di Simak, yaitu Dosen, Mahasiswa dan Jurusan. Namun di dalam pembuatan data induk hanya Dosen dan Mahasiswa saja yang diimplementasikan menjadi tabel. Ketiga peran tersebut menjalankan kegiatan seperti yang terlihat Gambar III-1.
Gambar III-1 Diagram Fungsional Simak (Proses Bisnis)
35
Keterangan simbol-simbol proses bisnis: Tabel III-2 Simbol -simbol Proses Bisnis
No 1
Simbol
Arti Proses
2
Keputusan
3
Dokumen
Diagram di atas memberikan gambaran proses kegiatan atau proses bisnis secara umum yang ada di Simak. Dari diagram di atas dapat terlihat bahwa kegiatan Simak hanya sedikit namun terlihat banyak, hal ini dikarenakan ada satu tujuan kegiatan namun melewati banyak proses terlebih dahulu. Seperti contoh, Mahasiswa akan melakukan KRS di awal semester. Mereka harus mengisi lembar kertas formulir KRS kemudian jurusan akan men-scan formulir tersebut, kemudian hasil scan akan diolah agar menjadi sebuah file tabel KRS, lalu pengecakan validitas isian formulir. Apabila ada isian formulir yang tidak valid, maka akan diperbaiki secara manual (dengan konfirmasi ke mahasiswa bersangkutan). Setelah itu diterbitkan KSM sebagai tanda mahasiswa mengambil matakuliah yang sesuai dengan apa yang diisi di formulir KRS. Hal inilah yang nantinya akan disederhanakan dan direkayasa ulang sedemikian hingga proses yang dilakukan tidak terlalu banyak namun memiliki kualitas yang lebih baik dari sebelumnya.
III.3 Diagram Konseptual (Diagram ER) Pada proses pembangunan Simak ini tidak disertakan dengan dokumentasi yang berisikan aliran data atau yang disebut dengan Diagram Konseptual. Dengan melakukan pengamatan dan percobaan yang ada di Simak, maka dicoba digambarkan sendiri secara sederhana aliran data tersebut. Secara keseluruhan diagram tidaklah mengikuti kaidah penggambaran diagram konseptual yang sebenarnya, karena tersangkut basisdata yang tidak valid.
36
Mhs_XXX
Dosen_D3
MK_XXX
Prasyarat
KRS_XXX
KHS_XXX
TRANSKRIP_XXX
Gambar III-2 Diagram Konseptual Simak (Diagram ER)
III.4 Diagram Fisik Berikut adalah Diagram Fisik yang dapat digambarkan dari sistem basisdata yang terdapat sistem lama:
FK12
FK16 FK16
Gambar III-3 Diagram Fisik Simak
37
Keterangan: 1. Titik tiga kali titik (. . .) yang ada di tabel TRANSKRIP_XXX, KRS_XXX dan KHS_XXX menunjukkan bahwa ada penomoran kolom yang berurutan, sehingga tidak ditulis secara keseluruhan mengingat banyaknya kolom yang ada di tabel tersebut. 2. Relasi yang ada di atas belum sepenuhnya menunjukkan relasi yang benar, tetapi paling tidak mendekati, hal ini disebabkan karena kaidah-kaidah basisdata relasional yang tidak diterapkan di sistem lama ini dimana pemberian kolom-kolom yang tidak tepat dan terkesan asal-asalan. Diagram fisik adalah diagram yang menggambarkan bentuk fisik dari tabel dengan relasinya beserta kolom-kolom yang dimiliki masing-masing tabel. Namun basisdata yang ada di sistem lama sulit sekali untuk digambarkan bagaimana relasi yang benar terhadap antar tabel (dokumen rancangan PL tidak ada). Kolom NIM dan NAMA mahasiswa muncul di beberapa tabel, sehingga akan sangat memungkinkan terjadinya redundansi data. serta jumlah kolom yang melebihi batas normal (mencapai 707 kolom). Beberapa DBMS seperti Microsoft Access membatasi jumlah kolom sebanyak 255 kolom. Kebergantungan fungsi yang terdapat pada skema di atas adalah :
1. Pada Skema MHS_XXX MHS_XXX={NIM, NAMA} F = { NIM Æ NAMA }
2. Pada Skema DOSEN_D3 DOSEN_D3={NIP, NAMA, JURUSAN} F = { NIP Æ NAMA, JURUSAN }
3. Pada Skema MK_XXX MK_XXX={KODE_KOM, KODE_MK, NAMA_MK, SKS, SEMESTER, PRASYARAT} F = { KODE_KOM Æ KODE_MK, NAMA_MKSKS, SEMESTER, PRASYARAT}
38
III.5 Pengolahan Basisdata Secara sederhana pengolahan basisdata di dalam program berjalan memenuhi hampir semua kebutuhan akademik, namun seiring berjalannya perkuliahan dan semakin banyaknya mahasiswa menjadikan data semakin banyak pula, sehingga pengelolaan data menjadi suatu hal yang penting. Salah satu contoh bagaimana program Simak dalam mengolah basisdata diberikan di Gambar III-4.
Gambar III-4 Pengolahan basisdata Simak
Setelah mahasiswa mengisi formulir KRS, maka jurusan akan men-scan formulir tersebut dan didapatkan file data hasil scan (*.dat). Hasil scan tersebut yang akan diolah dengan memasukkan data hasil scan ke file tabel (*.dbf; file ini telah dibuat sebelumnya). Data inilah yang akan diproses selanjutnya kemudian akan menjadi data KHS dan Transkrip.
III.6 Deteksi Smells Basisdata Peningkatan fungsionalitas dari Simak ini didasarkan dengan kualitas basisdata yang dimilikinya. Berdasarkan struktur data dan informasi yang terkandung di tabel-tabelnya, maka akan dilihat sejauh mana “smells” yang terkandung di dalam Simak sehingga menentukan kualitas basisdata yang dimilikinya.
39
III.6.1 Multipurpose Column Berdasarkan struktur data Simak yang ada di Lampiran A serta diagram fisik yang terlihat di Gambar III-3, tidak terlihat adanya nilai yang ada di kolom tertentu yang memiliki tujuan lebih dari satu. III.6.2 Multipurpose Table Berdasarkan struktur data Simak yang ada di Lampiran A serta diagram fisik yang terlihat di Gambar III-3, tidak terlihat adanya tabel yang memiliki tujuan lebih dari satu. III.6.3 Data Redundan Berdasarkan struktur data Simak yang ada di Lampiran A serta diagram fisik yang terlihat di Gambar III-3, maka akan memungkinkan sekali terjadinya data yang redundan. Beberapa kolom yang berisikan informasi dari tabel tertentu muncul di tabel yang lain seperti yang digambarkan di Tabel III-3. Tabel III-3 Deteksi data redundan No 1
Kolom/Informasi NAMA
2
NAMA, NAMAPA NAMA_MK NMKX
3
Tabel Mhs_XXX, TRANSKRIP_XXX, KHS_XXX Dosen_D3, KHS_XXX MK_XXX KHS_XXX
Frekuensi 3
2 2
Redundansi data akan memungkinkan sekali terjadi pada Kolom NAMA, karena kolom NAMA ini muncul pada beberapa tabel. Pada Simak ini terlihat kolom NAMA memiliki arti yang ganda, yaitu NAMA dapat berarti NAMA mahasiswa, atau NAMA dapat berarti NAMA dosen, sehingga kolom NAMA ini sebaiknya direstrukturisasi sehingga penamaan dan kebergantungan fungsionalnya terlihat jelas sehingga redundansi data dapat diminimalisasi. Hal ini juga berlaku untuk kolom NAMA_MK dan NMKX yang notabene memiliki kesamaan nilai atau kesamaan makna. III.6.4 Tabel yang memiliki terlalu banyak kolom Tabel yang memiliki terlalu banyak kolom akan memberikan kesulitan dalam akses data melalui program serta kecepatan akses ke data tersebut. Smell ini juga
40
memungkinkan sebuah kolom dapat bernilai kosong (nullable). Berdasarkan Tabel III-1 ada beberapa tabel yang dianggap memiliki kolom yang terlalu banyak, yaitu seperti yang terlihat di Tabel III-4 di bawah ini. Tabel III-4 Deteksi banyak kolom
No Nama File Jumlah kolom 1 KRS_XXX.dbf 18 2 KHS_XXX.dbf 121 3 Transkrip_XXX.dbf 707 Dari tabel III-4 di atas terlihat ada 2 tabel yang memiliki jumlah kolom yang terlalu banyak. Walaupun sebagian besar DBMS tidak memberikan batas maksimum jumlah kolom dalam satu tabel, namun ada pertimbangan lain yan menyebabkan satu tabel dikatakan memiliki terlalu bayak kolom antara lain: 1. Adanya kemungkinan terjadi nilai kosong dalam satu kolom. 2. Adanya relasi lebih dari satu antara dua entitas yang sama yang menyebabkan kemungkinan data yang redundan. Hal ini akan menyebabkan penurunan kualitas basisdata Simak. Selain itu pengaksesan data oleh program akan menjadi lambat dan cenderung memiliki tingkat kesalahan yang lebih tinggi. Dengan demikian tabel yang terlalu memiliki banyak kolom ini akan direstrukturisasi, kolom-kolom yang tidak memiliki kebergantungan fungsional dipindahkan ke tabel yang lebih tepat, atau lebih tepatnya tabel ini akan didekomposisi dengan mengacu ke kaidah BCNF. III.6.5 Tabel yang memiliki terlalu banyak baris Di dalam Simak ada beberapa tabel yang memungkinkan memiliki baris yang semakin bertambah seiring banyaknya mahasiswa dan kegiatan akademik masingmasing mahasiswa. Untuk melihat seberapa besar penambahan baris dalam satu tabel dapat diprediksi seperti yang terlihat di Tabel III-5 di bawah ini. Tabel III-5 Deteksi banyak baris
No 1 2 3 4 5 6
Nama File Dosen_D3.dbf Mhs_XXX.dbf MK_XXX.dbf KRS_XXX.dbf KHS_XXX.dbf Transkrip_XXX.dbf
Jumlah kolom 3 2 6 18 121 707
Prediksi Penambahan ± 9 orang / 2 tahun ± 80 orang / tahun Tidak tentu ± 80 baris / semester ± 80 baris / semester ± 80 baris / tahun
41
Kemungkinan terjadi banyak baris Tidak Tidak Tidak Ya Ya Ya
Dari Tabel III-5 di atas terlihat ada beberapa tabel yang memungkinkan akan memiliki baris yang terlalu banyak. Memang di Simak sudah diantisipasi dengan mem-partisi
tabel menjadi beberapa file, seperti yang terlihat pada tabel
KRS_XXX dan KHS_XXX. Tabel ini akan berisikan baris yang sangat banyak sekali dalam kurun waktu yang sangat singkat, apalagi nanti setelah tabel-tabel itu restrukturisasi, maka akan sangat memungkinkan sekali terjadi lebih dari 2000 baris per semester, dengan asumsi ada 3 jurusan masing-masing 3 angkatan serta 40 mahasiswa per angkatan dengan masing-masing mahasiswa mengambil 6 matakuliah. Partisi ini juga akan dilakukan pada saat implementasi basisdata yang baru, namun dengan teknik-teknik yang lebih baik yang mudah diakses oleh program. III.6.6 Kolom “Smart” Berdasarkan struktur data Simak yang ada di Lampiran A serta diagram fisik yang terlihat di Gambar III-3, tidak terlihat adanya nilai yang ada di kolom yang menyimpan informasi lebih dari satu kegunaan. III.6.7 Takut akan perubahan Berdasarkan struktur data Simak dan fungsionalitas yang ada di dalamnya, maka akan terjadi kesulitan integritasi data jika ada rencana penambahan fungsionalitas tertentu. Struktur data akan semakin menjauhi kaidah relasional basisdata.
III.7 Asumsi dan Batasan Simak Seiring dengan meningkatnya fungsionalitas dari perangkat lunak, maka sistem akan di-reengineering (rekayasa ulang). Namun dari sisi basisdata, informasi yang telah ada sebelumnya tetap harus dijaga. Dokumentasi yang tidak ada dan skema lojik basisdata yang tidak jelas mengakibatkan sistem sulit untuk ditelusuri proses modelnya. Adapun asumsi dan batasan yang terdapat di basisdata Simak yaitu: 1. Seluruh tabel yang harus dibuat terlebih dahulu sebelum melakukan pengisian data akademik. 2. Tabel Mhs_XXX dibuat dan di-split berdasarkan masing-masing jurusan. Jika nantinya akan jurusan akan bertambah, maka tabel Mhs_XXX pun akan ditambah pula. 42
3. Tabel MK_XXX dibuat dan di-split berdasarkan masing-masing jurusan. Jika nantinya akan jurusan akan bertambah, maka tabel MK_XXX pun akan ditambah pula. 4. Tabel KRS_XXX dibuat dan di-split berdasarkan masing-masing jurusan dan tahun akademik pengambilan KRS. Jika nantinya akan jurusan akan bertambah dna atau memasuki tahun akademik berikutnya, maka tabel KRS_XXX pun akan ditambah pula. 5. Tabel KHS_XXX dibuat dan di-split berdasarkan masing-masing jurusan dan tahun akademik penerbitan KHS. Jika nantinya akan jurusan akan bertambah dna atau memasuki tahun akademik berikutnya, maka tabel KHS_XXX pun akan ditambah pula. 6. Tabel TRANSKRIP_XXX dibuat dan di-split berdasarkan masing-masing jurusan. Jika nantinya akan jurusan akan bertambah, maka tabel TRANSKRIP _XXX pun akan ditambah pula.
III.8 Kebutuhan Fungsional Sistem Baru Adapun spesifikasi kebutuhan fungsional di sistem baru adalah sebagai berikut: 1. Sistem dapat melayani mahasiswa melakukan pengisian KRS atau KPRS per semester secara online (FCS01). 2. Sistem dapat melayani dosen PA melakukan persetujuan isian KRS dan KPRS secara online (FCS02). 3. Sistem dapat melayani dosen memasukkan nilai mahasiswa per kelas per semester secara online (FCS03). 4. Sistem dapat mengolah nilai sesuai dengan aturan perkuliahan (FCS04). 5. Sistem dapat menerbitkan KSM, KHS, DNA dan TNA (FCS05). 6. Sistem dapat menerbitkan nilai mahasiswa per matakuliah per semester (FCS06). 7. Sistem dapat melayani mahasiswa mengambil beberapa matakuliah dari jurusan lain (FCS07).
III.9 Kebutuhan Non Fungsional Sistem Baru Adapun spesifikasi kebutuhan non fungsional di sistem baru adalah sebagai berikut:
43
1. Sistem yang berbasiskan web (web based) (FCS07). 2. Tidak menggunakan scanner OMR lagi (FCS08). 3. Mahasiswa mengisi KRS dan KPRS langsung secara online (FCS09). 4. Sistem dapat digunakan di jaringan lokal saja (intranet), namun ada kemungkinan akan menjadi jaringan internet (FCS10). 5. Kemungkinan sistem baru ini akan dikembangkan ke tingkat universitas (FCS11). 6. Data yang ada di sistem lama dapat dikonversi dan dipindahkan ke sistem baru semaksimal mungkin dengan menjaga informasi yang ada di dalamnya (FCS12).
III.10 Evaluasi Sistem Basisdata Berdasarkan analisa basisdata Simak di atas, ditemukan beberapa kategori “database smell” yang dapat dikategorikan sebagai “bad smells”. Tabel III-6 di bawah ini merupakan hasil evaluasi secara menyeluruh terhadap analisa basisdata simak. Tabel III-6 Evaluasi basisdata keseluruhan
No Kategori Smell 1 Multipurpose column
Status Tidak ditemukan Tidak ditemukan Ditemukan
Deskripsi -
2
Multipurpose table
3
Data Redundan
4
Tabel yang memiliki terlalu banyak kolom
Ditemukan
5
Tabel yang memiliki terlalu banyak kolom
Ditemukan
Terdapat 3 tabel yang diidentifikasi akan memiliki terlalu banyak baris
6
Kolom “Smart”
-
7
Takut akan perubahan
Tidak ditemukan Tidak ditemukan
44
Terdapat 3 kolom yang diidentifikasi akan terjadi data redundan Terdapat 2 tabel yang diidentifikasi memiliki banyak kolom
-