Perencanaan Proyek Software

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” = 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.

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 ”

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)

Tabel 5-3 Contoh LOC 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

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)

Tabel 5-1 Contoh FP-Based estimation

Tabel 5-2 Estimasi information domain Values

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 : $  (8000 / 6,5) Maka, total estimasi biaya proyek: $  (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 : $ per month Estimasi effort : 46 person-permonth Total estimasi : $  (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.

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

Tabel 5-5 Konstanta COCOMO.

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

Tabel 5-6 COCOMO81 intermediate cost drivers

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.

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

selesai…

Perencanaan Proyek Software

Presentasi serupa

Presentasi berjudul: "Perencanaan Proyek Software"— Transcript presentasi:

Presentasi serupa

Tentang proyek

Tanggapan

Masuk

Otorisasi melalui jaringan sosial:

Perencanaan Proyek Software

Presentasi serupa

Presentasi berjudul: "Perencanaan Proyek Software"— Transcript presentasi:

Presentasi serupa

Tentang proyek

Tanggapan