*Pengembangan SistemSoftware DevelopmentPengembangan Sistem AplikasiPendekatan Tradisional

oleh Retantyo W

SDLCSystem Development Life Cycle)proses pembuatan dan pengubahan sistem serta model dan metodologi yang digunakan untuk mengembangkan sistem.*

Waterfall*

*Fase-fase dalam SDLC (3 fase)Fase Definisi:analisis kelayakan (feasibility analysis)definisi kebutuhan (requirement definition)Fase Kontruksi/Pengembangan:desain sistemmembangun sistempengujian sistemFase Implementasi:InstalasiOperasional & Maintenance

*Analysis KelayakanYang dianalisis:kemungkinan pengurangan biayakeuntungan yang mungkin diraihkesuksesan bisnisestimasi waktu dan jadwalkelayakan terhadap kemampuan teknis organisasi

*Analysis Kelayakan (lanjutan)dengan memperhatikan:apa yang akan dikerjakan oleh sistemoutput apa yang akan dihasilkanbagaimana data input akan diperolehdata yang akan diperlukankecepatan sistem tersebut untuk menghasilkan output

*Definisi Kebutuhan (Requirement Analysis)Inti pada tahapan ini adalah mendefinisikan kebutuhan, yaitu apa yang akan dilakukan oleh sistem, secara akurat dan lengkap

*Rancangan Sistem (System Design)Rancangan sistem melibatkan:penentuan hardware dan softwareperancangan isi dan struktur basisdatapendefinisian modul-modul proses (prosedure) yang menyusun sistempenentuan bagaimana modul-modul tersebut saling berhubungan

*Membangun dan Pengujian Sistem (Building & Testing Systems)Aktifitas dalam membangun sistem:membuat program komputerrancangan rinci sistem basisdatakonfigurasi hardwaresoftware untuk sistemSistem OperasiDatabase Management SystemBahasa pemrograman

*Membangun dan Pengujian Sistem (Building & Testing Systems) lanjutanPengujiansetiap modul setiap kali dihasilkankeseluruhan sistem jika sudah lengkapPengujian 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 tsbSayangnya, data pada sistem yang lama mungkin: tidak akurat, tidak lengkap, atau tidak kompatibel

*Instalasi Sistem (Installing the System) lanjutanDapat menimbulkan tugas yang bervolume tinggi dan juga mungkin sukarterutama apabila harus terus melanjutkan sistem lama selama pengkonversian sistem baruBagian paling krusial dalam instalasi sistem adalah:mentraining orangmemotivasi mereka untuk merubah pola kebiasaan dalam menggunakannya dengan baik

*Instalasi Sistem (Installing the System) lanjutanBeberapa strategi konversi yang mungkin dapat dilakukan:strategi paralel: jalan bersama untuk beberapa waktustrategi pilot: menjalankan di beberapa bagianstrategi berfase: bertahap menerapkanstrategi Cold Turkey: langsung menghentikan total sistem lama

*

*Operasional dan MaintenanceSetelah segala usaha dan waktu digunakan untuk proses pengembangan sistem, diharapkan sistem yang baru akan berope-rasi dengan panjang dan bermanfaatMaintenans merupakan proses modifikasi sistem untuk mengadaptasi perubahan kebutuhan organisasi

Kasus yg biasa muncul saat maintenance :Modifikasi sistemBerpedoman (interfacing) ke sistem lainPerubahan hak akses sistemPenanganan terhadap fasilitas pada sistem yg rusakPerlu adanya dokumentasi yg baik serta transfer of knowledge dari pembuat sistem ke SDM perusahaan untuk menjamin terkelolanya proses pemeliharaan sistem.

*

*Pendekatan alternatifPengembangan sistem menggunakan metodologi evolusi yang didasarkan pada prototypingPembelian paket softwarepengembangan sistem bersumber diluar

*Pendekatan Evolusi (prototyping)Prototyping

Step 1Kebutuhan sistem dasarStep 2Kembangkan prototipe awalStep 3Gunakan prototipe dan catat perubahan yang diinginkanStep 4Perbaiki prototipe sesuai dengan yang diinginkanUser Ok

*Pendekatan evolusi lanjutanPrototipe sbg metodologi pengembangan

*Pendekatan evolusi lanjutanStep 5: Evaluasi sebagai sistem operasionalStep 6: Buat modifikasi seperlunyaStep 7: Install, operasikan, dan evolve1

*Pendekatan evolusi lanjutanPrototipe dalam SDLCStep 1: Analisis KelayakanStep 2: Prototipe pedefinisian kebutuhanStep 3: Desain SistemStep 4: Membangun SistemStep 5: Pengujian SistemStep 6: Instalasi SistemStep 7: Operasi & Maintenans

Verification & Validationoleh Retantyo W*

oleh Retantyo W

Verification and ValidationUntuk menjamin bahwa software yang dibangun sesuai dengan kebutuhan user

