Makale Özeti

Application Lifecycle Management konusundaki yazılarımıza Waterfall ve Spiral metodolojilerini anlattığımız makalemiz ile devam ediyoruz.

Makale

Application Lifecycle Management konusundaki yazılarımıza yazılım metodolojileri ile devam ediyoruz.

İlk yazımızda, yazılım sürecinin asamalarindan bahsetmiştik. Yazılım metodolojileri ise bu süreçlerin hangilerinin, nasıl ele alındığının belirlendiği farklı yazılım geliştirme yöntemleridir.

Yazılım metodolojilerinin amacı ALM in amacı ile bütünlük gösterir ama; yazılın metodolojileri ALM'nin daha küçük bir parçası ya da alt kumesidir.

Bu yazı da iki metodoloji üzerinde duracağız, Waterfall ve Spiral.

Waterfall

İyi kotu yazılım süreçleri hakkında kulak dolgunluğu olan herkes Waterfall (Şelale) modelini duymuştur. Bu metodoloji ortaya atılan ilk yazılım geliştirme metodolojisiydi ve önerildiği 1970 yılında adı bile bu değildi. 1970'li yıllarda Winston W. Royce tarafından yazılan bir makalede oluşturulan Waterfall modeli yıllarca birçok firma ve kurum tarafından kullanıldı. Oysa ki Royce'un makalede kurguladığı örnek hatalıydı ve çalışmıyordu; ancak insanlar bunu umursamadı ve projelerinde kullanmaya başladı.

Waterfall modelinin bu adı almasının sebebi ise ardışık aşamalardan oluşması, aynı yukarıdan aşağıya doğru akan bir şelale gibi. Waterfall daki yazılım sürecimiz, akan şelaledeki su gibi düşünülebilir; suyun aşağı doğru aktığı gibi sürecimizde belli aşamaları takip ederek sonuca (aşağı) doğru akar gider.

Waterfall metodolojisi aşağıdaki gibi şematize edilmekte.

Royce yazdığı makalesinde 7 süreçten bahsediyordu,

  1. Requirement Specification (Gereksinim analizi)
  2. Design (Teknik Tasarım)
  3. Construction (Yazılım Geliştirme)
  4. Integration (Entegrasyon)
  5. Testing and debugging (Test ve doğrulama)
  6. Installation (Canlı hayata geçiş)
  7. Maintenance (Bakım)

Şayet ilk yazıyı okuduysanız yukarıda adı geçen yedi süreçten altısından bahsetmiştik standar yazılım süreçlerinde; bundan sonraki birçok metodolojide de benzer bir durum olacak; çünkü yıllardır edinilen deneyimler hep aynı şeyleri işaret ediyor. Biraz daha detaylı bakarsak,

1. Requirement Specification (Gereksinim analizi): Bu süreç müşteriden ihtiyaçların alınıp analizin yapılması sürecidir. Daha fazla bilgi için tıklayınız.

2. Design (Teknik Tasarım): Alınan analize uygun olarak sistem mimarisinin ve yapısının çıkartılması sürecidir. Daha fazla bilgi için tıklayınız.

3. Construction (Yazılım Geliştirme): Alınan analiz ve oluşturulan mimariye uygun olarak kod yazımı sürecidir. Daha fazla bilgi için tıklayınız.

4. Integration (Entegrasyon): Takdir edersiniz ki bir uygulama genellikle birden fazla bileşen ve sistemden oluşur. Bazen bir web servis, bazen bir web uygulaması, bazen de windows servisi. Uygulama canlı hayata çıktığı zaman tüm bu farklı bir bileşenler beraber çalışacağı için öncelikle hepsinin bir araya getirilmesi gerekmektedir. Bu aşama yazılım geliştirme aşamasnda geliştirilen farklı bileşen ve yapıların birbirine entegre edilmesi ve bir sistem olarak test edilmesi aşamasıdır.

5. Testing and debugging (Test ve doğrulama): Bu süreçte geliştirmesi bitirilen yazılım test edilir; zaten waterfall metodolojisinin önemli bir eksikliği de budur. Eğer test süreci sadece yazılım bittikten sonra uygulanırsa ciddi sorunlarla karşılaşma ihtimali yüksektir. Şöyle düşünelim, 6 ay veya 12 ay boyunca yazılım geliştirilmiş ve sadece geliştiriciler tarafından yapılan yüzeysel testler ile geliştirmeler bitirilmiş. Tüm iş bittikten sonra da yazılım asıl test sürecine alınmış ve o güne kadar fark edilmemiş birçok ciddi yapısal bozukluklar ortaya çıkmış. Bu durumda ne olacak, çok basit hesaplanmayan birçok efor ve maliyet.

Test sürecinin nasıl yönetileceğini daha önceki makalemizde ele almıştık; ancak waterfall modelinde bir süreç tamamlanmadan bir sonrakine geçilmez yani yazılım geliştirilirken test aynı anda yürütülemez. Ayrıca nasıl bir şelalede su yukarı akmayacaksa, waterfall metodolojisinde de testten tekrar yazılım geliştirme veya teknik tasarım sürecine dönülmez.

6. Installation (Canlı hayata geçiş): Bu süreçte ise sağ salim yazılımı tamamlanmış ve testlerden geçmiş yazılımın canlı hayata alımı yapılmaktadır. Daha fazla bilgi için tıklayınız.

7. Maintenance (Bakım): Bakım süreci ise uygulama canlı hayatta iken verilecek destek ve güncelleme çalışmalarını kapsamaktadır. Daha fazla bilgi için tıklayınız.

