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.
1. 1. Pengertian
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
1. Kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus.
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
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
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:
1. Kebutuhan software sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien juga
sering berubah seiring berjalannya proyek.
2. Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh desain yang diperlukan
sebelum pembangunan.
3. Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan.
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.
1. 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.
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)
1. 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.
1. Planning Game
Berikut ini adalah tabel setelah dilakukan perubahan pada siklus:
Split story –
Summarize stories
– (simple
documenting)
– Sort by velocity
Choose scope –
Summarize stories
– (update simple
document)
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.
1. 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.
1. 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.
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.
1. Small, frequent releases
Memproduksi dengan cepat.
1. System metaphors
System metaphors antara Customer dengan Programeruntuk menunjukkan semua perkembangan dengan
menjelaskan bagaimana cara kerja system.
1. Simple design
Perhatiannya pada pendisainnan atau perancngan solusi yang sederhana
1. Frequent refactoring
Penyusunan system kembali dengan cara duplikat atau salinan,memperbaiki komunikasi, menambahkan
kelenturan
1. Pair programming
Dua orang menulis kode pada 1 komputer
1. Continuous integration
Bagian baru code di gabungkan ke dalam kode dasar
1. 40-hour weak
Max 40 jam kerja seminggu,
1. On-site customer
Customer harus hadir dan ada setiap saat untuk teamnya.
1. Coding standards
Terdapat aturan pengkodean dan di ikuti oleh programmer.
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).
1. 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:
– 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.
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
– Pembangunan dan orang yang membangun dibagi dalam tim yang kecil
– Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun
1.
1. 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.
1.
1. 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.
1.
1. Demo
Aktifitas Demo adalah penyerahan software increment ke klien didemonstrasikan dan dievaluasi oleh klien.
1.2.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.
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.
1.2.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.
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.
– Mengunakan multiple models: tiap model mewakili aspek yang berbeda dari model lain.
– Isi lebih penting dari pada penampilan: modeling menyajikan informasi kepada audiens yang tepat.
– Memahami model dan alat yang yang digunakan untuk membuat software
– 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.