Apakah metodologi pengujian perangkat lunak mengandalkan data yang cacat?

Ini adalah fakta yang terkenal dalam rekayasa perangkat lunak bahwa biaya perbaikan bug meningkat secara eksponensial di kemudian hari dalam pengembangan bug yang ditemukan. Ini didukung oleh data yang diterbitkan dalam Kode Lengkap dan diadaptasi dalam berbagai publikasi lainnya.

Namun, ternyata data ini tidak pernah ada . Data yang dikutip oleh Code Complete ternyata tidak menunjukkan korelasi biaya / waktu pengembangan, dan tabel yang diterbitkan serupa hanya menunjukkan korelasi dalam beberapa kasus khusus dan kurva datar pada yang lain (yaitu tidak ada peningkatan biaya).

Apakah ada data independen untuk menguatkan atau membantah ini?

Dan jika benar (yaitu jika tidak ada data untuk mendukung biaya yang secara eksponensial lebih tinggi untuk bug yang ditemukan belakangan ini), bagaimana dampak metodologi pengembangan perangkat lunak ini?

Apakah metodologi pengujian perangkat lunak mengandalkan data yang cacat?

Ya, terbukti. Memeriksa Kurva Biaya Agile of Change menunjukkan bahwa bagian dari pekerjaan Kent Beck pada XP (saya tidak yakin apakah itu adalah bagian dari motivasi atau pembenarannya) adalah untuk "meratakan kurva" dari biaya cacat, berdasarkan pengetahuan tentang " kurva "eksponensial" yang terletak di belakang tabel Kode Lengkap. Jadi ya, bekerja pada setidaknya satu metodologi - metodologi yang paling banyak mempopulerkan pengembangan tes pertama - setidaknya sebagian didasarkan pada data yang cacat.

Apakah ada data independen untuk menguatkan atau membantah ini?

Ya, tentu saja ada data lain yang dapat Anda lihat - studi terbesar yang saya ketahui adalah analisis cacat yang dilakukan di Hughes Aircraft sebagai bagian dari program evaluasi CMM mereka . Laporan dari sana menunjukkan bagaimana biaya cacat tergantung pada fase untuk mereka : meskipun data dalam laporan itu tidak termasuk varians sehingga Anda harus berhati-hati dalam menarik terlalu banyak kesimpulan "hal ini lebih mahal daripada hal itu". Anda juga harus memperhatikan bahwa, terlepas dari metodologi, telah ada perubahan dalam alat dan teknik antara 1980-an dan hari ini yang menyebut relevansi data ini dipertanyakan.

Jadi, dengan asumsi kita masih memiliki masalah membenarkan angka-angka ini:

bagaimana dampak metodologi pengembangan perangkat lunak ini?

Fakta bahwa kita mengandalkan angka yang tidak dapat diverifikasi tidak menghentikan orang membuat kemajuan berdasarkan anekdot dan pengalaman: cara yang sama seperti yang dipelajari banyak perdagangan master-magang. Saya tidak berpikir ada Jurnal Masonry Berbasis Bukti selama abad pertengahan, tetapi sejumlah besar bangunan besar, mengesankan dan tahan lama dibangun dengan sejumlah keberhasilan yang dapat diamati. Maksudnya adalah bahwa kita terutama mendasarkan praktik kita pada "apa yang berhasil untuk saya atau orang yang saya temui"; tidak ada hal buruk, tetapi mungkin bukan cara yang paling efisien untuk meningkatkan bidang jutaan orang yang menyediakan landasan era teknologi saat ini.

Saya merasa mengecewakan bahwa dalam apa yang disebut disiplin teknik tidak memiliki dasar yang lebih baik dalam empirisme, dan saya curiga (meskipun jelas tidak dapat membuktikan) bahwa kita akan dapat membuat kemajuan yang lebih baik, lebih jelas dalam meningkatkan teknik dan metodologi kami. fondasi yang ada - sama seperti kedokteran klinis tampaknya telah diubah oleh praktik berbasis bukti. Itu didasarkan pada beberapa asumsi besar:

• bahwa hak milik sebagian besar praktik rekayasa perangkat lunak tidak mencegah pengumpulan data yang berguna dan relevan;
• bahwa kesimpulan yang diambil dari data ini secara umum dapat diterapkan (karena rekayasa perangkat lunak adalah profesi yang terampil, variasi pribadi dalam pengalaman, kemampuan dan selera dapat memengaruhi penerapan semacam itu);
• bahwa insinyur perangkat lunak "di lapangan" mampu dan termotivasi untuk memanfaatkan hasil yang diperoleh; dan
• bahwa kita sebenarnya tahu pertanyaan apa yang seharusnya kita tanyakan sejak awal. Ini jelas poin terbesar di sini: ketika kita berbicara tentang meningkatkan rekayasa perangkat lunak, apa yang ingin kita tingkatkan? Apa pengukurannya? Apakah meningkatkan pengukuran itu benar-benar meningkatkan hasil, atau apakah itu permainan sistem? Sebagai contoh, misalkan manajemen di perusahaan saya memutuskan kami akan mengurangi rasio antara biaya proyek aktual dan perkiraan biaya proyek. Saya hanya bisa mulai mengalikan semua perkiraan biaya saya dengan faktor fudge dan saya akan mencapai "tujuan" itu. Haruskah itu menjadi praktik standar industri untuk memperdaya semua perkiraan?

Bagi saya, jawaban untuk "bagaimana dampak metodologi pengembangan perangkat lunak ini" adalah "tidak banyak".

Apakah tertangkap oleh pengembang atau pengguna akhir, apakah dibutuhkan lebih banyak uang untuk memperbaikinya setelah ditangkap oleh pengguna atau tidak, faktanya tetap ada bug yang ditemukan dalam sistem. Jika ketahuan oleh pengembang, mudah - mudahan ini perbaikan cepat. Harapan yang sama berlaku untuk bug yang ditangkap oleh pengguna.

Terlepas dari biaya aktual pengembang untuk memperbaiki bug yang ditangkap oleh pengguna akhir, ada biaya tidak berwujud untuk mempertahankan stereotip yang dihisap oleh coders atas apa yang mereka lakukan. Ketika pengguna menemukan bug, itu adalah kesalahan pengembang. Oleh karena itu, setiap bug yang ditemukan pengguna akhir mengurangi kepercayaan pengguna terhadap sistem. Ini seperti berkeliling ke rumah yang ingin Anda beli, dan melihat noda air muncul di langit-langit di salah satu sudut rumah. Itu, dalam dirinya sendiri, adalah perbaikan yang mudah, tetapi Anda bertanya-tanya apa yang menyebabkannya, dan apa lagi yang disebabkan oleh root. Apa nilai ketenangan pikiran Anda? Anda mungkin harus merobohkan dinding kembali ke stud dan secara visual memeriksa semuanya untuk memastikan noda berasal dari insiden terisolasi yang telah diperbaiki. Mengetahui bahwa itu adalah suatu kemungkinan tidak membuat Anda sangat percaya diri di rumah. Demikian pula,

Biaya tidak berwujud ini dihindari semakin cepat bug ditangkap, yang merupakan tujuan dari metodologi gaya TDD. Bug yang tertangkap saat mengetik oleh pengembang atau mitra berpasangan, satu yang tertangkap pada waktu kompilasi, atau yang tertangkap oleh unit / pengujian integrasi (lapisan ditambahkan oleh TDD), adalah bug yang tidak pernah diketahui oleh pengguna, bahwa Anda manajer proyek tidak perlu meminta maaf, dan bahwa Anda tidak harus ditarik dari apa pun yang Anda lakukan saat ini juga untuk mengganti persneling menjadi mode memperbaiki kerusakan pada bagian sistem yang Anda pikir akan Anda tinggalkan minggu-minggu sebelumnya. lalu.

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.

Logikanya sederhana saja.

Kesalahan terdeteksi dalam spesifikasi.

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

Seperti yang dapat Anda lihat nanti, kesalahan terdeteksi, semakin banyak orang terlibat, semakin banyak pekerjaan yang harus dilakukan dan di lingkungan "normal" kertas apa pun dan birokrasi meningkat secara eksponensial setelah Anda menekan UAT.

Ini semua tanpa termasuk biaya bisnis yang mungkin timbul karena kesalahan dalam perangkat lunak produksi (kehilangan penjualan, pemesanan berlebihan, peretasan pelanggan, dll.)

