Şelale Yöntemi Nedir?

Bu makale açıklar Şelale yöntemi pratik bir şekilde. Bu makaleyi okuduktan sonra, yazılım geliştirme ve internet teknolojisi için bu güçlü aracın temellerini anlayacaksınız.

Şelale Yöntemi nedir?

Şelale yöntemi, projenin birbirini takip eden doğrusal aşamalara bölündüğü bir proje yaklaşımıdır. Bir sonraki aşamanın başlatılabilmesi için her aşamanın başarıyla tamamlanması gerekir. Yöntem genellikle teknik tasarıma sahip projelerde kullanılır ve Sistem Geliştirme Yaşam Döngüsünün (SDLC) bir versiyonudur.

Yazılım geliştirmede uygulandığında, model, bir şelalenin suyu gibi ilerlemenin büyük ölçüde aşamalar boyunca tek bir aşağı doğru akışta olduğu yinelemeli ve esnek bir yaklaşımdır. Aşamalar şunlardır: tasarım, başlatma, analiz, tasarım, yapım, test, uygulama ve bakım.

Şelale yöntemi, tanıtılan ilk süreç modelidir (SDLC). Başlangıçta şelale yöntemi inşaat sektöründe başladı. Yüksek düzeyde yapılandırılmış ve fiziksel ortamlar, inşaat sırasında tasarım değişikliklerinin çok yüksek maliyetlerle sonuçlandığı anlamına geliyordu. Daha sonra yazılıma olan talep arttığında, bu projeleri yönetmenin bilinen bir alternatifi yoktu. Bugün, Hızlı Uygulama Geliştirme (RAD), Ortak Uygulama Programı (JAD), Çevik Proje Yönetimi (APM) ve spiral model gibi çok iyi geliştirilmiş bazı alternatifler bulunmaktadır.

Şelale Yönteminin Kökeni

Şelale yönteminin ilk resmi girişi ve açıklaması 1970 yılında Winston W. Royce tarafından yazılan bir makaleye atfedilir. Fakat Royce henüz şelale kelimesini kullanmamaktadır. Şelale terimi ilk olarak 1976’da Bell ve Thayer tarafından yazılan bir makalede kullanıldı. Örneğin, 1985’ten itibaren ABD Savunma Bakanlığı, bu yöntemi yazılım üzerinde çalışan müteahhitleri için uyarladı.

Şelale yönteminin aşamaları

Royce’un orijinal modelinde aşağıdaki aşamalar açıklanmıştır.

1. Sistem ve yazılım gereksinimleri

İlk aşama, tam olarak neyin geliştirilmesi gerektiğini, amacın ne olduğunu, işlevi vb. anlamayı içerir. Gereksinimler, son tarihler, yönergeler ve diğer konular bu aşamada belirlenir. Yani çoğunlukla gereksinimlerin listelendiği bir belgedir (Gereksinimleri Anlama Belgesi).

• Gereksinimlerin oluşturulması
• Beyin fırtınası
• Canlılık testi

2. Analiz

İlk aşamada toplanan bilgiler, burada ürün modelleri ve mantığı oluşturmak için kullanılır. Bu durum üretimin yönetimi için çok önemlidir. Bu aşamanın sonunda bir fizibilite testi de yapılır. Bu durum mali ve teknik kaynaklar için geçerlidir.

3. Tasarım

Üçüncü aşama, tasarım aşamasıdır. Bu aşamada ilk aşamadaki şartnameler incelenir ve bir sistem tasarımı hazırlanır. Sistem tasarımı, sistem ve donanım gereksinimlerinin oluşturulmasına yardımcı olur. Daha sonra genel sistem mimarisinin tanımlanmasına yardımcı olur. Kodlama aşamasına geçmeden önce bu aşamanın tamamlanması gerekir. Bir sonraki aşamada geliştirilecek olan kod aslında şu anda hazırlanıyor. Bu aşamanın sonucu bir Üst Düzey Tasarım Belgesi (HLD) veya Düşük Düzeyli Tasarım Belgesidir (LLD).

• Tüm gereksinimleri dikkate alan tasarım geliştirme
• Sistem gereksinimlerinin oluşturulması
• Tasarımları belgelemek

4. Kodlama

Dördüncü aşamada, önceki aşamalardan gelen ürün modelleri, mantık ve gereksinimler kullanılarak kod geliştirilir.

5. Test etme

Kodlama tamamlandıktan sonra sistem tasarımı test edilir. Bu durum istemci onu kullanmaya başladığında sistemde herhangi bir hata olmamasını sağlamak içindir. Projeye bağlı olarak çeşitli testler uygulanır. Kalite güvencesi, sistem testleri, beta testleri veya birim testleri düşünün. Sistem tüm testleri geçerse şelale alçalmaya devam edecektir. Bu aşamanın sonucu genellikle bir test raporudur ama bazı durumlarda ayrıca bir Kullanıcı Kabul Testinden (UAT) oluşur. Sistem kamuya açık hale gelmeden önce çok sayıda kullanıcı tarafından test edilir.

• Kod entegrasyonu
• Test faaliyetleri
• Sapma durumunda rapor edin
• İlerlemeyi izle

6. Uygulama (kurulum, geçiş, destek ve bakım)

Son aşama, yeni yazılımın (bileşenlerin) kurulması, taşınması ve bakımından oluşur. uygulama farklı şekillerde gerçekleşebilir. Bazen daha küçük birimler önce mevcut bir sisteme entegre edilir. Bu durumda, her birim ayrı ayrı test edilir ve geliştirilir. Buna Birim Testi de denir.

Önceki aşamadaki işlevsel ve işlevsel olmayan testler başarıyla tamamlandıktan sonra, ürün müşteri ortamına getirilir. Hatalar ve hatalar test edilerek engellenmekle birlikte, sistemin bakımı istenir. Bu aşamada bakım, performansı iyileştirmek için sistemde veya sistemin küçük bölümlerinde küçük değişiklikler yapmayı içerir. Bu değişiklikler, istemci veya sistem geliştiricilerinin isteklerinin sonucudur. Bu aşamanın sonucu genellikle bir kullanım kılavuzudur.

Şelale yöntemi ve Çevik

Proje yönetiminde her iki yöntem de uygulanırken, Waterfall yöntemi Agile proje yönetimi yaklaşımından çok farklıdır. İlk olarak, Çevik bir döngüdür ve Şelale yöntemi sıralı aşamalardan oluşur. Waterfall yönteminin odak noktası projenin tasarım aşamasındayken, Agile ile tasarım aşamasına çok az zaman harcanır. Waterfall yöntemi ayrıca yeni yazılım bileşenlerini oluşturmak ve test etmek için Agile’den çok daha uzun süreler gerektirir. Agile’ın güçlü yönlerinden biri, yazılımın proje sırasında sürekli olarak test edilip geliştirilebilmesidir.

Şelale yöntemi, tartışıldığı gibi, yeni bir aşamanın başlamasının önceki aşamadaki görevlerin tamamlanmasına bağlı olduğu bir metodolojidir. Bir aşama tamamen tamamlanmadan önce, yeni bir aşama başlatılamaz ve başlatılamayabilir. Şelale yöntemiyle sonuçların düz bir akış gibi düştüğü yerde, Çevik, Çevik ve esneklik değerlerinden en iyi şekilde yararlanan çok sayıda türev yönteminin eklendiği bir hareket olarak görülüyor.

Waterfall yöntemi, görevler ve eylemler arasında çeşitli bağımlılıkları olan projelerde kullanım için idealdir. Çevik, müşterinin istenen sonuçtan emin olmadığı veya gelecekteki faktörlere bağlı olduğu projeler için daha uygundur. Genel olarak Agile projelerinin teslim süresi Waterfall projelerine göre daha kısadır. Farklı yöntemler arasında seçim yaparken, kalite ve hız arasında bir denge kurulmalıdır.

Şelale yöntemine örnekler

Yüzyılın sonuna kadar, yöntem esas olarak yazılım geliştirme için kullanılıyordu. Çevik manifestosunun 2001’de yayınlanmasından sonra bile, Şelale yöntemi hala birçok kuruluş tarafından kullanılıyordu. Şelale yöntemi günümüzde pek popüler değil. Genellikle projeler, proje gereksinimlerine bağlı olarak Çevik bir yaklaşımı veya başka bir yinelemeli modeli izler.

Başarılı Şelale yöntemi projeleri

Şelale yönteminin inşaat sektörüne tanıtılmasının ardından iş dünyasında benimsenmesi biraz zaman aldı. Yöntem ilk olarak Müşteri İlişkileri Yönetimi (CRM) sistemleri, İnsan Kaynakları Yönetimi (İKY) sistemleri, Tedarik Zinciri Yönetim sistemleri, Envanter Yönetim Sistemleri ve mağazalar ve toptancılar için satış sistemleri gibi iş uygulamalarını geliştirmek için kullanıldı.

Şelale yönteminin avantajları ve dezavantajları

Şelale yöntemini kullanmanın diğer proje yaklaşımlarına göre bazı avantajları vardır.

Şelale yönteminin avantajları

• Yöntemin anlaşılması ve uygulanması kolaydır.
• Daha küçük projeler için Waterfall yöntemi iyi çalışır ve kaliteli sonuçlar verir.
• Şelale yöntemi, yönetilmesi nispeten kolay bir yaklaşımdır çünkü aşamalar tek tek gerçekleştirilir.
• Projenin hem giriş hem de çıkış kriterleri iyi tanımlanmıştır. Bu yüzden iyi kaliteyi garanti etmek daha kolaydır.
• Sonuçlar ve ilerleme Şelale yöntemiyle doğru bir şekilde belgelenir.
• Waterfall yöntemi, önceden tanımlayarak iyi kodlama alışkanlıklarını pekiştirir.
• Şelale yöntemi, kilometre taşlarını ve son tarihleri ​​açıkça tanımlar.
• Waterfall yöntemi, programa ve son tarihlere göre yönetim kontrolünü kolaylaştırır.

Şelale yönteminin dezavantajları

Açıktır ki, şelale yöntemini kullanmanın diğer proje yaklaşımlarına kıyasla bazı dezavantajları da vardır.

• Şelale yönteminin tasarımı uyarlanabilir değildir. Daha sonraki bir aşamada bir hata bulunursa, tüm sürecin yeniden başlaması gerekir. Bu durum zaman alıcı ve maliyetlidir.
• Waterfall yöntemi, geliştirme sürecinin ortasında kullanıcı ve müşteri geri bildirimlerini ve girdileri alma ve işleme fırsatını göz ardı eder.
• Şelale süreci, tüm sürecin sonuna kadar testlerle başlamaz.
• Şelale süreci, hataların düzeltilmesini hesaba katmaz.
• Waterfall yöntemi, süreçlerin çakışmasına izin vermeyerek verimliliği düşürür.
• Çalışan bir ürün yalnızca geliştirme sürecinin sonunda mevcuttur.
• Şelale yöntemi, karmaşık ve riskli projeler için daha az uygundur.

Şelale yönteminin eleştirisi

Waterfall yönteminin önemli bir dezavantajı, müşterilerin tam olarak neyi ve nasıl geliştirildiğini bilmemesidir ve bu yüzden gereksinimleri değiştiğinde, tüm projenin yeniden tasarlanması, yeniden geliştirilmesi, yeni testler ve daha yüksek maliyetlere ihtiyacı olacaktır. Öte yandan, sistem üzerinde çalışan tasarımcılar, bir yazılım sistemi tasarlarken gelecekteki sorunların tam olarak farkında olmayabilirler. Bu durumda yeni bir ürün tasarlamak, yeni sınırlamaları, gereksinimleri veya sorunları hesaba katmayan bir tasarımda ısrar etmekten daha iyidir.

