Buku ajar kecil 03

Buku Ajar Rekayasa Perangkat Lunak

BAB 3
Metrik Proyek Perangkat Lunak

Kompetensi Dasar :
Mahasiswa memahami maksud dari metrik proyek perangkat lunak dan
mampu menggunakan metrik tersebut.

Pengukuran merupakan suatu hal yang pokok bagi disiplin
perekayasaan (engineering), rekayasa perangkat lunakpun tidak
terkecuali.
Metrik perangkat lunak mengacu pada suatu jangkauan luas
pengukuran perangkat lunak komputer. Pengukuran dapat
diterapkan pada proses perangkat lunak guna
mengembangkannya dengan dasar yang kontinyu. Pengukuran
dapat digunakan di seluruh proyek perangkat lunak untuk
membantu perhitungan, kontrol kualitas, perkiraan produktivitas
dan kontrol proyek. Akhirnya, pengukuran dapat digunakan oleh
perekayasa perangkat lunak untuk membantu memperkirakan
kualitas produk kerja teknis serta untuk membantu mengambil
keputusan taktis pada saat proyek sudah berjalan.
Dalam konteks manajemen perangkat lunak, perhatian utama
pada produktivitas dan metrik kualitas – pengukuran output
perkembangan perangkat lunak sebagai sebuah fungsi usaha
dan waktu yang diaplikasikan serta pengukuran “kesesuaian
pemakaian” produk kerja yang dihasilkan. Untuk tujuan
perencanaan dan perkiraan harus memperhatikan sejarah.

1. Pengukuran, metrik dan indikator.
Meskipun bentuk measure (mengukur), measurement
(pengukuran), dan metrik sering dipakai secara bergantian,
namun penting untuk dicatat perbedaaan kecil yang ada
diantara ketiganya. Measure dan measurement dapat
digunakan dengan baik sebagai kata kerja atau kata benda.
Dalam konteks RPL, measure mengindikasikan kuantitatif dari
luasan, jumlah, dimensi, kapasitas, atau ukuran dari atribut
sebuah proses atau produk. Measurement adalah kegiatan

23


menentukan sebuah measure (pengukuran). IEEE Standard
Glossary of Software Engineering Terms (IEEE 93)
mendefinisikan metrics sebagai “Ukuran kuantitatif dari tingkat
dimana sebuah sistem, komponen, atau proses memiliki
atribut tertentu “.
Metrik perangkat lunak menghubungkan pengukuran individu
dengan banyak cara (seperti rata-rata jumlah kesalahan
yang ditemukanper kajian atau jumlah rata-rata kesalahan
yang ditemukan per person-hour yang dipakai pada kajian).
RPL mengumpulkan pengukuran dan mengembangkan
metrik sehingga diperoleh suatu indikator. Indikator adalah
sebuah metrik atau kombinasi dari metrik yang memberikan
pengetahuan ke dalam proses perangkat lunak, sebuah
proyek perangkat lunak, atau produk itu sendiri. Indikator
memberikan pengetahuan yang memungkinkan manajer
proyek atau perekayasa perangkat lunak meneyesuaikan
proses, proyek dan produk, untuk membuat semuanya
menjadi lebih baik.

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. Indikator proses memungkinkan manajer dan
pelaksana memperkirakan apa yang harus dikerjakan dan
yang tidak. Metrik proses dikumpulkan di seluruh proyek dan
pada perkembangan proses perangkat lunak jangka
panjang.
Indikator proyek memungkinkan manajer proyek perangkat
lunak :
1. memperkirakan status sebuah proyek yang sedang
berlangsung.
2. menelusuri risiko-risiko potensial.
3. menemukan area masalah sebelum masalah menjadi
semakin kritis.
4. menyesuaikan aliran kerja atau tugas-tugas.
5. mengevaluasi kemampuan tim proyek untuk mengontrol
kualitas hasil kerja rekayasa perangkat lunak.

24


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.

Gambar 3.1. Determinan untuk kualitas dan efektivitas
organisasional perangkat lunak.

Dalam gambar 3.1. proses berada di tengah-tengah sebuah
segitiga yang menghubungkan tiga faktor yang sangat besar
pengaruhnya terhadap kualitas pertangkat lunak dan unjuk
kerja organisasional. Keterampilan dan motivasi yang
diperlihatkan oleh manusia merupakan satu-satunya faktor
yang paling berpengaruh pada kualitas dan unjuk kerja tim.
Teknologi yang menghuni proses juga berpengaruh. Segitiga
proses juga berada di dalam sebuah lingkaran yang
menggambarkan kondisi lingkungan yang menyangkut
lingkungan pengembangan, kondisi bisnis dan karakteristik
pelanggan.
Pengukuran 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.

