Kajian perangkat lunak adalah suatu "filkter" bagi proses perangkat lunak yaitu kajian yang diterapkan pada berbagai titik selama pengembangan perangkat lunak dan berfungsi untuk mencari kesalahan yang kemudian akan dihilangkan.
 |
| Kajian Perangkat Lunak |
Pengaruh Biaya Cacat Terhadap Perangkat Lunak
· IEEE Standar Distioning of Electrical and electronic Terms (IEEE Standar 100 - 1992) mendefinisikan cacat sebagai "suatu anomaly produk".
· Definisi untuk kesalahan dalam konteks dapat diternukan claim IEEE Standard 610.12 - 1990.
Cacat (defect) dan kesalahan (fault) adalah sinonim
Penguatan dan Penghilangan Cacat
Model penguatan cacat dapat digunakan untuk menggambarkan pemunculan dan pendeteksian kesalahan selama desain awal, desain detail dan langkah pengkodean proses rekayasa perangkat lunak.Jaminan Kualitas Statistik (SQS)
Jaminan Kualitas Statistik mencerminkan trend yang sedang tumbuh di seluruh industri untuk menjadi lebih kuantitatif terhadap kualitas.
Pada perangkat lunak, jaminan kualitas statistik mengimplikasikan langkah-langkah berikut ini:
- Informasi tentang cacat perangkat lunak dikumpulkan dan dipilah-pilahkan.
- Melakukan suatu usaha untuk menelusuri masing-masing cacat sampai ke penyebab pokoknya.
- Dengan menggunakan prinsip Pareto (80 persen cacat dapat ditelusuri sampai 20 persen dari semua kemungkinan penyebab), mengisolasi yang 20 persen tersebut (vital few)
- Sekali penyebab vital few telah diidentifikasi, beralih untuk membetulkan maslah yang menyebabkan cacat.
Banyak kesalahan ditemukan pada waktu perangkat lunak sedang dalam proses pengembangan. Cacat yang lain ditemukan setelah perangkat lunak diluncurkan kepada pemakai akhir. Meskipun ratusan kesalahan yang berbeda diluncurkan, semuanya dapat ditelusuri dari satu (atau lebih) penyebab berikut ini :
1) Spesifikasi yang tidak lengkap atau keliru (IES)
2) Kesalahan interpretasi komunikasi pelanggan (MMC)
3) Deviasi intersioanl dari spesifikasi (IDS)
4) Pelanggaran standar pemrograman (VPS)
5) Kesalahan dalam representasi data (EDRIMI)
6) Kesalahan dalam logika desain (EDL)
7) Interface modul yang tidak konsisten (IMI)
8) Pengujian yang tidak lengkap atau keliru (IET)
9) Dokumentasi yang tidak lengkap atau tidak akurat (IID)
10) Kesalahan dalam penerjemahan bahasa pemrograman desain (PLT)
11) Antarmuka manusia dengan komputer yang tidak konsisten atau mengandung ambiguitas (HCI)
12) Dan masih banyak lagi (MIS)
Reliabilitas Perangkat Lunak
 |
| Reliabilitas Preangkat Lunak |
Reliabilitas perangkat lunak, tidak seperti faktor kualitas yang lain, dapat diukur, diarahan, dan diestimasi dengan menggunakan data pengembangan historis. Reliabilitas perangkat lunak didefinisikan dalam bentuk statistik sebagai "kemungkinan operasi program komputer bebas kegagalan di dalam suatu lingkungan tertentu dan waktu tertentu".
Kapan saja rehabilitas perangkat lunak dibicarakan, selalu muncul pertanyaan yang sangat penting : Apa yang dimaksudkan dengan bentuk kegagalan dalam konteks dan banyak diskusi mengenai kualitas dan reliabilitas perangkat lunak, kegagalannlah ketidaksesuaian dengan kebutuhan perangkat lunak.
Kegagalan hanya akan mengganggu atau bahkan merupakan bencana. Satu kegagalan dapat diperbaiki dalam beberapa detik sementara kesalahan yang lain mungkin membutuhkan waktu pembetulan berminggu-minggu atau bahkan berbulan-bulan.
Pembetulan satu kegagalan kenyataannya dapat menghasilkan kesalahan lain yang baru yang mungkin akan membawa lagi kesalahan yang lain lagi.
Pengukuran Reliabilitas dan Availabilitas
Kerja awal dalam rehabilitas perangkat lunak berusaha mengekstrapolasi matematika teori reliabitas perangkat keras. Sebagian besai model reliabilitas yang berhubungan dengan perangkat keras didasarkan pada kegagalan sehubungan dengan keusangan (wear), bukan kesalahan karena cacat desain. Dalam perangkat keras, kegagalan sehubungan dengan keusangan fisik (mIsalnya pengaruh suhu, korosi, kejutan) lebih banyak terjadi daripada kegagalan karena isu, Aksn tetapi, yang terjadi pada perangkat lunak adalah hal yang sebaliknya. Kenyataannya, soma kegagalan perangkat lunak dapat ditelusuri ke dalam desain atau masalah implementasi; keusangan tidak tercakup.
Masih ada perdebatan yang teriadi di seputar hubunan antara konsep kunci dalam reliabilitas perangkat keras dan kermunpuan aplikasinya terhadap perangkat lunak. Meskipun ada hubungan yang tidak dapat dibantah, namun sangat penting untuk mempertimbangkan beberapa konsep sederhana yang berlaku untuk kedua sistem elemen tersebut.
Bila kites andaikan suatu sistern yang berbasis komputer, pengukuran reliabilitas secara sederhana adalah berupa mean time between failure (MTBF), dimana
MTBF = MTTF + MTTR
(Akronim MTTF adalah mean time to failure dan MTR berarti mean time to repair.)
Banvak penditi berpendapat bahwa MTBF merupakan pengukuran yang jauh lebih berguna daripada pengukuran cacat/KLOC. secara sederhana dapat dikatakan bahwa seorang pemakai akhir lebih memperhatikan kegagalan, bukan jumlah cacat, Karena masing-masing cacat yangada pada sebuah program tidak memiliki tingkat kegagalan yang salsa, maka penghitungan cacat total hanya memberikan sedikit indikasi tentang reliabifitas sisteem.
Contohnya adalah sebuah program yang telah beroperasi selama 14 bulan. Banyak cacat mungkin tidak terdeteksi dalam jumlah waktu yang lama sampai pada akhirnya cacat itu ditemukan. MTBF dari cacat yang tidak jelas seperti itu dapat berlangsung sampai 50, bahkan 100 tahun. Cacat yang lain, yang juga belum diternukan, dapat memiliki tingkat kegagalan 18 atau 24 bulan. Meskipun setiap kategori pertama cacat (yang niemiliki MTBF panjang) dihilangkan, pengaruhnya pada reliabilitas perangkat lunak tidak dapat diabaikan.
Availabilitas perangkat lunak adalah kemungkinan sebuah program beroperasi sesuai dengan kebutuhan pada s, suatu titik yang diberikan pada suatu waktu dan didefinisikan sebagai
= MTTF / (MTTF + MTTR) x 100 %
Pengukuran reltabilitas MTBF sama sensitifnyt dengan MTTF dan MTTR. Pengukuran availabilitas jauh lebih sensitif daripada MTTR, yang merupakan pengukuran tidak langsung terhadap kemampuan perneliharaan perangkat lunak.
EmoticonEmoticon