Rekayasa Perangkat Lunak

Pertemuan Ke 5
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.

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 :

Lecture-Note

Hal : 3

Rekayasa Perangkat Lunak

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.

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

Lecture-Note

Hal : 4

Rekayasa Perangkat Lunak

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

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

Lecture-Note

Hal : 5

Rekayasa Perangkat Lunak

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.

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

Lecture-Note

Hal : 6

Rekayasa Perangkat Lunak

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).
Persamaan COCOMO dasar berbentuk :
E = abKLOCbb
D = cbEdb
Dimana

E adalah usaha yang diaplikasikan dalam person-month,

D adalah waktu pengembangan dalam bulan kronologis
KLOC adalah 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

Lecture-Note

E adalah usaha yang diaplikasikan dalam person-month,

Hal : 7

Rekayasa Perangkat Lunak

KLOC adalah 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
Proyek Perangkat Lunak

ai

bi

Organik

3,2

1,05

Semi-detached

3,0

1,12

Embedded

2,8

1,20

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

5.8. Keputusan MAKE-BUY

Lecture-Note

Hal : 8

Rekayasa Perangkat Lunak

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.

Built

Sederhana(0,30)

$380,000

Sulit (0,70)
Perub. Kecil(0,40)

$450,000
$275,000

Sederhana(0,20)

$310,000

Kompleks(0,80)
Perub. Kecil(0,70)

$490,000
$210,000

Perub. Besar(0,30)
Tanpa perub(0,60)

$400,000
$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 : 9