R P L - AFLAHUL MUKMIN, ALAM SYAH , SHELA AMANDA, VIVIANTI LISU BUA

PROGRAM STUDI TEKNIK INFORMATIKA

FAKULTAS KOMPUTER
UNCP
 HALAMAN SAMPUL
Buku Saku
REKAYASA
PERANGKAT LUNAK
Dosen Pengampu : Ruhamah, S.Kom., M.Kom.

Oleh :
1904411005 Aflahul Mukmin
1904411041 Alam Syah
1904411011 Shela Amanda
1904411845 Vivianti Lisu Bua

Program Studi Teknik Informatika

Fakultas Komputer
UNCP
2021
 KATA PENGANTAR

Assalamualaikum Wr. Wb.

Dengan memanjatkan puji syukur kehadirat Allah SWT Yang
Maha Pengasih Lagi Maha Penyayang atas karunia dan rahmat-Nya,
sehingga buku saku ini dapat terselesaikan tepat pada waktunya.
Dengan judul “Rekaya Perangkat Lunak“ ini, kami mencoba
menyajikan materi-materi yang berkaitan dengan Rekaya Perangkat
Lunak. Buku saku ini dibuat sebagai tugas akhir semester mata kuliah
rekayasa perangkat lunak pada semester ini.
Rasa terima kasih kami tidak terkirakan kepada yang terhormat
Ibu Ruhamah, S.Kom., M.Kom. selaku dosen pengajar Mata Kuliah
ini atas bantuan dan ilmunya yang telah diberikan, serta tak lupa pula
kami sampaikan kepada semua pihak yang telah mendukung dalam
penyusunan buku saku ini.
Kami menyadari bahwa buku saku ini masih jauh dari sempurna
dengan keterbatasan yang kami miliki. Tegur sapa dari pembaca akan
kami terima dengan tangan yang terbuka demi perbaikan dan
penyempurnaan buku saku selanjutnya. Akhirnya kami berharap
semoga laporan ini bermanfaat. Sekian dan terima kasih.
Wassalamualaikum Wr. Wb.
Palopo, 4 Juli 2021
Penulis

ii
 DAFTAR ISI

HALAMAN SAMPUL ..................................................................... i

KATA PENGANTAR ..................................................................... ii

DAFTAR ISI ................................................................................... iii

BAB I RODUK DAN PROSES PERANGKAT LUNAK ............. 1

A. Perkembangan Perangkat Lunak ........................................... 1

B. Peran Perangkat Lunak .......................................................... 3
C. Perspektif Industri ................................................................. 9
D. Karakteristik dan Komponen Perangkat Lunak .................... 11
E. Tingkatan Teknologi Perangkat Lunak ................................. 16
F. Model-Model Proses Manajemen dan Pengembangan
Perangkat Lunak ................................................................. 22
BAB II PENGENALAN REKAYASA PERANGKAT LUNAK 25

A. Konsep Dasar Rekayasa Perangkat Lunak ............................ 25

B. Tanggung Jawab Profesional Dan Etika Pada Rekayasa
Perangkat Lunak ................................................................. 34
C. Siklus Hidup Rekayasa Perangkat Lunak .............................. 38
BAB III PERENCANAAN PROYEK PERANGKAT LUNAK 41

A. Observasi Dan Estimasi ........................................................ 41

B. Tujuan Perencanaan Proyek Perangkat Lunak ..................... 43
C. Ruang Lingkup Perangkat Lunak .......................................... 43
D. Sumber Daya ....................................................................... 45

iii
 E. Estimasi Proyek Perangkat Lunak ........................................ 48
F. Langkah-langkah Dalam Perencanaan Proyek Perangkat
Lunak : ................................................................................ 51
BAB IV KONSEP DAN PRINSIP ANALISIS ............................ 58

A. Analisis Kebutuhan Perangkat Lunak ................................... 58

B. Teknik Komunikasi ............................................................... 63
C. Prinsip-Prinsip Analisis ......................................................... 65
D. Prototyping Perangkat Lunak .............................................. 68
E. Spesifikasi Dan Kajian Spesifikasi Perangkat Lunak.............. 70
BAB V PEMODELAN DAN MEKANISME ANALISIS ........... 76

A. Elemen Model Analisis ........................................................ 76

B. Pemodelan Data .................................................................. 82
C. Pemodelan Fungsional dan Aliran Informasi ....................... 90
D. Pemodelan Tingkahlaku ...................................................... 93
E. Mekanisme dari Analisis Terstruktur ................................... 95
F. Kamus Data ....................................................................... 101
G. Overview Mengenai Metode Analisis Klasik ...................... 103
BAB VI PRINSIP DAN KONSEP DESAIN .............................. 106

A. Desain Perangkat Lunak dan Rekayasa Perangkat Lunak .. 106

B. Prinsip desain .................................................................... 111
C. Konsep Desain ................................................................... 115
D. Desain Modular Efektif ...................................................... 120
E. Model Desain..................................................................... 123
F. Dokumentasi Desain .......................................................... 124
iv
BAB VII METODE DESAIN ..................................................... 126

A. Desain Data ....................................................................... 126

B. Desain Arsitektur ............................................................... 129
C. Proses Desain Arsitektur .................................................... 130
D. Pasca Pemrosesan Arsitektur ............................................ 131
E. Desain Interface................................................................. 132
F. Desain Interface Manusia-Mesin ....................................... 132
G. Desain Prosedural .............................................................. 134
H. Coding ............................................................................... 135
BAB VIII TEKNIK PENGUJIAN PERANGKAT LUNAK .... 136

A. Dasar-dasar Pengujian Perangkat lunak ............................ 136

B. Desain Test Case ................................................................ 137
C. Pengujian White Box ......................................................... 138
D. Pengujian Basis Path .......................................................... 140
E. Pengujian Struktur Kontrol ................................................ 141
F. Pengujian Black Box ........................................................... 142
BAB IX STRATEGI PENGUJIAN PERANGKAT LUNAK .. 145

A. Pendekatan strategis ke pengujian perangkat lunak ......... 145

B. Pengujian Unit ................................................................... 148
C. Pengujian Integrasi ............................................................ 150
D. Pengujian Validasi .............................................................. 152
E. Pengujian Sistem ............................................................... 153
F. Debugging.......................................................................... 154
BAB X PEMELIHARAAN PERANGKAT LUNAK ............... 158
v
 A. Konsep Pemeliharaan Perangkat Lunak ............................ 158
B. Siklus Hidup Pemeliharaan Sistem (SMLC)...................... 160
C. Teknik Pemeliharaan Perangkat Lunak ............................. 165
D. Aktivitas Selama Pemeliharaan ......................................... 169
BAB XI PRINSIP DAN KONSEP ANALISIS BERBASIS
OBJEK ......................................................................................... 175

A. Paradigma berorientasi Objek ............................................ 175

B. Konsep berorientasi Objek ................................................ 178
C. Identifiksi Elemen Model Objek........................................ 180
D. Analisis berorientasi Objek................................................ 181
E. Proses Perancangan Sistem Berbasis Objek ...................... 187
KESIMPULAN ............................................................................ 194

DAFTAR PUSTAKA .................................................................. 198

vi
 BAB I

PRODUK DAN PROSES PERANGKAT LUNAK

A. Perkembangan Perangkat Lunak

Komputer merupakan mesin yang memproses

fakta atau data menjadi informasi. Komputer di
gunakan orang untuk meningkatkan hasil kerja dan
memecahkan berbagai masalah. Yang menjadi
pemroses data atau pemecah masalah itu adalah
perangkat lunak.
Bentuk terkecil dari perangkat lunak adalah
operasi aritmatik (+, -, :, x) dan logika (AND, OR, >, <,
=). Dari operasi dasar ini di susun program / perangkat
lunak.
Tingkat pemrosesan yang di kerjakan perangkat lunak
pun dari machine-like, mulai berubah seperti human-
like. Di dalam teori informasi, di susun hirarki
informasi, mulai dari data/ fakta, kemudian setelah
proses seleksi dan pengurutan menjadi sesuatu yang
berguna menjadi informasi. Informasi yang di susun
secara sistematis dengan suatu alur logika tertentu
menjadi knowledge. Dan pada akhirnya gabungan
knowledge yang di gabung dari berbagai sisi guna

1
membangun.wisdom. Data yang di proses pun telah
banyak berubah, yang semula hanya berupa data
bilangan dan karakter merambah ke audio visual (bunyi,
suara, gambar, film). Sejauh perkembangan hingga saat
ini, seluruh proses menggunakan format data digital
dengan satuan bit (binary digit).
Dari perkembangan perangkat lunak, kita bisa
membayangkan bagaimana perkembangan interaksi
manusia dengan perangkat lunak. Bentuk paling
primitif dari perangkat lunak, menggunakan aljabar
Boolean, yang di representasikan sebagai binary digit
(bit), yaitu 1 (benar / on) atau 0 (salah / off), cari ini
sudah pasti sangat menyulitkan, sehingga orang mulai
mengelompokkan bit tersebut menjadi nible (4 bit), byte
(8 bit), word (2 byte), double word (32 bit). Kelompok-
kelompok bit ini di susun ke dalam struktur instruksi
seperti penyimpanan, transfer, operasi aritmatika,
operasi logika, dan bentuk bit ini di ubah menjadi kode-
kode yang di kenal sebagai assembler. Kode-kode
mesin sendiri masih cukup menyulitkan karena tuntutan
untuk dapat menghapal kode tersebut dan format
(aturan) penulisannya yang cukup membingungkan,
dari masalah ini kemudian lahir bahasa pemrograman
tingkat tinggi yang seperti bahasa manusia (bahasa

2
 Inggris). Saat ini pembuatan perangkat lunak sudah
menjadi suatu proses produksi yang sangat kompleks,
dengan urutan proses yang panjang dengan melibatkan
puluhan bahkan ratusan orang dalam pembuatannya.

B. Peran Perangkat Lunak

Fungsi atau peran perangkat lunak (software)

adalah memproses data atau instruksi / perintah hingga
mendapat hasil atau menjalankan sebuah perintah
tertentu. Perangkat Lunak juga berfungsi sebagai sarana
interaksi yang menjembatani atau menghubungkan
pengguna komputer (user) dengan perangkat keras
(hardware). Adapun jennies-jenis perangkat lunak dan
perannya sebagai berikut:
1. Perangkat lunak aplikasi (software application).
Perangkat lunak aplikasi (software application)
merupakan suatu subkelas perangkat lunak
komputer yang memanfaatkan kemampuan
komputer langsung untuk melaksanakan sebuah
tugas yang di instruksikan pengguna. Contoh
umum perangkat lunak aplikasi ialah pengolah
kata seperti Microsoft Office dan OpenOffice.org

3
 serta pemutar media seperti Windows Media
Player, Winamp dan GOM Player.
2. Perkakas pengembangan perangkat lunak
(software development tool). Pengertian
Software development tool adalah salah satu
jenis perangkat lunak (software) yang digunakan
untuk membuat, mendebug, maintain (merawat /
memelihara) dan mengembangkan perangkat
lunak lainnya. seperti Kompiler untuk bahasa
pemrograman tingkat tinggi seperti Pascal dan
bahasa pemrograman tingkat rendah yaitu bahasa
rakitan.
3. Sistem operasi (operating system). Sistem
Operasi (Operating System) adalah perangkat
lunak komputer (software) yang bertugas untuk
melakukan kontrol dan manajemen perangkat
keras dan juga operasi-operasi dasar sistem,
termasuk menjalankan perangkat lunak lain
seperti program-program pengolah kata yang
bisa digunakan untuk mempermudah kegiatan
manusia. Sistem operasi adalah jenis yang paling
penting dari perangkat lunak sistem dalam sistem
komputer. Tanpa sistem operasi, pengguna tidak
bisa menjalankan / menggunkan perangkat lunak

4
 lain pada komputer mereka (kecuali program
booting). Contoh sistem operasi modern adalah
Windows, Linux, iOS, Android dan Mac OS X.
4. Pengendali perangkat keras (device driver).
Device driver dapat dikatakan sebagai
penghubung antara perangkat perangkat keras
dan komputer, misalnya menghubugkan
penggunakan barcode scanner pada aplikasi
database nya, contoh aplikasi yang dipake di
swalayan.
5. Perangkat lunak menetap (firmware). Perangkat
lunak menetap (firmware) adalah istilah yang
mengacu kepada perangkat lunak yang disimpan
di dalam Memori Hanya Baca. Tidak seperti
Memori Akses Acak, Memori Hanya Baca tidak
akan dapat berubah meski tidak dialiri listrik.
ROM BIOS merupakan contoh perangkat lunak
menetap yang berada pada motherboard sebuah
komputer. contoh firmware juga seperti yang
dipasang dalam jam tangan digital
6. Perangkat lunak bebas (free 'libre' software / free
software). Perangkat lunak bebas (free software)
mengacu pada software yang bebas untuk
dipakai, dipelajari dan dimodifikasi serta bisa

5
 disalin dengan / tanpa modifikasi, atau dengan
beberapa ketentuan untuk memastikan bahwa
kebebasan serupa juga bisa dinikmati oleh
pengguna selanjutnya. Bebas di sini juga berarti
dalam memakai, menyalin mempelajari,
mengubah, atau menjual sebuah perangkat lunak,
kita tidak perlu mendapatkan izin dari siapa pun.
7. Perangkat lunak sumber terbuka (open source
software). Perangkat lunak sumber terbuka
adalah jenis perangkat lunak yang kode sumber-
nya terbuka untuk dipelajari, dimodifikasi,
ditingkatkan dan disebarluaskan. Karena sifat ini,
biasanya dikembangkan oleh sebuah komunitas
yang bertujuan mengembangkan perangkat lunak
bersangkutan. Produk perangkat lunak yang
dihasilkan ini biasanya bersifat bebas dengan
tetap menganut kaidah dan etika tertentu. Semua
perangkat lunak bebas (free software) ialah
perangkat lunak sumber terbuka, akan tetapi
perangkat lunak sumber terbuka belum tentu
perangkat lunak bebas, tergantung kaidah yang
dipakai dalam melisensikan perangkat lunak
sumber terbuka tersebut.

6
8. Perangkat lunak uji coba (shareware / trialware).
Perangkat lunak uji coba mengacu kepada
perangkat lunak berpemilik yang disediakan
untuk pengguna tanpa membayar secara uji coba
dan sering di batasi oleh koombinasi dari fungsi,
ketersedian, atau kenyamanan. Perangkat lunak
uji coba sering ditawarkan untuk memeberikan
calon pembeli kesempatan untuk mencoba
menggunakan program sebelum membeli lisensi
untuk versi lengkap dari perangkat lunak
tersebut.
9. Perangkat lunak gratis (freeware). Freeware
merupakan perangkat lunak komputer berhak
cipta yang gratis digunakan untuk selamanya,
berbeda dari shareware (perangkat lunak uji
coba) yang mewajibkan penggunanya membayar
(misalnya setelah jangka waktu 1 bulan atau
untuk memperoleh fitur tambahan). Para
pengembang perangkat lunak gratis biasanya
membuat perangkat gratis untuk diberikan
kepada komunitas / kelompok yang
membutuhkan, namun juga tetap ingin
mempertahankan hak mereka sebagai
pengembang dan memiliki kontrol dalam

7
 pengembangan selanjutnya. Kadang jika
pengembang memutuskan untuk berhenti
mengembangkan sebuah produk perangkat
freeware, mereka akan membagikan kode
sumbernya kepada pengembang lain atau
mengedarkan kode sumber tersebut untuk
khalayak umum sebagai perangkat lunak bebas
agar bisa dikembangkan oleh pengembang
selanjutnya.
10. Perangkat lunak perusak (malware). Perangkat
lunak perusak / perangkat berbahaya (malware)
adalah perangkat lunak yang dibuat untuk
merusak atau menyusup ke sistem komputer atau
jejaring komputer tanpa izin dari pemilik sah.
Istilah ini merupakan istilah umum yang biasa
dipakai untuk mengartikan berbagai jenis
perangkat lunak atau kode perangkat lunak yang
mengusik atau mengganggu. Perangkat lunak
dianggap sebagai perangkat lunak berbahaya /
perusak berdasarkan tujuan dari perangkat lunak
itu diciptakan / efek yang timbul dari sebuah
perangkat lunak, bukan berdasarkan ciri-ciri
tertentu. perangkat lunak perusak mencakup
virus komputer, rootkit, kuda Troya (Trojan

8
 horse), perangkat iklan (adware) yang tak jujur,
perangkat pengintai (spyware) dan perangkat
lunak lainnya yang mempunyai niat jahat.
Contoh perangkat lunak perusak yang dapat
mencuri data antaralain adalah Bancos :
perangkat ini bekerja dengan cara menunggu
pengguna untuk membuka sebuah situs
perbankan kemudian perangkat lunak ini
mengalihkan halaman situs bank yang asli ke
yang palsu untuk mencuri informasi rahasia yang
dimasukkan.

C. Perspektif Industri

Perangkat lunak adalah suatu bidang yang masih

baru dan banyak pendekatan dilakukan dalam
mengembangkannya. Salah satu pendekatan adalah
pendekatan rekayasa. Bermula di Amerika Serikat
tahun 60-an dimana pembuatan perangkat lunak selalu
saja mengalami krisis. Sebuah proyek pembuatan
perangkat lunak tak pernah kunjung selesai dan
cenderung menjadi never ending project yang sangat
menguras biaya, waktu dan tenaga. Karena itu,
dilakukan pendekatan rekayasa (engineering). Dengan

9
pendekatan rekayasa kode kode program dibuat dalam
bentuk modul modul yang bisa dipakai berulang ulang
untuk keperluan membangun program yang serupa.
Sebelum rekayasa perangkat lunak ditemukan
pengembangan perangkat lunak dilakukan dengan
pendekatan craftmanship atau meminjam istilah dosen
kami Pak Eko Budiarjo PhD, pengrajin software,
dimana keberhasilannya tidak bisa diperhitungkan dan
sangat tergantung pada peran individual.
1. Proses Manajemen Rekayasa Perangkat Lunak
Rekayasa perangkat lunak semata mata tidak
menjadi jaminan sebuah proyek pengembangan
perangkat lunak bisa berhasil dengan tepat waktu dan
tepat budget. Perlu dilakukan manajemen atas proses
dari pengembangannya yang meliputi lebih banyak
disiplin ilmu manajemen ketimbang ilmu rekayasa
perangkat lunak. Banyak pihak melakukan proses yang
berbeda beda hingga terdapat berbagai macam model
proses. Model yang paling banyak diadopsi oleh
industri perangkat lunak adalah model Capability
Maturity Model (CMM) yang dikeluarkan oleh
Software Engneering Institute (SEI) pada tahun 1986.

2. Capability Maturity Model (CMM)

10
 CMM ini kemudian diakui secara defacto sebagai
standar setelah Departemen Pertahanan Amerika
Serikat mensyaratkan perusahaan perusahaan yang
boleh ikut tender pengembangan perangkat lunak dalam
lingkungan departmennya harus mengantongi
sertifikasi CMM minimal level 2.

3. Level Dalam CMM

Dalam model CMM kematangan sebuah
organisasi dalam mengembangkan perangkat lunak
dibagi dalam tingkatan mulai dari level 1 hingga level 5
paling tinggi. Lima tingkat kematangan itu adalah:
Level 1: Initial
Level 2: Repeatable
Level 3: Defined
Level 4: Manageable
Level 5: Optimazing

D. Karakteristik dan Komponen Perangkat Lunak

1. Karakteristik Perangkat Lunak

Setiap individu menilai perangkat lunak secara
berbeda. Ini karena mereka terlibat dengan perangkat

11
lunak dengan cara yang berbeda. Misalnya,
pengguna ingin perangkat lunak tampil sesuai dengan
kebutuhan mereka. Demikian pula, pengembang
(developer) yang terlibat dalam perancangan,
pengkodean, dan pemeliharaan perangkat lunak
mengevaluasi perangkat lunak dengan melihat
karakteristik internalnya, sebelum mengirimkannya ke
pengguna. Karakteristik perangkat lunak
dikelompokkan menjadi enam komponen utama.
a. Functionality: Mengacu pada tingkat kinerja
perangkat lunak terhadap tujuan yang telah
ditentukan.
b. Reliability: Mengacu pada kemampuan
perangkat lunak untuk menyediakan
fungsionalitas yang diinginkan dalam kondisi
tertentu.
c. Usability: Mengacu pada sejauh mana perangkat
lunak dapat digunakan dengan mudah.
d. Efficiency: Mengacu pada kemampuan
perangkat lunak untuk menggunakan sumber
daya sistem dengan cara yang paling efektif dan
efisien.

12
 e. Maintainability: Mengacu pada kemudahan
modifikasi yang dapat dilakukan dalam sistem
perangkat lunak untuk memperluas fungsinya,
memperbaiki kinerjanya, atau memperbaiki
kesalahannya.
f. Portability: Mengacu pada kemudahan
pengembang perangkat lunak (software
developer) mana yang dapat mentransfer
perangkat lunak dari satu platform ke platform
lainnya, tanpa (atau dengan minimum)
perubahan. Secara sederhana, ini mengacu pada
kemampuan perangkat lunak untuk berfungsi
dengan baik pada berbagai platform perangkat
keras (hardware) dan perangkat lunak (software)
tanpa membuat perubahan apa pun di dalamnya.
g. Robustness, yaitu jika perangkat memiliki data
yang tidak valid, sejauh manakah kemapuan dari
perangkat lunak tersebut.
h. Integrity, yaitu berhubungan dengan kemampuan
dari perangkat lunak dalam hal akses data yang
tidak sah dan juga data yang bisa dicegah.
2. Komponen Perangkat Lunak
Tiga komponen perangkat lunak, antara lain
adalah sebagai berikut :

13
a. Sistem Operasi : Merupakan komponen utama
perangkat lunak system. Sistem Operasi (disebut
juga platform software) terdiri dari program
utama dan program low-level yang mengatur
operasi dasar komputer. Memungkinkan
perangkat lunak aplikasi untuk berinteraksi
dengan komputer dan Membantu komputer untuk
mengelola sumber daya baik itu internal maupun
eksternal. Secara khusus, sistem operasi
menangani control dan penggunaan sumber daya
perangkat keras, termasuk ruang disk, memori,
alokasi CPU time, dan perangkat peripheral.
b. Device Driver : Membantu komputer mengontrol
perangkat peripheral. Driver artinya adalah
pemacu yang maksudnya adalah dengan
dipasangnya suatu device ke komputer sementara
operating sistem kita atau komputer tidak
mengenalinya maka driver tadi yang akan
memperkenalkan bahwa device yang dipasang
itu adalah benar adanya dan bisa digunakan
karena Device Driver adalah program komputer
yang mengawal jenis-jenis peranti yang
dipasangkan (install) pada komputer. Program ini
adalah spesifik untuk peranti yang tertentu saja

14
 dan tidak boleh digunakan pada peranti yang lain
, contoh: mesin pencetak(printer) memerlukan
driver untuk berfungsi
c. Program Utilitas. Adalah sebuah program yang
digunakan untuk Meningkatkan kapabilitas
program komputer yang telah ada pada computer
Perangkat lunak utilitas merupakan perangkat
lunak komputer yang didisain untuk membantu
proses analisis, konfigurasi, optimasi, dan
membantu pengelolaan sebuah komputer ataupun
sistem. Perangkat lunak utilitas harus dibedakan
dengan perangkat lunak aplikasi yang
memungkinkan pengguna melakukan berbagai
hal dengan komputer seperti mengetik,
melakukan permainan, merancang gambar, dan
lain-lain. Perangkat lunak utilitas lebih
memfokuskan penggunaannya pada
pengoptimasian fungsi dari infrastruktur yang
terdapat dalam sebuah komputer. Karena
fungsinya, perangkat lunak utilitas umumnya
tidak ditujukan untuk pengguna secara umum,
melainkan ditujukan untuk pengguna yang
memiliki pemahaman atas cara kerja sistem
komputer yang cukup baik. Kebanyakan

15
 perangkat keras utilitas ini dibuat secara khsus
untuk melakukan fungsi tertentu pada suatu area
komputasi secara spesifik, seperti memformat
harddisk, atau melakukan pengecekan
konektifitas jaringan. Namun dalam
perkembangannya sejumlah perangkat lunak
utilitas terkadang pula dipaketkan dalam satu
paket utilitas yang ditujukan untuk beragam
kebutuhan.

E. Tingkatan Teknologi Perangkat Lunak

Perangkat lunak (Software) merupakan program-

program komputer yang berguna untuk menjalankan
suatu pekerjaan sesuai dengan yang dikehendaki.
Program tersebut ditulis dengan bahasa khusus yang
dimengerti oleh komputer. Ada dua jenis perangkat
lunak, yaitu : perangkat lunak sistem (system software)
dan perangkat lunak aplikasi (application software).
1. Perangkat Lunak Sistem
Perangkat lunak sistem melaksanakan tugas-
tugas dasar tertentu yang diperlukan semua pengguna
untuk komputer. Perangkat lunak sistem biasanya

16
disiapkan oleh pembuat perangkat keras (penjual atau
pemasok perangkat keras sering disebut sebagai
vendor) atau perusahaan yang mengkhususkan diri
dalam membuat perangkat lunak (penjual atau pemasok
perangkat lunak). Ada tiga jenis dasar perangkat lunak
sistem, yaitu: sistem operasi (operating system), bahasa
pemograman dan program utilitas.
a. Sistem Operasi
Sistem operasi (operating System) adalah
software yang berfungsi untuk mengaktifkan seluruh
perangkat yang terpasang pada komputer sehingga
masing-masingnya dapat saling berkomunikasi. Tanpa
ada sistem operasi maka komputer tak dapat
difungsikan sama sekali.Contoh sistem operasi adalah:
DOS, Unix, Linux, OS/2,Windows, Mac OS dan lain-
lain. Pengertian sistem operasi secara umum adalah
mengelola seluruh sumber-daya yang terdapat pada
sistem komputer dan menyediakan sekumpulan layanan
(system calls ke pengguna sehingga memudahkan dan
kenyamanan penggunaan serta pemanfaatan sumber
daya sistem komputer.
Fungsi dasar sistem komputer pada dasarnya
terdiri dari empat komponen utama,yaitu perangkat-
keras, program aplikasi, sistem operasi, dan para

17
pengguna. Sistem operasi berfungsi untuk mengatur dan
mengawasi penggunaan perangkat keras oleh berbagai
program aplikasi serta para pengguna. Sistem operasi
berfungsi ibarat pemerintah dalam suatu negara, dalam
arti membuat kondisi komputer agar dapat menjalankan
program secara benar. Untuk menghindari konflik yang
terjadi pada saat pengguna menggunakan sumber daya
yang sama, sistem operasi mengatur pengguna mana
yang dapat mengakses suatu sumber-daya. Sistem
operasi juga sering disebut resource allocator. Satu lagi
fungsi penting dari sistem operasi adalah sebagai
program pengendali yang bertujuan untuk menghindari
kesalahan (error) dan penggunaan komputer yang tidak
perlu.
Komponen-komponen sistem pada kenyataannya
tidak semua sistem operasi mempunyai struktur yang
sama. Namun menurut Avi Silberschatz, Peter Galvin,
dan Greg Gagne, umumnya sebuah sistem operasi
modern mempunyai komponen sebagai berikut :
1) Managemen Proses.
2) Managemen Memori Utama.
3) Managemen Secondary-Storage.
4) Managemen Sistem I/O.

18
 5) Managemen Berkas.
6) Sistem Proteksi.
7) Jaringan
Manajemen Proses adalah keadaan ketika sebuah
program sedang di eksekusi. Sebuah proses
membutuhkan beberapa sumber daya untuk
menyelesaikan tugasnya. Sumber daya tersebut dapat
berupa CPUtime, memori, berkas-berkas, dan
perangkat-perangkat I/O.Sistem operasi bertanggung
jawab atas aktifitas-aktifitas yang berkaitan dengan
manajemen proses seperti :
1) Pembuatan atau penghapusan proses yang
dibuat oleh pengguna dan sistem proses.
2) Menunda atau melanjutkan proses.
3) Menyediakan mekanisme untuk proses
sinkronisasi.
4) Menyediakan mekanisme untuk proses
komunikasi.
5) Menyediakan mekanisme untuk penanganan
deadlock.
Manajemen Memori Utama atau lebih dikenal
sebagai memori adalah sebuah array yang besar dari
word atau byte, yang ukurannya mencapai

19
 ratusan,ribuan, atau bahkan jutaan. Setiap word atau
byte mempunyai alamat tersendiri. Memori utama
berfungsi sebagai tempat penyimpanan yang akses
datanya digunakan oleh CPU atau perangkat I/O.

b. Bahasa pemograman
Perangkat lunak bahasa yaitu program yang
digunakan untuk menerjemahkan intruksi-intruksi yang
ditulis dalam bahasa pemrograman ke bahasa mesin
dengan aturan atau prosedur tertentu, agar diterima oleh
komputer. Ada tiga level bahasa pemrograman, yaitu:
1) Bahasa tingkat rendah (low level language).
Bahasa ini disebut juga bahasa mesin
(assembler), dimana pengkodean bahasanya
menggunakan kode angka 0 dan 1.
2) Bahasa tingkat tinggi (high level
language).Bahasa ini termasuk dalam bahasa
pemrograman yang mudah dipelajari oleh
pengguna komputer karena menggunakan
bahasa inggris. Contohnya: Basic, cobol,
pascal, fortran.
3) Bahasa generasi keempat (fourt generation
language).Bahasa generasi keempat merupakan
bahasa yang berorientasi pada objek yang

20
 disebut Object Oriented Programming (OOP).
Contohnya: Visual basic, delphi, dan visual
C++.

c. Program Bantu (utility).

Program utilitas berfungsi membantu atau
mengisi kekurangan atau kelemahan sistem operasi,
misalnya PC Tools dapat melakukan perintah format
sebagaimana DOS, tetapi PC Tools mampu
memberikan keterangan dan animasi yang bagus dalam
proses pemformatan. Terdapat beberapa jenis program
utilitas, yakni:
1) Program Antivirus.
Mengindentifikasi dan menghapus virus-virus
dalam memori, media storage, dan file yang akan
dimasukkan.
2) Spyware.
Program yang diletakkan dalam sebuah komputer
tanpa pengetahuan user, secara rahasia
mengumpulkan informasi tentang user.
3) Pengompres File.
Kompres file maksudnya untuk memperkecil
ukuran untuk membebaskan ruang dan

21
 meningkatkan kinerja. Contoh aplikasinya:
Winzip, winrar, dsb.

4) Software CD/DVD Burning.

Membaca text, grafik, audio dan file audio untuk
dapat direkam ulang atau dibaca ulang oleh CD
atau DVD. Contoh aplikasi: Nero.
5) Perangkat Lunak Aplikasi
Program aplikasi adalah perangkat lunak yang
dirancang khusus untuk kebutuhan tertentu,
misalnya program pengolah kata, mengelola
lembar kerja, program presentasi, design grafis,
dan lain-lain. Contohnya: Ms. Office.

F. Model-Model Proses Manajemen dan

Pengembangan Perangkat Lunak

1. Model proses perangkat lunak merupakan representasi

abstrak dari proses perangkat lunak.
2. Setiap model proses merepresentasikan suatu proses
dari sudut pandang tertentu sehingga hanya
memberikan informasi parsial mengenai proses
tersebut.

22
3. Model-model ini biasanya merupakan abstraksi yang
dapat digunakan untuk menjelaskan pendekatan-
pendekatan terhadap pengembangan perangkat lunak.
Model proses perangkat lunak diantaranya adalah:
1. Pendekatan Model Air terjun (Water fall),
Menempatkan semua aktifitas sesuai dengan
tahapan pada model Waterfall dengan memisahkan
dan membedakan antara spesifikasi dan
pengembangan
2. Pengembangan yang berevolusi, Pendekatan yang
melanjutkan Aktifitas satu dan yang lainnya dari
Spesifikasi dan pengembangan serta validasi
secara cepat
3. Pengembangan sistem Formal, Pendekatan
aktifitas bersasar suatu model sistem matematika
yang ditransformasikan ke implementasi,
4. Pengembangan Sstem berbasis Re-use
(penggunaan ulang) komponen, sistem dibangun
dari komponen yang sudah ada dengan fokus
integrasi sistem.

23
24
 BAB II

PENGENALAN REKAYASA PERANGKAT LUNAK

A. Konsep Dasar Rekayasa Perangkat Lunak

1. Arti dan Definisi Perangkat Lunak

Istilah Reakayasa Perangkat Lunak (RPL) secara

umum disepakati sebagai terjemahan dari istilah
Software engineering. Istilah Software Engineering
mulai dipopulerkan pada tahun 1968 pada software
engineering Conference yang diselenggarakan oleh
NATO. Sebagian orang mengartikan RPL hanya
sebatas pada bagaimana membuat program komputer.
Padahal ada perbedaan yang mendasar antara perangkat
lunak (software) dan program komputer.Perangkat
lunak adalah seluruh perintah yang digunakan untuk
memproses informasi. Perangkat lunak dapat berupa
program atau prosedur. Program adalah kumpulan
perintah yang dimengerti oleh komputer sedangkan
prosedur adalah perintah yang dibutuhkan oleh
pengguna dalam memproses informasi (O’Brien, 1999).
Pengertian RPL sendiri adalah suatu disiplin ilmu
yang membahas semua aspek produksi perangkat lunak,
mulai dari tahap awal yaitu analisa kebutuhan

25
 pengguna, menentukan spesifikasi dari kebutuhan
pengguna, disain, pengkodean, pengujian sampai
pemeliharaan sistem setelah digunakan. Dari pengertian
ini jelaslah bahwa RPL tidak hanya berhubungan
dengan cara pembuatan program komputer. Pernyataan
”semua aspek produksi” pada pengertian di atas,
mempunyai arti semnua hal yang berhubungan dengan
proses produksi seperti manajemen proyek, penentuan
personil, anggaran biaya, metode, jadwal, kualitas
sampai dengan pelatihan pengguna merupakan bagian
dari RPL.
Perangkat Lunak Merupakan program komputer
dan dokumentasi yang berkaitan. Produk perangkat
lunak dibuat untuk pelanggan tertentu ataupun untuk
pasar umum terdiri dari:
1) Generik – dibuat untuk dijual ke suatu kumpulan
pengguna yang berbeda.
2) Bespoke (custom)
– dibuat untuk suatu pengguna tunggal
sesuai dengan spesifikasinya.

a. Secara Etimologi
Rekayasa Perangkat Lunak berasal dari duakata
“Rekayasa/ Engineering” dan “Perangkat Lunak n

26
 Software”.Perangkat Lunak (Software) adalah source
code pada suatu program atau sistem. Perangkat lunak
tidak hanya dokumentasi terhadap source code tapi juga
dokumentasi terhadap sesuatu yang dibutuhkan selama
pengembangan, instalasi, penggunaan dan
pemeliharaan sebuah sistem. Engineering atau
Rekayasa adalah aplikasi terhadap pendekatan
sistematis yang berdasar atas ilmu pengetahuan dan
matematis serta aplikasi tentang produksi terhadap
struktur,mesin, produk, proses atau sistem.

b. Secara Terminologi
Definisi Klasik (1969) Penerapan prinsip
engineering untuk memperoleh software yang
ekonomis, reliable (dapat dipercaya, dapat diandalkan)
dan bekerja efisien pada computer.

Definisi IEEE (1993) RPL :

1) Penerapan secara sistematis, disiplin, pendekatan

terukur pada pengembangan, pengoperasian dan
pemeliharaan software.
2) RPL adalah suatu disiplin rekayasa yang
berkonsentrasi terhadap seluruh aspek.

27
 Sesuai dengan definisi yang telah disampaikan
sebelumnya, maka ruang lingkup RPL dapat
digambarkan sebagai berikut :
1) Software Requirements berhubungan dengan
spesifikasi kebutuhan dan persyaratan perangkat
lunak.
2) Software desain mencakup proses penampilan
arsitektur, komponen, antar muka, dan
karakteristik lain dari perangkat lunak.
3) Software construction berhubungan dengan detail
pengembangan perangkat lunak, termasuk
algoritma, pengkodean, pengujian dan pencarian
kesalahan.
4) Software testing meliputi pengujian pada
keseluruhan perilaku perangkat lunak.
5) Software maintenance mencakup upaya-upaya
perawatan ketika perangkat lunak telah
dioperasikan.
6) Software configuration management berhubungan
dengan usaha perubahan konfigurasi perangkat
lunak untuk memenuhi kebutuhan tertentu.
7) Software engineering management berkaitan
dengan pengelolaan dan pengukuran RPL,
termasuk perencanaan proyek perangkat lunak.

28
 8) Software engineering tools and methods mencakup
kajian teoritis tentang alat bantu dan metode RPL.
9) Software engineering process berhubungan dengan
definisi, implementasi pengukuran, pengelolaan,
perubahan dan perbaikan proses RPL.
10) Software quality menitik beratkan pada
kualitas dan daur hidup perangkat lunak

2. Jenis-jenis Perangkat Lunak

Jenis-jenis Perangkat lunak secara umum dapat
dikelompokkan sebagai berikut :

a. Perangkat Lunak Sistem, Sekumpulan program

yang ditulisuntuk melayani programprogram yang
lain. Seperti kompiler, editor dan utilitas pengatur
file.
b. Perangkat Lunak Real-Time, Program-program
yang memonitor/menganalisi/mengontrol kejadian
dunia nyata pada saat terjadinya ( real time event).
c. Perangkat Lunak Bisnis, memroses informasi
bisnis spt payroll, inventory dll.
d. Perangkat Lunak Teknik dan Ilmu Pengetahuan,
ditandai dengan penggunaan algoritma number
crunching.

29
 e. Embedded Software, produk yang ada dalam read
only memory dan dipakai untuk mengontrol hasil
dan sistem untuk keperluan konsumen dan pasar
industri.
f. Perangkat Lunak Komputer Personal, sesuai
kebutuhan personal spt pengolah kata,angka dan
manajamen database.
g. Perangkat Lunak Kecerdasan Buatan,
menggunakan algoritma non-numeris untuk
memecahkan masalah kompleks yang tidak sesuai
untuk perhitungan atau analisis secara langsung.

3. Pentingnya Perangkat Lunak

Perangkat lunak dipandang sangat perlu karena ia
memengaruhi hampir setiap aspek di dalam kehidupan
kita dan telah menyatu dalam budaya, bisnis dan
kegiatan kita sehari-hari.Rekayasa perangkat lunak juga
dipandang sangat perlu karena ia pada dasarnya
memungkinkan kita membangun sistem/perangkat
lunak yang kompleks dalam jangka waktu tertentu dan
pada dasarnya harus memiliki kualitas tinggi.
Tujuannya dari adanya rekayasa perangkat lunak adalah
:

30
a. Agar seseorang dapat mengembangkan
perangkat lunak yang bermanfaat bagi user.
Tujuan dan juga fungsi yang pertama adalah
agar seseorang yang mempelajari rekayasa
perangkat lunak ini mampu mengembangkan sebuah
perangkat lunak yang berguna dan juga bermanfaat
bagi usernya. Sebuah perangkat lunak tentu saja
tidak akan digunakan oleh user apabila tidak
memiliki fungsi yang spesifik. Karena itu dengan
mempelajari rekayasa perangkat lunak, akan
membuat seseorang menjadi lebih paham mengenai
pengembangan perangkat lunak yang fungsional.
Contohnya, perangkat lunak jaringan komputer yang
digunakan dalam mengkoneksikan komputer pada
internet.

b. Agar seseorang mampu mengembangkan

perangkat lunak yang sudah ada menjadi lebih
baik lagi.
Perangkat lunak yang sudah ada terkadang
membutuhkan pembaruan, karena fungsinya yang
mungkin sudah berkurang. Karena itu, dengan
mempelajari rekayasa perangkat lunak seseorang
akan mampu mengembangkan perangkat lunak yang

31
sudah ada sebelumnya agar kemudian menjadi
sebuah sistem perangkat lunak yang dapat berguna
dan menjadi lebih baik lagi di kalangan user.

c. Menciptakan sebuah perangkat lunak yang

ramah dan user friendly.
Sistem perangkat lunak yang user friendly
adalah sebuah sistem yang didambakan oleh setiap
user. Paling tidak, sebauh sistem perangkat lunak
yang user friendly membutuhkan tampilan atau
interface yang menarik, fungsionalitas, hingga
kemudahan dalam penggunaannya. Mereka yang
mempelajari sistem rekayasa perangkat lunak ini
tentu saja paham betul dengan hal ini, sehingga dapat
membantu mereka mengembangkan sebuah sistem
perangkat lunak yang user friendly, dan pastinya
mudah untuk digunakan oleh banyak kalangan user.

d. Agar sebuah sistem perangkat lunak bisa

diintegrasikan dengan peralatan mekanikal
yang ada, sehingga menjadi lebih bermanfaat.
Beberapa peralatan mekanikal, seperti robotik
membutuhkan integrasi dengan perangkat lunak
agar bisa bekerja dengan baik dan juga optimal.
Mereka yang mempelajari mengenai rekayasa

32
perangkat lunak tentu saja sudah sangat paham
dengan hal ini. Dengan kemampuan yang dipelajari
dalam rekayasa perangkat lunak, maka sebuah
sistem perangkat lunak dapat diintegrasikan ke
dalam sebuah peralatan mekanikal, sehingga dapat
mendukung kegiatan operasional dari peralatan
tersebut.

e. Agar seseorang mampu untuk melakukan

perawatan dari perangkat lunak yang sudah ada.
Fungsi dari mereka yang mempelajari
rekayasa perangkat lunak tidak hanya terpaku pada
pembuatan dan juga pengembangan dari sistem
perangkat lunak yang ada, namun juga berada pada
level maintenance atau perawatan dari sebuah
perangkat lunak yang ada. Setiap perangkat lunak
tentu saja membutuhkan maintenance, terutam
aketika perangkat lunak tersebut mengalami suatu
gangguan atau kendala. Karena itu, pembelajaran
mengenai rekayasa perangkat lunak sangatlah
dibutuhkan, untuk kepentingan perawatan dan juga
maintenance dari perangkat lunak tersebut.

33
B. Tanggung Jawab Profesional Dan Etika Pada
Rekayasa Perangkat Lunak

Pada implementasinya terdapat banyak peluang

bahwa rekayasa perangkat lunak dapat digunakan untuk
penyalahgunaan fungsi khususnya dalam dunia
kejahatan. Untuk memastikan bahwa rekayasa
perangkat lunak digunakan dengan baik untuk
kemaslahatan umat manusia maka ada upaya agar para
software engineer harus berkomitmen untuk
menjadikan profesi ini menguntungkan dan dihormati
sehingga diperlukan harus mematuhi standar Kode Etik
dan Profesional. Software engineer berkomitmen untuk
membuat analisis, spesifikasi, desain, pengembangan,
pengujian dan pemeliharaan perangkat lunak yang
menguntungkan dan dihargai sebagai sebuah profesi.
Secara umum software engineer harus mematuhi
8(delapan) prinsip berikut:
1. PUBLIC Software engineers shall act consistently
with the public interest. Pernyataan ini berarti
seorang software engineer harus bertindak secara
konsisten dengan kepentingan publik.
2. CLIENT AND EMPLOYER Software engineers
shall act in a manner that is in the best interests of
their client and employer consistent with the public

34
 interest. Seorang software engineer harus
bertindak sesuai dengan kepentingan terbaik klien
dan atasan yang konsisten dengan kepentingan
publik.
3. PRODUCT Software engineers shall ensure that
their products and related modifications meet the
highest professional standards possible. Seorang
Software engineer harus memastikan bahwa
produk dan modifikasi yang terkait dengan
memenuhi standar profesional setinggi mungkin.
4. JUDGMENT Software engineers shall maintain
integrity and independence in their professional
judgment. Seorang Software engineer harus
mempertahankan integritas dan 39 kemandirian
dalam penilaian profesional yang dimiliki.
5. MANAGEMENT Software engineering managers
and leaders shall subscribe to and promote an
ethical approach to the management of software
development and maintenance. Seorang pimpinan
dan manajer Software engineering melakukan
pendekatan etis kepada manajemen pengembangan
perangkat lunak dan pemeliharaan.
6. PROFESSION Software engineers shall advance
the integrity and reputation of the profession

35
 consistent with the public interest. Seorang
Software engineer harus memajukan integritas dan
reputasi profesi yang konsisten dengan
kepentingan public.
7. COLLEAGUES Software engineers shall be fair to
and supportive of their colleagues. seorang
Software engineer harus bersikap adil dan
mendukung rekan-rekan taua kolega dalam
pekerjaan.
8. SELF Software engineers shall participate in
lifelong learning regarding the practice of their
profession and shall promote an ethical approach
to the practice of the profession. Seorang Software
engineer harus berpartisipasi dalam pembelajaran
seumur hidup tentang praktek profesi yang dimiliki
dan akan mempromosikan pendekatan etis untuk
profesinya.
Cakupan ruang lingkup yang cukup luas,
membuat RPL sangat terkait dengan disiplin dengan
bidang ilmu lain. tidak saja sub bidang dalam disiplin
ilmu komputer namun dengan beberapa disiplin ilmu
lain diluar ilmu komputer.
1. Bidang ilmu manajemen meliputi akuntansi,
finansial, pemasaran, manajemen operasi,

36
 ekonomi, analisis kuantitatif, manajemen sumber
daya manusia, kebijakan, dan strategi bisnis-
bidang ilmu matematika meliputi aljabar linier,
kalkulus, peluang, statistik, analisis numerik, dan
matematika diskrit.
2. Bidang ilmu manajemen proyek meliputi semua
hal yang berkaitan dengan proyek, seperti ruang
lingkup proyek, anggaran, tenaga kerja, kualitas,
manajemen resiko dan keandalan, perbaikan
kualitas, dan metode-metode kuantitatif.
3. Bidang ilmu ergonomika menyangkut hubungan (
interaksi) antar manusia dengan komponen-
komponen lain dalam sistem komputer- bidang
ilmu rekayasa sistem meliputi teori sistem, analisis
biaya-keuntungan, pemodelan, simulasi, proses,
dan operasi bisnis.

37
C. Siklus Hidup Rekayasa Perangkat Lunak

1. Era Pioner

Bentuk perangkat lunak pada awalnya adalah

sambungan-sambungan kabel ke antar bagian dalam
komputer, gambar berikut memperlihatkan orang yang
sedang menggunakan komputer. Cara lain dalam
mengakses komputer adalah menggunakan punched
card yaitu kartu yang di lubangi. Penggunaan komputer
saat itu masih dilakukan secara langsung, sebuah
program untuk sebuah mesin untuk tujuan tertentu.
Pada era ini, perangkat lunak merupakan satu kesatuan
dengan perangkat kerasnya. Penggunaan komputer
dilakukan secara langsung dan hasil yang selesai di
kerjakan komputer berupa print out. Proses yang di
lakukan di dalam komputer berupa baris instruksi yang
secara berurutan di proses.

2. Era Stabil

Pada era stabil penggunaan komputer sudah

banyak di gunakan, tidak hanya oleh kalangan peneliti
dan akademi saja, tetapi juga oleh kalangan industri /
perusahaan. Perusahaan perangkat lunak bermunculan,

38
 dan sebuah perangkat lunak dapat menjalankan
beberapa fungsi, dari ini perangkat lunak mulai bergeser
menjadi sebuah produk. Baris-baris perintah perangkat
lunak yang di jalankan oleh komputer bukan lagi satu-
satu, tapi sudah seperti banyak proses yang di lakukan
secara serempak (multi tasking). Sebuah perangkat
lunak mampu menyelesaikan banyak pengguna (multi
user) secara cepat/langsung (real time). Pada era ini
mulai di kenal sistem basis data, yang memisahkan
antara program (pemroses) dengan data (yang di
proses).

3. Era Mikro

Sejalan dengan semakin luasnya PC dan jaringan

komputer di era ini, perangkat lunak juga berkembang
untuk memenuhi kebutuhan perorangan. Perangkat
lunak dapat di bedakan menjadi perangkat lunak sistem
yang bertugas menangani internal dan perangkat lunak
aplikasi yang di gunakan secara langsung oleh
penggunannya untuk keperluan tertentu. Automatisasi
yang ada di dalam perangkat lunak mengarah ke suatu
jenis kecerdasan buatan.

4. Era Modern
39
 Saat ini perangkat lunak sudah terdapat di mana-
mana, tidak hanya pada sebuah superkomputer dengan
25 prosesornya, sebuah komputer genggampun telah di
lengkapi dengan perangkat lunak yang dapat di
sinkronkan dengan PC. Tidak hanya komputer, bahkan
peralatan seperti telepon, TV, hingga ke mesin cuci, AC
dan microwave, telah di tanamkan perangkat lunak
untuk mengatur operasi peralatan itu. Dan yang
hebatnya lagi adalah setiap peralatan itu akan mengarah
pada suatu saat kelak akan dapat saling terhubung.
Pembuatan sebuah perangkat lunak bukan lagi
pekerjaan segelentir orang, tetapi telah menjadi
pekerjaan banyak orang, dengan beberapa tahapan
proses yang melibatkan berbagai disiplin ilmu dalam
perancangannya. Tingkat kecerdasan yang di tunjukkan
oleh perangkat lunak pun semakin meningkat, selain
permasalahan teknis, perangkat lunak sekarang mulai
bisa mengenal suara dan gambar.

40
 BAB III

PERENCANAAN PROYEK PERANGKAT LUNAK

A. Observasi Dan Estimasi

Perencanaan Proyek (Project Planning)

merupakan awal dari serangkaian aktivitas secara
kolektif dari sebuah proses Manajemen Proyek
Perangkat Lunak. Proses manajemen proyek perangkat
lunak dimulai dengan kegiatan project planning
(perencanaan proyek). Yang pertama dari aktifitas ini
adalah estimation (perkiraan). Estimasi menjadi dasar
bagi semua aktivitas perencanaan proyek yang lain dan
perencanaan proyek memberikan sebuah peta jalan bagi
suksesnya rekayasa perangkat lunak, maka tanpa
estimasi kita tidak dapat berjalan dengan baik Tahap
perencanaan Perangkat Lunak bertujuan untuk
menyediakan sebuah kerangka kerja sehingga manajer
dapat membuat estimasi mengenai sumber daya, biaya,
dan jadwal.
Aktivitas-aktivitas yang dilakukan pada tahap
perencanaan Perangkat Lunak:
1. Menentukan ruang lingkup Perangkat Lunak yang
meliputi fungsi, kinerja, batasan

41
2. Interface, dan reliabilitas. Mengestimasi sumber
daya yang diperlukan.
3. Menentukan ukuran dari proyek Perangkat Lunak.
4. Studi kelayakan: teknis, ekonomis, legal,
operasional dan schedule
Kebutuhan-Kebutuhan Perangkat Lunak:
1. Kebutuhan fungsional: menyajikan suatu
pelayanan, operasi dan transformasi data dsb
kepada user.
2. Kebutuhan non-fungsional: menentukan batasan-
batasan dimana PL harus dioperasikan.
3. Antar-muka pemakai.
4. Antar-muka eksternal/ sistem dengan sistem
lain.
5. Perangkat keras (hardware).
6. Database. - Penanganan kesalahan (error
handling).
7. Implementasi rancangan, petunjuk dan panduan
pengujian.

42
B. Tujuan Perencanaan Proyek Perangkat Lunak

Tujuan perencanaan proyek perangkat lunak

adalah untuk menyediakan sebuah kerangka kerja yang
memungkinkan manajer membuat estimasi yang dapat
dipertanggungjawabkan mengenai sumber daya, biaya
dan jadwal. Tujuan perencanaan dicapai melalui suatu
proses penemuan informasi yang menunjuk ke estimasi
yang dapat dipertanggungjawabkan.

C. Ruang Lingkup Perangkat Lunak

Penentuan ruang lingkup perangkat lunak

merupakan aktivitas pertama dalam perencanaan
proyek perangkat lunak. Ruang lingkup perangkat lunak
menggabarkan fungsi, kinerja, batasan, interface dan
reliabilitas. Fungsi yang digambarkan dalam statmen
ruang lingkup dievaluasi dan disaring untuk
memberikan awalan yang lebih detail pada saat estimasi
dimulai. Pertimbangan kinerja melingkupi pemrosesan
dan kebutuhan waktu respon. Batasan ini
mengidentifikasi dari batas yang ditempatkan pada
perangkat lunak oleh perangkat keras eksternal,
memori, atau sistem informasi yang ada.

43
 Teknik yang banyak dipakai secara umum untuk
menjembatani jurang komunikasi antara pelanggan dan
pengembang serta untuk memulai proses komunikasi
adalah dengan melakukan pertemuan atau wawancara
pendahuluan. Gause & weinberg mengusulkan bahwa
analis harus memulai dengan mengajukan pertanyaan-
pertanyaan bebas konteks, yaitu serangkaian pertanyaan
yang akan membawa pada pemahaman mendasar
terhadap masalah, orang yang menginginkan suatu
solusi, sifat solusi yang diharapkan, dan efektivitas
pertemuan itu.
Bagian Question dan Answer hanya akan
digunakan untuk pertemuan pertama yang kemudian
diganti dengan format pertemuan yang
mengkombinasikan elemen-elemen penyelesaian
masalah, negoisasi, dan spesifikasi. Sejumlah peneliti
lepas mengembangkan pedekatan yang berorientasi
pada tim terhadap pengumpulan kebutuhan yang dapat
deiterapkan untuk membangun ruang lingkup sebuah
proyek, yang disebut teknik spesifikasi aplikasi yang
teraplikasi (FAST).

44
D. Sumber Daya

