Banyak orang membayangkan pembuatan aplikasi sebagai pekerjaan menulis kode di depan layar hitam. Kenyataannya, mengetik kode hanya satu bagian kecil dari rangkaian keputusan yang disebut Software Development Life Cycle (SDLC) atau siklus hidup pengembangan perangkat lunak. SDLC bukan teori akademis, melainkan urutan tahapan yang menentukan apakah sebuah aplikasi akhirnya dipakai orang atau ditinggalkan setelah dua bulan.
Cara paling mudah memahaminya adalah mengikuti satu contoh dari awal sampai akhir. Bayangkan sebuah klinik di kota kabupaten yang ingin punya aplikasi antrean agar pasien tidak menumpuk sejak pukul enam pagi. Dari titik itu, seluruh tahap SDLC bisa terlihat bekerja.
Tahap kebutuhan: proyek biasanya gagal di sini, bukan di kode
Tahap pertama adalah analisis kebutuhan. Di sinilah kegagalan paling mahal terjadi, dan penyebabnya jarang bersifat teknis. Pemilik klinik berkata, “Saya butuh aplikasi antrean.” Jika tim pengembang langsung membuatnya, hasilnya mungkin aplikasi yang rapi tetapi tidak menyelesaikan masalah. Sebab masalah sebenarnya bukan antrean, melainkan dokter yang sering datang terlambat sehingga jadwal bergeser satu jam.
Analis yang baik tidak berhenti pada permintaan, tetapi mengejar akar persoalannya: siapa yang memanggil nomor antrean sekarang, apa yang terjadi kalau pasien lansia tidak punya ponsel pintar, dan bagaimana perawat mencatat pasien darurat yang harus menyalip antrean. Pertanyaan-pertanyaan itu berujung pada dokumen kebutuhan. Perubahan satu kalimat di dokumen ini biayanya nol rupiah; perubahan yang sama setelah aplikasi jadi bisa berarti membongkar struktur basis data.
Desain: keputusan yang paling mahal untuk dibatalkan
Setelah kebutuhan jelas, tim menyusun desain — mulai dari alur layar (wireframe), struktur basis data, sampai arsitektur server. Pada tahap ini pula muncul pertanyaan yang sering dilewati tim kecil: data apa saja yang sebenarnya perlu dikumpulkan?
Aplikasi antrean klinik menyimpan nama, nomor telepon, keluhan, dan bisa jadi nomor rekam medis. Semua itu termasuk data pribadi, dan sebagian tergolong data pribadi spesifik menurut Undang-Undang No. 27 Tahun 2022 tentang Pelindungan Data Pribadi (UU PDP). Undang-undang tersebut mewajibkan pengendali data melakukan penilaian dampak pelindungan data pribadi untuk pemrosesan berisiko tinggi, termasuk data kesehatan. Artinya, keputusan “apakah kolom keluhan pasien perlu disimpan permanen atau cukup 30 hari” adalah keputusan desain, bukan urusan teknis belakangan. Prinsip inilah yang disebut privacy by design: pelindungan data dipasang di gambar rancangan, bukan ditempel setelah aplikasi jalan.
Pengembangan: menulis kode sambil mencatat jejaknya
Tahap pengembangan adalah saat kode ditulis. Yang membedakan tim profesional dari tim asal jadi bukan kecepatan mengetik, melainkan disiplin pencatatan. Kode disimpan dalam sistem kontrol versi seperti Git, sehingga setiap perubahan tercatat siapa penulisnya dan kapan dilakukan. Ketika suatu fitur rusak, tim bisa menelusuri perubahan mana yang menjadi penyebab, lalu mengembalikan kondisi sebelumnya dalam hitungan menit.
Sebelum masuk ke sistem utama, kode biasanya dibaca dulu oleh rekan setim (code review). Praktik sederhana ini menangkap banyak kesalahan yang tidak terlihat oleh penulisnya sendiri, misalnya kolom nomor telepon yang menerima teks bebas sehingga notifikasi antrean gagal terkirim.
Pengujian: bug yang lolos adalah bug yang tak terbayangkan
Pengujian sering disalahpahami sebagai “mencoba klik semua tombol”. Padahal masalah paling merepotkan justru muncul dari skenario yang tidak pernah dibayangkan perancangnya. Contoh klasik di Indonesia: formulir yang mewajibkan nama depan dan nama belakang, padahal banyak warga memiliki nama satu kata di KTP. Atau dua perawat yang menekan tombol “panggil pasien berikutnya” pada detik yang sama, sehingga satu nomor antrean terlewati.
Karena itu pengujian dilakukan berlapis: pengujian unit untuk memastikan tiap fungsi kecil bekerja, pengujian integrasi untuk memastikan antarbagian saling terhubung, lalu uji coba oleh calon pengguna sungguhan. Pada aplikasi yang menyimpan data pribadi, ditambah pengujian keamanan. Badan Siber dan Sandi Negara (BSSN) menyediakan acuan pengelolaan keamanan informasi, salah satunya Indeks KAMI, yang bisa dipakai instansi untuk mengukur kesiapan sistemnya sebelum digunakan publik.
Rilis: bukan garis finis, melainkan pintu masuk
Aplikasi yang lulus uji tidak langsung dilempar ke semua pengguna. Praktik yang lazim adalah rilis bertahap: dibuka dulu untuk satu poli atau sepuluh persen pengguna, dipantau beberapa hari, baru diperluas. Bila terjadi lonjakan galat, tim menarik versi baru dan kembali ke versi lama.
Rilis juga membawa kewajiban administratif. Berdasarkan PP No. 71 Tahun 2019 tentang Penyelenggaraan Sistem Elektronik dan Transaksi Elektronik, penyelenggara sistem elektronik wajib mendaftarkan layanannya, dan pendaftaran PSE kini dikelola Kementerian Komunikasi dan Digital (Komdigi, sebelumnya Kominfo). Selain itu, UU PDP mengatur bahwa bila terjadi kegagalan pelindungan data pribadi, pemberitahuan harus disampaikan kepada subjek data dan lembaga terkait paling lambat 3x24 jam — kewajiban yang menuntut tim sudah punya sistem pemantauan dan log sejak hari pertama, bukan dicari saat insiden terjadi.
Pemeliharaan: bagian terpanjang yang paling sering diabaikan
Setelah dirilis, siklus berputar kembali. Pemeliharaan mencakup perbaikan bug, pembaruan pustaka pihak ketiga yang ditemukan bercelah, penyesuaian saat regulasi berubah, hingga penambahan fitur baru berdasarkan keluhan pengguna. Dalam banyak proyek, tahap inilah yang menyerap porsi biaya terbesar sepanjang usia aplikasi.
Yang menumpuk di tahap ini adalah technical debt — utang teknis akibat jalan pintas yang diambil saat mengejar tenggat. Kode yang ditulis “sementara” dan tidak pernah dibereskan membuat setiap perubahan berikutnya makin lambat dan berisiko.
Waterfall atau agile?
Urutan tahapan di atas bisa dijalankan secara berurutan kaku (waterfall) atau berulang dalam siklus pendek dua mingguan (agile). Waterfall masih relevan untuk proyek dengan spesifikasi terkunci sejak awal, misalnya pengadaan pemerintah yang kontraknya rinci. Agile lebih cocok bila kebutuhan pengguna belum pasti dan produk perlu diuji ke pasar lebih cepat. Keduanya melewati tahap yang sama; yang berbeda hanya seberapa sering tim kembali ke tahap awal.
Memahami SDLC berguna bukan hanya bagi programmer. Bagi pemilik usaha atau pengelola instansi yang memesan aplikasi, kerangka ini menjadi alat untuk bertanya secara tepat: sudah sampai tahap mana pekerjaannya, siapa yang menguji, dan siapa yang bertanggung jawab merawatnya setelah kontrak selesai.
