1. Dasar-dasar kualitas software (bagian 3)

 1.3 Kesalahan, kecacatan, dan kegagalan software.

Jika Kita mendengarkan dengan seksama selama berbagai pertemuan dengan kolega Kita, Kita akan melihat bahwa ada banyak istilah yang digunakan untuk menggambarkan masalah dengan perangkat lunak yang timbul selama pengoperasiannya. Sebagai contoh:

1. Sistem macet selama produksi.

2. Perancang membuat kesalahan.

3. Setelah peninjauan, kita menemukan cacat dalam rencana pengujian.

4. Saya menemukan bug dalam program hari ini.

5. Sistem rusak.

6. Klien mengeluhkan masalah perhitungan di laporan pembayaran.

7. Kegagalan dilaporkan dalam subsistem pemantauan.

 

Apakah semua istilah ini mengacu pada konsep yang sama atau konsep yang berbeda? Penting untuk menggunakan terminologi yang jelas dan tepat jika kita ingin memberikan arti khusus untuk masing-masing istilah ini. Figure 1.2 menjelaskan bagaimana menggunakan istilah-istilah ini dengan benar.

Figure 1.2 Terminology recommended for describing software problems.

 Sedikit informasi tentang penggunaan istilah bug:

Bug
Sejak zaman Thomas Edison, para insinyur telah menggunakan kata "bug" untuk merujuk pada kegagalan dalam sistem yang telah mereka kembangkan. Kata ini dapat menggambarkan banyaknya kemungkinan masalah. Kasus "bug komputer" pertama yang terdokumentasi melibatkan ngengat yang terperangkap di relay komputer Mark II di Universitas Harvard pada tahun 1947. Grace Hopper, operator komputer, menempelkan Bug ke dalam log laboratorium, menetapkannya sebagai "Kasus nyata pertama dari bug yang ditemukan" (lihat halaman log ini di foto di bawah).

Pada awal 1950-an, istilah “bug” , “debug”, dan “debugging”, sebagaimana diterapkan pada komputer dan program komputer dijaman sekarang, mulai muncul di media populer [KID 98].

Foto dari Museum Nasional Sejarah Amerika Smithsonian.

 

 

Kegagalan / failure (sinonim dengan crash atau breakdown) adalah eksekusi (atau manifestasi) dari kesalahan di lingkungan operasi. Kegagalan didefinisikan sebagai penghentian kemampuan komponen untuk sepenuhnya atau sebagian untuk melakukan fungsi yang dirancang untuk dilaksanakan. Asal kegagalan terletak pada cacat tersembunyi, yaitu, tidak terdeteksi oleh pengujian atau tinjauan, dalam sistem yang  sedang beroperasi. Selama sistem dalam produksi tidak menjalankan instruksi yang salah atau memproses data yang salah, maka akan berjalan normal. Oleh karena itu, ada kemungkinan sistem mengandung cacat yang belum dieksekusi. Cacat (sinonim dari kesalahan) adalah kesalahan manusia yang tidak terdeteksi selama pengembangan perangkat lunak, jaminan kualitas (QA), atau pengujian. Kesalahan dapat ditemukan dalam dokumentasi, instruksi kode sumber perangkat lunak, eksekusi logis dari kode, atau di manapun dalam siklus hidup sistem.

Kesalahan/Error, Cacat/Defect, dan Kegagalan/Failure

Kesalahan
Tindakan manusia yang menghasilkan hasil yang salah (ISO 24765) [ISO 17a].

Cacat
1) Masalah (sinonim kesalahan) yang, jika tidak diperbaiki, dapat menyebabkan aplikasi gagal atau menghasilkan hasil yang salah. (ISO 24765) [ISO 17a].

2) Ketidaksempurnaan atau kekurangan pada komponen perangkat lunak atau sistem yang dapat mengakibatkan komponen tersebut tidak menjalankan fungsinya, misalnya definisi data atau instruksi kode sumber yang salah. Cacat, jika dijalankan, dapat menyebabkan kegagalan perangkat lunak atau komponen sistem (ISTQB 2011 [IST 11]).

Kegagalan
Pengakhiran kemampuan produk untuk melakukan fungsi yang diperlukan atau ketidakmampuannya untuk melakukan dalam batas yang ditentukan sebelumnya (ISO 25010 [ISO 11i])

 

 

Figure1.3 menunjukkan hubungan antara kesalahan, cacat, dan kegagalan dalam siklus hidup perangkat lunak. Kesalahan mungkin muncul selama tahap uji kelayakan dan perencanaan awal perangkat lunak baru. Kesalahan ini menjadi cacat ketika dokumen telah disetujui dan kesalahan tidak diketahui. Cacat dapat ditemukan di kedua produk perantara (seperti spesifikasi dan desain persyaratan) dan kode sumber itu sendiri. Kegagalan terjadi ketika produk perantara atau perangkat lunak yang rusak digunakan.

 

 Figur 3 : Kesalahan, cacat, dan kegagalan dalam siklus hidup perangkat lunak. Sumber: Galin (2017). [GAL 17]. Diadaptasi dengan izin dari Wiley-IEEE Computer Society Press.

 

