Verification and Validation l Untuk menjamin bahwa software

Verification and Validation l Untuk menjamin bahwa software yang dibangun sesuai dengan kebutuhan user ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 1

Verification vs validation l Verification: “Apakah kita membangun produk dengan benar" • l PL Harus seusia dengan spesifikasinya Validation: “Apakah kita membangun produk yang benar” • PL harus sesuai dengan harapan klien ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 2

Static and dynamic verification l Software inspections (inspeksi PL). • l Menganalisa dan memeriksa representasi sistem spt dokumen persyaratan, diagram rancangan dan kode sumber program (static verification) tidak menuntut program dieksekusi Software testing (pengujian PL) • • Melibatkan eksekusi implementasi PL dgn data uji, memeriksa output dan prilaku kerja (dynamic verification) Menggunakan data uji memeriksa PL apakah berlaku seperti yang dibutuhkan ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 3

Static dan dynamic V&V Inspeksi PL (SV) Spesifikasi s persyaratan Peranc. tk. tinggi Spesifikasi formal Perancangan rinci Program Pengujian prog (DV) Prototipe SV dapat digunakan pada semua tahap proses PL, sementara DV hanya bisa dilakukan jika ada program atau prototype ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 4

The V & V process l l l Adalah sebuah proses siklus hidup penuh V & V harus ada di setiap tahap proses pengembangan PL. Tujuan : Menemukan cacat dalam sistem ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 5

Static Verification l l l Hanya dapat memeriksa hubungan antar program & spesifikasinya tanpa dpt menunjukkan bahwa PL bermanfaat secara operasional Sebuah testing yg baik/sukses adalah yg mampu menemukan satu atau lebih error Tidak dapat memeriksa karakterstik non fungsional PL spt kinerja & keandalannya ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 6

Pengujian PL l l Masih mendominasi Menggunakan data riil Sebuah testing yg baik/sukses adalah yg mampu menemukan satu atau lebih error Kekurangan & ketidaksesuaian disimpulkan dengan melihat output ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 7

Type pengujian l Defect testing (pengujian cacat) • Untuk mengungkapkan adanya cacat pada sistem, bukan untuk simulasi penggunaan. • Uji cacat yg sukses adalah uji yg menyebabkan sistem berlaku tidak benar shg mengungkapkan adanya cacat pd PL. • Menunjukkan keberadaan kesalahan, bukan tidak adanya kesalahan program • Menemukan ke-tidakkonsisten-an antara program dengan spesifikasinya l Statistical testing • Uji dirancang untuk menunjukkan input user yg sebenarnya dan frekuensinya. • Untuk menguji kinerja dan keandalan program dan memeriksa bagaimana kerjanya pd kondisi operasional ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 8

Tujuan akhir V& V l l Menanamkan kepercayaan bahwa sistem PL “siap untuk tujuannya” Tidak berarti bahwa program harus benar-benar bebas dari cacat Melainkan : Ini berarti bahwa sistem harus cukup baik untuk tujuannya. Tingkat kepercayaan bergantung pada tujuan sistem, harapan user dan lingkungan pemasaran sistem pd saat itu ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 9

V & V confidence (Tingkat Kepecayaan V & V) l Tergantung pada tujuan sistem, harapan user dan lingkungan pemasaran pada saat itu • Software function » Bergantung pada seberapa kritis PL tsb bagi organisasi • User expectations » Banyak User memiliki harapan yang rendah dari PL mrk & tidak terkejut saat PL tsb gagal saat dipakai • Marketing environment » Melemparkan produk ke pasaran lebih penting dari pada menemukan kesalahan terlebih dahulu ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 10

Testing dan debugging l l Pengujian (V&V) dan debuging adalah sebuah proses yang berbeda (terpisah) V &V adalah proses yg meyakinkan adanya cacat pada sistem PL Debugging adalah proses untuk menemukan dan membetulkan adanya cacat ini Debugging termasuk mencari pola output uji tentang prilaku sistem dan selanjutnya menguji pola ini untuk menemukan kesalahan sistem ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 11

Proses Debug Hasil Test Temukan lokasi error ©Ian Sommerville 2000 Specification Rancang perbaikan Kasus uji Perbaiki error Software Engineering, 6 th edition. Chapter 19 Uji ulang program Slide 12

Perencanaan V & V l l Diperlukan perrencanaan yang hati-hati utk mendapatkan keuntungan maksimum dari kegiatan inspeksi dan pengujian PL Perencanaan V & V harus dimulai dari awal proses pengembangan Perencanaan harus memutuskan keseimbangan antara verifikasi statis dan verifikasi dinamis Test planning berhubungan dengan penentuan standar untuk proses pengujian dan bukan mendeskripsikan uji produk ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 13

The V-model of development Specifikasi persyaratan Spesifikasi sistem cccc c Rencana uji c penerimaan Layanan Rencana uji integrasi sistem Uji Penerimaan ©Ian Sommerville 2000 Perancangan sistem Uji integrasi sistem Perancangan rinci Rencana uji integrasi sub sistem Kode dan pengujian modul dan unit Uji integrasi sub sistem Software Engineering, 6 th edition. Chapter 19 Slide 14