Bunu ele almanın bir yolu, sistem analistlerini istihdam etmektir. Nasıl değiştirilebileceklerini veya geliştirilebileceklerini belirlemek için mevcut sistemleri analiz etmek. Fakat pratikte, sistem analizi ile programlamayı ayırmak çok zordur. Bunun nedeniyse bir sistemin uygulanması neredeyse kaçınılmaz olarak analistin önceden düşünmediği sorunlara yol açmaktadır.

Yukarıdaki eleştirilere yanıt olarak, değiştirilmiş Şelale yöntemleri tanıtıldı. Örnekler arasında Sashimi (Aşamaları çakışan Şelale), alt projeleri olan Şelale yöntemleri ve risk azaltmaya vurgu yapan Şelale yöntemleri bulunmaktadır. ABD Savunma Bakanlığı gibi bazı kuruluşlar hala Şelale yöntemine değer veriyor. Bunun temel nedeni, kontrol seviyesinin proje yaklaşım alternatiflerinden daha yüksek olmasıdır.

Esnek sistem geliştirmenin savunucuları, Waterfall yönteminin yazılım geliştirme için çok etkisiz olduğunu savunuyorlar. Diğerleri, Waterfall yönteminin yalnızca ticari kazanç için alternatif geliştirme yöntemlerini pazarlamak için kullanıldığını iddia ediyor. Karma, karşılaştırılabilir bir yazılım geliştirme biçimi, Rational Unified Process (RUP) yöntemidir. Bu yöntem, bir projeyi yolunda gitmesi için gereken kilometre taşlarının gerekliliğini ve gerekliliğini kabul eder ama aynı zamanda farklı aşamalarda yinelemeyi teşvik eder. Bu yönteme Şelale benzeri de denir.

Şelale yönteminin özeti

Şelale yöntemi, sistem ve tasarım projeleri için bir proje yaklaşımıdır. Yöntem, ekip bir sonraki aşamaya başlamadan önce tamamlanması gereken her aşama ile beş aşamaya bölünmüştür. Bu tür bir projenin yönetimi için alternatif bir terim, Sistem Geliştirme Yaşam Döngüsüdür (SDLC).

İlk aşama, sistem gereksinimlerinin toplanmasından oluşur. Yani tüm gereksinimlerin listelendiği bir belgedir. Bundan sonra proje ekibi, ürün modelleri ve mantığı oluşturmak için bu gereksinimleri analiz etmeye başlar. Bu aşamanın sonunda bir fizibilite testi yapılır. Üçüncü aşamada tasarım özelliği yer alır. Tüm gereksinimlerin entegrasyonu ile eksiksiz tasarım dikkate alınır. Sonraki aşamada yeni sistemin kodlanması üzerinde çalışılır. Kodlar tamamlandıktan sonra, sistem test edilir ve ardından uygulanır ve sürdürülür.

Çevik yaklaşımın aksine, Şelale yöntemi sıralı bir süreçtir. Bu durum farklı aşamalar arasında örtüşme olmadığı anlamına gelir. Bu bazılarına göre verimsizliklere, gecikmelere ve ek maliyetlere yol açarken, Şelale yöntemini tercih eden firma ve kuruluşlar da bulunmaktadır. Bu durum esas olarak kontrolün önemli bir rol oynadığı kuruluşlar ve projeler ile ilgilidir. Bir başka eleştiri noktası, şelale yönteminde danışanın çok küçük bir rol oynamasıdır. Sadece tüm geliştirme sürecinin sonunda müşteri bilgi ve kılavuzları alacaktır…