A. PENDAHULUAN

Sebuah defect adalah suatu karakteristik yang mengurangi kegunaan atau harga suatu item; atau semacam kelemahan, ketidaksempurnaan, atau kekurangan^[1]. Software defect merupakan segala cacat atau ketidaksempurnaan didalam produk software (program komputer, perencanaan, dokumentasi terkait, atau data) atau proses software (aktivitas, metode dan transformasi yang digunakan untuk mengembangkan dan mengelola produk software). Software defect merupakan perwujudan dari kesalahan manusia (produsen software); biar bagaimanapun tidak semua kesalahan manusia merupakan defect, dan tidak semua defect merupakan hasil kesalahan manusia. Ketika ditemukan di dalam executable code, sebuah defect lebih sering disebut fault atau bug. Sebuah fault adalah langkah program, proses, atau data yang salah di dalam program komputer. Fault merupakan defect yang menetap di dalam software sampai software tersebut dieksekusi.

Istilah lain yang berhubungan dengan software defect adalah sotware problem. Software problem adalah sesuatu yang ditemui manusia dari software yang menyebabkan kesulitan, keraguan, atau ketidaktentuan dalam penggunaan atau pemeriksaan software. Dalam lingkungan dinamik (operasional), beberapa problem/masalah mungkin disebabkan oleh failure. Suatu software failure terjadi selama eksekusi program. Sebuah failure disebabkan oleh fault, yang mana defect ditemukan dalam executable code. Dalam lingkungan statis (non-operasional), seperti inspeksi kode, suatu problem mungkin disebabkan oleh defect. Diantara lingkungan dinamik dan statis, problem munbkin disebabkan oleh kesalahpahaman, kesalahan penggunaaan atau sejumlah faktor lain yang tidak berhubungan dengan produk software yang sedang digunakan.

B. 10 HAL TENTANG SOFTWARE DEFECT

Berikut ini daftar 10 hal teratas dalam software defect reduction ^[2] yang disesuaikan dari “Industrial Metrics Top 10 List” (B. Boehm, IEEE Software, Sept. 1987, pp. 84-85)

1. Menemukan dan memperbaiki software problem setelah delivery seringkali 100 kali lebih mahal daripada menemukan dan memperbaikinya selama fase requirements and design. Sebagaimana yang diobservasi Boehm di tahun 1987, “pengetahuan ini telah menjadi penggerak utama di dalam memfokuskan praktek industri software pada desain dan analisis kebutuhan yang teliti, verifikasi dan validasi sejak permulaan, serta prototyping dan simulasi di awal untuk mencegah masalah beruntut yang menghabiskan biaya.” Penggunaan kata “seringkali” dikarenakan pada sistem software yang kecil dan noncrtical lebih mendekati 5:1 daripada 100:1.

2. Proyek software saat ini menghabiskan upaya mereka sekitar 40 – 50% pada mengerjakan kembali pekerjaan (rework) yang sebetulnya pekerjaan tersebut dapat dicegah. Mengurangi “pengerjaan ulang yang sebetulnya dapat dicegah” dapat secara signifikan meningkatkan produktivitas software. Suatu pengerjaan ulang terdiri atas upaya yang dihabiskan untuk memperbaiki berbagai kesulitan software yang bisa saja telah ditemukan lebih awal. Implikasinya, suatu upaya juga terdiri atas "pengerjaan ulang yang tidak dapat dihindarkan", sebuah observasi yang meningkatkan kredibilitas dengan meningkatkan realisasi yang menghasilkan sistem user-interaktif yang lebih baik dari proses-proses yang muncul. Dalam proses-proses tersebut, kebutuhan yang muncul dari prototyping dan aktivitas multistakeholder-shared-learning, kemudian membawa ke praktek desain dan coding. Proses muncul yang mengindikasikan perubahan pada definisi sistem yang membuatnya lebih cost-effective tidak perlu diklasifikaskan sebagai defect yang dapat dicegah.

3. Sekitar 80% dari pengerjaan ulang (rework) berasal dari 20% defect. Nilai 80% tersebut mungkin lebih rendah untuk sistem yang kecil dan lebih tinggi untuk sistem yang sangat besar. Dua sumber utama dari "pengerjaan ulang yang dapat dicegah" (avoidable rework) meliputi menetapkan kebutuhan dan biaya desain serta pengembangan dengan tergesa-gesa, yang mana menyebabkan kerusakan code, desain, dan arsitektur utama. Suatu sistem tracking untuk laporan permasalahan software yang mencatat upaya untuk perbaikan setiap defect, membantu anda menganalisa data dengan mudah untuk menentukan sumber tambahan utama untuk rework.

4. Sekitar 80% defect berasal dari 20% dari modul, dan sekitar separuh dari modul adalah bebas dari defect. Studi dari environment yang berbeda-beda pada beberapa tahun telah menunjukkan, dengan sangat konsisten, bahwa antara 60 sampai 90% defect timbul dari 20% modul, dengan median sekitar 80%.

5. Sekitar 90% dari downtime berasal dari, paling banyak, 10% dari defect. Namun, beberapa defect tak begitu mempengaruhi downtime dan reliability sistem. Sebagai contoh, sebuah analisis sejarah software failure dari 9 produk software besar IBM mengungkapkan bahwa sekitar 0,3% defect dihitung untuk sekitar 90% downtime.

