Metrik
perangkat lunak mengacu pada pengukuran perangkat lunak komputer. Pengukuran digunakan untuk membantu perhitungan, kontrol kualitas, perkiraan
produktivitas, & kontrol proyek, serta untuk membantu mengambil keputusan
taktis pada saat proyek sudah berjalan.
Tujuan
pengukuran perangkat lunak adalah:
·
Untuk menyatakan
kualitas produk
·
Untuk menilai kualitas
manusia yang terlibat dalam pembuatan produk.
·
Untuk menilai
keuntungan pemakaian metode & alat bantu yang baru.
·
Sebagai dasar untuk
melakukan perkiraan.
·
Untuk membantu
penyesuaian pemakaian alat
bantu yang baru
atau pelatihan tambahan.
PENGUKURAN, METRIK,
DAN INDIKATOR
Measure
(mengukur):
Mengindikasikan
kuantitatif dari luasan, jumlah, dimensi, kapasitas, atau ukuran dari atribut
sebuah proses atau produk.
Measurement (pengukuran):
Kegiatan
menentukan sebuah measure (pengukuran)
Metrics (metrik):
Ukuran
kuantitatif dari tingkat dimana sebuah sistem, komponen, atau proses memiliki
atribut tertentu.
RPL
mengumpulkan pengukuran & mengembangkan metrik sehingga diperoleh suatu
indicator.
Indicator
(indicator):
Sebuah
metrik atau kombinasi dari metrik yang memberikan pengetahuan kedalam proses
PL, sebuah proyek PL, atau produk itu sendiri.
Indikator
memberikan pengetahuan yang memungkinkan manajer proyek atau perekayasa PL menyesuaikan
proses, proyek, dan produk, untuk membuat semuanya menjadi lebih baik.
METRIK DALAM PROSES
DAN DOMAIN PROYEK
Metric
harus dikumpulkan sehingga indicator proses dan produk dapat dipastikan.
Indicator proses memungkinkan sebuah organisasi rekayasa perangkat lunak
memperoleh pengetahuan tentang reliabilitas sebuah proses yang sedang
berlangsung (misalnya paradigma, tugas-tugas rekayasa perangkat lunak, produk
kerja, dan kejadian penting). Indicator proses memungkinkan manajer dan
pelaksana memperkirakan apa yang harus dikerjakan dan yang tidak. Metric proses
dikumpulkan di seluruh proyek dan pada perkembangan proses perangkat lunak
jangka panjang.
Metrik
harus dikumpulkan sehingga indikator proses dan indikator produk (proyek) dapat
dipastikan.
Indikator
proses memungkinkan:
1. Sebuah
organisasi rekayasa PL memperoleh pengetahuan tentang reliabilitas sebuah proses
yang sedang berlangsung.
2. Manajer
& pelaksana memperkirakan apa yang harus dikerjakan dan yang tidak.
Indikator
proyek memungkinkan manajer proyek PL:
1. Memperkirakan
status sebuah proyek yang sedang berlangsung.
2. Menelusuri
resiko-resiko 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 RPL.
METRIK PROSES
Satu-satunya
cara yang paling rasional untuk meningkatkan proses adalah dengan mengukur
atribut tertentu dari proses, mengembangkan serangkaian metric yang berarti
berdasarkan atribut-atribut tersebut, dan kemudian menggunakan metric itu untuk
memberikan indicator yang akan membawa pada sebuah strategi pengembangan.
Proses adalah factor yang dapat dikontrol dalam mengembangkan kualitas perangkat lunak serta unjuk kerja organisasional.
Proses adalah factor yang dapat dikontrol dalam mengembangkan kualitas perangkat lunak serta unjuk kerja organisasional.
Gambar
1 Determinan untuk kualitas dan efektivitas organisasional PL.
Pada
gambar, proses berada di tengah-tengah sebuah segitiga yang menghubungkan tiga
factor yang sangat besar pengaruhnya terhadap kualitas perangkat lunak dan
unjuk kerja organisasional. Ketrampilan dan motivasi yang diperlihatkan manusia
merupakan satu-satunya factor 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 (seperti alat-alat Bantu CASE), kondisi
bisnis (seperti batas waktu, aturan bisnis), dan karakteristik pelanggan
(misalnya lancarnya komunikasi).
Kita
mengukur reliabilitas proses perangkat lunak secara tidak langsung yaitu dengan
mengambil serangkaian metric berdasarkan keluaran yang dapat diambil dari
proses. Keluaran menyangkut pengukuran kesalahan yang ditemukan sebelum
pelepasan perangkat lunak, cacat yang disampaikan dan dilaporkan oleh pemakai
akhir, prduk kerja yang dikirim, usaha manusia yang dilakukan, waktu kalender
yang digunakan, konfirmasi jadwal, serta pengukuran yang lain.
Terdapat
penggunaan privat dan public untuk tipe-tipe data proses yang berbeda, karena
memang alamiah bila perekayasa perangkat lunak sensitive terhadap pemakaian
metric yang dikumpulkan pada basis individual. Data-data tersebut juga harus
bersifat pribadi bagi individu dan berfungsi sebagai indicator hanya untuk
individu. Contoh metric yang bersifat pribadi terhadap individu menyangkut:
§ Nilai
cacat oleh individu
§ Nilai
cacat oleh modul
§ Kesalahan
yang ditemukan selama pengembangan
Metric
public biasanya mengasimilasi informasi yang secara orisinil bersifat pribadi
bagi individu dan tim. Nilai cacat tingkat proyek, usaha, waktu calendar, dan
data yang dikumpulkan dan dievaluasi dalam upaya menemukan indicator yang dapat
mengembangkan unjuk kerja proses organisasional.
Maka
dari itu diperlukan etika metric perangkat lunak ketika para manajer ingin melembagakan
program metric proses:
§ Gunakan
istilah umum dan kepekaan organisasi ketika menginterpretasikan data metric.
§ Berikan
umpan balik regular kepada individu dan tim yang telah bekerja untuk
mengumpulkan pengukuran dan metric.
§ Jangan
menggunakan metric untuk menilai individu.
§ Bekerja
dengan pelaksana dan tim untuk menentukan tujuan dan metric yang jelas yang
akan dipakai untuk mencapainya.
§ Jangan
pernah menggunakan metric untuk mengancam individu dan tim.
§ Metric
data yang menunjukkan sebuah area masalah tidak boleh dianggap negative.
Data-data itu hanya merupakan sebuah indicator bagi peningkatan proses.
§ Jangan
tergoda pada sebuah metric dan kemudian mengabaikan metric penting yang lain.
Pada
saat organisasi menjadi lebih nyaman dengan kumpulan dan manfaat metric proyek,
deviasi dari indicator sederhana memberikan suatu cara kepada suatu pendekatan
yang lebih teliti yang disebut statistical software process improvement (SSPI).
Pada dasarnya SSPI menggunakan analisis kegagalan perangkat lunak untuk
mengumpulkan informasi seputar semua kesalahan dan cacat yang terjadi pada saat
sebuah aperangkat lunakikasi, system, atau produk dikembangkan dan dipakai.
Metrik
proses digunakan untuk tujuan strategis. Cara untuk meningkatkan proses
perangkat lunak:
·
Mengukur atribut
tertentu dari proses.
·
Mengembangkan
serangkaian metrik yang berarti.
·
Menggunakan metrik itu
untuk memberikan indikator yang akan membawa kepada sebuah strategi
pengembangan.
Mengukur
reliabilitas proses PL secara tidak langsung yaitu dengan mengambil serangkaian
metrik berdasarkan keluaran yang dapat diambil oleh proses.
Keluaran
menyangkut:
·
Pengukuran kesalahan yang
ditemukan sebelum pelepasan PL.
·
Cacat yang disampaikan
& dilaporkan oleh pemakai akhir.
·
Produk kerja yang
dikirim.
·
Usaha manusia yang
dilakukan
·
waktu kalender yang
digunakan
·
konfirmasi jadwal
·
dll
Pada
saat organisasi menjadi lebih nyaman dengan kumpulan & manfaat metrik
proses, derivasi dari indikator sederhana memberikan suatu cara kepada suatu
pendekatan yang lebih teliti yang disebut SSPI (Statistical Software Process
Improvement).
SSPI
menggunakan analisis kegagalan PL untuk mengumpulkan informasi seputar semua
kesalahan & cacat yang terjadi pada saat sebuah aplikasi, sistem, atau produk
dikembangkan dan dipakai.
Kesalahan:
Ketidaksempurnaan
pada sebuah produk kerja yang ditemukan oleh perekayasaan PL. Sebelum PL itu disampaikan
kepada pemakai akhir.
Cacat:
Ketidaksempurnaan
pada sebuah produk kerja yang ditemukan oleh perekayasaan PL. Setelah PL itu
disampaikan kepada pemakai akhir.
Analisis
kegagalan bekerja dengan cara sebagai berikut:
1.
Semua kesalahan &
cacat dikategorikan dari awal
2.
Biaya untuk
mengkoreksi setiap kesalahan & cacat dicatat.
3.
Jumlah kesalahan &
cacat dari setiap kategori dihitung dan ditata dalam urutan naik.
4.
Biaya keseluruhan dari
kesalahan & cacat dalam setiap kategori dihitung.
5.
Data resultan
dianalisis untuk menemukan kategori yang menelan biaya besar.
6. Rencana dikembangkan untuk memodifikasi proses guna
mengeliminasi kelas kesalahan & cacat yang paling membutuhkan banyak biaya.
Gambar
3 Grafik tulang ikan analisa proses pengembangan perangkat lunak
Berdasarkan
langkah 1&2 diatas, ditemukan ada 8 penyebab kerusakan dan sumbernya :
·
Sumber
spesifikasi/persyaratan :
a. Logic
20%
b. Penanganan
data 10,5%
c. Standar
6,9%
Sumber
desain:
a. Spesifikasi
25,5%
·
Sumber kode :
a.
Interface perangkat
lunak 6,0%
b.
Interface perangkat
keras 7,7%
c.
Pemeriksaan kesalahan
10,9%
d.
Interface pemakai
11,7%
METRIK PROYEK
Metrik
Proses 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.
Pada
saat kerja teknis dimulai, metrik proyek mulai memiliki arti. Nilai produksi
yang disajikan dalam bentuk halaman dokumentasi, jam kajian, titik-titik
fungsi, dan deretan sumber yang disampaikan diukur, dan kesalahan yang
ditemukan selama masing-masing tugas 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 akan diambil untuk memunculkan
kode dan modul serta pengujian integrasi.
Tujuan
metrik proyek:
1. Untuk
meminimalkan jadwal pengembangan dengan melakukan penyesuaian yang diperlukan
untuk menghindari penundaan serta mengurangi masalah & resiko potensial.
2. 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 seharusnya mengukur:
·
Input (pengukuran
sumber daya yang dibutuhkan untuk melakukan pekerjaan).
·
Output (pengukuran
kemampuan penyampaian atau produk kerja yang diciptakan selama proses rekayasa
perangkat lunak).
·
Hasil (pengukuran yang
menunjukkan efektivitas kemampuan penyampaian).
Pengukuran
proyek PL bersifat taktis, yaitu bahwa metrik proyek & indikator yang
berasal dari pengukuran digunakan oleh manajer proyek dan Tim PL untuk
mengadaptasi aliran kerja proyek & aktifitas teknis.
Selagi
sebuah proyek berjalan, pengukuran usaha dan waktu kalender yang digunakan
dibandingkan dengan perkiraan awal (dan jadwal proyek). Manajer proyek
menggunakan data tersebut untuk memonitor & mengontrol kemajuan.
Selagi
PL berjalan dari spesifikasi ke perancangan, metrik teknik dikumpulkan untuk
memperkirakan kualitas desain serta memberikan indikator yang akan mempengaruhi
pendekatan yang akan diambil untuk memunculkan kode & modul serta pengujian
integrasi (integrated test).
PENGUKURAN PERANGKAT
LUNAK
Pengukuran
langsung dari proses rekayasa perangkat lunak menyangkut biaya dan usaha yang
diaperangkat lunakikasikan. 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, komperangkat lunakeksitas, efisiensi,
reliabilitas, kemampuan pemeliharaan, dsb.
Pengukuran
perangkat lunak dibedakan menjadi dua yaitu :
·
Pengukuran langsung
(direct)
o Metrik
Size-Oriented
·
Pengukuran tidak
langsung (indirect)
o Metrik
Function-Oriented
o Metrik
Function Point
Yang
diukur pada pengukuran langsung adalah:
·
Biaya
·
Pengaruh
·
Jumlah baris perintah
(LOC) yang diproduksi
·
Kecepatan eksekusi
·
Ukuran memori
·
Kesalahan
Yang
diukur pada pengukuran tidak langsung adalah:
·
fungsi
·
kualitas
·
kompleksitas
·
efisiensi
·
keandalan
·
kemampuan pemeliharaan
Metrik Size-Oriented
Metrik
perangkat lunak size-oriented ditarik dengan normalisasi kualitas dan atau
pengukuran produktivitas dengan mempertimbangkan ukuran perangkat lunak yang
dihasilkan.
Parameternya
adalah ukuran dari software yang dihasilkan. Dapat dilakukan jika ada record
atau catatan dari organisasi. Perlu diperhatikan bahwa yang record yang
diperlukan adalah keseluruhan aktivitas rekayasa perangkat lunak. Misalnya
tabel di bawah ini adalah pengumpulan dari data-data record yang ada dari
sebuah organisasi:
Proyek
|
LOC
|
Usaha
|
Dolar
|
halaman
|
Kesalahan
|
cacat
|
Manusia
|
alpha
|
12,100
|
24
|
168
|
365
|
134
|
29
|
3
|
betha
|
27,200
|
62
|
440
|
1224
|
321
|
86
|
5
|
gamma
|
20,200
|
43
|
314
|
1050
|
256
|
64
|
6
|
0 komentar:
Posting Komentar