Pendahuluan
Metodologi dalam perangkat lunak
digunakan untuk merancang atau membangun suatu perangkat lunak, dengan
perkembangan teknologi yang sangat pesat metodologi perangkat lunak juga
terjadi perubahan atau penambahan requirements. Dari model waterfall sampai
dengan model-model incremental. Semua metodologi yang berkembang sebelumnya
tidak mampu menangani kemungkinan perubahan atau penambahan requirements.
Metode pengembangan perangkat lunak telah dilacak kembali pada tahun 1957. Pada
tahun tersebut EA Edmonds telah memperkenalkan proses pengembangan perangkat
lunak adaptif. “Lightwight” merupakan metode pengembangan perangkat lunak yang
berkembang pada tahun 1990, sebagai reaksi terhadap apa yang disebut metode
“heavyweight”. Yang ditandai dengan kritik mereka terhadap metode waterfall
Pada tahun 90-an diperkenalkan dengan
metodologi baru yang dikenal dengan nama agile methods,kata Agile berarti
bersifat cepat, ringan, bebas bergerak, waspada. Metodologi yang dikenal
sebagai agile methods ini mengutamakan fleksibilitas terhadap
perubahan-perubahan yang terjadi selama pengembangan. Bahkan perubahan ataupun
penambahan pada saat fase terakhir pun teratasi apabila menggunakan metodologi
ini.
Agile Methods dikembangkan karena pada
metodologi tradisional terdapat banyak hal yang membuat proses pengembangan
tidak dapat berhasil dengan baik sesuai tuntutan user. Konsep Agile Software
Development dicetuskan oleh Kent Beck dan 16 rekannya dengan menyatakan bahwa
Agile Software Development adalah cara membangun software dengan melakukannya
dan membantu orang lain membangunnya sekaligus.
Pengertian Agile Method
Agile methods merupakan salah satu
dari beberapa metode yang digunakan dalam pengembangan software. 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
Extreme
Programming (XP)
Requirement
yang berubah dengan cepat menuntut lifecycles
yang lebih pendek, dan tidak selaras dengan metoda pengembangan tradisional,
yang pada umumnya memerlukan disain luas di awal dan mengakibatkan perubahan
desain yang terjadi kemudian memerlukan biaya yang lebih tinggi atau kehilangan
milestones.
Berdasarkan
hal ini kemudian dilahirkan konsep XP yang digagas oleh Kent Beck dan Ward
Cunningham pada Maret 1996. Metode XP merupakan yang terpopuler dari beberapa
metodologi pengembangan software yang dipakai untuk mengimplementasikan proyek
pengembangan perangkat lunak.
Tujuan
XP
Tujuan
utama XP adalah menurunkan biaya dari adanya perubahan software. Dalam metodologi pengembangan sistem tradisional,
kebutuhan sistem ditentukan pada tahap awal pengembangan proyek dan bersifat
fixed. Hal ini berarti biaya terhadap adanya perubahan kebutuhan yang terjadi
pada tahap selanjutnya akan menjadi mahal. XP diarahkan untuk menurunkan biaya
dari adanya perubahan dengan memperkenalkan nilai-nilai basis dasar, prinsip
dan praktis. Dengan menerapkan XP, pengembangan suatu sistem haruslah lebih fleksibel
terhadap perubahan.
Nilai-nilai Dasar XP
Berikut
adalah nilai-nilai mendasar yang menjadi roh dari XP pada setiap tahapan proses
pengembangan perangkat lunak:
1.
Communication
XP mengfokuskan
pada hubungan komunikasi yang baik antar anggota tim. Para anggota tim harus
membangun saling pengertian, mereka juga wajib saling berbagi pengetahuan dan
keterampilan dalam mengembangkan perangkat lunak. Ego dari para programer yang
biasaanya cukup tinggi harus ditekan dan mereka harus membuka diri untuk bekerjasama
dengan programer lain dalam menuliskan kode program.
2.
Courage
Para anggota
tim dan penanggungjawab pengembangan perangkat lunak harus selalu memiliki
keyakinan dan integritas dalam melakukan tugasnya. Integritas ini harus selalu
dijaga bahkan dalam kondisi adanya tekanan dari situasi sekitar (misalnya oleh
klien atau pemilik perusahaan). Untuk dapat melakukan sesuatu dengan penuh
integritas terlebih dahulu para anggota tim harus terlebih dahulu memiliki rasa
saling percaya. Rasa saling percaya inilah yang coba dibangun dan ditanamkan
oleh XP pada berbagai aspeknya.
3.
Simplicity
Lakukan semua
dengan sederhana. Hal tersebut adalah salah satu nilai dasar dari XP. Gunakan method
yang pendek dan simpel, jangan terlalu rumit dalam membuat desain, hilangkan fitur
yang tidak ada gunanya, dan berbagai proses penyederhanaan lain akan selalu
menjadi nilai utama dari setiap aspek XP.
4.
Feedback
Berikan selalu
feedback kepada sesama anggota tim maupun pihak-pihak lain yang terlibat dalam
pengembangan perangkat lunak. Utarakan selalu pikiran anda dan diskusikan kesalahan-kesalahan yang muncul
selama proses pengembangan. Dengarkan selalu pendapat rekan yang lain, dengan
adanya feedback inilah seringkali kita menyadari bagian mana yang salah atau
bisa ditingkatkan lagi dari perangkat lunak yang dikembangkan.
5.
Quality Work
Semua nilai di atas berujung pada sebuah
kondisi di mana kita melakukan pekerjaan dengan berkualitas. Dengan proses yang
berkualitas maka implikasinya akan muncul pula perangkat lunak yang berkualitas
sebagai hasil akhirnya.
Aspek Dasar XP
Aspek dasar XP terdiri dari berbagai
teknik atau metode yang diterapkan Beck dan Jeffries pada C3 Project.
Teknik-teknik tersebut dapat diamati pada gambar berikut ini:
1.
The Planning Game
Pendekatan XP dalam perencanaan sangat mirip
dengan metode yang diterapkan pada RAD (Rapid Application Development). Proses
pendek dan cepat, mengutamakan aspek teknik, memisahkan unsur bisnis dengan
unsur teknis dan pertemuan intensif antara klien dengan developer. Pada XP
proses ini menggunakan terminologi “game” karena Beck menyarankan untuk
menggunakan teknik score card dalam menentukan requirements. Semakin sulit
aspek teknis yang dibutuhkan semakin tinggi pula skor pada kartu rencana
tersebut.
2.
Small Releases
Setiap release dilakukan dalam lingkup sekecil
mungkin pada XP. Setiap developer menyelesaikan sebuah unit atau bagian dari
perangkat lunak maka hasil tersebut harus segera dipresentasikan dan
didiskusikan dengan klien. Jika memungkinkan untuk menerapkan unit tersebut
pada perusahaan, hal itu juga dapat dilakukan sekaligus sebagai tes awal dari
penerapan keseluruhan sistem. Kendati demikian hal ini tidak selalu perlu
dilakukan karena harus dihitung terlebih dahulu sumberdaya yang dibutuhkan. Apakah lebih menguntungkan langsung melakukan
tes terhadap unit tersebut atau melakukan tes setelah unit tersebut
terintegrasi secara sempurna pada sistem.
3.
Metaphor
Metaphor pada
dasarnya sama dengan arsitektur perangkat lunak. Keduanya menggambarkan visi
yang luas terhadap tujuan dari pengembangan perangkat lunak. Beck sendiri
seperti para penandatangan Agile Manifesto lainnya bercita-cita menyederhanakan
proses pengembangan perangkat lunak yang saat ini sudah dianggap terlalu rumit.
Arsitektur yang saat ini banyak berisi diagram dan kode semacam UML dianggap
terlalu rumit untuk dimengerti, terutama oleh klien. Metaphor, walaupun mirip
dengan arsitektur lebih bersifat naratif dan deskriptif. Dengan demikian
diharapkan komunikasi antara klien dengan developer akan berlangsung lebih baik
dan lancar dengan penggunaan metaphor.
4.
Simple Design
Sebagai salah
seorang penandatangan Agile Manifesto, Beck adalah seorang yang tidak menyukai
desain yang rumit dalam sebuah pengembangan perangkat lunak. Tidak heran jika
dia memasukkan Simple Design sebagai salah satu unsur XP. Pada XP desain dibuat
dalam lingkup kecil dan sederhana. Tidak perlu melakukan antisipasi terhadap
berbagai perubahan di kemudian hari. Dengan desain yang simpel apabila terjadi
perubahan maka membuat desain baru untuk mengatasi perubahan tersebut dapat
dengan mudah dilakukan dan resiko kegagalan desain dapat diperkecil.
5.
Refactoring
Refactoring
adalah salah satu aspek paling khas dari XP. Refactoring seperti didefinisikan
oleh Martin Fowler adalah ”Melakukan perubahan pada kode program dari perangkat
lunak dengan tujuan meningkatkan kualitas dari struktur program tersebut tanpa
mengubah cara program tersebut bekerja”. Refactoring sendiri sangat sesuai
untuk menjadi bagian XP karena Refactoring mengusung konsep penyederhanaan dari
proses desain maupun struktur baris kode program. Dengan Refactoring tim
pengembang dapat melakukan berbagai usaha untuk meningkatkan kualitas program
tanpa kembali mengulang-ulang proses desain. Fowler adalah salah satu kolega
dekat dari Kent Beck karena itu tidak mengherankan bahwa cara berpikir mereka
terhadap proses pengembangan perangkat lunak sangat mirip satu dengan lainnya.
6.
Testing
XP menganut
paradigma berbeda dalam hal tes dengan model pengembangan perangkat lunak
lainnya. Jika pada pengembangan perangkat lunak lainnya tes baru dikembangkan
setelah perangkat lunak selesai menjalani proses coding maka pada XP tim
pengembang harus membuat terlebih dahulu tes yang hendak dijalani oleh
perangkat lunak. Berbagai model tes yang mengantisipasi penerapan perangkat
lunak pada sistem dikembangkan terlebih dahulu. Saat proses coding selesai
dilakukan maka perangkat lunak diuji dengan model tes yang telah dibuat
tersebut. Pengetesan akan jauh lebih baik apabila dilakukan pada setiap unit
perangkat lunak dalam lingkup sekecil mungkin daripada menunggu sampai seluruh
perangkat lunak selesai dibuat. Dengan memahami tahap ini kita dapat melihat
bahwa siklus pada XP adalah requirement analysis à test à code à design. Sekilas terlihat hal ini tidak
mungkin dilakukan tetapi pada kenyataannya memang gambaran inilah yang paling
dapat menjelaskan tentang XP.
7.
Pair Programming
Pair programming
adalah melakukan proses menulis program dengan berpasangan. Dua orang programer
saling bekerjasama di komputer yang sama untuk menyelesaikan sebuah unit.
Dengan melakukan ini maka keduanya selalu dapat berdiskusi dan saling melakukan
koreksi apabila ada kesalahan dalam penulisan program. Aspek ini mungkin akan
sulit dijalankan oleh para programer yang memiliki ego tinggi dan sering tidak
nyaman untuk berbagi komputer bersama rekannnya.
8.
Collective Ownership
Tidak ada satupun
baris kode program yang hanya dipahami oleh satu orang programer. XP menuntut
para programer untuk berbagi pengetahuan untuk tiap baris program bahkan
beserta hak untuk mengubahnya. Dengan pemahaman yang sama terhadap keseluruhan program,
ketergantungan pada programer tertentu ataupun berbagai hambatan akibat
perbedaan gaya menulis program dapat diperkecil. Pada level yang lebih tinggi
bahkan dimungkinkan para programer dapat bertukar unit yang dibangunnya.
9.
Coding Standards
Pair programming dan
collective ownership hanya akan dapat berjalan dengan baik apabila para
programer memiliki pemahaman yang sama terhadap penulisan kode program. Dengan
adanya coding standards yang telah disepakati terlebih dahulu maka pemahaman
terhadap program akan menjadi mudah untuk semua programer dalam tim. Hal ini
dapat diterapkan sebagai contoh pada penamaan variabel dan penggunaan tipe data
yang sama untuk tiap elemen semua record atau array pada program.
10.
Continous Integration
Melakukan build setiap
hari kerja menjadi sebuah model yang disukai oleh berbagai tim pengembang
perangkat lunak. Hal ini terutama didorong oleh keberhasilan penerapan sistem
ini oleh Microsoft dan telah sering dipublikasikan. Dengan melakukan build
sesering mungkin berbagai kesalahan pada program dapat dideteksi dan diperbaiki
secepat mungkin. Apabila banyak tim pengembang perangkat lunak meyakini bahwa build
sekali sehari adalah minimum maka pada XP hal tersebut adalah maksimum. Pada XP
tim disarankan untuk melakukan build sesering mungkin misalnya setiap 4 jam
atau bahkan lebih cepat lagi.
11.
40-hours Week
Beck berpendapat
bekerja 8 jam sehari dan 5 hari seminggu adalah maksimal untuk iap programer.
Lebih dari itu programer akan cenderung membuat berbagai error pada baris-baris
kode programnya karena kelelahan.
12.
On-Site Customer
Sebuah pendekatan
klasik, di mana XP menganjurkan bahwa ada anggota dari klien yang terlibat pada
proses pengembangan perangkat lunak. Yang lebih penting lagi ia harus ada di
tempat pemrogaman dan turut serta dalam proses build dan test yang dilakukan.
Apabila ada kesalahan dalam pengembangan diharapkan klien dapat segera
memberikan masukan untuk koreksinya.
Component-based Development Model
Component-based
development sangat berkaitan dengan teknologi berorientasi objek. Pada
pemrograman berorientasi objek, banyak class yang dibangun dan menjadi komponen
dalam suatu software. Class-class tersebut bersifat reusable artinya bisa
digunakan kembali. Model ini bersifat iteratif atau berulang-ulang prosesnya.
Secara umum proses yang terjadi dalam model ini adalah:
1.
identifikasi
class-class yang akan digunakan kembali dengan menguji class tersebut dengan
data yang akan dimanipulasi dengan aplikasi/software dan algoritma yang baru
2.
Class yang dibuat
pada proyek sebelumnya disimpan dalam class library, sehingga bisa langsung
diambil dari library yang sudah ada. Jika ternyata ada kebutuhan class baru,
maka class baru dibuat dengan metode berorientasi objek.
3. bangun software
dengan class-class yang sudah ditentukan atau class baru yang dibuat,
integrasikan. Penggunaan kembali komponen software yang sudah ada menguntungkan
dari segi:
1.
siklus waktu
pengembangan software, karena mampu mengurangi waktu 70%
2.
biaya produksi
berkurang sampai 84% arena pembangunan komponen berkurang
Pembangunan
software dengan menggunakan komponen yang sudah tersedia dapat menggunakan
komponen COTS (Commercial off-the-shelf) – yang bisa didapatkan dengan membeli
atau komponen yang sudah dibangun sebelumnya secara internal. Component-Based
Software Engineering (CBSE) adalah proses yang menekankan perancangan dan
pembangunan software dengan menggunakan komponen software yang sudah ada. CBSE
terdiri dari dua bagian yang terjadi secara paralel yaitu software engineering
(component-based development) dan domain engineering seperti yang digambarkan
pada Gambar 2:
2.
software
engineering (component-based development) melakukan analisis terhadap domain
model yang sudah ditetapkan kemudian menentukan spesifikasi dan merancang
berdasarkan model struktur dan spesifikasi sistem, kemudian melakukan
pembangunan software dengan menggunakan komponen-komponen yang sudah ditetapkan
berdasarkan analisis dan rancangan yang
dihasilkan sebelumnya hingga akhirnya menghasilkan software.
Biaya
Pengembangan :
1
1.
https://docs.google.com/viewer?a=v&q=cache:cMASUmOGwUQJ:elib.unikom.ac.id/download.php%3Fid%3D132899+&hl=id&gl=id&pid=bl&srcid=ADGEESiUruhfoSPRTpjtklcB0ySwMBotvnXRqfg7SNVhF4tpox0GYHPFN51ZUJvnR6a72mC_j6jnrTI4RNXpSl4uCwoLfEHpDZRbhzpGbgHWy07jzppaBnq9lZT5oIM27XA-ln1xWRU1&sig=AHIEtbTO3sUZ8-OR5l_-mtXaa_18sjEJDg
2.
http://moel87cronaldo.blogspot.com/2009/03/tugas-rpl-3-model-extreme-programming.html
3.
http://www.scribd.com/doc/38743898/5-Model-Proses-Software
0 comments:
Posting Komentar