RAD Model (Rapid Application Development) Rapid Application Development atau RAD adalah salah satu metode pengembangan
sistem
informasi
Pengembangan
suatu
sekurangnya 12
hari, namun dengan menggunakan metode RAD sistem dapat
sistem
dengan
informasi
waktu normal
yang
relatif
membutuhkan
singkat. waktu
diselesaikan dalam waktu yang singkat, sekitar 3 - 4 hari. Model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang dicapai dengan menerapkan :
Component based construction ( pemrograman berbasis komponen bukan prosedural).
Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada.
Pembangkitan kode program otomatis/semi otomatis.
Multiple team (banyak tim), tiap tim menyelesaikan satu tugas yang selevel tapi tidak sama. Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun.
Model RAD hampir sama dengan model waterfall. Hal yang membedakan adalah siklus pengembangan model ini sangat pendek dengan p enerapan teknik yang cepat. Perangkat lunak dibagi menjadi beberapa modul dan dikerjakan oleh tim dalam waktu yang hampir bersamaan dengan waktu yang sudah ditentukan. Model ini melibatkan banyak tim, dan setiap tim mengerjakan tugas dengan tingkatan yang sama, namun berbeda modul. Menurut Britton (2001), Kelebihan dan kekurangan dalam implementasi pengembangan menggunakan model RAD : a.
Model RAD memerlukan sumber daya yang cukup besar, terutama untuk proyek dengan skala besar.
b.
Model ini cocok untuk proyek dengan skala besar.
c.
Model RAD memerlukan komitmen yang kuat antara pengembang dan pemesssan, bahkan keduanya bisa tergabung dalam satu tim 6
d.
Kinerja dari perangkat lunak yang dihasilkan dapat menjadi masalah apabila kebutuhan-kebutuhan diawal proses tidak dapat dimodulkan, sehingga pendekatan dengan model ini kurang bagus.
e.
Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini.
f.
Penghalusan dan penggabungan dari beberapa tim di akhir proses sangat diperlukan dan ini memerlukan kerja keras.
g.
Proyek memiliki kemungkinan gagal, apabila waktu yang disepakati tidak dipenuhi
h.
Risiko teknis yang tinggi juga kurang cocok untuk model ini.
Spiral Boehm (1988) mengusulkan sebuah model yang setiap loop mewakili sebuah tahapan dari proses perangkat lunak. Model Boehm tersebut berbentuk spiral. Tidak terdapat tahap yang tetap dalam model ini.
Gambar Model Spiral (Pressman, 2010: 46)
Setiap loop atau perulangan dibagi dalam 4 sektor, yaitu : a. Communication
7
Tahap perundingan kebutuhan dengan stakeholder atau pengguna untuk perangkat lunak yang akan dikembangkan. b. Planning Tahap menentukan tujuan dan hambatan dalam proses ataupun produk serta resiko-resiko proyek yang akan dijalankan. Rencana rinci ditulis secara lengkap. Strategi alternatif juga direncanakan sesuai dengan resiko yang mungkin terjadi. c. Modeling Tahap menganalisis dan merancang perangkat luank yang akan dikembangkan. Perancangan desain dapat berupa DFD, ERD dan lain sebagainya. Menentukan fitur dan model perangkat lunak yang dibutuhkan oleh pengguna. d. Construction Tahap pembangunan perangkat lunak. tahap ini biasa disebut coding , implementasi rancangan pada tahap sebelumnya ke dalam bentuk perangkat lunak yang nyata. e. Deployment Pada tahapan ini, perangkat lunak dipresentasikan kepada pengguna. Pengguna dan pengembang melakukan proses evaluasi terhadap perangkat lunak tersebut. Kemudian pengguna memberikan feedback be rupa masukan atau saran berdasarkan hasil evaluasi. Perbedaan yang terlihat antara model spiral dengan model lainnya yaitu model spiral secara eksplisit mempertimbangkan resiko-resiko yang ada. Resiko dapat diartikan sebagai hal sederhana yang dapat menyebabkan kesalahan(Hamdani dan Fera, 1999).
Unified Process Model Model ini termasuk model yang baru dalam perkembangan metode pengembangan perangkat lunak. model Unified Process dapat digunakan pada proyek skala kecil maupun skala besar. Tahap pada model ini dijelaskan sebagai berikut (Pressman, 2010): 8
a. Inception Tahap awal merupakan tahapan untuk mendiskusikan mengenai hal-hal mendasar pengembangan perangkat lunak pada pengguna. Diskusi ini meliputi tujuan dan pendanaan proyek. Tujuan dari tahap ini adalah untuk menyamakan persepsi antara pengembang dengan stakeholder atau pengguna. b. Elaboration Tahap selanjutnya adalah analisis kebutuhan pengembangan perangkat lunak atau produk. tahapan ini meliputi analisis mengenai fitur -fitur yang dibutuhkan produk, rancangan awal produk yang berkaitan dengan bagaimana produk tersebut secara keseluruhan. Tahap ini mencakup tahap planning dan modelling.
c. Gambar
Tahapan Unified Process
d. Construction Setelah tahap perancangan produk, perlu adanya implementasi dari tahap tersebut. Desain produk tersebut diimplementasikan dalam bentuk coding program. tahap ini dapat disebut juga sebagai tahap pembangunan
produk. Dalam tahap ini, produk yang sudah selesai dikembangkan akan diuji apakah sudah memenuhi kebutuhan awal pengguna atau belum. e. Transition
9
Tahap ini adalah tahapan penyampaian produk pada pengguna atau stakeholder. Pengguna akan menguji perangkat lunak dan memberikan feedback yang dapat berupa saran atau perubahan pada produk, sehingga produk menjadi lebih baik.
2. Data Flow Diagram Data flow diagram atau biasa disebut dengan DFD adalah suatu diagram yang menggunakan notasi-notasi untuk alur data sistem, yang penggunaannya sangat membantu dalam memahami sistem secara logis, terstruktur dan jelas. DFD dapat dikatakan sebagai suatu model logika data atau proses yang dibuat untuk menggambarkan dari mana asal data dan kemana tujuan data yang keluar dari sistem, dimana data disimpan, proses apa yang menghasilkan data tersebut dan interaksi antara data yang tersimpan dan proses yang dikenakan pada data tersebut. DFD sering juga disebut Bubble chart, Bubble diagram, model proses, diagram alur kerja, atau model fungsi. DFD adalah salah satu alat pembuatan model yang sering digunakan, khususnya bila fungsi-fungsi sistem merupakan bagian yang lebih penting dan kompleks dari pada data yang dimanipulasi oleh sistem. DFD hanya memberikan penekanan pada fungsi sistem yang berorientasi pada alur data dengan konsep dekomposisi. Hal ini dapat digunakan untuk penggambaran analisa maupun rancangan sistem yang mudah dikomunikasikan oleh profesional sistem kepada pemakai maupun pembuat program. DFD memodelkan
memiliki
simbol-simbol
atau
kompoen
yang
digunakan
untuk
data. Komponen tersebut adalah (Jogiyanto ,1990):
•
External entity (entitas eksternal) atau boundary (batas sistem);
•
Process (proses);
•
Data store (simpanan data).
•
Data flow (arus data); 10
Entitas
eksternal
mewakili
entitas
eksternal
yang
berkomunikasi dengan sistem yang sedang dikembangkan. Entitas eksternal
dapat berupa orang atau unit yang berinteraksi dengan
sistem, tapi berada di luar sistem. Komponen ini perlu diberi nama
Gambar sesuai dengan dunia luar yang berkomunikasi dengan sistem yang
Entitas
Eksternal
sedang dibuat modelnya, dan biasanya menggunakan kata benda, misalnya Bagian Penjualan, Dosen, Mahasiswa.
Proses merupakan kegiatan atau pekerjaan yang dilakukan oleh orang atau mesin komputer dimana aliran data masuk diubah atau ditransformasikan ke aliran data keluar.
Gambar Proses DFD
Komponen Data Store DFD ditunjukkan pada Gambar disamping Data store ini berkaitan dengan
Gambar
penyimpanan-penyimpanan, seperti file atau database
Data Store DFD
yang berkaitan dengan penyimpanan secara komputerisasi, misalnya file disket, file harddisk, file pita magnetik. Data
store juga berkaitan dengan penyimpanan secara manual seperti buku alamat, file folder,
dan
agenda.
Data
store
diberi
nama
sesuai
dengan
nama
file
penyimpanannya misalnya mahasiswa, matakuliah, dosen dan data registrasi.
11
Gambar 14.4 Alur Data DFD
Suatu data flow / alur data digambarkan dengan anak panah, yang menunjukkan arah menuju ke dan keluar dari suatu proses. Alur data ini
digunakan untuk menjelaskan perpindahan data atau paket data/informasi dari satu bagian sistem ke bagian lainnya. Alur data memiliki aturan dasar aliran data yang diperbolehkan dan yang tidak diperbolehkan. Berikut aturan dasar aliran data yang ditunjukkan pada Tabel .1
Tabel 1 aturan aliran data Aliran data
Ya
Proses Proses
√
ProsesData Store
√
Proses Entitas Eksternal
√
Tidak
Entitas eksternal Entitas Eksternal
√
Entitas eksternal Data Store
√
Data Store Data Store
√
DFD terdiri dari context diagram dan diagram rinci (DFD Levelled). Context diagram berfungsi memetakan model lingkungan (menggambarkan hubungan antara
12
entitas luar, masukan dan keluaran sistem), yang direpresentasikan dengan lingkaran tunggal yang mewakili keseluruhan sistem.
Gambar
Diagram Context Sistem Informasi Perpustakaan
DFD levelled menggambarkan sistem sebagai jaringan kerja antara fungsi yang berhubungan satu sama lain dengan aliran dan penyimpanan data, model ini hanya memodelkan sistem dari sudut pandang fungsi. Contoh diagram context
dan
diagram rinci level 2.
Gambar
Diagram level 2 Peminjaman
13
B.Sumber: Materi dalam sumber belajar ini disusun/ dirujuk/ diadaptasi/ disalin/ disarikan dari : 1.
http://informatika.web.id/category/data-flow-diagram/
2.
https://www.academia.edu/5166405/Model__Model_Pengembangan_Rekayas a_Perangkat_Lunak: Model –Model Pengembangan Rekayasa Perangkat Lunak. Oleh : Adnyana, Ngurah.
3.
http://hero.lecturer.pens.ac.id/datahero/kuliah/RPL/02%20Model%20Proses%2 0RPL.pdf: Bahan Ajar Rekayasa Perangkat Lunak. PENS ITS.
4.
http://www.elektroindonesia.com/elektro/komp27.html: Pemodelan
Dalam
Rekayasa Perangkat Lunak.oleh Hamdani, Arief dan Fera. 5.
https://www.academia.edu/17873145/Model_Pengembangan_Perangkat_Luna k_dengan_Waterfall_Rad_Prototyping_Incremental_dan_Spiral_beserta_Perbed aannya: Model Pengembangan Perangkat Lunak dengan Waterfall, RAD, Prototyping, Incremental dan Spiral beserta Perbedaannya. Oleh Kurniawan, M. Agung.
6.
https://www.academia.edu/7675480/Model_Pengembangan_Prototyping: Misri, Ali. Model Pengembangan Prototyping.
7.
https://id.wikipedia.org/wiki/Rapid_application_development: Sistem Informasi Mana jemen. Edisi ke-9. Yuliyanto dan Heri, penerjemah: Jakarta: Indeks. Terjemahan dari: Management Information System, Edisi ke-8. Pearson Prentice Hall, Inc.oleh McLeod Jr. P, GP Schell.
8.
Pressman, Roger S. 2010. Software Engineering, a Practitioner's Approach Fourth Edition. McGraw Hill
9.
https://saraswatidwi18.wordpress.com/2014/01/18/dfd-data-flow-diagram-sist em-informasi-perpustakaan-berbasis-web/
10. Hartono, Jogiyanto. 1990. Analisis dan Desain Sistem Informasi. Andi Offset : Yogyakarta. 11. Prasetya, Didik Dwi. 2013. Bahan Ajar Sistem Informasi. Universitas Negeri Malang 14