Mengukur Produktifitas Dalam Pengembangan Perangkat Lunak

1. Latar Belakang Masalah

Pada pertengahan tahun 60 sampai 70-an banyak dikembangkan sistem-sistem perangkat lunak yang besar. Sistem-sistem yang dikembangkan ini banyak yang dipandang tidak efisien, kurang berhasil, bahkan banyak yang gagal. Kegagalan ini disebabkan karena tidak tersedianya teknik pengembangan perangkat lunak yang baik. Pada awal tahun 70-an mulai muncul metodologi-metodologi pengembangan perangkat lunak yang cukup baik.

Pengembangan perangkat lunak dapat diartikan sebagai proses membuat suatu perangkat lunak baru untuk menggantikan perangkat lunak lama secara keseluruhan atau memperbaiki perangkat lunak yang telah ada. Agar lebih cepat dan tepat dalam mendeskripsikan solusi dan mengembangkan perangkat lunak, juga hasilnya mudah dikembangkan dan dipelihara, maka pengembangan perangkat lunak memerlukan suatu metodologi khusus. Metodologi pengembangan perangkat lunak adalah suatu proses pengorganisasian kumpulan metode dan konvensi notasi yang telah didefinisikan untuk mengembangkan perangkat lunak. Secara prinsip bertujuan untuk membantu menghasilkan perangkat lunak yang berkualitas. Penggunaan suatu metodologi sesuai dengan persoalan yang akan dipecahkan dan memenuhi kebutuhan pengguna akan menghasilkan suatu produk perekayasaan yang berkualitas dan terpelihara serta dapat menghindari masalah-masalah yang sering terjadi seperti estimasi penjadwalan dan biaya, perangkat lunak yang tidak sesuai dengan keinginan pengguna dan sebagainya.

Metodologi pengembangan perangkat lunak (atau disebut juga model proses atau etric rekayasa perangkat lunak) adalah suatu strategi pengembangan yang memadukan proses, metode, dan perangkat (tools). Disamping ketiga hal tersebut diperlukan juga suatu model untuk pengukuran kualitas perangkat lunak yang akan dibangun. Kualitas perangkat lunak dapat dihitung pada saat proses rekayasa perangkat lunak ataupun setelah diserahkan kepada pemakai. Satuan ukuran kualitas perangkat lunak pada saat proses rekayasa dapat meliputi; Kompleksitas program, modularitas yang efektif dan besarnya program.

Pengukuran adalah suatu hal pokok bagi disiplin perekayasaan(engineering), tidak terkecuali pada perekayasaan perangkat lunak atau software. Jangkauan luas pengukuran pada perangkat lunak etricr disebut etric 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 etric kualitas (pengukuran output perkembangan software sebagai fungsi usaha dan waktu yang diaplikasikan serta pengukuran kesesuaian pemakaian dari produk kerja yang dihasilkan).

2. Rumusan Masalah

1. Apa yang dimaksud dengan pengukuran, metric dan indicator?
2. Apa yang dimaksud dengan pengukuran perangkat lunak?
3. Apa yang dimaksud dengan Metrik Size Oriented?
4. Apa yang dimaksud dengan Metrik Function Oriented?
5. Apa saja Faktor Kualitas Perangkat Lunak dengan Model Faktor McCall?

3. Tujuan Penulisan

1. Untuk mengetahui apa yang dimaksud dengan pengukuran, metric dan indicator.
2. Untuk mengetahui apa yang dimaksud dengan pengukuran perangkat lunak.
3. Untuk mengetahui apa yang dimaksud dengan Metrik Size Oriented.
4. Untuk mengetahui apa yang dimaksud dengan Metrik Function Oriented.
5. Untuk mengetahui apa saja Faktor Kualitas Perangkat Lunak dengan Model Faktor McCall

PEMBAHASAN

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.

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

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

1. 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.
2. 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.
3. Jumlah penyelidikan pemakai: input online yang mengakibatkan munculnya beberapa respon perangkat lunak yang cepat dalam bentuk output online.
4. Jumlah file: setiap master logika (pengelompokan data logis yang menjadi suatu bagian dari sebuah database yang besar atau sebuah file terpisah).
5. 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:

Faktor pembobotan

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.

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:

1. 0 = Tidak berpengaruh
2. 1 = Insidental
3. 2 = Moderat
4. 3 = Rata-rata
5. 4 = Signifikan
6. 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:

1. Kesalahan per FP
2. Cacat per FP
3. $ per FP
4. Halaman dokumentasi per FP
5. FP per person-month
6. 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.

5. Faktor Kualitas Perangkat Lunak dengan Model Faktor McCall

Beberapa model faktor kualitas perangkat lunak dan kategorisasinya sudah diusulkan selama bertahun-tahun. Model klasik dari faktor kualitas perangkat lunak dikemukakan oleh McCall yang terdiri dari 11 faktor [McCall et al, 1977]. Model berikutnya dikemukakan oleh Deutsch dan Willis (1988) terdiri dari 12 sampai 15 faktor dan oleh Evans dan Marciniak (1987). Alternatif model tidak berbeda jauh dari model McCall. Perbedaannya terletak pada penambahan sudut pandang yang dirasa belum dinilai pada model McCall.

Model faktor McCall mengklasifikasikan semua kebutuhan perangkat lunak ke dalam 11 faktor kualitas. Kesebelas faktor tersebut dibagi menjadi tiga kategori sebagai berikut:1.Faktor operasi produk, terdiri dari: Correctness, Reliability, Efficiency, Integrity dan Usability. 2.Faktor revisi produk, terdiri dari: Maintainability, Flexibility,Testability. 3.Faktor transisi produk, terdiri dari: Portability, Reusability, Interoperability. Berikut ini adalah pembahasan tiap-tiap faktor beserta sub faktor yang ada di dalam model McCall:

Ada dua pengertian tentang efisiensi sebuah perangkat lunak, yaitu:a. Menurut McCall (1977) Penggunaan sumber daya seperti waktu pemrosesan processor (eksekusi), pemakaian media penyimpanan (memori, space, bandwidth). b.Menurut ISO 9126 (1993): Berkaitan dengan hubungan antara kinerja perangkat lunak dan jumlah sumber daya yang digunakan.

1. Integrity, Integritas perangkat lunak pada model McCall lebih menekankan kepada keamanan sebuah perangkat lunak. Pihak developer harus mampu melihat kebutuhan akan hak akses perangkat lunak tersebut pada setiap penggunanya.
2. Usability mempunyai unsur akademis seperti psikologis, ergonomi, dan human factors [Nielsen,1993]. Lima properti yang dibuat oleh Nielsen untuk mengukur usability sebuah perangkat lunak, yaitu: Cepat dan mudah untuk dipelajari, Efisien untuk digunakan, mengizinkan rapid recovery jika terjadi error, Nyaman untuk digunakan, Mudah untuk diingat.
3. Portability, Perangkat lunak dikatakan portabel jika biaya untuk memindahkannya (transport dan adaptasi) ke lingkungan yang baru lebih kecil jika dibandingkan dengan biaya untuk membangun perangkat lunak tersebut dari awal.
4. Reusability, Reusability adalah properti dari perangkat lunak yang memungkinkan perangkat lunak atau modul-modulnya digunakan kembali untuk sistem lain. Suatu perangkat lunak dikatakan reusable yang baik jika modul-modulnya dapat digunakan kembali untuk aplikasi lainnya.
5. Interoperability adalah kemampuan suatu perangkat lunak untuk bekerja dengan perangkat lunak lainnya tanpa mengalami kesulitan.

PENUTUP

1. Kesimpulan

Mengukur produktivitas dalam pengembangan perangkat lunak sangatlah perlu untuk dilakukan. Karena hal itu akan memberikan kita informasi sejauh mana perangkat lunak itu berhasil digunakan. Pengukurannya bisa menggunakan metric yang akan menghasilkan indicator. Ada dua matrik yang dapat digunakan dalam proses pengukuran, yakni matrik size oriented dan matrik fokus oriented. Lalu ada beberapa faktor kualitas suatu perangkat lunak menurut model kualitas McCall. Yang mana faktor-fektor ini akan menunjukkan kualitas dari perangkat lunak yang dioperasikan.