Pengembangan Konsep Pendekatan budaya Modularit

(1)

PENGEMBANGAN KONSEP PENDEKATAN MODULARITAS DENGAN MODULARITY INDEX DAN MODULARITY FRAMEWORK PADA

PROYEK PERANGKAT LUNAK BERORIENTASI OBYEK

CONCEPT DEVELOPMENT OF MODULARITY APPROACHES WITH MODULARITY INDEX AND MODULARITY FRAMEWORK IN OBJECT

ORIENTED SOFTWARE PROJECTS

ANDI WAHJU RAHARDJO EMANUEL 08/274713/SPA/00182

PROGRAM DOKTOR ILMU KOMPUTER

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM UNIVERSITAS GADJAH MADA

(2)

PENGEMBANGAN KONSEP PENDEKATAN MODULARITAS DENGAN MODULARITY INDEX DAN MODULARITY FRAMEWORK PADA

PROYEK PERANGKAT LUNAK BERORIENTASI OBYEK

CONCEPT DEVELOPMENT OF MODULARITY APPROACHES WITH MODULARITY INDEX AND MODULARITY FRAMEWORK IN OBJECT

ORIENTED SOFTWARE PROJECTS

Disertasi untuk memperoleh derajat Doktor dalam Ilmu Komputer pada Universitas Gadjah Mada

ANDI WAHJU RAHARDJO EMANUEL 08/274713/SPA/00182

PROGRAM DOKTOR ILMU KOMPUTER

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM UNIVERSITAS GADJAH MADA

YOGYAKARTA

2012

(3)

(4)

(5)

dan duka

(6)

kasih dan karuniaNya penyusunan Disertasi yang merupakan dokumentasi proses penyelesaian studi tingkat Doktoral di Program Doktor Ilmu Komputer di Universitas Gadjah Mada ini telah berhasil disusun. Penyusun mengucapkan banyak terima kasih kepada berbagai pihak yang sangat membantu dalam proses penyelesaian studi Doktoral ini, terutama:

• Bp. Dr. Chairil Anwar (Dekan FMIPA, UGM)

• Bp. Dr. Pekik Nurwantoro, M.S (Wakil Dekan I dan Ketua Tim Penguji)

• Bp. Prof. Dr. Jazi Eko Istiyanto (Ketua Jurusan Ilmu Komputer dan Elektronika dan Ko-Promotor)

• Ibu Dra. Sri Hartati, M.Sc, Ph.D (Ketua Program Studi Monodisiplin S2/S3 Ilmu Komputer)

• Bp. Drs. Retantyo Wardoyo, M.Sc, Ph.D (Promotor)

• Bp. Dr. Tech. Khabib Mustofa (Ko-Promotor)

• Bp. Drs. Edi Winarko, M.Sc, Ph.D (Ketua Tim Penilai dan Penguji)

• Bp Ir. Lukito Edi Nugroho, M.Sc, Ph.D (Tim Penilai dan Penguji)

• Bp. Dr. Ridi Ferdiana, S.T, M.T (Tim Penilai dan Penguji)

• Bp. Prof. Dr. Ir. Iping Supriatna Suwardi (Penguji)

• Bp. Drs. Agus Harjoko, M.Sc, Ph.D (Penguji)

Kami juga mengucapkan banyak terima kasih kepada Universitas Kristen Maranatha yang telah memberikan bantuan finansial dan moral selama proses pelaksanaan studi dan penelitian Doktoral ini, terutama bagi rekan – rekan di

(7)

Perangkat Lunak (Software Engineering).

(8)

PERNYATAAN...iii

PRAKATA...v

DAFTAR ISI...vii

DAFTAR GAMBAR...xi

DAFTAR TABEL...xiii

DAFTAR LAMPIRAN...xix

DAFTAR LAMBANG DAN SINGKATAN...xx

INTISARI...xxiii

ABSTRACT...xxv

BAB I. PENDAHULUAN...1

1.1 Latar Belakang...1

1.2 Identifikasi dan Perumusan Masalah...5

1.3 Batasan Masalah...6

1.4 Tujuan Penelitian...7

1.5 Manfaat Penelitian...8

1.6 Sistematika Penulisan ...9

1.7 Daftar Publikasi...11

BAB II. TINJAUAN PUSTAKA...13

2.1 Penelitian Terkini...13

2.1.1 Proyek Perangkat Lunak Berbasis Open Source ...13

2.1.2 Pengukuran Kualitas pada Proyek Perangkat Lunak Open Source...16

2.2 Keaslian Penelitian...17

BAB III. LANDASAN TEORI...19

3.1 Pemrograman Berorientasi Obyek...19

3.2 Proyek Perangkat Lunak Open Source ...20

3.3 Metrics Perangkat Lunak (Software Metrics)...23

3.4 Framework Perangkat Lunak (Software Framework)...25

(9)

3.6 Modularitas Perangkat Lunak...29

3.7 SONAR...32

BAB IV. METODE PENELITIAN...33

4.1 Pengumpulan Informasi...33

4.2 Pengembangan Konsep...33

4.3 Analisis...34

4.4 Desain...35

4.5 Konstruksi...35

4.6 Pengujian...36

BAB V. DATAMINING PROYEK PERANGKAT LUNAK OPEN SOURCE. .38 5.1 Pengumpulan dan Klasifikasi Data Proyek Perangkat Lunak Open Source ...39

5.2 Hasil Datamining Association Rule untuk 2-Itemset ...67

5.3 Hasil Datamining Association Rule untuk 3-Itemset ...69

5.4 Hasil Publikasi...71

BAB VI. FORMULASI MODULARITY INDEX...72

6.1 Analisis Statistik dari Software Metrics yang Mempengaruhi Modularitas ...72

6.1.1 Proses pengumpulan data ...73

6.1.2 Analisis statistik dari software metrics...76

6.1.3 Kesimpulan hasil analisis statistik...84

6.2 Formulasi Modularity Index...86

6.2.1 Modularitas tingkat class ...86

6.2.2 Modularitas tingkat package...91

6.2.3 Modularitas tingkat sistem...92

6.2.4 Perumusan modularity index...93

6.3 Validitas untuk Bahasa Pemrograman Berorientasi Obyek...94

BAB VII. KONSTRUKSI MODULARITY FRAMEWORK...97

(10)

7.1.3 Arsitektur diagram modularity framework...101

7.1.4 Proses konstruksi modularity framework...102

7.1.5 Diagram jaringan modularity framework ...103

7.2 Sistem Rekomendasi (Recommender System)...104

7.2.1 Sistem rekomendasi tingkat sistem...105

7.2.2 Sistem rekomendasi tingkat package ...109

7.2.3 Sistem rekomendasi tingkat class...112

7.3 Tampilan Portal Modularity Framework...115

BAB VIII. VERIFIKASI DAN VALIDASI...123

8.1 Verifikasi Modularity Index: Studi Kasus Evolusi JFreeChart...123

8.1.1 Modularity index...124

8.1.2 Arsitektur sistem (SA)...125

8.1.3 Jumlah package di setiap versi...126

8.1.4 Rata – rata kualitas package...126

8.1.5 Jumlah class...127

8.1.6 Rata – rata class per package...128

8.1.7 NCLOC...129

8.1.8 Rata – rata NCLOC per class...130

8.1.9 Jumlah fungsi...131

8.1.10 Rata – rata fungsi per class...132

8.1.11 Kohesi (LCOM4) per class...133

8.1.12 Kesimpulan studi kasus JFreeChart...134

8.2 Verifikasi Modularity Index: Rekonstruksi Modularity Index dari Proyek OSS Lainnya...135

8.2.1 Histogram NCLOC di class...138

8.2.2 Histogram functions di class...142

8.2.3 Kesimpulan hasil verifikasi...147

(11)

8.3.3 Hasil uji user...150

Profil responden...150

Hasil kuestioner ...156

Hasil survey untuk pemula...157

Hasil survey untuk programer dan programer tingkat lanjut...191

Pertanyaan terbuka...226

8.3.4 Kesimpulan validasi dengan uji user...226

BAB IX. KESIMPULAN DAN SARAN...228

9.1 Kesimpulan...230

9.2 Saran...231

DAFTAR PUSTAKA...233

LAMPIRAN...238

(12)

Gambar 5.2 Sistem crawling dari proyek perangkat lunak open source...42

Gambar 5.3 Distribusi dari jumlah kata dari deskripsi proyek...49

Gambar 6.1 Grafik scatter dari NCLOC vs. Lines ...78

