Menü

Yazılım Projesi Başarısızlığının Nedenleri

Mart 24, 2019 - Ofis yazılımları
Yazılım Projesi Başarısızlığının Nedenleri

Çoğu yazılım projesi tamamen başarısız olur ya da kısmen başarısız olur, çünkü az sayıda proje tüm gereksinimlerini karşılar. Bu gereksinimler, maliyet, zamanlama, kalite veya gereksinim hedefleri olabilir. Birçok çalışmaya göre, yazılım projelerinin başarısızlık oranı% 50 -% 80 arasındadır. Bu makale, yazılım geliştirme projelerinin başarısızlık sebeplerinin bir derlemesidir; Bu makale, yazılım projesinin başarısızlığında hayati bir rol oynayan birkaç alanı özetlemektedir.

Peki, yazılım projesinin başarısız olmasının sebebi gerçekten nedir? İşin üzücü gerçeği, yazılım projelerinin başarısız olması, çünkü iyi mühendislik ilkelerinin, tıpkı ofis binaları inşa etmek için olduğu gibi yazılım projelerine uygulanması gerektiğini de kabul etmiyoruz. Yazılım yapımının “farklı” olduğunu söyleyerek kendimizi savunmaya çalışıyoruz.

Yazılım arızasına karşı en ciddi şikayetlerden biri yetersizliği

Kabul edilebilir bir doğrulukla maliyet, kaynak ve gerekli zamanlamayı tahmin etmek

bir yazılım projesi için. Geleneksel değerlendirme yöntemleri her zaman üretti

İstila edilen çok iyi bilinen maliyete katkıda bulunan olumlu sonuçlar ve

kaymayı zamanla.

Son 20 yılda birçok maliyet ve program tahmin tekniği kullanılmıştır.

değerlendirme modellerinin kısıtlamaları nedeniyle karışık hissi ile kullanılır. Büyük bir

tahminlerin başarısız olmasının bir kısmı,

Yazılım geliştirme süreci ve projede kullanılan bu yöntemin etkisi

plan, zamanlama ve maliyet tahminleri.

Arıza Durum Çalışmaları

Aşağıda, getirilmek üzere analiz edileceği düşünülen örnek olay incelemeleri yer almaktadır.

Yazılım sisteminin başarısızlığının temel nedenleri.

Northumbria Üniversitesi günden güne yönetmek için muhasebe yazılımı geliştirdi

iş. Proje istenen sonuçları bulamadı ve başarısızlıkla sonuçlandı.

son teslim tarihlerini karşılayın. Yapılan araştırmalar temel proje yönetiminin yapıldığını gösterdi

prosedürler izlenmedi. Bu örnek olay incelemesinde bu makalede bahsedilmiştir.

Gerektiğinde farklı noktalar. [1]

Hong Kong merkezli çok uluslu bir şirketin (SMHK) Tayland yan kuruluşu (SMTL)

elektronik cihazların imalatı ile uğraşmaktadır. Bir uyguladılar

entegre yazılım paketi; birkaç faktörde başarısızlık oldu. Bunlar

faktörler çoğunlukla yönetimle ilişkiliydi. İş arasında zayıf bir uyum gibi

SMTL’de yazılıma ve iş süreçlerine yazılan süreç varsayımlarını,

farklı seviyelerde zayıf liderlik, kültürel farklılıklar, örgütsel

çevre ve zayıf insan kaynakları yönetimi.

St John's Hastanesi bir Bölge Genel Hastanesi tıbbi sağlar ve

Hem genel cerrahi hem de tıpı içeren hemşirelik hizmetleri.

hizmetler tanı görüntüleme, laboratuvar, ambulans, eczane tarafından desteklenir

ve hepsi tesiste olan terapi hizmetleri. Turistlerin en büyük hastanesi olarak

Alan, tatil sezonunda birçok ziyaretçi ile ilgilenir, büyük bir

rezerve edilmemiş kabul iş miktarı.

Yazılım Yönetimi ve Liderlik

Başarılı bir şekilde BT uygulaması için etkili liderliğin şart olduğu defalarca gösterilmiştir (Klenke, 1994). Bir lider aynı zamanda kültürel duyarlılığa, iletişim becerilerine, yaratıcılığa, temsilci seçme yetkisine ve insan kaynaklarını geliştirme ve elinde tutma yeteneğine sahip olmalıdır (Luthans, 1994). (SMHK) 'daki yazılım yöneticisi, alt yöneticilerin Doğu olduğu bir batı idi. Böylece her zaman bir kültürel çatışma yaşanıyordu. Jack (Manager) daima yaratıcı düşünceler ortaya çıkarmaya çalışır. Ve çoğu zaman düşük yönetim onları yapamadı. Dolayısıyla her zaman bir çatışma yaşanıyordu.

Çalışanlar ayrıca yönetimin kaygılarını neredeyse hiç “dinlediğini” hissetmedi

veya onları ele almaya çalıştı. Sonuç olarak, birçok çalışan ayrılmak için istekliydi

şirket ve diğerlerinde alternatif fırsatlar buldukları anda bunu yaptılar

şirketler.

Proje Planlama ve Çizelgeleme

Proje planlama, iş dağılımı oluşturmak ve ardından zaman içinde geliştiricilere sorumluluk vermek anlamına gelir. Proje planlama, Gantt çizelgeleri ve PERT çizelgeleri ve çeşitli durumlar için farklı yazılı planlar dahil olmak üzere çeşitli görevlerin, zaman çizelgelerinin ve temel yolların oluşturulmasından oluşur.

Yazılım geliştirme sürecinde geriden çalışmak oldukça olağandır.

Tamamen yazılım proje hatasıyla sonuçlanan proje bitiş tarihi. Bu

Bir projenin planlama aşamasından itibaren verimli bir şekilde tamamlanması imkansızdır

uygulama aşamasına

Rollerin ve sorumlulukların paylaştırılması açıkça tanımlanmalı ve

kabini dışarıdan işe alırken çok önemli hale gelir. Üniversitenin daha yüksek

Yönetim, kendisine uygulanan temel proje yönetimi kurallarını uygulayamadı.

proje hatası.

Proje başlamadan önce uygun zamanlama da gereklidir. O

zaman çizelgelemeyi, takım çizelgelemeyi içerir. Proje yöneticileri ne olduğunu bilmiyor

planlamak ve programlamak zorundalar. Sadece programcıya ne yapmaları gerektiğini söylerler.

ve programcılar uygun bir çözüm bulabilirler.

Geliştirme yeni bir ofise taşındı ve ofis tam değildi

uygun altyapı ile donatılmış. Zaman aynı zamanda başarıda büyük bir faktör olduğu için

veya bir projenin başarısızlığı. Böylece gelişme sürecini geciktirdi ve katkıda bulundu.

proje başarısızlığına doğru. Altyapı tam olarak planlanmadı ve

yönetim ekibi proje geliştirmenin nerede ve nasıl olacağını bilmiyordu

başladı.

Kazanan bir yazılım geliştirme projesinin en büyük sırrı kontrol etmektir.

kaliteyi arttırın ve riski azaltın. Acil durum planı da planlamanın bir parçasıdır. İçinde

işler yanlış gittiğinde, bu durumun etkisini azaltmak için izlenebilir.

projenin başarısızlığı. Aynı üniversitenin muhasebe yazılımı ile aynıydı.

yönetim ekibinin böyle bir acil durum planı yoktu ve riski de değerlendirmediler

Yeni sistemin geliştirilmesine dahil olmuştur. Bu yüzden olmadan daha fazla sorun neden oldu

yedekleme sistemi veya yedekleme planı.

Yönetim sadece SDLC veya RAD gibi metodolojileri izlemeye çalışır, fakat hangi metodu kullanacağını ve hangi zamanda doğru tekniği kullanması gerektiğini bilmez.

Maliyet tahmini

Maliyet tahmini esas olarak yazılım projesini üretme çabasının maliyetini içerir. Ancak bu sadece çaba ile sınırlı değildir. Ayrıca donanım ve yazılım maliyetini, çalışanları ve müşteriyi eğitmeyi, müşteriye seyahat etmeyi, ağ ve iletişim maliyetlerini içerir. Maliyet tahmini, yazılım süreç modelinin bir parçası olarak yapılmalıdır.

Maliyet tahmini, projenin başlamasından önce yapılmalıdır

gelişme. Bütçelemenin proje maliyeti için başarısız olması,

tam bir felaket. Altyapı maliyetinin üzerinde belirtildiği gibi geliştirme araçları

maliyet ve donanım maliyetinin de önce tahmin edilmesi gerekir.

Aynı şey üniversitenin muhasebe sistemi geliştirmesinde de oldu. Onlar

yeni sistemi maliyetin ciddi bir tahminde bulunmadan satın aldı ve

gelir kaynakları.

Aşağıda yanlış maliyet tahmininin yapılmasının sebepleri bulunmaktadır.

Uygunsuz tahmin metodolojisi

Diğer bir neden, uygun olmayan bir maliyet tahmin metodolojisinin kullanılmasıdır. Tek bir metodoloji diğerinden daha iyidir. Her metodolojinin, dikkate alınması gereken kendi güçlü ve zayıf noktaları vardır. Barry Boehm'in Yazılım Mühendisliği Ekonomisi kitabında yedi tahmin metodolojisi listelenmiştir. Bu metodolojilerden biri veya birkaçı bir projenin maliyetini tahmin etmek için kullanılabilir

“İyi bir öneri birden fazla yazılımın maliyet tahmini metodolojisinin olmasıdır

Doğru tahmin için kullanılmalıdır “.

Maliyet tahmini araçları

Manuel maliyet tahmininde birçok sakınca vardır. Bu teknik artık neredeyse modası geçmiş durumda. Günümüzde başarılı maliyet tahmini, uygun ticari yazılım maliyet tahmin aracının kullanımını içermektedir.

İyi yazılım tahmin araçları her zaman güvenilir yazılımları garanti etmez

tahmin etmektedir. Yazılım boyutunun yanlış girilmesi, yanlış tahminde bulunacaktır.

Tahmini yazılımı da belirli bir ihtiyaç için özelleştirilmiş olması gerekir

organizasyon. Bu özelleştirmeler geçmiş projelerden gelen verileri gerektirir.

Tahmini tahmin etmek için araç girişi.

Bu araçların yanlış tahminde bulunmasının birkaç nedeni vardır.

Doğru tahmin aracını seçme

Doğru tahmin için doğru tahmin aracının seçimi gereklidir. Araç girişi ele alma yeteneğine sahip değildir ve bu nedenle yanlış tahmin ile ortaya çıkabilir ve bu nedenle yazılım projesinin başarısız olmasına neden olabilir.

Özelleştirme kolaylığı

Yukarıda bahsedildiği gibi, seçilen araç organizasyonun ihtiyaçlarına göre özelleştirilebilir olmalıdır, böylece organizasyon bunu ihtiyaçlara ve geçmiş proje verilerine göre kişiselleştirebilir.

Kullanımı ve öğrenmesi kolay

Maliyet tahmini aracının kullanımı ve öğrenmesi kolay olmalıdır. Yardım ve örnekler içermeli, basit ve anlaşılır kullanıcı arayüzü. Sistemi öğrenmek için daha az eğitime ihtiyaç duyulmalı ve girdiler iyi tanımlanmalıdır.

Doğru Tahmin

Tahmin aracı, tüm parametreleri analiz etme ve maliyet için doğru bir tahmin yapma yetisine sahip olmalıdır.

Risk yönetimi

Risk yönetimi, zamanında ve etkili bir şekilde yönetilmezse, yazılım projesinin başarısızlığına karşı önemli bir faktördür. Gelecekte ne olacağı konusunda hiçbir şey tahmin edilemeyeceğinden, gelecekte belirsiz bir durum için şu anda gerekli adımları atmamız gerekiyor. Risk yönetimi, kriz haline gelmeden önce endişe ile baş etmek anlamına gelir.

Risk tanımlaması

Evrensel risk Projesine göre, riskin sembolü olabilecek iki tür koşul vardır.

