Pengembangan Sistem Aplikasi Pendekatan Tradisional Software Development Pengembangan Sistem Aplikasi Pendekatan Tradisional

SDLC System Development Life Cycle) proses pembuatan dan pengubahan sistem serta model dan metodologi yang digunakan untuk mengembangkan sistem-sistem tersebut

Waterfall

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

Analysis Kelayakan Yang dianalisis: kemungkinan pengurangan biaya keuntungan yang mungkin diraih kesuksesan bisnis estimasi waktu dan jadwal kelayakan terhadap kemampuan teknis organisasi

Analysis Kelayakan (lanjutan) dengan memperhatikan: apa yang akan dikerjakan oleh sistem output apa yang akan dihasilkan bagaimana data input akan diperoleh data yang akan diperlukan kecepatan sistem tersebut untuk menghasilkan output

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

Rancangan Sistem (System Design) Rancangan sistem melibatkan: penentuan hardware dan software perancangan isi dan struktur basisdata 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 basisdata konfigurasi hardware software untuk sistem Sistem Operasi Database Management System Bahasa pemrograman

Membangun dan Pengujian Sistem (Building & Testing Systems) lanjutan 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

Instalasi Sistem (Installing the System) lanjutan 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 mereka untuk merubah pola kebiasaan dalam menggunakannya dengan baik

Instalasi Sistem (Installing the System) lanjutan 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

Paralel Pilot Bertahap Cold Turkey

Operasional dan Maintenance Setelah segala usaha dan waktu digunakan untuk proses pengembangan sistem, diharapkan sistem yang baru akan berope-rasi dengan panjang dan bermanfaat Maintenans merupakan proses modifikasi sistem untuk mengadaptasi perubahan kebutuhan organisasi

Kasus yg biasa muncul saat maintenance : Modifikasi sistem Berpedoman (interfacing) ke sistem lain Perubahan hak akses sistem Penanganan terhadap fasilitas pada sistem yg rusak Perlu adanya dokumentasi yg baik serta transfer of knowledge dari pembuat sistem ke SDM perusahaan untuk menjamin terkelolanya proses pemeliharaan sistem.

Pendekatan alternatif Pengembangan sistem menggunakan metodologi evolusi yang didasarkan pada prototyping Pembelian paket software pengembangan sistem bersumber diluar

Pendekatan Evolusi (prototyping) Step 1 Kebutuhan sistem dasar Step 2 Kembangkan prototipe awal Step 3 Gunakan prototipe dan catat perubahan yang diinginkan User Ok Step 4 Perbaiki prototipe sesuai dengan yang diinginkan

Pendekatan evolusi lanjutan Prototipe sbg metodologi pengembangan Step 1: Kebutuhan sistem dasar Step 2: Kembangkan prototipe awal Step 3: Gunakan prototipe dan catat perubahan yang diinginkan Step 4: Perbaiki prototipe 1 User Ok

Pendekatan evolusi lanjutan 1 Step 5: Evaluasi sebagai sistem operasional Step 6: Buat modifikasi seperlunya Step 7: Install, operasikan, dan evolve

Pendekatan evolusi lanjutan Prototipe dalam SDLC Pendekatan evolusi lanjutan 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

Verification & Validation oleh Retantyo W

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

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

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

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

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

Static Verification Hanya dapat memeriksa hubungan antar program & spesifikasinya tanpa dpt menunjukkan bahwa PL bermanfaat secara operasional Sebuah testing yg baik/sukses adalah yg mampu menemukan satu atau lebih error Tidak dapat memeriksa karakterstik non fungsional PL spt kinerja & keandalannya

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

Type pengujian Defect testing (pengujian cacat) Untuk mengungkapkan adanya cacat pada sistem, bukan untuk simulasi penggunaan. Uji cacat yg sukses adalah uji yg menyebabkan sistem berlaku tidak benar shg mengungkapkan adanya cacat pd PL. Menunjukkan keberadaan kesalahan, bukan tidak adanya kesalahan program Menemukan ke-tidakkonsisten-an antara program dengan spesifikasinya

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

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