Saya tidak berpikir ada orang yang pernah berhasil menulis sistem non-sepele yang tidak pernah memiliki bug dalam produksi, tetapi, apa pun yang dapat Anda lakukan untuk menangkap bug lebih awal akan menghemat waktu dan upaya Anda dalam jangka panjang. Ulasan spesifikasi, ulasan kode, pengujian unit yang luas, menggunakan coders yang berbeda untuk menulis tes, dll. Dll. Semuanya merupakan metode yang terbukti untuk menangkap bug lebih awal.

Saya percaya ini, dan selalu, tentang manajemen risiko dan ekonomi. Berapa biaya untuk mengurangi jumlah cacat vs nilai sekarang dari dampak cacat di masa depan. Lintasan burung kuning yang sedikit mati di Angry Birds tidak menyamakan lintasan dari rudal jelajah Tomahawk yang mati. Pengembang perangkat lunak di kedua proyek tidak dapat membuat keputusan berdasarkan tabel itu. Dalam hal ini, tidak ada yang berubah.

Cara saya pikir ini cenderung bekerja adalah melalui umpan balik, bug mahal di lapangan menyebabkan perusahaan memperketat proses kualitas mereka sementara tidak ada keluhan dari lapangan menyebabkan perusahaan untuk bersantai. Jadi seiring waktu perusahaan pengembangan perangkat lunak akan cenderung untuk berkumpul atau berosilasi di sekitar sesuatu yang bekerja untuk mereka (+/-). Kode Lengkap dapat memengaruhi beberapa nilai awal atau mungkin sedikit menarik perusahaan dengan satu atau lain cara. Sebuah perusahaan yang menghabiskan terlalu banyak upaya untuk menghilangkan cacat yang tidak akan diketahui oleh siapa pun mungkin akan kehilangan bisnisnya karena pesaing yang memiliki pendekatan yang lebih optimal. Di sisi lain, perusahaan yang mengeluarkan produk kereta juga akan gulung tikar.

Beberapa makalah yang relevan dari pencarian cepat (baca makalah lengkap, lakukan penelitian lebih lanjut, dan bentuk pendapat Anda sendiri):

Tinjauan Literatur Sistematik dari Penelitian Biaya Kualitas Perangkat Lunak (2011)

"Sementara masyarakat telah mengembangkan pemahaman yang baik tentang struktur domain penelitian, validasi empiris sering kurang. Hanya sekitar sepertiga dari artikel yang dianalisis menyajikan studi kasus atau hasil empiris yang lebih luas. Ini tampaknya tidak cukup untuk penelitian biaya kualitas perangkat lunak , yang sangat bergantung pada data kuantitatif untuk menghasilkan temuan baru. Oleh karena itu diperlukan pendekatan baru untuk mengumpulkan data biaya berkualitas, serta kerja sama yang lebih kuat antara industri dan penelitian untuk membuat data tersebut tersedia. "

Mengevaluasi Biaya Kualitas Perangkat Lunak (1998)

"Akhirnya, kita telah melihat bahwa penting untuk memantau kesesuaian perangkat lunak dan biaya ketidaksesuaian sehingga kebijakan kesesuaian dapat disesuaikan untuk mengurangi total biaya kualitas perangkat lunak."

Perilaku biaya cacat perangkat lunak (2004)

Abstrak ... "Penelitian saat ini mencoba untuk memperbarui pengetahuan kita tentang cara cacat dan biaya untuk memperbaikinya (atau sebagai alternatif, membiarkannya tidak terkoreksi) memengaruhi biaya akhir perangkat lunak" ... "cacat yang tidak dikoreksi menjadi lebih mahal secara eksponensial menjadi lebih mahal dengan setiap fase di mana mereka tidak terselesaikan "

Cakupan Tes dan Cacat Pasca Verifikasi: Studi Kasus Berganda (2009)

"Kami juga menemukan bahwa upaya pengujian meningkat secara eksponensial dengan cakupan uji, tetapi pengurangan masalah lapangan meningkat secara linier dengan cakupan uji. Ini menunjukkan bahwa untuk sebagian besar proyek tingkat cakupan optimal cenderung kurang dari 100%."

Menjembatani Kesenjangan antara Proses Uji Perangkat Lunak dan Nilai Bisnis: Studi Kasus (2009)

Saya tidak dapat menjawab bagian pertama dari pertanyaan Anda, karena saya belum memeriksa. Tapi saya bisa merumuskan jawaban untuk pertanyaan kedua Anda, dan mungkin mengisyaratkan kemungkinan jawaban untuk yang pertama.

