Agile Modeling and Prototyping

Agile Modeling, but First Prototyping

Merupakan metode yang berusaha untuk membangun suatu sistem secara incremental,
dengan cara membangun serangkaian prototipe dan secara konstan menyesuaikannya dengan
kebutuhan user. Agile menekankan pada pendekatan umpan balik berkelanjutan, dan setiap
langkah peningkatan dipengaruhi oleh apa yang telah dipelajari sebelumnya.
Agile modeling merupakan kumpulan inovasi pengembangan sistem yang berpusat pada user
dalam pengembangan sistem, BUT FIRST PROTOTYPING
Melakukan prototipe menghasilkan versi awal dari model yang berkeja yang sedang dibangun
untuk sistem informasi yang ditawarkan, disebut protipe (Purna Rupa). Prototyping
melibatkan rangkaian berulang dalam analisis, perancangan, pemodelan dan pengujian,
merupakan teknik umum yang dapat digunakan untuk merancang apapun dari suatu beranda
baru ke jaringan computer.
Prototyping merupakan suatu teknik pengumpulan informasi yang berguna mengetahui :

Reaksi user dan manajemen terhadap protipe, seberapa baik prototipe dapat memeni user
dari fitur-fitur prototipe.
Sararn dari user terkait pergantian maupun membersihkan sistem yang sedang di purwa
rupa.
Inovasi
Revisi Rencana yang memerinci bagian mana dari sistem yang perlu dilakukan lebih
dahulu
Prototyping and RAD (Rapid Application Development) dapat juga digunakan sebagai suatu
metode alternatif dari SDLC (Siklus Hidup Pengembangan Sistem).
Kinds of Prototyping

Patched-up
Nonoperational
First-of-a-series
Selected features

Pengumpulan informasi pada phase prototyping memungkinkan analis mengatur prioritas dan
mengarah pada perencanaan yang tidak mahal, dengan gangguan yang minimum.
Patched-Up Prototype (Seadanya)

Membangun suatu sistem yang bekerja tetapi disulam atau disulam bersama-sama
(digabung bersama)

Suatu model yang memiliki semua fitur-fitur tetapi tidak efisien.

Para User dapat berinteraksi dengan sistemmenjadi terbiasa dengan interface dan jenisjenis output yang tersedia.

Pencarian maupun penyimpanan informasi mungkin tidak efisien, karena program ditulis
secara cepat dengan tujuan dapat berjalan bukan efisien.

Dalam perekasayaan pendekatan ini dikenal dengan istilah breadboarding.

Nonoperational Scale Models Of an Information System

Suatu Skala Model tidak bekerja, yang diatur untuk menguji asfek-asfek tertentu dari
perancangan.
Ex. Model Skala penuh kendaraan

Suatu Skala Model tidak bekerja dari suatu sistem informasi yang dibuat bilamana asfek
pensandian (coding) yang diperlukan untuk aplikasi terlalu luas untuk prototype, namun bila

suatu gagasan mengenai suatu sistem dapat dihasilkan hanya melalui prototipe input dan
output.
First-of-a-Series Prototype

Membuat prototipe skala penuh dari sistem yang disebut pilot model, jika berhasil
prototipe beroperasi secara lengkap,

Prototipe ini berguna pada saat merencanakan menginstalasi sistem informasi yang sama
dalam jumlah banyak.

Suatu Prototipe-Skala Penuh pertama di instalasi pada satu atau dua lokasi, jika berhasil,
duplikat di instalasi pada semua lokasi berdasarkan pola penggunaan pelanggan dan faktorfaktor kunci lainnya.
Selected Features Prototype

Prototipe ini terkait membangun model yang beroperasi yang mencakup beberapa, namun
bukan keseluruhan fitur-fitur yang akan dimiliki sistem pada akhirnya.

Beberapa, namun bukan keseluruhan fitur-fitur khusus dimasukan.

Saat prototipe selesai dikerjakan, sistem disempurnakan dalam modul-modul terpasang,

setelah ievaluasi user sukses, maka dapat dibangun sistem yang lebih besar.

Protipe yang telah diselesaikan merupakan bagian dari sistem actual.

Four Kinds of Prototypes
Clockwise, Starting from the Upper Left (Figure 6.1)

Prototyping as an Alternative to the Systems Life Cycle

Dua masalah utama terkait SDLC (Daur Hidup Pengembangan Sistem)

Terkait masalah waktu yang panjang untuk menggunakan Siklus Hidup
Pengembangan Sistem

