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.
5. Emanuel A.W.R., Wardoyo R., Istiyanto J.E., Mustofa K., "Success Factors of OSS Projects from Sourceforge using Datamining Association
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.
12. Emanuel A.W.R., Istiyanto J.E., "analisis Awal Strategi Peningkatan Partisipasi Kontributor Pemula Pada Proyek - Proyek Open Source", Compile Jurnal Teknologi Komputer, Vol. 2 No. 1, Januari 2009, ISSN 1978-4678
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 &
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).
Meskipun proyek – proyek Open Source telah berkembang dengan baik, namun ternyata terdapat beberapa kelemahan yang perlu diwaspadai, baik dalam hal sistem perangkat lunak itu sendiri maupun di dalam komunitas. Dalam hal sistem perangkat lunaknya itu sendiri kelemahannya antara lain adalah lemahnya
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).
Beberapa studi telah menunjukkan solusi yang mungkin diterapkan untuk mengatasi masalah – masalah yang telah dikemukakan sebelumnya. Solusi yang pertama adalah pembuatan perangkat lunak yang memungkinan monitoring jarak jauh, monitoring aktifitas refaktoring, dan adanya umpan balik secara real-time kepada para developer (Raymond, 2000). Solusi lainnya yang ditawarkan adalah pengelolaan manajemen persyaratan yang lebih baik (Paech & Reuschenbach, 2006). Beberapa studi juga menunjukkan persyaratan agar suatu proyek berbasis Open Source agar berhasil antara lain teknologi yang dikembangkan memang dibutuhkan, persyaratannya bisa bertumbuh seiring dengan waktu, produk awal harus baik dan berarsitektur modular (DeKoegnigsberg, 2008) (Gurbani et al, 2006), memiliki programmer yang berpengalaman, menggunakan perangkat / metode yang tepat (Gurbani et al, 2005)(Lawrie & Gacek, 2002) dan menggabungkan teknik pengembangan yang baik di dunia Open Source dan dunia komersial (Mockus et al, 2000).
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 individual 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 perangkat 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).
Usaha untuk melakukan pengukuran tingkat kualitas dari proyek perangkat lu-nak Open Source di tingkat sistem juga banyak dilakukan. Huynh dan Cai meng-gunakan kerangka DSMs (Design Structure Matrices) untuk mengukur keselaras-an keselaras-antara modularitas kode sumber dengkeselaras-an modularitas desain (Huynh & Cai,
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.
Untuk menentukan tingkat modularitas dalam suatu sistem perangkat lunak berorientasi obyek, diperlukan tolok ukur secara kuantitatif. Beberapa studi sebelumnya hanya mengidentifikasikan modularitas sebagai suatu tingkatan kualitatif (Lawrie & Gacek, 2002) (Gurbani et al, 2006) (Dekoenigsberg, 2008) yang dapat dipakai untuk menunjukkan tingkat kualitas dari suatu perangkat lunak. Studi yang lain menunjukkan bahwa tingkat kualitas dari suatu software
ditentukan oleh faktor – faktor seperti : coupling yang rendah , cohesion yang tinggi dan ukurannya (size) yang akan menentukan tingkat kompleksitasnya (Lee et al, 2007) (Stewart et al, 2005). Bagaimana memformulasikan beberapa faktor – faktor diatas menjadi satu parameter dalam bentuk Software Metrics untuk menentukan tingkat modularitas suatu perangkat lunak secara kuantitatif tunggal belum pernah dilakukan. Di dalam penelitian ini diusulkan suatu Software Metrics – dinamakan Modularity Index - yang secara kuantitatif akan dapat memberikan suatu nilai tunggal tingkat modularitas dari suatu sistem perangkat lunak berorientasi obyek.
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).
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:
• Kode sumber (Source Code) yang dapat diunduh, dimodifikasi, dan dikembangkan oleh pengguna (Raymond, 2000). Pengguna yang sebelumnya hanya ditempatkan di sisi konsumen sekarang ditempatkan juga di sisi pengembang (developer). Para pengembang ini pada akhirnya akan membentuk kelompok yang disebut komunitas, yang pada proyek Open Source yang semakin kompleks, komunitas pengembangnya akan terstruktur menjadi beberapa posisi sosial yang telah diidentifikasikan
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).
• Tidak atau sedikit sekali mempergunakan metodologi formal (Christley & Madey, 2007). Fokus dari pengembangan secara kode terbuka hanya pada dua hal yaitu menambah fitur dan perbaikan terhadap bug yang dilaporkan. Selama proses pengembangan, proyek – proyek perangkat lunak berbasis kode terbuka menggunakan perangkat pendukung yang didesain khusus seperti perangkat pengelola versi secara bersamaan (concurrent) seperti CVS (Concurrent Versioning System) dan yang sejenisnya, perangkat untuk melaporkan kesalahan (bug reporting) yang jenisnya beragam seperti bugzilla di Mozilla, sarana komunikasi antar developer dan pengguna dilakukan dengan menggunakan mailing – list dan forum, sebuah situs untuk proyek tersebut juga diperlukan sebagai sarana bagi para user untuk mengunduh, menempatkan dokumentasi, pengumuman dan lain – lain. Situs portal yang dikhususkan untuk proyek
– 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.
Beberapa studi sebelumnya juga telah mencoba memahami kunci keberhasilan proyek – proyek Open Source dengan mencoba memahami proses kerjanya. Beberapa studi mempelajari kasus – kasus proyek Open Source besar yang dikategorikan berhasil seperti Debian GNU/Linux (Spaeth & Stuermer, 2007), FreeBSD (Dinh-Trong & Bieman, 2004), Apache (Mockus et al, 2000), OpenBSD (Li et al, 2005). Beberapa studi telah mencoba mencari keseragaman pola dengan mempelajari lebih dari satu proyek Open Source saja seperti Apache dan Mozilla (Mockus et al, 2002), 15 Proyek Open Source (von Krogh et al, 2005), dua proyek Open Source (Capiluppi & Ramil, 2004). Sementara studi yang lain mencoba menghubungkan pengembangan proyek Open Source dengan praktek rekayasa perangkat lunak modern seperti rekayasa persyaratan (Paech & Reuschenbach, 2006), kesalahan kode (Li et al, 2006), pola desain (Hahsler, 2005), model kehandalan (Zhou & Davis, 2005), tahapan pengembangan (Stewart et al, 2005) dan praktek kerja (Crowston et al, 2004). Beberapa juga telah
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:
• Metrics yang berhubungan dengan size (ukuran). Contohnya adalah LOC (Lines of Code), jumlah kelas atau berkas header, jumlah metode per kelas, jumlah atribut per kelas, ukuran kode yang terkompilasi, dan jejak memo-ri.
• 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.
6. Lack of Cohesion in Methods (LCOM): ukuran ketidaksatuan dari se-buah class. Metrics ini kemudian disempurnakan lagi menjadi metrics
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 (Software Framework)
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