Mata Kuliah: Rekayasa Perangkat Lunak
Renita Astri, M.Sc โ 2025/2026
Disusun oleh: M Dicky Desriansyah (22130005), Misary Handayani (22130003), Raniy Julia Putri (22130004)
Pemeliharaan perangkat lunak adalah proses memodifikasi, memperbaiki, dan meningkatkan perangkat lunak yang sudah dirilis agar tetap berfungsi optimal, memenuhi kebutuhan baru, dan bebas dari bug.
| Jenis | Tujuan | Contoh |
|---|---|---|
| Korektif (Corrective) |
Memperbaiki bug/error | Fix login gagal |
| Adaptif (Adaptive) |
Menyesuaikan lingkungan baru | Migrasi ke server cloud |
| Perfektif (Perfective) |
Meningkatkan performa | Optimasi query database |
| Preventif (Preventive) |
Mencegah masalah masa depan | Refactoring kode |
60โ80% biaya total proyek PL ada di fase maintenance.
Menjaga sistem tetap relevan dan kompatibel dengan teknologi baru.
Meningkatkan kepercayaan pengguna dan meminimalkan risiko kerusakan.
Menutup celah keamanan yang baru ditemukan.
Setiap perubahan harus melalui quality gate tidak boleh langsung diperbarui tanpa testing.
Bug: Kesalahan logika, sintaks, atau perilaku program yang menyebabkan sistem tidak berjalan sesuai harapan.
Kesalahan bahasa pemrograman (cth: kurang ";")
Hasil salah, tapi tidak error (cth: diskon salah hitung)
Error saat dijalankan (cth: NullPointerException)
Masalah saat modul digabung (cth: API gagal)
Ditemukan oleh user/QA
Catat di Issue Tracker
Kritis vs Minor
Fix & Commit
Regression Testing
Patch & Dokumentasi
Pelacakan bug & backlog Agile. Integrasi penuh Scrum.
Open-source, stabil, & mudah dikustomisasi.
Langsung di repo, cocok untuk open-source.
Visualisasi simpel, cocok untuk tim kecil.
Sistem informasi akademik universitas mengalami bug pada fitur transkrip nilai โ menyebabkan nilai IPK tidak akurat.
Referensi: IEEE 1219-1998, Sommerville (2016), Pressman (2019)
Mata Kuliah: Rekayasa Perangkat Lunak
Renita Astri, M.Sc โ 2025/2026
Disusun oleh: M Dicky Desriansyah (22130005), Misary Handayani (22130003), Raniy Julia Putri (22130004)
Kemungkinan terjadinya kejadian yang dapat menghambat, menunda, atau menurunkan kualitas proyek.
Proses sistematis untuk mengidentifikasi, menganalisis, merencanakan respons, dan memantau risiko selama proyek berlangsung.
| Jenis Risiko | Deskripsi | Contoh |
|---|---|---|
| Teknis โ๏ธ | Masalah desain, bug, integrasi | Kesalahan arsitektur |
| Manusia ๐ฅ | Kinerja, komunikasi, resign | Programmer utama resign |
| Manajemen ๐ข | Perencanaan buruk, konflik | Jadwal tidak realistis |
| Eksternal ๐ | Regulasi, vendor, infrastruktur | Server pihak ketiga down |
| Operasional ๐ | Gangguan testing/deployment | Data hilang saat migrasi |
Mengikuti pendekatan PMBOK dan IEEE 1540.
Tujuan: mengenali semua potensi risiko sejak awal proyek.
Daftar panjang potensi risiko tanpa penilaian besar/kecilnya terlebih dahulu.
Tujuan: menilai probabilitas dan dampak risiko.
| Risiko | Probabilitas (1-5) | Dampak (1-5) | Level (PxD) |
|---|---|---|---|
| Resign programmer utama | 4 | 5 | 20 (Tinggi) |
| Server lambat | 3 | 2 | 6 (Sedang) |
| Perubahan requirement | 5 | 4 | 20 (Tinggi) |
Ubah rencana untuk menghapus risiko sepenuhnya.
Kurangi probabilitas atau dampaknya.
Pindahkan risiko ke pihak lain (asuransi/vendor).
Siapkan cadangan (contingency plan) jika terjadi.
| ID | Risiko | Lvl | Strategi | PIC | Status |
|---|---|---|---|---|---|
| R1 | Server gagal saat testing | 12 | Mitigate | DevOps | Open |
| R2 | Pergantian tim QA | 25 | Transfer | PM | Closed |
| R3 | Keterlambatan vendor | 20 | Accept | PM | Open |
Proyek sistem informasi akademik mengalami delay karena perubahan requirement di tengah sprint.