25


Dalam proses terdapat tipe data yang berbeda sehubungan
dengan “privat dan publik”. Data-data tersebut juga harus
bersifat privat bagi individu dan berfungsi sebagai indikator
hanya untuk individu. Contoh metrik yang bersifat privat
terhadap individu menyangkut :
 Nilai cacat oleh individu.
 Nilai cacat oleh modul.
 Kesalahan yang ditemukan selama pengembangan.
Metrik publik biasanya mengasimilasi informasi yang secara
orisinal bersifat privat bagi individu dan tim. Nilai cacat tingkat
proyek, usaha, waktu kalender dan data dikumpulkan dan
dievaluasi dalam upaya menemukan indikator yang dapat
mengembangkan unjuk kerja proses organisasional.
Metrik proses perangkat lunak digunakan untuk tujuan
strategis. Pengukuran proyek perangkat lunak bersifat taktis,
yaitu bahwa metrik proyek dan indikator yang berasal dari
pengukuran digunakan oleh manajer proyek dan tim
perangkat lunak untuk mengadaptasi aliran kerja proyek dan
aktivitas teknis.
Aplikasi pertama dari metrik proyek pada sebagian besar
proyek perangkat lunak terjadi selama perkiraan. Metrik yang
dikumpulkan dari proyek yang terdahulu digunakan sebagai
dasar untuk membuat perkiraan usaha dan durasi waktu
untuk kerja perangkat lunak saat ini. Selagi proyek berjalan,
pengukuran usaha dan waktu kalender yang digunakan
dibandingkan dengan perkiraan awal dan jadwal proyek.
Manajer menggunakan data tersebut untuk memonitor dan
mengontrol kemajuan.
Pada saat kerja teknis dimulai, metrik proyek mulai memiliki
arti. Nilai produksi yang disajikan dalam bentuk halaman
dokumentasi, jam kajian, titik-titik fungsi dan sederetan sumber
yang disampaikan diukur dan kesalahan yang ditemukan
selama masing-masing tugas kerja rekayasa perangkat lunak
kemudian ditelusuri. Selagi perangkat lunak berjalan dari
spesifikasi ke perancangan, metrik teknik dikumpulkan untuk
memperkirakan kualitas desain serta memberikan indikator
yang akan mempengaruhi pendekatan yang akna diambil
untuk memunculkan kode dan modul serta pengujian
integrasi.
Metrik proyek mempunyai tujuan ganda. Pertama, metrik
tersebut digunakan untuk meminimalkan jadwal

26


pengembangan dengan melakukan penyesuaian yang
diperlukan untuk menghindari 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.
Pada saat kualitas meningkat, kesalahan menjadi minimal,
dan selagi kesalahan semakin berkurang, jumlah kerja ulang
yang dibutuhkan selama proyek berlangsung juga berkurang.
Dengan demikian, pembiayaan proyek secara keseluruhan
dapat berkurang.
Model yang lain dari metrik proyek mengusulkan bahwa
setiap proyek harus mengukur :
 Input, yaitu pengukuran sumber daya seperti manusia,
lingkungan yang dibutuhkan untuk melakukan pekerjaan.
 Output, yaitu pengukuran kemampuan penyampaian
atau produk kerja yang diciptakan selama proses
rekayasa perangkat lunak.
 Hasil, yaitu pengukuran yang menunjukkan efektivitas
kemampuan penyampaian.
Pada kenyataannya model ini dapat diterapkan, baik proses
maupun pada proyek. Dalam konteks proyek, model dapat
diterapkan secara rekursif pada saat masing-masing aktivitas
kerangka kerja berjalan, sehingga output dari satu aktivitas
menjadi input bagi aktivitas selanjutnya. Metrik hasil dapat
digunakan untuk memberikan indikasi daya guna produk kerja
selagi mereka mengalir dari satu aktivitas kerangka kerja ke
aktivitas kerangka kerja selanjutnya.

3. Pengukuran perangkat lunak.
Pengukuran langsung dari proses rekayasa perangkat lunak
menyangkut biaya dan usaha yang diaplikasikan. Pengukuran
langsung dari produk menyangkut deretan kode (LOC) yang
diproduksi, kecepatan eksekusi, ukuran memori dan cacat
yang dilaporkan pada sejumlah periode waktu. Pengukuran
tidak langsung dari produk menyangkut fungsionalitas,
kualitas, kompleksitas, efisiensi, reliabilitas, kemampuan
pemeliharaan dan banyak lagi kemampuan lain.
3.1. Metrik size – oriented.
Metrik perangkat lunak size oriented (berorientasi pada
ukuran) ditarik dengan normalisasi kualitas dan atau

