Yazılım geliştirme yaşam döngüsü

02-13 kavramı kurdu: altı evre, şelale ve V, çevik, gereksinim, tahmin. Bu ders aynı konuyu uygulayan kişinin gözünden yeniden açar: her evrenin girdisi, çıktısı ve çıkış ölçütü nedir; iyi gereksinim nasıl yazılır ve nasıl test edilir; modeller arasında seçim hangi ölçütle yapılır; DevOps evreleri nasıl sıkıştırdı; ve kamu ihalesiyle alınan bir sistemde şartname, analiz dokümanı ve kabul tutanağı zinciri nasıl işler. İki ilanda da "yazılım geliştirme yaşam döngüsü" maddesi var ve yazılıda evre sıralama sorusu garantidir; sözlüde ise ayırt edici soru "hangi modeli seçersiniz, neden"dir. Ders 15-11'in bakım türlerine, 8. dersin PR bağına ve 11. dersin dokümanlarına köprü kurar; Agile'ın kendisi 10. derstedir.

01Ne öğreneceksin

02Evreler: girdi, çıktı, çıkış ölçütü

02-13'ün altı evresi bir liste olarak ezberlenir; meslekte ise her evrenin ne ürettiği ve "bitti" diyebilmek için hangi ölçütün sağlanması gerektiği bilinir. Evrenin çıktısı bir sonraki evrenin girdisidir; çıkış ölçütü olmayan evre bitmez, sürüklenir:

Tablonun kıdemli okuması: evreler ardışık olmak zorunda değildir ama var olmak zorundadır. Çevik bir ekipte her sprint bu altı satırı minyatürde döner; şelalede her satır aylar sürer; ikisinde de bir gereksinimi kabul kriteri olmadan geliştirmeye başlamak aynı hatadır. 15-01'in kusur maliyeti eğrisi evre başına okunur: analizde yakalanan yanlış gereksinim bir cümle düzeltmektir, üretimde yakalanan aynı yanlış veri taşıma ve yeniden eğitimdir.

03Gereksinim mühendisliği

Projelerin çoğu kodda değil gereksinimde batar: eksik, çelişkili, ölçülemez ya da değişen gereksinim. Bu yüzden analiz evresi bir "yazma" değil mühendislik işidir: toplama (görüşme, gözlem, mevcut sistem incelemesi, mevzuat okuma), çözümleme (çelişki ve boşluk bulma), belgeleme, doğrulama (paydaşla onay) ve yönetim (değişiklik kontrolü).

İşlevsel ↔ işlevsel olmayan. İşlevsel gereksinim sistemin ne yaptığını söyler: "Aday, başvuru süresi içinde bir sınava bir kez başvurabilir." İşlevsel olmayan gereksinim (kalite gereksinimi) ne kadar iyi yaptığını: ISO/IEC 25010 kalite modeli sekiz başlık verir — işlevsel uygunluk, performans, uyumluluk, kullanılabilirlik, güvenilirlik, güvenlik, bakım yapılabilirlik, taşınabilirlik. İşlevsel olmayan gereksinimler mimariyi belirler (performans hedefi önbellek ve ölçekleme kararını, güvenlik gereksinimi kimlik mimarisini doğurur) ve en çok ihmal edilenlerdir, çünkü "sistem hızlı olmalı" cümlesi yazması kolay, test etmesi imkânsız bir gereksinimdir.

İyi gereksinimin ölçütleri (IEEE 830'dan bu yana yerleşik): doğru, tek anlamlı, tam, tutarlı, önceliklendirilmiş, doğrulanabilir, değiştirilebilir, izlenebilir. Bunlardan ikisi süreç kurar. Doğrulanabilirlik için her gereksinime bir kabul kriteri yazılır — en yaygın biçim Given/When/Then:

Gereksinim BAS-17: Aday bir sınava yalnız bir kez başvurabilir.
Kabul kriteri:
  Given  adayın 2026-KPSS sınavına onaylı bir başvurusu var
  When   aynı sınava ikinci başvuru gönderir
  Then   sistem 409 ile reddeder ve "mevcut başvuru" numarasını döner
  And    ilk başvuru değişmeden kalır

Bu kriter aynı zamanda 15. hattın test senaryosudur — analist ile testçi aynı cümleyi kullanır, geliştirici PR'ında (8. ders) aynı numaraya bağlanır. İzlenebilirlik için bir izlenebilirlik matrisi tutulur: gereksinim → tasarım öğesi → kod/PR → test → sürüm. Denetçi "BAS-17 nerede test edildi" sorduğunda cevap bir tabloda bulunur; bir gereksinim değiştiğinde etkilenen testler ve kod aynı tablodan okunur (etki analizi). Kamu projelerinde bu matris çoğu zaman sözleşmesel teslimattır.

Değişiklik kontrolü. Gereksinim değişir; sorun değişmesi değil, kontrolsüz değişmesidir (kapsam kayması). Yerleşik mekanizma: değişiklik talebi yazılı gelir → etki analizi (matris: hangi tasarım, kod, test, doküman, süre, maliyet) → yetkili kurul (değişiklik kontrol kurulu) karar verir → kabul edilirse SRS sürümlenir, backlog ve sözleşme güncellenir. Çevik ekipte aynı mekanizma daha hafiftir: PO backlog'u yeniden önceliklendirir — ama "sprint ortasında kapsam değişmez" kuralı aynı ihtiyacın cevabıdır (10. ders).

04Modeller: evreleri zamana dizmek

02-13'ün cümlesi: evreler değişmez, akış değişir. Modeller o akışın stratejileridir:

• Şelale. Evreler ardışık, her evrenin sonunda doküman onayı (çıkış kapısı), geriye dönüş istisna. Tarihî not: 1970'te modeli çizen Royce, aynı makalede bu biçimin riskli olduğunu ve iterasyon gerektiğini yazmıştı; "şelale" adı sonradan kondu. Uygun yeri: gereksinim gerçekten sabit, teknoloji bilinen, sözleşme kilometre taşı isteyen işler. Riski: ilk çalışan yazılım en sonda görülür; yanlış anlaşılan gereksinim en pahalı anda çıkar.
• V modeli. Şelalenin "test sonda" zaafına cevap: sol koldaki her tanımlama evresi, sağ kolda bir test seviyesiyle baştan eşleştirilir — gereksinim ↔ kabul testi, sistem tasarımı ↔ sistem testi, mimari ↔ entegrasyon testi, modül tasarımı ↔ birim testi. Test planı, kod yazılmadan önce yazılır; 15-02'nin piramidi V'nin sağ koludur. Düzenleyici ve güvenlik kritik alanların (savunma, sağlık, otomotiv) yerleşik modeli.
• Artımlı ↔ iteratif. İki farklı fikir, sık karıştırılır. Artımlı: sistem parça parça inşa edilir, her artım tam ve kullanılabilir bir dilimdir (önce başvuru, sonra ödeme, sonra rapor). İteratif: aynı parça tekrar tekrar rafine edilir (önce kaba başvuru, sonra doğrulamalı, sonra hızlı). Çevik ikisini birleştirir: her iterasyonda artım.
• Spiral. Boehm'in risk odaklı modeli: her döngüde hedef belirle → riskleri tanımla ve prototiple azalt → geliştir ve doğrula → sonraki döngüyü planla. Büyük, riskli, yeni teknolojili projeler için; maliyeti risk analizi uzmanlığı ister.
• RUP (Rational Unified Process). Dört evre — başlangıç, ayrıntılandırma (mimari riskleri kapat, çalışan mimari iskelet), inşa, geçiş — ve her evrede iteratif disiplinler. Ağır dokümantasyonuyla anılır; bugün çoğu ekipte iz olarak yaşar: "önce mimari iskelet, sonra özellik" fikri.
• Agile. Kısa iterasyon, çalışan yazılım, geri bildirim, değişime yanıt. 10. ders.

05Model seçimi: hangi durumda hangisi

Sözlüde "hangi modeli kullanırsınız" sorusunun tek cevabı yoktur; ölçütlü cevabı vardır. Beş ölçüt:

1. Gereksinim belirsizliği. Ne istendiği netse ve değişmeyecekse ardışık model çalışır; belirsizse iterasyon şart — belirsiz gereksinimi şelaleyle sabitlemeye çalışmak, yanlış sistemi doğru süreçle üretmektir.
2. Sözleşme ve mevzuat. Sabit kapsam-sabit fiyat sözleşme, kabul kilometre taşları ve denetim kanıtı istiyorsa evre kapıları gerekir; ama kapı içinde iterasyon yasak değildir.
3. Teknik risk. Bilinmeyen teknoloji, entegrasyon riski, performans şüphesi varsa erken prototip (spiral / RUP ayrıntılandırma / Agile spike).
4. Geri bildirim erişimi. Gerçek kullanıcı her iki haftada bir ürünü görebiliyor mu? Göremiyorsa Agile'ın ana motoru çalışmaz; görebiliyorsa şelale o fırsatı çöpe atar.
5. Ekip ve organizasyon olgunluğu. Test otomasyonu, CI, ürün sahipliği yoksa "Agile" sadece kısa şelalelerdir.

Bu ölçütlerle kamu senaryosu şöyle çözülür: mevzuat sabit + sözleşmeli teslimat → şelale-benzeri kilometre taşları (analiz onayı, tasarım onayı, kabul); içeride iteratif — kabul edilmiş SRS'nin dilimleri sprint'lerle geliştirilir, her sprint sonu kurum temsilcisine gösterilir, UAT kabulden aylar önce başlar. Bu hibrit, 02-13'ün "olgun cevap ikisini kutuplaştırmaz" cümlesinin işletilmiş hâlidir. Anti-örnek, sık görülür: sözleşme "Agile" der, şartname 400 sayfa sabit kapsam ister, sprint'ler analiz-tasarım-kod-test sırasıyla mini şelaleye döner, sonunda tek büyük teslim — adı çevik, işleyişi şelale, iki modelin de kazancı yok. Model seçimi bir kez yapılıp ADR olarak yazılır (11. ders); "neden böyle çalışıyoruz" sorusunun cevabı sözlü gelenek olmamalı.

06Tasarım ve geliştirme evresinin kıdemli gerçekleri

Tasarım evresinin çıktısı diyagram değil karardır: hangi mimari (4-13 tas-mimari), hangi veritabanı, kimlik nasıl (13. hat), sınırlar nerede, hangi teknoloji neden. Her kararın gerekçesi ve reddedilen seçenekleri ADR olarak kayda geçer; altı ay sonra "neden PostgreSQL" sorusunun cevabı bir dosyadır (11. ders). Arayüz sözleşmesi (OpenAPI, 6. hat) tasarımda yazılır, böylece frontend ve backend paralel ilerler ve sözleşme testi (15. hat) erken kurulur. Güvenlik tasarımı burada başlar: 14-02'nin tehdit modeli, 14-09'un güvenli geliştirme yaşam döngüsü (SDL) — güvenlik, test evresinde bulunan hata değil, tasarım evresinde alınan karardır.

Bilinmeyen için spike/prototip: kısa, atılacak bir deneme ("bu kütüphane 10 bin kaydı kaç saniyede işler"). Prototip üretime gitmez; giderse teknik borç doğar (15-11'in "bilinçli ve kayıtlı" borç kuralı). Geliştirme evresinde DoD (10. ders) neyin "bitti" olduğunu tanımlar — kod yazıldı değil: incelendi (8. ders), testler yeşil, CI geçti, doküman güncellendi, dağıtılabilir. Tasarım dokümanı yaşayan dokümandır: kodla aynı PR'da güncellenmeyen tasarım, ilk ayda yalan söylemeye başlar.

07Test, dağıtım ve geçiş

Test evresi, V modelinin sağ koludur ve çoğu otomasyondur (15. hat). Bu evrede süreç olarak eklenen parçalar: test planı (neyi, hangi seviyede, hangi ortamda, kim, giriş/çıkış ölçütü), hata sınıflandırması — önem (severity: sistem çöküyor mu, veri bozuluyor mu) ile öncelik (priority: ne zaman düzeltilmeli) ayrı eksenlerdir; kritik ama nadir bir hata düşük öncelikli olabilir — ve kabul testi (UAT): gerçek kullanıcı, gerçek senaryo, kabul kriterleri (03. bölüm) üzerinden; UAT geçmeden "bitti" yoktur. Performans, güvenlik (sızma testi, 14-09) ve erişilebilirlik testleri işlevsel olmayan gereksinimlerin kanıtıdır.

Dağıtım evresinin karar noktası go/no-go: açık kritik hata yok mu, geri alma planı var mı, izleme kuruldu mu, veri geçişi provası yapıldı mı, eğitim verildi mi, artık risk (14-02) yazılı kabul edildi mi. Geri alma planı pazarlıksızdır: her dağıtım, önceki sürüme dönüş yolunu (6. dersin revert'i, 18. hattın mavi-yeşil/kanarya stratejileri) ve veri şeması değişmişse geriye uyumlu migration'ı içerir. Eski sistemden geçiş (migration) ayrı bir mini projedir: veri temizliği, eşleme, prova, paralel çalışma dönemi, kesim tarihi.

08Bakım ve DevOps'un döngüye etkisi

02-13'ün en pahalı evresi burada büyür: yaşayan bir sistemin toplam maliyetinin kabaca %60-80'i teslimden sonra harcanır. 15-11 dört bakım türünü verdi (düzeltici, uyarlayıcı, iyileştirici, önleyici); süreç tarafında eklenenler: SLA/SLO (kullanılabilirlik, yanıt süresi, düzeltme süresi taahhütleri — 14-14'ün yama SLA'sı bunun güvenlik dilimidir), olay yönetimi (14-10: tespit, sınıflandırma, müdahale, postmortem), sürüm politikası (SemVer, destek penceresi — 7. dersin "kaç sürüm destekleniyor" kararı), ve bakım sözleşmesi (kamu: garanti süresi + bakım-destek sözleşmesi).

DevOps, SDLC'yi yeni bir model değil, evreler arasındaki duvarları kaldıran bir yaklaşımdır: "geliştiren ekip yazar, işletim ekibi çalıştırır" ayrımı yerine aynı ekip yazar, dağıtır, izler ("you build it, you run it"). Sonsuz döngü şeması — planla → kodla → derle → test et → yayımla → dağıt → işlet → izle → planla — altı evrenin aynısıdır, ama her commit için döner: CI/CD (18. hat) analiz dışındaki tüm evreleri dakikalara sıkıştırır. Bu, modelin seçimini değiştirmez; her modelin hızını değiştirir — şelale kilometre taşlı bir kamu projesinde bile her PR derlenir, test edilir ve UAT ortamına otomatik çıkar. 7. dersin DORA metrikleri bu döngünün sağlığını ölçer.

09Kamu ihalesi gerçeği: doküman zinciri

İki ilanın kurumlarında yazılım büyük ölçüde ya iç ekiple ya ihaleyle geliştirilir; ikinci durumda SDLC, bir doküman zinciri olarak somutlaşır ve her halka sözleşmesel teslimattır:

Bu zincirin kıdemli gerçekleri: (1) kabul kriteri yazılı değilse kabul tartışmadır — "hızlı olmalı" şartname maddesi kabul komisyonunda ölçüsüz kalır; şartname yazan mühendisin en değerli katkısı 03. bölümün ölçülebilirliğidir. (2) Analiz dokümanı onayı, kapsamın hukuken sabitlendiği andır; sonrası değişiklik kontrolüdür ve ek süre/bedel tartışması doğurur. (3) Kurum tarafındaki yazılım uzmanının işi kod yazmak kadar bu dokümanları okumak, doğrulamak ve kabul etmektir — 11. dersin teknik yazım ilkeleri burada sınav konusudur. (4) Standart referansı: ISO/IEC/IEEE 12207 yazılım yaşam döngüsü süreçlerini (edinme, tedarik, geliştirme, işletme, bakım) tanımlar; şartnameler sık atıf yapar; küçük kuruluşlar için hafifletilmiş 29110 vardır. (5) e-Devlet, kurumlar arası entegrasyon ve kamu bulut/veri merkezi kısıtları (14-13 kamu mevzuatı) işlevsel olmayan gereksinim olarak şartnameye girer; mimari kararı baştan belirler.

10Mini alıştırma — bir sayfalık SRS

11Kendini sına

SDLC'nin evreleri nelerdir; her evrenin çıktısı ve çıkış ölçütü nedir? Evreler neden "ardışık olmak zorunda değil ama var olmak zorunda"dır?

Planlama/fizibilite (kapsam, kaba maliyet, risk, go/no-go); analiz (SRS + kabul kriterleri; çıkış: her gereksinim ölçülebilir, onaylı, izlenebilirlik numaralı); tasarım (mimari + ADR'ler, veri modeli, arayüz sözleşmesi, güvenlik tasarımı, test stratejisi; çıkış: her gereksinim bir bileşene eşlendi, tehdit modeli yapıldı); geliştirme (kod + testler + PR'lar; çıkış: DoD — incelendi, CI yeşil, doküman); test (test planı ve raporu, hata kayıtları, UAT tutanağı; çıkış: kabul kriterleri geçti, açık kritik hata yok, artık risk kabul edildi); dağıtım + bakım (tag, runbook, changelog, eğitim; çıkış: geri alınabilir dağıtım, izleme; sonra dört bakım türü). Çıkış ölçütü olmayan evre bitmez, sürüklenir. Ardışık olmak zorunda değiller çünkü çevik ekip altı evreyi her sprint'te minyatürde döndürür; var olmak zorundalar çünkü kabul kriteri olmadan geliştirmeye başlamak her modelde aynı hatadır ve kusur maliyeti eğrisi evre başına okunur — analizde yakalanan yanlış gereksinim bir cümle, üretimde yakalanan veri taşıma ve yeniden eğitimdir.

İşlevsel ve işlevsel olmayan gereksinim farkı nedir? İyi gereksinimin ölçütleri, kabul kriteri ve izlenebilirlik matrisi ne işe yarar?

İşlevsel gereksinim sistemin ne yaptığını söyler ("aday bir sınava bir kez başvurabilir"); işlevsel olmayan, ne kadar iyi yaptığını — ISO/IEC 25010'un sekiz başlığı: işlevsel uygunluk, performans, uyumluluk, kullanılabilirlik, güvenilirlik, güvenlik, bakım yapılabilirlik, taşınabilirlik. İşlevsel olmayanlar mimariyi belirler ve en çok ihmal edilenlerdir çünkü "hızlı olmalı" yazması kolay, test etmesi imkânsızdır; iyi hâli sayı + eşik + koşuldur ("500 eşzamanlı kullanıcıda p95 < 300 ms"). İyi gereksinim: doğru, tek anlamlı, tam, tutarlı, önceliklendirilmiş, doğrulanabilir, değiştirilebilir, izlenebilir. Kabul kriteri doğrulanabilirliği sağlar — Given/When/Then biçimi analistin, testçinin ve geliştiricinin aynı cümleyi kullanmasını sağlar; test senaryosunun kendisidir; PR aynı numaraya bağlanır. İzlenebilirlik matrisi gereksinim → tasarım → kod/PR → test → sürüm zincirini tutar: denetçiye "nerede test edildi" cevabı, değişiklikte etki analizi (hangi test, kod, doküman etkilenir), kamu projesinde sözleşmesel teslimat. Değişiklik kontrolü: yazılı talep → etki analizi → yetkili kurul kararı → SRS sürümlenir; kapsam kaymasının ilacı.

Şelale, V, artımlı/iteratif, spiral ve Agile'ı karşılaştır. Hangi ölçütlerle model seçilir; mevzuatı sabit, ihaleyle alınan bir kamu projesi için ne önerirsin?

Şelale: ardışık evreler, doküman onaylı kapılar; ilk çalışan yazılım sonda; sabit gereksinim ve sözleşme kilometre taşı için (Royce bile iterasyon önermişti). V: her tanımlama evresi bir test seviyesiyle baştan eşleşir — gereksinim ↔ kabul, sistem tasarımı ↔ sistem, mimari ↔ entegrasyon, modül ↔ birim; test planı koddan önce; düzenleyici ve kritik sistemler. Artımlı (parça parça, her artım kullanılabilir dilim) ↔ iteratif (aynı parça rafine edilir); Agile ikisini birleştirir. Spiral: risk odaklı döngüler — hedef, risk/prototip, geliştir, planla; büyük ve riskli projeler. RUP: başlangıç, ayrıntılandırma (mimari iskelet), inşa, geçiş. Agile: kısa iterasyon, çalışan yazılım, geri bildirim. Seçim ölçütleri: gereksinim belirsizliği, sözleşme/mevzuat (kapı ve kanıt ihtiyacı), teknik risk (erken prototip), geri bildirim erişimi (gerçek kullanıcı iki haftada bir görebiliyor mu), ekip olgunluğu (test otomasyonu, CI, ürün sahipliği). Kamu senaryosu: mevzuat sabit + sözleşmeli teslimat → şelale-benzeri kilometre taşları (analiz onayı, tasarım onayı, kabul) + içeride iteratif — onaylı SRS'nin dilimleri sprint'lerle geliştirilir, her sprint sonu kurum temsilcisine gösterilir, UAT erken başlar. Anti-örnek: adı Agile, sprint'ler mini şelale, tek büyük teslim. Karar ADR olarak yazılır.

Bakımın maliyet payı nedir; DevOps SDLC'yi nasıl değiştirir? Kamu ihalesinde doküman zinciri nasıl işler ve kabul neden kriterle bağlıdır?

Yaşayan sistemin toplam maliyetinin kabaca %60-80'i teslimden sonra harcanır; dört bakım türü (düzeltici, uyarlayıcı, iyileştirici, önleyici) + süreç parçaları: SLA/SLO, olay yönetimi ve postmortem, sürüm politikası ve destek penceresi, bakım sözleşmesi/garanti. DevOps yeni bir model değil, evreler arasındaki duvarları kaldıran yaklaşımdır: aynı ekip yazar, dağıtır, izler; sonsuz döngü (planla-kodla-derle- test-yayımla-dağıt-işlet-izle) altı evrenin aynısıdır ama her commit için döner; CI/CD analiz dışı evreleri dakikalara sıkıştırır; model seçimini değil hızını değiştirir — kilometre taşlı kamu projesinde bile her PR derlenip UAT'ye otomatik çıkar; DORA metrikleri döngünün sağlığını ölçer. İhale zinciri: teknik şartname (kurum; kapsam, gereksinimler, teslimatlar, kabul yöntemi, garanti) → analiz dokümanı/SRS (yüklenici yazar, kurum onaylar; kapsam mührü) → tasarım dokümanı/SDD → test planı ve raporu + UAT → kılavuzlar, runbook, kaynak kod teslimi → muayene ve kabul tutanağı (komisyon maddeleri tek tek doğrular, garanti başlar). Kabul kriteri yazılı değilse kabul tartışmadır: "hızlı olmalı" maddesi komisyonda ölçüsüz kalır; analiz onayından sonra her değişiklik ek süre/bedel tartışmasıdır; kurum tarafındaki uzmanın işi bu dokümanları okuyup doğrulamaktır. Referans standart ISO/IEC/IEEE 12207 (küçük kuruluşlar için 29110).

12Sınav köşesi