Şelale Modeli (Waterfall Model)

Yazan : Şadi Evren ŞEKER

Şelale modeli, yazılım geliştirme sürecinin yönetimi için kullanılan modellerden birisidir. Model basitçe bir şelalenin dökülmesine benzer şekilde yazılım geliştirme sürecinin adımları arasındaki geçişi modellemektedir. Bu açıdan arka arkaya devam eden aşamalardan oluşan bir süreç olarak görülebilir.

Temelde bu aşamalar 4 ana grupta toplanır.

Yazılım mühendisliğindeki diğer modellere temel teşkil eden bu modelde yukarıdaki aşamalar sırasıyla izlenir. Aşamalar arası geçişleri oldukça sıkı olan bu modelde geri dönüşler oldukça maliyetli olmaktadır.

Buna göre ilk aşamada sistemin tahlili yapılır ve uygulanmak istenen yapı tam olarak ortaya konulur. Bu tahlil aşamasından sonra SRS (Software requirements specifications , yazılım ihtiyaç özellikleri) ismi verilen bir doküman ve bu dokümanla birlikte bir tahlil raporu (analiz raporu) çıkarılır.

Sonra bu tahlil ışığında bir tasmim (tasarım) yapılır ve çözüm yolları ortaya konulur.  Tasmim aşaması sonunda da SDD (Software design document, tasmimname, yazılım tasarım dokümanı) adı verilen bir doküman hazırlanır.

İsteklerin ve çözümlerinin dokümantasyonunun ardından uygulamaya geçilir ve bu çözümler tatbik edilir. Bu aşamadan sonra sistem somut (müşahhas) bir hâl almış olur ve yapılan hataları daha net görme imkanı doğar. Bu hataların tam olarak ortaya konulduğu aşama ise tecrübe (test) aşamasıdır. Bu son aşamadan sonra bir test raporu çıkarılarak gerekli adımlara geri dönülür ve hatalar telafi edilerek sistem istenen hale getirilir.

Tarihsel Gelişimi

Metot tarihsel olarak üretim ve inşaat sektörlerinde kullanılmakta olan ve isteklerin zaman içerisinde değişmesinin maliyetli olduğu ve isteğin ortaya konmasının ardından üretim tamamlanana kadar herhangi bir değişimin olmadığı alanlarda uygulanmaktaydı. Genelde inşaat ve üretim alanında bir üretimin tasarımı yapılıp üretime geçildikten sonra talepler ya hiç karşılanamamakta ya da kısıtlı oranlarda karşılanabilmektedir. 1983 yılında literatüre ilk model olarak Benington tarafından kazandırılan şelale modeli de bu yapıyı benimsemiştir [1]. Fikrin yayınlanmasından çok daha önce 1956 yılında fikir Amerikan Donanması tarafından düzenlenen bir matematik sempozyumunda yine Benington tarafından sunulmuştur [2].

Fikir boyutunda metodun geliştirilmesi incelendiğinde, yine “şelale (waterfall)” ismini kullanmadan metottan bahseden ve genelde literatürde en çok atıfta bulunulan çalışma Royce’a aittir [3]. Makalesine aşağıdaki bağlantıdan erişilebilir:

http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

Makalenin dikkat çekici yanı, yazılım dünyasında yaşanan geliştirme süreçlerini analiz ederken ve genel olarak yapılan hataları ve problemleri anlatırken şelale modeli yaklaşımını, ismini zikretmeden kullanmış olmasıdır.

Royce tarafından önerilen orjinal metot aşağıdaki şekildedir [4]:

  1. İster analizi (Requirement Specifications), bu aşamanın sonunda ürün ister dokümanı çıkar
  2. Tasarım (design), bu aşamanın sonunda yazılım mimarisi çıkar
  3. İnşa (construction), kodlama veya uygulama (implementation) aşamasıdır ve sonunda yazılım çıkar
  4. Uyum (integration)
  5. Test ve hata ayıklama (test and debugging)
  6. Kurulum (installation)
  7. Bakım (maintenance)

Royce tarafından önerilen orijinal şelale modelinin yanında geliştirilmiş modellerden bahsetmek de mümkündür ancak orijinal modelde aşamalar arası geçişler net bir şekilde belirlenmiş ve geri dönüş olmayacak şekilde tasarlanmıştır. Modelin diğer çeşitlerinin en önemli farkı, adımlar arasında geri dönüşlerin daha başarılı tanımlanmış olmasıdır.

Şelale Modeline Eleştirel Bakış

Şelale modelinin en zayıf yönü olan ve geri dönüşe izin vermeyen yapı, çoğu zaman önceki adımlarda yaşanan problemler yüzünden geri dönülmeyi gerektirir. Özellikle yazılım gibi esnek bir yapıdaki üretimin çok defa bu şekilde ihtiyaçlarda ve dolayısıyla analiz, tasarım gibi ilerleyen adımlarda değişikliklere ihtiyaç duyması yeni modellerin çıkmasına sebep olmuştur.

Bu konuda David Parnas tarafından “Mantıklı bir sistemi aldatmak” başlıklı yazısında yapılan kritik aşağıdaki şekilde tercüme edilebilir [5]:

“Çoğu sistemin detayları ancak sistem üzerinde çalışmaya başladıktan sonra anlaşılmaktadır. Yapılan işlemlerin bazıları, hata yaptığımızı göstermekte ve geri dönmemizi gerektirmektedir”

Bu karşı yaklaşımı destekleyen unsurlar aşağıdaki şekilde sıralanabilir:

  1. Bilişim teknolojileri konusunda tecrübesi olmayan paydaşların teknolojik olarak neler yapılabileceğinden haberdar olmaması yüzünden isteklerinin değişime açık olması
  2. Proje ihtiyaçlarının zaman içerisinde değişime açık olması
  3. Proje paydaşlarının isteklerini doğru şekilde aktaramaması
  4. Proje ekibinin acemiliği veya kodlama öncesi aşamalardaki kaynak eksiklikleri (nitelik ve nicelik anlamındaki eksikler)
  5. Projenin ilerideki şeklinin önceden kestirilememesi

Yukarıdaki kritik noktalarına karşılık şelale modelini destekleyen unsurlar aşağıdaki şekilde sıralanabilir:

  1. iki kere ölçüp bir kere biçmek yaklaşımının kurumda uygulanmasını sağlaması
  2. Proje dokümantasyonu hazırlanmaya zorlaması
  3. Hataların hangi aşamalarda ve kimin tarafından kaynaklandığının bulunmasını kolaylaştırması
  4. Her sonraki aşamaya geçmeden önce, önceki aşamanın tamamlanması, bu sayede önceki aşamada ayrılan kaynakların serbest kalması ve farklı projelere aktarılabilmesi

Yukarıdaki destekleyen unsurlara ilave olarak bilinmesinde fayda olan bir özellik ise, çoğu yazılım mühendisliği derslerinde şelale modelinin bir zorunluluk olarak okutulduğudur. Bunun sebebi çoğu modelin aslında şelale modeline dayanan (üzerine devam şeklinde veya karşı görüş olarak) yapısıdır.

 Referanslar

[1] Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. doi:10.1109/MAHC.1983.10102.

[2] United States. Navy Mathematical Computing Advisory Panel. (29 June 1956), Symposium on advanced programming methods for digital computers, [Washington, D.C.]: Office of Naval Research, Dept. of the Navy, OCLC 10794738

[3] Royce, Winston (1970), "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 1–9

[4] Royce, Winston. "Managing the Development of Large Software Systems". Retrieved 11 August 2014.

[5] "A Rational Design Process: How and Why to Fake It", David Parnas (PDF file)

 

 

 

Leave a Reply

You must be logged in to post a comment.