Perangkat Lunak
DAFTAR ISI
BAB1.PENGANTARRPL...................................................................
..................................1
A. PENGERTIANRPL..................................................................
........................................................1
B. KEGUNAANRPL....................................................................
......................................................11
C. PERKEMBANGANRPL................................................................
.................................................12
D. DESKRIPSIRPL...................................................................
..........................................................12
E. KARAKTERISTIKRPL...............................................................
.....................................................13
F. KOMPONENRPL....................................................................
.....................................................13
G. APLIKASIRPL....................................................................
...........................................................13
BAB2.MANAGINGSOFTWAREPROJECTS........................................................
................15
A. PROJECTMANAGEMENTCONCEPT........................................................
....................................15
B. SOFTWAREPROJECTPLANNING.........................................................
........................................17
C. RISKANALYSISANDMANAGEMENT........................................................
..................................20
D. SQA...........................................................................
..................................................................24
BAB3.METODEKONVENSIONALUNTUKSOFTWAREENGINEERING................................26
A. SYSTEMENGINEERING..............................................................
.................................................26
B. REQUIREMENTENGINEERING.........................................................
...........................................30
BAB4.ANALISIS......................................................................
.........................................35
A. KONSEPDANPRINSIPANALISIS.........................................................
.........................................35
B. MODELANALISIS..................................................................
......................................................42
C. ANALISISTERSTRUKTUR............................................................
.................................................44
D. KAMUSDATA......................................................................
........................................................46
BAB5.DESAIN........................................................................
..........................................48
A. PROSESDESAIN...................................................................
.......................................................48
B. PRINSIPPRINSIPDESAIN............................................................
................................................50
C. KONSEPDESAIN...................................................................
.......................................................51
D. EFECTIVEMODULARDESIGN...........................................................
...........................................57
E. ARCHITECTURALDESIGN............................................................
................................................58
F. USERINTERFACEDESIGN............................................................
................................................62
BAB6.DESAINUNTUKSYSTEMREALTIME........................................................
.............64
A. SYSTEMREALTIME..................................................................
...................................................64
B. ANALISISDANSIMULASIUNTUKSYSTEMREALTIME............................................
................68
C. DESAINREALTIME...................................................................
.................................................75
BAB7.TEKNIKPENGUJIANPERANGKATLUNAK....................................................
...........77
A. DASARDASARPENGUJIANPERANGKATLUNAK.................................................
.......................77
B. TESTCASEDESIGN....................................................................
................................................78
C. WHITEBOXTESTING.................................................................
.................................................80
D. CONTROLSTRUCTURETESTING..........................................................
.......................................84
BAB8.STRATEGIPENGUJIANPERANGKATLUNAK.................................................
...........98
A. PENDEKATANSTRATEGISKEPENGUJIANPERANGKATLUNAK.......................................
...........98
B. MASALAHMASALAHSTRATEGIS.........................................................
.......................................99
C. PENGUJIANUNIT..................................................................
....................................................100
D. PENGUJIANINTEGRASI.............................................................
................................................102
E. PENGUJIANVALIDASI..............................................................
.................................................103
F. PENGUJIANSISTEM................................................................
..................................................103
G. PENGUJIANDEBUGGING.............................................................
.............................................104
BAB9.OBJECTORIENTEDSOFTWAREENGINEERING................................................
......109
A. KONSEPDANPRINSIPOBJECTORIENTED.....................................................
...........................109
B. OBJECTORIENTEDANALIS............................................................
............................................118
C. OOAVSCONVENSIONAL...............................................................
...........................................125
D. UNIFIEDMODELLINGLANGUAGE(UML)....................................................
..............................125
E. OBJECTORIENTEDDESIGN............................................................
...........................................135
BAB10.CLIENTSERVERSOFTWAREENGINEERING.................................................
........137
A. STRUKTURDARISISTEMCLIENTSERVER.....................................................
...........................137
B. SOFTWAREENGINEERINGUNTUKSISTEMCLIENTSERVER.........................................
............145
C. DESAINUNTUKCLIENTSERVERSISTEM.....................................................
..............................150
BAB11.WEBENGINEERING.................................................................
..........................156
A. ATRIBUTDARIAPLIKASIWEB...........................................................
........................................161
B. DESAINUNTUKWEBBASEDAPPLICATION.....................................................
........................162
C. TESTINGWEBDESIGNAPLICATION.......................................................
...................................165
BAB 1
PENGANTAR RPL
Rekayasa
perangkat
lunak
merupakan
sebuah
disiplin
ilmu
yang
bertujuan
mengembangkan sistem perangkat lunak yang efektif dari segi biaya. Perangkat lun
ak 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 scie
nce atau
ilmu komputer. Pada intinya computer science berhubungan dengan teori dan metode
yang
mendasari sistem komputer dan perangkat lunak. Sedangkan rekayasa perangkat luna
k
berhubungan
dengan
masalah-masalah
praktis
dalam
memproduksi
perangkat
lunak.
Pengetahuan tetang computer science sangat penting bagi perekayasa perangkat lun
ak sama
seperti pengetahuan tentang fisika sangat penting bagi teknik kelistrikan.
Istilah lain yang juga populer adalah rekayasa sistem atau rekayasa sistem berba
sis
komputer.
Rekayasa
sistem
berhubungan
dengan
pengembangan
perangkat
keras,
perancangan kebijakan dan proses, dan penyebaran sistem sebagaimana pada rekayas
a
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 seb
uah
produk dan peran kedua sebagai kendaraan yang mengantarkan sebuah produk (Pressm
an,
2002). Sebagai produk
perangkat lunak mengantarkan potensi perhitungan yang dibangun
oleh perangkat lunak komputer. Tidak peduli apakah perangkat lunak ada dalam tel
epon
seluler, dalam mainframe komputer. Perangkat lunak merupakan transformer informa
si yang
memproduksi,
mengatur,
memperoleh,
memodifikasi,
menampilkan
atau
menyebarkan
1
informasi dimana pekerjaan ini dapat menjadi sederhana suatu bit tunggal atau se
kompleks
simulasi multimedia. Sebagai kendaraan yang dipakai untuk mengantarkan produk, p
erangkat
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 membua
t
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 ya
ng
menghasilkan perangkat lunak. Kegiatan-kegiatan ini sebagian besar dilakukan ole
h 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 terse
but
harus dipenuhi.
3) Validasi perangkat lunak, perangkat lunak harus divalidasi untuk menjamin bah
wa
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 berbe
da
dan dijelaskan dengan tingkat kerincian yang berbeda pula. Waktu kegiatan bervar
iasi,
sebagaimana hasilnya.
Proses perangkat lunak sangat rumit dan seperti semua proses intelektual, bergan
tung
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.
2
Problem
Definition
Status
Quo
Solution
Integration
Teknikal
Development
Problem
Definition
Status
Quo
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)
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 perangka
t
lunak (analis) harus memahami domain informasi, tingkah laku, unjuk kerja, dan a
ntarmuka (interface) yang diperlukan. Kebutuhan baik untuk sistem maupun perangk
at
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 l
unak,
representasi interface, dan detail (algoritma) procedural. Proses desain menerje
mahkan
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 perangk
at
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 lengk
ap,
pembuatan kode dapat diselesaikan secara mekanis.
5. Pengujian
Sekali kode dibuat, pengujian program dimulai. Proses pengujian berfokus pada lo
gika
internal perangkat lunak, memastikan bahwa semua pernyataan sudah diuji, dan pad
a
eksternal fungsional yaitu mengarahkan pengujian untuk menemukan kesalahankesala
han 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 ak
an
terjadi karena kesalahan-kesalahan ditentukan, karena perangkat lunak harus
6
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 lu
as
dipakai dan paling tua. Tetapi kritik dari paradigma tersebut telah menyebabkan
dukungan aktif
untuk mempertanyakan kehandalannya (Hanna, 1995). Masalah-masalah yang kadangkada
ng
terjadi ketika model sekuensial linier diaplikasikan adalah:
a)
Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh mode
l.
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 unt
uk
mengakomodasi ketidakpastian natural yang ada pada bagian awal beberapa proyek.
c)
Pelanggan harus bersikap sabar. Sebuah versi kerja dari program-program itu tida
k 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 a
wal dan
akhir sebuah proses sekuensial linier.
Masing-masing dari masalah tersebut bersifat riil. Tetapi paradigm siklus kehidu
pan
klasik memiliki tempat yang terbatas namun penting di dalam kerja rekayasa peran
gkat lunak.
Paradigma itu memberikan template dimana metode analisis, desain, pengkodean, pe
ngujian,
dan pemeliharaan bisa dilakukan. Siklus kehidupan klasik tetap menjadi model bag
i rekayasa
perangkat lunak yang paling luas dipakai. Sekalipun memiliki kelemahan, secara s
ignifikan dia
7
lebih baik daripada pendekatan yang sifatnya sembrono kepada pengembangan perang
kat
lunak.
c.
Model Prototipe
Sering seorang pelanggan mendifinisikan serangkaian sasaran umum bagi perangkat
lunak, tetapi tidak melakukan mengidentifikasi kebutuhan output, pemrosesan, ata
upun
input detail. Pada kasus yang lain, pengembang mungkin tidak memiliki kepastian
terhadap
efisiensi algoritme, kemampuan penyesuaian dari sebuah system operasi, atau bent
ukbentuk yang harus dilakukan oleh interaksi manusia dengan mesin. Dalam hal ini
, serta
pada banyak situasi yang lain, prototyping paradigm mungkin menawarkan pendekata
n
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 gari
s besar
dimana definisi lebih jauh merupakan keharusan kemudian dilakukan perancangan kil
at.
Perancangan kilat berfokus pada penyajian dari aspek aspek perangkat lunak terseb
ut
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 me
menuhi
kebutuhan pelanggan, dan pada saat yang sama memungkinkan pengembang untuk
secara lebih baik memahami apa yang harus dilakukannya.
Membangun
Memperbaiki
Market
Mendengarkan
Pelanggan
Uji PelangganMengendalikan
Market
Gambar 1.4 Prototipe Paradigma
Secara ideal prototype berfungsi sebagai sebuah mekanisme untuk mengidentifikasi
kebutuhan perangkat lunak. Bila prototype yang sedang bekerja dibangun, pengemba
ng
harus mempergunakan fragmen-fragmen program yang ada atau mengaplikasikan alat-a
lat
8
bantu (contohnya report generator, window manager, dll) yang memungkinkan progra
m
yang bekerja untuk dimunculkan secara cepat.
Tetapi apa yang kita lakukan dengan prototype tersebut pada saat dia sudah melay
ani
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 pema
kaian,
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 ma
na
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
membangunnya dengan segera. Tetapi prototyping bisa juga menjadi masalah
bisa
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 prod
uk
harus dibangun lagi agar tingkat kualitas yang tinggi bisa dijaga, pelanggan aka
n
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 tida
k
9
sesuai bisa dipakai secara sederhana karena mungkin diperoleh dan dikenal; algor
itma
yang tidak efisien secara sederhana bisa diimplementasikan untuk mendemontrasika
n
kemampuan. Setelah selang waktu tertentu, pengembang mungkin mengenali pilihanpi
lihan 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 efe
ktif
bagi rekayasa perangkat lunak. Kuncinya adalah mmendefinisikan aturan-aturan mai
n 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 direka
yasa
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 v
ersi
sampai sistem yang memenuhi persyaratan diperoleh. Model pengembangan evolusione
r
dapat dilihat pada Gambar 1.5.
Penjelasan garis
besar
Spesifikasi
Versi awal
Pengembangan
Versi menengah
Versi akhir
Versi akhir
Validasi
Versi akhir
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 m
enjadi
program yang dapat dijalankan. Model pengembangan sistem formal dapat dilihat pa
da
Gambar 1.6.
10
11
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 m
etode
yang sistematis. Perkembangan perangkat lunak sebenarnya tidak dapat diatur samp
ai terjadi
jadwal yang bergeser, atau biaya yang mulai melonjak. Para pemrogram kemudian mu
lai
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 interk
asi
manusia dan komputer. Konsep ini membuka sebuah dunia aplikasi yang baru serta t
ingkat
kecanggihan perangkat lunak dan perangkat keras yang baru pula. Sistem real-time
dapat
mengumpulkan, menganalisis, serta mengubah data dari banyak sumber sehingga pros
es
pengontrolan dan penghasilan output tidak lagi berada dalam skala menit, melaink
an detik.
Kemajuan dalam penyimpanan online membawa ke generasi pertama sistem manajemen
database.
- 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 sem
ua aspek
produksi perangkat lunak. Mulai dari tahap awal spesifikasi sistem sampai pemeli
haraan 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 me
ncoba
mencari solusi terhadap permasalahan, walaupun tidak ada teori atau metode yang
12
mendukung. Perekayasa juga menyadari bahwa mereka harus bekerja dalam batasan
organisasi dan keuangan, sehingga mereka berusaha mencari solusi dalam batasan-b
atasan
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 proye
k
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 per
angkat
lunak dengan perangkat keras yang mendasar adalah:
1)
2)
Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuknya yang kla
sik.
Perangkat lunak tidak pernah usang.
Sebagian besar perangkat lunak dibuat secara custom (pemesanan) serta tidak dapa
t 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-ele
men 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 kualita
s
tinggi. Sebuah komponen perangkat lunak harus didesain dan diimplementasi sehing
ga dapat
dipakai lagi pada berbagai program yang berbeda. Komponen perangkat lunak dibang
un
dengan bahasa pemrograman yang memiliki kosakata terbatas, sebuah tata bahasa ya
ng
dibatasi secara eksplisit. Bahasa tingkat mesin merupakan perwakilan simbolik da
ri
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 proce
dural
(seperti algoritma) telah didefinisikan (pengecualian-pengecualian yang dapat di
catatat pada
aturan ini adalah sistem pakar dan jaringan syaraf tiruan dalam aplikasi kecerda
san buatan).
13
BAB 2
MANAGING SOFTWARE PROJECTS
15
2. Problem
Seorang manajer proyek perangkat lunak dihadapkan pada sebuah dilemma pada awal
proyek rekayasa perangkat lunak. Analisis yang mendetail tentang kebutuhan peran
gkat lunak
akan memberikan informasi yang memadai untuk suatu perhitungan, tetapi analis se
ring
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 berik
ut:
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 ad
a usaha
untuk secara penuh melakukan dekomposisi masalah. Dekomposisi diterapkan pada du
a 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 m
emilih
paradigm rekayasa perangkat lunak yang paling baik bagi proyek dan tugas rekayas
a perangkat
lunak.
16
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 y
ang
pertama menyerap 90 persen dari usaha dan waktu yang diberikan. Yang 10 persen t
erakhir
mengambil 90 persen lain dari usaha dan waktu yang diberikan.
Proses manajemen proyek perangkat lunak dimulai dengan serangkaian aktivitas yan
g
secara kolektif disebut project planning. Yang pertama dari aktivitas ini adalah
estimation
(perkiraan). Meskipun estimasi juga merupakan sebuah seni seperti juga pada sain
s, 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 s
emua
aktivitas perencanaan proyek yang lain, dan perencanaan proyek memberikan sebuah
peta
jalan bagi suksesnya rekayasa perangkat lunak, maka tanpa estimasi kita tidak da
pat berjalan
dengan baik.
lainnya.
Perencana
mempertimbangkan
sifat
dan
kompleksitas masing-masing interface untuk menentukan pengaruhnya terhadap sumbe
r daya,
biaya dan jadwal pengembangan.
3. Resource
Tugas selanjutnya dalam perencanaan proyek perangkat lunak adalah estimasi sumbe
r
daya yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak ters
ebut.
Gambar 2.1 memperlihatkan sumber daya pengembangan sebagai sebuah pyramid.
18
Dalam tingkat yang lebih tinggi kita menemukan komponen perangkat lunak reuseabl
e.
Blok bangungan perangkat lunak yang dapat mengurangi biaya pengembangan secara d
ramatis
dan mempercepat penyampaian. Di puncak piramida terdapat sumber daya utama yaitu
manusia (people). Masing-masing sumber daya ditentukan dengan empat karakteristi
k.
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.
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 da
lam langkahlangkah yang sistematis yang memberikan estimasi dengan resiko yang d
apat diterima.
19
Rencana
proyek (WBS,
biaya, staff,
perekrutan)
Informasi
histori
Output:
Sumbersumber risiko
Teknik:
Checklist
Flowchart
Wawancara
Potensi risiko
Tanda-tanda
risiko (trigger)
Input ke
proses
lainnya
Identifikasi risiko terdiri atas pengawasan dan penentuan risiko apa saja yang d
apat
mempengaruhi proyek serta mendokumentasikan setiap dari risiko tersebut. Identif
ikasi tidak
hanya dilakukan sekali, namun harus dilakukan sepanjang perjalanan proyek dari a
wal sampai
akhir.
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.
21
2)
Rencana proyek
a. Work breakdown structure: pendekatan pada deliverables setiap unit kerja seca
ra
detail. Dengan cara ini identifikasi terhadap risiko bisa sampai ke level yang s
angat
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 seki
tar
proyek dapat menyebabkan fluktuasi nilai kontrak proyek.
3)
Informasi historis. hal-hal yang pernah terjadi di masa lalu, dan berkaitan deng
an
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 knowle
dge.
Untuk teknik yang digunakan dalam proses identifikasi risiko adalah:
1)
Checklist: dari informasi (riset, dll) yang diperoleh dapat dibuat checklist yan
g 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.
o
tersebut.
22
2)
Kejadian yang berpotensi menjadi risiko: biasanya merupakan kejadian-kejadian lu
ar
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, s
ebabsebab 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 identifi
kasi risiko
memperkirakan bahwa harga barang kebutuhan utama proyek akan naik, maka ada baik
nya
pada penjadwalan, pembelian barang utama tersebut dilakukan di awal proyek.
g
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.
23
Output:
Setelah dianalisis, manajer proyek harus mampu memutuskan berbuat apa terhadap
risiko yang mungkin ada. Menerimanya, membuat rencana lanjutan atau mencari alte
rnatif 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 karakte
ristik
atau atribut dari sesuatu. Sebagai atribut dari sesuatu, kualitas mengacu pada k
arakteristik
yang dapat diukur, sesuatu yang dapat kita bandingkan dengan standar yang sudah
diketahui,
seperti panjang, warna, sifat kelistrikan, kelunakannya dan sebagainya. Tetapi p
erangkat lunak,
yang sebagaian besar merupakan entitas intelektual lebih menantang untuk dikarak
terisasi
daripada objek fisik.
Ada dua jenis kualitas yaitu kualitas desain dan kualitas konformasi. Kualitas d
esain
mengacu pada karakteristik yang ditentukan oleh desainer terhadap suatu item ter
tentu.
Kualitas konformansi adalah tingkat dimana spesifikasi desain terus diikuti sela
ma
pembuatan. Dalam pengembangan perangkat lunak kualitas desain mencakup syarat,
spesifikasi, dan desain sistem. Kualitas konformansi adalah suatu masalah yang d
ifokuskan
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 pro
duk
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. Konse
p 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.
24
3. Quality Assurance
Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen. Tujuan ja
minan
kualitas
adalah
untuk
memberikan
data
yang
diperlukan
oleh
manajemen
untuk
menginformasikan masalah kualitas produk, sehingga dapat memberikan kepastian da
n
kepercayaan bahwa kualitas produk dapat memenuhi sasaran. Jika data yang diberik
an melalui
jaminan kualitas mengidentifikasikan adanya masalah, maka adalah tanggung jawab
manajemen untuk menetapkan masalahnya dan mengaplikasikan sumber-sumber daya yan
g
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 biay
a 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 k
e dalam
biaya kegagalan internal dan eksternal. Biaya kegagalan internal adalah biaya ya
ng 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?
25
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. Selam
a
kuartal terakhir abad ke-20, sistem berbasis komputer telah memperkenalkan tatan
an baru.
Meskipun teknologi telah membuat langkah benar sejak pernyataan Machiavelli, ung
kapan
yang dikatakannya itu masih tetap bergema sampai sekarang.
Rekayasa perangkat lunak terjadi sebagai konsekuensi dari suatu proses yang dise
but
rekayasa sistem. Daripada berkonsentrasi semata-mata pada perangkat lunak, rekay
asa
sistem memfokuskan diri pada berbagai elemen, analisis, perancangan, dan pengorg
anisasian
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 disebu
t 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 komput
er
lainnya.
1. Computer Based System
Tujuannya mungkin adalah untuk mendukung berbagai fungsi bisnis atau untuk
mengembangkan suatu produk yang dapat dijual untuk menghasilkan keuntungan bisni
s. Untuk
mencapai tujuan tersebut, sistem berbasis komputer menggunakan berbagai elemen s
istem:
1)
Perangkat lunak.
26
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 si
stem
berbasis komputer yang lebih besar lagi. Sebagai contoh, perhatikansistem otomasi
sasi 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 nu
Gam
mbar 3.1 Siste
em Dari Banya
ak Sistem
Tingkat selanjutnya pa
ada hirarki, (Gambar 3.1
1) adalah se
sel pemanukf
kfaturan. Sel
peman
nukfaturan merupakan
m
s
siste
berbasiss komputer yang mem
miliki elemenn
nya sendiri
(misaln
nya, kompute
er, perlengkapan mekaniss) dan juga mengintegras
m
si elemen-ele
emen makro
yang kita
k sebut messin kontrol nu
umerik, robot dan perangka
at pemasukan
n data.
Singkatnya,, sel pemanu
ukfaturan dan
n elemen ma
akro masing--masing terdiri dari dari
elemen
n-elemen sisttem dengan label generik: perangkat lunak, perrangkat kerass, manus
ia,
databa
ase,
prosedu
ur,
dan
dokumentasi.
Dalam
banyyak
kasus,
elemen
ma
akro
dapat
mengg
gunakan elem
memastikan bahwa bisnis atau konteks teknologi yang tepat dapat dibangun. WV dip
erhalus
untuk lebih berfokus pada domain interes tertentu. Pada suatu domain tertentu, k
ebutuhan
untuk sistem yang ditargetkan (misalnya data, perangkat lunak, perangkat keras,
manusia)
dianalisis. Akhirnya, analisis, desain, dan konstruksi dari elemen yang ditarget
kan diinisiasi.
Pada puncak hirarki, suatu konteks yang luas dibangun, dan di bagian dasarnya ak
tivitas teknik
lengkap yang dilakukan oleh disiplin rekayasa yang relevan (misalnya, rekayasa p
erangkat
keras atau perangkat lunak) dilakukan.
Gambar 3.2 Hirarki Rekayasa Perangkat Lunak
Secara lebih resmi dapat dikatakan bahwa WV terdiri dari sejumlah domain (Di) ya
ng
masing-masing dapat berupa sebuah system atau system dari system yang lebih besa
r.
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}
29
B. REQUIREMENT ENGINEERING
Ketika otomasi bisnis diperkenalkan pertama kali pada awal tahun 1960-an, banyak
perusahaan yang kemudian mencari berbagai peluang dan mengotomasisasi fungsi-fun
gsi
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. Ba
nyak sistem
sulit dihubungkan satu dengan lainnya; data redundan ada di mana-mana; pengaruh
peubahan
terhadap aplikasi yang melayani satu daerah bisnis sulit diproyeksikan dan bahka
n lebih sulit
untuk diimplementasikan; dan program-program lama menjadi tidak dapat dipakai la
gi.tetapi
kurangnya sumber daya menyebabkan sistem digunakan dalam waktu yang sangat lama.
Tujuan global rekayasa informasi adalah untuk mengaplikasikanteknologi informasi
dengan cara tertentu yang melayani dengan paling baik kebutuhan bisnis secara ke
seluruhan.
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 masi
ngmasing area bisnis dan bisnis secara keseluruhan. Hanya setelah hal itu dilaku
kan, IE membuat
transisi ke dalam domain rekayasa perangkat lunak yang lebih teknis proses di ma
na sistem
informasi, aplikasi, dan program dianalisis, didesain, dan dibangun.
30
1. Requirement Elicitation
Semua proyek dapat dikerjakan dengan mudah dengan sumber daya dan waktu yang
tidak terbatas! Sayangnya, pengembangan sistem atau produk berbasis komputer leb
ih banyak
terganggu oleh kurangnya sumber daya dan tanggal penyampaian yang sulit (bila ti
dak benarbenar tidak realistis). Memang perlu dan bijaksana untuk melakukan eval
uasi 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 s
ebuah 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 dar
i
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 r
uang
angkasa). Pembenaran ekonomis menyangkut rentang yang luas dari pertimbangan yan
g
meliputi analisis biaya-keuntungan, stratgi pemasukan yang berhubungan dengan ho
kum dalam
jangka panjang, pengaruhnya pada pusat keuntungan atau produk yang lain, iaya su
mber daya
yang dibutuhkan untuk pengembangan, dan pertumbuhan pasar potensial.
Feasibilitas teknis sering menjadi area yang paling sulit untuk ditaksir pada ti
ngkat
proses rekayasa produk. Karena sasaran, fungsi, dan kinerja agak tidak penting b
ahwa proses
analisis dan definisi dilakukan secara paralel dengan sebuah penilaian feasibili
tas teknis.
Dengan cara inilah spesifikasi yang konkrit dapat diputuskan pada saat ditentuka
n.
31
4)
Komponen komunikasi
5)
Komponen koordinasi
6) Komponen iterface
32
5. Requirement Validation
Validasi perysaratan berkenaan dengan pengidentifikasian bahwa persyaratan benar
benar mendefinisikan sistem yang diinginkan pelanggan. Kegiatan ini memiliki ban
yak
kesamaan dengan analisis karena hubungan dengan penemuan masalah dengan persyara
tan.
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 se
telah
sistem dipakai. Biaya melakukan perubahan sistem yang merupakan akibat dari masa
lah
persyaratan lebih besar dari perbaikan desasin atau kesalahan pengkodean. Alasan
untuk hal ini
adalah karena perubahan persyaratan biasanya mengharuskan perubahan desain siste
m dan
implementasinya, beserta pengujian ulang sistem.
Pada saat proses validasi persyaratan tipe pemeriksaan yang berbeda harus ditera
pkan
pada persyaratan-persyaratan di dokumen persyaratan. Pemeriksaan ini meliputi:
1)
Pemeriksaan validitas.
Seorang user mungkin berpikir bahwa sistem diperlukan untuk melakukan fungsifung
si 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
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 masala
h. Karena
masalah tidak dapat didefinisikan sepenuhnya, persyaratan perangkat lunak cender
ung tidak
lengkap. Pada saat proses perangkat lunak, pemahaman pengembang akan masalah ber
ubahubah dan perubahan ini diumpan balikkan pada persyaratan.
Sistem besar biasanya memiliki komunitas user yang beragam. User yang berbedabed
a mempunyai persyaratan dan prioritas yang berbeda pula. Hal-hal ini bias menimb
ulkan
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 elisita
si
persyaratan awal dan manajemen persyaratan aktif harus dimulai segera setelah ve
rsi 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?
34
BAB 4
ANALISIS
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-proy
ek
perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah tahap rekaya
sa
sistem/informasi dan software project planning.
Analisis persyaratan adalah sebuah tugas rekayasa perangkat lunak yang menjembat
ani
jurang antara alokasi perangkat lunak tingkat sistem dan perancangan perangkat l
unak seperti
dilihat pada gambar 6.1.
36
Gambar 4.1 Analisis dan Kesenjangan antara rekayasa sistem dan desain perangkat
lunak
Analisis persyaratan memungkinkan perekayasa sistem menentukan fungsi dan kinerj
a
perangkat lunak, menunjukkan interface perangkat lunak dengan elemen-elemen sist
em.
Pendefinisian kebutuhan merupakan aktivitas yang sangat penting, karena sangat
mempengaruhi sukses atau gagalnya pelaksanaan pengembangan perangkat lunak. Menu
rut
hasil survey DeMarco, 56% kegagalan proyek pengembangan perangkat lunak dikarena
kan
ketidaklengkapan pendefinisian kebutuhan dari perangkat lunak tersebut. Perhatik
an gambar
dampak kesalahan kumulatif akibat kesalahan dalam pendefinisian kebutuhan pada G
ambar
4.2.
37
c. Pengujian kesesuaian perangkat lunak dengan kebutuhan yang dimaksud tidak aka
n
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 ana
lisis
dihubungkan oleh serangkaian prinsip operasional yang dapat dijabarkan sebagai b
erikut:
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.
39
c.
Data atau dokumen yang lengkap.
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.
40
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.
41
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 se
ring
disebut throwaway prototyping. Dengan menggunakan pendekatan tersebut prototype
merupakan sebuah demonstrasi kasar dari persyaratan. Kemudian prototype dikesamp
ingkan,
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.
42
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.
43
3. Object Oriented
C. ANALISIS TERSTRUKTUR
Analisis Terstruktur (Structured Analysis) merupakan salah satu teknik analisis
yang
mengunakan pendekatan berorientasi fungsi. Teknik ini mempunyai sekumpulan petun
juk dan
perangkat komunikasi grafis yang memungkinkan analis sistem mendefinisikan spesi
fikasi
fungsional perangkat lunak secara terstruktur. Pada metode ini, semua fungsi sis
tem
direpresentasikan sebagai sebuah proses transformasi informasi, dan disusun seca
ra hirarkis
sesuai tingkat abstraksinya (sistem maupun perangkat lunak) yang hasilnya dituju
kan untuk
entitas-entitas eksternal.
Analisis Terstruktur pertama kali diperkenalkan oleh Tom DeMarco sekitar tahun 1
978
[DEM79]. Prinsip dari teknik ini adalah dekomposisi fungsi dari sistem berdasark
an aliran data
dan proses-prosesnya untuk mendapatkan produk analisis yang dapat diubah dan dip
erbaiki
secara mudah (highly maintainable). Dalam bukunya itu, DeMarco mendefinisikan An
alisis
Terstruktur sebagai teknik untuk mendeskripsikan spesifikasi sistem baru melalui
Data Flow
Diagrams, Data Dictionary, Structured English, dan Data Structure Diagrams. Spes
ifikasi sistem
tersebut dinyatakan dalam suatu dokumen yang disebut Spesifikasi Terstuktur (Str
uctured
Specification).
Dalam
perkembangannya,
teknik
Analisis
Terstruktur
mengalami
perubahan,
penambahan, dan penyempurnaan, baik untuk perangkat pemodelannya maupun mekanism
e
atau cara pelaksanaannya. Salah satunya oleh Edward Yourdon [YOU89] yang memperk
enalkan
pendekatan baru dari Analisis Terstruktur, yaitu Analisis Terstruktur Modern (Mo
dern Structures
Analysis).
44
Nomor
: 3.0
Nama Proses
: Buat laporan penjualan
Jenis
: Pembuatan laporan
45
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 mendeskripsik
an 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 tertent
u
sebagai berikut:
= sama dengan atau terdiri dari atau terbentuk dari
+ dan
[] pilih salah satu
{} iterasi atau pengulangan
() pilihan (option)
* komentar
| pemisah
46
Saat ini ada banyak variasi penulisan kamus data, yang secara umum dibedakan
menjadi bentuk lengkap (long form) dan bentuk ringkas (short form). Sebagai cont
oh 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 at
au
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!
47
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 didef
inisikan
sebagai proses aplikasi berbagai teknik dan prinsip bagi tujuan pendefinisian su
atu perangkat
lunak, suatu proses atau sistem dalam detail yang memadai untuk memungkinkan rea
lisasi
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 pera
ngkat
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 p
erangkat
lunak. Objek dan hubungan data yang ditetapkan dalam diagram hubungan entitas (E
RD) dan
isi detail yang digambarkan di dalam kamus data, menjadi basis bagi aktifitas de
sain data.
Desain arsitektur menentukan hubungan diantara elemen-elemen struktural utama
dari program. Representasi desain tersebut berupa kerangka modular dari sebuah p
rogram
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 kontro
l.
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
48
perangkat lunak. Desain memberi kita representasi perangkat lunak yang kualitasn
ya dapat
dinilai. Desain adalah satu-satunya cara dimana kita dapat secara akurat menterj
emahkan
kebutuhan pelanggan ke dalam produk atau sistem perangkat lunak yang sudah seles
ai. 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. Persyarat
an
diterjemahkan ke dalam cetak biru (blueprint) untuk membangun perangkat lunak. C
etak biru
menggambarkan suatu pandangan menyeluruh rekayasa perangkat lunak. Sepanjang pro
ses
desain, kualitas yang melengkapi dinilai dengan serangkaian kajian teknis formal
. Terdapat 3
karakteristik yang berfungsi sebagai pedoman bagi evaluasi suatu desain yang bai
k:
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 mengeva
luasi
kualitas dari suatu desain kita harus membangun kriteria teknis untuk desain yan
g 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 logi
ka 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.
49
Keenam kriteria di atas tidak dapat dicapai secara kebetulan. Proses desain pera
ngkat
lunak memungkinkan adanya desain yang baik melalui aplikasi prinsip-prinsip desa
in
fundamental, metodologi sistematis, dan kajian yang mendalam.
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 masingmasing pen
dekatan 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.
50
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
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 car
a
dimana struktur memberikan integrasi konseptual bagi suatu sistem. Dalam bentukn
ya yang
paling sederhana, arsitektur merupakan struktur hirarki dari komponen program (m
odul), cara
bagaimana komponen tersebut berinteraksi, dan struktur yang digunakan oleh kompo
nen.
Secara lebih luas komponen dapat digeneralisir untuk mewakili elemen-elemen sist
em 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 p
erekayasa
perangkat lunak untuk menggunakan kembali konsep tingkat desain.
a. Control Hierarchy
Hirarki kontrol, disebut juga struktur program mewakili organisasi komponen (mod
ul)
serta mengimplementasikan suatu hirarki kontrol. Hirarki kontrol tidak mengimple
mentasikan
aspek procedural dari perangkat lunak, seperti urutan proses, urutan kejadian, k
eputusan atau
pengulangan.
Hirarki kontrol juga mewakili dua karateristik yang berbeda dari arsitektur pera
ngkat
lunak yaitu visibilitas dan konektivitas. Visibilitas menunjuk kepada serangkaia
n
komponen yang dapat diminta atau dipakai sebagai daa oleh komponen yang lain. Se
dangkan
konektivitas menandai serangkain komponen yang diminta secara tidak langsung ata
u
digunakan sebagai data oleh sebuah modul yang ditetapkan. Sebagai contoh sebuah
modul
yang secara langsung menyebabkan modul lain memulai eksekusi akan disambungkan d
engan
modul tersebut.
b. Structural Partitioning
Struktur program harus dipartisi baik secara horizontal maupun struktural/vertik
al.
Partisi arsitektural secara horizontal memberikan keuntungan nyata, yaitu:
a)
Menghasilkan perangkat lunak yang mudah diuji.
b)
Perangkat lunak mudah dipelihara.
53
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 b
ahwa
control/pembuat keputusan (decision making modules) dan kerja harus didistribusi
kan secara
top-down dalam arsitektur program. Modul tingkat puncak harus melakukan fungsi-f
ungsi
kontrol dan melakukan sedikit kerja pemrosesan aktual. Modul-modul yang dalam ar
sitektur
berada di bawah harus menjadi para pekerjanya yaiut melakukan tugas input, kompu
tasi 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 arsitektu
r, lebih kecil
kemungkinannya untuk menyebabkan penyebaran efek samping. Secara umum perubahan
program komputer berada di seputar perubahan input, komputasi dan transformasi s
erta
output.
Gambar 5.2 Partisi Vertikal/Struktural
54
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 represent
asi
arstitektur perangkat lunak. Struktur data menentukan organisasi, metode akses,
tingkat
hubungan dan alternatif pemrosesan untuk informasi. Ada sejumlah struktur data k
lasik yang
membentuk blok bangunan bagi struktur yang lebih canggih. Struktur data yang lai
n
digabungkan atau dikonstruksi dengan menggunakan struktur data fundamental seper
ti yang
telah dijelaskan.
Penting
untuk
dicatat
bahwa
struktur
data
seperti
struktur
program
dapat
direpresentasikan pada tingkat abstraksi yang berbeda. Contohnya stack adalah mo
del
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
masingmasing modul secara terpisah. Prosedur harus memberikan spesifikasi yang t
eliti 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 s
edang
digambarkan, yaitu representasi procedural dari perangkat lunak yang dilapiskan
seperti pada
gambar 5.3.
55
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 me
merlukan
sedikit interaksi dengan prosedur yang sedang dilakukan di bagian lain dari suat
u 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 pera
ngkaian
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-mas
ing tidak
berhubungan sehingga tidak terjadi perangkaian langsung. Modul c adalah sub ordi
nat dari
modul a dan diakses melalui sebuah daftar argument yang konvensional di mana dat
a
dilewatkan. Selama ada argument sederhana (yakni data sederhana yang dilewatkan;
hubungan satu-ke-satu dari item yang ada), perangkaian rendah. Variasi perangkai
an data
yang disebut perangkaian melekat (stamp coupling) ditemukan jika satu bagian dar
i suatu
struktur data (daripada sebuah argument sederhana) dilewatkan melalui sebuah int
erface
modul. Hal ini terjadi antara modul a dan b.
57
Relationship
1) Relationship adalah hubungan yang terjadi antara satu atau lebih entity.
2) Relationship set adalah kumpulan relationship yang sejenis.
ContohdarirelationshipdapatdilihatpadaGambar5.6.
Atribut
Gambar5.6Relationship
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 perh
atian (1)
desain interface antara modul-modul perangkat lunak; (2) desain interface antara
perangkat
lunak dan prosedur dan konsumen informasi bukan manusia lainnya (yakni entitas e
ksternal
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 re
solusi tinggi
dan interaksi dengan memakai mouse dan keyboard. Beberapa karakteristik yang men
dasar
dari tipe interface bersifat GUI adalah:
62
Karakteristik
Windows
Keterangan
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!
63
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 res
pon
komputer melewati batas waktu tersebut, maka terjadi degradasi performansi atau
kegagalan
sistem. Sebuah Real time system adalah sistem yang kebenarannya secara logis did
asarkan
pada kebenaran hasil-hasil keluaran sistem dan ketepatan waktu hasil-hasil terse
but
dikeluarkan. Aplikasi penggunaan sistem seperti ini adalah untuk memantau dan me
ngontrol
peralatan seperti motor, assembly line, teleskop, atau instrumen lainnya. Perala
tan
telekomunikasi dan jaringan komputer biasanya juga membutuhkan pengendalian seca
ra 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
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 jamina
n waktu
tertentu. Jika kebutuhan waktu tidak terpenuhi, maka aplikasi akan gagal. Dalam
definisi
lain disebutkan bahwa kontrol sistem hard real-time dapat mentoleransi keterlamb
atan
tidak lebih dari 100 mikro detik.Secara umum, sebuah proses di kirim dengan sebu
ah
pernyataan jumlah waktu dimana dibutuhkan untuk menyelesaikan atau menjalankan I
/O.
Kemudian penjadwal dapat menjamin proses untuk selesai atau menolak permintaan
64
karena tidak mungkin dilakukan. Mekanisme ini dikenal dengan resource reservatio
n. Oleh
karena itu setiap operasi harus dijamin dengan waktu maksimum. Pemberian jaminan
seperti ini tidak dapat dilakukan dalam sistem dengan secondary storage atau vir
tual
memory, karena sistem seperti ini tidak dapat meramalkan waktu yang dibutuhkan u
ntuk
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 beraki
bat 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 y
ang kritis
menerima prioritas lebih daripada yang lain. Walaupun menambah fungsi soft realtime ke
sistem time sharing mungkin akan mengakibatkan ketidakadilan pembagian sumber da
ya
dan mengakibatkan delay yang lebih lama, atau mungkin menyebabkan starvation,
hasilnya adalah tujuan secara umum sistem yang dapat mendukung multimedia, grafi
k
berkecepatan tinggi, dan variasi tugas yang tidak dapat diterima di lingkungan y
ang 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 mesi
n tersebut
dapat mengalami penurunan kualitas,misalnya waktu pelayanannya menjadi lebih lam
bat
dibandingkan ketika masih baru. Keterlambatan pada sistem ini tidak menyebabkan
kecelakaan
atau akibat fatal lainnya, melainkan hanya menyebabkan kerugian keuangan saja. J
ika
pelayanan mesin menjadi lambat, maka para pengguna dapat saja merasa tidak puas
dan
akhirnya dapat menurunkan pendapatan pemilik mesin. Setelah batas waktu yang dib
erikan
telah habis, pada sistem hard realtime,aplikasi yang dijalankan langsung dihenti
kan. Akan
tetapi, pada sistem softreal-time, aplikasi yang telah habis masa waktu pengerja
an
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 prior
itas
penjadualan, dan proses real-time harus memiliki prioritas tertinggi, tidak mela
mpaui waktu,
walaupun prioritas non real-time dapat terjadi.Kedua, dispatch latency harus leb
ih kecil.
Semakin kecil latency, semakin cepat real-time proses mengeksekusi. Untuk menjag
a dispatch
tetap rendah, kita butuh agar system call untuk preemptible. Ada beberapa cara u
ntuk
mencapai tujuan ini.
65
Pertama adalah dengan memasukkan preemption points di durasi system call yang la
ma, yang
memeriksa apakah prioritas utama butuh untuk dieksekusi. Jika sudah, maka contex
switch
mengambil alih, ketika high priority proses selesai, proses yang diinterupsi men
eruskan 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 y
ang
benar dapat dijamin, semua struktur data kernel harus diproteksi dengan mekanism
e
sinkronisasi. Dengan metode ini, kernel dapat selalu di preemptible, karena seti
ap data kernel
yang sedang di update diproteksi dengan pemberian prioritas yang tinggi. Jika ad
a proses
dengan prioritas tinggi ingin membaca atau memodifikasi data kernel yang sedang
dijalankan,
prioritas yang tinggi harus menunggu sampai proses dengan prioritas rendah terse
but selesai.
Situasi seperti ini dikenal dengan priority inversion. Kenyataanya, serangkaian
proses dapat saja
mengakses sumber daya yang sedang dibutuhkan oleh proses yang lebih tinggi prior
itasnya.
Masalah ini dapat diatasi dengan priority- inheritance protocol, yaitu semua pro
ses yang sedang
mengakses sumber daya mendapat prioritas tinggi sampai selesai menggunakan sumbe
r 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 dib
andingkan
dengan soft real-time ( SRTS ).
4.
Interaktif Deadline ( Waktu Deadlinenya Bisa Ditawar )
Pada interaktif real-time, maka waktu deadlinennya bisa ditawar, artinya tidak s
ecara
mutlak pada titik tertentu, tetapi tergantung dari kesepakatan yang ditentukan d
an fleksibel.
5.
Probabilistic / Statistik
Metode ini biasanya menggunakan teori probabilitas / teori kemungkinan dengan me
toda
statistik.
6.
Intelligence RTS
Tujuan :
Bertujuan untuk menyelesaikan masalah dengan waktu tertentu dan proses waktu
nyata dapat diselesaikan dalam waktu tertentu.
67
Diagram
m alir data mempunyai be
entuk standar, tetapi identtifikasi aliran data diganti
pij . mo
odel jaringan antrian yang
g ditarik dari D
DFD diperlihattkan pada gambar dibawah ini
2. Te
eknik Simula
asi dan Perm
modelan
Analisis matematis dari
d suatu sisttem real-time
e merepresen
ntasikan satu pendekatan
yang dapat digun
nakan untukk memaham
mi kinerja terproyeksi. Akan tetapi, sejumlah
pengem
mbang perangkat
real-tiime yang se
edang berkem
mbang mengg
gunakan pera
anti simulasi
dan pe
emodelan ya
ang tidak ha
anya mengan
nalisa kinerja
a sistem teta
api juga mem
mungkinkan
pereka
ayasa memba
angun protottipe, mengekksekusinya se
ehingga mem
mahami perila
aku sistem.
Keseluruhan hubungan rasional dibalik permo
odelan dan simulasi untukk sistem-siste
em real-time
ut i-Logix (pe
erusahaan yan
ng mengemba
angkan peran
nti untuk para
a perekayasa sistem)
menuru
a.
Atturan seri (kedatangan dila
ayani oleh sub
bsistem secarra seri)
b.
Atturan pararel (kedatangan dilayani oleh subsistem se
ecara pararel))
c.
Atturan looping
g (server den
ngan delay d
dan sebuah loop feedba
ack dengan probabilitas
loo
oping)
Pendek
katan i-Logix menggunaka
an notasi yang menggab
bungkan tiga pandangan
yang berbeda
b
dari suatu sistem : activity-cha
art, module-cchart, state-chart. Pendekkatan i-Logix
untuk simulasi
s
dan pemodelan sistem real-tim
me akan digam
mbarkan pada
a bagian berikkut ini :
a.
Pa
andangan Kon
nseptual
Masalah-masalah
fungsion
nal
diperlakkukan
denga
an
menggu
unakan
aktivvitas
yang
esan sistem.. Permintaan
n konfirmasi pelanggan
merepresentasikan kapabilitas pemrose
n contoh darii suatu aktiviitas, karena
didalam suatu sistem reserrvasi pesawat merupakan
edang mengu
update posissi pesawat didalam sua
atu sistem a
avionik. Aktivvitas dapat
se
dikumpulkan, yang
y
membe
entuk hirarki yang membangun suatu dekomposisi fungsional
ari sistem. Ittem informasii seperti jarakk ke suatu sa
asaran atau nama seorang pelanggan,
da
ak
kan secara khusus men
ngalir dianta
ara aktivitas dan juga dapat disim
mpan pada
nal dari suattu sistem ditangkap deng
pe
enyimpanan data.
d
Pandan
ngan fungsion
gan activitych
hart, yang mirrip dengan dia
agram aliran data konvenssional.
70
Masalah perila
aku dinamis yang biasan
nya menunjukk pada aspe
ek kontrol, diperlakukan
d
engan mengg
gunakan state
echart, suatu notasi yang dikembangka
an oleh Harel dan rekande
re
ekannya. Disini keadaan (atau
(
mode) dapat dikum
mpulkan dan di-link denga
an sejumlah
ca
ara untuk me
erepresentasikkan perilaku sekuensial attau konkuren. Komputer misi
m avionik,
misalnya dapatt menjadi sala
ah satu dari ketiga keadaa
an : udara ke
e udara, udarra ke tanah,
attau navigasi. Pada saat yang
y
sama, komputer ha
arus berada dalam keadaan kontrol
pe
enerbangan otomatis
o
atau
u manual. Trransisi diantara keadaan-kkeadaan terse
ebut secara
kh
husus dipicu oleh event-e
event yang d
dapat dikualiffikasikan menurut kondissi. Membalik
sa
aklar tertentu
u pada klep
p penutup, misalnya merupakan
m
su
uatu event yang akan
menyebabkan transisi dari keadaan uda
ara ke tanah
h, tetapi hanyya pada kon
ndisi dimana
pe
esawat berad
da pada keada
aan udara ke
e tanah maka amunisi dapa
at diperoleh.
Ja
adi, dua pand
dangan dari sistem itu diin
ntergrasikan dengan
d
activity
y-chart dan sstatechart terk
kait erat, wala
aupun bukan merupakan
re
epresentasi ya
ang berbeda dari suatu hal yang sama
a. Activity chart sendiri tid
dak lengkap
se
ebagai sebuah model siste
em, karena tidak
t
meneka
ankan perilakku. Statechartt juga tidak
71
lengkap karena tanpa aktivitas statechart tidak mempunyai apa-apa untuk dikontro
l.
Bersama-sama, activity chart detail dan statechart pengontrolannya memberikan mo
del
konseptual. Activity-chart merupakan tulang punggung dari model tersebut; dekomposisi
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 perspe
ktif fisik
dan alat untuk memastikan bahwa sistem diimplementasi dengan cara yang benar unt
uk
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 statech
art
controlling-nya, maka model tersebut dapat secara teliti dianalisis dan diuji. M
odel dapat
menggambarkan keseluruhan sistem, sampai ke tingkat detail yang paling rendah, a
tau
hanya berupa spesifikasi partial.
Kita harus memastikan bahwa sintaksis model tersebu benar. Oleh karena itu ada b
erbagai
pengujian langsung. Misalnya, bahwa berbagai bagan tidak lengkap secara menyolok
(seperti hilangnya label atau nama, anak panah yang berbayang-bayang), definisi
eleme nelemen nongrafis seperti event dan kondisi, hanya menggunakan operasi leg
al dan
sebagainya. Pengecekan sintaks juga melibatkan lebih banyak pengujian yang cerma
t,
seperti kebenaran input dan output. Contoh untuk hal tersebut adalah pengujian t
erhadap
elemene-elemen yang digunakan pada statechart. Tetapi tidak ada satu input pun y
ang
secara internal dipengaruhi seperti event power-on yang dimaksudkan untuk menyeb
abkan
transisi pada statechart tetapi pada activity-chart tidak ditetapkan sebagai inp
ut. Itu semua
biasanya dirujuk oleh pengujian konsistensi dan kelengkapan dan sebagian besar d
ari
mereka analog dengan pengecekan yang dilakukan oleh kompiler sebelum kompilasi a
ktual
dari suatu bahasa pemrograman.
72
d.
Skenario Running
Model yang secara sintaksis benar, secara akurat menggambarkan banyak sistem, te
tapi
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 apa
kah
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 baha
sa
permodelan yang lebih dari sekedar sintaks formal, dan mengharuskan sistem yang
dibuat
Bila model didasarkan pada suatu semantik formal, perekayasa sistem dapat mengek
sekusi
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 eventevent sep
erti 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 keada
an
dan aktivitas yang aktif) disoroti secara grafis dan eksekusi dinamis menghasilk
an
representasi model teranimasi. Eksekusi suatu skenario mensimulasi sistem yang b
erjalan
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 te
tapi,
saat ini ada lebih banyak simulasi ekstensif yang dapat diharapkan. Kinerja diba
wah
kondisi acak baik dalam situasi khusus maupun tidak khusus, mungkin perlu dinila
i. Untuk
situasi dimana simulasi ekstensif dari suatu model real time diinginkan, Simulat
ion Control
73
-chart
dan statechart controlling nya dapat diterjemahkan kedalam bahasa pemrograman ti
ngkat
tinggi, seperti Ada atau C. Saat ini kegunaaan utama dari kode yang dihasilkan a
dalah
untuk mengamati sistem yang bekerja dalam keadaan yang sedekat mungkin dengan
dunia nyata. Contohnya, kode prototype dapat dieksekusi dalam stimulator full-fl
edged dari
lingkungan target atau lingkungan akhir itu sendiri. Kode yang dihasilkan oleh p
eranti
CASE seperti itu harus dikategorikan menjadi protipikal. Model ini bukan merupakan
produksi atau kode akhir. Akibatnya model tidak dapat selalu merefleksikan kiner
ja real74
time yang akurat dari sistem yang dimaksudkan. Meskipun demikian, model sistem s
angat
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 l
unak realtime 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, perang
kat
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 desa
in
real-time. Aksi atau event atomik merupakan fungsi yang dibatasi dengan baik yan
g dapat
dieksekusi oleh suatu tugas tunggal atau dieksekusi secara konkuren oleh beberap
a 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 sehar
usnya
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 be
berapa aksi
dapat berlangsung didalam suatu keadaan yang diberikan, maka dapat ditimbulkan h
asil
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 maksu
dkan
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.
75
BAB 7
TEKNIK PENGUJIAN PERANGKAT
LUNAK
Pengujian perangkat lunak adalah elemen kritis dari jaminan kualitas perangkat l
unak 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 me
rupakan satu
langkah dalam proses rekayasa perangkat lunak yang dapat dianggap sebagai hal ya
ng
merusak daripada membangun.
Dalam melakukan uji coba ada 2 masalah penting yang akan dibahas, yaitu :
a.
Teknik Uji Coba Perangkat Lunak
Pada dasarnya, pengujian merupakan suatu proses rekayasa perangkat lunak yg dapa
t
dianggap
b.
(secara
psikologis)
sebagai
hal
yg
destruktif
daripada
konstruktif.
Sasaran Pengujian (Glen Myers) :
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) :
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.
77
d.
Pengujian harus mulai "dari yg kecil" dan berkembang ke pengujian "yang besar".
e.
ATRIBUT PENGUJIAN YG BAIK :
Tidak redundan.
Pengetahuan tentang cara kerja dari produk, test dapat dilakukan untuk memperlih
atkan
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 bat
as
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 fasilit
as 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 pat
h
(jalur logika) perangkat lunak akan ditest dengan menyediakan test case yang aka
n
mengerjakan kumpulan kondisi dan atau pengulangan secara spesifik. Secara sekila
s
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
79
White box testing dapat dilakukan dengan follow up performance line coverage, de
ngan
memberikan pihak tester list of line code yang belum dieksekusi.
80
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
81
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 sedikitny
a
satu rangkaianstatemenprosesbaruatausuatukondisibaru.
82
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
Tujuan pengujian kondisi adalah mendeteksi tidak hanya kesalahan di dalam kondis
i
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
Jika kondisi tidak benar, maka setidaknya satu komponen dari kondisi tidak
benar.
Untuk meng
ggunakan stra
ategi DU testi
ting dalam me
emilih jalur tes dari diagram
m control
flow, perlu mengetahui defnisi
d
dan pe
enggunaan da
ari variabel di tiap kondisi atau
a
blok
pada PDL.
Diasumsikan
n bahwa varia
abel X didefin
nisikan pada pernyataan
p
akkhir dari blok B1, B2, B3,
B4, dan B5 dan digunaka
an pada pernyyataan pertam
ma dari blok B2,
B B3, B4, B5, dan B6.
Jika menggunakan strate
egi branch tes
esting untuk memilih
m
jalur ttes dari PDL,
sebagaiman
na disebutkan
n di atas, tidakk dibutuhkan informasi tam
mbahan.
Untuk mem
milih jalur tes dari
d diagram untuk BRO te
esting, dibutuhkan pengetaahuan akan
struktur darri tiap kondisi atau blok. (S
Setelah pemiliihan jalur pro
ogram, perlu menentukan
m
apakah jalur fisibel untuk
k program; ya
aitu setidakny
ya satu masukkan ada yang
g melalui
jalur.)
ataan pada su
uatu program dihubungkan
n satu sama lain
Sejak pernyyataan-pernya
berdasarkan
n pada definissi dan penggu
unaan variabe
el, pendekata
an data flow testing
te
akan
efektif untuk mendeteksii error.
Bagaimanap
pun juga, masalah-masalah pengukuran
n cakupan tess dan pemilihan jalur tes
untuk data flow testing akan
a
lebih sullit daripada masalah
m
yang berkaitan den
ngan
testing kond
disi.
Adalah tidakk realistis unttuk mengasum
msikan bahwa
a data flow te
esting akan diigunakan
secara ekste
ensif bila melakukan tes su
uatu sistem yang
y
besar. Namun biasanyya akan
digunakan pada
p
daerah tertentu
t
yang
g ditargetkan sebagai penyyebab kesalah
han dari
software.
86
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.
87
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 merupa
kan
concatenated loops, dan nilai loop counter pada loop 1 digunakan sebagai nilai a
wal
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 di
disain
ulang.
BLACK-BOX TESTING
Black box testing, dilakukan tanpa pengetahuan detil struktur internal dari sist
em atau
komponen yang dites. juga disebut sebagai behavioral testing, specification-base
d testing,
input/output testing atau functional testing. Black box testing berfokus pada ke
butuhan
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 :
Metode ini tidak terfokus pada struktur kontrol seperti pengujian white-box teta
pi 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 hubu
ngan
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 menjelaska
n
beberapa karakteristik dari penghubung / link.
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 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 (mi
sal
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).
mempunyai loops (yaitu, jalur pada grafik yang terdiri dari satu atau lebih node
s, 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 diident
ifikasi,
hubungan dan bobot hubungan akan dapat ditetapkan. Hubungan harus diberi nama, w
alaupun
hubungan yang merepresentasikan alur kendali antar obyek program sebenarnya tida
k butuh
diberi nama. Pada banyak kasus, model grafik mungkin mempunyai loops (yaitu, jal
ur pada
90
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 meng
identifikasi
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 da
pat
diperoleh.
Perancangan test case equivalence partitioning berdasarkan evaluasi kelas
equivalence untuk kondisi input ygmenggambarkan kumpulan keadaan yg valid atau t
idak.
Kondisi input dapat berupa nilai numeric, range nilai,kumpulan nilai yg berhubun
gan 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 diteri
ma 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 dit
entukan
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 nila
i 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 n
ilai yg
91
telah ditentukan, dgn teknik perancangan test casemelengkapi test case equivalen
ce
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 di
rancang
dengan nilai a dan b.
2. Jika kondisi input ditentukan dgn sejumlah nilai, test case harus dikembangka
n dengan
mengerjakan sampaibatas maksimal nilai tsb.
3. Sesuai petunjuk 1 dan 2 untuk kondisi output dirancang test case sampai jumla
h
maksimal.
4. Untuk struktur data pada program harus dirancang sampai batas kemampuan.
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 dipangg
il
lagi ?
Apakah semua fungsi yang berhubungan dengan window dapat diperoleh bila diperluk
an
?
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 sesu
ai ?
Apakah pemilihan mouse bertingkat atau tidak benar di dalam window menyebabkan e
fek
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 (mis
al
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 ?
93
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 berub
ah
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 bekesesua
ian dengan
operasi GUI, maka pengujian harus didekati denga menggunakan peranti otomatis. S
udah
banyak peranti pengujian GUI yang muncul dipasaran selama beberapa tahun terakhi
r.
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, ma
salah kinerja
yang berhubungan dengan pemrosesan transaksi, kehadiran potensial dari sejumlah
platform
perangkat keras yang berbeda, kompleksitas komunikasi jaringan,kebutuahn aka lay
anan client
multipel dari suatu database terpusat dan persyaratan koordinasi yang dibebabkan
pada server,
semua secara bersama-sama membuat pengujian terhadap arsitektur C/S dan perangka
t lunak
yang ada didalamnya menjadi jauh lebih sulit daripada pengujian aplikasi yang be
rdiri sendiri.
Kenyataannya studi industri terakhir menunjukkan pertambahan berarti di dalam wa
ktu
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 dimani
pulasi
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.
94
Apakah terminologi, gambaran menu dan respon sistem konsisten dengan program akt
ual?
Apakah tabel dokumen dari isi dan indeks akurat dan lengkap ?
Apakah desain dokumen (layout, typeface, indetasi, grafik) kondusif untuk pemaha
man
dan asimilasi cepat terhadap informasi ?
Apakah semua pesan kesalahan ditampilkan bagi pemakai dan digambarkan secara leb
ih
tugas-tugas (proses) yang menangani data. Pada banyak situasi, data pengujian ya
ng diberikan
pada saat sebuah sistem real time ada dalam satu keadaan akan menghasilkan pemro
sesan
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 meny
ebabkan
pengaruh kegagalan perangkat keras pada pemrosesasn perangkat lunak. Kesalahan s
emacam
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 masingm
asing tugas secara independen, yaitu pengujian white box dan black box yang dide
sain
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.
96
telah diuji,maka event-event disajikan pada sistem dalam urutan acak dan dengan
frekuensi acak. Perilaku sistem diuji untuk mendeteksi kesalahan perilaku.
Pengujian sistem
Perangkat lunak dan perangkat keras diintegrasi dan suatu rentang penuh dari pen
gujian
sistem dilakukan di dalam usahan mengungkap keslahan pada interface perangkat
lunak/perangkat keras.
Sebagian besar sitem real time memproses interupsi, karena itu pengujian penanga
nan
terhadap kejadian-kejadian. Boolean merupakan hal yang penting. Dengan menggunak
an
diagram keadaan transisi dan spesifikasi kontrol, penguji mengembangkan daftar s
emua
interupsi yang mungkin dan pemroesan yang terjadi sebagai konsekuensi dari inter
upsi.
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 seb
agai bagian
dari pemrosesan interupsi yang harus diuji untuk menilai potensi munculnya efek
samping.
97
BAB 8
STRATEGI PENGUJIAN PERANGKAT
LUNAK
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 :
98
Unit testing-testing per unit yaitu mencoba alur yang spesifik pada struktur mod
ul
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 strate
gi
pengujian perangkat lunak yang sukses akan dipublikasikan.
1. Menetapkan seluruh kebutuhan produk software dalam perhitungan sebelum memula
i
testing
99
2. Status obyek testing harus jelas3. Memahami pengguna software dan mengembangk
an
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 t
es 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 d
ari desain
Perangkat Lunak, yakni modul. Ujicoba unit selalu berorientasi pada white box te
sting dan
dapat dikerjakan paralel ayau beruntun dengan modul lainnya. Pertimbangan Penguj
ian Unit
Interface modul diuji untuk memastikan bahwa informasi secara tepat mengalir mas
uk dan
keluar dari intiprogram yang diuji. Struktur data local diuji untuk memastikan b
ahwa data yang
tersimpan secara temporal dapattetap menjaga integritasnya selama semua langkah
langkah di
dalam suatu algoritma dieksekusi. Kondisi batasdiuji untuk memastikan bahwa modu
l
beroperasi dengan tepat pada batas yang ditentukan untuk membatasipemrosesan. Se
mua
jalur independen(jalur dasar) yang melalui struktur control dipakai sedikirnya s
atu 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?
100
Apakah atribut dari argumen yang ditransmisikan ke modul yang dipanggil sama den
gan
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 haru
s
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.
101
D. PENGUJIAN INTEGRASI
Pengujian terintegrasi adl teknik yg sistematis untuk penyusunan struktur progra
m, pada
saat bersamaandikerjakan uji coba untuk memeriksa kesalahan yg nantinya digabung
kan
dengan interface.
Metode pengujian integrasi :
- Top down integration
- Buttom up integration
Top Down Integration
Merupakan pendekatan inkrmental untuk penyusunan struktur program. Modul dipaduk
an
dgn bergerak ke bawahmelalui kontrol hirarki dimulai dari modul utama.Modul subo
rdinat
ke modul kontrol utama digabungkan ke dalam struktur baik menurut depth first at
au
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 sela
lu
diberikan harus ada dan diperlukan untuk stub yg akan dihilangkan.
102
Strategi pengujian :
Driver (program kontrol pengujian) ditulis untuk mengatur input test case dan
output
Cluster diuji
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
103
G. PENGUJIAN DEBUGGING
Debugging adalah sebuah metode yang dilakukan oleh para pemrogram dan
pengembang perangkat lunak untuk mencari dan mengurangi bug, atau kerusakan di d
alam
sebuah program komputer atau perangkat keras sehingga perangkat tersebut bekerja
sesuai
dengan harapan. Debugging cenderung lebih rumit ketika beberapa subsistem lainny
a 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. Bu
g
merupakan suatu kesalahan desain pada suatu perangkat keras komputer atau perang
kat lunak
komputer yang menyebabkan peralatan atau program itu tidak berfungsi semestinya.
Bug
umumnya lebih umum dalam dunia perangkat lunak dibandingkan dengan perangkat ker
as.
Debugging adalah proses menghilangkan bug dari suatu program. Pengujian perangka
t
lunak adalah proses yang dapat direncanakan dan ditentukan secara sistematis. De
sain test
case dapat dilakukan, strategi dapat ditentukan, dan hasil dapat dievaluasi berd
asarkan
harapan-harapan yang ditentukan sebelumnya. Debugging terjadi sebagai akibat dar
i pengujian
yang berhasil. Jika test case mengungkap kesalahan, maka debugging adalah proses
yang
104
Proses Debugging
Debugging bukan merupakan pengujian, tetapi selalu terjadi sebagai bagian akibat
dari
pengujian. Proses debungging dimulai dengan eksekusi terhadap suatu test case. H
asilnya
dinilai, dan ditemukan kurangnya hubungan antara harapan dan yang sesungguhnya.
Dalam
banyak kasus, data yang tidak berkaitan merupakan gejala dari suatu penyebab pok
ok 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 sua
tu
penyebab, mendesainsuatu test case untuk membantu kecurigaannya, dan bekerja unt
uk
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 aplika
si 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
.
105
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 mening
katkan
kesulitan tugas. Meskipun mungkin sulit untuk mempelajari debugging, sejumlah pe
ndekatan
terhadap masalah tersebut dapat diusulkan. Kita akan melihat dalam sub bab selan
jutnya.
Pendekatan-pendekatan Debugging
Tanpa memperhatikan pendekatan yang diambil, debugging memiliki satu sasaran yan
g
diabaikan, untuk menemukan dan mengkoreksi penyebab kesalahan perangkat lunak. S
asaran
tersebut
direalisasi
dengan
suatu
kombinasi
evaluasi
yang
sistematis,
intuisi,
dan
keberuntungan.
107
Van Vleck (FAN89) mengusulkan tiga pertanyaan sederhana yang harus diajukan kepa
da
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 y
ang
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 un
tuk
memperkirakan pemasangan logika dan struktur data. Bila koreksi akan dilakukan p
ada bagian
program yang akan dirangkai, maka harus ada perhatian khusus bila banyak perubah
an
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 selan
jutnya.
108
BAB 9
OBJECT ORIENTED SOFTWARE
ENGINEERING
Dapat membagi aplikasi ke dalam potongan kecil yang banyak, independen satu sama
lain, potongan-potongan kecil tersebut disebut obyek.
State
Behaviour
Identity
Identitas adalah properti objek yang membedakan dirinya dari semua objek
yang lain.
111
Behaviour
agaimana objjek bereaksi dab bereaksi terhadap ob
bjek lain, dan bagaimana
yaitu ba
mengirimka
an ke objek la
ain. Pada prog
gramming di implementasiikan dengan method dan
member fun
nction
Object Beh
haviour
112
Identity
Properti darri objek yg membedakan dari
d objek lain
n. Menunjuk ssuatu referen
nce ke objek
lain, jika objjek dibuat ma
aka identiti akkan muncul.
Hubungan
n antar objek
ek
Berelassi antara
Acto
or = sebuah objek dapat m
mengakses su
uatu objek te
etapi objek tersebut tidak
dap
pat di akses,
Servver = sebuah
h objek yg han
nya dpt diakses objek lain
Age
ent = dapat akses dan diakkses
Ex : me
esin mobil yg terdiri dari b
banyak elemen
n piston, plug
g, carburator, dll
Relationship
ps Objects
2.
Ke
elas
113
Class me
erupakan blo
ok pembangunan terpentin
ng pd OO. Class
C
adalah
tip
pe data abstrrak yg dilengkapi sarana untuk
u
dapat melakukan im
mplementasi
se
ecara parsial dan total. Deskripsi
D
dari kelompok ob
bjek dengan properti yg
sa
ama (atribut),, kelakukan yyg sama (operasi) dan re
elationship / simantik yg
sa
ama.
Class adalah sebuah hasil abstraksi dari sesuatu dgn mengelompokkan
ka
arakteristik yg
g sejenis dgn mengabaikan
n karakteristikk lainnya.
Ex
x : kelas kursu
us
Prropertinya / atributnya : lokasi, hari, waktu, tutorr, dan kelaku
uan operasi
se
eperti kelakua
an (operasi) se
eperti add sisswa, kurang siswa,
s
jadwal kursus, dll
Hirarki Kelas
114
Class menciptakan perbedaan visvibility ;
If punya benda burung elang, ikan hiu, gadjah, telpon, tv, kamera
Jadi Objek = 6
115
K dpt mene
Kita
entukan classs dari ojek terrsebut berdassarkan sifat yg
g terdiri dari
2 kelas ;
Benda mati
m dan benda hidup
J
Jika
operasi dan
d atribut diperinci, akan diperoleh leb
bih banyak je
enis kelas yg
m
memiliki
batasan lebih jela
as, ex;
Kelas ma
amalia, burun
ng, audio, visu
ual dan audio visual
Inh
heritance
Ada
alah Hubunga
an antara class dan saling
g relasionhip, menshare mengunakan
m
beh
havior bersam
ma. Single inheritance = mempunyai
m
ha
anya 1 class dan
d multiple
inhe
eritance. Inh
heritace berg
guna untuk mengorganisa
m
asikan know
wledge pada
sebuah domain masalah.
m
3.
Attribut
Nama-na
ama properti dari sebuah kelas
k
yg menjjelaskan bata
asan nilainya
dari properti
p
yg dimiliki oleh
h sebuah kelas
k
terseb
but. Atribut dari kelas
memprresentasikan properti2 yg
g dimiliki kelas tsb. Kea
adaan (state)) dari objel
dijelaskkan dengan nilai dari atrribut yg dimilikinya. Dala
am sebuah kelas
k
atribut
hanya dinyatakan keberadaan dan batasan nilainya saja. Dalam se
ebuah objek
atributn
nya sudah din
nyatakan nila
ai dan menjela
askan kedudu
ukan/ keadaan dari objek
tersebu
ut.
4.
Op
perasi
116
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.
118
Objek diberi garis bawah (kata benda, atau anak kalimat yang bersifat sebagai ka
ta
benda) dan kemudian dimasukkan ke dalam tabel. Sinonim dicatat. Jika objek
diperlukan untuk mengimplementasikan status solusi, maka object tersebut merupak
an
119
bagian dari solution space. Jika objek hanya diperlukan untuk mendeskripsikan stat
us
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 ke
rja
dan predikat, serta menghubungkan setiap operasi dengan objek yang sesuai.
b. Pengertian OOA
Pada dasarnya kebanyakan metode analisis system memisahkan antara data dan
proses. Walaupun SA dan IE telah melakukan usaha untuk menyelaraskan keduanya, n
amun
usaha tersebut belum sepenuhnya berhasil. Analisis berbasis objek kemudian muncu
l dan
digunakan untuk mengurangi batas pemisah abtara data dan proses. Seluruh data sp
esifik dan
proses yang membuat, membaca, meng- update atau menghapus data-data tersebut
diintegrasikan dan disebut dengan objek. Beberapa bahasa pemrograman yang berbas
is 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 O
OA 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 i
nformasi
atau representasi entitas di dunia nyata. Seperti contohnya dalam system reserva
si
penerbangan hal-hal yang bisa disebut sebagai object seperti pesawat, jalur pene
rbangan 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 dib
awah
ini:
1. Maintainability , yaitu tingkat kemudahan dalam mengakomodasi perubahan- peru
bahan.
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. Jad
i 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.
121
Pada obyek mobil, walaupun minibus dan truk merupakan jenis obyek mobil yang sam
a, 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 ad
alah 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 ya
ng
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 i
nformasi) atau
model
yang
tertarik
secara
eksklusif
dari
struktur
infromasi
hiraskis.
OOA
memperkenalkansejumlah konsep baru menurut Coad dan Yourdon yang menyinggung mas
alah
ini dengan mengatakan: OOA didasarkan pada konsep yang pertama kali kita pelajar
i 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 t
erlalu sibuk
mengikuti aliran selama masa emas analisis terstruktur untuk mempertimbangkan alte
rnatif
alternatif tersebut.
4. Sasaran OOA
Sasaran OOA adalah mengembangkan sederetan model yang menggambarkan perangkat lu
nak
komputer pada saat komputer itu bekerja unutk memenuhi serangkaian persyaratan y
ang
ditentukan oleh pelanggan. OOA membangun metode multibagian untuk memenuhi sasar
an
tersebut.
123
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.
125
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 sam
a
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.
126
organisasi ini salah satunya bertugas membuat spesifikasi manajemen objek untuk
menetapkan kerangka bersama dalam rekayasa software.
Sasaran
technology
dan
OMG
adalah
mengarahkannya
membantu
dengan
perkembangan
mendirikan
object-oriented
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 la
gi
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
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.
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 terpenu
hi.
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.
131
Notasi class berbentuk persegi panjang berisi 3 bagian: persegi panjang paling a
tas
untuk nama class, persegi panjang paling bawah untuk operasi, dan persegi panjan
g
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
132
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 apak
ah
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 navigatio
n
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
133
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
Representasi keadaan
9
Keadaan dari masing-masing objek ketika sistem melakukan fungsinya
9
Keadaan sistem pada saat diselidiki dari luar ketika sistem melakukan
fungsinya
BAB 10
CLIENT SERVER SOFTWARE
ENGINEERING
User
User disini adalah end user yang mengakses client untuk mendapatkan sebuah layan
an. End
user bisa saja seorang manager perusahaan, professional, karyawan di sebuah peru
sahaan,
atau pelanggan. Ada timbul sedikit kerancuan. Pelanggan dalam sebuah bisnis atau
perdagangan disebut dengan client, tapi client ini adalah manusia, jangan dibing
ungkan 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 termin
al tua
dengan kemampuan proses yang terbatas. Secara mendasar client adalah sebuah PC d
engan
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 tradisiona
l. 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 y
ang ada. Untuk
139
memfasilitasi query pemprosesan dari client, sebagian besar sistem client server
menggunkaan
Structured Query Language (SQL) yang merupakan struktur bahasa tingkat tinggi. S
QL dengan
database relationalnya adalah standar de facto untuk hampir sebagian besar siste
m client
server. Salah satu komponen terpenting sistem client server adalah User Interfac
e (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 us
er friendly.
Dibutuhkan Graphical User Interface (GUI) untuk end user karena GUI menampilkan
grafis
untuk melakukan akses dengan icon-icon tanpa perlu memasukan perintah pemrograma
n.
Kedepannya GUI tidak hanya digunakan untuk menggantikan akses perintah pemprogra
man
tapi juga digunakan untuk grafik, voice, video, animasi, untuk selanjutnya menja
di sebuah
teminal multimedia.
Network dan Transmisi
Server dan client dapat terkoneksi dengan sebuah media transmisi. Media transmis
i ini dapat
berupa kabel, wireless, atau fiber. Dengan media ini memungkinkan sebuah perusah
aan 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 be
rbedabeda. Dengan interoperability baik vendor dan customer akan mendapatkan keu
ntungan.
Interoperability memberikan dampak pada arsitektur jaringan. Awal sebuah arsitek
tur jaringan
adalah SNA namun arsitektur ini bersifar proprietary dan tidak terbuka dengan ve
ndor lainnya.
Kemudian sebagian besar orang beralih ke OSI yang di standarkan oleh ISO (Intern
ational
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 U
nix User
Group.
Servers
Konektivitas adalah hal yang terpenting namun bukan satu-satunya faktor untuk me
ndapatkan
efisiensi dan efektivitas sharing resource yang dimiliki. Dibutuhkan sebuah pera
ngkat yang
memiliki kemampuan mengontrol software, menjalankan program applikasi, dan menga
kses
database dengan mudah dan cepat. Untuk itulah diperlukan sebuah Server. Sebuah S
erver
harus mendukung spesifikasi yang mendukung resource sharing seperti Network Serv
er
Operating System, Multiple User Interface, GUI (Graphic User Interface), dialog
oriented cleint
server languange seperti SQL dan database arsitektur. Saat ini resuorce bisa ter
sebar secara
140
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 ters
ebut bisa
bersifat mainframe centric (sentral) atau PC server centric. Namun selain semua
hal yang
tersedia pada paket software tersebut tetap dibutuhkan in house sofware developm
ent. Juga
perlu untuk mengintegrasikan sistem client server dengan sistem informasi yang t
elah ada dan
menggunakan sistem tersebut tidak hanya sebagai end user tapi juga bekerja diant
ara group
end user.
Server melakukan pemprosesan mirip dengan pemrosesan yang ada disisi client. Nam
un 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 y
ang
dilakukan. Sebagai contoh sebuah server dapat bertindak sebagai repository dan p
enyimpanan
informasi dalam kasus pada file server. Tipe dari Server tergantung pada kebutuh
an 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 mela
kukan
teleprosesing. Dengan kapabilitas seperti itu menjadikan server memiliki harga y
ang 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 integrit
as, sekuriti,
dan recovery data. Enterprise data yang dibutuhkan oleh sebuah perusahaan membut
uhkan
sebuah integrasi, pengaksesan data yang di kendalikan dan kelola dengan securiti
yang baik,
dan recovery data dapat dilakukan jika terjadi kegagalan sistem.
141
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 serv
er. Ada
beberapa applikasi client server yang disediakan oleh vendor. Tools applikasi in
i menjadikan
pengembangan sistem client-server menjadi lebih kompetitif. Pengembangan applika
si clientserver dapat dilakukan dengan beberapa cara yakni :
1. Fungsi pemprosesan didistribusikan diantara client dan server. Porsi dari cli
ent
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 opera
si.
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 tingk
at
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 perub
ahan bentuk
untuk mendapatkan tampilan yang lebih baik. Semuanya ini dilakukan di sisi clien
t oleh end
user melalui UI (User Interface). Diagram skematik pendekatan client server ditu
njukan pada
gambar dibawah ini.
142
Fat Server biasanya ditemukan pada desain sebuah sistem transaksi dan groupware
.
Server menyediakan dukungan aplikasi yang diperlukan untuk melakukan transaksi d
an
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 s
erver,
biasanya sebuah mainframe. Server juga berisi aplikasi untuk menyiapkan tampilan
informasi.
Contohnya adalah Virtual Class, Semua aplikasi baik database, tampilan ataupun l
ogika aplikasi
terletak di server, client hanya membutuhkan sebuah browser untuk menampilkan GU
I yang
disediakan oleh server.
Remote Presentation
Adalah sebuah extensi dari pendekatan distributed presentation , primary databas
e dan logika
aplikasi terletak di server , dan data akan dikirimkan ke client untuk ditampilk
an 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 up
date 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 sourc
edengan
format data yang telah di extrak dari tempat lain (contohnya dari corporate leve
l source).
Aplikasi di alokasikan di client digunakan untuk mengevaluasi data yang telah di
format oleh
server.
Decission
Pedoman
untuk
support
system
termasuk
Mendistribusikan
ke
Subsistem
dalam
kategori
dari
ini.
Aplikasi
Presentation / Interaction subsitem terletak di client. Ketersediaan PC, lingkun
gan 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 databa
se ditaruh
di server . DBMS dan kemampuan akses database juga ditaruh di server bersamaan d
engan
fisik database
Data statis yang digunakan sebagai referensi terletak di client. Peletakan data
dekat dengan
user meminimalisir trafik jaringan yang tidak perlu.
147
Analisis Pemodelan
Kebutuhan aktifitas pemodelan untuk sistem c/s sedikit berbeda dari metode pemod
elan yang
diaplikasikan ke arsitektur komputer konvensional .Oleh karena itu prinsip dasar
analaisis dan
metodologi pemodelan dapat diterapkan di software c/s. Dengan catatan , bahwa ke
banyakan
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 mel
ayani satu
atau lebih client untuk kebutuhan penyediaan data. Yang mana terletak di jaringa
n. Client
mengorganisasi panggilan ke server , yang bekerja secara asynchronous ataupun sy
nchronous.
Jika server bekerja secara synchronous , maka akan ia akan mengembalikan control
ke client
bersamaan dengan dengan pengembailan data. Jika server bekerja secara asynchrono
usly,
maka
hanya
Pendekatan
akan
Desain
mengembalikan
data
Konvensional
(Tanpa
untuk
kontrol)
software
ke
Client.
Aplikasi
Di sistem c/s, DFD dapat digunakan untuk membangun system scope, mengidentifikas
i fungsi
high-level , menentukan area data , membolehkan dekomposisi dari high-level func
tion. 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, didef
inisikan
sebagai satu set tugas yang di lakukan tanpa henti oleh satu user pada client. T
ugas tersebut
dilakukan sekaligus atau tidak sama sekali.
ERD juga bias digunakan untuk memperluas role. ERD dapat digunakan untuk mendoko
mpisi
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 menggu
nakan
SQL , tanpa menggunakan informasi navigational. implikasi dari hal ini adalah RD
MBS harus
handal dalam memilihara lokasi dari data dan kapabel dalam mendefinisikan jalur
terbaik untuk
148
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, anta
ra 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.
Business
Rule
mengidentifikasikan
komponen
yang
siginfikan
terhadap
menentukan objek bisnis high-level. Struktur chart itu tidak dipakai sebagai ala
t
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 da
n
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 digabungka
n
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 virtua
l,
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 :
151
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 diha
pus
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 untu
k
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.
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
153
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
154
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.
155
BAB 11
WEB ENGINEERING
Web Enginerring (Rekayasa web) adalah proses yang diunakan untuk menciptakan
aplikasi web yang berkualitas tinggi. Rekayasa web mengadaptasi rekayasa perangk
at lunak
dalam hal konsep dasar yang menekankan pada aktifitas teknis dan manajemen. Namu
n
demikian adaptasi tidak secara utuh, tapi dengan perubahan dan penyesuaian. Reka
yasa web
gabungan antara web publishing (suatu konsep yang berasal dari printed publishin
g) dan
aktifitas rekayasa perangkat lunak. Dikatakan demikian karena desain sebuah apli
kasi web
menekankan pada desain grafis, desain informasi, teori hypertext, desain sistem
dan
pemrograman.
156
Faktor-faktor yang menentukan kualitas suatu web digambarkan pada gambar dibawah
.
Faktor-faktor kualitas pada gambar 1 adalah faktor-faktor yang membantu web deve
loper
dalam merancang dan membangun webapp yang dapat diterima dan memenuhi kebutuhan
end
user yang begitu beragam. Untuk memenuhi faktor-faktor kualitas tersebut, peranc
angan dan
implementasi webapp terkait dengan 3 teknologi yang sangat penting yaitu: compon
entbased development, security dan standart Internet. Seorang web developer haru
s mengenal 3
teknologi ini untuk membangun webapp yang berkualitas:
Component-based
merupakan standar
development
yang
:
CORBA,DCOM/COM
memungkinkan
web
dan
developer
JavaBeans
menggunakan
komponenkomponen yang sudah ada untuk berkomunikasi dengan sistem pada level
lain.
Modified waterfall
Tahapan dalam modified waterfall adalah :
1.
Problem definition dan concept exploration.
2.
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 tid
ak
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.
Beberapa contoh aplikasi berbasis web yang paling banyak digunakan sekarang adal
ah 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, diantarany
a
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 it
u 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 si
apa
saja tanpa harus membayar royalti. Juga banyak contoh aplikasi berbasis web yang
159
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. Pengun
jung
atau pengguna perangkat lunak ini sangat bervariasi baik dari segi perangkat ker
as
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
pengembangan perangkatlunak berbasis web :
yang
perlu
dipertimbangan
pada
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 at
au
sisi klien secara tepat sehingga dapat mengoptimalkan performa aplikasi tersebut
.
e. Kemanan. Ini merupakan hal yang sangat diperhatikan untuk aplikasi berbasiswe
b
melalui internet, karena begitu suatu web dihosting di internet, maka semua oran
g
(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
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.
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
featurehp,sedangvertikaladalahmerekHP
162
Menentukan cara yang tepat: pilihannya adalah text-based links, icons, buttons a
nd
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 interfacen
ya buruk
maka hal lain tidak berguna, karena akan membuat user berpindah ke web lain.
Membaca di layar monitor lebih lambat 25% dari pada di kertas, karena itu teks j
angan
terlalu banyak.
User tidak suka scroll. Pastikan informasi cukup dalam satu layar.
Opsi navigasi harus jelas sehingga tahu bagaimana berpindah atau mencari hal lai
n
pada halaman aktif.
164
165