3.7 Pemeliharaan perangkat lunak

Tinjauan dan motivasi

Sebagian besar perangkat lunak menghabiskan mayoritas absolut masa hidupnya bukan untuk dibangun, melainkan untuk dipelihara. Saat sistem masuk produksi, ia memasuki fase (sering berlangsung bertahun-tahun atau puluhan tahun) memperbaiki cacat, beradaptasi dengan lingkungan yang berubah, menyempurnakan apa yang sudah berfungsi, dan mencegah masalah di masa depan. Di enterprise besar, dan terutama di pemerintah, fase ini mendominasi. Mesin pajak, sistem tunjangan, platform pertahanan, dan buku besar keuangan inti rutin dipelihara jauh lebih lama daripada yang diperkirakan siapa pun yang memesannya. Pemeliharaan perangkat lunak adalah disiplin menjaga perangkat lunak yang telah diserahkan tetap benar, mutakhir, dan bernilai sepanjang seluruh masa operasionalnya.

Pemeliharaan secara kronis diremehkan dan kurang dihargai, dan kekeliruan itu mahal. Studi demi studi, selama puluhan tahun, menempatkan pemeliharaan jauh di atas separuh total biaya perangkat lunak seumur hidup, lazim dikutip dalam kisaran 60 hingga 90 persen untuk sistem berumur panjang. Namun organisasi merencanakan, menganggarkan, mengisi staf, dan merayakan pembangunan awal seolah itu seluruh upaya. Lalu mereka memperlakukan segala sesuatu sesudahnya sebagai renungan belakangan, didanai dari kantong yang menyusut dan diserahkan kepada siapa pun yang tersedia. Hasilnya dapat diduga: sistem rapuh, pemelihara yang patah semangat, biaya perubahan yang meningkat, dan akhirnya krisis yang dibingkai sebagai “masalah warisan” (bab 3.6) padahal sejak awal itu masalah pemeliharaan yang tak terkelola.

Bab ini mengikuti area pengetahuan Pemeliharaan Perangkat Lunak dari SWEBOK (Software Engineering Body of Knowledge) dan ISO/IEC 14764. Ia mencakup dasar-dasar pemeliharaan dan empat kategori yang diakui; isu kunci yang membuat pemeliharaan sulit, termasuk biaya, staf, dan moral; proses pemeliharaan; teknik inti pemahaman program, reengineering, dan refaktoring; cara memperkirakan biaya pemeliharaan; dan (gagasan berpengungkit tertinggi dalam bab ini) cara merancang untuk kemudahan pemeliharaan sejak awal. Keyakinan pusatnya adalah bahwa pemeliharaan bukan aktivitas yang lebih rendah yang mengikuti rekayasa. Ia bagian terbesar rekayasa perangkat lunak, dan harus direncanakan, diberi sumber daya, dan dihormati sebagaimana mestinya.

Prinsip utama

Pemeliharaan adalah mayoritas siklus hidup, bukan epilog. Rencanakan dan anggarkan sejak hari pertama; biayanya akan lebih besar daripada pembangunan.
Keempat kategori adalah pekerjaan yang berbeda. Pemeliharaan korektif, adaptif, perfektif, dan preventif punya pendorong dan irama berbeda; sebagian besar upaya bukan memperbaiki bug.
Anda tidak dapat mengubah apa yang tidak Anda pahami. Pemahaman program adalah aktivitas tunggal terbesar dalam pemeliharaan; buat kode dan riwayatnya terbaca.
Kemudahan pemeliharaan adalah properti desain. Biaya perubahan di masa depan sebagian besar ditetapkan oleh keputusan yang dibuat selama konstruksi; rancang untuknya dengan sengaja.
Perubahan kecil, aman, dan berkelanjutan mengalahkan perubahan besar yang ditunda. Refaktor dan modernisasi secara inkremental di bawah jaring pengaman tes alih-alih menumpuk utang perubahan.
Perangkat lunak menua bahkan ketika diam. Lingkungan bergerak (dependensi, platform, regulasi), sehingga sistem statis membusuk diam-diam; pemeliharaan preventif adalah pekerjaan nyata.
Pemelihara layak mendapat status kelas satu. Moral, retensi pengetahuan, dan pengisian staf tim pemeliharaan langsung menentukan biaya dan risiko jangka panjang.

Rekomendasi

Bedakan empat kategori pemeliharaan dan sediakan staf untuk semuanya

