MAKALAH

ANALISIS KEBUTUHAN PERANGKAT LUNAK

NAMA : RANI JUITA

NIM : 41813120165
DOSEN : WACHYU HARI HAJI. S.Kom.MM

JURUSAN SISTEM INFORMASI

FAKULTAS ILMU KOMPUTER
UNIVERSITAS MERCU BUANA
JAKARTA
2015
 ANALISIS KEBUTUHAN PERANGKAT LUNAK
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 aktivitas sistem
information engineering dan software project planning. Tahap analisis adalah tahapan
pengumpulan kebutuhan-kebutuhan dari semua elemen sistem perangkat lunak yang akan di
bangun. Pada tahap ini dibentuk spesifikasi kebutuhan perangkat lunak, fungsi perangkat lunak
yang dibutuhkan, performansi (unjuk kerja) sistem perangkat lunak, penjadwalan proyek,
identifikasi sumber daya (manusia, perangkat keras dan perangkat lunak yang dibutuhkan) dan
taksiran biaya pengembangan perangkat lunak. Kegunaan analisis adalah untuk memodelkan
permasalahan dunia nyata agar dapat dimengerti. Permasalahan dunia nyata harus dimengerti
dan dipelajari supaya spesifikasi kebutuhan perangkat lunak dapat diungkapkan. Tujuan
aktivitas ini adalah untuk mengetahui ruang lingkup produk (product space) dan pemakai yang
akan menggunakannya. Analisis yang baik akan mengungkapkan hal-hal yang penting dari
permasalahan, dan mengabaikan yang tidak penting.
Setiap metode analisis mempunyai pandangan yang berbeda. Tetapi pada dasarnya semua
metode analisis memiliki prinsip analisis yang sama, yaitu :
1. Menggambarkan domain informasi masalah
2. Mendefinisikan fungsi perangkat lunak
3. Menghasilkan model yang menggambarkan informasi, fungsi dan kelakuan yang dibagi
secara rinci pada sebuah model lapisan (hirarki)
4. Informasi pokok pada tahap analisis memudahkan tahap implementasi yang lebih rinci.
Tujuan tahap analisis adalah :
1. Menjabarkan kebutuhan pemakai
2. Meletakkan dasar-dasar untuk tahap perancangan perangkat lunak
3. Mendefinisikan semua kebutuhan pemakai sesuai dengan lingkup kontrak yang disepakati
kedua belah pihak (pengembang dan pengguna).

A. KEBUTUHAN (REQUIREMENT)
Pengertian Kebutuhan Menurut arti kamus, kebutuhan adalah sesuatu yang diminta, sesuatu
yang dibutuhkan. Sedangkan menurut IEEE (The Institute of Electrical and Electronics
Engineers) kebutuhan adalah :
 Kondisi atau kemampuan yang diperlukan pemakai untuk menyelesaikan suatu
persoalan, atau untuk mencapai sebuah objek.
 Kondisi atau kemampuan yang harus dipenuhi oleh sistem, dalam arti memenuhi
kontrak, standar, spesifikasi atau dokumen formal lain yang diinginkan.
Tahap kebutuhan akan perangkat lunak dimulai dengan:
1. Dikenalinya adanya sebuah permasalahan yang membutuhkan sebuah penyelesaian.
Identifikasi sebuah permasalahan mungkin dapat dilakukan dengan berorientasi pada
aplikasi, berorientasi pada bisnis, atau berorientasi pada kenaikan produktivitas
(product improvement oriented).
 2. Munculnya ide untuk membuat sebuah perangkat lunak baru (sebagai sebuah
kemajuan).

Ada dua jenis kebutuhan:

1). Behavioral
Adalah apa yang dilakukan oleh sistem (input dan output dari dan ke sistem), hubungan
informasi antara input dan output sehingga menghasilkan sebuah fungsi transformasi.
2). Non-behavioral
Mendefinisikan atribut sistem yang terkait untuk membentuk pekerjaan tersebut.
Termasuk deskripsi lengkap tentang efisiensi, keamanan (security), rehability
maintenability (bagaimana perawatan untuk sistem), dan portability (bisa dipindahkan
dari satu perangkat keras ke perangkat keras lainnya).