Struktur Rencana Uji Perangkat Lunak l l l l Proses pengujian deskripsi tahap utama proses pengujian Kemamputelusuran persyaratan user paling tertarik dgn apakah sistem memenuhi pesyaratan Item yang di uji hrs dispesifikasi Jadwal Pengujian sehub dgn jadwal pengembangan secara umum Prosedur Pencatatan Ujian sistematis Persyaratan PL & PK sesuai kebutuhan Batasan sdm/staf ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 15

Software inspections (inspeksi PL) l l Pengujian program yg sistematis membutuhkan sejumlah besar uji yg akan dikembangkan, dieksekusi dan diperiksa. Tidak menuntut program dieksekusi. Shg dapat digunakan sbg teknik verifikasi sebelum implementasi Dapat diterapkan disetiap tahapan (requirements, design, test data, dll. ) Teknik yg efektif utk mendeteksi error ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 16

Mengapa inspeksi lebih efektif dibanding pengujian l l Banyak cacat yg berbeda dapat dideteksi pada satu sesi inspeksi. Satu cacat dapat menyebabkan program crash atau mempengaruhi gejala cacat program lain Adanya pemakaian ulang domain dan pengetahuan bhs pemrograman. Intinya para peninjau mungkin telah melihat jenis eror yg umum terjadi pada suatu bhs pemrograman terentu dan pada jenis aplikasi tertentu. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 17

Inspeksi dan Pengujian l l l Inspections dan pengujian saling melengkapi, tidak berarti inspeksi harus sepenuhnya menggantikan pengujian sistem Inspeksi sebagai proses verifikasi awal untuk menemukan sebagian besar cacat program Inspeksi dan pengujian tetap harus digunakan selama proses V & V Inspections dapat memeriksa kesesuaian dengan spesifikasi, tetapi tidak dapat memvalidasi prilaku dinamik(apakah peralatan PL telah sesuai dengan keinginan user) Inspections tidak dapat mencek karakteristik non fungsional seperti performance, usability dll ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 18

Inspeksi Program l l l Proses formal yg dilakukan oleh tim kecil Fokus pada deteksi kesalahan bukan koreksi Cacat dapat berupa logical errors, penyimpangan kode yg menunjukkan adanya kondisi eror (cth, variabel yg tidak terinisialisasi) atau ketidaksesuaian dengan standard organisasi atau proyek ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 19

Inspection pre-conditions Sebelum inspeksi program dimulai, adalah penting bahwa: l Ada spesifikasi yg pasti mengenai kode yg akan diperiksa l Anggota team inspeksi mengenal baik standard organisasi l Tersedia versi kode yg up to date dan benar secara sintak tidak ada gunanya memeriksa kode yg “hampir lengkap” l Daftar error yg umum harus dipersiapkan l Manajemen harus menerima kenyataan bahwa proses inspeksi akan menimbulkan peningkatan biaya dalam pembangunan PL l Manajemen tidak boleh menggunakan proses inspeksi untuk penilaian staf ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 20

Proses Inspeksi Perencanaan Tinjauan Persiapan i individu ©Ian Sommerville 2000 Rapat pemeriksaan Pengerjaan ulang Software Engineering, 6 th edition. Chapter 19 Tindak lanjut Slide 21

Prosedur Inspeksi l l l Program yg akan diinspeksi diserahkan kpd team inspeksi Kode dan dokumen terkait didistribusikan dlm tahap peninjauan saat mendeskripsikan apa yg menjadi tujuan program Harus berlangsung relatif singkat (tidak lebih dari 2 jam) Tim tidak boleh menyarankan bgm cacat harus diperbaiki Setelah inspeksi, program diubah oleh pembuatnya utk membetulkan masalah yg ditemukan Inspeksi ulang tidak mutlak harus dilakukan ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 22

Team Inspeksi l l l Tim paling sedikit terdiri dari 4 orang Pembuat program adalah org yg bertanggung jawab menghasilkan program yg akan di inspeksi Inspector adalah orang yg menemukan error, hal-hal yg tidak terdeteksi dan ketidak konsistenan pd program Reader (pembaca) adalah oarng yg menguraikan program dgn kata-katanya sendiri dlm rapat inspeksi Moderator adalah org yg menangani proses & memfasilitasi inspeksi ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 23

Inspection checklists (daftar error) l l l Untuk memandu kegiatan inspeksi Tergantung bahasa pemrograman yang digunakan Contoh : inisialisasi, penamaan constanta, Examples: Initialisation, Constant naming, loop termination, dll. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 24

Inspection che

Pengukuran Proses Inspeksi l l 500 statement/jam selama peninjauan 125 source statement/jam saat persiapan individu 90 -125 statements/jam saat rapat Sehingga Inspeksi adalah proses yang sangat mahal ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 26

