March 5, 2011

[TUGAS INDIVIDU RPL VERA SURYANINGSIH (M0509074)]

Perbandingan Waterfall, RAD, Prototyping, Spiral, Incremental, Unified Process,

Extreme Programming (XP), Scrum, Agile S/W dari Segi Kelebihan dan Kekurangan
No

Software Proses

Kelebihan

Kekurangan

Waterfall Process
Model

Proses menjadi teratur

Estimasi menjad lebih baik
Jadwal menjadi lebih menentukan

Sifatnya kaku, sehingga susah melakukan perubahan di tengah proses

Membutuhkan daftar kebutuhan yang lengkap di awal, tapi jarang
konsumen bisa memberikan kebutuhan secara lengkap diawal

RAD Process Model

Cocok untuk proyek skala besar

Fleksibilitas yang lebih besar
Sangat mengurangi manual coding
Peningkatan keterlibatan pengguna
Mungkin lebih sedikit cacat
Mungkin dikurangi biaya
Singkat siklus pengembangan

Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi

Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini
Resiko teknis yang tinggi juga kurang cocok untuk model ini

Prototyping Process
Model

User dapat berpartisipasi aktif

Penentuan kebutuhan lebih mudah diwujudkan
Mempersingkat waktu pengembangan SI

Proses analisis dan perancangan terlalu singkat

Mengesampingkan alternatif pemecahan masalah
Bisanya kurang fleksible dalam mengahadapi perubahan
Prototype yang dihasilkan tidak selamanya mudah dirubah
Prototype terlalu cepat selesai

Spiral Process Model

Dapat disesuaikan agar bisa dipakai selama hidup software komputer.

Cocok untuk proyek skala besar
Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi
terhadap resiko setiap tingkat evolusi karena perangkat lunak terus
bekerja selama proses
Menggunakan prototipe sebagai mekanisme pengurangan resiko dan
pada setiap keadaan di dalam evolusi produk.
Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan
memasukkannya ke dalam kerangka kerja iteratif .
Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga
mengurangi resiko sebelum menjadi permaslahan yang serius.

Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner

ini bisa dikontrol.
Memerlukan penaksiran resiko yang masuk akal dan akan menjadi
masalah yang serius jika resiko mayor tidak ditemukan dan diatur.
Butuh waktu lama untuk menerapkan paradigma ini menuju
kepastian yang absolut

Model ini cocok jika jumlah anggota tim pengembang/pembangun PL

tidak cukup
Mampu mengakomodasi perubahan secara fleksibel.

Increment Process
Model

Hanya untuk proyek berskala kecil

Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke
dalam rencana spesifikasi masing-masing hasil increment.

March 5, 2011

[TUGAS INDIVIDU RPL VERA SURYANINGSIH (M0509074)]

Unified Process Model

UP dapat diaplikasikan pada berbagai skala proyek

Penggunaan UML

Bersifatus e-cas e-dr iven

Membutuhkan tim proyek yang memfokuskan untuk mengatasi
masalah yang paling penting pada awal life cycle proyek sehingga
pada fase elaborasi masalah tersebut bisa deketahui sejak awa

Extreme Programming
Process Model

Hasil biaya di dapat dalam waktu yang sangat cepat

Menjalin komunikasi yang baik dengan client
Bekerja lebih baik dengan tidak ada perubahan yang tak tentu

Membutuhkan kedisiplinan yang tinggi

Hanya untuk proyek kecil
Membutuhkan lebih banyak inputan dari pengguna
Developer harus selalu siap dengan perubahan

Scrum Process Model

Hanya untuk proyek berskala kecil

Membutuhkan kedisiplinan yang tinggi

The V Process Model

Komunikasi mudah karena tim Cuma kecil

Proses bisa beradaptasi dengan teknis dan bisnis
Dokumentasi teratur
Keterganrungan antar pekerja kecil
Fleksibel terhadap perubahan
User dapat berpartisipasi aktif
Merupakan model pengembangan terstruktur.
Setiap fase dapat diimplementasikan dengan dokumentasi yang detail
dari fase sebelumnya.
Aktivitas pengujian dapat dimulai di awal proyek, sehingga mengurangi
waktu proyek.

Hanya bisa digunakan sekali dalam suatu proyek

Dokumentasi harus cukup detail agar fase selanjutnya dapat berjalan
dengan baik

10

Agile Process Model

Meningakatkan rasio kepuasan pelanggan.

Bisa melakukan reviw pelanggan mengenai software yang dibuat lebih
awal.
Mengurangi resiko kegagalan implementasi software dari non-teknis.
Besar kerugian baik secara material atau imaterial tidak terlalu besar jiak
terjadi kegagalan.

Membutuhkan kedisiplinan tinggi

Tepat hanya jika dilakukan di projek kecil
Membutuhkan lebih banyak inputan dari pengguna

syukriya.files.wordpress.com/2009/.../rapid-application-development.ppt

http://teknologi.kompasiana.com/internet/2010/09/27/sdlc/

blog.unsri.ac.id/userfiles/09071003035.doc

http://Blog.binadarma.ac.id/usman/?p=940

http://johan-it-2009.blogspot.com/2009/11/blog-post.html
http://www.scribd.com/doc/21670617/Model-Proses-Software
http://Mkompasiana,com/post4cd6b1489bc80be556080700