0 - Modul Testing Dan Implementasi

MODUL PERKULIAHAN
Testing dan Implementasi SI
Modul Standar untuk

digunakan dalam Perkuliahan
di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
1 18017
Disini diisi Fakultas Program Tim Dosen
penerbit Modul Studi Sistem
Informasi
Abstract Kompetensi
Define Software Testing Scope, Understanding purposes and objective
Purpose and Objective. Introduction for of Software Testing in Industri
Testing in Software Engineering
‘13 Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning
1 Team Dosen http://www.mercubuana.ac.id
Materi Testing
Terminologi
Software : seluruh komponen pengolahan data yang dapat membantu memecahkan masalah
diluar dari perangkat hardware yang meliputi system design, program dan prosedur.
Beberapa gambaran umum tentang perangkat lunak antara lain :
1. Perintah (program computer) yang bila dieksekusi memberikan fungsi dan unjuk kerja
seperti yang diinginkan.
2. Struktur data yang memungkinkan program memanipulasi informasi secara proporsional.
3. Dokumen yang menggambarkan operasi dan kegunaan program.
Jenis-jenis software antara lain :
1. CP/M-80 (control program for Microprocecor 8080) di pakai pada komputer Appel / Intel
8080
2. CP/m-86 (control program for Microprocecor 8086) di pakai untuk intel 8086
3. PC-Dos (Personal Computer Disk Operating System) di buat oleh Microsoft Corppration
4. MS-DOS (Microsoft Disk Operating System) pengembangan dari PC-DOS
5. MS-Windows dibuat oleh Microsoft Corporation, mulai dari Windows 3.1, Windows NT,
Windows 95, Windows 98, Windows 2000 Profesional, dan Windows XP yang
merupakan perbaikan dari versi sebelumnya, komponen strategisnya antara lain :
 Fleksibel dengan hardware yang ada saat ini

 Menggunakan konfigurasi hardware otomatis
 Prosedur instalasi mudah
 Fasilitas jaringan network
 Telah memperbaiki bug-bug pada versi sebelumnya.
1. Unix adalah sistem operasi yang dikembangkan oleh Dennis M. Ritche dan Ken
Thompson, di tulis dalam pemrograman bahasa C.
2. Linux.
3. Dll.
Ada dua tipe produk perangkat lunak :
1. Produk generik
2. Produk pesanan (yang disesuaikan)
Pengujian perangkat lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan
merespresentasikan kajian pokok dari spesifikasi, desain dan pengkodean. Meningkatnya
visibilitas perangkat lunak sebagai suatu elemen sistem dan “biaya” yang muncul akibat
kegagalan perangkat lunak, memotivasi dilakukannya perencanaan yang baik melalui pengujian
yang teliti.
Pengujian termasuk dalam teknik verifikasi dan validasi (V & V). Pengujian melibatkan
pelatihan perangkat lunak dengan memakai data seperti data riil yang diolah oleh perangkat
lunak.
Tujuan akhir dari proses verifikasi dan validasi adalah menanamkan kepercayaan bahwa system
perangkat lunak “siap untuk tujuannya”.
Apakah yang dimaksud dengan pengujian perangkat lunak ?
 Pengujian adalah proses menjalankan sebuah program dengan maksud menemukan

kesalahan-kesalahan (error).
 Proses untuk menjalankan sebuah program komputer dan membandingkan tingkah laku
yang sesungguhnya dengan yang diharapkan.
 Yang dimaksud membandingkan adalah menemukan bentuk penyimpangan-
penyimpangan (jika ada). Antara lain membandingkan tingkah laku yang sesungguhnya
dengan yang diharapkan.
 Layanan pengujian sebagai bentuk suatu rintangan untuk menyediakan produk yang
berkualitas dalam mendapatkan pelanggan
Pada saat V & V perangkat lunak, kesalahan pada perangkat lunak biasanya ditemukan dan
kemudian diubah untuk membetulkan kesalahan tersebut. Proses debug ini seringkali terintegrasi
dengan kegiatan verifikasi dan validasi lain. Bagaimanapun, pengujian (atau lebih umum
verifikasi dan validasi) dan debug merupakan proses yang berbeda yang tidak harus
diintegrasikan :
1. Verifikasi dan validasi adalah proses yang meyakinkan adanya kesalahan pada sistem
perangkat lunak.
2. Debug merupakan proses yang menemukan dan membetulkan kesalahan tersebut.
Tipe pengujian yang dapat digunakan pada berbagai tahap proses perangkat lunak :
1.Pengujian cacat (Defect Testing)
 Menetapkan keberadaan cacat sistem.

 Tujuannya untuk menemukan ketidak konsistenan antara program dan spesifikasinya.
 Dirancang untuk mengungkapkan adanya cacat pada sistem dan bukan untuk
mensimulasi penggunaan operasionalnya.
 Bermanfaat bagi pemrogram dan menunjukkan cacat-cacat yang ada di kode (program).
2.Pengujian statistik
 Menguji kinerja dan keandalan program dan memeriksa bagaimana kerjanya pada kondisi
operasional
 Dirancang untuk menunjukkan input user yang sebenarnya dan frekuensinya.
 Kehandalan sistem dapat dilakukan dengan menghitung kegagalan sistem yang diteliti.
Sasaran Pengujian
Glen Myers menyatakan bahwa sasaran dari pengujian perangkat lunak adalah :
1. Pengujian adalah proses menjalankan suatu program dengan maksud menemukan kesalahan.
2. Pengujian yang baik adalah yang memiliki kemungkinan tinggi untuk menemukan kesalahan
yang belum pernah ditemukan sebelumnya.
3. Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum
pernah ditemukan sebelumnya.
Satu hal yang perlu diingat/diperhatikan dalam pengujian terhadap perangkat lunak bahwa :
“Pengujian tidak dapat memperlihatkan kerusakan sistem, tetapi hanya dapat memperlihatkan
bahwa ada kesalahan perangkat lunak. “
Kaner, Falk dan Nguyen mengusulkan atribut-atribut dari
pengujian yang “baik” sebagai berikut :
1. Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan.
2. Pengujian yang baik tidak redundan.
3. Pengujian yang baik seharusnya “jenis terbaik”
4. Pengujian yang baik tidak boleh terlalu sederhana atau terlalu kompleks.
Tidak semua pengujian akan berhasil dengan baik. Masih ada beberapa kekurangan yang
terdapat pada pengujian suatu perangkat lunak.
Kekurangan-kekurangan tersebut antara lain :

1.Tidak pernah cukup melakukan banyak ujian yang layak.
2.Pengujian tidak akan menemukan semua kesalahan
3.Pengujian sulit dan menghabiskan banyak waktu
4.Pengujian sebagian besar masih merupakan tugas yang tidak resmi.
Prinsip-prinsip Pengujian
Sebelum menetapkan metode pengujian, seorang ahli pada bidang software harus mengerti betul
atau memahami prinsip dasar yang menuntun pengujian perangkat lunak. Prinsip-prinsip
pengujian secara umum yang banyak dianut oleh para ahli perangkat lunak, antara lain :
 Seorang Programmer seharusnya tidak menguji programnya sendiri.

 Sebaiknya satu pengujian tidak hanya mengerjakan program yang dianggap benar, tetapi
tidak mengerjakan yang dianggap salah.
 Tujuan dari pengujian adalah untuk menemukan kesalahan, bukan untuk menunjukkan
bahwa program tersebut salah.
 Tidak ada sejumlah pengujian yang dapat menjamin bahwa program bebas dari
kesalahan.
 Bagian-bagian dari program di mana terdapat banyak kesalahan yang telah ditemukan
adalah suatu tempat yang baik untuk menemukan kesalahan yang lebih banyak.
 Tujuannya adalah bukan untuk mempermalukan programmer.
Selain pernyataan diatas, Roger S. Pressman mendefinisikan sendiri mengenai prinsip-prinsip

pengujian terhadap perangkat lunak :
 Pengujian harus sesuai dengan persyaratan konsumen.

 Para ahli harus betul-betul mengetahui spesifikasi dari produk (software) yang
diinginkan konsumen.
 Pengujian harus direncanakan lama sebelum pengujian itu di mulai.
 Prinsip Pareto berlaku untuk pengujian perangkat lunak.
 80 % kesalahan yang ditemukan, hanya dapat ditelusuri sampai 20 % dari semua modul
program.
 Pengujian harus dimulai dari yang kecil dan berkembang ke pengujian yang besar.
 Pengujian berfokus dalam usaha menemukan kesalahan pada modul yang terintegrasi,
dan akhirnya pad asistem secara keseluruhan.
 Pengujian yang sempurna tidak mungkin.
 Agar efektif, pengujian harus dilakukan oleh pihak ketiga yang independent (third
party).
 Pengujian yang memiliki probabilitas tinggi untuk menemukan kesalahan.
 Pembuat sistem bukanlah orang yang paling tepat untuk melakukan semua pengujian
bagi perangkat lunak.
Kegagalan dan Kesalahan
Kesalahan sistem tidak selalu mengakibatkan eror sistem, karena status salahnya mungkin
bersifat sementara dan dapat diperbaiki sebelum terjadi perilaku yang merupakan eror.
Jenis kegagalan dan kesalahan pada sistem antara lain :
 Kegagalan sistem (system failure)
Peristiwa yang terjadi pada suatu waktu ketika sistem tidak memberikan layanan sebagaiman
diharapkan oleh user.
 Eror sistem (system eror)
Perilaku eror sistem dimana perilaku, sistem yang tidak sesuai dengan spesifikasinya
 Kesalahan sistem (system fault)
Status sistem yang tidak benar, yaitu status sistem yang tidak diharapkan oleh perancang sistem.
 Eror atau kesalahan manusia (human error)
Perilaku manusia yang mengakibatkan kesalahan sistem.
Bagaimana kesalahan tersebut mempengaruhi kita ?
Telah diketahui bahwa salah satu tujuan dari pengujian terhadap perangkat lunak, adalah untuk
menemukan suatu kesalahan. Kesalahan-kesalahan tersebut mempunyai tingkatan-tingkatan yang
diukur dengan istilah yang dimengerti oleh manusia. Tingkatan-tingkatan kesalahan tersebut
dikategorikan sebagai berikut
A. MILD (ringan)
Gejala dari kesalahan yang mengganggu kita secara estetis
 Kesalahan pengejaan
 Kesalahan penempatan
B. MODERATE (sedang)
 Kesalahan yang berpengaruh pada penampilan system

 Informasi yang menyesatkan
C. ANNOYING (menjengkelkan)
 • Kesalahan dari system karena adanya suatu virus.
▫ Nama yang terpotong
▫ Tagihan untuk Rp. 0,00 di cetak / dikirim
D. DISTURBING (mengganggu)
 Sistem menolak untuk menangani transaksi yang sah
▫ Kartu kredit yang dilaporkan tidak bisa digunakan
E. SERIOUS (serius)
 • Perhitungan yang salah
▫ Hal ini menghilangkan hubungan pada proses transaksi
▫ Tidak mencetak setiap pembayaran
F. VERY SERIOUS (sangat serius)
 Kesalahan yang menyebabkan system melakukan transaksi yang salah
▫ Sebuah system kredit dapat melakukan kesalahan perhitungan.
G. EXTREME (besar)
 Masalah yang tidak terbatas pada beberapa transaksi

 Sering berubah-ubah atau masalah yang tidak lazim
H. INTOLERABLE (kurang tahan)
 Pertimbangan yang serius diberikan untuk mematikan system.
I. CATASTROPHIC (bencana besar)
 Sistem yang salah
MODUL PERKULIAHAN
Modul Standar untuk

2 18017
Informasi
Abstract Kompetensi
A method how to organize software Understanding Software Development a
development project Life Cycle in Software Engineering.
Testability (Kemampuan Test)
Testabilitas perangkat lunak adalah seberapa mudah sebuah program komputer dapat diuji.
Karena pengujian sangat sulit, maka perlu diketahui apa yang dapat dilakukan untuk
membuatnya menjadi mudah. Kadang-kadang pemrogram bersedia melakukan hal-hal yang akan
membantu proses pengujian, dan membuat checklist (daftar periksa) mengenai masalah-masalah
desain yang mungkin, fitur dan lain sebagainya yang dijadikan sebagai pedoman dalam
melakukan pengujian.
Beberapa checklist dibawah ini, akan membantu sebagai pedoman dalam kegiatan pengujian
perangkat lunak :
1. OPERABILITY. (Mampu menjalankan/operasi.)
 Semakin baik hal tersebut dijalankan, pengujian akan semakin efesien.

 Sistem memiliki sedikit kesalahan.
 Tidak ada kesalahan yang menghalangi jalannya pengujian.
 Produk berkembang dalam tahapan fungsional (memungkinkan pengembangan dan
pengujian secara simultan)
2. OBSERVABILITY(Kemampuan untuk mengamati/meneliti) “Apa yang dilihat adalah apa

yang diuji.”
 Output yang berbeda dikeluarkan oleh masing-masing input.

 Tahap dan variabel sistem dapat dilihat atau diantrikan selama eksekusi.
 Sistem dan variabel yang lalu dapat dilihat atau diantrikan (misalnya, logaritma transaksi)
 Semua faktor yang mempengaruhi output dapat dilihat.
 Output yang tidak benar dapat diidentifikasi dengan mudah.
 Kesalahan internal dideteksi secara otomatis melalui mekanisme pengujian itu sendiri.
 Kesalahan internal dilaporkan secara otomatis.
 Kode sumber dapat diakses.
3. CONTROLLABILITY(Kemampuan untuk mengawasi)
“ Semakin baik kita dapat mengontrol perangkat lunak, semakin banyak pengujian yang dapat
diotomatisasi dan dioptimalkan. “
 Semua output yang baik, dapat diperoleh melalui beberapa kombinasi input.
 Semua kode dapat dijalankan melalui berbagai kombinasi input.
 Keadaan dan variabel perangkat lunak dan perangkat keras dapat dikontrol secara
langsung oleh penguji.
 Format input dan output konsisten dan terstruktur.
 Pengujian dapat dispesifikasi, dioptimasi, dan direproduksi dengan baik.
4. DECOMPOSABILITY(Kemampuan untuk menyelesaikan).
 Dengan mengontrol ruang lingkup pengujian, kita dapat dengan lebih cepat mengisolasi
masalah dan melakukan pengujian kembali secara lebih halus.
 Sistem perangkat lunak dibangun dari modul-modul yang independen.
 Modul-modul dapat diuji secara independen.
5. SIMPLICITY (Kemampuan untuk menyederhanakan kerumitan).
 Semakin sedikit yang diuji, semakin cepat kita dapat mengujinya.

 Fungsi yang sederhana (kumpulan fitur adalah kebutuhan minimum untuk memenuhi
persyaratan).
 Struktur yang sederhana (arsitektur dimodularisasi untuk membatasi penyebaran
kesalahan).
 Kode yang sederhana (standar pengkodean diadopsi demi kemudahan inspeksi dan
pemeliharaan)
6. STABILITY(Mampu menyeimbangkan ).
 Semakin sedikit perubahan, semakin sedikit gangguan dalam pengujian.

 Perubahan perangkat lunak jarang terjadi.
 Perubahan perangkat lunak dapat dikontrol.
 Perubahan perangkat lunak memvalidasi pengujian yang sudah ada.
 Kegagalan perangkat lunak dapat diperbaiki dengan baik.
7. UNDERSTANDBILITY (kemampuan untuk memahami/mengerti).
 Semakin banyak informasi yang kita dapat, semakin mudah pengujian dilakukan.
 Rancangan dapat dipahami dengan baik.
 Ketergantungan antara komponen internal, eksternal, dan yang dipakai bersama,
dipahami dengan baik.
 Perubahan rancangan dibicarakan.
 Dokumentasi teknik dapat diakses dengan cepat.
 Dokumen teknik diorganisasikan dengan baik.
 Dokumentasi teknik spesifik dan detail.
 Dokumentasi teknik akurat.
Ÿ MENGAPA PROGRAM MENGALAMI KERUSAKAN ?
Ÿ Ketika orang mengerjakan tugas-tugas yang kompleks, mereka membuat kesalahan yang
tidak dapat dihindari.
Ÿ Mereka lebih memperbaiki kerusakan-kerusakan selama pengujian.
Ÿ Mereka harus memperbaiki banyak kesalahan sebelum program akan berjalan semuanya.
Ÿ MEMPERBAIKI KERUSAKAN ADALAH SESUATU YANG MAHAL
Ÿ Dengan waktu sehari, pengujian perangkat lunak secara umum masih mempunyai banyak
kerusakan
Ÿ Komputer akan menjalankan program yang tidak sempurna
Ÿ ketika menghadapi kerusakan, program tidak akan mengerjakan apa yang seharusnya
dikerjakan.
Ÿ Bahkan mungkin menyebabkan kerugian.
Ÿ Semakin lama kerusakan tersisa, semakin buruk memperbaikinya
Ÿ membutuhkan biaya lebih untuk perbaikan
Ÿ kerusakan yang tersisa akan menjadi penyebab gangguan
Ÿ REVIEW (Peninjauan)
Ÿ Melakukan peninjauan adalah langkah yang terpenting, karena dapat mengembangkan kualitas
perangkat lunak.
Ÿ Lebih awal mengenali dan mengatasi masalah, semakin mudah dan murah untuk
memperbaikinya.
Ÿ APA YANG PERLU DITINJAU ?
Ÿ REQUIREMENT & ANALYSIS (pemahaman dan analisa)
Ÿ DESIGN (rancangan)
Ÿ CODE (kode)
Ÿ DOCUMNTATION (dokumentasi)
Ÿ TEST PLAN & CASES (rencana ujian dan kasus)
TESTING TECHNIQUE / Teknik Pengujian
Pengujian merupakan elemen yang paling kritis dari penilaian perangkat lunak yang telah
dikerjakan.
Pembahasan :
 Dasar-dasar pengujian perangkat lunak
 Perancangan permasalahan pengujian yang berfokus pada kumpulan teknik yang
digunakan untuk membuat pengujian sesuai dengan permasalahan dan juga disesuaikan
dengan tujuan pengujian secara keseluruhan.
Pengujian merupakan salah satu dari siklus pengembangan perangkat lunak yang jika ditinjau
dari sudut pandang psikologi adalah penghancuran dibandingkan penyusunan.
MODUL PERKULIAHAN
Modul Standar untuk

3 18017
Informasi
Abstract Kompetensi
Production of High Quality Software Understanding Production of High
and Its Development life Cycle Quality Software and Its Development
life Cycle
Aliran Informasi Pengujian
Aliran informasi yang terdapat pada saat pengujian dilaksanakan dapat digambarkan sebagai
berikut :
Terdapat 2 (dua) tingkatan yang tersedia pada proses pengujian, yaitu :
 Konfigurasi perangkat lunak yang mencakup spesifikasi keperluan perangkat lunak,

spesifikasi perancangan, test case, dan program sumber.
 Konfigurasi pengujian yang mencakup rencana dan prosedur uji coba, test case dan hasil
yang diharapkan.
Desain Test Case
Dengan melihat lagi sasaran pengujian, kita harus mendesain pengujian yang memiliki
kemungkinan tertinggi dalam menemukan kesalahan dengan jumlah waktu dan usaha yang
minimum.
Terdapat 2 (dua) macam test case :
 Pengetahuan fungsi yang spesifik dari produk yang telah dirancang untuk diperlihatkan,
test dapat dilakukan untuk menilai masing-masing fungsi apakah telah berjalan
sebagaimana yang diharapkan.
 Pengetahuan tentang cara kerja dari produk, test dapat dilakukan untuk memperlihatkan
cara kerja dari produk secara rinci sesuai dengan spesifikasinya.
Terdapat dua pendekatan dalam teknik pengujian perangkat lunak :
 Black Box Testing
Dilakukan untuk testing pada interface perangkat lunak. Test case ini bertujuan untuk
menunjukkan fungsi perangkat lunak tentang cara beroperasinya, apakah pemasukan data
keluaran telah berjalan sebagaimana yang diharapkan dan apakah informasi yang disimpan
secara eksternal selalu dijaga kemutakhirannya.
 White Box Testing
Meramalkan cara kerja perangkat lunak secara rinci, karenanya logikal path (jalur logika) yang
melewati perangkat lunak diuji dengannmemberikan test case yang menguji serangkaian kondisi
dan loop secara spesifik.
Secara sekilas dapat disimpulkan bahwa metoda White Box Testing merupakan petunjuk untuk
mendapatkan program yang benar, karena semuanya dilakukan dengan mendefinisikan seluruh
jalur logika, mengembangkan test case untuk mengerjakan program, dan mengevaluasi hasilnya,
sehingga test case akan mengerjakan logika program secara mendalam.
WHITE BOX TESTING
Pengujian white box adalah metode perancangan test case yang menggunakan struktur kontrol
dari perancangan prosedural untuk mendapatkan test case.
Pengujian White Box disebut juga :
 Glass Box Testing (Pengujian kotak bening)

 Code Base Testing (Source kodenya dimunculkan)
 Structural Testing (Struktur program ditampilkan)
Dengan menggunakan metoda White Box Testing, perekayasa sistem akan dapat melakukan test
case yang :
1. Menjamin bahwa seluruh independent path di dalam modul telah dikerjakan paling tidak
satu kali.
2. Mengerjakan seluruh keputusan logika pada sisi true dan false
3. Melaksanakan seluruh loop sesuai dengan batasannya
4. Mengerjakan seluruh struktur data internal yang menjamin validitas
BASIS-PATH TESTING
Pengujian basis path adalah teknik pengujian white box yang diusulkan oleh Tom MacCabe.
Tujuannya memperoleh ukuran kekomplekan logikal dari perancangan prosedural dan

menggunakannya sebagai petunjuk untuk menetapkan basis set dari jalur eksekusi.
Objek dari pengujian path adalah untuk meyakinkan bahwa penerapan masalah ujian untuk
masing-masing path yang melalui program dilaksanakan setidaknya sekali.
Point permulaan dari pengujian path adalah Folwgraph program yang menunjukkan keputusan
program dan aliran kontrol.
Metode pengujian basis path dapat diaplikasikan pada desain prosedural atau kode sumber.
Cyclomatic Complexity
 Adalah metrik perangkat lunak yang menyediakan ukuran kuantitatif dari kekomplekan
logika suatu program.
 Nilai yang dihitung untuk cyclomatic complexity menentukan jumlah independent path
dalam basis set suatu program.
 Memberikan batas atas bagi jumlah pengujian yang harus dilakukan untuk memastikan
bahwa seluruh statemen telah dilaksanakan sedikitnya sekali.
 Independet path adalah jalur yang melintasi atau melalui program dimana sekurang-
kurangnya terdapat proses perintah yang baru atau kondisi yang baru.
 Dalam flowgraph, independent path harus bergerak sekurang-kurangnya pada satu edge
yang belum dilewati sebelum jalur tersebut didefinisikan.
Cyclomatic Complexity digunakan untuk mencari jumlah path dalam satu flowgraph. Dapat
dicari dengan 3 (tiga) metode, yaitu :
 Cyclomatic comlpexity V untuk flowgraph dihitung dengan rumus :
V(G) = E – N + 2
dimana E = jumlah Edge, dan N = jumlah Node
 Cyclomatic comlpexity V untuk flowgraph dapat dicari dengan rumus :
V(G) = P + 1
dimana P = jumlah predikat node
 Jumlah region dalam flowgraph mempunyai hubungan dengan cyclomatic complexity.
