Pengembangan Sistem

Software Development
Pengembangan Sistem Aplikasi
Pendekatan Tradisional
1

SDLC
System 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 sistem
membangun sistem
pengujian sistem

Fase Implementasi:
Instalasi
Operasional & Maintenance
4

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
9

Membangun dan Pengujian Sistem (Building

& Testing Systems) lanjutan
Pengujian
setiap modul setiap kali dihasilkan
keseluruhan sistem jika sudah lengkap
Pengujian dilakukan untuk meyakinkan

bahwa sistem akan bekerja dengan benar

pada lingkungan user

10

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
11

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
12

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
13

Paralel
Pilot

Bertahap

Cold Turkey

14

Operasional dan Maintenance

Setelah segala usaha dan waktu digunakan

untuk proses pengembangan sistem,

diharapkan sistem yang baru akan beroperasi dengan panjang dan bermanfaat
Maintenans merupakan proses modifikasi
sistem untuk mengadaptasi perubahan
kebutuhan organisasi
15

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

Pendekatan alternatif
Pengembangan sistem menggunakan

metodologi evolusi yang didasarkan pada

prototyping
Pembelian paket software
pengembangan sistem bersumber diluar

17

Pendekatan Evolusi (prototyping)

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

18

Pendekatan evolusi lanjutan

Prototipe sbg metodologi pengembangan
Step 1: Kebutuhan sistem dasar
Step 2: Kembangkan prototipe
awal

User
Ok

Step 3: Gunakan prototipe dan

catat perubahan yang diinginkan
Step 4: Perbaiki prototipe

19

Pendekatan evolusi lanjutan

1

Step 5: Evaluasi sebagai sistem

operasional
Step 6: Buat modifikasi seperlunya

Step 7: Install, operasikan, dan

evolve
20

 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

21

Verification
&
Validation

oleh Retantyo W

22

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

Inspeksi
PL (SV)

Spesifikasi
s
persyaratan

Prototipe

Peranc. tk.
tinggi

Spesifikasi
formal

Perancangan rinci

Program

Pengujian
prog (DV)

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

Hasil Test

Temukan lokasi
error

Specification

Rancang
perbaikan

Kasus uji

Perbaiki
error

Uji ulang
program

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

cccc
c

Rencana
c
uji
penerimaan

Layanan

Perancangan
sistem

Rencana uji
integrasi sistem

Uji Penerimaan

Uji integrasi
sistem

Perancangan
rinci

Rencana uji
integrasi
sub sistem

Kode dan
pengujian modul
dan unit

Uji integrasi
sub sistem

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

Perencanaan
Tinjauan
Persiapan
i
individu

Rapat
pemeriksaan

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.

Faultclass
Datafaults

Controlfaults

Input/outputfaults
Interfacefaults

Storage management
faults

Exception
managementfaults

Inspectioncheck
Areallprogramvariablesinitialisedbeforetheir values
areused?
Haveallconstantsbeennamed?
Shouldthelowerboundofarraysbe0,1,orsomething
else?
Shouldtheupperboundofarraysbeequaltothesizeof
thearrayorSize1?
Ifcharacterstringsare used,isadelimiterexplicitly
assigned?
Foreachconditionalstatement,istheconditioncorrect?
Iseachloopcertaintoterminate?
Arecompoundstatementscorrectlybracketed?
Incasestatements,areallpossiblecasesaccountedfor?
Areallinputvariablesused?
Arealloutputvariablesassigned avaluebeforetheyare
output?
Do allfunctionandprocedurecallshavethecorrect
numberofparameters?
Doformalandactualparametertypesmatch?
Aretheparametersintherightorder?
Ifcomponentsaccesssharedmemory,dotheyhave the
samemodelofthesharedmemorystructure?
Ifalinkedstructureismodified, havealllinksbeen
correctlyreassigned?
Ifdynamic storageisused,hasspacebeenallocated
correctly?
Isspaceexplicitlydeallocatedafterit
isnolonger
required?
Haveallpossibleerrorconditionsbeentaken
into
account?

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

Faultclass
Datafaults

