Yazılım Geliştirme Yaşam Döngüleri (System Development Life Cycle – SDLC) Nedir?

Yazılım Mühendisliği projelerinin temel döngüleri SDLC (System Development Life Cycle) olarak
geçmektedir. Bu döngüler; Planlama (Planning), Analiz (Analyze), Tasarım (Design), Gerçekleştirme
(Implementation) ve Bakım (Maintanance)’dır. Kısaca PADIM olarak geçmektedir. Aşağıda bu konular
başlıklar halinde detaylıca incelenecektir.

1. Planlama

Bu aşamada, bir ürün geliştirmek için ürünü kullanacak müşteriden beklentileri ve talepleri toplanır.
Daha sonra herhangi bir belirsizlikle karşılaşmamak adına bu aşama detaylıca hazırlanmalıdır.


Ürünle ilgilenen İş Analisti/Proje Yöneticisi, ürünü kullanacak müşterinin hayalinde tasarladığı ürün
hakkında bilgi edinmek için müşteriyle bir toplantı düzenler. Örneğin, Bir müşteri sanal pos ile ödeme
sistemine sahip olmak istiyor. Bu sistemin kurulması için hangi özelliklere ihtiyaç varsa bu gerekliliklerin
net olarak öğrenilmesi gerekmektedir. Müşteri talepleri öğrenildikten sonra analiz yapılır. Herhangi bir
belirsizlik olması durumunda belirsizlikler ortadan kalkana kadar müşteri ile görüşmelere devam edilir.


Yukarıdaki örnekte yer alan sanal pos sistemi hakkında örnek bir fizibilite yapalım. Müşterinin ödeme
almak için sanal pos ihtiyacının olması aslında bir ticari sisteminin olduğu ve ürün/hizmet sattığı
aşikardır. Bu durumda ödeme alınacak ürün/hizmet ile ilgili bilgiler ile tahsil edilen tutarı ödeme
sonrasında bir şekilde kayıt altına almak gerekmektedir. Bu sebeple bu verileri saklayabileceğimiz bir
veri tabanına ihtiyaç vardır. Ayrıca mevcut sistemin de bir veri tabanı olması durumunda bu veri
tabanında ayrı bir tabloya bu veriler kaydedilebilir. Sonrasında sanal pos hizmetini verecek banka(lar)
ile bağlantı yapılması konusu ele alınmalıdır. Bu durum için banka(lar) tarafından verilen hizmetler
incelenmeli ve ona göre gerekiyorsa API create veya API consume süreçleri planlanmalı. Sistemin hangi
platformda çalışacağına göre geliştirme dili vs. belirlenmeli. Yine seçilen platforma bağlı olarak hangi
donanımların gerekeceği belirlenmeli. Teknik detaylardan sonra projenin ne kadar adam/saat sürede
tamamlanacağı hesaplanmalı. Mevcut personelin ürün geliştirirken bilmediği ve öğrenme ihtiyacı olan
konular var ise eğitim maliyetleri ve süreleri göz önüne alınmalı. Benzer bir ürün daha önce
geliştirilmediyse Ar-Ge süreçleri hesaplanmalı. Fonksiyonel olan ve olmayan gereksinimler ortaya
konulmalı. Son olarak maliyet hesaplanmalıdır.

2. Analiz (Çözümleme)

Bu aşamada, planlama aşmasında belirlenen ihtiyaçların ayrıntılı bir şekilde anlaşılmasını sağlamak
için sistem gereksinimleri de dahil olmak üzere derinlemesine bir analiz gerçekleştirilir.


İstenen ürünün yapısını tam manasıyla ortaya koyabilmek adına sektör araştırmaları, benzer ürün
analizleri ve hukuksal süreç analizleri yapılır. Yapılan analizler sonucunda ortaya çıkan ihtiyaçlar en ince
detayına kadar belirlenir ve nasıl çözümler sunulacağı hakkında çalışmalar yapılır.

Ürün gereksinimleri net olarak elde edildikten sonra, SRS (Yazılım Gereksinim Analizi Belgesi)
oluşturulur. Bu belgede geliştirilecek olan ürünün amacı ve ortamı detaylı olarak tanımlanır. Amaç,
kapsam, literatür özeti, özgün değer, hedefler ve başarı kriteri, gereksinim analizi, donanım analizi,
yazılım analizi, yazılım geliştirme süreç modeli, modül tanımları, işlevsel model, kullanım senaryoları
(use cases), arayüzler (interfaces), fonksiyonel olmayan gereksinimler (güvenlik, servisler,
entegrasyonlar vb.) tanımlanır. Oluşturulan belge ürün geliştiricileri tarafından tamamen anlaşılmalı ve
müşteri tarafından incelenmeli ve üzerine mutabakata varılmalıdır.

Örnek Kullanım Senaryosu (Use Case)

3. Tasarım

Yazılım projesinin nasıl sürdürüleceğinin tasarlanması bu aşamada yapılır. Bir veritabanı
kullanılacaksa verilerin nasıl tutulacağı ile ilgili bir tasarım yapılmalıdır.

