Politeknik Telkom Rekayasa Perangkat Lunak
Pemeliharaan Perangkat Lunak 137
Pemeliharaan perfektif mencakup semua perubahan yang berasal dari permintaan pengguna.
Presentase masing-masing kategori pemeliharaan dapat dilihat pada diagram berikut ini:
Gambar 8.1 Presentase Kategori Pemeliharaan
Pigoski menggabungkan pemeliharaan adaptif dan perfektif sebagai enhancement karena kedua tipe ini tidak bersifat korektif, namun merupakan
peningkatan kemampuan perangkat lunak. Namun sebagian organisasi menggunakan istilah pemeliharaan perangkat lunak
jika itu berkaitan dengan perubahan kecil pada sistem perangkat lunak, sedangkan untuk perubahan besar pada sistem perangkat lunak disebut
dengan pengembangan perangkat lunak. Idealnya, pemeliharaan tidak boleh mengurangi realibilitas dan struktur dari
sistem, sebab akan menyusahkan perubahan di masa datang. Namun, kasus ini tidak berlaku pada dunia nyata di mana usia sistem akan mengakibatkan
struktur sistem menjadi lebih kompleks dan sumber daya ekstra harus ditambahkan untuk menyediakan semantik dan menyederhanakan struktur.
Karena itu, beberapa ahli menyarankan kategori keempat dari pemeliharaan perangkat lunak, yang disebut dengan pemeliharaan preventif.
ISO mendefinisikan juga tiga kategori pemeliharaan perangkat lunak, yakni:
Resolusi permasalahan yang mencakup deteksi, analisis, dan koreksi terhadap ketidaksesuaian perangkat lunak yang menyebabkan
permasalahan operasional
Modifikasi antarmuka diperlukan ketika perubahan dilakukan kepada sistem perangkat keras yang dikendalikan oleh perangkat lunak
Politeknik Telkom Rekayasa Perangkat Lunak
138 Pemeliharaan Perangkat Lunak
Peningkatan kinerjaekspansi fungsional yang diperlukan oleh konsumen pada fase pemeliharaan. Sebuah rekomendasi adalah semua
perubahan harus dilakukan dengan prosedur yang sama dengan yang digunakan pada pengembangan perangkat lunak
IEEE mengkategorikan pemeliharaan perangkat lunak ke dalam empat kategori, yakni:
Pemeliharaan korektif. Perubahan reaktif pada perangkat lunak yang dilakukan setelah penggunaan perangkat lunak oleh konsumen untuk
memperbaiki kerusakan yang ditemukan
Pemeliharaan adaptif. Perubahan pada perangkat lunak yang dilakukan setelah penggunaan perangkat lunak oleh konsumen agar
perangkat lunak dapat digunakan pada lingkungan yang berubah
Pemeliharaan perfektif. Perubahan pada perangkat lunak yang dilakukan setelah penggunaan perangkat lunak oleh konsumen untuk
meningkatkan kinerja atau maintainabilitas
Pemeliharaan emergensi. Pemeliharaan korektif yang tidak dijadwalkan untuk menjaga operasional sistem
Berikut adalah hubungan antara kategorisasi yang dilakukan oleh ISO dengan yang dilakukan oleh IEEE:
Politeknik Telkom Rekayasa Perangkat Lunak
Pemeliharaan Perangkat Lunak 139
8.3 Permasalahan Pemeliharaan Perangkat Lunak
Pemeliharaan merupakan aktivitas yang sangat menghabiskan biaya. Satu alasannya adalah karena untuk menambahkan fungsionalitas sistem yang
sedang beroperasi jauh lebih mahal dibandingkan dengan menambahkan fungsionalitas sistem ketika fase pengembangan.
Faktor yang membedakan antara pengembangan dan pemeliharaan yang berakibat pada mahalnya pemeliharaan adalah:
Stabilitas sistem. Setelah sistem dipasarkan, biasanya tim pengembang dibubarkan dan masing-masing anggota bekerja pada proyek yang baru.
Tim yang kemudian bertanggung jawab terhadap pemeliharan perangkat lunak tidak memiliki pemahaman yang lengkap terhadap perangkat lunak
yang bersangkutan sehingga diperlukan usaha tambahan untuk memahami perangkat lunak yang bersangkutan
Tanggung jawab kontraktual. Kontrak untuk pemeliharaan perangkat lunak biasanya terpisah dari kontrak untuk pengembangan
perangkat lunak
Keahlian staf. Staf pemeliharaan seringkali kurang pengalaman dan tidak terbiasa dengan domain aplikasi. Proses pemeliharaan seringkali
dilihat sebagai proses yang membutuhkan skill tidak terlalu tinggi dibandingkan dengan proses pengembangan perangkat lunak, hal ini
menyebabkan staf bagian pemeliharaan seringkali adalah staf dengan level junior. Lebih parah lagi, sistem yang dipelihara adalah seringkali sistem
yang menggunakan bahasa pemrograman dengan versi lama. Staf bagian pemeliharaan tentu saja kurang familiar dengan bahasa pemrograman
model ini sehingga perlu usaha untuk memahami bahasa pemrograman tersebut
Usia dan struktur program. Seiring dengan usia program, struktur dari program juga ikut berubah sehingga semakin sulit untuk dimengerti
apalagi diubah. Beberapa bagian sistem tidak dibuat dengan menggunakan teknik RPL modern, sehingga tidak pernah diatur dengan baik.
Dokumentasi sistem mungkin saja hilang atau inkonsisten
Tiga permasalahan awal dapat diselesaikan dengan cara merencanakan sebuah proses pengembangan berkelanjutan sepanjang usia dari perangkat lunak
sedangkan permasalahan yang terakhir dapat diselesaikan melalui teknik merekayasa ulang perangkat lunak Software Re-engineering.
Politeknik Telkom Rekayasa Perangkat Lunak
140 Pemeliharaan Perangkat Lunak
8.4 Model Pemeliharaan Perangkat Lunak
Pendekatan tipikal untuk pemeliharaan perangkat lunak adalah dengan mengubah kode program terlebih dahulu, kemudian membuat perubahan
yang diperlukan pada dokumentasi program. Pendekatan ini disebut pendekatan quick-fix model. Idealnya setelah kode diubah, maka dokumentasi
terkait kebutuhan, analisis, perancangan, pengujian, dan hal-hal terkait perangkat lunak yang bersangkutan harus diubah juga menyesuaikan dengan
perubahan pada kode program. Namun realita di lapangan menunjukkan bahwa perubahan pada kode program kadang tidak didokumentasikan
disebabkan oleh tekanan waktu dan biaya sehingga tim pemelihara tidak sempat untuk mengubah dokumentasi program.
Gambar 8.2 Quick-Fix Model
Model siklus hidup evolutionary menawarkan pendekatan alternatif untuk pemeliharaan perangkat lunak. Model ini menyatakan bahwa kebutuhan
sistem tidak dapat dikumpulkan dan dipahami pada tahap awal, sehingga sistem dibangun dengan memperbaiki kebutuhan dari bangunan sistem
sebelumnya berdasarkan feedback dari pengguna. Kelebihan dari model ini adalah dokumentasi dari sistem senantiasa berubah seiring dengan perubahan
pada kode program.
