Waterfall (Şelale) Yönteminin Avantaj ve Dezavantajları

Waterfall (Şelale) Yönteminin Avantaj ve Dezavantajları

Waterfall (Şelale) metodolojisi sıralı, doğrusal bir süreci takip eder ve yazılım mühendisliği ve BT projeleri için yazılım geliştirme yaşam döngüsünün (Software Development Life Cycle - SDLC) en popüler versiyonudur. Bazen her görev için başlangıç ve bitiş tarihlerini gösteren bir çubuk grafik türü olan bir Gantt grafiği kullanılarak planlanır. Sekiz aşamadan biri tamamlandığında, geliştirme ekibi bir sonraki adıma geçer. Ekip, sürecin başından başlayarak bir önceki aşamaya geri dönemez. Ekip, bir sonraki aşamaya geçmeden önce, ihtiyaçların müşteri tarafından gözden geçirilmesi ve onaylanması gerekebilir.

Waterfall modeli, imalat ve inşaat endüstrilerinden ortaya çıkmıştır. Bu iki sektör de hem çok pahalı hem de bazen imkansız olabilecek yapıda ortamlardır. WAterfall' un ilk resmi tanımı, hatalı bir yazılım modelini tarif ettiği 1970 tarihli bir makalede Winston W. Royce'a atfedilir.

Waterfall' un Avantajları

Waterfall en iyi kullanıldığı projeler basit, değişmeyen projelerdir. Doğrusal olması ve sert doğası kullanımı kolaylaştırır ve derinlemesine dokümanlara ihtiyaç duyar.

WAterfall' un avantajları şunlardır:

  • Kullanımı ve yönetimi kolaydır: Waterfall modeli her bir proje için aynı sıralı deseni takip ettiğinden, kullanımı ve anlaşılması kolaydır. Ekip, bir Waterfall projesi üzerinde çalışmadan önce herhangi bir ön bilgiye veya eğitime ihtiyaç duymaz. Waterfall katı bir modeldir; Her fazın belirli çıktıları ve gözden geçirmeleri vardır, bu yüzden yönetimi ve kontrolü kolaydır.
  • Disiplin yürürlüğe konulur : Waterfall' un her aşamasının bir başlangıç ve bitiş noktası vardır ve ilerlemeyi paydaşlarla ve müşterilerle paylaşmak kolaydır. Ekip, kod yazmadan önce gereksinimlere ve tasarıma odaklanarak, herhangi bir teslim tarihini kaçırma riskini azaltabilir.
  • İyi dökümanlara (belgelere) sahip bir yaklaşım gerektirir : Waterfall, her aşama için dokümantasyon gerektirir ve bu da kodun ve testlerin arkasındaki mantığın daha iyi anlaşılmasını sağlar. Ayrıca, gelecekteki projeler için bir kağıt izi bırakır veya paydaşların belirli bir aşama hakkında daha fazla ayrıntı görmesi gerekiyorsa bu belgeler kullanılabilir.

Waterfall' un Dezavantajları

Waterfall' un en büyük dezavantajı, değişimi nasıl ele aldığıdır. Waterfall doğrusal, sıralı bir model olduğu için, beklenmedik değişiklikler meydana gelse bile fazlar arasında zıplayamazsınız. Bir aşamada bittiğinde, bitmiştir.. İşte bu kadar.

Waterfall' un dezavantajları hakkında daha fazla bilgi:

  • Değişiklikler kolayca yerine getirilemez: Ekip bir aşamayı tamamladıktan sonra geri dönemez. Test aşamasına ulaşırlarsa ve bir özellik gereksinim aşamasından eksik çıktığı fark edilerse, geri dönmek ve düzeltmek çok zor ve pahalıdır.
  • Yazılım en sona kadar teslim edilemez : Proje, kodlamanın gerçekte başlaması için iki ila dört aşamayı tamamlamalıdır. Sonuç olarak, paydaşlar yaşam döngüsünün sonuna kadar çalışan yazılımlarını görmeyeceklerdir.
  • Doğru gereksinimleri toplamak zor olabilir: Bir Waterfall projesindeki ilk aşamalardan biri, müşteriler ve paydaşlar ile konuşmak ve onların gereksinimlerini tanımlamaktır. Ancak, projede bu kadar erken aşamada müşterilerin istediklerini tam olarak belirlemek zor olabilir. Çoğu zaman, müşteriler bu kadar erken bir zamanda ne istediklerini bilmiyorlar ve bunun yerine proje ilerledikçe gereksinimleri öğreniyor ve belirliyorlar.

