Rifqi Rahmatika Az-Zahra (12650112)

Laila Nur Shoima (12650038)

Erik Hendara Kurniawan (12650036)
 XP
Pengertian
ASD
Sejarah

Agile DSDM
Pengembangan
Development Agile
SCRUM
Manfaat
RUP
karakteristik
Crystal
Prinsip-prinsip
FDD
Agile Model
Proses
AM
◦ Agile Development Methods adalah sekelompok metodologi
pengembangan perangkat lunak yang didasarkan pada prinsip-
prinsip yang sama atau pengembangan sistem jangka pendek yang
memerlukan adaptasi cepat dari pengembang terhadap perubahan
dalam bentuk apapun. Agile development methods merupakan
salah satu dari Metode pengembangan perangkat lunak yang
digunakan dalam pengembangan perangkat lunak.
◦ Agile memiliki pengertian bersifat cepat, ringan, bebas bergerak,
dan waspada. Sehingga saat membuat perangkat lunak dengan
menggunakan agile development methods diperlukan inovasi dan
responsibiliti yang baik antara tim pengembang dan klien agar
kualitas dari perangkat lunak yang dihasilkan bagus dan kelincahan
dari tim seimbang.
 Pada tahun 1970, Dr Winston Royce mempresentasikan makalah berjudul
"Mengelola Pengembangan Perangkat Lunak Sistem Besar," yang mengkritik
pembangunan berurutan.

 The Agile Manifesto diperkenalkan istilah pada tahun 2001. Sejak itu, Agile Movement,
dengan segala nilai-nilai, prinsip, metode, praktek, alat-alat, juara dan praktisi, filosofi
dan budaya, secara signifikan mengubah lanskap modern reakayasa perangkat dan
perangkat lunak komersial pembangunan di era Internet.

 Pada bulan Februari 2001, 17 pengembang perangkat lunak bertemu di Snowbird

,Utah resort, mendiskusikan metode pengembangan ringan. Mereka menerbitkan
Manifesto untuk Agile Software Development .
Berikut adalah ekosistem dari pengembangan
perangkat lunak tangkas (agile) :
 Perspektif chaordic ,
 Nilai – nilai Collaborative dan prinsip-prinsip ,
 Metodologi yang memadai.
Pada dasar nya pengembangan tangkas
(agile), mempunyai beberapa poin pokok
pendekatan, sebagai berikut :

 Solusi yang sesuai dengan setiap

permasalahan yang terjadi.
 Strategi – strategi cadangan berdasarkan
permasalahan.
 Menciptakaan perubahan.
 Menanggapi dan memberikan solusi pada
suatu perubahan.
 Mengambil keputusan sesuai kondisi
dengan cepat.
 Sebuah perspektif chaordic muncul dari
pengakuan dan meningkatnya penerimaan
dalam ketidakpastian perekonomian kami yang
bergejolak. Dua konsekuensi konkret mencoba
untuk mengelola dalam lingkungan yang tak
terduga adalah tujuan sementara yang dapat
dicapai, rincian proyek sering tidak terduga,
dan bahwa dasar dari banyak proses-driven
pendekatan (tujuan berulang proses) tidak bisa
dicapai.
 Gaya chaordic Hock ini mirip dengan apa
yang disebut kepemimpinan kolaborasi atau
manajemen adaptif, yang berbicara tentang
menciptakan suatu lingkungan dengan berbagai
kondisi yang diperlukan untuk memenuhi
tantangan proyek yang ekstrim, khususnya
tantangan perubahan tingkat tinggi.
Manajer Agile memahami bahwa menuntut
kepastian dalam menghadapi ketidakpastian
disfungsional. Mereka menetapkan tujuan dan
kendala yang memberikan batas-batas dalam
dimana kreativitas dan inovasi dapat berkembang.
Mereka adalah macromanagers dari pada
micromanagers.
 Metodologi dirancang untuk membakukan orang
