JAMINAN KUALITAS PERANGKAT LUNAK
Software Quality Assurance [SQA]
Jaminan kualitas
perangkat lunak adalah aktivitas pelindung yang diaplikasikan pada seluruh
proses perangkat lunak.
SQA meliputi :
1. pendekatan
manajemen kualitas
2. teknologi
rekayasa perangkat lunak yang efektif (metode dan peranti)
3. kajian teknik
formal yang diaplikasikan pada keseluruhan proses perangkat lunak
4. strategi
pengujian multitiered (deret bertingkat)
5. kontrol
dokumentasi perangkat lunak dan perubahan
6. prosedur
untuk menjamin kesesuaian dengan standar pengembangan perangkat lunak
7. mekanisme
pengukuran dan pelaporan.
Kontrol Kualitas
Kontrol
kualitas merupakan serangkaian pemeriksaan, kajian, dan pengujian yang
digunakan pada keseluruhan siklus pengembangan untuk memastikan bahwa setiap produk
memenuhi persyaratan yang ditetapkan.
Konsep
kunci kualitas kontrol adalah bahwa semua produk kerja memiliki spesifikasi
yang telah ditentukan dan dapat diukur dimana kita dapat membandingkan output
dari setiap proses.
Jaminan Kualitas
Jaminan kualitas
terdiri atas fungsi auditing dan pelaporan manajemen.
Tujuan jaminan kualitas adalah :
untuk memberikan
data yang diperlukan oleh manajemen untuk menginformasikan masalah kualitas
produk, sehingga dapat memberikan kepastian & konfidensi bahwa
kulitas produk
dapat memenuhi sasaran.
Biaya Kualitas
Biaya kualitas
menyangkut semua biaya yang diadakan untuk mengejar kualitas atau untuk
menampilkan kualitas yang berhubungan dengan aktivitas. Studi tentang biaya
kualitas dilakukan untuk memberikan garis dasar bagi biaya kualitas yang sedang
digunakan, untuk mengidentifikasi kemungkinan pengurangan biaya kualitas serta
memberikan basis perbandingan yang ternormalisasi.
Biaya kualitas
dapat dibagi ke dalam biaya-biaya yang dihubungkan dengan :
a) Biaya
pencegahan meliputi :
•
Perencanaan
•
Kajian teknis formal
•
Perlengkapan pengujian
•
Pelatihan
b) Biaya
penilaian meliputi :
•
Inspeksi in-proses dan interproses
•
Pemeliharaan dan kalibrasi peralatan
•
Pengujian
c) Biaya
kegagalan
Biaya
kegagalan adalah biaya yang akan hilang bila tidak ada cacat yang muncul
sebelum produk disampaikan kepada pelanggan.
Biaya
kegagalan internal adalah biaya yang diadakan bila kita mendeteksi suatu
kesalahan dalam produk sebelum produk dipasarkan. Biaya kegagalan internal
meliputi:
• Pengerjaan
kembali
• Perbaikan
• Analisis mode
kegagalan
Biaya
kegagalan eksternal adalah biaya yang berhubungan dengan cacat yang ditemukan setelah
produk disampaikan kepada pelanggan. Biaya kegagalan eksternal meliputi:
• Resolusi
keluhan
• Penggantian
dan pengembalian produk
• Dukungan help
line
• Kerja jaminan
Biaya
relatif mendapatkan dan membetulkan cacat bertambah secara dramatis pada saat
kita melangkah dari pencegahan ke pendeteksian dan dari kegagalan internal ke kegagalan
eksternal.
Jaminan Kualitas Perangkat Lunak
Kualitas
perangkat lunak didefinisikan sebagai konformansi terhadap kebutuhan fungsional
dan kinerja yang dinyatakan secara eksplisit, standar perkembangan yang
didokumentasikan secara eksplisit, dan karakteristik implisit yang diharapkan
bagi semua perangkat lunak dikembangkan secara profesional. definisi tersebut
berfungsi untuk menekankan tiga hal penting, yaitu:
1.
Kebutuhan
perangkat lunak merupakan fondasi yang melaluinya kualitas diukur.
2.
Standar
yang telah ditentukan menetapkan serangkaian kriteria pengembangan yang
menuntun cara perangkat lunak direkayasa.
3.
Ada
serangkaian kebutuhan implisit yang sering dicantumkan (misalnya kebutuhan akan
kemampuan pemeliharaan yang baik).
Kelompok
SQA berfungsi sebagai perwakilan in-house pelanggan, yaitu orang yang akan
melakukan SQA harus memperhatikan perangkat lunak dari sudut pandang pelanggan.
Kelompok SQA harus dapat menjawab pertanyaan-pertanyaan dibawah ini untuk
memastikan bahwa kualitas perangkat lunak benar-benar terjaga.
1.
Apakah
perangkat lunak cukup memenuhi factor kualitas
2.
Sudahkah
pengembangan perangkat lunak dilakukan sesuai dengan standar yang telah ditetapkan
sebelumnya?
3.
Sudahkah
disiplin teknik dengan tepat memainkan perannya sebagi bagian dari aktivitas SQA?
Aktivitas SQA
Jaminan
kualitas perangkat lunak terdiri dari berbagai tugas yang berhubungan dengan
dua konstituen yang berbeda :
–
perekayasa
perangkat lunak yang mengerjakan kerja teknis
–
kelompok
SQA yang bertanggung jawab terhadap perencanaan jaminan kualitas, kesalahan,
penyimpanan rekaman, analisis, dan pelaporan.
Tugas
kelompok SQA adalah membantu tim rekayasa perangkat lunak dalam pencapaian
produk akhir yang berkualitas tinggi. Aktivitas yang dilakukan (atau
difasilitasi) oleh kelompok
SQA yang
independen:
1.
Menyiapkan
rencana SQA untuk suatu proyek.
Rencana
tersebut mengindentifikasikan hal-hal berikut:
ü Evaluasi yang
dilakukan
ü Audit dan kajian
yang dilakukan
ü Standar yang
dapat diaplikasikan pada proyek
ü Prosedur untuk
pelaporan & penelusuran kesalahan
ü Dokumen yang
dihsilkan oleh kelompok SQA
ü Jumlah umpan
balik yang diberikan pada tim proyek perangkat lunak
2.
Berpartisipasi
dalam pengembangan deskripsi proses pengembangan proyek.
3.
Mengkaji
aktivitas rekayasa perangkat lunak untuk memverifikasi pemenuhan proses
perangkat lunak yang sudah ditentukan.
4.
Mengaudit
produk kerja perangkat lunak yang ditentukan untuk membuktikan kesesuaian
dengan produk kerja yang ditentukan tersebut sebagai bagian dari proses
perangkat lunak.
5.
Memastikan
bahwa deviasi pada kerja dan produk perangkat lunak didokumentasikan & di-
tangani sesuai dengan rosedur pendokuementasian.
6.
Mencatat
ketidak-sesuaian dan melaporkannya kepada manajemen senior.
7.
Mengkoordinasi
kontrol dan manajemen perubahan, dan membantu mengumpulkan dan menganalisis metrik
perangkat lunak.
Kajian Perangkat Lunak
Kajian
perangkat lunak merupakan salah satu aktivitas SQA yang terpenting. Kajian
perangkat lunak adalah suatu filter bagi proses rekayasa perangkat lunak, yaitu
kajian yg diterapkan pada berbagai titik selama pengembangan PL & berfungsi
untuk mencari kesalahan yg kemudian akan dihilangkan. Kajian perangkat lunak
berfungsi untuk “memurnikan” produk kerja perangkat lunak yang terjadi sebagai
hasil dari analisis, desain, dan pengkodean.
Jaminan Kualitas Statistik (SQA)
Jaminan
kualitas statistik mencerminkan trend yang sedang tumbuh di seluruh industri
untuk menjadi lebih kuantitatif terhadap kualitas. Pada perangkat lunak,
jaminan kualitas statistic mengimplikasikan langkah-langkah berikut ini:
1.
Informasi
tentang cacat perangkat lunak dikumpulkan dan dipilah-pilahkan.
2.
Melakukan
suatu usaha untuk menelusuri masingmasing cacat sampai ke penyebab pokoknya.
3.
Dengan
menggunakan prinsip Pareto (80 persen cacat dapat ditelusuri sampai 20 persen dari
semua kemungkinan penyebab), mengisolasi yang 20 persen tersebut (vital few)
4.
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 :
• Spesifikasi
yang tidak lengkap atau keliru (IES)
• Kesalahan
interpretasi komunikasi pelanggan (MMC)
• Deviasi
intersioanl dari spesifikasi (IDS)
• Pelanggaran
standar pemrograman (VPS)
• Kesalahan
dalam representasi data (EDRIMI)
• Kesalahan
dalam logika desain (EDL)
• Interface
modul yang tidak konsisten (IMI)
• Pengujian yang
tidak lengkap atau keliru (IET)
• Dokumentasi
yang tidak lengkap atau tidak akurat (IID)
• Kesalahan
dalam penerjemahan bahasa pemrograman desain (PLT)
• Antarmuka
manusia dengan komputer yang tidak konsisten atau mengandung ambiguitas (HCI)
• Dan msih
banyak lagi (MIS)
Reliabilitas Perangkat Lunak
Reliabilitas
perangkat lunak, tidak seperti factor kualitas yang lain, dapat diukur,
diarahan, dan diestimasi dengan menggunakan data pengembangan historis. Reliabilitas
perangkat lunak didefinisikan dalam bentuk statistik sebagai “kemungkinan
operasi program computer bebas kegagalan di dalam suatu lingkungan tertentu dan
waktu tertentu”.
Kapan
saja reliabilitas 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, kegagalann
adalah 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 bermingguminggu 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 reliabilitas perangkat lunak berusaha mengekstrapolasi matematika
teori reliabitas perangkat keras. Sebagian besar 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. Akan tetapi, yang terjadi pada perangkat
lunak adalah hal yang sebaliknya. Kenyataannya, semua kegagalan perangkat lunak
dapat ditelusuri ke dalam desain atau masalah implementasi; keusangan tidak
tercakup. Masih ada perdebatan yang terjadi di seputar hubunan antara konsep
kunci dalam reliabilitas perangkat keras dan kemampuan aplikasinya terhadap
perangkat lunak.
Meskipun
ada hubungan yang tidak dapat dibantah, namun sangat penting untuk memprtimbangkan
beberapa konsep sederhana yang berlaku untuk kedua sistem
elemen tersebut.
Bila kita andaikan suatu sistem 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.)
Banyak
peneliti 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 yang ada pada sebuah program tidak memiliki tingkat kegagalan yang sama,
maka penghitungan cacat total hanya memberikan sedikit indikasi tentang reliabilitas
sistem. 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
ditemukan, dapat memiliki tingkat kegagalan 18 atau 24 bulan. Meskipun setiap
kategori pertama cacat (yang memiliki MTBF panjang) dihilangkan, pengaruhnya
pada reliabilitas perangkat lunak tidak dapat diabaikan.
Availabilitas
perangkat lunak adalah kemungkinan sebuah program beroperasi sesuai dengan
kebutuhan pada suatu titik yang diberikan pada suatu waktu dan didefinisikan
sebagai :
Availabilitas =
MTTF / (MTTF + MTTR) x 100 %
Pengukuran
reliabilitas MTBF sama sensitifnya dengan MTTF dan MTTR. Pengukuran
availabilitas jauh lebih sensitif daripada MTTR, yang merupakan pengukuran tidak
langsung terhadap kemampuan pemeliharaan perangkat lunak.
Keamanan Perangkat Lunak dan Analisis Risiko
Leveson
membicarakan pengaruh perangkat lunak dalam sistem kritis keamanan ketika
menulis: Sebelum perangkat lunak digunakan di dalam system kritis keamanan,
perangkat lunak itu sering dikontrol oleh alat mekanik konvensional (tidak
dapat diprogram) dan elektronik. Teknik keamanan system didesain untuk
mengatasi kegagalan acak dalam sistem-sistem tersebut.
Kesalahan
perancangan oleh manusia dapat sepenuhnya dihindari atau dihilangkan sebelum
perangkat lunak tersebut diluncurkan dan dioperasikan. Ketika perangkat lunak
diguanakn sebagai bagian dari sistem kontrol, kompleksitasnya dapat bertambah
dengan satu urutan besaran atau lebih. Kesalahan desain yang tidak kentara yang
disebabknan oleh kesalahan manusia – sesuatu yang dapat diungkapkan dan
dikurangi dalam kontrol konvensional berbasis perangkat keras – menjadi lebih
sulit ditemukan pada waktu perangkat lunak digunakan.
Keamanan
perangkat lunak dan analisis risiko adalah aktivitas jaminan kualitas perangkat
lunak yang berfokus pada identifikasi dan penilaian risiko potensial yang mungkin
berpengaruh negatif terhadap perangkat lunak dan menyebabkan seluruh sistem
menjadi gagal. Jika risiko dapat diidentifikasi pada awal proses rekayasa
perangkat lunak, maka ciri-ciri desain perangkat lunak dapat ditetapkan
sehingga akan mengeliminasi atau mengontrol risiko potensial.
Proses
analisis dan modeling dilakukan sebagai bagian dari keamanan perangkat lunak.
Awalnya, risiko diidentifikasi dan dipilah-pilahkan berdasarkan kekritisan dan
risiko. Sebagai contoh, beberapa risiko yang berkaitan dengan kontrol
peluncuran berbasis komputer untuk automobil mungkin:
• Menyebabkan
percepatan yang tidak terkontrol tidak dapat dihentikan
• Tidak lepas
ketika pedal rem ditekan
• Tidak nyambung
ketika skalar diaktifkan
• Perlahan-lahan
kehilangan atau menambah kecepatan
Setelah
risiko tingkat sistem diidentifikasi, maka digunakan teknik analisis untuk
menandai kehebatan dan probabilitas event. Supaya efektif, perangkat lunak
harus dianalisis dalam konteks keseluruhan sistem. Sebagai contoh, kesalahan input
pemakai yang tidak kentara (manusia sebagai komponen sistem) dapat diperbesar
oleh kesalahan perangkat lunak, sehingga menghasilkan data kontrol yang
memposisikan sebuah perangkat lunak, sehingga menghasilkan data kontrol yang
memposisikan sebuah perangkat mekanik secara tidak tepat. Jika ada serangkaian
kondisi lingkungan eksternal (dan hanya jika mereka ditemui), maka posisi
perangkat mekanik yang tidak tepat dapat menyebabkan kegagalan fatal. Teknik analisis
seperti analisis pohon kegagalan, logika real-time, atau model Petrinet, dapat
digunakan untuk memprediksi rantai event yang dapat mengakibatkan risiko dan kemungkinan
di mana setiap event akan terjadi untuk menciptakan rantai.
Analisis
pohon kesalahan membangun model grafis dan kombinasi event yang konkuren dan
berurutan yang dapat menyebabkan suatu event atau sistem yang penuh risiko.
Dengan menggunakan pohon kesalahan yang dikembangkan dengan baik, maka
dimungkinkan untuk meneliti kosekuensi urutan kegagalan yang terinterelasi yang
terjadi pada komponen sistem yang berbeda. Logika real-time (RTL) membangun
sebuah model sistem dengan menentukan event dan aksi yang sesuai. Model
eventaction dapat dianalisis dengan menggunakan operasi logika untuk menguji
tuntutan keamanan seputar komponen sistem dan timing-nya. Model Petrinet dapat digunakan
untuk menentukan kesalahan yang paling berisiko. Sekali risiko diidentifikasi
dan dianalisis, maka keamanan yang berhubungan dengan kebutuhan untuk perangkat
lunak dapat ditetapkan. Spesifikasi dapat berupa sederetan event yang tidak
diinginkan dan sistem
yang diinginkan
merespon event tersebut. Peran perangkat lunak dalam mengatur event yang tidak diinginkan
kemudian diindikasi.
Meskipun
reliabilitas perangkat lunak berhubungan erat satu sama lain dengan lainnya,
namun sangat penting untuk memahami perbedaan tipis yang ada di antara mereka.
Reliabilitas perangkat lunak menggunakan analisis statistik untuk menentukan
kemungkinan terjadinya kegagalan perangkat lunak. Tetapi kegagalan tidak perlu menghasilkan
risiko atau kecelakaan. Kemanan perangkat lunak mengamati bagaimana kegagalan
menimbulkan keadaan yang dapat menyebabkan kecelakaan. Kegagalan tidak perlu
dipertimbangkan di dalam ruang hampa, tetapi
dievaluasi dalam
konteks keseluruhan sistem berbasis komputer.
Rencana SQA
SQA
plan menjadi peta jalan untuk membangun jaminan kualitas perangkat lunak.
Dikembangkan oleh kelompok SQA dan tim proyek, rencana itu berfungsi sebagai template
bagi aktifitas SQA yang dibangun untuk setiap proyek perangkat lunak.
Bagian
awal menggambarkan tujuan dan ruang lingkup dokumen dan menunjukkan aktivitas
proses perangkat lunak yang diungkap oleh jaminan kualitas. Semua dokumen yang dicatat
oleh rencana SQA didaftar dan semua standar yang dapat diapliksikan dicatat.
Bagian Manajemen dari rencana tersebut menggambarkan tempat SQA pada struktur organisasi;
tugas-tugas dan aktivitas SQA dan penempatannya di seluruh proses perangkat
lunak; dan peran organisasional serta tanggung jawab relatif terhadap kualitas
produk. Bagian Dokumentasi menggambarkan (dengan refernsi) masing-masing produk
kerja yang dihasilkan sebagai bagian dari proses perangkat lunak, mencakup hal-hal
berikut :
• Dokumen proyek
(misalnya, rencana proyek)
• Model
(misalnya, hirarki kelas ERD)
• Dokumen teknis
(misalnya, spesifikasi, rencana pengujian)
• Dokumen
pemakai (misalnya file-file help)
Sebagai tambahan,
bagian ini menentukan serangkaian produk kerja minmum yang dapat diterima untuk
mencapai kualitas yang tinggi. Standar, Praktik dan Konversi mencatat semua standar/praktik
yang diterapkan selama proses perangkat lunak (misalnya, standar dokumen,
stadar pengkodean, dan pedoman kajian). Semua proyek, proses, dan metric produk
yang dikumpulkan sebagai bagian dari usaha rekayasa perangkat lunak juga harus dicatat.
Bagian Kajian dan Audit dari rencana mengidentifiaksi kajian dan audit yang
akan dilakukan oleh tim rekayasa perangkat lunak, kelompok SQA, dan pelanggan.
Bagian ini memberikan gambaran yang luas terhadap pendekatan bagi masing-masig
kajian dan audit.
