Yazılım Geliştirme Yaşam Döngüsü (SDLC) Nedir?

SDLC süreci

SDLC süreci, müşteri beklentilerini karşılamayı, öngörülen zaman içerisinde projeyi tamamlamayı, maliyeti doğru bir şekilde hesaplamayı ve bu doğrultuda yüksek kaliteli yazılımlar üretmeyi amaçlayan kuruluşların olmazsa olmazları arasındadır.

Yazılım projelerinde bazı başarısızlıkların nedenleri kendini belirgin bir biçimde göstermektedir. Bunlardan başlıcaları şunlardır:

• Müşterinin isteklerini doğru analiz edememek,
• Ekiplerin görev tanımlarının belirsiz olması,
• Maliyet hesaplarındaki eksiklikler.

SDLC, saydığımız bu durumların olabildiğince az yaşanması veya mümkünse hiç yaşanmaması için uygulanması gereken adımlardan oluşan süreçtir ve birden fazla sayıda modele sahiptir. Bu modeller geçmişten günümüze değişen ihtiyaçlarla birlikte gelişmiş ve çeşitlenmiştir. Bu yazıda standart bir yazılım geliştirme yaşam döngüsünün aşamalarından bahsedeceğiz.

Standart bir yazılım geliştirme yaşam döngüsünün adımları şu şekildedir:

1. Planlama ve gereksinim analizi (Planning and requirement analysis)
2. Gereksinimleri tanımlama (Defining requirements)
3. Ürün mimarisini tasarlama (Designing the product architecture)
4. Ürünü oluşturma veya geliştirme (Building or developing the product)
5. Ürünü test etme (Testing the product)
6. Ürünü pazarlama ve bakım (Deployment in the market and maintenance)

Planlama ve gereksinim analizi

Gereksinim analizi SDLC'nin en önemli aşamasıdır. Bu aşamanın atlandığı veya fazla önem verilmeden gerçekleştirildiği projelerin başarısız olma ihtimali yüksektir. Bu aşamada başta müşterimiz olmak üzere yaptığımız pazar araştırmalarından, uzmanlarımızdan ve diğer departmanlardan gelen girdiler kullanılarak ekibin kıdemli üyeleri bir planlama yapar. Projeyle ilgili risklerin belirlenmesi, fizibilite çalışmaları gibi projenin başarılı bir şekilde hayata geçmesi için izlenecek yaklaşımlar tanımlanır.
 

Gereksinimleri tanımlama

Bu aşamada ise birinci aşamada planlanan gereksinimler açıkça tanımlanır ve belgelenir. Projenin yaşam döngüsü boyunca geliştirilecek olan tüm gereksinimleri içeren dökümanlar hazırlanır ve müşteriden onay alınır. Hazırlanan bu dokümana BRD (Business requirement document) yani iş gereksinimi belgesi adı verilir. BRD, oluşturmak istediğimiz yazılımın işlevsel özelliklerini temel düzeyde tanımlar. BRD oluştururken müşteri etkileşimi çok önemlidir. Müşteri ile şirketimizin mutabık kaldığı bir belge olmalıdır.

İkinci olarak oluşturulan belge ise FRD (Functional requirement document) yani fonksiyonel gereksinim belgesidir. Bu belge BRD'den türetilmiştir ve BRD'de tanımlanan gereksinimleri ayrıntılı ve teknik olarak olarak açıklar. BRD’nin beklentilerine ulaşma süreci FRD’nin kendisidir. 

BRD işletmenin ne yapmak istediği sorusuna yanıt verirken, FRD işin nasıl yapılması gerektiği sorusuna yanıt verir
 

Ürün mimarisini tasarlama

Bu aşamada BRD  baz alınarak, geliştirilecek ürün için bir tasarım yapılır ancak burada bahsedilen tasarım UI tasarım değildir, yazılımın tamamının mimari tasarımıdır. Bunu bir inşaat projesine başlamadan önce oluşturulan ve inşaatın tamamıyla ilgili bir şablon çıkartılan proje çizim aşamasına benzetebiliriz. Genellikle ürün mimarisi için birden fazla yaklaşım önerilir ve bir DDS (Design document specification) yani tasarım belgesi spesifikasyonu hazırlanır. Ürünün tüm mimari modülleri ve tüm modüllerin iç tasarımı en küçük ayrıntısına kadar tanımlanır. Bu döküman paydaşlar tarafından gözden geçirilir ve risk değerlendirmesi yapılarak ürünün sağlamlığı, tasarımın modülerliği, bütçe ve zaman kısıtlamaları gibi parametrelere dayanarak ürün için en iyi tasarım yaklaşımı seçilir.