untuk proses, sedangkan proses tangkas dirancang
untuk memanfaatkan masing-masing individu dan
kekuatan unik masing-masing tim.
 Organisasi Agile fokus pada bangunan keterampilan
individu dan membina tingkat interaksi antara
anggota tim dan pelanggan proyek.
 Organisasi Agile percaya bahwa dengan proyek-
proyek yang kompleks saat ini, pemahaman akan
lebih didapatkan dari interaksi face – toface dari pada
dokumentasi.
 Organisasi Agile tidak percaya bahwa ketergantungan
pada proses berat membuat untuk kurangnya
keterampilan, bakat, dan pengetahuan.
 Untuk lincah, kita harus menyeimbangkan
fleksibilitas dan struktur, dan nyaris tidak
memadai tidak berarti tidak cukup. kecukupan
Bare mengurangi biaya melalui perampingan
tetapi bahkan lebih penting lagi , itu
menggabungkan perspektif chaordic bahwa
kreativitas dan inovasi terjadi dalam lingkungan
yang sedikit berantakan, bukan yang terutama
terstruktur. Terlalu banyak organisasi beroperasi
pada asumsi tak terucapkan bahwa "jika sedikit
proses yang baik, maka banyak proses akan lebih
baik ."
 Metodologi pengembangan Agile memberikan kesempatan
untuk menilai arah proyek melalui siklus pengembangan

 Dengan berfokus pada pengulangan siklus kerja disingkat serta

produk fungsional mereka menghasilkan, metodologi tangkas
digambarkan sebagai "berulang" dan "incremental.“

 Dalam paradigma tangkas, setiap aspek persyaratan

pembangunan, desain, dll terus ditinjau kembali selama
pemakaian.
 Respon yang efektif, cepat dan adaptif terhadap perubahan
 Komunikasi yang efektif diantara stakeholder
 Menggambarkan kebutuhan customer terhadap tim
 Mengorganisasikan tim sehingga performansi kerja berada dalam
control.
 Cepat, pertambahan delivery software
 Menghilangkan gap antara developer dan customer
 Menekankan pentingnya delivery secara cepat dari software
operasional dan menekankan pentingnya diantara work product
1.Kepuasan pelanggan dengan pengiriman cepat dari perangkat lunak yang
berguna.

2. Adanya perubahan kebutuhan bahkan larut dalam pembangunan .

3.Kerja perangkat lunak sering disampaikan (minggu, bukan bulan) .

4.Software yang Bekerja adalah ukuran utama dari kemajuan .

5.Pembangunan berkelanjutan, mampu mempertahankan kecepatan konstan

6. kerjasama harian antara orang-orang bisnis dan pengembang

7.Face-to-face percakapan adalah bentuk terbaik dari komunikasi (co-
location)

8.Proyek yang dibangun di sekitar individu termotivasi, siapa yang harus

dipercaya

9.Memperhatikan keunggulan teknis dan desain yang baik terus menerus

10.Kesederhanaan seni memaksimalkan jumlah pekerjaan tidak dilakukan-

sangat penting

11.Tim yang mengatur dirinya sendiri

12.Adaptasi biasa untuk mengubah keadaan

 Didorong oleh deskripsi dari kebutuhan pelanggan
(skenario)

 Mengenali bahwa rencana memiliki durasi yang pendek

 Pengembang perangkat lunak secara iteratif dengan lebih

menekankan pada kegiatan pengembangan

 Bertambahnya delivery perangkat lunak secara increment

 Adaptasi terhadap perubahan yang sering terjadi

Aktifitas framework (terhadap pembangunan dan
delivery).
o Komunikasi Customer
o Planning
o Modeling
o Construction
o Delivery
o Evaluation
 Extreme Programming (XP)

 Adaptive Software Development (ASD)

 Dynamic Systems Development Method (DSDM)

 Scrum

 Crystal

 Feature Driven Development (FDD)

 Agile Modeling (AM)