Verification: Apakah kita membangun produk dengan benar"PL Harus seusia dengan spesifikasinyaValidation: Apakah kita membangun produk yang benarPL harus sesuai dengan harapan klienVerification vs validation

Software inspections (inspeksi PL). Menganalisa dan memeriksa representasi sistem spt dokumen persyaratan, diagram rancangan dan kode sumber program (static verification) tidak menuntut program dieksekusi

Static and dynamic verification

Software testing (pengujian PL)Melibatkan eksekusi implementasi PL dgn data uji, memeriksa output dan prilaku kerja (dynamic verification)Menggunakan data uji memeriksa PL apakah berlaku seperti yang dibutuhkan

Static and dynamic verification

Static dan dynamic V&VSV dapat digunakan pada semua tahap proses PL, sementara DV hanya bisa dilakukan jika ada program atau prototype

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

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 errorTidak dapat memeriksa karakterstik non fungsional PL spt kinerja & keandalannyaStatic Verification

Masih mendominasiMenggunakan data riilSebuah testing yg baik/sukses adalah yg mampu menemukan satu atau lebih errorKekurangan & ketidaksesuaian disimpulkan dengan melihat outputPengujian PL

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 programMenemukan ke-tidakkonsisten-an antara program dengan spesifikasinyaType pengujian

Statistical testingUji dirancang untuk menunjukkan input user yg sebenarnya dan frekuensinya.Untuk menguji kinerja dan keandalan program dan memeriksa bagaimana kerjanya pd kondisi operasional

Type pengujian

Tujuan akhir V& V Menanamkan kepercayaan bahwa sistem PL siap untuk tujuannyaTidak berarti bahwa program harus benar-benar bebas dari cacatMelainkan : Ini berarti bahwa sistem harus cukup baik untuk tujuannya.Tingkat kepercayaan bergantung pada tujuan sistem, harapan user dan lingkungan pemasaran sistem pd saat itu

V & V confidence (Tingkat Kepercayaan V & V)Tergantung pada tujuan sistem, harapan user dan lingkungan pemasaran pada saat ituSoftware functionBergantung pada seberapa kritis PL tsb bagi organisasiUser expectationsBanyak User memiliki harapan yang rendah dari PL mrk & tidak terkejut saat PL tsb gagal saat dipakaiMarketing environmentMelemparkan produk ke pasaran lebih penting dari pada menemukan kesalahan terlebih dahulu

Pengujian (V&V) dan debuging adalah sebuah proses yang berbeda (terpisah)V &V adalah proses yg meyakinkan adanya cacat pada sistem PLDebugging adalah proses untuk menemukan dan membetulkan adanya cacat iniDebugging termasuk mencari pola output uji tentang prilaku sistem dan selanjutnya menguji pola ini untuk menemukan kesalahan sistemTesting dan debugging

Proses Debug

Diperlukan perrencanaan yang hati-hati utk mendapatkan keuntungan maksimum dari kegiatan inspeksi dan pengujian PLPerencanaan V & V harus dimulai dari awal proses pengembanganPerencanaan harus memutuskan keseimbangan antara verifikasi statis dan verifikasi dinamisTest planning berhubungan dengan penentuan standar untuk proses pengujian dan bukan mendeskripsikan uji produkPerencanaan V & V

The V-model of development

Struktur Rencana Uji Perangkat LunakProses pengujian deskripsi tahap utama proses pengujianKemamputelusuran persyaratan user paling tertarik dgn apakah sistem memenuhi pesyaratanItem yang di uji hrs dispesifikasiJadwal Pengujian sehub dgn jadwal pengembangan secara umumProsedur Pencatatan Ujiansistematis Persyaratan PL & PK sesuai kebutuhanBatasan sdm/staf

Software inspections (inspeksi PL)Pengujian program yg sistematis membutuhkan sejumlah besar uji yg akan dikembangkan, dieksekusi dan diperiksa.Tidak menuntut program dieksekusi. Shg dapat digunakan sbg teknik verifikasi sebelum implementasiDapat diterapkan disetiap tahapan (requirements, design, test data, dll.)Teknik yg efektif utk mendeteksi error

Mengapa inspeksi lebih efektif dibanding pengujianBanyak cacat yg berbeda dapat dideteksi pada satu sesi inspeksi. Satu cacat dapat menyebabkan program crash atau mempengaruhi gejala cacat program lainAdanya pemakaian ulang domain dan pengetahuan bhs pemrograman. Intinya para peninjau mungkin telah melihat jenis eror yg umum terjadi pada suatu bhs pemrograman terentu dan pada jenis aplikasi tertentu.

Inspeksi dan PengujianInspections dan pengujian saling melengkapi, tidak berarti inspeksi harus sepenuhnya menggantikan pengujian sistemInspeksi sebagai proses verifikasi awal untuk menemukan sebagian besar cacat programInspeksi dan pengujian tetap harus digunakan selama proses V & VInspections 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 ProgramProses formal yg dilakukan oleh tim kecilFokus pada deteksi kesalahan bukan koreksiCacat dapat berupa logical errors, penyimpangan kode yg menunjukkan adanya kondisi eror (cth, variabel yg tidak terinisialisasi) atau ketidaksesuaian dengan standard organisasi atau proyek

Inspection pre-conditionsSebelum inspeksi program dimulai, adalah penting bahwa: Ada spesifikasi yg pasti mengenai kode yg akan diperiksaAnggota team inspeksi mengenal baik standard organisasiTersedia versi kode yg up to date dan benar secara sintak tidak ada gunanya memeriksa kode yg hampir lengkapDaftar error yg umum harus dipersiapkanManajemen harus menerima kenyataan bahwa proses inspeksi akan menimbulkan peningkatan biaya dalam pembangunan PLManajemen tidak boleh menggunakan proses inspeksi untuk penilaian staf

Proses Inspeksi

Prosedur InspeksiProgram yg akan diinspeksi diserahkan kpd team inspeksiKode dan dokumen terkait didistribusikan dlm tahap peninjauan saat mendeskripsikan apa yg menjadi tujuan programHarus berlangsung relatif singkat (tidak lebih dari 2 jam)Tim tidak boleh menyarankan bgm cacat harus diperbaikiSetelah inspeksi, program diubah oleh pembuatnya utk membetulkan masalah yg ditemukanInspeksi ulang tidak mutlak harus dilakukan

Team InspeksiTim paling sedikit terdiri dari 4 orangPembuat program adalah org yg bertanggung jawab menghasilkan program yg akan di inspeksi Inspector adalah orang yg menemukan error, hal-hal yg tidak terdeteksi dan ketidak konsistenan pd program Reader (pembaca) adalah oarng yg menguraikan program dgn kata-katanya sendiri dlm rapat inspeksiModerator adalah org yg menangani proses & memfasilitasi inspeksi

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

Inspection checks

Pengukuran Proses Inspeksi500 statement/jam selama peninjauan125 source statement/jam saat persiapan individu90-125 statements/jam saat rapatSehingga Inspeksi adalah proses yang sangat mahal

Analisa statis terotomasiSebuah alat bantu perangkat lunak yang mampu menscan teks sumber programDengan melakukan parsing teks dan selanjutnya mampu mendeteksi kesalahan pada setiap statement.Sangat efektif, namun bukan sebagai untuk pengganti kegiatan inspeksi.cth : dpt mengidentifikasi var yg tidak diinisialisasi, tapi tidak dapat mengidentifikasi inisialisasi yang tidak benar.

Static analysis checks

Tahapan dalam analisis statikAnalisis aliran kontrol. Menandai loop yang memiliki banyak titik masuk dan titik keluar, dan menemukan kode2 yang tidak bisa dicapai (dikelilingi oleh statement goto), dll.Analisis penggunaan data. Mendeteksi var yg digunakan tanpa inisialisasi sebelumnya, variabel yang ditulis dua kali tanpa penentuan nilai diantaranya dan variabel yang dideklarasikan tapi tidak pernah dipakai, dll.Analisis interface. Memeriksa konsistensi deklarasi prosedur dan penggunaannya, atau utk fungsi dan procedure yg dideklarasikan tetapi tidak pernah dipanggil atau digunakan tidak utk java (strongly typed), tetapi utk fortran dan C (weakly typed)

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

LINT static analysis Unix dan Linux utk C 138% more lint_ex.c

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

Artinya terjadi kesalahan dimana sebuah fungsi telah didefenisikan dengan satu parameter, akan tetapi pemanggilan fungsi ini menggunakan 3 parameter. Selanjutnya variabel i dan c dideklarasikan tetapi tidak diberi nilaiDan nilai yang dikembalikan oleh fungsi tidak pernah digunakan

Manfaat analisis statisPada bhs pemrog yg weakly typed seperti C, dapat mendeteksi fungsi yang memiliki jumlah dan jenis argumen yang salah atau error jenis lain yang tidak terdeteksi oleh compilerTidak efekti dari segi biaya utk bhs Java, karena Java termasuk strongly typed, dimana perancang telah membuang beberapa fitur yang rentan terhadap error, semua var hrs diinisialisasikan dan tidak ada statement goto

Salah satu cntoh pengembangan PL yg menghindari cacatIstilah Cleanroom berasal dari unit pabrikasi semikonduktor. Pd unit ini (cleanroom) cacat dihindari dgn pemabrikan pada atmosfir yang ultra-bersihMerupakan filosofi pengembangan PL utk menghindari cacat PL dengan pengembangan proses inspeksi yg sangat telitiCleanroom telah menggantikan pengujian unit komponen sistem dengan inspeksi untuk memeriksa konsistensi komponen dgn spesifikasinya

Pengembangan PL Cleanroom

Karakteristik kunci pengembangan PL dgn model cleanroom :Spesifikasi formalPengembangan inkrementalPL dibagi menjadi inkremen (bagian) dan divalidasi secara terpisah dgn metode cleanroom.Pemrograman terstrukturVerifikasi statis.Pengujian statistik sistem

Proses Pengembangan Cleanroom

Proses Pengembangan Ikremental

Tim Spesifikasi. Bertanggung jawab mengembangkan dan memelihara spesifikasi sistemTim pengembang. Mengembangkan dan verifikasi perangkat lunakTim sertifikasi. Mengembangkan satu set standar uji statistik untuk melatih PL setelah dikembangkanTim yang terlibat

Pengujian Perangkat Lunak*

Pengujian Cacat (Defect Testing)Pengujian program untuk mengungkap adanya cacat pada sistem Perangkat Lunak

PembahasanDefect testing (Pengujian cacat)Integration testing (Pengujian integrasi)Object-oriented testing (Pengujian berbasis objek)Testing workbenches (meja kerja pengujian)

Proses PengujianPengujian KomponenBerhubungan dengan pengujian berfungsinya komponenBiasanya merupakan tanggung jawab programmerTes dilakukan berdasarkan pengalaman programerPengujian IntegrasiMenguji sekumpulan komponen yang terintegrasi sehingga membentuk sebuah sistem atau sub sistemMerupakan tanggung jawab team penguji independentTes dilakukan berdasarkan spesifikasi sistem

Fase Pengujian

I. Pengujian CacatTujuannya adalah untuk mengungkap cacat pada programPengujian yg berhasil adalah pengujian yang menyebabkan sistem berprilaku tidak benar Pengujian ini menunjukkan keberadaan bukan tidak adanya kesalahan programBerlawanan dengan pengujian validasi yang menuntut sistem berlaku benar

Hanya pengujian mendalam dapat menunjukkan suatu program bebas dari cacat. Namun, pengujian lengkap adalah mustahilTes harus fokus pada kemampuan sistem, bukan komponen-komponennyaTesting priorities

The defect testing process

Pengujian cacat terdiri dari :Black-box testingPartisi equivalensiPengujian strukturalPengujian jalur

A. Black-box testingPengujian berdasarkan pada spesifikasi sistemprogram dianggap sebagai sebuah black-box yg prilakunya hanya dapat ditentukan dgn mempelajari input dan output yg berkaitanPerencanaan uji dapat dilakukan di awalDisebut juga pengujian fungsionalitas (bukan implementasi PL)

Black-box testing

B. Partisi EquivalensiData Input dan hasil output biasanya masuk dalam sejumlah kelas yang berbeda namun memiliki karakteristik yang sama. Mis : bil positif, bil negatif, string tanpa blank, dllProgram biasanya berlaku dengan cara yg dapat dibandingkan untuk semua anggota kelasBagitu satu himpunan partisi telah diidentifikasikan, kemudian dipilihlah kasus uji dari setiap partisi ini

Partisi Equivalesi

PE dapat diidentifikasi dengan menggunakan spesifikasi program atau dokumentasi userPartisi Equivalesi

Identifikasikan Himpunan Partisi input dan output ke dalam sebuat bentuk equivalensiMis : Spesifikasi program menyatakan bahwa program menerima 4 sampai 10 input yang 5 digit bilangan bulat antara 10.000 dan 99.999 Partisi equivalensinya adalah 99.999Pilih kasus uji pada batasan dari himpunan tersebut00000, 09999, 10000, 99999, 10001Partisi Ekuivalensi (contoh)

Partisi Equivalensi (cth)

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 elementTFIRST = i

Testing guidelines (sequences)Uji PL dengan deret yang hanya memiliki 1 nilaiGunakan deret yang berbeda dengan ukuran yang berbeda pada uji yang berbedaTurunkan uji sehingga elemen deret yang pertama, tengah dan terakhir diakses

Input dengan elemen kunci adalah anggota deret ( Found = True)Input dengan elemen kunci bukan anggota deret ( Found = False)Dari spesifikasi tersebut, dapat diidentifikasi dua Partisi ekuivalensi :

Search routine - input partitions

Array

Element

Single value

In sequence

Single value

Not in sequence

More than 1 value

First element in sequence

More than 1 value

Last element in sequence

More than 1 value

Middle element in sequence

More than 1 value

Not in sequence

Input sequence (T)

Key (Key)

Output (Found, L)

17

17

true, 1

17

0

false, ??

17, 29, 21, 23

17

true, 1

41, 18, 9, 31, 30, 16, 45

45

true, 7

17, 18, 21, 23, 29, 41, 38

23

true, 4

21, 23, 29, 33, 38

25

false, ??

