Rekayasa Perangkat Lunak
PERENCANAAN PROYEK PERANGKAT LUNAK 5.1. OBSERVASI PADA ESTIMASI Kompleksitas merupakan pengukuran relatif yang dipengaruhi oleh kebiasaan dengan usaha yang sudah dilakukan pada masa sebelumnya. Ukuran proyek (project size) merupakan faktor penting lain yang dapat mempengaruhi akurasi estimasi. Bila ukuran bertambah maka ketergantungan di antara berbagai elemen perangkat lunak akan meningkat dengan cepat. Tingkat ketidakpastian struktural (structural uncertainty) juga berpengaruh dalam resiko estimasi. Bila ruang lingkup proyek tidak dipahami dengan baik atau syarat proyek merupakan subyek terjadinya perubahan, maka resiko dan ketidakpastian menjadi sangat tinggi. Perencana perangkat lunak harus melengkapi fungsi, kinerja dan definisi interface (yang diisikan ke dalam spesifikasi sistem).
5.2. TUJUAN PERENCANAAN PROYEK Untuk menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasiyang dapat dipertanggungjawabkan mengenai sumber daya, biaya dan jadwal. Estimasi dibuat dengan sebuah kerangka waktu yang terbatas pada awal sebuah proyek perangkat lunak dan seharusnya diperbaharui secara teratur selagi proyek sedang berjalan.
5.3. RUANG LINGKUP PERANGKAT LUNAK Aktivitas pertama dalam perencanaan perangkat lunak adalah penentuan ruang lingkup perangkat lunak. Fungsi dan kinerja yang dialokasikan untuk perangkat lunak selama rekayasa sistem seharusnya ditaksir untuk membentuk sebuah
Lecture-Note
Hal : 1
Rekayasa Perangkat Lunak
ruang lingkup proyek yang jelas dan dapat dimengerti pada tingkat manajemen dan teknis. Ruang lingkup perangkat lunak menggambarkan fungsi, kinerja, batasan, interface dan reliabilitas. Fungsi-fungsi yang digambarkan dalam statemen ruang lingkup dievaluasi dan dalam banyak kasus juga disaring untuk memberikan awalan yang lebih detail pada saat estimasi dimulai. Teknik yang banyak dipakai secara umum untuk menjembatani jurang komunikasi antara pelanggan dan pengembang serta untuk memulai proses komunikasi adalah dengan melakukan pertemuan atau wawancara pendahuluan. Gause & Weinberg mengusulkan bahwa analisis harus memulainya dengan mengajukan
pertanyaan-pertanyaan
bebas
konteks,
yaitu
serangkaian
pertanyaan yang akan membawa kepada pemahaman yang mendasar terhadap masalah, orang yang menginginkan suatu solusi, sifat solusi yang diharapkan, dan efektivitas pertemuan itu sendiri.
5.4. SUMBER DAYA Tugas kedua perencanaan perangkat lunak adalah mengestimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak tersebut. Gambar berikut memperlihatkan sumber daya pengembangan sebagai sebuah piramid.
Manusia Komponen PL Peranti PK/PL Gambar 5.1. Sumber Daya
Lecture-Note
Hal : 2
Rekayasa Perangkat Lunak
Perencana Sumber daya manusia memulai dengan mengevaluasi ruang lingkup serta memilih kecakapan yang dibutuhkan untuk menyelesaikan pengembangan. Beunatan mengusulkan empat kategori sumber daya perangkat lunak yang harus dipertimbangkan pada saat perencanaan berlangsung, yaitu : -
Komponen Off-the-self. Komponen-komponen PL yang ada dapat diperoleh dari proyek sebelumnya yang siap digunakan pada proyek sekarang dan telah divalidasi seluruhnya.
-
Komponen Full-Experience. Komponen-konponen PL yang sudah ada yang dikembangkan pada proyek yang lalu yang serupa dengan PL yang akan dibangun pada proyek saat ini. Setiap anggota tim memiliki pengalaman penuh sehingga modifikasi yang dibutuhkan bagi komponen ini secara relatif resikonya akan lebih rendah.
-
Komponen partial-experience. Komponen-konponen PL yang sudah ada yang dikembangkan pada proyek yang lalu yang serupa dengan PL yang akan dibangun pada proyek saat ini, tetapi akan membutuhkan modifikasi substansial. Anggota tim PL ini memiliki pengalaman yang terbatas sehingga modifikasi yang dibutuhkan bagi komponen partialexperience memiliki tingkat resiko sedang.
-
Komponen baru. Komponen PL yang harus dibangun oleh tim Pl khususnya adalah untuk kebutuhan proyek sekarang.
Lingkungan yang mendukung proyek Perangkat lunak, yang disebut juga Software Engineering environment (SEE), menggabungkan PL dan PK.
Lecture-Note
Hal : 3
Rekayasa Perangkat Lunak
5.5. ESTIMASI PROYEK PERANGKAT LUNAK Estimasi biaya dan usaha perangkat lunak tidak akan pernah menjadi ilmu pasti. Variabel yang terlalu banyak – manusia, teknik, lingkungan, politik – dapat mempengaruhi
biaya
dan
usaha
akhir
yang
diaplikasikan
untuk
mengembangkannya. Ada sejumlah pilihan untuk mencapai estimasi biaya dan usaha yang dapat dipertanggungjawabkan : 1. Menunda estimasi sampai akhir proyek (estimasi akurat 100% bila proyek sudah selesai) 2. mendasarkan estimasi pada proyek-proyek yang mirip yang sudah dilakukan sebelumnya. 3. menggunkana
“teknik
dekomposisi”
yang
relatif
sederhana
untuk
melakukan estimasi biaya dan usaha proyek. 4. menggunakan satu atau lebih model empiis bagi estimasi usaha dan biaya PL. Secara ideal, teknik yang ditulis untuk masing-masing pilihan harus diaplikasi secara berpasangan, masing-masing digunakan sebagai cross check bagi yang lain. Pada estimasi proyek PL, teknik dekomposisi mengambil cara “membagi dan mengalahkan.” Model estimasi empiris dapat digunakan untuk melengkapi teknik dekomposisi serta menawarkan pendekatan estimasi yang secara potensial berharga. Model berbasis pengalaman dan berbentuk :
D = f(vi) Dimana d adalah satu dari sejumlah harga estimasi (contoh usaha, biaya, durasi proyek) dan vi adalah parameter independen yang dipilih (seperti LOC dan FP yang diestimasi). Peranti estimasi otomatis mengimplementasi satu atau lebih teknik dekomposisi atau model empiris.
Lecture-Note
Hal : 4
Rekayasa Perangkat Lunak
5.6. TEKNIK DEKOMPOSISI Akurasi estimasi proyek PL didasarkan pada sejumlah hal : 1. tingkat dimana perencana telah dengan tepat mengestimasi ukuran produk yang akan dibuat 2. kemampuan untuk menerjemahkan estimasi ukuran ke dalam kerja manusia, waktu kalender, dan dolar 3. Tingkat di mana rencana proyek mencerminkan kemampuan tim PL 4. stabilitas syarat produk serta lingkungan yang mendukung usaha pengembangan PL. Dalam konteks perencanaan proyek, ukuran berarti keluaran yang dapat dikuantitatifkan dari proyek PL. Bila dilakukan pendekatan langsung, ukuran dapat diukur dalam LOC. Tetapi bila dipilih pendekatan tidak langsung, ukuran dihadirkan sebagai FP. Selama estimasi proyek PL, data LOC dan FP digunakan dalam dua cara : 1. sebagai variabel estimasi yang dipakai untuk “mengukur” masing-masing elemen PL, 2. Sebagai metrik baseline yang dikumpulkan dari proyek yang lalu dan dipakai
dalam
hubungannya
dengan
variabel
estimasi
untuk
mengembangkan proyeksi kerja dan biaya. Teknik estimasi LOC dan FP berbeda di dalam tingkat detail yang dibutuhkan untuk dekomposisi dan target pembagian. Bila LOC digunakan sebagai variabel estimasi, dekomposisi menjadi sangat penting dan sering dipakai pada tingkat yang dapat dipertanggungjawabkan. Semakin besar tingkat pemisahannya, semakin akurat estimasi LOC dan FP yang dikembangkan. Kemudian three-point atau expected value dihitung. Expected value untuk variabel estimasi (ukuran), EV, dapat dihitung sebagai rata-rata terbobot dari estimasi optimistik (Sopt), paling sering (Sm) dan pesimistik(Spess). Contohnya : EV = (Sopt + Sm + Spess)/6
Lecture-Note
Hal : 5
Rekayasa Perangkat Lunak
5.7. MODEL PERKIRAAN EMPIRIS Model perkiraan untuk PL komputer menggunakan rumusan yang ditarik secara empiris untuk memprediksi usaha sebagai sebuah fungsi LOC dan FP. Data empiris yang mendukung sebagian besar model perkiraan ditarik dari sebuah sampel proyek yang terbatas. Karena itulah maka tidak ada model perkiraan yang
sesuai
untuk
semua
kelas
PL
dan
dalam
semua
lingkungan
pengembangan.
5.7.1 Struktur Model Perkiraan Di antara berbagai model perkiraan yang berorientasi pada LOC yang diusulkan dalam literatur ini adalah : E = 5,2 x (KLOC)0,91
Walston-felix Model
E = 5,5 + 0,73 x (KLOC)1,16
Baily-Basili Model
E = 3,2 x (KLOC)1,05
Model sederhana Boehm
E = 5,288 x (KLOC)1,047
Dotu Model untuk KLOC > 9
Model-model orientasi FP juga telah diusulkan, yaitu : E = -13,39 + 0,0545 FP
Albercht dan Gaffney Model
E = 60,62 x 7,728 x 10-8FP3
Kemerer Model
E = 585,7 + 15,12 FP
Matson, Barnett, dan Mellichamp Model
5.7.2 Model COCOMO Barry Boehm memperkenalkan hirarki model estimasi PL dengan nama COCOMO, kependekatan dari COnstructive COst Model (Model Biaya Konstruktif). Hirarki model Boehm berbentuk sbb : Model 1 :
Model COCOMO Dasar menghitung usaha pengembangan PL (dan biaya) sebagai fungsi dari ukuran prgram yang diekspresikan dalam baris kode yang diestimasi.
Lecture-Note
Hal : 6
Rekayasa Perangkat Lunak
Model 2 :
Model COCOMO Intermediate menghitung usaha pengembangan PL sebagai fungsi ukuran program dan serangkaian “pengendali biaya” yang menyangkut penilaian yang subyektif terhadap produk, perangkat keras personil, dan atribut proyek.
Model 3 :
Model COCOMO advanced menghubungkan semua karakteristik versi intermediate dengan penilaian terhadap pengaruh pengendali biaya pada setiap langkah (analisis, perancangan, dll) dari proses rekayasa PL. Tabel 5.1. Model Cocomo Dasar
Proyek Perangkat Lunak
ab
bb
cb
db
Organik
2,4
1,05
2,5
0,38
Semi-detached
3,0
1,12
2,5
0,35
Embedded
3,6
1,20
2,5
0,32
Model COCOMO ditetapkan untuk tiga kelas proyek PL : 1. mode organik – proyek PL yang sederhana dan relatif kecil di mana tim kecil dengan pengalaman aplikasi yang baik. 2. mode semi-detached – proyek PL menengah 9dalam ukuran dan kompleksitas) di mana tim dengan pengalaman pada tingkat tingkat yang berbeda-beda harus memenuhi bauran yang kurang kuat dari syarat yang ketat (misalnya sistem pemrosesan transaksi dengan syarat tertentu untuk PK terminal dan PL database) 3. mode embedded – proyek PL yang harus dikembangkan ke dalam serangkaian PK, Pl dan batasan operasional yang ketat (seperti PL kontrol penerbangan untuk pesawat udara).
Lecture-Note
Hal : 7
Rekayasa Perangkat Lunak
Persamaan COCOMO dasar berbentuk :
E = abKLOCbb D = cbEdb Dimana E
: usaha yang diaplikasikan dalam person-month,
D
: waktu pengembangan dalam bulan kronologis
KLOC : jumlah baris penyampaian kode yang diperkirakan untuk proyek tsb. Koefisien ab dan cb dan eksponen bb dan db ada pada tabel 5.1. Model COCOMO menengah berbentuk :
E = aiKLOCbi x EAF Dimana E
:
usaha yang diaplikasikan dalam person-month,
KLOC : jumlah baris penyampaian kode yang diperkirakan untuk proyek tsb. Koefisien ai dan eksponen bi ada pada tabel 5.2. Tabel 5.2. Model COCOMO Intermediate
Lecture-Note
Proyek Perangkat Lunak
ai
bi
Organik Semi-detached Embedded
3,2 3,0 2,8
1,05 1,12 1,20
Hal : 8
Rekayasa Perangkat Lunak
5.7.3. Persamaan Perangkat Lunak Persamaan
perangkat
mengasumsikan
lunak
distribusi
adalah
khusus
model usaha
yang
multivariasi
sepanjang
hidup
yang proyek
pengembangan PL. Berdasarkan data-data tersebut, model estimasi berbentuk :
E = [LOC x B0,333/P]3 x (1/t4) Dimana E = usaha dalam person-month atau person-year B = ‘faktor skill khusus” yang meningkat secara perlahan. Untuk program kecil (KLOC = 5 – 15) B = 0,16. Untuk program yang lebih besar dari 70 KLOC, B = 0,39 t=
durasi proyek dalam bulan atau tahun
P = “parameter produktivitas” P = 2000 untuk pengembangan PL real time P = 10.000 untuk telekomunikasi dan PL sistem P = 28.000 untuk aplikasi sistem bisnis P = 12.000 untuk PL ilmu pengetahuan
Lecture-Note
Hal : 9
Rekayasa Perangkat Lunak
5.8. KEPUTUSAN MAKE-BUY Langkah-langkah membuat keputusan MAKE-BUY dapat ditelusuri dengan membuat Analisis Pohon Keputusan. Di sini kita akan mencari expected cost dengan rumus sbb :
Expected cost = (jalur probabilitas)i x (biaya jalur terestimasi)i Dimana i adalah garis edar pohon keputusan. Ini berarti bahwa : Expected costbuilt = 0,30($380K) + 0,70 ($450K) = $429K Expected costreuse = 0,40($275K) + 0,60[0,20($310K)+0,80($490K)] = $382K Expected costbuyt = 0,70($210K) + 0,30 ($400K) = $267K Expected costcontract = 0,60($350K) + 0,40 ($500K) = $410K Berdasarkan biaya probabilitas dan proyeksi yang telah ditulis pada gambar 5.6, expected cost yang paling rendah adalah pilihan buy. Namun penting pula untuk dicatat bahwa banyak kriteria – bukan hanya biayaharus dipertimbangkan selama proses pembuatan keputusan. Keberadaan, pengalaman pengembang/vendor/kontraktor, penyesuaian terhadap kebutuhan, dan kecenderungan perubahan, juga merupakan beberapa kriteria yang dapat mempengaruhi keputusan akhir untuk memilih garis built, reuse, buy atau contract.
Lecture-Note
Hal : 10
Rekayasa Perangkat Lunak
Built
Sederhana(0,30)
$380,000
Sulit (0,70)
$450,000
Perub. Kecil(0,40)
$275,000
Sederhana(0,20)
$310,000
Kompleks(0,80)
$490,000
Perub. Kecil(0,70)
$210,000
Perub. Besar(0,30)
$400,000
Tanpa perub(0,60)
$350,000
Dengan perub(0,40)
$500,000
Reuse Sistem x
perubahan besar(0,60)
Buy
contract
Gambar 5.6. Pohon Keputusan untuk Mendukung keputusan MAKE-BUY
Lecture-Note
Hal : 11