Model Proses AGILE
 XP merupakan suatu model yang tergolong
dalam pendekatan agile yang diusulkan oleh
Kent Back.

 definisi XP adalah sebagai berikut: "Extreme

Programming (XP) is a lightweight, efficient,
low-risk, flexible, predictable, scientific, and
fun way to develop software“

 Model ini cenderung menggunakan

pendekatan Object-Oriented
 Aktifitas Perencanaan : pengumpulan user stories dari klien yang klien
tetapkan prioritasnya. Setiap story ditetapkan harga dan lama
pembangunan, jika terlalu besar, story dapat dipecah menjadi
beberapa story yang lebih kecil. Periksa dan pertimbangkan resiko.
 Aktifitas Desain: berprinsip: sederhana.Memanfaatkan kartu CRC
(Class-Responsibility-Collaborator) untuk identifikasi dan mengatur
class-class di konsep OO. Jika temui kesulitan, prototype dibangun [ini
namanya spike solution]. Lakukan refactoring, yaitu mengembangkan
desain dari program setelah ditulis
 Aktifitas Pengkodean: siapkan unit test sebelum pengkodean dipakai
sebagai fokus pemrogram untuk membuat program. Pair programming
dilakukan untuk real time program solving dan real time quality
assurance
 Aktifitas Pengujian: menggunakan unit test yang dipersiapkan sebelum
pengkodean.
XP tepat digunakan saat kondisi
 Keperluan berubah dengan cepat
 Resiko tinggi dan ada proyek dengan tantangan yang bar
 Tim programmer sedikit, yaitu 2-10 orang
 Mampu mengotomatiskan tes
 Ada peran serta pelanggan secara langsung
Kelemahan XP:
 Cerita-cerita yang menunjukkan requirements kemungkinan
besar tidak lengkap sehingga 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).
 XP tidak memiliki dokumentasi formal yang dibuat selama
pengembangan. Satu-satunya dokumentasi adalah dokumentasi
awal yang dilakukan oleh user.
 ASD merupakan suatu model yang tergolong dalam
pendekatan agile yang diusulkan oleh Jim Highsmith

 ASD menggunakan tools yang disebut "time-boxing"

- yaitu berupa aktifitas yang menentukan jangka
waktu tertentu yang dialokasikan untuk
menyelesaikan berbagai macam tugas.

 ASD menekankan pada pengorganisasian tim secara

mandiri, kolaborasi antar-perseorangan, dan terus
belajar, baik secara individu maupun secara tim.
 Pada tahap Speculation, proyek dimulai dan
adaptive cycle planning diselenggarakan.
 Pada tahapan ini, didefinisikan visi dan misi
pengguna terhadap sistem yang akan dibuat,
selanjutnya mendefinisikan project
constraints, misalnya: waktu deliver dan
selanjutnya mendefinisikan satu set dari
requirements yang akan dikerjakan dalam
suatu cycle.
 Pada tahap Collaboration, pada tahap ini diorganisasikan tim kerja
untuk membangun sistem.
 Direkomendasikan menggunakan model Joint Application
Development (JAD).
 Pada tahap Learning, terdapat tiga aktifitas yaitu: pelanggan atau
end-user menyediakan feedback terhadap hasil incremental
delivery.
 tim ASD melakukan review terhadap komponen perangkat lunak
untuk memperbaiki dan meningkatkan kualitas perangkat lunak
yang sedang dibuat.
 Pada tahap Learning, terdapat tiga aktifitas yaitu: pelanggan atau
end-user menyediakan feedback terhadap hasil incremental
delivery.
 tim ASD melakukan review terhadap komponen perangkat lunak
untuk memperbaiki dan meningkatkan kualitas perangkat lunak
yang sedang dibuat.
 Pada Dynamic System Development Method menyajikan kerangka kerja
(framework) untuk membangun dan memelihara sistem dalam waktu yang
terbatas melalui penggunaan prototip yang incremental dalam lingkungan
yang terkondisikan. Metode ini bisa membuat pengerjaan software lebih
cepat 80%.Hal -hal yang perlu diperhatikan jika menggunakan dynamic
system development method: Feasibility study, siapkan requirement, dan
batasan, lalu uji apakah sesuai gunakan proses DSDM.
 Business Study, susun kebutuhan fungsional dan informasi, tentukan
arsitektur aplikasi dan identifikasi kebutuhan pemeliharaan untuk aplikasi.
 Functional model iteration, perlihatkan fungsi perangkat lunak ke klien
untuk mendapatkan feedback
 Design and Build Iteration, cek ulang prototip yang dibangun dan pastikan
bahwa prototip dibangun dengan cara yang memungkinkan fungsi
tersebut benar-benar bekerja.
 Implementation: buat perangkat lunak sesuai protoip yang ada dan terus
tambah fungsionalitasnya.
3 Tahapan Utama

 Sebelum proyek, di mana kandidat proyek diidentifikasi, pembiayaan

proyek terpenuhi, dan jaminan proyek dipastikan. Penanganan hal- hal
tersebut pada tahap ini menghindari masalah pada tahaptahap
berikutnya.

 Siklus hidup proyek, merupakan inti dari DSDM, yang terdiri dari 5 sub
tahap yaitu i) studi kelayakan; ii) studi bisnis; iii) perulangan model
fungsional; iv) perulangan perancangan dan pembuatan; v) penerapan.

 Setelah proyek, yaitu memastikan sistem berjalan secara efektif dan

efisien. Hal ini diwujudkan dengan perawatan, peningkatan dan
perbaikan sesuai prinsip-prinsip DSDM. Perawatan dapat dilihat sebagai
usaha meneruskan pengembangan berdasarkan sifat alami DSDM, yaitu
perulangan dan pertambahan.

 Kegiatan Kegiatan Sub Deskripsi

Tahap dimana kesesuaian DSDM dinilai. Dilihat oleh

jenis proyek, organisasi dan masalah orang,
keputusan dibuat, apakah akan menggunakan DSDM
Studi Kelayakan atau tidak. Oleh karena itu akan menghasilkan
LAPORAN KELAYAKAN, sebuah PROTOTIPE
KELAYAKAN, dan GARIS RENCANA GLOBAL yang
mencakup RENCANA PEMBANGUNAN dan LOG RISIKO.

Studi
Analisa karakteristik dari sisi bisnis dan teknologi.
Pendekatan utama adalah pengadaan lokakarya,
dimana pengguna ahli berkumpul dan menghasilkan
hal-hal yang relevan dari sistem serta menyetujui
Studi Bisnis skala prioritas dalam pengembangan. Dihasilkan
daftar prioritas kebutuhan, definisi dari wilayah bisnis,
definisi arsitektur sistem, dan garis besar rencana
prototip.
 Identifikasi Menentukan fungsionalitas yang akan dikerjakan pada prototip.
prototipe Dihasilkan sebuah model fungsional menurut hasil dari tingkat studi
fungsional bisnis.

Menyetujui
Setuju tentang bagaimana dan kapan untuk mengembangkan fungsi ini.
Jadwal
Fungsional
Model prototipe Mengembangkan PROTOTIPE FUNGSIONAL, sesuai dengan jadwal yang
Iterasi fungsional disepakati dan MODEL FUNGSIONAL.

Memeriksa kebenaran dari prototipe yang dikembangkan. Hal ini dapat

Meninjau
dilakukan melalui pengujian oleh pengguna akhir dan / atau melihat
prototipe
dokumentasi. Dihasilkansebuah dokumen tinjauan prototip model
fungsional
fungsional.

Mengidentifikasi kebutuhan fungsional dan non-fungsional yang

Mengidentifik diperlukan dalam sistem yang diujikan. Dan berdasarkan identifikasi ini,
asi desain sebuah STRATEGI IMPLEMENTASI dihasilkan. Jika ada catatan pengujian
prototipe dari iterasi sebelumnya, maka akan digunakan juga untuk menentukan
STRATEGI IMPLEMENTASI.

Menyetujui menyetujui tentang bagaimana dan kapan untuk mewujudkan

Desain jadwal persyaratan ini.
dan Build
Iterasi Buat sistem (DESAIN PROTOTIPE) yang dapat dengan aman diserahkan
Buat desain
kepada end-user untuk penggunaan sehari-hari, juga untuk tujuan
prototipe
pengujian.

Meninjau Mengecek kebenaran hasil rancangan sistem, melalui serangkaian teknik

desain uji coba dan peninjauan.Dokumentasipengguna mau pun catatan
prototipe pengujian akan dibuat.
 End user menyetujui sistem yang telah diuji
Persetujuan
(PERSETUJUAN) untuk implementasi dan
pemakai dan
pedoman yang berkaitan dengan pelaksanaan
pedoman
dan penggunaan sistem
Melatih calon pengguna akhir dalam
Melatih
penggunaan sistem. Dihasilkan sekelompok
Pengguna
pengguna yang terlatih
Menerapkan sistem telah diuji di lokasi
Penerapan pengguna akhir, yang disebut sebagai SISTEM
Implementasi yang telah tersampaikan
Review dampak dari sistem yang diterapkan
pada bisnis, isu sentral akan apakah sistem
tersebut memenuhi tujuan yang ditetapkan di
awal proyek. Berdasarkan hal ini, apakah
Ulasan bisnis proyek ini menuju ke tahap berikutnya, pasca-
proyek atau loop kembali ke salah satu tahap
sebelumnya untuk pengembangan lebih
lanjut. Ulasan ini akan didokumentasikan
dalam sebuah PROYEK REVIEW DOKUMEN.
 Pengadaan lokakarya, di mana teknik penting untuk menjaga
kemajuan proyek secara cepat dan dalam arah yang tepat, baik dari
sisi bisnis maupun teknis. Lokakarya digunakan menyeluruh pada
proyek untuk menciptakan produk dan membuat keputusan dengan
cepat, serta mengumpulkan pandangan luas dari pihak-pihak terkait.

MoSCoW, menyajikan cara dalam memprioritaskan persyaratan. Ini

adalah suatu singkatan yang berarti:
 Must, persyaratan ini harus ada demi tuntutan bisnis.
 Should, persyaratan ini ada bilamana mungkin, tetapi keberhasilan
proyek tidak bergantung padanya.
 Could, persyaratan ini bisa ada, dan tidak mempengaruhi
kemampuan dari tuntutan bisnis.
 Would, persyaratan ini dipenuhi di masa depan bila terdapat sisa
waktu atau pada pengembangan sistem selanjutnya.
a) Diperkenalkan oleh Jeff Sutherland tahun awal tahun
1990an
b) Pengembangan berikutnya dilakukan oleh Schwaber dan
Beedle. Scrum memiliki prinsip:
 ukuran tim yang kecil melancarkan komunikasi,
mengurangi biaya, dan memberdayakan satu sama lain
 proses dapat beradaptasi terhadap perubahan teknis dan
bisnis
 proses menghasilkan beberapa software increment
 pembangunan dan orang yang membangun dibagi dalam
tim yang kecil
 dokumentasi dan pengujian terus menerus dilakukan
setelah software dibangun
 proses scrum mampu menyatakan bahwa produk selesai
kapanpun diperlukan
 Aktifitas Backlog : Backlog adalah daftar kebutuhan yang jadi
prioritas klien. Daftar dapat
bertambah.
 Aktifitas Sprints: unit pekerjaan yang diperlukan untuk
memenuhi kebutuhan yang ditetapkan dalam backlog sesuai
dengan waktu yang ditetapkan dalam time-box (biasanya
30hari). Selama proses ini berlangsung backlog tidak ada
penambahan.
 Aktifitas Scrum Meeting: pertemuan 15 menit perhari untuk
evaluasi apa yang dikerjakan, hambatan yang ada, dan target
penyelesaian untuk bahan meeting selanjutnya.
 Aktifitas Demo :penyerahan software increment ke klien
didemonstrasikan dan dievaluasi oleh klien.
Kelebihan Scrum antara lain:

 Keperluan berubah dengan cepat

 Tim berukuran kecil sehingga melancarkan komunikasi,
mengurangi biaya dan memberdayakan satu sama lain
 Pekerjaan terbagi-bagi sehingga dapat diselesaikan dengan
cepat
 Dokumentasi dan pengujian terus menerus dilakukan setelah
software dibangun
 Proses Scrum mampu menyatakan bahwa produk selesai
kapanpun diperlukan

Kelemahan Scrum antara lain:

 Developer harus selalu siap dengan perubahan karena

perubahan akan selalu diterima.
 Crystal diperkenalkan oleh Cockburn dan Highsmith,
Development yang tidak pada jalur kritis, dapat menghabikan
waktu lebih, mereka yang memperbaiki produk atau membantu
oaring yang ada di jalur proyek kritis.
 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
 Rational unified process, adalah suatu kerangka
pengembangan perangkat lunak iteratif yang dibuat oleh Rational
Software, suatu divisi dari IBM sejak 2003. Rational unified
process bukanlah suatu proses dengan aturan yang konkrit,
melainkan suatu kerangka proses yang dapat diadaptasi dan
dimaksudkan untuk disesuaikan oleh tim pengembang perangkat
lunak yang akan memilih elemen proses disesuaikan dengan
kebutuhan mereka.Model ini membagi suatu sistem aplikasi
menjadi beberapa komponen sistem dan memungkinkan para
developer aplikasi untuk menerapkan metoda iterative (analisis,
disain, implementasi dan pengujian) pada tiap komponen.
1. Inception, merupakan tahap untuk mengidentifikasi sistem yang
akan dikembangkan. Aktivitas yang dilakukan pada tahap ini
antara lain mencakup analisis sistem, perumusan target dari
sistem yang dibuat, identifikasi kebutuhan, perumusan
kebutuhan pengujian, pemodelan diagram UML, dan pembuatan
dokumentasi.

1. Elaboration, merupakan tahap untuk melakukan disain secara

lengkap berdasarkan hasil analisis di tahap inception. Aktivitas
yang dilakukan pada tahap ini antara lain mencakup pembuatan
disain arsitektur subsistem, disain komponen sistem, disain
format data disain database, disain antarmuka/tampilan, disain
peta tampilan, penentuan design pattern yang digunakan,
pemodelan diagram UML, dan pembuatan dokumentasi.
3. Construction, merupakan tahap untuk mengimplementasikan hasil disain
dan melakukan pengujian hasil implementasi. Pada tahap awal
construction, ada baiknya dilakukan pemeriksaan ulang hasil analisis dan
disain, terutama disain pada diagram sequence,class, component, dan
deployment. Apabila disain yang dibuat telah sesuai dengan analisis
sistem, maka implementasi dengan bahasa pemrograman tertentu dapat
dilakukan. Aktivitas yang dilakukan pada tahap ini antara lain mencakup
pengujian hasil analisis dan disain (misal menggunakan class
responsibility collaborator untuk kasus pemrograman berorientasi
obyek), pendataan kebutuhan implementasi lengkap (berpedoman pada
identifikasi kebutuhan di tahap analisis), penentuan coding pattern yang
digunakan, pembuatan program, pengujian, optimasi program,
pendataan berbagai kemungkinan pengembangan / perbaikan lebih
lanjut, dan pembuatan dokumentasi.
4. Transition, merupakan tahap untuk menyerahkan sistem aplikasi ke
konsumen (roll-out), yang umumnya mencakup pelaksanaan pelatihan
kepada pengguna dan testing beta aplikasi terhadap ekspetasi pengguna.
Keuntungan Pengembangan Perangkat Lunak RUP :
 Menyediakan akses yang mudah terhadap pengetahuan dasar
