BAB elemen dari. . Rencana .434. . . . . . . .

0,445

16
statistik. . . . .439 tugas. . . . . . . 0,436

JAMINAN KUALITAS PERANGKAT LUNAK

KMATA

T
Pendekatan rekayasa perangkat lunak yang diuraikan dalam buku ini bekerja untuk satu
CONCEPTS tujuan: menghasilkan perangkat lunak yang tepat waktu dan berkualitas tinggi. Namun
pendekatan banyak pembaca akan ditantang oleh pertanyaan: "Apa kualitas perangkat lunak?"
formal. . . . .438
Philip Crosby [Cro79], dalam buku utamanya tentang kualitas, memberikan jawaban masam
gol. . . . . . . . 0,436
untuk pertanyaan ini:
ISO 9001: 2000
standar. . . . . 0,445 Masalah manajemen kualitas bukanlah apa yang orang tidak tahu tentang itu. Masalahnya adalah apa yang
Six Sigma. . . . . mereka pikir tahu. . . .
0,441
perangkat lunak Dalam hal ini, kualitas memiliki banyak kesamaan dengan seks. Semua orang untuk itu. (Dalam
keandalan. . . . . . kondisi tertentu, tentu saja.) Semua orang merasa mereka memahaminya. (Meskipun mereka tidak mau
442 perangkat menjelaskannya.) Semua orang berpikir eksekusi hanya masalah mengikuti kecenderungan alami.
lunak (Bagaimanapun juga, kita memang rukun.) Dan, tentu saja, kebanyakan orang merasa bahwa masalah
keamanan . . . . . . .
di bidang ini disebabkan oleh orang lain. (Kalau saja mereka akan meluangkan waktu untuk melakukan
0,443
hal yang benar.)
SQA

CEPAT Apa itu? Itu tidak cukup untuk berbicara
LIHATberbicara dengan mengatakan bahwa
kualitas perangkat lunak itu penting.
Anda harus (1) secara eksplisit
mendefinisikan apa yang dimaksud
ketika Anda mengatakan
"Kualitas perangkat lunak," (2) membuat
serangkaian kegiatan yang akan membantu
memastikan bahwa setiap produk pekerjaan
rekayasa perangkat lunak menunjukkan kualitas
tinggi, (3) melakukan kontrol kualitas dan kegiatan
penjaminan pada setiap proyek perangkat lunak,
(4) menggunakan metrik untuk mengembangkan
strategi untuk meningkatkan proses perangkat
lunak Anda dan, sebagai konsekuensinya, kualitas
produk akhir.
Siapa yang melakukannya Setiap orang yang terlibat
dalam proses rekayasa perangkat lunak
bertanggung jawab atas kualitas.
Mengapa ini penting? Anda bisa melakukannya dengan
benar, atau Anda bisa melakukannya lagi. Jika tim
perangkat lunak menekankan kualitas dalam
semua kegiatan rekayasa perangkat lunak, ini
mengurangi jumlah pengerjaan ulang yang
harus dilakukan. Hasilnya adalah biaya yang
lebih rendah, dan yang lebih penting,
peningkatan waktu ke pasar.
Apa langkah-langkahnya? Sebelum kegiatan jaminan
kualitas perangkat lunak (SQA) dapat dimulai,
itu
432
penting untuk menentukan kualitas perangkat
lunak pada sejumlah tingkat abstraksi yang
berbeda. Setelah Anda memahami apa
kualitasnya, tim perangkat lunak harus
mengidentifikasi serangkaian kegiatan SQA yang
akan menyaring kesalahan dari produk kerja
sebelum diteruskan.
Apa produk pekerjaan? Rencana Jaminan Kualitas
Perangkat Lunak dibuat untuk menentukan
strategi SQA tim perangkat lunak. Selama
pemodelan dan pengkodean, produk kerja SQA
 2 BAGIAN KETIGA MANAJEMEN MUTU

utama adalah output dari tinjauan teknis (Bab 15).

Selama pengujian (Bab 17 hingga 20), rencana dan
prosedur pengujian diproduksi. Produk kerja lain yang
terkait dengan peningkatan proses mungkin juga
dihasilkan.
Bagaimana saya memastikan bahwa saya telah melakukannya
dengan benar? Temukan kesalahan sebelum cacat!
Yaitu, bekerja untuk meningkatkan efisiensi
penghilangan cacat Anda (Bab 23), sehingga
mengurangi jumlah pengerjaan ulang yang harus
dilakukan oleh tim perangkat lunak Anda.
Memang, kualitas adalah konsep yang menantang — konsep yang saya bahas secara rinci dalam Bab 14. 1
Beberapa pengembang perangkat lunak terus percaya bahwa kualitas perangkat lunak adalah sesuatu yang
Anda mulai khawatirkan setelah kode dihasilkan. Tidak ada yang bisa lebih jauh dari kebenaran! Jaminan
kualitas perangkat lunak (sering disebut manajemen kualitas) adalah kegiatan payung (Bab 2) yang diterapkan
selama proses perangkat lunak.
Jaminan kualitas perangkat lunak (SQA) meliputi (1) proses SQA, (2) tugas jaminan kualitas dan kontrol
kualitas tertentu (termasuk tinjauan teknis dan strategi pengujian multitier), (3) praktik rekayasa perangkat lunak
yang efektif (metode dan alat), (4 ) mengendalikan semua produk kerja perangkat lunak dan perubahan yang
dilakukan padanya (Bab 22), (5) prosedur untuk memastikan kepatuhan dengan standar pengembangan
perangkat lunak (bila berlaku), dan (6) mekanisme pengukuran dan pelaporan.
Dalam bab ini, saya fokus pada masalah manajemen dan aktivitas spesifik proses yang memungkinkan
organisasi perangkat lunak untuk memastikan bahwa hal itu "melakukan hal yang benar pada waktu yang tepat
dengan cara yang benar."

16.1 BACKGROUND sayaSSUES

Kontrol kualitas dan jaminan adalah kegiatan penting untuk setiap bisnis yang menghasilkan produk untuk
digunakan oleh orang lain. Sebelum abad kedua puluh, kontrol kualitas adalah tanggung jawab pengrajin yang
membangun sebuah produk. Seiring berjalannya waktu dan teknik produksi massal menjadi hal yang biasa,
kontrol kualitas menjadi kegiatan yang dilakukan oleh orang-orang selain orang yang membangun produk.
Fungsi jaminan kualitas dan kontrol formal pertama kali diperkenalkan di Bell Labs pada tahun 1916 dan
uote: menyebar dengan cepat ke seluruh dunia manufaktur. Selama 1940-an, pendekatan yang lebih formal untuk
"Kamu juga pengendalian kualitas disarankan. Ini bergantung pada pengukuran dan peningkatan proses yang berkelanjutan
banyak yang
membuatnya [Dem86] sebagai elemen kunci dari manajemen kualitas.
kesalahan
salah Saat ini, setiap perusahaan memiliki mekanisme untuk memastikan kualitas dalam produknya. Faktanya,
." pernyataan eksplisit tentang kepedulian perusahaan terhadap kualitas telah menjadi taktik pemasaran selama
Yogi Berra
beberapa dekade terakhir.
Sejarah jaminan kualitas dalam pengembangan perangkat lunak paralel dengan sejarah kualitas dalam
pembuatan perangkat keras. Selama masa-masa awal komputasi (1950-an dan 1960-an), kualitas adalah
tanggung jawab programmer. Standar untuk jaminan kualitas untuk perangkat lunak diperkenalkan dalam

1Jika Anda belum membaca Bab 14, Anda harus melakukannya sekarang.
 BAB 16 JAMINAN KUALITAS PERANGKAT LUNAK 3

pengembangan perangkat lunak kontrak militer selama tahun 1970-an dan telah menyebar dengan cepat ke dalam
pengembangan perangkat lunak di dunia komersial [IEE93]. Memperluas definisi yang disajikan sebelumnya,
jaminan kualitas perangkat lunak adalah "pola tindakan yang terencana dan sistematis" [Sch98c] yang diperlukan
untuk memastikan kualitas tinggi dalam perangkat lunak. Ruang lingkup tanggung jawab jaminan kualitas
mungkin paling baik ditandai dengan parafrase iklan mobil yang pernah populer: "Kualitas Adalah Pekerjaan # 1.
Grup SQA berfungsi sebagai perwakilan pelanggan. Artinya, orang yang melakukan SQA harus melihat
perangkat lunak dari sudut pandang pelanggan. Apakah perangkat lunak memenuhi faktor kualitas yang
tercantum pada Bab 14 secara memadai? Apakah pengembangan perangkat lunak telah dilakukan sesuai dengan
standar yang ditetapkan sebelumnya? Sudahkah disiplin ilmu menjalankan peran mereka dengan baik sebagai
bagian dari kegiatan SQA? Grup SQA berupaya menjawab pertanyaan ini dan lainnya untuk memastikan kualitas
perangkat lunak terjaga.

16.2 ELINGS OF SPERANGKAT LUNAK QUALITY SEBUAHKEAMANAN

WebRef kus pada pengelolaan kualitas perangkat lunak. Ini dapat diringkas dengan cara berikut
Diskusi [Hor03]:
mendalam
tentang SQA, Standar. IEEE, ISO, dan organisasi standar lainnya telah menghasilkan beragam
termasuk
standar rekayasa perangkat lunak dan dokumen terkait. Standar dapat diadopsi secara
beragam
definisi, dapat sukarela oleh organisasi rekayasa perangkat lunak atau dipaksakan oleh pelanggan
diperoleh di atau pemangku kepentingan lainnya. Tugas SQA adalah untuk memastikan bahwa
www.swqual
standar yang telah diadopsi diikuti dan bahwa semua produk kerja sesuai dengan
.com / buletin /
vol2 / no1 / mereka.
vol2no1.html.
Ulasan dan audit. Tinjauan teknis adalah kegiatan kontrol kualitas yang dilakukan
Jami
oleh insinyur perangkat lunak untuk insinyur perangkat lunak (Bab 15). Tujuan
nan
mereka adalah untuk mengungkap kesalahan. Audit adalah jenis tinjauan yang
kuali
dilakukan oleh personel SQA dengan maksud untuk memastikan bahwa pedoman
tas
peran kualitas diikuti untuk pekerjaan rekayasa perangkat lunak. Misalnya, audit proses
gkat peninjauan dapat dilakukan untuk memastikan bahwa peninjauan dilakukan dengan
lunak cara yang akan mengarah pada kemungkinan tertinggi untuk mengungkap kesalahan.
menc Pengujian. Pengujian perangkat lunak (Bab 17 hingga 20) adalah fungsi kontrol
akup kualitas yang memiliki satu tujuan utama — untuk menemukan kesalahan. Tugas
berba SQA adalah memastikan bahwa pengujian direncanakan dengan baik dan dilakukan
gai secara efisien sehingga memiliki kemungkinan tertinggi untuk mencapai tujuan
masa utamanya.
lah
Pengumpulan dan analisis kesalahan / cacat. Satu-satunya cara untuk
dan
meningkatkan adalah dengan mengukur kinerja Anda. SQA mengumpulkan dan
aktiv
menganalisis data kesalahan dan cacat untuk lebih memahami bagaimana kesalahan
itas
diperkenalkan dan kegiatan rekayasa perangkat lunak apa yang paling cocok untuk
yang
menghilangkannya.
berfo
4 BAGIAN KETIGA MANAJEMEN MUTU

U satu aspek yang paling mengganggu dari setiap proyek perangkat lunak. Jika tidak
b dikelola dengan baik, perubahan dapat menyebabkan kebingungan, dan kebingungan
a hampir selalu mengarah pada kualitas yang buruk. SQA memastikan bahwa praktik
h manajemen perubahan yang memadai (Bab 22) telah dilembagakan.

uote:
m
“Keunggulan adalah kemampuan tanpa batas untuk meningkatkan kualitas
a
dari apa yang Anda tawarkan. "
n
a Rick Petin
Pendidikan. Setiap organisasi perangkat lunak ingin meningkatkan praktik rekayasa perangkat
j
lunaknya. Kontributor utama untuk peningkatan adalah pendidikan insinyur perangkat lunak,
e
manajer mereka, dan pemangku kepentingan lainnya. Organisasi SQA memimpin dalam
m
peningkatan proses perangkat lunak (Bab 30) dan merupakan pendukung utama dan sponsor
e
program pendidikan.
n
. Manajemen vendor. Tiga kategori perangkat lunak diperoleh dari vendor perangkat lunak
eksternal — paket yang dibungkus menyusut (mis., Microsoft Office), cangkang khusus
P [Hor03] yang menyediakan struktur kerangka dasar yang disesuaikan dengan kebutuhan
e pembeli, dan peranti lunak yang dikontrak dirancang khusus dan dibangun dari spesifikasi yang
r disediakan oleh organisasi pelanggan. Tugas organisasi SQA adalah untuk memastikan bahwa
u hasil perangkat lunak berkualitas tinggi dengan menyarankan praktik kualitas khusus yang
b harus diikuti oleh vendor (bila mungkin), dan memasukkan mandat kualitas sebagai bagian dari
a kontrak apa pun dengan vendor eksternal.
h Manajemen keamanan. Dengan meningkatnya kejahatan dunia maya dan peraturan
a pemerintah baru tentang privasi, setiap organisasi perangkat lunak harus melembagakan
n kebijakan yang melindungi data di semua tingkatan, membangun perlindungan firewall untuk
WebApps, dan memastikan bahwa perangkat lunak belum dirusak secara internal. SQA
a memastikan bahwa proses dan teknologi yang tepat digunakan untuk mencapai keamanan
d perangkat lunak.
a
Keamanan. Karena perangkat lunak hampir selalu merupakan komponen penting dari sistem
l
yang dimanusiakan (misalnya, aplikasi otomotif atau pesawat terbang), dampak cacat
a
tersembunyi dapat menjadi bencana besar. SQA mungkin bertanggung jawab untuk menilai
h
dampak kegagalan perangkat lunak dan untuk memulai langkah-langkah yang diperlukan untuk
mengurangi risiko.
s
Manajemen risiko. Meskipun analisis dan mitigasi risiko (Bab 28) menjadi perhatian para
a
insinyur perangkat lunak, organisasi SQA memastikan bahwa kegiatan manajemen risiko
l
dilakukan dengan benar dan bahwa rencana kontinjensi terkait risiko telah ditetapkan.
a
h
 BAB 16 JAMINAN KUALITAS PERANGKAT LUNAK 5

Selain masing- memastikan bahwa kegiatan dukungan perangkat lunak (misalnya, pemeliharaan, saluran bantuan,
masing dokumentasi, dan manual) dilakukan atau diproduksi dengan kualitas sebagai masalah dominan.
masalah dan
kegiatan ini,
SQA bekerja INFO
untuk
Sumber Daya Manajemen Mutu
Ada puluhan manajemen kualitas Asosiasi untuk Mesin Komputer www.acm.org sumber daya
yang tersedia di Web, termasuk Pusat profesional Data dan Analisis untuk Perangkat Lunak (DACS), organisasi
standarons, dan www.dacs.dtic.mil/
sumber informasi umum. Situs yang mengikuti menyediakan Organisasi Internasional untuk Standardisasi (ISO)
titik awal yang baik: www.iso.ch
ISO SPICE
Divisi Perangkat Lunak Masyarakat Amerika untuk Kualitas (ASQ)
www.asq.org/software www.isospice.com
Penghargaan Kualitas Nasional Malcolm Baldridge TickIT International: Topik sertifikasi kualitas www.quality.nist.gov
www.tickit.org/international.htm
Institut Rekayasa Perangkat Lunak Total Quality Management (TQM) www.sei.cmu.edu/ Informasi Umum:
Pengujian Perangkat Lunak dan Rekayasa Kualitas www.gslis.utexas.edu/~rpollock/tqm.htmlwww.stickyminds.com Artikel:
www.work911.com/tqmarticles.htm
Sumberdaya Six Sigma Glosarium:
www.isixsigma.com/ www.quality.org/TQM-MSI/TQM-glossary www.asq.org/sixsigma/ .html