ISO/IEC 14764 dan SWEBOK mengakui empat kategori, dan mencampuradukkannya adalah kekeliruan perencanaan yang umum. Pemeliharaan korektif memperbaiki cacat yang ditemukan dalam operasi. Pemeliharaan adaptif menjaga perangkat lunak tetap berfungsi seiring lingkungannya berubah: sistem operasi, peramban, dependensi, perangkat keras, regulasi, atau sistem yang berinteraksi yang baru. Pemeliharaan perfektif menyempurnakan perangkat lunak bagi pengguna dan pemelihara, lewat fitur baru, kinerja lebih baik, kegunaan yang membaik, dan kemudahan pemeliharaan yang meningkat. Pemeliharaan preventif memperbaiki kesalahan laten dan mengurangi risiko masa depan sebelum muncul, lewat pengerasan, pembersihan, dan modernisasi area rapuh. Pembagian lanjutan yang berguna mengelompokkan korektif dan preventif sebagai koreksi (menangani kesalahan) dan adaptif serta perfektif sebagai penyempurnaan (menangani persyaratan baru). Yang krusial, studi empiris konsisten menemukan bahwa mayoritas pemeliharaan bukan korektif; penyempurnaan dan adaptasi mendominasi. Anggarkan dan sediakan staf sesuai itu, dan lacak kategori mana yang sebenarnya jatuh pada upaya Anda agar dapat mengelolanya.

Investasikan pada pemahaman program

Aktivitas tunggal terbesar dalam pemeliharaan adalah memahami sistem yang ada cukup baik untuk mengubahnya dengan aman. Pemelihara rutin menghabiskan lebih banyak waktu membaca dan bernalar tentang kode daripada memodifikasinya. Buat ini lebih murah dengan sengaja. Jaga dokumentasi dekat dengan kode dan mutakhir (bab 2.7). Pertahankan riwayat keputusan lewat catatan keputusan arsitektur (bab 1.6) dan riwayat komit yang bersih (bab 2.6). Gunakan analisis statis, graf dependensi, dan perkakas navigasi kode untuk memetakan wilayah asing. Tes karakterisasi (tes yang mengunci perilaku saat ini, termasuk keanehan) mengubah pemahaman tersirat menjadi pengetahuan yang dapat dieksekusi dan tahan lama. Ketika pemahaman mahal, setiap perubahan lambat dan berisiko. Ketika murah, pemeliharaan menjadi rutin.

Refaktor terus-menerus di bawah jaring pengaman tes

Refaktoring adalah penataan ulang kode secara disiplin yang meningkatkan kualitas internalnya tanpa mengubah perilaku eksternalnya. Dilakukan terus-menerus dan dalam langkah kecil, ia melawan kecenderungan alami menuju kompleksitas dan menjaga biaya perubahan tetap datar alih-alih naik. Prasyarat yang tak dapat ditawar adalah rangkaian tes otomatis yang andal (bab 2.4). Tanpanya, “refaktoring” hanyalah penulisan ulang berisiko. Lipat refaktoring ke dalam pekerjaan sehari-hari: tinggalkan setiap modul sedikit lebih bersih daripada saat Anda menemukannya, alih-alih menyimpannya untuk pembersihan besar yang jarang dan berbahaya. Inilah pemeliharaan preventif dalam praktik, dan pemeliharaan termurah yang ada.

Lakukan reengineering ketika perubahan inkremental tak lagi cukup

Ketika komponen telah merosot hingga perubahan rutin terlalu mahal atau berisiko, reengineering (memeriksa dan mengubah sistem untuk menyusunnya kembali dalam bentuk baru) adalah perkakas yang lebih berat. Reengineering biasanya memadukan rekayasa balik (memulihkan desain dan maksud dari implementasi) dengan reengineering maju (membangun ulang ke struktur yang lebih baik sambil mempertahankan perilaku). Pilih melakukan reengineering dalam irisan terbatas dan inkremental memakai pola seperti strangler fig dan branch-by-abstraction (bab 3.6), alih-alih penulisan ulang menyeluruh. Reengineering berada pada kontinum pemeliharaan-ke-modernisasi: refaktoring untuk yang kecil dan lokal, reengineering untuk yang struktural, dan modernisasi untuk tingkat platform.

Jalankan proses pemeliharaan yang terdefinisi

Pemeliharaan diuntungkan oleh proses eksplisit yang dapat diulang, sebagaimana dijelaskan dalam ISO/IEC 14764: implementasi proses (menetapkan rencana dan prosedur), analisis masalah dan modifikasi (triase, reproduksi, nilai dampak dan biaya), implementasi modifikasi, tinjauan dan penerimaan pemeliharaan, migrasi, dan pensiun. Bungkus dalam manajemen perubahan yang disiplin: setiap permintaan pemeliharaan (laporan cacat maupun penyempurnaan) harus dicatat, diklasifikasikan menurut kategori, dinilai dampaknya, diprioritaskan, diimplementasikan di bawah kontrol versi dengan tes, ditinjau, dan dirilis lewat pipeline normal (bab 11.2). Analisis dampak, memahami segala yang mungkin disentuh perubahan yang diusulkan, adalah pusat dan layak mendapat upaya nyata. Pensiun juga bagian dari proses: menonaktifkan sistem dengan aman, memigrasikan data dan penggunanya, dan menjaga catatan adalah pekerjaan pemeliharaan yang harus direncanakan, bukan diimprovisasi.

