RESUME

REKAYASA PERANGKAT LUNAK

Erlina Pujiasri A
207533408610

2/26/2010
Malang State University
Erlina Pujiasri A.
Daftar Isi
1. Perangkat Lunak ...................................................................................................... 1
1.1 Karakteristik Perangkat Lunak ...................................................................... 1
1.2 Komponen Perangkat lunak ............................................................................ 2
1.3 Aplikasi Perangkat Lunak ............................................................................... 2
2. Rekayasa Perangkat Lunak ..................................................................................... 4
2.1 Tujuan Rekayasa Perangkat Lunak ............................................................... 5
2.2 Ruang Lingkup.................................................................................................. 5
3. Mitos Rekayasa Perangkat Lunak .......................................................................... 6
4. Proses Perangkat Lunak .......................................................................................... 8
5. Model Proses Perangkat Lunak............................................................................... 9
5.1 Model Konvensional ......................................................................................... 9
Linear SequentialModel/ Waterfall Model ............................................................. 9
Model Prototyping .................................................................................................. 10
RAD (Rapid Application Development) ............................................................... 11
5.2 Model Evolusioner .......................................................................................... 12
1. Incremental Model (Original: Mills) ............................................................. 12
2. Spiral Model (Original: Boehm) .................................................................... 13

1
1. Perangkat Lunak
Perangkat lunak, adalah program komputer yang berfungsi sebagai sarana
interaksi antara pengguna dan perangkat keras. Perangkat lunak dapat juga
dikatakan sebagai 'penterjemah' perintah-perintah yang dijalankan pengguna
komputer untuk diteruskan ke atau diproses oleh perangkat keras. Perangkat lunak
ini dibagi menjadi 3 tingkatan: tingkatan program aplikasi (application program
misalnya OpenOffice.org), tingkatan sistem operasi (operating system misalnya
Ubuntu), dan tingkatan bahasa pemrograman (yang dibagi lagi atas bahasa
pemrograman tingkat tinggi seperti Pascal dan bahasa pemrograman tingkat
rendah yaitu bahasa rakitan).
Perangkat lunak merupakan program komputer yang isi instruksinya dapat
diubah dengan mudah. Perangkat lunak umumnya digunakan untuk mengontrol
perangkat keras (yang sering disebut sebagai device driver), melakukan proses
perhitungan, berinteraksi dengan perangkat lunak yang lebih mendasar lainnya
(seperti sistem operasi, dan bahasa pemrograman), dan lain-lain.
Gambaran tentang perangkat lunak di dalam sebuah buku teks mungkin
mengambil bentuk berikut :
1. Perangkat lunak merupakan perintah (program komputer) yang bila dieksekusi
memberikan fungsi dan unjuk kerja seperti yang diinginkan.
2. Perangkat lunak adalah struktur data yang memungkinkan program
memanipulasi informasi secara proporsional, dan
3. Perangkat lunak merupakan dokumen yang menggambarkan operasi dan
kegunaan program.

1.1 Karakteristik Perangkat Lunak

Perangkat lunak lebih merupakan elemen logika dan bukan merupakan
elemen sistem fisik. Dengan demikian, perangkat lunak memiliki ciri yang
berbeda dari perangkat keras :
1. Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuk yang
klasik (pabrikasi). Biaya untuk perangkat lunak dikonsentrasikan kepada
pengembangan. Hal ini berarti proyek perangkat lunak tidak dapat diatur
seperti pengaturan proyek-proyek pemanufakturan.
2. Perangkat lunak tidak pernah usang. Perangkat lunak tidak rentan terhadap
pengaruh lingkungan yang merusak yang menyebabkan perangkat keras
menjadi usang. Selama hidupnya, perangkat lunak mengalami perubahan
(pemeliharaan). Aspek lain dari keusangan menggambarkan perbedaan antara
perangkat keras dan perangkat lunak. Bila komponen suatu perangkat keras
telah usang, komponen dapat diganti dengan suku cadangnya. Namun tidak
ada suku cadang bagi perangkat lunak. Setiap kegagalan perangkat lunak
menggambarkan kesalahan dalam perancangan atau proses di mana rancangan
diterjemahkan ke dalam kode mesin yang dapat dieksekusi.

1
3. Sebagian besar perangkat lunak dibuat secara custom-built, serta tidak dapat
dirakit dari komponen yang sudah ada. Perhatikan bagaimana perangkat keras
untuk produksi berbasis mikroprosesor dirancang dan dibuat. Setelah masing-
masing komponen diseleksi, perangkat keras dapat dipesan secara terpisah.
Sementara pada perangkat lunak, tidak katalog komponen perangkat lunak.
Memang memungkinkan untuk memesan perangkat lunak secara terpisah,
tetapi tetap merupakan satu kesatuan yang lengkap, bukan sebagai komponen
yang dapat dipasangkan ke dalam program-program yang baru.

1.2 Komponen Perangkat lunak

Reusability merupakan suatu ciri penting dari komponen perangkat lunak
kualitas tinggi. Sebuah komponen perangkat lunak harus didesain dan
diimplementasikan sehingga dapat dipakai lagi pada berbagai program yang
berbeda.
Komponen perangkat lunak dibangun dengan bahasa pemrograman yang
memiliki kosakata yang terbatas, sebuah tata bahasa yang dibatasi secara eksplisit, serta
aturan-aturan syntax dan semantik yang dibentuk secara baik.
Bahasa tingkat mesin merupakan perwakilan simbolik dari serangkaian instruksi
CPU. Bila program tidak dirancang dengan baik dan hanya memiliki sedikit dokumentasi,
maka bahasa tingkat mesin akan menjadi sebuah mimpi buruk.
Bahasa tingkat menengah memungkinkan pengambang perangkat lunak
serta program tidak tergantung pada mesin. Pada kenyataannya, bahasa tingkat
menengah meng-compile dan menginterpretasikan hasil bahasa tingkat mesin
sebagai keluaran.
Kode mesin, bahasa assembly (tingkat mesin), bahasa pemrograman
tingkat menengah, sering disebut tiga generasi bahasa komputer yang pertama.
Dengan bahasa-bahasa tersebut, pemrogram harus melihat dengan baik
kekhususan struktur informasi maupun kontrol pemrograman itu sendiri.
Demikianlah bahasa di dalam tiga generasi yang pertama dimasukkan ke dalam
jenis bahasa prosedural.
Bahasa generasi keempat, juga disebut bahasa nonprosedural menggerakkan
pengembang perangkat lunak untuk mengkhususkan pada detail prosedural.

1.3 Aplikasi Perangkat Lunak

Perangkat lunak dapat diaplikasikan ke berbagai situasi di mana
serangkaian langkah prosedural (seperti algoritma) telah didefinisikan.
Kandungan informasi dan determinasi merupakan faktor penting dalam
menentukan sifat aplikasi perangkat lunak. Content mengarah kepada arti dan
bentuk dari informasi yang masuk dan keluar.
Memang sulit untuk menentukan kategori umum untuk aplikasi perangkat lunak.
Ketika kompleksitas perangkat lunak mulai muncul, maka penggolongan yang rapi
menjadi hilang. Area perangkat lunak berikut menunjukkan luasnya aplikasi potensial :

2
Perangkat Lunak Sistem. Perangkat lunak sistem merupakan sekumpulan
program yang ditulis untuk melayani program-program yang lain. Banyak
perangkat lunak sistem (misal kompiler, editor, dan utilitas pengatur file)
memproses struktur-struktur informasi yang lengkap namun tetap. Perangkat
lunak sistem ditandai dengan eratnya interaksi dengan perangkat keras komputer.

Perangkat Lunak Real-Time. Program-program yang memonitor/menganalisis