V & V confidence (Tingkat Kepercayaan V & V) Tergantung pada tujuan sistem, harapan user dan lingkungan pemasaran pada saat itu Software function Bergantung pada seberapa kritis PL tsb bagi organisasi User expectations Banyak User memiliki harapan yang rendah dari PL mrk & tidak terkejut saat PL tsb gagal saat dipakai Marketing environment Melemparkan produk ke pasaran lebih penting dari pada menemukan kesalahan terlebih dahulu

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

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

Perencanaan V & V Diperlukan perrencanaan yang hati-hati utk mendapatkan keuntungan maksimum dari kegiatan inspeksi dan pengujian PL Perencanaan V & V harus dimulai dari awal proses pengembangan Perencanaan harus memutuskan keseimbangan antara verifikasi statis dan verifikasi dinamis Test planning berhubungan dengan penentuan standar untuk proses pengujian dan bukan mendeskripsikan uji produk

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

Struktur Rencana Uji Perangkat Lunak Proses pengujian deskripsi tahap utama proses pengujian Kemamputelusuran persyaratan user paling tertarik dgn apakah sistem memenuhi pesyaratan Item yang di uji hrs dispesifikasi Jadwal Pengujian sehub dgn jadwal pengembangan secara umum Prosedur Pencatatan Ujiansistematis Persyaratan PL & PK sesuai kebutuhan Batasan sdm/staf

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

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

Inspeksi dan Pengujian Inspections dan pengujian saling melengkapi, tidak berarti inspeksi harus sepenuhnya menggantikan pengujian sistem Inspeksi sebagai proses verifikasi awal untuk menemukan sebagian besar cacat program Inspeksi dan pengujian tetap harus digunakan selama proses V & V Inspections dapat memeriksa kesesuaian dengan spesifikasi, tetapi tidak dapat memvalidasi prilaku dinamik(apakah peralatan PL telah sesuai dengan keinginan user) Inspections tidak dapat mencek karakteristik non fungsional seperti performance, usability dll

Inspeksi Program Proses formal yg dilakukan oleh tim kecil Fokus pada deteksi kesalahan bukan koreksi Cacat dapat berupa logical errors, penyimpangan kode yg menunjukkan adanya kondisi eror (cth, variabel yg tidak terinisialisasi) atau ketidaksesuaian dengan standard organisasi atau proyek

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

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

Prosedur Inspeksi Program yg akan diinspeksi diserahkan kpd team inspeksi Kode dan dokumen terkait didistribusikan dlm tahap peninjauan saat mendeskripsikan apa yg menjadi tujuan program Harus berlangsung relatif singkat (tidak lebih dari 2 jam) Tim tidak boleh menyarankan bgm cacat harus diperbaiki Setelah inspeksi, program diubah oleh pembuatnya utk membetulkan masalah yg ditemukan Inspeksi ulang tidak mutlak harus dilakukan

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

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

Inspection checks

Pengukuran Proses Inspeksi 500 statement/jam selama peninjauan 125 source statement/jam saat persiapan individu 90-125 statements/jam saat rapat Sehingga Inspeksi adalah proses yang sangat mahal

Analisa statis terotomasi Sebuah alat bantu perangkat lunak yang 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 : dpt mengidentifikasi var yg tidak diinisialisasi, tapi tidak dapat mengidentifikasi inisialisasi yang tidak benar.

Static analysis checks

Tahapan dalam analisis statik Analisis aliran kontrol. Menandai 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 Analisa aliran informasi. Mengidentifikasi ketergantungan antara var input dengan var output. Analisis jalur. Mengidentifikasi semua jalur yang mungkin melalui program

LINT static analysis  Unix dan Linux utk C 138% more lint_ex.c #include <stdio.h> printarray (Anarray) int Anarray; { printf(“%d”,Anarray); } main () int Anarray[5]; int i; char c; printarray (Anarray, i, c); printarray (Anarray) ; 139% cc lint_ex.c 140% lint lint_ex.c lint_ex.c(10): warning: c may be used before set lint_ex.c(10): warning: i may be used before set printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(11) printf returns value which is always ignored LINT static analysis  Unix dan Linux utk C 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 nilai Dan nilai yang dikembalikan oleh fungsi tidak pernah digunakan

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

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

Karakteristik kunci pengembangan PL dgn model cleanroom : Spesifikasi formal Pengembangan inkremental PL dibagi menjadi inkremen (bagian) dan divalidasi secara terpisah dgn metode cleanroom. Pemrograman terstruktur Verifikasi statis. Pengujian statistik sistem

Proses Pengembangan Cleanroom Buat program terstruktur Defenisikan inkremen PL Verifikasi kode secara formal Integrasikan inkremen Spesifikasi sistem secara Kembangkan profil operasional Rancang uji statistik Uji sistem terintegrasi Pengerjaan ulang error

Proses Pengembangan Ikremental Spesifikasi formal Kembangkan inkremen PL Tetapkan persyaratan Serahkan PL Spesifikasi yang sudah tetap Permintaan perubahan persyaratant

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

Pengujian Perangkat Lunak

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

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

Proses Pengujian Pengujian Komponen Pengujian Integrasi Berhubungan dengan pengujian berfungsinya komponen Biasanya merupakan tanggung jawab programmer Tes dilakukan berdasarkan pengalaman programer Pengujian Integrasi Menguji sekumpulan komponen yang terintegrasi sehingga membentuk sebuah sistem atau sub sistem Merupakan tanggung jawab team penguji independent Tes dilakukan berdasarkan spesifikasi sistem

Fase Pengujian Pengujian komponen integrasi Pengembang PL Tim penguji independent

I. Pengujian Cacat Tujuannya adalah untuk mengungkap cacat pada program Pengujian yg berhasil adalah pengujian yang menyebabkan sistem berprilaku tidak benar Pengujian ini menunjukkan keberadaan bukan tidak adanya kesalahan program Berlawanan dengan pengujian validasi yang menuntut sistem berlaku benar

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

The defect testing process Rancang kasus uji Siapkan data uji Jalankan prog dgn data uji Bandingkan hasil dgn kasus uji Kasus Uji Data uji Hasil uji Laporan uji s

Pengujian cacat terdiri dari : Black-box testing Partisi equivalensi Pengujian struktural Pengujian jalur

A. Black-box testing Pengujian berdasarkan pada spesifikasi sistem program dianggap sebagai sebuah ‘black-box’ yg prilakunya hanya dapat ditentukan dgn mempelajari input dan output yg berkaitan Perencanaan uji dapat dilakukan di awal Disebut juga pengujian fungsionalitas (bukan implementasi PL)

Black-box testing I n p u t s d a O r l S y m yg menyebabkan prilaku menyimpang Jika output bukan merupakan yang diramalkan, berarti uji tsb telah berhasil mendeteksi masalah dgn PL tsb yg mengungkap adanya cacat

B. 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 Bagitu satu himpunan partisi telah diidentifikasikan, kemudian dipilihlah kasus uji dari setiap partisi ini

Partisi Equivalesi

Partisi Equivalesi PE dapat diidentifikasi dengan menggunakan spesifikasi program atau dokumentasi user

Partisi Ekuivalensi (contoh) Identifikasikan Himpunan Partisi input dan output ke dalam sebuat bentuk equivalensi Mis : Spesifikasi program menyatakan bahwa program menerima 4 sampai 10 input yang 5 digit bilangan bulat antara 10.000 dan 99.999 Partisi equivalensinya adalah <10.000, 10.000-99. 999 dan > 99.999 Pilih kasus uji pada batasan dari himpunan tersebut 00000, 09999, 10000, 99999, 10001