Perkirakan biaya pemeliharaan secara eksplisit dan danai

Jangan perlakukan pemeliharaan sebagai gratis, atau sebagai derau dalam anggaran pembangunan. Perkirakan. Pendekatan umum mencakup rasio upaya pemeliharaan (aturan praktis yang banyak dipakai bahwa pemeliharaan tahunan berjalan sekitar 15 hingga 25 persen dari biaya pengembangan awal, meski sistem kritis berumur panjang mengakumulasi jauh lebih banyak sepanjang hidupnya), model parametrik seperti COCOMO II (Constructive Cost Model) dengan ekstensi pemeliharaan dan penggunaan ulangnya, dan peramalan berbasis metrik dari data historis Anda sendiri tentang tingkat cacat, volume perubahan, dan biaya perubahan. Masukkan perkiraan ini ke analisis total biaya kepemilikan dan ekonomi yang dibahas dalam bab 10.10. Harga pembelian atau biaya bangun sistem adalah uang muka. Cicilan hipotek adalah pemeliharaan, dan ia harus muncul di setiap kasus bisnis.

Rancang untuk kemudahan pemeliharaan sejak awal

Pengungkit terbesar atas biaya pemeliharaan dilakukan sebelum pemeliharaan dimulai. Kemudahan pemeliharaan (keterananalisisan, kemudahan dimodifikasi, kemudahan diuji, dan modularitas, dalam kosakata ISO/IEC 25010) adalah kualitas desain yang harus menjadi persyaratan eksplisit, bukan kebetulan yang menyenangkan. Pilih desain modular, berkopling longgar, berkohesi tinggi (bab 2.2); antarmuka jelas dan pemisahan perhatian; tes otomatis kuat; kode terbaca dan dokumentasi mutakhir; serta observabilitas kaya agar operator dan pemelihara dapat melihat apa yang dilakukan sistem (Bagian 9). Setiap keputusan ini menukar sedikit lebih banyak upaya sekarang dengan penghematan besar yang berlipat sepanjang puluhan tahun hidup sebenarnya sistem. Membangun untuk kemudahan pemeliharaan adalah investasi berimbal hasil tertinggi di seluruh siklus hidup.

Trade-off: kelebihan dan kekurangan

Pendekatan	Kelebihan	Kekurangan
Refaktoring berkelanjutan / pemeliharaan preventif	Menjaga biaya perubahan datar, mengurangi risiko, ROI tinggi	Upaya berkelanjutan tanpa fitur baru yang terlihat; butuh tes kuat
Menunda pemeliharaan (“jaga lampu menyala”)	Termurah kuartal ini; membebaskan kapasitas untuk fitur	Utang perubahan berlipat; krisis akhirnya dan tindakan mahal yang dipaksakan
Reengineering komponen yang merosot	Memulihkan kemudahan pemeliharaan dan memperpanjang umur berguna	Upaya dan risiko signifikan; perilaku harus dipertahankan dengan hati-hati
Merancang untuk kemudahan pemeliharaan di muka	Penghematan seumur hidup berlipat; setiap perubahan mendatang lebih mudah	Biaya awal dan disiplin lebih tinggi; manfaat ditunda dan kurang terlihat

Trade-off yang berulang dalam pemeliharaan adalah biaya sekarang versus biaya mendatang, dan godaan selalu mengarah pada penundaan. Melewatkan refaktoring, membiarkan dependensi menua, dan membuat tim pemeliharaan kelaparan semuanya tampak gratis kuartal ini, karena tagihan tiba belakangan: sebagai sistem yang lebih lambat, berisiko, dan mahal, dan akhirnya sebagai “krisis warisan.” Disiplin pemeliharaan yang baik adalah membayar biaya kecil, berkelanjutan, dan terlihat sekarang untuk menghindari biaya besar, mendadak, yang menentukan karier kelak. Karena penghematannya tertunda dan tak terlihat, pertukaran ini membutuhkan kepemimpinan yang memahami ekonomi siklus hidup, bukan sekadar tanggal peluncuran.

Pertanyaan untuk didiskusikan dengan tim Anda

