Pengembangan Sistem



Software Development

Pengembangan Sistem Aplikasi Pendekatan Tradisional

Fase-fase dalam SDLC (3 fase)

ò Fase Definisi:

ò analisis kelayakan (feasibility analysis)

ò definisi kebutuhan (requirement definition)

ò Fase Kontruksi/Pengembangan:

ò desain sistem

ò membangun sistem

ò pengujian sistem

ò Fase Implementasi:

ò Instalasi

ò Operasional & Maintenans

Analysis Kelayakan

ò Yang dianalisis:

ò kemungkinan pengurangan biaya

ò keuntungan yang mungkin diraih

ò kesuksesan bisnis

ò estimasi waktu dan jadwal

ò kelayakan terhadap kemampuan teknis organisasi

ò dengan memperhatikan:

ò apa yang akan dikerjakan oleh sistem

ò output apa yang akan dihasilkan

ò bagaimana data input akan diperoleh

ò data yang akan diperlukan

ò kecepatan sistem tersebut untuk menghasilkan output

Definisi Kebutuhan (Requirement Analysis)

ò Inti pada tahapan ini adalah mendefinisikan kebutuhan, yaitu apa yang akan dilakukan oleh sistem, secara akurat dan lengkap

Rancangan Sistem (System Design)

Rancangan sistem melibatkan:

ò penentuan hardware dan software

ò perancangan isi dan struktur basis data

ò pendefinisian modul-modul proses (prosedure) yang menyusun sistem

ò penentuan bagaimana modul-modul tersebut saling berhubungan

Membangun dan Pengujian Sistem (Building & Testing Systems)

ò Aktifitas dalam membangun sistem:

ò membuat program komputer

ò rancangan rinci sistem basis data

ò konfigurasi hardware

ò software untuk sistem

ò Sistem Operasi

ò Database Management System

ò Bahasa pemrograman

ò membuat program komputer

ò rancangan rinci sistem basis data

ò konfigurasi hardware

ò software untuk sistem

ò Sistem Operasi

ò Database Management System

ò Bahasa pemrograman

ò Pengujian

ò setiap modul setiap kali dihasilkan

ò keseluruhan sistem jika sudah lengkap

ò Pengujian dilakukan untuk meyakinkan bahwa sistem akan bekerja dengan benar pada lingkungan user

Instalasi Sistem (Installing the System)

ò Salah satu aktifitas besar pada instalasi sistem adalah konversi data (data conversion)

ò yaitu membangun file dan basis-data dan mengisinya dengan data-data yang perlu untuk mengoperasikan sistem tsb

ò Sayangnya, data pada sistem yang lama mungkin: tidak akurat, tidak lengkap, atau tidak kompatibel

ò Dapat menimbulkan tugas yang bervolume tinggi dan juga mungkin sukar

ò terutama apabila harus terus melanjutkan sistem lama selama pengkonversian sistem baru

ò Bagian paling krusial dalam instalasi sistem adalah:

ò mentraining orang

ò memotivasi mrk untuk merubah pola kebiasaan dl menggunakannya dengan baik

ò Beberapa strategi konversi yang mungkin dapat dilakukan:

ò strategi paralel: jalan bersama untuk beberapa waktu

ò strategi pilot: menjalankan di beberapa bagian

ò strategi berfase: bertahap menerapkan

ò strategi Cold Turkey: langsung menghentikan total sistem lama

Operasional dan Maintenans

ò Setelah segala usaha dan waktu digunakan untuk proses pengembangan sistem, diharapkan sistem yang baru akan beroperasi dengan panjang dan bermanfaat

ò Maintenans merupakan proses modifikasi sistem untuk mengadaptasi perubahan kebutuhan organisasi

Pendekatan alternatif

• Pengembangan sistem menggunakan metodologi evolusi yang didasarkan pada prototyping

• Pembelian paket software

• pengembangan sistem bersumber diluar

[pic]

[pic]

[pic]

[pic]

Bahan 2

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 dg data uji, memeriksa output dan prilaku kerja (dynamic verification)

• Menggunakan data uji memeriksa PL apakah berlaku spt yg dibutuhkan

[pic]

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 karakteristik 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 & ketidak sesuaian disimpulkan dengan melihat output

Type pengujian

- 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 ketidak konsistenan 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

[pic]

Perencanaan V & V

• Diperlukan perencanaan 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

[pic]Struktur Rencana Uji Perangkat Lunak