B. PRINSIP – PRINSIP ANALISIS

Lebih dari dua decade terakhir, para peneliti mengidentifikasi masalah – masalah
analisis dan penyebab – penyebabnya, serta mengembangkan berbagai notasi pemodelan
dan serangkaian penelitian yang sesuai untuk menanggulanginya. Masing – masing metode
analisis memiliki titik pandang yang unik. Tetapi semua metode analisis dihubungkan oleh
serangkaian prinsip operasional:
 Dominan informasi dari suatu masalah harus direpresentasikan dan dipahami.
 Fungsi – fungsi yang akan dilakukan oleh perangkat lunak harus di definisikan.
 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 (atau
hirarki).
 Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
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 serangkaian 5 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.
1. Merekam asal dan alas an untuk setiap persyaratan. Hal ini merupakan langkah pertama
dalam membangun kemampuan penelusuran kembali ke pelanggan.
2. 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.
3. 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.
4. 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.
5. Perekayasa perangkat lunak yang mempercayai prinsip tersebut akan dapat lebih
mengembangkan spesifikasi perangkat lunak yang kemudian akan menjadi dasar yang
kuat bagi desain.

1. 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:
a. Muatan dan hubungan informasi
b. Aliran informasi
c. Struktur informasi
Untuk benar – benar memahami domain informasi, masing – masing dari pandangan
tersebut harus diperhatikan. Muatan Informasi mewakili data dan objek control
individual yang terdiri dari beberapa kumpulan informasi yang lebih besar yang di
transformasikan oleh perangkat lunak. Misalnya, objek data paycheck merupakan
sebuah gabungan dari sejumlah data yang penting : nama pembayar, jumlah bersih yang
dibayarkan, pembayaran keseluruhan, potongan, dan seterusnya. Demikianlah, muatan
dari paycheck ditentukan oleh atribut – atribut yang dibutuhkan untuk membuatnya.
Dengan cara yang sama, muatan dari suatu objek control yang disebut status system
dapat dibatasi oleh sebuah string dari banyak bit. Masing – masing bit mewakili jenis
 informasi yang berbeda yang menunjukkan apakah perangkat tertentu itu on-line atau
off-line.
Objek data dan control dapat dihubungkan dengan objek data dan control lainnya.
Sebagai contoh, objek data paycheck memiliki satu hubungan atau lebih dengan objek
timecard, employee, bank dan lain – lain. Selama analisis domain informasi, hubungan
– hubungan itu harus ditetapkan.
Aliran informasi mewakili cara dimana data dan kontrol berubah pada saat masing –
masing bergerak melalui sebuah system. Spereti diperlihatkan pada Gambar 11.3, objek
input ditransformasikan ke informasi intermediate ( data dan atau control), dan lebih
jauh lagi ditransformasikan ke output. Sepanjang jalur transformasi tersebut, informasi
tambahan dapat dimunculkan dari penyimpanan data yang ada (seperti, file disket atau
memory buffer). Transformasi yang diaplikasikan merupakan fungsi atau subfungsi
yang harus dilakukan oleh sebuah program. Data dan control yang bergerak diantara
dua (fungsi) transformasi menentukan interface dari masing” fungsi.
Struktur informasi mewakili organisasi internal dari berbagai jenis data dan control.
Apakah jenis data akan diorganisasi sebagai sebuah table n-dimensi atau sebagai sebuah
struktur pohon hirarki? Dalam konteks struktur, informasi apa yang dihubungkan
dengan informasi lain? Apakah semua informasi di isikan ke dalam sebuah struktur
tunggal atau akan digunakan struktur yang berbeda? Bagaimana informasi dalam suatu
struktur informasi berhubungan dengan informasi pada struktur yang lain? Pertanyaan
– pertanyaan tersebut dijawab dengan suatu penilaian struktur informasi. Harus dicatat
juga bahwa struktur data, konsep yang berhubungan yang akan di diskusikan pada buku
ini, mengacu pada perancangan dan implementasi informasi.

