Jaminan Mutu dalam Kebutuhan Rekayasa

Abstrak Bab ini menyajikan survei dari keadaan untuk jaminan kualitas untuk persyaratan. Yang dimaksud kualitas dalam konteks persyaratan dibahas, seperti pengaruh jaminan kualitas selama persyaratan lainnya bagian dari pembangunan. Pendekatan jaminan kualitas yang berbeda dikategorikan baik sebagai konstruktif (misalnya, standar, pedoman, teknik elisitasi) atau analisis (misalnya, inspeksi) dan dibahas sehubungan dengan dampaknya terhadap persyaratan kualitas. Berdasarkan pendekatan, tantangan masa depan dibahas. itu tantangan utama masa depan terletak pada menyelidiki laba atas investasi dari jaminan kualitas dalam konteks kebutuhan dan memberikan hasil yang lebih empiris yang Pendekatan yang efektif mencegah atau mendeteksi masalah.

1. Pentingnya Jaminan Kualitas Terus meningkatnya kompleksitas, semakin meningkat tekanan pasar, dan tuntutan pelanggan untuk kualitas yang lebih tinggi memerlukan kombinasi yang dipilih dengan cermat validasi dan verifikasi teknik untuk memberikan produk software tepat waktu, sesuai anggaran dan dengan kualitas yang diinginkan. Rekayasa kebutuhan adalah bagian awal dari proses pengembangan perangkat lunak, dan semua langkah-langkah selanjutnya pembangunan dipengaruhi dengan persyaratan, sehingga kualitas persyaratan yang penting faktor untuk kualitas keseluruhan dari sistem yang dikembangkan.

Independen dari domain, jaminan kualitas (quality assurance -QA) adalah penting namun sulit dipahami bagian dari pengembangan perangkat lunak. Secara tradisional, teknik QA telah terutama difokuskan pada tahap perkembangan selanjutnya seperti tahap implementasi dan terkait kegiatan pengujian. Namun, QA dapat dan harus dimulai lebih awal. Mengapa penting untuk mendeteksi cacat sedini mungkin? Sebuah isu yang berasal dalam persyaratan menjalankan risiko yang mempengaruhi tidak hanya persyaratan lain tetapi juga tahap selanjutnya dan dapat menyebabkan cacat tindak lanjut dalam arsitektur, desain, coding dan pengujian, lihat Gb. 8.1

Dampak dari isu kebutuhan

2. Persyaratan dan Jaminan Kualitas Kualitas sulit untuk menentukan karena merupakan konsep yang rumit, tergantung pada organisasi sudut pandang dan karakteristik konteks [32]. Misalnya, apakah lebih sedikit cacat perbaris kode sama berkualitas tinggi? Bagaimana jika salah satu dari cacat ini menyebabkan hilangnya kerusakan sistem? Kualitas memiliki arti yang sangat berbeda dalam situasi yang berbeda. Dalam pengolah kata, kriteria kualitas yang berbeda penting daripada di unit kontrol elektronik dari mobil atau pesawat terbang.

2.1 Kualitas Persyaratan Kualitas kebutuhan tergantung pada berbagai pemangku kepentingan dan perspektif mereka. Beberapa pandangan yang berbeda perlu dipertimbangkan dalam rangka untuk menentukan apa kualitas berarti dalam konteks tertentu [32]. The first view pada kualitas adalah pandangan transendental. Di dalamnya, kualitas dianggap sebagai sesuatu yang kami selalu berusaha untuk sebagai ideal, tetapi kita tidak akan pernah dapat menerapkan ideal ini. Tujuan dari sudut pandang ini adalah untuk mengungkapkan kompleksitas kualitas konsep pada umumnya. Kedua, tampilan pengguna mengevaluasi kualitas produk perangkat lunak sehubungan dengan kebugaran yang tujuan untuk memenuhi tugas-tugas pengguna tertentu.

