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