Tim RPL Prodi Teknik Informatika Software Process Tim RPL Prodi Teknik Informatika

Topic Classic Process Model Agile Development

CLASSIC PROCESS MODEL Prescriptive Models The Waterfall Model Incremental Models Evolutionary Process Models Specialized Process Models The Unified Process

Waterfall Model/ Classic life cycle Sebuah pendekatan pengembangan perangkat lunak yang sistematik dan sekuensial.

Kriteria Waterfall Model Syarat keberhasilan penggunaan model waterfall: Kebutuhan Sistem sudah diidentifikasi lama sebelum mulai. Perubahan kebutuhan diminimalkan selama proyek berjalan. Kekurangan: Kurang fleksibel antar tiap tahap dan perubahan Banyak waktu terlewat antara mulai awal proposal sistem dalam fase analisis hingga sistem dikirimkan. Model ini hanya sesuai bila kebutuhan dimengerti dengan baik dan cukup stabil

Varian Waterfall – V Model Setiap aksi yang dilakukan pada awal proyek hingga implementasi berasosiasi dengan aksi quality assurance

Incremental Process Model Kombinasi model proses linear dan paralel Mengirimkan PL secara bertahap dalam bagian kecil yang berguna hingga komplit

Evolutionary Model Evolutionary model bersifat iteratif, memungkinkan pembangunan yang cepat berubah. Prototyping Model langkah pertama yang baik bila pelanggan memiliki kebutuhan, tapi clueless tentang rincian Spiral Model Prototyping yang iteratif dengan aspek terkontrol darn sistematik dari model sekuensial Concurrent Development Model Pembangunan iteratif dan bersamaan untuk berbagai proses model

Prototyping Metodologi prototyping terdiri dari fase the analysis, design and implementation yang berbarengan dan terus berulang. Prototype adalah versi sederhana dari sistem dengan sejumlah fitur minimal.

Advantage vs Disadvantage Keuntungan: Menyediakan gambaran sistem bagi pengguna, walau belum siap untuk digunakan. Kerugian: Prototipe sering mengalami perubahan yang signifikan sehingga banyak desain awal yang tidak digunakan.

Spiral Model Sesuai untuk pembangunan PL skala besar Software berkembang sejalan dengan proses yang berlangsung, pengembang dan pelanggan lebih memahami dan bereaksi terhadap resiko pada setiap tingkat evolusi.

The Concurrent Proses Model Semua tahap dalam model proses dapat dilakukan bersamaan dan iteratif Serangkaian aktivitas di triger dari statusnya Contohnya saat aktivitas modelling, ada perubahan kebutuhan dalam aktivitas communication maka status modelling menjadi menunggu perubahan

Specialized Model Process Component-Based Development variasi model spiral dimana aplikasi dibangun dari komponen software yang dikemas atau disebut kelas Formal Methods Model notasi matematika yang digunakan untuk menentukan, desain, dan memverifikasi sistem berbasis komputer Aspect-Oriented Programming menyediakan sebuah proses untuk mendefinisikan, menentukan, merancang, dan membangun aspek perangkat lunak seperti antarmuka pengguna, keamanan, dan manajemen memori yang mempengaruhi banyak bagian dari sistem yang dikembangkan

Unified Process Use-case driven, architecture centric, iterative, and incremental software process Phases Inception phase (customer communication and planning) Elaboration phase (communication and modeling) Construction phase Transition phase (customer delivery and feedback)

Iterasi dan Workflow h W k f w c p E b C u T A Requirements Design y I t o ( s ) . # 1 2 + c p E b C u T h W k f w A Requirements Design Implementation Test Analysis

Agile development

Agile Methodology Kata Agile berarti bersifat cepat, ringan, bebas bergerak, waspada Dapat memberikan sistem cepat Menekankan komunikasi terus menerus dan kolaborasi antara pengembang dan pelanggan Menganut filosofi yang mendorong: kepuasan pelanggan, pengiriman perangkat lunak bertahap, tim proyek kecil (5-20 anggota), metode informal dan produk rekayasa PL yang minimal Efektif (cepat & adaptif) dalam merespon perubahan

Kriteria Agile Fokus pada kolaborasi: Kurangi dokumen dan perbanyak percakapan Stakeholders aktif terlibat Fokus pada perangkat lunak yang berjalan: Banyaknya feedback membuat proyek agile mudah dikelola Sedikit dokumentasi juga diperlukan Kurangi birokrasi Agilists adalah spesialis yang bisa segalanya: Kurangi lempar tanggung jawab antar tiap anggota Dibutuhkan sedikit orang Spesialis merasa sulit pada awalnya untuk masuk ke dalam tim Agile didasarkan pada praktek, bukan teori: Perubahan yang signifikan dari tradisional Anda perlu melihat cara kerja Agile dalam praktek untuk benar-benar memahaminya