kejadian dunia nyata pada saat terjadinya disebut perangkat lunak real-time.
Elemen-elemen perangkat lunak real-time mencakup komponen pengumpul data
yang mengumpulkan dan memformat informasi dari lingkungan eksternal, sebuah
komponen analisis yang mentransformasi informasi pada saat dibutuhkan oleh
aplikasi, sebuah komponen kontrol/output yang memberi respon kepada
lingkungan eksternal, serta sebuah komponen monitor yang mengkoordinasi
semua komponen lain agar respon real-timenya (I milidetik sampai 1 menit) dapat
tetap terjaga. Perlu dicatat di sini bahwa real-time berbeda dengan interaksi atau
timesharing. Sistem real-time harus merespon di dalam suatu rentang waktu yang
tetap. Waktu respon sebuah sistem interaktif (timesharing) secara normal dapat
diperpanjang tanpa memberikan risiko kerusakan pada hasil.

Perangkat Lunak Bisnis. Sistem diskrit (contohnya payroll, account

receivable/payable, inventory) telah mengembangkan perangkat lunak sistem
informasi manajemen (MIS) yang mengakses satu atau lebih database besar yang
berisi informasi bisnis. Aplikasi perangkat lunak bisnis juga meliputi
penghitungan klien/server serta penghitungan interaktif (misal pemrosesan
transaksi point-of-sale).

Perangkat Lunak Teknik dan Ilmu Pengetahuan. Perangkat lunak teknik dan
ilmu pengetahuan ditandai algoritma number crunching. Perangkat lunak ini
memiliki jangkauan aplikasi mulai dari astronomi sampai vulkanologi, dari
analisis otomotif sampai dinamika orbit pesawat ruang angkasa, dan dari biologi
molekuler sampai pabrik yang sudah diotomatisasi. Computer-aided design,
simulasi sistem, dan aplikasi interaktif yang lain, sudah mulai memakai ciri-ciri
perangkat lunak sistem genap dan real-time.

Embedded Software. Embedded software ada dalam read-only memory dan

dipakai untuk mengontrol hasil serta sistem untuk keperluan konsumen dan pasar
industri. Embedded software dapat melakukan fungsi yang terbatas serta fungsi
esoterik (misal key pad control untuk microwave) atau memberikan kemampuan
kontrol dan fungsi yang penting (contohnya fungsi dijital dalam sebuah automobil
seperti kontrol bahan bakar, penampilan dash-board, sistem rem, dll).

3
Perangkat Lunak Komputer Personal. Pengolah kata, spreadsheet, grafik
komputer, multimedia, hiburan, manajemen database, aplikasi keuangan, bisnis
dan personal, jaringan eksternal atau akses database hanya merupakan beberapa
saja dari ratusan aplikasi yang ada.

Perangkat Lunak Kecerdasan Buatan. Perangkat lunak kecerdasan buatan

(Artificial Inteligent /AI) menggunakan algoritma non-numeris untuk
memecahkan masalah kompleks yang tidak sesuai untuk perhitungan atau analisis
secara langsung. Perangkat lunak kecerdasan buatan adalah pengenalan pola
(image dan voice), pembuktian teorema, dan permainan game. Di tahun-tahun
terakhir, cabang perangkat lunak kecerdasan buatan yang baru, yang disebut
artificial neural network, telah berkembang. Jaringan syaraf mensimulasi struktur
proses-proses otak dan kemudian membawanya kepada perangkat lunak kelas
baru yang dapat mengenali pola-pola yang kompleks serta belajar dari
pengalaman-pengalaman masa lalu.

2. Rekayasa Perangkat Lunak

