27 Kasım 2015

Agile (Çevik) ve Waterfall (Şelale) Yazılım Geliştirme Modeli

Merhaba,
Bugünkü yazımda Waterfall (Şelale) Yazılım Geliştirme Modeli'nden ve Agile (Çevik) Yazılım Geliştirme Modeli'nden bahsedeceğim.

Konuyu;

1.
Yazılım Geliştirme
Modelleri

2.
Waterfall (Şelale) Modeli
3. Agile (Çevik) Modeli


başlıkları altında anlatacağım.


1. Yazılım Geliştirme Modelleri
Geliştirdiğimiz yazılımın, üretim aşaması ve kullanım süreci boyunca geçirdiği tüm aşamaları yazılım geliştirme yaşam döngüsü olarak tanımlıyoruz. Her yazılım, bu döngüde planlama-analiz-tasarım-üretim-bakım aşamalarından geçer.
Yazılım yaşam döngüsündeki bu temel adımların nasıl gerçekleştirileceğine yönelik çeşitli modeller geliştirilm. Yazılım geliştirme modelleri, elimizdeki projenin 'hangi felsefe' doğrultusunda işi yürüteceğimize karar verdikten sonra kullanacağımız metodolojilerdir. Projenin hangi felsefeye göre yürütüleceğine ise iş ihtiyacına göre karar veririz.

Özetleyecek olursak; bir yazılım geliştirme metodolojisi aşağıdaki adımlardan meydana gelir:
- Yazılım geliştirme süreci yaklaşımıyla bir yazılım geliştirme felsefesi
- Yazılım geliştirme sürecine destek veren araçlar, modeller ve yöntemler

Çokça bilinen yazılım geliştirme modellerimiz:
> Waterfall (Şelale) Model
> Agile Software Development (Çevik Yazılım Geliştirme) Model
> Prototyping (Prototip) Model
> Incremental (Artırımsal) Model
> Spiral (Sarmal) Model
> Rapid Application Development (Hızlı Uygulama Geliştirme) Model
> Object-Oriented Analisys and Design (Nesne Yönelimli Analiz ve Tasarım) Model

Geleneksel yazılım geliştirme süreçlerinde çoğunlukla Waterfall (şelale) modeli kullanılır.

2. Waterfall (Şelale) Modeli



Waterfall modeli, yazılım geliştirmenin gereksinim analizi, tasarım, geliştirme, test ve bakım gibi fazları boyunca aşağıya doğru (şelale gibi) devam eder gibi göründüğü sıralı geliştirme sürecidir. 

Genel Özellikleri:
  • Şelalenin her basamağında yer alan aktiviteler eksiksiz olarak yerine getirilir. Bu, sonraki basamağa geçmenin şartıdır. 
  • Her safhanın sonunda bir doküman oluşturulur. Bu yüzden waterfall  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.  

Teoride her ne kadar her şey mükemmel görünse de bu prensipler pratik hayata geçirildiğinde her şey bu kadar mükemmel olmayabiliyor.

Problemler

  • Bir safha bitmeden diğer safhaya geçilememesi müşterinin tüm gereksinimlerini ilk aşamada tanımlamayı gerektirir. Yazılımcıların büyük çoğunluğunun tecrübe ettiği gibi;

    - Proje başlangıcında müşteriler, tam olarak ne istediklerinden yüzde yüz emin değildirler.
    - Müşteriler yazılım teknolojilerinin içinde değillerse
    isteklerini net bir şekilde dile getirmekte zorlanabilirler.
    - Müşterilerin asıl istekleriyle ilgili detaylar proje başlangıcında fark edilebilir değildirler, süreç içerisinde yüzeye çıkarlar.
    - Müşteriler isteklerinin gerçekleştiğini gördükçe, proje gözle görülür sonuçlar üretmeye başladıkça, isteklerinde değişiklik yapma eğilimindedirler.
    - Dış koşullar değişim içerisindedir ve projelerin bunlardan etkilenerek değişime uğramaları kaçınılmazdır.
      Ş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 edebilecektir. Müşteri tamamlanan yazılım sistemini tüm artı ve eksileriyle kabullenmek ve kullanmak zorundadır. Dolayısıyla tüm gereksinimlerin en başta tanımlanıp daha sonra geri dönülememesi prensibi ürün geliştirme sürecinde oluşabilecek her türdeğişikliği göz ardı etmek demektir.

  • Müşterinin talebinin anlaşılması ve tüm gereksinimler için detaylı dokümanların oluşturulması, yazılımcının bunları okuyup uygulaması, test aşamasında oluşabilecek herhangi bir hatada her şeyin sil baştan yapılması; projenin hayata geçme süresini uzatacaktır.

  • Başlangıçta yapılan hataların tespiti çok uzun zaman alabilir. Bu hataların giderilmesi maliyeti yükseltecektir.

