Sebuah Jawaban Atas “Misteri Proyek Rekayasa Perangkat Luna

Sebuah Jawaban Atas “Misteri Proyek Rekayasa Perangkat Lunak”

Whew, sudah lima bulan saya tidak menulis di blog ini. Harap maklum, saya baru hijrah ke ibukota untuk bekerja di sebuah perusahaan konsultansi TI. Saya harus mengubah kebiasaan dari semi-pengangguran ke pekerja. Dari yang biasanya “everyday is Sunday, every night is Saturday night” menjadi “berangkat pagi, pulang malam”  . Alhasil, saya hanya punya sedikit waktu untuk menulis.

Tapi itu tak mengapa karena saya hijrah ke Jakarta demi menimba pengalaman di bidang konsultansi TI. Terlebih lagi perusahaan saya memberikan pelatihan terlebih dahulu selama satu tahun sebelum benar-benar bekerja. Menimba pengalaman dan pengetahuan dengan terjun langsung ke dunia industri adalah motivasi utama yang membuat saya mau meninggalkan kenyamanan Yogyakarta dan hijrah ke Jakarta.

Untuk dua bulan pertama saya dan teman-teman yang lain mengikuti foundation school di Binus. Materi yang diberikan meliputi softskill (presentation skill, selling skill, negotiation skill, solutioning skill, analytical thinking skill, leadership), hardskill(sistem informasi, enterprise resource planning, decision support system, Project Management Professional, software development lifecycle, basic accounting), business english, dan materi-materi lain dengan tujuan agar pesertanya dapat menjadi konsultan TI yang handal. Pengajarnya ada yang merupakan dosen dari Binus, konsultan dari perusahaan sendiri, bahkan sampai CEO-nya.

Mengapa saya begitu bersemangat ingin menimba pengalaman secara langsung dari dunia industri? Hal ini karena saya merasakan adanya jurang yang cukup besar antara ilmu yang saya dapat dari kuliah dengan prakteknya di dunia industri, khususnya mengenai rekayasa perangkat lunak dan manajemen proyeknya. Saya ketika mahasiswa pernah terlibat dalam beberapa proyek pengembangan perangkat lunak berskala kecil, baik sebagai programmermaupun sebagai koordinator proyeknya. Dari pengalaman tersebut, saya melihat bahwa metodologi rekayasa perangkat lunak yang dipelajari dalam kuliah tidak atau sulit diterapkan dalam prakteknya. Jadi seperti yang dikatakan oleh Romi Satria Wahono, industri perangkat lunak di Indonesia kebanyakan masih menggunakan metodologi “hajar bleh”  .

Oleh karena itu ketika saya lulus saya berkeinginan untuk bekerja di perusahaan pengembang perangkat lunak yang sudah benar-benar menerapkan metodologi rekayasa perangkat lunak. Kebetulan perusahaan tempat saya bekerja telah cukup matang dalam proses pengembangan perangkat lunaknya. Hal tersebut telah dibuktikan dengan perolehan maturity level 3 dalam CMMI.

“Misteri” dalam Proyek Rekayasa Perangkat Lunak

Salah satu hal yang menjadi misteri besar bagi saya dalam proyek rekayasa perangkat lunak adalah: “bagaimana menentukan waktu dan biaya yang diperlukan dalam sebuah proyek?”. Mengapa begitu? Dalam rekayasa perangkat lunak, dengan metodologi waterfall, terdapat sebuah fase yang bernamarequirement analysis. Fase ini bertujuan untuk menggali dan menganalisis seperti apa spesifikasi perangkat lunak yang dibutuhkan oleh pengguna. Hasil yang diharapkan dari fase ini adalah spesifikasi kebutuhan perangkat lunak yang lengkap dan detail. Padahal, pembuatan dan penandatanganan kontrak proyek, yang di dalamnya telah ditentukan waktu dan biaya yang diperlukan, umumnya dilakukan sebelum fase ini. Bagaimana kita bisa menentukan waktu dan biaya yang dibutuhkan untuk membuat suatu perangkat lunak jika spesifikasi kebutuhan lengkapnya belum diketahui secara detail?

Jadi, ibaratnya kita akan pergi ke suatu tempat. Kita belum tahu bagaimana jalur yang perlu ditempuh agar kita sampai dari tempat asal hingga ke tempat tujuan. Kemudian, kita harus menentukan berapa lama waktu dan berapa biaya yang diperlukan agar kita bisa sampai ke tempat tersebut. Bagaimana kita bisa memperkirakan waktu dan biaya yang dibutuhkan jika kita sendiri belum mengetahui bagaimana jalurnya?

