Akhirnya berani juga ngirim postingan di thread ini,hehehe….Untuk pembahasan kali ini mungkin saya akan mencoba memberikan pendapat dan pengalaman saya kenapa RG yang kita lakukan didalam sebuah project sering kurang optimal.

Sebelum menginjak ke topik kenapa RG kurang maksimal kita definisikan dulu apa itu RG. RG adalah singkatan dari Requirement Gathering. RG di dalam dunia software engeneering adalah sebuah proses untuk menggali informasi dari berbagai sumber terkait akan sebuah perangkat lunak yang akan dibangun dalam hal ini klien atau user yang akan menggunakan sistem perangkat lunak tersebut. Proses penggalian informasi ini bisa berbagai macam cara seperti wawancara dengan user, analisa dokumen-dokumen yang dibutuhkan user, dan analisa dokumen-dokumen yang berkaitan erat dengan sistem perangkat lunak yang akan dibangun. Proses RG ini didalam sebuah project pembuatan sistem perangkat lunak berlangsung di fase-fase awal project tergantung methodologi proses pembangunan perangkat lunak yang dipakai.

RG yang kurang maksimal akan berakibat kepada sistem perangkat lunak yang kurang mature dan pastinya akan mengakibatkan kemunduran project secara keseluruhan. Kenapa RG yang kita lakukan sering kurang optimal? berikut pendapat saya tentang hal itu :

1. Proses alokasi waktu untuk RG yang terlalu cepat

Hal yang sering terjadi dalam dunia project IT adalah alokasi waktu yang kurang pada saat proses RG. Proses alokasi waktu cenderung lebih diutamakan kepada proses development aplikasi dan implementasi. Menurut saya dari keseluruhan siklus project alokasi untuk RG berkisar sekitar 25%-35%. hal yang terjadi kebanyakan alokasi RG paling sekitar 10%-20% atau malah kurang dari itu.
2. Hanya memperhatikan alur secara global tetapi melupakan detil

Penyakit ini yang sering saya temui dalam berbagai project, sayapun sering sekali miss dalam hal ini😀. Memang kemampuan seorang sistem analis untuk melihat sesuatu tidak hanya dari segi global tapi juga detail membutuhkan pengalaman dan jam terbang yang tinggi. Hal itupun juga tidak bisa saya pungkiri bahwa sayapun sering melupakan hal itu dalam berbagai project yang saya tangani, maklum jam terbang saya masih rendah,hehe… Sebenarnya apa sih yang disebut melihat detil? dan apa pengaruhnya kepada sistem yang kita buat?

Melihat hal detil adalah menganalisa sesuatu sampai level terkecil dari sebuah aplikasi, contoh kecil :

ketika ada sebuah project pembuatan sistem informasi kepegawaian disitu ada sebuah aktor yaitu pegawai. Pertanyaan-pertanyaan yang biasa dilontarkan adalah siapa saja pegawai itu? item-item apa yang menempel dalam pegawai? pegawai bisa melakuakan apa? Tapi sering kali kita lupa menanyakan adalah NIP pegawai berapa digit? isinya angka, huruf, atau bisa dua2nya? alamat pegawai terdiri dari item apa saja?

Efek dari melupakan detil ini adalah desain aplikasi baik dari segi database atau dari segi struktur class(kalau kita pake class/object oriented) akan menjadi kurang efektif.

3. Konsep integrasi antar modul yang sering terlupakan

Dalam pembuatan software apalagi software berskala menengah dan besar tentu tidak luput dari yang namanya integrasi antar modul atau integrasi antar sistem dalam skala yang lebih besar. Seorang sistem analis dituntut untuk bisa menganalisa sebuah sistem beserta integrasinya, sehingga didalam melakukan sebuah RG seorang sistem analis bisa menggali informasi yang lebih dalam kepada user terkait integrasi-integrasi yang ada dalam/antar sistem tersebut.

4. Kurang bisa memancing user untuk mendeskripsikan apa yang mereka butuhkan

Kemampuan berbicara dan menggali informasi menjadi hal yang vital dalam proses RG karena tidak dalam setiap project kita akan menemukan user-user yang paham betul akan kebutuhannya sehingga dalam hal ini peran sistem analislah yang akan menggali kebutuhan user tersebut sekaligus memberikan saran bagaimana sistem yang baik dan bisa diterapkan sesuai dengan kebutuhan yang diinginkannya.

5. Terlalu banyak berasumsi

Penyakit kedua yang sering muncul dalam setiap sistem analis adalah ini😀, terlalu banyak berasumsi!!. Dalam proses RG usahakan minimalisasi asumsi, gali hal-hal real yang terjadi dan dibutuhkan oleh user sehingga sistem yang kita buat tidak jauh melenceng dengan apa yang sebenarnya user inginkan/butuhkan.

6. Proses dokumentasi yang setengah-setengah

Dalam pembangunan sebuah perangkat lunak, dokumentasi memegang peranan sangat penting. Kenapa sangat penting? dengan dokumentasi semua hal yang dibutuhkan dan diinginkan user akan terekam, proses perubahan aplikasi di masa-masa implementasi akan berkurang, proses interaksi antar role pada saat development akan sangat berkurang karena dengan dokumentasi yang lengkap seorang developer sepertyi layaknya tukang jahit yang bahan-bahanya sudah lengkap tinggal menjahit saja. Dan masih banyak lagi keuntungan-keuntungan yang kita dapatkan dengan membuat dokumentasi yang lengkap.

7. Intensitas komunikasi yang kurang

Requirement gathering yang kontinyu akan membuat perangkat lunak yang kita buat menjadi lebih mature dan lebih diterima oleh klien pada saat dilakukan implementasi. Bagaiamana kalau klien kita berbeda daerah atau bahkan berbeda pulau? sekarang dah jamannya teknologi, komunikasi tidak perlu selalu dilakukan dengan tatap muka, komunikasi bisa dilakukan dengan email, telp atau messenger.