Disebut juga white-box testingDiturunkan dari pengetahuan struktur dan implementasi PLBiasa diterapkan utk unit program yg relatif kecilPenguji dpt menganalisis kode dan menggunakan pengetahuan mengenai struktur komponen utk menurunkan data ujiPengetahuan mengenai algorithma dpt dipakaiC. Structural testing

White-box testing

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

Berdasarkan kode utk search rutin, binary search melibatkan pembagian ruang searching menjadi 3elemArray[mid]==keyelemArray[mid]keySelanjutnya pengujian dilakukan berdasarkan pengetahuan mengenai algorithma binary search

Binary search equiv. partitions

Binary search - test cases

Input array (T)

Key (Key)

Output (Found, L)

17

17

true, 1

17

0

false, ??

17, 21, 23, 29

17

true, 1

9, 16, 18, 30, 31, 41, 45

45

true, 7

17, 18, 21, 23, 29, 38, 41

23

true, 4

17, 18, 21, 23, 29, 33, 38

21

true, 3

12, 18, 21, 23, 32

23

true, 4

21, 23, 29, 33, 38

25

false, ??

D. Pengujian JalurBertujuan untuk menguji setiap jalur eksekusi independent melalui komponen atau program paling tidak 1 kali eksekusiTitik awal pengujian jalur merupakan graph alir yang terdiri dari node yg akan mewakili keputusan dan edge (tanda panah) yang menunjukkan aliran kontrol

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 loopDigunakan sebagai dasar perhitungan the cyclomatic complexity (CC)CC = Jumlah tanda panah jumlah node +2Graf alir program

Binary search flow graphEdge = 11Node = 9CC = 11-9+2 =4

1, 2, 3, 8, 91, 2, 3, 4, 6, 7, 21, 2, 3, 4, 5, 7, 21, 2, 3, 4, 6, 7, 2, 8, 9Independent paths

Hitung nilai CC graph alir disamping ini, serta jalur independen yg ada*Edge=9, node=8Cc=9-8+2=3a: 1,2,3,5,6,8b: 1,2,4,5,7,8c: 1,2,3,5,7,8d:

II. Pengujian IntegrasiPengujian terhadap sistem yang telah lengkap ( terintegrasi dari beberapa komponen)Pengujian integrasi menjadi black-box testing dengan menurunkan uji dari spesifikasi sistemKesulitan utama adalah lokalisasi error yang ditemukanSolusi Pengujian inkremental

Yaitu dgn mengintegrasi konfigurasi sistem minimal dan menguji sistem iniKemudian tambahkan komponen pada pada konfigurasi minimal dan mengujinya setelah inkremen ditambahkan

Incremental integration testing

a. Pengujian Top-down dan Bottom-upTop-down testing (Pengujian top-down)Dimulai dr komponen sistem tingkat tinggi, diintegrasikan dan diuji sebelum perancangan dan implementasinya selesaiBottom-up testing (Pengujian bottom-up)Komponen tingkat rendah diintegrasikan dan diuji sebelum komponen tingkat yang lebih tinggi dikembangkanDalam prakteknya, kedua strategi ini sering dikombinasikan

Top-down testing

Bottom-up testing

Perbandingan metode top-down dan bottom-upValidasi ArsitekturalTop-down lebih memungkinkan menemukan error pada arsitektur sistemDemonstrasi sistemDgn Top-down sistem yg dapat dipakai dan terbatas tersedia pada tahap awal pengembanganImplementasi ujiLebih mudah diimplementasikan dengan bottom-upPengamatan ujiBermasalah utk keduanya.

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

Dilakukan saat sub sistem diintegrasi utk membuat sistem yang lebih besarTujuannya utk mendeteksi kesalahan yg mungkin telah masuk ke dalam sistem karena error interface atau asumsi valid mengenai interfaceSangat penting untuk pengembangan berorientasi objek terutama saat objek dan kelas dipakai ulangb.Pengujian Interface

Interface testingPengujian bukan terhadap komponen, tetapi terhadap subsistem yg terbuat dari gabungan komponen

Jenis InterfaceParameter interfaces (interface parameter)Interface tempat data yg dikirim dari procedure (komponen) ke komponen lainShared memory interfaces (interface memory bagi pemakai)Interface dgn satu blok memory dipakai bersama antar sub sistem

Jenis InterfaceProcedural interfaces (Interface procedural)Interface dgn satu sub sistem mengencapsulasi satu set prosedur yg dapat dipanggil oleh sub sistem lainMessage passing interfaces Interface tempat satu sub sistem meminta layanan dari satu sub sistem lain dengan mengirimkan message kepadanya

Error InterfaceSalah satu bentuk error paling umum pd sistem komplek.Penyalahgunaan InterfaceKomponen pemanggil memanggil komponen lain dan melakukan error dalam penggunaan interfacenya. Mis urutan dan jml pengiriman yg salahKesalahpahaman InterfaceKomponen pemanggil salah memahami spesifikasi interface komponen yg dipanggil. Mis rutin search biner dipanggil dgn aaray yg tidak urut, shg search akan gagal

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

Panduan Umum Pengujian InterfaceRancang satu set uji dengan nilai parameter ke komponen eksternal.Selalu uji interface dgn parameter pointer nullRancang uji yg akan mengakibatkan komponen gagalGunakan pengujian stress dlm sistem message passingDalam sharing memory rancang uji yg mengubah-ubah urutan aktivasi komponen

c. Pengujian StressMelanjutkan 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 prosesorMisalnya :sistem pengolahan transaksi dpt dirancang utk memproses sampai 100 transaksi per detik. Kemudian dilakukan uji stress sampai melewati angka tsb sampai sistem gagalOS dirancang utk menangani sampai 200 terminal yg terpisah

Komponen yg akan diuji adalah class object yang telah diinisialisasikan sebagai objekObjek sbg komponen individu seringkali lebih besar dari fungsi tunggalIII. Pengujian berorientasi object

Tingkat pengujian pada PBOPengujian operasi individual yg berhubungan dgn objek fungsi atau procedure (dgn blck-box atau white-box testing)Pengujian kelas objek individuPengujian kelompok objekPengujian sistem berorientasi objek

Pengujian Kelas ObjectSaat menguji objek liputan uji yg lengkap harus mencakupPengujian semua operasi yg berhubungan dgn objek Setting dan integrasi semua attribut yg berhub dgn objek tsbMelatih objek dgn semua status yg mungkinPenggunaan konsep inheriten mengakibatkan perancangan uji kelas objek menjadi lebih sulitKarena semua sub class harus diuji dgn semua operasi yg diwarisi.

d. Pengujian WorkbenchesPengujian adalah fase proses yang mahal. Shg banyak alat bantu pengujian dikembangkan untuk memperkecil biaya proses pengujianPengujian Workbenches (meja kerja) mengintegrasikanberbagai alat pengujian untuk mengurangi waktu pengujian

A testing workbench

SISTEM KRITIS

oleh Retantyo W

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

Ada 3 tipe utama sistem kritisSistem kritis dalam hal keselamatanSistem yang kegagalannya dapat mengakibatkan cedera, kematian atau kerusakan lingkungan. Contoh : sistem kendali untuk pabrik kimiaSistem kritis dalam hal misiKegagalannya dapat mengakibatkan kegagalan pada suatu kegiatan yang diarahkan pada suatu tujuan. Contoh : Sistem navigasi pesawat udaraSistem kritis dalam hal bisnisKegagalannya dapat mengakibatkan kegagalan pada bisnis yang menggunakan sistem tersebut. Contoh : Sistem rekening nasabah pada sebuah bank

Biaya Kegagalan SistemLangsungKarena sistem harus digantiTidak langsungBiaya proses pengadilanKerugian bisnis yang terjadi karena sistem tidak tersedia

Komponen sistem yang rentan terhadap kegagalan Hardware: disebabkan karena :Kesalahan dalam perancanganKomponen rusak karena kesalahan manufakturKomponen telah mencapai akhir masa pakaiSoftware : karena kesalahan dalam perincian, perancangan, atau implementasiOperator sistem : gagal menjalankan sistem dengan benar

Dependabilitas Sistem KritisDependabilitasProperti dari sistemSama 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 saatKeandalan (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 sistemKeamanan (Security)Penilaian pada seberapa besar kemungkinan sistem dapat bertahan terhadap campur tangan yang disengaja atau tidak disengaja

Contoh: sistem penyaluran insulin untuk mengontrol diabetes : Sistem otomatisMemonitor tingkat gula darah dan menyalurkan dosis insulin saat dibutuhkanBekerja dengan sensor mikro yang terpasang dalam tubuh pasien

Ada 3 dimensi dependabilitas yg berlakuKetersediaan :Sistem hrs tersedia untuk memberikan insulin saat dibutuhkanKeandalan :Sistem hrs bekerja andal dan mengalirkan jumlah insulin yang tepatKeselamatan :Kegagalan sistem dapat mengakibatkan pemberian dosis yg berlebihan shg mengancam hidup pasien

KETERSEDIAAN & KEANDALANKeandalan mencakup ketersediaanKrn jika suatu layanan yg telah ditentukan tidak diberikan, maka sistem tidak akan berjalan sebagaimana mestinyaNamun 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 BTetapi 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 kesalahanPengujian dan debug sistemToleransi kesalahanMenjamin bahwa kesalahan sistem tidak menghasilkan eror atau menjamin bahwa eror sistem tidak mngakibatkan kegagalan

Tidak semua kesalahan PL memiliki kemungkinan yang sama untuk mengakibatkan kegagalan PLSebuah program mungkin mengandung kesalahan yg diketahui namun tetap dapat diandalkan oleh usernyaUser yg berpengalaman seringkali berputar menghindari kesalahan PL yg diketahui akan menyebabkan kegagalan.

KESELAMATANYaitu 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

Keselamatan

PL lunak yg kritis dalam hal keselamatan terbagi atas :PL kritis keselamatan primerPL yg menyatu sbg kontroler pada sistemMalfungsi PL menyebabkan malfungsi PK Menyebabkan cedera pada manusia atau kerusakan pada lingkungan

PL kritis keselamatan sekunderPL yg secara tidak langsung dapat menimbulkan cederaCth : 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 Spesifikasi mungkin tidak lengkapTingkat persentase malfungsi sistem yg tinggi merupakan akibat dari eror spesifikasi, bukan eror perancangan.Malfungsi perangkat kerasShg menyebabkan PL menghasilkan suatu lingkungan yg tidak dapat diantisipasiOperator sistem

Ada 3 hal yg perlu dilakukan utk menjamin bahwa kecelakaan tidak akan terjadi atau bahwa konsekuensi kecelakaan akan minimal, yaitu :Menghindari bahayaDeteksi dan membuang bahayaCth : sistem pabrik pengolahan bahan kimia yg dpt mendeteksi tekanan yg berlebihan dan akan membuka sebuah katup untuk mengurangi tekanan ini.Membatasi kerusakanDgn menyertakan fitur proteksi yg akan meminimalisasi kerusakancth : pemadam api otomatis, sebelum melukai penumpang dan awak pesawat

KEAMANANYaitu 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 sistemCth 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 :Penolakan layananSehingga layanan normal sistem tidak tersediaKorupsi program atau dataKarena perubahan komponen PLPenyingkapan informasi rahasia

Keamanan semakin penting dgn beragamnya sistem yg terhubung dgn internetAtribut yg yg terpenting utk utk sistem berbasis internet adalah kemampuan bertahanYaitu kemampuan sistem untuk terus meberikan layanan pada saat diserang atau pada saat sebagian sistem telah dilumpuhkan.

Spesifikasi keandalan PLPerlunya dependibilitas pd sistem kritis menimbukan :Persyaratan fungsionalDibuat utk mendefenisikan pemeriksaan eror dan fasilitas pemulihan serta fitur2 yg memberikan proteksi thd kegagalan sistemPersyaratan non-fungsionalUntuk 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)

SPESIFIKASI SISTEM KRITISKarena 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

Ada 3 dimensi ketika menspesifikasikan keandalan sistem secara menyeluruh :Keandalan PKKeandalan PLKeandalan operatorKegagalan PK dpt menyebabkan sinyal palsu yg berada diluar kisaran inputShg PL dp berprilaku spt yg tidak diharapkanPrilaku sistem yg tidak diharapkan dpt membingungkan operator dan mengakibatkan stres operatorEror operator sangat mungkin terjadi dalam kondisi stres, shg akan memberikan input yg tidak benar.

Spesifikasi keselamatan PLOperasi yg selamat mrpk karakteristik yg dibutuhkan pada sistem PL yg berhubungan dgn keselamatanSetiap bahaya harus dinilai terhadap resiko yg dimilikiSelanjutnya mendeskripsikan bagaimana PL harus berprilaku utk meminimalisasi resiko atau mempersyratkan bahwa bahaya tidak boleh terjadi

Analisa biaya dan resikoTujuannya 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, dllAnalisis resiko dan klasifikasi biayaPenguraian bahaya penyebabPenilaian reduksi resiko

Analisa Pohon kesalahanPohon kesalahan yg dapat diidentifikasi utk bahaya yg memungkin muncul yg berhubungan dgn PL pada sistem penyaluran insulin

Pengurangan resiko :Penghindaran bahayaSistem dirancang shg bahaya tidak munculDeteksi dan pembuangan bahayaSistem dirancang shg bahaya terdeteksi dan dinetralisasi sebelum menimbulkan kecelakaanPembatasan kerusakanSistem dirancang shg konsekuensi kecelakaan diminimalisasi

Spesifikasi KeamananTahap proses spesifikasi keamanan :Identifikasi dan evaluasi aset (data dan program)Analisis ancaman dan penilaian resikoPenggolongan ancamanAnalisis teknologi

PENGEMBANGAN SISTEM KRITISAda 2 pendekatan komplementer yg dapat dipakai jika tujuannya adalah mengembangkan PL yg dapat diandalkan :Penghindaran kesalahanMeminimalisasi eror manusia dan membantu menemukan kesalahan sistem sebelum sistem dipakaiToleransi kesalahanSistem hrs dirancang sedemikian rupa shg kesalahan selama eksekusi akan terdeteksi dan tertangani.

Toleransi kesalahan

