direkatkan.Perubahan akan terjadi karena kesalahan-kesalahan ditentukan,karena perangkat lunak harus disesuaikan untuk mengakomodasi perubahan-perubahan
di dalam lingkungan eksternalnya.
Contohnya perubahan yang dibutuhkan sebagai akibat dari perangkat peripheral atau sistem operasi yang baru.
C. 2. Model Prototipe
Prototyping paradigma dimulai dengan pengumpulan kebutuhan.
Secara ideal prototipe berfungsi sebagai sebuah mekanisme untuk
mengidentifikasi kebutuhan perangkat lunak.
Bila prototipe sedang bekerja atau dibangun,pengembang harus mempergunakan fragmen-fragmen yang ada atau mengaplikasikan alat-alat bantu
Contohnya:report generator,window manager,dll yang memungkinkan program
yang bekerja untuk dimunculkan cecara cepat.
Prototipe bisa berfungsi sebagai “sistem pertama”
Prototipe bisa juga menjadi masalah karena alasan-alasan sebagai berikut: 1. Pelanggan melihat apa yang tampak sebagai versi perangkat lunak yang bekerja
tanpa melihat bahwa prototipe itu dijalankan bersama-sama tanpa melihat bahwa didalam permintaan untuk membjuatnya bekerja.
2. Pengembang sering membuat kompromi-kompromi implementasi untuk membuat prototipe bekerja dengan cepat.Sistem operasi atau bahasa
pemrograman yang tidak sesuai bisa dipakai secara sederhana karena mungkin diperoleh da dikenal .
Prototyping dipakai bila ditemui kondisi
• Definisi user bersifat umum • user tidak tahu pasti apa yang diinginkan
• definisi user bersifat tidak rinci • user tidak tahu pasti apa bagaimana bentuk
– masukan – proses
– keluaran
• pengembang merasa tidak tahu pasti tentang – pilihan algoritma yang akan dipakai
– bagaimana lingkungan sistem yang akan dikembangkan – bentuk, sifat karakteristik antar-muka pemakai
• Terdapat ketidak pastian dipihak user yaitu tentang apa diinginkan • Terdapat ketidak pastian dipihak pengembang yaitu tentangapa yang harus
dilakukan
C. 3. Model Rad
- 18 -
Rapid Aplication Development RAD adalah sebuah model proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan
yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier dimana perkembangan cepat dicapai dengan menggunakan
pendekatan konstruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “system fungsional yang utuh”
dalam periode waktu yang sangat pendek kira-kira dalam waktu 60 – 90 hari.
Pendekatan RAD melingkupi fase – fase sebagai berikut :
Bussines modeling. Aliran informasi diantara fungsi – fungsi bisnis dimodelkan dengan suatu cara
untuk menjawab pertanyaan berikut : Informasi apa yang mengendalikan proses bisnis? Informasi apa yang dimunculkan? Siapa yang memunculkan? Kemana
informasi itu pergi? Siapa yang memprosesnya?
Data modeling.
Aliran informasi yang didefinisikan sebagai bagian dari fase Bussines modeling disaring kedalam serangkaian objek data yang dibutuhkan untuk menopang bisnis
tersebut. Karakteristik disebut atribut masing – masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisakan .
Process modeling.
Aliran informasi yang didefinisikan didalam fase data modeling ditrnsformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi
bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data.
Aplication generation.
RAD mengasumsikan pemakaian teknik generasi ke-empat dalam pembahasan selanjutnya. Selain menghasilkan perangkat lunak dengan menggunakan bahasa
pemrograman generasi ke-tiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program yang ada pada saat memunkinkan
atau menciptakan komponen yang biasa dipakai lagi bila perlu. Pada semua kasus, alat – alat Bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat
lunak.
Testing and turnover.
Karena proses RAD menekankan pada pemakaian kembali, banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian . Tetapi
komponen baru harus diuji dan semua interface harus dilatih secara penuh.
Berikut kekurangan yang dimiliki RAD:
Bagi proyek yang besar tapi berskala, RAD memerlukan SDM yang memadai, untuk menciptakan jumlah tim RAD yang baik.
RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktifitas
rapid-fire yang diperlukan untuk melengkapi sebuah system, didalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada dari tiap
konstituen, proyek RAD akan gagal.
Tidak semua aplikasi sesuai untuk RAD. Bila system tidak dapat dimodulasikan
dengan teratur, pembangunan penting pada RAD akan sangat terganggu.
- 19 -
Gambar Model RAD Dari gambar diatas, secara jelas batasan waktu yang dibebankan pada sebuah
proyek RAD memerlukan “ruang lingkup yang bias diskala”. Jika sebuah aplikasi bisnis dapat dimodulkan dengan cara tertentu sehingga memungkinkan setiap fungsi mayor
untuk dilengkapi dalam waktu kurang dari 3 bulan dengan menggunakan pendekatan yang digambarkan diatas,maka aplikasi itu merupakan kandidat bagi RAD. Masing –
masing fungsi mayor bias dibicarakan oleh suatu tim RAD yang terpisah, dan kemudian diintegrasikan untuk membentuk suatu keadaan.
C. 4. Model Proses Perangkat Lunak Evolusioner