PROSES PENGEMBANGAN SIM

METODE PROTOTYPING
Menurut Raymond McLeod, prototype didefinisikan sebagai alat yang memberikan
ide bagi pembuat maupun pemakai potensial tentang cara system berfungsi dalam bentuk
lengkapnya, dan proses untuk menghasilkan sebuah prototype sisebut prototyping.
Prototyping adalah proses pembuatan model sederhana software yang mengijinkan
pengguna memiliki gambaran dasar tentang program serta melakukan pengujian awal.
Prototyping memberikan fasilitas bagi pengembang dan pemakai untuk saling berinteraksi
selama proses pembuatan, sehingga pengembang dapat dengan mudah memodelkan
perangkat lunak yang akan dibuat. Prototyping merupakan salah satu metode pengembangan
perangat lunak yang banyak digunakan.
Model tersebut dapat berupa tiga bentuk :
1.
Prototipe kertas atau model berbasis komputer yang menjelaskan bagaimana interaksi
antara pemakai dan komputer.
2.
Prototipe yang mengimplementasikan beberapa bagian fungsi dari perangkat lunak
yang sesungguhnya. Dengan cara ini pemakai akan lebih mendapatkan gambaran tentang
program yang akan dihasilkan, sehingga dapat menjabarkan lebih rinci kebutuhannya.
3.
Menggunakan perangkat lunak yang sudah ada. Seringkali pembuat software memiliki
beberapa program yang sebagian dari program tersebut mirip dengan program yang akan
dibuat.
Di dalam proses pengembangan, sering kali pemakai / pelanggan hanya dapat
mendefinisikan tujuan dan penggunan software yang dibutuhkan, tetapi tidak dapat
mendefinisikan secara rinci kebutuhan masukan, pengolahan, dan keluarannya. Di sisi lain,
pembuat software tidak memiliki kepastian akan hal tersebut. Hal ini menyebabkan
pengembang kurang memperhatikan efisiensi algoritma, kemampuan sistem operasi dan
interface yang menghubungkan manusia dan komputer. Untuk menyelaraskan antara
pelanggan dan pengembang , maka harus dibutuhkan kerjasama yanga baik di antara
keduanya sehingga pengembang akan mengetahui dengan benar apa yang diinginkan
pelanggan dengan tidak mengesampingkan segi-segi teknis. Dan pelanggan akan mengetahui
proses-proses dalam menyelesaikan sistem yang diinginkan. Dengan demikian akan
menghasilkan sistem sesuai dengan jadwal waktu penyelesaian yang telah ditentukan.
Kunci agar model prototype ini berhasil dengan baik adalah dengan mendefinisikan
aturan-aturan main pada saat awal, yaitu pelanggan dan pengembang harus setuju bahwa
prototype dibangun untuk mendefinisikan kebutuhan.
Prototyping merupakan Javascript Framework yang dibuat untuk lebih memudahkan
proses dalam membangun aplikasi berbasis web. Metode protyping sebagai suatu paradigma
baru dalam pengembangan sistem informasi, tidak hanya sekedar suatu evolusi dari metode
pengembangan sistem informasi yang sudah ada, tetapi sekaligus merupakan revolusi dalam
pengembangan sistem informasi manajemen.

Proses-proses tersebut dapat dijelaskan sebagai berikut:

1.
Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum,
kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya;
2.
Perancangan: perancangan dilakukan cepat dan rancangan mewakili semua aspek
software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype;
3.
Evaluasi Prototype: klien mengevaluasi prototype yang dibuat dan digunakan untuk
memperjelas kebutuhan software.
Terdapat tiga pendekatan utama prototyping, yaitu:
1.
THROW-AWAY
Prototype dibuat dan dites. Pengalaman yang diperoleh dari pembuatan prototype digunakan
untuk membuat produk akhir (final), kemudian prototype tersebut dibuang (tak dipakai).
2.
INCREMENTAL
Produk finalnya dibuat sebagai komponen-komponen yang terpisah. Desain produk finalnya
secara keseluruhan haya ada satu tetapi dibagi dalam komonen-komponen lebih kecil yang
terpisah (independent).
3.
EVOLUTIONARY
Pada metode ini, prototipenya tidak dibuang tetapi digunakan untuk iterasi desain berikutnya.
Dalam hal ini, sistem atau produk yang sebenarnya dipandang sebagai evolusi dari versi awal
yang sangat terbatas menuju produk final atau produk akhir.
Prototyping bekerja dengan baik pada penerapan-penerapan yang berciri
sebagai berikut:
1.
Resiko tinggi yaitu untuk masalah - masalah yang tidak terstruktur dengan baik, ada
perubahan yang besar dari waktu ke waktu, dan adanya persyaratan data yang tidak menentu.
2.
Interaksi pemakai penting. Sehingga sistem harus menyediakan dialog on-line antara
pelanggan dan komputer.
3.
Waktu penyelesaian yang cepat.
4.
Perilaku pemakai yang sulit ditebak.
5.
Sistem yang inovatif yaitu system yang membutuhkan cara penyelesaian masalah dan
penggunaan perangkat keras yang mutakhir.
Untuk memodelkan sebuah perangkat lunak, metode prototyping memiliki tahapantahapan di dalam proses pengembangannya. Tahapan inilah yang menentukan keberhasilan
dari sebuah software. Pengembang perangkat lunak harus memperhatikan tahapan dalam
metode prototyping agar software finalnya dapat diterima oleh pemakai. Dan tahapantahapan dalam prototyping tersebut adalah sebagai berikut :
1.
Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak,
mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.
2.
Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang berfokus pada
penyajian kepada pelanggan (misalnya dengan membuat input dan format output).
3.
Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai
dengan keinginan pelanggan. Jika sudah sesuai maka langkah keempat akan diambil. Jika
tidak, maka prototyping direvisi dengan mengulang langkah 1, 2 , dan 3.
4.
Mengkodekan system
Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke dalam bahasa
pemrograman yang sesuai.

5.
Menguji system
Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu
sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path,
pengujian arsitektur dan lain-lain.
6.
Evaluasi Sistem
Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang
diharapkan . Jika sudah, maka langkah ketujuh dilakukan, jika belum maka mengulangi
langkah 4 dan 5.
7.
Menggunakan system
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.
Berikut ini adalah jenis-jenis prototyping, yaitu :
1.
Feasibility prototyping
Digunakan untuk menguji kelayakan dari teknologi yang akan digunakan untuk system
informasi yang akan disusun.
2.
Requirement prototyping
Digunakan untuk mengetahui kebutuhan aktivitas bisnis user.
3.
Desain prototyping
Digunakan untuk mendorong perancangan system informasi yang akan digunakan.
4.
Implementation prototyping
Merupakan lanjutan dari rancangan, prototype ini langsung disusun sebagai suatu system
informasi yang akan digunakan.
Teknik-teknik prototyping meliputi:
1.
Perancangan Model
Perancangan awal software oleh pengembang untuk dimodelkan sebagai gambaran awal
kepada user/pengguna.
2.
Perancangan Dialog
Perancangan menu-menu pada software yang dibuat, dengan maksud agar user/pengguna
dapat dengan mudah menggunkaannya.
3.
Simulasi
Proses percobaan software kepada calon user sebelum software dinyatakan layak pakai.
Keunggulan dan Kelemahan Prototyping adalah sebagai berikut :
A. Keunggulan prototyping :
1.
Adanya komunikasi yang baik antara pengembang dan pelanggan.
2.
Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan.
3.
Pelanggan berperan aktif dalam pengembangan system.
4.
Lebih menghemat waktu dalam pengembangan system.
5.
Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya
B. Kelemahan prototyping :
1.
Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum
mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan
kemampuan pemeliharaan untuk jangka waktu lama.
2.
Pengembang biasanya ingin cepat menyelesaikan proyek. Sehingga menggunakan
algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat
selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan cetak biru
sistem .
3. Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan
teknik perancangan yang baik.

4. Proses Pembuatan Prototipe

Proses pembuatan prototipe merupakan proses yang interaktif dan berulang-ulang yang
menggabungkan langkah-langkah siklus pengembangan tradisional. Prototipe dievaluasi beberapa kali
sebelum pemakai akhir menyatakan protipe tersebut diterima. Gambar di bawah ini mengilustrasikan
proses pembuatan prototipe :

Langkah-Langkah Prototyping

a. Analisis Kebutuhan Sistem

Pembangunan sistem informasi memerlukan penyelidikan dan analisis mengenai alasan timbulnya ide
atau gagasan untuk membangun dan mengembangkan sistem informasi. Analisis dilakukan untuk
melihat berbagai komponen yang dipakai sistem yang sedang berjalan meliputi hardware, software,
jaringan dan sumber daya manusia. Analisis juga mendokumentasikan aktivitas sistem informasi
meliputi input, pemrosesan, output, penyimpanan dan pengendalian (O'Brien, 2005).
Selanjutnya melakukan studi kelayakan (feasibility study) untuk merumuskan informasi yang
dibutuhkan pemakai akhir, kebutuhan sumber daya, biaya, manfaat dan kelayakan proyek yang
diusulkan (Mulyanto, 2009).
Analisis kebutuhan sistem sebagai bagian dari studi awal bertujuan mengidentifikasi masalah dan
kebutuhan spesifik sistem. Kebutuhan spesifik sistem adalah spesifikasi mengenai hal-hal yang akan
dilakukan sistem ketika diimplementasikan (Mulyanto, 2009).
Analisis kebutuhan sistem harus mendefinisikan kebutuhan sistem yang spesifik antara lain :
1)
2)
3)
4)
5)

Masukan yang diperlukan sistem (input)

Keluaran yang dihasilkan (output)
Operasi-operasi yang dilakukan (proses)
Sumber data yang ditangani
Pengendalian (kontrol)

Spesifikasi Kebutuhan Sistem

