Modul-Rpl Free

Rekayasa Perangkat Lunak
1

BAB I
PENGENALAN REKAYASA PERANGKAT LUNAK

1. Perangkat Lunak
1. Pengertian Perangkat Lunak
Gambaran perangkat lunak pada sebuah buku teks mungkin mengambil bentuk
berikut : (1) perintah (program komputer) yang bila dieksekusi memberikan fungsi dan
unjuk kerja seperti yang diinginkan. (2) Struktur data yang memungkinkan program
memanipulasi informasi secara proporsional, dan (3) dokumen yang menggambarkan
operasi kegunaan program.
2. Karakteristik Perangkat Lunak
Perangkat lunak lebih merupakan elemen logika dan bukan merupakan elemen
fisik. Dengan demikian, perangkat lunak memiliki ciri yang berbeda dari perangkat
keras. Ciri-ciri yang membedakan tersebut antara lain :
1. Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuk yang
klasik.
Meskipun terdapat kesamaan antara pembuatan perangkat keras dan pengembangan
perangkat lunak, yaitu kualitas yang tinggi bisa dicapai melalui perancangan yang
baik, tetapi di dalam fase pembuatan perangkat keras selalu saja ditemukan masalah
kualitas yang tidak mudah disesuaikan dengan perangkat lunak.
2. Perangkat lunak tidak pernah usang

Gambar 1.1. Kurva Kegagalan Perangkat Keras
Gambar 1.1 menggambarkan laju kegagalan sebagai fungsi waktu untuk
perangkat keras, disebut kurva bathtub, menunjukkan bahwa perangkat keras
mengalami laju kegagalan yang sangat tinggi pada awal hidupnya, yang disebabkan
kematian
segera usang
Waktu
Tingkat
Kegagalan

2

oleh perancangan atau cacat pembuatannya. Setelah diperbaiki maka laju kegagalan
menurun, kemudian naik lagi pada saat komponen perangkat keras terkena
penumpukkan debu, getaran, suhu tinggi, serta pengaruh lingkungan yang lain.
Secara singkat dapat dikatakan bahwa perangkat keras sudah mulai usang.
Sedangkan perangkat lunak tidak rentan terhadap pengaruh lingkungan yang
merusak dan menyebakan perangkat keras menjadi usang.
Gambar 1.2 secara teoritis menggambarkan tingkat kegagalan perangkat lunak.
Kesalahan-kesalahan yang tidak ditemukan akan menyebabkan tingkat kegagalan
tinggi pada awal hidup program, tetapi itu dapat diperbaiki sehingga kurvanya
menjadi datar. Secara singkat perangkat lunak tidak usang, meskipun pada
kenyataannya semakin lama makin memburuk.

Gambar 1.2. Kurva Kegagalan Perangkat Lunak

Selama masa hidupnya, perangkat lunak mengalami perubahan (pemeliharaan).
Sewaktu perubahan dibuat, kesalahan lain akan muncul yang menyebabkan kurva
kegagalan naik secara cepat. Lihat Gamabr 1.3. Setelah semua kesalahan diperbaiki
maka kurva akan menjadi normal kembali. Kemudian secara perlahan tingkat laju
kesalahan minimum mulai naik perangkat lunak mulai memburuk sehubungan
perubahan yang dilakukan.

Pada tingkat yang sama
sampai usang
Waktu
Tingkat
Kegagalan

3

Gambar 1.3. Kurva Kegagalan Aktual Perangkat Lunak
Aspek lain dari keusangan yang membedakan antara perangkat keras dan lunak
adalah bila perangkat keras telah usang maka bisa diganti dengan suku cadangnya,
tetapi tidak demikian dengan perangkat lunak.
3. Sebagian besar perangkat lunak dibuat secara custom-built, serta tidak dapat dirakit
dari komponen yang sudah ada.
Perhatikan bagaimana perangkat keras komputer dirancang dan dibuat. Pengembang
desain menggambar skema sederhana dari rangkaina digital, melakukan serangkaian
analisis dasar untuk memastikan bahwa fungsi yang tepat dapat dicapai serta
kemudian menyesuaikan ke katalog komponen digital. Setiap IC (chip) mempunyai
nomor tersendiri, sebuah fungsi yang telah tervalidasi, interface yang didefinisikan
dengan baik, serta rangkaian standar tuntunan integrasi. Setelah masing-masing
komponen diseleksi, perangkat keras bisa dipesan secara terpisah. Tidak demikian
dengan pengembangan perangkat lunak, katalog komponen perangkat lunak tidak
ada. Memang memungkinkan memesan perangkat lunak secara terpisah, tetapi tetap
merupakan satu kesatuan yang lengkap, bukan sebagai komponen yang dapat
dipasang ke dalam program-program yang baru.

4

3. Evolusi Perangkat Lunak.
Pada awal tahun 1990-an Toffler menggambarkan adanya pergeseran kekuatan
dimana struktur kekuatan lama (pemerintah, pendidikan, industri, dan militer)
mengalami disintegrasi ketika komputer membawa ke arah demikratisasi pengetahuan.
Sedangkan pada tahun 1992 Yourdon mengkawatirkan perusahaan-perusahaan Amerika
akan kehilangan sisi kompetitif mereka di dalam bisnis yang berhubungan dengan
perangkat lunak dan meramalkan penurunan serta jatuhnya para pemrogram Amerika.
Tahun 1993 Hammer dan Champy berpendapat bahwa teknologi informasi akan
memainkan peranan sentral dalam pengembangan kerjasama. Pada pertengahan tahun
1990 daya tembus komputer dan perangkat lunak menimbulkan banyak pendapat bahwa
komputer menekankan sisi legitimasi tetapi mengabaikan keuntungan besar yang
diperoleh.
Perkembangan perangkat lunak bisa digambarkan pada Gambar 1.4. Pada masa
awal era komputer, perangkat lunak dilihat hanya sebagai suatu permenungan.
Pemrogram komputer menjadi sebuah seni seat-of-pants dimana di situ terdapat
beberapa metode yang sistematis. Perkembangan perangkat lunak sebenarnya tidak bisa
diatur sampai terjadi jadwal yang bergeser, atau biaya yang mulai melonjak. Para
pemrogram kemudian berusaha untuk membuat semuanya benar kembali, dan dengan
cara yang heroik akhirnya mereka berhasil. Pada masa itu perangkat lunak dirancang
secara khusus untuk aplikasi tertentu saja dan hanya memiliki areal distribusi yang
terbatas. Produk perangkat lunak yang dijual kepada pelangan atau masyarakat masih
langka. Kebanyak dikembangkan dan digunakan oleh orang atau organisasi yang sama,
dibuat untuk dipakai sendiri.
Era kedua evolusi sistem komputer antar pertengahan tahun 1960 dan 1970-an.
Sistem multiprogram dan multiuser memperkenalkan konsep baru interaksi manusia dan
mesin. Teknik interaktif membuka sebuah dunia aplikasi yang baru serta tingkat
kecanggihan perangkat lunak dan perangkat keras yang baru pula. Sistem real-time
mampu melakukan pengontrolan dalam menghasilkan output tidak lagi dalam skala
menit, melainkan detik. Kemajuan dalam penyimpanan on-line membawa ke generasi
pertama sistem mamajemen database. Pada era kedua ini juga ditandai dengan
kehadiran software-house. Produk perangkat lunak didistribusikan ke pasar yang lebih
luas dan multidisiplin. Program mainframe dan minikomputer didistribusikan kepada

5

masyarakat luas. Pengusaha, pemerintah, industri, serta akademisi masing-masing
mengembang-kan paket perangkat lunak paling mewah dengan mengeruk banyak uang.

Tahun-tahun
awal
Era kedua Era Ketiga Era keempat
- Orientasi batch - Multi user - Sistem terdistribusi
- Sistem desk-top
bertenaga kuat
- Distribusi
terbatas
- Realtime
- embedded
intelegence
- Teknologi berorientasi
objek
- Perangkat
lunak
kustomasi
- Database
- Perangkat keras
biaya rendah
- Sistem pakar

- Perangkat
lunak produk
- Jaringan saraf tiruan
- Komputasi paralel
- Komputer jaringan

Gambar 1.4. Evolusi Perangkat Lunak

Era ketiga evolusi sistem komputer dimulai pertengahan tahun 1970-an dan berlangsung
lebih dari satu dekade penuh. Sistem terdistribusi dan multikomputer menambah
kompleksitas sistem berbasis komputer. Jaringan area global dan lokal, jaringan
komunikasi digital dengan bandwidh yang tinggi serta pertambahan permintaan untuk
akses sesaat sangat mendongkrak perkembangan perangkat lunak. Era ketiga ini juga
ditandai dengan kehadiran dan penyebaran pemakaian mikroprosesor, sehingga produk-
produk pintar, seperti automobil, microwave, robot sampai peralatan kedokteran bisa
dihasilkan. Yang paling penting pada era ini adalah munculnya komputer personal (PC
= Personal Computer).
1950 1960 1970 1980 1990 2000

6

Evolusi sistem komputer era keempat menjauhkan kita dari komputer individual
dan program komputer untuk menuju pengaruh kolektif dari komputer dan perangkat
lunak. Mesin desktop yang kuat yang dikontrol oleh sistem operasi yang canggih,
jaringan lokal dan global, serta didukung dengan aplikasi perangkat lunak yang maju,
menjadi sebuah aturan. Arsitektur penghitungan berubah dari lingkungan mainframe
yang terpusat ke lingkungan klien/server yang terdesentralisasi. Dan yang paling
penting pada era ini adalah internet sudah dapat dilihat sebagai perangkat lunak yang
dapat diakses oleh para pemakai individual.
Tetapi selama era evolusi sistem berbasis komputer, serangkaian masalah yang
berhubungan ddengan perangkat lunak masih muncul dengan intensitas yang terus
bertambah, misalnya :
1. Kemajuan perangkat keras terus berlajut, melampaui perkembangan perangkat
lunak yang sesuai dengan perangkat keras yang ada.
2. Kemampuan pengembangan perangakt lunak tidak cukup sepat untuk memenuhi
kebutuhan bisnis dan pasar.
3. Pemakaian komputer yang semakin luas membuat masyarakat semakin
tergantung pada perangkat lunak yang reliabel.
4. Sistem desain dan sumberdaya untuk mengembangkan perangkat lunak kurang
memadai, sehingga masih sulit untuk dibagun perangkat lunak dengan
reliabilitas dan kualitas yang tinggi.

4. Aplikasi Perangkat Lunak
Perangkat lunak dapat diaplikasikan ke berbagai situasi dimana serangakaian
langkah prosedural (seperti algoritma) telah didefinisikan. Kandungan (content) dan
determinasi informasi merupakan faktor penting dalam menentukan sifat aplikasi
perangkat lunak. Content mengarah pada arti dan bentuk informasi yang masuk dan
keluar. Misalnya, banyak aplikasi bisnis memakai data input dengan struktur data lebih
tinggi (misal database) dan mengahasilkan laporan yang sudah terformat. Perangkat
lunak yang mengontrol mesin otomatis menerima bentuk data diskrit dengan struktur
yang terbatas dan menghasulkan perintah mesin individual dalam ekskusi yang cepat.
Sedangkan determinasi informasi merujuk pada predikbilitas urutan dan timing
informasi.

7

Berikut beberapa jenis aplikasi perangkat lunak :
a. Perangkat lunak sistem. Sekumpulan program untuk melayani programprogram
lain, misalnya sistem operasi, kompiler, editor, utilitas pengatur file, driver, prosesor
telekomunikasi.
b. Perangkat lunak real-time. Program-program untuk mengontrol/menganalisis/
memonitor kejadian dunia nyata pada saat terjadinya. Misalnya program untuk
mengontrol mesin industri.
c. Perangkat lunak bisnis. Program untuk pemrosesan informasi di dunia bisnis, mulai
dari payroll, account payable, inventory, post system, sampai perangkat lunak
sistem informasi manajemen yang bisa mengakses satu atau lebih database.
d. Perangkat lunak teknik dan ilmu pengetahuan. Jangkauan aplikasinya meliputi,
asmronomi, vulkanologi, kedokteran, analisis otomotif, biologi, mesin-mesin pabrik,
sampai pada perangkat bantu dalam perancangan (computer aided design) untuk
konstuksi bangunan, komponen elektronik, rancangan mesin, simulasi sitem, dan
lain-lain.
e. Embeded Software. Program yang disertakan dalam suatu perangkat dan berfungsi
untuk mengontrol hasil serta sistem perangkat tersebut. Contoh : key pad control
untuk microwave, fungsi digital pada automobil (pengontrol bahan bakar,
penampilan dash board, sistem rem, dll).
f. Perangkat lunak komputer personal. Programprogram yang bisa dijalankan pada
komputer personal. Contoh : pengolah kata, multimedia, hiburan, manajemen
database, aplikasi keuangan bisnis, dll.
g. Perangkat lunak kecerdasan buatan dan jaringan syaraf tiruan. Sistem pakar atau
disebut juga sistem berbasis pengetahuan. Program yang digunakan untuk
menggerakkan/mengontrol robot, permainan game, pengolah gambar dan pola
(image dan voice).

8

2. Rekayasa Perangkat Lunak
1. Pengertian Rekayasa Perangkat Lunak
Pada tahun 1969 Fritz Bauer memberikan definisi rekayasa perangkat lunak
adalah sebagai berikut :
The establishment and use of sound engineering principles in order to
obtain economically software that is reliable and work efficiently on
real machines.
Hampir setiap pembaca tergoda untuk menambah sendiri definisi tersebut,
karena definisi tersebut hanya menyinggung sedikit saja tentang aspek teknis dan
kualitas perangkat lunak, dan tidak secara langsung menyinggung kebutuhan dan
kepuasan pelanggan, pengabaikan pencamtuman pentingnya pengukuran dan matriks,
tidak menyinggung pentingnya sebuah proses. Apakah sound enginnering aplication
yang dapat diaplikasikan kepada pengembangan komputer? Bagaimana kita secara
ekonomis membangun perangkat lunak sehingga menjadi dapat diandalkan dan
reliable? Apakah yang dibutuhkan untuk menciptakan program komputer yang bekerja
secara efisien pada lebih dari satu mesin riril yang berbeda? Pertanyaan-pertanyaan ini
masih terus menjadi tantangan bagi pengembangan perangkat lunak.
Pada tahun 1985 Richard Fairly mendefinisikan rekayasa perangkat lunak
sebagai berikut :
The technological and managerial dicipline concernment with
systematic production and maintenance of software products that are
developed and modified on time and within cost estimates.
Definisi ini sudah menyinggung aspek teknis pengembangan perangkat lunak,
pengelolaan tim yang terlibat dalam pengembangan tersebut, pemeliharaan perangkat
lunak yang telah dikembangkan, serta waktu serta biaya pengem-bangan.
Kemudian pada tahun 1993, IEEE mengembangkan definisi yang lebih
komprehensif yaitu sebagai berikut :
Rekayasa perangkat lunak adalah : (1) Aplikasi dari sebuah pendekatan
kuantifiabel, disiplin, dan sistematis terhadap pengembangan, operasi,
dan pemeliharaan perangkat lunak; yaitu aplikasi dan rekayasa
perangkat lunak; (2) Studi tentang pendekatan-pendekatan tentang (1).

9

2. Lingkup Rekayasa Perangkat Lunak
Lingkup rekayasa perangkat lunak bisa digambarkan seperti Gambar 1.5.
Rekayasa perangkat lunak merupakan suatu kegiatan untuk menghasilkan suatu produk,
sehingga harus berada pada satu komitmen dasar menuju kualitas. Untuk itu fokus
kualitas menjadi batu landasanya. Lingkup kedua adalah proses. Proses-proses rekayasa
perangkat lunak adalah perekat yang menjaga bentangan teknologi secara bersama-sama
dan memungkinkan perkembangan perangkat lunak yang tepat waktu dan rasional.
Proses-proses tersebut membatasi kerangka kerja untuk serangkaian area proses kunci
yang harus dibangun demi keefektifan penyampaian teknologi pengembangan perangkat
lunak. Area proses kunci ini membentuk dasar bagi kontrol manajemen proyek
pengembangan perangkat lunak serta membangun kontek dimana metode teknis
diaplikasikan sehingga sebuah produk yang berkualitas bisa dihasilkan.

Gambar 1.5. Lingkup Rekayasa Perangkat Lunak.
Lingkup berikutnya adalah metodologi, yaitu sekumpulan metode untuk
melaksanakan setiap tahap pengembangan perangkat lunak, yang meliputi : perencanaan
dan estimasi proyek, analisa kebutuhan, prosedur algoritma dan arsitektur program,
menulis program (coding), pengujian (testing), dan pemeli-haraan (maintenance).
Terakhir adalah perangkat bantu (tools). Perangkat bantu yang dimaksus adalah suatu
perangkat, baik lunak atau keras, otomatis maupun semi-otomatis yang bisa digunakan
untuk proses pengembangan perangkat lunak. Tools untuk rekayasa perangkat lunak
disebut computer-aided sofware engineering (CASE). CASE ini terus dikembangkan
untuk menciptakan lingkungan rekayasa perangkat lunak sehingga analog dengan
CAD/CAE (computer-aided design/engineering) pada pengembangan perangkat keras.

Fokus kualitas
proses
metodologi
perangkat bantu

10

3. Paradigma Rekayasa Perangkat Lunak
Untuk menyelesaikan masalah aktual didalam sebuah seting industri, rekayasa
perangkat lunak atau tim perekaysa harus menggabungkan strategi pengembangan yang
mencakup semua lingkup rekayasa perangkat lunak seperti yang digambarkan pada
Gambar 1.5 tersebut . Strategi ini sering disebut paradigma atau model proses rekayasa
perangkat lunak.
Perkembangan perangkat lunak bisa dianggap sebagai lingkaran pemecahan
masalah dimana terdapat empat keadaan berbeda, yaitu status quo, definisi masalah,
perkembangan teknis pemecahan masalah, dan integrasi pemecahan menyampaikan
hasil (dokumen, program, data, fungsi bisnis baru, produk baru) kepada yang
membutuhkan hasil/produk tersebut. Lihat Gambar 1.6.
Lingkaran pemecahan masalah tersebut digunakan pada tingkat makro ketika
bagian dalam aplikasi dipakai; pada tingkat tengah ketika komponen program
direkayasa; dan pada tingkat mikro ketika baris-baris kode ditulis. Masing-masing
keadaan di dalam pemecahan masalah tersebut berisi lingkaran yang identik. Lihat
Gambar 1.7. Tanpa memperdulikan model proses yang dipilih untuk suatu proyek
rekayasa perangkat lunak, semua keadaan tersebut -- status quo, definisi masalah,
perkembangan teknis pemecahan masalah, dan integrasi pemecahan secara simultan
hidup berdampingan pada beberapa tingkatan / tahapan detail.
Dalam subbab ini akan dibahas beberapa model proses yang berbeda pada
rekaya perangkat lunak.

Gambar 1.6. Fase lingkaran pemecahan masalah
Definisi
masalah
Penyatuan
Solusi
Pengembangan
Teknis
Status
Quo

11

Gambar 1.7. Fase-fase di dalam lingkaran pemecahan masalah

a. Siklus Hidup Klasik
Paradigma siklus hidup klasik untuk rekayasa perangkat lunak diilustrasikan
seperti pada Gambar 1.8. Disebut juga sebagai model air terjun.
Beberapa kelebihan model ini adalah :
1) Titik awal dan titik akhir yang eksplisit
2) Setiap tahapan didefinisikan dengan jelas
3) Setiap akhir suatu tahap, disesuikan kembali dengan tahap sebelumnya, sehingga
kesalahan yang mungkin terjadi bisa ditemukan dan diselesaikan lebih dini.
Definisi
masalah
Penyatuan
Solusi
Pengembangan
Teknis
Status
Quo
Definisi
masalah
Penyatuan
Solusi
Pengembangan
Teknis
Status
Quo
Definisi
masalah
Penyatuan
Solusi
Pengembangan
Teknis
Status
Quo Status
Quo

12

4) Incremental release, lingkup kerja untuk tahapan-tahapan berikutnya menjadi lebih
kecil, dan tugas yang lebih mudah. Jika tahap awal dilakukan dengan benar maka
akan mempermudah tahap berikutnya.

Gambar 1.8. Paradigma Siklus Hidup Klasik : Model Air Terjun
Aktivitas setiap tahapannya adalah :
1) System Engineering : Pengumpulan kebutuhan seluruh elemen sistem
2) Sofware Requirements Analysis : Pengumpulan kebutuhan dengan berfokus pada
perangkat lunak, meliputi : domain informasi, fungsi, unjuk kerja, antar muka
3) Design, meliputi : Perancang struktur data, arsitektur perangkat lunak, rincian
prosedural, karakteristik antar muka
4) Coding : penerjemah perancang ke bentuk yang dapat dimengerti oleh mesin
5) Testing, mencakup kegiatan : penguji lojikal, penguji fungsional, menemukan
kesalahan dan memastikan suatu masukan diproses menjadi keluaran yang sesuai
dengan yang diinginkan
6) Maintenance, bagian terujung dari siklus pengembangan dan dilakukan setelah
perangkat lunak dipergunakan. Kegiatan adalah corrective maintenance, yaitu
mengkoreksi kesalahan pada perangkat lunak, yang baru terdeteksi pada saat
perangkat lunak dipergunakan

Software
Enginering
Analysis
Design
Coding
Testing
Maintenance

13

Model air terjun adalah paradigma rekayasa perangkat lunak yang paling luas
dipakai dan paling tua. Tetapi kritik terhadap paradigma tersebut menyebabkan banyak
pihak yang mempertanyakan kehandalannya. Masalah-masalah yang timbul ketika
model tersebut diterapkan adalah :
1. Meskipun dalam prosesnya model ini bisa mengakomodasi iterasi, tetapi tidak
dilakukan secara langsung, akibatnya perubahan-perubahan dapat menyebabkan
keraguan pada saat tim proyek berjalan.
2. Kadang-kadang pelanggan sulit untuk menyatakan semua kebutuhannya secara
eksplisit, sehingga sulit untuk mengakomodasi ketidakpastian tersebut.
3. Pelanggan harus bersikap sabar, karena masa pakai dari program tidak akan
diperoleh sampai akhir waktu proyek berakhir. Akibatnya bisa saja terdapat
kesalahan yang tidak tedeteksi sampai program tersebut tiba masanya untuk dikaji
ulang.
4. Pengembang sering melakukan penundaan yang tidak perlu, karena seringnya
beberapa anggota tim proyek harus menunggu anggota lain untuk melengkapi tugas
yang saling ketergantungan.

b. Model Prototype
Sering kali seorang pelanggan mendefinisikan serangkaian umum bagi
perangkat lunak yang dibutuhkan, tetapi tidak mengidentifikasi kebutuhan output,
pemrosesan, maupun input secara detail. Pada kasus lain, pengembang tidak memiliki
kepastian terhadap efisiensi algoritma, kemampuan penyesuaian dari sebuah sistem
operasi, atau bentuk-bentuk yang harus dilakukan oleh interaksi manusia dan mesin.
Dalam hal ini, paradigma prototipe menawarkan pendekatan yang terbak.
Paradigma ini dimulai dengan mengumpulkan kebutuhan. Pengembang dan
pelanggan bertemu untuk mendefinisikan obyektif keseluruhan dari perangkat lunak.
Kemudian dilakukan perancangan kilat yang berfokus pada penyajian dari aspek-aspek
perangakt lunak yang akan nampak oleh pelanggan/pemakai (misal format input dan
outputnya). Perancangan kilat tersebut membawa kepada konstruksi prototipe. Prototipe
ini dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaring kebutuhan
pengembangan perangkat lunak yang dibutuhkan. Iterasi terjadi pada saat prototipe

14

disetel untuk memenuhi kebutuhan pelanggan, dan pada saat yang sama memungkinkan
pengembang untuk secara lebih baik memahami apa yang harus dilakukan.
Prototipe bisa berfungsi sebagai sistem awal. Tetapi pada beberapa proyek
yang dibangun dengan prototipe, saat penggunaan pertama sistem awal yang baru
dibangun tersebut, mungkin akan terasa terlalu pelan, terlalu besar, janggal dalam
pemakaian, atau bahkan tiga hal tersebut semua terjadi. Jika terjadi demikian maka tidak
ada pilihan lain kecuali memulai lagi untuk membangun versi yang baru dimana
masalah yang muncul bisa diselesaikan.

c. Model RAD (Rapid Aplication Development).
RAD adalah merupakan model proses pengembangan perangkat lunak adaptasi
kecepatan tinggi dari model sekuensial linier yang menekankan siklus perkembangan
yang sangat pendek. Perjalanan pengembangannya sangat cepat dengan menggunakan
pendekatan konstruksi berbasis komponen, yang memungkinkan tim pengembang bisa
menciptakan sistem fungsional secara utuh dalam waktu 60 s.d. 90 hari. Pada umumnya
digunakan pada aplikasi sistem konstruksi.
Pendekatan RAD melingkupi fase-fase sebagai berikut :
1) Businnes modelling. Pemodelan dari aliran informasi diantara fungsi-fungsi bisnis.
2) Data modelling. Mengidentifikasi serangkaian objek data yang dibutuhkan dan
karakteristik masing-masing objek tersebut, serta mendefinisikan hubungan antara
objek-objek tersebut.
3) Proses modelling. Mentransformasikan hasil data modelling untuk mencapai aliran
informasi yang perlu bagi implementasi fungsi-fungsi prosesnya. Gambaran proses
dibuat untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali
sebuah objek data.
4) Aplication generation. RAD mengasumsikan pemakaian teknik generasi keempat
(4GL), lebih banyak memakai komponen program yang sudah ada, juga
menciptakan komponen yang bisa dipakai lagi.
5) Testing and turnover. Karena proses RAD menekankan pada pemakaian kembali,
maka setiap komponen baru harus diuji untuk mengurangi keseluruhan waktu
pengujian

15

Kelemahan model RAD :
1) Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusi
yang memadai untuk menciptakan jumlah tim RAD yang baik.
2) RAD menuntut pengembang dan pelanggan memiliki komitmen tinggi di dalam
aktivitas pengembangan.

Gambar 1.9. Model RAD

Disamping tiga model di atas, masih banyak lagi model proses rekayasa
perangkat lunak yang lain, yaitu :
1) Model Proses Rekayasa Perangkat Lunak Evolusioner, antara lain :
a) Model Pertambahan
b) Model Spiral
c) Model Rakitan Komponen
d) Model Perkembangan Konkuren

Pemodelan
bisnis
Pemodelan
data
Pemodelan
Proses
Pembentukan
aplikasi
Pengujian
& turnover
Pemodelan
bisnis
Pemodelan
data
Pemodelan
Proses
Pembentukan
aplikasi
Pengujian
&
turnover
Pemodelan
bisnis
Pemodelan
data
Pemodelan
Proses
Pembentukan
aplikasi
Pengujian
&
turnover
Tim #1
Tim #2
Tim #3

16

2) Model Formal
3) Teknik Generasi Keempat (4GL)
Model-model itu bisa anda baca di buku Software Engineering yang ditulis oleh
Rogers. Pressman, PhD.

3. Rekayasa Sistem Komputer
Dengan melihat definisi dari Websters, kita mendefinisikan sistem berbasis
komputer sebagai:
serangkaian atau tatanan elemen-elemen yang diatur untuk mencapai tujuan yang
ditentukan sebelumnya melalui pemrosesan informasi
Tujuannya adalah untuk mendukung berbagai fungsi bisnis atau untuk mengembangkan
suatu produk yang dapat dijual untuk menghasilkan keuntungan bisnis. Untuk mencapai
tujuan tersebut, sistem berbasis komputer menggunakan berbagai elemen sistem:
a) Perangkat lunak, program komputer, struktur data, dan dokumen yang
berhubungan yang berfungsi untuk mempengaruhi metode logis, prosedur, dan
kontrolyang dibutuhkan.
b) Perangkat keras, perangkat elektronik yang memberikan kemampuan
penghitungan, dan perangkat elektromekanik (misalnya: sensor, rotor,
pompa)yang memberikan fungsi dunia eksternal.
c) Manusia, pemakai dan operator perangkat lunak dan perangkat keras.
d) Database, kumpulan informasi yang besar dan terorganisasi yang diakses
melalui perangkat lunak.
e) Dokumentasi, manual, formulir, dan informasi deskriptif lainnya yang
menggambarkan penggunaan dan pengoprasian sistem.
f) Prosedur, langkah-langkah yang menentukan penggunaan khusus dari masing
elemen sistem atau konteks prosedural dimana sistem berada.
Satu karakteristik sistem berbasis komputer yang rumit adalah bahwa elemen yang
berisi satu sistem juga dapat mewakili satu elemen makro dari suatu sistem yang
sangat besar. Elemen makro adalah suatu sistem berbasis komputer yang merupakan
bagian dari sistem berbasis komputer yang lebih besar lagi. Peran rekayasa sistem
adalah membatasi elemen-elemenuntuk sistem berbasis komputer tertentu dalam
konteks keseluruhan hirarki sistem (elemen makro). Berikut adalah tugas-tugas yang
merupakan rekayasa sistem komputer:

17

Sistem Otomasi Pabrik
Sistem Pemanufakturan Sistem Inventori Sistem Informasi
Sistem Aliran Material Sel pemenufakturan
Robot Mesin NC Perangkat Entry Data
Gambar 1.10. Sistem dari banyak sistem

18

BAB II
DASAR ANALISIS KEBUTUHAN

2.1. Lingkup Analisis
a) Pengenalan Permasalahan
b) Evalusi dan Sintesis
c) Pemodelan
d) Spesifikasi
e) Peninjauan Ulang

Gambar 2.1 Hubungan Antara Analisis dan Perancangan
Dalam menemukan area permasalahan, perlu adanya komunikasi yang intensif
dengan user. Hal yang perlu diperhatikan dalam berkomunikasi adalah menghindari
salah interpretasi.
Pertanyaan pertama memfokuskan pada pengertian dasar permasalahan :
1. Menemukan yang membutuhkan software tersebut :
a. Siapa yang membutuhkan sistem (serta personal di belakangnya?)
b. Siapa yang akan menggunakan solusi
c. Apa yang akan menjadi keuntungan ekonomis dari solusi yang baik
d. Adakah sumber lain dari solusi yang dibutuhkan
2. Bentuk solusi yang diinginkan
a. Bagaimana user mengkarakteristikkan suatu output sistem yang baik yang akan
dihasilkan oleh solusi yang benar
b. Masalah-masalah apa yang akan dicarikan solusinya?
c. Lingkungan solusi yang akan digunakan
d. Adakah isukah isu atau kendala khusus yang berdampak kepada solusi
3. Efektifitas
a. Mendapatkan person yang benar/berhak atas jawaban pertanyaan,
b. Apakah pertanyaan yang diajukan relevan dengan permasalahan
c. Adakah personal lain yang dapat menambah informasi

Analisis
Peran-
cangan
Apa ? Bagaimana ?

19

d. Adakah hal lain yang perlu ditambahkan?

Jenis Kebutuhan:
1) Kebutuhan Fungsional
Pendefinisian layanan yang harus disediakan, bagaimana reaksi sistem terhadap
input dan apa yang harus dilakukan sistem pada situasi khusus (Kebutuhan sistem
dilihat dari kacamata pengguna)
2) Kebutuhan Non-Fungsional
Kendala pada pelayanan atau fungsi sistem seperti kendala waktu, kendala proses
pengembangan, standard, dll. Contoh: kehandalan, waktu respon dan kebutuhan
storage. Contoh kendala seperti: Keterbatasan kemampuan peralatan I/O,
representasi sistem dll.

2.2. Sistem Analis
a) Dituntut untuk dapat memiliki Kemampuan :
a. Pemimpin Proyek
b. Mediator
c. Inovator
d. Arkeolog
b) Nama Lain : System Engineer, Chief System Designer, Programmer/Analyst
dsb

Gambar 2.2 Cara Kerja Sistem Analis

c) Prinsip-Prinsip Analisis :
a. Domain Informasi dari masalah harus dapat direpresentasikan dan
mudah dimengerti
b. Harus ada model yg dpt mengambarkan fungsi dan perilaku sistem
c. Model dan masalah harus dapat dibuat bertingkat (dipartisi) perinciannya
Clien
t
Pengem
bang
Konsultan/Specifi
er
(Perancang
Senior)

20

d. Proses Analisis harus berpindah dari informasi dasar ke perincian
implementasi

2.3. Domain Information
Tirdiri dari 3 pandangan : Information Flow, Information Content, dan Information
Sructure
a) I nformation Flow mempresentasikan bagaimana data dan kontrol berubah
dalam perjalananannya melalui sistem
b) I nformation Content merepresentasikan item-item individual dari data dan
kontrol yang lebih besar
c) I nformation Structure merepresentasikan organisasi internal dari item-item data
kontrol

Gambar 2.3 Struktur Informasi

2.4. Pemodelan
Harus dapat memodelkan informasi yang diolah oleh perangkat lunak, fungsi dan
sub fungsi yang memungkinkan pengolahan dan perilaku sistem ketika pengolahan
dilakukan. Dapat berupa notasi grafis atau tekstual.
1. Peranan Model :
a) Membantu analisis dalam pemahaman informasi fungsi dan dan prilaku sistem
sehingga aktivtas analisis kebutuhan menjadi lebih mudah dan lebih sistematis
Transform 1
Transfrom 2
Input
information
Output
information
Intermediate
information
Data Store

21

b) Merupakan poin kritis untuk peninjauan ulang yang penting untuk kelengkapan,
konsistensi dan ketetapan dari spesifikasi
c) Merupakan dasar untuk tahap perancangan dengan menyediakan kepada
perancang representasi dasar perangkat yang dapat dipetakan ke dalam konteks
implementasi.
2. Pembagian
a) Berguna untuk penyederhanan
b) Proses pembagian
a. pembagian vertikal untuk memperinci fungsi
b. pembagian horisontal untuk dekomposisi fungsi

2.5. Informasi Dasar dan Implementasi
Informasi Dasar merepresentasikan fungsi yang ingin dicapai dan informasi yang
akan diproses dengan mengabaikan perincian implementasi. Perincian implementasi
merepresentasikan manifestasi dunia nyata dari fungsi pemrosesan dan struktur
informasi
1. Kebutuhan Perangkat Lunak
Dapat dinyatakan dalam berbagai bentuk :
a) Gambar di atas kertas
b) Gambar di komputer ( dengan CASE Tool)
c) Prototype
d) Bahasa spesifikasi formal

2. Spesifikasi
a) Merupakan proses representasi dari kebutuhan sistem untuk suksesnya
implementasi perangkat lunak
b) Balzer dan Goldman memberikan 8 prinsip spesifikasi yang bagus, yaitu :
a. pisahkan fungsionalitas dari implementasi. Pusatkan pada apa bukan
bagaimana
b. dibutuhkan bhs spesifikasi sistem yang berorientasi pada proses
c. spesifikasi harus mencakup sistem dimana perangkat lunak adalah salah satu
komponen

22

d. spesifikasi harus meliputi lingkungan dimana sistem beroperasi
e. spesifikasi sistem merupakan model kognitif
f. spesifikasi harus dapat dioperasionalkan
g. spesifikasi sistem harus toleran terhadap ketidaklengkapan dan penambahan
h. spesifikasi harus terlokalisasi dan loosely coupled.

23

BAB III
ANALISA TERSTRUKTUR

3.1. Sejarah Analisa Terstruktur
1 Dipopularkan oleh DeMarco (1979)
2 Dikembangkan lebih lanjut oleh Page-Jones (1980), Gane dan Sarson (1982)
3 Dikembangkan untuk sistem waktu nyata (Real Time) oleh Ward dan Mellor
(1985) kemudian Hatley dan Pirbhai (1987)
4 Merupakan teknik pemodelan information flow dan information content

3.2. Data Flow Diagram (DFD)
DFD atau yang sering disebut juga Bubble Chart, Bubble Diagram, model proses,
diagram alur kerja, atau model fungsi, merupakan suatu diagram yang menggambarkan
aliran data dalam sebuah sistem.
Komponen DFD terbagi menjadi 4:
1) Terminator atau External Entity
External Entity adalah lingkungan luar dari sistem tetapi dia memiliki
pengaruh terhadap sistem. External Entity bisa digambarkan sebagai individu,
kelompok, atau sistem lain (bukan orang).
Notasi :
2) Proses
Proses berfungsi untuk mentransformasikan data secara umum. Karena proses
melakukan pekerjaan, maka dalam menamai sebuah proses dimulai dengan
kata kerja dan diikuti objek.
Suatu proses harus memiliki input dan output. Suatu proses juga dapat
dihubungkan dengan komponen External Entity, Data Store, atau Proses lain
melalui Aliran Data.

Konsumen

24

Notasi :

Model DeMarco/Yourdon Model Gane & Sarson

3) Data Store
Data Store berfungsi menyimpan data/ file. Data store biasanya berkaitan
dengan penyimpanan-penyimpanan secara komputasi, contoh: harddisk,
disket, dvd disc, namun bisa juga berupa seperti buku, alamat, agenda.
Data Store hanya dapat dihubungkan dengan komponen Proses melalui Alur
Data, tidak dengan komponen DFD lain.
Notasi :

Model DeMarco/Yourdon Model Gane & Sarson

4) Alur Data
Alur Data menggambarkan aliran data dari suatu proses ke proses lainnya.
Alur Data dapat merepresentasikan data/informasi yang berkaitan dengan
komputer seperti bit, bilangan real, karakter, maupun yang tidak seperti nama,
nim, alamat.
Notasi :

Diagram aliran data (DFD) memungkinkan perekayasa perangkat lunak untuk
mengembangkan model domain informasi dan domain fungsional pada saat yang sama.
Pada saat DFD disaring kedalam tingkah detail yang lebih tinggi, analis melakukan
suatu dekomposisi fungsional implisit dari sistem, sehingga memenuhi prinsip analisis
1
Periksa
Pesanan
1

Periksa
Pesanan
Pesanan Pesanan
Pesanan_barang

25

operasional keempat. Pada saat yang sama, penyaringan DFD menghasilkan suatu
penyaringan yang sesuai dari data pada saat dia bergerak melalui proses yang
membentuk aplikasi. Beberapa tuntunan sederhana dengan tak terukur dapat membantu
selama derivasi sebuah diagram alir data:
1) Diagram aliran data tingkat 0 (Nol) harus menggambarkan perangkat
lunak/sistem sebagai gelembung tunggal.
2) Input dan output utama harus dicatat secara hati-hati.
3) Penyaringan harus dimulai dengan mengisolasi proses calon, objek data, dan
penyimpanan yang akan direpresentasikan pada tingkat selanjutnya.
4) Semua anak panah dan gelembung harus diberi label dengan nama yang berarti.
5) Satu gelembung pada suatu saat harus disaring.

Diagram Aliran Data Bertingkat
1. Dasar Pemikiran
a) ROSS
Pikiran manusia dapat menerima segala bentuk kerumitan, asalkan disajikan
dalam susunan yang terdiri bagian-bagian kecil yang mudah dimengerti
b) GEORGE MILLER
Pikiran manusia paling banyak dapat mengerti sesuatu yang terbagi menjadi 7 +
2 bagian dan tetap masih dapat mengerti konsep dari sesuatu tadi secara
keseluruhan .

2. Jenis DAD dalam DAD Bertingkat
a) Diagram konteks ( Context Diagram): Diagram paling atas, terdiri dari satu
proses dan mengambarkan ruang lingkup sisrtem.
b) Diagram Prinsif Fungsional ( Functional Primitive ): Diagram-diagram paling
bawah, yang tidak dapat dibagi lagi atau memiliki masukan tunggal dan
keluaran tunggal atau telah sangat sederhana ( narasi untuk deskripsi dapat
dituliskan secara singkat ).
c) Diagran tengah: Diagram-diagram yang terletak antara Diagram Konteks dan
Primitif Fungsional.

26

3. Penyusunan DAD
a. Penomoran
a) Diagram konteks biasanya diberi nomor 0
b) Proses-proses pada DAD paling atas diberi nomor mulai dari 1 dan seterusnya
sampai semua proses bernomor
c) Pada saat setiap proses dipecah menjadi DAD dengan tingkat yang lebih
rendah, maka proses pada DAD tersebut diberi nomor sesuai dengan nomor
proses tadi
d) Setiap proses diberi nomor yang merupakan kombinasi dari nomor diagram
diikuti dengan nomor urut dalam tingkay yang bersangkutan.

b. Bentuk Umum Diagram Konteks :

R

S
Gambar 2.5 Bentuk umum diagram konteks
a) Nomor Diagram ANAK harus diawali dengan nomor proses pada diagram
ORANG TUA yang terkait,

Diagram 0 Diagram 3

Gambar 2.6 Penomoran diagram konteks
TI
T2
O
SISTEM
T3
1
2
3
3.1
3.2 3.3
AAA
Z
Z
Y
X
B
A
X
Y
R
S
A

27

b) Dengan menyebutkan nomor diagram ANAK yang sesuai dengan nomor
proses diagram pada diagram ORANG TUA yang terkait . Nomor proses
pada diagram ANAK boleh tidak diawali dengan nomor proses diagram
ORANG TUA
c) Aturan Keseimbangan ( Balancing )
Semua aliran data yang masuk dan keluar diagram ORANG TUA harus
ada/sama pada diagram ANAK

Diagram 0 Diagram 3

Gambar 2.7 Balancing DFD

4. Kamus Data
Sebuah daftar terorganisasi dari komposisi setiap elemen data, aliran data, dan
penyimpanan data yang digunakan dalam sebuah DAD, serta spesifikasi lojik dari
proses juga modul dan dekripsi modul dari Bagan Susunan dari daftar dari Entitas dan
Relasi yang digunakan didalam Diagram E-R
Nama lain : Requirements Dictionary, Data Dictionary, Encylopedia.
Mengapa diperlukan ?
Karena adanya kebutuhan untuk mendifinisikan isi dari :
a) Aliran Data ( DAD )
b) Penyimpanan Data
c) Proses ( DAD )
d) Entitas ( ERD )
e) Relasi (ERD)
1
2
3
.1
.2 .3
AAA
Z
Z
Y
X
B
A
X
Y
R
S
A

28

5. Notasi Kamus Data
Tabel 2.1 Simbol notasi kamus data
SIMBOL ARTI
=
+
{}
[ ]
( )
* *
Terdiri dari
Dan
Iterasi
Pilihan salah Satu
Boleh ada, boleh tidak
Komentar

Contoh Kamus Data
a) Data : Nomor Telepon
Name : telephon number
aliases : none
where used/low used : access against set-up (output) dial phone
(input)
description :
Telephone number = [ lokal extension | outside number ]
Lokal extension = [ 2001 | 2002 | ..| 2999 ]
Outside number = 9 + [ local number | long distance number ]
Local number = prefix + access number
Long distance number = ( 1 ) + area code + local number
Prefix = [ 795 | 799 | 874 | 877 ]
Access number = *any four number strings

29

b) Arus Data : Surat Pengeluaran Barang
Nama Arus : Sales Order
Alias : SO
Bentuk Data : Cetakan komputer
Arus Data : Pelanggan Proses pemesanan barang
Proses pemesanan Data Store
Penjelasan : Untuk mencatat pemesanan barang
Periode : Setiap ada pesanan
Volume : Rata rata tiap hari adalah 35
Struktur Data <Surat Pesanan Barang> = HEADER + ISI + FOOTER
HEADER = No_SO + Tanggal + Tgl-PO + No PO Costumer + Nama_Pelanggan +
Alamat + Telp
- No_SO : * Terdiri dari lima belas digit *
- Tanggal : Tanggal + Bulan + Tahun
- Nama_Plangan : (Titel) + Nama_depan + Nama_belakang
- Alamat : Jalan + Nomor + Kota
- Telepon : * Maksimal 14 digit *
ISI = 1 {KD_Item + Item + Nama_Barang + Satuan + Quantity + Harga/Unit +
Disc (%) + Jumlah} 20
- item : * Nomor urut *
- Nama Barang : * Jenis barang yang dipesan *
- Satuan : * Maximal tiga digit *
- Harga/unit : * Dalam Rupiah *
-Quantity : * Dihitung dari unit dikali harga satuan dikurangi
discount *
FOOTER = Total
- Total : * Total semua penjualan *

3.3. Entity Relationship Diagram (ERD)
Komponen dari ERD ada 6 yaitu
1) Entitas (Entity)

30

Entitas adalah suatu objek yang dapat dibedakan dari objek lain. Suatu entitas
haruslah bersifat fakta. Entitas dapat berupa fisik, contoh: Mobil, Rumah,
Gedung, dan dapat berupa konsep, contoh: Pekerjaan, Perusahaan.
2) Atribut (Attribute)
Atribut merupakan properti yang dimiliki setiap entitas yang datanya akan
disimpan. Contoh : atribut MAHASISWA -> NIM, Nama, Alamat.
3) Relasi(Relationship)
Asosiasi antara satu atau lebih entitas. Berupa kata kerja.
4) Kardinalitas (Cardinality)

Gambar 3.1 Kardinalitas
5) Kardinalitas menunjukkan banyaknya objek yang terlibat dengan objek lain pada
suatu relasi. Ada 3 kombinasi yang mungkin terjadi, diantaranya : 1:1 (One to
One), 1:N (One to Many), dan N:M (Many to Many).
6) Modalitas (Modality)
Partisipasi sebuah entitas pada suatu relasi. 0 berarti partisipasi parsial. 1 berarti
partisipasi total.
Diagram hubungan entitas memungkinkan seorang perekayasa perangkat lunak untuk
secara penuh menspesifikasikan objek data yang merupakan input dan output dari
sistem, atribut yang mendefinisikan sifat dari objek tersebut, dan hubungan antar objek.
Seperti kebanyakan model analisis elemen, ERD dikonstruksi didalam cara yang
iteratif. Pendekatan berikut ini diambil:
1) Selama pengumpulan persyaratan, pelanggan diminta untuk mendaftar hal-hal
yang akan ditujuoleh proses bisnis dan aplikasi. hal-hal ini dimasukan
kedalam sebuah daftar objek data input dan output dan entitas eksternal yang
menghasilkan atau mengkonsumsi informasi.

31

2) Dengan mengambil objek satu pada satu saat, analis dan pelanggan
mendefinisikan apakiah ada sambungan (tidak diberi nama pada tahap ini) ada
diantara objek data dan objek lain.
3) Dimanapun sambungan ada, analis dan pelanggan menciptakan satu pasangan
hubungan objek atau lebih.
4) Untuk masing-masing pasangan hubungan objek, dicari kardinalitas dan
modalitas.
5) Langkah 2 sampai 4 dilanjutkan secara iteratif sampai semua pasangan
hubungan objek sudah dudefinisikan. Sudah menjadi kebiasaan untuk
menemukan penghilangan pada saat proses ini berlanjut. Objek dan hubungan
baru akan ditambahkan pada saat jumlah iterasi bertambah.
6) Atribut dari masing-masing entitas didefinisikan.
7) Diagram hubungan entitas diformulasikan dan dikaji.
8) Langkah 1 sampai 7 diulang sampai pemodelan data terlengkapi.

3.4. State Transition Diagram (STD)
STD merupakan diagram yang memodelkan tingkah laku (behaviour) sistem
berdasarkan pada definisi satu bagian dari keadaan sistem. STD sering dipakai untuk
menggambarkan kinerja sistem. Komponen STD dibagi menjadi 4 :

a. State
State merupakan kondisi dari suatu sistem. State dapat dikategorikan
menjadi 2 macam, yaitu : State Awal dan State Akhir. State Awal hanya
boleh berjumlah 1 state, dan State Akhir boleh memiliki jumlah lebih dari
satu state.
b. State Change (Tanda Panah)
Menyatakan perubahan state dari sistem.
c. Kondisi
Kondisi menyatakan suatu kejadian pada lingkungan eksternal yang dapat
dideteksi oleh sistem, contoh: sinyal.

32

d. Aksi
sistem melakukan sesuatu sehingga terjadi perubahan state atau merupakan
suatu reaksi terhadap kondisi.

33

BAB IV
ANALISA DAN PERANCANGAN BERORIENTASI OBJEK

4.1. Konsep Umum Metodologi Berorientasi Objek
Ada beberapa tema yang mendasari teknologi berorientasi objek. Meski tema-tema ini
tidak unik pada sistem berorientasi objek, mereka sangat didukung pada metoda
analisis, perancangan serta implementasi dengan metodologi berorientasi objek. Tema-
tema object oriented:
1. Kelas
Kelas membungkus (encapsulating) objek-objek. Suatu kelas tunggal dapat
digunakan untuk menciptakansejumlah objek-objek. Selain itu, suatu kelas juga
dapat digunakan untuk menciptakan kelas-kelas lain yang mewarisi (inheritance)
sebagian atau seluruh data serta fungsi yang dimiliki oleh kelas yang disebutkan
terdahulu.
2. Abstraksi
Abstraksi adalah menemukan hal-hal yang esensial pada suatu objek dan
mengabaikan hal-hal yang sifatnya insidental. Maksudnya adalah menangkap
sesuatu yang berarti untuk dituangkan sistem/perangkat lunak alih-alih menangkap
seluruh fakta yang ada. Penggunaan konsep abstraksi selama analisis berarti
jangan pernah melakukan perancangan dan implementasi sebelum persoalan
benar-benar dipahami.
3. Pembungkusan (Encapsulation) dan Pengiriman Pesan (Message Passing)
Pembungkusan berarti meninggalkan aspek eksternal dari objek yang dapat
dimasuk (diakses) oleh objek lain dan memfokuskan diri pada implementasi
internal suatu objek. Keuntungan pembungkusan adalah kita dapat mengharapkan
suatu objek melakukan metoda apa yang kita inginkan tanpa harus tahu bagaimana
objek itu melakukannya. Kita ibaratkan suatu objek dengan televisi. Kita tidak
perlu tahu bagaimana televisi melakukan suatu tugas tertentu, misalnya
menayangkan gambar tertentu, yang perlu kita ketahui adalahtombol mana pada
remote control yang harus ditekan, kemudian televisi akan berfungs. Penekanan
tombol pada remote control mengirim pesan tertentu ( baca Message) pada televisi,

34

memberitahu metode apa yang akan dilakukan (pindah saluran,mengeraskan suara,
meningkatkan intensitas warna tertentu dan sebagainya).
4. Generalisasi dan Polimorfisme
Generalisasi memungkinkan kelas-kelas berbagi data serta perilaku yang sama.
Pada konteks pemrograman ini memungkinkan penguranganukuran kode dan
menyediakan kemungkinan pengembangan sistem/perangkat lunak yang lebih
mudah dipelihara. Polimorfisme mengijinkan penyesuaian berbagai kode untuk
memenuhi keadaan tertentu.
5. Penggabungan Data (Atribut) dan Perilaku (Fungsi)
6. Sharing
7. Penekanan pada struktur objek, bukan pada struktur prosedur
Teknologi berorientasi objek menekankan pada apa itu objek, bukan pada
bagaimana objek itu digunakan.
8. Sinergis
Identitas, klasifikasi, polimorfisme serta pewarisan adalah karakteristik utama dari
bahasa pemrograman berorientasi objek.

4.2. Konsep Dasar Analisis Berorientasi Objek

Gambar 4.1 Konsep dasar analisis berorientasi objek
Obyek inheritan pada
semua atributnya kelas
Kelas : Mebel
Harga
Dimensi
Berat
Lokasi
Warna
Obyek : Kursi
Harga
Dimensi
Berat
Lokasi
Warna

35

Konsep Dasar:
Object merupakan Entitas yang memiliki data yang menyatakan kondisi pada suatu
saat, dan sekumpulan operasi yang dapat mengakses dan mengubah kondisi tersebut.
Object, dapat berupa:
a. External Entities: sistem lain, alat atau orang yang memberi atau memakai
informasi yang digunakan oleh sistem
b. Things: laporan tampilan, sinyal yang merupakan bagian dan domain informasi
dari masalah.
c. Events or occurences: selesainya gerak robot.
d. Roles: manajer, staf teknik, staf pemasaran yang berperan sebagai orang
berinteraksi dengan sistem.
e. Unit organisasi: divisi, kelompok. Tim yang berhubungan dengan sistem.

4.3. Analisis Berorientasi Objek
Analisis berorientasi objek (OOA- Object Oriented Analysis) adalah tahapan perangkat
lunak dengan menentukan spesifikasi sistem dan mengidentifikasi kelas-kelas serta
hubungannya satu terhadap yang lain. Ivar Jaobson (dikutif dari buku Object Oriented
System Development tulisan Ali Bahrawi, 1999) memperkenalkan konsep use case
sebagai skenario untuk mrnjelaskan interaksi pengguna dengan sistem

Analisis berorientasi objek memiliki 5 (lima) aktivitas:
1. Finding Class & Objects
2. Identifying Structures
3. Identifying Subjects
4. Defining Attributes
5. Defining Service

Ada 5 (lima) lapisan dalam analisis berorintasi objek:
1. Subject layer
2. Class & Onject layer
3. Structure layer

36

4. Attribute layer
5. Service layer
Identifikasi struktur dalam analisis berorientasi objek
1. Generalization Specialialization. (Gen-Spec) Structure dapat dianggap sebagai
is a atau is a kind of.

2. Whole Part Struktur dapat dianggap sebagai has a

Whole Part
a) Sebuah pesawat merupakan assembly dari 0-4 mesin. Dan sebuah mesin
merupakan bagian dari 0-1 pesawat

b) Sebuah organisasi merupakan kumpulan dari 0-n staf. Dan seorang staf
merupakan bagian dari tepat 1 organisasi

Pesawat
Mesin
0-
4
0-1
Organisasi
Staf
0-n
1

37

