REKAYASA PERANGKAT LUNAK

DAFTAR ISI
BAB 1. PENGANTAR RPL ..................................................................................................... 1
A. PENGERTIAN RPL .......................................................................................................................... 1
B. KEGUNAAN RPL .......................................................................................................................... 11
C. PERKEMBANGAN RPL ................................................................................................................. 12
D. DESKRIPSI RPL ............................................................................................................................. 12
E. KARAKTERISTIK RPL .................................................................................................................... 13
F. KOMPONEN RPL ......................................................................................................................... 13
G. APLIKASI RPL ............................................................................................................................... 13
BAB 2. MANAGING SOFTWARE PROJECTS ........................................................................ 15
A. PROJECT MANAGEMENT CONCEPT ............................................................................................ 15
B. SOFTWARE PROJECT PLANNING ................................................................................................. 17
C. RISK ANALYSIS AND MANAGEMENT .......................................................................................... 20
D. SQA ............................................................................................................................................. 24
BAB 3. METODE KONVENSIONAL UNTUK SOFTWARE ENGINEERING ................................ 26
A. SYSTEM ENGINEERING ............................................................................................................... 26
B. REQUIREMENT ENGINEERING .................................................................................................... 30
BAB 4. ANALISIS ............................................................................................................... 35
A. KONSEP DAN PRINSIP ANALISIS .................................................................................................. 35
B. MODEL ANALISIS ........................................................................................................................ 42
C. ANALISIS TERSTRUKTUR ............................................................................................................. 44
D. KAMUS DATA .............................................................................................................................. 46
BAB 5. DESAIN .................................................................................................................. 48
A. PROSES DESAIN .......................................................................................................................... 48
B. PRINSIP‐PRINSIP DESAIN ............................................................................................................ 50
C. KONSEP DESAIN .......................................................................................................................... 51
D. EFECTIVE MODULAR DESIGN ...................................................................................................... 57
E. ARCHITECTURAL DESIGN ............................................................................................................ 58
F. USER INTERFACE DESIGN............................................................................................................ 62
BAB 6. DESAIN UNTUK SYSTEM REAL‐TIME ...................................................................... 64
A. SYSTEM REAL‐TIME ..................................................................................................................... 64
B. ANALISIS DAN SIMULASI UNTUK SYSTEM REAL‐TIME ............................................................... 68

C. DESAIN REAL‐TIME .................................................................................................................... 75
BAB 7. TEKNIK PENGUJIAN PERANGKAT LUNAK ............................................................... 77
A. DASAR‐DASAR PENGUJIAN PERANGKAT LUNAK ........................................................................ 77
B. TEST CASE DESIGN .................................................................................................................... 78
C. WHITE‐BOX TESTING .................................................................................................................. 80
D. CONTROL STRUCTURE TESTING ................................................................................................. 84
BAB 8. STRATEGI PENGUJIAN PERANGKAT LUNAK............................................................ 98
A. PENDEKATAN STRATEGIS KE PENGUJIAN PERANGKAT LUNAK .................................................. 98
B. MASALAH‐MASALAH STRATEGIS ................................................................................................ 99
C. PENGUJIAN UNIT ...................................................................................................................... 100
D. PENGUJIAN INTEGRASI ............................................................................................................. 102
E. PENGUJIAN VALIDASI ............................................................................................................... 103
F. PENGUJIAN SISTEM .................................................................................................................. 103
G. PENGUJIAN DEBUGGING .......................................................................................................... 104
BAB 9. OBJECT ORIENTED SOFTWARE ENGINEERING ...................................................... 109
A. KONSEP DAN PRINSIP OBJECT ORIENTED ................................................................................ 109
B. OBJECT ORIENTED ANALIS ........................................................................................................ 118
C. OOA VS CONVENSIONAL .......................................................................................................... 125
D. UNIFIED MODELLING LANGUAGE (UML) .................................................................................. 125
E. OBJECT ORIENTED DESIGN ....................................................................................................... 135
BAB 10. CLIENT SERVER SOFTWARE ENGINEERING ......................................................... 137
A. STRUKTUR DARI SISTEM CLIENT‐ SERVER ................................................................................ 137
B. SOFTWARE ENGINEERING UNTUK SISTEM CLIENT SERVER ..................................................... 145
C. DESAIN UNTUK CLIENT‐SERVER SISTEM ................................................................................... 150
BAB 11. WEB ENGINEERING ........................................................................................... 156
A. ATRIBUT DARI APLIKASI WEB ................................................................................................... 161
B. DESAIN UNTUK WEB‐BASED APPLICATION ............................................................................. 162
C. TESTING WEB‐DESIGN APLICATION .......................................................................................... 165

1
BAB 1
PENGANTAR RPL
Rekayasa perangkat lunak merupakan sebuah disiplin ilmu yang bertujuan
mengembangkan sistem perangkat lunak yang efektif dari segi biaya. Perangkat lunak bersifat
abstrak dan tidak nyata. Rekayasa perangkat lunak masih merupakan disiplin yang relatif muda.
Istilah rekayasa perangkat lunak pertama kali diajukan pada tahun 1968.
A. PENGERTIAN RPL
Banyak orang menyamakan istilah perangkat lunak dengan program komputer.
Sesungguhnya pandangan ini terlalu dangkal, perangkat lunak tidak hanya mencakup program,
tetapi juga semua dokumentasi dan konfigurasi data yang berhubungan (Sommerville, 2003).
Rekayasa perangkat lunak adalah disiplin ilmu yang membahas semua aspek produksi
perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan.
Di sisi lain terdapat istilah yang juga tidak kalah populer adalah computer science atau
ilmu komputer. Pada intinya computer science berhubungan dengan teori dan metode yang
mendasari sistem komputer dan perangkat lunak. Sedangkan rekayasa perangkat lunak
berhubungan dengan masalah-masalah praktis dalam memproduksi perangkat lunak.
Pengetahuan tetang computer science sangat penting bagi perekayasa perangkat lunak sama
seperti pengetahuan tentang fisika sangat penting bagi teknik kelistrikan.
Istilah lain yang juga populer adalah rekayasa sistem atau rekayasa sistem berbasis
komputer. Rekayasa sistem berhubungan dengan pengembangan perangkat keras,
perancangan kebijakan dan proses, dan penyebaran sistem sebagaimana pada rekayasa
perangkat lunak. Rekayasa sistem merupakan disiplin yang lebih tua dari rekayasa perangkat
lunak.
1. PRODUCT
Saat ini perangkat lunak memiliki dua peran. Peran pertama berfungsi sebagai sebuah
produk dan peran kedua sebagai kendaraan yang mengantarkan sebuah produk (Pressman,
2002). Sebagai produk perangkat lunak mengantarkan potensi perhitungan yang dibangun
oleh perangkat lunak komputer. Tidak peduli apakah perangkat lunak ada dalam telepon
seluler, dalam mainframe komputer. Perangkat lunak merupakan transformer informasi yang
memproduksi, mengatur, memperoleh, memodifikasi, menampilkan atau menyebarkan

informasi dimana pekerjaan ini dapat menjadi sederhana suatu bit tunggal atau sekompleks
simulasi multimedia. Sebagai kendaraan yang dipakai untuk mengantarkan produk, perangkat
lunak berlaku sebagai dasar untuk kontrol komputer (sistem operasi), komunikasi informasi
(jaringan komputer).
Untuk memperoleh pemahaman tentang perangkat lunak serta pemahaman tentang
rekayasa perangkat lunak penting juga untuk mengetahui karakteristik yang membuat
perangkat lunak berbeda dengan dengan produk lain yang dihasilkan oleh manusia. Ketika
perangkat lunak dibuat proses kreatif manusia (analisis, desain, konstruksi dan pengujian)
diterjemahkan ke dalam bentuk fisik.
2. PROCESS
Proses perangkat lunak merupakan serangkaian kegiatan dan hasil-hasil relevan yang
menghasilkan perangkat lunak. Kegiatan-kegiatan ini sebagian besar dilakukan oleh perekayasa
perangkat lunak. Ada empat kegiatan proses dasar perangkat lunak:
1) Spesifikasi perangkat lunak, fungsional perangkat lunak dan batasan kemampuan
2
operasinya harus didefinisikan.
2) Pengembangan perangkat lunak, perangkat lunak yang memenuhi spesifikasi tersebut
harus dipenuhi.
3) Validasi perangkat lunak, perangkat lunak harus divalidasi untuk menjamin bahwa
perangkat lunak melakukan apa yang diinginkan oleh pelanggan.
4) Evolusi perangkat lunak, perangkat lunak harus dikembangkan untuk memenuhi
kebutuhan pelanggan yang berubah-ubah.
Proses perangkat lunak yang berbeda mengatur kegiatan ini dengan cara yang berbeda
dan dijelaskan dengan tingkat kerincian yang berbeda pula. Waktu kegiatan bervariasi,
sebagaimana hasilnya.
Proses perangkat lunak sangat rumit dan seperti semua proses intelektual, bergantung
pada penilaian manusia. Karena dibutuhkan penilaian dan kreatifitas keberhasilan usaha untuk
mengotomasi proses perangkat lunak menjadi terbatas. Satu alasan mengapa otomasi proses
memiliki cakupan terbatas adalah adanya keragaman proses perangkat lunak. Tidak ada proses
yang ideal dan organisasi berbeda yang mengembangkan pendekatan yang benar-benar
berbeda dalam pengembangan perangkat lunak.

3
1. Model Proses Perangkat Lunak
Model proses perangkat lunak merupakan deksripsi yang disederhanakan dari proses
perangkat lunak yang dipresentasikan dengan sudut pandang tertentu. Model sesuai sifatnya,
merupakan penyederhanaan sehingga model proses bisa mencakup kegiatan yang merupakan
bagian dari proses perangkat lunak, produk perangkat lunak, peran orang yang terlibat pada
rekayasa perangkat lunak.
a. Model Air Terjun (Waterfall)
Model ini dikenal sebagai model air terjun atau siklus hidup pengembangan perangkat
lunak. Model ini dapat dilihat pada Gambar 1.1. Tahap-tahap utama dari model ini
memetakan kegiatan-kegiatan pengembangan dasar, yaitu:
1) Analisis dan Definisi persyaratan. Pelayanan, batasan dan tujuan sistem ditentukan
melalui konsultasi dengan user sistem. Persyaratan ini kemudian didefinisikan secara
rinci dan berfungsi sebagai spesifikasi sistem.
2) Perancangan sistem dan perangkat lunak. Proses perancangan sistem membagi
persyaratan dalam sistem perangkat keras atau perangkat lunak. Kegiatan ini
menentukan arsitektur sistem secara keseluruhan. Perancangan perangkat lunak
melibatkan identifikasi dan deskripsi abstraksi sistem perangkat lunak yang mendasar
dan hubungan-hubungannya.
3) Implementasi dan pengujian unit. Pada tahap ini, perancangan perangkat lunak
direalisasikan sebagai serangkaian program atau unit program. Pengujian unit
melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasi.
4) Integrasi dan pengujian sistem. Unit program atau program individual diintegrasikan
dan diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem telah
dipenuhi. Setelah pengujian sistem, perangkat lunak dikirim kepada pelanggan.
5) Operasi dan pemeliharaan. Biasanya merupakan fase siklus hidup yang paling lama.
Sistem diinstall dan dipakai. Pemeliharaan mencakup koreksi dan berbagai error yang
tidak ditemukan pada tahap-tahap terdahulu, perbaikan atas implementasi unit sistem
dan pengembangan pelayanan system, sementara persyaratan-persyaratan baru
ditambahkan.

4
Gambar 1.1 Model Waterfall
b. Model Sekuensial Linier
Gambar 1.2a menggambarkan sekuensial linier untuk rekayasa perangkat lunak, yang
sering disebut juga dengan “siklus kehidupan klasik” atau “model air terjun.”
Gambar 1.2a Fase lingkaran pemecahan masalah (Raccoon, 1995)

5
Status Quo
Problem
Definition
Problem
Definition
Status
Quo
Solution
Integration
Teknikal
Development
Status
Quo
Solution
Integration
Teknikal
Development
Problem
Definition
Status
Quo
Solution
Integration
Teknikal
Development
Gambar 1.2b Fase-fase di dalam fase lingkaran pemecahan masalah (Raccoon, 1995)
Pemodelan Sistem Informasi
Analisis Desain Kode Tes
Gambar 1.3 Model sekuensial linier
Sekuensial linier mengusulkan sebuah pendekatan kepada perkembangan perangkat
lunak yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada
seluruh analisis, desain, kode, pengujian, dan pemeliharaan. Dimodelkan setelah siklus
rekayasa konvensional, model sekuensial linier melingkupi aktivitas-aktivitas sebagai
berikut:
1. Rekayasa dan Pemodelan Sistem/Informasi
Karena perangkat lunak selalu merupakan bagian dari sebuah sistem (bisbis) yang lebih
besar, kerja dimulai dengan membangun syarat dari semua elemen sistem dan
mengalokasikan beberapa subset dari kebutuhan ke perangkat lunak tersebut.
Pandangan sistem ini penting ketika perangkat lunak harus berhubungan dengan

elemen-elemen yang lain seperti perangkat lunak, manusia, dan database. Rekayasa
dan analisis sistem menyangkut pengumpulan kebutuhan pada tingkat sistem dengan
sejumlah kecil analisis serta desain tingkat puncak. Rekayasa informasi mencakup juga
pengumpulan kebutuhan pada tingkat bisnis strategis dan tingkat area bisnis.
6
2. Analisis Kebutuhan Perangkat Lunak
Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khususnya pada
perangkat lunak. Untuk memahami sifat program yang dibangun, perekayasa perangkat
lunak (analis) harus memahami domain informasi, tingkah laku, unjuk kerja, dan antar-muka
(interface) yang diperlukan. Kebutuhan baik untuk sistem maupun perangkat
lunak di dokumentasikan dan dilihat lagi dengan pelanggan.
3. Desain
Desain perangkat lunak sebenarnya adalah proses multi langkah yang berfokus pada
empat atribut sebuah program yang berbeda; struktur data, arsitektur perangkat lunak,
representasi interface, dan detail (algoritma) procedural. Proses desain menerjemahkan
syarat/kebutuhan ke dalam sebuah representasi perengkat lunak yang dapat
diperkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana
persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi perangkat
lunak.
4. Generasi Kode
Desain harus diterjemahkan ke dalam bentuk mesin yang bisa dibaca. Langkah
pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap,
pembuatan kode dapat diselesaikan secara mekanis.
5. Pengujian
Sekali kode dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika
internal perangkat lunak, memastikan bahwa semua pernyataan sudah diuji, dan pada
eksternal fungsional – yaitu mengarahkan pengujian untuk menemukan kesalahan-kesalahan
dan memastikan bahwa input yang akan memberikan hasil actual yang
sesuai dengan hasil yang dibutuhkan.
6. Pemeliharaan
Perangkat lunak akan mengalami perubahan setelah disampaikan kepada pelanggan
(perkecualian yang mungkin adalah perangkat lunak yang dilekatkan). Perubahan akan
terjadi karena kesalahan-kesalahan ditentukan, karena perangkat lunak harus

disesuaikan untuk mengakomodasi perubahan-perubahan di dalam lingkungan
eksternalnya (contohnya perubahan yang dibutuhkan sebagai akibat dari perangkat
peripheral atau sistem operasi yang baru), atau karena pelanggan membutuhkan
perkembangan fungsional atau unjuk kerja. Pemeliharaan perangkat lunak
mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang baru
lagi.
Model sekuensial linier adalah paradigma rekayasa perangkat lunak yang paling luas
dipakai dan paling tua. Tetapi kritik dari paradigma tersebut telah menyebabkan dukungan aktif
untuk mempertanyakan kehandalannya (Hanna, 1995). Masalah-masalah yang kadang–kadang
terjadi ketika model sekuensial linier diaplikasikan adalah:
a) Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model.
Meskipun model linier bias mengakomodasi iterasi, model itu melakukannya dengan cara
tidak langsung. Sebagai hasilnya, perubahan-perubahan dapat menyebabkan keraguan
pada saat tim proyek berjalan.
b) Kadang-kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya secara
ekplisit. Model linier sekuensial memerlukan hal ini dan mengalami kesulitan untuk
mengakomodasi ketidakpastian natural yang ada pada bagian awal beberapa proyek.
c) Pelanggan harus bersikap sabar. Sebuah versi kerja dari program-program itu tidak akan
diperoleh sampai akhir waktu proyek dilalui. Sebuah kesalahan besar, jika tidak terdeteksi
sampai program yang bekerja tersebut dikaji ulang, bias menjadi petaka.
d) Pengembang sering melakukan penundaan yang tidak perlu. Di dalam analisis yang
menarik tentang proyek actual, (Bradac, 1994) mendapatkan bahwa sifat alami dari siklus
kehidupan klasik membawa kepada blocking state dimana banyak anggota tim proyek
harus menunggu tim yang lain untuk melengkapi tugas yang saling memiliki
ketergantungan. Kenyataannya, waktu yang dipakai untuk menunggu bisa mengurangi
waktu untuk usaha produktif! Blocking state cenderung menjadi lebih lazim pada awal dan
akhir sebuah proses sekuensial linier.
Masing-masing dari masalah tersebut bersifat riil. Tetapi paradigm siklus kehidupan
klasik memiliki tempat yang terbatas namun penting di dalam kerja rekayasa perangkat lunak.
Paradigma itu memberikan template dimana metode analisis, desain, pengkodean, pengujian,
dan pemeliharaan bisa dilakukan. Siklus kehidupan klasik tetap menjadi model bagi rekayasa
perangkat lunak yang paling luas dipakai. Sekalipun memiliki kelemahan, secara signifikan dia
7

lebih baik daripada pendekatan yang sifatnya sembrono kepada pengembangan perangkat
lunak.
8
c. Model Prototipe
Sering seorang pelanggan mendifinisikan serangkaian sasaran umum bagi perangkat
lunak, tetapi tidak melakukan mengidentifikasi kebutuhan output, pemrosesan, ataupun
input detail. Pada kasus yang lain, pengembang mungkin tidak memiliki kepastian terhadap
efisiensi algoritme, kemampuan penyesuaian dari sebuah system operasi, atau bentuk-bentuk
yang harus dilakukan oleh interaksi manusia dengan mesin. Dalam hal ini, serta
pada banyak situasi yang lain, prototyping paradigm mungkin menawarkan pendekatan
yang terbaik.
Prototyping paradigma (Gambar 1.4) dimulai dengan pengumpulan kebutuhan.
Pengembang dan pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari
perangkat lunak, mengidentifikasi segala kebutuhan yang diketahui, dan area garis besar
dimana definisi lebih jauh merupakan keharusan kemudian dilakukan “perancangan kilat”.
Perancangan kilat berfokus pada penyajian dari aspek –aspek perangkat lunak tersebut
yang akan Nampak bagi pelanggan/pemakai (contohnya pendekatan input dan format
output). Perancangan kilat membawa kepada konstruksi sebuah prototype. Prototipe
tersebut dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaring kebutuhan
pengembangan perangkat lunak. Iterasi terjadi pada saat protipe disetel untuk memenuhi
kebutuhan pelanggan, dan pada saat yang sama memungkinkan pengembang untuk
secara lebih baik memahami apa yang harus dilakukannya.
Mendengarkan
Pelanggan
Uji Pelanggan-
Mengendalikan
Market
Membangun
Memperbaiki
Market
Gambar 1.4 Prototipe Paradigma
Secara ideal prototype berfungsi sebagai sebuah mekanisme untuk mengidentifikasi
kebutuhan perangkat lunak. Bila prototype yang sedang bekerja dibangun, pengembang
harus mempergunakan fragmen-fragmen program yang ada atau mengaplikasikan alat-alat

bantu (contohnya report generator, window manager, dll) yang memungkinkan program
yang bekerja untuk dimunculkan secara cepat.
Tetapi apa yang kita lakukan dengan prototype tersebut pada saat dia sudah melayani
9
usulan yang digambarkan di atas? (Brooks, 1975) memberikan jawabannya:
Pada sebagian besar proyek, system pertama yang dibangun baru saja bisa
dipergunakan. Sistem mungkin terlalu pelan, terlalu besar, janggal di dalam pemakaian,
atau bahkan ketiganya. Tidak ada alternatif lain selain mulai lagi, tidak dengan halus tetapi
dengan lebih halus lagi, dan membangun sebuah versi yang dirancang kembali di mana
masalah-masalah tersebut bisa diselesaikan … Ketika sebuah konsep system baru atau
teknologi baru dipergunakan, seseorang harus membangun sebuah system sebagai
pembuangan, bahkan untuk perencanaan terbaik sekalipun, tidak akan mudah untuk
membuatnya benar pada pertama kalinya. Dengan demikian, pertanyaan manajemen
tidaklah untuk membangun sebuah system contoh dan untuk membuangnya. Anda akan
melakukannya. Satu-satunya pertanyaan adalah apakah akan merencanakan lebih dulu
untuk membangun sebuah pembuangan, atau menjanjikan untuk menyampaikan
pembuangan tersebut kepada pelanggan …………..
Prototipe bisa berfungsi sebagai “system yang pertama”. Brooks setuju bila kita
membuangnya. Tetapi mungkin ini merupakan pandangan yang ideal. Memang benar
bahwa baik pelanggan maupun pengembang menyukai paradigma prototype. Para
pemakai merasa enak dengan system aktual, sedangkan pengembang bisa
membangunnya dengan segera. Tetapi prototyping bisa juga menjadi masalah karena
alasan-alasan sebagai berikut:
a) Pelanggan melihat apa yang tampak sebagai versi perangkat lunak yang bekerja tanpa
melihat bahwa prototype itu dijalin bersama-sama “dengan permen karet dan baling
wire”, tanpa melihat bahwa di dalam permintaan untuk membuatnya bekerja, kita
belum mencantumkan kualitas perangkat lunak secara keseluruhan atau kemampuan
pemeliharaan untuk jangka waktu yang panjang. Ketika diberi informasi bahwa produk
harus dibangun lagi agar tingkat kualitas yang tinggi bisa dijaga, pelanggan akan
meneriakkan kecurangan dan permintaan agar dipakai “beberapa campuran” untuk
membuat protipe menjadi sebuah produk yang bekerja yang lebih sering terjadi,
sehingga manajemen pengembangan perangkat lunak menjadi penuh dengan belas
kasihan.
b) Pengembang sering membuat kompromi-kompromi implementasi untuk membuat
prototype bekerja dengan cepat. Sistem operasi atau bahasa pemrograman yang tidak

sesuai bisa dipakai secara sederhana karena mungkin diperoleh dan dikenal; algoritma
yang tidak efisien secara sederhana bisa diimplementasikan untuk mendemontrasikan
kemampuan. Setelah selang waktu tertentu, pengembang mungkin mengenali pilihan-pilihan
tersebut dan melupakan semua alasan mengapa mereka tidak cocok. Pilihan
10
yang kurang ideal telah menjadi bagian integral dari sebuah system.
Meskipun berbagai masalah bisa terjadi, prototype bisa menjadi paradigm yang efektif
bagi rekayasa perangkat lunak. Kuncinya adalah mmendefinisikan aturan-aturan main pada
saat awal; yaitu pelanggan dan pengembang keduanya harus setuju bahwa prototype
dibangun untuk berfungsi sebagai mekanisme pendefinisian kebutuhan. Prototipe
kemudian disingkirkan (paling tidak sebagian), dan perangkat lunak actual direkayasa
dengan tertuju kepada kualitas dan kemampuan pemeliharaan.
d. Pengembangan Evolusioner
Pengembangan evolusioner berdasarkan ide untuk mengembangkan implementasi awal,
memperlihatkannya kepada user untuk dikomentari, dan memperbaikinya versi demi versi
sampai sistem yang memenuhi persyaratan diperoleh. Model pengembangan evolusioner
dapat dilihat pada Gambar 1.5.
VersVi emresin aeknhgiar h
Versi akhir
Spesifikasi
Pengembangan
Validasi
Penjelasan garis
besar
Versi awal
Versi akhir
Gambar 1.5 Model Evolusioner
e. Pengembangan Sistem Formal
Pengembangan sistem formal merupakan pendekatan terhadap pengembangan perangkat
lunak yang memiliki kesamaan dengan model air terjun (waterfall). Tetapi proses
pengembangannya didasarkan pada transformasi matematis dari spesifikasi sistem menjadi
program yang dapat dijalankan. Model pengembangan sistem formal dapat dilihat pada
Gambar 1.6.

11
Gambar 1.6 Model Sistem Formal
f. Pengembangan Berorientasi Pemakaian Ulang
Pada pengembangan perangkat lunak yang besar, terjadi pemakaian ulang. Hal ini
biasanya terjadi secara informal ketika orang yang bekerja di proyek tersebut mengetahui
adanya rancangan atau kode yang mirip dengan yang dibutuhkan. Mereka mencari
rancangan atau kode ini, memodifikasinya sebagaimana dibutuhkan, dan
menggabungkannya dalam sistem. Model pengembangan berorientasi pemakaian ulang
dapat dilihat pada Gambar 1.7.
Spesifikasi
Persyaratan
Analisis
Komponen
Memodifikasi
Persyaratan
Perancangan Sistem
dengan pemakaian
ulang
Pengembangan dan
integrasi
Validasi Sistem
Gambar 1.7 Model Pengembangan Berorientasi Pemakaian Ulang
B. KEGUNAAN RPL
Perangkat lunak kini sudah menjadi kekuatan yang menentukan. Perangkat lunak
menjadi mesin yang mengendalikan pengambilan keputusan di dalam dunia bisnis. Berfungsi
sebagai dasar dari semua bentuk pelayanan serta penelitian keilmuan modern. Perangkat lunak
dilekatkan pada semua sistem, seperti transportasi, medis, telekomunikasi, militer, proses
industri, hiburan, produk kantor dan sebagainya. Program-program perangkat lunak sudah
tersebar secara luas, dan masyarakat memandangnya sebagai kenyataan teknologi dalam
kehidupan.

12
C. PERKEMBANGAN RPL
Selama masa awal era komputer, perangkat lunak dilihat hanya sebagai suatu
permenungan. Pemrograman komputer menjadi seni di mana di situ terdapat banyak metode
yang sistematis. Perkembangan perangkat lunak sebenarnya tidak dapat diatur sampai terjadi
jadwal yang bergeser, atau biaya yang mulai melonjak. Para pemrogram kemudian mulai
berusaha untuk membuat semuanya benar kembali.
Era kedua evolusi sistem komputer melingkupi decade pertengahan tahun 1960 dan
1970-an. Sistem multiprogram dan multiprosesor memperkenalkan konsep baru interkasi
manusia dan komputer. Konsep ini membuka sebuah dunia aplikasi yang baru serta tingkat
kecanggihan perangkat lunak dan perangkat keras yang baru pula. Sistem real-time dapat
mengumpulkan, menganalisis, serta mengubah data dari banyak sumber sehingga proses
pengontrolan dan penghasilan output tidak lagi berada dalam skala menit, melainkan detik.
Kemajuan dalam penyimpanan online membawa ke generasi pertama sistem manajemen
database.
Tabel 1.1 perkembangan RPL
Tahun-Tahun Awal Era Kedua Era Ketiga Era Keempat
- Orientasi Batch
- Distribusi terbatas
- Perangkat lunak
customisasi
- Multiuser
- Real-time
- Database
- Perangkat lunak
produk
- Sistem terdistribusi
- Embedded
intelligence
- Perangkat keras
rendah biaya
- System desktop
bertenaga kuat
- Teknologi
berorientasi
objek
- Sistem pakar
- Jarigan syaraf
tiruan
- Komputasi
parallel
- Komputer
jaringan
D. DESKRIPSI RPL
Secara umum rekayasa perangkat lunak memakai pendekatan yang sistematis dan
terorganisir terhadap pekerjaan karena cara ini seringkali paling efektif untuk menghasilkan
perangkat lunak. Rekayasa perangkat lunak adalah disiplin ilmu yang membahas semua aspek
produksi perangkat lunak. Mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem
setelah digunakan. Pada definisi ini ada dua istilah kunci:
1) Disiplin Rekayasa
Perekayasa membuat suatu alat bekerja. Mereka menerapkan teori, metode, dan alat bantu
yang sesuai. Selain itu mereka juga menggunakannya dengan selektif dan selalu mencoba
mencari solusi terhadap permasalahan, walaupun tidak ada teori atau metode yang

mendukung. Perekayasa juga menyadari bahwa mereka harus bekerja dalam batasan
organisasi dan keuangan, sehingga mereka berusaha mencari solusi dalam batasan-batasan
ini.
13
2) Semua Aspek Produksi Perangkat Lunak
Rekayasa perangkat lunak tidak hanya berhubungan dengan proses teknis dari
pengembanga perangkat lunak, tetapi juga dengan kegiatan seperti manajemen proyek
perangkat lunak dan pengembangan alat bantu, metode, dan teori untuk mendukung
produksi perangkat lunak.
E. KARAKTERISTIK RPL
Perangkat lunak lebih kepada logika dan bukan semata elemen fisik. Perbedaan perangkat
lunak dengan perangkat keras yang mendasar adalah:
1) Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuknya yang klasik.
2) Perangkat lunak tidak pernah usang.
Sebagian besar perangkat lunak dibuat secara custom (pemesanan) serta tidak dapat dirakit
dari komponen yang sudah ada.
F. KOMPONEN RPL
Bersamaan dengan perkembangan disiplin keteknikan diciptakan sekumpulan
komponen perancangan standar. Komponen-komponen yang dapat digunakan lagi sudah
diciptakan sehingga ahli teknik dapat benar-benar berkonsentrasi pada elemen-elemen inovatif
suatu perancangan. Dalam dunia perangkat keras hal ini merupakan hal yang harus dicapai
dalam skala yang luas.
Reusability meruapakan suatu cirri penting dari komponen perangkat lunak kualitas
tinggi. Sebuah komponen perangkat lunak harus didesain dan diimplementasi sehingga dapat
dipakai lagi pada berbagai program yang berbeda. Komponen perangkat lunak dibangun
dengan bahasa pemrograman yang memiliki kosakata terbatas, sebuah tata bahasa yang
dibatasi secara eksplisit. Bahasa tingkat mesin merupakan perwakilan simbolik dari
serangkaian instruksi CPU. Bahasa tingkat menengah memungkinkan pengembang
perangkat lunak serta program tidak bergantung pada mesin.
G. APLIKASI RPL
Perangkat lunak dapat diaplikasikan ke berbagai situasi dimana serangkaian procedural
(seperti algoritma) telah didefinisikan (pengecualian-pengecualian yang dapat dicatatat pada
aturan ini adalah sistem pakar dan jaringan syaraf tiruan dalam aplikasi kecerdasan buatan).

Kandundan informasi dan determinasi merupakan faktor penting dalam menentukan sifat
aplikasi perangkat lunak.
14
EVALUASI
1) Apakah yang dimaksud dengan perangkat lunak?
2) Apakah rekayasa perangkat lunak itu?
3) Apa perbedaan antara rekayasa perangkat lunak dan computer science?
4) Apa perbedaan rekayasa perangkat lunak dan rekayasa sistem?
5) Apakah yang dimaksud dengan proses perangkat lunak?
6) Apakah model proses perangkat lunak itu?

15
BAB 2
MANAGING SOFTWARE PROJECTS
A. PROJECT MANAGEMENT CONCEPT
Manajemen perangkat lunak yang efektif berfokus pada tiga P (people/manusia), P
(Problem/masalah) dan P (Process/proses). Manajer proyek yang lupa bahwa kerja rekayasa
perangkat lunak merupakan usaha manusia yang intens tidak akan pernah meraih sukses dalam
manajemen proyek.
1. People
Faktor manusia sangat penting sehingga software engineering institute telah
mengembangkan sebuah model untuk mempertinggi kesiapan ornganisasi perangkat lunak
untuk mengerjakan aplikasi yang semakin kompleks. Model kematangan manajemen manusia
mencakup rekruitmen, seleksi, menajamen untuk kerja, pelatihan, kompensasi, perkembangan
karir, desain kerja dan organisasi serta perkembangan kultur.
Proses perangkat lunak diisi oleh para pemain yang dapat dikategorikan ke dalam salah
satu dari lima kelompok sebagai berikut:
1) Manajer Senior, yang menentukan isu-isu bisnis yang sering memiliki pengaruh
penting di dalam proyek.
2) Manajer (teknik) proyek, yang harus merencanakan, memotivasi, mengorganisir dan
mengontrol sebuah produk atau aplikasi.
3) Pelaksana, yang menyampaikan ketrampilan teknik yang diperlukan untuk
merekayasa sebuah produk atau aplikasi.
4) Pelanggan, yang menentukan jenis kebutuhan bagi perangkat lunak yang akan
direkayasa.
5) Pemakai akhir, yang berinteraksi dengan perangkat lunak bila perangkat lunak telah
dikeluarkan untuk digunakan.
Setiap proyek perangkat lunak dihuni oleh para pemain seperti yang tersebut di atas.

16
2. Problem
Seorang manajer proyek perangkat lunak dihadapkan pada sebuah dilemma pada awal
proyek rekayasa perangkat lunak. Analisis yang mendetail tentang kebutuhan perangkat lunak
akan memberikan informasi yang memadai untuk suatu perhitungan, tetapi analis sering
memerlukan waktu berminggu-minggu atau bahkan berbulan-bulan. Lebih buruk lagi,
kebutuhan terkadang berubah-ubah.
Aktivitas manajemen proyek perangkat lunak yang pertama adalah menentukan ruang
lingkup perangkat lunak. Ruang lingkup dibatasi dengan menjawab pertanyaan berikut:
Konteks. Bagaimana perangkat lunak yang akan dibangun dapat memenuhi sebuah
sistem, produk, atau konteks bisnis yang lebih besar, serta batasan apa yang
ditentukan sebagai hasil dari konteks tersebut.
Tujuan informasi. Objek data pelanggan apa yang dihasilkan sebagai output dari
perangkat lunak? Objek data apa yang diperlukan sebagai input?
Fungsi dan unjuk kerja. Fungsi apa yang dilakukan oleh perangkat lunak untuk
mentransformasikan input data menjadi output? Adakah ciri khusus yang akan
ditekankan?
Ruang lingkup proyek tidak boleh ambigu dan dapat dipahami pada tingkat teknis
maupun manajemen. Selama aktivitas penentuan ruang lingkup berlangsung, tidak ada usaha
untuk secara penuh melakukan dekomposisi masalah. Dekomposisi diterapkan pada dua area
utama (1) fungsionalitas yang harus disampaikan dan (2) proses yang akan dipakai untuk
menyampaikannya.
3. Process
Perencanan proyek dimulai dengan menggabungkan masalah dan proses. Setiap fungsi
yang akan direkayasa oleh tim perangkat lunak harus melampaui sejumlah aktivitas kerangka
kerja yang sudah ditentukan bagi sebuah organisasi perangkat lunak.
Tim perangkat lunak harus memiliki tingkat fleksibilitas yang signifikan dalam memilih
paradigm rekayasa perangkat lunak yang paling baik bagi proyek dan tugas rekayasa perangkat
lunak.

17
4. Project
Para professional industry yang payah sering mengacu aturan 90-90 pada saat
mendiskusikan proyek-proyek perangkat lunak yang sukar : 90 persen dari sistem yang
pertama menyerap 90 persen dari usaha dan waktu yang diberikan. Yang 10 persen terakhir
mengambil 90 persen lain dari usaha dan waktu yang diberikan.
Proses manajemen proyek perangkat lunak dimulai dengan serangkaian aktivitas yang
secara kolektif disebut project planning. Yang pertama dari aktivitas ini adalah estimation
(perkiraan). Meskipun estimasi juga merupakan sebuah seni seperti juga pada sains, aktivitas
yang penting itu tidak perlu dilakukan dengan cara serampangan. Benar-benar ada teknik yang
berguna untuk mengestimasi waktu dan usaha. Karena estimasi menjadi dasar bagi semua
aktivitas perencanaan proyek yang lain, dan perencanaan proyek memberikan sebuah peta
jalan bagi suksesnya rekayasa perangkat lunak, maka tanpa estimasi kita tidak dapat berjalan
dengan baik.
B. SOFTWARE PROJECT PLANNING
1. Observation On Estimation
Estimasi sumber daya, biaya dan jadwal untuk usaha pengembangan perangkat lunak
membutuhkan pengalaman, mengakses informasi historis yang baik, dan keberanian untuk
melakukan pengukuran kuantitatif bila hanya data kualitatif saja yang ada. Estimasi membawa
resiko yang inheren dan resiko inilah yang membawa kepada ketidak pastian.
Kompleksitas proyek berpengaruh kuat terhadap ketidak pastian yang inheren dalam
perencanaan. Tetapi kompleksitas merupakan pengukuran relative yang dipengaruhi oleh
kebiasaan dengan usaha yang sudah dilakukan pada masa sebelumnya.
Ukuran proyek merupakan factor penting lain yang dapat mempengaruhi akurasi
estimasi. Bila ukuran bertambah maka ketergantungan diantara berbagai elemen perangkat
lunak akan meningkat dengan cepat. Dekomposisi masalah sebagai suatu pendekatan yang
sangat penting dalam proses estimasi menjadi lebih sulit lagi karena elemen-elemen yang akan
didekomposisi masih sangat berat.
Tingkat ketidak pastian structural juga berpengaruh dalam resiko estimasi. Resiko
diukur melalui tingkat ketidakpastian pada estimasi kuantitatif yang dibuat untuk sumber daya,
biaya dan jadwal. Bila ruang lingkup proyek tidak dipahami dengan baik atau syarat proyek

merupakan subjek terjadinya perubahan, maka resiko dan ketidakpastian menjadi sangat tinggi.
Perencana perangkat lunak harus melengkapi fungsi, kinerja, dan definisi interface.
Manejer proyek tidak perlu obsesif terhadap estimasi. Pendekatan-pendekatan rekayasa
perangkat lunak modern memakai pandangan pengembangan yang interaktif. Pada pendekatan
semacam ini dimungkinkan untuk melihat lagi estimasi dan merevisinya bila pelanggan
mengubah kebutuhannya.
2. Software Scope
Tujuan perencanaan proyek perangkat lunak adalah untuk menyediakan sebuah
kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat
dipertanggungjawabkan mengenai sumber daya, biaya dan jadwal. Estimasi dibuat dengan
sebuah kerangka waktu yang terbatas pada awal sebuah proyek perangkat lunak dan
seharusnya diperbaharui secara teratur selagi proyek sedang berjalan. Tujuan perencanaan
dicapai melalui suatu proses penemuan informasi yang menunjuk estimasi yang dapat
dipertanggungjawabkan. Aktivitas pertama dalam perencanaan proyek perangkat lunak adalah
penentuan ruang lingkup perangkat lunak. Ruang lingkup perangkat lunak menggambarkan
fungsi, kinerja, batasan, interface dan reliabilitas. Fungsi-fungsi yang digambarkan dalam ruang
lingkup dievaluasi dan dalam banyak kasus juga disaring untuk memberikan awalan yang lebih
detail pada saat estimasi dimulai.
Teknik yang banyak dipakai secara umum untuk menjembatani jurang komunikasi
antara pelanggan dan pengembang serta untuk memulai proses komunikasi adalah dengan
melakukan pertemuan atau wawancara pendahuluan. Perangkat lunak berinteraksi dengan
elemen sistem berbasis computer lainnya. Perencana mempertimbangkan sifat dan
kompleksitas masing-masing interface untuk menentukan pengaruhnya terhadap sumber daya,
biaya dan jadwal pengembangan.
3. Resource
Tugas selanjutnya dalam perencanaan proyek perangkat lunak adalah estimasi sumber
daya yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak tersebut.
Gambar 2.1 memperlihatkan sumber daya pengembangan sebagai sebuah pyramid.
18