27


pengukuran produktivitas dengan mempertimbangkan
“ukuran” perangkat lunak yang dihasilkan. Bila sebuah
organisasi memelihara rekaman-rekaman sederhana,
sebuah tabel pengukuran size-oriented seperti ditunjukkan
pada gambar 3.2. dapat diciptakan. Tabel tersebut
mencantumkan daftar setiap proyek pengembangan
perangkat lunak yang sudah diselesaikan pada tahun-
tahun terakhir dan pengukuran yang sesuai untuk proyek
tersebut.

Gambar 3.2. Metrik size-oriented.
Untuk mengembangkan metrik yang dapat diasimilasi
dengan metrik yang sama dari proyek yang lain, kita
memilih sederetan kode sebagai nilai normalisasi. Dari
data yang belum sempurna yang ada pada tabel, dapat
dikembangkan serangkaian metrik size – oriented yang
sederhana untuk setiap proyek :
 Kesalahan (error) per KLOC (kilo LOC).
 $ per LOC.
 Cacat (defect) per KLOC.
 Halaman dokumentasi per KLOC.
Sebagai tambahan, metrik menarik yang lain dapat
dihitung :
 Kesalahan / person – month.
 LOC per person – month.
 $ / halaman dokumentasi.

28


3.2. Metrik function – oriented.
Metrik perangkat lunak function – oriented (berorientasi
pada fungsi) menggunakan sebuah pengukuran
fungsionalitas yang disampaikan oleh aplikasi sebagai
suatu nilai normalisasi. Karena fungsionalitas tidak dapat
diukur secara langsung, maka fungsionalitas harus ditarik
secara tidak langsung dengan menggunakan
pengukuran langsung yang lain. Metrik berorientasi fungsi
pertama kali diusulkan oleh Albrecht yang mengusulkan
sebuah pengukuran yang disebut function point.

Gambar 3.3. Penghitungan metrik function point

Function point ditarik dengan menggunakan sebuah
hubungan empiris berdasarkan pengukuran langsung
domain informasi perangkat lunak yang dapat dihitung
serta perkiraan kompleksitas perangkat lunak. Function
point dihitung dengan melengkapi tabel yang
diperlihatkan pada gambar 3.3. lima karakteristik domain
informasi ditentukan dan penghitungan diberikan di
dalam lokasi tabel yang sesuai. Nilai domain informasi
didefinisikan dengan cara sebagai berikut :
 Jumlah input pemakai (External Input, EI). Setiap input
pamakai yang memberikan data yang berorientasi
pada aplikasi yang jelas pada perangkat lunak

29


dihitung. Input ini harus dibedakan dari penelitian
yang dihitung secara terpisah.
 Jumlah output pemakai (External Output, EO). Setiap
output pemakai yang memberikan informasi yang
berorientasi pada aplikasi kepada pemakai dihitung.
Pada konteks ini output mengacu pada laporan,
layar, tampilan kesalahan dan sebaginya. Jenis data
individual pada sebuah laporan tidak dihitung secara
terpisah.
 Jumlah penyelidikan pemakai (External Inquiry, EQ).
Sebuah penyelidikan didefinisikan sebagai input on-
line yang mengakibatkan munculnya beberapa
respon perangkat lunak yang cepat dalam bentuk
sebuah output on-line. Setiap penyelidikan yang jelas
dihitung.
 Jumlah file (Internal Logical Files, ILF). Setiap file master
logika (yaitu pengelompokan data secara logis yang
menjadi suatu bagian dari sebuah database yang
besar atau sebuah file yang terpisah) dihitung.
 Jumlah interface eksternal (External Interface Files,
EIF). Semua interface yang dapat dibaca oleh mesin
yang digunakan untuk memindahkan informasi ke
sistem yang lain dihitung.
Setelah komponen-komponen tersebut diklasifikasikan
pada lima komponen utama, sebuah tingkatan rendah,
sedang atau tinggi diberikan. Untuk transaksi (EI, EO, EQ)
tingkatannya berdasarkan jumlah file yang diupdate atau
direferensi (File Type Referenced, FTR) dan jumlah tipe
elemen data (DET). Untuk file ILF dan EIF tingkatannya
berdasarkan tipe elemen record (RET). Tipe elemen record
adalah subgrup dari elemen data dalam ILF atau EIF yang
dapat dikenali oleh user. Tipe elemen data adalah
sesuatu yang dapat dikenali secara unik oleh user,
nonrekursif field. Tabel-tabel berikut ini membantu dalam
menentukan tingkatan proses.

Tabel 3.1. Tabel jumlah input pemakai.

30


Tabel 3.2. Tabel jumlah output pemakai dan jumlah
penyelidikan pemakai.

