Rekayasa Perangkat Lunak
Fajar Pradana S.ST., M.Eng
Fajar Pradana
CP. 08 222 820 2121
Blog:
fajar.lecture.ub.ac.id
Student representative
contact person
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.
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, 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.
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
9/14
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
10/14
Agenda Pembahasan
Pendahuluan
Pengertian RPL
Urgensi RPL
RPL Hari Ini
Mitos Seputar RPL
11/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)
12/14
Pengertian RPL (S/W Engineering - WHAT)
Analisis
Perancangan
Implementasi
Pengujian
Siklus Hidup Pengembangan PL
(S/W Development Life Cycle – SDLC) :
1. Model Waterfall/Classic/Linear Sequential
13/14
Pengertian RPL (S/W Engineering - WHAT)
Implementasi
2. Model V
Perancangan Awal
Perancangan Detil
Analisis
Pengujian Unit
Pengujian Terintegrasi
Validasi
3. Model Spiral, RAD, Prototyping, RUP, XP, dll.
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
15/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
16%
31%
53%
On time, on budget, with all of the specified features and functions
Cancelled before they were completed
delivered and
operational but over- budget, over-schedule or with fewer features and functions than specified
average cost overrun = 189%
average time overrun =
222%.
61% of originally specified features included
?
?
16/14
Urgensi RPL (S/W Engineering – WHY)
S/W Eng. Framework High quality
s/w
Customer Developer
17/14
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
18/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
19/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
20/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
21/14
