MN232 - Manajemen Proyek Piranti Lunak Pertemuan : ESTIMASI

Transkripsi

1 Pokok Bahasan Sejarah estimasi. Proses estimasi. Ukuran estimasi. Estimasi usaha. Estimasi jadwal. Sulitnya estimasi usaha. Penghalusan estimasi. ESTIMASI Sejarah estimasi. Isu - Beberapa estimasi dilakukan secara cermat, sebagian dilakukan sembarangan. - Kebanyakan proyek meleset %, hanya sebagian kecil yang meleset 10%.Yang meleset 5% belum pernah ada. - Ketepatan dalam estimasi adalah bagian yang penting sebagai dasar penetapan kecepatan pengembangan. - Estimasi adalah pekerjaan yang sulit, karena mengandung ketidak-pastian. Latar belakang estimasi. Gambar 8.1 Pengembangan S/W adalah proses penghalusan. Tingkat akurasi yang biasa dapat diterima oleh pihak manajemen adalah 10% dari estimasi anggaran. Penghalusan konsep dimulai dari pernyataan kebutuhan, rancangan awal, dan seterusnya hingga pemrograman. Project Project Cost Schedule (effort and size) 1.6 4x 2x Initia produ definitio Approv Requireme produ definitio Produ specificati desig specificati Gambar 8.2 Detaile desig specificati on Produ complet

2 Beberapa pertanyaan yang dapat dipakai pada proses penghalusan : - Apakah pemakai / pelanggan butuh fungsi tertentu? - Apakah dia butuh fungsi tadi harganya murah atau mahal? - Bila sekarang dia butuh yang murah apakah nantinya mau yang mahal? - Bagaimana fungsi tersebut dirancang? - Sampai tingkatan mana kualitas fungsi tersebut? - Berapa lama untuk me-debug dan mengoreksi error? - Berapa lama untuk memadukan fungsi tersebut dengan fungsi lainnya? - Gambar 8.2 diatas menunjukkan susahnya melakukan estimasi untuk mengembangkan perangkat lunak. Rangkuman estimasi dari gambar 8.2 adalah : Usaha & Ukuran Jadwal Fasa Optimistik Pesimistik Optimistik Pesimistik Konsep awal Konsep disetujui Spesifikasi kebutuhan Spesifikasi rancangan Spesifikasi Rancangan Rinci Estimasi vs Kendali. Kebanyakan pelanggan perangkat lunak awalnya membutuhkan sesuatu lebih dari yang sebenarnya mereka butuhkan. Features are bent to match available resources Resources sre bent to match desired features Produc Size Initially feature Initially resource Produc Feature Size Resource Initially feature Initially resource Feature Resource Evolution of Project Evolution of Project Gambar 8.3 Pengembang perangkat lunak selalu dihadapkan pada pilihan antara keakurasian estimasi dengan kendali proyek.

3 Kerjasama. Perlu disampaikan kepada pemakai di tahap mana saja pengembang dapat melakukan estimasi dengan cukup akurat. Pemakai perlu diberitahu tindakan / kegiatan selanjutnya. Strategi yang akan dipakai untuk melaksanakan kegiatan tsb. Bila ada perubahan dari kebutuhan, rancangan awal-rinci, termasuk perubahan anggaran. Dekatkan estimasi dengan kenyataan. Bila pemakai ingin mempercepat, hindarkan pengembang dari kesalahan estimasi yang terlalu rendah atau memberikan estimasi yang menyesatkan. Estimate too low : cost higher due to planning inefficiencies and mistakes Actual Schedule Minimu actua schedul Estimate too high : cost higher due to Parkinson's law Actual schedule = Estimated Estimated Schedule Gambar 8.4 Target pimpro adalah mencoba melakukan estimasi yang tepat dan sesuai anggaran. Dalam melakukan estimasi perhatikan : 1. Tidak ada yang dapat menentukan dengan tepat berapa biaya yang akan dikeluarkan kecuali dapat tepat mengetahui apa yang dikehendaki. 2. Bila ingin buat anggaran, buatlah karakteristik produk yang lentur. 3. Proses pengembangan adalah penghalusan bertahap. 4. Estimasi dapat diperhalus seiring dengan pelaksanaan proyek. 5. Bedakan pengertian akurasi dengan presisi. Akurasi :seberapa dekat dengan tetapan tertentu. misal : 3 adalah lebih akurat dibandingkan 4 dalam merepresentasikan Pi (π). Presisi :seberapa signifikan angka digit sebuah pengukuran. misal : 3,14 lebih presisi dibanding 3 dalam merepresentasikan Pi (π). Pada estimasi perangkat lunak, kesalahan presisi merupakan musuh dari akurasi. Proses estimasi.

