Anda di halaman 1dari 10

Project Flexibility Matrix

July 18, 2012


Ada dua hal penting yang menjadi tujuan
suatu organisasi berbasis laba dalam
melaksanakan sebuah project. Pertama,
project ditujukan untuk memperbesar
revenue dan kedua, untuk mengurangi
cost dari suatu proses. Inilah yang
mendasari terciptanya proyek yang ada di
dalam suatu organisasi.
Dalam pelaksanaan suatu project
organisasi akan meng-assign suatu divisi
atau pun pihak eksternal (diluar dari
organisasi) yang akan menjalankan
project ini. Dalam hal ini organisasi
bertindak sebagai sponsor sedangkan
pihak yang diserahi project akan
bertindak sebagai project team / project
manager. Ada satu hal yang disepakati
diwal antara Project Team (dalam hal ini
adalah Project Manager) dengan Sponsor,
yaitu Project Objective Statement (POS).
POS merupakan statement yang
menyatakan scope (lingkup pekerjaan),
resources (baik SDM, pembiayaan,
peralatan dll) dan jadwal pelaksanaan
(kapan project dimulai dan kapan project
berakhir). Berdasarkan best practice
sebisa mungkin POS ini tidak lebih dari
25 kata, dan bisa mencakup aspek
resource, scope dan schedulenya sehingga
pihak sponsor langsung clear sekali
membaca dokumen POS ini.
POS inilah yang menentukan scope,
resources dan schedule dari suatu proyek
(yang biasa disebut project triple
constraint), yang hendaknya dijaga
supaya ketiga-tiganya dapat tercapai di
akhir project. Namun dalam
pelaksanannya akan ada satu atau
beberapa dari constraint ini yang tidak
dapat dicapai, misalnya waktu molor,
biaya membengkak atau scope yg tidak
sesuai denga rencana awal, karena pada
dasarnya project adalah suatu kegiatan
yang penuh dengan ketidakpastian dan
resiko. Maka dibuatlah matrix flexibility
yang akan menjadi solusi kalaupun salah
satu atau beberapa hal diatas tidak
tercapai. Matrix flexibility ini akan
digunakan oleh project manager untuk
berkompromi dengan sponsor, jikalau
salah satu dari tiga tujuan proyek tidak
sesuai dengan rancana awal, aspek mana
yang boleh berubah. Matrix flexibility
inilah yang akan menentukan aspek mana
yang akan didahulukan atau diprioritaskan
dalam pelaksanaannya. Namun perlu
diingat bahwa Matrix Flexibility ini
dibuat bukan untuk mengakomodir bahwa
proyek itu boleh molor, biayanya boleh
membengkak atau scopenya boleh
berubah / kurang. Justru ini dibuat sebagai
langkah antisipasi sehingga meskipun
berubah, sudah diketahui dari awal aspek
apa saja yang flexible untuk berubah.
Prioritas salah satu dari ketiga aspek ini
bisa berbeda-beda tergantung dari
karakteristik dari suatu project itu sendiri.
Ada project yang lebih diprioritaskan
pada aspek waktu, ada yang aspek biaya
(cost) atau aspek scope (kualitas).


Project Flexibility Matrix
Flexibility matrix diatas menjelaskan
bahwa Schedule merupakan prioritas
utama dari project. Sehingga apapun akan
dilakukan sehingga waktu atau schedule
dari project tidak berubah. Sedangkan
scope merupakan aspek moderate
flexible, sehingga scope dari project bisa
dibuah sepanjang dalam batas-batas wajar
(dalam tahap moderate). Resource (SDM,
Cost dll) merupakan hal yang paling
flexible sehingga perubahan dapat
diakomodir di aspek ini.
Perlu diingat bahwa satu kolom yang ada
di matrix diatas hanya boleh diisi 1 item
saja (satu centangan), sehingga kita tidak
boleh menge-set schedule dan scope
merupakan least flexible. Namun harus
dipilih satu dari ketiga aspek yang
merupakan least flexible.
Berikut adalah tipe-tipe project yang akan
membantu memahami dalam menentukan
prioritas dalam pelaksanaan suatu project:
1. Project Peluncuran Astronot ke
Luar Angkasa

proyek pesawat luar angkasa
Ini adalah salah satu contoh eksekusi
dalam suatu project yang akan
menitikberatkan prioritas pada aspek
scope / kualitas dari suatu project.
Sedangkan Schedule dan Resource
merupakan aspek yang boleh flexible.
Bayangkan saja jika suatu project
peluncuran pesawat ke antariksa namun
pilot / astronotnya tidak kembali ke bumi,
oleh karena itu proyek ini bisa
dikategorikan sebagai proyek yang least
flexible pada aspek Scope pekerjaan.
Pergeseran waktu maupun
membengkaknya biaya akan dilakukan
selama menjamin bahwa scope pekerjaan
dapat terpenuhi.
2. Project Pernikahan

Proyek Pernikahan
Misalkan sepasang muda mudi yang ingin
melangsungkan pernikahan tetapi
terkendala oleh faktor ekonomi, sehingga
mereka menetapkan bahwa anggaran
untuk nikah mereka tidak boleh lebih dari
50 jt, sehingga dalam hal ini anggaran /
resources adalah komponen Least
Flexible dalam matrix flexibility,
sehingga inilah prioritas yang harus
didahulukan. Apapun yang terjadi dalam
pelaksanaan pernikahannya harus tidak
boleh lebih dari 50 jt. Komponen
moderate flexibility adalah Schedule,
dalam hal ini waktu pelaksanaan nikah
dapat bergeser (misalnya sewa gedung
yang murah hanya tersedia 1 minggu
setelah hari H rencana awal, sehingga
waktu pelaksanaan digeser) dan
komponen yang Most Flexible adalah
scope dari pernikahan, misalnya dengan
mengurangi skope, contohnya dengan
menurunkan standar hidangan untuk
menjamu tamu atau dengan cara
mengurangi jumlah undangan.
3. Project Pelaksanaan Shalat Idul
Fitri

Pelaksanaan Shalat Idul Fitri
Project ini bisa dikatakan least Flexible
pada aspek schedule karena apapun yang
terjadi project harus terlaksana pada
tanggal 1 Syawal. Jadi faktor waktu
merupakan faktor least flexible. Project
akan sia-sia jika dilaksanakan pada
tanggal 2 syawal atau malah justru 30/29
Ramadhan. Untuk tipe proyek ini aspek
scope lebih flexible dari cost karena ada
syarat-syarat yang memang harus
dipenuhi terkait dengan pelaksanaan
Shalat Idul Fitri, seperti pemenuhan sound
system, karpet atau tikar yang harus suci,
penyediaan tempat wudhu, penyediaan
khotib dan imam.
Demikian penjelasan singkat tentang
Project Flexibility Matrix, semoga
membantu lebih memahami dinamika
pengelolaan proyek, terutama me-manage
project triple constraint.

Scope, Time and Cost Managing the
Triple Constraint
May 2, 2011 1 Comment

