Rekayasa Perangkat Lunak - Universitas BrawijayaMata Kuliah Mata Kuliah : Rekayasa Perangkat Lunak Kode Mata Kuliah : PTI15011 Beban Studi : 4 SKS Sifat : Wajib Praktikum : Ada Deskripsi
Post on 26-Nov-2020
7 Views
Preview:
Transcript
Rekayasa Perangkat Lunak
Fajar Pradana S.ST., M.Eng
Fajar Pradana
CP. 08 222 820 2121
fajar.p@ub.ac.id
fajar.prd@gmail.com
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 dalammelakukan analisis kebutuhan perangkat lunak, perancangan awal danperacangan detil, implementasi / pemrograman, dan pengujianperangkat lunak.
Setelah mengikuti perkuliahan ini, mahasiswa diharapkan akan dapatmenjabarkan metoda-metoda yang harus diterapkan dalammengembangkan 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. FrameworkHigh 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
Penutup
apabila kita gagal membuat perencanaan
dengan baik, maka kita sebetulnya
merencanakan untuk gagal . . .
top related