Tabel 3.3. Nilai transaksi.

Seperti semua komponen, EQ dihitung dan dinilai. Pada
dasarnya, EQ dihitung (rendah, sedang, tinggi) seperti EO,
tetapi diberikan nilai seperti EI. Perhitungan berdasar
pada jumlah DET dan FTR yang merupakan kombinasi
input dan output. Jika FTR yang sama digunakan pada
input dan output, maka hanya akan dihitung sekali.
Untuk ILF dan EIF jumlah tipe elemen record dan jumlah
tipe elemen data digunakan untuk menentukan tingkatan
rendah, sedang, atau tinggi. Suatu tipe elemen record
adalah subgrup dari elemen data yang dapat dikenali
oleh user dengan ILF atau EIF. Suatu tipe elemen data
adalah sesuatu yang unik dikenali oleh user, tidak ada
field rekursif pada ILF maupun EIF.

Tabel 3.4. Jumlah elemen data

31


Tabel 3.5. Tingkatan untuk ILF dan EIF

Sekali data tersebut dikumpulkan, maka sebuah nilai
kompleksitas akan dihubungkan dengan masing-masing
perhitungan. Organisasi yang menggunakan metode titik
fungsi mengembangkan kriteria untuk menentukan
apakah sebuah entri tertentu bersifat sederhana, rata-
rata atau kompleks. Meskipun demikian perkiraan
kompleksitas tetap bersifat subyektif.
Untuk menghitung titik-titik fungsi dipakai hubungan
sebagai berikut :
FP = jumlah total x [ 0.65 + 0.01 x (Fi)]
Dimana jumlah total adalah jumlah semua entri yang
diperoleh dari gambar 3.3.
Value Adjustment Factor (VAF) berdasarkan pada 14
karakteristik umum sistem (GSC) yang menghitung
fungsionalitas umum dari aplikasi yang sedang dihitung.
Setiap karakteristik mempunyai deskripsi yang
berhubungan yang membantu menentukan derajat
pengaruh karakteristik. Fi ( i = 1 s/d 14 ) adalah harga
penyesuaian kompleksitas berdasarkan respon pada
pertanyaan yang ditulis pada tabel 3.6. nilai konstanta
pada persamaan dan faktor pembobotan yang
diaplikasikan pada hitungan domain informasi ditentukan
secara empiris.

Tabel 3.6. Menghitung function points.

32


Karakteristik
No. Keterangan
Sistem
1 Kemudahan Apakah sistem membutuhkan
operasional backup dan recovery yang
reliabel ?
2 Komunikasi data Apakah komunikasi data
dibutuhkan ?
3 Pemrosesan data Apakah fungsi pemrosesan
terdistribusi didistribusikan ?
4 Kinerja Apakah kinerja penting ?
5 Konfigurasi Apakah sistem akan berjalan
pada lingkungan operasional
yang sudah ada yang paling
banyak digunakan ?
6 Data entry on-line Apakah sistem membutuhkan
entry data on-line ?
7 Transaksi Apakah entry data on-line
membutuhkan ada transaksi input
terhadap layar atau operasi
ganda ?
8 Update on-line Apakah file master diperbarui
secara on-line ?
9 Efisiensi end-user Apakah input, output, file atau
inquiry kompleks ?
10 Kompleksitas Apakah pemrosesan internal
pemrosesan kompleks ?
11 Pemakaian Apakah kode didesain untuk
kembali dapat dipakai kembali ?
12 Kemudahan Apakah desain melibatkan
instalasi konversi dan instalasi ?
13 Situs ganda Apakah sistem didesain untuk
instalasi ganda dalam situs untuk
organisasi berbeda ?
14 Fasilitas Apakah aplikasi didesain untuk
perubahan memfasilitasi perubahan dan
mempermudah pemakai untuk
menggunakannya ?

Sekali titik fungsi telah dihitung, maka titik-titik itu
digunakan dengan cara analog dengan LOC untuk

33


menormalisasi pengukuran produktifitas, kualitas
perangkat lunak, serta atribut-atribut yang lain :
 Kesalahan per FP.
 Cacat per FP.
 $ per FP.
 Halaman dokumentasi per FP.
 FP per person – month.
