Yazılım Proje Yönetimi

Özkan SARIHaziran 2013

http://www.javafun.net/

http://www.ozkansari.net/

http://bilgisayardunyam.blogspot.com/

YAZILIM PROJE YAZILIM PROJE YÖNETİMİYÖNETİMİ

2

GündemProje Yönetimi KavramlarıProje Yönetimi Süreç AdımlarıWork Breakdown StructureKritik YolGantt DiagramıProje Yönetimi OrganizasyonlarıRisk YönetimiYazılım Proje StandartlarıYazılım Maliyet Tahmini

3

Proje Yönetimi Kavramları>>>

Yazılım Geliştirme Temel Aktiviteleri

Proje planlamaGereksinim analizi (gereksinim spesifikasyon

raporunun hazırlanması)Tasarım (Yazılım mimarisi)GerçekleştirmeTest

* Yazılım geliştirme süreç modeline göre sıralama değişebilir

4


Yazılım Geliştirme Destek AktiviteleriAna adımların daha iyi gerçekleşmesi için gerekli adımlardır. (umbrella act.)

Yazılım Kalite Yönetimi Yazılım Konfigürasyon Yönetimi : Yazılım elemanlarının

kimliklendirilmesi, hangi değişiklik ne zaman ve hangi versiyonda yapılmış Yazılım Proje Yönetimi Yazılım Risk Yönetimi : Nerelerde hata yapabiliriz? Alınacak önlemler

nelerdir? Riski belirleyip takip ediyoruz. Risk faktörleri: yazılımı geliştiren personel ve müşteri

Teknik Gözden Geçirme (milestones) : Ara adımlardaki gözden geçirmeler maliyet açısından önemli, sonradan olursa maliyet artıyor.

Yeniden Kullanılabilirlik Yönetimi : Yazılan kütüphanelerin kullanımı gibi konulardır.

Software domain language : Alan yönetimi, aynı alanda geliştirilebilecek diğer programlar Commercial Off The Shelf (COTS) : ready-made and available for sale, e.g. MS Office

Yazılım Ölçümü : Geliştirilen yazılımların büyüklüğünün ölçümü, çalışan kişi sayısı, zaman bilgilerinin kullanılarak yazılım maliyet tahmini yapılmasını sağlar.

5


ProjeProje: Amacı, kapsamı, süresi ve bütçesi olan sürece proje denir.

- Amaç

- Kapsam

- Süre (Başlangıç-Bitiş zamanı)

- Kaynak & Bütçe

Proje tekildir.

Rutin işlerden oluşursa operasyonel olur. (Ör. Düzenli Fatura basımı proje olmaz ama Faturaların Basılması İçin Bir Sistem Geliştirme Proje olabilir.)

Proje Örnekleri: Marmaray, Cebit Fuarının düzenlenmesi vb..

Proje Paydaşları: Sponsor, yöneticiler, proje ekibi


Proje Temel UnsurlarıProje Yönetimi üçgeni → daralıp

genişleyebilir

Örneğin zamanında yetiştirilemeyecek projenin kapsamı küçültülüp, zamanında yetişmesi sağlanabilir.

Kapsam daralabilirKaliteden ödün verilebilirMaliyet/Bütçe arttırılabilirZaman uzatılabilir

Bu değişiklikler sponsorun kararına bağlıdır.

Matbaanın kanunu: Ucuz, hızlı,kaliteli?

6

7


Proje YöneticisiProje yöneticisi ne yapar?

Plan yapar (zaman, kapsam, bütçe)Takip ederRaporlama Yapar : Proje paydaşlarına

(sponsorlar, yöneticiler, proje ekibi) Koordinasyon → ekip içi ve dışı iletişim (%90)

8


Proje Yöneticisi (devamı...)Proje yöneticisinin sahip olması gereken özellikler :

İletişimi kuvvetli, Sabırlı, Analitik, Büyük resmi görebilmeli, Vizyoner, Lider, Ekip yönetimi yapabilen, Kriz yönetimi yapabilen, Çözüm odaklı, Teknik bilgi ve beceri sahibi Motivasyon sağlama becerisi sahibi Gerekli durumlarda üst yönetime karşı durabilmeli Çalışanların arkasında durmalı

