Perangkat Lunak (RAD)

Metode Pengembangan Perangkat Lunak (RAD)

Posted by astro plk Senin, 20 Mei 2013 0 comments

Metode Pengembangan Perangkat Lunak (RAD)

Metode pengembangan perangkat lunak yang akan saya bahas adalah model raid aplication
development atau yang biasa disebut dengan metode RAD, seperti tulisan yang sebelumnya yang
membahas metode pengembangan perangkat lunak model prototype. Metode ini di dalam
pengembangannya menggunakan semua sumberdaya yang ada dengan tujuan pengembangan
perangkat lunak yang sangat cepat dan singkat.  Dan boleh dikatakan ini merupakan model
pengembangan perangkat lunak secara linear sequential yang menekankan pada siklus
pengembangan yang sangat singkat atau pendek.

Jika kebutuhan dipahami dengan baik, proses metode pengembangan perangkat lunak RAD
memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode
waktu yang sangat pendek (kira-kira 60-90 hari). Pendekatan RAD model menekankan cakupan :

a.     Pemodelan bisnis (Bussiness Modelling)

Aliran informasi diantara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab
pertanyaan-pertanyaan berikut : Informasi apa yang mengendalikan proses bisnis ? Kemana
informasi itu pergi? Siapa yang memprosesnya ?

b.    Pemodelan data (Data Modelling)

Aliran informasi yang didefinisikan sebagai bagian dari fase pemodelan bisnis disaring ke dalam
serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik/attribut
dari masing-masing objek diidentifikasi dan hubungan antara objek-objek tersebut didefinisikan.

c.     Pemodelan proses (Process Modelling)

Aliran informasi yang didefinisikan dalam fase pemodelan data ditransformasikan untuk
mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran
pemrosesan diciptakan untuk menambah, memodifikasi, menghapus atau mendapatkan kembali
sebuah objek data.

d.    Pembuatan aplikasi (Application generation)

Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga
yang konvensional, metode pengembangan perangkat lunak RAD lebih banyak memproses
kerja untuk memakai lagi komponen program yang telah ada atau menciptakan komponen yang
bisa dipakai lagi. Pada semua kasus, alat-alat Bantu otomatis dipakai untuk memfasilitasi
kontruksi perangkat lunak.

e.    Pengujian dan pergantian (Testing and turnover)

Karena proses metode pengembangan perangkat lunak RAD menekankan pada pemakaian
kembali, banyak komponen yang telah diuji. Hal ini mengurangi keseluruhan waktu pengujian.
Tapi komponen baru harus diuji

Metode Pengembangan Perangkat Lunak (RAD)

Kelemahan model  RAD :
1. Untuk proyek dengan skala besar, metode pengembangan perangkat lunak RAD
membutuhkan sumber daya manusia yang cukup untuk membentuk sejumlah tim RAD
yang baik.
2. Metode pengembangan perangkat lunak RAD membutuhkan pengembang dan pemakai
yang mempunyai komitmen dalam aktivitas rapid-fire untuk melaksanakan aktivitas
melengkapi sistem dalam kerangka waktu yang singkat. Jika komitmen tersebut tidak
ada, proyek RAD gagal.
3. Tidak semua aplikasi sesuai untuk metode pengembangan perangkat lunak RAD.bila
sistem tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada
RAD akan menjadi sangat problematic. RAD menjadi tidak sesuai jika risiko teknisnya
tinggi.
Rapid Application Development (RAD) adalah sebuah model proses perkembangan software sekuensial
linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah
adaptasi “kecepatan tinggi” dari model sekuensial linier di mana perkembangan cepat dicapai dengan
menggunakan pendekatan kontruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses
RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode
waktu yang sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem
konstruksi, pendekatan RAD melingkupi fase – fase sebagai berikut : bussiness modeling, data modeling,
process modeling, application generation dan testing and turnover.

Model Pengembangan Sistem Informasi Berbasis Web

1. Berikut adalah beberapa model pengembangan informasi berbasis web, yaitu :
Metode RAD (Rapid Application Development)
• Merupakan metode pengembangan sistem secara linear sequential yang menekankan pada siklus
pengembangan yang sangat singkat.
• Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan
“sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60-90 hari).
• Pemakai sistem dapat mendefinisikan kebutuhan perangkat lunak dengan baik.
• Pemakai sistem bersedia meluangkan waktu yang cukup untuk berkomunikasi intensif dengan
pengembang sehubungan dengan pengembangan perangkat lunak

Rapid Application Development adalah seperangkat strategi yang terintegrasi yang ada dalam suatu
kerangka kerja meneyeluruh yang disebut Information Engineering (IE).
ALASAN MEMILIH METODE RAD
Di dalam memilih metode RAD harus memperhatikan alasan-alasan berikut ini:

1. 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.

2. 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 system supaya tidak
mengalami perubahan.
-Apabila menggunakan RAD untuk menghemat waktu, dan kalau memungkinkan bisa menghemat biaya
serta menghasilkan produk yang berkualitas.

1. 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 potongan-potongan 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.

2. Kerugian RAD
Beberapa kerugian dalam menggunakan metode RAD adalah sebagai berikut :
- Dengan melakukan pembelian belum tentu bisa menghemat biaya dibanding-
kan 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 diban-
dingkan 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.
 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.
ABSTRAK: Rapid Application Development (RAD) sebagai salah satu alternatif dari System
Development Life Cycle belakangan ini seringkali digunakan untuk mengatasi keterlambatan
yang terjadi apabila menggunakan metode konvensional. Adapun keunggulan yang bisa
didapatkan dengan menggunakan metode ini adalah kecepatan, ketepatan, dan biaya yang relatif
lebih rendah dibanding dengan metode konvensional. Di samping itu dengan melibatkan user
pada proses desain menyebabkan kebutuhan user dapat terpenuhi dengan baik dan secara
otomatis kepuasan user sebagai pengguna sistem semakin meningkat. Akan tetapi di dalam
menggunakan metode Rapid Aplication Development perlu untuk memperhatikan hal-hal yang
penting, terutama kesiapan tim, ruang lingkup sistem, kebutuhan user, dan kinerja sistem. Pada
akhirnya, sebagai salah satu alternatif dari System Development Life Cycle, maka Rapid
Aplication Development dapat dijadikan acuan untuk menghasilkan sistem informasi yang dapat
memenuhi kebutuhan user.
Kata kunci: Rapid Application Development (RAD), System Development life Cycle (SDLC).
ABSTRACT: Rapid Application Development is one of the alternatives of System Development
Life Cycle which is lately used to cope with the “slowness” of the conventional method. The
Strength of using this method is the speed, accuracy and relatively lower cost than the
conventional method. Moreover, the user’s needs can be fulfilled well by involving the user in
the design process. As a result, the user’s satisfaction will increase. However, there are several
things that should be considered in using the Rapid Application Development such as the team’s
preparation, the system territory, user’s needs, and system operation. Finally, as one of the
alternatives of System Development Life Cycle, Rapid Application Development can be used as
the fundamental to produce an information system which is able to fulfill the user’s needs.
Keywords: Rapid Application Development (RAD), System Development life Cycle (SDLC).

1. LATANG BELAKANG
Rapid Application Development (RAD)
adalah salah satu metode pengembangan suatu sistem informasi dengan waktu yang relatif
singkat. Untuk pengembangan suatu sistem informasi yang normal membutuhkan waktu minimal
180 hari, akan tetapi dengan menggunakan metode RAD suatu sistem dapat diselesaikan hanya
dalam waktu 30-90 hari.
Tujuan utama dari semua metode sistem development adalah memberikan suatu sistem yang
dapat memenuhi harapan dari para pemakai, akan tetapi sering kali di dalam melakukan
pengembangan suatu sistem tidak melibatkan para pemakai sistem secara langsung, sehingga hal
ini menyebabkan sistem informasi yang dibuat jauh dari harapan pemakai yang dapat berakibat
sistem tersebut walaupun dapat diterima tetapi para pemakai enggan untuk menggunakannya
atau bahkan para pemakai menolak untuk menggunakannya.
Pada saat RAD diimplementasikan, maka para pemakai bisa menjadi bagian dari keseluruhan
proses pengembangan sistem dengan bertindak sebagai pengambil keputusan pada setiap tahapan
pengembangan.
RAD bisa menghasilkan suatu sistem dengan cepat karena sistem yang dikembangkan dapat
memenuhi keinginan dari para pemakai sehingga dapat mengurangi waktu untuk pengembangan
ulang setelah tahap implementasi.

2. KELEMAHAN-KELEMAHAN METODE KONVENSIONAL

Adapun kelemahan-kelemahan yang terdapat pada metode konvensional adalah sebagai berikut:
- Dengan metode konvensional, maka terdapat batas waktu yang cukup lama mulai dari
pembuatan sistem sampai dengan konsumen dapat menggunakan sistem tersebut.
- Dengan metode konvensional, apabila proses pengembangan suatu sistem membutuhkan waktu
yang lama maka kebutuhan konsumen pada sistem akan mengalami perubahan seiring dengan
perubahan proses bisnis yang dilakukan oleh konsumen.
- Dengan metode konvensional, sistem yang dikembangkan tidak akan mempunyai manfaat
apabila belum diselesaikan seluruhnya.
3. ALASAN MEMILIH METODE RAD
Di dalam memilih metode RAD harus memperhatikan alasan-alasan berikut ini:

3.1 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.
3.2 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.
4. 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.
4.1 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
4.2 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.
4.3 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.
5. TAHAPAN-TAHAPAN PADA RAD
Metode RAD mempunyai 3 tahapan utama seperti yang terlihat pada gambar 1.

Gambar 1. Tahapan RAD

5.1 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.
5.2 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 perbaikan-perbaikan. Dengan demikian proses
pengembangan suatu sistem membutuhkan waktu yang cepat.
5.3 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.
5.4 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 kebutuhan-
kebutuhan 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.
6. KONDISI-KONDISI YANG MEMPENGARUHI RAD
Pada saat akan menggunakan metode RAD perlu memperhatikan kondisi-kondisi yang bisa
menunjang dan menghambat keberhasilan dari suatu sistem.
6.1 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.
6.2 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.
7. KEUNTUNGAN DAN KERUGIAN RAD
Dalam menggunakan RAD ada beberapa hal yang perlu diperhatikan terutama berkaitan dengan
keuntungan dan kerugian.
7.1 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.
7.2 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.
8. 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.
7
akan menjadi sangat problematic. RAD menjadi tidak sesuai jika risikoteknisnya tinggi.
 
 
8
BAB 2PERBANDINGAN METODE PERANGKAT LUNAK DENGANMETODE
TRADISIONAL
Metode Tradisional Metode RAD
1.
 
Aspek 
Pada 1970an, Rapid ApplicationDevelopment muncul sebagairespon mengerikan untuk
prosesnontangkas, seperti modelWaterfall. Pengembang perangkatlunak menghadapi masalah
waktudengan metodologi sebelumnyasebagai aplikasi begitu lama untuk membangun bahwa
spesifikasi persyaratan diubah oleh sistemwaktu itu selesai. Dengandemikian, metodologi
tersebutsering mengakibatkan sistem tidak dapat digunakan. Dengandemikian, metodologi
tersebutsering mengakibatkan sistem tidak dapat digunakan.
2.
 
Tahap
tahap tradisonal mengacu padaurutan tahaptahapSDLC
1.
 
Aspek 
 pembangunan prototipe untuk tujuan membangkitkan kembalidesain untuk
kebutuhan pengguna. Tujuannya adalahuntuk membangun sebuah fitur ringan yang hasil
akhirnya dalam jumlah pendek dengan waktuyang memugkinkan. Prototipeawal berfungsi
sebagai buktikonsep untuk klien, tetapi lebih penting berfungsi sebagai titik  berbicara dan alat
untuk kebutuhan pemurnian.Mengembangkan prototipe cepatdicapai dengan Computer
AidedEngineering CASE toolsSoftware yang berfokus padamenangkap
persyaratan,mengkonversi mereka ke modeldata, mengubah model data kedatabase,
danmenghasilkan kode semua dalamsatu alat.
2.
 
Tahap
Pada RAD Tahap pertamalangsung membuat analisis dandesign, lalu langsung ketahapsiklus
prototyping yaitumembangun, memperhalus danmendemonstrasikannya. Itu akanmempercepat
proses dalam pembuatan suatu project. RADmemang lebih cepat dariWaterfall. Jika kebutuhan
dan batasan project sudah diketahuidengan baik. Juga jika proyek memungkinkan
untuk dimodularisasi.
 
 
9
Gambar 1 Perbandingan RAD dengan metode tradisionalMetode tradisional Metode
Prototype pengerjaan dari suatu sistemdilakukan secara berurutan atausecara linear. Jadi jika
langkah satu belum dikerjakan maka tidak akan bisa melakukan pengerjaan langkah2, 3 dan
seterusnya. Secaraotomatis tahapan ke-3 akan bisadilakukan jika tahap ke-1 dan ke-2sudah
dilakukan.1.
 
TahapanPemilihan Fungsi., PenyusunanSistem Informasi, Evaluasi.Penggunaan
selanjutnya.Metode ini sering digunakan padadunia
riil.
Karena metode ini secarakeseluruhan akan mengacu kepadakepuasan
user.
Bisa dikatakan bahwa metode ini merupakanmetode
waterfall 
yang dilakukansecara berulang-ulang.1.
 
TahapAnalisa, Design, Code danTesting, Penerapan danPemeliharaan.