Istilah Rekayasa Perangkat Lunak (RPL) secara umum disepakati sebagai
terjemahan dari istilah Software Engineering. Istilah Software Engineering mulai
dipopulerkan tahun 1968 pada Software Engineering Conference yang
diselenggarakan oleh NATO. Sebagian orang mengartikan RPL hanya sebatas
pada bagaimana membuat program komputer. Padahal ada perbedaan yang
mendasar antara perangkat lunak (software) dan program komputer.
Perangkat lunak adalah seluruh perintah yang digunakan untuk
memproses informasi. Perangkat lunak dapat berupa program atau prosedur.
Program adalah kumpulan perintah yang dimengerti oleh komputer sedangkan
prosedur adalah perintah yang dibutuhkan oleh pengguna dalam memproses
informasi (O’Brien, 1999). Pengertian RPL sendiri adalah sebagai berikut:
Suatu disiplin ilmu yang membahas semua aspek produksi perangkat
lunak, mulai dari tahap awal yaitu analisa kebutuhan pengguna,
menentukan spesifikasi dari kebutuhan pengguna, disain,
pengkodean, pengujian sampai pemeliharaan sistem setelah
digunakan.
Jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan
program komputer. Pernyataan “semua aspek produksi” pada pengertian di atas,
mempunyai arti semua hal yang berhubungan dengan proses produksi seperti
manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas
sampai dengan pelatihan pengguna merupakan bagian dari RPL.

4
2.1 Tujuan Rekayasa Perangkat Lunak
Secara umum tujuan RPL tidak berbeda dengan bidang rekayasa yang lain.
Mari kita perhatikan Gambar 1. berikut ini.

Dari Gambar 1 dapat diartikan bahwa bidang rekayasa akan selalu

berusaha menghasilkan output yang kinerjanya tinggi, biaya rendah dan waktu
penyelesaian yang tepat. Secara lebih khusus kita dapat menyatakan tujuan RPL
adalah :
a. Memperoleh biaya produksi perangkat lunak yang rendah.
b. Menghasilkan perangkat lunak yang kinerjanya tinggi, andal dan tepat waktu.
c. Menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis
platform.
d. Menghasilkan perangkat lunak yang biaya perawatannya rendah.

2.2 Ruang Lingkup

Sesuai definisi yang telah disampaikan sebelumnya, maka ruang lingkup
RPL dapat digambarkan sebagai berikut.

Software requirements berhubungan dengan spesifikasi kebutuhan dan

persyaratan perangkat lunak.
Software design mencakup proses penentuan arsitektur, komponen,
antarmuka, dan karakteristik lain dari perangkat lunak.
Software construction berhubungan dengan detil pengembangan perangkat
lunak, termasuk algoritma, pengkodean, pengujian, dan pencarian
kesalahan.
Software testing meliputi pengujian pada keseluruhan perilaku perangkat
lunak.
Software maintenance mencakup upaya-upaya perawatan ketika perangkat
lunak telah dioperasikan.

5
 Software configuration management berhubungan dengan usaha
perubahan konfigurasi perangkat lunak untuk memenuhi kebutuhan
tertentu.
Software engineering management berkaitan dengan pengelolaan dan
pengukuran RPL, termasuk perencanaan proyek perangkat lunak.
Software engineering tools and methods mencakup kajian teoritis tentang
alat bantu dan metode RPL.
Software engineering process berhubungan dengan definisi, implementasi,
pengukuran, pengelolaan, perubahan dan perbaikan proses RPL.
Software quality menitikberatkan pada kualitas dan daur hidup perangkat
lunak.

3. Mitos Rekayasa Perangkat Lunak

Sekarang ini kebanyakan kaum profesional yang memilki banyak
pengetahuan mengetahui berbagai mitos di bidang ilmu yang digelutinya – sikap
yang salah yang menyebabkan masalah yang serius bagi manajer serta masyarakat
teknisi. Tetapi sikap lama tersebut memang sangat sulit diubah, dan sisa-sisa
mitos perangkat lunak masih tetap dipercaya.

Mitos manajemen. Manajer yang bertanggung-jawab terhadap masalah