2. Agile (Çevik) Modeli
Agile Modeli yazılım geliştirme sürecinde karşılaşılan (bizim waterfall modeliyle örnek verdiğimiz) problemleri çözmek üzere çıkmış, tekrarlanan yazılım geliştirme modeli taban alınarak geliştirilmiş, sık aralıklarla parça parça yazılım teslimatını ve değişikliği teşvik eden bir yazılım geliştirme modeli. 1970'li yıllardan itibaren uygulanmaya başlanmış. 2001 yılında 17 profesyonel Amerikalı tarafından Agile (Çevik) Manifestosu yayınlanmış.

Agile (Çevik) Manifestosu
1. Bireyler ve etkileşimi, süreç ve araca tercih etmek.
2. Çalışan bir yazılımı, detaylı belgelendirmeye tercih etmek.
3. Müşteri ile işbirliğini, sözleşmedeki kesin kurallara tercih etmek.
4. Değişiklere uyum sağlayabilmeyi, belirli bir plana tercih etmek.

(Soldaki
lerin sağdakilere göre üstünlüğü kabul edilir. Fakat bu sağdaki unsurların önemsiz olduğu anlamına gelmemelidir.)

Agile Modeli, waterfall modelinde olduğu gibi tüm gereksinimleri en başta belirleyip analiz aşamasını bitirdikten sonra tasarım-geliştirme-test aşamalarına geçmektense işi parçalara bölüp bu süreci işletmeyi amaçlar.

Örnek verecek olursak ColorNote gibi bir uygulama yapacağımızı düşünelim.

Waterfall modeline göre yapmak istediğimizde öncelikle t
üm gereksinimlerimizi düşüneceğiz:

- Kullanıcıların yapacakları şeyleri listeleyeceği, not alabileceği bir ekran.
- Kullanıcıların yapacakları şeyleri hatırlatacak alarm sistemi.
- Kullanıcıların yapacakları şeyleri nerde yapacaklarını belirtecekleri lokasyon belirtme aracı.

Waterfall modelinde; bunun gibi belki 10 tane daha gereksinim yazıp bunları hangi program kullanılacaksa, o programın gerektirdikleriyle birlikte tasarımını yapıp uzun bir doküman hazırlayıp yazılımcıya teslim etmemiz gerekiyor, yazılım geliştirme aşamasından sonra test edilecek; müşterinin gereksinimlerinde bir değişiklik olduğunda
herhangi bir hata olması halinde ya da test aşamasında herhangi bir hata olması durumunda tekrar en başa dönülecek.

Agile modelinde ise; her bir gereksinim üzerinden bu süreç yürütülecek.
  • Yani diyeceğiz ki; biz önce bir notepad şeklinde insanların sadece yapacakları şeyleri listeleyeceği bir ekran yapalım. Bu uygulamaya konduktan sonra son kullanıcıdan, yazılım ekibinden ya da bizden bu projeyi isteyen yatırımcıdan feedback alabileceğiz. Ve belki de diyecek ki son kullanıcı: "İş hayatımı ve özel hayatımı ayırmak istiyorum ben, notlarımı farklı renklerde yapabileyim", "Not aldığım ekrana .doc, .pdf uzantılı dokümanlar ekleyebileyim". Bu şekilde geri bildirim aldığımızda projemizde değişiklik yapabileceğiz.
  • Belki de proje için fazla para harcıyoruz. Bunu projenin en başında farkedebileceğiz ve bundan sonraki süreci ona göre ayarlayabileceğiz. Bu da bizim maliyetimizi düşürecek.
  • Waterfall gibi klasik yöntemlerle oluşabilecek herhangi bir hata için tüm sistemin sil baştan dönmesi gerekirken burada hatayı en baştan farkedebileceğiz. Bu da bizim sürecimizi kısaltacak. 
Dolayısıyla Agile modeli sayesinde boşu boşuna para, zaman ve emek harcamamış olacağız.
Agile Modeli içerisinde en çok kullanılan metodolojileri (frameworkleri) şu şekilde sıralayabiliriz:

> Scrum
> Kanban
> Lean
> Extreme Programming (XP)
> Crystal
> Test-Driven Development
> Feature-Driven Development (FDD)
> Dynamic Systems Development Method (DSDM)

Kaynaklar

  • http://www.acm-software.com/Pdf/AboutAgile.pdf 
  • http://www.bimetri.com/urunler/yazilim/ozel/yazilim-gelistirme-metodolojilerimiz/
  • https://tr.wikipedia.org/wiki/Waterfall_model
  • http://kod5.org/agile-proje-yonetim-metodolojisi/
  • http://www.yazilimheryerde.com/2014/09/agile-metodoloji-scrum.html
  • http://www.isanalizinedir.com/index.php?option=com_content&view=article&id=53:sdm&catid=39:yazilim-gelistirme-metodoloji&Itemid=56
  • https://www.youtube.com/watch?v=Gxz1kgL5GZ8
  • https://www.youtube.com/watch?v=ntVAryrzlOE
  • https://www.youtube.com/watch?v=_U7Py7W-Qng


   







Share:

0 yorum:

Yorum Gönder

Pages

Blog Archive