Change Sizing

Download Report

Transcript Change Sizing

Pertemuan VIII





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

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.
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”.

1.
2.
3.
4.
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.

Ada 4 pendekatan yang berbeda terhadap
masalah penentuan “ukuran” :
1.
2.
3.
4.
Fuzzy logic sizing
Function Point sizing
Standar component sizing
Change 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
Function Point sizing

Planner melakukan estimasi karakteristik
domain informasi (bab 4) yang meliputi (14)
: jumlah orang yang dipakai, biaya dan lainlain.
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
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.

1.
2.
Selama estimasi proyek software, data LOC
dan FP digunakan dalam 2 cara, :
Sebagai estimation variable yang
digunakan untuk mengukur masingmasing 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
: $ 13.00  (8000 / 620)
Maka, total estimasi biaya proyek: $431.000  (33.200 * 13)
dan estimasi effortnya: 54 person-month.  (33.200 / 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
: $ 1.230  (8000 / 6,5)
Maka, total estimasi biaya proyek: $457.000  (372 * 1230)
dan estimasi effortnya: 58 person-month.  (372 / 6,5)

Tabel 5-4 Contoh process based estimation:




Labor rate
Estimasi effort
Total estimasi
: $ 8.000 per month
: 46 person-permonth
: $ 368.000  (8000 * 46)
Jika diperlukan, labor rate bisa dibuat berbeda sesuai dengan
aktifitas proses software.



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
D
◦
◦
◦
◦
◦
◦
= c * size k
= 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 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

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…