Nearly anyone familiar with project
management, even in a tangential fashion,
has probably heard of the famous Triple
Constraint. (Also often referred to as the
Project Management Triangle)
Referring to the diagram to the right, the
Triple Constraint basically demonstrates
in pictorial fashion, the key attributes that
must be handled effectively for successful
completion and closure of any project.
For thoroughness, the key attributes of the
Triple Constraint are itemized as follows:
Time This refers to the actual time
required to produce a deliverable. Which
in this case, would be the end result of the
project. Naturally, the amount of time
required to produce the deliverable will be
directly related to the amount of
requirements that are part of the end result
(scope) along with the amount of
resources allocated to the project (cost).
Cost This is the estimation of the
amount of money that will be required to
complete the project. Cost itself
encompasses various things, such as:
resources, labor rates for contractors, risk
estimates, bills of materials, et cetera. All
aspects of the project that have a
monetary component are made part of the
overall cost structure.
Scope These are the functional elements
that, when completed, make up the end
deliverable for the project. The scope
itself is generally identified up front so as
to give the project the best chance of
success. (Although scope can potentially
change during the project life-cycle, a
concept known as scope creep) Note
that the common success measure for the
scope aspect of a project is its inherent
quality upon delivery.
The major take-away from the Triple
Constraint, being that it is a triangle, is
that one cannot adjust or alter one side of
it without in effect, altering the other
sides. So for example, if there is a request
for a scope change mid-way through the
execution of the project, the other two
attribues (cost and time) will be affected
in some manner. How much or how little
is dictated by the nature and complexity
of the scope change. As an added
example, if the schedule appears to be
tight and the project manager determines
that the scoped requirements cannot be
accomplished within the allotted time,
both cost AND time are affected.
Based on the aforementioned definitions
and examples, how does the project
manager stay on top of the triple
constraint? What steps can one take to
ensure successful project rollout knowing
how the three attributes affect each other?
Understand the Triple Constraint
For starters, the project manager MUST
be fully cognizant of the fact that scope,
time and cost are fully inter-related and
that the triple constraint dictates any
adjustment to any of those items MUST
affect the other. In many cases, a project
manager may be somewhat aloof about
adding scope to a project or accepting a
budget cut without taking the effort to
determine what the consequences of that
change will be. Denial of the potential
repurcussions of adjustments to the scope,
time or cost of a project are only going to
lead to issues down the road and may also
cause the project to fail.
Convey the Triple Constraint
Along with recognizing how the triple
constraint functions, it is imperative that
the project manager convey that
information to the project stakeholders.
Making sure everyone who is involved
with the project recognizes the
importance of the constraint will make
discussions regarding the scope, time and
cost far easier. In many cases, the
stakeholders are likely to be the main
reasons for scope creep or budget
adjustments in a project. Having them
aware up front of what the ramifications
might be for any requested or mandated
changes will make dialog easier in follow-
up meetings and will also make them
scrutinize their change requests more
thoroughly rather than assuming that any
change will have no issue on the project
release cycle. Note that conveyance of the
triple constraint to the stakeholders is best
performed at the outset, likely during the
formation of the initial project plan.
Monitor the Triple Constraint
As the project manager, making sure that
you stay on top of all the key attributes of
the triple constraint will make the
likelihood of project success that much
higher. So be cognizant of any
fluctuations to the key attributes, whether
they be unexpected or requested. Never
assume that other attributes can be left un-
changed if one attribute is known to be
changing or fluctuating. As noted earlier,
one cannot simply dismiss a change to
one without being fully aware of the fact
that it WILL affect the other two.
*Conclusion*
The Triple Constraint is one of the most
well known and well respected
mechanisms for signifying the interaction
of the key attributes of a project. By being
fully aware of its function and
implications is an important aspect of the
project managers role and responsibility.
The triple constraint is meant to be a asset
to the project managers arsenal and
should not be viewed as a hinderance.

4 Hal penting dalam
Project Management
Posted on November 26, 2008 by henry
Sering kali seorang project manager
terbentur dengan permasalahan klasik
dalam pelaksanaan suatu proyek
(khusunya proyek-proyek IT). Terlambat,
biaya membengkak, dan owner yang
terlalu banyak permintaan merupakan
contoh dinamika yang ada dalam suatu
proyek. Lantas bagaimana menyikapinya
?
Ada 4 (empat) hal penting yang harus
dipahami oleh seorang project manager
ketika melaksanakan suatu proyek, yaitu
cakupan proyek (project scope), waktu
pelaksanaan proyek (project timeline),
biaya proyek (project cost) dan kualitas
dari proyek itu sendiri (project quality).
Keempat hal tersebut menjadi pilar utama
dalam project management body of
knowledge (PMBOK), sebuah best
practise yang digunakan oleh seluruh
project manager di dunia, khususnya
mereka yang telah memiliki sertifikasi
sebagai project manager professional
(PMP). Gambar berikut akan
menggambarkan bagaimana keempat hal
tersebut berinteraksi.

1. Scope
Scope berbicara masalah cakupan
pekerjaan yang dilakukan. Terkadang hal
ini yang menjadi perdebatan antara
pelaksana proyek dengan pemilik proyek.
Scope yang menjadi luas (biasanya terjadi
pada proyek yang dilakukan ad-hoc, tanpa
perencanaan atau metode yang tepat)
akibat permintaan owner yang datang
terus menerus dapat mempengaruhi waktu
pelaksanaan proyek dan biaya proyek.
2. Time
Merupakan waktu pelaksanaan proyek.
Semakin lama suatu proyek dikerjakan,
maka semakin besar biaya operasional
proyek yang dibutuhkan. Project Time
management yang baik akan
mempengaruhi besar kecilnya profit
margin proyek yang didapat
3. Cost
Merupakan komponen biaya proyek.
Komponen ini juga saling terkait dengan
2 komponen sebelumnya (scope and time)
karena besar kecilnya biaya proyek
(termasuk penambahan biaya jika
diperlukan) akan mempengaruhi besarnya
scope proyek serta cepatnya waktu
pelaksanaan proyek
4. Quality
Kualitas merupakan harapan yang ingin
didapatkan owner dari proyek tersebut
dan atau mengacu pada standar tertentu
(misal ISO). Kualitas dapat diraih dengan
menentukan biaya, waktu dan scope
proyek sesuai dengan kebutuhan.
Idealnya, Suatu proyek yang baik adalah
proyek yang dapat selesai tepat waktu
(time) dengan budget yang telah
direncanakan sebelumnya (cost) sesuai
dengan cakupan pekerjaan yang disetujui
(scope) dengan kualitas yang diharapkan /
ditentukan sebelumnya (quality).
Namun, bagaimana jika sebuah proyek
mengalami keterlambatan, sementara
kecenderungan tidak ada penambahan
biaya proyek (injection cost) dan scope
yang terus berkembang ? Apakah kualitas
sah untuk dikorbankan ?

Tidak banyak pilihan memang, jika
seorang project manager dihadapkan pada
permasalahan tersebut. Namun, ada
baiknya kita menggunakan cara-cara yang
sistematis dalam menyelesaikan
permasalahan diatas. Untuk dapat meraih
keuntungan (dalam hal ini tangible
benefit) adalah sesuatu hal yang hanya
dapat menjadi angan-angan. Namun, tetap
masih ada opsi lain, dimana hubungan
baik tetap diusahakan terjaga. Intagible
benefit itulah yang dapat kita harapkan
dari kerugian dan resiko kegagalan suatu
proyek. Dimana, sedapat mungkin kita
memberikan kesan bertanggung jawab
kepada klien kita dengan mencari solusi
terbaik (walaupun muncul tendensi
mengeliminasi kerugian yang diderita
semaksimal mungkin, walaupun kualitas
harus sedikit berkurang), sehingga
kepercayaan pelanggan tetap terjaga, dan
merubah paradigma pelanggan bahwa
kegagalan ini adalah satu diantara
keberhasilan yang pernah kami lakukan,
bukan ketidakprofesionalan sebagai
seorang pengembang.
Beberapa pilihan yang dapat
dipertimbangkan terkait 4 pilar utama
project management dalam mengatasi
kasus diatas adalah:
1. Negosiasi Pengurangan Scope

Orientasi manajemen proyek adalah
bagaimana menyelesaikan proyek secepat
mungkin sehingga kerugian akibat
pembengkakan biaya operasional proyek
dapat ditekan. Untuk itu, mau tidak mau,
project manager harus mempersiapkan
seorang negosiator ulung agar dapat
melobi pihak pemilik proyek untuk
menurunkan / mengurangi scope
pekerjaan yang ada, dengan harapan
kualitas dapat dipertahankan.
Pengurangan scope pekerjaan tentunya
akan menjadi lelucon belaka jika tidak
disertai strategi yang tepat dalam
melakukan lobi, misalnya dengan
menjanjikan versi berikutnya (pada
proyek pengembangan TIK) pada proyek
selanjutnya. Hal ini memungkinkan
manajemen proyek untuk mendapatkan
injection cost secara tidak langsung
dengan menempatkan scope proyek yang
dikurangi pada proyek selanjutnya,
tentunya dengan project cost yang baru.
2. Menambah kerugian untuk
mempertahankan image baik

Alternatif lain adalah menyelesaikan
proyek tersebut sesuai dengan scope yang
disepakati semaksimal mungkin, dengan
mengambil resiko meningkatnya
operasional cost. Strategi ini digunakan
apabila orientasi manajemen perusahaan
adalah mempertahankan citra baik di
depan pelanggannya, atau jika pemilik
proyek merupakan pelanggan potensial
perusahaan. Sehingga, walaupun
perusahaan menderita kerugian dari sisi
biaya proyek (tangible lost), namun
perusahaan tetap berusaha untuk
mempertahankan nama baik di depan
pelanggannya (intangible benefit) dengan
harapan kerjasama masih dapat terjalin di
masa yang akan datang
3. Cut the project

Pilihan berikutnya adalah memutuskan
proyek tersebut dan menyerahkan hasil
yang telah dilakukan apapun resikonya.
Dalam risk management, istilah ini
dinamakan accept the risk. Hal ini
dilakukan dengan pertimbangan cost of
risk yang harus ditanggung lebih kecil
daripada usaha menangani resiko tersebut
(baik tangible maupun intangible ).
Sehingga tidak ada pilihan lain selain
mengakhiri proyek tersebut dengan
menerima segala konsekuensinya.
Menindaklanjuti tulisan sebelumnya
tentang 4 hal penting dalam project
management, kali ini saya akan coba
mengulas beberapa penyebab kegagalan
pelaksanaan proyek IT dari beberapa
penelitian yang telah dilakukan, termasuk
memetakan penyebab kegagalan mengacu
pada PMBOK dengan menggunakan tools
fishbone analysis.
1. The Bulls Survey (1998)
Pada tahun 1998, sebuah manufaktur
komputer dan sistem integrator dari
perancis, BULLS, melakukan survey
tentang faktor-faktor penyebab kegagalan
pelaksanaan proyek untuk kebutuhan
internal perusahan. Hasil survey tersebut
dapat dilihat pada gambar berikut ini:

Pada gambar diatas dapat dilihat bahwa 3
(tiga) faktor penyebab terbesar kegagalan
proyek adalah buruknya komunikasi
antara pihak-pihak terkait, baik
pengembang maupun pemilik proyek
(57%), Kurang baiknya perencanaan
proyek (39%) serta buruknya
pengendalian kualitas pekerjaan (35%).
Hasil dari penelitian ini lebih menekankan
pada pentingnya komunikasi dalam
proyek, perencanaan yang matang serta
pengendalian kualitas yang mengacu pada
standar yang telah ditetapkan.
2. The KPMG Canada Survey (1997)
Sedangkan survey yang dilakukan oleh
KPMG canada menemukan beberapa
fakta tentang kegagalan pelaksanaan
proyek, diantaranya adalah:
- Buruknya perencanaan proyek
- Buruknya pengetahuan dan penggalian
kebutuhan bisnis
- Kurangnya keterlibatan dan dukungan
management
Sehingga dapat disimpulkan bahwa faktor
kegagalan proyek berdasarkan survey
yang dilakukan oleh KPMG adalah
perencanaan proyek, user and business
needs serta executive support.
3. The Chaos Report (1995)
Hasil studi dari the standish group yang
dituangkan dalam sebuah laporan berjudul
CHaos Report memaparkan 5 penyebab
utama kegagalan implementasi proyek,
yaitu:
1. Penggalian requirement (user &
business) yang kurang lengkap
2. Kurangnya keterlibatan user dalam
pengembangan sistem
3. Kurangnya sumberdaya manusia
proyek
4. Harapan/ekspektasi yang berlebihan
dari owner terhadap kapabilitas sistem
yang dibangun
5. Kurangnya dukungan dari
eksekutif/manajemen perusahaan pemilik
proyek
Berdasarkan hasil temuan pada 3 survey
diatas serta acuan dari best practise dalam
project management (PMBOK) maka
penyebab kegagalan proyek dapat
dipetakan dalam fishbone diagram berikut
ini:

1. Scope
faktor pertama dari penyebab kegagalan
proyek adalah cakupan atau scope proyek
yang dilakukan. Terkadang hal ini
dianggap hal sepele bagi sebagian project
manager, dimana mereka membuat scope
menjadi fleksibel, tanpa dibatasi secara
jelas dan dibuat mekanisme perubahan
(change request) jika terjadi penambahan
scope proyek. Akibatnya terjadi
penambahan scope diluar perencanaan
yang berakibat pada pembengkakan biaya
dan molornya waktu pelaksanaan proyek.
DImensi ini juga menentukan baik
buruknya sebuah perencanaan proyek
yang dilakukan, dimana hal ini akan
sangat menentukan keberhasilan
pelaksanaan proyek.
2. Time
Dimensi berikutnya adalah waktu.
Keterlambatan pelaksanaan suatu proyek
dapat berakibat fatal bagi proyek tersebut.
Waktu yang terlambat tentunya akan
membutuhkan biaya ekstra diluar biaya
proyek yang telah direncanakan. Selain
itu, keterlambatan juga dapat berakibat
pada buruknya image pengembang di
mata pemberi proyek. Keterlambatan
pelaksanaan proyek dapat disebabkan
oleh berbagai hal, diantaranya adalah
penambahan scope, pergantian tim proyek
di tengah-tengah pelaksanaan proyek dan
atau konflik internal yang terjadi pada
perusahaan pemilik proyek. Sehingga
memanage waktu pelaksanaan proyek
dengan baik merupakan salah satu kunci
keberhasilan dalam pelaksanaan proyek.
3. Cost
Dimensi berikutnya adalah biaya proyek.
Masih berkaitan erat dengan scope dan
time, biaya proyek pun merupakan salah
satu faktor penentu keberhasilan proyek.
Besar kecilnya alokasi biaya untuk
pelaksanaan proyek akan mempengaruhi
waktu dan tentunya kualitas yang
diharapkan. Permasalahan pada dimensi
ini biasanya terjadi ketika proyek sudah
mengalami keterlambatan dan atau
perkembangan scope proyek diluar
perencanaan.
4. Quality
Hal penting lain dalam pelaksanaan
proyek adalah kualitas proyek tersebut.
Untuk proyek pengembangan sistem
informasi, kualitas proyek ditentukan oleh
user melalui mekanisme user acceptance
test, dimana user akan melakukan
pengujian apakah sistem yang dibangun
telah memenuhi spesifikasi yang
ditentukan sebelumnya. Untuk beberapa
kasus tertentu, terkadang kualitas
dikorbankan demi menekan kerugian
atau memperbesar keuntungan.
5. Human resource
Mengelola manusia dengan berbagai
karakter bukanlah hal mudah dalam
sebuah proyek yang sifatnya sementara
dan berlangsung dalam waktu yang relatif
singkat. Konflik antar anggota tim
maupun konflik antara anggota tim
dengan project manager menjadi
penghalang yang dapat menggagalkan
tercapainya tujuan proyek sesuai dengan
perencanaan awal. Isu lain adalah
rendahnya kompetensi SDM yang
dimiliki dapat mengancam selesainya
proyek tepat waktu dengan kualitas yang
telah ditentukan. Permasalahan-
permasalahan klasik seperti ini terkadang
menjadi penting untuk dipikirkan dalam
suatu manajemen proyek. Menciptakan
iklim kerja yang kondusif mungkin dapat
menjadi salah satu alternatif dalam
mengatasi permasalahan sumberdaya
manusia dalam proyek.
6. Communication
Kesalahpahaman yang terjadi baik antar
tim proyek maupun antara tim proyek
dengan project manager dapat memicu
konflik yang berpotensi memperburuk
atmosfir kerja yang dibangun. Dengan
load yang tidak menentu, kesalahpahaman
bisa berujung menjadi pertikaian. Untuk
itu, komunikasi yang baik antar sesama
anggota tim proyek perlu dijalin. Selain
itu, kegagalan komunikasi biasanya
terjadi ketika mensosialisasikan project
task kepada anggota dan atau transfer
knowledge tentang proyek yang akan
dilaksanakan. Hal ini dapat berakibat fatal
dimana masing-masing anggota proyek
akan mempunyai persepsi yang berbeda
tentang pekerjaan yang dilakukan.
Bahkan besar kemungkinan apa yang
dikerjakan oleh anggota tim tidak selaras
dengan tujuan dan scope proyek tersebut.
7. Risk
Ada 3 (tiga) hal penting dalam memanage
resiko terkait dengan pelaksanaan proyek,
yaitu bagaimana merencanakan tindakan
korektif atas resiko yang kemungkinan
muncul (preventive action), atau
mengambil tindakan yang diperlukan
ketika resiko tersebut terjadi dan tidak
dapat lagi dicegah dengan tujuan
meminimalisasi dampak yang
ditimbulkan akibat resiko
tersebut(corrective action), atau
menerima resiko tersebut (accepted the
risk) jika cost of risk yang ditimbulkan
lebih besar daripada mengatasi resiko
tersebut.
8. Project Change
Perubahan lingkungan perusahaan
pemilik proyek, baik lingkungan eksternal
maupun internal, dapat mengakibatkan
munculnya permintaan-permintaan baru
yang secara langsung maupun tidak
langsung akan mempengaruhi scope
proyek yang telah direncanakan.
Perubahan tersebut otomatis akan
mempengaruhi waktu pelaksanaan dan
biaya yang dibutuhkan. Jika perubahan
terjadi tanpa adannya penambahan biaya
yang sesuai dan atau pemunduran waktu
pelaksanaan proyek, maka masalah ini
bisa menjadi salah satu penyebab
gagalnya proyek. Untuk itu penting bagi
project manager dalam mengelola
perubahan yang terjadi, salah satunya
adalah dengan mengendalikan perubahan
melalui change request form yang berarti
adanya kesepakatan baru dalam kontrak
terkait perubahan yang terjadi.