V(G) = R
Nilai cyclomatic complexity memberi batas untuk jumlah jalur independen yang membentuk
basis set dan implikasinya, batas atas jumlah pengujian yang harus didesain dan dieksekusi untuk
menjamin semua statemen program.
Graph metrik
 Adalah matrik empat persegi yang mempunyai ukuran (jumlah baris dan kolom) yang
sama dengan jumlah node pada flowgraph.
 Masing-masing baris dan kolom mempunyai hubungan dengan node yang telah
ditentukan.
 Pemasukan data matrik berhubungan dengan hubungan (edge) antarnode.
 dikembangkan untuk membantu pengujian basis path atau struktur data.
LOOP TESTING
Loop merupakan kendala yang sering muncul untuk menerapkan algoritma dengan cepat.
Pengujian loop merupakan teknik pengujian white box yang berfokus pada validitas dari loop.
Terdapat 4 kelas dari loop, :
 Simple loop.
 Nested loop.
 Concanated loop.
 Unstructured loop.
Simple Loop
 Diaplikasikan pada bentuk loop yang sederhana, dimana n adalah jumlah maksimum
yang diijinkan untuk melalui loop.
 lewati loop secara keseluruhan.
 hanya satu yang melalui loop
 m dapat melalui loop dimana m = n atau m < n
Nested loop
 teruskan sampai semua loop selesai diuji.
Concanated Loop
 Dapat diuji dengan menggunakan pendekatan simple loop bila masing-masing dari loop
independent terhadap yang lain.
 Bila dua loop dirangkai dan pencacah loop untuk loop 1 digunakan sebagai harga awal
untuk loop 2, kemudian loop tersebut menjadi tidak independen, maka pendekatan yang
diaplikasikan ke loop tersebut direkomendasikan.
Unstructured Loop
 Apabila memungkinkan, kelas loop ini harus didesain lagi untuk mencerminkan
penggunaan konsepsi pemrograman terstruktur.
Black Box Testing
 Ÿ Metode pengujian black box berfokus pada keperluan fungsional dari perangkat lunak
dan domain informasi.
 Ÿ Analis sistem memperoleh kumpulan kondisi dari input yang akan mengerjakan
seluruh keperluan fungsional program.
 Ÿ Cenderung diaplikasikan selama tahap akhir pengujian.
 Ÿ Disebut juga pengujian behavioral/pengujian partisi/pengujian interface.
 Ÿ Memperhatikan dari sudut pandang Input data dan Output data.
 Perangkat lunak ditinjau sebagai kotak hitam yang menyalurkan input kepada output
berdasarkan rincian dimana perangkat lunak tersebut harus melakukannya.
 Periksa kecocokan dari pengujian S/W yang membentuk tingkah laku.
 Mencari kesalahan-kesalahan yang dihasilkan oleh kesalahan
 ŸKesalahan perangkat lunak adalah bagian dari perangkat lunak yang tidak menurut pada
penyedian definisi itu sendiri dalam dokumen pengembangan.
Tujuannya untuk mencari kesalahan-kesalahan pada :
 Fungsi yang salah atau hilang.
 Kesalahan pada interface.
 Kesalahan pada struktur data atau akses database.
 Kesalahan performansi (kinerja).
 Kesalahan initialisasi dan tujuan akhir.
Type dari pengujian black box :
1. Equivalence Class Partitioning. (pembagian kelas yang sama)
 Metode pengujian black box yang memecah atau membagi domain input dari suatu
program ke dalam kelas-kelas data.
 Perancangan test case berdasarkan evaluasi kelas equivalence untuk kondisi input.
 Kelas equivalence menggambarkan kumpulan keadaan yang valid dan tidak valid untuk
kondisi input.
 Kondisi input dapat berupa nilai numerik, range dari nilai, kumpulan nilai yang
berhubungan atau kondidi boolean.
Kelas equivalence dapat ditentukan sesuai pedoman berikut ini :
 Bila kondisi input menentukan suatu range, maka kelas equivalence valid dan dua yang
invalid ditentukan.
 Bila kondisi input membutuhkan suatu harga khusus, maka satu kelas equivalence valid
dan dua yang invalid ditentukan.
 Bila kondisi input menentukan anggota suatu himpunan, maka satu kelas equivalence
valid dan dua yang invalid ditentukan.
 Bila kondisi input adalah boolean, maka satu kelas dan satu yang tidak valid ditentukan.
Contoh :
Dalam persamaan matematika.
1 juta <= Gaji <= 5 juta
Valid : 1 juta samapi 5 juta
Invalid : kurang dari 1 juta lebih dari 5 juta
1. Boundary Value Analysis.(analisa penilaian terbatas)
 Untuk permasalahan yang tidak diketahui dengan jelas, akan cenderung menimbulkan
kesalahan pada domain output-nya.
 Pemilihan test case yang mengerjakan nilai-nilai yang telah ditentukan.
 Melengkapi equivalence class partitioning.
Petunjuk pemakaian BVA :
 Jika kondisi input berupa range yang dibatasi oleh nilai a dan b, test case harus dirancang
dengan nilai a dan b.
 Jika kondisi input ditentukan dengan sejumlah nilai, test case harus dikembangkan
dengan mengerjakan sampai batas maksimal dari nilai tersebut.
 Sesuai dengan 1 dan 2, untuk kondisi output harus dirancang test case sampai jumlah
maksimal.
 Untuk struktur data pada program juga harus dirancang sampai batas kemampuan.
1. Comparison Testing. (pengujian perbandingan)
 Perangkat keras dan perangkat lunak yang berlebihan memungkinkan untuk digunakan.
 Menggunakan team yang terpisah untuk mengembangkan versi-versi yang independent
dari perangkat lunak dengan menggunakan spesifikasi yang sama.
 Mencoba masing-masing versi dengan data yang sama untuk memastikan bahwa semua
versi memberikan output yang identik.
 Semua versi dieksekusi secara paralel dengan perbandingan real time hasil untuk
memastikan konsistensi.
 Output dari masing-masing versi sama implementasi benar.
 Output berbeda masing-masing versi dari aplikasi diperiksa untuk menentukan cacat pada
suatu versi (perbedaan jelas)
 Spesifikasi semua fungsi yang dikembangkan mengandung kesalahan, maka semua versi
kemungkinan besar merefleksikan kesalahan.
 Masing-masing versi independen identik tetapi tidak benar, maka pengujian kondisi akan
gagal mendeteksi kesalahan.
MODUL PERKULIAHAN
Modul Standar untuk

4 18017
Informasi
Abstract Kompetensi
Basic of Software Testing, Model of Understanding a methodology to test a
Software Testing Blackbox and White Software with Graph, Path.
Box
Prosedur pengujian unit.
 Pengujian unit pada umumnya merupakan perkembangan dari langkah pengkodean.

 Setelah program sumber dikembangkan, ditinjau kembali dan diverifikasi untuk
sintaknya, maka perancangan test case di mulai.
 Peninjauan kembali perancangan informasi akan menyediakan petunjuk untuk
menentukan test case.
 Karena modul bukan program yang berdiri sendiri, maka driver (pengendali) dan atau
stub perangkat lunak harus dikembangkan untuk tiap-tiap pengujian unit.
MODUL TESTING (pengujian modul)
 Pengujian interaksi dari semua komponen yang berhubungan terhadap modul.

 Pengujian modul yang indpendent.
 Modul secara individu diuji secara terpisah.
 Modul berupa kumpulan fungsi, prosedure atau program-program.
 Tidak secara increment, biasanya dilakukan oleh seorang programmer yang membuat
program tersebut.
 Menggunakan stub dan driver.
 Pengujian whit-box cocok untuk tingkatan ini.
 Pengujian struktur data lokal, kondisi batasan, jalur independen, jalur penanganan
kesalahan.
 Formal : rencana pengujian dijelaskan dan tertulis.
 Modul bukanlah program yang berdiri sendiri, perangkat lunak driver dan atau stub harus
dikembangkan bagi masing-masing pengujian unit.
 Pada sebagian besar aplikasi, driver tidak lebih dari sebuah “program utama”, yang
menerima data test case.
 Data sampai ke modul untuk diuji, dan kemudian mencetak hasil yang relevan.
 Stub berfungsi untuk menggantikan modul yang merupakan subordinat dari modul yang
akan diuji.
 Stub menggunakan interface modul subordinat untuk melakukan manipulasi data
minimal, mencetak , entri dan kembali.
INTEGRATION TESTING (pengujian integrasi)
♪ Pengujian integrasi adalah teknik yang sistematis untuk mengkonstruksi susunan program
sambil melakukan pengujian untuk memeriksa kesalahan yang nantinya digabungkan dengan
interface.
♪ Sasarannya adalah untuk mengambil modul yang dikenai pengujian unit dan membangun
struktur program yang telah ditentukan oleh desain.
♪ Kesulitannya adalah lokalisasi error yang sulit ditemukan pada saat proses.
♪ Terdapat interaksi yang rumit antara komponen sistem dan ketika ditemukan output yang
menyimpang, mungkin sulit untuk menemukan sumber error tersebut.
Integrasi non-inkremental
Program diuji sebagai satu kesatuan. Serangkaian kesalahan akan terjadi. Koreksi sulit dilakukan
karena isolasi penyebab diperumit oleh luasnya program keseluruhan. Sekali kesalahan tersebut
dibetulkan, maka akan muncul lagi yang baru dan proses itu terus berlanjut dalam loop yang
kelihatannya tidak akan pernah berhenti.
Integrasi inkremental
Program dibangun dan diuji di dalam segmen-segmen kecil, sehingga kesalahan lebih mudah
diisolasi dan dibetulkan, interface lebih mungkin untuk diuji secara lengkap, dan pendekatan
pengujian yang sistematis dapat diaplikasikan.
Top-down Integrasi
 adalah pendekatan inkremental terhadap struktur program.

 Modul diintegrasikan dengan menggerakkan ke bawah melalui hirarki kontrol, dimulai
dengan modul kontrol utama (program utama).
 Memverifikasi kontrol utama dan keputusan pada saat awal proses pengujian.
 Pada struktur program yang dibuat dengan baik, keputusan akan dikerjakan pada tingkat
atas hirarki.
 Stub mengganti modul tingkat rendah pada awal pengujian top-down, sehingga tidak ada
data yang penting yang dapat mengalir ke atas di dalam struktur program.
Proses integrasi dilakukan dalam 5 (lima) langkah :
1. Modul kontrol utama digunakan sebagai test driver, dan stub ditambahkan pada semua
modul yang secara langsung subordinat terhadap modul kontrol utama.
2. Stub subordinat diganti pada suatu saat dengan modul aktual.
3. Pengujian dilakukan pada saat masing-masing modul diintegrasi.
4. Pada pelengkapan masing-masing rangkaian pengujian, stub yang lain diganti dengan
modul real.
5. Pengujian regresi dapat dilakukan untuk memastikan bahwa kesalahan baru belum
dimunculkan.
Bottom-up Integrasi
 Dapat dinyatakan dengan penyusunan yang dimulai dan diuji dengan atomic modul
(modul tingkat paling bawah pada struktur program).
 Modul diintegrasikan dari bawah ke atas sehingga pemrosesan yang diperlukan untuk
modul subordinat yang selalu diberikan akan selalu tersedia dan kebutuhan akan stub
dapat dieliminasi.
Strategi bottom-up integration dapat diterapkan dengan urutan langkah-langkah sebagai berikut :
1. Modul tingkat bawah digabungkan ke dalam cluster (sering disebut build) yang
malakukan subfungsi perangkat lunak spesifik.
2. Driver (program kontrol untuk pengujian) ditulis untuk mengkoordinasi input dan output
test case.
3. Cluster diuji.
4. Driver diganti dan cluster digabungkan dengan menggerakkannya ke atas di dalam
struktur program.
Regression Testing (pengujian regresi)
 adalah aktivitas yang membantu memastikan bahwa perubahan (karena pengujian atau
alasan lain) tidak menimbulkan tingkah laku yang tidak diharapkan atau kesalahan
tambahan.
 Merupakan eksekusi ulang dari beberapa subset yang telah dilakukan untuk memastikan
bahwa perubahan tidak menimbulkan efek samping yang tidak diharapkan.
 Pengujian yang berhasil akan menghasilkan kesalahan, dan setiap kesalahan harus
dikoreksi.
 Setiap kali perangkat lunak dikoreksi, maka banyak aspek konfigurasi perangkat lunak
(program, dokumentasi atau data yang mendukung) akan diubah.
Pengujian regresi (subset dari pengujian yang akan dieksekusi) berisi tiga kelas test case yang
berbeda, yaitu :
 Sampel respresentatif dari pengujian yang akan menggunakan semua fungsi

perangkat lunak.
 Pengujian tambahan yang berfokus pada fungsi-fungsi perangkat lunak yang mungkin
dipengaruhi oleh perubahan tersebut.
 Pengujian yang berfokus pada komponen perangkat lunak yang telah diubah.
 Pemilihan strategi integrasi, tergantung pada karakteristik perangkat lunak dan kadang-
kadang juga pada jadwal proyek.
 Secara umum, pendekatan yang digabungkan (sandwitch testing), yang menggunakan
strategi top-down untuk tingkat yang lebih tinggi dari struktur program, dipasangkan
dengan strategi bottom-up untuk tingkat subordinat.
 Pada saat pengujian integrasi dilakukan, penguji harus mengidentifikasi modul kritis.
Modul kritis memiliki karakteristik sebagai berikut :
1. menekankan beberapa persyaratan perangkat lunak.

2. memiliki tingkat kontrol yang tinggi.
3. Kompleks (cyclomatic complexity dapat digunakan sebagai indikator).
4. memiliki persyaratan kinerja yang terbatas.
Scope of Testing merangkum fungsi yang spesifik, kinerja dan karakteristik desain internal yang
akan diuji. Pengujian dibatasi ; kriteria perlengkapan dari masing-masing fase pengujian
digambarkan; dan batasan jadwal didokumentasikan.
Test Plan menggambarkan seluruh strategi integrasi. Pengujian dibagi ke dalam phases dan
builds yang menekankan fungsional spesifik dan karakteristik tingkah laku dari perangkat lunak
tersebut. Misalnya pengujian integrasi untuk sebuah sistem komputer yang berorientasi pada
grafik dapat dibagi ke dalam fase-fase pengujian sebagai berikut :
 Interaksi pemakai (seleksi perintah, representasi tampilan, pemrosesan dan respresentasi

kesalahan).
 Manipulasi dan analisis data (pembuatan simbol, penentuan dimensi, rotasi, komputasi
sifat fisis)
 Pemrosesan dan pemunculan tampilan (tampilan dua dimensi, tampilan tiga dimensi,
grafik dan bagan)
 Manajemen database (akses, update, integritas, kinerja)
Kriteria dan pengujian yang sesuai diaplikasikan untuk semua fase pengujian :
 Integritas interface. Antar muka internal dan eksternal diuji pada saat masing-masing
modul (kluster) ditambahkan ke dalam struktur.
 Validitas fungsional. Pengujian yang didesain untuk mengungkap kesalahan fungsional
yang dilakukan.
 Isi informasi. Pengujian yang didesain untuk mengungkap kesalahan yang berhubungan
dengan struktur data global atau lokal yang dilakukuan.
 Kinerja. Pengujian yang didesain untuk memeriksa batasan kinerja yang dibangun selama
desain perangkat lunak dilakukan.
VALIDATION TESTING (pengujian validasi)
 Dilakukan setelah integration testing dilakukan serta kesalahan-kesalahan yang

ditemukan telah diperbaiki.
 Validasi berhasil jika fungsi-fungsi yang ada pada perangkat lunak telah sesuai dengan
yang diharapkan oleh pemakai.
 Merupakan kumpulan pengujian black-box yang memperlihatkan atau menunjukkan
sesuai dengan yang diperlukan.
 Garis besar rencana pengujian dikerjakan dan prosedur pengujian didefinisikan dengan
test case yang spesifik untuk menunjukkan sesuai dengan yang diperlukan.
 Rencana dan prosedur dirancang untuk menjamin seluruh keperluan fungsional telah
terpenuhi, seluruh performansi dapat dicapai, dokumentasi dilakukan dengan benar.
Setelah pengujian dikerjakan, ada satu kemungkinan dari dua kondisi yang ada, yaitu :
1. Karakteristik performansi fungsi sesuai dengan spesifikasi dan dapat diterima.

2. Penyimpangan dari spesifikasi ditemukan dan daftar penyimpangan dibuat.
Kajian Konfigurasi
 Merupakan elemen penting dari proses validasi.

 Tujuannya untuk memastikan apakah semua elemen konfigurasi perangkat lunak telah
dikembangkan dengan tepat, dikatalog, dan memiliki detail yang perlu untuk mendukung
fase pemeliharaan dari siklus hidup perangkat lunak.
 Sering disebut audit.
ALPHA & BETA TESTING
 Sangat tidak mungkin bagi pengembang perangkat lunak untuk meramalkan bagaimana
pelanggan akan benar-benar menggunakan sebuah program.
 Instruksi yang digunakan dapat disalah-interprestasikan, kombinasi data yang aneh dapat
dipakai secara reguler, dan output yang kelihatannya sudah jelas bagi penguji tidak dapat
dimengerti oleh pemakai di lapangan.
 Bila perangkat lunak biasa dibangun bagi satu pelanggan, maka dapat acceptance test
dapat dilakukan untuk memungkinkan pelanggan memvalidasi semua persyaratan.
 Acceptance test dilakukan karena memungkinkan pelanggan untuk menemukan
kesalahan yang lebih terinci dan membiasakan pelanggan memahami perangkat lunak
yang telah dibuat.
 Jika perangkat lunak dikembangkan atau dibuat untuk dipakai oleh banyak pelanggan,
maka tidak praktis untuk melakukan pengujian satu per satu terhadap perangkat lunak
tersebut.
 Maka digunakan alpha dan beta testing.
 Alpha testing adalah tahap pengembangan, dimana perangkat lunak atau perangkat keras
yang telah dibuat dikirim ke kelompok pemakai atau pembeli yang potensial kemudian
mereka akan menggunakan produk ini untuk melaporkan jika produk itu gagal ?
 Pengujian aplha dilakukan pada sebuah lingkungan yang terkontrol.
 Pengujian beta dilakukan oleh pelanggan yang merupakan pemakai akhir perangkat
lunak.
 Pengujian beta merupakan sebuah aplikasi “live” dari perangkat lunak dalam suatu
lingkungan yang tidak dapat dikontrol oleh pengembang.
 Pelanggan merekam semua masalah yang ditemui selama pengujian beta dan
melaporkannya kepada pengembang.
 Pengembang melakukan modifikasi kemudian mempersiapkan pelepasan produk ke
seluruh pelanggan.
SYSTEM TESTING
 Perangkat lunak merupakan salah satu elemen dari sistem yang berbasis komputer yang
sangat besar.
 Perangkat lunak diintegrasi dengan elemen sistem lainnya (hardware, informasi) dan
serangkaian integrasi sistem dan validasi test dilakukan.
 Jika pengujian gagal atau diluar scope dari pengembangan sistem dan tidak hanya
dikerjakan oleh programmer, maka langkah yang diambil selama perancangan dan
pengujian dapat diperbaiki
 Peran analis sistem antara lain :
o Menangani kesalahan yang muncul dari elemen-elemen perangkat lunak
o Mengerjakan serangkaian pengujian
o Mencatat hasil pengujian.
o Berpartisipasi dalam perencanaan dan merangcang pengujian sistem untuk
menjamin kualitas perangkat lunak.
o System testing adalah sederetan pengujian yang berbeda-beda dengan tujuan
utama mengerjakan keseluruhan elemen dalam sistem yang telah dikembangkan.
Stress Testing (pengujian stres)
 Didesain untuk menghadapi situasi yang tidak normal pada saat program mengalami
pengujian.
 Dilakukan oleh sistem untuk kondisi-kondisi seperti volume data yang normal (melebihi
atau kurang dari batasan), frekuensi dll.
 Intinya penguji berusaha untuk merusak program.
Recovery Testing (pengujian perbaikan)
 Adalah pengujian sistem yang memaksa perangkat lunak untuk mengalami kegagalan
dalam berbagai cara dan melakukan verifikasi sesuai dengan performansi yang tepat.
 Banyak sistem yang berbasis komputer harus melindungi dari kesalahan dan melanjutkan
prosesnya dalam waktu yang telah ditentukan.
 Sistem harus toleran terhadap kesalahan. Kesalahan pemrosesan tidak boleh
menyebabkan keseluruhan fungsi sistem berhenti.
Security Testing (pengujian keamanan)
 Adalah pengujian yang akan melakukan verifikasi dari mekanisme perlindungan yang
akan dibuat oleh sistem, melindungi dari hal-hal yang mungkin terjadi.
 Penguji memerankan individu yang akan menembus sistem.
 Pengujian untuk mencoba menembus tingkat keamanan sebuah perangkat lunak.
 Strategi Sandwich Compromise, menguji perangkat lunak dengan melakukan pengujian

mulai dari entry-point tertentu kemudian bergerak keatas ataupun kebawah.
 Volume Testing, menguji perangkat lunak dengan memberi data yang berlebihan.
 Configuration Testing, menguji berbagai variasi perangkat lunak diberbagai lingkungan
perangkat lunak.
 Compatibility Testing, menguji kesesuaian sebuah perangkat lunak dengan sistem yang
sedang dimanfaatkan.
 Timing sistem, melakukan pengujian terhadap perangkat lunak untuk evaluasi terhadap
waktu tanggap dan waktu proses Yng dibutuhkan untuk menyelesaikan sebuah tugas.
 Enviromental Testing, menguji toleransi perangkat lunak terhadap suhu, kelembaban,
gerak dan perpindahan.
 Human Factor Testing, menguji antarmuka perangkat lunak bersama-sama dengan
pemakai.
Interface Testing (pengujian interface)
 Dilakukan ketika modul atau subsistem diintegrasi untuk membuat sistem yang lebih
besar.
 Setiap modul atau subsistem memiliki interface yang terdifinisi yang dipanggil oleh
komponen program lain.
 Tujuannya adalah untuk mendeteksi kesalahan yang mungkin telah masuk ke dalam
sistem karena eror interface atau asumsi invalid mengenai interface.
 Penting untuk pengembangan berorientasi objek
MODUL PERKULIAHAN
Modul Standar untuk

5 18017
Informasi
Abstract Kompetensi
Blackbox testing and Technique to Understanding Black box testing and its
implement a software testing with component
blackbox.
Black Box Testing
 Ÿ Metode pengujian black box berfokus pada keperluan fungsional dari perangkat lunak
dan domain informasi.
 Ÿ Analis sistem memperoleh kumpulan kondisi dari input yang akan mengerjakan
seluruh keperluan fungsional program.
 Ÿ Cenderung diaplikasikan selama tahap akhir pengujian.
 Ÿ Disebut juga pengujian behavioral/pengujian partisi/pengujian interface.
 Ÿ Memperhatikan dari sudut pandang Input data dan Output data.
 Perangkat lunak ditinjau sebagai kotak hitam yang menyalurkan input kepada output
berdasarkan rincian dimana perangkat lunak tersebut harus melakukannya.
 Periksa kecocokan dari pengujian S/W yang membentuk tingkah laku.
 Mencari kesalahan-kesalahan yang dihasilkan oleh kesalahan
 ŸKesalahan perangkat lunak adalah bagian dari perangkat lunak yang tidak menurut pada
