JURNAL TEKNIK POMITS Vol. 2, No. 1, (2013) ISSN: 2337-3539 (2301-9271 Print)
1
Rekayasa Ulang SIM Akademik ITS Berdasarkan Karakteristik Pemeliharaan Menggunakan Model Kualitas ISO/IEC 9126 Agus Budi Raharjo, Umi Laili Yuhana, Siti Rochimah Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember (ITS) Jl. Arief Rahman Hakim, Surabaya 60111 Indonesia E-mail:
[email protected] Abstrak—Sistem Informasi Akademik (SIAKAD) pada perguruan tinggi adalah perangkat yang digunakan untuk mendukung kegiatan akademik. Pemeliharaan SIAKAD ITS saat ini belum memiliki pedoman baku. Kekurangan yang ditimbulkan adalah tidak adanya dokumentasi perubahan lengkap dan mekanisme pemeliharaan yang tidak terstruktur. Hal tersebut membuat biaya pemeliharaan tidak dapat didefinisikan dengan jelas. Selain itu, perkembangan teknologi informasi saat ini sudah tidak mendukung spesifikasi lingkungan SIAKAD. Pada penelitian ini studi kasus SIAKAD direkayasa ulang menggunakan pendekatan model kualitas ISO/IEC 9126 berdasarkan karakteristik pemeliharaan. Sistem baru dibangun berdasarkan rekomendasi yang didapatkan pada hasil pengujian sistem lama. Sistem yang dibangun merupakan prototipe modul Formulir Rencana Studi (FRS). Hasil pengujian kualitas menunjukkan perbedaan hasil pada empat subkarakteristik dari lima subkarakteristik yang diuji. Pengujian dilakukan menggunakan matriks yang sama. Sistem baru menghasilkan fungsi dan dokumentasi yang lebih lengkap. Rekayasa ulang sistem lama dapat meminimalisir perbedaan tampilan antarmuka sistem baru. Pendekatan model kualitas pada rekayasa ulang memberikan peningkatan signifikan sesuai karakteristik yang diukur. Kata Kunci—model kualitas, rekayasa ulang, sistem informasi akademik.
I. PENDAHULUAN
S
ISTEM informasi akademik adalah kakas bantu pemeliharaan kegiatan akademik di ITS. Sistem informasi akademik ITS (SIAKAD) memerlukan pemeliharaan berkala agar tetap beroperasi. SIAKAD memiliki dua jenis pengembang dan satu jenis pemelihara. Pengembang pertama adalah Pengembang awal SIAKAD. Pengembang awal dilakukan oleh pihak luar ITS. Pengembang kedua adalah pengembang internal ITS. Pemelihara SIAKAD dilakukan oleh Badan Teknologi dan Sistem Informasi (BTSI) ITS. Pengembang dan pemelihara memiliki arahan kerja yang berbeda dalam mengelola SIAKAD. Pengembang memiliki tugas melakukan perubahan sistem. Pemelihara memiliki tugas melakukan pemeliharaan rutin sistem. Saat ini proses perubahan dan pemeliharaan SIAKAD belum menggunakan standar baku. Hal ini menyebabkan lima kelemahan. Kelemahan pertama adalah dokumentasi perubahan yang tidak
tersimpan. Pengembang pertama SIAKAD tidak memberikan dokumentasi pengembangan dan perubahan SIAKAD secara lengkap. Hal tersebut menyebabkan pengembang internal BTSI mengalami kesulitan untuk mengubah sistem. Pengembang harus menganalisis ulang setiap fungsi yang diubah. Kelemahan kedua adalah rentang waktu pemeliharaan tidak didefinisikan secara rinci. Hal tersebut menyebabkan proses pemeliharaan memerlukan waktu yang tidak teratur. Dampak negatifnya adalah adanya toleransi kelonggaran waktu pemeliharaan. Toleransi kelonggaran waktu pemeliharaan didasarkan atas kondisi kesibukan pemelihara internal ITS. Lamanya waktu pemeliharaan mempengaruhi besarnya biaya yang diperlukan. Kelemahan ketiga adalah proses pemeliharaan yang tidak menggunakan metode baku. Metode yang digunakan oleh BTSI saat ini belum menggunakan metode daur hidup perangkat lunak baku. Hal ini membuat proses pemeliharaan tidak terorganisasi dengan baik. Kelemahan keempat adalah spesifikasi sistem yang belum didefinisikan secara lengkap. Proses pengembangan SIAKAD ITS yang saat ini digunakan dilakukan pada tahun 2004. Kemajuan teknologi informasi menyebabkan ketidaksesuaian spesifikasi SIAKAD dengan teknologi saat ini. Pengembang internal harus menganalisis spesifikasi yang bisa digunakan setiap perubahan. Kelemahan kelima adalah proses pertama pengembangan SIAKAD tidak menggunakan kerangka kerja resmi. Pengembang pertama menggunakan metode pengodean yang tidak sesuai standar. Hal tersebut menyebabkan pengembang internal ITS melakukan perubahan sesuai gaya pengodean pengembang awal. Oleh karena itu perlu dilakukan rekayasa ulang SIAKAD sesuai standar kualitas baku. Hal tersebut agar proses perubahan dan pemeliharaan menjadi lebih efisien [1]. Ada dua sudut pandang yang perlu diperhatikan agar rekayasa ulang SIAKAD memberikan hasil yang efisien. Sudut pandang pertama adalah pihak pengguna sistem. Sistem yang baru harus mudah dipahami oleh pengguna. Rekayasa ulang harus meminimalkan perubahan cara penggunaan sistem saat ini. Sudut pandang kedua adalah pihak BTSI. Sistem yang baru harus memiliki metode pemeliharaan dan perubahan yang lebih baku [2]. Rekayasa ulang yang dilaksanakan pada penelitian ini memiliki tiga langkah utama. Langkah pertama adalah melakukan pengukuran standar kualitas sesuai aspek
JURNAL TEKNIK POMITS Vol. 2, No. 1, (2013) ISSN: 2337-3539 (2301-9271 Print)
Proses identifikasi perubahan
Usulan perubahan
Sistem baru
Proses evolusi perangkat lunak Gambar 1. Gambaran proses terjadinya evolusi
tertentu. Langkah kedua adalah mengambil sistem lama yang masih sesuai digunakan kembali. Langkah ketiga adalah pembangunan sistem baru sesuai dengan masukan hasil pengukuran standar kualitas sistem lama. Hasil rekayasa ulang adalah rekomendasi kualitas sesuai standar dan SIAKAD baru. Keluaran yang dihasilkan diharapkan dapat memperbaiki aspek pemeliharaan (maintainability) pada SIAKAD ITS. Perbaikan pada aspek pemeliharaan dapat mempermudah proses pemeliharaan dan mengurangi biaya pemeliharaan. II. TINJAUAN PUSTAKA Pada penelitian ini dilakukan pendekatan proses rekayasa ulang berdasarkan teori evolusi perangkat lunak dalam membangun prototipe sistem baru. Untuk menjamin kualitas sistem baru yang lebih baik dari sistem sebelumnya, kedua sistem diukur menggunakan model kualitas ISO/IEC 9126 dengan sudut pandang pengukuran karakteristik pemeliharaan. Pada bab ini dijelaskan teori-teori penunjang yang berkaitan dengan proses rekayasa perangkat lunak. A. Evolusi Perangkat Lunak Evolusi perangkat lunak adalah salah satu metode pengembangan perangkat lunak. Metode ini dilaksanakan ketika ada perubahan. Perubahan perangkat lunak terjadi karena mengalami tiga penyebab. Penyebab pertama adalah pengoreksian kesalahan yang ditemukan pada fase operasional. Penyebab kedua adalah penyesuaian perangkat lunak terhadap perubahan lingkungan sistem. Lingkungan sistem yang berubah dapat berupa perangkat keras dan perangkat lunak. Penyebab ketiga adalah kebutuhan untuk meningkatkan kemampuan atau karakteristik lain. Proses tersebut membentuk siklus terjadinya evolusi perangkat lunak. Siklus terjadinya evolusi perangkat lunak dijelaskan pada Gambar 1. Implementasi evolusi perangkat lunak dapat dilakukan dengan metode tangkas atau pengembangan bertahap. Kelebihan metode tangkas adalah menerapkan penyelesaian masalah yang dapat beroperasi secara cepat. Namun metode ini tidak disertai analisis perubahan baku. Kelemahan dari metode ini adalah terbentuknya analisis, rancangan dan kode yang tidak konsisten. Metode yang kedua adalah pengembangan bertahap. Metode ini menerapkan perubahan yang sesuai dengan analisis perubahan baku, berkala, dan terbagi menjadi beberapa modul perubahan. Salah satu bentuk metode pengembangan bertahap adalah pemeliharaan
2
perangkat lunak. Pemeliharaan perangkat lunak adalah proses perubahan sistem yang dilakukan setelah sistem dikirim kepada klien. Perubahan diimplementasikan dengan memodifikasi atau menambahkan sistem yang ada. Rekayasa ulang adalah implementasi pemeliharaan perangkat lunak pada kasus khusus. Kasus khusus adalah proses pemeliharaan pada sistem yang sulit dipahami. Rekayasa ulang digunakan untuk meningkatkan aspek pemeliharaan perangkat lunak. Rekayasa ulang tidak mengubah fungsionalitas suatu sistem, namun membuat perubahan besar pada proses pemeliharaan. Ada dua kelebihan rekayasa ulang sistem dibandingkan dengan penggantian sistem baru. Kelebihan pertama adalah meminimalisir risiko yang ditimbulkan pada fase pengembangan awal. Rekayasa ulang mendapatkan warisan komponen perangkat lunak dari sistem lama. Warisan komponen sistem lama mengurangi kesalahan pendefinisian kebutuhan sistem baru. Kelebihan kedua rekayasa ulang yaitu dapat mengurangi biaya pengembangan karena menggunakan sebagian sumber daya yang masih ada. Rekayasa ulang perangkat lunak terdiri atas lima jenis aktivitas, yaitu penerjemahan kode sumber, rekayasa pembalikan, pengembangan struktur program, pengelompokan program untuk mengurangi perulangan fungsi, dan rekayasa ulang data. Meskipun memiliki lima kategori aktivitas, pada proses rekayasa ulang tidak perlu diterapkan semua aktivitas tersebut. Rekayasa ulang perangkat lunak dapat menerapkan aktivitas yang sesuai dengan usulan perubahan [3]. B. Model Kualitas ISO/IEC 9126 ISO/IEC 9126 merupakan model yang digunakan untuk mengevaluasi kualitas perangkat lunak. tujuan utama ISO/IEC 9126 adalah memberikan standar baku dalam proyek pengembangan perangkat lunak. ISO/IEC 9126 terdiri atas empat bagian, yaitu ISO/IEC 9126-1 yang membahas istilah karakteristik kualitas perangkat lunak, ISO/IEC 9126-2 yang membahas matriks eksternal, ISO/IEC 9126-3 yang membahas maktriks internal, dan ISO/IEC 9126-4 yang membahas penggunaan matriks kualitas. Karya tulis ini menggunakan karakteristik pemeliharaan untuk mengukur standar kualitas SIAKAD berdasarkan matriks internal ISO/IEC 9126-3. Karakteristik pemeliharaan ISO/IEC 9126-3 memiliki lima subkarakteristik. Masing-masing subkarakteristik pemeliharaan memiliki bobot yang berbeda. Subkarakteristik pertama adalah matriks analisis. Matriks analisis digunakan untuk memprediksi usaha yang diperlukan pengguna atau pemelihara untuk mendiagnosis kekurangan atau kesalahan perangkat lunak. Aspek pengukuran matriks analisis terdiri atas perekaman aktivitas dan kesiapan fungsi diagnosis. Subkarakteristik kedua adalah matriks perubahan. Matriks perubahan digunakan untuk memprediksi usaha yang diperlukan pengguna atau pemelihara untuk memodifikasi bagian khusus pada perangkat lunak. Aspek pengukuran matriks perubahan terdiri atas kemampuan untuk merekam perubahan. Subkarakteristik ketiga adalah matriks stabilitas. Matriks stabilitas digunakan untuk memprediksi tingkat kestabilan perangkat lunak setelah dilakukan modifikasi. Aspek pengukuran matriks stabilitas terdiri atas dampak perubahan dan lokalisasi dampak perubahan. Subkarakteristik
JURNAL TEKNIK POMITS Vol. 2, No. 1, (2013) ISSN: 2337-3539 (2301-9271 Print)
3
START
PHP
HTML
javascript
CSS
dokumentasi
Kel engkapan lain
SIAKAD ITS aktif
CSS
disesuaikan
javascript
Kode sumber aplikasi
Rekayasa ulang data
SQL Server 2000 Kode basi s data
ASP .NET
REKAYASA ULANG Penerjemahan kode sumber
Kode sumber aplikasi
gambar
digunakan kembali digunakan kembali digunakan kembali
SQL Server 2008 Kode basi s data
Pengelompokan program
dokumentasi
Rekayasa pembalikan
gambar
Kel engkapan lain
Peningkatan struktur program
Prototipe SIAKAD rekomendasi
PENGUKURAN KUALITAS KARAKTERISTIK PEMELIHARAAN ISO/IEC 9126
diukur
Model kualitas ISO/IEC 9126 karakteristik pemeliharaan (analisis, perubahan, stabilitas, pengujian, kepatuhan pemeliharaan)
menganalisis model kualitas merancang skenario mengukur kualitas
matriks kualitas
memvalidasi
skenario pengukuran
hasil pengukuran
STOP Gambar 2. Proses rekayasa ulang SIM Akademik ITS berdasarkan karakteristik pemeliharaan ISO/IEC 9126
keempat adalah matriks pengujian. Matriks pengujian digunakan untuk memprediksi jumlah fungsi pengujian otomatis yang dirancang dan diimplementasikan pada produk. Aspek pengukuran matriks pengujian terdiri atas kelengkapan fungsi pengujian otomatis yang terpasang, kemampuan pengujian otomatis, dan pengamatan perkembangan pengujian. Subkarakteristik kelima adalah matriks pemenuhan aspek pemeliharaan. Matriks pemenuhan aspek pemeliharaan digunakan untuk mengukur kemampuan perangkat lunak memenuhi aturan dan pedoman sesuai aspek pemeliharaan. Matriks ini mengukur semua aspek pemeliharaan perangkat lunak yang ada pada organisasi atau aturan yang didefinisikan pada awal pengembangan [4]. C. Kerangka Kerja Entitas ADO.NET Kerangka kerja entitas adalah kakas pemetaan relasi objek yang menghubungkan kode sumber perangkat lunak dengan basis data. Kerangka kerja entitas menghilangkan kebutuhan untuk menulis kode yang digunakan untuk mengakses basis data. Kerangka kerja entitas ADO.NET adalah pustaka untuk pemrograman berbasis .NET yang direpresentasikan dalam bentuk mesin pemetaan middleware. Middleware dapat meningkatkan faktor keluwesan, keluasan, pemeliharaan, dan kemampuan penggunaan kembali pada sistem terdistribusi [5]. ADO.NET merupakan kelas berorientasi objek yang dapat berinteraksi dengan sumber data. ADO.NET memanipulasi basis data dengan cara mengubahnya menjadi XML. Kerangka kerja entitas ADO.NET bekerja sama dengan Language Integrated Query (LINQ) menciptakan kode
pengaksesan basis data yang dapat mengurangi perbedaan pembuatan kode sistem dan kode data. Ada empat kelemahan penggunaan metode pengaksesan basis data tradisional dibandingkan dengan penggunaan ADO.NET dan LINQ. Kelemahan pertama adalah potensi kesalahan karena normalisasi relasi tabel pada kode SQL. Kelemahan kedua adalah program harus mendefinisikan koneksi basis data setiap menjalankan perintah SQL. Kelemahan ketiga adalah kesalahan nama kolom dan tabel baru terdeteksi ketika program dijalankan. Kelemahan keempat adalah kesalahan pada kode SQL baru diketahui ketika program dijalankan. Dengan menggunakan ADO.NET dan LINQ, panjang kode pengaksesan basis data dapat diringkas. Selain itu, pengecekan kode dapat dilakukan oleh kompilator C#. Dalam karya tulis ini, ADO.NET digunakan karena mempermudah faktor pemeliharaan perangkat lunak [6]. III. REKAYASA ULANG SISTEM Ada dua aktivitas utama rekayasa ulang sistem menggunakan pengukuran model kualitas ISO/IEC 9126. Tahap pertama adalah proses rekayasa ulang kerangka sistem untuk mendapatkan informasi sistem lama. Pada tahap ini data sistem lama akan dikelompokkan menjadi tiga, yaitu data yang dapat langsung digunakan kembali, data yang perlu direkayasa, dan data yang tidak dapat digunakan pada sistem baru. Data yang dapat digunakan kembali meliputi gambar, kode sumber CSS, dan Javascript. Data yang harus direkayasa agar dapat digunakan kembali adalah kode basis data. Data yang tidak
JURNAL TEKNIK POMITS Vol. 2, No. 1, (2013) ISSN: 2337-3539 (2301-9271 Print)
mengisi FRS mengatur periode menyetujui FRS
mengatur jadwal semester
menambah kelas
mengatur komponen penilaian
mengisi nilai
Gambar 3. Alur proses bisnis SIAKAD
dapat digunakan kembali adalah kode sumber PHP dan HTML. Tahap rekayasa ulang juga menjadi tahap penggalian kebutuhan pada pengembangan sistem baru [7]. Rekayasa ulang yang dilakukan pada sistem terdiri atas dua aktivitas, yaitu rekayasa pembalikan dan rekayasa ulang data. Rekayasa pembalikan dilakukan pada basis data untuk mendapatkan struktur data. Proses tersebut dilakukan secara otomatis menggunakan kakas bantu Power Designer. Keluaran diolah sesuai dengan sistem baru dan disimpan ke dalam dokumen perancangan. Rekayasa ulang data dilakukan dengan memindahkan isi basis data yang menggunakan SQL Server 2000 ke dalam SQL Server 2008. Proses tersebut dilakukan semi otomatis karena tidak semua data dipindahkan. Data yang dipindahkan hanya data utama yang diperlukan pada modul FRS Online. Tahap kedua adalah pengukuran matriks kualitas berdasarkan karakteristik pemeliharaan ISO/IEC 9126. Proses ini meliputi analisis model kualitas yang menghasilkan matriks kualitas, perancangan skenario, dan pengukuran kualitas. Matriks yang dibuat disesuaikan dengan jumlah subkarakteristik pada karakteristik pemeliharaan. Skenario pengukuran disesuaikan dengan kondisi sistem lama. Hasil akhir tahap dua adalah rekomendasi pada sistem baru. Matriks kualitas dijelaskan sebagai berikut. 1. Matriks Analisis Matriks analisis internal terdiri atas pengukuran rekaman aktivitas dan kelengkapan fungsi diagnosis. Tujuan dari matriks ini adalah mengetahui besarnya usaha untuk mendiagnosis penyebab kesalahan atau mengidentifikasi bagian yang harus dimodifikasi pada sistem. Bobot matriks analisis internal termasuk kategori tinggi. Komponen penilaian matriks ini terdiri atas pengukuran rekaman aktivitas dan pengukuran kelengkapan fungsi diagnosis. 2. Matriks Perubahan Matriks perubahan internal terdiri atas kelengkapan rekaman perubahan sistem. Kelengkapan dapat berupa dokumen atau baris komentar pada kode sumber program. Tujuan dari matriks ini adalah mengetahui besarnya usaha
4
narasumber untuk mengimplementasikan modifikasi yang spesifik pada sistem. Bobot matriks perubahan termasuk ke dalam kategori sedang. Komponen penilaian matriks ini terdiri atas pengukuran kelengkapan rekaman perubahan sistem. 3. Matriks Stabilitas Matriks stabilitas internal terdiri atas pengukuran dampak perubahan dan lokalisasi dampak perubahan. Tujuan dari matriks ini adalah mengetahui besarnya tingkat kestabilan sistem setelah dilakukan perubahan. Matriks ini juga mengukur tingkat ketergantungan bagian sistem terhadap sistem lain. Bobot matriks stabilitas termasuk kategori rendah. Komponen penilaian matriks ini terdiri atas pengukuran dampak perubahan dan pengukuran tingkat ketergantungan dampak modifikasi. 4. Matriks Pengujian Matriks pengujian internal terdiri atas kelengkapan fungsi pengujian otomatis yang terpasang, kemampuan pengujian otonom, dan kemampuan pengamatan perkembangan pengujian. Tujuan dari matriks ini adalah memprediksi jumlah fungsi pengujian bantuan yang dirancang dan diimplementasikan pada sistem. Bobot matriks pengujian termasuk ke dalam kategori sedang. Komponen penilaian matriks ini terdiri atas pengukuran kelengkapan fungsi pengujian otomatis yang terpasang, pengukuran kemampuan pengujian otonom, dan pengukuran kemampuan pengamatan perkembangan pengujian. 5. Matriks Kepatuhan Pemeliharaan Matriks kepatuhan pemeliharaan internal hanya terdiri atas satu pengukuran, yaitu matriks kepatuhan pemeliharaan. Kepatuhan pemeliharaan mencakup semua aspek pemeliharaan dalam sistem. Tujuan dari matriks ini adalah mengukur kemampuan sistem dalam memenuhi aspek pemeliharaan seperti standardisasi dan aturan organisasi yang berkaitan dengan pemeliharaan. Bobot matriks stabilitas termasuk ke dalam kategori tinggi. Komponen penilaian matriks ini terdiri atas pengukuran kepatuhan pemeliharaan. Tahap pertama dan kedua dapat dikerjakan secara bersamaan. Gambar 2 menjelaskan metode penelitian yang berisi dua aktivitas utama tersebut. Setelah mendapatkan keluaran dari masing-masing tahap, langkah selanjutnya adalah membangun sistem baru sesuai rekomendasi standar kualitas dan menggunakan sumber daya sistem lama yang telah dikelompokkan. Rekomendasi pengukuran didapatkan dari hasil analisis dan temuan pada saat peninjauan. Rekayasa ulang SIAKAD dilakukan pada kerangka sistem hasil rekayasa ulang pada tahap satu. Secara umum gambaran alur aktivitas yang terjadi pada SIAKAD dapat dilihat pada Gambar 3. Administrator akademik pusat ITS pada awal semester menambahkan periode semester. Selanjutnya administrator menentukan jadwal kegiatan studi selama satu semester tersebut. Jadwal tersebut digunakan untuk menjalankan proses bisnis akademik. Pada tahap selanjutnya proses bisnis berada pada ranah program studi. Pada ranah ini pihak akademik jurusan memiliki hak untuk menambahkan kelas baru. Kelas dibuka berdasarkan mata kuliah yang telah ditetapkan sesuai kurikulum terbaru. Setelah kelas ditambahkan, maka status kelas secara otomatis menjadi ditawarkan kepada mahasiswa.
JURNAL TEKNIK POMITS Vol. 2, No. 1, (2013) ISSN: 2337-3539 (2301-9271 Print) Tabel 1. Peningkatan hasil pengujian karakteristik pemeliharaan ISO/IEC 9126-3
5
5. Mengisi Nilai Kasus penggunaan ini digunakan untuk mengisi nilai kelas. Pengisian dapat dilakukan selama satu semester. Pengisian nilai terdiri atas pengisian standar nilai dan pengisian nilai mahasiswa. Pengisian dapat dilakukan pada form di SIAKAD maupun mengunggah dokumen berekstensi xls.
subkarakteristik
hasil sistem lama
hasil sistem baru
Analisis
1,64
2,22
perubahan
0,83
0,83
Stabilitas
0,542
0,83
Pengujian
tidak didefinisikan
2
IV. HASIL DAN DISKUSI
kepatuhan pemeliharaan
2,25
3
Pada tahap pengujian dilakukan pengukuran sistem lama dan sistem baru menggunakan matriks yang telah dibuat. Pengujian dilakukan dengan mengukur SIAKAD baru dan dibandingkan dengan duplikat SIAKAD yang saat ini digunakan di ITS. Bentuk perbandingan ditampilkan dalam bentuk perbedaan perubahan. Perbedaan tersebut tidak bisa langsung dibandingkan karena sistem lama dan sistem baru dibangun menggunakan sudut pandang yang berbeda. Sistem lama merupakan gabungan sudut pandang semua modul dan memiliki kompleksitas yang lebih tinggi dibandingkan sistem baru. Meskipun demikian, sistem baru dapat menunjukkan hasil yang lebih baik dengan melakukan optimasi berdasarkan sudut pandang pemeliharaan. Pada subkarakteristik analisis, fokus penelitian adalah normalisasi tabel sebagai representasi rekaman aktivitas dan penambahan fungsi diagnosis beserta kode standarnya. Sistem lama tidak memiliki fungsi diagnosis yang lengkap disertai kode diagnosisnya. Pada sistem baru dilakukan pemasangan fungsi diagnosis disertai kode standar agar pengguna dapat mengetahui kesalahan spesifik yang muncul dari hasil diagnosis. Selain itu, hal tersebut memudahkan pemelihara untuk mengidentifikasi fungsi yang rusak berdasarkan frekuensi kemunculan kesalahan terkait fungsi tersebut. Pada subkarakteristik perubahan tidak dilakukan peningkatan antara sistem lama dan sistem baru karena fokus pada subkarakteristik ini adalah perilaku perubahan yang dilakukan pengembang atau pemelihara. Pembangunan sistem baru tidak memberikan dampak aktivitas perubahan namun memudahkan aktivitas perubahan yang dilakukan. Pada subkarakteristik stabilitas, fokus penelitian adalah perbaikan kemampuan pendeteksian dampak negatif yang ditimbulkan karena adanya perubahan. Perbaikan ini dilakukan dengan menyediakan fasilitas identifikasi dampak negatif seawal mungkin agar tidak terjadi kesalahan ketika sistem dijalankan. Pendeteksian dampak negatif pada basis data banyak dibantu dengan penggunaan kerangka kerja entitas ADO.NET sehingga sistem dapat memberitahu kemungkinan hasil di luar kewajaran yang akan ditampilkan. Contoh kemungkinan hasil di luar kewajaran adalah munculnya nilai null dan pengaksesan satu rekaman spesifik namun berpotensi memiliki keluaran yang lebih dari satu. Pada subkarakteristik pengujian, fokus penelitian adalah menyediakan fasilitas pengujian pada beberapa kasus penggunaan untuk memastikan sistem berjalan dengan benar. Pada subkarakteristik kepatuhan pemeliharaan, fokus penelitian adalah melengkapi dokumen perancangan sistem. Dokumen tersebut dibuat sesuai modul FRS Online. Hasil akhir pengukuran kualitas didapatkan dari hasil perkalian skor matriks dengan bobot matriks. Skor matriks didapatkan dari pengukuran sistem sesuai masing-masing
Mahasiswa mengisi FRS dengan cara mengambil kelas sesuai sistem kredit semester (sks) yang dimiliki. Mahasiswa wajib mengikuti kelas yang diambil dalam satu semester. Setelah pengisian FRS selesai, mahasiswa menghadap ke dosen wali dan memohon persetujuan FRS. Ketika FRS sudah disetujui, mahasiswa menjadi peserta aktif pada kelas tersebut. Pada saat kegiatan akademik berjalan, dosen pengajar dapat mengatur komponen penilaian kelas. Pada akhir semester, dosen pengajar mengisi nilai mahasiswa dan kegiatan akademik berakhir ketika dosen menyimpan nilai mahasiswa. Penelitian ini memiliki lima kasus penggunaan utama. Kasus penggunaan diperoleh dari hasil analisis proses bisnis SIAKAD. Aktor yang disediakan pada prototipe SIAKAD baru terdiri atas mahasiswa, dosen, ketua jurusan, dan administrator akademik. Deskripsi masing-masing kasus penggunaan dijelaskan sebagai berikut. 1. Mengatur Periode Kasus penggunaan ini digunakan untuk mengatur jadwal periode perkuliahan. Jadwal periode perkuliahan meliputi pengambilan kelas, perubahan kelas yang diambil, dan pembatalan kelas. Aktivitas ini dilakukan pada awal semester. 2. Menambah Kelas Kasus penggunaan ini digunakan untuk menambah kelas baru pada awal semester. Aktivitas ini dilakukan pada saat awal semester hingga masa pengambilan kelas selesai. Data utama kelas terdiri atas mata kuliah, pengajar, dan jadwal sesuai kurikulum. Pengajar yang bisa mengajar pada kelas tersebut bisa berjumlah lebih dari satu orang. Data mata kuliah dan pengajar diambil dari data jurusan. Perubahan yang dilakukan pada proses penyuntingan dapat mengakibatkan perubahan pada kasus penggunaan mengisi FRS. 3. Mengisi FRS Kasus penggunaan ini digunakan untuk mengisi FRS dalam satu semester. Pengisian dilakukan dengan mengambil kelas yang ditawarkan. Pengambilan kelas dipengaruhi oleh mata kuliah prasyarat, batas pengambilan sks, dan jenjang prioritas kelas. Aktivitas ini dilakukan pada awal semester hingga batas selesai pengambilan kelas. 4. Menyetujui FRS Kasus penggunaan ini digunakan agar aktor dapat menyetujui FRS. Aktivitas ini dilakukan pada awal semester hingga semester aktif berjalan. Aktivitas ini berakhir pada batas selesainya masa pembatalan pengambilan kuliah. Pada kasus penggunaan ini aktor juga dapat menjalankan kasus penggunaan mengisi FRS.
JURNAL TEKNIK POMITS Vol. 2, No. 1, (2013) ISSN: 2337-3539 (2301-9271 Print) subkarakteristik. Bobot matriks didapatkan dari formula yang disediakan ISO/IEC 9126-3. Formula yang disediakan ditampilkan dalam tingkat tinggi, menengah, dan rendah. Pada penelitian ini dilakukan pengubahan bobot menjadi nilai absolut. Tingkat tinggi direpresentasikan dalam nilai 3, tingkat menengah direpresentasikan dengan nilai 2, dan tingkat rendah direpresentasikan dengan nilai 1. Tabel 1 menjelaskan perbedaan perubahan yang terjadi setelah dilakukan rekayasa ulang sistem baru. Hasil masing-masing subkarakteristik adalah hasil mandiri dan tidak dapat dijumlahkan. Pada subkarakteristik pengujian, sistem lama tidak dapat didefinisikan nilainya karena sumber referensinya tidak dibuat oleh pengembang awal. Oleh karena itu, pada perbaikan sistem baru dibuat dokumentasi yang lebih lengkap. V. KESIMPULAN/RINGKASAN Kesimpulan yang diperoleh pada penelitian ini adalah sebagai berikut. 1. Analisis aspek pemeliharaan pada SIAKAD dapat dilakukan dengan menggunakan metode pengukuran kualitas berdasarkan karakteristik pemeliharaan model kualitas ISO/IEC 9126. Pengukuran kualitas dimulai dengan menganalisis model kualitas dan menghasilkan matriks kualitas. Matriks kualitas yang telah terbentuk disesuaikan dengan sistem yang diuji dan dilakukan perancangan skenario. Langkah selanjutnya adalah mengukur kualitas sistem berdasarkan skenario yang telah dibuat. Hasil dari proses ini adalah kondisi kualitas sistem saat ini berdasarkan karakteristik pemeliharaan dan rekomendasi yang dapat diimplementasikan pada sistem baru. 2. Untuk membuat prototipe SIAKAD baru yang tetap mengacu pada sistem lama dapat digunakan metode rekayasa ulang. Rekayasa ulang yang dilakukan dapat disesuaikan dengan masalah yang akan diselesaikan agar tidak menimbulkan masalah baru. Pada Tugas Akhir ini, proses rekayasa yang digunakan adalah rekayasa pembalikan kode sumber basis data menjadi rancangan model data dan rekayasa ulang basis data dari versi lama menjadi versi yang lebih baru. Kode sumber aplikasi tidak dilakukan rekayasa ulang karena mengalami perubahan dari jenis pemrograman terstruktur menjadi pemrograman berorientasi objek. Untuk rancangan tampilan dan perlengkapan sistem lain dapat digunakan kembali tanpa direkayasa ulang. Hasil yang didapatkan dari proses rekayasa ulang ini adalah terciptanya prototipe sistem baru yang memiliki tampilan antarmuka mirip dengan sistem lama dan memiliki proses bisnis yang sama sehingga tidak menyulitkan pengguna. 3. Penerapan rekomendasi pengukuran standar kualitas baku pada SIAKAD dapat dilakukan dengan mengukur sistem lama sesuai standar kualitas baku menerapkan hasil rekomendasi tersebut. Pengukuran kualitas menghasilkan keluaran berupa nilai dan rekomendasi pembangunan sistem baru. Rekayasa ulang perangkat lunak berdasarkan pengukuran model kualitas ISO/IEC 9126 memberikan peningkatan signifikan dan dapat menutup kekurangan pada aspek pemeliharaan. Hasil pengukuran menunjukkan empat
6
dari lima subkarakteristik yang digunakan untuk pengujian mengalami perbaikan dan peningkatan kualitas sistem. Ada beberapa pengembangan yang dapat dilakukan lebih lanjut pada penelitian ini. Bentuk pengembangan yang bisa dilakukan dijelaskan sebagai berikut. 1. Model kualitas yang diukur hanya difokuskan pada satu karakteristik saja. Ada potensi sifat saling meniadakan dan saling menguatkan antar karakteristik jika semua model kualitas diterapkan. Oleh karena itu diperlukan pengembangan menyeluruh dan terstruktur untuk menghasilkan produk yang memenuhi semua aspek kualitas. 2. Penelitian ini hanya mengembangkan karakteristik pemeliharaan pada modul FRS. Karakteristik ini memberikan keuntungan pada pengembang dan pemelihara tetapi tidak memberikan manfaat besar pada pengguna sistem. Oleh karena itu diperlukan pengembangan berdasarkan sudut pandang pengguna, pengembang, pemelihara, dan pemilik sistem. 3. Evolusi perangkat lunak pada SIAKAD ITS memiliki potensi pedoman baku yang dapat diimplementasikan pada perguruan tinggi lain. Studi kasus pembuatan pedoman baku SIAKAD dapat dikembangkan menjadi judul topik penelitian yang lebih jauh. UCAPAN TERIMA KASIH Penulis mengucapkan terima kasih kepada Allah SWT, Kedua Orang Tua Penulis, Dosen Pembimbing, dan kerabat TC09, serta teman-teman penulis. DAFTAR PUSTAKA [1] Carlos, V.S. and Rodrigues, R.G. 2012. Web Site Quality Evaluation in Higher Education Institutions. Proceedings of Conference on Enterprise Information Systems – International Conference on Health and Social Care Information Systems and Technologies [Online], pp.273-282. Available from: http://www.sciencedirect.com/science/article/pii/S2212017312004616 [Diakses pada 21 Maret 2013]. [2] Nabil, D., Mosad, A., and Hefny, H.A. 2011. Web-Based Applications Quality Factors:A Survey and a Proposed Conceptual Model. Egyptian Informatics Journal, vol 12, pp. 211-217. [3] Sommerville, I. 2011. Software Engineering. Boston: Addison-Wesley. [4] ISO/IEC JTC1. 2002. Software engineering –Product quality – Part 3: Internal metrics. Japan: ISO/IEC. [5] An, Y., Hu, X., and Song, I. 2008. Round-Trip Engineering for Maintaining Conceptual-Relational Mappings. Advanced Information Systems Engineering, vol 5074, pp.296-311. [6] Adya, A., Blakeley, J.A., Melnik, S., Muralidhar, S., and the ADO.NET Team. 2007. Anatomy of the ADO.NET Entity Framework. Proceedings of the 2007 ACM SIGMOD international conference on Management of data. New York: ACM, pp.877-888. [7] Fahmi A.S. and Choi H. 2007. Software Reverse Engineering to Requirements. Proceedings of International Conference on Convergence Information Technology. Seoul: IEEE Computer Society Press, pp. 21992204.