Partisi Equivalensi (cth) Antara 10000dan 999999 Kurang dari 10000 Lebih dari 99999 9 1 5 Nilai input Antara 4 dan 10 Kurang dari 4 Lebih dari 10 3 4 7 Jumlah nilai input

Search routine specification  mencari sederet elemen untuk elemen tertentu (kunci) procedure Search (Key : ELEM ; T: ELEM_ARRAY; Found : in out BOOLEAN; L: in out ELEM_INDEX) ; Pre-condition -- the array has at least one element T’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 and not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key )) kondisi pra menyatakan rutin search dirancang utk bekerja dengan deret kosong  Kondisi pasca menyatakan variabel Found diset jika elemen kunci ada pd deret  Posisi elemen kunci ditunjukkan oleh indeks L dan tidak didefenisikan jika elemen tidak berada dalam deret

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

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

Search routine - input partitions

C. 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 Pengetahuan mengenai algorithma dpt dipakai

White-box testing Kode komponen Output Uji Data Uji Menurunkan Uji

Binary search (Java)

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

Binary search - test cases

D. Pengujian Jalur Bertujuan untuk menguji setiap jalur eksekusi independent melalui komponen atau 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) yang menunjukkan aliran kontrol

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 Edge = 11 Node = 9 CC = 11-9+2 =4 Binary search flow graph

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

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

II. Pengujian Integrasi Pengujian terhadap sistem yang telah lengkap ( terintegrasi dari beberapa komponen) Pengujian integrasi menjadi black-box testing dengan menurunkan uji dari spesifikasi sistem Kesulitan utama adalah lokalisasi error yang ditemukan Solusi  Pengujian inkremental

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

Incremental integration testing

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

Top-down testing

Bottom-up testing

Perbandingan metode top-down dan bottom-up Validasi Arsitektural Top-down lebih memungkinkan menemukan error pada arsitektur sistem Demonstrasi sistem Dgn Top-down sistem yg dapat dipakai dan terbatas tersedia pada tahap awal pengembangan Implementasi uji Lebih mudah diimplementasikan dengan bottom-up Pengamatan uji Bermasalah utk keduanya.

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

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

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

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

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

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

Error Interface Timing errors 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 Dalam sharing memory rancang uji yg mengubah-ubah urutan aktivasi komponen

c. Pengujian Stress Melanjutkan pengujian utk melewati beban rancangan maksimum sistem sampai sistem gagal. Pengujian stres menguji prilaku kegagalan sistem. Sangat penting bahwa kegagalan sistem tidak menyebabkan kerusakan data atau kerugian yg tidak diharapkan dari layanan user

Relevan bagi sistem terdistribusi yg berdasarkan jaringan prosesor Misalnya : sistem pengolahan transaksi dpt 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

III. 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 blck-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 Pengujian semua operasi yg berhubungan dgn objek Setting dan integrasi semua attribut yg berhub dgn objek tsb 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.

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

A testing workbench

SISTEM KRITIS

Defenisi 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 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) Keamanan (Security) 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

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

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 : Ketersediaan : 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 kesalahan 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 : PL kritis keselamatan primer PL yg menyatu sbg kontroler pada sistem Malfungsi PL menyebabkan malfungsi PK Menyebabkan cedera pada manusia atau kerusakan pada lingkungan 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”

Spesifikasi mungkin tidak lengkap Malfungsi perangkat keras Ada beberapa alasan lain mengapa sistem PL yg dapat diandalkan belum tentu menjamin keselamatan Spesifikasi mungkin tidak lengkap Tingkat persentase malfungsi sistem yg tinggi merupakan akibat dari eror spesifikasi, bukan eror perancangan. Malfungsi perangkat keras Shg menyebabkan PL menghasilkan suatu lingkungan yg tidak dapat diantisipasi Operator sistem

