Pengembangan Sistem Aplikasi Pendekatan Tradisional

Presentasi berjudul: "Pengembangan Sistem Aplikasi Pendekatan Tradisional"— Transcript presentasi:

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

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

3 Waterfall

4 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

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

6 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

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

8 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

9 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

10 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

11 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

12 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

13 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

14 Paralel Pilot Bertahap Cold Turkey

15 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

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

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

18 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

19 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

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

21 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

22 Verification & Validation
oleh Retantyo W

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

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

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

37 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

38 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

39 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

40 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

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

42 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

43 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

44 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

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

46 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

47 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

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

49 Inspection checks

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

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

52 Static analysis checks

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

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

55 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

56 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

57 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

58 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

59 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

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

61 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

62 Pengujian Perangkat Lunak

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

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

65 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

66 Fase Pengujian Pengujian komponen integrasi Pengembang PL
Tim penguji independent

67 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

68 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

69 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

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

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

72 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

73 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

74 Partisi Equivalesi

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

76 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 dan Partisi equivalensinya adalah <10.000, dan > Pilih kasus uji pada batasan dari himpunan tersebut 00000, 09999, 10000, 99999, 10001

77 Partisi Equivalensi (cth)
Antara 10000dan 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

78 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

79 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

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

81 Search routine - input partitions

82 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

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

84 Binary search (Java)

85 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

86 Binary search equiv. partitions

87 Binary search - test cases

88 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

89 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

90 Binary search flow graph
Edge = 11 Node = 9 CC = =4 Binary search flow graph

91 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

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

93 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

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

95 Incremental integration testing

96 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

97 Top-down testing

98 Bottom-up testing

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

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

101 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

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

103 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

104 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

105 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

106 Error Interface Timing errors
Terjadi pada sistem waktu nyata (sistem yg memberikan respons langsung saat diakses. Cth : ATM, pemesanan tiket online) yg menggunakan memory

107 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

108 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

109 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

110 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

111 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

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

113 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

114 A testing workbench

115 SISTEM KRITIS

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

117 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

118 Biaya Kegagalan Sistem
Langsung Karena sistem harus diganti Tidak langsung Biaya proses pengadilan Kerugian bisnis yang terjadi karena sistem tidak tersedia

119 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

120 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

121 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

122 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

123 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

124 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

125 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

126 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

127 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

128 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

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

130 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

131 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

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

133 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

134 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

135 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

136 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

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

138 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

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

140 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

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

142 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

143 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

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

145 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

146 Spesifikasi Keamanan Tahap proses spesifikasi keamanan :
Identifikasi dan evaluasi aset (data dan program) Analisis ancaman dan penilaian resiko Penggolongan ancaman Analisis teknologi

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

148 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

149 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

150 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

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

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

153 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

154 Aspek toleransi kesalahan :
Deteksi kesalahan Penilaian kerusakan Pemulihan kerusakan status aman Perbaikan kesalahan

155 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

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

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

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

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

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

161 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

162 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

163 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

164 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

165 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

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