Sebagian besar proyek perangkat lunak gagal total atau kegagalan parsial karena sejumlah kecil proyek memenuhi semua persyaratan mereka. Persyaratan ini bisa menjadi tujuan biaya, jadwal, kualitas, atau persyaratan. Menurut banyak penelitian, tingkat kegagalan proyek perangkat lunak adalah antara 50% – 80%. Esai ini merupakan kompilasi penyebab kegagalan proyek pengembangan perangkat lunak; Esai ini merangkum beberapa bidang yang memainkan peran penting dalam kegagalan proyek perangkat lunak.
Jadi, apa sebenarnya alasan kegagalan proyek perangkat lunak? Fakta menyedihkan adalah bahwa proyek perangkat lunak gagal karena kita tidak menyadari bahwa prinsip rekayasa yang baik harus diterapkan pada proyek perangkat lunak seperti halnya membangun gedung perkantoran. Kami mencoba membela diri dengan mengatakan bahwa konstruksi perangkat lunak "berbeda".
Salah satu keluhan paling serius terhadap kegagalan perangkat lunak adalah ketidakmampuannya
untuk memperkirakan dengan akurasi yang dapat diterima biaya, sumber daya, dan jadwal yang diperlukan
untuk proyek perangkat lunak. Metode penilaian konvensional selalu diproduksi
hasil positif yang berkontribusi terhadap biaya yang terlalu terkenal dan
jadwal selip.
Selama 20 tahun terakhir banyak teknik penjadwalan biaya dan jadwal telah dilakukan.
digunakan dengan sensasi campuran karena pembatasan model penilaian. Utama
bagian dari estimasi kegagalan dapat disebabkan oleh kurangnya pemahaman tentang
proses pengembangan perangkat lunak dan efek dari metode yang digunakan dalam proyek
rencana, perkiraan jadwal dan biaya.
Studi Kasus Gagal
Berikut adalah beberapa studi kasus yang dipertimbangkan yang akan dianalisis untuk diambil
alasan utama kegagalan sistem perangkat lunak.
Universitas Northumbria mengembangkan perangkat lunak akuntansi untuk mengelola hari ke hari
bisnis. Proyek tidak bisa menghasilkan hasil yang diinginkan dan gagal
memenuhi tenggat waktu. Investigasi menunjukkan bahwa manajemen proyek dasar
prosedur tidak diikuti. Studi kasus ini dirujuk dalam esai ini di
poin yang berbeda jika diperlukan [1]
Anak perusahaan Thailand (SMTL) dari perusahaan multinasional berbasis di Hong Kong (SMHK)
bergerak di bidang pembuatan peralatan elektronik. Mereka menerapkan sebuah
paket perangkat lunak terpadu; Yang merupakan kegagalan pada beberapa faktor. Ini
Faktor
sebagian besar terkait dengan manajemen. Seperti kurang fit antara bisnis
asumsi proses tertulis dalam perangkat lunak dan proses bisnis di SMTL,
kepemimpinan yang buruk pada tingkat yang berbeda, perbedaan budaya, organisasi
lingkungan, dan pengelolaan sumber daya manusia yang buruk
Rumah Sakit St John adalah Rumah Sakit Umum Distrik yang menyediakan perawatan medis dan
layanan keperawatan, yang mencakup operasi umum dan obat-obatan. Semua ini
layanan didukung oleh pencitraan diagnostik, laboratorium, ambulans, apotek
dan layanan terapi, yang semuanya ada di lokasi. Sebagai rumah sakit besar di turis
daerah, ini berhubungan dengan banyak pengunjung di musim liburan, menghasilkan yang besar
jumlah pekerjaan penerimaan yang tidak dipesan
Manajemen & Kepemimpinan Perangkat Lunak
Telah ditunjukkan berulang kali, bahwa kepemimpinan yang efektif sangat penting untuk implementasi TI yang berhasil (Klenke, 1994). Seorang pemimpin juga harus memiliki kepekaan budaya, kemampuan berkomunikasi, kreativitas, kemampuan untuk mendelegasikan, dan kemampuan untuk mengembangkan dan mempertahankan sumber daya manusia (Luthans, 1994). Manajer perangkat lunak di (SMHK) adalah orang barat, di mana sebagai manajer yang lebih rendah adalah orang Timur. Jadi terjadi benturan budaya yang selalu terjadi. Jack (Manager) selalu mencoba mengenalkan pemikiran kreatif. Dan sebagian besar waktu manajemen yang lebih rendah tidak bisa melakukannya. Oleh karena itu ada benturan yang terjadi sepanjang waktu. [1945992]
Karyawan juga merasa bahwa manajemen hampir tidak pernah "mendengarkan" keprihatinan mereka.
atau berusaha untuk mengatasinya. Akibatnya, banyak karyawan sangat ingin pergi
perusahaan, dan melakukannya segera setelah mereka menemukan peluang alternatif lain
perusahaan.
Perencanaan Proyek & Penjadwalan
Perencanaan proyek berarti menciptakan rincian pekerjaan, dan kemudian mengalokasikan tanggung jawab kepada pengembang dari waktu ke waktu. Perencanaan proyek terdiri dari konstruksi berbagai tugas, garis waktu dan jalur penting termasuk grafik Gantt dan grafik PERT dan rencana tertulis yang berbeda untuk berbagai situasi. [19459]
Hal ini cukup biasa dalam proses pengembangan perangkat lunak untuk bekerja mundur dari
tanggal akhir proyek yang menghasilkan kegagalan proyek perangkat lunak yang lengkap. ini
tidak mungkin sebuah proyek dapat diselesaikan secara efisien dari tahap perencanaan
ke tahap implementasi.
Alokasi peran dan tanggung jawab harus didefinisikan secara jelas, dan
menjadi penting saat menyewa kios dari luar. Universitas lebih tinggi
manajemen gagal menerapkan peraturan manajemen proyek dasar yang diletakkan di
kegagalan proyek.
Penjadwalan yang tepat juga diperlukan sebelum dimulainya proyek. Saya t
mencakup penjadwalan waktu, penjadwalan tim. Manajer proyek tidak tahu apa
mereka harus merencanakan dan menjadwalkannya. Mereka hanya memberitahu programmer apa yang harus dilakukan
dan pemrogram dapat menghasilkan solusi yang tepat. [1945992]
Perkembangan dipindahkan ke kantor baru dan kantornya tidak sepenuhnya
dilengkapi dengan infrastruktur yang tepat. Seiring berjalannya waktu juga merupakan faktor besar dalam kesuksesan
atau kegagalan sebuah proyek. Sehingga menunda proses pembangunan dan memberikan kontribusi
menuju kegagalan proyek. Infrastruktur tidak sepenuhnya terjadwal dan
tim manajemen tidak tahu dimana dan bagaimana pengembangan proyeknya
dimulai.
Rahasia utama proyek pengembangan perangkat lunak yang menang adalah mengendalikan
kualitas naik dan menurunkan risikonya. Rencana kontinjensi juga merupakan bagian dari perencanaan. Di
hal-hal yang tidak beres maka rencana ini dapat diikuti untuk menurunkan pengaruh
kegagalan proyek. Sama halnya dengan perangkat lunak akuntansi universitas. Itu
Tim manajemen
tidak memiliki rencana kontinjensi semacam itu dan juga tidak mengevaluasi risikonya
terlibat dalam pengembangan sistem baru. Jadi itu menyebabkan lebih banyak masalah tanpa
sistem cadangan atau rencana cadangan.
Manajemen hanya mencoba mengikuti metodologi seperti SDLC atau RAD, namun tidak mengetahui metodologi mana yang akan digunakan dan pada saat mana harus menerapkan teknik yang tepat.
Estimasi Biaya
Estimasi biaya terutama melibatkan biaya usaha untuk menghasilkan proyek perangkat lunak. Tapi itu tidak terbatas hanya pada usaha saja. Ini juga mencakup biaya perangkat keras dan perangkat lunak, melatih karyawan dan pelanggan, bepergian ke pelanggan, biaya jaringan dan komunikasi. Estimasi biaya harus dilakukan sebagai bagian dari model proses perangkat lunak.
Estimasi biaya perlu dilakukan dengan baik sebelum dimulainya proyek.
pembangunan. Kegagalan penganggaran untuk biaya proyek menghasilkan
bencana yang lengkap Sebagaimana dinyatakan di atas biaya infrastruktur, alat pengembangan
biaya dan biaya perangkat keras juga perlu diestimasi terlebih dahulu.
Hal yang sama terjadi pada pengembangan sistem akuntansi universitas. Mereka
membeli sistem baru dengan baik tanpa perkiraan biaya yang serius dan
sumber pendapatan.
Berikut adalah alasan mengapa estimasi biaya salah dilakukan.
Metodologi estimasi yang tidak tepat
Alasan lain adalah penggunaan metodologi estimasi biaya yang tidak tepat. Tidak satu pun metodologi yang lebih baik dari yang lain. Setiap metodologi memiliki titik kuat dan lemah yang harus dipertimbangkan. Buku Dr. Barry Boehm, Software Engineering Economics mencantumkan tujuh metodologi estimasi. Satu atau lebih dari metodologi ini dapat digunakan untuk memperkirakan biaya proyek
"Saran yang bagus adalah bahwa lebih dari satu metodologi estimasi biaya perangkat lunak
harus digunakan untuk estimasi yang akurat "
Alat estimasi biaya
Ada banyak kekurangan dalam estimasi biaya manual. Teknik ini hampir ketinggalan jaman sekarang. Saat ini estimasi biaya yang berhasil mencakup penggunaan alat estimasi biaya perangkat lunak komersial yang sesuai.
Alat estimasi perangkat lunak yang bagus tidak selalu menjamin perangkat lunak yang dapat diandalkan
perkiraan. Masukan salah dari ukuran perangkat lunak akan menghasilkan perkiraan yang salah.
Perangkat lunak estimasi juga perlu disesuaikan untuk kebutuhan spesifik
organisasi. Penyesuaian ini membutuhkan data dari proyek masa lalu sebagai
masukan untuk alat untuk memperkirakan.
Ada beberapa alasan alat ini dapat mengembalikan perkiraan yang salah. [1945992]
Memilih alat estimasi yang tepat
Pilihan alat estimasi yang tepat diperlukan untuk estimasi yang tepat. Alat ini tidak mampu menangani input dan dengan demikian dapat menghasilkan estimasi yang salah dan karenanya menyebabkan proyek perangkat lunak gagal.
Kemudahan penyesuaian
Seperti yang disebutkan di atas, alat yang dipilih harus disesuaikan sesuai kebutuhan organisasi, sehingga organisasi dapat menyesuaikannya sesuai kebutuhan dan data proyek masa lalu.
Mudah digunakan dan dipelajari
Alat estimasi biaya harus mudah digunakan dan dipelajari. Ini harus mencakup bantuan dan contoh, antarmuka pengguna yang sederhana dan lurus ke depan. Ini harus memerlukan sedikit pelatihan untuk mempelajari sistem dan masukan harus didefinisikan dengan baik.
Estimasi Akurat
Alat estimasi harus memiliki kemampuan untuk menganalisis semua parameter dan menghasilkan estimasi biaya yang akurat.
Manajemen Risiko
Manajemen risiko merupakan faktor penting terhadap kegagalan proyek perangkat lunak jika tidak dikelola secara tepat waktu dan efektif. Karena tidak ada yang bisa diprediksi bahwa apa yang akan terjadi di masa depan jadi kita harus mengambil langkah-langkah yang diperlukan saat ini untuk menghadapi situasi yang tidak pasti di masa depan. Manajemen risiko berarti menghadapi masalah sebelum menjadi krisis. [1945992]
Identifikasi Resiko
Menurut Universal risk Project ada dua jenis kondisi yang bisa menjadi simbol. Sebagai risiko
- IF-THEN Statements
- "JIKA teknologi tidak tersedia, MAKA kita tidak akan memenuhi persyaratan"
- "JIKA kita tidak bisa merekrut insinyur perangkat lunak yang memenuhi syarat, MAKA kita tidak dapat memenuhi jadwal pembangunan yang direncanakan
- CONDITION-CONSEQUENCE Statements
- Mengingat "kondisi", ada kemungkinan bahwa "konsekuensi" akan terjadi
- "Mengingat bahwa tes spesifik ini gagal (KONDISI), KONSEKUENSI adalah jadwal yang direncanakan akan tergelincir"
Manajer proyek harus mengidentifikasi area dimana risiko dan bagaimana caranya
dapat mempengaruhi perkembangan proyek. Risiko bisa bersifat teknis atau
tidak teknis. Manajer proyek perlu menyadari kedua risikonya. Sebagian besar
proyek manajer tidak baik di salah satu sisi. Seorang manajer yang baik
keterampilan pemrograman bisa bagus dalam mengidentifikasi risiko teknis tapi tidak di non
risiko teknis.
Analisis Risiko
Setelah risiko diidentifikasi, ada kebutuhan untuk membuat kategori risiko itu. Analisis risiko adalah proses memeriksa hasil dan kiriman proyek setelah analisis risiko dan menerapkan teknik ini untuk menurunkan risiko. Setelah analisis risiko selesai, rencana analisis risiko yang tepat perlu dilakukan untuk mengatasi situasi yang tidak pasti. Risiko yang diidentifikasi pertama dikategorikan dan membuat hirarki risiko tersebut. Pada titik ini risiko diklasifikasikan sebagai risiko positif atau negatif. [1945992]
Prioritas Risiko
Setelah risiko dianalisis, langkah selanjutnya adalah memprioritaskan risikonya. Pada awalnya fokus pada yang paling memutuskan risiko dulu; Dan les memutuskan nanti. Faktor risiko ini dapat bekerja dari waktu ke waktu sehingga proyek akhir keluar bebas dari risiko. Jadi sebagian besar waktu tim manajemen proyek gagal untuk mengidentifikasi risiko yang diputuskan dan bekerja pada risiko yang kurang ketat. Hal ini sering terjadi dalam bentuk krisis. [194596]
Penghindaran Risiko
Berurusan dengan risiko adalah seni. Beberapa kali manajemen mengambil proyek tanpa mengidentifikasi risiko yang tepat yang terlibat dalam proyek. Jadi, seorang manajer yang berpengalaman akan mengambil proyek tersebut setelah analisis risiko yang tepat dan menghindari risiko yang ada dalam proyek tersebut. [1945992]
Risk control
Mengelola risiko untuk mencapai hasil dan kiriman yang diinginkan dilakukan dengan mengendalikan risiko yang terbaik. Ini adalah proses intuitif murni dan bergantung pada pengalaman tim manajemen proyek, atau risiko yang sudah dikelola dalam proyek-proyek masa lalu yang dilakukan oleh organisasi yang sama. [1945992]
Kesimpulan
Esai ini telah menghadirkan tiga faktor dasar yang dapat menyebabkan proyek pengembangan perangkat lunak gagal. Perencanaan & Penjadwalan, estimasi biaya dan manajemen risiko. Semua faktor ini harus dipertimbangkan pada tingkat manajemen dan kemudian dipindahkan ke manajemen yang lebih rendah. [1945992]
Perencanaan & Penjadwalan dimulai pada awalnya, perencanaan dan penjadwalan yang baik membuat
dasar yang kuat untuk proyek perangkat lunak. Perencanaan proyek terdiri dari
pembangunan berbagai tugas, garis waktu dan jalur penting termasuk Gantt
bagan dan diagram PERT dan rencana tertulis yang berbeda untuk berbagai situasi. Jika
faktor-faktor ini tidak terjadi, perangkat lunak mungkin mengalami masalah
selama pengembangan dan produk akhir akan menjadi kegagalan. [1945992]
Estimasi biaya bergantung pada anggaran proyek, jenis pelanggan dan
ukuran dan usaha untuk dimasukkan ke dalam proyek. Perkiraan biaya dilakukan berkali-kali
selama siklus hidup sebuah proyek. Ini mempengaruhi proyek dengan berbagai cara, salah
estimasi kegagalan total, mempengaruhi kemauan baik organisasi jika
biaya tidak tercakup, pemangku kepentingan terpengaruh dan pemborosan sumber daya. [1945992]
Mengelola risiko adalah pendekatan praktis untuk mengurangi ambiguitas dan
kemungkinan kerugian terkait dengan proyek pengembangan perangkat lunak. Langkah-langkah potensial
dapat dianggap sebagai fokus kesempatan (positive risk) jika konsekuensinya
menguntungkan, atau sebagai ancaman (risiko negatif) jika konsekuensinya
tidak menguntungkan.