16.3 SQA TMEMINTA, GOAL, DAN M.ETRICS

Jaminan kualitas perangkat lunak terdiri dari beragam tugas yang terkait dengan dua daerah
pemilihan — insinyur perangkat lunak yang melakukan pekerjaan teknis dan kelompok SQA
yang memiliki tanggung jawab untuk perencanaan, pengawasan, penyimpanan catatan, analisis,
dan pelaporan penjaminan mutu.
Insinyur perangkat lunak menangani kualitas (dan melakukan kegiatan kontrol kualitas)
dengan menerapkan metode dan tindakan teknis yang solid, melakukan tinjauan teknis, dan
melakukan pengujian perangkat lunak yang terencana dengan baik.

16.3.1 Tugas SQA

Piagam kelompok SQA adalah untuk membantu tim perangkat lunak dalam mencapai produk
akhir berkualitas tinggi. Institut Rekayasa Perangkat Lunak merekomendasikan serangkaian
tindakan SQA yang membahas perencanaan penjaminan kualitas, pengawasan, penyimpanan
catatan, analisis, dan pelaporan. Tindakan-tindakan ini dilakukan (atau difasilitasi) oleh
kelompok SQA independen yang:
6 BAGIAN KETIGA MANAJEMEN MUTU

Mempersiapkan rencana SQA untuk suatu proyek. Rencana tersebut dikembangkan

sebagai bagian dari Apakah yang perencanaan proyek dan ditinjau oleh semua pemangku kepentingan. Kualitas
? asuransi
peran seorang tindakan yang dilakukan oleh tim rekayasa perangkat lunak dan kelompok SQA
Kelompok SQA? diatur oleh rencana tersebut. Rencana tersebut mengidentifikasi evaluasi yang akan dilakukan,
audit dan tinjauan yang akan dilakukan, standar yang berlaku untuk proyek, prosedur
pelaporan kesalahan dan pelacakan, produk kerja yang dihasilkan oleh kelompok
SQA, dan umpan balik yang akan diberikan kepada tim perangkat lunak .
Berpartisipasi dalam pengembangan deskripsi proses perangkat lunak proyek.
Tim perangkat lunak memilih proses untuk pekerjaan yang akan dilakukan. Grup SQA
meninjau deskripsi proses untuk kepatuhan dengan kebijakan organisasi, standar
perangkat lunak internal, standar yang diberlakukan eksternal (misalnya, ISO-9001),
dan bagian lain dari rencana proyek perangkat lunak.
uote: kat lunak untuk memverifikasi kepatuhan dengan proses perangkat lunak yang
ditentukan. Grup SQA mengidentifikasi, mendokumentasikan, dan melacak penyimpangan
“Kualitas tidak
pernah dari proses dan memverifikasi bahwa koreksi telah dilakukan.
merupakan Mengaudit produk kerja perangkat lunak yang ditunjuk untuk memverifikasi kepatuhan
kecelakaan; dengan yang ditetapkan sebagai bagian dari proses perangkat lunak.Grup SQA meninjau
selalu
produk kerja yang dipilih; mengidentifikasi, mendokumentasikan, dan melacak penyimpangan;
merupakan
hasil dari niat memverifikasi bahwa koreksi telah dilakukan; dan secara berkala melaporkan hasil
tinggi, upaya pekerjaannya kepada manajer proyek.
tulus, arahan Memastikan bahwa penyimpangan dalam pekerjaan perangkat lunak dan produk kerja
cerdas dan
didokumentasikan dan ditangani sesuai dengan prosedur yang didokumentasikan.
eksekusi yang
terampil; itu Penyimpangan dapat ditemui dalam rencana proyek, deskripsi proses, standar yang berlaku,
melambangka atau produk kerja rekayasa perangkat lunak.
n pilihan bijak Rekam semua ketidakpatuhan dan laporan kepada manajemen senior.
dari banyak
alternatif. ” Item ketidakpatuhan dilacak sampai diselesaikan.

William A. Selain tindakan-tindakan ini, grup SQA mengoordinasikan kontrol dan manajemen perubahan (Bab
Membantu 22) dan membantu mengumpulkan dan menganalisis metrik perangkat lunak.
perkembanga
n 16.3.2 Sasaran, Atribut, dan Metrik
Meninj
Tindakan SQA yang dijelaskan di bagian sebelumnya dilakukan untuk mencapai serangkaian tujuan
au
pragmatis:
aktivita
s Persyaratan kualitas. Ketepatan, kelengkapan, dan konsistensi model persyaratan akan
rekayas memiliki pengaruh kuat pada kualitas semua produk kerja yang mengikuti. SQA harus
a memastikan bahwa tim perangkat lunak telah meninjau model persyaratan dengan benar untuk
perang
 BAB 16 JAMINAN KUALITAS PERANGKAT LUNAK 7

menca dinilai oleh tim perangkat lunak untuk memastikan bahwa itu menunjukkan kualitas tinggi dan
pai bahwa desain itu sendiri sesuai dengan persyaratan. SQA mencari atribut desain yang
tingkat merupakan indikator kualitas.
kualita Kualitas kode. Kode sumber dan produk kerja terkait (misalnya, informasi deskriptif lainnya)
s yang harus sesuai dengan standar pengkodean lokal dan menunjukkan karakteristik yang akan
tinggi. memudahkan pemeliharaan. SQA harus mengisolasi atribut-atribut yang memungkinkan
Kualitas analisis yang wajar dari kualitas kode.
desain. Efektivitas kontrol kualitas. Tim perangkat lunak harus menerapkan sumber daya yang
Setiap terbatas dengan cara yang memiliki kemungkinan tertinggi untuk mencapai hasil berkualitas
elemen tinggi. SQA menganalisis alokasi sumber daya untuk ulasan dan pengujian untuk menilai
dari apakah mereka dialokasikan dengan cara yang paling efektif.
model
desain Gambar 16.1 (diadaptasi dari [Hya96]) mengidentifikasi atribut yang merupakan indikator untuk
keberadaan kualitas untuk setiap tujuan yang dibahas. Metrik yang dapat digunakan untuk
harus
menunjukkan kekuatan relatif suatu atribut juga ditampilkan.

FIGURE 16.1 Sasaran, atribut, dan metrik kualitas perangkat lunak

SumbeDiadaptasi dari
r: [Hya96].

Tujuan Atribut Metrik

Kualitas persyaratan Kemenduaan Jumlah pengubah ambigu (mis., Banyak, besar, ramah
manusia)
Kelengkapan Jumlah TBA, TBD

Dapat dimengerti Jumlah bagian / subbagian

Keriangan Jumlah perubahan per persyaratan

Ketertelusuran
Kejelasan model
Kualitas desain Integritas arsitektur
Kelengkapan komponen
Kompleksitas antarmuka
Pola
Waktu (berdasarkan aktivitas) saat perubahan diminta
Jumlah persyaratan yang tidak dapat dilacak ke desain /
kode
Jumlah model UML
Jumlah halaman deskriptif per model
Jumlah kesalahan UML
Keberadaan model arsitektur
Jumlah komponen yang ditelusuri ke model arsitektur
Kompleksitas desain prosedural
Jumlah rata-rata pilihan untuk mendapatkan fungsi atau
konten yang khas
Kesesuaian tata letak
Jumlah pola yang digunakan
 8 BAGIAN KETIGA MANAJEMEN MUTU

Kualitas kode Kompleksitas Kompleksitas siklus

Maintabilitas Faktor desain (Bab 8)

Dapat dimengerti Persen komentar internal

Konvensi penamaan variabel
Dapat digunakan kembali Persen komponen yang digunakan kembali

Dokumentasi Indeks keterbacaan

Efektivitas qc Alokasi sumber daya Persentase jam staf per aktivitas

Tingkat penyelesaian Waktu penyelesaian aktual vs. dianggarkan

