PERENCANAAN PROYEK

PERANGKAT LUNAK
PENDAHULUAN
• Estimation (perkiraan) merupakan aktivitas
dalam project planning (perencanaan proyek).
• Project complexity (kompleksitas proyek)
berpengaruh kuat terhadap ketidak pastian yang
inheren dalam perencanaan.
• Project size (ukuran proyek) merupakan faktor
penting lain yang mempengaruhi akurasi
estimasi.
• Ketidakpastian struktural (structural uncertainty)
juga berpengaruh dalam estimasi.
TUJUAN PERENCANAAN PROYEK
• Tujuan perencanaan proyek Perangkat Lunak
adalah untuk menyediakan sebuah kerangka
kerja yang memungkinkan manajer membuat
estimasi yang dapat dipertanggung jawabkan
mengenai sumber daya, biaya, dan jadwal.
• Tujuan perencanaan dicapai melalui suatu
proses penemuan informasi yang menunjuk ke
estimasi yang dapat dipertanggung jawabkan.
RUANG LINGKUP PERANGKAT LUNAK
• Ruang lingkup Perangkat Lunak menggambarkan fungsi,
kinerja, batasan, interface dan reliabilitas.
• Fungsi-fungsi yang digambarkan dalam statement ruang
lingkup dievaluasi dan disaring untuk memberikan
awalan yang lebih detail saat estimasi dimulai.
• Mencari informasi yang dibutuhkan untuk ruang lingkup.
Penggunaan teknik diperlukan utk menjembatani jurang
komunikasi antara pelanggan dan pengembang.
Analis harus memulai dengan mengajukan pertanyaan-
pertanyaan yg bebas konteks, yaitu serangkaian pertanyan yg
akan membawa kepada pemahaman yg mendasar terhadap
masalah, orang yg menginginkan suatu solusi, sifat solusi yg
diharapkan, dan efektivitas pertemuanitu sendiri.
Rangkaian pertanyaan bebas konteks yg
pertama berfokus kepada pelanggan , tujuan
keseluruhan serta keuntungan. Sebagai contoh
analis dpt menayakan :
Siapa dibelakang permintaan kerja ini ?
Siapa yang akan memakai solusi ini ?
Apakah yang akan menjadi keuntungan
ekonomi dari sebuah solusi yg sukses ?
Adakah sumber daya lain bagi solusi ini ?
Rangkaian pertanyaan berikutnya
memungkinkan analis utk memahami masalah
dengan lebih baik serta memungkinkan
pelanggan untuk menyuarakan persepsi mereka
tentang sebuah solusi :
Bagaimanakah anda (pelanggan) menandai output
yg baik yg akan diunsulkan oleh sebuah solusi yg
baik ?
Masalah apa yg akan dituju oleh solusi ini ?
Dapatkah anda memperlihatkan atau
menggambarkan lingkungan dimana solusi akan
dipakai ?
Adakah batasan atau isu kinerja khusus yg akan
mempengaruhi cara pendekatan terhadap solusi ?
Rangkaian akhir pertanyaan berfokus pada
efektivitas pertemuan. Gauss dan weinberg
menyebutnya meta-question dan mengusulkan
daftar berikut :
Apakah anda orang yg tepat untuk menjawab
pertanyaan ini ? Apakah jawaban anda resmi ?
Apakah pertanyaan saya relevan dengan problem
yg anda punyai ?
Apakah saya terlalu banyak pertanyaan ?
Apakah ada orang lain yg dapat menyediakan
informasi tambahan ?
Adakah sesuatu yg lain yg dapat saya tanyakan
kepada anda ?
• Untuk membangun ruang lingkup sebuah
proyek sejumlah peneliti lepas mengambangkan
pendekatan yg berorientasi pada tim dengan
menggunakan teknik spesifikasi aplikasi yg
teraplikasi (FAST). Pendekatan ini
menumbuhkan kreasi tim gabungan pelanggan
dan pengembang, yang bekerja besama-sama
untuk menentukan masalah, mengusulkan
elemen-elemen solusi, membicarakan
pendekatan-pendekatan yang berbeda dan
menentukan serangkaian kebutuhan
pendahuluan.
SUMBER DAYA
• Tugas kedua perencanaan Perangkat Lunak adalah
mengestimasi sumber daya yang dibutuhkan untuk
menyelesaikan usaha pengembangan Perangkat Lunak
tersebut.
Perspektif Sumber Daya
• Masing-masing sumber daya tersebut
dispesifikasikan dengan 4 karakteristik berikut
ini:
Deskripsi  Siapa, Apa
Ketersediaan  Jumlah dan kualitas
Waktu  Kapan digunakan
Durasi  Berapa lama dipakai
1. Sumber Daya Manusia
• Perencana sumber daya manusia memulai
dengan mengevaluasi ruang lingkup dan
kecakapan yang dibutuhkan utk menyelesaikan
pengembangan.
• Posisi organisasi (seperti manajer, perekayasa
Perangkat Lunak senior, dll) maupun specialty
( seperti telekomunikasi, data base,client/server)
ditentukan.
• Jumlah orang yang diperlukan utk sebuah
proyek Perangkat Lunak dapat ditentukan
hanya setelah sebuah estimasi pengembangan
dibuat.
 2. Sumber Daya PL Reusable
• Beunatan mengusulkan empat kategori sumber daya
Perangkat Lunak yang harus dipertimbangkan saat
perencanaan berlangsung :
1. Komponen Off-the-self. Perangkat lunak yang ada yang
dpt diperoleh dari sebuah bagian ketiga atau telah
dikembangkan secara internal untuk proyek sebelumnya.
Komponen-komponen tersebut siap digunakan pada proyek
sekarang dan telah divalidasi seluruhnya.
2. Komponen Full-Experience. Spesifikasi, kode, desain
atau pengujian data yg sudah ada yg dikembangkan pada
proyek yg lalu yg serupa dengan Perangkat Lunak yang akan
dibangun pada proyek saat ini.
3. Komponen Partial-Experience. Aplikasi, kode, desain
atau data pengujian yg ada pada proyek yang lalu yang
dihubungkan dengan Perangkat Lunak yg akan dibangun utk
proyek saat ini, tetapi akan membutuhkan modiikasi
subtansial.
4. Komponen baru. Komponen PL yg harus dibangun oleh
tim PL khususnya adalah untuk kebutuhan proyek sekarang.
3. Sumber Daya Lingkungan
• Lingkungan yg mendukung proyek perangkat
lunak disebut juga dengan Software
Engineering Enviroment (SEE),
menggabungkan perangkat lunak dan perangkat
keras.
• Perangkat keras menyediakan sebuah platform
yg mendukung peranti (perangkat lunak) yg
dibutuhkan untuk menghasilkan produk kerja yg
merupakan keluaran dari pratik rekayasa
Perangkat Lunak yang baik.
ESTIMASI PROYEK PERANGKAT LUNAK
Pada masa-masa awal perhitungan, biaya Perangkat
Lunak terdiri dari persentase kecil biaya sistem
berbasis komputer secara keseluruhan.
Sekarang Perangkat Lunak menjadi elemen paling
mahal di dalam sebagian besar sistem berbasis
komputer.
Kesalahan estimasi biaya yg besar dpt memberikan
perbedaan antara keuntungan dan kerugian.
Biaya yg terlalu banyak dpt menjasi bencana bagi
pengembang Perangkat Lunak.
 Ada sejumlah pilihan untuk mencapai estimasi
biaya dan usaha yg dapat dipertanggung jawabkan.
1. Menunda estimasi sampai akhir proyek (jelas kita
dapat melakukan estimasi yang 100 persen akurat
bila proyek sudah selesai).
2. Mendasarkan estimasi pada proyek-proyek yg
mirip yg sudah dilakukan sebelumnya.
3. Menggunakan “teknik dekomposisi” yg relatif
sederhana utk melakukan estimasi biaya dan usaha
proyek.
4. Menggunakan satu atau lebih model empiris bagi
estimasi usaha dan biaya Perangkat Lunak.
TEKNIK DEKOMPOSISI
• Software Sizing
• Perkiran berdasarkan masalah
• Process based estimation
Software Sizing
• Akurasi estimasi PL didasarkan pada sejumlah
hal :
1. Tingkat dimana perencana telah dengan tepat
mengestimasi ukuran produk yg akan dibuat.
2. Kemampuan utk menterjemahkan estimasi
ukuran ke dalam kerja manusia, waktu,
kalender, dan dolar (fungsi availabilitas
metrikPL yg reliabel dari proyek sebelumnya).
3. Tingkat dimana rencana proyek mencerminkan
kemampuan tim PL.
4. Stabilitas syarat produk serta lingkungan yg
mendukung usaha pengembangan PL.
 • Putnam dan Myers mengusulkan 4 pendekatan berbeda
terhadap masalah penentuan ukuran :
1. Fuzzy-logic sizing. Pendekatan ini menggunakan teknik
reasoning aproksimasi yg merupakan dasar bagi fuzzy logic
(logika kabur). Untuk menerapkan ini perencana harus
mengidentifikasi tipe aplikasi, membuat besaran dalam skala
kuantitatif, dan menyaring besaran itu dalam rentang
orisinil.
2. Function point sizing. Perencana mengembangkan
estimasi karakteristik domain informasi .

“komponen standar” yg berbeda-beda yg umum bagi suatu

3. Standard component sizing. PL dibangun dari sejumlah
area aplikasi tertentu.Contohnya komponen standar bagi
sebuah sistem informasi adalah subsistem, modul, layar,
laporan, program-program interaktif, program batch, file,
LOC dan instruksi logika objek.
4. Change sizing. Pendekatan ini digunakan bila ukuran
proyek melingkupi pemakaian PL yg ada yg harus
dimodifikasi dengan banyak cara sebagai bagian dari sebuah
proyek.
Perkiraan Berdasarkan Masalah
• Baris kode (LOC) dan titik fungsi (FP)
digambarkan sebagai pengukuran dasar dimana
metrik produktivitas dapat dihitung.
• Selama estimasi PL data LOC dan FP digunakan
dalam dua cara :

“mengukur” masing-masing elemen PL.

1. Sebagai variabel estimasi yg dipakai utk

2. Sebagai metrik baseline yg dikumpulkan dari

proyek yg lalu dan dipakai dalam hubungannya
dengan variabel estimasi untuk proyeksi kerja
dan biaya.
Contoh LOC based
Contoh FP based
 Estimasi Berbasis Proses
• Teknik yang paling umum untuk memperkirakan sebuah
proyek adalah dengan mendasarkan perkiraan pada sebuah
proses yg akan digunakan; yaitu proses yg akan didekomposisi
ke dalam serangkaian aktivitas atau tugas yg relatif sangat
kecil dan usaha yg dibutuhkan utk menyelesaikan masing-

• Perkiraan berbasis proses dimulai dengan gambaran fungsi-

masing tugas yg diperkirakan.

fungsi Perangkat Lunak yang diperoleh dari ruang lingkup

• Untuk masing-masing fungsi dilakukan aktivitas proses

proyek.

Perangkat Lunak yg berhubungan yang dapat disajikan

• Sekali fungsi masalah dan aktivitas proses disatukan

sebagai bagian dari suatu tabel.

perencana akan memperkirakan usaha (seperti person-

month) yang dibutuhkan utk menyelesaikan setiap aktivitas
proyek Perangkat Lunak untuk setiap fungsi Perangkat Lunak.
Contoh Process based
MODEL PERKIRAAN EMPIRIS
• Digunakan utk memprediksi usaha sebagai sebuah fungsi

• Data empiris yg mendukung sebagian besar perkiraan

LOC dan FP.

ditarik dari sebuah sampel proyek yg terbatas.

E = A + B x (Ev)c

• Dimana A, B, dan C adalah konstanta yang ditarik secara

empiris, E adalah usaha dalam persont-mont, dan Ev
adalah variabel perkiraan (baik dalam LOC maupun FP).
• Model perkiraan yg berorientasi pada LOC yg
diusulkan 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 Boeehm
E = 5.288 x (KLOC)1.047 Dotu Model untuk KLOC >
9

• Model-model orientasi FP yg diusulkan yaitu :

E = -13.39 + 0.0545 FP Albercht dan Gaffney Model

E = 60.62 x 7.728x 10-8 FP3 Kemerer Model
E= 585.7 + 15.12 FP Matson, Barnett, dan Mellicchamp Model
 MODEL COCOMO
• Model COCOMO (Constructive Cost Model ) atau model

• Hirarki model Boehm berbentuk sebagai berikut :

biaya konstruksi.

 Model 1 : Model COCOMO Dasar

menghitung usaha pengembangan Perangkat Lunak (dan biaya)
sebagai fungsi dari ukuran program yg diekspresikan dalam baris
kode yg diestimasi.
 Model 2 : Model COCOMO Intermediate

ukuran program dan serangkaian “pengendalian biaya” yg