Gambar 6.2 Grafik scatter dari NCLOC vs. Cyclomatic Complexity...80

Gambar 6.3 Histogram dari NCLOC di class...87

Gambar 6.4 Histogram dari functions di class...88

Gambar 7.1 Use cases untuk modularity framework...99

Gambar 7.2 Diagram arsitektur dari modularity framework...101

Gambar 7.3 Diagram jaringan dari modularity framework...104

Gambar 7.4 Aturan sistem rekomendasi tingkat sistem...109

Gambar 7.5 Aturan sistem rekomendasi tingkat package...112

Gambar 7.6 Aturan sistem rekomendasi tingkat class...115

Gambar 7.7 Tampilan daftar proyek...116

Gambar 7.8 Tampilan komunitas proyek...116

Gambar 7.9 Membuat proyek baru...117

Gambar 7.10 Informasi proyek...117

Gambar 7.11 Pengaturan konfigurasi proyek...118

Gambar 7.12 Tampilan package...119

Gambar 7.13 Tampilan package dengan daftar berkas...119

Gambar 7.14 Tampilan package dengan daftar berkas dan melihat berkas...120

Gambar 7.15 Tampilan package dengan daftar berkas dan mengubah berkas....120

Gambar 7.16 Tampilan file manager dan melihat berkas...121

Gambar 7.17 Informasi modularity index dari sebuah proyek...121

Gambar 8.1 Modularity index di 33 versi dari JFreeChart...124

Gambar 8.2 Nilai SA di 33 versi dari JFreeChart...125

Gambar 8.3 Jumlah package di 33 versi JFreeChart...126

Gambar 8.4 Rata - rata PQ di 33 versi dari JFreeChart...127

(13)

Gambar 8.8 Rata – rata NCLOC per class dari 33 versi JFreeChart...131

Gambar 8.9 Jumlah fungsi dari 33 versi JFreeChart...132

Gambar 8.10 Jumlah fungsi per Class dari 33 versi JFreeChart...133

Gambar 8.11 Perkembangan LCOM4 per class dari 33 versi JFreeChart...134

Gambar 8.12 Histogram dari NCLOC di class...138

Gambar 8.13 Perkembangan nilai gradient untuk LOC Quality...139

Gambar 8.14 Perkembangan nilai constant untuk LOC Quality...140

Gambar 8.15 Perkembangan nilai polynomial untuk LOC Quality...141

Gambar 8.16 Perkembangan nilai err untuk LOC Quality...142

Gambar 8.17 Grafik histogram untuk functions di class...143

Gambar 8.18 Perkembangan nilai gradient untuk Function Quality...144

Gambar 8.19 Perkembangan nilai constant untuk Function Quality...145

Gambar 8.20 Perkembangan nilai polynomial untuk Function Quality...146

Gambar 8.21 Perkembangan nilai err untuk Function Quality...147

Gambar 8.22 Diagram lingkaran hasil pertanyaan 2...152

(14)

Tabel 5.1 Jumlah proyek perangkat lunak open source di berbagai portal...39

Tabel 5.2 Pertumbuhan proyek perangkat lunak open source di sourceforge.net. 40 Tabel 5.3 Parameter dan penjelasan dari data terekam ...42

Tabel 5.4 Statistik audiens dari proyek ...44

Tabel 5.5 Klasifikasi audience dari proyek...46

Tabel 5.6 Jumlah audiens dari setiap proyek...46

Tabel 5.7 Klasifikasi dari jumlah audiens...47

Tabel 5.8 Kategori basis data dari proyek...47

Tabel 5.9 Jumlah basis data untuk setiap proyek...48

Tabel 5.10 Klasifikasi dari jumlah database setiap proyek...49

Tabel 5.11 Jumlah kata dari deskripsi proyek...50

Tabel 5.12 Jumlah developer untuk setiap proyek ...50

Tabel 5.13 Klasifikasi dari jumlah developer...51

Tabel 5.14 Status pengembangan dari proyek...51

Tabel 5.15 Jumlah status pengembangan dari setiap proyek...52

Tabel 5.16 Klasifikasi dari jumlah status pengembangan ...52

Tabel 5.17 Statistik dari jumlah unduhan proyek...53

Tabel 5.18 Klasifikasi dari jumlah unduhan ...54

Tabel 5.19 Statistik dari ekstensi berkas...54

Tabel 5.20 Statistik dari orde ukuran berkas...55

Tabel 5.21 Statistik dari lisensi proyek...55

Tabel 5.22 Jumlah lisensi dari setiap proyek...56

Tabel 5.23 Klasifikasi dari jumlah lisensi ...57

Tabel 5.24 Statistik dari sistem operasi yang bisa dipakai proyek...57

Tabel 5.25 Jumlah sistem operasi untuk setiap proyek...58

Tabel 5.26 Klasifikasi dari jumlah sistem operasi di setiap proyek...59

Tabel 5.27 Statistik dari bahasa pemrograman proyek...59

(15)

Tabel 5.31 Klasifikasi dari jumlah review di setiap proyek ...61

Tabel 5.32 Statistik dari thumb total dari proyek ...62

Tabel 5.33 Klasifikasi dari total thumb ...62

Tabel 5.34 Statistik dari topik proyek...63

Tabel 5.35 Jumlah topik di setiap proyek...63

Tabel 5.36 Klasifikasi dari jumlah topik di setiap proyek ...64

Tabel 5.37 Kategori bahasa terjemahan di proyek ...64

Tabel 5.38 Jumlah bahasa terjemahan dalam proyek...65

Tabel 5.39 Klasifikasi dari jumlah bahasa terjemahan di setiap proyek...65

Tabel 5.40 Kategori antar muka dari proyek ...66

Tabel 5.41 Jumlah antar muka di setiap proyek...66

Tabel 5.42 Klasifikasi dari jumlah antar muka di setiap proyek...67

Tabel 5.43 Daftar publikasi yang berhubungan dengan datamining proyek...71

Tabel 6.1 Daftar software metrics yang dipergunakan...74

Tabel 6.2 Daftar dari 50 proyek perangkat lunak open source...75

Tabel 6.3: Klasifikasi dari nilai pearson r ...77

Tabel 6.4 Korelasi antara metrics ukuran dengan metrics yang lainnya...79

Tabel 6.5 Complexity metrics versus metrics lainnya...80

Tabel 6.6 Metrics kohesi versus metrics Lainnya...81

Tabel 6.7 RFC versus metrics lainnya...82

Tabel 6.8 Efferent coupling versus metrics lainnya...83

Tabel 6.9 Afferent coupling versus metrics lainnya...84

Tabel 6.10 Hasil observasi nilai kohesi di class...89

Tabel 6.11 Equivalensi SLOC terhadap Function Point...95

Tabel 6.12 Hasil publikasi tentang modularity index...96

Tabel 7.1 Klasifikasi metrics MI...106

Tabel 7.2 Klasifikasi metrics SA...107

Tabel 7.3 Klasifikasi metrics jumlah PQ...107

(16)

Tabel 7.7 Klasifikasi metrics rata - rata NLOC per class...111

Tabel 7.8 Klasifikasi metrics rata - rata functions per class...111

Tabel 7.9 Klasifikasi metrics CQ...113

Tabel 7.10 Klasifikasi metrics LOCQ...113

Tabel 7.11 Klasifikasi metrics FQ...114

Tabel 7.12 Klasifikasi metrics LCOM4...114

Tabel 7.13 Hasil publikasi tentang modularity framework...122

Tabel 8.1 Daftar proyek OSS sebagai sumber verifikasi...136

Tabel 8.2 Hasil profil untuk pertanyaan 1...150

Tabel 8.10 Hasil survey untuk pernyataan 1...157

Tabel 8.11 Korelasi pernyataan 1 dengan pernyataan lainnya...158

(17)

(18)

(19)

(20)

berbasis Java ...239

Lampiran B: Data modularitas dari 50 Proyek Open Source berbasis Java ...243

Lampiran C: Metrics – metrics tingkat sistem dari 33 versi Proyek OSS JFreeChart...246

Lampiran D: Data modularitas dari 33 versi Proyek OSS JFreeChart...249

Lampiran E: Metrics – metrics tingkat sistem dari 25 Proyek OSS...252

Lampiran F: Data modularitas dari 25 Proyek OSS...254

Lampiran G: Skenario Uji User...256

Lampiran H: Daftar Pertanyaan untuk Profil Responden Uji User...259

Lampiran I: Daftar Kuestioner untuk Uji User...260

Lampiran J: Petunjuk Pemakaian Modularity Framework...263