Tinjau efektivitas Lihat metrik ulasan (Bab 14)

Efektivitas pengujian Jumlah kesalahan yang ditemukan dan kekritisan

Diperlukan upaya untuk memperbaiki kesalahan

Asal kesalahan

SEBUAHPENDEKATA
16.4 FORMAL N UNTUK SQA
Pada bagian sebelumnya, saya berpendapat bahwa kualitas perangkat lunak adalah pekerjaan semua orang dan
dapat dicapai melalui praktik rekayasa perangkat lunak yang kompeten serta melalui penerapan tinjauan teknis,
strategi pengujian multi-tier, kontrol yang lebih baik terhadap produk kerja perangkat lunak dan perubahan
yang dibuat untuk mereka, dan penerapan standar rekayasa perangkat lunak yang diterima. Selain itu, kualitas
dapat didefinisikan
Web yang berguna tentang SQA dan metode kualitas formal dapat ditemukan di www.gslis
Ref .utexas.edu /
Infor ~ rpollock / tqm .html.
masi dalam hal berbagai atribut kualitas dan diukur (secara tidak langsung) menggunakan berbagai indeks
dan metrik.
Selama tiga dekade terakhir, segmen kecil, tetapi vokal, komunitas rekayasa perangkat lunak
berpendapat bahwa pendekatan yang lebih formal untuk jaminan kualitas perangkat lunak diperlukan.
Dapat dikatakan bahwa program komputer adalah objek matematika. Sintaks dan semantik yang ketat
dapat didefinisikan untuk setiap bahasa pemrograman, dan pendekatan yang ketat untuk spesifikasi
persyaratan perangkat lunak (Bab 21) tersedia. Jika model persyaratan (spesifikasi) dan bahasa
pemrograman dapat direpresentasikan secara ketat, harus dimungkinkan untuk menerapkan bukti
kebenaran matematika untuk menunjukkan bahwa suatu program sesuai persis dengan spesifikasinya.
BAB 16 JAMINAN KUALITAS PERANGKAT LUNAK 9
10 BAGIAN KETIGA MANAJEMEN MUTU
 BAB 16 JAMINAN KUALITAS PERANGKAT LUNAK 11

Upaya dengan benar bukanlah hal baru. Dijkstra [Dij76a] dan Linger, Mills, dan Witt [Lin79], antara lain,
untuk menganjurkan bukti kebenaran program dan mengaitkannya dengan penggunaan konsep

melakukan (misalnya, ketidaksesuaian dengan spesifikasi, kesalahan desain, pelanggaran standar,

SQA statistik? komunikasi yang buruk dengan pelanggan).
3. Menggunakan prinsip Pareto (80 persen dari cacat dapat ditelusuri ke 20 persen dari semua
kemungkinan penyebab), mengisolasi 20 persen (beberapa yang vital).
16.5 STATISTIK SPERANGKAT LUNAK QUALITY SEBUAHKEAMANAN
4. Setelah beberapa penyebab vital telah diidentifikasi, bergerak untuk memperbaiki masalah
Jaminan kualitas statistik mencerminkan tren yang berkembang di seluruh industri untuk menjadi
yang menyebabkan kesalahan dan cacat.
lebih kuantitatif tentang kualitas. Untuk perangkat lunak, jaminan kualitas statistik menyiratkan
langkah-langkah berikut:
Konsep yang relatif sederhana ini merupakan langkah penting menuju penciptaan proses perangkat
lunak adaptif di mana perubahan dilakukan untuk meningkatkan elemen-elemen proses yang
1. Informasi tentang
menyebabkan kesalahan dan kerusakan perangkat lunak dikumpulkan dan
kesalahan.
dikategorikan.
? Langkah apa
2. Upaya dilakukan untuk melacak setiap kesalahan dan cacat ke penyebab mendasarinya
diperlukan

16.5.1 Contoh Umum

uote: Untuk mengilustrasikan penggunaan metode statistik untuk pekerjaan rekayasa perangkat lunak, asumsikan
“Statistik bahwa organisasi rekayasa perangkat lunak mengumpulkan informasi tentang kesalahan dan analisis cacat,
dengan benar untuk periode satu tahun. Beberapa kesalahan ditemukan karena perangkat lunak sedang didekondisi,
adalah a
veloped. Lainnya (cacat) ditemukan setelah perangkat lunak dirilis ke diseksi yang rumit
ketidakpastian, pengguna akhir. Meskipun ratusan masalah yang berbeda terungkap, semua bisa menjadi
operasi dilacak ke satu (atau lebih) dari penyebab berikut: dugaan. "
• Spesifikasi tidak lengkap atau salah (IES)
MJ Moroney
• Misinterpretasi komunikasi pelanggan (MCC)
membuktikan pemrograman terstruktur (Bab 10).
program
12 BAGIAN KETIGA MANAJEMEN MUTU

uote: • Pengujian tidak lengkap atau salah (IET)

“20 persen • Dokumentasi yang tidak akurat atau tidak lengkap (IID)
kode memiliki
80 persen • Kesalahan dalam terjemahan bahasa desain desain (PLT)
kesalahan.
Temukan
• Antarmuka manusia / komputer yang ambigu atau tidak konsisten (HCI)
mereka, • Lain-lain (MIS)
perbaiki! ”
Untuk menerapkan SQA statistik, tabel pada Gambar 16.2 dibuat. Tabel menunjukkan
Lowell Arthur
bahwa IES, MCC, dan EDR adalah beberapa penyebab penting yang menyebabkan 53
• Penyim
persen dari semua kesalahan. Namun perlu dicatat bahwa IES, EDR, PLT, dan EDL akan
pangan
yang dipilih sebagai beberapa penyebab vital jika hanya kesalahan serius yang dipertimbangkan.
disenga Setelah beberapa penyebab vital ditentukan, organisasi rekayasa perangkat lunak dapat
ja dari memulai tindakan korektif. Misalnya, untuk memperbaiki MCC, Anda dapat menerapkan
spesifik teknik pengumpulan persyaratan (Bab 5) untuk meningkatkan kualitas komunikasi dan
asi
spesifikasi pelanggan. Untuk meningkatkan EDR, Anda dapat memperoleh alat untuk
(IDS)
pemodelan data dan melakukan tinjauan desain data yang lebih ketat.
• Pelangg Penting untuk dicatat bahwa tindakan korektif terutama berfokus pada beberapa vital. Saat
aran
beberapa penyebab vital diperbaiki, kandidat baru muncul ke puncak tumpukan.
standar
pemrog Teknik jaminan kualitas statistik untuk perangkat lunak telah terbukti memberikan peningkatan
raman kualitas yang substansial [Art97]. Dalam beberapa kasus, organisasi perangkat lunak
(VPS)

• Kesalah
an
dalam
represe
ntasi
data
(EDR)

• Antarm
uka
kompon
en tidak
konsiste
n (ICI)

• Kesalah
an
dalam
logika
desain
(EDL)
 BAB 16 JAMINAN KUALITAS PERANGKAT LUNAK 13

Tota Serius Moderat Minor

l
Kesalahan Tida % Tidak. % Tidak. % Tidak. %
k.
IES 205 22% 34 27% 68 18% 103 24
%
MCC 156 17% 12 9% 68 18% 76 17
%
IDS 48 5% 1 1% 24 6% 23 5
%
VPS 25 3% 0 0% 15 4% 10 2
%
EDR 130 14% 26 20% 68 18% 36 8
%
AKU CI 58 6% 9 7% 18 5% 31 7
%
EDL 45 5% 14 11% 12 3% 19 4
%
IET 95 10% 12 9% 35 9% 48 11
%
IID 36 4% 2 2% 20 5% 14 3
%
PLT 60 6% 15 12% 19 5% 26 6
%
HCI 28 3% 3 2% 17 4% 8 2
%
SALAH 56 6% 0 0% 15 4% 41 9
%
14 BAGIAN KETIGA MANAJEMEN MUTU

Total 942 100% 128 100% 379 100% 435 100

%

FIGURE 16.2
Pengumpulan data untuk statistik
SQA
telah mencapai pengurangan 50 persen per tahun dalam cacat setelah menerapkan teknik
ini.
Penerapan SQA statistik dan prinsip Pareto dapat diringkas dalam satu kalimat:
Luangkan waktu Anda berfokus pada hal-hal yang benar-benar penting, tetapi pertama-tama
pastikan Anda memahami apa yang sebenarnya penting!

16.5.2Six Sigma untuk Rekayasa Perangkat Lunakcincin

Six Sigma adalah strategi yang paling banyak digunakan untuk jaminan kualitas statistik di
industri saat ini. Awalnya dipopulerkan oleh Motorola pada 1980-an, strategi Six Sigma
"adalah metodologi yang ketat dan disiplin yang menggunakan data dan analisis statistik
untuk mengukur dan meningkatkan kinerja operasional perusahaan dengan
mengidentifikasi dan menghilangkan cacat dalam proses manufaktur dan yang berhubungan
dengan layanan" [ISI08] . Istilah Six Sigma berasal dari enam standar deviasi — 3,4
kejadian (cacat) per juta kejadian — menyiratkan standar kualitas yang sangat tinggi.
Metodologi Six Sigma mendefinisikan tiga langkah inti:

Apa itu • Menetapkan persyaratan dan hasil pelanggan dan sasaran proyek melalui
? sumurlangkah inti dari metode komunikasi pelanggan yang didefinisikan.
metodologi Six
Sigma? • Mengukur proses yang ada dan outputnya untuk menentukan kinerja kualitas saat ini
(kumpulkan metrik cacat).
• Menganalisa metrik cacat dan menentukan beberapa penyebab vital.

Jika proses perangkat lunak yang ada sudah ada, tetapi diperlukan perbaikan, Six Sigma
menyarankan dua langkah tambahan:

• Memperbaiki proses dengan menghilangkan akar penyebab cacat.

• Kontrol proses untuk memastikan bahwa pekerjaan di masa depan tidak
memperkenalkan kembali penyebab cacat.

Langkah-langkah inti dan tambahan ini kadang-kadang disebut sebagai metode DMAIC
(define, ukur, analysis, improve, and control).
Jika organisasi mengembangkan proses perangkat lunak (daripada meningkatkan proses
yang ada), langkah-langkah inti ditambah sebagai berikut:
 BAB 16 JAMINAN KUALITAS PERANGKAT LUNAK 15

• Rancangan proses untuk (1) menghindari akar penyebab cacat dan (2) untuk
memenuhi persyaratan pelanggan.

• Memeriksa bahwa model proses akan, pada kenyataannya, menghindari cacat dan
memenuhi persyaratan pelanggan.

Variasi ini kadang-kadang disebut metode DMADV (define, ukur, analisis, desain, dan
verifikasi).
Diskusi komprehensif Six Sigma sebaiknya diserahkan kepada sumber daya yang
didedikasikan untuk subjek ini. Jika Anda memiliki minat lebih lanjut, lihat [ISI08],
[Pyz03], dan [Sne03].
uote: Masalah keandalan perangkat lunak hampir selalu dapat ditelusuri dari cacat dalam desain
atau
"Harga
keandalan
yang tidak
dapat
dihindari penerapan.
adalah
kesederhanaa
n."

CAR Hoare

Penting untuk dicatat bahwa MTBF dan tindakan terkait didasarkan pada waktu CPU, bukan
waktu jam dinding.

SPERANGKA
16.6 T LUNAK RELIABILITAS

Tidak ada keraguan bahwa keandalan program komputer adalah elemen penting dari
kualitas keseluruhannya. Jika suatu program berulang kali dan sering gagal melakukan, itu
penting sedikit apakah faktor kualitas perangkat lunak lain dapat diterima.
Keandalan perangkat lunak, tidak seperti banyak faktor kualitas lainnya, dapat diukur
secara langsung dan diperkirakan menggunakan data historis dan perkembangan. Keandalan
perangkat lunak didefinisikan dalam istilah statistik sebagai "probabilitas operasi bebas
kegagalan dari program komputer dalam lingkungan yang ditentukan untuk waktu yang
ditentukan" [Mus87]. Sebagai gambaran, program X diperkirakan memiliki keandalan
16 BAGIAN KETIGA MANAJEMEN MUTU

0,999 berlalu (waktu eksekusi), kemungkinan akan beroperasi dengan benar (tanpa kegagalan)
selama 999 kali.
delapa Kapan pun keandalan perangkat lunak dibahas, muncul pertanyaan penting: Apa yang
n jam dimaksud dengan istilah gagal? Dalam konteks diskusi tentang kualitas dan keandalan
pemros perangkat lunak, kegagalan adalah ketidaksesuaian dengan persyaratan perangkat lunak.
esan Namun, bahkan dalam definisi ini, ada gradasi. Kegagalan bisa hanya mengganggu atau
yang bencana. Satu kegagalan dapat diperbaiki dalam hitungan detik, sementara yang lain
telah membutuhkan minggu atau bahkan bulan untuk memperbaikinya. Lebih rumit lagi masalah
berlalu. ini, koreksi satu kegagalan sebenarnya bisa mengakibatkan pengenalan kesalahan lain yang
Denga akhirnya menghasilkan kegagalan lainnya.
n kata
lain, 16.6.1 Ukuran Keandalan dan Ketersediaan
jika Pekerjaan awal dalam keandalan perangkat lunak berusaha untuk mengekstrapolasi
progra matematika dari teori keandalan perangkat keras dengan prediksi keandalan perangkat
m X lunak. Sebagian besar model keandalan yang terkait dengan perangkat keras didasarkan
akan pada kegagalan karena keausan daripada kegagalan karena cacat desain. Dalam perangkat
diekse keras, kegagalan karena keausan fisik (misalnya, efek suhu, korosi, guncangan) lebih
kusi mungkin terjadi daripada kegagalan terkait desain. Sayangnya, yang terjadi justru
1000 sebaliknya untuk perangkat lunak. Faktanya, semua kegagalan perangkat lunak dapat
kali ditelusuri ke masalah desain atau implementasi; memakai (lihat Bab 1) tidak masuk ke
dan dalam gambar.
membu Ada perdebatan yang sedang berlangsung tentang hubungan antara konsep-konsep kunci
tuhkan dalam keandalan perangkat keras dan penerapannya pada perangkat lunak. Meskipun tautan
total yang tak terbantahkan masih harus dibangun, ada baiknya mempertimbangkan beberapa
delapa konsep sederhana yang berlaku untuk kedua elemen sistem.
n jam Jika kita mempertimbangkan sistem berbasis komputer, ukuran sederhana reliabilitas adalah
waktu sementara-di antara kegagalan (MTBF):
pemros
esan MTBF MTTF MTTR
yang di mana akronim MTTF dan MTTR adalah mean-time-to-failure dan mean-time-torepair, 2 masing-
telah masing.

Beberapa aspek ketersediaan (tidak dibahas di sini) tidak ada hubungannya dengan
kegagalan. Misalnya, penjadwalan waktu henti (untuk fungsi dukungan)
menyebabkan perangkat lunak tidak tersedia.

2 Meskipun debugging (dan koreksi terkait) mungkin diperlukan sebagai konsekuensi dari kegagalan, dalam
banyak kasus perangkat lunak akan bekerja dengan baik setelah restart tanpa perubahan lainnya.
 BAB 16 JAMINAN KUALITAS PERANGKAT LUNAK 17

u terdapat dalam suatu program tidak memiliki tingkat kegagalan yang sama, jumlah cacat total hanya
o memberikan sedikit indikasi keandalan suatu sistem. Sebagai contoh, pertimbangkan sebuah program
t yang telah beroperasi selama 3000 jam prosesor tanpa kegagalan. Banyak cacat dalam program ini
e mungkin tetap tidak terdeteksi selama puluhan ribu jam sebelum ditemukan. MTBF dari kesalahan
: yang tidak jelas tersebut mungkin 30.000 atau bahkan 60.000 jam prosesor. Cacat lain, yang belum
ditemukan, mungkin memiliki tingkat kegagalan 4000 atau 5000 jam. Bahkan jika setiap salah satu
"Kese
kategori kesalahan (yang memiliki MTBF panjang) dihapus,
lamat
an Namun, MTBF dapat menjadi masalah karena dua alasan: (1) ia memproyeksikan rentang waktu
rakya antara kegagalan, tetapi tidak memberikan kami dengan tingkat kegagalan yang diproyeksikan, dan
t (2) MTBF dapat disalahartikan sebagai rata-rata rentang hidup meskipun ini bukan apa implikasinya.
akan Ukuran alternatif keandalan adalah kegagalan-dalam-waktu (FIT) - ukuran statistik tentang berapa
menj
banyak kegagalan suatu komponen akan memiliki lebih dari satu miliar jam operasi.
adi
huku Karenanya, 1 FIT setara dengan satu kegagalan dalam setiap miliar jam operasi.
m Selain ukuran keandalan, Anda juga harus mengembangkan ukuran ketersediaan. Ketersediaan
tertin perangkat lunak adalah probabilitas bahwa suatu program beroperasi sesuai dengan persyaratan pada
ggi." titik waktu tertentu dan didefinisikan sebagai
Cicer
MTTF
o
Ketersediaan 100% MTTF
Banyak MTTR
peneliti Ukuran keandalan MTBF sama sensitifnya dengan MTTF dan MTTR. Ukuran ketersediaan agak
berpendapat lebih sensitif terhadap MTTR, ukuran tidak langsung dari pemeliharaan perangkat lunak.
bahwa MTBF
adalah ukuran 16.6.2Keamanan Perangkat Lunak
yang jauh lebih
Keamanan perangkat lunak adalah kegiatan jaminan kualitas perangkat lunak yang berfokus pada
berguna
identifikasi dan penilaian potensi bahaya yang dapat memengaruhi perangkat lunak secara negatif
daripada metrik
dan menyebabkan keseluruhan sistem gagal. Jika bahaya dapat diidentifikasi pada awal proses
perangkat lunak
perangkat lunak, fitur desain perangkat lunak dapat ditentukan yang akan menghilangkan atau
terkait kualitas
mengendalikan potensi bahaya.
lainnya yang
Proses pemodelan dan analisis dilakukan sebagai bagian dari keamanan perangkat lunak.
dibahas dalam
Awalnya, bahaya diidentifikasi dan dikategorikan berdasarkan kekritisan dan risiko. Sebagai contoh,
Bab 23. Secara
beberapa bahaya yang terkait dengan cruise control berbasis komputer untuk mobil mungkin: (1)
sederhana,
menyebabkan percepatan yang tidak terkendali yang tidak dapat dihentikan, (2) tidak menanggapi
pengguna akhir
depresi pedal rem (dengan mematikan), ( 3) tidak terlibat ketika sakelar diaktifkan, dan (4) perlahan-
khawatir dengan
lahan kehilangan atau menambah kecepatan. Setelah bahaya tingkat sistem ini diidentifikasi, teknik
kegagalan,
analisis digunakan untuk menentukan tingkat keparahan dan probabilitas terjadinya. 3 Agar efektif,
bukan dengan
perangkat lunak harus dianalisis dalam konteks keseluruhan
jumlah total
uote:
cacat. Karena
setiap cacat yang 3 Pendekatan ini mirip dengan metode analisis risiko yang dijelaskan dalam Bab 28. Perbedaan utama adalah penekanan
pada masalah teknologi daripada topik yang berkaitan dengan proyek.
18 BAGIAN KETIGA MANAJEMEN MUTU

“Aku tidak bisa i contoh, kesalahan input pengguna yang halus (orang adalah komponen sistem) dapat
membayangkan diperbesar oleh kesalahan perangkat lunak untuk menghasilkan data kontrol yang secara
kondisi apa pun tidak tepat menempatkan perangkat mekanis. Jika dan hanya jika satu set kondisi
yang akan
lingkungan eksternal terpenuhi, posisi yang tidak tepat dari perangkat mekanik akan
menyebabkan
kapal ini menyebabkan kegagalan bencana. Teknik analisis [Eri05] seperti analisis pohon kesalahan,
menjadi logika waktu-nyata, dan model Petri net dapat digunakan untuk memprediksi rantai
pendiri. peristiwa yang dapat menyebabkan bahaya dan probabilitas bahwa setiap peristiwa akan
Pembuatan terjadi untuk membuat rantai.
kapal modern Setelah bahaya diidentifikasi dan dianalisis, persyaratan terkait keselamatan dapat
telah
ditentukan untuk perangkat lunak. Artinya, spesifikasi dapat berisi daftar peristiwa yang
melampaui itu.
” tidak diinginkan dan respons sistem yang diinginkan untuk peristiwa ini. Peran perangkat
lunak dalam mengelola acara yang tidak diinginkan kemudian ditunjukkan.
EI Smith,
Meskipun perangkat lunak dapat diandalkan dan aman sepenuhnya terkait dengan orang
kapten Titanic
lain, penting untuk memahami perbedaan halus di antara mereka. Keandalan perangkat
lunak menggunakan analisis statistik untuk menentukan kemungkinan terjadinya kegagalan
perangkat lunak. Namun, kejadian yang tidak terjamin tidak perlu muncul kembali sebagai
WebRef
bencana. Keamanan perangkat lunak memeriksa cara-cara kegagalan menghasilkan kondisi
Kumpulan kertas
yang dapat menyebabkan kecelakaan. Artinya, kegagalan tidak dianggap dalam ruang
berharga tentang
keamanan hampa, tetapi dievaluasi dalam konteks seluruh sistem berbasis komputer dan
perangkat lunak lingkungannya.
dapat ditemukan
Diskusi komprehensif tentang keamanan perangkat lunak berada di luar cakupan buku
di
www.safewaree ini. Jika Anda memiliki minat lebih lanjut dalam keamanan perangkat lunak dan masalah
ng.com /. sistem terkait, lihat [Smi05], [Dun02], dan [Lev95].
sistem. WebRef
Sebaga Tautan ekstensif ke sumber daya ISO 9000/9001 dapat ditemukan di

16.7 TDIA ISO 9000 QUALITY STANDARD

Sistem jaminan kualitas dapat didefinisikan sebagai struktur organisasi, tanggung jawab, prosedur,
proses, dan sumber daya untuk menerapkan manajemen mutu [ANS87]. Sistem jaminan kualitas
dibuat untuk membantu organisasi memastikan produk dan layanan mereka memenuhi harapan
pelanggan dengan memenuhi spesifikasi mereka. Sistem ini mencakup berbagai kegiatan yang
mencakup seluruh siklus hidup produk termasuk perencanaan, pengendalian, pengukuran, pengujian
dan pelaporan, dan peningkatan tingkat kualitas di seluruh proses pengembangan dan pembuatan.
ISO 9000 menjelaskan elemen-elemen jaminan kualitas dalam istilah umum yang dapat diterapkan
pada bisnis apa pun terlepas dari produk atau layanan yang ditawarkan.
Untukdistribusidaripada sistem sistem jaminan kualitas yang terkandung dalam ISO 9000,
sistem mutu perusahaan dan operasinya diperiksa oleh auditor partiteruntukmemenuhi persyaratan
dan operasi yang efektif.Kebijakan pendaftaran yang sukses, sebuah perusahaan mengeluarkan
sertifikat dari badan registrasi yang diwakili oleh auditor.
Audit pengawasan setengah tahunan memastikan kepatuhan berkelanjutan terhadap standar.
 BAB 16 JAMINAN KUALITAS PERANGKAT LUNAK 19

www.t oleh ISO 9001: 2000 membahas topik-topik seperti tanggung jawab manajemen, sistem mutu,
antara tinjauan kontrak, kontrol desain, kontrol dokumen dan data, identifikasi dan penelusuran produk,
.ab .ca
/ kontrol proses, inspeksi dan pengujian, tindakan korektif dan preventif, kontrol catatan kualitas ,
info.ht audit kualitas internal, pelatihan, servis, dan teknik statistik. Agar organisasi perangkat lunak
m. didaftarkan ke ISO 9001: 2000, ia harus menetapkan kebijakan dan prosedur untuk memenuhi setiap
Persyaratan
persyaratan yang baru saja dicatat (dan lainnya) dan kemudian dapat menunjukkan bahwa kebijakan
yang
dan prosedur ini diikuti. Jika Anda menginginkan informasi lebih lanjut tentang ISO 9001: 2000,
digambarkan
lihat [Ant06], [Mut03], atau [Dob04].
Standar ISO 9001: 2000 Untuk kegiatan teknis (misalnya, analisis, desain, pengujian)
Garis besar berikut mendefinisikan elemen dasar Untuk pemantauan dan manajemen proyek
dari standar ISO 9001: 2000. Informasi lengkap tentang Tentukan metode untuk remediasi.
standar dapat diperoleh dari Organisasi Internasional untuk Nilai data dan metrik kualitas.
Standardisasi (www.iso.ch) dan sumber-sumber Internet Tetapkan pendekatan untuk proses berkelanjutan dan
lainnya (misalnya, www.praxiom.com). peningkatan kualitas.

Menetapkan unsur-unsur sistem manajemen mutu.

Mengembangkan, mengimplementasikan, dan
meningkatkan sistem.
Tetapkan kebijakan yang menekankan pentingnya sistem.
Dokumentasikan sistem kualitas.
Jelaskan prosesnya.
Menghasilkan manual operasional.
Kembangkan metode untuk mengendalikan (memperbarui)
dokumen.
Menetapkan metode untuk pencatatan.
Mendukung kontrol kualitas dan jaminan.
Promosikan pentingnya kualitas di antara semua pemangku
kepentingan.
Fokus pada kepuasan pelanggan.
INFO

Tetapkan rencana kualitas yang membahas tujuan,

tanggung jawab, dan wewenang.
Tetapkan mekanisme komunikasi di antara para pemangku
kepentingan.
Menetapkan mekanisme peninjauan untuk sistem
manajemen mutu.
Identifikasi metode ulasan dan mekanisme umpan balik.
Tetapkan prosedur tindak lanjut.
Identifikasi sumber daya berkualitas termasuk personil,
pelatihan, dan elemen infrastruktur.
Menetapkan mekanisme kontrol.
Untuk perencanaan
Untuk kebutuhan pelanggan
20 BAGIAN KETIGA MANAJEMEN MUTU

TDI
16.8 A SQA PLAN
SQA Plan memberikan peta jalan untuk melembagakan jaminan kualitas perangkat lunak.
Dikembangkan oleh grup SQA (atau oleh tim perangkat lunak jika grup SQA tidak ada),
rencana berfungsi sebagai templat untuk aktivitas SQA yang dilembagakan untuk setiap
proyek perangkat lunak.
Standar untuk rencana SQA telah diterbitkan oleh IEEE [IEE93]. Standar
merekomendasikan struktur yang mengidentifikasi: (1) tujuan dan ruang lingkup rencana, (2)
deskripsi dari semua produk pekerjaan rekayasa perangkat lunak (misalnya, model, dokumen,
kode sumber) yang termasuk dalam lingkup SQA, (3) ) semua standar dan praktik yang
berlaku yang diterapkan selama proses perangkat lunak, (4) tindakan dan tugas SQA
(termasuk ulasan dan audit) dan penempatannya di seluruh proses perangkat lunak, (5) alat
dan metode yang mendukung tindakan dan tugas SQA, ( 6) prosedur manajemen konfigurasi
perangkat lunak (Bab 22), (7) metode untuk merakit, menjaga, dan memelihara semua catatan
terkait SQA, dan (8) peran dan tanggung jawab organisasi relatif terhadap kualitas produk.

ALAT PERANGKAT LUNAK

Manajemen Kualitas Perangkat Lunak digunakan untuk menilai kualitas dokumen persyaratan
perangkat lunak.
Objektif: Tujuan dari alat SQA adalah untuk
QPR ProcessGuide dan Scorecard, dikembangkan oleh QPR
membantu tim proyek dalam menilai dan
Perangkat lunak (www.qpronline.com), provides mendukung
meningkatkan kualitas produk kerja perangkat lunak.
untuk Six Sigma dan manajemen kualitas lainnya
Mekanika: Mekanika alat bervariasi. Secara umum, niat pendekatan.
adalah untuk menilai kualitas produk kerja tertentu. catatan: Alat dan Template Berkualitas, dikembangkan
oleh iSixSigma Berbagai alat pengujian perangkat lunak (lihat Bab 17 (www.isixsigma.com/tt/), dejuru tulis
beragam melalui 20) sering termasuk dalam alat SQA alat yang berguna dan methods untuk manajemen kualitas.
kategori. Sumber Daya Kualitas NASA, dikembangkan oleh Goddard
Pusat Penerbangan Luar Angkasa (sw-assurance.gsfc.nasa
Alat Perwakilan:4
.gov / index.php) menyediakan formulir, templat,
LENGAN, dikembangkan oleh NASA (satc.gsfc.nasa.gov/ daftar periksa, dan alat untuk
SQA.
tools / index.html), memberikan langkah-langkah yang bisa dilakukan

4 Alat-alat yang dicatat di sini tidak mewakili suatu dukungan, tetapi lebih sebagai contoh alat dalam kategori ini.
Dalam kebanyakan kasus, nama-nama alat adalah merek dagang oleh pengembang masing-masing.
 BAB 16 JAMINAN KUALITAS PERANGKAT LUNAK 21

16.9 SUMMARY
Jaminan kualitas perangkat lunak adalah kegiatan payung rekayasa perangkat lunak yang
diterapkan pada setiap langkah dalam proses perangkat lunak. SQA mencakup prosedur untuk
penerapan metode dan alat yang efektif, pengawasan kegiatan pengendalian kualitas seperti
tinjauan teknis dan pengujian perangkat lunak, prosedur untuk manajemen perubahan,
prosedur untuk memastikan kepatuhan terhadap standar, dan mekanisme pengukuran dan
pelaporan.
Untuk melakukan jaminan kualitas perangkat lunak dengan benar, data tentang proses
rekayasa perangkat lunak harus dikumpulkan, dievaluasi, dan disebarluaskan. Statistik SQA
membantu meningkatkan kualitas produk dan proses perangkat lunak itu sendiri. Model
keandalan perangkat lunak memperluas pengukuran, memungkinkan data cacat yang
dikumpulkan diekstrapolasi ke dalam tingkat kegagalan yang diproyeksikan dan prediksi
keandalan.
Singkatnya, Anda harus mencatat kata-kata Dunn dan Ullman [Dun82]: "Jaminan kualitas
perangkat lunak adalah pemetaan aturan manajerial dan disiplin desain jaminan kualitas ke
ruang manajerial dan teknologi rekayasa perangkat lunak yang berlaku." Kemampuan untuk
memastikan kualitas adalah ukuran dari disiplin teknik yang matang. Ketika pemetaan
berhasil dilakukan, rekayasa perangkat lunak yang matang adalah hasilnya.

PMASALAH DAN POINTS TO PONDER

FLAINNYA RGEMASAN DAN sayaNFORMASI SOURCES