Mengestimasi sumber daya yang dibutuhkan

untuk menyelesaikan usaha pengembangan perangkat
lunak yang meliputi manusia, komponen perangkat
lunak, dan peranti perangkat keras/perangkat lunak.
Piramida di atas memperlihatkan sumber daya
pengembangan sebagai sebuah piramid. Peranti
perangkat keras dan perangkat lunak berada pada
fondasi dari piramida di atas dan menyediakan
infrastruktur untuk mendukung usaha
pengembangan(lingkungan pengembang).
Dalam tingkat yang lebih tinggi terdapat
komponen perangkat lunak reuseable – blok bangungan
perangkat lunak yang dapat mengurangi biaya
pengembangan secara dramatis dan mempercepat
penyampaian. Dan di puncak terdapat sumber daya
utama yaitu manusia. Masing-masing sumber daya
ditentukan dengan empat karakteristik :
1) Deskripsi sumber daya
2) Statemen ketersediaan
3) Waktu kronologis sumber daya diperlukan
4) Durasi waktu sumber daya diaplikasikan
1. Sumber daya manusia

45
 Perencanaan sumber daya manusia memulai
dengan mengevaluasi ruang lingkup serta memilih
kecakapan yang dibutuhkan untuk mnyelesaikan
pengembangan. Baik posisi organisasi maupun
specialty. Jumlah orang yang diperlukan untuk sebuah
proyek perangkat lunak dapat ditentukan setelah
estimasi usaha pengembangan dibuat.
2. Sumber daya perangkat lunak reusable
Kreasi dan penggunaan kembali blok bangunan
perangkat lunak yang seharusnya dikatalog menjadi
referensi yang mudah, distandarisasi untuk aplikasi
yang mudah, dan divalidasi untuk integrasi yang
mudah. Ada empat kategori sumber daya perangkat
lunak yang harus dipertimbngkan pada saat
perencanaan berlangsung, yaitu :
a. Komponen off-the-self Perangkat lunak yang ada
dapat diperoleh dari bagian ketiga atau telah
dikembangkan secara internal untuk proyek
sebelumnya.
b. Komponen full-experience Spesifikasi, kode,
desain atau pengujian data yang sudah ada yang
dikembangkan pada proyek yang lalu yang serupa
dengan perangkat lunak yang akan dibangun pada
proyek saat ini.

46
c. Komponen partial-experience Aplikasi, kode,
desain, atau data pengujiaan yang ada pada proyek
yang lalu yang dihubungkan dengan perangkat
lunak yang dibangun untuk proyek saat ini, tetapi
akan membutuhkan modifikasi substansial.
d. Komponen baru Komponen perangkat lunak yang
harus dibangun oleh tim perangkat lunak
khususnya adalah untuk kebutuhan proyek
sekarang .
Lebih baik mengkhususkan syarat sumber daya
perangkat lunak dari awal. Dengan cara ini evaluasi
teknis dari semua alternatif dapat dilakukan dan akuisisi
secara berkala dapat terjadi.
3. Sumber Daya Lingkungan
Lingkungan yang mendukung poyek perangkat
lunak, yang disebut juga Software Engineering
Environment (SEE), menggabungkan perangkat lunak
dan perangkat keras. Karena sebagian besar organisasi
perangkat lunak memiliki konstituen ganda yang
memerlukan akses ke SEE, maka perencana proyek
harus menentukan jendela waktu yang dibutuhkan bagi
perangkat keras dan perangkat lunak serta
membuktikan bahwa sembersumber daya tersebut dapat
diperoleh.

47
 Pada saat sebuah sistem berbasis komputer akan
direkayasa, tim perangkat lunak mungkin
membutuhkan akses ke elemen perangkat keras yang
sedang dikembangkan oleh tim rekayasa yang lain.

E. Estimasi Proyek Perangkat Lunak

Estimasi sumber daya, biaya dan jadwal untuk

usaha pengembangan perangkat lunak membutuhkan
pengalaman, mengakses informasi historis yang baik,
dan keberanian untuk melakukan pengukuran
kuantitatif bila hanya data kualitatif saja yang ada.
Estimasi membawa resiko yang inheren dan resiko
inilah yang membawa kepada ketidakpastian. Dibawah
ini merupakan faktor-faktor yang mempengaruhi
estimasi.
1. Project Complexity (Kompleksitas Proyek)
Kompleksitas Proyek berpengaruh kuat terhadap
ketidapastian yang inheren dalam perencanaan. Tetapi
kompleksitas merupakan pengukuran relatif yang
dipengaruhi oleh kebiasaan dengan usaha yang sudah
dilakukan pada masa sebelumnya.
2. Project Size (Ukuran Proyek)

48
 Bila ukuran bertambah maka ketergantungan
diantara berbagai elemen perangkat lunak akan
meningkat dengan cepat. Dekomposisi masalah sebagai
suatu pendekatan yang sangat penting dalam proses
estimasi menjadi lebih sulit karena lagi karena elemen-
elemen yang akan didekomposisimasih sangat berat.
3. Structural Uncertainty (Ketidakpastian Struktural)
Bila metrik perangkat lunak yang komprehensif
dapat diperoleh pada proyek yang telah lalu, maka
estimasi dapat dilakukan dengan kepastian yang lebih
tinggi.jadwal dapat dibuat untuk menhindari kesulitan-
kesuliatan yang terjadi di masa lalu, dan resiko
keseluruhan dapat dikurangi.
Biaya perangkat lunak terdiri dari presentase
kecil pada biaya sistem berbasis komputer secara
keseluruhan. Kesalahan estimasi biaya yang besar dapat
memberikan perbedaan antara keuntungan dan
kerugian. Estimasi proyek perangkat lunak dapat
ditranformasi dari suatu seni yang misterius ke dalam
langkah-langkah yang sistematis yang memberikan
estimasi dengan risiko yang dapat diterima.
Sejumlah pilihan untuk mencapai estimasi biaya
dan usaha yang dapat dipertanggung jawabkan :
1) Menunda etimasi sampai akhir proyek

49
2) Mendasarkan etimasi pada proyek-proyek yang
mirip yang sudah pernah dilakukan sebelumnya.
3) Menggunakan “teknik dekomposisi” yang relatif
sederhana untuk melakukan estimasi biaya dan
usaha proyek.
4) Menggunakan satu atau lebih model empiris bagi
estimasi usaha dan biaya perangkat lunak.
Model estimasi empiris dapat digunakan untuk
melengkapi teknik dekomposisi serta menawarkan
pendekatan estimasi yang secara potensial berharga.
Model berbasis pengalaman (data hitoris) dan
berbentuk : d = ƒ( 𝑣𝑖) di mana d adalah satu dari
sejumlah harga estimasi (contoh : usaha, biaya,durasi
proyek) dan 𝑣𝑖 adalah parameter independen yang
dipilih (seperti LOC dan FP yang diestimasi). Peranti
estimasi otomatis mengimplementasi satu atau lebih
teknik dekomposisi atau model empiris. Masing-masing
pilihan estimasi biaya perangkat lunak yang dapat
dilakukan sama baiknya dengan data hitoris yang
digunakan untuk menumbuhkan estimasi.

50
F. Langkah-langkah Dalam Perencanaan Proyek
Perangkat Lunak :

1. Scoping (Ruang Lingkup)

Memahami permasalahan dan pekerjaan yang
harus dilaksanakan. Idenya adalah sejauh mana
permasalahan atau pekerjaan yang akan ditangani.
Misalnya mengenai: Data, fungsionalfungsional,
kinerja, kendala (constraint) atau syarat.
Scoping menggunakan teknik :
a. Teknik Dekomposisi
Masalah yang dipecahkan sangat kompleks untuk
dipertimbangkan sebagai satu kesatuan, karena itu kita
mendekomposisi masalah, menandainya sebagai
serangkaian masalah yang lebih kecil. Penggambaran
dua fungsi perangkat lunak mayor, diikuti oleh
perkiraan baik ukuran maupun jumlah person-month
yang dibutuhkan untuk mengimplementasikan masing-
masing fungsi.
Dekomposisi |---------> Masalah : LOC Dan FP
|---------> Proses : perkiraan
proses yg akan digunakan, dekomposisi aktivitas dan
usaha yg dibutuhkan untuk menyelesaikan tugas yang
diestimasi.
Teknik yang digunakan :
51
1) Software Sizing (Penentuan ukuran Proyek)
Yaitu dengan cara langsung (LOC) dan tak
langsung (FP). Akurasi estimasi proyek perangkat lunak
didasarkan pada sejumlah hal :
a) Tingkat di mana perencana telah dengan tepat
mengestimasi ukuran produk yang akan dibuat.
b) Kemampuan untuk menerjemahkan estimasi
ukuran ke dalam kerja manusia, waktu kalender,
dan dolar.
c) Tingkat di mana rencana proyek mencerminkan
kemampuan tim perangkat lunak.
d) Stabilitas syarat produk serta lingkungan yang
mendukung usaha pengembangan perangkat
lunak.
Dalam konteks perencanaan proyek, ukuran
berarti keluran yang dapat dikuantitatifkan dari proyek
perangkat lunak. Bila dilakukan pendekatan secara
langung, ukuran dapat diukur dalam LOC. Tetapi bila
dipilih pendekatan tidak langsung, ukuran dihadirkan
dalam FP. Putnam dan Myres mengusulkan 4
pendekatan yang berbeda dalam masalah pengukuran :
a) Fuzzy-logic sizing
Pendekatan yang menggunakan teknik reasoning
aproksimasi yang merupakan dasar bagi fuzzy

52
logic(logika kabur). Perencana harus mengidentifikasi
tipe aplikasi, membuat besarnya dalam skala kuantitatif,
dan menyaring besaran itu dalam bentuk oriinil.
b) Function point sizing
Perencanaan pengembangan estimasi karakteritik
domain informasi
c) Standart component sizing
Perangkat lunak dibangun dari sejumlah
komponen yang standar yang berbeda-beda yang umum
bagi suatu era aplikasi tertentu.
d) Change sizing
Pendekatan ini digunakan bila proyek
melingkupi pemakaian perangkat lunak yang ada harus
dimodihikasi dengan banyak cara sebagai bagian dari
sebuah proyek. Dengan menggungakan suatu “rasio
kerja” bagi masing-masing tipe perubahan, maka
ukuran perubahan dapat diperkirakan.
2) Perkiraan berdasarkan masalah
Baris kode (LOC) dan titik fungsi (FP)
digambarkan sebagai pengukuran dasar di mana metrik
produktivitas dapat dihitung. Data LOC dan FP
digunakan dalam dua cara :

53
 a) Sebagai variabel untuk estimasi yang dipakai
untuk mengukur masing-masing elemen
perangkat lunak.
b) Sebagai metrik baseline yang dikumpulkan dari
proyek yang lalu dan dipakai dalam
hubungannya dengan variabel estimasi untuk
mengembangkan proyeksi kerja dan biaya.
Expected value untuk variabel estimasi (ukuran),
EV, dapat dihitung sebagai rata-rata terbobot dari
estimasi optimistik (Sopt), paling sering(Sm), dan
pesimistik (Spess). Contohnya :
EV = ( Sopt +Sm +Spess)/6
Memberikan kepercayaan terbesar pada estimasi
“yang paling mungkin” serta mengikuti distribui
probabilitas beta. Sekali expected value untuk variabel
estimasi ditentukan, data produktivitas LOC dan FP
diaplikasikan. Setiap teknik estimasi, bagaimanapun
canggihnya, masih harus tetap di cross check dengan
pendekatan lainnya dan baru kemudian kaidah umum
dan pengalaman dapat berlaku di sini.
b. Model Perkiraan Empiris
Model perkiraan untuk perangkat lunak
komputer menggunakan rumusan yang ditarik secara
empiris untuk memprediksi usaha sebagai sebuah fungi

54
LOC dan FP. Data empiris yang mendukung sebagaian
besar model perkiraan ditarik dari sebuah sampel
proyek yang terbatas.
1) Struktur model perkiraaan
Model perkiraan tertentu ditarik dengan
menggunakan analisis regresi terhadap data yang
dikumpulkan dari proyek perangkat lunak sebelumnya.
Struktur model ini berbentuk :
E = A+Bx(Ev)c
Dimana A, B, C adalah konstanta yang ditarik
secara empiris, E adalah usaha dalam peron-month, dan
EV adalah variabel perkiraan (baik dalam LOC maupun
FP).
2) Model COCOMO
Kependekan dari COnstructive COst MOdel
(Model Biaya KOnstruktif). Hirarki model Boehm
berbentuk sebagai berikut :
a) Model1 : Model COCOMO dasar menghitung
usaha pengembangan perangkat lunak (dan
biaya) sebagai fungsi dari ukuran program yang
diekspresikan dalam baris kode yang diestimasi,
b) Model2 : Model COCOMO Intermediete
menghitung usaha pengembangan perangkat
lunak sebagai fungsi ukuran program dan

55
 serangkaian “pengendali biaya” yang
menyangkut penilaian yang subyektif terhadap
produk, perangkat keras personil, dan atribut
proyek.
c) Model3 : Model COCOMO advenced
menghubungkan semua karakteristik versi
intermediete dengan penilaian terhadap pengaruh
pengendali biaya pada setiap langkah (analisis,
perancangan, dll) dari proses rekayasa perangkat
lunak. Persamaan COCOMO dasar berbentuk :
E = abKLOCbb D = cbEdb
Dimana E adalah usaha yang diaplikasikan dalam
person-month, D adalah waktu pengembangan dalam
bulan kronologis, dan KLOC adalah jumlah baris
penyampaian kode yang diperkirakan untuk proyek
tersebut. Koefisien ab dan cb dan eksponen bb dan db
ada pada tabel Model cocomo dasar Proyek perangkat
lunak ab bb cb db
Organik 2,4 1,05 2,5 0,38
Semi-detached 3,0 1,12 2,5 0,35
Embedded 3,6 1,20 2,5 0,32

c. Estimasi

56
 Menyangkut cost (biaya) dan time (waktu) kerja,
size (besarnya software yang akan dikerjakan), user,
usaha-usaha yang diperlukan. Apakah estimasi itu
berdasarkan yang meminta atau yang mempunyai uang
(proyek) hal itu menjadi masalah.
d. Pertimbangkan Resiko / hal-hal yang harus
dipikirkan :
1) Apa yang dapat menjadi salah
2) Bagaimana untuk menghindari
3) Apa yang dapat dikerjakan untuk mengatasi hal
tersebut

57
 BAB IV

KONSEP DAN PRINSIP ANALISIS

A. Analisis Kebutuhan Perangkat Lunak

Analisa kebutuhan adalah suatu proses untuk

mendapatkan informasi, mode, spesifikasi tentang
perangkat lunak yang diinginkan klien/pengguna. Kedua
belah pihak, yaitu klien dan pembuat perangkat lunak
terlibat aktif dalam tahap ini. Informasi dari klien yang
akan menjadi acuan untuk melakukan desain perangkat
lunak. Analisis kebutuhan merupakan satu di antara
banyak aktivitas kritis pada proses rekayasa kebutuhan
perangkat lunak untuk memahami ranah permasalahan
dari sistem yang berjalan dan ranah solusi dari sistem
yang akan dibuat. Ada tiga faktor yang harus dipenuhi
ketika melakukan analisis kebutuhan ini, yaitu sebagai
berikut :
1. Lengkap artinya semua yang diharapkan oleh
klien telah didapatkan oleh pihak yang
melakukan analisis.
2. Detail maksudnya adalah berhasil
mengumpulkan informasi yang terperinci.

58
 3. Benar artinya semua data dari analisis kebutuhan
ini haruslah benar, sesuai apa yang dimaksud
oleh klien, bukan benar menurut apa yang
dipikirkan oleh pihak analisis.

Analisis kebutuhan yang dilakukan terhadap

perangkat lunak akan menghasilkan spesifikasi perangkat
lunak tersebut. Analisa kebutuhan ini terdiri dari lima
langkah pokok:
1. Identifikasi masalah
2. Evaluasi dan sintesis
3. Pemodelan
4. Spesifikasi
5. Review

Ada tiga tujuan utama dari proses analasis

kebutuhan yang dapat diformulasikan sebagai berikut :
1. Mengelola hasil elistasi kebutuhan untuk
menghasilkan dokumen spesifikasi kebutuhan
yang isi keseluruhannya sesuai dengan apa yang
diinginkan pengguna.
2. Mengembangkan persyaratan kualitas yang
memadai dan rinci, dimana para manajer dapat
membuat pekerjaan proyek yang realistis dan staf

59
 teknis dapat melanjutkan dengan perancangan,
implementasi dan pengujian.
3. Membangun pemahaman tentang karakteristik
ranah permasalahan dan sekumpulan kebutuhan
untuk menemukan solusi.

Ketiga tujuan tersebut dapat dicapai oleh

perekayasa kebutuhan dengan melalui serangkaian
tahapan-tahapan analisis. Tahap analisis adalah tahapan
pengumpulan kebutuhan-kebutuhan dari semua elemen
sistem perangkat lunak yang akan di bangun. Pada tahap
ini dibentuk spesifikasi kebutuhan perangkat lunak,
fungsi perangkat lunak yang dibutuhkan, performansi
(unjuk kerja) sistem perangkat lunak, penjadwalan
proyek, identifikasi sumber daya (manusia , perangkat
keras dan perangkat lunak yang dibutuhkan) dan taksiran
biaya pengembangan perangkat lunak.
Beberapa tahapan analisis, yaitu sebagai berikut :
1. Domain Understanding
Pada tahap ini perekayasa kebutuhan pera
ngkat lunak harus mengetahui bagaimana organi
sasi perusahaan beroperasi dan apa yang menjad
i permasalahan pada sistem yang sedang berjala
n pada saat ini.

60
2. Requirements Collection
Tahapan ini merupakan tahapan
pengumpulan kebutuhan akan sistem yang akan
dibangun. Pada tahapan ini perlukan adanya
interaksi intensif dengan pemangku kepentingan
terutama dengan pengguna akhir.
3. Classification
Jika pada tahapan sebelumnya kumpulan
kebutuhan masih tidak terstruktur, pada tahapan
ini kebutuhan yang saling berkaitan
dikelompokkan, baik menurut kelas
penggunanya maupun jenis kebutuhannya.
Kebutuhan-kebutuhan tersebut diorganisasi ke
dalam kelompok yang koheren. Perekayasaan
perlu memisahkan antara kebutuhan dan
keinginan dari pengguna.
4. Conflict resolution
Pada tahap ini yang dilakukan adalah
menemukan dan menyelesaikan kebutuhan yang
di dalamnya terdapat konflik.
5. Prioritisation
Pada tahapan ini dilakukan interaksi
dengan pemangku kepentingan untuk
identifikasikan kebutuhan prioritas agar sumber

61
 daya yang tersedia pada organisasi dialokasikan
untuk mengimplementasikan kebutuhan yang
utama dari pemangku kepentingan.
6. Requirements checking
Menganalisa sekumpulan kebutuhan dari
hasil tahapan sebelumnya untuk memverifikasi
dan memvalidasi berdasarkan aspek
kelengkapan, konsistensi, dan kebutuhan nyata.

Kegunaan analisis, yaitu untuk memodelkan

permasalahan dunia nyata agar dapat dimengerti. Dalam
rekayasa kebutuhan, analisa kebutuhan yang baik
hendaklah menitik beratkan pada ranah permasalahan dan
bukan pada ranah solusi. Tujuan utamanya adalah untuk
mencapai pemahaman tentang sifat dari ranah
permasalahan dan permasalahan yang ada di dalamnya.
Pada dasarnya, analisis kebutuhan diawali dengan
spesifikasi (layanan, atribut, properti, kualitas, batasan)
dari sistem solusi yang hendak dibangun.

62
B. Teknik Komunikasi

Gause dan Weinberg menyarankan agar analis

memulainya dengan mengajukan pertanyaan bebas
konteks, dimana pertanyaan tersebut terfokus pada
pelanggan, tujuan keseluruhan, dan keuntungan.
Contoh :
1. Siapa di balik permintaan untuk pekerjaan ini?
2. Apa keuntungan ekonomi dari pemecahan yang
berhasil?

Rangkaian pertanyaan berikutnya memungkinkan

analis mendapatkan pemahaman yang lebih baik
mengenai masalah dan pelanggan, untuk menyatakan
persepsinya terhadap suatu pemecahan.
Contoh:
1. Masalah apakah yang akan diselesaikan oleh
pemecahan ini?
2. Dapatkah anda memperlihatkan kepada saya atau
menjelaskan lingkungan dimana pemecahan
tersebut akan digunakan?

Pertanyaan berikutnya berfokus pada efektifitas

pertemuan. Contohnya :

63
 1. Apakah ada orang lain yang dapat memberikan
informasi tambahan?
2. Apakah ada hal lain yang harus saya tanyakan
kepada anda?

Pertanyaan-pertanyaan tersebut akan membantu

analis mengawali komunikasi yang perlu untuk
berhasilnya analisis. Pada dasarnya, sesi tanya jawab
harus digunakan pada pertemuan pertama dan kemudian
diganti elemen-elemen pemecahan masalah, negosiasi,
dan spesifikasi.
Penyebaran fungsi kualitas disebut juga Quality
Function Deployment (QFD), yaitu teknik manajemen
kualitas yang menerjemahkan kebutuhan pelanggan ke
dalam persyaratan teknis bagi perangkat lunak. QFD
mengidentifikasi 3 persyaratan, yaitu :

1. Persyaratan normal
2. Sasaran
3. Tujuan dinyatakan bagi sebuah produk atau
sistem selama pertemuan dengan pelanggan.

Apabila persyaratan tersebut ada, maka

pelanggan akan menjadi puas. Seperti tipe tampilan

64
 grafis yang diminta, dan tingkat kerja yang
didefinisikan.
Dalam kenyataan, QFD mencakup seluruh proses
rekayasa, tetapi banyak konsep QFD yang dapat
diaplikasikan ke dalam masalah komunikasi pelanggan
yang dihadapi oleh perekayasa perangkat lunak selama
tahap awal analisis persyaratan.

C. Prinsip-Prinsip Analisis

Masing-masing metode analisis memiliki titik

pandang yang unik. Tetapi semua metode analisis
dihubungkan oleh serangkaian prinsip operasional :
1. Domain informasi dari suatu masalah harus
direpresentasikan dan dipahami.
2. Fungsi-fungsi yang akan dilakukan oleh
perangkat lunak harus didefinisikan.
3. Tingkah laku perangkat lunak (sebagai suatu
urutan kejadian eksternal) harus diwakilkan.
4. Model-model yang menggambarkan
informasi, fungsi, dan tingkah laku harus
dipecah-pecah dalam suatu cara yang

65
 membongkar suatu detail dalam bentuk
lapisan.
5. Proses analisis harus bergerak dari informasi
dasar ke detail implementasi.

Dengan mengaplikasikan prinsip-prinsip

tersebut, analis mendekati suatu masalah secara
sistematis. Perekayasa perangkat lunak yang
mempercayai prinsip tersebut akan dapat lebih
mengembangkan spesifikasi perangkat lunak yang
kemudian akan menjadi dasar yang kuat bagi desain.
Prinsip analisis operasional mengharuskan kita
membangun model fungsi dan tingkah laku, yaitu:
1. Model fungsional
Perangkat lunak mentransformasi
informasi, dan untuk melakukannya,
perangkat lunak harus melakukan paling tidak
tiga fungsi genetik, yaitu input, pemrosesan,
dan output. Pada saat model fungsional dari
suatu aplikasi dibuat, perekayasa perangkat
lunak memfokuskan diri pada fungsi-fungsi
masalah khusus. Model fungsi dimulai
dengan sebuah model tingkat konteks tunggal
(yakni nama perangkat lunak yang akan

66
 dibuat). Dengan serangkaian iterasi, maka
lebih banyak lagi detail fungsional diberikan,
sampai seluruh rancangan dari semua
fungsionalitas sistem terwakili.
2. Model tingkah laku
Model tingkah laku menciptakan representasi
pernyataan-pernyataan perangkat lunak dan
event-event yang menyebabkan perangkat lunak
mengubah pernyataan. Model yang diciptakan
selama analisis persyaratan melayani sejumlah
peran penting, yaitu :
a. Model membantu analis dalam memahami
informasi, fungsi, dan tingkah laku suatu
sistem, sehingga membuat tugas analisis
persyaratan menjadi lebih mudah dan lebih
sistematis.
b. Model menjadi titik fokus bagi kajian
sehingga merupakan kunci bagi penentuan
kelengkapan, konsistensi, dan akurasi dari
spesifikasi.
c. Model menjadi dasar bagi pengerjaan
desain, memberi perancang suatu
representasi esensial dari perangkat lunak
yang dapat diterjemahkan ke dalam suatu

67
 konteks implementasi. Meskipun metode
pemodelan yang digunakan sering menjadi
masalah preferensi personal atau
organisasional, aktivitas pemodelan adalah
dasar bagi kerja analisis yang baik.

D. Prototyping Perangkat Lunak

Dalam beberapa hal, prototyping perangkat lunak

mungkin untuk menerapkan analisis operasi prinsip dan
memperoleh suatu model software dari suatu desain yang
dapat dikembangkan.
Prototyping perangkat lunak (software
prototyping) atau siklus hidup menggunakan
protoyping (life cycle using prototyping) adalah salah
satu metode siklus hidup sistem yang didasarkan pada
konsep model bekerja (working model). Tujuannya
adalah mengembangkan model menjadi sistem final.
Artinya sistem akan dikembangkan lebih cepat daripada
metode tradisional dan biayanya menjadi lebih
rendah. Ada banyak cara untuk memprotoyping, begitu
pula dengan penggunaannya. Ciri khas dari metodologi
adalah pengembang sistem (system developer), klien, dan

68
pengguna dapat melihat dan melakukan eksperimen
dengan bagian dari sistem komputer dari sejak awal
proses pengembangan.
Dengan prototype yang terbuka, model sebuah
sistem (atau bagiannya) dikembangkan secara cepat dan
dipoles dalam diskusi yang berkali-kali dengan
klien. Model tersebut menunjukkan kepada klien apa
yang akan dilakukan oleh sistem, namun tidak didukung
oleh rancangan desain struktur yang mendetil. Pada saat
perancang dan klien melakukan percobaan dengan
berbagai ide pada suatu model dan setuju dengan desain
final, rancangan yang sesungguhnya dibuat tepat seperti
model dengan kualitas yang lebih bagus.
Berikut merupakan beberapa pendekatan
prototyping :
1. Pendekatan close-ended yang disebut juga
lembaran prototype iklah, yaitu sebuah
prototype melayani sebagai demonstrasi
keras dari kebutuhan.
2. Pendekatan open-ended yang disebut juga
evolusiner membuat prototype, yaitu suatu
prototype bertindak sebagai evolusi pertama
dari sistem yang telah selesai.

69
 Protoyping membantu dalam menemukan
kebutuhan di tahap awal pengembangan, terutama jika
klien tidak yakin dimana masalah berasal. Selain itu
protoyping juga berguna sebagai alat untuk mendesain
dan memperbaiki user interface bagaimana sistem akan
terlihat oleh orang-orang yang menggunakannya.
Salah satu hal terpenting mengenai metodologi ini,
cepat atau lambat akan disingkirkan dan hanya digunakan
untuk tujuan dokumentasi. Kelemahannya adalah metode
ini tidak memiliki analisis dan rancangan yang mendalam
yang merupakan hal penting bagi sistem yang sudah
kokoh, terpercaya dan bisa dikelola. Jika seorang
pengembang memutuskan untuk membangun jenis
prototipe ini, penting untuk memutuskan kapan dan
bagaimana ia akan disingkirkan dan selanjutnya
menjamin bahwa hal tersebut telah diselesaikan tepat
pada waktunya.

E. Spesifikasi Dan Kajian Spesifikasi Perangkat Lunak

1. Spesifikasi perangkat lunak

Pada prinsipnya, spesifikasi merupakan
representasi persyaratan dari perangkat lunak yang

70
akan dibangun. Yang memerlukan pendekatan
sebagai berikut :
a. Teknik spesifikasi yang
terfasilitasi/Facilitated Aplication
Specification Techniques (FAST)
Adanya teknik pendekatan spesifikasi
aplikasi yang teratasi / Facilitated
Aplication Spesification Techniques (FAST)
dapat mendorong munculnya tim gabungan
antara pengembang dan pelanggan yang
bekerjasama untuk mengidentifikasi
masalah, mengusulkan elemen pemecahan,
menegosiasi pendekatan yang berbeda, dan
mengkhususkan rangkaian pemecahan awal.
FAST bukanlah obat bagi masalah yang
dihadapi dalam pengumpulan awal berbagai
persyaratan, tetapi pendekatan tim
memberikan keuntungan dari banyak sudut
pandang, diskusi sesaat, dan penyaringan,
serta merupakan langkah maju konkrit ke
arah pengembangan spesifikasi.
Banyak pendekatan yang berbeda
terhadap FAST yang telah diusulkan dan
masing-masing pendekatan menggunakan

71
 skenario yang sangat berbeda, tetapi
semuanya menerapkan beberapa variasi
tuntutan dasar seperti pertemuan dilakukan
di sisi netral dan dihadiri baik oleh
pengembang maupun pelanggan.

b. Penyebaran fungsi kualitas

Penyebaran fungsi kualitas disebut
juga Quality Function Deployment (QFD),
yaitu teknik manajemen kualitas yang
menerjemahkan kebutuhan pelanggan ke
dalam persyaratan teknis bagi perangkat
lunak. QFD mengidentifikasi 3 persyaratan,
yaitu :
1.) Persyaratan normal
2.) Sasaran
3.) Tujuan dinyatakan bagi sebuah
produk atau sistem selama
pertemuan dengan pelanggan.

Apabila persyaratan tersebut ada,

maka pelanggan akan menjadi puas.
Seperti tipe tampilan grafis yang

72
 diminta, dan tingkat kerja yang
didefinisikan.

Dalam kenyataan, QFD mencakup seluruh

proses rekayasa, tetapi banyak konsep QFD yang
dapat diaplikasikan ke dalam masalah komunikasi
pelanggan yang dihadapi oleh perekayasa perangkat
lunak selama tahap awal analisis persyaratan.
Berikut merupakan beberapa prinsip
spesifikasi, yaitu sebagai berikut:
a. Memisahkan kemampuan dari
implementasi.
b. Mengembangkan suatu model menyangkut
perilaku yang diinginkan dari suatu system.
c. Menetapkan konteks di mana software
beroperasi.
d. Menggambarkan lingkungan di mana sistem
beroperasi.
e. Menciptakan suatu model teori dibanding
suatu implementasi atau desain model.
f. Menetapkan struktur dan isi dari suatu
spesifikasi (mudah untuk diubah).

2. Kajian spesifikasi perangkat lunak

73
 Kajian spesifikasi digunakan untuk
memastikan spesifikasi perangkat lunak sudah
lengkap, konsisten, dan akurat. Contoh pertanyaan
kajian :
c. Apakah tujuan dan sasaran yang dinyatakan
bagi perangkat lunak tetap konsisten dengan
tujuan dan sasaran sistem?
d. Apakah interface ke semua elemen sistem
sudah digambarkan?
e. Apakah aliran informasi dan struktur telah
didefinisikan dengan tepat bagi domain
masalah?
f. Apakah diagram telah dipresentasikan
dengan jelas?
g. Apakah fungsi mayor tetap ada dalam ruang
lingkup dan sudah digambarkan dengan
tepat?
h. Apakah perilaku PL konsisten dengan
informasi yang harus diproses dan fungsi
yang harus dilakukannya?
i. Apakah batasan desain realistis?
j. Apakah risiko teknologis pengembangan
sudah dipertimbangkan?

74
k. Apakah kriteria validasi dinyatakan secara
detil dan memadai untuk menggambarkan
sebuah sistem yang berhasil?
l. Apakah ada inkonsistensi, penghilangan,
atau redundancy?
m. Apakah kontak dengan pelanggan sudah
lengkap?
n. Apakah pemakai sudah mengkaji manual
atau prototype?

75
 BAB V

PEMODELAN DAN MEKANISME ANALISIS

A. Elemen Model Analisis

Model analisis merupakan serangkaian model,

representasi teknis yang pertama dari sistem. Pemodelan
analisis didominasi oleh 2 hal yaitu analisis terstruktur
dan analisis berorientasi objek. Pada tingkat teknik,
rekayasa perangkat lunak dimulai dengan serangkaian
tugas pemodelan yang membawa kepada suatu
spesifikasi lengkap dari persyaratan representasi dan
representasi desain yang komprehensip bagi perangkat
lunak yang dibangun.
Model analisis harus dapat mencapai 3 sasaran
utama, yaitu :
1. Untuk menggambarkan apa yang dibutuhkan
oleh pelanggan.
2. Untuk membangun dasar bagi pembuatan desain
perangkat lunak.
3. Untuk membatasi serangkaian persyaratan yang
dapat divalidasi begitu perangkat lunak
dibangun.

76
 Untuk mencapai sasaran tersebut dibuatlah model
analisis yang berisi:
1. Data Dictionary (Kamus Data)
Kamus data adalah suatu daftar data
elemen yang terorganisir dengan definisi yang
tetap dan sesuai dengan sistem, sehingga user dan
analis sistem mempunyai pengertian yang sama
tentang input, output, dan komponen data strore.
Kamus data ini sangat membantu analis sistem
dalam mendefinisikan data yang mengalir di
dalam sistem, sehingga pendefinisian data itu
dapat dilakukan dengan lengkap dan terstruktur.
Pembentukan kamus data dilaksanakan dalam
tahap analisis dan perancangan suatu sistem.
Pada tahap analisis, kamus data
merupakan alat komunikasi antara user dan analis
sistem tentang data yang mengalir di dalam
sistem, yaitu tentang data yang masuk ke sistem
dan tentang informasi yang dibutuhkan oleh user.
Sementara itu, pada tahap perancangan sistem
kamus data digunakan untuk merancang input,
laporan dan database. Pembentukan kamus data
didasarkan atas alur data yang terdapat pada
DFD.

77
2. Entity Relationship Diagram (ERD)
Merupakan notasi yang digunakan untuk
melakukan aktivitas pemodelan data.. ERD
merupakan suatu model untuk menjelaskan
hubungan antar data dalam basis data
berdasarkan objek-objek dasar data yang
mempunyai hubungan antar relasi.
ERD digunakan untuk memodelkan
struktur data dan hubungan antar data dan untuk
menggambarkannya digunakan beberapa elemen.
Pada dasarnya ada lima elemen yang digunakan,
yaitu :
a. Entitas
b. Relasi
c. Attribut
d. Kardinalitas
e. Modalitas

3. Data Flow Diagram (DFD)

Data Flow Diagram (DFD) merupakan
alat yang digunakan untuk menggambarkan suatu
sistem yang telah ada atau sistem baru yang akan
dikembangkan secara logika tanpa
mempertimbangkan lingkungan fisik dimana

78
 data tersebut mengalir ataupun lingkungan fisik
dimana data tersebut akan disimpan. Pada
dasarnya ada empat elemen yang digunakan,
yaitu :
a. Process
b. Data flow
c. Data store
d. External entity

Data Flow Diagram (DFD) melayani 2

tujuan, yaitu :
a. Untuk memberikan indikasi mengenai
bagaimana data ditransformasikan pada
saat data bergerak melalui system.
b. Untuk menggambarkan fungsi-fungsi (dan
sub fungsi) yang
mentransformasikanaliran data.

4. State Transition Diagram (STD)

State Transition Diagram (STD)
menunjukan bagaimana sistem bertingkah laku
sebagai akibat dari kejadian eksternal. Untuk
melakukannya, STD menunjukkan berbagai
model tingkah laku yang disebut dengan STATE

79
 system dan cara dimana transisi dibuat dari
STATE satu ke STATE yang lain. STD berfungsi
sebagi dasar bagi pemodelan tingkah laku .
Aspek control dari perangkat lunak diisikan
dalam spesifikasi kontrol/Control Specification
(SCPEC). STD juga menggambarkan aksi yang
dilakukan karena kejadian tertentu, dimana
memiliki 3 elemen yaitu:
1) State : state kondisi pada sistem.
2) Event : kondisi yang akan terjadi yang
dapat merubah state.
3) Action : perubahan yang terjadi akibat dari
perubahan state.

5. Control Specification (CSPEC)

Control Specification digunakan untuk
menggambarkan deskripsi dan spesifikasi dari
setiap proses yang paling rendah (proses atomik)
yang ada pada system. Control Specification
menggunakan notasi yang disebut Structure
English atau pseudo-Code, yang penulisaannya
cukup sederhana sehingga dapat digunakan
sebagai media untuk mengkomunikasikan proses
yang dilakukan sistem kepada pemakai. Control

80
 Specification tersusun dari tiga struktur dasar,
yaitu :
a. Struktur sekuensi.
b. Pemilihan.
c. Pengulangan.

Pada inti model terdapat kamus data (data

dictionary), penyimpan yang berisi deskripsi dari semua
objek data yang dikonsumsi/diproduksi oleh perangkat
lunak. Pada tahap analisis, kamus data merupakan alat
komunikasi antara user dan analis sistem tentang data
yang mengalir di dalam sistem, yaitu tentang data yang
masuk ke sistem dan tentang informasi yang dibutuhkan
oleh user. Berikut ini yang megelilingi inti yakni :
a. Entity Relationship Diagram (ERD).
b. Data Flow Diagram (DFD).
c. State Transition Diagram (STD).

Keuntungan dari pemodelan analisis, yaitu:

a. Memberikan spesifikasi kebutuhan yang
lebih lengkap dan presisi menghilangkan
ambiguitas dan redudansi.
b. Dijelaskan dalam bahasa
“developer” lebih formal.

81
 c. Spesifikasi lebih terstruktur sehingga lebih
mudah dipahami dan dipelihara.

B. Pemodelan Data

Pemodelan Data dalam rekayasa perangkat lunak

adalah proses menciptakan sebuah model data dengan
menerapkan model deskripsi formal data menggunakan
teknik pemodelan data. Pemodelan data adalah metode
yang digunakan untuk menentukan dan menganalisis
persyaratan data yang diperlukan untuk mendukung
proses bisnis suatu organisasi. Data yang dibutuhkan
adalah dicatat sebagai data model konseptual dengan
definisi data yang terkait. Realisasi penerapan model
konseptual yang disebut model data logis.
Untuk menerapkan satu model konseptual data
mungkin membutuhkan beberapa model data logis.
Pemodelan data mendefinisikan elemen tidak hanya data,
tapi struktur dan hubungan antara mereka, teknik
pemodelan data dan metodologi yang digunakan untuk
model data dengan cara yang standar yang konsisten,

82
dapat diprediksi untuk mengelolanya sebagai sumber
daya. Pada tingkat teknik, rekayasa perangkat lunak
dimulai dengan serangkaian tugas pemodelan. Model
analisis sebenarnya merupakan serangkaian model yang
merupakan representasi teknis yang pertama dari system.
Di dalam suatu industri dikenal berbagai macam
proses, demikian juga halnya dengan industri perangkat
lunak. Perbedaan proses yang digunakan akan
menguraikan aktivitas-aktivitas proses dalam cara-cara
yang berlainan. Perusahaan yang berbeda menggunakan
proses yang berbeda untuk menghasilkan produk yang
sama. Tipe produk yang berbeda mungkin dihasilkan oleh
sebuah perusahaan dengan menggunakan proses yang
berbeda. Namun beberapa proses lebih cocok dari lainnya
untuk beberapa tipe aplikasi. Jika proses yang salah
digunakan akan mengurangi kualitas kegunaan produk
yang dikembangkan.
Pemodelan data merupakan sebuah tahapan dalam
merancang sebuah sistem informasi. Pemodelan data
berfokus pada data apa yang akan disimpan yang
menggambarkan hubungan entara entiti set yang
dibutuhkan oleh sebuah organisasi dalam pengelolaan
data. Untuk menerapkan satu model konseptual data
mungkin membutuhkan beberapa model data logis.

83
Pemodelan data mendefinisikan elemen tidak hanya data,
tapi struktur dan hubungan antara mereka teknik
pemodelan data dan metodologi yang digunakan untuk
model data dengan cara yang standar yang konsisten,
dapat diprediksi untuk mengelolanya sebagai sumber
daya. Pemodelan data menjawab serangkaian pertanyaan
spesifik yang relevan dengan aplikasi pemrosesan data.
1. Bagaimana komposisi dari masing-masing obyek
data dan atribut apa yang menggambarkab obyek
tersebut?
2. Dimana obyek saat ini berada?
3. Bagaimana hubungan antara masing-masing
obyek data dan obyek lainnya?
4. Bagaimana hubungan antara obyek dengan
proses yang mentransformasikannya?

Untuk menjawab pertanyaan-pertanyaan tersebut,

metode pemodelan data menggunakan ERD. ERD hanya
berfokus pada data (sehingga memuaskan prinsip
pertama analisis operasional). Metode pemodelan data
menggunakan ERD (Entity Relationship Diagram ).
Pada konteks analisis terstruktur, ERD menetapkan
semua data yang dimasukkan, disimpan, ditransformasi,
dan diproduksi pada suatu aplikasi. ERD hanya berfokus

84
pada data (sehingga memuaskan prinsip pertama analisis
operasional) dengan menunjukan “jaringan data” yang
ada untuk suatu system yang berikan. ERD sangat
berguna bagi aplikasi dimana data dan hubungannya
mengatur data yang kompleks.
1. Obyek Data, Atribut dan Hubungan
Model data terdiri dari tiga informasi yang
saling bergantungan :
a. Obyek Data
Obyek data adalah representasi dari
hampir semua informasi gabungan yang
harus dipahami oleh perangkat lunak.
Maksudnya dengan informasi gabungan
kita mengartikan sesuatu yang memiliki
sejumlah sifat atau atribut yang berbeda.
Contohnya orang atau mobil dapat
dipandang sebagai objek data bila salah
satu dari mereka dapat didefinisikan dalam
bentuk atribut.
b. Atribut
Atribut, yaitu menentukan property
suatu obyek data dan mengambil salah satu
dari tiga karakteristik yang berbeda.
Atribut dapat digunakan untuk :

85
 a. Menamai sebuah contoh dari obyek
data.
b. Menggambarkan contoh.
c. Membuat referensi ke contoh yang
lain pada tabel yang lain.
c. Hubungan
Hubungan, yaitu obyek data
disambungkan satu dengan lainnya dengan
berbagai macam cara. Andaikan ada dua
objek data BUKU dan TOKO BUKU,
objek tersebut dapat diwakilkan dengan
menggunakan notasi sederhana, misalnya :
Toko buku memesan buku.

2. Kardinalitas dan Modalitas Kardinalitas

Model data harus dapat merepresentasikan
jumlah peristiwa dari obyek di dalam hubungan
yang diberikan. Kardinalitas merupakan
spesifikasi dari sejumlah peristiwa dari suatu
(objek) yang dapat dihubungkan kesejumlah
peristiwa dari (objek) yang lain. Kardinalitas
biasanya diexpresikan secara sederhana ‘satu’
atau ‘banyak’. Dengan mempertimbangkan

86
 semua kombinasi dari ‘satu’ dan ‘banyak’ dua
objek dapat dihubungkan sebagai :
a. Satu ke satu (1:1)
Misalnya: seorang suami hanya
dapat memiliki satu istri, dan seorang istri
hanya mempunyai satu suami.
b. Satu ke banyak (1:N)
Misalnya: seorang ibu dapat
memiliki banyak anak, tetapi seorang anak
hanya dapat memiliki satu ibu.
c. Banyak ke banyak (M:N)
Misalnya: seorang paman dapat
memiliki banyak keponakan, sementara itu
seorang keponakan dapat memiliki banyak
paman.

Modalitas-modalitas dari suatu hubungan

adalah nol bila tidak ada kebutuhan eksplisit
untuk hubungan yang terjadi atau hubungan itu
bersifat opsional. Modalitas bernilai satu jika
suatu kejadian dari hubungan merupakan
perintah.

3. Entity Relational Diagram

87
 ERD pada mulanya digunakan untuk
desain sistem database relational dan telah
dikembangkan oleh yang lainnya. Serangkaian
komponen utama diidentifikasikan untuk ERD:
obyek data, atribut, hubungan dan berbagai tipe
indicator. Tujuan utama dari ERD adalah untuk
mewakili obyek data dan hubungan mereka.
Objek data diwakili oleh sebuah persegi
panjang yang diberi label. Hubungan ditunjukkan
dengan garis yang diberi label yang
menghubungkan objek dalam variasi ERD, garis
yang menghubungkan berisi sebuah label
permata yang diberi label dengan hubungan
tersebut. Sambungan antara data dan objek dan
hubungan dibangun dengan menggunakan
berbagai macam simbol khusus yang
menunjukkan kardinalitas dan modalitas.
Pemodelan data dan ERD memberi notasi
yang singkat untuk mengamati data didalam
konteks aplikasi pemrosesan data kepada analis.
Dalam sebbagian besar kasus, pendekatan
pemodelan data digunakan untuk menciptakan
satu potong analisis, tetapi dia juga dapat
digunakan untuk perancangan database dan

88
 untuk mendukung metode analisis persyaratan
yang lain.

Karena banyaknya variasi dalam model proses

yang digunakan maka tidak mungkin menghasilkan
gambaran-gambaran yang reliabel untuk alokasi biaya
dalam aktivitas-aktivitas ini. Modifikasi perangkat lunak
biasanya lebih dari 60 % dari total biaya pembuatan
perangkat lunak. Presentasi ini terus bertambah karena
lebih banyak perangkat lunak dihasilkan dan dipelihara.
Pembuatan perangkat lunak untuk suata perubahan
adalah penting. Proses perangkat lunak komplek dan
melibatkan banyak aktivitas.
Seperti produk, proses juga memiliki atribut dan
karakteristik seperti :
a. Understandability, yaitu sejauh mana proses
secara eksplisit ditentukan dan bagaimana
kemudahan definisi proses itu dimengerti.
b. Visibility, apakah aktivitas-aktivitas proses
mencapai titik akhir dalam hasil yang jelas
sehingga kemajuan dari proses tersebut dapat
terlihat nyata/jelas.
c. Supportability, yaitu sejauh mana aktivitas proses
dapat didukung oleh CASE.

89
 d. Acceptability, apakah proses yang telah
ditentukan oleh insinyur dapat diterima dan
digunakan dan mampu bertanggung jawab
selama pembuatan produk perangkat lunak.
e. Reliability, apakah proses didesain sedikian rupa
sehingga kesalahan proses dapat dihindari
sebelum terjadi kesalahan pada produk.
f. Robustness, dapatkah proses terus berjalan
walaupun terjadi masalah yang tak diduga.
g. Maintainability, dapatkah proses berkembang
untuk mengikuti kebutuhan atau perbaikan.
h. Rapidity, bagaimana kecepatan proses
pengiriman sistem dapat secara lengkap
memenuhi spesifikasi.

C. Pemodelan Fungsional dan Aliran Informasi

Informasi ditransformasi pada saat mengalir

melalui sebuah sistem berbasis komputer. Sistem tersebut
menerima input dengan berbagai cara dan menghasilkan
suatu output. Input mengendalikan transformasi tersebut
untuk memproduksi informasi Output yang dilewatkan ke
entitas eksternal.

90
 Analisis terstruktur dimulai sebagai sebuah teknik
pemodelan aliran informasi. Pada saat informasi mengalir
melalui perangkat lunak, dia dimodifikasi oleh suatu
deretan transformasi. Akibatnya kita dapat menciptakan
suatu model aliran bagi setiap sistem berbasis komputer
tanpa melihat ukuran dan kompleksitasnya.

1. Diagram Aliran Data/ Data Flow Diagram (DFD)

Diagram aliran data / data flow diagram
(DFD) adalah sebuah teknik grafis yang
menggambarkan aliran informasi dan
transformasi yang diaplikasikan pada saat data
bergerak dari input menjadi output. Dikenal juga
dengan sebutan grafik aliran data atau buble
chart. Komponen-komponen DFD, yaitu :
a) Proses : menunjukkan apa yang dikerjakan
oleh sistem. Setiap proses memiliki nama
yang unik dan nomor yang ditempatkan
dalam simbol.
b) External entity adalah di luar sistem, tetapi
mereka merupakan salah satu bagian yang
memberikan input data ke dalam sistem atau
digunakan oleh output sistem.

91
 c) Data Flow adalah tempat penyimpanan data
Data Store : Proses dapat menempatkan
data ke dalam data store atau mengambil /
mendapatkan data store. Setiap data store
mempunyai nama yang unik External
Entity.

2. Ekstensi Sistem Real-Time

Sistem real-time harus berinteraksi dengan
dunia nyata didalam kerangka waktu yang
ditentukan oleh dunia nyata. Penerbangan
pesawat, proses pabrik, produk konsumen dan
instrumentasi industri merupakan beberapa dari
ratusan aplikasi perangkat lunak real-time.

3. Ekstensi Ward dan Mellor

Ward dan Mellor memperluas notasi
analisis struktur dasar untuk mengakomodasi
permintaan yang dikenakan oleh system real-
time berikut ini :
a. Aliran informasi dikumpulkan atau
dihasilkan pada basis time-continious.
b. Informasi control yang dilewatkan melalui
system dan pemrosesan control yang sesuai.

92
 c. Contoh bertingkat dari transformasi yang
sama, yang kadang-kadang terjadi didalam
situasi multitasking.
d. Pernyataan system dan mekanisme yang
menyebabkan transisi diantara keadaan.

4. Ekstensi Hatley dan Pirbhai

Ekstensi Hatlei dan Pirbhai kenotasi
analisis terstruktur dasar kurang berfokus pada
kreasi dari symbol grafis tambahan dan lebih
berfokus pada representasi dan spesifikasi aspek
perangkat lunak yang berorientasi pada control.

D. Pemodelan Tingkahlaku

Pemodelan ini merupakan suatu prinsip

operasional untuk semua metode analisis persyaratan
tetapi hanya versi analisis terstruktur yang luas, yang
memberikan suatu notasi bagi tipe pemodelan ini. Untuk
menggambarkan penggunaan ekstensi control dan
tingkah laku Hatley dan Pirbhai, diandaikan perangkat
lunak embedded dalam sebuah mesin foto kopi. Foto kopi
tersebut melakukan sejumlah fungsi yang diimplikasikan

93
oleh DFD tingkat 1, perlu dicatat bahwa penyaringan
tambahan dari aliran dan definisi dari masing-masing
item akan diperlukan.
Diagram state merepresentasikan tingkah laku dari
suatu sistem dengan menggambarkan keadaannya dan
kejadian yang menyebabkan sistem mengubah keadaan.
Suatu keadaan merupakan mode tingkah laku yang dapat
diobservasi.
Model perilaku menggambarkan bagaimana
Perangkat Lunak merespon event atau stimulan eksternal.
Untuk model tersebut, anlisis harus melakukan langkah-
langkah sebagai berikut :
1. Evaluasi semua use-case untuk mendapatkan
pemahaman menyeluruh tentang urutan interaksi
di dalam sistem.
2. Mengenali event yang mengendalikan urutan
interaksi dan memahami bagaimana event
mempunyai relasi terhadap objek spesifik.
3. Membuat urutan untuk setiap use-case.
4. Membangun state diagram untuk sistem.
5. Review model behavioral untuk memverifikasi
akurasi dan konsistensi.

94
E. Mekanisme dari Analisis Terstruktur

Tahap analisis terstruktur dimulai dengan membuat

Diagram Konteks (disebut juga model sistem dasar atau
model konteks) yang menggambarkan fungsi sistem
sebagai sebuah proses transformasi tunggal. Proses dan
aliran informasi pada diagram konteks kemudian dipecah
dan dibagi-bagi menjadi tingkat-tingkat DFD,
selanjutnya untuk pemerincian (tingkat 0, 1, 2, …) sampai
didapat proses atomik (proses – proses yang akan
dikerjakan oleh komputer). Pemerincian dilakukan untuk
menghindari komplektivitas penggambaran DFD.
Gunakan kamus data (Data Dictionary) untuk
mendeskripsikan data yang mengalir dalam sistem dan
spesifikasi proses untuk menerangkan prosesnya.
Kemudian modelkan hubungan antar tempat
penyimpanannya dengan Diagram Entity Relationship
(ERD).
1. Membuat sebuah diagram hubungan Entitas
Diagram hubungan entitas
memungkinkan seorang perekayasa perangkat
lunak untuk secara penuh menspesifikasikan
objek data yang merupakan input dan output dari

95
system. Pendekatan berikut ini perlu diketahui
dalam membuat diagram Entitas :
a. Selama pengumpulan persyaratan,
pelanggan diminta untuk mendaftar ‘hal-
hal’ yang akan dituju oleh proses bisnis
dan aplikasi. ‘Hal-hal’ ini dimasukkan
kedalam sebuah daftar objek data input
dan output dan entitas eksternal yang
menghasilkan atau mengkonsumsi
informasi.
b. Dengan mengambil objek satu pada satu
saat , analis dan pelanggan mendefinisikan
apakah ada sambungan (tidak diberi nama
pada tahap ini ) ada diantara objek data
dan objek lain.
c. Dimanapun sambungan ada, analis dan
pelanggan menciptakan satu pasangan
hubungan objek atau lebih.
d. Untuk masing-masing pasangan hubungan
objek, dicari kardinalitas dan modalitas.
e. Langkah 2 sampai 4 dilanjutkan secara
iterative sampai semua pasangan
hubungan objek sudah didefinisikan.
Sudah menjadi kebiasaan untuk

96
 menemukan penghilangan pada saat
