Seringkali, pelanggan mendefinisikan seperangkat tujuan umum untuk perangkat lunak tetapi tidak mengidentifikasi input, pemrosesan, atau persyaratan output yang terperinci. Dalam kasus lain, pengembang mungkin tidak yakin dengan efisiensi algoritme, kemampuan beradaptasi sistem operasi, atau bentuk interaksi manusia/mesin. Dalam situasi ini, dan banyak situasi lainnya, paradigma prototyping mungkin menawarkan pendekatan terbaik. Paradigma prototyping (Gambar 2.5) dimulai dengan pengumpulan kebutuhan. Pengembang dan pelanggan bertemu dan
menentukan tujuan keseluruhan untuk perangkat lunak, mengidentifikasi persyaratan apa pun yang diketahui, dan menguraikan area di mana definisi lebih lanjut adalah wajib. Sebuah "desain cepat"
kemudian terjadi. Desain cepat berfokus pada representasi dari aspek-aspek perangkat lunak yang akan terlihat oleh pelanggan/pengguna (misalnya, pendekatan input dan format output). Desain cepat mengarah pada pembangunan prototipe. Prototipe dievaluasi oleh pelanggan/pengguna dan digunakan untuk menyempurnakan persyaratan perangkat lunak yang akan dikembangkan. Iterasi terjadi ketika prototipe disetel untuk memenuhi kebutuhan pelanggan, sementara pada saat yang sama memungkinkan pengembang untuk lebih memahami apa yang perlu dilakukan.
Idealnya, prototipe berfungsi sebagai mekanisme untuk mengidentifikasi kebutuhan perangkat lunak. Jika prototipe kerja dibangun, pengembang mencoba menggunakan fragmen program yang ada atau menerapkan alat (misalnya, pembuat laporan, manajer jendela) yang memungkinkan program kerja dihasilkan dengan cepat
. dijelaskan? Brooks [BRO75] memberikan jawaban:
Di sebagian besar proyek, sistem pertama yang dibangun hampir tidak dapat digunakan.
Mungkin terlalu lambat, terlalu besar, canggung saat digunakan atau ketiganya. Tidak ada alternatif selain memulai lagi, cerdas tetapi lebih cerdas, dan membangun versi yang didesain ulang di mana masalah ini diselesaikan. . . Ketika konsep sistem baru atau teknologi baru digunakan, seseorang harus membangun sistem untuk dibuang, karena bahkan perencanaan terbaik pun tidak begitu tahu untuk melakukannya dengan benar pertama kali. Oleh karena itu, pertanyaan manajemen bukanlah apakah akan membangun sistem percontohan dan membuangnya. Anda akan melakukan itu. Satu- satunya pertanyaan adalah apakah akan merencanakan terlebih dahulu untuk membangun tempat pembuangan sampah, atau berjanji untuk mengirimkan barang sekali pakai kepada pelanggan . . .
Prototipe dapat berfungsi sebagai "sistem pertama." Yang Brooks rekomendasikan untuk kita buang. Tapi ini mungkin pandangan yang ideal. Memang benar bahwa baik pelanggan dan pengembang menyukai paradigma prototyping. Pengguna dapat merasakan sistem yang
sebenarnya dan pengembang dapat segera membangun sesuatu. Namun, pembuatan prototipe juga dapat menjadi masalah karena alasan berikut
1. Pelanggan melihat apa yang tampak sebagai versi perangkat lunak yang berfungsi, tidak menyadari bahwa prototipe disatukan "dengan permen karet dan kawat baling", tidak menyadari bahwa terburu-buru untuk mendapatkan itu berfungsi, tidak ada yang mempertimbangkan kualitas perangkat lunak secara keseluruhan atau pemeliharaan jangka panjang. Ketika diberitahu bahwa produk harus dibangun kembali sehingga tingkat kualitas yang tinggi dapat dipertahankan, pelanggan menangis dan menuntut agar "beberapa perbaikan" diterapkan untuk membuat prototipe produk yang berfungsi. Terlalu sering, manajemen pengembangan perangkat lunak mengalah.
2. Pengembang sering membuat kompromi implementasi agar prototipe dapat bekerja dengan cepat. Sistem operasi atau bahasa pemrograman yang tidak tepat dapat digunakan hanya
karena tersedia dan diketahui; algoritma yang tidak efisien dapat diimplementasikan hanya untuk menunjukkan kemampuan. Setelah beberapa waktu, pengembang mungkin terbiasa dengan pilihan ini dan melupakan semua alasan mengapa pilihan itu tidak pantas. Pilihan yang kurang ideal kini telah menjadi bagian integral dari sistem.
Meskipun masalah dapat terjadi, prototyping dapat menjadi paradigma yang efektif untuk rekayasa perangkat lunak. Kuncinya adalah menentukan aturan main di awal; yaitu, pelanggan
dan
pengembang keduanya harus setuju bahwa prototipe dibangun untuk melayani sebagai mekanisme untuk mendefinisikan persyaratan. Itu kemudian dibuang (setidaknya sebagian) dan perangkat lunak yang sebenarnya direkayasa dengan memperhatikan kualitas dan pemeliharaan
