1

PREDIKSI UMUR BUG DALAM POYEK PENGEMBANGAN PERANGKAT LUNAK

Median Yuli Hartanto1, Daniel Oranova S 2, Sarwosri3

1,2,3 Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember Kampus ITS Sukolilo Surabaya, 60111, Indonesia

1median@cs.its.ac.id, 2daniel@if.its.ac.id, 3sri@cs.its.ac.id

Abstrak Dalam manajemen proyek perangkat lunak, salah satu hal yang menjadi masalah adalah penjadwalan. Penjadwalan dibutuhkan proyek perangkat lunak agar proyek perangkat lunak dapat berjalan baik sesuai perencanaan. Namun ketika proyek memasuki tahap pemeliharaan, terdapat masalah baru di dalam penjadwalan tersebut. Penjadwalan disesuaikan dengan waktu pengerjaan perbaikan suatu bug. Ketika suatu bug ditemukan, maka tim pengembangpun memperbarui jadwal kerjanya disesuaikan waktu perbaikan bug tersebut. Jadwal kerja yang disusun oleh tim pengembang dengan tujuan agar pengerjaan proyek dapat efektif dan efisien. Namun tujuan itu menjadi tidak berlaku saat jadwal yang disusun tidak benar. Salah satu masalah yang muncul adalah kesalahan menentukan waktu perbaikan suatu bug. Pada tugas akhir ini akan dibangun suatu perangkat lunak yang dapat memberikan rekomendasi umur dari bug. Aplikasi ini akan dibangun dengan menggunkan teknik-teknik penggalian data. Model prediksi yang dibangun didasarkan kepada data bug yang pernah terjadi sebelumnya pada proyek perangkat lunak yang tertentu.Untuk dapat memberikan rekomendasi umur bug, pertama yang dilakukan aplikasi adalah mengambil data secara langsung dari repositori bugzilla. Dari data yang didapatkan disaring untuk mendapatkan bug ynag dinyatakan telas terselesaikan atau telah ditutup kasusnya. Setelah itu, aplikasi menyimpan data tersebut ke dalam sebuah file ARFF. Dari file ARFF tersebut, Aplikasi melakukan proses penggalian data yang terdiri atas proses filterisasi dan klasifikasi. Proses penggalian data menghasilkan model umur bug. Model tersebut yang digunakan untuk memberikan rekomendasi umur bug atas data bug baru yang dimasukkan oleh user. Aplikasi ini menggunakan dataset yang berasal dari repositori bugzilla. Data tersebut diolah menggunakan lima metode klasifikasi yaitu Zero R, One R, C4.5, Naive Bayes dan Logistic Regresi. Untuk melakukan metode-metode klasifikasi tersebut, aplikasi ini menggunakan weka API.Rekomendasi yang keluar berupa rekomendasi rentang waktu dengan satuan hari dan jam. Uji coba aplikasi ini dilakukan melalui beberapa skenario, yang mencerminkan fitur-fitur yang ada di aplikasi.Uji coba ini berhasil menggambarkan bahwa aplikasi ini telah mampu memberikan rekomendasi umur bug atas data yang dimasukkan user. Hal tersebut dapat mengurangi unsur subyektifitas dari user ketika memasukkan waktu pengerjaan suatu bug, sehingga penjadwalan proyek perangkat lunak lebih efektif dan efisien. Kata kunci: Bug, Bugzilla, Umur, Klasifikasi, ZeroR, OneR, J48, NaiveBayes, Logisticregression

1. PENDAHULUAN Proses pengembangan perangkat lunak secara umum dapat dibagi menjadi beberapa aktifitas, yaitu spesifikasi (specification), pengembangan (development), validasi (validation),evolusi (evolution).[1] Biasanya proses pengembangan perangkat lunak dimulai dari tahap spesifikasi kebutuhan sistem, yaitu aktifitas untuk menspesifikasikan layanan yang harus disediakan oleh sistem serta batasannya, baik dalam lingkungan pengembangan maupun operasional. Tahap selanjutnya adalah aktifitas pengembangan. Pada aktifitas pengembangan, sistem perangkat lunak mulai dibangun. Dalam aktifitas ini, pertama kali pengembang harus mengembangkan desain perangkat lunak. Setelah itu pengembang mengimplementasikan langsung dari desain tersebut hingga menghasilkan suatu perangkat lunak, baik berupa aplikasi dan dokumentasinya. Setelah perangkat lunak terbentuk, pengembang melakukan aktifitas