Lampiran K: Hasil Datamining Association Rule 2 – Itemset...279

Lampiran L: Hasil Datamining Association Rule 3 – Itemset...280

(21)

AFL

-lunak Open Source.

API

-Application Programming Interface – pustaka dari modul – modul perangkat lunak yang dapat dipergunakan sebagai antar muka ke berbagai komponen perangkat lunak oleh pengembangan / developer .

AWT - pustaka grafik untuk bahasa pemrograman Java yang dikembangkan sebelum terdapat pustaka yang lebih baik yang dinamakan Swing.

BSD

-Berkeley Software Distribution - tipe lisensi atau Sistem Operasi berbasis Unix yang dikembangkan di UCLA di Berkeley, Amerika Serikat.

CBO - Coupling Between Object – salah satu jenis metrics Kategori ketergantungan (dependency)

CVS

-Concurrent Version System – sistem kendali versi dari kode sumber perangkat lunak yang memungkinkan banyak orang untuk mengembangkan kode sumber secara bersama – sama tanpa adanya konflik yang berarti.

DB

-Database – sistem perangkat lunak yang khusus dibuat untuk menyimpan dan menampilkan data dalam jumlah sangat banyak atau basis data

GB - Gigabyte – sama dengan 1 milyar byte

GNU - GNU is not Unix - salah satu organisasi yang mempopulerkan konsep perangkat lunak Free atau Open Source

GPL - General Public License – salah satu jenis lisensi Open Source Software yang paling populer yang dikeluarkan oleh GNU

GTK - Graphical Toolkit – pustaka grafis yang dipakai untuk Sistem Operasi Linux khususnya manajer tampilan grafis Gnome

IDE

-Integrated Development Environment – lingkungan pengembangan terintegrasi yang dipakai untuk mengembangkan aplikasi perangkat lunak yang kompleks, contohnya adalah Netbeans, Eclipse, dan lain – lainya.

(22)

KDE - Manajer tampilan grafis untuk Sistem Operasi Linux selain Gnome, XFCE dan lain - lainnya

LCOM4

-Lack of Cohesion Metrics versi 4 – salah satu jenis metrics yang mengukur tingkat kesatuan (kohesi) dari suatu class, versi 4 adalah versi termutakhir yang lebih cocok dipergunakan untuk bahasa pemrograman beriorientasi obyek.

LGPL

-Lesser General Public License – tipe lisensi perangkat lunak Open Source yang populer, khususnya untuk pustaka perangkat lunak yang dikeluarkan oleh GNU

LOC - Lines of Code – baris kode perangkat lunak

LOCQ

-LOC (Lines of Code) Quality – salah satu metrics yang dikembangkan sebagai bagian dari Modularity Index untuk mengetahui kualitas dari baris kode dalam suatu class.

LTS

-Long Term Support – jenis dukungan yang diberikan untuk suatu rilis dari Sistem Operasi Linux varian Ubuntu yang akan memberikan dukungan dalam jangka waktu yang lebih lama daripada rilis lainnya. MB - Megabyte – sama dengan 1 juta byte

MI

-Modularity Index – salah satu software metrics yang dihasilkan dalam penelitian ini untuk mengukur tingkat modularitas suatu proyek perangkat lunak Open Source.

MIT - Massachuset Institute of Technology – salah satu perguruan tinggi ternama di Ameriak Serikat

MS - Microsoft – salah satu perusahaan Teknologi Informasi terkemuka yang didirikan oleh Bill Gates.

MySQL - Salah satu jenis aplikasi basis data yang dapat dipergunakan secara gratis.

NCLOC - Non-Commenting Lines of Code – baris kode tanpa menghitung komentar

NOC

-Number of Children – salah satu jenis software metrics yang menunjukkan jumlah anak class dari suatu class atau jumlah anak package dalam suatu package.

(23)

OS

-Operating System – salah satu jenis aplikasi perangkat lunak yang berhubungan langsung dengan perangkat keras seperti Linux, Windows, OSX dan lain – lainnya.

OSS - Open Source Software

PHP - Hypertext Preprocessor – salah satu jenis bahasa pemrograman berbasis skrip yang populer

PQ

-Package Quality – salah satu metrics dari Modularity Index yang dipergunakan untuk mengukur kualitas dari sebuah Package.

RFC - Request for Classes

SA

-Software Architecture – salah satu parameter penting dalam Modularity Index yang akan mengukur kualitas arsitektur dari sistem perangkat lunak.

SDL - Salah satu jenis lisensi perangat lunak Open Source (kalah populer dibandingkan GPL atau LGPL)

SLOC - Source Line of Code – metrics perangkat lunak untuk menentukan ukuran berdasarkan baris kode sumber

SQL - Structured Query Language – bahasa pengambilan data untuk basis data

SWT

-pustaka grafik untuk bahasa pemrograman Java yang dikembangkan oleh IBM dan komunitas Eclipse untuk menyaingi Swing yang dikeluarkan oleh Sun Microsystem

(24)

MODULARITY INDEX DAN MODULARITY FRAMEWORK PADA PROYEK PERANGKAT LUNAK BERORIENTASI OBYEK

oleh:

ANDI WAHJU RAHARDJO EMANUEL 08/274713/SPA/00182

Sistem perangkat lunak telah berkembang seiring dengan berkembangnya tantangan dan permasalahan yang perlu diakomodasi oleh sistem tersebut. Bahasa pemrograman dalam sistem perangkat lunak telah berkembang dari bahasa mesin yang sangat bergantung pada jenis mesinnya ke bahasa pemrograman berorientasi obyek, dan kemudian berkembang lagi ke penerapan prinsip modularitas untuk meningkatkan kemampuan sistem tersebut dalam menghadapi perubahaan dan tantangan yang lebih kompleks. Beberapa studi telah mengidentifikasikan bahwa modularitas adalah salah satu kunci keberhasilan dari proyek – proyek berorientasi obyek, namun bagaimana agar suatu proyek tersebut dapat mencapai modularitas belum sepenuhnya diketahui karena masih bersifat penilaian kualitatif. Penelitian doktoral ini mengusulkan beberapa pendekatan telah dikembangkan untuk menjawab penerapan konsep modularitas ini dalam proyek – proyek perangkat lunak berorientasi obyek, yaitu:

• Software Metrics (dinamakan Modularity Index) yang dapat memberikan nilai kuantitatif tingkat modularitas perangkat lunak berorientasi obyek.

• Software Framework (dinamakan Modularity Framework) yang merupakan bentuk penerapan dari Modularity Index dalam wujud suatu portal pengembangan sistem berorientasi obyek berbasis web.

Sumber – sumber data proyek dalam merumuskan konsep ini berasal dari proyek

(25)

berbasis web dengan rekomendasi – rekomendasi yang dihasilkan dari pengukuran Modularity Index maka diharapkan proses evolusi dari suatu proyek perangkat lunak bisa berjalan dengan menerapkan pendekatan modularitas sejak awal yang pada akhirnya akan meningkatkan modularitas dari proyek tersebut. Dari hasil studi kasus, verifikasi, dan validasi yang dilakukan menunjukkan bahwa Modularity Index mampu menganalisis kelemahan dan kelebihan dari suatu proyek perangkat lunak JFreeChart dan Modularity Framework mampu membantu para pengembang untuk meningkatkan modularitas sistem perangkat lunaknya.

(26)

MODULARITY INDEX AND MODULARITY FRAMEWORK IN OBJECT ORIENTED SOFTWARE PROJECTS

by:

ANDI WAHJU RAHARDJO EMANUEL 08/274713/SPA/00182

Software systems have evolved as the challenges and problems to be accomodated with them are also evolved. The programming languages of the software systems have evolved from machine-dependent machine languages into object-oriented programming languages, and then they matures into the application of modularity principles to enhance the capabilities of system against more complex challenges. Some studies have identified that modularity is one of the key success factors of object-oriented software projects, but how modularity should be applied in these projects is not clearly understood since it is still justified qualitatively. This doctoral research proposes several approaches to answer this application of modularity concept in object-oriented poftware projects, which are:

• Software Metrics (named Modularity Index) to measure quantitatively the modularity level of object-oriented software projects.

• Software Framework (named Modularity Framework) which implements the Modularity Index metrics in the form of web-based object-oriented Software Integrated Development Environment.

The project data sources are taken sourceforge portal which are Open Source java projects that are popular and architecturally good. The combination of Modularity Framework which is a web-based Integrated Development Environment and recommendations generated from Modularity Index should enable the application

(27)

identify the weaknesses dan strengths of the JFreeChart project, and the Modularity Framework is able to assist developers to improve the modularity of their projects.

(28)

1.1 Latar Belakang

Pemrograman berorientasi obyek telah menjadi arus utama (mainstream) dari bahasa pemrograman di dunia. Bermula dari bahasa pemrograman yang sangat berorientasi mesin (bahasa mesin dan bahasa assembler) yang sangat sulit dibaca dan dipahami sehingga menjadi tidak berkembang karena sulit untuk menarik minat pengembang – pengembang baru. Seiring dengan berkembangnya tingkatan permasalahan yang bisa diakomodasi oleh perangkat lunak, maka berkembanglah bahasa pemrograman prosedural seperti bahasa C, Pascal, Fortran, Basic dan lain – lainnya yang hanya mampu menjawab tantangan permasalahan pada tingkat kompleksitas tertentu saja. Dengan tuntutan permasalahan yang semakin besar lagi maka berkembanglah bahasa pemrograman berorientasi obyek seperti Java dan C# yang dianggap mampu menjawab tantangan permasalahan selama dua dasawarsa.

Dengan semakin kompleksnya permasalahan yang ingin diselesaikan dengan menggunakan perangkat lunak, maka modularitas dari perangkat lunak berorientasi obyek menjadi semakin penting. Permasalahan yang besar dan kompleks akan sulit diakomodasi oleh suatu perangkat lunak yang dibuat secara spesifik untuk permasalahan tersebut. Pemecahan masalah akan lebih mudah apabila permasalahan yang besar tersebut dapat dipecah – pecah menjadi permasalahan yang lebih kecil dalam bentuk suatu 'modul' perangkat lunak yang ukurannya kecil pula. Modul – modul ini dibuat sedemikian rupa agar dapat 'berkomunikasi' satu dengan yang lain dengan aturan yang tidak terlalu ketat sehingga memudahkan dalam pengembangannya apabila terdapat persyaratan baru yang muncul. Suatu 'modul' dari suatu sistem perangkat lunak yang modular juga dapat dipergunakan kembali di sistem yang lainnya yang memiliki kemiripan baik sebagian kecil maupun besar dalam persyaratannya. Pada proses

(29)

pengembangan dan pemeliharaannya, modul – modul ini akan dikembangkan oleh kelompok – kelompok pengembang yang berbeda – beda baik secara tertutup dan komersial maupun secara kode terbuka (Open Source).

Salah satu model pengembangan perangkat lunak yang sekarang menjadi tren adalah proyek perangkat lunak berbasis Open Source. Konsep pengembangan perangkat lunak berbasis Open Source yang menerapkan prinsip kode terbuka dengan ajakan bagi siapa saja untuk mengembangkan bersama – sama secara komunitas telah berkembang menjadi salah satu arus utama dalam pengembangan berbagai macam aplikasi dan telah terbukti kehandalannya. Gerakan ini dipelopori pada tahun 1990an oleh Richard Stallman dalam tulisannya “Why Software Should be Free” (Stallman, 1992) dan juga oleh Eric Raymond dalam tulisannya “The Cathedral and the Bazaar” (Raymond, 2000). Dengan mengandalkan berbagai macam perangkat pendukung (Version Control, Bug Report, Mailing List, Wish List / TODO List, email, dan lain – lain), para developer mampu bekerja sama satu dengan yang lain meskipun mereka tidak pernah bertemu secara fisik karena mereka tersebar di segala penjuru dunia. Meskipun demikian, cara pengembangan ini telah terbukti berhasil menghasilkan berbagai macam aplikasi dengan kualitas tinggi yang tidak kalah dengan aplikasi yang dikembangkan secara komersial. Beberapa aplikasi yang dikembangkan dengan metode ini telah menjadi pemimpin pasar atau menjadi aplikasi pesaing yang pantas diperhitungkan seperti server web Apache, browser web Mozilla Firefox, sistem operasi Linux dengan berbagai Distro-nya, pendukung perkantoran Libre Office dan lain – lain.

(30)

357 proyek (0,2%), yang diunduh 1 juta – 100 ribu kali sebanyak 1761 proyek (1,1%), yang diunduh dibawah 100 ribu kali sebanyak 79.089 proyek (51%), dan yang berakhir di tingkat konsep saja sekitar 73.998 proyek (48%). Fenomena ini terjadi disebabkan oleh beberapa faktor yang juga telah berhasil diidentifikasi oleh para peneliti.

Berbagai macam faktor telah teridentifikasi sebagai penyebab kegagalan proyek – proyek perangkat lunak Open Source ini, seperti kurangnya kemampuan teknis, minimnya dukungan dokumentasi dan kurangnya metodologi formal (Christley & Madey, 2007). Tingginya tingkat kemampuan teknis yang harus dimiliki terlebih dahulu oleh seseorang untuk dapat berkontribusi secara signifikan pada suatu proyek Open Source merupakan salah satu alasan kegagalan suatu proyek Open Source (Bird et al, 2007) (Stewart et al, 2005). Ini berakibat banyak pengguna yang berkeinginan menjadi kontributor menjadi segan untuk berkecimpung lebih jauh yang menyebabkan minimnya partisipasi dari orang lain selain inisiator proyek Open Source itu sendiri. Kurangnya dokumentasi juga merupakan kendala yang lain (Bouktif et al, 2006), yang akan menyebabkan calon kontributor akan kesulitan dalam menentukan pada bagian mana dalam proyek Open Source tersebut dia akan ikut berperan. Kurangnya metodologi formal juga dituding sebagai penyebab dari kegagalan proyek Open Source, yang menyebabkan tolok ukur dan panduan dalam siklus hidup suatu proyek pengembangan perangkat lunak berbasis Open Source menjadi tidak jelas.

(31)

(DeKoeg-nigsberg, 2008) (Gurbani et al, 2006). Modularitas merupakan elemen atau atri-but internal yang paling penting dari kualitas perangkat lunak Open Source dan modularitas ini memiliki hubungan langsung dengan arsitektur dari perangkat lu-nak tersebut (Nakagawa el al, 2008) (Melton & Tempero, 2007). Berdasarkan fakta – fakta diatas, maka satu aspek penting yang dipilih untuk menjadi fokus pada penelitian doktoral ini adalah faktor modularitas dari kode sumber dari pro-yek – propro-yek perangkat lunak Open Source.

(32)

diperguna-kan sebagai panduan dalam proses perkembangan proyek – proyek perangkat lu-nak berorientasi obyek agar dapat meningkat modularitasnya, yang pada akhir-nya akan meningkatkan juga kualitas dari perangkat lunak tersebut.

1.2 Identifikasi dan Perumusan Masalah

Dari berbagai macam paparan, petunjuk dan fakta yang telah dikemukakan diatas, maka dapat diketahui identifikasi masalah yang perlu dikaji lebih jauh dalam penelitian doktoral ini, yaitu:

1. Pengembangan pada proyek perangkat lunak berorientasi obyek, khususnya proyek perangkat lunak Open Source memang sudah menunjukkan beberapa hasil yang sangat baik, misalnya sistem operasi Linux, web server Apache, web browser Mozilla, server email Sendmail, dan lain – lain, namun jumlahnya masih relatif sangat kecil dibandingkan dengan total keseluruhan proyek Open Source yang ada selama ini.

2. Kontributor aktif dari proyek perangkat lunak berorientasi obyek khususnya proyek perangkat lunak Open Source masih sangat sedikit, terutama di sisi pengembang utama (Core Developer) dikarenakan terdapatnya skill barrier (penghambat kemampuan) bagi siapa saja dengan kemampuan teknis pemrograman yang sedang atau kurang untuk dapat berkontribusi secara signifikan (Bird et al, 2007) (Stewart et al, 2005). Tingkat dokumentasi yang seharusnya bisa menjadi alat bantu bagi para calon kontributor untuk mendalami proyek Open Source pada situs – situs proyek tersebut juga dalam kondisi yang sangat sedikit untuk proyek – proyek Open Source skala kecil dan sedang (Bouktif et al, 2006) .

(33)

Dari permasalahan – permasalahan yang telah diidentifikasikan diatas, maka perumusan masalah yang akan diteliti pemecahannya pada penelitian doktoral ini adalah menemukan sebuah konsep pendekatan modularitas sejak awal proses pengembangan dari proyek – proyek perangkat lunak berorientasi obyek yang ditempuh dengan 2 pendekatan:

1. Bagaimana merumuskan sebuah tolok ukur kuantitatif tunggal dari tingkat modularitas dari suatu proyek perangkat lunak berorientasi obyek?

