SOFTWARE VERIFICATION AND VALIDATION Software Quality Materi 3 Eko Prasetyo Teknik Informatika Univ. Pembangunan Nasional Veteran Jawa Timur 2011

Verifikasi dan Validasi Software verification and validation adalah aktivitas pemeriksaan software yang dihadapkan dengan spesifikasinya. Setiap proyek harus men-verifikasi dan validasi produk softwarenya. Hal ini dilakukan dengan: Pemeriksaan bahwa setiap item software memenuhi kebutuhan yang ditetapkan. Pemeriksaan setiap item software sebelum dia digunakan sebagai input pada aktivitas yang lain. Meyakinkan bahwa setiap item software sudah selesai, jika memungkinkan, dilakukan oleh orang lain selain author. Meyakinkan bahwa sejumlah usaha verifikasi dan validasi cukup untuk menunjukkan setiap item software cocok dengan operasi penggunaan. Manajemen proyek bertanggung jawab untuk mengorganisasikan aktivitas verifikasi dan validasi software, definisi peran verifikasi dan validasi, dan alokasi staf pada peran tersebut.

Verifikasi dan Validasi Berapapun ukuran proyek, verifikasi dan validasi software berpengaruh besar pada kualitas software. Masyarakat yakin bahwa software yang tidak diverifikasi mempunyai kesempatan kerja yang sedikit. Umumnya, 20 – 50 error per 1000 lines of code ditemukan selama pengembangan, dan 1.5 – 4 per 1000 lines of code yang tersisa setelah pengujian sistem. Tujuan verifikasi dan validasi adalah untuk mengurangi error software untuk mencapai level yang dapat diterima. Usahanya berkisar 30% - 90% dari total sumber daya proyek, tergantung kekritisan dan kompleksitas software.

PRINCIPLES OF SOFTWARE VERIFICATION AND VALIDATION Verifikasi dapat berarti: Tindakan peninjauan (reviewing), pemeriksaan (inspecting), pengujian (testing), auditing, atau lainnya yang memunculkan dan mendokumentasikan apakah item, proses, service, atau dokumen sesuai dengan kebutuhan (requirements) yang ditetapkan. Proses evaluasi sistem atau komponen untuk menentukan apakah hasil dari fase pengembangan yang diberikan memenuhi kondisi yang ditetapkan diawal fase. Bukti formal kebenaran (correctness) program. Validasi (menurut ANSI/IEEE) adalah “proses evaluasi sistem atau komponen selama atau diakhir proses pengembangan untuk menentukan apakah memenuhi kebutuhan (requirements) yang ditetapkan” Validasi, oleh karena itu, adalah verifikasi “end-to-end”

Mengapa dilakukan Verifikasi? Membangun pengembangan, dan tes dalam proses solusi dari requirement yang disetujui dan yang telah tercapai di setiap tahapan dalam desain. Verifikasi dilakukan untuk memastikan aktifitas verifikasi (review, inspeksi dan testing) telah direncanakan dan dilakukan dalam suatu cara, seperti memaksimalkan penemuan cacat, dengan memakai resource yang paling efisien dan efektif, dalam batasan cakupan project/kontrak.

Verifikasi Yang masuk aktivitas verifikasi: Technical reviews, walkthroughs and software inspections; Checking that software requirements are traceable to user requirements; Checking that design components are traceable to software requirements; Unit testing; Integration testing; System testing; Acceptance testing; Audit

Perbedaan Verifikasi Dan Validasi Pembahasan verifikasi dan validasi sering dijadikan satu, namun sebenarnya verifikasi dan validasi merupakan hal yang berbeda Verifikasi & Validasi merupakan hal yang berbeda (Boehm, 1984): Verifikasi: “Are we building the product right?” Verifikasi memeriksa apakah pengembang perangkat lunak membangun perangkat lunak dengan cara yang benar Validasi: “Are we building the right product?” Validasi memeriksa apakah perangkat lunak yang dibangun sesuai dengan kebutuhan pengguna yang dinyatakan dalam SRS 18/11/2018

Latar belakang Terdapat beberapa cara untuk meningkatkan kualitas perangkat lunak Cara 1 : Mencegah terjadinya defect perangkat lunak Process Improvement Complexity Reduction Risk Management Causal Analysis Cara 2 : Mendeteksi dan perbaikan defect Verification Validation Rework 18/11/2018

Perbedaan Verifikasi Dan Validasi Requirements Phase System Reqts Analysis S/W Reqts Analysis Interface Analysis Process Analysis Technical Reviews & Audits Design Phase Design Analysis Test Program Analysis Supportability Analysis Code Phase Code Analysis Test Phase Independent Test Verify Validate Phase-dependent tasks Planning analyses Software development, verification, reconfiguration plans Requirements analyses Command & data flow Interface Horizontal architectural requirements Phasing (staging/reconfiguration) Requirements validation Design analyses Critical algorithms Timing & sizing Code analyses Test analyses Plan, procedure, & report Unit, integration, interface, acceptance and system Phase-independent tasks Catastrophic/mission critical/high risk functions identification Traceability matrix Issue/Discrepancy tracking and reporting Analytic studies Loading Metrics Schedule 18/11/2018

Tujuan validasi Validasi bertujuan untuk memberikan keyakinan bahwa perangkat lunak dapat memenuhi kebutuhan penggunanya Hal ini tidak berarti bahwa perangkat lunak harus 100% bebas dari defect Namun, perangkat lunak harus “cukup” bagus untuk digunakan sesuai tujuannya. Makna “cukup” berbeda beda untuk tiap perangkat lunak. Perangkat lunak yang menyangkut keselamatan manusia, misalnya aoutopilot, harus memiliki standar yang lebih tinggi dibanding perangkat lunak biasa 18/11/2018

Aktivitas yang dilakukan pada proses validasi Pada proses validasi, terdapat tiga aktivitas dilakukan Testing Testing merupakan kegiatan utama validasi yang dilakukan untuk mengetahui apakah perangkat lunak telah memenuhi SRS Pengukuran Diperlukan pengukuran menggunakan metrik tertentu untuk menilai efektifitas proses validasi dan penanganan tingkat defect yang ditemukan Software reliability growth modelling Bertujuan untuk mengetahui kapan proses validasi dihentikan 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Testing Testing diperlukan pada proses validasi untuk menguji apakah perangkat lunak telah memenuhi SRS Untuk melakukan testing yang baik, perlu diketahui hirarki testing, pembagian testing pada tiap hirarki, cara mengkombinasikan testing dari tiap hirarki testing dan kombinasi testing seperti apa yang sesuai untuk kasus tertentu Di sini tidak dibahas secara mendetail tentang testing. Hanya bagian testing yang berkaitan dengan validasi dibahas secara lebih mendalam 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Testing (2) Pembagian testing dapat dilakukan secara hirarki. Tiap hirarki terdiri atas level – level, metode – metode dan tipe – tipe testing 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Testing (3) Pembagian testing pada hirarki level adalah sebagai berikut Unit / module testing Integration testing Validation / system testing Validation testing bertujuan untuk menentukan apakah perangkat lunak telah memenuhi requirementnya sesuai dengan dokumen SRS. Setelah dilakukan validation testing, jika ditemukan defect, dilakukan proses untuk memperbaiki perangkat lunak untuk menghilangkan defect. Perbaikan tersebut mungkin akan menyebabkan bagian lain dari perangkat lunak tidak bekerja dengan baik. Oleh karena itu, perlu dilakukan regression testing. 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Testing (4) Regression testing Validation testing yang dilakukan pada bagian tertentu secara selektif perangkat lunak untuk meyakinkan bahwa perbaikan sebuah defect tidak mengakibatkan defect pada bagian yang lain. Alpha dan beta testing Alpha dan beta testing merupakan testing yang melibatkan pengguna perangkat lunak untuk mencoba perangkat lunak yang akan dirilis. Agar alpha dan beta testing berjalan dengan efisien, maka sebelum dilakukan alpha dan beta testing direncanakan dan dituliskan dahulu. Acceptance testing Acceptance testing agak mirip dengan validation testing, hanya saja pada acceptance testing, pengguna dilibatkan. 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Testing (5) Pembagian testing pada hirarki metode White box atau glass box testing Functional atau black box testing Proses testing dimana struktur internal perangkat lunak (kode program) tidak dites, namun digunakan untuk membuat skenario tes Top down dan bottom up Act like customer testing (ALAC) Pada perangkat lunak yang kompleks terdapat banyak defect. Namun pengguna biasanya hanya menemukan sebagian kecil dari defect tersebut. Untuk efisiensi dan prioritas, maka proses testing difokuskan pada usaha menemukan defect yang kemungkinan ditemukan oleh pengguna perangkat lunak 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Testing (6) ALAC testing 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Testing (7) Testing truth “Testing cannot show the absence of software errors; it can only show that software errors are present!” Jika pada proses testing tidak lagi ditemukan defect, tidak dapat disimpulkan bahwa perangkat lunak telah benar – benar bebas defect Pada saat proses validasi, kita harus mengetahui kapan harus berhenti melakukan testing 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Pengukuran Perlu dilakukan penilaian dan pengukuran pada proses validasi untuk menilai apakah proses validasi telah berjalan dengan efektif Penilaian efektifitas proses validasi dilakukan dengan menjawab pertanyaan berikut Berapa banyak waktu yang dibutuhkan untuk menemukan defect? Apakah defect yang ditemukan berhasil diperbaiki Berapa banyak waktu yang dikeluarkan untuk melakukan testing? Berapa banyak code yang diperiksa? Apakah semua fitur perangkat lunak telah diuji? Berapa persen defect yang telah diperbaiki pada saat perangkat lunak dirilis Seberapa baikkah tes ALAC dilakukan? 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Pengukuran (2) Untuk menjawab pertanyaan pertanyaan di atas maka aspek – aspek proses validasi harus diukur dan dinyatakan dengan angka Proses pengukuran tersebut membutuhkan adanya metrik Terdapat beberapa metrik yang digunakan untuk mengukur efektifitas proses validasi 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Pengukuran (3) Beberapa metrik yang digunakan untuk mengukur efektifitas proses validasi Metrik yang berhubungan dengan waktu Metrik yang berhubungan cakupan testing Berapa persen bagian dari perangkat lunak yang divalidasi? Metrik yang berhubungan kualitas berapa banyak defect yang ditemukan? Berapa persen yang berhasil diperbaiki? 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Pengukuran (4) Metrik yang berhubungan dengan waktu find-fix cycle time Berapa banyak waktu yang dibutuhkan untuk menemukan defect, memperbaiki defect tersebut dan memverifikasi apakah defect telah diperbaiki. Satuan dari metrik ini adalah person-hours / defect Cumulative test time mengukur waktu testing kumulatif untuk semua aktivitas validation testing. Satuan dari metric ini adalah test hours. 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Pengukuran (5) SRS Reference Estimated Number of Tests Required Notes 4.1.1 3 2 positive and 1 negative test 4.1.2 2 2 automated tests 4.1.3 4 4 manual tests 4.1.4 5 1 boundary condition, 2 error conditions, 2 usability tests … Total 165 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Pengukuran (6) Estimated Number of Tests: 165 Average Test Development Time: 3.5 (person-hours/test) Estimated Test Development Time: 577.5 (person-hours) Estimated Number of Tests: 165 Average Test Execution Time: 1.5 Estimated Test Execution Time: 247.5 Estimated Regression Testing (50%): 123.75 Total Estimated Test Execution Time: 371.25 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Pengukuran (7) Metric yang berhubungan dengan cakupan testing terbagi atas Code coverage Berapa banyak kode program yang telah dites? Code coverage dibagi menjadi dua metrik, yaitu segment coverage dan call-pair coverage Requirement coverage Apakah seluruh fitur dari perangkat lunak telah ditesting? 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Pengukuran (8) Segment coverage Dihitung dengan menghitung berapa persen edge dari flow graph source code yang ditesting Secara umum, Segment coverage minimum bernilai 85% 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Pengukuran (9) Call pairs adalah interface dari modul di mana sebuah modul memanggil modul lain. Call pairs berguna terutama pada integration testing untuk meyakinkan bahwa semua interface modul telah ditesting. Nilai call pairs yang harus ditesting biasanya bernilai 100%. Requirement coverage metric menjawab pertanyaan “apakah seluruh fitur dari perangkat lunak telah ditesting?”. Requirement traceability matrix digunakan untuk menelusuri apakah testing telah memeriksa semua aspek SRS. Satuan dari requirenment coverage metric adalah persentase dari requirement yang telah ditesting. Metric ini berfungsi untuk meyakinkan apakah semua requirement pada SRS telah ditesting. 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Pengukuran (10) 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Pengukuran (11) Metrik yang berhubungan dengan kualitas terdiri atas Defect removal percentage Metric ini menghitung persentase defect yang telah dibuang (diperbaiki) dibandingkan dengan banyaknya defect yang ditemukan. Untuk menghitung defect removal percentage digunakan persamaan 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Pengukuran (12) Defect detection efficiency Metric ini menjawab pertanyaan “sebaik apakah dilakukan ALAC testing? ”. metric ini mengukur seberapa berhasilkan kita menemukan defect yang kemungkinan akan ditemukan oleh pengguna perangkat lunak? Metric ini dihitung menggunakan persamaan 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Software reliability growth modelling Pada saat proses validasi dilakukan testing dan perbaikan perangkat lunak jika ditemukan defect Proses tersebut dilakukan berulang kali sehingga perangkat lunak makin reliable (reliability growth) Karena kita tidak dapat mengetahui apakah masih ada defect yang tertinggal (testing truth), muncul pertanyaan Sampai kapankah kita melakukan testing? Sampai sereliable apakah perangkat lunak harus dibuat? apakah saat ini perangkat lunak telah siap dirilis? Jika belum, berapa banyak lagi usaha validasi (testing) yang harus dilakukan sampai perangkat lunak layak rilis? Kapan perangkat lunak dapat dirilis? 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Software reliability growth modelling(2) Pemodelan software reliability growth menunjukkan bahwa seiring dengan validasi, maka reliabilty dari perangkat lunak bertambah. Pada gambar ditunjukkan bahwa intensitas kegagalan menurun. Sampai batas apakah reliabilitas yang harus dicapai ? 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Software reliability growth modelling (3) Untuk menjawab pertanyaan tersebut dilakukanlah pemodelan reliability growth Pemodelan ini mengkuantisasi reliabilitas dari perangkat lunak Jika nilai reliabilitynya mencapai threshold tertentu, maka dianggap bahwa software telah layak dirilis Threshold untuk tiap perangkat lunak berbeda beda tergantung tujuan perangkat lunak. Misalnya untuk perangkat lunak yang berhubungan dengan keselamatan manusia thresholdnya harus lebih tinggi 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Software reliability growth modelling (4) Software growth modelling berhubungan dengan waktu peluncuran produk perangkat lunak. Beberapa pertimbangan tentang waktu peluncuran produk Fungsi perangkat lunak perangkat lunak yang menjalankan fungsi yang kritis harus divalidasi lebih ketat User expectations Tidak perlu melakukan validasi yang sangat ketat untuk perangkat lunak yang memiliki ekspektasi rendah dari penggunanya Lingkungan marketing perangkat lunak Meluncurkan perangkat lunak sedini mungkin kadang lebih penting dari menemukan defect untuk merebut pasar 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Software reliability growth(5) Beberapa istilah yang berkaitan dengan reliability growth 18/11/2018

Manfaat dari software reliability growth modelling Aktivitas yang dilakukan pada proses validasi ~ Software reliability growth modelling (6) Manfaat dari software reliability growth modelling Menghitung reliabilitas perangkat lunak menggunakan MTTF Menentukan waktu optimal untuk menghentikan testing dan merilis perangkat lunak Menyediakan data untuk membuat tradeoff antara waktu testing, reliabilitas, biaya dan performa perangkat lunak Menyediakan tujuan reliabilitas perangkat lunak secara realistis 18/11/2018

Aktivitas yang dilakukan pada proses validasi ~ Software reliability growth modelling (7) Beberapa teknik software reliability growth modelling 18/11/2018

Waktu pelaksanaan validasi ~ di akhir SDLC Proses validasi dapat dilakukan pada akhir SDLC. Kekurangan : Perangkat lunak yang dihasilkan memiliki banyak defect Biaya untuk memperbaiki defect perangkat lunak jika dilakukan pada tahap akhir SDLC menjadi sangat besar 18/11/2018

Waktu pelaksanaan validasi ~ di akhir SDLC (2) Grafik hubungan antara waktu perbaikan defect dengan biaya yang harus dikeluarkan 18/11/2018

To Be Continued … ANY QUESTIONS ?