perangkat lunak, seperti juga manajer pada kebanyakan disimplin, sering
mengalami tekanan karena masalah pengaturan keuangan, menjaga jadwal agar
tidak kacau, dan peningkatan kualitas.
Mitos : Kita sudah memilki buku yang penuh dengan standar dan prosedur
untuk membuat perangkat lunak. Apakah buku itu tidak memberikan
semua yang ingin diketahui oleh staf saya?
Kenyataan : Buku standar mungkin ada, tetapi apakah buku-buku tersebut
dipakai? Apakah para praktisi perangkat lunak sadar akan keberadaan
buku-buku tersebut? Apakah dia benar-benar mencerminkan praktik
perkembangan perangkat lunak modern? Apakah sudah lengkap? Dalam
banyak hal, jawaban untuk semua pertanyaan di atas adalah “tidak”.

Mitos : Staf saya sebenarnya memiliki alat pengembangan perangkat

lunak terkini, karena itulah kita membeli komputer baru bagi mereka.
Kenyataan : Dibutuhkan lebih dari sekedar mainframe model terakhir,
workstation atau PC untuk mengembangkan perangkat lunak berkualitas
tinggi. Computer-aided software engineering (CASE) lebih penting
daripada perangkat keras untuk mencapai kualitas dan produktivitas yang
tinggi, tetapi mayoritas pengembang perangkat lunak tetap belum
menggunakannya.

6
 Mitos : Jika kita mentaati jadwal, kita dapat menambah lebih banyak lagi
pemrogram dan mengejar ketinggalan (kadang-kadang disebut
“Mongolian horde concept”).
Kenyataan : Perkembangan perangkat lunak bukan merupakan proses
mekanis seperti pemanufakturan. Semakin manusia bertambah, para
personil yang sudah bekerja lebih lama harus menggunakan waktu untuk
membimbing pendatang baru, sehingga akan mengurangi jumlah waktu
yang digunakan dalam fase pengembangan produksi.

Mitos Pelanggan. Pelanggan mempercayai mitos tentang perangkat lunak karena

manajer dan para pelaksana yang bertanggung-jawab atas masalah perangkat
lunak hanya bekerja sedikit saja untuk memperbaiki kesalahan informasi. Mitos
ini membawa ke arah pengharapan yang salah (oleh pelanggan) dan ketidak-
puasan pengembang.
Mitos: pernyataan umum tentang obyektivitas sudah cukup untuk memulai
menulis program. Kita dapat mengisi detailnya nanti.
Kenyataan: Definisi awal yang buruk merupakan sebab utama gagalnya
kerja perangkat lunak. Deskripsi yang detail dan formal tentang domain
informasi, fungsi, unjuk kerja , interface, design constraint, dan kriteria
validasi merupakan hal yang mendasar. Ciri-ciri dapat ditentukan melalui
komunikasi yang hati-hati antara pelanggan dan pengembang.

Mitos: kebutuhan proyek berubah terus-menerus, tetapi perubahan

tersebut dapat diakomodasi karena perangkat lunak bersifat fleksibel.
Kenyataan: Memang benar bahwa kebutuhan-kebutuhan perangkat lunak
selalu berubah. Tetapi pengaruh perubahan itu bervariasi sesuai waktu saat
perangkat lunak dikenalkan. Perubahan-perubahan pada fungsi, unjuk
kerja, atau karakteristik lain pada saat implementasi (kode dan tes) besar
pengaruhnya terhadap biaya. Perubahan, ketika diminta setelah perangkat
lunak diproduksi, dapat lebih mahal daripada bila perubahan yang sama
dilakukan pada saat yang lebih awal.

Mitos Para Praktisi. Seperti yang ditulis sebelumnya, selama masa awal
perangkat lunak, pemrograman dilihat sebagai sebuah karya seni. Cara dan
kebiasaan lama tetap sukar lenyap.
Mitos: Sekali kita menulis program, dan dapat membuatnya bekerja,
pekerjaan kita akan terselesaikan.
Kenyataan: Data industri menunjukkan bahwa antara 50 sampai 70 dari
semua usaha yang dilakukan pada sebuah program akan terus dilakukan
sampai program diantar ke tangan konsumen untuk yang pertama kalinya.

7
 Mitos: Saya benar-benar tidak mempunyai cara untuk “menilai” kualitas
program, kecuali jika saya dapat membuat program itu “berjalan”.
Kenyataan: Salah satu dari mekanisme jaminan kualitas perangkat lunak
yang paling efektif dapat diperkirakan dari awal proyek – formal technical
review. Tinjauan perangkat lunak merupakan “filter kualitas” yang lebih
efektif daripada pengujian untuk menemukan kelas-kelas kesalahan
perangkat lunak yang khusus.

Mitos: satu-satunya yang dapat disampaikan untuk sebuah proyek yang

sukses adalah program yang bekerja.
Kenyataan: Program yang bekerja hanya merupakan salah satu bagian
dari konfigurasi perangkat lunak yang menyangkut program, dokumen,
dan data. Dokumentasi membentuk fondasi bagi perkembangan yang
berhasil, serta yang lebih penting lagi, memberikan tuntunan bagi tugas
pemeliharaan perangkat lunak.

4. Proses Perangkat Lunak

Merupakan aktifitas yang saling terkait (koheren) untuk
menspesifikasikan, merancang, implementasi dan pengujian sistem perangkat
lunak.
Karakteristik proses pada perangkat lunak terdiri dari:
- Understandability
- Supportability
- Acceptability
- Reliability
- Maintainability
Secara umum prorses prangkat lunak terdiri dari beberapa proses yaitu,
spesifikasi, pengambangan, validasi, dan evolusi.
Spesifikasi merupakan apa yang harus dilakukan oleh perangkat lunak dan
batasan/kendala pengembangannya
Pengembangan merupakan proses memproduksi sistem perangkat lunak
Validasi merupakan pengujian perangkat lunak terhadap keinginan pengguna
Evolusi merupakan perubahan perangkat lunak berdasarkan perubahan keinginan.
Pada tahap proses rekayasa perangkat lunak, ciri-ciri yang dimunculkan
antara lain:
Biasanya, spesif
Lebih menghilangkan pembedaan sampai spesifikasi, desain, dan
manufacture
Tidak dalam bentuk fisik untuk menguji sistem
Software tidak bisa wear-out (maintenance bukan berarti mengganti
komponen)

8
5. Model Proses Perangkat Lunak
Merupakan suatu representasi proses software yang disderhanakan,
dipresentasikan dari perspektif khusus
5.1 Model Konvensional
Model konvensional pada proses perangkat lunak mulai dikembangkan
sebelum pertengahan 1970-an. Dengan ciri cara spesifikasi narrative Victorian
novel, hard to read, hard to understand, dan virtually impossible to maintain.
Banyak macam model konvensional “klasik”, antara lain:
 Linear Sequential Model / Waterfall Model
 Prototyping Model
 RAD (Rapid Application Development) Model

Linear SequentialModel/ Waterfall Model

Model ini adalah model klasik yang bersifat sistematis, berurutan dalam
membangun software. Berikut ini ada dua gambaran dari waterfall model.
Sekalipun keduanya menggunakan nama-nama fase yang berbeda, namun sama
dalam intinya. Fase-fase dalam Waterfall Model menurut referensi Pressman:

Fase-fase dalam Waterfall Model menurut referensi Sommerville :

1. Requirements analysis and definition: Mengumpulkan kebutuhan secara

lengkap kemudian kemudian dianalisis dan didefinisikan kebutuhan yang
harus dipenuhi oleh program yang akan dibangun. Fase ini harus dikerjakan
secara lengkap untuk bisa menghasilkan desain yang lengkap.
2. System and software design: Desain dikerjakan setelah kebutuhan selesai
dikumpulkan secara lengkap.

