Software Development Life Cycle (SDLC);  IT analistlerinin, müsterilerin ihtiyaçlarini karsilayabilecek kaliteli yazilimlar yapabilmek amaciyla, yazilim gelistirme, bakim, onarim ve testlerinin tüm arti ve eksilerini dikkate alarak  bir sistemin olusturulmasinda izledikleri yöntemler bütünüdür. Yani basit bir ifade ile yazilim projeleri uygulanirken bu sürecin yönetilmesidir. Bu sürecin genel olarak asagidaki adimlari içerir;

Ihtiyaçlarin Belirlenmesi:

Bir ihtiyaç dogdugunda ve bu ihtiyaci giderebilecek bir çözüm sunabilmek adina proje müdürleri, analistler, diger yöneticiler vb karar vericiler toplantilar yaparlar ve sonuçta yeni bir projeye baslanir. Bu projeye baslamadan önce gereklilikler çikarilir. Örnegin ; Sistem hangi isleri yapacak? Sistemi kimler kullanacak ? Sistem datayi nasil saklayacak ve isleyecek ? Sistemin çiktilari nasil olacak ? Ne tür teknolojiler kullanilacak ? gibi sistemle ilgili sorulara yanitlar bulunur. Bu sorular daha da detaylandirildikça, sistemin nitelikleri yavas yavas su üstüne çikmaya baslar. Gereksinimler ve nitelikler belirlendikten sonra sistemin tasairmina baslanir.

Sistemin Tasarlanmasi:

Tasarim asamasi gereksinimlerin ardindan yapilmaya baslanir ve tasarimin ihtiyaci duyulan gereksinimleri yerine getirecek bir yapida olmasi gerekir. Bu asamada sistemin niteliklerine odaklanilir ve sistemin mimari yapisi kurgulanir. Sistemin tasarimi esnasinda aslinda bu sistemin ana hatlarinin ve detaylarinin nasil çalisacagina yön verilmis oluyor. Sistem teknik olarak nasil bir platformda yer alacak, iç ve dis birimlerler haberlesmesi nasil olacak , veri yapilari nasi olacak ve sistemin isleyisi hangi süreçleri içerecek gibi mimari detaylara da deginilir. Bu safhada UML bir çok ihtiyaci karsilayabilir.

Sistemin Gelistirilmesi:

Bu adim projenin yapildigi adim olup belki de en uzun süren safhadir. Kodlama bu adimda yazilim uzmanlari tarafindan yapilir. Ihtiyaçlar çikarilirken ve sistem tasarlanirken nerede hangi teknolojilerin veya tekniklerin kullanilacagi önceden belirlenmis olacagindan, yazilim uzmanlari kendilerine verilmis olan proje dökümanlarindan faydalanarak projenin ana hatlarini ve gerekli detaylari anlarlar ve yine dökümanda belirtilmis olan teknolojileri kullanarak sistemi gelistirirler. Bu noktada çesitli yazilim dilleri ve teknolojileri kullanilabilir.

Sistemlerin Entegre Edilmesi ve Testler:

Yazilim projelerinin durumuna göre bu adim çok küçük veya büyük bir süreç olabilir. Burada hem yazilim uzmanlari tarafindan gelistirilen modüller birlestirilir, hem de sistemin dis sistemlerle olan entegrasyonu yapilir. Ayrica bu esnada sistemin testleri yapilir ki önemli süreçlerden birisidir. Bu asamada ilgili proje dökümanlari güncellenir ve ilerde yapilacak olan güncelleme ya da yenilikler için geçmiste kurgulanan sistem hakkinda güncel bilgilerin olmasi saglanir.

Yayinlama ve Bakim:

Sistemin gelistirilmesi tamamlanip, testlerinin tamamlanmasinin ardindan yayinlama süreci baslar. Bu esnada ilgili sistem müsteri ihtiyacini gidermeye yönelik kurulum yapilabilirken, ürün olarak dagitimi da baslanabilir. Bu esnada gerekli kurulum destegi ya da egitimleri verilmesi önemlidir. Sistem kullanimi ile beraber de bakim süreci baslar. Bakim mevcut hatalarin giderilmesi yani sira yeni istenen yeniliklerin karsilanmasini da içerir.

Genel olarak kullanilan SDLC metodlari:

  • Waterfall Model
  • Iterative (Incremental) Model
  • Spiral Model
  • V Model
  • Agile Model

 

Waterfall Model:

Waterfall modeli isminden de anlasilacagi gibi sirali bir akis seklinde ilerleyen bir sürece sahiptir. Bir önceki asamanin çiktilari, bir sonraki asamanin girdileri olurlar.  Genellikle yazilim projelerinde kullanilan metodlarin birisidir.Ancak öncesinde üretim ve insaat sektörlerinde de kullanilmistir. Adimlar süreç islerken diger adima geçmeden önce kendi içerisinde yinelenebilir. Geçmis adimlara geri dönüsü benimsemedigi için daha esnek modellere ihtiyaç duyulmustur.

 

  • Requirement Gathering and analysis: Sistem ile ilgili tüm ihtiyaçlar mümkün oldugunca bu asamada belirlenir ve gereklilik dökümani adi altinda dökümanlastirilir.

  • System Design: Ilk asamada ortaya çikan ihtiyaçlar üzerinde çalisiliarak bir dizayn olusturulur. Bu asama sistemin donanimsal ihtiyaçlarini da ortaya çikarirken bir yandan da sistemin mimarisi belirginlesir.

  • Implementation: Sistem dizaynindaki çiktilar ile küçük birimler halinde, bir sonraki asama ile entegre olacak ilk yazilimlar (units) yapilir. Her bir birim yazilimi kendi içerisinde gelistirilir ve testleri yapilir (unit tests).

  • Integration and Testing: Her bir birimin test ve gelistirmesinden sonra, tüm birimler birlestirilir. Ardindan tüm sistemin testi yapilir.

  • Deployment of system: Ürün testleri yapilmadan önce, sistem kendi çalisacagi ortama aktarilir ve ilk ürün testleri yapilir. Sonrasinda ürün kullanilir hale getirilir.

  • Maintenance: Ürün kullanimda oldugu sürede bazi sorunlar veya ürün gelistirmeye yönelik istekler gelebilir (ki genelde gelir) . Bakim asamasi burada ürünün gelismesini ve daha stabil olmasini saglayan asamadir.

Waterfall modelinin kullaniminin daha uygun oldugu durumlari söyle siralayabiliriz;

  • Ihtiyaçlar çok iyi belirlenmis, açik ve anlasilir biçimde dökümanlastirilmis ise.

  • Ürün tanimi belirgin ve sabit ise.

  • Teknolojisi anlasilir ve degisken degil ise.

  • Ürünü destekleyecek yeterli kaynak ve uzmanlik var ise.

  • Kisa bir proje ise.

Avantajlari;

Projeyi bölümlere ayirmayi ve bu bölümlerin kontrolünü kolaylastirir. Her bir asama için bitis zamanlari belirlenebilir ve ürün adim adim asamalardan sadece bir defa geçirilir. Her bir üretim adiminin sirasi bellidir ve ürünün üretiminde hangi asamada oldugu da bellidir.

Dezanatajlari;

Proje baslandiktan sonra, herhangi bir degisime kapalidir. Geri dönüsü olmamasi nedeni ile dökümantasyonun çok iyi yapilmis ve gelistirmenin dökümana uygun yapilmis olmasi gerekir. Bu yüzden kompleks ve büyük çapli projelere uygun degildir. Ayni zamanda devamli degiskenlik gösteren projeler için de uygun degildir.

 

Iterative Model:

Yazilimin basit bir ihtiyacini karsilamakla baslayip, ilerledikçe daha fazla ihtiyaci karsilayan ve sonunda müsterinin istediklerini karsilar halde yazilimi hazirlar.Model, her bir yenilemede ürüne yeni özellikler katar. Yani her bir döngü, yeni bir versiyon anlamina gelebilir. Yazilim gelistirme süreci içerisinde birde fazla döngü, ayni anda gerçeklesebilir de.

Bu modelde, tüm ihtiyaçlar farkli asamalara (build) bölünür. Her bir döngü tasarim & gelistirme, test ve entegrasyon asamalarini içerir. Tüm bu döngü, sistem gereksinimleri tamamen karsilanincaya kadar devam eder. Modelin basarili olmasinin yolu, her bir döngüde eklenen gelistirmelerin iyice test edilmesi ve bu testlerden onaylanmasindan geçer. Her bir döngüde yapilan testler, bir öncekileri de kapsamalidir.

Iterative (veya Incremental) modeli genelde asagidaki senaryolarda kullanilir;

  • Sistemin ihtiyaçlari açik ve net bir sekilde anlasilir oldugunda.

  • Ana ihtiyaçlar belirtilmis olmalidir, ancak bazi yan ihtiyaçlar sonrada eklenebilirler.

  • Piyasa vb. baskisindan dolayi kisitli zaman oldugunda.

  • Yazilim takiminin hakim olmadigi ve proje süresince ögrenecekleri yeni bir teknoloji kullanildiginda.

  • Projede yeterli kaynaklarin olmamasi durumunda veya ilgili kaynaklarin sonradan projeye dahil olmasi durumunda.

  • Projenin risklerinin veya kazanimlarinin zamanla degisme ihtimali oldugunda.

Avantajlari;

Henüz projenin ilk zamanlarinda ortaya çalisan bir model çikar ve bunun üzerinden olmasi/olmamasi gereken yerler görünebilir. Bu da az bir bütçe/kaynak ile dogru bir proje yapilanmasi saglar. Degiskenlik gösteren ihtiyaçlari karsilamak da kolaydir. Büyük çapli projelerde yönetimi ve risk dagilimini daha kolay hale getirir.

Dezavantajlari;

Sadece büyük ve uzun zaman alan projelere uygundur. Daha fazla kaynak ve yönetimsel efor gerektirir. Ayrica projenin bitis tarihinin bilinmemesi de bir risk olusturur.

Spiral Model:

Spiral model, waterfall ve iterative modelin karisimi gibidir. Gelistirme tarafinda iterative modelin ana fikrini baz alirken, yönetim tarafinda waterfall modelindeki gibi kontrol edilir. Spiral model 4 fazdan meydana gelir;

  • Identification: Spiralin ilk bölümünde is ihtiyaçlarinin belirlenmesi vardir. Sonraki bölümlerde ürüm gelisir ancak bu bölümde sistem, alt sistem ve birim ihtiyaçlari belirlenir. Ayni zamanda burasi sistem analisti ile müsterinin sürekli irtibat halinde oldugu bölümdür.

  • Design: Tasarim fazi, aslinda sprialin ilk bölümünde kavramsal olarak baslamistir. Burada mimari tasarim, modüller arasi mantiksal tasarim ve fiziksel ürün tasarimi yapilarak ürünün son durumu tasarlanmis olur.

  • Construct or Build:  Yapi veya gelistirme fazi. Bu fazda müsteriye sunulacak bir ürün, tasarim ortaya çikar. Müsteriden gelen geri bildirimler dahilinde gelistirmeler devam eder.

  • Evaluation and Risk Analysis:  Risk analizinde ürünün ayirici özellikleri, teknik fizibilitesi, yönetimsel riskleri (gecikme veya maliyet asimi gibi) tahminler ortaya konulur. Buna göre müsteri testlerinden sonra, müsteri yazlimi degerlendirir ve görüslerini bildirir.

Spiral model yaygin kullanilan modellerden birisidir. Hem üretici hem de son kullanici için menfaatler sunar. Asagidaki durumlarda kullanimi uygundur;

  • Bir bütçe limiti oldugunda ve deger tahmininin önemli oldugu durumlarda.

  • Orta-Yüksek dereceli risk içerebilen projelerde.

  • Uzun vadeli projelerde (ekonomik kaygilarin ön planda oldugu durumlarda)

  • Müsterinin isteklerinin net olmadigi durumlarda.

  • Ihtiyaçlarin karmasik ve belirgin olmadigi durumlarda.

  • Yeterli müsteri görüsüne ulasildiktan sonra yeni ürün hattinin olusmasi gerektiginde.

  • Gelistirme asamasinda önemli degisiklikler olabilecegi durumlarda.

Avantajlari;

Proje ile ilgili elementlerin erisilebilir ve bilinebilir oldugu durumlarda projeye eklenebilmelerini saglar. Bu önceki istekler ile örtüsmese de yapilabilir. Bu belirli bir sira ile çok sayida yazilimin ve ürünün yayinlanmasina ve bakimina olanak saglar. Ayrica kullanici ile çabuk iletisim kuruldugundan gelistirme asamasi daha efektif geçer.

Dezavantajlari

Fazlaca otoriter bir yönetim anlayisi gerektirir ve sonsuz bir döngü içerisinde kalinmasina neden olabilir. Bu yüzden degisimin büyüklügü ve içerigi, gelistirme ve ürünlestirme için çok önemlidir. Küçük ve riskli projeler için uygun degildir.

V Model:

V modeli dogrulamali (Verification) veya geçerli (Validation) model olarak da bilinir. V modeli Waterfall modeli ile benzerlikler tasir. Burada da her bir adim kendi içinde disiplinlidir ve bir adim tamamlanmadan diger adima geçilmez. V modelinde gelistirme ve test fazlari birbirine paralel yürütülür. V modelinin bir yaninda dogrulama (Verification) yapilirken diger tarafinda da geçerlilik testleri (Validation) yapilir ve bunlar V nin altinda kodlama (coding) fazi ile birlesir.

Dogrulama (Verification) Fazlari;

  • Business Requirement Analysis: Burasi, müsteriden gelen isteklere göre gelistirme döngüsünün ilk fazidir. Bu faz müsteri ile isteklerinin teyit edilmesini saglar. Burasi iyi yönetilmesi gereken bir yerdir çünkü birçok müsteri ne istediklerini pek iyi bilmezler. Ayrica bu fazda belirlenen isteklere göre test planlamasi (kabul testi durumlari - Acceptance Testing ) da yapilabilir.

  • System Design: Öncelikle ürün ihtiyaçlari açik bir sekilde detaylandirilmalidir. Ayni zamanda yazilimin donanim ile iletisimi gibi detaylar da belirlenirken sistem dizaynina göre test senaryolari da hazirlanir. Önceden bu test senaryolarinin olusturulmasi sonradan yapilacak testler zamaninda zaman kazandiracaktir.

  • Architectural Design: Mimari tasarim fazinda, mimari sartlar anlasilir ve tasarlanir. Genellikle birden fazla teknik yaklasim önerilirken, teknik ve finansal fizibiliteye en uygun karar verilir. Sistem tasarimi modül tasarimi ile devam eder. Burasi yüksek seviyeli tasarim olarak kabul de edilir. 
    Modüllerin birbirleri ile etkilesimi ve veri transferi ve dis dünya ile iletisim açikça ve net bir sekilde bu bölümde kesinlesir. Bu da bu asamada entegrasyon test senaryolarinin da yazilmasini saglar.

  • Module Design: Burada sistemdeki tüm modüller için detayli tasarim uygulanir, burasi düsük seviyeli tasarim olarak kabul edilir. Suna dikkat edilmelidir, modül tasarimlari hem birbirleri ile uyumlu olmali, hem yüksek seviyeli tasarimin kaliplari içerisinde kalmali, hem de dis dünyadaki uygulamalar ile uyumlu olmalidir. Birim testleri, her yazilim sürecinin esas bölümlerindendir ve büyük ölçüde problem bu testlerde giderilir. Dolayisi ile birim testleri bu bölümde senaryo edilebilir.

Geçerlilik (Validation) Fazlari;

  • Unit Testing: Birim testleri modül dizayni asamasinda tasarlanirken bu fazda uygulanir. Birim testleri kod seviyesinde testlerdir ve hatalarin olusmasini erkenden önlerler ancak yine de tüm hatalar birim testlerinde bulunamayabilirler.

  • Integration Testing: Entegrasyon testleri mimari tasarim fazi ile iliskilidir. Entegrasyon testlerinde modüllerin birbirleri ile iletisimi test edilir.

  • System Testing: Sistem testleri, sistem tasarimi ile dogrudan iliskilidir. Sistem testleri, tüm sistemin fonksiyonalitesini test ederken, ayni zamanda dis sistemlerle olan baglantilari da test eder. Birçok yazilimsal ve donanimsal sorun bu asamada çözümlenebilir.

  • Acceptance Testing: Kabul testleri, is ihtiyaçlari analizi ile ilgilidir ve sistemin kendi platformunda (canli ortam) test edilmesini saglar. Kabul testleri ayni zamanda canli ortamdaki harici sistemler ile olan uyumluluk sorunlarini da ortaya çikarir. Ayni zamanda fonksiyonel olmayan sorunlar da (performans sorunlari, güvenlik sorunlari gibi..) ortaya çikarir.

Kodlama (Coding) Fazi;

  • Bu fazda sistemin kendisi, tasarimlarda ve test senaryolarinda uygun görülen yönergelere bagli kalarak gelistirilir. Kodlama için kullanilacak teknoloji önceden karar verilen teknolojidir ve yazilan kodlar tekrar gözden geçirilerek en iyi performans ve saglamlik sartlarinda optimize edilir.