proses ini berlanjut. Objek dan hubungan
baru akan ditambahkan pada saat jumlah
iterasi bertambah.
f. Atribut dari masing-masing entitas
didefinisikan.
g. Diagram entitas diformalisasikan dan
dikaji.
h. Langkah 1 sampai 7 diulangi sampai
pemodelan data terlengkapi.
2. Membuat Sebuah Model Aliran Data
Diagram aliran data (DFD)
memungkinkan perekayasa perangkat lunak
untuk mengembangkan model domain informasi
dan domain fungsional pada saat yang sama.
Beberapa tuntunan sederhana dengan terukur
dapat membantu selama derivasi sebuah diagram
aliran data :
a. Diagram aliran data tingkat 0 harus
menggambarkan perangkat lunak/system
sebagai gelembung tunggal.
b. Input dan output utama harus dicatat
secara berhati-hati.

97
 c. Penyaringan harus dimulai dengan
mengisolasi proses calon, objek data, dan
penyimpanan yang akan direpresentasikan
pada tingkat selanjutnya.
d. Semua anak panah dan gelembung harus
diberi label dengan nama yang berarti.
e. Kontinyuitas aliran informasi harus dijaga
dari tingkat ke tingkat.
f. Satu gelembung pada satu saat harus
disaring. Ada kecenderungan natural
untuk terlalu mengkomlikasikan diagram
aliran data. Hal ini terjadi bila analisis
ingin menunjukkan terlalu banyak detail
pada saat yang terlalu dini.
3. Membuat Sebuah Model Aliran Kontrol
Untuk beberapa tipe aplikasi pemrosesan,
model data dan diagram aliran data meruapakan
hal yang diperlukan untuk memperoleh wawasan
yang berarti kedalam persyaratan perangkat
lunak. Tetapi, seperti yang telah dicatat, disana
ada suatu kelas aplikasi yang besar yang lebih
dikendalikan oleh kejadian dari pada data, yang
lebih menghasilkan informasi control dari pada
menghasilkan laporan dan tampilan. Dan yang

98
memproses informasi dengan perhatian besar
kepada waktu dan kinerja kerja. Aplikasi
semacam itu mambutuhkan pemodelan aliran
control sebagai tambahan kepemodelan aliran
data. Telah kita catat bahwa sebuah kejadian atau
item control diimplementasikan sebagai harga
Boolean (misalnya; benar atau salah, on atau off,
1 atau 0) atau sebuah daftar diskrit dari keadaan
(kosong,penuh), untuk memilih calon kejadian
yang potensial, diusulkan tuntutan berikut ini :
a. Daftarlah semua sensor yang dibaca oleh
perangkat lunak.
b. Daftarlah semua keadaan interupsi.
c. Bacalah semua saklar yang diaktuasi oleh
operator.
d. Daftarlah semua keadaan data.
e. Dengan menarik uraian data kerja dan data
benda yang diaplikasikan ke narasi
pemrosesan, kajilah semua item control
sebagai input /output CSPEC yang
mungkin.
f. Gambarkanlah tingkah laku dari system
dengan mengidentifikasi keadaannya.
Identifikasikanlah bagaimana keadaan

99
 dicapai dan definisikanlah transisi antar
keadaan.
g. Fokuskanlah penghilangan yang mungkin
sebuah kesalahan yang paling umum
didalam menspesifikasikan control
(misalnya, tanyakanlah apakah adakah
suatu cara dimana saya dapat masuk ke
keadaan itu atau keluar darinya).
4. Spesifikasi Kontrol
CSPEC mempresentasikan tingkah laku
system (pada tingkat dimana dia direferensikan)
didalam dua cara yang berbeda. CSPEC berisi
sebuah diagram transisi keadaan (STD) yang
merupakan suatu spesifikasi sekuensial dari
tingkah laku. Dia juga dapat berisi suatu table
aktifitas proses (PAT), yaitu sebuah spesifikasi
kombinaturial dari tingkah laku.
5. Spesifikasi Proses
Spesifikasi Proses (PSPEC) digunakan
untuk menggambarkan semua proses model
aliran yang nampak pada tingkat akhir
penyaringan. Kandungan dari spesifikasi proses
dapat termasuk teks naratif, bahasa design
program/Progamme Design Language (PDL)

100
 dari Algoritma proses, persamaan Matematika,
table, diagram atau bagan, dengan memberikan
sebuah PSPEC untuk mengiringi masing-masing
gelembung didalam model aliran, berarti
perekayasa perangkat lunak menciptakan sebuah
“spesifikasi mini”yang dapat berfungsi sebagai
sebuah langkah pertama didalam kreasi
spesifikasi persyaratan perangkat lunak dan
sebagai penuntun bagi desaign komponen
program yang akan mengimplementasikan
program.

F. Kamus Data

Kamus data merupakan sebuah daftar yang

teroganisasi dari elemen data yang berhubungan dengan
system, dengan definisi yang tegar dan teliti sehingga
pemakai dan analisis system akan memiliki pemahaman
yang umum mengenai input, output, komponen
penyimpan, dan bahkan kalkulasi inter-mediate.
Kamus data pertama berbasis dokumen, kamus data
itu tersimpan dalam bentuk hard copy dengan mencatat
semua penjelasan data dalam bentuk tercetak. Walau

101
sejumlah kamus berbasis dokumen masih ada, praktek
yang umum sekarang adalah menggunakan kamus data
berbasis komputer. Pada kamus data berbasis komputer
penjelasan data dimasukkan ke dalam komputer dengan
menggunakan Data Description Language (DDL) dari
sistem manajemen database,sistem kamus, atau peralatan
CASE.
Saat ini, kamus data hampir selalu
diimplementasikan sebagai bagian dari sebuah “piranti
desain dan analisis terstruktur “ CASE. Sebagian kamus
data berisi informasi sebagai berikut :
a. Name = nama data atau item control,
penyimpanan data, atau entitas eksternal.
b. Aliasi = nama lain yang digunakan untuk entri
pertama.
c. Where-used/how used = suatu daftar dari proses
yang menggunakan data atau item control dan
bagaimana dia digunakan (misalnya input ke
progress, output dari progress, sebagai suatu
penyimpanan, sebagai suatu entitas eksternal).
d. Content description = suatu notasi untuk
mempresentasikan isi.

102
 e. Supplementary information = informasi lain
mengenai tipe data, harga preset (bila
diketahui).

Dengan menggunakan kamus data, analis system

dapat mendefinisikan data yang mengalir di system
dengan lengkap. Kamus data dibuat pada tahap analisis
system dan digunakan baik pada tahap analisis maupun
pada tahap perancangan system, yang berdasarkan arus
data yang ada di DFD.
a. Pada tahap analisis, kamus data digunakan
sebagai alat komunikasi antara analisis system
dengan pemakai system tentang data yang
mengalir di system, yaitu tentang data yang
masuk ke system dan tentang informasi yang
dibutuhkan oleh pemakai system.
b. Pada tahap perancangan sistem, kamus data
digunakan untuk merancang input, merancang
laporan-laporan dan database.

G. Overview Mengenai Metode Analisis Klasik

1. Data Structured Systems Development

103
 Data Structure System Development
(DSSD), yang disebut juga dengan metodologi
Warnier-Orr terjadi dari kerja perintis mengenai
analisis domain informasi yang dilakukan oleh
J.D Warnier. Warnier mengembangkan sebuah
notasi untuk mempresentasikan hirarki informasi
dengan menggunakan tiga kontruksi untuk
urutan, pemilihan, dan pengulangan dan
mendemonstrasikan bahwa struktur perangkat
lunak dapat ditarik dari struktur data. Ken Orr
memperluas kerja Warnier untuk mencakup
pandangan yang lebih luas mengenai domain
informasi yang telah dikembangkan kedalam
DSSD.
2. Jackson System Development
Jackson System Development (JDS)
mengembangkan kerja yang dilakukan oleh M.A.
Jackson tentang analisis domain informasi dan
hubungannya dengan desain system dan
program. Dalam kalimat Jackson , “Pengembang
memulai dengan menciptakan sebuah model
realistis dimana system diperhatikan, realitas
yang memperlengkapi masalah subjek
systemnya..”.

104
3. SADT
Structured Analysis And Design Technique
(SADT) adalah sebuah teknik yang telah
digunakan secara luas sebagai sebuah notasi
untuk definisi system, representasi proses,
analisis persyaratan perangkat lunak dan desaign
system/perangkat lunak.

105
 BAB VI

PRINSIP DAN KONSEP DESAIN

A. Desain Perangkat Lunak dan Rekayasa Perangkat

Lunak

Desain adalah salah satu langkah dalam fase

pengembangan bagi setiap produk atau sistem yang
direkayasa. Desain dapat didefinisikan berbagai “proses
aplikasi berbagai teknik dan prinsip bagi tujuan
pendefinisian suatu perangkat, suatu proses atau sistem
dalam detail yang memadai untuk memungkinkan
realisasi fisiknya”.
Tujuan desainer adalah untuk menghasilkan suatu
model atau representasi dari entitas yang kemudian akan
dibangun. Desain perangkat lunak berada pada inti teknik
dari proses rekayasa perangkat lunak dan diaplikasikan
tanpa memperhatikan model proses perangkat lunak yang
digunakan.
Persyaratan perangkat lunak, yang dimanifestasi
oleh data, fungsional, dan model-model perilaku mengisi
langkah desain. Desain perangkat lunak berada pada
posisi teknik inti dari suatu proses rekayasa perangkat
lunak yang digunakan. pada dasarnya desain perangkat

106
lunak memiliki aktivitas sebagai berikut. Dengan
menggunakan satu dari sejumlah metode desain, langkah
desain menghasilkan hal yang harus diperhatikan, yaitu :
1. Desain data (Data Design)
Desain data merupakan suatu aktivitas
pertama dan juga yang terpentig dari empat
aktivitas desain yang dilakukan selama rekayasa
perangkat lunak. Proses dalam pemilihan struktur
didalam menentukan desain yang paling efisien
dan juga yang sesuai kebutuhan. Desain data
mentransformasikan model domain suatu
informasi yang dibuat selama analisis ke dalam
struktur data yang akan diperlukan untuk dapat
mengimplementasikan perangkat lunak .
2. Desain Arsitektur (Architectural Design)
Pada desain arsitektur ini menentukan
suatu hubungan diantara elemen-elemen struktur
utama dan program.
3. Desain Antar Muka (Interface Design)
Pada desain interface menggambarkan
bagaimana PL berinteraksi dengan sistem yang
berinteroperasi dengan desain interface tersebut
serta pengguna yang menggunakannya.
4. Desain Prosedural (Procedural Design)

107
 Mentransformasikan elemen-elemen
struktural dari desai arsitektur progrma ke dalam
sebuah deskripsi prosedural dari komponen-
komponen perangkat lunak.

Fase pengembangan terdiri dari tiga langkah yaitu

design (teknik desain), code generation (manual or
automatic)/pembuatan kode, dan testing (pengujian),
yang diperlukan untuk membangun dan menguji
perangkat lunak. Setiap langkah melakukan transformasi
informasi dengan suatu cara yang akhirnya menghasilkan
software komputer yang valid.
1) Software Requirements
Dijelaskan dengan information domain,
functional and performance requirments, dan
feed the design step. Dengan menggunakan satu
dari sejumlah metode desain, langkah desain
menghasilkan :
b. Desain data (difokuskan pada definisi dari
struktur data).
c. Desain arsitektur (mendefinisikan
hubungan antara elemen struktur
utamadari program).
d. Desain interface.

108
 e. Desain prosedural (mengubah struktur
elemen kedalam prosedur software).
Selama desain, kita dapat membuat
keputusan yang akan mempengaruhi kesuksesan
konstruksi software dan kemudahan
maintenance-nya. Desain sangat penting karena
dapat menentukan kualitas dari suatu software.
2) Proses Desain
Proses software design dibagi dalam 2
tahap :
1.) Preliminary Design
Pada tahap ini difokuskan dengan
transformasi dari keperluan/kebutuhan ke
dalam data dan arsitektur software.
2.) Detail Design
Difokuskan pada penghalusan
representasi arsitektur yang berisi struktur
data detail dan algoritma untuk software.
Agar dihasilkan desain dengan kriteria
yang baik, maka suatu desain haruslah :
a. Memperlihatkan organisasi hirarki yang
mengontrol elemen-elemen software.

109
 b. Berkenaan dengan modul, software secara
logika terbagi dalam elemen-elemen yang
membentuk fungsi dan sub fungsi.
c. Berisi representasi yang berbeda dan
terpisah dari data dan prosedur.
d. Membentuk modul (contoh subroutine dan
procedure) yang memperlihatkan
karakteristik fungsi yang tidak saling
bergantung.
e. Diturunkan dengan menggunakan metode
perulangan yang didukung oleh informasi
yang ada selama analisa kebutuhan
software.
3) Evolusi Desain Software
Evolusi desain software merupakan suatu
proses kontinu yang terus berlangsung selama
tiga dekade. Beberapa metodologi telah tumbuh,
dan secara umum memiliki karakteristik sebagai
berikut :
a. Mekanisme penerjemahan suatu model
analisis ke dalam representasi desain.
b. Notasi untuk merepresentasikan
komponen-komponen fungsional dan
interface-nya.

110
 c. Heuristik bagi penyaringan dan partisi.
d. Pedoman bagi penilaian kualitas

Agar dihasilkan desain yang baik suatu desain

haruslah :
a. Memperlihatkan organisasi hirarki yang
mengontrol elemen-elemen software.
b. Software secara logika terbagi dalam elemen-
elemen yang membentuk fungsi dan sub fungsi.
c. Berisi representasi yang berbeda dan terpisah dari
data dan prosedur.
d. Membentuk modul ( contoh subroutine dan
procedure ) yang memperlihatkan karakteristik
fungsi yang tidak saling bergantung.
e. Diturunkan dengan menggunakan metode
perulangan yang didukung oleh informasi yang
ada selama analisa kebutuhan software.

B. Prinsip desain

Desain perangkat lunak berupa model dan proses.

Proses desain adalah serangkaian langkah iteratif yang
memungkinkan desainer menggambarkan semua aspek

111
perangkat lunak yang dibangun. Model desain adalah
ekivalen rencana arsitek untuk sebuah “rumah”, yang
dimulai dengan menyajikan totalitas dari hal yang akan
dibangun. Prinsip desain dasar memungkinkan
perekayasa perangkat lunak untuk mengendalikan proses
desain.
1. Proses desain tidak boleh menderita karena“tunnel
vision”. Desainer yang baik harus memperhatikan
pendekatan-pendekatan alternatif, menilai masing-
masing pendekatan berdasarkan persyaratan
masalah.
2. Desain harus dapat ditelusuri sampai model
analisis.
3. Desain tidak boleh berulang. Sistem
dibangundengan menggunakan serangkain pola
desain, beberapa diantaranya kemungkinan telah
ditemukan sebelumnya.
4. Desain harus “meminimalkan kesenjangan
intelektual” di antara perangkat lunak dan masalah
yang ada di dunia nyata. Ini menyatakan bahwa
struktur desain perangkat lunak harus
mencerminkan struktur domain permasalahan.
5. Desain harus mengungkap keseragaman dan
integrasi.desain seragam bila desain

112
 memperlihatkan bahwa satu orang
mengembangkankeseluruhannya.
6. Desain harus terstruktur untuk mengakomodasi
perubahan.
7. Desain harus terstruktur untuk berdegradasi
dengan baik, bahkan pada saat data dan event-
event menyimpang, atau menghadapi kondisi
operasi. Program komputer yang telah dirancang
dengan baik seharusnya tidak pernah “Meledak”.
8. Desain bukanlah pengkodean,dan pengkodean
bukanlah desain. Bahkan bila dibuat desain
prosedural detail bagi komponen-komponen
program.
9. Desain harus dinilai kualitasnya pada saat desain
dibuat, bukan setelah jadi. Ada berbagai konsep
desain dan pengukuran desain untuk membantu
desainer menilai kualitas.
10. Desain harus dikaji untuk meminimalkan
kesalahan-kesalahan konseptual (semantik).
Kadang-kadang ada kecenderungan untuk
memfokuskan pada hal-hal yang remeh pada saat
desain dikaji, sehingga hal yang lebih penting luput
dari perhati. Desainer harus memastikan bahwa
elemen-elemen konseptual mayor dari desain

113
 (penghilangan, ambiguitas, inkonsistensi) telah
ditekankan sebelum mengkhawatirkan sintaks
model desain.

David mengusulkan serangkaian prinsip bagi

desain perangkat lunak , antara lain sebagai berikut :
1. Proses desain seharusnya tidak bertahan dari “tunnel
vision”.
2. Desain harus dapat di trace ke model analisa.
3. Desain seharusnya tidak menemukan/invent wheel.
4. Desain harus “memperkecil jarak intellectual” antara
software dan masalah-masalah pada dunia nyata.
5. Desain harus mengeluarkan uniformity dan integrasi.
6. Desain harus terstruktur untuk mengakomodasi
perubahan.
7. Desain harus terstruktur untuk mendegradasi secara
halus(degrade gently).
8. Desain bukan coding.
9. Desain harus di-assessed untuk kualitas.
Desain harus diulang untuk meminimalis kesalahan
konsep.

114
C. Konsep Desain

Dalam konsep-konsep desain perangkat lunak

terdapat :
1. Abstraksi
Abstraksi memungkinkan desainer
menentukan prosedur dan data, dan masih
menekan detail tingkat rendah. Terdapat 3
macam bentuk abstraksi, yaitu :
a. Abstraksi prosedural.
Merupakan urutan instruksi yang diberi
nama yang mempunyai fungsi tertentu dan
terbatas.
b. Abstraksi data.
Kumpulan data yang bernama yang
menggambarkan obyek data.
c. Abstraksi kontrol.
Mengimplikasikan suatu mekanisme
kontrol program tanpa menentukan detail-
detail internal.
2. Penyaringan
Penyaringan stepwise (dengan serangkaian
langkah) adalah strategi desain top-down yang
diusulkan oleh Wiklaus Wirth. Kajian dari

115
 konsep tersebut adalah “Pada setiap langkah
(penyaringan), satu atau beberapa instruksi dari
program yang diberikan didekomposisi ke dalam
instruksi-instruksi yang lebih detail.
Dekomposisi berurutan atau penyaringan
spesifikasi berhenti bila semua instruksi
diekspresikan dalam bentuk bahasa
pemrograman atau komputer yang mendasar.
Jika tugas-tugas disaring, maka data harus
disaring juga, didekomposisi atau distruktur, dan
adalah wajar untuk menyaring program dan
spesifikasi data secara paralel” . Abstraksi dan
penyaringan adalah konsep kompementer. Kedua
konsep tersebut membantu desainer dalam
menciptakan suatu model desain lengkap jika
desain berkembang.
3. Modularitas
Modularitas merupakan atribut tunggal
dari perangkat lunak yang memungkinkan
sebuah program untuk dikelola secara intelektual.
Meyer menyebutkan 5 kriteria yang
memungkinkan kita untuk mengevaluasi suatu
metode desain dengan merujuk pada

116
 kemampuannya untuk menentukan sistem
modular yang efektif.
a. Dekomposisi modular.
b. Komposabilitas modular (modular
composability), sebuah metode desain
memungkinkan komponen desain yang
telah ada dirakit ke sebuah sistem baru.
c. Kemampuan pemahaman modular
(modular understandability), sebuah
modul dapat dimengerti sebagai sebuah
unit yang berdiri sendiri dan akan lebih
mudah membangun dan mengubahnya.
d. Kontinuitas modular (modular continuity),
perubahan kecil terhadap kebutuhan
sistem menghasilkan perubahan pada tiap
modul, dibanding perubahan system-wide
e. Proteksi modular (modular protection),
sebuah kondisi aberrant terjadi dalam
sebuah modul dan efeknya di-constrain
dalam modul
4. Arsitektur Perangkat Lunak
Arsitektur perangkat lunak mencakup
struktur keseluruhan perangkat lunak dan cara
dimana struktur memberikan integrasi konseptual

117
 bagi suatu sistem. Shaw dan Garlan menjelaskan
sekumpulan properti yang seharusnya ditetapkan
sebagai bagian dari desain arsitektural :
a. Properti struktural.
Menentukan komponen suatu
sistem dan cara dimana komponen-
komponen tersebut dikemas dan
berinteraksi satu dengan yang lain.
b. Properti ekstra-fungsional.
Menekankan pada bagaimana
arsitektur desain memenuhi persyaratan
kinerja, kapasitas, reliabilitas, keamanan,
adaptibilitas, dan karakteristik sistem yang
lain.
c. Keluarga dari sistem yang berhubungan.
Desain harus memiliki kemampuan
untuk memakai lagi blok bangunan
arsitektural tersebut.
5. Hirarki Kontrol
Hirarki kontrol, disebut juga struktur
program merepresentasikan organisasi
komponen program serta mengimplikasikan
suatu hirarki kontrol. Hirarki kontrol tidak
mengimplikasikan aspek prosedural dari

118
 perangkat lunak, seperti urutan proses,
kejadian/urutan dari keputusan, atau
pengulangan operasi.
6. Partisi Struktural
Struktur progam harus dipartisi baik secara
horizontal maupun vertikal. Partisi horizontal
menentukan cabang-cabang terpisah dari hirarki
modular untuk setiap fungsi program mayor,
keuntungannya :
a. Menghasilkan perangkat lunak yang lebih
mudah diuji.
b. Membawa kepada perangkat lunak yang
lebih mudah dipelihara.
c. Menghasilkan penyebaran efek samping
yang lebih sedikit.
d. Menghasilkan suatu perangkat lunak yang
lebih mudah untuk diperluas.

Partisi vertikal menyatakan bahwa kontrol

dan kerja harus didistribusikan secara top-down
dalam arsitektur program.
7. Struktur Data

119
 Struktur data adalah representasi dari
hubungan logis antara elemen-elemen data
individual.
8. Prosedur Perangkat Lunak
Prosedur perangkat lunak berfokus pada
detail-detail pemrosesan dari masing-masing
modul secara individual. Prosedur harus
memberikan spesifikasi yang teliti terhadap
pemrosesan, mencakup urutan event, poin-poin
keputusan nyata, operasi repetitif, dan organisasi
struktur data.
9. Penyembunyian Informasi
Prinsip penyembunyian informasi
menyatakan bahwa bahwa modul ditandai
dengan keputusan desain tersembunyi dari semua
desain lain.

D. Desain Modular Efektif

Desain modular efektif mudah untuk dibangun,

mudah untuk dirubah dan mudah untuk ditetapkan.
Modular design mereduksi komplesitas masalah,
menyediakan fasilitas untuk melakukan perubahan
(dalam hal pemeliharaan), dan memudahkan

120
implementasi dengan pengembangan paralel dari bagian-
bagian yang berbeda dalam suatu sistem.
1. Module types
Abstraksi dan penyembunyian informasi
dipakai untuk mendefinisikan modul-modul di
dalam lingkungan software architecture. Suatu
modul mungkin dikategorikan sebagai berikut :
a. Sequential module : dieksekusi tanpa
interupsi yang dilakukan software aplikasi.
b. Incremental module : dapat diinterupsi
oleh program aplikasi dan kemudian
kembali ke titik semula setelah interupsi
selesai.
c. Parallel module : dieksekusi secara
simultan dengan modul lain dalam
lingkungan Concurrent multiprocessor.
2. Independensi Fungsional
Konsep functional independence
berkembang dari modularitas dan konsep
abstraksi serta information hiding. Independence
diukur dengan menggunakan 2 kriteria kualitatif,
yaitu cohesion, coupling.
a. Cohesion ( keterpautan )

121
 Suatu modul kohesif membentuk
sebuah tugas tunggal di dalam suatu
software prosedur dan memerlukan sedikit
interaksi dengan prosedur yang dibuat
dalam bagian lain dari suatu program.
1) Coincidental cohesion : sebuah modul
yang membentuk sejumlah tugas
yang berhubungan satu sama lain
dengan longgar.
2) Logically cohesion : sebuah modul
yang membentuk tugas-tugas yang
dihubungkan secara logical.
3) Temporal cohesion : jika sebuah
modul berisi sejumlah tugas yang
dihubungkan dengan segala yang
harus dieksekusi di dalam waktu yang
bersamaan.
4) Procedural cohesion : jika
pemrosesan elemen-elemen dari suatu
modul dihubungkan dan harus
dieksekusi dalam urutan spesifik.
5) Communication cohesion : jika
pemrosesan elemen-elemen

122
 dikonsentrasikan pada satu area dari
suatu struktur data.
b. Coupling (bergandengan)
Coupling merupakan suatu
pengukuran dari keterkaitan atau
keterhubungan antara sejumlah modul
dalam struktur program. Coupling
tergantung pada kompleksitas interface
antar modul.

E. Model Desain

Prinsip dan konsep desain disini dimaksudkan

membangun sebuah fondasi untuk pembuatan model
desain yang mencakup representasi data, arsitektur,
interface, dan prosedural. Seperti model analisis
sebelumnya. Pada model desain, masing-masing
representasi desain diikatkan dengan yang lainnya, dan
semua dapat ditelusuri balik ke persyaratan perangkat
lunak.
Banyak pemrogram terus menerus mendesain
secara implisit, dengan melakukan desain prosedural
pada saat dikodekan. Hal itu sama dengan mengambil
desain piramid dan mendirikannya pada titiknya, hasil

123
 desain yang sangat tidak stabil. Perubahan yang paling
kecil dapat menyebabkan piaramid tersebut (dan
program) tumbang.

F. Dokumentasi Desain

Outline spesifikasi desain :

1. Ruang Lingkup
a. Sasaran sistem.
b. Persyaratan utama software.
c. Batasan-batasan dan pembatasan desain.
2. Desain Data
a. Obyek data dan struktur data resultan.
b. Struktur file dan database.
1) Struktur file eksternal.
a) Struktur logis.
b) Deskripsi record logis.
c) Metode akses.
2) Data global.
3) File dan referensi lintas data.
3. Desain Arsitektural
a. Kajian data dan aliran control.
b. Struktur program yang diperoleh.

124
4. Desain Interface
a. Spesifikasi interface manusia-mesin.
b. Aturan desain interface manusia-mesin.
c. Desain interface eksternal.
1) Interface untuk data eksternal.
2) Interface untuk sistem atau peralatan
eksternal.
5. Desain Prosedural
Untuk masing-masing modul :
a. Naratif pemrosesan.
b. Deskripsi interface.
c. Deskripsi bahasa (atau lainnya) desain.
d. Modul-modul yang digunakan.
e. Struktur data internal.
f. Keterangan/larangan/pembatasan.
6. Persyaratan Lintas Referensi
7. Ketentuan Pengujian
a. Panduan pengujian.
b. Strategi integrasi.
c. Pertimbangan khusus.
8. Catatan Khusus
9. Lampiran

125
 BAB VII

METODE DESAIN

A. Desain Data

Desain data adalah aktivitas pertama dari empat

