2. Model Prototipe 3. Model Rad

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