Azərbaycanca
Беларускі
Dansk
Deutsch
Española
Français
Indonesia
Italiana
日本語
Қазақ
Lietuvos
Nederlands
Português
Русский
සිංහල
แบบไทย
Türkçe
Українська
中國人
United State
Afrikaans
Şelale yönteminde (yaygın kullanılan adı Waterfall Model) yazılım geliştirme süreci analiz, tasarım, kodlama, test, sürüm 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ıç noktasında bir önceki safhanın ürettiklerini bulur. Kendi bünyesindeki değişikler doğrultusunda teslim aldıklarını bir sonraki safhanın kullanabileceği şekilde değiştirir.
Özellikleri
- Şelalenin her basamağında yer alan aktiviteler eksiksiz olarak yerine getirilir. Bu bir sonraki basamağa geçmenin şartıdır.
- Her safhanın sonunda bir doküman oluşturulur. Bu yüzden şelale modeli doküman güdümlüdür.
- Yazılım süreci doğrusaldır, yani bir sonraki safhaya geçebilmek için bir önceki safhada yer alan aktivitelerin tamamlanmış olması gerekir.
- Kullanıcı katılımı başlangıç safhasında mümkündür. Kullanıcı gereksinimleri bu safhada tespit edilir ve detaylandırılır. Daha sonra gelen tasarım ve kodlama safhalarında müşteri ve kullanıcılar ile diyaloğa girilmez.
Avantajları
- Fazların net bir şekilde sınırlandırılması
- Basit planlama ve kontrol olanakları
- Basit ve anlaşılabilir bir model
- Düşük maliyet
Dezavantajları
- Kullanıcı katılımı sadece tanım aşamasında mümkün
- Doküman güdümlü
- Sıralama, sınırlandırma ve yeterlilik problemleri
Modelin Getirdiği Problemler
- Safhaların birbirinden kesin olarak ayrı tutulmaları gerçekçi değildir. Projelerde safhalar arasındaki bu sınırlar yok olabilir.
- Teoride safhalar birbirlerini takip edeler. Projelerde bunun bazen mümkün olmadığını ve önceki safhalara geri dönülmek zorunda kalındığını görebiliriz.
- Safhalar arası geri dönüş yetersizdir. Model değişikliğe açık değildir.
- Müşteri gereksinimlerinin proje öncesi detaylı olarak kâğıt üzerinde oluşturulması ileride sorun yaratabilir. Müşteri gereksinimleri değişikliğe uğrayabileceği için, yazılım sisteminin de yapısal değişikliğe uğraması kaçınılmaz olabilir. Böyle bir durum maliyeti artırır, çünkü yeni ve değişen gereksinimleri implemente edebilmek için modelde yer alan safhaların birkaç kere uygulanması gerekebilir.
- Sistemin kullanılır hale gelmesi uzun zaman alabilir.
- Başlangıçta yapılan hataların tespiti çok uzun zaman alabilir. Bu hataların giderilmesi maliyeti yükseltir.
- Modül implementasyonları için zaman tahminleri proje planlarını oluşturan yöneticiler tarafından yapılır. Teknik bilgiye sahip olmayan şahıslar tarafından yapılan bu tahminler çoğu zaman doğru değildir. Bu durum proje planlama sürecini negatif etkiler.
Müşteri Gereksinimleri
Proje başlangıcında her detayı göz önünde bulundurmak mümkün olmadığı için, şelale modeliyle geliştirilen yazılım sistemlerinin müşteri gereksinimlerini tam tatmin etmediğini görmekteyiz. Bunun önüne geçebilmek için projenin başlangıç safhasında analiz için çok zaman harcanır ve müşteri gereksinimleri en ince detayına kadar tespit edilir. Aslında proje başlangıcıyla oluşturulan dokümanlar obsolet (eskimiş) hale gelmiştir, çünkü müş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 müşterinin talep ettiği değişiklikleri aza indirmeye çalışır. Bunun bir sebebi de sonradan gelen değişiklik taleplerinin maliyeti yükseltmesidir, çünkü bu durumda şelale modelinde yer alan safhaların birkaç kere uygulanması gerekebilir.
Bu çerçeveden bakıldığında proje sonunda oluşan program müşterinin aktüel gereksinimlerini tatmin etmez durumdadır. Program daha çok müşterinin proje başlangıcında sahip olduğu gereksinimleri tatmin edecek şekilde tasarlanmıştır. Projelerin birkaç sene boyunca sürebileceğini düşünürsek, aslında bu süreç sonunda oluşan program aktüel değildir.
Neden Yazılımda Şelale Modeli Kullanılmamalı?
- Müşteri ne istediğini tam olarak bilmeyebilir. Bu yüzden proje öncesi detaylı analiz yapılması, müşterinin her gereksimini dile getirdiğinin garantisi değildir. Müş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 büyük sebeplerinden birisi de yazılım için oluşturulan tasarımın projesi öncesi belirlenmesi ve bu yüzden ileride meydana gelebilecek değişikliklerin göz önünde bulundurulmamış olmasıdır. Projenin ilerleyen safhalarında meydana gelen her değişiklik tasarımı zorlar. Tasarım çevik olmadığı için değişiklikleri taşıyamaz.
- Müşteri ne istediğini doğru olarak ifade edemeyebilir. Bu durumda proje öncesi yapılan analizler doğru olmayacaktır. Bu müşterinin istemediği bir yazılım sisteminin meydana gelmesine sebep olur. Şelale yöntemi müşteri ile devamlı diyalog içinde olunmasını engeller. Müşteriden geri dönüş sağlanamadığı için, müşterinin analiz safhasında meydana gelen yanlış anlaşılmaları düzeltmesi mümkün değildir.
- Şelale yönteminde proje akışı bir sonraki safhaya geçiş yönündedir. Bu yüzden iletişim tek yönlüdür. Safhalar arası geri dönüş mümkün değildir. Bu yapılan hataların tamir edilmesini engeller.
- Şelale yöntemi ile müşterinin istediği yazılım sistemi proje sonunda tamamlanır. Ancak bu safhada müşteri yazılım sistemini test edebilir. Müşteri tamamlanan yazılım sistemini tüm artı ve eksileriyle kabullenmek ve kullanmak zorundadır.
Kaynakça
- ^ "Neden Şelale Modeli Kullanılmamalı". 13 Ocak 2013 tarihinde kaynağından . Erişim tarihi: 3 Ocak 2013.
Dış bağlantılar
| Wikimedia Commons'ta Waterfall model ile ilgili ortam dosyaları bulunmaktadır. |
- Understanding the pros and cons of the Waterfall Model of software development2 Ocak 2013 tarihinde Archive.is sitesinde arşivlendi
- Project lifecycle models: how they differ and when to use them10 Mart 2010 tarihinde Wayback Machine sitesinde .
- Going Over the Waterfall with the RUP6 Temmuz 2008 tarihinde Wayback Machine sitesinde .
- CSC and IBM Rational join to deliver C-RUP and support rapid business change25 Haziran 2009 tarihinde Wayback Machine sitesinde .
- c2:WaterFall
wikipedia, wiki, viki, vikipedia, oku, kitap, kütüphane, kütübhane, ara, ara bul, bul, herşey, ne arasanız burada,hikayeler, makale, kitaplar, öğren, wiki, bilgi, tarih, yukle, izle, telefon için, turk, türk, türkçe, turkce, nasıl yapılır, ne demek, nasıl, yapmak, yapılır, indir, ücretsiz, ücretsiz indir, bedava, bedava indir, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, resim, müzik, şarkı, film, film, oyun, oyunlar, mobil, cep telefonu, telefon, android, ios, apple, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, pc, web, computer, bilgisayar
Selale yonteminde yaygin kullanilan adi Waterfall Model yazilim gelistirme sureci analiz tasarim kodlama test surum ve bakim gibi safhalardan olusur Geleneksel yazilim metotlarinda bu safhalar selale modelinde oldugu gibi dogrusal olarak isler Her safha baslangic noktasinda bir onceki safhanin urettiklerini bulur Kendi bunyesindeki degisikler dogrultusunda teslim aldiklarini bir sonraki safhanin kullanabilecegi sekilde degistirir OzellikleriSelalenin her basamaginda yer alan aktiviteler eksiksiz olarak yerine getirilir Bu bir sonraki basamaga gecmenin sartidir Her safhanin sonunda bir dokuman olusturulur Bu yuzden selale modeli dokuman gudumludur Yazilim sureci dogrusaldir yani bir sonraki safhaya gecebilmek icin bir onceki safhada yer alan aktivitelerin tamamlanmis olmasi gerekir Kullanici katilimi baslangic safhasinda mumkundur Kullanici gereksinimleri bu safhada tespit edilir ve detaylandirilir Daha sonra gelen tasarim ve kodlama safhalarinda musteri ve kullanicilar ile diyaloga girilmez Avantajlari Fazlarin net bir sekilde sinirlandirilmasi Basit planlama ve kontrol olanaklari Basit ve anlasilabilir bir model Dusuk maliyetDezavantajlari Kullanici katilimi sadece tanim asamasinda mumkun Dokuman gudumlu Siralama sinirlandirma ve yeterlilik problemleriModelin Getirdigi ProblemlerSafhalarin birbirinden kesin olarak ayri tutulmalari gercekci degildir Projelerde safhalar arasindaki bu sinirlar yok olabilir Teoride safhalar birbirlerini takip edeler Projelerde bunun bazen mumkun olmadigini ve onceki safhalara geri donulmek zorunda kalindigini gorebiliriz Safhalar arasi geri donus yetersizdir Model degisiklige acik degildir Musteri gereksinimlerinin proje oncesi detayli olarak kagit uzerinde olusturulmasi ileride sorun yaratabilir Musteri gereksinimleri degisiklige ugrayabilecegi icin yazilim sisteminin de yapisal degisiklige ugramasi kacinilmaz olabilir Boyle bir durum maliyeti artirir cunku yeni ve degisen gereksinimleri implemente edebilmek icin modelde yer alan safhalarin birkac kere uygulanmasi gerekebilir Sistemin kullanilir hale gelmesi uzun zaman alabilir Baslangicta yapilan hatalarin tespiti cok uzun zaman alabilir Bu hatalarin giderilmesi maliyeti yukseltir Modul implementasyonlari icin zaman tahminleri proje planlarini olusturan yoneticiler tarafindan yapilir Teknik bilgiye sahip olmayan sahislar tarafindan yapilan bu tahminler cogu zaman dogru degildir Bu durum proje planlama surecini negatif etkiler Musteri GereksinimleriProje baslangicinda her detayi goz onunde bulundurmak mumkun olmadigi icin selale modeliyle gelistirilen yazilim sistemlerinin musteri gereksinimlerini tam tatmin etmedigini gormekteyiz Bunun onune gecebilmek icin projenin baslangic safhasinda analiz icin cok zaman harcanir ve musteri gereksinimleri en ince detayina kadar tespit edilir Aslinda proje baslangiciyla olusturulan dokumanlar obsolet eskimis hale gelmistir cunku musteri gereksinimleri piyasa ve rekabet kosullari geregi degisiklige ugramis olabilir Ne yazik ki selale modeli bunlari dikkate almaz ve musterinin talep ettigi degisiklikleri aza indirmeye calisir Bunun bir sebebi de sonradan gelen degisiklik taleplerinin maliyeti yukseltmesidir cunku bu durumda selale modelinde yer alan safhalarin birkac kere uygulanmasi gerekebilir Bu cerceveden bakildiginda proje sonunda olusan program musterinin aktuel gereksinimlerini tatmin etmez durumdadir Program daha cok musterinin proje baslangicinda sahip oldugu gereksinimleri tatmin edecek sekilde tasarlanmistir Projelerin birkac sene boyunca surebilecegini dusunursek aslinda bu surec sonunda olusan program aktuel degildir Neden Yazilimda Selale Modeli Kullanilmamali Musteri ne istedigini tam olarak bilmeyebilir Bu yuzden proje oncesi detayli analiz yapilmasi musterinin her gereksimini dile getirdiginin garantisi degildir Musterinin bazi gereksinimlerini projenin ilerleyen safhalarinda kesfetmesi durumunda olusan degisikliklerin projeye dahil edilmesi hemen hemen imkansiz olacaktir Bunun en buyuk sebeplerinden birisi de yazilim icin olusturulan tasarimin projesi oncesi belirlenmesi ve bu yuzden ileride meydana gelebilecek degisikliklerin goz onunde bulundurulmamis olmasidir Projenin ilerleyen safhalarinda meydana gelen her degisiklik tasarimi zorlar Tasarim cevik olmadigi icin degisiklikleri tasiyamaz Musteri ne istedigini dogru olarak ifade edemeyebilir Bu durumda proje oncesi yapilan analizler dogru olmayacaktir Bu musterinin istemedigi bir yazilim sisteminin meydana gelmesine sebep olur Selale yontemi musteri ile devamli diyalog icinde olunmasini engeller Musteriden geri donus saglanamadigi icin musterinin analiz safhasinda meydana gelen yanlis anlasilmalari duzeltmesi mumkun degildir Selale yonteminde proje akisi bir sonraki safhaya gecis yonundedir Bu yuzden iletisim tek yonludur Safhalar arasi geri donus mumkun degildir Bu yapilan hatalarin tamir edilmesini engeller Selale yontemi ile musterinin istedigi yazilim sistemi proje sonunda tamamlanir Ancak bu safhada musteri yazilim sistemini test edebilir Musteri tamamlanan yazilim sistemini tum arti ve eksileriyle kabullenmek ve kullanmak zorundadir Kaynakca Neden Selale Modeli Kullanilmamali 13 Ocak 2013 tarihinde kaynagindan Erisim tarihi 3 Ocak 2013 Dis baglantilarWikimedia Commons ta Waterfall model ile ilgili ortam dosyalari bulunmaktadir Understanding the pros and cons of the Waterfall Model of software development2 Ocak 2013 tarihinde Archive is sitesinde arsivlendi Project lifecycle models how they differ and when to use them10 Mart 2010 tarihinde Wayback Machine sitesinde Going Over the Waterfall with the RUP6 Temmuz 2008 tarihinde Wayback Machine sitesinde CSC and IBM Rational join to deliver C RUP and support rapid business change25 Haziran 2009 tarihinde Wayback Machine sitesinde c2 WaterFall