Estimasi sumber daya, biaya, dan jadwal untuk upaya rekayasa perangkat lunak membutuhkan pengalaman, akses ke informasi historis yang baik, dan keberanian untuk berkomitmen pada prediksi kuantitatif ketika hanya ada informasi kualitatif yang tersedia. Estimasi membawa risiko dan risiko ini mengarah pada ketidakpastian. Kompleksitas proyek memiliki efek yang kuat pada ketidakpastian yang melekat dalam perencanaan. Ukuran proyek adalah faktor penting lain yang dapat mempengaruhi keakuratan dan kemanjuran perkiraan. Dengan meningkatnya ukuran, hubungan saling ketergantungan antara berbagai elemen perangkat lunak tumbuh dengan cepat.

Tujuan dari perencanaan proyek perangkat lunak adalah untuk menyediakan kerangka kerja yang memungkinkan manajer untuk membuat estimasi sumber daya, biaya, dan jadwal yang masuk akal. Perkiraan ini dibuat dalam kerangka waktu terbatas pada awal proyek perangkat lunak dan harus diperbarui secara teratur seiring kemajuan proyek. Selain itu, perkiraan harus berupaya untuk menentukan skenario terbaik dan skenario terburuk sehingga hasil proyek dapat dibatasi. Tujuan perencanaan dicapai melalui proses penemuan informasi yang mengarah pada perkiraan yang masuk akal.

SOFTWARE SCOPE

Aktivitas pertama dalam perencanaan proyek perangkat lunak adalah penentuan ruang lingkup perangkat lunak. Fungsi dan kinerja yang dialokasikan untuk perangkat lunak selama rekayasa sistem harus dinilai untuk menetapkan ruang lingkup proyek yang tidak ambigu dan dapat dipahami pada tingkat manajemen dan teknis. Pernyataan lingkup perangkat lunak harus dibatasi.

Lingkup perangkat lunak menggambarkan data dan kontrol untuk diproses, fungsi, kinerja, kendala, antarmuka, dan keandalan. Fungsi yang dijelaskan dalam pernyataan ruang lingkup dievaluasi dan dalam beberapa kasus disempurnakan untuk memberikan rincian lebih lanjut sebelum awal estimasi. Karena perkiraan biaya dan jadwal secara fungsional berorientasi, beberapa tingkat penguraian sering berguna. Pertimbangan kinerja mencakup persyaratan pemrosesan dan waktu respons. Constraints mengidentifikasi limit yang ditempatkan pada perangkat lunak oleh perangkat keras eksternal, memori yang tersedia, atau sistem lainnya yang sudah ada.

SOFTWARE PROJECT ESTIMATION

Pada hari-hari awal komputasi, biaya perangkat lunak merupakan persentase kecil dari keseluruhan biaya sistem berbasis komputer. Urutan kesalahan besarnya dalam taksiran biaya perangkat lunak memiliki dampak yang relatif kecil. Saat ini, perangkat lunak adalah elemen paling mahal dari hampir semua sistem berbasis komputer. Untuk sistem kustom yang rumit, besar kesalahan estimasi biaya dapat membuat perbedaan antara laba dan rugi. Kelebihan biaya dapat menjadi bencana bagi pengembang. Perkiraan biaya dan upaya perangkat lunak tidak akan pernah menjadi ilmu pasti. Terlalu banyak variabel (manusia, teknis, lingkungan, politik) dapat memengaruhi biaya akhir perangkat lunak dan upaya diterapkan untuk mengembangkannya. Namun, estimasi proyek perangkat lunak dapat ditransformasikan ke serangkaian langkah sistematis yang memberikan estimasi dengan risiko yang dapat diterima. Untuk mencapai perkiraan biaya dan upaya yang andal, sejumlah opsi muncul:

  1. Delay estimasi hingga akhir proyek
  2. Mendasarkan perkiraan pada proyek serupa yang telah selesai.
  3. Gunakan teknik dekomposisi yang relatif sederhana untuk menghasilkan biaya dan proyek estimasi upaya.
  4. Gunakan satu atau lebih model empiris untuk perkiraan biaya dan upaya perangkat lunak.

