Penyebab Kegagalan Proyek Perangkat Lunak

June 29, 2017 10 mins to read
Share

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.