Belajar System Analyst - SDLC & Metodologi

#Pendahuluan

Setelah di episode 1 kalian memahami peran System Analyst sebagai jembatan bisnis-teknik, pada episode ini kita membahas kerangka tempat seluruh pekerjaan itu berlangsung: SDLC (Software Development Life Cycle) dan metodologinya. Mengapa ini penting sebelum masuk ke requirement? Karena setiap artefak yang akan kalian hasilkan — user story, diagram UML, SDD, test scenario — melekat pada fase tertentu dalam SDLC. Dan setiap metodologi menentukan kapan artefak itu dibuat, oleh siapa divalidasi, dan seberapa sering berubah.

Analoginya seperti membangun rumah vs merenovasi dapur: keduanya konstruksi, tetapi urutan kerja, frekuensi perubahan desain, dan pola komunikasinya sangat berbeda. Analyst yang tidak memahami metodologi proyeknya akan salah memilih bentuk dokumen — misalnya menulis BRD 60 halaman untuk tim yang bekerja sprint dua mingguan.

#Anatomi SDLC

SDLC adalah siklus hidup software dari ide sampai pensiun. Enam fase intinya:

Perhatikan posisi SA: dominan di Analysis dan Design, tetapi menyentuh semua fase. Inilah alasan episode-episode series ini tersusun mengikuti alur SDLC.

#Fase yang Sering Diremehkan: Maintenance

Banyak pemula menganggap proyek selesai saat go-live. Kenyataannya, biaya maintenance bisa mencapai 60-80% dari total cost of ownership. Keputusan desain kalian hari ini menentukan betapa mahalnya perubahan tiga tahun lagi. Prinsipnya: setiap rupiah yang dihemat di fase analisis biasanya dikali sepuluh di fase maintenance.

#Waterfall

Waterfall menjalankan fase secara linear dan sekuensial: analisis selesai → desain dimulai → dst. Dokumen menjadi gate: fase berikutnya tidak boleh mulai sebelum artefak fase sebelumnya di-sign-off.

Requirements ──▶ Design ──▶ Implementation ──▶ Verification ──▶ Maintenance

Kapan Waterfall masih tepat?

• Kebutuhan benar-benar stabil dan dipahami sejak awal.
• Domain teregulasi ketat (perbankan core system, avionik, alat medis) yang mensyaratkan dokumentasi audit lengkap sebelum kode ditulis.
• Vendor fixed-price/fixed-scope dengan kontrak klasik.
• Integrasi dengan sistem fisik yang tidak bisa iteratif.

Kelebihan: rencana jelas, dokumentasi lengkap, mudah dikelola manajemen tradisional. Kekurangan: perubahan mahal (kesalahan analisis baru ketahuan saat testing), feedback pengguna datang terlambat, risiko membangun produk yang tepat-disesifikasikan-tapi-salah.

#Agile dan Scrum

Agile membalik logika: daripada mendokumentasikan semuanya lalu membangun sekali jalan, kita membangun sedikit, belajar cepat, menyesuaikan terus. Nilainya dirangkum dalam Agile Manifesto: individu & interaksi di atas proses & tool, software yang berfungsi di atas dokumentasi komprehensif, kolaborasi dengan customer di atas negosiasi kontrak, merespons perubahan di atas mengikuti rencana.

Scrum adalah implementasi Agile paling populer dengan ritme tetap:

Dalam dunia Agile, artefak SA berubah bentuk: BRD raksasa pecah menjadi product backlog, requirement ditulis sebagai user story + acceptance criteria, dan diagram dibuat just-in-time — cukup detail untuk sprint berjalan, bukan untuk setahun ke depan.

#Hybrid

Praktik industri nyata sering berada di tengah: hybrid. Pola umumnya:

• Waterfall untuk gerbang besar: business case, kontrak, milestone release, compliance sign-off.
• Agile di dalam eksekusi: sprint, demo rutin, backlog adaptif.

Model lain yang patut kalian kenal sebagai kosakata:

• Kanban: alur kontinu tanpa sprint, cocok untuk tim support/maintenance dengan pekerjaan tak terduga.
• V-Model: varian Waterfall di mana setiap fase pengembangan dipasangkan dengan fase testing-nya — populer di industri safety-critical.
• Spiral: iterasi berbasis manajemen risiko, leluhur konsep risk-driven iteration.

#Cara Memilih Metodologi

Jangan memilih karena tren. Gunakan lima pertanyaan penentu:

1. Seberapa stabil kebutuhan? Stabil → Waterfall layak; berubah cepat → Agile.
2. Bagaimana struktur kontrak? Fixed-price scope kaku condong Waterfall; time-and-material condong Agile.
3. Akses ke pengguna? Mudah diajak rutin → iterasi bernilai tinggi; sulit diakses → butuh analisis depan lebih dalam.
4. Tingkat regulasi & audit? Ketat → dokumentasi gate lebih tebal (Waterfall/V-Model/hybrid).
5. Ukuran & distribusi tim? Tim besar multi-vendor sering butuh gerbang formal meski eksekusinya agile.

Terapkan ke studi kasus TokoKita kita: owner ingin POS + inventori terpusat untuk 12 cabang. Kebutuhan inti kasir relatif stabil, tetapi fitur lanjutan (laporan, promo, integrasi supplier) masih cair. Owner punya modal terbatas dan ingin lihat hasil cepat di cabang pilot. Regulasi: pencatatan pajak standar, tidak ada domain ultra-ketat.

Keputusan yang masuk akal: hybrid — fase analisis & desain arsitektur dilakukan cukup dalam di awal (fondasi data & integrasi tidak boleh asal), kemudian pembangunan fitur berjalan sprint 2 mingguan dengan pilot satu cabang sebagai iterasi nyata.

project: TokoKita POS & Inventory
metodologi: hybrid
fase_depan:
  gaya: waterfall-ringan
  durasi: 4 minggu
  output:
    - brd-ringkas
    - sdd-arsitektur-inti
    - erd-v1
eksekusi:
  gaya: scrum
  sprint: 2 minggu
  pilot_cabang: 1
gerbang_release:
  - uat-lulus-di-pilot
  - training-kasir-selesai
  - owner-sign-off

#Jebakan Umum

Tiga kesalahan yang paling sering saya lihat di lapangan:

1. Agile sebagai alasan tanpa analisis — tim bilang "agile" lalu langsung coding tanpa memahami proses bisnis. Hasilnya produk rapi tapi salah arah. Iterasi mengganti arah, bukan mengganti pemahaman.
2. Cargo cult ceremony — daily scrum, sprint board, retro semua jalan, tetapi tidak ada keputusan yang berubah. Metodologi adalah sarana; ukuran keberhasilannya adalah value yang terkirim.
3. Skala dokumen tidak menyesuaikan — menuntut SDD lengkap ala Waterfall di tim 5 orang, atau sebaliknya tanpa dokumentasi apa pun di program korporasi 200 orang. Sesuaikan bobot dengan risiko, bukan tradisi.

#Penutup

Inti yang harus dibawa pulang:

• SDLC punya enam fase — planning, analysis, design, implementation, testing, deployment/maintenance — dan SA dominan di analysis-design namun menyentuh semuanya.
• Waterfall unggul saat kebutuhan stabil & regulasi ketat; Agile/Scrum unggul saat kebutuhan cair & akses pengguna baik; hybrid adalah realitas industri.
• Pilih metodologi lewat lima pertanyaan: stabilitas kebutuhan, kontrak, akses pengguna, regulasi, dan skala tim — bukan karena tren.
• Untuk TokoKita kita memutuskan hybrid: fondasi analisis-depan ringkas, eksekusi sprint 2 mingguan dengan cabang pilot.

Di episode 3 selanjutnya kita masuk ke jantung pekerjaan SA: requirement gathering — teknik interview, workshop, dan elicitation lainnya, termasuk praktik interview session sungguhan dengan stakeholder TokoKita. Pastikan tetap semangat!