pengembangan sistem - adekyanna's blog | modul kuliah · web viewindependent assessment...

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


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


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


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


» Melemparkan produk ke pasaran lebih penting dari pada menemukan kesalahan terlebih dahulu

Testing dan debugging Pengujian (V&V) dan debuging adalah sebuah proses

yang berbeda (terpisah) V &V adalah proses yg meyakinkan adanya cacat pada

sistem PL Debugging adalah proses untuk menemukan dan

membetulkan adanya cacat ini Debugging termasuk mencari pola output uji tentang

prilaku sistem dan selanjutnya menguji pola ini untuk menemukan kesalahan sistem


Proses Debug

Temukan 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



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


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


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


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.


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



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


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



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


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


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


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


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)


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


Partisi Equivalesi

System

Outputs

Invalid inputs Valid inputs

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


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


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)


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


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


White-box testing

Componentcode

Testoutputs

Test data

DerivesTests


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



Binary search equiv. partitions

Mid-point

Elements < Mid Elements > Mid

Equivalence class boundaries


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


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



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


Top-down testing

Level 2Level 2Level 2Level 2

Level 1 Level 1Testingsequence

Level 2stubs

Level 3stubs

. . .



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


Interface testingTestcases

BA

C

Pengujian bukan terhadap komponen, tetapi terhadap subsistem yg terbuat dari gabungan komponen


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


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


- 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


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


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 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 :


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


• 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


• 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


• 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/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


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


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


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


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


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


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


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


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



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


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


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



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


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


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


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


pengembangan sistem - adekyanna's blog | modul kuliah · web viewindependent assessment...

Documents