penyedian definisi itu sendiri dalam dokumen pengembangan.
Tujuannya untuk mencari kesalahan-kesalahan pada :
 Fungsi yang salah atau hilang.

 Kesalahan pada interface.
 Kesalahan pada struktur data atau akses database.
 Kesalahan performansi (kinerja).
 Kesalahan initialisasi dan tujuan akhir.
Type dari pengujian black box :
2. Equivalence Class Partitioning. (pembagian kelas yang sama)
 Metode pengujian black box yang memecah atau membagi domain input dari suatu
program ke dalam kelas-kelas data.
 Perancangan test case berdasarkan evaluasi kelas equivalence untuk kondisi input.
 Kelas equivalence menggambarkan kumpulan keadaan yang valid dan tidak valid untuk
kondisi input.
 Kondisi input dapat berupa nilai numerik, range dari nilai, kumpulan nilai yang
berhubungan atau kondidi boolean.
Kelas equivalence dapat ditentukan sesuai pedoman berikut ini :
 Bila kondisi input menentukan suatu range, maka kelas equivalence valid dan dua yang
invalid ditentukan.
 Bila kondisi input membutuhkan suatu harga khusus, maka satu kelas equivalence valid
dan dua yang invalid ditentukan.
 Bila kondisi input menentukan anggota suatu himpunan, maka satu kelas equivalence
valid dan dua yang invalid ditentukan.
 Bila kondisi input adalah boolean, maka satu kelas dan satu yang tidak valid ditentukan.
Contoh :
Dalam persamaan matematika.
1 juta <= Gaji <= 5 juta
Valid : 1 juta samapi 5 juta
Invalid : kurang dari 1 juta lebih dari 5 juta
2. Boundary Value Analysis.(analisa penilaian terbatas)
 Untuk permasalahan yang tidak diketahui dengan jelas, akan cenderung menimbulkan
kesalahan pada domain output-nya.
 Pemilihan test case yang mengerjakan nilai-nilai yang telah ditentukan.
 Melengkapi equivalence class partitioning.
Petunjuk pemakaian BVA :
 Jika kondisi input berupa range yang dibatasi oleh nilai a dan b, test case harus dirancang
dengan nilai a dan b.
 Jika kondisi input ditentukan dengan sejumlah nilai, test case harus dikembangkan
dengan mengerjakan sampai batas maksimal dari nilai tersebut.
 Sesuai dengan 1 dan 2, untuk kondisi output harus dirancang test case sampai jumlah
maksimal.
 Untuk struktur data pada program juga harus dirancang sampai batas kemampuan.
2. Comparison Testing. (pengujian perbandingan)
 Perangkat keras dan perangkat lunak yang berlebihan memungkinkan untuk digunakan.
 Menggunakan team yang terpisah untuk mengembangkan versi-versi yang independent
dari perangkat lunak dengan menggunakan spesifikasi yang sama.
 Mencoba masing-masing versi dengan data yang sama untuk memastikan bahwa semua
versi memberikan output yang identik.
 Semua versi dieksekusi secara paralel dengan perbandingan real time hasil untuk
memastikan konsistensi.
 Output dari masing-masing versi sama implementasi benar.
 Output berbeda masing-masing versi dari aplikasi diperiksa untuk menentukan cacat pada
suatu versi (perbedaan jelas)
 Spesifikasi semua fungsi yang dikembangkan mengandung kesalahan, maka semua versi
kemungkinan besar merefleksikan kesalahan.
 Masing-masing versi independen identik tetapi tidak benar, maka pengujian kondisi akan
gagal mendeteksi kesalahan.
TESTING STAGES
Sasaran utama desain test case
untuk mendapatkan serangkaian pengujian yang memiliki kemungkinan tertinggi di dalam

pengungkapan kesalahan pada perangkat lunak.
Teknik yang digunakan
 Pengujian white-box (white–box testing)

 Pengujian black-box (black-box testing)
Pengujian white-box
 Berfokus pada struktur kontrol program.

 Pengujian dilakukan untuk memastikan bahwa semua statemen pada program telah
dieksekusi paling tidak satu kali selama pengujian dan semua kondisi telah diuji.
 Pengujian basis path, teknik pengujian white-box, menggunakan grafik program (matrik
grafik) untuk melakukan serangkaian pengujian yang independen secara linear yang
memastikan cakupan.
 Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program, dan
pengujian loop menyempurnakan teknik white box yang lain dengan memberikan sebuah
prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi.
 Implikasinya secara khusus diaplikasikan ke dalam komponen program yang kecil
(modul atau kelompok kecil dari modul).
Pengujian black-box
 Didesain untuk mengungkap kesalahan pada persyaratan fungsional tanpa

mengabaikan kerja internal dari suatu program.
 Berfokus pada domain informasi dari perangkat lunak.
 Melakukan teste case dengan mempartisi domain input dan output dari suatu program
dengan cara yang memberikan cakupan pengujian yang mendalam.
 Partisi ekivalensi (Equivalence Class Partitioning) membagi domain input kedalam kelas
data yang mungkin untuk melakukan fungsi perangkat lunak tertentu.
 Analisis nilai terbatas (Boundary Value Analysis) memeriksa kemampuan program untuk
menangani data pada patas yang dapat diterima.
 Pengujian perbandingan (Comparison Testing) mengembangkan perangkat lunak ke
