SOFTWARE VERIFICATION AND VALIDATION Software Quality Materi 3

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

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 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 11/09/2021 7

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 ◦Causal Analysis 11/09/2021 8

Perbedaan Verifikasi Dan Validasi Requirements Phase • System Reqts Analysis • S/W Reqts Analysis • Interface Analysis • Process Analysis • Technical Reviews & Audits Design Phase • Design Analysis • Interface Analysis • Test Program Analysis • Supportability Analysis • Process Analysis • Technical Reviews & Audits Code Phase • Code Analysis • Test Program Analysis • Supportability Analysis • Process Analysis • Technical Reviews & Audits Verify Test Phase • Test Program Analysis • Independent Test • Supportability Analysis • Technical Reviews & Audits Verify Validate Verify 11/09/2021 10

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 untuk tiap perangkat lunak. Perangkat lunak yang menyangkut keselamatan manusia, misalnya aoutopilot, harus memiliki standar yang lebih tinggi dibanding perangkat lunak biasa 11/09/2021 11

Aktivitas yang dilakukan pada proses validasi Pada proses validasi, terdapat tiga aktivitas dilakukan � 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 11/09/2021 12

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 11/09/2021 13

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 11/09/2021 14

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. 11/09/2021 15

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 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 dituliskan dahulu. � Acceptance testing agak mirip dengan validation testing, hanya saja pada acceptance testing, pengguna dilibatkan. 11/09/2021 16

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 11/09/2021 17

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

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 11/09/2021 19

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? 11/09/2021 20

Aktivitas yang dilakukan pada proses validasi ~ Pengukuran (2) � Untuk menjawab 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 11/09/2021 21

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? 11/09/2021 22

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. 11/09/2021 23

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 11/09/2021 24

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 (person-hours/test) Estimated Test Execution Time: 247. 5 (person-hours) Estimated Regression Testing (50%): 123. 75 (person-hours) Total Estimated Test Execution Time: 371. 25 (person-hours) 11/09/2021 25

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? 11/09/2021 26

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% 11/09/2021 27

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. 11/09/2021 28

Aktivitas yang dilakukan pada proses validasi ~ Pengukuran (10) 11/09/2021 29

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 11/09/2021 30

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 11/09/2021 31

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? 11/09/2021 32

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 ? 11/09/2021 33

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 tergantung tujuan perangkat lunak. Misalnya untuk perangkat lunak yang berhubungan dengan keselamatan manusia thresholdnya harus lebih tinggi 11/09/2021 34

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 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 11/09/2021 35

Aktivitas yang dilakukan pada proses validasi ~ Software reliability growth(5) Beberapa istilah yang berkaitan dengan reliability growth 11/09/2021 36

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 � 11/09/2021 37

Aktivitas yang dilakukan pada proses validasi ~ Software reliability growth modelling (7) Beberapa teknik software reliability growth modelling 11/09/2021 38

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 11/09/2021 39

Waktu pelaksanaan validasi ~ di akhir SDLC (2) � Grafik hubungan antara waktu perbaikan defect dengan biaya yang harus dikeluarkan 11/09/2021 40

To Be Continued … ANY QUESTIONS ?