KLASIFIKASI SEVERITY DARI BUG UNTUK PROYEK PERANGKAT LUNAK

KLASIFIKASI SEVERITY DARI BUG UNTUK PROYEK PERANGKAT LUNAK 1,2,3

Tegar Riyono Putra1, Daniel Oranova S 2, Umi Laili Yuhana3 Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember Kampus ITS Sukolilo Surabaya, 60111, Indonesia 1 [email protected], [email protected], [email protected]

Abstrak Manajemen bug merupakan salah satu bagian penting dalam proses pembangunan proyek perangkat lunak. Untuk memudahkan manajemen bug, banyak pengembang menggunakan Bugzilla sebagai kakas bantu pelacakan bug. Dalam aktivitas pelaporan bug baru, seorang pelapor harus memasukkan nilai dari atribut-atribut bug, yang salah satunya adalah atribut severity(tingkat keparahan). Penentuan maupun intepretasi nilai severity dapat berbeda-beda antar anggota tim pengembang, tergantung pada pengalaman (pemula atau berpengalaman), keahlian (novice atau ahli), dan informasi yang tersedia mengenai bug itu sendiri. Hal ini dapat menimbulkan kesalahan dalam mengelola bug, terutama dalam menentukan waktu yang dibutuhkan untuk penyelesaian suatu bug. Oleh karena itu diperlukan suatu kakas bantu yang dapat memberikan rekomendasi severity. Pada Tugas Akhir ini dibangun suatu perangkat lunak yang dapat memberikan rekomendasi severity dari bug secara otomatis kepada pelapor. Proses pemodelan klasifikasi dilakukan terhadap atribut deskripsi dari bug. Oleh karena itu, sistem ini dibangun menggunakan teknik-teknik penggalian data yang berbasis teks, antara lain tokenisasi, stop word removal, stemming, tf*idf, infogain dan RIPPER(Repeated Incremental Prunning to Produce Error Reduction). Model prediksi yang dibangun didasarkan pada data sejarah bug pada repositori Bugzilla. Dari uji coba pada 929 laporan bug dihasilkan tingkat akurasi sebesar 54,1%. Kata kunci: Bug, Bugzilla, Severity, Tf*idf, Infogain, RIPPER Atribut-atribut bug tersebut haruslah diisi dengan 1. PENDAHULUAN Rekayasa perangkat lunak adalah disiplin teknik nilai atau isian yang sesuai oleh pelapor. Namun disatu yang berhubungan dengan semua aspek dari proses sisi kolom severity menjadi suatu masalah jika produksi perangkat lunak. Rekayasa perangkat lunak dihadapkan pada beberapa hal. Yang pertama adalah jika pelapor mempunyai latar belakang yang beragam. diharuskan mengimplementasikan sebuah pendekatan Satu bug dilaporkan dengan nilai major oleh seorang yang sistematis dan terorganisir dalam kerja mereka tester dan nilai minor oleh tester yang lain. Tester dan menggunakan kakas dan teknik yang sesuai yang kurang berpengalaman menganggap bahwa bug berdasarkan masalah yang akan dipecahkan, batasantersebut tidak berdampak banyak terhadap batasan dan sumber yang tersedia[1]. Oleh karena itu, fungsionalitas perangkat lunak, sementara tester yang rancang bangun perangkat lunak dapat mencakup berpengalaman melihat ada beberapa fungsi perangkat penelitian, pengembangan baru, modifikasi, reuse, lunak yang tidak berjalan dengan baik. Masalah yang reengineering, pemeliharaan atau aktivitas lain yang lain adalah ketika pelapor dihadapakan pada waktu berdampak pada perangkat lunak. Secara garis besar, singkat sehingga tidak dapat melakukan pengecekan cakupan-cakupan di atas masuk kedalam daur hidup secara menyeluruh. Oleh karena itu diperlukan suatu perangkat lunak. Ada enam fase dalam daur hidup perangkat lunak yaitu analisis dan spesifikasi rekomendasi kepada pelapor secara otomatis agar dapat membantu dalam pemberian nilai severity yang sesuai. kebutuhan, perancangan, pemrograman, pengujian, dan Salah satu kakas yang dapat memberikan rekomendasi pemeliharaan. Diantara keenam fase tersebut fase severity kepada pelapor adalah SEVERIS. SEVERIS pemeliharaan mempunyai pengaruh yang paling besar adalah salah satu Sistem pelacakan bug yang digunakan karena 67% biaya dari keseluruhan daur hidup perangkat lunak ditujukan untuk pemeliharaan[2]. Oleh NASA dalam melakukan manajemen bug-nya[3]. SEVERIS menggunakan standart text mining dan karena itu diperlukan suatu sistem manajemen machine learning yang diujicobakan pada beberapa set pemeliharaan yang baik agar biaya yang dikeluarkan laporan bug dalam proses klasifikasi severity-nya. Studi dapat ditekan. kasusnya menggunakan data yang berasal dari NASA’s Sistem pelacakan bug adalah aplikasi perangkat Project and Issue Tracing System (PITS). Pada ujicoba lunak yang didesain untuk membantu penjaminan kualitas dan programmer untuk selalu memantau bug yang dilakukan terhadap 5 set data didapatkan bahwa SEVERIS adalah prediktor yang baik untuk masalah (fase pemeliharaan) dari perangkat lunak yang telah severity, mudah digunakan dan efisien. SEVERIS dilaporkan didalam kerja mereka. Bug yang ditemukan melakukan pelatihan pada rata-rata 775 laporan bug. oleh pengguna dapat dilaporkan secara langsung melalui sistem ini. Ada beberapa kolom/ field yang Dalam tugas akhir ini dibangun perangkat lunak yang harus diisi oleh pelapor, misalnya tingkat kerusakan dapat memberikan rekomendasi severity kepada bug/ severity, kelakukan kerusakan dari perangkat pelapor dengan menggunakan beberapa metode data lunak, cara mendapatkan bug, dan lainnya.

1

mining yang dapat ditentukan oleh pengguna. Pelatihan dilakukan pada 929 laporan bug. 2. DASAR TEORI 2.1. Bug Bug merupakan sesuatu yang seharusnya tidak dilakukan oleh perangkat lunak atau perangkat lunak yang tidak melakukan seperti yang seharusnya dilakukan[4]. Bug tersebut dibagi menjadi beberapa macam, yaitu - Arithmetic bugs Merupakan bug yang terjadi karena kesalahan aritmatika, contohnya ketika suatu bilangan dibagi 0. - Logic bugs Merupakan bug yang terjadi karen kesalahan logika kode program. Sebagai contoh adanya perulangan tek terbatas. - Syntax bugs Merupakan bug yang terjadi karena kesalahan penulisan kode program. - Resource bugs Bug yang terjadi karena sumber daya yang ada tidak dapat menginbangi kebutuhan yang dibutuhkan, seperti terjadinya kekurangan memory untuk buffering. - Multi-threading programming bugs Bug yang terjadi pada program yang berjalan secara multi-threading, contohnya terjadi deadlock. - Interfacing bugs Merupakan bug yang terjadi pada antar muka yang ada seperti pada API, pada penanganan perangkat keras, dan protokol yang digunakan. - Teamworking bugs Bug yang terjadi saat perangkat lunak dibangun dalam tim. Semakin besar tim yang membangun semakin besar pula kemungkinan terjadi bug. Semaikin besar perangkat lunak yang dibangun maka semakin besar pula kemungkinan munculnya bug. Selain itu juga dalam aktifitas evolusi, diperlukan mencatat perkembangan suatu bug. Catatan tersebut diperlukan agar nantinya tidak muncul bug-bug lain yang disebabkan adanya kesalahan dalam penanganan suatu bug. Untuk itulah perlu dikembangkan sebuah sistem untuk mencatat bug yang terjadi. Sistem tersebut disebut dengan sistem pelacakan bug. 2.2. Sistem Pelacakan Bug Merupakan perangkat lunak yang dirancang untuk membantu mancatat dan melacak bug perangkat lunak yang dilaporkan, baik oleh pengembang, penjamin kualitas, maupun anggota tim yang lain. Ada juga sistem pelacakan bug yang mengizinkan pengguna untuk melaporkan bug secara langsung. Salah satu komponen utama dari sebuah sistem pelacakan bug adalah basis data. Basis data digunakan untuk mencatat bug-bug yang ditemukan beserta atribut-atribut yang dimilikinya. Atribut-atribut tersebut antara lain tanggal ditemukannya bug, penemu bug, severity bug, dan lain sebagainya. Nantinya atribut-atribut ini digunakan untuk mengetahui sejarah suatu bug. Dalam

