Yazılım Projesi Başarısızlığının Nedenleri - Maxi Daily Good Pin Blog Yazılım Projesi Başarısızlığının Nedenleri - Maxi Daily Good Pin Blog
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
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. 
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
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
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 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
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 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
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.
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.
Tahmin aracı, tüm parametreleri analiz etme ve maliyet için doğru bir tahmin yapma yetisine sahip olmalıdır.
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.
Evrensel risk Projesine göre, riskin sembolü olabilecek iki tür koşul vardır.
“EĞER teknoloji mevcut değilse, gereksinimi karşılamayacağız”
Yetkili yazılım mühendislerini işe alamazsak, planlanan geliştirme programını yerine getiremiyoruz.
“Koşul” göz önüne alındığında, “sonuç” ortaya çıkma olasılığı vardır
“Bu özel testin başarısız olduğu (DURUM) göz önüne alındığında, CONSEQUENCE, planlanan programın kayacağı”
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
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 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.
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.
İ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.
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)