4.3.1. Subject
a. Masalah yang besar sebaiknya dibagi-bagi dalam lingkup masalah yang lebih kecil
lagi.
b. Begitu pula dalam OO, kelas-kelas yang ada dapat di kumpulkan dalam satu
domain masalah tertentu.
c. Notasi :

4.3.2. Hubungan antar Kelas
2 jenis hubungan antar kelas
a) Intance Connection
merupakan suatu hubungan antar objek, dimana suatu objek membutuhkan objek
lain untuk memenuhi tanggung jawabnya.
b) Message Connection
memodelkan suatu ketergantungan objek. Dimana suatu objek membutuhkan
suatu service darri objek lain (biasanya dari class yang beda) untuk memenuhi
tanggung jawabnya.

4.4. Perancangan Berorientasi Objek
Ada 4 aktivitas dalam perancangan berorientasi objek yaitu
1. Designing the Problem Domain Component
2. Designing the Human Interaction Component
3. Designing the Task Management Component
4. Designing the Data MC
Ada 4 komponen dalam perancangan berorientasi objek yaitu
1. Problem Domain Component (PDC)
2. Human Interaction Component (HIC)
3. Task Management Component (TMC)
4. Data Management Component (DMC)
1. Subject 1 1

1 1

1 1

38

Managemant Component terdiri dari:

Gambar 4.2 Management component
Bahasa Pemprograman Berorientasi Objek (C++)
1. Dikembangkan oleh AT&T Bell Lab.
2. Merupakan evolusi dari bahasa C.
3. Merupakan superset dari bahasa C.
4. Dikembangkan untuk :
a) mempertahankan efisiensi dan portabilitas bahasa C
b) mempertahankan kompatibilitas dengan bahasa C.
c) menutupi kekurangan pada bahasa C.
d) mempertajam penerapan konsep information hidding.
5. DEKLARASI CLASS
a) Makna pernyataan STRUCT diubah menjadi CLASS
Contoh : class ostream {
public:
FILE file:
int nextchar:
char buf[128]:
}
b) Kata public menyebabkan file, nextchar, buf dapat diakses oleh semua
object dalam kelas yang sama.
c) Bila kata public tidak dinyatakan maka data file, nextchar, buf bersifat
private.
6. MEMBER FUNCTION
7. DEKLARASI FUNGSI
8. BASE CLASS
9. DRIVED CLASSES

Subject
Class & Object
Structure
Attribute
Service

39

BAB V
PEMODELAN DATA

Metode pemodelan data menggunakan ERD (Entity Relationship Diagram). Dengan
ERD memungkinkan perekayasa perangkat lunak mengidentifikasi objek data dan
hubungannya dengan menggunakan notasi grafis. ERD hanya berfokus pada data,
dengan menunjukan jaringan data yang ada untuk suatu sistem yang diberikan. ERD
sangat berguna bagi aplikasi dimana data dan hubungan yang mengatur data sangatlah
kompleks.tidak seperti diagram alir data, pemodelan data melihat secara independen
dari pemprosesan yang memtransformasikan data tersebut.
1. ERD merupakan model jaringan yang menggunakan susunan data yang disimpan
dalam sistem secara abstrak
2. Diagram E-R berupa model data konseptual, yang merepresentasikan data dalam
suatu organisasi.
3. ERD menekankan pada struktur dan relationship data, berbeda dengan DFD(Data
Flow Diagram) yang merupakan model jaringan fungsi yang akan dilaksanakan
sistem
4. Biasanya digunakan oleh profesional sistem untuk berkomunikasi dengan pemakai
eksekutif tingkat tinggi dalam perusahaan yang tidak tertarik pada pelaksanaan
operasi sistem sehari-hari, namun lebih kepada :
a. Data apa saja yang diperlukan untuk bisnis mereka?
b. Bagaimana data tersebut berelasi dengan data lainnya?
c. Siapa saja yang diperbolehkan mengakses data tsb?

40

Notasi Yang digunakan pada perancangan E-R diagram

Gambar 5.1 Simbol-simbol ERD
Contoh ER diagram terlampir.

Gambar 5.2 Contoh ERD

latihan
Rancanglah diagram E-R dari kasus aplikasi database sederhanauntuk sistem informasi
akademis suatu universitas.
Dengan ketentuan sebagai berikut :
Entities yang dimuat adalah :
1. mahasiswa: menyimpan semua informasi pribadi mengenai semua mahasiswa
2. dosen: menyimpan semua informasi pribadi mengenai semua dosen
Memasok
BARANG
Mengirim
KIRIMAN
Memasok
PEMASOK
Digunakan_
pada
PRODUK
Beris
i
PESANAN
Mengirim
PELANGGA
N
ENTITAS
Hubungan
Kardinalitas:
Selalu hanya satu
Satu atau banyak
Nol atau satu
Nol, satu, atau banyak
Atribut

41

3. mata_kuliah: menyimpan semua informasi mengenai semua mata kuliah yang
ditawarkan
4. ruang: menyimpan semua informasi mengenai ruang kelas yang digunakan

42

BAB VI
DASAR-DASAR PERANCANGAN PIRANTI LUNAK

6.1. Prinsip Dasar Perancangan Perangkat Lunak
Perancangan Perangkat Lunak merupakan proses penerjemahan dari kebutuhan menjadi
perangkat lunak. Hasil dari perancangan adalah :
1. Rancangan data yang memetakan model domain informasi pada saat analisis
menjadi struktur data yang dibutuhkan untuk implementasi perangkat lunak.
2. Rancangan arsitektural yang mendefinisikan hubungan dari komponen-komponen
struktural utama dari program.
3. Rancangan prosedural yang memetakan komponen-komponen struktural ke
deskripsi prosedur perangkat lunak

ABSTRACTION ( Wasserman )
1. Pada rancangan secara modular, beberapa tingkatan abstraksi dapat diperoleh,
sehingga perancang dapat mengkonsen- trasikan pada setiap tingkatan abstraksi
yang lebih terinci.
2. Pada level paling tinggi, solusi dinyatakan secara global dengan bahasa pada
lingkungan masalah. Dan pada abstraksi paling bawah, solusi dinyatakan dalam
bahasa yang dapat langsung diimplementasikan.
Contoh Abstraksi Program dan Abstraksi Data :
PROGRAM ABSTRACTION

Abstraksi tingkat pertama :
CAD Software Task
User interface Task
2-D Drawing Creation Task

end.

Abstraksi tingkat kedua :
PROCEDURE User interface

end
DATA ABSTACTION

TYPE drawing IS STRUCTURE
DEFINED
Number IS INTEGER
Icon IS ICON_STRUCTURE
Notes IS STRING LENGTH (225)
Versi IS STRING LENGTH ( 10 )

end

43

MODULARITY & SOFTWARE ARCHITECTURE
1. Perangkat lunak dibagi atas beberapa modul.
2. Sebuah modul dapat dibagi lagi atas beberapa sub-modul
3. Modul memiliki nama yang unik.
4. Sebuah modul dapat memanggil modul lainya.

Gambar 6.1 Struktur Evolusi

Gambar 6.2 Struktur Berbeda

S
1
S
2

S
4

S
3

S
5

Software solution
Problem to be solved via software
P
S
5
S
4
S
1
S
3
S
2
S
4
S
1
S
3
S
5
S
2
S
4
S
2
S
3
S
5
S
1
Problem
Structure 1 Structure 2 Structure 3

44

Gambar 6.3 Struktur Terminologi
HIRARKI KONTROL ( STRUKTUR PROGRAM )
1. Menunjukkan organisasi dari modul-modul program dan menunjukan hirarki
kontrolnya. Tidak merepresentasikan aspek prosedural dari perangkat lunak seperti
urutan proses, keputusan, atau perulangan.
2. Kedalaman dan lebar menunjukkan jumlah tingkatan kontrol dan seluruh cakupan
kontrol
3. Fan-out menunjukkan jumlah modul yang secara langsung dikontrol oleh modul
lain
4. Fan-in menunjukkan jumlah modul yang mengontrol modul yang bersangkutan
5. Modul yang mengontrol modul yang lain disebut superordinate
6. Modul yang dikontrol modul yang lain disebut subordinate

FAN-OUT
1. Fan-out dari sebuah modul adalah banyaknya subordinate langsung dari modul
tersebut
2. Perluasan kontrol dari sebuah modul sebaiknya tidak melebihi 7 + 2 ( kecuali pada
pusat-pusat transaksi )
3. Hindarkan Fan-out yang bersifat main-line (satu boss, dengan modul-modul lain
sebagai subordinate )
Depth
Width
Fan-out
Fan-in
M
b c a
k d e l m
g f h o n p q
i j r

45

4. Sebuah modul dengan Fan-out yang banyak biasanya sukar dipelihara.
5. Untuk memecahkan fan-out yang banyak gunakan modul-modul antara

FAN-IN
1. Fan-in dari modul adalah banyaknya modul lain yang ( boss )
menggunakan/memanggil modul tersebut.
2. Jika mungkin Fan-in harus dilakukan sebanyak-banyaknya.
3. Fan-in yang banyak menghindari pengulangan pembuatan modul yang sama atau
serupa
4. Fan-in yang banyak mempermudah pemeliharaan karena menempatkan suatu fungsi
yang sama dalam satu modul

STRUKTUR DATA
Refresentasi lojikal dari hubungan antara elemen-elemen data.

Gambar 6.4 Struktur Data Klasik

A linked list
A scalar item
A scalar item

An N-dimensional space

A hierarchical tree

46

PROSEDUR PERANGKAT LUNAK
Struktur program hanya mendefinisikan hirarki kontrol tanpa memperhatikan urutan
proses. Prosedur perangkat lunak berfokus pada rincian proses dari setiap modul.

INFORMATION HIDING ( by Pamas )
Prinsip dasar dalam pembentukan modul dimana hanya data yang benar-benar perlu,
yang dikenalkan dan dapat diakses oleh sebuah modul.

Gambar 6.5 Prosedur Berlapis
Module
A
Module
A
Prosedur di dalam
suatu modul

47

6.2. PERANCANGAN YANG MODULAR
1. Keuntungan :
a) menurunkan kompleksitas
b) mempermudah pengubahan
c) implementasi yang lebih mudah karena bagian-bagian yang berbeda dapat dibuat
dengan paralel
2. Evaluasi dari hubungan antar modul dapat dinilai dengan melihat kohesi dan
koplingnya ( Steven, Myers, dan Constantine )

KOPLING
1. Kopling adalah tingkat saling ketergantungan antara dua modul.
2. Kita menghendaki modul dengan kopling rendah yaitu modul-modul yang sedapat
mungkin tidak saling bergantungan.
3. Kopling yang rendah adalah tanda dari pembagian sistem yang baik, dimana
sesuatu yang tidak berhubungan dipisahkan.
4. Jika sedikit atau tidak ada interaksi dua modul disebut loosely coupled (kopling
rendah) dan jika sebaliknya disebut tighty coupled (kopling tinggi)
5. Makin tinggi kopling yang ada makin sulit sebuah program untuk dimengerti.
6. Jika dua modul memiliki kopling yang rendah, maka sebuah modul dapat diubah
tanpa perlu mengubah modul yang lain.
7. Mengapa kopling yang rendah diperlukan ?
Untuk menghilangkan ripple effect (perubahan pada sebuah modul dapat
berpengaruh pada modul lain). Sehingga dapat memelihara atau mengubah suatu
modul dengan resiko yang minimal untuk mengubah modul lainnya. Jika mungkin
kita ingin dapat bekerja dengan modul A tanpa perlu mengetahui tentang apapun
dalam modul B.
8. Faktor-faktor yang berpengaruh pada kopling antara dua modul adalah :
a) Jumlah item data yang disalurkan diantara dua modul (makin banyak data yg
disalurkan makin tinggi kopling yang terjadi).
b) Jumlah data kontrol yang disalurkan diantara dua modul (makin banyak data
kontrol yang disalurkan makin tinggi kopling yang terjadi)

48

X
X

Y
Y
Lalu lintas jalan
Kopling rendah Kohesi tinggi

Y
X

X
Y
Lalu lintas jalan
Kopling tinggi Kohesi rendah
c) Jumlah elemen data global yang digunakan bersama-sama oleh beberapa modul
(makin banyak data global yang digunakan, makin tinggi kopling yang terjadi)

KOHESI
1. Melekatkan hal-hal yang berkaitan didalam modul yang sama, akan mengurangi
lalu-lintas diantara modul-modul .
2. Apa yang terjadi diantara modul-modul (kopling) dipengaruhi oleh apa yang terjadi
dalam modul-modul tersebut secara individual (kohesi)
3. Kohesi adalah ukuran kekuatan asosiasi antar elemen didalam suatu modul.
4. Elemen yang dimaksud adalah : sebuah instruksi, sekumpulan intruksi, atau
pemanggilan ke modul lain.
5. Kohesi tinggi jika sebuah modul hanya bertanggung jawab terhadap satu pekerjaan
saja.

Gambar 6.6 Kohesi
6.3. RANCANGAN DATA
1. Rancangan data yang bagus dapat membuat struktur program lebih baik,
modularitas efektif dan menurunkan kompleksitas prosedural
2. Beberapa petunjuk :
a) Semua struktur data dan operasi yang mengolahnya harus didefinisikasi
b) Selalu gunakan kamus data

49

c) Rancanagan data yang bersifat low-level harus ditunda sampai akhir dari
proses perancangan
d) Bentuk keputusan dan struktur data dan operasi-operasi yang mengolahnya
e) Bahasa pemrograman harus mendukung spesifikasi dan realisasi dari tipe data
abstrak.
6.4. PERANCANGAN ARSITEKTURAL
Tujuan dari perancangan arsitektural adalah untuk membangun struktur program yang
modular dan membentuk hubungan kontrol antar modul. Rancangan arsitektural
menggabungkan struktur program dan struktur data serta mendefinisikan interfaceyang
membuat data melalui program. Dan dinyatakan dalam bentuk Bagan Susunan atau
diagram Wamier/Orr.

