Yazılım proje yönetimi - Software project management

IEEE yazılım yaşam döngüsü

Yazılım proje yönetimi yazılım projeleri planlama ve liderlik sanatı ve bilimidir.[1] Bir alt disiplinidir proje Yönetimi içinde yazılım projeler planlanır, uygulanır, izlenir ve kontrol edilir.

Tarih

1970'lerde ve 1980'lerde, bilgisayar şirketleri, donanım üretimi ve devre ile karşılaştırıldığında nispeten düşük yazılım üretim maliyetini çabucak fark ettiğinden, yazılım endüstrisi çok hızlı büyüdü. Yeni geliştirme çabalarını yönetmek için şirketler, belirlenen proje yönetimi yöntemlerini uyguladılar, ancak programları kaymış test çalıştırmaları sırasında, özellikle kullanıcı spesifikasyonları ile teslim edilen yazılım arasındaki gri bölgede karışıklık meydana geldiğinde. Bu sorunların önüne geçebilmek için, yazılım proje yönetimi yöntemleri, kullanıcı gereksinimlerini teslim edilen ürünlerle eşleştirmeye odaklandı, şu anda bilinen bir yöntemle şelale Modeli.

Sektör olgunlaştıkça, yazılım proje yönetimi başarısızlıklarının analizi, aşağıdakilerin en yaygın nedenler olduğunu göstermiştir:[2][3][4]

  1. Yetersiz son kullanıcı katılımı
  2. Müşteriler, geliştiriciler, kullanıcılar ve kullanıcılar arasında zayıf iletişim proje yöneticileri
  3. Gerçekçi olmayan veya açıklanmamış proje hedefleri
  4. Yanlış tahminler ihtiyaç duyulan kaynaklar
  5. Kötü tanımlanmış veya eksik sistem gereksinimleri ve özellikleri
  6. Projenin durumunun kötü raporlanması
  7. Kötü yönetilen riskler
  8. Olgunlaşmamış teknoloji kullanımı
  9. Projenin karmaşıklığını idare edememe
  10. Özensiz geliştirme uygulamaları
  11. Menfaat sahibi siyaset (ör. yönetici desteğinin olmaması veya müşteri ile son kullanıcılar arasında politika)
  12. Ticari baskılar

Yukarıdaki listedeki ilk beş madde, müşterinin ihtiyaçlarını, uygun kaynakların uygun proje hedeflerine ulaşmasını sağlayacak şekilde ifade etmenin zorluklarını göstermektedir. Özel yazılım proje yönetimi araçları yararlıdır ve çoğu zaman gereklidir, ancak yazılım proje yönetimindeki gerçek sanat, doğru yöntemi uygulamak ve ardından yöntemi desteklemek için araçları kullanmaktır. Bir yöntem olmadan araçlar değersizdir. 1960'lardan beri, yazılım üreticileri tarafından kendi kullanımları için çeşitli tescilli yazılım proje yönetimi yöntemleri geliştirilirken, bilgisayar danışmanlık firmaları da müşterileri için benzer yöntemler geliştirmiştir. Bugün yazılım proje yönetimi yöntemleri hala gelişmektedir, ancak mevcut eğilim, şelale modelinden, bir yazılım geliştirme sürecini taklit eden daha döngüsel bir proje teslim modeline yönelmektedir.

Yazılım geliştirme süreci

