Di bab sebelumnya kamu sudah mengenal tujuh tahap SDLC. Pertanyaan berikutnya: bagaimana tahapan itu dijalankan? Apakah satu per satu sampai selesai? Apakah diulang dalam putaran kecil? Apakah semuanya berjalan terus-menerus?

Jawabannya tergantung model SDLC yang dipakai. Model adalah cara menyusun dan menjalankan tahapan. Deck membahas enam model populer: Waterfall, V-Model, Iteratif, Spiral, Agile, dan DevOps. Bab ini membahas dua model klasik yang sifatnya berurutan: Waterfall dan V-Model.

Pada model Waterfall, tahapan berjalan berurutan seperti air terjun. Tahap berikutnya dimulai setelah tahap sebelumnya selesai. Urutannya:

1. Kebutuhan
2. Desain
3. Implementasi
4. Pengujian
5. Penerapan
6. Pemeliharaan

Bayangkan air yang jatuh dari tingkat atas ke tingkat bawah. Air tidak naik kembali. Begitu pula di Waterfall: setelah desain disetujui dan tim masuk ke implementasi, kembali mengubah kebutuhan menjadi mahal dan merepotkan.

Waterfall diperkenalkan lewat makalah Winston Royce (1970) dan menjadi model klasik.

Kelebihan dan Kekurangan

Waterfall cocok untuk proyek dengan kebutuhan jelas dan stabil, serta proyek kecil sampai menengah.

Skenario: Kas Kelas dengan Waterfall

Misalkan kebutuhan aplikasi kas kelas sudah sangat jelas: catat iuran, lihat saldo, cetak laporan. Bendahara sudah memakai format buku kas yang sama selama tiga tahun dan tidak ada rencana perubahan. Dalam kondisi ini Waterfall masuk akal:

• Minggu 1: kebutuhan ditulis lengkap dan disetujui bendahara.
• Minggu 2: desain database dan tampilan selesai.
• Minggu 3 sampai 4: implementasi.
• Minggu 5: pengujian.
• Minggu 6: rilis.

Jadwal mudah dibuat dan dipantau. Tapi perhatikan risikonya: bendahara baru melihat aplikasi yang bisa dipakai di minggu ke-5 atau ke-6. Kalau saat itu ia baru sadar butuh fitur pengingat tagihan, perubahan harus masuk lewat jalur yang mahal karena desain dan kode sudah jadi.

Di sinilah kekurangan "kesalahan analisis mahal diperbaiki" terasa nyata. Kesalahan di tahap kebutuhan baru ketahuan di akhir, setelah merambat ke semua tahap.

V-Model adalah pengembangan Waterfall dengan penekanan pada pengujian. Bentuknya seperti huruf V. Sisi kiri berisi tahap desain yang menurun, bagian bawah adalah coding, dan sisi kanan berisi tahap pengujian yang naik.

Kekuatan utamanya: setiap tahap desain di sisi kiri dipasangkan dengan tahap pengujian di sisi kanan, dan rencana uji disusun sejak awal.

Coding berada di titik paling bawah huruf V.

Artinya, saat tim menulis analisis kebutuhan, mereka sekaligus menyusun rencana acceptance test. Saat merancang modul, mereka sekaligus merencanakan unit test untuk modul itu. Pengujian tidak lagi menjadi urusan di akhir saja.

Verifikasi vs Validasi

Dua kata ini sering tertukar. Deck memberi rumusan yang mudah diingat:

• Verifikasi: apakah kita membangun produk dengan benar? (building the product right)
• Validasi: apakah kita membangun produk yang benar? (building the right product)

Contoh pada kas kelas:

• Verifikasi: apakah fungsi perhitungan saldo sesuai dengan dokumen desain? Apakah kode mengikuti spesifikasi? Ini memeriksa kesesuaian dengan rancangan.
• Validasi: apakah aplikasi ini benar-benar membantu bendahara mengelola kas? Bisa saja semua sesuai desain, tetapi ternyata bendahara butuh hal lain. Ini memeriksa kesesuaian dengan kebutuhan nyata pengguna.

Produk bisa lolos verifikasi tapi gagal validasi: dibangun persis sesuai rancangan, tapi rancangannya tidak menjawab kebutuhan. Itulah mengapa acceptance test (yang melibatkan pengguna) dipasangkan dengan analisis kebutuhan.

Kelebihan dan Kekurangan V-Model

V-Model cocok untuk sistem kritis seperti medis, otomotif, dan perbankan. Di sistem seperti ini, kesalahan bisa membahayakan nyawa atau uang dalam jumlah besar, sehingga disiplin pengujian dan kemudahan audit lebih penting daripada fleksibilitas.

Memodelkan Pasangan V-Model

Pasangan di V-Model bisa ditulis sebagai objek sederhana:

const pasanganV = {
  "analisis kebutuhan": "acceptance test",
  "desain sistem": "system test",
  "desain arsitektur": "integration test",
  "desain modul": "unit test",
};

console.log(pasanganV["desain modul"]); // "unit test"

Keduanya sama-sama berurutan dan sulit menerima perubahan. Bedanya, Waterfall menaruh pengujian sebagai satu tahap setelah implementasi, sedangkan V-Model merencanakan pengujian sejak tahap desain dan memasangkannya secara eksplisit. Karena itu V-Model biasanya mendeteksi cacat lebih awal.

• Mengira Waterfall selalu buruk. Untuk kebutuhan yang jelas dan stabil, kesederhanaannya justru menguntungkan.
• Menukar pasangan V-Model. Analisis kebutuhan berpasangan dengan acceptance test, bukan unit test. Desain modul yang berpasangan dengan unit test.
• Menyamakan verifikasi dan validasi. Verifikasi tentang "dengan benar", validasi tentang "yang benar".
• Memakai V-Model untuk produk yang kebutuhannya terus berubah. Sifatnya yang kaku akan memperlambat tim.