Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

Pertemuan VIII.  5.5. Estimasi proyek software  5.6. Software sizing  5.7. Estimasi berbasis problem  5.8. Estimasi berbasis proses  5.9. Estimasi.

Presentasi serupa


Presentasi berjudul: "Pertemuan VIII.  5.5. Estimasi proyek software  5.6. Software sizing  5.7. Estimasi berbasis problem  5.8. Estimasi berbasis proses  5.9. Estimasi."— Transcript presentasi:

1 Pertemuan VIII

2  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

3  Untuk mendapatkan estimasi biaya dan effort yang bisa dipertanggung jawabkan, maka muncul sejumlah opsi : 1.Estimasi didelay sampai dengan akhir proyek (estimasi biaya akurat 100% jika proyek selesai). 2.Estimasi berdasarkan proyek serupa yang telah dikembangkan 3.Gunakan teknik dekomposisi yang sederhana untuk menghasilkan biaya dan effort proyek tersebut. 4.Gunakan satu atau beberapa model empiris untuk estimasi biaya dan effort software.

4 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  Akurasi sistem proyek software ditentukan pada hal-hal sebagai berikut: 1. Tingkatan dimana perencana telah dengan tepat mengestimasi ukuran produk yang akan dibuat. 2. Kemampuan untuk menterjemahkan estimasi ukuran kedalam calender time, human effort dan biaya. 3. Tingkat dimana perencanaan proyek mencerminkan kemampuan tim software. 4. Stabilitas syarat produk dan lingkungan yang mendukung usaha pengembangan software.

6  Ada 4 pendekatan yang berbeda terhadap masalah penentuan “ukuran” : 1.Fuzzy logic sizing 2.Function Point sizing 3.Standar component sizing 4.Change Sizing

7 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

8 Function Point sizing  Planner melakukan estimasi karakteristik domain informasi (bab 4) yang meliputi (14) : jumlah orang yang dipakai, biaya dan lain- lain.

9 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” = LOC

10 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.

11  Selama estimasi proyek software, data LOC dan FP digunakan dalam 2 cara, : 1. Sebagai estimation variable yang digunakan untuk mengukur masing- masing element software. 2. Sebagai base line metric yang dikumpulkan dari proyek sebelumnya yang kemudian dikombinasikan dengan estimation variable untuk menentukan proyeksi biaya dan effornya.

12  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 ”

13  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)

14  Tabel 5-3 Contoh LOC Based Estimation

15  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 =(S opt +4S m +S pess )/6  Jadi EV untuk 3DGA adalah = (4600+(4x6.900)+8600)/6  = 6800

16  Berdasar data historis, produktifitas sistem seperti itu adalah: 620 LOC/pm  labor rate: $ 8.000/month  Cost/LOC : $  (8000 / 620)  Maka, total estimasi biaya proyek: $  ( * 13) dan estimasi effortnya: 54 person-month.  ( / 620)

17  Tabel 5-1 Contoh FP-Based estimation

18  Tabel 5-2 Estimasi information domain Values

19  Akhirnya, jumlah FP yang diestimasi ditarik menjadi :  Fp terestimasi = jumlah total * (0,65 + 0,01 *  Fi)  Fp terestimasi = 318 * (0,65 + 0,01 *  ) = 372  Berdasar data historis, produktifitas sistem seperti itu adalah: 6,5 Fp/pm  labor rate: $ 8.000/month  Cost/Fp : $  (8000 / 6,5)  Maka, total estimasi biaya proyek: $  (372 * 1230) dan estimasi effortnya: 58 person-month.  (372 / 6,5)

20  Tabel 5-4 Contoh process based estimation:

21  Labor rate : $ per month  Estimasi effort : 46 person-permonth  Total estimasi : $  (8000 * 46)  Jika diperlukan, labor rate bisa dibuat berbeda sesuai dengan aktifitas proses software.

22  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.

23  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 : 

24  Tabel 5-5 Konstanta COCOMO.

25  Contoh :  Masih pada pengembangan CAD, dari estimasi LOC sebelumnya didapat 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

26  Tabel 5-6 COCOMO81 intermediate cost drivers

27  Estimasi nominal diatur melalui dem (development effort multiplier ) ◦ pm est = pm nom 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.

28  Tabel 5-7 Contoh pemberian bobot pada masing-masing atribut

29 selesai…


Download ppt "Pertemuan VIII.  5.5. Estimasi proyek software  5.6. Software sizing  5.7. Estimasi berbasis problem  5.8. Estimasi berbasis proses  5.9. Estimasi."

Presentasi serupa


Iklan oleh Google