Tidak perlu dikatakan bahwa beberapa faktor terpenting dalam biaya memperbaiki bug, yang secara intrinsik sulit untuk menggunakan alat pengembangan, adalah kompleksitas intrinsik produk, dan seberapa baik pengguna dapat memahami produk itu.

Berfokus sejenak pada kode, dengan asumsi bahwa kode biasanya ditulis dan dikelola oleh pengembang yang mampu menangani kompleksitas intrinsik kode mereka (yang mungkin tidak sepenuhnya benar dan mungkin pantas diperdebatkan sendiri), saya berani menyarankan bahwa dari kepentingan utama dalam pemeliharaan, dan dengan demikian dalam memperbaiki bug, adalah kemampuan pengelola untuk memahami kode tersebut.

Kemampuan untuk memahami kode sangat ditingkatkan dengan menggunakan alat rekayasa perangkat lunak yang terbukti, sayangnya, sebagian besar kurang atau tidak benar digunakan. Menggunakan tingkat abstraksi, modularitas, kohesi modul penambah yang tepat, dan mengurangi pemasangan modul adalah alat yang sangat penting dalam mengatasi kompleksitas yang membutuhkan penggunaan yang tepat. Pengkodean ke antarmuka, atau, dalam OOP, menghindari penggunaan yang berlebihan atas komposisi, pengemasan berdasarkan fitur, adalah beberapa teknik yang sering kurang diperhatikan dalam pengkodean.

Saya percaya bahwa kenyataan persaingan di industri ini memberikan kekuatan negatif pada penggunaan metode peningkatan kualitas untuk mengembangkan perangkat lunak, menjaga kualitas intrinsik perangkat lunak sebagai ukuran keberhasilan yang berkelanjutan.

Akibatnya, saya percaya bahwa, di industri, perangkat lunak cenderung lebih menderita karena biaya perbaikan bug yang semakin besar. Dalam produk tersebut, bug menjadi lebih sulit untuk diperbaiki dari waktu ke waktu karena sistem menjadi lebih sulit untuk dipahami seiring pertumbuhannya. Kekhawatiran yang diperkenalkan oleh masing-masing fitur terlalu digabungkan dengan masalah lain, membuat sulit dipahami. Atau, level abstraksi yang tepat tidak digunakan, sehingga sulit bagi pengelola untuk merumuskan model sistem yang tepat dan alasan tentangnya. Kurangnya dokumentasi tentu tidak membantu.

Ada beberapa pengecualian. Saya yakin Google tidak berfungsi dengan kecepatannya tanpa ada praktik solid yang didukung oleh pengembang bintang. Dan yang lain mungkin dalam situasi yang sama. Tetapi untuk sebagian besar perangkat lunak, saya tidak akan terkejut jika data benar -benar mengkonfirmasi klaim dalam Kode Lengkap .

Jawaban Lain! Kali ini untuk menjawab pertanyaan judul "Apakah perangkat lunak morhtodoligy mengandalkan data yang cacat".

Jawaban sebenarnya adalah "tidak ada data". Seperti di sana tidak ada tubuh besar data yang dapat diandalkan pada proyek-proyek perangkat lunak ada cacat, berhasil waktu ke pasar dll.

Semua upaya untuk mengumpulkan data semacam itu telah kekurangan dana, cacat secara statistik, atau, begitu spesifik untuk proyek tertentu, tidak mungkin diperoleh kesimpulan umum.

Lebih lanjut saya tidak berpikir akan pernah ada, proses pengembangan perangkat lunak terlalu subyektif dan licin untuk pengukuran yang ketat. Organisasi-organisasi yang paling baik ditempatkan untuk mengumpulkan data semacam itu (rumah-rumah perangkat lunak besar dan integrator sistem) tahu dalam hati mereka bahwa setiap angka yang dikumpulkan dari kinerja mereka akan sangat memalukan.

Satu-satunya organisasi yang mempublikasikan angka pada biaya dan keberhasilan proyek perangkat lunak
adalah departemen pemerintah, dan, hanya karena mereka harus melakukannya, dan, ya angka-angka ini sangat memalukan, tidak peduli seberapa besar mereka memijat angka-angka itu.

Jadi kesimpulannya semua studi perangkat lunak harus murni subjektif karena tidak ada data nyata yang menjadi dasar kesimpulan objektif.