Mengapa estimasi perangkat lunak seringkali salah?

Estimasi dibuat ketika informasi paling sedikit diketahui, persyaratan berubah, dan bias manusia cenderung ke arah optimisme; kerucut ketidakpastian (cone of uncertainty) menangkap seberapa lebar estimasi awal yang tak terhindarkan, itulah sebabnya rentang dan estimasi ulang lebih disukai daripada angka tunggal yang tetap.

Apakah story point hanya jam yang disamarkan?

Tidak. Story point menyatakan ukuran dan kompleksitas relatif daripada waktu absolut; dikombinasikan dengan kecepatan (velocity) tim yang diamati, mereka menghasilkan perkiraan, tetapi menyamakan satu poin dengan jumlah jam yang tetap merusak tujuan mereka untuk menangkap upaya relatif.

Estimasi dan Perencanaan Perangkat Lunak

Estimasi dan perencanaan perangkat lunak memprediksi upaya, biaya, jadwal, dan sumber daya yang akan dibutuhkan oleh suatu proyek perangkat lunak serta mengorganisir pekerjaan untuk menyelesaikannya dalam batasan-batasan tersebut.

Temukan Topik dengan PaperMindSegeraFind papers & topics

Tools & resources

Unduh salindia

Learn & explore

VideoSegera

Definition

Estimasi perangkat lunak adalah prediksi upaya, durasi, dan biaya yang dibutuhkan untuk mengembangkan atau memelihara perangkat lunak, dan perencanaan adalah pengorganisasian aktivitas, pencapaian (milestone), dan sumber daya untuk mencapai tujuan proyek dalam estimasi tersebut.

Scope

Topik ini mencakup ukuran-ukuran ukuran seperti baris kode dan function point; model biaya algoritmik seperti COCOMO; estimasi berdasarkan penilaian ahli, analogi, dan perencanaan poker; teknik pemecahan pekerjaan dan penjadwalan termasuk jalur kritis dan burndown; perencanaan tangkas (agile) dengan kecepatan (velocity) dan story point; serta penanganan ketidakpastian estimasi melalui rentang dan kerucut ketidakpastian (cone of uncertainty).

Core questions

Bagaimana ukuran perangkat lunak diukur untuk mendorong estimasi?
Bagaimana perbandingan metode algoritmik, analogi, dan penilaian ahli?
Bagaimana ketidakpastian direpresentasikan dan dikurangi seiring kemajuan proyek?
Bagaimana perencanaan tangkas (agile) dengan kecepatan (velocity) berbeda dari penjadwalan di awal?

Key theories

Model biaya algoritmik: Model seperti COCOMO menyatakan upaya dan jadwal sebagai fungsi terkalibrasi dari perkiraan ukuran dan pendorong biaya proyek, memberikan estimasi yang dapat diulang dan dapat disesuaikan dengan data historis.
Penentuan ukuran function point: Analisis function point menentukan ukuran perangkat lunak dengan menghitung dan memberi bobot komponen fungsionalnya secara independen dari bahasa implementasi, menyediakan masukan ukuran yang netral teknologi untuk estimasi.

Clinical relevance

Estimasi dan perencanaan yang realistis mendasari komitmen kepada pemangku kepentingan dan keputusan sumber daya; estimasi yang terlalu rendah secara kronis menyebabkan keterlambatan jadwal dan pembengkakan anggaran yang sering terjadi pada proyek perangkat lunak, sehingga metode yang disiplin dan pengakuan ketidakpastian secara eksplisit sangat penting.

Evidence & guidelines

Penelitian empiris tentang akurasi estimasi dan model seperti COCOMO II memberikan panduan berbasis bukti, dan penghitungan function point diatur oleh standar pengukuran ukuran fungsional IFPUG dan ISO/IEC.

History

Function point diperkenalkan oleh Albrecht pada akhir tahun 1970-an dan COCOMO oleh Boehm pada tahun 1981, memberikan dasar kuantitatif untuk estimasi; pekerjaan selanjutnya menyempurnakan model (COCOMO II), mempelajari bias estimasi, dan memperkenalkan metode penentuan ukuran relatif yang ringan untuk perencanaan tangkas (agile).

Debates

Estimasi versus gerakan tanpa estimasi (no-estimates movement): Beberapa praktisi tangkas (agile) berpendapat bahwa estimasi terperinci membuang-buang upaya dan bahwa pengiriman kecil yang stabil membuat perkiraan lebih andal daripada estimasi, sementara yang lain berpendapat bahwa estimasi tetap diperlukan untuk perencanaan dan komitmen; perdebatan ini bergantung pada konteks dan kebutuhan pemangku kepentingan.

Key figures

Barry Boehm
Allan Albrecht
Steve McConnell

Seminal works

boehm1981
albrecht1983
mcconnell2006

Frequently asked questions

Mengapa estimasi perangkat lunak seringkali salah?: Estimasi dibuat ketika informasi paling sedikit diketahui, persyaratan berubah, dan bias manusia cenderung ke arah optimisme; kerucut ketidakpastian (cone of uncertainty) menangkap seberapa lebar estimasi awal yang tak terhindarkan, itulah sebabnya rentang dan estimasi ulang lebih disukai daripada angka tunggal yang tetap.
Apakah story point hanya jam yang disamarkan?: Tidak. Story point menyatakan ukuran dan kompleksitas relatif daripada waktu absolut; dikombinasikan dengan kecepatan (velocity) tim yang diamati, mereka menghasilkan perkiraan, tetapi menyamakan satu poin dengan jumlah jam yang tetap merusak tujuan mereka untuk menangkap upaya relatif.