Modul Standar untuk digunakan dalam Perkuliahan di...

127
‘13 1 Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning Team Dosen http://www.mercubuana.ac.id 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 Disini diisi Fakultas penerbit Modul Program Studi Sistem Informasi 1 18017 Tim Dosen Abstract Kompetensi Define Software Testing Scope, Purpose and Objective. Introduction for Testing in Software Engineering Understanding purposes and objective of Software Testing in Industri

Transcript of Modul Standar untuk digunakan dalam Perkuliahan di...

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Disini diisi Fakultas penerbit Modul

Program Studi Sistem Informasi

1 18017 Tim Dosen

Abstract Kompetensi

Define Software Testing Scope, Purpose and Objective. Introduction for Testing in Software Engineering

Understanding purposes and objective of Software Testing in Industri

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

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

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 5

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 6

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 7

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 8

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

‘13 9

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Disini diisi Fakultas penerbit Modul

Program Studi Sistem Informasi

2 18017 Tim Dosen

Abstract Kompetensi

A method how to organize software development project

Understanding Software Development a Life Cycle in Software Engineering.

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

Ÿ 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

‘13 5

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Disini diisi Fakultas penerbit Modul

Program Studi Sistem Informasi

3 18017 Tim Dosen

Abstract Kompetensi

Production of High Quality Software and Its Development life Cycle

Understanding Production of High Quality Software and Its Development life Cycle

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 5

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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 :

‘13 6

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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 :

‘13 7

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Disini diisi Fakultas penerbit Modul

Program Studi Sistem Informasi

4 18017 Tim Dosen

Abstract Kompetensi

Basic of Software Testing, Model of Software Testing Blackbox and White Box

Understanding a methodology to test a Software with Graph, Path.

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 5

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 6

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 7

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 8

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Disini diisi Fakultas penerbit Modul

Program Studi Sistem Informasi

5 18017 Tim Dosen

Abstract Kompetensi

Blackbox testing and Technique to implement a software testing with blackbox.

Understanding Black box testing and its component

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 5

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 6

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 7

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

pengembang sistem dan pelanggan setuju bahwa sistem yang diserahkan merupakan

implementasi yang dapat diterima dari persyaratan sistem.

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Disini diisi Fakultas penerbit Modul

Program Studi Sistem Informasi

6 18017 Tim Dosen

Abstract Kompetensi

Software Testing in Object Oriented Analysis and Design

Understanding Software Testing in Object Oriented Analysis and Design

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

Pengujian integrasi, integrasi berfokus pada kelas-kelas dan eksekusinya pada satu thread

atau use case.

Pengujian validasi, menggunakan pengujian kotak hitam tradisional

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Disini diisi Fakultas penerbit Modul

Program Studi Sistem Informasi

7 18017 Tim Dosen

Abstract Kompetensi

Stratefy of Software Testing Approach and Validation Testing

Understanding Stratefy of Software Testing Approach and Validation Testing

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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)

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 5

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 6

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 7

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 8

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 9

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 10

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Fasilkom Program Studi Sistem Informasi

9 18017 Tim Dosen

Abstract Kompetensi

Produktivitas dan Kualitas Perangkat Lunak

Mengerti dan Memahami Kualitas dan Produktivitas Perangkat Lunak

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 5

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 6

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 7

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 8

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 9

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 10

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 11

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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 .

‘13 12

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 13

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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:

‘13 14

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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:

‘13 15

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 16

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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:

‘13 17

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Fasilkom Program Studi Sistem Informasi

10 18017 Tim Dosen

Abstract Kompetensi

Metriks untuk Object Oriented Software Metrik Teknis Untuk Sistem Berorientasi Objek

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 5

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 6

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 7

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 8

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 9

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 10

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 11

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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:

‘13 12

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

Cara perhitungan :

Berikut hasil pengukuran metrik LCOM pada program Characters Graphic

‘13 13

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 14

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

+ 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

‘13 15

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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)

‘13 16

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 17

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

Pada paper berjudul “Applying and Interpreting Object Oriented Metrics” yang ditulis oleh Dr.

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:

‘13 18

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

Berikut hasil pengukuran metrik NOC pada seluruh class 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 DIT dan NOC dengan

menggunakan NASA project data sebagai berikut:

‘13 19

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Fasilkom Program Studi Sistem Informasi

11 18017 Tim Dosen

Abstract Kompetensi

Impelementasi Sistem

Impelementasi Sistem

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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)

‘13 5

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Fasilkom Program Studi Sistem Informasi

12 18017 Tim Dosen

Abstract Kompetensi

Dokumentasi Perangkat Lunak Memahami Dokumentasi Perangkat Lunak

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 5

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

- 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

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Fasilkom Program Studi Sistem Informasi

13 18017 Tim Dosen

Abstract Kompetensi

Pemliharaan Sistem dalam SDLC Memahami Pemeliharaan Sistem dalam SDLC

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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 :

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

■ 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

‘13 5

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 6

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Siklus Hidup Pemeliharaan Sistem (SDLC) :

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

‘13 7

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

Tahapan-Tahapan Siklus Hidup Pemeliharaan Sistem (SMLC)

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.

‘13 8

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Case Tools Untuk memelihara Sistem :

– Forward engineering

– Reverse Engineering

– Reengineering

– Restrukturing

– Maintenance Expert Systems

‘13 9

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 10

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Fasilkom Program Studi Sistem Informasi

13 18017 Tim Dosen

Abstract Kompetensi

Pemliharaan Sistem dalam SDLC Memahami Pemeliharaan Sistem dalam SDLC

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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 :

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

■ 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

‘13 5

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 6

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Siklus Hidup Pemeliharaan Sistem (SDLC) :

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

‘13 7

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

Tahapan-Tahapan Siklus Hidup Pemeliharaan Sistem (SMLC)

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.

‘13 8

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Case Tools Untuk memelihara Sistem :

– Forward engineering

– Reverse Engineering

– Reengineering

– Restrukturing

– Maintenance Expert Systems

‘13 9

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

‘13 10

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Fasilkom Program Studi Sistem Informasi

15 18017 Tim Dosen

Abstract Kompetensi

Distribusi Perangkat Lunak Memahami Distribusi Perangkat Lunak

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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.

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

5. Menanamkan dan menjaga unsur kepercayaan.

‘13 1

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Fasilkom Program Studi Sistem Informasi

14 18017 Tim Dosen

Abstract Kompetensi

Oranisasi dalam Pengetesan Perangkat Lunak

Memahami Organisasi Dalam Pengetesan Perangkat Lunak

‘13 2

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

‘13 3

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

‘13 4

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

‘13 5

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

‘13 6

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

‘13 7

Nama Mata Kuliah dari Modul Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id