Agile Modeling Metode Pengembangan Sistem

20 Programming XP menggunakan user stories untuk menampung kebutuhan pengguna. Sedangkan metode lainnya menggunakan Functional Specification FS. Tabel 2.1 Perbedaan Extreme Programming Dengan Pengembangan Perangkat Lunak Lain. XP Waterfall Staged MSF Requirements User Stories FS Functional Specification FS FS Planning Incremental Planning Detailed Detailed Stage Plans VisionScope High-Level Design Metaphor Evolutinary Detailed Design Detailed +Stage Reviews Detailed Design Build Continuous Integration Linear Linear Daily Build Automated tools Test Test FirstAutomate d tools Unit testing, Acceptance tests Unit testing, Acceptance tests Unit testing, Acceptance tests Deploy Platform Spesific Deployment guides Deploymen t guides Deployment guides Sumber: Bai, 2003. Menurut Jeb, 2009, mahasiswa dari Universitas Utara Malaysia, dalam thesisnya yang berjudul “Vacant Parking Place System Using WAP Technologies”, Extreme Programming adalah sebuah metode yang disiplin ilmunya mengutamakan kepuasan pelanggan dalam mengembangkan perangkat lunak. Pada thesisnya, Jeb, 2009 membangun sebuah sistem perparkiran yang diakses oleh pengguna melalui mobile. Hal ini dilakukan olehnya untuk mengurangi pemadatan area parkir. Karena aplikasi yang dibangun olehnya mengharuskan pengguna untuk terlebih dahulu mendaftarkan kendaraannya ke tempat dimana nantinya mereka 21 akan pergi. Sehingga perancangan aplikasi yang dibangun oleh Jeb, 2009, membutuhkan adanya keterlibatan pengguna. Dalam hal ini metode Extreme Programming sangat membantu pengembang dalam membangun sebuah aplikasi. Karena Extreme Programming XP memungkinkan pengembang siap menanggapi perubahan sesuai kebutuhan pelanggan secara cepat Mar, 2003.

2.1.2.3 User Stories

User Stories adalah model yang digunakan untuk melakukan requirements elicitation pada metodologi Extreme Programming XP. Fungsinya adalah untuk membuat estimasi waktu untuk release planning meeting. Selain itu digunakan juga untuk mengakomodasi dokumen requirements yang umumnya panjang. User Stories ditulis oleh customers sebagai sesuatu yang harus dilakukan oleh sistem untuk mereka. Hampir mirip sebagai skenario, tetapi tidak terbatas untuk menjabarkan user interface. Format pada umumnya berupa sekitar 3 kalimat teks yang ditulis oleh customer dalam terminologi customer sendiri tanpa adanya techno-syntax. User Stories juga berlanjut dalam pembuatan acceptance tests. Satu atau lebih acceptance test harus dibuat untuk memverifikasi apakah user story sudah diimplementasikan secara benar. Salah satu kesalahpahaman yang benar mengenai user stories adalah mengenai perbedaannya dengan traditional specifications. Perbedaan terbesarnya ialah pada tingkatan detilnya. User stories hanya memberikan detil yang cukup untuk membuat suatu reasonably low-risk estimate mengenai seberapa lama suatu skenario akan terimplementasi. 22 Developer mengestimasi seberapa lama suatu skenario akan dapat diimplementasikan. Masing-masing skenario akan mendapatkan1,2,atau 3 minggu estimasi dalam suatu “ideal development time”. Ideal development time ini adalah seberapa lama waktu yang dibutuhkan untuk mengimplementasikan suatu skenario dalam kode. Bila memakan waktu lebih dari 3 minggu berarti harus dilakukan breakdown lagi terhadap story tersebut. Berbeda dengan usecase, dalam user stories tidak terdapat detil alur kegiatan dalam suatu stories. Dalam tiap stories hanya dituliskan mengenai apa yang diinginkan oleh customer untuk dapat dilakukan oleh sistem yang akan dikembangkan. Deskripsi keseluruhan dari masing-masing stories itu sendiri sangkat singkat, tidak lebih dari beberapa baris yang ditulis langsung oleh customer. Berikut adalah sebuah contoh user stories yang diambil dari Extreme Programming