perkembangannya, sistem pelacakan bug sudah banyak digunakan dalam dunia pengembangan perangkat lunak, bahkan sistem ini diintegrasikan dengan sistem manajemen proyek. 2.3. Bugzilla Bugzilla adalah salah satu contoh dari sistem pelacakan bug. Sistem ini mengijinkan pengembang individu atau grup untuk mengawasi bug yang muncul di dalam produk mereka secara efektif. Bugzilla dapat digunakan untuk melacak bug dan perubahan kode, berkomunikasi dengan anggota tim, mengirim dan meninjau patches dan management quality assurance(QA). Informasi bug yang disimpan dapat dilihat pada tabel 1. Tabel 1 Atribut dari Bug Nama Atribut Deskripsi Deskripsi bug Atribut yang berisi uraian singkat dari suatu bug Status Atribut yang berisi status dari bug dalam suatu sistem manajemen bug Severity Atribut yang berisi tingkat keparahan dari bug Resolusi Atribut yang berisi resolusi yang dilakukan terhadap suatu bug Assigned_to Atribut yang berisi id pemrogram yang akan menyelesaikan bug Produk Atribut yang berisi nama produk dari suatu aplikasi dimana bug terjadi Komponen Atribut yang berisi nama komponen dari suatu produk Prioritas Atribut yang berisi tingkat prioritas dari suatu bug Versi Atribut yang berisi versi dari produk dimana bug terjadi Bug yang ada dalam Bugzilla memiliki siklus/ diagram alir yang menggambarkan status bug dari awal dilaporkan sampai bug tersebut diselesaikan. Alur hidup bug dimulai dari status unconfirmed sampai closed. Status unconfirmed merupakan status awal dari bug report ketika pertama kali dilaporkan yang menunjukkan bahwa bug report tersebut belum mendapat konfirmasi dari pihak supervisor/admin. Setelah diterima sebagai suatu bug report yang benar maka statusnya akan menjadi new. Status assigned menunjukkan bahwa bug report sudah ditugaskan kepada pihak developer sekaligus menunjukkan bahwa bug sedang diperbaiki oleh developer. Setelah diperbaiki maka statusnya menjadi resolved, kemudian akan berubah menjadi verified dan closed jika sudah diverifikasi dan dinyatakan selesai. Siklus hidup bug dalam Bugzilla dapat dilihat pada gambar 1.

2

Dalam tugas akhir ini akan digunakan beberapa metode penggalian data, yaitu Tokenization, stop word removal, stemming tf*idf, info gain dan RIPPER. Masing-masing metode tersebut digunakan untuk menemukan model dari data repositori bugzilla. Selanjutnya model tersebut dapat digunakan untuk memberikan rekomendasi severity dari bug kepada pelapor. Salah satu sistem sejenis yang juga memberikan rekomendasi severity serupa adalah Severis. 2.6. SEVERIS Di dalam suatu sistem misi yang kritis, seperti misimisi yang dibangun oleh NASA, sangatlah penting bagi test engineer untuk dapat mengenali severity dari tiap masalah yang mereka identifikasi selama proses testing. Pemberian severity yang tepat sangat penting untuk pengalokasian sumber yang sesuai dan penjadwalan aktifitas pemeliharaan serta testing tambahan. Sementara itu severity sangat dipengaruhi oleh tingkat pengalaman test engineer dan lama waktu yang dihabiskan dalam menangani tiap masalah. Oleh karena itu diperlukan suatu tools yang mampu memberikan rekomendasi severity dari bug agar bug report mempunyai nilai kebenaran yang berdasar jelas. Salah satu tools yang memenuhi kebutuhan tersebut adalah SEVERIS(SEVERity Issue assesment). SEVERIS menggunakan standart text mining dan machine learning yang diujicobakan pada satu set laporan bug. Studi kasusnya menggunakan data yang berasal dari NASA’s Project and Issue Tracing System (PITS). Pada ujicoba tersebut disimpulkan bahwa SEVERIS adalah prediktor yang baik untuk masalah severity, mudah digunakan dan efisien. Nasa menggunakan skala 1-5 untuk menilai severity dari suatu masalah, dari yang terburuk sampai yang teringan. Untuk masalah yang berkaitan dengan robotic dan human-rated missions digunakan skala yang berbeda. Tabel 3 menunjukkan klasfikasi severity untuk robotic missions dan human rated missions. Robotic missions menyangkut segala aspek yang berhubungan dengan tugas yang dilakukan oleh robot ,sedangkan human rated missions berhubungan dengan tugas yang dilakukan oleh manusia. Tabel 3 Severities untuk Robotic Missions dan Human Rated Mission Severities for robotic missions Severity 1: Prevent the accomplishment of an essential capability; or jeopardize safety, security, or other requirement designated critical. Severity 2: Adversely affect the accomplishment of an essential capability and no work-around solution is known; or adversely affect technical, cost or schedule risks to the project or life cycle support of the system, and no workaround solution is known. Severity 3: Adversely affect the accomplishment of an essential capability but a work-around solution is known; or adversely affect technical, cost, or schedule risks to the project or life cycle