Atribut Kualitas untuk Prasyarat Quality Attribute Definition Correctness (IEEE, userview) Persyaratan yang diterapkan harus mencerminkan diharapkan (dimaksudkan) perilaku dari pengguna dan pelanggan. Artinya, segala sesuatu yang dinyatakan sebagai syarat adalah sesuatu yang harus dipenuhi oleh sistem akhir untuk memenuhi tujuan tertentu (kesesuaian). Unambiguity (IEEE, product-view) Persyaratan hanya harus memiliki satu interpretasi yang mungkin. Perhatikan bahwa salah satu persyaratan mungkin jelas untuk kelompok tertentu dari pemangku kepentingan namun memiliki arti yang berbeda di negara lain. Hal ini penting untuk melibatkan semua pemangku kepentingan dalam proses rekayasa kebutuhan untuk memperoleh pemahaman bersama (lihat bab. 2 dan 3)

Quality Attribute Definition Completeness (IEEE, product-view) Semua elemen penting yang relevan untuk memenuhi tugas-tugas pengguna yang berbeda yang harus dipertimbangkan. Ini termasuk kebutuhan fungsional dan non-fungsional yang relevan dan interface ke sistem lain, definisi tanggapan terhadap semua input potensi untuk sistem, semua referensi untuk gambar dan tabel dalam spesifikasi, dan definisi dari semua persyaratan dan langkah-langkah yang relevan. Consistency (IEEE, product, manufacturing view ) kebutuhan yang dinyatakan harus konsisten dengan semua persyaratan lainnya, dan kendala penting lainnya seperti pembatasan hardware, pembatasan anggaran, dll

Quality Attribute Definition Ranked for Importance / Stability (IEEE, product, value-based, user view) Setiap persyaratan menentukan pentingnya dan / atau stabilitas. Stabilitas mengungkapkan kemungkinan bahwa persyaratan perubahan, sedangkan pentingnya menentukan seberapa penting kebutuhannya adalah untuk keberhasilan proyek (dari valuebased dan sudut pandang pengguna). Verifiability (IEEE, product view) Semua persyaratan harus diverifikasi. Artinya, ada sebuah proses untuk sebuah mesin atau manusia untuk memeriksa (dalam cara yang hemat biaya) apakah persyaratan terpenuhi atau tidak. Modifiable (IEEE, product Semua persyaratan harus dimodifikasi, yaitu struktur persyaratan dan spesifikasi kebutuhan memungkinkan integrasi perubahan yang mudah, konsisten dan secara lengkap.

Quality Attribute Definition Traceable (IEEE, manufacturing view) Semua persyaratan harus dilacak, yaitu, itu harus mungkin untuk referensi kebutuhan dengan cara yang mudah. Selain itu, adalah mungkin untuk mengidentifikasi asal syarat (lihat juga Bab. 4) Comprehensibility (New, manufacturing, user, value-based view) Persyaratan yang ditentukan dan diungkapkan dengan cara yang dipahami oleh semua pemangku epentingan yang terlibat. Feasibility (New, valuebased, product view) Semua persyaratan dapat diimplementasikan dengan teknologi yang tersedia, sumber daya manusia dan anggaran. Selain itu, semua persyaratan kontribusi bagi keberhasilan moneter dari sistem, yaitu, mereka layak untuk dimasukkan ke dalam sistem. Right Level of Detail (New, user, manufacturing, value-based view) Informasi yang diberikan dalam persyaratan ini cocok untuk mendapatkan pemahaman yang benar tentang sistem dan memulai pelaksanaan. Tidak ada yang tidak perlu implementasi atau desain detail ditentukan dalam persyaratan.

The IEEE Standard diperpanjang untuk memberikan cara yang lebih lengkap menjelaskan kualitas persyaratan: Comprehensibility sangat penting, karena ada banyak pihak yang terlibat dalam proses rekayasa persyaratan. Adalah penting bahwa persyaratan dapat dengan mudah dipahami oleh semua pemangku kepentingan ini dan bahwa mereka semua memiliki pemahaman umum dari persyaratan. Feasibility sangat penting untuk dipertimbangkan sebagai syarat dan hanya dari nilai jika dapat ditransformasikan ke dalam desain dan implementasi dengan upaya yang wajar dan biaya. Finally, persyaratan harus ditentukan pada tingkat yang memadai detail, yaitu, cukup konkret untuk memungkinkan bahwa desain dan implementasi dapat dimulai, tapi itu di sisi lain cukup abstrak untuk memungkinkan pembicaraan antara semua melibatkan pemangku kepentingan (yang dalam banyak kasus teknis dan non-teknis latar belakang).