Saya akan mengawali ini dengan fakta bahwa sebagian besar dari apa yang saya temukan berasal dari tahun 1970-an dan awal 1980-an. Selama waktu ini, model proses berurutan jauh lebih umum daripada pendekatan iteratif dan / atau tambahan (model Spiral atau metode gesit). Banyak dari pekerjaan ini dibangun pada model sekuensial ini. Namun, saya tidak berpikir itu menghancurkan hubungan, tetapi salah satu manfaat dari pendekatan iteratif / inkremental adalah merilis fitur (seluruh irisan vertikal aplikasi) dengan cepat dan memperbaiki masalah di dalamnya sebelum dependensi disuntikkan dan kompleksitas setiap fase tinggi.
Saya baru saja mengeluarkan salinan Ekonomi Rekayasa Perangkat Lunak dan menemukan referensi ke data di balik bagan ini di Bab 4. Dia mengutip "Desain dan Inspeksi Kode untuk Mengurangi Kesalahan dalam Pengembangan Program" oleh ME Fagan ( IEEE , PDF dari UMD ), EB "Manajemen Rekayasa Perangkat Lunak" Daly, WE Stephenson, "Analisis Sumber Daya yang Digunakan dalam Pengembangan Perangkat Lunak Sistem Perlindungan" ( ACM ), dan "beberapa proyek TRW".
... biaya relatif untuk memperbaiki kesalahan perangkat lunak (atau membuat perubahan perangkat lunak lain) sebagai fungsi dari fase di mana koreksi atau perubahan dilakukan. Jika kesalahan persyaratan perangkat lunak terdeteksi dan diperbaiki selama fase rencana dan persyaratan, koreksi adalah masalah yang relatif sederhana untuk memperbarui spesifikasi persyaratan. Jika kesalahan yang sama tidak diperbaiki hingga fase pemeliharaan, koreksi melibatkan inventaris yang jauh lebih besar dari spesifikasi, kode, manual pengguna dan pemeliharaan, dan materi pelatihan.
Selanjutnya, koreksi yang terlambat melibatkan proses persetujuan dan kontrol perubahan yang jauh lebih formal, dan kegiatan yang jauh lebih luas untuk memvalidasi ulang koreksi. Faktor-faktor ini bergabung untuk membuat kesalahan biasanya 100 kali lebih mahal untuk diperbaiki pada fase pemeliharaan pada proyek-proyek besar daripada pada fase persyaratan.
Bohem juga melihat dua proyek yang lebih kecil, kurang formal dan menemukan peningkatan biaya, tetapi jauh lebih kecil daripada 100 kali diidentifikasi dalam proyek yang lebih besar. Dengan bagan tersebut, perbedaannya tampak 4 kali lebih besar untuk memperbaiki cacat persyaratan setelah sistem beroperasi daripada pada fase persyaratan. Dia menghubungkan ini dengan persediaan barang yang lebih kecil yang terdiri dari proyek dan berkurangnya formalitas yang menyebabkan kemampuan untuk mengimplementasikan perbaikan yang lebih sederhana dengan lebih cepat.
Berdasarkan Boehm dalam Ekonomi Rekayasa Perangkat Lunak, tabel dalam Kode Lengkap agak membengkak (ujung rendah kisaran sering kali terlalu tinggi). Biaya untuk melakukan perubahan dalam fase memang 1. Ekstrapolasi dari Gambar 4-2 dalam Ekonomi Rekayasa Perangkat Lunak, perubahan persyaratan harus 1,5-2,5 kali dalam arsitektur, 2,5-10 dalam pengkodean, 4-20 dalam pengujian, dan 4- 100 dalam perawatan. Jumlahnya tergantung pada ukuran dan kompleksitas proyek serta formalitas proses yang digunakan.
Dalam Lampiran E dari Barry Boehm dan Agility dan Disiplin Penyeimbang Richard Turner berisi bagian kecil tentang temuan empiris mengenai biaya perubahan.
Paragraf pembuka mengutip Extreme Beck Programming Dijelaskan, mengutip Beck. Dikatakan bahwa jika biaya perubahan naik perlahan dari waktu ke waktu, keputusan akan dibuat selambat mungkin dan hanya yang diperlukan yang akan dilaksanakan. Ini dikenal sebagai "kurva datar" dan inilah yang mendorong Extreme Programming. Namun, apa yang ditemukan literatur sebelumnya adalah "kurva curam", dengan sistem kecil (<5 KSLOC) memiliki perubahan 5: 1 dan sistem besar memiliki perubahan 100: 1.
Bagian ini mengutip Pusat Rekayasa Perangkat Lunak Berbasis Universitas Maryland (disponsori oleh National Science Foundation). Mereka melakukan pencarian literatur yang tersedia dan menemukan bahwa hasilnya cenderung mengkonfirmasi rasio 100: 1, dengan beberapa hasil menunjukkan kisaran 70: 1 hingga 125: 1. Sayangnya, ini biasanya proyek "desain besar di depan" dan dikelola secara berurutan.
Ada sampel "proyek Jawa komersial kecil" yang dijalankan menggunakan Extreme Programming. Untuk setiap Story, jumlah upaya memperbaiki kesalahan, desain baru, dan refactoring dilacak. Data menunjukkan bahwa ketika sistem dikembangkan (lebih banyak cerita pengguna diimplementasikan), upaya rata-rata cenderung meningkat dalam tingkat non-sepele. Upaya refactoring meningkat sekitar 5% dan upaya memperbaiki upaya meningkat sekitar 4%.
Apa yang saya pelajari adalah bahwa kompleksitas sistem memainkan peran besar dalam jumlah upaya yang diperlukan. Dengan membuat irisan vertikal melalui sistem, Anda memperlambat laju kurva dengan menambahkan kompleksitas secara perlahan alih-alih menambahkannya dalam tumpukan. Daripada berurusan dengan kerumitan persyaratan yang diikuti oleh arsitektur yang sangat kompleks, diikuti oleh implementasi yang sangat kompleks, dan seterusnya, Anda mulai dengan sangat sederhana dan menambahkan.
Apa dampaknya terhadap biaya perbaikan? Pada akhirnya, mungkin tidak banyak. Namun, ia memang memiliki kelebihan yang memungkinkan kontrol lebih besar atas kompleksitas (melalui pengelolaan utang teknis). Selain itu, seringnya hasil yang sering dikaitkan dengan gesit berarti bahwa proyek mungkin berakhir lebih cepat - daripada memberikan "sistem", potongan dikirimkan sampai kebutuhan bisnis dipenuhi atau telah mengubah secara drastis sistem baru (dan karenanya proyek baru) dibutuhkan.
Metrik dan Model Stephen Kan dalam Rekayasa Kualitas Perangkat Lunak memiliki bagian dalam Bab 6 tentang efektivitas biaya penghapusan cacat fase.
Dia memulai dengan mengutip makalah Fagan tahun 1976 (juga dikutip dalam Rekayasa Perangkat Lunak Ekonomi) untuk menyatakan bahwa pengerjaan ulang dilakukan dalam desain tingkat tinggi (arsitektur sistem), desain tingkat rendah (desain rinci), dan implementasi dapat antara 10 dan 100 kali lebih murah daripada pekerjaan yang dilakukan selama pengujian tingkat komponen dan sistem.
Dia juga mengutip dua publikasi, dari 1982 dan 1984, oleh Freedman dan Weinberg yang membahas sistem besar. Yang pertama adalah "Buku Pegangan Walkthroughs, Inspeksi, dan Ulasan Teknis" dan yang kedua adalah "Ulasan, Walkthroughs, dan Inspeksi". Penerapan ulasan di awal siklus pengembangan dapat mengurangi jumlah kesalahan yang mencapai fase pengujian dengan faktor 10. Pengurangan jumlah cacat ini menyebabkan berkurangnya biaya pengujian sebesar 50% hingga 80%. Saya harus membaca studi lebih terinci, tetapi tampaknya biayanya juga termasuk menemukan dan memperbaiki cacat.
Sebuah studi tahun 1983 oleh Remus, "Validasi Perangkat Lunak Terpadu dalam Pandangan Inspeksi / Tinjauan", mempelajari biaya untuk menghilangkan cacat dalam fase yang berbeda, khususnya desain / inspeksi kode, pengujian, dan pemeliharaan, menggunakan data dari Laboratorium Santa Teresa IBM di California. Hasil yang dikutip menunjukkan rasio biaya 1:20:82. Yaitu, cacat yang ditemukan dalam inspeksi desain atau kode memiliki biaya untuk mengubah 1. Jika cacat yang sama lolos ke pengujian, biayanya 20 kali lebih tinggi. Jika lolos sampai ke pengguna, itu akan melipatgandakan biaya hingga benar hingga 82. Kan, menggunakan data sampel dari Rochester, fasilitas Minnessota IBM, menemukan bahwa biaya penghilangan cacat untuk proyek AS / 400 sama. pada 1:13:92. Namun, ia menunjukkan bahwa kenaikan biaya mungkin karena meningkatnya kesulitan untuk menemukan cacat.
Publikasi Gilb's 1993 ( "Inspeksi Perangkat Lunak" ) dan 1999 ("Optimalisasi Spesifikasi Perangkat Lunak dan Proses Kontrol Kualitas") pada inspeksi perangkat lunak disebutkan untuk menguatkan penelitian lain.
Informasi tambahan dapat ditemukan di halaman Construx tentang Peningkatan Biaya Cacat , yang menyediakan sejumlah referensi tentang kenaikan biaya perbaikan cacat. Perlu dicatat bahwa Steve McConnell, penulis Code Complete, didirikan dan bekerja untuk Construx.
Saya baru-baru ini mendengarkan ceramah, Rekayasa Perangkat Lunak Nyata , yang diberikan oleh Glenn Vanderburg di Lone Star Ruby Conference pada 2010. Dia diberi ceramah yang sama di Scottish Ruby Conference dan Erubycon pada 2011, QCon San Francisco pada 2012 , dan O'Reilly Software Architecture Conference pada tahun 2015 . Saya hanya mendengarkan Konferensi Lone Star Ruby, tetapi pembicaraan telah berkembang seiring waktu ketika idenya disempurnakan.
Venderburg menyarankan bahwa semua data historis ini benar-benar menunjukkan biaya untuk memperbaiki cacat seiring berjalannya waktu, tidak harus ketika proyek bergerak melalui fase. Banyak proyek yang diperiksa dalam makalah dan buku yang disebutkan sebelumnya adalah proyek "air terjun" berurutan, di mana fase dan waktu bergerak bersama. Namun, pola yang sama akan muncul dalam proyek iteratif dan tambahan - jika cacat disuntikkan dalam satu iterasi, itu akan relatif murah untuk diperbaiki dalam iterasi itu. Namun, seiring dengan kemajuan iterasi, banyak hal terjadi - perangkat lunak menjadi lebih kompleks, orang melupakan beberapa detail kecil tentang bekerja dalam modul atau bagian tertentu dari kode, persyaratan berubah. Semua ini akan meningkatkan biaya memperbaiki cacat.
Saya pikir ini mungkin lebih dekat dengan kenyataan. Dalam proyek air terjun, biaya meningkat karena jumlah artefak yang perlu diperbaiki karena masalah hulu. Dalam proyek berulang dan tambahan, biaya meningkat karena peningkatan kompleksitas dalam perangkat lunak.