2. Pemodelan
Kita menciptakan model untuk memperoleh pemahaman yang lebih baik mengenai
entitas actual yang akan dibangun. Bila entitas tersebut berupa sebuah bentuk fisik
(bangunan, pesawat, mesin), kita dapat membangun model yang identik dalam bentuk
dan potongan, tetapi dalam skala yang lebih kecil. Tetapi bila entitas yang akan
dibangun adalah perangkat lunak, maka model harus memakai bentuk yang berbeda.
Model harus dapat memodelkan informasi yang di transformasikan oleh perangkat
lunak, fungsi (dan subfungsi) yang memungkinkan transformasi terjadi, dan tingkah
laku system pada saat transformasi terjadi.
Selama analisis persyaratan perangkat lunak, kita menciptakan model system yang akan
dibuat. Model tersebut berfokus pada apa yang harus dilakukan oleh system, bukan
pada bagaimana system melakukannya. Dalam beberapa kasus, model yang kita buat
menggunakan notasi grafis yang menggambarkan informasi, pemrosesan, tingkah laku
system, dan karakteristik lain sebagai symbol yang berbeda dan dapat dikenali. Bagian
lain dari model dapat benar – benar tekstual. Informasi deskriptif dapat diberikan
dengan menggunakan bahasa natural atau bahasa khusus untuk menggambarkan
persyaratannya.
Prinsip analisis operasional kedua dan ketiga mengharuskan kita membangun model
fungsi dan tingkah laku :
 1. Model fungsional.
Perangkat lunak mentransformasi informasi, dan untuk melakukannya, perangkat
lunak harus melakukan paling tidak tiga fungsi genetic: input, pemrosesan, dan
output. Pada saat model fungsional dari suatu aplikasi dibuat, perekayasa perangkat
lunak memfokuskan dri pada fungsi – fungsi masalah khusus. Model fungsi dimulai
dengan sebuah model tingkat konteks tunggal (yakni nama perangkat lunak yang
akan dibuat). Dengan serangkaian iterasi , maka lebih banyak lagi detail fungsional
diberikan, smapai seluruh rancangan dari semua fungsionalitas system terwakili.
2. Model tingkah laku.
Sebagian besar perangkat lunak merespon kejadian – kejadian dari dunia luar.
Karakteristik stimulus-respon ini membentuk dasar dari model tingkah laku.
Program computer selalu ada dalam pernyataan – suatu mode tingkah laku yang
dapat di obeservasi secara eksternal (misalnya, penungguan, penghitungan,
pencetakan, polling) yang diubah hanya pada saat beberapa event berlangsung.
Contohnya, perangkat lunak akan tetap berada dalam wait state sampai (1) jam
internal menunjukkan bahwa beberapa interval waktu telah berlalu, (2) satu event
eksternal (misalnya, pergerakan mouse) menyebabkan suatu interupsi, atau (3)
sebuah system eksternal member sinyal kepada perangkat lunak agar bergerak
dengan beberapa cara. Model tingkah laku menciptakan representasi pernyataan –
pernyataan perangkat lunak dan event – event yang menyebabkan perangkat lunak
mengubah pernyataan.
Model yang diciptakan selama analisis persyaratan melayani sejumlah peran penting :
 Model membantu analisis dalam memahami informasi, fungsi, dan tingkah laku
suatu system, sehingga membuat tugas analisis persyaratan menjadi lebih mudah
dan lebih sistematis.
 Model menjadi titik focus bagi kajian sehingga merupakan kunci bagi penetuan
kelengkapan, konsistensi, dan akurasi dari spesifikasi.
 Model menjadi dasar bagi pengerjaan desain, member perancang suatu representasi
esensial dari perrangkat lunak yang dapat diterjemahkan ke dalam suatu konteks
implementasi.

