1. Dasar-dasar kualitas software (bagian 4)

Pada pembahasan sebelumnya, yaitu Dasa-dasar kualitas software (bagian 3) telah disebutkan 8 penyebab masalah perangkat lunak yang populer. Berikut ini adalah pembahasannya:

1.3.1 Masalah dalam Mendefinisikan Persyaratan

Mendefinisikan persyaratan perangkat lunak sekarang dianggap sebagai spesialisasi, yang berarti seorang analis bisnis atau insinyur perangkat lunak yang berspesialisasi dalam persyaratan. Definisi persyaratan adalah topik kelompok kepentingan serta subjek program sertifikasi profesi (lihat http://www.iiba.org).

Ada sejumlah masalah tertentu terkait dengan penulisan persyaratan yang jelas, benar, dan ringkas sehingga dapat diubah menjadi spesifikasi yang dapat langsung digunakan oleh rekan kerja, seperti arsitek, desainer, programmer, dan penguji.
Juga harus dipahami bahwa ada sejumlah aktivitas tertentu yang harus dikuasai saat memunculkan persyaratan, yaitu:

• Mengidentifikasi pemangku kepentingan (terutama pemain kunci) yang harus berpartisipasi dalam elisitasi persyaratan;

• Mengelola pertemuan;

• Teknik wawancara yang dapat mengidentifikasi perbedaan antara keinginan, harapan, dan kebutuhan yang sebenarnya;

 

• Dokumentasi yang jelas dan ringkas tentang persyaratan fungsional, persyaratan kinerja, kewajiban, dan properti sistem masa depan;

• Menerapkan teknik sistematis untuk elisitasi kebutuhan;

• Mengelola prioritas dan perubahan (misalnya perubahan persyaratan).

Jelas bahwa kesalahan dapat ditemukan saat memunculkan persyaratan. Mungkin sulit untuk memenuhi keinginan, harapan, dan kebutuhan banyak kelompok pengguna yang berbeda secara bersamaan (lihat Gambar 1.4). Oleh karena itu, penting untuk memberikan perhatian khusus pada definisi kebutuhan yang salah, kurangnya definisi untuk kewajiban kritis dan karakteristik perangkat lunak, penambahan persyaratan yang tidak perlu (misalnya, yang tidak diminta oleh pelanggan), kurangnya perhatian pada prioritas bisnis, dan deskripsi kebutuhan fuzzy.

Memesan Sup

Katakanlah Kita memesan sup di restoran. Persyaratan yang Kita nyatakan adalah "Saya ingin sup hari ini." Namun pada kenyataannya, keinginan, harapan, dan kebutuhan yang tidak diungkapkan antara lain: tidak terlalu panas, tidak terlalu dingin; sup yang tidak terlalu asin; peralatan makan, garam, dan merica tersedia di atas meja; kamar kecil yang bersih; meja yang terletak dengan baik; lingkungan yang tenang. Dan itu adalah persyaratan sederhana, bayangkan perangkat lunak yang kompleks!

Suatu persyaratan dikatakan berkualitas baik jika memenuhi karakteristik sebagai berikut:

• Benar;

• Menyelesaikan;

• Jelas untuk setiap kelompok pemangku kepentingan (misalnya, klien, arsitek sistem, penguji, dan mereka yang akan memelihara sistem);

• Jelas, yaitu interpretasi persyaratan yang sama dari semua pemangku kepentingan;

• Ringkas (sederhana, tepat);

• Konsisten;

• Layak (realistis, mungkin);

• Diperlukan (merespon kebutuhan klien);

• Independen dari desain;

• Terlepas dari teknik implementasi;

• Dapat diverifikasi dan diuji;

• Dapat ditelusuri kembali ke kebutuhan bisnis;

• Unik.

kita akan menyajikan teknik untuk membantu mendeteksi cacat dalam dokumentasi persyaratan di bab selanjutnya tentang tinjauan/review. Kita juga harus memastikan bahwa kita tidak akan mengejar produk yang sempurna tanpa cacat, karena kita tidak selalu memiliki waktu atau sarana, atau anggaran, untuk mencapai tingkat kesempurnaan ini.

Artikel oleh Ambler [AMB 04] berjudul “Memeriksa Pendekatan Persyaratan Besar di Awal” menunjukkan bahwa terkadang tidak efektif untuk menulis persyaratan terperinci di awal siklus hidup proyek perangkat lunak. Dia mengklaim bahwa pendekatan tradisional ini meningkatkan risiko kegagalan proyek. Dia menetapkan bahwa sebagian besar spesifikasi ini tidak terintegrasi dalam versi final perangkat lunak dan dokumentasi terkait jarang diperbarui selama proyek. Dengan demikian ia menegaskan bahwa cara kerja ini sudah ketinggalan zaman. Dalam artikelnya, ia merekomendasikan untuk menggunakan teknik agile yang lebih baru, seperti Test-Driven Development, untuk menghasilkan dokumentasi kertas dalam jumlah minimum.

Kita telah mengamati bahwa analis dan perancang perangkat lunak juga sering menggunakan prototyping, yang membantu menghilangkan sebagian dokumen persyaratan tradisional dan menggantinya dengan satu set antarmuka pengguna dan kasus uji yang menggambarkan persyaratan, arsitektur, dan desain perangkat lunak yang akan dikembangkan. Prototipe terbukti berguna untuk menunjukkan dengan tepat apa yang klien bayangkan dan mendapatkan umpan balik yang berharga di awal proyek. Pada bagian berikutnya, praktik pembangunan yang diadopsi oleh berbagai sektor bisnis akan dibahas.

Dalam sistem dengan komponen perangkat keras dan perangkat lunak, persyaratan dikembangkan pada tingkat sistem dan kemudian dialokasikan ke perangkat keras, perangkat lunak, dan terkadang ke operator. Gambar berikut mengilustrasikan interaksi antara proses siklus hidup sistem, perangkat keras, dan perangkat lunak.

 

Rekayasa sistem harus bekerja sama erat dengan rekayasa perangkat keras dan perangkat lunak selama alokasi persyaratan sistem (misalnya, fungsionalitas dan persyaratan kualitas seperti keselamatan dan kinerja) ke perangkat keras dan perangkat lunak.

1.3.2 Menjaga Komunikasi yang Efektif Antar Klien dan Pengembang

Kesalahan juga dapat terjadi pada produk perantara karena kesalah-pahaman yang tidak disengaja antara personel perangkat lunak dan klien dan pengguna sejak awal proyek perangkat lunak. Pengembang perangkat lunak dan insinyur perangkat lunak harus menggunakan bahasa non-teknis yang sederhana dan mencoba mempertimbangkan realitas pengguna. Mereka harus menyadari semua tanda-tanda kurangnya komunikasi, di kedua sisi. Contoh situasi ini adalah:

• Pemahaman yang buruk tentang instruksi klien;

• Klien menginginkan hasil yang segera;

• Klien atau pengguna tidak meluangkan waktu untuk membaca dokumentasi yang dikirimkan kepadanya;

• Pemahaman yang buruk tentang perubahan yang diminta dari pengembang selama desain;

• Analis berhenti menerima perubahan selama fase definisi dan desain persyaratan, mengingat bahwa untuk proyek tertentu 25% spesifikasi akan berubah sebelum akhir proyek.

 

Untuk meminimalkan error :

• Membuat catatan pada setiap pertemuan dan mendistribusikan notulen ke seluruh tim proyek;

• Meninjau dokumen yang dihasilkan;

• Konsisten dengan penggunaan istilah dan kembangkan daftar istilah untuk dibagikan kepada semua pemangku kepentingan;

• Menginformasikan klien tentang biaya perubahan spesifikasi;

• Pilih pendekatan pengembangan yang memungkinkan Kita menerima perubahan di sepanjang jalan;

• Beri nomor setiap persyaratan dan terapkan proses manajemen perubahan (seperti yang akan disajikan di bab lain).

HVCCR adalah perusahaan yang didedikasikan untuk penjualan online alat ventilasi, pendingin, dan pendingin udara khusus. Seorang klien menghubungi perusahaan yang memelihara katalog webnya untuk memperbarui beberapa gambar dan menambahkan beberapa produk terbaru. Tugas itu diperkirakan memakan waktu 10–20 menit kerja.
Orang yang bertanggung jawab untuk memelihara katalog web menghubungi klien dan memberitahunya bahwa untuk menyelesaikan pembaruan dari perubahan yang diminta, server harus dimulai ulang, yang dapat membatalkan sesi apa pun saat ini. Pekerjaan ini sebaiknya dilakukan pada malam hari. Klien, yang tidak sepenuhnya memahami dampak permintaannya, bersikeras agar pembaruan ini segera dilakukan. Pada saat pembaruan, beberapa pembeli sedang memproses pembayaran secara online. Mematikan sistem mengganggu transaksi bank, menyebabkan ketidakpuasan pelanggan serta korupsi data. HVCCR membutuhkan waktu beberapa hari untuk menangani keluhan pembeli dan memperbaiki masalah.

1.3.3 Penyimpangan dari Spesifikasi

Situasi ini terjadi ketika pengembang salah menafsirkan persyaratan dan mengembangkan perangkat lunak berdasarkan pemahamannya sendiri. Situasi ini menciptakan kesalahan yang sayangnya hanya dapat ditangkap di kemudian hari dalam siklus pengembangan atau selama penggunaan perangkat lunak.

Jenis penyimpangan lainnya adalah:

• Menggunakan kembali kode yang ada tanpa membuat penyesuaian yang memadai untuk memenuhi persyaratan baru;

• Memutuskan untuk membatalkan sebagian persyaratan karena anggaran atau tekanan waktu;

• Inisiatif dan peningkatan yang diperkenalkan oleh pengembang tanpa memverifikasi dengan klien.

1.3.4 Kesalahan Arsitektur dan Desain

Kesalahan dapat terselipkan ke dalam perangkat lunak ketika perancang (arsitek sistem dan data) menerjemahkan kebutuhan pengguna ke dalam spesifikasi teknis. Kesalahan desain tipikal adalah:

• gambaran umum yang tidak lengkap tentang perangkat lunak yang akan dikembangkan;

• peran yang tidak jelas untuk setiap komponen arsitektur perangkat lunak (tanggung jawab, komunikasi);

• data primer dan kelas pemrosesan data yang tidak ditentukan;

• desain yang tidak menggunakan algoritma yang benar untuk memenuhi persyaratan;

• urutan proses bisnis atau teknis yang salah;

• desain kriteria aturan bisnis atau proses yang buruk;

• desain yang tidak melacak kembali ke persyaratan;

• penghilangan status transaksi yang mewakili proses klien dengan benar;

• kegagalan untuk memproses kesalahan dan operasi ilegal, yang memungkinkan perangkat lunak untuk memproses kasus yang tidak akan ada di sektor bisnis klien hingga 80% dari kode program diperkirakan memproses pengecualian atau kesalahan.

  1.3.5 Kesalahan Pengkodean

Banyak kesalahan dapat terjadi dalam pembangunan perangkat lunak. McConnell (2004) [MCC 04] mencurahkan sebagian besar bukunya "Kode Lengkap" untuk menjelaskan teknik yang efektif untuk membuat kode sumber berkualitas. Dia menjelaskan kesalahan pemrograman umum dan inefisiensi. Menurut McConnell, kesalahan pemrograman yang khas adalah:

• pilihan bahasa pemrograman dan konvensi yang tidak tepat;

• tidak membahas bagaimana mengelola kompleksitas sejak awal;

• pemahaman/interpretasi yang buruk terhadap dokumen desain;

• abstraksi yang tidak koheren;

• kesalahan loop dan kondisi;

• kesalahan pemrosesan data;

• kesalahan urutan pemrosesan;

• kurangnya atau validasi data yang buruk pada saat input;

• desain kriteria aturan bisnis yang buruk;

• penghilangan status transaksi yang diperlukan untuk benar-benar mewakili proses klien;

• kegagalan untuk memproses kesalahan dan operasi ilegal, yang memungkinkan perangkat lunak untuk memproses kasus yang tidak akan ada di sektor bisnis klien;

• penugasan atau pemrosesan tipe data yang buruk;

• kesalahan dalam loop atau mengganggu indeks loop;

• kurangnya keterampilan dalam menangani sarang yang sangat kompleks;

• masalah pembagian bilangan bulat;

• inisialisasi variabel atau pointer yang buruk;

• kode sumber yang tidak melacak kembali ke desain;

• kebingungan tentang alias untuk data global (variabel global diteruskan ke subprogram).

1.3.6 Non-Complience / Ketidak-patuhan dengan Proses/Prosedur Saat Ini

Beberapa organisasi memiliki metodologi internal dan standar internal mereka sendiri untuk mengembangkan/memperoleh perangkat lunak. Metodologi internal ini menjelaskan proses, prosedur, langkah, hasil, templat, dan standar (misalnya, standar pengkodean) yang harus dipertimbangkan untuk akuisisi, pengembangan, pemeliharaan, dan operasi perangkat lunak. Tentu saja, dalam organisasi yang kurang matang, proses/prosedur ini tidak akan didefinisikan dengan jelas.

Oleh karena itu, kita dapat mengajukan pertanyaan berikut kepada diri kita sendiri: Bagian mana yang tidak memenuhi persyaratan yang terkait dengan metodologi internal dapat menyebabkan cacat pada perangkat lunak? Kita harus berpikir dalam hal siklus hidup total  (misalnya, selama beberapa dekade untuk kereta bawah tanah dan pesawat komersial) dari perangkat lunak, dan bukan hanya pengembangan awal. Jelas bahwa seseorang yang hanya memprogram kode tampaknya jauh lebih produktif daripada seseorang yang mengembangkan produk perantara, seperti persyaratan, rencana pengujian, dan dokumentasi pengguna, sebagaimana ditentukan oleh metodologi internal organisasi. Namun, produktivitas langsung akan merugikan dalam jangka panjang.

Perangkat lunak yang tidak berdokumen akan menimbulkan masalah baik cepat atau lambat berikut:

• Ketika anggota tim perangkat lunak perlu mengoordinasikan pekerjaan mereka, mereka akan mengalami kesulitan untuk memahami dan menguji perangkat lunak yang miskin dokumentasi atau tidak terdokumentasi dengan baik.

• Orang yang mengganti atau memelihara perangkat lunak hanya akan memiliki kode sumber sebagai referensi.

• SQA akan menemukan sejumlah besar ketidaksesuaian (berkenaan dengan metodologi internal) mengenai perangkat lunak ini.

• Tim penguji akan mengalami masalah dalam mengembangkan rencana dan skenario pengujian, terutama karena spesifikasinya tidak tersedia.

1.3.7 Ulasan dan Tes yang Tidak Memadai

Tujuan dari tinjauan dan pengujian perangkat lunak adalah untuk mengidentifikasi dan memeriksa bahwa kesalahan dan cacat telah dihilangkan dari perangkat lunak. Jika aktivitas ini tidak efektif, perangkat lunak yang dikirimkan ke klien kemungkinan akan rentan terhadap kegagalan.

Semua jenis masalah berikut dapat muncul saat meninjau dan menguji perangkat lunak:

• ulasan hanya mencakup sebagian kecil dari hasil perantara perangkat lunak;

• ulasan tidak mengidentifikasi semua kesalahan yang ditemukan dalam dokumentasi dan kode perangkat lunak;

• daftar rekomendasi yang berasal dari review tidak dilaksanakan atau ditindaklanjuti secara memadai;

• rencana pengujian yang tidak lengkap tidak cukup mencakup seluruh rangkaian fungsi perangkat lunak, meninggalkan bagian yang belum diuji;

• rencana proyek tidak menyisakan banyak waktu untuk melakukan tinjauan atau tes. Dalam beberapa kasus, langkah ini dipersingkat karena terjepit antara pengkodean dan pengiriman akhir. Penundaan pada langkah awal proyek tidak selalu berarti tanggal pengiriman akan diperpanjang, sehingga merugikan pengujian yang tepat;

• proses pengujian tidak melaporkan kesalahan atau cacat yang ditemukan dengan benar;

• cacat yang ditemukan diperbaiki, tetapi tidak tunduk pada pengujian regresi yang memadai (yaitu, pengujian ulang perangkat lunak yang dikoreksi secara lengkap) setelahnya.
  

1.3.8 Kesalahan Dokumentasi

Telah diakui bahwa dokumentasi usang atau tidak lengkap untuk perangkat lunak yang digunakan dalam suatu organisasi adalah masalah umum. Beberapa tim pengembangan menikmati menghabiskan waktu mempersiapkan dan meninjau dokumentasi.

Kita akan cenderung mengatakan tidak pada pertanyaan "apakah perangkat lunak aus?" Memang, angka 0 dan 1 yang ditemukan dalam memori tidak akan aus karena digunakan seperti halnya perangkat keras. Selain mengklasifikasikan jenis kesalahan, penting untuk memahami kurva keandalan yang khas untuk perangkat lunak. Gambar 1.5 menggambarkan kurva keandalan perangkat keras komputer sebagai fungsi waktu. Kurva ini disebut kurva berbentuk U atau bak mandi. Ini mewakili keandalan peralatan, seperti mobil, sepanjang siklus hidupnya.

Berkenaan dengan perangkat lunak, kurva keandalan lebih menyerupai apa yang ditunjukkan pada Gambar 1.6. Ini berarti bahwa kerusakan perangkat lunak terjadi dari waktu ke waktu karena, antara lain, banyak perubahan dalam persyaratan.

 

Profesor April bekerja di Timur Tengah antara tahun 1998 dan 2003 di sebuah perusahaan telekomunikasi besar. Ketika dia tiba, dia melihat bahwa dokumentasi asli untuk perangkat lunak aplikasi penting untuk perusahaan telepon belum diperbarui selama lebih dari 10 tahun. Tidak ada fungsi jaminan kualitas perangkat lunak di divisi teknologi informasi perusahaan itu.

 

Kesimpulannya, kita melihat bahwa ada banyak sumber kesalahan potensial, dan tanpa SQA, cacat ini dapat mengakibatkan kegagalan jika tidak ditemukan.