ESTIMASI BIAYA PERANGKAT LUNAK

Sebuah proyek dikatakan berhasil apabila sistem tersebut bisa diserahkan tepat waktu, sesuai antara biaya dan kualitas yang diinginkan. Hal tersebut menandakan bahwa apa yang ditargetkan manajer proyek telah bisa dicapat. Meski target yang dibuat manajer proyek masuk akal, tapi tidak memperhitungkan catatan level produktivitas timnya, kemungkinan tidak akan bisa memenuhi deadline dikarenakan estimasi awal yang salah. Oleh karenanya, perkiraan yang realistik menjadi kebutuhan yang sangat krusial bagi seorang manajer proyek. Beberapa kendala estimasi sangat dipengaruhi oleh karakteristik perangkat lunak (software), khususnya kompleksitas dan hal-hal lain yang tidak kasat mata. Juga kegiatan SDM yang terlibat dalam pengembangan sistem tidak bisa diperhitungkan secara pasti dengan menggunakan cara-cara yang mekanistik. Belum lagi kesulitan lain yang menghalangi keberhasilan proyek perangkat lunak, sepert :

1. Aplikasi perangkat lunak yang diusulkan : beberapa proyek mirip biasanya dikembangkan berdasarkan pengalaman sebelumnya. Padahal proyek perangkat lunak memiliki sifat yang unik sehingga sering ada hal-hal yang tidak terduga dan penuh ketidakpastian.
2. Perubahan teknologi : perubahan bahasa pemrograman yang digunakan bisa menghambat waktu selesainya proyek.
3. Kurang homoginnya pengalaman proyek : estimasi akan efektif bila dibuat berdasarkan proyek-proyek sebelumnya, hanya saja banyak perusahaan yang menyembunyikan data proyek-proyek sebelumnya dari para staf.
4. Subyektifitas estimasi : orang cenderung berlaku under-estimate terhadap kesulitan dari pekerjaan-pekerjaan kecil dan ber bertindak over-estime pada proyek-proyek besar yang dianggap lebih komplek dan sulit.
5. Implikasi Politik : kelompok berbeda dalam sebuah organisasi bisa memiliki tujuan berbeda. Manajer pengembang sistem informasi mungkin akan menekan pada bagian ‘estimator’ untuk mengurangi estimasi harga berdasarkan anjuran atasannya. Sedangkan pada bagian pemeliharaan berharap tidak terjadi pembengkaan biaya dan keterlambatan waktu penyerahan agar citranya tidak jelek. Sebagai jalan tengahnya, estimasi sebaiknya dibuat oleh tim khusus yang bersifat independen dari penngguna maupun tim proyek.

A. Dimana Estimasi Dilakukan ?

Estimasi bisa dilakukan pada tahapan yang berbeda dalam proyek perangkat lunak. Namun setiap tahap memiliki alasan dan metode estimasi yang berbeda-beda. Adapun tahapan dimana estimasi bisa dilakukan, antara lain :

1. Perencanaan Strategis (strategic planning)
2. Studi kelayakan (feasibility study)
3. Spesifikasi Sistem (system specification)
4. Evaluasi proposal supplier (evaluation of supplier’ proposals)
5. Perencanaan Poyek (project planning)

Dua hal yang perlu diperhatikan :

* Karena proyek sedang berjalan, akurasi estimasi harus bisa memperbaiki pengetahuan tentang peningkatan proyek aslinya.
* Pada awal proyek, kebutuhan user merupakan hal yang sangat penting, sehingga pertimbangan yang tergesa-gesa pada implementasi fisik harus dihindari.

B. Problema ‘Over-Estimate’ Dan ‘Under-Estimate’

Estimasi yang berlebihan bisa menyebabkan waktu penyelesaian proyek molor dari biasanya. Hal ini bisa dijelaskan menggunakan hukum :

* Parkinson’s Law : ‘work expands to fill the time available’. Bila staf diberi target yang mudah akan bekerja kurang keras.
* Hukum Brooks’ Law : ‘ Putting more people on a late job makes it later’. Biaya yang diperlukan untuk mewujudkan sebuah proyek akan meningkat secara tidak proporsional terhadap jumlah staf yang dipekerjakan. Bila estimasi biaya yang diperlukan berlebihan menyebabkan jumlah staf yang dialokasikan lebih banyak dari yang diperlukan dan overhead manajemen akan meningkat.

C. Dasar Estimasi Perangkat Lunak

1. Kebutuhan data historis : memerlukan informasi bagaimana proyek yang telah diimplementasikan sebelumnya, terutama bahasa pemrograman dan tool yang digunakan, standar yang dipakai dan pengalaman staf.
2. Metrik pekerjaan: biasanya tidak mungkin menghitung langsung harga aktual atau waktu yang diperlukan untuk merealisasikan proyek. Waktu yang dipakai untuk menulis program bisa berbeda sesuai kompetensidan pengalaman software developer. Secara praktis, untuk mengukur volume pekerjaan didasarkan pada jumlah source lines of code (SLOC) atau function points.
3. Kompleksitas : Telah banyak usaha yang dilakukan untuk mengukur kompleksitas secara obyektif, namun seringkali akan tergantung penilaian subyektif estimatornya.

D. Teknik-Teknik Estimasi Biaya Perangkat Lunak

* Algorithmic models : menggunakann ‘effort driver’ yang menggambarkan karakteristik dari sistem target dan lingkungan implementasi untuk memprediksi biaya.
* Expert judgement : dimana nasehat staf yang memiliki kemampuan sangat diharapkan
* Analogy : kemiripan, kelengkapan, proyek diidentifikasi dan biaya aktualnya digunakan sebagai dasar estimasi proyek baru.
* Parkinson : mengidentifikasi kelayakan biaya staf untuk mengerjakan proyek dan menggunakannya sebagai estimasi (bukan merupakan metode prediksi biaya yang sebenarnya).
* Price to win : estimasi harus kelihatan cukup rendah untuk memenangkan kontrak.
* Top-down: keseluruhan estimasi diformulasikan untuk keseluruhan proyek yang kemudian dipecah ke dalam usaha yang diperlukan untuk komponen-komponen tugas.
* Bottom-up : komponen-komponen tugas diidentifikasi, diukur dan dilakukan estimasi sendiri-sendiri untuk kemudian dijumlahkan

Estimasi Bottom-Up

Pendekatan bottom-up memecah proyek ke dalam komponen-komponen tugasnya dan kemudian menghitung berapa banyak biaya yang diperlukan untuk menyelesaikan setiap tugas tersebut. Untuk proyek besar, proses pemecahan akan berulang hingga mendapatkan komponen yang bisa dieksekusi oleh satu orang selama 1 hingga 2 minggu. Setiap komponen tugas dianalisa hingga komponen sub tugasnya, yang menghasilkan Work Breakdown Schedule (WBS). Bagian bottom-up muncul ketika terjadi penjumlahan biaya yang dihitung dari setiap aktifitas untuk memperoleh estimasi keseluruhan. Pendekatan ini lebih cocok digunakan di bagian akhir tahap perencanaan proyek. Jika digunakan pada awal siklus proyek, beberapa karakteristik sistem final harus diasumsikan.

Pendekatan Top-Down dan Model Parametrik

Pendekatan top-down normalnya dihubungkan dengan dengan model parametric (algoritma). Biaya yang diperlukan untuk implementasi proyek akan dikaitkan terutama dengan variabel yang berhubungan karakteristik sistem final. Bentuk dari model parametrik biasanya berupa satu atau lebih formula dalam bentuk :

Effort = (system size) x (productivity rate) …….(1)

Suatu model untuk memperkirakan biaya pengembangan perangkat lunak memiliki 2 komponen utama. Pertama, metode untuk menaksir ukuran pekerjaan pengembangan perangkat lunak (software) dan menaksir laju pekerjaan yang berhasil dikerjakan. Beberapa model parametrik (seperti Function Point ) berfokus pada sistem maupun ukuran pekerjaan, sementara metode lain (seperti COCOMO) lebih berkonsentrasi pada faktor produktifitas.

E. Experd Judgement

Metode ini digunakan ketika melakukan estimasi biaya yang diperlukan untuk mengubah sebagian software yang masih eksis. Estimator akan memberikan beberapa analisis dampak berdasarkan pendapat yang proporsional dengan kode yang ditambahkan. Seseorang yang telah terbiasa dengan software tersebut yang lebih tepat untuk mengerjakannya.

F. Estimasi Dengan Analogi

Penggunaan analogi disebut juga case-based reasoning. Estimator mencari proyek-proyek yang telah selesai dikerjakan (sumber) yang memiliki karakteristik hampir sama untuk referensi proyek baru (target). Biaya yang telah dilaporkan yang sesuai dengan kasus sumber dapat dijadikan pijakan estimasi proyek target. Estimator kemudian melakukan identifikasi perbedaan sistem target dengan sumber, selanjutnya menetapkan estmasi dasar untuk menghasilakan estimasi biaya proyek baru. Masalahnya adalah bagaimana mengidentifikasi kemiripan dan perbedaan yang sesungguhnya pada aplikasi yang berbeda, khususnya bila ada banyak proyek masa lampau sebagai gambaran. Untuk mengidentifikasi sumber yang paling dekat dengan target biasanya menggunakan ukuran jarak Euclidian :

Distance = square-root of ((target_parameter1 – source_parameter1)2 + …. + (target _parametern – source_parametern)2) …….(2)

G. Albrecht Function Point Analysis

Albrecht telah melakukan investigasi terhadap produktifitas pemrograman dan diperlukan beberapa cara menghitung ukuran fungsional program yang independen terhadap bahasa pemroghraman yang telah dikodekan. Ide yang dikembangkan disebut function pont (FP). Dasar analisa function point adalah lima komponen utama (external user type) :

* External input type : transaksi input untuk meng-update file komputer internal.
* External output type : transaksi data yang di-outputkan ke user, khususnya print-out laporan dan tidak termasuk yang di-displaykan ke layar monitor (termasuk external inquiry type)
* Logical internal file type : file yang dipakai oleh sistem, berupa grup data yang biasanya dipakai bersama-sama.
* External interface file type : mengikuti input dan output yang melewatkan aplikasi dari dan ke komputer lain.
* External inquire type : transaksi yang diajukan oleh user yang memberikan informasi tetapi tidak meng-update file internal.