3.3. Metrik function point yang diperluas.
Metrik function point secara orisinal dirancang untuk
diterapkan pada aplikasi informai bisnis yang ditekankan
pada pengeluaran dimensi (kontrol) tingkah laku dan
fungsional. Karena alasan tersebut, maka pengukuran
function point tidak sesuai untuk beberapa sistem terapan
dan rekayasa. Sejumlah ekstensi pada pengukuran
function point dasar telah diusulkan untuk mengatasi
situasi ini.
Eksistensi function point yang disebut feature point
merupakan superset dari pengukuran function point yang
dapat diterapkan pada aplikasi perangkat lunak
rekayasa dan sistem. Pengukuran feature point
mengakomodasi aplikasi yang kompleksitas algoritmanya
tinggi. Real-time, kontrol proses dan aplikasi perangkat
lunak embedded, cenderung memiliki kompleksitas
algoritma yang tinggi sehingga dapat dipertanggung
jawabkan untuk feature point.
Untuk menghitung feature point, harga domain informasi
harus dihitung lagi dan dibobot. Sebagai tambahan,
metrik feature point juga menghitung karakteristik
perangkat lunak yang baru, yaitu algoritma. Algoritma
didefinisikan sebagai masalah perhitungan yang terbatas
yang dilakukan dalam sebuah program komputer yang
spesifik.
Ekstensi function point untuk sistem real – time dan produk
rekayasa telah dikembangkan oleh Boeing. Pendekatan
Boeing mengintegrasi dimensi data perangkat lunak
dengan dimensi kontrol dan fungsional untuk memberikan
sebuah pengukuran yang berorientasi pada fungsi, yang
disebut 3D function point, yang dapat dipertanggung
jawabkan untuk aplikasi yang menekankan kemampuan
fungsi dan kontrol. Karakteristik dari semua dimensi
perangkat lunak dihitung, dikuantisasi dan ditransformasi

34


ke dalam sebuah pengukuran yang memberikan indikasi
fungsionalitas yang disampaikan oleh perangkat lunak.
Dimensi data dievaluasi dengan cara yang sama seperti
dijelaskan pada subbab sebelumnya. Penghitungan data
yang disimpan (struktur data program internal, seperti file)
dan data eksternal (input, output, inquiry dan referensi
eksternal) dipakai bersama dengan pengukuran
kompleksitas untuk menarik penghitungan dimensi data.
Dimensi fungsional diukur dengan mempertimbangkan
jumlah operasi internal yang dibutuhkan untuk
mentransformasi input ke data output. Karena tujuan
komputasi adalah function point 3D, maka suatu
transformasi dipandang sebagai sebuah deretan langkah
pemrosesan yang dibatasi oleh sejumlah pernyataan
semantik. Sebagai aturan umum, transformasi dilakukan
dengan sebuah algoritma yang menghasilkan suatu
perubahan dasar ke data input ketika dia diproses untuk
menjadi data output. Langkah pemrosesan yang
membutuhkan data dari sebuah file dan secara
sederhana menempatkan data tersebut ke dalam
memori program, tidak akan dipertimbangkan sebagai
sebuah transformasi. Data itu sendiri tidak diubah dengan
cara yang mendasar.
Tingkat kompleksitas yang diberikan pada masing-masing
transformasi merupakan fungsi dari sejumlah langkah
proses dan sejumlah pernyataan semantik yang
mengontrol langkah pemrosesan. Gambar 3.4.
memberikan tuntunan bagi kompleksitas penugasan
dalam dimensi fungsional.

35


Gambar 3.4. Menentukan kompleksitas transformasi untuk
function point 3D.

Dimensi kontrol diukur dengan menghitung jumlah transisi
antar pernyataan. Pernyataan mewakili beberapa mode
tigkah laku yang dapat diobservasi secara eksternal.
Transisi terjadi sebagai hasil dari kejadian yang
menyebabkan perangkat lunak atau sistem mengubah
mode tingkah lakunya. Contohnya telepon seluler berisi
perangkat lunak yang mendukung fungsi-fungsi autodial.
Untuk menghitung function point 3D, digunakan
hubungan sebagai berikut :
Indeks = I + O + Q + F + E + T + R
Dimana I, O, Q, E, F, T dan R mewakili nilai bobot
kompleksitas untuk elemen-elemen yang telah disebut-
kan : input, output, inquiry, struktur data eksternal, file
eksternal, transformasi dan transisi secara berurutan.
Masing-masing nilai bobot kompleksitas dihitung dengan
menggunakan hubungan sebagai berikut :
Nilai bobot kompleksitas = Nil Wil + Nia Wia + Nih Wih
Dimana N adalah jumlah kejadian elemen i untuk masing-
masing tingkat kompleksitas dan W adalah bobot masing-
masing. Perhitungan keseluruhan untuk function point 3D
diperlihatkan pada gambar 3.5.

36


Gambar 3.5. Menghitung indeks function point 3D.

