Vikipedi, ozgur ansiklopedi
?elale yonteminde (yaygın kullanılan adı Waterfall Model)
yazılım
geli?tirme sureci
analiz
, tasarım, kodlama, test, surum ve bakım gibi safhalardan olu?ur. Geleneksel yazılım metotlarında bu safhalar ?elale modelinde oldu?u gibi do?rusal olarak i?ler. Her safha, ba?langıc noktasında bir onceki safhanın urettiklerini bulur. Kendi bunyesindeki de?i?ikler do?rultusunda teslim aldıklarını bir sonraki safhanın kullanabilece?i ?ekilde de?i?tirir.
- ?elalenin her basama?ında yer alan aktiviteler eksiksiz olarak yerine getirilir. Bu bir sonraki basama?a gecmenin ?artıdır.
- Her safhanın sonunda bir dokuman olu?turulur. Bu yuzden ?elale modeli dokuman gudumludur.
- Yazılım sureci do?rusaldır, yani bir sonraki safhaya gecebilmek icin bir onceki safhada yer alan aktivitelerin tamamlanmı? olması gerekir.
- Kullanıcı katılımı ba?langıc safhasında mumkundur. Kullanıcı gereksinimleri bu safhada tespit edilir ve detaylandırılır. Daha sonra gelen tasarım ve kodlama safhalarında mu?teri ve kullanıcılar ile diyalo?a girilmez.
- Fazların net bir ?ekilde sınırlandırılması
- Basit planlama ve kontrol olanakları
- Basit ve anla?ılabilir bir model
- Du?uk maliyet
- Kullanıcı katılımı sadece tanım a?amasında mumkun
- Dokuman gudumlu
- Sıralama, sınırlandırma ve yeterlilik problemleri
- Safhaların birbirinden kesin olarak ayrı tutulmaları gercekci de?ildir. Projelerde safhalar arasındaki bu sınırlar yok olabilir.
- Teoride safhalar birbirlerini takip edeler. Projelerde bunun bazen mumkun olmadı?ını ve onceki safhalara geri donulmek zorunda kalındı?ını gorebiliriz.
- Safhalar arası geri donu? yetersizdir. Model de?i?ikli?e acık de?ildir.
- Mu?teri gereksinimlerinin proje oncesi detaylı olarak ka?ıt uzerinde olu?turulması ileride sorun yaratabilir. Mu?teri gereksinimleri de?i?ikli?e u?rayabilece?i icin, yazılım sisteminin de yapısal de?i?ikli?e u?raması kacınılmaz olabilir. Boyle bir durum maliyeti artırır, cunku yeni ve de?i?en gereksinimleri implemente edebilmek icin modelde yer alan safhaların birkac kere uygulanması gerekebilir.
- Sistemin kullanılır hale gelmesi uzun zaman alabilir.
- Ba?langıcta yapılan hataların tespiti cok uzun zaman alabilir. Bu hataların giderilmesi maliyeti yukseltir.
- Modul implementasyonları icin zaman tahminleri proje planlarını olu?turan yoneticiler tarafından yapılır. Teknik bilgiye sahip olmayan ?ahıslar tarafından yapılan bu tahminler co?u zaman do?ru de?ildir. Bu durum proje planlama surecini negatif etkiler.
Proje ba?langıcında her detayı goz onunde bulundurmak mumkun olmadı?ı icin, ?elale modeliyle geli?tirilen yazılım sistemlerinin mu?teri gereksinimlerini tam tatmin etmedi?ini gormekteyiz. Bunun onune gecebilmek icin projenin ba?langıc safhasında analiz icin cok zaman harcanır ve mu?teri gereksinimleri en ince detayına kadar tespit edilir. Aslında proje ba?langıcıyla olu?turulan dokumanlar obsolet (eskimi?) hale gelmi?tir, cunku mu?teri gereksinimleri piyasa ve rekabet ko?ulları gere?i de?i?ikli?e u?ramı? olabilir. Ne yazık ki ?elale modeli bunları dikkate almaz ve mu?terinin talep etti?i de?i?iklikleri aza indirmeye calı?ır. Bunun bir sebebi de sonradan gelen de?i?iklik taleplerinin maliyeti yukseltmesidir, cunku bu durumda ?elale modelinde yer alan safhaların birkac kere uygulanması gerekebilir.
Bu cerceveden bakıldı?ında proje sonunda olu?an program mu?terinin aktuel gereksinimlerini tatmin etmez durumdadır. Program daha cok mu?terinin proje ba?langıcında sahip oldu?u gereksinimleri tatmin edecek ?ekilde tasarlanmı?tır. Projelerin birkac sene boyunca surebilece?ini du?unursek, aslında bu surec sonunda olu?an program aktuel de?ildir.
- Mu?teri ne istedi?ini tam olarak bilmeyebilir. Bu yuzden proje oncesi detaylı analiz yapılması, mu?terinin her gereksimini dile getirdi?inin garantisi de?ildir. Mu?terinin bazı gereksinimlerini projenin ilerleyen safhalarında ke?fetmesi durumunda, olu?an de?i?ikliklerin projeye dahil edilmesi hemen hemen imkansız olacaktır. Bunun en buyuk sebeplerinden birisi de yazılım icin olu?turulan tasarımın projesi oncesi belirlenmesi ve bu yuzden ileride meydana gelebilecek de?i?ikliklerin goz onunde bulundurulmamı? olmasıdır. Projenin ilerleyen safhalarında meydana gelen her de?i?iklik tasarımı zorlar. Tasarım cevik olmadı?ı icin de?i?iklikleri ta?ıyamaz.
- Mu?teri ne istedi?ini do?ru olarak ifade edemeyebilir. Bu durumda proje oncesi yapılan analizler do?ru olmayacaktır. Bu mu?terinin istemedi?i bir yazılım sisteminin meydana gelmesine sebep olur. ?elale yontemi mu?teri ile devamlı diyalog icinde olunmasını engeller. Mu?teriden geri donu? sa?lanamadı?ı icin, mu?terinin analiz safhasında meydana gelen yanlı? anla?ılmaları duzeltmesi mumkun de?ildir.
- ?elale yonteminde proje akı?ı bir sonraki safhaya geci? yonundedir. Bu yuzden ileti?im tek yonludur. Safhalar arası geri donu? mumkun de?ildir. Bu yapılan hataların tamir edilmesini engeller.
- ?elale yontemi ile mu?terinin istedi?i yazılım sistemi proje sonunda tamamlanır. Ancak bu safhada mu?teri yazılım sistemini test edebilir. Mu?teri tamamlanan yazılım sistemini tum artı ve eksileriyle kabullenmek ve kullanmak zorundadır.
 |
Wikimedia Commons'ta
Waterfall model
ile ilgili ortam dosyaları bulunmaktadır.
|
|
|---|
| Alanlar
| |
|---|
| Kavramlar
| |
|---|
| Yonelimler
| |
|---|
| Modeller
| |
|---|
Yazılım
muhendisleri
| |
|---|
| ?lgili alanlar
| |
|---|
