A. Analisis Kebutuhan Perangkat Lunak Kebutuhan perangkat lunak adalah kondisi, kriteria, syarat atau kemampuan yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan pemakai. Ada tiga buah jenis kebutuhan perangkat lunak 1) Kebutuhan fungsional (functional requirement) / kebutuhan operasional Merupakan kebutuhan yang berkaitan dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh perangkat lunak. Sebagai contoh:
Perangkat lunak harus dapat menyimpan semua rincian data pesanan pelanggan.
Perangkat lunak harus dapat membuat laporan penjualan sesuai dengan periode waktu tertentu.
Perangkat lunak harus mampu menyajikan informasi jalur pengiriman barang terpendek.
2) Kebutuhan antarmuka (interface requirement) Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak, atau basis data. Sebagai contoh:
Perangkat untuk memasukkan data dapat berupa keyboard, mouse atau scanner.
Akses ke basisdata menggunakan ODBC (Open Database Connectivity).
3) Kebutuhan unjuk kerja (performance requirement) Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh perangkat lunak, misalnya: kecepatan, ketepatan, frekuensi. Sebagai contoh:
Perangkat lunak harus bisa mengolah data sampai 1 juta record untuk tiap transaksi.
Perangkat lunak harus dapat digunakan oleh multiuser sesuai dengan otoritas yang diberikan pada user.
Waktu tanggap penyajian informasi maksimal selama satu menit.
Pendefinisian kebutuhan merupakan aktivitas yang sangat penting, karena sangat mempengaruhi sukses atau gagalnya pelaksanaan pengembangan perangkat
lunak. Menurut hasil survey DeMarco, 56% kegagalan proyek pengembangan perangkat lunak dikarenakan ketidaklengkapan pendefinisian kebutuhan dari perangkat lunak tersebut. Perhatikan gambar dampak kesalahan kumulatif akibat kesalahan dalam pendefinisian kebutuhan pada Gambar 4.1.
Dari gambar terlihat bahwa produk perangkat lunak yang tidak sempurna akan dihasilkan karena kesalahan pada saat menentukan spesifikasi kebutuhan. Jika kesalahan tersebut diketahui di akhir siklus hidup pengembangan, usaha untuk memperbaikinya akan sangat mahal.
Gambar 4.1 Dampak Kesalahan Kumulatif
Selain itu, kesalahan penentuan kebutuhan akan memberikan dampak: 1) Perangkat lunak yang dihasilkan tidak akan memenuhi kebutuhan pemakai yang sebenarnya. 2) Interpretasi kebutuhan yang berbeda-beda sehingga dapat menyebabkan ketidaksepakatan antara pelanggan dan pengembang, menyia-nyiakan waktu dan biaya, dan mungkin akan menghasilkan perkara hukum. 3) Pengujian kesesuaian perangkat lunak dengan kebutuhan yang dimaksud tidak akan mungkin dilaksanakan dengan sesungguhnya. 4) Waktu dan biaya akan terbuang percuma untuk membangun sistem yang salah.
Analisis Kebutuhan
Analisis kebutuhan perangkat lunak (software requirements analysis) merupakan aktivitas awal dari siklus hidup pengembangan perangkat lunak. Untuk proyek-proyek perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah tahap rekayasa sistem/informasi dan software project planning.
Analisis kebutuhan dapat diartikan sebagai berikut : 1) Proses mempelajari kebutuhan pemakai untuk mendapatkan definisi kebutuhan sistem atau perangkat lunak. 2) Proses untuk menetapkan fungsi dan unjuk kerja perangkat lunak, menyatakan antarmuka perangkat lunak dengan elemen-elemen sistem lain, dan menentukan kendala yang harus dihadapi perangkat lunak.
Tujuan pelaksanaan analisis kebutuhan adalah 1) Memahami masalah secara menyeluruh (komprehensif) yang ada pada perangkat lunak yang akan dikembang seperti ruang lingkup produk perangkat lunak(product space) dan pemakai yang akan menggunakannya. 2) Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk memenuhi keinginan pelanggan.
Tahapan Analisis Kebutuhan 1) Mempelajari dan memahami persoalan
Pada tahap ini, seorang analis mempelajari masalah yang ada pada perangkat lunak yang dikembangkan, sehingga dapat ditentukan o siapa pemakai yang menggunakan perangkat lunak. o dimana perangkat lunak akan digunakan . o pekerjaan apa saja dari pemakai yang akan dibantu oleh perangkat lunak. o apa saja cakupan dari pekerjaan tersebut, dan bagaimana mekanisme pelaksanaannya. o apa yang menjadi kendala dilihat dari sisi teknologi yang digunakan atau dari sisi hukum dan standar. Cara yang digunakan oleh pengembang khususnya analis dalam memahami masalah perangkat lunak biasanya dilakukan o wawancara dengan pemakai o observasi atau pengamatan lapangan o kuesioner o mempelajari referensi atau dokumen-dokumen yang digunakan, seperti dokumen hasil analisa dan perancangan perangkat lunak.
Hasil dari pemahaman masalah tersebut dapat digambarkan dengan model-model tertentu sesuai dengan jenis permasalahannya. Sebagai contoh jika masalah bisnis dapat digambarkan dengan flowmap atau bussiness use case untuk analisa berorientasi objek. Sedangkan untuk masalah matematika dapat digambarkan dengan graf.
2) Mengidentifikasi kebutuhan pemakai Pada tahap identifikasi kebutuhan pemakai (user requirement) in pada prakteknya menjadi satu pelaksanaannya dengan pemahaman masalah. Hanya saja substansi yang ditanyakan ada sedikit perbedaan, yaitu o fungsi apa yang diinginkan pada perangkat lunak. o data atau informasi apa saja yang akan diproses. o kelakuan sistem apa yang diharapkan. o antarmuka apa yang tersedia (software interfaces, hardware interfaces, user interfaces, dan communication interfaces)
Untuk menangkap kebutuhan dari pemakai dengan baik,terutama kesamaan persepsi. seorang analis membutuhkan
o komunikasi dan brainstorming yang intensif dengan pelanggan. o pembuatan prototype perangkat lunak atau screenshoot. o Data atau dokumen yang lengkap.
3) Mendefinisikan kebutuhan perangkat lunak Saat melakukan pengidentifikasian kebutuhan pemakai, informasi yang diperoleh masih belum terstruktur. Biasanya pemakai akan mengungkapkan apa yang diinginkan dengan bahasa sehari-hari yang biasa mereka gunakan. Sebagi contoh, ungkapan kebutuhan pemakai dibagian akutansi. o saya ingin data yang dimasukkan oleh bagian penjualan bisa langsung dijurnal. o Informasi neraca keuangan bisa saya lihat kapan saja. Kemudian pada tahap ini, kebutuhan pemakai yang belum terstruktur tersebut akan akan dianalisis, diklasifikasikan, dan diterjemahkan menjadi kebutuhan fungsional, antarmuka dan unjuk kerja perangkat lunak. Sebagai contoh, kebutuhan “data yang dimasukkan oleh bagian penjualan bisa langsung dijurnal” setelah dianalisis, diklasifikasikan dan diterjemahkan, mungki akan menghasilkan pendefinisian kebutuhan sebagai berikut. a. Kebutuhan fungsional
Entri dan rekam data transaksi penjualan.
Retrieve data transaksi penjualan untuk periode tertentu (periode sesuai dengan inputan periode yang diinputkan pada keyboard).
Rekam data akumulasi transaksi penjualan periode tertentu ke jurnal umum berikut account pasangannya (kas).
b. Kebutuhan antarmuka
Antarmuka pemakai untuk memasukkan dan merekam data penjualan.
Antarmuka pemakai untuk menyajikan dan menjurnal informasi transaksi penjualan pada periode tertentu.
Antarmuka untuk jaringan lokal yang menghubungkan perangkat lunak aplikasi dibagian penjualan dengan perangkat lunak aplikasi dibagian akutansi.
c. Kebutuhan unjuk kerja
proses jurnal hanya bisa dilakukan sekali setelah data transaksi penjualan direkam.
Adanya otoritas pemakaian perangkat lunak dan akses data sesuai dengan bagian pekerjaan masing-masing.
Kemudian kebutuhan tersebut akan dimodelkan atau digambarkan dengan teknik analisis dan alat bantu tertentu. Sebagai contoh kebutuhan fungsional dapat dimodelkan dengan menggunakan -
Data flow diagram,kamus data,dan spesifikasi proses jika menggunakan anlisis tertsruktur
-
Use case diagram dan skenario sistem jika menggunkan analisis berorientasi objek. 4) Membuat dokumen spesifikasi kebutuhan perangkat lunak (SKPL)
Semua kebutuhan yang telah didefinisikan selanjutnya dibuat dokumentasinya yaitu Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirement Specification (SRS). Dokumen ini dibuat untuk menyatakan secara lengkap apa yang dapat dilakukan oleh perangkat lunal, termasuk deskripsi lengkap semua antarmuka yang akan digunakan.
5) Mengkaji ulang (review) kebutuhan Proses untuk mengkaji ulang (validasi) kebutuhan apakah SKPL sudah konsisten, lengkap, dan sesuai dengan yang diinginkan oleh pemakai. Proses ini bisa dilakukan lebih dari satu kali. Dan sering kali akan muncul kebuthan-kebutuhan baru dari pemakai. Oleh karena itu, diperlukannya negosiasi antara pengembang dengan pelanggan sesuai dengan prinsip “win win solution” sampai kebutuhan tersebut disetujui oleh kedua belah pihak. Sedangkan menurut Pressman, analisis kebutuhan perangkat lunak dapat dibagi menjadi lima area pekerjaan, yaitu: a) Pengenalan masalah b) Evaluasi dan sistesis c) Pemodelan d) Spesifikasi e) Tinjau ulang (review)
B. Teknik Komunikasi dan Prinsip – Prindip Analisis Komunikasi adalah proses penyampaian suatu pesan oleh seseorang kepada orang lain untuk memberi tahu atau untuk mengubah sikap, pendapat, atau perilaku, baik langsung secara lisan, maupun tak langsung melalui media. Menurut Gause dan Weinberg menyarankan agar analis memulainya dengan mengajukan pertanyaan bebas konteks, dimana pertanyaan tersebut berfokus pada pelanggan, tujuan keseluruhan, dan keuntungan. Rangkaian pertanyaan berikutnya memungkinkan analis mendapatkan pemahaman yang lebih baik mengenai masalah dan pelanggan, untuk menyatakan persepsinya terhadap suatu pemecahan.
Masalah apakah yang akan diselesaikan oleh pemecahan ini?
Dapatkah anda memperlihatkan kepada saya atau menjelaskan lingkungan dimana pemecahan tersebut akan digunakan
Teknik Komunikasi
Mengawali Proses Gause dan Weinberg [GAU89] menyarankan agar analis memulainya dengan mengajukan pertanyaan bebas konteks, dimana pertanyaan tersebut berfokus pada pelanggan, tujuan keseluruhan, dan keuntungan. Teknik Spesifikasi Aplikasi yang Terfasilitasi Adanya teknik pendekatan spesifikasi aplikasi yang teratasi / facilitated aplication spesification techniques (FAST) dapat mendorong munculnya tim gabungan
antara
pengembang
dan
pelanggan
yang
bekerjasama
untuk
mengidentifikasimasalah, mengusulkan elemen pemecahan, menegosiasi pendekatan yang berbeda, dan mengkhususkan rangkaian pemecahan awal [ZAH90].Banyak pendekatan yang berbeda terhadap FAST telah diusulkan. Masing-masing pendekatan menggunakan skenario yang sangat berbeda, tetapi semuanya menerapkan beberapa
variasi tuntutan dasar seperti: Pertemuan dilakukan di sisi netral dan dihadiri baik oleh pengembang maupun pelanggan. Aturan main untuk persiapan dan partisipasi dibuat. Sebuah mekanisme definisi (dapat merupakan sebuah lembar kerja, diagram flip, stiker dinding, atau papan tembok) digunakan. FAST bukanlah obat bagi masalah yang dihadapi dalam pengumpulan awal berbagai persyaratan, tetapi pendekatan tim memberikan keuntungan dari banyak sudut pandang, diskusi sesaat, dan penyaringan, serta merupakan langkah maju konkrit ke arah pengembangan spesifikasi.
Penyebaran Fungsi Kualitas Disebut juga Quality function deployment (QFD) adalah teknik manajemen
kualitas yang menerjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi perangkat lunak. QFD mengidentifikasi 3 persyaratan [ZUL92] yaitu:
Persyaratan normal:
Sasaran dan
tujuan dinyatakan bagi sebuah produk atau sistem selama pertemuan dengan pelanggan.
Bila persyaratan ini ada, maka pelanggan akan menjadi puas. Contoh : tipe tampilan grafis yang diminta, dan tingkat kerja yang didefinisikan. Persyaratan yang diharapkan: Persyaratan ini implisit terhadap produk atau sistem dan sangat fundamental sehingga pelanggan tidak menyatakannya secara eksplisit. Ketidakhadirannya menyebabkan ketidakpuasan. Contoh: Mudahnya instalasi perangkat lunak. Exciting requirment: Persyaratan ini sangat diharapkan oleh pelanggan dan terbukti sangat memuaskan bila ada. Misalnya, perangkat lunak pengolah kata diharapkan dengan fitur standar. Produk yang disampaikan berisi sejumlah kemampuan layout halaman yang sangat menyenangkan dan tidak terduga. Dalam kenyataan, QFD mencakup seluruh proses rekayasa [AKA90]. Tetapi banyak konsep
QFD dapat diaplikasikan ke dalam masalah komunikasi pelanggan yang dihadapi oleh perekayasa perangkat lunak selama tahap awal analisi persyaratan. Prinsip – Prinsip Analisis Masing-masing metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis dihubungkan oleh serangkaian prinsip operasional:
Domain informasi dari suatu masalah harus direpresentasikan dan dipahami.
Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus diwakilkan.
Model-model yang menggambarkan informasi, fungsi, dan tingkah laku harus dipecah-pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan.
Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
Prinsip analisis operasional mengharuskan kita membangun model fungsi dan tingkah laku, yaitu:
Model Fungsional: Perangkat lunak mentransformasi informasi, dan untuk melakukannya, perangkat lunak harus melakukan paling tidak tiga fungsi genetik: input, pemrosesan, dan output. Dengan mengaplikasikan prinsip – prinsip tersebut, analis mendekati suatu
masalah secara sistematis. Domain informasi diuji sehingga fungsi itu dapat di pahami secara lebih lengkap. Model – model digunakan sehingga karakteristik fungsi dan tingkah laku dapat dikomunikasikan dengan cara yang rapi. Pembagian diterapkan untuk mengurangi keruwetan. Pandanagan esensial dan implementasi dari perangkat lunak diperlukan untuk mengakomodasi batasan logis yang dibebankan oleh persyaratan pemrosesan dan batasan fisik yang dibebankan oleh elemen system yang lain. Sebagai tambahan untuk prinsip analisis operasional tersebut, Davis [DAV95a] mengusulkan serangkaian5 prinsip panduan untuk “rekayasa persyaratan”:
Mengembangkan prototype yang memungkinkan seorang pemakai memahami bagaimana interaksi manusia dengan mesin terjadi. Karena persepsi mengenai
kualitas prangkat lunak sering di dasarkan pada persepsi “friendliness” interface, maka prototyping (dan terasi yang dihasilkan) sangatlah dianjurkan.
Merekam asal dan alas an untuk setiap persyaratan. Hal ini merupakan langkah pertama dalam membangun kemampuan penelusuran kembali ke pelanggan.
Menggunakan pandangan persyaratan bertingkat. Pembangunan data, fungsional, dan model tingkah laku member perekayasa perangkat lunak tiga pandangan berbeda. Hal ini mengurangi kemungkinan bahwa inkonsistensi akan diketahui.
Memprioritaskan persyaratan. Batas waktu yang tegas dapat menghalangi implementasi setiap persyaratan perangkat lunak. Bila model proses inkremental (Bab2) diaplikasikan, maka persyaratan yang disampaikan dalam inkremental pertama harus di identifikasi.
Berusaha mengurangi ambiguitas. Karena sebagian besar persyaratan di gambarkan dalam bahasa natural, kemungkinan untuk terjadinya ambiguitas selalu ada. Penggunaan kajian teknis formal merupakan satu – satunya cara untuk mengurangi ambiguitas tersebut. Perekayasa perangkat lunak yang mempercayai prinsip tersebut akan dapat
lebih mengembangkan spesifikasi perangkat lunak yang kemudian akan menjadi dasar yang kuat bagi desain. Domain Informasi Semua aplikasi perangkat lunak secara kolektif dapat disebut data processing. Menarik bahwa istilah itu berisi sebuah kunci ke pemahaman terhadap persyaratan perangkat lunak. Perangkat lunak dibangun untuk memproses data, menstraformasi data dari bentuk yang satu kebentuk yang lain, yaitu untuk menerima input, memanipulasinya dengan berbagai cara, dan menghasilkan output. Pernyataan mendasar dari sasaran ini benar bila kita membangun perangkat lunak batch untuk system daftar gaji atau perangkat lunak real-time embedded untuk mengontrol aliran bahan bakar ke mesin kendaraan bermotor. Tetapi sangat penting untuk dicatat bahwa perangkat lunak juga memproses event. Event mewakili banyak aspek dari control system dan tidak lebih daripada data Boolean – baik on atau off, true or false, there or not there.
Sebagai contoh, sensor tekanan mendeteksi bahwa tekanan melampaui batas nilai aman dan mengirimkan sebuah sinyal alarm ke monitoring perangkat lunak. Sinyal alarm tersebut merupakan suatu event yang mengontrol tingkah laku system. Dengan demikian, data (bilangan, karakter, citra, suara, dll) dan control (kejadian), keduanya ada pada domain informasi dari suatu masalah. Prinsip analisis operasional yang pertama membutuhkan suatu pengujian domain informasi. Domain informasi berisi tiga pandangan yang berbeda dari data dan control ketika masing – masing dip roses oleh program computer : 1) Muatan dan hubungan informasi 2) Aliran informasi, 3) Struktur informasi. C. Pembuatan Model Prototype Perangkat Lunak Dahulu, rancangan fisik merupakan proses yang menggunakan kertas dan pinsil. Seorang analis mengambarkan tata letak atau struktur dari output, input, basis data, dan aliran hubungan dan prosedur. Ini merupakan proses yang memakan waktu yang memiliki kemungkinan terjadinya kesalahan. Biasanya hasil dari rancangan kertas ini adalah tidak lengkap dan tidak akurat. Sekarang, banyak analis dan perancang memilih Prototyping, sebuah pendekatan berbasis rekayasa (engineering) untuk merancang. Pendekatan Prototyping adalah proses iterative yang melibatkan hubunan kerja yang dekat antara perancang dan pengguna. Pressman
(2001)
menyatakan
bahwa
seringkali
seorang
pelanggan
mendefinisikan serangkaian sasaran umum bagi perangkat lunak, tetapi tidak mengidentifikasi kebutuhan input, pemrosesan, ataupun output detail. Pada kasus yang lain, pengembang mungkin tidak memiliki kepastian terhadap efisiensi algoritme, kemapuan penyesuaian dari sistem operasi, atau bentuk-bentuk yang harus dilakukan oleh interaksi manusia dan mesin. Dalam situasi seperti ini salah satu model yang cocok digunakan adalah model prototype (Prototyping paradigm). Model Prototype dapat dilihat pada gambar dibawah ini.
Gambar 1 Prototype Paradigma Pendekatan Prototyping melewati tiga proses, yaitu pengumpulan kebutuhan, perancangan, dan evaluasi Prototype. Proses-proses tersebut dapat dijelaskan sebagai berikut: 1. Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya; 2. Perancangan: perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype; 3. Evaluasi Prototype: klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software. Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi. prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk memahami kebutuhan klien lebih baik. Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa
dimanfaatkan. Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien mendapat gambaran awal dari Prototype. Pendekatan ini memiliki beberapa keuntungan : 1. Pemodelan membutuhkan partisipasi aktif dari end-user. Hal ini akan meningkatkan sikap dan dukungan pengguna untuk pengerjaan proyek. Sikap moral pengguna akan meningkat karena system berhubungan nyata dengan mereka. 2. Perubahan dan iterasi merupakan konsekuensi alami dari pengembangan system-sehingga end user memiliki keinginan untuk merubah pola pikirnya. Prototyping
lebih
baik
menempatkan
situasi
alamiah
ini
karena
mengasumsikan perubahan model melalui iterasi kedalam system yang dibutuhkan. 3. Prototyping mematahkan folosofi “end user tidak mengetahui secara detail apa yang dibutuhkan sampai mereka melihat implementasinya” 4. Prototyping adalah model aktif, tidak pasif, sehingga end user dapat melihat, merasakan, dan mengalaminya. 5. Kesalahan yang terjadi dalam prototyping dapat dideteksi lebih dini 6. Prototyping dapat meningkatkan kreatifitas karena membolehkan adanya feedback dari end user. Hal ini akan memberikan solusi yang lebih baik. 7. Prototyping mempercepat beberapa fase hidup dari programmer. McLeod dan Schell (2001) mengemukakan bahwa alasan-alasan pemakai maupun spesialis informasi menyukai model prototype adalah: 1. Komunikasi antara analis sistem dan pemakai membaik; 2. Analis dapat bekerja dengan lebih baik dalam menemukan kebutuhan pemakai; 3. Pemakai berperan lebih aktif dalam pengembangan sistem; 4. Spesialis informasi dan pemakai menghabiskan lebih sedikit waktu dan usaha dalam mengembangkan sistem; 5. Implementasi menjadi lebih mudah karena pemakai mengetahui sistem yang diharapkan. Tetapi, terdapat beberapa kelemahan dari prototyping, kelemahan tersebut antara lain :
1. Prototyping
memungkinkan
terjadinya
pengembalian
terhadap
kode,
implementasi, dan perbaikan siklus hidup yang dugunakan untuk mendominasi sistem informasi. 2. Prototyping tidak menolak kebutuhan dari fase analisis sistem. Prototype hanya dapat memecahkan masalah yang salah dan memberi kesempatan sebagai sistem pengembangan konvensional. 3. Perancangan issu numerik tidak dialamaykan oleh prototyping. Isu tersebut dapat dilupakan jika pengguna tidak berhati-hati. 4. Prototyping dapat mengurangi kreatifitas perancangan. Prototyping terkadang dapat memberikan performansi yang lambat, membantu mendapatkan kebutuhan detil lebih baik namun demikian Prototype juga menimbulkan masalah: 1. Dalam membuat prototype banyak hal yang diabaikan seperti efisiensi, kualitas,
kemudahan
dipelihara/dikembangkan,
dan
kecocokan
dengan
lingkungan yang sebenarnya. Jika klien merasa cocok dengan prototype yang disajikan dan berkeras terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya. 2. Developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana. 3. Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.