3. Pembagian
Masalah sering menjadi terlalu luas atau terlalu rumit untuk dipahami sebagai salah
satu kesatuan. Karena itulah kita cenderung membagi masalah seperti itu ke dalam
bagian – bagian sehingga dapat dipahami dengan mudah dan kemudian membangun
interface antara bagian – bagian tersebut, sehingga keseluruhan fungsi dapat dilakukan.
Prinsip analisis operasional keempat menyatakan bahwa domain informasi, fungsional,
dan tingkah laku perangkat lunak tidak dapat dibagi – bagi. Secara konseptual, kita
membangun sebuah representasi hirarki dari informasi atau fungsi dan kemudian
membagi elemen bagian paling atas (1). mengekpos detail pertambahan dengan
bergerak secara vertical dalam hirarki (2). Mendekomposisi masalah dengan bergerak
secara horizontal dalam hirarki.
Persyaratan untuk perangkat lunak Safe Home dapat dianalisis dengan pembagian
domain informasi, fungsional, dan tingkah laku produk. Untuk mengilustrasikannya,
domain fungsional dari masalah tersebut akan di bagi – bagi.
 Pendekatan pembagian yang telah di aplikasikan pada fungsi – fungsi Safe-home juga
dapat di aplikasikan padadomain informasi dan kelakuan system akan memberikan
wawasan tambahan ke dalam persyaratan system. Pada saat masalah di bagi – bagi,
interface di antara system – system ditarik. Data dan control yang bergerak melewati
suatu interface harus dibatasi untuk input yang diperlukan untuk melakukan fungsi
yang dinyatakan dan outputyang diperlukan oleh elemen fungsi atau system yang lain.
4. Pandangan Esensial dan Implementasi
Pandangan esensial persyaratan perangkat lunak menyajikan fungsi yang akan
dikerjakan dan informasi yang akan diproses tanpa melihat detail implementasinya.
Sebagai contoh, pandangan esensial dari fungsi Safe Home read sensor status tidak
tergantung pada bentuk fisik dari data atau tipe sensor yang digunakan. Pada dasarnya,
dapat diperdebatkan bahwa read status akan menjadi nama yang lebih sesuai bagi fungsi
tsb, karena fungsi itu tidak mengabaikan detail mekanisme input keseluruhan. Dengan
cara yang sama, sebuah model data esensial dari item data phone number
(diimplikasikan oleh fungsi dial phone number) dpt di representasikan pada tahap ini
tanpa menghiraukan struktur data yang utama (bila ada) yang digunakan untuk
mengimplementasi item data.
Pandangan implementasi dari persyaratan menyajikan manifestasi dunia nyata dari
pemrosesan fungsi – fungsi dan struktur informasi. Perangkat input Safe Home
merupakan sebuah sensor perimeter. Sensor tsb mendeteksi masukan ilegal dengan
“mengendus” adanya break dalam sebuah rangkaian listrik. Analisis harus mengenali
batasan yang dikenakan oleh elemen system yang diberlakukan oleh elemen (sensor)
system sebelumnya dan mempertimbangkan pandangan implementasi fungsi dan
informasi bila pandangan semacam itu sesuai.

C. PROTOTYPING PERANGKAT LUNAK

