MODUL PERKULIAHAN

Rekayasa
Perangkat Lunak

Perkiraan Biaya Perangkat

Lunak

Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh

Fasilkom Teknik Informatika W151700007 Roni Yusman S.Kom, M.I.kom

12
Abstract Kompetensi
Ukuran proyek (project size) merupakan  Mampu menjelaskan teknik teknik
factor penting lain yang dapat mempengaruhi untuk memperkirakan biaya
akurasi estimasi. Bila ukuran bertambah dibuatnya sebuah perangkat lunak
maka ketergantungan di antara berbagai
elemen perangkat lunak akan meningkat
dengan cepat. Tingkat ketidakpastian
structural (structural uncertainty) juga
berpengaruh dalam risiko estimasi.
Pembahasan
Observasi Pada Estimasi
Estimasi sumber daya, biaya, dan jadwal untuk usaha pengembangan
perangkat lunak membutuhkan pengalaman, mengakses informasi historis yang baik,
dan keberanian untuk melakukan pengukuran kuantitatif bila hanya data kualitatif saja
yang ada. Estimasi membawa resiko yang inheren dan resiko inilah yang membawa
kepada ketidakpastian.
Project complexity (kompleksitas proyek) berpengaruh kuat terhadap ketidak
pastian yang inheren dalam perencanaan. Tetapi kompleksitas merupakan
pengukuran relative yang dipengaruhi oleh kebiasaan dengan usaha yang sudah
dilakukan pada masa sebelumnya. Aplikasi real-time dapat dirasakan sebagai sangat
kompleks bagi sebuah kelompok perangkat lunak yang hanya mengembangkan
aplikasi-aplikasi batch saja.
Ukuran proyek (project size) merupakan factor penting lain yang dapat
mempengaruhi akurasi estimasi. Bila ukuran bertambah maka ketergantungan di
antara berbagai elemen perangkat lunak akan meningkat dengan cepat. Tingkat
ketidakpastian structural (structural uncertainty) juga berpengaruh dalam risiko
estimasi. Santayana pernah mengatakan, “Mereka yang tidak dapat mengingat masa
lalu terkutuk untuk mengulanginya lagi”.
Risiko diukur melalui tingkat ketidakpastian pada estimasi kuantitatif yang
dibuat untuk sumber daya, biaya dan jadwal. Bila ruang lingkup proyek tidak dipahami
dengan baik atau syarat proyek merupakan subjek 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). Perencana, dan lebih penting lagi pelanggan, harus mengetahui bahwa
variabilitas pada kebutuhan perangkat lunak berarti ketidak stabilan biaya dan jadwal.
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. Estimasi dibuat
dengan sebuah kerangka waktu yang terbatas pada awal sebuah proyek perangkat
unak dan seharusnya diperbarui secara teratur selagi proyek sedang berjalan.
Sebagai tambahan, estimasi akan berusaha mendefinisikan scenario kasus terbaik

2018 Rekayasa Perangkat Lunak Pusat Bahan Ajar dan eLearning

2 Roni Yusman S,Kom, M.I.kom http://www.mercubuana.ac.id
dan kasus terburuk. Tujuan perencanaan dicapai melalui suatu proses penemuan
informasi yang menuju ke estimasi yang dapat dipertanggung jawabkan.

Ruang Lingkup Perangkat Lunak

Ruang lingkup perangkat lunak menggambarkan fungsi, kinerja, batasan,
interface danreliabilitas. Fungsi-fungsi yang di gambarkan dalam statement ruang
lingkup dievaluasi dan di dalam banyak kasus juga disaring untuk memberikan awalan
yang lebih detail pada saat estimasi dimulai. Banyak derajat dekomposisi sering
menjadi berguna karena baik estimasi jadwal maupuun biaya diorientasikan secara
fungsional. Pertimbangan kinerja melingkupi pemrosesan dan kebutuhan waktu
respon. Batasan mengidentifikasi batas yang di tempatkan pada perangkat lunak oleh
perangkat keras eksternal, memori atau sistem yang lain yang ada.
Sumber Daya
Tugas kedua perencanaan peragkat lunak adalah mengestimasi sumber daya
yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak
tersebut. Lingkungan pengembangan perangkat keras dan perangkat lunak berada
pada pondasi pyramid sumber daya dan menyediakan infrastruktur untuk mendukung
usaha pengembangan. Dalam tingkat yang lebih tinggi, kita menemukan komponen
perangkat lunak reusable-blok bangunan perngkat lunak yang dapat mengurangi
biaya pengembangan secara dramatis dan mempercepat penyampaian. Di puncak
piramida terdapat sumber daya utama-manusia (people). Masing-masing sumber
daya ditentukan dengan 4 karakteristik yaitu,

2018 Rekayasa Perangkat Lunak Pusat Bahan Ajar dan eLearning

3 Roni Yusman S,Kom, M.I.kom http://www.mercubuana.ac.id
 1. deskripsi sumber daya,
2. statement ketersediaan,
3. waktu kronologis sumber daya diperlukan,
4. serta durasi waktu sumber daya di aplikasikan.
Dua karakteristik terakhir dapat di lihat sebagai time windows (jendela waktu).
Tersedianya sumber daya untuk sebuah jendela khusus harus dibangun pada waktu
praktik paling awal.

Sumber Daya Manusia

Perencanaan sumber daya manusia memulai dengan mengevaluasi ruang
lingkup serat memilih kecakapan yang dibutuhkan untuk menyelesaikan
pengembangan. Baik posisi organisasi (seperti manajer, perekayasa perangkat lunak
senior, dan lain-lain) maupun specialty (seperti telekomunikasi, data base,
client/server) ditentukan. Untuk proyek yang sangat kecil (6 person- month atau
kurang), seorang individu dapat melakukan semua langkah rekayasa perangkat lunak,
berkonsultasi dengan spesialis bila diperlukan. Jumlah orang/manusia yang
diperlukan untuk sebuah proyek perangkat lunak dapat ditentukan hanya setelah
sebuah estimasi usaha pengembangan (seperti person-mount atau person-year)
dibuat.
Sumber Daya Perangkat Lunak Reusable
Setiap diskusi mengenai sumber daya perangkat lunak tidak akan lengkap
tanpa pengetahuan tentang reusabilitas, yaitu kreasi dan pengguanaan kembali blok
bangunan perangkat lunak. Blok-blok bangunan semacam itu harus di catalog menjadi
referensi yang mudah, distandarisasi untuk aplikasi yang mudah, dan divalidasi untuk
integrasi yang mudah. Beunatan mengusulkan 4 kategor sumber daya perangkat
lunak yang harus dipertimbangkan pada saat perencanaan berlangsung yaitu,
1. Komponen off-the-self.
Perangkat yang ada yang dapat diperoleh dari sebuah bagian ketiga
atau telah dikembangkan secara internal untuk pyoyek sebelumnya.
2. Komponen fuul experience.
Setiap anggota tim perangkat lunak saat ini memiliki pengalaman penuh
pada bidang aplikasi yang disajikan oleh komponen-komponen tersebut
sehingga modifikasi yang dibutuhkan bagi komponen full experience
secara relative resikonya akan lebih rendah.

2018 Rekayasa Perangkat Lunak Pusat Bahan Ajar dan eLearning

4 Roni Yusman S,Kom, M.I.kom http://www.mercubuana.ac.id
 3. Komponen partial experience.
Aplikasi, kode, desain atau data pengujian yang ada pada proyek yang
lalu yang dihubungkan dengan perangkat lunak yang dibangun untuk
proyek saat ini, tetapi akan membutuhkan modifikasi substansial.
4. Komponen baru.
Komponen perangkat lunak yang harus dibangun oleh tim perangkat
lunak khususnya adalah untuk kebutuhan proyek sekarang.
Sumber Daya Lingkungan
Lingkungan yang mendukung proyek perangkat lunak, yang disebut juga
software engineering environment (SEE), menggabungkan perangkat lunak dan
perangkat keras. Perangkat keras menyediakan sebuah platform yang mendukung
peranti yang di butuhkan untuk menghasilkan produk kerja yang merupakan keluaran
dari praktik rekayasa perangkat lunak yang baik.
Estimasi Proyek Perangkat Lunak
Ada sejumlah pilihan untuk mencapai estimasi biaya dan usaha yang dapat
dipertanggung jawabkan,
1. Menunda estimasi sampai akhir proyek (jelas kita dapat melakukan estimasi
yang 100% akurat bila proyek sudah selesai)
2. Mendasarkan estimasi pada proyek-proyek yang mirip yang sudah dilakukan
sebelumnya.
3. Menggunakan ‘teknik dekomposisi” yang relative sederhana untuk melakukan
estimasi biaya dan usaha proyek.
4. Menggunakan satu atau lebih model empiris bagi estimasi usaha dan biaya
perangkat lunak.
Peranti estimasi otomatis mengimplementasi satu atau lebih teknik
dekomposisi atau model empiris. Bila dikombinasi dengan interface manusia-mesin,
peranti otomatis akan memberikan pilihan yang atraktif untuk estimasi. Pada sistem
semacam itu, karakteristik organisasi pengembangan serta perangkat lunak yang
akan dikembangkan kemudian di gambarkan. Estimasi biaya dan usaha ditarik dari
data-data terebut. Masing-masing pilihan estimasi biaya perangkat lunak yang dapat
dilakukan sama baiknya dengan data historis yang digunakan untuk menumbuhkan
estimasi. Bila tidak ada data historis, maka pembiayaan akan menjadi tidak pasti.

2018 Rekayasa Perangkat Lunak Pusat Bahan Ajar dan eLearning

5 Roni Yusman S,Kom, M.I.kom http://www.mercubuana.ac.id
Teknik Dekomposisi
Estimasi proyek perangkat lunak merupakan bentuk pemecahan masalah. Dan
banyak kasus, masalah yang harus dipecahkan (yakni pengembangan estimasi biaya
dan usaha bagi sebuah proyek perangkat lunak) sangat kompleks untuk
dipertimbangkan sebagai satu bagian. Karena alasan tersebut, kita mendekomposisi
masalah, menandainya sebagai serangkaian masalah yang lebih kecil (yang
diharapkan lebih apat diatur).
Software Sizing Putnam dan mayers mengusulkan 4 pendekatan yang berbeda
terhadap ukuran penentuan masalah,
1. Fuzzy logic sizzing.
Pendekatan ini menggunakan teknik reasoning aproksimasi yang
merupakan dasar bagi fuzzy logic. Untuk menerapkan aplikasi ini,
perencana harus mengidentifikasi tipe aplikasi, membuat besarnya
aplikasi dalam skala kuantitatif, dan kemudian menyaring besaran itu
dalam rentang orisinil. Meskipun pengalaman personal dapat
digunakan, tetapi perencana harus memiliki akses terhadap database
historis dari proyek. Sehingga estimasi dapat dibandingkan dengan
pengalaman actual.
2. Function point sizing.
Perencana mengembangkan estimasi karakteristik domain informasi.
3. Standard component sizing.
Perangkat lunak dibangun dari sejumlah komponen standar yang
berbeda-beda yang umum bagi suatu area aplikasi tertentu. Contohnya,
komponen standar bagi sebuah sistem informasi adalah subsistem,
modul, layar, laporan, program-program interaktif, program batch, file,
dan instruksi tingkat objek.
4. Change sizing.
Pendekatan ini digunakan bila proyek melingkupi pemakaian perangkat
lunak yang ada yang harus dimodifikasi dengan banyak cara sebagai
bagian dari sebuah proyek.
Model Perkiraan Empiris
Model perkiraan untuk perangkat lunak computer 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

2018 Rekayasa Perangkat Lunak Pusat Bahan Ajar dan eLearning

6 Roni Yusman S,Kom, M.I.kom http://www.mercubuana.ac.id
sample proyek yang terbatas. Karena itulah maka tidak ada model perkiraan yang
sesuai untuk semua kelas perangkat lunak dan dalam semua lingkungan
pembangunan. Oleh karena itu hasil yang diperoleh dari model semacam itu harus
digunakan secara bijaksana.
Struktur Model Perkiraan
Model perkiraan tertentu ditarik menggunakan analisis regrisi terhadap data
yang dikumpulkan dari proyek perangkat lunak yang sebelumnya. Struktur
keseluruhan dari model semCm ini berbentuk [MAT94]
E = A B x (Ev)’
Dimana A, B, dan C adalah konstanta yang ditarik yang ditrik secara empiris,
E adalah usaha dalam person month, dan Ev adalah variable perkiraan (baik dalam
LOC maupun FP). Sebagai tambahan untuk hubungan yang dicatat pada persamaan,
mayoritas model perkiraan memiliki banyak bentuk komponen penyesuaian proyek
yang memungkinkan E disesuaikan dengan karakteristk proyek yang lain (misalnya
kompleksitas masalah, pengalaman staf, lingkungan pengembangan).
Komponen COCOMO
Model COCOMO ditetapkan untuk tiga kelas proyek perangkat lunak dedngan
menggunakan teknologi BOEHM. Persamaan COCOMO dasar berbentuk:
E = abKLOCbb
D = cbEdb
Dimana E adalah usaha yang di aplikasikan dalam person month, D adalah
waktu pengembangan dalam bulan kronologis, dan KLOC adalah jumlah baris
penyampaian kode yang di perkirakan untuk proyek tersebut (diekspresikan dalam
ribuan). Model COCOMO menengah berbentuk:
E = aiKOLCbi x EAF

Dimana E adalah usaha yang diaplikasikan dalam person month dan KLOC
mrupakan jumlah penyampaian kode yang diperkirakan bagi proyek.
Membuat Pohon Keputusan
Bila sistem akan di bangun dari permulaan,hanya ada 70 % probabilitas
sehingga pekerjanya menjdi sulit.Dengan menggunakan teknik estimasi yang
dibicarakan sebelumnya dalam bab ini,perencna proyek dapat memproyeksikan
bahwa usaha pengembangan yang sulit akan berbiaya $450.000.Usaha “sederhana

