Metodologi Pengembangan PL

1. MetodologiPengembangan PL

2. Metodologi Metodologi adalah kesatuan metode-metode, prosedur-prosedur, konsep-konsep pekerjaan, aturan-aturan yang digunakan oleh suatu ilmu pengetahuan, seni atau disiplin yang lainnya. Metode adalah suatu cara, teknik yang sistematik untuk mengerjakan sesuatu.

3. MetodologiPerangkatLunak UntukmelakukansuatupengembanganPLdibutuhkansuatumetodologipengembanganperankatlunak MetodologipengembanganPLadalahmetode-metode, prosedur-prosedur, konsep-konseppekerjaandanaturan-aturan yang akandigunakanuntukmengembangkansuatuperangkatlunak

4. Keberhasilan Pengembangan PL PL berjalan sesuai dengan apa yang diharapkan (sesuai dengan perencanaan pengembangan sistem, mulai dari segi biaya dan effort) • Proyek lengkap • PL sesuai dengan keinginan user • Hasil dari PL aman • Hasil mempunyai waktu operasional yang lama

5. Kegagalan pengembangan PL • Kurangnya penyesuaian pengembangan PL • Kelalaian menetapkan kebutuhan pemakai dan melibatkan pemakai PL • Kurang sempurnanya evaluasi kualitas analisis biaya • Adanya kerusakan dan kesalahan rancangan • Penggunaan teknologi komputer dan perangkat lunak yang tidak direncanakan dan pemasangan teknologi tidak sesuai • Pengembangan PL yang tidak dapat dipelihara • Implementasi yang direncanakan dilaksanakan kurang baik

6. Model Waterfall • Urutan linear tahap/fase • Kebutuhan – Rancangan Tingkat Tinggi – Rancangan Rinci - Pemrograman - Pengujian – Penyerahan • Suatu fase dimulai hanya ketika fase sebelumnya telah selesai; tidak ada umpan balik • Fase membagi proyek, masing-masing menangani masalah yang terpisah

7. Waterfall... • Urutan linear menyiratkan setiap tahap harus memiliki beberapa keluaran • Keluaran harus divalidasi/diverivikasi • Keluaran dari fase sebelumnya: produk kerja • Keluaran umum dari waterfall: SRS, rencana proyek, dokumen rancangan, rencana dan laporan pengujian, kode akhir, dokumen pendukung

8. Keunggulan Waterfall • Secara konseptual sederhana, membagi masalah ke dalam tahap yang berbeda yang dapat dilakukan secara independen • Pendekatan alami untuk pemecahan masalah • Mudah untuk mengelola dalam kontrak - setiap fase adalah milestone

9. Kelemahan Waterfall • Menganggap bahwa kebutuhan dapat ditetapkan dan dibekukandi awal • Menetapkan perangkat keras dan teknologi lainnya terlalu dini • Mengikuti pendekatan "big bang" – “all or nothing delivery”; terlalu berisiko • Sangat berorientasi dokumen, membutuhkan dokumen pada akhir setiap tahap

10. Penggunaan Waterfall • Penggunaan Waterfall • Telah digunakan secara luas • Cocok untuk proyek-proyek di mana kebutuhan dapat dipahami dengan mudah dan keputusan teknologi yang mudah • Untuk proyek yang sudah dikenal mungkin ini yang paling optimal

11. Prototyping • Prototyping mengatasi keterbatasan spesifikasi kebutuhan waterfall • Sebagai ganti pembekuan kebutuhan hanya dengan diskusi, Prototyping dibangun untuk memahami kebutuhan • Membantu meringankan risiko kebutuhan • Sebuah model waterfall kecil menggantikan tahap kebutuhan

12. Prototyping

13. Prototyping • Pengembangan Prototyping • Mulai dengan kebutuhan awal • Hanya fitur kunci yang perlu pemahaman yang lebih baik yang termasuk dalam Prototyping • Tidak ada gunanya memasukkan fitur-fitur yang dipahami dengan baik • Umpan balik dari pengguna diambil untuk meningkatkan pemahaman dari kebutuhan

