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

(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

(2)

9.1 Ruang Lingkup



Tujuan utama dari rekayasa perangkat lunak adalah

_{Tujuan utama dari rekayasa perangkat lunak adalah}

menghasilkan perangkat lunak yang berkualitas tinggi



Jaminan kualitas perangkat lunak adalah

_{Jaminan kualitas perangkat lunak adalah}

aktivitas

pelindung

yang diaplikasikan pada

seluruh proses

perangkat lunak, yang meliputi:

 pendekatan _pendekatanmanajemenmanajemen kualitas kualitas

 teknologi rekayasa perangkat lunak yang efektif (_{teknologi rekayasa perangkat lunak yang efektif (}metodemetode))

 kajian teknik formal_{kajian teknik formal} yang diaplikasikan pada keseluruhan proses yang diaplikasikan pada keseluruhan proses perangkat lunak

perangkat lunak

 strategi pengujian_{strategi pengujian} multitiered multitiered

 kontrol _kontroldokumentasidokumentasi perangkat lunak dan perubahan yang perangkat lunak dan perubahan yang dibuat untuknya

dibuat untuknya

 prosedur_prosedur untuk menjamin kesesuaian untuk menjamin kesesuaian dengan standar pengem- dengan standar pengem-bangan perangkat lunak

bangan perangkat lunak

(3)

9.2 Konsep Kualitas

9.2.1 Kualitas

 Kualitas (menurut American Heritage Dictionary) adalah sebuah Kualitas (menurut American Heritage Dictionary) adalah sebuah

karakteristik atau atribut

karakteristik atau atribut dari sesuatu yang dapat diukur, dari sesuatu yang dapat diukur, dibandingkan dengan standar yang diketahui.

dibandingkan dengan standar yang diketahui.

 Berdasarkan pada sifat pengkurannya, ada dua jenis kualitas yang Berdasarkan pada sifat pengkurannya, ada dua jenis kualitas yang ada, yaitu

ada, yaitu kualitas desainkualitas desain dan dan kualitas konformansi.kualitas konformansi.

1.

1. Kualitas desainKualitas desain mengacu pada karakteristik tertentu yang ditentukan mengacu pada karakteristik tertentu yang ditentukan oleh desainer terhadap item tertentu. Desain berkualitas bila produk oleh desainer terhadap item tertentu. Desain berkualitas bila produk yang dihasilkan sesuai dengan

yang dihasilkan sesuai dengan spesifikasi yang ditentukanspesifikasi yang ditentukan. . Kualitas desain mencakup syarat, spesifikasi dan desain sistem. Kualitas desain mencakup syarat, spesifikasi dan desain sistem.

2.

2. Kualitas konformansiKualitas konformansi adalah adalah tingkat spesifikasi desaintingkat spesifikasi desain yang yang terus terus diikuti selama pembuatan

diikuti selama pembuatan. Semakin tinggi tingkat konformansi, . Semakin tinggi tingkat konformansi, semakin tinggi tingkat kualitas konformasi.

semakin tinggi tingkat kualitas konformasi. Kualitas konformansi

Kualitas konformansi difokuskan pada implementasidifokuskan pada implementasi, jika , jika implementasi mengikuti desain, dan sistem yang dihasilkan implementasi mengikuti desain, dan sistem yang dihasilkan memenuhi persyaratan dan kinerja, maka kualitas konformasi memenuhi persyaratan dan kinerja, maka kualitas konformasi menjadi tinggi.

(4)

9.2.2 Kontrol Kualitas



Kontrol kualitas merupakan

_{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

_{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)

9.2.3 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 dan konfidensi

bahwa kualitas produk dapat memenuhi

(6)

9.2.4 Biaya Kualitas

 Biaya kualitas menyangkut semua biaya yang diadakan untuk menampilkan Biaya kualitas menyangkut semua biaya yang diadakan untuk menampilkan kualitas yang berhubungan dengan aktivitas.

kualitas yang berhubungan dengan aktivitas.

 Biaya kualitas dapat dibagi ke dalam biaya yang dihubungkan dengan Biaya kualitas dapat dibagi ke dalam biaya yang dihubungkan dengan pencegahan, penilaian, dan kegagalan

pencegahan, penilaian, dan kegagalan..

 Biaya pencegahan_{Biaya pencegahan} meliputi meliputi

 perencanaan kualitasperencanaan kualitas

 kajian teknis formal (FTR)kajian teknis formal (FTR)

 perlengkapan pengujianperlengkapan pengujian

 pelatihanpelatihan

 Biaya penilaianBiaya penilaian meliputi meliputi

 inspeksi dalam suatu proses dan interprosesinspeksi dalam suatu proses dan interproses

 pemeliharaan dan kalibrasi peralatanpemeliharaan dan kalibrasi peralatan

 pengujianpengujian

 Biaya kegagalan _{Biaya kegagalan}meliputi

Internal (sebelum penyerahan produk) Internal (sebelum penyerahan produk)

 pengerjaan kembali_{pengerjaan kembali}

 perbaikanperbaikan

 analisis mode kegagalan_{analisis mode kegagalan}

Eksternal (setelah penyerahan produk) Eksternal (setelah penyerahan produk)

 resolusi keluhanresolusi keluhan

 penggantian dan pengembalian produkpenggantian dan pengembalian produk

 dukungan help linedukungan help line

(7)

9.3 Aktivitas SQA



Jaminan kualitas perangkat lunak

terdiri dari berbagai tugas yang berhubungan dengan dua konstituen yang berbeda:

 perekayasa perangkat lunak_{perekayasa perangkat lunak} yang mengerjakan kerja teknis yang mengerjakan kerja teknis

 kelompok SQAkelompok SQA yang bertanggungjawab terhadap perencanaan yang bertanggungjawab terhadap perencanaan jaminan kualitas, kesalahan, penyimpanan rekaman, analisis, dan jaminan kualitas, kesalahan, penyimpanan rekaman, analisis, dan

pelaporan pelaporan



Aktivitas oleh kelompok SQA:

_{Aktivitas oleh kelompok SQA:}

 menyiapkan menyiapkan rencana SQArencana SQA untuk suatu proyek; untuk suatu proyek;

 berpartisipasi dalam berpartisipasi dalam deskripsi proses pengembangandeskripsi proses pengembangan proyek; proyek;

 mengkaji aktivitas perangkat lunak untuk mengkaji aktivitas perangkat lunak untuk memverifikasi memverifikasi pemenuhan proses

pemenuhan proses perangkat lunak yang sudah ditentukan; perangkat lunak yang sudah ditentukan;

 meng-audit produk kerjameng-audit produk kerja perangkat lunak yang ditentukan untuk perangkat lunak yang ditentukan untuk membuktikan kesesuaian dengan produk kerja yang ditentukan membuktikan kesesuaian dengan produk kerja yang ditentukan

tersebut sebagai bagian dari proses perangkat lunak; tersebut sebagai bagian dari proses perangkat lunak;

 memastikan bahwa deviasi pada kerja dan produk kerja perangkat memastikan bahwa deviasi pada kerja dan produk kerja perangkat lunak

lunak didokumentasi didokumentasi dan ditangani sesuai prosedur dan ditangani sesuai prosedur pendokumentasian;

pendokumentasian;

 mencatat mencatat ketidakssesuaianketidakssesuaian dan melaporkannya kepada dan melaporkannya kepada manajemen senior.

(8)

9.4 Kajian Perangkat Lunak

(Software Review)



Software reviews adalah sebuah

_{Software reviews adalah sebuah}

filter

untuk

proses rekayasa perangkat lunak.



Reviews dilaksanakan di berbagai titik selama

_{Reviews dilaksanakan di berbagai titik selama}

pengembangan perangkat lunak dan

membantu

menemukan error

yang kemudian dapat

dihilangkan.



Software reviews membantu untuk

_{Software reviews membantu untuk}

memurnikan

produk kerja perangkat lunak yang terjadi sebagai

suatu

hasil dari analisis, desain, dan coding

.



FTR (

_{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 _{Dalam kontek proses PL, istilah}defect dan faultdefect dan fault adalah sinonim. adalah sinonim. Keduanya menyatakan secara tidak langsung suatu

Keduanya menyatakan secara tidak langsung suatu problem problem kualitas yang ditemukan setelah PL dirilis kepada end users. kualitas yang ditemukan setelah PL dirilis kepada end users.

 Sasaran utama dari FTR adalah _{Sasaran utama dari FTR adalah}menemukan errorsmenemukan errors selagi proses selagi proses PL berjalan sehingga tidak menjadi defect setelah PL dirilis.

PL berjalan sehingga tidak menjadi defect setelah PL dirilis.

 Keuntungan sesungguhnya dari FTR adalah menemukan error _{Keuntungan sesungguhnya dari FTR adalah menemukan error}

sedini mungkin

sedini mungkin sehingga error tsb tidak menjalar ke langkah sehingga error tsb tidak menjalar ke langkah berikutnya dalam proses PL.

berikutnya dalam proses PL.

 Sejumlah studi menunjukkan bahwa kegiatan _{Sejumlah studi menunjukkan bahwa kegiatan}desaindesain mengintrodusir mengintrodusir error antara

error antara 50% dan 65%50% dan 65% dari seluruh error (dan pada akhirnya, dari seluruh error (dan pada akhirnya, seluruh defect) selama proses PL.

seluruh defect) selama proses PL.

 FTR telah menunjukkan bahwa sampai _{FTR telah menunjukkan bahwa sampai}75% efektif75% efektif dalam dalam menemukan cacat-cacat desain.

menemukan cacat-cacat desain.

 Dengan mendeteksi dan menghapus sejumlah besar persentase _{Dengan mendeteksi dan menghapus sejumlah besar persentase} error, proses review secara subtansial

error, proses review secara subtansial mengurangi biayamengurangi biaya pada pada langkah-langkah selanjutnya dalam phase-phase pengembangan 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

_{menemukan error dalam}

fungsi, logika, atau

implementasinya

dalam berbagai representasi

perangkat lunak;



memverifikasi bahwa perangkat lunak yang direview

_{memverifikasi bahwa perangkat lunak yang direview}

memenuhi syarat

;



memastikan bahwa perangkat lunak tersebut telah

_{memastikan bahwa perangkat lunak tersebut telah}

direpresentasikan

sesuai dengan standard

yang telah

ditentukan sebelumnya;



untuk mencapai perangkat lunak yang dikembangkan

_{untuk mencapai perangkat lunak yang dikembangkan}

dengan

cara yang seragam

;

(11)

9.7 Review

9.7.1 Review Meeting



Review meeting (pertemuan kajian) adalah pertemuan

_{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:

_{Diakhir review, tim harus memutuskan apakah:}



menerima

_menerima

hasil kerja tersebut tanpa modifikasi lebih

lanjut.



menolak

_menolak

hasil kerja tersebut karena adanya kesalahan

yang fatal, atau



menerima hasil kerja tersebut secara sementara

_{menerima hasil kerja tersebut secara sementara}

(error

22

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 Review produkproduk, bukan produser, bukan produser

 MenetapkanMenetapkan agendaagenda dan tetap menjaganya dan tetap menjaganya  Membatasi Membatasi perdebatan dan bantahanperdebatan dan bantahan

 Menetapkan Menetapkan area masalaharea masalah, tetapi tidak mencoba untuk , tetapi tidak mencoba untuk

menyelesaikan setiap masalah yang dicatat menyelesaikan setiap masalah yang dicatat

 Buat Buat catatan tertuliscatatan tertulis

 Membatasi jumlah pesertaMembatasi jumlah peserta dan lakukan persiapan awal dan lakukan persiapan awal

 Buat sebuah Buat sebuah daftar utk setiap work productdaftar utk setiap work product yang direview. yang direview.

 Alokasikan Alokasikan sumber-sumber daya dan jadwal waktusumber-sumber daya dan jadwal waktu untuk FTR. untuk FTR.  Lakukan Lakukan pelatihanpelatihan yang berguna bagi yang berguna bagi semua reviewersemua reviewer..

(14)

9.8 Reliabilitas Perangkat Lunak

9.8.1 Reliabilitas (kehandalan)



Reliabilitas perangkat lunak didefinisikan

_{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

(15)

9.8.2 Pengukuran Reliabilitas & Availabilitas



_{Dalam kenyataannya, semua kegagalan}

perangkat lunak

dapat dilacak dari problem-

dapat dilacak dari

problem-problem desain atau implementasi

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

_{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

_{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).

***