EVALUASI KUALITAS PERANGKAT LUNAK BERORIENTASI OBJEK
RHAMDANI
DEPARTEMEN ILMU KOMPUTER FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM INSTITUT PERTANIAN BOGOR BOGOR 2008
EVALUASI KUALITAS PERANGKAT LUNAK BERORIENTASI OBJEK
Skripsi sebagai salah satu syarat untuk memperoleh gelar Sarjana Komputer pada Fakultas Matematika dan Ilmu Pengetahuan Alam Institut Pertanian Bogor
Oleh : RHAMDANI G64104038
DEPARTEMEN ILMU KOMPUTER FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM INSTITUT PERTANIAN BOGOR BOGOR 2008
Judul : Evaluasi Kualitas Perangkat Lunak Berorientasi Objek Nama : Rhamdani NRP
: G64104038
Menyetujui : Pembimbing I,
Pembimbing II,
Wisnu Ananta Kusuma, S.T, M.T
Toto Haryanto, S.Kom
NIP. 132312485
Mengetahui: Dekan Fakultas Matematika dan Ilmu Pengetahuan Alam Institut Pertanian Bogor
Dr. drh. Hasim, DEA NIP 131578806
Tanggal Lulus :
ABSTRAK RHAMDANI. Evaluasi Kualitas Perangkat Lunak Berorientasi Objek. Dibimbing oleh WISNU ANANTA KUSUMA dan TOTO HARYANTO. Pengembangan perangkat lunak berorientasi objek membutuhkan pendekatan yang berbeda dengan pengembangan perangkat lunak terstruktur. Perbedaan tersebut terdapat pada tahap desain, implementasi, dan evaluasi kualitas perangkat lunak tersebut. Dengan demikian, dibutuhkan metrics yang berbeda dengan traditional metrics untuk melakukan evaluasi kualitas perangkat lunak tersebut. Chidamber & Kemerer (1994) mengajukan enam buah object oriented metrics. Keenam metrics tersebut memiliki sudut pandang yang terkait dengan faktor-faktor kualitas perangkat lunak. Dengan demikian, metrics tersebut dapat digunakan untuk melakukan evaluasi kualitas perangkat lunak berorientasi objek dari beberapa faktor kualitas yang terkait. Penelitian ini melakukan perhitungan object oriented metrics terhadap semua class pada perangkat lunak ERP. Selanjutnya, nilai metrics masing-masing class dibandingkan dengan nilai batas atas metrics tersebut. Dengan melakukan perbandingan tersebut, dapat diketahui class mana saja yang disarankan untuk diperiksa ulang dan/atau direvisi. Selain itu, penelitian ini juga melakukan perhitungan lebih lanjut untuk mengetahui nilai rata-rata masing-masing metrics pada perangkat lunak tersebut. Nilai rata-rata tersebut dibandingkan juga dengan nilai batas atas metrics sehingga dapat diketahui tinggi rendahnya nilai metrics secara keseluruhan. Dengan mengetahui tinggi rendahnya nilai metrics, dapat diketahui kualitas perangkat lunak tersebut. Dari penelitian yang dilakukan, ditemukan beberapa class yang disarankan untuk diperiksa ulang dan/atau direvisi. Selain itu, perangkat lunak ERP berkualitas baik dari segi usability, understandability, modifiability, dan testability. Akan tetapi, dari segi reusability, kualitas perangkat lunak ERP hanya dapat dikatakan moderat. Kata kunci: Object oriented metrics, Chidamber & Kemerer metrics, desain berorientasi objek, faktor kualitas.
RIWAYAT HIDUP Penulis dilahirkan di Jakarta pada tanggal 29 Mei 1986 dari pasangan Bapak M. Sadikin dan Ibu Ahyani. Penulis merupakan anak pertama dari dua bersaudara. Tahun 2004 penulis lulus dari SMU Negeri 91 Jakarta dan pada tahun yang sama lulus seleksi masuk IPB melalui jalur Undangan Saringan Masuk IPB (USMI). Penulis memilih Program Studi Ilmu Komputer, Departemen Ilmu Komputer, Fakultas Matematika dan Ilmu Pengetahuan Alam IPB. Pada tahun 2007, Penulis menjalankan praktek kerja lapangan di PT. Sigma Karya Sempurna (Balicamp) selama kurang lebih 5 bulan sebagai software tester untuk project Panin Business Internet Banking. Penulis juga pernah menjadi assisten praktikum mata kuliah Pengembangan Sistem Berorientasi Objek pada semester genap 2007/2008. Saat ini, penulis aktif sebagai anggota Java Campus Team di Departemen Ilmu Komputer IPB.
PRAKATA Alhamdulillah, puji dan syukur penulis panjatkan ke hadirat Allah SWT atas segala rahmat dan karunia-Nya sehingga penulis dapat menyelesaikan skripsi ini. Shalawat serta salam juga penulis sampaikan kepada junjungan kita Nabi Muhammad SAW beserta seluruh sahabat dan umatnya hingga akhir zaman. Penulis menyampaikan terima kasih kepada Bapak Wisnu Ananta Kusuma, S.T., M.T. selaku pembimbing I yang telah banyak membantu dan membimbing penulis selama proses penelitian dan penyusunan skripsi ini. Penulis juga menyampaikan terima kasih kepada Bapak Toto Haryanto, S.Kom. selaku pembimbing II yang telah memberikan saran dan masukan kepada penulis, serta Bapak Irman Hermadi, S.Kom., M.S. yang bersedia menjadi moderator dan dosen penguji dalam pelaksanaan seminar dan sidang. Terima kasih juga penulis sampaikan kepada: 1.
Ayahanda M. Sadikin dan Ibunda Ahyani yang senantiasa mendoakan dan memberikan dukungan selama penulis menjalankan studi di Institut Pertanian Bogor. Adik penulis Imam Suderajat yang senantiasa mendengarkan cerita-cerita penulis selama kuliah di IPB.
2.
Destarina Arghia (MSL 42) beserta keluarga yang selalu memberi dukungan dan semangat dalam mengerjakan skripsi ini.
3.
Teman-teman satu tim dalam pengerjaan perangkat lunak ERP Halida Ernita (ILKOM 41) dan Dian Indah Savitri (ILKOM 41).
4.
Roby Ikhsan & istri, Ifnu Bima, S.Kom. (ILKOM 38), dan Hadikusuma Wahab, S.Kom. (ILKOM 40 ) yang bersedia memberikan arahan dalam mengerjakan perangkat lunak ERP dan skripsi ini.
5.
Diomidis Spinellis sebagai pengembang tool CKJM yang bersedia memberikan arahan dan saran melalui email dalam menggunakan CKJM untuk mengolah data pada skripsi ini.
6.
Teman-teman satu kost Riza Mahendra, Hasan, Rizki Pebuardi, Hely Kurniwan yang rela membantu dalam pelaksanaan seminar dan sidang.
7.
Sahabat penulis, Ardian PrawiraYudha, yang memberikan fasilitas internet di rumahnya untuk digunakan penulis dalam menyelesaikan skripsi ini.
8.
Teman-teman ILKOM 41 lainnya yang telah banyak membantu penulis selama menjalani kuliah di IPB.
9.
Departemen Ilmu Komputer, staf, dan dosen yang telah begitu banyak membantu baik selama penelitian maupun pada masa perkuliahan.
Penulis juga mengucapkan terima kasih kepada semua pihak lainnya yang telah memberikan kontribusi yang besar selama pengerjaan penelitian ini yang tidak dapat disebutkan satu-persatu. Semoga penelitian ini dapat memberikan manfaat.
Bogor, Juli 2008
Rhamdani
v
DAFTAR ISI Halaman DAFTAR TABEL ............................................................................................................................ vi DAFTAR GAMBAR ....................................................................................................................... vi DAFTAR LAMPIRAN .................................................................................................................... vi PENDAHULUAN............................................................................................................................. 1 Latar Belakang............................................................................................................................. 1 Tujuan Penelitian ......................................................................................................................... 1 Ruang Lingkup Penelitian ........................................................................................................... 1 Manfaat Penelitian ....................................................................................................................... 1 TINJAUAN PUSTAKA.................................................................................................................... 1 Kualitas Perangkat Lunak ............................................................................................................ 1 Metrics ......................................................................................................................................... 2 Object Oriented Metrics .............................................................................................................. 3 Weighted Methods per Class (WMC).......................................................................................... 3 Depth of Inheritance Tree (DIT) ................................................................................................. 3 Number of Children (NOC) ......................................................................................................... 4 Coupling between Object (CBO) ................................................................................................. 4 Response for A Class (RFC) ........................................................................................................ 4 Lack of Cohesion in Methods (LCOM) ...................................................................................... 4 Cyclomatic Complexity (CC) ....................................................................................................... 5 METODE PENELITIAN .................................................................................................................. 5 Studi Literatur .............................................................................................................................. 6 Pengumpulan Data ....................................................................................................................... 6 Implementasi Perhitungan Metrics .............................................................................................. 6 Analisis Hasil Pengukuran Metrics ............................................................................................. 6 HASIL DAN PEMBAHASAN ......................................................................................................... 6 Pengumpulan Data ....................................................................................................................... 6 Implementasi Perhitungan Metrics .............................................................................................. 6 Analisis Hasil Perhitungan Metrics ............................................................................................. 7 1 Weighted Methods per Class (WMC) ............................................................................... 7 2 Depth of Inheritance Tree (DIT) ....................................................................................... 7 3 Number of Children (NOC) .............................................................................................. 7 4 Coupling Between Object Class (CBO) ............................................................................ 8 5 Response for A Class (RFC) ............................................................................................. 8 6 Lack of Cohesion in Methods (LCOM) ............................................................................. 9 7 Kualitas Perangkat Lunak ERP ....................................................................................... 10 KESIMPULAN DAN SARAN ....................................................................................................... 11 Kesimpulan ................................................................................................................................ 11 Saran .......................................................................................................................................... 11 DAFTAR PUSTAKA ..................................................................................................................... 11
vi
DAFTAR TABEL Halaman Tabel 1 Ringkasan statistik WMC pada perangkat lunak ERP. ........................................................ 7 Tabel 2 Ringkasan statistik DIT pada perangkat lunak ERP............................................................. 7 Tabel 3 Ringkasan statistik NOC pada perangkat lunak ERP. .......................................................... 8 Tabel 4 Ringkasan statistik CBO pada perangkat lunak ERP. .......................................................... 8 Tabel 5 Ringkasan statistik RFC pada perangkat lunak ERP. ........................................................... 9 Tabel 6 Ringkasan statistik nilai rasio LCOM pada perangkat lunak ERP. ..................................... 9 Tabel 7 Kategori metrics perangkat lunak ERP beserta pengaruhnya terhadap faktor kualitas ...... 10
DAFTAR GAMBAR Halaman Gambar 1 Faktor-faktor kualitas perangkat lunak (El-Ahmadi 2006)............................................... 2 Gambar 2 Hierarki metrics (Sarker 2005). ........................................................................................ 3 Gambar 3 Perhitungan CC dengan graph (Rosenberg 1998). ........................................................... 5 Gambar 4 Diagram metodologi penelitian. ....................................................................................... 5 Gambar 6 Histogram WMC pada perangkat lunak ERP. .................................................................. 7 Gambar 7 Histogram DIT pada perangkat lunak ERP. ..................................................................... 7 Gambar 8 Histogram NOC pada perangkat lunak ERP. ................................................................... 8 Gambar 9 Histogram CBO pada perangkat lunak ERP. .................................................................... 8 Gambar 10 Histogram RFC pada perangkat lunak ERP. .................................................................. 8 Gambar 11 Histogram LCOM pada perangkat lunak ERP. .............................................................. 9
DAFTAR LAMPIRAN Halaman Lampiran 1 Source Code class LoginCustomerController.............................................................. 13 Lampiran 2 Perhitungan Metrics pada Class LoginCustomerController ........................................ 14 Lampiran 3 Hasil Perhitungan Metrics pada semua Class project ERP.......................................... 17 Lampiran 4 Beberapa Class yang Disarankan Agar Diperiksa Ulang dan/atau Direvisi Terkait Dengan Nilai Metrics-nya ............................................................................................................... 22 Lampiran 5 Ringkasan Pengaruh Metrics Terhadap Faktor-Faktor Kualitas berdasarkan sudut pandang masing-masing metric. ...................................................................................................... 23
1
1
Menerapkan object oriented metrics untuk melakukan evaluasi perangkat lunak berorientasi objek.
Desain berorientasi objek merupakan suatu konsep yang banyak digunakan oleh pengembang perangkat lunak saat ini. Hal ini dikarenakan kemudahan yang ditawarkan di dalam desain berorientasi objek dari sisi pengembangan dan perawatannya. Dengan kata lain, desain berorientasi objek merupakan pendekatan yang efektif untuk membangun perangkat lunak yang flexibel.
2
Menganalisis efektivitas object oriented metrics yang digunakan.
Pengembangan berorientasi objek ternyata membutuhkan pendekatan yang berbeda dengan pengembangan struktural. Perbedaan tersebut terdapat pada tahap desain dan implementasinya. Perbedaan ini yang kemudian menimbulkan permasalahan dalam penggunaan metrics untuk mengevaluasi kualitas perangkat lunak berorientasi objek.
2 Perhitungan metrics dilakukan dengan bantuan tool Chidamber & Kemerer Java Metrics (CKJM).
PENDAHULUAN Latar Belakang
Traditional metrics seperti Cyclomatic Complexity (CC), yang digunakan untuk mengevaluasi desain terstruktur, ternyata tidak dapat digunakan begitu saja dalam desain berorientasi objek. Bahkan beberapa traditional metrics tidak dapat digunakan sama sekali dalam lingkungan berorientasi objek. Oleh karena itu, dibutuhkan metrics yang dapat merefleksikan desain berorientasi objek. Banyak penelitian yang mengajukan object oriented metrics. Salah satu penelitian tersebut dilakukan oleh Chidamber & Kemerer (1994). Chidamber & Kemerer, yang merupakan pelopor dalam penelitian object oriented metrics, mengajukan enam buah object oriented metrics. Metrics tersebut adalah Weighted Methods per Class (WMC), Depth of Inheritance Tree (DIT), Number of Children (NOC), Coupling Between Object (CBO), Response for A Class (RFC), dan Lack of Cohesion in Methods (LCOM). Keenam metrics tersebut dapat digunakan di dalam lingkungan berorientasi objek. Penelitian ini membahas penggunaan Chidamber & Kemerer object oriented metrics untuk mengevaluasi kualitas perangkat lunak berorientasi objek. Perangkat lunak yang digunakan adalah perangkat lunak ERP yang berorientasi objek yang dikembangkan oleh Ernita (2008). Tujuan Penelitian Tujuan dari penelitian ini adalah:
Ruang Lingkup Penelitian Ruang lingkup penelitian ini adalah : 1 Metrics yang digunakan adalah object oriented metrics yang diajukan oleh Chidamber & Kemerer (1994).
Manfaat Penelitian Penelitian ini diharapkan dapat melakukan estimasi kualitas perangkat lunak ERP yang berorientasi objek melalui faktor-faktor kualitas perangkat lunak. Selain itu, hasil perhitungan metrics dapat digunakan sebagai acuan untuk memperbaiki desain perangkat lunak ERP (Ernita 2008).
TINJAUAN PUSTAKA Kualitas Perangkat Lunak Kualitas perangkat lunak dapat memiliki banyak arti bergantung dari siapa yang memandangnya. Bila dilihat dari sudut pandang customer, perangkat lunak yang baik adalah perangkat lunak yang memuaskan kebutuhan customer. Dengan demikian, perangkat lunak tersebut dikatakan memiliki kualitas yang baik. Lain halnya jika dilihat dari sudut pandang pengembang. Pengembang perangkat lunak akan melihat produk perangkat lunak dari dalam perangkat lunak itu sendiri. Pengembang yang menggunakan pemikiran berorientasi objek memiliki tujuan pada terpenuhinya karakterisktik tertentu. Terpenuhinya karakteristik - karakteristik tersebut merupakan kualitas dari sudut pandang pengembang (El-Ahmadi 2006). Dengan kata lain, jika diinginkan kualitas perangkat lunak yang tinggi, haruslah ditentukan karakteristik apa saja yang diinginkan. Karakteristik tersebut berupa faktor-faktor kualitas. Faktor-faktor tersebut dapat dilihat pada gambar 1.
2
• Testability Menurut Jawadekar (2004), testability adalah tingkat usaha yang dibutuhkan untuk menguji perangkat lunak dalam proses quality assurance. • Availability
Gambar 1 Faktor-faktor kualitas perangkat lunak (El-Ahmadi 2006). Definisi faktor-faktor tersebut sebagai berikut: • Reliability Menurut Jawadekar (2004), reliability adalah tingkat ketepatan fungsi-fungsi perangkat lunak tanpa adanya kesalahan. • Reusability Reusability adalah tingkat kemampuan perangkat lunak atau bagian perangkat lunak untuk dapat digunakan ulang di lain tempat sebagai komponen yang reusable (Jawadekar 2004). • Usability Usability adalah tingkat usaha yang dibutuhkan untuk mempelajari, mengoperasikan, dan menggunakannya untuk tujuan yang diinginkan (Jawadekar 2004). • Maintainability Maintainability adalah tingkat usaha untuk mengetahui letak kesalahan dan memperbaikinya. Faktor ini dapat dipecah menjadi tiga subfaktor, masing-masing understandability, modifiability, dan testability (El-Ahmadi 2006). • Understandability Understandability terkait dengan peningkatan kompleksitas psikologis (SATC 1995). • Modifiability Modifiability dari segi flexibility adalah tingkat kemudahan sebuah sistem atau komponen agar dapat dimodifikasi untuk penggunaan dalam suatu aplikasi atau lingkungan (IEEE Std. 610.12 diacu dalam Barbacci 2004).
Availabillity adalah tingkat kemudahan suatu sistem atau komponen agar dapat dioperasikan dan diakses ketika ingin digunakan (IEEE Std. 610.12, diacu dalam Barbacci 2004). • Complexity El-Ahmadi (2006) menyatakan masih terdapat satu faktor lagi yang tidak secara langsung terkait dalam hierarki faktor pada gambar 1. Faktor tersebut adalah complexity. Complexity dibagi menjadi dua jenis, yaitu complexity of problem dan complexity of solution. Complexity of problem adalah jumlah sumber daya yang dibutuhkan untuk sebuah solusi yang optimal terhadap sebuah permasalahan. Complexity of solution terdiri dari time complexity dan space complexity. Time complexity terkait dengan sumber daya waktu sedangkan space complexity terkait dengan sumber daya memori (Fenton & Pfleeger 1997). Complexity berpengaruh pada understandability, modifiability, dan testability (El-Ahmadi 2006). Semua faktor kualitas tersebut dapat diukur secara kuantitatif menggunakan metrics. Penjelasan metrics dapat dilihat pada subbab selanjutnya. Metrics Sarker (2005) membagi metrics ke dalam dua kategori, yaitu project based metrics dan design based metrics. Project based metrics terdiri dari process, product, dan resources sedangkan design based metrics terdiri dari traditional metrics dan object oriented metrics. Gambar 2 memperlihatkan hierarki metrics tersebut. Process metrics, disebut juga management metrics, berhubungan dengan proses dalam mengembangkan sebuah sistem (Systa & Yu 1999). Process metrics biasanya digunakan untuk: • Membantu memprediksi ukuran akhir sebuah sistem, • Memprediksi tingkat usaha yang dibutuhkan dalam sebuah proyek,
3
• Dan menentukan apakah sebuah proyek sesuai dengan jadwal.
Object oriented metrics yang diajukan oleh Chidamber & Kemerer (1994) adalah: • Complexity metrics terdiri dari weighted methods per class (WMC). • Inheritance metrics terdiri dari depth of inheritance tree (DIT) dan number of children (NOC). • Communication metrics terdiri dari coupling between object (CBO), response for a class (RFC), dan lack of cohesion in method (LCOM).
Gambar 2 Hierarki metrics (Sarker 2005). Product metrics, disebut juga quality metrics, digunakan untuk mengontrol kualitas dari produk perangkat lunak. Metrics ini digunakan untuk perangkat lunak yang belum selesai dibuat agar dapat diprediksi properti dan kompleksitas hasil akhir perangkat lunak tersebut (Sarker 2005). Resources adalah entitas yang dibutuhkan dalam aktifitas proses pengembangan. Resources yang diukur adalah semua input dalam menghasilkan perangkat lunak (Sarker 2005). Pada sistem berorientasi objek, traditional metrics umumnya digunakan dalam ruang lingkup methods yang terdiri atas operasioperasi sebuah class. Beberapa contoh traditional metrics antara lain cyclomatic complexity (CC), source line of code (SLOC), dan comment percentage (CP). Object oriented metrics digunakan untuk merefleksikan perangkat lunak berorientasi objek. Beberapa contoh object oriented metrics yang telah diajukan antara lain Chidamber & Kemerer (CK) metrics, MOOD, dll. Penjelasan tentang object oriented metrics akan dijelaskan lebih detil pada subbab selanjutnya. Object Oriented Metrics Systa & Yu (1999) membagi object oriented metrics ke dalam tiga kategori, yaitu inheritance metrics, complexity metrics, dan communication metrics. Inheritance metrics mengukur hierarki pewarisan (inheritance), complexity metrics memperkirakan kompleksitas perangkat lunak, dan communication metrics mengukur pasangan (coupling) dan keterpaduan (cohesion) antar class.
Penjelasan mengenai definisi, sudut pandang, nilai batas atas, dan faktor-faktor kualitas apa saja yang terkait dengan masingmasing metrics dapat dilihat pada subbab selanjutnya. Weighted Methods per Class (WMC) Misalkan sebuah class C1 memiliki methods M1, M2,…, Mn dan c1, c2, …, cn adalah kompleksitas tiap method tersebut, maka:
Kompleksitas methods dapat didefinisikan oleh masing-masing pengembang (Chidamber & Kemerer 1994). Penelitian ini menggunakan cyclomatic complexity untuk perhitungan kompleksitas tiap method. Semakin banyak jumlah method sebuah class, semakin besar pula pengaruh pada class yang mewarisinya. Akibatnya, semakin besar upaya dan waktu yang dibutuhkan untuk maintenance dan testing (Chidamber & Kemerer 1994; Lindroos 2004). Selain itu, class yang memiliki banyak method yang kompleks berarti class tersebut semakin spesifik. Hal ini dapat membatasi kemungkinan reuse (Chidamber & Kemerer 1994; Systa & Yu 1999; Lindroos 2004). Dari kedua sudut pandang tersebut dapat disimpulkan bahwa WMC terkait dengan beberapa faktor-faktor kualitas, yaitu maintainability (testability), usability, dan reusability. RefactorIT menyarankan nilai batas atas WMC sebesar 50 untuk sebuah class. WMC yang didefiniskan RefactorIT menggunakan cyclomatic complexity dalam perhitungan kompleksitas tiap method. Depth of Inheritance Tree (DIT) Kedalaman sebuah class dalam hierarki pewarisan diukur oleh DIT. Apabila terdapat multiple inheritance, DIT didapat dari panjang
4
maksimum dari node ke root pada tree tersebut (Chidamber & Kemerer 1994). Penelitian ini menggunakan perangkat lunak berorientasi objek dengan bahasa pemrograman Java sehingga tidak ada multiple inheritance dalam implementasinya. Selain itu, setiap class merupakan turunan dari class Object sehingga DIT setiap class pada pemrogaman Java minimal 1. Class Object sendiri memiliki DIT = 0. RefactorIT menyarankan nilai batas atas DIT sebesar 5 untuk sebuah class. Semakin dalam sebuah class dalam sebuah hierarki pewarisan, semakin besar pula potensi penggunaan ulang method yang diwarisinya (Chidamber & Kemerer 1994; Systa & Yu 1999; Lindroos 2004). Selain itu, semakin dalam sebuah class dalam hierarki pewarisan maka semakin banyak method yang dimilikinya, baik method pada class itu sendiri maupun method yang diwarisinya. Hal ini mengakibatkan class tersebut semakin kompleks (Systa & Yu 1999 dalam Lindroos 2004). Kedua sudut pandang tersebut menjelaskan bahwa DIT berpengaruh pada faktor reusability dan complexity. El-Ahmadi (2006) menyatakan bahwa complexity mempengaruhi understandability, modifiability, dan testability. Jadi, secara keseluruhan DIT berpengaruh pada reusability, understandability, modifiability, dan testability. Number of Children (NOC) NOC adalah jumlah subclasses langsung yang mewarisi sebuah class pada hierarki class (Chidamber & Kemerer 1994). Semakin besar NOC maka semakin tinggi reusability. Hal ini dikarenakan pewarisan merupakan bentuk dari reuse. Selain itu, semakin besar NOC maka semakin besar upaya dan waktu untuk testing. (Chidamber & Kemerer 1994; SATC 1995; Lindroos 2004; Sarker 2005). Dari sudut pandang di atas, dapat disimpulkan bahwa NOC berpengaruh pada reusability dan testability. RefactorIT menyarankan nilai batas atas NOC sebesar 10 untuk sebuah class. Coupling between Object (CBO) CBO didefinisikan untuk sebuah class, yaitu banyaknya class yang terpasangkan oleh class yang diukur. Sebuah class A dikatakan terpasangkan dengan class B jika class A menggunakan method atau instance variable pada class B (Chidamber & Kemerer 1994).
CBO yang berlebihan merupakan perusak desain modular dan mengurangi reuse. Semakin tidak tergantung sebuah class dengan class lain maka semakin mudah class tersebut digunakan ulang untuk aplikasi lain (Lindroos 2004). Selain itu, class dengan CBO yang besar berarti semakin sensitif class tersebut terhadap perubahan pasangan class-nya. Hal ini mengakibatkan upaya untuk maintenance class tersebut semakin besar (Chidamber & Kemerer 1994; Systa & Yu 1999; Lindroos 2004). Dengan demikian, dapat disimpulkan bahwa CBO terkait dengan reusability dan maintainability. Nilai batas atas metric ini, sampai saat ini, belum dapat ditemukan. Akan tetapi, berdasarkan sudut pandang di atas dapat disimpulkan bahwa semakin kecil nilai CBO maka akan semakin baik kualitas desain class tersebut. Response for A Class (RFC) RFC adalah |RS|. RS didefinisikan sebagai berikut:
Dimana, adalah himpunan method yang dipanggil oleh method i dan adalah himpunan semua method yang ada di class tersebut (Chidamber & Kemerer 1994). RefactorIT menyarankan nilai batas atas RFC sebesar 50 untuk sebuah class walaupun RFC sebesar 100 untuk sebuah class masih bisa diterima. Semakin banyak method yang dapat dipanggil sebagai respon sebuah pesan, semakin besar juga upaya dan waktu untuk testing. Hal ini dikarenakan tester membutuhkan pemahaman yang tinggi terhadap class tersebut sebelum melakukan testing (Chidamber & Kemerer 1994; Lindroos 2004). Selain itu, semakin banyak method yang dapat dipanggil pada sebuah class, semakin besar kompleksitas class tersebut. Ini berarti semakin besar upaya pemeliharaan class tersebut (El-Ahmadi 2006). Sudut pandang di atas menyatakan bahwa RFC terkait dengan maintainability (understandability, modifiability, dan testability). Lack of Cohesion in Methods (LCOM) Misalkan sebuah class C1 dengan n buah methods M1, M2, …, Mn. Lalu {Ij} adalah himpunan instance variable yang digunakan oleh method Mi. Dengan demikian terdapat n buah himpunan I1, I2, …, In.
5
Kemudian P = {Ii, Ij | Ii ∩ Ij = Ø} dan Q = {Ii, Ij | Ii ∩ Ij ≠ Ø}. Jika semua n himpunan {I1}, {I2}, …, {In} adalah Ø maka P = Ø.
LCOM diharapkan rendah pada sebuah class (cohesiveness tinggi) karena menaikkan encapsulation. LCOM yang tinggi (cohesiveness rendah) menandakan sebuah class yang semestinya dipecah menjadi 2 atau lebih class. Selain itu, LCOM yang tinggi menandakan kompleksitas yang tinggi (Chidamber & Kemerer 1994; Lindroos 2004). Dari sudut pandang tersebut, dapat ditarik kesimpulan bahwa LCOM berpengaruh terhadap maintainability (understandability, modifiability, dan testability). Sampai saat ini, belum dapat ditemukan berapa besar nilai batas atas metric ini. Akan tetapi, dari definisi Chidamber dan Kemerer (1994), nilai LCOM bergantung pada jumlah methods pada sebuah class. Dengan demikian, terdapat nilai maksimum LCOM pada class tersebut, yaitu ketika |Q| = 0. Berdasarkan sudut pandang dan nilai maksimum LCOM dapat ditarik kesimpulan bahwa semakin kecil nilai aktual LCOM dibanding nilai maksimumnya, semakin baik cohesiveness class tersebut (Rosenberg, 1998). Cyclomatic Complexity (CC) CC, disebut juga McCabe cyclomatic complexity, digunakan untuk evaluasi kompleksitas sebuah method (Rosenberg et. al. 1997 diacu dalam Sarker 2005). CC adalah jumlah test cases yang dibutuhkan untuk menguji methods secara komprehensif (Rosenberg 1998). Perhitungannya dapat dilakukan dengan menggambarkan urutan program sebuah method menjadi graph dengan semua path yang mungkin terjadi. Kompleksitasnya dihitung dengan rumus:
Gambar 3 Perhitungan CC dengan graph (Rosenberg 1998). Ada cara lain untuk menghitung v(G). Andersson dan Vestergren (2004) merumuskannya sebagai berikut:
dimana, • P adalah jumlah predicate nodes yang ada dalam graph G. • Predicate node adalah sebuah node yang merepresentasikan pernyataan Boolean di dalam code sehingga terdapat dua buah outgoing edges. Method dengan CC yang rendah umumnya lebih baik (El-Ahmadi 2006). CC yang rendah berarti semakin baik dalam faktor testability dan understandability. Semakin kompleks sebuah method (CC tinggi) maka semakin tinggi testability dan understandability. Akan tetapi, method yang memiliki CC yang rendah bukan berarti method tersebut tidak kompleks. Hal ini mungkin berarti bahwa method tersebut melakukan message passing dalam implementasinya (SATC 1995).
METODE PENELITIAN
dimana, • v(G) adalah cylomatic complexity untuk graf G. • e adalah jumlah edges pada graf G, dan • n adalah jumlah nodes pada graf G. Gambar 3 menjelaskan bagaimana perhitungan CC pada sebuah graf.
Gambar 4 Diagram metodologi penelitian. Penelitian ini dilaksanakan dengan mengikuti tahap-tahap seperti pada gambar 4. Penelitian ini diawali dengan studi literatur,
6
pengumpulan data, kemudian melakukan implementasi perhitungan metrics, dan yang terakhir adalah analisis hasil perhitungan metrics.
2008). Perangkat lunak tersebut dikembangkan dengan bahasa pemrograman Java, terdiri dari 236 classes dan 39 jar file sebagai library.
Studi Literatur
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.
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 Data Perangkat lunak yang dipilih pada penelitian ini adalah perangkat lunak berbasis web, yaitu perangkat lunak ERP (Ernita
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.
7
Analisis Hasil Perhitungan Metrics Dari hasil perhitungan keenam metrics yang didapat pada tahap sebelumnya, dapat dilakukan analisis sebagai berikut:
Tabel 1 Ringkasan statistik WMC pada perangkat lunak ERP. Metric
Min
Max
Median
Stdev
WMC
0
81
9
15.9791
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.
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. 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 ratarata 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 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 perangkat lunak ERP.
pada
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
8
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.
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 8 Histogram NOC pada perangkat lunak ERP.
Gambar 9 Histogram CBO 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 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 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 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)
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,
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
9
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 cohesivenessnya, 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 cohesivenessnya menjadi lebih tinggi. Tabel 6 Ringkasan statistik nilai rasio LCOM pada perangkat lunak ERP. rasioLCOM Min
Max
Mean
Stdev
0.0000
0.9693
0.3191
0.3670
10
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 faktorfaktor 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 Faktor Kualitas No Metrics Kategori 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
↑
↑
↑
Keterangan : NA = Not Applicable
11
KESIMPULAN DAN SARAN Kesimpulan Enam buah metrics yang diajukan oleh Chidamber & Kemerer (1994) dapat digunakan untuk mengetahui kualitas perangkat lunak berorientasi objek dari beberapa faktor kualitas. Selain itu, metrics tersebut juga dapat digunakan untuk mengetahui class mana saja yang perlu diperiksa ulang dan/atau direvisi. Akan tetapi, LCOM tidak dapat digunakan langsung untuk mengetahui class mana saja yang perlu diperiksa ulang dan/atau direvisi. Berdasar pada hasil analisis, dapat disimpulkan bahwa perangkat lunak ERP (Ernita 2008) berkualitas baik dari segi usability, understandability, modifiability, dan testability. Akan tetapi, dari segi reusability, kualitas perangkat lunak ERP hanya dapat dikatakan moderat. Saran Penelitian selanjutnya disarankan menggunakan object oriented metrics lainnya sehingga kualitas perangkat lunak ERP dapat diketahui dari faktor-faktor kualitas lainnya. Selain itu, penelitian selanjutnya dapat pula mengimplementasikan Chidamber & Kemerer metrics untuk mengukur seberapa besar pengaruh penggunaan framework pada Java terhadap kualitas perangkat lunak tersebut.
DAFTAR PUSTAKA Andersson, Magnus & Patrik Vestergren. 2004. Object-Oriented Design Quality Metrics [Master Thesis]. Uppsala: Computing Science Department, Uppsala University. Barbacci, Mario R. 2004. Software Quality Atributes: Modifiability And Usability. Pittsburgh: Carnegie Mellon University. Chidamber, S dan Chris F. Kemerer. 1994. A Metrics Suite for Object Oriented Design. IEEE Transaction on Software Engineering, vol. 20 no. 6. El-Ahmadi, Abdellatif. 2006. Software Quality Metrics for Object Oriented Systems. Kongens Lyngby : Technical University of Denmark. Ernita, Halida. 2008. Pengembangan Enterprise Resource Planning (ERP) Untuk Perusahaan Ritel. Prosiding
Seminar Nasional Informatika 2008 ISSN: 1979-2328: 149-156. Fenton, Norman E. & Shari Lawrence Pfleeger. 1997. Software Metrics: A Rigourous and Practical Approach. Boston: PWS Publishing Company. Hogan, Jer. 1997. An Analysis of OO Software Metrics. Coventry: Department of Computer Science, University of Warwick. Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice. New Delhi: Tata McGraw-Hill. Lindroos, Jaana. 2004. Code and Design Metrics for Object-Oriented Systems. Helsinski: Department of Computer Science, University of Helsinsky. Rosenberg, Linda H. 1998. Applying and Interpreting Object Oriented Metrics. Utah: SATC NASA. Sarker, Muktamyee. 2005. An Overview of Object Oriented Design Metrics [Master Thesis]. Umea: Department of Computer Science, Umea University. SATC. 1995. Software Quality Metrics for Object Oriented System Environments. Grenbelt Maryland : NASA Goddard Space Flight Center. Spinellis, Diomidis. 2005. Tool Writing: A Forgotten Art?. IEEE Software. Systa, Tarja & Ping Yu. 1999. Using OO Metrics and Rigi to Evaluate Java Software. Tampere: Department of Computer Science, University of Tampere. Walpole, Ronald E. 1982. Pengantar Statistika. Jakarta: PT Gramedia Pustaka Utama.
LAMPIRAN
13
Lampiran 1 Source Code Class LoginCustomerController 1 package ilkom.erp.web.controller.customer; 2 3 import ilkom.erp.order.OrderDebitur; 4 import ilkom.erp.service.OrderService; 5 import ilkom.erp.web.util.MessageResourceUtil; 6 import ilkom.erp.web.util.SessionUtil; 7 import java.security.MessageDigest; 8 import java.security.NoSuchAlgorithmException; 9 import java.util.logging.Level; 10 import java.util.logging.Logger; 11 import javax.faces.application.FacesMessage; 12 13 public class LoginCustomerController { 14 private OrderService orderService; 15 private OrderDebitur debitur = new OrderDebitur(); 16 private String realPassword; 17 18 public String getRealPassword() { 19 return realPassword; 20 } 21 22 public void setRealPassword(String realPassword) { 23 this.realPassword = realPassword; 24 } 25 26 public void setOrderService(OrderService orderService) { 27 this.orderService = orderService; 28 } 29 30 public OrderDebitur getDebitur() { 31 return debitur; 32 } 33 34 public void setDebitur(OrderDebitur debitur) { 35 this.debitur = debitur; 36 } 37 38 public String login(){ 39 OrderDebitur orderDebiturDb = 40 orderService.getByNameOrderDebitur(debitur.getDebiturName()); 41 42 if (orderDebiturDb==null){ 43 MessageResourceUtil.addMessage(FacesMessage.SEVERITY_INFO, 44 Login.fail.signUpFirst", null); 45 clear(); 46 return "fail"; 47 }else if(!orderDebiturDb.getPassword().equals(md5(realPassword))){ 48 MessageResourceUtil.addMessage(FacesMessage.SEVERITY_INFO, 49 "Login.fail", null); 50 clear(); 51 return "fail"; 52 } 53 54 SessionUtil.setDebitur(orderDebiturDb); 55 return "login success"; 56 } 57 58 public String signUp(){ 59 clear(); 60 return "signup"; 61 } 62 63 private void clear() { 64 debitur = new OrderDebitur(); 65 } 66 67 public static String md5(String s){ 68 try { 69 MessageDigest md = MessageDigest.getInstance("MD5"); 70 md.update(s.getBytes()); 71 return new String(md.digest());
14
Lanjutan 72 } catch (NoSuchAlgorithmException ex) { 73 74 Logger.getLogger(LoginCustomerController.class.getName()).log(Level.SEVERE, 75 null, ex); 76 } 77 return null; 78 } 79 }
Lampiran 2 Perhitungan Metrics pada Class LoginCustomerController •
WMC
Class LoginCustomerController memiliki 10 buah method, yaitu getRealPassword(), setRealPassword(), setOrderService(), getDebitur(), setDebitur(), login(), signup(), clear(), md5(). Akan tetapi, masih terdapat satu buah method yang secara implisit selalu dimiliki oleh sebuah class di Java, yaitu method constructor. Kalau tidak didefinisikan oleh pembuat class, konstruktor tersebut disebut default constructor. Default constructor ini memanggil method super(), yaitu konstruktor dari superclass-nya. Dengan demikian, class LoginCustomerController memiliki 7 buah method. CC untuk setiap method sebagai berikut: Constructor: CC1 = P + 1 = 0 + 1 =1 getRealPassword(): CC2 = P + 1 = 0 + 1 =1 setRealPassword(): CC3 = P + 1 = 0 + 1 =1 setOrderService(): CC4 = P + 1 = 0 + 1 = 1 getDebitur(): CC5 = P + 1 = 0 + 1 = 1 setDebitur(): CC6 = P + 1 = 0 + 1 = 1 login(): CC7 = P + 1 = 2 + 1 = 3 signup(): CC8 = P + 1 = 0 + 1 = 1 clear(): CC9 = P + 1 = 0 + 1 = 1 md5():CC10 = P + 1 = 1 + 1 = 2 Dari CC setiap method didapat :
•
DIT
Class LoginCustomerController tidak melakukan extends (mewarisi) class lain secara eksplisit. Akan tetapi, setiap class di Java mewarisi class Object dan class Object adalah root pada hierarki pewarisan class di Java. Dengan demikian,
•
NOC
Setelah menelusuri semua class pada data, tidak terdapat satu pun class yang mewarisi class LoginCustomerController. Dengan demikian,
15
Lanjutan •
CBO
Class LoginCustomerController memiliki instance variable dari class OrderService (orderService) dan OrderDebitur (debitur). Selain itu, method login() memanggil static method addMessage() dari class MessageResourceUtil dan static method setDebitur() dari class SessionUtil. Dengan demikian,
•
RFC
Semua method yang terdapat pada class LoginCustomerController dan method yang dipanggil di dalamnya sebagai berikut: •
Constructor memanggil Object.super().
•
getRealPassword() tidak memanggil method lain.
•
setRealPassword() tidak memanggil method lain.
•
setOrderService() tidak memanggil method lain.
•
getDebitur() tidak memanggil method lain.
•
setDebitur() tidak memanggil method lain.
•
login() memanggil OrderService.getByNameOrderDebitur(), OrderDebitur.getDebiturName(), MessageResourceUtil.addMessage(), this.clear(), OrderDebitur.getPassword(), String.equals(), this.md5(), dan SessionUtil.setDebitur().
•
signUp() memanggil this.clear().
•
clear() memanggil OrderDebitur.this().
•
md5() memanggil MessageDigest.getInstance(), MessageDigest.update(), String.getBytes(), String.this(), MessageDigest.digest(), Logger.getLogger(), LoginCustomerController.class.getName(), Logger.log().
Selanjutnya RS dapat ditentukan sebagai berikut :
= {this(), this.getRealPassword(), this.setRealPassword(), this.setOrderService(), this.getDebitur(), this.setDebitur(), this.login(), this.signUp(), this.clear(), this.md5(), Object.super(), OrderService.getByNameOrderDebitur(), OrderDebitur.getDebiturName(), MessageResourceUtil.addMessage(), OrderDebitur.getPassword(), String.equals(), SessionUtil.setDebitur(), OrderDebitur.this(), MessageDigest.getInstance(), MessageDigest.update(), String.this(), String.getBytes(), MessageDigest.digest(), Logger.getLogger(), LoginCustomerController.class.getName(), Logger.log()} Dengan demikian,
•
LCOM
Class LoginCustomerController memiliki dua buah instance variable, yaitu orderService dan debitur sehingga, Iconstructor = I1 = Ø IgetRealPassword = I2 ={realPassword} IsetRealPassword = I3 ={realPassword} IsetOrderService = I4 = {orderService}
16
Lanjutan IgetDebitur = I5 = {debitur} IsetDebitur = I6 = { debitur} Ilogin = I7 = {orderService, debitur, realPassword} IsignUp = I8 = {debitur} Iclear = I9 = {debitur} Imd5 = I10 = Ø Kemudian, dari hasil di atas dapat ditentukan himpunan P dan Q sebagai berikut: P = { I1 ∩ I2, I1 ∩ I3, I1 ∩ I4, I1 ∩ I5, I1 ∩ I6, I1 ∩ I7, I1 ∩ I8, I1 ∩ I9, I1 ∩ I10, I2 ∩ I4, I2 ∩ I5, I2 ∩ I6, I2 ∩ I8, I2 ∩ I9, I2 ∩ I10, I3 ∩ I4, I3 ∩ I5, I3 ∩ I6, I3 ∩ I8, I3 ∩ I9, I3 ∩ I10, I4 ∩ I5, I4 ∩ I6, I4 ∩ I8, I4 ∩ I9, I4 ∩ I10, I5 ∩ I10, I6 ∩ I10, I7 ∩ I10, I8 ∩ I10, I9 ∩ I10} Q = { I2 ∩ I3, I2 ∩ I7, I3 ∩ I7, I4 ∩ I7, I5 ∩ I6, I5 ∩ I7, I5 ∩ I8, I5 ∩ I9, I6 ∩ I7, I6 ∩ I8, I6 ∩ I9, I7 ∩ I8, I7 ∩ I9, I8 ∩ I9} Karena |P| >|Q|, dengan demikian
17
Lampiran 3 Hasil Perhitungan Metrics pada Semua Class Project ERP No.
Class
WMC
DIT
NOC
CBO
RFC
LCOM MaxLCOM RasioLCOM
1 ilkom.erp.web.controller.admin.AccPeriodListController
7
1
0
4
15
6
21
0.2857
2 ilkom.erp.purchase.dao.PurchaseDemandDetailDao
4
1
0
1
4
0
6
0.0000
3 ilkom.erp.purchase.dao.hibernate.PurchaseSupplierDaoHibernate
14
3
0
7
27
0
45
0.0000
4 ilkom.erp.order.dao.hibernate.OrderCartDaoHibernate
12
3
0
9
30
0
21
0.0000
5
1
0
1
9
6
10
0.6000
6 ilkom.erp.order.OrderCartDetail
21
1
0
4
22
190
210
0.9048
7 ilkom.erp.web.controller.admin.AdminUserFormController
5 ilkom.erp.web.controller.deliveryOrder.DeliverOrderCartController$OrderCartWrapper
16
1
0
4
31
18
78
0.2308
8 ilkom.erp.order.dao.hibernate.OrderShippingTypeDaoHibernate
6
3
0
5
17
0
10
0.0000
9 ilkom.erp.web.controller.accountReceivable.ARInvoiceController
11
1
0
3
17
18
36
0.5000
10 ilkom.erp.web.controller.accountPayable.APMonthEndController
19
1
0
9
58
82
136
0.6029
6
3
0
9
21
0
10
0.0000
11 ilkom.erp.accountReceivable.dao.hibernate.AccountReceivableMonthEndDaoHibernate 12 ilkom.erp.order.dao.OrderShippingTypeDao
4
1
0
1
4
0
6
0.0000
13 ilkom.erp.purchase.PurchaseOrderDetail
21
1
0
4
22
190
210
0.9048
14 ilkom.erp.web.controller.inventory.ListInventoryController
15
1
0
4
28
9
45
0.2000
15 ilkom.erp.service.AccountPayableService
25
1
0
5
25
0
300
0.0000
5
1
0
1
5
0
10
0.0000
15
1
0
3
21
0
55
0.0000
6
1
0
1
6
0
15
0.0000
19 ilkom.erp.service.PurchaseService
57
1
0
12
57
0
1596
0.0000
20 ilkom.erp.generalLedger.GLMonthEnd
39
1
0
5
40
703
741
0.9487
21 ilkom.erp.purchase.dao.hibernate.PurchaseDemandDetailDaoHibernate
6
3
0
8
20
0
10
0.0000
22 ilkom.erp.order.dao.OrderCartDao
6
1
0
1
6
0
15
0.0000
23 ilkom.erp.purchase.dao.PurchaseDemandDao
6
1
0
2
6
0
15
0.0000
24 ilkom.erp.inventory.InventoryGoodReceiveDetail
23
1
0
5
24
231
253
0.9130
25 ilkom.erp.generalLedger.dao.GLMonthEndDao
4
1
0
1
4
0
6
0.0000 0.0000
16 ilkom.erp.purchase.dao.PurchaseRequisitionDao 17 ilkom.erp.web.util.SessionUtil 18 ilkom.erp.admin.dao.AdminUserDao
26 ilkom.erp.generalLedger.dao.hibernate.GeneralLedgerDaoHibernate
6
3
0
5
17
0
10
31
1
0
7
31
0
465
0.0000
28 ilkom.erp.web.validator.EmailValidator
3
1
0
0
10
1
1
0.0000
29 ilkom.erp.web.controller.purchase.ListSupplierController$PurchaseSupplierWrapper
5
1
0
3
8
2
10
0.2000
30 ilkom.erp.inventory.dao.InventoryProductCategoryDao
4
1
0
1
4
0
6
0.0000 0.0000
27 ilkom.erp.service.OrderService
31 ilkom.erp.purchase.dao.PurchaseMonthendtrxDao
4
1
0
1
4
0
6
32 ilkom.erp.web.controller.accountReceivable.AddReceiptController
62
1
0
12
95
368
630
0.5841
33 ilkom.erp.inventory.InventoryProductCategory
15
1
0
1
17
87
105
0.8286
34 ilkom.erp.web.controller.admin.AdminUOMController
7
1
0
4
15
6
21
0.2857
35 ilkom.erp.purchase.dao.hibernate.PurchaseRequisitionDetailDaoHibernate
7
3
0
8
22
0
15
0.0000
36 ilkom.erp.web.util.MessageResourceUtil
4
1
0
0
18
0
6
0.0000
11
1
0
1
12
45
55
0.8182
5
1
0
1
8
0
10
0.0000
39 ilkom.erp.inventory.InventoryGoodReceive
29
1
0
3
31
374
406
0.9212
40 ilkom.erp.accountReceivable.AccountReceivableReceipt
25
1
0
2
28
246
276
0.8913
7
1
0
1
17
7
15
0.4667
22
1
0
4
37
56
136
0.4118
4
1
0
1
4
0
6
0.0000
37 ilkom.erp.order.OrderShippingType 38 ilkom.erp.web.controller.customer.InventoryItemController
41 ilkom.erp.web.controller.customer.FormOrderCartController$OrderCartDetailWrapper 42 ilkom.erp.web.controller.admin.AdminUOMConvFormController 43 ilkom.erp.inventory.dao.InventoryProductBrandDao 44 ilkom.erp.web.controller.admin.AdminVehicleController
7
1
0
4
15
6
21
0.2857
45 ilkom.erp.web.controller.generalLedger.GLAccountAddController
10
1
0
3
15
0
36
0.0000
46 ilkom.erp.purchase.PurchaseDemand
31
1
0
4
34
399
435
0.9172
47 ilkom.erp.admin.dao.hibernate.AdminUserDaoHibernate
9
3
0
5
25
0
21
0.0000
48 ilkom.erp.admin.dao.AdminUOMDao
5
1
0
1
5
0
10
0.0000
49 ilkom.erp.accountReceivable.dao.hibernate.AccountReceivableReceiptDaoHibernate
7
3
0
6
21
0
15
0.0000
50 ilkom.erp.web.controller.purchase.ApproveListRFQSupplierController$PurchaseSupplyRFQWrapper
7
1
0
2
15
7
15
0.4667
18
Lanjutan No.
Class
51 ilkom.erp.web.controller.inventory.FormInventoryController 52 ilkom.erp.web.controller.accountReceivable.AddReceiptController$ReceiptDetailWrapper 53 ilkom.erp.order.dao.hibernate.OrderPaymentTypeDaoHibernate
WMC
DIT
NOC
CBO
RFC LCOM MaxLCOM RasioLCOM
46
1
0
10
77
324
496
0.6532
5
1
0
1
11
6
10
0.6000
6
3
0
5
17
0
10
0.0000
54 ilkom.erp.purchase.PurchaseMonthendtrx
37
1
0
4
38
630
666
0.9459
55 ilkom.erp.purchase.PurchaseSupplyRFQDetail
28
1
0
4
30
264
300
0.8800
6
1
0
3
6
0
15
0.0000
57 ilkom.erp.web.controller.accountPayable.APPaymentController
11
1
0
3
17
18
36
0.5000
58 ilkom.erp.web.util.UserAuthenticatinPhaseListener
24
1
0
4
20
0
10
0.0000
59 ilkom.erp.web.controller.purchase.ApproveListRFQSupplierController
11
1
0
7
27
14
28
0.5000
60 ilkom.erp.accountReceivable.dao.AccountReceivableReceiptDao
5
1
0
1
5
0
10
0.0000
61 ilkom.erp.order.dao.OrderPaymentTypeDao
4
1
0
1
4
0
6
0.0000
56 ilkom.erp.purchase.dao.PurchaseSupplyRFQDetailDao
62 ilkom.erp.web.controller.generalLedger.GLJournalController
9
1
0
3
15
11
21
0.5238
63 ilkom.erp.accountPayable.AccountPayableInvoice
31
1
0
3
34
399
435
0.9172
64 ilkom.erp.admin.AdminVehicle
27
1
0
4
29
297
325
0.9138
65 ilkom.erp.purchase.PurchaseRequisition
25
1
0
2
28
246
276
0.8913
66 ilkom.erp.admin.AdminUOM
15
1
0
1
17
75
91
0.8242
5
1
0
1
5
0
10
0.0000
25
1
0
6
26
276
300
0.9200
6
3
0
7
20
0
10
0.0000
14
1
0
4
21
21
55
0.3818
71 ilkom.erp.accountPayable.dao.AccountPayableInvoiceDao
6
1
0
1
6
0
15
0.0000
72 ilkom.erp.web.controller.purchase.RFQSupplierController
20
1
0
6
35
25
55
0.4545
73 ilkom.erp.purchase.dao.hibernate.PurchaseSupplyRFQDaoHibernate
17
3
0
10
39
0
55
0.0000
74 ilkom.erp.inventory.InventoryProductBrand
15
1
0
1
17
87
105
0.8286
5
1
0
1
10
6
15
0.4000
53
1
0
2
55 1318
1378
0.9565
9
1
0
11
45
11
21
0.5238
78 ilkom.erp.admin.AdminAccPeriod
17
1
0
1
19
102
120
0.8500
79 ilkom.erp.accountPayable.AccountPayableMonthEnd
37
1
0
5
38
630
666
0.9459
80 ilkom.erp.web.controller.customer.EditPasswordController
17
1
0
5
23
39
91
0.4286
81 ilkom.erp.accountPayable.dao.AccountPayablePaymentDao
6
1
0
1
6
0
15
0.0000
82 ilkom.erp.order.dao.OrderDeliveryDao
4
1
0
1
4
0
6
0.0000
83 ilkom.erp.purchase.PurchaseSupplier
49
1
0
3
68
779
1035
0.7527
84 ilkom.erp.accountReceivable.dao.AccountReceivableMonthEndDao
4
1
0
1
4
0
6
0.0000
85 ilkom.erp.generalLedger.dao.GLJournalDao
5
1
0
1
5
0
10
0.0000
86 ilkom.erp.web.controller.admin.AdminUserController
7
1
0
4
15
6
21
0.2857 0.0000
67 ilkom.erp.order.dao.OrderDebiturDao 68 ilkom.erp.accountPayable.AccountPayableInvoiceDetail 69 ilkom.erp.inventory.dao.hibernate.InventoryGoodReceiveDaoHibernate 70 ilkom.erp.web.controller.customer.SignUpController
75 ilkom.erp.web.controller.inventory.GoodReceiveController$GoodReceiveDetailWrapper 76 ilkom.erp.order.OrderDebitur 77 ilkom.erp.web.controller.purchase.PurchaseDemandController
87 ilkom.erp.admin.dao.AdminModulDao
5
1
0
1
5
0
10
14
1
0
4
28
11
55
0.2000
5
1
0
1
5
0
10
0.0000
44
1
0
8
70
74
276
0.2681
8
3
0
6
22
0
21
0.0000
14
1
0
3
28
7
55
0.1273
7
3
0
5
19
0
15
0.0000
94 ilkom.erp.order.OrderDelivery
23
1
0
4
25
227
253
0.8972
95 ilkom.erp.purchase.PurchaseDemandDetail
21
1
0
4
22
190
210
0.9048
8
3
0
9
24
0
21
0.0000
31
1
0
1
34
399
435
0.9172
98 ilkom.erp.accountPayable.dao.hibernate.AccountPayableInvoiceDaoHibernate
8
3
0
7
23
0
21
0.0000
99 ilkom.erp.admin.dao.hibernate.AdminModulDaoHibernate
7
3
0
5
21
0
15
0.0000
100 ilkom.erp.accountReceivable.dao.AccountReceivableReceiptDetailDao
4
1
0
1
4
0
6
0.0000
88 ilkom.erp.web.controller.purchase.ListRFQController 89 ilkom.erp.inventory.dao.InventoryItemDao 90 ilkom.erp.web.controller.generalLedger.GLJournalDetailController 91 ilkom.erp.accountPayable.dao.hibernate.AccountPayablePaymentDaoHibernate 92 ilkom.erp.web.controller.deliveryOrder.ListOrderCartController 93 ilkom.erp.admin.dao.hibernate.AdminUOMDaoHibernate
96 ilkom.erp.accountPayable.dao.hibernate.AccountPayableInvoiceDetailDaoHibernate 97 ilkom.erp.generalLedger.GLJournal
19
Lanjutan No.
Class
WMC
DIT
NOC
CBO
RFC LCOM MaxLCOM RasioLCOM
101 ilkom.erp.web.controller.customer.FormOrderCartController
54
1
0
11
104
385
595
0.6471
102 ilkom.erp.web.controller.LoginController
17
1
0
6
18
3
21
0.1429 0.0000
103 ilkom.erp.web.controller.purchase.ListSupplierController$1
0
1
0
0
0
0
0
21
1
0
2
23
168
190
0.8842
105 ilkom.erp.web.controller.admin.AdminCompanyController
7
1
0
4
15
6
21
0.2857
106 ilkom.erp.web.controller.inventory.GoodReceiveController
104 ilkom.erp.admin.AdminPage
60
1
0
11
87
288
496
0.5806
107 ilkom.erp.admin.dao.AdminGroupDao
5
1
0
1
5
0
10
0.0000
108 ilkom.erp.purchase.PurchaseRFQPrice
11
1
0
2
12
45
55
0.8182
109 ilkom.erp.admin.AdminModulPeriod
33
1
0
1
34
496
528
0.9394
6
3
0
9
21
0
10
0.0000
110 ilkom.erp.generalLedger.dao.hibernate.GLMonthEndDaoHibernate 111 ilkom.erp.service.impl.OrderServiceImpl
46
1
0
15
78
787
1035
0.7604
112 ilkom.erp.web.controller.deliveryOrder.DeliveredCartsController
11
1
0
3
18
0
36
0.0000
113 ilkom.erp.web.controller.customer.ConfirmShippingController
15
1
0
3
24
19
55
0.3455
114 ilkom.erp.inventory.dao.hibernate.InventoryMonthenditemDaoHibernate
6
3
0
6
18
0
10
0.0000
115 ilkom.erp.accountPayable.dao.hibernate.AccountPayableMonthEndDaoHibernate
6
3
0
9
20
0
10
0.0000
116 ilkom.erp.web.util.MessagesNotJsfApprouchListener
6
1
0
0
19
0
6
0.0000
117 ilkom.erp.web.controller.purchase.PurchaseRequisitionController$PurchaseRequisitionDetailWrapper
5
1
0
1
10
6
10
0.6000
10
1
0
3
15
0
36
0.0000
119 ilkom.erp.inventory.dao.InventoryGoodReceiveDetailDao
4
1
0
1
4
0
6
0.0000
120 ilkom.erp.inventory.dao.InventoryGoodReceiveDao
4
1
0
1
4
0
6
0.0000
121 ilkom.erp.purchase.dao.hibernate.PurchaseSupplyRFQDetailDaoHibernate
8
3
0
9
25
0
21
0.0000
122 ilkom.erp.generalLedger.dao.hibernate.GLJournalDetailDaoHibernate
6
3
0
7
19
0
10
0.0000
123 ilkom.erp.web.controller.admin.AdminVehicleFormController
24
1
0
6
42
89
171
0.5205
124 ilkom.erp.purchase.dao.hibernate.PurchaseDemandDaoHibernate
10
3
0
8
30
0
21
0.0000
125 ilkom.erp.accountReceivable.AccountReceivableInvoice
27
1
0
3
30
293
325
0.9015
126 ilkom.erp.service.impl.AccountPayableServiceImpl
38
1
0
15
104
392
630
0.6222
127 ilkom.erp.web.controller.purchase.ListPurchaseDemandController
13
1
0
4
20
27
55
0.4909
128 ilkom.erp.admin.AdminCompany
39
1
0
1
41
663
703
0.9431
129 ilkom.erp.accountPayable.AccountPayablePaymentDetail
21
1
0
5
22
190
210
0.9048
130 ilkom.erp.web.util.TextUtil
3
1
0
0
6
0
1
0.0000
131 ilkom.erp.admin.AdminUser
23
1
0
1
25
207
231
0.8961
132 ilkom.erp.web.controller.admin.AdminUOMFormController
10
1
0
3
15
0
36
0.0000 0.0000
118 ilkom.erp.web.controller.admin.AdminCompanyFormController
133 ilkom.erp.purchase.dao.hibernate.PurchaseRequisitionDaoHibernate
9
3
0
6
26
0
15
134 ilkom.erp.service.AdminService
45
1
0
10
45
0
990
0.0000
135 ilkom.erp.web.controller.admin.AccPeriodController
10
1
0
3
15
0
36
0.0000
136 ilkom.erp.web.controller.purchase.RFQController
68
1
0
11
95
266
496
0.5363
4
1
0
1
4
0
6
0.0000
137 ilkom.erp.accountReceivable.dao.AccountReceivableInvoiceDetailDao 138 ilkom.erp.web.controller.generalLedger.GLPostJournalController 139 ilkom.erp.accountReceivable.AccountReceivableInvoiceDetail 140 ilkom.erp.accountReceivable.dao.AccountReceivableInvoiceDao
7
1
0
4
16
6
21
0.2857
25
1
0
5
26
276
300
0.9200 0.0000
5
1
0
1
5
0
10
141 ilkom.erp.web.controller.purchase.PurchaseOrderController
11
1
0
12
47
26
36
0.7222
142 ilkom.erp.web.controller.deliveryOrder.DeliverOrderCartController
31
1
0
6
52
192
300
0.6400
143 ilkom.erp.admin.AdminGroup
17
1
0
0
20
98
120
0.8167
144 ilkom.erp.purchase.PurchaseRequisitionDetail
19
1
0
4
20
153
171
0.8947
6
3
0
8
20
0
10
0.0000
146 ilkom.erp.web.controller.accountPayable.AddInvoiceController
77
1
0
15
119
723
1035
0.6986
147 ilkom.erp.web.controller.accountPayable.APInvoiceController
9
1
0
3
15
5
21
0.2381
148 ilkom.erp.admin.dao.hibernate.AdminGroupDaoHibernate
7
3
0
4
20
0
15
0.0000
149 ilkom.erp.order.dao.OrderMonthendtrxDao
4
1
0
1
4
0
6
0.0000
33
1
0
11
56
354
528
0.6705
145 ilkom.erp.inventory.dao.hibernate.InventoryGoodReceiveDetailDaoHibernate
150 ilkom.erp.service.impl.AccountReceivableServiceImpl
20
Lanjutan No.
Class
151 ilkom.erp.inventory.InventoryMonthenditem 152 ilkom.erp.inventory.dao.InventoryMonthenditemDao 153 ilkom.erp.service.impl.AdminServiceImpl
WMC
DIT
NOC
CBO
RFC LCOM MaxLCOM RasioLCOM
23
1
0
2
24
231
253
0.9130
4
1
0
1
4
0
6
0.0000
66
1
0
21
111 1779
2145
0.8294
154 ilkom.erp.generalLedger.dao.hibernate.GLJournalDaoHibernate
7
3
0
5
20
0
15
0.0000
155 ilkom.erp.purchase.dao.PurchaseSupplierDao
9
1
0
3
9
0
36
0.0000
156 ilkom.erp.inventory.dao.hibernate.InventoryProductBrandDaoHibernate
6
3
0
5
20
0
10
0.0000
157 ilkom.erp.admin.dao.AdminVehicleDao
5
1
0
1
5
0
10
0.0000
158 ilkom.erp.generalLedger.GeneralLedgerAccount
17
1
0
1
19
102
120
0.8500
159 ilkom.erp.web.controller.purchase.ListPurchaseOrderController
11
1
0
3
18
14
36
0.3889
160 ilkom.erp.service.InventoryService
25
1
0
6
25
0
300
0.0000
161 ilkom.erp.web.controller.admin.AdminUOMConvertionController
7
1
0
4
15
6
21
0.2857
162 ilkom.erp.accountPayable.dao.hibernate.AccountPayablePaymentDetailDaoHibernate
7
3
0
4
17
0
15
0.0000
163 ilkom.erp.order.dao.hibernate.OrderDeliveryDaoHibernate
6
3
0
8
20
0
10
0.0000
164 ilkom.erp.web.controller.purchase.RFQController$PurchaseRFQDetailWrapper
5
1
0
1
10
6
15
0.4000
165 ilkom.erp.purchase.dao.hibernate.PurchaseMonthendtrxDaoHibernate
6
3
0
8
20
0
10
0.0000
63
1
0
12
98
368
630
0.5841
4
1
0
1
4
0
6
0.0000
166 ilkom.erp.web.controller.accountPayable.AddPaymentController 167 ilkom.erp.admin.dao.AdminAccPeriodDao
15
1
0
6
30
5
45
0.1111
169 ilkom.erp.accountReceivable.dao.hibernate.AccountReceivableReceiptDetailDaoHibernate
168 ilkom.erp.web.controller.purchase.ListSupplierController
6
3
0
8
19
0
10
0.0000
170 ilkom.erp.admin.dao.hibernate.AdminUOMConvertionDaoHibernate
7
3
0
6
21
0
15
0.0000
171 ilkom.erp.service.AccountReceivableService
22
1
0
5
22
0
231
0.0000
172 ilkom.erp.purchase.Address
15
1
0
0
16
91
105
0.8667
5
1
0
2
8
2
10
0.2000
5
0.0000
173 ilkom.erp.web.controller.customer.CompanyController 174 ilkom.erp.purchase.dao.PurchaseRequisitionDetailDao
5
1
0
1
0
10
175 ilkom.erp.service.impl.PurchaseServiceImpl
81
1
0
25
153 2588
3160
0.8190
176 ilkom.erp.web.controller.customer.LoginCustomerController
13
1
0
4
26
45
0.3778 0.0000
177 ilkom.erp.purchase.dao.PurchaseOrderDao
17
5
1
0
1
5
0
10
21
1
0
2
23
168
190
0.8842
179 ilkom.erp.admin.dao.AdminUOMConvertionDao
5
1
0
1
5
0
10
0.0000
180 ilkom.erp.purchase.dao.hibernate.PurchaseOrderDaoHibernate
9
3
0
8
28
0
15
0.0000
181 ilkom.erp.web.controller.generalLedger.GLJournalDetailController$GLJournalDetailWrapper
5
1
0
1
10
6
10
0.6000
182 ilkom.erp.admin.dao.hibernate.AdminModulPeriodDaoHibernate
6
3
0
5
17
0
10
0.0000
183 ilkom.erp.inventory.dao.hibernate.InventoryItemDaoHibernate
7
3
0
9
23
0
15
0.0000
184 ilkom.erp.accountReceivable.dao.hibernate.AccountReceivableInvoiceDetailDaoHibernate
6
3
0
9
21
0
10
0.0000
185 ilkom.erp.web.controller.purchase.ListPurchaseRequisitionController
12
1
0
3
23
11
45
0.2444
186 ilkom.erp.order.OrderCart
47
1
0
5
49 1031
1081
0.9537
7
3
0
5
19
15
0.0000
188 ilkom.erp.service.impl.InventoryServiceImpl
38
1
0
13
64
511
703
0.7269
189 ilkom.erp.accountPayable.AccountPayablePayment
25
1
0
2
28
246
276
0.8913
190 ilkom.erp.web.controller.inventory.ListGoodReceiveController
9
1
0
3
15
5
21
0.2381
191 ilkom.erp.order.dao.hibernate.OrderCartDetailDaoHibernate
6
3
0
5
17
0
10
0.0000
192 ilkom.erp.purchase.dao.PurchaseOrderDetailDao
4
1
0
1
4
0
6
0.0000
193 ilkom.erp.accountPayable.dao.AccountPayableInvoiceDetailDao
6
1
0
1
6
0
15
0.0000
39
1
0
5
40
703
741
0.9487
9
1
0
3
15
5
21
0.2381
39
1
0
5
40
703
741
0.9487
6
3
0
5
17
0
10
0.0000
178 ilkom.erp.admin.AdminUOMConvertion
187 ilkom.erp.admin.dao.hibernate.AdminPageDaoHibernate
194 ilkom.erp.accountReceivable.AccountReceivableMonthEnd 195 ilkom.erp.web.controller.accountPayable.listInvoiceController 196 ilkom.erp.order.OrderMonthendtrx 197 ilkom.erp.admin.dao.hibernate.AdminAccPeriodDaoHibernate 198 ilkom.erp.web.controller.accountPayable.AddPaymentController$PaymentDetailWrapper
0
5
1
0
1
11
2
10
0.2000
199 ilkom.erp.generalLedger.GLJournalDetail
19
1
0
3
20
153
171
0.8947
200 ilkom.erp.accountReceivable.AccountReceivableReceiptDetail
19
1
0
4
20
153
171
0.8947
21
Lanjutan No.
Class
201 ilkom.erp.web.controller.SignOutController
WMC
DIT
NOC
CBO
RFC
LCOM MaxLCOM RasioLCOM
2
1
0
0
7
0
1
0.0000
202 ilkom.erp.admin.dao.hibernate.AdminCompanyDaoHibernate
10
3
0
5
22
0
36
0.0000
203 ilkom.erp.service.impl.GeneralLedgerServiceImpl
26
1
0
9
44
193
325
0.5938
204 ilkom.erp.purchase.dao.PurchaseSupplyRFQDao
10
1
0
4
10
0
45
0.0000
205 ilkom.erp.purchase.dao.hibernate.PurchaseOrderDetailDaoHibernate
6
3
0
8
20
0
10
0.0000
206 ilkom.erp.order.dao.hibernate.OrderMonthendtrxDaoHibernate
6
3
0
9
21
0
10
0.0000
207 ilkom.erp.web.controller.accountReceivable.AddARInvoiceController$ARInvoiceDetailWrapper
5
1
0
1
10
6
15
0.4000
208 ilkom.erp.admin.dao.AdminModulPeriodDao
4
1
0
1
4
0
6
0.0000 0.2857
209 ilkom.erp.web.controller.generalLedger.GLAccountController
7
1
0
4
15
6
21
69
1
0
5
71
2208
2278
0.9693
211 ilkom.erp.accountPayable.dao.AccountPayablePaymentDetailDao
5
1
0
1
5
0
10
0.0000
212 ilkom.erp.web.util.MessagesListener
7
1
0
0
14
0
10
0.0000
213 ilkom.erp.generalLedger.dao.GeneralLedgerDao
4
1
0
1
4
0
6
0.0000
35
1
0
4
38
521
561
0.9287
4
1
0
1
4
0
6
0.0000
216 ilkom.erp.order.OrderPaymentType
11
1
0
1
12
45
55
0.8182
217 ilkom.erp.service.GeneralLedgerService
17
1
0
4
17
0
136
0.0000
218 ilkom.erp.web.controller.inventory.ListInventoryController$InventoryItemWrapper
5
1
0
2
7
2
10
0.2000
219 ilkom.erp.web.controller.purchase.ListRFQSupplierController
4
1
0
3
9
2
6
0.3333 0.0000
210 ilkom.erp.inventory.InventoryItem
214 ilkom.erp.purchase.PurchaseOrder 215 ilkom.erp.accountPayable.dao.AccountPayableMonthEndDao
220 ilkom.erp.admin.dao.AdminCompanyDao 221 ilkom.erp.web.controller.accountReceivable.AddARInvoiceController 222 ilkom.erp.admin.dao.hibernate.AdminVehicleDaoHibernate 223 ilkom.erp.web.controller.customer.EditProfileController 224 ilkom.erp.inventory.dao.hibernate.InventoryProductCategoryDaoHibernate 225 ilkom.erp.generalLedger.dao.GLJournalDetailDao
8
1
0
1
8
0
28
78
1
0
15
118
723
1035
0.6986
7
3
0
8
22
0
15
0.0000
10
1
0
3
14
23
45
0.5111
6
3
0
5
18
0
10
0.0000 0.0000
4
1
0
1
4
0
6
39
1
0
4
43
641
703
0.9118
8
3
0
6
24
0
15
0.0000
228 ilkom.erp.web.controller.admin.ModulPeriodController
44
1
0
2
54
339
465
0.7290
229 ilkom.erp.web.controller.purchase.PurchaseRequisitionController
45
1
0
9
65
97
253
0.3834
5
1
0
1
10
6
10
0.6000 0.0000
226 ilkom.erp.purchase.PurchaseSupplyRFQ 227 ilkom.erp.order.dao.hibernate.OrderDebiturDaoHibernate
230 ilkom.erp.web.controller.accountPayable.AddInvoiceController$InvoiceDetailWrapper 231 ilkom.erp.order.dao.OrderCartDetailDao 232 ilkom.erp.admin.AdminModul 233 ilkom.erp.accountReceivable.dao.hibernate.AccountReceivableInvoiceDaoHibernate 234 ilkom.erp.web.controller.purchase.FormSupplierController 235 ilkom.erp.admin.dao.AdminPageDao 236 ilkom.erp.web.controller.accountReceivable.ARReceiptController
4
1
0
1
4
0
6
21
1
0
1
24
160
190
0.8421
7
3
0
7
22
0
15
0.0000
16
1
0
5
31
20
78
0.2564
5
1
0
1
5
0
10
0.0000
11
1
0
3
17
18
36
0.5000
22
Lampiran 4 Beberapa Class yang Disarankan Agar Diperiksa Ulang dan/atau Direvisi Terkait Dengan Nilai Metrics-nya Metrics
WMC
CBO
RFC
No.
Class
1 ilkom.erp.order.OrderDebitur 2 ilkom.erp.web.controller.customer.FormOrderCartController 3 ilkom.erp.service.PurchaseService 4 ilkom.erp.web.controller.inventory.GoodReceiveController 5 ilkom.erp.web.controller.accountReceivable.AddReceiptController 6 ilkom.erp.web.controller.accountPayable.AddPaymentController 7 ilkom.erp.service.impl.AdminServiceImpl 8 ilkom.erp.web.controller.purchase.RFQController 9 ilkom.erp.inventory.InventoryItem 10 ilkom.erp.web.controller.accountPayable.AddInvoiceController 11 ilkom.erp.web.controller.accountReceivable.AddARInvoiceController 12 ilkom.erp.service.impl.PurchaseServiceImpl 1 ilkom.erp.service.impl.AdminServiceImpl 2 ilkom.erp.service.impl.PurchaseServiceImpl 1 ilkom.erp.web.controller.deliveryOrder.DeliverOrderCartController 2 ilkom.erp.web.controller.admin.ModulPeriodController 3 ilkom.erp.order.OrderDebitur 4 ilkom.erp.service.impl.AccountReceivableServiceImpl 5 ilkom.erp.service.PurchaseService 6 ilkom.erp.web.controller.accountPayable.APMonthEndController 7 ilkom.erp.service.impl.InventoryServiceImpl 8 ilkom.erp.web.controller.purchase.PurchaseRequisitionController 9 ilkom.erp.purchase.PurchaseSupplier 10 ilkom.erp.web.controller.generalLedger.GLJournalDetailController 11 ilkom.erp.inventory.InventoryItem 12 ilkom.erp.web.controller.inventory.FormInventoryController 13 ilkom.erp.service.impl.OrderServiceImpl 14 ilkom.erp.web.controller.inventory.GoodReceiveController 15 ilkom.erp.web.controller.accountReceivable.AddReceiptController 16 ilkom.erp.web.controller.purchase.RFQController 17 ilkom.erp.web.controller.accountPayable.AddPaymentController 18 ilkom.erp.web.controller.customer.FormOrderCartController 19 ilkom.erp.service.impl.AccountPayableServiceImpl 20 ilkom.erp.service.impl.AdminServiceImpl 21 ilkom.erp.web.controller.accountReceivable.AddARInvoiceController 22 ilkom.erp.web.controller.accountPayable.AddInvoiceController 23 ilkom.erp.service.impl.PurchaseServiceImpl
Nilai Metric 53 54 57 60 62 63 66 68 69 77 78 81 21 25 52 54 55 56 57 58 64 65 68 70 71 77 78 87 95 95 98 104 104 111 118 119 153
23
Lampiran 5 Ringkasan Pengaruh Metrics Terhadap Faktor-Faktor Kualitas berdasarkan sudut pandang masing-masing metric. Faktor Kualitas No Metric
Kategori Reusability
Usability Understandability Modifiability
Testability
1 WMC
tinggi
↓
↓
NA
NA
↓
2 DIT
tinggi
↑
NA
↓
↓
↓
3 NOC
tinggi
↑
NA
NA
NA
↓
4 CBO
tinggi
↓
NA
↓
↓
↓
5 RFC
tinggi
NA
NA
↓
↓
↓
6 LCOM
tinggi
NA
NA
↓
↓
↓
Keterangan : NA = Not Applicable