Perlu diperhatikan bahwa function point, feature point
dan function point 3D menunjukkan hal yang sama yaitu
fungsionalitas atau utility yang dikirim oleh perangkat
lunak. Pada dasarnya, masing-masing pengukuran
menghasilkan nilai yang sama hanya jika dimensi data
dari sebuah aplikasi dipetimbangkan. Untuk sistem real-
time yang lebih kompleks, jumlah feature point sering
antara 20 % dan 35 % lebih tinggi daripada jumlah yang
ditentukan dengan hanya menggunakan function point.

4. Menyatukan berbagai pendekatan metrik yang berbeda.
Hubungan antara baris-baris kode dan function point
tergantung pada bahasa pemrograman yang digunakan
untuk mengimplementasikan perangkat lunak dan kualitas
desain. Berikut ini pernyataan Albrecht dan Gaffney : “Thesis
studi ini adalah jumlah fungsi yang disediakan oleh aplikasi
(program) dapat diestimasi dari itemisasi komponen utama
data yang digunakan atau disediakan oleh aplikasi. Lebih
lanjut, estimasi fungsi harus dihubungkan dengan jumlah LOC
yang akan dikembangkan dan dengan usaha
pengembangan yang diperlukan.
Tabel berikut ini memberikan estimasi kasar terhadap rata-rata
jumlah baris kode yang diperlukan untuk membangun satu
function point dalam berbagai bahasa pemrograman :
Bahasa Pemrograman LOC / FP (rata-rata)

37


Assembly 320
C 128
Cobol 105
Fortran 105
Pascal 90
ADA 70
Bahasa berorientasi objek 30
Bahasa generasi keempat 20
Generator kode 15
Spreadsheets 6
Bahasa Grafis 4

Ukuran LOC dan FP sering digunakan untuk mendapatkan
metrik produktifitas. Hal itu menimbulkan adanya perdebatan
mengenai pemakaian data tersebut. LOC / person-month
atau FP / person-month dari suatu kelompok tidak harus
dibandingkan dengan data serupa dari kelompok lainnya.
Demikian juga penilaian kerja individual oleh manajer dengan
menggunakan metrik tersebut tidak harus dilakukan, karena
ada banyak faktor yang mempengaruhi produktivitas.
Basili dan Zelkowitz menetapkan empat faktor penting yang
mempengaruhi produktifitas perangkat lunak, yaitu :
• Faktor manusia. Ukuran dan keahlian organisasi
pengembangan.
• Faktor masalah. Kompleksitas masalah yang dipecahkan
dan jumlah perubahan dalam batasan dan persyaratan
desain.
• Faktor proses. Teknik analisis dan desain yang digunakan,
bahasa dan peranti CASE yang tersedia, dan teknik-teknik
kajian.
• Faktor sumber daya. Ketersediaan peranti CASE dan
sumber daya perangkat keras dan perangkat lunak.
Jika salah satu faktor produktifitas tersebut di atas rata-rata
(sangat baik) untuk suatu proyek yang ditentukan, maka
produktifitas pengembangan perangkat lunak akan secara
signifikan lebih tinggi daripada jika faktor yang sama berada
di bawah rata-rata (tidak baik).
Proses membuat baseline ditunjukkan pada gambar 3.6.
idealnya data yang diperlukan untuk membaut baseline
dikumpulkan secara terus-menerus. Oleh karena itu, kumpulan

38


data membutuhkan investigasi historis terhadap proyek-
proyek sebelumnya untuk menyusun kembali data yang
diperlukan. Komputasi metrik dapat dilakukan setelah ukuran-
ukuran dikumpulkan. Akhirnya metrik harus dievaluasi dan
diterapkan selama estimasi, kerja teknis, kontrol proyek, dan
peningkatan proses. Evaluasi metrik memfokuskan pada
alasan-alasan mendasar untuk hasil yang diperoleh dan
membuat sekumpulan indikator yang memandu proyek atau
proses.

Prose
s RPL

Proye Kumpulan
ukuran
k RPL data

Produ Komputasi
k RPL metrik
numerik

Evaluasi
indikator
metrik

Gambar 3.6. Proses kumpulan metrik perangkat lunak.

5. Metrik untuk kualitas perangkat lunak.
Tujuan rekayasa perangkat lunak adalah untuk menghasilkan
sistem, aplikasi atau produk berkualitas tinggi. Untuk mencapai
tujuan tersebut, perekayasa perangkat lunak harus
menerapkan metode-metode yang efektif bersama-sama
dengan peranti modern dalam konteks proses perangkat
lunak yang matang. Sebagai tambahan, perekayasa
perangkat lunak yang baik harus mengukur apakah kualitas
tinggi terealisasi.
Kualitas sistem, aplikasi, atau produk, merupakan persyaratan
yang menjelaskan masalah, desain model solusi, kode yang
membuat program dapat dieksekusi, dan pengujian yang
menguji perangkat lunak untuk menemukan kesalahan.
Perekayasa perangkat lunak yang baik menggunakan
pengukuran untuk menilai kualitas model analisis dan desain,
kode sumber, dan test case yang dibuat ketika perangkat
lunak direkayasa. Untuk mencapai kualitas penilaian real-time,

39


perekayasa harus menggunakan pengukuran teknis untuk
mengevaluasi kualitas dalam cara-cara yang obyektif.
Manajer proyek juga harus mengevaluasi kualitas saat
melanjutkan proyek. Metrik-metrik privat yang dikumpulkan
oleh para perekayasa perangkat lunak disatukan untuk
mendapatkan hasil tingkat proyek. Meskipun ada banyak
pengukuran kualitas yang dapat dikumpulkan, tujuan utama
pada tingkat proyek adalah mengukur kesalahan dan cacat.
Metrik yang diperoleh dari pengukuran tersebut memberikan
adanya indikasi mengenai efektifitas jaminan kualitas
perangkat lunak kelompok dan individual, serta tindakan-
tindakan kontrol.
Kesalahan yang ditemukan per jam kajian dan kesalahan
yang ditemukan per jam pengujian memberikan wawasan
mengenai kehebatan masing-masing aktivitas yang
diimplikasikan oleh metrik. Data salah juga dapat digunakan
untuk menghitung Defect Removal Efficiency untuk masing-
masing aktifitas kerja proyek.
McCall dan Cavano menetapkan sekumpulan faktor kualitas
yang merupakan langkah pertama dalam mengembangkan
metrik-metrik untuk kualitas perangkat lunak. Faktor-faktor
tersebut menilai perangkat lunak dari tiga sudut pandang
berbeda, yaitu operasi produk (menggunakannya), revisi
produk (mengubahnya), transisi produk (memodifikasinya
untuk bekerja dalam lingkungan yang berbeda).
McCall dan Cavano juga menjelaskan hubungan antara
faktor kualitas tersebut dan aspek-aspek lain dari proses
rekayasa perangkat lunak :
• Kerangka kerja memberikan suatu mekanisme untuk
manajer proyek untuk mengenali kualitas-kualitas apa
yang penting. Kualitas tersebut merupakan atribut
perangkat lunak, sebagai tambahan untuk koreksi dan
kinerja fungsionalnya, yang mempunyai implikasi daur
hidup.
• Kerangka kerja memberikan alat untuk menilai secara
kuantitatif seberapa baik kemajuan pengembangan.
Dalam hal ini, penilaian adalah bersifat relatif dengan
tujuan-tujuan kualitas yang ditetapkan.
• Kerangka kerja memberikan interaksi yang lebih dalam
pada personil QA di sepanjang usaha pengembangan.

40


• Personil jaminan kualitas dapat menggunakan indikasi
buruknya kualitas untuk membantu mengidentifikasi
standar-standar untuk diusahakan di masa mendatang.
Gilb memberikan definisi dan ukuran terhadap pengukuran
kualitas perangkat lunak :
• Cara yang benar. Program harus beroperasi dengan
benar atau program itu memberikan sedikit saja nilai bagi
para pemakainya. Cara yang benar adalah tingkat di
mana perangkat lunak melakukan fungsi yang ditentukan.
Ukuran paling umum untuk cara yang benar adalah
cacat per KLOC, di mana cacat didefinisikan sebagai
kurangnya kesesuaian dengan persyaratan.
• Maintanabilitas. Pemeliharaan perangkat lunak
menjelaskan usaha dari pada sekedar aktivitas rekayasa
perangkat lunak. Maintanabilitas adalah kemudahan di
mana program dapat dikoreksi jika ditemukan kesalahan,
diadaptasi jika lingkungannya berubah, atau diperkuat
jika pelanggan menginginkan perubahan kebutuhan.
Tidak ada cara untuk mengukur maintanabilitas secara
langsung, karena itu harus digunakan pengukuran tidak
langsung. Metrik time-oriented sederhana adalah rata-
rata waktu untuk berubah (MTTC), waktu yang diperlukan
untuk menganalisis perubahan yang diperlukan, desain
modifikasi yang tepat, mengimplementasi perubahan,
mengujinya, dan mendistribusikan perubahan kepada
semua pemakai.
• Integritas. Atribut ini mengukur kemampuan sistem untuk
menahan serangan terhadap sekuritasnya. Serangan
dapat dilakukan pada semua komponen perangkat
lunak : program, data dan dokumen. Untuk mengukur
integritas, ada dua atribut tambahan yang harus
ditentukan : ancaman dan sekuritas. Ancaman adalah
probabilitas bahwa serangan tipe tertentu akan terjadi
dalam suatu periode waktu yang ditentukan. Sekuritas
adalah probabilitas bahwa serangan tipe tertentu akan
dipukul mundur. Integritas sistem kemudian dapat
ditentukan sebagai :
Integritas = ∑ [1 – ancaman x (1- sekuritas)]
Di mana ancaman dan sekuritas adalah jumlah dari
masing-masing jenis serangan.

