proses perangkat lunak dan metrik proyek
DESCRIPTION
manproTRANSCRIPT
PROSES PERANGKAT LUNAK DAN METRIK PROYEK
1. Pengukuran, Metrik dan Indikator.2. Metrik dalam proses dan domain proyek3. pengukuran perangkat lunak4. Penyatuan berbagai pendekatan metrik5. Metrik untuk kualitas perangkat lunak
Metrik perangkat lunak mengacu pada pengukuran perangkat lunak komputer.
Pengukuran digunakan untuk membantu perhitungan, kontrolkualitas,
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.
1. Pengukuran, Metrik dan Indikator
Sebelum kita membahas lebih juah lagi, sebaiknya kita mengetahui dulu apa
dimaksud dengan pengukuran, metric dan indicator.
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.
2. 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.
2.1. 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
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 2 : Diagram analisa proses pengembangan perangkat lunak
Gambar 3 : Grafik tulang ikan analisa proses pengembangan perangkat lunak
Berdasarkan pada gambar di atas, 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%
2.2. 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).
3. 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 :
1. Pengukuran langsung (direct)
Metrik Size-Oriented
2. Pengukuran tidak langsung (indirect)
Metrik Function-Oriented
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
3.1. 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
Produktivitas = KLOC / usaha
Kualitas = kesalahan / KLOC
Biaya = biaya / KLOC
Dokumentasi = halaman / KLOC
Dimana LOC (line of code) menunjukkan jumlah baris kode yang dibuat pada
masing-masing proyek, misalnya pada kolom pertama, proyek aplha dibuat dengan
12100 baris kode dalam 365 halaman, dikembangakan dengan usaha 24 orang per
bulan dengan biaya $168000. Lalu ditemukan kesalahan sebanyak 134 pada proyek
sebelum direlease, 29 cacat setelah direlease pada pelanggan, dan ada 3 orang yang
bekerja pada pengembangan proyek perangkat lunak alpha.
Untuk pengembangan dari metrik ini, dapat dibuat metrik size oriented baru
yang sederhana untuk tiap proyek, misal: kesalahan per baris kode (dihitung ribuan),
cacat per baris kode (ribuan), dokumentasi per baris kode (ribuan), kesalahan per
usaha, baris kode per usaha, biaya per halaman dokumentasi, dsb.
Metrik ini tidak dapat diterima secara universal karena adanya kontroversi
pada penggunaan baris kode sebagai titik ukur. Sebagian yang setuju pada
pengukuran LOC menganggap bahwa LOC adalah suatu bukti real dari apa yang
dilakukan oleh perekayasa perangkat lunak (dalam konteks ini membuktikan berapa
banyak baris program yang ditulis oleh seorang programmer comment yang ada).
Sedangkan sebagian yang tidak setuju bahwa LOC dijadikan suatu tolak ukur
kebanyakan disebabkan alasan ambiguitas dari cara menghitung LOC itu sendiri.
Dalam masa-masa awal bahasa pemrograman Assembly, hal ini tidak menjadi suatu
masalah karena dalam 1 baris aktual program merupakan 1 baris instruksi, tetapi
dalam bahasa pemrograman tingkat tinggi, dimana pada masing-masing bahasa,
untuk menyelesaikan suatu masalah dengan algoritma yang sama pun LOC nya sudah
berbeda-beda. Bahkan dalam satu bahasa pemrograman yang sama, untuk
menyelesaikan masalah yang sama, LOC nya bisa berbeda jauh tergantung dari
algoritma yang digunakan. Hal ini yang membuat banyak sekali kontroversi
mengenai LOC sebagai tolak ukur dari sebuah software.
Metrik size-oriented tidak diterima sebagai cara terbaik untuk mengukur
proses pengembangan perangkat lunak. Sebagian besar berkisar di seputar pemakaian
LOC.
3.2. Metrik Function-Oriented
Metric perangkat lunak function-oriented menggunakan sebuah pengukuran
fungsionalitas yang disampaikan oleh aperangkat lunakikasi sebagai suatu nilai
normalisasi. Function point ditarik dengan menggunakan sebuah hubungan empiris
berdasarkan pengukuran langsung domain informasi perangkat lunak yang dapat
dihitung serta perkiraan kompleksitas perangkat lunak.
Normalisasi dilakukan pada fungsionalitas pada aplikasi, tetapi untuk
melakukan hal ini, fungsionalitas harus diukur dengan pengukuran langsung yang lain
karena fungsionalitas tidak dapat diukur secara langsung. Maka pengukuran dapat
dilakukan dengan pengukuran function point. Function point didapat dari penarikan
hubungan empiris berdasarkan pengukuran domain informasi software dan perkiraan
kompleksitas software.
Domain informasi yang biasa digunakan ada 6 karakteristik, yaitu:
Jumlah input pemakai: setiap input pemakai yang memberikan data yang
berorientasi pada aplikasi yang jelas pada perangkat lunak (harus dibedakan dari
penelitian yang dihitung secara terpisah) misal: tipe transaksi.
Jumlah output pemakai: setiap output pemakai yang memberikan informasi yang
berorientasi pada aplikasi kepada pemakai. Pada konteks ini output mengacu pada
laporan.
Layar, tampilan kesalahan, dsb. Jenis data individual pada laporan tidak dihitung
terpisah. Misal: report type.
Jumlah penyelidikan pemakai: input online yang mengakibatkan munculnya
beberapa respon perangkat lunak yang cepat dalam bentuk output online.
Jumlah file: setiap master logika (pengelompokan data logis yang menjadi suatu
bagian dari sebuah database yang besar atau sebuah file terpisah).
Jumlah interface eksternal: semua interface yang dapat dibaca oleh mesin yang
digunakan untuk memindahkan informasi ke sistem yang lain.
Sekali data telah dikumpulkan, maka nilai kompleksitas dihubungkan dengan
masing-masing penghitungan dengan tabel perhitungan sebagai berikut:
Metode pendekatan yang digunakan dapat disebut: Function Point (FP).
Parameter
PengukuranJumlah Sederhana Rata-Rata Kompleks
Faktor
Pembobotan
Jumlah input pemakai
X 3 4 6 =
Jumlah output pemakai
X 4 5 7 =
Jumlah penyelidikan pemakai
X 3 4 6=
Jumlah file X 7 10 15 =
Jumlah interface eksternal
X 6 7 10 =
Total =
FP = jumlah total x [0,65 + 0,01 x jumlah (fi)]
Dalam hal ini faktor pembobotan setiap faktor sudah menjadi standar dan
tidak dapat diubah- ubah, tetapi dalam penentuan kriteria suatu perangkat lunak pada
salah satu parameter pengukuran adalah sederhana, rata-rata atau kompleks
ditentukan oleh organisasi atau perkeyasa perangkat lunak yang melakukan
penghitungan itu sendiri. Tetapi meskipun begitu perkiraan kompleksitas tetap
bersifat subyektif.
Penghitungan metrik function point:
- Jumlah input pemakai. Setiap input pemakai yang memberikan data yang
berorientasi pada aperangkat lunakikasi yang jelas pada perangkat lunak dihitung.
Input ini harus dibedakan dari penelitian yang dihitung secara terpisah.
- Jumlah output pemakai. Setiap output pemakai yang memberikan informasi
yang berorientasi pada aperangkat lunakikasi kepada pemakai dihitung. Pada
konteks ini output mengacu pada laporan, layar, tampilan kesalahan, dsb. Jenis
data individual pada sebuah laporan tidak dihitung secara terpisah.
- 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. Setiap penyelidikan yang jelas dihitung.
- Jumlah file. 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. Semua interface yang dapat dibaca oleh mesin yang
digunakan untuk memindahkan informas ke sistem yang lain dihitung.
Jumlah (fi) didapat dari jumlah range jawaban dari 14 pertanyaan berikut:
1. Apakah sistem membutuhkan backup & recovery yang reliable?
2. Apakah komunikasi data dibutuhkan?
3. Apakah fungsi pemrosesan didistribusikan?
4. Apakah kinerja penting?
5. Apakah sistem akan berjalan pada lingkungan operasional yang sudah ada yang
paling banyak digunakan?
6. Apakah sistem membutuhkan entry data online?
7. Apakah entry data online membutuhkan ada transaksi input terhadap layar atau
operasi ganda?
8. Apakah file master diperbarui secara online?
9. Apakah input, output, file, atau in query kompleks?
10. Apakah pemrosesan internal kompleks?
11. Apakah kode didesain untuk dapat dipakai kembali?
12. Apakah desain melibatkan konversi dan instalasi?
13. Apakah sistem didesain untuk instalasi ganda dalam organisasi berbeda?
14. Apakah aplikasi didesain untuk memfasilitasi perubahan & mempermudah
pemakai untuk menggunakannya?
Range jawaban (skala) untuk pertanyaan diatas antara 0 s/d 5:
0 : tidak berpengaruh
1 : kurang penting
2 : cukup penting
3 : rata-rata
4 : penting
5 : sangat penting
Sekali function points telah dihitung, maka poin-poin tersebut digunakan
dengan cara analog dengan LOC untuk normalisasi 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
(Dimana untuk mendapatkan data-data untuk kesalahan, cacat, dolar, dsb dapat
diambil dari data-data pada tabel record pada metrik size-oriented).
Contoh:
Pada proyek alpha (tabel record metrik size oriented) sudah dihitung bahwa
jumlah input pemakainya ada 18 buah, jumlah output pemakai: 6 buah, jumlah
penyelidikan pemakai 22 buah, jumlah file 45 buah, jumlah interface eksternal 20
buah, dengan asumsi bahwa jumlah input pemakai rata-rata, jumlah output pemakai
sederhana, jumlah penyelidikan pemakai rata-rata, jumlah file kompleks, jumlah
interface eksternal sederhana. Semua karakteristik pada perangkat lunak ini moderat.
Hitung $ per FP nya!
Jawab:
Jumlah total = (18 x 4) + (6 x 4) + (22 x 4) + (45 x 15) + (20 x 6) = 979Fi = 14 x 2 = 28
FP = 979 x (0,65 + (0,01 x 28)) = 910,47
$ Pada proyek alpha: 168000
$ Per FP = 168000 / 910,47 = $184,52
Hasil dari contoh kasus diatas masih berupa suatu angka mentah, untuk dapat
dilihat apakah angka ini termasuk baik atau tidak harus diperbandingkan dengan
perhitungan lain, misalnya $ per FP dari proyek beta atau gamma, atau proyek dari
organisasi lain.
Sebenarnya banyak sekali metrik-metrik yang digunakan untuk mengukur
perangkat lunak, misalnya metrik FP yang diperluas (biasanya diaplikasikan dalam
dunia bisnis) tetapi belum sempat dibahas disini.
Lima faktor penting yang mempengaruhi produktivitas perangkat lunak
menurut Basili dan Zelkowitz:
1. faktor manusia
2. faktor masalah
3. faktor proses
4. faktor produk
5. faktor sumber daya
Faktor – faktor untuk mengukur kualitas perangkat lunak (4 metrik kualitas):
1. Cara yang benar. Program harus beroperasi dengan benar. Cara yang benar adalah
tingkat dimana perangkat lunak melakukan fungsi-fungsi yang ditentukan. Ukuran
yang paling umum adalah cacat per KLOC, dimana cacat didefinisikan sebagai
kurangnya kesesuaian (yang telah terbukti) dengan persyaratan.
2. Maintanabilitas. Merupakan kemudahan dimana program dapat dikoreksi jika
ditemukan kesalaha, diadaptasi jika lingkungannya berubah, atau diperkuat jika
pelanggan menginginkan perubahan kebutuhan. Metrik time-oriented sederhana
adalah rata-rata waktu untuk berubah-ubah (MTTC), waktu yang diperlukan untuk
menganalisis perubahan yang diperlukan, desain modifikasi yang tepat,
mengimperangkat lunakementasikan perubahan, mengujinya, dan
mendistribusikan perubahan kepada semua pemakai. Rata-rata, program yang
dapat dipelihara akan mempunyai MTTC lebih rendah (untuk tipe perubahan
ekivalen) daripada program yang tidak dapat dipelihara.
3. Integritas. Mengukur kemampuan sistem untuk menahan serangan (baik kebetulan
maupun sengaja) terhadap sekuritasnya. Serangan dapat dilakukan pada semua
komponen perangkat lunak: program, data, dan dokumen.
4. Untuk mengukur integritas, ada dua atribut tambahan yang harus ditentukan:
ancaman dan sekuritas. Ancaman adalah probabilitas (yang dapat diestimasi atau
berasal dari bukti-bukti empiris) bahwa serangan tipe tertentu akan terjadi dalam
suatu periode waktu yang ditentukan. Sekuritas adalah probabilitas probabilitas
(yang dapat diestimasi atau berasal dari bukti-bukti empiris) bahwa serangan tipe
tertentu akan dipukul mundur. Integritas sistem kemudian ditentukan sebagai:
integritas = Σ [1-ancaman*(1-sekuritas)], dimana ancaman dan sekuritas adalah
jumlah dari masing-masing jenis serangan.
5. Usebilitas. Merupakan usaha untuk mengukur user-friendliness dan dapat diukur
dalam empat karakteristik:
Ketrampilan fisik dan atau intelektual untuk mempelajari sistem.
Waktu yang diperlukan untuk menjadi cukup efisien dalam menggunakan
sistem.
Peningkatan bersih dalam produktivitas (dalam pendekatan jika sistem diganti)
yang diukur ketika sistem digunakan oleh seseorang yang cukup efisien.
Penilaian subyektif (kadang-kadang diperoleh melalui kuisioner) dari sikap
pemakai terhadap sistem.
Faktor – faktor yang mempengaruhi biaya pengembangan PL:
1. Kemampuan programmer dan tenaga kerja
2. Kekompleksan produk
3. Ukuran produk
4. Waktu yang tersedia
5. Keandalan yang diperlukan
6. Teknologi yang dipergunakan
4. Penyatuan berbagai pendekatan metrik
Basili dan Zelkowitz menetapkan faktor penting yang mempengaruhi produktivitas perangkat lunak, yaitu:
Faktor manusia. Ukuran dan keahlian organisasi pengembangan.
Faktor masalah. Komperangkat lunakeksitas 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 produktivitas tersebut diatas rata-rata untuk suatu proyek yang ditentukan, maka produktivitas pengembangan perangkat lunak akan secara signifikan lebih tinggi daripada jika faktor yang sama berada dibawah rata-rata.
METRIK UNTUK KUALITAS PERANGKAT LUNAK
Tujuan rekayasa perangkat lunak adalah untuk menghasilkan sistem, aperangkat lunakikasi, atau produk brkualitas tinggi. Untuk mencapai tujuan tersebut, perekayasa perangkat lunak harus menerapkan perangkat kerasan 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 direalisir.
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.
Faktor-Faktor yang Mempengaruhi Kualitas
Faktor-faktor kualitas yang merupakan langkah pertama dalam mengembangkan metrik-metrik untuk kualitas perangkat lunak. Faktor-faktor tersebut menilai perangkat lunak dari tiga sudut pandang yang berbeda, yaitu (1) operasi produk(menggunakannya), (2) revisi produk(mengubahnya), (3) transisi produk(memodifikasinya untuk bekerja dalam lingkungan yang berbeda).
Mengukur Kualitas
Indikator berharga bagi tim proyek:
- Cara yang benar. Program harus beroperasi dengan benar. Cara yang benar adalah tigkat dimana perangkat lunak melakukan fungsi-fungsi yang ditentukan. Ukuran yang paling umum adalah cacat per KLOC, dimana cacat didefinisikan sebagai kurangnya kesesuaian(yang telah terbukti) dengan persyaratan.
- Maintanibilitas. merupakan kemudahan dimana program dapat dikoreksi jika ditemukan kesalaha, diadaptasi jika lingkungannya berubah, atau diperkuat jika pelanggan menginginkan perubahan kebutuhan. Metrik time-oriented sederhana adalah rata-rata waktu untuk berubah-ubah (MTTC), waktu yang diperlukan untuk menganalisis perubahan yang diperlukan, desain modifikasi yang tepat, mengimperangkat lunakementasikan perubahan, mengujinya, dan mendistribusikan perubahan kepada semua pemakai. Rata-rata, program yang dapat dipelihara akan mempunyai MTTC lebih rendah(untuk tipe perubahan ekivalen) daripada program yang tidak dapat dipelihara.
- Integritas. Mengukur kemampuan sistem untuk menahan serangan (baik kebetulan maupun sengaja) 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 (yang dapat diestimasi atau berasal dari bukti-bukti empiris) bahwa serangan tipe tertentu akan terjadi dalam suatu periode waktu yang ditentukan. Sekuritas adalah probabilitas probabilitas (yang dapat diestimasi atau berasal dari bukti-bukti empiris) bahwa serangan tipe tertentu akan dipukul mundur. Integritas sistem kemudian ditentukan sebagai:
integritas = Σ [1-ancaman*(1-sekuritas)], dimana ancaman dan sekuritas adalah jumlah dari masing-masing jenis serangan.
- Usabilitas. Merupakan usaha untuk mengukur user-friendliness dan dapat diukur dalam empat karakteristik:
1. ketrampilan fisik dan atau intelektual untuk mempelajari sistem,
2. waktu yang diperlukan untuk menjadi cukup efisien dalam menggunakan sistem,
3. peningkatan bersih dalam produktivitas (dalam pendekatan jika sistem diganti) yang diukur ketika sistem digunakan oleh seseorang yang cukup efisien,
4. penilaian subyektif (kadang-kadang diperoleh melalui kuisioner) dari sikap pemakai terhadap sistem.
Efisiensi Penghapusan Cacat
Metrik kualitas yang memberikan manfaat pada tingkat proyek dan tingkat proses adalah efisiensi penghapusan cacat (DRE-Defect Removal Efficiency). Pada dasarnya DRE adalah mengukur kemampuan penyaringan jaminan kualitas dan aktivitas kontrol ketika keduanya diteraperangkat kerasan pada semua aktivitas kerangka kerja proses.
DRE = E/(E+D), dimana
E = Σ kesalahan yang ditemukan sebelum perangkat lunak dikirim kepada pemakai akhir,
D = jumlah cacat yang ditemukan setelah pengiriman,
Nilai idealnya adalah 1, dimana tidak ditemukan adanya cacat pada perangkat lunak. Secara kenyataan, D akan lebih besar dari nol, tetapi nilai DRE masih dapat mendekati 1 jika E bertambah. Jika E bertambah, maka kemungkinan besar nilai akhir D akan berkurang(kesalahan disaring sebelum menjadi cacat).
MENYATUKAN METRIK-METRIK DALAM PROSES PERANGKAT LUNAK
Pengukuran memberikan manfaat pada tingkat strategik, pada tingkat proyek, dan tingkat teknis. Jika proses pengembangan perangkat lunak dapat ditingkatkan, maka akan diperoleh pengaruh langsung kepada lini dasar. Tetapi untuk dapat menetaperangkat kerasan tujuan untuk peningkatan, maka status saat ini dari pengembangan perangkat lunak harus dipahami. karena itu digunakan pengukuran untuk membuat baseline proses. Baseline berfungsi sebagai basis untuk estimasi. Kumpulan metrik kualitas memampukan organisasi mengaktifkan proses rekayasa perangkat lunaknya untuk menghapus penyebab vital few dari cacat-cacat yang paling besar pengaruhnya terhaadap pengembangan perangkat lunak.
Kumpulan data membutuhkan investigasi historis terhadap proyek-proyek sebelumnya untuk menyusun kembali data yang diperlukan. komputasi metrik dapat dilakukan setelah ukuran-ukuran dikumpulkan. Tergantung luasnya ukuran yang dikumpulkan, metrik dapat menjangkau banyak metrik LOC atau FP serta metrik kualitas dan orientasi proyek lainnya. akhirnya, metrik harus dievaluasi dan diteraperangkat kerasan 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.