KUALITAS PERANGKAT LUNAK

KUALITAS PERANGKAT LUNAK

1.      KONSEP KUALITAS 

Kontrol variasi merupakan inti dari kontrol kualitas. Pemanufaktur ingin meminimalkan variasi antara produk yang mereka buat, bahwa dalam hal kecil sekalipun, seperti menduplikasi disket. Kita ingin meminimalkan variasi diantara pasangan disket yang identik. Tentu saja ini bukan masalah. Menduplikasi disket merupakan operasi produksi yang sangat mudah, dan  kita dapat menjamin bahwa duplikat perangkat lunak yang tepat selalu dapat dibuat.

Bagaimana organisai pengembangan perangkat lunak melakukan kontrol variasi? Dari satu proyek keproyek lain, kita perlu meminimalkan perbedaan antara sumber-sumber daya yang diharakan menyelesaikan subuah proyek dengan sumberdaya aktual yang digunakan. Termasuk penataan staf, perlengkapan dan waktu kalender. Kita tidak hanya perlu meminimalkan jumlah cacat yang dilepas kemedan, tetapi kita juga harus memastikan bahwa varian dalam jumlah bug juga telah diminimalkan dari satu pelepasan kepelepasan lain. Kita perlu meminimalkan perbedaan dan akurasi hotline pendukung yang merespon masalah pelanggan.

1.1  Kualitas

American Heritage Dictionary mendefinisikan sebagai “sebuah karakteristik atau atribut dari sesuatu”. Kualitas mengacu pada karakteristik yang dapat diukur, sesuatu yang dapat dibandingkan dengan standar yang sudah diketahui, seperti panjang, warna, sifat kelisterikan, kelunakan dan sebagainya.

Bila kita mengamati sebuah item dangan didasarkan pada sifat pengukurannya, ada 2 jenis kualitas yang ada, yaitu:

a.       Kualitas desain

Mengacu pada karakteristis yang ditentukan oleh desainer terhadap suatu item tertentu. Nilai material, toleransi, dan spesifikasi kinerja, semuanya memberikan kontribusi terhadap kualitas desain.

b.      Kualitas konfirmasi

Adalah tingkat dimana spesifikasi desain terus diikuti selama pembuatan

1.2  Kontrol Kualitas

kontrol variasi dapat disamakan dengan kontrol kualitas. Kontrol kualitas merupakan serangkaian pemeriksaan, kajian dan pengujian yang digunakan pada keseluruahn siklus pengembangan untuk memastikan bahwa setiap produk memenuhi persyaratan yang ditetapkan. Kontol kualitas mencangkup loop umpan balik pada proses yang menciptakan produk kerja.

Konsep kunci kualitas kontrol adalah bahwa semua produk kerja memiliki spesifikasi yang telah ditentukan dan dapat diukur dimana kita dapat membandingkan autput dari setiap proses.

1.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 syarat.

1.4  Buaya Kualitas

Buiaya kulitas menyangkut semua biaya yang diadakan untuk mengejar kualitas atau untuk menampilkan kualitas yang berhubungan dengan aktivitas. Biaya kualitas dapat dibagi kedalam biaya – biaya yang dihubungkan dengan pencegahan, penelitian, dan kegagalan.

Biaya pencegahan meliputi:

a.       Perencanaan kualitas

b.      Kajian teknis formal

c.       Perlengkapan pengujian

d.      Pelatihan

Biaya penelitaian meliputi aktivitas untuk memperoleh wawasan mengenai kondisi produk ”pertama kali” pada masing-masing proses. Contoh biaya ini meliputi:

a.       Inspeksi in-proses dan interproses

b.      Pemeliharaan dan kalibrasi peraltan

c.       Pengujian

Biaya kegagaln adalah biaya yang akan hilang biala tidak ada cacat yang muncul sebelum produk disampaikan kepada pelanggan. Biaya kegagalan dapat dibagi menjadi biaya kegagalan internal, yaitu biaya yang diadakan bila kita mendeteksi suatu kesalahan dalam produk sebelum produk dipasarkan. Yang meliputi : pengerjaan kembali, perbaikan, analisis model kegagalan.

Biaya kegagalan eksternal adalah biaya yang berhubungan dengan cacat yang ditemukan setelah produk disampaikan kepada pelanggan. Contoh biaya kegagalan eksternal meliputi: resolusi keluhan, penggantian dan pengembangan produk, dukungan help line, dan kerja jaminan.

2.      PERGERAKAN KUALITAS

Para manajer senior mengetahui bahwa kualitas produk yang tinggi diterjemahkan kedalam penghematan biaya dan peningkatan garis dasar. Meskipun istilah yang digunakan perusahaan berbeda-bada, ada 4 langkah kemajuan dasar yang biasanya ditemui dan menjadi fokus dari banyak program TQM (Total Quality Management) yang baik :

Langkah pertama disebut kaizen, yang mengacu pada sistem peningkatan proses yang kontinu. Tujuannya adalah mengembangkan sebuah proses perangkat lunak yang kelihatan, dapat diulang dan dapat ditukar.

Langkah kedua disebut antarimae hinshitsu, langkah ini mengamati hal yang tidak terlihat yang mempearuhi proses, dan bekerja untuk mengoptimasi pengaruhnnya terhadap proses tersebut.

Langkah pertama dan kedua berfokus pada proses. Pada proses langkah ketiga disebut kansei (“lima indra”), berkonsentrasi pada pemakai produk perangkat lunak.

Langkah terakhir disebut miyokuteki hinshitsu. Langkah ini merupakan langkah yang berorientasi pada bisnis yang mencari peluang dalam area yang berkaitan, yang dapat di identifikasi dengan mengamati penggunaan produk dipasar.

3.      JAMINAN KUALITAS PERANGKAT LUNAK

Kualitas perangkat lunak didefinisikan : sebagai konformasi terhadap kebutuhan fungsional dan kinerja yang dinyatakan secara eksplisit, standar perkembangan yang didokumentasikan secara eksplisit, dan karakteristik implisit yang diharapkan bagi semua perangkat lunak yang dikembangakan.

3.1  Masalah – Masalah Latar Belakang

juminan kualitas merupakan aktifitas mendasar bagi banyak bisnis yang menghasilkan produk yang akan digunakan oleh orang lain. Kelompok SQA berfungsi sebagai perwakilan in-house  pelanggan, yanitu orang yang akan melakukan SQA harus memperhatikan perangkat lunak dari sudut pandang pelanggan.

3.2  Aktivitas SQA

tugas kelompuk SQA adalah membantu tim rekayasa perangkat lunak dalam mencari produk akhir yang berkualitas tinggi. Berikut ini aktivitas SQA:

a.       menyimpan rencana SQA untuk suatu produk

rencana tersebut mengidentifikasi hal-hal ini: evaluasi yang dilakukan, audit dan kajian yang dilakukan, standar yang dapat diaplikasikan pada proyek, prosedur untuk pelaporan dan penelusuran kesalahan, dokumen yang dihasilkan oleh kelompok SQA, dan jumlah umpan baik yang diberikan pada tim proyek perangkat lunak.

b.      Berpartisipasi dalam pengembangan diskripsi proses pengembangan proyek.

c.       Mengkaji aktivitas rekayasa perangkat lunak yang sudah ditentukan.

d.      Mengaudit produk kerja perangkat lunak yang ditentukan untuk membuktikan kesesuaian dengan produk kerja yang ditentukan tersebut sebagai bagian dari proses perangkat lunak.

e.       Memastikan bahwa deviasi pada kerja dan produk kerja perangkat lunak didokumentasi dan ditangani sesuai prosedur pendokumentasi.

f.       Mencatat ketidak kesesuain dan melaporkannya kepada menajemen senior.

4.      KAJIAN PERANGKAT LUNAK

Kajian perangkat lunak adalah suatu “filter” bagi proses rekayasa perangkat lunak, yaitu kajian yang diterapkan pada berbagai titik selama pengembangan perangkat lunak dan berfungsi untuk mencari kesalahan yang kemudian akan dihilangkan.

Kajian teknis diperlukan kerena meskipun menusia sangat jeli dalam melihat kesalahan mereka sendiri, kajian teknis formal adalah filter yang paling efektif dari suatu titik jaminan kualitas.

4.1  Pengaruh Biaya Cacat Terhadap Perangkat Lunak

IEEE Standard Dictionary of Electrical and Electronics Terms (IEEE Standard 100-1992) mendefinisikan cacat sebagai “suatu anomali produk”. Dalam konteks proses perangkat lunak, bentuk “cacat” (defect) dan “kesalahan” (fault) dalam sinoim. Keduanya mengimplementasikan maslah kualitas yang ditemukan setelah perangkat lunak diluncurkan kepada pemakai akhir.

Tujuan utama kajian teknis formal adalah untuk menemukan kesalahan selama proses, sehingga mereka benar-benar sudah cacat setelah dilepas kepada pemakai akhir. Keuntungan utama kajian teknis formal adalah penemuan kesalahan sejak awal sehingga tidak berlanjut kelangkah selanjutnya dalam proses perngkat lunak.

4.2  Penguatan Dan Penghilangan Cacat

model penguatan cacat dapat digunakan untuk menggambarkan pemunculan dan pedeteksian kesalahan semala desain awal, desain detail, dan langakh pengkodean proses rekayasa perangkat lunak.

5.      KAJIAN TEKNIK FORMAL

Kajian teknik formal (FTR) adalah aktivitas jaminan kualitas perangkat lunak dan dilakukan oleh perekayasa perangkat lunak. Tujua FTR adalah:

a.       Menemukan kesalahan dalam fungsi, logika, atau implementasinya dalam berbagai representasi perangkat lunak.

b.      Membuktikan bahwa perangkat lunak disajikan sesuai dengan standar yang sudah ditentukan sebelumnya.

c.       Membuktikan bahwa perangkat lunak dibawah kajian memenuhi syarat.

d.      Mencapai perangkat lunak yang dikembangakn dengan cara yang seragam

e.       Membuat proyek lebih dapat dikelola.

5.1  Pertemuan Kajian

setiap pertemuan kajian harus mematuhi batasan-batasan berikut:

a.       antara 3 dan 5 orang harus dilibatkan dalam kajian.

b.      Persiapan awal harus dilakukan, tetapi eaktu yang dibutuhkan harus tidak lebih dari dua jam dari kerja bagi setiap person.

c.       Durasi pertemuan kajian harus kurang dari 2 jam.

Faktor FTR adalah pada produk kerja, kompunen perangkat lunak, infividu yang telah mengembangkan produk kerja, prosedur, memberitahu pimpinan proyek bahwa produk kerja telah selesai dan membutuhkan kajian.

Pertemuan kajian dihadiri oleh pimpinan kajian, pengkaji, dan prosedur. Salah satunya berperan sebagai pencatat. FTR dimulai dengan pengenalan agenda dan pendahuluan dari produser. Produser kemudian meneruskannya dengan “berjalan melalui” produk kerja tersebut, menjelaskan materi yang ada, sementara para pengkaji menunculkan masalah berdasarkan persiapan awal mereka.

Pada akhirnya semua peserta FTR yang hadir harus memutuskan apakah akan :

a.       Menerima produk kerja tanpa modifikasi lebih lanjut.

b.      Menolak produk kerja sehubungan kesalahan yang ada.

c.       Menerima produk kerja secara sementara.

5.2  Pelaporan Kajian Dan Penyimpanan Rekaman

laporan rangkaian kajian yang telah diselesaikan yang merupakan jawaban dari 3 pertanyaan ini:

a.       apa yang dikaji?

b.      Siapa yang melakukan?

c.       Penemuan apa yang dihasilkan dan apa kesimpulannya?

Daftar masalah kajian mempunya 2 tujuan : (1) mengidentifikasi area masalah pada produk. Dan (2) berfungsi sebagai daftar item kegiatan yang menjadi petunjuk bagi produser saat koreksi dilakukan.

5.3  Pedoman Kajian

a.       Kajian produk, bukan prosedur

Pimpinan kajian harus meminpin pertemuan untuk memastikan bahwa sikap dan nada yang tepat tertap terjaga

b.      Menetapkan agenda dan menjaganya.

c.       Membatasi perdebatan dan bantahan

d.      Menentukan area masalah, tetapi tidak tergoda untuk menyelesaikan setiap masalah yang dicatat.

e.       Mengambil cacatan tertulis

f.       Membatasi jumlah perseta dan mewajibkan persiapan awal.

g.       Mengambakan daftar bagi masing-masing produk kerja yang akan dikaji.

h.      Mengalokasikan sumber-sumber daya dan jadwal waktu untuk FTR.

i.        Melakukan peatihan bagi semua pengkaji

j.        Mengkaji kajian awal.

6.      PENDEKATAN FORMAL TERHADAP SQA

Kualitas dapat ditetapkan dalam bentuk array faktor kualitas yang luas dan diukur dengan menggunakan berbagai indeks dan matrik.

7.      JAMINAN KUALITAS STATISTIK (SQA)

Jaminan kualitas statistik mengimpelikasikan langkah-langkah berikut:

a.       Informasi tentang cacat perangkat lunak dikumpulkan dan dipilih-pilih.

b.      Melakukan suatu usaha untuk menelusuri masing-masing cacat sampai ke penyebab pokoknya.

c.       Dengan menggunakan prinsip pareto.

d.      Sekali penyebab vital few teleh diidentifikasi, beralih untuk membetulkan masalah yang menyebabkan cacat.

Meskipun ratusan kesalahan yang berbeda ditemukan, semuanya dapat ditelusuri dari satu atau lebih penyebab berikut: IES, MCC, IDS, VPS, EDRIMI, EDL, IMI, IED, IID, PLT, HCI, dan MIS. Setelah analisis, desain, penkodean, pengujian, dan peluncuran, dikumpulkan data-data berikut:

Ei = jumlah kesalah total yang ditemukan selama langkah ke i dalam proses rekayasa perangkat lunak.

Si = jumlah kesalahan serius

Mi = jumlahke salahan  moderat

Ti = jumlah kesalahan minor

PS = ukuran produk (LOC, pernyataan desain, halaman dokumentasi) pada langkah ke i.

Ws,Wm,Wt = faktor pembobotan untuk kesalahan kerius, moderat, dan sepele, dimana harga yang disetujui adalah Ws=10, Wm=3, Wt=1. Pada masing-masing proses rekayasa perangkat lunak, indeks fase, Pi, dihitung sebagai:

Pii=Ws(Si/Ei) + Wm(Mi/Ei) + Wt(Ti/Ei)

Indeks kesalahan (EI) dihitung dengan menghitung pengaruh kumulatif atau pengaruh masing-masing PI.

EI=E(ixPIi)/PS

   =(PI1+2PI2+3pI3+iPIi)/ PS

8.      RELIABILITAS PERANGKAT LUNAK

Realibilitas perangkat lunak didefinisikan dalam bentuk statisktik sebagai “kemungkinan operasi program komputer bebas kegagalan dalam suatu lingkungan tertentu dan waktu tertentu”. Kegagalan adalah ketidak sesuaian dengan kebutuha perangkat lunak.

8.1  Pengukuran Relibilitas Dan Availabilitas

semua kegagalan perangkat lunak dapat ditelusuri kedalam desain atau masalah implementasi dan keusangan. Bila kita andaikan suatu sistem yang berbasis komputer, pengukuran reliabilitas secara sederhana adalah berupa mean time berween failure (MTBF), dimana:

MBTF= MTTF + MTTR

(akronim MTTF adalam mean time to failure dan MTR berarti mean time to repair)

Availabilitas perangkat lunak adalah kemungkinan sebuah program beroperasi sesuai dengan kebutuhan pada suatu titik yang diberikan pada suatu waktu dan didentifikadikan sebagai :

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

8.2  Keamanan Perangkat Lunak Dan Analisis Resiko

keamanan perangkat lunak dan analisis resiko adalah aktivitas jaminan kualitas perangkat lunak yang berfokus pada identifikasi dan penilaian resiko potensial yang mungkin berpengaruh negatif terhadap perangkat lunak dan menyebabkan seluruh sistem menjadi gagal.

Setelah resiko tingkat sistem di identifikasi, maka digunakan teknik analisis untuk menandai kehebatan dan probabilitas event. Supaya efektif, perangkat lunak harus dianalisis dalam konteks kesluruhan sistem. Teknik analisis seperti analisis pohon kegagalan, logika real-time, atau model petrinet, dapat digunakan untuk memprediksi rantai event yang dapat mengakibatkan resiko dan kemungkinan dimana 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 perlu resiko. Logika real-time (RTL) membangun sebuah model sistem dengan menentukan event dan aksi yang sesuai. Model event-action dapat dianalisis dengan menggunakan operasi logika untuk menguji tuntutan keamanan sepuer komponen sistem dan timingnya. Model pertinet dapat digunakan untuk menentukan keksalahan yang paling beresiko.

9.      RENCANA SQA

SQA Plan menjadi peta jalan untuk membangun jaminan kualitas perangkat lunak. Dikembangan oleh kelompok SQA dan tim proyek, rncana itu berfungsi sebagai template bagi aktivitas SQA yang dibangun untuk setiap proyek perangkat lunak. Bagian dokumentasi menggambarkan masing-masing produk kerja yang dihasilkan sebagai bagian dari proses perangkat lunak, mencangkup hal-hal berikut:

a.       Dokumen proyek (misalnya : rencana proyek)

b.      Model (misalnya : hirarki kelas ERD)

c.       Dokumen teknis (misalnya : spesifikasi, rencana pengujian)

d.      Dokumen pemakai (misalnya : file-file help)

Bagaimana kajian dan audi dari rencana mengidentifikasi kajian dan audit yang akan dilakukan oleh tim rekayasa perangkat lunak, kelompok SQA, dan pelanggan. Bagian pengujian merupakan rencana dan prosedur pengujian perangkat lunak. Bagian ini juga menentukan kebutuhan penyimpanan rkaman pengujian, pelaoran masalah dan tindakan korektif menemukan prosedur untuk pelaporan, pelacakan, dan pembetulan kesalahan serta cacat. Bagian akhir rencana SQA adalah mengidentifikasi peranti dan model yang mendukung aktivitas dan tugas-tugas SQA.

10.  STANDAR KUALITAS ISO 9000

Sistem jaminan kualitas dapat diidentifikasikan sebagai struktur, tanggung jawab, prosedur, proses, dan sumber- seumber daya organisasi untuk mengimplementasi manajemen kualitas. ISO 9000 menjelaskan elemen jaminan kualitas dalam bentuk umum yang dapat diaplikasikan pada berbagai bisnis tanpa memandang produk jasa yang ditawarkan.

10.1          Pendekatan ISO Terhadap Sistem Jaminan Kualitas

model jaminan kualitas ISO 9000 memperlakukan perusahaan sebagai jaminan proses yang saling terhubung (interkoneksi). Suatu sistem kualitas, supaya sesuai denga ISO, proses-prosesnya harus menekankan pada area yang telah diidentifikasi pada standar ISO. Dan harus didokumentasi dan di praktekkan.

ISO 9000 menggambarkan elemen sebuah sistem jaminan kualista secara umum, elemen-elemen tersebut mencangkup struktur, prosedur, proses, organisasi, dan sumberdaya yang dibutuhakan untuk mengimplementasi rancana kualitas. Kontrol kualitas, jaminan kualitas, dan pengembangan kualitas. Tetapi ISO 9000 tidak menggambarkan bagaimana organisasi seharusnya mengimplementasi elemen-elemen kualitas tersebut. Sebagai konsekuensi, adanya tantangan dalam mendesain dan mengimplementasi suatu sistem jaminan kualitas yang memenuhi standar dan sesuai denga produk layanan dan budaya perusahaan.

10.2          Standar ISO 9001

ISO 9001 adalah standar jaminan kualitas yang berlaku untuk rekayasa perangkat lunak. Standar tersebut berisi 20 syarat yang harus ada untuk mencapai sistem jaminan kualitas yang efektif. 20 syarat yang gigambarkan oleh ISO 9001 menekankan topik-topik berikut:

a.       tanggung jawab manajement

b.      sistem kualitas

c.       kajian kontrol

d.      kontrol desain

e.       kontrol data dan dokument

f.       pemelian

g.       kontrol terhadap produk yang disuplay oleh pelanggan

h.      identifikasi dan kemampuan menelusuri produk

i.        kontrol proses

j.        pemeriksaan dan pengujian

k.      kontrol pemeriksaan, pengukuran, dan pelengkapan pengujian

l.        pemeriksaan dan status pengujian

m.    kontrol ketidak sesuaian produk

n.      tindakan preversif dan korektif

o.      penganganan, penyimpanan, pengepakan, preservasi, dan penyampaian

p.      kontrol terhadap cacatan kualitas

q.      audit kualitas internal

r.        pelatihan

s.       pelayanan

t.        teknik statistik