9


Proje Yöneticisi (devamı...)Proje yöneticisinin yönetim tarzları :

Yol Gösterici : Çalışanlar tecrübesizse onlara yol gösterir, işin nasıl yapılacağını anlatır

Devredici : Tecrübeli kişilerle çalışırken işi onlara bırakır, sadece yapılması gerekenleri belirtir

Yönlendirici : İşini tam yapmayan, zamanında bitirmeyen, motivasyona ihtiyaç duyan kişilerle çalışırken

Destekleyici : Ekibin eğitime, danışmanlığa vs. ihtiyacı varsa bunu sağlayan

10


Proje BaşarısıBaşarı unsurları: Süre, kaynak, hedef

Proje başarısı tüm takıma bağlıdır → Sadece Proje yöneticisine değil

Proje yöneticilerinin yetkisiz sorumluluğu var → Proje sahibi/sponsoru konumunda değil

Proje başarısı için iletişim önemli → Proje başarısı başka projelere ya da departmanlara bağlı olabilir

Proje bazlı işe alımlarda Proje yöneticisi güçlü konumda; ama varolan kaynaklar kullanıldığında sıkıntılar olabiliyor → Mevcut kaynakları yönetmeli

11


Proje Başarısı (devamı...)Proje Başarısı ölçümü:Süre → İstenen sürede bitirildi mi?Kaynak & BütçeHedef → Gereksinimleri karşılıyor mu?

Proje başarısı bir süre sonra ortaya çıkabilirKullanıcı memnuniyetiHata çıkması oranı

Projenin başarısızlık etmenleri:Alan değişikliği yapılmasıEkip içi uyumsuzlukGerekli alımların zamanında yapılamamasıBelirlenen teknolojiye uyum sorunuHedeflerden sapma

12


ToplantılarToplantı ne zaman gereklidir? 6 kişiden fazla katılmamalı (interaktif limit, fazlası bildiri olur) Basit bir yazışma ile halledilemeyecek şeyler Sadece ilgililer katılmalı

Toplantı nasıl yapılmalıdır? Bir yönetici Toplantının başlangıcını ve bitişini o belirler. Gündem Toplantıdan önce belirlenmiş ve taraflara iletilmiş Toplantıya hazırlıklı gelinir Toplantı gündeminden lazım olduğu belli

olacak çalışmalar önceden yapılır, bilgiler önceden toplanır. Zaman sınırı konulmalı Toplantıya saatinde gelinir, saatinde bitirilir. İyi planlanmalı Son 15 dk’ya en önemli konular kalır Sonuca bağlanmalı Toplantı sonuçları ve notları, toplantı sonrasına

katılanlara ve ilgililere duyrulur.

* http://www.safkan.org/blog/?p=3081** http://www.paulgraham.com/makersschedule.html

13


Toplantılar (devamı...)Toplantı ne zamana konmalı? Katılımcılar kim? Yönetici / Üretici ? Sadece Yöneticiler : Uygun her hangi bir zamanda +Üreticiler : Zaman Önemli

Yüzde Verim = 100 x (Saat cinsinden kesintisiz sürelerin karelerinin toplamı) / 81

Yazılımcının günlük çalışma süresi, yemek saati dahil: 9

Yüzde Verim (kesintisiz) = 100 x (9 x 9) / 81 = %100

Yüzde Verim (14:00-15:00 toplantı) = 100 x (5×5 + 3×3) / 81 = %41.98

Yüzde Verim (17:00-18:00 toplantı) = 100 x (8×8) / 81 = %79.0

* http://www.safkan.org/blog/?p=3081** http://www.paulgraham.com/makersschedule.html

14


Yazılım & YazılımcılarYazılım dediğin nedir ki? Kodlama?

Yazılım mühendisliği ?

Yazılımcının çalışma ortamıYazılım işi konsantrasyon ister Sessizlik gerekli, kişisel alan