validasi. Validasi merupakan aktifitas yang dilakukan untuk memastikan perangkat lunak yang dibangun sesuai dengan tujuan awal pembangunan perangkat lunak. Dalam aktifitas ini perangkat lunak diperiksa apakah perangkat lunak yang dihasilkan sesuai dengan keinginan pelanggan yang memesannya. Aktifitas terakhir adalah evolusi. Aktifitas ini bertujuan untuk membuat perubahan pada perangkat lunak sehingga perangkat lunak tersebut sesuai dengan perubahan-perubahan yang terjadi di luar maupun di dalam sistem perangkat lunak tersebut. Dalam tahapan ini, perangkat lunak akan dirubah beberapa bagian untuk disesuaikan dengan perubahan yang terjadi sehingga perangkat lunak tersebut masih dapat digunakan dan difungsikan dengan baik. Salah satu aktifitas terpanjang dalam suatu pengembangan perangkat lunak adalah evolusi. Menurut Sommerville, evolusi merupakan aktifitas yang menghabiskan paling banyak dana dan usaha.

2

Pembangunan sistem perangkat lunak hanya memakan 25% dari total biaya yang dikeluarkan, 75%nya dikeluarkan untuk melakuakan evolusi sistemnya. Hal tersebut disebabkan aktifitas evolusi dilakukan setelah perangkat lunak dibuat hingga perangkat lunak sudah tidak lagi dipakai. Disana pihak pengembang dituntut untuk dapat menyelesaikan setiap kesalahan yang ada dalam perangkat lunak. Bagian-bagian yang harus diubah dapat diusulkan oleh tim pengembang maupun pemakai yang nantinya akan disetujui oleh pimpinan proyek.

Dalam SDLC (Software Development Life Cycle), aktifitas evolusi dilakukan dalam tahapan pemeliharaan (maintenance). Dalam aktifitas ini, pengembang dihadapkan pada banyak sekali masalah, terutama masalah untuk mengatur sumber daya. Mulai dari jumlah tim pengembang yang terbatas, dana yang terbatas, dan waktu yang diberikan untuk menyelesaikan suatu masalah terbatas. Maka dari itu pengembang meperlukan suatu tindakan yang efektif dan efisien yang dapat menyelesaikan permasalah tersebut, terutama untuk masalah bug. Untuk dapat melakukan tindakan yang efektif dan efisien diperluakan mekanisme manajemen, baik menajemen terhadap sumber daya maupun manajemen terhadap masalah yang ada. Karena masalah yang muncul pada tahap pemeliharaan adalah bug, maka diperlukan suatu sistem pelacak bug.

Salah satu contoh sistem pelacakan bug yang populer adalah bugzilla[8]. Sistem ini akan mencatat atribut bug yang ditemukan. Setelah itu juga ditentukan pula berapa lama cwaktu yang akan diberikan kepada salah seorang anggota tim pengembang untuk menyelesaikannya. Untuk menentukan waktu penyelesaian tersebut tim pengembang masih mengandalkan pengalaman manusia tanpa ada rekomendasi yang diberikan oleh sistem. Padahal, salah satu masalah yang paling krusial dalam sistem pelacakan bug adalah masalah penentuan waktu yang diberikan kepada tim pengembang untuk menyelesaikan suatu bug. Penentuan waktu tersebut sangat besar kaitannya dengan efisiensi kerja. Penentuan waktu ini akan sangat berpengaruh terhadap penentuan jadwal kerja bagi setiap anggota tim pengembang. Bila pengembang melakuakan kesalahan dalam penentuan waktu ini, maka jadwal kerja yang dibuat untuk masing-masing anggota tim pengembang akan berubah dan akan sangat berdampak terhapa jalannya proses pengembangan perangkat lunak. Oleh karena itu, sangat dibutuhkan penentuan waktu penyelesaian suatu bug yang tepat. Biasanya waktu yang dipelukan untuk menyelesaikan suatu bug disebut dengan umur bug.

Panjer pernah melakukan penelitian mengenai bagaimana memprediksi umur bug untuk dataset perangkat lunak eclipse dengan menggunakan pendekatan beberapa metode penggalian data. Dalam penelitian tersebut, hasil terbaik yang ditemukan adalah 34,9% untuk menemukan prediksi benar[3]. Dalam penelitian

tersebut, Panjer masih menggunakan aplikasi yant terpisah-pisah untuk mencari prediksi umur bug. Panjer menggunakan perkakas Weka untuk membantu menganalisa data, namun Panjer belum membuat aplikasi tersebut terintegrasi. Untuk itulah diperluakan suatu aplikasi untuk menghitung berapa waktu yang diperluakan untuk menyelesaikan suatu bug dalam suatu perangkat lunak. 2. DASAR TEORI

2.1. Bugzilla Bugzilla memiliki fungsi utama untuk melacak bug dan perubahan kode suatu perangkat lunak. Selain itu bugzilla juga dapat digunakan sebagai sarana komunikasi antar anggota tim pengembang. Bugzilla juga menyediakan fitur untuk mengelola jaminan kualitas (QA). Gambar 1 menjelaskan bagaimana suatu bug hidup dalam Bugzilla. Bug memiliki status-status yang menunjukkan bagaiman kondisi bug tersebut dalam proyek perangkat lunak. Setiap user memiliki hak masing-masing dalam menentukan status tiap bug. Seperti untuk menentukan apakah suatu bug sudah terverifikasi merupakan hal dari QA (Quality Assurence). Gambar 1 dapat digunakan untuk mendefinisikan umur bug. Menurut gambar tersebut umur bug adalah selisih waktu dari suatu bug memasuki tahap New dan tahap Resolved.[1]

Dalam Bugzilla, bug memiliki atribut-atribut yang berfungsi untuk mencatat spesifikasi dari bug tersebut. Atribut-atribut tersebut dapat digunakan untuk memihat catatan-catatan mengenai bug. Di dalam Bugzilla, but memiliki 20 atribut yang semestinya diisi oleh pelapor bug. Atribut-atribut tersebut antara lain, Product and Component, Status and Resolution, Assigned To, QA Contact, URL, Summary, Status Whiteboard, Keywords, Platform and OS, Version, Priority, Severity, Target, Reporter, CC list, Time Tracking, Attachments, Dependencies, Votes, Additional Comments. Setelah membahas sistem pelacakan bug, uraian ini akan membahas mengenai penggalian data.

Salah satu fasiltas yang disediakan Bugzilla adalah fasiltas transfer data melalui webservice. Bugzilla memiliki dua interface untuk pengaksesan data, yaitu XML-RPC dan JSON-RPC. Namun Bugzilla menyarankan menggunakan XML-RPC karena XML-RPC merupakan interface yang sudah stabil. Sedangkan JSON-RPC masih bersifat eksperimen.

3

Gambar 1 Alur hidup bug pada Bugzilla [4]

2.2. WEKA Salah unsur terpenting dalam pembuatan tugas akhir

ini adalah penggalian data. Penggalian data digunakan penulis untuk menemukan model dari umur bug dalam dataset yang digunakan. Untuk membuat implementasi dari penggalian data penulis membutuhkan banyak sekali sumber daya, mulai dari waktu, teknik, tenaga. Untuk itu dalam pembuatan tugas akhir ini akan menggunakan pustaka untuk melakukan penggalian data. Pustaka yang akan digunakan adalah Weka[5]. Weka merupakan kepanjangan dari Waikato Environment for Knowledge Analysis.

Seluruh metode klasifikasi pasti merupakan turunan dari kelas Classifier yang dapat diakses di weka.classifiers.Classifier. Kelas Classifier ini memiliki method-method dasar yang dibutuhkan, seperti method classifyInstance dengan parameter sebuah instance yang berfungsi untuk mendapatkan nilai prediksi kelas dari model yang telah dibangun. Ada juga method buildClassifier yang digunakan untuk membangun model dari suatu Instances atau dataset yang ada. Method setOption digunakan untuk mengatur option suatu metode dalam melakukan klasifikasi. Selain itu ada beberapa method lainnya. Aplikasi ini hanya akan menggunakan 5 kelas turunan dari Classifier yaitu, OneR, ZeroR, J48, NaiveBayes, dan Logistic.

2.3. ARFF

ARFF (Attribute-Relation File Format) adalah berkas teks berformat ASCII yang berisikan daftar satu set data atribut. Berkas ARFF dikembangkan oleh Machine Learning Project di Departemen Ilmu Komputer Universitas Waikato untuk digunakan dengan sebagai dataset Weka. Gambar 2 menunjukkan contoh dari isi berkas ARFF.

Gambar 2 Contoh Isi Berkas ARFF [2]