• Proses pengujian( deskripsi tahap utama proses pengujian

• Kemampuan telusuran persyaratan( user paling tertarik dg apakah sistem memenuhi pesyaratan

• Item yang di uji( hrs dispesifikasi

• Jadwal Pengujian( sehub dg 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 dp 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/mempengaruhi gejala cacat program lain

• Adanya pemakaian ulang domain dan pengetahuan bhs pemrograman. Intinya para peninjau mungkin telah melihat jenis error yg umum terjadi pada suatu bhs pemrograman tertentu 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 error (cth, variabel yg tidak terinisialisasi) atau ketidak sesuaian dengan standar organisasi/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 standar 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

[pic]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 diinspeksi

• Inspector adalah orang yg menemukan error, hal-hal yg tidak terdeteksi dan ketidak konsistenan pd program

• Reader (pembaca) adalah org yg menguraikan program dg kata-katanya sendiri dl 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.

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 mampu 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: dp mengidentifikasi var yg tidak diinisialisasi, tapi tidak dapat mengidentifikasi inisialisasi yang tidak benar

[pic]

Tahapan dalam analisis statik

• Analisis aliran kontrol. Menandai loop yang memiliki banyak titik masuk dan titik keluar, dan menemukan kode-kode 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/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. Mengidentifikasi ketergantungan antara var input dengan var output.

• Analisis jalur. Mengidentifikasi semua jalur yang mungkin melalui program

[pic]

Manfaat analisis statis

• Pada bhs pemrograman yg weakly typed seperti C, dp mendeteksi fungsi yang memiliki jumlah dan jenis argumen yang salah atau error jenis lain yang tidak terdeteksi oleh compiler

• Tidak efektif dari segi biaya utk bhs Java, kr 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 semikonduktor.

• Pd unit ini (cleanroom) cacat dihindari dg pemabrikan pd atmosfir yg 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 dg spesifikasinya

- Karakteristik kunci pengembangan PL dgn model cleanroom:

• Spesifikasi formal

• Pengembangan inkremental

» PL dibagi menjadi inkremen (bagian) dan divalidasi secara terpisah dg metode cleanroom.

• Pemrograman terstruktur

• Verifikasi statis

• Pengujian statistik sistem

[pic]

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

[pic]

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

• 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

Bahan 4

Pengujian Cacat (Defect Testing)

Pengujian program untuk mengungkap adanya cacat pada sistem PL

Tujuan

• Untuk memahami sejumlah teknik pengujian yang digunakan untuk menemukan kesalahan program

• Mengetahui panduan yang mendukung pengujian interface komponen

• Memahami pendekatan spesifik bagi pengujian komponen dan pengujian integrasi untuk sistem berorientasi objek

• Memahami prinsip kerja pendukung alat bantu CASE untuk pengujian

Pembahasan

• Defect testing (Pengujian cacat)

• Integration testing (Pengujian integrasi)

• Object-oriented testing (Pengujian berbasis objek)

• Testing work-benches (meja kerja pengujian)

[pic]Pengujian Cacat

• Tujuannya adalah untuk mengungkap cacat pada program

• Pengujian yg berhasil adalah pengujian yang menyebabkan sistem berprilaku tidak benar shg dapat diungkapkan bahwa adanya cacat pada program tersebut

• Pengujian ini menunjukkan keberadaan bukan tidak adanya kesalahan program

• Berlawanan dengan pengujian validasi yang menuntut sistem berlaku benar

Testing priorities

• Only exhaustive testing can show a program is free from defects. However, exhaustive testing is impossible

• Tests should exercise a system's capabilities rather than its components

• Testing old capabilities is more important than testing new capabilities

• Testing typical situations is more important than boundary value cases

Test data and test cases

• Test data Inputs which have been devised to test the system

• Test cases Inputs to test the system and the predicted outputs from these inputs if the system operates according to its specification

[pic]Pengujian cacat terdiri dari:

• Black-box testing

• Partisi equivalensi

• Pengujian struktural

• Pengujian jalur

Black-box testing

• Pengujian berdasarkan pada spesifikasi sistem

• program dianggap sebagai sebuah ‘black-box’ yg prilakunya hanya dapat ditentukan dg mempelajari input dan output yg berkaitan

• Perencanaan uji dapat dilakukan di awal

• Disebut juga pengujian fungsionalitas (bukan implementasi PL)

[pic]Partisi Equivalensi

• Data Input dan hasil output biasanya masuk dalam sejumlah kelas yang berbeda namun memiliki karakteristik yang sama. Mis : bil positif, bil negatif, string tanpa blank, dll

• Program biasanya berlaku dengan cara yg dapat dibandingkan untuk semua anggota kelas

• Begitu satu himpunan partisi telah diidentifikasikan, kemudian dipilihlah kasus uji dari setiap partisi ini

[pic]

Partisi Equivalesi

- Identifikasikan Himpunan Partisi input dan output ke dalam sebuat bentuk equivalensi

• Mis: Spesifikasi program menyatakan bahwa program menerima 4-10 input yang 5 digit bilangan bulat antara 10.000 dan 99.999

Partisi equivalensinya adalah 99.999

- Pilih kasus uji pada batasan dari himpunan tersebut

• 00000, 09999, 10000, 99999, 10001

[pic]

[pic]

Partisi input - Search routine

• Input yg cocok dengan kondisi pra

• Input yg tidak cocok dengan kondisi pra

• Input yg key elemennya merupakan anggota array

• Input yg key elemennya bukan anggota array

Testing guidelines (sequences)

• Uji PL dengan deret yang hanya memiliki 1 nilai

• Gunakan deret yang berbeda dengan ukuran yang berbeda pada uji yang berbeda

• Turunkan uji sehingga elemen deret yang pertama, tengah dan terakhir diakses

[pic]Structural testing

• Disebut juga “white-box testing”

• Diturunkan dari pengetahuan struktur dan implementasi PL

• Biasa diterapkan utk unit program yg relatif kecil

• Penguji dpt menganalisis kode dan menggunakan pengetahuan mengenai struktur komponen utk menurunkan data uji

[pic]

[pic]Berdasarkan kode utk search rutin, binary search melibatkan pembagian ruang searching menjadi 3

• elemArray[mid]==key

• elemArray[mid]key

Selanjutnya pengujian dilakukan berdasarkan pengetahuan mengenai algorithma binary search

Binary search - equiv. partitions

• Pre-conditions satisfied, key element in array

• Pre-conditions satisfied, key element not in array

• Pre-conditions unsatisfied, key element in array

• Pre-conditions unsatisfied, key element not in array

• Input array has a single value

• Input array has an even number of values

• Input array has an odd number of values

[pic]

[pic]Pengujian Jalur

• Bertujuan untuk menguji setiap jalur eksekusi independent melalui komponen/program paling tidak 1 kali eksekusi

• Titik awal pengujian jalur merupakan graph alir yang terdiri dari node yg akan mewakili keputusan dan edge (tanda panah) yg menunjukkan aliran control

Graf alir program

• Menggambarkan aliran kontrol program.

• Setiap percabangan pada statement kondisional (if-then-else/case) ditunjukkan sebagai jalur yang terpisah

• Loop ditunjukkan dgn tanda panah yang kembali ke node kondisi loop

• Digunakan sebagai dasar perhitungan “the cyclomatic complexity” (CC)

• CC = Jumlah tanda panah – jumlah node +2

[pic]Independent paths

• 1, 2, 3, 8, 9

• 1, 2, 3, 4, 6, 7, 2

• 1, 2, 3, 4, 5, 7, 2

• 1, 2, 3, 4, 6, 7, 2, 8, 9

• Test cases should be derived so that all of these paths are executed

• A dynamic program analyser may be used to check that paths have been executed

Pengujian Integrasi

• Pengujian terhadap sistem yang telah lengkap (terintegrasi dari beberapa komponen)

• Pengujian integrasi menjadi black-box testing dengan menurunkan uji dari spesifikasi sistem

• Kesulitan utama adalah lokalisasi error yang ditemukan

• Solusi ( Pengujian inkremental

• Yaitu dg mengintegrasi konfigurasi sistem minimal dan menguji sistem ini

• Kemudian tambahkan komponen pada konfigurasi minimal dan mengujinya setelah inkremen ditambahkan

[pic]Pendekatan pengujian integrasi

• Top-down testing (Pengujian top-down)

o Dimulai dr komponen sistem tingkat tinggi, diintegrasikan dan diuji sebelum perancangan dan implementasinya selesai

• Bottom-up testing (Pengujian bottom-up)

o Komponen tingkat rendah diintegrasikan dan diuji sebelum komponen tingkat yang lebih tinggi dikembangkan

• Dalam prakteknya, kedua strategi ini sering dikombinasikan

[pic]

[pic]Perbandingan metode top-down dan bottom-up

• Validasi Arsitektural

o Top-down lebih memungkinkan menemukan error pd arsitektur sistem

• Demonstrasi sistem

o Dg Top-down sistem yg dapat dipakai dan terbatas tersedia pada tahap awal pengembangan

• Implementasi uji

o Lebih mudah diimplementasikan dengan bottom-up

• Pengamatan uji

o Bermasalah utk keduanya.

( Biasanya sistem dikembangkan dan diuji dg metode campuran, kr jadwal pengembangan yang berbeda, berarti tim harus bekerja dg komponen apapun yg tersedia

Pengujian Interface

• Dilakukan saat sub sistem diintegrasi utk membuat sistem yang lebih besar

• Tujuannya utk mendeteksi kesalahan yg mungkin telah masuk ke dl sistem kr error interface/asumsi valid mengenai interface

• Sangat penting untuk pengembangan berorientasi objek terutama saat objek dan kelas dipakai ulang

[pic]

Jenis Interface

• Parameter interfaces (interface parameter)

o Interface tempat data yg dikirim dari procedure (komponen) ke komponen lain

• Shared memory interfaces (interface memory bagi pemakai)

o Interface dg satu blok memory dipakai bersama antar sub sistem

• Procedural interfaces (Interface procedural)

o Interface dg satu sub sistem mengencapsulasi satu set prosedur yg dapat dipanggil oleh sub sistem lain

• Message passing interfaces

o Interface tempat satu sub sistem meminta layanan dari satu sub sistem lain dg mengirimkan message kepadanya

Error Interface

Salah satu bentuk error paling umum pd sistem komplek.

• Penyalah gunaan Interface

o Komponen pemanggil memanggil komponen lain dan melakukan error dalam penggunaan interfacenya. Mis urutan dan jml pengiriman yg salah

• Kesalahpahaman Interface

o Komponen pemanggil salah memahami spesifikasi interface komponen yg dipanggil. Mis rutin search biner dipanggil dg array yg tidak urut, shg search akan gagal

• Timing errors

o Terjadi pada sistem waktu nyata (sistem yg memberikan respons langsung saat diakses. Cth: ATM, pemesanan tiket online) yg menggunakan memory

Panduan Umum Pengujian Interface

• Rancang satu set uji dengan nilai parameter ke komponen eksternal.

• Selalu uji interface dgn parameter pointer null

• Rancang uji yg akan mengakibatkan komponen gagal

• Gunakan pengujian stress dlm sistem message passing

• Dl sharing memory rancang uji yg mengubah-ubah urutan aktivasi komponen

Pengujian Stress

• Melanjutkan pengujian utk melewati beban rancangan maksimum sistem sampai sistem gagal.

• Pengujian stres menguji prilaku kegagalan sistem.

• Sangat penting bahwa kegagalan sistem tidak menyebabkan kerusakan data atau kerugian yg tidak diharapkan dari layanan user

• Relevan bagi sistem terdistribusi yg berdasarkan jaringan prosesor

• Misalnya :

-sistem pengolahan transaksi dp dirancang utk memproses sampai 100 transaksi per detik. Kemudian dilakukan uji stress sampai melewati angka tsb sampai sistem gagal

- OS dirancang utk menangani sampai 200 terminal yg terpisah

Pengujian berorientasi object

• Komponen yg akan diuji adalah class object yang telah diinisialisasikan sebagai objek

• Objek sbg komponen individu sering kali lebih besar dari fungsi tunggal

Pengujian berorientasi object

• Komponen yg akan diuji adalah class object yang telah diinisialisasikan sebagai objek

• Objek sbg komponen individu seringkali lebih besar dari fungsi tunggal

Tingkat pengujian pada PBO

• Pengujian operasi individual yg berhubungan dgn objek ( fungsi atau procedure (dgn black-box atau white-box testing)

• Pengujian kelas objek individu

• Pengujian kelompok objek

• Pengujian sistem berorientasi objek

Pengujian Kelas Object

• Saat menguji objek liputan uji yg lengkap harus mencakup

o Pengujian semua operasi yg berhubungan dgn objek tsb

o Setting dan integrasi semua attribut yg berhub dgn objek tsb

o Melatih objek dgn semua status yg mungkin

• Penggunaan konsep inheriten mengakibatkan perancangan uji kelas objek menjadi lebih sulit

• Karena semua sub class harus diuji dg semua operasi yg diwarisi.

Pengujian Kelas Object

• Saat menguji objek liputan uji yg lengkap harus mencakup

o Pengujian semua operasi yg berhubungan dgn objek tsb

o Setting dan integrasi semua attribut yg berhub dgn objek tsb

o Melatih objek dgn semua status yg mungkin

• Penggunaan konsep inheriten mengakibatkan perancangan uji kelas objek menjadi lebih sulit

• Karena semua sub class harus diuji dgn semua operasi yg diwarisi.

Object integration

• Levels of integration are less distinct in object-oriented systems

• Cluster testing is concerned with integrating and testing clusters of cooperating objects

• Identify clusters using knowledge of the operation of objects and the system features that are implemented by these clusters

Approaches to cluster testing

• Use-case or scenario testing

o Testing is based on a user interactions with the system

o Has the advantage that it tests system features as experienced by users

• Thread testing

o Tests the systems response to events as processing threads through the system

• Object interaction testing

o Tests sequences of object interactions that stop when an object operation does not call on services from another object

Approaches to cluster testing

- Use-case or scenario testing

• Testing is based on a user interactions with the system

• Has the advantage that it tests system features as experienced by users

- Thread testing

• Tests the systems response to events as processing threads through the system

- Object interaction testing

• Tests sequences of object interactions that stop when an object operation does not call on services from another object

Scenario-based testing

▪ Identify scenarios from use-cases and supplement these with interaction diagrams that show the objects involved in the scenario

▪ Consider the scenario in the weather station system where a report is generated

[pic]Weather station testing

- Thread of methods executed

• CommsController:request ® WeatherStation:report ® WeatherData:summarise

- Inputs and outputs

• Input of report request with associated acknowledge and a final output of a report

• Can be tested by creating raw data and ensuring that it is summarised properly

• Use the same raw data to test the WeatherData object

Testing workbenches

• Testing is an expensive process phase. Testing workbenches provide a range of tools to reduce the time required and total testing costs

• Most testing workbenches are open systems because testing needs are organisation-specific

• Difficult to integrate with closed design and analysis workbenches

SISTEM KRITIS

Yaitu Sistem yang apabila terjadi kegagalan, maka dapat mengakibatkan kerugian ekonomi yang besar, kerusakan fisik atau mengancam hidup manusia.

Ada 3 tipe utama sistem kritis

• Sistem kritis dalam hal keselamatan

– Sistem yang kegagalannya dapat mengakibatkan cedera, kematian atau kerusakan lingkungan. Contoh : sistem kendali untuk pabrik kimia

• Sistem kritis dalam hal misi

– Kegagalannya dapat mengakibatkan kegagalan pada suatu kegiatan yang diarahkan pada suatu tujuan. Contoh : Sistem navigasi pesawat udara

• Sistem kritis dalam hal bisnis

– Kegagalannya dapat mengakibatkan kegagalan pada bisnis yang menggunakan sistem tersebut. Contoh : Sistem rekening nasabah pada sebuah bank

Biaya Kegagalan Sistem

• Langsung

– Karena sistem harus diganti

• Tidak langsung

– Biaya proses pengadilan

– Kerugian bisnis yang terjadi karena sistem tidak tersedia

Komponen sistem yang rentan terhadap kegagalan

• Hardware: disebabkan karena :

– Kesalahan dalam perancangan

– Komponen rusak karena kesalahan manufaktur

– Komponen telah mencapai akhir masa pakai

• Software : karena kesalahan dalam perincian, perancangan, atau implementasi

• Operator sistem : gagal menjalankan sistem dengan benar

Dependabilitas Sistem Kritis

• Dependabilitas

– Properti dari sistem

– Sama dengan keterpercayaan (trustworthiness)

– Yaitu derajad kepercayaan user bahwa sistem yang akan beroperasi sebagaimana yang mereka harapkan

– Atau sistem tidak akan gagal dalam penggunaan yang normal

Dimensi dependabilitas :

• Ketersediaan (Availability)

– Probabilitas bahwa sistem dapat bekerja dan memberikan layanan yang berguna setiap saat

• Keandalan (Reliability)

– Probabilitas bahwa dalam jangka waktu tertentu bahwa sistem akan memberikan layanan dengan benar sesuai harapan user

• Keselamatan (Safety)

– Penilaian pada seberapa besar kemungkinan sistem akan menyebabkan kerusakan terhadap orang dan lingkungan sistem

• Keamanan (Security)

– Penilaian pada seberapa besar kemungkinan sistem dapat bertahan terhadap campur tangan yang disengaja atau tidak disengaja

• Ada 3 dimensi dependabilitas yg berlaku

– Ketersediaan :

• Sistem hrs tersedia untuk memberikan insulin saat dibutuhkan

– Keandalan :

• Sistem hrs bekerja andal dan mengalirkan jumlah insulin yang tepat

– Keselamatan :

• Kegagalan sistem dapat mengakibatkan pemberian dosis yg berlebihan shg mengancam hidup pasien

KETERSEDIAAN & KEANDALAN

• Keandalan mencakup ketersediaan

• Krn jika suatu layanan yg telah ditentukan tidak diberikan, maka sistem tidak akan berjalan sebagaimana mestinya

• Namun ada sistem yg dapat mentolerir kegagalan yg relatif sering terjadi, namun memiliki persyaratan ketersediaan yg cukup tinggi ( cth : saklar hub telepon

• Jika sistem A gagal sekali setahun dan sistem B gagal sekali sebulan, maka A lebih dapat diandalkan dibanding B

• Tetapi jika A membutuhkan 3 hari untuk dapat bekerja kembali sementara B membutuhkan 10 menit,maka ketersediaan B selama setahun jauh lebih besar ketimbang A

• Keandalan :

– Probabilitsas sistem yg bebas dr kegagalan dlm kurun waktu tertentu pada suatulingkungan tertentu dan untuk tujuan yg tertentu pula

• Ketersediaan :

– Probabilitas bahwa suatu sistem pada suatu waktu akan bekerja dan dapat memberikan layanan yang diminta

• Tiga pendekatan yg saling melengkapi yg dapat digunakan untuk memperbaiki keandalan sistem :

– Penghindaran kesalahan

menghindari konstruksi bhs pemrograman yg rentan thd eror (pointer, rekursi, dll)

– Deteksi dan buang kesalahan

Pengujian dan debug sistem

– Toleransi kesalahan

Menjamin bahwa kesalahan sistem tidak menghasilkan eror atau menjamin bahwa eror sistem tidak mngakibatkan kegagalan

• Tidak semua kesalahn PL memiliki kemungkinan yang sama untuk mengakibatkan kegagalan PL

• Sebuah program mungkin mengandung kesalahan yg diketahui namun tetap dapat diandalkan oleh usernya

• User yg berpengalaman seringkali “berputar menghindari” kesalahan PL yg diketahui akan menyebabkan kegagalan.

KESELAMATAN

• Yaitu atribut sistem yg merefleksikan kemampuan sistem untuk beroperasi secara normal atau abnormal tanpa membahayakan manusia atau lingkungan

• Contoh : sistem kontrol dan monitor pada pesawat udara, sistem kontrol proses pada pabrik kimia dan farmasi, dan sistem kontrol pada mobil

PL lunak yg kritis dalam hal keselamatan terbagi atas :

1. PL kritis keselamatan primer

– PL yg menyatu sbg kontroler pada sistem

– Malfungsi PL menyebabkan malfungsi PK

– Menyebabkan cedera pada manusia atau kerusakan pada lingkungan

1. PL kritis keselamatan sekunder

– PL yg secara tidak langsung dapat menimbulkan cedera

– Cth : malfungsi sistem perancangan berbasis komputer yg mengakibatkan kesalahan pd objek yg dirancang

Fakta menunjukkan bahwa :

“Kita tidak akan pernah 100% yakin bahwa suatu sistem PL bebas dari kesalahan dan bertoleransi terhadap kesalahan”

Ada beberapa alasan lain mengapa sistem PL yg dapat diandalkan belum tentu menjamin keselamatan

1. Spesifikasi mungkin tidak lengkap

Tingkat persentase malfungsi sistem yg tinggi merupakan akibat dari eror spesifikasi, bukan eror perancangan.

1. Malfungsi perangkat keras

Shg menyebabkan PL menghasilkan suatu lingkungan yg tidak dapat diantisipasi

3. Operator sistem

Ada 3 hal yg perlu dilakukan utk menjamin bahwa kecelakaan tidak akan terjadi atau bahwa konsekuensi kecelakaan akan minimal, yaitu :

1. Menghindari bahaya

2. Deteksi dan membuang bahaya

Cth : sistem pabrik pengolahan bahan kimia yg dpt mendeteksi tekanan yg berlebihan dan akan membuka sebuah katup untuk mengurangi tekanan ini.

3. Membatasi kerusakan

Dgn menyertakan fitur proteksi yg akan meminimalisasi kerusakan

cth : pemadam api otomatis, sebelum melukai penumpang dan awak pesawat

KEAMANAN

• Yaitu penilaian sampai sejauh mana sistem melindungi diri dari serangan eksternal yg disengaja atau tidak.

• Contoh serangan : virus, penggunaan yg tidak syah atas layanan sistem, modifikasi yg tidak diijinkan thd data atau sistem

• Cth sistem yg memerlukan jaminan keamanan tinggi : sistem militer, sistem e-commerce, dan sistem yg melibatkan pertukaran informasi rahasia

Ada 3 jenis kerusakan yg dapat disebabkan oleh serangan eksternal :

1. Penolakan layanan

– Sehingga layanan normal sistem tidak tersedia

2. Korupsi program atau data

– Karena perubahan komponen PL

3. Penyingkapan informasi rahasia

4. Keamanan semakin penting dgn beragamnya sistem yg terhubung dgn internet

5. Atribut yg yg terpenting utk utk sistem berbasis internet adalah “kemampuan bertahan”

6. Yaitu kemampuan sistem untuk terus meberikan layanan pada saat diserang atau pada saat sebagian sistem telah dilumpuhkan.

SPESIFIKASI SISTEM KRITIS

• Karena biaya potensi kegagalan sistem tinggi, maka penting untuk menjamin bahwa spesifikasi sistem kritis harus berkualitas tinggi dan dgn akurat merefleksikan kebutuhan user sistem yg sebenarnya

Spesifikasi keandalan PL

• Perlunya dependibilitas pd sistem kritis menimbukan :

– Persyaratan fungsional

• Dibuat utk mendefenisikan pemeriksaan eror dan fasilitas pemulihan serta fitur2 yg memberikan proteksi thd kegagalan sistem

– Persyaratan non-fungsional

• Untuk mendefenisikan keandalan dan ketersediaan sistem yg dibutuhkan

• Persyaratan lain yg hrs dipertimbangkan adalah persyaratan “tidak akan”, yaitu :

– Sistem tidak akan memperbolehkan user mengubah ijin akses terhadap file manapun yg tidak mereka buat (keamanan)

– Sistem tidak akan memperbolehkan dipilihnya metode mendorong ke belakang (reverse thrust mode) ketika pesawat sedang terbang (keselamatan)

– Sistem tidak akan membolehkan aktivasi lebih dari tiga sinyal alarm secara bersamaan (keselamatan)

• Ada 3 dimensi ketika menspesifikasikan keandalan sistem secara menyeluruh :

– Keandalan PK

– Keandalan PL

– Keandalan operator

• Kegagalan PK dpt menyebabkan sinyal palsu yg berada diluar kisaran input

• Shg PL dp berprilaku spt yg tidak diharapkan

• Prilaku sistem yg tidak diharapkan dpt membingungkan operator dan mengakibatkan stres operator

• Eror operator sangat mungkin terjadi dalam kondisi stres, shg akan memberikan input yg tidak benar.

Spesifikasi keselamatan PL

• Operasi yg selamat mrpk karakteristik yg dibutuhkan pada sistem PL yg berhubungan dgn keselamatan

• Setiap bahaya harus dinilai terhadap resiko yg dimiliki

• Selanjutnya mendeskripsikan bagaimana PL harus berprilaku utk meminimalisasi resiko atau mempersyratkan bahwa bahaya tidak boleh terjadi

Analisa biaya dan resiko

• Tujuannya utk menemukan bahaya potensial yg mungkin muncul, akar penyebab bahaya, dan resiko yg berhubungan dgnnya.

• Proses iteratif dr analisis biaya dan resiko :

– Identifikasi bahaya ( petir, gempa bumi, dll

– Analisis resiko dan klasifikasi biaya

– Penguraian bahaya ( penyebab

– Penilaian reduksi resiko

[pic]

• Pengurangan resiko :

– Penghindaran bahaya

• Sistem dirancang shg bahaya tidak muncul

– Deteksi dan pembuangan bahaya

• Sistem dirancang shg bahaya terdeteksi dan dinetralisasi sebelum menimbulkan kecelakaan

– Pembatasan kerusakan

• Sistem dirancang shg konsekuensi kecelakaan diminimalisasi

Spesifikasi Keamanan

• Tahap proses spesifikasi keamanan :

– Identifikasi dan evaluasi aset (data dan program)

– Analisis ancaman dan penilaian resiko

– Penggolongan ancaman

– Analisis teknologi

PENGEMBANGAN SISTEM KRITIS

• Ada 2 pendekatan komplementer yg dapat dipakai jika tujuannya adalah mengembangkan PL yg dapat diandalkan :

– Penghindaran kesalahan

• Meminimalisasi eror manusia dan membantu menemukan kesalahan sistem sebelum sistem dipakai

– Toleransi kesalahan

• Sistem hrs dirancang sedemikian rupa shg kesalahan selama eksekusi akan terdeteksi dan tertangani.

Minimalisasi Kesalahan

• PL yg bebas dr kesalahan adalah PL yg dgn tepat mengikuti spesifikasinya.

• Namun PL yg bebas dr kesalahan belum tentu bebas dari kesalahan

Persyaratan utk pengembangan PL yg bebas dr kesalahan :

1. Harus ada spesifikasi sistem yg tepat

2. Organisasi yg mengembangkan sistem hrs memiliki kultur kualitas organisasi

3. Hrs digunakan pendekatan perancangan dan implementasi PL yg berdasarkan penyembunyian informasi dan enkapsulasi

4. Gunakan bhs pemrograman yg strongly-typed (dpt mendeteksi kesalahan lebih banyak oleh kompilator)

5. Menghindari penulisan yg potensial rentan thd eror

6. Proses pengembangan hrs didefenisikan. Manajer kualitas hrs memeriksa kesesuaian proses

Penghindaran Eror

• Stetement goto merupakan konstruksi pemrograman yg secara bawaan rentan thd eror

• Pemrograman terstruktur berarti :

– pemrograman tanpa penggunaan statement goto

– Hanya menggunakan loop while dan statement if sebagai konstruksi kontrol

• Pemrog terstruktur mrpk batu loncatan yg penting bagi pengembangan RPL

Penyembunyian Informasi

• Komponen2program harus diperbolehkan akses hanya ke data yg mereka butuhkan untuk implementasi.

• Peyembunyian informasi akan mengakibatkan inf yg disembunyikan tidak dapat dirusak oleh komponen2 program yg tidak seharusnya menggunakannya.

Toleransi Kesalahan

• Tujuannya utk menjamin bahwa kesalahan sistem tidak mengakibatkan kegagalan sistem

• Diperlukan pada situasi dimana kegagalan sistem dapat menyebabkan kecelakaan hebat

• Atau kerugian operasi sistem akan menyebabkan kerugian ekonomi yg besar

• Bebas kesalahan tidak berarti bebas kegagalan

Aspek toleransi kesalahan :

1. Deteksi kesalahan

2. Penilaian kerusakan

3. Pemulihan kerusakan( status aman

4. Perbaikan kesalahan

VALIDASI SISTEM KRITIS

• Proses V&V harus mendemonstrasikan bahwa sistem memenuhi spesifikasinya dan bahwa layanan dan prilaku sistem mendukung persyaratan klien

• Shg diperlukan penambahan analisis dan pengujian normal, karena :

– Biaya kegagalan ( jauh lebih besar dr pd sistem non-kritis

– Validasi atribut tingkat dependabilitas ( meyakinkan user

• Lebih dari 50% biaya pengembangan total utk sistem PL kritis ( agar kegagalan sistem yg mahal terhindari

• Contoh : kegagalan sistem PL dalam hal misi pada roket Ariane 5 th 1996, yg mengakibatkan beberapa satelit rusak.

• Kualitas sistem dipengaruhi oleh kualitas proses yg dipakai untuk mengembangkan sistem.

Validasi System Kritis

Validasi terhadap reliability (keandalan), safety (keselamatan) dan security (keamanan) bagi sistem berbasis komputer

Validation perspectives

• Validasi Reliability/keandalan

o Apakah keandalan sistem telah sesuai dengan spesifikasinya?

o Apakah keandalan sistem telah memberikan kepuasan pada user pemakai sistem?

• Validasi Safety/keselamatan

o Menjamin bahwa kecelakaan tidak akan terjadi atau bahwa konsekuensi kecelakaan akan minimal.

• Validasi Security/keamanan

o Apakah sistem dan datanya aman terhadap serangan external?

Tekhnik Validasi

• Static techniques

o Review terhadap disain /inspeksi program

• Dynamic techniques

o Pengujian Statistik

o Pengujian berbasis skenario

o Pemeriksaan Run-time

• Process validation

o Desain proses pembangunan yang meminimalkan kemungkinan kesalahan dari proses sesuai dgn dependibilitas sistem (keandalan, ketersediaan, keselamatan dan keamanan)

Static validation techniques

• Static validation lebih fokus pada analisa dokumentasi sistem(persyaratan, disain, kode dan data uji)

• Fokus pada penemuan eror sistem dan identifikasi permasalahan yg berpotensi muncul saat exekusi.

• Beberapa dokumen (argumen terstruktur, pembuktian secara matematis, dll) dapat disiapkan utk mendukung validasi statik

Static techniques for safety validation

• Menunjukkan keselamatan sistem melalui sebuah pengujian merupakan sesuatu yg sulit

• Karena pengujian bertujuan utk menunjukkan apa yg dilakukan sistem saat situasi normal.

• Tidak mungkin dilakukan pengujian thd setiap kondisi operasional

Safety reviews

1. Peninjauan thd Review for kebenaran function

2. Peninjauan thd maintainable, understandable structure

3. Peninjauan thd algorithma dan disain struktur data berdasarkan spesifikasi

4. Peninjauan thd konsistensi kode dgn algorithma dan disain struktur data

5. Peninjauan thd kelayakan sistem pengujian

Review guidance

1. Buatlah software sesederhana mungkin

2. Gunakan teknik yg sederhana dlm pencegahan error seperti menghindari pemakaian pointers and recursion

3. Gunakan information hiding (penyembunyian inf) agar inf yg dsembunyikan tidak dirusak oleh komponen program yg tidak seharusnya menggunakannya

4. Gunakan teknik toleransi kesalahan yg sesuai , namun jangan pernah berfikir bahwa hasilnya benar-benar aman

Hazard-driven analysis

1. Efektif atau tidaknya jaminan keselamatan bergantung pada identifikasi bahaya

2. Keselamatan dapat dijamin melalui

a. Menghindari bahaya( sistem pemotongan yg menuntut operator agar menekan 2 tombol terpisah

b. Deteksi dan membuang bahaya( deteksi tekanan berlebihan dan pembukaan katup sebelum meledak pd pabrik kimia

c. Membatasi kerusakan ( pemadam api otomatis

3. Safety review (ulasan keselamatan) harus menunjukkan bahwa satu atau lebih teknik ini telah diterapkan untuk semua bahaya yg telah diidentifikasi

The system safety case

1. Saat ini praktek formal untuk keselamatan menjadi hal yang diperlukan untuk keselamatan semua sistem berbasis komputer, misalnya isyarat rel kereta api, pengendalian lalu lintas udara, dan lain-lain

2. Kasus keselamatan menyajikan daftar argumen, berdasarkan bahaya yg teridentifikasi

3. Mengapa ada penerimaan yg rendah thd kemungkinan bahwa bahaya ini tidak akan mengakibatkan kecelakaan

4. Argumen dapat didasarkan pada bukti formal, desain dasar, keselamatan bukti, dll. Faktor Proses mungkin juga dimasukkan

Formal methods and critical systems

• Pengembangan sistem kritis adalah salah satu 'keberhasilan' dari metode formal

• Di Inggris digunakan untuk pengembangan beberapa jenis perangkat lunak keamanan untuk aplikasi pertahanan

• Saat ini tidak ada perjanjian umum tentang nilai metode formal dalam pengembangan sistem

Formal methods and validation

• Specification validation

o Developing a formal model of a system requirements specification forces a detailed analysis of that specification and this usually reveals errors and omissions

o Mathematical analysis of the formal specification is possible and this also discovers specification problems

• Formal verification

o Mathematical arguments (at varying degrees of rigour) are used to demonstrate that a program or a design is consistent with its formal specification

Formal methods conclusion

1. Spesifikasi formal dan memeriksa komponen sistem yang penting adalah sangat berguna

a. Walaupun formalitas tidak memberikan jaminan, hal ini membantu untuk meningkatkan keyakinan dalam sistem dgn mendemonstrasikan bahwa beberapa kesalahan tidak muncul

2. Verifikasi formal hanya mungkin digunakan untuk sistem yg sangat kecil, kritis, dan utk komponen sistem

a. Kurang lebih 5-6000 baris kode

Safety proofs

1. Safety proofs are intended to show that the system cannot reach in unsafe state

2. Weaker than correctness proofs which must show that the system code conforms to its specification

3. Generally based on proof by contradiction

a. Assume that an unsafe state can be reached

b. Show that this is contradicted by the program code

4. May be displayed graphically

Construction of a safety proof

▪ Establish the safe exit conditions for a component or a program

▪ Starting from the END of the code, work backwards until you have identified all paths that lead to the exit of the code

▪ Assume that the exit condition is false

▪ Show that, for each path leading to the exit that the assignments made in that path contradict the assumption of an unsafe exit from the component

Gas warning system

▪ System to warn of poisonous gas. Consists of a sensor, a controller and an alarm

▪ Two levels of gas are hazardous

o Warning level - no immediate danger but take action to reduce level

o Evacuate level - immediate danger. Evacuate the area

▪ The controller takes air samples, computes the gas level and then decides whether or not the alarm should be activated

Gas sensor control

Gas_level: GL_TYPE ;

loop

-- Take 100 samples of air

Gas_level := 0.000 ;

for i in 1..100 loop

Gas_level := Gas_level + Gas_sensor.Read ;

end loop ;

Gas_level := Gas_level / 100 ;

if Gas_level > Warning and Gas_level < Danger then

Alarm := Warning ; Wait_for_reset ;

elsif Gas_level > Danger then

Alarm := Evacuate ; Wait_for_reset ;

else

Alarm := off ;

end if ;

end loop ;

[pic]

[pic]

Key points

▪ Safety-related systems should be developed to be as simple as possible using ‘safe’ development techniques

▪ Safety assurance may depend on ‘trusted’ development processes and specific development techniques such as the use of formal methods and safety proofs

▪ Safety proofs are easier than proofs of consistency or correctness. They must demonstrate that the system cannot reach an unsafe state. Usually proofs by contradiction

Dynamic validation techniques

l These are techniques that are concerned with validating the system in execution

• Testing techniques - analysing the system outside of its operational environment

• Run-time checking - checking during execution that the system is operating within a dependability ‘envelope’

Reliability validation

▪ Reliability validation involves exercising the program to assess whether or not it has reached the required level of reliability

▪ Cannot be included as part of a normal defect testing process because data for defect testing is (usually) atypical of actual usage data

▪ Statistical testing must be used where a statistically significant data sample based on simulated usage is used to assess the reliability

Statistical testing

▪ Testing software for reliability rather than fault detection

▪ Measuring the number of errors allows the reliability of the software to be predicted. Note that, for statistical reasons, more errors than are allowed for in the reliability specification must be induced

▪ An acceptable level of reliability should be

specified and the software tested and amended

until that level of reliability is reached

Reliability validation process

▪ Establish the operational profile for the system

▪ Construct test data reflecting the operational profile

▪ Test the system and observe the number of failures and the times of these failures

▪ Compute the reliability after a statistically significant number of failures have been observed

Operational profiles

▪ An operational profile is a set of test data whose frequency matches the actual frequency of these inputs from ‘normal’ usage of the system. A close match with actual usage is necessary otherwise the measured reliability will not be reflected in the actual usage of the system

▪ Can be generated from real data collected from an existing system or (more often) depends on assumptions made about the pattern of usage of a system

[pic]

Operational profile generation

▪ Should be generated automatically whenever possible

▪ Automatic profile generation is difficult for interactive systems

▪ May be straightforward for ‘normal’ inputs but it is difficult to predict ‘unlikely’ inputs and to create test data for them

Reliability modelling

▪ A reliability growth model is a mathematical model of the system reliability change as it is tested and faults are removed

▪ Used as a means of reliability prediction by extrapolating from current data

o Simplifies test planning and customer negotiations

▪ Depends on the use of statistical testing to measure the reliability of a system version

[pic]

Observed reliability growth

▪ Simple equal-step model but does not reflect reality

▪ Reliability does not necessarily increase with change as the change can introduce new faults

▪ The rate of reliability growth tends to slow down with time as frequently occurring faults are discovered and removed from the software

▪ A random-growth model may be more accurate

[pic]

Growth model selection

▪ Many different reliability growth models have been proposed

▪ No universally applicable growth model

▪ Reliability should be measured and observed data should be fitted to several models

▪ Best-fit model should be used for reliability prediction

[pic]

Reliability validation problems

1. Operational profile uncertainty

a. Is the operational profile an accurate reflection of the real use of the system

2. High costs of test data generation

a. Very expensive to generate and check the large number of test cases that are required

3. Statistical uncertainty for high-reliability systems

a. It may be impossible to generate enough failures to draw statistically valid conclusions

Security validation

1. Security validation has something in common with safety validation

2. It is intended to demonstrate that the system cannot enter some state (an unsafe or an insecure state) rather than to demonstrate that the system can do something

3. However, there are differences

a. Safety problems are accidental; security problems are deliberate

b. Security problems are more generic; Safety problems are related to the application domain

Security validation

Experience-based validation

The system is reviewed and analysed against the types of attack that are known to the validation team

Tool-based validation

Various security tools such as password checkers are used to analyse the system in operation

Tiger teams

A team is established whose goal is to breach the security of the system by simulating attacks on the system.

Key points

• Statistical testing supplements the defect testing process and is intended to measure the reliability of a system

• Reliability validation relies on exercising the system using an operational profile - a simulated input set which matches the actual usage of the system

• Reliability growth modelling is concerned with modelling how the reliability of a software system improves as it is tested and faults are removed

The portable insulin pump

Validating the safety of the insulin pump system

Safety validation

• Design validation

o Checking the design to ensure that hazards do not arise or that they can be handled without causing an accident.

• Code validation

o Testing the system to check the conformance of the code to its specification and to check that the code is a true implementation of the design.

• Run-time validation

o Designing safety checks while the system is in operation to ensure that it does not reach an unsafe state.

Insulin system hazards

• insulin overdose or underdose (biological)

• power failure (electrical)

• machine interferes electrically with other medical equipment such as a heart pacemaker (electrical)

• parts of machine break off in patient’s body(physical)

• infection caused by introduction of machine (biol.)

• allergic reaction to the materials or insulin used in the machine (biol).

[pic]

Safety proofs

• Safety proofs are intended to show that the system cannot reach in unsafe state

• Weaker than correctness proofs which must show that the system code conforms to its specification

• Generally based on proof by contradiction

o Assume that an unsafe state can be reached

o Show that this is contradicted by the program code

Insulin delivery system

1. Safe state is a shutdown state where no insulin is delivered

a. If hazard arises,shutting down the system will prevent an accident

2. Software may be included to detect and prevent hazards such as power failure

3. Consider only hazards arising from software failure

a. Arithmetic error The insulin dose is computed incorrectly because of some failure of the computer arithmetic

b. Algorithmic error The dose computation algorithm is incorrect

Arithmetic errors

▪ Use language exception handling mechanisms to trap errors as they arise

▪ Use explicit error checks for all errors which are identified

▪ Avoid error-prone arithmetic operations (multiply and divide). Replace with add and subtract

▪ Never use floating-point numbers

▪ Shut down system if exception detected (safe state)

Algorithmic errors

▪ Harder to detect than arithmetic errors. System should always err on the side of safety

▪ Use reasonableness checks for the dose delivered based on previous dose and rate of dose change

▪ Set maximum delivery level in any specified time period

▪ If computed dose is very high, medical intervention may be necessary anyway because the patient may be ill

Insulin delivery code

// The insulin dose to be delivered is a function of blood sugar level, the previous dose

// delivered and the time of delivery of the previous dose

currentDose = computeInsulin () ;

// Safety check - adjust currentDose if necessary

if (previousDose == 0) // if statement 1

{

if (currentDose > 16)

currentDose = 16 ;

}

else

if (currentDose > (previousDose * 2) )

currentDose = previousDose * 2 ;

if ( currentDose < minimumDose ) // if statement 2

currentDose = 0 ; // then branch

else if ( currentDose > maxDose ) // else branch

currentDose = maxDose ;

administerInsulin (currentDose) ;

[pic]

System testing

▪ System testing of the software has to rely on simulators for the sensor and the insulin delivery components.

▪ Test for normal operation using an operational profile. Can be constructed using data gathered from existing diabetics

▪ Testing has to include situations where rate of change of glucose is very fast and very slow

▪ Test for exceptions using the simulator

Safety assertions

▪ Predicates included in the program indicating conditions which should hold at that point

▪ May be based on pre-computed limits e.g. number of insulin pump increments in maximum dose

▪ Used in formal program inspections or may be pre-processed into safety checks that are executed when the system is in operation

Safety assertions

static void administerInsulin ( ) throws SafetyException

{

int maxIncrements = InsulinPump.maxDose / 8 ;

int increments = InsulinPump.currentDose / 8 ;

// assert currentDose InsulinPump.maxDose)

throw new SafetyException (Pump.doseHigh);

else

for (int i=1; i maxIncrements)

throw new SafetyException ( Pump.incorrectIncrements);

} // for loop

} //administerInsulin

-----------------------

Fault class

Inspection check

Data faults

Are all program variables initialised before their

values

are used?

Have all constants been named?

Should the lower bound of arrays

be 0, 1, or something

else?

Should the upper bound of arrays be

equal to the size of

the array or Size -1?

If character strings are

used, is a delimiter explicitly

assigned?

Control faults

For each conditional statement, is the condition correct?

Is each loop certain to terminate?

Are compound statements correctly bracketed?

In case statements, are all possible cases accounted for?

Input/output faults

Are all input variables used?

Are all output variables assigned

a value before they are

output?

Interface faults

Do

all function and procedure calls have the correct

number of parameters?

Do formal and actual parameter types match?

Are the parameters in the right order?

If components access shared memory, do they have

the

same model of the shared memory structure?

Storage

management

faults

If a linked structure is modified,

have all links been

correctly reassigned?

If dynamic

storage is used, has space been allocated

correctly?

Is space explicitly de-allocated after it

is no longer

required?

Exception

management faults

Have all possible error conditions been taken

into

account?

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download