Opsi pertama tidak praktis karena perkiraan biaya harus disediakan “di muka.” Namun, kita harus menyadari bahwa semakin lama kita menunggu dan semakin banyak kita tahu, semakin kecil kemungkinan kita untuk membuat kesalahan serius dalam estimasi. Opsi kedua dapat bekerja dengan cukup baik, jika proyek saat ini sangat mirip dengan upaya masa lalu dan pengaruh proyek lainnya (mis., Pelanggan, kondisi bisnis, tenggat waktu) adalah setara. Sayangnya, pengalaman masa lalu tidak selalu menjadi indikator yang baik untuk hasil di masa depan. Opsi yang tersisa adalah pendekatan yang layak untuk estimasi proyek perangkat lunak. Idealnya, teknik yang dicatat untuk setiap opsi harus diterapkan bersama-sama; masing-masing digunakan sebagai cek silang untuk yang lain. Teknik dekomposisi mengambil “membagi dan menaklukkan” pendekatan untuk estimasi proyek perangkat lunak. Dengan menguraikan proyek menjadi fungsi utama dan kegiatan rekayasa perangkat lunak terkait, estimasi biaya dan upaya dapat dilakukan secara bertahap. Model estimasi empiris dapat digunakan untuk melengkapi teknik dekomposisi dan menawarkan estimasi yang berpotensi berharga pendekatan dalam hak mereka sendiri. Model didasarkan pada pengalaman (data historis) dan mengambil bentuk d = f(vi) dimana d adalah salah satu nilai yang diestimasi (effort, cost, durasi projek), dan vi adalah parameter independent yang dipilih (contoh: estimasi LOC atau FP).

Estimasi LOC dan FP adalah teknik estimasi yang berbeda. Namun keduanya memiliki sejumlah karakteristik yang sama. Project planner dimulai dengan pernyataan terbatas lingkup perangkat lunak dan dari pernyataan ini upaya untuk menguraikan perangkat lunak menjadi fungsi masalah yang masing-masing dapat diperkirakan secara individual. LOC atau FP (variabel estimasi) kemudian diperkirakan untuk setiap fungsi. Perencana dapat pilih komponen lain untuk ukuran seperti kelas atau objek, perubahan, atau proses bisnis yang terpengaruh.

Metrik produktivitas awal (mis., LOC / pm atau FP / pm9) kemudian diterapkan ke variabel estimasi yang sesuai, dan biaya atau upaya untuk fungsi diturunkan. Estimasi fungsi digabungkan untuk menghasilkan estimasi keseluruhan untuk keseluruhan proyek. Penting untuk dicatat, bagaimanapun, bahwa sering ada hamburan besar dalam metrik produktivitas untuk suatu organisasi, sehingga membuat penggunaan produktivitas dasar tunggal tersangka metrik.

Secara umum, rata-rata LOC / pm atau FP / pm harus dihitung oleh domain proyek. Artinya, proyek harus dikelompokkan berdasarkan ukuran tim, area aplikasi, kompleksitas, dan parameter terkait lainnya. Rata-rata domain lokal seharusnya dihitung. Ketika sebuah proyek baru diperkirakan, itu pertama-tama harus dialokasikan ke domain, dan kemudian rata-rata domain yang sesuai untuk produktivitas harus digunakan dalam menghasilkan estimasi.

Teknik estimasi LOC dan FP berbeda dalam tingkat detail yang diperlukan dekomposisi dan target partisi. Ketika LOC digunakan sebagai variabel estimasi, dekomposisi sangat penting dan sering dibawa ke tingkat detail yang cukup besar.

Contoh Estimasi Berbasis LOC

Sebagai contoh teknik estimasi berbasis masalah LOC dan FP, mari kita pertimbangkan paket perangkat lunak yang akan dikembangkan untuk aplikasi desain berbantuan komputer untuk komponen mekanis. Tinjauan Spesifikasi Sistem menunjukkan bahwa perangkat lunak akan dijalankan pada workstation teknik dan harus terhubung dengan berbagai peripheral grafis komputer termasuk mouse, digitizer, layar warna resolusi tinggi dan printer laser.

