Blog

Blog APTIKA DISKOMINFOSP KUTIM

Software Development Life Cycle (SDLC) Best Practices

Senin, 14 September 2026 03:20 PM
Ami Arief
Artikel
Views 13

SDLC adalah konsep. Mencakup di dalamnya tahapan, ekosistem metodologis multidimensional yang mentransformasikan kebutuhan tata kerja/laksana dan manusia menjadi solusi digital yang aman, efisien, dan terkelola secara struktural sepanjang siklus hidupnya. Siklus normatif SDLC, memang lebih menjanjikan ketertiban dalam penerapan SDLC, namun sedikit improvisasi pada persiapan dalam bentuk inisialisasi/pendefinisian output yang diperlukan pasca SDLC akan memberikan lebih sedikit risiko dan membantu menjadikan pembuatan dan pengembangan perangkat lunak lebih efektif dan efisien.

Tahapan

  • persiapan

    • pihak supervisi dan teknis terlebih dahulu memastikan tidak ada aplikasi umum atau aplikasi khusus yang telah mengakomodasi kebutuhan transformasi digital atas tata kerja/laksana yang hendak didigitalisasi melalui mekanisme registrasi untuk akses user tenant (jika tidak memahami ini, maka dapat berkonsultasi/berkoordinasi ke Diskominfo terdekat/instansi pembina berkenaan Probis terkait)
    • surat tugas Pengelola Teknis Teknologi Informasi/Aplikasi Informatika (PTTI/AI)
    • PTTI/AI yang sudah ada surat tugasnya, dilakukan registrasi pada SI Aptika Kutim dan melakukan simulasi pengisian formulir Domain dan formulir Aplikasi untuk membantu memetakan modul-modul layanan pada Proposal/BRD
    • inisialisasi/pendefinisian output yang diperlukan pasca SDLC (jika bisa "harus ada di awal" maka jangan "sebaiknya ada di awal"), misal
      • breakdown penjadwalan/timestamp SDLC dari persiapan hingga pasca SDLC;
      • proposal beserta kerangka tulisan, (butir pada Renstra/RKA/KAK jika menggunakan anggaran);
      • kerangka tulisan laporan pembuatan/pengembangan yang komprehensif;
      • source code dan database;
      • dokumen-dokumen berkenaan anggaran (jika ada), dsb
    • analisis kebutuhan (Business Requirement Document/BRD)
    • jika memungkinkan, membuat, menjalankan dan mematangkan prototype sebelum masuk SDLC akan mengkondisikan penggarapan laporan lebih sedikit revisi, terutama pada bagian desain dan perancangan sistem

  • proses inti

    • perencanaan (pendahuluan)
    • landasan teori (termasuk di dalamnya analisis kebutuhan/BRD)
    • rancang bangun (desain dan perancangan sistem)
    • implementasi & pengujian
      • implementasi
      • pengujian (uji kelayakan)
        • black box
        • white box
        • penetration testing

  • pasca pengembangan

    • pemeliharaan (teknis dilakukan oleh PTTI/AI)
    • evaluasi (dipimpin oleh supervisi/struktural, diikuti oleh PTTI/AI beserta pihak yang terkait)

 

Tips lainnya

  • proposal dan prototype serta dokumen pembuatan perangkat lunak selesai di satu atau dua tahun awal;
  • prototype yang telah selesai, dijalankan selama 3 tahun;
  • laporan pembuatan dan pengembangan dikerjakan setelah 3 tahun menjalankan prototype. Ini lebih menjamin integritas, antara apa laporan yang ada dan apa proses bisnis yang telah/diperkirakan stabil untuk dijalankan.

Untuk tips ini dapat diabaikan jika orientasi/keperluannya adalah kecepatan penggarapan dan penyelesaian laporan pertanggungjawaban anggaran.

 

Benefit