Sebuah berkas ARFF terdiri atas dua bagian yaitu Header dan Data. Header terdiri atas tiga informasi kunci yaitu nama dari relasi, daftar atribut dan tipe datanya. Gambar 2 setelah kata @relation weather menunjukkan salah satu contoh header pada berkas ARFF. Simbol “%” digunakan untuk menuliskan komentar. Kemudian, @relation <relation-name> digunakan untuk mendeklarasikan nama dari relasi dalam berkas tersebut, dimana <relation-name> berupa string. Format untuk @attribute adalah @attribute <attribute-name> <datatype>, dimana <attribute-name> adalah suatu string nama untuk atribut tersebut dan <datatype> merupakan salah satu dari tipe data yang didukung oleh Weka, yaitu numeric, nominal-specification, string, date . @attribute digunakan untuk mendeklarasikan nama atribut dan tipe datanya.

Untuk tipe data yang didukung oleh weka terdiri atas empat macam yaitu

1. Numeric digunakan untuk angka real dan integer. 2. Nominal-Specification digunakan untuk mebuat

suatu urutan nilai yang disusun sendiri oleh pengguna. Untuk menuliskannya dalam header, Nominal-specification ini ditulis dengan format {<nominal-name1>, <nominal-name2>, <nominal-name3>, ...}. Contohnya : @ATTRIBUTE class {Iris-setosa,Iris-versicolor,Iris-virginica}

3. String digunakan untuk data yang berupa tulisan string.

4

4. Date digunakan untuk data tanggal. Untuk menuliskannya, date ini menggunakan format @attribute <name> date [<date-format>], dimana [<date-format>] diisi dengan kombinasi dari "yyyy-MM-dd'T'HH:mm:ss”.

3. METODOLOGI

3.1. Arsitektur Sistem Gambar 3 menunjukkan arsitektur sistem yang

dipakai dalam aplikasi ini.

Gambar 3 Arsitektur Sistem Secara garis besar ada empat proses utama yang

dilakukan oleh aplikasi ini, yaitu 1. Proses pengambilan data dari repositori bugzilla

dan penyesuaian data. Proses pengambilan dilakukan dengan memanfaatkan fasilitas webservice. Penyesuaian dilakukan dengan memotong data XML yang berasal dari server kemudian disimpan dalam sebuah file ARFF.

2. Proses penggalian data untuk mendapatkan model umur bug. Proses ini dilakuakan dengan menggunakan metode pengglian data. Proses ini dimulai dengan melakukan filterisasi data dilanjutkan dengan klasifikasi. Filterisasi terdiri atas tiga teknik, yaitu string to nominal, discretize, dan remove. Klasifikasi menggunakan 5 metode, yaitu zeroR, oneR, C4.5, aiveBayes, dan Logistic regression.

3. Proses evaluasi model umur bug. Proses ini dilakukan dengan menggunakan metode statistika yaitu Kappa Statistika dan Prosentase Kebenaran Data Model.

4. Proses melakukan prediksi umur bug. Proses ini dilakukan dengan menginputkan data bug baru, kemudian aplikasi akan memberikan rekomendasi umur dari bug tersebut.

3.2. Analisa Perancangan Perangkat Lunak

Aplikasi ini memiliki 3 proses utama, yaitu 1. Pengambilan data dari repositori bugzilla.

Pengambilan data dilakukan dengan menggunakan fasilitas dari BugzillaAPI. Tidak semua atribut bug

disimpan, hanya atribut-atribut yang diperlukan yang diambil, yaitu assign to, qa contact, priority, severity, product, component, operating system, platform, target milistone,cc, dependent bug, keyword, resolution, creation time, last change time,dan comment. Tidak semua atribut tersebut disimpan secara langsung. Untuk atribut cc, dependent bug, dan keyword diambil berupa list atribut-atribut tersebut, namun program hanya akan menyimpan jumlah dari masing-masing atribut. Untuk creation time dan last change time disimpan selisih dari kedua waktu tersebut nama atribut, bug lifetime. Khusus untuk comment , data yang disimpan adalah rata-rata kata per kalimat. Data-data tersebut disimpan kedalam file dengan format ARFF. 2. Pemrosesan data bug dengan zeroR, oneR, naivebayes, c4.5, dan logistic regression hingga mendapatkan model prediksi umur bug.

Pemrosesan data bug dilakukan dengan beberapa metode, yaitu dengan zeroR, oneR, naivebayes, c4.5, dan logistic regression seperti. Masing-masing metode akan menghasilkan sebuah model prediksi umur bug. Bentuk model berbeda-beda untuk masing-masing prediksi, seperti model berupa decision tree untuk c4.5. Setelah data diolah dan mendapatkan suatu model, model disimpan ke dalam sebuah file yang memiliki ekstensi .model. Model tersebut disimpan agar nantinya tidak perlu lagi melakukan proses penggalian data ulang. Sehingga aplikasi cukup membaca file model untuk menentukan rekomendasi terhadap umur suatu bug. 3. Pengimplementasian dari model prediksi umur bug untuk mendapatkan prediksi umur bug dari inputan bug baru yang ada. Pengimplementasian dari model predisksi umur bug dilakukan dengan membaca file yang berisi model dari hasil langkah no 2. Setelah file tersebut dibaca, program meminta user untuk menuliskan atribut-atribut bug yang diperlukan model tersebut untuk memberikan rekomendasi. Setelah atribut-atribut diberikan, program akan menjalankan rumus ataupun decision tree yang disimpan untuk mendapatkan rekomendasi prediksi umur bug. 3.3. Aktor

Aplikasi ini memiliki 2 aktor yang memiliki hak dan wewenang masing-masing. Nama dan tugas dari kedua aktor tersebut dijelaskan pada tabel 1.

Tabel 1 Aktor Aplikasi No. Actor Deskripsi

1 Admin Admin merupakan orang yang bertugas memperbarui data bug dari aplikasi ini. Admin juga berhak untuk memilihkan model mana yang dapat digunakan oleh TimeTracker User.

5

2 TimeTracker User

TimeTracker merupakan orang yang berhak untuk menentukan berapa lama suatu bug diselesaikan. Dalam aplikasi ini, timetracker hanya dapat melihat hasil prediksi umur bug dari informasi bug yang telah dia masukkan.

3.4. Implementasi Proses Pengambilan Data Bug Proses ini dilakukan dengan memanfaatkan

webservice dari server bugzilla. Proses ini menggunakan mekanisme XML-RPC. Proses ini akan menggunakan alur sesuai dengan gambar 4.

Proses ini dimulai dengan admin memasukkan email dan sandi untuk masuk ke sistem repository bugzilla. Bila login atau authentifikasi diterima maka aplikasi akan melakuakan permintaan kepada webservice bugzilla berupa data bug dan data comment bug. Hal ini memang dilakukan terpisah karena struktur data dari webservice bugzilla memisahkan keduannya. Aplikasi ini akan meminta data bug sejumlah permintaan dari admin. Permintaan ke webservice dilakukan secara bertahap, 20 databug untuk tiap permintaan. Hal ini dilakukan untuk meminimalkan kehilangan data. Data kemudian disimpan ke dalam sebuah file ARFF.

Mulai

Melakukan Authentifikasi ke Sistem Bugzilla

Mengambil Data Detail Bug

Mengambil Data Comment Bug

Menyimpan ke File ARFF

File ARFF untuk data bug

Memasukkan username dan password

Berhasil Logintidak

Menghasilkan

Selesai

ya

Gambar 4 Flowchart pengambilan data bug

Proses pengambilan data bug melibatkan empat kelas dan satu kelas abstract. Proses pengambilan data bug ini terdapat Bugzilla API yang dimasukkan ke dalam dua kelas dan satu kelas abstract, yaitu

BugzillaGetCommentCall, BugzillaGetCall, dan BugzillaAbstractRPCCall. BugzillaGetCommentCall dan BugzillaGetCall merupakan turunan dari BugzillaAbstractRPCCall.

Untuk proses pengambilan data akan digunakan antar muka seperti yang terlihat pada gambar 5. Gambar tersebut menunjukkan bahwa admin harus memasukkan tiga atribut yaitu, email, sandi dan jumlah bug.

Proses ini membutuhkan data akun untuk masuk sistem bugzilla dan juga jumlah bug yang diinginkan sebagai data masukkan. Untuk data keluaran, proses ini menghasilkan sebuah data bug yang disimpan dalam sebuag file ARFF yang diberi nama data Mentah.arff yang disimpan dalam folder data.

3.5. Implementasi Proses Pembangunan Model

Umur Bug Proses ini merupakan proses untuk membuat model

dari umur bug. Proses ini sangat mentukan apakah rekomendasi yang dihasilkan oleh aplikasi ini perhitungan cukup valid atau tidak. Aplikasi ini memiliki dua tahap utama yaitu proses filterisasi dan

proses klasifikasi. Proses ini mengikuti flowchart yang ditunjukkan pada gambar 6.

Gambar 5 Antar muka untuk pengambilan data

