Upload
tranthien
View
213
Download
0
Embed Size (px)
Citation preview
Software DevelopmentPengembangan 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 lengkapRancangan 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
testing dan implementasi sistem//STMIK Jayanusa
ò 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
testing dan implementasi sistem//STMIK Jayanusa
oleh Retantyo W 15
Pendekatan Evolusi (prototyping)
PrototypingStep 1
Kebutuhan sistem dasar
Step 2Kembangkan prototipe awal
Step 3Gunakan prototipe dan catatperubahan yang diinginkan
Step 4Perbaiki prototipe sesuai dengan
yang diinginkan
User Ok
oleh Retantyo W 16
Pendekatan evolusi lanjutan
Prototipe sebagai metodologipengembangan Step 1: Kebutuhan sistem dasar
Step 2: Kembangkan prototipeawal
Step 3: Gunakan prototipe dancatat perubahan yang diinginkan
Step 4: Perbaiki prototipe1
User
Ok
oleh Retantyo W 17
Pendekatan evolusi lanjutan
Step 5: Evaluasi sebagai sistemoperasional
Step 6: Buat modifikasiseperlunya
Step 7: Install, operasikan danevolve
1
testing dan implementasi sistem//STMIK Jayanusa
oleh Retantyo W 18
Pendekatan evolusi lanjutan Prototipe dalam SDLC
Step 1: Analisis Kelayakan
Step 2: Prototipe pedefinisian kebutuhan
Step 3: Desain Sistem
Step 4: Membangun Sistem
Step 5: Pengujian Sistem
Step 6: Instalasi Sistem
Step 7: Operasi & Maintenans
Bahan 2Verification and ValidationUntuk menjamin bahwa software yang dibangun sesuai dengan kebutuhan userVerification 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 klienStatic 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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 19 Slide 4
Static dan dynamic V&V
Spesifikasiformal
Peranc. tk. tinggi
sSpesifikasi 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
testing dan implementasi sistem//STMIK Jayanusa
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 &
keandalannyaPengujian 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 ituV & 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
testing dan implementasi sistem//STMIK Jayanusa
» 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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 19 Slide 12
Proses Debug
Temukan lokasierror
Rancangperbaikan
Perbaikierror
Uji ulangprogram
Hasil Test Specification Kasus uji
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
testing dan implementasi sistem//STMIK Jayanusa
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 19 Slide 14
The V-model of development
Specifikasipersyaratan
Spesifikasisistem
Perancangansistem
Perancanganrinci
Kode danpengujian modul
dan unit
Rencana ujiintegrasisub sistem
Rencana ujiintegrasi sistem
cccccRencana ujipenerimaan
c
Layanan Uji Penerimaan Uji integrasisistem
Uji integrasisub sistem
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
testing dan implementasi sistem//STMIK Jayanusa
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-conditionsSebelum 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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 19 Slide 21
Proses Inspeksi
Rapatpemeriksaan
Persiapanindividui
TinjauanPerencanaan
Pengerjaanulang
Tindaklanjut
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
testing dan implementasi sistem//STMIK Jayanusa
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.
testing dan implementasi sistem//STMIK Jayanusa
Fault class Inspection checkData 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 somethingelse? Should the upper bound of arrays be equal to the size ofthe array or Size -1?If character strings are used, is a delimiter explicitlyassigned?
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 areoutput?
Interface faults Do all function and procedure calls have the correctnumber of parameters?Do formal and actual parameter types match? Are the parameters in the right order? If components access shared memory, do they have thesame model of the shared memory structure?
Storage managementfaults
If a linked structure is modified, have all links beencorrectly reassigned?If dynamic storage is used, has space been allocatedcorrectly?Is space explicitly de-allocated after it is no longerrequired?
Exceptionmanagement faults
Have all possible error conditions been taken intoaccount?
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
testing dan implementasi sistem//STMIK Jayanusa
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 19 Slide 28
Static analysis checksFault class Static analysis check
Data faults Variables used before initialisationVariables declared but never usedVariables assigned twice but never usedbetween assignmentsPossible array bound violations Undeclared variables
Control faults Unreachable codeUnconditional branches into loops
Input/output faults Variables output twice with no interveningassignment
Interface faults Parameter type mismatchesParameter number mismatchesNon-usage of the results of functionsUncalled functions and procedures
Storage managementfaults
Unassigned pointersPointer arithmetic
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
testing dan implementasi sistem//STMIK Jayanusa
LINT static analysis Unix dan Linux utkC
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.c140% lint lint_ex.c
lint_ex.c(10): warning: c may be used before setlint_ex.c(10): warning: i may be used before setprintarray: 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
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
testing dan implementasi sistem//STMIK Jayanusa
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 19 Slide 35
The Cleanroom process
Constructstructuredprogram
Definesoftware
increments
Formallyverifycode
Integrateincrement
Formallyspecifysystem
Developoperational
profileDesign
statisticaltests
Testintegrated
system
Error rework
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).
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 19 Slide 37
Incremental development
Formalspecification
Develop s/wincrement
Establishrerquirements
Deliversoftware
Frozenspecification
Requirements change request
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
testing dan implementasi sistem//STMIK Jayanusa
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 engineersKey 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 4Pengujian Cacat (Defect Testing)
Pengujian program untuk mengungkap adanya cacat pada sistem PLTujuan
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)
testing dan implementasi sistem//STMIK Jayanusa
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 5
Testing phases
Componenttesting
Integrationtesting
Software developer Independent testing team
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 9
The defect testing process
Rancang kasus uji
Siapkan data uji
Jalankan prog dgn data uji
Bandingkan hasil dgn kasus uji
Kasus Uji
Tdata uji Hasil uji Laporan uji
s
Pengujian cacat terdiri dari: Black-box testing Partisi equivalensi Pengujian struktural Pengujian jalur
Black-box testing
testing dan implementasi sistem//STMIK Jayanusa
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)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 12
Black-box testing
I eInput testdata
OeOutputtestresults
System
Input yg menyebabkan prilaku menyimpang
Output
Jika output bukan merupakan yang diramalkan, berarti uji tsb telah berhasilmendeteksi
masalah dgn PL tsbyg mengungkap adanya cacat
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 14
Partisi Equivalesi
System
Outputs
Invalid inputs Valid inputs
Partisi Equivalesi
testing dan implementasi sistem//STMIK Jayanusa
- 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.999Partisi equivalensinya adalah <10.000, 10.000-99. 999 dan > 99.999
- Pilih kasus uji pada batasan dari himpunan tersebut• 00000, 09999, 10000, 99999, 10001
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 16
Equivalence partitions
Between 10000 and 99999Less than 10000 More than 99999
999910000 50000
10000099999
Input values
Between 4 and 10Less than 4 More than 10
34 7
1110
Number of input values
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 17
Search routine specificationprocedure Search (Key : ELEM ; T: ELEM_ARRAY;
Found : in out BOOLEAN; L: in out ELEM_INDEX) ;
Pre-condition-- the array has at least one elementT’FIRST <= T’LAST
Post-condition-- the element is found and is referenced by L( Found and T (L) = Key)
or-- the element is not in the array( not Found andnot (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))
mencari sederet elemen untuk elemen tertentu (kunci)
kondisi pra menyatakan rutin search dirancang utk bekerja dengan deret kosong Kondisi pasca menyatakan variavel Found diset jika elemen kunci ada pd deret
Posisi elemen kunci ditunjukkan oleh indeks L dan tidak didefenisikan jika elemen tidak berada dalam deret
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)
testing dan implementasi sistem//STMIK Jayanusa
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 20
Search routine - input partitionsArray ElementSingle value In sequenceSingle value Not in sequenceMore than 1 value First element in sequenceMore than 1 value Last element in sequenceMore than 1 value Middle element in sequenceMore than 1 value Not in sequence
Input sequence (T) Key (Key) Output (Found, L)17 17 true, 117 0 false, ??17, 29, 21, 23 17 true, 141, 18, 9, 31, 30, 16, 45 45 true, 717, 18, 21, 23, 29, 41, 38 23 true, 421, 23, 29, 33, 38 25 false, ??
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 22
White-box testing
Componentcode
Testoutputs
Test data
DerivesTests
testing dan implementasi sistem//STMIK Jayanusa
Binary search (Java)
class BinSearch {
// This is an encapsulation of a binary search function that takes an array of// ordered objects and a key and returns an object with 2 attributes namely// index - the value of the array index// found - a boolean indicating whether or not the key is in the array// An object is returned because it is not possible in Java to pass basic types by// reference to a function and so return two values// the key is -1 if the element is not found
public static void search ( int key, int [] elemArray, Result r ){
int bottom = 0 ;int top = elemArray.length - 1 ;int mid ;r.found = false ; r.index = -1 ;while ( bottom <= top ){
mid = (top + bottom) / 2 ;if (elemArray [mid] == key){
r.index = mid ;r.found = true ;return ;
} // if partelse{
if (elemArray [mid] < key)bottom = mid + 1 ;
elsetop = mid - 1 ;
}} //while loop
} // search} //BinSearch
Berdasarkan kode utk search rutin, binary search melibatkan pembagian ruang searching menjadi 3
• elemArray[mid]==key• elemArray[mid]<key• elemArray>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
testing dan implementasi sistem//STMIK Jayanusa
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 26
Binary search equiv. partitions
Mid-point
Elements < Mid Elements > Mid
Equivalence class boundaries
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 27
Binary search - test cases
Input array (T) Key (Key) Output (Found, L)17 17 true, 117 0 false, ??17, 21, 23, 29 17 true, 19, 16, 18, 30, 31, 41, 45 45 true, 717, 18, 21, 23, 29, 38, 41 23 true, 417, 18, 21, 23, 29, 33, 38 21 true, 312, 18, 21, 23, 32 23 true, 421, 23, 29, 33, 38 25 false, ??
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
testing dan implementasi sistem//STMIK Jayanusa
Binary search flow graph
1
2
3
4
65
7
while bottom <= top
if (elemArray [mid] == key
(if (elemArray [mid]< key8
9
bottom > top
Edge = 11Node = 9CC = 11-9+2
=4
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
executedPengujian 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
testing dan implementasi sistem//STMIK Jayanusa
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 34
Incremental integration testing
T3
T2
T1
T4
T5
A
B
C
D
T2
T1
T3
T4
A
B
C
T1
T2
T3
A
B
Test sequence1
Test sequence2
Test sequence3
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 36
Top-down testing
Level 2Level 2Level 2Level 2
Level 1 Level 1Testingsequence
Level 2stubs
Level 3stubs
. . .
testing dan implementasi sistem//STMIK Jayanusa
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 37
Bottom-up testing
Level NLevel NLevel NLevel NLevel N
Level N–1 Level N–1Level N–1
Testingsequence
Testdrivers
Testdrivers
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 ujio Lebih mudah diimplementasikan dengan bottom-up
Pengamatan ujio Bermasalah utk keduanya.
à Biasanya sistem dikembangkan dan diuji dg metode campuran, kr jadwal pengembangan yang berbeda, berarti tim harus bekerja dg komponen apapun yg tersediaPengujian 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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 41
Interface testingTestcases
BA
C
Pengujian bukan terhadap komponen, tetapi terhadap subsistem yg terbuat dari gabungan komponen
testing dan implementasi sistem//STMIK Jayanusa
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 InterfaceSalah satu bentuk error paling umum pd sistem komplek.
Penyalah gunaan Interfaceo Komponen pemanggil memanggil komponen lain dan melakukan error
dalam penggunaan interfacenya. Mis urutan dan jml pengiriman yg salah
Kesalahpahaman Interfaceo Komponen pemanggil salah memahami spesifikasi interface komponen
yg dipanggil. Mis rutin search biner dipanggil dg array yg tidak urut, shg search akan gagal
Timing errorso 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 komponenPengujian 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
testing dan implementasi sistem//STMIK Jayanusa
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 tsbo Setting dan integrasi semua attribut yg berhub dgn objek tsbo 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 mencakupo Pengujian semua operasi yg berhubungan dgn objek tsbo Setting dan integrasi semua attribut yg berhub dgn objek tsbo 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 clustersApproaches to cluster testing
Use-case or scenario testingo Testing is based on a user interactions with the systemo Has the advantage that it tests system features as experienced by users
Thread testingo 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
testing dan implementasi sistem//STMIK Jayanusa
- Object interaction testing• Tests sequences of object interactions that stop when an object
operation does not call on services from another objectScenario-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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 53
Collect weather data:CommsController
request (report)
acknowledge ()report ()
summarise ()
reply (report)
acknowledge ()
send (report)
:WeatherStation :WeatherData
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
testing dan implementasi sistem//STMIK Jayanusa
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)
testing dan implementasi sistem//STMIK Jayanusa
– 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.
testing dan implementasi sistem//STMIK Jayanusa
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 lengkapTingkat persentase malfungsi sistem yg tinggi merupakan akibat dari eror spesifikasi, bukan eror perancangan.
1. Malfungsi perangkat kerasShg menyebabkan PL menghasilkan suatu lingkungan yg tidak dapat
diantisipasi3. Operator sistem
Ada 3 hal yg perlu dilakukan utk menjamin bahwa kecelakaan tidak akan terjadi atau bahwa konsekuensi kecelakaan akan minimal, yaitu :
1. Menghindari bahaya2. 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 kerusakanDgn menyertakan fitur proteksi yg akan meminimalisasi kerusakancth : 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 :
testing dan implementasi sistem//STMIK Jayanusa
1. Penolakan layanan– Sehingga layanan normal sistem tidak tersedia
2. Korupsi program atau data– Karena perubahan komponen PL
3. Penyingkapan informasi rahasia4. Keamanan semakin penting dgn beragamnya sistem yg terhubung dgn internet5. 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
testing dan implementasi sistem//STMIK Jayanusa
• 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
Analisa Pohon kesalahan
Incorrectsugar levelmeasured
Incorrectinsulin doseadministered
or
Correct dosedelivered atwrong time
Sensorfailure
or
Sugarcomputation
error
Timerfailure
Pump signalsincorrect
or
Insulincomputation
incorrect
Deliverysystemfailure
Arithmeticerror
or
Algorithmerror
Arithmeticerror
or
Algorithmerror
Pohon kesalahan yg dapat diidentifikasi utk bahaya yg meungkin muncul yg berhubungan dgn PL pada sistem penyaluran insulin
• 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
testing dan implementasi sistem//STMIK Jayanusa
• 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 tepat2. Organisasi yg mengembangkan sistem hrs memiliki kultur kualitas organisasi3. Hrs digunakan pendekatan perancangan dan implementasi PL yg berdasarkan
penyembunyian informasi dan enkapsulasi4. Gunakan bhs pemrograman yg strongly-typed (dpt mendeteksi kesalahan lebih
banyak oleh kompilator)5. Menghindari penulisan yg potensial rentan thd eror6. 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 kesalahan2. Penilaian kerusakan3. Pemulihan kerusakanà status aman4. Perbaikan kesalahan
VALIDASI SISTEM KRITIS
testing dan implementasi sistem//STMIK Jayanusa
• 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
testing dan implementasi sistem//STMIK Jayanusa
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/keamanano Apakah sistem dan datanya aman terhadap serangan external?
Tekhnik Validasi Static techniques
o Review terhadap disain /inspeksi program Dynamic techniques
o Pengujian Statistiko Pengujian berbasis skenarioo Pemeriksaan Run-time
Process validationo 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 reviews1. Peninjauan thd Review for kebenaran function2. Peninjauan thd maintainable, understandable structure3. Peninjauan thd algorithma dan disain struktur data berdasarkan
spesifikasi4. Peninjauan thd konsistensi kode dgn algorithma dan disain struktur
data5. Peninjauan thd kelayakan sistem pengujian
testing dan implementasi sistem//STMIK Jayanusa
Review guidance1. Buatlah software sesederhana mungkin2. Gunakan teknik yg sederhana dlm pencegahan error seperti
menghindari pemakaian pointers and recursion3. 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 analysis1. Efektif atau tidaknya jaminan keselamatan bergantung pada
identifikasi bahaya2. 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 otomatis3. Safety review (ulasan keselamatan) harus menunjukkan bahwa satu
atau lebih teknik ini telah diterapkan untuk semua bahaya yg telah diidentifikasi
The system safety case1. 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
testing dan implementasi sistem//STMIK Jayanusa
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 verificationo 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 conclusion1. Spesifikasi formal dan memeriksa komponen sistem yang penting adalah
sangat bergunaa. 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 proofs1. Safety proofs are intended to show that the system cannot reach in unsafe state2. Weaker than correctness proofs which must show that the system code
conforms to its specification3. Generally based on proof by contradiction
a. Assume that an unsafe state can be reachedb. 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 levelo 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
testing dan implementasi sistem//STMIK Jayanusa
Gas_level: GL_TYPE ; loop
-- Take 100 samples of airGas_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 ;
©Ian Sommerville 2000 CS 365 Critical Systems Validation Slide 17
Graphical argument
Gas_level > Warning and Alarm = off Unsafe state
Gas_level > Warning and Gas_level < Danger
Gas_level > Danger
Alarm = WarningAlarm = Evacuate Alarm = off
or or or
contradiction contradiction
Path 1 Path 2 Path 3
©Ian Sommerville 2000 CS 365 Critical Systems Validation Slide 18
Condition checking
Gas_level < Warning Path 3 Alarm = off (Contradiction)Gas_level = Warning Path 3 Alarm = off (Contradiction)Gas_level > Warning andGas_level < Danger
Path 1 Alarm = Warning(Contradiction)
Gas_level = Danger Path 3 Alarm = offGas_level > Danger Path 2 Alarm = Evacuate
(Contradiction)
Code is incorrect. Gas_level = Danger does not cause the alarm to be on
Key points
testing dan implementasi sistem//STMIK Jayanusa
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 techniquesl 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
testing dan implementasi sistem//STMIK Jayanusa
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
©Ian Sommerville 2000 CS 365 Critical Systems Validation Slide 25
An operational profile
Numberof inputs
Inputclasses
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
©Ian Sommerville 2000 CS 365 Critical Systems Validation Slide 28
Equal-step reliability growth
t1 t2 t3 t4 t5
Reliability(ROCOF)
Time
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
testing dan implementasi sistem//STMIK Jayanusa
©Ian Sommerville 2000 CS 365 Critical Systems Validation Slide 30
Random-step reliability growth
t1 t2 t3 t4 t5Time
Note differentreliabilityimprovements Fault repair adds new fault
and decreases reliability(increases ROCOF)
Reliability(ROCOF)
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
©Ian Sommerville 2000 CS 365 Critical Systems Validation Slide 32
Reliability prediction
Reliability
Requiredreliability
Fitted reliabilitymodel curve
Estimatedtime of reliability
achievement
Time
= Measured reliability
Reliability validation problems1. Operational profile uncertainty
a. Is the operational profile an accurate reflection of the real use of the system
2. High costs of test data generationa. Very expensive to generate and check the large number of test cases
that are required3. Statistical uncertainty for high-reliability systems
a. It may be impossible to generate enough failures to draw statistically valid conclusions
Security validation1. Security validation has something in common with safety validation2. 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
testing dan implementasi sistem//STMIK Jayanusa
3. However, there are differencesa. Safety problems are accidental; security problems are deliberateb. Security problems are more generic; Safety problems are related to the
application domain
Security validationExperience-based validation
The system is reviewed and analysed against the types of attack that are known to the validation team
Tool-based validationVarious security tools such as password checkers are used to analyse the system in operation
Tiger teamsA 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 pumpValidating 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 validationo 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 validationo 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).
testing dan implementasi sistem//STMIK Jayanusa
©Ian Sommerville 2000 CS 365 Critical Systems Validation Slide 40
Fault tree for software hazards
Incorrectsugar levelmeasured
Incorrectinsulin doseadministered
or
Correct dosedelivered atwrong time
Sensorfailure
or
Sugarcomputation
error
Timerfailure
Pump signalsincorrect
or
Insulincomputation
incorrect
Deliverysystemfailure
Arithmeticerror
or
Algorithmerror
Arithmeticerror
or
Algorithmerror
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 reachedo Show that this is contradicted by the program code
Insulin delivery system1. Safe state is a shutdown state where no insulin is delivered
a. If hazard arises,shutting down the system will prevent an accident2. Software may be included to detect and prevent hazards such as power failure3. 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
testing dan implementasi sistem//STMIK Jayanusa
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 necessaryif (previousDose == 0) // if statement 1{
if (currentDose > 16)currentDose = 16 ;
}else
if (currentDose > (previousDose * 2) )currentDose = previousDose * 2 ;
if ( currentDose < minimumDose ) // if statement 2currentDose = 0 ; // then branch
else if ( currentDose > maxDose ) // else branchcurrentDose = maxDose ;
administerInsulin (currentDose) ;
©Ian Sommerville 2000 CS 365 Critical Systems Validation Slide 46
Informal safety proof
Insulin_dose = 0
Insulin_dose := 0
if statement 2then partexecuted
Insulin_dose =Maximum_dose
Insulin_dose :=Maximum_dose
if statement 2elsif partexecuted
if statement 2not executed
Insulin_dose >= Minimum_dose andInsulin_dose <= Maximum_dose
or
Insulin_dose >Maximum_dose
Administerinsulin
Contradiction
Contradiction Contradiction
Pre-conditionfor unsafe state
Overdoseadministered
See Portrait slide
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
testing dan implementasi sistem//STMIK Jayanusa
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.maxDoseif (InsulinPump.currentDose > InsulinPump.maxDose)
throw new SafetyException (Pump.doseHigh);else
for (int i=1; i<= increments; i++){
generateSignal () ;if (i > maxIncrements)
throw new SafetyException ( Pump.incorrectIncrements);
} // for loop} //administerInsulin
testing dan implementasi sistem//STMIK Jayanusa