BAB 2 KAJIAN PUSTAKA 2.1 Cacat Perangkat Lunak (Software Defect) Cacat perangkat lunak (software defect) didefinisikan sebagai cacat pada perangkat lunak seperti cacat pada dokumentasi, pada kode program, pada desain dan hal – hal lain yang menyebabkan kegagalan perangkat lunak. Cacat perangkat lunak dapat muncul pada berbagai tahap proses pengembangan perangkat lunak (Pressman, 2001). Cacat perangkat lunak merupakan faktor penting yang mempengaruhi kualitas perangkat lunak. Kualitas perangkat lunak dapat ditingkatkan dengan mencegah munculnya cacat perangkat lunak melalui perbaikan aksi yang mungkin menghasilkan cacat perangkat lunak pada proses pengembangan perangkat lunak (Boehm dan Basili, 2001). Teknik pencegahan cacat perangkat lunak pertama kali diusulkan oleh IBM corporation dan dapat digunakan untuk mencegah munculnya cacat perangkat lunak di tahap lanjut pada proses pengembangan perangkat lunak (Chang,2007). Setelah itu, muncul beberapa pendekatan untuk mencegah munculnya cacat perangkat lunak seperti causal analysis dan prediction model (Chang,2007).
2.1.1
Teknik Causal Analysis and Resolution (CAR) Teknik causal analysis and resolution (CAR) berisi dua tahap utama untuk
menentukan sebab – sebab cacat perangkat lunak, yaitu pemilihan cacat perangkat lunak dan analisa sebab – sebab dari cacat perangkat lunak. Pada pertemuan untuk analisa sebab – sebab dari cacat perangkat lunak, dilakukan brainstorming untuk mencari sebab munculnya cacat perangkat lunak. cacat perangkat lunak yang dianalisa adalah cacat perangkat lunak yang memiliki prioritas tinggi dengan parameter tingkat keparahan cacat perangkat lunak, kekerapan terjadinya cacat perangkat lunak dan kerugian yang ditimbulkan cacat perangkat lunak. Terdapat dua hal yang harus dipertimbangkan dalam melakukan analisa sebab cacat perangkat lunak, yaitu jumlah cacat perangkat lunak yang dilaporkan dan
5
banyaknya sebab yang menimbulkan cacat perangkat lunak. Jika banyaknya cacat perangkat lunak yang dilaporkan terlalu kecil, maka akan sulit menarik kesimpulan penyebab munculnya cacat perangkat lunak. Sedangkan apabila cacat perangkat lunak yang dilaporkan terlalu banyak, maka proses analisa akan sangat sulit dilakukan (Mahopatra dan Mohanty, 2001).
2.1.2
Teknik Software Defect Prediction Model Teknik software prediction model berusaha untuk menemukan sejumlah
pola cacat perangkat lunak yang dapat digunakan untuk memprediksi kemunculan cacat perangkat lunak di masa mendatang. Sebuah pola cacat perangkat lunak didefinisikan sebagai sekumpulan attribut yang dapat digunakan untuk mendeskripsikan dan memprediksikan kemunculan dari cacat perangkat lunak. Pola cacat perangkat lunak dapat diturunkan dengan menerapkan model statistik pada perangkat lunak yang mengandung cacat. Untuk menentukan apakah sebuah perangkat lunak mengandung cacat perangkat lunak, attribut – attribut dari dari perangkat lunak dibandingkan dengan pola cacat perangkat lunak. Attribut – attribuat yang digunakan untuk mengukur produk perangkat lunak antara lain ukuran, kompleksitas, usaha dan sejarah perubahan (Chang 2007).
2.2
Action Based Model Sebuah aksi (action) merupakan operasi dasar yang dilakukan pada saat
mengeksekusi sebuah langkah (step) pada sebuah proyek perangkat lunak. Sebuah tugas (task) dapat dianggap sebagai elemen dasar dari work breakdown structure (WBS) rencana proyek (Chang, 2008).
Untuk melaksanakan sebuah task,
serangkaian steps bisa dijadwalkan atau mengadaptasi dari modal proses yang ada. Pengembang bisa melaksanakan tasks berdasarkan steps yang dijadwalkan. Pada Gambar 2.1 ditunjukkan bagan work breakdown structure proyek perangkat lunak serta hubungan antara tasks dan actions, dimana sebuah proyek dipecah ke dalam beberapa work packages. Masing-masing work packages meliputi beberapa task. PA1 (prosses asset) dan PA2 menandakan dua modal proses yang bisa digunakan untuk melakukan task 1. PA1 terdapat beberapa steps seperti sa1 dan sa2 yang direncanakan untuk dijalankan. Ketika tidak ada modal 6
proses yang layak bisa diadaptasi untuk melaksanakan tasks, steps perlu dirancang, seperti sa4. Actions (a1-a6) adalah actions sebenarnya yang digunakan untuk menjalankan planned steps dari tasks. Tabel 2.1 adalah attribut utama yang digunakan untuk melakukan aksi.
Gambar 2.1 Work Breakdown Structure serta Hubungan Antara Task dan Performed Actions (Chang,2008)
Action state merepresentasikan hubungan antara aksi yang dilakukan (performed action) dengan perencanaan tugas (planned task), dimana sebuah aksi diartikan sebagai aksi terjadwal (Action State=0) jika aksi tersebut adalah melakukan langkah-langkah yang sudah dijadwalkan (planned step), dan diartikan sebagai tidak terjadwal jika sebaliknya. Action type merepresentasikan jenis pengoperasian, seperti pembuatan modifikasi, atau penghapusan modul. Jika aksi yang dilakukan adalah membuat modul baru. Jika aksi yang dilakukan adalah pembuatan modul baru maka nilai dari action state bernilai penambahan modul baru, misal penambahan menu pada aplikasi atau pembuatan stored procedure baru pada subsistem database. Action type bernilai modifikasi jika jenis aksi adalah memodifikasi modul yang sudah ada, misal desain antart muka perangkat lunak yang sudah dibuat namun kurang
7
sesuai dengan keinginan pengguna sehingga membutuhkan modifikasi untk menyesuaikan dengan keinginan pengguna. Action state akan benilai penghapusan modul jika aksi yang dilakukan adalah menghapus modul yang sudah ada, misal penghapusan stored procedure pada database karena dirasa stored procedure sudah dibutuhkan atau tidak digunakan lagi. Action complexity menggambarkan kompleksitas sebuah aksi, dan diperkirakan oleh developer sebelum melakukan aksi. Tinggi, menengah atau rendahnya tingkat kompleksitas dari suatu aksi semua tergantung dari perkiraan developer. Jika suatu aksi memang dianggap memiliki tingkat kesulitan yang tinggi maka nilai dari action complexity adalah high. Action complexity bernilai median jika aksi tersebut dipandang oleh developer tidak memiliki kompleksitas yang tinggi atau rendah jadi berada diantarnya sedangkan jika aksi yang dilakukan dirasa tidak mempunyai tingkat kesulitan yang cukup berarti maka action complexity akan bernilai low. Object type merepresentasikan jenis modul yang dilakukan oleh aksi, seperti dokumen, kode, basisdata, atau konfigurasi sistem. Nilai dari object type tergantung pada di modul mana aksi tersebut akan dilakukan, misal aksi yang akan dilakukan adalah mempelajari dokumentasi dari kebutuhan rekayasa perangkat lunak yang diperoleh dari pelanggan maka object type dapat bernilai dokumen. Effort expected
merepresentasikan usaha yang dilibatkan dalam
melakukan aksi, dan diperkirakan terlebih dahulu. Dalam pelaksaan aksi satuan effort effected yang digunakan adalah jam, yaitu banyakanya jam yang dibutuhkan untuk melaksanakan suatu aksi. Jika dimisalakan untuk membuat suatu modul dalam aplikasi dibutuhkan waktu 24 jam maka nilai dari effort effected adalah 24 jam. Action originator adalah orang yang berperan sehingga suatu aksi terjadi atau akan dilakukan. Pada perangkat lunak yang sudah dikirimkan ke pelanggan dan ketika masa implementasi ditemukan suatu cacat sehingga pelanggan tersebut melaporkan kepada pihak pengembang dan ditindaklanjuti dengan melakukan suatu aksi untuk memperbaiki cacat tersebut, dalam hal ini nilai dari action originator adalah customer. 8
Tabel 2.1 Attribut Utama dari Aksi (Chang, 2008) Attribut
Keterangan / Nilai
Action ID
ID dari aksi yang akan dilakukan
Action Description
Deskripsi dari aksi yang akan dilakukan
Action State
0: tidak terjadwal, 1: terjadwal
Action Date
Tanggal aksi dilakukan
Action Type
N: Membuat modul baru, M: Modifikasi, D: Penghapusan, A: Penambahan, -: None
Action Complexity
0: low, 5: median, 10: high
Object Type
0: none, 1:document, 2: Database, 3: Application, 4: System Configuration
Effort Expected
Banyaknya jam yang diharapkan untuk melaksanakan aksi
Effort Used
Banyaknya jam yang digunakan untuk melakukan aksi
Action Originator
0: none,1: customer, 2: user, 3: manager, 4: programmer
Action Target
0: none, 1: Requirement Development, 2: requirement development, 3: requirement development,, 4: Coding, 5:Testing, 6:Maintenance, 7:Support
Number of objects
Jumlah objek yang dioperasikan oleh aksi
Reaction ID
ID aksi yang menyebabkan aksi dilakukan
Task ID
ID unik dari tugas untuk melakukan aksi berdsarkan WBS
Action target adalah langkah
proses dimana aksi dilakukan, seperti
requirement development, design atau coding. Number of objects menunjukkan jumlah obyek yang dioperasikan oleh aksi. Jumlah obyek dalam hal ini sesuai dengan attribut object type, misal object type dari aksi yang dilakukan adalah database maka bisa diperkirakan objek yang terpengaruh adalah database itu sendiri, aplikasi dan dokumentasi, jika masing-masing dari objek yang terpengaruh hanya terdapat sebuah database, dokumentasi, aplikasi maka total dari number of object adalah 3. Task ID merepresentasikan ID tugas yang dilakukan oleh aksi.
9
Reaction ID adalah id aksi yang menyebabkan aksi lain dilakukan. Reaction ID hanya akan memiliki nilai jika aksi yang dilakukan disebabkan oleh aksi yang lain, sebaliknya jika aksi tersebut merupakan general aksi maka reaction id dapat bernilai kosong. Dalam prakteknya, eksekusi dari sebuah aksi bukanlah kejadian tunggal, dan dapat menyebebkan modul lain berubah. Contohnya, perubahan pada DB API (Database Application Interface) akan mengarah pada semua modul yang menggunakan API tersebut, dimana model ini mungkin dikembangkan oleh orang yang berbeda. Untuk merepresentasikan hubungan aksi, reaksi digunakan untuk menunjukkan bahwa aksi tersebut diakibatkan oleh aksi lain dan ditunjukkan oleh tindakan R yang mungkin menghasilkan kesalahan, dan mungkin dilaporkan oleh customer jika tidak dilakukan pada waktunya (modul tertentu tidak berubah ketika API yang digunakan telah dirubah). Aksi digunakan untuk menghilangkan kerusakan didefinisikan sebagai Aksi D. Aksi yang bukan R dan bukan D diartikan sebagai root aksi. Gambar 2.2 menunjukkan hubungan antara tindakan R dan D. Aksi a1, a2, a3, a4, a5 dan a6 adalah tindakan terjadwal, yang berarti bahwa tindakan tersebut memang diharapkan dan dapat dijadwalkan berdasar WBS, sedangkan tindakan tidak terjadwal adalah tindakan yang tidak bisa diperkirakan, seperti a21 (diakibatkan oleh kerusakan) dan a23 (diakibatkan oleh tindakan lain). Aksi a22 dilakukan untuk menangani kerusakan yang diakibatkan oleh a21, dan mengakibatkan aksi a24 dan a26 dalam dua tugas yang berbeda. Aksi a25 dapat berupa reaksi yang tidak dilakukan segera setelah a24 dan menghasilkan cacat yang harus ditangani oleh a25. Cacat dari sebuah aksi dapat tidak terdeteksi sampai produk dirilis, dan cacat itu dilaporkan oleh pelanggan, dan cacat yang dilaporkan bisa sulit untuk dilacak penyebabnya. Cacat yang dilaporkan lalu dianalisa dalam pertemuan causal analysis. .
10
Gambar 2.2 Hubungan Antara Satu Aksi dengan Aksi yang Lain pada Sebuah Proyek Perangkat Lunak (Chang, 2007)
Tabel 2.2 Attribut Utama dari Cacat Perangkat Lunak (Chang, 2007) Attribut
Keterangan / Nilai
Defect ID
ID unik dari cacat
Description
Deskripsi dari cacat yang dilaporkan
Action Generated
Aksi yang menyebabkan cacat
Action Detected
Aksi yang mendeteksi cacat
Action Removed
Aksi yang digunakan untuk membuang cacat
Severity
1: Exception, 2: Minor, 3: Average, 4: Major, 5: Critical
Object ID
Modul yang menyebabkan cacat
Cacat yang dilaporkan dapat ditulis menggunakan atribut yang ditunjukkan dalam Table 2.2 dimana action generated menunjukkan aksi mana yang menyebabkan cacat. Menentukan aksi aktual yang menyebabkan cacat tidak lah mudah ketika interval antara tanggal aksi dan cacat terdeteksi sangat lama. Stakeholder yang terkait dapat menganalisa action generated dari cacat yang dilaporkan. Action detected menunjukkan aksi yang dilakukan untuk mendeteksi cacat, seperti inspeksi atau ulasan pada proses pengembangan oleh pengembang. Action removed menunjukkan aksi mana yang dilakukan untuk menangani cacat yang dilaporkan. Severity menunjukkan tingkat keparahan cacat yang dilaporkan. Disamping atribut aksi dan cacat, atribut tugas, work package, dan proyek juga disediakan untuk mencatat proses perangkat lunak. Task ID aksi dapat digunakan
untuk
menghubungkan
tugas.
11
Task
progress
menunjukkan
perkembangan tugas, dan dapat diukur dengan membagi usaha nyata dalam semua aksi tugas yang dilakukan dengan usaha yang diharapkan. Task status menunjukkan status tugas, baik terbuka atau tertutup. Task effort estimated adalah usaha yang dilibatkan dalam melakukan tugas, seperti dipastikan dalam tahap perencanaan proyek.
2.3 Komponen Action Based Defect Predicition ABDP membangun model prediksi mengunakan data dari proyek yang sama berdasarkan pada identifikasi penyebab dari permasalahan untuk memprediksi aksi yang mungkin dikarenakan permasalahan yang sama, dimana model prediksi menjadi stabil ketika jumlah dari data yang terkumpul bertambah. Arsitektur dari ABDP ditunjukkan pada Gambar 2.3 yang meliput lima langkah yaitu definisi action definition, action submission, action prediction, data collection, data analysis.
Gambar 2.3 Arsitektur dari Komponen ABDP (Chang,2008)
12
Action definition digunakan untuk mendefinisikan sekumpulan fitur seperti yang ditunjukkan pada Tabel 2.1 untuk mendiskripsikan attribut dari aksi, seperti effort, action type / complexity, task, work package dan project. Sasaran utama dari action definition adalah untuk memperkecil penggunaan effort dan memperbesar proses dari aplikasi yang ada untuk koleksi data. Langkah kedua adalah action submission. ABDP komponen disajikan sebagai sebuah proses iterasi, dimana masing-masing action dilakukan proses prediksi
sebelum
dijalankan.
Action
submission
bisa
dicapai
dengan
menggunakan sebuah proses manajemen sistem dimana actor dapat memasukkan informasi dari aksi dan memperoleh hasil prediksi secepatnya. Action Prediction digunakan untuk memprediksi apakah action berikutnya akan menghasilkan masalah.
2.4 Atribut-Atribut Aksi (Action) Pada penelitan yang dilakukan oleh (Chang,2008) telah diperoleh sejumlah atribut yang mempengaruhi apakah sebuah aksi dapat mengakibatkan high defect atau low defect. Atribut-atribut tersebut diperoleh melalui proses pendefinisian aksi, pengumpulan data dan analisa data.
2.4.1
Definisi Aksi (Action) Tujuan utama dari definisi aksi adalah untuk mendefinisikan attribut -
attribut yang akan dikumpulkan dari catatan aksi dan laporan cacat pada proses pengembangan perangkat lunak. Attribut – attribut ini menjadi kandidat attribut yang digunakan untuk membangun model prediksi. Attribut – attribut dari cacat perangkat lunak dan aksi yang digunakan ditunjukkan pada Tabel 2.1 dan Tabel 2.2. Setiap aksi yang dilakukan untuk mencapai tujuan proyek dapat digunakan sebagai sumber untuk mengumpulkan data. Selain attribut yang didapatkan langsung dari catatan aksi pada proses pengembangan perangkat lunak dan laporan cacat perangkat lunak, dapat juga ditambahkan attribut yang relevan, seperti pengalaman dari orang – orang yang melaksanakan proses pengembangan perangkat lunak dan dukungan dari lingkungan (seperti dana) untuk melakukan aksi. 13
2.4.2
Pengumpulan Data Sebuah pelaksanaan aksi pada proses pengembangan perangkat lunak
dibagi menjadi lima tahap, yaitu tahap perencanaan aksi, prediksi, pelaksanaan kegiatan, pelaporan hasil kegiatan dan pelaporan cacat perangkat lunak. Gambar 2.4 menunjukkan tahap – tahap dalam melakukan sebuah aksi pada proses pengembangan perangkat lunak.
Perencanaan aksi
Prediksi
Pelaksanaan kegiatan
Laporan kegiatan
Catatan cacat perangkat lunak
Gambar 2.4 Tahap Pelaksanaan Aksi pada Proses Pengembangan Perangkat Lunak
Tahap – tahap pelaksanaan aksi tersebut akan didokumentasikan. Dokumentasi tersebut, terutama dokumen perencanaan aksi dan catatan cacat perangkat lunak digunakan sebagai sumber data untuk mendapatkan nilai attribut dari aksi dan cacat perangkat lunak yang digunakan untuk menyusun dataset untuk pembentukan model prediksi.
14
Pada Gambar 2.4 ditunjukkan bahwa tahap pertama dari pelaksanaan aksi adalah perencanaan kegiatan. Sebuah kegiatan harus direncanakan dahulu sehingga attribut – attibut kegiatannya diketahui. Mungkin tidak semua attribut dari kegiatan dapat diketahui saat tahap perencanaan aksi, namun sebagian besar attibut yang dibutuhkan untuk melakukan prediksi sudah dapat diketahui sebelum aksi dilaksanakan. Pada tahap perencanaan aksi, attribut – attribut dari aksi yang akan dilakukan ditentukan nilainya. Attribut – attribut yang ditentukan nilainya pada tahap perencanaan aksi adalah attribut yang terdapat pada Tabel 2.1 Attribut dari aksi yang akan dilakukan digunakan untuk melakukan proses prediksi apakah aksi tersebut akan menghasilkan high defect atau tidak. Setelah nilai attribut – attribut aksi diketahui, dilakukan proses prediksi untuk mengetahui apakah aksi tersebut beresiko menghasilkan high defect. Sebuah aksi dikatakan menghasilkan high defect jika menghasilkan defect dalam jumlah yang melebihi ambang batas (threshold) tertentu. Jika pada tahap prediksi sebuah aksi dianggap akan menghasilkan high defect, maka rencana aksi (attribut – attribut aksi) tersebut harus direvisi sedemikian hingga ketika dimasukkan pada tahap prediksi, model prediksi tidak menganggap aksi yang akan dilakukan tidak menghasilkan high defect lagi. Setelah tahap prediksi menganggap bahwa aksi yang akan dilakukan tidak menghasilkan high defect, dilakukan eksekusi aksi. Dari pelaksanaan aksi akan dihasilkan laporan aksi dan catatan cacat perangkat lunak yang dihasilkan aksi tersebut. Catatan cacat perangkat lunak yang dihasilkan digunakan untuk mengecek apakah prediksi yang telah dilakukan sebelumnya telah benar. Dengan kata lain, dari laporan cacat perangkat lunak dapat diuji akurasi dari tahap prediksi. Selain itu, laporan cacat perangkat lunak juga digunakan untuk membangun dataset yang digunakan untuk membuat model prediksi dan uji coba Tahap pelaporan cacat menangkap attribut - attibut dari cacat yang dihasilkan oleh aksi tertentu yang telah dilakukan pada proses pengembangan perangkat lunak. Pada laporan cacat, attribut – attribut yang dicatat adalah attribut yang dari cacat yang terdapat pada Tabel 2.2.
15
2.4.3
Analisis Data Analisis data dilakukan dengan menganalisa data aksi dan cacat yang telah
terkumpul. Analisa tersebut bertujuan untuk menghasilkan dataset yang digunakan untuk membangun model prediksi dan uji coba. Sehingga, tahap analisa data terdiri atas dua bagian, yaitu (i) tahap preprocessing data dan (ii) tahap pembuatan model prediksi. (i)
Tahap Preprocessing Data Data preprocessing mengubah data yang telah terkumpul pada tahap
pengumpulan data menjadi dataset yang digunakan untuk membangun model prediksi. Pada tahap ini, attribut – attribut dari action yang telah dilakukan beserta attribut – attribut dari cacat perangkat lunak yang telah terjadi digabung menjadi sebuah dataset. Selain attribut – attribut dari aksi dan cacat perangkat lunak yang telah didefinisikan sebelumnya, dapat pula ditambahkan attribut - attribut lain yang relevan atau attribut turunan. Karena data attribut aksi dan cacat perangkat lunak yang yang telah dikumpulkan pada tahap sebelumnya tersebar di beberapa bagian database atau tabel, maka data perlu ditransformasi menjadi sebuah tabel yang nantinya dapat diolah oleh algoritma yang menghasilkan model prediksi. Gambar 2.5 menunjukkan proses untuk menghasilkan dataset dari data aksi dan cacat perangkat lunak yang telah dikumpulkan sebelumnya. Pada Gambar 2.5 ditunjukkan bahwa attribut – attribut dari aksi dan cacat perangkat lunak yang telah terjadi digabung dalam baris yang sama pada dataset. Attribut – attribut gabungan yang ada pada dataset ditunjukkan pada Tabel 2.3. Pada Tabel 2.3 ditunjukkan bahwa terdapat beberapa attribut yang diturunkan dari attribut yang telah ada, yaitu : task actions, task modifications, task creations, task reactions, task D actions, task H defect dan task defect efforts.
16
Gambar 2.5 Proses Pembuatan Dataset (Chang, 2007) Tabel 2.3 Attribut – Attribut dari Dataset ID
Attribut
Nilai 0 : terjadwal 1, : tidak terjadwal
1
Action state
2
Action type
N : membuat modul baru, M : modifikasi modul yang telah ada, D : menghapus modul, A : menambahkan modul, - : none
3
Caused type
4
Action complexity Object type
Menyatakan hubungan antara performed action ( - : general action, R : reaction, D: defect action ) 0 : rendah, 5 : sedang, 10 : tinggi
5 6 7 8 9 10 11 12 13
0 : none, 1 : dokumen, 2 : database, 3 : aplikasi, 4 : konfigurasi sistem
Effort expected Action originator Action target
Numerik, estimasi dari waktu (jam) untuk menyelesaikan action
Number of object Task status
Banyaknya object yang berhubungan dengan action yang dilakukan
Task effort estimated Task action Task modification
0 : none, 1 : customer, 2 : pengguna, 3 : manajer, 4 : programmer 0 : tidak ada, 1 : requirement, 2 : desain pendahuluan, 3 : desain, 4 : coding, 5 : testing, 6 : maintenance, 7 : support
0 : sesuai jadwal, 1 : setelah jadwal, 2 : setelah penyelesaian, 9 : tidak diketahui Estimasi usaha yang diperlukan untuk menyelesaikan task Banyaknya action yang dilakukan untuk menyelesaikan task Banyaknya action berjenis modifikasi yang dilakukan untuk menyelesaikan task
17
14
Task creation
Banyaknya action yang digunakan untuk membuat modul baru
15
Task reaction
Banyaknya action R yang diperlukan untuk menyelesaikan task
16
Task D action
Banyaknya action D yang diperlukan untuk menyelesaikan task
17
Task H defect
Banyaknya action yang menyebabkan high defect
18
Task defect effort Task progress
Total usaha yang diperlukan untuk memperbaiki defect pada task
Number of defect
L jika defect 0 – 3 dan H jika lebih dari 3
19 20
Usaha yang telah dilakukan / estimasi usaha keseluruhan
Attribut - attribut dataset yang ditunjukkan pada Tabel 2.3 dibagi menjadi dua bagian yaitu attribut antecedent, yaitu attribut nomor 1 - 19 dan attribut consequent, attribut nomor 20. Attribut antecedent digunakan pada tahap prediksi sebagai data model prediksi untuk menebak nilai dari attribut consequent. Attribut consequent merupakan attribut yang menentukan class dari data yang memiliki attribut antecedent tertentu.
(ii)
Tahap Pembuatan Model Prediksi dan Proses Prediksi Pembuatan model prediksi dibangun dengan decision tree. Decision tree
dibangun mulai dari root node, dimana pemilihannya dilakukan dengan perhitungan gain ratio dari masing atribut dari dataset. Gambaran umum dari pembuatan model prediksi dan proses prediksi yang dilakukan oleh (Chang,2007) ditunjukkan pada Gambar 2.6 dan Gambar 2.7. Gambar 2.6 ditunjukkan bahwa input dari proses pembangunan decision tree adalah data training dari input akan dilakukan sebuah proses pembangunan decision tree, pada proses penentuan class label leaf node menggunakan mayoritas kelas dan output yang dihasilkan adalah sebuah model prediksi dengan sebuah decision tree. Gambar 2.7 menunjukkan proses prediksi, proses prediksi dilakukan dengan memasukkan data test dan model prediksi yang telah dihasilkan dari proses Gambar 2.6, selanjutnya data test dimasukkan pada model prediksi dan akan dihasilkan sebuah hasil prediksi yang akan mengkategorikan apakah sebuah aksi akan menghasilkan high defect atau low defect.
18
START
Input Data training
Masukkan Data test (attribute sebuah action)
Proses pembuatan decision tree
Masukkan data test pada model prediksi
Penentuan class label leaf node menggunakan mayoritas kelas
Kategori (High defect atau low defect)yang dihasilkan oleh model prediksi
Model prediksi yang terdiri atas sebuah decision tree
STOP
Gambar 2.6 Proses Pembangunan Model Prediksi dengan Single Decision Tree
Gambar 2.7 Proses Prediksi dengan Single Decision Tree
2.5 Contoh Work Breakdown Structure Proyek AMS-COMFT Attendance Management System for the Customs Office of the Ministry of Finance of the Republic of China, Taiwan (AMS-COMFT) adalah system manajemen kehadiran untuk kantor bea cukai kementrian keuangan Republik Cina, Taiwan dimana dalam AMS-COMFT terdapat manajemen jadwal, libur, dan manajemen permintaan overtime, analisa kartu waktu dan pelaporan (Chang, 2008).
Proyek tersebut terdiri dari tujuh paket kerja terbagi dalam 22 tugas
terjadwal seperti ditunjukkan dalam Tabel 2.4, dimana nomer yang ditunjukkan dalam kurung menunjukkan ID work package atau task.
Gambar 2.8
menunjukkan hubungan antara aksi dengan work package dimana aksi berfungsi sebagai operasi dasar yang digunakan untuk menjalankan planned steps yang ada pada task dari masing-masing work package.
Tabel 2.4 Work Breakdown Structure dari Proyek AMS-COMFT (Chang, 2008) 19
Work Package
Tasks
(04) Project Management
(18) Project Monitor & Control (14) Project Planning
(06) System Engineering
(22) Requirements Development (RD) (24) RD Review (26) Preliminary Design (PD) (28) PD Review (30) Detailed Design (DD) (42) DD Review
(12) Software Development
(74) Database Subsystem (DBS) Development (67) General Attendance Management (GAM) Subsystem Development (71) User Request Management (URM) Subsystem Development (79) Time Card Collection (TCC) Subsystem Modification (82) Software Integration & Testing
(02) System Integration
(10) H/S Integration & Testing
(14) Resources
(86) Hardware Resource (90) Software Resource
(10) Purchase
(62) H/S Purchase (65) H/S Integration & Testing
(04) Project Support
(46) Requirement Management (REQM) (50) Quality Assurance (QA) (55) Configuration Management (58) Training
20
Gambar 2.8 Bagian Work Breakdown Structure pada Tabel 2.4 dengan Work Package Software Development dan Task Database Subsystem (DBS) Development Dari Tabel 2.4 misal diambil contoh pada work package software development dan task database subsystem (DBS) development dan dimisalkan terdapat dua planned steps yaitu sa1 (database design) dan sa2 (create stored procedure) dan sebuah aksi a1 (database design) yang digunakan untuk melaksanakan sa1 seperti yang ditunjukkan pada Gambar 2.8. Pada Gambar 2.8 terlihat bahwa terdapat sa2 yang belum dieksekusi oleh aksi sehingga sebelum sa2 dieksekusi, maka aksi (a2= create stored procedure) yang akan digunakan untuk mengeksekusi sa2 dapat dilakukan proses prediksi dengan asumsi sudah terdapat model prediksi, karena aksi yang direncanakan akan mengeksekusi sa2 yang berada pada WBS maka action statenya adalah terjadwal. Action type a2 adalah pembuatan modul baru karena pada sa2 dapat diasumsikan bertujuan untuk membuat stored procedure yang merupakan subsistem dari database. Action complexity dari a2 bergantung dari sudut pandang pengembang, jika dianggap tidak terlalu mudah dan tidak terlalu sulit maka action complexity dapat bernilai sedang. Karena a2 merupakan rencana aksi yang timbul bukan karena R atau D maka untuk caused typenya adalah general action. Object 21
type pada a2 yaitu database. Jika diperkirakan waktu untuk mengerjakan a2 adalah 12 jam maka nilai dari effort expected adalah 12 jam. Action originator a2 adalah manajer dengan asumsi bahwa orang yang punya inisiatif supaya aksi itu dikerjakan adalah manajer proyek. Action target dari a2 adalah coding karena pembuatan stored procedure bisa dipastikan menggunakan PL-SQL. Number of object a2 dapat bernilai berapapun sesuai dengan objek yang terpengaruh dengan adanya rencana aksi a2 dan jenis objek sesuai dengan object type, jika asumsikan dengan adanya a2 maka yang terpengaruh adalah sebuah database dan sebuah aplikasi maka nilai number of object dari a2 adalah 2. Task status dapat bernilai sesuai jadwal jika task tersebut dikerjakan sesuai dengan jadwal yang telah dibuat. Task effort estimated merupakan waktu yang dibutuhkan untuk menyelesaikan task database subsystem (DBS) development jika diasumsikan effort expected a1 adalah waktu 24 jam maka total waktu untuk menyelesaikan task database subsystem (DBS) development adalah jumlah effort expected a1 dan a2 yaitu 36 jam. Task action dari task database subsystem (DBS) development adalah satu seperti yang ditunjukkan pada Gambar 2.8 dimana hanya terdapat sebuah action performed yaitu a1. Jika selama pelaksaan task database subsystem (DBS) development tidak terdapat aksi yang dimodifikasi maka task modification bernilai 0. Task creations merupakan nilai total dari aksi yang sudah dijalankan pada task database subsystem (DBS) development dimana action type bernilai N, jika pada a1 action type bernilai N maka task creations pada task database subsystem (DBS) development bernilai 1. Task reaction dan task D action dari task database subsystem (DBS) development bernilai 0 jika selama pelaksanaan a1 tidak menghasil aksi R dan D, dan task H defect juga bernilai 0 jika selama pelaksanaan a1 tidak menghasilkan high defect. Karena belum terdapat cacat selama pelaksaan a1 maka nilai dari task defect effort adalah 0. Task progress merupakan waktu yang sudah digunakan selama melaksanakan task database subsystem (DBS) development dibagi dengan seluruh waktu yang dibutuhkan untuk menyelesaiakan task database subsystem (DBS) development, jika untuk mengerjakan a1 waktu yang sudah digunakan adalah 20 jam maka task progress dari task database subsystem (DBS)
22
development adalah 20/36 = 0.55 jam. Sehingga nilai dari a2 yang akan diprediksi secara keseluruhan adalah seperti ditunjukkan pada Tabel 2.5. Tabel 2.5 Nilai dari a2 yang Akan Diprediksi Sebelum Menjalankan sa2 ID
2.6
Attribut
Nilai
1
Action state
0 : terjadwal
2 3
Action type Caused type
N : membuat modul baru - : general action
4
Action complexity
5 : sedang
5
Object type
2 : database
6
Effort expected
12 jam
7
Action originator
3 : manajer
8 9
Action target Number of object
4 : coding 2
10 11
Task status Task effort estimated
0 : sesuai jadwal 36 jam
12
Task action
1
13 14
Task modification Task creation
0 1
15
Task reaction
0
16
Task D action
0
17
Task H defect
0
18
Task defect effort
0
19
Task progress
0.55
Klasifikasi Proses klasifikasi mengolah input berupa kumpulan data. Setiap data
memiliki himpunan attribut x dan kategori kelas y. Pada klasifikasi, data yang memiliki attribut x dipetakan atau diprediksi nilai y-nya. Model prediksi merupakan bagian yang bertugas untuk melakukan proses klasifikasi atau prediksi nilai kategori kelas y berdasarkan nilai attribut x, seperti yang ditunjukkan pada gambar 2.9 Model prediksi memiliki dua fungsi, yaitu fungsi penggambaran dan fungsi
peramalanPada
fungsi
penggambaran,
model
prediksi
berfungsi
menggambarkan object – object yang memiliki kelas tertentu. (Tan, Steinbach, dan Kumar, 2006). Sebagai contoh, model prediksi dapat digunakan untuk menggambarkan perbedaan antara jenis kendaraan yang berbeda, misalnya antara
23
mobil dengan truk berdasarkan ciri – ciri mobil dan truk.. Fungsi peramalan dari model prediksi menyatakan bahwa model prediksi digunakan untuk meramalkan kelas dari sebuah data yang kelasnya (nilai attribut y) belum diketahui bila attribut yang lain (nilai attribut x) diketahui.
Gambar 2.9 Proses Prediksi atau Klasifikasi Sebuah Data
Untuk membangun model prediksi dari dataset input, digunakan teknik klasifikasi. Contoh dari teknik klasifikasi antara lain SVM, jaringan syaraf tiruan, fuzzy, dan lain - lain. Model prediksi yang dibangun dari teknik klasifikasi harus mampu mengklasifikasikan data training dengan baik dan dapat memprediksi class label dari data baru yang belum diketahui sebelumnya berdasarkan nilai attribut x-nya.
Gambar 2.10 Bagan dari Proses Pembuatan Model Prediksi
24
Gambar 2.10 menunjukkan tahap – tahap pembuatan model prediksi Pada Gambar 2.10 ditunjukkan bahwa pembuatan model prediksi terdiri atas dua tahap. Tahap pertama adalah tahap induksi, di mana training set diolah menggunakan learning algorithm atau teknik klasifikasi. Learning algorithm mempelajari training set dan menghasilkan learn model atau model prediksi. Model prediksi kemudian digunakan untuk melakukan peramalan. Pada tahap ini model prediksi digunakan untuk meramalkan class label dari data telah diketahui attribut – attributnya (nilai attribut x) selain attribut class label (nilai attribut y). Performa dari model prediksi dapat diukur menggunakan beberapa metrik. Metrik yang umum digunakan adalah akurasi dan error rate akurasi =
banyaknya _ prediksi _ benar ......................................................(2.1) banyaknya _ seluruh _ prediksi
error _ rate =
2.7
banyaknya _ prediksi _ salah .................................................(2.2) banyaknya _ seluruh _ prediksi
Decision tree Decision tree merupakan sebuah teknik klasifikasi yang menggunakan tree
untuk membangun model prediksinya (Tan, Steinbach dan Kumar, 2006). Gambar 2.11 menunjukkan struktur sebuah decision tree. Seperti yang ditunjukkan pada Gambar 2.11, sebuah decision tree terdiri atas 1)
Root node Node yang tidak memiliki edge yang mengarah pada dirinya
2)
Internal node Node yang memiliki sebuah edge yang mengarah pada dirinya dan dua atau lebih edge yang mengarah keluar
3)
Leaf node Node yang memiliki satu edge yang menuju ke dirinya dan tidak memiliki edge yang menuju keluar
25
Gambar 2.11 Struktur dari Decision Tree
Proses pembuatan decision tree dilakukan dengan menggunakan pengembangan dari algoritma Hunt. Pada algoritma Hunt, sebuah decison tree dibangun secara rekursif menggunakan pendekatan greedy dengan membagi data training menjadi subset yang lebih murni. Misalkan Dt merupakan himpunan data training yang menjadi elemen node t dan Y = {Y1, Y2,...,Yk} merupakan class label. Algoritma Hunt yang digunakan untuk membangun decision tree : 1)
Step1 Jika semua elemen Dt tergolong satu kelas Yt, maka t merupakan leaf node dengan class label Yt
2)
Step 2 Jika Dt berisi data yang termasuk pada beberapa kelas, sebuah attribute test condition dipilih untuk mempartisi Dt menjadi subset yang lebih kecil. Sebuah child node dibuat untuk setiap outcome attribut test condition dan elemen Dt didistribusikan berdasar nilai outcomenya. Untuk tiap child yang terbentuk, algoritma Hunt dilakukan lagi secara rekursif Jika data memiliki beberapa attribut, maka attribut yang digunakan untuk
mempartisi dataset adalah attribut yang menghasilkan gain atau selisih impurity terbesar. Gain dihitung dengan
26
k
N (V j )
j =1
N
∆ = I ( parent ) − ∑
I (V j )
(2.3)
Dengan ∆ adalah gain, I(parent) adalah impurity dataset sebelum diplit, N(Vj) adalah banyaknya elemen dataset pada child ke j dan N adalah banyaknya elemen dataset dan I(Vj) adalah impurity dari child ke j. Pengukuran impurity untuk setiap node dilakukan dengan rumus berikut. c −1
gini = 1 − ∑ p 2 (i | t )
(2.4)
i =0
c −1
entropy = −∑ p (i | t ) log 2 p (i | t )
(2.5)
Misclassif ication _ error = 1 − p (i | t )
(2.6)
i =0
Dengan p (i | t ) merupakan proporsi class tertentu pada sebuah node. Pengukuran impurity dilakukan dengan salah salah satu metrik gini, entropy atau misclassification error. Berikut ini contoh pembuatan decision tree. Data training yang digunakan ditunjukkan pada Tabel 2.6.
Tabel 2.6 Data Training untuk Pembuatan Decision Tree X
Y
Z
Banyaknya class C1
Banyaknya class C2
0 0 0
0 0 1
0 1 0
5 0 10
40 15 5
0
1
1
45
0
1
0
0
10
5
1
0
1
25
0
1
1
0
5
20
1
1
1
0
15
Split data training dapat dilakukan dengan variabel X, Y atau Z. Gambar 2.12 menunjukkan dataset yang displit menggunakan ketiganya
27
Gambar 2.12 Partisi Dataset dengan Attribut X, Y dan Z
Attribute yang digunakan untuk melakukan split level 1 adalah attribute yang menghasilkan gain terbesar. Gain terbesar didapatkan dari attribute yang menghasilkan child dengan impurity terkecil. Jika menggunakan metrik impurity misclassification error, impurity terkecil dihasilkan bila dataset dipartisi dengan attribute Z yaitu 0,3 Partisi cabang 0 dari Z dapat dilakukan dengan attribut yang tersisa, yaitu X dan Y. Gambar 2.13 menunjukkan hasil partisi cabang 0 dari Z menggunakan attribut X dan Y
Gambar 2.13 Partisi Cabang 0 dari Z dengan Attribut X dan Y Attribute yang digunakan untuk melakukan split cabang 0 dari Z adalah attribute yang menghasilkan gain terbesar atau misclassification error terkecil yaitu attribut Y dengan nilai 0,3 Partisi cabang 1 dari Z dapat dilakukan dengan attribut yang tersisa, yaitu X dan Y. Gambar 2.14 menunjukkan hasil partisi cabang 1 dari Z menggunakan attribut X dan Y
28
Gambar 2.14 Partisi Cabang 1 dari Z dengan Attribut X dan Y
Attribute yang digunakan untuk melakukan plit cabang 1 dari Z adalah attribute yang menghasilkan gain terbesar atau misclassification error terkecil yaitu attribut Y dengan nilai 0,3. Decision tree yang telah jadi ditunjukkan pada
Gambar 2.15 Decision Tree Dua Level yang Telah Jadi
Leaf node diklasifikasikan sebagai class mayoritas dari dataset yang menjadi isi leaf node. Sebagai contoh, pada leaf node cabang 0 dari Y, karena banyaknya data dengan class label C2 melebihi data dengan class label C1 maka setiap data yang masuk pada leaf node tersebut diklasifikasikan sebagai C2
2.8
Ensemble Method Untuk meningkatkan akurasi dari proses klasifikasi, salah satu cara yang
dapat dilakukan adalah menggunakan model prediksi yang terdiri atas banyak classifier (Tan, Steinbach dan Kumar, 2006). Teknik ini dinamakan ensemble method. Ensemble method membangun model prediksi yang terdiri atas banyak classifier dan melakukan proses klasifikasi dengan melakukan voting hasil prediksi classifier – classifiernya. Ada syarat yang harus dipenuhi oleh ensemble
29
method agar memberikan hasil yang lebih baik dari classifier tunggal, yaitu classifier – classifiernya harus independen satu dengan yang lain dan performa classifier penyusunnya harus lebih baik dari tebakan random. Terdapat beberapa cara untuk mengimplementasikan ensemble method. Salah satunya adalah dengan memanipulasi training set. Pada pendekatan ini, training set dibuat dengan melakukan Sampling pada training set asli secara berulang – ulang. Classifier – classifier penyusun model prediksi dibangun dari training set buatan menggunakan algoritma learning tertentu. Bagging merupakan salah satu teknik yang mengimplementasikan metode manipulasi training set. Bagging atau sering disebut bootstrap aggregating merupakan teknik untuk membuat classifier menggunakan data training baru dari training set asli dengan teknik sampling with replacement menggunakan uniform probability distribution. Setiap data training buatan, disebut juga bootstrap, berukuran sama dengan data training asli. Sampling with replacement berarti bahwa pada saat sampling, setiap data yang diambil sebagai sample dari data training asli dapat diambil lagi sebagai sample pada pengambilan sample berikutnya. Uniform probability distribution berarti bahwa setiap sample dari data training asli memiliki kemungkinan yang sama untuk diambil. Secara rata – rata, setiap bootstrap mengandung 63% data training asli karena setiap elemen data training memiliki peluang 1 – (1 – 1/N)N untuk dipilih sebagai sample, dengan N adalah ukuran data training. Algoritma Bagging : 1. 2. 3. 4. 5.
For i = 1 to k do // K adalah banyaknya bootstrap Buat sebuah bootstrap sample Di berukuran N Buatlah sebuah classifier Ci menggunakan bootstrap sample Di End for
C * ( x) = arg max ∑ δ (C i ( x) = y ) y
6.
i
( δ (.) = 1 ) jika argumennya bernilai true dan sebaliknya
Algoritma bagging adalah algoritma pembuatan ensemble classifier menggunakan metode bagging. Mula – mula ditentukan dulu banyaknya bootstrap atau classifier yang akan dibuat yang ditunjukkan pada baris 1. Pada baris 2 sampai 5, untuk setiap iterasi dilakukan pembuatan bootstrap
30
menggunakan teknik Sampling with replacement dengan uniform probablity distribution. Dari bootstrap yang didapatkan pada setiap iterasi, dibuat sebuah classifier untuk masing – masing bootstrap. Model prediksi yang terbentuk terdiri atas banyak classifier. Jika terdapat data yang akan diklasifikasikan atau diprediksi class labelnya, maka proses klasifikasi dilakukan dengan melakukan voting dari classifier – classifier penyusun model prediksi
2.9
Cost Sensitive Learning Cost sensitive learning merupakan salah satu teknik pembangunan model
yang dalam prosesnya memperhitungkan misclassification cost. Misclassification cost merupakan kerugian yang ditanggung karena ada data yang gagal diklasifikasikan ke kelas tertentu atau penalti jika mengklasifikasikan sebuah data yang sebenarnya termasuk suatu class menjadi class yang lain. C(i, j) menotasikan cost function yang berarti penalti jika mengklasifikasikan sebuah data yang sebenarnya berasal dari class i menjadi class j (Tan, Steinbach dan Kumar, 2006). Dengan demikian, C(+, -) menyatakan cost atau penalti jika melakukan false negative error, sedangkan C(-, +) menyatakan cost atau penalti jika melakukan false alarm. Dari sekumpulan data training, cost total dari dari sebuah model prediksi C(M) yang dibangun dari data training tersebut adalah C(M) = TP x C(+,+) + FP x C(-,+) + FN x C(+,-) + TN x C(-,-) .......................(2.7)
Dengan TP merupakan banyaknya data positif yang diklasifikasi positif, FP merupakan banyaknya data negatif yang diklasifikasi positif, FN merupakan banyaknya data positif yang diklasifikasi negatif dan TN merupakan banyaknya data negatif yang diklasifikasi negatif. Pada umumnya, nilai C(+,+) dan C(-,-) adalah 0 karena tidak ada penalti jika model prediksi melakukan prediksi dengan benar. Dengan demikian, persamaan 2.10 dapat disederhanakan menjadi C(M) = FP x C(-,+) + FN x C(+,-) .....................................................................(2.8)
Pada kasus decision tree, cost sensitive learning dapat diintegrasikan pada algoritma decision tree menggunakan beberapa cara (1) dimasukkan sebagai kriteria pemilihan attribut yang digunakan untuk melakukan split data training (2)
31
menentukan apakah subtree akan dipangkas (3) memanipulasi bobot dari data training sehingga algoritma decision tree akan menghasilkan tree dengan total cost paling rendah (4) memodifikasi aturan pengambilan keputusan class pada leaf node decision tree Pada pendekatan terakhir, proses pembuatan decision tree dilakukan seperti biasa. Namun, setelah tree terbentuk, proses penentuan class label dari leaf node tidak dilakukan dengan menggunakan class mayoritas isi leaf node. Metode penentuan class label dari leaf node dilakukan dengan memberikan class label pada leaf node yang memberikan cost paling kecil. Untuk memperjelas konsep di atas, dapat digunakan contoh sebagai berikut. Pada sebuah leaf node dari decision tree terdapat 10 class + dan 100 class -. Dengan menggunakan algoritma decision tree biasa, maka leaf node tersebut akan diklasifikasikan sebagai class -, karena class – merupakan class mayoritas pada leaf node tersebut. Jika menggunakan cost sensitive learning, hasilnya bisa berbeda. Bila diketahui bahwa C(-,-) = C(+,+) = 0, C(+,-) = 20 dan C(-,+) = 1, maka cost mengklasifikasikan leaf node sebagai – adalah 200 (berasal dari cost mengklasifikasikan
10
data
dengan
class
+
menjadi
-)
dan
cost
mengklasifikasikan leaf node sebagai + adalah 100 (berasal dari cost mengklasifikasikan 100 data dengan class - menjadi +). Karena cost mengklasifikasikan leaf node sebagai + kurang dari cost mengklasifikasikan leaf node sebagai -, maka leaf node diklasifikasikan sebagai +.
2.10 Metrik Uji Coba Metrik yang digunakan untuk mengukur performa model prediksi adalah accuracy dan recall (Chang,2007). Hasil dari pengukuran metrik yaitu berupa prosentase dimana semakin tinggi persentase yang dihasilkan oleh accuracy dan recall berarti kontribusi yang diajukan memberikan hasil yang baik namun jika semakin rendah prosentase yang dihasilkan oleh accuracy dan recall berarti kontribusi yang diajukan memberikan hasil yang kurang baik. Persamaan accuracy dan recall ditunjukkan pada persamaan 2.5 dan 2.6 dimana T, F, P dan N menggambarkan true, false, positive, dan negative, secara berurutan. Dalam penelitian (Chang,2007) terdapat empat notasi yang digunakan yaitu TP, TN, FP, 32
FN. Huruf pertama akan bernilai T jika hasil prediksi sama dengan data asli yaitu jika terdapat suatu aksi yang sebenarnya high defect diprediksi sebagai high defect dan jika terdapat suatu aksi yang sebenarnya low defect diprediksi sebagai low defect dan akan bernilai F jika sebaliknya. Sedangkan huruf kedua akan bernilai P jika hasil prediksi menghasilkan high defect dan akan menghasilkan nilai N jika hasil prediksi menghasilkan low defect. Dalam penelitian ini digunakan konversi ke notasi lain untuk lebih mempermudah dimana TP = HH, TN = LL, FP = LH, FN = HL. Accuracy merupakan metrik untuk mengukur performa model prediksi dalam memprediksi jenis defect yang dihasilkan data test secara keseluruhan.
accuracy =
HH + LL x100% .....................................................(2.9) HH + LL + LH + HL
Recall merupakan metrik untuk mengukur performa model prediksi dalam mendeteksi action yang sebenarnya high defect.
recall =
HH x100 % ..................................................................(2.10) HH + HL
HH adalah banyaknya data tes yang sebenarnya high defect dan diprediksi high defect oleh model prediksi. LL adalah banyaknya data test yang low defect dan diprediksi low defect oleh model prediksi. LH merupakan banyaknya data test yang sebenarnya low defect namun diprediksi high defect oleh model prediksi. HL merupakan banyaknya data test yang high defect namun diprediksi low defect oleh model prediksi. Penggunaan ensemble classification tree bertujuan untuk meningkatkan accuracy model prediksi, sedangkan penggunaan cost sensitive learning bertujuan untuk meningkatkan recall model prediksi.
33
