Chapter 1

The software quality challenge

1.1 The uniqueness of software quality assurance
Pemeriksaan jaminan yang ditawarkan oleh pengembang perangkat lunak umumnya mengungkapkan
pola yang sama. Pengembang tidak akan menyatakan bahwa perangkat lunak ini bebas dari cacat,
sebagai mana dilakukan para produsen perangkat keras komputer. Penolakan ini sebenarnya
mencerminkan perbedaan unsur penting antara perangkat lunak dan produk industri lainnya, seperti
mobil, mesin cuci atau radio. perbedaan-perbedaan ini dapat dikategorikan sebagai berikut:
(1) Kompleksitas Produk.
Kompleksitas produk dapat diukur dengan jumlah mode operasional yang diizinkan suatu produk.
Sebuah produk industri, bahkan mesin canggih, tidak memungkinkan untuk menjalankan lebih dari
beberapa ribu mode operasi, yang diciptakan oleh kombinasi pengaturan mesin yang berbeda. Jika
melihat paket suatu perangkat lunak, seseorang dapat menemukan jutaan operasi di dalam sebuah
software. Oleh karena itu, untuk bisa menjamin 100% pada sebuah perangkat lunak adalah sebuah
tantangan besar .
(2) Visibilitas Produk.
Produk hasil industri dapat terlihat, produk perangkat lunak tidak terlihat. Sebagian besar cacat dalam
sebuah produk industri dapat dideteksi selama proses manufaktur. Namun, cacat pada produk
perangkat lunak (apakah disimpan pada disket atau CD) adalah tidak terlihat, karena kenyataannya
bahwa bagian-bagian dari paket perangkat lunak mungkin masih ada meskipun sudah diperbaiki sejak
awal.
(3) Pengembangan produk dan proses produksi.
Marilah kita sekarang meninjau fase di mana kemungkinan mendeteksi cacat dalam sebuah produk
industri mungkin timbul:
(a) Pengembangan produk. Dalam fase ini para desainer dan staf jaminan kualitas (QA)
memeriksa dan menguji prototipe produk, dalam rangka mendeteksi cacat tersebut.
(b) Perencanaan Produksi. Selama fase ini proses produksi dan alat-alat dirancang dan
dipersiapkan. Dalam beberapa produk ada kemungkinan bahwa serangkaian produk khusus
untuk dirancang dan dibangun. Sehingga fase ini dapat memberikan kesempatan tambahan
untuk memeriksa produk, yang dapat mengungkapkan cacat yang "lolos" dari review dan tes
yang dilakukan selama tahap pengembangan.
(c) Manufaktur. Pada fase ini prosedur QA diterapkan untuk mendeteksi kegagalan produk itu
sendiri. Cacat pada produk yang terdeteksi pada tahap awal biasanya dapat dikoreksi dengan
perubahan dalam desain produk atau bahan atau alat-alat produksi, dengan cara
menghilangkan cacat tersebut dalam produk yang akan diproduksi di masa depan.
Dibandingkan dengan produk industri, produk perangkat lunak tidak mendapatkan manfaat dari
kesempatan untuk mendeteksi cacat di semua tiga tahap proses produksi tersebut. Cacat hanya dapat
dideteksi pada tahap pengembangan.
Mari kita meninjau apa setiap tahap yang dapat memberikan kontribusi terhadap deteksi cacat:
(a) Pengembangan produk. Selama fase ini, upaya tim pengembangan dan profesional dalam
jaminan kualitas perangkat lunak yang diarahkan untuk mendeteksi cacat produk yang melekat.
Pada akhir fase ini sebuah prototipe disetujui, siap untuk reproduksi, menjadi tersedia.
(b) Produk perencanaan produksi. Fase ini tidak diperlukan untuk proses produksi perangkat lunak,
seperti pembuatan salinan perangkat lunak dan pencetakan manual perangkat lunak yang