Siapa yang memiliki angka pemeliharaan dalam anggaran Anda, dan apakah ia baris kelas satu atau sisa yang dikais dari apa pun yang tidak dihabiskan pembangunan? Pemeliharaan adalah mayoritas biaya seumur hidup, lazim 60 hingga 90 persen untuk sistem berumur panjang, namun rutin didanai sebagai renungan belakangan dan diisi staf oleh siapa pun yang bebas. Ketika anggaran bersifat sisa, pekerjaan preventif adalah yang pertama dipotong, utang perubahan berlipat, dan menyusul perosotan yang dapat diduga menuju “krisis warisan.” Bawa perkiraan nyata (rasio upaya pemeliharaan, model parametrik, atau data biaya perubahan historis Anda sendiri) dan namai orang yang bertanggung jawab mendanainya sepanjang umur sistem. Perbaikannya adalah menganggarkan pemeliharaan secara eksplisit dalam setiap kasus bisnis, seperti cicilan hipotek yang duduk di samping harga pembelian. Kepemimpinan yang hanya merayakan peluncuran akan terus kekurangan dana pada fase di mana sebagian besar uang dan risiko sebenarnya berada.
Apakah Anda menyisihkan kapasitas untuk pemeliharaan preventif, atau ia selalu kalah dari fitur berikutnya? Pekerjaan preventif (refaktoring di bawah jaring tes, menjaga dependensi mutakhir, mengeraskan area rapuh) adalah pemeliharaan termurah yang ada, karena menjaga kurva biaya-perubahan datar alih-alih membiarkannya naik. Ia juga yang paling mudah ditunda, karena melewatkannya tampak gratis kuartal ini dan tagihan tiba belakangan sebagai sistem yang lebih lambat dan berisiko. Mekanisme konkret membantu: alokasi tetap, dan banyak tim kuat melindungi sekitar seperlima kapasitas, yang dijaga alih-alih dinegosiasikan habis setiap sprint. Bawa tren biaya perubahan Anda sebagai bukti; jika naik, Anda sudah berinvestasi kurang. Disiplinnya membayar biaya kecil dan terlihat sekarang untuk menghindari yang besar dan mendadak yang menentukan karier kelak, dan itu membutuhkan kepemimpinan yang membaca ekonomi siklus hidup alih-alih tanggal peluncuran.
Apa rencana Anda untuk memensiunkan sistem, dan kapan terakhir kali Anda benar-benar menonaktifkan satu? Pensiun adalah bagian eksplisit dari proses pemeliharaan (migrasi data, cutover pengguna, pelestarian catatan, penutupan aman), namun organisasi membawa sistem mati dan redundan selama bertahun-tahun karena penonaktifan tidak glamor dan tidak dianggarkan. Setiap sistem zombi masih memakan lisensi, penambalan keamanan, permukaan integrasi, dan perhatian orang yang bisa berada di tempat lain. Bawa inventaris dan tandai sistem tanpa pengguna aktif atau yang penggantian penuhnya sudah hidup, lalu rencanakan penutupannya seperti pekerjaan lain: migrasikan data, jaga apa yang diwajibkan undang-undang, dan pastikan tak ada yang masih bergantung padanya. Terutama di pemerintah, hukum retensi catatan membentuk cara Anda memensiunkan, jadi libatkan kepatuhan sejak awal. Sinyal kematangan yang layak dilacak: kapan terakhir kali organisasi Anda dengan sengaja mematikan sesuatu?
Berapa banyak dari setiap perubahan dihabiskan untuk memahami sistem sebelum menyentuhnya, dan berapa bus factor Anda pada sistem yang paling penting? Pemahaman program adalah aktivitas tunggal terbesar dalam pemeliharaan, dan biayanya ditentukan oleh seberapa terbaca Anda menjaga kode, riwayatnya, dan perilakunya. Ketika pemahaman hanya hidup di beberapa kepala berpengalaman panjang, setiap kepergian atau pensiun menaikkan harga setiap perubahan mendatang, dan satu ketidakhadiran dapat menghentikan perbaikan kritis. Bawa bukti: rasio waktu membaca-dan-bernalar terhadap waktu menyunting pada perubahan terbaru, jumlah orang yang dapat memodifikasi setiap modul inti dengan aman, dan apakah aturan bisnis serta keputusan didokumentasikan di samping kode atau direkonstruksi dari ingatan setiap kali. Pertimbangan yang bersaing adalah bahwa dokumentasi dan tes karakterisasi memakan upaya sekarang untuk penghematan yang baru terlihat kelak, sehingga mudah dilewatkan. Di enterprise dan pemerintah, di mana sistem hidup lebih lama daripada penulis aslinya selama puluhan tahun dan aturan undang-undang terkubur dalam mesin perhitungan yang tak diingat sepenuhnya oleh siapa pun, perlakukan pemahaman yang tertangkap (catatan keputusan arsitektur, tes karakterisasi, dokumentasi mutakhir) sebagai aset yang Anda danai dengan sengaja, bukan basa-basi yang terjadi ketika seseorang punya waktu luang.
Siapa yang sebenarnya mengisi staf pekerjaan pemeliharaan Anda, dan apakah status dan moralnya sepadan dengan pentingnya? Pemeliharaan adalah mayoritas biaya seumur hidup dan rekayasa tersulit yang ada, mengubah dengan aman sistem yang tidak Anda bangun dan mungkin tak sepenuhnya Anda pahami, namun rutin diserahkan kepada orang paling tidak berpengalaman dan dibingkai sebagai “menjaga lampu menyala” berstatus rendah. Sinyal itu korosif: insinyur terbaik Anda menghindari pekerjaan itu, pengetahuan terkonsentrasi lalu keluar dari pintu, dan biaya perubahan naik sementara tak seorang pun mengawasi. Bawa profil senioritas orang yang memelihara sistem berumur terpanjang Anda, data atrisi dan retensi pengetahuan Anda, dan pembacaan jujur apakah pemeliharaan jalan buntu karier atau spesialisasi yang dihormati di organisasi Anda. Ketegangannya nyata, karena insinyur berambisi ingin membangun hal baru dan pimpinan ingin merayakan peluncuran, sehingga menghormati pemeliharaan membutuhkan struktur yang disengaja. Bagi enterprise besar atau badan publik yang menjalankan sistem yang membawa risiko regulasi dan keuangan selama puluhan tahun, mengisi staf pemeliharaan dengan insinyur senior yang dihormati adalah keputusan manajemen risiko, dan membiarkan pemeliharaan menjadi penempatan hukuman adalah cara Anda memproduksi krisis warisan berikutnya.
Apakah Anda melacak ke kategori mana dari keempatnya upaya Anda sebenarnya jatuh, dan apakah Anda mengukur biaya perubahan sebagai indikator utama? Tim rutin merencanakan pemeliharaan seolah sebagian besar memperbaiki bug, padahal studi empiris menunjukkan penyempurnaan dan adaptasi mendominasi, sehingga portofolio yang hanya didanai untuk kerja korektif salah cakupan sejak awal. Tanpa pelacakan kategori Anda tidak dapat melihat bahwa sistem dibentuk ulang oleh arus stabil adaptasi regulasi, dan tanpa metrik biaya perubahan (lead time perubahan, tingkat kegagalan perubahan, tren kompleksitas) Anda tidak dapat mengatakan apakah kurva Anda datar atau diam-diam naik menuju krisis. Bawa rincian kategori aktual Anda untuk setahun terakhir, tren biaya perubahan Anda jika ada, dan catatan jujur apakah analisis dampak langkah nyata atau formalitas yang dilewati di bawah tekanan tenggat. Tarikan yang bersaing adalah bahwa pengukuran sendiri memakan upaya dan dapat terasa seperti beban ketika sistem masih berfungsi. Dalam portofolio enterprise dan pemerintah, di mana banyak tim memelihara banyak sistem dan kurva biaya yang naik pada salah satunya adalah peringatan dini yang layak ditindaklanjuti, pelacakan kategori bersama dan indikator biaya perubahan memungkinkan pimpinan melakukan reengineering modul sebelum merosot alih-alih setelah gagal di depan publik.