9
3. Implementation and unit testing: desain program diterjemahkan ke dalam
kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan.
Program yang dibangun langsung diuji baik secara unit.
4. Integration and system testing: Penyatuan unit-unit program kemudian diuji
secara keseluruhan (system testing).
5. Operation and maintenance: mengoperasikan program dilingkungannya dan
melakukan pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi
dengan situasi sebenarnya.
Kekurangan yang utama dari model ini adalah kesulitan dalam
mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya harus
lengkap dan selesai sebelum mengerjakan fase berikutnya.
Masalah dengan waterfall :
1. Perubahan sulit dilakukan karena sifatnya yang kaku.
2. Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara
lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada
kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan
kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar
terjadi.
3. Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana
proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa
bagian sub-proyek.

Model Prototyping
Kadang-kadang klien hanya memberikan beberapa kebutuhan umum
software tanpa detil input, proses atau detil output. Di lain waktu mungkin dimana
tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang
digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user
interface. Ketika situasi seperti ini terjadi model prototyping sangat membantu
proses pembangunan software.
Proses pada model prototyping yang digambarkan pada gambar 1, bisa
dijelaskan sebagai berikut:
 pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan
umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan
dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini,
pada awal pengumpulan kebutuhan
 perancangan : perancangan dilakukan cepat dan rancangan mewakili semua
aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan
prototype.
 Evaluasi prototype: klien mengevaluasi prototype yang dibuat dan digunakan
untuk memperjelas kebutuhan software.

10
 Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan
terpenuhi. Prototype-prototype dibuat untuk memuaskan kebutuhan klien dan
untuk memahami kebutuhan klien lebih baik.
Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun
software lebih cepat, namun tidak semua prototype bisa dimanfaatkan.
Sekalipun prototype memudahkan komunikasi antar developer dan klien,
membuat klien mendapat gambaran awal dari prototype , membantu mendapatkan
kebutuhan detil lebih baik namun demikian prototype juga menimbulkan masalah:
1. dalam membuat prototype banyak hal yang diabaikan seperti efisiensi,
kualitas, kemudahan dipelihara/dikembangkan, dan kecocokan dengan
lingkungan yang sebenarnya. Jika klien merasa cocok dengan prototype yang
disajikan dan berkeras terhadap produk tersebut, maka developer harus kerja
keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas
yang seharusnya.
2. developer biasanya melakukan kompromi dalam beberapa hal karena harus
membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak
sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih
sederhana.
Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh
klien dan developer bahwa prototype yang dibangun merupakan alat untuk
mendefinisikan kebutuhan software.

RAD (Rapid Application Development)

RAD adalah model proses pembangunan PL yang incremental. RAD
menekankan pada siklus pembangunan yang pendek/singkat. RAD mengadopsi
model waterfall dan pembangunan dalam waktu singkat dicapai dengan
menerapkan component based construction. Waktu yang singkat adalah batasan
yang penting untuk model ini.
Jika kebutuhan lengkap dan jelas maka waktu yang dibutuhkan untuk
menyelesaikan secara komplit software yang dibuat adalah misalnya 60 sampai 90
hari.
Kelemahan dalam model ini:
1. tidak cocok untuk proyek skala besar
2. proyek bisa gagal karena waktu yang disepakati tidak dipenuhi
3. sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini
4. resiko teknis yang tinggi juga kurang cocok untuk model ini

11
 Fase-fase di atas menggambarkan proses dalam model RAD. Sistem
dibagi-bagi menjadi beberapa modul dan dikerjakan dalam waktu yang hampir
bersamaan dalam batasan waktu yang sudah ditentukan.
1. Business modelling : menjawab pertanyaan-pertanyaan: informasi apa yang
mengendalikan proses bisnis? Informasi apa yang dihasilkan? Siapa yang
menghasilkan informasi? Kemana informasi itu diberikan? Siapa yang
mengolah informasi?  kebutuhan dari sistem
2. Data modelling: aliran informasi yang sudah didefinisikan, disusun menjadi
sekumpulan objek data. Ditentukan karakteristik/atribut dan hubungan antar
objek-objek tersebut  analisis kebutuhan dan data
3. Process Modelling : objek data yang sudah didefinisikan diubah menjadi
aliran informasi yang diperlukan untukmenjalankan fungsi-fungsi bisnis.
4. Application Generation: RAD menggunakan component program yang sudah
ada atau membuat component yang bisa digunakan lagi, selama diperlukan.
6. Testing and Turnover: karena menggunakan component yang sudah ada,
maka kebanyakan component sudah melalui uji atau testing. Namun
component baru dan interface harus tetap diuji.