Kasus Kesalahan, Cacat, dan Kegagalan

Kasus 1: Sebuah apotek lokal menambahkan persyaratan perangkat lunak ke mesin kasirnya untuk mencegah penjualan lebih dari $75 kepada pelanggan yang berutang lebih dari $200 pada kartu kredit apotek mereka. Pemrogram tidak sepenuhnya memahami spesifikasi dan membuat batas penjualan $500 dalam program. Cacat ini tidak pernah menyebabkan kegagalan karena tidak ada klien yang dapat membeli barang senilai lebih dari $500 karena kartu kredit apotek memiliki batas $400.

Kasus 2: Pada tahun 2009, program loyalitas diperkenalkan kepada klien American Signature, pemasok furnitur besar. Spesifikasi menjelaskan aturan bisnis berikut: pelanggan yang melakukan pembelian bulanan yang lebih tinggi dari jumlah rata-rata pembelian bulanan untuk semua pelanggan akan dianggap sebagai Pelanggan Pilihan. Preferred Customer akan diidentifikasi saat melakukan pembelian, dan akan langsung diberikan hadiah atau diskon besar sebulan sekali. Cacat yang dimasukkan ke dalam 

sistem (karena pemahaman yang buruk tentang algoritme untuk menyiapkan persyaratan ini) hanya mencakup jumlah rata-rata pembelian saat ini dan bukan riwayat bulanan pelanggan. Pada saat kegagalan perangkat lunak, mesin kasir mengidentifikasi terlalu banyak Klien Pilihan, yang mengakibatkan kerugian bagi perusahaan.

Kasus 3: Peter menguji program Patrick ketika Patrick pergi. Dia menemukan cacat dalam perhitungan untuk rencana tabungan pensiun yang dirancang untuk menerapkan undang-undang pembebasan pajak baru untuk jenis investasi ini. Dia menelusuri kesalahan kembali ke spesifikasi proyek dan memberitahu analis. Dalam hal ini, aktivitas pengujian dengan benar mengidentifikasi cacat dan sumber kesalahan.

Tiga kasus di atas dengan benar menggunakan istilah untuk menggambarkan masalah kualitas perangkat lunak. Mereka juga mengidentifikasi masalah yang diselidiki oleh peneliti di bidang kualitas perangkat lunak untuk menemukan cara membantu menghilangkan masalah ini:

1. Kesalahan dapat terjadi di salah satu fase pengembangan perangkat lunak sepanjang siklus hidup.

2. Cacat harus diidentifikasi dan diperbaiki sebelum menjadi kegagalan.

3. Penyebab kegagalan, cacat, dan kesalahan harus diidentifikasi.

 

Siklus hidup / life cycle

Siklus Hidup

Evolusi sistem, produk, layanan, proyek, atau entitas buatan manusia lainnya dari konsepsi hingga pensiun.

Siklus Hidup Pengembangan

Proses siklus hidup perangkat lunak yang berisi kegiatan analisis kebutuhan, desain, pengkodean, integrasi, pengujian, instalasi, dan dukungan untuk penerimaan produk perangkat lunak.

ISO 12207 [ISO 17]

 

Selama pengembangan perangkat lunak, cacat terus-menerus ditemukan secara tidak sengaja dan harus ditemukan dan diperbaiki sesegera mungkin. Hal itu akan berguna untuk mengumpulkan dan menganalisis data tentang cacat yang ditemukan serta perkiraan jumlah cacat yang tersisa di perangkat lunak. Dengan demikian, kita dapat meningkatkan proses rekayasa perangkat lunak dan, pada gilirannya, meminimalkan jumlah cacat yang ditemukan pada versi baru produk perangkat lunak di masa depan.

Metode untuk mengklasifikasikan cacat telah dibuat untuk tujuan ini, salah satunya dijelaskan dalam bab tentang verifikasi dan validasi.

 

Lubang Tak Terdeteksi di Lapisan Ozon

Lubang di lapisan ozon di atas Antartika tidak diketahui untuk waktu yang lama karena perangkat lunak analisis data TOMS yang digunakan oleh NASA sebagai bagian dari proyeknya untuk memetakan lapisan ozon telah dirancang untuk mengabaikan nilai yang menyimpang secara signifikan dari pengukuran yang diantisipasi.

Proyek ini diluncurkan pada tahun 1978, tetapi baru pada tahun 1985 lubang itu ditemukan, dan bukan oleh NASA. Setelah menganalisis data, NASA mengkonfirmasi kesalahan desain ini.

http://earthobservatory.nasa.gov/Features/RemoteSensingAtmosphere/remote_sensing5.php

 

 

Bergantung pada model bisnis organisasi Kita, Kita harus mengizinkan berbagai tingkat upaya dalam mengidentifikasi dan memperbaiki cacat. Sayangnya, saat ini ada budaya toleransi tertentu untuk ke-cacat-an perangkat lunak. Namun, tidak diragukan lagi bahwa kita semua ingin Airbus, Boeing, Bombardier, dan Embraer mengidentifikasi dan memperbaiki semua cacat pada perangkat lunak untuk pesawat mereka sebelum kita menaikinya! Cukup menakutkan kan kalau kita menaiki maskapai mereka, sementara potensi resiko dari permasalahan software tidak terjamin?

Banyak peneliti telah mempelajari sumber kesalahan perangkat lunak dan telah menerbitkan penelitian yang mengklasifikasikan kesalahan perangkat lunak berdasarkan jenisnya untuk mengevaluasi frekuensi setiap jenis kesalahan. Beizer (1990) [BEI 90] memberikan penelitian yang menggabungkan hasil beberapa penelitian lain untuk memberikan indikasi asal kesalahan. Berikut adalah rangkuman daftar hasil penelitian ini [BEI 90].

• 25% struktural;

• 22% data;

• 16% fungsionalitas diimplementasikan;

• 10% konstruksi/pengkodean;

• 9% integrasi;

• 8% persyaratan/spesifikasi fungsional;

• 3% definisi/tes berjalan;

• 2% arsitektur/desain;

• 5% tidak ditentukan.

Peneliti juga mencoba untuk menentukan berapa banyak kesalahan yang dapat ditoleransi dalam perangkat lunak yang khas. McConnell (2004) [MCC 04] menyarankan bahwa jumlah ini bervariasi berdasarkan kualitas dan kematangan proses rekayasa perangkat lunak serta pelatihan dan kompetensi pengembang. Semakin matang prosesnya, semakin sedikit kesalahan yang dimasukkan ke dalam siklus hidup pengembangan perangkat lunak. Humphrey (2008) [HUM 08] juga mengumpulkan data dari banyak pengembang. Dia menemukan bahwa seorang pengembang tanpa sadar menciptakan sekitar 100 cacat untuk setiap 1000 baris kode sumber yang ditulis. Selain itu, ia mencatat variasi besar untuk sekelompok 800 pengembang berpengalaman, yaitu dari kurang dari 50 cacat hingga lebih dari 250 cacat yang disuntikkan per 1000 baris kode. Di Rolls-Royce, produsen mesin pesawat, variasi yang dipublikasikan adalah dari 0,5 hingga 18 cacat per 1000 baris kode sumber [NOL 15]. Penggunaan proses yang proven / andal, pengembang yang kompeten dan terlatih, dan penggunaan kembali komponen perangkat lunak yang proven / andal dapat sangat mengurangi jumlah kesalahan perangkat lunak.

McConnell juga merujuk penelitian lain yang sampai pada kesimpulan berikut:

• Cakupan sebagian besar cacat sangat terbatas dan mudah diperbaiki.

• Banyak cacat terjadi di luar aktivitas pengkodean (misalnya, persyaratan, aktivitas arsitektur).

• Pemahaman yang buruk tentang desain adalah masalah yang berulang dalam studi kesalahan pemrograman.

• Merupakan ide bagus untuk mengukur jumlah dan asal cacat di organisasi Kita untuk menetapkan target perbaikan.

Oleh karena itu, kesalahan adalah penyebab utama kualitas perangkat lunak yang buruk. Penting untuk mencari penyebab kesalahan dan mengidentifikasi cara untuk mencegah kesalahan ini di masa mendatang. Seperti yang telah kita tunjukkan pada Gambar 1.3, kesalahan dapat terjadi pada setiap langkah siklus hidup perangkat lunak: kesalahan dalam persyaratan, kode, dokumentasi, data, pengujian, dll. Penyebabnya hampir selalu kesalahan manusia yang dibuat oleh klien, analis, desainer , insinyur perangkat lunak, penguji, atau pengguna. SQA perlu mengembangkan klasifikasi penyebab kesalahan perangkat lunak berdasarkan kategori yang dapat digunakan oleh semua orang yang terlibat dalam proses rekayasa perangkat lunak.

Sebagai contoh, berikut adalah delapan kategori penyebab kesalahan yang populer:
1) Masalah dalam mendefinisikan persyaratan;
2) Menjaga komunikasi yang efektif antara klien dan pengembang;
3) Penyimpangan dari spesifikasi;
4) Kesalahan arsitektur dan desain;
5) Kesalahan pengkodean (termasuk kode uji);
6) Ketidakpatuhan terhadap proses/prosedur saat ini;
7) Ulasan dan tes yang tidak memadai;
8) Kesalahan dokumentasi.

 

Penjelasan terhadap 8 kategori penyebab permasalahana diatas akan dibahas pada postingan berikutnya, yaitu bagian 4.