İnşa: programlama yönetimi, dokümantasyon ve test

Tasarım bitti, sıra inşada (construction): kod yazılır, test edilir, belgelenir. Bu aşama genelde projenin en çok kişi ve zaman gerektiren kısmıdır. Analist burada kod yazmaktan çok yönetir ve doğrular: programcıların aynı planla çalışmasını, testlerin gereksinimlere bağlanmasını, kullanıcıya doğru belgenin gitmesini sağlar. Final sınavında test seviyeleri, black-box ile white-box farkı ve “bu fonksiyon için test case’leri yaz” sorusu gelir.

Altın kurallar:

1. Test seviyeleri sırayla: unit → integration → system → acceptance.
2. Black-box spesifikasyondan, white-box koddan.
3. Sınırda test et: alt − 1, alt, üst, üst + 1.
4. Her alternate flow bir test case’tir. 7. haftadaki description’lar test planının hammaddesidir.

Programlama yönetimi

Proje yöneticisinin bu aşamadaki üç işi:

1. Programcılara görev atamak. Modüller (paketler, sınıflar) programcılara dağıtılır. Birbirine çok bağımlı modüller aynı kişiye ya da aynı küçük ekibe verilir. Ekip büyüdükçe iletişim yükü artar (3. haftadaki $n(n-1)/2$ kanal), bu yüzden “geç kalan projeye adam eklemek” işe yaramaz.

2. Aktiviteleri koordine etmek.

• Haftalık toplantılar, kısa ilerleme raporları.
• Standartlar: adlandırma, kodlama, yorum kuralları.
• Kod kontrolü (source code control / version control): kim hangi dosyayı değiştirdi, hangi sürüm test edildi. Git gibi araçlar.
• Üç ortam: geliştirme (development), test, üretim (production). Kod bir ortamdan diğerine kontrollü geçer.

3. Takvimi yönetmek. İş planı güncel tutulur, gecikmeler erken fark edilir. Scope creep bu aşamada da kontrol edilir: yeni istekler change request ile gelir.

Klasik hatalar:

Dokümantasyon

Kullanıcı dokümantasyonunun üç türü:

Online dokümantasyonun artıları: arama yapılabilir, güncellemesi kolay, ekranla bağlamsal (context-sensitive help). Belgeler kullanıcının dilinde yazılır: teknik jargon yok, görev odaklı başlıklar (“Ders rezervasyonu yap”), kısa adımlar.

Test

Test planı

Test planı analizde başlar. Her test case şu bilgileri içerir:

Test seviyeleri

Integration testing türleri: User interface testing (her arayüz fonksiyonu), use scenario testing (bir use case’i uçtan uca), data flow testing (veri modüller arasında doğru akıyor mu), system interface testing (dış sistemlerle veri alışverişi, ör. ödeme sağlayıcısı).

Integration stratejileri: Top-down (üst modüller önce, alttakiler yerine stub), bottom-up (alt modüller önce, üstteki çağıran yerine driver), big bang (hepsi birden; hata bulmak zor).

System testing türleri: requirements testing (her gereksinim karşılanıyor mu), usability testing, security testing, performance testing (yük, stres: 12. haftadaki 167 istek/sn hedefi), documentation testing (belgelerdeki adımlar gerçekten çalışıyor mu).

Black-box ve white-box

Equivalence partitioning: Girdi uzayını aynı davranması beklenen sınıflara böl, her sınıftan bir değer test et. Boundary value analysis: her sınırın altını, kendisini, üstünü test et.

Cyclomatic complexity: Koddaki bağımsız yol sayısı.

$V(G) = E - N + 2 \qquad \text{ya da} \qquad V(G) = \text{karar sayısı} + 1$

$E$ akış grafiğindeki kenar, $N$ düğüm sayısıdır. Branch coverage için en az $V(G)$ test case gerekir.

Çözümlü örnek: ceza hesaplama metodu

Kütüphane sisteminden bir metot. Kural: gecikilen her gün 2 TL; personel yarı fiyat öder; ceza kitap bedelini geçemez; gecikme yoksa ceza 0.

static double fine(int daysLate, boolean isStaff, double bookPrice) {
    if (daysLate <= 0) return 0;
    double f = daysLate * 2.0;
    if (isStaff) f = f / 2;
    if (f > bookPrice) f = bookPrice;
    return f;
}

Adım 1: Cyclomatic complexity. Üç if → V(G) = 3 + 1 = 4. En az dört bağımsız yol:

Yol 1: daysLate <= 0            → return 0
Yol 2: >0, staff değil, sınır altı
Yol 3: >0, staff, sınır altı
Yol 4: >0, staff değil, sınır üstü

Adım 2: Black-box sınıflar ve sınırlar. daysLate için: ≤ 0 (ceza yok), ≥ 1 (ceza var). Sınır: 0 ve 1. Ceza için: bedelin altı, eşit, üstü.

Adım 3: Test case tablosu (bookPrice = 100):

Hepsini çalıştırınca:

System.out.println("TC1 " + fine(0, false, 100));
System.out.println("TC2 " + fine(5, false, 100));
System.out.println("TC3 " + fine(5, true, 100));
System.out.println("TC4 " + fine(80, false, 100));
System.out.println("TC5 " + fine(1, false, 100));
System.out.println("TC6 " + fine(-3, false, 100));

TC1 0.0
TC2 10.0
TC3 5.0
TC4 100.0
TC5 2.0
TC6 0.0

TUZAK · sadece “mutlu yol” test etmek. TC2 tek başına geçer ve metodu “doğru” gösterir. Hataların çoğu sınırlarda (TC1, TC5), kısıtlarda (TC4) ve beklenmeyen girdide (TC6) çıkar.

İPUCU · use case’ten test case. 7. haftadaki Reserve Book description’ındaki her alternate flow (2a, 3a, S-1.2a, S-1.3a, 5a) bir system test case’idir. Normal flow da bir tanesidir: en az 6 test case hazır.

Sık yapılan hatalar

static double fine(int daysLate, boolean isStaff, double bookPrice) {
    if (daysLate <= 0) return 0;
    double f = daysLate * 2.0;
    if (isStaff) f = f / 2;
    if (f > bookPrice) f = bookPrice;
    return f;
}