Dahulu, ketika kuliah saya sempat menanyakan kepada dosen mata kuliah Rekayasa Perangkat Lunak mengenai apakah tanda tangan kontrak dilakukan sebelum atau setelah requirement analysis. Dosen saya menjawab: “setelahrequirement analysis“. Saya dahulu cuma manggut-manggut mendengar jawaban tersebut. Namun, ketika saya mulai mendapatkan proyek rekayasa perangkat lunak, saya baru mengetahui bahwa bisnis tidak bisa berjalan seperti itu. 

Requirement analysis memerlukan waktu yang cukup lama, belum lagi tingkat kesulitannya. Spesifikasi kebutuhan perangkat lunak yang dihasilkan pun umumnya rentan terhadap perubahan. Tentunya kita harus menghitung biaya yang dikeluarkan untuk menggaji analis. Kalau tanda tangan kontrak dilakukan setelah fase requirement analysis, dan kemudian tidak diperoleh kesepakatan dalam penyusunan kontrak (proyek tidak jadi dibuat, sehingga tidak ada pemasukan dari klien), maka dari mana kita bisa menggaji analis? Belum lagi sifat dunia bisnis yang membutuhkan kepastian dalam masalah waktu dan biaya.

Ketika saya bekerja sebagai programmer di PPTIK UGM, saya mengerjakan proyek-proyek yang telah ditentukan waktu dan biayanya sebelum spesifikasi kebutuhan perangkat lunaknya jelas. Hal ini karena proyek-proyek tersebut merupakan proyek internal dan anggarannya telah ditentukan sejak awal. Masalah timbul ketika saya mendapatkan proyek pribadi dari luar karena saya tidak bisa menentukan waktu dan biaya yang dibutuhkan sebelum mengetahui spesifikasi kebutuhan perangkat lunaknya.

Sebuah Jawaban dari “Misteri” Itu

Ketika jawaban dari dosen saya ternyata tidak sesuai dengan kondisi di dunia industri perangkat lunak yang sesungguhnya, maka saya pun mencari jawabannya langsung dari dunia industri. Dalam foundation school terdapat materi mengenaiPMP dan juga metodologi rekayasa perangkat lunak di perusahaan saya. Yang mengajarkan mengenai PMP adalah kepala divisi Project Management yang telah memperoleh sertifikasi PMP, sedangkan yang mengajarkan metodologi rekayasa perangkat lunak adalah CEO-nya sendiri  . Metodologi yang digunakan adalah kombinasi antara metodologi waterfall, Rapid Application Development, dan Spiral.

Dalam metodologi tersebut, waktu dan biaya yang diperlukan dalam sebuah proyek telah ditentukan dalam kontrak yang telah ditandatangani sebelum proyek secara resmi berjalan. Karena spesifikasi kebutuhan perangkat yang lengkap baru diketahui setelah proyek berjalan (setelah fase analisis), maka akan kacau sekali apabila setelah diketahui spesifikasinya ternyata terlihat bahwa waktu dan biaya yang telah ditentukan dalam kontrak tidak realistis dengan spesifikasi yang ada. Oleh karena itu, penentuan waktu dan biaya proyek harus diperkirakan (istilah kerennya adalah estimasi  ) seakurat mungkin. Bagaimana estimasi yang akurat bisa didapat? Kuncinya adalah pengalaman. Seorang manajer proyek akan melakukan estimasi dengan melihat proyek-proyek yang mirip dan pernah ditangani sebelumnya. Oleh karena itu, perusahaan pengembang perangkat lunak yang baik harus mendokumentasikan proyek-proyek yang telah ditanganinya agar dapat dipelajari untuk menghadapi proyek-proyek di masa depan.

Itulah sebuah jawaban yang saya dapatkan dari perusahaan saya saat ini. Mungkin, di masa yang akan datang, ketika bidang rekayasa perangkat lunak sudah berkembang lagi, akan ada jawaban lain yang lebih tepat. Namun, saat ini saya lebih ingin mencari tahu dengan terjun langsung ke dunia industri. Wish me luck  .

Source : http://blog.seagatesoft.com/2010/07/08/sebuah-jawaban-atas-misteri-proyek-rekayasa-perangkat-lunak/

Posted in: Umum