Deteksi dan membuang bahaya Ada 3 hal yg perlu dilakukan utk menjamin bahwa kecelakaan tidak akan terjadi atau bahwa konsekuensi kecelakaan akan minimal, yaitu : Menghindari bahaya 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. Membatasi kerusakan Dgn menyertakan fitur proteksi yg akan meminimalisasi kerusakan cth : pemadam api otomatis, sebelum melukai penumpang dan awak pesawat

KEAMANAN Yaitu penilaian sampai sejauh mana sistem melindungi diri dari serangan eksternal yg disengaja atau tidak. Contoh serangan : virus, penggunaan yg tidak syah atas layanan sistem, modifikasi yg tidak diijinkan thd data atau sistem Cth sistem yg memerlukan jaminan keamanan tinggi : sistem militer, sistem e-commerce, dan sistem yg melibatkan pertukaran informasi rahasia

Ada 3 jenis kerusakan yg dapat disebabkan oleh serangan eksternal : Penolakan layanan Sehingga layanan normal sistem tidak tersedia Korupsi program atau data Karena perubahan komponen PL Penyingkapan informasi rahasia

Keamanan semakin penting dgn beragamnya sistem yg terhubung dgn internet Atribut yg yg terpenting utk utk sistem berbasis internet adalah “kemampuan bertahan” Yaitu kemampuan sistem untuk terus meberikan layanan pada saat diserang atau pada saat sebagian sistem telah dilumpuhkan.

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)

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

Shg PL dp berprilaku spt yg tidak diharapkan 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 Pohon kesalahan yg dapat diidentifikasi utk bahaya yg memungkin muncul yg berhubungan dgn PL pada sistem penyaluran insulin

Pengurangan resiko : Penghindaran bahaya Deteksi dan pembuangan 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 kerusakan

Persyaratan utk pengembangan PL yg bebas dr kesalahan Harus ada spesifikasi sistem yg tepat Organisasi yg mengembangkan sistem hrs memiliki kultur kualitas organisasi Hrs digunakan pendekatan perancangan dan implementasi PL yg berdasarkan penyembunyian informasi dan enkapsulasi Gunakan bhs pemrograman yg strongly-typed (dpt mendeteksi kesalahan lebih banyak oleh kompilator) Menghindari penulisan yg potensial rentan thd eror 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 Komponen2 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 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.

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 : Deteksi kesalahan Penilaian kerusakan Pemulihan kerusakan status aman 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

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

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

Validation perspectives Validasi Security/keamanan Apakah sistem dan datanya aman terhadap serangan external?

Tekhnik Validasi Static techniques Dynamic techniques Review terhadap disain /inspeksi program Dynamic techniques Pengujian Statistik Pengujian berbasis skenario Pemeriksaan Run-time

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

Teknik Validasi Statik Validasi 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 validation Menunjukkan keselamatan sistem melalui sebuah pengujian merupakan sesuatu yg sulit Karena pengujian bertujuan utk menunjukkan apa yg dilakukan sistem saat situasi normal. Tidak mungkin dilakukan pengujian thd setiap kondisi operasional

Safety reviews Peninjauan thd Review utk kebenaran function Peninjauan thd maintainable, understandable structure Peninjauan thd algorithma dan disain struktur data berdasarkan spesifikasi Peninjauan thd konsistensi kode dgn algorithma dan disain struktur data Peninjauan thd kelayakan sistem pengujian

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

Hazard-driven analysis Efektif atau tidaknya jaminan keselamatan bergantung pada identifikasi bahaya Keselamatan dapat dijamin melalui Menghindari bahaya sistem pemotongan yg menuntut operator agar menekan 2 tombol terpisah Deteksi dan membuang bahaya deteksi tekanan berlebihan dan pembukaan katup sebelum meledak pd pabrik kimia Membatasi kerusakan  pemadam api otomatis

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