Lensa sektor

Startup. Dengan segelintir insinyur dan landasan pendek, Anda tidak mampu proses pemeliharaan berat, tetapi juga tidak mampu basis kode yang tak mau disentuh siapa pun. Sisihkan irisan tetap kecil dari setiap siklus (kira-kira satu hari dari lima) untuk kerja preventif: tambal dependensi, bersihkan cacat kecil sebelum berlipat, dan refaktor sudut yang sudah Anda takuti di bawah tes apa pun yang Anda punya. Tujuannya menjaga kode murah diubah selagi Anda berputar haluan, agar Anda tidak pernah bangun pada dua puluh insinyur dan keliru menganggap pemeliharaan yang ditunda sebagai “masalah warisan.”

Bisnis kecil. Tanpa spesialis pemeliharaan khusus dan dengan anggaran ketat, condonglah ke membeli dan menumpang di hosting daripada membangun, agar pemeliharaan adaptif (tambalan keamanan, pembaruan platform dan dependensi) sebagian besar menjadi pekerjaan orang lain. Di tempat Anda memiliki kode, jaga tetap kecil, membosankan, dan terdokumentasi baik, dan pastikan setidaknya dua orang memahami apa pun yang diandalkan bisnis. Lacak segelintir sistem yang tak sanggup Anda hilangkan, dan anggarkan baris sederhana yang eksplisit untuk menjaganya tetap mutakhir alih-alih berpura-pura pemeliharaan gratis.