bagi anggota tim.
 Menyediakan petunjuk bagaimana menggunakan UML secara
efektif.
 Mendukung proses pengulangan dalam pengembangan software.
 Memungkinkan adanya penambahan-penambahan pada proses.
 Memungkinkan untuk secara sistematis mengontrol perubahan-
perubahan yang terjadi pada software selama proses
pengembangannya.
 Memungkinkan untuk menjalankan test case dengan
menggunakan Rational Test Manager Tool
Kekurangan Pengembangan Perangkat Lunak RUP :
 Metodologi ini hanya dapat digunakan pada pengembangan
perangkat lunak yang berorientasi objek dengan berfokus pada
UML (Unified Modeling Language).
 Membutuhkan waktu yang cukup lama dibandingkan XP dan
Scrum
 Menurut Palmer (2001), FDD adalah proses yang didesain dan
dilaksanakan untuk menyajikan (deliver) hasil kerja secara
berulang-ulang dalam waktu tertentu dan dapat diukur.
 FDD adalah pendekatan yang mengacu pembuatan sistem
menggunakan metode yang mudah dimengerti dan mudah
diimplentasikan; teknik problem solving; dan pelaporan yang
mudah dimengerti dan dikontrol oleh stakeholders.
 Pemrogram diberikan informasi yang cukup dan diberikan
alat bantu yang baik untuk menyelesaikan aplikasi yang
diberikan. Team leader dan manajer proyek diberikan
informasi yang baik berdasar waktu mengenai tim dan
proyek yang berjalan untuk menghindari resiko yang
mungkin terjadi. Pelaporan menjadi lebih mudah, tidak
membebani, periodik dan akurat.
 Build an Overall Model

Ketika fase ini dimulai, Domain Expert telah menyadari scope, konteks
dan requirement dari sistem yang akan dibangun. Pembuatan dokumen
requirement seperti use case atau spesifikasi fungsional ada dalam fase ini.
Namun FDD tidak secara eksplisit menggali, mencari dan mengatur
requirement ini. Domain expert menyajikan apa yang disebut
“walkthrough” yang mana anggota tim dan Chief Architect diinformasikan
dengan deskripsi level tinggi dari sistem.Domain keseluruhan (overal
domain) lebih lajut dibagi kedalam area domain yang berbeda sedangkan
walkthrough yang lebih detail deberikan oleh anggota domain. Kemudian
anggota tim developer bekerja dalam grup-grup kecil untuk mengerjakan
project model dari domain area yang telah diterima.
 Build a Feature List
Walkthrough, object model dan dokumentasi requirement yang ada
memberikan dasar yang kuat dalam membangun feature list yang
komprehensif untuk sistem yang dikerjakan. Dalam daftar (list), tim
menyajikan masing-masing client valued functions ke dalam sistem.
Fungsi-fungsi tersebut dibagikan kepada masing-masing domain area
dan masing-masing grup dari fungsi tersebut disebut sebagai major
feature set. Sebagai tambahan, major feature sets kemudian dibagi lagi
menjadi feature sets. Ini merepresentasikan aktifiti yang berbeda di
setiap domain area. Feature list adalah yang dilihat oleh user atau
sponsor untuk validitas dan kelengkapan mereka.
 Plan by Features
Plan by feature mencakup perencanaan pada level yang lebih
tinggi, dimana feature set diatur sedemikian rupa sesuai
dengan prioritas dan hubungannya. Prioritas ditentukan
sesuai dengan kebutuhan customer yang disetujui oleh Chief
Programmer. Dalam fase ini, Project Manager, Development
Manager dan Chief Programmer merencanakan urutan
feature-feature yang akan dikerjakan dengan demikian class
owenership telah dilengkapi.
 Design by Feature dan Build by Feature