Analisis harus dilakukan tanpa mengabaikan pardigma rekayasa perangkat lunak yang
di aplikasikan; tetapi bentuk yang di ambil oleh analisis akan bermacam – macam. Dalam
situasi yang lain, dilakukan pengumpulan persyaratan (melalui FAST, QFD, atau teknik
“cuci otak” yang lain [JOR89], pengaplikasian prinsip analisis, dan penyusunan model
perangkat lunak yang akan di bangun yang disebut prototype, untuk penilaian pelanggan
dan pengembang.
1. Pemilihan Pendekatan Prototyping
Paradigma protyping dapat terbatas atau tidak terbatas. Pendekatan terbatas sering
disebut throwaway prototyping. Dengan menggunakan pendekatan tsb, prototype
melulu sebagai sebuah demonstrasi kasar dari persyaratan. Pendekatan tidak terbatas,
yang disebut juga evolutionary prototyping, menggunakan prototype sebagai bagian
pertama dari aktivitas analisis yang akan diteruskan kedalam desain dan kontruksi.
Prototipe perangkat lunak merupakan evolusi pertama dari system yang diselesaikan.
Secara umum, sembarang aplikasi yang menciptakan tampilan visual yang dinamis,
berinteraksi erat dengan pemakai manusia, atau membutuhkan algoritma atau
pemrosesan kombinatorial yang harus dikembangkan dalam sebuah gaya evolusioner,
adalah calon untuk prototyping
 2. Metode dan peranti prototyping
Supaya prototyping perangkat lunak efektif, maka harus dikembangkan suatu prototype
dengan cepat sehingga pelanggan dapat menilai hasil dan perubahan yang di
rekomendasi. Untuk melakukan prototyping secara cepat, ada tiga kelas metode dan
peranti generic: teknik generasi keempat, komponen perangkat lunak reusable,
spesifikasi formal, dan lingkungan prototyping.
Teknik Generasi Keempat (4GT). Teknik generasi keempat meliputi suatu array yang
luas dari query database dan bahasa pelaporan, program dan generator aplikasi, serta
bahasa nonprocedural. Karena 4GT memungkinkan perekayasa perangkat lunak
memunculkan kode yang dapat dieksekusi dengan cepat, maka 4GT ideal untuk
prototyping yang cepat. Komponen Perangkat Lunak Reusable. Pendektan lain ke rapid
prototyping adalah dengan memasang, bukan membangun, prototype dengan
menggunakan serangkaian komponen perangkat lunak yangada.Pada setiap kasus,
komponen perangkat lunak harus dirancang dengan cara terntentu sehingga
memungkinkannya untuk dipakai kembali tanpa harus mempunyai pengetahuan yang
mendetail mengenai kerja internalnya. Perlu di catat bahwa sebuah produk perangkat
lunak yabg ada dapat digunakan sebagai sebuah prototype bagi produk kompetitif yang
“baru dan telah dikembangkan”. Dengan cara tertentu, hal tsb merupakan suatu bentuk
dari reusabilitas untuk prototyping perangkat lunak.
Lingkungan Prototyping dan Spesifikasi Formal. Selama dua decade terakhir, sejumlah
bahasa spesifikasi formal dan peranti telah dikembangkan sebagai pengganti bagi
teknik spesifikasi bahasa natural. Sekarang pengembang bahasa formal itu berada
dalam proses pengembangan lingkungan interaktif yang (1) memungkinkan seorang
analisis untuk secara interaktif menciptakan spesifikasi system atau perangkat lunak
yang berdasarkan pada bahasa, (2) memanggil peranti otomatis yang menerjemahkan
spesifikasi berdasarkan bahasa kedalam kode yang dapat di eksekusi, dan (3)
memungkinkan pelanggan untuk menggunakan kode prototype yang dapat di eksekusi
untuk menyaring persyaratan – persyaratan formal.
Dalam pembuatan software, dikenal beberapa metode untuk membuat software yang
dibutuhkan untuk memenuhi kebutuhan user yang memerlukan software tersebut. Pada
kesempatan kali ini, saya akan membahas salah satu metode pembuatan software yang dimana
baru-baru ini saya dan kelompok saya bahas dikampus untuk menyelesaikan tugas mata kuliah
rekayasa perangkat lunak yaitu model prototype(Prototyping Model)
Sebelum memasuki lebih mendalam mengenai pembuatan software menggunakan metode
prototype, kita harus terlebih dahulu mengetahui apa yang dimaksud dengan prototype itu
sendiri. Prototype adalah model atau simulasi dari semua aspek produk sesungguhnya yang
akan dikembangkan yang dimana model tersebut harus representative dari produk akhirnya.
Setelah mengetahui arti prototype mungkin masih menganjal dibenak kita bagaimana sih
software itu terbentuk menggunakan metode prototype? Apakah model prototype lebih bagus
digunakan daripada model lain? Apakah resiko-resiko dari penggunaan model tersebut? Dan
mungkin masih banyak pertanyaan lain yang akan muncul. Oleh sebab itu, pada postingan kali
ini saya sendiri akan menjelaskan lebih lanjut mengenai pembuatan software dengan
menggunakan metode prototype tersebut.
 Model Prototype
Menurut saya sendiri prototyping model adalah suatu proses pembuatan software yang
yang bersifat berulang dan dengan perencanaan yang cepat yang dimana terdapat umpan
balik yang memungkinkan terjadinya perulangan dan perbaikan software sampai dengan
software tersebut memenuhi kebutuhan dari si pengguna. Sedangkan dari beberapa
referensi yang saya temukan, prototyping model adalah salah satu model sederhana
pembuatan software yang dimana mengijinkan pengguna memiliki suatu gambaran
awal/dasar tentang program serta melakukan oengujian awal yang didasarkan pada konsep
model kerja(working model).
 Tujuan Prototype
Prototyping model sendiri mempunyai tujuan yaitu mengembangkan model awal software
menjadi sebuah sistem yang final.
 Proses-prosesnya
Proses-proses dalam model prototyping yaitu:
 Komunikasi terlebih dahulu yang dilakukan antara pelanggan dengan tim pemgembang
perangkat lunak mengenai spesifikasi kebutuhan yang diinginkan
 Akan dilakukan perencanaan dan pemodelan secara cepat berupa rancangan
cepat(quick design) dan kemudian akan memulai konstruksi pembuatan prototype
 Prototipe kemudian akan diserahkan kepada para stakeholder untuk dilakukan evaluasi
lebih lanjut sebelum diserahkan kepada para pembuat software
 Pembuatan software sesuai dengan prototype yang telah dievaluasi yang kemudian
akan diserahkan kepada pelanggan
 Jika belum memenuhi kebutuhan dari pelanggan maka akan kembali ke proses awal
sampai dengan kebutuhan dari pelanggan telah terpenuhi
Sedangkan proses-proses dalam model prototyping secara umum adalah sebagai berikut:
1. Pengumpulan kebutuhan
developer dan klien akan bertemu terlebih dahulu dan kemudian menentukan tujuan umum,
kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya
2. Perancangan
perancangan dilakukan dengan cepat dan rancangan tersebut mewakili semua aspek software
yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype
3. Evaluasi Prototype
klien akan mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan
software.
 Tahapan-tahapannya
Selain itu, untuk memodelkan sebuah perangkat lunak dibutuhkan beberapa tahapan di
dalam proses pengembangannya. Tahapan inilah yang akan menentukan keberhasilan dari
sebuah softwareitu .Pengembang perangkat lunak harus memperhatikan tahapan dalam
metode prototyping agar software finalnya dapat diterima oleh penggunanya. Dan tahapan-
tahapan dalam prototyping tersebut adalah sebagai berikut :
1. Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format dan kebutuhan
kesseluruhan perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar
sistem yang akan dibuat.
2. Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang berpusat pada
penyajian kepada pelanggan (misalnya dengan membuat input dan contoh outputnya).
3. Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah
sesuai dengan keinginan pelanggan. Jika sudah sesuai maka langkah keempat akan diambil.
Jika tidak, maka prototyping diperbaiki dengan mengulang langkah 1, 2 , dan 3.
4. Mengkodekan system
Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke dalam bahasa
pemrograman yang sesuai.
5. Menguji system
Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu
sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path,
pengujian arsitektur dan lain-lain.
6. Evaluasi Sistem
Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang
diharapkan . Jika sudah, maka langkah ketujuh dilakukan, jika belum maka mengulangi
langkah 4 dan 5.
7. Menggunakan system
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan
 Keunggulan dan kelemahan metode prototype
Keunggulan prototyping :
1. Komunikasi akan terjalin baik antara pengembang dan pelanggan.
2. Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan setiap
pelanggannya.
3. Pelanggan berperan aktif dalam proses pengembangan sistem.
4. Lebih menghemat waktu dalam pengembangan sistem.
5. Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya

Kelemahan prototyping :
1. Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum
mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan
kemampuan pemeliharaan untuk jangka waktu lama.
2. Pengembang biasanya ingin cepat menyelesaikan proyek sehingga menggunakan
algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih
cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan
sebuah kerangka kerja(blueprint) dari sistem .
3. Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan
teknik perancangan yang baik dan benar.
Dalam setiap metode mempunyai kelebihan maupun kekurangan, namun kekurangan
tersebut dapat diminimalisir yaitu dengan mengetahui kunci dari model prototype tersebut.
Kunci agar model prototype ini berhasil dengan baik adalah dengan mendefinisikan aturan-
aturan main pada saat awal, yaitu pelanggan dan pengembang harus setuju bahwa prototype
dibangun untuk mendefinisikan kebutuhan.