Model Prototipe

Sering seorang pelanggan mendefinisikan serangkaian sasaran umum bagi perangkat lunak, tetapi tidak melakukan mengidentifikasi kebutuhan output, pemrosesan, atupun input detail. Pada kasus yang lain, pengembang mungkin tidak memiliki kepastian terhadap efisiensi algoritme, kemampuan penyesuaian dari sebuah sistem operasi,atau bentuk-bentuk yang harus dilakukan oleh interaksi manusia dengan mesin. Dalam hal ini, serta pada banyak situasi yang lain, prototyping paradigma mungkin menawarkan pendekatan yang terbaik.

Prototyping paradigma dimulai dengan pengumpulan kebutuhan. Pengembang dan pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari software, mengidentifikasi segala kebutuhan yang diketahui, dan area garis besar diman definisi lebih jauh merupakan keharusan kemudian dilakukan “perancangan kilat”. Perancangan kilat berfokus pada penyajian dari aspek-aspek software tersebut yang akan nampak bagi pelanggan atau pemakai (contohnya pendekatan input dan format output). Perancangan kilat membawa kepada konstruksi sebuah prototipe. Prototipe tersebut dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaring kebutuhan pengembangan software. Iterasi terjadi pada saat prototipe disetel untuk memenuhi kebutuhan pelanggan, dan pada saat yang sama memungkinkan pengembang untuk secara lebih baik memahami apa yang harus dilakukannya.

Secara ideal prototipe berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan software. Bila prototipe yang sedang bekerja dibangun, pengembang harus mempergunakan fragmen – fragmen program yang ada atau mengaplikasikan alat –alat bantu (contohnya report generator, window manager, dll) yang memungkinkan program yang bekerja untuk dimunculkan secara cepat.

Prototipe bisa berfungsi sebagai "sistem yang pertama". Brooks setuju bila kita membuangnya. Tetapi mungkin ini merupakan pandangan yang ideal. memang benar bahwa baik pelanggan maupun pengembang menyukaiparadigma prototipe. Para pemakai merasa enak dengan sitem aktual, sedangkan pengembang bisa membangun dengan segera. tetapi prototipe bisa juga menjadi masalah karena alasan sebagai berikut:

1. Pelanggan melihat apa yang tampak sebagai versi software yang bekerja tanpa melihat bahwa prototipe itu dijalin bersama – sama “dengan permen karet dan baling wire”, tanpa melihat bahwa di dalam untuk membuatnya bekerja, kita belum menyantumkan kualitas software secara keseluruhan atau kemampuan pemeliharaan untuk jangka waktu yang panjang. Ketika diberi informasi bahwa produk harus dibangun lagi agar tingkat kualitas yang tinggi bisa dijaga, pelanggan akan meneriakan kecurangan dan permintaan agar dipakai “beberapa campuran” untuk membuat prototipe menjadi sebuah produk yang bekerja yang lebih sering terjadi, sehingga manajemen pengembangan software menjadi penuh dengan belas kasihan.
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 dan dikenal; algoritma yang tidak efisien secara sederhana bisa diimplementasikan untuk mendemonstrasikan kemampuan. Setelah selang waktu tertentu, pengembang mungkin mengenali pilihan – pilihan tersebut dan melupakan semua alasan mengapa mereka tidak cocok. Pilihan yang kurang ideal telah menjadi bagian integral dari sebuah sistem.

Meskipun berbagai masalah bisa terjadi, prototipe bisa menjadi paradigma yang efektif bagi Software Engineering. Kuncinya adalah mendefinisikan aturan main pada saat awal; yaitu pelanggan dan pengembang keduanya harus setuju bahwa prototipe dibangun untuk berfungsi sebagai mekanisme pendefinisian kebutuhan. Prototipe kemudian disingkirkan (paling tidak sebagian), dan software aktual direkayasa dengan tertuju kepada kualitas dan kemampuan pemeliharaan.