dilakukan secara otomatis. Hal ini berlaku untuk semua produk perangkat lunak, apakah jumlah
salinan yang kecil, seperti dalam custom-made software, atau besar, seperti dalam paket
perangkat lunak yang dijual untuk umum.
(c) Manufaktur. Seperti disebutkan sebelumnya, pembuatan perangkat lunak terbatas untuk
menyalin salinan produk dan pencetakan manual perangkat lunak. Akibatnya, harapan untuk
mendeteksi cacat sangat terbatas selama fase ini.
Perbedaan mempengaruhi deteksi cacat pada produk perangkat lunak dibandingkan produk industri
lainnya ditunjukkan pada Tabel 1.1 dan Frame 1.1.

Perlu dicatat bahwa bagian-bagian penting dari mesin-mesin canggih serta mesin rumah tangga dan
produk lainnya, didalamnya tertanam komponen software (biasanya disebut "firmware") yang terintegrasi
ke dalam produk.
Komponen perangkat lunak ini (firmware) berbagi karakteristik dengan produk perangkat lunak yang
disebutkan di atas. Perbandingan yang ditunjukkan di atas adalah produk perangkat lunak dibandingkan
produk industri lainnya yang tidak memiliki firmware.

1.2 The environments for which SQA methods are Developed

Perangkat lunak dikembangkan oleh banyak individu dan dalam situasi yang berbeda sesuai dengan
kebutuhan:

Siswa dan mahasiswa mengembangkan perangkat lunak sebagai bagian dari pendidikan
mereka.
Perangkat lunak amatir mengembangkan perangkat lunak sebagai hobi.
Profesional di bidang teknik, ekonomi, manajemen dan bidang lainnya mengembangkan
perangkat lunak untuk membantu mereka dalam pekerjaan mereka, untuk melakukan
perhitungan, meringkas kegiatan penelitian dan survei, dan sebagainya.
Profesional pengembangan perangkat lunak (sistem analis dan programer) mengembangkan
produk perangkat lunak atau firmware sebagai tujuan karir profesional

Mari kita mulai dengan pemeriksaan lingkungan pengembangan perangkat lunak profesional dan
pemeliharaan (selanjutnya disebut "lingkungan SQA"), karena merupakan pertimbangan utama dalam
pengembangan metodologi SQA dan pelaksanaannya.
Karakteristik utama dari lingkungan ini adalah sebagai berikut:
1. Kondisi Kontrak. Sebagai hasil dari komitmen dan kondisi yang ditentukan dalam kontrak antara
pengembang software dan pelanggan, kegiatan pengembangan perangkat lunak dan
pemeliharaan perlu untuk mengatasi:
a. Harus memenuhi daftar persyaratan fungsional perangkat lunak yang akan
dikembangkan dan pemeliharaannya.
b. Anggaran proyek.
c. Jadwal proyek.
Para manajer proyek pengembangan perangkat lunak dan pemeliharaan perlu menginvestasikan
sejumlah besar usaha dalam pengawasan kegiatan dalam rangka memenuhi persyaratan
kontrak.
2. Ketaatan pada hubungan pelanggan-pemasok. Selama proses pengembangan perangkat lunak
dan pemeliharaan, kegiatan berada di bawah pengawasan dari para pelanggan. Tim proyek
harus bekerja sama terus menerus dengan pelanggan: untuk mempertimbangkan perubahan
atas permintaannya, untuk mendiskusikan kritik tentang berbagai aspek proyek, dan untuk
mendapatkan persetujuan untuk perubahan yang diprakarsai oleh tim pengembangan. Hubungan
seperti biasanya tidak ada ketika perangkat lunak dikembangkan bukan oleh profesional.
3. Diperlukan kerja sama tim. Tiga faktor biasanya memotivasi pembentukan tim proyek dan bukan
menetapkan proyek untuk satu profesional:
Persyaratan Jadwal. Dengan kata lain, beban kerja yang dilakukan selama periode
proyek membutuhkan partisipasi lebih dari setiap orang jika proyek tersebut akan selesai
tepat waktu.
Kebutuhan untuk berbagai spesialisasi dalam rangka untuk melaksanakan proyek
tersebut.
Keinginan untuk mendapatkan manfaat dari saling mendukung secara profesional dan
review untuk peningkatan kualitas proyek.
4. Kerjasama dan koordinasi dengan tim perangkat lunak lain. Pada proyek-proyek yang besar,
dikerjakan oleh lebih dari satu tim adalah suatu peristiwa yang sangat umum dalam industri
perangkat lunak. Dalam kasus ini, mungkin diperlukan kerjasama dengan:
tim pengembangan perangkat lunak lainnya dalam organisasi yang sama.
tim pengembangan Hardware di organisasi yang sama.
Perangkat lunak dan tim pengembangan perangkat keras dari pemasok lain.
Pelanggan perangkat lunak dan tim pengembangan perangkat keras yang mengambil
bagian dalam pengembangan proyek.

