BAB II LANDASAN TEORI
2.8 Metode Pengembangan Sistem Extreme Programming
Pada penelitian ini dalam mengembangkan aplikasi penulis menggunakan Extreme Programming. Extreme Programming (XP) adalah metode pengembangan perangkat lunak yang ringan dan termasuk salah satu
agile methods yang dipelopori oleh Kent Beck, Ron Jeffries, dan Ward Cunningham. XP merupakan agile methods yang paling banyak digunakan dan menjadi sebuah pendekatan yang sangat terkenal. Extreme Programming (XP) adalah sebuah pendekatan pengembangan perangkat lunak yang mencoba meningkatkan efisiensi dan fleksibilitas dari sebuah proyek pengembangan perangkat lunak dengan mengkombinasikan berbagai ide sederhana (Pressman, 2010).
Extreme Programming merupakan salah satu metodologi dalam
rekayasa perangkat lunak dan juga merupakan satu dari beberapa agile software development methodologies yang berfokus pada coding sebagai aktivitas utama di semua tahap pada siklus pengembangan perangkat lunak (software development lifecycle). Metodologi ini mengedepankan proses pengembangan yang lebih responsive terhadap kebutuhan customer
(”agile”) dibandingkan dengan metode-metode tradisional sambil membangun suatu software dengan kualitas yang lebih baik. Extreme
Programming muncul menawarkan sebuah disiplin baru dalam pengembangan software secara agile. Nilai dasar yang terkandung di dalam
Extreme Programming adalah: Komunikasi (Communication),
Kesederhanaan (Simplicity), Umpan balik (Feedback) 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. 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.
3. 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.
Kelebihan Extreme Programming diantaranya adalah:
1. Sistem yang dikembangkan adalah sistem yang sesuai dengan sistem yang diinginkan user, karena pada extreme programming ada keterlibatan user selama pembangunan sistem.
2. Testing yang dilakukan maksimal, karena pada extreme programming mengutamakan coding dan testing pada pengembangannya, testing dilakukan oleh programmer, dan user.
3. Adanya komunikasi yang baik antara user dan pengembang aplikasi. 4. Terciptanya hubungan komunikasi yang baik antar anggota tim, karena
adanya prinsip pair programming.
Selain kelebihan terdapat beberapa kelemahan pada metode pengembangan
extreme programming:
1. Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.
2.Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan).
Gambar 2.13 Tahapan-tahapan extreme programming
Sumber: (Pressman, 2010)
Tahapan-tahapan pada metode pengembangan extreme programming:
1. Planning, Kebutuhan awal user atau biasa disebut user stories, ditulis pada fase ini. User stories menjelaskan rincian perkiraan awal untuk mengidentifikasi proses pengembangan dan faktor resiko yang mungkin muncul. User stories umumnya ditulis pada index card. Tim XP dan Customer bekerja bersama untuk menentukan group stories kedalam rilis berikutnya (software increment) untuk dikembangkan oleh tim XP
2. Design. Desain XP ketat mengikuti prinsip Keep it Simple
(KIS). desain sederhana selalu lebih disukai daripada representasi yang lebih kompleks. Selain itu, desain menyediakan petunjuk
pelaksanaan dari story seperti apa adanya tertulis tidak kurang dan tidak lebih. XP mendorong penggunaan CRC card sebagai sebuah Mekanisme yang efektif untuk digunakan pada perangkat lunak dalam konteks berorientasi objek. CRC card mengidentifikasi dan mengatur kelas-kelas obyek orinted yang relevan dengan pengembangan perangkat lunak. hanya CRC card merupakan produk yang hanya digunakan dalam design work yang merupakan bagian dari proses xp. Jika kesulitan mendesain ditemui sebagai bagian dari desain story, xp merekomendasikan pembuatan sebuah prototipe operasional yang merupakan bagian dari desain. Yang disebut Spike Solution, prototipe perancangan diimplementasikan dan dievaluasi. Tujuannya adalah untuk menurunkan risiko pada saat mulai pelaksanaan yang sebenarnya dan untuk memvalidasi perkiraan untuk story yang mengandung masalah pada desain. Karena desain xp menggunakan notasi hampir tidak ada, jika produk pekerjaan apapun selain CRC card dan spike solution, desain dipandang sebagai artefak sementara yang bisa dan harus terus diubah sebagai hasil konstruksi.
3. Coding. XP merekomendasikan bahwa setelah stories
dikembangkan dan desain awal dilakukan, tim mulai
mengembangkan serangkaian tes unit yang akan digunakan pada setiap stories yang akan disertakan (pengembangan perangkat lunak) . setelah unit test telah dibuat, pengembang berfokus pada
apa yang harus diimplementasikan untuk diuji.setelah kode selesai, bisa langsung diuji sehingga memberikan umpan balik seketika kepada para pengembang.
Konsep kunci selama kegiatan coding adalah pair
programming. XP merekomendasikan bahwa dua orang bekerja bersama-sama pada satu komputer workstation untuk membuat kode dari stories. Ini menyediakan mekanisme untuk memecahkan masalah pengembangan secara time dan jaminan kualitas real-time. Juga membuat para pengembang berfokus pada masalah yang dihadapi. Pada prakteknya, setiap orang mengambil peran yang sedikit berbeda. misalnya, satu orang mungkin mengerjakan rincian tentang bagian pengkodean tertentu dari desain, sementara yang lain membuat standar coding dan coding yang dihasilkan akan "sesuai" ke dalam desain story.
4. Refactoring adalah proses mengubah sistem perangkat lunak sedemikian rupa sehingga tidak mengubah perilaku eksternal kode sebelum memperbaiki struktur internal.itu adalah cara disiplin untuk membersihkan kode (dan memodifikasi / menyederhanakan desain internal) yang meminimalkan kemungkinan adanya bug. Pada dasarnya, ketika Anda merefactore Anda meningkatkan desain kode setelah ditulis. Maksud refactoring adalah untuk mengontrol modifikasi dengan menyarankan perubahan desain
kecil yang "umumnya dapat meningkatkan desain". perlu dicatat, bagaimanapun upaya yang diperlukan untuk refactoring dapat tumbuh secara dramatis sebagai ukuran dari pengembangan aplikasi.
5. Testing. Kita mencatat bahwa penciptaan tes unit sebelum coding dimulai merupakan elemen kunci dari pendekatan xp. Unit test yang dibuat harus dilaksanakan dengan menggunakan kerangka kerja yang memungkinkan mereka untuk otomatis (sehingga, mereka dapat dieksekusi dengan mudah dan berulang-ulang). XP acceptance test, juga disebut cistomer tests, ditetapkan oleh
customer dan fokus pada fitur-fitur sistem secara keseluruhan dan fungsionalitas yang terlihat dan ditinjau kembali oleh
customers. acceptance test berasal dari user stories yang telah diimplementasikan sebagai bagian dari rilis software.
2.12.1. Index Card
Kartu ini adalah media yang baik untuk menangani cerita pengguna untuk sejumlah alasan (clin ton Keith, 2010):
1.
Ukuran kartu membatasi jumlah detail dalam cerita. Kami tidak mau cerita menjadi dokumen besar yang mencakup seti ap diperlukan desain detail. Sebuah kartu kecil mencegah hal ini terjadi.2.
Kartu dapat fisik dimanipulasi (disortir, diedit, diganti, dan lulus) oleh banyak tangan dalam pengaturan kolaboratif (scrum sehari-hari dan perencanaan pertemuan).2.12.1. Class Responsibility Colaborator
Model Class Responsibility Collaborator (Wir, 1990) menyediakan cara sederhana untuk mengidentifikasi dan mengorganisir kelas-kelas yang relevan dengan persyaratan sistem atau produk. Ambler (Ambler, 1995) Menggambarkan pemodelan CRC bahwa CRC merupakan sebuah koleksi dari index card yang menggambarkan kelas-kelas. CRC dibagi menjadi tiga bagian. Dibagian atas kartu anda dapat menuliskan nama kelas, Dalam badan kartu mencatat responsibility dari class pada bagian kiri dan Collaborator pada bagian kanan.
Responsibility merupakan attribute dan operasiyang
relevan untuk class. Collaborator adalah kelas-kelas yang diperlukan untuk melengkapi kelas dengan informasi yang dibutuhkan untuk Responsibility pada umumnya, Collaborator
menyiratkan baik request informasi atau request untuk beberapa tindakan.