Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Metodologi extreme programming

2,159 views

Published on

Metodologi extreme programming

Published in: Software
  • Be the first to comment

Metodologi extreme programming

  1. 1. METODOLOGI EXTREME PROGRAMMING Pengertian Tahapan Artefak Role Pair Programming Test Driven Development User Story
  2. 2. Pengertian/ Definisi Extreme Programming (XP) 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) Keberanian (Courage) dan menghormati (Respect).
  3. 3. Tahapan Extreme Programming
  4. 4. Kebutuhan informasi Modul Program Di sisi lain, tim yang lain mengidentifikasi teknologi dalam pelaksanaan proyek. Tahap ini dapat dilaksanakan dalam beberapa minggu, tergantung pada kerumitan sistem yang akan dibangun. a. Dokumentasi atas visi dan ruang lingkup pekerjaan b. Dokumentasi struktur proyek yang akan dikembangkan c. Dokumentasi teknologi yang akan digunakan Explorasi
  5. 5. Planning Phase Berorientasi Kepada Analisa dan Desain Kebutuhan Pengguna Kebutuhan Operasi Analisa Kebutuhan Bisnis Kebutuhan Sistem Spesifikasi fungsional atas suatu sistem Perencanaan jadwal pelaksanaan proyek
  6. 6. Iterasi Peluncuran Perangkat lunak Analisis lingkungan organisasi, analisis sistem untuk memenuhi kebutuhan waktu sekarang, analisis system requirement (input, output, process, storage, and control). Desain lingkungan organisasi, analisis sistem untuk memenuhi kebutuhan waktu sekarang, analisis system requirement (input, output, process, storage, and control). Aktivitas desain sistem meliputi (1) desain interface, (2). Desain fisik, (3). Desain logika. Testing Pada tahap ini sistem yang akan diluncurkan di uji terlebih dahulu. Pengujian dilakukan terhadap fungsional sistem dan terkait dengan hal-hal teknis sistem. Pada setiap iterasi pekerjaan diluncurkan untuk kemudian dievaluasi kembali untuk kemudian dilakukan perbaikan oleh tim.
  7. 7. Productionizing Phase System Documenta tion Memberikan gambaran mengenai sistem agar orang bisa memahami sistem. Informasi umum dalam dokumen ini mencakup gambaran dari arsitektur teknis, arsitektur bisnis, persyaratan tingkat tinggi untuk sistem ini, ringkasan keputusan desain kritis, diagram arsitektur tingkat, dan model desain yang penting (jika ada). Operation Documenta tion Mencakup indikasi dependensi bahwa sistem Anda terlibat dengan sifat interaksi dengan sistem lain, database, dan file, referensi untuk backup procedure, daftar point sistem Anda dan bagaimana untuk mencapainya , ringkasan requirements untuk sistem Anda, merupakan panduan untuk pemecahan masalah. Support Documenta tion Dokumentasi ini meliputi bahan pelatihan khusus untuk mendukung staf, semua dokumentasi pengguna untuk menggunakan sebagai acuan saat memecahkan masalah, panduan pemecahan masalah, prosedur eskalasi untuk menangani masalah-masalah sulit, dan daftar titik kontak dalam tim maintenance. User Documenta tion Customer mungkin memerlukan referensi manual, panduan penggunaan, panduan dukungan, dan bahkan materi pelatihan sendiri
  8. 8. Fase maintenance ini adalah tahap normal proyek XP karena harus berkembang dari tahun ke tahun. Maintenance Planning Itteration release Productionizing Death Tahapan ini merupakan sesi akhir dalam pengembangan sistem dengan menggunakan XP. Sistem yang telah di uji kemudian di implementasikan sesuai dengan kebutuhan client. Perangkat lunak yang diaplikasikan merupakan rilis akhir, hasil dari iterasi dan perbaikan dari versi-versi sebelumnya
  9. 9. Artefak dari setiap tahapan
  10. 10. Peranan/ Role •Sekitar sekali atau dua kali seminggu, tracker meminta setiap Programmer menjelaskan mengenai progress ,mengambil tindakan jika hal-hal tampaknya akan keluar jalur. Tindakan termasuk menyarankan sesi CRC, menyiapkan pertemuan dengan customer, meminta Pelatih atau Programmer lain untuk membantu. Tracker •Menulis UserStories dan FunctionalTests menentukan Prioritas Set, menjelaskan cerita, pandangan sesi CRC. Sesuai dengan GoalDonor C3 ini, mungkin atau tidak mungkin juga menjadi GoldOwner tersebut. Mungkin atau mungkin tidak menjadi pengguna akhir. Memiliki kewenangan untuk memutuskan pertanyaan tentang cerita. Mungkin memiliki jabatan seperti "Planner", "Analis", "ProjectLead?", "ProductLead?", "ProductManager", atau bahkan "Designer". Customer
  11. 11. Peranan/ Role •Memperkirakan User Story, mendefinisikan Teknik Tugas dari Story, memperkirakan bagaimana cerita panjang dan tugas akan mengambil, menerapkan cerita dan Unit Pengujian. Programmer •Mengamati semuanya, mengirimkan sinyal jelas, memastikan proyek terus StayExtreme. Membantu dengan apa pun. Berlaku RolledUpNewspaper seperti yang diperlukan. Coach (Pelatih)
  12. 12. Peranan/ Role •mengimplementasikan dan menjalankan FunctionalTests. Grafik hasil, membuat orang yakin tahu kapan hasil uji penurunan. (Catatan: Programmer melakukan UnitTests mereka sendiri.) Tester •Yang memberikan relaksasi pada saat terjatuh, dan ketika Anda berada dalam masalah besar. Doomsayer •namun diharapkan mengerti tugas-tugas ITstaff agar dapat mengetahui jangka waktu suatu project dari IT staff tersebut guna me manage tugas mereka agar tidak bentrok dengan tugas yang lainnya dan setidaknya IT manager harus dapat memutuskan solusi yang tepat ketika IT staff tersebut mengalami kendala dalam tugasnya It Manger
  13. 13. Pair Programming Semua perangkat lunak yang dibangun dengan pendekatan XP dibangun oleh dua orang programmer. Keduanya duduk berdampingan di satu komputer yang sama. Seorang programmer akan membuat code dan programmer yang lainnya akan mengoreksinya. Praktik seperti ini mungkin kelihatan tidak efisien. Namun dari segi hasil dari pair programming, desain akan lebih baik, pengujian lebih baik, dan code yang dihasilkan pun akan lebih baik.
  14. 14. XP begitu terobsesi dengan umpan balik, dan dalam pengembangan perangkat lunak, umpan balik yang baik mensyaratkan pengujian yang baik pula. Test-Driven Development bergantung pada pengulangan siklus development yang sangat pendek. Pertama tim XP akan menuliskan automated test case yang mendefinisikan perbaikan yang diinginkan atau fungsi baru. Kemudian dari test case tersebut dihasilkan jumlah minimal code yang harus dituliskan untuk lulus tes tersebut. Setelah itu melakukan refactoring code baru agar memenuhi standar baru. Test Driven Development
  15. 15. User Story  User Story ditulis oleh customer sebagai sistem yang harus dibuat. (sistem requirements) Seperti skenario penggunaan, mereka terbatas untuk menggambarkan user interface.  User stories harus memberikan detail yang cukup untuk membuat resiko yang cukup rendah berapa lama cerita yang diperlukan untuk dilaksanakan.
  16. 16. Love You All Yaaa.. 
  17. 17. Daftar Pustaka http://johns1987.wordpress.com/2011/12/04 /paradigma-perancangan-perangkat- lunak/ http://wsilfi.staff.gunadarma.ac.id/ http://rpl.if.its.ac.id/extreme-programming/ http://c2.com/cgi/wiki?ExtremeRoles http://library.binus.ac.id/eColls/eThesisdoc/ Bab2/2012-1-00666-IF%20Bab2001.pdf

×