Problem analizi ve takvim araçları: Gantt, PERT, kritik yol

Bu hafta iki parçalı. İlki problem analizi: kullanıcının şikâyetinin altındaki gerçek nedeni bulmak. İkincisi takvim araçları: 3. haftada çıkardığın görev listesini (WBS) bir takvime ve bir ağa dönüştürmek. Sınav hesabı burada: bir görev tablosu verilir, sen ağı kurar, ileri ve geri geçiş yapar, kritik yolu ve slack’leri bulursun. Bu soruyu tablo kurarak çözen kaçırmaz.

Altın kurallar:

1. Semptomu çözme, nedeni çöz. “Sistem yavaş” bir semptomdur.
2. Kritik yol = en uzun yol. Proje süresi kritik yolun uzunluğudur.
3. İleri geçişte max, geri geçişte min.
4. Slack = LS − ES. Kritik görevlerde 0.

Problem analizi

Analiz evresinin başında mevcut sistem (as-is) incelenir ve problemler listelenir. Kullanıcılar genelde semptom söyler: “Kitap ödünç almak çok uzun sürüyor.” Analistin işi bunun nedenini bulmaktır. Neden çözülmezse yeni sistem de aynı problemi taşır.

Kök neden analizi (root cause analysis)

Basit teknik: “Neden?” sorusunu birkaç kez sor.

Ödünç işlemi uzun sürüyor.       Neden?
 -> Görevli her kitabı elle yazıyor. Neden?
 -> Barkod okuyucu yok.          Neden?
 -> Eski sistem barkodu desteklemiyor.
Kök neden: sistem barkod desteklemiyor.

Fishbone (Ishikawa) diagram

Problem balığın başına yazılır, kemikler neden kategorileridir.

 People        Process
   \             \
    \ tek gorevli \ kagit form
     \             \
------+-------------+-----> [Laptop odunc
     /             /         almak 20 dk]
    / okuyucu     / kimlik
   /  bozuk      /  fotokopisi
 Technology    Policy

Her kemiğe somut nedenler yazılır, sonra hangilerinin gerçekten etkili olduğu veriyle (gözlem, ölçüm) kontrol edilir.

PIECES çerçevesi

Problemleri sınıflandırmak için kontrol listesi:

Problemler önceliklendirilir (etki, aciliyet) ve iyileştirme hedefleri (improvement objectives) yazılır: “Ödünç işlem süresini 20 dakikadan 3 dakikaya indir.” Ölçülebilir hedef, sonraki aşamalarda başarıyı test etmeyi sağlar.

Gantt şeması

Gantt chart görevleri yatay çubuklar olarak takvim üzerinde gösterir. Kolay okunur, yöneticilere sunum için idealdir. İlerleme çubuğun içi doldurularak, milestone’lar elmas ile gösterilir.

Gun           0    5    10   15 18
A Gereksinim  ####
B DB tasarim      ###
C UI tasarim      #####
D Backend            ######
E Frontend             ###
H Kilavuz              ##
F Entegrasyon              ###
G Test                        ##
Teslim                          <>

Zayıf yanı: bağımlılıklar (hangi görev hangisini bekliyor) zor görünür. Bunun için PERT ağı kullanılır.

PERT ve CPM

PERT chart (program evaluation and review technique) görevleri düğümler, bağımlılıkları oklar ile gösterir. CPM (critical path method) bu ağ üzerinde en uzun yolu bulur.

Üç noktalı tahmin (three-point estimate)

Süre belirsizse her görev için üç tahmin alınır: iyimser (optimistic, $o$), en olası (most likely, $m$), kötümser (pessimistic, $p$).

$t_e = \frac{o + 4m + p}{6}$

Örnek: $o = 4$, $m = 6$, $p = 14$ gün → $t_e = (4 + 24 + 14)/6 = 7$ gün. Standart sapma yaklaşık $(p - o)/6 = 1.67$ gün.

Dört değer

Slack (float) = LS − ES. Görevin projeyi geciktirmeden ne kadar gecikebileceği.

Çözümlü örnek: kütüphane rezervasyon sistemi

Ağ

        +-->[B 3]-->[D 6]--+
        |                  v
[A 4]---+-->[C 5]-->[E 3]->[F 3]-->[G 2]
              |                     ^
              +------>[H 2]---------+

İleri geçiş (forward pass)

Soldan sağa. ES = öncüllerin EF’lerinin en büyüğü.

A: ES 0               EF 0+4  = 4
B: ES 4  (A)          EF 4+3  = 7
C: ES 4  (A)          EF 4+5  = 9
D: ES 7  (B)          EF 7+6  = 13
E: ES 9  (C)          EF 9+3  = 12
H: ES 9  (C)          EF 9+2  = 11
F: ES max(13,12)=13   EF 13+3 = 16
G: ES max(16,11)=16   EF 16+2 = 18
Proje süresi = 18 gün

Geri geçiş (backward pass)

Sağdan sola. Son görevin LF’si proje süresi. LF = ardılların LS’lerinin en küçüğü.

G: LF 18              LS 18-2 = 16
F: LF 16 (G)          LS 16-3 = 13
H: LF 16 (G)          LS 16-2 = 14
D: LF 13 (F)          LS 13-6 = 7
E: LF 13 (F)          LS 13-3 = 10
C: LF min(10,14)=10   LS 10-5 = 5
B: LF 7  (D)          LS 7-3  = 4
A: LF min(4,5)=4      LS 4-4  = 0

Tablo ve slack

Kritik yol: A-B-D-F-G, 4 + 3 + 6 + 3 + 2 = 18 gün. Kontrol için diğer yollar: A-C-E-F-G = 17, A-C-H-G = 13. En uzun 18, tutarlı.

Yorum

• D bir gün gecikirse proje 19 güne çıkar. D üç gün gecikirse 21 gün.
• C ya da E bir gün gecikebilir, proje etkilenmez. Ama gecikirse artık iki kritik yol olur ve risk artar.
• H beş gün gecikebilir. Kaynak sıkışırsa H’deki kişiyi geçici olarak D’ye vermek mantıklıdır.

TUZAK · geri geçişte max kullanmak. C’nin iki ardılı var: E (LS 10) ve H (LS 14). LF en küçük olanı alır: 10. 14 alırsan C’ye sahte bir slack verirsin ve E’yi geciktirirsin.

İPUCU · çapraz kontrol. Hesabın sonunda slack’i 0 olan görevlerin bir zincir oluşturduğunu ve bu zincirin uzunluğunun proje süresine eşit olduğunu kontrol et. Eşit değilse bir yerde hata var.

Sık yapılan hatalar