Staticanalysischeck
Variablesusedbeforeinitialisation
Variablesdeclaredbutneverused
Variables assignedtwicebutneverused
betweenassignments
Possiblearrayboundviolations
Undeclaredvariables
Controlfaults
Unreachablecode
Unconditionalbranchesintoloops
Input/outputfaults
Variables outputtwicewithnointervening
assignment
Interfacefaults
Parametertypemismatches
Parameternumbermismatches
Nonusageoftheresultsoffunctions
Uncalledfunctionsandprocedures
Storage
management Unassignedpointers
faults
Pointerarithmetic

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

ketergantungan antara var input dengan var

output.
Analisis jalur. Mengidentifikasi semua jalur
yang mungkin melalui program

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

LINT static analysis

Unix dan Linux utk
C

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

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

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
Pengerjaanulangerror

Spesifikasi
sistemsecara
formal
Defenisikan
inkremenPL
Kembangkan
profil
operasional

Buat
program
terstruktur

Verifikasi
kodesecara
formal

Rancang
ujistatistik

Integrasikan
inkremen

Ujisistem
terintegrasi

Proses Pengembangan Ikremental

Spesifikasiyangsudahtetap

Tetapkan
persyaratan

Spesifikasi
formal

Kembangkan
inkremenPL

Permintaanperubahanpersyaratant

SerahkanPL

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

62

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

Pengujian
integrasi

PengembangPL

Timpengujiindependent

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

Kasus
Uji
Rancang
kasus uji

Data uji

Siapkan
data uji

Hasil uji

Jalankan prog
dgn data uji

s
Laporan
uji

Bandingkan hasil dgn

kasus uji

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

Jika output
bukan merupakan
yang diramalkan,
berarti uji tsb
telah berhasil
mendeteksi
masalah dgn PL tsb

Input test data

Input yg menyebabkan
prilaku menyimpang

System

Outputtest results

Oe

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

System

Outputs

Validinputs

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)

3

Kurang dari 4

Nilaiinput

11
10

Lebihdari10

Antara 4 dan
10

Jumlahnilaiinput
9999
10000
Kurangdari10000

50000

100000
99999

Antara10000dan999999

Lebihdari99999

Search routine specification

mencari sederet
elemen untuk
elemen tertentu
(kunci)
kondisi pra
menyatakan rutin
search dirancang
utk bekerja
dengan deret
kosong
Kondisi pasca
menyatakan
variabel Found
diset jika elemen
kunci ada pd deret

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
TFIRST <= TLAST
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, TFIRST >= i <= TLAST, T (i) = Key ))

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

Array
Singlevalue
Singlevalue
Morethan1value
Morethan1value
Morethan1value
Morethan1value

Inputsequence(T)
17
17
17,29,21,23
41,18,9,31,30,16,45
17,18,21,23,29,41,38
21,23,29,33,38

Element
Insequence
Notinsequence
Firstelementinsequence
Lastelementinsequence
Middleelementinsequence
Notinsequence

Key(Key)
17
0
17
45
23
25

Output(Found, L)
true,1
false,??
true,1
true,7
true,4
false,??

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

DataUji

Uji

Menurunkan
Kodekomponen

OutputUji

class BinSearch {
// This is an encapsulation of a binary search function that takes an array of
// ordered objects and a key and returns an object with 2 attributes namely
// index - the value of the array index
// found - a boolean indicating whether or not the key is in the array
// An object is returned because it is not possible in Java to pass basic types by
// reference to a function and so return two values
// the key is -1 if the element is not found
public static void search ( int key, int [] elemArray, Result r )
{
int bottom = 0 ;
int top = elemArray.length - 1 ;
int mid ;
r.found = false ; r.index = -1 ;
while ( bottom <= top )
{
mid = (top + bottom) / 2 ;
if (elemArray [mid] == key)
{
r.index = mid ;
r.found = true ;
return ;
} // if part
else
{
if (elemArray [mid] < key)
bottom = mid + 1 ;
else
top = mid - 1 ;
}
} //while loop
} // search
} //BinSearch

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

Equivalenceclassboundaries

Elements<Mid

Elements>Mid

Midpoint

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

bottom>top

whilebottom<=top
2

if(elemArray[mid]==key

8
5

(if(elemArray[mid]<key

Edge = 11
Node = 9
CC = 11-9+2
=4

9
7

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

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

T1

T1

A
T1

T2

T2
T2

T3
T3

C
T4

T3
C

T4
T5

D
Testsequence
1

Testsequence
2

Testsequence
3

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
Level1

Testing
sequence

Level2
Le vel2
stubs

Le vel3
stubs

Level1

Level2

Le vel2

...

Level2

Bottom-up testing
Test
drivers
LevelN

Test
drivers

LevelN

LevelN1

Le velN

LevelN1

LevelN

LevelN

LevelN1

Testing
sequence

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

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
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 mengubahubah 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
Testdata
generator

Specification

Source
code

Test
manager

Testdata

Oracle

Dynamic
analyser

Program
beingtested

Test
results

Test
predictions

Execution
report

Simulator

File
comparator

Report
generator

Testresults
report

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

Dependabilitas
Properti dari sistem
Sama dengan keterpercayaan (trustworthiness)
Yaitu derajad kepercayaan user bahwa sistem
yang akan beroperasi sebagaimana yang
mereka harapkan
Atau sistem tidak akan gagal dalam
penggunaan yang normal

Dimensi dependabilitas :
Ketersediaan (Availability)
Probabilitas bahwa sistem dapat bekerja dan
memberikan layanan yang berguna setiap saat
Keandalan (Reliability)
Probabilitas bahwa dalam jangka waktu tertentu
bahwa sistem akan memberikan layanan
dengan benar sesuai harapan user

 Keselamatan (Safety)
Penilaian pada seberapa besar kemungkinan
sistem akan menyebabkan kerusakan terhadap
orang dan lingkungan sistem
Keamanan (Security)
Penilaian pada seberapa besar kemungkinan
sistem dapat bertahan terhadap campur tangan
yang disengaja atau tidak disengaja

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

 Keselamatan

PL lunak yg kritis dalam hal keselamatan terbagi atas :

1.PL kritis keselamatan primer
PL yg menyatu sbg kontroler pada sistem
Malfungsi PL menyebabkan malfungsi PK
Menyebabkan cedera pada manusia atau kerusakan pada
lingkungan

2.PL kritis keselamatan sekunder

PL yg secara tidak langsung dapat menimbulkan cedera
Cth : malfungsi sistem perancangan berbasis komputer yg
mengakibatkan kesalahan pd objek yg dirancang

Fakta menunjukkan bahwa :

Kita tidak akan pernah 100% yakin bahwa
suatu sistem PL bebas dari kesalahan dan
bertoleransi terhadap kesalahan

Ada beberapa alasan lain mengapa sistem PL

yg dapat diandalkan belum tentu menjamin
keselamatan
1.Spesifikasi mungkin tidak lengkap
Tingkat persentase malfungsi sistem yg tinggi merupakan akibat dari eror
spesifikasi, bukan eror perancangan.

2.Malfungsi perangkat keras

Shg menyebabkan PL menghasilkan suatu lingkungan yg tidak dapat diantisipasi

3.Operator sistem

Ada 3 hal yg perlu dilakukan utk menjamin

bahwa kecelakaan tidak akan terjadi atau bahwa
konsekuensi kecelakaan akan minimal, yaitu :
1.Menghindari bahaya
2.Deteksi dan membuang bahaya
Cth : sistem pabrik pengolahan bahan kimia yg dpt mendeteksi tekanan yg berlebihan
dan akan membuka sebuah katup untuk mengurangi tekanan ini.

3.Membatasi 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 :
1. Penolakan layanan
Sehingga layanan normal sistem tidak tersedia

2. Korupsi program atau data

Karena perubahan komponen PL
3. 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

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

 Toleransi kesalahan

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

1.Harus ada spesifikasi sistem yg tepat
2.Organisasi yg mengembangkan sistem hrs memiliki
kultur kualitas organisasi
3.Hrs digunakan pendekatan perancangan dan
implementasi PL yg berdasarkan penyembunyian
informasi dan enkapsulasi
4.Gunakan bhs pemrograman yg strongly-typed (dpt
mendeteksi kesalahan lebih banyak oleh kompilator)
5.Menghindari penulisan yg potensial rentan thd eror
6.Proses pengembangan hrs didefenisikan. Manajer
kualitas hrs memeriksa kesesuaian proses

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

1. Deteksi kesalahan
2. Penilaian kerusakan
3. Pemulihan kerusakan status aman
4. 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 nonkritis
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
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