Enterprise. Pada skala besar Anda memelihara banyak sistem berumur panjang di banyak tim, jadi prioritasnya proses yang terdefinisi dan dapat diulang: pipeline permintaan yang dicatat dan ditriase, klasifikasi ke empat kategori, analisis dampak rutin, dan alokasi preventif tetap yang dijaga alih-alih dinegosiasikan habis. Danai pemeliharaan sebagai program kelas satu, ukur indikator biaya perubahan di seluruh portofolio, dan pakai kurva yang naik sebagai pemicu untuk melakukan reengineering modul sebelum menjadi liabilitas. Ekspektasi tata kelola dan audit berarti pelacakan kategori dan catatan perubahan bukan beban, melainkan bukti bahwa properti berada di bawah kendali.

Pemerintah. Aturan pengadaan, transparansi, dan akuntabilitas publik membentuk pemeliharaan sebanyak rekayasa. Pemeliharaan adaptif yang digerakkan undang-undang tiba pada tenggat tahunan keras yang tak dapat meleset, jadi anggarkan pemeliharaan sebagai biaya operasi tanpa batas dan isi staf tim ahli yang stabil untuk mempertahankan pengetahuan tentang aturan yang penulisnya sudah lama pensiun. Pensiun dibatasi hukum retensi catatan, jadi rencanakan penonaktifan bersama kepatuhan sejak awal, dan pilih kontrak serta arsitektur yang menjaga sistem tetap dapat dipelihara dan portabel alih-alih menjebak Anda pada satu vendor selama puluhan tahun.

Contoh

Startup. Sebuah startup yang baru merilis MVP-nya tergoda menuangkan setiap jam ke fitur baru, tetapi insinyur pendirinya menyisihkan irisan tetap dari setiap sprint (kira-kira satu hari dari lima) untuk pemeliharaan sejak bulan pertama. Anggaran itu menjaga dependensi tertambal, membersihkan cacat kecil sebelum berlipat, dan merefaktor sudut yang sudah ditakuti tim, sehingga basis kode tetap murah diubah selagi produk berputar haluan. Startup yang melewatkan ini mencapai dua puluh insinyur dengan basis kode yang tak ingin disentuh siapa pun dan keliru menganggapnya “masalah warisan” padahal sejak awal itu pemeliharaan yang ditunda.

Enterprise. Sebuah bank global menjalankan platform pembayaran yang sudah berada di produksi selama lima belas tahun. Ia mendanai pemeliharaan sebagai program permanen kelas satu alih-alih baris anggaran sisa. Pekerjaan ditriase ke empat kategori: arus stabil perubahan adaptif mengikuti regulasi baru dan pembaruan antarmuka bank mitra, kerja perfektif menambah fitur dan meningkatkan throughput, kerja korektif membersihkan cacat terhadap perjanjian tingkat layanan (SLA) ketat, dan alokasi preventif tetap (kira-kira seperlima kapasitas tim) melunasi kompleksitas lewat refaktoring berkelanjutan di bawah rangkaian tes komprehensif. Tim mengukur lead time perubahan dan tingkat kegagalan perubahan, dan memperlakukan biaya perubahan yang naik sebagai peringatan dini untuk melakukan reengineering modul sebelum menjadi liabilitas. Pemelihara adalah insinyur senior yang dihormati, bukan staf junior yang diparkir pada “menjaga lampu menyala.”

Pemerintah. Otoritas pajak nasional memelihara sistem yang telah berjalan lebih dari tiga puluh tahun dan diubah setiap tahun ketika hukum pajak berubah. Kategori dominan di sini adalah pemeliharaan adaptif yang digerakkan undang-undang, dengan tenggat tahunan keras yang tak dapat meleset. Otoritas berinvestasi besar pada pemahaman program: aturan bisnis didokumentasikan di samping kode, tes karakterisasi mengunci perilaku aturan yang penulis aslinya sudah lama pensiun, dan analisis dampak adalah langkah formal sebelum perubahan apa pun pada mesin perhitungan. Karena lingkungan (hukum) berubah terus-menerus, sistem tidak pernah dapat “selesai,” sehingga otoritas menganggarkan pemeliharaan sebagai biaya operasi tanpa batas, mengisi staf tim ahli yang stabil untuk mempertahankan pengetahuan, dan memodernisasi praktik pengiriman di sekelilingnya seperti kontrol sumber, integrasi berkelanjutan (CI), dan pengujian otomatis, meski inti bertahan.

Kasus bisnis: motivasi, ROI, dan TCO

Fakta bisnis inti perangkat lunak adalah bahwa pemeliharaan, bukan konstruksi, adalah tempat uang pergi. Di seluruh industri dan selama puluhan tahun studi, pemeliharaan menyumbang mayoritas jelas biaya seumur hidup, sering dikutip 60 hingga 90 persen untuk sistem yang hidup lama, yang di enterprise dan pemerintah adalah sebagian besar sistem. Analisis total biaya kepemilikan yang berhenti pada go-live meleset beberapa kali lipat. Kasus bisnis utama untuk menganggap pemeliharaan serius sederhana saja: akurasi. Anggarkan untuk seluruh umur sistem, atau berulang kali terkejut oleh tagihan.

Imbal hasil investasi datang dari membengkokkan kurva biaya. Dalam sistem yang diabaikan, biaya setiap perubahan naik seiring waktu karena kompleksitas menumpuk dan pemahaman meluruh, sampai perubahan menjadi terlalu lambat dan berisiko. Dalam sistem yang dipelihara baik, kerja preventif berkelanjutan (refaktoring, kemutakhiran dependensi, cakupan tes, dokumentasi) menjaga kurva itu datar, sehingga perubahan keseribu berbiaya kira-kira sama dengan yang kesepuluh. Berinvestasi pada kemudahan pemeliharaan dan pemeliharaan preventif karenanya bukan pengeluaran untuk diminimalkan. Ia pengungkit yang menentukan apakah sistem tetap terjangkau untuk diubah atau hanyut ke biaya dan risiko yang meningkat dari properti warisan (bab 3.6) dan tantangan keberlanjutan bab 10.4. Danai pemeliharaan dengan sengaja, ukur biaya perubahan sebagai indikator utama, dan perlakukan kurva yang naik sebagai sinyal untuk bertindak, bukan fakta alam. Ekonominya dibahas lebih lanjut dalam bab 10.10.

Anti-pola dan jebakan

Memperlakukan pemeliharaan sebagai renungan belakangan. Menganggarkan dan merayakan hanya pembangunan, lalu membuat fase pemeliharaan yang jauh lebih besar dan lebih panjang kelaparan.
Mengisi staf pemeliharaan dengan orang paling tidak berpengalaman. Menugaskan pekerjaan tersulit (mengubah dengan aman sistem yang tidak sepenuhnya dipahami) kepada yang paling kurang siap, dan memberi sinyal bahwa pemeliharaan berstatus rendah.
Mencampuradukkan pemeliharaan dengan perbaikan bug. Merencanakan hanya kerja korektif padahal adaptasi dan penyempurnaan sebenarnya mendominasi upaya.
Menunda pemeliharaan preventif tanpa batas. Tidak pernah merefaktor, tidak pernah memperbarui dependensi, sampai utang perubahan memaksa krisis mahal.
Mengubah kode tanpa analisis dampak. Membuat “perbaikan kecil” yang beriak menjadi kegagalan tak terduga di tempat lain.
Refaktoring tanpa jaring pengaman tes. Menata ulang kode tanpa cara membuktikan perilaku terjaga: itu hanya penulisan ulang berisiko.
Membiarkan pengetahuan keluar dari pintu. Gagal mendokumentasikan aturan bisnis dan keputusan, sehingga setiap pensiun atau kepergian menaikkan biaya setiap perubahan mendatang.
Tidak pernah memensiunkan apa pun. Membawa sistem mati dan redundan selamanya karena penonaktifan tidak glamor dan tidak direncanakan.

Model kematangan

Tingkat 1: Memulai. Pemeliharaan tidak direncanakan dan tidak didanai, ditangani reaktif oleh siapa pun yang bebas. Dipandang sebagai perbaikan bug dan pekerjaan berstatus rendah. Tidak ada pelacakan kategori, tidak ada perkiraan biaya, dan pengetahuan hidup di beberapa kepala. Biaya perubahan naik tanpa disadari sampai perbaikan terhenti atau krisis memaksa perhatian.
Tingkat 2: Mengembangkan. Beberapa tim mulai mencatat dan menriase permintaan pemeliharaan dan membawa baris anggaran, tetapi praktik tidak konsisten di seluruh organisasi dan anggaran biasanya sisa. Kerja korektif dilacak sementara upaya adaptif dan perfektif tidak jelas dibedakan. Beberapa tes dan dokumentasi ada di kantong-kantong, sehingga perubahan terkendali sebagian tetapi pemahaman tetap mahal dan tidak merata dari tim ke tim.
Tingkat 3: Membakukan. Proses pemeliharaan terdefinisi (menurut ISO/IEC 14764) terdokumentasi dan ditegakkan di seluruh organisasi: pekerjaan diklasifikasikan ke empat kategori, analisis dampak dan manajemen perubahan rutin, dan pemeliharaan diperkirakan serta didanai secara eksplisit dalam setiap kasus bisnis. Pemeliharaan preventif dan refaktoring adalah praktik standar di bawah rangkaian tes yang solid, dan kemudahan pemeliharaan (keterananalisisan, kemudahan dimodifikasi, kemudahan diuji, modularitas) adalah persyaratan desain eksplisit alih-alih kebiasaan lokal.
Tingkat 4: Mengelola. Pemeliharaan diukur dan dikendalikan dengan data terhadap garis dasar. Indikator biaya perubahan (lead time perubahan, tingkat kegagalan perubahan, tren kompleksitas dan cacat) dilacak per sistem, campuran upaya empat kategori dikuantifikasi terhadap ekspektasi, dan rasio upaya pemeliharaan serta perkiraan parametrik diperiksa terhadap biaya perubahan historis aktual. Kurva biaya yang naik terdeteksi sebagai indikator utama dan memicu tindakan, dan alokasi preventif ditakar dari bukti alih-alih ditebak. Keputusan untuk merefaktor, melakukan reengineering, atau memensiunkan dibuat pada ambang terukur, bukan intuisi.
Tingkat 5: Mengorkestrasi. Pemeliharaan terus diperbaiki dan terintegrasi di seluruh organisasi dan ekonomi siklus hidupnya. TCO siklus hidup menggerakkan investasi portofolio, reengineering diterapkan dengan sengaja sebelum komponen merosot, pengetahuan dipertahankan secara aktif, dan pensiun direncanakan serta rutin dilaksanakan. Organisasi menyeimbangkan ulang upaya pemeliharaan seiring bergesernya lingkungan (regulasi, platform, dependensi), pemelihara adalah insinyur senior yang dihormati, dan seluruh properti beradaptasi sehingga biaya perubahan tetap datar di seluruh sistem yang hidup puluhan tahun.

