YAZILIM SÜREÇLERI
Yazılım Geliştirme Modelleri
İlk yazımdaki proje farklılıkları, sizin farklı farklı modeller kullanmanızı gerektirir. En bilenenleri Waterfall, Incremental, Unfied Process ve Agile olan bu modellerin ne gibi özellikleri olduğunu anlatmaya çalışacağım.
Bir önceki yazımda Neden Farklı farklı Yazılım Geliştirme Yaşam Döngü Modellerinin olduğunu sorgulamıştım. Bir sonraki yazımda da bu geliştirmeyi oluşturan ana fazlardan bahsetmiştim.
Bu fazların sırası, tekrar edilme sayısı , uzunlukları ve ne kadar üstüne düşüldüklerine göre bu modeller değişir. Daha önceden de bahsettiğim gibi Askeri yazılım, Enterprise yazılım, Mobil yazılım ile SaaS yazılım geliştirme arasında oluşacak farklardan dolayı seçeceğimiz modellerde farklı olacaktır.
Geliştirme modellerini sıralarsak;
- Code & Fix
- Waterfall
- Waterfall Iterative
- V Model
- Iterative
- Incremental
- Evolutionary
- Spiral
- Rational Unified Process
- Agile (XP, Kanban, Scrum)
1. Code & Fix Model
Genelde bir konuda araştırma yapıyorsan, veya 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.
2. Waterfall (Şelale) Modeli
Analiz, Tasarım, Gerçekleştirim, Kodlama, Test, Entegrasyon … adımların sıra ile işletilerek bitirilmesi sürecidir. Geri dönülmemesi için her fazın hakkını vererek doğru bir şekilde yapılması gerekir. Eski askeri yazılımlar ve projelerde bu model oldukça sık kullanılmıştır.
Ama sonradan bu modelin işletiminin çok da basit olmadığı, analizin süreç içerisinde değişebildiği, kodlama sırasında tasarımın değiştiği farkedilmiş bunun yerine daha uygulanabilir modeller aranmaya başlanmıştır.
Bunun yöntemide bu safhalara yeri geldikçe geri dönebildikleri fazların tekrar tekrar üzerinden geçebildikleri sistemler oluşturabilmekti.
Tabi bundaki bir diğer etkende eskiden programların yazılma, işletilme maliyetleri fazlaydı. Yani çalıştığı zaman sorunsuz çalışacak sistemler üretmek çok kritikti. Bunun için baştan analizlerin çok çok iyi yapılması gerekiyorki Uzay/Uydu aracında kullanılacak program, Askeri Cihaz/Füze/Teçhizat kullanılacak program vb için böyle tekrar safhalı yazılım geliştirme mümkün değildi.
İlerleyen süreçte, teknolojiyle yazılımın hayatımızın her alanında kullanılmasıyla, değişen ihtiyaçlar ve koşullar sayesinde farklı farklı yazılım geliştirme modelleride ortaya çıkmıştır.
3. 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.
4. V Modeli
Waterfall Modeline Verification(Doğrulama) ve Validation(Onaylama) mekanizmasının eklenmiş halidir. Aslında fazları anlattığımda gerçekleştirme fazı içerisinde Kodlama ve Test aşamalarını içerir. Ve bu test türlerinin Unit, Integration, Regression, Smoke, Beta, System, Stress, Performance Testing olduğundan bahsetmiştim. 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.
5. 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.
6. 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 açıdan Bu gereksinimi karşılayan projeyi incremental model ile geliştirebilirsiniz.
Bu 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.
7. 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)
8. 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.
Spiral Modelleme ürünü bir salyongoz kabuğu gibi giderek üstüne büyüyen bir geliştirme sistemi olarak görebilirsiniz.
Risk Analizi → Prototype1 → Operasyon Kapsamı → RQTS Plan → Risk Analizi → Prototype2 → Emulations → Software RQTS → Gereksinim Doğrulama → Geliştirme Planı → Risk Analizi → Prototype3 → Model Yapısını Oluşturma → Tasarım → Tasarım Doğrulama ve Onaylama → Entegrasyon ve Test Planı → Risk Analizi → Operasyonel Prototype → Benchmarks. → Detaylı Tasarım → Kod → Unit Test → Entegrasyon Testi → Kabul Testi → ..
9. 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.
9 Agile(Çevik) Model
Neden çevik demişler ?
Benim çeviklikten anladığım müşterinin karşısına en hızlı sürede ürünü çıkarmak, üründe bir değişiklik ihtiyacı olduğunda veya hata çıktığında bunu en kısa sürede en kalite şekilde çözebilme modelidir.
Bunun için neler gereklidir. Bana göre :)
- Yukarıda bahsettiğim yöntemlerden Evolutionary bu yapı için uygundur. Çünkü analiz çalışmasına müşteri, iş uzmanı, ürün sahibi, ve geliştirici gibi ekibin topluca bu aşamaya katılması uygulamadan istenenleri gereksinim olarak doğru tariflemeyi sağlar.
- Standup meetings(Günlük toplantılar): Ekibin en iyi şekilde senkron olmasını, birbirini bekleyen veya problem olan bir kısmın olup olmadığını her gün kontrol etme imkanı sunar.
- İterasyon kavramı : Ürünü parçalara bölüp bu parçaların müşteri önüne çıkması, bu aşama da iterasyon planlaması, gözden geçirilmesi ve işleyişinin(restrospective) değerlendirilmesi çok önemlidir. Bu işlerin ardı ardına hızlı bir şekilde işletilebilmesi
- Sürekli Entegrasyon ve Canlıya Gönderebilme: Geliştirilen ürün parçalarının sürekli otomatik build/compile edilmesi, ünit testlerinin çalıştırılması, entegre edilmesi, entegrasyon testlerinin çalışması ve ardından hızlı bir şekilde canlıya müşterinin karşısına çıkarabilme yeteneğidir.
- Kanban Board: İşleri hangi safhada olduğunu takip edebildiğiniz tahta.
- Refactoring, Pair Programming, Unit Test, Code Analyser: Kodunuzun kalitesini arttırmak için kötü gördüğünüz kısımlarda iyileştirmeler(refactoring) çalışmaları yapabilirsiniz. Pair programming ile kod bir başka kişinin gözünden de yazılırken kontrolünü sağlatıp, unit test ve kod analizi ile kodun doğru işler yapıp yapmadığını test edebilirsiniz.
- Kaynak kod yönetimi ve sürüm yönetimi: Kaynak kod dağıtımı ve sürüm yönetimini doğru şekilde gerçekleştirebilirseniz aynı kod yapısı üzerinde birbiriniz ile paralel kod geliştirebilme imkanı , ayrı dallar üzerinden hata giderme veya yeni feature özellik geliştirme işlemlerini gerçekleştirebilirsiniz.
Çevik modeli oluşturanlara göre ise
Manifesto
https://agilemanifesto.org/iso/tr/manifesto.html
12 Prensip
https://agilemanifesto.org/iso/tr/principles.html
Çevik yazılımı baz almış bazı geliştirme metodları aşağıda listeledim. Bu konulara bir diğer yazımda okuyabilirsiniz. (Kanban, XP, Scrum Arasındaki Farklar)
- Kanban
- Scrum
- XP (Extreme programming)
Referanslar
- Agile’s 3 categories: Iterative, Incremental, and Evolutionary
- Spiral Model
- Rational Unified Process from Wikipedia
- Agile Manifesto
Okumaya Devam Et 😃
Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.