Menggunakan Spesifikasi Sistem sebagai panduan, pernyataan awal lingkup perangkat lunak dapat dikembangkan: Perangkat lunak CAD akan menerima data geometrik dua dan tiga dimensi dari insinyur. Insinyur akan berinteraksi dan mengontrol sistem CAD melalui antarmuka pengguna yang akan menunjukkan karakteristik desain antarmuka manusia / mesin yang baik. Semua geometris data dan informasi pendukung lainnya akan disimpan dalam basis data CAD. Modul analisis desain akan dikembangkan untuk menghasilkan output yang diperlukan, yang akan ditampilkan pada berbagai perangkat grafis. Perangkat lunak akan dirancang untuk mengontrol dan berinteraksi dengan perangkat periferal yang mencakup mouse, digitizer, printer laser, dan plotter.

Pernyataan ruang lingkup bersifat preliminary tidaklah dibatasi. Sebagai contoh, sebelum estimasi dapat dimulai, perencana harus menentukan “karakteristik apa yang baik desain antarmuka manusia / mesin ” cara atau ukuran dan kecanggihan “CAD database” yang harus dibuat. Untuk tujuan ini, kami mengasumsikan bahwa penyempurnaan lebih lanjut telah terjadi dan bahwa fungsi perangkat lunak utama berikut diidentifikasi:

  • User interface and control facilities (UICF)
  • Two-dimensional geometric analysis (2DGA)
  • Three-dimensional geometric analysis (3DGA)
  • Database Management (DBM)
  • Computer graphics display facilities (CGDF)
  • Peripheral control function (PCF)
  • Design analysis modules (DAM)

Mengikuti teknik dekomposisi untuk LOC, tabel estimasi, ditunjukkan pada gambar 1 dibawah ini dikembangkan. Berbagai perkiraan LOC dikembangkan untuk setiap fungsi. Untuk misalnya, kisaran perkiraan LOC untuk fungsi analisis geometris 3D optimis — 4600 LOC, kemungkinan besar — ​​6900 LOC, dan pesimistis — 8600 LOC.

Gambar 1. Tabel estimasi untuk metode LOC

Nilai yang diharapkan untuk fungsi analisis geometrik 3D adalah 6800 LOC. Perkiraan lain diperoleh dengan cara yang serupa. Dengan menjumlahkan secara vertikal dalam kolom LOC yang diestimasi, perkiraan 33.200 baris kode dibuat untuk sistem CAD. Tinjauan data historis menunjukkan bahwa produktivitas rata-rata organisasi untuk sistem jenis ini adalah 620 LOC / pm. Berdasarkan tingkat tenaga kerja yang dibebani $ 8000 per bulan, biaya per baris kode adalah sekitar $ 13. Berdasarkan estimasi LOC dan data produktivitas historis, total perkiraan biaya proyek adalah $ 431.000 dan upaya yang diperkirakan adalah 54 orang-bulan.12

Contoh Estimasi Berbasis FP

Dekomposisi untuk estimasi berbasis FP berfokus pada nilai-nilai domain informasi dari fungsi perangkat lunak. Mengacu pada tabel perhitungan titik fungsi yang disajikan pada gambar 2 dibawah ini. Perencana proyek memperkirakan input, output, pertanyaan, file, dan eksternal antarmuka untuk perangkat lunak CAD. Untuk keperluan estimasi ini, faktor bobot kompleksitas diasumsikan rata-rata. Gambar 2 dibawah menyajikan hasil estimasi ini. Setiap kompleksitas factor bobot diestimasi dan complexity adjustment factor dihitung.

Gambar 2. Estimating Information Domain Values

PROCESS BASED ESTIMATION

Teknik yang paling umum untuk memperkirakan suatu proyek adalah dengan mendasarkan estimasi pada proses yang akan digunakan. Artinya, prosesnya terurai menjadi relatif kecil serangkaian tugas dan upaya yang diperlukan untuk menyelesaikan setiap tugas diestimasi. Seperti teknik berbasis masalah, estimasi berbasis proses dimulai dengan penggambaran fungsi perangkat lunak yang diperoleh dari ruang lingkup proyek. Serangkaian perangkat lunak proses kegiatan harus dilakukan untuk setiap fungsi.

