Perencanaan Proyek Software Pertemuan VIII
:: Outline 5.5. Estimasi proyek software 5.6. Software sizing 5.7. Estimasi berbasis problem 5.8. Estimasi berbasis proses 5.9. Estimasi Empiris COCOMO: Parametric model
5.5. Estimasi Proyek Software Untuk mendapatkan estimasi biaya dan effort yang bisa dipertanggung jawabkan, maka muncul sejumlah opsi : Estimasi didelay sampai dengan akhir proyek (estimasi biaya akurat 100% jika proyek selesai). Estimasi berdasarkan proyek serupa yang telah dikembangkan Gunakan teknik dekomposisi yang sederhana untuk menghasilkan biaya dan effort proyek tersebut. Gunakan satu atau beberapa model empiris untuk estimasi biaya dan effort software.
5.5. Estimasi Proyek Software TEKNIK DEKOMPOSISI Pendekatan dekomposisi : Dekomposisi problem Dekomposisi proses Sebelum estimasi dibuat, perencana software harus mengetahui ruang lingkup software yang akan dibangun dan kemudian membuat estimasi dari “ukurannya”.
5.6. Software Sizing Akurasi sistem proyek software ditentukan pada hal-hal sebagai berikut: Tingkatan dimana perencana telah dengan tepat mengestimasi ukuran produk yang akan dibuat. Kemampuan untuk menterjemahkan estimasi ukuran kedalam calender time, human effort dan biaya. Tingkat dimana perencanaan proyek mencerminkan kemampuan tim software. Stabilitas syarat produk dan lingkungan yang mendukung usaha pengembangan software.
5.6. Software Sizing Ada 4 pendekatan yang berbeda terhadap masalah penentuan “ukuran” : Fuzzy logic sizing Function Point sizing Standar component sizing Change Sizing
5.6. Software Sizing Fuzzy logic sizing menggunakan teknik fuzzy-logic (logika kabur). Planner harus mengidentifikasi : jenis aplikasi, besaran dalam skala kuantitatif, dan menyaringnya dalam rentang orizinil Walaupun pengalaman personal bisa digunakan, planner sebaiknya mengakses historis database proyek sehingga estimasi bisa dibandingkan dengan pengalaman aktual
5.6. Software Sizing Function Point sizing Planner melakukan estimasi karakteristik domain informasi (bab 4) yang meliputi (14) : jumlah orang yang dipakai, biaya dan lain- lain.
5.6. Software Sizing Standar component sizing Software dibentuk dari sejumlah component standart yang berbeda yang umum bagi area aplikasi tertentu. Contoh standar komponen untuk IS : subsystem, modules, screen report, interactive programs, batch program. LOC dan object level instructions. Perencana proyek mengestimasi keberadaan masing-masing komponen standar dan menggunakan data historis proyek untuk menentukan besarnya ukuran tiap-tiap komponen standar. Ex : untuk komponen “laporan”, diperkirakan 18. data historis 967 LOC Cobol per laporan. Berarti untuk komponen standart “laporan” = 17.000 LOC
5.6. Software Sizing Change Sizing Pendekatan ini digunakan pada saat sebuah proyek harus menggunakan software yang ada tetapi harus dimodifikasi. Planner mengestimasi jumlah dan tipe modifikasi. Misal: (reusable, adding code, change code, deleting code) yang harus diselesaikan.
5.7. Problem Based Estimation Selama estimasi proyek software, data LOC dan FP digunakan dalam 2 cara, : Sebagai estimation variable yang digunakan untuk mengukur masing- masing element software. Sebagai base line metric yang dikumpulkan dari proyek sebelumnya yang kemudian dikombinasikan dengan estimation variable untuk menentukan proyeksi biaya dan effornya.
5.7. Problem Based Estimation Contoh teknik estimasi LOC dan FP: Software yang akan dikembangkan Computer Aided Design (CAD) untuk komponen mekanis. Pertama, Pernyataan ruang lingkup : “software CAD menerima data geometri 2 dan 3 dimensi dari perekayasa. Perekayasa berinteraksi & mengontrol sistem CAD melalui interface pemakaiyang memperlihatkan karakteristik desain manusia-mesin yg baik. Semua data geometri & informasi disimpan pada database CAD. Modul analisa desain dikembangkan untuk memproduksi output yg ditampilkan ke berbagai perangkat grafik. Software akan dirancang untuk mengontrol dan berinteraksi dengan perangkat periferal termasuk mouse, digitizer, & printer lazer ”
5.7. Problem Based Estimation Kedua, fungsi – fungsi mayor yang terbentuk dari pernyataan ruang lingkup : Interface pemakai dan fasilitas kontrol (UICF) Analisis geometri 2 dimensi (2DGA) Analisis geometri 3 dimensi (3DGA) Manajemen database (DBM) Fasilitas tampilan grafis komputer (CGDF) Kontrol periferal (PC) Modul analisis desain (DAM)
5.7. Problem Based Estimation Tabel 5-3 Contoh LOC Based Estimation
5.7. Problem Based Estimation Contoh : untuk mendapatkan estimasi LOC 3D untuk geometric Analysis function : Optimistic : 4600 Most Likely : 6900 Pesimistic : 8600 Rumus expected value (EV) atau “three point” : EV =(Sopt+4Sm+Spess)/6 Jadi EV untuk 3DGA adalah = (4600+(4x6.900)+8600)/6 = 6800
5.7. Problem Based Estimation Berdasar data historis, produktifitas sistem seperti itu adalah: 620 LOC/pm labor rate : $ 8.000/month Cost/LOC : $ 13.00 (8000 / 620) Maka, total estimasi biaya proyek: $431.000 (33.200 * 13) dan estimasi effortnya: 54 person-month. (33.200 / 620)
5.7. Problem Based Estimation Tabel 5-1 Contoh FP-Based estimation
5.7. Problem Based Estimation Tabel 5-2 Estimasi information domain Values
5.7. Problem Based Estimation Akhirnya, jumlah FP yang diestimasi ditarik menjadi : Fp terestimasi = jumlah total * (0,65 + 0,01 * SFi) Fp terestimasi = 318 * (0,65 + 0,01 * 52) = 372 Berdasar data historis, produktifitas sistem seperti itu adalah: 6,5 Fp/pm labor rate : $ 8.000/month Cost/Fp : $ 1.230 (8000 / 6,5) Maka, total estimasi biaya proyek: $457.000 (372 * 1230) dan estimasi effortnya: 58 person-month. (372 / 6,5)
5.8. Proses Based Estimation Tabel 5-4 Contoh process based estimation:
5.8. Proses Based Estimation Labor rate : $ 8.000 per month Estimasi effort : 46 person-permonth Total estimasi : $ 368.000 (8000 * 46) Jika diperlukan, labor rate bisa dibuat berbeda sesuai dengan aktifitas proses software.
5.9. COCOMO : Parametric Model Organic Mode Pengembangan software membutuhkan tim yang relatif kecil pada lingkungan internal dan sistem yang dikembangkan adalah sistem yang kecil dan kebutuhan interfacenya fleksibel. Embedded Mode Produk yang akan dikembangkan harus beroperasi dalam lingkungan (hardware), perangkat lunak dan batasan operasional yang ketat. Semi-detached mode Mengkombinasikan elemen organik dan embedded mode atau mempunyai karekteristik yang berasal dari dua mode tsb.
5.9. COCOMO : Parametric Model COCOMO : Constructive Cost Model Salah satu cara melakukan estimasi software (model empiris). Model dasar dibuat atas dasar persamaan : Effort = c * size k D = x * Effort y Effort adalah usaha yang dinyatakan dalam bentuk pm (person month ). D adalah waktu pengembangan yang dinyatakan dalam bulan kronologis Size dalam bentuk kdsi (ribuan delivered source code instruction) atau KLOC C dan k maupun X dan Y = konstanta Langkah pertama adalah menentukan estimasi ukuran sistem dalam kdsi atau KLOC Konstansta c,k,x dan y bergantung pada apakah sistem bisa diklasifikasikan dalam bentuk :
5.9. COCOMO : Parametric Model Tabel 5-5 Konstanta COCOMO.
5.9. COCOMO : Parametric Model Contoh : Masih pada pengembangan CAD, dari estimasi LOC sebelumnya didapat 33.200 LOC 33,2 KLOC Dengan menggunakan model dasar COCOMO, didapat usaha = E = 2,4 (KLOC) 1,05 E = 2,4 (33,2) 1,05 = 95 pm Untuk menghitung durasi proyek, dari estimasi usaha diatas = D = 2,5 (95) 0,35 = 12,3 bulan Dari durasi tersebut, diperkirakan sejumlah orang (N) yg disetujui = N = E/D = 95 / 12,3 = 8 orang
5.9. COCOMO : Parametric Model Tabel 5-6 COCOMO81 intermediate cost drivers
5.9. COCOMO : Parametric Model Estimasi nominal diatur melalui dem (development effort multiplier ) pmest = pmnom x dem dem dihitung berdasarkan tabel cost driver Tim dengan kemampuan yang tinggi bisa mengurangi effort implementasi proyek sampai dengan 20% dibandingkan dengan tim dengan kemampuan rendah atau tidak familiar pada bahasa pemrograman tertentu.
5.9. COCOMO : Parametric Model Tabel 5-7 Contoh pemberian bobot pada masing-masing atribut
selesai…