Web Engineering 2010 Pertemuan ke-11

Slides:



Advertisements
Presentasi serupa
RAPID APLICATION DEVELOPMENT ( RAD )
Advertisements

REKAYASA PERANGKAT LUNAK
Bab 1 Pemasaran Mengatur Hubungan Pelanggan yang Menguntungkan
Pengembangan Sistem Informasi
CHAPTER 7 Pengembangan Sistem
ENTREPRENEURSHIP KEWIRAUSAHAAN BAB 14 Oleh : Zaenal Abidin MK SE 1.
ANALISIS DAN PEMODELAN BERORIENTASI OBJEK DENGAN UML
Extreme Programming By : Adhi Nugroho ( )
Manajemen Proyek Aplikasi Web Husni husni.trunojoyo.ac.id komputasi.wordpress.com Web Engineering 2010 Pertemuan ke-12.
Proses Perangkat Lunak
Pertemuan 7 DSS Development
Sasaran Menjelaskan apa yang dimaksud model proses
Oleh : Maria Tantri Agus Setiawan Ahmad Budi S
Pertemuan 13 Sistem Informasi Viska Armalina, S.T., M.Eng.
REKAYASA PERANGKAT LUNAK (Software Engineering) Eka Ismantohadi
BAB 2 METODE REKAYASA PERANGKAT LUNAK
METODE REKAYASA PERANGKAT LUNAK
Rekayasa Perangkat Lunak
KOMPONEN SISTEM INFORMASI Materi Pertemuan ke-4.
Luas Daerah ( Integral ).
Model Proses PL.
TUGAS PERSENTASI RATIONAL UNIFIED PROCESS (R.U.P)
Proses Perangkat Lunak
PERENCANAAN PROSES PERANGKAT LUNAK
PERTEMUAN 9 Otoritas, Pendelegasian Wewenang dan Sentralisasi
Pengenalan Manajemen Proyek
Pengembangan Sistem Informasi
PLANNING A SOFTWARE PROJECT Ir. Waniwatining Astuti, M.T.I.
1 Pendahuluan Ir. Waniwatining Astuti, M.T.I Muhammad Rachmadi, S.T., M.T.I.
Proses Perangkat Lunak
ANALISIS SISTEM 1.
PERTEMUAN 9 Otoritas, Pendelegasian Wewenang dan Sentralisasi
PERANCANGAN SISTEM.
PERTEMUAN 7 PENGEMBANGAN SPK
Metodologi Rekayasa Sistem Informasi
Metodologi Pengembangan Sistem Informasi
SIKLUS HIDUP SISTEM Proses Pengembangan sistem berasal dari system life cycle/siklus hidup sistem. Siklus hidup sistem terjadi begitu saja System.
Rapid Application Development & Incremental Development
Rekayasa Perangkat Lunak
Metode rpl BY: Y. PALOPAK S.Si., MT..
PROCESS MODELS.
PriNciples That Guide Practice
Rekayasa Perangkat Lunak Model Proses PL
System Development Life Cycle (SDLC)
Rekayasa perangkat lunak (rpl)
Pengenalan Rekayasa Perangkat Lunak
Perancangan Sistem Informasi
ANALISA DAN PERANCANGAN SISTEM INFORMASI
RPL.
Metode Rekayasa Perangkat Lunak
SISTEM INFORMASI PEMASARAN
REKAYASA PERANGKAT LUNAK
PROSES REKAYASA PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
Analisa dan Perancangan Sistem
RPL.
Pengantar Teknologi Informasi (Teori)
PENGANTAR UML Citra N., S.Si, MT UNIKOM.
PERTEMUAN 2 Proses Pengembangan Perangkat Lunak
ANALISA DAN PERANCANGAN SISTEM INFORMASI
SDLC (System Development Life Cycle)
Rekayasa Perangkat Lunak (Software Engineering)
Kelompok V FERDY WIDJAJA YOUNGKY DWI P
REKAYASA PERANGKAT LUNAK
Pengembangan Sistem Informasi
PENGEMBANGAN SISTEM.
SOFTWARE ENGGINERING Model Model Siklus Rekayasa Perangkat Lunak
Pengembangan Sistem Informasi
MODEL PROSES PERANGKAT LUNAK
Software Development Life Cycle (SDLC)
Transcript presentasi:

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

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

Proses dan aplikasi web

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

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

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.

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

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.

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

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

THE RATIONAL UNIFIED PROCESS

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

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

Aliran Kerja Inti RUP

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

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.

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

EXTREME PROGRAMMING

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

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.

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.

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.

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.

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.

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

XP – Pandangan Iterasi

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

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.

Alternatif Proses Meta

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

Referensi Bacaan utama Bab 10

Pertanyaan?