31813767 model proses perangkat lunak

7/23/2019 31813767 Model Proses Perangkat Lunak

1/14

BAB I

PENDAHULUAN

1.1 Latar Belakang

Proses Perangkat Lunak merupakan Sekumpulan aktifitas yang memilikitujuan 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 pengembangannyaPengembangan 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 prosesperangkat 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 rangkapengembangan 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 Waterfall2. 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 model3. Rapid Aplication development (RAD) model

4. Evolutionary software process model terdiri dari:

a. Increment Modelb. Spiral model

c. WINWIN Spiral Model

d. Conccurent development model5. Component based development


2/14

6. Formal method model

7. 4th Generation technique paradigm

Selain Model proses diatas masih banyak proses model lainnya, Model proses munculdikarenakan :

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 prosesperangkat 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 yangdigunakan 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.


3/14

BAB II

EXTREME PROGRAMMING

2.1 PENGERTIAN EXTREME PROGRAMMING

Extreme Programming merupakan salah satu metodologi dalam rekayasaperangkat lunak dan juga merupakan satu dari beberapa agile software development

methodologies yang berfokus pada codingsebagai aktivitas utama di semua tahap pada

siklus pengembangan perangkat lunak (software development lifecycle). Metodologi inimengedepankan 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 dalampengembangan 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-anini terancam gagal karena rumitnya sistem yang dibangun dan kegagalan pada saat

testing. Chrysler kemudian menyewa Kent Beck, seorang pakarsoftware engineering

yang di kemudian hari dikenal sebagai pencetus awal dari XP, untuk menyelamatkanproyek 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 mampumemenuhi permintaan utama dari Chrysler, untuk melakukan launchingperangkat 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 lamayang terlalu sederhana dan tidak akan memberikan efek apapun pada sebuah proyek

pengembangan perangkat lunak.


4/14

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 inimemerlukan 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 terjadikemudian 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 mengimplementasikanproyek 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 terhadapadanya 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 adalahmengkomunikasikan kebutuhan sistem kepada pengembang perangkat lunak.

Komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pairprogramming). 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.


5/14

2. Simplicity (Kesederhanaan)

XP mencoba untuk mencari solusi paling sederhana dan praktis. Perbedaan

metode ini dengan metodologi pengembangan sistem konvensional lainnya terletak padaproses desain dan coding yang terfokus pada kebutuhan saat ini daripada kebutuhan

besok, seminggu lagi atau sebulan lagi. Lebih baik melakukan hal yang sederhana danmengembangkannya besok jika diperlukan.

3. Feedback (Umpan Balik)

Hal ini diperlukan untuk mengetahui kemajuan dari proses dan kualitas dariaplikasi 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 ditanggapidengan 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 kesalahanditemukan, 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). Halini menjadikan pengembang merasa nyaman dengan refactoring program ketika

diperlukan

5. Respect (Menghormati)

Pentingnya respect terhadap anggota team lainnya karena dengan siklus pendekdan 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 duniaXP adalah sebagai berikut:

User harus memahami konteks bisnis yang akan dikembangkan sistemnya,

sehingga developer dapat menangkap sistem secara aplikatif dan dapatmengusulkan 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


6/14

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 nilaikemudahan, 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 danJeffries pada C3 Project. Teknik-teknik tersebut dapat diamati pada gambar berikut ini
http://www.xprogramming.com/xpmag/whatisxp.htm#wholehttp://www.xprogramming.com/xpmag/whatisxp.htm#whole


7/14

Gambar 01. model proses XP

1. The Planning GamePendekatan XP dalam perencanaan sangat mirip dengan metode yang diterapkan

padaRAD (Rapid Application Development). Proses pendek dan cepat,

mengutamakan aspek teknik, memisahkan unsur bisnis dengan unsur teknis danpertemuan intensif antara klien dengan developer. Pada XP proses ini menggunakan

terminologi game karena Beck menyarankan untuk menggunakan teknikscore

carddalam menentukan requirements. Semakin sulit aspek teknis yang dibutuhkansemakin tinggi pula skor pada kartu rencana tersebut.

2. Small Releases

Setiap release dilakukan dalam lingkup sekecil mungkin pada XP. Setiap developermenyelesaikan 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 dilakukansekaligus 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


8/14

unit tersebut atau melakukan tes setelah unit tersebut terintegrasi secara sempurna

pada sistem.

3. Metaphor

Metaphorpada 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 kodesemacam 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 developerakan

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 melakukanantisipasi 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 dapatdiperkecil.

5. Refactoring

Refactoringadalah salah satu aspek paling khas dari XP.Refactoringsepertididefinisikan 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.Refactoringsendiri sangatsesuai untuk menjadi bagian XP karenaRefactoringmengusung konsep

penyederhanaan dari proses desain maupun struktur baris kode program. Dengan

Refactoringtim pengembang dapat melakukan berbagai usaha untuk meningkatkankualitas 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 pengembanganperangkat lunak lainnya. Jika pada pengembangan perangkat lunak lainnya tes baru

dikembangkan setelah perangkat lunak selesai menjalani proses codingmaka pada

XP tim pengembang harus membuat terlebih dahulu tes yang hendak dijalani olehperangkat lunak. Berbagai model tes yang mengantisipasi penerapan perangkat lunak

pada sistem dikembangkan terlebih dahulu. Saat proses codingselesai 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


9/14

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 programmingadalah melakukan proses menulis program dengan berpasangan.

Dua orang programer saling bekerjasama di komputer yang sama untukmenyelesaikan 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 yangmemiliki 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 orangprogramer. XP menuntut para programer untuk berbagi pengetahuan untuk tiap baris

program bahkan beserta hak untuk mengubahnya. Dengan pemahaman yang samaterhadap 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 unityang dibangunnya.

9. Coding StandardsPair programmingdan 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 dahulumaka pemahaman terhadap program akan menjadi mudah untuk semua programerdalam tim. Hal ini dapat diterapkan sebagai contoh pada penamaan variabel dan

penggunaan tipe data yang sama untuk tiap elemen semua recordatau array pada

program.

10. Continous Integration

Melakukan buildsetiap hari kerja menjadi sebuah model yang disukai oleh berbagaitim pengembang perangkat lunak. Hal ini terutama didorong oleh keberhasilan

penerapan sistem ini oleh Microsoft dan telah sering dipublikasikan. Dengan

melakukan buildsesering mungkin berbagai kesalahan pada program dapat dideteksi

dan diperbaiki secepat mungkin. Apabila banyak tim pengembang perangkat lunakmeyakini bahwa buildsekali sehari adalah minimum maka pada XP hal tersebut

adalah maksimum. Pada XP tim disarankan untuk melakukan buildsesering mungkin

misalnya setiap 4 jam atau bahkan lebih cepat lagi.

11. 40-hours Week


10/14

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 klienyang 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 dapatsegera 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).


11/14

BAB III

PROTOTYPING MODEL

3.1 PENGERTIAN PROTOTYPING MODEL

Model prototipe (prototyping model), merupakan suatu teknik untukmengumpulkan informasi tertentu mengenai kebutuhankebutuhan informasi pengguna

secara cepat. Berfokus pada penyajian dari aspekaspeksoftware tersebut yang akan

nampak bagi pelanggan atau pemakai (contohnya pendekatan input dan format output).

Prototipe tersebut dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaringkebutuhan pengembangansoftware. 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 denganmenyajikan 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 adaptasiterhadap 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 prototipeapakah 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 memenuhikebutuhan 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 diprototipekanselanjutnya.


12/14

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 danpenyempurnaan

4. Evaluasi pelanggan : mengevaluasi prototype dan memperhalus analis

kebutuhan calon pemakai5. 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 untukmemahami kebutuhan klien lebih baik. Prototype yang dibuat dapat dimanfaatkan

kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa

dimanfaatkan.


13/14

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 berkerasterhadap 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 membuatprototype 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

KelemahanPrototype 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

oMemudahkan useruntuk memetakan pikirannya dengan prototipe

oLebih tampak realistis bagi user

oMembangun komunikasi yang baik dengan user

oBermanfaat untuk menyatakan objek yang abstrak

oMembantu mengidentifikasi kebingungan spesifikasi

oDapat menggenerasi spesifikasi aplikasi

oMendorong adanya inovasi dan desain yang fleksibel

oWaktu pengembangan cepat jika tidak terjadi banyak iterasi

Kondisi Sesuai Prototype

Membutuhkan banyak input dari user

Proyek besar dengan banyakuser

Proyek tidak jelas objeknya

Ada tekanan untuk implementasi secepatnya

Perubahan fungsional sering berubah

Usertidak terlalu memiliki pengetahuan yang memadai


14/14

Anggota tim berpengalaman

Komposisi tim stabil

Manajer proyek berpengalaman

Tidak ada jadwal strik

Mengijinkan ada banyak inovasi

Kondisi Tidak Sesuai Prototype

oAplikasi berbasis transaksi dengan system batch

oSistem e-bisnis berbasis web

oKomposisi tim tidak stabil

oKemungkinan perubahan desain tidak terlalubanyak

oObjek proyek jelas

31813767 model proses perangkat lunak

Documents