Proses Pengembangan Aplikasi Web

Husnihusni@if.trunojoyo.ac.id

husni.trunojoyo.ac.idkomputasi.wordpress.com

Web Engineering 2010Pertemuan ke-11

Outline

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

2

PROSES DAN APLIKASI WEB

3

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

4

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 UML5

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.

6

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 ditangguhkan7

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. 8

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 9

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

10

THE RATIONAL UNIFIEDPROCESS

11

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”)

12

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

13

Aliran Kerja Inti RUP

14

Prinsip Kunci Dibalik RUP

• Menyesuaikan proses (Adaptif)• Memperhitungkan prioritas stakeholder• Kolaborasi lintas tim• Menunjukkan nilai secara iteratif• Encourage abstraction• Fokus berkelanjutan pada kualitas,

15

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.

16

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

17

EXTREME PROGRAMMING

18

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

19

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.

20

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.

21

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.

22

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.

23

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.

24

XP – Pandangan Proses

• Rilis berurutan yang cepat (Rapid Successive Releases)

25

XP – Pandangan Iterasi

26

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

27

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. 28

Alternatif Proses Meta

29

Rangkuman

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

30

Referensi

• Bacaan utama– Bab 10

31

Pertanyaan?

32