Buku oleh Hoyle (Fundamentals Manajemen Kualitas, Butterworth-Heinemann, 2007), Tian (Rekayasa
Kualitas Perangkat Lunak, Wiley-IEEE Computer Society Press, 2005), El Emam (ROI dari Kualitas
Perangkat Lunak, Auerbach, 2005), Horch (Panduan Praktis untuk Manajemen Kualitas Perangkat Lunak,
Artech House, 2003), dan Nance dan Arthur (Mengelola Kualitas Perangkat Lunak, Springer, 2002)
adalah presentasi tingkat manajemen yang sangat baik tentang manfaat program jaminan kualitas formal
untuk perangkat lunak komputer. Buku oleh Deming [Dem86], Juran (Juran pada Kualitas oleh Desain,
Free Press, 1992), dan Crosby ([Cro79] dan Kualitas Masih Gratis, McGraw-Hill, 1995) tidak fokus pada
perangkat lunak, tetapi harus membaca untuk manajer senior dengan tanggung jawab pengembangan
perangkat lunak. Gluckman and Roome (Pahlawan Sehari-hari dari Gerakan Berkualitas, Dorset House,
1993) memanusiakan masalah kualitas dengan menceritakan kisah para pemain dalam proses kualitas. Kan
(Metrik dan Model dalam Rekayasa Kualitas Perangkat Lunak, Addison-Wesley, 1995) menyajikan
pandangan kuantitatif kualitas perangkat lunak.
Buku oleh Evans (Kualitas Total: Manajemen, Organisasi dan Strategi, edisi ke-4, Penerbitan
SouthWestern College, 2004), Bru (Six Sigma untuk Manajer, McGraw-Hill, 2005), dan Dobb
(Pendaftaran Kualitas ISO 9001: 2000) -Langkah, ed. 3d, Butterworth-Heinemann, 2004) mewakili banyak
buku yang ditulis pada TQM, Six Sigma, dan ISO 9001: 2000, masing-masing.
Pham (Keandalan Perangkat Lunak Sistem, Springer, 2006), Musa (Rekayasa Keandalan Perangkat
Lunak: Perangkat Lunak yang Lebih Andal, Pengembangan dan Pengujian Lebih Cepat, 2d ed., McGraw-
Hill, 2004) dan Peled (Metode Keandalan Perangkat Lunak, Springer, 2001) telah menulis praktis panduan
yang menjelaskan metode untuk mengukur dan menganalisis keandalan perangkat lunak.
Vincoli (Panduan Dasar untuk Keamanan Sistem, Wiley, 2006), Dhillon (Keselamatan Rekayasa,
World Scientific Publishing Co., Inc., 2003), Hermann (Keselamatan dan Keandalan Perangkat Lunak,
Wiley-IEEE Computer Society Press, 2000), Storey (Keselamatan) -Critical Computer Systems, Addison-
22 BAGIAN KETIGA MANAJEMEN MUTU

Wesley, 1996), dan Leveson [Lev95] adalah diskusi paling komprehensif tentang keamanan perangkat
lunak dan sistem yang dipublikasikan hingga saat ini. Selain itu, van der Meulen (Definisi untuk Insinyur
Keselamatan Hardware dan Software, Springer-Verlag, 2000) menawarkan ringkasan lengkap dari konsep
dan ketentuan penting untuk keandalan dan keselamatan; Gartner (Pengujian Perangkat Lunak Terkait
Keselamatan, Springer-Verlag, 1999) memberikan panduan khusus untuk pengujian sistem kritis
keselamatan; Friedman and Voas (Penilaian Perangkat Lunak: Keamanan dan Uji Keandalan, Wiley,
1995) memberikan model yang berguna untuk menilai keandalan dan keamanan. Ericson (Teknik Analisis
Bahaya untuk Keamanan Sistem, Wiley, 2005) membahas domain yang semakin penting dalam analisis
bahaya.
Berbagai sumber informasi tentang jaminan kualitas perangkat lunak dan topik terkait tersedia di
Internet. Daftar referensi World Wide Web terkini yang relevan dengan SQA dapat ditemukan di situs
web SEPAwww.mhhe.com/engcs/compsci/pressman/professional/ olc / ser.htm.
KONSEP

17
UTAMA
uji alfa. . . . . .469 uji
beta. . . . . . .469
pengujian STRATEGI
kelas. . . . .466
tinjauan konfigurasi.
. . . . . . .468 PENGUJIAN PERANGKAT LUNAK
debugging. . . . . .

SEBUAH
473
penyebaran strategi untuk pengujian perangkat lunak
pengujian. . . . . . . . . menyediakan peta jalan yang
472 menggambarkan langkah-langkah yang
kelompok uji
independen. . . . . . harus dilakukan sebagai bagian dari pengujian, ketika langkah-langkah ini direncanakan dan
452 kemudian dilakukan, dan berapa banyak upaya, waktu, dan sumber daya yang akan diperlukan.
BAB Oleh karena itu, setiap strategi pengujian harus memasukkan perencanaan pengujian, desain kasus
pengujian, pelaksanaan pengujian, dan pengumpulan serta evaluasi data yang dihasilkan.
Strategi pengujian perangkat lunak harus cukup fleksibel untuk mempromosikan pendekatan
pengujian khusus. Pada saat yang sama, itu harus cukup kaku untuk mendorong perencanaan yang
wajar dan pelacakan manajemen ketika proyek berlangsung. Shooman [Sho83] membahas
masalah ini:

Dalam banyak hal, pengujian adalah proses individualistis, dan jumlah jenis tes yang berbeda bervariasi
sebanyak pendekatan pengembangan yang berbeda. Selama bertahun-tahun, kami

CEPAT Apa itu? Perangkat lunakSiapa

diuji yang
untuk
LIHATmengungkap kesalahan yang
dibuat secara tidak sengaja karena
dirancang dan dibangun. Tetapi
bagaimana Anda melakukan tes?
Haruskah Anda mengembangkan
rencana formal untuk tes Anda?
Haruskah Anda menguji keseluruhan
program secara keseluruhan atau
menjalankan tes hanya pada sebagian
kecil saja? Jika Anda menjalankan
kembali tes yang sudah Anda lakukan
saat Anda menambahkan komponen
baru ke sistem besar? Kapan Anda harus
melibatkan pelanggan? Ini dan banyak
pertanyaan lainnya dijawab ketika Anda
mengembangkan strategi pengujian
perangkat lunak.
melakukannya Strategi untuk
pengujian perangkat lunak dikembangkan
oleh manajer proyek, insinyur perangkat
lunak, dan spesialis pengujian.
Mengapa ini penting? Pengujian sering kali
menyumbang lebih banyak upaya proyek
daripada tindakan rekayasa perangkat
lunak lainnya. Jika hal itu dilakukan secara
sembarangan, waktu terbuang sia-sia,
usaha yang tidak perlu dikeluarkan, dan
bahkan lebih buruk lagi, kesalahan-
kesalahan telah berhasil dideteksi. Karena
itu akan masuk akal untuk membangun
strategi sistematis untuk pengujian
perangkat lunak.
Apa langkah-langkahnya? Pengujian dimulai
"dalam hal kecil" dan berlanjut "ke besar."
Maksud saya pengujian awal ini berfokus
pada satu komponen atau sekelompok
kecil komponen terkait dan menerapkan
tes ko untuk mengungkap kesalahan dalam
un mp memenuhi persyaratan pelanggan.
tu on Karena kesalahan terungkap, mereka
k en harus didiagnosis dan diperbaiki
me diu menggunakan proses yang disebut
ng ji debugging.Apa produk pekerjaan?Sebuah
un me Spesifikasi Tes mendokumentasikan
gk rek pendekatan tim perangkat lunak untuk
ap a pengujian dengan menetapkan rencana
ke har yang menggambarkan keseluruhan
sal us strategi dan prosedur yang
ah dii menentukan langkah-langkah
an nte pengujian spesifik dan jenis tes yang
dal gra akan dilakukan.
am sik Bagaimana saya memastikan bahwa saya
da an telah melakukannya dengan benar?
ta sa Dengan meninjau Spesifikasi Tes
da mp sebelum pengujian, Anda dapat
n ai menilai kelengkapan kasus uji dan
log sist tugas pengujian. Rencana dan
ika em prosedur pengujian yang efektif
pe len akan mengarah pada pembangunan
mr gka tertib perangkat lunak dan
os p penemuan kesalahan pada setiap
es dib tahap dalam proses konstruksi.
an ang
ya un. 449
ng Pa
tel da
ah titi
die k
nk ini,
ap ser
sul ang
asi kai
ole an
h tes
ko tin
m gka
po t
ne tin
n. ggi
Set dija
ela lan
h kan