Pertama kali, file ARFF diinisialisasi ke dalam aplikasi. Proses ini akan menghasilkan object instances. Instances inilah yang akan diolah melalui proses filterisasi untuk mempersiapkan data agar dapat diterima oleh masing-masing metode klasifikasi. Proses filterisasi ini terdiri atas tiga proses yaitu StringtoNominal, Discretize, dan Remove. Hasil dari filetrisasi tersebut disimpan ke dalam sebuah file ARFF. File inilah yang dijadikan dataset untuk proses klasifikasi. Proses klasifikasi dilakukan dengan menggunakan metode yang dipilih oleh admin. Proses ini menghasilkan model umur bug. Setelah model tersebut disimpan ke dalam sebuah file, tahap selanjutnya adalah melakukan evaluasi terhadap model yang dihasilkan. Ecaluasi terhadap model umur bug menggunkaan perhitungan statistika yaitu menghitung prosesntase kebenaran dan nilai Kappa

6

Statistic. Hasilnya ditampilkan sehingga dapat menjadi bahan acuan utuk admin.

Proses pembangunan model memiliki dua proses besar didalamnya yaitu proses klasifikasi dan proses filterisasi. Dalam aplikasi ini kedua fungsi tersebut merupakan tanggung jawab dari kelas Classifiers dan Filters.

Kelas Classifier bertanggung jawab melaksanakan proses klasifikasi. Kelas Classifiers memiliki turunan sebanyak lima kelas, dimana masing-masing kelas tersebut mengimplementasikan masing-masing metode klasifikasi yang bisa digunakan. Kelas-kelas tersebut adalah J48,Naivebayes, OneR, ZeroR, dan LogisticRegression. Setiap kelas Classifiers memiliki array of Filter yang berfungsi untuk melakukan proses filterisasi sesuai kebutuhan dari metode klasifikasi yang dipakai. Kelas Classifiers juga menangani masalah penyimpanan dan pemuatan ulang model. Selain itu Classifiers juga memiliki method untuk melakukan perhitungan prediksi umur bug sesuai dengan model yang dipilih.

Mulai

Inisialisasi DataSet

Preprocessing Data/Filterisasi

Klasifikasi Umur Bug

File Model Umur Bug

Selesai

Menghasilan

Memilih Metode Penggalian Data

Melakukan Permodelan lagi

tidak

ya

Menampilkan Hasil Evaluasi

Model

Melakukan Evaluasi Model

File ARFF data bug filtered

Gambar 6 Flowchart pembangunan model umur bug

Karena Classifiers kemungkinan besar akan mengalami proses penambahan metode maka diperlukan sebuah kelas untuk mempermudah programmer melakukan pemanggilan terhadap kelas ini. Hal tersebut diperlukan agar programmer tidak kesulitan untuk menambah metode baru. Oleh karena itu ditambahkan sebuah kelas dengan nama CreateClassifier yangberfungsi untuk membuat kelas Classifiers sesuai dengan metode yang diinginkan namun tidak perlu sampai mendeklarasikan kelas turunan dari Classifiers. Hal tersebut dimungkinkan karena ada sebuah factoryMethod didalam kelas tersebut.

Kelas Filter bertanggung jawab untuk melakukan proses filterisasi dataset. Kelas Filter merupakan kelas abstract. Filters memiliki tiga turunan yang masing-masing merupakan implementasi dari metode klasifikasi. Tiga kelas tersebut adalah StringAttributetoNominal, DiscretizeAttribute, dan RemoveAttribute.

Untuk menghubungkan kedua kelas tersebut dengan UI diperlukan sebuah kelas lagi. Kelas tersebut akan bertanggung jawab menerjemahkan perintah dari UI untuk melakukan sesuatu sekaligus menerjemahkan hasil dari kedua kelas itu utuk dapat ditampilkan pada UI. Kelas tersebut adalah UIAdminManager. Gambar 7 menujukkan diagram kelas untuk kelas tersebut. Karena UIAdmin menajer juga mengurusi masalah pengambilan data. Maka tanggung jawab kelas ini bertambah yaitu mengurusi masalah penjaga alur dalam pengambilan data seperti diterangkan pada subbab sebelumnya.

Proses ini membutuhkan data masukkan berupa file data bug dengan format ARFF. Selain itu, proses ini juga membutuhkan metode klasifikasi dan jumlah interval umur bug untuk mengatur keluaran dari proses ini. Keluaran untuk proses ini ada tiga yaitu file ARFF header, ARFF data bug yang telah difilterisasi, dan file model umur bug. Kedua file ARFF tersebut disimpan ke dalam folder filtered dan file model disimpan ke dalam folder model. File tersebut dibuat untuk masing-masing proses pembangunanan model.

Gambar 7 Diagram Kelas UIAdminManager

3.6. Implementasi Proses Prediksi Umur Bug Proses prediksi umur bug dilakukan setelah aplikasi

mendapatkan model umur bug atau dengan kata lain prediksi umur bug baru dapat dijalankan setelah kedua proses lainnya sudah pernah dijalankan. Proses ini digambarkan pada gambar 8.

Pertama kali aplikasi akan membuka project yang telah diset oleh admin. User hanya perlu memilih metode yang akan digunakan untuk melakukan rekomendasi umur bug. Aplikasi akan membuka model yang dipilh oleh user. User harus memasukkan informasi atribut-atribut bug. Aplikasi akan menyimpan data informasi tersebut ke dalam sebuah file ARFF. File tersebut akan

class UIAdminManager

UIAdminManager

~ classifierClass: weka1.Classifiers~ createclassy: CreateClassifier

+ classify(String, String) : String+ createNewProject(File, String) : void+ getDataBug(String, String, String, String) : void- makeDefaultHeader(String, String) : void+ saveModel(String, String) : String+ setProject(String) : void+ UIAdminManager()

7

digunakan sebagai data testing dalam membuat rekomendasi umur bug. Setelah rekomendasi umur bug didapatkan, rekomendasi tersebut ditampilkan kepada user.

Proses ini merupakan tanggung jawab dari kelas Classifiers dan turunannya. Kelas tersebut memiliki method untuk membuka file model(loadModel) dan menlakukan implementasi dari model yang disimpan(runClassify).

Untuk mengatur hubungan antara UI dengan kelas Classifiers pada proses ini, dibutuhkan sebuah kelas lagi. Kelas tersebut bertanggung jawab untuk menerjemahkan keinginan dari UI untuk melakukan sesuatu dan menerjemahakan keluaran dari proses pada kelas Classifiers. Kelas itu adalah UIUserManager. Gambar 10 menunjukkan diagram kelas dari kelas tersebut.

Pada proses ini aplikasi membutuhkan data masukkan berupa file model dan header. File model digunakan sebagai acuan pembuatan rekomendasi umur bug dan file header digunakan untuk membuat file testing. Keluaran proses ini adalah rekomendasi umur bug yang langsung ditampilkan dan file testingData.arff yang digunakan untuk menjembatani kekurangan weka dalam mengimplementasikan suatu model. File tersebut digunakan untuk menyimpan data yang dimasukkan oleh user melalui antarmuka proses ini. File testingData.arff disimpan dalm folder data.

Mulai

Membuka model

Memilih Metode yang digunakan

Membuka model yang dirujuk

Membuat file data testing

Menyisi atribut-atribut bug

Menghitung rekomendasi bug dari data testing melalui model

Menampilkan rekomendasi

bug

Selesai

Mengulangi proses untuk mendapatkan

rekomendasi lain

tidak

ya

Gambar 8 Flowchart proses prediksi umur bug

4. UJI COBA Uji coba dibagi menjadi 2 bagian yaitu uji coba

fungsionalitas dan uji coba non fungsionalitas. Uji coba

fungsionalitas meliputi semua kebutuhan fungsional pada aplikasi. Sedangkan uji coba non fungsionalitas dilakukan untuk melihat performa. 4.1. Uji Coba Fungsional 1. Proses pengambilan data bug

Uji coba ini bertujuan untuk menguji apakah implementasi untuk proses pengambilan bug berjalan sesuai dengan perencanaan dan berjalan baik atau tidak. Salah satu uji coba untuk proses ini adalah melakukan pengambilan data dengan memasukkan alamat email dan sandi yang valid. Penguji memasukkan alamat email median.xuser@gamail.com, sandi *************, dan jumlah data 100. Ujicoba untuk proses ini berjalan lancar dan berhasil. Gambar 9 menunjukkan keberhasilan dari ujicoba ini.

2. Proses pembangunan umur bug Uji coba ini bertujuan untuk menguji apakah

implementasi untuk proses pembangunan model bug berjalan sesuai dengan perencanaan dan berjalan baik atau tidak. Salah satu uji coba untuk proses ini adalah melakukan pembangunan model bug dengan menggunakan metode oneR dengan data mentah berjumlah 100 orang dan jumlah interval 7. Ujicoba untuk proses ini berjalan lancar dan berhasil. Gambar 10 menunjukkan keberhasilan dari ujicoba ini. Selain untuk metode OneR, uji coba untuk proses ini juga berhasil dilakukan untuk semua metode yang lain yaitu ZeroR, J48, Naivebayes dan Logistic regression.

3. Proses Prediksi umur bug Uji coba ini bertujuan untuk menguji apakah

implementasi untuk proses prediksi umur bug berjalan sesuai dengan perencanaan dan berjalan baik atau tidak. Salah satu uji coba untuk proses ini adalah melakukan pembangunan model bug dengan menggunakan metode oneR dan isian yang valid. Ujicoba untuk proses ini berjalan lancar dan berhasil. Gambar 11 menunjukkan keberhasilan dari ujicoba ini.

Gambar 9 Statistika data yang baru diambil dari

repositori bugzilla

8

Gambar 10 Hasil evaluasi untuk model OneR yang

ditampilkan pada aplikasi

Gambar 11 Aplikasi setelah menampilkan hasil

rekomendasi umur bug

4.2. Uji Coba Validitas Dalam uji coba validitas ini digunakan untuk menguji

aplikasi apakah telah memenuhi persyaratan kevalidan hasil aplikasi.Pengujian validitas hasil aplikasi ini menggunakan file ARFF dengan jumlah file bervariasi. Skenario pengunjiannya adalah dengan jalan membangun model umur kemudian mengujinya secara fold dengan perulangan 10 kali. Jumlah interval untuk umur bug menggunkan 7 buah interval. Pengunjian ini memanfaatkan Weka API pada kelas evaliation yang telah diimplementasikan pada aplikasi ini. Hasil pengujian ini terangkum pada tabel 2.

Tabel 2 Hasil Uji coba validitas Jumlah data Nama metode Hasil 9000 ZeroR CCI 1280 14.2222

% ICI 7720 85.7778 % KS -0.0008

OneR CCI 2619 29.1% ICI 6381 70.9% KS 0.1728

J48/C4.5 CCI 2914 32.3778 % ICI 6086 67.6222 % KS 0.2111

NaiveBayes CCI 3056 33.9556 % ICI 5944 66.0444 % KS 0.2295

LogisticRegression -

Tabel 2 berisi data hasil pengujian yang dilakukan terhadap model hasil dari proses di aplikasi ini. CCI merupakan Correctly Classified Instances atu dengan kata lain, data yang berhasil diklasifikasikan dengan benar. Kemudian ICI merupakan Incorrectly Classified Instances atau data yang belum berhasil diklasifikasikan dengan benar. Sedangkan KS adalah Kappa statistic, salah satu pengujian statistika. Untuk metode LogisticRegression, beberapa dataset menunjukkan bahwa metode ini tidak mendapatkan hasil. Hal tersebut terjadi karena komputer yang pakai untuk uji coba tidak dapat memenuhi permintaan memori yang diminta oleh aplikasi sehingga aplikasi mendadak berhenti beroperasi. 5. KESIMPULAN

Dari hasil pengamatan selama perancangan, implementasi, dan proses uji coba perangkat lunak yang dilakukan, penulis mengambil kesimpulan sebagai berikut:

1. Aplikasi yang dibuat dapat membaca data repositori dari Bugzilla kemudian merubahnya kedalam format ARFF dengan menggunakan mekanisme XMLRPC pada webservice Bugzilla.

2. Aplikasi yang dibuat sudah dapat memodelkan umur bug melalui penerapan beberapa teknik penggalian data dengan menggunakan Weka.

3. Aplikasi ini sudah dapat mengimplementasikan model umur bug yang ditemukan untuk mengembangkan aplikasi yang dapat memprediksi umur suatu bug.

4. Aplikasi ini telah mampu memberika rekomendasi umur bug yang dapat mengurangi unsur subyektifitas dari user TimeTracker dalam menentukan waktu penyelesaian suatu bug.

6. DAFTAR PUSTAKA [1] Sommerville, I.(2004). Software, 8th ed. Harlow, England:Pearson Education Ltd. [2] Witten, Ian H & Frank, Eibe.(2005).Data Mining: Practical Machine Learning Tools and Techniques, 2nd ed. USA: Elsevier Inc [3] Panjer, L.D. (2007). Predicting Eclipse Bug Lifetime. IEEE. [4] Bugzilla Team, 2010, The Bugzilla Guide - 3.6 Release, Mozilla Foundation, Mountain View, CA. [5] Weka 3 - Data Mining with Open Source Machine Learning Software in Java, (http://www.cs.waikato.ac.nz/ml/weka/index.html, diakses tanggal 06 April 2011)