Nama : Andi Septiana

NIM : 1703003
Kelas : D3TI3A
INTERATIVE MODEL

1. Prototype
2. Spiral
3. Unified Process
4. CleanRoom
1. Model Spiral
Aktivitas didalam Model Spiral
a) Komunikasi Pemakai (Customer Communication)
b) Membangun komunikasi yang baik dengan pengguna sistem.
c) Perencanaan (Planning)
d) Penentuan tujuan, alternatif dan batasan.
e) Analisis resiko (Risk Analysis)
f) Analisis alternatif dan identifikasi / pemecahan resiko
g) Rekayasa (Engineering)
h) Pembangunan contoh-contoh aplikasi, misalnya prototype.
i) Pembangunan & Realisasi (Construction & Release)
Merupakan model proses perangkat j) Pembangunan sistem, test, install dan support.
lunak yang memadukan wujud k) Evaluasi Pemakai (Customer Evaluation)
perulangan dari model prototyping l) Penilaian terhadap hasil dari fase rekayasa dan fase pembangunan
dengan aspek pengendalian dan & realisasi oleh pengguna.
sistematika dari waterfall model, dengan
penambahan elemen baru yaitu analisis Bentuk spiral memberikan gambaran bahwa semakin besar
resiko. iterasinya, maka menunjukkan makin lengkap versi dari
perangkat lunak yang dibuat.
Kelemahan Model Spiral` Keuntungan Model Spiral

Sulit untuk meyakinkan pemakai (saat situasi
kontrak) bahwa penggunaan pendekatan ini akan
dikendalikanMemerlukan tenaga ahli untuk
memperkirakan resiko, dan harus
mengandalkannya supaya suksesBelum terbukti
apakah metode ini cukup efisien karena usianya
relatif baru.
Pada model spiral, resiko sangat dipertimbangkan. Resiko
adalah sesuatu yang mungkin mengakibatkan
kesalahan.Model spiral merupakan pendekatan yang
realistik untuk pengembangan perangkat lunak / sistem
berskala besar.Pengguna dan pembangun bisa memahami
dengan baik perangkat lunak yang dibangun karena setiap
kemajuan yang dicapai selama proses dapat dinikmati
dengan baik.
2. Model prototype

Prototipe merupakan simulasi atau animasi dari bakal sistem.Prototipe

merupakan suatu metode dlm pengembangan sistem yg menggunakan
pendekatan utk membuat sesuatu program dg cepat & bertahap shg
segera dpt dievaluasi oleh pemakaiPrototipe ini memang benar-benar
cocok utk user yg awam IT.Dalam pembuatan prototipe kita dpt
menerapkan UCD (User Centered Design).

Tahapan prototype

• Pengumpulan kebutuhan
• Membangun prototyping
• Evaluasi protoptyping
• Mengkodekan system
• Menguji system
• Evaluasi Sistem
• Menggunakan sistem
Kelebihan Model Prototype
1. Pelanggan berpartisipasi aktif dalam pengembangan
sistem, sehingga hasil produk pengembangan akan
semakin mudah disesuaikan dengan keinginan dan
kebutuhan pelanggan.
2. Penentuan kebutuhan lebih mudah diwujudkan.
3. Mempersingkat waktu pengembangan produk
perangkat lunak.
4. Adanya komunikasi yang baik antara pengembang
dan pelanggan.
5. Pengembang dapat bekerja lebih baik dalam
menentukan kebutuhan pelanggan.
6. Lebih menghemat waktu dalam pengembangan
sistem.
7. Penerapan menjadi lebih mudah karena pelanggan
mengetahui apa yang diharapkannya.
Kekurangan Model Prototype
1. Proses analisis dan perancangan terlalu
singkat.
2. Biasanya kurang fleksibel dalam
mengahadapi perubahan.
3. Walaupun pemakai melihat berbagai
perbaikan dari setiap versi prototype, tetapi
pemakai mungkin tidak menyadari bahwa
versi tersebut dibuat tanpa memperhatikan
kualitas dan pemeliharaan jangka panjang.
4. Pengembang kadang-kadang membuat
kompromi implementasi dengan
menggunakan sistem operasi yang tidak
relevan dan algoritma yang tidak efisien.
3. Unified Process
Mengapa Unified Process
1. Perancangan berbasis obyek
2. Menerapkan Unified Modelling Language (UML)
3. Dapat diterapkan ke pendekatan Agile (XP, Scrum)
4. Analisis kebutuhan secara incremental
Unived process adalah Metode proses
pengembangan sistem yang bersifat
use-case-driven atau menggunakan use
case sebagai alur untuk membangun
sebuah sistem informasi.
Kelebihan Kekurangan

1. Menyediakan akses yang mudah terhadap 1. Metodologi ini hanya dapat digunakan pada
pengetahuan dasar bagi anggota tim pengembangan perangkat lunak yang berorientasi
2. Menyediakan petunjuk bagaimana menggunakan objek dengan berfokus pada UML (Unified Modeling
UML secara efektif. Language)
3. Mendukung proses pengulangan dalam 2. Membutuhkan waktu yang cukup lama
pengembangan software
4. Memungkinkan adanya penambahan-
penambahan pada proses.
5. Memungkinkan untuk secara sistematis
mengontrol perubahan- perubahan yang terjadi
pada software selama proses pengembangannya.
Model Proses Cleanroom
Secara umum pendekatan dengan menggunakan
metodologi Cleanroom ini tidak begitu banyak yang
menggunakannya padahal saat awal penggunaannya
terhadap rekayasa perangkat lunak menunjukan hasil yang
memuaskan. Henderson [HEN95] mengemukakan tiga
alasan yang mungkin:
Cleanroom software engineering adalah salah satu
1. Kepercayaan bahwa metodologi cleanroom terlalu
pendekatan yang bertujuan untuk memenuhi
teoritis, terlalu matematis, dan terlalu radikal
kebutuhanakan software yang bebas dari kesalahan
2. Tidak membutuhkan unit pengetesan oleh
sejak proses pengembangan. Pendekatan Cleanroom
pengembang tetapi menggantinya dengan verifikasi
sendiri memilikisudut pandang yang berbeda dengan
kebenaran dan quality control statistikal—konsep yang
siklus klasik. Filosofinya adalah menghilangkan
sungguh asing bagi pengembangan software saat ini.
proses debugging yang memerlukan biaya cukup
3. Industri pengembangan software belum siap untuk
besar dengan meningkatan kebenaran penulisan kode
mengaplikasikan teknik ini.
sejak awal dan memverifikasinya kebenarannya
sebelum pengetesan dilakukan.
Model Proses Cleanroom Keunikan Cleanroom
Proses Cleanroom itu sendiri menggunakan teknologi- Perbedaan perekayasaan software cleanroom dengan
teknologi yang berbasis teori, seperti spesifikasi struktur perekayasaan software konvensional dan berorientasi
kotak dari fungsi pengguna arsitektur objek system, objek:
perancangan teoritis fungsi dengan verifikasi pembenaran, 1. Penggunaan secara eksplisit quality control statistikal
dan ujian pemakaian statistik untuk sertifikasi kualitas. 2. Pemverifikasian spesifikasi desain menggunakan bukti
kebenaran berbasis matematik
Manajemen Cleanroom berdasar kepada pembanguna 3. Sangat bergantung pada testing statistikal untuk
incremental dan sertifikasi dari sebuah garis menemukan error yang mungkin berakibat fatal
increment(peningkatan) fungsi pengguna yang bertumpuk 4. Meminimalkan peran unit testing dan debugging (dan
sedikit demi sedikit ke dalam produk akhir. Operasi- secara dramatis mengurangi aktivitas testing oleh
operasi Cleanroom dapat dikeluarkan dengan mudah oleh pengembang software)
tim pengembang independen dan tim sertifikasi dengan tim
dari tim-tim untuk proyek besar. Setelah setiap increment
tersertifikasi, kemudian semua increment tersebut
digabungkan. Urutan kerja cleanroom untuk setiap
increment diilustrasikan dalam gambar 1. Semua
requirement sistem dikembangkan dengan metode
perekayasaan sistem (system engineering methods). Ketika
fungsionalitas telah diberikan, pipeline increment
cleanroom dimulai.
PREDICTIVE MODEL

1. Waterfall
2. Waterfall With Feedback
3. Sashimi
4. Incremental Waterfall
5. V - Model
WATERFALL

Linear sequential model (atau disebut juga “classic life cycle” atau

“waterfall model”) adalah metode pengembangan perangkat lunak dengan
pendekatan sekuensial dengan cakupan aktivitas :

1. Rekayasa sistem dan Analisis (Sistem Engineering and Analysis) :

Karena perangkat lunak adalah bagian dari sistem yang lebih besar,
pekerjaan dimulai dari pembentukan kebutuhan-kebutuhan untuk
seluruh elemen sistem dan kemudian memilah mana yang untuk
pengembangan perangkat lunak. Hal ini penting, ketika perangkat
lunak harus berkomunikasi dengan hardware, orang dan basis data

2. Analisis kebutuhan perangkat lunak (Software Requirements

Analysis) : Pengumpulan kebutuhan dengan fokus pada perangkat
lunak, yang meliputi Domain informasi, fungsi yang dibutuhkan, unjuk
kerja/performansi dan antarmuka. Hasilnya harus didokumentasi dan
direview ke pelanggan
1. Perancangan (Design) : Ada 4 atribut untuk program yaitu : Struktur Data, Arsitektur perangkat lunak, Prosedur detil
dan Karakteristik Antarmuka. Proses desain mengubah kebutuhan-kebutuhan menjadi bentuk karakteristik yang
dimengerti perangkat lunak sebelum dimulai penulisan program. Desain ini harus terdokumentasi dengan baik dan
menjadi bagian konfigurasi perangkat lunak.
2. Pembuatan kode (Coding) : Penterjemahan perancangan ke bentuk yang dapat dimengerti oleh mesin, dengan
menggunakan bahasa pemrograman
3. Pengujian (Testing) : Setelah kode program selesai testing dapat dilakukan. Testing memfokuskan pada logika internal
dari perangkat lunak, fungsi eksternal dan mencari segala kemungkinan kesalahan dan memriksa apakah sesuai dengan
hasil yang diinginkan.
4. Pemeliharaan (Maintenance) : Merupakan bagian paling akhir dari siklus pengembangan dan dilakukan setelah
perangkat lunak dipergunakan. Kegiatan :
o Corrective Maintenance : Mengoreksi kesalahan pada perangkat lunak, yang baru terdeteksi pada saat perangkat
lunak dipergunakan
o Adaptive Maintenance : Penyesuaian dengan lingkungan baru, misalnya sistem operasi atau sebagai tuntutan atas
perkembangan sistem komputer, misalnya penambahanprinter driver
o Perfektive Maintenance : Bila perangkat lunak sukses dipergunakan oleh pemakai. Pemeliharaan ditujukan untuk
menambah kemampuannya seperti memberikan fungsi-fungsi tambahan, peningkatan kinerja dan sebagainya.
 Berikut merupakan keuntungan dan kerugian penggunaan model water fall :
Keuntungan:
Terstruktur
 Tiap tahap memiliki metode untuk menghasilkan
suatu dokumen yang bisa diserahkan ke pemakai
 Dokumen yang dihasilkan tiap tahap bisa di
spesifikasikan secara jelas dan mendetail
Kerugian:
 Linear, tidak ada umpan balik (feedback)
 Sumber daya dan penjadwalan harus di perkirakan pada
awal proyek
 Tahap terisolasi, kurang terjalin transisi ke tahap
berikutnya.  Akibat paling besar terasa pada tahap
requirement
 Pemakai tidak bisa melihat produk perangkat lunak
sampai akhir proyek
 Penekanan terbesar pada dokumen
WATERFALL WITH FEEDBACK
Dalam proyek pengembangan perangkat lunak praktis, model air terjun klasik
sulit digunakan. Jadi, model air terjun berulang dapat dianggap sebagai
memasukkan perubahan yang diperlukan untuk model air terjun klasik untuk
membuatnya dapat digunakan dalam proyek pengembangan perangkat lunak
praktis. Ini hampir sama dengan model air terjun klasik kecuali beberapa
perubahan dilakukan untuk meningkatkan efisiensi pengembangan perangkat
lunak.

Model air terjun iteratif memberikan jalur umpan balik dari setiap fase ke fase
sebelumnya, yang merupakan perbedaan utama dari model air terjun klasik.
Ketika kesalahan terdeteksi pada beberapa fase kemudian, jalur umpan balik
ini memungkinkan mengoreksi kesalahan yang dilakukan oleh programmer
selama beberapa fase. Jalur umpan balik memungkinkan fase untuk dikerjakan
ulang di mana kesalahan dilakukan dan perubahan ini tercermin dalam fase
selanjutnya. Tetapi, tidak ada jalur umpan balik ke tahap - studi kelayakan,
karena sekali proyek telah diambil, tidak mudah menyerah.
Adalah baik untuk mendeteksi kesalahan pada fase yang sama di mana mereka
berkomitmen. Ini mengurangi upaya dan waktu yang diperlukan untuk
memperbaiki kesalahan.
Fase Penahanan Kesalahan: Prinsip mendeteksi kesalahan sedekat mungkin
dengan poin komitmen mereka dikenal sebagai Fase penahanan kesalahan.
Keuntungan Model Air Terjun Iteratif
1. Jalur Umpan Balik: Dalam model air terjun klasik, tidak ada jalur umpan balik, sehingga tidak ada mekanisme untuk koreksi
kesalahan. Tetapi dalam jalur umpan balik model air terjun iteratif dari satu fase ke fase sebelumnya memungkinkan mengoreksi
kesalahan yang dilakukan dan perubahan ini tercermin dalam fase selanjutnya.
2. Sederhana: Model air terjun berulang sangat sederhana untuk dipahami dan digunakan. Itu sebabnya ini adalah salah satu model
pengembangan perangkat lunak yang paling banyak digunakan.
Kerugian dari Model Air Terjun Iteratif
1. Sulit untuk memasukkan permintaan perubahan: Kelemahan utama dari model air terjun iteratif adalah
bahwa semua persyaratan harus dinyatakan dengan jelas sebelum memulai tahap pengembangan.
Pelanggan dapat mengubah persyaratan setelah beberapa waktu tetapi model air terjun iteratif tidak
meninggalkan ruang lingkup untuk memasukkan permintaan perubahan yang dibuat setelah fase
pengembangan dimulai.
2. Pengiriman tambahan tidak didukung: Dalam model air terjun iteratif, perangkat lunak lengkap
dikembangkan dan diuji sepenuhnya sebelum dikirim ke pelanggan. Tidak ada ruang untuk pengiriman
perantara. Jadi, pelanggan harus menunggu lama untuk mendapatkan perangkat lunak.
3. Tumpang tindih fase tidak didukung: Model air terjun berulang mengasumsikan bahwa satu fase dapat
dimulai setelah selesainya fase sebelumnya, Tetapi dalam proyek nyata, fase mungkin tumpang tindih
untuk mengurangi upaya dan waktu yang dibutuhkan untuk menyelesaikan proyek.
4. Penanganan risiko tidak didukung: Proyek mungkin menderita berbagai jenis risiko. Namun, model air
terjun berulang tidak memiliki mekanisme untuk penanganan risiko.
5. Interaksi pelanggan terbatas: Interaksi pelanggan terjadi pada awal proyek pada saat pengumpulan
persyaratan dan pada penyelesaian proyek pada saat pengiriman perangkat lunak. Interaksi yang lebih
sedikit dengan pelanggan ini dapat menyebabkan banyak masalah karena perangkat lunak yang
dikembangkan akhirnya mungkin berbeda dari persyaratan aktual pelanggan.
SASHIMI
Model Sashimi. Jadi, dalam Model Sashimi idenya adalah bahwa kami
mengizinkan tumpang tindih berbagai fase siklus pengembangan perangkat
lunak. Misalnya, saat Anda mengerjakan persyaratan, alih-alih menunggu fase
persyaratan selesai, Anda akan mulai dengan desain saat persyaratan sedang
dibuat. Dan pada dasarnya, kami hanya akan mengatakan bahwa persyaratan
tidak dilakukan, bagaimana saya bisa mulai dengan desain? Nah, ketika Anda
melakukan persyaratan, Anda semacam membangun persyaratan untuk
bagian aplikasi dan sudah menjalankan persyaratan itu. Para arsitek atau
perancang mereka sebenarnya dapat mulai bekerja pada persyaratan yang
sudah dibuat. Jadi itulah bagaimana Anda bisa tumpang tindih fase yang
berbeda Model Sashimi. Demikian juga, sementara jika bagian dari aplikasi
adalah desain, Anda dapat memulai fase implementasi dan sebagainya. Jadi
ide utama di balik fase ini adalah bahwa fase berikutnya tidak harus
menunggu fase sebelumnya untuk memulai, kan? Anda tidak harus menunggu
fase sebelumnya selesai untuk memulai fase yang ada. Nah, jika Anda ingin
mempersingkat skala waktu Anda, maka Anda berpotensi menggunakan
model ini. Atau jika Anda memiliki semua sumber daya yang tersedia, dan
Anda ingin mereka segera memulai proyek, maka Anda juga dapat
menggunakan model ini untuk tumpang tindih dengan ini.
INCREMENTAL WATERFALL

Model incremental adalah metode pengembangan perangkat lunak di

mana produk dirancang, diimplementasikan, dan diuji secara bertahap
hingga produk selesai. Model ini menggabungkan elemen-elemen
model waterfall dengan filosofi iteratif dari prototyping. Ada banyak
situasi di mana kebutuhan perangkat lunak awal didefinisikan dengan
cukup baik, tetapi ruang lingkup keseluruhan dari upaya pengembangan
menghalangi proses yang murni linier. Selain itu, mungkin ada
kebutuhan yang mendesak untuk menyediakan seperangkat
fungsionalitas perangkat lunak yang terbatas kepada pengguna dengan
cepat dan kemudian memperbaiki dan memperluas fungsionalitas
tersebut dalam rilis perangkat lunak yang lebih baru. Dalam kasus
seperti itu, model yang dibutuhkan adalah model incremental.
Tahapan ini berlaku umum untuk semua model :
1. Komunikasi (communication) : membantu
memahami tujuan.
2. Perencanaan (planning): diperlukan karena
banyak orang (tim perangkat lunak) bekerja
pada proyek yang sama tetapi fungsinya
berbeda pada saat yang sama.
3. Pemodelan (modelling): melibatkan pemodelan
bisnis, pemodelan data, dan pemodelan proses.
4. Konstruksi (construction): melibatkan
penggunaan kembali komponen perangkat
lunak dan kode otomatis.
5. Penyebaran (deployment): integrasi semua
increment.
Kelebihan dan kekurangan model incremental
Kelebihan-kelebihan dari model incremental, yaitu
menghasilkan perangkat lunak yang berfungsi dengan cepat dan
lebih awal selama siklus hidup perangkat lunak, lebih fleksibel
dan lebih murah untuk mengubah ruang lingkup dan kebutuhan,
sehingga menurunkan biaya pengiriman awal. Selanjuntnya
model ini lebih mudah untuk melakukan pengujjian dan debug
selama iterasi yang lebih kecil. Kemudian pelanggan dapat
merespons masing-masing build. Yang terakhir adanya
kemudahan untuk mengelola risiko karena potongan berisiko
diidentifikasi dan ditangani selama iterasi. Adapun kelemahan
dari model incremental ini, antara lain membutuhkan desain dan
rencana yang baik, membutuhkan definisi keseluruhan sistem
yang lengkap sebelum dipecah menjadi beberapa increment, dan
total biayanya lebih banyak dari pada model waterfall.
V - MODEL

Merupakan model pengembangan perangkat lunak yang

didasarkan pada hubungan antara setiap fase
pengembangan siklus hidup yang tercantum dalam model
Watterfall yang merupakan pengembangan perangkat
lunak dan fase yang terkait pengujian. Bisa dikatakan
model ini merupakan perluasan dari model waterfall.
Disebut sebagai perluasan karena tahap-tahapnya mirip
dengan yang terdapat dalam model waterfall. Jika dalam
model waterfall proses dijalankan secara linear, maka
dalam model V proses dilakukan bercabang.
 Tahapan dalam  V Model

Tahap Verfiikasi mengacu kepada usaha penyesuaian spesifikasi software dengan kebutuhan klien/konsumen,
tahapan ini meliputi serangkaian kegiatan sebagai berikut:
1. Business Case: Merupakan tahapan awal yang menggambarkan kebutuhan/harapan konsumen terhadap
sistem yang akan dikembangkan, termasuk manfaat sistem terhadap konsumen dan perkiraan biaya yang
harus disediakan.
2. Requirement: pada fase ini klien mendapatkan gambaran atau diminta memberikan gambaran kebutuhan
yang diharapkan dapat dipenuhi oleh software, baik kebutuhan fungsional maupun non fungsional.
3. Analisis Informasi: Setelah diperoleh spesifikasi sistem dari fase requirement, selanjutnya aktivitas
difokuskan bagaimana cara kerja software untuk memenuhi kebutuhan tersebut, termasuk metode,
hardware dan software apa saja yang diperlukan untuk mencapai kebutuhan yang sudah didefinisikan.
4. Perancangan Sistem: pada tahapan ini akan dibuat rancangan software secara lebih terinci sesuai
spesifikasi yang sudah disepakati.
5. Unit Design: merancang setiap elemen/unit software termasuk rancangan modul/program, antarmuka,
database dan lain-lain.
6. Development: merealisasikan hasil rancangan menjadi satu aplikasi/program tertentu.
Tahapan Validasi merupakan serangkaian tahapan yang mengacu kepada kesesuaian software dengan spesifikasi
yang sudah ditetapkan. Tahapan ini dicapai melalui serangkaian pengujian/testing sebagai berikut:
1. Unit test: menguji setiap komponen/unit program apakah sesuai dengan rancangan unit yang sudah ditetapkan.
Secara teoritis seharusnya pengujian dilakukan oleh orang tertentu yang bertugas sebagai software tester, tetapi
dalam kenyataannya seringkali unit testing dilakukan oleh programmer sendiri.
2. Interface test: setelah semua komponen diuji secara terpisah, tahapan selanjutnya dilakukan interface test untuk
melihat sejauh mana setiap komponen dapat berinteraksi satu sama lain sesuai dengan fungsi yang diharapkan.
3. System test: setelah semua interface berjalan dengan baik, selanutnya dilakukan system test untuk melihat
sejauh mana sistem/software dapat memenuhi kebutuhan secara keseluruhan. System testing bersifat
menyeluruh dan tidak dapat dilakukan berdasarkan fungsionalitas sistem yang diuji secara terpisah. Aktivitas
pada system testing termasuk melakukan pengujian hal-hal berikut:
 Performance – apakah kinerja sistem sesuai dengan target yang sudah didefinisikan sebelumnya.
 Volume – apakah software/sistem dapat menampung volume informasi yang cukup besar.
 Stress – apakah software/sistem dapat menampung sejumlah informasi pada waktu-waktu
tertentu.
 Documentation – apakah semua dokumentasi penting sudah disiapkan.
 Robustness – apakah software/sistem cenderung stabil pada berbagai kondisi diluar
dugaan/ekstrim.
3. Acceptance test merupakan aktivitas untuk menguji sejauh mana sistem/software dapat membantu
memecahkan business case, dalam artian apakah sistem/software tersebut sudah sesuai dengan harapan
konsumen/klien dan sejauh mana manfaat sistem/software ini bagi klien. Test ini sering kali disebut
sebagai User Acceptance Test (UAT).
4. Release testing: test ini dilakukan untuk menguji sejauh mana sistem/software dapat mendukung aktivitas
organisasi dan berjalan dengan harmonis sesuai dengan kegiatan rutin organisasi. Beberapa pertanyaan
coba dijawab pada fase ini misalnya apakah software tersebut mempengaruhi sistem lain? Apakah
software tersebut kompatibel dengan sistem lain? Bagaimana kinerja sistem sebenarnya di dalam
organisasi?
 Kelebihan V model
Kekuranagn V model
1. V model sangat fleksibel. V model ini bisa
1. V model hanya bisa digunakan sekali dalam suatu proyek
digunakan untuk project tailoring serta
hal tersebut disebabkan kerena V model merupakan model
penambahan pengurangan method dan tool
yang project oriented.
secara dinamik.
2. V model bersifat terlalu fleksibel sehingga mengakibatkan
2. V model dikembangkan dan di maintain oleh
beberapa aktivitas-aktivitas yang digambarkan dalam V
publik. User dari V model berpartisipasi dalam
model menjadi terlalu abstrak. Hal tersebut mengakibatkan
change board yang memproses semua change
tidak bisa diketahui dengan jelas apa yang termasuk dalam
request terhadap V model.
activity tersebut dan apa yang tidak.

Dimana saja V Model Diterapkan?

1. Dalam proyek teknologi informasi di Jerman.
2. V Model dibandingkan dengan CMM.
3. V Model didesain untuk mengembangkan sistem yang didalamnya terdapat dua komponen.
4. Pengembangan V Model dalam bidang industri dapat dilakukan dengan mudah.
MODEL RAPID APPLICATION DEVELOPMENT (RAD)

RAD merupakan singkatan dari Rapid Application Development.

Metode ini juga menggunakan pendekatan iteratif dan
inkremental, tetapi lebih menekankan pada tenggat waktu dan
efisiensi biaya yang sesuai dengan kebutuhan. 

Kekurangan model RAD :

1. Butuh orang banyak untuk menyelesaikan sebuah proyek berskala
besar.
2. Pengembang dan customer harus punya komitmen yang kuat untuk
Kelebihan Model RAD : menyelesaikan sebuah software.

1. Cocok untuk proyek yang memerlukan waktu 3. RAD tidak cocok digunakan untuk sistem yang mempunyai resiko
yang singkat teknik yang tinggi.

2. Lebih efektif dan pendekatan waterfall/sequential 4. Jika sistem tidak dibangun dengan benar maka RAD akan bermasalah.
linear dalam menghasilakn sistem yang 5. Jika ada peubahan di tengah-tengah pengerjaan maka harus membuat
memenuhi kebutuhan langsung dari pelanggan. kontrak baru antara pengembang dan customer.
Agile Agile adalah sebuah metode software development yang mencakup
website, web application, dan mobile application yang berfokus untuk
menghasilkan software berkualitas tinggi secara konsisten dengan mengurangi
biaya proyek dan meningkatkan nilai jual suatu bisnis. Secara definisi, Agile
dapat diartikan sebagai sebuah pendekatan pada project management dengan
menggunakan teknik iterasi dan bertahap secara dinamis (atau dikenal
dengan Sprint) dalam proses pembuatan suatu produk.

Kelebihan dari agile

Kekurangan dari agile

1. Dapat melakukan review pelanggan mengenai

1. Pengembang harus selalu siap dengan perubahan
software yang dibuat lebih awal.
karena perubahan akan selalu diterima.
2. Pembangunan system dibuat lebih cepat.
2. Agile tidak akan berjalan dengan baik jika
3. Perubahan dengan cepat ditangani komitmen tim kurang.

4. Jika pada saat pembangunan system terjadi 3. Tidak cocok dalam skala tim yang besar (>20
kegagalan kerugian dari segi materi relatif kecil. orang).
Extreme Programming (XP)

Extreme Programming adalah suatu model yang termasuk dalam pendekatan agile yang

diperkenalkan oleh Kent Back. Menurut penjelasannya, definisi XP adalah sebagai
berikut: “Extreme Programming (XP) adalah metode pengembangan software yang cepat,
efisien, beresiko rendah, fleksibel, terprediksi, scientific, dan menyenangkan.“.

Pair Programming
Semua perangkat lunak yang dibangun dengan pendekatan XP dibangun oleh dua orang programmer. Keduanya duduk berdampingan di
satu komputer yang sama. Seorang programmer akan membuat code dan programmer yang lainnya akan mengoreksinya. Praktik seperti
ini mungkin kelihatan tidak efisien. Namun dari segi hasil dari pair programming, desain akan lebih baik, pengujian lebih baik, dan code
yang dihasilkan pun akan lebih baik.

Test-Driven Development
XP begitu terobsesi dengan umpan balik, dan dalam pengembangan perangkat lunak, umpan balik yang baik mensyaratkan pengujian
yang baik pula. Test-Driven Development bergantung pada pengulangan siklus development yang sangat pendek. Pertama tim XP akan
menuliskan automated test case yang mendefinisikan perbaikan yang diinginkan atau fungsi baru. Kemudian dari test case tersebut
dihasilkan jumlah minimal code yang harus dituliskan untuk lulus tes tersebut. Setelah itu melakukan refactoring code baru agar
memenuhi standar baru.
Continuous Integration
Beberapa kali dalam sehari, tim XP akan menggabungkan seluruh salinan pekerjaan tim menjadi satu dalam jaringan utama.
Sehingga tim XP harus menjaga tim agar terintegrasi setiap saat.

Design Improvement
XP berfokus pada memberikan nilai bisnis dalam setiap perulangan. Agar dapat mencapai tujuan tersebut selama proyek berlangsung,
perangkat lunak harus dirancang dengan baik. XP menggunakan proses perbaikan desain secara terus menerus dengan Refactoring.
Proses refactoring berfokus pada penghapusan duplikasi dari code yang telah dibuat. Disamping itu, proses refactoring didukung
dengan pengujian yang komprehensif utnuk memastikan bahwa desain yang dibuat berkembang dan tiidak ada yang rusak.

Kelebihan Extreme Programming, yaitu: Kelemahan Extreme Programming, yaitu:

1. Meningkatkan kepuasan kepada klien 1. Cerita-cerita yang menunjukkan requirements dari pelanggan
kemungkinan besar tidak lengkap sehingga Developer harus selalu
2. Pembangunan system dibuat lebih cepat siap dengan perubahan karena perubahan akan selalu diterima.
3. Menjalin komunikasi yang baik dengan client.
2. Tidak bisa membuat kode yang detail di awal
4. Meningkatkan komunikasi dan sifat saling (prinsip simplicity dan juga anjuran untuk melakukan apa yang
menghargai antar developer. diperlukan hari itu juga).
3. XP tidak memiliki dokumentasi formal yang dibuat selama
pengembangan. Satu-satunya dokumentasi adalah dokumentasi
awal yang dilakukan oleh user.
Dynamic System Development Method (DSDM) 

- Dynamic System Development Method (DSDM) adalah sebuah

kerangka kerja yang mengutamakan keterlibatan pengguna secara
berkesinambungan dengan pendekatan pengembangan secara berulang
dan bertambah, yang menangani proyek secara efektif dan efisien.
DSDM memfasilitasi sebuah kerangka kerja untuk mengembangkan
fungsi dengan cara yang lebih baik, memberikan fungsionalitas secara
efisien dan efektif, dan memenuhi kebutuhan yang nyata dari suatu
projek.

Kelebihan
1. Menyajikan kerangka kerja (framework) untuk
membangun dan memelihara sistem dalam waktu yang
terbatas melalui penggunaan prototyping yang
incremental dalam lingkungan yang terkondisikan.
2. Membangun software dengan cepat.
3. DSDM dapat dikombinasikan dengan XP menghasilkan
kombinasi model proses yang mengikuti DSDM dan
praktek yang sejalan dengan XP.
Kekurangan
1. Setiap iterasi bergantung pada prototype sebelumya.
2. Menentukan scope dari suatu prototype proyek tidak pernah
selesai.
3. Dokumentasi sering kali tidak lengkap fokus pada
pembuatan prototype.
4. Isu-isu mengenai system backup and recovery, system
performance dan system security kurang/tidak diperhatikan
dan sering terlupakan.
 Scrum adalah sebuah metode iteratif yang termasuk dalam metode
Agile tentang bagaimana cara Anda mengelola dan menjalankan
sebuah proyek. Ini bisa digunakan untuk mengelola segala jenis proyek
mulai dari pembuatan software, website, hardware, marketing, event
planning, dan sebagainya. Scrum membantu Anda untuk mengorganisir
sebuah tim dan Anda harus memiliki komunikasi yang kuat antar member
tim tersebut. Scrum mengatakan bahwa setiap “sprint” dimulai dengan
meeting singkat untuk perencanaan dan diakhiri dengan review. Ini adalah
ide fundamental dari Scrum untuk sebuah project management.
Scrum
Kelebihan SCRUM
1. SCRUM dapat membantu perusahaan Anda dalam menghemat waktu 6. Dengan adanya short sprint dan constant feedback, SCRUM dapat
dan biaya (dalam hal ini uang). Biaya overhead dari proses dan dengan mudah mengatasi setiap perubahan yang terjadi.
manajemen sangat minim sehingga dapat mengarahkan kita kepada 7. Dengan adanya daily scrum meeting, memungkinan SCRUM untuk
hasil yang lebih cepat dan lebih murah. mengukur produktvitas individu, hal ini mengarah pada
2. Dengan menggunakan metode SCRUM, Anda dapat
peningkatan produktivitas dari setiap anggota tim.
mentranformasikan bisnis yang sulit untuk diukur menjadi mudah
untuk dikembangkan. 8. Dengan SCRUM, setiap ada masalah yang timbul dapat di
3. Pada metode SCRUM, pergerakan pengembangan cutting edge dapat identifikasi dengan baik pada pertemuan harian dan oleh karena itu
dengan cepat dikodekan dan diuji menggunakan metode ini. setiap masalah dapat di selesaikan dengan cepat.
Bagaikan kesalahan yang mudah untuk diperbaiki. 9. Dengan menggunakan metode SCRUM, Anda dapat dengan mudah
4. Dengan menggunakan SCRUM, Anda dapat mengontrol dan untuk mengirim produk berkualitas sesuai dengan waktunya.
memonitoring aktivitas peningkatan dan penurunan beban pekerjaan 10. SCRUM dapat bekerja dengan berbagai teknologi dan bahasa
yang bisa terjadi kapan saja.
pemrograman. Namun secara khusus berguna untuk pengembangan
5. Seperti metodologi agile pada umumnya, SCRUM merupakan
metode iterative yang membutuhkan feedback secara berkelanjutan proyek dengan teknologi web 2.0 ataupun media proyek baru
dari user atau pengguna. lainnya.
Kekurangan SCRUM

1. SCRUM bisa menjadi salah satu penyebab utama terjadinya scope creep, kecuali ada tanggal akhir
tertentu. Stakeholder proyek atau manajemen akan terus menuntut fungsi dan fitur baru untuk
disampaikan.
2. Setiap tugas harus didefinisikan dengan baik, karena hal ini dapat mempengaruhi perkiraan biaya dan
waktu pengerjaan proyek. Jika tidak didefinisikan dengan baik maka semua hal tersebut tidak akan
akurat. Dalam kasus seperti ini, biasanya tugas dapat tersebar di beberapa sprint.
3. Jika anggota tim Anda tidak berkomitmen dengan baik, maka proyek Anda tidak akan selesai atau
bahkan bisa gagal.
4. Metode SCRUM ini hanya membutuhkan anggota tim yang sudah berpengalaman, jika tim Anda
berisi orang-orang yang masih pemula maka proyek tidak dapat selesai sesuai dengan waktunya.
5. SCRUM dapat bekerja dengan baik jika seorang Scrum Master dapat mempercayai tim yang mereka
kelola. Jika Scrum Master terlalu mengontrol secara ketat, hal ini dapat menyebabkan tim menjadi
tertekan dan stress, sehingga mengakibatkan demoralisasi dan kegagalan dari proyek tersebut.
6. Jika sering terjadi pergantian anggota tim saat pengembangan proyek berlangsung, hal ini dapat
menyebabkan efek yang kurang baik bagi perkembangan proyek tersebut, proyek akan semakin lama
selesai dari waktunya.
Kanban
Kanban adalah framework yang sangat baik bila digunakan
untuk proses kontinyu atau rilis produk harian. Ia juga baik
untuk diterapkan dalam proyek-proyek pemeliharaan
(maintenance). Kanban memiliki ciri-ciri alur kerja yang
tervisualisasi (visualized workflow), tugas yang dipecah
menjadi item-item diskrit, progres kerja yang dibatasi, dan
pengaturan tugas-tugas dari backlog.

Kanban suatu metode untuk menvisualisasikan proses perkerjaan yang dilakukan saat kita sedang
mengembangkan suatu Software. Team member dapat Menarik/Pull tugas yang harus diselsaikan dan
bukan mendorong atau didorong oleh suatu tugas. Dengan menggunakan metode ini, kita dapat menjaga
keseimbangan antara perkerjaan team member yang satu, dengan team member yang lainya. Metode ini
juga dapat melacak Bottleneck dalam pengembangan aplikasi. Untuk mengetahu lebih lanjut
tentang Kanban pertama kita harus mengerti tentang proses Agile development berkerja.
Kelebihan :
1. Membatasi work in progress (WIP) ke area yang
paling penting untuk menjaga jumlah perubahan
seminimal mungkin pada waktu tertentu dan
mempercepat proses pengembangan.
2. Hampir tidak ada investasi untuk alat atau pelatihan
tambahan untuk tim developer.
3. Menggunakan hal yang sederhana seperti sticky
notes dan papan tulis sebagai cara untuk visualisasi
membantu menjaga denyut nadi perkembangan
produk.
Kekurangan :
1. Sticky notes tidak dapat memprediksi jangka
waktu, sehingga tidak cocok untuk proyek jangka
panjang.
2. Walaupun menyederhanakan WIP, Kanban tidak
baik untuk perencanaan dan dapat sepenuhnya
dirombak oleh model lain, seperti Scrum. Akan
tetapi, Kanban bekerja paling baik di atas Lean
atau Scrum, hanya menunjukkan aliran
perkembangan dan membantu menghindari
kemacetan di dalamnya.
Feature Driven Development (FDD) 
Feature Driven Development (FDD) merupakan proses
yang didesain dan dilaksanakan untuk menyajikan hasil
kerja secara berulang-ulang dalam waktu tertentu dan dapat
diukur.

FDD merupakan pendekatan yang mengacu pada

pembuatan sistem menggunakan metode yang mudah
dimengerti dan diimplementasikan, teknik problem solving,
dan pelaporan yang mudah dimengerti dan dikontrol oleh
stakeholders.

Dengan metode FDD, tim pengembang diberikan informasi yang cukup dan alat bantu untuk menyelesaikan
proyek. Pemimpin proyek dan manajer diberikan informasi berdasarkan waktu mengenai tim dan proyek yang
sedang berjalan untuk menghindari risiko yang terjadi. Pelaporan menjadi lebih mudah, tidak membebani,
periodik, dan akurat.

Pengguna juga dapat secara langsung melihat bagian mereka sebagai hasil progress proyek dan
memberikan feedback dalam tahap pengembangan yang bertujuan untuk menciptakan sistem sesuai keinginan
klien.
Kelebihan
• Tangible results rather than process pride.
Proses dalam metode FDD mengutamakan sesuatu yang dapat
diukur ketimbang proses-proses perancangan yang rumit dan
menghabiskan waktu, sumber daya, dan biaya. Pada saat merancang
proyek, penjadwalan langsung diarahkan ke dalam bentuk fitur.
• A system for building system is necessary.
Sistem yang dibangun harus rapi dan kuat agar para pengembang
dapat bekerja dan menghasilkan sebuah sistem yang diharapkan
oleh klien.
• Simple is better.
Perancangan dibuat sesederhana mungkin, tetapi dapat memenuhi
semua persyaratan yang diberikan oleh klien sehingga mereka
mendapatkan gambaran sistem dengan mudah.
• Process steps should be obviously valuable to each team member.
Setiap langkah atau proses selama pengembangan sistem harus
dapat dinilai dan terukur bagi para pengembang sistem. Selain itu,
desain kode juga menjadi lebih mudah dan efektif pada saat
pemeriksaan.
• Good processes move to the background.
Semua proses lebih baik dikerjakan di belakang sehingga
pengerjaan dengan metode FDD terlihat lebih sederhana.
Kekurangan
 Membutuhkan jumlah pekerja yang banyak (10-250 orang)
yang dibagi ke dalam beberapa divisi. Semakin banyak
pekerja, biaya yang dikeluarkan semakin tinggi.
 Lebih menekankan pengembang dengan keterampilan tinggi
dan sulit untuk mencari pengembang dengan kriteria
tersebut.
 Dalam FDD terdapat class owner yang menangani setiap
fitur. Masalahnya adalah ketika fitur A memiliki dependensi
terhadap fitur B dan fitur B mengalami perubahan, fitur A
harus menunggu kepastian dari fitur B yang menyebabkan
mundurnya jadwal proyek.
Pada intinya, FDD bersifat individual, maka dapat terjadi
saling tunggu antar fitur yang terkait. FDD membatasi
penambahan fitur kurang dari 10% dari total waktu, biaya,
dan kualitas. Perubahan fitur hanya dilakukan pada sebuah
proses dan keterlibatan klien hanya pada beberapa tahapan.
 Jumlah jam kerja FDD tidak terikat sehingga dapat
menyebabkan para pengembang tidak bekerja
secara optimal di pertengahan, tetapi pada akhir jadwal
mereka akan bekerja lebih ekstra.
 Agile Unified Process (AUP
Agile Unified Process (AUP) adalah versi sederhana dari Rational Unified
Process (RUP) yang dikembangkan oleh Scott Ambler. AUP menjelaskan
pendekatan yang sederhana, mudah dipahami untuk mengembangkan
perangkat lunak aplikasi bisnis menggunakan teknik dan konsep agile namun
masih tetap berlaku untuk RUP. Pendekatan ini menerapkan teknik agile,
termasuk Test-driven Development (TDD), Agile Model Driven Development
(AMDD), agile change management, dan refactoring database untuk
meningkatkan produktivitas[1]. Agile Unified Process (AUP) mengadopsi
filosofi “serial in the large” dan “iterative in the small” [1]untuk membangun
sistem berbasis komputer.

Dengan mengadopsi tahapan kegiatan klasik Unified Process — permulaan (inception), elaborasi (elaboration),
konstruksi (construction), dan transisi (transition) — AUP menyediakan lapisan serial (mis., Urutan linier kegiatan
rekayasa perangkat lunak) yang memungkinkan tim memvisualisasikan alur proses keseluruhan untuk proyek perangkat
lunak. Namun, dalam setiap kegiatan, tim melakukan iterasi untuk mencapai agility dan untuk memberikan software
increment yang bermakna kepada pengguna akhir secepat mungkin.
Kelebihan
Kekurangan

·    Meningkatkan kepuasan kepada klien.

·   Developer harus selalu siap dengan perubahan karena
·    Dapat melakukan review pelanggan mengenai software
perubahan akan selalu diterima.
yang dibuat lebih awal.
·     Agile tidak akan berjalan dengan baik jika komitmen tim
·    Pembangunan system dibuat lebih cepat.
kurang.
· Mengurangi resiko kegagalan implementasi software
·     Tidak cocok dalam skala tim yang besar (>20 orang).
dari segi non-teknis.
·     Perkiraan waktu release dan harga perangkat lunak sulit
· Jika pada saat pembangunan system terjadi kegagalan
ditentukan
kerugian dari segi materi relatif  kecil  
 
 Metode Crystal adalah sebuah keluarga merodologi (keluaga kristal)
yang dikembangkan oleh yang dikembangkan oleh Alistair Cockburn
pada pertengahan 1990-an. Keluarga Crystal adalah cara cockburn untuk
katalogisasi apa saja yang mereka lakukan yang membuat project
menjadi sukses.
Metodologi Crystal diangap “metodologi ringan”. Penggunaan kata
Crystal berasal dari batu permata. Dalam hal perangkat lunak, tampilan
merupakan sebuah pandangan yang berbeda pada inti yang mendasari
prinsip dan nilai – nilai. Tampilan adalah representasi dariteknik, alat,
standar, dan peran.
Crystal
Karakteristik Crystal :
1. Secara aktual sebuah model proses keluarga yang memungkinkan manuver
berdasar karakteristik permasalahan
2. Menyarankan penggunaan workshop refleksi untuk review kebiasaan kerja
tim
3. Selalu murah dan cepat berkomunikasi secara langsung.
4. Proyek berkembang sesuai ukuran team menjadi lebih atau luas dan metologi
akan menjadi lebih tinggi.
LEAN
Lean software development adalah suatu proses engineering yang digunakan
untuk mengembangkan dan menghasilkan suatu software berkualitas tinggi
yang telah terjamin kehandalannya sehingga tidak terjadi kegagalan dalam
penggunaan software tersebut. Lean software development ini berpedoman pada
pemahaman lapangan dan kesesuaian pelaksanaan prinsip  lean disepanjang
seluruh proses pengembangan software. Slogan yang dipakai yaitu berpikir
besar, bertindak kecil, gagal cepat, belajar cepat.
 
Kelebihan
• Proyek sangat bergantung pada tim yang saling
• Mengeliminasi Ketidak Effisienan membantu
bekerjasama dan berkomitmen pada proyek
mempercepat proses, menghemat sumberdaya dan
efisiensi • Customer harus mengetahui apa yang mereka butuhkan
dan tidak bisa mengubah setelah mereka membuat
• Membantu memberikan produk lebih awal
sebuah keputusan
• Kekuatan tim membantu dalam membuat
• Kita membutuhkan sebuah tim yang kemampuannya
keputusan antara tim dan memotivasi tim
saling melengkapi
Kekurangan
• Time limit yang dapat berubah-ubah akibat adanya hal yang tidak sesuai
rencana
• Kebutuhan biaya dapat membesar apabila semakin banyak perubahan yang
dilakukan sebab dalam metode ini kelebihan waktu menjadi tanggungan
client.