Proje yönetimi ve kapsam: function point, timeboxing, WBS

Planlama evresinde fizibilite “yapalım” dedikten sonra proje yöneticisi (project manager) devreye girer. Sorusu: “Bu iş ne kadar büyük, kaç kişi, kaç ay?” Bu haftanın sınav kalbi function point hesabıdır: bileşenleri say, ağırlıklandır, karmaşıklıkla düzelt, satır sayısına, efora ve süreye çevir. Yanına kapsam kayması (scope creep), timeboxing ve WBS tanımları gelir.

Altın kurallar:

1. Size, time, cost üçlüsü. Biri değişirse en az biri daha değişir.
2. Function point dört adım: TUFP → APC → AFP → efor ve süre.
3. Ağırlık tablosunu ezberle ya da sınavda verilmişse doğru satırı kullan.
4. Kapsam yazılı değişir. Değişiklik isteği belge ile gelir, etkisi hesaplanır.

Proje yönetimi nedir?

Proje yönetimi (project management), sistemi istenen zamanda, bütçede ve kalitede teslim etmek için planlama, organize etme, izleme ve kontrol etme işidir. Proje yöneticisinin dört ana işi:

1. Proje büyüklüğünü tahmin etmek (size, effort, time).
2. İş planı oluşturmak (work plan: görevler, süreler, bağımlılıklar).
3. Ekip planı yapmak (staffing plan: kaç kişi, hangi rol, raporlama yapısı, motivasyon).
4. Projeyi koordine etmek ve kontrol etmek (CASE araçları, standartlar, belgeleme, risk yönetimi, kapsam yönetimi).

Bu dört iş size, time ve cost arasındaki dengeyle yapılır. Patron “sistemi 3 ayda istiyoruz” derse, proje yöneticisi ya kapsamı daraltmayı ya da bütçeyi büyütmeyi önermek zorundadır.

Tahmin yöntemi 1: endüstri standartları

En basit yöntem: benzer projelerde evrelerin toplam eforun yüzde kaçını aldığına bak. Sık kullanılan bir oran tablosu:

Planlama bitince gerçek planlama eforunu bilirsin, gerisini oranla tahmin edersin. Planlama 3 person-month sürdüyse toplam 3 / 0.15 = 20 person-month: analiz 4, tasarım 7, implementation 6. Hızlı ama kaba bir yöntemdir.

Tahmin yöntemi 2: function point

Function point, sistemin büyüklüğünü kullanıcının gördüğü işlevlerden ölçer, satır sayısından değil. Programlama dilinden bağımsızdır.

Beş bileşen

EI, EO, EQ işlemlerdir; ILF ve EIF dosyalardır (veri grupları).

TUZAK · EO ile EQ. İkisi de veriyi kullanıcıya gösterir. Fark: EO bir hesap içerir (toplam, ortalama, rapor). EQ sadece kayıtlı veriyi getirir. “Sipariş durumunu göster” EQ, “aylık ciro raporu” EO.

Ağırlıklar

Her bileşen düşük (low), orta (average), yüksek (high) karmaşıklıkta sayılır:

Adımlar

1. TUFP (total unadjusted function points): her hücrede sayı × ağırlık, hepsini topla.
2. PC (processing complexity): 14 genel sistem özelliğini (veri iletişimi, dağıtık işlem, performans, online veri girişi, kullanım kolaylığı, yeniden kullanılabilirlik vb.) 0-5 arası puanla, topla. PC 0 ile 70 arası.
3. APC (adjusted processing complexity): $APC = 0.65 + 0.01 \times PC$.
4. AFP (adjusted function points): $AFP = TUFP \times APC$.
5. LOC: AFP × dile özgü “function point başına satır” sayısı.
6. Efor (person-month): $\text{efor} = 1.4 \times \text{KLOC}$ (KLOC = bin satır).
7. Süre (ay): $\text{süre} = 3.0 \times \text{efor}^{1/3}$.

Çözümlü örnek: KampüsYemek

Üniversite içinde kafeteryalardan sipariş verilen bir uygulama. Analist şu sayımları çıkardı:

Adım 1: TUFP.

EI : 6x3 + 4x4 + 2x6   = 18+16+12 = 46
EO : 3x4 + 2x5 + 1x7   = 12+10+7  = 29
EQ : 4x3 + 2x4 + 0x6   = 12+8+0   = 20
ILF: 2x7 + 3x10 + 1x15 = 14+30+15 = 59
EIF: 1x5 + 1x7 + 0x10  = 5+7+0    = 12
                          TUFP    = 166

Adım 2-3: APC. 14 faktörün puanları toplandı: PC = 32.

APC = 0.65 + 0.01 x 32 = 0.97

Adım 4: AFP.

AFP = 166 x 0.97 = 161.02

Adım 5: LOC. Uygulama Java ile yazılacak, ekip geçmiş projelerde function point başına 60 satır ölçmüş:

LOC = 161.02 x 60 = 9,661 satır  (9.661 KLOC)

Adım 6: Efor.

efor = 1.4 x 9.661 = 13.53 person-month

Adım 7: Süre ve ekip.

süre = 3.0 x 13.53^(1/3) = 3.0 x 2.383 = 7.15 ay
ekip ≈ 13.53 / 7.15 = 1.89 → yaklaşık 2 kişi

Yorum: 2 kişilik bir ekip bu uygulamayı yaklaşık 7 ayda bitirir. Yönetim 4 ay isterse proje yöneticisi kapsamı daraltmayı (örneğin EIF’i, yani dış ödeme entegrasyonunu sonraki sürüme bırakmayı) ya da timeboxing’i önerir. Sadece kişi eklemek süreyi aynı oranda kısaltmaz.

İPUCU · küp kök. Hesap makinesinde $x^{1/3}$ için x ^ (1/3) yaz. Parantezi unutursan x^1 / 3 hesaplanır.

İş planı ve WBS

İş planı (work plan), projenin bütün görevlerini, sürelerini, sorumlularını ve bağımlılıklarını gösteren dinamik bir takvimdir. Temeli work breakdown structure (WBS): projeyi hiyerarşik olarak küçük görevlere bölmek.

1 KampüsYemek
  1.1 Planning
      1.1.1 System request
      1.1.2 Fizibilite
  1.2 Analysis
      1.2.1 Kafeterya görüşmeleri
      1.2.2 Use case modeli
  1.3 Design
      1.3.1 Veritabanı tasarımı
      1.3.2 Arayüz taslakları
  1.4 Implementation
      1.4.1 Kodlama
      1.4.2 Test

WBS iki şekilde kurulabilir: SDLC evrelerine göre (yukarıdaki gibi) ya da ürünlere göre (sipariş modülü, ödeme modülü, raporlama modülü). Her en alt görev için: süre tahmini, sorumlu kişi, bağımlılıklar, çıktı. Bir görev bir raporlama döneminden uzun sürüyorsa daha da bölünür. WBS’den sonra Gantt ve PERT gibi araçlarla takvim çizilir (4. hafta).

Kapsam yönetimi

Scope creep

Kapsam kayması (scope creep), proje başladıktan sonra gereksinimlerin plansızca büyümesidir. “Şunu da eklesek, küçük bir şey” cümlesi en tehlikeli cümledir. Tasarım veya kodlama sırasında eklenen bir özellik analiz sırasında eklenenden kat kat pahalıdır.

Kontrol yolları:

• Gereksinimleri erken ve eksiksiz topla (JAD, prototip).
• Gereksinimleri yazılı hale getir ve onaylat.
• Değişiklikleri change request ile al: kim istedi, neden, süreye ve maliyete etkisi, onay.
• Onaylanmayan ya da düşük öncelikli istekleri sonraki sürüme ertele.

Timeboxing

Timeboxing’de teslim tarihi sabitlenir, işlevsellik esnetilir:

1. Teslim tarihini belirle ve dondur.
2. Gereksinimleri önceliklendir.
3. En önemli çekirdek özellikleri yap.
4. Tarih gelince ne bitmişse teslim et (kaliteden ödün vermeden).
5. Kalan özellikleri sonraki “timebox”a taşı.

Agile’daki sprint de bir timebox’tır.

Ekip ve risk

Staffing plan: Eforu süreye bölerek ortalama ekip büyüklüğü bulunur. Ekip büyüdükçe iletişim kanalları $n(n-1)/2$ ile artar: 4 kişide 6, 8 kişide 28 kanal. Bu yüzden büyük ekipler alt gruplara bölünür ve bir raporlama yapısı (reporting structure) kurulur.

Risk assessment: Her risk için olasılık, etki ve azaltma planı yazılır. Örnek: “Ödeme sağlayıcısı API’si değişebilir; olasılık orta, etki yüksek; adaptör katmanı yaz.”

Standartlar ve belgeleme: Belgeleme standartları, kodlama standartları, değişiklik istek formları projeyi tutarlı tutar. Proje defteri (project binder) bütün çıktıları saklar.

Sık yapılan hatalar