BAB II LANDASAN TEORI
2.2 Tinjauan Pustaka
2.2.1 Prediksi Cacat Software
2.2 Tinjauan Pustaka
2.2.1 Prediksi Cacat Software
Istilah cacat, kesalahan dan bug biasa digunakan secara bergantian. Istilah-istilah ini mengacu pada manifestasi dari kesalahan dalam kode sumber (source
code), di mana kesalahan adalah suatu tindakan yang keliru yang dibuat oleh
pengembang. Cacat software adalah kekurangan/cacat pada sebuah software karena melakukan proses yang tak terduga (McDonald, Musson, & Smith, 2008, p. 4). Cacat software dapat menjadi penyebab kegagalan software, yang terjadi ketika pengguna mengalami perilaku sistem yang tidak diinginkan pada titik waktu tertentu. Bagi user, cacat software adalah segala kekurangan yang menyebabkan software tidak dapat memenuhi apa yang diharapkan. Misalnya
user ingin software yang digunakan dapat memberikan hasil penghitungan yang
tepat, tetapi software memberikan hasil yang salah. Secara umum, kesalahan sintaks tidak dianggap sebagai cacat, karena mereka dapat ditemukan dengan jauh lebih efisien menggunakan parser dan/atau pengujian jalur dasar.
Tabel 2.3 di bawah ini menampilkan beberapa contoh umum cacat pada software.
Tabel 2.3
Contoh Umum Cacat Software
Harapan Cacat
Software dapat membantu menyelesaikan pekerjaan
Fungsionalitas sofware tidak ada
Mengklik tombol untuk mengerjakan suatu proses
Mengklik tombol, tetapi tidak ada atau tidak sesuai dengan proses yang diinginkan
File dapat di-copy ke lokasi lain
Terjadi kerusakan file selama proses peng-copy-an
27 Tabel 2.4
Contoh Nyata Cacat Software
Harapan Cacat
Software membantu menghilangkan kesalahan
(contohnya kesalahan pengejaan)
Tidak dapat mendeteksi kesalahan ejaan
Software dapat merespons dengan cepat
Respons software sangat lambat dari yang perkiraan
Software aman dari serangan
hacker
Hacker dapat mengekploitasi celah
dan melakukan serangan terhadap software
Cacat software dapat terjadi karena beberapa hal (McDonald, Musson, & Smith, 2008, p. 7): 1) akibat kesalahan manusia, tidak ada orang yang sempurna, jadi ada kemungkinan programmer melakukan kesalahan dalam pengetikan yang tidak disadari. 2) Kesalahan sistemik selama pengembangan, adanya kesalahan suatu proses yang keluarannya digunakan untuk proses yang lain. 3) Akibat kesalahan penggunaan peralatan pengembangan. 4) Salah pengertian terhadap kebutuhan customer. Tidak semua kesalahan menyebabkan cacat software, tetapi setiap cacat software dapat diselidiki kesalahan yang menyebabkannya.
Kualitas perangkat lunak dan tingkat cacat dapat diatasi dengan tiga tingkat (McDonald, Musson, & Smith, 2008, p. 9), yaitu: 1) Deteksi, yaitu melakukan pengujian terhadap software sampai menemukan cacat yang mungkin terjadi dan memperbaikinya. 2) Analisa, dengan cara menganalisa cacat sebelumnya untuk mengetahui kecenderungan dan memahami kenapa bisa terjadi dan tidak terdeteksi. 3) Pencegahan, dilakukan secara proaktif mencari dan menghilangkan potensi cacat software. Model pencegahan cacat software dapat dilihat pada Gambar 2.5.
28 Gambar 2.5
Model Pencegahan Cacat Software
Pada Gambar 2.5, tahap pertama dilakukan pendeteksian cacat dengan cara melakukan pengujian secara sederhana yang berfokus pada setiap proses. Tahap kedua adalah prediksi, prediksi dilakukan dengan cara menganalisa terhadap data-data cacat software pada pengembangan sebelumnya. Pada proses prediksi, pertama dilakukan pengumpulan data berdasarkan pengukuran dan metrik yang tepat, selanjutnya membuat laporan yang disediakan bagi yang membutuhkan, kemudian dibuat pemodelan untuk memprediksi cacat pada pengembangan selanjutnya. Tahap ketiga adalah pencegahan cacat, dilakukan dengan mengimplementasikan teknik pencegahan berdasarkan hasil pada tahap prediksi.
Salah satu metode yang efektif untuk mengidentifikasi rawan kegagalan modul pada software adalah dengan menggunakan teknik data mining yang diterapkan dalam software metrics yang dikumpulkan selama proses pengembangan software (Khoshgoftaar, Gao, & Seliya, 2010, p. 137).
2.2.1.1 Software Metrics
Metrik perangkat lunak (software metrics) adalah istilah yang mencakup banyak kegiatan, yang semuanya melibatkan beberapa tingkat pengukuran perangkat lunak, seperti estimasi biaya dan usaha, produktivitas, ukuran dan model, pengumpulan data, model kualitas dan ukuran, model keandalan, evaluasi kinerja dan model, metrik struktur dan kompleksitas, penilaian kematangan kemampuan, manajemen berdasarkan metrik, evaluasi metode dan alat.
29
Metrik adalah nilai-nilai numerik yang menyatakan ukuran proses dan produk, yang digunakan untuk menetapkan, mengukur, mengelola, memantau, dan meningkatkan efektifitas proses dan produk (Strangio, 2009, p. 389). Software
metrics (metrik perangkat lunak) dapat didefinisikan sebagai penerapan
terus-menerus dari teknik pengukuran terhadap proses pengembangan software, dan hasilnya digunakan untuk memberikan informasi pengelolaan yang penuh dengan arti dan tepat pada waktunya, bersamaan dengan penggunaan teknik tersebut untuk meningkatkan proses dan produk yang dihasilkan (Goodman, 2004, p. 4).
Software metrics adalah pengukuran langsung maupun tidak langsung, baik
pengukuran terhadap artefak perangkat lunak atau proses pengembangan perangkat lunak. Dua jenis utama software metrics adalah metrik produk dan metrik proses. Metrik produk, seperti metrik kode statis, didasarkan pada artefak perangkat lunak. Metrik proses, seperti pengukuran kesalahan, didasarkan pada proses pengembangan perangkat lunak.
Tujuan utama dari penggunaan metrik pemeriksaan adalah untuk memperbaiki deteksi cacat, dan mengurangi biaya pengerjaan ulang. Identifikasi cacat pada tahap penyebaran (deployment) atau bahkan pada akhir pengembangan membutuhkan biaya yang sangat mahal. Biaya untuk memperbaiki cacat akibat salah persyaratan (requirement) setelah fase pengembangan (deployment) dapat mencapai 100 kali, biaya untuk memperbaiki cacat pada tahap desain setelah pengiriman produk mencapai 60 kali, sedangkan biaya untuk memperbaiki cacat pada tahap desain yang ditemukan oleh pelanggan adalah 20 kali (Strangio, 2009, p. 389). Gambaran biaya tersebut menunjukkan pentingnya pemeriksaan dan pengawasan kualitas software pada saat pengembangan.
2.2.1.2 Metrik Kode Statis
Metrik kode statis (static code metrics) adalah pengukuran langsung kode sumber (source code) yang dapat digunakan dalam upaya untuk mengukur berbagai properti software. Metrik kode statis adalah pengukur sifat perangkat lunak yang berpotensi berhubungan dengan cacat, dan kualitasnya (Gray, Bowes, Davey, Sun, & Christianson, 2010, p. 2). Pengukuran dalam rekayasa perangkat lunak merupakan faktor penting, karena tidak mungkin dapat mengontrol apa yang tidak dapat diukur (DeMarco, 2009, p. 96), dan berdasarkan banyak
30
penelitian metrik software tepat dan sering digunakan sebagai ukuran kualitas software.
Gambar 2.6
Contoh Kode Sumber Program Java
Mungkin metrik kode statik yang paling dikenal adalah metrik yang didasarkan pada jumlah baris kode (LOC: Line of Code), dan memberikan indikasi ukuran perangkat lunak. Memperhatikan kode sumber program Java yang ditunjukkan pada Gambar 2.6 diperlihatkan sebuah kelas Metrik dengan fungsi tunggal yang disebut main. Fungsi ini terdiri dari 14 baris, 3 baris kosong, 3 baris hanya berisi sebuah kurung, dan 1 baris hanya berisi komentar/keterangan. Untuk alasan ini, maka ada beberapa jenis LOC, di antaranya LOC total, LOC
executable, LOC comments, LOC blank dan LOC non-blank. Sayangnya, rincian
secara tepat tentang apa yang telah diukur sering diabaikan, sehingga menyebabkan ketidakjelasan (ambigutas) ketika nilai LOC-count diberikan. Masalah dengan LOC-count tradisional juga mencakup tentang kepekaan terhadap gaya pengkodean. Melihat pada Gambar 2.6, satu atau lebih dari tanda kurung yang digunakan dalam pernyataan if dapat diletakkan pada baris tersendiri, sehingga berpotensi mempengaruhi pengukuran berbasis LOC-count. Namun perbedaan tersebut mungkin tidak penting pada prakteknya selama gaya pengkodeannya konsisten. Pada prakteknya sering mengarah ke indentasi kode dari alat-alat (tools) yang sebelumnya digunakan untuk mengumpulkan metrik. Meskipun ada masalah dengan LOC-count, metrik kode statik merupakan yang
31
paling sering digunakan, dan jika diukur secara konsisten dapat memberikan beberapa wawasan ke dalam ukuran software.
Sedangkan pengukuran berbasis LOC-count bertujuan untuk memberikan wawasan tentang ukuran software, ukuran metrik lain diusulkan oleh Maurice Halstead pada tahun 1977, bertujuan untuk memberikan wawasan tentang kompleksitas kode dan usaha pengembangan. Metrik Halstead didasarkan pada empat ukuran dasar berikut ini:
a. Jumlah operator yang unik: n1 b. Jumlah operan yang unik: n2 c. Total jumlah operator: N1 d. Total jumlah operan: N2
Menggunakan basis pengukuran di atas, dapat diperoleh persamaan sebagai berikut:
a. Halstead Length: N = N1 + N2 b. Halstead Vocabulary: n = n1 + n2 c. Halstead Volume: V = N * log 2(n)
d. Halstead Difficulty: D = (n1 / 2) * (N2 / n2) e. Halstead Level: L = 1 / D
f. Halstead Effort: E = D *V g. Halstead Content: C = L * V
h. Halstead Error Estimate (number of validation bugs): B = V / 3000 i. Halstead Programming Time (seconds): T = E / 18
Panjang metrik adalah jumlah dari semua operator dan operan, dan merupakan alternatif pengukuran ukuran untuk mereka yang berbasis hitungan LOC (Lines Of Code). Volume metrik menggambarkan kandungan informasi dalam bit, dan ukuran terkait lain. Metrik/tingkat kesulitan telah diklaim untuk mengukur betapa sulitnya kode itu ditulis, dan dan menggambarkan seberapa rawan kesalahan itu mungkin terjadi. Kebalikan dari tingkat metrik ini adalah tingkat yang lebih rendah menunjukkan sedikit rawan terjadi kesalahan penulisan kode.
32
2.2.1.3 Dataset
Dataset NASA yang telah tersedia untuk umum merupakan data metrik perangkat lunak yang sangat populer dalam pengembangan model prediksi cacat software, karena 62 penelitian dari 208 penelitian telah menggunakan dataset NASA (Hall, Beecham, Bowes, Gray, & Counsell, 2011, p. 18). Dataset NASA yang tersedia untuk umum telah banyak digunakan sebagai bagian dari penelitian cacat software (Shepperd, Song, Sun, & Mair, 2013, p. 1208). Dataset NASA yang tersedia untuk umum mencakup 21 tingkat metode metrik yang diusulkan oleh Halstead dan McCabe (Catal & Diri, 2009, p. 1041). Dataset NASA tersedia dari dua sumber, yaitu NASA MDP (Metrics Data Program) repository dan PROMISE (Predictor Models in Software Engineering) Repository (Gray, Bowes, Davey, Sun, & Christianson, 2011, p. 98). NASA Metrics Data Program (MDP)
Repository saat ini terdiri dari 13 dataset secara eksplisit ditujukan untuk
penelitian metrik perangkat lunak (Gray, Bowes, Davey, Sun, & Christianson, 2011, p. 97). Setiap kumpulan data merupakan sistem/subsistem software NASA dan berisi metrik kode statis, dan data kesalahan dari setiap modul. Metrik kode statis yang dicatat meliputi:
a. Ukuran LOC-count, seperti jumlah baris kode dan komentar. b. Ukuran Halstead, seperti hitungan operan dan operator yang unik. c. Ukuran McCabe, seperti kompleksitas cyclomatic.
Dataset NASA yang asli masih mengandung noise (kegaduhan), yaitu data yang tidak masuk akal atau tidak konsisten. Noise (kegaduhan) dapat disebut sebagai data yang salah (Liebchen & Shepperd, 2008, p. 39). Oleh karena itu perlu dilakukan pemrosesan awal untuk membersihkan data dari noise (kegaduhan). Pembersihan data adalah prosedur yang memakan waktu dan padat karya, tapi satu yang mutlak diperlukan untuk keberhasilan data mining (Witten, Frank, & Hall, 2011, p. 60).
Strategi pemrosesan awal, yang pertama pada data yang bermasalah (misalnya: kasus dengan nilai fitur yang bertentangan atau nilai yang tidak masuk akal) dihapus, dan kemudian untuk data yang tidak bermasalah tapi tidak membantu meningkatkan prediksi cacat (misalnya: fitur dengan nilai konstan dan identik atau tidak konsisten) juga dihapus. Hasilnya dataset DS ditransformasikan ke DS' dan DS'' secara berturut-turut (Shepperd, Song, Sun, & Mair, 2013, p.
33
1209). Dataset NASA yang asli dan yang sudah dibersihkan tersedia secara umum di website wikispaces (http://nasa-softwaredefectdatasets.wikispaces.com/).
Deskripsi dataset NASA ditunjukkan pada Tabel 2.5. Spesifikasi dataset NASA MDP Repository yang asli ditunjukkan pada Tabel 2.6, spesifikasi dataset NASA MDP Repository setelah transformasi ditunjukkan pada Tabel 2.7 untuk DS' dan Tabel 2.8 untuk DS''. Sedangkan spesifikasi dataset PROMISE
Repository yang asli ditunjukkan pada Tabel 2.9, spesifikasi dataset PROMISE Repository setelah transformasi ditunjukkan pada Tabel 2.10 untuk DS' dan Tabel
2.11 untuk DS''. Setiap dataset yang terdiri dari sejumlah modul software (kasus), masing-masing berisi jumlah yang sesuai dengan cacat dan berbagai atribut kode statis perangkat lunak. Setelah pemrosesan awal, modul yang berisi satu atau lebih cacat diberi label sebagai cacat.
Tabel 2.5 Dekripsi Dataset NASA
Dataset Sistem Bahasa Total LOC
CM1 Instrumen pesawat ruang angkasa C 20K
JM1 Sistem prediksi pendaratan realtime C 315K
KC1 Manajemen penyimpanan data lapangan C++ 18K
KC3 Manajemen penyimpanan data lapangan Java 18K
MC2 Sistem panduan video C, C++ 6K
PC1 Perangkat lunak penerbangan satelit yang mengorbit bumi
C 40K
PC2 Simulator dinamis untuk sistem kontrol perilaku
C 26K
PC3 Perangkat lunak penerbangan satelit yang mengorbit bumi
C 40K
PC4 Perangkat lunak penerbangan satelit yang mengorbit bumi
C 36K
PC5 Peningkatan keamanan sistem upgrade kokpit
34 Tabel 2.6
Spesifikasi Dataset NASA MDP Repository Asli (DS)
Tabel 2.7
Spesifikasi Dataset NASA MDP Repository Transformasi Pertama (DS')
Dataset Atribut Modul Cacat Cacat (%)
CM1 41 505 48 9,50% JM1 22 10878 2102 19,32% KC1 22 2107 325 15,42% KC3 41 458 43 9,39% MC1 40 9466 68 0,72% MC2 41 161 52 32,30% MW1 41 403 31 7,69% PC1 41 1107 76 6,87% PC2 41 5589 23 0,41% PC3 41 1563 160 10,24% PC4 41 1458 178 12,21% PC5 40 17186 516 3,00%
Dataset Atribut Modul Cacat Cacat (%)
CM1 38 344 42 12,21% JM1 22 9591 1759 18,34% KC1 22 2095 325 15,51% KC3 40 200 36 18,00% MC1 39 8737 68 0,78% MC2 40 125 44 35,20% MW1 38 263 27 10,27% PC1 38 735 61 8,30% PC2 37 1493 16 1,07% PC3 38 1099 138 12,56% PC4 38 1379 178 12,91% PC5 39 16962 502 2,96%
35 Tabel 2.8
Spesifikasi Dataset NASA MDP Repository Transformasi Kedua (DS'')
Tabel 2.9
Spesifikasi Dataset PROMISE Repository Asli (DS)
Dataset Atribut Modul Cacat Cacat (%)
CM1 38 327 42 12,84% JM1 22 7720 1612 20,88% KC1 22 1162 294 25,30% KC3 40 194 36 18,56% MC1 39 1952 36 1,84% MC2 40 124 44 35,48% MW1 38 250 25 10,00% PC1 38 679 55 8,10% PC2 37 722 16 2,22% PC3 38 1053 130 12,35% PC4 38 1270 176 13,86% PC5 39 1694 458 27,04%
Dataset Atribut Modul Cacat Cacat (%)
CM1 22 498 49 9,84% JM1 22 10885 2106 19,35% KC1 22 2109 326 15,46% KC3 40 458 43 9,39% MC1 39 9466 68 0,72% MC2 40 161 52 32,30% MW1 38 403 31 7,69% PC1 22 1109 77 6,94% PC2 37 5589 23 0,41% PC3 38 1563 160 10,24% PC4 38 1458 178 12,21% PC5 39 17186 516 3,00%
36 Tabel 2.10
Spesifikasi Dataset PROMISE Repository Transformasi Pertama (DS')
Tabel 2.11
Spesifikasi Dataset PROMISE Repository Transformasi Kedua (DS'')