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.
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
kolom
Deskripsi Keterangan
1 Dosen_D3.dbf 3 Data master Dosen
Berisikan informasi mengenai data dosen
2 Mhs_XXX.dbf 2 Data master Mahasiswa
Berisikan informasi mengenai data mahasiswa
3 MK_XXX.dbf 6 Data master Matakuliah
Berisikan data mengenai matakuliah
4 KRS_XXX.dbf 18 Data isian KRS mahasiswa per semester
Berisikan matakuliah apa saja yang diambil mahasiswa dalam satu semester
5 KHS_XXX.dbf 121 Data KHS mahasiswa per semester
Berisikan nilai-nilai matakuliah setiap mahasiswa
per semester 6 Transkrip_XXX.dbf 707 Data kumpulan
nilai mahasiswa keseluruhan
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.
Keterangan simbol-simbol proses bisnis:
Tabel III-2 Simbol -simbol Proses Bisnis
No Simbol Arti
1 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.
Mhs_XXX Dosen_D3 MK_XXX
KRS_XXX
KHS_XXX TRANSKRIP_XXX
Prasyarat
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
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}
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.
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 Kolom/Informasi Tabel Frekuensi
1 NAMA Mhs_XXX, TRANSKRIP_XXX, KHS_XXX 3 2 NAMA, NAMAPA Dosen_D3, KHS_XXX 2 3 NAMA_MK NMKX MK_XXX KHS_XXX 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
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 masing-masing 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 Nama File Jumlah
kolom
Prediksi Penambahan
Kemungkinan terjadi banyak baris
1 Dosen_D3.dbf 3 ± 9 orang / 2 tahun Tidak 2 Mhs_XXX.dbf 2 ± 80 orang / tahun Tidak
3 MK_XXX.dbf 6 Tidak tentu Tidak
4 KRS_XXX.dbf 18 ± 80 baris / semester Ya 5 KHS_XXX.dbf 121 ± 80 baris / semester Ya 6 Transkrip_XXX.dbf 707 ± 80 baris / tahun 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.
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:
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 Status Deskripsi
1 Multipurpose column Tidak ditemukan
- 2 Multipurpose table Tidak
ditemukan
-
3 Data Redundan Ditemukan Terdapat 3 kolom yang diidentifikasi akan terjadi data redundan
4 Tabel yang memiliki terlalu banyak kolom
Ditemukan Terdapat 2 tabel yang diidentifikasi memiliki banyak kolom
5 Tabel yang memiliki terlalu banyak kolom
Ditemukan Terdapat 3 tabel yang diidentifikasi akan memiliki terlalu banyak baris
6 Kolom “Smart” Tidak
ditemukan
- 7 Takut akan perubahan Tidak
ditemukan