Minimalisasi KesalahanPL yg bebas dr kesalahan adalah PL yg dgn tepat mengikuti spesifikasinya.

Namun PL yg bebas dr kesalahan belum tentu bebas dari kerusakan

Persyaratan utk pengembangan PL yg bebas dr kesalahan Harus ada spesifikasi sistem yg tepatOrganisasi yg mengembangkan sistem hrs memiliki kultur kualitas organisasiHrs digunakan pendekatan perancangan dan implementasi PL yg berdasarkan penyembunyian informasi dan enkapsulasiGunakan bhs pemrograman yg strongly-typed (dpt mendeteksi kesalahan lebih banyak oleh kompilator)Menghindari penulisan yg potensial rentan thd erorProses pengembangan hrs didefenisikan. Manajer kualitas hrs memeriksa kesesuaian proses

Penghindaran ErrorStetement goto merupakan konstruksi pemrograman yg secara bawaan rentan thd erorPemrograman terstruktur berarti :pemrograman tanpa penggunaan statement goto Hanya menggunakan loop while dan statement if sebagai konstruksi kontrolPemrog terstruktur mrpk batu loncatan yg penting bagi pengembangan RPL

Penyembunyian InformasiKomponen2 program 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.

Lebih dari 50% biaya pengembangan total utk sistem PL kritis agar kegagalan sistem yg mahal terhindariContoh : 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.

Toleransi KesalahanTujuannya utk menjamin bahwa kesalahan sistem tidak mengakibatkan kegagalan sistemDiperlukan pada situasi dimana kegagalan sistem dapat menyebabkan kecelakaan hebat Atau kerugian operasi sistem akan menyebabkan kerugian ekonomi yg besarBebas kesalahan tidak berarti bebas kegagalan

Aspek toleransi kesalahan :Deteksi kesalahanPenilaian kerusakanPemulihan kerusakan status amanPerbaikan kesalahan

VALIDASI SISTEM KRITISProses V&V harus mendemonstrasikan bahwa sistem memenuhi spesifikasinya dan bahwa layanan dan prilaku sistem mendukung persyaratan klienShg diperlukan penambahan analisis dan pengujian normal, karena :Biaya kegagalan jauh lebih besar dr pd sistem non-kritisValidasi atribut tingkat dependabilitas meyakinkan user

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

Validation perspectivesValidasi Reliability/keandalanApakah keandalan sistem telah sesuai dengan spesifikasinya?Apakah keandalan sistem telah memberikan kepuasan pada user pemakai sistem?Validasi Safety/keselamatanMenjamin bahwa kecelakaan tidak akan terjadi atau bahwa konsekuensi kecelakaan akan minimal.

Validation perspectivesValidasi Security/keamananApakah sistem dan datanya aman terhadap serangan external?

Tekhnik ValidasiStatic techniquesReview terhadap disain /inspeksi programDynamic techniquesPengujian StatistikPengujian berbasis skenarioPemeriksaan Run-time

Tekhnik ValidasiProcess validationDesain proses pembangunan yang meminimalkan kemungkinan kesalahan dari proses sesuai dgn dependibilitas sistem (keandalan, ketersediaan, keselamatan dan keamanan)

Teknik Validasi StatikValidasi Static 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 validationMenunjukkan keselamatan sistem melalui sebuah pengujian merupakan sesuatu yg sulitKarena pengujian bertujuan utk menunjukkan apa yg dilakukan sistem saat situasi normal. Tidak mungkin dilakukan pengujian thd setiap kondisi operasional

Safety reviewsPeninjauan thd Review utk kebenaran functionPeninjauan thd maintainable, understandable structurePeninjauan thd algorithma dan disain struktur data berdasarkan spesifikasiPeninjauan thd konsistensi kode dgn algorithma dan disain struktur dataPeninjauan thd kelayakan sistem pengujian

Buatlah software sesederhana mungkinGunakan teknik yg sederhana dlm pencegahan error seperti menghindari pemakaian pointers and recursionGunakan information hiding (penyembunyian inf) agar inf yg dsembunyikan tidak dirusak oleh komponen program yg tidak seharusnya menggunakannyaGunakan teknik toleransi kesalahan yg sesuai , namun jangan pernah berfikir bahwa hasilnya benar-benar amanReview guidance

Hazard-driven analysisEfektif atau tidaknya jaminan keselamatan bergantung pada identifikasi bahayaKeselamatan dapat dijamin melaluiMenghindari bahaya sistem pemotongan yg menuntut operator agar menekan 2 tombol terpisahDeteksi dan membuang bahaya deteksi tekanan berlebihan dan pembukaan katup sebelum meledak pd pabrik kimiaMembatasi kerusakan pemadam api otomatis

Hazard-driven analysisSafety review (ulasan keselamatan) harus menunjukkan bahwa satu atau lebih teknik ini telah diterapkan untuk semua bahaya yg telah diidentifikasi

***********