2. Bagaimana menerapkan tolok ukur kuantitatif tunggal ini dalam sebuah lingkungan pengembangan terintegrasi yang bisa membantu para administrator dan kontributor lainnya dalam suatu proyek agar tingkat modularitas dari proyek tersebut dapat meningkat?

1.3 Batasan Masalah

Berbagai macam permasalahan dan kendala mengenai proses pengembangan perangkat lunak berorientasi obyek yang disebutkan pada sub bab 1.2, tidak semu-anya bisa dikaji dan dirumuskan solusinya dalam penelitian selama 3 tahun. Maka perlu dirumuskan batasan – batasan penelitian agar lebih terfokus pada be-berapa permasalahan penting yaitu:

• Fokus pada pengembangan perangkat lunak berorientasi obyek pada skala kecil sampai menengah. Batasan kecil dan menengah disini adalah memi-liki NCLOC ≤ 170K yang didapatkan berdasarkan observasi berbagai ma-cam proyek perangkat lunak Open Source di portal sourceforge. Semua proyek perangkat lunak yang dikembangkan secara Open Source akan di-mulai dari skala kecil, pada fase ini adalah fase paling kritis yang akan me-nentukan tingkat keberhasilan proyek perangkat lunak tersebut (Lehman, 1996).

(34)

parameter yang menjadi karakteristik utama modularitas seperti jumlah modul, ketergantungan (dependency), kompleksitas (complexity) dan lain – lain akan lebih mudah dilakukan dengan parameter – parameter yang ter-dapat pada pemrograman berorientasi obyek seperti package, class, functi-on / method dan lain – lain. Bahasa pemrograman Java dipilih karena me-rupakan salah satu bahasa pemrograman berorientasi obyek paling populer (lebih dari 20% proyek Open Source di sourceforge dikembangkan dengan bahasa pemrograman Java, seperti yang ditunjukkan pada tabel 5.27) di dunia Open Source yang bersifat multi-platform (mendukung lebih dari satu Sistem Operasi).

• Fokus pada penerapan konsep modularitas kode sumber proyek perangkat lunak berorientasi obyek yang bersifat statis. Kemudahan pemahaman dari kode sumber karena memiliki tingkat modularitas yang tinggi diha-rapkan mampu menarik pengembangan dan kontributor lainnya untuk ber-gabung. Aspek – aspek dinamis yang juga ada dalam sistem perangkat lu-nak tersebut misalnya ketergantungan yang dinamis tidak diperhitungkan dalam penelitian doktoral ini.

1.4 Tujuan Penelitian

Berangkat dari temuan bahwa modularitas merupakan salah satu kunci keberhasilan pada proyek – proyek berorientasi obyek, dan juga telah teridentifikasinya karakteristik – karakteristik modularitas pada perangkat lunak (lihat sub bab 3.6), maka dipandang perlu untuk mengembangkan lebih lanjut hasil – hasil temuan diatas menjadi sebuah konsep pendekatan modularitas pada proyek pengembangan perangkat lunak berorientasi obyek agar lebih terukur dan sistematis. Penerapan konsep pendekatan modularitas ini akan diterapkan dalam dua buah pendekatan yang lebih spesifik, yaitu:

(35)

modularitas suatu perangkat lunak dengan menggabungkan karakteristik – karakteristik utama yang mengindikasikan modularitas perangkat lunak yaitu ukuran (size – berupa ukuran modul dan jumlah modul), kompleksitas (complexity), kohesi (cohesion), dan ketergantungan (dependency / coupling – afferent coupling dan efferent coupling) ke dalam suatu pengukuran tunggal yang dinamakan Modularity Index.

2. Suatu Software Framework (dinamakan Modularity Framework) yang akan mengintegrasikan pengukuran berdasarkan Modularity Index dalam pengembangan proyek – proyek perangkat lunak berorientasi obyek berbasis web. Hasil – hasil pengukuran akan menghasilkan rekomendasi – rekomendasi akan diberikan selama proses pengembangan agar tingkat modularitas dari proyek perangkat lunak berorientasi obyek bisa meningkat.

1.5 Manfaat Penelitian

Hasil dari penelitian doktoral ini dapat dipergunakan sebagai perangkat pendukung pengembangan perangkat lunak berorientasi obyek yang lebih baik yang akan memudahkan bagi berbagi pihak yang ingin memulai atau berpartisipasi dalam proyek tersebut. Adapun manfaat penelitian doktoral adalah sebagai berikut:

1. Bagi keilmuan Software Engineering:

• Software Metrics yang dikembangkan yaitu Modularity Index merupakan bentuk Software Metrics baru jenis Quality Metrics yang dapat dipergunakan untuk mengukur secara kuantitatif tingkat modularitas perangkat lunak berbasis berorientasi obyek.

(36)

menerapkan rekomendasi – rekomendasi berdasarkan pengukuran dari Modularity Index.

2. Bagi organisasi – organisasi pengelola portal untuk proyek – proyek perangkat lunak: akan memberikan nilai lebih pada portalnya dengan tambahan fitur seperti Modularity Index beserta rekomendasi – rekomendasinya dalam Modularity Framework. Tambahan – tambahan fitur ini dapat membantu para administrator dan pengembang lainnya dalam meningkatkan tingkat modularitas proyek – proyek perangkat lunak yang didaftarkan dan dikembangkan di dalam portal tersebut.

3. Bagi inisiator / Administrator proyek: akan diberikan rekomendasi - rekomendasi dalam memulai dan mengembangkan suatu proyek berorientasi obyek secara benar. Apabila proyek tersebut sudah berjalan, inisiator akan lebih mudah dalam mengembangkan proyeknya agar lebih meningkat modularitasnya.

4. Bagi pengembang (developer) lainnya: memiliki gambaran yang lebih baik tentang proyek yang memungkinkan untuk berpartisipasi lebih jauh dan mendapatkan gambaran yang lebih jelas tentang proyek berorientasi obyek dimana developer tersebut aktif berkontribusi.

5. Bagi pemula / passive user / reader: akan memudahkan kontribusi awal dalam proyek dalam bentuk apapun sehingga dapat tertarik untuk berkontribusi lebih lanjut ke tingkat yang lebih tinggi.

1.6 Sistematika Penulisan

Hasil penelitian doktoral ini didokumentasikan dalam disertasi ini yang dibagi menjadi 9 buah bab, yaitu:

(37)

• Bab II. Tinjauan Pustaka: Tinjauan terhadap karya – karya ilmiah terkini dari beberapa peneliti yang berkaitan dengan penelitian doktoral ini, yaitu mengenai proyek perangkat lunak Open Source, dan pengukuran modularitas perangkat lunak. Keaslian dari penelitian doktoral ini juga dipaparkan dalam bab ini.

• Bab III. Landasan Teori: Penjelasan secara ringkas teori – teori yang berkaitan dengan permasalahan dan tahapan penelitian yang telah ditempuh dalam rangka menemukan solusi dari permasalah tersebut.

• Bab IV. Metode Penelitian: Tahapan – tahapan atau milestones dari penelitian yang telah ditempuh dalam rangka menemukan solusi dari permasalahan yang ditemukan.

• Bab V. Datamining Proyek Perangkat Lunak Open Source: Tahapan awal penelitian yang bertujuan untuk mendapatkan gambaran besar tentang proyek – proyek perangkat lunak Open Source dari portal pengembangan proyek perangkat lunak Open Source terbesar yaitu sourceforge.net. Hasil penelitian ini merupakan pijakan untuk penelitian tahap – tahap selanjutnya.

• Bab VI. Formulasi Modularity Index: Proses perumusan dari Modularity Index yang merupakan tolok ukur kuantitatif tingkat modularitas dari proyek perangkat lunak berorientasi obyek.

• Bab VII. Konstruksi Modularity Framework: proses pengembangan dari portal Modularity Framework yang didalamnya terdapat sistem rekomendasi yang berdasarkan dari pengukuran Modularity Index.

(38)

• Bab IX. Kesimpulan dan Saran: Kesimpulan yang dapat diperoleh selama penelitian doktoral dan saran pengembangan lebih lanjut dari penelitian ini.

Pada bagian akhir dari disertasi ini dicantumkan pula Daftar Pustaka dan Lampiran – lampiran yang berisi data – data terperinci yang menjadi pendukung paparan dan argumentasi dalam isi disertasi.

1.7 Daftar Publikasi

Selama proses penelitian doktoral ini telah menghasilkan beberapa publikasi di jurnal lokal, konferensi Internasional dan Jurnal Internasional, yaitu:

1. Emanuel A.W.R., Wardoyo R., Istiyanto J.E., Mustofa K., "Modularity Index Metrics for Java-Based Open Source Software Projects", International Journal of Advanced Computer Science and Applications (IJACSA) Vol. 2 No. 11, November 2011.

2. Emanuel A.W.R., Wardoyo R., Istiyanto J.E., Mustofa K., "Statistical Analysis on Software Metrics Affecting Modularity in Open Source Software", International Journal of Computer Science and Information Technology (IJCSIT), Vol. 3 No. 3 June 2011.

3. Emanuel A.W.R., Wardoyo R., Istiyanto J.E., Mustofa K., "Success Rule of OSS Projects using Datamining 3-Itemset Association Rule", International Journal of Computer Science Issues (IJCSI), Vol. 7 Issue 6 November 2010.

4. Emanuel A.W.R., Wardoyo R., Istiyanto J.E., Mustofa K., "Finding Suitable Modularity Technique for OSS Projects", Proceeding The 6th International Conference on Information and Communication Technology and Systems (ICTS) 2010.

(39)

Rule", Proceeding The 2nd International Conference on Distributed Frameworks and Applications (DFmA) 2010.

6. Emanuel A.W.R., Wardoyo R., Istiyanto J.E., Mustofa K., "Statistical Analysis of Open Source Software Projects from Sourceforge.Net", Proceeding The International Conference on Computer and Mathematical Science 2010.

7. Emanuel A.W.R., Istiyanto J.E., "An Ideal Internet-based Integrated Development Environment for Open Source Software Projects", Proceeding International Industrial Informatics Seminar (IIS) 2009.

8. Emanuel A.W.R., Mustofa K., "Modularity Index to Quantify Modularity of Open Source Software Projects", Proceeding The 5th International Conference on Information and Communication Technology and Systems (ICTS) 2009.

9. Emanuel A.W.R., Wardoyo R., "An Ideal Structure of Open Source Communities", Proceeding The 5th International Conference on Information and Communication Technology and Systems (ICTS) 2009. 10. Istiyanto J.E., Emanuel A.W.R., "Success Factors of Open Source

Software Projects using Datamining Technique", Proceeding Information and Communication Technology International Seminar (ITIS) 2009.

11. Emanuel A.W.R, Mustofa K, "Modularity Framework as a New Software Framework in Enhancing Modularity in Open Source Projects", Proceedings International Conference on Rural Information and Communication Technology (r-ICT) 2009.

(40)

2.1 Penelitian Terkini

Penelitian – penelitian terkini yang berhubungan dengan penelitian doktoral ini terbagi menjadi dua bagian, yaitu: penelitian di proyek – proyek perangkat lunak berbasis Open Source, dan penelitian di pengukuran kualitas perangkat lunak pada proyek – proyek perangkat lunak Open Source.

2.1.1 Proyek Perangkat Lunak Berbasis Open Source

Beberapa studi telah berhasil mengidentifikasikan beberapa kunci keberhasilan dari proyek – proyek perangkat lunak berbasis Open Source, diantaranya:

• Adanya komunitas Open Source (Open Source Communities) yang ber-evolusi baik di dalam komunitas itu sendiri, juga ber-ber-evolusi bersama sama dengan system perangkat lunak Open Source yang dikembangkan (Nakakoji et al, 2002). Open Source Communities merupakan bagian yang tidak terpisahkan dengan Sistem Open Source itu sendiri (Christley & Madey, 2007) (Crowston et al, 2006) (van Mendel & de Bruijne, 2006).

• Arsitektur dari Sistem Open Source yang sound dan modular (Lawrie & Gacek, 2002) (Gurbani et al, 2006) (Dekoenigsberg, 2008). Kondisi arsitektur yang seperti ini akan memungkinkan adanya penurunan hambatan awal (entry-barier) bagi pengembangnya (Dekoenigsberg, 2008) dan juga memungkinkan adanya partisipasi yang berguna bagi anggota baru dari komunitas.

• User adalah developer dari Sistem Open Source itu sendiri (Crowston et al, 2004). Para User dan juga sebagai Developer dari Sistem Open Source ini biasanya terdiri dari para programmer yang berpengalaman (Lawrie &

(41)

Gacek, 2002). Ketersediaan dari Source Code (Crowston et al, 2004) juga memungkinkan semua orang untuk mengunduh, memodifikasi, dan mengembangkan Sistem Open Source tersebut.

Pada proyek perangkat lunak berbasis Open Source yang sudah maju, sistem perangkat lunaknya pada akhirnya akan bersifat modular dan bisa dikembangkan secara bersama – sama oleh kelompok yang terdistribusi secara geografis. Sedangkan komunitas Open Source biasanya terstruktur dengan baik menjadi:

• Delapan peran (roles) yang mulai dari Project Leader, Core Member, Active Developer, Peripheral Developer, Bug Fixer, Bug Reporter, Reader dan Passive Users yang sifatnya sangat dinamis (Mockus et al, 2000). Dengan konsep pengembangan yang memungkinkan kelompok orang yang ahli hanya mengembangkan bagian tertentu saja yang diinginkan dan yang sesuai saja, ditambah adanya review antar developer (peer review) yang sangat intens maka komunitas biasanya akan berkembang seiring dengan kemajuan perkembangan sistem perangkat lunak yang sedang dikembangkan.

• Struktur lapisan bawang (Crowston et al, 2006) dimana Core Developer terletak di tengah – tengah dan dikelilingi oleh banyak Peripheral Developer, dan di lapisan paling akhir adalah Bug Reporter di lapisan paling luar. Lebih lanjut lagi, penelitian oleh Showole et al menganjurkan struktur komunitas yang dinamakan model Open Onion (Showole et al, 2011).

• Komunitas Open Source telah menerapkan sejenis metode pengembangan perangkat lunak meskipun masih dalam bentuk yang sederhana (Christley & Madey, 2007).

(42)

sisi dokumentasi (Bouktif et al, 2006), tidak adanya atau lemahnya sarana pengembangan yang formal seperti perancanaan proyek, manajemen persyaratan, manajemen kualitas dan lain – lain (Bouktif et al, 2006) (Stallman, 1992), dan juga sisi kode sumbernya itu sendiri adalah perubahan kode sumber dengan sangat cepat, gaya koding yang buruk, dan kesulitan penanganan apabila sudah menjadi sangat kompleks (Lawrie & Gacek, 2002)(Zhou & Davis, 2005). Adapun di sisi komunitas memiliki kelemahan yaitu keluar masuknya pendukung yang sangat cepat, kurangnya dukungan formal, dan pada kenyataannya hanya terdapat sedikit proyek Open Source yang berhasil menarik cukup banyak pendukung sehingga berhasil (Bouktif et al, 2006) (Lawrie & Gacek, 2002). Bahkan beberapa ahli menekankan masalah potensial yang serius di dalam proyek berbasis Open Source yang sekarang ini yang sudah dianggap berhasil misalnya peningkatan kompleksitas, ledakan jumlah kode sumber, dan penurunan kualitas yang dikarenakan semakin sulitnya pengelolaan proyek tersebut (Bouktif et al, 2006) (Spaeth & Stuermer, 2007).

(43)

2.1.2 Pengukuran Kualitas pada Proyek Perangkat Lunak Open Source

Isu fundamental dari pengembangan proyek perangkat lunak Open Source adalah bagaimana mengukur kualitas dari suatu sistem yang modular (Aruna et al, 2008) dikarenakan kualitas dari perangkat lunak Open Source adalah sulit untuk didefinisikan dan kompleks untuk divalidasi (Yang, 2006). Capra et al dalam stu-di literaturnya mengungkapkan bahwa tidak ada suatu metrics instu-dividual yang da-pat menentukan kualitas dari suatu perangkat lunak Open Source dan pengukuran kualitas yang tersedia sekarang ini hanya berkisar pada tingkat kompleksitas dan metrics desain kualitas (Capra et al, 2008). Zhou dan Davis dalam penelitian reka tentang model kehandalan perangkat lunak menyatakan bahwa tidak ada me-tode atau metrics yang cukup baik untuk mengevaluasi kualitas proyek – proyek perangkat lunak Open Source (Zhou & Davis, 2005).