Görüldüğü üzere temel süreçler hep aynı, ancak Waterfall metodolojisinin sıkıntılı noktası süreçler arasında zıplama yapılamaması veya geri gidilememesi. Başka bir sıkıntı da dikkat ettiyseniz müşteriden gelebilecek değişiklik isteklerini yönetebilecek bir süreç yok Waterfall'da. Yani müşteriden yazılım sürecinin ortasında gelebilecek bir değişiklik isteği, şayet alt yapıyı toptan değiştirebilecek birşeyse ciddi bir sorunla karşı karşıyasınız demektir.

Bu olumsuzluklara rağmen Waterfall yıllar boyunca özellikle Amerika da Savunma Bakanlığı ve Nasa projelerinde yıllarca kullanıldı, şimdi ise bu kurumlardaki yazılım süreçleri Agile veya Scrum gibi daha güncel süreçlerle değiştirilmektedir.

Waterfall, şayet yazılımda çok birşey değişmeyecek ise, ihtiyaçlar açık ve çok kompleks değilse, yazılım ekibi çok kaliteli ve testte öngörülmedik bir durum ortaya çıkmasına sebep olmayacak durumda ise kullanılabilir. Tabi ki böyle ideal bir durum ne yazık ki pek gerçekçi değildir, Ken Schewaber'a (Agile Alliance ve Scrum'ın fikir babası) göre bir yazılım projesindeki ihtiyaçların %35'i değişmektedir. Böyle bir rakam ise ciddi bir riski teşkil etmektedir.

Ayrıca, Steve McConnel'ın hesaplarına göre "bir gereksinim probleminin yazılım geliştirme veya bakım aşamasına kadar tespit edilememesi, bu problemin gereksinim analizi sırasında fark edilmesine göre 50 ile 200 kat daha fazla maliyete sebep oluyor". Bu durumda Waterfall metodolojisinin her sürecinin tam doğruluk ile yapılması zorunluluğunu açıklıyor.

Spiral

Spiral modeli ilk olarak 1988 yılında Barry Boehm tarafından tanımlanmıştır. Spiral modeli, Waterfall modelinden farklı olarak belli ve düz bir akıştan ziyade iteratif bir yazılım modelidir.Tabi ki Spiral ilk iteratif model değildir; ancak neden iteratif bir süreç yürütüldüğünü açıkça gösteren ilk modeldir.

Spiral modelinde iteratiflikten kasıt ise, her bir iterasyon bir tasarım hedefi ile başlar, standart yazılım süreçlerinin bazı aşamalarını geçip müşteri yorumu ve görüşü ile tamamlanır. Her bir iterasyonda amaç iş değerini (businnes value) yakalamak olup, bir önceki iterasyonun sonuçlarından faydalanarak gelişen bir yapıda devam eder.

Basitçe Scrum modelinin aşamaları aşağıdaki gibidir.

1. Requirement Analysis (Gereksinim analizi): Bu süreç müşteriden ihtiyaçların alınıp analizin yapılması sürecidir. Daha fazla bilgi için tıklayınız.

2. Preliminary Design (Taslak Tasarım): Bu süreçte alınan analize göre taslak tasarım yapılır.

3. First Prototype (İlk prototip): Oluşturulan taslak tasarıma göre yazılımın ilk prototipi oluşturulur. Tabi bu prototip sadece müşteriye yazılım karakteriği ve çözüme yaklaşımı konusunda fikir vermek için geliştirilen basit bir prototiptir.

4. Second Prototype (İkinci prototip): İkinci prototip aşağıdaki dört adımın sonunda oluşturulur.

  1. İlk prototipin güçlü ve zayıf yanları ve risklerinin değerlendirilmesi
  2. İkinci prototip için tekrar gereksinim analizinin yürütülmesi
  3. Tekrarlanan gereksinim analizi sonucuna göre tekrar teknik tasarım yapılması
  4. Oluşan teknik tasarıma göre yazılımın geliştirilmesi ve test edilmesi
  5. Müşteri ile oluşan prototipin değerlendirilmesi. Bu aşamada eğer müşteri gidişattan memnun değilse daha en başta proje iptal edilebilir, böylece boşa gitme ihtimali olan birçok maliyetten daha başta kurtulunur. Şayet müşteri gidişattan memnunsa sürece devam edilir.

5. n. Prototype (n. Prototip): Spiral modelde süreç bu şekilde iteratif adımlarla devam eder. Her bir adımda yukarıdaki beş adım uygulanır.

6. Her prototip sonunda yapılan müşteri değerlendirmeleri, müşteri oluşan yapıdan memnun olana kadar devam eder. Ne zaman müşteri ihtiyaçlarının karşılandığını düşünür ve sonuçtan tatmin olursa nihai ürün için çalışılmaya başlanır.

7. Nihai ürün, onaylanan son prototip üzerinde şekillenir ve canlı hayata alınır.

Görüldüğü gibi Spiral modelde açık bir değişiklik yönetimi, kapsamlı bir test süreci yoktur. Çünkü her iterasyonda müşteriden alınan analiz ile değişiklik istekleri toplanmış olur ve tekrar tekrar test edilmiş olur.

Spiral model, küçük kapsamlı projeler için uygun değildir ve büyük projelerde kullanılabilir. Örneğin Amerikan ordusunun geliştirdiği Future Combat System programı Spiral model ile geliştirilmiştir. [kaynak]

Spiral model aşağıdaki şekilde şematize edilmektedir.

 

Spiral model ile bu yazımızın sonuna geliyoruz, sonraki yazılarımızda diğer yazılım metodolojilerine devam edeceğiz. Bu yazıyı yazarken ağırlıklı olarak Joachim Rossberg'in Pro Visual Studio Team System Application Lifecycle Management kitabından faydalandım.

Pro Visual Studio Team System Application Lifecycle Management

Future Combat System

Application Lifecycle Management (ALM) Makalesi