AGIL

DEVELOPMENT
Rifqi Rahmatika Az-Zahra (12650112)
Laila Nur Shoima
(12650038)
Erik Hendara Kurniawan
(12650036)

Mapping Agile
Development XP
Pengertian
ASD
Sejarah
Agile
Development

Pengembangan
Agile

DSDM
SCRUM

Manfaat
RUP
karakteristik
Crystal
Prinsip-prinsip
Agile Model
Proses

FDD
AM

Pengertian Agil
Agile

Development

Methods

adalah

sekelompok

metodologi

pengembangan perangkat lunak yang didasarkan pada prinsipprinsip 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.

Sejarah AGIL

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 .

Pengembangan Perangkat Lunak

Tangkas(agile)
Berikut adalah ekosistem dari pengembangan
perangkat lunak tangkas (agile) :
Perspektif chaordic ,
Nilai nilai Collaborative dan prinsipprinsip ,
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.

Perspektif Chaordic
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.

Chaordic Hock
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.

Nilai Nilai Collaborative dan

Prinsip-Prinsip

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.

Metodologi yang Memadai

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 ."

Manfaat Agil

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.

Karakteristik Agil

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

Prinsip Agil
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

Prinsip Agil
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

Agile Process

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

Langkah Agil Development

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

Siklus Agile

Table Traditional Agil

Agil Proses Model

Extreme Programming (XP)

Adaptive Software Development (ASD)

Dynamic Systems Development Method (DSDM)

Scrum

Crystal

Feature Driven Development (FDD)

Agile Modeling (AM)

Model Proses AGILE

Extreme Programming
(XP)

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

Siklus XP(Extreme
Programming)

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 (ClassResponsibility-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.

Siklus XP (Extreme
Programming)

Penggunaan yang Tepat untuk XP

dan Kelemahan XP
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.

Adaptive Software Development

(ASD)

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.

ASD Process

Penjelasan Siklus Proses

ASD
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.

Penjelasan Siklus Proses

ASD

Pada tahap Collaboration, pada tahap ini diorganisasikan tim kerja

untuk membangun sistem.

Direkomendasikan
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.

menggunakan

model

Joint

Application

Dynamic Systems Development Method (DSDM)

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.

Siklus DSDM

Proses SiklusDSDM Terdiri Dari 3 Tahapan Utama

dan Sub Tahapannya
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.

Sub Tahapan DSDM

Kegiatan

Kegiatan Sub

Deskripsi

Tahap dimana kesesuaian DSDM dinilai.Dilihat oleh

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

Studi

Studi Bisnis

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
skala prioritas dalam pengembangan. Dihasilkan
daftar prioritas kebutuhan, definisi dari wilayah
bisnis, definisi arsitektur sistem, dan garis besar
rencana prototip.

Identifikasi
prototipe
fungsional

Menentukan fungsionalitas yang akan dikerjakan pada prototip.

Dihasilkan sebuah model fungsional menurut hasil dari tingkat studi
bisnis.

Menyetujui
Jadwal

Setuju tentang bagaimana dan kapan untuk mengembangkan fungsi

ini.

Fungsional
Model
prototipe
Iterasi
fungsional

Desain
dan Build
Iterasi

Mengembangkan PROTOTIPE FUNGSIONAL, sesuai dengan jadwal yang

disepakati dan MODEL FUNGSIONAL.

Meninjau
prototipe
fungsional

Memeriksa kebenaran dari prototipe yang dikembangkan.Hal ini dapat

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

Mengidentifik
asi desain
prototipe

Mengidentifikasi kebutuhan fungsional dan non-fungsional yang

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

Menyetujui
jadwal

menyetujui tentang
persyaratan ini.

Buat desain
prototipe

Buat sistem (DESAIN PROTOTIPE) yang dapat dengan aman

diserahkan kepada end-user untuk penggunaan sehari-hari, juga untuk
tujuan pengujian.

Meninjau
desain
prototipe

Mengecek kebenaran hasil rancangan sistem, melalui serangkaian

teknik uji coba dan peninjauan.Dokumentasipengguna mau pun
catatan pengujian akan dibuat.

bagaimana

dan

kapan

untuk

mewujudkan

Implementas
i

Persetujuan
pemakai
dan
pedoman

End user menyetujui sistem yang telah diuji

(PERSETUJUAN) untuk implementasi dan
pedoman yang berkaitan dengan pelaksanaan
dan penggunaan sistem

Melatih
Pengguna

Melatih
calon
pengguna
akhir
dalam
penggunaan sistem.Dihasilkan sekelompok
pengguna yang terlatih

Penerapan

Menerapkan sistem telah diuji di lokasi

pengguna akhir, yang disebut sebagai SISTEM
yang telah tersampaikan

Ulasan
bisnis

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

Beberapa Teknik Penting Untuk

Menentukan keberhasilan DSDM
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.

Scrum
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
a)

Proses Siklus Scrum

Proses Siklus Scrum

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 dan Kelemahan

Scrum
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

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 (RUP)

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.

Siklus Rational Unified Process

(RUP)

Pengembang Perangkat Lunak

RUP dalam 4 fase
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.

2.

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.

Pengembang Perangkat Lunak RUP dalam 4 fase

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 dan Kekurangan

Mengembangkan Perangkat Lunak RUP
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 perubahanperubahan 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

Feature Driven Development

(FDD)

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.

Siklus FDD

5 Proses FDD Dalam Mendesain

dan Membangun Sistem

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.

5 Proses FDD Dalam Mendesain

dan Membangun Sistem

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.

5 Proses FDD Dalam Mendesain

dan Membangun Sistem

Plan by Features
Plan by feature mencakup perencanaan pada level yang
lebih tinggi, dimana feature set diatur sedemikian rupa
sesuai

dengan

ditentukan

prioritas

sesuai

dengan

dan

hubungannya.

kebutuhan

Prioritas

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 :

5 Proses FDD Dalam Mendesain

dan Membangun Sistem

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

menunjukkan kemajuan.

tren

dan

grafik

digunakan

untuk

5 Proses FDD Dalam Mendesain

dan Membangun Sistem

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

developer diatas rata-rata, klien tidak dilibatkan dalam

jumlah

AGILE MODELING

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

Proses Siklus Agile

Modelling

Kelemahan dan Kelebihan

AM
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.

Refrensi

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