Diktat RPL
Diktat RPL
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
kematian
segera usang
Tingkat
Kegagalan
Waktu
1
Rekayasa Perangkat Lunak
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.
Waktu
Gambar 1.2. Kurva Kegagalan Perangkat Lunak
2
Rekayasa Perangkat Lunak
3
Rekayasa Perangkat Lunak
4
Rekayasa 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).
5
Rekayasa Perangkat Lunak
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.
6
Rekayasa Perangkat Lunak
7
Rekayasa Perangkat Lunak
8
Rekayasa Perangkat Lunak
perangkat bantu
metodologi
proses
Fokus kualitas
9
Rekayasa Perangkat Lunak
Definisi
masalah
Pengembangan
Status Teknis
Quo
Penyatuan
Solusi
10
Rekayasa Perangkat Lunak
Definisi
masalah
Status Pengembangan
Quo Teknis
Penyatuan
Solusi
Definisi
masalah
Status Pengembangan
Status Quo Teknis
Quo
Penyatuan
Solusi
Definisi
masalah
Status Pengembangan
Quo Teknis
Penyatuan
Solusi
11
Rekayasa Perangkat Lunak
Software
Enginering
Analysis
Design
Coding
Testing
Maintenance
12
Rekayasa Perangkat Lunak
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
13
Rekayasa Perangkat Lunak
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.
14
Rekayasa Perangkat Lunak
Tim #3
Pemodelan
Tim #2 bisnis
Pemodelan Pemodelan
bisnis data
Pengujian
& turnover
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
15
Rekayasa Perangkat Lunak
2) Model Formal
3) Teknik Generasi Keempat (4GL)
Model-model itu bisa anda baca di buku “Software Engineering” yang ditulis oleh
Rogers. Pressman, PhD.
16
Rekayasa Perangkat Lunak
17
Rekayasa Perangkat Lunak
BAB II
DASAR ANALISIS KEBUTUHAN
Apa ? Bagaimana ?
18
Rekayasa Perangkat Lunak
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.
Clien Pengem
t bang
Konsultan/Specifi
er
Gambar 2.2 Cara Kerja Sistem Analis
(Perancang
c) Prinsip-Prinsip Analisis : Senior)
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
19
Rekayasa Perangkat Lunak
Input Output
information information
Intermediate
information
Transfrom 2
Transform 1
Data Store
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
20
Rekayasa Perangkat Lunak
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. 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
21
Rekayasa Perangkat Lunak
22
Rekayasa Perangkat Lunak
BAB III
ANALISA TERSTRUKTUR
23
Rekayasa Perangkat Lunak
Notasi :
1
1
Periksa
Pesanan
Periksa
Pesanan
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 :
Pesanan Pesanan
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 :
Pesanan_barang
24
Rekayasa Perangkat Lunak
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.
25
Rekayasa Perangkat Lunak
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.
TI
R
O
T3
SISTEM
T2
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
X
3.1 A
1 X Z
R
AAA
3 A
S
2 3.2 3.3
Y Z
Y
B
26
Rekayasa Perangkat Lunak
Diagram 0 Diagram 3
X
.1 A
1 X Z
R
AAA
3 A
S
2 .2 .3
Y Z
Y
B
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)
27
Rekayasa Perangkat Lunak
28
Rekayasa Perangkat Lunak
29
Rekayasa Perangkat Lunak
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)
30
Rekayasa Perangkat Lunak
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.
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.
31
Rekayasa Perangkat Lunak
d. Aksi
sistem melakukan sesuatu sehingga terjadi perubahan state atau merupakan
suatu reaksi terhadap kondisi.
32
Rekayasa Perangkat Lunak
BAB IV
ANALISA DAN PERANCANGAN BERORIENTASI OBJEK
33
Rekayasa Perangkat Lunak
34
Rekayasa Perangkat Lunak
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.
35
Rekayasa Perangkat Lunak
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’.
Whole Part
a) Sebuah pesawat merupakan assembly dari 0-4 mesin. Dan sebuah mesin
merupakan bagian dari 0-1 pesawat
Pesawat
0-
0-1
4
Mesin
b) Sebuah organisasi merupakan kumpulan dari 0-n staf. Dan seorang staf
merupakan bagian dari tepat 1 organisasi
Organisasi
0-n
1
Staf
36
Rekayasa Perangkat Lunak
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 :
1. Subject 1 1
1 1
37
Rekayasa Perangkat Lunak
38
Rekayasa Perangkat Lunak
BAB V
PEMODELAN DATA
39
Rekayasa Perangkat Lunak
ENTITAS Kardinalitas:
Mengirim PEMASOK
Mengirim
Memasok
PESANAN
PRODUK
Digunakan_
pada
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
40
Rekayasa Perangkat Lunak
41
Rekayasa Perangkat Lunak
BAB VI
DASAR-DASAR PERANCANGAN PIRANTI 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 :
42
Rekayasa Perangkat Lunak
S1 S2
S3
S4 S5
Software “solution”
“Problem” to be solved via software
P
S1 S4 S5 S4
“Problem”
S3 S1 S2 S5
S1 S2 S3 S4 S5 S2 S3
43
Rekayasa Perangkat Lunak
M
Fan-out
a b c
Depth l m
d e k
f g h n o p q
Fan-in
i j r
Width
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 )
44
Rekayasa Perangkat Lunak
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.
A scalar item
…
A scalar item A linked list
…
… A hierarchical tree
An N-dimensional space
45
Rekayasa Perangkat Lunak
Module
A
Module
A
Prosedur di dalam
suatu modul
46
Rekayasa Perangkat Lunak
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)
47
Rekayasa Perangkat Lunak
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.
X Y
Kopling rendah Kohesi tinggi
X Y
48
Rekayasa Perangkat Lunak
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 interface yang
membuat data melalui program. Dan dinyatakan dalam bentuk Bagan Susunan atau
diagram Wamier/Orr.
2 : hubungan
3 : pengulangan
4 : Seleksi / pemilihan
5 : Kopel Kontrol
6 : Kopel Data
Gambar 6.7 Simbol-simbol bagan terstruktur
49
Rekayasa Perangkat Lunak
Contoh :
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.
50
Rekayasa Perangkat Lunak
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.
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
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.
51
Rekayasa Perangkat Lunak
b. Transaction-centered
52
Rekayasa Perangkat Lunak
Contoh :
53
Rekayasa Perangkat Lunak
TABEL KEPUTUSAN
Tabel keputusan (decision table) adalah tabel yang digunakan sebagai alat bantu untuk
menyelesaikan logika dalam program
Condition Stub
Condition Entry
Action Stub
Action Entry
◦ Action entry digunakan untuk memberi tanda tindakan mana yang akan
dilakukan dan mana yang tidak akan dilakukan
54
Rekayasa Perangkat Lunak
DIAGRAM KEPUTUSAN
Merupakan model dari sebuah fungsi diskrit dimana nilai dari sebuah variabel
ditentukan; berdasarkan nilai ini beberapa tindakan dilakukan
55
Rekayasa Perangkat Lunak
BAHASA TERSUSUN
Konteks Logik :
Contoh :
MAKA
BONUS = 100.000
SELAIN ITU
BONUS = 50.000
AKHIR JIKA
56
Rekayasa Perangkat Lunak
DIAGRAM ALIR/FLOWCHART
57
Rekayasa Perangkat Lunak
Contoh :
58
Rekayasa Perangkat Lunak
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.
59
Rekayasa Perangkat Lunak
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 )
60
Rekayasa Perangkat Lunak
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
61
Rekayasa Perangkat Lunak
62
Rekayasa Perangkat Lunak
BAB VII
63
Rekayasa Perangkat Lunak
64
Rekayasa Perangkat Lunak
c) statechart diagram
d) activity diagram
e) sequence diagram
f) collaboration diagram
g) component diagram
h) deployment 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:
65
Rekayasa Perangkat Lunak
66
Rekayasa Perangkat Lunak
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:
67
Rekayasa Perangkat Lunak
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:
68
Rekayasa Perangkat Lunak
69
Rekayasa Perangkat Lunak
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
70
Rekayasa Perangkat Lunak
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.
71
Rekayasa Perangkat Lunak
72
Rekayasa Perangkat Lunak
73
Rekayasa Perangkat Lunak
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.
74
Rekayasa Perangkat Lunak
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
75
Rekayasa Perangkat Lunak
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;
76
Rekayasa Perangkat Lunak
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.
77
Rekayasa Perangkat Lunak
78
Rekayasa Perangkat Lunak
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
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 :
79
Rekayasa Perangkat Lunak
80
Rekayasa Perangkat Lunak
81
Rekayasa Perangkat Lunak
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:
82
Rekayasa Perangkat Lunak
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?
83
Rekayasa Perangkat Lunak
inakurasi ketelitian
representasi simbolis yang tidak benar dari sebuah persamaan.
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
84
Rekayasa Perangkat Lunak
85
Rekayasa Perangkat Lunak
86
Rekayasa Perangkat Lunak
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.
87
Rekayasa Perangkat Lunak
DAFTAR PUSTAKA
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.
Verdi Yasin, Rekayasa Perangkat Lunak Berorientasi Objek, Mitra Wacana Media, Jakarta
2012.
88