Waterfall aşamaları

Waterfall'da sekiz aşama vardır ve hepsi sıralı olarak gerçekleşmelidir. Örneğin, geliştirme ekibi test aşamasındaysa analiz aşamasına geri dönülemez.

  • Kavram (Conception) : Bu aşama bir fikirle başlar. Kavram aşaması, projenin kaba bir değerlendirmesini içerir, neden yararlıdır ve herhangi bir başlangıç maliyet tahminine bakılır.
  • Başlangıç (Initiation) : Fikir oluşturulduktan sonra, proje ekibini işe almanız ve hedefleri, kapsamı, amacı ve çıktıları tanımlamanız gerekir.
  • İhtiyaç Toplama ve Analiz (Requirement ve Analysis) : Gereksinimler, projenin gerçekten mümkün olup olmadığını görmek için toplanır ve analiz edilir. Bütün bu bilgiler bir gereksinim dökümanında belgelenir.
  • Tasarım (Design) : Bu aşamada oluşturulan tasarım özellikleri, kodun gerçekten yazılması için kodlama aşamasında kullanılır. Gereksinimler üzerinde çalışılmış ve değerlendirilmiş ve sistemin tasarımı hazırlanmıştır. Takımın amacı hangi eylemlerin yapılması gerektiğini ve neye benzemesi gerektiğini anlamaktır.
  • Uygulama / Kodlama (implementation / Coding) : Yazılımın gerçek kodlaması başlar. Tasarım aşamasında oluşturulan herhangi bir akış şeması veya algoritma bir programlama diline çevrilir.
  • Test etme: Kod tamamlandıktan sonra, yazılımın herhangi bir hata için test edilmesi gerekir. Test bittiğinde, yazılım müşteriye teslim edilir. Bazı ekipler, kullanıcıların yazılımı genel halka dağıtılmadan önce test ettiği kullanıcı kabul testini (UAT) dahil etmeyi seçebilir.
  • Bakım (Maintenance) : Müşteriler yazılımı gerçek dünyada kullandıklarında, ek sorunlar bulabilirler. Geliştirme ekibinin, etkili olmaya devam etmek için yazılımı çözmesi, değiştirmesi veya üzerinde değişiklik yapması gerekecektir.

waterfall-yontemin-artilari-ve-eksileri-1

İteratif Waterfall Geliştirme

Geleneksel Waterfall modelinde, ekip tüm proje için her aşamadan geçer. Örneğin, tüm proje için analiz yaparlar, daha sonra projenin tamamı için tasarım yaparlar.

Yinelemeli bir Waterfall modelinde hala çok fazla ön planlama yapılması gerekiyor. Plan bir kez uygulandığında, ekip geleneksel Waterfall ile aynı örüntüyü izler ama her hikaye için yapar. Bir hikaye için analizi yaparlar, sonra bir hikayenin tüm tasarımını yaparlar, sonra bir hikaye için tüm kodlama ve testler yaparlar. Daha sonra süreci başka bir hikaye için tekrar ederler. İş, geliştirme ekibine yarar sağlayan parçalara ayrılır.

Waterfall yöntemde Yazılım Gereksinimleri Bakış Açısı Nasıldır?

Waterfall projeleri, tüm yazılım gereksinimlerini önceden tanımlamaktadır. Bu şartlar tanımlanmadığı ve belgelenmediği sürece proje devam edemez.

Bazı Waterfall projelerinde bu gereksinimleri yakalamak, toplamak ve yayınlamak için özel bir ekip bulunabilir. Paydaşları ve müşteri ihtiyaçlarını yakalamak için anketler, yüz yüze veya telefon görüşmeleri, beyaz tahtalar ve modelleme araçlarını da kullanabilirler.

İlk şartlar tanımlandıktan sonra, ekip bir gereksinim belgesi (requirements specification document) üretmelidir (bazen birden fazla da oluşturulabilir). Bu belge, herkesin projenin kapsamını anlaması için neyin teslim edilmesi gerektiğini tanımlar.


  Sen Ne Düşünüyorsun ?