MANAJEMEN PROYEK PERANGKAT LUNAK (3) - Mengapa proyek perangkat lunak lebih bermasalah dibanding proyek rekayasa lain?
Assalamualaikum wr wb.
Pada bagian ke-3, saya akan membahas mengenai proyek. Karena materi mengenai dasar proyek & manajemen proyek telah dijelaskan pada bagian ke-2, maka kali ini saya akan membahas lebih lanjut mengenai pertanyaan ke-2 mengenai "Mengapa proyek perangkat lunak lebih bermasalah dibanding proyek rekayasa lain?"
Sumber: freepik.com.
Sebelumnya kita membahas masalah kegagalan perangkat lunak, yang secara langsung menjadi tolak ukur pengembangan nya yang menjadi bermasalah.
Singkatnya. pada artikel proxsisgroup.com, banyak sekali faktor yang menyebabkan suatu perangkat lunak yang telah dibangun dalam proyek dikatakan gagal. Penyebabnya bisa dari ekspektasi dan pemakaian oleh pengguna yang tidak sesuai harapan, dan bisa dari proyek pengembangannya yang kurang baik.
Dari perspektif proyek perangkat lunak, pengembangan yang gagal ini memiliki rasio 50 - 80% dari seluruh proyek perangkat lunak. Artinya, faktor yang menyebabkan proyek perangkat lunak gagal sangat berpengaruh. dalam proxsisgroup.com, faktor tersebut antara lain:
- Implementasi aturan bisnis yang salah
- Kinerja perangkat lunak yang bermasalah
- Vendor yang tidak lagi mendukung
Faktor ini merupakan hal yang menyebabkan proyek perangkat lunak bermasalah dan menghasilkan produk perangkat lunak yang gagal. Faktor ini menurut saya dilihat dari segi bisnis.
Sumber: freepik.com.
Bagaimana jika kita lihat penyebab permasalahan proyek ini dari sumber lain?
Kita bandingkan dengan proyek konstruksi.
Dalam pmhut.com yang membahas perbedaan proyek konstruksi dan perangkat lunak, perbedaan kedua proyek dilihat dari 5 aspek, yaitu:
1. Bentuk : Fisik vs virtual
Konstruksi bersifat fisik, sedangkan perangkat lunak bersifat virtual, sehingga tidak nampak secara real apa yang proyek lakukan.
2. Kebutuhan awal: Bahan baku vs Pengetahuan
Konstruksi membutuhkan sumber daya nyata seperti bahan bangunan dan alat, yang lebih kelihatan jika ada kekurangan dan kesulitan dari awal. Perangkat lunak membutuhkan pengetahuan. Pengetahuan berarti harus fleksibel dalam memahami kebutuhan pengguna, sehingga lebih sulit untuk menilai kekurangan / kesulitan pengembangan awal.
3. Tahap pengembangan: berurutan vs modular
Konstruksi pasti bersifat bertahap waterfall, sedangkan perangkat lunak harus menyesuaikan dengan proyek yang akan dibuat. Ini dapat mempermudah proyek perangkat lunak jika metodologi yang digunakan dalam proyek. Artinya, kemungkinan pilihan cara pengembangan lebih banyak dan kita harus memilih mana yang benar, tidak seperti proyek konstruksi yang pasti waterfall, sehingga setiap proyek konstruksi memliki kesulitan yang mirip antara satu dengan yang lain dan banyak solusi yang dapat dipertimbangkan.
4. Produk yg terlihat : Hasl akhir vs MVP (minimum viable product)
Jika produk awal yang dapat dilihat pada proyek konstruksi adalah model / blueprint, maka pada perangkat lunak, jika menggunakan metodologi prototyping atau RAD, kita bisa menunjukkan MVP terlebih dahulu yang didapat pada putaran awal pengembangan perangkat lunak. Tetapi tidak semua perangkat lunak dibangun dengan metodologi itu. Jika metodologi yang digunakan adalah waterfall, maka sama saja dengan proyek konstruksi, yaitu hanya dapat menampilkan desain mock up dari produk yang akan dikembangkan,
5. Tahap akhir pengembangan: Menggunakan produk vs memperbaiki produk
Pada proyek konstruksi, ketika bangunan telah selesai dan aktivitas manusia dimulai disana, maka proyek konstruksi dapat dikatakan selesai dan beberapa proyek biasanya akan melakukan survey snagging (cacat bangunan post-produksi). Beda halnya dengan proyek perangkat lunak. Ketika produk selesai dibuat, maka produk tersebut baru akan masuk tahap pemakaian dan penerimaan feedback pengguna, serta akan terus di perbaiki hingga memnuhi ekspektasi pengguna. Jadi pengembangan konstruksi harus matang namun sekali jalan, sedangkan prangkat lunak akan selalu diperbaiki terus menerus.
Pada sumber lain (thenewstack.io), dijelaskan bahwa proyek perangkat lunak itu adalah menciptakan produk yang berevolusi dari produk sejenis, tidak seperti konstruksi yang membangun dari awal. Jadi kita jangan mengembangkan teknologi perangkat lunak dari akarnya, namun memodifikasi produk yang sudah ada sebelumnya dengan inovasi baru, sehingga fokus pengembangan awal bukan lagi membuat produk secara teknis dari awal namun fokus pada inovasi dan solusi baru.
Untuk permasalahan ekspektasi pengguna, di sini dijelaskan bahwa pengembangan perangkat lunak yang efektif memberikan perangkat lunak secepat mungkin ke pengguna kemudian memperbaiki secara berkala. Ini berarti versi pertama produk tidak akan langsung memenuhi ekspektasi pengguna.
Sekarang kita balik lagi ke poin dasar. Mengapa proyek perangkat lunak itu susah?
Sumber dari levelup.gitconnected.com mengatakan bahwa bahwa garis besar nya didasari oleh asumsi eksplisit dan implisit. Asumsi implisit lebih berbahaya dari asmusi eksplisit.
Asumsi eksplisit itu seperti:
- perubahan teknologi yang semakin cepat
- banyak framework baru yang diciptakan
- paradigma pemrograman yang cepat berlalu
- semakin besar aplikasi, maka komunikasi tim harus meningkat.
- permintaan fitur yang sering tidak jelas.
Asumsi implisit lebih berkaitan dengan menajemen proyek. Sesuatu yang dibutuhkan user dalam mengembangan perangkat lunak harus lebih diperhatikan daripada sesuatu yang menambah nilai perangkat lunak, Sehingga software dengan penulisan yang bagus, dokumentasi yang lengkap akan berlawanan pada prinsip pengguna yang "tidak membutuhkannya". "user membutuhkannya" atau "apakah user membutuhkannya sekarang" menjadi poin yang lebih diperhatikan, seperti pepatah dari Timūr Gurkānī "It is better to on time with ten features than late with ten thousand".
Dari sini, untuk mengurangi permasalahan perangkat lunak, yang diperhatikan dahulu adalah apakah kebutuhan yag diperlukan user telah dibuat, setelah itu baru kita mempertimbangkan pengkodean yang bebas bug dan lain-lain, karena itu sangat mahal dan memakan waktu.
Semua permasalahan mengenai "proyek" perangkat lunak adalah apa yang mesti diselesaikan oleh Manajemen Proyek. Seperti penelitian oleh Varajão et. al. (2014) yang mengatakan bahwa sebenarnya level kesuksesan perangkat (yang cenderung rendah) itu tidak sendirian, proyek konstruksi juga demikian. Yang penting adalah bagaimana manajemen proyek bekerja di dalamnya, karena Pekerjaan manajemen proyek penuh dengan aktivitas langsung, sehingga banyak ketidakpastian saat mengerjakan proyek.
Sumber:
Komentar
Posting Komentar