Rapid Application

Development
(RAD)
Dr. Ahmad Sabri
Universitas Gunadarma
 • Rapid Application Development (RAD) adalah
konsep pengembangan yang dilakukan dengan
singkat namun tetap mengutamakan kualitas
melalui: joint application development untuk
mengumpulan requirements, prototyping dan
pengujian secara iteratif.
• Konsep RAD sangat erat hubungannya dengan
prototyping pada SDLC konvensional, karena
Pendahuluan memiliki tujuan yang sama: mempersingkat waktu
pengembangan.
• Penerapan prototyping pada RAD ditujukan untuk
mengakomodasi perubahan bisnis user yang cepat.
• Karena kecepatannya, sebagian pengembang
memandang sebagai pendekatan yang ampuh untuk
membangun e-commerce baru, sebelum didahului
oleh kompetitor.
• Gagasan RAD dikemukakan oleh James
Martin pada 1991
• RAD menekankan pada user involvement
yang besar dalam mendisain dan
membangun sistem.
• Setelah itu konsep RAD berkembang sesuai
dengan kemajuan teknologi informasi
• Materi ini membahas konsep RAD yang
dikemukakan oleh Kendall (2011)
• RAD, tidak bisa dipungkiri, telah menjadi metode
pengembangan yang cocok untuk aplikasi yang akan
diluncurkan dalam waktu dekat, menggunakan software
development tools yang dengan cepat dapat meng-
generate layout layar, tabel database dan report.
• Penggunaan RAD cenderung menggantikan tahapan
analisa dan user requirements dengan prototyping dan
sesi joint application development (JAD) secara iteratif
dan bertahap (incremental).
• Hal ini memungkinkan user terlibat secara interaktif dan
bertahap dalam merumuskan requirements dan disain
melalui serangkaian proses pengembangan.
• Ketika user menyetujui disain sistem, ia melakukannya
berdasar representasi visual dari disain, bukan berdasar
konsep di atas kertas, sebagaimana model SDLC
tradisional.
 Gunakan RAD antara lain jika:
1. Tim anda terdiri dari programmer dan
analis yang handal dan berpengalaman.
2. Terdapat tekanan untuk melakukan
Kapan percepatan dalam pengembangan sistem.
menggunakan 3. Terdapat peluang untuk menjadi pelopor
dalam suatu inovasi e-commerce, dan
RAD? tidak ingin peluang itu diambil oleh
kompetitor. Karena banyak benefit yang
dapat diraih dengan menjadi pelopor.
Sasaran RAD
1. Menghasilkan sistem berkualitas
tinggi dengan
2. waktu pengembangan yang High
singkat dengan delivery yang
segera dan speed
3. berbiaya rendah

• Terdapat trade-off antara ketiganya High Low

• RAD mengatur pencapaian
ketiganya sehingga secara agregat
quality cost
mencapai hasil maksimal
 • Sasaran SDLC tradisional tidak menekankan
pada waktu delivery yang singkat dan biaya
rendah.
• Walaupun demikian, RAD tetap harus
berjalan berdasar prinsip-prinsip software
engineering, dengan syarat:
RAD vs SDLC • tidak menghambat kecepatan delivery
tradisional • tidak mengurangi user requirements
• harus proporsional dari segi waktu. Misalnya:
Sistem dengan lifetime 3 bulan seharusnya tidak
memakan waktu 18 bulan untuk
pengembangannya
 Definisi kualitas dalam konteks RAD:
“terpenuhinya kebutuhan pengguna (user
requirement) seefektif mungkin pada saat sistem
diserahkan ke user”

Kualitas Dalam RAD, kualitas tidak diartikan sebagai

“terpenuhinya spesifikasi tertulis seefektif mungkin”

Artinya: dalam mendapatkan user requirement, RAD

selalu melibatkan user dalam proses development.
 RAD memiliki karakteristik sbb:
• Konsep pengembangan tidak kaku (adaptif terhadap
perkembangan user requirements)
• Menekankan pada user involvement dan user
responsibility (user harus terlibat dan berperan
dalam proses pengembangan)
Karakteristik • Waktu penuntasan 2 – 6 bulan
• Dilakukan secara bertahap (incremental) jika sistem
terlalu besar
• Setiap tahapan merupakan sebuah self-contained
working system yang di-deliver dalam waktu yang
berdekatan
Skema penekanan biaya
 • Tools: code generators, CASE tools, prototyping
tools, 4GL
• Metodologi: untuk menggunakan tools dengan
Unsur seefektif mungkin
pembentuk • Partisipan: high-skilled programmer and analysts,
end user
RAD • Manajemen: memfasilitasi fast-development
• Infrastruktur: tempat di mana fast-development
dilakukan
Time boxing
• Time boxing diterapkan untuk menjaga agar proyek berjalan tepat waktu, dengan
menentukan prioritas pengembangan beserta delivery deadlines-nya.
• Jika proyek cenderung meleset dari batas waktu, maka dilakukan pengurangan
requirements (yang tidak prioritas) agar batas waktu dapat ditepati, alih-alih
memundurkan batas waktu.
 Rapid Business Analysis

• Studi kelayakan dan riset terkait

RAD project • Timescale yang pendek mengakibatkan
structure perlunya JAD workshops untuk
mendapatkan user requirements dan
protoyping

Incremental delivery

• Pengembangan iteratif dengan melibatkan

user
• prototyping dan delivery dalam jeda waktu
singkat
Rapid Business
Analysis
 JAD workshops
• Berlangsung lokasi khusus (terpisah dari business
environment)
Joint • Output berupa user requirements yang
terdokumentasi penuh
Application • Berlangsung 3 – 5 hari
Development • Berlangsung di bawah arahan high-skilled facilitator
untuk memastikan
(JAD) • semua isu tercakup dalam pembahasan
• semua hambatan politis terselesaikan
• user dan developer memiliki pengaruh yang setara
Iterative
development
Incremental development
• Memecah projek menjadi bagian yang
lebih kecil
• Didahului oleh analisa projek secara Modul A
keseluruhan
• Setiap incremental adalah sistem yang
self contained (berdiri sendiri) Modul B

• Setiap increment umumnya

melibatkan iterative development dan
prototyping
 Prototyping berlangsung dalam aktivitas developer
dan klien untuk mereview dan memperbaiki sistem
berdasarkan working software sampai dicapai
software yang memenuhi requirements.

Prototyping Keunggulan prototyping:

• Lebih akurat dalam mendapatkan requirements
• Biaya produksi lebih rendah
• Gold plating: memungkinkan developer
menambahkan fitur yang tidak terpikirkan
sebelumnya
Pendekatan 1. System prototyping
prototyping 2. Throwaway prototyping
System prototyping
• System prototyping: pengembangan
dalam waktu singkat untuk menghasilkan
prototipe awal sistem dengan fitur
minimal.
• Berdasarkan masukan dari user,
developer kembali menganalisa,
mendisain, dan mengimplementasikan
prototipe berikutnya dengan berbagai
perbaikan dan penambahan fitur
• Proses ini berulang sampai analis dan
user (beserta sponsor) menyepakati
prototipe yang dianggap memenuhi
fungsionalitas sesuai dengan
requirements .
• Dalam hal ini, prototipe berevolusi
menjadi working system.
Throwaway prototyping
• Dilakukan jika user tidak dapat mendeskripsikan
bagaimana kerja sistem yang diinginkannya.
• Pengembangan prototype ditujukan untuk
mengeksplorasi berbagai alternatif disain, alih-
alih membangun suatu sistem baru (tidak
sebagaimana pada system prototyping).
• Developer mengajukan berbagai contoh
prototipe untuk membantu user medapat
visualisasi sistem.
• Prototipe yang dibangun bukanlah working
system, melainkan berupa mock-up (model)
yang ditampilkan pada layar.
• Saat semua isu sudah terpecahkan, prototipe • Dalam hal ini, prototype tidak berevolusi
disain tidak lagi digunakan (thrown away), dan menjadi final disain
project melangkah ke tahap disain dan
implementasi.