Gambar 1 Siklus Hidup Bug pada Bugzilla Bug yang ada di dalam Bugzilla dapat diklasifikasikan severity-nya dengan menggunakan beberapa metode penggalian data. 2.4. Severity dari bug Severity dari suatu bug didefinisikan sebagai tingkat keparahan yang bisa diakibatkan oleh sebuah bug. Sistem manajemen bug Bugzilla memetakan severity menjadi 7 macam yang dapat dilihat pada tabel . Tabel 2 Macam Severity dari Bug Nama Deskripsi Severity Blocker Tidak ada uji coba lanjutan yang dapat dikerjakan. Critical Aplikasi berbenturan, terjadi kehilangan data. Major Banyak kehilangan fungsi. Normal Kehilangan fungsi yang bersesuaian. Minor Sedikit kehilangan fungsi. Trivial Perbaikan beberapa antar muka. Enhancement Permintaan untuk fitur baru atau beberapa pelengkap pada bagian yang dilaporkan 2.5. Penggalian Data Penggalian data atau data mining didefinisikan sebagai proses untuk menemukan pola pada data yang berjumlah sangat besar dan proses tersebut berjalan secara otomatis atau semi-otomatis[6]. Dari dataset yang ada, menggunakan metode-metode penggalian data, akan ditemukan model yang nantinya dapat digunakan untuk memprediksi sesuatu. Dataset tersebut terdiri atas beberapa atribut yang nantinya akan dicari komposisi dari masing-masing atribut tersebut kepada model yang dibuat.

3

word removal dan stemming), infogain dan JRIP(Java Repeated Incremental Prunning). 2.8. ARFF ARFF(Attribute Relation File Format) adalah suatu berkas teks ASCII yang berisikan sebuah daftar data yang berisikan satu set atribut. File ARFF dibagi menjadi 2 bagian, bagian Header Information dan Data Information. Header Information berisikan nama relasi, daftar atribut(kolom dari data) dan tipenya. Sedangkan Data Information berisikan data dari file berdasarkan kolom pada bagian Header Information. Contoh isi berkas Arff dapat dilihat pada gambar 2.

support of the system, but a work-around solution is known. Severity 4: Results in user/operator inconvenience but does not affect a required operational or mission essential capability; or results in inconvenience for development or pemeliharaan personnel, but does not affect the accomplishment of these responsibilities. Severity 5: Any other issues. Severities for human-rated missions Severity 1: A failure which could result in the loss of the human rated system, the loss of flight or ground personnel, or a permanently disabling personnel injury. Severity 1N: A failure which would otherwise be Severity 1 but where an established mission procedure precludes any operational scenario in which the problem might occur, or the number of detectable failures necessary to result in the problem exceeds requirements. Severity 2: A failure which could result in loss of critical mission support capability Severity 2N: A failure which would otherwise be Severity 2 but where an established mission procedure precludes any operational scenario in which the problem might occur or the number of detectable failures necessary to result in the problem exceeds requirements. Severity 3: A failure which is perceivable by an operator and is neither Severity 1 nor 2. Severity 4: A failure which is not perceivable by an operator and is neither Severity 1 nor 2, nor 3. Severity 5: A problem which is not a failure but needs to be corrected such as standards violations or pemeliharaan issues.

Gambar 2 Contoh Isi berkas ARFF normal[7] Selain bentuk normal, berkas Arff dapat juga direpresentasikan menjadi bentuk sparse. Dalam bentuk sparse, setiap data tidak diharuskan memiliki nilai dari tiap atributnya layaknya berkas Arff normal. Proses penulisan data dilakukan dengan menggunakan indeks dari dari atribut, kemudian diberi spasi sebelum dimasukkan nilai dari atribut tersebut. Contoh isi berkas Arff sparse dapat dilihat pada Gambar 3.

2.7. Weka Weka adalah perangkat lunak yang mempunyai banyak koleksi algoritma machine learning yang digunakan dalam proses data mining. Algoritma yang ada dapat diaplikasikan secara langsung pada set data atau dipanggil dari kode Java buatan sendiri. Weka menyediakan tools untuk pre-processing data, klasifikasi, regresi, clustering, association rules dan visualization. Selain itu, Weka juga dapat digunakan untuk membangun skema machine learning baru. Perangkat lunak dapat mengimplementasikan pustaka Weka melalui Weka API (Aplication Programming Interface) yang mencakup beberapa proses diantaranya membuat set data di memory, loading and sabing data, filtering, classifying, clustering, selecting attributes, visualization, dan serialization[7]. Dalam melakukan proses data mining, Weka menggunakan berkas bertipe ARFF dalam input file maupun output file-nya. Aplikasi yang dibangun menggunakan beberapa metode penggalian data yang diambil dari pustaka Weka, antara lain metode StringtoWordVector(mencakup proses tokenisasi, stop

Gambar 3 Contoh Isi Berkas Arff Sparse

4

pengguna. Pengguna berinteraksi dengan sistem, yang mempunyai peran dalam pengaturan model klasifikasi, meliputi pembuatan dan pengubahan model klasifikasi, sekaligus dapat melaporkan suatu bug dan mendapatkan rekomendasi. 3.4. Perancangan Model Klasifikasi Model klasifikasi dapat digunakan oleh kelas Classifier untuk melakukan klasifikasi severity dari suatu laporan bug. Untuk mendapatkan model klasifikasi tersebut, maka diperlukan suatu alur proses yang dapat mengubah data kasar laporan bug menjadi data yang dapat dimodelkan oleh kelas Classifier. Karena fitur laporan bug yang digunakan adalah deskripsi bug yang bertipe String, maka diperlukan beberapa metode text mining. Terdapat enam proses untuk menghasilkan model klasifikasi antara lain seleksi laporan bug, tokenisasi, stop word removal, stemming, pembobotan kata, perangkingan kata dan pelatihan model klasifikasi. Alur proses penggunaan metode text mining dapat dilihat pada gambar 5.

3. METODOLOGI 3.1. Arsitektur Sistem Gambar 4 menunjukkan arsitektur sistem yang dipakai dalam aplikasi ini. KLASIFIKASI SEVERITY DARI BUG UNTUK PROYEK PERANGKAT LUNAK

PENGAMBILAN DATA

Bugzilla Repository KONVERSI DATA MENJADI ARFF

PROSES PENGGALIAN DATA UNTUK PEMODELAN KLASIFIKASI BUG

Folder penyimpanan data set Pengguna KLASIFIKASI SEVERITY DARI BUG

BUG REPORT

PUSTAKA WEKA REKOMENDASI SEVERITY DARI BUG

Gambar 4 Arsitektur Sistem Gambar 4 menunjukkan arsitektur sistem yang dibangun. Proses dimulai dari tahap pengambilan data yang mencakup pengambilan data dari sistem manajemen bug yang masih berupa data kotor sesuai dengan API(Application Programming Intreface) yang disediakan Bugzilla. Tahap konversi data menjadi ARFF(Attribute Relation File Format) mencakup proses pengubahan data kasar menjadi data yang teratur agar dapat dibuka oleh aplikasi Weka maupun digunakan dalam tahap selanjutnya. Setelah itu dilanjutkan dengan proses penggalian data yang melibatkan pustaka Weka. Selanjutnya model yang dihasilkan akan disimpan dalam model basis data yang berbentuk kumpulan berkas ARFF. 3.2. Analisa Perancangan Perangkat Lunak Pada tugas akhir ini dibangun sebuah aplikasi yang dapat memberikan rekomendasi severity dari bug kepada pihak pelapor. Rekomendasi yang diberikan berdasarkan model yang telah dibangun dari data laporan bug yang lampau dari sistem manajemen bug. Laporan bug tersebut kemudian diolah dengan beberapa proses penggalian data seperti tokenization, stop word removal, stemming, tf*idf, infogain dan RIPPER(Repeated Incremental Prunning to Produce Error Reduction). Selain itu, perangkat lunak yang dibangun menyediakan fitur bagi pengguna untuk mengambil data laporan bug dari sistem manajemen bug agar model yang dihasilkan dapat selalu digunakan seiring dengan berkembangnya waktu. Proses pemodelan dilakukan dengan melakukan pembagian menjadi modul-modul proses agar data yang dihasilkan dari setiap proses dapat digunakan kembali dan dianalisis. Model yang dihasilkan disimpan dalam bentuk data set/ paket sehingga pengguna dapat memilih model klasifikasi yang diinginkan. 3.3. Aktor Dalam perancangan sistem aplikasi ini akan dijelaskan mengenai use case yang digunakan untuk memberikan gambaran yang lebih jelas mengenai fiturfitur perangkat lunak yang ada pada sistem. Pada use case diagram sistem ini terdapat satu aktor, yaitu

act Modelling Workflow Sistem Data Kasar Laporan Bug

Seleksi Laporan Bug

mulai

Tokenisasi

Stop Word Remov al

Model Klasifikasi

Stemming

selesai Pembobotan Kata

Pelatihan Model Klasifikasi

Perangkingan Kata

Gambar 5 Alur Proses Pemodelan Klasifikasi Severity 3.4.1. Seleksi laporan Bug Tujuan dari seleksi laporan bug adalah menghilangkan data laporan bug yang dianggap tidak valid dan tidak layak dijadikan data latih. Data-data tersebut dapat meliputi - Data yang nilai severity-nya tidak dibutuhkan Dalam pemodelan klasifikasi ini aplikasi tidak membutuhkan laporan bug yang mempunyai nilai severity blocker dikarenakan nilai blocker sudah tidak lagi dipakai dalam penggunaan bug. - Data yang mempunyai distribusi tidak merata Yang dimaksud dengan data yang tidak merata adalah adanya satu atau lebih laporan pada severity tertentu yang mempunyai jumlah yang relatif sangat besar sehingga dengan severity lainnya sehingga timbul suatu kesenjangan. Pada gambar 6 dapat dilihat contoh distribusi laporan bug yang tidak merata.

5

Setiap macam akhiran diasosiasikan dengan satu kondisi. Pada tahap awal sebuah kata dicari akhirannya dengan mencari potongan akhiran yang terpanjang yang sesuai dengan daftar akhiran. Kemudian dilakukan pengecekan kondisi sesuai dengan akhiran yang digunakan. Jika terpenuhi selanjutnya dilakukan proses transformasi sesuai dengan daftar aturan transformasi. IteratedLovins Stemmer dan SnowballStemmer merupakan bentuk turunan dari metode LovinsStemmer. Dari proses seleksi ini dihasilkan distribusi susunan kata dalam laporan bug. Contoh hasil proses seleksi laporan bug dapat dilihat pada gambar 7 dan 8.

Gambar 6 Contoh Distribusi Laporan Bug Data yang mengandung karakter selain huruf Karena proses pemodelan didasarkan pada kata yang ada pada deskripsi bug maka karakter huruf dan simbol tidak boleh disertakan. Contoh :  pm-app-amo24 constantly segfaulting  -moz-border-radius + overflow:hidden does not hide children (or shadows of children) at the rounded corners  Port Bug 227305 (Support drag-drop single message to desktop / file-system window)  jemalloc can be deadlock with fork(2)  Russian Holidays 2010-2020 Setelah data diseleksi maka dilakukan perubahan susunan laporan bug agar dapat dilakukan pembobotan. Pembobotan dilakukan terhadap kata dari suatu laporan, bukan bobot suatu laporan. Oleh karena itu, data laporan bug lama yang berupa text/ String harus dirubah menjadi bentuk representasi kata dengan menggunakan metode tokenisasi, stop word removal dan stemming. 3.4.2. Tokenisasi Tokenisasi adalah proses memecah suatu text/String menjadi kumpulan subString dengan menggunakan text/String pemisah tertentu. Ada dua macam kelas tokenisasi yang dapat digunakan, yaitu WordTokenizer dan AlphabeticTokenizer. WordTokenizer adalah kelas tokenisasi sederhana yang menggunakan kelas java.util.StringTokenizer untuk proses tokenisasinya, sedangkan AlphabeticTokenizer melakukan tokenisasi berdasarkan urutan alphabetic dari kata yang didapat. Aplikasi menggunakan String ' \r\n\t.,;:'"()?!' sebagai String pemisah dalam tokenisasi. 3.4.3. Stop Word Removal Stop Word Removal adalah proses menghilangkan kata-kata yang umum digunakan dan tidak mempunyai informasi yang berharga pada suatu konteks. Aplikasi menggunakan list stop words standar yang sudah disediakan oleh pustaka Weka. 3.4.4. Stemming Stemming adalah proses mengurangi kata yang berimbuhan atau kata turunan menjadi bentuk dasar. Contohnya kata ‘runs’, ‘ran’, ‘running’ adalah kata yang ditulis dari bentuk dasar yang sama yaitu ‘run’, oleh karena itu hanya perlu disimpan satu kali saja. Ada tiga kelas stemmer yang digunakan pada aplikasi yaitu LovinsStemmer, IteratedLovinsStemmer dan Snowball Stemmer. LovinsStemmer menggunakan 3 tahap dalam proses stemming, yaitu tahap pemotongan akhiran, pengecekan kondisi akhiran dan transformasi sisa kata. -

Gambar 7 Data Kasar Laporan Bug

Gambar 8 Rancangan Hasil Seleksi Laporan Bug 3.4.5. Perancangan Pembobotan Kata Setelah laporan bug diseleksi menjadi susunan kata, maka proses pembobotan dapat dilakukan. Pembobotan didasarkan pada metode pembobotan Tf*idf. Tf*idf yang merupakan kependekan dari ‘term frequency times inverse document frequency’ melakukan pembobotan berdasarkan frekuensi kata dalam suatu dokumen (laporan bug) dikalikan dengan persebarannya dalam kumpulan dokumen. Jika ada n buah dokumen dan di dokumen ke-j kata ke-i muncul sebanyak kij kali dari jumlah kata lij dan terdapat ni buah dokumen yang mengandung kata ke-i, maka nilai Tf*idf dari kata ke-i pada dokumen ke-j adalah Tf*idfij=kij/lij * log(n/ni)

6

71 71 108 108 log 2 − log 2 913 913 913 913 607 46 46 607 − log 2 − log 2 913 913 913 913 17 64 17 64 − log 2 − log 2 913 913 913 913 Jika nilai severity dihubungkan dengan satu kata (contohnya fennec) maka tabel datanya akan menjadi seperti pada tabel 5. Tabel 5 Asosiasi fennec dengan Severity Fennec Severity Tidak Critical Ada Normal Tidak Normal Tidak Critical Ada Normal Tidak Normal Ada Minor Tidak Minor Ada Trivial Ada Trivial Ada Enhancement Ada Enhancement Maka H(Severity|Fennec=Ada) diartikan sebagai nilai entropi Severity pada laporan bug yang mengandung kata fennec. Agar nilainya mewakili semua kemungkinan dari kata (Ada dan Tidak ada) maka harus dihitung nilai H(Y|X). Setelah menghitung nilai entropi kondisional dari Severity H(Severity|Kata), maka dapat ditentukan nilai infogain dari kata IG(Severity|Kata). Hasil dari proses perangkingan adalah susunan kata yang terurut berdasarkan nilai infogain dari besar ke kecil. Contoh rancangan hasil perangkingan dapat dilihat pada gambar.

Karena pembobotan dilakukan pada kata secara umum (bukan pembobotan kata tiap dokumen), maka diperlukan sedikit perubahan pada rumus Tf*idf. Nilai Tfi yang semula kij/lij dirubah menjadi Tfi(avg)=

k ia a =j l ia

ni

H 𝑆𝑒𝑣𝑒𝑟𝑖𝑡𝑦 = −

.

Setelah dilakukan pembobotan, susunan kata diurutkan dari bobot yang tertinggi ke yang terendah, kemudian diambil p persen dari keseluruhan kata yang akan digunakan untuk proses perangkingan. Contoh rancangan hasil pembobotan dapat dilihat pada gambar 9.

Gambar 9 Rancangan Hasil Pembobotan Kata 3.4.6. Perancangan Perangkingan Kata Setelah kata dibobotkan, selanjutnya dilakukan proses perangkingan kata. Tujuan dari perangkingan ini adalah untuk mendapatkan informasi tentang distribusi kata dalam kumpulan laporan bug terhadap severity. Metode perangkingan yang dipakai oleh aplikasi adalah InfoGain. Dimisalkan ada 913 laporan bug yang mempunyai komposisi severity seperti terlihat pada tabel 4. Tabel 4 Distribusi Laporan Bug Terhadap Severity Severity Jumlah Critical 71 Major 108 Normal 607 Minor 46 Trivial 17 Enhancement 64 Maka nilai entropi dari Severity adalah

Gambar 10 Rancangan Hasil Perangkingan Laporan Bug

7

3.4.7. Perancangan Pelatihan Model Klasifikasi Proses pelatihan model klasifikasi bertujuan untuk menghasilkan model yang nantinya digunakan untuk proses klasifikasi severity. Baik pelatihan(training) ataupun klasifikasi dilakukan oleh kelas Classifier. Metode pelatihan data yang digunakan adalah RIPPER yang merupakan kependekan dari ’Repeated Incremental Pruning to Produce Error Reduction’. Hasil keluaran dari proses pelatihan adalah kumpulan aturan yang yang akan digunakan dalam proses klasifikasi untuk menghasilkan rekomendasi severity. 4. UJI COBA Uji coba dilakukan terhadap 3 data set yang terdiri atas 42, 450 dan 929 buah laporan bug yang dilaporkan pada tahun 2010. Terhadap tiap data set dilakukan proses pemodelan dengan kriteria sebagai berikut - Seleksi laporan bug Huruf kecil : Ya Jumlah kemunculan minimum : 1 Jumlah maksimum per kelas : 1000 Metode tokenisasi : WordTokenizer Metode stemming : LovinsStemmer Normalisasi data per kelas : Ya Gunakan karakter huruf : Ya - Pembobotan laporan bug Jumlah maksimum kata per kelas : 50 % - Perangkingan laporan bug Jumlah maksimum kata : 50 % - Pelatihan laporan bug Gunakan pemangkasan : Tidak Cek Error Rate : Tidak Jumlah Optimasi : 2 Jumlah Folds : 3 Bobot minimum tiap laporan : 0 Setelah data set melalui proses perangkingan, dihasilkan sejumlah instance dan kata. Jumlah instance dan kata yang dihasilkan dari tiap data set dapat dilihat pada tabel 6. Tabel 6 Jumlah Instance dan Kata 3 Data Set Data Set 42 450 929 laporan laporan laporan Jumlah instance Jumlah kata

30

124

340

47

150

295

Data Set Jumlah aturan

Tabel 7 Jumlah aturan 3 Data Set 42 laporan 450 929 laporan laporan 17 61 56

4.2. Evaluasi Umum Pada Data Uji Proses pelatihan dilakukan secara penuh (full training set) dengan hasil evaluasi yang dapat dilihat pada tabel 8. Tabel 8 Evaluasi Umum 3 Data Set Data Set 42 laporan 450 laporan 929 laporan Correctly 26 103 185 Classified (86.6667 %) (83.0645 %) (54.4118 Instances %) Incorrectly 4 21 155 Classified (13.3333 %) (16.9355 %) (45.5882 Instances %) 4.3. Detil akurasi tiap kelas Proses pelatihan dilakukan terhadap kelas severity yang terdiri enam macam nilai (critical, major, normal, minor, trivial dan enhancement). Detil akurasi pemodelan tiap kelas untuk tiap data set dapat dilihat pada tabel 9. Tabel 9 Detil Akurasi Pelatihan Tiap Kelas Data Set

42 laporan

450 laporan

929 laporan

Precisi on 1 0,857 0,833 1 0,6 1 0,877 1 0,642 0,952 1 0,857 1 0,886 1 0,395 1 1 1 1 0,82

Recall

f-measure

class

1 1 1 1 0,6 0,5 0,867 0,278 1 0,909 0,955 1 0,773 0,831 0,164 1 0,339 0,244 1 0,466 0,514

1 0,923 0,909 1 0,6 0,667 0,858 0,435 0,782 0,93 0,977 0,923 0,872 0,815 0,282 0,566 0,506 0,393 1 0,787 0,73

Critical Major Normal Minor Trivial enhancement Bobot rata-rata Critical Major Normal Minor Trivial enhancement Bobot rata-rata Critical Major Normal Minor Trivial enhancement Bobot rata-rata

5. KESIMPULAN Dari hasil pengamatan selama perancangan, implementasi, dan proses uji coba perangkat lunak yang dilakukan, penulis mengambil kesimpulan sebagai berikut : a. Hasil pengunduhan laporan bug dari repositori Bugzilla dapat diubah menjadi bentuk Arff. b. Proses pelatihan laporan bug yang menggunakan metode RIPPER dapat menghasilkan model dengan tingkat akurasi yang baik (tingkat akurasi 83%) untuk data yang kecil meskipun hanya dilakukan terhadap atribut deskripsi/summary.

Proses pemodelan dilakukan terhadap keseluruhan laporan bug (full training set). Dengan menggunakan pilihan pelatihan yang sama menggunakan Weka, didapat hasil evaluasi meliputi aturan klasifikasi, evaluasi umum pada data uji, detil akurasi tiap kelas dan confusion matrix. 4.1. Aturan Klasifikasi Dari pelatihan yang dilakukan terhadap 3 data set dihasilkan sejumlah aturan. Jumlah aturan dari tiap data set dapat dilihat pada tabel 7.

8

c.

Aplikasi yang dibuat dalam Tugas Akhir ini telah dapat mengimplementasikan sebuah sistem yang mampu memberikan rekomendasi severity kepada pengguna. 6. DAFTAR PUSTAKA [1] Sommerville, Ian, 2007, Software Engineering (8th ed.), Pearson Education , Harlow, England. [2] Zelkowitz, M. V., Shaw, A. C., dan Gannon, J. D., 1979, Principles of Software Engineering and Design, Prentice-Hall, Inc., Englewood Cliffs, NJ. [3] Marcus, A., Menzies, T., 2008, Automated Severity Assessment of Software Defect Reports, Wayne State University, West Virginia University, Detroit. [4] Telles, Matt and Yuan Hsieh. The Science of Debugging. Scottsdale: Coriolis, 2001. [5] Bugzilla Team, 2010, The Bugzilla Guide - 3.6 Release, Mozilla Foundation, Mountain View, CA. [6] Witten, Ian H & Frank, Eibe.(2005). Data Mining: Practical Machine Learning Tools and Techniques, 2nd ed. USA: Elsevier Inc [7] Frank, E., Hall, M., Kirkby, R., et all, 2010, WEKA Manual for Version 3-7-3, University of Waikato, Hamilton, New Zealand.

9