Rekayasa Perangkat Lunak Fajar Pradana S.ST., M.Eng
Fajar Pradana
CP. 08 222 820 2121 Email
Blog:
[email protected] [email protected] fajar.lecture.ub.ac.id
Student representative
contact person
Mata Kuliah
Mata Kuliah Kode Mata Kuliah Beban Studi Sifat Praktikum Deskripsi Singkat
: Rekayasa Perangkat Lunak : PTI15011 : 4 SKS : Wajib : Ada :
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.
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
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, PrenticeHall International Inc., Second Edition. Coad, Peter/Edward Yourdon, 1991, Object-Oriented Design, PrenticeHall 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.
Penilaian
Praktikum 20% Kuliah 80% :
UTS 30% UAS 40% Tugas / keaktifan 20% Quiz 10%
Peraturan
Tugas dikumpulkan tepat waktu, keterlambatan tugas dan plagiarisme akan mengakibatkan nilai 0 Plagiarisme tugas akan ditindak tegas Tugas copy paste berakibat nilai 0
Regulasi
Kehadiran
Minimal kehadiran 80% Kehadiran < 80%, nilai akhir adalah K Toleransi keterlambatan 15 menit
Kode Etik Mahasiswa
Pakaian Sikap
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
Agenda Pembahasan
Pendahuluan Pengertian RPL Urgensi RPL RPL Hari Ini Mitos Seputar RPL
10/14
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
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
Pengertian RPL (S/W Engineering - WHAT) 2. Model V Analisis
Validasi
Perancangan Awal
Pengujian Terintegrasi
Perancangan Detil
Pengujian Unit
Implementasi
3. Model Spiral, RAD, Prototyping, RUP, XP, dll.
13/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
Urgensi RPL (S/W Engineering – WHY)
Data Survei :
Standish Group – 1995 365 IT executives in US comp. in diverse industry segments 8,380 projects Project completion
average time overrun = 222%.
61% of originally specified features included
On time, on budget, with all of the specified features and functions
16% 53%
? average cost overrun = 189%
15/14
Cancelled before they were completed
31%
delivered and operational but overbudget, over-schedule or with fewer features and functions than specified
?
Urgensi RPL (S/W Engineering – WHY)
S/W Eng.
Framework
Customer
16/14
High quality s/w
Developer
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
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
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
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
Penutup
apabila kita gagal membuat perencanaan dengan baik, maka kita sebetulnya merencanakan untuk gagal . . .
21/14
