BAB 8

JAMINAN KUALITAS PERANGKAT LUNAKSoftware Quality Assurance [SQA]

Jaminan kualitas perangkat lunak adalah aktivitaspelindung yang diaplikasikan pada seluruh prosesperangkat lunak.

SQA meliputi :1. pendekatan manajemen kualitas2. teknologi rekayasa perangkat lunak yang efektif

(metode dan peranti)3. kajian teknik formal yang diaplikasikan pada

keseluruhan proses perangkat lunak4. strategi pengujian multitiered (deret bertingkat)5. kontrol dokumentasi perangkat lunak dan

perubahan6. prosedur untuk menjamin kesesuaian dengan

standar pengembangan perangkat lunak7. mekanisme pengukuran dan pelaporan.

Kontrol Kualitas

Kontrol kualitas merupakan serangkaianpemeriksaan, kajian, dan pengujian yang digunakanpada keseluruhan siklus pengembangan untukmemastikan bahwa setiap produk memenuhipersyaratan yang ditetapkan.

Konsep kunci kualitas kontrol adalah bahwa semuaproduk kerja memiliki spesifikasi yang telahditentukan dan dapat diukur dimana kita dapatmembandingkan output dari setiap proses.Kalang (loop) menjadi penting untuk meminimalkancacat yang dihasilkan.

Jaminan Kualitas

Jaminan kualitas terdiri atas fungsi auditing danpelaporan manajemen.

Tujuan jaminan kualitas adalah :untuk memberikan data yang diperlukan olehmanajemen untuk menginformasikan masalahkualitas produk, sehingga dapat memberikankepastian & konfidensi bahwa kulitas produk dapatmemenuhi sasaran.

Biaya Kualitas

Biaya kualitas menyangkut semua biaya yangdiadakan untuk mengejar kualitas atau untukmenampilkan kualitas yang berhubungan denganaktivitas.

Studi tentang biaya kualitas dilakukan untukmemberikan garis dasar bagi biaya kualitas yangsedang digunakan, untuk mengidentifikasikemungkinan pengurangan biaya kualitas sertamemberikan basis perbandingan yang ternormalisasi.

Biaya kualitas dapat dibagi ke dalam biaya-biayayang dihubungkan dengan :

a. pencegahanb. penilaianc. kegagalan.

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 bilatidak ada cacat yang muncul sebelum produkdisampaikan kepada pelanggan.

Biaya kegagalan internal adalahbiaya yang diadakan bila kita mendeteksi suatukesalahan dalam produk sebelum produk dipasarkan.

Biaya kegagalan internal meliputi:• Pengerjaan kembali• Perbaikan• Analisis mode kegagalan

Biaya kegagalan eksternal adalahbiaya yang berhubungan dengan cacat yangditemukan setelah produk disampaikan kepadapelanggan.

Biaya kegagalan eksternal meliputi:• Resolusi keluhan• Penggantian dan pengembalian produk• Dukungan help line• Kerja jaminan

Biaya relatif mendapatkan dan membetulkan cacatbertambah secara dramatis pada saat kita melangkahdari pencegahan ke pendeteksian dan dari kegagalaninternal ke kegagalan eksternal.

P e m b e n tu k a n D e s a in K o d e U jiP e n g e m b a n g a n

U jiS is te m

O p e ra s iL a p a n g a n

1 0 0 0

1 0 0

1 0

1

Bia

yaR

elat

ifP

embe

ntuk

anK

esal

ahan

1w a k tu

3 - 6w a k tu

1 0w a k tu

1 5 - 4 0w a k tu

3 0 - 7 0w a k tu

4 0 - 1 0 0 0w a k tu

Gambar 8.1 Biaya Relatif pembetulan kesalahan

JAMINAN KUALITAS PERANGKAT LUNAK

Kualitas perangkat lunak didefinisikan sebagai:Konformansi terhadap kebutuhan fungsional dankinerja yang dinyatakan secara eksplisit, standarperkembangan yang didokumentasikan secaraeksplisit, dan karakteristik implisit yang diharapkanbagi semua perangkat lunak dikembangkan secaraprofesional.

definisi tersebut berfungsi untuk menekankan tiga halpenting, yaitu:

1. Kebutuhan perangkat lunak merupakan fondasiyang melaluinya kualitas diukur.

2. Standar yang telah ditentukan menetapkanserangkaian kriteria pengembangan yangmenuntun cara perangkat lunak direkayasa.

3. Ada serangkaian kebutuhan implisit yang seringdicantumkan (misalnya kebutuhan akankemampuan pemeliharaan yang baik).

Kelompok SQA berfungsi sebagai perwakilan in-house pelanggan, yaitu orang yang akan melakukanSQA harus memperhatikan perangkat lunak darisudut pandang pelanggan.

Kelompok SQA harus dapat menjawab pertanyaan-pertanyaan dibawah ini untuk memastikan bahwakualitas perangkat lunak benar-benar terjaga.

• Apakah perangkat lunak cukup memenuhifaktor kualitas

• Sudahkah pengembangan perangkat lunakdilakukan sesuai dengan standar yang telahditetapkan sebelumnya?

• Sudahkah disiplin teknik dengan tepatmemainkan perannya sebagi bagian dariaktivitas SQA?

Aktivitas SQA

Jaminan kualitas perangkat lunak terdiri dari berbagaitugas yang berhubungan dengan dua konstituen yangberbeda :

– perekayasa perangkat lunak yangmengerjakan kerja teknis

– kelompok SQA yang bertanggung jawabterhadap perencanaan jaminan kualitas,kesalahan, penyimpanan rekaman, analisis,dan pelaporan.

Tugas kelompok SQA adalahmembantu tim rekayasa perangkat lunak dalampencapaian produk akhir yang berkualitas tinggi.

Aktivitas yang dilakukan (atau difasilitasi) olehkelompok SQA yang independen:

v Menyiapkan rencana SQA untuk suatu proyek.Rencana tersebut mengindentifikasikan hal-halberikut:• 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

v Berpartisipasi dalam pengembangan deskripsiproses pengembangan proyek.

v Mengkaji aktivitas rekayasa perangkat lunakuntuk memverifikasi pemenuhan prosesperangkat lunak yang sudah ditentukan.

v Mengaudit produk kerja perangkat lunak yangditentukan untuk membuktikan kesesuaiandengan produk kerja yang ditentukan tersebutsebagai bagian dari proses perangkat lunak.

vMemastikan bahwa deviasi pada kerja danproduk perangkat lunak didokumentasikan & di-tangani sesuai dgn rosedur pendokuementasian.

v Mencatat ketidak-sesuaian dan melaporkannyakepada manajemen senior.

vMengkoordinasi kontrol dan manajemenperubahan, dan membantu mengumpulkan danmenganalisis metrik perangkat lunak.

KAJIAN PERANGKAT LUNAK

Kajian perangkat lunak merupakan salah satuaktivitas SQA yang terpenting.

Kajian perangkat lunak adalah suatu filter bagi prosesrekayasa perangkat lunak, yaitu kajian yg diterapkanpd berbagai titik selama pengembangan PL &berfungsi untuk mencari kesalahan yg kemudian akandihilangkan.

Kajian perangkat lunak berfungsi untuk “memurnikan”produk kerja perangkat lunak yang terjadi sebagaihasil dari analisis, desain, dan pengkodean.

KAJIAN TEKNIK FORMAL(Formal Technic Review - FTR )

FTR adalah aktivitas jaminan kualitas perangkat lunakyang dilakukan oleh perekayasa perangkat lunak.

Kajian teknik formal atau walktrough adalahpertemuan kajian yang disesuaikan dengankebutuhan yang terbukti sangat efektif untukmenemukan kesalahan.

Keuntungan utama kajian teknis formal adalahpenemuan kesalahan sejak awal sehingga tidakberlanjut ke langkah selanjutnya dalam prosesperangkat lunak.

Tujuan FTR adalah1. Menemukan kesalahan dlm fungsi, logika, /

implementasinya dlm berbagai representasi PL;2. Membuktikan bahwa perangkat lunak di bawah

kajian memenuhi syarat;

3. Memastikan bahwa PL disajikan sesuai dgnstandar yg sudah ditentukan sebelumnya;

4. Mencapai perangkat lunak yg dikembangkandengan cara yang seragam;

5. Membuat proyek lebih dapat dikelola.

FTR berfungsi sebagai dasar pelatihan yangmemungkinkan perekayasa yunior mengamatiberbagai pendekatan yang berbeda terhadap analisisperangkat lunak, desain, dan implementasi.FTR juga berfungsi untuk mengembangkan backupdan kontinuitas karena sejumlah orang mengenal baikbagian-bagian perangkat lunak yang tidak merekaketahui sebelumnya.

Masing-masing FTR dilakukan sebagai suatupertemuan dan akan berhasil hanya biladirencanakan, dikontrol dan dihadirkan dengan tepat.Dalam paragraf berikut, panduan yang mirip denganwalktrough disajikan sebagai kajian teknis formalrepresentatif.

TABEL 8.1 Perbandingan Biaya PengembanganKesalahan yang

ditemukanJumlah Unit Biaya Total

Kajian dilakukanSelama desainSebelum pengujianSelama pengujianSetelah peluncuran

2236153

1.5 6.5

1567

33234315201783

Kajian tidakdilakukan

Sebelum pengujianSelama pengujianSetelah peluncuran

228212

6.51567

1431230

8042177

Pertemuan Kajian

Tanpa memperhatikan format FTR yang dipilih, setiappertemuan kajian harus mematuhi batasan-batasanberikut ini :

• Antara 3 & 5 orang (khususnya) harus dilibatkandalam kajian;

• Persiapan awal harus dilakukan, tetapi waktuyang dibutuhkan harus tidak lebih dari 2 jam darikerja bagi setiap person

• Durasi pertemuan kajian harus kurang dari 2 jam

Pertemuan kajian dihadiri oleh pimpinan kajian,pengkaji, dan prosedur. Salah satu dari pengkajiberperan sebagai pencatat, yaitu seseorang yangmencatat semua masalah penting yang munculselama pengkajian.

FTR dimulai dengan pengenalan agenda danpendahuluan dari prosedur. Bila ada masalahkesalahan ditemukan akan dicatat.

Pada akhir kajian, semua peserta FTR yang hadirharus memutuskan apakah akan

1. menerima produk kerja tanpa modifikasi lebihlanjut,

2. menolak produk kerja sehubungan dengankesalahan yangada (sekali dbetulkan, kajiann lainharus dilakukan), atau

3. menerima produk kerja secara sementara(kesalahan minor telah terjadi & harus dikoreksi,tetapi kajian tambahan akan diperlukan).

Keputusan kemudian dibuat.

Semua peserta FTR melengkapinya dengan tandatangan yang menunjukkan partisipasi mereka dalamkajian serta persetujuan mereka terhadap pertemuantim kajian.

Pelaporan Kajian dan Penyimpanan Rekaman

Selama FTR, seorang pengkaji (pencatat) secara aktifmencatat semua masalah yang sudah dimunculkan,yang kemudian dirangkum pada akhir pertemuansehingga dihasilkan daftar masalah kajian. Sebagaitambahan, laporan rangkuman kajian yang sederhanatelah diselesaikan di mana rangkuman kajianmerupakan jawaban dari tiga pertanyaan berikut:

1. Apa yang dikaji ?2. Siapa yang melakukan?3. penemuan apa yang dihasilkan dan apa

kesimpulannya?

Daftar masalah kajian mempunyai dua tujuan:1. Mengidentifikasi area masalah pada produk,2. Daftar item kegiatan yang menjadi petunjuk bagi

prosedur saat koreksi dilakukan.Daftar masalah biasanya dilampirkan pada laporan.

Pedoman Kajian

Pedoman untuk melakukan kajian teknis formal harusdilakukan sebelumnya, didistribusikan kepada semuapengkaji, disetujui, dan kemudian dilaksanakan.Kajian yang tidak terkontrol sering dapat menjadi lebihburuk daripada bila tidak ada kajian sama sekali.

Berikut ini serangkaian pedoman minimum untukkajian teknis formal:

1. Kajian produk, bukan produser.2. Menetapkan agenda dan menjaganya.3. Membatasi perdebatan dan bantahan.

4. Menetapkan area masalah, tetapi tidak tergodauntuk menyelesaikannya setiap masalah yangdicatat.

5. Mengambil catatan tertulis.6. Membatasi jumlah peserta dan mewajibkan

persiapan awal.7. Mengembangkan daftar bagi masing-

masing produk kerja yang akan dikaji.8. Mengalokasikan sumber-sumber daya dan

jadwal waktu untuk FTR.9. Melakukan pelatihan bagi semua pengkaji.

10. Mengkaji kajian awal Anda.

PENDEKATAN FORMAL TERHADAP SQA

Kualitas perangat lunak merupakan tugas setiaporang & kualitas dapat dicapai melalui analisis,desain, pengkodean, dan pengujian yang baik sertaaplikasi standar pengembangan perangkat lunak yangditerima.

Pada lebuh dari dua dekade, segmen komunitasrekayasa perangkat lunak yang kecil tetapi vokal telahmemperlihatkan bahwa dibutuhkan suatu pendekatanyang lebih formal terhadap jaminan kualitas perangkatlunak.

Pembuktian matematis terhadap kebenarannyadapat diaplikasikan untuk menunjukkan bahwaprogram menyesuaikan diri secara tepat denganspesifikasinya.

JAMINAN KUALITAS STATISTIK (SQA)

Jaminan kualitas statistik mencerminkan trend yangsedang tumbuh di seluruh industri untuk menjadi lebihkuantitatif terhadap kualitas.

Pada perangkat lunak, jaminan kualitas statistikmengimplikasikan langkah-langkah berikut ini:

1. Informasi tentang cacat perangkat lunakdikumpulkan dan dipilah-pilahkan.

2. Melakukan suatu usaha untuk menelusurimasing-masing cacat sampai ke penyebabpokoknya.

3. Dengan menggunakan prinsip Pareto (80 persencacat dapat ditelusuri sampai 20 persen darisemua kemungkinan penyebab), mengisolasiyang 20 persen tersebut (vital few)

4. Sekali penyebab vital few telah diidentifikasi,beralih untuk membetulkan maslah yangmenyebabkan cacat.

Banyak kesalahan ditemukan pada waktuperangkat lunak sedang dalam prosespengembangan. Cacat yang lain ditemukan setelahperangkat lunak diluncurkan kepada pemakai akhir.Meskipun ratusan kesalahan yang berbedadiluncurkan, semuanya dapat ditelusuri dari satu (ataulebih) 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 tidakkonsisten atau mengandung ambiguitas (HCI)

• Dan msih banyak lagi (MIS)

RELIABILITAS PERANGKAT LUNAK

Reliabilitas perangkat lunak, tidak seperti faktorkualitas yang lain, dapat diukur, diarahan, dandiestimasi dengan menggunakan datapengembangan historis. Reliabilitas perangkat lunakdidefinisikan dalam bentuk statistik sebagai“kemungkinan operasi program komputer bebaskegagalan di dalam suatu lingkungan tertentu danwaktu tertentu”.

Kapan saja reliabilitas perangkat lunakdibicarakan, selalu muncul pertanyaan yang sangatpenting : Apa yang dimaksudkan dengan bentuk“kegagalan?” dalam konteks dan banyak diskusimengenai kualitas dan reliabilitas perangkat lunak,kegagalann adalah ketidaksesuaian dengankebutuhan perangkat lunak.

Kegagalan hanya akan mengganggu ataubahkan merupakan bencana. Satu kegagalan dapatdiperbaiki dalam beberapa detik sementara kesalahanyang lain mungkin membutuhkan waktu pembetulanberminggu-minggu atau bahkan berbulan-bulan.

Pembetulan satu kegagalan kenyataannya dapatmenghasilkan kesalahan lain yang baru yangmungkin akan membawa lagi kesalahan yang lainlagi.

Pengukuran Reliabilitas dan Availabilitas

Kerja awal dalam reliabilitas perangkat lunakberusaha mengekstrapolasi matematika teorireliabitas perangkat keras. Sebagian besar modelreliabilitas yang berhubungan dengan perangkat

keras didasarkan pada kegagalan sehubungandengan keusangan (wear), bukan kesalahan karenacacat desain. Dalam perangkat keras, kegagalansehubungan dengan keusangan fisik (misalnyapengaruh suhu, korosi, kejutan) lebih banyak terjadidaripada kegagalan karena isu. Akan tetapi, yangterjadi pada perangkat lunak adalah hal yangsebaliknya. Kenyataannya, semua kegagalanperangkat lunak dapat ditelusuri ke dalam desain ataumasalah implementasi; keusangan tidak tercakup.

Masih ada perdebatan yang terjadi di seputarhubunan antara konsep kunci dalam reliabilitasperangkat keras dan kemampuan aplikasinyaterhadap perangkat lunak.

Meskipun ada hubungan yang tidak dapatdibantah, namun sangat penting untukmemprtimbangkan beberapa konsep sederhana yangberlaku untuk kedua sistem elemen tersebut.

Bila kita andaikan suatu sistem yang berbasiskomputer, pengukuran reliabilitas secara sederhanaadalah berupa mean time between failure (MTBF),dimana :

MTBF = MTTF + MTTR(Akronim MTTF adalah mean time to failure dan MTRberarti mean time to repair.)

Banyak peneliti berpendapat bahwa MTBFmerupakan pengukuran yang jauh lebih bergunadaripada pengukuran cacat/KLOC. Secara sederhanadapat dikatakan bahwa seorang pemakai akhir lebihmemperhatikan kegagalan, bukan jumlah cacat.Karena masing-masing cacat yangada pada sebuahprogram tidak memiliki tingkat kegagalan yang sama,maka penghitungan cacat total hanya memberikansedikit indikasi tentang reliabilitas sistem.

Contohnya adalah sebuah program yang telahberoperasi selama 14 bulan. Banyak cacat mungkintidak terdeteksi dalam jumlah waktu yang lamasampai pada akhirnya cacat itu ditemukan. MTBF daricacat yang tidak jelas seperti itu dapat berlangsungsampai 50, bahkan 100 tahun. Cacat yang lain, yangjuga belum ditemukan, dapat memiliki tingkatkegagalan 18 atau 24 bulan. Meskipun setiap kategoripertama cacat (yang memiliki MTBF panjang)dihilangkan, pengaruhnya pada reliabilitas perangkatlunak tidak dapat diabaikan.

Availabilitas perangkat lunak adalahkemungkinan sebuah program beroperasi sesuaidengan kebutuhan pada suatu titik yang diberikanpada suatu waktu dan didefinisikan sebagai :

Availabilitas = MTTF / (MTTF + MTTR) x 100 %

Pengukuran reliabilitas MTBF sama sensitifnyadengan MTTF dan MTTR. Pengukuran availabilitasjauh lebih sensitif daripada MTTR, yang merupakanpengukuran tidak langsung terhadap kemampuanpemeliharaan perangkat lunak.

Keamanan Perangkat Lunak dan Analisis Risiko

Leveson membicarakan pengaruh perangkat lunakdalam sistem kritis keamanan ketika menulis :

Sebelum perangkat lunak digunakan di dalamsistem kritis keamanan, perangkat lunak itusering dikontrol oleh alat mekanik konvensional(tidak dapat diprogram) dan elektronik. Teknikkeamanan sistem didesain untuk mengatasikegagalan acak dalam sistem-sistem tersebut.Kesalahan perancangan oleh manusia dapatsepenuhnya dihindari atau dihilangkan sebelum

perangkat lunak tersebut diluncurkan dandioperasikan.

Ketika perangkat lunak diguanakn sebagaibagian dari sistem kontrol, kompleksitasnya dapatbertambah dengan satu urutan besaran atau lebih.Kesalahan desain yang tidak kentara yangdisebabknan oleh kesalahan manusia – sesuatu yangdapat diunkapkan dan dikurangi dalam kontrolkonvensional berbasis perangkat keras – menjadilebih sulit ditemukan pada waktu perangkat lunakdigunakan.

Keamanan perangkat lunak dan analisis risikoadalah aktivitas jaminan kualitas perangkat lunakyang berfokus pada identifikasi dan penilaian risikopotensial yang mungkin berpengaruh negatif terhadapperangkat lunak dan menyebabkan seluruh sistemmenjadi gagal. Jika risiko dapat diidentifikasi padaawal proses rekayasa perangkat lunak, maka ciri-ciridesain perangkat lunak dapat ditetapkan sehinggaakan mengeliminasi atau mengontrol risiko potensial.

Proses analisis dan modeling dilakukan sebagaibagian dari keamanan perangkat lunak. Awalnya,risiko diidentifikasi dan dipilah-pilahkan berdasarkankekritisan dan risiko. Sebagai contoh, beberapa risikoyang berkaitan dengan kontrol peluncuran berbasiskomputer untuk automobil mungkin:

• Menyebabkan percepatan yang tidak terkontroltidak dapat dihentikan

• Tidak lepas ketika pedal rem ditekan• Tidak nyambung ketika skalar diaktifkan• Perlahan-lahan kehilangan atau menambah

kecepatan

Setelah risiko tingkat sistem diidentifikasi, makadigunakan teknik analisis untuk menandai kehebatandan probabilitas event. Supaya efektif, perangkatlunak harus dianalisis dalam konteks keseluruhansistem. Sebagai contoh, kesalahan input pemakaiyang tidak kentara (manusia sebagai komponensistem) dapat diperbesar oleh kesalahan perangkatlunak, sehingga menghasilkan data kontrol yangmemposisikan sebuah perangkat lunak, sehinggamenghasilkan data kontrol yang memposisikansebuah perangkat mekanik secara tidak tepat. Jikaada serangkaian kondisi lingkungan eksternal (danhanya jika mereka ditemui), maka posisi perangkatmekanik yang tidak tepat dapat menyebabkankegagalan fatal. Teknik analisis seperti analisis pohonkegagalan, logika real-time , atau model Petrinet ,dapat digunakan untuk memprediksi rantai event yangdapat mengakibatkan risiko dan kemungkinan dimana setiap event akan terjadi untuk menciptakanrantai.

Analisis pohon kesalahan membangun modelgrafis dan kombinasi event yang konkuren danberurutan yang dapat menyebabkan suatu event atausistem yang penuh risiko. Dengan menggunakanpohon kesalahan yang dikembangkan dengan baik,maka dimungkinkan untuk meneliti kosekuensi urutankegagalan yang terinterelasi yang terjadi padakomponen sistem yang berbeda. Logika real-time(RTL) membangun sebuah model sistem denganmenentukan event dan aksi yang sesuai. Modelevent-action dapat dianalisis dengan menggunakanoperasi logika untuk menguji tuntutan keamananseputar komponen sistem dan timing-nya. ModelPetrinet dapat digunakan untuk menentukankesalahan yang paling berisiko.

Sekali risiko diidentifikasi dan dianalisis, makakeamanan yang berhubungan dengan kebutuhanuntuk perangkat lunak dapat ditetapkan. Spesifikasidapat berupa sederetan event yang tidak diinginkandan sistem yang diinginkan merespon event tersebut.Peran perangkat lunak dalam mengatur event yangtidak diinginkan kemudian diindikasi.

Meskipun reliabilitas perangkat lunakberhubungan erat satu sama lain dengan lainnya,namun sangat penting untuk memahami perbedaantipis yang ada di antara mereka. Reliabilitasperangkat lunak menggunakan analisis statistik untukmenentukan kemungkinan terjadinya kegagalanperangkat lunak. Tetapi kegagalan tidak perlumenghasilkan risiko atau kecelakaan. Kemananperangkat lunak mengamati bagaimana kegagalanmenimbulkan keadaan yang dapat menyebabkankecelakaan. Kegagalan tidak perlu dipertimbangkan didalam ruang hampa, tetapi dievaluasi dalam kontekskeseluruhan sistem berbasis komputer.

Diskusi komprehensif tentang analisis risiko dankeamanan perangkat lunak tidak masuk dalam ruanglingkup buku ini. Pembaca yang tertarik untukmengetahui lebih jauh tentang hal tersebut sebaiknyamembaca buku yang ditulis oleh Leveson .

RENCANA SQA

SQA plan menjadi peta jalan untuk membangunjaminan kualitas perangkat lunak. Dikembangkan olehkelompok SQA dan tim proyek, rencana itu berfungsisebagai template bagi aktifitas SQA yang dibangununtuk setiap proyek perangkat lunak.

Gambar 8.5 memperlihatkan sebuah outlineuntuk rencana SQA yang disetujui oleh IEEE . Bagian

awal menggambarkan tujuan dan ruang lingkupdokumen dan menunjukkan aktivitas prosesperangkat lunak yang diungkap oleh jaminan kualitas.Semua dokumen yang dicatat oleh rencana SQAdidaftar dan semua standar yang dapat diapliksikandicatat. Bagian Manajemen dari rencana tersebutmenggambarkan tempat SQA pada strukturorganisasi; tugas-tugas dan aktivitas SQA danpenempatannya di seluruh proses perangkat lunak;dan peran organisasional serta tanggung jawab relatifterhadap kualitas produk.

Bagian Dokumentasi menggambarkan (denganrefernsi) masing-masing produk kerja yang dihasilkansebagai 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 file0file help)

Sebagai tambahan, bagian ini menentukanserangkaian produk kerja minmum yang dapatditerima untuk mencapai kualitas yang tinggi.

Standar, Praktik dan Konversi mencatat semuastandar/praktik yang diterapkan selama prosesperangkat lunak (misalnya, standar dokumen, stadarpengkodean, dan pedoman kajian). Semua proyek,proses, dan metrik produk yang dikumpulkan sebagaibagian dari usaha rekayasa perangkat lunak jugaharus dicatat.

Bagian Kajian dan Audit dari rencanamengidentifiaksi kajian dan audit yang akan dilakukanoleh tim rekayasa perangkat lunak, kelompok SQA,

dan pelanggan. Bagian ini memberikan gambaranyang luas terhadap pendekatan bagi masing-masigkajian dan audit.

I. Tujuan RencanaII. ReferensiIII. Manajemen

1. Organisasi2. Tugas3. Tanggung jawab

IV. Dokumentasi1. Tujuan2. Dokuen rekayasa perangkat lunak yang diperlukan3. Dokumen-dokumen lain

V. Standar, Praktis dan Konversi1. Tujuan2. Konvensi

VI. Tinjauan dan Audit1. Tujuan2. Tinjauan

a. Kebutuhan perangkat lunakb. Desainc. Verifikasi dan validasi perangkat lunakd. Audit fungsionale. Audit fisikf. Audit in-processg. Manajemen

VII. PengujianVIII. Pelaporan Masalah dan Tindakan KoreksiIX. Peranti, Teknik, dan MetodologiX. Kontrol KodeXI. Kontrol MediaXII. Kontrol PemasokXIII. Pengumpulan, Pemeliharaan, dan Penyimpanan CatatanXIV. PelatihanXV. Manajemen Risiko

Gambar 8.5 Rencana kualitas jaminan perangkatlunak standar ANSI/IEEE 730 – 1984 dan 983-1986

Bagian pengujian merujuk rencana dan prosedurpengujian perangkat lunak (Bab17). Bagian ini jugamenentukkan kebutuhan penyimpanan rekamanpengujian. Pelaporan Masalah dan Tindakan Korektifmenentukan prosedur untuk pelaporan, pelacakan,

dan pembetulan kesalahan serta cacat, jugamengidentifikasi tanggung jawab organisaional untukakyivitas-aktivitas tersebut.

Bagian akhir rencana SQA adalah mengidentifikasiperanti dan metode yang mengandung aktifitas dantugas-tugas SQA; merujuk manajemen konfigurasiperangkat lunak untuk mengontrol perubahan;menetapkan pendekatan manajemen kontrak;membangun metode perakitan, perlindungan danpemeliharaan semua catatan; mengidentifikasipelatihan yang dibutuhkan untuk memenuhikebutuhan rencana, serta menetapkan metode-metode untuk mengidentifikasi, menilai, memonitor,dan mengontrol risiko.

STANDAR KUALITAS ISO 9000

Sistem jaminan kualitas dapat didefinisikan sebagaistrukutr, tanggung jawab, prosedur, proses dansumber-sumber daya organisasi untukmengimplementasi manajemen kualitas. ISO 9000menjelaskan elemen jaminan kualitas dalam bentukyang umum yang dapat diaplikasikan pada berbagaibisnis tanpa memandang produk dan jasa yangditawarkan.

Agar terdaftar dalam satu model sistem jaminankualitas yang ada pada ISO 9000, sistem kualitas danoperasi perusahaan diperiksa oleh auditor bagianketiga untuk memeriksa kesesuaiannya denganstandar dan operasi efektif. Bila registrasi itu berhasil,perusahaan diberi sertifikat dari badan registrasi yangdiwakili oleh auditor. Audit pengawasan tegah tahuanterus dilakukan untuk memastikan kesesuaiannyadengan standar yang sudah ditetapkan.

Pendekatan ISO terhadap Sistem JaminanKualitas

Model jaminan kualitas ISO 9000 memperlakukanperusahaan sebagai jaringan proses yang salingterhubung (interkoneksi). Suatu sistem kualitas,supaya sesuai dengan ISO, proses-prosesnya harusmenekankan pada area yang telah diidentifikasi padastandar ISO, dan harus didokumentasi dandipraktikan sebagimana dikelaskan.Pendokuemnatsian proses membantu organisasiuntuk memahami, mengontrol, dan mengembangkanjaringan proses yang mungkin dapat mendatangkankeuntunagn terbesar bagi organisasi yang merancangdan mengimplementasikan kualitas yang sesuaidengan ISO.

ISO 9000 menggambarkan elemen sebuahsistem jaminan kualitas secara umum. Elemen-elemen tersebut mencakup struktur, prosedur, proses,organisasi, dan sumber day ayang dibutuhkan untukmehimplementasi rencana kualitas, kontrol kualitas,jaminan, kualitas, dan pengembangan kualiats. TetapiISO 9000 tidak menggambarkan bagaimananorganisasi seharusnya mengimpelemnatsi elemen-elemen kualitas tersebut. Sebagai konsekuensi, adatantangan dalam mendesain dan mengimplementasisuatu sistem jaminan kualitas yang memenuhistandar dengan produk, layanan dan budayaperusahaan.

Standar ISO 9001

ISO 9001 adalah standar kualitas yang berkalu untukrekayasa perangkat lunak. Standar tersebut berisi 20syarat yang harus ada untuk mencapai sistemjaminan kualitas yangefektif. Karena standar ISO9001 dapat diaplikasikan pada semua disiplin

rekayasa / engineering, maka dikembangkansekumpulan khusus pedoman ISO untuk membantumenginterpretsi standar untuk digunakan pada prosesperangkat lunak.

Dua puluh syarat yang digambarkan oleh ISO9001 menekankan topik-topik berikut :

1. Tanggung jawab manajemen2. Sistem kualitas3. Kajian kontrak4. Kontrol desain5. Kontrol data dan dokumen6. Pembelian7. Kontrol terhadap produk yang disuplai oleh

pelanggan8. Identifikasi dan kemampuan penelusuran

produk9. Kontrol proses10. Pemeriksaan dan pengujian11. Kontrol pemeriksaan, pengukuran, dan

perlengkapan pengujian12. Pemeriksaan dan status pengujian13. Kontrol ketudaksesuaian produk14. Tindakan preventif dan korektif15. Penanganan, penyimpanan, pengepakan,

preservasi, dan penyampaian16. Kontrol terhadap catatan kualitas17. Audit kualitas internal18. Pelatihan19. Pelayanan20. Teknik statistik

Untuk dapat didaftar dalam ISO 9001, organisasiperangkat lunak harus membuat kebijakan danprosedur yang memberi tekanan pada masing-masingsyarat tersebut dan kemudian dapat menunjukkanbahwa prosedur dan fungsi itu telah diikuti. Untukpenjelsan leih lanjt, pembaca yang tertarik denganinformasi mengnenai ISO 9001.