Web Engineering 2010 Pertemuan ke-11

1. Proses Pengembangan Aplikasi WebHusnihusni@if.trunojoyo.ac.idhusni.trunojoyo.ac.idkomputasi.wordpress.com Web Engineering 2010 Pertemuan ke-11

2. Outline • Proses dan Aplikasi Web • Rational Unified Process (RUP • Extreme Programming (XP) • Proses Meta • Rangkuman

3. Proses dan aplikasi web

4. Kebutuhan Proses Formal • Banyak proyek dikerjakan secara “quick and dirty” • Pro: waktu pengembangan lebih singkat • Kontra: kualitas rendah, biaya operasional & perawatam lebih tinggi • Dua solusi: • Adaptasi model proses software konvensional yang ada • Model sering menyediakan fleksibilitas • Tetapi apakah itu selalu pas? • Mengembangkan model proses spesifik Web yang baru

5. Definisi: Model vs Metode • Model proses – mendeskripsikan proses pengembangan dalam konteks keseluruhan • Kapan sesuatu akan dikerjakan • Di bawah aspek organisasional • Contoh: RUP, XP • Heavyweight vs. lightweight – derajat dari formalisasi proses • Metode – mendeskripsikan pendekatan pengembangan secara detail • Bagaimana sesuatu akan dikerjakan • Kapan itu dapat dilakukan • Di abwah aspek spesifik content • Contoh: diagram UML

6. Definisi: Model vs Metode • Contoh. Jika pemanfaatan suatu diagram UML tertentu disarankan untuk meraih tujuan spesifik, sebagaimana dipraktekkan dalam RUP, maka ini adalah bagian dari metode, karena tujuan yang dikejar di sini adalah spesifik content. • Jika disarankan untuk memrogram berpasangan, sebagaimana dipraktekkan dalam XP, maka ini juga suatu rekomendasi metodologis, karena benefit dari pendekatan demikian utamanya adalah suatu perbaikan dalam kualitas kode. • Sedangkan keputusan untuk menggunakan pemrograman berpasangan merupakan bagian dari proses XP.

7. Definisi: Iterasi & Fase • Iterasi – sehimpunan aktifitas berbeda yang menghasilan suatu pelepasan perangkat lunak (software release) • Penggunaan ulang pengetahuan yang terkumpul • Langkah-langkah sama mungkin terjadi beberapakali • Tim yang berpengalaman, domain aplikasi baru • Fase – Rentang wakti antara 2 tonggak waktu (milestone) • Berorientasi tujuan (Goal-oriented) • Berorientasi Resiko (Risk-oriented) • Literatur sering tak menentu membahas mengenai fase-fase untuk menunjukkan aktifitas metodologis, yaitu definisi requirements, analysis, design, implementation, testing dan maintenance. Ini cocok dengan pendekatan yang sesuai dengan model waterfall rekayasa web tradisional, dinama aktifitas metodologis mengikuti satu yang lain secara linier. • Penanganan resiko ditangguhkan

8. Kebutuhan Proses Bagi Web • Penanganan siklus pengembangan pendek • Durasi yangdiharapankan: 3-6 bulan • Teknologi dan pemasaran siklusnya cepat • Penanganan perubahan kebutuhan • Banyak requirements hadir setelah pengembangan dimulai. • Restrukturisasi data. • Pengembangan teknologi dan standar. • Keterlibatan yang kuat dari pelanggan. • Keputusan tingkat bisnis berpengaruh pada requirements dari proses.

9. Kebutuhan Proses Bagi Web • Fixed Deadline vs Flexible Content • Merilis segera “yang dapat dirilis” untuk menunjukkan fiungsionalitas • Waktu sangat kritis (sangat singkat 2-15 hari) • Pengembangan Paralel dari Rilis • Tim kecil bekerja pada versi berbeda dari aplikasi secara konkuren • Sebagian besar masalah manajemen proyek • Perhatian pada komunikasi • Penanganan perubahan reaktif cepat mengharuskan prototyping • Rilis didefinisikan oleh tanggal, bukan fitur lagi • Requirement menjadi fleksibel. • Teknik demikan juga didukung oleh fakta bahwa metrik bagi biaya dalam aplikasi web sulit digunakan untuk perancanaan jangka panjang.22

10. Kebutuhan Proses Bagi Web • Penggunaan Ulang (Reuse) dan Integrasi • Koordinasi antar proyek berbeda yang akan menggunakan ulang komponen • Pemodelan memajukan penggunaan ulang • Menekan masalah ke arah integrasi dan menaikkan resiko dari rmasalah menjalar lintas proyek berbeda • Adaptasi terhadap tingkat kompleksitas • Rproses akan beradaptasi sebagai pengembangan menjadi lebih kompleks • Makin kompleks suatu aplikasi, makin terformalkan proses tersebutsebaiknya • Penggunaan ulang ditekan oleh waktu delivery yang pendek • Integrasi adalah masalah lebih besar ketika melibatkan pihak ketiga

11. THE RATIONAL UNIFIEDPROCESS

12. Rational Unified Process (RUP) • RUP merupakan suatu framework proses kelas berat. • Berorientasi fase • Incremental • Iteratif • Dirancang untuk aplikasi yang kualitas dan kompleksitasnya tinggi • Metode RUP dikelompokkan ke dalam beberapa workflow inti (atau “bidang”)

13. 4 Fase RUP • Inception (Permulaan) • Kebutuhan (requirement), Lingkup dan Arsitektur awal • Elaboration (Perluasan) • Definisikan arsitektur, platform, harga pasti • Construction (Pembangunan) • Selesaikan analisis; Rancang (desain) & coding • Transition (Peralihan) • Pasangkan aplikasi ke konsumen

14. Aliran Kerja Inti RUP

15. Prinsip Kunci Dibalik RUP • Menyesuaikan proses (Adaptif) • Memperhitungkan prioritas stakeholder • Kolaborasi lintas tim • Menunjukkan nilai secara iteratif • Encourage abstraction • Fokus berkelanjutan pada kualitas,

16. Kesesuaian RUP Dengan Aplikasi Web • Inception – POOR • Anggapan dapat berubah mengikuti perkembangan proyek • Elaboration – POOR • Pengembangan sistem yang sesuai lebih berat daripada menentukan harga • Internet sebagian besar mendefinisikan arsitektur sistem • Construction – GOOD • Transition – GOOD • Pada beberapa kasus lebih awal karena distribusi bersifat otomatis • Sangat mudahkan aplikasi web mati, kadaluarsa • Arsitektur yang bagus: Teknologi web berubah cepat; sulit punya metodologi untuk digandeng dengan ini.

17. RUP & Kebutuhan Proses Aplikasi Web • Siklus pengembangan pendek: POOR • Kebutuhan (requirement) berubah: POOR • Fixed deadline, Flexible content: POOR • Pengembangan Paralel: FAIR • Reuse dan Integrasi • GOOD reuse • Integrasi POOR • Menyesuaikan tingkat fleksibilitas: GOOD

18. EXTREME PROGRAMMING

19. Extreme Programming (XP) • XP adalah salah satu bentuk paling top dari proses agile. • Iteratif, “test-first” • Lebih human-centric/feedback-oriented • Nilai Utama • Communication Komunikasi • Simplicity Kesederhanaan • Feedback Umpan-balik • Respect Respek, Tanggap, Ngerti • Courage Keberanian, Semangat, Komit

20. Kesederhanaan • Kita akan lakukan apa yang diperlukan dan diminta, tidak lebih. • Ini akan memaksimalkan nilai yang dibuat untuk investasi up-to-date. • Kita akan mengambil langkah-langkah sederhana yang kecil menuju tujuan kita dan mengurangi kegagalan begitu terjadi. • Kita akan membuat sesuai yang membanggakan dan rawat untuk jangka panjang karena alasan biaya.

21. Komunikasi • Setiap orang adalah bagian dari tim dan kita berkomunikasi face toface sehari-hari. • Kita akan bekerja bersama menyelesaikan apa saja mulai requirementsampai code. • Kita akan membuat solusi terbaik bagi masalah kita yang kita dapat lakukan bersama.

22. Umpan Balik • Kita akan mengambil setiap komitmen iterasi secara serius dengan menyampaikan software yang berjalan baik. • Kita menunjukkan software kita sejak awal dan sering, kemudian mendengarkan dengan cermat dan membuat perubahan yang diperlukan. • Kita berbicara mengenai proyek dan menyesuaikan proses kita dengannya, bukan cara lain.

23. Respek • Setiap orang memberikan dan merasakan respek yang mereka berhak dapatkan sebagai anggota tim yang bernilai. • Setiap orang mengkontribusikan nilai bahkan jika itu antusiame sederhana. • Para pengembang menghormati kepakaran dari konsumen dan sebaliknya. • Manajemen menghormati hak kita untuk menerima tanggungjawab dan menerima hak (otoritas) terhadap pekerjaan kita sendiri.

24. Keberanian, Komitmen • Kita akan memberitahukan kebenaran mengenai perkembangan (progress) dan perkiraan (estimasi). • Kita tidak “menuliskan” alasan kegagalan karena kita merencanakan suskes • Kita tidak takut apapun karena tidak ada yang benar-benar bekerja sendiri. • Kita akan beradaptasi, berubah, ketika perubahan benar-benar terjadi.

25. XP – Pandangan Proses • Rilis berurutan yang cepat (Rapid Successive Releases)

26. XP – Pandangan Iterasi

27. Kebutuhan Proses & XP • Siklus pengembangan pendek: GOOD • Kebutuhan berubah: GOOD • Deadline ditetapkan, content fleksibel: GOOD • Pengembangan Paralel: GOOD • Reusedan Integrasi: POOR • Menyesuaikan tingkat kompeksitas: POOR

28. Alternatif Proses Meta • Proses Agile secara umum disukai untuk Web, tetapi punya 2 hambatan: • Scalability & Complexity • Tuntutan tinggi pada anggota tim • Penanganan skalabilitas & kompleksitas terjadi di sepanjang jalan beberapa proyek. • Proses meta lintas proyek pengembangan software dapat membantu mengelola perubahan ini.

29. Alternatif Proses Meta

30. Rangkuman • Proses pengembangan yang baik penting untuk: • Mengurangi biaya • Memungkinkan dicapainya tujuan • Beradaptasi dengan masalah yang baru

31. Referensi • Bacaan utama • Bab 10

32. Pertanyaan?