pengumpulan data, kemudian melakukan implementasi perhitungan metrics, dan yang terakhir adalah analisis hasil perhitungan metrics.
Studi Literatur
Studi literatur dilakukan dengan cara mempelajari jurnal, buku, artikel, dan situs yang terkait dengan metrics perangkat lunak berorientasi objek.
Metrics yang dipakai dalam penelitian ini adalah 6 buah metrics yang diajukan oleh Chidamber & Kemerer (1994). Metrics ini dipilih karena berhubungan dengan kualitas perangkat lunak. Selain itu, metrics ini banyak digunakan oleh umum (Hogan 1997).
Untuk nilai batas atas beberapa metrics, diperoleh berdasarkan saran dari RefactorIT. Pengumpulan Data
Pengumpulan data dilakukan setelah perangkat lunak ERP selesai dikembangkan. Data yang dikumpulkan adalah semua yang terkait dengan pengukuran metrics perangkat lunak ERP.
Implementasi Perhitungan Metrics
Pada tahap ini, perhitungan metrics dilakukan dengan bantuan tool CKJM (Chidamber & Kemerer Java Metrics) (Spinellis 2005). Tool ini dipilih karena hasil perhitungan metrics yang dihasilkan cukup sesuai dengan definisi metrics Chidamber & Kemerer (1994).
Analisis Hasil Perhitungan Metrics
Analisis dilakukan dengan cara membandingkan nilai metrics perangkat lunak ERP dengan nilai standard metrics yang disarankan oleh RefactorIT (Sarker 2005). Dari hasil perbandingan tersebut dapat diketahui class mana saja yang perlu diperiksa dan/atau direvisi. Selain itu, dicari juga nilai maksimal, minimal, dan median secara keseluruhan dari masing-masing metrics. Nilai-nilai ini yang akan memperkirakan kualitas perangkat lunak dari beberapa faktor kualitas yang terkait.
HASIL DAN PEMBAHASAN
Pengumpulan DataPerangkat lunak yang dipilih pada penelitian ini adalah perangkat lunak berbasis web, yaitu perangkat lunak ERP (Ernita
2008). Perangkat lunak tersebut dikembangkan dengan bahasa pemrograman Java, terdiri dari 236 classes dan 39 jar file sebagai library.
Perhitungan metrics secara manual membutuhkan semua file *.java (java file) sedangkan perhitungan metrics dengan CKJM membutuhkan semua file hasil kompilasi (class file) pada project ERP beserta library yang dipakainya. File tersebut masing-masing berekstensi *.class dan *.jar.
Pada project ERP, class file dan jar file tersimpan di bawah direktori erp/build/web/WEB-INF/classes dan erp/build/web/WEB-INF/lib sedangkan java file tersimpan di bawah direktori erp/src/java. Implementasi Perhitungan Metrics
Pada tahap ini, perhitungan metrics secara manual dilakukan dengan melihat source code class (*.java) dari data yang diperoleh. Lampiran 1 memperlihatkan source code salah satu class, yaitu class LoginCustomerController. Perhitungan keenam metrics secara manual terhadap class LoginCustomerController dapat dilihat pada lampiran 2. Berikut nilai keenam metrics untuk class LoginCustomerController:
• WMC = 13 • DIT = 1 • NOC = 0 • CBO = 4 • RFC = 26 • LCOM = 17
Implementasi perhitungan metrics secara manual tentunya membutuhkan waktu yang tidak sedikit. Dengan mempertimbangkan keterbatasan waktu, maka digunakan CKJM sebagai tool untuk melakukan perhitungan DIT, NOC, CBO, RFC sedangkan WMC dan LCOM dihitung secara manual. Hal ini dikarenakan CKJM mengasumsikan kompleksitas semua methods = 1 dalam menghitung WMC sedangkan penelitian ini menggunakan CC sebagai kompleksitas semua methods. Selain itu, CKJM masih belum dapat menghitung LCOM ketika class yang diukur tidak memiliki instance variable. Hasil perhitungan keenam metrics pada perangkat lunak ERP (Ernita 2008) dapat dilihat pada lampiran 3.
Analisis Hasil Perhitungan Metrics
Dari hasil perhitungan keenam metrics yang didapat pada tahap sebelumnya, dapat dilakukan analisis sebagai berikut:
1 Weighted Methods per Class (WMC) Histogram pada gambar 6 memperlihatkan bahwa modus nilai WMC adalah 6, yaitu sebanyak 30 class. Selain itu, sebanyak 224 class memiliki WMC di bawah 50 dan hanya 12 class yang memiliki WMC di atas 50. Ini menunjukkan bahwa sebagian besar class yang ada pada perangkat lunak ERP memiliki kompleksitas yang masih bisa ditoleransi.
Class yang memiliki WMC di bawah 50, bukan berarti class tersebut tidak kompleks. Bisa saja methods pada class tersebut lebih banyak menggunakan message passing. Hal ini tentunya dapat mengurangi nilai CC pada methods tersebut sehingga mengurangi nilai WMC. Akan tetapi, WMC setidaknya dapat menentukan class mana saja yang patut disarankan untuk diperiksa ulang dan/atau direvisi.
Gambar 6 Histogram WMC pada perangkat lunak ERP.
Ada sebanyak 12 class yang disarankan diperiksa ulang dan/atau diperbaiki dari segi kompleksitas karena memiliki WMC di atas 50. 12 class tersebut dapat dilihat pada lampiran 4.
Tabel 1 memperlihatkan ringkasan statistik nilai-nilai WMC pada perangkat lunak ERP. Tabel tersebut memperlihatkan nilai standard deviasi yang cukup besar. Ini berarti nilai-nilai WMC pada classes yang diamati menyebar dari nilai tengahnya sehingga lebih baik menggunakan nilai median sebagai nilai rata-rata daripada menggunakan nilai mean (Walpole 1992). Dari nilai mediannya, dapat diartikan bahwa rata-rata nilai WMC perangkat lunak ERP memiliki nilai di bawah nilai batas atas. Dengan demikian WMC perangkat lunak ERP rendah.
Tabel 1 Ringkasan statistik WMC pada perangkat lunak ERP.
Metric Min Max Median Stdev
WMC 0 81 9 15.9791
2 Depth of Inheritance Tree (DIT)
Gambar 7 adalah histogram DIT pada perangkat lunak ERP. Tidak seperti WMC, DIT pada perangkat lunak ERP cenderung memiliki nilai yang hampir seragam. Modus DIT adalah 1, yaitu sebanyak 189 class. Ini berarti bahwa sebagian besar class pada perangkat lunak ERP hanya mewarisi class root-nya, yaitu class java.lang.Object. Selain itu, sebanyak 47 class memiliki nilai DIT sebesar 3. Ini berarti bahwa tingkat reuse pada perangkat lunak ERP sangat tinggi karena semua class mewarisi superclass-nya. Untuk class yang memiliki nilai DIT 3, class tersebut memiliki tingkat reuse yang lebih tinggi, tetapi juga meningkatkan kompleksitasnya.
Gambar 7 Histogram DIT pada perangkat lunak ERP.
Tabel 2 memperlihatkan ringkasan statistik nilai-nilai DIT. Metric DIT pada perangkat lunak ERP memiliki nilai median sebesar 1. Dengan demikian, rata-rata class pada perangkat lunak ERP memiliki nilai DIT yang kecil di bawah nilai batas atas yang disarankan oleh RefactorIT, yaitu sebesar 5. Atau lebih tepatnya lagi, semua class pada perangkat lunak ERP memiliki nilai DIT di bawah 5. Dengan demikian tidak perlu dilakukan pemeriksaan ulang dan/atau revisi pada semua class dari segi inheritance. Tabel 2 Ringkasan statistik DIT pada
perangkat lunak ERP.
Metric Min Max Median Stdev
DIT 1 3 1 0.80042
3 Number of Children (NOC)
Histogram pada gambar 8 menjelaskan bahwa NOC pada perangkat lunak ERP
seragam, yaitu sebesar 0. Ini berarti bahwa semua class pada perangkat lunak ERP tidak memiliki subclass. Dengan kata lain, pengembang perangkat lunak ERP tidak memanfaatkan pewarisan dalam membuat class. Hal ini mungkin diakibatkan kurangnya komunikasi antara desainer class yang berbeda sehingga kesempatan reuse class tidak dapat direalisasikan.
Gambar 8 Histogram NOC pada perangkat lunak ERP.
NOC yang semakin rendah berarti kemungkinan kesalahan dalam melakukan sub-classing semakin rendah. Dalam kasus ini tidak terdapat kesalahan dalam melakukan sub-classing karena semua class memiliki nilai NOC sebesar 0.
Tabel 3 memperlihatkan ringkasan statistik nilai-nilai NOC. Dapat dilihat pada tabel 3 bahwa semua nilai statistiknya adalah 0. Dengan demikian, rata-rata nilai NOC sangat rendah dibandingkan nilai batas atas yang disarankan RefactorIT sehingga tidak diperlukan pemeriksaan ulang dan/atau revisi class dari segi ketepatan sub-classing.
Tabel 3 Ringkasan statistik NOC pada perangkat lunak ERP.
Metric Min Max Mean Stdev
NOC 0 0 0 0
4 Coupling Between Object Class (CBO) Histogram pada gambar 9 menjelaskan bahwa nilai CBO pada perangkat lunak ERP memiliki modus sebesar 1. Sebanyak 66 class memiliki nilai CBO sebesar 1. Histogram tersebut juga menunjukkan adanya dua pencilan atau nilai ekstrim. Kedua pencilan tersebut memiliki nilai CBO masing-masing sebesar 21 dan 25.
Karena belum ditemukannya nilai batas atas CBO, tidak dapat dipastikan apakah kedua pencilan tersebut disarankan untuk diperiksa ulang dan/atau direvisi. Akan tetapi,
setidaknya kedua pencilan tersebut memiliki peluang besar untuk diperiksa ulang dan/atau direvisi. Hal ini dikarenakan class dengan nilai CBO yang semakin besar mengindikasikan class tersebut semakin sulit dipahami, semakin sulit untuk digunakan ulang, dan tentunya semakin sulit dirawat. Kedua class tersebut dapat dilihat pada lampiran 4.
Gambar 9 Histogram CBO pada perangkat lunak ERP.
Tabel 4 menunjukkan bahwa nilai-nilai CBO cukup menyebar dari nilai tengahnya. Selain itu, median sebesar 4 menunjukkan bahwa rata-rata nilai CBO pada perangkat lunak ERP cukup rendah.
Tabel 4 Ringkasan statistik CBO pada perangkat lunak ERP.
Metric Min Max Median Stdev
CBO 0 25 4 3.7587
5 Response for A Class (RFC)
Gambar 10 Histogram RFC pada perangkat lunak ERP.
Histogram pada gambar 8 menjelaskan bahwa modus nilai RFC adalah 4, yaitu sebanyak 22 class. Selain itu, histogram tersebut juga menunjukkan bahwa sebagian besar class memiliki nilai RFC di bawah batas atas yang disarankan RefactorIT, yaitu sebesar 50. Jumlah class tersebut sebanyak 213 class. Sisanya, 23 class, memiliki nilai di atas batas atas. RFC yang tinggi tentunya meningkatkan kompleksitas class tersebut. Dengan
demikian, ke-23 class tersebut disarankan untuk diperiksa ulang dan/atau direvisi sehingga nilai RFC-nya bisa berada di bawah nilai batas atas yang disarankan oleh RefactorIT. Ke-23 class tersebut dapat dilihat pada lampiran 4.
Tabel 5 memperlihatkan ringkasan statistik nilai-nilai RFC. Rata-rata nilai RFC, sebesar 20, berada di bawah nilai batas atas yang disarankan oleh RefactorIT. Ini berarti RFC pada perangkat lunak ERP rendah.
Tabel 5 Ringkasan statistik RFC pada perangkat lunak ERP.
Metric Min Max Median Stdev
RFC 0 153 20 23.2365
6 Lack of Cohesion in Methods (LCOM) Gambar 11 memperlihatkan histogram LCOM. Dapat dilihat dengan jelas bahwa modus nilai LCOM sebesar 0, yaitu sebanyak 116 class. Seperti yang telah dibahas pada Tinjauan Pustaka, nilai LCOM sebesar 0 dapat terjadi ketika nilai |P| ≤ |Q|. Selain itu, dapat juga terjadi ketika semua n himpunan {I1},
{I2}, …, {In} adalah Ø. Dengan demikian,
class yang memiliki nilai LCOM sebesar 0 bisa saja adalah class yang tidak memiliki instance variable, class yang hanya memiliki 1 buah method, atau bahkan interface. Banyaknya nilai 0 ini terjadi karena memang sebagian besar class pada perangkat lunak ERP adalah interface dan class yang tidak memiliki instance variable.
Gambar 11 Histogram LCOM pada perangkat lunak ERP.
Histogram tersebut juga memperlihatkan cukup banyaknya nilai LCOM yang berada di atas 100, yaitu sebanyak 58 class. Bahkan terdapat class yang memiliki nilai LCOM mencapai 2588. Akan tetapi, nilai LCOM yang besar belum berarti tingkat cohesiveness suatu class rendah.
Rosenberg (1998) mengatakan semakin kecil nilai LCOM dibandingkan dengan nilai maksimumnya, semakin baik cohesiveness-nya, begitu juga sebaliknya. Dengan demikian perlu diketahui nilai rasio antara nilai aktual LCOM dengan nilai maksimal LCOM suatu class sebelum menyimpulkan tingkat cohesiveness-nya. Berdasarkan landasan tersebut nilai rasio didapat dengan rumus sebagai berikut:
dimana,
• rasioLCOM adalah nilai rasio LCOM • LCOM adalah nilai aktual LCOM suatu
class.
• maxLCOM adalah nilai maksimum LCOM
suatu class.
maxLCOM terjadi ketika |Q| = 0, yaitu ketika |P| maksimal. Ini berarti tidak terdapat satu-pun pasangan method yang menggunakan instance variable yang sama. Dengan kata lain, nilai maksimum LCOM dirumuskan sebagai berikut:
dimana,
• NOM adalah number of methods, yaitu jumlah method yang terdapat pada class. Nilai rasio tersebut berada dalam selang [0, 1]. Class yang memiliki nilai rasio yang semakin dekat dengan 0, berarti semakin tinggi cohesiveness class tersebut. Begitu juga sebaliknya, semakin dekat nilai rasio sebuah class dengan 1, berarti semakin rendah cohesiveness class tersebut.
Nilai rasio masing-masing class dapat dilihat pada lampiran 3. Nilai rasio tersebut dapat digunakan sebagai petunjuk untuk mengetahui class mana saja yang sekiranya perlu diperiksa ulang dan/atau direvisi, yaitu class yang memiliki nilai rasioLCOM mendekati 1 (cohesiveness rendah). Class tersebut disarankan untuk dipecah menjadi dua atau lebih class agar tingkat cohesiveness-nya menjadi lebih tinggi.
Tabel 6 Ringkasan statistik nilai rasio LCOM pada perangkat lunak ERP.
Min Max Mean Stdev
0.0000 0.9693 0.3191 0.3670 rasioLCOM
Dapat dilihat pada tabel 6, nilai standard deviasi dari nilai rasio LCOM cukup kecil sehingga tidak terlalu banyak pencilan dalam data. Dengan demikian, rata-rata nilai rasio LCOM dapat menggunakan nilai mean, yaitu sebesar 0.3191. Ini menandakan tingginya tingkat cohesiveness perangkat lunak ERP. Dengan kata lain LCOM pada perangkat lunak ERP dapat dikatakan cukup rendah. 7 Kualitas Perangkat Lunak ERP
Dari hasil analisis keenam metrics, dapat dianalisis lebih lanjut seberapa baik kualitas perangkat lunak ERP berdasarkan faktor-faktor kualitas yang terkait dengan keenam metrics tersebut. Tinggi rendahnya nilai metrics akan mempengaruhi pada tinggi rendahnya faktor-faktor kualitas yang terkait pada masing-masing metric. Sebagai contoh, nilai WMC yang tinggi menyebabkan menurunnya tingkat reusability, usability, dan testability. Untuk lebih jelasnya, dapat dilihat pengaruh nilai metrics terhadap faktor-faktor kualitas yang terkait pada lampiran 5.
Pada pembahasan sebelumnya telah diketahui apakah nilai setiap metrics pada perangkat lunak ERP itu rendah atau tinggi. Dengan demikian, dapat diketahui seberapa tinggi reusability, usability, uderstandability, modifiability, dan testability perangkat lunak ERP dari nilai-nilai hasil pengukuran keenam metrics. Tabel 7 memperlihatkan ringkasan tinggi rendahnya nilai rata-rata setiap metric
beserta pengaruhnya terhadap faktor-faktor kualitas.
Dapat dilihat pada tabel 7 bahwa WMC dan CBO yang rendah mengakibatkan peningkatan reusability. Ini berarti setiap class mudah untuk di-reuse karena memiliki kompleksitas yang rendah. Di lain sisi, rendahnya DIT dan NOC mengakibatkan penurunan reusability. Ini dapat terjadi karena, pada kenyataanya, pengembang tidak terlalu memanfaatkan pewarisan dalam membuat class. Perbedaan tersebut dapat terjadi karena WMC dan CBO melakukan prediksi seberapa mudah suatu class untuk digunakan ulang berdasarkan kompleksitasnya sedangkan DIT dan NOC lebih melihat kepada fakta apakah suatu class memanfaatkan pewarisan secara baik. Dengan demikian, perbedaan pengaruh kedua pasangan metrics tersebut bukan merupakan suatu keanehan.
Lain halnya dengan faktor kualitas selain reusability, setiap metric meningkatkan faktor kualitas usability, understandability, modifiability, dan testability. Dengan demikian, kualitas perangkat lunak ERP dapat dikatakan tinggi dari segi usability, understandability, modifiability, dan testability. Akan tetapi, dari segi reusability hanya dapat dikatakan moderat.
Tabel 7 Kategori metrics perangkat lunak ERP beserta pengaruhnya terhadap faktor kualitas
Reusability Usability Understandability Modifiability Testability
1 WMC rendah ↑ ↑ NA NA ↑ 2 DIT rendah ↓ NA ↑ ↑ ↑ 3 NOC rendah ↓ NA NA NA ↑ 4 CBO rendah ↑ NA ↑ ↑ ↑ 5 RFC rendah NA NA ↑ ↑ ↑ 6 LCOM rendah NA NA ↑ ↑ ↑ No Metrics Kategori Faktor Kualitas
