Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

Web Engineering 2010 Pertemuan ke-11

Presentasi serupa


Presentasi berjudul: "Web Engineering 2010 Pertemuan ke-11"— Transcript presentasi:

1 Web Engineering 2010 Pertemuan ke-11
Proses Pengembangan Aplikasi Web Husni husni.trunojoyo.ac.id komputasi.wordpress.com

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 tersebut sebaiknya Penggunaan ulang ditekan oleh waktu delivery yang pendek Integrasi adalah masalah lebih besar ketika melibatkan pihak ketiga

11 THE RATIONAL UNIFIED PROCESS

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) Elaboration (Perluasan)
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 to face sehari-hari. Kita akan bekerja bersama menyelesaikan apa saja mulai requirement sampai 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 Reuse dan 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?


Download ppt "Web Engineering 2010 Pertemuan ke-11"

Presentasi serupa


Iklan oleh Google