- Bab 9 dari 9
- 25 menit
- 4 soal kuis
Praktik Terbaik, Tantangan, dan Studi Kasus
Di bab ini (6 bagian)
Tujuan bab ini
- Menerapkan delapan praktik terbaik SDLC pada proyek sendiri.
- Mengenali tantangan umum proyek software beserta solusinya.
- Mengikuti penerapan SDLC Agile pada studi kasus aplikasi layanan surat desa.
- Merangkum seluruh materi SDLC.
Praktik Terbaik SDLC
Deck menyebut delapan praktik yang dapat langsung diterapkan pada proyek apa pun. Mari lihat satu per satu beserta penerapannya pada aplikasi kas kelas.
| Praktik | Inti | Contoh penerapan |
|---|---|---|
| Libatkan pengguna sejak awal | Validasi kebutuhan lewat prototipe dan demo rutin | Tunjukkan wireframe ke bendahara sebelum menulis kode |
| Kebutuhan jelas dan terlacak | Setiap fitur terhubung ke kebutuhan dan test case | Fitur cetak laporan punya ID kebutuhan F-03 dan test case TC-11 |
| Version control dan code review | Semua perubahan tercatat dan ditinjau rekan | Setiap perubahan lewat Git dan dibaca satu teman sebelum digabung |
| Otomatisasi uji dan CI/CD | Umpan balik cepat, rilis konsisten | Tes berjalan otomatis setiap kali kode digabung |
| Estimasi realistis dan kelola risiko | Gunakan data historis dan sediakan buffer | Proyek lalu molor 1 minggu, jadi sisakan buffer 1 minggu |
| Keamanan sejak desain | Terapkan prinsip Secure SDLC di setiap tahap | Abuse case sudah dibahas saat analisis |
| Ukur dengan metrik | Defect rate, lead time, cakupan pengujian | Catat berapa bug ditemukan per rilis |
| Perbaikan berkelanjutan | Retrospektif rutin dan tindak lanjuti hasilnya | Setiap akhir sprint, pilih satu perbaikan dan jalankan |
Tentang Metrik
Tiga metrik yang disebut deck:
- Defect rate: seberapa banyak cacat yang muncul.
- Lead time: berapa lama sebuah pekerjaan dari diminta sampai sampai ke pengguna.
- Cakupan pengujian: seberapa banyak kode yang tersentuh tes.
Metrik membuat perbaikan bisa dibuktikan. Kalau setelah menerapkan code review defect rate turun, kamu punya bukti praktik itu bermanfaat.
Tentang Retrospektif
Praktik terakhir sering terlupa bagian keduanya: tindak lanjuti hasilnya. Retrospektif yang hanya berisi keluhan tanpa tindakan tidak mengubah apa pun. Pilih satu atau dua perbaikan yang konkret, lalu periksa di retrospektif berikutnya apakah sudah dijalankan.
Tantangan Umum dan Solusinya
| Tantangan | Solusi |
|---|---|
| Scope creep (ruang lingkup melebar) | Change control dan prioritas backlog yang disepakati |
| Kebutuhan tidak jelas | Prototyping, user story dan validasi bersama pengguna |
| Estimasi waktu meleset | Pecah pekerjaan kecil, estimasi berbasis data |
| Komunikasi tim buruk | Daily stand-up dan dokumentasi bersama |
| Utang teknis menumpuk | Refactoring terjadwal dan code review |
Scope creep adalah tantangan yang paling sering dialami. Contohnya pada kas kelas: di tengah proyek, satu siswa minta fitur grafik, siswa lain minta notifikasi, wali kelas minta fitur absensi. Kalau semua diterima begitu saja, proyek tidak pernah selesai. Solusinya change control: setiap permintaan baru dicatat, dinilai, lalu dimasukkan ke backlog dengan prioritas yang disepakati bersama Product Owner.
Utang teknis muncul saat tim mengambil jalan pintas demi cepat, misalnya kode disalin di banyak tempat. Lama-lama setiap perubahan jadi lambat. Solusinya refactoring terjadwal, yang tidak lain adalah pemeliharaan preventif yang sudah kamu pelajari.
Estimasi meleset bisa dikurangi dengan memecah pekerjaan menjadi bagian kecil. Menebak "fitur laporan butuh berapa lama" sulit, tetapi menebak "membuat query total per bulan" jauh lebih mudah.
Studi Kasus: Aplikasi Layanan Surat Desa
Deck memberi contoh ilustratif penerapan SDLC dengan pendekatan Agile untuk aplikasi permohonan surat online bagi warga desa. Mari ikuti setiap tahapnya.
| Tahap | Yang dilakukan |
|---|---|
| 1. Perencanaan | Tujuan: warga mengurus surat tanpa antre. Target rilis 4 bulan |
| 2. Analisis Kebutuhan | Wawancara perangkat desa dan warga, daftar jenis surat, login berbasis NIK |
| 3. Desain Sistem | ERD warga, permohonan, dan surat; wireframe formulir; arsitektur web |
| 4. Implementasi | Sprint 2 mingguan, Git dan code review, modul permohonan dan verifikasi |
| 5. Pengujian | Unit dan integration test, UAT bersama operator desa |
| 6. Penerapan | Uji coba (pilot) di satu desa, lalu rilis bertahap |
| 7. Pemeliharaan | Perbaikan bug, tambah jenis surat, pantau performa |
Hasilnya: layanan lebih cepat, data surat tercatat rapi dan mudah dilacak.
Menghubungkan dengan Materi Sebelumnya
Studi kasus ini merangkum hampir semua yang sudah kamu pelajari:
- Perencanaan punya tujuan yang jelas dan target waktu yang terukur (4 bulan).
- Analisis memakai teknik wawancara, dan login berbasis NIK adalah contoh kebutuhan yang langsung berkaitan dengan keamanan dan data pribadi. Menurut prinsip Secure SDLC, kepatuhan terhadap UU PDP perlu dipikirkan sejak awal.
- Desain menghasilkan ERD dan wireframe, dua output tahap desain.
- Implementasi memakai sprint 2 mingguan ala Scrum, ditambah Git dan code review.
- Pengujian mencakup tingkatan unit, integration, dan acceptance test bersama operator desa.
- Penerapan memakai pilot di satu desa lalu rilis bertahap. Ini mirip semangat strategi Canary: mulai dari kelompok kecil, baru diperluas.
- Pemeliharaan mencakup korektif (perbaikan bug), perfektif (tambah jenis surat), dan pemantauan.
Studi kasus ini bersifat ilustratif, tetapi polanya bisa kamu pakai untuk proyekmu sendiri.
Rangkuman Seluruh Materi
Deck merangkum SDLC dalam tiga angka: 7 tahapan inti, 6 model populer, dan 1 tujuan, yaitu software berkualitas. Poin-poin utamanya:
- SDLC memberi struktur agar pengembangan software terarah, terukur, dan berkualitas.
- Setiap tahap punya aktivitas, output, dan peran yang jelas, lalu berputar sebagai siklus.
- Pilih model sesuai karakter proyek. Agile dan DevOps unggul saat kebutuhan dinamis.
- Keamanan, otomatisasi, dan perbaikan berkelanjutan adalah kunci SDLC modern.
Pertanyaan Diskusi
Uji pemahamanmu dengan empat pertanyaan dari deck:
- Mengapa kesalahan di tahap analisis kebutuhan berdampak besar pada biaya proyek? Petunjuk: kesalahan merambat ke desain, kode, dan uji.
- Apa perbedaan verifikasi dan validasi pada V-Model? Petunjuk: produk dibangun dengan benar dibandingkan produk yang benar.
- Sebuah startup ingin rilis fitur tiap minggu. Model apa yang cocok? Petunjuk: Agile atau DevOps dengan CI/CD.
- Sebutkan dua aktivitas keamanan di tahap implementasi. Petunjuk: secure coding review, SAST, scan dependensi.
Untuk bacaan lanjutan, deck merujuk Sommerville (Software Engineering), Pressman dan Maxim (Software Engineering: A Practitioner's Approach), ISO/IEC/IEEE 12207:2017, The Scrum Guide, Agile Manifesto, NIST SP 800-218, dan OWASP SAMM. Siklusnya bisa diingat dalam tujuh kata: Plan, Analyze, Design, Build, Test, Deploy, Maintain.
Rangkuman
- Delapan praktik terbaik meliputi keterlibatan pengguna, kebutuhan terlacak, version control, otomatisasi CI/CD, estimasi realistis, keamanan sejak desain, metrik, dan perbaikan berkelanjutan.
- Tantangan umum seperti scope creep, kebutuhan kabur, estimasi meleset, komunikasi buruk, dan utang teknis punya solusi yang jelas.
- Studi kasus layanan surat desa menunjukkan tujuh tahap SDLC dijalankan dengan pendekatan Agile, dari tujuan tanpa antre sampai pemeliharaan.
- SDLC modern bertumpu pada keamanan, otomatisasi, dan perbaikan berkelanjutan.
Slide 29 sampai 36 dari deck Software Development Life Cycle (SDLC). Penjelasan lengkapnya ada di mode Baca.

Selesaikan bab ini
- 1. Baca materi
- 2. Kuis (4 soal)
Cek pemahaman
1Solusi yang disarankan untuk scope creep adalah...
2Pada studi kasus layanan surat desa, strategi penerapannya adalah...
3Defect rate, lead time, dan cakupan pengujian adalah contoh metrik dalam praktik terbaik SDLC.
4Solusi untuk utang teknis yang menumpuk adalah...
