1. OBSERVASI PADA ESTIMASI
Estimasi yang diperlukan dalam perancangan proyek
perangkat lunak di antaranya adalah sumber daya, biaya, dan jadwal sebagai
usaha dalam pengembangan perangkat lunak, mengakses informasi historis yang
baik, dan keberanian untuk melakukan pengukuran kuantitatif bila hanya data
kualitatif saja yang ada. Berikut adalah yang menimbulkan ketidakpastian dalam
estimasi :
– Project complexity (kompleksitas proyek)
berpengaruh kuat terhadap ketidakpastian yang inheren dalam perencanaan.
Komplekitas ini merupakan pengukuran relatif yang dipengaruhi oleh kebiasaan
dengan usaha yang dilakukan sebelumnya. – Project size (Ukuran proyek)
Merupakan faktor penting yang dapat mempengaruhi akurasi estimasi. Bila ukuran
bertambah maka ketergantungan di antara berbagai elemen perangkat lunak akan
meningkat dengan cepat.
– Structural uncertainty (Ketidakpastian
struktural) Tingkat ketidakpastian strutural juga berpengaruh dalam risiko
estimasi. Dengan melihat kembali, kita dapat mengingat lagi hal-hal yang
terjadi dan dapat menghindari tempat-tempat dimana masalah muncul.
Risiko diukur melalui tingkat ketidakpastian pada
estimasi kuantitatif yang dibuat untuk sumber daya, biaya, dan jadwal.Bila ruang lingkup proyek atau syarat
proyek tidak dipahami dengan baik, maka risiko dan ketidakpastian menjadi
sangat tinggi. Perencana perangkat lunak harus melengkapi fungsi, kinerja, dan
definisi interface(yang diisikan ke dalam spesifikasi sistem). Pendekatan-pendekatan
rekayasa perangkat lunak modern (seperti model proses evolusioner) memakai
pandangan pengembangan yang interaktif. Dengan pandangan semacam ini
dimungkinkan untuk melihat estimasi dan merevisinya bila customer mengubah
kebutuhannya.
2. TUJUAN PERENCANAAN PROYEK
Tujuan perencanaan proyek perangkat lunak adalah
untuk menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat
estimasi yang dapat dipertanggungjawabkan mengenai sumber daya, biaya dan
jadwal. Tujuan perencanaan dicapai melalui suatu proses penemuan informasi yang
menunjuk ke estimasi yang dapat dipertanggungjawabkan.
3. RUANG LINGKUP PERANGKAT LUNAK
Penentuan ruang lingkup perangkat lunak merupakan
aktivitas pertama dalam perencanaan proyek perangkat lunak. Ruang lingkup perangkat
lunak menggabarkan fungsi, kinerja, batasan, interface dan reliabilitas. Fungsi
yang digambarkan dalam statmen ruang lingkup dievaluasi dan disaring untuk
memberikan awalan yang lebih detail pada saat estimasi dimulai. Pertimbangan
kinerja melingkupi pemrosesan dan kebutuhan waktu respon. Batasan ini
mengidentifikasi dari batas yang ditempatkan pada perangkat lunak oleh
perangkat keras eksternal, memori, atau sistem informasi yang ada.
3.1 MENCARI INFORMASI YANG DIBUTUHKAN UNTUK RUANG
LINGKUP
Teknik yang banyak dipakai secara umum untuk
menjembatani jurang komunikasi antara pelanggan dan pengembang serta untuk
memulai proses komunikasi adalah dengan melakukan pertemuan atau wawancara
pendahuluan. Gause & weinberg mengusulkan bahwa analis harus memulai dengan
mengajukan pertanyaan-pertanyaan bebas konteks, yaitu serangkaian pertanyaan
yang akan membawa pada pemahaman mendasar terhadap masalah, orang yang
menginginkan suatu solusi, sifat solusi yang diharapkan, dan efektivitas
pertemuan itu. Beberapa pertanyaan bebas konteks pada pelanggan yang meliputi
tujuan keseluruhan, serta keuntungan :
o Siapa di belakang permintaan
kerja ini?
o Siapa yang akan memakai
solusi ini?
o Apakah yang akan menjadi
keutungan ekonomi dari sebuah solusi yang sukses? o Adakah sumberdaya lain bagi
solusi ini?
Beberapa contoh pertanyaan yang memungkinkan
analis untuk memahami masalah lebih baik :
o Bagaimanakah anda menandai
output yang baik yang akan dimunculkan oleh sebuah solui yang baik?
o Masalah apa yang akan dituju
oleh solusi ini?
o Dapatkah anda memperlihatkan
atau menggambarkan lingkungan di mana solusi akan dipakai?
o Adakah batasan atau isu
kinerja khusus yang akan mempengaruhi cara pendekatan terhadap solusi?
Beberapa pertanyaan yang berfokus pada
efektivitas pertemuan :
o Apakah anda orang yang tepat
untuk menjawab pertanyaan ini? Apakah anda resmi?
o Apakah pertanyaan saya
relevan dengan problem yang anda punyai?
o Apakah saya terlalu banyak
pertanyaan?
o Apakah ada orang lain yang
dapat menyedikan informasi tambahan?
o Adakah sesuatu yang lain
yang dapat saya tanyakan kepada anda?
Bagian Question dan Answer hanya akan digunakan
untuk pertemuan pertama yang kemudian diganti dengan format pertemuan yang
mengkombinasikan elemen-elemen penyelesaian masalah, negoisasi, dan
spesifikasi. Sejumlah peneliti lepas mengembangkan pedekatan yang berorientasi
pada tim terhadap pengumpulan kebutuhan yang dapat deiterapkan untuk membangun
ruang lingkup sebuah proyek, yang disebut teknik spesifikasi aplikasi yang
teraplikasi (FAST)
4. SUMBER DAYA
Mengestimasi sumber daya yang dibutuhkan untuk
menyelesaikan usaha pengembangan perangkat lunak yang meliputi manusia,
komponen perangkat lunak, dan peranti perangkat keras/perangkat lunak. Piramida
di atas memperlihatkan sumber daya pengembangan sebagai sebuah piramid. Peranti
perangkat keras dan perangkat lunak berada pada fondasi dari piramida di atas
dan menyediakan infrastruktur untuk mendukung usaha pengembangan(lingkungan pengembang).
Dalam tingkat yang lebih tinggi terdapat komponen perangkat lunak reuseable –
blok bangungan perangkat lunak yang dapat mengurangi biaya pengembangan secara
dramatis dan mempercepat penyampaian. Dan di puncak terdapat sumber daya utama
yaitu manusia. Masing-masing sumber daya ditentukan dengan empat karakteristik
:
o Deskripsi sumber daya
o Statemen ketersediaan
o Waktu kronologis sumber daya diperlukan
o Durasi waktu sumber daya diaplikasikan
5.4.1 Sumber daya manusia
Perencanaan sumber daya manusia memulai dengan
mengevaluasi ruang lingkup serta memilih kecakapan yang dibutuhkan untuk
mnyelesaikan pengembangan. Baik posisi organisasi maupun specialty. Jumlah
orang yang diperlukan untuk sebuah proyek perangkat lunak dapat ditentukan
setelah estimasi usaha pengembangan dibuat.
5.4.2 Sumber daya perangkat lunak reusable
Kreasi dan penggunaan kembali blok bangunan
perangkat lunak yang seharusnya dikatalog menjadi referensi yang mudah,
distandarisasi untuk aplikasi yang mudah, dan divalidasi untuk integrasi yang
mudah. Ada empat kategori sumber daya perangkat lunak yang harus dipertimbngkan
pada saat perencanaan berlangsung, yaitu :
– Komponen off-the-self Perangkat lunak yang ada
dapat diperoleh dari bagian ketiga atau telah dikembangkan secara internal
untuk proyek sebelumnya.
– Komponen full-experience Spesifikasi, kode,
desain atau pengujian data yang sudah ada yang dikembangkan pada proyek yang
lalu yang serupa dengan perangkat lunak yang akan dibangun pada proyek saat
ini.
– Komponen partial-experience Aplikasi, kode,
desain, atau data pengujiaan yang ada pada proyek yang lalu yang dihubungkan
dengan perangkat lunak yang dibangun untuk proyek saat ini, tetapi akan membutuhkan
modifikasi substansial.
– Komponen baru Komponen perangkat lunak yang
harus dibangun oleh tim perangkat lunak khususnya adalah untuk kebutuhan proyek
sekarang .Lebih baik mengkhususkan syarat sumber daya perangkat lunak dari
awal. Dengan cara ini evaluasi teknis dari semua alternatif dapat dilakukan dan
akuisisi secara berkala dapat terjadi.
5.4.3 Sumber daya lingkungan
Lingkungan yang mendukung poyek perangkat lunak,
yang disebut juga software engineering environment (SEE), menggabungkan
perangkat lunak dan perangkat keras. Karena sebagian besar organisasi perangkat
lunak memiliki konstituen ganda yang memerlukan akses ke SEE, maka perencana
proyek harus menentukan jendela waktu yang dibutuhkan bagi perangkat keras dan
perangkat lunak serta membuktikan bahwa sember-sumber daya tersebut dapat
diperoleh. Pada saat sebuah sistem berbasis komputer akan direkayasa, tim
perangkat lunak mungkin membutuhkan akses ke elemen perangkat keras yang sedang
dikembangkan oleh tim rekayasa yang lain.
5.5 ESTIMASI PROYEK PERANGKAT LUNAK
Biaya perangkat lunak terdiri dari presentase
kecil pada biaya sistem berbasis komputer secara keseluruhan. Kesalahan estimasi
biaya yang besar dapat memberikan perbedaan antara keuntungan dan kerugian.
Estimasi proyek perangkat lunak dapat ditranformasi dari suatu seni yang
misterius ke dalam langkah-langkah yang sistematis yang memberikan estimasi
dengan risiko yang dapat diterima. Sejumlah pilihan untuk mencapai estimasi
biaya dan usaha yang dapat dipertanggung jawabkan :
1. Menunda etimasi sampai akhir proyek
2. Mendasarkan etimasi pada proyek-proyek yang
mirip yang sudah pernah dilakukan sebelumnya
3. Menggunakan “teknik dekomposisi” yang relatif
sederhana untuk melakukan estimasi biaya dan usaha proyek
4. Menggunakan satu atau lebih model empiris bagi
estimasi usaha dan biaya perangkat lunak.
Model estimasi empiris dapat digunakan untuk
melengkapi teknik dekomposisi serta menawarkan pendekatan estimasi yang secara
potensial berharga. Model berbasis pengalaman(data hitoris) dan berbentuk :
d=f(vi)
di mana d adalah satu dari sejumlah harga
estimasi(contoh : usaha, biaya,durasi proyek) dan vi adalah parameter
independen yang dipilih (seperti LOC dan FP yang diestimasi). Peranti estimasi
otomatis mengimplementasi satu atau lebih teknik dekomposisi atau model
empiris. Masing-masing pilihan estimasi biaya perangkat lunak yang dapat
dilakukan sama baiknya dengan data hitoris yang digunakan untuk menumbuhkan
estimasi.