Fungsi dan aktivitas proses perangkat lunak terkait dapat direpresentasikan sebagai bagian dari table. Begitu fungsi masalah dan aktivitas proses dilebur, perencana memperkirakan upaya (mis., orang-bulan) yang akan diminta untuk menyelesaikan setiap proses perangkat lunak aktivitas untuk setiap fungsi perangkat lunak. Tarif tenaga kerja rata-rata (mis., Upaya biaya / unit) kemudian diterapkan pada upaya tersebut diperkirakan untuk setiap aktivitas proses. Sangat mungkin tingkat tenaga kerja akan bervariasi untuk setiap tugas. Staf senior yang sangat terlibat dalam kegiatan awal biasanya lebih mahal daripada junior staf yang terlibat dalam tugas desain selanjutnya, pembuatan kode, dan pengujian awal.

Biaya dan upaya untuk setiap fungsi dan aktivitas proses perangkat lunak dihitung sebagai langkah terakhir. Jika estimasi berbasis proses dilakukan secara independen dari LOC atau FP estimasi, kami sekarang memiliki dua atau tiga estimasi untuk biaya dan upaya yang dapat dibandingkan dan direkonsiliasi. Jika kedua set estimasi menunjukkan kesepakatan yang masuk akal, ada alasan yang baik untuk percaya bahwa estimasi tersebut dapat diandalkan. Sebaliknya, jika hasilnya teknik dekomposisi ini menunjukkan sedikit kesepakatan, penyelidikan lebih lanjut dan analisis harus dilakukan.

Gambar 3. Process-based Estimation Table

EMPIRICAL ESTIMATION MODELS

Model estimasi untuk perangkat lunak komputer menggunakan formula yang diturunkan secara empiris untuk memprediksi upaya sebagai fungsi LOC atau FP. Nilai untuk LOC atau FP diperkirakan menggunakan pendekatan Problem-based Estimation dan LOC based estimation. Nilai-nilai yang dihasilkan untuk LOC atau FP dimasukkan ke dalam model estimasi. Data empiris yang mendukung sebagian besar model estimasi berasal dari sampel proyek yang terbatas. Untuk alasan ini, tidak ada model estimasi yang sesuai untuk semua kelas perangkat lunak dan di semua lingkungan pengembangan. Oleh karena itu, hasil yang diperoleh dari model tersebut harus digunakan secara bijaksana.

THE MAKE/BUY DECISION

Dalam banyak bidang aplikasi perangkat lunak, seringkali lebih efektif untuk memperoleh biaya daripada mengembangkan perangkat lunak komputer. Manajer rekayasa perangkat lunak dihadapkan dengan keputusan membuat / membeli yang dapat menjadi lebih rumit dengan sejumlah opsi akuisisi: (1) perangkat lunak dapat dibeli (atau dilisensikan) di luar rak, (2) “pengalaman penuh” atau “komponen perangkat lunak partial-experience” dapat diperoleh dan kemudian dimodifikasi dan diintegrasikan untuk memenuhi kebutuhan spesifik, atau (3) perangkat lunak mungkin dibuat khusus oleh kontraktor luar untuk memenuhi spesifikasi pembeli.

Langkah-langkah yang terlibat dalam akuisisi perangkat lunak ditentukan oleh kekritisan perangkat lunak yang akan dibeli dan biaya akhirnya. Dalam beberapa kasus (mis., Perangkat lunak PC murah), lebih murah untuk membeli dan bereksperimen daripada melakukan evaluasi panjang paket perangkat lunak potensial. Untuk produk perangkat lunak yang lebih mahal,pedoman berikut dapat diterapkan:

  1. Kembangkan spesifikasi untuk fungsi dan kinerja perangkat lunak yang diinginkan.
    Tetapkan karakteristik yang terukur bila memungkinkan.
  2. Perkirakan biaya internal untuk pengembangan dan tanggal pengiriman.

3a. Pilih tiga atau empat kandidat aplikasi yang paling memenuhi spesifikasi Anda.

3b. Pilih komponen perangkat lunak yang dapat digunakan kembali yang akan membantu dalam membangun aplikasi yang dibutuhkan.

  1. Kembangkan matriks perbandingan yang menyajikan perbandingan kunci secara langsung fungsi. Atau, lakukan tes benchmark untuk membandingkan perangkat lunak kandidat.
  2. Evaluasi setiap paket perangkat lunak atau komponen berdasarkan kualitas produk masa lalu, dukungan vendor, arah produk, reputasi, dan sejenisnya.
  3. Hubungi pengguna perangkat lunak lain dan minta pendapat.