aktivitas desain yang dilakukan selama rekayasa perangkat
lunak. Pengaruh struktur data pada struktur program dan
kompleksitas prosedural menyebabkan desain data
berpengaruh penting terhadap kualitas perangkat lunak,
konsep penyembunyian informasi dan abstraksi data
memberi dasar pendekatan terhadap desain data.
Tanpa melihat teknik desain yang akan digunakan,
data yang di desain dengan baik dapat membawa kepada
struktur program dan modularitas yang lebih baik, serta
mengurangi kompleksitas prosedural.
Wasserman mengusulkan serangkaian prinsip yang
dapat digunakan untuk menentukan dan mendesain data.
Pada Kenyataannya desain data dimulai selama pembuatan
model analis. Karena analisis persyaratan perangkat lunak
dan desain seringkali overlap. Serangkaian prinsip untuk
spesifikasi data :
1. Prinsip analisis sistematik yang diaplikasikan pada
fungsi dan perilaku seharusnya diaplikasikan juga

126
 pada data. Representasi dari objek data, hubungan,
aliran data, dan isi juga harus dikembangkan dan
dikaji, organisasi data alternatif harus
dipertimbangkan dan pengaruh permodelan data pada
desain perangkat lunak harus dievaluasi.
2. Semua struktur data dan operasi yang akan dilakukan
pada masing – masing struktur data harus
diidentifikasi. Desain dari sebuah struktur data yang
efisien harus mencakup operasi yang akan
dilakukanpada struktur data.
3. Kamus data harus dibangun dan digunakan untuk
menentukan baik data maupun desain program.
Algoritma yang harus memanfaatkan hubungan
khusus dapat lebih mudah ditetapkan jika ada
spesifikasi data yang menyerupai kamus.
4. Keputusan desain data tingkat rendah harus ditunda
sampai akhir proses desain. Proses penyaringan
stepwise dapat digunakan untuk desain basis data,
yaitu keseluruhan organisasi data dapat ditetapkan
selama analisis persyaratan, disaring selama
pengerjaan, desain pendahuluan, dan ditentukan
secara detail selama pengerjaaan pendahuluan dan
itersasi desain selanjutnya.

127
5. Representrasi struktur data hanya boleh diketahui oleh
modul-modul yang harus menggunakan secar
langsung data yang diisikan didalam struktur tersebut.
Konsep penyembunyian informasi dan konsep yang
berkaitan mengenai perangkaian, memberikan
wawasan yang penting mengenai kualitas desain
perangkat lunak.
6. Pustaka struktur data dan operasi yang berna yang
dapat diaplikasikan pada struktur data tersebut harus
dikembangkan. Struktur dan operasi data harusdi
pandang sebagai sumber daya untuk desain perangkat
lunak. Struktur data dapat didesain untuk dapat
digunakan kembali. Tipe data abstrak dapat
mengurangi baik spesifikasi maupun desain data.
7. Desain perangkat lunak dan bahasa pemrograman
harus mendukung spesifikasi dan realisasi dari tipe-
tipe data abstrak. Implementasi struktur data yang
canggih sangat sulit dilakukan jika tidak ada alat untuk
spesifikasi langsung terhadap struktur yang ada.
Prinsip- prinsip tersebut membentuk basis bagi
pendekatan desain data yang dapat diintegrasikan ke dalam
fase definisi dan pengembangan proses rekayasa perangkat
lunak. Definisi yang jelas mengenai informasi sangatlah
penting bagi keberhasilan pengembangan perangkat lunak.

128
B. Desain Arsitektur

Sasaran utama desain arsitektur adalah untuk

mengembangkan struktur program modular dan
merepresentasikan hubungan kontrol antar modul. Desain
arsitektur juga membentuk struktur program dan struktur
data dengan menentukan interface yang memungkinkan
data mengalir melalui program.

Langkah – langkah desain:

1. Jadilah model sistem yang fundamental
2. Kaji dan saringlah diagram aliran data untuk
perangkat lunak.
3. Tentukan apakah DFD memiliki karakteristik aliran
transaksi formasi dan transaksi.
4. Isolasi pusat informasi dengan mengkhususkan batas
aliran masuk dan keluar.
5. Lakukan “pemfaktoran tingkat pertama.”
6. Lakukan “pemfaktoran tingkat kedua.”
7. Saringlah struktur protram iterasi pertama dengan
menggunakan heuristik desain

129
C. Proses Desain Arsitektur

Desain yang berrorientasi pada aliran data merupakan

suatu metode desain arsitektur yang mengizinkan transissi
yang baik dari model analisis deskripsi desain dari struktur
program. Transisi dari aliran informasi (yang di tunjukan
sebagai diagram aliran data) kestruktur dilakukan bagian
dari proses lima langkah :
1. Tiga aliran informasi di bangun.
2. Batas aliran di indikasikan.
3. DFD dipetakan di dalam struktur program.
4. Hirarki control di tentukan dengan pemfaktoran.
5. Struktur resultan di saring atau di perhalus dengan
menggunakan perukuran desain dan heuristic.
Pada bagian ini kita akan mengamati 2 tipe aliran:
1. Aliran Transformasi
Informasi memasuki sistem bersama dengan jalur
yang menstransformasikan data eksternal ke dalam
bentuk internal dan akan di definisikan sebagai aliran
masuk.pada inti perangkat lunakterjadi transisi. Data
yang masuk di lewatkan melalui pusat transformasi dan
mulai bergerak sepanjang jalur yangs sekarang
mengarah keluar dari perangkat lunak. Data yag
mengalir di sepanjang jalur-jalur disebut aliran

130
 keluar.keseluruhan aliran data terjadi dalam cara yang
berurutan dn mengikuti satu atau hanya beberapa jalur
“garis lurus”. Bila segmen dari diagram aliran data
menunjukan karakteristik tersebut, maka distu ada
aliran transformasi
2. Aliran Transaksi
Aliran transaksi ditandai dengan pergerakan data
sepanjang jalur masuk yang mengkonfersi informasi
dunia eksternal kedalam suatu transaksi. Transaksi
tersebut dievaluasi, berdasarkan nilai, aliran sepanjang
satu dari beberapa jalur aksi diinisiasi. Pusat aliran
informasi dari mana banyak jalur aksi berasa disebut
pusat transaksi

D. Pasca Pemrosesan Arsitektur

Aplikasi dari pemetaan transaksi dan transformasi

yang berhasil kemudian ditambahkan pada dokumentasi
tambahan yang dibutuhkan sebagai bagian dari desain
arsitektur. Setelah struktur dikembangkan dan disaring,
tugas – tugas berikut harus dilakukan:
1. Mengembangkan narasi pemerosesan untuk masing –
masing modul.

131
 2. Menyediakan deskripsi interface untuk masing –
masing modul.
3. Menentukan struktur data local dan global.
4. Mencatat semua batasan desain.
5. Mengkaji desain.
6. Mempertimbangkan “optimasi” (bila perlu dan
dibenarkan).

E. Desain Interface

Memberikan suatu gambaran mengenai struktur program

kepada perekayasa perangkat lunak. Fokus Desain
Interface :
1. Desain interface antar modul
2. Desain interface antara perangkat lunak dan entitas
eksternal (produser & konsumen)
3. Desain interface manusia dengan computer

F. Desain Interface Manusia-Mesin

Ada empat model yang berbeda pada saat manusia-

komputer/ human-komputer interface (HCL) akan
didesain. Perekayasa perangkat lunak menciptakan sebuah
model desain, perekayasa perangkat lunak membangun

132
model pemakai, pemakai akhir mengembangkan citra
mental yang sering disebut user’s model atau perception,
dan implementer sistem menciptakan system image.
Model desain dari keseluruhan sistem
menggabungkan data, arsitektur, interface, dan
representasi prosedural dari perangkat lunak.
Model pemakai menggambarkan profil para pemakai akhir
dari sistem. Untuk membangun interface pemakai yang
efektif, semua desain harus dimulai dengan suatu
pemahaman terhadap pemakai yang dimaksudkan,
meliputi profil, usia, jenis kelamin.
Para pemakai juga dapat dikategorikan sebagai:
1. Orang baru
2. Pemakai intermiten yang banyak pengetahuan
3. Pemakai yang banyak pengetahuan dan sering
Persepsi sistem (model pemakai) merupakan citra
sistem yang ada dikepala seorang pemakai akhir. Sebgai
contoh, bila pemakai pengelola kata tersebut, persepsi
sistem akan menuntun respon tersebut.
Citra sistem merangkai manifestasi bagian luar dari
sistem berbasis computer (tampilan luar dan “rasa”
interface), dengan semua informasi yang mendukung
(buku-buku, manual, pita video) yang menggambarkan
sintaksis dan semantik sistem.

133
G. Desain Prosedural

Desain prosedural terjadi setelah data, desain

arsitektur dan interface dibangun. Dalam dunia yang ideal,
spesifikasi prosedural diperlukan untuk menetapkan detail
algoritma yang akan dinyatakan dalam suatu bahasa ibu,
seperti bahasa inggris. Desain prosedural harus
menentukan detail desain prosedural tanpa ada ambiguitas.
Ciri – ciri program yang baik/ terstruktur :
1. Dapat dijalankan dengan baik dan benar.
2. Dapat dijalankan secara efektif dan efisien dengan tidak
banyak menggunakan syntaks yang tidak perlu
3. Mudah di baca dan dipahami oleh orang lain maksud
dan tujuan objek yang akan ditampilkan.
4. Mudah diperbaiki jika terjadi kesalahan.
5. Biaya pengujian yang dibutuhkan rendah.
6. Memiliki dokumentasi yang baik
7. Biaya perawatan dan dokumentasi yang dibutuhkan
rendah.
8. Program hanya terdiri dari tiga struktur kontrol. Yaitu
struktur urut, struktur seleksi, dan sturkutr repetisi atau
reiterasi.

134
H. Coding

Bahasa Desain Program (atau disingkat PDL) adalah

metode untuk merancang dan mendokumentasikan metode
dan prosedur dalam perangkat lunak. Ini terkait dengan
pseudocode, tetapi tidak seperti pseudocode, ini ditulis
dalam bahasa sederhana tanpa istilah apa pun yang dapat
menyarankan penggunaan bahasa pemrograman atau
pustaka apa pun.
PDL awalnya dikembangkan oleh perusahaan Caine,
Farber & Gordon dan telah dimodifikasi secara substansial
sejak mereka menerbitkan makalah awal mereka pada
tahun 1975.

135
 BAB VIII

TEKNIK PENGUJIAN PERANGKAT LUNAK

A. Dasar-dasar Pengujian Perangkat lunak

Objektifitas Pengujian
1. Test case yang baik adalah yang mempunyai
probabilitas yg tinggi untuk menemukan error yang
tak ditemukan.
2. Pengujian merupakan suatu proses eksekusi program
yang ditujukan untuk menemukan error.
3. Uji yang sukses adalah yang dapat membuka error
yang tak ditemukan.

Dua kelas input yang disediakan untuk proses uji perangkat

lunak adalah :
1. Konfigurasi software, termasuk Software
Requirement Specification, Design Specification dan
Source code.
2. Konfigurasi uji, termasuk Test Plan & Procedure,
perangkat testing yang akan digunakan, test case dan
hasil yang diharapkan.

136
B. Desain Test Case

Pendekatan pengujian blackbox dan whitebox.

1. Pengujian Blackbox :
a. Berkaitan dengan pengujian pada interface PL.
b. Blackbox testing menyinggung ujicoba yang
dilakukan.
c. pada interface software.
d. Blackbox testing didesain untuk menemukan
kesalahan.
e. Blackbox testing digunakan untuk
mendemonstrasikan fungsi software yang
dioperasikan.
f. Blackbox testing sedikit memeriksa struktur logika
internal software.

2. PengujianWhitebox :
a. Didasarkan pada pemeriksaan detail prosedural.
b. Whitebox testing akan menghasilkan program
yang 100% benar.
c. Whitebox testing dilakukan pada alur logika yang
penting.

137
 d. Alur logika software diujicoba dengan
menyediakan kasus ujicoba dengan melakukan
sekumpulan kondisi atau perulangan.

C. Pengujian White Box

Pengujian ke white box testing adalah menguji yang

didasarkan kepada pengecekan ke dalam detail rancangan,
penggunaan yang dilakukan struktur kontrol dari suatu
desain pemrograman untuk dapat membagi pengujian ke
beberapa kasus pengujian. Dan didapat bahwa white box
testing menggunakan petunjuk untuk menghasilkan
program yang diharapkan dan efisien.
Pengujian yang didasarkan pada detail prosedur dan
alur logika kode program. Pada kegiatan whitebox testing,
tester melihat source code program dan menemukan bugs
dari kode program yang diuji. Intinya whitebox testing
adalah pengujian yang dilakukan sampai kepada detail
pengecekan kode program.

Kegiatan Tester :
Melihat kode program -> membuat test case untuk
mencari kesalahan / bugs / error dari kode program yang
dibuat oleh programmer.

138
 Metode pengujian pada white box testing ini
seringkali dilakukan untuk:
1. Memberikan dan membuat suatu jaminan bahwa
seluruh jalur-jalur yang independen hanya
menggunakan modul minimal satu kali.
2. Keputusan yang sifatnya logis dapat digunakan di
semua kondisi true (benar) atau false (salah).
3. Mengeksekusi seluruh perulangan yang ada ke pada
batas nilai dan operasional di setiap situasi dan kondisi.
4. Syarat yang dilakukan dalam menjalankan strategi
white box testing
5. Mendefinisikan tentang seluruh alur-alur logika yang
ada.
6. Membangun dan membuat suatu kasus yang akan
digunakan untuk tahap pengujian.
7. Hasil pengujian yang telah didapatkan akan dilakukan
evaluasi kembali.
8. Pengujian yang dilakukan haruslah secara menyeluruh.

Kasus yang sering menggunakan white box testing diuji

dalam beberapa tahapan:
1. Uji semua keputusan dengan logika.
2. Tes semua loop yang tersedia dengan batasan-
batasannya.

139
 3. Tes untuk struktur data internal dan terjamin
validitasnya.

Kelebihan White Box Testing yaitu:

1. Efisien dalam menemukan kesalahan dan masalah.
2. Diperlukan pengetahuan tentang internal perangkat
lunak yang sedang diuji bermanfaat untuk pengujian
menyeluruh.
3. Memungkinkan menemukan kesalahan tersembunyi.
4. Membantu mengoptimalkan kode.

Kelemahan White Box Testing yaitu:

1. Membutuhkan pengetahuan tingkat tinggi dari
perangkat lunak internal yang sedang diuji.
2. Membutuhkan akses kode.

D. Pengujian Basis Path

1. Pengujian basis path adalah teknik pengujian whitebox

pertama yang diusulkan Tom McCabe (1976).
2. Basis path memungkinkan desainer test case mengukur
kompleksitas logis dari desain procedural dan
pengukuran ini dijadikan pedoman dalam pendefinisian
sekumpulan basis dari jalur eksekusi.
3. Yang termasuk basis path test :

140
 a. Notasi Diagram Alir (Path Graph Notation)
b. Kompleksitas Siklomatik
c. Test Case
d. Matriks Grafik (Graph Matrices)
Metode identifikasi yang berdasarkan pada jalur,
struktur atau koneksi yang ada dari suatu sistem umumnya
disebut sebagai tes cabang karena cabang kode atau fungsi
logika diidentifikasi dan diuji, atau bahkan tes kontrol
aliran.
Ada 2 bentuk Basis Path, yaitu:
1. Zero Path: Jalur tautan yang tidak perlu atau tautan yang
ada pada suatu sistem.
2. One Path: Jalur penting atau proses koneksi dalam suatu
sistem.

E. Pengujian Struktur Kontrol

Pengujian struktur kontrol adalah desain test case

yang menggunakan kondisi logisyang ada pada suatu
program.
Contoh :
Kondisi sederhana dari persamaan relasional
E1 (Operator relasional) E2
E1 dan E2 merupakan persamaan matematika

141
 Operator Relasional adalah sasalah satu dari operator
berikut ini :
<, ≤, =, ≠ ( – = ), >, ≥

Operator Boolean : OR (‘│’), AND (‘&’), NOT (‘-‘)

Setiap bahasa pemrograman memiliki kemampuan

untuk melakukan pengujian kondisi agar program dapat
berjalan dinamis dan interaktif. Untuk menguji setiap
kondisi, diperlukan pembanding yang bisa sama dengan,
lebih besar, lebih kecil, atau tidak sama dengan lainnya.
Untuk mengujinya dibutuhkan operator yang dapat
menyatakan kondisi tersebut, yaitu dengan operator :
< Lebih kecil
> Lebih besar
<= Lebih kecil & sama dengan
>= Lebih besar & sama dengan
= = Sama dengan
!= Tidak sama dengan

F. Pengujian Black Box

Black Box Testing atau yang sering dikenal dengan

sebutan pengujian fungsional merupakan metode

142
pengujian Perangkat Lunak yang digunakan untuk menguji
perangkat lunak tanpa mengetahui struktur internal kode
atau Program. Dalam pengujian ini, tester menyadari apa
yang harus dilakukan oleh program tetapi tidak memiliki
pengetahuan tentang bagaimana melakukannya.
Pengujian yang didasarkan pada detail aplikasi seperti
tampilan aplikasi, fungsi-fungsi yang ada pada aplikasi,
dan kesesuaian alur fungsi dengan bisnis proses yang
diinginkan oleh customer. Pengujian ini tidak melihat dan
menguji souce code program.
Kegiatan Tester :
1. Membuat test case untuk menguji fungsi-fungsi yang
ada pada aplikasi.
2. Membuat test case untuk menguji kesesuaian alur kerja
suatu fungsi di aplikasi dengan requirement yang
dibutuhkan customer untuk fungsi tersebut.
3. Mencari bugs / error dari tampilan (interface) aplikasi.

Kelebihan Black Box Testing yaitu:

1. Efisien untuk segmen kode besar
2. Akses kode tidak diperlukan
3. Pemisahan antara perspektif pengguna dan pengembang
Kelemahan Black Box Testing yaitu:

143
1. Cakupan terbatas karena hanya sebagian kecil dari
skenario pengujian yang dilakukan
2. Pengujian tidak efisien karena keberuntungan tester dari
pengetahuan tentang perangkat lunak internal

144
 BAB IX

STRATEGI PENGUJIAN PERANGKAT LUNAK

Dalam strategi pengujian perangkat lunak dapat

digambarkan dengan ilustrasi berikut: Sebuah perangkat lunak
dimulai dari penentuan kebutuhan perangkat lunak, kemudian
prose dilanjutkan ke dalam bentuk rancangan, dan akhirnya ke
pengkodean.
Strategi pengujian serupa dengan halt ersebut, dimulai
dengan unit testing di pusat spiral di mana masing-
masingmodul/unit dari perangkat lunak yang
diimplementasikan dalam source code menjadi sasaran
pengujian. Kemudian dilakukan integration testing dengan
focus pengujian adalah desain dan kontruksi arsitektur
perangkat lunak. Selanjutnya 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 sistem diuji.

A. Pendekatan strategis ke pengujian perangkat lunak

Pengujian merupakan rangkaian aktivitas yang dapat

direncanakan sebelumnya dan dilakukansecara sistematis.

145
Strategi uji coba perangkat lunak memudahkan para
perancang untuk menentukan keberhasilan system yang
telah dikerjakan. Hal yang harus diperhatikan adalah
langkah-langkah perencanaan dan pelaksanaan harus
direncanakan dengan baik dan berapa lama waktu, upaya
dan sumber daya yang diperlukan strategi uji coba
mempunyai karakteristik sebagai berikut:
a. Pengujian mulai pada tingkat modul yang paling bawah,
dilanjutkan dengan modul di atasnya kemudian hasilnya
dipadukan.
b. Teknik pengujian yang berbeda mungkin menghasilkan
sedikit perbedaan (dalam hal waktu).
c. Pengujian dilakukan oleh pengembang perangkat lunak
dan (untuk proyek yang besar) suatu kelompok
pengujian yang independen.
d. Pengujian dan debugging merupakan aktivitas yang
berbeda, tetapi debugging termasuk dalam strategi
pengujian.

1) Verifikasi dan validasi

Verifikasi dan validasi merupakan dua istilah yang
sering dikaitkan dengan tahapan pengujian perangkat
lunak. Verifikasi mengacu pada serangkaian aktivitas
untuk memastikan bahwa perangkat lunak

146
mengimplementasikan fungsi tertentu secara benar,
sedangkan validasi mengacu pada serangkaian aktivitas
untuk memastikan bahwa perangkat lunak yang telah
dibuat sesuai dengan kebutuhan konsumen.
Definisi V&V mencakup serangkaian aktivitas dari
penjaminan kualitas perangkat lunak (SQA) yangmeliputi
kajian teknis formal, audit kualitas dan control, monitoring
kinerja, simulasi, studi feasibilitas, kajian dokumentasi,
kajian basis data, analisis algoritma, pengujian
pengembangan, pengujian kualifikasi, dan pengujian
instalasi.

Pengorganisasian Pengujian Perangkat Lunak

Proses pengujian sebuah perangkat lunak sebaiknya
melibatkan pihak yang memang secara khusus
bertanggung jawab untuk melakukan proses pengujian
secara independen. Untuk itulah diperlukan Independent
Test Group (ITG). Peran dari ITG adalah untuk
menghilangkan “conflict of interest” yang terjadi ketika
pengembang perangkat lunak berusaha untuk menguji
produknya sendiri.
Walaupun seperti itu, sering terjadi beberapa
kesalahan pemahaman berkaitan dengan peran ITG, antara
lain:

147
 a. Pengembang tidak boleh melakukan pengujian sama
sekali. Pendapat ini tidak 100% benar, karena dalam
banyak kasus, pengembang juga melakukan proses unit
testing dan integration test.
b. Perangkat lunak dilempar begitu saja untuk diuji secara
sporadic. Hal tersebut adalah salah karena pengembang
dan ITG bekerja sama pada kesalahan proyek untuk
memastikan pengujian akan dilakukan. Sementara
pengujian dilakukan, pengembang harus memperbaiki
kesalahan yang ditemukan.
c. Penguji tidak terlibat pada proyek sampai tahap
pengujian dimulai. Hal tersebut salah karena ITG
merupakan bagian dari tim proyek pengembangan
perangkat lunak dimana ia terlihat selama spesifikasi
proses dan tetap terlihat pada keseluruhan proyek besar.

B. Pengujian Unit

Unit testing (uji coba unit) fokusnya pada usaha

verifikasi pada unit terkecil dari desain perangkat lunak,
yakni modul. Uji coba unit selalu berorientasi pada white
box testing dan dapat dikerjakan paralel ayau beruntun
dengan modul lainnya.

1) Pertimbangan Pengujian Unit

148
 Interface modul diuji untuk memastikan bahwa
informasi secara tepat mengalir masuk dan keluar dari
inti program yang diuji. Struktur data local diuji untuk
memastikan bahwa data yang tersimpan secara
temporal dapat tetap menjaga integritasnya selama
semua langkah langkah di dalam suatu algoritma
dieksekusi. Kondisi batas diuji untuk memastikan
bahwa modul beroperasi dengan tepat pada batas yang
ditentukan untuk membatasi pemrosesan. Semua jalur
independen (jalur dasar) yang melalui struktur control
dipakai sedikirnya satu kali. Dan akhirnya penanganan
kesalan diuji.

2) Prosedur Pengujian Unit

Sumber telah dikembangkan, ditunjang kembali
dan diverifikasi untuk sintaksnya, maka perancangan
test case dimulai. Peninjauan kembali perancangan
informasi akan menyediakan petunjuk untuk
menentukan testcase. Karena modul bukan program yg
berdiri sendiri maka driver (pengendali) dan atau stub
perangkat lunak harus dikembangkan untuk pengujian
unit.
Driver adalah program yang menerima data untuk
test case dan menyalurkan ke modul yang diuji dan

149
 mencetak hasilnya. Stub melayani pemindahan modul
yg akan dipanggil untuk diuji.

C. Pengujian Integrasi

Pengujian terintegrasi adalah teknik yg sistematis

untuk penyusunan struktur program, pada saat dikerjakan
uji coba untuk memeriksa kesalahan yang nantinya
digabungkan dengan interface. Metode pengujian:
1. Top down integration
Merupakan pendekatan inkrmental untuk
penyusunan struktur program. Modul dipadukan
dengan bergerak ke bawah melalui kontrol hirarki
dimulai dari modul utama. Modul subordinat ke modul
kontrol utama digabungkan ke dalam struktur baik
menurut depth first atau breadth first.

Proses integrasi:
a. Modul utama digunakan sebagai test driver dans
tub yang menggantikan seluruh modul yang secara
langsung berada di bawah modul kontrol utama.
b. Tergantung pada pendekatan perpaduan yang
dipilih (depth / breadth)
c. Uji coba dilakukan selama masing-masing modul
dipadukan

150
 d. Pada penyelesaian masing-masing uji coba stub
yang lain dipindahkan dengan modul sebenarnya.
e. Uji coba regression yaitu pengulangan pengujian
untuk mencari kesalahan lain yang mungkin
muncul.

2. Buttom up integration
Pengujian buttom up dinyatakan dengan
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
a. Modul tingkat bawah digabungkan ke dalam
cluster yang memperlihatkan subfungsi perangkat
lunak.
b. Driver (program kontrol pengujian) ditulis untuk
mengatur input test case dan output.
c. Cluster diuji.
d. Driver diganti dan cluster yang dikombinasikan
dipindahkan ke atas pada struktur program.

151
D. Pengujian Validasi

Setelah semua kesalahan diperbaiki maka langkah

selanjutnya adalah validasi tertinggi. Pengujian validasi
dikatakan berhasil bila fungsi yang ada pada perangkat
lunak sesuai dengan yang diharapkan pemakai. Validasi
perangkat lunak merupakan kumpulan seri uji coba black
box yang menunjukkan sesuai dengan yang diperlukan.

Kemungkinan kondisi setelah pengujian:

1. Karakteristik performansi fungsi sesuai dengan
spesifikasi dan dapat diterima.
2. Penyimpangandari spesifikasi ditemukan dan
dibuatkan daftar penyimpangan.

Pengujian BETA dan ALPHA

Apabila perangkat lunak dibuat untuk pelanggan
maka dapat dilakukan aceeptance test sehingga
memungkinkan pelanggan untuk memvalidasi seluruh
keperluan. Test ini dilakukan karena memungkinkan
pelanggan menemukan kesalahan yang lebih rinci dan
membiasakan pelanggan memahami perangkat lunak
yang telah dibuat.

Pengujian Alpha

152
 Dilakukan pada sisi pengembang oleh seorang
pelanggan. Perangkat Lunak digunakan pada setting yang
natural dengan pengembang “yang memandang” melalui
bahu pemakai dan merekam semua kesalahan dan
masalah pemakaian

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

E. Pengujian Sistem

Pada akhirnya perangkat lunak digabungkan dengan

elemen system lainnya dan rentetan perpaduan system 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 perangkat lunak dan
system yang besar merupakan kuncinya.

153
 Sistem testing merupakan rentetan pengujian yang
berbeda-beda dengan tujuan utama mengerjakan
keseluruhan elemen system yang dikembangkan.

1) Recovery Testing
Adalah system testing yang memaksa perangkat lunak
mengalami kegagalan dalam bermacam-macam cara dan
apakah perbaikan dilakukan dengan tepat.

2) Security Testing
Adalah pengujian yang akan melalukan verifikasi dari
mekanisme perlindungan yang akan dibuat oleh system,
melindungi dari hal-hal yang mungkin terjadi.

3) Strees Testing
Dirancang untuk menghadapi situasi yang 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 fekuensi.

F. Debugging

Debugging bukan merupakan pengujian, namun

merupakan konsekuensi dari pengujian yang berhasil. Jika
sebuah kasus uji berhasil menemukan kesalahan, maka

154
proses debugging bertujuan untuk menghilangkan
kesalahan tersebut.
Debugging merupakan proses yang sulit untuk
dilakukan karena adanya beberapa karakteristik bug
seperti:
1. Gejala dan penyebab dari bug bisa saja sangat jauh,
gejala dapat muncul pada bagian tertentu dari program
dan penyebabnya bisa saja berada pada bagian lain yang
sangat jauh dari tempat munculnya gejala.
2. Gejala dapat hilang ketika kesalahan yang lain
diperbaiki
3. Gejala dapat ditimbulkan oleh sesuatuyang tidak salah
(mis. Pembulatan yang tidak akurat).
4. Gejala dapat disebabkan oleh masalah timing.
5. Kemungkinan sulit untuk memproduksi kondisi onput
secara akurat.
6. Gejala dapat terjadi tiba-tiba.
7. Gejala dapat disebabkan oleh sesuatu yang
didistribusikan melewati sejumlah tugas yang bekerja
pada prosesor yang berbeda-beda.

Terdapat 3 jenis pendekatan debugging, antara lain:

a. Brute Force

155
 Merupakan teknik yang paling sering digunakan
dan paling tidak efisien dalam mengisolasi penyebab
kesalahan. Dengan prinsip “biarkan computer
menemukan kesalahan”, maka seluruh sumber daya
computer digunakan dengan tujuan untuk menemukan
penyebab kesalahan

b. Backtracking
Merupakan pendekatan yang dimulaidari
penemuan gejala kemudian menelusuri balik hingga ke
penyebab.

c. Cause Elimination
Dimanifestasikan oleh induksi atau deduksi dan
menggunakan konsep partisi biner. Data yang
berhubungan dengankesalahan yang muncul
dikumpulkan untuk mengisolasi penyebab. Kemudian
dibuat sebuah hipotesis dan data digunakan untuk
membuktikan hipotesis tersebut. Daftar rangkaian
penyebab yang mungkin dibuat dan dilakukan
pengujian untuk mengeliminasi penyebab-penyebab
tersebut. Jika pengujian menunjukkan kebenaran
hipotesis untuk suatu penyebab, maka data diperbaiki
untuk mengisolasi bug. Sekali bug ditemukan, bug
harus diperbaiki. Namun, perbaikan pada bug dapat

156
 memunculkan kesalahan lain, maka ada beberapa
pertimbangan sebelum bug dihilangkan antara lain:
1) Apakah penyebab bug ada pada bagianlain dari
program?
2) Apakah “bug yang lain” mungkin terjadipada saat
perbaikan dilakukan?
Apakah yang telah dilakukan untukmencegah bug pada
tempat pertama?

157
 BAB X

PEMELIHARAAN PERANGKAT LUNAK

A. Konsep Pemeliharaan Perangkat Lunak

1. Definisi Pemeliharaan Perangkat Lunak

Pemeliharaan perangkat lunak adalah proses
umum pengubahan/pengembangan perangkat lunak
setelah diserahkan ke konsumen. Perubahan mungkin
berupa perubahan sederhana untuk membetulkan error
koding atau perubahan yg lebih ekstensif untuk
membetulkan error perancangan/perbaikan signifikan
untuk membetulkan error spesifikasi/akomodasi
persyaratan baru. (Mirza, 2015)
Aktivitas yang terjadi pada pase pemeliharaan
antara lain:
a. Aktifitas Penambahan perbaikan produk
perangkat lunak :
1) Penambahan fungsi-fungsi baru
2) Perbaikan tampilan dan modus interaktif
3) Memperbaharui dokumen eksternal
4) Memperbaharui karakteristik
performansi dan sistem

158
b. Adaptasi produk dengan lingkungan
operasional yang baru:
1) pemindahan perangkat lunak ke
perangkat keras yang lain
2) modifikasi untuk dapat mempergunakan
protokol tambahan dll
c. Pembetulan permasalahan yang timbul :
Pembenaran kesalahan yang timbul
setelah produk perangkat lunak dipergunakan
oleh user Biasanya 70 % dari seluruh biaya
pengembangan adalah untuk pemeliharaan.
Dari seluruh biaya pemeliharaan, 60 %
digunakan untuk anggaran penambahan atau
perbaikan perangkat lunak, sisanya untuk
adaptasi atau pembentulan.

Karakteristik perangkat lunak yang mudah

dalam pemeliharaan :
a. Perangkat lunak dikerjakan per modul
b. Perangkat lunak mempunyai kejelasan
c. Dokumentasi internal yang baik dan jelas
d. Dilengkapi dokumen-dokumen pendukung
lainnya

159
 Pemeliharaan juga mempengaruhi dokumen
pendukung seperti :
a. dokumen spesifikasi kebutuhan perangkat
lunak
b. dokumen rancangan
c. dokumen rencana pengujian
d. prinsip pengoperasian
e. petunjuk pemakaian

2. Manfaat pemeliharaan perangkat lunak

a. Memastikan kesesuaian dengan kebutuhan
fungsionalitas teknis software.
b. Memastikan kesesuaian kebutuhan pihak
manajerial mengenai jadwal dan budget.
c. Dapat meningkatkan efisiensi software
berikut juga aktifitas pemeliharaannya.

B. Siklus Hidup Pemeliharaan Sistem (SMLC)

Siklus Hidup Pemeliharaan Sistem (SMLC)

terdiri dari 3 tahapan yaitu :
a. Tahapan SMLC :
1) Memahami Permintaan Pemeliharaan

160
 2) Mentransformasi permintaan
pemeliharaan menjadi pengubahan
3) Menspesifikasi perubahan
4) Mengembangkan perubahan
5) Menguji perubahan
6) Melatih pengguna dan melakukan test
penerimaan
7) Pengkonversian dan meluncurkan
operasi
8) Mengupdate Dokumen
9) Melakukan pemeriksaan Pasca
implementasi
b. Maintainability (Kemampuan pemeliharaan
sistem)
1) Prosedur untuk peningkatan
maintainability :
a) Menerapkan SDLC dan SWDLC
b) Menspesifikasi definisi data standar
c) Menggunakan bahasa pemrograman
standart
d) Merancang modul-modul yang
terstruktur dengan baik
e) Mempekerjakan modul yang dapat
digunakan kembali

161
 f) Mempersiapkan dokumentasi yang
jelas, terbaru dan komprehensif
g) Menginstall perangkat lunak,
dokumentasi dan soal-soal test di
dalam sentral repositor sistem
CASE atau CMS (change
management system)
Tiga pendekatan untuk menyusun
Pemeliharaan sistem :
1) Pendekatan Pemisahan --> Pemeliharaan
dan Pemeliharaan
2) Pendekatan Gabungan -->
Menggabungkan personalia penyusun
dan pemelihara menjadi sebuah
kelompok utama sistem informasi
3) Pendekatan Fungsional --> Variasi dari
pendekatan gabungan dengan
memindahkan tenaga profesional sistem
dari sistem informasi dan menugasi
mereka pada fungsi bisnis untuk
penyusunan maupun pemeliharaan.
Ada 5 CASE Tools yang membantu
pemeliharaan sistem dari sistem lama dan

162
 membantu memecahkan kemacetan timbunan
sistem baru yang belum dikerjakan :
1) Rekayasa Maju (Forward engineering)
2) Rekayasa Mundur (Reverse engineering)
3) Rekayasa Ulang (Reengineering)
4) Restrukturisasi (restrukturing)
5) Sistem Pakar Pemeliharaan
(Maintenance expert system)
c. Mengelola Pemeliharaan Sistem
Dalam mengelola pemeliharaan sistem
baik itu rekayasa maju, mundur, ulang dan
restrukturisasi terdapat beberapa tahapan
yang harus diperhatikan. Tahapan
pengelolaan terhadap pemeliharaan sistem
(perangkat lunak), meliputi:
1) Menetapkan Kegiatan Pemeliharaan
Sistem
2) Mengawali dan merekam kegiatan
pemeliharaan sistem tidak terjadwal
(Form Maintenance Work Order :
Pekerjaan yang diperlukan/dilakukan,
waktu yang diperkirakan dibandingkan
dengan waktu yang sebenarnya, kode
pemeliharaan, biaya pemeliharaan)

163
 3) Menggunakan sistem perangkat lunak
helpdesk
4) Mengevaluasi aktivitas pemeliharaan
sistem
5) Mengoptimalkan program pemeliharaan
sistem
Sedangkan Resiko CMS yang harus dihindari,
antara lain:
a. Kekurangan inventaris program perangkat
lunak yang akurat dan sumber-sumber
sistem informasi lainnya.
b. Ketidak lengkapan sejarah perubahan
program
c. Modul-modul program perangkat lunak
terduplikasi
d. Perubahan program perangkat lunak yang
tidak sah
e. Kekurangan dokumentasi yang jelas,
komprehensif dan terbaru
f. Rendahnya kualitas dan reabilitas
perangkat lunak

164
C. Teknik Pemeliharaan Perangkat Lunak

1. Pemeliharaan Korektif
Ini termasuk modifikasi dan perbaruan yang
dilakukan untuk memperbaiki atau memperbaiki
masalah, yang ditemukan oleh pengguna atau
disimpulkan oleh laporan kesalahan pengguna.
Pemeliharaan korektif berkaitan dengan perbaikan
kesalahan atau cacat yang ditemukan pada fungsi
sistem sehari-hari. Kerusakan dapat terjadi karena
kesalahan dalam desain perangkat lunak, logika dan
pengkodean. Kesalahan desain terjadi ketika
perubahan yang dilakukan pada perangkat lunak tidak
benar, tidak lengkap, salah dalam
mengkomunikasikan, atau permintaan perubahan
disalah pahami. Kesalahan logis dihasilkan dari
pengujian dan kesimpulan yang tidak valid,
implementasi spesifikasi desain yang salah, aliran
logika yang salah, atau uji data yang tidak lengkap.
Semua kesalahan ini, disebut sebagai kesalahan
residual, mencegah perangkat lunak untuk memenuhi
spesifikasi yang disepakati. Perhatikan bahwa
kebutuhan pemeliharaan korektif biasanya dimulai
oleh laporan bug yang dibuat oleh pengguna.

165
 Dalam hal terjadi kegagalan sistem karena
adanya kesalahan, tindakan diambil untuk
mengembalikan operasional sistem perangkat lunak.
Pendekatan dalam pemeliharaan korektif adalah
dengan menemukan spesifikasi asli untuk
menentukan apa yang semula dirancang untuk
dilakukan oleh sistem. Namun, karena tekanan dari
manajemen, tim pemeliharaan terkadang
menggunakan perbaikan darurat yang dikenal sebagai
penambalan. Pemeliharaan korektif menyumbang
20% dari semua kegiatan pemeliharaan.

2. Pemeliharaan Adaptif
Pemeliharaan Adaptif terjadi karena
pertumbuhan atau perkembangan perangkat lunak
atau perangkat keras sehingga memerlukan
modifikasi dari perangkat lunak yang telah dibuat. Ini
termasuk modifikasi dan pembaruan yang diterapkan
untuk menjaga agar produk perangkat lunak tetap
mutakhir dan disesuaikan dengan dunia teknologi dan
lingkungan bisnis yang terus berubah. Pemeliharaan
adaptif adalah implementasi perubahan di bagian
sistem, yang telah dipengaruhi oleh perubahan yang
terjadi di bagian lain pada sistem. Pemeliharaan

166
 adaptif terdiri dari aktifitas mengadaptasi perangkat
lunak untuk perubahan di lingkungan seperti
perangkat keras atau sistem operasi.
Istilah lingkungan dalam konteks ini mengacu
pada kondisi dan pengaruh yang terjadi (dari luar)
pada sistem. Misalnya, aturan bisnis, pola kerja, dan
kebijakan pemerintah memiliki dampak signifikan
pada sistem perangkat lunak. Misalnya, kebijakan
pemerintah untuk transaksi hanya menggunakan 'mata
uang Rupiah' akan memiliki efek signifikan pada
sistem perangkat lunak. Penerimaan perubahan ini
akan meminta bank dalam negeri untuk membuat
perubahan signifikan dalam sistem perangkat lunak
mereka untuk mengakomodasi mata uang ini. Akun
pemeliharaan adaptif untuk 25% dari semua kegiatan
pemeliharaan.
3. Pemeliharaan perfektif
Pemeliharaan Perfective terutama berkaitan
dengan penerapan persyaratan pengguna yang baru
atau diubah. Pemeliharaan Perfective mencakup tugas
melakukan peningkatan fungsional padasistem di
samping aktifitas untuk meningkatkan kinerja bahkan
ketika perubahan belum disarankan oleh adanya
kesalahan. Ini termasuk meningkatkan fungsi dan

167
 efisiensi kode serta mengubah fungsi sistem sesuai
kebutuhan pengguna yang berubah-ubah.
Contoh pemeliharaan Perfective termasuk
memodifikasi program penggajian untuk
memasukkan item perubahan komponen pembayaran
dan menambahkan laporan baru dalam sistem analisis
penjualan. Pemeliharaan Perfective menyumbang
sebesar 50%, yaitu yang terbesar dari semua kegiatan
pemeliharaan.
4. Pemeliharaan Prefentif
Pemeliharaan Prefentif ini termasuk modifikasi
dan perbaruan untuk mencegah masalah perangkat
lunak di masa mendatang. Hal ini bertujuan untuk
menghadapi masalah, yang tidak signifikan pada saat
ini tetapi dapat menyebabkan masalah serius di masa
depan. Pemeliharaan preventif melibatkan kegiatan
untuk mencegah terjadinya kesalahan. Ini cenderung
mengurangi kompleksitas perangkat lunak sehingga
meningkatkan pemahaman terhadap program dan
meningkatkan pemeliharaan perangkat lunak. Ini
terdiri dari pembaruan dokumentasi, optimisasi kode,
dan restrukturisasi kode. Pembaruan dokumentasi
melibatkan modifikasi dokumen yang dipengaruhi
oleh perubahan agar sesuai dengan kondisi sistem saat

168
 ini. Optimasi kode melibatkan memodifikasi program
untuk eksekusi yang lebih cepat atau penggunaan
ruang penyimpanan yang efisien. Restrukturisasi kode
melibatkan transformasi struktur program untuk
mengurangi kompleksitas dalam kode sumber dan
membuatnya lebih mudah untuk dipahami.

D. Aktivitas Selama Pemeliharaan

1. Permasalahan Selama Pemeliharaan

Tujuan utama pengembangan adalah
menghasilkan sistem yang dapat terus bertahan.
Tingginya biaya pemeliharaan adalah karena sejumlah
masalah yang tercantum di bawah ini:
a. Perawatan dipandang tidak sama
berharganya dengan aktifitas
pengembangan sistem. Hal ini dianggap
selesai cukup dengan keterampilan atau
pengalaman.
b. Pengguna tidak sepenuhnya sadar akan
masalah pemeliharaan atau biayanya yang
tinggi.
c. Beberapa alat dan teknik tersedia untuk
maintanence.

169
d. Rencana pengujian yang baik masih belum
memadai.
e. Standar, prosedur, dan pedoman tidak
didefinisikan dengan baik dan ditegakkan.
Program-program yang dipelihara
mungkin telah dikembangkan bertahun-
tahun yang lalu tanpa teknik modern.
f. Pemeliharaan dipandang sebagai kejahatan
yang diperlukan, sering diturunkan ke
programmer junior. Tidak ada klasifikasi
pekerjaan manajer pemeliharaan di bidang
MIS.
g. Program sering dipertahankan tanpa
mempedulikan struktur dan dokumentasi.
Ketika sebuah sistem berubah, strukturnya
cenderung tidak mampu beradaptasi. Ini
membuat sistem lebih sulit untuk
memahami dan membuat perubahan
karena program menjadi kurang kohesif.
h. Adanya standar minimal untuk
pemeliharaan.
i. Programmer berharap tidak akan terlibat
dalam komitmen yang mengikat bahwa
mereka ikut serta ke siklus pemeliharaan.

170
 j. Perubahan yang dilakukan pada suatu
program dapat memicu terjadinya
kesalahan baru, yang memicu permintaan
perubahan lebih lanjut.
k. Keterkaitan antara program dan
dokumentasi terkadang hilang selama
proses pemeliharaan. Dokumentasi itu
mungkin menjadi bantuan yang tidak dapat
diandalkan untuk memahami program.
2. Fase Pemeliharaan
IEEE menyediakan kerangka kerja untuk
kegiatan proses pemeliharaan berurutan. Ini dapat
digunakan secara berulang dan dapat diperpanjang
sehingga barang dan proses yang disesuaikan dapat
dimasukkan. Aktifitas ini berjalan seiring dengan
masing-masing fase sebagai berikut:
a. Identification & Tracing.
Tahap pertama berkaitan dengan identifikasi
dan manajemen permintaan modifikasi. Pemelihara
memvalidasi permintaan modifikasi,
mengklasifikasikannya sesuai dengan kategori
pemeliharaan seperti pemeliharaan korektif atau
adaptif dan menetapkan prioritasnya. Berdasarkan
hal itu mereka dapat memperkirakan sumber daya

171
 yang diperlukan untuk memenuhi permintaan
tersebut. Permintaan tersebut kemudian ditelusuri
melalui melalui suatu mekanisme dan akhirnya
dikonfirmasikan.
b. Analysis.
Modifikasi yang dilakukan selanjutnya perlu
dianalisis untuk mengkaji dampaknya terhadap
sistem termasuk implikasi keselamatan dan
keamanan. Jika kemungkinan dampaknya berat,
maka perlu dicarikan solusi alternative untuk
mencegah dampak buruk yang berpotensi terjadi.
Satu rangkaian modifikasi yang dibutuhkan
kemudian diwujudkan menjadi spesifikasi
kebutuhan. Biaya modifikasi/pemeliharaan juga
dianalisis dan diestimasi.
c. Design.
Modul baru, yang perlu diganti atau
dimodifikasi, dirancang berdasarkan spesifikasi
persyaratan yang ditetapkan pada tahap sebelumnya.
Selanjutnya dokumentasi perlu diperbarui.
d. Implementation.
Modul baru dikodekan dengan bantuan desain
terstruktur yang dibuat dalam langkah desain. Setiap

172
 programmer diharapkan untuk melakukan pengujian
unit secara paralel.
e. System Testing.
Pengujian integrasi dilakukan di antara modul
yang baru dibuat. Pengujian integrasi juga dilakukan
antara modul-modul baru dan sistem. Akhirnya
sistem diuji secara keseluruhan, mengikuti prosedur
pengujian regresif.
f. Acceptance Testing .
Setelah menguji sistem secara internal, diuji
untuk penerimaan dengan bantuan pengguna. Jika
pada keadaan ini, pengguna mengeluhkan beberapa
masalah yang ditunjukan atau dicatat untuk
ditangani dalam iterasi berikutnya.
g. Delivery.
Setelah tes penerimaan, sistem ini digunakan
di seluruh organisasi baik oleh paket pembaruan
kecil atau instalasi baru dari sistem. Pengujian akhir
berlangsung di sisi klien setelah perangkat lunak di-
delivery.
Fasilitas pelatihan disediakan apabila diperlukan,
di samping hard copy manual pengguna.
h. Maintenance Management.

173
 Manajemen pemeliharaan adalah bagian
penting dari pemeliharaan sistem yang melekat pada
dokumen standar sebagai lampiran. Ini termasuk,
antara lain, kegiatan manajemen yang perlu
dilakukan untuk mengatur proses. Hal ini termasuk
bagian informatif dari standar.

174
 BAB XI

PRINSIP DAN KONSEP ANALISIS BERBASIS OBJEK

A. Paradigma berorientasi Objek

Berorientasi objek merupakan paradigma dalam

merekayasa perangkat lunak yang memandang sistem
sebagai kumpulan objek-objek yang saling berinteraksi
satu sama lain (Sartika, 2019)
Pemrograman Berorientasi Objek (Object Oriented
Programming/OOP) merupakan pemrograman yang
berorientasikan kepada objek, dimana semua data dan
fungsi dibungkus dalam class-class atau object-object.
Setiap object dapat menerima pesan, memproses data,
mengirim, menyimpan dan memanipulasi data. Beberapa
object berinteraksi dengan saling memberikan informasi
satu terhadap yang lainnya. (Supriyadi, 2012)
Sebuah sistem yang dibangun berdasarkan metoda
berorientasi objek adalah sebuah sistem yang
komponennya di-enkapsulasi menjadi kelompok data dan
fungsi, yang dapat mewarisi atribut dan sifat dari
komponen lainnya, dan komponen-komponen tersebut
saling berinteraksi satu sama lain. Pemrograman
berorientasi objek adalah metode pemrograman

175
berdasarkan hirarki kelas, dimana kelas-kelas tersebut
didefinisikan dengan baik dan bisa saling bekerja sama
untuk menyelesaikan masalah. (Lusiani, 2017)
Kelas (class) merupakan penggambaran satu set
objek yang memiliki atribut yang sama. Kelas mirip
dengan tipe data ada pemrograman non objek, akan tetapi
lebih komprehensif karena terdapat struktur sekaligus
karakteristiknya. Kelas baru dapat dibentuk lebih spesifik
dari kelas ada umumnya.kelas merupakan jantung dalam
pemrograman berorientasi objek.
Objek merupakan teknik dalam menyelesaikan
masalah yang kerap muncul dalam pengembangan
perangkat lunak. Teknik ini merupakan teknik yang
efektif dalam menemukan cara yang tepat dalam
membangun sistem dan menjadi metode yang paling
banyak dipakai oleh para pengembang perangkat lunak.
Orientasi objek merupakan teknik pemodelan sistem riil
yang berbasis objek.
Objek adalah entitas yang memiliki atribut,
karakter dan kadang kala disertai kondisi. Objek
mempresentasikan sesuai kenyataan seperti siswa,
mempresentasikan dalam bentuk konsep seperti merek
dagang, juga bisa menyatakan visualilasi seperti bentuk
huruf (font).

176
 Karakteristik atau sifat-sifat yang dipunyai sebuah
sistem berorientasi objek adalah:
a. Abstraksi
Prinsip untuk merepresentasikan dunia nyata
yang kompleks menjadi satu bentuk model
yang sederhana dengan mengabaikan aspek-
aspek lain yang tidak sesuai dengan
permasalahan.
b. Enkapsulasi
Pembungkusan atribut data dan layanan
(operasi-operasi) yang dipunyai objek, untuk
membunyikan implementasi dari objek
sehingga objek lain tidak mengetahui cara
kerjanya.
c. Pewarisan (inheritance)
Mekanisme yang memungkinkan satu objek
(baca: kelas) mewarisi sebagian atau seluruh
definisi dai objek lain sebagai bagian dari
dirinya.
d. Reusability
Pemanfaatan kembali objek yang sudah
didefinisikan untuk suatu permasalahan pada
permasalahan lainnya yang melibatkan objek
tersebut.

177
 e. Generalisasi dan Spesialisasi
Menunjukkan hubungan antara kelas dan
objek yang umum dengan kelas dan objek
yang khusus.
f. Komunikasi antar Objek
Komunikasi antar objek dilakukan lewat pesat
(message) yang dikirim dari satu objek ke
objek lainnya.
g. Polymorphism
Kemampuan suatu objek untuk digunakan di
banyak tujuan yang berbeda dengan nama
yang sama sehingga menghemat baris
program.

B. Konsep berorientasi Objek

1. Abstraksi (Abstraction)
Kemampuan sebuah program untuk melewati
aspek informasi yang diolah adalah kemampuan untuk
fokus pada inti permasalahan. Setiap objek dalam
sistem melayani berbagai model dari pelaku abstrak
yang dapat melakukan kerja, laporan dan perubahan
serta berkomunikasi dengan objek lain dalam sistem,
tanpa harus menampakkan kelebihan diterapkan.

178
2. Enkapsulasi (pembungkus)
Pembungkusan merupakan penggabungan
potongan-potongan informasi dan perilaku-perilaku
spesifik yang bekerja pada informasi tersebut,
kemudian mengemasnya menjadi sesuatu yang
disebut objek (Nugroho,2005). Enkapsulasi adalah
proses memastikan pengguna sebuah objek tidak
dapat menggantikan keadaan dari sebuah objek
dengan cara yang tidak sesuai prosedur. Artinya,
hanya metode yang terdapat dalam objek tersebut
yang diberi izin untuk mengakses keadaan yang
diinginkan. Setiap objek mengakses interface yang
menyabutkan bagaimana objek lainnya dapat
berintegrasi dengannya. Objek lainnya tidak akan
mengetahui dan tergantung kepada representasi dalam
objek tersebut.
3. Polimorfisme
Polimorfise merupakan suatu fungsionalitas yang
diimplikasikan dengan berbagai cara yang berbeda.
Pada program berorientasi objek, pembuat program
dapat memiliki berbagai implementasi untuk sebagian
fungsi tertentu.
4. Inheritas (Pewarisan)
Konsep inheritas mempunyai fungsi mengatur
polimorfise dan enkapsulasi dengan mengizinkan

179
 objek didefinisikan dan diciptakan dengan jenis
khusus dari objek yang sudah ada. Objek-objek ini
dapat membagi dan memperluas perilaku mereka
tanpa mengimplementasikan perilaku tersebut.

C. Identifiksi Elemen Model Objek

1. Atribut
a. Nilai atau elemen-elemen data yang dimiliki
oleh objek dalam kelas objek.
b. Merupakan ciri dari sebuah objek
c. Dipunyai secara individual oleh sebuah objek.
d. Contoh: berat, warna, jenis, nama, dan
sebagainya.
2. Layanan (Service)
a. Metode atau operasi yang berfungsi untuk
memanipulasi objek itu sendiri.
b. Fungsi atau transformasi yang dapat dilakukan
terhadap objek atau dilakukan oleh objek.
c. Dapat berasal dari:
d. model objek
e. event
f. aktivitas atau aksi keadaan

180
 g. fungsi
h. kelakuan dunia nyata
i. Contoh: Read, Write, Move, Copy dan
sebagainya.
3. Klasifikasi Objek
a. ADT (Abstract Data Type)
Definisi dari kelas dimana komponen type
menjadi atribut dan fungsi primitif menjadi
operasi/metode/layanan.
b. Mesin
Objek pasif yang punyai status yang akan
diaktifkan oleh objek lain. Fungsi primitif pada
mesin merupakan mekanisme transisi yang
mengubah suatu status ke status lain.
b. Proses
Objek aktif yang mempunyai “urutan
kendali” (thread of control)

