Requirements Management Pada Extreme Programming

Publish in

Documents

23 views

Please download to get full document.

View again

of 7
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Description
dregrt
Transcript
  See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/277116093 Requirements Management pada ExtremeProgramming Conference Paper  · June 2006 CITATIONS 0 READS 274 2 authors: Widodo WidodoJakarta State University 4   PUBLICATIONS   3   CITATIONS   SEE PROFILE Massus SubektiJakarta State University 1   PUBLICATION   0   CITATIONS   SEE PROFILE All content following this page was uploaded by Widodo Widodo on 27 August 2015. The user has requested enhancement of the downloaded file.  Seminar Nasional Aplikasi Teknologi Informasi 2006 (SNATI 2006) ISSN: 1907-5022 Yogyakarta, 17 Juni 2006 REQUIREMENTS MANAGEMENT PADA EXTREME PROGRAMMING Widodo, Massus Subekti  Jurusan Teknik Elektro, Fakultas Teknik, Universitas Negeri Jakarta  Jl. Rawamangun Muka, Jakarta. 13220  E-mail: widodo03@yahoo.com ABSTRAKSI  Metodologi pengembangan perangkat lunak yang berkembang saat ini telah beralih ke metodologi yang lebih sederhana. 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. Salah satu yang paling popuper yaitu eXtreme Programming. Metodologi ini memiliki keunikan yang sebenarnya juga bisa menjadi kelemahannya, yaitu tanpa dokumentasi formal. Makalah ini akan mencoba memasukkan dokumentasi sederhana pada extreme  programming sebagai requirements management. Selanjutnya hasil penambahan sebagai fase requirements management tersebut diuji dengan distribusi normal untuk menunjukkan bahwa penambahan tersebut mempertahankan eXtreme Programming dalam batas-batas agile method.  Kata kunci : Agile methods, eXtreme Programming, requirements management.   1.   PENDAHULUAN Bidang pengembangan perangkat lunak berkembang sangat pesat dewasa ini. Dalam perkembangannya ini tidak terlepas dari peran metodologi yang digunakan untuk membangun. Jika kita lihat kembali ke belakang, berbagai metodologi untuk mengembangkan perangkat lunak telah cukup banyak diperkenalkan. Mulai dari model waterfall  sampai dengan model-model incremental . Semua metodologi yang berkembang sebelumnya tidak mampu menangani kemungkinan perubahan atau penambahan requirements  yang terjadi pada saat pengembangan dilaksanakan atau bahkan pada waktu fase terakhir pengembangan. Hal inilah yang mendorong munculnya metodologi atau model pengembangan perangkat lunak yang baru yang mampu mengatasi kekurangan tersebut. Pada dekade 90-an diperkenalkan metodologi baru yang dikenal dengan nama agile methods.  Metodologi ini sangat revolusioner perubahannya  jika dibandingkan dengan berbagai metode sebelumnya.  Agile Methods  dikembangkan karena pada metodologi tradisional terdapat banyak hal yang membuat proses pengembangan tidak dapat berhasil dengan baik sesuai tuntutan user.  Saat ini metodologi ini sudah cukup banyak berkembang, di antaranya adalah:    eXtreme Programming (XP)    Scrum Methodology    Crystal Family     Dynamic Systems Development Method (DSDM)     Adaptive Software Development (ASD)    Feature Driven Development (FDD) Jika kita lihat, agile  bisa berarti tangkas, cepat, atau ringan.  Agility  merupakan metode yang ringan dan cepat dalam pengembangan perangkat lunak.  Agile Alliance  mendefinisikan 12 prinsip untuk mencapai proses yang termasuk dalam agility : 1.   Prioritas tertinggi adalah memuaskan pelanggan melalui penyerahan awal dan berkelanjutan perangkat lunak yang bernilai. 2.   Menerima perubahan requirements  meskipun perubahan tersebut diminta pada akhir pengembangan. 3.   Memberikan perangkat lunak yang sedang dikerjakan dengan sering, beberapa minggu atau beberapa bulan, dengan pilihan waktu yang paling singkat. 4.   Pihak bisnis dan pengembang harus bekerja sama setiap hari selama pengembangan berjalan. 5.   Bangun proyek dengan individu-individu yang bermotivasi tinggi dengan memberikan lingkungan dan dukungan yang diperlukan, dan mempercayai mereka sepenuhnya untuk menyelesaikan pekerjaannya. 6.   Metode yang paling efektif dan efisien dalam menyampaikan informasi kepada tim pengembangan adalah dengan komunikasi langsung  face-to-face . 7.   Perangkat lunak yang dikerjakan merupakan pengukur utama kemajuan. 8.   Proses agile  memberikan proses pengembangan yang bisa ditopang. Sponsor, pengembang, dan user   harus bisa menjaga ke-konstanan langkah yang tidak pasti. 9.   Perhatian yang terus menerus terhadap rancangan dan teknik yang baik meningkatkan agility . 10.   Kesederhanaan –seni untuk meminimalkan  jumlah pekerjaan– adalah penting. 11.   Arsitektur, requirements , dan rancangan terbaik muncul dari tim yang mengatur sendiri. E- 95  Seminar Nasional Aplikasi Teknologi Informasi 2006 (SNATI 2006) ISSN: 1907-5022 Yogyakarta, 17 Juni 2006 12.   Pada interval reguler tertentu, tim merefleksikan bagaimana menjadi lebih efektif, kemudian menyesuaikannya. 2.   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. Sasaran  XP  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.  XP  sebagai sebuah metode yang dinamis diperlihatkan dalam empat values  yang dimilikinya dan keempatnya merupakan dasar-dasar yang diperlukan dalam  XP . 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 ) 2.   Kesederhanaan ( Simplicity ) 3.   Umpan Balik ( Feedback  ) 4.   Keberanian ( Courage ) Sebagai sebuah metodologi untuk mengembangkan peragkat lunak XP tentu memiliki siklus hidup. Siklus hidup pada XP 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 1.  Fase pada eXtreme Programming (sebelum modifikasi) Meskipun para developer mungkin memiliki  practices yang berbeda namun secara mendasar  XP  memiliki 12  practices  utama yaitu: 1. Planning Game 7. Pair Programming 2. Small Releases 8. Collective Ownership 3.  Metaphor 9. Continuous Integration 4. Simple Design 10. 40-hour week 5. Testing 11. On-site Customer 6.  Refactoring 12. Coding Standard Pada  practice Planning Game  sendiri memiliki tiga fase yaitu exploration phase, commitment phase, dan steering phase . Planning game ini adalah pertemuan antara dua pihak, yaitu dari pihak developer   dan pihak bisnis, dibahas mulai membuat story  oleh on-site customer sampai re-estimate  oleh pihak development  . Tabel 1.  Fase pada  planning game  (sebelum modifikasi)  NOPHASE BUSINESS DEVELOPMENT  Write story - -  Estimate story I Exploration phase Split story - Sort by value - - Sort by risk - Sort by velocity II Commitment phase Choose scope -  Iteration - -  Recovery IIISteering phase  New story Re-estimate Pada fase-fase XP tidak terdapat sebuah fase ataupun bagian dari satu fase yang melakukan dokumentasi formal selama proses pengembangan. Satu-satunya dokumentasi adalah penulisan requirements pada index card yang disebut dengan stories.   Stories  ini ditulis pada fase exploration,  di mana satu  function  yang akan diimplementasikan akan ditulis dalam satu index card.  Selanjutnya pada proses pengembangan apabila satu  function pada stories telah berhasil diimplementasikan, index card- nya akan dibuang. Ini bisa menjadi kelemahan XP karena tanpa dokumentasi formal maka proses pengembangan ini akan kembali seperti proses yang tidak terpola dan primitif. Apabila ditarik kepada model CMM ( Capability Maturity Model ) maka proses yang tanpa dokumentasi formal ini akan masuk ke level paling bawah yaitu lebel initial . Namun jika terdapat dokumentasi formal yang cukup berat, diperkirakan metodologi ini tidak menjadi ringan lagi sehingga tidak masuk dalam kategori agile . Exploration   Maintenance   Planning   Iteration to Release   ProductionizingDeath   3.   ANALISIS PENAMBAHAN FASE REQUIREMENTS MANAGEMENT Pada bagian ini akan dilakukan penambahan fase pada XP 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 XP keluar dari lingkup agile . Tiga hal yang dilakukan yaitu: E- 96  Seminar Nasional Aplikasi Teknologi Informasi 2006 (SNATI 2006) ISSN: 1907-5022 Yogyakarta, 17 Juni 2006 1. Penambahan  Requirements Management    Requirements management   akan dijadikan sebuah fase tersendiri namun kronologis pelaksanaannya adalah paralel dengan fase  planning.  Hal ini dimaksudkan agar penambahan fase ini tidak akan berpengaruh secara signifikan terhadap waktu pengembangan secara keseluruhan. Penambahan anggota tim juga tidak diperlukan untuk melakukan proses requirements management   ini. 2. Pendokumentasian sederhana (  simple  documenting ) Ini merupakan implementasi dari fase requirements management.  Pihak development   melakukan peringkasan stories  ( summarize stories ) ke dalam dokumen sederhana ( simple document  ) dari pihak bisnis. Teknis pelaksanaannya dilakukan tidak menggunakan komputer tapi ditulis tangan. Ini dimaksudkan agar metodologi ini tetap ringan. Penulisan dengan menggunakan komputer bisa dilakukan setelah proses pengembangan berakhir.  Requirements yang ditulis hendaknya mencantumkan identitas dari stories  yang didokumentasikan yaitu nomor story pada index card.  Ini diperlukan sebagai trace  karena requirements yang ditulis pada simple document   tidak serinci pada story,  namun sudah dirangkum menjadi sebuah  feature.  Jika requirements yang dirangkum tersebut mengalami perubahan maka pada perubahan itu juga harus ada trace -nya untuk mengetahui asal requirement- nya. 3. Mempertahankan index card   yang telah diimplementasi dengan baik. Pada metode XP, index card   akan dibuang apabila story yang terdapat di dalamnya telah berhasil diimplementasikan dengan baik. Namun pada modifikasi ini index card   tidak perlu dibuang, karena selain sebagai bahan dokumentasi, index card   adalah bukti dari requirements  pada simple document.  Pada requirements  tersebut terdapat satu atribut yang mengarah ke index card, yaitu story  asal dari requirements  tersebut yang tertulis lebih rinci. Gambar 2. Fase pada eXtreme Programming  setelah modifikasi Setelah dilakukan modifikasi terdapat beberapa pengaruh pada  practice- nya. Dari dua belas  practice  yang terdapat pada XP, 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 XP tersebut. 1.   Planning Game  Berikut ini adalah tabel setelah dilakukan perubahan pada siklus: Tabel 2.  Fase pada  planning game  (setelah modifikasi)  NO PHASE BUSINESS DEVELOPMENT  Write story - -  Estimate story Split story - I Exploration phase - Summarize stories (simple  documenting) Sort by value - - Sort by risk - Sort by velocity II Commitment phase Choose scope -  Iteration - -  Recovery  New story Re-estimate III Steering phase - 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.  Pihak bisnis melakukan split story  menjadi dua atau lebih story  apabila pihak development tidak dapat mengestimasi  story , atau story  yang ditulis terlalu kompleks. Sebaliknya pihak development melakukan summarize story  yaitu story  dirangkum menjadi sebuah requirements  yang menjadi sebuah  feature pada sistem yang akan diimplementasikan. Proses ini dikerjakan langsung pada waktu customer   selesai menulis story,  tidak perlu menunggu sampai semua stories  selesai ditulis. DeathExploration   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. Planning   Iteration to Release   ProductionizingMaintenanceRequirements Management E- 97
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks