rekayasa perangkat lunak
TRANSCRIPT
Rekayasa Perangkat Lunak
DAFTAR ISI
BAB 1. PENGANTAR RPL ..................................................................................................... 1 A. PENGERTIAN RPL .......................................................................................................................... 1
B. KEGUNAAN RPL .......................................................................................................................... 11
C. PERKEMBANGAN RPL ................................................................................................................. 12
D. DESKRIPSI RPL ............................................................................................................................. 12
E. KARAKTERISTIK RPL .................................................................................................................... 13
F. KOMPONEN RPL ......................................................................................................................... 13
G. APLIKASI RPL ............................................................................................................................... 13
BAB 2. MANAGING SOFTWARE PROJECTS ........................................................................ 15 A. PROJECT MANAGEMENT CONCEPT ............................................................................................ 15
B. SOFTWARE PROJECT PLANNING ................................................................................................. 17
C. RISK ANALYSIS AND MANAGEMENT .......................................................................................... 20
D. SQA ............................................................................................................................................. 24
BAB 3. METODE KONVENSIONAL UNTUK SOFTWARE ENGINEERING ................................ 26 A. SYSTEM ENGINEERING ............................................................................................................... 26
B. REQUIREMENT ENGINEERING .................................................................................................... 30
BAB 4. ANALISIS ............................................................................................................... 35 A. KONSEP DAN PRINSIP ANALISIS .................................................................................................. 35
B. MODEL ANALISIS ........................................................................................................................ 42
C. ANALISIS TERSTRUKTUR ............................................................................................................. 44
D. KAMUS DATA .............................................................................................................................. 46
BAB 5. DESAIN .................................................................................................................. 48 A. PROSES DESAIN .......................................................................................................................... 48
B. PRINSIP‐PRINSIP DESAIN ............................................................................................................ 50
C. KONSEP DESAIN .......................................................................................................................... 51
D. EFECTIVE MODULAR DESIGN ...................................................................................................... 57
E. ARCHITECTURAL DESIGN ............................................................................................................ 58
F. USER INTERFACE DESIGN............................................................................................................ 62
BAB 6. DESAIN UNTUK SYSTEM REAL‐TIME ...................................................................... 64 A. SYSTEM REAL‐TIME ..................................................................................................................... 64
B. ANALISIS DAN SIMULASI UNTUK SYSTEM REAL‐TIME ............................................................... 68
C. DESAIN REAL‐TIME .................................................................................................................... 75
BAB 7. TEKNIK PENGUJIAN PERANGKAT LUNAK ............................................................... 77 A. DASAR‐DASAR PENGUJIAN PERANGKAT LUNAK ........................................................................ 77
B. TEST CASE DESIGN .................................................................................................................... 78
C. WHITE‐BOX TESTING .................................................................................................................. 80
D. CONTROL STRUCTURE TESTING ................................................................................................. 84
BAB 8. STRATEGI PENGUJIAN PERANGKAT LUNAK............................................................ 98 A. PENDEKATAN STRATEGIS KE PENGUJIAN PERANGKAT LUNAK .................................................. 98
B. MASALAH‐MASALAH STRATEGIS ................................................................................................ 99
C. PENGUJIAN UNIT ...................................................................................................................... 100
D. PENGUJIAN INTEGRASI ............................................................................................................. 102
E. PENGUJIAN VALIDASI ............................................................................................................... 103
F. PENGUJIAN SISTEM .................................................................................................................. 103
G. PENGUJIAN DEBUGGING .......................................................................................................... 104
BAB 9. OBJECT ORIENTED SOFTWARE ENGINEERING ...................................................... 109 A. KONSEP DAN PRINSIP OBJECT ORIENTED ................................................................................ 109
B. OBJECT ORIENTED ANALIS ........................................................................................................ 118
C. OOA VS CONVENSIONAL .......................................................................................................... 125
D. UNIFIED MODELLING LANGUAGE (UML) .................................................................................. 125
E. OBJECT ORIENTED DESIGN ....................................................................................................... 135
BAB 10. CLIENT SERVER SOFTWARE ENGINEERING ......................................................... 137 A. STRUKTUR DARI SISTEM CLIENT‐ SERVER ................................................................................ 137
B. SOFTWARE ENGINEERING UNTUK SISTEM CLIENT SERVER ..................................................... 145
C. DESAIN UNTUK CLIENT‐SERVER SISTEM ................................................................................... 150
BAB 11. WEB ENGINEERING ........................................................................................... 156 A. ATRIBUT DARI APLIKASI WEB ................................................................................................... 161
B. DESAIN UNTUK WEB‐BASED APPLICATION ............................................................................. 162
C. TESTING WEB‐DESIGN APLICATION .......................................................................................... 165
1
BAB 1 PENGANTAR RPL
Rekayasa perangkat lunak merupakan sebuah disiplin ilmu yang bertujuan
mengembangkan sistem perangkat lunak yang efektif dari segi biaya. Perangkat lunak bersifat
abstrak dan tidak nyata. Rekayasa perangkat lunak masih merupakan disiplin yang relatif muda.
Istilah rekayasa perangkat lunak pertama kali diajukan pada tahun 1968.
A. PENGERTIAN RPL
Banyak orang menyamakan istilah perangkat lunak dengan program komputer.
Sesungguhnya pandangan ini terlalu dangkal, perangkat lunak tidak hanya mencakup program,
tetapi juga semua dokumentasi dan konfigurasi data yang berhubungan (Sommerville, 2003).
Rekayasa perangkat lunak adalah disiplin ilmu yang membahas semua aspek produksi
perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan.
Di sisi lain terdapat istilah yang juga tidak kalah populer adalah computer science atau
ilmu komputer. Pada intinya computer science berhubungan dengan teori dan metode yang
mendasari sistem komputer dan perangkat lunak. Sedangkan rekayasa perangkat lunak
berhubungan dengan masalah-masalah praktis dalam memproduksi perangkat lunak.
Pengetahuan tetang computer science sangat penting bagi perekayasa perangkat lunak sama
seperti pengetahuan tentang fisika sangat penting bagi teknik kelistrikan.
Istilah lain yang juga populer adalah rekayasa sistem atau rekayasa sistem berbasis
komputer. Rekayasa sistem berhubungan dengan pengembangan perangkat keras,
perancangan kebijakan dan proses, dan penyebaran sistem sebagaimana pada rekayasa
perangkat lunak. Rekayasa sistem merupakan disiplin yang lebih tua dari rekayasa perangkat
lunak.
1. PRODUCT
Saat ini perangkat lunak memiliki dua peran. Peran pertama berfungsi sebagai sebuah
produk dan peran kedua sebagai kendaraan yang mengantarkan sebuah produk (Pressman,
2002). Sebagai produk perangkat lunak mengantarkan potensi perhitungan yang dibangun
oleh perangkat lunak komputer. Tidak peduli apakah perangkat lunak ada dalam telepon
seluler, dalam mainframe komputer. Perangkat lunak merupakan transformer informasi yang
memproduksi, mengatur, memperoleh, memodifikasi, menampilkan atau menyebarkan
2
informasi dimana pekerjaan ini dapat menjadi sederhana suatu bit tunggal atau sekompleks
simulasi multimedia. Sebagai kendaraan yang dipakai untuk mengantarkan produk, perangkat
lunak berlaku sebagai dasar untuk kontrol komputer (sistem operasi), komunikasi informasi
(jaringan komputer).
Untuk memperoleh pemahaman tentang perangkat lunak serta pemahaman tentang
rekayasa perangkat lunak penting juga untuk mengetahui karakteristik yang membuat
perangkat lunak berbeda dengan dengan produk lain yang dihasilkan oleh manusia. Ketika
perangkat lunak dibuat proses kreatif manusia (analisis, desain, konstruksi dan pengujian)
diterjemahkan ke dalam bentuk fisik.
2. PROCESS
Proses perangkat lunak merupakan serangkaian kegiatan dan hasil-hasil relevan yang
menghasilkan perangkat lunak. Kegiatan-kegiatan ini sebagian besar dilakukan oleh perekayasa
perangkat lunak. Ada empat kegiatan proses dasar perangkat lunak:
1) Spesifikasi perangkat lunak, fungsional perangkat lunak dan batasan kemampuan
operasinya harus didefinisikan.
2) Pengembangan perangkat lunak, perangkat lunak yang memenuhi spesifikasi tersebut
harus dipenuhi.
3) Validasi perangkat lunak, perangkat lunak harus divalidasi untuk menjamin bahwa
perangkat lunak melakukan apa yang diinginkan oleh pelanggan.
4) Evolusi perangkat lunak, perangkat lunak harus dikembangkan untuk memenuhi
kebutuhan pelanggan yang berubah-ubah.
Proses perangkat lunak yang berbeda mengatur kegiatan ini dengan cara yang berbeda
dan dijelaskan dengan tingkat kerincian yang berbeda pula. Waktu kegiatan bervariasi,
sebagaimana hasilnya.
Proses perangkat lunak sangat rumit dan seperti semua proses intelektual, bergantung
pada penilaian manusia. Karena dibutuhkan penilaian dan kreatifitas keberhasilan usaha untuk
mengotomasi proses perangkat lunak menjadi terbatas. Satu alasan mengapa otomasi proses
memiliki cakupan terbatas adalah adanya keragaman proses perangkat lunak. Tidak ada proses
yang ideal dan organisasi berbeda yang mengembangkan pendekatan yang benar-benar
berbeda dalam pengembangan perangkat lunak.
3
1. Model Proses Perangkat Lunak
Model proses perangkat lunak merupakan deksripsi yang disederhanakan dari proses
perangkat lunak yang dipresentasikan dengan sudut pandang tertentu. Model sesuai sifatnya,
merupakan penyederhanaan sehingga model proses bisa mencakup kegiatan yang merupakan
bagian dari proses perangkat lunak, produk perangkat lunak, peran orang yang terlibat pada
rekayasa perangkat lunak.
a. Model Air Terjun (Waterfall)
Model ini dikenal sebagai model air terjun atau siklus hidup pengembangan perangkat
lunak. Model ini dapat dilihat pada Gambar 1.1. Tahap-tahap utama dari model ini
memetakan kegiatan-kegiatan pengembangan dasar, yaitu:
1) Analisis dan Definisi persyaratan. Pelayanan, batasan dan tujuan sistem ditentukan
melalui konsultasi dengan user sistem. Persyaratan ini kemudian didefinisikan secara
rinci dan berfungsi sebagai spesifikasi sistem.
2) Perancangan sistem dan perangkat lunak. Proses perancangan sistem membagi
persyaratan dalam sistem perangkat keras atau perangkat lunak. Kegiatan ini
menentukan arsitektur sistem secara keseluruhan. Perancangan perangkat lunak
melibatkan identifikasi dan deskripsi abstraksi sistem perangkat lunak yang mendasar
dan hubungan-hubungannya.
3) Implementasi dan pengujian unit. Pada tahap ini, perancangan perangkat lunak
direalisasikan sebagai serangkaian program atau unit program. Pengujian unit
melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasi.
4) Integrasi dan pengujian sistem. Unit program atau program individual diintegrasikan
dan diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem telah
dipenuhi. Setelah pengujian sistem, perangkat lunak dikirim kepada pelanggan.
5) Operasi dan pemeliharaan. Biasanya merupakan fase siklus hidup yang paling lama.
Sistem diinstall dan dipakai. Pemeliharaan mencakup koreksi dan berbagai error yang
tidak ditemukan pada tahap-tahap terdahulu, perbaikan atas implementasi unit sistem
dan pengembangan pelayanan system, sementara persyaratan-persyaratan baru
ditambahkan.
4
Gambar 1.1 Model Waterfall
b. Model Sekuensial Linier
Gambar 1.2a menggambarkan sekuensial linier untuk rekayasa perangkat lunak, yang
sering disebut juga dengan “siklus kehidupan klasik” atau “model air terjun.”
Gambar 1.2a Fase lingkaran pemecahan masalah (Raccoon, 1995)
5
Status Quo
Problem Definition
Status Quo
Solution Integration
Teknikal Development
Problem Definition
Status Quo
Solution Integration
Teknikal Development
Problem Definition
Status Quo
Solution Integration
Teknikal Development
Gambar 1.2b Fase-fase di dalam fase lingkaran pemecahan masalah (Raccoon, 1995)
Pemodelan Sistem Informasi
Analisis Desain Kode Tes
Gambar 1.3 Model sekuensial linier
Sekuensial linier mengusulkan sebuah pendekatan kepada perkembangan perangkat
lunak yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada
seluruh analisis, desain, kode, pengujian, dan pemeliharaan. Dimodelkan setelah siklus
rekayasa konvensional, model sekuensial linier melingkupi aktivitas-aktivitas sebagai
berikut:
1. Rekayasa dan Pemodelan Sistem/Informasi
Karena perangkat lunak selalu merupakan bagian dari sebuah sistem (bisbis) yang lebih
besar, kerja dimulai dengan membangun syarat dari semua elemen sistem dan
mengalokasikan beberapa subset dari kebutuhan ke perangkat lunak tersebut.
Pandangan sistem ini penting ketika perangkat lunak harus berhubungan dengan
6
elemen-elemen yang lain seperti perangkat lunak, manusia, dan database. Rekayasa
dan analisis sistem menyangkut pengumpulan kebutuhan pada tingkat sistem dengan
sejumlah kecil analisis serta desain tingkat puncak. Rekayasa informasi mencakup juga
pengumpulan kebutuhan pada tingkat bisnis strategis dan tingkat area bisnis.
2. Analisis Kebutuhan Perangkat Lunak
Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khususnya pada
perangkat lunak. Untuk memahami sifat program yang dibangun, perekayasa perangkat
lunak (analis) harus memahami domain informasi, tingkah laku, unjuk kerja, dan antar-
muka (interface) yang diperlukan. Kebutuhan baik untuk sistem maupun perangkat
lunak di dokumentasikan dan dilihat lagi dengan pelanggan.
3. Desain
Desain perangkat lunak sebenarnya adalah proses multi langkah yang berfokus pada
empat atribut sebuah program yang berbeda; struktur data, arsitektur perangkat lunak,
representasi interface, dan detail (algoritma) procedural. Proses desain menerjemahkan
syarat/kebutuhan ke dalam sebuah representasi perengkat lunak yang dapat
diperkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana
persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi perangkat
lunak.
4. Generasi Kode
Desain harus diterjemahkan ke dalam bentuk mesin yang bisa dibaca. Langkah
pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap,
pembuatan kode dapat diselesaikan secara mekanis.
5. Pengujian
Sekali kode dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika
internal perangkat lunak, memastikan bahwa semua pernyataan sudah diuji, dan pada
eksternal fungsional – yaitu mengarahkan pengujian untuk menemukan kesalahan-
kesalahan dan memastikan bahwa input yang akan memberikan hasil actual yang
sesuai dengan hasil yang dibutuhkan.
6. Pemeliharaan
Perangkat lunak akan mengalami perubahan setelah disampaikan kepada pelanggan
(perkecualian yang mungkin adalah perangkat lunak yang dilekatkan). Perubahan akan
terjadi karena kesalahan-kesalahan ditentukan, karena perangkat lunak harus
7
disesuaikan untuk mengakomodasi perubahan-perubahan di dalam lingkungan
eksternalnya (contohnya perubahan yang dibutuhkan sebagai akibat dari perangkat
peripheral atau sistem operasi yang baru), atau karena pelanggan membutuhkan
perkembangan fungsional atau unjuk kerja. Pemeliharaan perangkat lunak
mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang baru
lagi.
Model sekuensial linier adalah paradigma rekayasa perangkat lunak yang paling luas
dipakai dan paling tua. Tetapi kritik dari paradigma tersebut telah menyebabkan dukungan aktif
untuk mempertanyakan kehandalannya (Hanna, 1995). Masalah-masalah yang kadang–kadang
terjadi ketika model sekuensial linier diaplikasikan adalah:
a) Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model.
Meskipun model linier bias mengakomodasi iterasi, model itu melakukannya dengan cara
tidak langsung. Sebagai hasilnya, perubahan-perubahan dapat menyebabkan keraguan
pada saat tim proyek berjalan.
b) Kadang-kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya secara
ekplisit. Model linier sekuensial memerlukan hal ini dan mengalami kesulitan untuk
mengakomodasi ketidakpastian natural yang ada pada bagian awal beberapa proyek.
c) Pelanggan harus bersikap sabar. Sebuah versi kerja dari program-program itu tidak akan
diperoleh sampai akhir waktu proyek dilalui. Sebuah kesalahan besar, jika tidak terdeteksi
sampai program yang bekerja tersebut dikaji ulang, bias menjadi petaka.
d) Pengembang sering melakukan penundaan yang tidak perlu. Di dalam analisis yang
menarik tentang proyek actual, (Bradac, 1994) mendapatkan bahwa sifat alami dari siklus
kehidupan klasik membawa kepada blocking state dimana banyak anggota tim proyek
harus menunggu tim yang lain untuk melengkapi tugas yang saling memiliki
ketergantungan. Kenyataannya, waktu yang dipakai untuk menunggu bisa mengurangi
waktu untuk usaha produktif! Blocking state cenderung menjadi lebih lazim pada awal dan
akhir sebuah proses sekuensial linier.
Masing-masing dari masalah tersebut bersifat riil. Tetapi paradigm siklus kehidupan
klasik memiliki tempat yang terbatas namun penting di dalam kerja rekayasa perangkat lunak.
Paradigma itu memberikan template dimana metode analisis, desain, pengkodean, pengujian,
dan pemeliharaan bisa dilakukan. Siklus kehidupan klasik tetap menjadi model bagi rekayasa
perangkat lunak yang paling luas dipakai. Sekalipun memiliki kelemahan, secara signifikan dia
8
lebih baik daripada pendekatan yang sifatnya sembrono kepada pengembangan perangkat
lunak.
c. Model Prototipe
Sering seorang pelanggan mendifinisikan serangkaian sasaran umum bagi perangkat
lunak, tetapi tidak melakukan mengidentifikasi kebutuhan output, pemrosesan, ataupun
input detail. Pada kasus yang lain, pengembang mungkin tidak memiliki kepastian terhadap
efisiensi algoritme, kemampuan penyesuaian dari sebuah system operasi, atau bentuk-
bentuk yang harus dilakukan oleh interaksi manusia dengan mesin. Dalam hal ini, serta
pada banyak situasi yang lain, prototyping paradigm mungkin menawarkan pendekatan
yang terbaik.
Prototyping paradigma (Gambar 1.4) dimulai dengan pengumpulan kebutuhan.
Pengembang dan pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari
perangkat lunak, mengidentifikasi segala kebutuhan yang diketahui, dan area garis besar
dimana definisi lebih jauh merupakan keharusan kemudian dilakukan “perancangan kilat”.
Perancangan kilat berfokus pada penyajian dari aspek –aspek perangkat lunak tersebut
yang akan Nampak bagi pelanggan/pemakai (contohnya pendekatan input dan format
output). Perancangan kilat membawa kepada konstruksi sebuah prototype. Prototipe
tersebut dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaring kebutuhan
pengembangan perangkat lunak. Iterasi terjadi pada saat protipe disetel untuk memenuhi
kebutuhan pelanggan, dan pada saat yang sama memungkinkan pengembang untuk
secara lebih baik memahami apa yang harus dilakukannya.
Gambar 1.4 Prototipe Paradigma
Secara ideal prototype berfungsi sebagai sebuah mekanisme untuk mengidentifikasi
kebutuhan perangkat lunak. Bila prototype yang sedang bekerja dibangun, pengembang
harus mempergunakan fragmen-fragmen program yang ada atau mengaplikasikan alat-alat
Mendengarkan Pelanggan
Uji Pelanggan-Mengendalikan
Market
Membangun Memperbaiki
Market
9
bantu (contohnya report generator, window manager, dll) yang memungkinkan program
yang bekerja untuk dimunculkan secara cepat.
Tetapi apa yang kita lakukan dengan prototype tersebut pada saat dia sudah melayani
usulan yang digambarkan di atas? (Brooks, 1975) memberikan jawabannya:
Pada sebagian besar proyek, system pertama yang dibangun baru saja bisa
dipergunakan. Sistem mungkin terlalu pelan, terlalu besar, janggal di dalam pemakaian,
atau bahkan ketiganya. Tidak ada alternatif lain selain mulai lagi, tidak dengan halus tetapi
dengan lebih halus lagi, dan membangun sebuah versi yang dirancang kembali di mana
masalah-masalah tersebut bisa diselesaikan … Ketika sebuah konsep system baru atau
teknologi baru dipergunakan, seseorang harus membangun sebuah system sebagai
pembuangan, bahkan untuk perencanaan terbaik sekalipun, tidak akan mudah untuk
membuatnya benar pada pertama kalinya. Dengan demikian, pertanyaan manajemen
tidaklah untuk membangun sebuah system contoh dan untuk membuangnya. Anda akan
melakukannya. Satu-satunya pertanyaan adalah apakah akan merencanakan lebih dulu
untuk membangun sebuah pembuangan, atau menjanjikan untuk menyampaikan
pembuangan tersebut kepada pelanggan …………..
Prototipe bisa berfungsi sebagai “system yang pertama”. Brooks setuju bila kita
membuangnya. Tetapi mungkin ini merupakan pandangan yang ideal. Memang benar
bahwa baik pelanggan maupun pengembang menyukai paradigma prototype. Para
pemakai merasa enak dengan system aktual, sedangkan pengembang bisa
membangunnya dengan segera. Tetapi prototyping bisa juga menjadi masalah karena
alasan-alasan sebagai berikut:
a) Pelanggan melihat apa yang tampak sebagai versi perangkat lunak yang bekerja tanpa
melihat bahwa prototype itu dijalin bersama-sama “dengan permen karet dan baling
wire”, tanpa melihat bahwa di dalam permintaan untuk membuatnya bekerja, kita
belum mencantumkan kualitas perangkat lunak secara keseluruhan atau kemampuan
pemeliharaan untuk jangka waktu yang panjang. Ketika diberi informasi bahwa produk
harus dibangun lagi agar tingkat kualitas yang tinggi bisa dijaga, pelanggan akan
meneriakkan kecurangan dan permintaan agar dipakai “beberapa campuran” untuk
membuat protipe menjadi sebuah produk yang bekerja yang lebih sering terjadi,
sehingga manajemen pengembangan perangkat lunak menjadi penuh dengan belas
kasihan.
b) Pengembang sering membuat kompromi-kompromi implementasi untuk membuat
prototype bekerja dengan cepat. Sistem operasi atau bahasa pemrograman yang tidak
10
sesuai bisa dipakai secara sederhana karena mungkin diperoleh dan dikenal; algoritma
yang tidak efisien secara sederhana bisa diimplementasikan untuk mendemontrasikan
kemampuan. Setelah selang waktu tertentu, pengembang mungkin mengenali pilihan-
pilihan tersebut dan melupakan semua alasan mengapa mereka tidak cocok. Pilihan
yang kurang ideal telah menjadi bagian integral dari sebuah system.
Meskipun berbagai masalah bisa terjadi, prototype bisa menjadi paradigm yang efektif
bagi rekayasa perangkat lunak. Kuncinya adalah mmendefinisikan aturan-aturan main pada
saat awal; yaitu pelanggan dan pengembang keduanya harus setuju bahwa prototype
dibangun untuk berfungsi sebagai mekanisme pendefinisian kebutuhan. Prototipe
kemudian disingkirkan (paling tidak sebagian), dan perangkat lunak actual direkayasa
dengan tertuju kepada kualitas dan kemampuan pemeliharaan.
d. Pengembangan Evolusioner
Pengembangan evolusioner berdasarkan ide untuk mengembangkan implementasi awal,
memperlihatkannya kepada user untuk dikomentari, dan memperbaikinya versi demi versi
sampai sistem yang memenuhi persyaratan diperoleh. Model pengembangan evolusioner
dapat dilihat pada Gambar 1.5.
Versi akhir
Spesifikasi
Pengembangan
Validasi
Penjelasan garis besar
Versi awal
Versi akhir
Versi akhirVersi menengah
Gambar 1.5 Model Evolusioner
e. Pengembangan Sistem Formal
Pengembangan sistem formal merupakan pendekatan terhadap pengembangan perangkat
lunak yang memiliki kesamaan dengan model air terjun (waterfall). Tetapi proses
pengembangannya didasarkan pada transformasi matematis dari spesifikasi sistem menjadi
program yang dapat dijalankan. Model pengembangan sistem formal dapat dilihat pada
Gambar 1.6.
11
Gambar 1.6 Model Sistem Formal
f. Pengembangan Berorientasi Pemakaian Ulang
Pada pengembangan perangkat lunak yang besar, terjadi pemakaian ulang. Hal ini
biasanya terjadi secara informal ketika orang yang bekerja di proyek tersebut mengetahui
adanya rancangan atau kode yang mirip dengan yang dibutuhkan. Mereka mencari
rancangan atau kode ini, memodifikasinya sebagaimana dibutuhkan, dan
menggabungkannya dalam sistem. Model pengembangan berorientasi pemakaian ulang
dapat dilihat pada Gambar 1.7.
Spesifikasi Persyaratan
Analisis Komponen
Memodifikasi Persyaratan
Perancangan Sistem dengan pemakaian
ulang
Pengembangan dan integrasi
Validasi Sistem
Gambar 1.7 Model Pengembangan Berorientasi Pemakaian Ulang
B. KEGUNAAN RPL
Perangkat lunak kini sudah menjadi kekuatan yang menentukan. Perangkat lunak
menjadi mesin yang mengendalikan pengambilan keputusan di dalam dunia bisnis. Berfungsi
sebagai dasar dari semua bentuk pelayanan serta penelitian keilmuan modern. Perangkat lunak
dilekatkan pada semua sistem, seperti transportasi, medis, telekomunikasi, militer, proses
industri, hiburan, produk kantor dan sebagainya. Program-program perangkat lunak sudah
tersebar secara luas, dan masyarakat memandangnya sebagai kenyataan teknologi dalam
kehidupan.
12
C. PERKEMBANGAN RPL
Selama masa awal era komputer, perangkat lunak dilihat hanya sebagai suatu
permenungan. Pemrograman komputer menjadi seni di mana di situ terdapat banyak metode
yang sistematis. Perkembangan perangkat lunak sebenarnya tidak dapat diatur sampai terjadi
jadwal yang bergeser, atau biaya yang mulai melonjak. Para pemrogram kemudian mulai
berusaha untuk membuat semuanya benar kembali.
Era kedua evolusi sistem komputer melingkupi decade pertengahan tahun 1960 dan
1970-an. Sistem multiprogram dan multiprosesor memperkenalkan konsep baru interkasi
manusia dan komputer. Konsep ini membuka sebuah dunia aplikasi yang baru serta tingkat
kecanggihan perangkat lunak dan perangkat keras yang baru pula. Sistem real-time dapat
mengumpulkan, menganalisis, serta mengubah data dari banyak sumber sehingga proses
pengontrolan dan penghasilan output tidak lagi berada dalam skala menit, melainkan detik.
Kemajuan dalam penyimpanan online membawa ke generasi pertama sistem manajemen
database.
Tabel 1.1 perkembangan RPL
Tahun-Tahun Awal Era Kedua Era Ketiga Era Keempat - Orientasi Batch - Distribusi terbatas - Perangkat lunak
customisasi
- Multiuser - Real-time - Database - Perangkat lunak
produk
- Sistem terdistribusi - Embedded
intelligence - Perangkat keras
rendah biaya
- System desktop bertenaga kuat
- Teknologi berorientasi objek
- Sistem pakar - Jarigan syaraf
tiruan - Komputasi
parallel - Komputer
jaringan
D. DESKRIPSI RPL
Secara umum rekayasa perangkat lunak memakai pendekatan yang sistematis dan
terorganisir terhadap pekerjaan karena cara ini seringkali paling efektif untuk menghasilkan
perangkat lunak. Rekayasa perangkat lunak adalah disiplin ilmu yang membahas semua aspek
produksi perangkat lunak. Mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem
setelah digunakan. Pada definisi ini ada dua istilah kunci:
1) Disiplin Rekayasa
Perekayasa membuat suatu alat bekerja. Mereka menerapkan teori, metode, dan alat bantu
yang sesuai. Selain itu mereka juga menggunakannya dengan selektif dan selalu mencoba
mencari solusi terhadap permasalahan, walaupun tidak ada teori atau metode yang
13
mendukung. Perekayasa juga menyadari bahwa mereka harus bekerja dalam batasan
organisasi dan keuangan, sehingga mereka berusaha mencari solusi dalam batasan-batasan
ini.
2) Semua Aspek Produksi Perangkat Lunak
Rekayasa perangkat lunak tidak hanya berhubungan dengan proses teknis dari
pengembanga perangkat lunak, tetapi juga dengan kegiatan seperti manajemen proyek
perangkat lunak dan pengembangan alat bantu, metode, dan teori untuk mendukung
produksi perangkat lunak.
E. KARAKTERISTIK RPL
Perangkat lunak lebih kepada logika dan bukan semata elemen fisik. Perbedaan perangkat
lunak dengan perangkat keras yang mendasar adalah:
1) Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuknya yang klasik. 2) Perangkat lunak tidak pernah usang.
Sebagian besar perangkat lunak dibuat secara custom (pemesanan) serta tidak dapat dirakit
dari komponen yang sudah ada.
F. KOMPONEN RPL
Bersamaan dengan perkembangan disiplin keteknikan diciptakan sekumpulan
komponen perancangan standar. Komponen-komponen yang dapat digunakan lagi sudah
diciptakan sehingga ahli teknik dapat benar-benar berkonsentrasi pada elemen-elemen inovatif
suatu perancangan. Dalam dunia perangkat keras hal ini merupakan hal yang harus dicapai
dalam skala yang luas.
Reusability meruapakan suatu cirri penting dari komponen perangkat lunak kualitas
tinggi. Sebuah komponen perangkat lunak harus didesain dan diimplementasi sehingga dapat
dipakai lagi pada berbagai program yang berbeda. Komponen perangkat lunak dibangun
dengan bahasa pemrograman yang memiliki kosakata terbatas, sebuah tata bahasa yang
dibatasi secara eksplisit. Bahasa tingkat mesin merupakan perwakilan simbolik dari
serangkaian instruksi CPU. Bahasa tingkat menengah memungkinkan pengembang
perangkat lunak serta program tidak bergantung pada mesin.
G. APLIKASI RPL
Perangkat lunak dapat diaplikasikan ke berbagai situasi dimana serangkaian procedural
(seperti algoritma) telah didefinisikan (pengecualian-pengecualian yang dapat dicatatat pada
aturan ini adalah sistem pakar dan jaringan syaraf tiruan dalam aplikasi kecerdasan buatan).
14
Kandundan informasi dan determinasi merupakan faktor penting dalam menentukan sifat
aplikasi perangkat lunak.
EVALUASI
1) Apakah yang dimaksud dengan perangkat lunak?
2) Apakah rekayasa perangkat lunak itu?
3) Apa perbedaan antara rekayasa perangkat lunak dan computer science?
4) Apa perbedaan rekayasa perangkat lunak dan rekayasa sistem?
5) Apakah yang dimaksud dengan proses perangkat lunak?
6) Apakah model proses perangkat lunak itu?
15
BAB 2 MANAGING SOFTWARE PROJECTS
A. PROJECT MANAGEMENT CONCEPT
Manajemen perangkat lunak yang efektif berfokus pada tiga P (people/manusia), P
(Problem/masalah) dan P (Process/proses). Manajer proyek yang lupa bahwa kerja rekayasa
perangkat lunak merupakan usaha manusia yang intens tidak akan pernah meraih sukses dalam
manajemen proyek.
1. People
Faktor manusia sangat penting sehingga software engineering institute telah
mengembangkan sebuah model untuk mempertinggi kesiapan ornganisasi perangkat lunak
untuk mengerjakan aplikasi yang semakin kompleks. Model kematangan manajemen manusia
mencakup rekruitmen, seleksi, menajamen untuk kerja, pelatihan, kompensasi, perkembangan
karir, desain kerja dan organisasi serta perkembangan kultur.
Proses perangkat lunak diisi oleh para pemain yang dapat dikategorikan ke dalam salah
satu dari lima kelompok sebagai berikut:
1) Manajer Senior, yang menentukan isu-isu bisnis yang sering memiliki pengaruh
penting di dalam proyek.
2) Manajer (teknik) proyek, yang harus merencanakan, memotivasi, mengorganisir dan
mengontrol sebuah produk atau aplikasi.
3) Pelaksana, yang menyampaikan ketrampilan teknik yang diperlukan untuk
merekayasa sebuah produk atau aplikasi.
4) Pelanggan, yang menentukan jenis kebutuhan bagi perangkat lunak yang akan
direkayasa.
5) Pemakai akhir, yang berinteraksi dengan perangkat lunak bila perangkat lunak telah
dikeluarkan untuk digunakan.
Setiap proyek perangkat lunak dihuni oleh para pemain seperti yang tersebut di atas.
16
2. Problem
Seorang manajer proyek perangkat lunak dihadapkan pada sebuah dilemma pada awal
proyek rekayasa perangkat lunak. Analisis yang mendetail tentang kebutuhan perangkat lunak
akan memberikan informasi yang memadai untuk suatu perhitungan, tetapi analis sering
memerlukan waktu berminggu-minggu atau bahkan berbulan-bulan. Lebih buruk lagi,
kebutuhan terkadang berubah-ubah.
Aktivitas manajemen proyek perangkat lunak yang pertama adalah menentukan ruang
lingkup perangkat lunak. Ruang lingkup dibatasi dengan menjawab pertanyaan berikut:
Konteks. Bagaimana perangkat lunak yang akan dibangun dapat memenuhi sebuah
sistem, produk, atau konteks bisnis yang lebih besar, serta batasan apa yang
ditentukan sebagai hasil dari konteks tersebut.
Tujuan informasi. Objek data pelanggan apa yang dihasilkan sebagai output dari
perangkat lunak? Objek data apa yang diperlukan sebagai input?
Fungsi dan unjuk kerja. Fungsi apa yang dilakukan oleh perangkat lunak untuk
mentransformasikan input data menjadi output? Adakah ciri khusus yang akan
ditekankan?
Ruang lingkup proyek tidak boleh ambigu dan dapat dipahami pada tingkat teknis
maupun manajemen. Selama aktivitas penentuan ruang lingkup berlangsung, tidak ada usaha
untuk secara penuh melakukan dekomposisi masalah. Dekomposisi diterapkan pada dua area
utama (1) fungsionalitas yang harus disampaikan dan (2) proses yang akan dipakai untuk
menyampaikannya.
3. Process
Perencanan proyek dimulai dengan menggabungkan masalah dan proses. Setiap fungsi
yang akan direkayasa oleh tim perangkat lunak harus melampaui sejumlah aktivitas kerangka
kerja yang sudah ditentukan bagi sebuah organisasi perangkat lunak.
Tim perangkat lunak harus memiliki tingkat fleksibilitas yang signifikan dalam memilih
paradigm rekayasa perangkat lunak yang paling baik bagi proyek dan tugas rekayasa perangkat
lunak.
17
4. Project
Para professional industry yang payah sering mengacu aturan 90-90 pada saat
mendiskusikan proyek-proyek perangkat lunak yang sukar : 90 persen dari sistem yang
pertama menyerap 90 persen dari usaha dan waktu yang diberikan. Yang 10 persen terakhir
mengambil 90 persen lain dari usaha dan waktu yang diberikan.
Proses manajemen proyek perangkat lunak dimulai dengan serangkaian aktivitas yang
secara kolektif disebut project planning. Yang pertama dari aktivitas ini adalah estimation
(perkiraan). Meskipun estimasi juga merupakan sebuah seni seperti juga pada sains, aktivitas
yang penting itu tidak perlu dilakukan dengan cara serampangan. Benar-benar ada teknik yang
berguna untuk mengestimasi waktu dan usaha. Karena estimasi menjadi dasar bagi semua
aktivitas perencanaan proyek yang lain, dan perencanaan proyek memberikan sebuah peta
jalan bagi suksesnya rekayasa perangkat lunak, maka tanpa estimasi kita tidak dapat berjalan
dengan baik.
B. SOFTWARE PROJECT PLANNING
1. Observation On Estimation
Estimasi sumber daya, biaya dan jadwal untuk usaha pengembangan perangkat lunak
membutuhkan pengalaman, mengakses informasi historis yang baik, dan keberanian untuk
melakukan pengukuran kuantitatif bila hanya data kualitatif saja yang ada. Estimasi membawa
resiko yang inheren dan resiko inilah yang membawa kepada ketidak pastian.
Kompleksitas proyek berpengaruh kuat terhadap ketidak pastian yang inheren dalam
perencanaan. Tetapi kompleksitas merupakan pengukuran relative yang dipengaruhi oleh
kebiasaan dengan usaha yang sudah dilakukan pada masa sebelumnya.
Ukuran proyek merupakan factor penting lain yang dapat mempengaruhi akurasi
estimasi. Bila ukuran bertambah maka ketergantungan diantara berbagai elemen perangkat
lunak akan meningkat dengan cepat. Dekomposisi masalah sebagai suatu pendekatan yang
sangat penting dalam proses estimasi menjadi lebih sulit lagi karena elemen-elemen yang akan
didekomposisi masih sangat berat.
Tingkat ketidak pastian structural juga berpengaruh dalam resiko estimasi. Resiko
diukur melalui tingkat ketidakpastian pada estimasi kuantitatif yang dibuat untuk sumber daya,
biaya dan jadwal. Bila ruang lingkup proyek tidak dipahami dengan baik atau syarat proyek
18
merupakan subjek terjadinya perubahan, maka resiko dan ketidakpastian menjadi sangat tinggi.
Perencana perangkat lunak harus melengkapi fungsi, kinerja, dan definisi interface.
Manejer proyek tidak perlu obsesif terhadap estimasi. Pendekatan-pendekatan rekayasa
perangkat lunak modern memakai pandangan pengembangan yang interaktif. Pada pendekatan
semacam ini dimungkinkan untuk melihat lagi estimasi dan merevisinya bila pelanggan
mengubah kebutuhannya.
2. Software Scope
Tujuan perencanaan proyek perangkat lunak adalah untuk menyediakan sebuah
kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat
dipertanggungjawabkan mengenai sumber daya, biaya dan jadwal. Estimasi dibuat dengan
sebuah kerangka waktu yang terbatas pada awal sebuah proyek perangkat lunak dan
seharusnya diperbaharui secara teratur selagi proyek sedang berjalan. Tujuan perencanaan
dicapai melalui suatu proses penemuan informasi yang menunjuk estimasi yang dapat
dipertanggungjawabkan. Aktivitas pertama dalam perencanaan proyek perangkat lunak adalah
penentuan ruang lingkup perangkat lunak. Ruang lingkup perangkat lunak menggambarkan
fungsi, kinerja, batasan, interface dan reliabilitas. Fungsi-fungsi yang digambarkan dalam ruang
lingkup dievaluasi dan dalam banyak kasus juga disaring untuk memberikan awalan yang lebih
detail pada saat estimasi dimulai.
Teknik yang banyak dipakai secara umum untuk menjembatani jurang komunikasi
antara pelanggan dan pengembang serta untuk memulai proses komunikasi adalah dengan
melakukan pertemuan atau wawancara pendahuluan. Perangkat lunak berinteraksi dengan
elemen sistem berbasis computer lainnya. Perencana mempertimbangkan sifat dan
kompleksitas masing-masing interface untuk menentukan pengaruhnya terhadap sumber daya,
biaya dan jadwal pengembangan.
3. Resource
Tugas selanjutnya dalam perencanaan proyek perangkat lunak adalah estimasi sumber
daya yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak tersebut.
Gambar 2.1 memperlihatkan sumber daya pengembangan sebagai sebuah pyramid.
19
Gambar 2.1 Sumber Daya Proyek
Gambar 2.1 memperlihatkan bahwa lingkungan pengembangan perangkat keras dan
perangkat lunak berada pada fondasi pyramid sumber daya dan menyediakan infrastruktur
untuk mendukung usaha pengembangan.
Dalam tingkat yang lebih tinggi kita menemukan komponen perangkat lunak reuseable.
Blok bangungan perangkat lunak yang dapat mengurangi biaya pengembangan secara dramatis
dan mempercepat penyampaian. Di puncak piramida terdapat sumber daya utama yaitu
manusia (people). Masing-masing sumber daya ditentukan dengan empat karakteristik.
Jumlah orang/manusia yang diperlukan untuk sebuah proyek perangkat lunak dapat
ditentukan hanya setelah sebuah estimasi usaha pengembangan dibuat. Teknik untuk usaha
estimasi didiskusikan pada bagian selanjutnya dari bab ini.
4. Software Project Estimation
Pada masa awal perhitungan biaya perangkat lunak terdiri dari presentase kecil biaya
sistem berbasis computer secara kesuluruhan. Urutan kesalahan besaran pada estimasi biaya
perangkat lunak memiliki pengaruh yang relative kecil. Sekarang perangkat lunak menjadi
elemen paling mahal di dalam sebagian besar sistem berbasis komputer.
Esimasi biaya dan usaha perangkat lunak tidak akan pernah menjadi ilmu pasti.
Variable yang terlalu banyak seperti manusia, teknik, lingkungan, politik dapat mempengaruhi
biaya dan usaha akhir yang diaplikasikan untuk mengembangkannya. Namun demikian estimasi
proyek perangkat lunak dapat ditransformasi dari suatu seni yang misterius ke dalam langkah-
langkah yang sistematis yang memberikan estimasi dengan resiko yang dapat diterima.
20
C. RISK ANALYSIS AND MANAGEMENT
Setelah hasil dari feasibility plan dipresentasikan, proyek dapat dilanjutkan sampai
dengan tahap penyelesaiannya. Yang dibutuhkan setelah presentasi feasibility plan adalah
menambah input (masukan) terhadap proyek. Hasil dari riset yang telah dilakukan mungkin
saja harus ditambahkan dengan masukan-masukan baru, sehingga hasil akhir yang diharapkan
dapat dicapai.
Tambahan masukan untuk proyek ini dapat dilakukan antara lain dengan cara:
1) Dari hasil presentasi dengan tim manajemen (feed-back input);
2) Lewat informasi proyek-proyek sejenis sebelumnya, melalui perpustakaan, Internet,
database IT vendors, laporan ilmiah, jurnal ilmiah, dsb;
3) Lewat wawancara dengan pemakai akhir dan/atau personal yang pernah menggunakan
produk sejenis, sponsor, dsb.
Contoh penambahan informasi untuk kelangsungan proyek ini dapat berupa antara lain:
1) Pertanyaan dari pihak management mengapa tidak menggunakan teknologi lain yang
lebih murah;
2) Harapan dari pihak pengguna bahwa program software yang akan dibuat mudah untuk
dimengerti juga oleh mereka yang tidak memiliki basis IT yang kuat;
3) Adanya data dari database perusahaan bahwa di proyek sebelumnya teknologi terpilih
ternyata memiliki kelemahan mendasar, seperti ketidakstabilan suatu program yang
ditulis dalam Java di dalam lingkungan windows.
Perlu diingat informasi tambahan ini hanya sebagai masukan dan harus dicari solusi
pemecahan bila memang menghambat jalannya proyek. Tidak diharapkan bahwa informasi
tambahan justru akan membuat proyek menjadi tersendat.
Yang tetap menjadi acuan harus tetap feasibility plan yang semula. Karena dari feasibility plan,
diharapkan:
1) Memenuhi keinginan pemberi order;
2) Dapat menggunakan teknologi yang sepadan dengan kriteria;
3) Dapat menyusun biaya dan rencana kerja lebih detail (dan mungkin lebih rendah dari
perkiraan semula);
Sebagai bahan untuk presentasi pada pihak manajemen dan pengguna (report dan
speech work) serta dapat dijadikan suatu kekuatan untuk negotiating position.
21
Adapun dalam manajemen risiko tujuan yang hendak dicapai adalah:
1) Identifikasi terhadap risiko;
2) Evaluasi (analisa) risiko dan (estimasi) pengaruhnya terhadap proyek;
3) Mengembangkan responsi terhadap risiko;
4) Mengontrol responsi risiko.
Identifikasi Proyek
Identifikasi risiko terdiri atas pengawasan dan penentuan risiko apa saja yang dapat
mempengaruhi proyek serta mendokumentasikan setiap dari risiko tersebut. Identifikasi tidak
hanya dilakukan sekali, namun harus dilakukan sepanjang perjalanan proyek dari awal sampai
akhir.
Faktor internal di dalam serta eksternal di luar proyek harus diidentifikasi. Faktor
internal antara lain penugasan anggota tim kerja, perhitungan biaya dan waktu, serta support
dan pengaruh dari tim manajemen. Faktor eksternal antara lain melibatkan kebijaksanaan
pemerintah, bencana alam, dan hal-hal lain di luar kontrol atau pengaruh tim proyek.
Identifikasi terhadap risiko harus melibatkan pengaruh baik maupun pengaruh buruk dari
pengaruh faktor-faktor penentu risiko.
Dari gambar di atas dapat dilihat input bagi identifikasi risiko adalah:
1) Diskripsi produk
Produk yang berbasis pada teknologi yang telah dibuktikan kebenarannya memiliki
risiko yang lebih kecil dibandingkan dengan produk yang menuntut inovasi dan
penemuan.
Input: Deskripsi
produk
Rencana proyek (WBS, biaya, staff, perekrutan)
Informasi
histori
Output: Sumber-
sumber risiko Potensi risiko
Tanda-tanda
risiko (trigger) Input ke
proses lainnya
Teknik: Checklist
Flowchart
Wawancara
22
2) Rencana proyek
a. Work breakdown structure: pendekatan pada deliverables setiap unit kerja secara
detail. Dengan cara ini identifikasi terhadap risiko bisa sampai ke level yang sangat
detail;
b. Estimasi biaya dan waktu: estimasi yang terlalu kasar dan terburu-buru dapat
meningkatkan risiko proyek.
c. Penempatan SDM: setiap pekerjaan yang spesifik dan hanya dapat dilakukan oleh
orang tertentu meningkatkan risiko proyek, apabila orang tersebut berhalangan
untuk hadir;
d. Perekrutan dan sub-kontraktor: pengaruh ekonomi dan kebijakan politik di sekitar
proyek dapat menyebabkan fluktuasi nilai kontrak proyek.
3) Informasi historis. hal-hal yang pernah terjadi di masa lalu, dan berkaitan dengan
proyek dapat dilihat dari:
a. File-file proyek sejenis dari perusahaan;
b. Database komersial, contohnya: Internet knowledge-bases;
c. Ilmu dan pengalaman dari tim kerja, dikenal juga dengan sebutan: tacit knowledge.
Untuk teknik yang digunakan dalam proses identifikasi risiko adalah:
1) Checklist: dari informasi (riset, dll) yang diperoleh dapat dibuat checklist yang mendata
sumber-sumber risiko;
2) Flowcharting: dapat digunakan untuk menggambarkan penyebab dan efek dari risiko
yang ada;
3) Wawancara: data-data yang tersimpan dari hasil wawancara proyek-proyek terdahulu
dapat digunakan sebagai referensi, dan juga masukan dari stakeholders merupakan
sumber informasi yang berpengaruh untuk mengidentifikasi risiko.
Adapun hasil output dari pengidentifikasian risiko adalah:
1) Daftar sumber-sumber risiko
a. Yang seringkali menjadi sumber risiko proyek antara lain: perubahan requirements,
kesalahan design, pendefinisian peran kerja yang lemah, kesalahan estimasi, dan
tim kerja yang kurang mapan.
b. Pada umumnya penjelasan mengenai sumber-sumber risiko ini disertai pula dengan:
perhitungan kemungkinan terjadinya risiko tersebut, kemungkinan akibat dari risiko
tersebut, kemungkinan kapan terjadinya, pengantisipasian tindakan terhadap risiko
tersebut.
23
2) Kejadian yang berpotensi menjadi risiko: biasanya merupakan kejadian-kejadian luar
biasa yang jarang terjadi.
a. Contohnya bencana alam, perkembangan teknologi baru yang tiba-tiba.
b. Tanda-tanda datangnya risiko (risk symptoms), sering juga disebut triggers, sebab-
sebab yang mengakibatkan munculnya bencana pada saat ini.
c. Contohnya biaya yang mengembang pada awal proyek disebabkan oleh estimasi
yang terburu-buru dan tidak akurat.
Input pada proses-proses lainnya: identifikasi risiko mungkin saja menyebabkan
diperlukannya pelaksanaan suatu aktivitas di area lain. Contohnya: bila identifikasi risiko
memperkirakan bahwa harga barang kebutuhan utama proyek akan naik, maka ada baiknya
pada penjadwalan, pembelian barang utama tersebut dilakukan di awal proyek.
Kuantifikasi risiko meliputi pengevaluasian serta interaksi antara risiko dan akibatnya. Input:
1) Toleransi dari stakeholders dan sponsor: setiap organisasi memiliki toleransi yang
berbeda-beda terhadap risiko. Ada yang hanya 10% dari modal, tapi ada juga yang
berani hingga 40% dari modal proyek, asalkan proyek selesai tepat waktu.
2) Sumber risiko (dibahas di atas);
3) Kejadian yang berpotensi menjadi risiko(dibahas di atas);
4) Estimasi waktu dan biaya (akan dibahas pada Manajemen waktu dan biaya);
Teknik:
1) Perkiraan nilai moneter: bagaimana efek sebuah risiko yang telah dievaluasi nilainya?
Mungkin ada yang risiko yang kemungkinannya kecil, tapi nilai risikonya dapat
membuat proyek berhenti. Ada pula risiko yang kemungkinannya besar, tetapi efeknya
kecil terhadap jalannya proyek.
2) Perhitungan statistik: menghitung jangkauan (range) perhitungan minimum dan
maksimum untuk biaya dan penjadwalan kerja proyek.
3) Simulasi model: dengan bantuan model yang disimulasikan dapat diketahui estimasi
yang lebih tepat, contoh: penggunaan model statistik Monte Carlo untuk menghitung
estimasi durasi proyek.
4) Decision trees: diagram yang memberikan alur kemungkinan dan interaksi antara
keputusan serta akibatnya.
5) Penilaian ahli: penilaian ahli dapat digunakan sebagai masukan tambahan setelah
penggunaan teknik-teknik di atas.
24
Output:
Setelah dianalisis, manajer proyek harus mampu memutuskan berbuat apa terhadap
risiko yang mungkin ada. Menerimanya, membuat rencana lanjutan atau mencari alternatif lain
yang tidak terpengaruh risiko.
D. SQA
Banyak pengembang perangkat lunak terus percaya bahwa kualitas perangkat lunak
merupakan sesuatu yang mulai dikhawatirkan setelah kode-kode dihasilkan.
1. Quality
American Heritage Dictionary mendefinisikan kata kualitas sebagai sebuah karakteristik
atau atribut dari sesuatu. Sebagai atribut dari sesuatu, kualitas mengacu pada karakteristik
yang dapat diukur, sesuatu yang dapat kita bandingkan dengan standar yang sudah diketahui,
seperti panjang, warna, sifat kelistrikan, kelunakannya dan sebagainya. Tetapi perangkat lunak,
yang sebagaian besar merupakan entitas intelektual lebih menantang untuk dikarakterisasi
daripada objek fisik.
Ada dua jenis kualitas yaitu kualitas desain dan kualitas konformasi. Kualitas desain
mengacu pada karakteristik yang ditentukan oleh desainer terhadap suatu item tertentu.
Kualitas konformansi adalah tingkat dimana spesifikasi desain terus diikuti selama
pembuatan. Dalam pengembangan perangkat lunak kualitas desain mencakup syarat,
spesifikasi, dan desain sistem. Kualitas konformansi adalah suatu masalah yang difokuskan
pada implementasi. Bila implementasi mengikuti desain dan sistem yang dihasilkan memenuhi
persyaratan serta tujuan kinerja, maka kualitas konformansi menjadi tinggi.
2. Quality Control
Kontrol kualitas merupakan serangkaian pemeriksaan, kajian dan pengujian yang
digunakan pada keseluruhan siklus pengembangan untuk memastikan bahwa setiap produk
memenuhi persyaratan yang ditetapkan. Kontrol kualitas mencakup perulangan (loop) umpan
balik pada proses yang menciptakan produk kerja.
Aktivitas kualitas kontrol dapat menjadi otomatis sepenuhnya, manual secara
kesuluruhan, atau kombinasi antara piranti otomatis dan interaksi manusia. Konsep kunci
kualitas kontrol adalah bahwa semua produk kerja memiliki spesifikasi yang telah ditentukan
dan dapat diukur di mana kita dapat membandingkan output dari setiap proses.
25
3. Quality Assurance Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen. Tujuan jaminan
kualitas adalah untuk memberikan data yang diperlukan oleh manajemen untuk
menginformasikan masalah kualitas produk, sehingga dapat memberikan kepastian dan
kepercayaan bahwa kualitas produk dapat memenuhi sasaran. Jika data yang diberikan melalui
jaminan kualitas mengidentifikasikan adanya masalah, maka adalah tanggung jawab
manajemen untuk menetapkan masalahnya dan mengaplikasikan sumber-sumber daya yang
dibutuhkan untuk memecahkan masalah kualitas tersebut.
4. Cost Of Quality
Biaya kualitas menyangkut semua biaya yang diadakan untuk mengejar kualitas atau
untuk menampilkan kualitas yang berhubungan dengan aktivitas. Studi tentang biaya kualitas
dilakukan untuk memberikan garis besar bagi biaya kualitas yang sedang digunakan untuk
mengidentifikasi kemungkinan pengurangan biaya kualitas serta memberikan basis
perbandingan yang ternormalisasi.
Biaya kegagalan adalah biaya yang akan hilang bila tidak ada cacat yang muncul
sebelum produk disampaikan kepada pelanggan. Biaya kegagalan dapat dibagi lagi ke dalam
biaya kegagalan internal dan eksternal. Biaya kegagalan internal adalah biaya yang diadakan
bila kita mendeteksi suatu kesalahan dalam produk sebelum produk dipasarkan.
EVALUASI
1) Sebutkan 5 kelompok manusia yang terlibat dalam proses pengembangan perangkat
lunak?
2) Bagaimanakah cara membatasi ruang lingkup proyek?
3) Apakah tujuan dari perencanaan proyek perangkat lunak?
4) Sebutkan dan jelaskan jenis kualitas yang melekat pada perangkat lunak?
26
BAB 3 METODE KONVENSIONAL UNTUK SOFTWARE ENGINEERING
A. SYSTEM ENGINEERING
Empat ratus dan lima ratus tahun yang lalu, Machiavelli pernah berkata, “Tidak ada
yang lebih sukar untuk dilakukan, lebih membahayakan untuk dilakukan atau lebih tidak pasti
dalam keberhasilannya, daripada memimpin di dalam pembukaan orde yang baru.” Selama
kuartal terakhir abad ke-20, sistem berbasis komputer telah memperkenalkan tatanan baru.
Meskipun teknologi telah membuat langkah benar sejak pernyataan Machiavelli, ungkapan
yang dikatakannya itu masih tetap bergema sampai sekarang.
Rekayasa perangkat lunak terjadi sebagai konsekuensi dari suatu proses yang disebut
rekayasa sistem. Daripada berkonsentrasi semata-mata pada perangkat lunak, rekayasa
sistem memfokuskan diri pada berbagai elemen, analisis, perancangan, dan pengorganisasian
elemen-elemen tersebut ke dalam suatu sistem yang dapat menjadi sebuah produk , jasa,
atau teknologi untuk mentransformasi informasi atau kontrol.
Proses rekayasa sistem disebut rekayasa informasi bila konteks kerja rekayasa
berfokus pada perusahaan bisnis. Pada saat produk akan dibuat, prose situ disebut rekayasa
produk.
Baik rekayasa informasi maupun rekayasa produk cenderung untuk membawa orde
kepada pengembangan sistem berbasis komputer. Meskipun masing-masing diterapkan di
dalam domain aplikasi yang berbeda, keduanya berusaha untuk meletakkan perangkat lunak
ke dalam konteks. Baik rekayasa informasi maupun rekayasa produk kerja untuk
mengalokasikan suatu peran bagi perangkat lunak ke elemen sistem berbasis komputer
lainnya.
1. Computer Based System
Tujuannya mungkin adalah untuk mendukung berbagai fungsi bisnis atau untuk
mengembangkan suatu produk yang dapat dijual untuk menghasilkan keuntungan bisnis. Untuk
mencapai tujuan tersebut, sistem berbasis komputer menggunakan berbagai elemen sistem:
1) Perangkat lunak.
27
Program computer, struktur data, dan dokumen yang berhubungan yang berfungsi
untuk mempengaruhi metode logis, prosedur, dan kontrol yang dibutuhkan.
2) Perangkat keras
Perangkat elektronik yang memberikan kemampuan penghitungan, dan perangkat
elektromekanik (misalnya, sensor, rotor, pompa) yang memberikan fungsi dunia
eksternal.
3) Manusia
Pemakai dan operator perangkat keras dan perangkat lunak.
4) Database
Kumpulan informasi yang besar dan terorganisasi yang diakses melalui perangkat
lunak.
5) Dokumentasi
Manual, formulir, dan informasi deskriptif lainnya yang menggambarkan
penggunaan dan atau pengoperasian sistem.
6) Prosedur
Langkah-langkah yang menentukan penggunaan khusus dari masing-masing
elemen sistem atau konteks prosedural di mana sistem berada.
Satu karakteristik sistem berbasis komputer yang rumit adalah bahwa elemen yang
berisi satu sistem juga dapat mewakili satu elemen makro dari suatu sistem yang sangat besar.
Elemen makro adalah suatu sistem berbasis komputer yang merupakan bagian dari sistem
berbasis komputer yang lebih besar lagi. Sebagai contoh, perhatikan”sistem otomasisasi pabrik”
yang pada dasarnya merupakan hirarki sistem yang diperlihatkan pada gambar 3.1. Pada
tingkat yang paling rendah dari hirarki tersebut, kita memiliki mesin kontrol numerik, robot, dan
perangkat pemasukan data. Masing-masing merupakan sistem berbasis komputer. Elemen-
elemen dari mesin kontrol numerik tersebut adalah perangkat keras elektronik dan
elektromekanik (misalnya, prosesor dan memori, motor, sensor); perangkat lunak (untuk
komunikasi, kontrol mesin, dan intrpolasi); manusia (operator mesin); database (program NC
yang disimpan); dan dokumentasi serta prosedur. Dekomposisi yang sama dapat juga
diterapkan untuk robot dan perangkat pemasukan data. Masing-masing merupakan sistem
berbasis komputer.
peman
(misaln
yang k
elemen
databa
mengg
dapat
generik
berbas
subbab
2. Sy
bawah
diilustr
view (
Tingkat se
nukfaturan m
nya, kompute
kita sebut mes
Singkatnya,
n-elemen sist
ase, prosedu
gunakan elem
diatur oleh
k eksklusif be
Peran reka
sis computer
b berikut kita
ystem Eng
Tanpa melih
(top-down)
asikan pada g
(WV), yaitu
Gam
lanjutnya pa
merupakan s
er, perlengka
sin kontrol nu
, sel pemanu
tem dengan
ur, dan do
men generik s
seorang ope
ersifat untuk s
ayasa sistem
tertentu dala
akan mengam
gineering
hat domain fo
dan dari ba
gambar 3.2.
di mana ke
mbar 3.1 Siste
ada hirarki,
siste berbasis
pan mekanis
umerik, robot
ukfaturan dan
label gener
kumentasi.
ecara bersam
erator tungga
satu sistem sa
adalah me
am konteks k
mati tugas-tu
g Hierarch
okusnya, reka
awah ke atas
Proses rekay
eseluruhan d
em Dari Banya
(Gambar 3.1
s komputer
s) dan juga m
dan perangka
n elemen ma
ik: perangka
Dalam bany
ma-sama. Mis
al (elemen m
aja.
embatasi ele
keseluruhan
gas yang me
hy
ayasa melingk
s (bottom-up
asa sistem bi
domain bisnis
ak Sistem
1) adalah se
yang mem
mengintegras
at pemasukan
akro masing-
t lunak, per
yak kasus,
alnya, robot
manusia). Da
men-elemen
hirarki sistem
rupakan reka
kupi sekumpu
p) untuk men
iasanya dimu
s atau dom
sel pemanukf
miliki elemenn
si elemen-ele
n data.
-masing terd
rangkat keras
elemen ma
dan mesin N
lam kasus la
tersebut un
m (elemen m
yasa sistem k
ulan metode
ngendalikan h
lai dengan se
ain produk
28
kfaturan. Sel
nya sendiri
emen makro
iri dari dari
s, manusia,
akro dapat
C keduanya
ain, elemen
ntuk sistem
akro). Pada
komputer.
dari atas ke
hirarki yang
ebuah world
diuji untuk
29
memastikan bahwa bisnis atau konteks teknologi yang tepat dapat dibangun. WV diperhalus
untuk lebih berfokus pada domain interes tertentu. Pada suatu domain tertentu, kebutuhan
untuk sistem yang ditargetkan (misalnya data, perangkat lunak, perangkat keras, manusia)
dianalisis. Akhirnya, analisis, desain, dan konstruksi dari elemen yang ditargetkan diinisiasi.
Pada puncak hirarki, suatu konteks yang luas dibangun, dan di bagian dasarnya aktivitas teknik
lengkap yang dilakukan oleh disiplin rekayasa yang relevan (misalnya, rekayasa perangkat
keras atau perangkat lunak) dilakukan.
Gambar 3.2 Hirarki Rekayasa Perangkat Lunak
Secara lebih resmi dapat dikatakan bahwa WV terdiri dari sejumlah domain (Di) yang
masing-masing dapat berupa sebuah system atau system dari system yang lebih besar.
WV = {D1 D2 D3 … Dn}
Masing-masing domain terdiri elemen-elemen tertentu (Ej) dimana masing-masing
berperan dalam mencapai sasaran dan tujuan dari domain:
Di = {E1,E2,E3, …., Em}
30
Akhirnya, masing-masing elemen diimplementasikan dengan mengkhususkan pada
komponen-komponen teknis (Ck) yang mencapai fungsi yang diperlukan untuk suatu elemen.
Ej = {C1, C2, C3, … Ck}
Dalam konteks perangkat lunak, komponen dapat berupa program computer, komponen
program reusable, modul, kelas atau objek, atau bahkan dapat berupa satu pernyataan bahasa
pemrograman.
Penting untuk dicatat bahwa perekayasa system mempersempit focus kerja ketika ia
bergerak ke bawah dalam hirarki tersebut. Tetapi WV menggambarkan definisi yang jelas
terhadap keseluruhan fungsionalitas yang memungkinkan perekayasa memahami domain, dan
akhirnya system atau produk, dalam konteks yang tepat.
B. REQUIREMENT ENGINEERING
Ketika otomasi bisnis diperkenalkan pertama kali pada awal tahun 1960-an, banyak
perusahaan yang kemudian mencari berbagai peluang dan mengotomasisasi fungsi-fungsi
bisnis yang sebelumnya dijalankan dengan cara manual. Seiring berjalannya waktu, program
komputer individu kemudian dikombinasikan untuk menangani banyak aplikasi bisnis. Aplikasi
tersebut dikelompokkan ke dalam sistem informasi mayor yang melayani area bisnis yang
spesifik. Aplikasi tersebut dapat berjalan, tetapi tetap menimbulkan masalah. Banyak sistem
sulit dihubungkan satu dengan lainnya; data redundan ada di mana-mana; pengaruh peubahan
terhadap aplikasi yang melayani satu daerah bisnis sulit diproyeksikan dan bahkan lebih sulit
untuk diimplementasikan; dan program-program lama menjadi tidak dapat dipakai lagi.tetapi
kurangnya sumber daya menyebabkan sistem digunakan dalam waktu yang sangat lama.
Tujuan global rekayasa informasi adalah untuk mengaplikasikan”teknologi informasi”
dengan cara tertentu yang melayani dengan paling baik kebutuhan bisnis secara keseluruhan.
Untuk melakukan hal tersebut, IE harus memulainya dengan menganaisis sasaran dan tujuan
bisnis, memahami area-area bisnis yang harus bekerja bersama-sama untuk mencapai sasaran
dan tujuan tersebut, dan kemudian harus menentukan kebutuhan informasi bagi masing-
masing area bisnis dan bisnis secara keseluruhan. Hanya setelah hal itu dilakukan, IE membuat
transisi ke dalam domain rekayasa perangkat lunak yang lebih teknis – proses di mana sistem
informasi, aplikasi, dan program dianalisis, didesain, dan dibangun.
31
1. Requirement Elicitation
Semua proyek dapat dikerjakan dengan mudah – dengan sumber daya dan waktu yang
tidak terbatas! Sayangnya, pengembangan sistem atau produk berbasis komputer lebih banyak
terganggu oleh kurangnya sumber daya dan tanggal penyampaian yang sulit (bila tidak benar-
benar tidak realistis). Memang perlu dan bijaksana untuk melakukan evaluasi terhadap
feasibilitas sebuah proyek pada saat paling awal yang mungkin. Bulan atau tahun kerja, ribuan
atau jutaan dolar, dan keadaan melakukan tidak terkatakan dapat terhindar bila sebuah sistem
yang sakit dikenali sejak awal, ketika masih dalam fase definisi.
1) Feasibilitas ekonomis.
Evaluasi biaya pengembangan dibobot dengan pemasukan utama atau keuntungan
yang didapat dari sistem atau produk yang dikembangkan.
2) Feasibilitas teknis.
Studi mengenai fungsi, kinerja, dan batasan yang dapat mempengaruhi
kemampuan untuk mencapai sebuah sistem yang dapat diterima.
3) Feasibilitas legal.
Pertimbangan mengenai pelanggaran, kekasaran,atau liabilitas yang dihasilkan dari
pengembangan sistem.
4) Alterntif.
Evaluasi mengenai pendekatan alternatif pada pengembangan sistem atau produk.
5) Studi feasibilita
Tidak dijamin untuk sistem di mana pembenaran ekonomisnya jelas, risiko
teknisnya rendah, hanya memiliki sedikit masalah legal, dan tidak ada alternatif
yang tidak dipertanggungjawabkan. Tetapi, bila beberapa dari kondisi itu gagal,
maka studi mengenai area tersebut dapat dilakukan.
Justifikasi ekonomi biasanya merupakan pertimbangan bottom-line untuk sebagian
besar sistem (kecuali kadang-kadang mencakup sistem pertahanan seperti program ruang
angkasa). Pembenaran ekonomis menyangkut rentang yang luas dari pertimbangan yang
meliputi analisis biaya-keuntungan, stratgi pemasukan yang berhubungan dengan hokum dalam
jangka panjang, pengaruhnya pada pusat keuntungan atau produk yang lain, iaya sumber daya
yang dibutuhkan untuk pengembangan, dan pertumbuhan pasar potensial.
Feasibilitas teknis sering menjadi area yang paling sulit untuk ditaksir pada tingkat
proses rekayasa produk. Karena sasaran, fungsi, dan kinerja agak tidak penting bahwa proses
analisis dan definisi dilakukan secara paralel dengan sebuah penilaian feasibilitas teknis.
Dengan cara inilah spesifikasi yang konkrit dapat diputuskan pada saat ditentukan.
32
2. Analisis Area Bisnis
Analisis Area Bisnis membentuk suatu kerangka kerja lengkap untuk membangun
perusahaan yang berbasis informasi. Analisis area bisnis menggunakan suatu area bisnis pada
suatu waktu dan menganalisisnya secara detail. Analisis area bisnis menggunakan diagram dan
matriks untuk memodelkan dan merekam data dan aktivitas pada perusahaan dan memberikan
pemahaman yang jelas terhadap cara yang teliti dan cerdik di masa aspek informasi dari
perusahaan saling berhubungan.
3. Requirement Spesification
Spesifikasi Sistem adalah dokumen yang berfungsi sebagai dasar bagi rekayasa
perangkat keras, rekayasa perangkat lunak, rekayasa database, dan rekayasa manusia.
Spesifikasi sistem menggambarkan fungsi dan kinerja dari sebuah sistem berbasis computer
serta batasan yang mengatur pengembangannya. Spesifikasi tersebut membatasi masing-
masing elemen sistem yang teralokasi.
4. System Modelling
Sebagai bagian dari persyaratan sistem dan kegiatan perancangan, sistem harus
dimodelkan sebagai suatu kumpulan komponen dan hubungan antara komponen-komponen ini.
Ini biasanya diilustrasikan secara grafis pada model arsitektur sistem yang memberikan
pandangan kepada pembaca mengenai organisasi sistem.
Arsitektur sistem biasanya digambarkan sebagai diagram blok yang menunjukkan
subsistem direpresentasikan sebagai persegi empat pada diagram blok dan adanya hubungan
antara mereka ditunjukkan dengan tanda panah yang menghubungkan persegi empat ini.
Hubungan yang digambarkan bisa mencakup aliran data, hubungan menggunakan/digunakan
atau jenis hubungan ketergantungan lain.
Arsitektur sistem harus dirancang dalam bentuk subsistem fungsional tanpa
mempedulikan apakah sub sistem tersebut merupakan perangkat keras atau perangkat lunak.
Komponen fungsional pada sistem dapat diklasifikasikan dengan berbagai nama:
1) Komponen sensor
2) Komponen actuator
3) Komponen komputasi
4) Komponen komunikasi
5) Komponen koordinasi
6) Komponen iterface
33
5. Requirement Validation
Validasi perysaratan berkenaan dengan pengidentifikasian bahwa persyaratan benar-
benar mendefinisikan sistem yang diinginkan pelanggan. Kegiatan ini memiliki banyak
kesamaan dengan analisis karena hubungan dengan penemuan masalah dengan persyaratan.
Namun demikian, keduanya merupakan proses yang berbeda karena validasi harus
berhubungan dengan naskah dokumen persyaratan yang lengkap, sementara analisis
melibatkan pekerjaan dengan persyaratan yang tidak lengkap.
Validasi persyaratan penting karena error pada dokumen persyaratan dapat
menimbulkan biaya pengerjaan ulang jika ditemukan pada saat pengembangan atau setelah
sistem dipakai. Biaya melakukan perubahan sistem yang merupakan akibat dari masalah
persyaratan lebih besar dari perbaikan desasin atau kesalahan pengkodean. Alasan untuk hal ini
adalah karena perubahan persyaratan biasanya mengharuskan perubahan desain sistem dan
implementasinya, beserta pengujian ulang sistem.
Pada saat proses validasi persyaratan tipe pemeriksaan yang berbeda harus diterapkan
pada persyaratan-persyaratan di dokumen persyaratan. Pemeriksaan ini meliputi:
1) Pemeriksaan validitas.
Seorang user mungkin berpikir bahwa sistem diperlukan untuk melakukan fungsi-
fungsi tertentu. Namun demikian pemikiran dan analisis lebih lanjut dapat
mengidentifikasi fungsi tambahan atau fungsi berbeda yang diinginkan. Sistem
yang memiliki berbagai user dengan kebutuhan yang berbeda dengan persyaratan
apapun pada akhirnya akan merupakan suatu kompromi dari komunitas user.
2) Pemeriksaan Konsistensi
Persyaratan pada dokumen seharusnya tidak bertentangan. Artinya seharusnya
ada batasan-batasan yang saling bertentangan atau deskripsi yang berbeda dari
fungsi sistem yang sama.
3) Pemeriksaan Kelengkapan
Dokumen persyaratan harus mencakup persyaratan yang mendefinisikan semua
fungsi dan batasan yang dimaksud oleh user sistem.
4) Pemeriksaan realisme
Dengan menggunakan pengetahuan mengenai teknologi yang ada, persyaratan
harus diperiksa untuk menjamin persyaratan dapat diimplementasi. Pemeriksaan
ini harus memperhitungkan anggaran dan jadwal pengembangan sistem.
34
5) Kemampuan dapat diverifikasi
Untuk mengurangi potensi pertentangan antara pelanggan dan kontraktor,
persyaratan sistem harus selalu dituliskan sedemikian rupa sehingga dapat
diverifikasi. Ini berarti bahwa serangkaian pemeriksaan dapat dirancang untuk
mendemonstrasikan bahwa sistem yang diserahkan memenuhi persyaratan
tersebut.
6. Requirement Management
Persyaratan untuk sistem perangkat lunak besar selalu berubah. Satu alasan untuk hal
ini adalah karena sistem-sistem ini biasanya dikembangkan untuk mengatasi masalah. Karena
masalah tidak dapat didefinisikan sepenuhnya, persyaratan perangkat lunak cenderung tidak
lengkap. Pada saat proses perangkat lunak, pemahaman pengembang akan masalah berubah-
ubah dan perubahan ini diumpan balikkan pada persyaratan.
Sistem besar biasanya memiliki komunitas user yang beragam. User yang berbeda-
beda mempunyai persyaratan dan prioritas yang berbeda pula. Hal-hal ini bias menimbulkan
konflik atau kontradiksi.
Manajemen persyaratan adalah proses pemahaman dan pengendalian perubahan pada
persyaratan sistem. Proses manajemen persyaratan dilakukan bersama dengan proses rekayasa
persyaratan yang lainnya. Perencanaan dimulai pada saat yang sama dengan elisitasi
persyaratan awal dan manajemen persyaratan aktif harus dimulai segera setelah versi naskah
dokumen persyaratan tersedia.
Dari sudut pandang evolusi persyaratan terbagi menjadi dua kelas:
1) Persyaratan yang bertahan.
Ini merupakan persyaratan yang relative stabil, yang berasal dari kegiatan inti
organisasi dan berhubungan langsung dengan domain sistem.
2) Persyaratan yang berubah-ubah.
Ini merupakan persyaratan yang mungkin berubah pada saat pengembangan
sistem, atau setelah sistem dipakai.
EVALUASI
1) Sebutkan dan jelaskan elemen sistem berbasis komputer!
2) Apakah fungsi dari studi kelayakan!
3) Apakah yang dimaksud dengan manajemen persyaratan?
35
BAB 4 ANALISIS
A. KONSEP DAN PRINSIP ANALISIS
Pemahaman lengkap mengenai persyaratan perangkat lunak sangat penting bagi
keberhasilan usaha pengembangan perangkat lunak. Tidak peduli bagaimana perangkat lunak
dirancang atau dikodekan, program yang dianalisis dan ditentukan secara tidak baik akan
mengecewakan pemakaiannya dan akan membawa kegagalan bagi pengembangnya.
Tugas analisis persyaratan merupakan sebuah proses penemuan, perbaikan,
pemodelan dan spesifikasi. Ruang lingkup perangkat lunak yang secara mendasar
dikembangkan oleh perekayasa system dan diperbaiki selama perencanaan proyek perangkat
lunak diperbaiki secara detail. Model-model data yang dibutuhkan, aliran kontrol dan informasi,
dan tingkah laku operasional diciptakan.
Kebutuhan perangkat lunak adalah kondisi, kriteria, syarat atau kemampuan yang
harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan
pemakai. Bab ini berisi mengenai segala sesuatu yang dibutuhkkan untuk dapat melakukan
analisa kebutuhan perangkat lunak.
Menurut Kamus Webster seperti dikutip oleh Davis [DAV93], kebutuhan adalah sesuatu
yang disyaratkan; sesuatu yang diinginkan atau diperlukan. Sedangkan menurut IEEE [IEE93]
kebutuhan adalah:
1) Kondisi atau kemampuan yang diperlukan pemakai untuk menyelesaikan suatu
persoalan, atau untuk mencapai tujuan.
2) Kondisi atau kemampuan yang harus dimiliki atau dipunyai oleh sistem atau
komponen sistem untuk memenuhi kontrak, standar, spesifikasi, atau dokumen
formal lainnya.
Dengan mengadopsi pengertian-pengertian di atas, dapat disimpulkan bahwa
kebutuhan perangkat lunak adalah kondisi, kriteria, syarat atau kemampuan yang harus dimiliki
oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan pemakai.
36
Secara kategoris, ada tiga buah jenis kebutuhan perangkat lunak [IEE93] : 1) Kebutuhan fungsional (functional requirement)
Disebut juga kebutuhan operasional, yaitu kebutuhan yang berkaitan dengan
fungsi atau proses transformasi yang harus mampu dikerjakan oleh perangkat
lunak. Sebagai contoh:
a. Perangkat lunak harus dapat menyimpan semua rincian data pesanan
pelanggan.
b. Perangkat lunak harus dapat membuat laporan penjualan sesuai dengan
periode waktu tertentu.
c. Perangkat lunak harus mampu menyajikan informasi jalur pengiriman barang
terpendek.
2) Kebutuhan antarmuka (interface requirement)
Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen
perangkat keras, perangkat lunak, atau basis data. Sebagai contoh:
a. Perangkat untuk memasukkan data dapat berupa keyboard, mouse atau
scanner.
b. Akses ke basisdata menggunakan ODBC (Open Database Connectivity).
3) Kebutuhan unjuk kerja (performance requirement)
Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh
perangkat lunak, misalnya: kecepatan, ketepatan, frekuensi. Sebagai contoh:
a. Perangkat lunak harus bisa mengolah data sampai 1 juta record untuk tiap
transaksi.
b. Perangkat lunak harus dapat digunakan otoritas yang diberikan pada user.
c. Waktu tanggap penyajian informasi maksimal selama satu menit.
1. Analisis Kebutuhan
Analisis kebutuhan perangkat lunak (software requirements analysis) merupakan
aktivitas awal dari siklus hidup pengembangan perangkat lunak. Untuk proyek-proyek
perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah tahap rekayasa
sistem/informasi dan software project planning.
Analisis persyaratan adalah sebuah tugas rekayasa perangkat lunak yang menjembatani
jurang antara alokasi perangkat lunak tingkat sistem dan perancangan perangkat lunak seperti
dilihat pada gambar 6.1.
37
Gambar 4.1 Analisis dan Kesenjangan antara rekayasa sistem dan desain perangkat lunak
Analisis persyaratan memungkinkan perekayasa sistem menentukan fungsi dan kinerja
perangkat lunak, menunjukkan interface perangkat lunak dengan elemen-elemen sistem.
Pendefinisian kebutuhan merupakan aktivitas yang sangat penting, karena sangat
mempengaruhi sukses atau gagalnya pelaksanaan pengembangan perangkat lunak. Menurut
hasil survey DeMarco, 56% kegagalan proyek pengembangan perangkat lunak dikarenakan
ketidaklengkapan pendefinisian kebutuhan dari perangkat lunak tersebut. Perhatikan gambar
dampak kesalahan kumulatif akibat kesalahan dalam pendefinisian kebutuhan pada Gambar
4.2.
38
Gambar 4.2 Dampak Kesalahan Kumulatif
Dari gambar terlihat bahwa produk perangkat lunak yang tidak sempurna akan
dihasilkan karena kesalahan pada saat menentukan spesifikasi kebutuhan. Jika kesalahan
tersebut diketahui di akhir siklus hidup pengembangan, usaha untuk memperbaikinya akan
sangat mahal.
Selain itu, kesalahan penentuan kebutuhan akan memberikan dampak [DAV93]: a. Perangkat lunak yang dihasilkan tidak akan memenuhi kebutuhan pemakai yang
sebenarnya.
b. Interpretasi kebutuhan yang berbeda-beda sehingga dapat menyebabkan
ketidaksepakatan antara pelanggan dan pengembang, menyia-nyiakan waktu dan
biaya, dan mungkin akan menghasilkan perkara hukum.
39
c. Pengujian kesesuaian perangkat lunak dengan kebutuhan yang dimaksud tidak akan
mungkin dilaksanakan dengan sesungguhnya.
d. Waktu dan biaya akan terbuang percuma untuk membangun sistem yang salah.
2. Prinsip-Prinsip Analisis
Setiap metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis
dihubungkan oleh serangkaian prinsip operasional yang dapat dijabarkan sebagai berikut:
1) Dominan informasi dari suatu masalah harus direpresentasikan dan dipahami.
2) Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
3) Tingkah laku perangkat lunak harus diwakilkan.
4) Model-model yang menggambarkan informasi, fungsi dan tingkah laku harus
dipecah-pecah dalam suatu cara yang membongkar suatu detail dalam bentuk
lapisan (hirarki).
5) Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
Dengan mengaplikasikan prinsip-prinsip tersebut, analis mendekati suatu masalah
secara sistematis. Tujuan pelaksanaan analisis kebutuhan adalah:
1) Memahami masalah secara menyeluruh (komprehensif) yang ada pada perangkat
lunak yang akan dikembang seperti ruang lingkup produk perangkat lunak(product
space) dan pemakai yang akan menggunakannya.
2) Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk memenuhi
keinginan pelanggan.
Secara teknis pelaksanaan pekerjaan analisis kebutuhan perangkat lunak pada
dasarnya terdiri dari urutan aktivitas:
1) Mempelajari dan memahami persoalan
Pada tahap ini, seorang analis mempelajari masalah yang ada pada perangkat
lunak yang dikembangkan, sehingga dapat ditentukan.
a. Siapa pemakai yang menggunakan perangkat lunak.
b. Dimana perangkat lunak akan digunakan
c. Pekerjaan apa saja dari pemakai yang akan dibantu oleh perangkat lunak.
d. Apa saja cakupan dari pekerjaan tersebut, dan bagaimana mekanisme
pelaksanaannya.
e. Apa yang menjadi kendala dilihat dari sisi teknologi yang digunakan atau dari
sisi hukum dan standar.
40
Cara yang digunakan oleh pengembang khususnya analis dalam memahami
masalah perangkat lunak biasanya dilakukan
a. Wawancara dengan pemakai
b. Observasi atau pengamatan lapangan
c. Kuesioner
d. Mempelajari referensi atau dokumen-dokumen yang digunakan, seperti
dokumen hasil analisa dan perancangan perangkat lunak.
Hasil dari pemahaman masalah tersebut dapat digambarkan dengan model-model
tertentu sesuai dengan jenis permasalahannya. Sebagai contoh jika masalah bisnis
dapat digambarkan dengan flowmap atau bussiness use case untuk analisa
berorientasi objek. Sedangkan untuk masalah matematika dapat digambarkan
dengan graf.
2) Mengindentifikasi Kebutuhan Pemakai
Pada tahap identifikasi kebutuhan pemakai (user requirement) in pada prakteknya
menjadi satu pelaksanaannya dengan pemahaman masalah. Hanya saja substansi
yang ditanyakan ada sedikit perbedaan, yaitu:
a. Fungsi apa yang diinginkan pada perangkat lunak.
b. Data atau informasi apa saja yang akan diproses.
c. Kelakuan sistem apa yang diharapkan.
d. Antarmuka apa yang tersedia (software interfaces, hardware interfaces, user
interfaces, dan communication interfaces)
Untuk menangkap kebutuhan dari pemakai dengan baik,terutama kesamaan
persepsi. seorang analis membutuhkan:
a. Komunikasi dan brainstorming yang intensif dengan pelanggan.
b. Pembuatan prototype perangkat lunak atau screenshoot.
c. Data atau dokumen yang lengkap.
3) Mendefinisikan kebutuhan perangkat lunak
Saat melakukan pengidentifikasian kebutuhan pemakai, informasi yang diperoleh
masih belum terstruktur. Biasanya pemakai akan mengungkapkan apa yang
diinginkan dengan bahasa sehari-hari yang biasa mereka gunakan. Sebagi contoh,
ungkapan kebutuhan pemakai dibagian akutansi.
a. Saya ingin data yang dimasukkan oleh bagian penjualan bisa langsung
dijurnal.
b. Informasi neraca keuangan bisa saya lihat kapan saja.
41
Kemudian pada tahap ini, kebutuhan pemakai yang belum terstruktur tersebut
akan akan dianalisis, diklasifikasikan, dan diterjemahkan menjadi kebutuhan
fungsional, antarmuka dan unjuk kerja perangkat lunak. Sebagai contoh,
kebutuhan “data yang dimasukkan oleh bagian penjualan bisa langsung dijurnal”
setelah dianalisis, diklasifikasikan dan diterjemahkan, mungki akan menghasilkan
pendefinisian kebutuhan sebagai berikut.
a. Kebutuhan fungsional
a) Entri dan rekam data transaksi penjualan.
b) Retrieve data transaksi penjualan untuk periode tertentu (periode sesuai
dengan inputan periode yang diinputkan pada keyboard).
c) Rekam data akumulasi transaksi penjualan periode tertentu ke jurnal
umum berikut account pasangannya (kas).
b. Kebutuhan antarmuka
a) Antarmuka pemakai untuk memasukkan dan merekam data penjualan.
b) Antarmuka pemakai untuk menyajikan dan menjurnal informasi transaksi
penjualan pada periode tertentu.
c) Antarmuka untuk jaringan lokal yang menghubungkan perangkat lunak
aplikasi dibagian penjualan dengan perangkat lunak aplikasi dibagian
akutansi.
c. Kebutuhan unjuk kerja
a) Proses jurnal hanya bisa dilakukan sekali setelah data transaksi penjualan
direkam.
b) Adanya otoritas pemakaian perangkat lunak dan akses data sesuai
dengan bagian pekerjaan masing-masing.
Kemudian kebutuhan tersebut akan dimodelkan atau digambarkan dengan teknik
analisis dan alat bantu tertentu. Sebagai contoh kebutuhan fungsional dapat
dimodelkan dengan menggunakan
a) Data flow diagram,kamus data,dan spesifikasi proses jika menggunakan
anlisis tertsruktur.
b) Use case diagram dan skenario sistem jika menggunkan analisis berorientasi
objek.
42
4) Membuat dokumen spesifikasi kebutuhan perangkat lunak (SKPL)
Semua kebutuhan yang telah didefinisikan selanjutnya dibuat dokumentasinya
yaitu Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirement
Specification (SRS). Dokumen ini dibuat untuk menyatakan secara lengkap apa
yang dapat dilakukan oleh perangkat lunal, termasuk deskripsi lengkap semua
antarmuka yang akan digunakan.
5) Mengkaji ulang (review) kebutuhan
Proses untuk mengkaji ulang (validasi) kebutuhan apakah SKPL sudah konsisten,
lengkap, dan sesuai dengan yang diinginkan oleh pemakai. Proses ini bisa
dilakukan lebih dari satu kali. Dan sering kali akan muncul kebuthan-kebutuhan
baru dari pemakai. Oleh karena itu, diperlukannya negosiasi antara pengembang
dengan pelanggan sesuai dengan prinsip “win win solution” sampai kebutuhan
tersebut disetujui oleh kedua belah pihak.
Sedangkan menurut (Pressman, 2002), analisis kebutuhan perangkat lunak dapat
dibagi menjadi lima area pekerjaan, yaitu:
a. Pengenalan masalah
b. Evaluasi dan sistesis
c. Pemodelan
d. Spesifikasi
e. Tinjau Ulang (Review)
3. Prototipe Software
Paradigma prototyping dapat terbatas atau tidak terbatas. Pendekatan terbatas sering
disebut throwaway prototyping. Dengan menggunakan pendekatan tersebut prototype
merupakan sebuah demonstrasi kasar dari persyaratan. Kemudian prototype dikesampingkan,
dan perangkat lunak direkayasa dengan menggunakan suatu paradigm yang berbeda.
B. MODEL ANALISIS
Metode atau teknik untuk melakukan analisis kebutuhan perangkat lunak dapat
dikelompokkan berdasarkan pendekatan yang diambil pada saat melakukan aktivitas tersebut.
43
1. Data Flow Oriented atau Functional Oriented
Sudut pandang analisis pada pendekatan ini difokuskan pada aspek fungsional dan
behavioral (perilaku laku) sistem. Pengembang harus mengetahui fungsi-fungsi atau proses-
proses apa saja yang ada dalam sistem, data apa yang menjadi masukannya, dimana data
tersebut disimpan, transformasi apa yang akan dilakukan terhadap data tersebut, dan apa yang
menjadi hasil transformasinya. Selain itu, pengembang harus mengetahui keadaan (state),
perubahan (transition), kondisi (condition), dan aksi (action) dari sistem.
Salah satu metode yang paling populer untuk pendekatan ini adalah Analisis Terstruktur
(Structured Analysis) yang dikembangkan oleh (DeMarco,1976), Chris Gane dan Trish Sarson,
dan Edwad Yourdon (Yourdon, 1989). Pada metode ini, hasil analisis dan perancangan
dimodelkan dengan menggunakan beberapa perangkat pemodelan seperti:
a) Data Flow Diagram (DFD) dan Kamus Data (data dictionary) untuk
menggambarkan fungsi-fungsi dari sistem (system functions).
b) Entity-Relationship Diagram (ERD) untuk menggambarkan data yang disimpan
(data stored).
c) State Transition Diagram (STD) untuk menggambarkan perilaku sistem.
d) Structure Chart untuk menggambarkan struktur program.
2. Data Structured Oriented
Analisis dengan pendekatan ini difokuskan pada struktur data, dimana struktur tersebut
dapat dinyatakan secara hirarki dengan menggunakan konstruksi sequence, selection dan
repetition. Beberapa metode berorientasi struktur data ini diantaranya adalah:
a. Data Structured System Development (DSSD)
Diperkenalkan pertama kali oleh J.D. Warnier [1974] dan kemudian oleh Ken Orr
[1977], sehingga sering disebut juga metode Warnier-Orr. Metode ini
menggunakan perangkat entity diagram, assembly line diagram dan Warnier-Orr
diagram untuk memodelkan hasil analisis dan perancangannya.
b. Jackson System Development (JSD)
Dikembangkan oleh M.A. Jackson [1975] dengan menggunakan perangkat
pemodelan yang disebut structure diagram dan system specification diagram.
44
3. Object Oriented
Berbeda dengan pendekatan-pendekatan sebelumnya, pendekatan berorientasi objek
memandang sistem yang akan dikembangkan sebagai suatu kumpulan objek yang
berkorespondensi dengan objek-objek dunia nyata. Pada pendekatan ini, informasi dan proses
yang dipunyai oleh suatu objek “dienkapsulasi” (dibungkus) dalam satu kesatuan. Beberapa
metode pengembangan sistem yang berorientasi objek ini diantaranya adalah:
a) Object Oriented Analysis (OOA) dan Object Oriented Design (OOD) dari Peter Coad
dan Edward Yourdon (1990).
b) Object Modeling Technique (OMT) dari James Rumbaugh (1987).
c) Object Oriented Software Engineering (OOSE).
C. ANALISIS TERSTRUKTUR
Analisis Terstruktur (Structured Analysis) merupakan salah satu teknik analisis yang
mengunakan pendekatan berorientasi fungsi. Teknik ini mempunyai sekumpulan petunjuk dan
perangkat komunikasi grafis yang memungkinkan analis sistem mendefinisikan spesifikasi
fungsional perangkat lunak secara terstruktur. Pada metode ini, semua fungsi sistem
direpresentasikan sebagai sebuah proses transformasi informasi, dan disusun secara hirarkis
sesuai tingkat abstraksinya (sistem maupun perangkat lunak) yang hasilnya ditujukan untuk
entitas-entitas eksternal.
Analisis Terstruktur pertama kali diperkenalkan oleh Tom DeMarco sekitar tahun 1978
[DEM79]. Prinsip dari teknik ini adalah dekomposisi fungsi dari sistem berdasarkan aliran data
dan proses-prosesnya untuk mendapatkan produk analisis yang dapat diubah dan diperbaiki
secara mudah (highly maintainable). Dalam bukunya itu, DeMarco mendefinisikan Analisis
Terstruktur sebagai teknik untuk mendeskripsikan spesifikasi sistem baru melalui Data Flow
Diagrams, Data Dictionary, Structured English, dan Data Structure Diagrams. Spesifikasi sistem
tersebut dinyatakan dalam suatu dokumen yang disebut Spesifikasi Terstuktur (Structured
Specification).
Dalam perkembangannya, teknik Analisis Terstruktur mengalami perubahan,
penambahan, dan penyempurnaan, baik untuk perangkat pemodelannya maupun mekanisme
atau cara pelaksanaannya. Salah satunya oleh Edward Yourdon [YOU89] yang memperkenalkan
pendekatan baru dari Analisis Terstruktur, yaitu Analisis Terstruktur Modern (Modern Structures
Analysis).
45
1. Perangkat Pemodelan Terstruktur
Perangkat Pemodelan Analisis Terstruktur adalah alat bantu pemodelan yang
digunakan untuk menggambarkan hasil pelaksanaan Analisis Terstruktur. Perangkat Analisis
Terstruktur yang disampaikan oleh DeMarco [DEM78] adalah:
a) Diagram Aliran Data atau Data Flow Diagram (DFD)
b) Kamus Data atau Data Dictionary
c) Structured English
d) Tabel Keputusan atau Decision Table
e) Pohon Keputusan atau Decision Tree
Kelima perangkat tersebut oleh Yourdon [YOU89] dilengkapi dengan:
a) Diagram Entitas-Relasi atau Entity-Relationship Diagram (ERD)
b) Diagram Transisi Keadaan atau State Transition Diagram (STD)
Dan sebagai pengembangan untuk menggambarkan sistem waktu nyata, disertakan
Diagram Aliran Kendali atau Control Flow Diagram (CFD). Berikut adalah penjelasan rinci untuk
masing-masing perangkat, khususnya untuk DFD, Kamus Data, dan Structured English.
2. Spesifikasi Proses
Digunakan untuk menggambarkan deskripsi dan spesifikasi dari setiap proses yang
paling rendah (proses atomik) yang ada pada sistem dengan menggunakan notasi yang disebut
Structured English atau pseudo-code. Penulisannya cukup sederhana sehingga dapat digunakan
sebagai media untuk mengkomunikasikan proses yang dilakukan sistem kepada pemakai.
Seperti halnya notasi-notasi yang lain, ada cukup banyak variasi penulisan spesifikasi
proses dengan Structured English ini. Pada buku ini akan digunakan notasi penulisan yang
menggunakan kata-kata bahasa Indonesia, kecuali untuk kata-kata yang sering digunakan
dalam penulisan program, misalnya Read, Write, If, While, atau Repeat.
Ada tiga struktur dasar yang dapat digunakan untuk menyusun spesifikasi proses, yaitu
struktur sekuensi, pemilihan dan pengulangan. Berikut adalah contoh penulisan spesifikasi
proses untuk proses pembuatan laporan penjualan.
Nomor : 3.0
Nama Proses : Buat laporan penjualan
Jenis : Pembuatan laporan
46
Masukan : File Barang, file Jual dan periode transaksi
Keluaran : Laporan penjualan
Deskripsi :
Begin
Buka file BARANG dan file JUAL
Baca data periode tanggal transaksi
Saring (filter) data pada file JUAL sesuai periode tanggal transaksi
Cetak Laporan Penjualan
Tutup file BARANG dan file JUAL.
End
atau secara lebih ringkas:
Proses 3.0 Buat Laporan Penjualan
Begin
Buka file BARANG dan file JUAL
Baca data periode tanggal transaksi
Saring (filter) data pada file JUAL sesuai periode tanggal transaksi
Cetak Laporan Penjualan
Tutup file BARANG dan file JUAL.
End
D. KAMUS DATA
Merupakan suatu tempat penyimpanan (gudang) dari data dan informasi yang
dibutuhkan oleh suatu sistem informasi. Kamus data digunakan untuk mendeskripsikan rincian
dari aliran data atau informasi yang mengalir dalam sistem, elemen-elemen data, file maupun
basis data (tempat penyimpanan) dalam DFD.
Ada aturan (konvensi) penulisannya dengan menggunakan notasi atau simbol tertentu
sebagai berikut:
= sama dengan atau terdiri dari atau terbentuk dari
+ dan
[] pilih salah satu
{} iterasi atau pengulangan
() pilihan (option)
* komentar
| pemisah
47
Saat ini ada banyak variasi penulisan kamus data, yang secara umum dibedakan
menjadi bentuk lengkap (long form) dan bentuk ringkas (short form). Sebagai contoh dibawah
ini bentuk kamus data yang lengkap (long form):
Id. Barang = Kode_Brg + Nama_Brg + Satuan + Hrg_Beli + Hrg_Jual + Banyak
Kode_Brg = 1{character}6
Nama_Brg = 1{character}20
Satuan = 1{character}3
Hrg_Beli = 3{numeric}10
Hrg_Jual = 3{numeric}10
Banyak = 1{numeric}6
character = [A-Z|a-z|0-9|-| |]
numeric = [0-9]
Artinya:
a) Identitas Barang tersusun dari atribut Kode_Brg dan Nama_Brg dan Satuan dan
Hrg_Beli dan Hrg_Jual dan Banyak.
b) Kode_Brg tersusun dari minimal 4 karakter dan maksimal 6 karakter.
c) Nama_Brg tersusun dari minimal 8 karakter dan maksimal 20 karakter.
d) Satuan tersusun dari 3 karakter.
e) Hrg_Jual tersusun dari minimal 3 dijit numerik dan maksimal 10 dijit numeric
f) Jml_Stok tersusun dari 1 dijit numerik dan maksimal 6 dijit numerik.
g) Character terdari dari huruf besar A sampai Z, atau huruf kecil a sampai z atau
angka 0 sampai 9, atau karakter –, atau karakter spasi.
h) Numeric terdiri dari angka 0 sampai 9.
Sedangkan contoh bentuk ringkas (short form) dari kamus adalah
Identitas Barang = Kode_Brg + Nama_Brg + Satuan + Hrg_Jual + Jml_Stok
EVALUASI
1) Sebutkan area pekerjaan yang harus dilakukan pada tahap analisis menurut
Pressman?
2) Jelaskan pengertian dari throwaway prototyping?
3) Apakah Fungsi dari Kamus Data?
4) Buatlah Kamus Data untuk Menyimpan Biodata Mahasiswa!
48
BAB 5 DESAIN
A. PROSES DESAIN
Desain adalah langkah pertama dalam fase pengembangan bagi setiap produk atau
sistem yang direkayasa. Menurut Taylor dalam (Pressman, 2002) Desain dapat didefinisikan
sebagai proses aplikasi berbagai teknik dan prinsip bagi tujuan pendefinisian suatu perangkat
lunak, suatu proses atau sistem dalam detail yang memadai untuk memungkinkan realisasi
fisiknya.
Tujuan dari perancang sistem adalah untuk menghasilkan suatu model atau
representasi dari entitas yang akan dibangun. Desain berada pada inti teknik dan proses
rekayasa perangkat lunak dan diaplikasikan tanpa memperhatikan model proses perangkat
lunak yang digunakan. Langkah desain menghasilkan desain data, desain arsitektur, desain
interface serta desain prosedural.
Desain data menghasilkan transformasi model domain informasi yang dibuat selama
analisis ke dalam struktur data yang akan diperlukan untuk mengimplementasikan perangkat
lunak. Objek dan hubungan data yang ditetapkan dalam diagram hubungan entitas (ERD) dan
isi detail yang digambarkan di dalam kamus data, menjadi basis bagi aktifitas desain data.
Desain arsitektur menentukan hubungan diantara elemen-elemen struktural utama
dari program. Representasi desain tersebut berupa kerangka modular dari sebuah program
komputer.
Desain interface menggambarkan bagaimana perangkat lunak berkomunikasi dalam
dirinya sendiri, dengan sistem yang berinteroperasi dengannya dan dengan manusia yang
menggunakannya. Interface mengimplementasikan aliran informasi berupa dan kontrol.
Desain prosedural mentransformasi elemen-elemen struktural dari arsitektur
program ke dalam suatu deskripsi prosedur dari komponen-komponen perangkat lunak.
Selama tahap desain kita membuat keputusan yang akan mempengaruhi kesuksesan
konstruksi perangkat lunak, dan yang penting kemudahan bagaimana perangkat lunak dapat
dipelihara. Pentingnya desain perangkat lunak dapat dinyatakan dengan suatu kata tunggal
yaitu kualitas. Desain adalah tempat dimana kualitas dibangun dalam pengembangan
49
perangkat lunak. Desain memberi kita representasi perangkat lunak yang kualitasnya dapat
dinilai. Desain adalah satu-satunya cara dimana kita dapat secara akurat menterjemahkan
kebutuhan pelanggan ke dalam produk atau sistem perangkat lunak yang sudah selesai. Tanpa
desain kita beresiko membangun system yang tidak stabil, sistem yang akan gagal pada saat
perubahan kecil dibuat sehingga sulit diuji dan kualitasnya tidak dapat dinilai.
1. Desain dan Software Quality
Desain perangkat lunak adalah suatu proses interaktif yang melaluinya. Persyaratan
diterjemahkan ke dalam cetak biru (blueprint) untuk membangun perangkat lunak. Cetak biru
menggambarkan suatu pandangan menyeluruh rekayasa perangkat lunak. Sepanjang proses
desain, kualitas yang melengkapi dinilai dengan serangkaian kajian teknis formal. Terdapat 3
karakteristik yang berfungsi sebagai pedoman bagi evaluasi suatu desain yang baik:
a) Desain harus mengimplementasikan keseluruhan eksplisit yang dibebankan dalam
model analisis dan harus mengakomodasi semua persyaratan implisit yang
diinginkan pelanggan.
b) Desain harus menjadi panduan yang dapat dibaca dan dipahami bagi mereka yang
menghasilkan kode dan yang menguji serta memelihara perangkat lunak.
c) Desain harus memberikan suatu gambaran lengkap mengenai perangkat lunak
yang menekankan data, dan perilaku implementasi.
Ketiga karakteristik di atas merupakan sasaran dari proses desain. Untuk mengevaluasi
kualitas dari suatu desain kita harus membangun kriteria teknis untuk desain yang baik. Criteria
desain yang berkualitas baik mengikuti pedoman sebagai berikut:
1) Desain harus memperlihatkan suatu organisasi hirarki yang dengan baik
menggunakan kontrol di antara elemen-elemen perangkat lunak.
2) Desain harus modular, yaitu bahwa perangkat lunak harus dipartisi secara logika ke
dalam elemen-elemen yang melakukan fungsi dan sub fungsi khusus.
3) Desain harus berisi data dan abstraksi prosedural.
4) Desain harus membawa ke arah modul (misal sub rutin atau prosedur) yang
memperlihatkan karakteristik fungsional independen.
5) Desain harus mengarah kepada interface yang mengurangi kompleksitas hubungan
antara modul-modul dan dengan lingkungan eksternal.
6) Desain harus didapat dengan menggunakan metode berulang yang dikendalikan
oleh informasi yang diperoleh selama analisis persyaratan perangkat lunak.
50
Keenam kriteria di atas tidak dapat dicapai secara kebetulan. Proses desain perangkat
lunak memungkinkan adanya desain yang baik melalui aplikasi prinsip-prinsip desain
fundamental, metodologi sistematis, dan kajian yang mendalam.
2. Perkembangan Desain Perangkat Lunak
Evolusi desain perangkat lunak adalah suatu proses kontinu yang terus berlangsung
selama tiga dekade. Desain decade awal dikonsentrasikan pada kriteria untuk
pengembangan program moduler dan metode-metode untuk menyaring arsitektur perangkat
lunak dalam cara top-down yang dikemas dalam pemrograman terstruktur. Desain decade
kedua mengusulkan aliran translasi aliran data atau struktur data ke dalam definisi desain
perangkat lunak. Desain dekade yang lebih baru mengusulkan pendekatan orientasi obyek
ke dalam desain perangkat lunak.
Banyak metode desain yang tumbuh dari kerja tersebut dan tanpa memperhatikan
metode desain yang dipakai, perekayasa perangkat lunak harus mengaplikasikan serangkain
prinsip dasar dan konsep dasar terhadap data, arsitektur, interface dan desain prosedural.
B. PRINSIP-PRINSIP DESAIN
Desain perangkat lunak berupa proses dan model. Proses desain adalah serangkaian
langkah interatif yang memungkinkan desainer menggambarkan semua aspek perangkat lunak
yang dibangun. Tetapi perlu dicatat bahwa proses desain tidaklah sederhana. Keahlian kreatif,
pengalaman, rasa tentang apa yang membuat perangkat lunak menjadi baik dan keseluruhan
komitmen terhadap kualitas adalah faktor sukses.
Model desain berbanding lurus dengan recana arsitek untuk rancangan sebuah rumah.
Model desain memulai dengan menyajikan totalitas dari hal yang akan dibangun. Prinsip-prinsip
desain dasar memungkinkan perekayasa perangkat lunak untuk mengendalikan proses desain.
Menurut Davis dalam (Pressman, 2002) mengusulkan serangkaian prinsip bagi desain
perangkat lunak yang telah diadaptasi dan diperluas sebagai berikut:
a) Proses desain tidak boleh menderita karena “tunnel vision”. Desain yang baik
harus memmperhatikan pendekatan-pendekatan alternative. Menilai masing-
masing pendekatan berdasarkan persyaratan masalah.
b) Desain harus dapat ditelusuri sampai model analisis (reverse engineering).
c) Desain tidak boleh berulang.
d) Desain harus meminimalkan kesenjangan intelektual di antara perangkat lunak dan
masalah yang ada di dunia nyata.
51
e) Desain harus mengungkap keseragaman dan integrasi. Desain seragam
memperlihatkan bahwa satu orang mengembangkan keseluruhannya.
f) Desain harus terukur dan mengakomodasi perubahan.
g) Desain harus terstruktur dan berdegradasi dengan baik, bahkan pada saat data
dan event-event menyimpang atau menghadapi kondisi operasi.
h) Desain bukanlan pengkodean dan pengkodean bukanlah desain. Bahkan bila
dibuat desain procedural detail bagi komponen-komponen program, maka tingkat
abstraksi dari model desain adalah lebih tingi daripada kode sumber.
i) Desain harus dinilai kualitasnya pada saat desain dibuat, bukan setelah jadi.
j) Desain harus dikaji untuk meminimalkan kesalahan-kesalahan konseptual
(semantic).
C. KONSEP DESAIN
Serangkaian konsep desain perangkat lunak fundamental telah berkembang, meskipun
tingkat minat pada setiap konsep bervariasi selama bertahun-tahun. Konsep desain membantu
perekayasa perangkat lunak untuk menjawab beberapa pertanyaan berikut:
1) Kriteria apa yang dapat digunakan untuk mempartisi perangkat lunak ke dalam
komponen-komponen individual?
2) Bagaimana detail struktur data atau fungsi dipisahkan dari suatu representasi
konseptual perangkat lunak?
3) Adakah kriteria yang seragam yang menentukan kualitas teknis suatu desain
perangkat lunak?
Konsep desain perangkat lunak fundamental memberikan kerangka kerja untuk
mendapatkan program yang berfungsi dengan benar.
1. Abstraction
Pada saat kita mempertimbangkan solusi modular terhadap setiap masalah, banyak
tingkat abstraksi yang dapat diperoleh. Pada tingkat abstraksi tinggi solusi dinyatakan dalam
istilah yang luas. Pada saat kita bergerak pada tingkat abstraksi yang berbeda, kita bekerja
untuk membuat abstraksi data dan prosedural. Abstraksi prosedural adalah urutan instruksi
yang diberi nama dan mempunyai fungsi tertentu dan terbatas. Contoh abstraksi procedural
adalah kada Open pada sebuah pintu. Open mengklasifikasikan urutan panjang dari langkah-
langkah procedural (misal berjalan ke pintu, menggapai dan meraih tombol; memutar tombol;
mendorong pintu; dsb.). Abstraksi data adalah kumpulan data yang bernama yang
menggambarkan objek data.
52
Sejumlah bahasa pemrograman (seperti Ada, Modula dan CLU) memberikan
mekanisme untuk membuat berbagai tipe data abstrak. Abstraksi kontrol adalah bentuk
ketiga dari abstraksi yang dipakai dalam desain perangkat lunak. Abstraksi kontrol
mengimplementasikan suatu mekanisme kontrol program tanpa menentukan detail-detail
internal.
2. Modularity
Konsep modularitas dalam perangkat lunak komputer telah didukung selama hampir
empat dekade. Modularitas merupakan konsep dimana perangkat lunak dipecah menjadi
beberapa komponen dan diberi nama untuk dipanggil secara terpisah. Modularitas adalah
attribute tunggal dari perangkat lunak yang memungkinkan sebuah program untuk dikelola
secara intelektual. Perangkat lunak monolitik (yakni program besar yang terdiri dari modul
tunggal) tidak dapat dipahami dengan mudah oleh pembaca. Jumlah alur kontrol, cakupan
referensi, jumlah variable, dan kompleksitas keseluruhan akan membuat pemahaman menjadi
hamper tidak mungkin. Ada beberapa kriteria yang menjadi ciri sistem modular yang efektif:
a) Dekomposisi Modular
Bila metode desain memberikan suatu mekanisme sistematis untuk melakukan
dekomposisi terhadap masalah menjadi sub masalah-sub masalah, maka metode
dasain akan mengurangi kompleksitas keseluruhan masalah, sehingga dapat
mencapai solusi modular efektif.
b) Komposabilitas Modular
Bila suatu metode desain memungkinkan komponen desain (reuseable) yang ada
untuk dipasang ke dalam sebuah sistem baru, maka metode desain akan
menghasilkan suatu solusi modular yang tidak berulang.
c) Kemampuan Pemahaman Modular
Jika sebuah modul dapat dipahami sebagai unit yang berdiri sendiri (tanpa
referensi dan modul lain), maka modul akan lebih mudah dibangun dan diubah.
d) Kontinuitas Modular
Bila perubahan kecil pada persyaratan sistem menyebabkan perubahan kecil pada
modul individual dan bukan perubahan sistem secara luas, maka pengaruh dari
efek samping yang disebabkan oleh perubahan dapat diminimalkan.
53
e) Proteksi Modular Bila terjadi kondisi yang menyimpang pada modul tersebut, pengaruh dari efek
samping yang disebabkan oleh kesalahan akan diminimalkan. 3. Software Architecture
Arsitektur perangkat lunak mencakup struktur keseluruhan perangkat lunak dan cara
dimana struktur memberikan integrasi konseptual bagi suatu sistem. Dalam bentuknya yang
paling sederhana, arsitektur merupakan struktur hirarki dari komponen program (modul), cara
bagaimana komponen tersebut berinteraksi, dan struktur yang digunakan oleh komponen.
Secara lebih luas komponen dapat digeneralisir untuk mewakili elemen-elemen sistem mayor
dan interaksi mereka.
Tujuan desain perangkat lunak adalah untuk mendapatkan gambaran arsitektural
sebuah sistem. Gambaran tersebut berfungsi sebagai kerangka kerja yang dari sana aktivitas
desain yang lebih detail dilakukan. Serangkaian pola arsitektural memungkinkan perekayasa
perangkat lunak untuk menggunakan kembali konsep tingkat desain.
a. Control Hierarchy
Hirarki kontrol, disebut juga struktur program mewakili organisasi komponen (modul)
serta mengimplementasikan suatu hirarki kontrol. Hirarki kontrol tidak mengimplementasikan
aspek procedural dari perangkat lunak, seperti urutan proses, urutan kejadian, keputusan atau
pengulangan.
Hirarki kontrol juga mewakili dua karateristik yang berbeda dari arsitektur perangkat
lunak yaitu visibilitas dan konektivitas. Visibilitas menunjuk kepada serangkaian
komponen yang dapat diminta atau dipakai sebagai daa oleh komponen yang lain. Sedangkan
konektivitas menandai serangkain komponen yang diminta secara tidak langsung atau
digunakan sebagai data oleh sebuah modul yang ditetapkan. Sebagai contoh sebuah modul
yang secara langsung menyebabkan modul lain memulai eksekusi akan disambungkan dengan
modul tersebut.
b. Structural Partitioning
Struktur program harus dipartisi baik secara horizontal maupun struktural/vertikal.
Partisi arsitektural secara horizontal memberikan keuntungan nyata, yaitu:
a) Menghasilkan perangkat lunak yang mudah diuji.
b) Perangkat lunak mudah dipelihara.
54
c) Efek samping buruk yang dihasilkan perangkat lunak lebih sedikit.
d) Menghasilkan perangkat lunak yang mudah diperluas.
Gambar 5.1 Partisi Horisontal
Partisi vertical seperti gambar 5.2 yang sering disebut pemfaktoran menyatakan bahwa
control/pembuat keputusan (decision making modules) dan kerja harus didistribusikan secara
top-down dalam arsitektur program. Modul tingkat puncak harus melakukan fungsi-fungsi
kontrol dan melakukan sedikit kerja pemrosesan aktual. Modul-modul yang dalam arsitektur
berada di bawah harus menjadi para pekerjanya yaiut melakukan tugas input, komputasi dan
output.
Sifat perubahan dalam arsitektur program membenarkan kebutuhan akan partisi
vertikal. Perubahan pada modul kontrol (tinggi dalam arsitektural) akan memiliki probabilitas
penyebaran efek samping yang lebih tinggi ke modul yang menjadi sub ordinatnya. Perubahan
pada modul pekerja (worker modules) yang memiliki tingkat rendah dalam arsitektur, lebih kecil
kemungkinannya untuk menyebabkan penyebaran efek samping. Secara umum perubahan
program komputer berada di seputar perubahan input, komputasi dan transformasi serta
output.
Gambar 5.2 Partisi Vertikal/Struktural
55
c. Data Structure
Struktur data adalah representasi dari hubungan logis antara elemen-elemen data
individual. Karena struktur informasi akan secara bervariasi mempengaruhi desain prosedural
akhir, maka struktur data sama pentingnya dengan struktur program pada representasi
arstitektur perangkat lunak. Struktur data menentukan organisasi, metode akses, tingkat
hubungan dan alternatif pemrosesan untuk informasi. Ada sejumlah struktur data klasik yang
membentuk blok bangunan bagi struktur yang lebih canggih. Struktur data yang lain
digabungkan atau dikonstruksi dengan menggunakan struktur data fundamental seperti yang
telah dijelaskan.
Penting untuk dicatat bahwa struktur data seperti struktur program dapat
direpresentasikan pada tingkat abstraksi yang berbeda. Contohnya stack adalah model
konseptual dari suatu struktur data yang dapat diimplementasikan sebagai vendor atau sebuah
linked list.
d. Software Procedure
Struktur program membatasi hirarki kontrol tanpa melihat urutan pemrosesan data
keputusan. Prosedur perangkat lunak berfokus pada detail-detail pemrosesan dari masing-
masing modul secara terpisah. Prosedur harus memberikan spesifikasi yang teliti terhadap
pemrosesan, mencakup urutan event, poin-poin keputusan nyata, operasi repetitive dan bahkan
organisasi/struktur data.
Ada hubungan antara struktur dan prosedur. Pemrosesan yang diindikasikan bagi
masing-masing modul harus mencakup referensi bagi semua sub ordinat modul yang sedang
digambarkan, yaitu representasi procedural dari perangkat lunak yang dilapiskan seperti pada
gambar 5.3.
56
Gambar 5.3 Prosedur dibuat Berlapis
e. Information Hiding
Konsep modularitas membawa setiap desainer perangkat lunak ke suatau pertanyaan
mendasar yaitu bagaimana mendekomposisi suatu solusi perangkat lunak untuk mendapatkan
serangkaian modul terbaik. Prinsip penyembunyian informasi menyatakan bahwa modul
ditandai dengan keputusan desain yang (masing-masing) tersembunyi dari semua desain lain.
Dengan kata lain modul seharusnya ditentukan dan didesain sehingga informasi (prosedur dan
data) yang diisikan pada sebuah modul tidak dapat diakses ke modul lain yang tidak memiliki
kepentingan terhadap informasi tersebut.
Penyembunyian informasi memberikan bukti bahwa modularitas efektif dapat dicapai
dengan menetapkan serangkaian modul yang independen yang berkomunikasi satu dengan
yang lainnya dimana hanya informasi itu yang diperlukan untuk mencapai fungsi perangkat
lunak. Penggunaan penyembunyian informasi sebagai suatu criteria desain untuk sistem
modular memberikan keuntungan terbesarnya pada saat dibutuhkan modifikasi selama
pengujian dan sesudahnya yaitu selama pemeliharaan perangkat lunak. Karena sebagaian besar
data dan prosedur disembunyikan dari bagian perangkat lunak lain, maka kesalahan kecil yang
57
terjadi selama modifikasi punya kemungkinan lebih kecil untuk menyebarke lokasi lain dalam
perangkat lunak.
D. EFECTIVE MODULAR DESIGN
Semua konsep data fundamental yang telah dijelaskan berfungsi untuk mempercepat
desain modular.
1. Cohesi
Kohesi adalah suatu ekstensi alamiah dari konsep penyembunyian informasi. Modul
kohesi melalukan suatu tugas tunggal pada suatu prosedur perangkat lunak yang memerlukan
sedikit interaksi dengan prosedur yang sedang dilakukan di bagian lain dari suatu program.
Lebih ringkasnya modul kohesi seharusnya hanya melakukan satu hal saja.
2. Coupling
Coupling merupakan sebuah perangkaian pengukuran interkoneksi antara modul-modul
pada sebuah struktur program. Pada desain perangkat lunak kita mengusahakan perangkaian
yang serendah mungkin.
Gambar 5.4 memberikan sebuah ilustrasi mengenai tipe coupling modul yang berbeda-
beda. Modul a dan d adalah sub ordinat bagi modul-modul yang berbeda. Masing-masing tidak
berhubungan sehingga tidak terjadi perangkaian langsung. Modul c adalah sub ordinat dari
modul a dan diakses melalui sebuah daftar argument yang konvensional di mana data
dilewatkan. Selama ada argument sederhana (yakni data sederhana yang dilewatkan;
hubungan satu-ke-satu dari item yang ada), perangkaian rendah. Variasi perangkaian data
yang disebut perangkaian melekat (stamp coupling) ditemukan jika satu bagian dari suatu
struktur data (daripada sebuah argument sederhana) dilewatkan melalui sebuah interface
modul. Hal ini terjadi antara modul a dan b.
58
Gambar 5.4 Tipe Coupling/Perangkaian
E. ARCHITECTURAL DESIGN
Sasaran utama desain arsitektur adalah untuk mengembangkan struktur program
modular dan merepresentasikan hubungan kontrol antar modul. Desain arsitektur juga
membentuk struktur program dan struktur data dengan menentukan interface yang
memungkinkan data mengalir melalui program.
Sistem-sistem besar selalu diuraikan menjadi subsistem-subsistem yang memberikan
set layanan yang berhubungan. Proses perancangan awal untuk mengidentifikasi subsistem ini
dan menetapkan kerangka kerja untuk kontrol dan komunikasinya disebut perancangan
arsitektural dan output proses perancangan ini merupakan deskripsi dari arsitektur perangkat
lunak (Sommerville, 2003).
Keuntungan perancangan dan dokumentasi arsitektural perangkat lunak memiliki
keuntungan sebagai berikut:
a) Komunikasi stake holder. Arsitektur merupakan presentasi tingkat tinggi dari
sistem yang dapat digunakan sebagai fokus pembahasan oleh berbagai stake
holder.
b) Analis sistem. Membuat arsitektur sistem yang eksplisit pada tahap dini
pengembangan sistem mengandung arti bahwa analisis akan dilakukan.
59
c) Pemakaian ulang berskala besar. Arsitektur sistem merupakan deskripsi yang
kompak dan dapat ditangani mengenai bagaimana sistem diorganisir dan
bagaimana komponen-komponen saling mengoperasikan. 1. Software Architecture
Masing-masing metode desain memiliki kekuatan dan kelemahan. Faktor seleksi yang
penting untuk suatu metode desain adalah luasnya aplikasi di mana aplikasi dapat diaplikasikan.
Desain berorientasi pada aliran data dapat menyetujui rentang area aplikasi yang luas. Desain
yang berorientasi pada aliran data merupakan suatu metode desain arsitektur yang mengijinkan
transisi yang baik dari model analisis ke deskripsi desain dari struktur program.
Transisi dari aliran informasi (yang ditunjukkan sebagai diagram aliran data) ke struktur
dilakukan sebagai bagian dari proses lima langkah : (1) tipe aliran informasi dibangun; (2)
batas aliran diindikasikan; (3) DFD dipetakan ke dalam struktur program; (4) hirarki control
ditentukan dengan pemfaktoran; (5) struktur disaring atau diperhalus dengan melakukan
pengukuran desain.
2. Data Design
Model data sering kali dipakai bersama dengan model aliran data untuk
mendeskripsikan struktur informasi yang sedang diproses. Model data semantic dari desain
perangkat lunak dapat dilihat pada Gambar 5.5.
Gambar 5.5 Model Semantik
60
Kebanyakan sistem perangkat lunak yang besar memanfaatkan database sebagai
tempat penyimpanan data yang besar. Pada beberapa kasus, database ini ada secara
independen terhadap sistem perangkat lunak. Teknik pemodelan data yang paling banyak
dipakai adalah pemodelan Entiti Relasi Atribut (pemodelan ERA) yang menunjukkan entitas
data, atribut yang berhubungan dan relasi antar entitas-entitas ini.
Perancangan Database adalah proses untuk menentukan isi dan pengaturan data yang
dibutuhkan untuk mendukung berbagai rancangan sistem.
Perancangan sistem terjadi pada dua tingkat , yaitu :
1) Pada tingkat pertama, perencanaan sistem, analisis dan rancangan umum dilaksanakan
untuk menetapkan kebutuhan pemakai. Tingkat perancangan database ini melibatkan
tahap front-end, bebas dari perancangan database tertentu atau Database Management
System (DBMS).
2) Pada tingkat kedua, rancangan umum, seperti diagram entitas relasi tingkat tinggi,
ditransformasikan (atau didekomposisikan) ke dalam perancangan database rinci untuk
sebuah DBMS tertentu yang akan digunakan untuk mengimplementasikan sistem total.
Tiga model database yang cukup dikenal adalah:
a) Model Hierarkikal
b) Model Jaringan
c) Model Relasional
Pada masa lalu banyak penjual (vendors) menawarkan Database Management Systems
(DBMS) yang berdasarkan pada Model Hierarkikal dan Model Jaringan. Saat ini Model
Relasional adalah dominan. Karena itu hampir semua penjual perangkat lunak database
menawarkan produk perangkat lunak Relational Database Management Systems (RDBMS).
Model Entity Relationship
Adalah suatu penyajian data dengan menggunakan Entity dan Relationship.
Entity
1) Entity adalah obyek yang dapat dibedakan dalam dunia nyata
2) Entity set adalah kumpulan dari entity yang sejenis
3) Entity set dapat berupa:
a) Obyek secara fisik : Rumah, Kendaraan, Peralatan
b) Obyek secara konsep : Pekerjaan, Perusahaan, Rencana
61
Relationship
1) Relationship adalah hubungan yang terjadi antara satu atau lebih entity.
2) Relationship set adalah kumpulan relationship yang sejenis.
Contoh dari relationship dapat dilihat pada Gambar 5.6.
Gambar 5.6 Relationship
Atribut
1) Atribut adalah karakteristik dari entity atau relationship, yang menyediakan penjelasan
detail tentang entity atau relationship tersebut.
2) Nilai Atribut merupakan suatu data aktual atau informasi yang disimpan pada suatu
atribut di dalam suatu entity atau relationship. Jenis-Jenis Atribut :
1) Key
Atribut yang digunakan untuk menentukan suatu entity secara unik.
2) Atribut Simple
Atribut yang bernilai tunggal.
3) Atribut Multivalue
Atribut yang memiliki sekelompok nilai untuk setiap instan entity, dapat dilihat pada
Gambar 5.7.
Gambar 5.7 Atribut Multivalue
4) Atribut Composite
62
Suatu atribut yang terdiri dari beberapa atribut yang lebih kecil yang mempunyai arti
tertentu, dapat dilihat pada Gambar 5.8.
Gambar 5.8 Atribut Composite
5) Atribut Derivatif
Suatu atribut yang dihasilkan dari atribut yang lain, dapat dilihat pada Gambar 5.9.
Gambar 5.9 Atribut Derivatif F. USER INTERFACE DESIGN
Desain arsitektur memberikan kepada perekayasa perangkat lunak suatu gambaran
mengenai struktur program. Desain interface memfokuskan diri pada tiga area perhatian (1)
desain interface antara modul-modul perangkat lunak; (2) desain interface antara perangkat
lunak dan prosedur dan konsumen informasi bukan manusia lainnya (yakni entitas eksternal
lainnya); (3) desain interface antara seorang manusia (seperti pemakai komputer).
Interface user harus bersifat tekstual atau form. Hampir semua user komputer
sekarang memiliki personal computer. Komputer-komputer ini menyediakan interface user
grafis (graphical user interface/GUI) yang mendukung tampilan berwarna dengan resolusi tinggi
dan interaksi dengan memakai mouse dan keyboard. Beberapa karakteristik yang mendasar
dari tipe interface bersifat GUI adalah:
63
Karakteristik Keterangan
Windows Multiple window memungkinkan berbagai informasi
ditampilkan secara simultan pada layar user
Icon Icon mewakili berbagai tipe informasi, file maupun
proses.
Menu Perintah dipilih dari menu dan bukan diketikkan dalam
suatu bahasa perintah.
Pointing (alat penunjuk) Peranti penunjuk seperti mouse digunakan untuk
melakukan pemilihan dari menu atau menunjuk item
yang diinginkan pada window.
Grafik Elemen-elemen grafis dapat dicampur dengan teks pada
tampilan yang sama.
EVALUASI
1) Apakah manfaat dari reverse engineering?
2) Apakah pengertian reverse engineering?
3) Apakah perbedaan antara cohesi dan coupling?
4) Gambarkan sebuah ERD yang menggambarkan mahasiswa mengambil kartu
rencana studi setiap semester akademik!
64
BAB 6 DESAIN UNTUK SYSTEM REAL-TIME
A. SYSTEM REAL-TIME
1. Pengertian System Real-time
Real time system disebut juga dengan Sistem waktu nyata. Sistem yang harus
menghasilkan respon yang tepat dalam batas waktu yang telah ditentukan. Jika respon
komputer melewati batas waktu tersebut, maka terjadi degradasi performansi atau kegagalan
sistem. Sebuah Real time system adalah sistem yang kebenarannya secara logis didasarkan
pada kebenaran hasil-hasil keluaran sistem dan ketepatan waktu hasil-hasil tersebut
dikeluarkan. Aplikasi penggunaan sistem seperti ini adalah untuk memantau dan mengontrol
peralatan seperti motor, assembly line, teleskop, atau instrumen lainnya. Peralatan
telekomunikasi dan jaringan komputer biasanya juga membutuhkan pengendalian secara Real
time.
Berdasarkan batasan waktu yang dimilikinya, Real time system ini dibagi atas:
1. Hard Real time
2. Soft Real time
3. Firm Real time
Komponen dari Real time system ini adalah:
1. Perangkat keras
2. Sistem Operasi Real time
3. Bahasa Pemrograman Real time
4. Sistem Komunikasi
Berdasarkan response time dan dampaknya, maka komputasi real-time
dapat dibedakan menjadi :
1. Sistem Hard Real-Time (HRTS)
Sistem hard real-time dibutuhkan untuk menyelesaikan critical task dengan jaminan waktu
tertentu. Jika kebutuhan waktu tidak terpenuhi, maka aplikasi akan gagal. Dalam definisi
lain disebutkan bahwa kontrol sistem hard real-time dapat mentoleransi keterlambatan
tidak lebih dari 100 mikro detik.Secara umum, sebuah proses di kirim dengan sebuah
pernyataan jumlah waktu dimana dibutuhkan untuk menyelesaikan atau menjalankan I/O.
Kemudian penjadwal dapat menjamin proses untuk selesai atau menolak permintaan
65
karena tidak mungkin dilakukan. Mekanisme ini dikenal dengan resource reservation. Oleh
karena itu setiap operasi harus dijamin dengan waktu maksimum. Pemberian jaminan
seperti ini tidak dapat dilakukan dalam sistem dengan secondary storage atau virtual
memory, karena sistem seperti ini tidak dapat meramalkan waktu yang dibutuhkan untuk
mengeksekusi suatu proses.
Contoh dalam kehidupan sehari-hari adalah pada sistem pengontrol pesawat terbang.
Dalam hal ini, keterlambatan sama sekali tidak boleh terjadi,karena dapat berakibat tidak
terkontrolnya pesawat terbang. Nyawa penumpang yang ada dalam pesawat tergantung
dari sistem ini, karena jika sistem pengontrol tidak dapat merespon tepat waktu, maka
dapat menyebabkan kecelakaan yang merenggut korban jiwa.
2. Sistem Soft Real-Time (SRTS)
Komputasi soft real-time memiliki sedikit kelonggaran. Dalam sistem ini,proses yang kritis
menerima prioritas lebih daripada yang lain. Walaupun menambah fungsi soft real-time ke
sistem time sharing mungkin akan mengakibatkan ketidakadilan pembagian sumber daya
dan mengakibatkan delay yang lebih lama, atau mungkin menyebabkan starvation,
hasilnya adalah tujuan secara umum sistem yang dapat mendukung multimedia, grafik
berkecepatan tinggi, dan variasi tugas yang tidak dapat diterima di lingkungan yang tidak
mendukung komputasi soft real-time.
Contoh penerapan sistem ini dalam kehidupan sehari-hari adalah pada alat penjual/pelayan
otomatis. Jika mesin yang menggunakan sistem ini telah lama digunakan, maka mesin tersebut
dapat mengalami penurunan kualitas,misalnya waktu pelayanannya menjadi lebih lambat
dibandingkan ketika masih baru. Keterlambatan pada sistem ini tidak menyebabkan kecelakaan
atau akibat fatal lainnya, melainkan hanya menyebabkan kerugian keuangan saja. Jika
pelayanan mesin menjadi lambat, maka para pengguna dapat saja merasa tidak puas dan
akhirnya dapat menurunkan pendapatan pemilik mesin. Setelah batas waktu yang diberikan
telah habis, pada sistem hard realtime,aplikasi yang dijalankan langsung dihentikan. Akan
tetapi, pada sistem softreal-time, aplikasi yang telah habis masa waktu pengerjaan
tugasnya,dihentikan secara bertahap atau dengan kata lain masih diberikan
toleransiwaktu.Mengimplementasikan fungsi soft real-time membutuhkan design yang hati-hati
dan aspek yang berkaitan dengan sistem operasi. Pertama,sistem harus punya prioritas
penjadualan, dan proses real-time harus memiliki prioritas tertinggi, tidak melampaui waktu,
walaupun prioritas non real-time dapat terjadi.Kedua, dispatch latency harus lebih kecil.
Semakin kecil latency, semakin cepat real-time proses mengeksekusi. Untuk menjaga dispatch
tetap rendah, kita butuh agar system call untuk preemptible. Ada beberapa cara untuk
mencapai tujuan ini.
66
Pertama adalah dengan memasukkan preemption points di durasi system call yang lama, yang
memeriksa apakah prioritas utama butuh untuk dieksekusi. Jika sudah, maka contex switch
mengambil alih, ketika high priority proses selesai, proses yang diinterupsi meneruskan dengan
system call. Points premption dapat diganti hanya di lokasi yang aman di kernel dimana kernel
struktur tidak dapat dimodifikasi.
Metoda yang lain adalah dengan membuat semua kernel preemptible.Karena operasi yang
benar dapat dijamin, semua struktur data kernel harus diproteksi dengan mekanisme
sinkronisasi. Dengan metode ini, kernel dapat selalu di preemptible, karena setiap data kernel
yang sedang di update diproteksi dengan pemberian prioritas yang tinggi. Jika ada proses
dengan prioritas tinggi ingin membaca atau memodifikasi data kernel yang sedang dijalankan,
prioritas yang tinggi harus menunggu sampai proses dengan prioritas rendah tersebut selesai.
Situasi seperti ini dikenal dengan priority inversion. Kenyataanya, serangkaian proses dapat saja
mengakses sumber daya yang sedang dibutuhkan oleh proses yang lebih tinggi prioritasnya.
Masalah ini dapat diatasi dengan priority- inheritance protocol, yaitu semua proses yang sedang
mengakses sumber daya mendapat prioritas tinggi sampai selesai menggunakan sumber daya.
Setelah selesai, prioritas proses inidikembalikan menjadi seperti semula.
3. Semi Hard Real-Time System (HRTS) atau Semi Soft Real-Time ( SRTS )
Metoda ini merupakan gabungan antara Semi Hard Real-Time System (HRTS) atau Semi Soft Real-Time ( SRTS ). Dengan demikian waktu deadlinenya lebih pendek jika dibandingkan dengan soft real-time ( SRTS ).
4. Interaktif Deadline ( Waktu Deadlinenya Bisa Ditawar )
Pada interaktif real-time, maka waktu deadlinennya bisa ditawar, artinya tidak secara
mutlak pada titik tertentu, tetapi tergantung dari kesepakatan yang ditentukan dan fleksibel.
5. Probabilistic / Statistik
Metode ini biasanya menggunakan teori probabilitas / teori kemungkinan dengan metoda
statistik.
6. Intelligence RTS
Metode ini biasanya menggunakan Expert Systems / Kecerdasan buatan / Artifial
Inteligence atau Kendali Cerdas.
2. Karakteristik System Real Time
System Real Time umumnya punya karakteristik sebagai berikut:
67
• Biasanya merupakan embedded system
• Biasanya membutuhkan pemrosesan konkuren untuk sejumlah input yang masuk,
sehingga perlu didefinisikan sejumlah task untuk memrosesnya, serta perlu strategi
khusus untuk menjadwalkan eksekusi setiap task
• Harus bisa menangani input yang sinkron maupun asinkron
• Punya kebutuhan yang tinggi terhadap reliability dan safety, sehingga fault tolerance
dan exception handling jadi hal yang penting
• Seringkali melibatkan berbagai hardware sehingga ada kebutuhan untuk
mendefinisikan antarmuka yang baik
Elemen Real Time System umumnya terdiri dari:
1. Sensor control processes; yaitu proses yang menerima input dari berbagai sensor
2. Data processor; yaitu proses yang akan melakukan komputasi terhadap data-data
yang diterima dari berbagai sensor
3. Actuator control processes; yaitu proses yang akan membangkitkan sinyal untuk
berbagai actuator
3. Manfaat dan Tujuan System Real Time
Manfaat :
• Sistem waktu nyata keras menjamin bahwa proses waktu nyata dapat diselesaikan
dalam batas waktu yang telah ditentukan. Contoh : sistem safety-critical.
• Sistem waktu nyata banyak digunakan dalam bermacam-macam aplikasi. Sistem
waktu nyata tersebut dapat pula ditanam di dalam alat khusus seperti di kamera,
mp3 players, serta di pesawat dan mobil.
• Real time juga berguna untuk pengendali reaktor nuklir atau sistem pengendali rem
mobil. Juga sering dijumpai pada peralatan medis, peralatan pabrik, peralatan untuk
riset ilmiah, dan sebagainya.
Tujuan :
Bertujuan untuk menyelesaikan masalah dengan waktu tertentu dan proses waktu
nyata dapat diselesaikan dalam waktu tertentu.
68
B. ANALISIS DAN SIMULASI UNTUK SYSTEM REAL-TIME
Serangkain atribut di dinamis yang tidak dapat dipisahkan dari persyaratan fungsional
sebuah sistem real-time :
- Penanganan interupsi dan switching konteks
- Waktu respon
- Laju transfer data dan throughput
- Alokasi sumber daya dan penanganan priorotas
- Sikronisasi tugas dan komunikasi antar tugas
Masing-masing atribut kerja itu dapat ditentukan, tetapi sangat sulit untuk
membuktikan apakah elemen sistem akan mencapai respon yang diinginkan, sumber daya
sistem akan memadai untuk memenuhi persyaratan komputasional atau apakah algoritma
pemrosesan akan mengeksekusi dengan kecepatan yang memadai. Analisis sistem real-time
memungkinkan perekayasa sistem memperkirakan masalah-masalah “timing and sizing”.
1. Piranti Matematis untuk Analisis Sistem Real-Time
Serangkaian peranti matematis yang memungkinkan perekayasa sistem
memodelkan elemen sistem real-time dan mengakses masalah ukuran dan timing, telah
diusulkan oleh Thomas McCabe. Dengan kurang mendasarkan pada teknik analisis aliran data,
pendekatan McCabe membuat analisis mampu memodelkan elemen perangkat lunak dan
perangkat keras sistem real-time, merepresentasikan kontrol dengan cara probabilistik dan
mengaplikasikan analisis jaringan, teori antrian dan grafik dan model matematis Markovian
untuk mendapatkan timing sistem dan ukuran sumber daya.
Teknik analisis real-time dari McCabe didasar atas model aliran dari sistem real-
time. Daripada menggunakan DFD dengan cara yang konvensional, McCabe berpendapat
bahwa transformasi (gelembung) suatu DFD dapat direpresentasikan sebagai keadaan proses
dari rantai Markov dan aliran data sendirilah yang merepresentasikan transisi di antara
keadaan-keadaan proses. Analisis dapat menunjuk probabilitas transisional pada masing-masing
jalur aliran data.
0 <pij ≤ 1,0
Dimana harga dapat ditentukan untuk masing-masing jalur aliran, dimana pij
merepresentasikan probabilitas dimana aliran akan terjadi diantara proses i dan proses j. Proses
tersebut sesuai dengan transformasi informasi (gelembung) pada DFD
merepr
fungsin
dengan
yang m
1. Ju
2. W
3. W
untuk
gamba
Masing-
resentasikan
nya dan sebu
n proses terse
Model it
menghitung ;
umlah yang di
Waktu yang dig
Waktu total yan
Untuk m
sebuag sistem
r di bawah in
-masing pros
waktu eksek
ah “nilai mas
ebut.
tu kemudian
iharapkan dar
gunakan pada
ng digunakan
mengambarka
m tindakan b
ni :
ses pada mod
usi terestima
suk” yang me
dianalisis den
ri kunjungan
a sistem pada
n sistem terse
an teknik Mc
balasan (coun
del seperti D
si (atau aktu
enggambarkan
ngan menggu
ke suatu pros
a saat mulai p
ebut
cCabe pada c
ntermeausure
DFD dapat dib
al) yang dipe
n jumlah inte
unakan serang
ses
pada sebuah p
contoh yang r
e) elektronik
bebani ‘biaya
erlukan untuk
erupsi sistem
gkaian perant
proses terten
realistis, perh
yang diperlih
69
a unit” yang
k melakukan
yang sesuai
ti matematis
tu
hatikan DFD
hatkan pada
pij . mo
2. Te
yang
pengem
dan pe
pereka
Keselu
menuru
a. At
b. At
c. At
loo
yang b
untuk s
a. Pa
M
m
di
se
di
da
ak
pe
ch
Diagram
odel jaringan
eknik Simula
Analisis
dapat digun
mbang peran
emodelan ya
ayasa memba
ruhan hubun
ut i-Logix (pe
turan seri (ke
turan pararel
turan looping
oping)
Pendek
berbeda dari
simulasi dan
andangan Kon
asalah-masal
erepresentas
dalam suatu
edang mengu
kumpulkan, y
ari sistem. It
kan secara
enyimpanan d
hart, yang mir
m alir data m
antrian yang
asi dan Perm
matematis d
nakan untuk
gkat real-ti
ang tidak ha
angun protot
gan rasional
erusahaan yan
datangan dila
(kedatangan
g (server den
katan i-Logix
suatu sistem
pemodelan si
nseptual
ah fungsion
ikan kapabil
sistem reser
update posis
yang membe
tem informasi
khusus men
data. Pandan
rip dengan dia
empunyai be
g ditarik dari D
modelan
dari suatu sist
k memaham
ime yang se
anya mengan
tipe, mengek
dibalik permo
ng mengemba
ayani oleh sub
dilayani oleh
ngan delay d
menggunaka
: activity-cha
stem real-tim
nal diperlak
itas pemrose
rvasi pesawa
si pesawat
entuk hirarki
i seperti jarak
ngalir dianta
ngan fungsion
agram aliran
entuk standar
DFD diperlihat
tem real-time
mi kinerja t
edang berkem
nalisa kinerja
ksekusinya se
odelan dan s
angkan peran
bsistem secar
subsistem se
dan sebuah
an notasi ya
art, module-c
me akan digam
kukan denga
esan sistem.
t merupakan
didalam sua
yang memb
k ke suatu sa
ara aktivitas
nal dari suat
data konvens
, tetapi ident
tkan pada ga
e merepresen
erproyeksi.
mbang mengg
a sistem teta
ehingga mem
imulasi untuk
nti untuk para
ra seri)
ecara pararel)
loop “feedba
ng menggab
chart, state-c
mbarkan pada
an menggu
. Permintaan
n contoh dari
atu sistem a
angun suatu
asaran atau n
dan juga
tu sistem dit
sional.
tifikasi aliran
mbar dibawa
ntasikan satu
Akan tetapi
gunakan pera
api juga mem
mahami perila
k sistem-siste
a perekayasa
)
ack” dengan
bungkan tiga
hart. Pendek
a bagian berik
unakan aktiv
n konfirmasi
i suatu aktivi
avionik. Aktiv
dekomposis
ama seorang
dapat disim
angkap deng
70
data diganti
h ini
pendekatan
, sejumlah
anti simulasi
mungkinkan
aku sistem.
em real-time
sistem)
probabilitas
pandangan
katan i-Logix
kut ini :
vitas yang
pelanggan
itas, karena
vitas dapat
i fungsional
pelanggan,
mpan pada
gan activity-
M
de
re
ca
m
at
pe
kh
sa
m
pe
Ja
di
st
da
da
da
m
m
m
di
m
te
Pe
re
se
asalah perila
engan mengg
ekannya. Disi
ara untuk me
isalnya dapat
tau navigasi.
enerbangan o
husus dipicu
aklar tertentu
enyebabkan
esawat berad
adi, dua pand
hubungkan k
atechart yang
an data dari t
apat member
an merangku
empengaruhi
engirimkan s
emunculkan
lakukan oleh
enambah nil
ersebut dan m
erlu disadari b
epresentasi ya
ebagai sebua
aku dinamis
gunakan state
ni keadaan (
erepresentasik
t menjadi sala
Pada saat y
otomatis atau
oleh event-e
u pada klep
transisi dari
da pada keada
dangan dari s
ke masing-ma
g disebut akti
tingkat itu. Sta
i instruksi pad
m kerja mere
i pemrosesan
sinyal ke ak
aksi-aksi, s
statechart la
lai suatu va
menggunakann
bahwa activity
ang berbeda
h model siste
yang biasan
echart, suatu
(atau mode)
kan perilaku
ah satu dari
yang sama,
u manual. Tr
event yang d
p penutup,
keadaan uda
aan udara ke
istem itu diin
asing tingkat
ivitas kontrol,
atechart dapa
da aktivitas u
eka. Statecha
n yang dilaku
ktivitas itu m
statechart pe
ain. Misalnya,
riabel, maka
nya.
y-chart dan s
dari suatu h
em, karena t
nya menunjuk
notasi yang
dapat dikum
sekuensial at
ketiga keadaa
komputer ha
ransisi dianta
dapat dikualif
misalnya m
ara ke tanah
e tanah maka
ntergrasikan d
dari suatu ac
, yang perann
at mengontro
ntuk mulai da
art dapat men
kan oleh akti
mengubah pe
engontrolan
bila satu sta
statechart
statechart terk
al yang sama
tidak meneka
k pada aspe
dikembangka
mpulkan dan
tau konkuren
an : udara ke
arus berada
ra keadaan-k
fikasikan me
merupakan su
h, tetapi hany
amunisi dapa
dengan cara s
ctivity-chart, b
nya adalah m
ol aktivitas. Se
an berhenti d
ngubah harga
ivitas tersebu
erilaku merek
dapat menc
atechart mem
yang lain d
kait erat, wala
a. Activity ch
ankan perilak
ek kontrol, d
an oleh Harel
di-link denga
. Komputer m
e udara, udar
dalam kead
keadaan terse
nurut kondis
uatu event
ya pada kon
at diperoleh.
sebagai berik
biasanya akan
mengontrol alir
ebagai contoh
an untuk men
a variabel seh
ut. Statechart
ka sendiri. U
ium aksi ya
mulai suatu ak
apat menciu
aupun bukan
art sendiri tid
ku. Statechart
71
diperlakukan
dan rekan-
an sejumlah
misi avionik,
ra ke tanah,
aan kontrol
ebut secara
si. Membalik
yang akan
ndisi dimana
kut : dengan
n ada suatu
ran aktivitas
h, statechart
nangguhkan
hingga akan
t juga dapat
Untuk dapat
ang sedang
ktivitas atau
m kejadian
merupakan
dak lengkap
t juga tidak
72
lengkap karena tanpa aktivitas statechart tidak mempunyai apa-apa untuk dikontrol.
Bersama-sama, activity chart detail dan statechart pengontrolannya memberikan model
konseptual. Activity-chart merupakan tulang punggung dari model tersebut; dekom-posisi
kapabilitas sistemnya merupakan hirarki dominan dari spesifikasi, dan statechart
pengontrolannya merupakan kekuatan pengendali di balik perilaku sistem.
b. Pandangan Fisik
Spesifikasi yang menggunakan activity-chart dan statechart dalam bentuk model
konseptual merupakan fondasi yang sangat bagus, tetapi bukan sistem sesungguhnya. Ada
dua alat yang hilang, yaitu alat untuk menggambarkan sistem tersebut dari perspektif fisik
dan alat untuk memastikan bahwa sistem diimplementasi dengan cara yang benar untuk
spesifikasi tersebut.
Aspek-aspek fisik yang diperlukan dalam stemate menggunakan bahasa module-chart.
Terminologi “fisik” dan “modul” digunakan secara umum untuk menunjukkan komponen
suatu sistem, apakah perangkat keras, perangkat lunak atau hibrida. Seperti halnya
aktivitas pada suatu activity-chart, modul ditata di dalam suatu hirarki untuk
memperlihatkan dekomposisi sistem kedalam komponen dan subkomponennya. Modul
dihubungkan oleh garis-garis aliran dimana seseorang dapat menganggapnya sebagai
pembawa informasi diantara modul.
c. Analisis dan simulasi
Setelah membangun model konseptual, yang terdiri dari activity-chart dan statechart
controlling-nya, maka model tersebut dapat secara teliti dianalisis dan diuji. Model dapat
menggambarkan keseluruhan sistem, sampai ke tingkat detail yang paling rendah, atau
hanya berupa spesifikasi partial.
Kita harus memastikan bahwa sintaksis model tersebu benar. Oleh karena itu ada berbagai
pengujian langsung. Misalnya, bahwa berbagai bagan tidak lengkap secara menyolok
(seperti hilangnya label atau nama, anak panah yang berbayang-bayang), definisi eleme n-
elemen nongrafis seperti event dan kondisi, hanya menggunakan operasi legal dan
sebagainya. Pengecekan sintaks juga melibatkan lebih banyak pengujian yang cermat,
seperti kebenaran input dan output. Contoh untuk hal tersebut adalah pengujian terhadap
elemene-elemen yang digunakan pada statechart. Tetapi tidak ada satu input pun yang
secara internal dipengaruhi seperti event power-on yang dimaksudkan untuk menyebabkan
transisi pada statechart tetapi pada activity-chart tidak ditetapkan sebagai input. Itu semua
biasanya dirujuk oleh pengujian konsistensi dan kelengkapan dan sebagian besar dari
mereka analog dengan pengecekan yang dilakukan oleh kompiler sebelum kompilasi aktual
dari suatu bahasa pemrograman.
73
d. Skenario Running
Model yang secara sintaksis benar, secara akurat menggambarkan banyak sistem, tetapi
model dapat bukan merupakan sistem yang dipikirkan. Kenyataannya sistem yang
digambarkan dapat benar-benar cacat – kebenaran sintaksis tidak menjamin kebenaran
fungsi dan perilaku. Sasaran real dari analisis model adalah untuk menemukan apakah
model-model benar mengambarkan sistem yang kita inginkan. Analisis tersebut
memungkinkan kita mempelajari lebih banyak model yang telah dibangun, untuk
membuktikan apakah sistem sesuai dengan yang diharapkan. Hal ini memerlukan bahasa
permodelan yang lebih dari sekedar sintaks formal, dan mengharuskan sistem yang dibuat
Bila model didasarkan pada suatu semantik formal, perekayasa sistem dapat mengeksekusi
model tersebut. Perekayasa dapat menciptakan dan menjalankan skenario yang
memungkinnnya “menekan tombol” dan mengamati perilaku model sebelum sistem itu
benar-benar dibangun.
Contoh :
untuk menguji model Automated Teller Machine (ATM) diperlukan langkah-langkah
berikut :
- Menciptakan model konseptual
- Perekayasa memainkan peranan pelanggan dan komputer bank, membuat event-
event seperti memasukkan bank card, menekan tombol, dan pemunculan informasi
neraca baru
- Reaksi sistem terhadap event-event itu dimonitor
- Inkonsistensi pada perilaku sistem dicatat
- Model konseptual dimodifikasi untuk mencerminkan perilaku yang tepat
- Iterasi terjadi sampai sistem yang diinginkan berkembang
Perekayasa sistem menjalankan skenario dan memandang respon sistem secara grafis.
Elemen “aktif” dari model tersebut (seperti keadaan bahwa sistem tersebut pada keadaan
dan aktivitas yang aktif) disoroti secara grafis dan eksekusi dinamis menghasilkan
representasi model teranimasi. Eksekusi suatu skenario mensimulasi sistem yang berjalan
secara real time dan melacak informasi time-dependent. Pada setiap titik selama eksekusi,
perekayasa dapat meminta untuk mengetahui status yang lainnya: nongrafis, elemen,
seperti nilai suatu variabel atau kondisi.
e. Simulasi Pemrograman
Skenario memungkinkan perekayasa sistem menguji model secara interaktif. Akan tetapi,
saat ini ada lebih banyak simulasi ekstensif yang dapat diharapkan. Kinerja dibawah
kondisi acak baik dalam situasi khusus maupun tidak khusus, mungkin perlu dinilai. Untuk
situasi dimana simulasi ekstensif dari suatu model real time diinginkan, Simulation Control
74
Language (SCL) memungkinka perekayasa tetap menggunakan kontrol umum terhadap
bagaimana eksekusi itu berlangsung, tetapi pada saat yang sama mengeksploitasi
kekuatan peranti untuk mengambil alih berbagai detail tersebut.
Hal paling sederhana yang dapat dilakukan dengan SLC adalah membaca daftar event dari
suatu batch file. Ini berarti bahwa panjang skenario atau bagian dari skenario dapat
dipersiapkan sebelumnya dan dieksekusi secara otomatis. Hal ini dapat diobservasi oleh
perekayasa sistem. Sebagai alternatif, perekayasa sistem dapat memprogram dengan SCL
untuk menentukan break point dan memonitor variabel tertentu, keadaan atau kondisi.
Sebagai contoh, dalan menjalankan simulasi suatu sistem avionik, perekayasa sistem harus
meminta program SCL untuk berhenti kapan saja radar mengunci target dan beralih ke
mode interaktif. Sekali “lock on” dikenali, perekayasa mengambil alih secara interaktif,
sehingga keadaan ini dapat diamati secara lebih detail.
Penggunaan skenario dan simulasi juga memungkinkan perekayasa mengumpulkan
statistik yang sangat berarti tentang operasi sistem yang akan dibangun. Contohnya, kita
dapat mengetahui berapa kali dalam suatu penerbangan tertentu dari pesawat, radar
kehilangan target lock on. Karena mungkin sulit bagi perekayasa untuk meletakkan
bersama-sama skenario penerbangan all-encom-passing tunggal, maka dapat
dikembangkan simulasi terprogram dengan menggunakan hasil-hasil yang terakumulasi
dari skenario lain untuk mendapatkan statis tik kasus rata-rata. Program kontrol otomatis
menghasilkan event-event acak sesuai dengan probabilitas yang ditentukan sebelumnya.
Jadi event-event yang sangat terjadi (katakanlah tempat duduk yang meloncat otomatis
pada pesawat tempur) dapat diberi probabilitas sangat rendah sementara yang lain diberi
probabilitas yang lebih tinggi dan pemilihan acak dari kejadian sehingga menjadi realistis.
Untuk dapat mengumpulkan statistik yang diinginkan, masukkan break poiny yang sesuai
pada program SCL.
f. Translasi Otomatis ke dalam Kode
Sekali model sistem dibangun, maka keseluruhan model dapat diterjemahkan kedalam
kode yang dapat dieksekusi dengan menggunakan suatu fungsi prototyping, activity-chart
dan statechart controlling nya dapat diterjemahkan kedalam bahasa pemrograman tingkat
tinggi, seperti Ada atau C. Saat ini kegunaaan utama dari kode yang dihasilkan adalah
untuk mengamati sistem yang bekerja dalam keadaan yang sedekat mungkin dengan
dunia nyata. Contohnya, kode prototype dapat dieksekusi dalam stimulator full-fledged dari
lingkungan target atau lingkungan akhir itu sendiri. Kode yang dihasilkan oleh peranti
CASE seperti itu harus dikategorikan menjadi “protipikal”. Model ini bukan merupakan
produksi atau kode akhir. Akibatnya model tidak dapat selalu merefleksikan kinerja real-
75
time yang akurat dari sistem yang dimaksudkan. Meskipun demikian, model sistem sangat
berguna untuk pengujian kinerja sistem yang dekat dengan lingkungan nyata.
C. DESAIN REAL-TIME
Desain perangkat lunak real-time harus menggabungkan semua konsep dan prinsip
fundamental yang berhubungan dengan perangkat lunak kualitas tinggi. Perangkat lunak real-
time juga merupakan serangkaian masalah uni bagi para desainer :
- Representasi interupsi dan switching konteks
- Konkurensi yang dimanifestasikan oleh multitasking dan multi prosessing
- Komunikasi antar-tugas dan sinkronisasi
- Variasi yang luas didalam data dan laju komunikasi
- Representasi batasan timing
- Pemrosesan asinkron
- Perangkaian yang perlu dan tidak dapat dihindarkan dengan sistem operasi, perangkat
keras dan elemen sistem eksternal yang lain
Prinsip permodelan yang harus dipertimbangkan dalam desain sistem real-time :
- Atomisitas eksplisit
Perlu untuk menentukan “aksi atomik” secara eksplisit sebagai bagian dari model desain
real-time. Aksi atau event atomik merupakan fungsi yang dibatasi dengan baik yang dapat
dieksekusi oleh suatu tugas tunggal atau dieksekusi secara konkuren oleh beberapa tugas.
Aksi atomik diminta hanya mempengaruhi partisipan-partisipan tersebut; tidak ada bagian
lain dari sistem yang dipengaruhi
- Interleaving
Meskipun pemrosesan dapat dibuat konkuren, sejarah dari berbagai komputasi seharusnya
ditandai dengan suatu cara yang dapat diperoleh dengan urutan linier dari aksi. Sebagai
hasil dari aksi ini, keadaan di modifikasi dan aksi ked ua berlangsug. Karena beberapa aksi
dapat berlangsung didalam suatu keadaan yang diberikan, maka dapat ditimbulkan hasil
yang berbeda dari keadaan awal yang sama. “Non-determinisme ini penting dalam
permodelan interleaved dari konkurensi”
- Keadilan dan sejarah yang tidak terbatas
Sejarah pemrosesan dari suatu sistem diasumsikan tidak terbatas. Yang kita maksudkan
adalah pemrosesan berlanjut secara tidak terbatas. Yang kita maksudkan adalah
pemrosesan berlanjut secara tidak terbatas atau “tersendat” sampai beberapa event
menyebabkan sistem melanjutkan pemrosesan. Persyaratan keadilan mencegah sistem
berhenti pada beberapa titik yang berubah-ubah.
76
- Prinsip sistem tertutup
Model desain sistem real time harus meliputi perangkat lunak dan lingkungan dimana
perangkat lunak berada. “karena itu aksi-aksi dapat dibagi-bagi kedalam aksi yang sistem
itu sendiri bertanggung jawab dan kedalam aksi yang diasumsikan akan dieksekusi oleh
lingkungan”
- Penstrukturan keadaan
Sistem real time dapat dimodelkan sebagai serangkaian objek, masing-masing memiliki
keadaannya sendiri-sendiri
Perekayasa perangkat lunak harus memperhatikan masing-masing konsep tersebut pada
saat desain sistem real-time berkembang.
77
BAB 7 TEKNIK PENGUJIAN PERANGKAT LUNAK Pengujian perangkat lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan
merepresentasikan spesifikasi, desain dan pengkodean.
A. DASAR-DASAR PENGUJIAN PERANGKAT LUNAK
Meningkatnya visibilitas (kemampuan) perangkat lunak sebagai suatu elemen sistem
dan “biaya” yang muncul akibat kegagalan perangkat lunak, memotivasi dilakukannya
perencanaan yang baik melalui pengujian yang teliti. Pada dasarnya, pengujian merupakan satu
langkah dalam proses rekayasa perangkat lunak yang dapat dianggap sebagai hal yang
merusak daripada membangun.
Dalam melakukan uji coba ada 2 masalah penting yang akan dibahas, yaitu :
• Teknik uji coba perangkat lunak
• Strategi uji coba perangkat lunak
a. Teknik Uji Coba Perangkat Lunak
Pada dasarnya, pengujian merupakan suatu proses rekayasa perangkat lunak yg dapat
dianggap (secara psikologis) sebagai hal yg destruktif daripada konstruktif.
b. Sasaran Pengujian (Glen Myers) :
• Pengujian adalah proses eksekusi suatu program dengan maksud menemukan
kesalahan.
• Test case yg baik adalah test case yg memiliki probabilitas tinggi untuk
menemukan kesalahan yg belum pernah ditemukan sebalumnya.
• Pengujian yg sukses adalah pengujian yg mengungkap semua kesalahan yg belum
pernah ditemukan sebelumnya.
c. Prinsip pengujian (diusulkan davis) :
• Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan
• Pengujian harus direncanakan lama sebelum pengujian itu dimulai.
• Prinsip Pareto berlaku untuk pengujian perangkat lunak. Prinsip Pareto
mengimplikasikan 80% dari semua kesalahan yg ditemukan selama pengujian
sepertinya akan dapat ditelusuri sampai 20% dari semua modul program.
78
• Pengujian harus mulai "dari yg kecil" dan berkembang ke pengujian "yang besar".
• Pengujian yg mendalam tidak mungkin.
• Paling efektif, pengujian dilakukan oleh pihak ketiga yg independen.
d. Testabilitas
Testabilitas perangkat lunak adalah seberapa mudah sebuah program komputer dapat
diuji. Karena pengujian sangat sulit, perlu diketahui apa yg dapat dilakukan untuk
membuatnya menjadi mudah.
Karakteristik perangkat lunak yg diuji :
1. OPERABILITAS, semakin baik dia bekerja semakin efisien dia dapat diuji.
2. OBSERVABILITAS, apa yg anda lihat adalah apa yg anda uji.
3. KONTROLABILITAS, semakin baik kita dapat mengontrol perangkat lunak semakin
banyak pengujian yg adapat diotomatisasi dan dioptimalkan.
4. DEKOMPOSABILITAS, dengan mengontrol ruang lingkup pengujian kita dapat lebih
cepat mengisolasi masalah dan melakukan pengujian kembali.
5. KESEDERHANAAN, semakin sedikit yg diuji semakin cepat pengujian.
6. STABILITAS, semakin sedikit perubahan semakin sedikit gangguan pengujian.
7. KEMAMPUAN DIPAHAMI, semakin banyak informasi yg dimiliki semakin detail
pengujiannya.
e. ATRIBUT PENGUJIAN YG BAIK :
• Memiliki probabilitas yg tinggi menemukan kesalahan.
• Tidak redundan.
• Harusnya ‘jenis terbaik’.
• Tidak boleh terlalu sederhana atau terlalu kompleks.
B. TEST CASE DESIGN
Terdapat bermacam-macam rancangan metode test case yg dapat digunakan, semua
menyediakan pendekatan sistematis untuk uji coba, yg terpenting metode menyediakan
kemungkinan yg cukup tinggi menemukan kesalahan.
Terdapat 2 macam test case:
• Pengetahuan fungsi yg spesifik dari produk yg telah dirancang untuk diperlihatkan, test
dapat dilakukan untuk menilai masing-masing fungsi apakah telah berjalan sebagaimana
yg diharapkan.
79
• Pengetahuan tentang cara kerja dari produk, test dapat dilakukan untuk memperlihatkan
cara kerja dari produk secara rinci sesuai dengan spesifikasinya.
Dua macam pendekatan test yaitu :
1. Black Box Testing
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.
Tehnik pengujian black-box berfokus pada domain informasi dari perangkat lunak,
dengan melakukan test case dengan menpartisi domain input dari suatu program
dengan cara yang memberikan cakupan pengujian yang mendalam.
Metode pengujian graph-based mengeksplorasi hubungan antara dan tingkah laku
objek-objek program. Partisi ekivalensi membagi domain input ke dalam kelas data
yang mungkin untuk melakukan fungsi perangkat lunak tertentu. Analisis nilai batas
memeriksaa kemampuan program untuk menangani data pada batas yang dapat
diterima.
Metode pengujian yang terspesialisasi meliputi sejumlah luas kemampuan perangkat
lunak dan area aplikasi. GUI, arsitektur client/ server, dokumentasi dan fasilitas help
dan sistem real time masing-masing membutuhkan pedoman dan tehnik khusus untuk
pengujian perangkat lunak.
2. White Box Testing
Adalah meramalkan cara kerja perangkat lunak secara rinci, karenanya logikal path
(jalur logika) perangkat lunak akan ditest dengan menyediakan test case yang akan
mengerjakan kumpulan kondisi dan atau pengulangan secara spesifik. Secara sekilas
dapat diambil kesimpulan white box testing merupakan petunjuk untuk mendapatkan
program yang benar secara 100%.
• Pengujian white-box berfokus pada struktur control program. Test case dilakukan
untuk memastikan bahwa semua statemen pada program telah dieksekusi paling
tidak satu kali selama pengujian dan bahwa semua kondisi logis telah diuji.
Pengujian basic path, tehnik pengujian white-box, menggunakan grafik (matriks
80
grafiks) untuk melakukan serangkaian pengujian yang independent secara linear
yang akan memastikan cakupan.
Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program dan
pengujian loop menyempurnakan tehnik white-box yang lain dengan memberikan
sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi.
Pengujian black-box didesain untuk mengungkap kesalahan pada persyaratan
fungsional tanpa mengabaikan kerja internal dari suatu program.
C. WHITE-BOX TESTING
Uji coba white box adalah metode perancangan test case yang menggunakan struktur
kontrol dari perancanganprosedural untuk mendapatkan test case. Dengan menggunakan
metode white box, analis sistem akan dapatmemperoleh test case yang :
• Menjamin seluruh independent path di dalam modul yang dikerjakan sekurang-kurangnya
sekali
• Mengerjakan seluruh keputusan logikal
• Mengerjakan seluruh loop yang sesuai dengan batasannya
• Mengerjakan seluruh struktur data internal yang menjamin validitas
Apa yang di uji dengan white box
1. Struktur data
2. Statement Kondisi
3. Statement Pengulangan
Persyaratan dalam menjalankan strategi White Box Testing
• Mendefinisikan semua alur logika
• Membangun kasus untuk digunakan dalam pengujian
• Mengevaluasi semua hasil pengujian
• Melakukan pengujian secara menyeluruh
Kelebihan white box tes:
• Correctness program dan kebenaran dalam mendefinisikan algoritma dapat diketahui
secara langsung dengan pengolahan path.
• White box testing dapat dilakukan dengan follow up performance line coverage, dengan
memberikan pihak tester list of line code yang belum dieksekusi.
81
• Menentukan kualitas pekerjaan coding dan pengaruhnya untuk standar coding.
Kelemahan white box tes:
• Jumlah biaya untuk white box testing lebih besar daripada biaya yang dibutuhkan untuk
black box, untuk ukuran software yang sama.
• Belum mampu melakukan tes availability, reliability, load durability dan testing – testing
lain yang berhubungan dengan requirement faktor – faktor untuk operasi, revisi dan
transisi.
1. Pengujian Basis Path
Uji coba basis path adalah teknik uji coba white box yg diusulkan Tom
McCabe. Metode ini memungkinkan perancang test case mendapatkan ukuran
kekompleksan logical dari perancangan prosedural danmenggunkan ukuran ini sbg
petunjuk untuk mendefinisikan basis set dari jalur pengerjaan. Test case yg
didapat digunakan untuk mengerjakan basis set yg menjamin pengerjaan setiap
perintah minimal satu kali selama ujicoba.
a. Notasi diagram alir
Sebelum metode basis path dapat diperkenalkan, notasi sederhana
untuk representasi aliran kontrol yangdisebut diagram alir (atau grafik program)
harus diperkenalkan. Pada gambar dibawah ini masing-masing lingkaran disebut
simpul grafik alir, yang merepresentasikan satu atau lebih statemen prosedural.
Anak panah pada grafik alir tersebut yang disebut edges atau links,
merepresentansikan aliran kontrol dan analog dengan anak panah bagan alir. Edges
harus berhenti pada suatu simpul, meskipun bila simpul tersebut tidak
merepresentasikan statemen prosedural (seperti if-then-else). Area yang dibatasi
oleh edge dan simpul disebut region.
Untuk menggambarkan pemakaian diagram alir diberikan contoh perancangan
prosedural dalam bentuk flowchart
82
Lingkaran/node : menggambarkan satu/lebih perintah prosedural. Urutan
proses dan keputusan dapat dipetakan dalam satunode.
Tanda panah/edge : menggambarkan aliran kontrol. Setiap node harus
mempunyai tujuan node
Region : adalah daerah yg dibatasi oleh edge dan node. Termasuk
daerah diluar grafik alir.
b. Kompleksitas Siklomatis
Kompleksitas Siklomatis adalah metric perangkat lunak yang
memberikan pengukuran kuantitaif terhadap kompleksitas logis suatu program.
Kompleksitas Siklomatis menentukan jumlah jalur independen dalam basis set suatu
program dan memberikan batas atas bagi jumlah pengujian yang harus dilakukan
untuk memastikan bahwa semua statemen telah dieksekusi sedikitnya satu kali.
Jalur independen adalah jalur yang melalui program yang mengintroduksi sedikitnya
satu rangkaian statemen proses baru atau suatu kondisi baru.
83
c. Melakukan Test Case
1) Dengan menggunakan desain atau kode sebagai dasar, gambarkan
sebuah grafik alir yang sesuai.
2) Tentukan kompleksitas siklomatis dari grafik alir resultan.
3) Tentukan sebuah basis set dari jalur independen secara linier.
4) Siapkan test case yang akan memaksa adanya eksekusi setiap basis
set.
d. Matrik Grafis
• Matrik grafis adalah matriks bujur sangkar yang ukurannya sama
dengan jumlah simpul pada grafik alir.
• Masing-masing baris dan kolom sesuai dengan yang
diidentifikasikan, dan entri matriks sesuai dengan edge di antara
simpul
2. Pengujian Struktur Kontrol
Teknik pengujian basis path yang digambarkan diatas adalah satu dari
sejumlah teknik untuk pengujian stuktur kontrol. Meskipun pengujian basis path
sederhana dan sangat efektif, tetapi pengujian ini tidak memadai.
a. Pengujian Kondisi
Merupakan sebuah metode desain test case yang menggunakan kondisi
logis yang ada pada suatuprogram. Kondisi sederhana adalah variable Boolean atau
suatu persamaan hubungan, dapat didahuluidengan satu operator NOT.Bila terdapat
suatu kondisi tidak benar, maka paling tidak satu komponen dari kondisi tersebut
salah.Dengan demikian tipe kesalahan pada suatu kondisi meliputi berikut ini :
• Kesalahan operator Boolean (ada operator Boolean yang
salah/hilang/ekstra)
• Kesalahan variable Boolean
• Kesalahan tanda kurung Boolean
• Kesalahan operator relasional
• Kesalahan persamaan aritmatika
Metode pengujian kondisi berfokus pada pengujian masing-masing kondisi di dalam
program.
Metode ini mempunyai dua keuntungan yaitu :
• Pengukuran kupasan pengujian dari satu kondisi adalah sederhana
• Cakupan pengujian terhadap kondisi di dalam suatu program memberikan
pedoman untuk melkaukan pengujian tambahan untuk program tersebut.
84
Tujuan pengujian kondisi adalah mendeteksi tidak hanya kesalahan di dalam kondisi
program, tetapi juga kesalahan lain pada program.
b. Pengujian Aliran Data
Metode ini memilih jalur pengujian dari suatu program sesuai dengan
lokasi definisi dan menggunakanvariable-variabel pada program.Strategi
pengujian aliran data berguna untuk memilih jalur pengujian dari suatu
program yang berisistatemen if dan loop yang tersarang
c. Pengujian Loop
Loop adalah batu pertama untuk mayoritas algoritma yang
diimplementasikan pada Software. Pengujianloop merupakan teknik
pengujian white-box yang secara ekslusif berfokus pada validitas
konstruksiloop. Empat kelas loop yang berbeda dapat didefinisikan :
• Loop sederhana
• Loop terangkai
• Loop tersarang
• Loop tidak terstruktur
D. CONTROL STRUCTURE TESTING
Control Structure Testing merupakan bagian dari pengujian white-box. Kondisi
pengujian :
• kasus uji metode desain.
• bekerja pada kondisi logis dalam modul program
• melibatkan pengujian dari kedua ekspresi relasional dan ekspresi aritmatika.
• Jika kondisi tidak benar, maka setidaknya satu komponen dari kondisi tidak
benar.
• Jenis kesalahan dalam pengujian kondisi kesalahan operator boolean, variabel
boolean kesalahan, kesalahan kurung boolean, kesalahan operator relasional,
dan kesalahan aritmatika ekspresi.
- Kondisi Sederhana: ekspresi Boolean variabel atau relasional, kemungkinan
dilanjutkan oleh operator NOT.
- Kondisi Compound: Hal ini terdiri dari dua atau lebih kondisi sederhana,
operator Boolean dan tanda kurung.
- Ekspresi Boolean: suatu kondisi tanpa ekspresi relasional.
85
1. Data Flow Diagram
Metode data flow testing memilih jalur program berdasarkan pada lokasi dari
definisi dan penggunaan variabel-variabel pada program.
Sebagai ilustrasi pendekatan data flow testing, diasumsikan bahwa tiap
pernyataan dalam suatu program ditandai dengan suatu penomoran pernyataan yang
unik sifatnya, sebagai identitas dari tiap pernyataan tersebut, dimana tiap fungsi tidak
memodifikasi parameter atau variabel globalnya.
Untuk suatu pernyataan dengan S sebagai nomor pernyataannya:
– DEF(S) = [X | pernyataan S mengandung suatu definisi X]
– USE(S) = [X | pernyataan S mengandung suatu penggunaan X]
Jika pernyataan S adalah suatu pernyataan IF atau LOOP, maka bagian DEF akan
kosong dan bagian USE didasarkan pada kondisi dari pernyataan S. Definisi dari
variabel X pada pernyataan S dinyatakan “tinggal” di dalam pernyataan S’ jika ada
suatu jalur dari pernyataan S ke pernyataan S’ yang tidak mengandung definisi X
tersebut.
Ikatan Definition-Use (DU) dari X ditulis dalam bentuk [X,S,S’], dimana S dan S’ adalah
nomor pernyataan, hal ini berarti X ada pada DEF(S) dan USE(S’), dan definisi X pada
pernyataan S tinggal di dalam pernyataan S’.
Suatu strategi data flow testing sederhana harus mencakup tiap ikatan DU setidaknya
sekali. Oleh karena itu data flow testing disebut juga strategi DU testing.
DU testing tidak selalu menjamin pemenuhan cakupan seluruh cabang dari program.
Namun hal ini adalah suatu situasi yang jarang terjadi, bilamana suatu cabang tidak
menjadi cakupan dari DU testing, seperti konstruksi IF-THEN-ELSE, dimana bagian
THEN tidak mempunyai definisi variabel apapun, dan bagian ELSE tidak ada. Pada
situasi ini, cabang ELSE dari pernyataan IF tidak perlu di cakup oleh DU testing.
Strategi data flow testing sangat berguna untuk menentukan jalur tes pada program
yang berisi pernyataan nested if dan loop.
Sebagai ilustrasi dari penerapan DU testing untuk memilih jalur tes PDL sebagai berikut
Untuk meng
flow, perlu
pada PDL.
Diasumsikan
B4, dan B5
Jika mengg
sebagaiman
Untuk mem
struktur dar
apakah jalu
jalur.)
Sejak perny
berdasarkan
efektif untu
Bagaimanap
untuk data
testing kond
Adalah tidak
secara ekste
digunakan p
software.
ggunakan stra
mengetahui d
n bahwa varia
dan digunaka
unakan strate
na disebutkan
milih jalur tes d
ri tiap kondisi
r fisibel untuk
yataan-pernya
n pada definis
k mendeteksi
pun juga, ma
flow testing a
disi.
k realistis unt
ensif bila mel
pada daerah t
ategi DU testi
defnisi dan pe
abel X didefin
an pada perny
egi branch tes
n di atas, tidak
dari diagram
atau blok. (S
k program; ya
ataan pada su
si dan penggu
i error.
salah-masala
akan lebih sul
tuk mengasum
akukan tes su
tertentu yang
ting dalam me
enggunaan da
nisikan pada p
yataan pertam
esting untuk m
k dibutuhkan
untuk BRO te
Setelah pemili
aitu setidakny
uatu program
unaan variabe
h pengukuran
lit daripada m
msikan bahwa
uatu sistem y
g ditargetkan
emilih jalur te
ari variabel di
pernyataan ak
ma dari blok B
memilih jalur t
informasi tam
esting, dibutu
ihan jalur pro
ya satu masuk
dihubungkan
el, pendekata
n cakupan tes
masalah yang
a data flow te
yang besar. N
sebagai peny
s dari diagram
tiap kondisi a
khir dari blok
B2, B3, B4, B
tes dari PDL,
mbahan.
hkan pengeta
ogram, perlu m
kan ada yang
n satu sama l
an data flow te
s dan pemilih
berkaitan den
esting akan di
amun biasany
yebab kesalah
86
m control
atau blok
B1, B2, B3,
5, dan B6.
ahuan akan
menentukan
g melalui
ain
testing akan
an jalur tes
ngan
igunakan
ya akan
han dari
87
a. Loop Testing
Loop testing adalah suatu teknik white box testing yang berfokus pada validitas
konstruksi loop secara eksklusif. Gambar 3.10 memperlihatkan empat kelas yang
berbeda dari loop [BEI90], yaitu:
• Simple Loops
• Nested Loops
• Concatenated Loops
• Unstructured Loops
b. Simple Loops
Sekumpulan tes berikut ini dapat digunakan untuk simple loops, dimana n adalah
jumlah maksimum yang dapat dilewatkan pada loop:
- Lompati loop secara keseluruhan, tak ada iterasi / lewatan pada loop.
- Lewatkan hanya satu kali iterasi pada loop.
- Lewatkan dua kali iterasi pada loop.
- Lewatkan m kali iterasi pada loop dimana m<n.
- Lewatkan n-1, n, n+1 kali iterasi pada loop.
c. Nested Loops
Jika pendekatan tes untuk simple loops dikembangkan pada nested loops, jumlah
kemungkinan tes akan berkembang secara geometris searah dengan semakin tingginya
tingkat dari nested loops.
- Beizer [BEI90], memberikan suatu pendekatan yang akan menolong untuk
mengurangi jumlah tes.
- Mulailah dari loop yang paling dalam. Set semua loops lainnya dengan nilai
minimum.
- Lakukan tes simple loops untuk loop yang paling dalam, dengan tetap
mempertahankan loops yang ada di luarnya dengan nilai parameter iterasi yang
minimum. Tambahkan tes lainnya untuk nilai yang diluar daerah atau tidak
termasuk dalam batasan nilai parameter iterasi.
88
- Kerjakan dari dalam ke luar, lakukan tes untuk loop berikutnya, tapi dengan
tetap mempertahankan semua loop yang berada di luar pada nilai minimum
dan nested loop lainnya pada nilai yang umum.
- Teruskan hingga keseluruhan dari loops telah dites.
d. Concatenated Loops
Concatenated loops dapat dites dengan menggunakan pendekatan yang didefinisikan
untuk simple loops, jika tiap loops independen (tidak saling bergantung) antara satu
dengan yang lainnya. Dikatakan dua loops tidak independen, jika dua loops merupakan
concatenated loops, dan nilai loop counter pada loop 1 digunakan sebagai nilai awal
untuk loop 2. Bila loops tidak independen, direkomendasikan memakai pendekatan
sebagaimana yang digunakan pada nested loops.
e. Unstructured Loops Tidak dapat dites dengan efektif. Dan bila memungkinkan loops jenis ini harus didisain ulang.
BLACK-BOX TESTING
Black box testing, dilakukan tanpa pengetahuan detil struktur internal dari sistem atau
komponen yang dites. juga disebut sebagai behavioral testing, specification-based testing,
input/output testing atau functional testing. Black box testing berfokus pada kebutuhan
fungsional pada software, berdasarkan pada spesifikasi kebutuhan dari software. Black box
testing bukan teknik alternatif daripada white box testing. Lebih daripada itu, ia merupakan
pendekatan pelengkap dalam mencakup error dengan kelas yang berbeda dari metode white
box testing.
Kategori error yang akan diketahui melalui black box testing :
• Fungsi yang hilang atau tak benar
• Error dari antar-muka
• Error dari struktur data atau akses eksternal database
• Error dari kinerja atau tingkah laku
• Error dari inisialisasi dan terminasi
Tujuan metode ini mencari kesalahan pada:
• Fungsi yg salah atau hilang
• Kesalahan pada interface
• Kesalahan pada struktur data atau akses database
• Kesalahan performansi
• Kesalahan inisialisasi dan tujuan akhir
89
Metode ini tidak terfokus pada struktur kontrol seperti pengujian white-box tetapi pada
domain informasi. Pengujian dirancang untuk menjawab pertanyaan sebagai berikut :
• Bagaimana validitas fungsional diuji?
• Apa kelas input yg terbaik untuk uji coba yg baik?
• Apakah sistem sangat peka terhadap nilai input tertentu?
• Bagaimana jika kelas data yang terbatas dipisahkan?
• Bagaimana volume data yg dapat ditoleransi oleh sistem?
• Bagaimana pengaruh kombinasi data terhadap pengoperasian system?
a. Metode Pengujian Graph-Based
Langkah pertama pada black box testing adalah memahami obyek yang
dimodelkan dalam software dan hubungan koneksi antar obyek, kemudian definisikan
serangkaian tes yang merupakan verifikasi bahwa semua obyek telah mempunyai hubungan
dengan yang lainnya sesuai yang diharapkan. [BEI95]
Langkah ini dapat dicapai dengan membuat grafik, dimana berisi kumpulan node
yang mewakili obyek, penghubung / link yang mewakili hubungan antar obyek, bobot node
yang menjelaskan properti dari suatu obyek, dan bobot penghubung yang menjelaskan
beberapa karakteristik dari penghubung / link.
• Nodes direpresentasikan sebagai lingkaran yang dihubungkan dengan garis
penghubung.
• Suatu hubungan langsung (digambarkan dalam bentuk anak panah)
mengindikasikan suatu hubungan yang bergerak hanya dalam satu arah.
90
• Hubungan dua arah, juga disebut sebagai hubungan simetris, menggambarkan
hubungan yang dapat bergerak dalam dua arah.
• Hubungan paralel digunakan bila sejumlah hubungan ditetapkan antara dua nodes
Beizer menggambarkan sejumlah metode pengujian behavioral yang dapat
menggunakan grafik :
• Pemodelan Alur Transaksi, dimana node mewakili langkah-langkah transaksi (misal
langkah-langkah penggunaan jasa reservasi tiket pesawat secara on-line), dan
penghubung mewakili logika koneksi antar langkah (misal masukan informasi
penerbangan diikuti dengan pemrosesan validasi / keberadaan).
• Pemodelan Finite State, dimana node mewakili status software yang dapat
diobservasi (misal tiap layar yang muncul sebagai masukan order ketika kasir
menerimaa order), dan penghubung mewakili transisi yang terjadi antar status (misal
informasi order diverifikasi dengan menampilkan keberadaan inventori dan diikuti
dengan masukan informasi penagihan pelanggan).
• Pemodelan Alur Data, dimana node mewakili obyek data (misal data Pajak dan Gaji
Bersih), dan penghubung mewakili transformasi untuk me-translasikan antar obyek
data (misal Pajak = 0.15 x Gaji Bersih).
• Pemodelan Waktu / Timing, dimana node mewakili obyek program dan
penghubung mewakili sekuensial koneksi antar obyek tersebut. Bobot penghubung
digunakan untuk spesifikasi waktu eksekusi yang dibutuhkan.
Testing berbasis grafik (graph based testing) dimulai dengan mendefinisikan semua
nodes dan bobot nodes. Dalam hal ini dapat diartikan bahwa obyek dan atribut didefinisikan
terlebih dahulu. Data model dapat digunakan sebagai titik awal untuk memulai, namun perlu
diingat bahwa kebanyakan nodes merupakan obyek dari program (yang tidak secara eksplisit
direpresentasikan dalam data model). Agar dapat mengetahui indikasi dari titik mulai dan akhir
grafik, akan sangat berguna bila dilakukan pendefinisian dari masukan dan keluaran nodes.
Bila nodes telah diidentifikasi, hubungan dan bobot hubungan akan dapat ditetapkan.
Hubungan harus diberi nama, walaupun hubungan yang merepresentasikan alur kendali antar
obyek program sebenarnya tidak butuh diberi nama. Pada banyak kasus, model grafik mungkin
mempunyai loops (yaitu, jalur pada grafik yang terdiri dari satu atau lebih nodes, dan diakses
lebih dari satu kali iterasi). Loop testing dapat diterapkan pada tingkat black box. Grafik akan
menuntun dalam mengidentifikasi loops yang perlu dites. Bila nodes telah diidentifikasi,
hubungan dan bobot hubungan akan dapat ditetapkan. Hubungan harus diberi nama, walaupun
hubungan yang merepresentasikan alur kendali antar obyek program sebenarnya tidak butuh
diberi nama. Pada banyak kasus, model grafik mungkin mempunyai loops (yaitu, jalur pada
91
grafik yang terdiri dari satu atau lebih nodes, dan diakses lebih dari satu kali iterasi). Loop
testing dapat diterapkan pada tingkat black box. Grafik akan menuntun dalam mengidentifikasi
loops yang perlu dites.
b. Equivalence Partitioning
Equivalence partitioning adalah metode pengujian black-box yg memecah atau
membagi domain input dariprogram ke dalam kelas-kelas data sehingga test case dapat
diperoleh.
Perancangan test case equivalence partitioning berdasarkan evaluasi kelas
equivalence untuk kondisi input ygmenggambarkan kumpulan keadaan yg valid atau tidak.
Kondisi input dapat berupa nilai numeric, range nilai,kumpulan nilai yg berhubungan atau
kondisi Boolean.
Contoh :
Pemeliharaan data untuk aplikasi bank yg sudah diotomatisasikan. Pemakai dapat
memutar nomor telepon bank dengan menggunakan mikro komputer yg terhubung dengan
password yg telah ditentukan dan diikuti denganperintah-perintah. Data yg diterima adalah :
Kode area : kosong atau 3 digit
Prefix : 3 digit atau tidak diawali 0 atau 1
Suffix : 4 digit
Password : 6 digit alfanumerik
Perintah : check, deposit, dan lain-lain
Selanjutnya kondisi input digabungkan dengan masing-masing data elemen dapat ditentukan
sebagai berikut :
Kode area : kondisi input, Boolean – kode area mungkin ada atau tidak kondisi input, range –
nilai ditentukan antara 200 dan 999
Prefix : kondisi input range > 200 atau tidak diawali 0 atau 1Suffix : kondisi input nilai 4
digit
Password : kondisi input boolean – pw mungkin diperlukan atau tidak kondisi input nilai
dengan 6 karakter string
Perintah : kondisi input set berisi perintah-perintah yang telah didefinisikan
c. Boundary Value Analysis
Untuk permasalahan yg tidak diketahui dengan jelas cenderung menimbulkan
kesalahan pada domain outputnya. BVAmerupakan pilihan test case yg mengerjakan nilai yg
92
telah ditentukan, dgn teknik perancangan test casemelengkapi test case equivalence
partitioning yg fokusnya pada domain input. BVA fokusnya pada domainoutput.
Petunjuk pengujian BVA :
1. Jika kondisi input berupa range yg dibatasi nilai a dan b, test case harus dirancang
dengan nilai a dan b.
2. Jika kondisi input ditentukan dgn sejumlah nilai, test case harus dikembangkan dengan
mengerjakan sampaibatas maksimal nilai tsb.
3. Sesuai petunjuk 1 dan 2 untuk kondisi output dirancang test case sampai jumlah
maksimal.
4. Untuk struktur data pada program harus dirancang sampai batas kemampuan.
TESTING UNTUK LINGKUNGAN, ARSITEKTUR, APLIKASI YANG KHUSUS
Pada saat perangkat lunak komputer menjadi semakin kompleks, maka kebutuhan akan
pendekatan pengujian yang khusus juga makin berkembang.
d. Pengujian Grafical User Interface (GUI)
Grafical User Interface(GUIs) menyajikan tantangan yang menarik bagi para
perekayasa. Karenakomponen reusable berfungsi sebagai bagian dari lingkungan
pengembangan GUS, pembuatan interface pemakaitelah menjadi hemat waktu dan lebih
teliti.Pertanyaan berikut ini dapat berfungsi sebagai panduan untuk serangkaian pengujian
generik untuk GUI:
Misalnya:
- Pengujian GUI untuk Windows
- Pengujian GUI untuk operasi Mouse
- Pengujian GUI untuk entri data
Karena GUI modern memiliki bentuk dan cita rasa yang sama maka dapat dilakukan sederetan
pengujian standar. Pertanyaan berikut dapat berfungsi sebagai panduan untuk serangkaian
pengujian generik untuk GUI :
Untuk windows :
• Apakah window akan membuka secara tepat berdasarkan tipe yang sesuai atau perintah
• berbasis menu ?
• Dapatkah window di-resize, digerakkan atau digulung ?
93
• Apakah semua isi data yang diisikan pada window dapat dituju dengan tepat
dengansebuah
• mouse, function keys, anak panah penunjuk dan keyboard ?
• Apakah window dengan cepat muncul kembali bila dia ditindih dan kemudian dipanggil
lagi ?
• Apakah semua fungsi yang berhubungan dengan window dapat diperoleh bila diperlukan
?
• Apakah semua fungsi yang berhubungan dengan window operasional
• Apakah semua menu pull down, tool bar,scroll bar, kotak dialog, tombol ikon dan kontrol
• yang lain dapat diperoleh dan dengan tepat ditampilkan untu window tersebut ?
• Pada saat window bertingkat ditampilkan, apakah nama window tersebut
direpresentasikan secara tepat ?
• Apakah window yang aktif disorot secara tepat ?
• Bila multitasking digunakan, apakah semua window diperbarui pada waktu yang sesuai ?
• Apakah pemilihan mouse bertingkat atau tidak benar di dalam window menyebabkan efek
samping yang tidak diharapkan ?
• Apakah audio prompt dan atau color prompt ada di dala window atau sebagai
konsekuensi dari operasi windows disaajikan menurut spesifikasi ?
• Apakah window akan menutup secara tepat ?
Untuk menu pull down dan operasi mouse :
• Apakah menu bar yang sesuai ditampilkan di dalam konteks yang sesuai ?
• Apakah menu bar aplikasi menampilkan fitur-fitur yang terkait dengan sistem (misal
tampilan jam ) ?
• Apakah operasi menu pull down bekerja secara tepat ?
• Apakah menu breakway, palette dan tool bar bekerja secara tepat ?
• Apakah semua fungsi menu dan subfungsi pulldown didaftar secara tepat ?
• Apakah semua fungsi menu dapat dituju secara tepat oleh mouse ?
• Apakah typface, ukuran dan format teks benar ?
• Mungkinkah memanggil masing-masing fungsi menu denganmenggunakan perintah
berbasis teks alternatif ?
• Apakah fungsi menu disorot berdasarkan konteks operasi ang sedang berlangsung di
dalam suatu window ?
• Apakah semua menu function bekerja seperti diiklankan ?
• Apakah nama-nama menu funvtion bersifat self explanatory ?
• Apakah help dapat diperoleh untuk masing-masing item menu, apakah dia sensitif
terhadap konteks ?
94
• Apakah operasi mouse dikenali dnegna baik pada seluruh konteks interaktif ?
• Bila klik ganda diperlukan, apakah operasi dikenali di dalam konteks ?
• Jika mouse mempunyai tombol ganda, apakah tombol itu dikenali sesuai konteks ?
• Apakah kursor, indikator permosesan (seperti jam) dan pointer secara tepat berubah
pada saat operasi yang berbeda dipanggil ?
Entri Data :
• Apakah entri data alfanumeris dipantulkan dan diinput ke sistem ?
• Apakah mode grafik dari entri (misal, slide bar) bekerja dengan baik ?
• Apakah data invalid dikenali dengan baik ?
• Apakah pesan input data sangat pintar ?
Sebagai tambahan untuk pedoman tersebut, grafik pemodelan keadaan yang terbatas dapat
digunakan untuk melakukan sederetan pengujian yang menekankan objek program dan data
spesifik yang relevan dengan GUI. Karena sejumlah besar permutasi yang bekesesuaian dengan
operasi GUI, maka pengujian harus didekati denga menggunakan peranti otomatis. Sudah
banyak peranti pengujian GUI yang muncul dipasaran selama beberapa tahun terakhir.
e. Pengujian Arsitektur Client Server
Arsitektur client/server (C/S) menghadirkan tantangan yang berarti bagi para
penguji perangkat lunakan. Sifat terdistribusi dari lingkungan client/server, masalah kinerja
yang berhubungan dengan pemrosesan transaksi, kehadiran potensial dari sejumlah platform
perangkat keras yang berbeda, kompleksitas komunikasi jaringan,kebutuahn aka layanan client
multipel dari suatu database terpusat dan persyaratan koordinasi yang dibebabkan pada server,
semua secara bersama-sama membuat pengujian terhadap arsitektur C/S dan perangkat lunak
yang ada didalamnya menjadi jauh lebih sulit daripada pengujian aplikasi yang berdiri sendiri.
Kenyataannya studi industri terakhir menunjukkan pertambahan berarti di dalam waktu
pengujian dan biaya ketika lingkungan C/S dikembangkan.
f. Pengujian Dokumentasi dan Fasilitas Help
Istilah “pengujianperangkat lunak” memunculkan citra terhdapa sejumlah besar
test case yang disiapkan untuk menggunakan program komputer dan data yang dimanipulasi
oleh program. Dengan melihat kembali definisi perangkat lunak yang disajikan di awal, penting
untuk dicatat bahwa pengujian harus berkembang ke elemen ketiga dari konfigurasi perangkat
lunak, yaitu “dokumentasi”.
95
Kesalahan data dokumentasi dapat menghancurkan penerimaan program seperti
halnya kesalahan pada data atu kode sumber. Tidak ada yang lebih membuat frustasi dibanding
mengikuti tuntuan pemakai secara tepat dan mendapatkan hasil atau tingkah laku yang tidak
sesuai dengan yang diprediksi oleh dokumen. Karena itulah pengujian dokumentasi harus
menjadi suatu bagian yang berarti dari setiap rencana pengujian perangkat lunak.
Pengujian dokumentasi dapat didekati dalam dua fase. Fase pertama, kajian teknis
formal yang menguji kejelasan editorial dokumen. Fase kedua, live test, menggunakan
dokumentasi dalam kaitannya dengan penggunaan program aktual.
Live test untuk dokumentasi dapat didekati dengan menggunaka teknik yang
analog dnegan berbagai metode pengujian black box. Pengujian graph-based ddapat digunakan
untuk menggambarkan penggunaan program tersebut; partisi ekivalensi dan analisis nilai batas
dapat digunakan untuk menentukan berbagai kelas input dan interaksi yang sesuai. Kegunaan
program kemudian ditelusuri pada seluruh dokumen :
• Apakah dokumen tersebut secara akurat menggambarkan bagimana menyelesaikan
masing-masing mode penggunaan ?
• Apakah deskripsi dari masing-masing urutan interaksi akurat ?
• Apakah contoh-contoh akurat ?
• Apakah terminologi, gambaran menu dan respon sistem konsisten dengan program aktual?
• Apakah relatif mudah untuk menempatkan panduan di dalam dokumentasi ?
• Dapatkah trouble shooting dilakukan dnegan mudah dnegan dokumentasi ?
• Apakah tabel dokumen dari isi dan indeks akurat dan lengkap ?
• Apakah desain dokumen (layout, typeface, indetasi, grafik) kondusif untuk pemahaman
dan asimilasi cepat terhadap informasi ?
• Apakah semua pesan kesalahan ditampilkan bagi pemakai dan digambarkan secara lebih
detail di dalam dokumen ?
• Bila link hiperteks digunakan, apakah mereka akurat dan lengkap ?
Satu-satunya cara yang dapat berjalan untuk menjawab pertanyaan-pertanyaan tersebut
adalah dengan menggunakan bagian ketiga yang independen (misal : pemakai yang diseleksi)
yang menguji dokumentasi di dalam konteks kegunaan program. Semua diskrepansi dicatat dan
area ambiguitas atau kelemahan dokumen ditentuka untuk penulisan ulang yang potensial.
g. Pengujian Sistem Real-Time
Sifat asinkron dan tergantung waktu yang ada pada banyak aplikasi real time
menambahkan elemen baru yang sulit dan potensial untuk bauran pengujian-waktu. Tidak
hanya desainer teset case yang harus memeprtimbangkan test case balck box dan white box
tetapi juga penanganan kejadian (yaitu pemrosesan interupsi), timing data dan paralelisme
96
tugas-tugas (proses) yang menangani data. Pada banyak situasi, data pengujian yang diberikan
pada saat sebuah sistem real time ada dalam satu keadaan akan menghasilkan pemrosesan
yang baik, sementara data yang sama yang diberikan pada saat sistem berada dalam keadaan
yang berbeda dapat menyebabkan kesalahan.
Contohnya, perangkat lunak real time yang mengontrol alat foto kopi yang baru
menerima interupsi operator (yakni operator mesin menekan kunci kontrol seperti reset)
dengan tanpa kesalahan pada saat mesin sedang membuan kopian. Interupsi operator yang
sama ini bila diinputkan pada saat mesin ada dalam keadaan “jammed” akan menyebabkan
sebuah kode diagnostik yang menunjukkan lokasi jam yang akan hilang (kesalahan). Hubungan
erat perangkat lunak real time dan lingkungan perangkat kerasnya dapat juga menyebabkan
pengaruh kegagalan perangkat keras pada pemrosesasn perangkat lunak. Kesalahan semacam
itu dapat sangat sulit untuk bersimulasi secara realistis.
Metode desain test case yang komprehensif untuks istem real time harus
berkembang. Tetapi strategi emapat langkah berikut dapat diusulkan :
• Pengujian tugas.
Langkah pertama dalam pengujian perangkat lunak real time adalah menguji masing-
masing tugas secara independen, yaitu pengujian white box dan black box yang didesain
dan dieksekusi secara independen bagi masing-masing tugas. Masing-masing tugas
dieksekusi secara independen selama pengujian ni. Pengujian tugas mengungkap
kesalahan di dalam logika dan fungsi, tetapi tidak akan mengungkap timing atau
kesalahan tingkah laku.
• Pengujian tingkah laku.
Dengan menggunakan model yang idciptakan dengan peranti CASE, dimungkinkan untuk
mensimulasi tingkah laku sistem real time dan menguji tingkah lakunya sebagai
konsekuensi dari event eksternal. Aktivitas analisis ini dapat berfungsi sebgai dasar bagi
desain test case yang dilakukan pada saat perangkat lunak real time dibangun. Dengan
menggunak teknik yang sama dengan partisi ekuivalensi, event-event (misal interupsi,
signal, kontrol, data) dikategorikan untuk pengujian. Sebagai contoh, event untuk mesin
fotokopi dapat merupakan inerupsi pemakai (misal, pencacah reset), interupsi mekanis
(misal, paper jammed), interupsi sistem (misal tone rendah) dan mode kegagalan (misal
roller yang terlalu panas). Masing-masing event tersebut diuji secara individual dan
tingkah laku sistem yang dapat dieksekusi diperiksa untuk mendeteksi kesalahan yang
terjadi sebagai akibat pemrosesasn yang terkait denga event tersebut. Perilaku model
sisetm (dikembangkan selama aktivias analisis) dan perangkat lunaka yang dapat
dieksekusi dapat dibandingkan untuk penyesuaian. Sekali masing-masing kelas event
97
telah diuji,maka event-event disajikan pada sistem dalam urutan acak dan dengan
frekuensi acak. Perilaku sistem diuji untuk mendeteksi kesalahan perilaku.
• Pengujian antar tugas
Setelah kesalahan-keaslahan pada tugas individual dan pada perilaku sistem diisolasi,
maka pengujian beralih kepada kesalahan yang berkaitan dengan waktu. Tugas-tugas
asinkronous yang dikenali untuk saling berkomunikasi diuji dnegna tingkat data yang
berbeda dan pemrosesan dipanggil untuk menentukan apakah kesalahan sinkronisasi
antar tugas akan terjadi. Sebagai tambahan, tugas-tugas yang berkomuniaksi melalui
antrian pesan atau penyimpanan data, diuji untuk menemukan kesalahan dalam ukuran
area penyimpanan data tersebut.
• Pengujian sistem
Perangkat lunak dan perangkat keras diintegrasi dan suatu rentang penuh dari pengujian
sistem dilakukan di dalam usahan mengungkap keslahan pada interface perangkat
lunak/perangkat keras.
Sebagian besar sitem real time memproses interupsi, karena itu pengujian penanganan
terhadap kejadian-kejadian. Boolean merupakan hal yang penting. Dengan menggunakan
diagram keadaan transisi dan spesifikasi kontrol, penguji mengembangkan daftar semua
interupsi yang mungkin dan pemroesan yang terjadi sebagai konsekuensi dari interupsi.
Kemudian pengujian didesain untuk menilai karakteristik sistem berikut ini :
- Apakah priortias interupsi ditetapkan dan ditangani secara tepat ?
- Apakah pemrosesan untuk masing-masing interupsi ditangani dengan tepat ?
- Apakah kinerja (misal waktu pemrosesasn) dari masing-masing prosedur penangan
interupsi sesuai dengan persyaratan ) ?
- Apakah volume interupsi yang tinggi yang terjadi pada waktu kritis menimbulkan
masalah di dalam fungsi atau kinerja ?
Sebagai tambahan, area data global juga digunakan untuk mentransfe informasi sebagai bagian
dari pemrosesan interupsi yang harus diuji untuk menilai potensi munculnya efek samping.
98
BAB 8 STRATEGI PENGUJIAN PERANGKAT LUNAK
A. PENDEKATAN STRATEGIS KE PENGUJIAN PERANGKAT LUNAK
Strategi uji coba perangkat lunak memudahkan para perancang untuk menentukan
keberhasilan system yg telah dikerjakan. Hal yg harus diperhatikan adalah langkah-langkah
perencanaan dan pelaksanaan harus direncanakan dengan baik dan berapa lama waktu, upaya
dan sumber daya yg diperlukan. Strategi uji coba mempunyai karakteristik sebagai berikut :
- Pengujian mulai pada tingkat modul yg paling bawah, dilanjutkan dgn modul di atasnya
kemudian hasilnya dipadukan.
- Teknik pengujian yang berbeda mungkin menghasilakn sedikit perbedaan (dalam hal
waktu)
- Pengujian dilakukan oleh pengembang Software 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 satu elemen dari topik yang lebih luas yang sering diacu
sebagai verifikasi dan validasi (V dan V).
Verifikasi : Kumpulan aktifitas yg menjamin penerapan Perangkat Lunak benar-benar
sesuai dengan fungsinya.
Validasi : Kumpulan aktivitas yang berbeda yang memastikan bahwa Perangkat Lunak
yang dibangun dapat memenuhi keperluan pelanggan.
Dengan kata lain :
Verifikasi : “ Apakah kita membuat produk dgn benar?”
Validasi : “ Apakah kita membuat benar-benar suatu produk?”
Definisi dari VdanV meliputi berbagai aktivitas yang kita rujuk sebagai jaminan kualias PL
(SQA).Pengujian merupakan salah satu tugas yg ada dlm arus siklus
pengembangan system yg dapat digambarkan dalam bentuk spiral :
99
Langkah-langkah Pengujian Software
Terdapat 4 langkah yaitu:
• Unit testing-testing per unit yaitu mencoba alur yang spesifik pada struktur modul
kontrol untuk memastikan pelengkapan secara penuh dan pendeteksian error secara
maksimum
• Integration testing –testing per penggabungan unit yaitu pengalamatan dari isu-isu
yang diasosiasikan dengan masalah ganda pada verifikasi dan konstruksi program
• High-order test yaitu terjadi ketika software telah selesai diintegrasikan atau dibangun
menjadi satu –tidak terpisah-pisah
• Validation test yaitu menyediakan jaminan akhir bahwa software memenuhi semua
kebutuhan fungsional, kepribadian dan performa.
B. MASALAH-MASALAH STRATEGIS
Tom Gilb menyatakan bahwa masalah-masalah berikut harus diselesaikan bila strategi
pengujian perangkat lunak yang sukses akan dipublikasikan.
1. Menetapkan seluruh kebutuhan produk software dalam perhitungan sebelum memulai
testing
100
2. Status obyek testing harus jelas3. Memahami pengguna software dan mengembangkan
sebuah profil untuk setiap kategori user
3. Mengembangkan rencana testing yang menekankan pada “rapid cycle testing”
4. Membangun software yang sempurna yang didesain untuk mengetes dirinya sendiri
5. Menggunakan tinjauan ulang yang formal sebagai filter sebelum pengujian
6. Melakukan tinjauan ulang secara formal untuk menilai strategi tes dan kasus tes itu
sendiri
7. Mengembangkan pendekatan peningkatan yang berkelanjutan untuk proses testing
C. PENGUJIAN UNIT
Unit testing (uji coba unit) fokusnya pada usaha verifikasi pada unit terkecil dari desain
Perangkat Lunak, yakni modul. Ujicoba unit selalu berorientasi pada white box testing dan
dapat dikerjakan paralel ayau beruntun dengan modul lainnya. Pertimbangan Pengujian Unit
Interface modul diuji untuk memastikan bahwa informasi secara tepat mengalir masuk dan
keluar dari intiprogram yang diuji. Struktur data local diuji untuk memastikan bahwa data yang
tersimpan secara temporal dapattetap menjaga integritasnya selama semua langkah langkah di
dalam suatu algoritma dieksekusi. Kondisi batasdiuji untuk memastikan bahwa modul
beroperasi dengan tepat pada batas yang ditentukan untuk membatasipemrosesan. Semua
jalur independen(jalur dasar) yang melalui struktur control dipakai sedikirnya satu kali. Dan
akhirnya penanganan kesalan diuji.
Myers mengusulkan checklist untuk pengujian interface:
• Apakah jumlah parameter input sama dengan jumlah argumen?
• Apakah antara atribut dan parameter argumen sudah cocok?
• Apakah antara sistem satuan parameter dan argumen sudah cocok?
• Apakah jumlah argumen yang ditransmisikan ke modul yang dipanggil sama dengan
jumlahparameter?
101
• Apakah atribut dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan
atributparameter?
• Apakah sistem unit dari argumen yang ditransmisikan ke modul yang dipanggil sama
dengan sistemsatuan parameter?
• Apakah jumlah atribut dari urutan argumen ke fungsi-fungsi built-in sudah benar?
• Adakah referensi ke parameter yang tidak sesuai dengan pain entri yang ada?
• Apakah argumen input-only diubah?
• Apakah definisi variabel global konsisten dengan modul?
• Apakah batasan yang dilalui merupakan argumen?
Bila sebuah modul melakukan I/O ekstemal, maka pengujian interface tambahan harus
dilakukan.
• Atribut file sudah benar?
• Pemyataan OPEN/CLOSE sudah benar?
• Spesifikasi format sudah cocok dengan pernyataan I/O?
• Ukuran buffer sudah cocok dengan ukurn rekaman?
• File dibuka sebelum penggunaan?
• Apakah kondisi End-of-File ditangani?
• Kesalahan I/O ditangani?
• Adakah kesalahan tekstual di dalam informasi output?
Kesalahan yang umum di dalam komputasi adalah:
• Kesalah-pahaman atau prosedur aritmatik yang tidak benar
• Operasi mode yang tercampur
• Inisialisasi yang tidak benar
• Inakurasi ketelitian
• Representasi simbolis yang tidak benar dari sebuah persamaan.
Test case harus mengungkap kesalahan seperti Perbandingan tipe data yang berbeda
• Preseden atau operator logika yang tidak benar
• Pengharapan akan persamaan bila precision error membuat persamaan yang tidak
mungkin
• Perbandingan atau variabel yang tidak benar
• Penghentian loop yang tidak ada atau tidak teratur
• Kegagalan untuk keluar pada saat terjadi iterasi divergen
• Variabel loop yang dimodifikasi secara tidak teratur.
102
Prosedur Pengujian Unit
Program sumber telah dikembangkan, ditunjang kembali dan diverifikasi untuk sintaksnya,
makaperancangan test case dimulai. Peninjauan kembali perancangan informasi akan
menyediakan petunjuk untuk menentukan test case. Karena modul bukan program yg berdiri
sendiri maka driver (pengendali) dan atau stub PLharus dikembangkan untuk pengujian unit.
Driver adalah program yg menerima data untuk test case dan menyalurkan ke modul yg diuji
dan mencetak hasilnya. Stub melayani pemindahan modul yg akan dipanggil untuk diuji.
D. PENGUJIAN INTEGRASI
Pengujian terintegrasi adl teknik yg sistematis untuk penyusunan struktur program, pada
saat bersamaandikerjakan uji coba untuk memeriksa kesalahan yg nantinya digabungkan
dengan interface.
Metode pengujian integrasi :
- Top down integration
- Buttom up integration
- Top Down Integration
Merupakan pendekatan inkrmental untuk penyusunan struktur program. Modul dipadukan
dgn bergerak ke bawahmelalui kontrol hirarki dimulai dari modul utama.Modul subordinat
ke modul kontrol utama digabungkan ke dalam struktur baik menurut depth first atau
breadthfirst. Proses integrasi:
a) modul utama digunakan sebagai test driver dan stub yg menggantikan seluruh
modul yg secara langsungberada di bawah modul kontrol utama.
b) Tergantung pada pendekatan perpaduan yg dipilih (depth / breadth)
c) Uji coba dilakukan selama masing-masing modul dipadukan
d) Pada penyelesaian masing-masing uji coba stub yg lain dipindahkan dgn modul
sebenarnya.
e) Uji coba regression yaitu pengulangan pengujian untuk mencari kesalahan lain yg
mungkin muncul.
- Bottom Up Integration
Pengujian buttom up dinyatakan dgn penyusunan yg dimulai dan diujicobakan dgn
atomic modul (yi modultingkat paling bawah pd struktur program). Karena modul
dipadukan dari bawah ke atas, proses yg diperlukanuntuk modul subordinat yg selalu
diberikan harus ada dan diperlukan untuk stub yg akan dihilangkan.
103
Strategi pengujian :
· Modul tingkat bawah digabungkan ke dalam cluster yg memperlihatkan subfungsi
PL
· Driver (program kontrol pengujian) ditulis untuk mengatur input test case dan
output
· Cluster diuji
· Driver diganti dan cluster yg dikombinasikan dipindahkan ke atas pada struktur
program
E. PENGUJIAN VALIDASI
Setelah semua kesalahan diperbaiki maka langkah selanjutnya adalah validasi
terting. Pengujian validasidikatakan berhasil bila fungsi yg ada pada PL sesuai dgn yg
diharapkan pemakai.Validasi PL merupakan kumpulan seri uji coba black box yg menunjukkan
sesuai dengan yang diperlukan.
Kemungkinan kondisi setelah pengujian:
1. Karakteristik performansi fungsi sesuai dgn spesifikasi dan dapat diterima.
2. Penyimpangan dari spesifikasi ditemukan dan dibuatkan daftar penyimpangan.
- Pengujian BETA dan ALPHA
Apabila Perangkat Lunak dibuat untuk pelanggan maka dapat dilakukan aceeptance
test sehingga memungkinkan pelangganuntuk memvalidasi seluruh keperluan. Test ini
dilakukan karena memungkinkan pelanggan menemukan kesalahan yang lebih rinci dan
membiasakan pelanggan memahami Perangkat Lunak yg telah dibuat.
Pengujian Alpha Dilakukan pada sisi pengembang oleh seorang pelanggan. Perangkat
Lunak digunakan pada setting yang natural dengan pengembang “yang memandang”
melalui bahu pemakai dan merekam semua kesalahan dan masalah pemakaian.
Pengujian Beta Dilakukan pada satu atau lebih pelanggan oleh pemakai akhir Perangkat
Lunak dalam lingkungan yang sebenarnya, pengembangbiasanya tidak ada pada
pengujian ini. Pelanggan merekan semua masalah (real atau imajiner) yg ditemui
selama pengujian dan melaporkan pada pengembang pada interval waktu tertentu.
F. PENGUJIAN SISTEM
Pada akhirnya Perangkat Lunak digabungkan dengan elemen system lainnya dan
rentetan perpaduan system dan validasi tesdilakukan. Jika uji coba gagal atau di luar skope dari
proses daur siklus pengembangan system, langkah yang diambil selama perancangan dan
104
pengujian dapat diperbaiki. Keberhasilan perpaduan Perangkat Lunak dan system yang besar
merupakan kuncinya. Sistem testing merupakan rentetan pengujian yang berbeda-beda dengan
tujuan utama mengerjakan keseluruhan elemen system yang dikembangkan.
Pengujian Perbaikan
Adalah system testing yg memaksa Perangkat Lunak mengalami kegagalan dalam bermacam-
macam cara dan memeriksaapakah perbaikan dilakukan dgn tepat.
Pengujian Keamanan
Adalah pengujian yg akan melalukan verifikasi dari mekanisme perlindungan yg akan dibuat
oleh system,melindungi dari hal-hal yg mungkin terjadi.
Pengujian stress
Dirancang untuk menghadapi situasi yg tidak normal pada saat program diuji. Testing ini
dilakukan oleh systemuntuk kondisi seperti volume data yg tidak normal (melebihi atau kurang
dari batasan) atau fekuensi
Pengujian kinerja
Didesain untuk menguji kinerja run-time dari perangkat lunak didalam konteks sistem yang
terintegrasi. Pengujian kinerja terjadi pada seluruh langkah dalam proses pengujian. Bahkan
pada tingkat unit, kinerja modul individual dapat diperkirakan pada saat pengujian white-box
dilakukan.
G. PENGUJIAN DEBUGGING
Debugging adalah sebuah metode yang dilakukan oleh para pemrogram dan
pengembang perangkat lunak untuk mencari dan mengurangi bug, atau kerusakan di dalam
sebuah program komputer atau perangkat keras sehingga perangkat tersebut bekerja sesuai
dengan harapan. Debugging cenderung lebih rumit ketika beberapa subsistem lainnya terikat
dengan ketat dengannya, mengingat sebuah perubahan di satu sisi, mungkin dapat
menyebabkan munculnya bug lain di dalam subsistem lainnya.
Bug dengan terjemahan langsung ke bahasa Indonesia adalah serangga atau kutu. Bug
merupakan suatu kesalahan desain pada suatu perangkat keras komputer atau perangkat lunak
komputer yang menyebabkan peralatan atau program itu tidak berfungsi semestinya. Bug
umumnya lebih umum dalam dunia perangkat lunak dibandingkan dengan perangkat keras.
Debugging adalah proses menghilangkan bug dari suatu program. Pengujian perangkat
lunak adalah proses yang dapat direncanakan dan ditentukan secara sistematis. Desain test
case dapat dilakukan, strategi dapat ditentukan, dan hasil dapat dievaluasi berdasarkan
harapan-harapan yang ditentukan sebelumnya. Debugging terjadi sebagai akibat dari pengujian
yang berhasil. Jika test case mengungkap kesalahan, maka debugging adalah proses yang
105
menghasilkan penghilangan kesalahan. Perekayasa perangkat lunak yang mengevaluasi hasil
suatu pengujian sering dihadapkan pada indikasi “simtomatis” dari suatu masalah pernagkat
lunak, yaitu bahwa manisfestasi eksternaldari kesalahan dan penyebab internal kesalahan dapat
tidak memiliki hubungan yang jelas satu dengan lainnya. Proses mental yang dipahami secara
buruk yang menghubungkan sebuah symptom dengan suatu penyebab disebut debugging.
• Proses Debugging
Debugging bukan merupakan pengujian, tetapi selalu terjadi sebagai bagian akibat dari
pengujian. Proses debungging dimulai dengan eksekusi terhadap suatu test case. Hasilnya
dinilai, dan ditemukan kurangnya hubungan antara harapan dan yang sesungguhnya. Dalam
banyak kasus, data yang tidak berkaitan merupakan gejala dari suatu penyebab pokok tetapi
masih tersembunyi, sehingga perlu ada koreksi kesalahan.
Proses debugging akan selalu memiliki salah satu dari dua hasil akhir berikut:
1. Penyebab akan ditemukan, dikoreksi, dan dihilangkan, atau
2. Penyebab tidak akan ditemukan.
Dalam kasus yang terakhir, orang yang melakukan debugging mungkin mencurigai suatu
penyebab, mendesainsuatu test case untuk membantu kecurigaannya, dan bekerja untuk
koreksi kesalahan dengan gaya yang iterative.
Beberapa karakteristik bug memberi kunci :
1. Gejala dan penyebab dapat jauh secara geografis, dimana gejala dapat muncul
didalam satu bagian dari suatu program, sementara penyebab dapat ditempatkan
pada suatu sisi yang terlepas jauh.
2. Gejala dapat hilang (kadang-kadang) ketika kesalahan yang lain dibetulkan.
3. Gejala dapat benar-benar disebabkan oleh sesuatu yang tidak salah (misalnya
pembulatan yang tidak akurat).
4. Simpton dapat disebabkan oleh kesalahan manusia yang tidak dapat dengan mudah
ditelusuri.
5. Gejala dapat merupakan hasil dari masalah timing, dan bukan dari masalah
pemrosesan.
6. Mungkin sulit untuk mereproduksi kondisi input secara akurat (misalnya aplikasi real
time dimana pengurutan input tidak ditentukan).
7. Gejala dapat sebentar-sebentar. Hal ini sangat umum pada system yang embedded
yang merangkai perangkat lunak dan perangkat keras yang tidak mungkin dilepaskan.
106
8. Gejala dapat berhubungan dengan penyebab yang didistribusikan melewati sejumlah
tugas yang bekerja pada prosesor yang berbeda.
Selama debugging, kita menemukan kesalahan-kesalahan mulai dari gangguan yang
halus (missal format output yang tidak betul) sampai katrastropis (misalnya kegagalan system
yang menyebabkan kerusakan fisik atau ekonomis).
Sebagai akibat dari peningkatan keslahan, jumlah tekanan untuk menemukan kesalahan
juga bertambah. Sering kali tekanan memaksa seorang pengembang perangkat lunak untuk
membetulkan kesalahan dan pada saat yang sama memunculkan lagi dua kesalahan baru.
• Pertimbangan Psikologis
Sayangnya muncul banyak bukti bahwa kekuatan debugging adalah sifat bawaan
manusia. Banyak orang yang cakap dalam hal ini, sementara banyak juga yang tidak.
Menanggapi aspek manusia dari debugging. Shneiderman [SHN80] menyatakan :
Debugging merupakan salah satu dari berbagai bagian pemrograman yang membuat
lebih frustasi. Debugging memiliki elemen pemecahan masalah atau pengganggu otak, yang
bersama dengan penghindaran kesadaran bahwa Anda melakukan suatu kesalahan.
Kekhawatiran yang meningkat dan keengganan untuk menerima, kesalahan akan meningkatkan
kesulitan tugas. Meskipun mungkin sulit untuk mempelajari debugging, sejumlah pendekatan
terhadap masalah tersebut dapat diusulkan. Kita akan melihat dalam sub bab selanjutnya.
• Pendekatan-pendekatan Debugging
Tanpa memperhatikan pendekatan yang diambil, debugging memiliki satu sasaran yang
diabaikan, untuk menemukan dan mengkoreksi penyebab kesalahan perangkat lunak. Sasaran
tersebut direalisasi dengan suatu kombinasi evaluasi yang sistematis, intuisi, dan
keberuntungan.
Bradley (BRA85) menggambarkan pendekatan Debugging dengan cara berikut :
Debugging adalah sebuah aplikasi langsung dari metodekeilmuan yang telah
dikembangkan selama 2500 tahun. Dasar dari debugging adalah meletakkan sumber-sumber
masalah (penyebab) dengan partisi biner melalui hipotesis kerja yang memperkirakan nilai-nilai
baru yang akan diuji.
Ambillah contoh non-perangkat lunak sederhana, yaitu :
Lampu dirumah saya tidak bekerja. Bila tidak ada yang bekerja didalam rumah itu,
penyebabnya tentu pada pemutus rangkaian utama atau sebab dari luar. Saya melihat
sekeliling untuk melihat apakah lampu para tetangga juga mati. Saya memasukkan lampu yang
dicurigai kedalam soket yang bekerja dan menyelidiki lampu rangkaian yang dicurigai. Begitulah
berbagai pilihan hipotesa dan pengujian.
Secara umum, tiga kategori pendekatan debugging dapat diusulkan (MYE79) :
107
1. Gaya yang kasar (Brute force)
Kategori debugging brute force mungkin merupakan yang paling umum dan metode yang
paling efisien untuk mengisolasi penyebab kesalahan perangkat lunak. Kita mengaplikasikan
metode debugging brute force bila semua yang lain telah gagal. Dengan menggunakan filosofi
”biarkan komputer menemukan kesalahan”, tempat sampah memori dipakai, penelusuran
runtime dilakukan, dan program dibebani dengan statemen WRITE. Kita mengharapkan bahwa
dimanapun didalam rawa informasi yang diproduksi, kita akan menemukan suatu kunci yang
akan membawa kita kepada penyebab kesalahan. Meskipun banyaknya informasi yang
dihasilkan pada akhirnya akan membawa kita meraih sukses, lebih sering dia menyebabkan kita
menghambur-hamburkan usaha dan waktu. Kita harus memikirkannya terlebih dahulu.
2. Penelusuran balik (backtracking)
Backtracking adalah pendekatan debugging yang sangat umum yang dapat digunakan
secara sukses didalam program yang kecil. Mulai pada sisi dimana suatu gejala diungkap, kode
sumber ditelusuri balik (secara manual) samapai sisi penyebab ditemukan. Sayangnya, bila
jumlah baris sumber bertambah, maka jumlah jalur balik potensial dapat sangat banyak.
3. Eliminasi penyebab
Cause elimination dimanisfestasikan oleh induksi atau deduksi serta mengawali konsep
partisi biner. Data yang berhubungan dengan kejadian kesalahan dikumpulkan untuk
mengisolasi penyebab potensial. Hipotesis penyebab dibuat dan data digunakan untuk
membuktikan penolakan hipotesis tersebut. Sebagai alternatif, daftar semua penyebab yang
mungkin dikembangkan dan dilakukan pengujian untuk mengeliminasi masing-masing
kesalahan. Jika pengujian awal menunjukkan bahwa suatu hipotesis penyebab memberikan
gambaran hasil yang jelas, maka data itu disaring sebagai usaha untuk mengisolasi bug.
Masing-masing pendekatan debugging tersebut dapat ditambah dengan piranti
debugging. Kita dapat mengaplikasikan berbagai kompiler debugging yang luas, bantuan
debugging yang dinamis (tracer), generator test case, ruang sisa memori dan peta cross-
reference. Namun piranti bukanlah pengganti bagi evaluasi yang berhati-hati yang didasarkan
atas dokumen desain perangkat lunak yang lengkap dan kode sumber yang jelas.
Sekali bug ditemukan, bug harus dibetulkan. Tetapi seperti telah kita catat, koreksi
terhadap suatu bug dapat memunculkan kesalahan lain sehingga lebih banyak merugikan
daripada menguntungkan.
108
Van Vleck (FAN89) mengusulkan tiga pertanyaan sederhana yang harus diajukan kepada
perekayasa perangkat lunak sebelum melakukan koreksi yang menghilangkan penyebab suatu
bug, yaitu :
1. Apakah penyebab bug direproduksi didalam bagian lain program tersebut?
Dalam berbagai situasi, kesalahan program disebabkan oleh sebuah contoh logika yang
keliru yang dapat dibuat ulang ditempat lain. Pertimbangan eksplisit dari contoh logika tersebut
akan menghasilkan penemuan kesalahan yang lain.
2. Apa ”bug selanjutnya,” yang akan dimunculkan oleh perbaikan yang akan dibuat?
Sebelum koreksi dibuat, kode sumber (atau lebih baik,desain) harus dievaluasi untuk
memperkirakan pemasangan logika dan struktur data. Bila koreksi akan dilakukan pada bagian
program yang akan dirangkai, maka harus ada perhatian khusus bila banyak perubahan
dilakukan.
3. Apa yang dapat kita lakukan untuk menghindari bug ini didalam tempat pertama?
Pertanyaan ini merupakan langkah pertama untuk membangun pendekatan jaminan
kualitas perangkat lunak statistik. Bila kita mengkoreksi proses dan produk, bug akan
dihilangkan dari program yang ada dan dapat dieliminasi dari semua program selanjutnya.
109
BAB 9 OBJECT ORIENTED SOFTWARE ENGINEERING
A. KONSEP DAN PRINSIP OBJECT ORIENTED
Objek dapat dikategorikan, digambarkan, diatur, digabungkan, dimanipulasi dan
diciptakan. Dengan demikian, tidak mengherankan jika diusulkan pandangan berorientasi objek
untuk pembuatan perangkat lunak komputer – abstraksi yang memodelkan dunia dengan cara
yang membantu kita untuk lebih memahami dan mengendalikannya.
Pendekatan berorientasi objek ke pengembangan perangkat lunak pertama kali
diusulkan pada akhir tahun 1960-an. Rekayasa perangkat lunak berorientasi objek menjadi
paradigma pilihan bagi berbagai pembangun produk perangkat lunak dan sejumlah sistem
informasi yang sedang berkembang serta profesional rekayasa.
Teknologi objek membawa kepada penggunaan kembali, dan penggunaan kembali
membawa kepada pengembangan perangkat lunak yang lebih cepat dan program yang
berkualitas lebih tinggi. Perangkat lunak berorientasi objek lebih mudah dipelihara karena
strukturnya diurai secara inheren. Sehingga lebih sedikit efek samping dibanding bila perubahan
harus dilakukan. Dan tidak begitu membuat frustasi perekayasa perangkat lunak dan
pelanggan. Sistem berorientasi objek juga lebih mudah untuk disesuaikan dan lebih mudah
untuk diskala.
1. Paradigma Berorientasi Objek
Berorientasi Objek Merupakan paradigma baru dalam rekayasa perangkat lunak
yang memandang system sebagai kumpulan obyek-obyek diskrit yang saling berinteraksi satu
sama lain.
Faktor utama dari ditemukannya pendekatan berorientasi objek adalah karena
ditemukannya kekurangan-kekurangan pada pendekatan struktur: biaya pengembangan
perangkat lunak berkembang sesuai dengan berkembangnyakeinginan atau kebutuhan
pengguna, pemeliharaan yang sukar, lamanya penyelesaian suatu proyek, jangka waktu
penyelesaian proyek yang hampir selalu terlambat, biaya pengembangan perangkat lunak yang
sangat tinggi. Pendekatan berorientasi objek membuat data terbungkus pada setiap fungsi atau
prosedur dan melindunginya terhadap perubahan tidak dikendaki dari fungsi yang berada
diluar.
110
Beberapa karakteristik yang menjadi ciri-ciri pendekatan objek adalah:
1) Pendekatan lebih pada data dan bukannya pada prosedur atau fungsi.
2) Program besar dibagi pada apa yang dinamakan objek-objek.
3) Strukur data dirancang dan menjadi karakteristik dari objek-objek.
4) Fungsi-fungsi yang mengoperasikan data tergabung dalam suatu objek yang sama.
5) Data tersembunyi dan terlindung dari fungsi atau prosedur yang ada diluar
6) Objek-objek dapat saling berkomunikasi dengan saling mengirim message (pesan)
satu sama lain.
7) Pendekatan adalah dari bawah ke atas (bottom up approach).
Dibawah ini adalah penggambaran dari pendekatan berorientasi objek.
Gambar Pengorganisasian Data Serta Fungsi Pada Pendekatan Berorientasi Objek
MENGAPA BERORIENTASI OBYEK ??
Karena :
• Dapat membagi aplikasi ke dalam potongan kecil yang banyak, independen satu sama
lain, potongan-potongan kecil tersebut disebut obyek.
• Dapat membangun aplikasi dengan menyusun obyek-obyek ini bersama-sama untuk
membentuk satu kesatuan aplikasi
• Memiliki kemampuan untuk membangun komponen sekali saja, kemudian
menggunakannya berulang-ulang.
111
2. Konsep Object Oriented
Sembilan konsep object Oriented adalah :
1. Objek
Apakah obyek itu? Semua benda yang ada didunia ini dapat kita
sebutsebagai obyek. Guru mata pelajaran RPL kalian adalah suatu obyek.
Buku yang kalian pegang ini juga suatu obyek. Bahkan mata pelajaran RPL
adalah juga sebuah obyek. Setiap obyek akan mempunyai karakteristik dan
tingkah laku tertentu. Karakteristik disebut attribute dan tingkah laku disebut
sebagai behavior atau method.
Object mempresentasikan sebuah entitas, baik secar fisik, konsep
ataupun secara s.w Sebuah konsep, abstraksi atau sesuatu yang diberi
batasan jelas dan dimaksudkan untuk sebuah aplikasi Mempunyai keadaan,
kelakukan dan identitas. Keadaan objek adalah satu dari kondisi yang
memungkinkan dimana objek dapat muncul, dan dapat secara normal
berubah berdasarkan waktu Keadaan dari objek biasanya diimplementasikan
dengan kelompok propertinya (atribut) berisi nilai dari properti tsb, & relasi
dengan objek lain.
Kelakukan dari objek mendeskripsikan segala sesuatu yang dapat
dilakukan oleh objek untuk kita. Objek memiliki identitas yg unik Membedakan
dua objek yg berbeda, walaupun kedua objek tersebut mempunyai keadaan
dan nilai yang sama pada atributnya. Objek mempunyai 3 identitas yg penting
State
Behaviour
Identity
Identitas adalah properti objek yang membedakan dirinya dari semua objek
yang lain.
Sta
Sta
ada
Pro
pro
►
ate Mempuny
ate objek me
a pd saat itu
operties = cir
operties.
Example of
Behaviour
yaitu ba
mengirimka
member fun
Object Beh
yai suatu ciri
liputi semua
(dinamis) dar
ri yg kelihata
object state
agaimana obj
an ke objek la
nction
haviour
khusus, meni
properti obje
ri masing-mas
n & membed
jek bereaksi
ain. Pada prog
identifikasi se
ek (biasanya s
sing properti.
dakan dengan
dab bereaksi
gramming di
esuatu mempu
statis) Ditam
n objek lain, v
terhadap ob
implementasi
unyai propert
bah dengan n
value = diaso
bjek lain, dan
ikan dengan
112
ti dan value.
nilai-nilai yg
osiasikan ke
bagaimana
method dan
Identity
Properti dar
lain, jika obj
Hubungan
• Berelas
– Acto
dap
– Serv
– Age
• Ex : me
Relationship
2. Ke
ri objek yg m
jek dibuat ma
n antar objek
si antara
or = sebuah
pat di akses,
ver = sebuah
ent = dapat a
esin mobil yg
ps Objects
elas
embedakan d
aka identiti ak
ek
objek dapat m
h objek yg han
kses dan diak
terdiri dari b
dari objek lain
kan muncul.
mengakses su
nya dpt diaks
kses
banyak elemen
n. Menunjuk s
uatu objek te
es objek lain
n piston, plug
suatu referen
etapi objek te
g, carburator,
113
nce ke objek
rsebut tidak
dll
tip
se
sa
sa
Cl
ka
Ex
Pr
se
Hi
Class me
pe data abstr
ecara parsial
ama (atribut),
ama.
ass adalah
arakteristik yg
x : kelas kursu
ropertinya /
eperti kelakua
rarki Kelas
erupakan blo
rak yg dileng
dan total. D
, kelakukan y
sebuah hasi
g sejenis dgn
us
atributnya :
an (operasi) se
ok pembangu
kapi sarana u
Deskripsi dari
yg sama (op
l abstraksi
mengabaikan
lokasi, hari,
eperti add sis
nan terpentin
untuk dapat
kelompok ob
erasi) dan re
dari sesuatu
n karakteristik
waktu, tutor
swa, kurang s
ng pd OO. C
melakukan im
bjek dengan
elationship /
dgn meng
k lainnya.
r, dan kelaku
siswa, jadwal
114
Class adalah
mplementasi
properti yg
simantik yg
elompokkan
uan operasi
kursus, dll
115
Class menciptakan perbedaan visvibility ;
Public : dapat dilihat oleh siapapun
Protected : dapat dilihat oleh object turunannya
Private : hanya oleh class
Properti class
• Nama : class harus memiliki nama yg membedakan dari class lain
• Tanggung jawab : kelas mempunyai tanggung jawab, kelas berisi
sejumlah atribut dan operasi yg diemban untuk dilaksanakan
• Atribut : dapat memiliki sejumlah atribut atau tidak sama sekali,
mempersentasikan suatu properti dari sesuatu yg dimodelkan
• Operasi : implementasi layanan, abstraksi dari sesuatu yg dapat
dilakukan objek
Perbedaan class dan objek ; objek merupakan entitas konkret yg ada secara
ruang dan waktu sedangkan class hanya merupakan representasi abstraksi
Objek bukan class, meski class bisa jadi objek
Class = definisi abstrak dari sebuah objek, dimana dijelaskan bahwa struktur
dan kelakuan dari tiap objek yg tergabung dlm satu kelas
Kelas adalah deskripsi dari kumpulan objek yg mempunyai tanggung jawab yg
sama, keterhubungan yg sama, operasi, atribut, dan semantik yg sama
Objek dijelaskan di sebuah class, class menjelaskannya dengan bentuk struktur
dan kelakuan dari semua objeknya
Ilustrasi kelas & objek
• If punya benda burung elang, ikan hiu, gadjah, telpon, tv, kamera
• Jadi Objek = 6
• K
2
–
• J
m
Inh
Ada
beh
inhe
seb
3. At
dari p
mempr
dijelask
hanya
atributn
tersebu
4. Op
Kita dpt mene
2 kelas ;
– Benda m
Jika operasi d
memiliki bata
– Kelas ma
heritance
alah Hubunga
havior bersam
eritance. Inh
uah domain m
tribut
Nama-na
properti yg
resentasikan
kan dengan
dinyatakan
nya sudah din
ut.
perasi
entukan class
mati dan bend
dan atribut di
san lebih jela
amalia, burun
an antara cla
ma. Single inh
heritace berg
masalah.
ama properti
dimiliki oleh
properti2 yg
nilai dari atr
keberadaan
nyatakan nila
s dari ojek ter
a hidup
perinci, akan
as, ex;
ng, audio, visu
ss dan saling
eritance = m
guna untuk m
dari sebuah k
h sebuah k
g dimiliki ke
ribut yg dim
dan batasan
ai dan menjela
rsebut berdas
diperoleh leb
ual dan audio
g relasionhip,
mempunyai ha
mengorganisa
kelas yg menj
kelas terseb
las tsb. Kea
ilikinya. Dala
nilainya saj
askan kedudu
sarkan sifat yg
bih banyak je
visual
menshare m
anya 1 class d
asikan know
jelaskan bata
but. Atribut
adaan (state)
am sebuah k
a. Dalam se
ukan/ keadaa
116
g terdiri dari
enis kelas yg
mengunakan
dan multiple
wledge pada
asan nilainya
dari kelas
) dari objel
kelas atribut
ebuah objek
n dari objek
117
Implementasi dari layanan yg dapat diminta dari sebuah objek dari
sebuah kelas yg menentukan tingkah lakunya. Sebuah operasi dpt berupa perintah
ataupun permintaan. Sebuah permintaan tidak boleh mengubah kedudukan dari
objek tersebut.Hanya perintah yg dapat mengubah keadaan dari sebuah objek.
Keluaran dari sebuah operasi tergantung dari nilai keadaan terakhir dari sebuah
objek
5. Antar muka
Sebuah antar muka yg menutupi bagian-bagian detail didalamnya.
Polimorpisma = kemampuan untuk menyembunyikan banyak detail implemetasi yg
berbeda-beda dari dan dengan hanya menggunakan sebuah antar muka yg sama.
Implementasinya dapat terjadi di beberapa kasus implementasi yg berbeda yg
lebih banyak dari antarmukanya.
• Ex: remote control dapat digunakan untuk mengontrol beberapa jenis tv yg
mendukung antar muka tertentu. (antar muka yg digunakan pd remote)
Antar muka adalah kunci kemampuan ‘plug n play’ dari arsitektur, setiap bagian
(kelas, subsistem, komponen) yg menggunakan interface sama dan dapat
dipertukarkan satu dengan lainnya.
Example:
kita mempunyai antar muka musik, dgn operasi start n stop, kita terapkan
pd obejk piano, gitar, drum n bass. Jadi pd saat di start akan
mengimplementasikan perintah tersebut dgn memainkan alat musik yg
berbeda-beda, walaupun satu perintah
6. Komponen
Komponen hampir tidak tergantung pada apapun dan merupakan bagian
yg dapat diganti-ganti dari sebuah system. Sudah memenuhi dan menyediakan
penjabaran dari kelompok antar muka.
7. Paket
Sebuah Mekanisme yg bertujuan umum untuk mengorganisasikan
elemen-elemen kedalam sebuah grup. Model elemen dpt terbentuk ratusan bahkan
ribuan. Maka harus dikelompokkan ke koleksi logik, lalu membutuhkan pengelolaan
dan kemampuan pembacaan dari model tsb. Sebuah paket memiliki elemen-
elemen sendiri, sebuah elemen tidak dpt dimiliki oleh lebih dr satu paket.
118
8. Subsistem
Pengelompokan elemen-elemen dari beberapa elemen yg mempunyai
tingkah laku yg berbeda-beda yg ditawarkan. Pemodelan elemen yg mempunyai
tata bahasa dari paket.
9. keterhubungan
Menyediakan cara-cara berkomunikasi antar objek. Ada beberapa cara
keterhubungan : Asosiasi, asosiasi agregrasi, asosiasi komposisis, dependensi,
generalisasi dan realisasi.
Asosiasi menampilkan keterhubungan struktural antar objek dari kelas yg
berbeda
Depedensi : keterhubungan yg menampilkan keterhubungan antara pengguna
dengan penyedia yg saling mempengaruhi
Generalisasi : keterhubungan dibuat khussu ataupun umum dimana elemen-
elemen dari elemen yg lebih khusus (subtipe / child) dpt mengganti elemen
dari elemen yg lebih umum (parent)
Realisasi : keterhubungan secara tata bahasa antara dua klasifikasi, satu
sebagai penghubungan dan satunya sebagai pembawa
Agregasi : bentuk asosiasi khusus yg memodelkan bagian dari asosiasi antara
hubungan satu bagian kelas dengan kelas lainnya
3. Identifikasi Elemen-elemen dari Model Objek
Kita dapat mulai dengan mengidentifikasi objek dengan menguji masalah atau
dengan melakukan ‘uraian gramatikal’ pada narasi pemrosesan pada sistem yang akan
dibangun. Objek ditentukan dengan menggarisbawahi masing-masing kata benda atau klausa
benda serta memasukkannya pada suatu tabel sederhana.
Coad dan Yourdon mengusulkan enam karakteristik pilihan yang harus digunakan
pada saat analis mempertimbangkan masing-masing objek potensial untuk menyimpulkan
model analisisnya :
1. Informasi yang disimpan
2. Pelayanan yang diperlukan
3. Atribut bertingkat
4. Atribut umum
5. Operasi umum
6. Persyaratan dasar
119
B. OBJECT ORIENTED ANALIS
Object-oriented analysis (OOA) telah ada sejak 1988. orang yang telah memakai
metode ini adalah Shlaer-Mellor, Jacobson, Coad-Yourdon, and Rumbaugh. Hasil sukses dalam
penerapan metode ini dibuktikan di AT & T Bell Labs. AT & T Bell Labs menerapkan metode ini
dalam project besar yang disebut Call Attempt Data Collection System (CADCS). Dari proyek
tersebut didapat bahwa penggunaan metode ini mengurangi 8% dari total waktu untuk
spesifikasi kebutuhan project dan pengurangan 30% staff effort.
Ada hubungan yang sangat erat antara Object-oriented analysis dan teknologi object
oriented yang lain. Diantaranya yaitu Object-Oriented Database, Object- Oriented Design, and
Object-Oriented Programming Languages. Dalam penerapannya semua metode itu digunakan
secara keseluruhan dalam project disebut dengan metode object-oriented. Jika hanya
melakukan analisis saja dengan metode object-oriented dan tidak diikuti dengan design dan
programming dengan metode yang sama tentunya akan menambah kesulitan dalam
pengambangannya. Dalam kenyataannya ketiga metode diatas tidak bisa dilepaskan satu sama
lain. Karena memang untuk mendapatkan hasil yang maksimal dari metode object-oriented,
ketiganya harus ada.
1. Karakteristik dari object-orientedcteristics of
Abstraction and Classification: Pendefinisian sebuah class (object parent) yang memuat
seluruh informasi dasar sebuah object meliputi semua informasi dasar calam object
lain.
Encapsulation and Information Hiding: Bisa disebut pengkapsulan. Internal proses
suatu object/class yang tidak diperlukan untuk diketahui detailnya. Focus pada fungsi
yang telah di jalankan oleh masing-masing object.
Polymorphism and Inheritance: Kemampuan untuk membagi properties yang dimiliki
dengan inheritance (penurunan object). Juga memungkinkan untuk menambah atau
mengurangi properties yang didapat dari pewarisan sifat object.
Pendekatan analisa object-oriented:
• Sistem / software dialokasikan menggunakan strategi formal, yaitu dengan memakai
bahasa untuk mendeskripsikan. Strategi formal dapat dibuat dalam bentuk paragraph
tunggal dengan tatabahasa yang benar.
• Objek diberi garis bawah (kata benda, atau anak kalimat yang bersifat sebagai kata
benda) dan kemudian dimasukkan ke dalam tabel. Sinonim dicatat. Jika objek
diperlukan untuk mengimplementasikan status solusi, maka object tersebut merupakan
120
bagian dari “solution space”. Jika objek hanya diperlukan untuk mendeskripsikan status
solusi, maka objek tersebut merupakan bagian dari “problem space”.
• Atribut dari objek diidentifikasi dengan menggarisbawahi semua kata sifat dan
kemudian menghubungkannya dengan kata benda (objek) masing- masing.
• Operasi ditetapkan dengan menggarisbawahi semua kata kerja, anak kalimat kata kerja
dan predikat, serta menghubungkan setiap operasi dengan objek yang sesuai.
• Attribut dari operasi diidentifikasikan dengan menggarisbawahi semua kata keterangan
dan mengasosiasikan mereka dengan operasi ( kata kerja ) masing-masing.
2. Pengertian Dari Object Oriented Analysis(OOA)
a. Konsep objek
Obyek dalam ‘software analysis & design’ adalah sesuatu berupa konsep (concept),
benda (thing), dan sesuatu yang membedakannya dengan lingkungannya. Secara sederhana
obyek adalah mobil, manusia, alarm dan lainnya. Tapi obyek dapat pula merupakan sesuatu
yang abstrak yang hidup didalam sistem seperti tabel, database, event, system messages.
Obyek dikenali dari keadaannya dan juga operasinya. Sebagai contoh sebuah mobil dikenali dari
warnanya, bentuknya, sedangkan manusia dari suaranya. Ciri-ciri ini yang akan membedakan
obyek tersebut dari obyek lainnya. Alasan mengapa saat ini pendekatan dalam pengembangan
software dengan object-oriented, pertama adalah scalability dimana obyek lebih mudah dipakai
untuk menggambarkan sistem yang besar dan komplek. Kedua dynamic modeling, adalah dapat
dipakai untuk permodelan sistem dinamis dan real time.
Lima prinsip dasar untuk membangun model analisis
a. Domain Informasi dimodelkan
b. Fungsi modul digambarkan
c. Tingkah laku model direpresentasikan
d. Model di partisi untuk mengekpos detail yang lebih besar
e. Model awal mempresentasikan inti masalah sementara model selanjutnya
memberikan detail implementasi
121
b. Pengertian OOA
Pada dasarnya kebanyakan metode analisis system memisahkan antara data dan
proses. Walaupun SA dan IE telah melakukan usaha untuk menyelaraskan keduanya, namun
usaha tersebut belum sepenuhnya berhasil. Analisis berbasis objek kemudian muncul dan
digunakan untuk mengurangi batas pemisah abtara data dan proses. Seluruh data spesifik dan
proses yang membuat, membaca, meng- update atau menghapus data-data tersebut
diintegrasikan dan disebut dengan objek. Beberapa bahasa pemrograman yang berbasis objek
ini antara lain adalah Visual Basic, C++, dan Powerbuilder.
Object-Oriented Analysis (OOA) adalah teknik pemodelan yang mengintegrasikan
antara data dan proses kedalam suatu kesatuan yang disebut dengan objek. Model OOA berupa
gambar yang mengilustrasikan objek system dari berbagai macam persepsi.
Selain itu OOA adalah Adalah suatu metode dalam pengembangan perangkat lunak
berbasis object. Yang dimaksud dengan object bisa dipandang sebagai suatu item informasi
atau representasi entitas di dunia nyata. Seperti contohnya dalam system reservasi
penerbangan hal-hal yang bisa disebut sebagai object seperti pesawat, jalur penerbangan dll.
Dengan metode ini kita mempresentasikan sebuah permasalahan dalam dunia nyata
kedalam object-object, khususnya dalam pegembangan perangkat lunak, agar dalam
pelaksanaannya kita mendapatkan berbagai keuntungan dan kelebihan. Dari beberapa
keuntungan dan kelebihannya, metode ini nantinya akan mendukung dalam konsep dibawah
ini:
1. Maintainability , yaitu tingkat kemudahan dalam mengakomodasi perubahan- perubahan.
2. mengurangi kompleksitas dalam perarancangan design system.
3. Reusability , kemampuan untuk bisa digunakan kembali sehingga dapat menghemat
waktu dan biaya.
Dengan adanya konsep tersebut membuat metode ini seirng digunakan pada masa
sekarang. Kemampuannya untuk dapat digunakan kembali akan mendukung terciptanya suatu
perangkat lunak yang lebih sempurna dari yang sebelumnya dikarenakan kekurangan dari
perangkat lunak sebelumnya diperbaiki, dan kelebihannya tetpa dipertahankan. Jadi bisa
muncul sebuah perangkat lunak baru dengan kemampuan yang selalu lebh dari pada
sebelumnya.
Dengan semakin dikenalnya OOA, kemudian muncul Unified Modeling Language (UML)
yang menyediakan sintaks grafik untuk membuat model berbasis objek.
122
c. Hubungan OOA dengan object oriented yang lain
Ada hubungan yang sangat erat antara Object-oriented analysis dan teknologi object oriented
yang lain. Diantaranya yaitu Object-Oriented Database, Object- Oriented Design, and Object-
OrientedProgramming Languages. Dalam penerapannya semua metode itu digunakan secara
keseluruhan dalam project disebut dengan metode object-oriented. Jika hanya melakukan
analisis saja dengan metode object-oriented dan tidak diikuti dengan design dan programming
dengan metode yang sama tentunya akan menambah kesulitan dalam pengambangannya.
Dalam kenyataannya ketiga metode diatas tidak bisa dilepaskan satu sama lain Karena memang
untuk mendapatkan hasil yang maksimal dari metode object- oriented, ketiganya harus ada.
d. Teknik dasar OOA
Dalam dunia pemodelan, metodologi implementasi obyek walaupun terikat kaidah-kaidah
standar, namun teknik pemilihan obyek tidak terlepas pada subyektifitas software analyst &
designer. Beberapa obyek akan diabaikan dan beberapa obyek menjadi perhatian untuk
diimplementasikan di dalam sistem. Hal ini sah-sah saja karena kenyataan bahwa suatu
permasalahan sudah tentu memiliki lebih dari satu solusi. Ada 3 (tiga) teknik/konsep dasar
dalam OOA, yaitu pemodulan (encapsulation), penurunan (inheritance) dan polymorphism.
1. Pembungkusan (Encapsulation)
Pada dunia nyata, seorang ibu rumah tangga menanak nasi dengan menggunakan rice cooker,
ibu tersebut menggunakannya hanya dengan menekan tombol. Tanpa harus tahu bagaimana
proses itu sebenarnya terjadi. Disini terdapat penyembunyian informasi milik rice cooker,
sehingga tidak perlu diketahui seorang ibu. Dengan demikian menanak nasi oleh si ibu menjadi
sesuatu yang menjadi dasar bagi konsep information hiding.
2. Penurunan (Inheritance)
Obyek-obyek memiliki banyak persamaan, namun ada sedikit perbedan. Contoh dengan
beberapa buah mobil yang mempunyai kegunaan yang berbeda-beda. Ada mobil bak terbuka
seperti truk, bak tertutup seperti sedan dan minibus. Walaupun demikian obyek-obyek ini
memiliki kesamaan yaitu teridentifikasi sebagai obyek mobil, obyek ini dapat dikatakan sebagai
obyek induk (parent). Sedangkan minibus dikatakan sebagai obyek anak (child), hal ini juga
berarti semua operasi yang berlaku pada mobil berlaku juga pada minibus.
3. Polymorphism
123
Pada obyek mobil, walaupun minibus dan truk merupakan jenis obyek mobil yang sama, namun
memiliki juga perbedaan. Misalnya suara truk lebih keras dari pada minibus, hal ini juga berlaku
pada obyek anak (child) melakukan metoda yang sama dengan algoritma berbeda dari obyek
induknya. Hal ini yang disebut polymorphism, teknik atau konsep dasar lainnya adalah ruang
lingkup/pembatasan. Artinya setiap obyek mempunyai ruang lingkup kelas,atribut, dan metoda
yang dibatasi.
3. Tujuan OOA
Tujuan dari OOA adalah menentukan semua kelas(dan hubungan serta tingkah laku yang
berkaitan dengannya) yang relevan dengan masalah yang akan dipecahkan. Untuk itu perlu
melakukan sejumlah tugas yaitu:
1. Persyaratan pemakaian dasar harus di komunikasikan diantara pelanggan dan
perekayasa perangkat lunak.
2. Kelas – kelas harus diidentifikasi(misalnya: atribut dan metode yang ditentukan)
3. Hirarki kelas harus didpesifikasikan.
4. Hubungan objek – ke - objek(koneksi objek) harus direpresentasikan.
5. Tingkah laku objek dimodelkan.
6. Tugas 1 sampai 5 diaplikasikan lagi secara sampai model selesai.
Selain menguji suatu dengan masalah dengan menggunakan model input- proses-onput yang
klasik(aliran informasi) atau model yang ditarik secara eksekutifdari struktur informasi) atau
model yang tertarik secara eksklusif dari struktur infromasi hiraskis. OOA
memperkenalkansejumlah konsep baru menurut Coad dan Yourdon yang menyinggung masalah
ini dengan mengatakan: “ OOA didasarkan pada konsep yang pertama kali kita pelajari di
taman kanak – kanak. objek, atribut dan anggota. Keseluruhan dan bagian. Mengapa
diperlukan waktu yang panjang unutk mengaplikasikan konsep –konsep ini ke analisis dan
spesifikasi sistem informasi merupakan teka –teki bagi setiap orang – mungkin kita terlalu sibuk
“mengikuti aliran” selama masa emas analisis terstruktur untuk mempertimbangkan alternatif –
alternatif tersebut.”
4. Sasaran OOA
Sasaran OOA adalah mengembangkan sederetan model yang menggambarkan perangkat lunak
komputer pada saat komputer itu bekerja unutk memenuhi serangkaian persyaratan yang
ditentukan oleh pelanggan. OOA membangun metode multibagian untuk memenuhi sasaran
tersebut.
124
5. Pengujian model OOA
a. Kebenaran dari model OOA
Kebenaran dari sintaks : Penggunaan simbol dan aturan pemodelan yang tepat
Kebenaran dari sematik:
1. Model yang mewakili dunia nyata, dibutuhkan seorang ahli dalam domain persoalan.
2. Hubungan antar kelas
b. Kekonsistenan dari model OOA
1.hubungan antar entitas dalam model
2.dapat digunakan model CRC dan object-relationship diagram
6. Proses Analisis Domain:
input dan output unutk analisis domain
a. menurut Firesmith mengambarkan analisis domain perangkat lunak dengan cara sebagai
berikut:
Analisis domain perangkat lunak adalah identifikasi, analisis, dan spesifikasi dari persyaratan
umum suatu domain aplikasi spesifik.
b. Akativitas – aktivitas dalam proses analisis domain:
1. Tentukan domain yang diselidiki
2. Kategorikan item yang di ekstrak dari domain tersebut.
125
3. Kumpulkan sempel representatif dari aplikasi di dalam domain tersebut
4. Analisis masing –masing aplikasi pada sempel tersebut
5. Kembangkan model a analis unutk objek tersebut.
C. OOA VS CONVENSIONAL
Fichman dan Kamerer mengusulkan 11 dimensi permodelan yang dapat digunakan
untuk membandingkan berbagai metode OOA dan Konvensional :
1) Identifikasi/klasifikasi entitas
2) Umum ke spesifik dan keseluruhan ke hubungan entitas bagian
3) Hubungan entitas lain
4) Gambaran atribut entitas
5) Partisi model skala besar
6) Keadaan dan transisi antar keadaan
7) Spesifikasi detail untuk fungsi
8) Dekomposisi Top-Down
9) Urutan pemrosesan end-to-end
10) Identifikasi pelayanan eksklusif
11) Komunikasi entitas (melalui pesan atau event)
D. UNIFIED MODELLING LANGUAGE (UML)
1. Sejarah Singkat Unified Modelling Language (UML)
Unified Modelling Language (UML) adalah sebuah "bahasa" yang telah
menjadi standar dalam industri untuk menentukan, visualisasi, merancang dan
mendokumentasikan artifact dari sistem software, untuk memodelkan bisnis dan
sistem non software lainnya. UML merupakan suatu kumpulan teknik terbaik yang
telah terbukti sukses dalam memodelkan sistem yang besar dan kompleks.
Dengan menggunakan UML kita dapat membuat model untuk semua
jenis aplikasi piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti
keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman
apapun. Tetapi karena UML juga menggunakan class dan operation dalam konsep
dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa-bahasa
berorientasi objek seperti C++, Java, VB.NET. Walaupun demikian, UML tetap dapat
digunakan untuk modeling aplikasi prosedural dalam VB atau C.
126
Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan
syntax/semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk
menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna
tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat
dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada
sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT
(Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented Software
Engineering).
Sejarah UML sendiri cukup panjang. Sampai era tahun 1990 seperti kita
ketahui puluhan metodologi pemodelan berorientasi objek telah bermunculan di
dunia. Diantaranya adalah: metodologi Booch, metodologi Coad , metodologi OOSE,
metodologi OMT, metodologi Shlaer-Mellor, metodologi Wirfs-Brock, dan
sebagainya. Masa itu terkenal dengan masa perang metodologi (method war) dalam
pendesainan berorientasi objek. Masing-masing metodologi membawa notasi
sendiri-sendiri, yang mengakibatkan timbul masalah baru apabila kita bekerja sama
dengan group/perusahaan lain yang menggunakan metodologi yang berlainan.
Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan
tiga tokoh yang boleh dikatakan metodologinya banyak digunakan mempelopori
usaha untuk penyatuan metodologi pendesainan berorientasi objek. Pada tahun
1995 direlease draft pertama dari UML (versi 0.8). Sejak tahun 1996 pengembangan
tersebut dikoordinasikan oleh Object Management Group (OMG –
http://www.omg.org). Tahun 1997 UML versi 1.1 muncul, dan saat ini versi terbaru
adalah versi 1.5 yang dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson
menyusun tiga buku serial tentang UML pada tahun 1999. Sejak saat itulah UML
telah menjelma menjadi standar bahasa pemodelan untuk aplikasi berorientasi
objek.
Object Management Group, Inc. (OMG) adalah sebuah organisasi
international yang dibentuk pada 1989, didukung lebih dari 800 anggota, terdiri dari
perusahaan sistem informasi, software developer, dan pada user sistem komputer.
127
organisasi ini salah satunya bertugas membuat spesifikasi “manajemen objek” untuk
menetapkan kerangka bersama dalam rekayasa software.
Sasaran OMG adalah membantu perkembangan object-oriented
technology dan mengarahkannya dengan mendirikan Object Management
Architecture (OMA). OMA menentukan infrastruktur konseptual yang didasarkan
pada seluruh spesifikasi yang dikeluarkan OMG. OMG kemudian mengeluarkan UML,
dimana dengan adanya UML ini diharapkan dapat mengurangi kekacauan dalam
bahasa pemodelan yang selama ini terjadi dalam lingkungan industri. UML
diharapkan juga dapat menjawab masalah penotasian dan mekanisme tukar
menukar model yang terjadi selama ini.
2. Tinjauan Mengenai UML
Saat ini piranti lunak semakin luas dan besar lingkupnya, sehingga tidak bisa lagi
dibuat asal-asalan. Piranti lunak saat ini seharusnya dirancang dengan
memperhatikan hal-hal seperti scalability, security, dan eksekusi yang robust
walaupun dalam kondisi yang sulit. Selain itu arsitekturnya harus didefinisikan
dengan jelas, agar bug mudah ditemukan dan diperbaiki, bahkan oleh orang lain
selain programmer aslinya. Keuntungan lain dari perencanaan arsitektur yang
matang adalah dimungkinkannya penggunaan kembali modul atau komponen untuk
aplikasi piranti lunak lain yang membutuhkan fungsionalitas yang sama.
Pemodelan (modeling) adalah proses merancang piranti lunak sebelum melakukan
pengkodean (coding). Model piranti lunak dapat dianalogikan seperti
pembuatan blueprint pada pembangunan gedung. Membuat model dari sebuah
sistem yang kompleks sangatlah penting karena kita tidak dapat memahami sistem
semacam itu secara menyeluruh. Semakin komplek sebuah sistem, semakin penting
pula penggunaan teknik pemodelan yang baik.
Dengan menggunakan model, diharapkan pengembangan piranti lunak dapat
memenuhi semua kebutuhan pengguna dengan lengkap dan tepat, termasuk faktor-
faktor seperti scalability, robustness, security, dan sebagainya. Kesuksesan suatu
pemodelan piranti lunak ditentukan oleh tiga unsur, yang kemudian terkenal
dengan sebutan segitiga sukses (the triangle for success). Ketiga unsur tersebut
adalah metode pemodelan (notation), proses (process) dan tool yang digunakan.
Memahami notasi pemodelan tanpa mengetahui cara pemakaian yang sebenarnya
128
(proses) akan membuat proyek gagal. Dan pemahaman terhadap metode
pemodelan dan proses disempurnakan dengan penggunaan tool yang tepat.
Artifact UML UML menyediakan beberapa notasi dan artifact standar yang
bisa digunakan sebagai alat komunikasi bagi para pelaku dalam proses analisis dan
desain. Artifact didalam UML didefinisikan sebagai informasi dalam bentuk yang
digunakan atau dihasilkan dalam proses pengembangan perangkat. Contohnya
adalah source code yang dihasilkan oleh proses pemrograman.
Yang harus diperhatikan untuk menjaga konsistensi antar artifact selama proses
analisis dan desain adalah bahwa setiap perubahan yang terjadi pada satu artifact
harus juga dilakukan pada atifact sebelumnya.
Untuk membuat suatu model, UML memiliki diagram grafis sebagai berikut :
• use case diagram
• class diagram
• behavior diagram
• statechart diagram
• activity diagram
• interaction diagram
• sequence diagram
• collaboration diagram
• implementation diagram
• component diagram
• deployment diagram
Diagram-diagram tersebut diberi nama berdasarkan sudut pandang yang berbeda-
beda terhadap sistem dalam proses analisis atau rekayasa.
Dibuatnya berbagai jenis diagram diatas karena :
� Setiap sistem yang kompleks selalu paling baik jika didekati melalui himpunan
berbagai sudut pandang yang kecil yang satu sama lain hampir saling bebas
129
(independent). Sudut pandang tunggal senantiasa tidak mencukupi untuk melihat
sistem yang besar dan kompleks.
� Diagram yang berbeda-beda tersebut dapat menyatakan tingkatan yang berbeda-
beda dalam proses rekayasa.
� Diagram-diagram tersebut dibuat agar model yang dibuat semakin mendekati
realitas.
3. Semantik dalam UML
OMG telah menetapkan semantik (makna istilah) semua notasi UML dalam model
struktural dan model behavior. Model struktural (model statis), menekankan stuktur
obyek dalam sebuah sistem, menyangkut kelas-kelas, interface, atribut dan
hubungan antar komponen. Model behavioral (model dinamis), menekankan perilaku
obyek dalam sebuah sistem, termasuk metode, interaksi, kolaborasi dan state
history
4. Tujuan UML Tujuan utama UML diantaranya untuk :
� Memberikan model yang siap pakai, bahasa pemodelan visual yang
ekspresif untuk mengembangkan dan saling menukar model dengan
mudah dan dimengerti secara umum.
� Memberikan bahasa pemodelan yang bebas dari berbagai bahasa
pemrograman dan proses rekayasa.
� Menyatukan praktek-praktek terbaik yang terdapat dalam bahasa
pemodelan.
5. Cakupan UML
Pertama, UML menggabungkan konsep Booch, OMT dan OOSE, sehingga UML
merupakan suatu bahasa pemodelan tunggal yang umum dan digunakan secara luas
oleh para user ketiga metode tersebut dan bahkan para user metode lainnya.
Kedua, UML menekankan pada apa yang dapat dikerjakan dengan metode-meode
tersebut.
130
Ketiga, UML berfokus pada suatu bahasa pemodelan standar, bahkan pada proses
standar. Meskipun UML harus diaplikasikan dalam konteks sebuah proses, dari
pengalaman, bahwa organisasi dan masalah yang berbeda juga memerlukan proses
yang berbeda pula.
UML tidak mencakup :
• Bahasa Pemrograman UML adalah bahasa pemodelan visual, bukan dimaksudkan
untuk menjadi suatu bahasa pemrograman visual, tetapi UML memberikan arah
untuk bergerak kearah kode.
• Tool (software aplikasi) pemodelan
Membuat standar sebuah bahasa diperlukan oleh tool-tool dan proses. UML
mendefinisikan semantik dan notasi, bukan sebuah tool. Contoh tool yang
menggunakan UML sebagai bahasanya adalah Rational Rose dan Enterprise
Architect.
• Proses rekayasa
UML digunakan sebagai bahasa dalam proyek dengan proses yang berbeda-beda.
UML bebas dari proses dan mendefinisikan sebuah proses standar bukan tujuan
UML atau RFP dari OMG. Dalam pembahasan ini kita akan menggunakan sebuah
proses yang dikeluarkan Rational Software, yaitu Rational Unified Process (RUP)
Notasi dalam UML
a. Actor
Actor menggambarkan segala pengguna software aplikasi (user). Actor memberikan
suatu gambaran jelas tentang apa yang harus dikerjakan software aplikasi. Sebagai
contoh sebuah actor dapat memberikan input kedalam dan menerima informasi dari
software aplikasi, perlu dicatat bahwa sebuah actor berinteraksi dengan use case,
tetapi tidak memiliki kontrol atas use case. Sebuah actor mungkin seorang manusia,
satu device, hardware atau sistem informasi lainnya.
b. Use Case
131
Use case menjelaskan urutan kegiatan yang dilakukan actor dan sistem untuk
mencapai suatu tujuan tertentu. Walaupun menjelaskan kegiatan, namun use case
hanya menjelaskan apa yang dilakukan oleh actor dan sistem bukan bagaimana
actor dan sistem melakukan kegiatan tersebut.
Use-case Konkret adalah use case yang dibuat langsung karena keperluan actor.
Actor dapat melihat dan berinisiatif terhadapnya
Use-case Abstrak adalah use case yang tidak pernah berdiri sendiri. Use case
abstrak senantiasa termasuk didalam (include), diperluas dari (extend) atau
memperumum (generalize) use case lainnya. Untuk menggambarkannya dalam use
case model biasanya digunakan association relationship yang memiliki stereotype
include, extend atau generalization relationship. Hubungan include menggambarkan
bahwa suatu use case seluruhnya meliputi fungsionalitas dari use case lainnya.
Hubungan extend antar use case berarti bahwa satu use case merupakan tambahan
fungsionalitas dari use case yang lain jika kondisi atau syarat tertentu terpenuhi.
c. Class
Class merupakan pembentuk utama dari sistem berorientasi obyek, karena class
menunjukkan kumpulan obyek yang memiliki atribut dan operasi yang sama. Class
digunakan untuk mengimplementasikan interface.
Class digunakan untuk mengabstraksikan elemen-elemen dari sistem yang sedang
dibangun. Class bisa merepresentasikan baik perangkat lunak maupun perangkat
keras, baik konsep maupun benda nyata.
132
Notasi class berbentuk persegi panjang berisi 3 bagian: persegi panjang paling atas
untuk nama class, persegi panjang paling bawah untuk operasi, dan persegi panjang
ditengah untuk atribut.
Atribut digunakan untuk menyimpan informasi. Nama atribut menggunakan kata
benda yang bisa dengan jelas merepresentasikan informasi yang tersimpan
didalamnya. Operasi menunjukkan sesuatu yang bisa dilakukan oleh obyek dan
menggunakan kata kerja.
d. Interface
Interface merupakan kumpulan operasi tanpa implementasi dari suatu class.
Implementasi operasi dalam interface dijabarkan oleh operasi didalam class. Oleh
karena itu keberadaan interface selalu disertai oleh class yang
mengimplementasikan operasinya. Interface ini merupakan salah satu cara
mewujudkan prinsip enkapsulasi dalam obyek.
e. Interaction
Interaction digunakan untuk menunjukkan baik aliran pesan atau informasi antar
obyek maupun hubungan antar obyek. Biasanya interaction ini dilengkapi juga
dengan teks bernama operation signature yang tersusun dari nama operasi,
parameter yang dikirim dan tipe parameter yang dikembalikan.
f. Note
133
Note digunakan untuk memberikan keterangan atau komentar tambahan dari suatu
elemen sehingga bisa langsung terlampir dalam model. Note ini bisa disertakan ke
semua elemen notasi yang lain.
g. Dependency
Dependency merupakan relasi yang menunjukan bahwa perubahan pada salah satu
elemen memberi pengaruh pada elemen lain. Elemen yang ada di
bagian tanda panah adalah elemen yang tergantung pada elemen yang ada dibagian
tanpa tanda panah.
Terdapat 2 stereotype dari dependency, yaitu include dan extend. Include
menunjukkan bahwa suatu bagian dari elemen (yang ada digaris tanpa panah)
memicu eksekusi bagian dari elemen lain (yang ada di garis dengan panah).
Extend menunjukkan bahwa suatu bagian dari elemen di garis tanpa panah bisa
disisipkan kedalam elemen yang ada di garis dengan panah.
h. Association
Association menggambarkan navigasi antar class (navigation), berapa banyak obyek
lain yang bisa berhubungan dengan satu obyek (multiplicity antar class) dan apakah
suatu class menjadi bagian dari class lainnya (aggregation).
Navigation dilambangkan dengan penambahan tanda panah di akhir garis.
Bidirectional navigation menunjukkan bahwa dengan mengetahui salah satu class
bisa didapatkan informasi dari class lainnya. Sementara UniDirectional navigation
hanya dengan mengetahui class diujung garis association tanpa panah kita bisa
mendapatkan informasi dari class di ujung dengan panah, tetapi tidak sebaliknya.
Aggregation mengacu pada hubungan “has-a”, yaitu bahwa suatu class memiliki
class lain, misalnya Rumah memiliki class Kamar.
i. Generalization
Generalization menunjukkan hubungan antara elemen yang lebih umum ke elemen
yang lebih spesifik. Dengan generalization, class yang lebih spesifik (subclass) akan
menurunkan atribut dan operasi dari class yang lebih umum (superclass) atau
134
“subclass is superclass”. Dengan menggunakan notasi generalization ini, konsep
inheritance dari prinsip hirarki dapat dimodelkan.
j. Realization
Realization menunjukkan hubungan bahwa elemen yang ada di bagian tanpa panah
akan merealisasikan apa yang dinyatakan oleh elemen yang ada di bagian dengan
panah. Misalnya class merealisasikan package, component merealisasikan class atau
interface.
- ANALISIS DOMAIN
Firesmith [FIR93] menggambarkan analisis domain perangkat lunak dengan cara
sebagai berikut:
Analisis domain perangkat lunak adalah identifikasi, analisis dan spesifikasi
persyaratan umum suatu domai aplikasi spesigik, yang secara khas digunakan pada
proyek bertingakat pada domain aplikasi itu. Anlisis domain berorientasi objek
adalah identifikasi, analisis, dan spesifikasi kemampuan reusable yang umum di
dalam suatu domain aplikasi khusus, dalam bentuk objek umum, kelas,
subassembly, dan kerangka kerja.
Aktivitas yang terjadi sebelum proses analisis domain
Tentukan domain yang akan diselidiki
Kategorikan item yang diekstrak dari domain tersebut
Kumpulkan sampel representatif dari aplikasi di dalam domain tersebut
Analisis masing-masing aplikasi pada domain tersebut
Kembangkan model analisis untuk objek tersebut
- PROSES OOA
Use Case
Pemodelan Kelas-tanggung jawab-kolaborator
Kelas
Tanggung jawab
kolaborator
135
Pendefinisian stuktur dan hirarki
Begitu kelas dan objek sudah diidentifikasi dengan
menggunakan model CRC, analis mulai untuk berfokus pada stuktur
model kelas dan hirarki resultan yang muncul pada saat kelas dan
subkelas muncul.
Pendefinisian subjek dan sub sistem
Model analisis untuk aplikasi yang kompleks memiliki ratusan
kelas dan puluhan struktur.
- Model Hubungan Objek
Model hubungan objek dapat diperoleh dalam 3 langkah
Dengan menggunakan kartu indeks
Dengan mengkaji kartu indeks model CRC
Begitu yang telah diberi nama terbangun
Model Tingkah Laku Objek
Identifikasi event dengan use case
Representasi keadaan
Keadaan dari masing-masing objek ketika sistem melakukan fungsinya
Keadaan sistem pada saat diselidiki dari luar ketika sistem melakukan
fungsinya
E. OBJECT ORIENTED DESIGN
Object-oriented design adalah metoda untuk meng-arahkan arsitektur perangkat lunak
yang didasarkan pada manipulasi objek-objek sistem atau subsistem. Model kebutuhan-
kebutuhan yang dibuat pada fase analisis diperkaya dalan fase perancangan. Kadang-kadang
ditambahkan lebih banyak lagi atribut dan pelayanan.
•Ditambahkan antarmuka obyek-obyek.
• Memberikan blueprint untuk implementasi
• Menspesifikasi “HOW”
• Menspesifikasi: class definitions, class categories
• Menspesifikasi: subsystems, system architectures
•OOA + Rincian Implementasi
Tujuan dari OO Design adalah mengoptimalkan maintainability, reusability, enhancebility dan
reliability
136
Desain berorientasi objek mempergunakan desain data ketika atribut direpresentasikan, desain
interface ketika messaging model dikembangkan, dan component level (procedural) design
untuk desain operasi-operasi. Desain subsistem diturunkan dengan mempertimbangkan
kebutuhan customer secara keseluruhan (yang direpresentasikan dengan use-case), even dan
state yang diobservasi secara eksternal (object behavior model). Desain klas dan objek
dipetakan berdasarkan deskripsi dari atribut, operasi, dan kolaborasi yang terdapat dalam
model CRC. Desain message diturunkan dari object-relationship model. Dan desain
responsibilities diturunkan menggunakan atribut, operasi, dan kolaborasi yang digambarkan
dalam model CRC.
Ada berbagai macam metoda OOD yang dibuat, seperti Booch, Rumbaugh, Jacobson, Coad &
Yourdon dan Wirfs-Brock. Meskipun terminologi dan proses untuk setiap metoda OOD tersebut
berbeda, secara keseluruhan proses OOD termasuk konsisten. Untuk melaksanakan object-
oriented design, ada beberapa langkah umum yang seharusnya dilakukan :
a) Gambarkan setiap subsistem dan alokasinya pada processor dan task.
b) Pilih sebuah strategi desain untuk mengimplementasikan manajemen data, interface
support, dan manajemen task.
c) Desain suatu mekanisme kontrol yang tepat untuk sistem
d) Lakukan desain objek dengan membuat suatu representasi prosedural untuk setiap
operasi dan struktur data untuk setiap atribut klas.
e) Lakukan desain message menggunakan kolaborasi di antara objek-objek dan hubungan
objek (object relationships).
f) Buat messaging model.
g) Tinjau model desain dan ulangi jika dibutuhkan.
137
BAB 10 CLIENT SERVER SOFTWARE ENGINEERING
A. STRUKTUR DARI SISTEM CLIENT- SERVER
Diawal perkembangannya perangkat komputer adalah barang yang mahal dan mewah.
Pengembangan dan pengoperasiannya rumit dan terpusat. Namun seiring dengan berjalannya
waktu yang tadinya proses tersentralisasi dikembangakan menjadi proses terdistribusi sampai
pada end user. Hal ini sangat dipengaruhi oleh adanya perkembangan teknologi LAN (Local
Area Network) di pertengahan tahun 1980 an. Dengan LAN sebuah PC dapat melakukan
komunikasi satu dengan lainnya dan dapat saling berbagi resource baik perangkat keras
ataupun database. LAN mampu memberikan interkonektivitas yang tidak pernah ada
sebelumnya. Untuk dapat melakukan hal tersebut dibutuhkan sebuah komputer pemproses
yang memfasilitasi dan melayani proses sharing semua resource yang ada. Perangkat ini
disebut dengan Server. Untuk melakukan Sharing File biasanya dibutuhkan sebuah File Server
begitu juga untuk sharing Printer dibutuhkan sebuah Printer Server. Namun ternyata hal seperti
ini belumlah cukup. Jumlah PC yang bertambah dengan sangat cepat seiring dengan
berkembangnya sebuah organisasi. Jumlah end user dan client juga bertambah banyak.
Kebutuhan akan perangkat menjadi bertambah pula, tidak hanya membutuhkan sebuah printer
server, juga dibutuhkan server-server lainnya seperti server pengolahan gambar, server
pengolahan suara, dan lainnya. Server-server ini dengan database dan applikasinya harus dapat
diakses oleh beberapa PC, ataupun diakses oleh sebuah komputer mainframe melalui sebuah
LAN. Sistem seperti ini disebut Sistem Client Server seperti digambarkan pada Gambar 1
dibawah ini.
138
Gambar Skema Sistem Client-Server
Komponen dan Fungsi Sistem Client Server
Gambaran umum konfigurasi Client Server diperlihatkan pada gambar 2. Dengan pendekatan
Client Server setiap PC dapat melakukan secara independen sebuah pemrosesan lokal dan
mensharing perangkat enterprise melalui LAN. Untuk kasus yang lebih luas kemampuan akses
dapat dilakukan melalui MAN (Metropolita Area Network) atau WAN (Wide Area Network).
Sebuah database dan program applikasi enterprise misalnya diletakan pada sebuah server
dimana setiap end user dapat melakukan akses melalui Client Processor, LAN dan Server seperti
pada gambar 3.
Gambar-2 Host Sistem dan Sistem Client Server
139
User
User disini adalah end user yang mengakses client untuk mendapatkan sebuah layanan. End
user bisa saja seorang manager perusahaan, professional, karyawan di sebuah perusahaan,
atau pelanggan. Ada timbul sedikit kerancuan. Pelanggan dalam sebuah bisnis atau
perdagangan disebut dengan client, tapi client ini adalah manusia, jangan dibingungkan dengan
istilah client pada pemrosesan komputer. Dapat kita katakan sebuah user atau end user adalah
ketika melakukan proses akhir menggunakan sistem client server.
Gambar Komponen Sistem Client Server
Client
Client dapat berupa sebuah pemproses yang powerful atau dapat juga berupa terminal tua
dengan kemampuan proses yang terbatas. Secara mendasar client adalah sebuah PC dengan
sistem operasinya sendiri. Sebagian besar pemrosesan banyak dilakukan di sebuah server
dimana bagian-bagian dalam lingkup pekerjaannya ditentukan oleh program komputer, inilah
yang menyebabkan sistem client server berbeda dengan sistem transaksi tradisional. Sistem
client server memungkinkan sebuah teknologi dan applikasinya digunakan bersamaan. Applikasi
disini termasuk didalamnya adalah pemroses pesan seperti e-mail, pemproses file lokal seperti
DBMS untuk browsing dan penghitungan, atau sharing resource seperti sistem image
processing, sistem optical character, sistem advance grafic processing, plotter warna, atau
sebuah printer. Perangkat-perangkat ini bisa saja berasal dari berbagai vendor yang ada. Untuk
140
memfasilitasi query pemprosesan dari client, sebagian besar sistem client server menggunkaan
Structured Query Language (SQL) yang merupakan struktur bahasa tingkat tinggi. SQL dengan
database relationalnya adalah standar de facto untuk hampir sebagian besar sistem client
server. Salah satu komponen terpenting sistem client server adalah User Interface (UI), yang
digunakan user untuk berkomunikasi. Bagi user yang seorang programmer, UI tidak mesti user
friendly, tapi untuk end user yang bukan programmer sangat dibutuhkan UI yang user friendly.
Dibutuhkan Graphical User Interface (GUI) untuk end user karena GUI menampilkan grafis
untuk melakukan akses dengan icon-icon tanpa perlu memasukan perintah pemrograman.
Kedepannya GUI tidak hanya digunakan untuk menggantikan akses perintah pemprograman
tapi juga digunakan untuk grafik, voice, video, animasi, untuk selanjutnya menjadi sebuah
teminal multimedia.
Network dan Transmisi
Server dan client dapat terkoneksi dengan sebuah media transmisi. Media transmisi ini dapat
berupa kabel, wireless, atau fiber. Dengan media ini memungkinkan sebuah perusahaan untuk
melakukan enterprice network lebih besar dalam sebuah workgroup atau departemen. Untuk itu
dibutuhkan interoperability sebagai contoh operasi dan pertukaran informasi yang heterogen
melalui berbagai perangkat software dalam jaringan. Esensinya adalah keterbukaan dalam
melakukan pertukaran baik komponen dan software yang berasal dari vendor yang berbeda-
beda. Dengan interoperability baik vendor dan customer akan mendapatkan keuntungan.
Interoperability memberikan dampak pada arsitektur jaringan. Awal sebuah arsitektur jaringan
adalah SNA namun arsitektur ini bersifar proprietary dan tidak terbuka dengan vendor lainnya.
Kemudian sebagian besar orang beralih ke OSI yang di standarkan oleh ISO (International
Standards Organization). OSI banyak di gunakan di Eropa namun kurang berkembang di
Amerika Serikat. Di Amerika Serikat muncul TCP/IP yang kemudian di dukung oleh Unix User
Group.
Servers
Konektivitas adalah hal yang terpenting namun bukan satu-satunya faktor untuk mendapatkan
efisiensi dan efektivitas sharing resource yang dimiliki. Dibutuhkan sebuah perangkat yang
memiliki kemampuan mengontrol software, menjalankan program applikasi, dan mengakses
database dengan mudah dan cepat. Untuk itulah diperlukan sebuah Server. Sebuah Server
harus mendukung spesifikasi yang mendukung resource sharing seperti Network Server
Operating System, Multiple User Interface, GUI (Graphic User Interface), dialog oriented cleint
– server languange seperti SQL dan database arsitektur. Saat ini resuorce bisa tersebar secara
141
spasial tidak hanya berada dalam batasan sebuah negara namun sudah antar negara yang
membutuhkan interkoneksi yang tinggi.
Beberapa software dapat diperoleh dari vendor atau software house. Software tersebut bisa
bersifat mainframe centric (sentral) atau PC server centric. Namun selain semua hal yang
tersedia pada paket software tersebut tetap dibutuhkan in house sofware development. Juga
perlu untuk mengintegrasikan sistem client server dengan sistem informasi yang telah ada dan
menggunakan sistem tersebut tidak hanya sebagai end user tapi juga bekerja diantara group
end user.
Server melakukan pemprosesan mirip dengan pemrosesan yang ada disisi client. Namun ada
sedikit perbedaan, biasanya sebuah server tidak mempunyai User Interface karena didesain
untuk networking, memproses database dan memproses applikasi. Pembeda antara
pemrosesan client dan server ada pada tanggungjawab dan fungsi dari pemrosesan yang
dilakukan. Sebagai contoh sebuah server dapat bertindak sebagai repository dan penyimpanan
informasi dalam kasus pada file server. Tipe dari Server tergantung pada kebutuhan dan tujuan
sistem. Dalam beberapa kasus sebuah server harus mampu melakukan multitaskting
(membentuk multi fungsi secara simultan), menggunakan multiple operating system, lebih
portable, memiliki skalabilitas, dan memiliki waktu respon yang cepat untuk melakukan
teleprosesing. Dengan kapabilitas seperti itu menjadikan server memiliki harga yang relatif
mahal. Penyebab mahalnya harga server adalah :
1. Network Management
2. Gateway function termasuk akses keluar dan e-mail publik
3. Penyimpanan
4. File Sharing
5. Batch processing
6. Bulletin Board access
7. Facsimile transmission
Pemrosesan Database
Beberapa prinsip pemrosesan data pada server termasuk didalamnya adalah integritas, sekuriti,
dan recovery data. Enterprise data yang dibutuhkan oleh sebuah perusahaan membutuhkan
sebuah integrasi, pengaksesan data yang di kendalikan dan kelola dengan securiti yang baik,
dan recovery data dapat dilakukan jika terjadi kegagalan sistem.
142
Beberapa data management dilakukan secara otomatis. Biasanya dilakukan oleh DBMS yang
berada di Server yang mengontrol akses diantara pemprosesan multiple sistem dan
mengintegrasikan akses data melalui network management.
Pemrosesan Applikasi
Data digunakan oleh program applikasi yang mana sebagian besarnya berada di server. Ada
beberapa applikasi client server yang disediakan oleh vendor. Tools applikasi ini menjadikan
pengembangan sistem client-server menjadi lebih kompetitif. Pengembangan applikasi client-
server dapat dilakukan dengan beberapa cara yakni :
1. Fungsi pemprosesan didistribusikan diantara client dan server. Porsi dari client
dijalankan oleh end user dengan menggunakan bahasa pemrograman database seperti
SQL yang memberikan semacam request data dan kemudian mengekstrak data
tersebut dari lokasinya dimana semua proses tersebut dikontrol oleh sistem operasi.
2. UI dan GUI menjadi lebih sering digunakan karena tingkat kemudahan penggunaan
menjadi lebih penting.
3. Digunakannya Advance networking seperti LAN
4. Code generator juga digunakan, Metodelogi Objeck Oriented akan menambah tingkat
penggunan.
5. Tools pengembangan seperti SQL Server, FLOWMARK, Progress, ObjectView, Oracle
menjadi sangat diperlukan
Ketika sebuah applikasi diproses dan permintaan akan data dilakukan oleh client, maka hasilnya
dikirimkan melalui LAN. Hasil dari applikasi tersebut dapat saja dilakukan perubahan bentuk
untuk mendapatkan tampilan yang lebih baik. Semuanya ini dilakukan di sisi client oleh end
user melalui UI (User Interface). Diagram skematik pendekatan client server ditunjukan pada
gambar dibawah ini.
143
Gambar Applikasi Sistem Client Server
144
Keuntungan Sistem Client Server
1. Mengurangi tanggung jawab dan biaya overhead
2. Kontrol biaya operasional dan pengembangan yang lebih mudah
3. Waktu respon yang lebih baik dalam pemrosesan.
4. Akses data yang lebih besar bagi perusahaan. Sistem Client server mengamankan
transaksi data dan menyimpannya pada server untuk kemudian dapat di sharing,
dimanipulasi, dianalisa secara lokal.
5. Memungkinkan pendistribusian proses dari tersentralisasi menjadi desktop computing
6. Menawarkan kooperatif prosesing antara individu dan group antar departemen,
geografis dan zona waktu.
7. Rewriting software pada sistem client server memberikan keuntungan untuk
mendapatkan sistem yang terintegrasi dan memberikan efisiensi.
8. Menawarkan friendlu interface pada end user khususnya pada knowledge worker dan
customer.
9. Keterlibatan yang lebih untuk end user pada implementasi IT.
10. Arsitektur terbuka dan sistem terbuka memberikan fleksibilitas dalam memilih
konfigurasi hardware yang berbeda, network, dan DBMS dari berbagai vendor.
Hambatan Implementasi Sistem Client Server
Organisasi
1. Skill personel yang kurang memadai untuk implementasi sistem client server.
2. Anti perubahan terhadap teknologi baru.
3. Biaya konversi
4. Membutuhkan koordinasi dan kontrol yang lebih pada end user.
Teknologi
1. Membutuhkan infrastruktur LAN dan WAN
2. Skill dan peralatan yang belum memadai
3. Belum adanya pemahaman dan pengalaman dalam merencanakan sistem client server
4. Tidak tersedianya produk dan tools pengembangan sistem client server
5. Sedikitnya applikasi client server
6. Sedikitnya standar nasional dan internasional untuk sistem client server.
145
B. SOFTWARE ENGINEERING UNTUK SISTEM CLIENT SERVER
Arsitektur Client Server mendominasi sistem komputer kebanyakan hari ini .Semua ,
dari ATM sampai internet ada karena software yang berada di satu komputer – client , meminta
servis atau data dari komputer lainnya – server . Arsitektur Client/Server , menggabungkan
prinsip konvensional , konsep dan metode dari Object-Oriented dan Component based Software
engineering .
Kenapa Client/Server Software Engineering begitu penting ? Dampak dari sistem
client/server (c/s) pada pemerintahan , bisnis , komersial , dan lingkunan sains sangat terasa .
Dan perkembangan teknologi Software Engineering ( Component based – Software
development , object request broker , java ,dsb) merubah jalan untuk mengembangkan sistem
c/s . Proses Software Engineering yang solid harus diaplikasikan terhadap konstruksi sistem c/s.
Langkah – langkah yang harus diambil untuk mengembangkan sistem c/s mirip
dengan langkah – langkah yang diterapkan pada Object Oriented dan Component-Based
software engineering . Model Proses nya evolusioner , dimulai dengan pemilihan requirement .
Fungsionalitas di alokasikan ke subsistem dari komponen yang nantinya akan diterapakan baik
ke client ataupun ke server dari arsitektur c/s Struktur dari Sistem Client/Server
Di dalam sturktur Client/Server , komputer yang berada di atas komputer lainnya itu
disebut server ,dan komputer – komputer yang berada di bawah komputer server di sebut
client .
Struktur yang digambarkan pada gambar di atas tidaklah paten, dapat dirubah– rubah
sesuai dengan kebutuhan, asalkan masih tetap dalam konteks arsitektur yang digambarkan di
atas Komponen Software untuk sistem c/s
146
Arsitektur Client/Server tidak mengimplementasikan suatu software sebagai suatu
aplikasi monolitik yang hanya diterapkan pada satu mesin, sehingga arsitektur c/s
membutuhkan lebih dari satu mesin untuk diterapkan. Arsitektur c/s juga memiliki beberapa
subsistem yang berbeda yang dapat dialokasikan ke client, ke server ataupun ke kedua mesin :
User Interaction / Presentation Subsistem .
Subsistem ini mengimplemetasikan semua fungsi yang tergabung dalam Graphical
User Interface , Gunanya untuk berinteraksi dengan user dan terletak di client.
Application subsystem
Subsistem ini mengimplementasikan requirement yang didefiniskan aplikasi dengan
konteks dari domain dimana aplikasi tersebut beroperasi. Contohnya, aplikasi bisnis bisnis
memproduksi berbagai macam laporan cetak yang berdasarkan input numeric, kalkulasi,
informasi database dan sumber – sumber yang lainnya. Contoh lain adalah Sebuah aplikasi
groupware dapat menyediakan fasilitas bulletin board atau e-mail. dimana pada kedua kasus,
software aplikasi dapat dipartisi menjadi komponen yang berada baik di server ataupun di
client.
Database Management Subsistem
Subsistem ini melakukan pemanipulasian data dan manajemen yang harus di lakukan
oleh sebuah aplikasi . Manipulasi data dan manajemen mungkin semudah pencatatan sebuah
baris, dan mungkin dapat sekompleks memproses transaksi SQL yang rumit.
Distribusi dari Komponen Software
Setelah requirement dari aplikasi c/s ditentukan , maka Perancang Software harus
menentukan bagaimana pendistribusian komponen software yang dibutuhkan oleh client dan
server secara tepat.
Saat semua fungsi dari ketiga subsistem di atas dibebankan kepada server, maka
sebuah fat server design terbentuk. sebaliknya , jika client mengimplementasikan banyak dari
user interaction / presentation , application , dan database komponen , maka sebuah fat client
terbentuk. Fat Client biasa nya dapat ditemukan saat arsitektur file server dan database server
diterapkan . Pada kasus ini , server menyediakan manajemen data , tetapi aplikasi lainnnya dan
GUI terletak pada client.
147
Fat Server biasanya ditemukan pada desain sebuah sistem transaksi dan groupware .
Server menyediakan dukungan aplikasi yang diperlukan untuk melakukan transaksi dan
komunikasi dilakukan dari client . Software di client hanya fokus kepada GUI dan manajemen
komunikasi .
Distributed Presentation.
Pada pendekatan client/server, logika database dan logika aplikasi berada pada server,
biasanya sebuah mainframe. Server juga berisi aplikasi untuk menyiapkan tampilan informasi.
Contohnya adalah Virtual Class, Semua aplikasi baik database, tampilan ataupun logika aplikasi
terletak di server, client hanya membutuhkan sebuah browser untuk menampilkan GUI yang
disediakan oleh server.
Remote Presentation
Adalah sebuah extensi dari pendekatan distributed presentation , primary database dan logika
aplikasi terletak di server , dan data akan dikirimkan ke client untuk ditampilkan menggunkan
GUI yang berada di client.
Distributed Logic
Client memiliki semua fungsi user presentation dan sebuah fungsi yang berkaitan dengan data
entry. Seperti field-level validation, server query formula (SQL), dan server update information.
Server hanya menjalankan pekerjaan dan proses yang diberikan oleh client query, Server file
updates, client version control, dan aplikasi yang berkaitan tentang itu.
Remote data management. Aplikasi yang berada di server membuat sebuah data sourcedengan
format data yang telah di extrak dari tempat lain (contohnya dari corporate level source).
Aplikasi di alokasikan di client digunakan untuk mengevaluasi data yang telah di format oleh
server. Decission support system termasuk ke dalam kategori ini.
Pedoman untuk Mendistribusikan Subsistem dari Aplikasi
Presentation / Interaction subsitem terletak di client. Ketersediaan PC, lingkungan windows dan
kekuatan kopmuter dibutuhkan oleh gui untuk membuat pendekatan ini efektif dalam hal biaya.
Jika database di share oleh beberapa user yang terhubung dengan LAN, maka database ditaruh
di server . DBMS dan kemampuan akses database juga ditaruh di server bersamaan dengan
fisik database
Data statis yang digunakan sebagai referensi terletak di client. Peletakan data dekat dengan
user meminimalisir trafik jaringan yang tidak perlu.
148
Analisis Pemodelan
Kebutuhan aktifitas pemodelan untuk sistem c/s sedikit berbeda dari metode pemodelan yang
diaplikasikan ke arsitektur komputer konvensional .Oleh karena itu prinsip dasar analaisis dan
metodologi pemodelan dapat diterapkan di software c/s. Dengan catatan , bahwa kebanyakan
sistem c/s yang modern menggunakan komponen yang reusable.
Karena analisis pemodelan menghindari spesifikasi dari detail implementasi, maka isu – isu
yang berkaitan dengan alokasi komponen ke klien dan server hanya berupa desain.
Desain arsitektur untuk sistem client/server
Desain arsitektur dari c/s seringkali dinyatakan sebagai communicating processes style :
Tujuannya adalah untuk mencapai qualitas kestabilan. Sebuah server ada untuk melayani satu
atau lebih client untuk kebutuhan penyediaan data. Yang mana terletak di jaringan. Client
mengorganisasi panggilan ke server , yang bekerja secara asynchronous ataupun synchronous.
Jika server bekerja secara synchronous , maka akan ia akan mengembalikan control ke client
bersamaan dengan dengan pengembailan data. Jika server bekerja secara asynchronously,
maka hanya akan mengembalikan data (Tanpa kontrol) ke Client.
Pendekatan Desain Konvensional untuk software Aplikasi
Di sistem c/s, DFD dapat digunakan untuk membangun system scope, mengidentifikasi fungsi
high-level , menentukan area data , membolehkan dekomposisi dari high-level function. tetapi,
biar bagaimanapun dekomposisi hanya berhenti pada proses bisnis awal, dan tidak berlanjut
sampe ke level proses yang lebih kecil.
Di konteks c/s, sebuah Elementary business process (EBP)–Proses bisnis awal, didefinisikan
sebagai satu set tugas yang di lakukan tanpa henti oleh satu user pada client. Tugas tersebut
dilakukan sekaligus atau tidak sama sekali.
ERD juga bias digunakan untuk memperluas role. ERD dapat digunakan untuk mendokompisi
subject data area (data stores) lebih lanjut dari DFD untuk membangun high-level view dari
database yang akan diimplemtasikan dengan RDBMS.
Desain Database
Sebuah RDBMS dapat dijadikan sebagai solusi untuk desain database. RDBMS dapat
mendistribusikan data dengan mudah lewat SQL. keuntungan SQL dsebagai aristektur c/s
adalah “nonnavigational”. Di dalam RDBMS, tipe data dapat dispesifikan dengan menggunakan
SQL , tanpa menggunakan informasi navigational. implikasi dari hal ini adalah RDMBS harus
handal dalam memilihara lokasi dari data dan kapabel dalam mendefinisikan jalur terbaik untuk
149
hal itu. Dalam database system yang kurang handal, request untuk data, harus
mengindikasikan apa yang harus diakses, dan dimana harus mengakses data tersebut. Harus
dicatat, bahwa distribusi data dan teknik memanaje tersedia untuk desainer, antara lain :
• Manual extract : User diperbolehkan untuk mengcopy secara manual data yang
diinginkan dari server ke client . Pendekatan ini sangat berguna apabila data
statis diperlukan dan kontrol dari pengekstrakan dapat dihandle oleh user.
• Snapshot : teknik ini mengotomatisasi manual extract dengan menentukan
sebuah “snapshot” dari data yang harus di transfer dari server ke client pada
interval yang telah ditentukan . Pendekatan ini sangat berguna untuk
mendistribusikan data statis yang jarang diupdate.
• Replication : teknik ini dapat digunakan apabila banyak kopi dari data harus
dijaga pada situs yang berbeda (contoh : antara server yang berbeda atau
antara client dan server) , disini level kompleksitas meningkat karena konsistensi
data , update , keamanan , dan pemrosean harus di koordinasi pada banyak
situs.
• Fragmentation : Pada pendekatan ini, sistem database di fragmentasi lewat
beberapa mesin. Walaupun sangat menggiurkan dalam teori, namun
fragmentation sangat sulit diimplementasikan dan jarang ditemui.
Overview dari pendekatan desain
Langkah untuk mendesain sebuah proses bisnis awal (EBP – Elementary Business Process) yang
mengombinasikan elemen dari desain konvesional dengan element dari object oriented desain.
Dengan asumsi bahwa requirement model yang mendefinisikan objek bisnis telah dibuat dan
diperbaharui lebih dulu dari pendesainan EBP.
Langkah–langkah berikut ini untuk membuat desain :
1. Untuk setiap proses bisnis , identifikasikan file yang akan dibuat , di update , dan
direferensi , atau dihapus
2. Gunakan file yang didapat dari langkah 1 sebagai basis untuk mendefinisikan
komponen atau objek
3. Untuk setiap komponen , gunakan business rule an informasi objek bisnis lain yang
telah di buat untuk file yang bersangkutan.
4. Tentukan rule yang relevan dengan proses dan dekomposisi rule tersebut ke level
method
150
5. Jika diperlukan , tentukan komponen tambahan lainnya yang dibutuhkan untuk
mengimplementasikan method yang akan di buat di pada step 4
Iterasi proses desain .
Desain yang digunakan untuk merepresentasikan business object juga digunakan untuk
merepresentasikan interface, application , dan database object :
· Methods menjelaskan bagaiman business rule diimplementasikan
· Elementary proses mendefinisikan business proses yang di identifikasikan di model
analisis
· Process mengidentifikasikankomponenyang membuat solusi untuk Elementary
Business Process
· Component mendeskripsikan komponen yang tertera di structure chat
· Business Rule mengidentifikasikan komponen yang siginfikan terhadap
implementasi dari business rule yang diberikan
C. DESAIN UNTUK CLIENT-SERVER SISTEM
Ketika perangkat lunak dikembang untuk implementasi dengan menggunakan arsitektur
komputer tertentu, pendekatan desain harus memperhatikan lingkungan konstruksi tertentu.
Saat perangkat lunak dirancang untuk implementasi dengan memakai arsitektur client-server,
pendekatan desain harus disesuaikan dengan :
a. Desain data mendominasi proses desain
b. Ketika dipilih pola event-driven, behavioral modelling harus diterapkan dan aspek control-
oriented yang ada pada model behavioral harus diubah dalam model desain
c. Komponen interaksi/presentasi pemakai dari sistem client-server menerapkan semua fungsi
yang biasa dihubungkan dengan interface pemakai grafis
d. View desain OO sering dipakai
1. Pendekatan Desain Kovensional
Dalam sistem C/S DFD dapat dipakai untuk membuat lingkup sistem, untuk
mengenali fungsi tingkat tinggi dan area data subjek, serta untuk mengijinkan
dekomposisi/perombakan fungsi tingkat tinggi. Dalam konteks C/S EBP (Elementary
Bussiness Process) dapat digambarkan sebagai sekumpulan tugas yang
dilaksanakan tanpa “break” oleh seorang pemakai pada tempat client. ERD juga
punya peran tambahan. ERD masih dipakai untuk merombak area data subjek dari
DFD untuk membuat view database yang high-level yang akan dipasang dengan
memakai RDMS. Peran barunya adalah menyediakan struktur yang dipakai untuk
151
menentukan objek bisnis high-level. Struktur chart itu tidak dipakai sebagai alat
dekomposisi fungsional, tetapi dipakai sebagai diagram assembly untuk
menunjukkan komponen-komponen yang terlibat dalam solusi proses bisnis dasar.
Komponen-komponen tersebut, yang terdiri dari objek interface, objek aplikasi dan
objek database, menentukan cara pemrosesan data.
2. Desain Database
Desain database dipakai untuk menggambarkan dan kemudian menentukan
struktur objek bisnis yang dipakai dalam sistem C/S. Analisis yang dipakai untuk
mengenali objek bisnis dilakukan dengan menggunakan metode perekayasaan
informasi.
Tabel individual dipakai untuk menentukan informasi desain bagi database C/S
berikut ini :
- Entity : diidentifikasi di ERD untuk sistem yang baru
- File : yang memasang entity yang diidentifikasikan di ERD
- File-to-file Relationship (hubungan antar file) : membentuk layout untuk file
tersebut dengan mengidentifikasi field mana masuk ke file mana
- Fields : mendefinisi field dalam desai (kamus data)
- File to file Relationships : mengidentifikasi file terkait yang dapat digabungkan
untuk membuat view logis atau queriess.
- Relationship Validation : mengidentifikasi jenis file-to-file atau file-to-field
relationship yang dipakai untuk validasi
- Field Type : dipakai untuk memungkinkan pewarisan karakteristik field dari field
superclass (misal : tanggal, text, angka, nilai dan harga)
- Data type : yaitu karakteristik data yang tersimpan di field.
- File type : dipakai untuk mengenali lokasi suatu file
- Field function : yaitu key/kunci, foreign key/kunci asing, atribut, field virtual,
field anakan/derived dll
- Allowed values/nilai yang boleh : mengenali allowed values untuk field status
type
- Bussiness rules : aturan untuk mengedit, menghitung derived field dan lain-lain
Distribusi data yang lain dan tekhnik manajemen juga tersedia bagi para desainer,
yaitu :
152
- Manual extract
- Snapshot
- Replikasi
- Fragmentasi
3. Tinjauan Singkat terhadap Pendekatan Desain
Porter mengasumsikan bahwa model persyaratan yang menggambarkan objek
bisnis sudah dikembangkan dan dipercanggih sejak awal desain proses bisnis dasar.
Langkah berikut dipakai untuk membuat desain tersebut :
1) Untuk tiap EBP, tentukan dulu file yang dibuat, diperbarui, dirujuk atau dihapus
2) Gunakan file yang sudah ditentukan pada langkah 1 sebagai basis untuk
menentukan komponen atau objek
3) Untuk tiap komponen, gunakan aturan bisnis dan informasi objek bisnis lain
yang telah dibangun untuk file yang relevan
4) Tentukan aturan mana yang cocok untuk proses itu, dan uraikan aturan itu
dalam tingkat metode
5) Kalau perlu, tentukan komponen tambahan lain yang perlu untuk memasang
metodenya.
4. Iterasi Desain Proses
Repositori desain yang digunakan untuk menyajikan objek bisnis juga dipakai untuk
menyajikan interface, dan objek bisnis juga dipakai untuk menyajikan interface,
aplikasi dan objek database. Entitas yang harus diperhatikan :
a. Metode : menjelaskan bagaimana aturan bisnis diimplementasi
b. Proses dasar : menentukan proses bisnis dasar yang diidentifikasi dalam model
analisis
c. Process/componen link : mirip dengan rekening material dalam
pemanufakturan. Tabel ini mengidentifikasi komponen yang membuat solusi
untuk proses bisnis dasar.
d. Komponen : menggambarkan komponen yang ditunjukkan pada bagan struktur
e. Bussiness rule/component link : mengidentifikasi komponen yang penting untuk
implementasi aturan bisnis tertentu.
5. Masalah Pengujian
Sifat sistem C/S terdistribusi memiliki sekumpulan masalah unik bagi para penguji
perangkat lunak. Ada beberapa fokus perhatian yang disarankan oleh Binder :
153
a. Client GUI
b. Lingkungan target dan keanekaragaman platform
c. Database terdistribusi
d. Pemrosesan terdistribusi
e. Lingkungan target yang tidak kuat
f. Hubungan kinerja yang nonlinear
Strategi dan taktik yang dikaitkan dengan pengujian C/S harus dirancang
sedemikian rupa sehingga masalah tersebut dapat ditangani
1.0. Windows testing (GUI)
1.1. Identifikasi Skenario Bisnis
1.2. Pembuatan Test Case
1.3. Verifikasi
1.4. Peranti-peranti tes
2.0. Server
2.1. Pembuatan Data Tes
2.2. Pengujian Volume/Tekanan
2.3. Verifikasi
2.4. Peranti-peranti tes
3.0. Konektivitas
3.1. Kinerja
3.2. Pengujian Volume/tekanan
3.3. Verifikasi
3.4. Peranti-peranti tes
4.0. Kualitas teknis
4.1. Definisi
4.2. Identifikasi cacat
4.3. Metrix
4.4. Kualitas kode
4.5. Peranti-peranti tes
5.0. Pengujian fungsional
5.1. Definisi
5.2. Pembuatan Data Tes
5.3. Verifikasi
5.4. Peranti-peranti Tes
6.0. Pengujian Sistem
6.1. Definisi
6.2. Pengujian Usabilitas
154
6.3. Survei Kepuasan Pemakai
6.4. Verifikasi
6.5. Peranti-peranti Tes
7.0. Manajemen Pengujian
7.1. Tim pengujian
7.2. Jadwal Pengujian
7.3. Sumber daya yang diperlukan
7.4. Analisis Tes, Pelaporan dan Mekanisme Pelacakan
a. Strategi Pengujian C/S Keseluruhan
Pengujian perangkat lunak C/S terjadi pada tiga tingkat berbeda :
1. Aplikasi client individual diuji dalam cara yang “disconnect” artinya tidak
memperhatikan pengoperasian server dan jaringan yang membawahinya.
2. Perangkat lunak client dan aplikasi server terkaitnya diuji bersama-sama tetapi
pengoperasian jaringannya tidak dijalankan sepenuhnya.
3. Arsitektur C/S sepenuhnya, termasuk operasi jaringan dan penampilannya diuji
Cara pengujian berikut biasa dijumpai untuk aplikasi C/S :
1. Tes fungsi aplikasi
2. Tes server
3. Tes database
4. Pengujian transaksi
5. Pengujian komunikasi jaringan
155
b. Taktik pengujian C/S
Teknik uji yang object-oriented dapat selalu dipakai, bahkan bila sistem
C/S belum dipasang dengan memakai teknologi objek, karena data
replikasi dan prosesnya dapat diatur dalam kelas-kelas objek yang
punya sekumpulan properti yang sama. Sekali tes case sudah diambil
untuk suatu kelas objek, tes case harus dapat diaplikasikan untuk
semua jenis kelas.
Pandangan OO sangat berharga ketika kita mempertimbangkan
interface pemakai grafis dari sistem C/S modern. GUI bersifat OO dan
terpisah dari interface tradisional karena GUI harus beroperasi di
banyak platform. Pengujian tersebut menjadi lebih rumit karena
objeknya dapat ada dan tidak, objeknya dapat ada selama waktu yang
lama, dan dapat muncul dimana saja pada desktop.
Capture/playback tradisional merekam input sebagai keystroke dan
output sebagai citra layar yang disimpan untuk diperbandingkan
dengan citra input dan output dari tes selanjutnya. Capture/playback
terstruktur didasarkan pada pandangan internal (logika) terhadap
aktivitas eksternal.
156
BAB 11 WEB ENGINEERING
Web Enginerring (Rekayasa web) adalah proses yang diunakan untuk menciptakan
aplikasi web yang berkualitas tinggi. Rekayasa web mengadaptasi rekayasa perangkat lunak
dalam hal konsep dasar yang menekankan pada aktifitas teknis dan manajemen. Namun
demikian adaptasi tidak secara utuh, tapi dengan perubahan dan penyesuaian. Rekayasa web
gabungan antara web publishing (suatu konsep yang berasal dari printed publishing) dan
aktifitas rekayasa perangkat lunak. Dikatakan demikian karena desain sebuah aplikasi web
menekankan pada desain grafis, desain informasi, teori hypertext, desain sistem dan
pemrograman.
Ciri dan sifat WebApp (Web Application)
Aplikasi web berbeda dari software lain karena hal-hal dibawah ini:
1. Network intensive. Sifat dasar dari WebApp (aplikasi web) adalah aplikasi
ini ditujukan untuk berada di jaringan dan memenuhi kebutuhan komunitas
yang berbeda.
2. Content-Driven. Sebagian besar fungsi dari WebApp adalah untuk menyajikan
informasi dalam bentuk teks, grafik, audio dan video ke end user.
3. Continuous evolution. Selalu berkembang secara terus menerus.
4. Document-oriented. Halaman-halaman situs yang statis akan tetap ada sekalipun
sudah ada pemrograman web dengan java atau yang lain.
Selain itu WebApp memiliki karakteristik seperti berikut ini :
1. Immediacy. Diperlukan segera untuk memenuhi ditayangkan, dipasarkan dalam
waktu singkat.
2. Security. Untuk melindungi isi yang sensitif dan menyediakan pengiriman data yang
aman, keamanan suatu WebApp harus diterapkan pada seluruh infrastruktur yang
mendukung WebApp dan termasuk dalam WebApp sendiri.
3. Aesthetics. Daya tarik utama WebApp adalah tampilan dan keindahan. Jika WebApp
digunakan untuk memasarkan suatu produk maka sisi aestetika harus diperhatikan
sebagaimana sisi teknis.
157
Faktor-faktor yang menentukan kualitas suatu web digambarkan pada gambar dibawah.
Faktor-faktor kualitas pada gambar 1 adalah faktor-faktor yang membantu web developer
dalam merancang dan membangun webapp yang dapat diterima dan memenuhi kebutuhan end
user yang begitu beragam. Untuk memenuhi faktor-faktor kualitas tersebut, perancangan dan
implementasi webapp terkait dengan 3 teknologi yang sangat penting yaitu: component-
based development, security dan standart Internet. Seorang web developer harus mengenal 3
teknologi ini untuk membangun webapp yang berkualitas:
• Component-based development : CORBA,DCOM/COM dan JavaBeans
merupakan standar yang memungkinkan web developer menggunakan
komponenkomponen yang sudah ada untuk berkomunikasi dengan sistem pada level
lain.
• Keamanan: enkripsi, dan firewall
• Standard Internet: HTML, XML
Proses Rekayasa Web
Model yang dianggap cocok dan baik untuk rekayasa web adalah model modified waterfall dan
spiral.
• Modified waterfall
Tahapan dalam modified waterfall adalah :
1. Problem definition dan concept exploration.
2. Requirement analysis specification.
3. Design prototyping.
4. Implementation and unit testing
5. Integration and system testing
6. Operation and maintenance
158
pada modified waterfall, perbedaan berada pada 2 proses pertama yang
dilakukan secara berulang-ulang sehingga disebut whirlpool. Tujuannya adalah
dapat melengkapi requirement dan analisis secara lengkap.
• Spiral
Pada spiral terbagi beberapa sektor yaitu :
1. Determine site objectives and constraints.
2. Identify and resolve risks.
3. Develop the deliverables for the interation and verify that they are correct.
4. Plan the next iteration.
Spiral model sangat masuk akal untuk rekayasa web tapi rumit dan sulit
dalam pengaturan. Dibandingkan dengan waterfall, tahapan-tahapan pada spiral tidak
jelas dimana mulai dan dimana akhir. Pada prakteknya spiral berguna
selama perencanaan karena mengurangi resiko dan mendorong tim developer
untuk memikirkan apa yang paling penting.
Formulasi dan Analisis sistem berbasis web
Formulasi dan analisis sistem dan aplikasi berbasis web adalah serangkaian aktifitas rekayasa
web yang dimulai dengan identifikasi tujuan dan diakhiri dengan pembangunan analisis model
atau spesifikasi requirement sistem.
Formulasi
Formulasi memungkinkan klien dan pembangun untuk menetapkan tujuan-
tujuan pembangunan web. Beberapa pertanyaan berikut dapat membantu menentukan tujuan :
• Apa motivasi utama pembangunan WebApp?
• Mengapa WebApp diperlukan?
• Siapa yang akan menggunakan WebApp?
Ada dua macam tujuan:
• Informational goals—tujuan dari penyajian isi atau informasi kepada end
• Applicative goals—berkaitan dengan kemampuan yang dimiliki WebApp
Analisis rekayasa web
Ada 4 tipe analisis dalam rekayasa web:
1. Content Analysis. Isi yang akan disajikan oleh WebApp dalam ditentukan formatnya
baik itu berupa text, grafik dan image, video, dan audio.
2. Interaction Analysis. Cara interaksi antara user dan WebApp dijelaskan.
3. Functional Analysis. Menentukan operasi yang akan diaplikasikan pada WebApp dan
termasuk di dalamnya fungsi-fungsi yang melakukan proses. Semua operasi dan fungsi
dideskripsikan secara detil.
159
4. Configuration Analysis. Lingkungan dan infrastruktur dimana WebApp akan diberada
digambarkan secara detil.
Beberapa contoh aplikasi berbasis web yang paling banyak digunakan sekarang adalah seperti:
a) Aplikasi penjualan seperti Amazon
b) Jejaring sosial seperti Facebook
c) Perbankan seperti klikBCA
d) Mesin Pencari seperti Google
e) Informasi interaktif seperti Wikipedia
f) Surat elektronik seperti Yahoo Mail
g) Web logs seperti Wordpress
Keuntungan dan Tantangan Aplikasi Berbasis Web
Tidak sulit untuk melihat mengapa aplikasi berbasis web meningkat begitu pesat. Beberapa
faktor teknis telah memicu perkembangan revolusi penggunaan internet, diantaranya
adalah :
1. Hyper Text Transfer Protocol ( HTTP), protokol komunikasi inti yang digunakan dalam mengakses web cukup ringan dan dapat bersifat connectionless , yaitu langsung terkoneksi tanpa harus melakukan otentifikasi digital.
2. Semua pengguna web telah mempunyai perambah (browser ) yang telahlangsung terinstall di komputer mereka. Aplikasi web yang antramuka penggunanya didistribusikan menggunakan perambah, sehingga pengguna tidak perlu memasang perangkat lunak independen sebagai syarat pemasangan aplikasi. Perangkat lunak hanya perlu diinstall sekali pada server, danlangsung bisa dijalankan pada semua komputer klien, karena secara langsungmereka telah memiliki perambah saat mereka memasang sistem operasi.
3. Saat ini perambah telah mempunyai fitur yang sangat mudah digunakan,selain itu juga antarmuka yang disuguhkan cukup kaya dan memuaskan.Antarmuka web menggunakan navigasi standard dan kontrol masukan yangmudah dikenali oleh pengguna, sehingga pengguna tidak perlu mempelajari fungsi-fungsi khusus pada aplikasi tertentu.
4. Bahasa pemrograman yang digunakan untuk mengembangakan aplikasi berbasis web, relatif cukup mudah. Sudah banyak perkakas pengembanganyang dapat digunakan untuk mengembangakan perangakat lunak berbasis websecara mudah, bahkan oleh pengguna pemula sekalipun. Di samping itu, banyak juga perkakas pengembangan perangkat lunak berbasis web yang bersifat sumber terbuka dan dapat digunakan siapa saja tanpa harus membayar royalti. Juga banyak contoh aplikasi berbasis web yang
160
dapat digunakan dandicontoh bahkan dapat di-edit secara mudah karena bersifat sumber terbuka.
Selain mempunyai keuntungan sebagaimana dijelaskan, karena aplikasi berbasis web adalah perangkat lunak yang didistribusikan secara bebas melaluiinternet. Pengunjung atau pengguna perangkat lunak ini sangat bervariasi baik dari segi perangkat keras yang digunakan termasuk resolusi monitor dan kecepatan prosesor, juga dari segi perangkat lunak seperti sistem operasi yangmungkin berbeda dan juga perangkat perambah yang bervariasi.
Sebab itulah ada beberapa aspek khusus yang perlu dipertimbangan pada pengembangan perangkatlunak berbasis web :
a. Desain yang mudah digunakan. Kemudahan antarmuka perangkat lunak berbasis web mutlak diperlukan, karena seringkali pengunjung dari websitemempunyai keahlian yang bervariasi dalam penggunaan komputer.
b. Kaya konten. Maksudnya adalah perangkat lunak berbasis web, terutamayang berbasis internet harus selalu up to datemengikuti perkembangan yangada. Website yang isinya tidak pernah berubah akan segera kehilangan pengunjungnya karena bosan.
c. Skalabilitas. Tidak seperti aplikasi berbasis desktop yang bisa menentukanspesifikasi (kebutuhan minimal) perangkat keras dan perangkat lunak yangdigunakan, aplikasi berbasis web seharusnya dapat dijalankan dimana sajatergantung dengan spesifikasi komputer pengunjung.
d. Kesimbangan performa. Karena melalui jaringan yang kecepatan transfer datanya tidak secepat kabel komputer desktop, maka perlu dipertimbangkan performa aplikasi berbasis web. Juga perlu dipertimbangkan penggunaanskrip sisi server atau sisi klien secara tepat sehingga dapat mengoptimalkan performa aplikasi tersebut.
e. Kemanan. Ini merupakan hal yang sangat diperhatikan untuk aplikasi berbasisweb melalui internet, karena begitu suatu web dihosting di internet, maka semua orang (baik yang bertujuan baik dan buruk) dapat mengaksesnya.Sebab itulah perangkat lunak berbasis web yang dibuat, harus menjamin keamanan perangkatnya dan juga data yang disimpan di dalamnya.
f. Integrasi sistem. Semakin banyak perusahaan yang menginginkan penyatuan data yang tersebar pada beberapa tempat, dan seringkali data tersebut disimpan dengan teknologi yang berbeda oleh pengembang yang berbeda.Sebab itulah sebisa mungkin aplikasi berbasis web mampu mengintegrasikandata yang dimiliki dengan data yang mungkin didapat dari sumber lain, atausebaliknya perangkat lunak tersebut harus menjamin data yang disimpandapat diintegrasikan dengan sistem lain dengan perantara midleware.
g. Kecepatan pengembangan. Perangkat lunak yang dirancangan dengan baik dan dengan kualitas yang bagus adalah suatu keuntungan. Sebab itulahkecepatan
161
waktu implementasi akan memberikan keuntungan dalam pengembangan, yaitu memperpanjang waktu perancangan dan testing.
A. ATRIBUT DARI APLIKASI WEB
Ada beberapa atribut dasar yang dimiliki aplikasi berbasis web dalam membedakan dengan
aplikasi komputer biasa.
1. Network Intensiveness
Suatu aplikasi web harus membutuhkan jaringan guna menyediakan layanan pada klien
yang tersebar luas di berbagai penjuru dunia. Aplikasi web juga setidaknya bisa
ditempatkan dalam Internet (komunikasi seluruh dunia), Intranet (komunikasi satu
organsisasi), dan Ethernet (komunikasi 2 perangkat).
2. Concurrency
Dapat diakses oleh banyak user pada saat yang bersamaan.
3. Unpredictable load
Jumlah pengunjung aplikasi web tidak dapat di prediksi jumlahnya dari hari ke hari.
misal: hari senin ada 500 pengunjung, hari selasa ada 700 pengunjung, dll.
4. Performance
Kemampuan suatu aplikasi web dalam memproses, misal: bila proses loading suatu
web terlalu lama atau lambat, maka boleh jadi si user akan merasa tidak betah, dan
mencari web lain.
5. Availability
Ketersediaan suatu website untuk tetap hidup dan beroperasi, karena pada umumnya
suatu website diakses dalam waktu 24 jam 7 hari 1 tahun atau Non Stop. Entah itu
pada waktu pagi, siang, sore atau malam hari, tergantung dari masing-masing negara.
6. Data Driven
Fungsi-fungsi suatu aplikasi web dalam berbagai hal seperti menampilkan berbagai
media baik itu gambar, audio, video, text, mengakses informasi yang disimpan dalam
database, dll.
7. Content Sensitive
Kualitas dan estetika dalam suatu konten yang ditampilkan dalam suatu aplikasi web
menentukan kualitas dari web itu sendiri.
8. Continuous evolution
Aplikasi web akan terus berkembang karena sering terjadi update dari hari ke hari.
9. Immediacy
Kesegeraan suatu aplikasi web untuk dipublikasikan secara luas dan dimarketkan.
162
10. Security
Karena aplikasi web diakses dari berbagai penjuru dunia maka dibutuhkan proteksi dari
tangan-tangan jahil yang ingin melakukan tindakan negatif terhadap aplikasi web itu
sendiri, seperti pencurian informasi, plagiat konten, dll.
11. Aesthetics
Tampilan dalam suatu aplikasi web yang menarik untuk menjaring pengunjung
sebanyak-banyaknya.
B. DESAIN UNTUK WEB-BASED APPLICATION
Ada 3 tahapan dalam mendesain web based application :
1. Architectural design: Menggambarkan struktur WebApp
a. Struktur linier
• Urutan interaksi sudah bisa dipastikan.
• Misal untuk presentasi tutorial, pemesana produk yang harus mengikuti
urutan tertentu.
b. Struktur Grid
• Isi dapat dikatagorikan dalam 2 atau lebih dimensi
• Mmisal: e-commerce menjual handphone. Horizontal adalah katagori berdasarkan
feature hp, sedang vertikal adalah merek HP
163
c. Struktur jaringan / Pure Web
• Komponen pada struktur ini terhubung satu sama lain
• Sekalipun bersifat fleksibel, struktur ini membingungkan user
d. Struktur Hirarki
• Struktur paling umum digunakan.
• Memungkinkan aliran secara horizontal selain jalur vertikal yang umum.
• Aliran secara horizontal juga bisa mengakibatkan kebingungan user.
164
2. Navigation design: menentukan navigasi halaman-halaman web.
Setelah arsitektur WebApp sudah terbentuk dan komponen-komponen seperti halaman,
scripts, applet dan fungsi lain sudah ada, developer menentukan navigasi yang memungkinkan
user mengakses isi WebApp dan layananlayanannya. Jika user tidak bisa berpindah ke halaman
lain dalam web dengan mudah dan cepat maka mungkin karena grafik, dan isi tidak relevant,
ini masalah navigasi. Dalam desain navigasi beberapa hal perlu dilakukan :
• Menentukan semantik (arti ) dari navigasi untuk user yang berbeda.
• Menentukan cara yang tepat: pilihannya adalah text-based links, icons, buttons and
switches, and graphical metaphors
3. Interface design: membangun interaksi dengan user yang konsisten dan efektif.
User interface pada WebApp adalah kesan pertama. Sekalipun nilai isinya
baik, kemampuan prosesnya canggih, layanannya lengkap namun jika user interfacenya buruk
maka hal lain tidak berguna, karena akan membuat user berpindah ke web lain.
Beberapa petunjuk dalam merancang interface design :
• Server errors, menyebabkan user pindah ke website.
• Membaca di layar monitor lebih lambat 25% dari pada di kertas, karena itu teks jangan
terlalu banyak.
• Hindari tanda “under construction”.
• User tidak suka scroll. Pastikan informasi cukup dalam satu layar.
• Navigasi menu dan headbar harus konsisten.
• Keindahan tidak seharusnya lebih penting dari pada fungsinya
• Opsi navigasi harus jelas sehingga tahu bagaimana berpindah atau mencari hal lain
pada halaman aktif.
165
C. TESTING WEB-DESIGN APLICATION
Pengujian terhadap aplikasi berbasis WEB perlu dilakukan sebelum aplikasi tersebut
digunakan. Pengujian merupakan salah satu bagian yang paling penting dalam jaminan kualitas
aplikasi. Pengujian ini dilakukan untuk menemukan beberapa kesalahan yang disebabkan oleh
proses perancangan maupun proses implementasi yang belum benar.
Biasanya sebuah pengujian dilakukan oleh sekelompok tim yang sudah teroganisir.
Dalam pengujian aplikasi berbasis WEB ini tim tersebut akan menyusun beberapa langkah.
Menurut Krishen Kota terdapat 10 langkah dalam pengujian aplikasi berbasis WEB diantaranya
adalah :
1. Menentukan Sasaran Pengujian (Objective)
Sebelum melakukan sebuah pengujian kita harus menentukan beberapa sasaran
pengujian, agar pengujian yang akan dilakukan terarah. Sehingga seorang penguji dapat
menentukan beberapa prioritas pengujian dalam sebuah pengujian aplikasi.
2. Menentukan Proses dan Pelaporan Pengujian
Dengan menentukan proses pengujian dan susunan pelaporan pengujian, maka setiap
anggota dalam sebuah tim penguji akan mengerti aliran dari sebuah proses pengujian.
3. Memantau Hasil Pengujian (Tracking Results)
Ketika kita sudah memulai sebuah proses pengujian aplikasi, kita akan menemukan
beberapa error, bug, defect, dan sebagainya. Sehingga tim penguji membutuhkan cara
untuk menyimpan, mengorganisir dan mendistribusikan informasi tersebut kepada semua
anggota tim penguji. Tim juga akan membutuhkan cara untuk menjaga tim agar tetap
mendapat informasi status dari sebuah proses pengujian. Oleh karena itu, dalam sebuah
pengujian dibutuhkan pemantauan hasil (tracking results).
4. Menentukan Area Pengujian (Environment Test)
Menentukan area pengujian disini diartikan sebagai pembagian wilayah kerja dari sebuah
tim, misalkan sebuah tim penguji dibagi menjadi tiga area pengujian yaitu WEB server,
database server, dan application server.
5. Pengujian Kegunaan Aplikasi (Usability Testing)
Dalam tahap usability test ini kita akan mencoba meneliti tiga aspek yang berkaitan
dengan user’s experience diantaranya adalah :
o Apakah WEB application tersebut memiliki desain antarmuka yang konsisten?
o Seberapa mudahkah navigasi dari WEB application tersebut?
o Apakah feed back yang diberikan WEB application tersebut sesuai dengan keinginan
pengguna?
166
6. Pengujian Unit (Unit Testing)
Unit testing ini merupakan pengujian yang hanya fokus pada beberapa bagian kecil dari
fungsionalitas WEB application. Misalnya menguji kebenaran dari penyimpanan data
setelah pengguna menekan tombol “submit”.
7. Pengujian Kode HTML
Pengujian kode HTML ini bertujuan untuk menguji apakah aplikasi tersebut dapat
dijalankan pada bermacam-macam browser, resolusi layar dan OS yang berbeda.
Pengujian ini dapat dilakukan melalui http://validator.w3.org.
8. Load Testing
Pengujian ini dimaksudkan untuk mengukur seberapa lamakah sebuah halaman WEB
application di-load kedalam browser milik pengguna. Pada umumnya, sebuah halaman
dapat di-load kurang dari 15 detik.
9. User Acceptance Testing
Dengan melakukan pengujian ini, tim akan mengetahui apakah WEB application tersebut
sudah memiliki fungsi yang sesuai dengan keinginan pengguna atau belum. Pengujian ini
dapat dilakukan dengan menguji aplikasi versi Beta.
10. Pengujian Keamanan (Security Testing)
Tahap ini merupakan tahap akhir yang penting untuk mengetahui apakah WEB application
tersebut sudah memiliki sistem keamanan yang baik atau belum. Kita juga harus menguji
apakah WEB application tersebut aman terhadap serangan dari dalam maupun luar sistem.