D. Analisis berorientasi Objek

1. Pengertian Dasar
Pengertian dasar Analisis Berorientasi Objek
adalah sebagai berikut :
a. Investigasi masalah untuk menemukan

181
 (mengidentifikasikan) dan mendefinisikan
objek-objek atau konsep-konsep yang ada di
ruang masalah.
b. Proses untuk menentukan objek-objek
potensial yang ada dalam sistem dan
mendeskripsikan karakterisitik dan
hubungannya dalam sebuah notasi formal.
c. Aplikasi konsep berorientasi objek untuk
memodelkan permasalahan dan sistem, baik
untuk lingkup perangkat lunak maupun non-
perangkat lunak.

2. Tujuan Analisis
a. Memahami permasalahan secara menyeluruh.
b. Mengungkapkan apa yang harus dikerjakan
oleh sistem untuk memenuhikebutuhan
pemakai.
c. Mengetahui ruang lingkup produk (product
space) dan pemakai yang akanmenggunakan
produk tersebut.

3. Tahap Analisis
a. Mempelajari permasalahan

182
 b. Menentukan kebutuhan pemakai
c. Mengubah kebutuhan yang belum terstruktur
menjadi model-model atau gambar-gambar
dengan memanfaatkan metode dan teknik
analisis tertentu.
d. Mendokumentasikan hasil analisis, misalnya
Software Requirement Specification (SRS).

4. Metode Analisis Berorientasi Objek

Metode Analisis Berorientasi Objek secara umum
adalah sebagai berikut :
a. Cara kerja yang sistematis untuk mengerjakan
tahap analisis berdasarkanpendekatan objek.
b. Ada kumpulan aturan-aturan tertentu yang
harus diikuti untuk menyelesaikan pekerjaan
analisis tersebut.
c. Mempunyai urut-urutan aktivitas, teknik, dan
alat bantu (tools) tertentuuntuk memodelkan
(mendokumentasikan) hasil dari setiap
aktivitas.
d. Ada beberapa metode yang dapat digunakan
untuk melakukan analisis berorientasi objek,
dan diantaranya adalah sebagai berikut.

183
Metode orientasi objek yang digunakan dalam analisis
berorientasi objek antara lain
a. Metode Booch
Dikenal dengan nama Metode Desain Object
Oriented. Metode ini menjadikan proses
analisis dan desain ke dalam empat tahapan
yang iteratif (dapat berulang), yaitu identifikasi
kelas-kelas dan objek-objek, identifikasi
semantik dan hubungan objek dan kelas
tersebut, perincian interface dan implementasi.

b. Metode Rumbaugh (Object Modelling

Technique – OMT)
Metode ini berdasarkan pada analisis terstruktur
dan pemodelan entity-relationship. Tahapan
utama dalam metodologi ini adalah analisis,
desain sistem dan desain objek, dan
implementasi. Keunggulan metode ini adalah
dalam penotasian yang mendukung semua
konsep object oriented.

c. Metode Jacobson (Object Oriented Software

Engineering – OOSE)

184
 Metode yang mengandung elemen-elemen dari
Object Oriented lainnya. Metode ini memberi
penekanan lebih pada use-case. OOSE
memiliki tiga tahapan yaitu membuat model
requirement dan analisis, desain dan
implementasi, dan model pengujian (tes
model). Keunggulan metode ini adalah mudah
untuk dipelajari karena memiliki notasi yang
sederhana, mencakup seluruh tahapan dalam
rekayasa software.

d. Metode Coad dan Yourdon

Metode ini didasarkan pada pemodelan Object
Oriented dan entity-relationship. Metode ini
mempunyai perancangan yang berfokus pada
empat komponen yaitu Problem domain
componet, Human interaction componet, Data
management component dan Task management
component.

e. Metode Wirfs-Brock
Responsibility Driven Design/-Class
Responsibility Collaboration (RDD/CFC)
Metode ini diarahkan pada desain, tetapi sangat

185
 berguna untuk memunculkan ide dalam tahap
analisis. Keunggulannya adalah mudah
digunakan, metode ini juga
mengidentifikasikan hirarki kelas dan
subsistem-subsistem.

f. Metode Shlair-Mellor Object Oriented

Analysis/Design (OOA/D)
Metode yang menggunakan teknik pemodelan
informasi tradisional yang menjelaskan entitas
dalam sistem, menggunakan state diagram
untuk memodelkan keadaan (state) entitas,
menggunakan data flow diagram untuk
memodelkan alur data dalam sistem. Metode ini
menghasilkan tiga jenis model yaitu:
information model, state model dan process
model. Keunggulan metode ini adalah dalam
memandang masalah dari sudut pandang yang
berbeda, mudah dibuat (dikonversi) dari
metode struktural.

Perbedaan Metodologi berorientasi objek dengan

Metodologi Non Objek adalah:
a. Penggunaan Alat

186
 Metodologi non objek menggunakan beberapa
alat untuk menggambarkan model seperti: data
flow diagram, entity relationship diagram, dan
structure chart. Sedangkan pada metodologi
berorientasi objek menggunakan satu jenis
model dari tahap analisis sampai implementasi,
yaitu object diagram(diagram objek)
b. Data dan Proses
Metodologi non objek data dan proses dianggap
sebagai dua komponen yang berlainan,
sedangkan pada metodologi berorientasi objek
data dan proses merupakan satu kesatuan, yaitu
bagian dari objek.
c. Bahasa Pemrograman
Metodologi non objek dipergunakan untuk
melengkapi pemrograman terstruktur pada
bahasa generasi ketiga, sedangkan pada
metodologi berorientasi objek dipergunakan
untuk pemrograman berorientasi objek dan
bahasa generasi empat.

E. Proses Perancangan Sistem Berbasis Objek

1. Unified Modelling Language (UML)

187
 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.
UML dapat di definisikan sebagai bahasa visual
untuk menjelaskan, memberikan spesifikasi,
merancang, membuat model, dan
mendokumentasikan aspek-aspek dari sebuah system.
Karena tergolong bahasa visual, UML lebih
mengedepankan penggunaan diagram untuk
menggambarkan aspek dari system yang sedang
dimodelkan.

Fungsi UML
a. Memberikan bahasa pemodelan yang bebas dari
berbagai bahas pemrograman dan proses
rekayasa.
b. Menyatukan praktek-praktek terbaik yang
terdapat dalam pemodelan.
c. Memberikan model yang siap pakai, bahsa
pemodelan visual yang ekspresif untuk

188
 mengembangkan dan saling menukar model
dengan mudah dan dimengerti secara umum.
d. UML Sebagai Sketsa UML digambarkan dalam
sketsa coretan-coretan dalam kertas atau
whiteboard secara tidak normal. Biasanya
digunaan dalam sesi dskusi tim untuk membahas
aspek tertentu dalam tahap analisis dan
perancangan
e. UML Sebagai Blueprint system
UML sendiri juga memberikan standart
penulisan sebuah sistem blueprint yang meliputi
konsep bisnis proses penulisan kelas-kelas dalam
bahasa program yang spesifik, skema database
dan komponen-komponen yang diperlukan
dalam sistem.
f. UML Sebagai bahasa pemrograman
UML berfungsi sebagai bahasa
pemrograman mencoba melakukan semuanya
dengan UML sampai kepada produk jadinya.
Analisi dan perancangan dilakukan dengan
diagram-diagram yang ada dalam UML,
sementara sebuah tool atau generator bisa
menghasilkan produk akhir dari diagram-
diagram ini.yang ada dalam UML, sementara

189
 sebuah tool atau generator bisa menghasilkan
produk akhir dari diagram-diagram ini.

2. Konsep Dasar UML

Untuk dapat mememahami UML diperlukan
pemahaman tentang konsep bahasa pemodelan dan
tiga eleman utama UML.Tiga elemen utama UML
antara lain:
a. Buiding Bloks
b. Building bloks ini terdapat beberapa bagian
c. Benda / Things / Objek
d. Objek merupakan bagian paling statik dari
sebuah model, yang menjelaskan elemen –
elemen lainnya dari sebuah konsep. Bentuk dari
beberapa objek, yaitu:
1) Classes, sekelompok dari object yang
mempunyai atribute, operasi, dan
hubungan yang semantik
2) Interfaces, antar-muka yang
menghubungkan dan melayani antar kelas
dan atau elemen dan mendefinisikan

190
 sebuah kelompok dari spesifikasi
pengoperasian
3) Collaboration, interaksi dari sebuah
kumpulan kelas – kelas atau elemen –
elemen yang bekerja secara bersama –
sama.
4) Use cases, pembentuk tingkah laku objek
dalam sebuah model serta di realisasikan
oleh sebuahcollaboration.
5) Nodes, bentuk fisik dari elemen – elemen
yang ada pada saat dijalankannya sebuah
system
e. Hubungan / Relationship

Jenis-jenis Diagram UML :

a. Use Case Diagram
b. Class Diagram
c. Statechart Diagram
d. Activity Diagram
e. Sequence Diagram

3. Langkah-Langkah Penggunaan UML

191
Berikut ini adalah tips pengembangan piranti lunak
dengan menggunakan UML:
a. Buatlah daftar business process dari level
tertinggi untuk mendefinisikan aktivitas dan
proses yang mungkin muncul.
b. Petakan use case untuk tiap business process
untuk mendefinisikan dengan tepat
fungsionalitas yang harus disediakan oleh
sistem. Kemudian perhalus use case diagram
dan lengkapi dengan requirement, constraints
dan catatan-catatan lain.
c. Buatlah deployment diagram secara kasar untuk
mendefinisikan arsitektur fisik sistem.
d. Definisikan requirement lain (non-fungsional,
security dan sebagainya) yang juga harus
disediakan oleh sistem.
e. Berdasarkan use case diagram , mulailah
membuat activity diagram .
f. • Definisikan objek-objek level atas
( package atau domain ) dan buatlah
sequence dan/atau collaboration diagramuntuk
tiap alir pekerjaan. Jika sebuah use case

192
 memiliki kemungkinan alir normal dan error,
buatlah satu diagram untuk masing-masing alir.
g. Buarlah rancangan user interface model yang
menyediakan antarmuka bagi pengguna untuk
menjalankan skenario use case .
h. Berdasarkan model-model yang sudah
ada, buatlah class diagram . Setiap package
atau domain d ipecah menjadi hirarki class
lengkap dengan atribut dan metodanya. Akan
lebih baik jika untuk setiap class dibuat unit test
untuk menguji fungsionalitas class dan interaksi
dengan class lain.
i. Setelah class diagram dibuat, kita dapat
melihat kemungkinan pengelompokan class
menjadi komponen-komponen. Karena itu
buatlah component diagram pada tahap ini.
Juga, definisikan tes integrasi untuk setiap
komponen meyakinkan ia berinteraksi dengan
baik.
j. Perhalus deployment diagram yang sudah
dibuat. Detilkan kemampuan dan
requirement piranti lunak, sistem operasi,
jaringan, dan sebagainya. Petakan komponen ke
dalam node.

193
 k. Mulailah membangun sistem. Ada dua
pendekatan yang dapat digunakan :
1) Pendekatan use case , dengan meng- assign
setiap use case kepada tim pengembang
tertentu untuk mengembangkan unit code
yang lengkap dengan tes.
2) Pendekatan komponen, yaitu
meng- assign setiap komponen
kepada tim pengembang tertentu.
Tool pendesainan yang mendukung UML, baik itu
tool komersial maupun opensource. Beberapa
diantaranya adalah:
a. Rational Rose (www.rational.com)
b. Together (www.togethersoft.com)
c. Object Domain (www.objectdomain.com)
d. Jvision (www.object-insight.com)
e. Objecteering (www.objecteering.com)
f. MagicDraw
(www.nomagic.com/magicdrawuml)
g. Visual Object Modeller
(www.visualobject.com)

KESIMPULAN

194
 Perangkat lunak (Software) merupakan suatu istilah
khusus yang dipakai pada data yang diformat. Serta disimpan
secara digital yang di dalamnya meliputi program komputer,
dokumentasinya, serta seagala informasi yang bisa ditulis dan
dibaca oleh komputer. Perangkat lunak juga dapat disebut
sebagai sebuah bagian sistem dalam komputer yang tidak
memiliki wujud nyata.

Perangkat lunak atau software adalah sekumpulan data

elektronik yang tersimpan dan dikendalikan oleh perangkat
komputer. Data elektronik tersebut meliputi instruksi atau
program yang nantinya akan menjalankan perintah khusus.
Perangkat lunak juga disebut sebagai bagian sistem dalam
komputer yang tidak memiliki wujud fisik yang diinstal dalam
sebuah komputer atau laptop agar bisa dioperasikan.

Tujuan dari pengujian Sistem sebenarnya merupakan

hal yang sederhana, dimana pengujian digunakan untuk
memastikan bahwa Sistem yang akan dihasilkan sesuai
dengan kebutuhan (requirement) yang sebelumnya telah
ditentukan. Ketika suatu requirement dari suatu perangkat
lunak telah disusun maka semestinya sudah ada suatu
pengujian perencanaan (test plan). Selain itu suatu proses
testing membutuhkan tujuan akhir yang dapat dinilai sehingga

195
pihak tester bisa berhenti untuk melakukan suatu testing ketika
tujuan-tujuan itu telah tercapai.

Pemrograman Berorientasi Objek atau yang dalam

Bahasa Inggris disebut Object Oriented Programming dan
disingkat OOP, pastinya bukan lagi merupakan istilah yang
asing di telinga kita yang menekuni dunia pemrograman atau
IT. Ini merupakan paradigma pemrograman yang didasarkan
oleh konsep “objek” yang bisa terdiri dari data dalam bentuk
field yang juga dikenal sebagai atribut, kemudian kode
berbentuk fungsi yang juga disebut ‘method’.

Perintah (program komputer) yang mana bila

dieksekusi akan menghasilkan fungsi sebagai mana yang kita
inginkan. Struktur data yang memungkinkan suatu aplikasi
dapat memanipulasi informasi secara proporsional. Dokumen
yang menggambarkan suatu kegunaan dari pada sebuah
program. Perangkat lunak tersebut dibedakan menjadi 2 tipe
yaitu :

a. Produk Generik, yaitu sistem stand alone yang di

produksi oleh perusahaan pengembang perangkat lunak
dan di pasarkan ke pasar umum. Contohnya : Microsoft
Office, Adobe Creative Suite, dll.

196
b. Produk Pesanan, yaitu produk perangkat lunak yang
mana akan dikembangkan bila ada perusahaan/konsumen
yang memesannya. Contohnya : Sistem Penerimaan
Mahasiswa untuk sebuah kampus, dll.

197
 DAFTAR PUSTAKA

Adi, H. 2020. Pengertian Manajemen Proses. Dipetik Juli

5, 2021, Dari Hestanto.Web.id: https://www.
Hestanto.web.id/Pengertian-Manajemen-
Proses/

Adinata Dkk. 2021. Makalah Sistem Operasi Komputer

Kelompok 3 : Manajemen Proses. Palopo:
UNCP.

Admin. 2017. Konsep Dan Prinsip Desain | Rekayasa

Perangkat Lunak. Dipetik Juli 1, 2021, Dari
Pendidikanku.Org: https://Pendidikanku.Org/
2017/01/Konsep-Dan-Prinsip-Desain-
Rekayasa-Perangkat-Lunak.Html

Admin. 2021. Pemodelan Analisis Dalam Rekayasa

Perangkat Lunak. Dipetik Juli 1, 2021, Dari
Pendidikanku.org: https://pendidikanku.org/
2021/01/Pemodelan-Analisis-Dalam-Rekaya
sa-Perangkat-Lunak.Html

Aiza Dkk, N. 2021. Makalah Sistem Operasi Komputer

Kelompok 5 : Sinkronisasi Dan Deadlock.
Palopo: UNCP.

Ali, Edwar. 2019. Rekayasa Perangkat Lunak.

Yogyakarta. CV MFA

198
Armonitha, S. Tipe Manajemen Memori Pada Sistem
Operasi. Dipetik Juli 3, 2021, Dari Slideshare:
https://www.slideshare.net/Sharyarmonitha5/
Tipe-Manajemen-Memori-Pada-Sistem -
Operasi

Azhari. 2016. Modul Perancangan Berorientasi Objek.

Dipetik Juli 3, 2021, Dari Academia.edu:
https://www.scademia.edu/30174983/MODU
L_PERANCANGAN_BERORIENTASI_OB
JEK

Basuki,Achmad. 2006. Spesifikasi Rekayasa Perangkat

Lunak. http://hero.lecturer.pens.ac.id/
Datahero/Kuliah/RPL/02%20Deskripsi%20R
PL.Pdf Diakses Tanggal 3 April 2021

Candra. Manajemen Memori Pada Sistem Operasi

Bagian 1. Dipetik Juli 3, 2021, Dari Teknologi
Jempolan: https://www.teknojempol.com/
2017/12/Manajemen-Memori-Pada-Sistem-
Operasi-1.Html

Dika, Dkk. 2013. Perancangan Perangkat Lunak. Dipetik

Juni 8, 2021, Dari Slideshare: https://
www.slideshare.net/Aliandyka/Kelompok-5-
17353483

Firdha, B. T.Thn. Prinsip Dan Konsep Desain Pokok

Bahasan Dalam RPL: Desain PL Dan
Rekayasa PL Prinsip Desain Konsep Desain

199
 Desain Modular Afektif Model Desain.
Dipetik Juli 1, 2021, Dari ACADEMIA:
https://www.Academia.Edu/11971778/
PRINSIP_DAN_KONSEP_DESAIN_Pokok_
Bahasan_Dalam_RPL_Desain_PL_Dan_Rek
ayasa_PL_Prinsip_Desain_Konsep_Desain_
Desain_Modular_Afektif_Model_Desain

Gunardi, Y. T.Thn. Tugas Rekayasa Perangkat Lunak.

Dipetik Juli 1, 2021, Dari ANZDOC:
https://Adoc.Pub/Tugas-Rekayasa-Perangkat-
Lunak3bcc3a316c5a7be5f4986b2d9ab8d3fb1
9318.Html

Hartono. 2018. SISTEM OPERASI. Lhokseumawe: CV.

Sefa Bumi Persada.

IEEE Xplore - Software Engineering, IEEE

Transactionson.Http://Ieeexplore.Ieee.Org/Xp
l/Recentissue.Jsp?Punumber=32. Mulyanto,
Aunur R. 2008. Rekayasa Perangkat Lunak
Jilid 1 Untuk SMK. Direktorat Pembinaan
Sekolah Menengah Kejuruan, Direktorat
Jenderal Manajemen Pendidikan Dasar Dan
Menengah, Departemen Pendidikan Nasional :
Jakarta. Diakses Pada Tanggal 25 Juni 2021
Jam 08.00 WITA.

Imran Dkk, A. 2021. Makalah Sistem Operasi Komputer

Kelompok 4 : Kelompok Penjadwalan Proses.
Palopo: UNCP.

200
Ivanka Dkk, R. 2021. Makalah Sistem Operasi Komputer
Kelompok 7 : Sistem Berkas. Palopo: UNCP.

Kemina. 2016. PERANGKAT LUNAK REKAYASA

PRODUK. Http://Kemina04mpic.Blogspot.
Com/2016/01/V-Behaviorurldefaultvmlo_4.
Html?M=1 Diakses Tanggal 3 April 2021

Kuryanti, S. J. 2018. Perancangan Sistem Berbasis

Objek. Dipetik Juli 3, 2021, Dari Docplayer:
https://docplayer.Info/31232427-Perancang
an-Sistem-Ber Basis-Objek.Html

Lusiani, T. 2017. Paradigma Pemrograman Berorientasi

Objek. Dipetik Juli 3, 2021, Dari Taman Baca
Lusi: https://titiklusiani.wordpress.com/2017/
04/05/paradigma-pemrograman-berorientasi-
objek/

Mala, Dila, Trisna. 2013. REKAYASA PERANGKAT

LUNAK. http://bokdimal.blogspot.com/2013/
03/produk.html?m=1 Diakses Tanggal 3 April
2021

Mayarospita. 2013. Pemodelan Analisis. Dipetik Juli 1,

2021, Dari Maya Rospita Rahayu Mari
Berbagi Ilmu: https://mayarospita100.word
press.com/2013/11/01/rekayasa-perangkat-
lunak-pemodelan-analisis/

201
Mirza, A. 2015. Pemeliharaan Perangkat Lunak. Dipetik
Juli 2, 2021, Dari TCT: http://agam-
mirza.blogspot.com /2015/08/ pemeliharaan-
perangkat-lunak-ppl.html

Miswar, T. Manajemen Memori. Dipetik Juli 3, 2021,

Dari Sistem Operasi: http://sistemoperasitak
birmiswar.blogspot.com/2016/04/manajemen-
memori.html

Mufadhol. 2015. Buku Ajar : Sistem Operasi Komputer.

Semarang: Sekolah Tinggi Elektronika Dan
Komputer.

Mukmin Dkk, A. 2021. Makalah Sistem Operasi

Komputer Kelompok 6 : Manajemen Memori.
Palopo: UNCP.

Munif, Abdul. 2020. “Pemodelan Perangkat Lunak”.

Malang: PT Kuantum Buku Sejahtera

Nanda, D. R. 2012. Pengenalan Sistem Komputer.

Resume Upload OSF, 1-6.

Nusantara, R. 2019. Penjadwalan Proses Sistem Operasi.

Dipetik Juli 5, 2021, Dari Ridhonusa:
https://Ridhonusa.Blogspot.Com/2019/01/Pen
jadwalan-Proses.Html

202
Obbymaru. T.Thn. Tugas2 RPL II. Dipetik Juli 1, 2021,
Dari Shikamaru Nara: http://obbymaru.
blogspot.com/ 2012/06/tugas2-rpl -ii.html

Panduanilkom. 2018. Pengertian Manajemen Proses,

Tugas, Model Serta Status Proses Sistem
Operasi. Dipetik Juli 5, 2021, Dari
Panduanilkom: https://panduanilkom.
blogspot.com/2018/03/pengertian-
manajemen-proses-tugasmodel.html

Pendidikan.Org. 2017. Konsep Dan Prinsip Desain |

Rekayasa Perangkat Lunak. Dipetik Juni 8,
2021, Dari Pendidikan.Org: https://pendidi
kanku.org/2017/01/konsep-dan-prinsip-desain
-rekayasa-perangkat-lunak.html

Pengertian Software Engineering. http://en.wikipedia.

org/wiki/software_engineering. Diakses Pada
Tanggal 25 Juni 2021 Jam 08.00 WITA.

Putra, R. L. 2013. Konsep Perangkat Lunak. Dipetik Juni

6, 2021, Dari Asal Bikin: http://riellaks.
blogspot. com/ 2013/11/konsep-perangkat-
lunak.html

Riyadi, H. 2019. Pengertian Sistem Komputer Beserta

Fungsi Dan Komponen-Komponen Pada
Sistem Komputer. Dipetik Juli 2, 2021, Dari
nesabamedia: https://www.nesabamedia.com/

203
 pengertian-sistem-komputer/#pengertian_
sistem_komputer

RPLHLW117A02. 2015. Konsep Dan Prinsip Desain.

Dipetik Juli 1, 2021, Dari Rekayasa Perangkat
Lunak Kelompok 2: https://rplhlw117a02.
wordpress.com/2015/11/16/konsep-dan-
prinsip-desain/

Rudyryvan. 2016. Konsep Dan Prinsip Analisis Dan

Pemodelan Analisis. Dipetik Juli 1, 2021, Dari
Rudyryvan: https://rudyryvan.wordpress.com
/2016/04/29/konsep-dan-prinsip-analisis-dan-
pemodelan-analisis/

Santi, D. N. 2020. Bahan Ajar Pemodelan Perangkat

Lunak. Dipetik Juli 3, 2021, Dari Guru
Berbagi: https://ayoguruberbagi.kemdikbud.
go.id/artikel/bahan-ajar-pemodelan-perangkat
-lunak/

Sartika, D. 2019. Paradigma Bereorientasi Objek.

Dipetik Juli 3, 2021, Dari Slideplayer:
https://slideplayer.info/ slide/12648927/

Supriyadi. 2011 Pemrograman Berorientasi Obyek.

Dipetik Juli 3, 2021, Dari Supriyadi Eka
Saputra: https://cuepricornz.wordpress.com/
tutorial/pemrograman-berorientasi-obyek/

204
Sutiono. Teknik Manajemen Memori Dan
Penjelasannya. Dipetik Juli 3, 2021, Dari
Dosenit: https:// dosenit.com/hardware/
teknik-manajemen-memori

Tanpa Nama. Konsep Dasar Memori. Dipetik Juli 3,

2021, Dari Berbagai Ilmu Yang Asik: http://el-
kameel.blogspot.com/2014/05/tulisan-konsep
-dasar-memori.html

Tanpa Nama. Manajemen Memori, Manajemen

Masukan-Keluaran Dan Manajemen File.
Dipetik Juli 3, 2021, Dari Abaccess:
https://Abaccess.Wordpress.Com/2013/10/30/
Manajemen-Memori-Manajemen-Masukan-
Keluaran-Dan-Manajemen-File/

Unknown. 2010. Konsep Dan Prinsip Desain. Dipetik

Juli 1, 2021, Dari Hvi-Fluubht Blog:
https://viallyhardi.wordpress.com/2010/04/03
/konsep-dan-prinsip-desain/

Unknown. 2015. Pemodelan Analisis. Dipetik Juli 1,

2021, Dari: http://41813120100.blog.
mercubuana.ac.id/wp-content/uploads/sites/1
08/2015/05/pemodelan-analisis_linda-liana
_41813120100.pdf

Unknown. 2015. Prinsip Dan Konsep Desain Perangkat

Lunak. Dipetik Juli 1, 2021, Dari:
http://41813120051.blog.mercubuana.ac.id/w

205
 p-content/uploads/sites/113/2015/06/4181312
0051_FADHILLA_EKA_HENTINO_8.PRIN
SIP-DAN-KONSEP-DESAIN-PERANGKA
T-LUNAK1.Pdf

Unknown. T.Thn. Konsep Dan Prinsip Analisis. Dipetik

Juli 1, 2021, Dari Unlimeted:
http://digitalparameter. blogspot.com/2016/
04/konsep-dan-prinsip-analisis. html

Yasyim. 2021. Cara Mengganti Ikon Folder Di Windows

10 Tanpa Aplikasi. Dipetik Juli 3, 2021, Dari
Inwepo: https://inwepo.co/cara-mengganti-
ikon-folder-di-windows-10/

Zulkifli. 2020. Manajemen Proses. Dipetik Juli 5, 2021,

Dari Bintan: http://www.bintan-s.web.id/
2020/11/mana jemen -proses.html

206