6. Peer review menemukan 60% dari defect. Jika menemukan dan memperbaiki sebagian besar defect di dalam siklus pengembangan proyek adalah lebih cost-effective daripada menemukannya kemudian, kita mencari teknik yang dapat menemukan defect seawal mungkin. Berbagai studi mengemukakan bahwa peer review menyediakan teknik efektif yang dapat menemukan defect hingga 31-93%, dengan median sekitar 60%. Sehingga, 60% nilai yang disebut pada tahun 1987 tersebut merupakan estimasi yang beralasan. Faktor yang mempengaruhi persentase defect untuk ditemukan adalah termasuk jumlah dan tipe peer review yang dibentuk, ukuran dan kompleksitas sistem, dan frekuensi defect yang lebih bagus ditemukan oleh eksekusi, seperti defect algoritma dan concurrency. Studi menunjukkan fakta bahwa peer review, tool analisis, dan testing menangkap kelas defect yang berbeda pada poin yang berbeda di dalam siklus pengembangan. Kita membutuhkan riset empiris untuk membantu memilih strategi gabungan terbaik untuk investasi defect-reduction.

7. Perspective-based review menemukan defect 35% lebih banyak daripada nondirected review.

8. Mempraktekkan disiplin personal dapat mengurangi tingkat awal defect hingga 75%. Beberapa proses disiplin personal telah dibawa ke dalam praktik. Ini termasuk Harlan Mills’s Cleanroom software development process dan Watts Humphrey’s Personal Software Process (PSP). Data dari penggunaan Cleanroom pada NASA telah menunjukkan 25-75% pengurangan tingkat kesalahan selama testing. Penggunaan Cleanroom juga memperlihatkan pengurangan upaya pengerjaan kembali (rework) sehingga hanya 5% dari perbaikan yang memerlukan waktu lebih dari sejam, dimana proses standar memberikan lebih dari 60% dari perbaikan memerlukan waktu lebih lama. Sementara PSP berfous pada akar penyebab software defect individual, pada pengembangan ceklis personal, serta pada penceghan pengulangan kembali, telah secara signifikan mengurangi tingkat defect personal.

9. Jika semua hal sama, setiap intruksi sumber akan menghabiskan 50% lebih banyak untuk mengembangkan produk software high-dependability daripada untuk mengembangkan produk software low-dependability. Bagaimanapun investasi lebih dari nilainya jika proyek meliputi biaya operasi signifikan dan biaya pengelolaan.

10. Sekitar 40 – 50% program user mengandung defect yang tidak sepele / nontrivial. Sebuah studi pada area ini menemukan bahwa 44% dari 27 program spreadsheet yang diproduksi oleh developer spreadsheet berpengalaman mengandung defect nontrivial / tidak sepele — sebagian besar error di dalam formula spreadsheet (P.S. Brown and J.D. Gould, “An Experimental Study of People Creating Spreadsheets,” ACM Trans. Office Info. Sys., July 1987, pp.258-272) . Eksperimen lab selanjutnya melaporkan bahwa tingkat defect spreadsheet saat itu 35-90%. Analisa spreadsheet yang berjalan mengungkapkan tingkat defect antara
    21-26%; tingkat defect yang rendah mungkin dari koreksi yang dibuat selama pengoperasian.

C. CONTOH SOFTWARE DEFECT

Berikut ini adalah contoh dari adanya software defect yang pernah terjadi

1. Pada komputer Windows XP ,user tidak bisa melakukan hibernate apabila komputer memiliki 1GB atau lebih RAM, atau ketika komputer menjalankan multiple proses yang menyebabkan kondisi high-stres (Article ID 330909). Microsoft telah membuat update patch pada SP2 ^[3].

2. Komputer yang menjalankan Microsoft Windows XP ada kemungkinan berhenti me-respon/nge-hang ketika pesan “Applying local settings” muncul setelah login. Masalah ini terjadi ketika file srvsvc.dll menimbulkan error access violation. Error ini menghentikan proses svchost.exe yang meload layanan seperti workstation dan server. Akibatnya winlogon.exe berhenti merespon setelah anda log on ke windows (Article ID 823830). Microsoft telah membuat update patch masalah ini pada SP2.

3. Pada website situs jejaring sosial Friendster (www.friendster.com) di tahun 2008, banyak sekali ditemukan bug dan defect. Pada tahun 2008, situs Friendster tidak memiliki pengecekan comment yang sempurna. Pengguna bisa memasukkan javascript di dalam komentar yang berformat HTML. Hasilnya, user dapat menyisipkan javascript yang bisa menyebabkan user lain tidak dapat mengakses profilnya, bahkan bisa terjadi pencurian cookies web milik user lain. Saat ini, pihak Friendster telah memperbaiki situsnya sehingga lebih aman.

4. Pada Microsoft Office Excel 2007, jika anda melakukan perhitungan 850 x 77,1 pada A1 akan ditampilkan hasil 100000 dimana seharusnya hasilnya 65535. Tentu saja hal ini akan berakibat pada kesalahan perhitungan ^[4].

D. REFERENSI

[1.] William A. Florac, “Software Quality Measurement: A Framework for Counting Problems and Defects”, Technical Report p.23-24, Carnegie Mellon University, 1996 (in Pennsylvania).

[2.] Barry Boehm, Victor R. Basili, “Software Defect Reduction Top 10 List”, Software Management p.135-137, January 2001.

[3.] http://support.microsoft.com

[4.] http://digg.com/microsoft/Critical_Excel_2007_bug_cripples_users