Implementasi Pengukuran Perangkat Lunak (1)
7
BAB 2
LANDASAN TEORI
2.1 Pengukuran
2.1.1 Definisi Pengukuran
Pengukuran merupakan dasar dari setiap disiplin rekayasa dan berlaku juga dalam
perekayasaan perangkat lunak. Untuk mengevaluasi performa suatu system atau
proses diperlukan suatu mekanisme untuk mengamati dan menentukan tingkat
efisiensinya. Melalui pengukuran, maka akan diperoleh tingkat pencapaian di dalam
proyek perangkat lunak yang sedang diamati.
Pengukuran menurut IEEE adalah ukuran kuantitatif dari tingkat dimana
sebuah system, komponen atau proses memiliki atribut tertentu. Sedangkan mengukur
(measure) adalah mengindikasikan kuantitatif dari luasan, jumlah, dimensi dan
kapasitas. ( IEEE Std 610.12-1990, 1990)
Untuk setiap pengukuran yang dilakukan dibutuhkan tersedianya suatu ukuran
kuantitatif yang disebut metrik. Istilah ukuran, pengukuran dan metrik sering
digunakan secara bergantian. Metrik berdasarkan istilah rekayasa perangkat lunak
didefinisikan sebagai sebuah ukuran kuantitatif yang dimiliki oleh suatu system,
komponen atau proses tertentu dengan attribute-atribute yang diberikan. Oleh karena
itu, untuk selanjutnya akan digunakan istilah metrik untuk menyebutkan pengukuran
dalam pengukuran perangkat lunak
2.1.2 Metrik Perangkat Lunak
Ukuran merupakan faktor utama untuk menentukan biaya, penjadwalan, dan usaha.
Kegagalan dari perkiraan ukuran yang tepat akan mengakibatkan penggunaan biaya
yang berlebih atau keterlambatan penyelesaian proyek.
Universitas Sumatera Utara
8
Menurut Sommerville (2003), pengukuran terbagi atas dua, yaitu pengukuran
(metrik) kontrol dan pengukuran (metrik) prediktor. Metrik kontrol biasanya
dihubungkan dengan proses perangkat lunak, misalnya usaha dan waktu rata-rata yang
dibutuhkan untuk memperbaiki cacat yang dilaporkan. Sedangkan metrik prediktor
berhubungan dengan produk perangkat lunak, misalnya kompleksitas sikomatik
modul, panjang rata-rata identifier pada program dan jumlah atribut dan operasi yang
berhubungan dengan objek pada suatu rancangan.
Metrik juga dapat dipisahkan dalam dua kategori, yaitu metrik langsung dan
metrik tidak langsung. Metrik langsung dalam proses rekayasa perangkat lunak
berhubungan dengan biaya dan sumber daya yang diperlukan, misalnya: pengukuran
jumlah baris kode, kecepatan eksekusi, ukuran memori, dan kesalahan yang ditemui
dalam suatu periode waktu. Metrik tidak langsung dari suatu produk berhubungan
dengan fungsionalitas, kualitas, kompleksitas, efisiensi, reliabilitas, dan lain
sebagainya. Pengukuran secara langsung lebih mudah dilakukan, karena hasil dapat
diperoleh secara langsung, sedangkan pengukuran tidak langsung lebih sulit
dilakukan, karena harus melalui proses yang lebih kompleks.
Metrik dipisahkan menjadi metrik proses, proyek, dan produk. Metrik produk
bersifat privat untuk individu dan sering dikombinasikan untuk membuat metrik
proyek yang bersifat publik bagi tim pengembang. Metrik proyek kemudian
dikonsolidasikan untuk membuat metrik proses yang publik untuk seluruh organisasi
atau perusahaan. Kesulitan yang biasanya dihadapi adalah pada saat melakukan
kombinasi pada metrik-metrik yang diukur disebabkan karena sering terjadi perbedaan
metrik antara individu satu dengan individu lainnya. Masalah tersebut biasa diatasi
apabila dilakukan normalisasi pada proses pengukuran. Dengan adanya normalisasi
maka dapat dilakukan perbandingan metrik pada cakupan yang lebih luas.
2.2 Metrik Dalam Proses dan Domain Proyek
Metrik harus dikumpulkan sehingga indikator proses dan produk dapat dipastikan.
Indikator proses memungkinkan sebuah organisasi rekayasa perangkat lunak
memperoleh pengetahuan tentang reliabilitas sebuah proses yang sedang berlangsung
Universitas Sumatera Utara
9
(misalnya paradigma, tugas-tugas rekayasa perangkat lunak, produk kerja, dan
kejadian penting). Indikator proses memungkinkan manajer dan pelaksana
memperkirakan apa yang harus dikerjakan dan yang tidak.
Indikator proyek memungkinkan manajer proyek perangkat lunak :
a. Memperkirakan status sebuah proyek yang sedang berlangsung
b. Menelusuri risiko-risiko potensial
c. Menemukan area masalah sebelum masalah ”menjadi semakin kritis”
d. Menyesuaikan aliran kerja atau tugas-tugas; dan
e. Mengevaluasi kemampuan tim proyek untuk mengontrol kualitas hasil kerja
rekayasa perangkat lunak
2.2.1 Metrik Proses dan Peningkatan Perangkat Lunak
Satu-satunya cara yang paling rasional untuk meningkatkan proses adalah dengan
mengukur atribut tertentu dari proses, mengembangkan serangkaian metrik yang
berarti berdasarkan atribut-atribut tersebut, dan kemudian menggunakan metrik itu
untuk memberikan indikator yang akan membawa kepada sebuah strategi
pengembangan.
Keterampilan dan motivasi yang diperlihatkan oleh manusia merupakan satusatunya faktor yang paling berpengaruh pada kualitas dan unjuk kerja tim. Kita
mengukur reliabilitas proses perangkat lunak secara tidak langsung yaitu dengan
mengambil serangkaian metrik berdasarkan keluaran yang dapat diambil oleh proses.
Keluaran menyangkut pengukuran kesalahan yang ditemukan sebelum pelepasan
perangkat lunak, cacat yang disampaikan dan dilaporkan oleh pemakai akhir, produk
kerja yang dikirim, usaha manusia yang dilakukan, waktu kalender yang digunakan,
konfirmasi jadwal, serta pengukuran yang lain.
Menurut Sommerville, ada tiga kelas metrik proses:
a. Waktu yang dibutuhkan untuk penyelesaian proses tertentu. Bisa merupakan
waktu total yang dicurahkan untuk proses, waktu kalender, waktu yang
dihabiskan pada proses oleh insinyur tertentu dan sebagainya.
Universitas Sumatera Utara
10
b. Sumber daya yang dibutuhkan untuk suatu proses tertentu. Sumber Daya bisa
berupa usaha dalam orang-hari, biaya perjalanan, sumber daya komputer, dan
lain-lain.
c. Jumlah terjadinya even tertentu. Contoh event yang dapat dipantau mencakup
jumlah cacat yang ditemukan pada saat inspeksi kode, jumlah perubahan
persyaratan yang diminta, jumlah rata-rata baris kode yang dimodifikasi
sebagai tanggapan terhadap perubahan persyaratan dan lain-lain
Grady menyatakan bahwa ”etika metrik perangkat lunak” merupakan hal yang
tepat bagi para manajer ketika mereka melembagakan program metrik proses:
a. Gunakan istilah umum dan kepekaan organisasi ketika menginterpretasi data
metrik.
b. Berikan umpan balik reguler kepada individu dan tim yang telah bekerja untuk
mengumpulkan pengukuran dan metrik.
c. Jangan menggunakan metrik untuk menilai individu
d. Bekerja dengan pelaksana dan tim untuk menentukan tujuan dan metrik yang jelas
yang akan dipakai untuk mencapainya.
e. Jangan pernah menggunakan metrik untuk mengancam individu dan tim.
f. Metrik data yang menunjukkan sebuah area masalah tidak boleh “dianggap
negative.” Data-data itu hanya merupakan sebuah indicator bagi peningkatan
proses.
g. Jangan tergoda pada sebuah metrik dan kemudian mengabaikan metrik penting
yang lain.
Pada dasarnya statistical software process improvement (SSPI) menggunakan
analisis kegagalan perangkat lunak untuk mengumpulkan informasi seputar semua
kesalahan dan cacat yang terjadi pada saat sebuah aplikasi, sistem, atau produk
dikembangkan dan dipakai. Analisis kegagalan bekerja dengan cara sebagai berikut :
a. Semua kesalahan dan cacat dikategorikan dari awal (contohnya, kekurangan
dalam spesifikasi, kekurangan dalam logika, ketidaksesuaian dengan standar).
Universitas Sumatera Utara
11
b. Biaya untuk mengkoreksi setiap kesalahan dan cacat dicatat.
c. Jumlah kesalahan dan cacat dari setiap kategori dihitung dan ditata dalam
urutan naik.
d. Biaya keseluruhan dari kesalahan dan cacat dari setiap kategori dihitung.
e. Data resultan dianalisis untuk menemukan kategori yang menelan biaya besar.
f. Rencana dikembangkan untuk memodifikasi proses guna mengeliminasi
(mengurangi frekuensi kejadian) kelas kesalahan dan cacat yang paling
membutuhkan banyak biaya.
2.2.2 Metrik Proyek
Metrik yang dikumpulkan dari proyek terdahulu digunakan sebagai dasar yang dari
sana perkiraan usaha dan durasi waktu dibuat untuk kerja perangkat lunak saat ini.
Selagi sebuah proyek berjalan, pengukuran usaha dan waktu kalender yang digunakan
dibandingkan dengan perkiraan awal (dan jadwal proyek).
Nilai produksi yang disajikan dalam bentuk halaman dokumentasi, jam kajian,
titik-titik fungsi, dan deretan sumber yang disampaikan diukur serta kesalahan yang
ditemukan selama masing-masing tugas kerja rekayasa perangkat lunak kemudian
ditelusuri.
Metrik proyek mempunyai tujuan ganda. Pertama, metrik tersebut digunakan
untuk meminimalkan jadwal pengembangan dengan melakukan penyesuaian yang
diperlukan untuk menghindar penundaan serta mengurangi masalah dan risiko
potensial. Kedua, metrik proyek dipakai untuk memperkirakan kualitas produk pada
basis yang berlaku dan bila dibutuhkan, memodifikasi pendekatan teknis untuk
meningkatkan kualitas.
Model lain dari metrik proyek mengusulkan bahwa setiap proyek
seharusnya mengukur :
a. input (pengukuran sumber daya seperti manusia, lingkungan yang
dibutuhkan untuk melakukan pekerjaan).
Universitas Sumatera Utara
12
b. Output (pengukuran kemampuan penyampaian atau produk kerja yang
diciptakan selama proses rekayasa perangkat lunak).
c. Hasil
(pengukuran
yang
menunjukkan
efektivitas
kemampuan
penyampaian).
.
2.3 Mengimplementasikan Metrik pada Perangkat Lunak
Implementasi metrik pada perangkat lunak berkaitan erat dengan estimasi usaha dan
biaya kegiatan proyek perangkat lunak. Produktivitas pada sistem dapat diukur dengan
menghitung jumlah satuan yang dihasilkan dan membagi nilai ini dengan jumlah
orang-jam yang dibutuhkan untuk menghasilkannya. Estimasi produktivitas biasanya
berdasar atas pengukuran beberapa atribut perangkat lunak dan membaginya dengan
usaha total yang dibutuhkan untuk pengembangan. Ada dua jenis pengukuran yang
telah dipakai:
a. Metrik yang berhubungan dengan ukuran.
Pengukuran ini berhubungan dengan ukuran output dari suatu kegiatan.
Pengukuran yang berhubungan dengan ukuran yang paling umum adalah
jumlah baris kode sumber yang diserahkan. Pengukuran lain yang dapat
digunakan adalah jumlah instruksi kode objek yang diserahkan atau jumlah
halaman dokumentasi sistem.
b. Metrik yang berhubungan dengan fungsi.
Pengukuran ini berhubungan dengan fungsionalitas menyeluruh dari perangkat
lunak yang diserahkan. Produktivitas dinyatakan dalam jumlah fungsionalitas
yang berguna dalam waktu tertentu. Poin fungsi dan poin objek merupakan
pengukuran yang paling dikenal dari jenis ini.
Estimasi ukuran software merupakan suatu aktifitas yang komplek dan sukar
berdasarkan pada beberapa alas an seperti kemampuan programmer, faktor
lingkungan dan sebagainya. Tetapi karena tindakan ini harus dilakukan dan untuk
mendapatkannya dengan mengukur ukuran proyek menggunakan ukuran seperti
jumlah baris program (Source lines of code/SLOC) dan Function Points.
Universitas Sumatera Utara
13
2.3.1 Pengukuran Yang Berhubungan Dengan Ukuran
Pegukuran yang berhubungan dengan ukuran (Metric Size Oriented) adalah
pengukuran dengan normalisasi kualitas dan produktifitas atau mempertimbangkan
ukuran perangkat lunak yang dihasilkan. Metric size oriented dilakukan dengan
menghitung LOC (Line of Code) dari baris kode suatu perangkat lunak. Pada
pengembangan, pengukuran ini juga dapat mengukur:
h. Kesalahan per KLOC (Kilo Line Of Code)
i. Biaya per LOC
j. Cacat per LOC
k. Halaman dokumentasi per LOC
l. Kesalahan perorang perbulan
m. LOC perorang perbulan
n. Biaya perhalaman dokumentasi.
Menurut Jones (Pressman,2001) LOC merupakan ukuran yang kurang akurat
dan merupakan sebuah topik yang menimbulkan perdebatan selama bertahun-tahun,
dipandang sebagai sebuah ukuran untuk mengestimasi biaya dan waktu, tidak dapat
dipastikan bahwa dua program yang mempunyai LOC sama akan membutuhkan
waktu implementasi yang sama walaupun keduanya diimplementasikan dengan
kondisi pemrograman yang standard. Meskipun metode ini kurang akurat dan
merupakan metodologi yang belum diterima secara luas, tetapi metrik dengan
orientasi ukuran ini merupakan kunci pengukuran dan banyak estimasi software yang
menggunakan model ini.
Secara virtual tidak mungkin untuk menghitung LOC dari dokumen
requirement awal. LOC pengukurannya didasarkan pada bahasa pemrograman
tertentu, oleh karena itu muncul banyak masalah dalam membuat standard pengukuran
dengan teknik LOC. Ukuran lain yang ada untuk mengukur besaran software adalah
Universitas Sumatera Utara
14
ukuran yang berorientasi fungsi dan ukuran yang berorientasi object. Metode ini
merupakan metode yang lebih konsisten dan diterima secara luas.
2.3.2 Pengukuran yang Berhubungan dengan Function Point
Pengukuran yang berhubungan dengan fungsi (Metric Function Oriented) adalah
pengukuran fungsionalitas yang disampaikan oleh aplikasi sebagai suatu nilai
normalisasi. Perhitungan dengan metode Function Point menuntut untuk dilakukan
oleh seorang profesional yang berpengalaman karena memiliki tingkat subyektifitas
yang cukup tinggi. Metrik berorientasi fungsi diusulkan oleh Albrecth pada tahun
1979, yang menyarankan pengukuran yang disebut Function Point. Function Point
tidak bergantung pada bahasa sehingga produktivitas pada bahasa pemrograman yang
berbeda dapat dibandingkan. Produktivitas dinyatakan sebagai poin fungsi yang
dihasilkan per orang-bulan. Function Point di-bias menuju system pemrosesan data
yang didominasi oleh operasi input dan output. Metode ini sendiri terdiri dari banyak
varia. Variasi yang adalah pada langkah/tahapan yang ada maupun pada isi dari tiap
tahapan. Varian-varian ini timbul karena metode ini dapat diubah sesuai dengan
kebijakan perusahaan pengembang software. Namun apapun varian yang digunakan
oleh pengembang, hendaknya digunakan dengan konsisten agar tercipta komparasi
yang benar antara software-software yang dinilai.
Metode dalam metrik ini berdasarkan publikasi varian yang populer seperti
Gramus dan Herron, IEEE, Caldiera (Pressman, 2001) yang menghasilkan manual
penggunaan function point seperi IFPUG 3, IFPUG 4 dan Mark II. Tahapan-tahapan
yang ada dalam menentukan function point adalah sebagai berikut :
Langkah 1 : Menghitung crude function points (CFP)
Jumlah dari komponen fungsional sistem pertama kali diidentifikasi dan dilanjutkan
dengan mengevaluasi kuantitasi bobot kerumitan dari tiap komponen tersebut.
Pembobotan tersebut kemudian dijumlahkan dan menjadi angka CFP.
Perhitungan CFP melibatkan 5 tipe komponen sistem software berikut :
a. Jumlah macam aplikasi input (user inputs)
b. Jumlah macam aplikasi output (user outputs)
Universitas Sumatera Utara
15
c. Jumlah macam aplikasi query online – aplikasi ini berhubungan dengan query
terhadap data yang tersimpan (Inquiry)
d. Jumlah macam file/tabel logic yang terlibat
e. Jumlah macam interface eksternal – output atau input yang dapat berhubungan
dengan komputer lewat komunikasi data, CD, disket, dan lain-lain.
Kemudian diberikan faktor bobot pada tiap komponen di atas berdasarkan
kompleksitasnya. Tabel 2.1 di bawah ini merupakan contoh blanko pembobotan
tersebut.
Tabel 2.1 Blanko penghitungan CFP
Komponen
Sistem
Software
Input
Output
Query
Online
File logic
Interface
Eksternal
Total CFP
Total
CFP
Level kompleksitas
Sederhana
Count Faktor Point
Bobot
A
B
C=
AxB
3
4
3
Menengah
Count Faktor Point
Bobot
D
E
F=
DxE
4
5
4
7
5
10
7
Kompleks
Faktor Point
Bobot
G
H
I=
GxH
6
7
6
Count
J=C+F+I
15
10
Langkah 2 : Menghitung faktor pengubah kompleksitas relatif/Relative
Complexity Adjustment Factor (RCAF).
RCAF berfungsi untuk menghitung kesimpulan kompleksitas dari sistem software dari
beberapa subyek karakteristik. Penilaian berskala 0 sampai 5 diberikan pada tiap
subyek yang paling berpengaruh terhadap usaha pengembangan yang dibutuhkan.
Blanko penilaian yang diusulkan penulis diberikan seperti Tabel 2.2
Tabel 2.2 Blanko penghitungan RCAF
No
Subyek
Nilai
1
Tingkat kompleksitas kehandalan backup/recovery
012345
2
Tingkat kompleksitas komunikasi data
012345
3
Tingkat kompleksitas pemrosesan terdistribusi
012345
Universitas Sumatera Utara
16
4
Tingkat kompleksitas kebutuhan akan kinerja
012345
5
Tingkat kebutuhan lingkungan operasional
012345
6
Tingkat kebutuhan knowledge pengembang
012345
7
Tingkat kompleksitas updating file master
012345
8
Tingkat kompleksitas instalasi
012345
9
Tingkat kompleksitas aplikasi input, output, query online dan file
012345
10
Tingkat kompleksitas pemrosesan data
012345
11
Tingkat ketidakmungkinan penggunaan kembali dari kode (reuse)
012345
12
Tingkat variasi organisasi pelanggan
012345
13
Tingkat kemungkinan perubahan/fleksibilitas
012345
14
Tingkat kebutuhan kemudahan penggunaan
012345
Total = RCAF
Langkah 3 : Menghitung Function Point (FP)
Nilai function point untuk sistem software tersebut kemudian dihitung berdasarkan
hasil dari tahap 1 dan 2 yang dimasukkan ke dalam formula
FP = CFP x (0.65 + 0.01 x RCAF)
(2.1)
2.4 Estimasi Proyek Perangkat Lunak
Estimasi biaya dan tenaga sukar untuk menjadi sebuah ilmu pasti. Banyak
faktor seperti manusia, teknis, lingkungan, atau politik, yang dapat mempengaruhi
besarnya biaya dan tenaga yang diperlukan untuk mengembangkan perangkat lunak.
Bagaimanapun juga, estimasi proyek perangkat lunak dapat ditransformasikan dari
sesuatu yang abstrak menjadi suatu urutan langkah langkah sistematis yang
menghasilkan perkiraan-perkiraan dengan tingkat resiko yang dapat diterima.
Ada beberapa cara yang dapat digunakan untuk melakukan perkiraan proyek:
1. Perkiraan keterlambatan suatu proyek dapat diselesaikan
2. Perkiraan berdasarkan proyek serupa yang telah selesai dikerjakan
Universitas Sumatera Utara
17
3. Menggunakan teknik dekomposisi sederhana untuk membuat suatu kisaran
biaya dan tenaga
4. Menggunakan satu atau lebih model empiris untuk perkiraan biaya dan tenaga
Teknik yang disarankan oleh para ahli di bidang perangkat lunak adalah dengan
menggunakan kombinasi antara teknik dekomposisi dan model empiris. Teknik
dekomposisi menggunakan pendekatan dengan cara membagi suatu proyek ke dalam
beberapa fungsi mayor yang berhubungan dengan aktivitas rekayasa perangkat lunak.
Model estimasi empiris dapat digunakan sebagai pelengkap bagi teknik dekomposisi.
2.4.1 Estimasi Berbasis Masalah
Estimasi berbasis LOC dan FP memiliki teknik yang unik. Keduanya memiliki
karakteristik sendiri. Perencana proyek memulai dengan kumpulan pernyataan yang
berisi kerangka dan batasan-batasan dari perangkat lunak dan dari peryataanpernyataan tersebut kemudian mencoba untuk melakukan dekomposisi perangkat
lunak ke dalam banyak fungsi permasalahan (problem function) dan melakukan
estimasi variabel-variabel (LOC dan FP) pada tiap fungsi permasalahan. Sebagai
alternatif, perencana proyek dapat memilih komponen untuk menentukan ukuran,
seperti kelas obyek, perubahan, atau proses bisnis yang terpengaruh.
Metrik produktivitas (misalnya: LOC/pm atau FP/pm9) diaplikasikan ke dalam
variabel estimasi. Akronim pm digunakan untuk menyatakan satuan person-month
(orang-bulan). Metrik kemudian dikombinasikan untuk memperoleh estimasi dari
keseluruhan proyek. Dengan menggunakan data dari proyek di masa lalu, perencana
proyek dapat membagi nilai perkiraan ke dalam nilai ukuran (S),
2.5 Model Estimasi Empiris
Model estimasi perangkat lunak menggunakan formula yang diperoleh secara
empiris untuk memperkirakan tenaga sebagai sebuah fungsi dari LOC atau FP. Data
empiris yang paling banyak mendukung dalam model-model estimasi diperoleh dari
sampel proyek yang jumlahnya terbatas. Dengan alasan ini, maka tidak ada model
Universitas Sumatera Utara
18
estimasi yang cocok untuk semua lingkungan pengembangan perangkat lunak. Maka
dari itu, penerapan hasil yang diperoleh dari model-model yang sudah disediakan
harus digunakan secara bijaksana sesuai dengan keadaan lingkungan masing-masing
pengembang.
2.5.1 Struktur Model-Model Estimasi
Model estimasi diperoleh melalui analisis regresi pada data yang diperoleh
pada proyek-proyek di masa lalu. Keseluruhan struktur dari beberapa model
mengambil dari persamaan yang dipaparkan oleh Matson ( Matson, 1994):
E = A + B x (ev)C
(2-3)
Dimana E adalah effort dalam orang-bulan, dan A, B, C adalah konstanta yang
diperoleh secara empiris. Dalam perkembangannya persamaan tersebut dikembangkan
sesuai dengan proyek yang dikerjakan oleh masing-masing pengembang perangkat
lunak. Perbedaan persamaan yang digunakan oleh masing-masing pengembang
dikarenakan persamaan tersebut harus dikalibrasi terlebih dahulu, sesuai dengan
kondisi maupun kebutuhan.
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
(2.4)
E = 5,5 + 0,73 x (KLOC)1,16 Baily-Basili Model
E = 3,2 x (KLOC)
1,05
E = 5,288 x (KLOC)1,047
(2.5)
Model sederhana Boehm
(2.6)
Dotu Model untuk KLOC > 9
(2.7)
Model-model orientasi FP juga telah diusulkan, yaitu :
E = -13,39 + 0,0545 FP
-8
E = 60,62 x 7,728 x 10 FP
E = 585,7 + 15,12 FP
3
Albercht dan Gaffney Model
(2.8)
Kemerer Model
(2.9)
Matson, Barnett, dan Mellichamp
(2.10)
Universitas Sumatera Utara
19
2.5.2 Model COCOMO
COCOMO adalah sebuah model yang didesain oleh Barry Boehm untuk
memperoleh
perkiraan
dari
jumlah
orang-bulan
yang
diperlukan
untuk
mengembangkan suatu produk perangkat lunak. Satu hasil observasi yang paling
penting dalam model ini adalah bahwa motivasi dari tiap orang yang terlibat
ditempatkan sebagai titik berat. Hal ini menunjukkan bahwa kepemimpinan dan kerja
sama tim merupakan sesuatu yang penting, namun demikian poin pada bagian ini
sering diabaikan.
Model COCOMO dapat diaplikasikan dalam tiga tingkatan kelas:
1. Proyek organik, adalah proyek dengan ukuran relatif kecil, dengan anggota tim
yang sudah berpengalaman, dan mampu bekerja pada permintaan yang relatif
fleksibel.
2. Proyek sedang (semi-terpisah), adalah proyek yang memiliki ukuran dan tingkat
kerumitan yang sedang, dan tiap anggota tim memiliki tingkat keahlian yang
berbeda.
3. Proyek terintegrasi, adalah proyek yang dibangun dengan spesifikasi dan operasi
yang ketat.
Persamaan dasar model COCOMO adalah:
E = ab (KLOC)bb
(2.11)
D = cb (E)db
(2.12)
P=E/D
(2.13)
Dimana E adalah usaha dalam orang-bulan, D adalah waktu pengerjaan dalam
satuan bulan, KLOC adalah estimasi jumlah baris kode dalam ribuan, dan P adalah
jumlah orang yang diperlukan. Koefisien ab, bb, cb, dan db diberikan pada tabel
berikut:
Universitas Sumatera Utara
20
Tabel 2.3 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
Hirarki model Boehm berbentuk sebagai berikut:
Model 1 :
Model COCOMO Dasar menghitung usaha pengembangan perangkat
lunak (dan biaya) sebagai fungsi dari ukuran prgram yang
diekspresikan dalam baris kode yang diestimasi.
Model 2 :
Model COCOMO Intermediate menghitung usaha pengembangan
perangkat lunak 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, dan lain-lain) dari proses
rekayasa perangkat lunak.
Pengembangan model COCOMO adalah dengan menambahkan atribut yang
dapat menentukan jumlah biaya dan tenaga dalam pengembangan perangkat lunak,
yang dijabarkan dalam kategori dan subkategori sebagai berikut:
1. Atribut produk
a. Reliabilitas perangkat lunak yang diperlukan
b. Ukuran basis data aplikasi
c. Kompleksitas produk
2. Atribut perangkat keras
a. Performa program ketika dijalankan
b. Memori yang dipakai
c. Stabilitas mesin virtual
d. Waktu yang diperlukan untuk mengeksekusi perintah
Universitas Sumatera Utara
21
3. Atribut Sumber Daya Manusia
a. Kemampuan analisis
b. Kemampuan ahli perangkat lunak
c. Pengalaman membuat aplikasi
d. Pengalaman menggunakan mesin virtual
e. Pengalaman dalam menggunakan bahasa pemrograman
4. Atribut proyek
a. Menggunakan perangkat lunak tambahan
b. Metode rekayasa perangkat lunak
c. Waktu yang diperlukan
Masing-masing subkategori diberi bobot antara 0 (sangat rendah) sampai 6 (sangat
tinggi), dan kemudian dijumlahkan. Dari pengembangan ini diperoleh persamaan:
E=ai(KLOC)(b)i.EAF
(2.14)
2.5.3 Persamaan pada Perangkat Lunak
Persamaan perangkat lunak merupakan model variabel jamak yang
menghitung suatu distribusi spesifik dari usaha pada jalannya pengembangan
perangkat lunak. Persamaan berikut ini diperoleh dari hasil pengamatan terhadap lebih
dari 4000 proyek perangkat lunak:
E = [LOC x B0.333/P]3 x (1 / t4)
(2.15)
E = usaha dalam orang-bulan atau orang-tahun
t = durasi proyek dalam bulan atau tahun
B = faktor kemampuan khusus
P = parameter produktivitas
Nilai B diambil dengan berdasarkan perkiraan. Untuk program berukuran kecil (0.5 <
KLOC < 5), B = 0.16. Untuk program yang lebih besar dari 70 KLOC, B = 0.39.
Universitas Sumatera Utara
22
Nilai P merefleksikan:
1. Kematangan proses dan praktek manajemen
2. Kualitas rekayasa perangkat lunak
3. Tingkat bahasa pemrograman yang digunakan
4. Keadaan lingkungan perangkat lunak
5. Kemampuan dan pengalaman tim pengembang
6. Kompleksitas aplikasi
Berdasarkan teori, diperoleh P = 2000 untuk sistem terapan, P = 10000 untuk
perangkat lunak pada sistem informasi dan sistem telekomunikasi, dan P = 28000
untuk sistem aplikasi bisnis.
2.6 Konversi Waktu Tenaga Kerja
Konversi waktu tenaga kerja pada tugas akhir ini ini diperoleh dari angka pembanding
yang digunakan pada rata-rata pengerjaan proyek perangkat lunak (Sommervile,
2003), dengan hubungan persamaan antara orang-bulan (OB), orang-jam (OJ), orangminggu (OM), dan orang-tahun (OT) adalah sebagai berikut:
OM = 40 OJ
OT = 12 OB
OT = 52 OM
Dari persamaan di atas, diperoleh konversi orang-bulan ke orang-jam
sebagai berikut
OB = (40 OJ x 52) / 12
OB = 173,33 OJ
Universitas Sumatera Utara
BAB 2
LANDASAN TEORI
2.1 Pengukuran
2.1.1 Definisi Pengukuran
Pengukuran merupakan dasar dari setiap disiplin rekayasa dan berlaku juga dalam
perekayasaan perangkat lunak. Untuk mengevaluasi performa suatu system atau
proses diperlukan suatu mekanisme untuk mengamati dan menentukan tingkat
efisiensinya. Melalui pengukuran, maka akan diperoleh tingkat pencapaian di dalam
proyek perangkat lunak yang sedang diamati.
Pengukuran menurut IEEE adalah ukuran kuantitatif dari tingkat dimana
sebuah system, komponen atau proses memiliki atribut tertentu. Sedangkan mengukur
(measure) adalah mengindikasikan kuantitatif dari luasan, jumlah, dimensi dan
kapasitas. ( IEEE Std 610.12-1990, 1990)
Untuk setiap pengukuran yang dilakukan dibutuhkan tersedianya suatu ukuran
kuantitatif yang disebut metrik. Istilah ukuran, pengukuran dan metrik sering
digunakan secara bergantian. Metrik berdasarkan istilah rekayasa perangkat lunak
didefinisikan sebagai sebuah ukuran kuantitatif yang dimiliki oleh suatu system,
komponen atau proses tertentu dengan attribute-atribute yang diberikan. Oleh karena
itu, untuk selanjutnya akan digunakan istilah metrik untuk menyebutkan pengukuran
dalam pengukuran perangkat lunak
2.1.2 Metrik Perangkat Lunak
Ukuran merupakan faktor utama untuk menentukan biaya, penjadwalan, dan usaha.
Kegagalan dari perkiraan ukuran yang tepat akan mengakibatkan penggunaan biaya
yang berlebih atau keterlambatan penyelesaian proyek.
Universitas Sumatera Utara
8
Menurut Sommerville (2003), pengukuran terbagi atas dua, yaitu pengukuran
(metrik) kontrol dan pengukuran (metrik) prediktor. Metrik kontrol biasanya
dihubungkan dengan proses perangkat lunak, misalnya usaha dan waktu rata-rata yang
dibutuhkan untuk memperbaiki cacat yang dilaporkan. Sedangkan metrik prediktor
berhubungan dengan produk perangkat lunak, misalnya kompleksitas sikomatik
modul, panjang rata-rata identifier pada program dan jumlah atribut dan operasi yang
berhubungan dengan objek pada suatu rancangan.
Metrik juga dapat dipisahkan dalam dua kategori, yaitu metrik langsung dan
metrik tidak langsung. Metrik langsung dalam proses rekayasa perangkat lunak
berhubungan dengan biaya dan sumber daya yang diperlukan, misalnya: pengukuran
jumlah baris kode, kecepatan eksekusi, ukuran memori, dan kesalahan yang ditemui
dalam suatu periode waktu. Metrik tidak langsung dari suatu produk berhubungan
dengan fungsionalitas, kualitas, kompleksitas, efisiensi, reliabilitas, dan lain
sebagainya. Pengukuran secara langsung lebih mudah dilakukan, karena hasil dapat
diperoleh secara langsung, sedangkan pengukuran tidak langsung lebih sulit
dilakukan, karena harus melalui proses yang lebih kompleks.
Metrik dipisahkan menjadi metrik proses, proyek, dan produk. Metrik produk
bersifat privat untuk individu dan sering dikombinasikan untuk membuat metrik
proyek yang bersifat publik bagi tim pengembang. Metrik proyek kemudian
dikonsolidasikan untuk membuat metrik proses yang publik untuk seluruh organisasi
atau perusahaan. Kesulitan yang biasanya dihadapi adalah pada saat melakukan
kombinasi pada metrik-metrik yang diukur disebabkan karena sering terjadi perbedaan
metrik antara individu satu dengan individu lainnya. Masalah tersebut biasa diatasi
apabila dilakukan normalisasi pada proses pengukuran. Dengan adanya normalisasi
maka dapat dilakukan perbandingan metrik pada cakupan yang lebih luas.
2.2 Metrik Dalam Proses dan Domain Proyek
Metrik harus dikumpulkan sehingga indikator proses dan produk dapat dipastikan.
Indikator proses memungkinkan sebuah organisasi rekayasa perangkat lunak
memperoleh pengetahuan tentang reliabilitas sebuah proses yang sedang berlangsung
Universitas Sumatera Utara
9
(misalnya paradigma, tugas-tugas rekayasa perangkat lunak, produk kerja, dan
kejadian penting). Indikator proses memungkinkan manajer dan pelaksana
memperkirakan apa yang harus dikerjakan dan yang tidak.
Indikator proyek memungkinkan manajer proyek perangkat lunak :
a. Memperkirakan status sebuah proyek yang sedang berlangsung
b. Menelusuri risiko-risiko potensial
c. Menemukan area masalah sebelum masalah ”menjadi semakin kritis”
d. Menyesuaikan aliran kerja atau tugas-tugas; dan
e. Mengevaluasi kemampuan tim proyek untuk mengontrol kualitas hasil kerja
rekayasa perangkat lunak
2.2.1 Metrik Proses dan Peningkatan Perangkat Lunak
Satu-satunya cara yang paling rasional untuk meningkatkan proses adalah dengan
mengukur atribut tertentu dari proses, mengembangkan serangkaian metrik yang
berarti berdasarkan atribut-atribut tersebut, dan kemudian menggunakan metrik itu
untuk memberikan indikator yang akan membawa kepada sebuah strategi
pengembangan.
Keterampilan dan motivasi yang diperlihatkan oleh manusia merupakan satusatunya faktor yang paling berpengaruh pada kualitas dan unjuk kerja tim. Kita
mengukur reliabilitas proses perangkat lunak secara tidak langsung yaitu dengan
mengambil serangkaian metrik berdasarkan keluaran yang dapat diambil oleh proses.
Keluaran menyangkut pengukuran kesalahan yang ditemukan sebelum pelepasan
perangkat lunak, cacat yang disampaikan dan dilaporkan oleh pemakai akhir, produk
kerja yang dikirim, usaha manusia yang dilakukan, waktu kalender yang digunakan,
konfirmasi jadwal, serta pengukuran yang lain.
Menurut Sommerville, ada tiga kelas metrik proses:
a. Waktu yang dibutuhkan untuk penyelesaian proses tertentu. Bisa merupakan
waktu total yang dicurahkan untuk proses, waktu kalender, waktu yang
dihabiskan pada proses oleh insinyur tertentu dan sebagainya.
Universitas Sumatera Utara
10
b. Sumber daya yang dibutuhkan untuk suatu proses tertentu. Sumber Daya bisa
berupa usaha dalam orang-hari, biaya perjalanan, sumber daya komputer, dan
lain-lain.
c. Jumlah terjadinya even tertentu. Contoh event yang dapat dipantau mencakup
jumlah cacat yang ditemukan pada saat inspeksi kode, jumlah perubahan
persyaratan yang diminta, jumlah rata-rata baris kode yang dimodifikasi
sebagai tanggapan terhadap perubahan persyaratan dan lain-lain
Grady menyatakan bahwa ”etika metrik perangkat lunak” merupakan hal yang
tepat bagi para manajer ketika mereka melembagakan program metrik proses:
a. Gunakan istilah umum dan kepekaan organisasi ketika menginterpretasi data
metrik.
b. Berikan umpan balik reguler kepada individu dan tim yang telah bekerja untuk
mengumpulkan pengukuran dan metrik.
c. Jangan menggunakan metrik untuk menilai individu
d. Bekerja dengan pelaksana dan tim untuk menentukan tujuan dan metrik yang jelas
yang akan dipakai untuk mencapainya.
e. Jangan pernah menggunakan metrik untuk mengancam individu dan tim.
f. Metrik data yang menunjukkan sebuah area masalah tidak boleh “dianggap
negative.” Data-data itu hanya merupakan sebuah indicator bagi peningkatan
proses.
g. Jangan tergoda pada sebuah metrik dan kemudian mengabaikan metrik penting
yang lain.
Pada dasarnya statistical software process improvement (SSPI) menggunakan
analisis kegagalan perangkat lunak untuk mengumpulkan informasi seputar semua
kesalahan dan cacat yang terjadi pada saat sebuah aplikasi, sistem, atau produk
dikembangkan dan dipakai. Analisis kegagalan bekerja dengan cara sebagai berikut :
a. Semua kesalahan dan cacat dikategorikan dari awal (contohnya, kekurangan
dalam spesifikasi, kekurangan dalam logika, ketidaksesuaian dengan standar).
Universitas Sumatera Utara
11
b. Biaya untuk mengkoreksi setiap kesalahan dan cacat dicatat.
c. Jumlah kesalahan dan cacat dari setiap kategori dihitung dan ditata dalam
urutan naik.
d. Biaya keseluruhan dari kesalahan dan cacat dari setiap kategori dihitung.
e. Data resultan dianalisis untuk menemukan kategori yang menelan biaya besar.
f. Rencana dikembangkan untuk memodifikasi proses guna mengeliminasi
(mengurangi frekuensi kejadian) kelas kesalahan dan cacat yang paling
membutuhkan banyak biaya.
2.2.2 Metrik Proyek
Metrik yang dikumpulkan dari proyek terdahulu digunakan sebagai dasar yang dari
sana perkiraan usaha dan durasi waktu dibuat untuk kerja perangkat lunak saat ini.
Selagi sebuah proyek berjalan, pengukuran usaha dan waktu kalender yang digunakan
dibandingkan dengan perkiraan awal (dan jadwal proyek).
Nilai produksi yang disajikan dalam bentuk halaman dokumentasi, jam kajian,
titik-titik fungsi, dan deretan sumber yang disampaikan diukur serta kesalahan yang
ditemukan selama masing-masing tugas kerja rekayasa perangkat lunak kemudian
ditelusuri.
Metrik proyek mempunyai tujuan ganda. Pertama, metrik tersebut digunakan
untuk meminimalkan jadwal pengembangan dengan melakukan penyesuaian yang
diperlukan untuk menghindar penundaan serta mengurangi masalah dan risiko
potensial. Kedua, metrik proyek dipakai untuk memperkirakan kualitas produk pada
basis yang berlaku dan bila dibutuhkan, memodifikasi pendekatan teknis untuk
meningkatkan kualitas.
Model lain dari metrik proyek mengusulkan bahwa setiap proyek
seharusnya mengukur :
a. input (pengukuran sumber daya seperti manusia, lingkungan yang
dibutuhkan untuk melakukan pekerjaan).
Universitas Sumatera Utara
12
b. Output (pengukuran kemampuan penyampaian atau produk kerja yang
diciptakan selama proses rekayasa perangkat lunak).
c. Hasil
(pengukuran
yang
menunjukkan
efektivitas
kemampuan
penyampaian).
.
2.3 Mengimplementasikan Metrik pada Perangkat Lunak
Implementasi metrik pada perangkat lunak berkaitan erat dengan estimasi usaha dan
biaya kegiatan proyek perangkat lunak. Produktivitas pada sistem dapat diukur dengan
menghitung jumlah satuan yang dihasilkan dan membagi nilai ini dengan jumlah
orang-jam yang dibutuhkan untuk menghasilkannya. Estimasi produktivitas biasanya
berdasar atas pengukuran beberapa atribut perangkat lunak dan membaginya dengan
usaha total yang dibutuhkan untuk pengembangan. Ada dua jenis pengukuran yang
telah dipakai:
a. Metrik yang berhubungan dengan ukuran.
Pengukuran ini berhubungan dengan ukuran output dari suatu kegiatan.
Pengukuran yang berhubungan dengan ukuran yang paling umum adalah
jumlah baris kode sumber yang diserahkan. Pengukuran lain yang dapat
digunakan adalah jumlah instruksi kode objek yang diserahkan atau jumlah
halaman dokumentasi sistem.
b. Metrik yang berhubungan dengan fungsi.
Pengukuran ini berhubungan dengan fungsionalitas menyeluruh dari perangkat
lunak yang diserahkan. Produktivitas dinyatakan dalam jumlah fungsionalitas
yang berguna dalam waktu tertentu. Poin fungsi dan poin objek merupakan
pengukuran yang paling dikenal dari jenis ini.
Estimasi ukuran software merupakan suatu aktifitas yang komplek dan sukar
berdasarkan pada beberapa alas an seperti kemampuan programmer, faktor
lingkungan dan sebagainya. Tetapi karena tindakan ini harus dilakukan dan untuk
mendapatkannya dengan mengukur ukuran proyek menggunakan ukuran seperti
jumlah baris program (Source lines of code/SLOC) dan Function Points.
Universitas Sumatera Utara
13
2.3.1 Pengukuran Yang Berhubungan Dengan Ukuran
Pegukuran yang berhubungan dengan ukuran (Metric Size Oriented) adalah
pengukuran dengan normalisasi kualitas dan produktifitas atau mempertimbangkan
ukuran perangkat lunak yang dihasilkan. Metric size oriented dilakukan dengan
menghitung LOC (Line of Code) dari baris kode suatu perangkat lunak. Pada
pengembangan, pengukuran ini juga dapat mengukur:
h. Kesalahan per KLOC (Kilo Line Of Code)
i. Biaya per LOC
j. Cacat per LOC
k. Halaman dokumentasi per LOC
l. Kesalahan perorang perbulan
m. LOC perorang perbulan
n. Biaya perhalaman dokumentasi.
Menurut Jones (Pressman,2001) LOC merupakan ukuran yang kurang akurat
dan merupakan sebuah topik yang menimbulkan perdebatan selama bertahun-tahun,
dipandang sebagai sebuah ukuran untuk mengestimasi biaya dan waktu, tidak dapat
dipastikan bahwa dua program yang mempunyai LOC sama akan membutuhkan
waktu implementasi yang sama walaupun keduanya diimplementasikan dengan
kondisi pemrograman yang standard. Meskipun metode ini kurang akurat dan
merupakan metodologi yang belum diterima secara luas, tetapi metrik dengan
orientasi ukuran ini merupakan kunci pengukuran dan banyak estimasi software yang
menggunakan model ini.
Secara virtual tidak mungkin untuk menghitung LOC dari dokumen
requirement awal. LOC pengukurannya didasarkan pada bahasa pemrograman
tertentu, oleh karena itu muncul banyak masalah dalam membuat standard pengukuran
dengan teknik LOC. Ukuran lain yang ada untuk mengukur besaran software adalah
Universitas Sumatera Utara
14
ukuran yang berorientasi fungsi dan ukuran yang berorientasi object. Metode ini
merupakan metode yang lebih konsisten dan diterima secara luas.
2.3.2 Pengukuran yang Berhubungan dengan Function Point
Pengukuran yang berhubungan dengan fungsi (Metric Function Oriented) adalah
pengukuran fungsionalitas yang disampaikan oleh aplikasi sebagai suatu nilai
normalisasi. Perhitungan dengan metode Function Point menuntut untuk dilakukan
oleh seorang profesional yang berpengalaman karena memiliki tingkat subyektifitas
yang cukup tinggi. Metrik berorientasi fungsi diusulkan oleh Albrecth pada tahun
1979, yang menyarankan pengukuran yang disebut Function Point. Function Point
tidak bergantung pada bahasa sehingga produktivitas pada bahasa pemrograman yang
berbeda dapat dibandingkan. Produktivitas dinyatakan sebagai poin fungsi yang
dihasilkan per orang-bulan. Function Point di-bias menuju system pemrosesan data
yang didominasi oleh operasi input dan output. Metode ini sendiri terdiri dari banyak
varia. Variasi yang adalah pada langkah/tahapan yang ada maupun pada isi dari tiap
tahapan. Varian-varian ini timbul karena metode ini dapat diubah sesuai dengan
kebijakan perusahaan pengembang software. Namun apapun varian yang digunakan
oleh pengembang, hendaknya digunakan dengan konsisten agar tercipta komparasi
yang benar antara software-software yang dinilai.
Metode dalam metrik ini berdasarkan publikasi varian yang populer seperti
Gramus dan Herron, IEEE, Caldiera (Pressman, 2001) yang menghasilkan manual
penggunaan function point seperi IFPUG 3, IFPUG 4 dan Mark II. Tahapan-tahapan
yang ada dalam menentukan function point adalah sebagai berikut :
Langkah 1 : Menghitung crude function points (CFP)
Jumlah dari komponen fungsional sistem pertama kali diidentifikasi dan dilanjutkan
dengan mengevaluasi kuantitasi bobot kerumitan dari tiap komponen tersebut.
Pembobotan tersebut kemudian dijumlahkan dan menjadi angka CFP.
Perhitungan CFP melibatkan 5 tipe komponen sistem software berikut :
a. Jumlah macam aplikasi input (user inputs)
b. Jumlah macam aplikasi output (user outputs)
Universitas Sumatera Utara
15
c. Jumlah macam aplikasi query online – aplikasi ini berhubungan dengan query
terhadap data yang tersimpan (Inquiry)
d. Jumlah macam file/tabel logic yang terlibat
e. Jumlah macam interface eksternal – output atau input yang dapat berhubungan
dengan komputer lewat komunikasi data, CD, disket, dan lain-lain.
Kemudian diberikan faktor bobot pada tiap komponen di atas berdasarkan
kompleksitasnya. Tabel 2.1 di bawah ini merupakan contoh blanko pembobotan
tersebut.
Tabel 2.1 Blanko penghitungan CFP
Komponen
Sistem
Software
Input
Output
Query
Online
File logic
Interface
Eksternal
Total CFP
Total
CFP
Level kompleksitas
Sederhana
Count Faktor Point
Bobot
A
B
C=
AxB
3
4
3
Menengah
Count Faktor Point
Bobot
D
E
F=
DxE
4
5
4
7
5
10
7
Kompleks
Faktor Point
Bobot
G
H
I=
GxH
6
7
6
Count
J=C+F+I
15
10
Langkah 2 : Menghitung faktor pengubah kompleksitas relatif/Relative
Complexity Adjustment Factor (RCAF).
RCAF berfungsi untuk menghitung kesimpulan kompleksitas dari sistem software dari
beberapa subyek karakteristik. Penilaian berskala 0 sampai 5 diberikan pada tiap
subyek yang paling berpengaruh terhadap usaha pengembangan yang dibutuhkan.
Blanko penilaian yang diusulkan penulis diberikan seperti Tabel 2.2
Tabel 2.2 Blanko penghitungan RCAF
No
Subyek
Nilai
1
Tingkat kompleksitas kehandalan backup/recovery
012345
2
Tingkat kompleksitas komunikasi data
012345
3
Tingkat kompleksitas pemrosesan terdistribusi
012345
Universitas Sumatera Utara
16
4
Tingkat kompleksitas kebutuhan akan kinerja
012345
5
Tingkat kebutuhan lingkungan operasional
012345
6
Tingkat kebutuhan knowledge pengembang
012345
7
Tingkat kompleksitas updating file master
012345
8
Tingkat kompleksitas instalasi
012345
9
Tingkat kompleksitas aplikasi input, output, query online dan file
012345
10
Tingkat kompleksitas pemrosesan data
012345
11
Tingkat ketidakmungkinan penggunaan kembali dari kode (reuse)
012345
12
Tingkat variasi organisasi pelanggan
012345
13
Tingkat kemungkinan perubahan/fleksibilitas
012345
14
Tingkat kebutuhan kemudahan penggunaan
012345
Total = RCAF
Langkah 3 : Menghitung Function Point (FP)
Nilai function point untuk sistem software tersebut kemudian dihitung berdasarkan
hasil dari tahap 1 dan 2 yang dimasukkan ke dalam formula
FP = CFP x (0.65 + 0.01 x RCAF)
(2.1)
2.4 Estimasi Proyek Perangkat Lunak
Estimasi biaya dan tenaga sukar untuk menjadi sebuah ilmu pasti. Banyak
faktor seperti manusia, teknis, lingkungan, atau politik, yang dapat mempengaruhi
besarnya biaya dan tenaga yang diperlukan untuk mengembangkan perangkat lunak.
Bagaimanapun juga, estimasi proyek perangkat lunak dapat ditransformasikan dari
sesuatu yang abstrak menjadi suatu urutan langkah langkah sistematis yang
menghasilkan perkiraan-perkiraan dengan tingkat resiko yang dapat diterima.
Ada beberapa cara yang dapat digunakan untuk melakukan perkiraan proyek:
1. Perkiraan keterlambatan suatu proyek dapat diselesaikan
2. Perkiraan berdasarkan proyek serupa yang telah selesai dikerjakan
Universitas Sumatera Utara
17
3. Menggunakan teknik dekomposisi sederhana untuk membuat suatu kisaran
biaya dan tenaga
4. Menggunakan satu atau lebih model empiris untuk perkiraan biaya dan tenaga
Teknik yang disarankan oleh para ahli di bidang perangkat lunak adalah dengan
menggunakan kombinasi antara teknik dekomposisi dan model empiris. Teknik
dekomposisi menggunakan pendekatan dengan cara membagi suatu proyek ke dalam
beberapa fungsi mayor yang berhubungan dengan aktivitas rekayasa perangkat lunak.
Model estimasi empiris dapat digunakan sebagai pelengkap bagi teknik dekomposisi.
2.4.1 Estimasi Berbasis Masalah
Estimasi berbasis LOC dan FP memiliki teknik yang unik. Keduanya memiliki
karakteristik sendiri. Perencana proyek memulai dengan kumpulan pernyataan yang
berisi kerangka dan batasan-batasan dari perangkat lunak dan dari peryataanpernyataan tersebut kemudian mencoba untuk melakukan dekomposisi perangkat
lunak ke dalam banyak fungsi permasalahan (problem function) dan melakukan
estimasi variabel-variabel (LOC dan FP) pada tiap fungsi permasalahan. Sebagai
alternatif, perencana proyek dapat memilih komponen untuk menentukan ukuran,
seperti kelas obyek, perubahan, atau proses bisnis yang terpengaruh.
Metrik produktivitas (misalnya: LOC/pm atau FP/pm9) diaplikasikan ke dalam
variabel estimasi. Akronim pm digunakan untuk menyatakan satuan person-month
(orang-bulan). Metrik kemudian dikombinasikan untuk memperoleh estimasi dari
keseluruhan proyek. Dengan menggunakan data dari proyek di masa lalu, perencana
proyek dapat membagi nilai perkiraan ke dalam nilai ukuran (S),
2.5 Model Estimasi Empiris
Model estimasi perangkat lunak menggunakan formula yang diperoleh secara
empiris untuk memperkirakan tenaga sebagai sebuah fungsi dari LOC atau FP. Data
empiris yang paling banyak mendukung dalam model-model estimasi diperoleh dari
sampel proyek yang jumlahnya terbatas. Dengan alasan ini, maka tidak ada model
Universitas Sumatera Utara
18
estimasi yang cocok untuk semua lingkungan pengembangan perangkat lunak. Maka
dari itu, penerapan hasil yang diperoleh dari model-model yang sudah disediakan
harus digunakan secara bijaksana sesuai dengan keadaan lingkungan masing-masing
pengembang.
2.5.1 Struktur Model-Model Estimasi
Model estimasi diperoleh melalui analisis regresi pada data yang diperoleh
pada proyek-proyek di masa lalu. Keseluruhan struktur dari beberapa model
mengambil dari persamaan yang dipaparkan oleh Matson ( Matson, 1994):
E = A + B x (ev)C
(2-3)
Dimana E adalah effort dalam orang-bulan, dan A, B, C adalah konstanta yang
diperoleh secara empiris. Dalam perkembangannya persamaan tersebut dikembangkan
sesuai dengan proyek yang dikerjakan oleh masing-masing pengembang perangkat
lunak. Perbedaan persamaan yang digunakan oleh masing-masing pengembang
dikarenakan persamaan tersebut harus dikalibrasi terlebih dahulu, sesuai dengan
kondisi maupun kebutuhan.
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
(2.4)
E = 5,5 + 0,73 x (KLOC)1,16 Baily-Basili Model
E = 3,2 x (KLOC)
1,05
E = 5,288 x (KLOC)1,047
(2.5)
Model sederhana Boehm
(2.6)
Dotu Model untuk KLOC > 9
(2.7)
Model-model orientasi FP juga telah diusulkan, yaitu :
E = -13,39 + 0,0545 FP
-8
E = 60,62 x 7,728 x 10 FP
E = 585,7 + 15,12 FP
3
Albercht dan Gaffney Model
(2.8)
Kemerer Model
(2.9)
Matson, Barnett, dan Mellichamp
(2.10)
Universitas Sumatera Utara
19
2.5.2 Model COCOMO
COCOMO adalah sebuah model yang didesain oleh Barry Boehm untuk
memperoleh
perkiraan
dari
jumlah
orang-bulan
yang
diperlukan
untuk
mengembangkan suatu produk perangkat lunak. Satu hasil observasi yang paling
penting dalam model ini adalah bahwa motivasi dari tiap orang yang terlibat
ditempatkan sebagai titik berat. Hal ini menunjukkan bahwa kepemimpinan dan kerja
sama tim merupakan sesuatu yang penting, namun demikian poin pada bagian ini
sering diabaikan.
Model COCOMO dapat diaplikasikan dalam tiga tingkatan kelas:
1. Proyek organik, adalah proyek dengan ukuran relatif kecil, dengan anggota tim
yang sudah berpengalaman, dan mampu bekerja pada permintaan yang relatif
fleksibel.
2. Proyek sedang (semi-terpisah), adalah proyek yang memiliki ukuran dan tingkat
kerumitan yang sedang, dan tiap anggota tim memiliki tingkat keahlian yang
berbeda.
3. Proyek terintegrasi, adalah proyek yang dibangun dengan spesifikasi dan operasi
yang ketat.
Persamaan dasar model COCOMO adalah:
E = ab (KLOC)bb
(2.11)
D = cb (E)db
(2.12)
P=E/D
(2.13)
Dimana E adalah usaha dalam orang-bulan, D adalah waktu pengerjaan dalam
satuan bulan, KLOC adalah estimasi jumlah baris kode dalam ribuan, dan P adalah
jumlah orang yang diperlukan. Koefisien ab, bb, cb, dan db diberikan pada tabel
berikut:
Universitas Sumatera Utara
20
Tabel 2.3 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
Hirarki model Boehm berbentuk sebagai berikut:
Model 1 :
Model COCOMO Dasar menghitung usaha pengembangan perangkat
lunak (dan biaya) sebagai fungsi dari ukuran prgram yang
diekspresikan dalam baris kode yang diestimasi.
Model 2 :
Model COCOMO Intermediate menghitung usaha pengembangan
perangkat lunak 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, dan lain-lain) dari proses
rekayasa perangkat lunak.
Pengembangan model COCOMO adalah dengan menambahkan atribut yang
dapat menentukan jumlah biaya dan tenaga dalam pengembangan perangkat lunak,
yang dijabarkan dalam kategori dan subkategori sebagai berikut:
1. Atribut produk
a. Reliabilitas perangkat lunak yang diperlukan
b. Ukuran basis data aplikasi
c. Kompleksitas produk
2. Atribut perangkat keras
a. Performa program ketika dijalankan
b. Memori yang dipakai
c. Stabilitas mesin virtual
d. Waktu yang diperlukan untuk mengeksekusi perintah
Universitas Sumatera Utara
21
3. Atribut Sumber Daya Manusia
a. Kemampuan analisis
b. Kemampuan ahli perangkat lunak
c. Pengalaman membuat aplikasi
d. Pengalaman menggunakan mesin virtual
e. Pengalaman dalam menggunakan bahasa pemrograman
4. Atribut proyek
a. Menggunakan perangkat lunak tambahan
b. Metode rekayasa perangkat lunak
c. Waktu yang diperlukan
Masing-masing subkategori diberi bobot antara 0 (sangat rendah) sampai 6 (sangat
tinggi), dan kemudian dijumlahkan. Dari pengembangan ini diperoleh persamaan:
E=ai(KLOC)(b)i.EAF
(2.14)
2.5.3 Persamaan pada Perangkat Lunak
Persamaan perangkat lunak merupakan model variabel jamak yang
menghitung suatu distribusi spesifik dari usaha pada jalannya pengembangan
perangkat lunak. Persamaan berikut ini diperoleh dari hasil pengamatan terhadap lebih
dari 4000 proyek perangkat lunak:
E = [LOC x B0.333/P]3 x (1 / t4)
(2.15)
E = usaha dalam orang-bulan atau orang-tahun
t = durasi proyek dalam bulan atau tahun
B = faktor kemampuan khusus
P = parameter produktivitas
Nilai B diambil dengan berdasarkan perkiraan. Untuk program berukuran kecil (0.5 <
KLOC < 5), B = 0.16. Untuk program yang lebih besar dari 70 KLOC, B = 0.39.
Universitas Sumatera Utara
22
Nilai P merefleksikan:
1. Kematangan proses dan praktek manajemen
2. Kualitas rekayasa perangkat lunak
3. Tingkat bahasa pemrograman yang digunakan
4. Keadaan lingkungan perangkat lunak
5. Kemampuan dan pengalaman tim pengembang
6. Kompleksitas aplikasi
Berdasarkan teori, diperoleh P = 2000 untuk sistem terapan, P = 10000 untuk
perangkat lunak pada sistem informasi dan sistem telekomunikasi, dan P = 28000
untuk sistem aplikasi bisnis.
2.6 Konversi Waktu Tenaga Kerja
Konversi waktu tenaga kerja pada tugas akhir ini ini diperoleh dari angka pembanding
yang digunakan pada rata-rata pengerjaan proyek perangkat lunak (Sommervile,
2003), dengan hubungan persamaan antara orang-bulan (OB), orang-jam (OJ), orangminggu (OM), dan orang-tahun (OT) adalah sebagai berikut:
OM = 40 OJ
OT = 12 OB
OT = 52 OM
Dari persamaan di atas, diperoleh konversi orang-bulan ke orang-jam
sebagai berikut
OB = (40 OJ x 52) / 12
OB = 173,33 OJ
Universitas Sumatera Utara