Dalam analisis akhir, keputusan membuat / membeli dibuat berdasarkan kondisi berikut: (1) Apakah tanggal pengiriman produk perangkat lunak akan lebih cepat daripada yang untuk perangkat lunak yang dikembangkan secara internal? (2) Akankah biaya perolehan ditambah biaya penyesuaian kurang dari biaya pengembangan perangkat lunak secara internal? (3) Apakah biaya dukungan luar (mis., Kontrak perawatan) lebih rendah dari biaya dukungan internal? Ketentuan ini berlaku untuk masing-masing opsi akuisisi.

MEMBUAT DECISION TREE

Langkah-langkah yang baru saja dijelaskan dapat ditambah menggunakan teknik statistik seperti analisis pohon keputusan. Seperti contoh, Gambar 4 dibawah ini menggambarkan pohon keputusan untuk sistem berbasis perangkat lunak, X. Dalam kasus ini, organisasi rekayasa perangkat lunak dapat:

  1. membangun sistem X dari awal,
  2. menggunakan kembali komponen “partial-experience” yang ada untuk membangun sistem
  3. membeli produk perangkat lunak yang tersedia dan memodifikasinya untuk memenuhi kebutuhan lokal, atau
  1. mengontrak pengembangan perangkat lunak ke vendor luar.
Gambar 4. Decision Tree untuk mendukung Make / Buy Decision

AUTOMATED ESTIMATION TOOLS

Teknik dekomposisi dan model estimasi empiris tersedia sebagai bagian dari beragam alat perangkat lunak. Alat estimasi otomatis ini memungkinkan perencana untuk memperkirakan biaya dan upaya dan untuk melakukan Analisis “bagaimana-jika” untuk variabel proyek penting seperti tanggal pengiriman atau penempatan staf. Meskipun banyak alat estimasi otomatis ada, semua menunjukkan karakteristik umum yang sama dan semua melakukan enam fungsi generik berikut:

  1. Ukuran hasil proyek. “Ukuran” dari satu atau lebih pekerjaan perangkat lunak produk diperkirakan. Produk kerja termasuk representasi eksternal dari perangkat lunak (mis., layar, laporan), perangkat lunak itu sendiri (mis., KLOC), fungsionalitas dikirimkan (mis., poin fungsi), informasi deskriptif (mis. dokumen).
  2. Memilih kegiatan proyek. Kerangka kerja proses yang sesuai dipilih dan set tugas rekayasa perangkat lunak ditentukan.
  3. Memprediksi tingkat kepegawaian. Jumlah orang yang akan tersedia untuk lakukan pekerjaan yang ditentukan. Karena hubungan antar orang tersedia dan kerja (usaha yang diprediksi) sangat nonlinier, ini merupakan input penting.
  4. Memprediksi upaya perangkat lunak. Alat estimasi menggunakan satu atau lebih model yang mengaitkan ukuran hasil proyek dengan upaya diperlukan untuk memproduksinya.
  5. Memprediksi biaya perangkat lunak. Mengingat hasil langkah 4, biaya dapat dihitung dengan mengalokasikan tarif tenaga kerja untuk kegiatan proyek yang dicatat dalam langkah 2.
  6. Memprediksi jadwal perangkat lunak. Ketika upaya, tingkat kepegawaian, dan proyek kegiatan diketahui, draft jadwal dapat dihasilkan dengan mengalokasikan tenaga kerja kegiatan rekayasa perangkat lunak berdasarkan model yang direkomendasikan untuk distribusi usaha.

REFERENSI

  • Sommervile, Ian. (2011). Software Engineering, 9th Pearson.
  • Pressman, R.S. (2015). Software Engineering: A Practioner’s 8th ed. McGraw-Hill Companies.Inc,
  • Trendowicz, Adam and Jeffery, Ross. (2014). Software Project Effort Estimation: Foundations and Best Practice Guidelines for Success.

Author : Yuliana Muksin, Kevin Yatshen, Maurice M. Tin, Leonardo A. Wijanto, Gary R. L. Tobing
Supervised by : Irma Kartika Wairooy, S.Kom., M.T.I