Ürünü oluşturma veya geliştirme

SDLC’nin bu aşamasında kodlama süreciyle birlikte ürünün adım adım inşa edilme süreci başlamış olur. Developerlar kendilerine iletilen dökümanları dikkate alarak kodlamaları yaparlar. Kodlama sürecinin sorunsuz bir şekilde tamamlanması için bu aşamadan önce hazırlanan dökümanların detaylı ve organize bir şekilde yapılmış olması çok önemlidir. Eğer dökümanlarda bir gereksinim eksik veya yanlış (müşterinin isteğinin dışında) yazılmışsa yazılımcı bu eksiklikten habersiz bir şekilde kendisine iletilen gereksinimleri kodlayacaktır ve işin sonunda müşterinin isteğinin dışında bir ürün ortaya çıkacaktır. Bu nedenle bu aşamaya gelinirken hazırlanan bütün dökümanlar bir yanlış anlaşılmaya mahal vermeyecek şekilde dikkatlice hazırlanmalıdır.

Ürünü test etme

Bu aşamada, ürün BRD'de tanımlanan kalite standartlarına ve gereksinimlere ulaşıncaya kadar ürün kusurları rapor edilir, ürün izlenir ve tekrar test edilir. Bu aşamada karşılaşılan sorunlar, sanki yeni bir özellikmiş gibi SDLC döngüsünün 2. aşaması olan gereksinim tanımlama aşamasına geri döner ve yeniden test aşamasına kadar gelinir. Eğer sorun devam ediyorsa bu döngü sorun çözülünceye kadar tekrarlanır. 
 

Ürünü pazarlama ve bakım

Bu aşamada hazır olan ürünümüz resmi olarak uygun görülen şekilde piyasaya sürülür. Bazı kuruluşların iş stratejisine göre bu süreç aşamalar halinde gerçekleşebilir. Örneğin ürün ilk önce beta sürümü ile küçük bir gruba sunulabilir ve ardından geri bildirimlere bakılarak geliştirmeler yapıldıktan sonra hedeflenen pazara nihai ürün olarak sunulur. Ürün piyasaya sürüldükten sonra bakımı yapılmaya devam edilir.

SLDC aşamalarına ek olarak bahsedilmesi gereken bir diğer husus ise bu aşamalarda görev alanlar. Standart bir SDLC takımında project manager (PM), business analyst (BA), developer (Dev), quality analyst (QA) gibi roller bulunur. Farklı SDLC modellerinde bu rollerden daha fazla rol bulunabilir ancak temelde saydığımız bu rollerin olması gerekir.
 

SLDC'de roller

Proje yöneticisi (PM)

Takımdaki herkesin rolünü bilmesinden ve yerine getirmesinden sorumludur. Proje planının geliştirilmesi sürecinde proje müşteri ile yakın ilişki kurması gerekir. Takım içerisindeki iletişimi sağlar. Proje riskini yönetir. Proje çizelgesini hazırlar ve proje bütçesini yönetir. Yazılım anlamında teknik bilgisinin yüksek olması şartı yoktur. Daha çok yönetici yeteneklerinin iyi düzeyde olması beklenir. Ancak PM’nin teknik bilgi seviyesi arttıkça yazılım projeleri daha başarılı olma olasılığı da artabilir.

İş analisti (BA) 

Bir projeyi analiz eden, proje süreçlerini tasarlayan ve iş modelini değerlendiren kişidir. Teknik bilgisi yüksek olmayan PM ile developer ekibi arasında bir köprü görevi görür. BRD ve FRD'yi oluşturur ve bir takım functional requirement topladıktan sonra use cases oluşturur.
 

Geliştirici (Dev) 

Yazılımın kodlamasından sorumludur. Kendilerine aktarılan software requirement dokümanını analiz eder, gereken soruları sorar ve gereken programın oluşumunu sağlar. Beklentileri ve gereksinimleri karşılayacak yüksek kalitede kod yazarlar.

Kalite analisti (QA)

Oluşturulan projenin arzu edilen çıktı çerçevesinde son kullanıcının (end-user) beklentilerini karşılayacak seviyede olmasını sağlar. Projedeki hatalar kalite analisti tarafından bulunmalıdır ki developerlar bu hataların üzerinde calışıp sorun teşkil etmeyecek ürün ortaya koyabilsinler. Test planları stratejilerinin oluşturulması, test vaka ve senaryolarının hazırlanması, test verilerinin bir araya getirilmesi ve test caselerin execute edilmesi gibi sorumlulukları vardır.

Kaynaklar

• Big Water,  Software Development Life Cycle (SDLC)