Analisa statis terotomasi l l l Sebuah alat bantu perangkat lunak yang mamfu menscan teks sumber program Dengan melakukan parsing teks dan selanjutnya mampu mendeteksi kesalahan pada setiap statement. Sangat efektif, namun bukan sebagai untuk pengganti kegiatan inspeksi. cth : dpt mengidentifikasi var yg tidak diinisialisasi, tapi tidak dapat mengidentifikasi inisialisasi yang tidak benar. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 27

Static analysis checks ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 28

Tahapan dalam analisis statik l l l Analisis aliran kontrol. Menandai loopyang memiliki banyak titik masuk dan titik keluar, dan menemukan kode 2 yang tidak bisa dicapai (dikelilingi oleh statement goto), dll. Analisis penggunaan data. Mendeteksi var yg digunakan tanpa inisialisasi sebelumnya, variabel yang ditulis dua kali tanpa penentuan nilai diantaranya dan variabel yang dideklarasikan tapi tidak pernah dipakai, dll. Analisis interface. Memeriksa konsistensi deklarasi prosedur dan penggunaannya, atau utk fungsi dan procedure yg dideklarasikan tetapi tidak pernah dipanggil atau digunakan tidak utk java (strongly typed), tetapi utk fortran dan C (weakly typed) ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 29

l l Analisa aliran informasi. Mengidentifikasi ketergantungan antara var input dengan var output. Analisis jalur. Mengidentifikasi semua jalur yang mungkin melalui program ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 30

138% more lint_ex. c #include <stdio. h> printarray (Anarray) int Anarray; { printf(“%d”, Anarray); } main () { int Anarray[5]; int i; char c; printarray (Anarray, i, c); printarray (Anarray) ; } 139% cc lint_ex. c 140% lint_ex. c(10): warning: c may be used before set lint_ex. c(10): warning: i may be used before set printarray: variable # of args. lint_ex. c(4) : : lint_ex. c(10) printarray, arg. 1 used inconsistently lint_ex. c(4) : : lint_ex. c(11) printf returns value which is always ignored LINT static analysis Unix dan Linux utk C

Manfaat analisis statis l l Pada bhs pemrog yg weakly typed seperti C, dapat mendeteksi fungsi yang memiliki jumlah dan jenis argumen yang salah atau error jenis lain yang tidak terdeteksi oleh compiler Tidak efekti dari segi biaya utk bhs Java, karena Java termasuk strongly typed, dimana perancang telah membuang beberapa fitur yang rentan terhadap error, semua var hrs diinisialisasikan dan tidak ada statement goto ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 32

Pengembangan PL Cleanroom l l Istilah Cleanroom berasal dari unit pabrikasi semiknduktor. Pd unit ini (cleanroom) cacat dihindari dgn pemabrikan pada atmosfir yang ultra-bersih Merupakan filosofi pengembangan PL utk menghindari cacat PL dengan pengembangan proses inspeksi yg sangat teliti Cleanroom telah menggantikan pengujian unit komponen sistem dengan inspeksi untuk memeriksa konsistensi komponen dgn spesifikasinya ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 33

l Karakteristik kunci pengembangan PL dgn model cleanroom : • • Spesifikasi formal Pengembangan inkremental » PL dibagi menjadi inkremen (bagian) dan divalidasi secara terpisah dgn metode cleanroom. • • • Pemrograman terstruktur Verifikasi statis. Pengujian statistik sistemf ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 34

The Cleanroom process ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 35

Cleanroom process characteristics l l l Formal specification using a state transition model Incremental development Structured programming - limited control and abstraction constructs are used Static verification using rigorous inspections Statistical testing of the system (covered in Ch. 21). ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 36

Incremental development ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 37

Formal specification and inspections l l l The state based model is a system specification and the inspection process checks the program against this model Programming approach is defined so that the correspondence between the model and the system is clear Mathematical arguments (not proofs) are used to increase confidence in the inspection process ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 38

Cleanroom process teams l l l Specification team. Responsible for developing and maintaining the system specification Development team. Responsible for developing and verifying the software. The software is NOT executed or even compiled during this process Certification team. Responsible for developing a set of statistical tests to exercise the software after development. Reliability growth models used to determine when reliability is acceptable ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 39

Cleanroom process evaluation l l Results in IBM have been very impressive with few discovered faults in delivered systems Independent assessment shows that the process is no more expensive than other approaches Fewer errors than in a 'traditional' development process Not clear how this approach can be transferred to an environment with less skilled or less highly motivated engineers ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 40

Key points l l l Verification and validation are not the same thing. Verification shows conformance with specification; validation shows that the program meets the customer’s needs Test plans should be drawn up to guide the testing process. Static verification techniques involve examination and analysis of the program for error detection ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 41

Key points l l Program inspections are very effective in discovering errors Program code in inspections is checked by a small team to locate software faults Static analysis tools can discover program anomalies which may be an indication of faults in the code The Cleanroom development process depends on incremental development, static verification and statistical testing ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 19 Slide 42