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
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,
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
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
DAFTAR ISI
Halaman DAFTAR TABEL ... vi DAFTAR GAMBAR ... vi DAFTAR LAMPIRAN ... vi PENDAHULUAN... 1 Latar Belakang ... 1 Tujuan Penelitian ... 1Ruang 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 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). ... 2Gambar 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 ... 13Lampiran 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 pandangmasing-masing metric. ... 23
PENDAHULUAN
Latar BelakangDesain 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.
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. 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:
1 Menerapkan object oriented metrics
untuk melakukan evaluasi perangkat lunak berorientasi objek.
2 Menganalisis efektivitas object oriented
metrics yang digunakan. Ruang Lingkup Penelitian
Ruang lingkup penelitian ini adalah : 1 Metrics yang digunakan adalah object
oriented metrics yang diajukan oleh Chidamber & Kemerer (1994).
2 Perhitungan metrics dilakukan dengan
bantuan tool Chidamber & Kemerer Java
Metrics (CKJM). 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 LunakKualitas 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.
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).
• Testability
Menurut Jawadekar (2004), testability
adalah tingkat usaha yang dibutuhkan untuk
menguji perangkat lunak dalam proses quality
assurance. • Availability
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
• Dan menentukan apakah sebuah proyek sesuai dengan jadwal.
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
operasi-operasi 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.
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).
Penjelasan mengenai definisi, sudut
pandang, nilai batas atas, dan faktor-faktor kualitas apa saja yang terkait dengan
masing-masing metrics dapat dilihat pada subbab
selanjutnya.
Weighted Methods per Class (WMC)
Misalkan sebuah class C1 memiliki
methodsM1, M2,…, Mndan 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
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
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:
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 sebuahgraf.
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 CCyang rendah
bukan berarti method tersebut tidak kompleks.
Hal ini mungkin berarti bahwa method
tersebut melakukan message passing dalam
implementasinya (SATC 1995).
METODE PENELITIAN
Gambar 4 Diagram metodologi penelitian.
Penelitian ini dilaksanakan dengan
mengikuti tahap-tahap seperti pada gambar 4. Penelitian ini diawali dengan studi literatur,
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
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 cohesivenessclass tersebut. Begitu juga
sebaliknya, semakin dekat nilai rasio sebuah class dengan 1, berarti semakin rendah cohesivenessclass 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
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
KESIMPULAN DAN SARAN
KesimpulanEnam 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 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());
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
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}
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}
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 ilkom.erp.web.controller.deliveryOrder.DeliverOrderCartController$OrderCartWrapper 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 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 11 ilkom.erp.accountReceivable.dao.hibernate.AccountReceivableMonthEndDaoHibernate 6 3 0 9 21 0 10 0.0000 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 16 ilkom.erp.purchase.dao.PurchaseRequisitionDao 5 1 0 1 5 0 10 0.0000 17 ilkom.erp.web.util.SessionUtil 15 1 0 3 21 0 55 0.0000 18 ilkom.erp.admin.dao.AdminUserDao 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 26 ilkom.erp.generalLedger.dao.hibernate.GeneralLedgerDaoHibernate 6 3 0 5 17 0 10 0.0000 27 ilkom.erp.service.OrderService 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 31 ilkom.erp.purchase.dao.PurchaseMonthendtrxDao 4 1 0 1 4 0 6 0.0000 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 37 ilkom.erp.order.OrderShippingType 11 1 0 1 12 45 55 0.8182 38 ilkom.erp.web.controller.customer.InventoryItemController 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 41 ilkom.erp.web.controller.customer.FormOrderCartController$OrderCartDetailWrapper 7 1 0 1 17 7 15 0.4667 42 ilkom.erp.web.controller.admin.AdminUOMConvFormController 22 1 0 4 37 56 136 0.4118 43 ilkom.erp.inventory.dao.InventoryProductBrandDao 4 1 0 1 4 0 6 0.0000 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
Lanjutan
No. Class WMC DIT NOC CBO RFC LCOM MaxLCOM RasioLCOM
51 ilkom.erp.web.controller.inventory.FormInventoryController 46 1 0 10 77 324 496 0.6532 52 ilkom.erp.web.controller.accountReceivable.AddReceiptController$ReceiptDetailWrapper 5 1 0 1 11 6 10 0.6000 53 ilkom.erp.order.dao.hibernate.OrderPaymentTypeDaoHibernate 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 56 ilkom.erp.purchase.dao.PurchaseSupplyRFQDetailDao 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 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 67 ilkom.erp.order.dao.OrderDebiturDao 5 1 0 1 5 0 10 0.0000 68 ilkom.erp.accountPayable.AccountPayableInvoiceDetail 25 1 0 6 26 276 300 0.9200 69 ilkom.erp.inventory.dao.hibernate.InventoryGoodReceiveDaoHibernate 6 3 0 7 20 0 10 0.0000 70 ilkom.erp.web.controller.customer.SignUpController 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 75 ilkom.erp.web.controller.inventory.GoodReceiveController$GoodReceiveDetailWrapper 5 1 0 1 10 6 15 0.4000 76 ilkom.erp.order.OrderDebitur 53 1 0 2 55 1318 1378 0.9565 77 ilkom.erp.web.controller.purchase.PurchaseDemandController 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 87 ilkom.erp.admin.dao.AdminModulDao 5 1 0 1 5 0 10 0.0000 88 ilkom.erp.web.controller.purchase.ListRFQController 14 1 0 4 28 11 55 0.2000 89 ilkom.erp.inventory.dao.InventoryItemDao 5 1 0 1 5 0 10 0.0000 90 ilkom.erp.web.controller.generalLedger.GLJournalDetailController 44 1 0 8 70 74 276 0.2681 91 ilkom.erp.accountPayable.dao.hibernate.AccountPayablePaymentDaoHibernate 8 3 0 6 22 0 21 0.0000 92 ilkom.erp.web.controller.deliveryOrder.ListOrderCartController 14 1 0 3 28 7 55 0.1273 93 ilkom.erp.admin.dao.hibernate.AdminUOMDaoHibernate 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 96 ilkom.erp.accountPayable.dao.hibernate.AccountPayableInvoiceDetailDaoHibernate 8 3 0 9 24 0 21 0.0000 97 ilkom.erp.generalLedger.GLJournal 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
