Yazılım geliştirme modelleri nelerdir?
Yazılım geliştirme yaşam döngüsü (SDLC) modelleri, yazılım geliştirmenin karmaşık ve zorlu süreçlerini iyileştirmeyi hedefler.
Bir yazılım projesinin kalitesi, zaman çerçeveleri, bütçesi ve müşterilerin beklentilerini karşılama hedefi yazılım geliştirme sürecinde seçilen modele bağlı olarak değişir.
Günümüzde kullanılan yaklaşık 50’den fazla SDLC modeli vardır. Bu modellerin her birinin belirli bir yazılım projesi veya ekipler için avantajları ve dezavantajlarını vardır. Bu blog yazısında ise, modeller arasında en popüler ve en sık kullanılan modelleri karşılaştırdık.
Her yazılım sürecinin kendi içerisinde yaşadığı iş yaşam döngüleri ve proses süreçleri vardır.
Yazılım geliştirme süreçlerinde birçok model olmasına rağmen, bu süreçlerde öncelikle ihtiyaçların ve fırsatların tanımlanması gereklidir. Tanımlanma sonrası fizibilite çalışması yapılarak ihtiyaçların analizi ortaya çıkarılmalıdır. Sonraki aşamada uygulamaya geçilerek test edilir.
Yazılım projelerinin kalitesi ve bütçesi büyük ölçüde seçilen modele bağlıdır. En popüler SDLC metodolojilerinin artı ve eksilerine göz atalım
Yazılım Geliştirme Süreci Modelleri
Waterfall (Şelale) Modeli
Waterfall modeli, yapılandırılmış SDLC metodolojileri arasında en eskisi ve en basitidir.
Bu modelde, her aşama, bir önceki aşamadan gelen bilgilere dayanır ve kendi proje planına sahiptir. Ancak gecikme durumu tüm proje zaman çizelgesini karıştırabilir.
Code & Fix Model
Code & Fix model, bir konu üzerine araştırma yapma durumu ve bir konuyu yeni öğreniyorsan veya belli bir problemi çözmeye çalışıyorsan kullanacağın en basit yöntem, kodla ve düzelt modelini kullanmak olacaktır. En basit ürün geliştirme (Cowboy Coding) olarak adlandırılan bu modelde en kısa sürede prototipleyerek sonuca gitme hedeflenir. Planlama, Analiz yapma vs kısımlar ile çok vakit kaybetmeden hemen ana problem üzerine odaklanılarak sonuca gitme hedeflenir.
Waterfall Iterative Model
Waterfall Modelinde tüm fazlar tamamlandıktan sonra sistemin düzgün çalışmadığını farkettiğimiz zaman sorunun nerden kaynaklandığını anlayıp o faza dönüp sonraki fazların ardı sıra işletildiği modeldir. Örneğin kod geliştirme aşamasında bir hata yapıldıysa bu faza dönüp, bu fazdaki hatanın düzeltilip diğer fazlar işletilir. En kötü durum Analiz’in yanlış yapılması olacaktır. Analiz fazına gidip bu aşamadaki analizlerin tekrar yapılması, buna göre tasarımın değişmesi , ardından kodlama, test, entegrasyon hepsinin değişmesi gerekecektir.
V Modeli
Waterfall Modeline Verification(Doğrulama) ve Validation(Onaylama) mekanizmasının eklenmiş halidir. Aslında bu testlerin hepsi gerçekleştirim değil diğer fazlarıda içerecek teslerdir. Amaç her aşamanın karşısında ve doğrulama ve onaylama mekanizmalarını koyarak sistemin düzgün ve kalite çalıştığından emin olarak ilerlediğiniz geliştirme modelidir.
V Model, analiz sonucunda sistemi tepeden aşağıya doğru parçaladığımız ve tasarladığımız sonrasında da gerçekleştirme sırasında sistemi toparladığımız bir yapı olduğunu farketmiş ve bu toparlama sırasının her aşamanın karşısına onun ile ilgili doğrulama ve onaylama mekanizmasını koymuştur.
- Unit Test geçen Kodlarınız başarılı çalışıyor demektir.
- Entegrasyon Testi başarılıysa Modül ve Mimari Tasarımınız doğrudur.
- Sistem Testlerinden geçiyorsanız Sistem tasarımınız doğrudur.
- En son olarak müşteri kabul testlerinden geçiyorsanız Gereksinim analizini doğru yaptınız anlamına gelir.
Iterative Model
Projenin öncesinde iş analistleri ve ürün yöneticileri gerekli analizleri, toplantıları vb yaparak gereksinimleri çıkarır. Bu tamamlandıktan sonra Proje yöneticisi tarafından iş belli önceliklere göre birden fazla cycle/döngü halinde geliştirilir, en son tüm gereksinimlerin gerçekleştirilmesi tamamlandıktan sonra ürün müşterinin önüne çıkarılır.
Bundan dolayı her döngü sonrasında çalışabilir bir ürün çıktısı olmadığı için bu döngülerde önce aşağıdaki kısımlar geliştirilebilir
- riskli bölgeler geliştirilebilir
- altyapı çalışmaları yapılıp ( güvenlik, yetklilendirme, doğrulama, ui altyapısı, backend mimarisi, frontend-backend iletişimi ,CI/CD, testing)
- tüm kodlar tarafından ortak kullanılabilecek kütüphanelerin geliştirimi
daha sonrada bunlar üzerinde müşterinin istediği gereksinimler doğrultusunda uygulama yetenekleri eklenebilir.
Incremental Model
Iterative Modeldeki gibi iş Analistleri ve ürün Yöneticisi daha önceden gereksinimleri hazırlar ve yine belli döngüler ile projeyi geliştirmeniz gerekir ama burda bir fark bu döngülerin sonundaki çıktıların çalışan çıktılarının olması ve bunun müşteri tarafından kullanılabilmesi gerekir.
Proje yöneticisine işi çalışabilen parçalara/modüllere ayırabilme zorunluluğu getirir. Bu gereksinimi karşılayan projeyi incremental model ile geliştirebilirsiniz.
Sizin tüm sistemin tasarımını yapmanız gerekmeden kodlamaya, teste ve canlı ortama kurmaya götürecek ve müşteri ile daha kısa zaman içerisi iletişim kurup geri dönüşler almanızı sağlayacaktır.
Bu modelin başarısı iterasyonlarda bölünen parçaların birbirinden olabildiğince ayrı/soyut olması ve birbirleri ile entegrasyon ihtiyaçlarının az olması sayesinde olur.
Aksi durum yani parçaların birbiri ile çok ilişkili olması sonraki iterasyonlardaki tasarımların bir önceki iterasyondaki tasarımı etkilemesi durumunda bu model waterfall modelinden daha maliyetli bir hale gelmiş olur.
Evolutionary Model
Iterative model’ de işleri parçalayarak (tasarım, kodlama, test) aşamalarını birden fazla dönerek bu bölgede oluşabilecek mühendislik problemlerini/hatalarının risklerini biraz olsun azaltmış olduk.
- Mühendislerin tüm proje gereksinimlerine göre her şeyin tasarımını yapıp sonradan kodlamaya geçince bu tasarımın aynen kullanılabilmesi oldukça zordur. Tasarımcı ekibin çok çok deneyimli olması ve kodun nasıl oluşturulacağını bilmesi gerekir.
- Aynı şey kodlama yapılırken de geçerli, kodlamayı bitirdik artık hiç hata çıkmayacak ciddi kod değişiklikleri yapmayacağız demek oldukça zordur.
Incremental model’ de müşterinin ürünün hepsi tamamlandıktan sonra test edip geribildirim vermesi müşteriyi sürece oldukça geç dahil etmek sonuçta müşteri istediğim bu değildi demesi yerine ara çıktılar ile işlerin doğru gittiğinin onayının alınması oldukça önemlidir. Bu modelin en önemli olayı müşteriyi geliştirmeye dahil etmelidir.
Evolutionary model analiz aşamasının hazır halde geliştirici ekibe gelmesi bazı durumlarda ürün kalitesini olumsuz şekilde etkiler. Analizi bu süreçlerin bir parçası olarak geliştirme ekibi ile yapılması ,
- gereksinimlerin geliştirici ekip tarafından daha iyi anlaşılması
- geliştirmenin çok zor olacağı gereksinimler yerine daha ayağı yere basan gereksinimlerin ortaya çıkmasını sağlar. (Burda amaç gereksinimi yapmaktan kaçmak değil. Ürün sahibi, geliştirici ve iş analistlerinin ortak bir şekilde analizde yer almasıdır)
Spiral Model
Büyük projelerde planlama ve gereksinim analizini düzgün bir şekilde yapabilmeniz çok zordur çünkü karşınıza bilmediğiniz bir çok risk çıkabilir. İşte spiral model bu riskleri baz alarak bir model geliştirmiştir. Amacı riski seviye seviye azaltarak projenin başarılı bir şekilde tamamlanmasını sağlamaktır.
Risk Analizi ve Yönetimi önceden bahsettiğim Waterfall modelleri içerisinde bu kadar detaylı ele alınıp incelenmemişti. Ama diyelim ki;
- projenin specleri çok belli değil.
- gereksinimler tam olarak ortaya çıkarılamamış
- entegre olunacak sistemler yeni geliştiriliyor veya belirsiz bir sürü konu var
- vb..
olduğunda aynı döngü risklerin azaltılarak projenin geliştirimesi hedeflenir. Buradaki fazlar
- Hedeflerin Belirlenmesi ve Alternatif Çözüm Yollarının Bulunması: Bu aşamada müşteriden elde edilen gereksinimler sonucunda hedefler belirlenir ve bu hedeflere göre çözüm önerileri üretilir.
- Çözüm Yolu Seçilir ve Risk Ortadan Kaldırılır: Bu aşamada çözüm yolları değerlendirilir ve en iyi çözüm yolu belirlenip bu konuda prototip geliştirilir.
- Ürünün Bir Sonraki Aşaması için Geliştirme Yapılır:Bu aşamada bu bulunan çözüm yoluna göre geliştirme ve testleri yapılır ve ürün bir sonraki aşamaya hazırlanır.
- Bir Sonraki Faz Planlanır: Bu aşamada bir sonraki fazın planlaması yapılır. Operasyonel planlamalar, geliştirme planlamaları, entegrasyon ve test planlaması gibi.
Rational Unified Process
Rational Software firması tarafından geliştiren bu process yapısı Iterative Geliştirme modeli üzerine kurulmuştur.
Bu modeldeki fazlar bizim bahsettiğimiz fazlardan farklıdır; İlerleyen zaman üzerindeki zaman aralıkları üzerinden fazlar belirtilmiştir.
Inception(Başlangıç) I1: Projenin başlangıcında en fazla iş modelinin ortaya çıkarılması ve gereksinimlerin belirlenmesidir. Bu aşamada Analiz & Tasarım ve diğer Kodlama, Test ve Deploy işleri ile hiç uğraşılmaz.
Eloboration (Detaylandırma) E1,E2: Eldeki iş modelini , analiz ve tasarımınızı detaylandırdığınız zaman aralığıdır. Bu aşamada kodlama azda olsa başlar diğer işler çok çok az üzerinde durulur.
Construction (İnşaa etmek, Oluşturmak) C1,C2,C3 ve C4: Üründe en fazla kodlama, test ve deploy işlemlerinin arttığı kısımdır. Az da olsa işlerin ters gittiği kısımlarda tasarım ve analize geriye dönülerek düzeltmeler yapılabilir.
Transition (Geçiş) T1, T2: Ürünün müşteriye aktarılması aşamasıdır. Beta Tesleri ile sistem müşterinin isteklerine uyup uymadığı test edilir. Aynı zamanda kullanıcı, bakım ekiplerine eğitimlerin verilmesini içerir.
Agile(Çevik) Model
Çevik model, ürünü döngülere bölerek hızlı bir şekilde çalışan bir ürün sunar ve çok gerçekçi bir geliştirme yaklaşımı olarak kabul edilir. Model, her biri önceki sürümden küçük, artımlı değişiklikler içeren devam eden sürümler üretir. Her yinelemede ürün test edilir.
Bu model, müşteriler, geliştiriciler ve testçiler proje boyunca birlikte çalıştıkları için etkileşimi vurgular. Ancak bu model büyük ölçüde müşteri etkileşimine bağlı olduğundan, müşteri gitmek istediği yönde net değilse proje yanlış yöne gidebilir.