ihtiyacıBölünmemiş zaman ihtiyacı -> Toplantı, Telefon, e-posta

Negatif iş

“Bunu ay sonuna istiyorum” mantığı Sebep? Kaynak? Yöntem?

15


AdamxGün300 Adam x Gün’lük İş 1 adam 300 günde işi yapar mı? ??? 5 adam 60 günde işi yapar mı? 9 kadın 1 bebeği 1 ayda yapar mı? İşin hızı sabit mi? -> 1 ayda 25%, kalan 1 ayda 75%

Adam x Gün Hesabı İş miktarı olarak çok anlamlı değil Zaman Tahmini & Maliyet hesabında mantıklı

Zaman Tahmini İşin tahmin edilemeyen kısımları? Kara delikler Yazılımcı performansı? Yazılımcının konsantrasyonu +0.5 yazılım maliyeti

* http://www.teknikodu.com/adam-gun-hangi-adam-hangi-gun/** http://www.safkan.org/blog/?p=3075

16

http://dilbert.com/strips/comic/2007-09-03/

300 Adam/Günlük İş

17

* http://dilbert.com/strips/comic/2010-04-29/

Yeni Eleman ...

18

Genel Proje Yönetimi Süreçleri

19

Proje Yönetimi Süreç Adımları1. Proje Anlama : Genel projenin temelinin anlaşılması.

Nereden çıktı? Kim kullanacak? Neden yapılıyor? Önceliği nedir? Maliyet/Fayda nedir?

2. Proje Tanımlama : Projenin kapsamı, kapsam dışındakileri projenin alanı, proje sonucunda oluşturulacak dokümanlar-çıktılar (kim hazırlayacak, kim kontrol edecek)

3. Proje Planlama : Tüm Plan aktiviteleri

4. Proje İzleme : Proje gidişatının takip edilmesi. Proje plana uygun gidiyor mu? Plan değiştirilmeli mi?

5. Proje Kapatma : Biten projeden hangi dersler alındı? Projenin genel değerlendirmesi (Proje büyüklüğü, çalışanların performansı vb.) yapılması ve buradaki çıkarımların gelecek projelere aktarılması.

20

Proje Yönetimi Süreç Adımları >>

1. Adım : Proje AnlamaGenel projenin temelinin (özgeçmişinin) anlaşılması.

Proje nereden çıktı, geçmişi var mı? Gerekçesi nedir, neden yapılıyor? Projeyi kim kullanacak? Proje katılımcıları/Destek olacak birimler kimler? Önceliği nedir? (Başka projelere göre) Maliyetler neler? (yazılım, donanım, eğitim, işletme,

bakım vs..) Kabaca “Maliyet/Fayda” değerlendirmesi

Teklif → Talep Olgunlaştırma → İptal/Kabul

21


1. Adım : Proje Anlama (devamı...)Temel Bilgi Alanları :

Girdi ve Çıktılar

22


2. Adım : Proje TanımlamaProjenin tanımının tam olarak yapılması, kapsamının

belirlenmesi, her bir adımın ve çıktıların belirtilmesi gerekiyor. (Müşteri ile konuşarak kağıda dökülmeli)

Projenin alanının belirlenmesi : Kapsam-kapsam dışı tanımı. Aksi halde müşterinin tüm taleplerini karşılamak zorunda kalırsınız.

Her bir adımda hangi belgeler teslim edilecek? Kim hazırlayacak? Kim onay verecek?

Proje yöneticisin projenin gidişatı ile ilgili farkındalığı nasıl sağlanacak?

Projenin paydaşları arasındaki dağılım

23


2. Adım : Proje Tanımlama (devamı...)Proje alanı tanımlanarak müşteri/talep eden kontrol altına alınmış olur.

Proje alanı belirlendikten sonra projede değişiklik istenirse?

Değişiklik İstek Formu- Proje Yöneticisi

- Değişikliği İsteyen

- Değişiklik Gerekçesi

- Projeye etkisi (iş planı ve maliyete)

- Çözüm

- Kabul/Ret durumu

24


3. Adım : Proje PlanlamaNe yaparız? Nasıl? Kimle ve Neyle? Ne zaman? Kaça? Riskler nelerdir?

Kabul ve kısıtların belirlenmesi Proje ekip yapısı ve organizasyonun oluşturulması (Kimler çalışacak?) Yazılım geliştirme süreç modelinin belirlenmesi (hangi model kullanılacak) Projenin aktiviteleri (bkz. Yazılım Geliştirme Temel Aktiviteleri) Ayrıntılı aktivitelerin belirlenmesi (Work Breakdown Structure) Aktiviteler arasındaki bağlantıların belirlenmesi (Bir iş bittikten sonra

başkası mı başlayacak, Birinin başlaması için başkası bitmeli mi...) Start-Start, Start-Finish, Finish-Start, Finish-Finish. Başlangıç ve bitiş için araya süre de girebilir.

Kaynak ataması (Aktivetelere çalışanların atanması) Proje süresi ve maliyet Bütçe çıkarılması Kalite planı oluşturulacak Proje risk belirleme → Risk matrisinin Oluşturulması Projenin standarda uygun olarak belgelenmesi

25


3. Adım : Proje Planlama (devamı...) Milestone (Kilometre Taşı)

- İç Kilometre Taşı : Takımın kendi içindeki değerlendirme

- Dış Kilometre Taşı : Müşterilerin teslim edilenler üzerindeki incelemeleri

Proje Planlama Adımı girdi ve çıktıları

26


4. Adım : Proje İzlemePlanlama aşamasındaki maddelerin takibi yapılır

Ekip belirlenen organizasyon içinde çalışıyor mu?İş programı, tahminler ve bütçe yolunda gidiyor

mu?Müşteri beklentileri karşılanıyor mu?Kalite yönetimi yapıldı mı?Düzenli organizasyon işleyişi var mı?Ekip toplantıları, ara kontroller yapılıyor mu?

27


5. Adım : Proje KapatmaÇıkarılan dersler: Bundan sonraki projelere faydası

olması için bu projedeki kazanım ve problemlerin bir iç çıktı olarak kayıt altına alınması

Projedeki kazanımlar, yaşanan problemler belirlenir → sonraki projelerde risk belirlemede kullanılır

Kapanış onayları alınır

Kapanış sonrası bakım sözleşmesi devreye girer

Bakım sözleşmesi ilk safhada yapılmalıydı. Bu aşamaya bırakılmamalı.

28

Yazılım Mühendisliği & Proje Yönetimi

* Dan Brandon’ın kitabından alınmıştır. Scope: iş alanı, Change management: Değişim yönetimi, procurement: eldekilerin değerlendirilmesi.

29

Work Breakdown Structure İş Altkırılım Yapısı

Yapılacakları gösterir.

30

Work Breakdown Structure (devamı...) Seviye 1: Tüm proje 001

Seviye 2: Ana gruplar 100 200 300

Seviye 3: Görevler 110 120 130 310 320 330

Seviye 4: Aktiviteler 121 122 131 321 322 323 331 332

Üstteki yapı Daha alt seviyelere inerse proje kapsamında bir sorun var demektir.

Bu durumda kapsam gözden geçirilmeli, birden fazla proje çıkarılmalı.

WBS yanlızca yapıalcak işleri gösterir. Proje planını göstermez.

31

Work Breakdown Structure (devamı...)

http://www.projectinsight.net/i/project-management-basics/work-breakdown-structure.gif

32

Work Breakdown Structure (devamı...)

33

Kritik Yol Hesabı Hangi işin hangi işe bağlı olduğunu gösterir.

Erken Başlama Zamanı (Üstteki)→ Başlangıçtan bitişe giderek her adımın en erken başlama zamanını bul

Geç Başlama Zamanı (alttaki) → Bitişten başlangıca doğru zamanalrı çıkararak gidilir

Erken Baş. = Geç Başl olanlar Kritik Yolu Gösterir

34

Gantt DiagramıHangi işin ne kadar süreceğini gösterir.

http://upload.wikimedia.org/wikipedia/en/7/73/Pert_example_gantt_chart.gif

35

Organizasyon/Ekip YapısıEkip yönetimi nasıl yapılır?

Demokratik Ekip : Eş yeterlilik ve sorumlukta kişilerden oluşur. Aralarından birini sorumlu seçebilirler.

Şeflik Yapılı Ekip : Herkes şefe ve onun kararlarına bağlı

Hiyerarşik Ekip Yapısı : Fonksiyonel, Matris, Proje Organizasyon Yapıları

36

Proje Yönetim Organizasyonları

Fonksiyonel : PY = Departman YöneticisiZayıf Matris : Takımın Kendi İçinde YönetimKuvvetli Matris : PY Takımından Bir PY

yönetimi Proje Bazlı (Projectionized) : Çalışanlar

projeye bağlı

Proje yönetimi standartları aşağıya doğru artar

Kişisel başarıların etkisi aşağıya doğru azalır

37

Proje Yönetim Organizasyonları

38

Proje Yönetim Organizasyonları >>

Fonksiyonel OrganizasyonDepartmanlara bölünmüş yapıda departman

yöneticinin proje yönetici rolüne bürünmesi

Şirketin prosedürel işlerini yerine getirecek departmanlar tanımlanmıştır. Departmanların yetki ve sorumlulukları belirlidir.

39


Zayıf Matris OrganizasyonuProje koordinasyonu, departman yöneticilerinden alınmış ve

takım üyelerine bırakılmıştır. (Geçici PY)

Proje Yönetimi çok etkin değil.

Proje Yöneticisi ünvanı yok. Proje Asistanı veya Proje Koordinatörü vasıflarıyla projenin gidişatı konusunda üst yönetimi bilgilendiren bir kişi mevcuttur.

40


Kuvvetli Matris OrganizasyonuProje Yöneticileri’nin temel görevi proje yönetmektir.

Proje Yöneticileri ayrı bir takıma bağlıdır

Böylece proje yöneticilerinin diğer birimlerle çalışması esnasında yaşanan kaynak kısıtı sorunu bu şekilde azaltılır.

Özellikle projelerin şirket için hayati önem taşıdığı şirketlerde etkin olarak kullanılır.

41


Proje Bazlı OrganizasyonProje Yöneticilerinin Yetki ve Sorumluluk alanları oldukça geniştir.

Proje yöneticileri çok fazla idari süreçlere dahil olmak zorunda kalabilirler.

42

Risk Yönetimi

43

Risk Yönetimi (devamı...)Şimdi problem olmayıp ileride problem olabilecek

durumlar tespit edilir. (Oluşma ihtimali var)

Adımlar:Risk belirlemeRisk önem tanımı (risk olduğunda etkisi ne

olacak)Risk tablosuRisk izleme ve kontrolProje risk değerlendirme raporu ve kurumda

veritabanı oluşturulması

44

Risk Yönetimi (devamı...)Risk Tablosu Oluşturulur

• Risk tanımı• Risk kategorisi• Risk oluşma olasılığı

belirleme• Risk etki oranı :

Düşük, Orta, Yüksek• Alınacak Önlem• Maliyet

* http://www.docstoc.com/docs/122983556/Risk-Y%EF%BF%BDnetimi

45

Risk Yönetimi (devamı...)Yaygın Yazılım Projesi Riskleri : Ürün büyüklüğü : LOC, FP, Veritabanı, Kullanıcı sayısı vs.. Teknoloji riski (Yeni donanım, yeni ara yüz, yeni tasarım gibi

durumlarda ortaya çıkan riskler) Süreç (Takip nasıl geliştirilecek, var olan bir kontrol var mı? Her

defasında farklı bir yöntem seçiyorsak süreç zorlaşır. Standartlar olmalı. Konfigürasyon yönetimi standardı(belge - tablo)). CASE araçları kullanılıyor mu? Dokumanlar için standartlar.

Müşteri (Daha önce çalışıldı mı, müşteri istekli mi, gözden geçirmede müşteri ile çalışılıyor mu, müşteri yazılımdan ne kadar anlıyor.)

Geliştirme ortamı (Kullandığımız dil, var olan yenilikleri bize sunan bir sistem mi kullanıyoruz. Test için kullandığımız araçlar süreçteki teknoloji kısmıyla girintili.)

Personel (büyüklük, deneyim. Çalışanların sayısı yeterli mi, istenen yetkinlikte mi, ekip uyumlu mu, proje süresince personel bu işe adanmış olarak çalışacak mı? Çalışanlar yeterli eğitimi aldı mı? Takibi)

İşletmecilik Önemi

46

Yazılım Proje Standartları

Sürece Yönelik : Süreç boyunca oluşturulacak dokümantasyonlar; kodlama standartları, proje standartları vs.. IEEE,DoD, ISO

Ürüne Yönelik : Bitmiş ürünün sahip olması gereken özellikler (Ör. Donanım standartları)

Çalışma Modeline Yönelik : CMMI, SPICE

47

CMMIYazılım geliştirme firmalarının uyguladığı süreçlerin

etkinliğinin değerlendirilmesini sağlayan bir sistemdir.

Key Process Area (KPA)

Süreç ve ürün geliştirmeye destek vermektedir. Tekrarların azaltılması hedefHem kurumsal yeterlilik olgunluk, hem de süreçte

yeterlilik var mı?Bütün kalite yaklaşımlarında olduğu gibi süreklilik

isteniyor.

48

CMMI (devamı...)5 Seviye Süreç Alanları Yeterliliği Tanımlar. 1. Düzeyden

Başlayarak Yetkinlik ve olgunluk düzeyi artmaktadır.

1. Initial : başlangıç

2.Managed (temel proje yönetimi adımları uygulanıyor)

3.Defined : Süreç standardizasyonu ve belgelendirme (belli sayıda geçmiş projede uygulanmış)

4.Quantitatively Managed : Niceliksel & Sayısal ölçümler

5.Optimizing : Sürekli süreç iyileştirme. Çözümü iyileştirmeye yönelik düşünmek gerekiyor. Sadece ölçüm yeterli değil.

49

CMMI (devamı...)People CMMI: Çalışanların yetkinliğinin ölçülmesi

Çalışanların hangi yetkinlikte olması gerekiyor. (Yetkinlik değerlendirilmesi).

Varolan çalışanların eğitim planlarının nasıl yapılması gerektiği

Uygun ekip yapılandırılmasının nasıl yapılması gerektiği (kendini yenileyebilme kabiliyeti nedir?)

50

Unified Process ModelYazılım Geliştirme Süreci framework'ü

Inception : Başlangıç işlemleriEleboration : Dizayn & modellemeConstruction : GeliştirmeTransition : Yazılımın kullanıma hazır hale

gelmesi

51

Unified Process Model (devamı...)

52

Unified Process Model (devamı...)

http://www.wittmannclan.de/ptr/cs/rup_model.jpg

53

Yazılım Maliyet TahminiBitmiş projelerden elde edilmiş veri/tecrübelerden

faydalanılabilir

Geçmiş projeler için: Proje büyüklüğü, yazılım büyüklüğü, iş gücü, adam/ay değerleri olmalı

Yazılım Büyüklüğünün belirlenmesi :Doğrudan : LoC, KloC değerleri → güvenilir değilDolaylı : Function Point

54

Yazılım Maliyet Tahmini (devamı...) Her proje için “Function Point” hesabı yapılır

http://groups.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/artan/functionpoints.htm

http://geekswithblogs.net/Prabhats/archive/2007/03/01/107632.aspx

55

Yazılım Maliyet Tahmini (devamı...) CoCoMo (COnstructive COst Modelling)

İş yükü ve süreden proje büyüklüğü çıkarımı yapılır

http://en.wikipedia.org/wiki/COCOMO

56

Proje Beratı (Project Charter)Yazılım Proje Önerisi Dokümanıdır.

Proje kapsamı/kapsam dışındakilerKapsamı çok genel tutmak bir problemdir. Net

ifadeler konulmalı → Müşteri ile anlaşmazlık olmaması için

57http://www.swiftlightsoftware.com/project-charter/project-charter-example-L.gif

58

Proje Kontrolü & İzlemeProje başlangıcı-bitiş arasındaki kontroller sonucu

raporlamalar/bildirimler

Planlama safhasında kontrol noktaları belirlenmeli → ‘Baseline’ belirleme, proje kapsamı belirlendiğinde ve değişiklik olduğunda

Raporlamalar kullanılan yazılım geliştirme modeline göre değişebilir → Waterfall: Bir adımdan diğerine geçerken

Ne sıklıkta rapor verilecek? (Ne zaman?)Değerlendirme Ekibinde Kimler Olacak? (Kime?)Değerlendirme Şekli? (Nasıl?)

Proje Statü Raporu

59

Proje Kontrolü & İzleme (devamı...)Proje planındaki milestone (kilometre taşları)

neticesinde yapılan değerlendirmeler

Major Milestone: Bütün paydaşların bakış açılarıyla şu ana kadar geldiğimiz noktanın değerlendirilmesi

Minor Milestone: Tüm paydaşlar değil daha alt ekiplerin teknik bakış açısıyla değerlendirilmesi.

Durum Değerlendirmeleri

60

Proje Kontrolü & İzleme (devamı...)Periyodik Değerlendirmeler (Periodic Status

Assessment) : Belirli zaman aralıklarında yapılması gereken işlerin değerlendirilmesi. Özellikle destek verilen projelerde görülür. Örneğin: alt yüklenici takibi, 3 aylık geliş raporu, 6 aylık sonuç raporları vs..

Personel YapısıFinansal DurumRisklerTeknik İlerlemeTemel kilometre taşları (Plana uygunluk & sonuç)

61

Proje Kontrolü MetrikleriYönetim Açısından:İşlerdeki ilerlemelerBütçelendirilmiş maliyet: Değişimler, sapmalarPersonel ve ekip dinamiği: personel değişiklikleri

Kalite Açısından :Değişim trafiğiKırılım ve Modülarite : Bir değişiklik talebinin etkisi, yeni

modül/release ihtiyacına neden olup olmayacağıHer bir değişim için Ort. İş gücü saatiHata oranı : Hatalar arasında ortalama zaman, hata

oranı, hata onarımı için geçen süre

62

Proje Kontrolü Metrikleri

* Royce, Chapter 13.1

63

CASE Araçları KullanımıSüreç otomasyonundan faydalanılabilir

64

Sunum 1: Yazılım Proje Yönetiminde Agent KullanımıBaşarısız Yazılım Projeleri → projenin gerçek durumunun

bilinememesi

Software Project Planning Associate (SPPA) : Yazılım sürecinin etkinliği tahmini ve tavsiyeler çoklu ajanlar (multi agents) tarafından dinamik olarak raporlanır.

65

Sunum 2: Agile Sistemlerde Kalite GüvencesiAgile için Kalite Parametreleri

Parameter Description

Correctness (Doğruluk) Tanımlı özelliklere göre sistemin çalışması

Robustness (Sağlamlık) Belirtilmeyen durumlarda uygun performans sunması

Extendibility (Genişleyebilirlik) Yeni özelliklere uyum sağlaması

Reusability (Yeniden Kullanılabilirlik) Farklı uygulamalar için yeniden kullanılması

Compatibility (Uygunluk) Yazılımın diğer bileşenlerle uyumlu çalışması

Efficiency (Etkinlik) Sistem donanım birimlerinin verimli kullanması

Portability (Taşınabilirlik) Farklı donanım ve yazılım ortamlarına kurulabilmesi

Timeliness (Zamanlama) Müşteriye yazılımın zamannda ya da öncesinde teslimi

Integrity (Bütünlük) Yazılımın korunmasının ve erişimin ne kadar iyi olduğu

Verifiability and Validation (Doğrulanabilirlik ve Doğrulama)

Sistemi test etmenin ne kadar kolay olduğu

Ease of Use (Kolay Kullanım) Farklı kullanıcı tiplerinin programı kullanmasının kolaylığı

Maintainability (Bakım) Sistem bakımının ne kadar kolay olduğu

Cost Effectiveness (Maliyet Etkisi) Sistemin verilen bütçe ile gerçekleştirilebilmesi

66

Sunum 3 : Yazılım Projelerinde Başarısızlık NedenleriBir yazılım projesinin başarılı olabilmesi için

- belirlenen kapsam çerçevesinde tüm gereksinimleri karşılamalı

- planlanan bütçeyle, zamanında ve istenen kalitede olmalı

- uzun vadede sorunsuz çalışması gerekmekte

67

Sunum 3 : Yazılım Projelerinde Başarısızlık Nedenleri (devamı...)Başarı faktörleri- Açık gereksinimler ve tanımlamalar- Açık amaçlar ve hedefler- Gerçekçi zaman planı- Etkin proje yönetim becerileri/metot- Üst yönetimin desteği- Kullanıcı/müşteri katılımı- Etkin iletişim ve geribildirim- Gerçekçi bütçe planı- Yetenekli ve yeterli iş gücü- Değişmeyen gereksinimler- Teknolojiyle/metodolojiyle aşinalık- Uygun planlama- Uygun geliştirme süreçleri/metodolojileri- Güncel ilerleme raporu- Etkin izleme ve kontrol- Kaynakların yeterliliği- İyi liderlik- Risk yönetimi

68

Sunum 3 : Yazılım Projelerinde Başarısızlık Nedenleri (devamı...)Başarısızlık nedenleri:

- Belirsiz gereksinimler

- Kullanıcının proje sürecine yeterince katılamaması

- Proje büyüdükçe yönetimin zorlaşması

- Gerçekçi olmayan zaman planı

- Zayıf bütçe planı

- Değişen gereksinimlerin yönetilememesi

- Proje Yöneticisinin bilgi eksikliği

- Başarısız kalite yönetimi

- Kaynak yetersizliği

- Başarısız risk yönetimi

- Zayıf test süreci.

69

Sunum 4 : Koordinasyon ve İletişimÇevik yazılım geliştirmenin avantajları :

- Gereksinimlerin değişiminine kolay adaptasyonu sağlaması

- Müşteri ve geliştirici arasında kapsamlı işbirliğini sağlaması

- Ortaya erken ve sık ürün çıkarması

Global (distributed) yazılım geliştirmenin avantajları:

+ Ucuz, yüksek kalitede, kısa geliştirme süresine sahip yazılımlar

+ Farklı zaman dilimlerinde sürekli çalışma imkanı

+ Çok farklı becerileri kullanabilme

+ Düşük iş gücünden faydalanma

- İletişim ve koordinasyon sorunları (yönetim, müşteri)

- Kontrol/yönetim zorlukları

- Beklentinin çok üstünde maliyetler

- Kültürel farklılıklar

- Çalışan sirkülasyonu

70

* http://dilbert.com/strips/comic/2010-03-08/

Tavsiye ...

71

KaynaklarSunum Hazırlanırken kullanılan kaynaklar :

Yıldız Teknik Üniversitesi, Yazılım Proje Yönetimi ders notları

Walker Royce, “Software Project Management”, Rational Software Corporation kitabı

PMI’a Göre Matris Organizasyonları : http://www.gokremtekir.com/index.php/2009/02/03/pmia-gore-matris-organizasyonlar/

PMI’a Göre Fonksiyonel Organizasyon : http://www.gokremtekir.com/index.php/2009/02/02/pmia-gore-fonksiyonel-organizasyon/

PMI'a Göre Proje Bazlı Organizasyon: http://www.gokremtekir.com/index.php/2009/01/30/pmia-gore-proje-bazli-organizasyon/

Teknikodu.com

Safkan.org/blog

Teşekkürler …

Documents

Yazılım Proje Yönetimi