Ikhtisar
Rapid Application Development adalah metodologi pengembangan perangkat lunak yang melibatkan teknik seperti pembangunan berulang dan prototipe perangkat lunak. Menurut Whitten (2004), itu adalah penggabungan berbagai teknik terstruktur, terutama data-driven Teknik Informatika, dengan prototyping teknik untuk mempercepat pengembangan perangkat lunak sistem. [1]
Dalam Rapid Application Development, teknik terstruktur dan prototyping terutama digunakan untuk menetapkan persyaratan pengguna dan untuk merancang sistem final. Proses pembangunan dimulai dengan pengembangan model data awal dan model proses bisnis dengan menggunakan teknik terstruktur. Pada tahap berikutnya, persyaratan diverifikasi menggunakan prototyping, akhirnya untuk memperbaiki data dan model proses. Tahap-tahap ini diulang iteratively;. Hasil pengembangan lebih lanjut dalam "kebutuhan bisnis gabungan dan laporan desain teknis yang akan digunakan untuk membangun sistem baru" [1]
pendekatan RAD mungkin memerlukan kompromi dalam fungsionalitas dan kinerja dalam pertukaran untuk memungkinkan pengembangan yang lebih cepat dan memfasilitasi pemeliharaan aplikasi.[Sunting] Sejarah
Rapid Application Development adalah istilah yang awalnya digunakan untuk menggambarkan suatu proses pengembangan software yang diperkenalkan oleh James Martin pada tahun 1991. Martin metodologi iteratif melibatkan pengembangan dan pembangunan prototipe. Baru-baru ini, istilah dan singkatan yang telah datang untuk digunakan dalam arti, lebih luas generik yang mencakup berbagai teknik yang ditujukan untuk mempercepat pengembangan aplikasi, seperti penggunaan kerangka kerja aplikasi web dan jenis lain dari kerangka kerja perangkat lunak.
pengembangan aplikasi cepat merupakan tanggapan terhadap proses non-tangkas dikembangkan pada 1970-an dan 1980-an, seperti Structured Analisis dan Desain Sistem Metode dan lainnya Waterfall model. Satu masalah dengan metodologi sebelumnya adalah bahwa aplikasi begitu lama untuk membangun bahwa persyaratan telah berubah sebelum sistem itu selesai, sehingga sistem yang tidak memadai atau bahkan tidak dapat digunakan. Masalah lain adalah asumsi bahwa kebutuhan metodis tahap analisis saja akan mengidentifikasi semua persyaratan penting. Cukup bukti [rujukan?] Membuktikan fakta bahwa hal ini jarang terjadi, bahkan untuk proyek dengan profesional yang sangat berpengalaman di semua tingkat.
Dimulai dengan ide-ide dari Brian Gallagher, Alex Balchin, Barry Boehm dan Scott Shultz, James Martin mengembangkan pendekatan Rapid Application Development selama tahun 1980 di IBM dan akhirnya diresmikan itu dengan menerbitkan buku pada tahun 1991, Rapid Application Development.
Efektivitas relatif RAD
Pergeseran dari sesi klien tradisional berbasis / pengembangan server untuk membuka pembangunan sessionless dan kolaborasi seperti Web 2.0 telah meningkatkan kebutuhan untuk iterasi lebih cepat melalui fase SDLC. [2] ini, ditambah dengan pertumbuhan penggunaan kerangka kerja open source dan produk dalam pembangunan komersial inti, telah, bagi banyak pengembang, bunga menghidupkan kembali dalam mencari metodologi RAD peluru perak.
Meskipun metodologi RAD kebanyakan software digunakan kembali angkat, struktur tim kecil dan pengembangan sistem terdistribusi, paling RAD praktisi mengakui bahwa, pada akhirnya, tidak ada satu "cepat" metodologi yang dapat memberikan perintah perbaikan besarnya atas setiap metodologi pengembangan lainnya.
Semua rasa RAD memiliki potensi untuk menyediakan kerangka kerja yang baik untuk pengembangan produk lebih cepat dengan kualitas kode membaik, namun keberhasilan pelaksanaan dan manfaat sering bergantung pada jenis proyek, jadwal, siklus rilis software dan budaya perusahaan. Ini juga mungkin menarik bahwa beberapa vendor software terbesar seperti Microsoft [3] dan IBM [4] tidak secara ekstensif menggunakan RAD dalam pengembangan produk andalan mereka dan untuk sebagian besar, mereka masih terutama mengandalkan metodologi waterfall tradisional dengan beberapa derajat spiral. [5]
Tabel berikut berisi ringkasan tingkat tinggi dari beberapa rasa utama dari RAD dan kekuatan relatif mereka dan kelemahan.
| Pengembangan perangkat Lunak | |
Pros | Meminimalkan fitur creep dengan mengembangkan dengan interval pendek mengakibatkan proyek perangkat lunak miniatur dan melepaskan produk di mini-bertahap. |
Cons | iterasi pendek tidak mungkin menambah fungsionalitas cukup, menyebabkan keterlambatan signifikan dalam iterasi akhir. Sejak Agile menekankan pada komunikasi real-time (sebaiknya tatap muka), memanfaatkan itu bermasalah untuk multi-tim besar pengembangan sistem terdistribusi. metode Agile menghasilkan sangat sedikit dokumentasi tertulis dan memerlukan sejumlah besar dokumentasi pasca proyek. |
| Extreme Programming (XP) | |
Pros | Menurunkan biaya perubahan melalui spiral cepat persyaratan baru. Sebagian besar kegiatan desain berlangsung secara bertahap dan on the fly. |
Cons | Programmer diharuskan untuk bekerja berpasangan (yang mungkin sulit bagi beberapa pengembang). Tidak ada "desain detil" up-depan, yang dapat mengakibatkan usaha mendesain ulang lebih dalam jangka panjang. Juara bisnis yang melekat pada waktu proyek lengkap dapat berpotensi menjadi satu titik kegagalan proyek dan sumber utama stres bagi tim. |
| Joint Application Development (JAD) // pengembangan aplikasi bersama | |
Pros | Menangkap suara pelanggan dengan melibatkan mereka dalam desain dan pengembangan aplikasi melalui serangkaian lokakarya kolaboratif yang disebut sesi JAD. |
Cons | Klien dapat membuat suatu visi produk yang tidak realistis dan meminta emas plating-luas, memimpin tim untuk over-atau under-mengembangkan fungsi. |
| Lean software development (LD) // pengembangan perangkat lunak Lean | |
Pros | |
Cons | Produk mungkin kehilangan daya saingnya karena fungsionalitas inti tidak cukup dan mungkin menunjukkan kualitas secara keseluruhan yang buruk. |
| Rapid Application Development (RAD) | |
Pros | Meningkatkan suasana kolaboratif yang kuat dan dinamis mengumpulkan persyaratan. Pemilik Bisnis aktif berpartisipasi dalam prototyping, menulis kasus pengujian dan unit testing melakukan. |
Cons | Ketergantungan pada tim kohesif yang kuat dan komitmen individu untuk proyek. Pengambilan keputusan bergantung pada tim fungsionalitas fitur dan proses pengambilan keputusan komunal dengan tingkat yang lebih rendah PM terpusat dan otoritas rekayasa. |
| Scrum // orang banyak | |
Pros | Peningkatan produktivitas dalam tim yang sebelumnya lumpuh dengan berat "proses", kemampuan untuk memprioritaskan bekerja, pemanfaatan backlog untuk menyelesaikan item dalam serangkaian iterasi pendek atau sprint, harian diukur kemajuan dan komunikasi. |
Cons | Ketergantungan pada fasilitasi oleh master yang mungkin tidak memiliki kekuatan politik untuk menghilangkan hambatan dan menyampaikan tujuan sprint. Karena ketergantungan pada tim mengorganisir diri dan penolakan dari "pengendalian proses" terpusat tradisional, perebutan kekuasaan internal dapat melumpuhkan tim. |
referensi :
http://en.wikipedia.org/wiki/Rapid_application_development