Proje yöneticileri, riskin olabileceği alanları ve bunların risk alanlarını tanımlamalıdır.

Projenin gelişimini etkileyebilir. Risk teknik nitelikte olabilir veya

teknik olmayan Proje yöneticileri her iki riskin de farkında olmalıdır. Çoğu

proje yöneticileri her iki tarafta da iyi değil. İle iyi bir menajer

programlama becerileri teknik riski tanımlamakta iyi olabilir ancak olmayanlarda

teknik risk.

Risk analizi

Risk tanımlandıktan sonra bu riskin kategorilerini yapmaya ihtiyaç vardır. Risk analizi, risk analizinden sonra proje sonuçlarını ve teslim edilebilirleri inceleme ve riski düşürme tekniğini uygulama sürecidir. Risk analizi tamamlandıktan sonra, belirsiz durumlarla başa çıkmak için uygun risk analizi planının yapılması gerekir. Tanımlanan ilk riskler sınıflandırılır ve bu risklerin hiyerarşisini oluşturur. Bu noktada risk, pozitif veya negatif riskler olarak sınıflandırılır.

Risk önceliklendirmesi

Risk analiz edildikten sonra, bir sonraki adım riski önceliklendirmektir. İlk başta ilk olarak en ciddi riske odaklanın; ve sonra les sever. Bu risk faktörleri zaman zaman işe yarayabilir, böylece nihai projenin ortaya çıkması risksizdir. Bu yüzden çoğu zaman proje yönetimi ekibi ciddi riski tanımlayamıyor ve daha az ciddi risk üzerinde çalışıyor. Bu genellikle bir kriz şeklinde sonuçlanır.

Riskten kaçınma

Riskle baş etmek bir sanattır. Bazı zamanlarda yönetim, projede yer alan uygun riski tanımlayarak projeleri çıkarır. Bu nedenle deneyimli bir yönetici uygun risk analizinden sonra projeye katılacak ve projede yer alan risklerden kaçınacaktır.

Risk kontrolü

İstenilen sonuçları ve teslim edilebilirleri elde etmek için riski yönetmek, riski en iyi şekilde kontrol etmek suretiyle yapılır. Bu tamamen sezgisel bir süreçtir ve proje yönetim ekibinin deneyimine veya aynı kurum tarafından yapılan geçmiş projelerde halihazırda yönetilen riske bağlıdır.

Sonuç

Bu makale, yazılım geliştirme projesinin başarısız olmasına neden olabilecek üç temel faktör sunmuştur. Planlama ve Çizelgeleme, maliyet tahmini ve risk yönetimi. Bu faktörlerin tümü yönetim düzeyinde göz önünde bulundurularak alt yönetime aktarılmalıdır.

Planlama ve Çizelgeleme öncelikle gelir, iyi planlama ve çizelgeleme,

yazılım projesi için güçlü bir temel. Proje planlama oluşur

Gantt dahil olmak üzere çeşitli görevlerin, zaman çizelgelerinin ve temel yolların yapımı

grafikler ve PERT çizelgeleri ve çeşitli durumlar için farklı yazılı planlar. Eğer

bu faktörler parçalara alınmaz, daha sonra yazılım sorunla karşılaşabilir

geliştirme sırasında ve nihai ürün başarısız olacaktır.

Maliyet tahmini, projenin bütçesine, müşteri türüne ve

Projeye dahil edilecek büyüklük ve çaba. Maliyet tahminleri birçok kez yapılır

Bir projenin yaşam döngüsü boyunca. Projeyi birçok yönden etkiler, yanlış

Tahmini tamamlama, Kurumun iyi niyetini etkiliyorsa,

maliyetler karşılanmaz, pay sahipleri etkilenir ve kaynakların israfı.

Riski yönetmek, belirsizliği azaltmak için pratik bir yaklaşımdır ve

bir yazılım geliştirme projesiyle ilgili olası kayıp. Potansiyel önlemler

sonuçları neticesinde fırsat odaklı (pozitif risk) olarak kabul edilebilir

olumlu ya da sonuçları neticesinde tehdit odaklı (olumsuz riskli)

elverişsiz.