Rekayasa Perangkat Lunak. Fajar Pradana S.ST., M.Eng

Transkripsi

1 Rekayasa Perangkat Lunak Fajar Pradana S.ST., M.Eng

2 Fajar Pradana CP Blog: fajar.lecture.ub.ac.id Student representative contact person

3 Mata Kuliah Mata Kuliah : Rekayasa Perangkat Lunak Kode Mata Kuliah : PTI15011 Beban Studi : 4 SKS Sifat : Wajib Praktikum : Ada Deskripsi Singkat : Memberikan pemahaman tentang pengertian dan urgensi RPL, serta penerapan metoda-metoda pengembangan perangkat lunak dalam melakukan analisis kebutuhan perangkat lunak, perancangan awal dan peracangan detil, implementasi / pemrograman, dan pengujian perangkat lunak. Setelah mengikuti perkuliahan ini, mahasiswa diharapkan akan dapat menjabarkan metoda-metoda yang harus diterapkan dalam mengembangkan sebuah perangkat lunak.

4 Materi Pengertian dan Urgensi RPL (Introduction/Pengenalan) Spesifikasi/Analisis Kebutuhan Perangkat Lunak Analisa Model Prototyping Desain Model Desain Antar Muka Desain Tingkat Komponen Implementasi Teknik Pengujian Perangkat Lunak Strategi Pengujian Perangkat Lunak Deployment dan instalasi Operasi dan dukungan (Operation and Support) Evolusi perangkat lunak Topik penelitian dalam RPL

5 Pustaka Booch, Grady, 1994, Object-Oriented Analysis and Design With Applications, The Benjamin/Cummings Publishing Compani, Inc., Second Edition. Brackett, John W., 1990, Software Requirements, Software Engineering Institute. Coad, Peter/Edward Yourdon, 1991, Object-Oriented Analysis, Prentice- Hall International Inc., Second Edition. Coad, Peter/Edward Yourdon, 1991, Object-Oriented Design, Prentice- Hall International Inc. Pressman, Roger. S, 2001, Software Engineering A Practitioner s Approach, McGraw-Hill Series in Computer Science, Fifth Edition. Sommerville, Ian, 1996, Software Engineering, Addison-Wesley, Fifth Edition.

6 Penilaian Praktikum 20% Kuliah 80% : UTS 30% UAS 40% Tugas / keaktifan 20% Quiz 10%

7 Peraturan Tugas dikumpulkan tepat waktu, keterlambatan tugas dan plagiarisme akan mengakibatkan nilai 0 Plagiarisme tugas akan ditindak tegas Tugas copy paste berakibat nilai 0

8 Regulasi Kehadiran Minimal kehadiran 80% Kehadiran < 80%, nilai akhir adalah K Toleransi keterlambatan 15 menit Kode Etik Mahasiswa Pakaian Sikap

9 Pendahuluan Relevansi Perkuliahan : Tuntutan customer semakin tinggi dan kompleks PL kurang andal, jadwal projek molor, perawatan susah, dll. S/W engineer belum menguasai RPL Tujuan Instruksional Khusus : Mahasiswa akan dapat menjelaskan pengertian rekayasa perangkat lunak dan mengapa rekayasa perangkat lunak diperlukan dalam mengembangkan PL 9/14

10 Agenda Pembahasan Pendahuluan Pengertian RPL Urgensi RPL RPL Hari Ini Mitos Seputar RPL 10/14

11 Pengertian RPL (S/W Engineering - WHAT) Teknologi yang meliputi proses, sekumpulan metoda & sederetan alat bantu untuk pengembangan P/L (Roger S. Pressman) Penerapan sebuah pendekatan yang sistematik, tertib, dan terukur terhadap pengembangan, pengoperasian, dan perawatan perangkat lunak (IEEE Standards Collection) Penerapan prinsip-prinsip keteknikan/rekayasa dlm rangka memperoleh P/L yg ekonomis tetapi andal dan cukup efisien berjalan pada mesin yang sesungguhnya (Fritz Bauer) 11/14

12 Pengertian RPL (S/W Engineering - WHAT) Siklus Hidup Pengembangan PL (S/W Development Life Cycle SDLC) : 1. Model Waterfall/Classic/Linear Sequential Analisis Perancangan Implementasi Pengujian 12/14

13 Pengertian RPL (S/W Engineering - WHAT) 2. Model V Analisis Perancangan Awal Perancangan Detil Implementasi Pengujian Unit Pengujian Terintegrasi Validasi 3. Model Spiral, RAD, Prototyping, RUP, XP, dll. 13/14

14 Urgensi RPL (S/W Engineering WHY) Penderitaan Kronis (Chronic Affliction) : S/W delivered behind schedule S/W costs exceeds estimates S/W unreliable S/W difficult to maintain S/W performs poorly 14/14

15 Urgensi RPL (S/W Engineering WHY) Data Survei : Standish Group IT executives in US comp. in diverse industry segments 8,380 projects average time overrun = 222%. 53%? average cost overrun = 189% Project completion 61% of originally specified features included 16% 31% On time, on budget, with all of the specified features and functions Cancelled before they were completed delivered and operational but overbudget, over-schedule or with fewer features and functions than specified? 15/14

16 Urgensi RPL (S/W Engineering WHY) S/W Eng. Framework High quality s/w Customer Developer 16/14

17 Faktor Utama Kegagalan P/L Kebutuhan customer tidak bisa dipahami dan ditangkap dengan tepat Kebutuhan customer sering mengalami perubahan Customer tidak bisa bekerja sama dengan pengembang Pengembang kurang memiliki kecakapan dalam menjalankan tugas Sistem yang dikembangkan tidak terlalu banyak memberikan manfaat kepada customer 17/14

18 RPL Hari Ini RPL tidak populer dan hanya sedikit industri PL yang menerapkan : Pengembangan PL dipahami hanyalah sebatas membuat program saja, tanpa memahami pentingnya melakukan analisis dan perancangan Jadwal projek yang ketat Belum adanya kesadaran pengambil keputusan dlm. industri PL akan kemanfaatannya Belum banyak s/w engineer yang menguasai Manajemen projek masih belum menjadi kebutuhan 18/14

19 Mitos Seputar RPL Jika jadwal molor maka kita bisa menambah lebih banyak programmer Jika kita bisa outsourcing PL maka kita bisa lebih santai Pernyataan umum tentang tujuan sistem yang akan dikembangkan sudah cukup untuk memulai pemrograman Kebutuhan sistem sering mengalami perubahan, ttp hal ini mudah diakomodasi krn PL itu fleksibel Begitu selesai program & jalan selesai 19/14

20 Mitos Seputar RPL Hasil dari projek yang sukses hanyalah program yang jalan dengan baik RPL akan membuat kita repot dengan pembuatan dokumen yang tidak perlu 20/14

21 Penutup apabila kita gagal membuat perencanaan dengan baik, maka kita sebetulnya merencanakan untuk gagal... 21/14