Proses Perangkat Lunak Dan Metrik
Proyek
Manfaat Pengukuran proyek perangkat lunak
membantu memperkirakan kualitas
produk kerja teknis
membantu mengambil keputusan
Pengukuran, Metrik dan Indikator
Measure mengindikasikan kuantitatif dari luasan, jumlah, dimensi, kapasitas atau ukuran dari atribut sebuah proses atau produk.
Metrik perangkat lunak menghubungkan pengukuran individu dengan banyak cara (seperti rata-rata jumlah kesalahan yang ditemukan per kajian atau jumlah rata-rata kesalahan yang ditemukan per person-hour yang dipakai pada kajian).
Metrik Dalam Proses dan Domain Proyek
Metrik harus dikumpulkan sehingga indicator
proses dan produk dapat dipastikan. Indikator proses berfungsi untuk :
1. memperoleh pengetahuan tentang reliabilitas sebuah proses yang sedang berlangsung
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; dan
(5). Mengevaluasi kemampuan tim proyek untuk mengontrol kualitas hasil kerja
Cara Mengukur reliabilitas proses
perangkat lunak secara tidak langsung
mengambil serangkaian metrik berdasarkan
keluaran yang dapat diambil oleh proses.
cacat yang disampaikan dan dilaporkan oleh
pemakai akhir
produk kerja yang dikirim,
usaha manusia yang dilakukan, waktu kalender yang digunakan, konfirmasi jadwal
Etika metrik perangkat lunak (Grady )
Gunakan istilah umum dan kepekaan
organisasi ketika menginterpretasi data metrik.
Berikan umpan balik reguler kepada individu
dan tim yang telah bekerja untuk
mengumpulkan pengukuran dan metrik.
Jangan menggunakan metrik untuk menilai
Etika metrik perangkat lunak (Grady )
Bekerja dengan pelaksana dan tim untuk
menentukan tujuan dan metrik yang jelas yang akan dipakai untuk mencapainya.
Jangan pernah menggunakan metrik untuk
mengancam individu dan tim.
Metrik data yang menunjukkan sebuah area
masalah tidak boleh “dianggap negative.” Data-data itu hanya merupakan sebuah indicator bagi peningkatan proses.
Jangan tergoda pada sebuah metrik dan
Cara Kerja Analisis kegagalan
statistical software process improvement (SSPI)
Semua kesalahan dan cacat dikategorikan
dari awal (contohnya, kekurangan dalam spesifikasi, kekurangan dalam logika,
ketidaksesuaian dengan standar).
Biaya untuk mengkoreksi setiap kesalahan
dan cacat dicatat.
Jumlah kesalahan dan cacat dari setiap
Cara Kerja Analisis kegagalan
statistical software process improvement (SSPI)
Biaya keseluruhan dari kesalahan dan cacat
dari setiap kategori dihitung.
Data resultan dianalisis untuk menemukan
kategori yang menelan biaya besar.
Rencana dikembangkan untuk memodifikasi
proses guna mengeliminasi (mengurangi
Metrik Proyek
Tujuan Matrik proyek
untuk meminimalkan jadwal pengembangan
dengan melakukan penyesuaian yang
diperlukan untuk menghindar penundaan serta mengurangi masalah dan risiko
potensial.
untuk memperkirakan kualitas produk pada
Hal yang di ukur dalam metrik proyek
input (pengukuran sumber daya seperti
manusia, lingkungan yang dibutuhkan untuk melakukan pekerjaan).
Output (pengukuran kemampuan
penyampaian atau produk kerja yang
diciptakan selama proses rekayasa perangkat lunak).
Hasil (pengukuran yang menunjukkan
Pengukuran Perangkat Lunak
Pengukuran
langsung
dari
proses rekayasa perangkat lunak
Pengukuran langsung dari produk menyangkut :
deretan kode (LOC) yang diproduksi, kecepatan eksekusi
ukuran memori
cacat yang dilaporkan pada sejumlah periode
Pengukuran tidak langsung dari produk
menyangkut fungsionalitas, kualitas,
kompleksitas, efisiensi,
reliabilitas,
kemampuan pemeliharaan,
Metrik Size-Oriented
(berorientasi pada ukuran)
serangkaian metrik size-oriented yang sederhana untuk setiap proyek:
kesalahan (error) per KLOC (ribuan baris
kode),
$ perLOC cacat (defect) per KLOC, halaman dokumentasi per KLOC, Kesalahan/person-month,
Metrik Function-Oriented
(berorientasi pada
fungsi)
menggunakan sebuah pengukuran
fungsionalitas yang disampaikan oleh aplikasi sebagai suatu nilai normalisasi.
pertama kali diusulkan oleh Albrecht yang
mengusulkan sebuah pengukuran yang disebut function point.
Function point ditarik dengan menggunakan
sebuah hubungan empiris berdasarkan
pengukuran (langsung) domain informasi
Penghitungan metrik function point
Parameter pengukuran Jml sederhana rata-rata kompleks Faktor Pembobot
Jml input pemakai x 3 4 6 =
Jml output pemakai x 4 5 7 =
Jml penyelidikan pemakai
x 3 4 6 =
Jml file x 7 10 15 =
Jml interface internal x 6 7 10 =
Jumlah input pemakai. Setiap input pemakai yang memberikan
data yang berorientasi pada aplikasi yang jelas pada perangkat lunak dihitung.
Jumlah output pemakai. Setiap output pemakai yang memberikan
informasi yang berorientasi pada aplikasi kepada pemakai
dihitung. Pada konteks ini output mengacu pada laporan, layar, tampilan kesalahan dsb.
Jumlah penyelidikan pemakai. Sebuah penyelidikan didefinisikan
sebagai input on-line yang mengakibatkan munculnya beberapa respon perangkat lunak yang cepat dalam bentuk sebuah output on-line.
Jumlah file. Setiap file master dihitung.
Jumlah interface eksternal. Semua interface yang dapat dibaca
Untuk menghitung titik-titik fungsi (FP)
dipakai hubungan sebagai berikut :
Fi dapat dihitung dari perhitungan sebagai berikut:
· Pertama-tama kita diberi 14 buah karakteristik dari suatu perangkat sebagai berikut:
1. Data communications 2. Distributed functions 3. Performance
4. Heavily used configuration 5. Transaction rate
6. Online data entry 7. End-user efficiency 8. Online update
9. Complex processing 10. Reusability
11. Installation ease 12. Operational ease 13. Multiple sites
Pada setiap karakteristik tersebut diberi
bobot dari nilai 0 sampai 5 dengan asumsi nilai sebagai berikut:
0. Tidak berpengaruh 1. Insidental
titik-titik pengukuran produktivitas, kualitas perangkat lunak, serta atribut-atribut yang lain :
kesalahan per FP cacat per FP
$ per FP
halaman dokumentasi per FP FP per person-month
Menentukan kompleksitan untuk function point 3D
Pernyataan Semantik
Langkah-lang kah pemrosesan
1 – 5 6 – 10 11 +
1 – 10 rendah rendah rata-rata 11 – 20 rendah rata-rata tinggi
Berbagai Pendekatan Metrik Yang Berbeda
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)
Bahasa assembly 320
C 128
Cobol 105
Fortran 105
Pascal 90
Ada 70
lima faktor penting yang mempengaruhi produktivitas
perangkat lunak (Basili dan Zelkowitz)
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
Faktor-faktor yang Mempengaruhi Kualitas
tiga sudut pandang berbeda, yaitu
(1). operasi produk (menggunakannya) (2). revisi produk (mengubahnya)
Hubungan antara kualitas dan aspek-aspek lain
dari proses rekayasa perangkat lunak :
kerangka kerja memberikan suatu mekanisme untuk
manajer proyek untuk mengenali kualitas-kualitas apa yang penting.
Kerangka kerja memberikan alat untuk menilai secara
kuantitatif seberapa baik kemajuan pengembangan.
Kerangka kerja memberikan interaksi yang lebih
dalam pada personil QA di sepanjang usaha pengembangan.
Personil jaminan kualitas dapat menggunakan indikasi
buruknya kualitas untuk membantu mengidentifikasi standar-standar untuk diusahakan di masa
Mengukur Kualitas (Glib)
Cara yang benar. adalah cacat per KLOC, di mana cacat didefinisikan sebagai kurangnya kesesuaian (yang telah terbukti) dengan persyaratan.
Maintanabilitas. adalah kemudahan di mana
program dapat dikoreksi jika ditemukan kesalahan,
diadaptasi jika lingkungannya berubah, atau diperkuat jika pelanggan menginginkan perubahan kebutuhan. Integritas. mengukur kemampuan sistem untuk
menahan serangan (baik kebetulan maupun sengaja) terhadap sekuritasnya.
Karakteristik Useabilitas :
ketrampilan fisik dan atau intelektual untuk
mempelajari sistem;
waktu yang diperlukan untuk menjadi cukup
efisien dalam menggunakan sistem
peningkatan bersih dalam produktivitas yang
diukur ketika sistem digunakan oleh seseorang yang cukup efisien
penilaian subyektif dari sikap pemakai
Efisiensi Penghapusan Cacat
Metrik kualitas yang memberikan manfaat pada tingkat proyek dan tingkat proses adalah efisiensi
penghapusan cacat (DRE – defect removal efficiency). DRE adalah mengukur kemampuan penyaringan
jaminan kualitas dan aktivitas kontrol
Dengan mempertimbangkan proyek sebagai satu
kesatuan, maka DRE didefinisikan sbb : DRE = E / ( E + D )
E = jumlah kesalahan sblm dikirim kepada pemakai akhir
D = jumlah cacat setelah pengiriman