Verification and Validation Untuk menjamin bahwa software yang dibangun sesuai dengan kebutuhan user

Verification vs validation Verification: “Apakah kita membangun produk dengan benar" PL Harus seusia dengan spesifikasinya Validation: “Apakah kita membangun produk yang benar” PL harus sesuai dengan harapan klien

Static and dynamic verification Software inspections (inspeksi PL). 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

Static dan dynamic V&V Spesifikasi formal Peranc. tk. tinggi s Spesifikasi persyaratan Perancangan rinci Program Prototipe Pengujian prog (DV) Inspeksi PL (SV) SV dapat digunakan pada semua tahap proses PL, sementara DV hanya bisa dilakukan jika ada program atau prototype

The V & V process Adalah sebuah proses siklus hidup penuh V & V harus ada di setiap tahap proses pengembangan PL. Tujuan : Menemukan cacat dalam sistem

Static Verification 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

Pengujian PL Masih mendominasi Menggunakan data riil Sebuah testing yg baik/sukses adalah yg mampu menemukan satu atau lebih error Kekurangan & ketidaksesuaian disimpulkan dengan melihat output

Type pengujian Defect testing (pengujian cacat) Statistical testing 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 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

Tujuan akhir V& V 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

V & V confidence (Tingkat Kepecayaan V & V) 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

Testing dan debugging 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

Proses Debug Temukan lokasi e r o Rancang perbaikan Perbaiki Uji ulang Hasil Test S c i f t n Kasus uji

Perencanaan V & V 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

The V-model of development Specifikasi persyaratan Spesifikasi sistem Perancangan rinci Kode dan pengujian modul dan unit Rencana uji integrasi sub sistem integrasi sistem ccccc penerimaan c Layanan Uji Penerimaan Uji integrasi

Struktur Rencana Uji Perangkat Lunak 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

Software inspections (inspeksi PL) 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

Mengapa inspeksi lebih efektif dibanding pengujian 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.

Inspeksi dan Pengujian 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

Inspeksi Program 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

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

Proses Inspeksi Rapat pemeriksaan Persiapan individu i Tinjauan Perencanaan Pengerjaan ulang Tindak lanjut

Prosedur Inspeksi 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

Team Inspeksi 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

Inspection checklists (daftar error) Untuk memandu kegiatan inspeksi Tergantung bahasa pemrograman yang digunakan Contoh : inisialisasi, penamaan constanta, Examples: Initialisation, Constant naming, loop termination, dll.

Inspection checks

Pengukuran Proses Inspeksi 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

Analisa statis terotomasi 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.

Static analysis checks

Tahapan dalam analisis statik Analisis aliran kontrol. Menandai loopyang memiliki banyak titik masuk dan titik keluar, dan menemukan kode2 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)

Analisa aliran informasi Analisa aliran informasi. Mengidentifikasi ketergantungan antara var input dengan var output. Analisis jalur. Mengidentifikasi semua jalur yang mungkin melalui program

LINT static analysis  Unix dan Linux utk C 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 lint_ex.c 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(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 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

Pengembangan PL Cleanroom 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

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

The Cleanroom process

Cleanroom process characteristics 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).

Incremental development

Formal specification and inspections 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

Cleanroom process teams 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

Cleanroom process evaluation 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

Key points 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

Key points 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