AGIL DEVELOPMENT
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, 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 .
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
KegiatanKegiatan SubDeskripsiStudiStudi KelayakanTahap 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 BisnisAnalisa 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 IterasiIdentifikasi prototipe
fungsionalMenentukan fungsionalitas yang akan dikerjakan pada
prototip. Dihasilkan sebuah model fungsional menurut hasil dari
tingkat studi bisnis.Menyetujui JadwalSetuju tentang bagaimana dan
kapan untuk mengembangkan fungsi ini.prototipe
fungsionalMengembangkan PROTOTIPE FUNGSIONAL, sesuai dengan jadwal
yang disepakati dan MODEL FUNGSIONAL.Meninjau prototipe
fungsionalMemeriksa 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 IterasiMengidentifikasi desain
prototipeMengidentifikasi 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 jadwalmenyetujui
tentang bagaimana dan kapan untuk mewujudkan persyaratan ini.Buat
desain prototipeBuat sistem (DESAIN PROTOTIPE) yang dapat dengan
aman diserahkan kepada end-user untuk penggunaan sehari-hari, juga
untuk tujuan pengujian.Meninjau desain prototipeMengecek kebenaran
hasil rancangan sistem, melalui serangkaian teknik uji coba dan
peninjauan.Dokumentasipengguna mau pun catatan pengujian akan
dibuat.
ImplementasiPersetujuan pemakai dan pedomanEnd user menyetujui
sistem yang telah diuji (PERSETUJUAN) untuk implementasi dan
pedoman yang berkaitan dengan pelaksanaan dan penggunaan
sistemMelatih PenggunaMelatih calon pengguna akhir dalam penggunaan
sistem.Dihasilkan sekelompok pengguna yang
terlatihPenerapanMenerapkan sistem telah diuji di lokasi pengguna
akhir, yang disebut sebagai SISTEM yang telah tersampaikanUlasan
bisnisReview 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.
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
Diperkenalkan oleh Jeff Sutherland tahun awal tahun 1990an
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 :
Secara aktual sebuah model proses keluarga yang memungkinkan
manuver berdasar karakteristik permasalahan
Menyarankan penggunaan workshop refleksi untuk review kebiasaan
kerja tim
Selalu murah dan cepat berkomunikasi secara langsung.
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)
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.
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.
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
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.
5 Proses FDD Dalam Mendesain dan 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.
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 jumlah developer diatas rata-rata, klien tidak dilibatkan
dalam
5 Proses FDD Dalam Mendesain dan 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
Proses Siklus Agile Modelling
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