Gagasan untuk didiskusikan

Berapa fraksi upaya rekayasa Anda yang sebenarnya pergi ke pemeliharaan, dan apakah anggaran serta staf Anda mencerminkan kenyataan itu?
Dapatkah Anda memecah pekerjaan pemeliharaan Anda ke empat kategori, dan apakah campurannya cocok dengan asumsi Anda?
Berapa banyak dari perubahan tipikal dihabiskan untuk memahami sistem versus memodifikasinya, dan apa yang akan membuat pemahaman lebih murah?
Apakah biaya perubahan Anda naik, datar, atau turun seiring waktu, dan apakah Anda mengukurnya sama sekali?
Apakah tim Anda punya jaring pengaman tes yang andal yang membuat refaktoring berkelanjutan aman, atau penataan ulang terlalu berisiko untuk dicoba?
Siapa yang memelihara sistem berumur terpanjang Anda, bagaimana pengetahuan mereka ditangkap, dan bagaimana status serta moral pekerjaan itu?

Poin-poin utama

Pemeliharaan adalah mayoritas biaya seumur hidup perangkat lunak (lazim 60 hingga 90 persen untuk sistem berumur panjang) dan harus direncanakan, dianggarkan, dan diisi staf sebagai aktivitas kelas satu.
Keempat kategori (korektif, adaptif, perfektif, preventif) adalah pekerjaan berbeda, dan penyempurnaan serta adaptasi, bukan perbaikan bug, biasanya mendominasi.
Pemahaman program adalah aktivitas pemeliharaan tunggal terbesar; buat kode, riwayat, dan perilaku terbaca agar setiap perubahan tetap murah.
Refaktor terus-menerus di bawah jaring pengaman tes dan lakukan reengineering komponen yang merosot secara inkremental untuk menjaga biaya perubahan datar.
Perkirakan biaya pemeliharaan secara eksplisit dan masukkan ke total biaya kepemilikan dan keputusan ekonomi.
Rancang untuk kemudahan pemeliharaan sejak awal (investasi berimbal hasil tertinggi di seluruh siklus hidup) dan perlakukan pemelihara sebagai profesional senior sebagaimana mestinya.

Referensi dan bacaan lanjutan

IEEE Computer Society, SWEBOK Guide (Software Engineering Body of Knowledge), area pengetahuan Software Maintenance
ISO/IEC 14764 / IEEE 14764, Software Engineering: Software Life Cycle Processes, Maintenance
ISO/IEC 25010, Systems and software Quality Requirements and Evaluation (SQuaRE): karakteristik kualitas kemudahan pemeliharaan
Martin Fowler, Refactoring: Improving the Design of Existing Code
Michael Feathers, Working Effectively with Legacy Code
Thomas M. Pigoski, Practical Software Maintenance
Penny Grubb dan Armstrong A. Takang, Software Maintenance: Concepts and Practice
Barry Boehm et al., Software Cost Estimation with COCOMO II (model pemeliharaan dan penggunaan ulang)
Meir M. Lehman, “Laws of Software Evolution” (tentang mengapa perangkat lunak harus terus berubah atau menjadi kurang berguna)
Robert C. Seacord, Daniel Plakosh, dan Grace A. Lewis, Modernising Legacy Systems