4 Proses untuk mencapai keakuratan dalam menjadwal pengembangan : 1. Estimasikan ukuran dari produk (jumlah baris program atau function point). 2. Estimasikan effort (man-months). 3. Estimasi jadwal (calender-months). 4. Sajikan estimasi yang didapat dalam rangkuman & secara periodik di perbaiki. Estimasi ukuran. Dapat diukur melalui beberapa cara: 1. Menggunakan pendekatan algoritma. misal: function points (lihat box hal.175 ). 2. Berdasar deskripsi program (layar, dialog, files, tabel database, dsb). 3. Bandingkan dengan proyek sejenis bila telah punya pengalaman. Estimasi menggunakan function points. Digunakan pada awal proyek. Lebih mudah mendasarkan dari spesifikasi kebutuhan. Jumlah function point pada sebuah program dilihat dari jumlah dan kompleksitas setiap item berikut : - Input - Output - Inquiries - Logical Internal files - External Interface files Kalikan jumlah function point dengan faktor yang terdapat pada tabel berikut: Function-Point Multipliers Function Points Program Low Medium High Characteristic Complextly Complextly Complextly Number of inputs x 3 x 4 x 6 Number of outputs x 4 x 5 x 7 Inquiries x 3 x 4 x 6 Logical internal files x 7 x 10 x 15 External interface files x 5 x 7 x 10 Tabel 8.2 Contoh :

5 Example of Computing the Number of Function-Point Function Points Program Low Medium High Characteristic Complextly Complextly Complextly Number of inputs 6 x 3 = 18 2 x 4 = 8 3 x 6 = 18 Number of outputs 7 x 4 = 28 7 x 5 = 35 0 x 7 = 0 Inquiries 0 x 3 = 0 2 x 4 = 8 4 x 6 = 24 Logical internal files 5 x 7 = 35 2 x 10 = 20 3 x 15 =45 External interface files 9 x 5 = 45 0 x 7 = 0 2 x 10 = 20 Unadjusted function-point total 304 Influence multiplier 1.15 Adjusted function-point total 350 Tabel 8.3 Perhatikan : Influence Multiplier berkisar antara 0,65 1,35. Estimasi usaha (Effort Estimation). Cara merubah estimasi ukuran ke estimasi usaha,ada beberapa : Gunakan perangkat lunak estimasi untuk merubah estimasi ukuran ke estimasi usaha. Menggunakan tabel seperti berikut :

6 Shortest Possible Schedules Systems Products Business Products Shrink-Wrap Products Effort Effort Effort System Size Schedule (man- Schedule (man- Schedule (man- (lines or code) (months) months) (months) months) (months) months) 10, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,400 Tabel 8.8,8.9 & 8.10 Menggunakan data historis perusahaan, bukan dari ingatan seseorang. Menggunakan algoritma CoCoMo (Construction Cost Model) atau Putnam & Myers Life Cycle Model. Estimasi Jadwal. Secara kasar lamanya proyek dapat dihitung melalui rumus: Lama proyek= 3.0 Man-Months 1/3 Contoh : Proyek yang punya estimasi usaha: 65 Man-months,maka lama proyek = /3 = 12 bulan Besar tim pengembang = 5 atau 6 orang. Bandingkan dengan perhitungan bila pakai tabel 8.1. Sulitnya estimasi usaha. Tabel 8.8 s/d 8.10 menjelaskan 3 jenis proyek: systems software, business software dan shrinkwrap software.bila perangkat lunak yang dibuat tidak sepenuhnya masuk

7 kepada 3 katagori tersebut, lakukan penguraian berdasar persentase kandungan kemiripannya dengan 3 katagori tersebut. Jadwal. - Dihitung berdasar calender-months. - Termasuk untuk rancangan, konstruksi dan pengujian. - Tidak termasuk waktu untuk menentukan spesifikasi kebutuhan. - Cukup 1 atau 2 angka di belakang koma. Effort / Usaha. - Usaha pengembangan dihitung dengan man-months (boleh sampai 2 digit di belakang koma). - Dapat mudah menentukan rata-rata besarnya tim pengembangan. - Ingat Parkinson Law. Ukuran sistem. Satuannya adalah lines of code, tidak termasuk comment statement. Proyek skala kecil. - Tabel diatas tidak menyediakan proyek yang source codenya lebih kecil dari baris. - Proyek tersebut biasanya dapat diselesaikan oleh 1 orang. - Tergantung dari kemampuan orang tersebut. Jumlah baris code. - Sebagai dasar pengukur besarnya proyek. - Banyak pakar mengusulkan untuk diganti dengan function points. Akurasi dari estimasi. - Dengan menggunakan tabel, memudahkan estimator. - Pemakaian dengan tabel di kritik karena menyederhanakan masalah. Penghalusan estimasi. Menghaluskan estimasi berarti menghaluskan definisi proyek tersebut yaitu memperbaiki spesifikasi kebutuhan, rancangan produk, dst. Contoh : Single-Point-Estimation. Example of a Single-Point-Estimation History Point in Project Estimate (man-months) Initial product concept 100 Approved product concept 100 Requirements specification 135 Product design specification 145 Detailed design specification 160 Final 170 Tabel 8.11 Contoh : Range-Estimation.

8 Example of a Range-Estimation History Point in Project Estimate (man-months) Initial product concept Approved product concept Requirements specification Product design specification Detailed design specification Final 170 Tabel 8.12