Buku ajar kecil 03

Buku Ajar Rekayasa Perangkat Lunak

BAB 3Metrik 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 menentukan sebuah measure (pengukuran). IEEE

23


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.

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

24


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.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.

25


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 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.

26


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 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

27


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.

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

28


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 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.

29


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.

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

30


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

Tabel 3.5. Tingkatan untuk ILF dan EIF

31


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.

No. Karakteristik Sistem Keterangan

1 Kemudahan operasional

Apakah sistem membutuhkan backup dan recovery yang reliabel ?

2 Komunikasi data Apakah komunikasi data dibutuhkan ?

32


3 Pemrosesan data terdistribusi

Apakah fungsi pemrosesan 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 pemrosesan

Apakah pemrosesan internal kompleks ?

11 Pemakaian kembali

Apakah kode didesain untuk dapat dipakai kembali ?

12 Kemudahan instalasi

Apakah desain melibatkan konversi dan instalasi ?

13 Situs ganda Apakah sistem didesain untuk instalasi ganda dalam situs untuk organisasi berbeda ?

14 Fasilitas perubahan

Apakah aplikasi didesain untuk memfasilitasi perubahan dan mempermudah pemakai untuk menggunakannya ?

Sekali titik fungsi telah dihitung, maka titik-titik itu digunakan dengan cara analog dengan LOC untuk 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

33


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 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

34


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.

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.

35


Untuk menghitung function point 3D, digunakan hubungan sebagai berikut :Indeks = I + O + Q + F + E + T + RDimana 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.

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.

36


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)Assembly 320C 128Cobol 105Fortran 105Pascal 90ADA 70Bahasa berorientasi objek

30

Bahasa generasi keempat

20

Generator kode 15Spreadsheets 6Bahasa 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 :

37


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 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.

Gambar 3.6. Proses kumpulan metrik perangkat lunak.

5. Metrik untuk kualitas perangkat lunak.

Proses RPL

Proyek RPL

Produk RPL

Kumpulan data

Komputasi numerik

Evaluasi metrik

ukuran

metrik

indikator

38


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, 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).

39


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.

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.

40


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.

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 akhirD = 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

41


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

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

42


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

Documents

Buku ajar kecil 03