PENGUKURAN PERANGKAT LUNAK PENGANTAR: Pengukuran adalah suatu hal pokok bagi disiplin perekayasaan(engineering), tidak terkecuali pada perekayasaan perangkat lunak atau software. Jangkauan luas pengukuran pada perangkat lunak komputer disebut metrik perangkat lunak. Tujuan diterapkannya pengukuran pada proses perangkat lunak adalah untuk mengembangkan perangkat lunak itu sendiri dengan dasar yang kontinu. Pengukuran software dalam konteks manajemen software difokuskan pada produktivitas dan metrik kualitas (pengukuran output perkembangan software sebagai fungsi usaha dan waktu yang diaplikasikan serta pengukuran kesesuaian pemakaian dari produk kerja yang dihasilkan). 1. PENGUKURAN, METRIK, DAN INDIKATOR Dalam konteks rekayasa perangkat lunak, mengukur (measure) mengindikasikan kuantitatif dari ukuran atribut sebuah proses atau produk. Pengukuran (measurement) adalah kegiatan menentukan sebuah measure (pengukuran). Dan definisi metriks menurut IEEE adalah ukuran kuantitatif dari tingkat dimana sebuah system, komponen atau proses memiliki atribut tertentu. Pengukuran telah ada jika suatu data-data tunggal telah dikumpulkan (misal: jumlah kesalahan yang ditemukan pada kajian sebuah modul tunggal). Metrik perangkat lunak menghubungkan pengukuran-pengukuran individu dengan banyak cara, misal rata-rata dari jumlah kesalahan yang ditemukan pada setiap kajian. Rekayasa perangkat lunak mengumpulkan pengukuran dan mengembangkan metrik menjadi sebuah indikator, yaitu sebuah metrik atau kombinasi metrik yang memberikan pengetahuan dalam proses perangkat lunak, sebuah proyek perangkat lunak, atau produk itu sendiri. Fungsinya adalah memberi pengetahuan pada manajer proyek atau perekayasa perangkat lunak untuk menyesuaikan proses, proyek, dan produk agar menjadi lebih baik.
2. PENGUKURAN PERANGKAT LUNAK Pengukuran langsung dari produk berkaitan dengan deretan kode, kecepatan eksekusi, ukuran memori, dan cacat yang dilaporkan pada suatu periode tertentu. Sedangkan pengukuran tidak langsung dari produk adalah tentang fungsionalitas, kualitas, kompleksitas, efisiensi, realibilitas, kemampuan pemeliharaan, dsb.dalam kenyataannya, pengukuran perangkat lunak secara objektif akan sulit dilakukan secara langsung karena ada pengaruh-pengaruh seperti individu dalam tim pengukuran, atau tingkat kompleksitas proyek. Tetapi jika pengukuran dinormalisasi, maka mungkin akan dapat didapatkan metrik perangkat lunak yang memungkinkan perbandingan dengan rata-rata organisasional yang lebih besar. 2.1 METRIK SIZE ORIENTED 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 dibawah ini adalah pengumpulan dari data-data record yang ada dari sebuah organisasi: 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. 2.2 METRIK FUNCTION ORIENTED 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 5 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: Faktorpembobotan Dalam hal ini faktor pembobotan setiap faktor sudah menjadi standar dan tidak dapat diubahubah, 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. Untuk menghitung function point (FP) dapat digunakan hubungan sbb: FP = jumlah total x [0,65 + 0,01 x Fi] dimana jumlah total adalah nilai yang kita dapatkan pada tabel perhitungan di atas. Sedangkan Fi dapat dihitung dari perhitungan sebagai berikut: Pertama-tama kita diberi 14 buah karakteristik dari suatu perangkat sebagai berikut: 1. Data communications (Apakah komunikasi data dibutuhkan?)
2. Distributed functions (Apakah fungsi pemrosesan didistribusikan?) 3. Performance (Apakah kinerja penting?) 4. Heavily used configuration (Apakah konfigurasi berat yang digunakan?) 5. Transaction rate (Apakah entry data online membutuhkan ada transaksi input terhadap layar atau operasi ganda?) 6. Online data entry (Apakah sistem membutuhkan entry data online?) 7. End-user efficiency (Apakah keefektifan terhadap end-user?) 8. Online update (Apakah file master diperbarui secara online?) 9. Complex processing (Apakah pemrosesan internal kompleks?) 10. Reusability (Apakah kode didesain utk dpt dipakai kembali?) 11. Installation ease (Apakah mudah dalam melakukan instalasi?) 12. Operational ease (Apakah mudah dalam pengoperasian?) 13. Multiple sites (Apakah sistem didesain utk instalasi ganda dlm organisasi berbeda?) 14. Facilitation of change (Apakah aplikasi didesain utk memfasilitasi perubahan dan mempermudah pemakai utk menggunakannya?) Pada setiap karakteristik tersebut diberi bobot dari nilai 0 sampai 5 dengan asumsi nilai sebagai berikut: 0. Tidak berpengaruh 1. Insidental 2. Moderat 3. Rata-rata 4. Signifikan 5. Essential Setelah setiap karakteristik diberi bobot masing-masing, lalu bobot-bobot dari setiap karakteristik ini dijumlahkan (jadi minimum 0 dan maksimal 70) dan kita akan mendapatkan nilai Fi. Setelah mendapatkan nilai Fi maka kita bisa menghitung nilai FP dengan rumus di yang sudah ada di atas.
Setelah kita mendapatkan nilai FP, maka kita dapat menggunakannya dengan cara analog dengan LOC untuk menormalisasi pengukuran produktivitas, kualitas perangkat lunak, serta atribut-atribut yang lain seperti: kesalahan per FP cacat per FP $ per FP halaman dokumentasi per FP FP per person-month dsb (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) = 979 Fi = 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.