Örnek Veritabanı Tasarımı Diyagramı

Uygulamanın kullanıcılarının kullanacağı bir arayüz tasarlanmalıdır.

Örnek Ön Yüz Tasarımı

Uygulamanın arka planını yönetecek yöneticilerin kullanacağı ayrı bir arayüz tasarlanmalıdır.

Örnek Yönetim Paneli Tasarımı

Yukarıda bahsedilen kısımları planlayabilmek adına hangi modüllerin hazırlanacağı, hazırlanacak
modüllerin özellikleri, yetenekleri gibi kısımlar tasarlanmalıdır. Örneği verilen Kitap Takas
uygulamasında ana kalem olan kitapların sisteme yüklenmesi ve takas edilebilmesi için kategori, yazar,
yayın evi gibi bilgilerin sisteme kaydedilmesi gerekir. Ayrıca sistemi kullanacak üyelerin ve yönetecek
kullanıcıların da sisteme tutulması gerekir.


Bir alt kısımda modüle ait özellikler tasarlanmalıdır. Kitap örneğine geri dönersek Kitabın Adı, Sahibi,
Kategorisi, Yazarı, Basım Tarihi, Yayın Evi, Sayfa Sayısı, ISBN, Kapak Resmi gibi bilgilere ihtiyaç vardır.
Hem veritabanı hem de arayüz kısımlarında bu ihtiyaçları karşılayabilecek şekilde tasarımlar
yapılmalıdır.

Ayrıca bu sistemin bir de adres bilgilerine ihtiyaç duyduğunu düşünelim. Kullanıcıların adreslerini
gelişigüzel eklemelerini engellemek adına sırasıyla kırılım olarak Ülke > Şehir > İlçe > Semt > Mahalle
bilgilerini sisteme kayıtlı tutarak ön tanımlı olarak kullanıcıların hizmetine sunmak gerekir. Fakat yeni bir
mahalle eklendiğinde ne olacak sorusunun cevabı da gerekir. Bunun için yönetim panelinde bir kısım
tasarlanabilir fakat yöneticinin bununla ilgilenmesine gerek olmadan da bir yapı inşa edilebilir mi sorusu
sorulmalıdır. Bu soruya cevap olarak PTT posta kodu sisteminden destek alınarak bir servis yazılabilir
ve bu servis türkiye için güncel adres kırılımlarını PTT’den alarak veritabanına kaydedebilir. Sistemleri
tasarlarken bir numaralı öncelik hata yapma olasılığı yüksek olan kullanıcıların altyapıya müdahalesini
sıfır seviyesine yaklaştırmak olmalıdır.

4. Gerçekleştirme

Bu aşama yazılım projesinin kodlama ve test kısmıdır.
a. Kodlama
Tasarım aşaması tamamlandıktan sonra projenin yapısı hakkındaki kararların hemen hemen
tamamı alınmış olur. Kodlamak, tasarımı hazır olan bir sitemi ihtiyaçlar göz önüne alınarak seçilen
bir yazılım dili kullanılarak koda çevirmektir. Kodlamanın yapılma şekli sonraki aşamalardaki test ve
bakım süreçlerini de doğrudan etkiler. İyi kurgulanmış ve yazılmış kodlar, test ve bakım tarafındaki
maliyetleri azaltır. Yazılım projesi planında test ve bakım maliyeti kodlama maliyetinden çok daha
yüksektir. Bu nedenle, kodlama aşamasında sadelik ve netlik sağlanmalıdır.


Sade ve anlaşılır kod yazmanın belli başlı zorunlu olmayan standartları vardır. Her ne kadar
zorunlu olmasa da bu yazım şekilleri sayesinde kod daha okunur olmaktadır. Bunlara örnek vermek
gerekirse;
i. Tip ve metod değerlerin isimlendirilmesinde Pascal Casing kullanılmalıdır.
• Public class SinifOrnegi
• public MetodOrnegi()
ii. Metod argümanları (parametreleri) ve local değişkenler için Camel Notasyon
kullanılmalıdır. İlk kelimenin ilk harfi küçük bundan sonra devam eden kelimelerin ilk
harfleri büyük olmalı.
• int sayi;
• void MetodOrnegi (int birSayi) {}
iii. Interface isimleri “I” ile başlamalıdır.
• Interface IBenimArayuzum () {}
iv. Sınıf içerisinde yer alan private member değişkenlerin önüne “_” getirilmeli. Geri kalanı
da Pascal Casing’e göre tamamlanmalıdır.
• public class SinifOrnegi { private int _Sayi; }
v. Özel olarak kodlanan Attribute’lar isimlendirilirken sınıf isimi “Attribute” ile bitirilmelidir.
• public class BirAttribute: System.Attribute {}
ve bunlar gibi birçok yazım standardı vardır.
b. Test Aşaması
Yazılımın gerçekleştirme aşamasında her bir modül geliştirildikten sonra ilgili kısım ve
geliştirilen kısmın genele etkisi test edilmelidir. Ayrıca tüm modüller ve fonksiyonlar tamamlandıktan
sonra tekrar genel bir test yapılmalıdır.


