Chapter 1 The software quality challenge

Transkripsi

1 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

2 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:

3 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.

4 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.

5 Sumber: Software Quality Assurance From Theory To Implementation By Daniel Galin Terjemahan: Dadang Latif, M.Kom