Perbandingan Tiga Model RPL

Model Sequential Linear

Model metode rekayasa perangkat lunak (RPL) ini sering disebut dengan “classic life cycle” atau model waterfall. Karena model ini diperkenalkan pertama kali pada tahun 70-an maka sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement. Secara umum tahapan pada model waterfall dapat dilihat pada gambar berikut :



Menurut Roger S. Pressman model waterfall dibagi menjadi 6 tahapan yaitu:
1. System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.
2. Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.
3. Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.
4. Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.
5. Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.
6. Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.


Model Build and Fixed
Model rekayasa perangkat lunak (RPL) ini adalah model RPL paling sederhana, sangat cocok untuk proyek-proyek kecil yang terbatas komplesitasnya karena dibangun dengan persyaratan minimal, dan umumnya tidak ada spesifikasi usaha maupun desain, dan bahkan pengujiannya sering kali diabaikan.



Walaupun demikian dibalik kesederhanaan model ini terdapat beberapa kekurangan yang perlu diperhatikan yaitu:
- Pendekatan tidak memuaskan untuk produk ukuran yang masuk akal.
- Biaya yang lebih tinggi untuk proyek yang lebih besar.
- Produk tidak akan dikirimkan tepat waktu sebagian besar kali.
- Sering menghasilkan produk dengan kualitas rendah secara keseluruhan.
- Tidak ada dokumentasi yang dihasilkan.
- Pemeliharaan dapat menjadi sangat sulit tanpa spesifikasi dan desain dokumen.

Model Metodologi RAD
Model RAD merupakan model inkremental dari proses pengembangan perangkat lunak yang menekankan pada sedikitnya siklus pengembangan. Model ini memecah suatu proyek menjadi bagian-bagian kecil yang mana tiap bagiannya dibangun dengan model yang mirip dengan Waterfall. Tujuan utama model ini adalah menyelesaikan suatu proyek per bagian, sehingga proses perencanaannya pun per bagian (walaupun pada awalnya melakukan perencanaan secara global) .



Model RAD menekankan pada fase-fase berikut :
1. Business modeling. Pada tahap ini, aliran informasi (information flow) pada fungsi-fungsi bisnis dimodelkan untuk mengetahui informasi apa yang mengendalikan proses bisnis, informasi apa yang hasilkan, siapa yang membuat informasi itu, kemana saja informasi mengalir, dan siapa yang mengolahnya.
2. Data modeling. Aliran informasi yang didefinisikan dari business modeling, disaring lagi agar bisa dijadikan bagian-bagian dari objek data yang dibutuhkan untuk mendukung bisnis tersebut. Karakteristik (atribut) setiap objek ditentukan beserta relasi antar objeknya.
3. Process modeling. Objek-objek data yang didefinisikan sebelumnya diubah agar bisa menghasilkan aliran informasi untuk diimplementasikan menjadi funsi bisnis. Pengolahan deskripsi dibuat untuk menambah, merubah, menghapus, atau mengambil kembali objek data.
4. Application generation. RAD bekerja dengan menggunakan fourth generation techniques (4GT). Sehingga pada tahap ini sangat jarang digunakan pemrograman konvensional menggunakan bahasa pemrograman generasi ketiga (third generation programming languages), tetapi lebih ditekankan pada reuse komponen-komponen (jika ada) atau membuat komponen baru (jika perlu). Dalam semua kasus, alat bantu untuk otomatisasi digunakan untuk memfasilitasi pembuatan perangkat lunak.
5. Testing and turnover. Karena menekankan pada penggunaan kembali komponen yang telah ada (reuse), sebagian komponen-komponen tersebut sudah diuji sebelumnya. Sehingga mengurangi waktu testing secara keseluruhan. Kecuali untuk komponen-komponen baru.
Kelebihan :
- RAD memang lebih cepat dari Waterfall. jika kebutuhan dan batasan project sudah diketahui dengan baik. Juga jika proyek memungkinkan untuk dimodularisasi.

Kekurangan :
- Tidak semua project bisa dipecah (dimodularisasi), sehingga belum tentu RAD dipakai pada semua proyek.
- Karena project dipecah menjadi be
berapa bagian, maka dibutuhkan banyak orang untuk membentuk suatu tim yang mengerjakan tiap bagian tersebut.
- Membutuhkan komitmen antara pengemang dengan pelanggan.
- Karena dibuat dengan reuse komponen-komponen yang sudah ada, fasilitas-fasilitas pada tiap komponen belum tentu digunakan seluruhnya oleh program yang me-reuse-nya sehingga kualitas program bisa menurun.