Benefit yang didapatkan atau permasalahan yang termitigasi atas penerapan SDLC di atas jika dilakukan dengan benar yakni:

  • jika datang masa uji kelayakan/audit/sertifikasi kelayakan penyelenggaraan aplikasi, maka tidak ada beban yang terlalu berat diderita jajaran penyelenggara dan pelaksana, sebab segala hal yang paling diperlukan, paling krusial, paling fundamental telah tuntas/dipersiapkan di awal sebelum masuk ke proses inti SDLC;
  • tidak ada permasalahan berarti dalam konteks peralihan penatakelolaan. Berita Acara Serah Terima (BAST) hanya akuntabilitas dari entitas pengembang ke pengguna, namun tidak menjamin benar atau salahnya suatu tata kelola, proses bisnis, apalagi menjamin penguasaan mitigasi risiko penyelenggaraan dan pelaksanaan kepada penyedia layanan yang diserahi (pada BAST). Penguasaan end-to-end tata kelola oleh pihak 'yang punya' Probis lebih menjamin business continuity. Karena tahap perencanaan, landasan teori, analisis kebutuhan, perancangan sistem pada SDLC ditangani langsung oleh 'yang punya' Probis (Unor yang menjalani/hidup dalam Probis tersebut). Tidak ada lagi kondisi gagap Probis/gagap teknologi dalam konteks pemanfaatan, perawatan dan pengembangan sistem seselesainya tahap implementasi;
  • jika hendak masuk kepada kapabilitas kolaborasi dari kapabilitas transaksional, tidak ada biaya lebih/waktu lebih banyak yang diperlukan, karena 'yang punya' Probis sudah memiliki penguasaan cukup dari sisi desain database, familiar/memiliki penguasaan atas metadata yang hendak dibuat API
  • jika ada beberapa digit karakter atau satu dua baris program yang perlu diubah/diperbaiki, workflow-nya hanya sebatas:
    • PTTI/AI ubah kode sumber/sunting database pada media pengembangan,
    • unggah secara parsial ke media operasi.
  • Prosesnya tidak menjadi seperti ini:
    • menemukan adanya bahan perbaikan/perubahan,
    • lapor ke atasan langsung bahwa ada yang perlu diubah pada sistem,
    • atasan langsung menelaah dan mempertimbangkan terlebih dahulu,
    • atasan langsung mengkonfirmasi,
    • atasan langsung memberi instruksi kepada staf administrasi bahwa ada tata naskah yang perlu dibuat,
    • konseptor membuat satu atau beberapa lembar konsep surat keluar,
    • konsep dibawa ke verifikator untuk ditelaah,
    • konseptor melakukan revisi (jika ada),
    • perulangan proses hingga verifikator melakukan verifikasi (jika ada),
    • membawa/mengantre konsep ke Sekretaris/Kepala Dinas (jika pintunya dapat dibuka dan jika Ybs. ada di tempat serta jika ada konsep antrean nomor yang diimplementasi (first in first out)),
    • Sekretaris/Kepala Dinas melakukan paraf/tanda tangan (jika tidak ada revisi/pertimbangan lain),
    • login ke Srikandi,
    • unggah dokumen yang telah dinomori,
    • masuk ke proses verifikasi, tindak lanjut atasan langsung untuk verifikasi dokumen,
    • tindak lanjut Sekretaris/Kepala Dinas/perwakilan untuk TTE,
    • mengunduh dokumen TTE,
    • mengirim surat ke instansi/konsultan TI,
    • menunggu respon (jika ada direspon),
    • menindaklanjuti surat jika lama tidak direspon (melakukan perulangan atau berkunjung hingga direspon),
    • jika direspon maka membuat janji bertemu dengan pihak terkait,
    • berkoordinasi dengan pihak terkait,
    • pihak terkait mengubah (hanya) satu-dua karakter/satu-dua baris program yang perlu diubah.
    • pada intinya, terlalu panjang proses untuk terlalu sedikit kode program yang perlu diperbaiki/diubah. Jika birokrasi dan tata naskah diselisihi, maka menjadi pihak yang tidak patuh terhadap hukum, sementara hukum sendiri atas fungsinya sudah benar, tidak bersalah. Maka penyelesaian jangka panjangnya yakni PTTI/AI yang sudah diinisialisasikan pada surat tugas, melakukan perbaikan sendiri atas hasil deteksi. Tidak sampai berapa jam, hal sepelepun selesai dan tidak perlu berpindah-pindah Unor apalagi Instansi dengan eskalasi yang terlalu luas.

 

Referensi:

  • Peraturan Menteri Pendayagunaan Aparatur Negara dan Reformasi Birokrasi Republik Indonesia Nomor 8 Tahun 2026 tentang Evaluasi Kinerja Pemerintah Digital | Indikator 13: Deskripsi Indikator
  • Petunjuk Teknis Penyelenggaraan Aplikasi di Daerah Kabupaten Kutai Timur | Bab III. SOP Penyelenggaraan Aplikasi Domain Layanan Pengembangan Mandiri
Tags:
software development life cycle sdlc output persiapan prototype pengelola teknis teknologi informasi