dalam versi-versi yang independen dari suatu aplikasi dengan menggunakan spesifikasi
yang sama. Setiap versi diuji dengan data uji yang sama untuk memastikan bahwa
semua versi memberikan output yagn identik. Disebut juga pengujian back to
back.
Pengembang perangkat lunak yang berpengalaman sering mengatakan, “Pengujian tidak akan
pernah berakhir. Pengujian hanya berpindah dari Penguji ke pelanggan. Setiap pelanggan
menggunakan program tersebut, berarti suatu pengujian dilakukan.”
Dengan mengaplikasikan desain test case, perekayasa perangkat lunak dapat menapai pengujian
yang lebih lengkap sehingga dapat mengungkap dan melakukan koreksi sebelum “pengujian
pelanggan” dimulai.
TESTING STAGES (tingkatan pengujian
Validasi perangkat lunak (V & V) ditujukan untuk menunjukkan bahwa sistem sesuai dengan
spesifikasinya dan bahwa sistem memenuhi harapan pelanggan yang membelinya. Validasi
melibatkan proses pemeriksaan, seperti inspeksi dan peninjauan, pada setiap proses perangkat
lunak dari definisi persyaratan user sampai pengembangan program.
Validasi perangkat lunak adalah proses pemeriksaan untuk menjamin agar sistem telah sesuai
dengan spesifikasinya dan memenuhi kebutuhan sesungguhnya dari user sistem.
Namun demikian, mayoritas biaya validasi disediakan setelah implementasi sistem operasional
diuji.
 Untuk program-program kecil, sistem seharusnya tidak diuji sebagai sistem tunggal.
Sistem besar dibangun dari subsistem yang dibangun dari model yang terbuat dari
prosedur dan fungsi.
 Proses demikian dengan demikian harus dilakukan bertahap, dimana pengujian dilakukan
secara inkremental bersama dengan implementasi sistem.
 Proses pengujian terdiri dari 3 (tiga) tahap dimana komponen-komponen sistem diuji,
sistem yang terintegrasi diuji, dan akhirnya sistem diuji dengan data pelanggan.
 Idealnya, kesalahan komponen ditemukan dini pada proses dan masalah interface ketika
sistem diintegrasi.
 Namun demikian, dengan ditemukannya kesalahan, program harus didebug.
 Hal ini menuntut tahap proses pengujian ulang.
 Error pada komponen program, bisa muncul pada saat pengujian itegrasi.
 Proses dengan demikian bersifat iteratif, dengan informasi diumpan balik dari bagian
akhir ke bagian awal proses.
Tahap-tahap pada proses pengujian :
1. Unit Testing (pengujian unit).
 Komponen individual diuji untuk menjamin operasi yang benar.

 Setiap komponen diuji secara independen, tanpa komponen sistem yang lain.
2. Modul Testing (pengujian modul).
 Modul merupakan sekumpulan komponen yang berhubungan seperti kelas objek, atau
sekumpulan prosedur dan fungsi. Sebuah modul merangkum komponen-komponen yang
berhubungan, sehingga dapat diuji tanpa modul sistem yang lain.
3. Sub-system Testing (pengujian subsistem).
♠ Melibatkan pengujian sekumpulan modul yang telah diintegrasikan menjadi subsistem.
♠ Masalah yang sering muncul pada sistem perangkat lunak besar adalah ketidaksesuaian
interface.
♠ Proses pengujian subsistem dengan demikian harus terkonsentrasi pada deteksi kesalahan
interface modul dengan menjalankan interface ini berkali-kali.
4. System Testing (pengujian sistem).
 Subsistem diintegrasikan untuk membentuk sistem. Proses ini berkenaan dengan

penemuan kesalahan yang diakibatkan dari interaksi yang tidak diharapkan antara
subsistem dan masalah interface subsistem.
 Sistem pengujian secara keseluruhan dimana pengujian timbul karena sifat-sifat yang
baru.
 Pengujian atas penggabungan sistem perangkat lunak.
5. Acceptance Testing (pengujian penerimaan).
v Merupakan tahap akhir proses pengujian sebelum sistem diterima untuk penggunaan
operasional.
v Sistem diuji dengan data yang dipasok oleh pelanggan dan bukan data uji simulasi.
v Bisa menunjukkan kesalahan dan penghapusan definisi persyaratan sistem karena data riil
menjalankan sistem dengan cara yang berbeda dari data uji.
v Dapat mengungkap masalah persyaratan dimana fasilitas sistem tidak memenuhi keperluan
user atau kinerja sistem tidak dapat diterima.
 Pengujian unit dan pengujian modul biasanya merupakan tanggung jawab programmer
yang mengembangkan komponen tersebut. Programer membuat data uji sendiri dan
secara inkremental menguji kode pada saat dikembangkan. Pengujian ini sangat
ekonomis karena programmer adalah orang yang paling mengetahui komponen tersebut
dan merupakan orang terbaik untuk membuat data uji.
 Tahap berikutnya mencakup integrasi dari sejumlah programmer dan harus direncanakan
sebelumnya. Suatu tim penguji independent harus bekerja dari rencana uji pra-formulasi
yang dikembangkan dari spesifikasi dan rancangan sistem.
 Pengujian penerimaan kadang-kadang disebut pengujian alpha. Sistem yang
diperlihatkan dikembangkan untuk satu klien. Proses pengujian alpha berlanjut sampai
pengembang sistem dan pelanggan setuju bahwa sistem yang diserahkan merupakan
implementasi yang dapat diterima dari persyaratan sistem.
MODUL PERKULIAHAN
Modul Standar untuk

6 18017
Informasi
Abstract Kompetensi
Software Testing in Object Oriented Understanding Software Testing in
Analysis and Design Object Oriented Analysis and Design
OBJECT ORIENTED TESTING (pengujian berorientasi objek)
 Pengujian operasi individual yang berhubungan dengan objek. Merupakan fungsi atau
prosedur dan dapat digunakan pendekatan black-box dan white-box.
 Pengujian kelas objek individu. Prinsip pengujian black-box tidak berubah tetapi
pengertian kelas ekuivalensi harus diperluas untuk mencakup rangkaian operasi yang
berhubungan. Dengan cara yang sama, pengujian struktural membutuhkan jenis analisis
yang berbeda.
 Pengujian kelompok objek. Integrasi top-down dan bottom-up yang ketat tidak sesuai
untuk membuat kumpulan objek yang berhubungan. Pengujian berdasar skenario yang
digunakan.
 Pengujian sistem berorientasi objek. Verifikasi dan validasi terhadap spesifikasi
persyaratan sistem dilakukan dengan cara yang tepat sama sebagaimana untuk jenis
sistem yang lain.
Object Integration (integrasi objek)
 Pengujian use-case atau basis skenario. Mendeskripsikan satu model penggunaan sistem.
Pengujian dapat didasarkan atas deskripsi skenario ini dan kelompok objek yang dibuat
untuk mendukung use-case yang berhubungan dengan model penggunaan tersebut.
 Pengujian thread. Berdasar pengujian respon sistem terhadap suatu input atau set event
input tertentu. Sistem berorientasi objek seringkali dikendalikan event sehingga
merupakan bentuk pengujian yang sesuai. Untuk memakai pendekatan ini, kita harus
mengidentifikasi cara pemrosesan event menelusuri jalannya melalui sistem.
 Pengujian interaksi objek.
o Diusulkan oleh Jorgensen dan Erikson.
o Tingkat menengah dari pengujian integrasi dapat didasarkan atas identifikasi
jalur.
o Jalur melalui serangkaian interaksi objek yang berhenti ketika operasi objek tidak
memanggil layanan objek lain.
Tiga hal yang harus dilakukan untuk menguji sistem OO :
1. Definisi pengujian harus diperluas untuk mencakup teknik penemuan kesalahan yang
diaplikasikan ke model OOA dan OOD.
2. Strategi untuk pengujian unit dan terintegrasi harus berubah secara signifikan.
3. Desain test case harus bertanggung jawab terhadap karakteristik unik perangkat lunak
OO.
Model Pengujian OOA dan OOD
 Model desain dan analisis tidak dapat diuji dalam arti yang konvensional, karena model
tersebut tidak dapat dieksekusi.
 Kajian teknis formal dapat digunakan untuk menguji kebenaran dan konsistensi model
analisis maupun model desain.
Kebenaran Model OOA dan OOD
 Notasi dan sintaks digunakan untuk merespresentasikan model analisis dan desain.
 Kebenaran sintaks dinilai pada penggunaan simbol yang teratur.
 Masinag-masig model dikaji untuk memastikan apakah konvensi pemodelan yang tepat
telah terjaga.
Konsistensi Model OOA dan OOD
 mempertimbangkan hubungan antar entitas di dalam model tersebut.

 masing-masing kelas dan koneksinya ke kelas lain harus diuji.
 desain sistem dikaji dengan menguji model tingkah laku objek yang dikembangkan
selama OOA.
Metode Pengujian Berorientasi Objek
Pengujian sistem berorientasi objek umumnya dilakukan secara bottom-up dalam empat level :
1. Pengujian level metode yang menguji metode individu di kelas.

2. Metode-metode dan atribut-atribut yang menyusun kelas. Pengujian level kelas (intra
kelas) adalah pengujian terhadap interaksi-interaksi di antara komponen-komponen di
satu kelas individu.
3. Kelas-kelas yang bekerja sama menyusun tandan kelas (class cluster). Pengujian tandan
kelas menguji interaksi-interaksi di antara kelas-kelas.
4. Tandan-tandan kelas menyusun sistem. Pengujian level sistem berurusan dengan
masukan dan keluaran yang tampak bagi pemakai sistem.
Stratregi pengujian berorientasi objek
Strategi klasik pengujian perangkat lunak :
 Dimulai dari pengujian unit, bergerak menuju pengujian integrasi dan berakhir pada
validasi dan pengujian sistem.
 Pengujian unit berfokus pada satuan program kecil yang dapat di-compile.
 Unit diintegrasikan dengan suatu struktur program.
 Pengujian regresi dijalankan untuk mengungkap kesalahan sehubungan dengan
interfacing modul dan efek samping yang disebabkan oleh penambahan unit-unit baru.
 Sistem secara keseluruhan diuji untuk memastikan apakah kesalahan terungkap.
Perubahan strategi pengujian pada pendekatan berorientasi objek
 Pengujian unit, monsep mengenai unit diperluas di sistem berorientasi objek.
 Pengujian integrasi, integrasi berfokus pada kelas-kelas dan eksekusinya pada satu thread
atau use case.
Pengujian validasi, menggunakan pengujian kotak hitam tradisional
MODUL PERKULIAHAN
Modul Standar untuk

7 18017
Informasi
Abstract Kompetensi
Stratefy of Software Testing Approach Understanding Stratefy of Software
and Validation Testing Testing Approach and Validation
Testing
STRATEGI PENGUJIAN PERANGKAT LUNAK
 Strategi untuk pengujian perangkat lunak mengintegrasikan metode desain test case
perangkat lunak ke dalam sederetan langkah yang direncanakan dengan baik, hasilnya
adalah konstruksi perangkat lunak yang berhasil.
 Strategi pengujian perangkat lunak memberikan sebuah peta jalan bagi pengambang
perangkat lunak, organisasi jaminan kualitas, dan pelanggan.
 Peta jalan menggambarkan langkah-langkah yang akan dilakukan sebagai bagian dari
pengujian, kapan langkah-langkah itu direncanakan dan kemudian dijalankan, serta
berapa banyak usaha, waktu, dan sumber daya yang dibutuhkan.
 Strategi pengujian menggabungkan perencanan pengujian, desain test case, dan
kumpulan data resultan (hasil) serta evaluasi.
Kesimpulan :
 Strategi pengujian perangkat lunak memudahkan para perancang untuk menentukan

keberhasilan dari sistem yang telah dikerjakan.
 Hal yang harus diperhatikan adalah langkah-langkah perencanaan dan pelaksanaan
harus direncanakan dengan baik dan berapa lama waktu, upaya dan sumber daya yang
diperlukan.
Pendekatan Strategis ke pengujian perangkat lunak
Pengujian adalah serangkaian aktivitas yang dapat direncanakan sebelumnya dan dilakukan
secara sistematis. Karena ituah harus ditentukan suatu template untuk desain perangkat lunak –
serangkaian langkah yang di dalamnya kita dapat menempatkan metode desain test case yang
spesifik – untuk proses rekayasa perangkat lunak.
Banyak strategi pengujian yang dapat digunakan, tetapi secara umum mempunyai karakteristik
sebagai berikut :
 Pengujian dimulai pada tingkat modul yang palin bawah, dilanjutkan dengan modul di
atasnya kemudian hasilnya dipadukan.
 Teknik pengujian yang berbeda mungkin akan menghasilkan sedikit perbedaan dalam hal
waktu.
 Pengujian dilakukan oleh pengembang perangkat lunak dan (untuk proyek yang
besar) suatu kelompok pengujian yang independen.
 Pengujian dan debugging merupakan aktivitas yang berbeda, tetapi debugging termasuk
dalam strategi pengujian.
Pengujian perangkat lunak adalah suatu elemen dari topik yang sangat luas dimana dapat disebut
sebagai verifikasi dan validasi (V & V).
Verifikasi adalah kumpulan aktivitas yang menjamin bahwa perangkat lunak benar-benar sesuai
dengan fungsinya.
Validasi adalah serangkain aktivitas yang berbeda yang memastikan bahwa perangkat lunak
yang dibangun dapat sesuai dengan kepeluan pelanggan.
Strategi pengujian perangkat lunak
v Proses rekayasa perangkat lunak dapat juga dipandang sebagai sebuah bentuk spiral.
v Pada awalnya, rekayasa sistem menentukan peran perangkat lunak dan membawa kepada
analis persyaratan di mana domain informasi, fungsi, tingkah laku dan kinerja validasi bagi
perangkat lunak di bangun.
v Dengan bergerak dalam sepanjang spiral, kita akan sampai ke desain dan akhirnya ke
pengkodean.
 Unit testing dimulai pada pusaran spiral dan terpusat pada masing-masing satuan
perangkat lunak pada saat diimplementasikan di dalam kode sumber.
 Pengujian berjalan dengan bergerak keluar sepanjang spiral ke integration testing di
mana fokusnya adalah desain dan konstruksi arsitektur perangkat lunak.
 Dengan mengambil urutan keluar lainnya di dalam spiral, akan sampai ke validation
testing di mana persyaratan yang dibangun sebagai bagian dari analisis persyaratan
perangkat lunak di validasi terhadap perangkat lunak yang telah dikonstruksi.
 Akhirnya sampai pada system tesing di mana perangkat lunak dan elemen sistem yang
lain diuji secara keseluruhan.
Dengan mempertimbangkan proses dari titik pandang prosedural, pengujian di dalam konteks
rekayasa perangkat lunak secara aktual merupakan 4 (empat) langkah yang diimplementasi
secara berurutan.
1. Pada awalnya, pengujian berfokus pada setiap modul secara individual, dengan
memastikan bahwa modul berfungsi secara tepat sebagai suatu unit, karena itu dinamakan
unit testing. Menggunakan metoda pengujian white-box. Selanjutnya modul
diintegrasikan untuk membentuk paket perangkat lunak yang lengkap.
2. Integration testing menekankan pada masalah-masalah yang berhubungan dengan
masalah-masalah verifikasi dan konstruksi program. Mengunakan teknik pengujian
black-box.
3. Validation testing memberikan jaminan akhir di mana perangkat lunak harus memenuhi
semua persyaratan fungsional, tingkah laku dan kinerja. Teknik pengujian black-box
digunakan secara eksklusif selama validasi. Perangkat lunak, sekali divalidasi, harus
dikombinasikan dengan elemen sistem yang lain (hardware, manusia, database).
4. Pengujian sistem membuktikan bahwa semua elemen sistem saling bertautan dengan
tepat dan keseluruhan fungsi/kinerja sistem dapat dicapai.
UNIT TESTING (pengujian unit)
Pengujian berfokus pada usaha verifikasi pada unit terkecil dari desain perangkat lunak, yakni
modul. Dengan menggunakan deskripsi desain terinci sebagai panduan, jalur kontrol yang
penting diuji untuk mengungkap kesalahan di dalam batas dari modul tersebut. Kompleksitas
dari pengujian dan kesalahan ditentukan berdasarkan scope modul. Pengujian unit selalu
berorientasi ke white-box testing dan dapat dikerjakan dengan paralel atau berurutan dengan
modul-modul yang lainnya.
Unit Testing
 Unit individu diuji secara terpisah.

 Unit mungkin menjadi fungsi-fungsi sendiri, prosedur atau program.
 Dikerjakan secara meningkat, biasanya oleh programmer sendiri yang memberikan
kodenya.
 Kebanyakan white-box testing cocok untuk tingkatan ini.
 Susunan data ujian lokal, kondisi boundary, path independent dan path penanganan
kesalahan.
 Tak resmi, rencana ujian tidak resmi, jelas dan tertulis.
 Interface diuji untuk menjamin informasi yang mengalir masuk dan keluar dari unit
program telah tepat atau sesuai dengan yang diharapkan.
 Struktur data lokal dikerjakan untuk menjamin penyimpanan data selalu muthakir.
 Kondisi batasan-batasan adalah pengujian untuk menjamin modul-modul dioperasikan
sesuai dengan batasannya.
 Independent path untuk menjamin seluruh perintah dalam modul telah bekerja dengan
baik.
 Penanganan kesalahan kesalahan merupakan langkah terakhir dalam tahap ini.
Prosedur pengujian unit.
 Pengujian unit pada umumnya merupakan perkembangan dari langkah pengkodean.

 Setelah program sumber dikembangkan, ditinjau kembali dan diverifikasi untuk
sintaknya, maka perancangan test case di mulai.
 Peninjauan kembali perancangan informasi akan menyediakan petunjuk untuk
menentukan test case.
 Karena modul bukan program yang berdiri sendiri, maka driver (pengendali) dan atau
stub perangkat lunak harus dikembangkan untuk tiap-tiap pengujian unit.
MODUL TESTING (pengujian modul)
 Pengujian interaksi dari semua komponen yang berhubungan terhadap modul.

 Pengujian modul yang indpendent.
 Modul secara individu diuji secara terpisah.
 Modul berupa kumpulan fungsi, prosedure atau program-program.
 Tidak secara increment, biasanya dilakukan oleh seorang programmer yang membuat
program tersebut.
 Menggunakan stub dan driver.
 Pengujian whit-box cocok untuk tingkatan ini.
 Pengujian struktur data lokal, kondisi batasan, jalur independen, jalur penanganan
kesalahan.
 Formal : rencana pengujian dijelaskan dan tertulis.
 Modul bukanlah program yang berdiri sendiri, perangkat lunak driver dan atau stub harus
dikembangkan bagi masing-masing pengujian unit.
 Pada sebagian besar aplikasi, driver tidak lebih dari sebuah “program utama”, yang
menerima data test case.
 Data sampai ke modul untuk diuji, dan kemudian mencetak hasil yang relevan.
 Stub berfungsi untuk menggantikan modul yang merupakan subordinat dari modul yang
akan diuji.
 Stub menggunakan interface modul subordinat untuk melakukan manipulasi data
minimal, mencetak , entri dan kembali.
INTEGRATION TESTING (pengujian integrasi)
♪ Pengujian integrasi adalah teknik yang sistematis untuk mengkonstruksi susunan program
sambil melakukan pengujian untuk memeriksa kesalahan yang nantinya digabungkan dengan
interface.
♪ Sasarannya adalah untuk mengambil modul yang dikenai pengujian unit dan membangun
struktur program yang telah ditentukan oleh desain.
♪ Kesulitannya adalah lokalisasi error yang sulit ditemukan pada saat proses.
♪ Terdapat interaksi yang rumit antara komponen sistem dan ketika ditemukan output yang
menyimpang, mungkin sulit untuk menemukan sumber error tersebut.
Integrasi non-inkremental
Program diuji sebagai satu kesatuan. Serangkaian kesalahan akan terjadi. Koreksi sulit dilakukan
karena isolasi penyebab diperumit oleh luasnya program keseluruhan. Sekali kesalahan tersebut
dibetulkan, maka akan muncul lagi yang baru dan proses itu terus berlanjut dalam loop yang
kelihatannya tidak akan pernah berhenti.
Integrasi inkremental
Program dibangun dan diuji di dalam segmen-segmen kecil, sehingga kesalahan lebih mudah
diisolasi dan dibetulkan, interface lebih mungkin untuk diuji secara lengkap, dan pendekatan
pengujian yang sistematis dapat diaplikasikan.
Top-down Integrasi
 adalah pendekatan inkremental terhadap struktur program.

 Modul diintegrasikan dengan menggerakkan ke bawah melalui hirarki kontrol, dimulai
dengan modul kontrol utama (program utama).
 Memverifikasi kontrol utama dan keputusan pada saat awal proses pengujian.
 Pada struktur program yang dibuat dengan baik, keputusan akan dikerjakan pada tingkat
atas hirarki.
 Stub mengganti modul tingkat rendah pada awal pengujian top-down, sehingga tidak ada
data yang penting yang dapat mengalir ke atas di dalam struktur program.
Proses integrasi dilakukan dalam 5 (lima) langkah :
6. Modul kontrol utama digunakan sebagai test driver, dan stub ditambahkan pada semua
modul yang secara langsung subordinat terhadap modul kontrol utama.
7. Stub subordinat diganti pada suatu saat dengan modul aktual.
8. Pengujian dilakukan pada saat masing-masing modul diintegrasi.
9. Pada pelengkapan masing-masing rangkaian pengujian, stub yang lain diganti dengan
modul real.
10. Pengujian regresi dapat dilakukan untuk memastikan bahwa kesalahan baru belum
dimunculkan.
Bottom-up Integrasi
 Dapat dinyatakan dengan penyusunan yang dimulai dan diuji dengan atomic modul
(modul tingkat paling bawah pada struktur program).
 Modul diintegrasikan dari bawah ke atas sehingga pemrosesan yang diperlukan untuk
modul subordinat yang selalu diberikan akan selalu tersedia dan kebutuhan akan stub
dapat dieliminasi.
Strategi bottom-up integration dapat diterapkan dengan urutan langkah-langkah sebagai berikut :
5. Modul tingkat bawah digabungkan ke dalam cluster (sering disebut build) yang
malakukan subfungsi perangkat lunak spesifik.
6. Driver (program kontrol untuk pengujian) ditulis untuk mengkoordinasi input dan output
test case.
7. Cluster diuji.
8. Driver diganti dan cluster digabungkan dengan menggerakkannya ke atas di dalam
struktur program.
Regression Testing (pengujian regresi)
 adalah aktivitas yang membantu memastikan bahwa perubahan (karena pengujian atau
alasan lain) tidak menimbulkan tingkah laku yang tidak diharapkan atau kesalahan
tambahan.
 Merupakan eksekusi ulang dari beberapa subset yang telah dilakukan untuk memastikan
bahwa perubahan tidak menimbulkan efek samping yang tidak diharapkan.
 Pengujian yang berhasil akan menghasilkan kesalahan, dan setiap kesalahan harus
dikoreksi.
 Setiap kali perangkat lunak dikoreksi, maka banyak aspek konfigurasi perangkat lunak
(program, dokumentasi atau data yang mendukung) akan diubah.
Pengujian regresi (subset dari pengujian yang akan dieksekusi) berisi tiga kelas test case yang
berbeda, yaitu :
 Sampel respresentatif dari pengujian yang akan menggunakan semua fungsi

perangkat lunak.
 Pengujian tambahan yang berfokus pada fungsi-fungsi perangkat lunak yang mungkin
dipengaruhi oleh perubahan tersebut.
 Pengujian yang berfokus pada komponen perangkat lunak yang telah diubah.
 Pemilihan strategi integrasi, tergantung pada karakteristik perangkat lunak dan kadang-
kadang juga pada jadwal proyek.
 Secara umum, pendekatan yang digabungkan (sandwitch testing), yang menggunakan
strategi top-down untuk tingkat yang lebih tinggi dari struktur program, dipasangkan
dengan strategi bottom-up untuk tingkat subordinat.
 Pada saat pengujian integrasi dilakukan, penguji harus mengidentifikasi modul kritis.
Modul kritis memiliki karakteristik sebagai berikut :
5. menekankan beberapa persyaratan perangkat lunak.

6. memiliki tingkat kontrol yang tinggi.
7. Kompleks (cyclomatic complexity dapat digunakan sebagai indikator).
8. memiliki persyaratan kinerja yang terbatas.
Scope of Testing merangkum fungsi yang spesifik, kinerja dan karakteristik desain internal yang
akan diuji. Pengujian dibatasi ; kriteria perlengkapan dari masing-masing fase pengujian
digambarkan; dan batasan jadwal didokumentasikan.
Test Plan menggambarkan seluruh strategi integrasi. Pengujian dibagi ke dalam phases dan
builds yang menekankan fungsional spesifik dan karakteristik tingkah laku dari perangkat lunak
tersebut. Misalnya pengujian integrasi untuk sebuah sistem komputer yang berorientasi pada
grafik dapat dibagi ke dalam fase-fase pengujian sebagai berikut :
 Interaksi pemakai (seleksi perintah, representasi tampilan, pemrosesan dan respresentasi

kesalahan).
 Manipulasi dan analisis data (pembuatan simbol, penentuan dimensi, rotasi, komputasi
sifat fisis)
 Pemrosesan dan pemunculan tampilan (tampilan dua dimensi, tampilan tiga dimensi,
grafik dan bagan)
 Manajemen database (akses, update, integritas, kinerja)
Kriteria dan pengujian yang sesuai diaplikasikan untuk semua fase pengujian :
 Integritas interface. Antar muka internal dan eksternal diuji pada saat masing-masing
modul (kluster) ditambahkan ke dalam struktur.
 Validitas fungsional. Pengujian yang didesain untuk mengungkap kesalahan fungsional
yang dilakukan.
 Isi informasi. Pengujian yang didesain untuk mengungkap kesalahan yang berhubungan
dengan struktur data global atau lokal yang dilakukuan.
 Kinerja. Pengujian yang didesain untuk memeriksa batasan kinerja yang dibangun selama
desain perangkat lunak dilakukan.
VALIDATION TESTING (pengujian validasi)
 Dilakukan setelah integration testing dilakukan serta kesalahan-kesalahan yang

ditemukan telah diperbaiki.
 Validasi berhasil jika fungsi-fungsi yang ada pada perangkat lunak telah sesuai dengan
yang diharapkan oleh pemakai.
 Merupakan kumpulan pengujian black-box yang memperlihatkan atau menunjukkan
sesuai dengan yang diperlukan.
 Garis besar rencana pengujian dikerjakan dan prosedur pengujian didefinisikan dengan
test case yang spesifik untuk menunjukkan sesuai dengan yang diperlukan.
 Rencana dan prosedur dirancang untuk menjamin seluruh keperluan fungsional telah
terpenuhi, seluruh performansi dapat dicapai, dokumentasi dilakukan dengan benar.
Setelah pengujian dikerjakan, ada satu kemungkinan dari dua kondisi yang ada, yaitu :
3. Karakteristik performansi fungsi sesuai dengan spesifikasi dan dapat diterima.

4. Penyimpangan dari spesifikasi ditemukan dan daftar penyimpangan dibuat.
Kajian Konfigurasi
 Merupakan elemen penting dari proses validasi.

 Tujuannya untuk memastikan apakah semua elemen konfigurasi perangkat lunak telah
dikembangkan dengan tepat, dikatalog, dan memiliki detail yang perlu untuk mendukung
fase pemeliharaan dari siklus hidup perangkat lunak.
 Sering disebut audit.
ALPHA & BETA TESTING
 Sangat tidak mungkin bagi pengembang perangkat lunak untuk meramalkan bagaimana
pelanggan akan benar-benar menggunakan sebuah program.
 Instruksi yang digunakan dapat disalah-interprestasikan, kombinasi data yang aneh dapat
dipakai secara reguler, dan output yang kelihatannya sudah jelas bagi penguji tidak dapat
dimengerti oleh pemakai di lapangan.
 Bila perangkat lunak biasa dibangun bagi satu pelanggan, maka dapat acceptance test
dapat dilakukan untuk memungkinkan pelanggan memvalidasi semua persyaratan.
 Acceptance test dilakukan karena memungkinkan pelanggan untuk menemukan
kesalahan yang lebih terinci dan membiasakan pelanggan memahami perangkat lunak
yang telah dibuat.
 Jika perangkat lunak dikembangkan atau dibuat untuk dipakai oleh banyak pelanggan,
maka tidak praktis untuk melakukan pengujian satu per satu terhadap perangkat lunak
tersebut.
 Maka digunakan alpha dan beta testing.
 Alpha testing adalah tahap pengembangan, dimana perangkat lunak atau perangkat keras
yang telah dibuat dikirim ke kelompok pemakai atau pembeli yang potensial kemudian
mereka akan menggunakan produk ini untuk melaporkan jika produk itu gagal ?
 Pengujian aplha dilakukan pada sebuah lingkungan yang terkontrol.
 Pengujian beta dilakukan oleh pelanggan yang merupakan pemakai akhir perangkat
lunak.
 Pengujian beta merupakan sebuah aplikasi “live” dari perangkat lunak dalam suatu
lingkungan yang tidak dapat dikontrol oleh pengembang.
 Pelanggan merekam semua masalah yang ditemui selama pengujian beta dan
melaporkannya kepada pengembang.
 Pengembang melakukan modifikasi kemudian mempersiapkan pelepasan produk ke
seluruh pelanggan.
SYSTEM TESTING
 Perangkat lunak merupakan salah satu elemen dari sistem yang berbasis komputer yang
sangat besar.
 Perangkat lunak diintegrasi dengan elemen sistem lainnya (hardware, informasi) dan
serangkaian integrasi sistem dan validasi test dilakukan.
 Jika pengujian gagal atau diluar scope dari pengembangan sistem dan tidak hanya
dikerjakan oleh programmer, maka langkah yang diambil selama perancangan dan
pengujian dapat diperbaiki
 Peran analis sistem antara lain :
o Menangani kesalahan yang muncul dari elemen-elemen perangkat lunak
o Mengerjakan serangkaian pengujian
o Mencatat hasil pengujian.
o Berpartisipasi dalam perencanaan dan merangcang pengujian sistem untuk
menjamin kualitas perangkat lunak.
o System testing adalah sederetan pengujian yang berbeda-beda dengan tujuan
utama mengerjakan keseluruhan elemen dalam sistem yang telah dikembangkan.
Stress Testing (pengujian stres)
 Didesain untuk menghadapi situasi yang tidak normal pada saat program mengalami
pengujian.
 Dilakukan oleh sistem untuk kondisi-kondisi seperti volume data yang normal (melebihi
atau kurang dari batasan), frekuensi dll.
 Intinya penguji berusaha untuk merusak program.
Recovery Testing (pengujian perbaikan)
 Adalah pengujian sistem yang memaksa perangkat lunak untuk mengalami kegagalan
dalam berbagai cara dan melakukan verifikasi sesuai dengan performansi yang tepat.
 Banyak sistem yang berbasis komputer harus melindungi dari kesalahan dan melanjutkan
prosesnya dalam waktu yang telah ditentukan.
 Sistem harus toleran terhadap kesalahan. Kesalahan pemrosesan tidak boleh
menyebabkan keseluruhan fungsi sistem berhenti.
Security Testing (pengujian keamanan)
 Adalah pengujian yang akan melakukan verifikasi dari mekanisme perlindungan yang
akan dibuat oleh sistem, melindungi dari hal-hal yang mungkin terjadi.
 Penguji memerankan individu yang akan menembus sistem.
 Pengujian untuk mencoba menembus tingkat keamanan sebuah perangkat lunak.
 Strategi Sandwich Compromise, menguji perangkat lunak dengan melakukan pengujian

mulai dari entry-point tertentu kemudian bergerak keatas ataupun kebawah.
 Volume Testing, menguji perangkat lunak dengan memberi data yang berlebihan.
 Configuration Testing, menguji berbagai variasi perangkat lunak diberbagai lingkungan
perangkat lunak.
 Compatibility Testing, menguji kesesuaian sebuah perangkat lunak dengan sistem yang
sedang dimanfaatkan.
 Timing sistem, melakukan pengujian terhadap perangkat lunak untuk evaluasi terhadap
waktu tanggap dan waktu proses Yng dibutuhkan untuk menyelesaikan sebuah tugas.
 Enviromental Testing, menguji toleransi perangkat lunak terhadap suhu, kelembaban,
gerak dan perpindahan.
 Human Factor Testing, menguji antarmuka perangkat lunak bersama-sama dengan
pemakai.
Interface Testing (pengujian interface)
 Dilakukan ketika modul atau subsistem diintegrasi untuk membuat sistem yang lebih
besar.
 Setiap modul atau subsistem memiliki interface yang terdifinisi yang dipanggil oleh
komponen program lain.
 Tujuannya adalah untuk mendeteksi kesalahan yang mungkin telah masuk ke dalam
sistem karena eror interface atau asumsi invalid mengenai interface.
 Penting untuk pengembangan berorientasi objek
MODUL PERKULIAHAN
Modul Standar untuk

9 18017
Fasilkom Program Tim Dosen
Studi Sistem
Informasi
Abstract Kompetensi
Produktivitas dan Kualitas Perangkat Mengerti dan Memahami Kualitas dan
Lunak Produktivitas Perangkat Lunak
KUALITAS PERANGKAT LUNAK:
Definisi, Pengukuran dan Implementasi
Definisi
Berbagai macam definisi kualitas perangkat lunak (software quality) tergantung dari mana pemakai
(user) memandang dan melihat sesuai dengan kebutuhannya. Menurut Crosby (1979:34) mendefinisikan
kualitas atau mutu sebagai “conformance to requirements”. Selama seseorang dapat berdebat tentang
perbedaan antara kebutuhan, keinginan dan kemauannya, definisi kualitas harus mempertimbangkan
perspektif pemakai tersebut. Kunci utama pertanyaan untuk sebuah definisi kualitas adalah siapa
pemakainya, apa yang penting bagi merekadan bagaimana prioritasnya tentang metode apa yang
dibangun, dibungkus untuk mendukung sebuah produk?
Untuk menjawab pertanyaan tersebut, kita harus mengenali herarki dari kualitas perangkat lunak.
Pertama, suatu produk perangkat lunak harus menyediakan fungsi suatu jenis dan waktu yang sama
ketika pemakai memerlukannya. Kedua, produk harus berjalan. Jika produk memiliki kecacatan maka
produk tersebut tentunya tidak ada konsistensi kelayakan. Para pemakai tidak akan menggunakannya
dengan mengabaikan atribut-atribut yang menyertainya. Hal tersebut tidak berarti bahwa kecacatan
selalu menjadi prioritas yang paling utama dalam menolak suatu produk tetapi akan menjadi sangat
penting dalam melihat layak atau tidaknya. Jika tingkatan cacat minimum belum dicapai maka berbagai
hal tidak ada yang perlu dipertimbangkan. Di luar ambang kualitas tersebut, bagaimanapun juga sesuatu
yang berhubungan dengan pertimbangan dan penilaian cacat suatu produk perangkat lunak seperti
halnya kegunaan, kecocokan, kemampuan, dan lainnya tergantung pada pemakai tersebut memandang
dan menilainya termasuk didalamnya aplikasinya dan lingkungan software yang menyertainya
(Humphrey, 1994).
The Institute of Electrical and Electronic Engineers (IEEE) mendefinisikan
kualitas sebagai “the degree to which a system, component or process meets customer or user needs
or expectations” (IEEE90). Definisi dari IEEE digunakan dalam konteks suatu sistem perangkat lunak
secara rinci. kualitas adalah suatu atribut dari sistem yang berjalan yang sangat erat kaitannya dengan
resiko. Semakin tinggi resiko yang didapatkan dan kemudian dikuranginya maka akan tinggi kualitas
yang dihasilkannya. Dengan cara yang sama, lebih cepat resiko dikenali dan dikurangi, akan lebih tinggi
pula kualitasnya. Hasil dari sebuah aktivitas yang terencana, bukan kejadian yang spontan berbanding
terbalik dengan delivery date 85% kesalahan ada pada proses,15% pada pada SDM.
Menurut definisi dalam Steve McConnell’s Code Complete membagi perangkat lunak ke dalam dua hal
yaitu: : internal dan external quality characteristics. Karakteristik kualitas eksternal merupakan bagian-
bagian dari suatu produk yang berhubungan dengan para pemakainya, sedangkan karakteristik kualitas
internal tidak secara langsung berhubungan dengan pemakai. Software Quality didefinisikan sebagai:
kesesuaian yang diharapkan pada semua software yang dibangun dalam hal fungsi software yang
diutamakan dan unjuk kerja software, standar pembangunan software yang terdokumentasi dan
karakteristik yang ditunjukkan oleh software. Definisi ini menekankan pada 3 hal yaitu:
1. kebutuhan software adalah fondasi ukuran kualitas software, jika software Tidak sesuai dengan
kebutuhan yang ditentukan maka kualitaspun kurang
2. jika menggunakan suatu standar untuk pembangunan software maka jika software tidak
memenuhi standar tersebut maka dianggap kurang berkualitas
3. seringkali ada kualitas yang secara langsung diutarakan (tersirat) seperti kemudahan
penggunaan dan pemeliharaan yang baik. Kualitas software dipertanyakan jika tidak memenuhi
kebutuhan ini.
Sedangkan definisi kualitas menurut The International Organization for Standarization (ISO)
mendefinisikannya sebagai: “the totality of features and characteristics of a product or service that
bear on its ability to satisfy specified or implied needs [11].” ISO menyoroti pada fitur-fitur dan
karakteristik dari produk atau layanan dalam kemampuannya memenuhi kebutuhan yang ditentukan.
menyediakan model yang berbasikan obyek dalam 3 konteks dasar yaitu: quality, requirements dan
characteristics. Standar dapat membantu mendefinisikan suatu terminologi, seperti halnya kata
“kualitas” (quality). Meskipun demikian, rata-rata suatu kata tertentu tidak menggunakan standar
adalah sering sesuai dengan arti yang dimaksud. Hal ini juga benar untuk definisi ISO 8204 untuk mutu:
“Keseluruhan karakteristik dari suatu kesatuan dalam kemampuannya untuk memenuhi dan
memuaskan pemakai yang dinyatakan dan disiratkan dalam suatu kebutuhan.“ Makna tersebut artinya,
diperlukan suatu kualitas produk perangkat lunak yang mempunyai karakteristik tertentu yang
dihubungkan dengan kebutuhan pemakai dan membuat puas penggunanya. Kualitas perangkat lunak
adalah keberadaan karakteristik dari suatu produk ang dijabarkan dalam kebutuhannya, artinya kita
harus melihat terlebih dahulu karakteristik-karakteristik apa yang berhubungan atau tidak dengan
kebutuhankebutuhan yang diiinginkan oleh pemakai. Karakteristik yang dimaksud yaitu contra-
productive characteristics dan neutral characteristic. Mengetahui
karakteristik tersebut diperlukan untuk mengurangi kontra produktif dari kualitas perangkat lunak yang
dimaksud dan relevan atau tidak perangkat lunak tersebut untuk kebutuhan suatu organisasi. Tidak
hanya adanya keberadaan karakteristik tersebut tetapi juga tidak adanya kontra produktif dari suatu
karakteristik dari suatu perangkat lunak yang diinginkan (Petrasch, 1999: 2).
Kebutuhan dan karakteristik berperan penting dalam mendefinisikan suatu kualitas. Oleh karena itu,
suatu model yang berbasiskan obyek bermanfaat dalam pemahaman yang lebih baik untuk masalah ini.
Gambar di bawah menunjukkan suatu produk perangkat lunak, dimana untuk memenuhi suatu
kebutuhan diperlukan karakteristik yang sesuai. Keberadaan hubungan antara kebutuhan dan
karakteristik menjadikan dimungkinkannnta statemen yang jelas tentang kualitas suatu produk.
Hal lain yang perlu diperhatikan dalam kualitas perangkat lunak adalah quality assurarance (QA) yang
merupakan cctivity of providing evidence needed to establish confidence mong ll concerned,that
quality-related activities are being performed effectively (J.M.Juran). Selain itu harus adanya software
quality management (SQM). Tujuan dari SQM adalah untuk mengembangkan suatu pemahaman
kuantitatif dari kualitas proyek produk perangkat lunak dan mencapai tujuan spesifik kualitasnya yang
digambarkan dalam table sederhana berikut:
Pengukuran Kualitas Perangkat Lunak
Sistem dari kualitas perangkat lunak terintegrasi dalam tiga disiplin aplikasi yaitu: pemodelan proses
pengembangan (process), pemodelan pengukuran produk (product), dan pemodelan manajemen dan
interaksi manusia (human). Pemahaman suatu disiplin melibatkan pembangunan model, pengujian
model dan pelajaran untuk dipahami dalam aplikasi yang nyatal. Pengembang kualitas prima perangkat
lunak harus berhadapan dengan unsur-unsur matriks berikut:
Model [M] [M*PROCESS] [M*PRODUCT] [M*HUMAN]
Testing [T] Process Product Human = [T*PROCESS] [T*PRODUCT] [T*HUMAN]
Data [D] [D*PROCESS] [D*PRODUCT] [D*HUMAN]
Unsur-unsur perangkat lunak utama dari sistem kualitas perangkat lunak ditunjukkan pada gambar di
bawah. Pengintegrasian dari semua unsur-unsur system kualitas memerlukan suatu model.
Permasalahannya untuk diperbaiki oleh dua model berikut (1) penanganan kompleksitas dalam disiplin
dari sistem kualitas dantunsur-unsurnya dan (2) penunjukan beberapa kelemahan dari model existing
process. Kompleksitas proses pengembangan dan dokumentasinya serta perubahan dokumentasi
selama pemeliharaan adalah permasalahan penting dalam peningkatan kualitas. Dokumentasi yang
dievaluasi sering sangat banyak dan kompleks. Oleh karena itu, hubungan kompleksitas antara produk
data teknis, dokumentasi perencanaan, pengujian kebutuhan dan tahapan unsur-unsur life cycle
pengembangan yang berbeda mengakibatkan dokumentasi ini sulit untuk dievaluasi dalam meyakinkan
semua aktivitas telah cukup dikerjakan. Dokumentasi menyediakan komunikasi antar semua kelompok
terkait dengan pengembangannya dan kendali proses proyek tersebut. Schweiggert mencatat beberapa
pertimbangan untuk krisis dokumentasi:
“Software in the application process must be constantly adapted and altered. The maintenance
programmer usually does not have the time alteration to documentation. Often suitable tools are not
available either. This causes the quality of documentation to suffer”
Metoda tradisional untuk verifikasi kualitas, seperti checklist bisa gagal dalam proses pengembangan
software yang kompleks. Audit dan review tidak bisa dilakukan tanpa menggunakan bantuan dan alat
yang membantu mengidentifikasi pemenuhan standar dan prosedur. Lebih dari itu, kompleksitas proses
pengembangan dan perubahan yang tak terkontrol dari unsur-unsur proses secara negatif berdampak
pada kualitas. Lifecycle pengembangan software yang berbeda dapat diusulkan. Hal ini dapat
memungkinkan adanya perbedaan motivasi, kekuatan dan kelemahan. Tidak ada model lifecycle yang
universal disesuaikan dengan lingkungan pengembangannya. Dalam model lifecycle tradisional,
hubungan antara tahapan unsur-unsur lifecycle pengembangan software yang berbeda tidaklah cukup
terwakili. Oleh karena itu, sulit untuk menguraikan efek segala perubahan dalam kebutuhannya yang
ditetapkan atas kualitas, keselamatan dan sasaran hasil dari perangkat lunak. Lebih dari itu, keberadaan
komputer dapat membantu untuk aplikasi model proses yang tidak fleksibel dan sulit untuk ditangani
karena kekompleksitasnya. Dalam lifecycle pengembangan software, Identifikasi hubungan antara
kelompok organisasi sangat penting untuk beberapa
pertimbangan berikut: (1) Pengembangan Proses harus berhadapan dengan kompleksitas dan
perubahan kebutuhan, pengujian metoda, teknologi, ukuran dan lain lain; (2) Kesalahan perangkat lunak
yang dihasilkan baik dalam suatu tahapan proses pengembangan software maupun sebagai alat
penghubung antara dua tahapan; (3) Dukungan kuat dari manajemen puncak merupakan suatu faktor
utama dalam mempengaruhi proses pengembangan tersebut. Menururut Wahono (2006), Deras
masuknya produk perangkat lunak dari luarnegeri di satu sisi menguntungkan pengguna karena
banyaknya pilihan produk dan harga. Namun di sisi lain cukup mengkhawatirkan karena di Indonesia
tidak ada institusi yang secara aktif bertugas membuat standard dalam pengukuran kualitas perangkat
lunak yang masuk ke Indonesia. Demikian juga dengan produk-produk perangkat lunak lokal, tentu akan
semakin meningkat daya saing internasionalnya apabila pengembang dan software house di Indonesia
mulai memperhatikan masalah kualitas perangkat lunak ini. Kualitas perangkat lunak (software quality)
adalah tema kajian dan penelitian turun temurun dalam sejarah ilmu rekayasa perangkat lunak
(software engineering). Kajian dimulai dari apa yang akan diukur (apakah proses atau produk), apakah
memang perangkat lunak bisa diukur, sudut pandang pengukur dan bagaimana menentukan parameter
pengukuran kualitas perangkat lunak. Bagaimanapun juga mengukur kualitas perangkat lunak memang
bukan pekerjaan mudah. Ketika seseorang memberi nilai sangat baik terhadap sebuah perangkat lunak,
orang lain belum tentu mengatakan hal yang sama. Sudut pandang seseorang tersebut mungkin
berorientasi ke satu sisi masalah (misalnya tentang reliabilitas dan efisiensi perangkat lunak), sedangkan
orang lain yang menyatakan bahwa perangkat lunak itu buruk menggunakan sudut pandang yang lain
lagi (usabilitas dan aspek desain).
Apa yang diukur?
Pertanyaan pertama yang muncul ketika membahas pengukuran kualitas perangkat lunak, adalah apa
yang sebenarnya mau kita ukur. Kualitas perangkat lunak dapat dilihat dari sudut pandang proses
pengembangan perangkat lunak ( process) dan hasil produk yang dihasilkan (product). Dan penilaian ini
tentu berorientasi akhir ke bagaimana suatu perangkat lunak dapat dikembangkan sesuai dengan yang
diharapkan oleh pengguna. Dari sudut pandang produk, pengukuran dapat dilakukan dengan cara
sebagai berikut:
Parameter dan metode pengukuran menurut Kelvin dalam Wahono (2006), When you can measure
what you are speaking about, and express it in numbers, you know something about it. But when you
can not measure it, when you can not express it in numbers, your knowledge is of a meagre and
unsatisfactory kind. Pendekatan engineering menginginkan bahwa kualitas perangkat lunak ini dapat
diukur secara kuantitatif, dalam bentuk angka-angka yang mudah dipahami oleh manusia. Untuk itu
perlu ditentukan parameter atau atribut pengukuran. Menurut taksonomi McCall, atribut tersusun
secara hirarkis, dimana level atas (high-level attribute) disebut faktor (factor), dan level bawah (low-level
attribute) disebut dengan kriteria (criteria). Faktor menunjukkan atribut kualitas produk dilihat dari
sudut pandang pengguna. Sedangkan kriteria adalah parameter kualitas produk dilihat dari sudut
pandang perangkat lunaknya sendiri. Faktor dan kriteria ini memiliki hubungan sebab akibat (cause-
effect). Tabel berikut menunjukkan daftar lengkap faktor dan kriteria dalam kualitas perangkat lunak
menurut McCall
Kualitas software diukur dengan metode penjumlahan dari keseluruhan kriteria
dalam suatu faktor sesuai dengan bobot (weight) yang telah ditetapkan. Rumus
pengukuran yang digunakan adalah:
Fa = w1c1 + w2c2 + … + wncn
Dimana:
Fa adalah nilai total dari faktor a
wi adalah bobot untuk kriteria i
ci adalah nilai untuk kriteria i
Kemudian tahapan yang harus kita tempuh dalam pengukuran adalah sebagai
berikut:
Tahap 1: Tentukan kriteria yang digunakan untuk mengukur suatu faktor
Tahap 2: Tentukan bobot (w) dari setiap kriteria (biasanya 0 <= w <= 1)
Tahap 3: Tentukan skala dari nilai kriteria (misalnya, 0 <= nilai kriteria <=10)
Tahap 4: Berikan nilai pada tiap kriteria
Tahap 5: Hitung nilai total dengan rumus Fa = w1c1 + w2c2 + … + wncn
Contoh pengukuran perangkat lunak
Untuk mempermudah pemahaman, akan diberikan sebuah contoh pengukuran kualitas perangkat lunak
dari faktor usabilitas (usability). Yang akan diukur adalah dua buah perangkat lunak yang memiliki fungsi
untuk mengkontrol peralatan elektronik (electronic device). Perangkat lunak yang pertama bernama
TukangKontrol, sedangkan kedua bernama Caktrol. Contoh dan hasil pengukuran dapat dilihat pada
Table 3 dan
4.
Dari penghitungan yang ada di Tabel 4, dapat kita simpulkan bahwa dari faktor usabilitas, kualitas dari
perangkat lunak bernama TukangKontrol lebih baik daripada Caktrol. Nilai total TukangKontrol untuk
faktor usabilitas adalah 16.8, sedangkan Caktrol adalah 10.2 (dari maksimum total nilai 20).
Mengapa Software Quality Engineering perlu dipikirkan?
Penerapan suatu rumusan pemrograman sederhana jawaban bisa diperkenalkan cara yang berikut:
RISK= F (1/quality) Atau kualitas yang ditingkatkan untuk mengurangi resiko
Suatu metode di mana hasil dari resiko dari kualitas yang pudar dapat dimanifestasikan lebih banyak,
bagaimanapun untuk seorang pemakai yang berpengalaman dikenali dalam contoh berikut:
– Kerugian Sosial atau profesional (nformasi/data, waktu, uang, pekerjaan dll.)
– Kerugian kesehatan atau kehidupan ( contoh: pasien over-X-rayed dalam suatu rumah sakit)
Jelaslah bahwa sebagai pemakai mungkin akan bermimpi untuk mengharapakan adanya bug-free yang
merupakan tingkatan paling tinggi kualitasnya dengan harga yang serendah-rendahnya. Akan tetapi
seberapa besar hal tersebut terjadi, tergantung dari SQE oleh perusahaan pengembangan software.
Paling mungkin ada suatu kesempatan untuk tidak membeli perangkat lunak yang jelas ada cacat
produksinya. Rendahnya kualitas perangkat lunak merupakan resiko yang didapat suatu organisasi yang
membelinya dan terkadang suatu pengembang ataupun supplier tidak ambil pusing bahkan tidak mau
disalahkan. Berdasarkan pengalaman, resiko yang paling besar sebagai hasil dari rendahnya kualitas
perangkat lunak sering didapatkan oleh pemakai dan hanya sedikit yang didapatkan oleh penyalur
perangkat lunak. Karena itu harus ada suatu kompromi antara developer atau supplier dan pemakai
tentang perangkat lunak yang akan dibeli sehingga diharapkan tidak ada yang dirugikan dari transaksi
yang terjadi. Menentukan Kualitas Perangkat Lunak Dipandang dari sudut hipotesis, para ahli dalam
membuat dan menentukan kualitas perangkat lunak sebaiknya menerapkan, mengukur, mengevaluasi
dan meningkatkan mutu perangkat lunak sepanjang lifecycle-nya. Pengetahuan yang luas tentang
rekayasa perangkat lunak memerlukan suatu pendekatan yang terstruktur dan sistematis dengan
mempertimbangkan pengalaman yang diperolehnya. Jika mungkin, disesuiakan dengan praktek industri
sebenarnya. Suatu pendekatan terstruktur tidak terbatas pada tiga komponen utama yang terpusat
pada inti pengetahuan perangkat lunak. Contohnya komponen Quality Requirements didapatkan
dengan adanya prasyarat:
– Kualitas kebutuhan (Quality requirements)

– Pengukuran kualitas dan instrument evaluasi (Quality measurement and evaluation instruments)
– Implementasi kualitas dalam lifecycle (In-lifecycle quality implementation)
Pengetahuan dalam mendapatkan komponen Quality requirement (QR) sangat diperlukan terutama
bagi kalangan ahli software dalam mempertimbangkan dan memperoleh kebutuhan yang berkualitas
sehingga benar-benar didapatkan high-level stakeholder’s requirements. Karena itu untuk mendapatkan
kemudian untuk QR digambarkan pengukuran kualitas dalam gambar di bawah ini:
Model dekomposisi yang diusulkan didasarkan pada model kualitas dari ISO/IEC 9126 dalam konjungsi
dengan standar TL 9000, dimana kontribusi dari penggunaan QR adalah untuk menetapkan kebutuhan
mutu eksternal (External Quality requirements), yang mana pada gilirannya berperan untuk menetapkan
kebutuhan mutu internal (Internal Quality requirements). Model tersebut didokumentasikan dengan
baik sehingga relatif mudah untuk dipelajari dan digunakan akan tetapi sedikit statis dalam
perubahannya. Karena itu, ahli SQ yang baik seharusnya mengetahuinya tidak hanya apa? tetapi juga
bagaimana? Pendekatan ini ditujukan oleh model tersebut untuk proses praktis dalam melukiskan dan
mengendalikan kualitas kebutuhan
Pada gambar di atas, anak panah dengan garis yang tidak putus-putus menunjukkan alur tentang ”
bagaimana”, yaitu menanyakan tentang eksekusi dekomposisi kebutuhan. Yang ada dalam kotak berisi
tentang pertanyaan ” apa ” , yaitu menggambarkan kebutuhan apa yang diakibatkan oleh proses
dekomposisi. Sedangkan anak panah dengan garis putus-putus menandai adanya alur pokok dari
traceability kebutuhan. Pengetahuan teoritis dan praktis yang menjawab pertanyaan diatas
membutuhkan ahli yang berkompeten tentang SQ untuk mengatur proses definisi dan analisis
kebutuhan. Komponen dari The Quality measurement and evaluation instruments memiliki tujuan untuk
mendidik para ahli SQ tentang keberadaan
model kebutuhan dan mengukur pemilihan perangkat lunak dalam proses mendukung aktivitasnya.
Demikian juga, dua unsur tersebut sebaiknya didokumentasikan sehingga mudah untuk dipelajari walau
sedikit statis. Rancang bangun merupakan bagian dari pengetahuan dimana pemetaan tentang suatu
instrumen ke dalam tahapan lifecycle perangkat lunak trlihat pada gambar di bawah sangat sedikit
didokumentasikan dan memerlukan riset lebih lanjut .
Komponen terakhir dari hasil lifecycle quality implementation diakibatkan oleh dua Komponen yang
sebelumnya di mana pengetahuan dasar telah didaptkan. Implementasi sekarang memerlukan aplikasi
yang praktis tidak sekedar dengan pengetahuan tersebut tetapi juga dalam proses pengembangan
perangkat lunak.
Pengukuran Perangkat Lunak Menggunakan Metrik Size-Oriented dan Metrik

Function Oriented.
PENGANTAR:
Pengukuran adalah suatu hal pokok bagi disiplin perekayasaan(engineering), tidak terkecuali
pada perekayasaan perangkat lunak atau software. Jangkauan luas pengukuran pada perangkat
lunak komputer disebut metrik perangkat lunak.
Tujuan diterapkannya pengukuran pada proses perangkat lunak adalah untuk mengembangkan
perangkat lunak itu sendiri dengan dasar yang kontinu.
Pengukuran software dalam konteks manajemen software difokuskan pada produktivitas dan
metrik kualitas (pengukuran output perkembangan software sebagai fungsi usaha dan waktu
yang diaplikasikan serta pengukuran “kesesuaian pemakaian” dari produk kerja yang dihasilkan).
1. PENGUKURAN, METRIK, DAN INDIKATOR
Dalam konteks rekayasa perangkat lunak, mengukur (measure) mengindikasikan kuantitatif dari
ukuran atribut sebuah proses atau produk. Pengukuran (measurement) adalah kegiatan
menentukan sebuah measure (pengukuran). Dan definisi metriks menurut IEEE adalah “ukuran
kuantitatif dari tingkat dimana sebuah system, komponen atau proses memiliki atribut tertentu”.
Pengukuran telah ada jika suatu data-data tunggal telah dikumpulkan (misal: jumlah kesalahan
yang ditemukan pada kajian sebuah modul tunggal). Metrik perangkat lunak menghubungkan
pengukuran-pengukuran individu dengan banyak cara, misal rata-rata dari jumlah kesalahan
yang ditemukan pada setiap kajian.
Rekayasa perangkat lunak mengumpulkan pengukuran dan mengembangkan metrik menjadi

sebuah indikator, yaitu sebuah metrik atau kombinasi metrik yang memberikan pengetahuan
dalam proses perangkat lunak, sebuah proyek perangkat lunak, atau produk itu sendiri.
Fungsinya adalah memberi pengetahuan pada manajer proyek atau perekayasa perangkat lunak
untuk menyesuaikan proses, proyek, dan produk agar menjadi lebih baik.
2. PENGUKURAN PERANGKAT LUNAK
Pengukuran langsung dari produk berkaitan dengan deretan kode, kecepatan eksekusi, ukuran
memori, dan cacat yang dilaporkan pada suatu periode tertentu. Sedangkan pengukuran tidak
langsung dari produk adalah tentang fungsionalitas, kualitas, kompleksitas, efisiensi, realibilitas,
kemampuan pemeliharaan, dsb.Dalam kenyataannya, pengukuran perangkat lunak secara
objektif akan sulit dilakukan secara langsung karena ada pengaruh-pengaruh seperti individu
dalam tim pengukuran, atau tingkat kompleksitas proyek.
Tetapi jika pengukuran dinormalisasi, maka mungkin akan dapat didapatkan metrik perangkat
lunak yang memungkinkan perbandingan dengan rata-rata organisasional yang lebih besar.
METRIK SIZE ORIENTED
Parameternya adalah ”ukuran” dari software yang dihasilkan. Dapat dilakukan jika ada record
atau catatan dari organisasi. Perlu diperhatikan bahwa yang record yang diperlukan adalah
keseluruhan aktivitas rekayasa perangkat lunak. Misalnya tabel dibawah ini adalah pengumpulan
dari data-data record yang ada dari sebuah organisasi:
Dimana LOC (line of code) menunjukkan jumlah baris kode yang dibuat pada masing-masing
proyek, misalnya pada kolom pertama, proyek aplha dibuat dengan 12100 baris kode dalam 365
halaman, dikembangakan dengan usaha 24 orang per bulan dengan biaya $168000. Lalu
ditemukan kesalahan sebanyak 134 pada proyek sebelum direlease, 29 cacat setelah direlease
pada pelanggan, dan ada 3 orang yang bekerja pada pengembangan proyek perangkat lunak
alpha.
Untuk pengembangan dari metrik ini, dapat dibuat metrik size oriented baru yang sederhana
untuk tiap proyek, misal: kesalahan per baris kode (dihitung ribuan), cacat per baris kode
(ribuan), dokumentasi per baris kode (ribuan), kesalahan per usaha, baris kode per usaha, biaya
per halaman dokumentasi, dsb.
Metrik ini tidak dapat diterima secara universal karena adanya kontroversi pada penggunaan
baris kode sebagai titik ukur. Sebagian yang setuju pada pengukuran LOC menganggap bahwa
LOC adalah suatu bukti real dari apa yang dilakukan oleh perekayasa perangkat lunak (dalam
konteks ini membuktikan berapa banyak baris program yang ditulis oleh seorang programmer –
comment yang ada).
Sedangkan sebagian yang tidak setuju bahwa LOC dijadikan suatu tolak ukur kebanyakan
disebabkan alasan ambiguitas dari cara menghitung LOC itu sendiri. Dalam masa-masa awal
bahasa pemrograman Assembly, hal ini tidak menjadi suatu masalah karena dalam 1 baris aktual
program merupakan 1 baris instruksi, tetapi dalam bahasa pemrograman tingkat tinggi, dimana
pada masing-masing bahasa, untuk menyelesaikan suatu masalah dengan algoritma yang sama
pun LOC nya sudah berbeda-beda. Bahkan dalam satu bahasa pemrograman yang sama, untuk
menyelesaikan masalah yang sama, LOC nya bisa berbeda jauh tergantung dari algoritma yang
digunakan. Hal ini yang membuat banyak sekali kontroversi mengenai LOC sebagai tolak ukur
dari sebuah software.
METRIK FUNCTION ORIENTED
Normalisasi dilakukan pada fungsionalitas pada aplikasi, tetapi untuk melakukan hal ini,
fungsionalitas harus diukur dengan pengukuran langsung yang lain karena fungsionalitas tidak
dapat diukur secara langsung. Maka pengukuran dapat dilakukan dengan pengukuran function
point. Function point didapat dari penarikan hubungan empiris berdasarkan pengukuran domain
informasi software dan perkiraan kompleksitas software.
Domain informasi yang biasa digunakan ada 5 karakteristik, yaitu:
1. jumlah input pemakai: setiap input pemakai yang memberikan data yang berorientasi
pada aplikasi yang jelas pada perangkat lunak (harus dibedakan dari penelitian yang
dihitung secara terpisah) misal: tipe transaksi.
2. jumlah output pemakai: setiap output pemakai yang memberikan informasi yang
berorientasi pada aplikasi kepada pemakai. Pada konteks ini output mengacu pada
laporan, layar, tampilan kesalahan, dsb. Jenis data individual pada laporan tidak dihitung
terpisah. misal: report type.
3. jumlah penyelidikan pemakai: input online yang mengakibatkan munculnya beberapa
respon perangkat lunak yang cepat dalam bentuk output online
4. jumlah file: setiap master logika (pengelompokan data logis yang menjadi suatu bagian
dari sebuah database yang besar atau sebuah file terpisah).
5. jumlah interface eksternal: semua interface yang dapat dibaca oleh mesin yang digunakan
untuk memindahkan informasi ke sistem yang lain
Sekali data telah dikumpulkan, maka nilai kompleksitas dihubungkan dengan masing-masing
penghitungan dengan tabel perhitungan sebagai berikut:
Faktor pembobotan
Dalam hal ini faktor pembobotan setiap faktor sudah menjadi standar dan tidak dapat diubah-
ubah, tetapi dalam penentuan kriteria suatu perangkat lunak pada salah satu parameter
pengukuran adalah sederhana, rata-rata atau kompleks ditentukan oleh organisasi atau perkeyasa
perangkat lunak yang melakukan penghitungan itu sendiri. Tetapi meskipun begitu perkiraan
kompleksitas tetap bersifat subyektif.
Untuk menghitung function point (FP) dapat digunakan hubungan sbb:

FP = jumlah total x [0,65 + 0,01 x Fi] dimana jumlah total adalah nilai yang kita dapatkan pada
tabel perhitungan di atas. Sedangkan Fi dapat dihitung dari perhitungan sebagai berikut:
Pertama-tama kita diberi 14 buah karakteristik dari suatu perangkat sebagai berikut:
1. Data communications
2. Distributed functions
3. Performance.
4. Heavily used configuration
5. Transaction rate
6. Online data entry
7. End-user efficiency
8. Online update
9. Complex processing
10. Reusability
11. Installation ease
12. Operational ease
13. Multiple sites
14. Facilitation of change
Pada setiap karakteristik tersebut diberi bobot dari nilai 0 sampai 5 dengan asumsi nilai sebagai
berikut:
0. Tidak berpengaruh
1. Insidental
2. Moderat
3. Rata-rata
4. Signifikan
5. Essential
Setelah setiap karakteristik diberi bobot masing-masing, lalu bobot-bobot dari setiap
karakteristik ini dijumlahkan (jadi minimum 0 dan maksimal 70) dan kita akan mendapatkan
nilai Fi. Setelah mendapatkan nilai Fi maka kita bisa menghitung nilai FP dengan rumus di yang
sudah ada di atas. Setelah kita mendapatkan nilai FP, maka kita dapat menggunakannya dengan
cara analog dengan LOC untuk menormalisasi pengukuran produktivitas, kualitas perangkat
lunak, serta atribut-atribut yang lain seperti:
· kesalahan per FP
· cacat per FP
· $ per FP
· halaman dokumentasi per FP
· FP per person-month
· dsb
(dimana untuk mendapatkan data-data untuk kesalahan, cacat, dolar, dsb dapat diambil
dari data-data pada tabel record pada metrik size-oriented).
Contoh:
Pada proyek alpha (tabel record metrik size oriented) sudah dihitung bahwa jumlah input
pemakainya ada 18 buah, jumlah output pemakai: 6 buah, jumlah penyelidikan pemakai 22 buah,
jumlah file 45 buah, jumlah interface eksternal 20 buah, dengan asumsi bahwa jumlah input
pemakai rata-rata, jumlah output pemakai sederhana, jumlah penyelidikan pemakai rata-rata,
jumlah file kompleks, jumlah interface eksternal sederhana. Semua karakteristik pada perangkat
lunak ini moderat. Hitung $ per FP nya!
Jawab:
jumlah total = (18 x 4) + (6 x 4) + (22 x 4) + (45 x 15) + (20 x 6) = 979
Fi = 14 x 2 = 28
FP = 979 x (0,65 + (0,01 x 28)) = 910,47
$ pada proyek alpha: 168000
$ per FP = 168000 / 910,47 = $184,52
Hasil dari contoh kasus diatas masih berupa suatu angka mentah, untuk dapat dilihat apakah
angka ini termasuk baik atau tidak harus diperbandingkan dengan perhitungan lain, misalnya $
per FP dari proyek beta atau gamma, atau proyek dari organisasi lain.
Sebenarnya banyak sekali metrik-metrik yang digunakan untuk mengukur perangkat lunak,
misalnya metrik FP yang diperluas (biasanya diaplikasikan dalam dunia bisnis) tetapi belum
sempat dibahas disini.
MODUL PERKULIAHAN
Modul Standar untuk

10 18017
Studi Sistem
Informasi
Abstract Kompetensi
Metriks untuk Object Oriented Software Metrik Teknis Untuk Sistem
Berorientasi Objek
METRIK PENGEMBANGAN PERANGKAT LUNAK BERORIENTASI OBJEK:
Pengembangan dan desain perangkat lunak berorientasi objek saat ini sangat populer. Perbedaan
utama antara pemrograman terstruktur dengan berorientasi objek adalah pada pemrograman
terstruktur fundamental pembangunan program adalah algoritma. Sedangkan pada
pemrograman berorientasi objek menggunakan objek sebagai fundamentalnya. Dalam
pengembangan perangkat lunak berorientasi objek, supaya perangkat lunak/source code yang
kita buat berkualitas harus memperhatikan kaidah-kaidah seperti reusability, understandability,
maintainability dan testability. Reusability adalah kemampuan kode yang kita buat bisa
digunakan lagi pada aplikasi lain maupun pada aplikasi itu sendiri. Kode yang kita buat harus
mudah dimengerti(understanbility) supaya mudah di maintenace. Selain itu, kode yang kita
buat usahakan sederhana(simplicity) sehingga mudah dilakukan pengujian (testing). Nah
pertanyaannya sekarang, bagaimana kita mengetahui kualitas kode yang kita buat? Bagaimana
cara mengukurnya?
Metrics software merupakan tools yang bisa digunakan untuk mengukur kode yang kita buat
dengan berbagai macam tipe pengukuran yang berhubungan dengan sistem, proses atau dokumen
terkait dalam perangkat lunak. Metrics membantu dalam melakukan evaluasi terhadap
pengembangan dan testing yang perlu dilakukan dalam suatu sistem yang meliputi aspek
testability, understandability, maintainability dan reusability. Metrics yang bisa digunakan untuk
mengukur perangkat lunak berorientasi objek bisa juga metrik tradisional(pada pemrograman
struktural) dan metrik yang khusus digunakakan untuk pengembangan perangkat lunak berbasis
objek.
Pada posting ini kami akan membahas paper berjudul “Applying and Interpreting Object
Oriented Metrics” yang ditulis oleh Dr. Linda H. Rosenberg. Paper ini membahas tentang
Software Assurance Technology Center (SATC) pada NASA Goddard Space Flight Center yang
melakukan pendekatan untuk memilih metrics untuk project dengan terlebih dahulu
mengidentifikasi atribut yang terkait dengan pengembangan berorientasi objek. Cakupan bahasan
tersebut meliputi penjelasan metrik-metrik tersebut, termasuk, cara menghitung dan bagaimana
cara membacanya. Kami juga mengambil studi kasus dari tugas Character Graphics pada mata
kuliah TPL.
Pada paper ini, SATC mengusulkan panduan interpretasi metrik-metrik dengan cara melihat
kenapa suatu nilai metrik berbeda dari satu modul dengan modul lainnya, kemudian
menginvestigasinya. Berikut tabel intepretasi metrik.
Dalam penjelasan masing-masing metrik penghitungan metrik dilakukan pada kelas Character Graphic.
Berikut adalah kelas diagram Character Graphic.
Metric software: Cyclomatic Complexity (CC)

Cyclomatic Complexity (CC) merupakan metrik tradisional yang menghitung tingkat
kompleksitas suatu method/procedure. Metrik ini bisa diterapkan pada pemrograman berorientasi
objek untuk menghitung kompleksitas suatu method. Kompleksitas dalam method merujuk
kepada berapa jumlah test case yang diperlukan untuk mengevaluasi method tersebut sehingga
setiap percabangan didalam method tersebut pernah dilalui. Cyclomatic Complexity (CC) secara
langsung tidak bisa digunakan untuk mengukur kompleksitas kelas. Menurut sumber kami, hal
tersebut tidak bisa karena adanya pewarisan dalam code. Namun Cyclomatic Complexity (CC)
bisa menghitung kompleksitas kelas jika dikombinasikan dengan pengukuran lain.
Cyclomatic Complexity (CC) berpengaruh terhadap Understandability, Maintainability dan

Testing. Semakin kompleks suatu method berpengaruh terhadap semakin sulit untuk memahami
method tersebut dan tentu saja akan semakin sulit jika nantinya ingin melakukan memaintenace
method tersebut. Selain itu, tentu saja akan berpengaruh terhadap kompleksitas pengujian yang
dilakukan terjadap method tersebut.
Dalam menghitung Cyclomatic Complexity (CC) dalam method, statement disimbolkan dengan
node dan aliran program dilambangkan dengan edge. Nilai Cyclomatic Complexity (CC)
merupakan jumlah edges-jumlah node +2. Berikut contoh penghitungan CC.
Berikut contoh perhitungan CC dari code. Nilai CC 4 yang dihasilkan berarti diperlukan 4 test case untuk
menguji method tersebut
Kami juga melakukan penghitungan nilai CC pada program Character Graphic, diperoleh hasil seperti
berikut.
CC tertinggi ditemukan pada kelas Drawing Package. Nilai CC Drawing Package sangat significant
dibanding dengan kelas-kelas lain. Ini terjadi karena kelas Drawing Package merupakan kelas yang berisi
banyak kondisional case untuk menterjemahkan menu-menu diinput.
Metric software : Size

Metric Size merupakan metrik tradisional yang digunakan untuk mengevaluasi tingkat
kemudahan untuk mengerti code oleh developer dan mainteners. Seperti metrik Cyclomatic
Complexity, Metrik size juga berpengaruh terhadap understandbility, maintainability dan testing.
Semakin rendah nilai metrik size, maka semakin mudah untuk mengerti dan memelihara method
tersebut. Ada beberapa cara untuk menghitung size dari method, diantaranya adalah Line of
Code (LOC), Non-Comment Non Blank (NCNB) dan Executable Statements(EXEC).
LOC menghitung seluruh baris dalam program, NCNB menghitung semua baris yang tidak berisi
komentar dan tidak kosong sedangkan EXEC menghitung banyaknya jumlah statement
excecutable tanpa memperhatikan jumlah LOC. LOC dan NCNB sangat dipengaruhi oleh bahasa
pemrograman dan style dari programmer. pengukuran Exec paling sedikit dipengaruhi oleh
programmer, Exec sangat bagus digunakan untuk mengukur metric size terutama jika project
menggunakan banyak bahasa pemrograman seperti yang dilakukan oleh SATC yang
menggunakan EXEC untuk mengevaluasi project size. Berikut contoh perhitungan metric size.
IF X=3
Then
Y=10
Nilai LOC= 3 , NCNB=3, EXEC=1
LOC = 6, NCNB = 5, EXEC = 1.
Berikut hasil pengukuran metrik size pada Characters Graphic
Metric Software : Comment Percentage
Total Comments=1, LOC=6, Blank line =0, CP = 1/(6-0) x 100% =17%
Berikut hasil metric comment percentage Characters Graphic
New Object Oriented Metric
Metric Software : Weighted Methods per Class (WMC)
WMC termasuk metrik untuk object oriented yang mengukur banyaknya method yang
diimplementasikan dalam kelas atau jumlah keseluruhan kompleksitas method (CC). Dalam
paper sumber kami, WMC dihitung berdasarkan banyaknya method yang terdapat dalam kelas.
WMC berpengaruh terhadap understandability, maintenance dan reusability. Semakin banyak

method yang terdapat kelas, maka semakin sulit untuk memahami kelas tersebut dan semakin
sulit untuk melakukan pemeliharaan. Disamping itu, dengan semakin banyak method didalam
suatu kelas, maka kelas tersebut semakin tidak reusable.
Untuk menghitung WMC dilakukan secara sederhana, yaitu menghitung banyaknya suatu
method dalam kelas tersebut. Contohnya pada kelas dibawah ini, WMC nya adalah 6.
Berikut hasil WMC yang didapatkan pada program Character Graphic
Pada paper sumber kami, diperoleh Histogram WMC seperti dibawah ini. Histogramtersebut
memperlihatkan bahwa sebagian besar class memiliki WMC yang kurang dari 20 dan terdapat
beberapa class dengan WMC lebih besar dari 100. Beberapa class dengan WMC tertinggi
merupakan kandidat class yang perlu untuk diperiksa atau perlu dilakukan revisi.Histogram ini
juga berguna untuk melakukan monitor kompleksitas terhadap waktu.
Metric Software : Response for Class (RFC)

RFC(Response for Class) merupakan metrik yang menghitung banyaknya method yang kemungkinan di
eksekusi sebagai response atas message objek dari kelas tersebut. RFC Menyatakan banyaknya method
lokal dan banyaknya method yang dipanggil oleh method lokal termasuk semua method dalam kelas
hirarki dan juga termasuk kelas library(kecuali method print). Method tersebut menghitung method
secara rekursif. Method yang sama cukup dihitung sekali. sumber
Metrik ini berpengaruh terhadap Testability dan Reuseablility. Semakin banyak method yang ada pada
kelas tersebut + method kelas lain yang dipanggil maka kelas tersebut akan semakin sulit ditesting dan
semakin tidak reusable. RFC pada code dibawah adalah :
RFC(tool)=1(self)+1(drawing)
RFC(tool)=2;
Berikut hasil RFC pada kelas Characters Graphic.
Sedangkan grafik yang dihasilkan pada paper yang kami bahas seperti di bawah ini. Pada gambar
dibawah, terdapat beberapa class didalam project yang dalam prosesnya dapat melibatkan lebih dari
200 method. Class dengan RFC yang besar memiliki kompleksitas yang tinggi dan mengurangi
understandability dari class tersebut, sehingga menyebabkan testing dan debugging menjadi rumit.
Metric software: Lack of Cohesion (LCOM)
LCOM digunakan untuk mengukur derajat kemiripan method oleh variabel input data atau
atribut dalam class. Semakin besar nilai LCOM pada suatu class mengindikasikan meningkatnya
kompleksitas sehingga meningka
levitra online
tkan kemungkinan dari error selama proses pengembangan. Class dengan nilai LCOM yang
ditinggi dapat dibagi menjadi dua atau lebih subclass sehingga dapat meningkatkan nilai cohesi
dari class. Semakin kecil nilai LCOM pada suatu class mengindikasikan meningkatnya
reuseability, maintainabilty dan understanability.
Berikut rumus yang digunakan untuk menghitung LCOM:
Berikut contoh perhitungan LCOM pada class Cshape:
Cara perhitungan :
Berikut hasil pengukuran metrik LCOM pada program Characters Graphic
Pada paper berjudul “Applying and Interpreting Object Oriented Metrics” yang ditulis oleh Dr.
Linda H. Rosenberg disajikan aplikasi dan interpretasi dari metric LCOM dengan menggunakan
NASA project data sebagai berikut:
Dari
grafik plot yang disajikan diatas, kita dapat melihat pengukuran LCOM yang dibandingkan
dengan kemungkinan maksimumnya dari LCOM. Nilai LCOM maksimum bila tidak irisan
atribut diantara method di dalam class atau q=0.
write my paper for me
Rich Text Area Toolbar Bold (Ctrl / Alt + Shift + B) Italic (Ctrl / Alt + Shift + I) Strikethrough
(Alt + Shift + D) Unordered list (Alt + Shift + U) Ordered list (Alt + Shift + O) Blockquote (Alt
+ Shift + Q) Align Left (Alt + Shift + L) Align Center (Alt + Shift + C) Align Right (Alt + Shift
+ R) Insert/edit link (Alt + Shift + A) Unlink (Alt + Shift + S) Insert More Tag (Alt + Shift + T)
Toggle spellchecker (Alt + Shift + N) ▼ Toggle fullscreen mode (Alt + Shift + G) Show/Hide
Kitchen Sink (Alt + Shift + Z) Format Paragraph ▼ Underline Align Full (Alt + Shift + J) Select
text color ▼ Paste as Plain Text Paste from Word Remove formatting Insert custom character
Outdent Indent Undo (Ctrl + Z) Redo (Ctrl + Y) Help (Alt + Shift + H) LCOM digunakan untuk
mengukur derajat kemiripan method oleh variabel input data atau atribut dalam class. Semakin
besar nilai LCOM pada suatu class mengindikasikan meningkatnya kompleksitas sehingga
meningkatkan kemungkinan dari error selama proses pengembangan. Class dengan nilai LCOM
yang ditinggi dapat dibagi menjadi dua atau lebih subclass sehingga dapat meningkatkan nilai
cohesi dari class. Semakin kecil nilai LCOM pada suatu class mengindikasikan meningkatnya
reuseability, maintainabilty dan understanability. Berikut rumus yang digunakan untuk
menghitung LCOM: Berikut contoh perhitungan LCOM pada class Cshape: Cara perhitungan :
Berikut hasil pengukuran metrik LCOM pada program Characters Graphic Pada paper berjudul
“Applying and Interpreting Object Oriented Metrics” yang ditulis oleh Dr. Linda H. Rosenberg
disajikan aplikasi dan interpretasi dari metric LCOM dengan menggunakan NASA project data
sebagai berikut: Dari grafik plot yang disajikan diatas, kita dapat melihat pengukuran LCOM
yang dibandingkan dengan kemungkinan maksimumnya dari LCOM. Nilai LCOM maksimum
bila tidak irisan atribut diantara method di dalam class atau q=0. Path
Metric software: Coupling Between Object Classes (CBO)
CBO digunakan untuk menghitung jumlah class lainnya yang non-inheritance dimana class
tersebut di couple. Couple yang dimaksudkan adalah didalam satu class memanggil method dari
class lainnya. Class-class yang memiliki
nilai CBO yang tinggi dapat mengganggu desain modular dan mencegah reuseablity dari suatu
class. Untuk meningkatkan modularitas dan mendukung enkapsulasi, CBO seharusnya dijaga
tetap minimum. Karena semakin banyak couple, semakin besar sensivitas di dalam desain
sehingga pemeliharaan menjadi semakin rumit. Apabila ada class lain yang dipanggil lebih dari
1x maka akan tetap dihitung sebagai 1x pemanggilan.
Berikut contoh perhitungan CBO pada class Tool:
Berikut hasil pengukuran metrik CBO pada program Characters Graphic

Pada paper
berjudul “Applying and Interpreting Object Oriented Metrics” yang ditulis oleh Dr. Linda H.
Rosenberg disajikan aplikasi dan interpretasi dari metric CBO dengan menggunakan NASA
project data sebagai berikut:
Pada gambar grafik diatas, kita melihat bahwa dari 240 class, lebih dari 1/3 nya berdiri
sendiri(terdapat lebih dari 80 class memiliki CBO=0). Semakin besar CBO suatu class
mengindikasikan bahwa class tersebut kemungkinan lebih sulit dimengerti, susah untuk
digunakan kembali(reuse) dan lebih sulit untuk dimaintain.
Metric software: Depth of Inheritance Tree (DIT)
DIT digunakan untuk mengukur kedalaman dari suatu class pada inheritance hierarchy tree. DIT
dihitung dengan cara menghitung jumlah tingkatan dari kelas node ke root dari inheritance
hierarchy tree. Semakin besar
nilai DIT pada suatu class maka semakin banyak method yang diwarisi sehingga semakin rumit
untuk mengamati tingkah laku dari class tersebut tetapi semakin besar reuseability dari method
yang diwarisi.
Berikut contoh perhitungan DIT pada program Characters Graphic:
Berikut hasil pengukuran metrik DIT pada seluruh class pada program Characters Graphic
Linda H. Rosenberg disajikan aplikasi dan interpretasi dari metric DIT dengan menggunakan
NASA project data sebagai berikut:
Pada gambar grafik diatas, kita melihat bahwa Hampir 66% (DIT>0) dari class project ini berada
di bawah class lainnya di dalam tree, yang mengindikasikan berada dalam level sedang dari
reuse.
Metric software: Number of Children (NOC)

NOC merupakan jumlah subclass yang diturunkan langsung dari suatu class. Semakin tinggi
nilai NOC menyebabkan semakin besar reuseability karena inheritance adalah bentuk dari reuse.
Semakin besar NOC juga dapat menyebabkan proses pengujian semakin banyak karena apabila
terjadi perubahan di suatu class dapat mempengaruhi class yang menjadi subclass dari class
tersebut.
Berikut contoh perhitungan NOC pada program Characters Graphic:
Berikut hasil pengukuran metrik NOC pada seluruh class pada program Characters Graphic
Linda H. Rosenberg disajikan aplikasi dan interpretasi dari metric DIT dan NOC dengan
menggunakan NASA project data sebagai berikut:
Gambar grafik diatas menampilkan bagaimana dua cara pandang dari indentifikasi data pada
class yang diamati. DIT yang tinggi mengindikasikan trade-off diantara meningkatnya
kompleksitas dan meningkatnya reuse, tetapi perlu dilakukan lebih banyak testing pada sistem.
NOC yang tinggi juga mengindikasikan peningkatan reuse, tetapi kemungkinan memerlukan
lebih banyak testing pada sistem.
MODUL PERKULIAHAN
Modul Standar untuk

11 18017
Studi Sistem
Informasi
Abstract Kompetensi
Impelementasi Sistem Impelementasi Sistem
3.1. Implementasi Sebuah Sistem
Dalam proses akhir dari pengembangan sebuah sistem yaitu melakukan implementasi dengan
tahapan sebagai berikut:
1.Training Personal
2. Konversi Sistem
3. Review post-implementation
4. Dokumentasi
5. Dukungan lain
3.1. a. Tipe Training: disesuaikan dengan keadaan lingkungan implementasi sistem:
-Eksternal Training: kursus dr vendor pelatihan
 Internal Training: On the Job Training

 Belajar Sendiri
3.1. b. Memilih Staf yang akan dilatih
- Terdiri dari tiga kelompok User:
 Teknisi & Administrator yang akan bertugas merawat sistem

 Application user (user pd umumnya)
 General Manager
3.1.c. Konversi terdapat 4 macam:
 Konversi Langsung
 Konversi Paralel
 Konversi phase-in
 Konversi Pilot
3.1.d. Evaluasi Sistem

Bertujuan untuk mendapatkan cara meningkatkan efisiensi dan efektifitas sistem baru, serta
memberikan informasi untuk pengembangan sistem mendatang.
Biasanya dilakukan setelah dua hingga enam bulan instalasi -> sudah terdapat periodik
pelaporan serta isu sistem masih baru
3.1.2.a. Area Peninjauan Evaluasi Sistem (Faktor Sistem)
- Faktor kelayakan TELOS (Technical, Economical, Legality, Operation, Schedule)
Teknologi pendukung;
 Pendanaan utk biaya teknologi, operasional, pemeliharaan,

 Operasinal sistem yg tidak melanggar hukum, kesesuain jadwal.
-Keterampilan personal dlm Faktor strategik PDM (Productivity, Differentiation, Management )
 Sudah tercapainya produktivitas setelah implementasi sistem baru

 Kontribusi terhadap diferensiasi produk dan layanan
 Dukungan informasi utk peningkatan kualitas perencanaan, pengontrolan, dan
pembuatan keputusan manajemen,
-Faktor rancangan MURRE (Maintenability, Usability, reusability, extenability)
 Dokumentasi sudah komprehensive, jelas dan uptodate

 Mendukung CMS (Change Management System)
 Module untuk user sudah terpenuhi
 Terpenuhinya dukungan ke user
 Modul perangkat lunak dapat digunakan kembali
 Terbebas dari fault/error
 Adaptif dan fleksibel
3.1.2.b. Komponen Rancangan Sistem:
Output
 Output harus sesuai, relevan, akurat dan dapat digunakan kembali

 Kemanan pengguna output bagi user yg tidak berhak
 Kemudahan akses
 Sesuai dengan kognitif user
 Ketepatan edit dan identifikasi laporan
Input
 Form memenuhi kaidah pedoman dan spesifikasi rancangan

 Verifikator data input
 Manual pengisian form
Proses
 Pengujian terhadap semua proses

 Peninjauan terhadap prosedur dan dokumentasi
 Prosedure pengoperasian
 Reliability sistem
 Platform Teknologi
 Peripheral, workstation, processor, dan jaringan,
 Membandingkan kinerja dengan rancangan
Membutuhkan komponen penunjang:
 Job accounting system

 Hardware monitoring
 Software monitoring
 Konfigurasi teknologi yang optimal
 Respon time yang acceptable
 Keakuratan Estimasi
 Waktu: menggunakan tool spt PERT, Gannt, atau lainnya.
 Biaya yg sebenarnya sesuai dg yg diestimasi
Manfaat
 Tingkat dukungan:
 Sumber daya tersedia
 Manajemen puncak
 Pelatihan (teknik pelatihan, user, tutor)
MODUL PERKULIAHAN
Modul Standar untuk

12 18017
Studi Sistem
Informasi
Abstract Kompetensi
Dokumentasi Perangkat Lunak Memahami Dokumentasi Perangkat
Lunak
Dokumentasi yang ada di Departemen Sistem Informasi (Departemen Operasi) diantaranya adalah :
1. Dokumentasi Dokumen Dasar

Merupakan dokumentasi yang berisi kumpulan dokumen- dokumen dasar sebagai bukti
transaksi yang digunakan dalam sistem. Contoh :Faktur penjualan, Order penjualan, order
pembelian, surat pengiriman barang, time-card.
2. Dokumentasi Daftar Rekening (chart of account)

Merupakan dokumentasi yang menunjukkan informasi mengenai rekening-rekening yang
dipergunakan di dalam transaksi. Daftar rekening berisi daftar dari kode rekening, nama
rekening, klasifikasinya (aktiva, utang, modal, pendapatan-pendapatan, dan biaya-biaya), serta
petunjuk dari masing-masing rekening bagaimana rekening tersebut dipergunakan.
3. Dokumentasi Prosedur Manual

Merupakan dokumentasi yang menunjukkan arus dari dokumen-dokumen dasar di dalam
perusahaan. Dokumentasi ini menyedia-kan informasi mengenai bagian mana yang menyiapkan
dokumen dasar, jumlah tembusannya, bagian-bagian mana saja yang mengarsipkannya dan
kepada bagian mana saja dokumen dasar tersebut harus dikirimkan
4. Dokumentasi Prosedur
Dokumentasi prosedur dapat berisi prosedur-prosedur yang harus dilakukan pada suatu
keadaan tertentu, seperti misalnya prosedur pengetesan program, prosedur penggunaan file,
prosedur pembuatan back-up dan restore, dsb.
5. Dokumentasi Sistem
Dokumentasi sistem menunjukkan bentuk dari sistem informasi yang digambarkan dalam bagan
alir sistem (system flowchart). Pada dokumentasi ini dapat terlihat deskripsi dari input yang
digunakan, deskripsi output yang digunakan, deskripsi output yang dihasilkan, deskripsi file-file
yang digunakan, berita-berita kesalahan pengolahan dan daftar-daftar pengendalian untuk tiap-
tiap sistem pengolahan. Dokumentasi sistem merupakan dokumen yang dibutuhkan oleh sistem
analis, pemakai sistem, dan auditor.
6. Dokumentasi Program
Dokumentasi program menggambarkan logika dari program dalam bentuk bagan alir program
(program flowchart), tabel keputusan (decision table) dan bentuk pengendalian program.
Dokumentasi program sangat dibutuhkan oleh programmer bila akan memodifikasi atau
mengembangkan program.
7. Dokumentasi Operasi
Dokumentasi operasi berisi penjelasan-penjelasan cara dan prosedur-prosedur mengoperasikan
program. Dokumentasi ini sangat berguna untuk operator.
8. Dokumentasi DataDokumentasi data berisi definisi-definisi dari item-item data di dalam
database yang digunakan oleh sistem informasi. Yang paling banyak membutuhkan dokumentasi
ini adalah data base administrator (DBA) dan auditor
Sedangkan tujuan dokumentasi adalah :
1. Arus komunikasi
Komunikasi terjadi dalam tiga arah :
- Ke bawah untuk melakukan instruksi
- Ke atas untuk memberi laporan
- Ke samping (Lateral) untuk memberi saran
2. Untuk memberi informasi
Penting kiranya untuk terus menerus memberi informasi kepada orang tentang apa yang telah,
sedang, dan akan dilakukan, serta segala perubahan dalam pekerjaan yang telah ditetapkan.
3. Untuk mengidentifikasi
Beberapa dokumentasi dirancang untuk mengidentifikasi.
4. Untuk menetapkan prosedur dan standar
Prosedur menentukan rangkaian kegiatan yang akan dilaksanakan, sedangkan Standar
menentukan aturan yang akan dianut dalam menjalankan prosedur tersebut.
5. Untuk mencatat
Dokumentasi akan diperlukan unutuk memonitor kinerja peralatan, sistem, dan sumber daya
manusia. Dari dokumentasi ini, manajemen dapat memutuskan atau menilai apakah
departemen tersebut memenuhi atau mencapai tujuannya dalam skala waktu dan batasan
sumber dayanya. Selain itu manajemen dapat mengukur kualitas pekerjaan, yaitu apakah
outputnya sesuai dengan spesifikasi dan standar yang telah ditetapkan.
6. Untuk memberi instruksi
Dokumentasi yang baik akan membantu dalam pelatihan staf, apakah pelatihan untuk tujuan
penanganan instalasi baru atau untuk tujuan promosi.
Prinsip Dokumentasi :
1. Metode
Komunikasi yang baik tidak terjadi begitu saja. Manajer Operasi harus menetapkan dan
memelihara saluran komunikasi dan menetapkan kontrol guna memastikan bahwa saluran
komunikasi tersebut terbuka dan dapat digunakan. Manajer Operasi harus
memberi perhatian khusus pada :
- Siapa yang bertanggung jawab atas perpustakaan ?
- Siapa yang membuat atau menghasilkan dokumentasi
- Kapan dokumentasi tersebut harus dibuat ?
- Sirkulasi
- Pemeliharaan
- Aksesibilitas
2. Jumlah dokumentasi
Manajer Operasi harus mencoba untuk mengarsip dokumentasi agar dapat mencapai
keseimbangan antara jumlah yang terlalu banyak dan terlalu sedikit.
3. Kesederhanaan
Dokumentasi harus bersifat sederhana dan langsung, sehingga ia dapat dilengkapi secara
mudah dan dapat dipahami secara langsung. Hal ini dapat merangsang munculnya
partisipasi dan meningkatkan keakuratan. Informasi yang tidak akurat, tidak hanya tidak
andal namun juga menyesatkan.
4. Desain Form
Perlu dirancang sejumlah form untuk digunakan menurut kepentingan atau kegunaan kita
sendiri. Dalam merancang sebuah form untuk dokumentasi perlu dipertimbangkan
hal-hal berikut ini :
- Typeface (huruf ketikkannya)
- Tata letak
- Warna
- Referensi
- Identifikasi
MODUL PERKULIAHAN
Modul Standar untuk

13 18017
Studi Sistem
Informasi
Abstract Kompetensi
Pemliharaan Sistem dalam SDLC Memahami Pemeliharaan Sistem dalam
SDLC
PEMELIHARAAN SISTEM
Definisi Pemeliharaan Sistem
Pemeliharaan Sistem adalah suatu kombinasi dari berbagai tindakan yang dilakukan untuk
menjaga suatu sistem dalam, atau memperbaikinya sampai, suatu kondisi yang bisa diterima.
Pada bulan April 1970 didefinisikan sebuah istilah untuk Teknologi Pemeliharaan yang
mencakup pengertian yang lebih luas dari pada pengertian Pemeliharaan diatas. Istilah ini adalah
Teroteknologi.
Sistem perlu dipelihara karena beberapa hal, yaitu :
1. Sistem memiliki kesalahan yang dulunya belum terdeteksi, sehingga kesalahan-kesalahan

sistem perlu diperbaiki.
2. Sistem mengalami perubahan-perubahan karena permintaan baru dari pemakai sistem.
3. Sistem mengalami perubahan karena perubahan lingkungan luar (perubahan bisnis).
4. Sistem terinfeksi malware aktif
5. Sistem berkas corrupt
6. Perangkat keras melemah
Untuk mencegah hal-hal tesebut, digunakanlah mOS(maintenance Operating system) yang

berfungsi untuk:
-Manajemen Malware yang aktif
-Pemulihan data (recovery) dan perbaikan sistem berkas
-Diagnosa perangkat keras.

mOS tidak menulis ke disk atau menjalankan kode apapun dari disk, memiliki akses langsung ke
perangkat keras, dan hanya membutuhkan sedikit bagian dari perangkat keras untuk bekerja
dengan sempurna. Selain dengan mOS, kita juga dapat memelihara sistem (pada windows)
dengan cara-cara yang sederhana seperti:
-Jangan pernah mematikan power sampai sistem benar-benar sudah shutdown.
-Buatlah backup data-data yang penting.
-Lakukan defragment setidaknya satu bulan sekali
-Sisakan sedikitspace kosong di partisi tempat sistem operasi berada
-Gunakan firewall jika anda terkoneksi dengan jaringan.
-Lakukan pengecekan virus secara rutin.
Selain dengan menggunakan mOS pemeliharaan sistem juga dapat dilakukan dengan cara :
■ Pemeliharaan Korektif
Pemeliharaan korektif adalah bagian pemeliharaan sistem yang tidak begitu tinggi nilainya dan
lebih membebani, karena pemeliharaan ini mengkoreksi kesalahan-kesalahan yang ditemukan
pada saat sistem berjalan. Umumnya pemeliharaan korektif ini mencakup kondisi penting atau
bahaya yang memerlukan tindakan segera. Kemampuan untuk mendiagnosa atau memperbaiki
kesalahan atau malfungsi dengan cepat sangatlah berharga bagi perusahaan.
■ Pemeliharaan Adaptif
Pemeliharaan adaptif dilakukan untuk menyesuaikan perubahan dalam lingkungan data atau
pemrosesan dan memenuhi persyaratan pemakai baru. Lingkungan tempat sistem beroperasi
adalah dinamik, dengan demikian, sistem harus terus merespon perubahan persyaratan pemakai.
Misalnya, Undang-Undang Perpajakan yang baru mungkin memerlukan suatu perubahan dalam
kalkulasi pembayaran bersih. Umumnya pemeliharaan adatif ini baik dan tidak dapat dihindari.
■ Pemeliharaan Perfektif (Penyempurnaan)
Pemeliharaan penyempurnaan mempertinggi cara kerja atau maintainabilitas (kemampuan untuk

dipelihara). Tindakan ini juga memungkinkan sistem untuk memenuhi persyaratan pemakai yang
sebelumnya tidak dikenal. Ketika membuat perubahan substansial modul apapun, petugas
pemeliharaan juga menggunakan kesempatan untuk meng-upgrade kode, mengganti cabang-
cabang yang kadaluwarsa, memperbaiki kecerobohan, dan mengembangkan dokumentasi.
Sebagai contoh, kegiatan pemeliharaan ini dapat berbentuk perekayasaan ulang atau
restrukturisasi perangkat lunak, penulisan ulang dokumentasi, pengubahan format dan isi
laporan, penentuan logika pemrosesan yang lebih efisien, dan pengembangan efisiensi
pengoperasian perangkat.
■ Pemeliharaan Preventif
Pemeliharaan Preventif terdiri atas inspeksi periodik dan pemeriksaan sistem untuk mengungkap
dan mengantisipasi permasalahan. Karena personil pemeliharaan sistem bekerja dalam sistem ini,
mereka seringkali menemukan cacat-cacat (bukan kesalahan yang sebenarnya) yang menandakan
permasalahan potensial. Sementara tidak memerlukan tindakan segera, cacat ini bila tidak
dikoreksi di tingkat awal, jelas sekali akan mempengaruhi baik fungsi sistem maupun
kemampuan untuk memeliharanya dalam waktu dekat.
Memelihara Perangkat Lunak

Perangkat lunak aplikasi mungkin terstruktur mungkin pula tidak, atau mungkin
didokumentasikan mungkin pula tidak. Beberapa perangkat lunak yang tidak terstruktur dan
tidak didokumentasikan mungkin hampir tidak dapat dipelihara. Sebenarnya salah satu sebab
utama mengapa pemeliharaan sistem memerlukan anggaran sistem yang amat banyak adalah
karena kenaikan tenaga yang dibutuhkan untuk mencoba memelihara perangkat lunak yang
didokumentasikan serta distruktur secara acak-acakan. Di lain pihak program perangkat lunak
yang tidak terstruktur dan tidak terdokumentasi juga tidak dapat dipelihara. Seandainya suatu
perubahan dalam operasi memaksa program itu untuk berubah, maka program itu harus
disingkirkan dan dikembangkanlah program baru. Sehinga menyia-nyiakan semua sumber yang
dikeluarkan untuk
membangun program asli yang tidak dapat dipelihara tersebut, belum lagi kerugian operasi bisnis
bila hari yang ditentukan tiba.
Memelihara Perangkat Keras

Pemeliharaan perangkat keras terutama pemeliharaan preventif yang memerlukan reparasi,
penggantian, atau penambahan suku cadang dan komponen untuk merestorasi atau menjaga agar
perangkat keras tetap bekerja dengan baik. Komponen perangkat keras sistem informasi
sebaiknya dicek dan diservis secara periodik
Siklus Hidup Pemeliharaan Sistem (SMLC)

-Permintaan Perubahan
-Mengubah permohonan pemeliharaan menjadi suatu perubahan
-Menspesifikasi perubahan Membangun pengganti
-Menguji pengganti
-Melatih pengguna dan melakukan tes penerimaan
-Pengkonversian dan pelepasan ke operasi
-Mengupdate dokumentasi
-Melakukan pemeriksaan pascaimplementasi
Mengatur Pemeliharaan Sistem

-Menetapkan kegiatan pemeliharaan
-Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal
-HELP DESK
-Mengevaluasi aktivitas pemeliharaan sistem
Tahapan-Tahapan Siklus Hidup Pemeliharaan Sistem (SMLC)
Tahap pemeliharaan dilakukan setelah tahap implementasi. Sistem baru yang berjalan digunakan
sesuai dengan keperluan organisasi. Selama masa hidupnya, sistem secara periodik akan ditinjau.
Perubahan dilakukan jika muncul masalah atau jika ternyata ada kebutuhan baru. Selanjutnya,
organisasi akan menggunakan sistem yang telah diperbaiki tersebut.
Pemeliharaan sistem dilaksanakan untuk 3 alasan:
1. Memperbaiki kesalahan
2. Menjaga kemutakhiran sistem
3. Meningkatkan sistem
4. Menyiapkan usulan rekayasa ulang
5. Menyetujui atau menolak rekayasa ulang sistem
Merupakan siklus terakhir dari SDLC Pemeriksaan periodik, audit dan permintaan pengguna
akan menjadi source untuk melakukan perawatan sistem diseluruh masa hidup sistem.
Jenis Pemeliharaan :
1.Pemeliharaan Korektif
2.Pemeliharaan Adaptif
3.Pemeliharaan Perfektif
4.Pemeliharaan Preventif
Siklus Hidup Pemeliharaan Sistem (SDLC) :

1.Permintaan Perubahan
2.Mengubah permohonan pemeliharaan menjadi suatu perubahan
3.Menspesifikasi perubahan
4.Membangun pengganti
5.Menguji pengganti
6.Melatih pengguna dan melakukan tes penerimaan

1.Pengkonversian dan pelepasan ke operasi
2.Mengupdate dokumentasi
3.Melakukan pemeriksaan pascaimplementasi
Prosedur Pemeliharaan Sistem :

1.SDLC dan SWDLC
2.Definisi data standar
3.Bahasa pemrograman standar
4.Rancangan Moduler
5.Model yang dapat digunakan kembali
6.Dokumentasi standar
7.Kontrol sentral
a. Memahami Permintaan Pemeliharaan
b. Mentransformasi Permintaan Pemeliharaan Menjadi Pengubahan
c. Menspesifikasi Perubahan
d. Mengembangkan Perubahan
e. Menguji Perubahan
f. Melatih Pengguna dan Melakukan Test Penerimaan
g. Pengkonversian dan Meluncurkan Operasi
h. Mengupdate Dokumen
i. Melakukan Pemeriksaan Pasca Implementasi
Case Tools Untuk memelihara Sistem :

1.Forward engineering
2.Reverse Engineering
3.Reengineering
4.Restrukturing
5.Maintenance Expert Systems
Mengatur Pemeliharaan Sistem :

1.Menetapkan kegiatan pemeliharaan
2.Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal HELP DESK
3.Mengevaluasi aktivitas pemeliharaan sistem
Langkah-langkah pemeliharaan sistem terdiri atas:

1. Penggunaan Sistem
Yaitu menggunakan sistem sesuai dengan fungsi tugasnya masing-masing untuk operasi rutin
atau sehari-hari.
2. Audit Sistem
Yaitu melakukan penggunaan dan penelitian formal untuk menentukan seberapa baik sistem baru
dapat memenuhi kriteria kinerja. Hal semacam ini disebut penelaahan setelah penerapan dan
dapat dilakukan oleh seorang auditor internal.
3. Penjagaan Sistem
Yaitu melakukan pemantauan untuk pemeriksaan rutin sehingga sistem tetap beroperasi dengan
baik. Selain itu juga untuk menjaga kemutakhiran sistem jika sewaktu-waktu terjadi perubahan
lingkungan sistem atau modifikasi rancangan software.
4. Perbaikan Sistem
Yaitu melakukan perbaikan jika dalam operasi terjadi kesalahan (bugs) dalam program atau
kelemahan rancangan yang tidak terdeteksi saat tahap pengujian sistem.
5. Peningkatan Sistem
Yaitu melakukan modifikasi terhadap sistem ketika terdapat potensi peningkatan sistem setelah
sistem berjalan beberapa waktu, biasanya adanya potensi peningkatan sistem tersebut terlihat
oleh manajer kemudian diteruskan kepada spesialis informasi untuk dilakukan modifikasi sesuai
keinginan manajer.
Jenis-Jenis Pemeliharaan :
– Pemeliharaan Korektif
– Pemeliharaan Adaptif
– Pemeliharaan Perfektif
– Pemeliharaan Preventif
Siklus Hidup Pemeliharaan Sistem (SMLC):

– Pengkonversian dan pelepasan ke operasi
– Mengupdate dokumentasi
– Melakukan pemeriksaan pascaimplementasi
Prosedur Pemeliharaan sistem :

– SDLC dan SWDLC
– Definisi data standar
– Bahasa pemrograman standar
– Rancangan Moduler
– Model yang dapat digunakan kembali
– Dokumentasi standar
– Kontrol sentral

– Forward engineering
– Reverse Engineering
– Reengineering
– Restrukturing
– Maintenance Expert Systems
Mengatur Pemeliharaan sistem :
– Menetapkan kegiatan pemeliharaan
– Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal
– HELP DESK
– Mengevaluasi aktivitas pemeliharaan system
Alat-Alat Pemliharaan Sistem
 Hardware Yang dibutuhkan sesuai dengan kebutuhan system

 Software yang di butuhkan sesuai dengan kebutuhan system
Mengatur Pemeliharaan sitem
 Tentukan jadwal maintenance pada system yang kita miliki

 Update software yang compatible terhadap system kita
 Gunakan tenaga ahli yang terpercaya untuk
Mengembangkan Perubahan Sistem manajemen
Salah satu konsep yang dibahas, , dan dianalisis paling sering dalam beberapa tahun terakhir
telah terjadi perubahan organisasi dan konsep terkait resistensi terhadap perubahan dan
manajemen perubahan. Perubahan telah banyak didefinisikan sebagai membuat perbedaan materi
dalam sesuatu dibandingkan dengan keadaan sebelumnya, atau mengubah sesuatu, atau hanya
menjadi berbeda. Semua definisi ini dapat diterapkan untuk mengubah seperti itu terjadi dalam
organisasi dan bisnis. Perubahan organisasi bisa berarti perubahan teknologi infrastruktur
(misalnya, bergerak dari lingkungan mainframe untuk komputasi terdistribusi), strategi
pemasaran (target basis pelanggan baru), atau manajemen dan praktek pengambilan keputusan.
Perubahan organisasi bukanlah hal baru dengan lanskap bisnis Amerika. Sejak abad kesembilan
belas dan Revolusi Industri, perusahaan harus berurusan dengan perubahan dalam skala yang
semakin cepat. Semakin besar perkembangan teknologi dan semakin besar jumlah produk dan
informasi yang dihasilkan, semakin diperlukan menjadi bagi perusahaan untuk memberikan
manajemen yang efektif dan mengembangkan praktek organisasi yang solid Para profesional
bisnis yang paling dihormati di Amerika Serikat telah orang-orang yang paling mampu
memanfaatkan perubahan dalam bisnis dan perekonomian. Sebagai contoh, pada akhir abad
kesembilan belas, Andrew Carnegie sangat memperluas kerajaannya dengan membeli usaha
yang sangat ia bergantung pada untuk bisnis baja-nya, membuat satu perusahaannya contoh
sukses pertama dari integrasi vertikal.
Dimulai pada 1990-an, perubahan datang pada tingkat yang secara eksponensial lebih cepat
karena faktor-faktor seperti persaingan yang meningkat dalam ekonomi global, memperluas
pasar, cara-cara baru melakukan bisnis (seperti e-commerce), dan tugas di mana-mana menjaga
dengan yang terbaru teknologi. Guru manajemen Peter F. Drucker mengabdikan bukunya
Manajemen Tantangan dari 21 abad ke topik yang sangat. Akibatnya, perusahaan harus merevisi
(atau menyusun) misi perusahaan dan tujuan, praktek manajemen, dan fungsi bisnis sehari-hari.
Perusahaan secara rutin mulai merancang ulang strategi bisnis, sering menggantikan bagan
organisasi tradisional hirarki dengan struktur datar berpusat di sekitar “diberdayakan” tim.
Tujuan utama bagi kebanyakan organisasi adalah untuk perubahan iklim dan budaya perusahaan.
iklim Suatu organisasi dapat didefinisikan oleh bagaimana karyawan melihat alasan mendasar
organisasi. karena, khususnya, misi perusahaan secara keseluruhan dan tujuan dan bagaimana
pentingnya pengertian karyawan kesejahteraan adalah tujuan-tujuan tersebut. Iklim perusahaan
kemudian melahirkan budaya organisasi yang terdiri dari apa karyawan lihat sebagai
kepercayaan manajemen dan sistem nilai. Kedua hal, iklim dan budaya, kemudian menentukan
bagaimana setiap manajer dan karyawan bentuk kinerja nya sendiri, biasanya dalam rangka
paling berhasil mencapai tujuan perusahaan dan mudah-mudahan memastikan keberhasilan
sendiri serta perusahaan. Faktor-faktor ini mempengaruhi setiap aspek dari pekerjaan setiap
orang, termasuk proses pengambilan keputusan, pola komunikasi dalam organisasi, dan
tanggung jawab individu dan tanggung jawab perusahaan.
INDIKATOR PERUBAHAN
Ada empat indikator utama dari perubahan pekerjaan-tempat utama.. Mereka adalah perubahan
struktur organisasi, produk atau jasa baru, manajemen baru, dan teknologi baru. Struktur
Organisasi bisa berubah melalui perampingan besar, outsourcing, akuisisi, atau merger. Tindakan
ini sering disertai dengan PHK, khususnya sebagai posisi tertentu menjadi berlebihan.. Sebuah
produk atau jasa baru memiliki implikasi untuk perubahan dalam produksi, penjualan, dan
layanan pelanggan.. Selain itu, dengan mengubah produk atau jasa organisasi mungkin
menghadapi pesaing baru atau pasar baru.. manajemen baru, seperti perubahan dalam CEO atau
presiden, sering membawa masa transisi di mana para manajer tingkat atas cenderung untuk
mengubah proses bisnis yang ada dan kebijakan personil. Akhirnya, teknologi baru dapat
membuat perubahan besar bagi organisasi. Teknologi dapat mengubah proses produksi atau
kondisi kerja (yaitu, telecommuting), dan perubahan ini mungkin mempengaruhi keterampilan
yang karyawan menggunakan pada pekerjaan.
MODUL PERKULIAHAN
Modul Standar untuk

13 18017
Studi Sistem
Informasi
Abstract Kompetensi
Pemliharaan Sistem dalam SDLC Memahami Pemeliharaan Sistem dalam
SDLC
PEMELIHARAAN SISTEM
Definisi Pemeliharaan Sistem
Pemeliharaan Sistem adalah suatu kombinasi dari berbagai tindakan yang dilakukan untuk
menjaga suatu sistem dalam, atau memperbaikinya sampai, suatu kondisi yang bisa diterima.
Pada bulan April 1970 didefinisikan sebuah istilah untuk Teknologi Pemeliharaan yang
mencakup pengertian yang lebih luas dari pada pengertian Pemeliharaan diatas. Istilah ini adalah
Teroteknologi.
Sistem perlu dipelihara karena beberapa hal, yaitu :
7. Sistem memiliki kesalahan yang dulunya belum terdeteksi, sehingga kesalahan-kesalahan

sistem perlu diperbaiki.
8. Sistem mengalami perubahan-perubahan karena permintaan baru dari pemakai sistem.
9. Sistem mengalami perubahan karena perubahan lingkungan luar (perubahan bisnis).
10. Sistem terinfeksi malware aktif
11. Sistem berkas corrupt
12. Perangkat keras melemah
Untuk mencegah hal-hal tesebut, digunakanlah mOS(maintenance Operating system) yang

berfungsi untuk:
-Manajemen Malware yang aktif
-Pemulihan data (recovery) dan perbaikan sistem berkas
-Diagnosa perangkat keras.

mOS tidak menulis ke disk atau menjalankan kode apapun dari disk, memiliki akses langsung ke
perangkat keras, dan hanya membutuhkan sedikit bagian dari perangkat keras untuk bekerja
dengan sempurna. Selain dengan mOS, kita juga dapat memelihara sistem (pada windows)
dengan cara-cara yang sederhana seperti:
-Jangan pernah mematikan power sampai sistem benar-benar sudah shutdown.
-Buatlah backup data-data yang penting.
-Lakukan defragment setidaknya satu bulan sekali
-Sisakan sedikitspace kosong di partisi tempat sistem operasi berada
-Gunakan firewall jika anda terkoneksi dengan jaringan.
-Lakukan pengecekan virus secara rutin.
Selain dengan menggunakan mOS pemeliharaan sistem juga dapat dilakukan dengan cara :
■ Pemeliharaan Korektif
Pemeliharaan korektif adalah bagian pemeliharaan sistem yang tidak begitu tinggi nilainya dan
lebih membebani, karena pemeliharaan ini mengkoreksi kesalahan-kesalahan yang ditemukan
pada saat sistem berjalan. Umumnya pemeliharaan korektif ini mencakup kondisi penting atau
bahaya yang memerlukan tindakan segera. Kemampuan untuk mendiagnosa atau memperbaiki
kesalahan atau malfungsi dengan cepat sangatlah berharga bagi perusahaan.
■ Pemeliharaan Adaptif
Pemeliharaan adaptif dilakukan untuk menyesuaikan perubahan dalam lingkungan data atau
pemrosesan dan memenuhi persyaratan pemakai baru. Lingkungan tempat sistem beroperasi
adalah dinamik, dengan demikian, sistem harus terus merespon perubahan persyaratan pemakai.
Misalnya, Undang-Undang Perpajakan yang baru mungkin memerlukan suatu perubahan dalam
kalkulasi pembayaran bersih. Umumnya pemeliharaan adatif ini baik dan tidak dapat dihindari.
■ Pemeliharaan Perfektif (Penyempurnaan)
Pemeliharaan penyempurnaan mempertinggi cara kerja atau maintainabilitas (kemampuan untuk

dipelihara). Tindakan ini juga memungkinkan sistem untuk memenuhi persyaratan pemakai yang
sebelumnya tidak dikenal. Ketika membuat perubahan substansial modul apapun, petugas
pemeliharaan juga menggunakan kesempatan untuk meng-upgrade kode, mengganti cabang-
cabang yang kadaluwarsa, memperbaiki kecerobohan, dan mengembangkan dokumentasi.
Sebagai contoh, kegiatan pemeliharaan ini dapat berbentuk perekayasaan ulang atau
restrukturisasi perangkat lunak, penulisan ulang dokumentasi, pengubahan format dan isi
laporan, penentuan logika pemrosesan yang lebih efisien, dan pengembangan efisiensi
pengoperasian perangkat.
■ Pemeliharaan Preventif
Pemeliharaan Preventif terdiri atas inspeksi periodik dan pemeriksaan sistem untuk mengungkap
dan mengantisipasi permasalahan. Karena personil pemeliharaan sistem bekerja dalam sistem ini,
mereka seringkali menemukan cacat-cacat (bukan kesalahan yang sebenarnya) yang menandakan
permasalahan potensial. Sementara tidak memerlukan tindakan segera, cacat ini bila tidak
dikoreksi di tingkat awal, jelas sekali akan mempengaruhi baik fungsi sistem maupun
kemampuan untuk memeliharanya dalam waktu dekat.
Memelihara Perangkat Lunak

Perangkat lunak aplikasi mungkin terstruktur mungkin pula tidak, atau mungkin
didokumentasikan mungkin pula tidak. Beberapa perangkat lunak yang tidak terstruktur dan
tidak didokumentasikan mungkin hampir tidak dapat dipelihara. Sebenarnya salah satu sebab
utama mengapa pemeliharaan sistem memerlukan anggaran sistem yang amat banyak adalah
karena kenaikan tenaga yang dibutuhkan untuk mencoba memelihara perangkat lunak yang
didokumentasikan serta distruktur secara acak-acakan. Di lain pihak program perangkat lunak
yang tidak terstruktur dan tidak terdokumentasi juga tidak dapat dipelihara. Seandainya suatu
perubahan dalam operasi memaksa program itu untuk berubah, maka program itu harus
disingkirkan dan dikembangkanlah program baru. Sehinga menyia-nyiakan semua sumber yang
dikeluarkan untuk
membangun program asli yang tidak dapat dipelihara tersebut, belum lagi kerugian operasi bisnis
bila hari yang ditentukan tiba.
Memelihara Perangkat Keras

Pemeliharaan perangkat keras terutama pemeliharaan preventif yang memerlukan reparasi,
penggantian, atau penambahan suku cadang dan komponen untuk merestorasi atau menjaga agar
perangkat keras tetap bekerja dengan baik. Komponen perangkat keras sistem informasi
sebaiknya dicek dan diservis secara periodik
Siklus Hidup Pemeliharaan Sistem (SMLC)

-Permintaan Perubahan
-Mengubah permohonan pemeliharaan menjadi suatu perubahan
-Menspesifikasi perubahan Membangun pengganti
-Menguji pengganti
-Melatih pengguna dan melakukan tes penerimaan
-Pengkonversian dan pelepasan ke operasi
-Mengupdate dokumentasi
-Melakukan pemeriksaan pascaimplementasi
Mengatur Pemeliharaan Sistem

-Menetapkan kegiatan pemeliharaan
-Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal
-HELP DESK
-Mengevaluasi aktivitas pemeliharaan sistem
Tahap pemeliharaan dilakukan setelah tahap implementasi. Sistem baru yang berjalan digunakan
sesuai dengan keperluan organisasi. Selama masa hidupnya, sistem secara periodik akan ditinjau.
Perubahan dilakukan jika muncul masalah atau jika ternyata ada kebutuhan baru. Selanjutnya,
organisasi akan menggunakan sistem yang telah diperbaiki tersebut.
Pemeliharaan sistem dilaksanakan untuk 3 alasan:
1. Memperbaiki kesalahan
2. Menjaga kemutakhiran sistem
3. Meningkatkan sistem
4. Menyiapkan usulan rekayasa ulang
5. Menyetujui atau menolak rekayasa ulang sistem
Merupakan siklus terakhir dari SDLC Pemeriksaan periodik, audit dan permintaan pengguna
akan menjadi source untuk melakukan perawatan sistem diseluruh masa hidup sistem.
Jenis Pemeliharaan :
1.Pemeliharaan Korektif
2.Pemeliharaan Adaptif
3.Pemeliharaan Perfektif
4.Pemeliharaan Preventif

1.Permintaan Perubahan
2.Mengubah permohonan pemeliharaan menjadi suatu perubahan
3.Menspesifikasi perubahan
4.Membangun pengganti
5.Menguji pengganti
6.Melatih pengguna dan melakukan tes penerimaan

1.Pengkonversian dan pelepasan ke operasi
2.Mengupdate dokumentasi
3.Melakukan pemeriksaan pascaimplementasi
Prosedur Pemeliharaan Sistem :

1.SDLC dan SWDLC
2.Definisi data standar
3.Bahasa pemrograman standar
4.Rancangan Moduler
5.Model yang dapat digunakan kembali
6.Dokumentasi standar
7.Kontrol sentral
a. Memahami Permintaan Pemeliharaan
b. Mentransformasi Permintaan Pemeliharaan Menjadi Pengubahan
c. Menspesifikasi Perubahan
d. Mengembangkan Perubahan
e. Menguji Perubahan
f. Melatih Pengguna dan Melakukan Test Penerimaan
g. Pengkonversian dan Meluncurkan Operasi
h. Mengupdate Dokumen
i. Melakukan Pemeriksaan Pasca Implementasi

1.Forward engineering
2.Reverse Engineering
3.Reengineering
4.Restrukturing
5.Maintenance Expert Systems
Mengatur Pemeliharaan Sistem :

1.Menetapkan kegiatan pemeliharaan
2.Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal HELP DESK
3.Mengevaluasi aktivitas pemeliharaan sistem
Langkah-langkah pemeliharaan sistem terdiri atas:

1. Penggunaan Sistem
Yaitu menggunakan sistem sesuai dengan fungsi tugasnya masing-masing untuk operasi rutin
atau sehari-hari.
2. Audit Sistem
Yaitu melakukan penggunaan dan penelitian formal untuk menentukan seberapa baik sistem baru
dapat memenuhi kriteria kinerja. Hal semacam ini disebut penelaahan setelah penerapan dan
dapat dilakukan oleh seorang auditor internal.
3. Penjagaan Sistem
Yaitu melakukan pemantauan untuk pemeriksaan rutin sehingga sistem tetap beroperasi dengan
baik. Selain itu juga untuk menjaga kemutakhiran sistem jika sewaktu-waktu terjadi perubahan
lingkungan sistem atau modifikasi rancangan software.
4. Perbaikan Sistem
Yaitu melakukan perbaikan jika dalam operasi terjadi kesalahan (bugs) dalam program atau
kelemahan rancangan yang tidak terdeteksi saat tahap pengujian sistem.
5. Peningkatan Sistem
Yaitu melakukan modifikasi terhadap sistem ketika terdapat potensi peningkatan sistem setelah
sistem berjalan beberapa waktu, biasanya adanya potensi peningkatan sistem tersebut terlihat
oleh manajer kemudian diteruskan kepada spesialis informasi untuk dilakukan modifikasi sesuai
keinginan manajer.
Jenis-Jenis Pemeliharaan :
– Pemeliharaan Korektif
– Pemeliharaan Adaptif
– Pemeliharaan Perfektif
– Pemeliharaan Preventif
Siklus Hidup Pemeliharaan Sistem (SMLC):

– Pengkonversian dan pelepasan ke operasi
– Mengupdate dokumentasi
– Melakukan pemeriksaan pascaimplementasi
Prosedur Pemeliharaan sistem :

– SDLC dan SWDLC
– Definisi data standar
– Bahasa pemrograman standar
– Rancangan Moduler
– Model yang dapat digunakan kembali
– Dokumentasi standar
– Kontrol sentral

– Forward engineering
– Reverse Engineering
– Reengineering
– Restrukturing
– Maintenance Expert Systems
Mengatur Pemeliharaan sistem :
– Menetapkan kegiatan pemeliharaan
– Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal
– HELP DESK
– Mengevaluasi aktivitas pemeliharaan system
Alat-Alat Pemliharaan Sistem
 Hardware Yang dibutuhkan sesuai dengan kebutuhan system

 Software yang di butuhkan sesuai dengan kebutuhan system
Mengatur Pemeliharaan sitem
 Tentukan jadwal maintenance pada system yang kita miliki

 Update software yang compatible terhadap system kita
 Gunakan tenaga ahli yang terpercaya untuk
Mengembangkan Perubahan Sistem manajemen
Salah satu konsep yang dibahas, , dan dianalisis paling sering dalam beberapa tahun terakhir
telah terjadi perubahan organisasi dan konsep terkait resistensi terhadap perubahan dan
manajemen perubahan. Perubahan telah banyak didefinisikan sebagai membuat perbedaan materi
dalam sesuatu dibandingkan dengan keadaan sebelumnya, atau mengubah sesuatu, atau hanya
menjadi berbeda. Semua definisi ini dapat diterapkan untuk mengubah seperti itu terjadi dalam
organisasi dan bisnis. Perubahan organisasi bisa berarti perubahan teknologi infrastruktur
(misalnya, bergerak dari lingkungan mainframe untuk komputasi terdistribusi), strategi
pemasaran (target basis pelanggan baru), atau manajemen dan praktek pengambilan keputusan.
Perubahan organisasi bukanlah hal baru dengan lanskap bisnis Amerika. Sejak abad kesembilan
belas dan Revolusi Industri, perusahaan harus berurusan dengan perubahan dalam skala yang
semakin cepat. Semakin besar perkembangan teknologi dan semakin besar jumlah produk dan
informasi yang dihasilkan, semakin diperlukan menjadi bagi perusahaan untuk memberikan
manajemen yang efektif dan mengembangkan praktek organisasi yang solid Para profesional
bisnis yang paling dihormati di Amerika Serikat telah orang-orang yang paling mampu
memanfaatkan perubahan dalam bisnis dan perekonomian. Sebagai contoh, pada akhir abad
kesembilan belas, Andrew Carnegie sangat memperluas kerajaannya dengan membeli usaha
yang sangat ia bergantung pada untuk bisnis baja-nya, membuat satu perusahaannya contoh
sukses pertama dari integrasi vertikal.
Dimulai pada 1990-an, perubahan datang pada tingkat yang secara eksponensial lebih cepat
karena faktor-faktor seperti persaingan yang meningkat dalam ekonomi global, memperluas
pasar, cara-cara baru melakukan bisnis (seperti e-commerce), dan tugas di mana-mana menjaga
dengan yang terbaru teknologi. Guru manajemen Peter F. Drucker mengabdikan bukunya
Manajemen Tantangan dari 21 abad ke topik yang sangat. Akibatnya, perusahaan harus merevisi
(atau menyusun) misi perusahaan dan tujuan, praktek manajemen, dan fungsi bisnis sehari-hari.
Perusahaan secara rutin mulai merancang ulang strategi bisnis, sering menggantikan bagan
organisasi tradisional hirarki dengan struktur datar berpusat di sekitar “diberdayakan” tim.
Tujuan utama bagi kebanyakan organisasi adalah untuk perubahan iklim dan budaya perusahaan.
iklim Suatu organisasi dapat didefinisikan oleh bagaimana karyawan melihat alasan mendasar
organisasi. karena, khususnya, misi perusahaan secara keseluruhan dan tujuan dan bagaimana
pentingnya pengertian karyawan kesejahteraan adalah tujuan-tujuan tersebut. Iklim perusahaan
kemudian melahirkan budaya organisasi yang terdiri dari apa karyawan lihat sebagai
kepercayaan manajemen dan sistem nilai. Kedua hal, iklim dan budaya, kemudian menentukan
bagaimana setiap manajer dan karyawan bentuk kinerja nya sendiri, biasanya dalam rangka
paling berhasil mencapai tujuan perusahaan dan mudah-mudahan memastikan keberhasilan
sendiri serta perusahaan. Faktor-faktor ini mempengaruhi setiap aspek dari pekerjaan setiap
orang, termasuk proses pengambilan keputusan, pola komunikasi dalam organisasi, dan
tanggung jawab individu dan tanggung jawab perusahaan.
INDIKATOR PERUBAHAN
Ada empat indikator utama dari perubahan pekerjaan-tempat utama.. Mereka adalah perubahan
struktur organisasi, produk atau jasa baru, manajemen baru, dan teknologi baru. Struktur
Organisasi bisa berubah melalui perampingan besar, outsourcing, akuisisi, atau merger. Tindakan
ini sering disertai dengan PHK, khususnya sebagai posisi tertentu menjadi berlebihan.. Sebuah
produk atau jasa baru memiliki implikasi untuk perubahan dalam produksi, penjualan, dan
layanan pelanggan.. Selain itu, dengan mengubah produk atau jasa organisasi mungkin
menghadapi pesaing baru atau pasar baru.. manajemen baru, seperti perubahan dalam CEO atau
presiden, sering membawa masa transisi di mana para manajer tingkat atas cenderung untuk
mengubah proses bisnis yang ada dan kebijakan personil. Akhirnya, teknologi baru dapat
membuat perubahan besar bagi organisasi. Teknologi dapat mengubah proses produksi atau
kondisi kerja (yaitu, telecommuting), dan perubahan ini mungkin mempengaruhi keterampilan
yang karyawan menggunakan pada pekerjaan.
MODUL PERKULIAHAN
Modul Standar untuk

15 18017
Studi Sistem
Informasi
Abstract Kompetensi
Distribusi Perangkat Lunak Memahami Distribusi Perangkat Lunak
Pendistribusian Proyek Pengujian
Dalam suatu proyek tes kadang-kadang ada pihak dan orang-orang di luar organisasi testing
yang harus turut terlibat. Bahkan dalam suatu proyek tes perangkat lunak harus melibatkan pihak
atau orang-orang dari luar organisasi.
Cara tersebut diatas dapat dilakukan dengan cara :
1. Melibatkan vendor : perusahaan yang menyediakan produk yang akan dintegrasikan pada
produk yang sedang dikembangkan.
2. Melibatakan organisasi testing independen.
3. Melibatkan kantor pemasaran (terutama kantor di luar negeri untuk melakukan testing
lokalisasi)
4. Melibatkan pemakai/pelanggan (beta testing)
Tahap mendistribusikan proses pengujian
1. Pemilihan rekanan, berdasarkan kebutuhan akan testing yang bersifat khusus.
2. Perencanaan
3. Pengelolaan proses testing yang dilakukan secara ekster-nal seperti bila kita melaku-kannya
secara internal.
Pemilihan rekanan
Ada dua alasan untuk memilih rekanan:
1. Memanfaatkan kemampuan/ kelebihan yang dimiliki rekanan.
2. Untuk mengurangi beban pekerjaan.

Pihak yang dapat dijadikan rekanan dalam proyek (Vendor/Pemasok, Third-Party Testers, Sales
Office)
Pemasok / Vendor
Ada 3 faktor utama utk melibatkan vendor dlm proses testing : Irreplaceability, Coupling,
Capability
Third-Party Testers
1. Sumber daya testing dari pihak ketiga adalah setiap organisasi yang menawarkan jasa testing
kepada pelanggannya.
2. Jasa ini dpt diberikan secara off site, on site, atau keduanya.
3. Berdasarkan caranya mengelola proyek testing, organisasi pihak ketiga yang menawarkan
jasa testing dapat dibedakan menjadi 2, yaitu:

Temporary Agency (Agen Sementara) : menyediakan ahli testing.

Perusahaan Testing Pihak Ketiga : membuat perencanaan suatu proyek testing dan
pengelolaannya.
Keuntungan pemanfaatan Third-Party Tester
1. Memiliki keahlian dalam bidang pengelolaan proyek testing dan memiliki pengalaman untuk
melakukan testing secara teknis.
2. Dapat menyelesaikan proyek testing lebih cepat.

Kantor Pemasaran
1. Kantor pemasaran yg tersebar di seluruh dunia dpt dimanfaat-kan untuk melakukan testing
yang berhubungan dengan lokalisasi suatu sistem.
2. Kelemahannya: tidak dapat melakukan proses testing yang rumit atau yg bersifat terlalu
teknis.
Perencanaan sebuah proyek uji yang terdistribusi
1. Menilai Kemampuan
2. Biaya: biaya tetap dan biaya waktu dan material

3. Menyusun, mengkoordinasi, dan membagi program testing.
4. Pengelolaan Logistik
5. Pemetaan Kasus Testing
Pemetaan kasus Testing
1. Memetakan kasus testing yang dilakukan oleh pihak ketiga pada pola yang sesuai dengan
kebutuhan.
2. Dilakukan pada tahap koordinasi proyek testing.
Pengelolaan testing yang terdistribusi
1. Memantau pelaksanaan testing.
2. Mengkomunikasikan status testing.

3. Menangani Pertimbangan2 Politis
4. Peka terhadap terjadinya Pertentangan kebiasaan/ kebudayaan.
5. Menanamkan dan menjaga unsur kepercayaan.
MODUL PERKULIAHAN
Modul Standar untuk

14 18017
Studi Sistem
Informasi
Abstract Kompetensi
Oranisasi dalam Pengetesan Memahami Organisasi Dalam
Perangkat Lunak Pengetesan Perangkat Lunak

0 - Modul Testing Dan Implementasi

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

0 - Modul Testing Dan Implementasi

Diunggah oleh

Hak Cipta:

Format Tersedia

MODUL PERKULIAHAN

Testing dan Implementasi SI

Modul Standar untuk

Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh

Beberapa gambaran umum tentang perangkat lunak antara lain :

Jenis-jenis software antara lain :

 Fleksibel dengan hardware yang ada saat ini

Ada dua tipe produk perangkat lunak :

2. Produk pesanan (yang disesuaikan)

Apakah yang dimaksud dengan pengujian perangkat lunak ?

 Pengujian adalah proses menjalankan sebuah program dengan maksud menemukan

1.Pengujian cacat (Defect Testing)

 Menetapkan keberadaan cacat sistem.

Kaner, Falk dan Nguyen mengusulkan atribut-atribut dari

pengujian yang “baik” sebagai berikut :

2. Pengujian yang baik tidak redundan.

3. Pengujian yang baik seharusnya “jenis terbaik”

Kekurangan-kekurangan tersebut antara lain :

2.Pengujian tidak akan menemukan semua kesalahan

3.Pengujian sulit dan menghabiskan banyak waktu

4.Pengujian sebagian besar masih merupakan tugas yang tidak resmi.

 Seorang Programmer seharusnya tidak menguji programnya sendiri.

Selain pernyataan diatas, Roger S. Pressman mendefinisikan sendiri mengenai prinsip-prinsip

 Pengujian harus sesuai dengan persyaratan konsumen.

Kegagalan dan Kesalahan

 Kegagalan sistem (system failure)

 Eror sistem (system eror)

 Kesalahan sistem (system fault)

 Eror atau kesalahan manusia (human error)

Perilaku manusia yang mengakibatkan kesalahan sistem.

Bagaimana kesalahan tersebut mempengaruhi kita ?

Gejala dari kesalahan yang mengganggu kita secara estetis

 Kesalahan yang berpengaruh pada penampilan system

 • Kesalahan dari system karena adanya suatu virus.

▫ Nama yang terpotong

▫ Tagihan untuk Rp. 0,00 di cetak / dikirim

 Sistem menolak untuk menangani transaksi yang sah

▫ Kartu kredit yang dilaporkan tidak bisa digunakan

 • Perhitungan yang salah

▫ Hal ini menghilangkan hubungan pada proses transaksi

▫ Tidak mencetak setiap pembayaran

F. VERY SERIOUS (sangat serius)

 Kesalahan yang menyebabkan system melakukan transaksi yang salah

▫ Sebuah system kredit dapat melakukan kesalahan perhitungan.

 Masalah yang tidak terbatas pada beberapa transaksi

H. INTOLERABLE (kurang tahan)

 Pertimbangan yang serius diberikan untuk mematikan system.

I. CATASTROPHIC (bencana besar)

 Sistem yang salah

Testing dan Implementasi SI

Modul Standar untuk

Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh

1. OPERABILITY. (Mampu menjalankan/operasi.)

 Semakin baik hal tersebut dijalankan, pengujian akan semakin efesien.

2. OBSERVABILITY(Kemampuan untuk mengamati/meneliti) “Apa yang dilihat adalah apa

 Output yang berbeda dikeluarkan oleh masing-masing input.

3. CONTROLLABILITY(Kemampuan untuk mengawasi)

5. SIMPLICITY (Kemampuan untuk menyederhanakan kerumitan).

 Semakin sedikit yang diuji, semakin cepat kita dapat mengujinya.

 Semakin sedikit perubahan, semakin sedikit gangguan dalam pengujian.

7. UNDERSTANDBILITY (kemampuan untuk memahami/mengerti).

Ÿ MENGAPA PROGRAM MENGALAMI KERUSAKAN ?

Ÿ Mereka lebih memperbaiki kerusakan-kerusakan selama pengujian.