MODEL SIKLUS HIDUP PERANGKAT LUNAK
V- Model
2.3 RAPID APPLICATION DEVELOPMENT (RAD)
Model pengembangan aplikasi cepat/Rapid Applicationm Development (RAD) diusulkan pada awal tahun sembilan puluhan dalam upaya untuk mengatasi kekakuan model air terjun (dan turunannya) yang membuat sulit untuk mengakomodasi permintaan perubahan dari pelanggan. Ini mengusulkan beberapa ekstensi radikal untuk model air terjun.
Model ini memiliki fitur model prototipe dan model evolusioner. Ini menyebarkan mo de l pengiriman evolusioner untuk mendapatkan dan menggabungkan umpan balik pelanggan pada versi yang dikirimkan secara bertahap.
Dalam model ini prototipe dibangun, dan secara bertahap fitur dikembangkan dan dikirimkan ke pelanggan. Tetapi tidak seperti model prototipe, prototipe tidak dibuang tetapi ditingkatkan dan digunakan dalam konstruksi perangkat lunak
Tujuan utama dari model RAD adalah sebagai berikut:
• Untuk mengurangi waktu yang dibutuhkan dan biaya yang dikeluarkan untuk mengembangkan sistem perangkat lunak.
• Untuk membatasi biaya mengakomodasi permintaan perubahan.
• Untuk mengurangi kesenjangan komunikasi antara pelanggan dan pengembang.
Motivasi utama
Dalam model air terjun berulang, persyaratan pelanggan perlu dikumpulkan, dianalisis, didokumentasikan, dan ditandatangani di muka, sebelum pengembangan apa pun dapat dimulai. Namun, seringkali klien tidak tahu apa yang sebenarnya mereka inginkan sampai mereka melihat sistem yang bekerja. Sekarang telah diterima dengan baik di antara para praktisi bahwa hanya melalui proses mengomentari aplikasi yang diinstal, persyaratan yang tepat dapat dibawa keluar. Tetapi dalam model air terjun berulang, pelanggan tidak dapat melihat perangkat lunak, sampai pengembangan selesai dalam segala hal dan perangkat lunak telah dikirimkan dan diinstal. Secara alami, perangkat lunak yang dikirimkan seringkali tidak memenuhi harapan pelanggan dan banyak permintaan perubahan dibuat oleh pelanggan.
Perubahan dimasukkan melalui upaya pemeliharaan berikutnya. Hal ini membuat biaya untuk mengakomodasi perubahan menjadi sangat tinggi dan biasanya membutuhkan waktu lama untuk memiliki solusi yang baik yang dapat memenuhi kebutuhan pelanggan. Model RAD mencoba mengatasi masalah ini dengan mengundang dan memasukkan umpan balik pelanggan pada pengembangan dan prototipe.
Bekerja di RAD
Dalam model RAD, pengembangan berlangsung dalam serangkaian siklus pendek atau iterasi. Setiap saat, tim pengembangan hanya berfokus pada iterasi saat ini, dan oleh karena itu rencana dibuat untuk satu peningkatan pada satu waktu. Waktu yang direncanakan untuk setiap iterasi disebut kotak waktu. Setiap iterasi direncanakan untuk meningkatkan fungsionalitas aplikasi yang diimplementasikan hanya dalam jumlah kecil. Selama setiap kotak waktu, perangkat lunak bergaya prototipe cepat dan kotor untuk beberapa fungsi dikembangkan. Pelanggan mengevaluasi prototipe dan memberikan umpan balik tentang perbaikan spesifik yang mungkin diperlukan. Prototipe disempurnakan berdasarkan umpan balik pelanggan. Harap dicatat bahwa prototipe tidak dimaksudkan untuk dirilis ke pelanggan untuk penggunaan biasa.
Tim pengembangan hampir selalu menyertakan perwakilan pelanggan untuk mengklarifikasi persyaratan. Hal ini dimaksudkan untuk membuat sistem disesuaikan dengan kebutuhan pelanggan yang tepat dan juga untuk menjembatani kesenjangan komunikasi antara pelanggan dan tim pengembangan. Tim pengembangan biasanya terdiri dari sekitar lima hingga enam anggota, termasuk perwakilan pelanggan.
Bagaimana RAD memfasilitasi akomodasi permintaan perubahan?
Pelanggan biasanya menyarankan perubahan pada fitur tertentu hanya setelah mereka menggunakannya. Karena fitur dikirimkan sedikit demi sedikit, pelanggan dapat memberikan permintaan perubahan terkait fitur yang sudah dikirimkan. Penggabungan permintaan perubahan tersebut tepat setelah pengiriman fitur tambahan menghemat biaya karena hal ini dilakukan sebelum investasi besar dilakukan dalam pengembangan dan pengujian sejumlah besar fitur.
Bagaimana RAD memfasilitasi pengembangan yang lebih cepat?
Penurunan waktu dan biaya pengembangan, dan pada saat yang sama peningkatan fleksibilitas untuk memasukkan perubahan dicapai dalam model RAD dalam dua cara utama— penggunaan perencanaan yang minimal dan penggunaan ulang yang berat dari setiap kode yang ada melalui pembuatan prototipe cepat. Kurangnya perencanaan jangka panjang dan rinci memberikan fleksibilitas untuk mengakomodasi perubahan kebutuhan di kemudian hari.
Penggunaan kembali kode yang ada telah diadopsi sebagai mekanisme penting untuk mengurangi biaya pengembangan.
Model RAD menekankan penggunaan kembali kode sebagai sarana penting untuk menyelesaikan proyek lebih cepat. Faktanya, pengadopsi model RAD adalah yang paling awal merangkul bahasa dan praktik berorientasi objek. Selanjutnya, RAD menganjurkan penggunaan alat khusus untuk memfasilitasi pembuatan prototipe kerja dengan cepat. Alat khusus ini biasanya mendukung fitur berikut:
• Gaya visual perkembangan.
• Penggunaan komponen yang dapat digunakan kembali.
Penerapan Model RAD
Berikut ini adalah beberapa karakteristik aplikasi yang menunjukkan kesesuaiannya dengan gaya pengembangan RAD:
• Perangkat lunak yang disesuaikan: Seperti yang telah ditunjukkan, perangkat lunak yang disesuaikan dikembangkan untuk satu atau dua pelanggan hanya dengan mengadaptasi perangkat lunak yang ada. Dalam proyek pengembangan perangkat lunak yang disesuaikan, penggunaan kembali yang substansial biasanya dibuat dari kode dari perangkat lunak yang sudah ada sebelumnya. Misalnya, sebuah perusahaan mungkin telah mengembangkan perangkat lunak untuk mengotomatisasi kegiatan pemrosesan data di satu atau lebih lembaga pendidikan. Ketika lembaga lain meminta paket otomasi untuk dikembangkan, biasanya hanya beberapa aspek yang perlu disesuaikan—karena di antara lembaga pendidikan yang berbeda, sebagian besar kegiatan pemrosesan data seperti pendaftaran siswa, penilaian, pengumpulan biaya, manajemen perkebunan, akuntansi, pemeliharaan catatan layanan staf dll mirip untuk sebagian besar. Proyek yang melibatkan penjahitan semacam itu dapat dilakukan dengan cepat dan hemat biaya menggunakan model RAD.
• Perangkat lunak non-kritis: Model RAD menyarankan bahwa perangkat lunak cepat dan kotor pertama-tama harus dikembangkan dan kemudian ini harus disempurnakan menjadi perangkat lunak akhir untuk pengiriman. Oleh karena itu, produk yang dikembangkan biasanya jauh dari kinerja dan keandalan yang optimal. Dalam hal ini, untuk proyek pengembangan yang dipahami dengan baik dan di mana ruang lingkup penggunaan kembali agak terbatas, model air terjun berulang dapat memberikan solusi yang lebih baik.
• Jadwal proyek yang sangat terbatas: RAD bertujuan untuk mengurangi waktu pengembangan dengan mengorbankan dokumentasi, kinerja, dan keandalan yang baik. Secara alami, untuk proyek dengan jadwal waktu yang sangat agresif, model RAD harus lebih disukai.
• Perangkat lunak besar: Hanya untuk perangkat lunak yang mendukung banyak fitur (perangkat lunak besar), pengembangan dan pengiriman tambahan dapat dilakukan secara bermakna.
Karakteristik aplikasi yang membuat RAD tidak sesuai
Gaya pengembangan RAD tidak disarankan jika proyek pengembangan memiliki satu atau lebih karakteristik berikut:
• Produk generik (distribusi luas): Produk perangkat lunak bersifat generik dan biasanya memiliki distribusi yang luas. Untuk sistem seperti itu, kinerja dan keandalan yang optimal sangat penting dalam pasar yang kompetitif. Seperti yang telah dibahas, model pengembangan RAD mungkin tidak menghasilkan sistem yang memiliki kinerja dan keandalan yang optimal.
• Persyaratan kinerja dan/atau keandalan yang optimal: Untuk kategori produk tertentu, diperlukan kinerja atau keandalan yang optimal. Contoh sistem tersebut termasuk sistem operasi (diperlukan keandalan tinggi) dan perangkat lunak simulator penerbangan (diperlukan kinerja tinggi). Jika sistem tersebut akan dikembangkan dengan menggunakan model RAD, kinerja dan keandalan produk yang diinginkan mungkin tidak dapat diwujudkan.
• Kurangnya produk serupa: Jika sebuah perusahaan belum mengembangkan perangkat lunak serupa, maka hampir tidak akan dapat menggunakan kembali banyak artefak yang ada. Dengan tidak adanya komponen plug-in yang memadai, menjadi sulit untuk mengembangkan prototipe cepat melalui penggunaan kembali, dan penggunaan model RAD menjadi tidak berarti.
• Entitas monolitik: Untuk perangkat lunak tertentu, terutama perangkat lunak berukuran kecil, mungkin sulit untuk membagi fitur yang diperlukan menjadi bagian-bagian yang dapat dikembangkan dan dikirimkan secara bertahap.
Dalam hal ini, menjadi sulit untuk mengembangkan perangkat lunak secara bertahap.
Perbandingan RAD dengan Model Lain
Pada bagian ini, kita akan membandingkan keuntungan dan kerugian relatif dari RAD dengan model siklus hidup lainnya.
RAD versus model prototipe
Dalam model prototyping, prototipe yang dikembangkan terutama digunakan oleh tim pengembangan untuk mendapatkan wawasan tentang masalah, memilih antara alternatif, dan memperoleh umpan balik pelanggan. Kode yang dikembangkan selama konstruksi prototipe biasanya dibuang. Sebaliknya, di RAD itu adalah prototipe yang dikembangkan yang berkembang menjadi perangkat lunak yang dapat dikirimkan. Meskipun RAD diharapkan mengarah pada pengembangan perangkat lunak yang lebih cepat dibandingkan dengan model tradisional (seperti model prototyping), meskipun kualitas dan keandalannya akan lebih rendah.
RAD versus model air terjun berulang
Dalam model air terjun iteratif, semua fungsi perangkat lunak dikembangkan bersama.
Di sisi lain, dalam model RAD, fungsionalitas produk dikembangkan secara bertahap melalui penggunaan ulang kode dan desain yang berat. Selanjutnya, dalam model RAD, umpan balik pelanggan diperoleh pada prototipe yang dikembangkan setelah setiap iterasi dan berdasarkan ini prototipe disempurnakan. Dengan demikian, menjadi mudah untuk mengakomodasi setiap permintaan untuk perubahan persyaratan. Namun, model air terjun berulang tidak mendukung mekanisme apa pun untuk mengakomodasi permintaan perubahan persyaratan apa pun. Model air terjun iteratif memang memiliki beberapa keunggulan penting yang antara lain sebagai berikut. Penggunaan model air terjun berulang mengarah pada produksi dokumentasi berkualitas baik yang dapat membantu selama pemeliharaan perangkat lunak. Selain itu, perangkat lunak yang dikembangkan biasanya memiliki kualitas dan keandalan yang lebih baik daripada yang dikembangkan menggunakan RAD.
RAD versus model evolusioner
Perkembangan bertahap adalah ciri khas model evolusioner dan RAD. Namun, dalam RAD setiap kenaikan pada dasarnya menghasilkan prototipe yang cepat dan kotor, sedangkan dalam model evolusioner setiap kenaikan dikembangkan secara sistematis menggunakan model air terjun iteratif. Juga dalam model RAD, perangkat lunak dikembangkan dalam peningkatan yang jauh lebih pendek dibandingkan model evolusioner. Dengan kata lain, fungsionalitas tambahan yang dikembangkan memiliki granularitas yang cukup besar dalam model evolusi.