Tahap analisis kebutuhan sistem memerlukan evaluasi untuk mengetahui kemampuan sistem dengan
mendefinisikan apa yang seharusnya dapat dilakukan oleh sistem tersebut kemudian menentukan
kriteria yang harus dipenuhi sistem. Beberapa kriteria yang harus dipenuhi adalah pencapaian tujuan,
kecepatan, biaya, kualitas informasi yang dihasilkan, efisiensi dan produktivitas, ketelitian dan
validitas dan kehandalan atau reliabilitas (Mulyanto, 2009).
b. Desain Sistem
Analisis sistem (system analysis) mendeskripsikan apa yang harus dilakukan sistem untuk memenuhi
kebutuhan informasi pemakai. Desain sistem (system design) menentukan bagaimana sistem akan
memenuhi tujuan tersebut. Desain sistem terdiri dari aktivitas desain yang menghasilkan spesifikasi
fungsional. Desain sistem dapat dipandang sebagai desain interface, data dan proses dengan tujuan
menghasilkan spesifikasi yang sesuai dengan produk dan metode interface pemakai, struktur database
serta pemrosesan dan prosedur pengendalian (Ioanna et al., 2007).
Desain sistem akan menghasilkan paket software prototipe, produk yang baik sebaiknya mencakup
tujuh bagian :
1) Fitur menu yang cepat dan mudah.
2) Tampilan input dan output.
3) Laporan yang mudah dicetak.
4) Data dictionary yang menyimpan informasi pada setiap field termasuk panjang field, pengeditan
dalam setiap laporan dan format field yang digunakan.
5) Database dengan format dan kunci record yang optimal.
6) Menampilkan query online secara tepat ke data yang tersimpan pada database.
7) Struktur yang sederhana dengan bahasa pemrograman yang mengizinkan pemakai melakukan
pemrosesan khusus, waktu kejadian, prosedur otomatis dan lain-lain.
c. Pengujian Sistem
Paket software prototipe diuji, diimplementasikan, dievaluasi dan dimodifikasi berulang-ulang
hingga dapat diterima pemakainya (O'Brien, 2005). Pengujian sistem bertujuan menemukan
kesalahan-kesalahan yang terjadi pada sistem dan melakukan revisi sistem. Tahap ini penting untuk
memastikan bahwa sistem bebas dari kesalahan (Mulyanto, 2009).
Menurut Sommerville (2001) pengujian sistem terdiri dari :

1) Pengujian unit untuk menguji komponen individual secara independen tanpa komponen sistem
yang lain untuk menjamin sistem operasi yang benar.
2) Pengujian modul yang terdiri dari komponen yang saling berhubungan.
3) Pengujian sub sistem yang terdiri dari beberapa modul yang telah diintegrasikan.
4) Pengujian sistem untuk menemukan kesalahan yang diakibatkan dari interaksi antara subsistem
dengan interfacenya serta memvalidasi persyaratan fungsional dan non fungsional.
5) Pengujian penerimaan dengan data yang dientry oleh pemakai dan bukan uji data simulasi.
6) Dokumentasi berupa pencatatan terhadap setiap langkah pekerjaan dari awal sampai akhir
pembuatan program.
Pengujian sistem informasi berbasis web dapat menggunakan teknik dan metode pengujian
perangkat lunak tradisional. Pengujian aplikasi web meliputi pengujian tautan, pengujian browser,
pengujian usabilitas, pengujian muatan, tegangan dan pengujian malar (Simarmata, 2009).
Penerimaan pengguna (user) terhadap sistem dapat dievaluasi dengan mengukur kepuasan user
terhadap sistem yang diujikan. Pengukuran kepuasan meliputi tampilan sistem, kesesuaian dengan
kebutuhan user, kecepatan dan ketepatan sistem untuk menghasilkan informasi yang diinginkan user.
Ada beberapa model pengukuran kepuasan user terhadap sistem, diantaranya adalah Technology
Acceptance Model (TAM), End User Computing (EUC) Satisfaction, Task Technology Fit (TTF)
Analysis dan Human Organizational Technology (HOT) Fit Model.
Salah satu model pengukuran yang telah diterjemahkan ke dalam beberapa bahasa berbeda dan
tidak menunjukkan perbedaan hasil pengukuran yang signifikan adalah End User Computing (EUC)
Satisfaction. Model ini menekankan kepuasan user terhadap aspek teknologi meliputi aspek isi,
keakuratan, format, waktu dan kemudahan penggunaan sistem (Chin & Mathew, 2000).
d. Implementasi
Setelah prototipe diterima maka pada tahap ini merupakan implementasi sistem yang siap
dioperasikan dan selanjutnya terjadi proses pembelajaran terhadap sistem baru dan
membandingkannya dengan sistem lama, evaluasi secara teknis dan operasional serta interaksi
pengguna, sistem dan teknologi informasi.

METODE RAD
Rapid application development (RAD) atau rapid prototyping adalah model proses
pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD
menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat
adalah batasan yang penting untuk model ini. Rapid application development menggunakan
metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model
bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan
kebutuhan (requirement) user dan selanjutnya disingkirkan. Working model digunakan
kadang-kadang saja sebagai basis desain dan implementasi sistem final .
Model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang
dicapai dengan menerapkan :
1. Component based construction ( pemrograman berbasis komponen bukan prosedural).
2. Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada.
3. Pembangkitan kode program otomatis/semi otomatis.
4. Multiple team (banyak tim), tiap tim menyelesaikan satu tugas yang selevel tapi tidak
sama.
Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun.
Jika keutuhan yang diinginkan pada tahap analisis kebutuhan telah lengkap dan jelas, maka
waktu yang dibutuhkan untuk menyelesaikan secara lengkap perangkat lunak yang dibuat

adalah berkisar 60 sampai 90 hari. Model RAD hampir sama dengan model waterfall,
bedanya siklus pengembangan yang ditempuh model ini sangat pendek dengan penerapan
teknik yang cepat.
Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan beberapa tim dalam waktu yang
hampir bersamaan dalam waktu yang sudah ditentukan. Model ini melibatkan banyak tim,
dan setiap tim mengerjakan tugas yang selevel, namun berbeda. Sesuai dengan pembagian
modul sistem.
Beberapa hal (kelebhan dan kekurangan) yang perlu diperhatikan dalam implementasi
pengembangan menggunakan model RAD :
1. Model RAD memerlukan sumber daya yang cukup besar, terutama untuk proyek dengan
skala besar.
2. Model ini cocok untuk proyek dengan skala besar.
3. Model RAD memerlukan komitmen yang kuat antara pengembang dan pemesssan,
bahkan keduanya bisa tergabung dalam 1 tim
4. Kinerja dari perangkat lunak yang dihasilkan dapat menjadi masalah manakala
kebutuhan-kebutuhan diawal proses tidak dapat dimodulkan, sehingga pendekatan dengan
model ini kurang bagus.
5. Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini.
6. Penghalusan dan penggabungan dari beberapa tim di akhir proses sangat diperlukan dan
ini memerlukan kerja keras.
7. Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi
8. Risiko teknis yang tinggi juga kurang cocok untuk model ini.

ALASAN MEMILIH METODE RAD

Di dalam memilih metode RAD harus memperhatikan alasan-alasan berikut ini:
a. Alasan yang Buruk
- Apabila menggunakan RAD hanya untuk menghemat biaya pengembangan suatu sistem.
Hal ini disebabkan karena dengan menggunakan metode RAD membutuhkan suatu tim yang
mengerti betul mengenai manajemen biaya. Sebab bila tidak, maka biaya yang dikeluarkan
akan menjadi lebih besar.
- Apabila menggunakan RAD hanya untuk menghemat waktu pengembangan suatu sistem.
Hal ini disebabkan karena dengan menggunakan metode RAD membutuhkan suatu tim yang
mengerti betul mengenai manajemen waktu. Sebab bila tidak maka waktu yang dibutuhkan
akan menjadi lebih lama.
b. Alasan yang Baik
- Apabila menggunakan RAD untuk mendapatkan suatu desain yang dapat diterima oleh
konsumen dan dapat dikembangkan dengan mudah.
- Apabila menggunakan RAD untuk memberikan batasan-batasan pada suatu sistem supaya
tidak mengalami perubahan.
- Apabila menggunakan RAD untuk menghemat waktu, dan kalau memungkinkan bisa
menghemat biaya serta menghasilkan produk yang berkualitas.
SCHEDULE vs EKONOMI vs KUALITAS PRODUK
Ada beberapa hal yang perlu diperhatikan di dalam mengembangkan suatu sistem dengan
menggunakan metode RAD dengan berdasarkan pada schedule, ekonomi dan kualitas produk
antara lain model pengembangan, negosiasi, dan tujuan.

a. Model Pengembangan
Pada saat mengembangkan suatu sistem pasti dihadapkan dengan 3 pilihan model yaitu:
- Efficient Development (model pengembangan yang mengutamakan schedule, ekonomi dan
kualitas produk secara seimbang).
Schedule lebih cepat dari rata-rata
Ekonomi biaya lebih murah dari rata-rata
Produk lebih baik daripada kualitas rata-rata
- Sensible RAD (model pengembangan yang mengutamakan schedule dibandingkan dengan
ekonomi dan kualitas produk).
Schedule lebih cepat dari rata-rata
Ekonomi biaya lebih murah sedikit dari rata-rata
Produk lebih baik sedikit dari kualitas rata-rata
- All-out RAD (model pengembangan yang mengutamakan schedule dengan mengorbankan
ekonomi dan kualitas produk).
Schedule paling cepat
Ekonomi biaya lebih mahal dari rata-rata
Produk lebih buruk dari kualitas rata-rata
b. Negosiasi
Untuk menghasilkan suatu sistem yang sesuai dengan kebutuhan dan keinginan user maka
perlu melakukan suatu negosiasi dan bukan hanya lebih mementingkan schedule.
- RAD dapat dilakukan dengan cukup sukses apabila konsumen mampu melakukan negosiasi
untuk menentukan ekonomi atau kualitas dari suatu sistem.
- RAD bisa memperoleh kesuksesan yang lebih baik apabila konsumen mampu melakukan
negosiasi untuk menentukan ekonomi dan kualitas dari suatu sistem.
- Akan tetapi hal yang perlu diperhatikan adalah bahwa yang dimaksud negosiasi mengenai
kualitas adalah bukan berarti konsumen bisa menerima kesalahan yang semakin banyak,
tetapi yang dimaksud negosiasi adalah produk yang diterima mempunyai kekurangan baik itu
pada penggunaan, kelengkapan fasilitas atau kurang efisien.
c. Tujuan
Dengan menggunakan RAD maka ada satu atau beberapa tujuan berikut ini yang tidak akan
dapat dicapai secara bersamasama yaitu:
- Kemungkinan terjadi kesalahan yang kecil, karena pihak pengembang tidak mempunyai hak
untuk mengubah komponen- komponen yang digunakan dalam mengembangkan suatu
sistem.
- Tingkat kepuasan konsumen yang tertinggi, karena kebutuhan-kebutuhan sekunder dari
konsumen harus dikorbankan supaya suatu sistem dapat diselesaikan sesuai jadwal.
- Biaya pengembangan yang termurah, karena dengan menggunakan komponen yang sudah
ada dapat menyebabkan biaya yang lebih besar apabila dibandingkan dengan
mengembangkan komponen sendiri.
TAHAPAN-TAHAPAN PADA RAD
Metode RAD mempunyai 3 tahapan utama seperti yang terlihat pada gambar 1.

Gambar 1. Tahapan RAD

a. Rencana Kebutuhan (Requirement Planning)