5. Antarmuka dengan sistem perangkat lunak lain. Saat ini, sistem perangkat lunak biasanya
mencakup antarmuka dengan paket perangkat lunak lain. Antarmuka ini memungkinkan data
dalam bentuk elektronik mengalir antara sistem perangkat lunak, bebas dari memasukkan dalam
data diproses oleh sistem perangkat lunak lain. Satu dapat mengidentifikasi jenis utama berikut
interface:
Masukan interface, di mana sistem perangkat lunak lainnya mengirimkan data ke sistem
perangkat lunak Anda.
Output interface, dimana sistem perangkat lunak Anda mentransmisikan data diproses ke
sistem perangkat lunak lain.
Input dan output antarmuka untuk panel kontrol mesin, seperti dalam medis dan
laboratorium sistem kendali, peralatan pengolahan logam, dll.
6. Kebutuhan untuk terus melaksanakan proyek meskipun perubahan anggota tim. Hal ini cukup
umum bagi anggota tim untuk keluar dari tim selama periode pengembangan proyek, apakah
karena promosi untuk pekerjaan yang lebih tinggi, ganti posisi di kantor, transfer ke kota lain, dan
sebagainya.
Pemimpin tim kemudian harus mengganti anggota tim baik dengan karyawan lain atau dengan
karyawan yang baru direkrut. Tidak peduli berapa banyak usaha diinvestasikan dalam pelatihan
anggota tim baru, "show must go on", sehingga jadwal proyek yang semula tidak akan berubah.
7. Kebutuhan untuk terus melakukan pemeliharaan perangkat lunak untuk periode yang dapat
diperpanjang. Pelanggan yang memesan atau membeli sistem perangkat lunak berharap untuk
terus memanfaatkannya untuk jangka panjang, biasanya untuk 5-10 tahun. Selama periode
pelayanan, kebutuhan untuk pemeliharaan akhirnya akan muncul. Dalam kebanyakan kasus,
pengembang diwajibkan memberikan layanan ini secara langsung. Pelanggan internal, dalam
kasus di mana perangkat lunak telah dikembangkan, berbagi harapan yang sama tentang
pemeliharaan perangkat lunak selama masa layanan dari sistem perangkat lunak.
Karakteristik lingkungan menciptakan kebutuhan bagi upaya manajerial yang intensif dan
berkesinambungan sejajar dengan upaya profesional yang harus diinvestasikan untuk menjamin
kualitas proyek, dengan kata lain untuk memastikan keberhasilan proyek.
Sebuah ringkasan dari karakteristik utama dari lingkungan SQA ditampilkan dalam Bingkai 1.2.

Beberapa pengembang perangkat lunak maupun pengembang firmware tidak mentaati kontrak formal
atau hubungan formal pelanggan-pemasok, seperti yang disebutkan dalam dua karakteristik lingkungan
pertama SQA.

Sumber: Software Quality Assurance From Theory To Implementation By Daniel Galin

Terjemahan: Dadang Latif, M.Kom