V model kullanimi için uygun olan senaryolar su sekildedir;

  • Is ihtiyaçlari çok iyi tanimlanmis olmali ve dökümanlastirilmis olmali.

  • Ürün tanimi sabit olmali, degiskenlik göstermemeli.

  • Teknoloji degisken olmalai ve proje ekibi tarafindan iyi bilinmeli.

  • Tüm ihtiyaçlar benzersiz ve eksiksiz biçimde tanimlanmis olmali.

  • Kisa süreli proje olmali.

Avantajlari;

Kolaydir ve uygulanabilirdir. Bu nedenle yönetimi de kolay olur.

Dezavantajlari;

Degisimlere kapalidir, bu nedenle günümüz projelerine pek uygun degildir. Büyük ve sürekli deva edem projeler için uygun degildir.

 

Agile Model:

Agile modeli iterative model ve incremental modellerin karisiminin, yürütülebilirlik ve müsteri memnuniyetine odaklanmis halidir. Agile yöntemi, ürünü küçük küçük gelisen parçalara böler ve bu küçük gelisimler döngüsel bir biçimde tekrar eder. Her bir döngü 1 ile 3 hafta rasinda zaman alir ve her bir döngüde projenin bitirilmesi için gerekli ihtiyaçlar tamamlanir. Her bir döngü farkli gruplarin, ayni anda, planlama, analiz, tasarim, kodlama, test gibi projenin farkli asamalarinda birlikte çalismalarini kapsar.

Agile yaklasimi yazilim endüstrisinde uzun zamandir bilinen bir model olsa da, esnekligi ve uygulanabilirligi sayesinde son zamanlarda popüler olmustur. Popüler agile metodlari söyle siralanabilir;

  • Rational Unified Process (1994) : Birlestirilmis süreç, süreçleri daha küçük parçalara bölerek daha efektif bir üretimi hedefler. Böylece bireyler üzerindeki yük daha homojen dagilir.
  • Scrum (1995) : Takim veya takimlardan olusan bir grupta, rollere bölünmüs görevler ve kendine özgü yöntemleri vardir. Örnegin product owner (müsteri), scrum master (proje yöneticisi), gelistiriciler, tasarimcilar gibi takimlar olabilir. Yine 1-3 haftalik süreçler içerisine müsteriye kullanilabilir yazilimlar/ürünler/fonksiyonlar sunulur.
  • Crystal Clear : Kristal yöntemi, küçük takimlardan olusan yazilim ekibi ile ve hizli ve kullanilabilir fonksiyonlar sunmayi hedefler. Küçük çapli projelere yöneliktir.
  • Extreme Programming (1996) : Uç programlama, degiskenlik gösteren projelerde kullanimi uygundur. Tüm ekip projenin gelistirilmesine her asamada katkida bulunurken, bir is bazen ayni anda iki kisinin gözünden yapilir.
  • Adaptive Software Development : Adaptif gelistirme, degisen süreçlere uyum saglayan, görev odakli, takvimi olan ve riskli projelerde kullanimi hedefler. Öngörü döngüsü, ekiplerin/kisilerin iyi iletisimi ve ögrenebilen bir ekip modeli ile biline waterfall modelinin yerini alir.
  • Feature Driven Development (1997) : Özellikli gelistirme, belirli zaman zarfinda, ise yarar ve çalisan özellikleri müsteriye sunmayi hedefler. 5 ana aktivitede olusan döngüsel modeldedir.
  • Dynamic Systems Development Method (DSDM) (1995) : Sürekli kullanici/müsteri iliskisi dahilinde devam eden projelerde kullanilabilir.

Agile manifestosu (2001) na göre;

  • Kisisel motivasyon önemlidir.
  • Yazilim çalisir ve stabil olmalidir
  • Müsteri / Kullanici ile sürekli diyalog halinde olunmalidir, bu da baslangiçta belirlenemeyen hususlarin belirlenmesinde önemli rol oynar.
  • Degisime çabuk ayak uydurmalidir.

Avantajlari;

Yazilim gelistirmede gerçekçi bir ortam sunar. Degisime hizli uyum saglar, fazla kuralci olmamasi nedeniyle dökümantasyonu kolaydir. Takimlarin paralel çalismasina uygundur, ve az planlama ile yönetimi kolaydir.

Dezavantajlari;

Esnekliginden dolayi risklidir. Mutlaka bir agile liderine ihtiyaç duyar. Müsteriye çok baglidir ve eger müsteri ekibi yanlis yönlendirir ise, ekipte performans kaybina ve motivasyonsuzluga yol açar. Fazla dökümantasyon içermedigi için ekip arasi iletisim çok önemlidir.

 

If you like this, follow my RSS channel!