Ajeng Savitri Puspaningrum, M.Kom. | Dokumentasi
Ajeng Savitri Puspaningrum, M.Kom, Pakar Rekayasa Perangkat Lunak Universitas Teknokrat Indonesia
Anda seorang programmer? Atau seorang manajer proyek perangkat lunak?
Pernahkah Anda diminta untuk memperbaiki atau menambahkan modul baru pada perangkat lunak lama yang dibuat oleh programmer lain?
Bagaimana Anda memahami suatu perangkat lunak yang dikembangkan orang lain dan mencoba untuk memperbaiki atau meningkatkan fungsinya? Tentu sulit.
Kegagalan Proyek Perangkat Lunak
Sebanyak 40%-60% kesalahan dalam suatu proyek pengembangan perangkat lunak yang mungkin muncul pada tahapan berikutnya berawal dari kesalahan yang dilakukan pada tahap spesifikasi kebutuhan.
Kegagalan proyek menjadi dampak kesalahan yang terjadi selama proses pengembangan perangkat lunak. Tidak sedikit dana dan waktu serta tenaga yang terbuang sia–sia bila terjadi kegagalan pada proyek pengembangan perangkat lunak.
Peningkatan kualitas dokumentasi spesifikasi kebutuhan perangkat lunak mampu mengurangi dampak tersebut. Dokumen spesifikasi kebutuhan perangkat lunak atau Software Requirements Specification (SRS) sendiri merupakan sebuah dokumen yang berisi pernyataan lengkap dari apa yang dapat dilakukan oleh perangkat lunak tanpa menjelaskan bagaimana hal tersebut dikerjakan oleh perangkat lunak.
Dari spesifikasi kebutuhan yang tidak benar tentunya akan memengaruhi dalam proses analisis dan desain. Kebutuhan spesifikasi yang salah akan berakibat pada hasil program yang tidak sempurna.
Lalu bagaimana meningkatkan kualitas dokumentasi spesifikasi kebutuhan perangkat lunak?
Memahami Kebutuhan Perangkat Lunak
Untuk mendapatkan perangkat lunak yang minim kesalahan, pengembang perangkat lunak perlu mengidentifikasi stakeholder, mendapatkan pemahaman pelanggan dan pengguna untuk perencanaan sistem serta kebutuhannya terhadap sistem, identifikasi kebutuhan, klarifikasi dan mengulangi kebutuhan, analisis kebutuhan, mendefinisikan kebutuhan dengan cara pemahaman yang sama terhadap semua stakeholder.
Tiap analisis merupakan tahapan pengumpulan kebutuhan-kebutuhan dari semua elemen perangkat lunak yang akan dibangun.
Dari kegiatan tersebut terbentuklah spesifikasi kebutuhan perangkat lunak, fungsi perangkat lunak yang dibutuhkan, performansi sistem perangkat lunak, penjadwalan proyek, identifikasi sumber daya dan taksiran biaya pengembangan perangkat lunak.
Namun dalam prosesnya, pengumpulan kebutuhan sering kali mengalami kendala atau permasalahan. Permasalahan yang mungkin dihadapi ketika mengumpulkan kebutuhan perangkat lunak antara lain adalah:
Stakeholder bingung tentang yang dimaksud dengan “Kebutuhan”.
Kurangnya keterlibatan pelanggan
Kebutuhan yang kabur atau ambigu akibat penggunaan bahasa alamiah dalam menjelaskan kebutuhan
Tidak ada prioritas karena menganggap semua kebutuhannya penting
Membangun fungsionalitas yang tidak digunakan siapa pun akibat pengguna tidak bisa membedakan antara kebutuhan dan keinginan
Perancang dan programmer tidak mau bekerja berdasarkan spesifikasi yang belum lengkap
Pelanggan sering tidak tahu apa yang dia inginkan sehingga memungkinkan adanya kebutuhan yang terus-menerus berubah
Usulan permintaan kebutuhan terkadang disampaikan oleh pengguna secara informal kepada programmer sehingga terjadi perubahan yang tidak didokumentasikan
Pentingnya Dokumentasi
Dengan permasalahan-permasalahan yang dihadapi selama pengumpulan kebutuhan, dokumentasi itu menjadi penting.
Setidaknya sangat penting ketika anda menjadi seseorang yang akan mengembangkan suatu perangkat lunak yang telah digunakan.
Entah karena kebutuhan pengguna atau perkembangan teknologi, sangat mungkin sebuah perangkat lunak membutuhkan penambahan atau penambalan modul di sana dan di sini.
Dokumentasi juga menjadi solusi untuk setiap perubahan yang telah disepakati dan dikomunikasikan ke semua pihak yang berkepentingan sehingga perkiraan biaya, risiko teknis, dan lain-lain menjadi lebih terukur untuk mengurangi kemungkinan kegagalan proyek perangkat lunak.
Beberapa software engineers mungkin berpendapat bahwa “my code is self-documenting” atau dapat dijelaskan sebagai source code sudah merupakan dokumentasinya, sehingga tidak diperlukan dokumen tambahan.
Hal ini mungkin berlaku jika perangkat lunak tersebut dibuat untuk dirinya sendiri. Tetapi bagaimana jika program tersebut digunakan oleh orang lain atau program tersebut sebagai bagian dari sebuah sistem perangkat lunak yang dikerjakan oleh banyak orang?
Tanpa dokumentasi yang baik, Anda sebagai penerus pengembangan perangkat lunak tersebut akan meraba dan menerka sintaks-sintaks serta kebutuhan pengguna yang telah lalu.
Bisa saja kebutuhan pengguna yang lalu ternyata sangat berbeda dari sekarang. Bisa juga ada maksud-maksud penggunaan fungsi tertentu yang ternyata tidak disadari pentingnya oleh tim pengembang lanjutan.
Yang lebih penting lagi adalah dokumentasi dapat menjadi alat pertanggungjawaban, baik secara hukum maupun keilmuan atas karya perangkat lunak yang dikembangkan.
Pengembang dan pelanggan harus menempatkan dokumen spesifikasi kebutuhan perangkat lunak sebagai suatu kontrak kesepakatan antara kedua belah pihak.
Sehingga, jika pemilik proyek menuntut Anda mengapa ada fitur yang tidak dikembangkan, kita cukup tunjukkan project charter pada bagian cakupan proyek. Selesai. Dan Anda tidak akan dituntut atas permasalahan tersebut.
Jadi, jika Anda seorang programmer atau bagian dari tim pengembang suatu perangkat lunak, dokumentasikan kebutuhan perangkat lunak tersebut untuk memudahkan pengembangan di masa yang akan datang. []
