Bayangkan kamu dan dua temanmu diminta membuat aplikasi kas kelas. Tanpa rencana, biasanya yang terjadi seperti ini: satu orang langsung membuat tampilan, satu orang membuat database, dan satu lagi bingung harus mengerjakan apa. Seminggu kemudian, bendahara kelas bilang ia sebenarnya butuh fitur laporan bulanan yang bisa dicetak, padahal tidak ada yang tahu. Tampilan harus dirombak, tabel database diubah, dan semua orang mulai saling menyalahkan.

Masalahnya bukan karena kalian kurang pintar menulis kode. Masalahnya, tidak ada urutan kerja yang disepakati: kapan menggali kebutuhan, kapan merancang, kapan menulis kode, kapan menguji, dan kapan merilis. Di sinilah SDLC berperan.

SDLC adalah singkatan dari Software Development Life Cycle, atau siklus hidup pengembangan perangkat lunak. SDLC adalah kerangka kerja terstruktur yang mendefinisikan tahapan untuk merencanakan, membangun, menguji, merilis, dan memelihara perangkat lunak secara sistematis.

Kata kuncinya ada di "siklus hidup". Software tidak berhenti saat kodenya selesai ditulis. Ia direncanakan, dibangun, diuji, dirilis, dipakai orang, diperbaiki, lalu dikembangkan lagi. SDLC memberi peta jalan untuk seluruh perjalanan itu, dari ide pertama sampai software terus dirawat.

Tujuan akhirnya bisa diringkas dalam satu kalimat: software berkualitas, tepat waktu, dan sesuai anggaran.

Tiga Karakter SDLC

Ada tiga sifat yang membuat SDLC berbeda dari sekadar "daftar tugas".

Perhatikan karakter ketiga. Banyak pemula membayangkan pengembangan software sebagai garis lurus yang punya ujung. Padahal kenyataannya lebih mirip lingkaran. Setiap kali ada permintaan perubahan besar, prosesnya kembali ke perencanaan.

Input, Aktivitas, Output

Cara paling mudah memahami "terstruktur" adalah melihat setiap tahap sebagai mesin kecil:

• Input: apa yang diterima tahap ini dari tahap sebelumnya.
• Aktivitas: pekerjaan yang dilakukan di tahap ini.
• Output: hasil nyata yang diserahkan ke tahap berikutnya.

Misalnya tahap desain menerima daftar kebutuhan (input), lalu tim merancang tabel dan tampilan (aktivitas), dan menghasilkan dokumen desain beserta wireframe (output). Output inilah yang menjadi input tahap implementasi. Karena rantainya jelas, kamu selalu tahu apa yang harus ada sebelum melangkah.

Deck materi menyebut enam manfaat utama. Mari kita bahas satu per satu dengan contoh.

1. Kualitas Lebih Tinggi

Standar dan pengujian di setiap tahap menekan jumlah cacat. Kalau setiap tahap punya pemeriksaan sendiri, kesalahan tidak sempat menumpuk sampai akhir.

2. Biaya Terkendali

Ini manfaat yang paling sering dilupakan pemula. Cacat yang ditemukan lebih awal jauh lebih murah diperbaiki. Bandingkan dua skenario pada aplikasi kas kelas:

• Ditemukan saat analisis kebutuhan: kamu sadar laporan harus bisa dicetak. Cukup tambah satu baris di dokumen kebutuhan. Biayanya hampir nol.
• Ditemukan di produksi: aplikasi sudah dipakai, lalu baru ketahuan laporan tidak bisa dicetak. Kamu harus mengubah kode, menguji ulang semuanya, lalu melakukan rilis darurat.

Kesalahan yang sama, biaya perbaikannya sangat berbeda. Alasannya, kesalahan di awal merambat ke tahap berikutnya: ke desain, ke kode, ke pengujian. Semakin jauh merambat, semakin banyak yang harus dibongkar.

3. Jadwal Terprediksi

Milestone yang jelas memudahkan estimasi dan pemantauan. Kalau kamu tahu desain harus selesai di minggu kedua dan ternyata belum, kamu bisa langsung menyesuaikan rencana, bukan baru panik sehari sebelum tenggat.

4. Risiko Terkelola

Risiko teknis dan bisnis diidentifikasi sejak perencanaan. Contoh risiko: "anggota tim hanya bisa kerja di akhir pekan" atau "server gratis punya batas penyimpanan". Dengan mencatatnya di awal, kamu bisa menyiapkan rencana cadangan.

5. Komunikasi Jelas

Semua pihak memahami peran, tanggung jawab, dan target. Bendahara tahu kapan ia diminta mencoba aplikasi, developer tahu fitur apa yang dikerjakan minggu ini.

6. Dokumentasi Lengkap

Pengetahuan proyek tersimpan dan mudah diwariskan. Tahun depan, adik kelasmu yang melanjutkan aplikasi ini tidak perlu menebak-nebak alasan di balik setiap keputusan.

Sepanjang kelas ini kita akan memakai satu contoh kecil yang diikuti di setiap tahap dan model: aplikasi kas kelas. Bendahara mencatat iuran mingguan, siswa bisa melihat saldo, dan wali kelas bisa mencetak laporan bulanan.

Tanpa SDLC, kalian langsung membuka editor kode. Dengan SDLC, kalian bertanya dulu: apa masalahnya, apa yang dibutuhkan, bagaimana rancangannya, bagaimana mengujinya, kapan merilisnya, dan siapa yang merawatnya setelah rilis. Pertanyaan-pertanyaan ini akan kita jawab satu per satu di bab-bab berikutnya.

Kamu juga bisa memodelkan urutan tahap dalam kode sederhana. Perhatikan bahwa setelah tahap terakhir, urutannya kembali ke awal:

const tahap = ["perencanaan", "analisis", "desain", "implementasi", "pengujian", "penerapan", "pemeliharaan"];

function tahapBerikutnya(sekarang) {
  const i = tahap.indexOf(sekarang);
  return tahap[(i + 1) % tahap.length];
}

console.log(tahapBerikutnya("desain"));       // "implementasi"
console.log(tahapBerikutnya("pemeliharaan")); // "perencanaan"

Operator % (sisa bagi) membuat indeks kembali ke 0 setelah tahap ketujuh. Itulah gambaran "siklus" dalam bentuk kode.

• Menganggap SDLC hanya untuk perusahaan besar. Proyek tugas sekolah pun mendapat manfaat dari urutan kerja yang jelas, walau dokumennya cukup sederhana.
• Mengira SDLC berarti banyak dokumen. Dokumen itu alat, bukan tujuan. Yang penting setiap tahap punya hasil yang jelas.
• Menganggap pekerjaan selesai saat rilis. Software terus dirawat setelah dipakai, dan perubahan besar memicu siklus baru.
• Langsung menulis kode. Melewatkan perencanaan dan analisis terasa cepat di awal, tetapi sering berakhir dengan bongkar ulang yang mahal.