Manifesto for Agile Software Development Proposes that it may be better to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan While the items on the right are still important the items on the left are more valuable under this philosophy

Classic SDLC VS Agile Classic SDLCs While Agile Are Predictive not Adaptive They want the answers up front; have a hard time dealing with change Rely on Documentation rather than Trust Focus on Roles rather than Teamwork Emphasize planning over building While Agile No long planning/design phase up front; start building as soon as possible. Learn as we go Customers/clients involved in the process. Less emphasis on “sign-offs” and proposals Everyone is involved in understanding the problem and building the solution. Daily meetings to discuss progress/problems.

Agile Process Models Extreme Programming (XP) Adaptive Software Development (ASD) Dynamic Systems Development Method (DSDM) Scrum Crystal Feature Driven Development (FDD) Agile Modeling (AM)

Extreme Programming (XP) Pertama kali dipublikasikan Kent Beck tahun 1999 Menggunakan Pendekatan Berorientasi Objek Nilai yang mendasari Extreme Programming (XP): Communication Simplicity Feedback Courage Respect

Proses XP [1] XP Planning (Planning Game) Dimulai dengan pengumpulan ͞user stories͟ dari kustomer, tetapkan prioritasnya. Setiap story ditetapkan harga dan lama pembangunannya. Jika terlalu besar, story dapat dipecah menjadi beberapa story yang lebih kecil (konsep increment). Periksa dan pertimbangkan resiko serta jadwal diterimanya hasil increment.

Proses XP [2] XP Design Berprinsip sederhana (KIS Principle) Memanfaatkan kartu CRC (Class-Responsibility Collaborator) untuk identifikasi dan mengatur class di konsep OO. Kartu CRC berfungsi untuk menangkap elemen-elemen dari class. Jika temui kesulitan, maka dibangun prototype (langkah ini disebut spike solution) Lakukan ͞ refactoring, yaitu mengembangkan disain dari program yang telah ditulis (program diperbaiki)

Proses XP [3] XP Coding XP Testing Siapkan unit test sebelum pengkodean dipakai sebagai fokus pemrogram untuk membuat program. Menggunakan konsep ͞Pair programming͟, untuk real time problem solving dan real time quality assurance. XP Testing Testing dilakukan dengan menggunakan unit test yang dipersiapkan sebelum pengkodean. Dokumen untuk “Acceptance Test” disiapkan dan dilakukan oleh kustomer.

Siklus Proses dan Task XP

Scrum Pertama kali diperkenalkan oleh Jeff Sutherland pada tahun awal tahun 1990an

Prinsip Scrum Ukuran tim yang kecil melancarkan komunikasi, mengurangi biaya, dan memberdayakan satu sama lain. Proses dapat beradaptasi terhadap perubahan dan bisnis/fungsi. Proses menghasilkan beberapa increment perangkat lunak. Pembangunan dan orang yang membangun dibagi dalam tim yang kecil. Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun. Proses scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan.

Aktivitas Scrum Backlog: adalah daftar kebutuhan yang jadi prioritas kustomer. Daftar dapat bertambah. Sprints: unit pekerjaan yang diperlukan untuk memenuhi kebutuhan yang ditetapkan pada proses backlog sesuai dengan waktu yang ditetapkan dalam time-box (biasanya 30 hari). Selama proses ini berlangsung backlog tidak ada penambahan. Scrum Meeting: pertemuan 15 menit per-hari untuk mengevaluasi apa yang dikerjakan, hambatan yang ada, dan target penyelesaian untuk bahan meeting selanjutnya. Demo: penyerahan increment perangkat lunak ke kustomer, didemonstrasikan dan dievaluasi oleh kustomer.

Scrum Process Flow Daily Scrum Meeting

Memilih Metodologi Pengembangan yang Sesuai Memilih metodologi tidak sederhana, karena tidak ada satu metodologi yang selalu terbaik. Banyak organisasi memiliki standar mereka sendiri. Berikutnya dirangkum beberapa kriteria penting dalam seleksi metodologi. Power point Presentation for Dennis, Wixom, & Roth System Analysis and Design, 3rd Edition Copyright2006©John Wiley & Sons.Inc

Criteria for Selecting a Methodology Power point Presentation for Dennis, Wixom, & Roth System Analysis and Design, 3rd Edition Copyright2006©John Wiley & Sons.Inc

Clarity of User Requirements Metodologi RAD prototyping dan throwaway prototyping biasanya lebih tepat bila kebutuhan pengguna tidak jelas karena mereka memberikan prototipe bagi pengguna untuk berinteraksi di awal SDLC. Power point Presentation for Dennis, Wixom, & Roth System Analysis and Design, 3rd Edition Copyright2006©John Wiley & Sons.Inc

Familiarity with Technology Jika sistem dirancang tanpa beberapa kesamaan dengan teknologi dasar, risiko meningkat karena tool mungkin tidak mampu melakukan apa yang dibutuhkan. Power point Presentation for Dennis, Wixom, & Roth System Analysis and Design, 3rd Edition Copyright2006©John Wiley & Sons.Inc

Copyright2006©John Wiley & Sons.Inc System Complexity Sistem yang kompleks memerlukan analisis dan desain yang cermat dan rinci. Tim proyek yang mengikuti metodologi pembangunan incremental cenderung kurang memperhatikan analisis masalah domain lengkap daripada jika mereka menggunakan metodologi lain Power point Presentation for Dennis, Wixom, & Roth System Analysis and Design, 3rd Edition Copyright2006©John Wiley & Sons.Inc

Copyright2006©John Wiley & Sons.Inc System Reliability Keandalan sistem biasanya merupakan faktor penting dalam pengembangan sistem. metodologi berbasis prototipe umumnya bukan pilihan yang baik karena mereka tidak memiliki analisis dan desain yang cermat. Power point Presentation for Dennis, Wixom, & Roth System Analysis and Design, 3rd Edition Copyright2006©John Wiley & Sons.Inc

Copyright2006©John Wiley & Sons.Inc Short Time Schedules Metodologi berbasis RAD sangat cocok untuk proyek-proyek dengan jadwal waktu yang singkat karena mereka meningkatkan kecepatan. Metodologi berbasis Waterfall adalah pilihan terburuk ketika waktu adalah penting karena mereka tidak memungkinkan untuk perubahan jadwal mudah Power point Presentation for Dennis, Wixom, & Roth System Analysis and Design, 3rd Edition Copyright2006©John Wiley & Sons.Inc

Copyright2006©John Wiley & Sons.Inc Schedule Visibility Metodologi berbasis RAD memindahkan banyak keputusan desain kritis di awal proyek; akibatnya, ini membantu manajer proyek mengenali faktor risiko dan menjaga harapan yang tinggi. Power point Presentation for Dennis, Wixom, & Roth System Analysis and Design, 3rd Edition Copyright2006©John Wiley & Sons.Inc

STUDI KASUS MODEL PENGEMBANGAN PERANGKAT LUNAK Tugas kecil STUDI KASUS MODEL PENGEMBANGAN PERANGKAT LUNAK

Deliverable Diberikan 4 buah kasus, silahkan diskusikan model pengembangan PL yang sesuai untuk tiap kasus. Pilih (boleh lebih dari satu) dan jelaskan alasan pemilihan! Tugas dikerjakan perorangan pada kertas laporan (boleh diketik / tulis tangan) yang dikumpulkan max. Jum’at, 24 Maret 2017.

Kasus - 1 PT. IndoSoftware (pihak-1) diminta membantu membuat website untuk Departemen Pariwisata (pihak-2). Secara umum, pihak-2 mengetahui informasi apa saja yang harus ditampilkan pada website. Akan tetapi, bagaimana informasi tersebut ditampilkan, pihak-2 memerlukan bantuan dari pihak-1, termasuk didalamnya alur penyajian informasi dan bentuk serta media penyajian informasinya. Model proses apa yang paling tepat dipilih PT IndoSoftware ? Jelaskan alasan anda.

Kasus 2 PT Sukses Makmur sudah lama menggunakan perangkat lunak yang membantu operasional perusahaan. Akan tetapi, karena perusahaan ingin berpindah dari platform X ke platform Y, maka perangkat lunak versi baru perlu dibangun. PT Sukses Makmur meminta bantuan PT Software Solution untuk membuat perangkat lunak yang baru. Model proses apa yang paling tepat dipilih PT. Software Solution ? Jelaskan alasan anda.

Kasus 3 Sebuah proyek pembangunan perangkat lunak berskala besar akan segera dijalankan PT SysSoftware. PT SysSoftware adalah sebuah software company skala besar, sehingga memiliki cukup banyak tenaga pengembang. Perangkat lunak yang akan dibangun terdiri dari sembilan modul utama yang nantinya harus diintegrasikan. Sayangnya, meski perangkat lunak yang akan dibangun cukup besar, waktu yang tersedia agak terbatas. Model proses apa yang paling tepat dipilih PT SysSoftware ? Jelaskan alasan anda.

Kasus 4 PT WebSolution adalah perusahaan pengembang software yang relatif baru berdiri. Anggota timnya pun masih terbatas. Meskipun terbatas, setiap anggota adalah individu yang dapat diandalkan. PT ini mempunyai fokus pada pengembangan aplikasi berbasis web. Sebagian besar proyek yang ditangani harus selesai dalam waktu singkat. Karakteristik konten aplikasi yang sering sering berubah menuntut developer ini untuk terus menerus me-maintain aplikasi yang telah dibuatnya. Menurut anda, model proses apa yang paling tepat dipilih?

Selamat Mengerjakan ! 