menghitung usaha pengembangan Perangkat L sebagai fungsi
menyangkut perkalian yg 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
Perangkat Lunak.
• Model COCOMO ditetapkan untuk 3 kelas proyek PL
dengan menggunakan terminologi Boehm :
1. Mode organik : Proyek PL sederhana dan relatif kecil
dimana tim kecil dengan pengalaman aplikasi yg baik
mengerjakan serangkaian kebutuhan yg lebih tidak tegar
(misalnya program analisis termal yg dikembangkan untuk
kelompok transfer panas).
2. Mode semi-detached : Proyek PL menengah (dalam
ukuran dan kompleksitas) dimana tim dengan pengalaman
pada tingkat yg berbeda-beda harus memenuhi bauran yg
kurang kuat dari syarat yg ketat (misalnya sistem
pemrosesan transakasi dengan syarat tertentu untuk
perangkat keras terminal dan perangkat lunak database).
3. Mode embedded : Proyek PL yg harus dikembangkan ke
dalam serangkaian perangkat keras, perangkat lunak dan
batasan operasional yg ketat (seperti perangkat lunak
kontrol penerbangan untuk pesawat udara)
 Persamaan COCOMO
E = ab KLOCbb
D = cb Edb

•Dimana E adalah usaha yg diaplikasikan dalam person-month,

D adalah waktu pengembangan dalam bulan kronologis, dan
KLOC adalah jumlah baris penyampaian kode yang diperkirakan
untuk proyek tersebut (diekspresikan dalam ribuan).
•Koeffisien ab dan cb dan eksponen bb dan db ada pada tabel
berikut :

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
KEPUTUSAN BELI ATAU BUAT
• Keputusan make-buy dapat dikomplikasikan
lebih jauh oleh sejumlah pilihan :
1. Perangkat lunak dapat dibeli (atau lisensi)
2. Komponen perangkat lunak full-experience dan
partial experience (dpt diperoleh dan kemudian
dimodifikasi dan diintegrasi utk memenuhi
kebutuhan tertentu.
3. Perangkat lunak dapat dibuat custom-built oleh
kontraktor luar utk memenuhi spesifikasi
pembeli.
MEMBUAT POHON KEPUTUSAN
LANGKAHNYA :
1. Membangun sistem X dari permulaan
2. Menggunakan kembali partial experience yg
ada utk membangun sistem
3. Membeli sebuah produk perangkat lunak yg dpt
diperoleh dan memodifikasinya utk memenuhi
kebutuhan lokal
4. Mengkontrakkan pengembangan perangkat
lunak ke vendor luar.
Pohon Keputusan untuk mendukung
keputusan make-buy
OUTSOURCING
• Outsourcing (mengkontrakan ke luar) sangatlah
sederhana. Aktivitas rekayasa perangkat lunak
dikontrakan kepada partai ketiga yang melakukan
pekerjaan tersebut dengan biaya yang lebih murah, dan

• Sisi positif outsourching yaitu penghematan biaya dapat

diharapkan berkualitas lebih tinggi.

dicapai dengan mengurangi jumlah Perangkat Lunak

serta fasilitas yg mendukung mereka (spt komponen

• Sisi negatifnya yaitu perusahaan kehilangan banyak

infrastruktur).

kontrol pada Perangkat Lunak yg dibutuhkannya.

Karena Perangkat Lunak merupakan teknologi yg
membedakan sistem, pelayanan, dan produknya, maka
perusahaan harus menanggung resiko dengan
mempercayakan daya saingnya kepada tangan partai
ketiga.
PERANTI ESTIMASI OTOMATIS
1. Kuantitatif ukuran Perangkat Lunak (seperti
LOC) atau fungsionalitas (data function point)
2. Karakteristik proyek kualitatif seperti
kompleksitas, reliabilitas yg dibutuhkan atau
tingkat kekritisan bisnis
3. Banyak gambaran staf pengembangan dan atau
lingkungan pengembangan.
Kesimpulan
• Perencana proyek perangkat lunak harus
memperkirakan tiga hal sebelum proyek dimulai:
• Berapa lama waktu yang dibutuhkan.
• Berapa banyak usaha akan diperlukan.
• Berapa banyak orang yang akan terlibat.
• Selain itu, perencana harus memprediksi
sumber daya (hardware dan software) yang
akan diperlukan dan resiko yang terlibat.