Dalam pengembangan suatu software, waktu merupakan salah satu faktor yang krusial. Sering sekali pengembang software dalam membuat suatu software memerlukan waktu yang lebih lama dibandingkan dengan rencana pembuatan. Faktor yang menyebabkan pengembangan software ini membengkak merupakan hal yang sangat menarik untuk di kaji terutama oleh kalangan pengembang software. Dengan memperpendek waktu pengembangan berarti time-to-market akan lebih cepat dan efeknya adalah keadaan keuangan perusahaan akan lebih baik.
Sehingga sekarang pertanyaannya adalah bagaimana cara membuat suatu software yang tepat waktu ? Agar tepat waktu bagaimana dengan estimasi waktu pembuatan software apakah sudah menggunakan cara yang benar, kalau tidak berarti estimasinya sendiri juga salah, sehingga kalau dituntut agar pembuatan software tepat waktu juga sulit.
Faktor yang lainnya adalah dokumentasi kebutuhan pemakai, sering terjadi pada saat software sudah diserahkan, masih memerlukan banyak perubahan. Sehingga sering pengembang melakukan kerja ulang (Rework). Sering sekali pengembang tidak mengikuti SDLC (System Development Life Cycle) yang sesuai dengan project yang dikerjakan. Pemilihan SDLC yang tepat merupakan salah satu cara untuk dapat menyelesaikan proyek tepat waktu. Dibawah ini adalah hasil survey yang disajikan oleh Steve McConnel dalam bukunya Code Complete. Dari tabel tersebut dibawah ini jelaslah bahwa di proyek yang kecil waktu yang paling banyak digunakan adalah coding, sedangkan pada proyek yang besar, waktu yang paling banyak digunakan adalah desain.
Dapat disimpulkan agar kita dapat mengembangkan software dengan sesuai jadwal yang baik, pertama cara pembuatan schedule yang tepat sehingga schedule tidak dibuat dengan estimasi yang sebarang. Kedua kita harus dapat menentukan SDLC yang tepat, yang dilihat dari berbagai sudut, seperti apakah usernya mengetahui kebutuhannya, apakah ada dateline yang ketat. Ketiga kita harus perhatikan tim pengembang yang ada, seperti apakah kita dapat mengetahui progress pengembangan, sering kali progress pengembangan tidak diketahui oleh kepala tim pengembang. Kalau hal ini terjadi kepala tim tidak dapat memperbaiki hal hal yang rawan ditengah proyek itu berlangsung, setelah proyek selesai baru akan diketahui atau setelah dateline, baru muncul persoalan-persoalannya.
Pada edisi bulan depan akan dilanjutkan dengan bagaimana kita dapat membuat estimasi jadual pembuatan program, metoda apa yang harus digunakan agar proyek yang dikerjakan dapat tepat waktu.
Membuat estimasi jadual proyek Ada beberapa cara untuk membuat estimasi suatu pengembangan software, dengan menggunakan function point, dengan menggunakan jumlah baris dalam program, atau dibandingkan dengan proyek yang sejenis yang pernah dibuat sebelumnya.
Cara function point, setelah desain selesai, kita tentukan berapa banyak function point yang ada untuk input, output, inquiry kemudian function point tersebut dikelompokan lagi menjadi mudah, sedang dan komplek. Dari hasil perhitungan statistik Jones dalam bukunya Applied Software Measurement membuat suatu tabel seperti berikut dibawah ini :
Setelah semua function point dihitung jumlahnya dan dimasukan kedalam tabel diatas, lalu dikalikan dengan faktor tersebut, hasil perkaliannya dijumlahkan semuanya maka akan mendapatkan angka total function point. Angka total tersebut dikalikan dengan influence multiplier antara 0,65 – 1,35. Function point multiplier ini ditentukan berdasarkan faktor faktor yang mempengaruhi dalam pengembangan software tersebut seperti data communication, penggunaan technologi baru, tim yang relatif masih belum pengalaman dalam mengerjakan proyek yang akan dikerjakan.
Hasil perkalian antara total function point dengan influence multiplier akan mendapatkan nilai function point. Agar didapat jumlah hari, maka kita gunakan data data yang ada selama mengerjakan proyek berapa lama rata-rata untuk mengerjakan 100 function point.
Pemilihan SDLC yang tepat Sering sekali kita menjumpai perusahaan memanggil pengembang software untuk membuatkan suatu aplikasi, dan kebutuhan yang diinginkan tidak dapat dijelaskan dengan baik. Karena mungkin maunya banyak atau mungkin tidak tahu persis sistem yang dikehendaki, tahunya adalah ingin komputerisasi sehingga memudahkan pekerjaannya.
Bila kebutuhan user sulit ditangkap maka sebaiknya digunakan evolutionary prototyping, atau anjurkan saja menggunakan paket software yang sudah ada. Karena dengan menggunakan paket software yang ada paling tidak mereka akan dapat mempelajari, dan bila cocok dapat menggunakan paket software yang sudah jadi.
Dengan evolutionary prototyping pihak pengembang akan banyak pekerjaan diawal karena pada saat selesai survey kebutuhan, dibuatlah protype software yang akan dibuat, kemudian dari prototype tersebut dikembangkan disesuaikan dengan kebutuhan user. Setelah sesuai dengan kebutuhannya barulah dikerjakan programmnya. Cara ini akan menghemat banyak waktu di dalam coding, karena bila coding sudah selesai, sedikit perubahan yang dilakukan akan berakibat pada modul-modul yang lainnya. Sehingga akan memakan banyak waktu untuk mengerjakan ulang.
Bila dateline menjadi suatu hal yang sangat penting, maka SDLC design-to-schedule lebih tepat. Dalam menggunakan SDLC ini, salah satu syaratnya adalah kebutuhan user harus jelas benar. Kemudian ditentukan mana fungsi-fungsi yang harus dikerjakan terlebih dahulu, kemudian fungsi tersebut diurutkan berdasarkan prioritas. Sehingga bila pada saat dateline sudah tercapai maka fungsi-fungsi yang paling penting sudah diselesaikan, hanya fungsi-fungsi tambahan yang belum diselesaikan.
Dan masih banyak lagi SDLC dan bahkan kita dapat mengembangkan sendiri SDLC yang sesuai dengan pengembangan yang ditempat kita masing-masing.
Faktor-faktor penghambat lainnya Sering sekali kita ditawarkan oleh tool pengembangan software yang dapat mempercepat waktu pengembangan, tetapi kita lupa bahwa dalam menggunakan tool baru, tim pengembang harus mempelajarinya terlebih dahulu. Pergantian tool baru ditengah proyek akan menghambat jadual pembuatan software.
Developer Gold Platting, programmer banyak menghabiskan waktunya untuk memperbaiki hal-hal yang berkaitan dengan tampilan program, padahal proses dari program itu sendiri belum selesai dikerjakan. Masalah yang sering terjadi juga adalah feature creep, yaitu feature suatu software yang sedang dalam pengembangan bertambah terus, hal ini terjadi biasanya kalau perusahaan yang mempunyai tim pengembang sendiri, sehingga kita sering mendengar perusahaan yang mempunyai tim pengembang waktu pembuatan relatif lebih lama dibanding dengan di buat oleh pengembang luar.
Kadang-kadang pihak manajemen pengembangan software merasa bila proyeknya ingin cepat perlu ditambah orang, pada saat proyek sudah berjalan. Penambahan anggota tim di tengah berlangsungnya suatu proyek dapat menjadi faktor penghambat juga, karena anggota baru tersebut harus dapat menyesuaikan diri pada tim, disamping pengetahuan anggota baru tersebut terhadap proyek yang sedang dikerjakan.
Kesimpulan Manajemen pengembangan software cukup menarik untuk dikaji, hal diatas masih mencakup seputar cara pengembangan software. Padahal didalam pengembangan software kita juga tidak lepas dari fungsi Quality Assurance. Walaupun sudah mengikuti beberapa cara diatas, tetapi kalau tidak ditunjang dengan QA yang baik, waktu pengerjaan juga akan menjadi lama, yang mengakibatkan time delivery juga menjadi lambat.
Didalam pengembangan software ini ukuran sangatlah penting diperhatikan, dikatakan bahwa “what can be measured can be improved”, sehingga apabila kita ingin memperbaiki cara kita membangun suatu software haruslah kita ketahui ukuran-ukuran apa yang harus diterapkan. Salah mengambil pengukuran akan menjadikan arah pengembangan yang salah pula. Sebagai contoh bila didalam menentukan kualitas adalah jumlah bug yang ditemukan didalam program, jelas ini merupakan suatu ukuran yang tidak tepat. Jadi harus dapat mencari ukuran lain dalam kita menentukan qualitas suatu program.