Pada tahap ini, user dan analyst melakukan semacam pertemuan untuk melakukan
identifikasi tujuan dari aplikasi atau sistem dan melakukan identifikasi kebutuhan informasi
untuk mencapai tujuan. Pada tahap ini hal terpenting adalah adanya keterlibatan dari kedua
belah pihak, bukan hanya sekedar persetujuan akan proposal yang sudah dibuat. Untuk lebih
jauh lagi, keterlibatan user bukan hanya dari satu tingkatan pada suatu organisasi, melainkan
beberapa tingkatan organisasi sehingga informasi yang dibutuhkan untuk masingmasing user
dapat terpenuhi dengan baik. Di samping itu, dapat juga melakukan koordinasi dengan Chief
Information Office (CIO) atau bagian perencana strategis terutama untuk mengembangkan
suatu aplikasi E-commerce berbasis Web untuk mendapatkan informasi yang lebih detail akan
tujuan dari suatu organisasi. Pertemuan semacam ini seringkali disebut Joint Aplication
Development.
b. Proses Desain (Design Workshop)
Pada tahap ini adalah melakukan proses desain dan melakukan perbaikan-perbaikan apabila
masih terdapat ketidaksesuaian desain antara user dan analyst. Untuk tahap ini maka
keaktifan user yang terlibat sangat menentukan untuk mencapai tujuan, karena user bisa
langsung memberikan komentar apabila terdapat ketidaksesuaian pada desain. Biasanya, user
dan analyst berkumpul menjadi satu dan duduk di meja melingkar dimana masing-masing
orang bisa melihat satu dengan yang lain tanpa ada halangan.
Apabila memungkinkan, maka masingmasing user diberikan satu komputer yang
terhubung satu dengan yang lain, sehingga masing-masing bisa melihat desain yang dibuat
dan langsung memberikan komentar. Hal ini sering kali disebut dengan Group Decision
Support System (GDSS). Pada beberapa kasus, GDSS ini merupakan suatu langkah yang
ideal, karena user dan analyst dapat menyetujui desain yang dibuat untuk kemudian
dilanjutkan oleh programmer dalam pembuatan prototype dari aplikasi yang dimaksud
dengan langsung menampilkan kepada user hasilnya dengan cepat. Pada tahap desain ini
membutuhkan waktu beberapa hari, akan tetapi bisa semakin lebih lama, tergantung dari
besar kecilnya sistem yang dibuat. Pada selang waktu tersebut, user bisa memberikan
tanggapan akan sistem yang sudah dikembangkan untuk selanjutnya dilakukan perbaikanperbaikan. Dengan demikian proses pengembangan suatu sistem membutuhkan waktu yang
cepat.
c. Implementasi (Implementation)
Setelah desain dari sistem yang akan dibuat sudah disetujui baik itu oleh user dan Analyst,
maka pada tahap ini programmer mengembangkan desain menjadi suatu program. Setelah
program selesai baik itu sebagian maupun secara keseluruhan, maka dilakukan proses
pengujian terhadap program tersebut apakah terdapat kesalahan atau tidak sebelum
diaplikasikan pada suatu organisasi. Pada saat ini maka user bisa memberikan tanggapan
akan sistem yang sudah dibuat serta persetujuan mengenai sistem tersebut. Adapun hal
terpenting adalah bahwa keterlibatan user sangat diperlukan supaya sistem yang
dikembangkan dapat memberikan kepuasan kepada user, dan di samping itu, sistem yang
lama tidak perlu dijalankan secara paralel dengan sistem yang baru.
d. Tahapan keseluruhan
Dengan berdasarkan pada tahapantahapan tersebut di atas maka proses utama pengembangan
suatu sistem dengan menggunakan metode RAD adalah sebagai berikut :
- Pengembang membuat prototype berdasarkan kebutuhan-kebutuhan yang sudah
didefinisikan sebelumnya
- Desainer melakukan penilaian terhadap prototype
- User melakukan uji coba pada prototype dan memberikan masukan mengenai kebutuhankebutuhan yang kurang.

- User dan developer melakukan pertemuan untuk memberikan penilaian terhadap produk
secara bersama-sama, menyesuaikan kebutuhan serta memberikan komentar apabila
diperlukan perubahan.
- Semua kebutuhan akan sistem dan perubahan-perubahan yang terjadi dilakukan proses
timeboxed dengan mempunyai
2 kemungkinan :
Perubahan yang tidak dapat ditampung seperti yang sudah direncanakan harus dihilangkan.
Jika diperlukan, kebutuhan-kebutuhan yang bersifat sekunder ditiadakan.
KONDISI-KONDISI YANG MEMPENGARUHI RAD
Pada saat akan menggunakan metode RAD perlu memperhatikan kondisi-kondisi yang bisa
menunjang dan menghambat keberhasilan dari suatu sistem.
a. Kondisi Penunjang
Beberapa kondisi yang dapat menunjang keberhasilan dari RAD adalah sebagai berikut :
- Sistem berjalan sendiri (standalone).
- Kinerja dari sistem bukan faktor terpenting.
- Distribusi produk yang bersifat sempit.
- Ruang lingkup yang terbatas.
- Kehandalan dari sistem bukan faktor terpenting.
- Membutuhkan teknologi yang tidak terlalu baru (lebih dari 1 tahun).
- Sistem dapat dipecah-pecah menjadi bagian-bagian yang lebih kecil.
b. Kondisi Penghambat
Beberapa kondisi yang dapat menghambat keberhasilan dari RAD adalah sebagai berikut :
- Sistem harus dapat berjalan secara bersamaan dengan sistem yang lama.
- Komponen-komponen penunjang sangat langka untuk didapatkan.
- Kinerja yang optimal merupakan faktor terpenting.
- Distribusi produk yang bersifat luas.
- Ruang lingkup yang luas.
- Apabila digunakan untuk membuat Sistem Operasi, dimana membutuhkan sistem yang
handal.
- Sistem tidak dapat dipecah-pecah menjadi bagian-bagian yang lebih kecil.
KEUNTUNGAN DAN KERUGIAN RAD
Dalam menggunakan RAD ada beberapa hal yang perlu diperhatikan terutama berkaitan
dengan keuntungan dan kerugian.
a. Keuntungan RAD
Beberapa keuntungan dalam menggunakan metode RAD adalah sebagai berikut:
- Membeli sistem yang baru memungkinkan untuk lebih menghemat biaya ketimbang
mengembangkan sendiri.
- Proses pengiriman menjadi lebih mudah, hal ini dikarenakan proses pembuatan lebih
banyak menggunakan potonganpotongan script.
- Mudah untuk diamati karena menggunakan model prototype, sehingga user lebih mengerti
akan sistem yang dikembangkan.
- Lebih fleksibel karena pengembang dapat melakukan proses desain ulang pada saat yang
bersamaan.
- Bisa mengurangi penulisan kode yang kompleks karena menggunakan wizard.
- Keterlibatan user semakin meningkat karena merupakan bagian dari tim secara keseluruhan.
- Mampu meminimalkan kesalahan-kesalahan dengan menggunakan alat-alat bantuan (CASE
tools).
- Mempercepat waktu pengembangan sistem secara keseluruhan karena cenderung
mengabaikan kualitas.

- Tampilan yang lebih standar dan nyaman dengan bantuan software-software pendukung.
b. Kerugian RAD
Beberapa kerugian dalam menggunakan metode RAD adalah sebagai berikut :
- Dengan melakukan pembelian belum tentu bisa menghemat biaya dibandingkan dengan
mengembangkan sendiri.
- Membutuhkan biaya tersendiri untuk membeli peralatan-peralatan penunjang seperti
misalnya software dan hardware.
- Kesulitan melakukan pengukuran mengenai kemajuan proses.
- Kurang efisien karena apabila melakukan pengkodean dengan menggunakan tangan bisa
lebih efisien.
- Ketelitian menjadi berkurang karena tidak menggunakan metode yang formal dalam
melakukan pengkodean.
- Lebih banyak terjadi kesalahan apabila hanya mengutamakan kecepatan dibandingkan
dengan biaya dan kualitas.
- Fasilitas-fasilitas banyak yang dikurangi karena terbatasnya waktu yang tersedia.
- Sistem sulit diaplikasikan di tempat yang
lain.
- Fasilitas yang tidak perlu terkadang harus disertakan, karena menggunakan komponen yang
sudah jadi, sehingga hal ini membuat biaya semakin meningkat karena harga komponen yang
lebih lengkap semakin mahal.
KESIMPULAN
Berdasarkan pembahasan di atas, maka di dalam menggunakan metode RAD dapat
disimpulkan sebagai berikut:
- Penggunaan RAD harus digunakan secara tepat, sebab bila tidak maka akan menimbulkan
kerugian-kerugian seperti misalnya biaya yang semakin membengkak dan waktu yang
semakin lama.
- Penggunaan metode RAD harus digunakan dengan mempertimbangkan aspek waktu dan
biaya secara seimbang, tidak bisa diprioritaskan satu per satu.
- Sebagai salah satu alternatif dari SDLC maka RAD dapat dijadikan acuan untuk
Mengembangkan suatu sistem informasi yang unggul dalam hal kecepatan, ketepatan dan
biaya yang lebih rendah.
- Dengan menggunakan RAD, maka keterlibatan user menjadi semakin meningkat yang pada
akhirnya dapat meningkatkan kepuasan user terhadap sistem yang dikembangkan.