9. Software Quality Assurance

Presentasi berjudul: "9. Software Quality Assurance"— Transcript presentasi:

1 9. Software Quality Assurance
9.1 Ruang Lingkup 9.2 Konsep Kualitas 9.2.1 Kualitas 9.2.2 Kontrol Kualitas 9.2.3 Jaminan Kualitas 9.2.4 Biaya Kualitas 9.3 Aktivitas SQA 9.4 Kajian Perangkat Lunak (Software Review) 9.5 Dampak Defects Software thd. Biaya 9.6 Kajian Teknik Formal (Formal Technical Review) 9.7 Review 9.7.1 Review Meeting 9.7.2 Laporan Review 9.7.3 Pedoman Review 9.8 Reliabilitas Perangkat Lunak 9.8.1 Reliabilitas (kehandalan) 9.8.2 Pengukuran Reliabilitas & Availabilitas 9.9 Software Safety & Hazard Analysis 9.10 Rencana SQA

2 9.1 Ruang Lingkup Tujuan utama dari rekayasa perangkat lunak adalah menghasilkan perangkat lunak yang berkualitas tinggi Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang diaplikasikan pada seluruh proses perangkat lunak, yang meliputi: pendekatan manajemen kualitas teknologi rekayasa perangkat lunak yang efektif (metode) kajian teknik formal yang diaplikasikan pada keseluruhan proses perangkat lunak strategi pengujian multitiered kontrol dokumentasi perangkat lunak dan perubahan yang dibuat untuknya prosedur untuk menjamin kesesuaian dengan standar pengem-bangan perangkat lunak mekanisme pengukuran dan pelaporan

3 9.2 Konsep Kualitas 9.2.1 Kualitas
Kualitas (menurut American Heritage Dictionary) adalah sebuah karakteristik atau atribut dari sesuatu yang dapat diukur, dibandingkan dengan standar yang diketahui. Berdasarkan pada sifat pengkurannya, ada dua jenis kualitas yang ada, yaitu kualitas desain dan kualitas konformansi. Kualitas desain mengacu pada karakteristik tertentu yang ditentukan oleh desainer terhadap item tertentu. Desain berkualitas bila produk yang dihasilkan sesuai dengan spesifikasi yang ditentukan. Kualitas desain mencakup syarat, spesifikasi dan desain sistem. Kualitas konformansi adalah tingkat spesifikasi desain yang terus diikuti selama pembuatan. Semakin tinggi tingkat konformansi, semakin tinggi tingkat kualitas konformasi. Kualitas konformansi difokuskan pada implementasi, jika implementasi mengikuti desain, dan sistem yang dihasilkan memenuhi persyaratan dan kinerja, maka kualitas konformasi menjadi tinggi.

4 9.2.2 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. Kontrol kualitas mencakup loop (kalang) umpan balik pada proses yang menciptakan produk kerja dengan membandingkan output dari setiap proses dengan spesifikasi yang telah ditetapkan.

5 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 dan konfidensi bahwa kualitas produk dapat memenuhi sasaran.

6 9.2.4 Biaya Kualitas Biaya kualitas menyangkut semua biaya yang diadakan untuk menampilkan kualitas yang berhubungan dengan aktivitas. Biaya kualitas dapat dibagi ke dalam biaya yang dihubungkan dengan pencegahan, penilaian, dan kegagalan. Biaya pencegahan meliputi perencanaan kualitas kajian teknis formal (FTR) perlengkapan pengujian pelatihan Biaya penilaian meliputi inspeksi dalam suatu proses dan interproses pemeliharaan dan kalibrasi peralatan pengujian Biaya kegagalan meliputi Internal (sebelum penyerahan produk) pengerjaan kembali perbaikan analisis mode kegagalan Eksternal (setelah penyerahan produk) resolusi keluhan penggantian dan pengembalian produk dukungan help line jaminan

7 9.3 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 bertanggungjawab terhadap perencanaan jaminan kualitas, kesalahan, penyimpanan rekaman, analisis, dan pelaporan Aktivitas oleh kelompok SQA: menyiapkan rencana SQA untuk suatu proyek; berpartisipasi dalam deskripsi proses pengembangan proyek; mengkaji aktivitas perangkat lunak untuk memverifikasi pemenuhan proses perangkat lunak yang sudah ditentukan; meng-audit produk kerja perangkat lunak yang ditentukan untuk membuktikan kesesuaian dengan produk kerja yang ditentukan tersebut sebagai bagian dari proses perangkat lunak; memastikan bahwa deviasi pada kerja dan produk kerja perangkat lunak didokumentasi dan ditangani sesuai prosedur pendokumentasian; mencatat ketidakssesuaian dan melaporkannya kepada manajemen senior.

8 9.4 Kajian Perangkat Lunak (Software Review)
Software reviews adalah sebuah filter untuk proses rekayasa perangkat lunak. Reviews dilaksanakan di berbagai titik selama pengembangan perangkat lunak dan membantu menemukan error yang kemudian dapat dihilangkan. Software reviews membantu untuk memurnikan produk kerja perangkat lunak yang terjadi sebagai suatu hasil dari analisis, desain, dan coding. FTR (Formal Technical Review) atau disebut walkthrough adalah filter yang paling efektif untuk meningkatkan kualitas PL.