Pemodelan dan Arsitektur Agile
Istilah Agile sendiri terdiri dari dua
pengertian, yaitu: pertama pengertian dari
segi filosofi, dan kedua pengertian dari
segi pedoman pengembangan perangkat
lunak. Dari segi filosofi, agile mempunyai
arti antara lain: mendorong demi
terciptanya kepuasan pelanggan;
mempercepat delivery perangkat lunak
secara bertahap (incremental); tim proyek
yang ramping dan mempunyai motifasi
yang sangat tinggi; minimasi pekerjaan;
serta menyederhanakan (birokrasi)
keseluruhan proses pembangunan
perangkat lunak. Sedangkan dari segi
pedoman pengambangan perangkat lunak,
agile mempunyai pengertian, bahwa
secara aktif dan berkesinambungan,
antara pengembang dengan pelanggan
harus senantiasa menjalin kerjasama dan
komunikasi dengan baik.
Menurut Ivar Jacobson, agility
mengandung pengertian bahwa perubahan
(change) merupakan "hati" dan "jiwa"
dari perangkat lunak. Maksudnya adalah,
bahwa perubahan terhadap requirements
pelanggan, silih bergantinya anggota tim,
dan perubahan kebutuhan teknologi yang
berimplikasi terhadap produk yang
dihasilkan merupakan suatu hal yang
sangat wajar terjadi. Hampir semua
proyek pengambangan perangkat lunak
pasti mengalami hal tersebut. Sedangkan
menurut Goldman et al, agility
merupakan sesuatu yang dinamis,
mempunyai kontent yang spesifik,
menaggapi perubahan secara agresif, dan
beroriantasi pada pertumbuhan.
Dari definisi menurut Ivar Jacobson dan
Goldman et al, di atas dapat ditarik
kesimpulan bahwa Agility merupakan
suatu kemampuan atau "jiwa" yang harus
dimiliki oleh tim pengambangan
perangkat lunak. Kemampuan tersebut
antara lain berupa: kemampuan segera
menindaklanjuti terjadinya perubahan
secara efektif; kemampuan berkomunikasi
antar stakeholders secara efektif;
menganggap bahwa pelanggan
merupakan pihak yang berada di dalam
tim yang sama; kemampuan
mengorganisasikan tim (memberikan
motivasi) agar mampu meningkatkan
performa kinerja tim; secara tepat waktu
dan berkesinambungan dapat men-deliver
perangkat lunak yang telah dijadwalkan.
Agile Process
Agile Process merupakan sekelompok
aktifitas pembangunan perangkat lunak
secara iteratif yang menekankan pada
aktifitas konstruksi (desain dan koding).
Agile Process mengeliminasi sebagian
besar waktu untuk melakukan
perencanaan sistem dan berusaha sebisa
mungkin mematuhi jadwal deliver sistem
yang telah dijanjikan. Requirements yang
dibutuhkan secara langsung di-drive oleh
pelanggan itu sendiri, dan apabila terjadi
perubahan terhadap requirements
tersebut, pengembang dituntut mampu
beradaptasi dengan perubahan yang
terjadi.
A. Masalah-masalah Potensial dari
Pendekatan Tradisional:
Masalah dengan model waterfall :
1. Perubahan sulit dilakukan karena
sifatnya yang kaku.
2. karena sifat kakunya, model ini
cocok ketika kebutuhan
dikumpulkan secara lengkap
sehingga perubahan bisa ditekan
sekecil mungkin. Tapi pada
kenyataannya jarang sekali
konsumen/pengguna yang bisa
memberikan kebutuhan secara
lengkap, perubahan kebutuhan
adalah sesuatu yang wajarterjadi.
3. Waterfall pada umumnya
digunakan untuk rekayasa sistem
yang besar dimana proyek
dikerjakan di beberapa tempat
berbeda, dan dibagi menjadi
beberapa bagian sub-proyek.
Masalah dengan model Incremental:
1. Cocok untuk proyek berukuran kecil
(tidak lebih dari 200.000 baris coding)
2. Mungkin terjadi kesulitan untuk
memetakan kebutuhan pengguna ke
dalam rencana spesifikasi masing-masing
hasil increment
Masalah dalam model RAD (Rapid
Application Development):
1. Tidak cocok untuk proyek skala besar
2. Proyek bisa gagal karena waktu yang
disepakati tidak dipenuhi
3. Sistem yang tidak bisa dimodularisasi
tidak cocok untuk model ini
4. Resiko teknis yang tinggi juga kurang
cocok untuk model ini
Masalah model Prototyping adalah :
1. Pelanggan kadang tidak melihat
atau menyadari bahwa perangkat
lunak yang ada belum
mencantumkan kualitas
perangkat lunak secara
keseluruhan dan juga belum
memikirkan kemampuan
pemeliharaan untuk jangja waktu
lama.
2. penegmbang biasanya ingin
cepat menyelesaikan proyek.
Sehingga menggunakan
algoritma dan bahasa
pemrograman yang sederhana
untuk membuat prototyping
lebih cepat selesai tanpa
memikirkan lebih lanjut bahwa
program tersebut hanya
merupakan cetak biru sistem .
3. Hubungan pelanggan dengan
komputer yang disediakan
mungkin tidak mencerminkan
teknik perancangan yang baik.
B. Pengertian Agile Method
Agile methods merupakan salah satu dari
beberapa metode yang digunakan dalam
pengembangan sooftware. Agile method
adalah jenis pegembangan sistem jangka
pendek yang memerlukan adaptasi cepat
dan pengembang terhadap perubahan
dalam bentuk apapun.
Dalam Agile Software Development
interaksi dan personel lebih penting dari
pada proses dan alat, software yang
berfungsi lebih penting daripada
dokumentasi yang lengkap, kolaborasi
dengan klien lebih penting dari pada
negosiasi kontrak, dan sikap tanggap
terhadap perubahan lebih penting
daripada mengikuti rencana.
Agile Method juga dapat diartikan
sekelompok metodologi pengembangan
software yang didasarkan pada prinsip-
prinsip yang sama atau pengembangan
system jangka pendek yang memerlukan
adaptasi cepat dari pengembang terhadap
perubahan dalam bentuk apapun
C. Prinsip/Tujuan Agile Software
Development
Agile Software Development juga melihat
pentingnya komunikasi antara anggota
tim, antara orang-orang teknis dan
businessmen, antara developer dan
managernya. Ciri lain adalah klien
menjadi bagian dari tim pembangun
software. Ciri-ciri ini didukung oleh 12
prinsip yang ditetapkan oleh Agile
Alliance. Menurut Agile Alliance, 12
prinsip ini adalah bagi mereka yang ingin
berhasil dalam penerapan Agile Software
Development:
1. Kepuasan klien adalah prioritas utama
dengan menghasilkan produk lebih awal
dan terus menerus.
2. Menerima perubahan kebutuhan,
sekalipun diakhir pengembangan.
3. Penyerahan hasil/software dalam
hitungan waktu beberapa minggu sampai
beberapa bulan.
4. Pihak bisnis dan pengembang harus
bekerja sama setiap hari selama
pengembangan berjalan.
5. Membangun proyek dilingkungan
orang-orang yang bermotivasi tinggi yang
bekerja dalam lingkungan yang
mendukun dan yang dipercaya untuk
dapat menyelesaikan proyek.
6. Komunikasi dengan berhadapan
langsung adalah komunikasi yang efektif
dan efisien
7. Software yang berfungsi adalah ukuran
utama dari kemajuan proyek
8. Dukungan yang stabil dari sponsor,
pembangun, dan pengguna diperlukan
untuk menjaga perkembangan yang
berkesinambungan
9. Perhatian kepada kehebatan teknis dan
desain yang bagus meningkatkan sifat
agile
10. Kesederhanaan penting
11. Arsitektur, kebutuhan dan desain yang
bagus muncuk dari tim yang mengatur
dirinya sendiri
12. Secara periodik tim evaluasi diri dan
mencari cara untuk lebih efektif dan
segera melakukannya.
Dua belas prinsip tersebut menjadi suatu
dasar bagi model-model proses yang
punya sifat agile. Dengan prinsip-prinsip
tersebur Agile Process Model berusaha
untuk menyiasati 3 asumsi penting
tentang proyek software pada umumnya:
Kebutuhan software sulit diprediksi dari
awal dan selalu akan berubah. Selain itu,
prioritas klien juga sering berubah seiring
berjalannya proyek.
Desain dan pembangunan sering
tumpang tindih. Sulit diperkirakan
seberapa jauh desain yang diperlukan
sebelum pembangunan.
Analisis, desain, pembangunan dan
testing tidak dapat diperkirakan seperti
yang diinginkan.
Kelebihan dari Agile Method
1. Meningkatkan kepuasan kepada klien
2. Pembangunan system dibuat lebih
cepat
3. Mengurangi resiko kegagalan
implementasi software dari segi non-
teknis
4. Jika pada saat pembangunan system
terjadi kegagalan,kerugian dar segi materi
relative kecil.
Faktor Manusia Dalam Agile Process
Model
Kunci faktor manusia pada model ini
adalah proses didasari pada kebutuhan
orang dan tim bukan sebaliknya, Untuk
dapat sukses menerapkan model proses
ini, pada faktor manusia ada beberapa
kunci penting:
1. Kompetensi: ketrampilan dalam
membangun dan pengetahuan
tentang proses membangun
2. Fokus: memiliki fokus yang
sama sekalipun peran dalam tim
berbeda
3. Kolaborasi : kerja sama dengan
klien, anggota tim dan manajer.
4. Kemampuan ambil keputusan :
tim pembangun memiliki
otonomi dalam pengambilan
keputusan terkait teknis dan
proyek
5. Kemampuan fuzzy problem-
solving: mampu menyelesaikan
memilah masalah yang penting
untuk dipecahkan segera atau
nanti.
6. Saling percaya dan hormat:
kekompakan tim yang didukung
oleh rasa percaya dan saling
menghargai satu sama lain.
7. Manajemen diri: tim mengatur
diri untuk selesaikan proyek,
mengatur proses untuk
disesuaikan dengan
lingkungannya, tim menjadwal
dirinya untuk menyerahkan hasil.
D. Model-model Agile method
1. Extreme Programmning (XP)
2. Adaptive Software Development
(ASD)
3. Dynamic Systems Development
Method (DSDM)
4. Scrum Methodology
5. Crystal
6. Feature Driven Development (FDD)
7. Agile Modeling (AM)
8. Rational Unified Process
1. Extreme Programmning (XP)
Proyek Pemrograman Extreme pertama
dimulai 6 Maret 1996. Extreme
Programming adalah salah satu dari
beberapa Proses Agile populer. Sudah
terbukti sangat sukses di banyak
perusahaan dari berbagai ukuran dan
industri di seluruh dunia.
Extreme Pemrograman berhasil karena
menekankan kepuasan pelanggan. Alih-
alih memberikan semua yang anda
mungkin inginkan pada tanggal beberapa
jauh di masa depan proses ini
memberikan perangkat lunak yang Anda
butuhkan saat Anda membutuhkannya.
Extreme Pemrograman memberdayakan
pengembang Anda untuk percaya diri
menanggapi perubahan kebutuhan
pelanggan, bahkan terlambat dalam siklus
hidup.
Extreme Pemrograman menekankan kerja
sama tim. Pengelola, pelanggan, dan
pengembang semua mitra setara dalam
sebuah tim kolaboratif. Extreme
Pemrograman menerapkan, sederhana
namun efektif yang memungkinkan tim
lingkungan menjadi sangat produktif. Tim
mengorganisir diri mengatasi masalah
untuk menyelesaikannya seefisien
mungkin.
Extreme Pemrograman meningkatkan
proyek perangkat lunak dalam lima cara
penting; komunikasi, kesederhanaan,
umpan balik, rasa hormat, dan keberanian.
Extreme Programmer selalu
berkomunikasi dengan pelanggan mereka
dan programer sesama. Mereka terus
desain mereka yang sederhana dan bersih.
Mereka mendapatkan umpan balik dengan
menguji perangkat lunak mereka dimulai
pada hari pertama. Mereka memberikan
sistem ke pelanggan sebagai perubahan
sedini mungkin dan melaksanakan seperti
yang disarankan. Setiap keberhasilan
kecil memperdalam rasa hormat mereka
atas kontribusi yang unik dari masing-
masing dan setiap anggota tim. Dengan
dasar Extreme pemrogram dapat berani
merespon perubahan kebutuhan dan
teknologi.
Aspek yang paling mengejutkan dari
Extreme Programming adalah aturan
sederhana. Extreme Pemrograman sangat
mirip jig gergaji teka-teki. Ada banyak
potongan-potongan kecil. Individual
potongan
Extreme Programming adalah metode
pengembangan perangkat lunak yang
ringan dan termasuk salah satu agile
methods yang dipelopori oleh Kent Beck,
Ron Jeffries, dan Ward Cunningham.
Extreme Programming merupakan agile
methods yang paling banyak digunakan
dan menjadi sebuah pendekatan yang
sangat terkenal. Sasaran Extreme
Programming adalah tim yang dibentuk
berukuran antara kecil sampai medium
saja, tidak perlu menggunakan sebuah tim
yang besar. Hal ini dimaksudkan untuk
menghadapi requirements yang tidak jelas
maupun terjadinya perubahan-perubahan
requirements yang sangat cepat.
Extreme Programming sebagai sebuah
metode yang dinamis diperlihatkan dalam
empat values yang dimilikinya dan
keempatnya merupakan dasar-dasar yang
diperlukan dalam Extreme Programming.
Kent Beck menyatakan bahwa tujuan
jangka pendek individu sering
berbenturan dengan tujuan sosial jangka
panjang. Karena itu dibuatlah values yang
menjadi aturan, hukuman, dan juga
penghargaan. Keempat values tersebut
adalah :
1. Komunikasi (Communication)
Tugas utama developer dalam
membangun suatu sistem perangkat lunak
adalah mengkomunikasikan kebutuhan
sistem kepada pengembang perangkat
lunak. Komunikasi dalam Extreme
Programmning dibangun dengan
melakukan pemrograman berpasangan
(pair programming). Developer
didampingi oleh pihak klien dalam
melakukan coding dan unit testing
sehingga klien bisa terlibat langsung
dalam pemrograman sambil
berkomunikasi dengan developer.
Tujuannya untuk memberikan pandangan
pengembang sesuai dengan pandangan
pengguna sistem.
2. Kesederhanaan (Simplicity)
XP mencoba untuk mencari solusi paling
sederhana dan praktis. Perbedaan metode
ini dengan metodologi pengembangan
sistem konvensional lainnya terletak pada
proses desain dan coding yang terfokus
pada kebutuhan saat ini daripada
kebutuhan besok, seminggu lagi atau
sebulan lagi. Lebih baik melakukan hal
yang sederhana dan mengembangkannya
besok jika diperlukan.
3. Umpan Balik (Feedback)
Hal ini diperlukan untuk mengetahui
kemajuan dari proses dan kualitas dari
aplikasi yang dibangun. Informasi ini
harus dikumpulkan setiap interval waktu
yang singkat secara konsisten. Ini
dimaksudkan agar hal-hal yang menjadi
masalah dalam proses pengembangan
dapat diketahui sedini mungkin. Setiap
feed back ditanggapi dengan melakukan
tes, unit test atau system integration dan
jangan menunda karena biaya akan
membengkak (uang, tenaga, waktu).
4. Keberanian (Courage)
Berani mencoba ide baru. Berani
mengerjakan kembali dan setiap kali
kesalahan ditemukan, langsung
diperbaiki. Contoh dari courage adalah
komitmen untuk selalu melakukan design
dan coding untuk saat ini dan bukan untuk
esok. Ketika ada kode yang terlalu rumit,
sulit dibaca dan dipahami, tidak sesuai
dengan kemauan pelanggan, dll maka
seharusnya kode program seperti itu di
refactor (kalau perlu dibangun ulang). Hal
ini menjadikan pengembang merasa
nyaman dengan refactoring program
ketika diperlukan.
Extreme Programming menggunakan
pendekatan berorientasi objek. Pada
aktifitas Perencanaan terjadi
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.
Terjadi pemeriksaan dan pertimbangkan
resiko dan aktifitas Desain kegiatannya
sederhana yaitu memanfaatkan kartu CRC
(Class-Responsibility-Collaborator) untuk
identifikasi dan mengatur class-class di
konsep OO. Jika temuikan kesulitan,
prototype dibangun [ini namanya spike
solution].
Dilakukannya refactoring, yaitu
mengembangkan desain dari program
setelah ditulis. Pada aktifitas Pengkodean
adalah penyiapan unit test sebelum
pengkodean dipakai sebagai focus
pemrogram untuk membuat program. Pair
programming dilakukan untuk real time
program solving dan real time quality
assurance. Proses pengujiannya
menggunakan unit test yang dipersiapkan
sebelum pengkodean Menggunakan
pendekatan berorientasi objek
Sebagai sebuah metodologi untuk
mengembangkan peragkat lunak Extreme
Programming tentu memiliki siklus hidup.
Siklus hidup pada Extreme Programming
ini terdapat lima fase yaitu :
1. Exploration Phase
2. Planning Phase
3. Iteration to Release Phase
4. Productionizing Phase
5. Maintenance Phase

6. Death Phase

Gambar 2. Fase Extreme Programming
(XP) sebelum dimodifikasi
Pada bagian ini akan dilakukan
penambahan fase pada Extreme
Programmning yaitu dengan menyisipkan
sebuah fase yang disebut requirements
management phase. Fase ini disisipkan
tidak sekuensial tapi paralel dengan fase
planning. Tujuan penyisipan secara
paralel ini adalah mengurangi
kemungkinan Extreme Programmning
keluar dari lingkup agile. Tiga hal yang
dilakukan yaitu:
1. Requirements Management
2. Pendokumentasian sederhana (simple
documenting)
3. Mempertahankan index card yang telah
diimplementasi dengan baik

Gambar 3: Fase pada Extreme
Programming (XP) setelah modifikasi
Setelah dilakukan modifikasi terdapat
beberapa pengaruh pada practice-nya.
Dari dua belas practice yang terdapat pada
Extreme Programmning, ada empat buah
practice yang mempunyai singgungan
kuat dengan requirements management
yaitu planning game, metaphor, 40-hour
week, On-site customer. Dari keempatnya
planning game-lah yang paling besar
keterkaitannya dengan requirements. Pada
bagian ini akan dipaparkan yang terjadi
pada keempat practice tersebut setelah
dilakukan modifikasi pada Extreme
Programmning tersebut.
Planning Game
Berikut ini adalah tabel setelah dilakukan
perubahan pada siklus:


Sebelum modifikasi, pada exploration
phase terdapat tiga kegiatan yaitu write
story, estimate story, dan split story.
Setelah dilakukan modifikasi satu
kegiatan lagi yang dikerjakan oleh pihak
development adalah summarize stories
into simple document.
Demikian juga pada steering phase yang
pada awalnya hanya terdiri atas kegiatan-
kegiatan iteration, recovery, new story,
dan re-estimate, setelah modifikasi
ditambah satu lagi yaitu update simple
document. Proses ini sebenarnya sama
dengan summarize stories pada
exploration phase, perbedaannya pada
steering phase adalah untuk
mengantisipasi adanya new story yang
dikerjakan oleh pihak bisnis.
1. Metaphor
Metaphor merupakan panduan (guidance)
dalam melakukan pengembangan secara
keseluruhan. Metaphor di sini
memerlukan penjelasan rinci.
Requirements yang diperoleh melalui
proses summarize stories tersebut
berperan sebagai metaphor, sedangkan
penjelasan rincinya ada pada story awal.
2. 40-hour week
Story yang telah selesai ditulis oleh
customer langsung dirangkum ke dalam
simple document pada fase requirements
management. Terjadi penambahan waktu
secara signifikan.
3. On-site Customer
Komunikasi dengan on-site customer
tetap dilakukan terus, termasuk dalam
melakukan summarize stories. Sifatnya
hanya merangkum story ke dalam
requirements yang akan menjadi feature
pada sistem yang dibuat.
Penerapan Extreme Programmning
Beberapa hal yang harus dipertimbangkan
sebelum seseorang masuk dalam dunia
Extreme Programmning adalah sebagai
berikut:
1. User harus memahami konteks bisnis
yang akan dikembangkan sistemnya,
sehingga developer dapat menangkap
sistem secara aplikatif dan dapat
mengusulkan teknologi apa yang dapat
dikembangkan dalam sistem barunya.
2. Akan lebih efektif apabila developer
pernah menangani proyek pengembangan
sistem yang sejenis sehingga dapat
memberikan usulan model sistem baru, di
samping alasan bahwa developer telah
memiliki template aplikasi sistem tersebut
untuk dijadikan prototype sistem baru.
Hal ini akan berimplikasi kepada
kemudahan dalam konstruksi sistem
karena dikembangkan berdasarkan
template yang sudah ada.
3. Extreme programming menuntut
komunikasi antar developer dan user
secara intensif dan komunikasi internal
antar developer secara komprehensif,
sehingga akan lebih representatif apabila
tahap pengembangan sistem dilakukan di
lokal yang mendukung proses komunikasi
tersebut.
Extreme Programmning adalah suatu
bentuk pembangunan perangkat lunak
yang berbasis nilai kemudahan,
komunikasi, umpan balik, dan keberanian.
Bekerja dalam whole team bersama-sama
dengan praktek yang mudah. Dalam
Extreme Programming terdapat 12
practices utama yaitu :
1. Planning Game
Hubungan antara Customer dengan
Programer untuk memperkirakan
kenbutuhan kebutuhan dari Custumer
dalam implementasinya.
2. Small, frequent releases
Memproduksi dengan cepat.
3. System metaphors
System metaphors antara Customer
dengan Programeruntuk menunjukkan
semua perkembangan dengan
menjelaskan bagaimana cara kerja
system.
2. Simple design
Perhatiannya pada pendisainnan atau
perancngan solusi yang sederhana
3. Testing (unit testing & TDD)
Pelaksanaan pengujian atau testing
keseluruhan
4. Frequent refactoring
Penyusunan system kembali dengan cara
duplikat atau salinan,memperbaiki
komunikasi, menambahkan kelenturan
5. Pair programming
Dua orang menulis kode pada 1 komputer
6. Collective code ownership
Siapapun dapat merubah bagian pada
pengkodean setiap saat.
7. Continuous integration
Bagian baru code di gabungkan ke dalam
kode dasar
8. 40-hour weak
Max 40 jam kerja seminggu,
9. On-site customer
Customer harus hadir dan ada setiap saat
untuk teamnya.
10. Coding standards
Terdapat aturan pengkodean dan di ikuti
oleh programmer.
Keuntungan dan Kerugian XP
Keuntungan Extreme Programmning:
Menjalin komunikasi yang baik dengan
client. Meningkatkan komunikasi dan
sifat saling menghargai antar developer.
Kerugian Extreme Programmning:
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).
2. Adaptive Software Development
(ASD)
Adaptive Software Development (ASD)
diajukan oleh Jim Highsmith sebagai
teknik untuk membangun software dan
sistem yang kompleks. Filosofi yang
mendasari Adaptive Software
Development (ASD) adalah kolaborasi
manusia dan tim yang mengatur diri
sendiri.
System kerja adaptive software
development : Collaboration dan Learning
Adaptive cycle planning yaitu
menggunakan informasi awal seperti misi
dari klien, batasan proyek dan kebutuhan
dasar untuk definisikan rangkaian
software increment (produk software yang
secara berkala diserahkan)
a. Collaboration : orang-orang yang
bermotivasi tinggi bekerja sama: saling
melengkapi, rela membantu, kerja keras,
trampil di bidangnya, dan komunikasikan
masalah untuk hasilkan penyelesaian yang
efektif.
b. Learning: tim pembangun sering
merasa sudah tahu semua hal tentang
proyek, padahal tidak selamanya begitu.
Karena itu proses ini membuat mereka
belajar lebih tentang proyek melalui 3
cara:
Focus group: klien dan pengguna
memberi masukan terhadap software
Formal Technique Reviews: Tim ASD
lengkap melakukan review
Postmortems: Tim ASD lakukan
instrospeksi pada kinerja dan proses.
3. 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 prototyping
yang incremental dalam lingkungan yang
terkondisikan. Metode ini akan
membangun software dengan cepat: 80%
dari proyek diserahkan dalam 20% dari
waktu total untuk menyerahkan proyek
secara utuh.
Dynamic System Development Method
dapat dikombinasikan dengan Extreme
Programmning menghasilkan kombinasi
model proses yang mengikuti Dynamic
System Development Method dan praktek
yang sejalan dengan Extreme
Programmning.
Dynamic System Development Method
memiliki beberapa aaktifitas seperti :
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 : hasilkan
incremental prototype yang perlihatkan
fungsi software ke klien untuk dapatkan
kebutuhan lebih jelas dan konfirmasi
Design and Build Iteration : cek ulang
prototype yang dibangun untuk pastikan
bahwa prototype dibangun dengan cara
yang memungkinkan fungsi tersebut
benar-benar bekerja
Implementation: menempatkan software
pada lingkungan sebenar sekalipun belum
lengkap, atau masih ada perubahan.
4. Scrum Methodology
Pertama kali diperkenalkan oleh Jeff
Sutherland tahun awal tahun 1990an, dan
dikembangkan selanjutnya dilakukan oleh
Schwaber dan Beedle. Pada dasarnya
Scrum merupakan salah satu komponen
dari metodologi pengembangan Agile
mengenai pertemuan harian untuk
membahas kemajuan dan XP adalah
menekankan metodologi yang berbeda
sepasang ujian dulu pemrograman dan
pembangunan.
Scrum menguraikan proses untuk
mengidentifikasi dan katalogisasi
pekerjaan yang perlu dilakukan,
memprioritaskan yang bekerja dengan
berkomunikasi dengan pelanggan atau
wakil pelanggan, dan pelaksanaan yang
bekerja menggunakan rilis iterative dan
memiliki tujuan utama untuk
mendapatkan perkiraan berapa lama akan
pembangunan. XP lebih lanjut tentang
pengembang membantu menyelesaikan
pekerjaan secepat dan maintainably
mungkin
Scrum memiliki prinsip yaitu:
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 memiliki aktifitas yang meliputi
:
Backlog
Backlog adalah daftar kebutuhan yang
jadi prioritas klien, dan daftar yang dibuat
dapat bertambah
Sprints
Aktifitas Sprints merupakanunit 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.
Scrum Meetings
Aktifitas Scrum Meeting merupakan
pertemuan yang rutin dilakukan perhari
untuk evaluasi apa yang dikerjakan,
hambatan yang ada, dan target
penyelesaian untuk bahan meeting
selanjutnya.
Demo
Aktifitas Demo adalah penyerahan
software increment ke klien
didemonstrasikan dan dievaluasi oleh
klien.
Perbedaan Scrum dan XP
1. Scrum adalah sebuah proses
manajemen proyek, XP adalah sebuah
praktek pemrograman. Keduanya adalah
"gesit" teknik dan sering digunakan
bersama-sama.
2. Scrum menguraikan proses untuk
mengidentifikasi dan katalogisasi
pekerjaan yang perlu dilakukan,
memprioritaskan yang bekerja dengan
berkomunikasi dengan pelanggan atau
wakil pelanggan, dan pelaksanaan yang
bekerja menggunakan rilis iteratif.
3. Scrum tujuan utama adalah untuk
mendapatkan perkiraan berapa lama akan
pembangunan. XP lebih lanjut tentang
pengembang membantu menyelesaikan
pekerjaan secepat dan maintainably
mungkin.
4. Beberapa perbedaan utama adalah
bahwa scrum berfokus pada sprint pendek
lebih terstruktur, dan log kembali
memprioritaskan item. Beberapa XP
fokus lebih pada pemrograman
dipasangkan, memprioritaskan tugas, dan
lebih pembangunan berbasis tes.
Keduanya bekerja di iterasi dan keduanya
cukup fleksibel untuk menangani proyek
yang mudah menguap berubah.
5. Scrum merupakan salah satu komponen
dari metodologi pengembangan Agile
mengenai pertemuan harian untuk
membahas kemajuan dan XP adalah
menekankan metodologi yang berbeda
sepasang ujian dulu pemrograman dan
pembangunan.
5. 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.
6. Feature Driven Development
Feature Driven Development merupakan
model proses praktis untuk keahlian
proses software engineering, Feature
merupakan sebuah fungsi yang berharga
dimana dapat dilaksanakan.
Keuntungan dari metode feature :
User dapat menggambarkan
dengan mudah bentuk system.
Dapat di organisasikan atau
diatur ke dallamkelompok bisnis
yang hirarki.
Desain dank ode lebih mudah
diperiksa secara efektif.
Merancang proyek, penjadwalan
dan jalur diarahkan oleh feature.
7. Agile Modeling
Dalam situasi pembangunan 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. Agile Modeling
adalah suatu metodologi yang praktis
untuk dokumentasi dan pemodelan system
software. Agile Modeling adalah
kumpulan nilai-nilai, prinsip dan praktek-
praktek untuk memodelkan software agar
dapat diaplikasian pada software
development proyek secara efektif.
8. Rational Unified Process
Rational Unified Process, adalah suatu
kerangka kerja proses pengembangan
perangkat lunak iteratif yang dibuat oleh
Rational Software, suatu divisi dari IBM
sejak 2003. RUP bukanlah suatu proses
tunggal dengan aturan yang konkrit,
melainkan suatu kerangka proses yang
dapat diadaptasi dan dimaksudkan untuk
disesuaikan oleh organisasi pengembang
dan tim proyek perangkat lunak yang
akan memilih elemen proses sesuai
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. Dengan
menggunakan model ini, RUP membagi
tahapan pengembangan perangkat
lunaknya ke dalam 4 fase sebagai berikut.
Inception, merupakan tahap untuk
mengidentifikasi sistem yang akan
dikembangkan. Aktivitas yang dilakukan
pada tahap ini antara lain mencakup
analisis sistem eksisting, perumusan
sistem target, penentuan arsitektur global
target, identifikasi kebutuhan, perumusan
persyaratan 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 aliran
tampilan, penentuan design pattern yang
digunakan, pemodelan diagram UML, dan
pembuatan dokumentasi.
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
domain perilaku (diagram sequence) dan
domain struktural (diagram class,
component, deployment). Apabila disain
yang dibuat telah sesuai dengan analisis
sistem, maka implementasi dengan bahasa
pemrogramanan 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.
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.
Prinsip dalam Agile Modeling :
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 local
E. Dokumentasi Agile
Eelco Gravendeel menyatakan bahwa
hanya ada dua jenis dokumentasi dalam
Agile:
Dokumen yang diperlukan untuk
semua anggota tim untuk bekerja pada
proyek- Dalam dunia yang ideal, tim ini
merelokasi dan semua pengetahuan akan
dibagi dan diserahkan dengan komunikasi
langsung. Namun, jika tim didistribusikan
dan pengetahuan harus ditransfer
kemudian menulis dokumen dan
melengkapi dengan panggilan audio
visual akan sangat berguna. Satu set
dokumen minimal yang umum juga
dibutuhkan oleh tim untuk berbicara
bahasa macam-macam dan berada di level
yang sama pemahaman.
Eelco menyatakan bahwa banyak
dokumen, yang dibuat untuk mendukung
penciptaan produk, panggilan untuk
perhatian lebih karena mereka dibuang
segera setelah proyek selesai.
Dokumentasi untuk dikirim dengan
produk akhir - Adalah dokumen yang
merupakan bagian dari pengiriman
produk dan kelanjutan hubungan dengan
klien yang baik. Contoh umum termasuk:
User manual
Deployment manual
Pemeliharaan manual (ditujukan untuk
mengoperasikan perangkat lunak)
Teknis dokumentasi (ditujukan untuk
menjaga basis kode), dll
Kelebihan dan Kekurangan Agile
Kelebihan agile:
a. Meningkatkan rasio kepuasan
pelanggan
b. Bisa melakukan review pelanggan
mengenai software yang di buat lebih
awal.
Kekurangan agile:
1. Total lama pengembangan menjadi
lebih lama
2. Meningkatkan resiko kesalahan teknis
3. Proses pengembangan menjadi agak
kurang terorganisir.
Implementasi
Metodologi agile project management
dalam beberapa tahun terakhir telah
banyak digunakan untuk
mengembangkan, mengimplementasikan
sistem teknologi informasi, seiring
dengan mulai banyak diadopsinya konsep
agile pada proses manufaktur dan
produksi. Konsep agile project
management itu sendiri mengikuti life
cycle diatas dengan menggabungkan
konsep agility dalam prosesnya. Agility
itu sendiri adalah kemampuan untuk
membuat dan merespon perubahan
(Highsmith, 2009). Dengan kata lain
agility adalah kemampuan untuk
mengkombinasikan flexibilitas dan
stabilitas (Highsmith,2002). Dari
pengertian diatas bisa diambil titik temu
bahwa agile project management adalah
metodologi manajemen proyek yang
mempunyai adaptabilitas yang tinggi
terhadap perubahan yang terjadi di setiap
elemen-elemennya. Salah satu ciri dari
sebuah agility adalah adanya proses
iterasi yang terus menerus dan evaluasi
yang terus berjalan pada setiap proses
yang dilewatinya.
Berikut contoh kasus Agile:
Pelaku industri mulai sadar bahwa untuk
menyediakan produk yang murah,
berkualitas dan cepat, perbaikan di
internal perusahaan manufaktur adalah
tidak cukup. Peran serta supplier,
perusahaan transportasi dan jaringan
distributor adalah dibutuhkan. Pada
bagian produksi
Bagian ini bertugas secara fisik
melakukan transformasi dari bahan baku,
bahan setengan jadi atau komponen
menjadi produk jadi.
Kegiatan produksi dalam konteks SCM
tidak harus dilakukan dalam perusahaan.
Banyak perusahaan melakukan
outsourcing yaitu memindahkan kegiatan
produksi ke pihak subkontraktor,
sementara perusahaan konsentrasi ke
kegiatan yang menjadi core competency
mereka. Contoh perusahaan sepatu Nike.
Dalam kegiatan produksi, konsep lean
manufakturing yang mementingkan
efisiensi dan agile manufacturing yang
menekankan pada fleksibilitas dan
ketangkasan merespon perubahan adalah
dua hal yang penting.
F. Kesimpulan
Dari model-model proses di atas dapat
diambil beberapa poin penting:
1. komunikasi mempunyai peran penting
dalam pembanguna software
2. kebutuhan software tidak mudah untuk
diidentifikasikan secara lengkap
3. kerja sama dalam tim menentukan
kelancaran pembangunan software
Aktifitas yang terjadi di dalam Agile
Model Process tetap mengandung
aktifitas-aktifitas yang ada pada model
proses generasi sebelumnya seperti
waterfall, incremental, spiral dan RAD.
Selain itu, model-model proses di atas
tetaplah bukan model proses yang cocok
untuk setiap jenis software. Dengan
menerapkan metode agile ini diharapkan
pembangunan atau pengembangan
perangkat lunak bisa terkontrol dengan
baik dan selesai tepat pada waktu yang
telah ditetapkan.