Bir yazılım geliştirme süreci öncelikle üretim yönü ile ilgilidir. yazılım geliştirme gibi teknik yönün aksine yazılım araçları. Bu süreçler, öncelikle yazılım geliştirme yönetimini desteklemek için mevcuttur ve genellikle işle ilgili endişeleri ele almaya doğru eğilir. Birçok yazılım geliştirme süreci, genel proje yönetimi süreçlerine benzer şekilde çalıştırılabilir. Örnekler:

  • Kişiler arası iletişim ve çatışma yönetimi ve çözümü. Aktif, sık ve dürüst iletişim, proje başarı olasılığını artırmada ve sorunlu projeleri hafifletmede en önemli faktördür. Geliştirme ekibi, son kullanıcının katılımını sağlamalı ve geliştirme sürecinde kullanıcı girdisini teşvik etmelidir. Kullanıcıların dahil edilmemesi, gereksinimlerin yanlış yorumlanmasına, değişen müşteri ihtiyaçlarına duyarsız kalmaya ve müşteri tarafında gerçekçi olmayan beklentilere yol açabilir. Yazılım geliştiriciler, kullanıcılar, proje yöneticileri, müşteriler ve proje sponsorları düzenli ve sık iletişim kurma ihtiyacı duyuyor. Bu tartışmalardan elde edilen bilgiler, proje takımı güçlü yönleri, zayıf yönleri, fırsatları ve tehditleri (SWOT) analiz etmek ve fırsatlardan yararlanmak ve tehditleri en aza indirmek için bu bilgilere göre hareket etmek. Kötü haberler bile iyi olabilir Eğer görece erken bildirilir, çünkü sorunlar çok geç keşfedilmezse hafifletilebilir. Örneğin, kullanıcılar, ekip üyeleri ve diğer paydaşlarla gündelik görüşmeler, genellikle olası sorunları resmi toplantılardan daha erken ortaya çıkarabilir. Tüm iletişimin olması gerekir entelektüel olarak dürüst ve otantik ve düzenli, sık sık yüksek kaliteli eleştiri sakin, saygılı bir şekilde sağlandığı sürece geliştirme çalışması gereklidir, yapıcı, suçlayıcı olmayan, öfkeli olmayan moda. Geliştiriciler ve son kullanıcılar arasında ve proje yöneticileri ile müşteriler arasında sık sık gündelik iletişimler, projenin son kullanıcılar için alakalı, yararlı ve etkili olmasını ve nelerin tamamlanabileceğinin sınırları içinde kalmasını sağlamak için gereklidir. Etkili kişiler arası iletişim ve çatışma yönetimi ve çözümü, yazılım proje yönetiminin anahtarıdır. Hiçbir metodoloji veya süreç iyileştirme stratejisi, iletişimde veya kişilerarası çatışmanın yanlış yönetilmesinde ciddi sorunların üstesinden gelemez. Dahası, bu tür metodolojiler ve süreç iyileştirme stratejileriyle ilişkili sonuçlar, daha iyi iletişim ile geliştirilir. İletişim, ekibin bunu anlayıp anlamadığına odaklanmalıdır. proje tüzüğü ve takımın bu hedefe doğru ilerleyip ilerlemediğini. Son kullanıcılar, yazılım geliştiriciler ve proje yöneticileri sık sık ilköğretime sor basit sorular sorunları belirlemeye yardım et neredeyse felaketlere dönüşmeden önce. Son kullanıcı katılımı, etkili iletişim ve takım çalışması yeterli değillerse, iyi bir sonuç elde etmek için gereklidirler ve yoklukları neredeyse kesinlikle kötü bir sonuca yol açacaktır.[3][4][5]
  • Risk yönetimi ölçme süreci veya Risk değerlendirmesi ve ardından riski yönetmek için stratejiler geliştirmek. Genel olarak, uygulanan stratejiler, riski başka bir tarafa devretmeyi, riski önlemeyi, riskin olumsuz etkisini azaltmayı ve belirli bir riskin sonuçlarının bir kısmını veya tamamını kabul etmeyi içerir. Yazılım proje yönetiminde risk yönetimi, iş durumu aşağıdakileri içeren projeye başlamak için Maliyet fayda analizi yanı sıra, proje başarısızlığı için geri dönüş seçenekleri listesi olarak adlandırılan acil eylem planı.
    • Risk yönetiminin bir alt kümesi Fırsat Yönetimi potansiyel risk sonucunun olumsuz değil, olumlu bir etkiye sahip olması dışında aynı anlama gelir. Teorik olarak aynı şekilde ele alınsa da, biraz olumsuz "risk" terimi yerine "fırsat" terimini kullanmak, bir ekibin herhangi bir verinin olası olumlu sonuçlarına odaklanmasına yardımcı olur. risk kaydı spin-off projeleri, beklenmedik olaylar ve ücretsiz ekstra kaynaklar gibi projelerinde.
  • İhtiyaç Yönetimi tanımlama sürecidir, ortaya çıkarmak, belgelemek, analiz etmek, izleme, gereksinimleri önceliklendirmek ve kararlaştırmak ve ardından değişikliği kontrol etmek ve ilgili paydaşlarla iletişim kurmak. Yeni veya değiştirilmiş bilgisayar sistemi[1] Gereksinim yönetimi, şunları içerir: Gereksinimlerin analizi önemli bir parçasıdır yazılım Mühendisliği süreç; iş analistleri veya Yazılım geliştiricileri bir müşterinin ihtiyaçlarını veya gereksinimlerini belirlemek; bu gereksinimleri belirledikten sonra, bir çözüm tasarlama konumuna gelirler.
  • Yönetimi değiştir değişikliklerin belirlenmesi, belgelenmesi, analiz edilmesi, önceliklendirilmesi ve kabul edilmesi sürecidir. kapsam (proje yönetimi) ve sonra değişiklikleri kontrol etmek ve ilgili paydaşlarla iletişim kurmak. Etki analizini değiştirin yeni veya değiştirilmiş kapsam, şunları içerir: Gereksinimlerin analizi değişim düzeyinde, önemli bir parçasıdır yazılım Mühendisliği süreç; iş analistleri veya Yazılım geliştiricileri bir müşterinin değişen ihtiyaçlarını veya gereksinimlerini belirlemek; bu gereksinimleri belirledikten sonra, bir çözümü yeniden tasarlama veya değiştirme konumunda olurlar. Teorik olarak, her değişiklik bir yazılım projesinin zaman çizelgesini ve bütçesini etkileyebilir ve bu nedenle tanım gereği aşağıdakileri içermelidir: risk-fayda analizi onaydan önce.
  • Yazılım konfigürasyon yönetimi tüm alt ürünler ve değişiklikler dahil olmak üzere, sürmekte olan yazılım ürünü olan kapsamın kendisinin belirlenmesi, belgelenmesi ve bunların ilgili paydaşlara iletilmesi sürecidir. Genel olarak, kullanılan işlemler şunları içerir: sürüm kontrolü, adlandırma kuralı (programlama) ve yazılım arşivleme sözleşmeleri.
  • Sürüm yönetimi yazılım sürümlerinin belirlenmesi, belgelenmesi, önceliklendirilmesi ve üzerinde anlaşmaya varma ve ardından sürüm programını kontrol etme ve ilgili paydaşlarla iletişim kurma sürecidir. Çoğu yazılım projesinin, yazılımın yayınlanabileceği üç yazılım ortamına erişimi vardır; Geliştirme, Test ve Üretim. Dağıtılmış ekiplerin çalışmalarını kullanıcılara yayınlamadan önce entegre etmeleri gereken çok büyük projelerde, test için genellikle daha fazla ortam olacaktır. birim testi, sistem testi veya entegrasyon testi bırakılmadan önce Kullanıcı Kabul Testi (UAT).
    • Dikkat çeken bir sürüm yönetimi alt kümesi, Veri yönetimi zira kullanıcılar yalnızca bildikleri verilere dayanarak test yapabilirler ve "gerçek" veriler yalnızca "üretim" adı verilen yazılım ortamında bulunur. Bu nedenle, programcıların çalışmalarını test etmek için sıklıkla "yapay veriler" veya "veri taslakları" oluşturmaları gerekir. Geleneksel olarak, bir üretim sisteminin eski sürümleri bir zamanlar bu amaç için kullanılıyordu, ancak şirketler yazılım geliştirme için dışarıdan katkıda bulunanlara giderek daha fazla güvendikçe, şirket verileri geliştirme ekiplerine verilemeyebilir. Karmaşık ortamlarda, veri kümeleri oluşturulabilir ve bunlar daha sonra genel yazılım yayınlama çizelgesine çok benzer şekilde bir test sürüm programına göre test ortamları arasında taşınır.
  • Bakım ve güncelleme, Gereksinimlerin ve müşteri ihtiyaçlarının her zaman dahil olduğu süreçtir. Hiç şüphesiz hataları bulacaklar, yeni özellikler isteyebilecekler ve farklı işlevler ve daha fazla güncelleme isteyebilecekler. Dolayısıyla, tüm bu taleplerin müşterinin gereksinimlerini ve memnuniyetini kontrol etmesi ve karşılaması gerekir.

Proje planlama, yürütme, izleme ve kontrol

Amacı proje planlaması projenin kapsamını belirlemek, tahmin ilgili iş ve bir Proje takvimi. Proje planlaması ile başlar Gereksinimler geliştirilecek yazılımı tanımlayan. proje planı daha sonra tanımlamak için geliştirilir görevler bu tamamlanmaya götürecektir. proje yürütme proje planında tanımlanan görevleri tamamlama sürecidir.

Proje izleme ve kontrolünün amacı, ekibi ve yönetimi projenin ilerleyişi hakkında güncel tutmaktır. Proje plandan saparsa, proje yöneticisi sorunu düzeltmek için harekete geçebilir. Proje izleme ve kontrolü, ekipten durum toplamak için durum toplantılarını içerir. Değişiklik yapılması gerektiğinde, kontrolü değiştir ürünleri güncel tutmak için kullanılır.

Konu

Hesaplamada, "sorun" terimi, bir sistemde bir iyileştirme gerçekleştirmeye yönelik bir çalışma birimidir.[kaynak belirtilmeli ] Bir sorun bir hata, istenen bir özellik, görev, eksik olabilir dokümantasyon vb.

Örneğin, OpenOffice.org değiştirilmiş versiyonunu çağırmak için kullanılır Bugzilla IssueZilla. Eylül 2010 itibariyle, sistem Sorun İzleyicisi adını veriyorlar.[güncellenmesi gerekiyor ]

Önem seviyeleri

Sorunlar genellikle şu şekilde kategorize edilir: ciddiyet seviyeleri. Farklı şirketlerin farklı ciddiyet tanımları vardır, ancak en yaygın olanlardan bazıları şunlardır:

Yüksek
Hata veya sorun bir sistemin önemli bir bölümünü etkiler ve normal çalışmayı sürdürmesi için düzeltilmesi gerekir.
Orta
Hata veya sorun, bir sistemin küçük bir bölümünü etkiler, ancak işleyişi üzerinde bazı etkileri vardır. Bu önem seviyesi, bir sistemin merkezi olmayan bir gereksinimi etkilendiğinde atanır.
Düşük / Sabit
Hata veya sorun, bir sistemin küçük bir bölümünü etkiler ve çalışması üzerinde çok az etkiye sahiptir. Bu önem seviyesi, bir sistemin merkezi olmayan (ve daha düşük öneme sahip) bir gereksinimi etkilendiğinde atanır.
Önemsiz (kozmetik, estetik)
Sistem doğru çalışıyor, ancak görünüm beklenen ile uyuşmuyor. Örneğin: yanlış renkler, içerikler arasında çok fazla veya çok az boşluk, yanlış yazı tipi boyutları, yazım hataları vb. Bu, en düşük öneme sahip sorundur.

Birçok yazılım şirketinde,[hangi? ] sorunlar genellikle tarafından araştırılır kalite güvence analistleri Doğruluk için bir sistemi doğruladıklarında ve ardından bunları çözmekten sorumlu geliştiricilere atandıklarında. Aynı zamanda sistem kullanıcıları tarafından da atanabilirler. Kullanıcı Kabul Testi (UAT) evre.

Sorunlar kullanılarak iletilir Sorun veya Kusur İzleme Sistemleri. Diğer bazı durumlarda,[örnek gerekli ] e-postalar veya anlık mesajlaşma programları kullanılmış.

Felsefe

Proje yönetiminin bir alt disiplini olarak, bazıları yazılım geliştirme yönetimini, imalat, bu, yönetim becerilerine sahip, ancak programlama becerisi olmayan biri tarafından gerçekleştirilebilir. John C. Reynolds bu görüşü çürütür ve yazılım geliştirmenin tamamen tasarım iş ve karşılaştırır yönetici kim yapamaz program için yönetici editör bir gazete kim yapamaz yazmak.[6]

Referanslar

  1. ^ a b Stellman, Andrew; Greene, Jennifer (2005). Uygulamalı Yazılım Proje Yönetimi. O'Reilly Media. ISBN  978-0-596-00948-9. Arşivlenen orijinal 2015-02-09 tarihinde.
  2. ^ "Yazılım Neden Başarısız Olur", içinde IEEE Spektrumu
  3. ^ a b Açık Kaynak Yazılım Üretmek: Başarılı Bir Özgür Yazılım Projesi Nasıl Yürütülür (e-kitap, ücretsiz indirilebilir), Karl Fogel
  4. ^ a b Robert Frese ve Vicki Sauter, "Yazılım projesi başarısı için şansınızı artırma," IEEE Mühendislik Yönetimi İncelemesi, Cilt 42, Sayı 4, Dördüncü Çeyrek, Aralık 2014
  5. ^ Philip Greenspun Jessica Livingston'da Kurucular İş Başında (2007), ISBN  1-59059-714-1
  6. ^ John C. Reynolds, Programlama ve programlama dillerinin öğretilmesi üzerine bazı düşünceler, SİGPLAN Bildirimler, Cilt 43, Sayı 11, Kasım 2008, s.108: "Bazıları, yazılım üretiminin programlama yeteneği olmadan yönetilebileceğini savunuyor. Bu inanç, yazılım üretiminin bir üretim biçimi olduğu şeklindeki yanlış görüşten kaynaklanıyor gibi görünüyor. Ama imalat yazılım üretimi benzersiz nesnelerin yapımıdır, yani tüm süreç bir tasarım biçimidir. Bu nedenle bir haber kağıdının üretimine daha yakındır - böylece bir yazılım yöneticisi olamaz program yazamayan bir yönetici editöre benzer. "
Genel

Dış bağlantılar

Proje hatası