Meskipun cukup banyak peneliti yang menyangsikan adanya pengukuran yang komprehesif tentang kualitas perangkat lunak Open Source, ternyata cukup ba-nyak juga peneliti lain yang sudah memulai usaha – usaha pengukuran kualitas ini pada tingkat komponen / class. Alsmadi dan Magel menemukan bahwa ting-kat efisiensi Lines of Code (LOC) dari proyek – proyek perangting-kat lunak Open So-urce adalah sekitar 70% - 80% (Alsmadi & Magel, 2006). Studi tentang proyek Mozilla menunjukkan bahwa metrics CBO sangat baik dipergunakan untuk meng-ukur tingkat fault-proneness di sebuah class, sedangkan metrics LOC baik diper-gunakan dalam analisis cepat tingkat fault-proneness tersebut (Gymothy et al, 2005). Studi oleh Sing et al telah menunjukkan bahwa metrics NOC (Number of Children) memiliki korelasi yang tinggi dengan jumlah kecacatan (defects) dari proyek perangkat lunak Open Source dibandingkan dengan metrics – metrics yang lainnya (Sing et al, 2011).

(44)

2007). Studi tentang proyek JFreeChart menunjukkan bahwa kualitas dari pe-rangkat lunak ditentukan oleh rendahnya coupling dan tingginya cohesion. Pada studi ini ditemukan bahwa tingkat fan out diinginkan rendah supaya mudah diper-gunakan kembali sedangkat tingkat fan in diinginkan tinggi yang menandakan ba-nyaknya pemakaian kembali oleh modul / class lainnya (Lee et al, 2007). Bidve dan Khare menyatakan bahwa coupling adalah ukuran kualitas perangkat lunak yang penting di sistem berorientasi obyek dan dapat dipergunakan untuk mempre-diksi ukuran kualitas seperti fault-proneness, efek imbas dari perubahan, tingkat perubahan dan lain lainnya (Bidve & Khare, 2012).

2.2 Keaslian Penelitian

Dari faktor – faktor keberhasilan pada proyek – proyek perangkat lunak berorientasi obyek, modularitas akan menjadi fokus utama dari penelitian doktoral ini. Penerapan prinsip modularitas yang baik sejak inisiasi dari proyek akan meningkatkan tingkat modularitasnya, yang akhirnya akan bisa meningkatkan kualitas dari proyek itu sendiri. Penelitian doktoral ini akan menjawab bagaimana cara (HOWTO) mencapai modularitas dari proyek perangkat lunak berorientasi obyek sejak awal inisiasi proyek, dan pendekatan yang diusulkan pada penelitian ini adalah pengembangan proyek perangkat lunak secara terpusat melalui suatu Software Framework yang menerapkan prinsip modularitas. Ini berbeda apabila dibandingkan dengan penelitian – penelitian sebelumnya yang lebih berfokus pada identifikasi (WHAT) yang menemukan karakteristik – karakteristik dari modularitas pada proyek – proyek perangkat lunak berorientasi obyek.

(45)

(46)

yaitu landasan teori tentang pemrograman berorientasi obyek, proyek perangkat lunak Open Source, metrics perangkat lunak, framework perangkat lunak, Datamining Association Rule, modularitas perangkat lunak, dan pembahasan tentang perangkat SONAR yang dipergunakan selama penelitian doktoral ini.

3.1 Pemrograman Berorientasi Obyek

Bahasa pemrograman berorientasi obyek merupakan pengembangan revolusioner dari proses perkembangan bahasa pemrograman. Bahasa pemrograman berkembang dari bahasa mesin, bahasa assembler, bahasa pemrograman prosedural (C, Basic, dan lain - lain), dan pada akhirnya berkembang menjadi bahasa pemrograman berorientasi obyek. Contoh bahasa pemrograman berorientasi obyek yang sekarang masih populer adalah Java dan C#. Bentuk bahasa pemrograman berorientasi obyek ini masih bertahan meskipun sekarang ini sudah mulai populer bentuk bahasa pemrograman berbasis skrip seperti PHP, ASP, dan lain – lainnya.

Pemrograman berorientasi obyek adalah bentuk bahasa pemrograman yang berpusat pada 'obyek'. Obyek (yang dibentuk dari sebuah class) ini memiliki karakterisik tertentu (Rosenschein, 2012), yaitu:

• Dapat memiliki sebuah kondisi atau state yang dinyatakan dengan nilai – nilai yang dimiliki oleh atributnya.

• Dapat melakukan suatu aksi atau metode (method) pada kondisi – kondisi ini.

• Dapat berkomunikasi dengan obyek lainnya dengan cara pertukaran pesan (message passing).

(47)