BAGAN SUSUNAN (Structured Chart)
1. Bagan susunan merupakan susunan hirarki dari modul-modul
2. Bagan susunan menunjukkan
a) pembagian sistem menjadi modul-modul
b) hirarki dan organisasi modul-modul
c) komunikasi antar modul ( masukan dan keluaran )
d) nama modul, yang berarti juga fungsi modul.
3. Bagan Susunan tidak menunjukkan :
a) Mekanik didalam modul ( seperti ukuran pemanggilan modul lain, loops dsb )
b) Data internal dari modul
Simbol-simbol yang digunakan :

Gambar 6.7 Simbol-simbol bagan terstruktur
: hubungan 2
: pengulangan 3
: Seleksi / pemilihan 4

: Kopel Kontrol 5

: Kopel Data 6
: Nama Modul / Proses 1

50

Contoh :

Menunjukkan suatu model dengan nama Hitung Potongan.

Modul A memanggil modul B. Setelah proses dari modul B selesai, maka proses
kembali ke modul A yang memanggilnya.

Modul A memanggil modul B dan elemen data P dikirimkan dari modul A ke modul B.
Hasil proses dari modul B mengirimkan elemen data Q dan elemen kontrol Flag ke
modul A.

51

Modul A memanggil modul B bila kondisi yang diseleksi di modul terpenuhi. Modul A
juga memanggil modul C berulang kali yang ditunjukkan oleh simbol perulangan.
Model Bagan Terstruktur
Terdapat dua model dari bagan terstruktur, yaitu transformed-centered dan transaction
centered. Bagan terstruktur dapat berbentuk model transformed-centered saja atau
transaction centered saja atau kombinasi dari keduanya. Model yang digunakan ini
tergantung dari diagram arus data yang telah dibuat, karena bagan terstruktur
digambarkan berdasarkan diagram arus data (DAD).
a. Transformed-centered
Bagan terstruktur dengan model transformed-centered menggambarkan sistem
dalam 3 cabang utama, yaitu sebagai berikut :
1. Cabang input (input branch) atau disebut juga dengan affrerent branch,
merupakan cabang yang menerima input dan membentuk input kedalam suatu
status yang siap untuk diproses.
2. Cabang proses (process branch) atau disebut juga dengan cabang transformasi
(transform branch) atau disebut juga dengan central transform, merupakan
cabang yang akan melakukan fungsi utama dari sistem, yaitu memperoses
input yang dikirim dari cabang input.
3. Cabang output (output branch) atau disebut juga dengan efferent branch,
merupakan cabang yang akan memformat data menjadi output.

52

Gambar 6.8 Model dasar bagan terstruktur transformed-centered

b. Transaction-centered
Seringkali diagram arus data menggambarkan suatu sistem yang menangani
beberapa tipe transaksi yang mempunyai jalur yang berbeda. Diagram tersebut
mungkin akan sulit dipilah-pilah berdasarkan transformasinya. Untuk diagram alur
data tersebut, dapat dibuat bagan terstruktur model transaction-centered.

53

Gambar 6.9 Model bagan terstruktur jenjang dari transaction-centered

Contoh :

54

TABEL KEPUTUSAN
Tabel keputusan (decision table) adalah tabel yang digunakan sebagai alat bantu untuk
menyelesaikan logika dalam program

Condition Stub
Bagian ini berisi kondisi yang akan diseleksi.
Condition Entry
Bagian ini berisi kemungkinan dari kondisi yang diseleksi, yaitu
terpenuhi (diberi simbol Y) dan tidak terpenuhi (diberi simbol N).
Bila ada kondisi X diseleksi, terdapat N Kemungkinan terjadi N = 2
X

Action Stub
Action stub berisi pernyataan-pernyataan yang akan dikerjakan baik
kondisi yang diselesi terpenuhi maupun tidak terpenuhi.
Action Entry
Action entry digunakan untuk memberi tanda tindakan mana yang akan
dilakukan dan mana yang tidak akan dilakukan

55

DIAGRAM KEPUTUSAN
Merupakan model dari sebuah fungsi diskrit dimana nilai dari sebuah variabel
ditentukan; berdasarkan nilai ini beberapa tindakan dilakukan

56

BAHASA TERSUSUN
Konteks Logik :

BIT/SE merupakan jembatan antara analisis perancangan dan pengkodean
BIT/SE adalah bahasa spesifikasi yang menggunakan perbendaraan kata dan
sintaks yang terbatas
Perbendaharaan katanya hanya terdiri dari :
Kata kerja perintah/Imperative language verb.
Istilah yang didefinisikan dalam Kamus Data.
Reserved Word tertentu untuk formulasi logik.
Contoh :
JIKA MASA-KERJA LEBIH DARI 15 TAHUN
MAKA
BONUS = 100.000
SELAIN ITU
BONUS = 50.000
AKHIR JIKA

57

DIAGRAM ALIR/FLOWCHART

BOX DIAGRAM/N-S CHART

58

Contoh :

59

6.5. RANCANGAN PROSEDURAL
Rancangan prosedural dilakukan setelah struktur program dan data telah dibentuk.
Beberapa bentuk pernyataan :
1. pemrograman terstruktur
2. notasi grafis : flowchart, box diagram/N-S charts
3. bentuk tabel
4. PDL

KARAKTERISTIK NOTASI PERANCANGAN
1. Mendukung modularistas
2. Sederhana
3. Mudah diubah
4. Dapat dibaca oleh mesin
5. Dapat dipelihara
6. Structured enforcerment
7. Code-to-ability
8. Dapat diverifikasi

Beberapa Pedoman
1. Pemakai sistem harus selalu mengetahui apa yang mesti dilakukan berikutnya
a) beritahu pemakai apa yang diharapkan oleh sistem sekarang Contoh : SIAP,
MASUKKAN PERINTAH, MASUKKAN PILIHAN atau MASUKKAN
DATA.
b) Beritahu pemakai bahwa data telah dimasukkan dengan benar, Bisa berupa
perpindahan kursor ke data berikutnya atau pesan : MASUKKAN VALID
c) Beritahu pemakai bahwa pemasukkan data salah. Pemberitahuan format yang
benar lebih baik.
2. Bentuk pemakaian alasan adanya delay dalam pemrosesan.
Contoh : SORTING, PLEASE STAND BY, INDEXING, PLEASE WAIT, THIS
MAY TAKE A FEW MINUTES, TUNGGU SEBENTAR, Adanya pesan membuat
pemakai mengetahui bahwa sistem tidak gagal.

60

3. Beritahu pemakai sebuah pekerjaan selesai atau tidak selesai dilakukan Contoh :
PRINTING, COMPLETE, PRINTER NOT READY PLEASE CHECK AND
TRY AGAIN.

Rancangan Layar :
1. Layar sebaiknya diatur agar beberapa tipe informasi, intruksi dan pesan selalu
muncul di area yang konsisten. Ini akan membantu pemakai mencari informasi
yang spesifik
2. Perancangan layar yang terlalu norak
3. Berikan kesempatan pemakai menghemat pengetikan dengan function keys
4. Jika memungkinkan, berikan harga baku
5. Antisipasi kesalahan yang mungkin dibuat oleh pemakai.
a. Contoh : YAKIN DIHAPUS ?
6. Selalu Konsisten
7. Kurang jumlah informasi yang harus diingat diantaranya aksi

Penulisan Program
1. Cobalah untuk langsung menggunakan keistimewaan yang ada pada bahasa
pemrograman
2. Cobalah untuk menggunakan library dan fungsi-fungsi yang telah ada pada bahasa
pemrograman
3. Jangan mengabaikan pesan-pesan peringatan ( warning message )

Beberapa pedoman Bahasa
1. Sederhana, dan benar secara aturan bahasa.
o Bahasa percakapan lebih baik daripada bahasa tulisan
2. Jangan berusaha melucu atau sok imut .
o jika penggunaan harus memakainya 25x seharai. Akan tidak lucu lagi.
3. Jangan menyinggung intelegensia pemakai

61

Penulisan Pemrograman
1. Jumlah perintah dalam suatu subprogram sebaiknya 5 100 perintah
2. Jumlah paremeter yang di-pass sebaiknya <= 5
3. Hindari penggunaan GO TO
4. Gunakan identitasi
5. Kedalaman pernyataan bersarang sebaiknya < 5. Pengecualian untuk penggunaan
fungsi rekursif.
6. Kemampuan program untuk dibaca lebih penting dari pada efesiensi program
7. Gunakan nama-nama yang punya arti

Komentar
1. Berilah komentar pada program anda.
2. Hindari komentar yang terlalu panjang
3. Komentar merupakan jawaban dari pertanyaan pembaca program
4. Berilah komentar setiap variabel
5. Komentar bukan terjemahan dari program anda.

Perbaikan Program
1. Lupakan semua tentang efisiensi sampai program anda dapat bekerja dengan benar.
2. Jangan mencoba untuk memperbaiki sampai anda mengerti benar programnya
3. Jangan mengorbankan kemampuan untuk dibaca demi efisiensi

Pemilihan Bahasa
1. Jika dibutuhkan struktur data yang kompleks : PASCAL, C
2. Jika kinerja, kemampuan real-time : ADA
3. Jika perlu efisiensi memori :C
4. Banyak report & banyak manipulasi berkas : COBOL, 4GL, RPG
5. Akan lebih mudah jika hanya satu bahasa tersedia atau sudah ditemukan oleh
pemakai. Pada banyak kasus mengikuti sistem yang sudah ada
6. Beberapa de-facto :
a) C untuk sistem software
b) Ada, C, Modula-2 untuk aplikasi real-time

62

c) COBOL, 4GL untuk aplikasi bisnis
d) FORTRAN untuk aplikasi sains dan teknik
e) PASCAL, C untuk program-program aplikasi di PC
f) LISP, PROLOG untuk kecerdasan buatan

63

BAB VII
PENGANTAR UML (Unified Modeling Language)

7.1. Definisi UML
Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah menjadi standar
dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti
lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem.
Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi
piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi
dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun. Tetapi karena
UML juga menggunakan class dan operation dalam konsep dasarnya, maka ia lebih
cocok untuk penulisan piranti lunak dalam bahasabahasa berorientasi objek seperti C++,
Java, C# atau VB.NET. Walaupun demikian, UML tetap dapat digunakan untuk
modeling aplikasi prosedural dalam VB atau C. 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 [1], metodologi coad [2],
metodologi OOSE [3], metodologi OMT [4], metodologi shlaer-mellor [5], metodologi
wirfs-brock [6], dsb. 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 bekerjasama
dengan group/perusahaan lain yang menggunakan metodologi yang berlainan.
Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan
tiga tokoh yang boleh dikata 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

64

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 [7] [8] [9]. Sejak saat itulah UML telah menjelma
menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek.

7.2. Konsep Dasar UML

Gambar 7.1 Konsep Dasar UML
Abstraksi konsep dasar UML yang terdiri dari structural classification, dynamic
behavior, dan model management, bisa kita pahami dengan mudah apabila kita melihat
gambar diatas dari Diagrams. Main concepts bisa kita pandang sebagai term yang akan
muncul pada saat kita membuat diagram. Dan view adalah kategori dari diagaram
tersebut. Lalu darimana kita mulai ? Untuk menguasai UML, sebenarnya cukup dua hal
yang harus kita perhatikan:
1. Menguasai pembuatan diagram UML
2. Menguasai langkah-langkah dalam analisa dan pengembangan dengan UML
Tulisan ini pada intinya akan mengupas kedua hal tersebut. Seperti juga tercantum pada
gambar diatas UML mendefinisikan diagram-diagram sebagai berikut:
a) use case diagram
b) class diagram

65

c) statechart diagram
d) activity diagram
e) sequence diagram
f) collaboration diagram
g) component diagram
h) deployment diagram

7.2.1. Use Case Diagram
Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem.
Yang ditekankan adalah apa yang diperbuat sistem, dan bukan bagaimana. Sebuah
use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case
merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah
daftar belanja, dan sebagainya. Seorang/sebuah aktor adalah sebuah entitas manusia
atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan
tertentu. Use case diagram dapat sangat membantu bila kita sedang menyusun
requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan
merancang test case untuk semua feature yang ada pada sistem. Sebuah use case dapat
meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya.
Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali
use case yang meng-include dieksekusi secara normal. Sebuah use case dapat di-include
oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari
dengan cara menarik keluar fungsionalitas yang common. Sebuah use case juga dapat
meng-extend use case lain dengan behaviour-nya sendiri. Sementara hubungan
generalisasi antar use case menunjukkan bahwa use case yang satu merupakan
spesialisasi dari yang lain. Contoh use case diagram:

66

Gambar 7.2 Contoh Use Case
7.2.2. Class Diagram
Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek
dan merupakan inti dari pengembangan dan desain berorientasi objek. Class
menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan
untuk memanipulasi keadaan tersebut (metoda/fungsi). Class diagram menggambarkan
struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti
containment, pewarisan, asosiasi, dan lain-lain. Contoh class diagram:

Gambar 7.3 Contoh Class Diagram

67

7.2.3. Activity Diagram
Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang
dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan
bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel
yang mungkin terjadi pada beberapa eksekusi. Activity diagram merupakan state
diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi
di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu
activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi
antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur
aktivitas dari level atas secara umum. Sebuah aktivitas dapat direalisasikan oleh satu use
case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case
menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas.
Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat
untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour
pada kondisi tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join)
digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.
Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan
objek mana yang bertanggung jawab untuk aktivitas tertentu. Contoh activity diagram
tanpa swimlane:

Gambar 7.3 Contoh Activity Diagram

68

7.2.4. Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem
(termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan
terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi
horizontal (objek-objek yang terkait). Sequence diagram biasa digunakan untuk
menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai
respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang
men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara
internal dan output apa yang dihasilkan. Masing-masing objek, termasuk aktor,
memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek
ke objek lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi
operasi/metoda dari class. Activation bar menunjukkan lamanya eksekusi sebuah
proses, biasanya diawali dengan diterimanya sebuah message. Untuk objek-objek yang
memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk objek boundary,
controller dan persistent entity. Contoh sequence diagram:

Gambar 7.4 Contoh Sequence Diagram

69

7.2.5. Tool Yang Mendukung UML
Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool komersial
maupun opensource. Beberapa diantaranya adalah:
1) Rational Rose (www.rational.com)
2) Together (www.togethersoft.com)
3) Object Domain (www.objectdomain.com)
4) Jvision (www.object-insight.com)
5) Objecteering (www.objecteering.com)
6) MagicDraw (www.nomagic.com/magicdrawuml)
7) Visual Object Modeller (www.visualobject.com)

70

BAB VIII
PENGUJIAN PERANGKAT LUNAK

Saat ini sudah banyak berkembang berbagai metode untuk pengujian perangkat lunak.
Metode-metode tersebut memberikan pendekatan yang sistematik untuk pengujian
perangkat lunak kepada pengembang. Selain itu, metode-metode tersebut memberikan
mekanisme yang dapat membantu memastikan kelengkapan pengujian dan memberikan
kemungkinan tertinggi untuk mengungkap kesalahan pada perangkat lunak.
Semua produk yang direkayasa dapat diuji dengan satu atau dua cara, yaitu:
1) Dengan mengetahui fungsi yang ditentukan untuk dilakukan oleh suatu produk,
pengujian dapat dilakukan untuk memperlihatkan bahwa masing-masing fungsi
beroperasi sepenuhnya dan pada waktu yang sama mencari kesalahan pada setiap
fungsi
2) Dengan mengetahui kerja internal suatu produk, maka pengujian dapat dilakukan
untuk memastikan bahwa seluruh operasi internal bekerja sesuai spesifikasi dan
semua komponen internal telah diamati dengan memadai
Pendekatan pengujian pertama disebut sebagai pengujian black-box dan pengujian
kedua disebut sebagai pengujian white-box. Pengujian black-box berkaitan dengan
pengujian yang dilakukan pada antarmuka perangkat lunak. Meskipun dirancang untuk
mengungkap kesalahan, pengujian black-box digunakan untuk memperlihatkan bahwa
fungsi-fungsi perangkat lunak dapat beroperasi, bahwa input diterima dengan baik dan
output dihasilkan dengan tepat, dan integritas informasi eksternal (seperti file data)
dipelihara. Pengujian black-box menguji beberapa aspek dasar suatu sistem dengan
memperhatikan sedikit struktur logika internal perangkat lunak tersebut.
Pengujian white-box didasarkan pada pengamatan yang teliti terhadap detail prosedural.
Jalur-jalur logika yang melewati perangkat lunak diuji dengan memberikan kasus uji
yang menguji serangkaian kondisi dan atau loop tertentu. Status program tersebut dapat
diuji pada berbagai titik untuk menentukan apakah status yang diharapkan sesuai
dengan status yang sebenarnya.
Sekilas terlihat bahwa pengujian white-box yang sangat teliti akan membawa kepada
program yang benar 100%. Yang diperlukan adalah menentukan semua jalur logika,
mengembangkan kasus uji untuk mengujinya, dan mengevaluasi hasil, yaitu

71

memunculkan kasus uji untuk menguji logika program secara mendalam. Namun sesuai
dengan prinsip pengujian, pengujian secara mendalam akan menimbulkan masalah
logistik. Bahkan untuk program yang kecil, dapat dibangkitkan jumlah jalur logika yang
besar.
Tetapi pengujian white-box tidak boleh dianggap tidak praktis. Sejumlah jalur logika
yang penting dapat dipilih dan digunakan. Struktur-struktur data yang penting dapat
diperiksa validitasnya. Atribut pengujian black-box dan white-box dapat digabungkan
untuk memberikan pendekatan yang memvalidasi antarmuka perangkat lunak, dan
secara selektif menjamin bahwa kerja internal perangkat lunak itu benar.

8.1. White-Box Testing
White-box testing (kadang-kadang disebut sebagai glass-box testing) adalah metode
desain kasus uji yang menggunakan struktur kontrol desain prosedural untuk
memperoleh kasus uji. Dengan menggunakan metode pengujian white-box, perekayasa
sistem dapat melakukan kasus uji yang:
1) Memberikan jaminan bahwa semua jalur independen pada suatu modul telah
digunakan paling tidak satu kali
2) Menggunakan semua keputusan logis pada sisi true dan false
3) Mengeksekusi semua loop pada batasan mereka dan pada batas operasional
mereka
4) Menggunakan struktur data internal untuk menjamin validitasnya
Muncul pertanyaan tentang mengapa menghabiskan waktu dan sumber daya untuk
menguji logika jika dapat memastikan bahwa persyaratan program telah dapat dipenuhi
dengan lebih baik. Jawaban dari pertanyaan ini ada pada sifat cacat perangkat lunak
seperti:
a) Kesalahan logis dan asumsi yang tidak benar berbanding terbalik dengan
probabilitas jalur program yang akan dieksekusi. Kesalahan cenderung
muncul pada saat perancangan dan implementasi fungsi, kondisi, atau kontrol
yang berada di luar mainstream
b) Kepercayaan bahwa jalur logika mungkin tidak akan dieksekusi bila pada
kenyataannya mungkin dieksekusi pada basis reguler. Aliran logika dari
program kadang bersifat konterintuitif, artinya asumsi yang tidak disadari

72

mengenai aliran dan data kontrol dapat menyebabkan kesalahan perancangan
yang akan terungkap setelah pengujian jalur dimulai
c) Kesalahan tipografi sifatnya acak. Bila sebuah program diterjemahkan ke
dalam source code bahasa pemrograman, maka dimungkinkan akan terjadi
banyak kesalahan pengetikan. Beberapa kesalahan dapat ditemukan melalui
mekanisme pengecekan sintaks, namun yang lainnya tidak akan terdeteksi
sampai dilakukan pengujian
Sifat cacat tersebut sangat mungkin ditemukan dengan menggunakan pengujian white-
box sedangkan pengujian black-box tidak dapat menemukannya seberapa cermat pun
pengujian black-box dilakukan. Alasan inilah yang mendasari mengapa pengujian
white-box dilakukan.
Jenis pengujian White-Box testing antara lain:
1. Basis path testing
2. Control Structure Testing, yang terdiri dari:
- Condition Testing
- Data Flow Testing
- Loop Testing

UJI COBA 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 dan menggunakan ukuran ini sbg petunjuk untuk
mendefinisikan basis set dari jalur pengerjaan. Test case yg didapat digunakan untuk
mengerjakan basis set yang menjamin pengerjaan setiap perintah minimal satu kali
selama uji coba.
a) Notasi diagram alir

Gambar 8.1 Notasi diagram alir

73

Untuk menggambarkan pemakaian diagram alir diberikan contoh perancangan
prosedural dalam bentuk flowchart.

Gambar 8.2 Diagram alir flowchart

Selanjutnya diagram alir diatas dipetakan ke grafik alir

Gambar 8.3 Diagram grafik alir

74

Lingkaran/node :
Menggambarkan satu/lebih perintah prosedural. Urutan proses dan keputusan dapat
dipetakan dalam satu node.
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.

Contoh menterjemahkan pseudocode ke grafik alir

1: do while record masih ada
baca record
2: if record ke 1 = 0
3: then proses record
simpan di buffer
naikan kounter
4: else if record ke 2 = 0
5 then reser kounter
6 proses record
simpan pada file
7a: endif
endif
7b: enddo
8 : end

Nomor pada pseudocode berhubungan dengan nomor node. Apabila diketemukan
kondisi majemuk (compound condition) pada pseudcode pembuatan grafik alir menjadi

75

rumit. Kondisi majemuk mungkin terjadi pada operator Boolean (AND, OR, NAND,
NOR) yg dipakai pada perintah if.
Contoh :

if A or B
then procedure x
else procedure y
endif
Node dibuat terpisah untuk masing-masing kondisi A dan B dari pernyataan IF A OR B.
Masing-masing node berisi kondisi yg disebut predicate node dan mempunyai
karakteristik dua atau lebih edge darinya.
b) Cyclomatic Complexity
Cyclomatic complexity adalah metrik PL yang menyediakan ukuran kuantitatif dari
kekompleksan logikal program. Apabila digunakan dalam kontek metode uji coba basis
path, nilai yang dihitung untuk cyclomatic complexity menentukan jumlah jalur
independen dalam basis set suatu program dan memberi batas atas untuk jumlah uji
coba yang harus dikerjakan untuk menjamin bahwa seluruh perintah sekurang-
kurangnya telah dikerjakan sekali.
Jalur independent adalah jalur yang melintasi atau melalui program dimana sekurang-
kurangnya terdapat proses perintah yang baru atau kondisi yang baru.
Dari gambar 8.3 :
Path 1 : 1 - 11
Path 2 : 1 - 2 - 3 - 4 - 5 - 10 - 1 - 11
Path 3 : 1 - 2 - 3 - 6 - 8 - 9 ...: 10 - 1 - 11

76

Path 4 ': 1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11
Path 1,2,3,4 yang telah didefinisikan di atas merupakan basis set untuk diagram alir.
Cyclomatic complexity digunakan untuk mencari jumlah path dalam satu flowgraph.
Dapat dipergunakan rumusan sbb :
1. Jumlah region grafik alir sesuai dengan cyclomatic complexity.
2. Cyclomatix complexity V(G) untuk grafik alir dihitung dengan rumus:
V(G) = E - N + 2
dimana:
E = jumlah edge pada grafik alir
N = jumlah node pada grafik alir
3. Cyclomatix complexity V(G) juga dapat dihitung dengan rumus:
V(G) = P + 1
dimana P = jumlah predicate node pada grafik alir
Pada Gambar 8.3 dapat dihitung cyclomatic complexity:
1. Flowgraph mempunyai 4 region
2. V(G) = 11 edge - 9 node + 2 = 4
3. V(G) = 3 predicate node + 1 = 4
Jadi cyclomatic complexity untuk flowgraph Gambar 8.3 adalah 4
c) Melakukan Test Case
Metode uji coba basis path juga dapat diterapkan pada perancangan prosedural rinci
atau program sumber. Pada bagian ini akan dijelaskan langkah-langkah uji coba basis
path. Prosedur rata-rata pada bagian berikut akan digunakan sebagai contoh dalam
pembuatan test case.

PROCEDURE RATA-RATA
INTERFACE RESULT rata, total, input, total.valid
INTERFACE RESULT nilai, minim, max
TYPE NILAl (1:100) IS SCALAR ARRAY;
TYPE rata, total. input, total.valid, max.minim, jumlah IS SCALAR;
TYPE I IS INTEGER;
I = 1;
total. input = total. valid = 0;

77

jumlah = 0;
DO WHILE nilai(i) <> -999 .and. total.input < 100
tambahkan total.input dengan 1;
IF nilai(i) >= minimum .and. nilai(i} <=max;
THEN tambahkan total.valid dengan I;
jumlah=jumlah + nilai(i);
ELSE skip;
END IF
tambahkan i dengan 1;
ENDDO
IF total. valid> 0
THEN rata =jumlah/total. valid;
ELSE rata = -999;
ENDIF
END
Langkah-Iangkah pembuatan test case:
1. Dengan mempergunakan perancangan prosedural atau program sumber sebagai
dasar, digambarkan diagram alirnya.

Gambar 8.4 Diagram grafik alir prosedure rata-rata
2. Tentukan cyclomatic complexity untuk diagram alir yang telah dibuat:
V (G) = 6 region .
V(G) = 17 edge - 13 node + 2 = 6

78

V(G) = 5 predicate node + 1 = 6
3. Tentukan independent path pada flowgraph
Dari hasil perhitungan cyclomatic complexity terdapat 6 independent path yaitu:
path 1 : 1-2-10-11-13
path 2 : 1-2-10-12-13
path 3 : 1-2-3-10-11-13
path 4 : 1-2-3-4-5-8-9-2-..
path 5 : 1-2-3-4-5-6-8-9-2-..
path 6 : 1-2-3-4-5-6-7-8-9-2-...
4. Buat test case yang akan mengerjakan masing-masing path pada basis set. Data
yang dipilih harus tepat sehingga setiap kondisi dari predicate node dikerjakan
semua.
d) Graph Metrik
Graph metrik merupakan PL yang dikembangkan untuk membantu uji coba basis
path atau struktur data. Graph metrik adalah matrik empat persegi yang mempunyai
ukuran (sejumlah baris dan kolom) yang sama dengan jumlah node pada flowgraph.
Masing-masing baris dan kolom mempunyai hubungan dengan node yang telah
ditentukan dan pemasukan data matrik berhubungan dengan hubungan (edge)
antarnode.
Contoh sederhana pemakaian graph matrik dapat digambarkan sbb :

Gambar 8.5 Graph Metrik

79

Pada gambar flowgraph masing-masing node ditandai dengan angka clan edge dengan
huruf kecil, kemudian diterjemahkan ke graph matrik. Contoh hubungan node 3 dengan
node 4 pada graph ditandai dengan huruf b.
Hubungan bobot menyediakan tambahan informasi tentang aliran kontrol. Secara
simpel hubungan bobot dapat diberi nilai 1 jika ada hubungan antara node atau nilai 0
jika tidak ada hubungan. Dapat juga hubungan bobot diberi tanda dengan:
kemungkinan link (edge) dikerjakan
waktu yang digunakan untuk proses selama traversal dari link
memori yang diperlukan selama traversal link
sumber daya yang diperlukan selama traversal link

Gambar 8.6 Hubungan bobot
Koneksi :
1 1 = 0
2 1 = 1
2 1 = 1
2 1 = 1
3 + 1 = 4 cyclomatic complexity

PENGUJIAN LOOP
Loop merupakan kendala yang sering muncul untuk menerapkan algoritma dengan
tepat. Uji coba loop merupakan teknik pengujian white box yg fokusnya pada validitas
dari loop. Kelas loop yaitu :

80

a. Loop Sederhana, pengujian loop sederhana dilakukan dgn mudah, dimana n
jumlah maksimum yg diijinkan melewati loop tsb.
1. Lewati loop secara keseluruhan
2. Hanya satu yg dapat melewati loop
3. m dapat melewati loop dimana m< n
b. Loop Tersarang, pengujian loop ini menggunakan pendekatan loop sederhana.
Petunjuk pengujian loop tersarang :
1. Dimulai dari loop paling dalam. Atur semua loop ke nilai minimum.
2. Kerjakan dgn prinsip loop sederhana untuk loop yg paling dalam sementara
tahan loop yang di luar pada parameter terkecil (nilai kounter terkecil)
3. Kemudian lanjutkan untuk loop yg diatasnya.
4. Teruskan sampai semua loop selesai di uji.
c. Loop Terangkai, pengujian loop ini menggunakan pendekatan loop sederhana bila
masing-masing loop independen, tetapi bila dua loop dirangkai dan pencacah loop 1
digunakan sebagai harga awal loop 2 maka loop tersebut jadi tidak independen,
maka pendekatan yg diaplikasikan ke loop tersarang direkomendasikan.
d. Loop Tidak Terstruktur, Kapan saja memungkinkan, loop ini didisain kembali
agar mencerminkan penggunaan komsepsi pemrograman terstruktur.

Gambar 8.7 Macam-macam loop

81

8.2. Black-Box Testing
Pengujian ini fokus kepada persyaratan fungsional perangkat lunak. Pengujian ini
memungkinkan pelaku RPL mendapatkan serangkaian kondisi input yang memenuhi
persyaratan fungsional suatu program.
Pengujian ini berusaha menemukan kesalahan dengan kategori sebagai berikut:
1. Fungsi-fungsi yang salah atau hilang
2. Kesalahan antarmuka
3. Kesalahan struktur data atau akses basisdata eksternal
4. Kesalahan kinerja
5. Kesalahan inisialisasi atau terminasi
Pengujian ini cenderung untuk dilakukan pada tahap akhir pengujian berbeda dengan
white-box testing. Penguji dituntut untuk menjawab pertanyaan-pertanyaan berikut:
a) Bagaimana validitas fungsional diuji?
b) Kelas input apa yang akan membuat kasus uji menjadi baik?
c) Apakah sistem sangat sensitif terhadap nilai input tertentu?
d) Bagaimana batasan suatu data diisolasi?
e) Berapa kecepatan dan volume data yang dapat ditolerir sistem?
f) Apa pengaruh kombinasi tertentu dari data terhadap operasi sistem?
Dengan mengaplikasikan teknik pengujian ini, penguji membuat serangkaian kasus uji
yang:
a) Mengurangi jumlah kasus uji tambahan yang harus dirancang untuk mencapai
pengujian yang benar
b) Memberi tahu mengenai ada atau tidaknya kesalahan
Contoh pengujian Black-Box testing antara lain:
a) Graph Based Testing Method
b) Equivalence Partitioning
c) Boundary Value Analysis
d) Comparison Testing
e) Orthogonal Array Testing

82

8.3. Strategi Pengujian Perangkat Lunak
Proses pengujian perangkat lunak dapat digambarkan sebagai berikut:

Gambar 8.8 Strategi Pengujian Perangkat Lunak
Spiral di atas menggambarkan bagaimana rekayasa sistem membangun sebuah
perangkat lunak dimulai dari penentuan kebutuhan perangkat lunak, kemudian (spiral
bergerak ke dalam) proses dilanjutkan ke dalam bentuk rancangan, dan akhirnya ke
pengkodean (di pusat spiral). Strategi pengujian serupa dengan hal tersebut, namun
bergerak dimulai dari pusat menuju keluar spiral. Dimulai dengan unit testing di pusat
spiral di mana masing-masing modul/unit dari perangkat lunak yang
diimplementasikan dalam source code menjadi sasaran pengujian. Kemudian bergerak
keluar spiral, dilakukan integration testing dengan fokus pengujian adalah desain dan
konstruksi arsitektur perangkat lunak. Bergerak lagi keluar, dilakukan validation testing
dengan sasaran pengujian adalah kesesuaian dengan kebutuhan perangkat lunak yang
telah ditentukan di awal. Terakhir pada lingkaran terluar spiral sampai pada system
testing, di mana perangkat lunak dan keseluruhan elemen sistem diuji.

PENGUJIAN UNIT
Unit testing (uji coba unit) fokusnya pada usaha verifikasi pada unit terkecil dari desain
PL, yakni modul. Uji coba unit selalu berorientasi pada white box testing dan dapat
dikerjakan paralel ayau beruntun dengan modul lainnya.
a. Pertimbangan Pengujian Unit
Interface diuji cobakan untuk menjamin informasi yg masuk atau yg ke luar dari
unit program telah tepat atau sesuai dgn yg diharapkan. Pertama diuji coba adalah
interface karena diperlukan untuk jalannya informasi atau data antar modul. Myers
mengusulkan checklist untuk pengujian interface:

83

Apakahjumlah 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 jumlah parameter?
Apakah atribut dari argumen yang ditransmisikan ke modul yang dipanggil sama
dengan atribut parameter?
Apakah sistem unit dari argumen yang ditransmisikan ke modul yang dipanggil
sama dengan sistem satuan parameter?
Apakah jumlah atribut dari urutan argumen ke fungsi-fungsi built-in sudah
benar?
Adakah referensi ke parameter yang tidak sesuai dengan pain entri yang ada?
Apakah argumen input-only diubah?
Apakah definisi variabel global konsisten dengan modul?
Apakah batasan yang dilalui merupakan argumen?

Bila sebuah modul melakukan I/O ekstemal, maka pengujian interface tambahan
harus dilakukan.
Atribut file sudah benar?
Pemyataan OPEN/CLOSE sudah benar?
Spesifikasi format sudah cocok dengan pernyataan I/O?
Ukuran buffer sudah cocok dengan ukuran 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

84

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.
b. Prosedur Pengujian Unit
Program sumber telah dikembangkan, ditunjang kembali dan diverifikasi untuk
sintaksnya, maka perancangan test case dimulai. Peninjauan kembali perancangan
informasi akan menyediakan petunjuk untuk menentukan test case. Karena modul
bukan program yang berdiri sendiri maka driver (pengendali) dan atau stub PL
harus dikembangkan untuk pengujian unit.
Driver adalah program yg menerima data untuk test case dan menyalurkan ke
modul yg diuji dan mencetak hasilnya.
Stub melayani pemindahan modul yg akan dipanggil untuk diuji.

PENGUJIAN INTEGRASI
Pengujian terintegrasi adalah teknik yg sistematis untuk penyusunan struktur program,
pada saat bersamaan dikerjakan uji coba untuk memeriksa kesalahan yg nantinya
digabungkan dengan interface.
Metode pengujian
top down integration
buttom up integration
a. Top Down Integration
Merupakan pendekatan inkrmental untuk penyusunan struktur program. Modul
dipadukan dgn bergerak ke bawah melalui kontrol hirarki dimulai dari modul

85

utama. Modul subordinat ke modul kontrol utama digabungkan ke dalam struktur
baik menurut depth first atau breadth first.
Proses integrasi:
modul utama digunakan sebagai test driver dan stub yang menggantikan
seluruh modul yg secara langsung berada di bawah modul kontrol utama.
Tergantung pada pendekatan perpaduan yg dipilih (depth / breadth)
Uji coba dilakukan selama masing-masing modul dipadukan
Pada penyelesaian masing-masing uji coba stub yg lain dipindahkan dgn modul
sebenarnya.
Uji coba regression yaitu pengulangan pengujian untuk mencari kesalahan lain
yang mungkin muncul.
b. Bottom Up Integration
Pengujian buttom up dinyatakan dgn penyusunan yang dimulai dan diujicobakan
dengan atomic modul (modul tingkat paling bawah pada struktur program). Karena
modul dipadukan dari bawah ke atas, proses yang diperlukan untuk modul
subordinat yang selalu diberikan harus ada dan diperlukan untuk stub yang akan
dihilangkan.
Strategi pengujian :
Modul tingkat bawah digabungkan ke dalam cluster yang memperlihatkan
subfungsi PL
Driver (program kontrol pengujian) ditulis untuk mengatur input test case dan
output
Cluster diuji
Driver diganti dan cluster yg dikombinasikan dipindahkan ke atas pada struktur
program

86

Gambar 8.9 Bottom Up Integration

UJI COBA VALIDASI
Setelah semua kesalahan diperbaiki maka langkah selanjutnya adalah validasi testing.
Pengujian validasi dikatakan berhasil bila fungsi yg ada pada PL sesuai dgn yg
diharapkan pemakai. Validasi PL merupakan kumpulan seri uji coba black box yg
menunjukkan sesuai dgn yg diperlukan.
Kemungkinan kondisi setelah pengujian:
1. Karakteristik performansi fungsi sesuai dgn spesifikasi dan dapat diterima.
2. Penyimpangan dari spesifikasi ditemukan dan dibuatkan daftar penyimpangan.

Pengujian BETA dan ALPHA
Apabila PL dibuat untuk pelanggan maka dapat dilakukan acceptance test sehingga
memungkinkan pelanggan untuk memvalidasi seluruh keperluan. Test ini dilakukan
karena memungkinkan pelanggan menemukan kesalahan yang lebih rinci dan
membiasakan pelanggan memahami PL yg telah dibuat.
a. Pengujian Alpha
Dilakukan pada sisi pengembang oleh seorang pelanggan. PL digunakan pada
setting yang natural dgn pengembang yg memandang melalui bahu pemakai dan
merekam semua kesalahan dan masalah pemakaian.
b. Pengujian Beta

87

Dilakukan pada satu atau lebih pelanggan oleh pemakai akhir PL dalam lingkungan
yang sebenarnya, pengembang biasanya tidak ada pada pengujian ini. Pelanggan
merekam semua masalah (real atau imajiner) yang ditemui selama pengujian dan
melaporkan pada pengembang pada interval waktu tertentu.

UJI COBA SISTEM
Pada akhirnya PL digabungkan dgn elemen sistem lainnya dan rentetan perpaduan
sistem dan validasi tes dilakukan. Jika uji coba gagal atau di luar skope dari proses daur
siklus pengembangan system, langkah yang diambil selama perancangan dan pengujian
dapat diperbaiki. Keberhasilan perpaduan PL dan system yg besar merupakan kuncinya.
Sistem testing merupakan rentetan pengujian yang berbeda-beda dengan tujuan utama
mengerjakan keseluruhan elemen sistem yang dikembangkan.
a. Recovery Testing
Adalah system testing yg memaksa PL mengalami kegagalan dalam bermacam-
macam cara dan memeriksa apakah perbaikan dilakukan dengan tepat.
b. Security Testing
Adalah pengujian yg akan melalukan verifikasi dari mekanisme perlindungan yg
akan dibuat oleh system, melindungi dari hal-hal yang mungkin terjadi.
c. Strees Testing
Dirancang untuk menghadapi situasi yg tidak normal pada saat program diuji.
Testing ini dilakukan oleh system untuk kondisi seperti volume data yang tidak
normal (melebihi atau kurang dari batasan) atau frekuensi.

88

DAFTAR PUSTAKA

Anonim, (2013). Analisis Terstruktur. http://soft-to-gine.blogspot.com/2011/09/analisis-
terstruktur.html. Diakses 30 Januari 2013.
Darwiyanti, Sri dan Wahono Satrio Romi. Pengantar Unified Modeling language.
http://setia.staff.gunadarma.ac.id /Downloads /files/6039/MateriSuplemenUml.pdf.
Diakses 5 Februari 2013.
Pressman, S, R. (2002). Rekayasa Perangkat Lunak. Andi. Yogyakarta.
Jogiyanto,H.(1990).Analisis dan Design Sistem Informasi: Pendekatan Terstruktur
Teori dan Praktek Aplikasi Bisnis. Yogyakarta : ANDI Publisher.
Nugroho P E, Ratnasar K, Ramadhani N K, dan Putro L B. (2013 ). Rekayasa Perangkat
Lunak http://courseware.politekniktelkom.ac.id/BUKU_MI/Semester%203/IS213%20
Rekayasa%20Perangkat%20Lunak/Rekayasa%20Perangkat%20Lunak.pdf. Diakses 5
Februari 2013.

Verdi Yasin, Rekayasa Perangkat Lunak Berorientasi Objek, Mitra Wacana Media, Jakarta
2012.

Modul-Rpl Free

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Modul-Rpl Free

Diunggah oleh

Hak Cipta:

Format Tersedia

Rekayasa Perangkat Lunak

Anda mungkin juga menyukai