Test işlemi gelişigüzel değil bir plan dahilinde yapılmalıdır. Her bir test bir plan dahilinde
yapılmalı ve test sonucu raporlanmalıdır.

Yazılım test uzmanları testlerini Birim Testi (Unit Testing), Entegrasyon Testi (Integration
Testing), Sistem Testi (System Testing) ve Kabul Testi (Acceptance Testing) olmak üzere 4 ana
başlıkta yaparlar.
i. Birim Testi: Bu aşamada uygulamanın en küçük yapı taşları test edilir. Bir işi yapan
fonksiyonlar toplulukları ayrı ayrı görevlerini doğru olarak yerine getiriyor mu kontrolü yapılır.
Birim testi kullanıcı testi gibi algılanmamalıdır. Çünkü kullanıcının yaptığı bir işlem için
birden fazla fonksiyon kullanılabilir. Fonksiyonlar tek başına sorunsuz ama beraber
çalıştıklarında sorun teşkil edebilir. Bu yöntem tekil olarak işin doğru yapılıp yapılmadığını
test etmek için kullanılır.
ii. Entegrasyon Testi: Bu testte farklı fonksiyonlar birleştirilerek, aynı anda çalışma durumları
test edilir. Bu test türünde, veri akışının doğru olup olmadığı test edilir. Birim testinde cevabı
bulunamayan soruyu cevaplar.
iii. Sistem Testi: Entegre testinin bir üst aşamasıdır. entegre fonksiyonların toplu olarak test
edilmesidir diyebiliriz. Bu aşamada yük, performans, güvenilirlik ve güvenlik durumları test
edilir.
iv.Kabul Testi: Bu test sonrasında uygulamanın canlı ortama aktarılabilmesi test edilmektedir.
Gereksinimlere uygun geliştirilip geliştirilmediği kontrol edilir. Kendi içinde, Kullanıcı Kabul
Testi, Operasyonel (Kabul) Test, · Sözleşmeye Uygunluk Testi, Yasal Mevzuata Uygunluk
Testi, Alfa Testi, Beta Testi gibi tipleri vardır.
Testlerin, yazılım yaşam döngüsünün tüm aşamalarında yapılması tavsiye edilmektedir.
Hata ne kadar erken tespit edilirse çözüm süresi ve verdiği hasar o kadar azalır.

5. Bakım

Bir yazılımın bakımı yazılım geliştirme sürecinin son adımıdır. Yazılımlar yapılan bakımlarla yaşar.
Yapılan bakımların doğruluğu da yazılımın ömrünü belirler. Yazılım yaşadığı sürece müşterinin istediği
gereksinimlerin sağlanmasını sürekli hale getirmek adına sürekli bakım yapılması gerekir. Örneğin; bir
fabrikada üretim hattında kullanılan cihazlar vardır. Bunların periyodik (haftalık, aylık yıllık vb.) bakımları
ve değişen şartlara göre de uyarlamaların yapılması gerekir. Yazılım bakım türleri 4 başlıkta
toplanmıştır.
a. Düzeltici Bakım (Corrective Maintanence)
Bu bakım türünde yazılımdaki mevcut hatalar düzeltilir. Test ekibinin tespit ettiği hatalar
geliştirme ekibine iletilir. Geliştirme ekibi problemli kısımları düzelttikten sonra tekrar test edilir.
Bu işlem hiç hata kalmayana kadar tekrar edilir. Örneğin; bir işletim sistemi yayınlandıktan sonra
hataları tespit edilince sürekli durumda güncellemeler veya yeni ek paketler eklenir.
b. İyileştirici Bakım (Perfective Maintenance)
Bu bakım türünde yeni müşteri gereksinimleri üzerine çalışma yapılır. Yeni çıkan sonuçlar aynı
uygulamanın yeni versiyonları olarak ortaya çıkmaktadır. İşletim sistemi örneğini burada da
kullanabiliriz. Bir işletim sistemi çekirdeği sabittir. Fakat değişen ihtiyaçlara göre yeni
versiyonları çıkmaktadır. (Win 7, 8, 8.1,10 vs.)
c. Uyarlanabilen Bakım (Adaptable Maintenance)
Bu bakım türünde müşteri ihtiyaçları yerine altyapı ihtiyaçları değerlidir. Örneğin üretilen
yazılımın arka planında merkez bankasında güncel döviz kurlarını çektiğimizi varsayalım. Eğer
merkez bankası sağladığı bu bilgiyi başka bir yöntemle sağlamaya devam edecekse arka plan
servisimizi buna göre uyarlamamız gerekir.
d. Önleyici Bakım (Preventive Maintenance)
Bu bakım türünde odak noktası performans, verimlilik ve güvenliktir. Uygulamamıza tüm
süreçler gittikten sonra bir Penetration Test yaptırmakta fayda vardır. Bu test sonucuna göre
güvenlik zafiyetleri giderilmelidir. Performans analizi yapılarak sürecin yavaşlamasına neden
olan kısımlar iyileştirilmelidir.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir