P. 1
model proses perangkat lunak

model proses perangkat lunak

|Views: 4,547|Likes:
Published by emzy_cute
dasar model proses perangkat lunak, XP, extream programing , Prototype model
dasar model proses perangkat lunak, XP, extream programing , Prototype model

More info:

Published by: emzy_cute on May 23, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

01/10/2013

pdf

text

original

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

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->