19
Gambar 2.1 Sumber Daya Proyek
Gambar 2.1 memperlihatkan bahwa lingkungan pengembangan perangkat keras dan
perangkat lunak berada pada fondasi pyramid sumber daya dan menyediakan infrastruktur
untuk mendukung usaha pengembangan.
Dalam tingkat yang lebih tinggi kita menemukan komponen perangkat lunak reuseable.
Blok bangungan perangkat lunak yang dapat mengurangi biaya pengembangan secara dramatis
dan mempercepat penyampaian. Di puncak piramida terdapat sumber daya utama yaitu
manusia (people). Masing-masing sumber daya ditentukan dengan empat karakteristik.
Jumlah orang/manusia yang diperlukan untuk sebuah proyek perangkat lunak dapat
ditentukan hanya setelah sebuah estimasi usaha pengembangan dibuat. Teknik untuk usaha
estimasi didiskusikan pada bagian selanjutnya dari bab ini.
4. Software Project Estimation
Pada masa awal perhitungan biaya perangkat lunak terdiri dari presentase kecil biaya
sistem berbasis computer secara kesuluruhan. Urutan kesalahan besaran pada estimasi biaya
perangkat lunak memiliki pengaruh yang relative kecil. Sekarang perangkat lunak menjadi
elemen paling mahal di dalam sebagian besar sistem berbasis komputer.
Esimasi biaya dan usaha perangkat lunak tidak akan pernah menjadi ilmu pasti.
Variable yang terlalu banyak seperti manusia, teknik, lingkungan, politik dapat mempengaruhi
biaya dan usaha akhir yang diaplikasikan untuk mengembangkannya. Namun demikian estimasi
proyek perangkat lunak dapat ditransformasi dari suatu seni yang misterius ke dalam langkah-langkah
yang sistematis yang memberikan estimasi dengan resiko yang dapat diterima.

20
C. RISK ANALYSIS AND MANAGEMENT
Setelah hasil dari feasibility plan dipresentasikan, proyek dapat dilanjutkan sampai
dengan tahap penyelesaiannya. Yang dibutuhkan setelah presentasi feasibility plan adalah
menambah input (masukan) terhadap proyek. Hasil dari riset yang telah dilakukan mungkin
saja harus ditambahkan dengan masukan-masukan baru, sehingga hasil akhir yang diharapkan
dapat dicapai.
Tambahan masukan untuk proyek ini dapat dilakukan antara lain dengan cara:
1) Dari hasil presentasi dengan tim manajemen (feed-back input);
2) Lewat informasi proyek-proyek sejenis sebelumnya, melalui perpustakaan, Internet,
database IT vendors, laporan ilmiah, jurnal ilmiah, dsb;
3) Lewat wawancara dengan pemakai akhir dan/atau personal yang pernah menggunakan
produk sejenis, sponsor, dsb.
Contoh penambahan informasi untuk kelangsungan proyek ini dapat berupa antara lain:
1) Pertanyaan dari pihak management mengapa tidak menggunakan teknologi lain yang
lebih murah;
2) Harapan dari pihak pengguna bahwa program software yang akan dibuat mudah untuk
dimengerti juga oleh mereka yang tidak memiliki basis IT yang kuat;
3) Adanya data dari database perusahaan bahwa di proyek sebelumnya teknologi terpilih
ternyata memiliki kelemahan mendasar, seperti ketidakstabilan suatu program yang
ditulis dalam Java di dalam lingkungan windows.
Perlu diingat informasi tambahan ini hanya sebagai masukan dan harus dicari solusi
pemecahan bila memang menghambat jalannya proyek. Tidak diharapkan bahwa informasi
tambahan justru akan membuat proyek menjadi tersendat.
Yang tetap menjadi acuan harus tetap feasibility plan yang semula. Karena dari feasibility plan,
diharapkan:
1) Memenuhi keinginan pemberi order;
2) Dapat menggunakan teknologi yang sepadan dengan kriteria;
3) Dapat menyusun biaya dan rencana kerja lebih detail (dan mungkin lebih rendah dari
perkiraan semula);
Sebagai bahan untuk presentasi pada pihak manajemen dan pengguna (report dan
speech work) serta dapat dijadikan suatu kekuatan untuk negotiating position.

21
Adapun dalam manajemen risiko tujuan yang hendak dicapai adalah:
1) Identifikasi terhadap risiko;
2) Evaluasi (analisa) risiko dan (estimasi) pengaruhnya terhadap proyek;
3) Mengembangkan responsi terhadap risiko;
4) Mengontrol responsi risiko.
Identifikasi Proyek
Input:
ƒ Deskripsi
produk
ƒ Rencana
proyek (WBS,
biaya, staff,
perekrutan)
ƒ Informasi
histori
Output:
ƒ Sumber-sumber
risiko
ƒ Potensi risiko
ƒ Tanda-tanda
risiko (trigger)
ƒ Input ke
proses
lainnya
Teknik:
ƒ Checklist
ƒ Flowchart
ƒ Wawancara
Identifikasi risiko terdiri atas pengawasan dan penentuan risiko apa saja yang dapat
mempengaruhi proyek serta mendokumentasikan setiap dari risiko tersebut. Identifikasi tidak
hanya dilakukan sekali, namun harus dilakukan sepanjang perjalanan proyek dari awal sampai
akhir.
Faktor internal di dalam serta eksternal di luar proyek harus diidentifikasi. Faktor
internal antara lain penugasan anggota tim kerja, perhitungan biaya dan waktu, serta support
dan pengaruh dari tim manajemen. Faktor eksternal antara lain melibatkan kebijaksanaan
pemerintah, bencana alam, dan hal-hal lain di luar kontrol atau pengaruh tim proyek.
Identifikasi terhadap risiko harus melibatkan pengaruh baik maupun pengaruh buruk dari
pengaruh faktor-faktor penentu risiko.
Dari gambar di atas dapat dilihat input bagi identifikasi risiko adalah:
1) Diskripsi produk
Produk yang berbasis pada teknologi yang telah dibuktikan kebenarannya memiliki
risiko yang lebih kecil dibandingkan dengan produk yang menuntut inovasi dan
penemuan.

22
2) Rencana proyek
a. Work breakdown structure: pendekatan pada deliverables setiap unit kerja secara
detail. Dengan cara ini identifikasi terhadap risiko bisa sampai ke level yang sangat
detail;
b. Estimasi biaya dan waktu: estimasi yang terlalu kasar dan terburu-buru dapat
meningkatkan risiko proyek.
c. Penempatan SDM: setiap pekerjaan yang spesifik dan hanya dapat dilakukan oleh
orang tertentu meningkatkan risiko proyek, apabila orang tersebut berhalangan
untuk hadir;
d. Perekrutan dan sub-kontraktor: pengaruh ekonomi dan kebijakan politik di sekitar
proyek dapat menyebabkan fluktuasi nilai kontrak proyek.
3) Informasi historis. hal-hal yang pernah terjadi di masa lalu, dan berkaitan dengan
proyek dapat dilihat dari:
a. File-file proyek sejenis dari perusahaan;
b. Database komersial, contohnya: Internet knowledge-bases;
c. Ilmu dan pengalaman dari tim kerja, dikenal juga dengan sebutan: tacit knowledge.
Untuk teknik yang digunakan dalam proses identifikasi risiko adalah:
1) Checklist: dari informasi (riset, dll) yang diperoleh dapat dibuat checklist yang mendata
sumber-sumber risiko;
2) Flowcharting: dapat digunakan untuk menggambarkan penyebab dan efek dari risiko
yang ada;
3) Wawancara: data-data yang tersimpan dari hasil wawancara proyek-proyek terdahulu
dapat digunakan sebagai referensi, dan juga masukan dari stakeholders merupakan
sumber informasi yang berpengaruh untuk mengidentifikasi risiko.
Adapun hasil output dari pengidentifikasian risiko adalah:
1) Daftar sumber-sumber risiko
a. Yang seringkali menjadi sumber risiko proyek antara lain: perubahan requirements,
kesalahan design, pendefinisian peran kerja yang lemah, kesalahan estimasi, dan
tim kerja yang kurang mapan.
b. Pada umumnya penjelasan mengenai sumber-sumber risiko ini disertai pula dengan:
perhitungan kemungkinan terjadinya risiko tersebut, kemungkinan akibat dari risiko
tersebut, kemungkinan kapan terjadinya, pengantisipasian tindakan terhadap risiko
tersebut.

2) Kejadian yang berpotensi menjadi risiko: biasanya merupakan kejadian-kejadian luar
biasa yang jarang terjadi.
a. Contohnya bencana alam, perkembangan teknologi baru yang tiba-tiba.
b. Tanda-tanda datangnya risiko (risk symptoms), sering juga disebut triggers, sebab-sebab
23
yang mengakibatkan munculnya bencana pada saat ini.
c. Contohnya biaya yang mengembang pada awal proyek disebabkan oleh estimasi
yang terburu-buru dan tidak akurat.
Input pada proses-proses lainnya: identifikasi risiko mungkin saja menyebabkan
diperlukannya pelaksanaan suatu aktivitas di area lain. Contohnya: bila identifikasi risiko
memperkirakan bahwa harga barang kebutuhan utama proyek akan naik, maka ada baiknya
pada penjadwalan, pembelian barang utama tersebut dilakukan di awal proyek.
Kuantifikasi risiko meliputi pengevaluasian serta interaksi antara risiko dan akibatnya.
Input:
1) Toleransi dari stakeholders dan sponsor: setiap organisasi memiliki toleransi yang
berbeda-beda terhadap risiko. Ada yang hanya 10% dari modal, tapi ada juga yang
berani hingga 40% dari modal proyek, asalkan proyek selesai tepat waktu.
2) Sumber risiko (dibahas di atas);
3) Kejadian yang berpotensi menjadi risiko(dibahas di atas);
4) Estimasi waktu dan biaya (akan dibahas pada Manajemen waktu dan biaya);
Teknik:
1) Perkiraan nilai moneter: bagaimana efek sebuah risiko yang telah dievaluasi nilainya?
Mungkin ada yang risiko yang kemungkinannya kecil, tapi nilai risikonya dapat
membuat proyek berhenti. Ada pula risiko yang kemungkinannya besar, tetapi efeknya
kecil terhadap jalannya proyek.
2) Perhitungan statistik: menghitung jangkauan (range) perhitungan minimum dan
maksimum untuk biaya dan penjadwalan kerja proyek.
3) Simulasi model: dengan bantuan model yang disimulasikan dapat diketahui estimasi
yang lebih tepat, contoh: penggunaan model statistik Monte Carlo untuk menghitung
estimasi durasi proyek.
4) Decision trees: diagram yang memberikan alur kemungkinan dan interaksi antara
keputusan serta akibatnya.
5) Penilaian ahli: penilaian ahli dapat digunakan sebagai masukan tambahan setelah
penggunaan teknik-teknik di atas.

24
Output:
Setelah dianalisis, manajer proyek harus mampu memutuskan berbuat apa terhadap
risiko yang mungkin ada. Menerimanya, membuat rencana lanjutan atau mencari alternatif lain
yang tidak terpengaruh risiko.
D. SQA
Banyak pengembang perangkat lunak terus percaya bahwa kualitas perangkat lunak
merupakan sesuatu yang mulai dikhawatirkan setelah kode-kode dihasilkan.
1. Quality
American Heritage Dictionary mendefinisikan kata kualitas sebagai sebuah karakteristik
atau atribut dari sesuatu. Sebagai atribut dari sesuatu, kualitas mengacu pada karakteristik
yang dapat diukur, sesuatu yang dapat kita bandingkan dengan standar yang sudah diketahui,
seperti panjang, warna, sifat kelistrikan, kelunakannya dan sebagainya. Tetapi perangkat lunak,
yang sebagaian besar merupakan entitas intelektual lebih menantang untuk dikarakterisasi
daripada objek fisik.
Ada dua jenis kualitas yaitu kualitas desain dan kualitas konformasi. Kualitas desain
mengacu pada karakteristik yang ditentukan oleh desainer terhadap suatu item tertentu.
Kualitas konformansi adalah tingkat dimana spesifikasi desain terus diikuti selama
pembuatan. Dalam pengembangan perangkat lunak kualitas desain mencakup syarat,
spesifikasi, dan desain sistem. Kualitas konformansi adalah suatu masalah yang difokuskan
pada implementasi. Bila implementasi mengikuti desain dan sistem yang dihasilkan memenuhi
persyaratan serta tujuan kinerja, maka kualitas konformansi menjadi tinggi.
2. Quality Control
Kontrol kualitas merupakan serangkaian pemeriksaan, kajian dan pengujian yang
digunakan pada keseluruhan siklus pengembangan untuk memastikan bahwa setiap produk
memenuhi persyaratan yang ditetapkan. Kontrol kualitas mencakup perulangan (loop) umpan
balik pada proses yang menciptakan produk kerja.
Aktivitas kualitas kontrol dapat menjadi otomatis sepenuhnya, manual secara
kesuluruhan, atau kombinasi antara piranti otomatis dan interaksi manusia. Konsep kunci
kualitas kontrol adalah bahwa semua produk kerja memiliki spesifikasi yang telah ditentukan
dan dapat diukur di mana kita dapat membandingkan output dari setiap proses.

