BAB I

PENDAHULUAN

1.1 Latar Belakang

Proses Perangkat Lunak merupakan Sekumpulan aktifitas yang memiliki

tujuan untuk pengembangan ataupun evolusi perangkat lunak. Aktifitas generic dalam
semua proses perangkat lunak adalah:

Spesifikasi – apa yang harus dimiliki oleh perangkat lunak tersebut dan
batasan/kendala pengembangannya
Pengembangan– proses memproduksi sistem perangkat lunak
Validasi – pengujian perangkat lunak terhadap keinginan penggunak
Evolusi – perubahan perangkat lunak berdasarkan perubahan keinginan.

Model Proses Perangkat Lunak merupakan suatu representasi proses

perangkat lunak yang disederhanakan, dipresentasikan dan perspektif secara khusus.

Fungsi utama model proses pengembangan perangkat lunak :

• menentukan tahap-tahap yang diperlukan untuk pengembangan perangkat

lunak.
• menentukan urutan pelaksanaan dari tahap-tahap tersebut dalam rangka
pengembangan perangkat lunak.
• menentukan kriteria transisi/perpindahan dari satu tahap ke tahap
berikutnya.

Terdapat banyak model proses perangkat lunak antara lain:

Menurut Ian Sommerville:

1. Model Pengembangan Waterfall
2. Model Pengembangan Prototyping (Evolusioner)
3. Model Pengembanagan formal
4. Model Pengembangan perakitan komponen-komponen guna ulang

Menurut Roger S.Pressman:

1. Linier sequential model
2. Prototyping model
3. Rapid Aplication development (RAD) model
4. Evolutionary software process model terdiri dari:
a. Increment Model
b. Spiral model
c. WINWIN Spiral Model
d. Conccurent development model
5. Component based development
 6. Formal method model
7. 4th Generation technique paradigm
Selain Model proses diatas masih banyak proses model lainnya, Model proses muncul
dikarenakan :
1. Kompleksitas masalah semakin besar
2. Melibatkan tim dalam pengembangan software sehingga membutuhkan abstraksi.
3. Memelihara pengembangan sehingga membutuhkan standarisasi.

Dalam kesempatan kali ini kami ingin membahas tentang dua model proses
perangkat lunak yakni ’model proses Model Proses Extreme Programming dan
Prototyping Model’.

1.2 Perumusan masalah

Di dalam makalah ini kami akan menjelaskan dua buah model proses perangkat
lunak yakni model proses Model Proses Extreme Programming dan Prototyping Model
mulai dari latar belakang terbentuknya model proses tersebut, metode-metode yang
digunakan dalam model proses, hingga kelemahan dan kekurangannya.

Disamping itu, kami juga akan membandingkan software model tersebut dari segi
kehandalan, kelemahan dan kekurangannya.

1.3 Tujuan dan manfaat

Makalah ini bermanfaat untuk menambah pemahaman tentang model proses

perangkat lunak, khususnya model proses Model Proses Extreme Programming dan
Prototyping Model. Adapun tujuan makalah ini adalah untuk membandingkan kedua
Proses model tersebut.
 BAB II

EXTREME PROGRAMMING

2.1 PENGERTIAN EXTREME PROGRAMMING

Extreme Programming merupakan salah satu metodologi dalam rekayasa

perangkat lunak dan juga merupakan satu dari beberapa agile software development
methodologies yang berfokus pada coding sebagai aktivitas utama di semua tahap pada
siklus pengembangan perangkat lunak (software development lifecycle). Metodologi ini
mengedepankan proses pengembangan yang lebih responsive terhadap kebutuhan
customer (”agile”) dibandingkan dengan metode-metode tradisional sambil membangun
suatu software dengan kualitas yang lebih baik.

Extreme Programming muncul menawarkan sebuah disiplin baru dalam

pengembangan software secara agile. Nilai dasar yang terkandung di dalam Extreme
Programming adalah: Komunikasi (Communication), Kesederhanaan (Simplicity),
Umpan balik (Feedback) Keberanian (Courage) dan menghormati (Respect).

2.2 SEJARAH EXTREME PROGRAMMING

Proyek pengembangan perangkat lunak yang dianggap sebagai yang pertama kali
menerapkan XP adalah C3 (Chrysler Comprehensive Compensation) Project dari
Chrysler. Proyek ini adalah proyek penggajian 10.000 karyawan Chrysler, terdiri dari
kira-kira 2000 class dan 30.000 method. Proyek yang dimulai pertengahan dekade 90-an
ini terancam gagal karena rumitnya sistem yang dibangun dan kegagalan pada saat
testing. Chrysler kemudian menyewa Kent Beck, seorang pakar software engineering
yang di kemudian hari dikenal sebagai pencetus awal dari XP, untuk menyelamatkan
proyek tersebut. Beck bersama rekannya Ron Jeffries dengan kewenangan yang diberikan
oleh Chrysler melakukan berbagai perubahan di C3 Project untuk membuatnya lebih
efisien, adaptif, dan fleksibel. Hal yang paling penting bagi mereka adalah harus mampu
memenuhi permintaan utama dari Chrysler, untuk melakukan launching perangkat lunak
tersebut dalam waktu tidak lebih dari dua tahun sejak saat Beck dikontrak.

Beck dan Jeffries pada akhirnya berhasil menyelesaikan target Chrysler dengan
menerapkan berbagai metode dalam proses pengembangan perangkat lunak tersebut.
Kumpulan metode inilah yang kemudian dikenal sebagai model atau pendekatan XP
dalam pengembangan perangkat lunak. Begitu sederhananya metode-metode tersebut
sehingga bagi orang yang belum menerapkan, XP terlihat sebagai kumpulan ide lama
yang terlalu sederhana dan tidak akan memberikan efek apapun pada sebuah proyek
pengembangan perangkat lunak.
 Kent Beck sendiri mengakui dan menegaskan bahwa XP tidak selalu cocok untuk
setiap proyek pengembangan perangkat lunak. Kelebihan XP adalah sesuai untuk
digunakan pada proyek yang memiliki dynamic requirements. Proyek semacam ini
memerlukan adaptasi cepat dalam mengatasi perubahan-perubahan yang terjadi selama
proses pengembangan perangkat lunak. XP juga cocok untuk proyek dengan jumlah
anggota tim tidak terlalu banyak (sekitar 10-20 orang) dan berada pada lokasi yang sama.

2.3 LATAR BELAKANG EXTREME PROGRAMMING

Requirement yang berubah dengan cepat menuntut lifecycles yang lebih pendek,
dan tidak selaras dengan metoda pengembangan tradisional, yang pada umumnya
memerlukan disain luas di awal dan mengakibatkan perubahan desain yang terjadi
kemudian memerlukan biaya yang lebih tinggi atau kehilangan milestones.

Berdasarkan hal ini kemudian dilahirkan konsep XP yang digagas oleh Kent Beck
dan Ward Cunningham pada Maret 1996. Metode XP merupakan yang terpopuler dari
beberapa metodologi pengembangan software yang dipakai untuk mengimplementasikan
proyek pengembangan perangkat lunak.

2.4 TUJUAN EXTREME PROGRAMMING

Tujuan utama XP adalah menurunkan biaya dari adanya perubahan software.

Dalam metodologi pengembangan sistem tradisional, kebutuhan sistem ditentukan pada
tahap awal pengembangan proyek dan bersifat fixed. Hal ini berarti biaya terhadap
adanya perubahan kebutuhan yang terjadi pada tahap selanjutnya akan menjadi mahal.
XP diarahkan untuk menurunkan biaya dari adanya perubahan dengan memperkenalkan
nilai-nilai basis dasar, prinsip dan praktis. Dengan menerapkan XP, pengembangan suatu
sistem haruslah lebih fleksibel terhadap perubahan.

2.5 KUNCI UTAMA DALAM EXTREME PROGRAMMING

Menurut penggagas dari metode XP, Kent Beck mendefinisikan lima kunci utama
(inti) dari XP yaitu:

1. Communication (Komunikasi)

Tugas utama developer dalam membangun suatu sistem perangkat lunak adalah
mengkomunikasikan kebutuhan sistem kepada pengembang perangkat lunak.
Komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair
programming). Developer didampingi oleh pihak klien dalam melakukan coding dan unit
testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi
dengan developer. Tujuannya untuk memberikan pandangan pengembang sesuai dengan
pandangan pengguna sistem.
2. Simplicity (Kesederhanaan)

XP mencoba untuk mencari solusi paling sederhana dan praktis. Perbedaan

metode ini dengan metodologi pengembangan sistem konvensional lainnya terletak pada
proses desain dan coding yang terfokus pada kebutuhan saat ini daripada kebutuhan
besok, seminggu lagi atau sebulan lagi. Lebih baik melakukan hal yang sederhana dan
mengembangkannya besok jika diperlukan.

3. Feedback (Umpan Balik)

Hal ini diperlukan untuk mengetahui kemajuan dari proses dan kualitas dari
aplikasi yang dibangun. Informasi ini harus dikumpulkan setiap interval waktu yang
singkat secara konsisten. Ini dimaksudkan agar hal-hal yang menjadi masalah dalam
proses pengembangan dapat diketahui sedini mungkin. Setiap feed back ditanggapi
dengan melakukan tes, unit test atau system integration dan jangan menunda karena 
biaya akan membengkak (uang, tenaga, waktu).

4. Courage (Keberanian)

Berani mencoba ide baru. Berani mengerjakan kembali dan setiap kali kesalahan
ditemukan, langsung diperbaiki. Contoh dari courage adalah komitmen untuk selalu
melakukan design dan coding untuk saat ini dan bukan untuk esok. Ketika ada kode yang
terlalu rumit, sulit dibaca dan dipahami, tidak sesuai dengan kemauan pelanggan, dll
maka seharusnya kode program seperti itu di refactor (kalau perlu dibangun ulang). Hal
ini menjadikan pengembang merasa nyaman dengan refactoring program ketika
diperlukan

5. Respect (Menghormati)

Pentingnya respect terhadap anggota team lainnya karena dengan siklus pendek
dan integrasi continue, programmer tidak boleh melakukan perubahan yang dapat
merusak kompilasi dan menyebabkan keberadaan unit uji gagal atau memperlambat kerja
team. Respects tiap individu akan selalu menghasilkan kualitas tinggi.

2.6 PENERAPAN EXTREME PROGRAMMING

Beberapa hal yang harus dipertimbangkan sebelum seseorang masuk dalam dunia
XP adalah sebagai berikut:

 User harus memahami konteks bisnis yang akan dikembangkan sistemnya,

sehingga developer dapat menangkap sistem secara aplikatif dan dapat
mengusulkan teknologi apa yang dapat dikembangkan dalam sistem barunya
 Akan lebih efektif apabila developer pernah menangani proyek pengembangan
sistem yang sejenis sehingga dapat memberikan usulan model sistem baru, di
samping alasan bahwa developer telah memiliki template aplikasi sistem tersebut
untuk dijadikan prototype sistem baru. Hal ini akan berimplikasi kepada
 kemudahan dalam konstruksi sistem karena dikembangkan berdasarkan template
yang sudah ada.
 Extreme programming menuntut komunikasi antar developer dan user secara
intensif dan komunikasi internal antar developer secara komprehensif, sehingga
akan lebih representatif apabila tahap pengembangan sistem dilakukan di lokal
yang mendukung proses komunikasi tersebut.

XP adalah suatu bentuk pembangunan perangkat lunak yang berbasis nilai

kemudahan, komunikasi, umpan balik, dan keberanian. Bekerja dalam whole team
bersama-sama dengan praktek yang mudah. Adapun inti penerapannya adalah:

 Planning Game
 Small, frequent releases
 System metaphors
 Simple design
 Testing (unit testing & TDD)
 Frequent refactoring
 Pair programming
 Collective code ownership
 Continuous integration
 Sustainable pace
 Whole team together
 Coding standard

2.7 ASPEK DASAR EXTREME PROGRAMMING

Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan Beck dan
Jeffries pada C3 Project. Teknik-teknik tersebut dapat diamati pada gambar berikut ini
 Gambar 01. model proses XP

1. The Planning Game

Pendekatan XP dalam perencanaan sangat mirip dengan metode yang diterapkan
pada RAD (Rapid Application Development). Proses pendek dan cepat,
mengutamakan aspek teknik, memisahkan unsur bisnis dengan unsur teknis dan
pertemuan intensif antara klien dengan developer. Pada XP proses ini menggunakan
terminologi “game” karena Beck menyarankan untuk menggunakan teknik score
card dalam menentukan requirements. Semakin sulit aspek teknis yang dibutuhkan
semakin tinggi pula skor pada kartu rencana tersebut.

2. Small Releases
Setiap release dilakukan dalam lingkup sekecil mungkin pada XP. Setiap developer
menyelesaikan sebuah unit atau bagian dari perangkat lunak maka hasil tersebut
harus segera dipresentasikan dan didiskusikan dengan klien. Jika memungkinkan
untuk menerapkan unit tersebut pada perusahaan, hal itu juga dapat dilakukan
sekaligus sebagai tes awal dari penerapan keseluruhan sistem. Kendati demikian hal
ini tidak selalu perlu dilakukan karena harus dihitung terlebih dahulu sumberdaya
yang dibutuhkan. Apakah lebih menguntungkan langsung melakukan tes terhadap
 unit tersebut atau melakukan tes setelah unit tersebut terintegrasi secara sempurna
pada sistem.

3. Metaphor
Metaphor pada dasarnya sama dengan arsitektur perangkat lunak. Keduanya
menggambarkan visi yang luas terhadap tujuan dari pengembangan perangkat lunak.
Beck sendiri seperti para penandatangan Agile Manifesto lainnya bercita-cita
menyederhanakan proses pengembangan perangkat lunak yang saat ini sudah
dianggap terlalu rumit. Arsitektur yang saat ini banyak berisi diagram dan kode
semacam UML dianggap terlalu rumit untuk dimengerti, terutama oleh klien.
Metaphor, walaupun mirip dengan arsitektur lebih bersifat naratif dan deskriptif.
Dengan demikian diharapkan komunikasi antara klien dengan developer akan
berlangsung lebih baik dan lancar dengan penggunaan metaphor.

4. Simple Design
Sebagai salah seorang penandatangan Agile Manifesto, Beck adalah seorang yang
tidak menyukai desain yang rumit dalam sebuah pengembangan perangkat lunak.
Tidak heran jika dia memasukkan Simple Design sebagai salah satu unsur XP. Pada
XP desain dibuat dalam lingkup kecil dan sederhana. Tidak perlu melakukan
antisipasi terhadap berbagai perubahan di kemudian hari. Dengan desain yang simpel
apabila terjadi perubahan maka membuat desain baru untuk mengatasi perubahan
tersebut dapat dengan mudah dilakukan dan resiko kegagalan desain dapat
diperkecil.

5. Refactoring
Refactoring adalah salah satu aspek paling khas dari XP. Refactoring seperti
didefinisikan oleh Martin Fowler adalah ”Melakukan perubahan pada kode program
dari perangkat lunak dengan tujuan meningkatkan kualitas dari struktur program
tersebut tanpa mengubah cara program tersebut bekerja”. Refactoring sendiri sangat
sesuai untuk menjadi bagian XP karena Refactoring mengusung konsep
penyederhanaan dari proses desain maupun struktur baris kode program. Dengan
Refactoring tim pengembang dapat melakukan berbagai usaha untuk meningkatkan
kualitas program tanpa kembali mengulang-ulang proses desain. Fowler adalah salah
satu kolega dekat dari Kent Beck karena itu tidak mengherankan bahwa cara berpikir
mereka terhadap proses pengembangan perangkat lunak sangat mirip satu dengan
lainnya.

6. Testing
XP menganut paradigma berbeda dalam hal tes dengan model pengembangan
perangkat lunak lainnya. Jika pada pengembangan perangkat lunak lainnya tes baru
dikembangkan setelah perangkat lunak selesai menjalani proses coding maka pada
XP tim pengembang harus membuat terlebih dahulu tes yang hendak dijalani oleh
perangkat lunak. Berbagai model tes yang mengantisipasi penerapan perangkat lunak
pada sistem dikembangkan terlebih dahulu. Saat proses coding selesai dilakukan
maka perangkat lunak diuji dengan model tes yang telah dibuat tersebut. Pengetesan
akan jauh lebih baik apabila dilakukan pada setiap unit perangkat lunak dalam
 lingkup sekecil mungkin daripada menunggu sampai seluruh perangkat lunak selesai
dibuat. Dengan memahami tahap ini kita dapat melihat bahwa siklus pada XP adalah
requirement analysis  test  code  design. Sekilas terlihat hal ini tidak mungkin
dilakukan tetapi pada kenyataannya memang gambaran inilah yang paling dapat
menjelaskan tentang XP.

7. Pair Programming
Pair programming adalah melakukan proses menulis program dengan berpasangan.
Dua orang programer saling bekerjasama di komputer yang sama untuk
menyelesaikan sebuah unit. Dengan melakukan ini maka keduanya selalu dapat
berdiskusi dan saling melakukan koreksi apabila ada kesalahan dalam penulisan
program. Aspek ini mungkin akan sulit dijalankan oleh para programer yang
memiliki ego tinggi dan sering tidak nyaman untuk berbagi komputer bersama
rekannnya.

8. Collective Ownership
Tidak ada satupun baris kode program yang hanya dipahami oleh satu orang
programer. XP menuntut para programer untuk berbagi pengetahuan untuk tiap baris
program bahkan beserta hak untuk mengubahnya. Dengan pemahaman yang sama
terhadap keseluruhan program, ketergantungan pada programer tertentu ataupun
berbagai hambatan akibat perbedaan gaya menulis program dapat diperkecil. Pada
level yang lebih tinggi bahkan dimungkinkan para programer dapat bertukar unit
yang dibangunnya.

9. Coding Standards
Pair programming dan collective ownership hanya akan dapat berjalan dengan baik
apabila para programer memiliki pemahaman yang sama terhadap penulisan kode
program. Dengan adanya coding standards yang telah disepakati terlebih dahulu
maka pemahaman terhadap program akan menjadi mudah untuk semua programer
dalam tim. Hal ini dapat diterapkan sebagai contoh pada penamaan variabel dan
penggunaan tipe data yang sama untuk tiap elemen semua record atau array pada
program.

10. Continous Integration

Melakukan build setiap hari kerja menjadi sebuah model yang disukai oleh berbagai
tim pengembang perangkat lunak. Hal ini terutama didorong oleh keberhasilan
penerapan sistem ini oleh Microsoft dan telah sering dipublikasikan. Dengan
melakukan build sesering mungkin berbagai kesalahan pada program dapat dideteksi
dan diperbaiki secepat mungkin. Apabila banyak tim pengembang perangkat lunak
meyakini bahwa build sekali sehari adalah minimum maka pada XP hal tersebut
adalah maksimum. Pada XP tim disarankan untuk melakukan build sesering mungkin
misalnya setiap 4 jam atau bahkan lebih cepat lagi.

11. 40-hours Week

 Beck berpendapat bekerja 8 jam sehari dan 5 hari seminggu adalah maksimal untuk
tiap programer. Lebih dari itu programer akan cenderung membuat berbagai error
pada baris-baris kode programnya karena kelelahan.

12. On-Site Customer

Sebuah pendekatan klasik, di mana XP menganjurkan bahwa ada anggota dari klien
yang terlibat pada proses pengembangan perangkat lunak. Yang lebih penting lagi ia
harus ada di tempat pemrogaman dan turut serta dalam proses build dan test yang
dilakukan. Apabila ada kesalahan dalam pengembangan diharapkan klien dapat
segera memberikan masukan untuk koreksinya.

2.8 KELEBIHAN DAN KELEMAHAN EXTREME PROGRAMMING

Kelebihan

 Menjalin komunikasi yang baik dengan client.

 Meningkatkan komunikasi dan sifat saling menghargai antar developer

Kelemahan

 Developer harus selalu siap dengan perubahan karena perubahan akan selalu
diterima.
 Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran
untuk melakukan apa yang diperlukan hari itu juga).
 BAB III

PROTOTYPING MODEL

3.1 PENGERTIAN PROTOTYPING MODEL

Model prototipe (prototyping model), merupakan suatu teknik untuk

mengumpulkan informasi tertentu mengenai kebutuhankebutuhan informasi pengguna
secara cepat. Berfokus pada penyajian dari aspek–aspek software tersebut yang akan
nampak bagi pelanggan atau pemakai (contohnya pendekatan input dan format output).
Prototipe tersebut dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaring
kebutuhan pengembangan software. Iterasi terjadi pada saat prototipe ditunjukkan untuk
memenuhi kebutuhan pelanggan, dan pada saat yang sama memungkinkan pengembang
untuk secara lebih baik memahami apa yang harus dilakukannya. Metode dengan
menyajikan gambaran yang lengkap tentang sistemnya, pemesan dapat melihat
pemodelan sistem dari sisi tampilan maupun teknik prosedural yang akan dibangun.

Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software

tanpa detil input, proses atau detil output. Di lain waktu mungkin dimana tim pembangun
(developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi
terhadap sistem operasi atau rancangan form user interface. Ketika situasi seperti ini
terjadi model prototyping sangat membantu proses pembangunan software.

3.2 SEJARAH PROTOTYPING MODEL

?????

3.3 ASPEK DASAR PROTOTYPING MODEL

Tahapan Umum Model Prototype

 Reaksi awal dari pengguna, diawali dengan menampilkan sebuah prototipe system
informasi, kemudian melihat reaksi dari pengguna saat bekerja dengan prototipe
apakah fitur-fitur sistem pada prototype tersebut sudah sesuai dengan
kebutuhannya.
-Reaksi tersebut dikumpulkan dalam lembar observasi, wawancara dan kuesioner.
 Saran-saran pengguna, saran-saran merupakan hasil interaksi pengguna dengan
prototipe yang ditampilkan (evaluasi pengguna) yang merupakan masukan untuk
perbaikan, pengubahan atau ‘menghentikan’ prototipe sehingga dapat memenuhi
kebutuhan pengguan dengan lebih baik.
 Inovasi, adalah kemampuan-kemampuan sistem baru yang sebelumnya tidak ada
pada saat pengguna berinteraksi dengan prototipe. Inovasi prototipe jika berhasil
akan menjadi bagian dari sistem hasil jadi.
 Rencana revisi, prototipe menggambarkan sistem di masa datang. Rencana revisi
membantu mengidentifikasikan prioritas-prioritas apa saja yang akan diprototipekan
selanjutnya.
 Aktivitas Prototype
Proses pada model prototyping bisa dijelaskan sebagai berikut:
1. Mengidentifikasi kebutuhan : analisa terhadap kebutuhan calon user
2. Quick design : pembuatan desain global untuk membentuk contoh s/w
3. Build prototype : pembuatan s/w prototype termasuk pengujian dan
penyempurnaan
4. Evaluasi pelanggan : mengevaluasi prototype dan memperhalus analis
kebutuhan calon pemakai
5. Pembuatan & implementasi : pembuatan sebenarnya termasuk design,
coding, dan testing

Gambar 01. model proses Prototyping

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 , 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. Agar model ini
bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa
prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.

3.4 Kelebihan dan kekurangan Model Prototype

Kelemahan Prototype
 Ketidaksadaran user bahwa ini hanya suatu model awal bukan model akhir
 Pengembang kadang-kadang membuat implementasi yang sembarangan.
 Teknik dan tools yang tidak optimal pada prototype yang akan tetap digunakan
pada s/w sesungguhnya.
 Kebutuhan mempunyai kemungkinan sering berubah.
 Sulit dalam hal dokumentasi
 Banyaknya perulangan proses dapat membuat pembengkakan biaya dan jadwal

Kelebihan Prototype
o Memudahkan user untuk memetakan pikirannya dengan prototipe
o Lebih tampak realistis bagi user
o Membangun komunikasi yang baik dengan user
o Bermanfaat untuk menyatakan objek yang abstrak
o Membantu mengidentifikasi kebingungan spesifikasi
o Dapat menggenerasi spesifikasi aplikasi
o Mendorong adanya inovasi dan desain yang fleksibel
o Waktu pengembangan cepat jika tidak terjadi banyak iterasi

Kondisi Sesuai Prototype

 Membutuhkan banyak input dari user
 Proyek besar dengan banyak user
 Proyek tidak jelas objeknya
 Ada tekanan untuk implementasi secepatnya
 Perubahan fungsional sering berubah
 User tidak terlalu memiliki pengetahuan yang memadai
 Anggota tim berpengalaman
 Komposisi tim stabil
 Manajer proyek berpengalaman
 Tidak ada jadwal strik
 Mengijinkan ada banyak inovasi

Kondisi Tidak Sesuai Prototype

o Aplikasi berbasis transaksi dengan system batch

o Sistem e-bisnis berbasis web
o Komposisi tim tidak stabil
o Kemungkinan perubahan desain tidak terlalubanyak
o Objek proyek jelas