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.
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.
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.
Kualitas dapat ditetapkan
dalam bentuk array faktor kualitas yang luas dan diukur dengan menggunakan
berbagai indeks dan matrik.
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
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.
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
Post a Comment