Permintaan user berubah setiap waktu, seiring dengan perubahan kebutuhan user

Untuk mengatasi masalah tersebut, analis menyarankan menggunakan prototipe sebagai

alternatif dari SDLC, gunakan prototipe sebagai bagian dari SDLC.

Drawbacks(Kekurangan) to Supplanting (Pengganti) the SDLC With Prototyping

Kekurangan mencakup pengembangan suatu sistem secara prematur sebelum masalah

atau peluang dipahami menyeluruh.

menggunakan prototyping sebagai suatu alternatif dapat menghasilkan suatu sistem yang
di diterima oleh sekelompok pengguna tertentu, tapi tidak mencukupi untuk kebutuhan
seluruh sistem.
Guidelines for Developing a Prototype

Bekerjalah dalam modul-modul yang dapat dikelola.

Membangun prototipe secara cepat.

Modifikasi protipe dalam urutan pernyataan berulang.

Penekanan pada user interface

Work in Manageable Modules

Seorang analis harus bekerja dalam modul-modul yang dapat dikelola

Satu yang membedakan manfaat prototipe adalah tidak perlu atau ,menginginkan
membangun keseluruhan sistem yang bekerja untuk tujuan membuat prototipe.

Suatu modul yang dapat dikelola memungkinkan user untuk berinteraksi dengan fiturfitur utamanya, namun dapat dibangun secara terpisah dari modul-modul sistem lainnya.

Fitur-fitur modul yang dipandang kurang penting dikeluarkan dari prototipe awal.
Build the Prototype Rapidly

Kecepatan merupakan hal penting untuk keberhasilan melakukan protipe.

Analis dapat menggunakan prototiping untuk memperpendek gap interval antara

penyerahan sistem langkap dengan kebutuhan user dengan menggunakan teknik pengumpulan
informasi tradisional untuk menemukan informasi yang dibutuhkan, lalu buat keputusan yang
membawa kearah model yang bekerja.

Menempatkan secara bersama sebuah operasional prototipe dengan cepat dan lebih
awal dalam SDLC memungkinkan seorang analis untuk mendapatkan gambaran
mengenai yang tertinggal dari proyek.

Dengan cara menunjukan pada user pada awal proses bagian dari sistem sebenarnya
berjalan, melakukan prototipe cepat menjaga terhadap kelebihan kapasitas dari sumber daya
untuk proyek yang pada akhirnya jadi tidak berjalan (bekerja)

Modify the Prototype in successive iterations

Membangun suatu protipe yang dapat dimodifikasi, berarti menciptakan hal tersebut
dalam modul- yang sangat tidak saling tergantung.

Prototipe biasanya dimodifikasi beberapa kali.

Perubahan seharusnya mengarahkan sistem lebih dekat pada apa yang dikatakan penting
oleh user.

Setiap modifikasi diikuti oleh suatu evaluasi oleh user.

Stress the User Interface

Menggunakan prototipe untuk mendapatkan pengguna untuk lebih mengartikulasi

kebutuhan informasi mereka.

Mereka seharusnya dapat melihat bagaimana prototype akan dapat menyelesaikan tugas
mereka.

Interface pengguna haruslah cukup dikembangkan untuk memungkinkan untuk mengapit

sistem secara cepat.

Online, sistem interaktif menggunakan GUI interfaces secara ideal sesuai dengan
prototype. interactive systems using GUI interfaces are ideally suited to prototypes
Disadvantages of Prototyping

Sulit mengelola prototype sebagai suatu projek dalam sistem yang lebih besar.

User dan analis bisa mengadopsi prototipe sebagai suatu sistim yang lengkap, namun
pada kenyataannya tidak mencukupi dan tidak pernah dimaksudkan untuk melayani sistem
yang tuntas.

Mungkin untuk mengubah sistem pada awal pengembangan sistem.

Peluang untuk menghentikan pengembangan pada sistem yang tidak bekerja.

Memungkinkan untuk pengembangan suatu sistem yang lebih mendekati kebutuhan dan
harapan user.

Terkadang cara tercepat untuk prototipe adalah melalui instalasi modul perangkat lunak
COTS software (Commercial Of The Shelf).

Beberapa perangkat lunak COTS terperinci dan mahal, tetapi sangat berguna. Some

Users Role in Prototyping

Jujur terlibat

Berpengalaman dengan prototipe

Memeberikan reaksi terbuka terhadap prototipe.

Memberikan saran penambahan atau menghapus dari prototipe.

Prototype Evaluation Form
(Figure 6.3)

Agile Modeling
Merupakan metode yang berusaha untuk membangun suatu sistem secara incremental, dengan
cara membangun srengkaian prototipe dan secara teratur menyesuaikannya dengan kebutuhan
user.
Agile methods merupakan sekumpulan pendekatan inovatif yang berpusat pada user untuk
pengembangan sistem
Values and Principles of Agile Modeling

Communication

Simplicity

Feedback

Courage

Values Are Crucial to the Agile Approach (Figure 6.4)

The Basic Principles of Agile Modeling
Prinsip-prinsip agile merupakan reflesi dan spesifikasi dari nilai-nilai agile. Prinsip-prinsip
memberikan arahan bagi developer untuk mengikuti saat mengembangkan sistem. Peinsipprinsip juga memberikan pengaturan metodologi agile terpisah dari yg lebih tradisional yang
dipandu metodologi perencanaan, seperti SDLC juga metodologi berorientasi objek.
Back et al. memaparkan prinsip-prinsip agile sbb:

Memuaskan pelanggan melalui penyerahan perangkat lunak yang bekerja.

Meliputi perubahan, kendatipun terlambat ditetapkan dalam pengembangan

Penyerahan berkesinambungan , software yang berfungsi secara bertahap dan sering.

Mendorong kerja sama sehari-hari pelanggan dan analis.

Kepercayaan individual termotivasi untuk menyelesaikan pekerjaan.

Meningkatkan percakapan tatap muka.

Berkonsentrasi pada mendapatkan software yang bekerja.

Mendorong terus menerus, teratur dan berkelanjutan.

Mengadopsi kegesitan dengan perhatian untuk berhati-hati merancang.

Mendukung pengelolaan tim mandiri.

Memberikan feedback dengan cepat

Medukung kualitas.

Mereview dan adalakalanya menyesuaikan perilaku

Mengadopsi kesederhanaan.

Aktivitas, Sumber Daya dan Praktik Pemodelan Agile

Four Basic Activities of Agile Modelingi
Analis Agile perlu untuk mengindentifikasi sejumlah upaya yang akan masuk kedalam aktivitas
dan menyeimbangkan dengan sumber daya yang dibutuhkan untuk menyelasikan proyek.

Coding

Testing

Listening

Designing

Coding

Pengkodean merupakan satu aktivitas yang tidak bisa tidak harus dilakukan.

Nilai yang berharga dari coding adalah pembelajaran

Code bisa juga digunakan untuk mengkomunikasikan gagasan-gagasan yang tidak jelas
atau tidak terbentuk.
Testing
Agile memandang pengujian otomatisasi penting
Menulis tes-tes guna memeriksa coding, fungsionalitas, kinerja, dan kesesuaian
bersandar pada tes terotomatisasi
perpustakaan besar dari tes ada untuk kebanyakan bahasa pemrograman
ini diperbarui seperlunya selama proyek
Pengujian dalam jangka pendek memberikan kepercayaan ekstrim pada apa yang
sedang dibangun
Pengujian dalam jangka panjang membuat sistem hidup dan memungkinkan untuk
perubahan lebih lama dari yang mungkin jika tidak ada tes yang ditulis atau run
Listening

Dalam pendekatan Agile mendengarkan dilakukan secara ekstrim.

Pengembang menggunakan mendengarkan aktif untuk mendengar mitra programnya.

Karena kurangnya formalitas, komunikasi tertulis, mendengarkan menjadi puncak

keahlian.

Seorang pengembang juga memakai aktif mendengarkan dengan pelanggan.

Pengembang menganggap mereka tidak tahuap a-apa tetang bisnis, sehingga mereka
harus mendengakan secara cermat pada orang-orang bisnis.
Designing

Merancang merupakan cara untuk menciptakan suatu struktur untuk mengatur

semua logika dalam sistem
Merancang merupakan evolusi, dan sistem yang dirancang dikonseptualisasikan
sejalan perubahan, selalu dirancang
Desain yang baik sering sederhana
Desain harus memungkinkan fleksibilitas
desain yang efektif menempatkan logika dekat data yang akan beroperasi.
Desain harus berguna bagi semua orang yang akan membutuhkannya sebagai hasil
upaya pengembangan

Four Resource Control Variables of Agile Modeling

Time (Waktu) dibutuhkan waktu yang cukup untuk menyelesaikan proyek, kendatipun
waktu dipecah-peach dalam beberapa bagian (Waktu untuk mendengarkan pelanggan
mendisain, coding, menguji)

Cost (biaya), jika aktivitas coding, design, testing dan mendengarkan membebani proyek
dan sumber daya yang ditempatkan pada waktu, lingkup dan kualitas tidak mencukupi,
kendatipun dengan jumlah biaya normal yang dicurahkan untuk menyeimbangkan proyek.

Quality (kualitas), kualitas dapat disesuaikan baik secara internal maupun eksternal.
Kualitas internal melibatkan pengujian perangkat lunak untuk factor seperti fungionalitas
(Apakah program melakukan seperti apa yang diharapkan melakukan) dan sesuai (apakah
perangkat lunak memenuhi keseuaian standard an apakah dapat dipelihara.)
Kualitas eksternal atau bagaimana persepsi pelanggan atas sistem, pelanggan tertarik dengan
kinerja. (reabilitas program, atau apakah bug perangkat lunak masih ada? Apakah output
efektif? Apakah output sampai tepat waktu? Apakah perangkat lunak berjalan tanpa kesulitan?
Apakah user interface mudah dipahami dan digunakan?

Scope (Lingkup), Dalam Agile lingkup ditetapkan dengan cara mendengarkan pelanggan
dan menuliskan cerita. Cerita di periksa untuk melihat seberapa banyak dapat dilakukan
dalam waktu yang telah ditetapkan untuk memuaskan pelanggan.
Berikut ini contoh cetiap dari sistem travel penerbangan :
Tampilan alternative penerbangan, persiapkan lima penerbangan termurah.
Alternatif Penawaran Termurah, memberikan saran kepada pelanggan yang melakukan
perjalan hari berikutnya, menginap akhir pekan, mengambil promosi khusus, atau bandara
altenatif.
Pembelian Ticket, memungkinkan pelanggan membeli sebuah ticket langsung menggunakan
kartu kredit (pengecekan Validitas)
Memungkinkan pelanggan untuk memilih kursinya sendiri, pelanggan menampilkan
langsung pesawat terbang dan menanyakan pelanggan untuk memilih tempat duduk.

Four Core Agile Practices

Empat praktik pendekatan yang membedakan pendekatan agile dari pendekatan lain :

Short releases, berarti tim pengembang memadatkan waktu diantara waktu penyerahan
produk. Untuk memperpendek waktu penyerahan dengan cara mengerjakan fitur-fitur paling
penting, menyerahkan system atau produk dan memperbaikinya kemudian.

40-hour work week, Tim pengembang dengan sengaja menyokong budaya praktik inti di
mana tim bekerja bersama secara intense selama 40 jam per minggu. This helps team members spot
problems more readily, and prevents costly errors and omissions due to ineffectual performance or burnout.

Onsite customer, berarti bahwa user yang ahli dalam asfek bisnis dari pekerjaan sistem
yang dikembangkan berada dilapangan selama proses pengembangan. Orang ini bagian tak
terpisahkan dari proses, menulis cerita user, menkomunikasikan kepada anggota tim,
membantu memprioritaskan dan menyeimbangkan kebutuhan usaha jangka panjang, dan
membuat keputusan terkait fitur yang harus dikerjakan lebih dulu.

Pair programming (pemograman berpasangan), yang berarti bahwa anda bekerja dengan
programmer lain yang anda pilih sendiri. Pengkodean dan pengujian dilakukan berdua.
Umumnya programmer senior memimpin pengkodean awal, namun dengan keterlibatan
junior, siapapun yang memiliki penglihatan yang jelas mengenai tujuan biasanya melakukan
pengkodean pada saat itu. Bekerja dengan programmer lain membantu memperjelas
pemikiran.

Agile Core Practices (Figure 6.5)

The Agile Development Process
Umunya proses pemodelan Agile akan dilakukan sebagai berikut :
Dengarkan cerita penggun.
Gambar model alur kerja yang logis, untuk mendapatkan apresiasi keputusan bisnis yang
direpresentasikan dalam cerita pengguna.
Buat cerita pengguna baru berdasarkan model logis

 Mengembangkan beberapa prototipe display, menunjukan kepada pelanggan secara

pendek interface apa yang akan dimiliki.
Membuat model data fisik dengan menggunakan umpan balik dari prototipe dan
diagram alur kerja yang logis
Writing User Stories
Interaksi disampaikan antara pengembang dan pengguna
Pencarian pertama dan terutama untuk mengidentifikasi kebutuhan pengguna bisnis
yang bernilai
Tujuannya adalah pencegahan kesalahpahaman atau salah tafsir dari kebutuhan
pengguna
User Stories Can Be Recorded on Cards (Figure 6.6)

Scrum
Overall Stategy
Mulailah proyek dengan rencana tingkat tinggi yang dapat diubah dengan cepat
Keberhasilan proyek ini adalah yang paling penting
Keberhasilan individu adalah yang kedua
Pemimpin Proyek memiliki beberapa (tidak banyak) berpengaruh pada detail
Sistem Tim bekerja dalam kerangka waktu yang ketat
Componen of Scrum Methodology :

Product backlog (backlog Produk)

Sprint backlog (Backlog Lari Cepat)
Sprint, dlm periode 30 hari tim mentransformasi backlog ke software & dpt
didemontrasikan

Daily scrum, komunikasi yang telah dikerjakan dari meeting terakhir dan rencana harian
yg akan dikerjakan berikutnya

Demo, perangkat lunak yang bekerja didemontrasikan.

Lessons Learned from Agile Modeling
rilis pendek (atas produk) memungkinkan sistem untuk berkembang
Pemrograman Berpasangan meningkatkan kualitas secara keseluruhan
pelanggan di tempat yang saling menguntungkan pada bisnis dan tim pengembangan
Agile
40-jam kerja per minggu meningkatkan efektivitas pekerja
sumber daya berimbang dan kegiatan menunjang tujuan proyek
nilai-nilai Agile penting bagi keberhasilan

There Are Six Vital Lessons That Can Be Drawn from the Agile Approach to Systems
(Figure 6.7)

Comparing Agile Modeling and Structured Methods

a. Improving the efficiency of systems development
b. Risks inherent in organizational innovation
Strategies for Improving Efficiency Can Be Implemented Using Two Different
Development Approaches
(Figure 6.8)

Adopting New Information Systems Involves Balancing Several Risks (Figure 6.9)

Risks When Adopting New Information Systems

c. Fit of development team culture
d. Best time to innovate
e. Training cost for analysts and programmers
f. Clients reaction to new methodology
g. Impact of agile methodologies
h. Programmers/analysts individual rights
Summary
i. Prototyping
a. Patched-up system
b. Nonoperational
c. First-of-a-series
d. Selected-features
j. Prototype development guidelines
k. Prototype disadvantages
Prototype advantages
l. Users role in prototyping
m. Agile modeling
n. Five values of the agile approach
o. Principles of agile development
p. Agile activities
q. Agile resources
r. Summary (continued)
s. Core practices of the agile approach
t. Stages in the agile development process
u. User stories
v. Agile lessons
w. Scrum methodology
x. Dangers to adopting innovative approaches

In traditional Waterfall model

At a high level, the project teams would spend 15% of their time on gathering

requirements and analysis (1.5 months)

20% of their time on design (2 months)

40% on coding (4 months) and unit testing

20% on System and Integration testing (2 months).

At the end of this cycle, the project may also have 2 weeks of User Acceptance
testing by marketing teams.
In this approach, the customer does not get to see the end product until the end of

the project, when it becomes too late to make significant changes.

The image below shows how these activities align with the project schedule in
traditional software development.

y.
With Agile development methodology

In the Agile methodology, each project is broken up into several Iterations.

All Iterations should be of the same time duration (between 2 to 8 weeks).

At the end of each iteration, a working product should be delivered.

In simple terms, in the Agile approach the project will be broken up into 10 releases
(assuming each iteration is set to last 4 weeks).

Rather than spending 1.5 months on requirements gathering, in Agile software

development, the team will decide the basic core features that are required in the
product and decide which of these features can be developed in the first iteration.

Any remaining features that cannot be delivered in the first iteration will be taken up
in the next iteration or subsequent iterations, based on priority.

At the end of the first iterations, the team will deliver a working software with the
features that were finalized for that iteration.

There will be 10 iterations and at the end of each iteration the customer is delivered
a working software that is incrementally enhanced and updated with the features that
were shortlisted for that iteration.

The iteration cycle of an Agile project is shown in the image below.

This approach allows the customer to interact and work with functioning software at the end
of each iteration and provide feedback on it. This approach allows teams to take up
changes more easily and make course corrections if needed. In the Agile approach,
software is developed and released incrementally in the iterations. An example of how
software may evolve through iterations is shown in the image below.