Sekelompok kecil fitur diambil dari feature set dan diperlukan
feature team untuk membangun fitur terpilih yang disebut sebagai
class owner. Proses design by feature dan build by feature bersifat
iteratif selama fitur yang dipilih tersebut diproduksi. Satu kali iterasi
memerlukan waktu beberapa hari sampai 2 minggu. Proses iteratif
ini mencakup beberapa tugas seperti inspeksi rancangan,
pengkodean, pengujian unit, integrasi dan inspeksi kode. Dijelaskan
pada gambar di bawah ini :
 Project Tracking Methodology

Penelusuran proyek (Project Tracking) diperlukan untuk mengetahui

sejauh mana proyek telah berjalan dan mengevaluasi strategi dan
kemungkinan yang akan dijalankan terkait situasi itu. Menurut Pulla,
untuk mengukur kemajuan tiap feature dalam proses FDD terdiri dari 6
milestone di setiap featurenya menggunakan ukuran prosentase,
mencatat waktu feature selesai, diatur dari feature set dan feature area,
direpresentasikan secara grafis kepada manajemen di level yang lebih
tinggi, juga disusun tren dan grafik digunakan untuk menunjukkan
kemajuan.
 Karakteristik
Menurut Calberg, penggunaan FDD sebaiknya digunakan jika;
memekerjakan 10 – 250 developer yang memiliki kemampuan
teknis lebih dari rata-rata, dan jangan digunakan jika; jumlah tim
kurang dari 10, tim sedang belajar menguasai pekerjaan dan jika
kurang dukungan dari sistem. FDD lebih terhirarki daripada
Extreme Programming, memiliki class owenership yang terpisah-
pisah, sukses jika dalam rentang jumlah developer diatas rata-
rata, klien tidak dilibatkan dalam
 Banyak situasi pembangun software harus membangun sistem bisnis yang besar
dan penting. Jangkauan dan kompleksitas sistem harus dimodelkan sehingga
dapat dimengerti, masalah dapat dibagi menjadi lebih kecil dan kualitas dapat
dijaga pada tiap langkah pembangunan software.
 AM adalah suatu metodologi yang praktis untuk dokumentasi dan pemodelan
sistem software.
 AM adalah kumpulan nilai-nilai, prinsip dan praktek-praktek untuk memodelkan
software agar dapat diaplikasian pada software development proyek secara
efektif. Prinsip dalam AM;
 membuat model dengan tujuan: tentukan tujuan sebelum membuat model
 mengunakan multiple models: tiap model mewakili aspek yang berbeda dari
model lain.
 travel light: simpan model-model yang bersifat jangka panjang saja
 isi lebih penting dari pada penampilan: modeling menyajikan informasi kepada
audiens yang tepat.
 memahami model dan alat yang yang digunakan untuk membuat software
 adaptasi secara lokal
Kelebihan dari Agile Modeling:
 Meningkatkan kepuasan kepada klien
 Pembangunan system dibuat lebih cepat
 Mengurangi resiko kegagalan implementasi
software dari segi non-teknis
 Jika pada saat pembangunan system terjadi
kegagalan,kerugian dar segi materi relative kecil.

Kelemahan dari Agile Modeling:

 Developer harus selalu siap dengan perubahan
karena perubahan akan selalu diterima.
 Abrahamsson, pekka dkk. 2002. Agile software development
methods. Finland: Jukaisija-utgivare
 http://www.scribd.com/doc/84897015/Agile-Model-Proses, kamis
18 April 2014
 http://www.versionone.com/agile101/agile_development.asp ,
kamis 18 April 2014
 http://en.wikipedia.org/wiki/Agile_software_development,
kamis 18 April 2014
 http://lti-server.tamps.cinvestav.mx/~ertello/svam/s06-SWE-
AgileSW.pdf, kamis 18 April 2014
 http://www.uml.org.cn/softwareprocess/pdf/IEEEArticle2Final2.pdf,
kamis 18 April 2014