YAZILIM PROJE

YÖNETİMİ

Özkan SARI
Haziran 2013

http://www.javafun.net/
http://www.ozkansari.net/
http://bilgisayardunyam.blogspot.com/
Gündem
 Proje Yönetimi Kavramları
 Proje Yönetimi Süreç Adımları
 Work Breakdown Structure
 Kritik Yol
 Gantt Diagramı
 Proje Yönetimi Organizasyonları
 Risk Yönetimi
 Yazılım Proje Standartları
 Yazılım Maliyet Tahmini

2
Proje Yönetimi Kavramları>>>

Yazılım Geliştirme Temel Aktiviteleri

 Proje planlama
 Gereksinim analizi (gereksinim spesifikasyon
raporunun hazırlanması)
 Tasarım (Yazılım mimarisi)
 Gerçekleştirme
 Test

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

3
Proje Yönetimi Kavramları>>>

Yazılım Geliştirme Destek Aktiviteleri

Ana 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.

4
Proje Yönetimi Kavramları>>>

Proje
Proje: 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

5
Proje Yönetimi Kavramları>>>

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 daralabilir
 Kaliteden ödün verilebilir
 Maliyet/Bütçe arttırılabilir
 Zaman uzatılabilir
Bu değişiklikler sponsorun kararına
bağlıdır.

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

6
Proje Yönetimi Kavramları>>>

Proje Yöneticisi
Proje yöneticisi ne yapar?

 Plan yapar (zaman, kapsam, bütçe)

 Takip eder
 Raporlama Yapar : Proje paydaşlarına
(sponsorlar, yöneticiler, proje ekibi)
 Koordinasyon → ekip içi ve dışı iletişim (%90)

7
Proje Yönetimi Kavramları>>>

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ı
8
Proje Yönetimi Kavramları>>>

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

9
Proje Yönetimi Kavramları>>>

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

10
Proje Yönetimi Kavramları>>>

Proje Başarısı (devamı...)

Proje Başarısı ölçümü:
 Süre → İstenen sürede bitirildi mi?
 Kaynak & Bütçe
 Hedef → Gereksinimleri karşılıyor mu?

Proje başarısı bir süre sonra ortaya çıkabilir

 Kullanıcı memnuniyeti
 Hata çıkması oranı

Projenin başarısızlık etmenleri:

 Alan değişikliği yapılması
 Ekip içi uyumsuzluk
 Gerekli alımların zamanında yapılamaması
 Belirlenen teknolojiye uyum sorunu
 Hedeflerden sapma
11
 Proje Yönetimi Kavramları>>>

Toplantılar
Toplantı 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

12
 Proje Yönetimi Kavramları>>>

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

13
Proje Yönetimi Kavramları>>>

Yazılım & Yazılımcılar

Yazı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?

14
 Proje Yönetimi Kavramları>>>

AdamxGün
300 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

15
300 Adam/Günlük İş

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

16
Yeni Eleman ...

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

17
Genel Proje Yönetimi Süreçleri

18
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ı.
19
Proje Yönetimi Süreç Adımları >>

1. Adım : Proje Anlama

Genel 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

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

1. Adım : Proje Anlama (devamı...)

Temel Bilgi Alanları :

Girdi ve Çıktılar

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

2. Adım : Proje Tanımlama

Projenin 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

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

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

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

3. Adım : Proje Planlama

Ne 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
24
Proje Yönetimi Süreç Adımları >>

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ı

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

4. Adım : Proje İzleme

Planlama 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?

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

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ı.
27
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.

28
Work Breakdown Structure
İş Altkırılım Yapısı
Yapılacakları gösterir.

29
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.

30
Work Breakdown Structure
(devamı...)

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

31
Work Breakdown Structure
(devamı...)

32
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

33
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
34
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ı

35
Proje Yönetim Organizasyonları
 Fonksiyonel : PY = Departman Yöneticisi
 Zayıf Matris : Takımın Kendi İçinde Yönetim
 Kuvvetli 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

36
Proje Yönetim Organizasyonları

37
Proje Yönetim Organizasyonları >>

Fonksiyonel Organizasyon
Departmanlara 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.

38
Proje Yönetim Organizasyonları >>

Zayıf Matris Organizasyonu

Proje 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.

39
Proje Yönetim Organizasyonları >>

Kuvvetli Matris Organizasyonu

Proje 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.

40
Proje Yönetim Organizasyonları >>

Proje Bazlı Organizasyon

Proje Yöneticilerinin Yetki ve Sorumluluk alanları oldukça geniştir.
Proje yöneticileri çok fazla idari süreçlere dahil olmak zorunda
kalabilirler.

41
Risk Yönetimi

42
Risk Yönetimi (devamı...)
Şimdi problem olmayıp ileride problem olabilecek
durumlar tespit edilir. (Oluşma ihtimali var)

Adımlar:
 Risk belirleme
 Risk önem tanımı (risk olduğunda etkisi ne
olacak)
 Risk tablosu
 Risk izleme ve kontrol
 Proje risk değerlendirme raporu ve kurumda
veritabanı oluşturulması
43
 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
44
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

45
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

46
CMMI
Yazı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ı hedef
 Hem kurumsal yeterlilik olgunluk, hem de süreçte
yeterlilik var mı?
 Bütün kalite yaklaşımlarında olduğu gibi süreklilik
isteniyor.

47
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.

48
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?)

49
Unified Process Model
Yazılım Geliştirme Süreci framework'ü

 Inception : Başlangıç işlemleri

 Eleboration : Dizayn & modelleme
 Construction : Geliştirme
 Transition : Yazılımın kullanıma hazır hale
gelmesi

50
Unified Process Model (devamı...)

51
Unified Process Model (devamı...)

http://www.wittmannclan.de/ptr/cs/rup_model.jpg 52
Yazılım Maliyet Tahmini
Bitmiş 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ğil
 Dolaylı : Function Point

53
 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
54
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
55
Proje Beratı (Project Charter)
Yazılım Proje Önerisi Dokümanıdır.

 Proje kapsamı/kapsam dışındakiler

 Kapsamı çok genel tutmak bir problemdir. Net
ifadeler konulmalı → Müşteri ile anlaşmazlık
olmaması için

56
http://www.swiftlightsoftware.com/project-charter/project-charter-example-L.gif
57
Proje Kontrolü & İzleme
Proje 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

58
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

59
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 Durum
 Riskler
 Teknik İlerleme
 Temel kilometre taşları (Plana uygunluk & sonuç)

60
Proje Kontrolü Metrikleri
Yönetim Açısından:
 İşlerdeki ilerlemeler
 Bütçelendirilmiş maliyet: Değişimler, sapmalar
 Personel ve ekip dinamiği: personel değişiklikleri

Kalite Açısından :
 Değişim trafiği
 Kı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ü saati
 Hata oranı : Hatalar arasında ortalama zaman, hata
oranı, hata onarımı için geçen süre

61
Proje Kontrolü Metrikleri

* Royce, Chapter 13.1

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

63
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.

64
 Sunum 2: Agile Sistemlerde
Kalite Güvencesi
Agile 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 Sistemi test etmenin ne kadar kolay olduğu
Doğrulama)
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

65
Sunum 3 : Yazılım Projelerinde
Başarısızlık Nedenleri
Bir 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

66
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
67
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.
68
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
69
Tavsiye ...

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

70
Kaynaklar
Sunum 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

71
Teşekkürler …