PERENCANAAN PROYEK PERANGKAT LUNAK ID
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 pertanyaanpertanyaan 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 .
3. Standard component sizing. PL dibangun dari sejumlah
“komponen standar” yg berbeda-beda yg umum bagi suatu
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 :
1. Sebagai variabel estimasi yg dipakai utk
“mengukur” masing-masing elemen PL.
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 masingmasing tugas yg diperkirakan.
• Perkiraan berbasis proses dimulai dengan gambaran fungsifungsi Perangkat Lunak yang diperoleh dari ruang lingkup
proyek.
• Untuk masing-masing fungsi dilakukan aktivitas proses
Perangkat Lunak yg berhubungan yang dapat disajikan
sebagai bagian dari suatu tabel.
• Sekali fungsi masalah dan aktivitas proses disatukan
perencana akan memperkirakan usaha (seperti personmonth) 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
LOC dan FP.
• Data empiris yg mendukung sebagian besar perkiraan
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
E = 5.5 + 0.73 x (KLOC)1.16
E = 3.2 x (KLOC)1.05
E = 5.288 x (KLOC)1.047
9
Walston-Felix Model
Baily-Basili Model
Model sederhana Boeehm
Dotu Model untuk KLOC >
• 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
biaya konstruksi.
• Hirarki model Boehm berbentuk sebagai berikut :
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
menghitung usaha pengembangan Perangkat L sebagai fungsi
ukuran program dan serangkaian “pengendalian biaya” yg
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
Semi-detached
Embedded
2,4
3,0
3,6
1,05
1,12
1,20
2,5
2,5
2,5
0,38
0,35
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
diharapkan berkualitas lebih tinggi.
• Sisi positif outsourching yaitu penghematan biaya dapat
dicapai dengan mengurangi jumlah Perangkat Lunak
serta fasilitas yg mendukung mereka (spt komponen
infrastruktur).
• Sisi negatifnya yaitu perusahaan kehilangan banyak
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.
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 pertanyaanpertanyaan 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 .
3. Standard component sizing. PL dibangun dari sejumlah
“komponen standar” yg berbeda-beda yg umum bagi suatu
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 :
1. Sebagai variabel estimasi yg dipakai utk
“mengukur” masing-masing elemen PL.
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 masingmasing tugas yg diperkirakan.
• Perkiraan berbasis proses dimulai dengan gambaran fungsifungsi Perangkat Lunak yang diperoleh dari ruang lingkup
proyek.
• Untuk masing-masing fungsi dilakukan aktivitas proses
Perangkat Lunak yg berhubungan yang dapat disajikan
sebagai bagian dari suatu tabel.
• Sekali fungsi masalah dan aktivitas proses disatukan
perencana akan memperkirakan usaha (seperti personmonth) 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
LOC dan FP.
• Data empiris yg mendukung sebagian besar perkiraan
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
E = 5.5 + 0.73 x (KLOC)1.16
E = 3.2 x (KLOC)1.05
E = 5.288 x (KLOC)1.047
9
Walston-Felix Model
Baily-Basili Model
Model sederhana Boeehm
Dotu Model untuk KLOC >
• 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
biaya konstruksi.
• Hirarki model Boehm berbentuk sebagai berikut :
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
menghitung usaha pengembangan Perangkat L sebagai fungsi
ukuran program dan serangkaian “pengendalian biaya” yg
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
Semi-detached
Embedded
2,4
3,0
3,6
1,05
1,12
1,20
2,5
2,5
2,5
0,38
0,35
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
diharapkan berkualitas lebih tinggi.
• Sisi positif outsourching yaitu penghematan biaya dapat
dicapai dengan mengurangi jumlah Perangkat Lunak
serta fasilitas yg mendukung mereka (spt komponen
infrastruktur).
• Sisi negatifnya yaitu perusahaan kehilangan banyak
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.