5.2 Model Evolusioner

Bersifat iteratif/ mengandung perulangan. Hasil proses berupa produk
yang makin lama makin lengkap sampai versi terlengkap dihasilkan sebagai
produk akhir dari proses.
Dua model dalam evolutionary software process model adalah:
1. Incremental Model (Original: Mills)

12
1) kombinasikan element-element dari waterfall dengan sifat iterasi/perulangan.
2) element-element dalam waterfall dikerjakan dengan hasil berupa produk
dengan spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga
akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari
yang sebelumnya. Demikian seterusnya hingga semua spesifikasi memenuhi
kebutuhan yang ditetapkan oleh pengguna.
3) produk hasil increment pertama biasanya produk inti (core product), yaitu
produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh
pengguna atau menjalani review/pengecekan detil. Hasil review tersebut
menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus
dikerjakan sampai produk yang komplit dihasilkan.
4) model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak
cukup.
5) Mampu mengakomodasi perubahan secara fleksibel.
6) Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi
produk yang sudah bisa berfungsi dengan spesifikasi dasar.
Masalah dengan Incremental model:
a. cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding)
b. mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam
rencana spesifikasi masing-masing hasil increment

2. Spiral Model (Original: Boehm)

Proses digambarkan sebagai spiral. Setiap loop mewakili satu fase dari
software process. Loop paling dalam berfokus pada kelayakan dari sistem, loop
selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan
desain sistem dan seterusnya. Setiap Loop dibagi menjadi beberapa sektor :
1. Objective settings (menentukan tujuan): menentukan tujuan dari fase yang
ditentukan. Batasan-batasan pada proses dan produk sudah diketahui.
Perencanaan sudah disiapkan. Resiko dari proyek sudah diketahui. Alternatif

13
 strategi sudah disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah
direncanakan.
2. Risk assessment and reduction (Penanganan dan pengurangan resiko): setiap
resiko dianalisis secara detil pada sektor ini. Langkah-langkah penanganan
dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan
kebutuhan.
3. Development and Validation (Pembangunan dan pengujian): Setelah evaluasi
resiko, maka model pengembangan sistem dipilih. Misalnya jika resiko user
interface dominan, maka membuat prototype User Interface. Jika bagian
keamanan yang bermasalah, makamenggunakan model formal dengan
perhitungan matematis, dan jika masalahnya adalah integrasi sistem model
waterfall lebih cocok.
4. Planning: Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus
ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya
rencana untuk loop selanjutnya.
Pembagian sektor tidak bisa saja dikembangkan seperti pada pembagian
sektor berikut pada model variasi spiral di bawah ini:

1. Customer communication: membangun komunikasi yang baik dengan

pengguna/customer.
2. Planning: mendefinisikan sesumber, batas waktu, informasi-informasi lain
seputar proyek
3. Risk analysis: identifikasi resiko managemen dan teknis
4. Engineering: pembangunan contoh-contoh aplikasi, misalnya prototype
5. Construction and release : pembangunan, test, install dan support.
6. Customer evaluation: mendapatkan feedback dari pengguna beradasarkan
evaluasi PL pada fase engineering dan fase instalasi.
Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu
yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan
yang realistik untuk PL berskala besar. Pengguna dan pembangun bisa memahami
dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama
proses dapat diamati dengan baik. Namun demikian, waktu yang cukup panjang
mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan
biaya yang lebih besar.

14