9 9.5 Dampak Defects Software thd. Biaya
Dalam kontek proses PL, istilah defect dan fault adalah sinonim. Keduanya menyatakan secara tidak langsung suatu problem kualitas yang ditemukan setelah PL dirilis kepada end users. Sasaran utama dari FTR adalah menemukan errors selagi proses PL berjalan sehingga tidak menjadi defect setelah PL dirilis. Keuntungan sesungguhnya dari FTR adalah menemukan error sedini mungkin sehingga error tsb tidak menjalar ke langkah berikutnya dalam proses PL. Sejumlah studi menunjukkan bahwa kegiatan desain mengintrodusir error antara 50% dan 65% dari seluruh error (dan pada akhirnya, seluruh defect) selama proses PL. FTR telah menunjukkan bahwa sampai 75% efektif dalam menemukan cacat-cacat desain. Dengan mendeteksi dan menghapus sejumlah besar persentase error, proses review secara subtansial mengurangi biaya pada langkah-langkah selanjutnya dalam phase-phase pengembangan dan maintenance.

10 9.6 Kajian Teknik Formal (Formal Technical Review)
FTR adalah aktivitas jaminan kualitas perangkat lunak yang dilakukan oleh perekayasa perangkat lunak. Tujuan FTR adalah: menemukan error dalam fungsi, logika, atau implementasinya dalam berbagai representasi perangkat lunak; memverifikasi bahwa perangkat lunak yang direview memenuhi syarat; memastikan bahwa perangkat lunak tersebut telah direpresentasikan sesuai dengan standard yang telah ditentukan sebelumnya; untuk mencapai perangkat lunak yang dikembangkan dengan cara yang seragam; membuat proyek lebih mudah dikelola.

11 9.7 Review 9.7.1 Review Meeting Review meeting (pertemuan kajian) adalah pertemuan tim review produk kerja perangkat lunak yang terdiri dari 3 sampai 5 orang guna mengkaji dan mengevaluasi perangkat lunak yang telah dihasilkan. Diakhir review, tim harus memutuskan apakah: menerima hasil kerja tersebut tanpa modifikasi lebih lanjut. menolak hasil kerja tersebut karena adanya kesalahan yang fatal, atau menerima hasil kerja tersebut secara sementara (error2 kecil telah ditemukan dan harus dikoreksi; tetapi tidak perlu direview lagi).

12 9.7.2 Laporan Review Ada 2 dokumen yg dihasilkan dalam review meeting yaitu daftar masalah review (review issues list) dan laporan rangkuman review (review summary report). Review summary report memuat jawab dari 3 pertanyaan berikut: (1) apa yg telah direview, (2) siapa yg telah mereviewnya, dan (3) apa yang telah ditemukan & apa kesimpulannya. Review issues list berisi hal2 yang berguna dlm: (1) mengidentifikasi area problem, dan (2) bertindak sebagai action item checklist untuk memandu produsen dalam melakukan koreksi.

13 9.7.3 Pedoman Review Review produk, bukan produser
Menetapkan agenda dan tetap menjaganya Membatasi perdebatan dan bantahan Menetapkan area masalah, tetapi tidak mencoba untuk menyelesaikan setiap masalah yang dicatat Buat catatan tertulis Membatasi jumlah peserta dan lakukan persiapan awal Buat sebuah daftar utk setiap work product yang direview. Alokasikan sumber-sumber daya dan jadwal waktu untuk FTR. Lakukan pelatihan yang berguna bagi semua reviewer. Review hasil-hasil review yang baru saja dilakukan.

14 9.8 Reliabilitas Perangkat Lunak
9.8.1 Reliabilitas (kehandalan) Reliabilitas perangkat lunak didefinisikan sebagai probabilitas operasi komputer bebas kegagalan dalam suatu lingkungan tertentu dan waktu tertentu. Misal suatu PL memiliki reliabilitas 0,96 pada 8 jam eksekusi, berarti apabila PL tsb dieksekusi 100 kali selama 8 jam dia akan beroperasi dg benar 96 kali. Kehandalan perangkat lunak dapat diukur, diarahkan, dan diestimasi dengan menggunakan data pengembangan historis.

15 9.8.2 Pengukuran Reliabilitas & Availabilitas
Dalam kenyataannya, semua kegagalan perangkat lunak dapat dilacak dari problem-problem desain atau implementasi. Untuk sebuah sistem berbasis komputer, pengukuran sederhana kehandalan adalah berupa Mean Time Between Failure (MTBF), MTBF = MTTF + MTTR (MTTF : mean time to failure dan MTTR : mean time to repair) Software availability adalah probabilitas bahwa sebuah program beroperasi berdasarkan persyaratannya pada suatu titik tertentu pada suatu waktu dan didefinisikan sebagai: Availability = {MTTF/(MTTF + MTTR)} x 100%

16 9.9 Software Safety & Hazard Analysis
Keamanan perangkat lunak dan analisis risiko adalah aktivitas SQA yang memfokuskan pada identifikasi & penilaian hazard (risiko) potensial yang mungkin berpengaruh negatif terhadap perangkat lunak dan menyebabkan seluruh sistem menjadi gagal (fail). Bila risiko dapat diidentifikasi pada awal proses rekayasa perangkat lunak, maka ciri-ciri desain perangkat lunak dapat ditetapkan shg akan mengeliminasi risiko potensial.

17 9.10 Rencana SQA SQA plan adalah peta jalan untuk membangun jaminan kualitas perangkat lunak. SQA plan berfungsi sebagai template bagi aktivitas SQA yang dibangun untuk setiap proyek perangkat lunak. Rencana SQA dicatat dalam dokumen produk kerja yang mencakup: dokumen proyek (rencana proyek); model (ERD); dokumen teknis (spesifikasi, rencana pengujian); dokumen pemakai (file-file help). ***