Saya Berharap Tidak Mengenal Kurva S

Bulan Desember.. bulan tersibuk dalam hidup kawahyu, banyak yang harus dikerjain, banyak uang yang harus dikeluarin, banyak tulisan yang belum sempat di posting. Oke, pekerjaan harus dikerjakan satu-persatu toh. Setidaknya untuk keberlangsungan Blog ini, tercatat bahwa bulan Desember kawahyu pernah posting. Here..

Dalam suatu session surfing, kawahyu mentok di blog sohib lama. Meskipun jarang di update (bahkan tidak pernah diupdate semenjak Juli 2006), sohibku ini menceritakan tentang suatu Kurva disebut kurva S yang perlu diperhatikan dalam rekayasa PL, Begini ceritanya:

Kurva ini bisa mengambarkan aktifitas pengerjaan proyek secara umum. Jika kita lihat huruf S, maka terlihat garis yang landai dari bawah kemudian menukik ke atas secara tajam dan akhirnya landai bahkan diujungnya cenderung turun. Begitu juga aktifitas dalam proyek pembangunan perangkat lunak, dimulai dengan start yang wajar dan normal, kemudian pada periode tertentu proyek berjalan secara cepat. Namun menjelang akhir dari proyek biasanya landai kembali dan cenderung turun aktifitasnya. Banyak faktor yang menyebabkan hal ini terjadi, selain pekerja proyek yang sudah jenuh, juga bisa disebabkan karena requirement yang terus bertambah, bahkan tidak jelas. Oleh karena itu Kurva S bisa dijadikan pelajaran bagi kita sehingga kita harus bisa menjaga proyek berjalan sesuai dengan apa yang direncanakan. Dan jangan lupa pendefinisian ruang lingkup serta requirement dari proyek itu sendiri merupakan hal yang cukup penting.

Memang betul, dalam pembangunan PL kurva tersebut sering banget muncul. Diawali dengan kegiatan yang normal-normal aja dalam pandangan perekayasa. Misalnya analisa masalah, analisa kebutuhan-kebutuhan, dan lainnya yang berhubungan dengan data. Nggak Aneh kalo ada permintaan klien yang pingin tu program cepat selesai. Makanya, sebelum analisis rampung dan terbebas dari error kadang hasilnya sudah diserahkan ke programmer untuk dikerjakan.

Programer ya programer, mengerjakan apa yang dihasilkan dari analisis. Begonya lagi kita mengadopsi paradigma Waterfall, kalo ada error yang tidak terdeteksi pada saat analisis, maka error tersebut akan terbawa sampe ke tahap dibawahnya yaitu implementasi dan coding. Program yang udah setengah masak dikaji oleh klien dan ternyata diketemukan ada error, kurang ini, kurang itu, ini tidak sesuai, itu tidak sesuai, dalam artian ada requirement baru yang harus dikerjakan. Ribet deh pokoknya harus analisis dari awal lagi. Yang Capek siapa?? Yaa programer lah! harus coding dari awal, nambahain ini itu, memperbaiki ini itu, menyelesaikan requirement baru. Pokoknya Programmer jadi obyek penderita, akibat kerja analisis yang tidak maksimal. Kesimpulannya menurut kawahyu adalah analisa dulu harus benar, karena kadang kesalahan justru berasal dari analisis yang tergesa-gesa dan asal beres. kalo udah benar dan gak ada kesalahan baru serahkan ke programer. Mengeni ada requirement baru dari klien itu mah masalah wajar dalam RPL. Kalo ada requirement baru untuk memperbaiki kesalahan analisis itu baru kurang ajar.

Nah sebenarnya kalo kita telaah lagi, sebenarnya selama ini kita tidak pernah melakukan Rekayasa dengan paradigma Waterfall, malah serinya menggunakan paradigma Prototyping. Mengapa demikian? Coba aja dipikirin, mana dulu yang kita kerjakan: Pemodelan atau Program?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: