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.