SDLC Nedir? Yazılımın Fikirden Emekliliğe Yaşam Döngüsü

Sürüm notu: Bu yazı, Nisan 2026'da yayımlanan 12207:2026 yazılım yaşam döngüsü standardını ve 2024 tarihli SWEBOK (Software Engineering Body of Knowledge) Guide v4.0'ı esas alır.

Önce Tahmin Et

Bookstore ekibinden "sipariş iadesi" feature'ı isteniyor: müşteri, teslim aldığı siparişi 14 gün içinde iade edebilsin. Product Owner işi ekibe anlatırken "iki sprint'lik iş, kodlayıp test edip çıkarız" diyor. Ekip de kafasında aynı resmi çiziyor: bir endpoint, bir Angular formu, birkaç test.

Şimdi tahmin et: bu feature production'a çıktıktan üç yıl sonra, üzerinde harcanmış toplam emeğin ne kadarı o ilk iki sprint'te harcanmış olur? Ve feature bir gün kaldırılmak istenirse, o işin planı bugün kimin aklında?

Cevabı yazının sonunda kendi ekibinin verisiyle vereceksin. Ama sezgisel cevap neredeyse her zaman yanlış: ilk teslimat, bir yazılımın ömründeki en kısa ve en görünür dilimdir. SDLC (Software Development Life Cycle) dediğimiz şey, bu ömrün tamamına bakmanın adıdır.

SDLC Nedir? Phase ile Model Arasındaki Fark

SDLC, bir yazılım sisteminin fikir olarak doğmasından kullanımdan kaldırılmasına kadar geçtiği aşamaların bütünüdür. Bu tanımda iki kavram sürekli karışır ve serinin geri kalanı bu ayrıma dayanır:

• Phase (aşama): yapılması gereken iş türü. Requirements'ı anlamak, tasarlamak, kodlamak, test etmek, deploy etmek, işletmek, emekliye ayırmak.
• Model: bu aşamaların hangi sırayla, kaç kez ve ne kadar örtüşerek yapılacağına dair karar. Waterfall, V-Model, Spiral, iterative modeller, Scrum ve Kanban gibi Agile yaklaşımlar ve DevOps döngüsü birer modeldir.

Bu ayrım önemli, çünkü "biz Agile'ız, bizde design aşaması yok" cümlesi bir kategori hatası. Scrum yapan bir ekip de tasarım yapar; sadece bunu projenin başında bir kez ve altı ay boyunca değil, her sprint'te küçük parçalar halinde yapar. Waterfall yapan bir ekip de test eder; sadece testi tek bir büyük blok olarak sona koyar. Aşamalar her modelde var. Değişen, aşamaların sıralanışı, tekrar sayısı ve geri bildirimin ne kadar sürede geldiği.

Yedi Aşama ve Her Birinin Çıktısı

Kaynaklar aşamaları farklı sayılar ve adlarla verir; kimi analiz ile requirements'ı ayırır, kimi deployment'ı operations'ın içine koyar. Bu seride yedi aşamalık bir çerçeve kullanıyoruz, çünkü geliştiricinin günlük işinde gördüğü ayrım bu:

Her aşamanın elle tutulur bir çıktısı (artifact) var ve bir aşamanın "bitti" sayılması bu çıktının varlığına bağlı. Requirements aşamasının çıktısı, acceptance criteria'sı yazılmış user story'ler ya da bir requirements dokümanıdır. Design'ın çıktısı ADR'lar (Architecture Decision Record), API (Application Programming Interface) contract'ı ve veritabanı şemasıdır. Implementation'ın çıktısı review'dan geçmiş pull request'ler ve unit test'lerdir. Test aşaması bir test raporu ve bulunan hataların listesini üretir. Deployment'ın çıktısı versiyonlanmış bir release artifact'i ve release notudur. Operations aşaması runbook, dashboard ve incident kayıtları biriktirir. Retirement ise veri arşivi ve kullanıcılara yapılan sunset duyurusuyla biter.

Bu çıktılar bürokrasi için değil, sonraki aşamanın girdisi oldukları için var. Test eden kişi acceptance criteria'yı bilmiyorsa neyi doğrulayacağını bilmez; operations'taki nöbetçi runbook'u yoksa gece ikide çözümü sıfırdan keşfeder. Hangi modeli seçersen seç, bu zincirdeki bir halkayı atlarsan bedelini bir sonraki aşamada ödersin.

Bir Feature'ın Yolculuğu: Sipariş İadesi

Bookstore'un iade feature'ını aşama aşama izleyelim. Requirements'ta ekip ilk soruyu sorar: "14 gün neye göre sayılır, sipariş tarihine mi teslim tarihine mi?" Cevap teslim tarihi çıkar; bunu kargo firmasından gelen teslim event'inden öğreniyoruz. Bu tek cümle, design aşamasında Shipping tarafından gelen bir event'e bağımlılık doğurur. Bu tür user story ve acceptance criteria yazımı ilerideki Requirements Analysis serisinin konusu.

Design'da iki karar çıkar: iade talebi ayrı bir ReturnRequest kaydı olarak tutulacak ve para iadesi Payment servisine asenkron bir mesajla iletilecek. İkinci karar bir ADR'a yazılır, çünkü "neden senkron çağırmadık?" sorusu altı ay sonra mutlaka sorulacak. ADR yazmanın ayrıntısı Architecture Decision'lar serisinin "ADR Yazmak" yazısında.

Implementation ve test aşamaları ekibin en iyi bildiği kısım: endpoint, Angular formu, unit ve integration test'ler. Deployment'ta ilk sürpriz çıkar: para iadesi mesajını işleyen consumer'ın yeni bir queue'ya ihtiyacı var ve production ortamında bu queue'yu açacak yetki ekipte değil. İş, platform ekibinden bir talep bekler. Operations'ta ikinci sürpriz gelir: ilk ay iade taleplerinin yüzde kaçının para iadesine dönüştüğünü kimse göremiyor, çünkü kimse bunun için bir metric tanımlamamış.

İki sürprizin de ortak noktası, "kodlama + test" diye düşünülen işin dışında kalmaları. Biri deployment'ın, diğeri operations'ın requirements'ıydı ve ikisi de en başta konuşulabilirdi.

Bakım: Yaşam Döngüsünün En Uzun Aşaması

Feature production'a çıktığı gün yaşam döngüsünün en uzun aşaması başlar. Bakım standardı 14764 ve SWEBOK, bakım işini temelde dört türe ayırır: corrective (bulunan hatayı düzeltmek), adaptive (değişen ortama uyum: yeni .NET sürümü, kargo firmasının API'sinin değişmesi), perfective (performans ve kullanılabilirliği iyileştirmek) ve preventive (henüz hata vermemiş ama verecek sorunları önlemek, teknik borcu ödemek).

Bookstore'un iade feature'ı için bakımın ilk yılı şöyle geçebilir: kargo firması teslim event'inin formatını değiştirir (adaptive), yılbaşı kampanyasında iade süresi 30 güne çıkarılır (perfective), saat dilimi yüzünden 14. günün son saatlerinde gelen talepler reddedilir (corrective) ve .NET'in bir sonraki LTS (Long-Term Support) sürümüne geçiş yapılır (adaptive). Bunların hiçbiri ilk iki sprint'in planında yoktu.

Literatürde sık tekrarlanan bir tahmin, bir sistemin ömür boyu maliyetinin yarısından fazlasının ilk teslimattan sonra harcandığıdır. Oran sisteme ve kaynağa göre çok değişir; tek bir yüzdeyi kesin bilgi gibi kullanma. Ama yönü değişmez: uzun yaşayan bir sistemde ilk teslimat, toplam emeğin küçük bir parçasıdır. Bu yüzden ilk teslimatta okunabilir kod, test ve doküman için harcanan zaman bir lüks değil, bakım aşamasının ön ödemesidir.

Retirement: Kimsenin Planlamadığı Son Aşama

Her yazılım bir gün kaldırılır. Kaldırma işi "repo'yu arşivle" kadar basit değildir. Bookstore'un eski /api/v1/returns endpoint'ini kaldırmak istediğini düşün. Önce kimin çağırdığını bilmen gerekir; mobil uygulamanın iki yıl önceki sürümü hâlâ bunu kullanıyor olabilir. Sonra çağıranlara haber verirsin: HTTP (Hypertext Transfer Protocol) response'larında Deprecation ve Sunset header'ları (RFC (Request for Comments) 9745 ve RFC 8594) bu iş için standartlaşmış bir yol sunar. Sonra veri gelir: iade kayıtları vergi ve tüketici mevzuatı nedeniyle yıllarca saklanmak zorunda olabilir, ama kişisel veriler de KVKK (Kişisel Verilerin Korunması Kanunu) gereği süresi dolunca silinmeli ya da anonimleştirilmelidir.

Yaşam döngüsü standardı 12207 bu aşamayı "disposal" adıyla ayrı bir technical process olarak tanımlar. Bu, aşamanın ciddiye alınması gerektiğinin bir işareti: retirement, çoğu ekibin hiç planlamadığı ama mutlaka yaşadığı tek aşamadır.

Standart Ne Diyor? 12207:2026'nın Yapısı

Yazılım yaşam döngüsünün uluslararası standardı, ISO (International Organization for Standardization), IEC (International Electrotechnical Commission) ve IEEE (Institute of Electrical and Electronics Engineers) tarafından ortak yayımlanan ISO/IEC/IEEE 12207'dir. İkinci baskısı Nisan 2026'da çıktı ve 2017 baskısının yerini aldı. Standart, process'leri dört grupta toplar:

Standartla ilgili en önemli bilgi şu: 12207 bir yaşam döngüsü modeli dayatmaz. Hangi process'lerin olması gerektiğini ve ne amaçla yapıldığını söyler; bunların Waterfall ile mi, Scrum ile mi, DevOps ile mi yapılacağını sana bırakır. Bu yüzden "standart bizden Waterfall istiyor" cümlesi çoğu zaman standardın değil, standardı uygulayan kurumun kararıdır. 2026 baskısının 2017'ye göre değişiklik listesi ücretsiz kaynaklarda yayımlanmış değil; bu yüzden burada yalnız yapıya değindik.

SWEBOK Guide v4.0 ise bir standart değil, yazılım mühendisliğinin bilgi alanlarını haritalayan bir rehber. 2024'teki dördüncü sürümde bilgi alanı sayısı 18'e çıktı; yeni eklenenler arasında Software Architecture, Software Security ve Software Engineering Operations var. Operations'ın ayrı bir bilgi alanı olması, bu yazının ana iddiasıyla aynı yönü gösteriyor: yazılım mühendisliği deploy'la bitmiyor.

Üretimde Dikkat

Yaşam döngüsünü gerçek bir ekipte görünür kılmanın en ucuz yolu, her aşamanın çıktısını her feature için sormaktır. Bookstore ekibi bunun için Definition of Done'a üç madde ekledi: yeni endpoint'in sahibi ve izlenecek metric'i tanımlı, alarm eşiği runbook'ta yazılı, kaldırılırsa hangi verinin ne kadar saklanacağı biliniyor. Definition of Done'ın kendisi Scrum serisinin "Increment ve Definition of Done" yazısında ayrıntılı anlatılıyor.

İkinci pratik, operations'tan gelen geri bildirimi requirements'a bağlamaktır. Incident sonrası yazılan postmortem'deki "aksiyon" maddeleri backlog'a girmiyorsa, figürdeki yeşil ok kopuktur: döngü bir zincire dönüşür ve aynı incident tekrar yaşanır.

Üçüncüsü, maliyeti doğru aşamaya yazmaktır. Ekip yalnız yeni feature'ları sayıyorsa, bakım işi görünmez olur ve "neden yavaşladık?" sorusunun cevabı hiç bulunmaz. Board'da bakım işini ayrı bir etiketle göstermek, Kanban serisinde anlatılan flow metric'leriyle birleşince bu görünmez işi ölçülebilir kılar.

Sık Düşülen Tuzaklar

SDLC'yi yalnız "kodlama + test" sanmak en yaygın tuzak. Bu bakışla planlanan bir feature, deployment yetkisi, monitoring, veri saklama ve kaldırma gibi işleri plansız iş olarak geri getirir. Bu işler kaybolmaz, sadece en pahalı anda ortaya çıkar.

İkinci tuzak, aşama ile modeli karıştırmak. "Waterfall'ı bıraktık, artık design yapmıyoruz" diyen bir ekip design'ı bırakmamış, sadece görünmez yapmıştır. Kararlar yine verilir, ama koda gömülü ve belgesiz olarak.

Üçüncüsü retirement'ı unutmak. Kullanılmayan endpoint'ler kapatılmadan yıllarca açık kalır; her biri bakım maliyeti ve saldırı yüzeyidir. Web Güvenliği (OWASP Top 10) serisinde anlatılan güvenlik açıklarının bir kısmı tam olarak bu unutulmuş yüzeylerde yaşar.

Dördüncüsü, standartları bir modelin gerekçesi gibi okumak. 12207 hangi process'lerin gerektiğini söyler, sıralarını söylemez.

Küçük Bir Deneme

★☆☆ Ekibinin son tamamladığı feature'ı al ve yedi aşamanın her biri için çıktıyı yaz. Hangi aşamanın çıktısı yoktu ya da sadece birinin kafasındaydı?

★★☆ Son üç ayın kapanan işlerini board'dan dışa aktar ve her birini "yeni feature" ya da bakım türlerinden biri (corrective, adaptive, perfective, preventive) olarak etiketle. Yazının başındaki sorunun cevabı, senin ekibin için bu oran.

★★★ Sisteminde en az kullanılan bir endpoint seç ve onun için bir retirement planı yaz: kim çağırıyor, nasıl haber verilecek, hangi veri ne kadar saklanacak, hangi tarihte kapanacak.

Aşamaları ve modeli ayırdık. Bir sonraki yazıda bu aşamaları ilk kez tek bir diyagramda sıraya koyan makaleye, Winston Royce'un 1970 tarihli metnine dönüyoruz ve "Waterfall" diye bildiğimiz şeyin Royce'un aslında önermediği bir şey olduğunu göreceğiz.