Waktu yang dihabiskan untuk kebutuhan dan pengaruhnya terhadap keberhasilan proyek dan waktu pengembangan

Adakah bukti yang menunjukkan bahwa waktu yang dihabiskan untuk menulis, atau memikirkan persyaratan akan berpengaruh pada waktu pengembangan? Studi yang dilakukan oleh Standish (1995) menunjukkan bahwa persyaratan yang tidak lengkap sebagian (13,1%) berkontribusi pada kegagalan proyek. Adakah penelitian yang dilakukan yang menunjukkan bahwa waktu yang dihabiskan untuk analisis kebutuhan akan berdampak pada waktu pengembangan suatu proyek, atau seberapa sukses proyek tersebut.

software-engineering

— Ken Li
sumber

Bagaimana model tangkas cocok di sini? Orang dapat berargumen bahwa mereka menghabiskan waktu persyaratan (hidup dan mati) tetapi tidak ada persyaratan "fase" seperti itu.

— Raphael

Setuju dengan @Raphael. Apakah kita akan menjawab pertanyaan tentang rekayasa perangkat lunak? Atau apakah kebijakan resmi situs yang tidak layak untuk membedakan antara "ilmu komputer" dan "rekayasa perangkat lunak" pada saat ini?

— Patrick87

@ Patrick87 Mari kita pindahkan ini ke meta .

— Raphael

Tampaknya bagi saya bahwa pertanyaan ini akan lebih cocok untuk situs Rekayasa Perangkat Lunak dan Manajemen Proyek yang ada .

— Adam Lear

Jawaban:

Lihat Kode Lengkap, Oleh Steve McConnell, Tabel 3-1. Dia membandingkan biaya rata-rata perbaikan cacat berdasarkan pada saat diperkenalkan dan terdeteksi. Deteksi pada waktu konstruksi memakan biaya 5-10 kali lebih banyak daripada deteksi pada waktu persyaratan, dan 10-100 kali lebih banyak setelah rilis.

Tabel ini didasarkan pada sumber-sumber berikut:

"Desain dan Inspeksi Kode untuk Mengurangi Kesalahan dalam Pengembangan Program" (Fagan 1976)
Penghapusan Cacat Perangkat Lunak (Dunn 1984)
"Peningkatan Proses Perangkat Lunak di Hughes Aircraft" (Humphrey, Snyder, dan WIllis 1991)

dan beberapa lainnya

— Joe
sumber

Itu saja tidak cukup. Kesalahan mahal harus terjadi cukup sering dan harus cukup sering ditangkap dengan mengajukan persyaratan yang tepat. Jika tidak, biaya tambahan untuk membuat persyaratan mungkin masih lebih besar daripada biaya kesalahan.

— Raphael

Itu benar. Kita harus mengasumsikan bahwa sampai titik tertentu, tidak terburu-buru pada persyaratan berarti bahwa ada lebih sedikit kesalahan dalam persyaratan, tetapi itu tidak tampak seperti terlalu banyak peregangan.

— Joe

Ya, ada banyak penelitian tentang topik ini. Tentu saja, pertanyaannya terlalu umum untuk dijawab untuk semua jenis proyek pengembangan perangkat lunak, tetapi ada bukti dari beberapa konteks yang mendukung gagasan bahwa melakukan analisis persyaratan dengan benar akan berdampak positif pada tahap implementasi. Bukti ini sebagian telah dikumpulkan menjadi "undang-undang", dan berikut adalah tiga contoh:

Hukum Glass: Defisiensi persyaratan adalah sumber utama kegagalan proyek.

Undang-undang ini didukung oleh bukti studi kasus dari proyek pengembangan perangkat lunak besar. Glass menemukan bahwa dalam kasus yang gagal, ada terlalu banyak persyaratan, mereka tidak stabil karena perubahan yang terlambat, dan mereka ambigu dan tidak lengkap.

Ini menunjukkan bahwa ada hubungan antara kualitas persyaratan dan hasil proyek.

Hukum pertama Boehm: Kesalahan paling sering terjadi selama persyaratan dan aktivitas desain dan semakin mahal setelah dihapus.

Ini juga didukung oleh bukti studi kasus dan berkontribusi untuk menjawab pertanyaan dengan cara berikut: melakukan persyaratan dengan benar akan mengurangi jumlah kesalahan dalam sistem, dan memperbaiki kesalahan sebelum memulai implementasi akan lebih murah daripada memburu mereka. turun ketika implementasi sudah dimulai (atau lebih buruk, ketika sistem sudah dikirim).

Hukum kedua Boehm: Prototyping (secara signifikan) mengurangi kesalahan persyaratan dan desain, terutama untuk antarmuka pengguna.

Ini didukung oleh percobaan terkontrol dalam konteks siswa. Salah satu interpretasi yang mungkin adalah bahwa persyaratan dan fase desain tidak perlu sepenuhnya didorong oleh dokumentasi dan teoritis. Sebaliknya, melakukan prototyping sebagai bagian dari persyaratan dan fase desain - yang berarti menghabiskan waktu dan memikirkan persyaratan - akan mempengaruhi keberhasilan proyek dan waktu implementasi.

Ada juga banyak bukti lain yang menunjuk ke arah yang sama: menghabiskan waktu untuk mempersiapkan implementasi terbayarkan dalam bentuk risiko yang lebih sedikit dan lebih sedikit kemungkinan jadwal yang dikuasai karena kejutan. Meskipun pertanyaannya bukan tentang pengujian, persiapan yang tepat juga memengaruhi pengujian.

Referensi untuk undang-undang ini adalah:

Hukum Glass: Kaca, RL: Pelarian Perangkat Lunak. Pelajaran dari Kegagalan Proyek Perangkat Lunak Massive. Upper Saddle River, NJ: Prentice Hall 1998

Hukum pertama Boehm: Boehm, BW, McClean, RK, Urfrig, DB: Beberapa Pengalaman dengan Alat Bantu Otomatis untuk Desain Perangkat Lunak Skala Besar yang Andal. IEEE Trans pada Rekayasa Perangkat Lunak 1, 1 (1975), 125–133

Hukum kedua Boehm: Boehm, BW, Grey, TE, Seewaldt, T .: Prototyping vs. Menentukan: Eksperimen Banyak Proyek. IEEE Trans pada Rekayasa Perangkat Lunak 10, 3 (1984), 290-302

Juga, referensi berikut mungkin menarik: Endres, A. dan Rombach, D. Buku Pegangan Rekayasa Perangkat Lunak dan Sistem. Pengamatan Empiris, Hukum dan Teori. Seri IESE Fraunhofer tentang Rekayasa Perangkat Lunak. Addison Wesley, 2003.

— Fabian Fagerholm
sumber