Dalam dunia Open Source, bahasa pemrograman berorientasi obyek yang paling populer adalah Java. Bahasa pemrograman ini dikembangkan pada tahun 1990an oleh James Gosling dari perusahaan Sun Microsystem (http://www.freejavaguide.com/history.html). Perusahaan Sun Microsystem sekarang ini telah menjadikan bagian dari perusahaan Oracle.

3.2 Proyek Perangkat Lunak Open Source

Open Source merupakan suatu metode pengembangan perangkat lunak yang dilakukan secara bersama – sama oleh banyak orang yang tersebar di berbagai penjuru dunia dimana setiap orang berhak untuk mengunduh, mengembangkan, dan memodifikasi kode sumber untuk kepentingan bersama. Pelopor dari metode ini adalah Richard Stallman dalam tulisannya “Why Software Should be Free” (Stallman, 1992) dan Eric Raymond dengan tulisannya “The Cathedral and the Bazaar” (Raymond, 2000) pada awal tahun 1990an. Metode ini kemudian berkembang menjadi suatu gerakan yang menghasilkan aplikasi – aplikasi besar seperti Apache Web Server, Sistem Operasi Linux dengan segala distro-nya (Debian, FreeBSD, OpenBSD dan lain – lain), browser web Firefox dan lain – lain.

Metode pengembangan perangkat lunak secara Open Source memiliki beberapa karakteristik yang berbeda bila dibandingkan dengan metode pengembangan perangkat lunak secara tertutup (closed source) atau komersial (proprietary). Beberapa karakteristik penting dari metode pengembangan secara Open Source adalah:

(48)

memiliki waktu keanggotaan yang terbatas (Christley & Madey, 2007).

• Pengembang (developer) mendaftar atau direkrut secara sukarela. Seiring dengan perkembangannya, baik komunitas dan juga sistem aplikasi Open Source mengalami perubahan atau ber-evolusi. Komunitas suatu aplikasi Open Source akan terstruktur dengan pusatnya adalah beberapa developer inti (core developers) yang dikelilingi oleh banyak pengembang tambahan (periphery developers), dan juga lebih banyak lagi pelapor bug (bug reporter) yang oleh beberapa studi dikatatakan berbentuk lapisan bawang (Crowston et al, 2006). Pengembangan dilakukan secara kolaborasi dengan menggunakan media penghubung yaitu Internet.

• Dalam proses pengembangan perangkat lunak secara Open Source akan mengikuti beberapa tahapan. Lehman dalam papernya berjudul “Laws of Software Evolution Revisited” mengidentifikasikan 8 tahapan penting pengembangan software secara Open Source mulai dari tingkat yang paling sederhana sampai yang paling kompleks dimana inisiator proyek pada fase ini sudah tidak mampu lagi untuk mengelola proyeknya sendiri dan membutuhkan orang lain dan komunitas (Lehman, 1996).

(49)

– proyek Open Source sekarang ini cukup banyak misalnya sourceforge.net, freshmeat.net, launchpad.net, code.google.com dan lain – lain

Di sisi aplikasinya, sistem aplikasi Open Source akan berkembang dari suatu sistem yang dikembangkan oleh satu orang saja yang kemudian berkembang menjadi aplikasi yang besar dan kompleks. Suatu studi bahkan menekankan bahwa salah satu kunci utama keberhasilan suatu proyek Open Source adalah modularitas (DeKoenigsberg, 2008). Agar suatu proyek Open Source agar terus menerus berkembang maka proyek ini harus senantiasa bisa menarik banyak kontributor pemula yang nantinya bakal menjadi kandidat dari pengembang utama (core developer). Dengan sifat komunitas yang membolehkan seseorang datang dan pergi kapan saja, maka akan sangat mungkin bagi seorang pengembang (baik yang utama dan tambahan) untuk meninggalkan komunitas karena berbagai sebab (misalnya sudah kurang minat, mengembangkan proyek Open Source baru, dan lain – lain), maka kesinambungan dari jumlah orang yang baru harus senantiasa dipelihara agar proyek Open Source ini tetap berkembang.

(50)

mempelajari siklus hidup proyek – proyek Open Source untuk mengetahui pola penggunaan kembali (von Krogh et al, 2005) (Twindale & Nichols, 2005), dan evolusinya itu sendiri (Alsmadi & Magel, 2006).

Meskipun terdapat beberapa aplikasi Open Source yang telah berhasil dan populer, lebih banyak lagi yang tidak berkembang dan gagal yang dikarenakan berbagai macam hal. Beberapa studi telah mengidentifikasikan beberapa kelemahan metode pengembangan ini misalnya jumlah developer yang masih sedikit, pola pengembangan aplikasi yang masih tidak terstruktur (ad-hoc), dan juga dibutuhkan kemampuan pemrograman yang cukup tinggi bagi seseorang untuk dapat berkontribusi pada suatu pengembangan aplikasi Open Source. Untuk itu kiat – kiat ataupun strategi – strategi perlu ditemukan dan kemudian diterapkan bagi seorang calon inisiator proyek Open Source agar proyeknya dapat berhasil. Studi oleh Stewart juga menunjukkan bahwa apabila suatu perangkat lunak yang dikembangkan secara Open Source tidak dikelola secara aktif akan menjadi semakin kompleks (Stewart et al, 2005).

3.3 Metrics Perangkat Lunak (Software Metrics)

Software Metrics didefinisikan sebagai sebuah nilai yang diekspresikan dalam unit yang berhubungan dengan perangkat lunak (Meyer et al, 2009). Software metrics berguna untuk mengindikasikan bagaimana keadaan dari sebuah sistem perangkat lunak dan juga memungkinkan perbandingan dan perkiraan tentang apa yang telah dicapai oleh sebuah sistem perangkat lunak. Beberapa kategori soft-ware metrics yaitu:

(51)

• Metrics yang berhubungan dengan kualitas / kompleksitas. Contohnya adalah Cyclomatic Complexity, jumlah state, jumlah bug setiap LOC, Co-upling metrics, dan Inheritance metrics.

• Metrics yang berhubungan dengan proses. Contohnya Failed Builds, De-fect per Hour, Requirement Changes, Programming Time, dan Patches af-ter Release.

Dalam dunia pengukuran perangkat lunak atau software metrics, terdapat be-berapa perintis yang karyanya sangat berpengaruh seperti McCabe dan Chidamber – Kemerer. McCabe dalam papernya yang berjudul "A Complexity Measure" memperkenalkan sebuah metrics yang mengukur tingkat kompleksitas dari sebuah program yang kemudian dinamakan McCabe's Cyclomatic Complexity (McCabe, 1976). Metrics ini merupakan metrics kompleksitas yang paling banyak dipakai oleh banyak peneliti sampai sekarang. Metrics untuk perangkat lunak yang bero-rientasi obyek pertama kali diperkenalkan oleh Chidamber dan Kemerer (Chidam-ber & Kemerer, 1994). Metrics – metrics tersebut adalah:

1. Weighted Method Per Class (WMC): pengukuran kompleksitas dari class berdasarkan jumlah methods dalam class tersebut.

2. Depth of Inheritance Tree (DIT): panjang maksimum dari sebuah node ke root dalam sebuah pohon pewarisan.

3. Number of Children (NOC): jumlah subclass langsung dari sebuah class dalam suatu hirarki.

4. Coupling Between Object Classes (CBO): jumlah dari class – class lain yang terhubung dengan sebuah class.

5. Response For a Class (RFC): jumlah absolut dari response set dari se-buah class.

(52)

LCOM2, LCOM3, dan akhirnya versi terbaru yang dipergunakan di penelitian doktoral in adalah LCOM4.

Penelitian di bidang pengukuran perangkat lunak terus berkembang sampai dengan sekarang. Jumlah metrics perangkat lunak terus bertambah untuk menja-wab tantangan perkembangan perangkat lunak itu sendiri yang semakin besar dan kompleks dengan segala dinamikanya. Secara keseluruhan sekarang ini terdapat lebih dari 200 Software Metrics dengan tujuan pengukuran yang berbeda beda (Meyer et al, 2009).

3.4 Framework Perangkat Lunak (SoftwareFramework)

Sofware Framework adalah sebuah arsitektur mini dari perangkat lunak yang dibuat untuk dipergunakan kembali melalui hot spot dan hook (Aversano et al, 2007) . Software Framework menyediakan sebuah infrastruktur inti dalam pembuatan proyek perangkat lunak yang dibutuhkan seorang programer. Software Framework ini lebih besar, lebih konkrit, dan lebih spesifik dibandingkan dengan Software Design Pattern, namun lebih kecil dibandingkan dengan Software Architecture. Beberapa contoh dari kerangka kerja perangkat lunak adalah .NET Framework, Java 2 Enterprise Edition, PRADO, jHotDraws, dan lain – lain. Software Framework terdiri dari 2 komponen utama yaitu Software Component dan Software Design Pattern.

3.4.1 Komponen Perangkat Lunak (Software Component)

Software Component didefinisikan sebagai sebuah unit fungsionalitas dalam bentuk paket dan biasanya dipergunakan sebagai black box (struktur internal dari programnya tidak perlu diketahui). Komponen perangkat lunak terdiri dari koleksi kelas – kelas abstrak and kelas – kelas antarmuka. Koneksi ke kelas – kelas abstrak dan kelas – kelas antarmuka ini disebut sebagai hot spot atau hook.

(53)

dengan melihat pada karakteristik tingkat lanjut dari pemrograman berorientasi obyek, yaitu:

• Kelas – kelas abstrak (abstract classes): templat dari sebuah kelas yang harus diturunkan dan tidak dapat dibuat obyeknya. Sebuah kelas abstrak minimal memiliki sebuah metode abstrak (metode tanpa implementasi).

• Kelas – kelas antarmuka (interfaces): kelas – kelas khusus yang semua metodenya abstrak (tanpa implementasi. Sebuah kelas buataan pengguna bisa ber-antarmuka dengan satu atau lebih kelas – kelas antarmuka.

3.4.2 Pola Desain Perangkat Lunak (Software Design Pattern)

Design Pattern didefinisikan sebagai sebuah gambaran dari permasalahan yang berulang dan inti dari solusi yang memungkinkan. Pola desain dibutuhkan untuk menggunakan kembali pengetahuan desain, membangun terminologi yang seragam, dan menyediakan sudut pandang yang lebih tinggi yang memungkinkan untuk tidak memikirkan detil desain terlalu cepat. Pola desain ini dicetuskan pertama kali oleh Christopher Alexander di tahun 1970an dalam tulisannya yang berjudul “The Timeless Way of Building Pattern Language: Towns, Building, Constructions”, dan kemudian diformulasikan dengan lebih detil oleh Gang of Four (GoF) dalam buku “Design Pattern: Elements of Reusable Object – Oriented Software” di tahun 1995 yang mengkatalog sebanyak 23 design pattern dengan format yang terstruktur. Banyak peneliti – peneliti yang lain kemudian mengembangkan lebih lanjut dalam pola desain – pola desain yang lain (Blank, 2008). Pola desain dikategorikan menjadi 3 jenis yaitu:

• Creational Patterns: berhubungan dengan inisialisasi dan konfigurasi obyek dan kelas, sebagai contoh adalah Singleton yang membatasi pembuatan obyek dari sebuah kelas hanya boleh ada satu buah saja. Contoh lainnya misalnya Abstract Factory, Builder, Factory Method, dan Prototype.

(54)

dan implementasi dari kelas. Contohnya adalah Adapter, Bridge, Composite, Decorator, Facade, Flyweight, dan Proxy.

• Behavioural Patterns: berhubungan dengan interaksi dinamis diantara kelompok kelas dan obyek. Contohnya adalah Chain of Responsibility, Command, Iterator, Intepreter, Mediator, Momento, Observer, State, Strategy, Template Method, dan Visitor.

Beberapa studi telah mempelajari penerapan pola desain di proyek – proyek Open Source. Hahsler dalam studinya mencoba mengindetifikasikan adanya pola desain dalam sekita 1000 proyek Open Source dengan mempelajari informasi dari kontrol versi dan berbagai karakteristik dari proyek – proyek Open Source (Hahs-ler, 2005). Penelitian tersebut menemukan bahwa pola desain Singleton adalah yang paling banyak dipergunakan, dan jumlah developer yang menggunakan ma-sih sangat sedikit namun merupakan pengembang yang sangat aktif. Studi yang lainnya antara lain oleh Stewart yang mempelajari pola pengembangan dari pro-yek – propro-yek Open Source yang berfokus pada tingkat kompleksitasnya (Stewart, 2005).

3.5 Datamining Association Rule