14. Prototyping • Biaya dapat disimpan rendah • Hanya membangun fitur yang memerlukan klarifikasi • "cepat dan kotor" - mutu tidak penting, skrip dll dapat digunakan • Hal-hal seperti penanganan eksepsi, pemulihan, dan standar dihilangkan • Biaya bisa beberapa% saja dari total • Belajar dalam membangun Prototyping akan membantu dalam pengembangan, selain kebutuhan yang ditingkatkan

15. Prototyping • Keunggulan: kebutuhan akan lebih stabil, kebutuhan dibekukan kemudian, pengalaman membantu dalam pengembangan utama • Kelemahan: berpotensi meningkatkan biaya dan jadwal • Penerapan: Ketika kebutuhan sulit untuk diperoleh dan keyakinan dalam kebutuhan rendah; yaitu di mana kebutuhan tidak dipahami dengan baik

16. Pengembangan Iteratif • Mengatasimasalah"semua atau tidaksamasekali" yang merupakan kelemahan dari model waterfall • Menggabungkan manfaat Prototyping dan waterfall • Mengembangkan dan menyediakan perangkat lunak secara bertahap • Setiap peningkatanmerupakanbagian yang lengkap • Dapat dilihat sebagai waterfall ygberurutan • Umpan balik dari satu iterasi yang digunakan dalam iterasi yang berikutnya

17. Peningkatan Iteratif

18. Iteratif… • Setiap iterasi hampir selalu diikuti produk yang dihasilkan • Digunakan umumnya dalam pengembangan customjuga • Bisnis ingin respon cepat untuk PL • Tidak dapat menghadapi risiko “semua atau tidak sama sekali” • Pendekatan baru seperti XP, Agile, ... semua bergantung pada pengembangan iteratif

19. Iteratif… • Keunggulan: Mendapatkan sesuai yang dibayar, umpan balik untuk perbaikan • Kelemahan: Arsitektur/rancangan mungkin tidak optimal, pengerjaan ulang dapat meningkat, total biaya mungkin lebih besar • Penerapan: di mana waktu respon sangat penting, risiko proyek yang lama tidak dapat diambil, semua kebutuhan tidak diketahui

20. Bentuk lain Iteratif • Iterasi pertama membuat kebutuhan dan arsitektur dengan cara waterfall • Pengembangan dan penyerahan dilakukan secara bertahap dalam iterasi

21. Bentuk lain dari Iterasi ...

22. Timeboxing • Iteratif adalah urutan linier dari iterasi • Setiap iterasi adalah waterfall mini - menentukan spesifikasi, kemudian rencana iterasi • Timeboxing– menetapkan durasi iterasi, kemudian menentukan spesifikasi • Membagi iterasi dalam beberapa tahap yang sama • Menggunakan konsep pipelining untuk mengeksekusi iterasi secara paralel

23. Iterasi Time Boxed • Pengembangan iteratif umum – menetapkan fungsi untuk setiap iterasi, kemudian merencanakan dan jalankan • Pada iterasi kotak waktu – menetapkan durasi iterasi dan menyesuaikan fungsi yang akan dimasukkan • Waktu penyelesaiannya tetap, fungsi yang akan disampaikan fleksibel

24. Iterasi Time Boxed • Hal ini sendiri sangat berguna dalam banyak situasi • Waktu pengiriman dapatdiprediksi • Rilis produk secara keseluruhan dan pemasaran dapat lebih terencana • Membuat parameter waktu tidak bisa ditawar dan membantu memfokuskan perhatian pada jadwal • Mencegah penggelembungan kebutuhan • Waktu pengembangan secara keseluruhan masih tidak berubah

25. Timeboxing • Bagaimana jika kita memiliki beberapa iterasi yang dieksekusi secara paralel • Dapat mengurangi waktu penyelesaian rata-rata dengan memanfaatkan paralelisme • Untuk eksekusi paralel, dapat meminjam konsep-konsep pipelining dari perangkat keras • Hal ini menghasilkan Model Proses Timeboxing

26. Model Timeboxing • Dasar • Pengembangan dilakukan secara iteratif dalam kotak waktu berdurasi tetap • Setiap kotak waktu dibagi dalam tahap yang tetap • Setiap tahap melakukan tugas yang jelas yang dapat dilakukan secara mandiri • Setiap tahap kira-kira sama dalam hal durasi • Ada sebuah tim khusus untuk setiap tahap • Ketika tim satu tahap selesai, tim itu menyerahkan proyek kepada tim berikutnya

27. Timeboxing… • Dengan kotak waktu jenis ini, dapat menggunakan pipelining untuk mengurangi waktu siklus • Seperti pipelining perangkat keras – memandang iterasi sebagai satu instruksi • Sebagai tahap memiliki tim khusus, eksekusi simultan dari iterasi yang berbeda adalah memungkinkan

28. Contoh • Sebuah iterasi dengan tiga tahap – (A)nalisis, (B)angun, (S)erahkan • Tahap-tahap ini lebih kurang sama dalam banyak situasi • Dapat menyesuaikan durasi dengan menentukan batas yang sesuai • Dapat menyesuaikan durasi dengan menyesuaikan ukuran tim untuk setiap tahap • Memiliki tim terpisah untuk masing-masing tahap

29. Eksekusi Pipelined • Tim A mulai menjalankan iterasi 1 • Tim A selesai, menyerahkan iterasi 1 ke Tim B, dan mulai menjalankan iterasi 2 • Tim A menyelesaikan iterasi 2, menyerahkan ke Tim B, Tim B menyelesaikan iterasi 1, menyerahkan ke Tim S, Tim A memulai iterasi 3, Tim B mulai iterasi 2 (dan Tim S, iterasi 1) • ...

30. Eksekusi Timeboxing

31. eksekusi Timeboxing • Iterasi pertama selesai pada waktu T • Kedua selesai pada T + T / 3; ketiga pada T +2 T / 3, dan seterusnya • Dalam keadaan stabil, pengiriman setiap T / 3 waktu • Jika T adalah 3 minggu, pengiriman pertama setelah 3 minggu, 2 setelah 4 minggu, 3 setelah 5 minggu, ... • Dalam pelaksanaan linier, waktu pengiriman akan 3 minggu, 6 minggu, 9 minggu, ...

32. Eksekusi • Jangka waktu iterasi masing-masing masih sama • Jumlah pekerjaan dilakukan dalam kotak waktu juga sama • Produktivitas dari kotak waktu sama • Namun, waktu siklus rata-rata atau waktu pengiriman telah dikurangi menjadi sepertiga

33. UkuranTim • Dalam pelaksanaan linear dari iterasi, tim yang sama melakukan semua tahap • Jika setiap tahap memiliki tim dari S, dalam pelaksanaan linear ukuran tim adalah S • Dalam pelaksanaan pipelined, ukuran tim adalah tiga kali (satu tim untuk setiap tahap) • Tapi, ukuran total dalam tim timeboxing lebih besar, dan ini mengurangi waktu siklus

34. UkuranTim • Hanya dengan meningkatkan ukuran tim kita tidak bisa mengurangi waktu siklus - Hukum Brook • Timeboxingmemungkinkan cara yang terstruktur untuk menambah tenaga kerja untuk mengurangi waktu siklus • Perhatikan bahwa kita tidak dapat mengubah waktu iterasi - Hukum Brook masih berlaku • Alokasi pekerjaan yang berbeda untuk memungkinkan tim yang lebih besar untuk berfungsi dengan baik

35. Alokasi Kerja Tim

36. Timeboxing… • Keunggulan: waktu pengiriman lebih pendek, mendapatkan juga keuntungan lain dari pendekatan iteratif, distribusi eksekusi • Kelemahan: tim besar, manajemen proyek lebih sulit, sinkronisasi tinggi diperlukan, manajemen konfigurasi sulit • Penerapan:Ketika waktu pengiriman yang singkat sangat penting; arsitektur stabil; fleksibilitas dalam pengelompokan fitur