Chapter 2 What is Software Quality? 2.1 Definisi Software Software: Program komputer, prosedur, dan dokumentasi dan data yang berkaitan dengan pengoperasian suatu sistem komputer. Keempat komponen yang diperlukan dalam rangka untuk menjamin kualitas proses pengembangan perangkat lunak dan untuk alasan pelayanan pemeliharaan pada masa mendatang adalah sebagai berikut: Program komputer ("code") diperlukan untuk mengaktifkan komputer untuk melakukan aplikasi yang diperlukan. Prosedur yang diperlukan, untuk menentukan urutan dan jadwal di mana program yang dilakukan, metode yang digunakan, dan orang yang bertanggung jawab untuk melakukan kegiatan yang diperlukan untuk menerapkan perangkat lunak. Berbagai jenis dokumentasi yang dibutuhkan untuk pengembang, pengguna dan personil pemeliharaan. o Dokumentasi pengembangan (laporan persyaratan, laporan desain, deskripsi program, dll) yang memungkinkan kerjasama yang efisien dan koordinasi antara anggota tim pengembangan dan ulasan serta inspeksi dengan tujuan efisiensi dari desain dan produk pemrograman. o
Dokumentasi pemeliharaan ("manual programmer" perangkat lunak, dll) untuk menyediakan tim pemeliharaan dengan semua informasi yang diperlukan tentang kode, dan struktur dan tugas/fungsi dari masing-masing modul perangkat lunak. Informasi ini digunakan pada saat mencoba menemukan penyebab kegagalan perangkat lunak ("bug") atau untuk mengubah atau menambah perangkat lunak yang ada.
Data termasuk parameter, kode dan daftar nama yang mengadaptasi perangkat lunak. Untuk kebutuhan pengguna tertentu mungkin diperlukan operasi tertentu dari perangkat lunak. Tipe lain dari data adalah data standar untuk tes, digunakan untuk memastikan bahwa tidak ada perubahan yang tidak diinginkan dalam kode atau data perangkat lunak, dan apa jenis kerusakan apa yang diharapkan pada perangkat lunak.
2.2 Software errors, faults and failures Asal dari kegagalan perangkat lunak (software failures) terletak pada kesalahan perangkat lunak (software error) yang dibuat oleh programmer. Sebuah error dapat berupa kesalahan tata bahasa dalam satu atau lebih baris kode, atau kesalahan logis dalam melaksanakan satu atau lebih dari kebutuhan klien. Tidak semua error pada perangkat lunak menjadi kesalahan perangkat lunak (software fault). Dengan kata lain, error pada perangkat lunak hanya menyebabkan fungsi yang tidak tepat dari perangkat lunak secara umum atau dalam aplikasi tertentu. Sebuah kesalahan pada perangkat lunak (software faults) akan menjadi kegagalan pada perangkat lunak (software failure) hanya ketika “diaktifkan", artinya ketika user mencoba menjalankan perangkat lunak yang fault tersebut.
2.3 Classification of the causes of software errors Error pada perangkat lunak adalah penyebab berkurangnya kualitas perangkat lunak. Error pada software
dapat berupa "kesalahan kode", sebuah "kesalahan prosedur", sebuah "kesalahan dalam dokumentasi", atau "kesalahan data software". Penyebab dari semua kesalahan ini adalah manusia, yaitu kesalahan yang dibuat oleh analis sistem, programer, penguji perangkat lunak, ahli dokumentasi, manajer dan bahkan klien itu sendiri . Penyebab kesalahan perangkat lunak dapat diklasifikasikan lebih lanjut sebagai berikut sesuai dengan tahapan proses pembangunan perangkat lunak. (1) Kegagalan dalam pendefinisian dari kebutuhan Gagalnya pendefinisian dari kebutuhan, biasanya disebabkan oleh klien. Jenis kegagalannya berupa: Kesalahan pendefinisian kebutuhan. Beberapa kebutuhan utama/vital tidak disebutkan. Pendefinisian kebutuhannya tidak lengkap. Pencantuman persyaratan/kebutuhan yang tidak benar-benar diperlukan. (2) Kegagalan komunikasi antara klien-pengembang Kesalahpahaman yang diakibatkan cacat/kegagalan komunikasi antara client-pengembang merupakan penyebab lain terjadinya error kesalahan yang terjadi pada tahap awal dari proses pembangunan:
Kesalahpahaman terhadap instruksi klien sebagaimana dinyatakan dokumen kebutuhan. Kesalahpahaman terhadap perubahan kebutuhan klien yang disampaikan kepada pengembang dalam bentuk tertulis selama periode pembangunan. Kesalahpahaman terhadap perubahan kebutuhan klien yang disampaikan secara lisan kepada pengembang selama masa pembangunan. Kesalahpahaman atas tanggapan klien terhadap masalah desain yang disajikan oleh pengembang. Kurangnya perhatian pada pesan klien atas perubahan kebutuhan dan respon klien untuk pertanyaan yang diajukan oleh pengembang pada bagian dari proses pengembangan.
(3) Penyimpangan yang disengaja dari kebutuhan perangkat lunak Dalam beberapa keadaan, pengembang sengaja menyimpang dari persyaratan/kebutuhan yang sudah didokumentasikan, tindakan yang sering menyebabkan kesalahan perangkat lunak. Situasi yang paling umum dari penyimpangan yang disengaja adalah:
Pengembang menggunakan kembali modul perangkat lunak yang diambil dari proyek sebelumnya tanpa analisis yang cukup dari perubahan dan benar-benar memenuhi semua kebutuhan software yang baru. Karena tekanan waktu atau anggaran, pengembang memutuskan untuk menghilangkan bagian dari fungsi yang diperlukan dalam upaya untuk mengatasi tekanan ini. Inisiatif Sendiri. Pengembang melakukan perbaikan/pengembangan perangkat lunak tanpa persetujuan klien, sering mengabaikan persyaratan yang tampaknya kecil dari sisi pengembang.
(4) Kesalahan desain logis Kesalahan perangkat lunak (software error) seperti ini biasanya terjadi saat para profesional yang merancang sistem - sistem arsitek, insinyur perangkat lunak, analis, dll – sedang merumuskan kebutuhan dari perangkat lunak. Kesalahan khas meliputi:
Definisi kebutuhan perangkat lunak dengan algoritma yang salah. Pendefinisian proses yang mengandung kesalahan dalam urutan (sequence).
Sebagai contoh, persyaratan perangkat lunak untuk sistem pengumpulan utang sebuah perusahaan menentukan proses koleksi utang sebagai berikut. Setelah klien tidak membayar utang-utangnya,
bahkan setelah menerima tiga surat pemberitahuan berturut-turut, rincian tentang klien harus dilaporkan kepada manajer departemen penjualan yang akan memutuskan apakah klien tersebut akan dirujuk ke departemen hukum atau tidak. Sistem analis mendefinisikan proses dengan tidak benar dengan menyatakan bahwa setelah mengirimkan tiga surat berturut-turut, dan klien tetap tidak melakukan pembayaran, perusahaan akan memasukan nama klien pada daftar klien untuk ditangani oleh departemen hukum. Kesalahan logis disebabkan oleh kelalaian analis pada proses koleksi utang.
Keliru pendefinisian kondisi batas. Misalnya, kebutuhan klien menyatakan bahwa diskon khusus akan diberikan kepada pelanggan yang melakukan pembelian lebih dari tiga kali dalam bulan yang sama. Analis keliru mendefinisikan proses pada perangkat lunak untuk menyatakan bahwa diskon akan diberikan kepada mereka yang melakukan pembelian tiga kali atau lebih dalam bulan yang sama. Penghapusan statement dari sistem perangkat lunak yang diperlukan. Misalnya, diperlukan alat komputerisasi real-time untuk bereaksi sesuai dengan kombinasi temperatur dan tekanan. Analis tidak mendefinisikan reaksi diperlukan ketika suhu lebih dari 120 ° C dan tekanan antara 6 dan 8 atmosfer. Penghapusan definisi tentang reaksi operasi yang tidak diperbolehkan dari sistem perangkat lunak. Sebagai contoh, dalam sistem online teater tiketing, sistem perangkat lunak yang diperlukan untuk membatasi penjualan untuk 10 tiket per pelanggan. Oleh karena itu, setiap permintaan untuk pembelian lebih dari 10 tiket adalah "ilegal". Dalam desain, analis menuliskan pesan yang menyatakan bahwa penjualan terbatas sampai 10 tiket per pelanggan, tetapi tidak mendefinisikan reaksi sistem untuk kasus dimana seorang pelanggan (yang mungkin tidak membaca pesan) memasukan jumlah lebih dari 10. Ketika melakukan permintaan yang “ilegal”, sistem "crash" dan tidak ada reaksi dari sistem untuk operasi “ilegal” tersebut.
(5) Kesalahan Coding Terdapat banyak alasan yang menyebabkan seorang programmer untuk membuat kesalahan coding. Antara lain kesalahpahaman pada dokumentasi desain, kesalahan linguistik dalam bahasa pemrograman, kesalahan dalam penerapan CASE dan tools pembangunan lainnya, kesalahan dalam seleksi data, dan sebagainya. (6) Tidak dipenuhinya dokumentasi dan instruksi pengkodean Hampir setiap unit pengembangan memiliki dokumentasi sendiri dan standar pengkodean yang mendefinisikan konten, urutan dan format dari dokumen, dan kode yang dibuat oleh anggota tim. Untuk mendukung kebutuhan ini, unit mengembangkan dan mempublikasikan template dan instruksi pengkodean. Anggota tim pengembang atau unit diwajibkan untuk memenuhi kebutuhan tersebut. (7) Kelemahan dari proses pengujian Kelemahan proses pengujian mempengaruhi tingkat kesalahan dengan meninggalkan sejumlah besar kesalahan yang tidak terdeteksi atau dikoreksi. Kelemahan tersebut disebabkan:
Rencana uji yang tidak lengkap dapat menyebabakan tidak diperbaikinya beberapa bagian dari perangkat lunak atau fungsi aplikasi suatu sistem. Kegagalan untuk mendokumentasikan dan melaporkan kesalahan yang terdeteksi. Kegagalan untuk segera memperbaiki kesalahan perangkat lunak yang terdeteksi. Koreksi kesalahan yang terdeteksi tidak lengkap karena kelalaian atau tekanan waktu.
(8) Kesalahan prosedur Prosedur mengarahkan user pada kegiatan yang diperlukan pada setiap langkah proses. Prosedur adalah penting khususnya dalam sistem software yang kompleks di mana pengolahan dilakukan dalam beberapa langkah. (9) Kesalahan dokumentasi Kesalahan dokumentasi yang dapat mengganggu tim pengembangan dan pemeliharaan adalah kesalahan dalam dokumen desain dan dalam dokumentasi yang terintegrasi ke dalam perangkat lunak. Kesalahan ini dapat menyebabkan tambahan kesalahan dalam tahap lanjut dari kegiatan pengembangan dan pemeliharaan. Tipe lain dari kesalahan dokumentasi, salah satu yang mempengaruhi pihak pengguna adalah kesalahan dalam “user manual” dan dalam "helps" yang ditampilkan dalam perangkat lunak. Kesalahan khas jenis ini adalah:
Penghapusan fungsi perangkat lunak. Kesalahan dalam penjelasan dan instruksi yang diberikan kepada pengguna, sehingga menghasilkan "dead-end” / buntu" atau aplikasi yang salah. Daftar fungsi perangkat lunak yang tidak ada, yaitu fungsi pernah direncanakan pada tahap awal pengembangan tetapi kemudian dihapus, atau fungsi yang ada dalam versi sebelumnya tetapi dihapus pada versi terbaru.
2.4 Software quality – definition Kualitas perangkat lunak - IEEE definisi Kualitas perangkat lunak adalah: 1. Tingkat dimana suatu sistem, komponen, atau proses tertentu memenuhi kebutuhan/persyaratan. 2. Tingkat dimana sebuah sistem, komponen, atau proses memenuhi kebutuhan atau harapan pelanggan atau pengguna. Pernyataan diatas menawarkan dua alternatif definisi kualitas perangkat lunak, yang disampaikan oleh pendiri jaminan kualitas modern, Philip B. Crosby dan Joseph M. Juran. Setiap definisi mencerminkan konsepsi yang berbeda dari kualitas perangkat lunak: "Kualitas berarti kesesuaian dengan persyaratan/kebutuhan" (Crosby, 1979). "(1) Kualitas terdiri dari fitur-fitur produk yang memenuhi kebutuhan pelanggan dan dengan demikian memberikan kepuasan produk. (2) Kualitas terdiri dari kebebasan dari kekurangan "(Juran, 1988). Kualitas perangkat lunak - Pressman definisi: Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software. Kesesuaian dengan persyaratan fungsional dan kinerja yang secara eksplisit dinyatakan, standar pengembangan didokumentasikan secara eksplisit dan secara implisit menyatakan karakteristik yang diharapkan dari semua perangkat lunak yang dikembangkan secara profesional.
Definisi Pressman yang menyarankan tiga persyaratan untuk jaminan kualitas yang harus dipenuhi oleh pengembang:
Kebutuhan fungsional yang spesifik, yang terutama merujuk pada output dari perangkat lunak sistem. Standar kualitas perangkat lunak yang disebutkan dalam kontrak. Good Software Enginering Practices (GSEP), mencerminkan state-of-the-art kegiatan profesional, yang harus dipenuhi oleh pengembang meskipun tidak secara eksplisit disebutkan dalam kontrak.
2.5 Jaminan kualitas perangkat lunak - definisi dan tujuan Jaminan kualitas perangkat lunak - definisi IEEE Jaminan kualitas perangkat lunak adalah: 1. Sebuah pola yang direncanakan dan sistematis dari semua tindakan yang diperlukan untuk memberikan keyakinan yang memadai bahwa suatu barang atau produk didirikan sesuai dengan persyaratan teknis. 2. Satu set kegiatan yang dirancang untuk mengevaluasi proses bagaimana produk yang dikembangkan atau diproduksi. Kontras dengan kontrol kualitas. Definisi ini dapat dicirikan sebagai berikut:
Merencanakan dan menerapkan secara sistematis. SQA didasarkan pada perencanaan dan penerapan berbagai tindakan yang diintegrasikan ke dalam semua tahapan proses pengembangan perangkat lunak. Hal ini dilakukan untuk membuktikan kepercayaan klien bahwa produk perangkat lunak akan memenuhi semua persyaratan teknis. Melihat proses pengembangan perangkat lunak. Melihat spesifikasi dari persyaratan teknis.
Meskipun penekanannya pada perencanaan dan pelaksanaan yang sistematis, definisi IEEE menyatakan lingkup SQA dalam beberapa arah, termasuk pemeliharaan dan masalah jadwal serta anggaran. Penyimpangan utama dari definisi IEEE adalah:
SQA tidak harus dibatasi pada proses pembangunan. Sebaliknya, harus diperluas untuk mencakup pelayanan/maintenance jangka panjang dan proses pengiriman produk. SQA tindakan tidak harus terbatas pada aspek teknis dari persyaratan fungsional, tetapi harus mencakup juga kegiatan yang berhubungan dengan penjadwalan dan anggaran. Alasannya karena terdapat hubungan erat antara kegagalan jadwal atau anggaran dengan kegagalan dalam pemenuhan persyaratan teknis fungsional.
2.5.2 Perangkat Lunak jaminan kualitas vs kontrol kualitas perangkat lunak Dua frase terus-menerus diulang dalam konteks kualitas perangkat lunak: "Kualitas kontrol" dan "jaminan kualitas". Apakah mereka identik? Bagaimana mereka berhubungan? Menurut definisi perangkat lunak jaminan kualitas IEEE: Kontrol kualitas didefinisikan sebagai "seperangkat kegiatan yang dirancang untuk mengevaluasi kualitas suatu produk yang dikembangkan atau diproduksi" (IEEE, 1991); dengan kata lain, kegiatan yang tujuan utamanya adalah pemotongan atau penghapusan setiap produk yang tidak memenuhi syarat. Dengan demikian, kontrol kualitas adalah kegiatan yang berlangsung selama
proses pengembangan atau pembuatan produk hingga selesai namun sebelum produk dikirim ke klien. Tujuan utama dari jaminan kualitas adalah untuk meminimalkan biaya proses penjaminan kualitas yang terdiri dari berbagai kegiatan yang dilakukan di seluruh pengembangan dan proses/tahapan manufaktur. Kegiatan ini mencegah penyebab kesalahan, dan mendeteksi dan memperbaikinya sejak awal proses pembangunan. Akibatnya, kegiatan jaminan kualitas secara substansial mengurangi biaya pengiriman suatu produk yang tidak memenuhi syarat dan mengurangi biaya penenjaminan kualitas dalam kebanyakan kasus.
2.5.3 The objectives of SQA activities Tujuan dari kegiatan SQA Pengembangan perangkat lunak (berorientasi proses): 1. Menjamin suatu tingkatan kepercayaan yang dapat diterima bahwa perangkat lunak akan sesuai dengan persyaratan teknis fungsional. 2. Menjamin suatu tingkatan kepercayaan yang dapat diterima bahwa perangkat lunak akan sesuai dalam jadwal dan anggaran yang disyaratkan pihak manajemen. 3. Memulai dan mengelola kegiatan untuk perbaikan tingkat efisiensi yang lebih besar dari pengembangan perangkat lunak dan kegiatan SQA. Ini berarti meningkatkan prospek bahwa persyaratan fungsional dan manajerial akan dicapai sambil mengurangi biaya selama melaksanakan pembangunan perangkat lunak pembangunan dan kegiatan SQA. Pemeliharaan perangkat lunak (berorientasi produk): 1. Menjamin dengan tingkat keyakinan yang dapat diterima bahwa kegiatan pemeliharaan perangkat lunak akan sesuai dengan persyaratan teknis fungsional. 2. Menjamin dengan tingkat keyakinan yang dapat diterima bahwa kegiatan pemeliharaan perangkat lunak akan sesuai dengan penjadwalan manajerial dan kebutuhan anggaran. 3. Memulai dan mengelola kegiatan untuk memperbaiki dan meningkatkan efisiensi pemeliharaan perangkat lunak dan kegiatan SQA. 2.6 Software quality assurance and software engineering Menurut IEEE (1991), rekayasa perangkat lunak didefinisikan sebagai berikut: (1) Penerapan pendekatan sistematis, disiplin, diukur untuk pengembangan, operasional dan pemeliharaan perangkat lunak; yaitu, penerapan rekayasa perangkat lunak. (2) Studi pendekatan seperti pada (1). Karakteristik rekayasa perangkat lunak, seperti sistematis, disiplin dan pendekatan kuantitatif, pada intinya adalah membuat suatu lingkungan proses rekayasa perangkat lunak dengan infrastruktur yang baik untuk mencapai tujuan SQA. Metodologi dan alat-alat yang diterapkan oleh proses rekayasa perangkat lunak menentukan tingkat kualitas yang diharapkan dari proses dan layanan pemeliharaan perangkat lunak. Oleh karena itu, ketika membuat keputusan tentang metodologi dan tools pengembangan perangkat lunak, pertimbangan SQA ditambahkan untuk alasan efisiensi dan ekonomi yang terkait dengan rekayasa perangkat lunak. Pada umumnya diterima bahwa kerjasama antara ahli perangkat lunak dan tim SQA adalah cara yang tepat untuk mencapai efisien dan ekonomi kegiatan pembangunan dan pemeliharaan, pada saat yang sama, menjamin kualitas produk dari kegiatan ini.
Sumber: Software Quality Assurance From Theory To Implementation By Daniel Galin Terjemahan: Dadang Latif, M.Kom
