Beberapa tahun yang lalu, gw pernah diminta memuat software untuk mencatat transaksi pembayaran siswa di suatu sekolah.Kebutuhan yang diminta sendiri sebenarnya tidak terlalu banyak : Mencatat  history pembayaran SPP, uang bangunan, dan kewajiban-kewajiban lain seperti baju seragam, buku, dll. Masing-masing pembayaran memiliki aturan sendiri, sperti SPP dibayar setiap bulan, uang bangunan hanya sekali, dan lainnya.

Ok, buat kalian yang kebetulan programmer, mungkin dikepalanya akan langsung muncul struktur database. Selain database, yang juga ikutan muncul diotak palingan proses CRUD sederhana + pencarian. Soal design dan interface bisa belakangan. Ya.. ama sedikit report agregasi lah.. Gak gitu salah emang. Dulu juga yang muncul dikepala gw kayak gitu pada awalnya. Sampai.. proses development dimulai.

Semakin jauh proses development dijalani ternyata semakin banyak kebutuhan-kebutuhan dan masalah yang sebelumnya tidak terpikirkan sama sekali. Sebagai contoh, apa yang terjadi dengan siswa yang biaya sekolahnya digratiskan? Apakah dianggap sudah membayar saja? Apakah proses ini perlu diotomatisasi? Atau dilakukan manual oleh petugas? Lalu bagaimana efeknya terhadap laporan pemasukan sekolah? Terus gimana kalau biaya yang digratiskan hanya sebagian saja? Hm.. baru sampai sini sudah bikin pusing kepala. Itu belum termasuk hal-hal mendasar yang mau gak mau harus dibuat dan dipikirin alur datanya seperti struktur database siswanya sendiri. Inilah analisis software, mungkin tepatnya bussiness logic. Sangat sulit.

Masih di proyek sekolah diatas, ada satu kasus favorite yang akan selalu gw kenang : Apa yang terjadi kalau siswanya sudah lulus ? Apakah sidata dihapus? Atau diarsip dalam bentuk file? Atau bagaimana? Gw sempat ngobrol-ngobrol sama temen gw soal ini. Kata temen gw “hapus aja dan, daripada menuh-menuhin database”. Gw pun waktu itu merasa itu solusi yang masuk akal dan benar-benar gw terapkan. Baru saat gw ketemu ama client, gw sadar kalau solusi itu salah total. Kata si client “Well.. sering ada kasus dimana siswa baru membayar uang bangunan setelah dia lulus dan bekerja“.

hahaha.. Satu pelajaran penting mengenai analisis logika bisnis : Jangan pernah menebak.

Ini formula penting. Biar sekali lagi gw ulang. Pada saat ragu mengenai suatu kasus, jangan coba-coba menebak atau mengira-ngira, tanyakan pada domain expert yang bersangkutan. You need to be sure..

Oke, sekarang kita liat contoh kasus yang masih sangat-sangat hangat, bahkan panas : KRS Online. Dengan mencoba duduk di sisi programmer, gw membayangkan bahwa gw sedang kebingungan untuk menentukan tindakan apa yang harus diambil saat jadwal bentrok. Logika gw mengatakan, gak mungkin satu orang ikut kuliah di 2 tempat sekaligus. Harus ada satu mata kuliah yang dikorbankan. Mungkin kira-kira itu keputusan yang diambil oleh tim development KRS. Andai gw jadi yang bikin KRS, kemungkinan besar langkah itu juga yang bakalan gw ambil.

Diluar nebak atau bukan, kasus didunia nyata sering berkata lain. Ada fakta-fakta yang harus diperhatikan seperti jadwal praktikum yang sebenarnya sangat sering tidak sama dengan jadwal yang tertera di KRS. Untuk menghindari bentrok, banyak hal bisa dinegoisasikan termasuk diantaranya pemindahan jadwal. Tapi kalau dari awal kita gak boleh ngambil karena jadwal bentrok? hum.. mau apa lagi? Gak ngambil berarti gak bayar, dan gak bayar berarti gak boleh ikut kuliah. Untuk mahasiswa tingkat akhir kayak gw, penundaan pengambilan dan pengulangan mata kuliah sama dengan penundaan kelulusan. Wew..

Jujur, untuk masalah ini gw lebih senang solusi tahun lalu. Sistem KRS memberi peringatan saat terjadi jadwal bentrok, tapi tidak menghalangi mahasiswa untuk tetap ngotot mengambil matakuliah yang bentrok itu. Toh, soal jadwal masih bisa dinegoisasikan atau kadang ada solusi tak terduga lainnya ( seperti kelas tambahan atau ngambil mk yang sama di jurusan laen ).

Yap.. bagaimanapun, membuat software itu susah. Menganalisa problem-problem dan kebutuhan-kebutuhan yang mungkin muncul juga sangat susah. Perlu experience dan common sense. Begitulah, jadi inget tulisan jeff atwood. Developer sering mengira bahwa membuat software yang ada didepan mata dia itu sebagai hal yang “trivial”, ah sengini doang, gw juag bisa bikin. Padahal kalau dijalani, hm..

Btw, ni tulisan ada unsur curhat ,ada unsur ngeluh, ada unsur ngebelain juga. hahaha

This entry was posted on Thursday, August 6th, 2009 at 11:47 pm and is filed under Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.