25
3. Quality Assurance
Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen. Tujuan jaminan
kualitas adalah untuk memberikan data yang diperlukan oleh manajemen untuk
menginformasikan masalah kualitas produk, sehingga dapat memberikan kepastian dan
kepercayaan bahwa kualitas produk dapat memenuhi sasaran. Jika data yang diberikan melalui
jaminan kualitas mengidentifikasikan adanya masalah, maka adalah tanggung jawab
manajemen untuk menetapkan masalahnya dan mengaplikasikan sumber-sumber daya yang
dibutuhkan untuk memecahkan masalah kualitas tersebut.
4. Cost Of Quality
Biaya kualitas menyangkut semua biaya yang diadakan untuk mengejar kualitas atau
untuk menampilkan kualitas yang berhubungan dengan aktivitas. Studi tentang biaya kualitas
dilakukan untuk memberikan garis besar bagi biaya kualitas yang sedang digunakan untuk
mengidentifikasi kemungkinan pengurangan biaya kualitas serta memberikan basis
perbandingan yang ternormalisasi.
Biaya kegagalan adalah biaya yang akan hilang bila tidak ada cacat yang muncul
sebelum produk disampaikan kepada pelanggan. Biaya kegagalan dapat dibagi lagi ke dalam
biaya kegagalan internal dan eksternal. Biaya kegagalan internal adalah biaya yang diadakan
bila kita mendeteksi suatu kesalahan dalam produk sebelum produk dipasarkan.
EVALUASI
1) Sebutkan 5 kelompok manusia yang terlibat dalam proses pengembangan perangkat
lunak?
2) Bagaimanakah cara membatasi ruang lingkup proyek?
3) Apakah tujuan dari perencanaan proyek perangkat lunak?
4) Sebutkan dan jelaskan jenis kualitas yang melekat pada perangkat lunak?

26
BAB 3
METODE KONVENSIONAL UNTUK
SOFTWARE ENGINEERING
A. SYSTEM ENGINEERING
Empat ratus dan lima ratus tahun yang lalu, Machiavelli pernah berkata, “Tidak ada
yang lebih sukar untuk dilakukan, lebih membahayakan untuk dilakukan atau lebih tidak pasti
dalam keberhasilannya, daripada memimpin di dalam pembukaan orde yang baru.” Selama
kuartal terakhir abad ke-20, sistem berbasis komputer telah memperkenalkan tatanan baru.
Meskipun teknologi telah membuat langkah benar sejak pernyataan Machiavelli, ungkapan
yang dikatakannya itu masih tetap bergema sampai sekarang.
Rekayasa perangkat lunak terjadi sebagai konsekuensi dari suatu proses yang disebut
rekayasa sistem. Daripada berkonsentrasi semata-mata pada perangkat lunak, rekayasa
sistem memfokuskan diri pada berbagai elemen, analisis, perancangan, dan pengorganisasian
elemen-elemen tersebut ke dalam suatu sistem yang dapat menjadi sebuah produk , jasa,
atau teknologi untuk mentransformasi informasi atau kontrol.
Proses rekayasa sistem disebut rekayasa informasi bila konteks kerja rekayasa
berfokus pada perusahaan bisnis. Pada saat produk akan dibuat, prose situ disebut rekayasa
produk.
Baik rekayasa informasi maupun rekayasa produk cenderung untuk membawa orde
kepada pengembangan sistem berbasis komputer. Meskipun masing-masing diterapkan di
dalam domain aplikasi yang berbeda, keduanya berusaha untuk meletakkan perangkat lunak
ke dalam konteks. Baik rekayasa informasi maupun rekayasa produk kerja untuk
mengalokasikan suatu peran bagi perangkat lunak ke elemen sistem berbasis komputer
lainnya.
1. Computer Based System
Tujuannya mungkin adalah untuk mendukung berbagai fungsi bisnis atau untuk
mengembangkan suatu produk yang dapat dijual untuk menghasilkan keuntungan bisnis. Untuk
mencapai tujuan tersebut, sistem berbasis komputer menggunakan berbagai elemen sistem:
1) Perangkat lunak.

Program computer, struktur data, dan dokumen yang berhubungan yang berfungsi
untuk mempengaruhi metode logis, prosedur, dan kontrol yang dibutuhkan.
27
2) Perangkat keras
Perangkat elektronik yang memberikan kemampuan penghitungan, dan perangkat
elektromekanik (misalnya, sensor, rotor, pompa) yang memberikan fungsi dunia
eksternal.
3) Manusia
Pemakai dan operator perangkat keras dan perangkat lunak.
4) Database
Kumpulan informasi yang besar dan terorganisasi yang diakses melalui perangkat
lunak.
5) Dokumentasi
Manual, formulir, dan informasi deskriptif lainnya yang menggambarkan
penggunaan dan atau pengoperasian sistem.
6) Prosedur
Langkah-langkah yang menentukan penggunaan khusus dari masing-masing
elemen sistem atau konteks prosedural di mana sistem berada.
Satu karakteristik sistem berbasis komputer yang rumit adalah bahwa elemen yang
berisi satu sistem juga dapat mewakili satu elemen makro dari suatu sistem yang sangat besar.
Elemen makro adalah suatu sistem berbasis komputer yang merupakan bagian dari sistem
berbasis komputer yang lebih besar lagi. Sebagai contoh, perhatikan”sistem otomasisasi pabrik”
yang pada dasarnya merupakan hirarki sistem yang diperlihatkan pada gambar 3.1. Pada
tingkat yang paling rendah dari hirarki tersebut, kita memiliki mesin kontrol numerik, robot, dan
perangkat pemasukan data. Masing-masing merupakan sistem berbasis komputer. Elemen-elemen
dari mesin kontrol numerik tersebut adalah perangkat keras elektronik dan
elektromekanik (misalnya, prosesor dan memori, motor, sensor); perangkat lunak (untuk
komunikasi, kontrol mesin, dan intrpolasi); manusia (operator mesin); database (program NC
yang disimpan); dan dokumentasi serta prosedur. Dekomposisi yang sama dapat juga
diterapkan untuk robot dan perangkat pemasukan data. Masing-masing merupakan sistem
berbasis komputer.

Tingkat se
nukfaturan m
nya, kompute
kita sebut mes
peman
(misaln
yang k
Singkatnya,
n-elemen sist
ase, prosedu
gunakan elem
diatur oleh
k eksklusif be
elemen
databa
mengg
dapat
generik
Peran reka
sis computer
b berikut kita
ystem Eng
berbas
subbab
2. Sy
Tanpa melih
(top-down)
asikan pada g
WV), yaitu
bawah
diilustr
view (
Gam
mbar 3.1 Siste
lanjutnya pa
merupakan s
er, perlengka
sin kontrol nu
em Dari Banya
ada hirarki,
siste berbasis
pan mekanis
umerik, robot
, sel pemanu
tem dengan
ur, dan do
men generik s
seorang ope
ersifat untuk s
ak Sistem
(Gambar 3.1
s komputer
s) dan juga m
dan perangka
ukfaturan dan
label gener
kumentasi.
ecara bersam
erator tungga
satu sistem sa
ayasa sistem
tertentu dala
akan mengam
gineering
1) adalah se
yang mem
mengintegras
at pemasukan
n elemen ma
ik: perangka
Dalam bany
ma-sama. Mis
al (elemen m
aja.
adalah me
am konteks k
mati tugas-tu
g Hierarch
hat domain fo
dan dari ba
gambar 3.2.
di mana ke
sel pemanukf
miliki elemenn
si elemen-ele
n data.
akro masing-t
lunak, per
yak kasus,
alnya, robot
manusia). Da
embatasi ele
keseluruhan
gas yang me
hy
okusnya, reka
awah ke atas
Proses rekay
eseluruhan d
kfaturan. Sel
nya sendiri
emen makro
iri dari dari
s, manusia,
akro dapat
C keduanya
ain, elemen
-masing terd
rangkat keras
elemen ma
dan mesin N
lam kasus la
tersebut un
m (elemen m
yasa sistem k
men-elemen
hirarki sistem
rupakan reka
ayasa melingk
s (bottom-up
asa sistem bi
domain bisnis
kupi sekumpu
p) untuk men
iasanya dimu
s atau dom
ntuk sistem
akro). Pada
komputer.
ulan metode
ngendalikan h
lai dengan se
ain produk
dari atas ke
hirarki yang
ebuah world
diuji untuk
28

memastikan bahwa bisnis atau konteks teknologi yang tepat dapat dibangun. WV diperhalus
untuk lebih berfokus pada domain interes tertentu. Pada suatu domain tertentu, kebutuhan
untuk sistem yang ditargetkan (misalnya data, perangkat lunak, perangkat keras, manusia)
dianalisis. Akhirnya, analisis, desain, dan konstruksi dari elemen yang ditargetkan diinisiasi.
Pada puncak hirarki, suatu konteks yang luas dibangun, dan di bagian dasarnya aktivitas teknik
lengkap yang dilakukan oleh disiplin rekayasa yang relevan (misalnya, rekayasa perangkat
keras atau perangkat lunak) dilakukan.
29
Gambar 3.2 Hirarki Rekayasa Perangkat Lunak
Secara lebih resmi dapat dikatakan bahwa WV terdiri dari sejumlah domain (Di) yang
masing-masing dapat berupa sebuah system atau system dari system yang lebih besar.
WV = { D1
D2
D3
… Dn}
Masing-masing domain terdiri elemen-elemen tertentu (Ej) dimana masing-masing
berperan dalam mencapai sasaran dan tujuan dari domain:
Di = { E1
, E2
, E3
, …., Em}

Akhirnya, masing-masing elemen diimplementasikan dengan mengkhususkan pada
30
komponen-komponen teknis ( Ck
) yang mencapai fungsi yang diperlukan untuk suatu elemen.
Ej
= {C1, C2
, C3, … Ck
}
Dalam konteks perangkat lunak, komponen dapat berupa program computer, komponen
program reusable, modul, kelas atau objek, atau bahkan dapat berupa satu pernyataan bahasa
pemrograman.
Penting untuk dicatat bahwa perekayasa system mempersempit focus kerja ketika ia
bergerak ke bawah dalam hirarki tersebut. Tetapi WV menggambarkan definisi yang jelas
terhadap keseluruhan fungsionalitas yang memungkinkan perekayasa memahami domain, dan
akhirnya system atau produk, dalam konteks yang tepat.
B. REQUIREMENT ENGINEERING
Ketika otomasi bisnis diperkenalkan pertama kali pada awal tahun 1960-an, banyak
perusahaan yang kemudian mencari berbagai peluang dan mengotomasisasi fungsi-fungsi
bisnis yang sebelumnya dijalankan dengan cara manual. Seiring berjalannya waktu, program
komputer individu kemudian dikombinasikan untuk menangani banyak aplikasi bisnis. Aplikasi
tersebut dikelompokkan ke dalam sistem informasi mayor yang melayani area bisnis yang
spesifik. Aplikasi tersebut dapat berjalan, tetapi tetap menimbulkan masalah. Banyak sistem
sulit dihubungkan satu dengan lainnya; data redundan ada di mana-mana; pengaruh peubahan
terhadap aplikasi yang melayani satu daerah bisnis sulit diproyeksikan dan bahkan lebih sulit
untuk diimplementasikan; dan program-program lama menjadi tidak dapat dipakai lagi.tetapi
kurangnya sumber daya menyebabkan sistem digunakan dalam waktu yang sangat lama.
Tujuan global rekayasa informasi adalah untuk mengaplikasikan”teknologi informasi”
dengan cara tertentu yang melayani dengan paling baik kebutuhan bisnis secara keseluruhan.
Untuk melakukan hal tersebut, IE harus memulainya dengan menganaisis sasaran dan tujuan
bisnis, memahami area-area bisnis yang harus bekerja bersama-sama untuk mencapai sasaran
dan tujuan tersebut, dan kemudian harus menentukan kebutuhan informasi bagi masing-masing
area bisnis dan bisnis secara keseluruhan. Hanya setelah hal itu dilakukan, IE membuat
transisi ke dalam domain rekayasa perangkat lunak yang lebih teknis – proses di mana sistem
informasi, aplikasi, dan program dianalisis, didesain, dan dibangun.

31
1. Requirement Elicitation
Semua proyek dapat dikerjakan dengan mudah – dengan sumber daya dan waktu yang
tidak terbatas! Sayangnya, pengembangan sistem atau produk berbasis komputer lebih banyak
terganggu oleh kurangnya sumber daya dan tanggal penyampaian yang sulit (bila tidak benar-benar
tidak realistis). Memang perlu dan bijaksana untuk melakukan evaluasi terhadap
feasibilitas sebuah proyek pada saat paling awal yang mungkin. Bulan atau tahun kerja, ribuan
atau jutaan dolar, dan keadaan melakukan tidak terkatakan dapat terhindar bila sebuah sistem
yang sakit dikenali sejak awal, ketika masih dalam fase definisi.
1) Feasibilitas ekonomis.
Evaluasi biaya pengembangan dibobot dengan pemasukan utama atau keuntungan
yang didapat dari sistem atau produk yang dikembangkan.
2) Feasibilitas teknis.
Studi mengenai fungsi, kinerja, dan batasan yang dapat mempengaruhi
kemampuan untuk mencapai sebuah sistem yang dapat diterima.
3) Feasibilitas legal.
Pertimbangan mengenai pelanggaran, kekasaran,atau liabilitas yang dihasilkan dari
pengembangan sistem.
4) Alterntif.
Evaluasi mengenai pendekatan alternatif pada pengembangan sistem atau produk.
5) Studi feasibilita
Tidak dijamin untuk sistem di mana pembenaran ekonomisnya jelas, risiko
teknisnya rendah, hanya memiliki sedikit masalah legal, dan tidak ada alternatif
yang tidak dipertanggungjawabkan. Tetapi, bila beberapa dari kondisi itu gagal,
maka studi mengenai area tersebut dapat dilakukan.
Justifikasi ekonomi biasanya merupakan pertimbangan bottom-line untuk sebagian
besar sistem (kecuali kadang-kadang mencakup sistem pertahanan seperti program ruang
angkasa). Pembenaran ekonomis menyangkut rentang yang luas dari pertimbangan yang
meliputi analisis biaya-keuntungan, stratgi pemasukan yang berhubungan dengan hokum dalam
jangka panjang, pengaruhnya pada pusat keuntungan atau produk yang lain, iaya sumber daya
yang dibutuhkan untuk pengembangan, dan pertumbuhan pasar potensial.
Feasibilitas teknis sering menjadi area yang paling sulit untuk ditaksir pada tingkat
proses rekayasa produk. Karena sasaran, fungsi, dan kinerja agak tidak penting bahwa proses
analisis dan definisi dilakukan secara paralel dengan sebuah penilaian feasibilitas teknis.
Dengan cara inilah spesifikasi yang konkrit dapat diputuskan pada saat ditentukan.

32
2. Analisis Area Bisnis
Analisis Area Bisnis membentuk suatu kerangka kerja lengkap untuk membangun
perusahaan yang berbasis informasi. Analisis area bisnis menggunakan suatu area bisnis pada
suatu waktu dan menganalisisnya secara detail. Analisis area bisnis menggunakan diagram dan
matriks untuk memodelkan dan merekam data dan aktivitas pada perusahaan dan memberikan
pemahaman yang jelas terhadap cara yang teliti dan cerdik di masa aspek informasi dari
perusahaan saling berhubungan.
3. Requirement Spesification
Spesifikasi Sistem adalah dokumen yang berfungsi sebagai dasar bagi rekayasa
perangkat keras, rekayasa perangkat lunak, rekayasa database, dan rekayasa manusia.
Spesifikasi sistem menggambarkan fungsi dan kinerja dari sebuah sistem berbasis computer
serta batasan yang mengatur pengembangannya. Spesifikasi tersebut membatasi masing-masing
elemen sistem yang teralokasi.
4. System Modelling
Sebagai bagian dari persyaratan sistem dan kegiatan perancangan, sistem harus
dimodelkan sebagai suatu kumpulan komponen dan hubungan antara komponen-komponen ini.
Ini biasanya diilustrasikan secara grafis pada model arsitektur sistem yang memberikan
pandangan kepada pembaca mengenai organisasi sistem.
Arsitektur sistem biasanya digambarkan sebagai diagram blok yang menunjukkan
subsistem direpresentasikan sebagai persegi empat pada diagram blok dan adanya hubungan
antara mereka ditunjukkan dengan tanda panah yang menghubungkan persegi empat ini.
Hubungan yang digambarkan bisa mencakup aliran data, hubungan menggunakan/digunakan
atau jenis hubungan ketergantungan lain.
Arsitektur sistem harus dirancang dalam bentuk subsistem fungsional tanpa
mempedulikan apakah sub sistem tersebut merupakan perangkat keras atau perangkat lunak.
Komponen fungsional pada sistem dapat diklasifikasikan dengan berbagai nama:
1) Komponen sensor
2) Komponen actuator
3) Komponen komputasi
4) Komponen komunikasi
5) Komponen koordinasi
6) Komponen iterface

33
5. Requirement Validation
Validasi perysaratan berkenaan dengan pengidentifikasian bahwa persyaratan benar-benar
mendefinisikan sistem yang diinginkan pelanggan. Kegiatan ini memiliki banyak
kesamaan dengan analisis karena hubungan dengan penemuan masalah dengan persyaratan.
Namun demikian, keduanya merupakan proses yang berbeda karena validasi harus
berhubungan dengan naskah dokumen persyaratan yang lengkap, sementara analisis
melibatkan pekerjaan dengan persyaratan yang tidak lengkap.
Validasi persyaratan penting karena error pada dokumen persyaratan dapat
menimbulkan biaya pengerjaan ulang jika ditemukan pada saat pengembangan atau setelah
sistem dipakai. Biaya melakukan perubahan sistem yang merupakan akibat dari masalah
persyaratan lebih besar dari perbaikan desasin atau kesalahan pengkodean. Alasan untuk hal ini
adalah karena perubahan persyaratan biasanya mengharuskan perubahan desain sistem dan
implementasinya, beserta pengujian ulang sistem.
Pada saat proses validasi persyaratan tipe pemeriksaan yang berbeda harus diterapkan
pada persyaratan-persyaratan di dokumen persyaratan. Pemeriksaan ini meliputi:
1) Pemeriksaan validitas.
Seorang user mungkin berpikir bahwa sistem diperlukan untuk melakukan fungsi-fungsi
tertentu. Namun demikian pemikiran dan analisis lebih lanjut dapat
mengidentifikasi fungsi tambahan atau fungsi berbeda yang diinginkan. Sistem
yang memiliki berbagai user dengan kebutuhan yang berbeda dengan persyaratan
apapun pada akhirnya akan merupakan suatu kompromi dari komunitas user.
2) Pemeriksaan Konsistensi
Persyaratan pada dokumen seharusnya tidak bertentangan. Artinya seharusnya
ada batasan-batasan yang saling bertentangan atau deskripsi yang berbeda dari
fungsi sistem yang sama.
3) Pemeriksaan Kelengkapan
Dokumen persyaratan harus mencakup persyaratan yang mendefinisikan semua
fungsi dan batasan yang dimaksud oleh user sistem.
4) Pemeriksaan realisme
Dengan menggunakan pengetahuan mengenai teknologi yang ada, persyaratan
harus diperiksa untuk menjamin persyaratan dapat diimplementasi. Pemeriksaan
ini harus memperhitungkan anggaran dan jadwal pengembangan sistem.

34
5) Kemampuan dapat diverifikasi
Untuk mengurangi potensi pertentangan antara pelanggan dan kontraktor,
persyaratan sistem harus selalu dituliskan sedemikian rupa sehingga dapat
diverifikasi. Ini berarti bahwa serangkaian pemeriksaan dapat dirancang untuk
mendemonstrasikan bahwa sistem yang diserahkan memenuhi persyaratan
tersebut.
6. Requirement Management
Persyaratan untuk sistem perangkat lunak besar selalu berubah. Satu alasan untuk hal
ini adalah karena sistem-sistem ini biasanya dikembangkan untuk mengatasi masalah. Karena
masalah tidak dapat didefinisikan sepenuhnya, persyaratan perangkat lunak cenderung tidak
lengkap. Pada saat proses perangkat lunak, pemahaman pengembang akan masalah berubah-ubah
dan perubahan ini diumpan balikkan pada persyaratan.
Sistem besar biasanya memiliki komunitas user yang beragam. User yang berbeda-beda
mempunyai persyaratan dan prioritas yang berbeda pula. Hal-hal ini bias menimbulkan
konflik atau kontradiksi.
Manajemen persyaratan adalah proses pemahaman dan pengendalian perubahan pada
persyaratan sistem. Proses manajemen persyaratan dilakukan bersama dengan proses rekayasa
persyaratan yang lainnya. Perencanaan dimulai pada saat yang sama dengan elisitasi
persyaratan awal dan manajemen persyaratan aktif harus dimulai segera setelah versi naskah
dokumen persyaratan tersedia.
Dari sudut pandang evolusi persyaratan terbagi menjadi dua kelas:
1) Persyaratan yang bertahan.
Ini merupakan persyaratan yang relative stabil, yang berasal dari kegiatan inti
organisasi dan berhubungan langsung dengan domain sistem.
2) Persyaratan yang berubah-ubah.
Ini merupakan persyaratan yang mungkin berubah pada saat pengembangan
sistem, atau setelah sistem dipakai.
EVALUASI
1) Sebutkan dan jelaskan elemen sistem berbasis komputer!
2) Apakah fungsi dari studi kelayakan!
3) Apakah yang dimaksud dengan manajemen persyaratan?

35
BAB 4
ANALISIS
A. KONSEP DAN PRINSIP ANALISIS
Pemahaman lengkap mengenai persyaratan perangkat lunak sangat penting bagi
keberhasilan usaha pengembangan perangkat lunak. Tidak peduli bagaimana perangkat lunak
dirancang atau dikodekan, program yang dianalisis dan ditentukan secara tidak baik akan
mengecewakan pemakaiannya dan akan membawa kegagalan bagi pengembangnya.
Tugas analisis persyaratan merupakan sebuah proses penemuan, perbaikan,
pemodelan dan spesifikasi. Ruang lingkup perangkat lunak yang secara mendasar
dikembangkan oleh perekayasa system dan diperbaiki selama perencanaan proyek perangkat
lunak diperbaiki secara detail. Model-model data yang dibutuhkan, aliran kontrol dan informasi,
dan tingkah laku operasional diciptakan.
Kebutuhan perangkat lunak adalah kondisi, kriteria, syarat atau kemampuan yang
harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan
pemakai. Bab ini berisi mengenai segala sesuatu yang dibutuhkkan untuk dapat melakukan
analisa kebutuhan perangkat lunak.
Menurut Kamus Webster seperti dikutip oleh Davis [DAV93], kebutuhan adalah sesuatu
yang disyaratkan; sesuatu yang diinginkan atau diperlukan. Sedangkan menurut IEEE [IEE93]
kebutuhan adalah:
1) Kondisi atau kemampuan yang diperlukan pemakai untuk menyelesaikan suatu
persoalan, atau untuk mencapai tujuan.
2) Kondisi atau kemampuan yang harus dimiliki atau dipunyai oleh sistem atau
komponen sistem untuk memenuhi kontrak, standar, spesifikasi, atau dokumen
formal lainnya.
Dengan mengadopsi pengertian-pengertian di atas, dapat disimpulkan bahwa
kebutuhan perangkat lunak adalah kondisi, kriteria, syarat atau kemampuan yang harus dimiliki
oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan pemakai.

36
Secara kategoris, ada tiga buah jenis kebutuhan perangkat lunak [IEE93] :
1) Kebutuhan fungsional (functional requirement)
Disebut juga kebutuhan operasional, yaitu kebutuhan yang berkaitan dengan
fungsi atau proses transformasi yang harus mampu dikerjakan oleh perangkat
lunak. Sebagai contoh:
a. Perangkat lunak harus dapat menyimpan semua rincian data pesanan
pelanggan.
b. Perangkat lunak harus dapat membuat laporan penjualan sesuai dengan
periode waktu tertentu.
c. Perangkat lunak harus mampu menyajikan informasi jalur pengiriman barang
terpendek.
2) Kebutuhan antarmuka (interface requirement)
Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen
perangkat keras, perangkat lunak, atau basis data. Sebagai contoh:
a. Perangkat untuk memasukkan data dapat berupa keyboard, mouse atau
scanner.
b. Akses ke basisdata menggunakan ODBC (Open Database Connectivity).
3) Kebutuhan unjuk kerja (performance requirement)
Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh
perangkat lunak, misalnya: kecepatan, ketepatan, frekuensi. Sebagai contoh:
a. Perangkat lunak harus bisa mengolah data sampai 1 juta record untuk tiap
transaksi.
b. Perangkat lunak harus dapat digunakan otoritas yang diberikan pada user.
c. Waktu tanggap penyajian informasi maksimal selama satu menit.
1. Analisis Kebutuhan
Analisis kebutuhan perangkat lunak (software requirements analysis) merupakan
aktivitas awal dari siklus hidup pengembangan perangkat lunak. Untuk proyek-proyek
perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah tahap rekayasa
sistem/informasi dan software project planning.
Analisis persyaratan adalah sebuah tugas rekayasa perangkat lunak yang menjembatani
jurang antara alokasi perangkat lunak tingkat sistem dan perancangan perangkat lunak seperti
dilihat pada gambar 6.1.

37
Gambar 4.1 Analisis dan Kesenjangan antara rekayasa sistem dan desain perangkat lunak
Analisis persyaratan memungkinkan perekayasa sistem menentukan fungsi dan kinerja
perangkat lunak, menunjukkan interface perangkat lunak dengan elemen-elemen sistem.
Pendefinisian kebutuhan merupakan aktivitas yang sangat penting, karena sangat
mempengaruhi sukses atau gagalnya pelaksanaan pengembangan perangkat lunak. Menurut
hasil survey DeMarco, 56% kegagalan proyek pengembangan perangkat lunak dikarenakan
ketidaklengkapan pendefinisian kebutuhan dari perangkat lunak tersebut. Perhatikan gambar
dampak kesalahan kumulatif akibat kesalahan dalam pendefinisian kebutuhan pada Gambar
4.2.

38
Gambar 4.2 Dampak Kesalahan Kumulatif
Dari gambar terlihat bahwa produk perangkat lunak yang tidak sempurna akan
dihasilkan karena kesalahan pada saat menentukan spesifikasi kebutuhan. Jika kesalahan
tersebut diketahui di akhir siklus hidup pengembangan, usaha untuk memperbaikinya akan
sangat mahal.
Selain itu, kesalahan penentuan kebutuhan akan memberikan dampak [DAV93]:
a. Perangkat lunak yang dihasilkan tidak akan memenuhi kebutuhan pemakai yang
sebenarnya.
b. Interpretasi kebutuhan yang berbeda-beda sehingga dapat menyebabkan
ketidaksepakatan antara pelanggan dan pengembang, menyia-nyiakan waktu dan
biaya, dan mungkin akan menghasilkan perkara hukum.

c. Pengujian kesesuaian perangkat lunak dengan kebutuhan yang dimaksud tidak akan
39
mungkin dilaksanakan dengan sesungguhnya.
d. Waktu dan biaya akan terbuang percuma untuk membangun sistem yang salah.
2. Prinsip-Prinsip Analisis
Setiap metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis
dihubungkan oleh serangkaian prinsip operasional yang dapat dijabarkan sebagai berikut:
1) Dominan informasi dari suatu masalah harus direpresentasikan dan dipahami.
2) Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
3) Tingkah laku perangkat lunak harus diwakilkan.
4) Model-model yang menggambarkan informasi, fungsi dan tingkah laku harus
dipecah-pecah dalam suatu cara yang membongkar suatu detail dalam bentuk
lapisan (hirarki).
5) Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
Dengan mengaplikasikan prinsip-prinsip tersebut, analis mendekati suatu masalah
secara sistematis. Tujuan pelaksanaan analisis kebutuhan adalah:
1) Memahami masalah secara menyeluruh (komprehensif) yang ada pada perangkat
lunak yang akan dikembang seperti ruang lingkup produk perangkat lunak(product
space) dan pemakai yang akan menggunakannya.
2) Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk memenuhi
keinginan pelanggan.
Secara teknis pelaksanaan pekerjaan analisis kebutuhan perangkat lunak pada
dasarnya terdiri dari urutan aktivitas:
1) Mempelajari dan memahami persoalan
Pada tahap ini, seorang analis mempelajari masalah yang ada pada perangkat
lunak yang dikembangkan, sehingga dapat ditentukan.
a. Siapa pemakai yang menggunakan perangkat lunak.
b. Dimana perangkat lunak akan digunakan
c. Pekerjaan apa saja dari pemakai yang akan dibantu oleh perangkat lunak.
d. Apa saja cakupan dari pekerjaan tersebut, dan bagaimana mekanisme
pelaksanaannya.
e. Apa yang menjadi kendala dilihat dari sisi teknologi yang digunakan atau dari
sisi hukum dan standar.

Cara yang digunakan oleh pengembang khususnya analis dalam memahami
masalah perangkat lunak biasanya dilakukan
a. Wawancara dengan pemakai
b. Observasi atau pengamatan lapangan
c. Kuesioner
d. Mempelajari referensi atau dokumen-dokumen yang digunakan, seperti
40
dokumen hasil analisa dan perancangan perangkat lunak.
Hasil dari pemahaman masalah tersebut dapat digambarkan dengan model-model
tertentu sesuai dengan jenis permasalahannya. Sebagai contoh jika masalah bisnis
dapat digambarkan dengan flowmap atau bussiness use case untuk analisa
berorientasi objek. Sedangkan untuk masalah matematika dapat digambarkan
dengan graf.
2) Mengindentifikasi Kebutuhan Pemakai
Pada tahap identifikasi kebutuhan pemakai (user requirement) in pada prakteknya
menjadi satu pelaksanaannya dengan pemahaman masalah. Hanya saja substansi
yang ditanyakan ada sedikit perbedaan, yaitu:
a. Fungsi apa yang diinginkan pada perangkat lunak.
b. Data atau informasi apa saja yang akan diproses.
c. Kelakuan sistem apa yang diharapkan.
d. Antarmuka apa yang tersedia (software interfaces, hardware interfaces, user
interfaces, dan communication interfaces)
Untuk menangkap kebutuhan dari pemakai dengan baik,terutama kesamaan
persepsi. seorang analis membutuhkan:
a. Komunikasi dan brainstorming yang intensif dengan pelanggan.
b. Pembuatan prototype perangkat lunak atau screenshoot.
c. Data atau dokumen yang lengkap.
3) Mendefinisikan kebutuhan perangkat lunak
Saat melakukan pengidentifikasian kebutuhan pemakai, informasi yang diperoleh
masih belum terstruktur. Biasanya pemakai akan mengungkapkan apa yang
diinginkan dengan bahasa sehari-hari yang biasa mereka gunakan. Sebagi contoh,
ungkapan kebutuhan pemakai dibagian akutansi.
a. Saya ingin data yang dimasukkan oleh bagian penjualan bisa langsung
dijurnal.
b. Informasi neraca keuangan bisa saya lihat kapan saja.

Kemudian pada tahap ini, kebutuhan pemakai yang belum terstruktur tersebut
akan akan dianalisis, diklasifikasikan, dan diterjemahkan menjadi kebutuhan
fungsional, antarmuka dan unjuk kerja perangkat lunak. Sebagai contoh,
kebutuhan “data yang dimasukkan oleh bagian penjualan bisa langsung dijurnal”
setelah dianalisis, diklasifikasikan dan diterjemahkan, mungki akan menghasilkan
pendefinisian kebutuhan sebagai berikut.
41
a. Kebutuhan fungsional
a) Entri dan rekam data transaksi penjualan.
b) Retrieve data transaksi penjualan untuk periode tertentu (periode sesuai
dengan inputan periode yang diinputkan pada keyboard).
c) Rekam data akumulasi transaksi penjualan periode tertentu ke jurnal
umum berikut account pasangannya (kas).
b. Kebutuhan antarmuka
a) Antarmuka pemakai untuk memasukkan dan merekam data penjualan.
b) Antarmuka pemakai untuk menyajikan dan menjurnal informasi transaksi
penjualan pada periode tertentu.
c) Antarmuka untuk jaringan lokal yang menghubungkan perangkat lunak
aplikasi dibagian penjualan dengan perangkat lunak aplikasi dibagian
akutansi.
c. Kebutuhan unjuk kerja
a) Proses jurnal hanya bisa dilakukan sekali setelah data transaksi penjualan
direkam.
b) Adanya otoritas pemakaian perangkat lunak dan akses data sesuai
dengan bagian pekerjaan masing-masing.
Kemudian kebutuhan tersebut akan dimodelkan atau digambarkan dengan teknik
analisis dan alat bantu tertentu. Sebagai contoh kebutuhan fungsional dapat
dimodelkan dengan menggunakan
a) Data flow diagram,kamus data,dan spesifikasi proses jika menggunakan
anlisis tertsruktur.
b) Use case diagram dan skenario sistem jika menggunkan analisis berorientasi
objek.

42
4) Membuat dokumen spesifikasi kebutuhan perangkat lunak (SKPL)
Semua kebutuhan yang telah didefinisikan selanjutnya dibuat dokumentasinya
yaitu Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirement
Specification (SRS). Dokumen ini dibuat untuk menyatakan secara lengkap apa
yang dapat dilakukan oleh perangkat lunal, termasuk deskripsi lengkap semua
antarmuka yang akan digunakan.
5) Mengkaji ulang (review) kebutuhan
Proses untuk mengkaji ulang (validasi) kebutuhan apakah SKPL sudah konsisten,
lengkap, dan sesuai dengan yang diinginkan oleh pemakai. Proses ini bisa
dilakukan lebih dari satu kali. Dan sering kali akan muncul kebuthan-kebutuhan
baru dari pemakai. Oleh karena itu, diperlukannya negosiasi antara pengembang
dengan pelanggan sesuai dengan prinsip “win win solution” sampai kebutuhan
tersebut disetujui oleh kedua belah pihak.
Sedangkan menurut (Pressman, 2002), analisis kebutuhan perangkat lunak dapat
dibagi menjadi lima area pekerjaan, yaitu:
a. Pengenalan masalah
b. Evaluasi dan sistesis
c. Pemodelan
d. Spesifikasi
e. Tinjau Ulang (Review)
3. Prototipe Software
Paradigma prototyping dapat terbatas atau tidak terbatas. Pendekatan terbatas sering
disebut throwaway prototyping. Dengan menggunakan pendekatan tersebut prototype
merupakan sebuah demonstrasi kasar dari persyaratan. Kemudian prototype dikesampingkan,
dan perangkat lunak direkayasa dengan menggunakan suatu paradigm yang berbeda.
B. MODEL ANALISIS
Metode atau teknik untuk melakukan analisis kebutuhan perangkat lunak dapat
dikelompokkan berdasarkan pendekatan yang diambil pada saat melakukan aktivitas tersebut.

43
1. Data Flow Oriented atau Functional Oriented
Sudut pandang analisis pada pendekatan ini difokuskan pada aspek fungsional dan
behavioral (perilaku laku) sistem. Pengembang harus mengetahui fungsi-fungsi atau proses-proses
apa saja yang ada dalam sistem, data apa yang menjadi masukannya, dimana data
tersebut disimpan, transformasi apa yang akan dilakukan terhadap data tersebut, dan apa yang
menjadi hasil transformasinya. Selain itu, pengembang harus mengetahui keadaan (state),
perubahan (transition), kondisi (condition), dan aksi (action) dari sistem.
Salah satu metode yang paling populer untuk pendekatan ini adalah Analisis Terstruktur
(Structured Analysis) yang dikembangkan oleh (DeMarco,1976), Chris Gane dan Trish Sarson,
dan Edwad Yourdon (Yourdon, 1989). Pada metode ini, hasil analisis dan perancangan
dimodelkan dengan menggunakan beberapa perangkat pemodelan seperti:
a) Data Flow Diagram (DFD) dan Kamus Data (data dictionary) untuk
menggambarkan fungsi-fungsi dari sistem (system functions).
b) Entity-Relationship Diagram (ERD) untuk menggambarkan data yang disimpan
(data stored).
c) State Transition Diagram (STD) untuk menggambarkan perilaku sistem.
d) Structure Chart untuk menggambarkan struktur program.
2. Data Structured Oriented
Analisis dengan pendekatan ini difokuskan pada struktur data, dimana struktur tersebut
dapat dinyatakan secara hirarki dengan menggunakan konstruksi sequence, selection dan
repetition. Beberapa metode berorientasi struktur data ini diantaranya adalah:
a. Data Structured System Development (DSSD)
Diperkenalkan pertama kali oleh J.D. Warnier [1974] dan kemudian oleh Ken Orr
[1977], sehingga sering disebut juga metode Warnier-Orr. Metode ini
menggunakan perangkat entity diagram, assembly line diagram dan Warnier-Orr
diagram untuk memodelkan hasil analisis dan perancangannya.
b. Jackson System Development (JSD)
Dikembangkan oleh M.A. Jackson [1975] dengan menggunakan perangkat
pemodelan yang disebut structure diagram dan system specification diagram.

44
3. Object Oriented
Berbeda dengan pendekatan-pendekatan sebelumnya, pendekatan berorientasi objek
memandang sistem yang akan dikembangkan sebagai suatu kumpulan objek yang
berkorespondensi dengan objek-objek dunia nyata. Pada pendekatan ini, informasi dan proses
yang dipunyai oleh suatu objek “dienkapsulasi” (dibungkus) dalam satu kesatuan. Beberapa
metode pengembangan sistem yang berorientasi objek ini diantaranya adalah:
a) Object Oriented Analysis (OOA) dan Object Oriented Design (OOD) dari Peter Coad
dan Edward Yourdon (1990).
b) Object Modeling Technique (OMT) dari James Rumbaugh (1987).
c) Object Oriented Software Engineering (OOSE).
C. ANALISIS TERSTRUKTUR
Analisis Terstruktur (Structured Analysis) merupakan salah satu teknik analisis yang
mengunakan pendekatan berorientasi fungsi. Teknik ini mempunyai sekumpulan petunjuk dan
perangkat komunikasi grafis yang memungkinkan analis sistem mendefinisikan spesifikasi
fungsional perangkat lunak secara terstruktur. Pada metode ini, semua fungsi sistem
direpresentasikan sebagai sebuah proses transformasi informasi, dan disusun secara hirarkis
sesuai tingkat abstraksinya (sistem maupun perangkat lunak) yang hasilnya ditujukan untuk
entitas-entitas eksternal.
Analisis Terstruktur pertama kali diperkenalkan oleh Tom DeMarco sekitar tahun 1978
[DEM79]. Prinsip dari teknik ini adalah dekomposisi fungsi dari sistem berdasarkan aliran data
dan proses-prosesnya untuk mendapatkan produk analisis yang dapat diubah dan diperbaiki
secara mudah (highly maintainable). Dalam bukunya itu, DeMarco mendefinisikan Analisis
Terstruktur sebagai teknik untuk mendeskripsikan spesifikasi sistem baru melalui Data Flow
Diagrams, Data Dictionary, Structured English, dan Data Structure Diagrams. Spesifikasi sistem
tersebut dinyatakan dalam suatu dokumen yang disebut Spesifikasi Terstuktur (Structured
Specification).
Dalam perkembangannya, teknik Analisis Terstruktur mengalami perubahan,
penambahan, dan penyempurnaan, baik untuk perangkat pemodelannya maupun mekanisme
atau cara pelaksanaannya. Salah satunya oleh Edward Yourdon [YOU89] yang memperkenalkan
pendekatan baru dari Analisis Terstruktur, yaitu Analisis Terstruktur Modern (Modern Structures
Analysis).

45
1. Perangkat Pemodelan Terstruktur
Perangkat Pemodelan Analisis Terstruktur adalah alat bantu pemodelan yang
digunakan untuk menggambarkan hasil pelaksanaan Analisis Terstruktur. Perangkat Analisis
Terstruktur yang disampaikan oleh DeMarco [DEM78] adalah:
a) Diagram Aliran Data atau Data Flow Diagram (DFD)
b) Kamus Data atau Data Dictionary
c) Structured English
d) Tabel Keputusan atau Decision Table
e) Pohon Keputusan atau Decision Tree
Kelima perangkat tersebut oleh Yourdon [YOU89] dilengkapi dengan:
a) Diagram Entitas-Relasi atau Entity-Relationship Diagram (ERD)
b) Diagram Transisi Keadaan atau State Transition Diagram (STD)
Dan sebagai pengembangan untuk menggambarkan sistem waktu nyata, disertakan
Diagram Aliran Kendali atau Control Flow Diagram (CFD). Berikut adalah penjelasan rinci untuk
masing-masing perangkat, khususnya untuk DFD, Kamus Data, dan Structured English.
2. Spesifikasi Proses
Digunakan untuk menggambarkan deskripsi dan spesifikasi dari setiap proses yang
paling rendah (proses atomik) yang ada pada sistem dengan menggunakan notasi yang disebut
Structured English atau pseudo-code. Penulisannya cukup sederhana sehingga dapat digunakan
sebagai media untuk mengkomunikasikan proses yang dilakukan sistem kepada pemakai.
Seperti halnya notasi-notasi yang lain, ada cukup banyak variasi penulisan spesifikasi
proses dengan Structured English ini. Pada buku ini akan digunakan notasi penulisan yang
menggunakan kata-kata bahasa Indonesia, kecuali untuk kata-kata yang sering digunakan
dalam penulisan program, misalnya Read, Write, If, While, atau Repeat.
Ada tiga struktur dasar yang dapat digunakan untuk menyusun spesifikasi proses, yaitu
struktur sekuensi, pemilihan dan pengulangan. Berikut adalah contoh penulisan spesifikasi
proses untuk proses pembuatan laporan penjualan.
Nomor : 3.0
Nama Proses : Buat laporan penjualan
Jenis : Pembuatan laporan

46
Masukan : File Barang, file Jual dan periode transaksi
Keluaran : Laporan penjualan
Deskripsi :
Begin
Buka file BARANG dan file JUAL
Baca data periode tanggal transaksi
Saring (filter) data pada file JUAL sesuai periode tanggal transaksi
Cetak Laporan Penjualan
Tutup file BARANG dan file JUAL.
End
atau secara lebih ringkas:
Proses 3.0 Buat Laporan Penjualan
Begin
Buka file BARANG dan file JUAL
Baca data periode tanggal transaksi
Saring (filter) data pada file JUAL sesuai periode tanggal transaksi
Cetak Laporan Penjualan
Tutup file BARANG dan file JUAL.
End
D. KAMUS DATA
Merupakan suatu tempat penyimpanan (gudang) dari data dan informasi yang
dibutuhkan oleh suatu sistem informasi. Kamus data digunakan untuk mendeskripsikan rincian
dari aliran data atau informasi yang mengalir dalam sistem, elemen-elemen data, file maupun
basis data (tempat penyimpanan) dalam DFD.
Ada aturan (konvensi) penulisannya dengan menggunakan notasi atau simbol tertentu
sebagai berikut:
= sama dengan atau terdiri dari atau terbentuk dari
+ dan
[] pilih salah satu
{} iterasi atau pengulangan
() pilihan (option)
* komentar
| pemisah

Saat ini ada banyak variasi penulisan kamus data, yang secara umum dibedakan
menjadi bentuk lengkap (long form) dan bentuk ringkas (short form). Sebagai contoh dibawah
ini bentuk kamus data yang lengkap (long form):
47
Id. Barang = Kode_Brg + Nama_Brg + Satuan + Hrg_Beli + Hrg_Jual + Banyak
Kode_Brg = 1{character}6
Nama_Brg = 1{character}20
Satuan = 1{character}3
Hrg_Beli = 3{numeric}10
Hrg_Jual = 3{numeric}10
Banyak = 1{numeric}6
character = [A-Z|a-z|0-9|-| |]
numeric = [0-9]
Artinya:
a) Identitas Barang tersusun dari atribut Kode_Brg dan Nama_Brg dan Satuan dan
Hrg_Beli dan Hrg_Jual dan Banyak.
b) Kode_Brg tersusun dari minimal 4 karakter dan maksimal 6 karakter.
c) Nama_Brg tersusun dari minimal 8 karakter dan maksimal 20 karakter.
d) Satuan tersusun dari 3 karakter.
e) Hrg_Jual tersusun dari minimal 3 dijit numerik dan maksimal 10 dijit numeric
f) Jml_Stok tersusun dari 1 dijit numerik dan maksimal 6 dijit numerik.
g) Character terdari dari huruf besar A sampai Z, atau huruf kecil a sampai z atau
angka 0 sampai 9, atau karakter –, atau karakter spasi.
h) Numeric terdiri dari angka 0 sampai 9.
Sedangkan contoh bentuk ringkas (short form) dari kamus adalah
Identitas Barang = Kode_Brg + Nama_Brg + Satuan + Hrg_Jual + Jml_Stok
EVALUASI
1) Sebutkan area pekerjaan yang harus dilakukan pada tahap analisis menurut
Pressman?
2) Jelaskan pengertian dari throwaway prototyping?
3) Apakah Fungsi dari Kamus Data?
4) Buatlah Kamus Data untuk Menyimpan Biodata Mahasiswa!

48
BAB 5
DESAIN
A. PROSES DESAIN
Desain adalah langkah pertama dalam fase pengembangan bagi setiap produk atau
sistem yang direkayasa. Menurut Taylor dalam (Pressman, 2002) Desain dapat didefinisikan
sebagai proses aplikasi berbagai teknik dan prinsip bagi tujuan pendefinisian suatu perangkat
lunak, suatu proses atau sistem dalam detail yang memadai untuk memungkinkan realisasi
fisiknya.
Tujuan dari perancang sistem adalah untuk menghasilkan suatu model atau
representasi dari entitas yang akan dibangun. Desain berada pada inti teknik dan proses
rekayasa perangkat lunak dan diaplikasikan tanpa memperhatikan model proses perangkat
lunak yang digunakan. Langkah desain menghasilkan desain data, desain arsitektur, desain
interface serta desain prosedural.
Desain data menghasilkan transformasi model domain informasi yang dibuat selama
analisis ke dalam struktur data yang akan diperlukan untuk mengimplementasikan perangkat
lunak. Objek dan hubungan data yang ditetapkan dalam diagram hubungan entitas (ERD) dan
isi detail yang digambarkan di dalam kamus data, menjadi basis bagi aktifitas desain data.
Desain arsitektur menentukan hubungan diantara elemen-elemen struktural utama
dari program. Representasi desain tersebut berupa kerangka modular dari sebuah program
komputer.
Desain interface menggambarkan bagaimana perangkat lunak berkomunikasi dalam
dirinya sendiri, dengan sistem yang berinteroperasi dengannya dan dengan manusia yang
menggunakannya. Interface mengimplementasikan aliran informasi berupa dan kontrol.
Desain prosedural mentransformasi elemen-elemen struktural dari arsitektur
program ke dalam suatu deskripsi prosedur dari komponen-komponen perangkat lunak.
Selama tahap desain kita membuat keputusan yang akan mempengaruhi kesuksesan
konstruksi perangkat lunak, dan yang penting kemudahan bagaimana perangkat lunak dapat
dipelihara. Pentingnya desain perangkat lunak dapat dinyatakan dengan suatu kata tunggal
yaitu kualitas. Desain adalah tempat dimana kualitas dibangun dalam pengembangan

perangkat lunak. Desain memberi kita representasi perangkat lunak yang kualitasnya dapat
dinilai. Desain adalah satu-satunya cara dimana kita dapat secara akurat menterjemahkan
kebutuhan pelanggan ke dalam produk atau sistem perangkat lunak yang sudah selesai. Tanpa
desain kita beresiko membangun system yang tidak stabil, sistem yang akan gagal pada saat
perubahan kecil dibuat sehingga sulit diuji dan kualitasnya tidak dapat dinilai.
49
1. Desain dan Software Quality
Desain perangkat lunak adalah suatu proses interaktif yang melaluinya. Persyaratan
diterjemahkan ke dalam cetak biru (blueprint) untuk membangun perangkat lunak. Cetak biru
menggambarkan suatu pandangan menyeluruh rekayasa perangkat lunak. Sepanjang proses
desain, kualitas yang melengkapi dinilai dengan serangkaian kajian teknis formal. Terdapat 3
karakteristik yang berfungsi sebagai pedoman bagi evaluasi suatu desain yang baik:
a) Desain harus mengimplementasikan keseluruhan eksplisit yang dibebankan dalam
model analisis dan harus mengakomodasi semua persyaratan implisit yang
diinginkan pelanggan.
b) Desain harus menjadi panduan yang dapat dibaca dan dipahami bagi mereka yang
menghasilkan kode dan yang menguji serta memelihara perangkat lunak.
c) Desain harus memberikan suatu gambaran lengkap mengenai perangkat lunak
yang menekankan data, dan perilaku implementasi.
Ketiga karakteristik di atas merupakan sasaran dari proses desain. Untuk mengevaluasi
kualitas dari suatu desain kita harus membangun kriteria teknis untuk desain yang baik. Criteria
desain yang berkualitas baik mengikuti pedoman sebagai berikut:
1) Desain harus memperlihatkan suatu organisasi hirarki yang dengan baik
menggunakan kontrol di antara elemen-elemen perangkat lunak.
2) Desain harus modular, yaitu bahwa perangkat lunak harus dipartisi secara logika ke
dalam elemen-elemen yang melakukan fungsi dan sub fungsi khusus.
3) Desain harus berisi data dan abstraksi prosedural.
4) Desain harus membawa ke arah modul (misal sub rutin atau prosedur) yang
memperlihatkan karakteristik fungsional independen.
5) Desain harus mengarah kepada interface yang mengurangi kompleksitas hubungan
antara modul-modul dan dengan lingkungan eksternal.
6) Desain harus didapat dengan menggunakan metode berulang yang dikendalikan
oleh informasi yang diperoleh selama analisis persyaratan perangkat lunak.

Keenam kriteria di atas tidak dapat dicapai secara kebetulan. Proses desain perangkat
lunak memungkinkan adanya desain yang baik melalui aplikasi prinsip-prinsip desain
fundamental, metodologi sistematis, dan kajian yang mendalam.
50
2. Perkembangan Desain Perangkat Lunak
Evolusi desain perangkat lunak adalah suatu proses kontinu yang terus berlangsung
selama tiga dekade. Desain decade awal dikonsentrasikan pada kriteria untuk
pengembangan program moduler dan metode-metode untuk menyaring arsitektur perangkat
lunak dalam cara top-down yang dikemas dalam pemrograman terstruktur. Desain decade
kedua mengusulkan aliran translasi aliran data atau struktur data ke dalam definisi desain
perangkat lunak. Desain dekade yang lebih baru mengusulkan pendekatan orientasi obyek
ke dalam desain perangkat lunak.
Banyak metode desain yang tumbuh dari kerja tersebut dan tanpa memperhatikan
metode desain yang dipakai, perekayasa perangkat lunak harus mengaplikasikan serangkain
prinsip dasar dan konsep dasar terhadap data, arsitektur, interface dan desain prosedural.
B. PRINSIP-PRINSIP DESAIN
Desain perangkat lunak berupa proses dan model. Proses desain adalah serangkaian
langkah interatif yang memungkinkan desainer menggambarkan semua aspek perangkat lunak
yang dibangun. Tetapi perlu dicatat bahwa proses desain tidaklah sederhana. Keahlian kreatif,
pengalaman, rasa tentang apa yang membuat perangkat lunak menjadi baik dan keseluruhan
komitmen terhadap kualitas adalah faktor sukses.
Model desain berbanding lurus dengan recana arsitek untuk rancangan sebuah rumah.
Model desain memulai dengan menyajikan totalitas dari hal yang akan dibangun. Prinsip-prinsip
desain dasar memungkinkan perekayasa perangkat lunak untuk mengendalikan proses desain.
Menurut Davis dalam (Pressman, 2002) mengusulkan serangkaian prinsip bagi desain
perangkat lunak yang telah diadaptasi dan diperluas sebagai berikut:
a) Proses desain tidak boleh menderita karena “tunnel vision”. Desain yang baik
harus memmperhatikan pendekatan-pendekatan alternative. Menilai masing-masing
pendekatan berdasarkan persyaratan masalah.
b) Desain harus dapat ditelusuri sampai model analisis (reverse engineering).
c) Desain tidak boleh berulang.
d) Desain harus meminimalkan kesenjangan intelektual di antara perangkat lunak dan
masalah yang ada di dunia nyata.

REKAYASA PERANGKAT LUNAK

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to REKAYASA PERANGKAT LUNAK

Similar to REKAYASA PERANGKAT LUNAK (20)

Recently uploaded

Recently uploaded (14)

REKAYASA PERANGKAT LUNAK