2018 Rekayasa Perangkat Lunak Pusat Bahan Ajar dan eLearning

7 Roni Yusman S,Kom, M.I.kom http://www.mercubuana.ac.id
diperkirakan akan menyedot biaya $380.000.Expected value untuk biaya,dihitung
sepanjang cabang pohon keputusan,adalah
Expcted cost = Σ ( jalur probabilitas )1 x ( biaya jalur terestimasi )
Di mana i adalah garis edar pohon keputusan.
Namun penting pula dicatat bahwa banyak kriteria bukan hanya biaya harus
dipertimbangkan selama proses pembuatan keputusan. Keberadaan, pengalaman
pengembang/vendor/kontraktor, penyesuaian terhadap kebutuhan “politik” lokal, dan
kecenderungan perubahan, juga merupakan beberapa kreteria yang dapat
mempengaruhi keputusan akhir untuk memilih garis build, reuse, buy atau contract.
Peranti Estimasi Otomatis
Teknik dekomosisi dan model perkiraan empiris yang digambarkan dalam
subbab yang sebelumnya dapat diperoleh sebagai bagian dari luasnya variasi peranti
perangkat lunak. Peranti perangkat lunak otomatis ini memungkinkan para perencana
memperkirakan biaya dan usaha serta melakukan analisis “what if” pada variable
proyek yang penting seperti tanggal penyampaian atau staffing. Meskipun ada banyak
peranti otomatis, tetapi semua memperlihatkan karakteristik umum dan semua
memerlukan satu atau lebih kategori data berikut ini:
1. Kuantitatif ukuran perangkat lunak (seperti LOC) atau fungsionalitas (data
function point)
2. Karakteristik proyek kualitatif seperti seperti kompleksitas, reliabilitas yang
dibutuhkan, atau tingkat kekritisan bisnis
3. Banyak gambaran staf pengembangan dan atau lingkungan pengembangan.
Dari data data tersebut, model yang diimplementasikan oleh peranti estimasi
otomatis akan memberikan estimasi usaha yang dibutuhkan untuk menyelesaikan
proyek, biaya, dan loading staf, durasi waktu, dan dalam beberapa kasus jadwal
pengembangan dan resiko.
Perbandingan menarik dari peranti estimasi otomatis dilakukan oleh Martin.
Sejumlah peranti yang berbeda di aplikasikan ke beberapa proyek. Tidaklah
mengejutkan jika terjadi variasi yang relative luas dalam hasil estimasi. Lebih penting
lagi, harga yang di prediksikan kadang-kadang sangat berbeda dengan harga actual.
Hal ini memperkuat pernyataan bahwa output peranti estimasi harus digunakan
sebagai satu “titik data” dari mana perkiraan itu ditarik dan bukan sebagai satu-
satunya sumber untuk melakukan perkiraan.

2018 Rekayasa Perangkat Lunak Pusat Bahan Ajar dan eLearning

8 Roni Yusman S,Kom, M.I.kom http://www.mercubuana.ac.id
Daftar Pustaka

Janner, Simarmata. 2010. Rekayasa Perangkat Lunak.Yogyakarta: Penerbit Andi

A. S., Rosa dan Shalahuddin, M. 2013. Rekayasa Perangkat Lunak Terstruktur Dan
Berorientasi Objek. Informatika. Bandung.
Bennet, Simon. McRobb, Steve.dan Farmer, Ray. 2005. “Object Oriented Systems Analysis
and Design Using UML. 3 rd Ed.”, . Great Britain: McGraw Hill. (BMF).
Bernd Bruegge & Allen H. Dutoit. 2013. “Object-Oriented Software Engineering Using UML
Patterns & Java”. Pearson.
Ganong, William F. 2002. “Pembelajaran Berbantuan Komputer (alih bahasa M. Djauhari
Wijayakusumah) Edisi Ketiga”, Jakarta : EGC.
Heinich, R, dkk. 2002. “Instructional media and technology for learning. 7th edition”. New
Jersey: Prentice Hall, Inc.
John W. Satzinger, R. B. 2012. “Systems Analysis and Design in a Changing World.” Joe
Sabatino.
Pressman, Roger S. 2002. “Rekayasa Perangkat Lunak : Pendekatan Praktisi (Buku Satu)”.
Yogyakarta : Andi Offset.

2018 Rekayasa Perangkat Lunak Pusat Bahan Ajar dan eLearning

9 Roni Yusman S,Kom, M.I.kom http://www.mercubuana.ac.id