AGILE_DEVELOPMENT METODE MANAJEMEN .pptx

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

Mapping Agile Development
Agile
Development
FDD
RUP
Crystal
DSDM
ASD
XP
Agile Model
Proses
Prinsip-prinsip
karakteristik
Manfaat
Pengembangan
Agile
Pengertian
Sejarah
AM
SCRUM

◦ 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.
Pengertian Agil

 Pada tahun 1970, DrWinston 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 .
Sejarah AGIL

Berikut adalah ekosistem dari pengembangan
perangkat lunak tangkas (agile) :
 Perspektif chaordic ,
 Nilai – nilai Collaborative dan prinsip-prinsip ,
 Metodologi yang memadai.
Pengembangan Perangkat Lunak
Tangkas(agile)

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

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

 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.
Nilai – Nilai Collaborative dan Prinsip-
Prinsip

 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 yang Memadai

 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.
Manfaat 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
Karakteristik 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
Prinsip Agil

 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
Agile Process

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

 Extreme Programming (XP)
 Adaptive Software Development (ASD)
 Dynamic Systems Development Method (DSDM)
 Scrum
 Crystal
 Feature Driven Development (FDD)
 Agile Modeling (AM)
Agil Proses Model

 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
Extreme Programming (XP)

 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.
Siklus XP(Extreme Programming)

Siklus XP (Extreme Programming)

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.
Penggunaan yang Tepat untuk XP dan
Kelemahan XP

 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.
Adaptive Software Development (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 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.
Penjelasan Siklus Proses ASD

 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.
Dynamic Systems Development Method (DSDM)

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.

Proses SiklusDSDM Terdiri Dari 3 Tahapan Utama dan Sub
Tahapannya

Kegiatan Kegiatan Sub Deskripsi
Studi
Studi Kelayakan
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 LAPORAN
KELAYAKAN, sebuah PROTOTIPE KELAYAKAN, dan GARIS
RENCANA GLOBAL yang mencakup RENCANA
PEMBANGUNAN dan LOG RISIKO.
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.
Sub Tahapan DSDM

Fungsional
Model
Iterasi
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.
prototipe
fungsional
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.
Desain
dan Build
Iterasi
Mengidentifika
si 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 bagaimana dan kapan untuk mewujudkan 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
Mengecek kebenaran hasil rancangan sistem, melalui serangkaian teknik uji
coba dan peninjauan.Dokumentasipengguna mau pun catatan pengujian

Implementasi
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

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.
Beberapa Teknik Penting Untuk Menentukan
keberhasilan DSDM

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
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.
Proses Siklus 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.
Kelebihan dan Kelemahan Scrum

 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
Crystal

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.
Rational Unified Process (RUP)

Siklus Rational Unified Process (RUP)

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

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
Keuntungan dan Kekurangan Mengembangkan
Perangkat Lunak RUP

 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.
Feature Driven Development (FDD)

 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.
Membangun Sistem

 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.
Membangun Sistem

 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.
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 jumlah developer diatas rata-rata,
klien tidak dilibatkan dalam
Membangun Sistem

 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
AGILE MODELING

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.
Kelemahan dan Kelebihan AM

 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
Refrensi

AGILE_DEVELOPMENT METODE MANAJEMEN .pptx

More Related Content

Similar to AGILE_DEVELOPMENT METODE MANAJEMEN .pptx

Recently uploaded

AGILE_DEVELOPMENT METODE MANAJEMEN .pptx