41


• Usabilitas. Usabilitas adalah usaha untuk mengukur user
friendliness dan dapat diukur dalam empat karakteristik :
o Keterampilan fisik atau intelektual untuk mempelajari
sistem.
o Waktu yang diperlukan untuk menjadi cukup efisien
dalam menggunakan sistem.
o Peningkatan bersih dalam produktifitas yang diukur
ketika sistem digunakan oleh seseorang yang cukup
efisien.
o Penilaian subyektif dari sikap pemakai terhadap
sistem.
Metrik kualitas yang memberikan manfaat pada tingkat
poyek dan tingkat proses adalah efisiensi penghapusan cacat
(DRE). Pada dasarnya, DRE adalah mengukur kemampuan
penyaringan jaminan kualitas dan aktifitas kontrol ketika
keduanya diterapkan pada semua aktifitas kerangka kerja
proses.
Dengan mempertimbangkan proyek sebagai satu kesatuan,
maka DRE didefinisikan sebagai berikut :
DRE = E / (E + D)
Dimana E = jumlah kesalahan yang ditemukan sebelum
perangkat lunak dikirim kepada pemakai akhir
D = jumlah cacat yang ditemukan setelah
pengiriman.
Nilai ideal untuk DRE adalah 1, di mana tidak ditemukan
adanya cacat pada perangkat lunak. Secara kenyataan, D
akan lebih besar dari 0, tetapi nilai DRE masih dapat
mendekati 1, jika E bertambah. Jika digunakan sebagai metrik
yang memberikan indikator kemampuan memfilter aktifitas
kontrol dan jaminan kualitas, maka DRE mendorong tim
proyek perangkat lunak melembagakan teknik-teknik untuk
menemukan sebnyak mungkin kesalahan sebelum
pengiriman.
DRE dapat juga digunakan dalam proyek untuk menilai
kemampuan tim dalam menemukan kesalahan sebelum
kesalahan dilewatkan ke aktifitas kerangka kerja atau ke
tugas rekayasa perangkat lunak berikutnya.

Rangkuman

42


Measure dan measurement dapat digunakan dengan baik
sebagai kata kerja atau kata benda. Dalam konteks RPL, measure
mengindikasikan kuantitatif dari luasan, jumlah, dimensi, kapasitas,
atau ukuran dari atribut sebuah proses atau produk. Measurement
adalah kegiatan menentukan sebuah measure (pengukuran).
IEEE Standard Glossary of software Engfineering Terms (IEEE 93)
mendefinisikan metrics sebagai “Ukuran kuantitatif dari tingkat
dimana sebuah sistem, komponen, atau proses memiliki atribut
tertentu“. Indikator adalah sebuah metrik atau kombinasi dari
metrik yang memberikan pengetahuan ke dalam proses
perangkat lunak, sebuah proyek perangkat lunak, atau produk itu
sendiri.
Metrik proyek mempunyai tujuan ganda. Pertama, metrik tersebut
digunakan untuk meminimalkan jadwal pengembangan dengan
melakukan penyesuaian yang diperlukan untuk menghindari
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.
Pengukuran langsung dari proses rekayasa perangkat lunak
menyangkut biaya dan usaha yang diaplikasikan. Pengukuran
langsung dari produk menyangkut deretan kode (LOC) yang
diproduksi, kecepatan eksekusi, ukuran memori dan cacat yang
dilaporkan pada sejumlah periode waktu. Pengukuran tidak
langsung dari produk menyangkut fungsionalitas, kualitas,
kompleksitas, efisiensi, reliabilitas, kemampuan pemeliharaan dan
banyak lagi kemampuan lain.

Latihan/Tugas/Test Mandiri
1. Jelaskan apa yang dimaksud dengan pengukuran perangkat
lunak !
2. Mengapa pengukuran perangkat lunak diperlukan ?
3. Jelaskan yang dimaksud dengan metrik perangkat lunak !
4. Sebutkan dan jelaskan cara-cara pengukuran perangkat
lunak !
5. Carilah contoh kasus tentang pengukuran perangkat lunak,
dan jelaskan teknik pengukurannya !

43

Buku ajar kecil 03

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Buku ajar kecil 03

Similaire à Buku ajar kecil 03 (20)

Plus de Ainul Yaqin

Plus de Ainul Yaqin (20)

Buku ajar kecil 03