Manajemen Proyek Perangkat Lunak (MPPL)

Presentasi berjudul: "Manajemen Proyek Perangkat Lunak (MPPL)"— Transcript presentasi:

1 Manajemen Proyek Perangkat Lunak (MPPL)
BAB 4 Memilih pendekatan proyek The McGraw-Hill Companies/Software Project Management (second edition) / Bob Hughes and Mike Cotterell

2 Tujuan Pembelajaran Mengetahui karakteristik sistem yang akan dikembangkan ketika merencanakan suatu proyek Memilih model proses yang sesuai Penggunaan model proses waterfall Mengurangi resiko dengan membuat prototipe yang sesuai Mengurangi resiko lainnya dengan implementasi proyek dengan bertahap / increment

3 Analisa karakteristik Proyek
Analisa karakteristik proyek digunakan untuk menentukan teknologi dan metodologi yang digunakan dalam pengembangan suatu proyek Teknologi (Application Building environment, knowledge based systems tool) Metodologi (Object Oriented development, SSADM/Structure Systems Analysis and design method, JPS / Jackson Structure Programming)

4 The Waterfall Model Stable Product Definition & Well Known Technical Tools
Urutan aktifitas dieksekusi dari atas ke bawah. Setiap aktifitas divalidasi / ditest sebelum pindah ke aktifitas selanjutnya Aktifitas :Feasibility study, users requirements, system analysis, system design, program design, coding, testing, installation, operations & support, maintenance, retirement Keuntungan Water fall Model Mudah untuk dimengerti / diimplementasikan Baik untuk Kontrol proyek/milestone/utilisasi staf Kekurangan Model Tidak merefleksikan penyelesaian masalah sifat pengembangan software (iterations, solution preview, changes) Tidak banyak yang diketahui sebelum tahapan final (quality, budget, schedule, functionality, ease of use, maintainability, etc) Semua kebutuhan harus diketahui dari awal 4

5 Waterfall The waterfall model
Section 4.6 of the textbook discusses this topic. We have already touched upon the Waterfall approach in Lecture/Chapter 1 when we discussed the ISO The way that the Waterfall approach is usually interpreted, it implies that all work on one phase has to be completed and checked off before the next one can start. However, it can be argued that ISO is really a technical model showing the order technical processes need to be carried out on a software component. You might break down an application into component increments, but the technical processes relating to that increment are carried out in the ISO sequence. You can, within the ISO sequence, loop back in an iterative manner, but the technical sequence still remains. The waterfall model

6 Memperhatikan aktifitas validasi dan verivikasi
The V-Shaped Model Stable Product Definition & Well Known Technical Tools Memperhatikan aktifitas validasi dan verivikasi Testing/Acceptance tests didisain paralel dengan Requirements/Architecture Design. Project Requirements didifinisikan paralel dengan Product Operation Keuntungan: Memperhatikan pada proses validasi/testing/verivikasi, termasuk semua deliveri internal dan eksternal Kebutuhan sebelum disain sebelum coding Mudah untuk melacak, mudah untuk digunakan Kekurangan: Konsep tidak ada iterasi / perubahan dinamik Resiko dan delay jadwal dapat muncul terlalu lambat dalam life cycle suatu proyek 4/13/2017 6 6

7 7

8 The Spiral Model Medium to High Risk projects, New technology, Complex requirements, Large projects, Computation intensive system, Requirements are not final, No commitment for full budget Support proses manajemen, dan analisa resiko Memungkinkan adanya Prototyping dan Rapid Development Berdasarkan 4 aktifitas utama yang berulang-ulang sampai delivery produk. Setiap pengulangan (spiral) meningkatkan kapasitas aktifitas Menentukan tujuan, alternatif dan keterbatasan Melakukan evaluasi alternatif, identifikasi dan menyelesaikan resiko (risk analysis and prototyping) Mengembangkan tahapan software berikutnya (simulation, detailed design, code, unit test, integration and acceptance) Merencanakan tahapan berikutnya (from project planning to transition plan, integration and testing to operational and training) dan mereview 4 kuadran terakhir Spiral bagian dalam berhubungan dengan spesifikasi dan disain Spiral bagian luar berhubungan dengan development, implementation, maintenance and integration 8

9 The Spiral Model (Cont.)
Keuntungan: Rapid prototyping memungkinkan users untuk mengetahui sistem lebih awal Indikasi lebih awal dari resiko, keputusan Go-No-Go setiap spiral Malakukan Split pengembangan besar ke beberapa tahapan Disain fleksibel Kerugian: Terlalu mahal untuk proyek yang kecil dan resiko rendah Model komplek, tidak ada pengalaman industri Tool prototyping yang baik Versi yang sederhana dikembangkan untuk mengatasi kekurangan. 9

10 Samples for Partial Implementations of the Spiral Model
4/13/2017 10 10

11 11

12 The Incremental Model No upfront funding, Year+ Project, Requirements not totally defined, Short market window implies basic functionality first, New technology, Limited staff availability Melakukan konstruksi implementasi parsial dari total sistem dan perlahan-lahan menambahkan peningkatan fungsi / performansi Suatu model Waterfall dalam phase overlapping Tahapan-tahapan awal proyek (planning, analysis, design) mempertimbangkan sistem keseluruhan, kebutuhan prioritas dan mendifinisikan group yang akan diimplemntasikan pada sub proyek Keuntungan: Dana dapat dialokasikan sebagian Delivery operasional lebih awal sehingga meningkatkan keuntungan yang lebih besar Meningkatkan knowledge dan proses pembelajaran Mengurangi resiko, mudah untuk di test Bagian kecil lebih mudah diatur, dapat meng-utilisasi staf sedikit, meningkatkan momentum proyek. 12

13 The Incremental Model (Cont.)
Kekurangan: Tidak ada iterasi, susah untuk merubah kebutuhan pada tahap tertentu Diperlukan perencanaan yang baik dan kerjasama user Kebutuhan tidak didefinisikan secara penuh yang dapat membuat manajemen tidak nyaman Biaya dapat meningkat jika disain fisikal dan fungsi tidak terstruktur penuh 13

14 Incremental delivery delivered system first incremental delivery
design build install evaluate increment 1 first incremental delivery increment 2 design build install evaluate second incremental delivery increment 3 The application to be delivered is broken down into a number of components each of which will be actually used by the users. Each of these is then developed as a separate ‘mini-project’ or increment. design build install evaluate third incremental delivery

15 The incremental process
Intentional incremental delivery This approach has had a very vocal advocate in Tom Gilb (see the book Principles of Software Engineering Management published by Addison-Wesley (1988)). Gilb argues that the initial focus should be on high level business objectives. There may be many ways in which important objectives can be achieved and we ought to allow ourselves freedom in the way we try to achieve the objectives. Open technology plan – we need to ensure that the technologies we use are ones that facilitate the addition of components to an existing application. Plan increments – the nature and order of the increments to be delivered needs to be delivered to the users have to be planned at the outset.

16 Prototype Software Prototype Throw Away Prototype Evolutionary

17 Keuntungan Prototype Belajar sambil melakukan Meningkatkan komunikasi
Meningkatkan keterlibatan user Klarifikasi kebutuhan yang diketahui parsial Demo konsistensi dan kelengkapan dari spesifikasi Mengurangi kebutuhan dokumentasi Keterbatasan fitur Produksi hasil yang diharapkan

18 Kekurangan Prototype User kadang-kadang salah paham tentang aturan prototype Kekurangan kemungkinan standard proyek Kekurangan kontrol Tambahan biaya

19 TERIMA KASIH