yazilim gelİ ş tİrme süreç modellerİ

YAZIL

IM G

ELİŞ

TİRM

E

SÜREÇ M

ODELLE

Rİ

Sİ B

EL S

OM

YÜ

RE

K

YAZILIM GELİŞTİRME SÜRECİ

• Yazılımın hem üretim, hem de kullanım süreci boyunca geçirdiği tüm aşamalar yazılım geliştirme yaşam döngüsü olarak tanımlanır.

• Yazılım yaşam döngüsündeki temel adımlar:• Analiz, • Çözümleme, • Tasarım,• Gerçekleştirme, • Test, • Bakım.

YAZILIM GELİŞTİRME SÜRECİ

• Yazılım işlevleri ile ilgili gereksinimler sürekli olarak değiştiği ve genişlediği için, söz konusu aşamalar sürekli bir döngü biçiminde ele alınır.

• Bu döngü tek yönlü ve doğrusal değildir.

YAZILIM GELİŞTİRME SÜREÇ MODELİ

• Yazılım geliştirme temel adımlarının nasıl gerçekleştirileceğine yönelik çeşitli yazılım geliştirme süreç modelleri kullanılmaktadır.

YAZILIM GELİŞTİRME SÜREÇ MODELİ

• Gelişigüzel Model• Barok Modeli• Çağlayan (Şelale) Modeli• Helezonik (Sarmal) Model• Prototip Model• Hızlı Uygulama Geliştirme Modeli• V Süreç Modeli• Artırımsal Model• Evrimsel Model• Yeniden Kullanılabilir Model

GELİŞİGÜZEL MODEL

• Herhangi bir model ya da yöntem yok.

• Geliştiren kişiye bağımlı (belli bir süre sonra o kişi bile sistemi anlayamaz ve geliştirme güçlüğü yaşar).

• İzlenebilirliği ve bakımı oldukça zor.

• 60’lı yıllarda.

• Genellikle tek kişilik üretim ortamı.

• Basit programlama.

BAROK MODELİ

• İnceleme

• Analiz

• Tasarım

• Kodlama

• Modül Testleri

• Altsistem Testleri

• Sistem Testi

• Belgeleme

• Kurulum

BAROK MODELİ

• Yaşam döngüsü temel adımlarının doğrusal bir şekilde geliştirildiği model.

• 70’li yıllar.

• Belgelemeyi ayrı bir süreç olarak ele alır, ve yazılımın geliştirilmesi ve testinden hemen sonra yapılmasının öngörür.

• Halbuki, günümüzde belgeleme yapılan işin doğal bir ürünü olarak görülmektedir.

• Aşamalar arası geri dönüşlerin nasıl yapılacağı tanımlı değil.

ÇAĞLAYAN (ŞELALE) MODELİ

Şelale yönteminde yazılım geliştirme süreci:• analiz, • tasarım,• kodlama, • test, • sürüm ve • bakım gibi safhalardan oluşur.


Sistem ve YazılımTasarımı

GereksinimlerinTanımlanması

Birleştirme ve Sistemi test etme

Sistemin Bakım ve İdamesi

Kodlama ve Modültest etme

?

?

?


• Neden şelale ismi?

• Merdiven • su kendiliğinden aşağıya iner ve • bir daha asla yukarıya çıkmaz

• Geleneksel model olarak da bilinen bu modelin kullanımı günümüzde giderek azalmaktadır.


• Yazılım geliştirme süreci klasik üretim süreçlerinden farklıdır.(Bulaşık makinesi-ütü)

• Geliştirme sürecinde gereksinimler ve planlama değişir,

• Müşterinin geliştirilen ürün hakkında sürekli bilgilendirilmesi gerekir

• İçeriğin yazılım geliştirme sürecinde değişmesi gerekir,

• Kilometre taşlarının değişmesi gerekir


• Şelale modeli yazılım geliştirmedeki bu riskleri görmezden geldiği için projeyi ana safhalara böler.

• Yazılım tanımlamada belirsizlik yok (ya da az) ise ve yazılım üretimi çok zaman almayacak ise uygun bir süreç modelidir.


• Sorunlar:• Gerçek yaşamdaki projeler genelde yineleme gerektirir.

• Gereksinim tanımlamaları çoğu kez net bir şekilde yapılamadığından dolayı,• yanlışların düzeltilme ve • eksiklerin giderilme maliyetleri yüksektir.


• Sorunlar:• Yazılım üretim ekipleri bir an önce program yazma, çalıştırma ve sonucu görme eğiliminde olduklarından,• bu model ile yapılan üretimlerde ekip mutsuzlaşmakta ve

• kod yazma dışında kalan (ve iş yükünün %80’ini içeren) kesime önem vermemektedirler.


• Sorunlar:• Üst düzey yönetimlerin ürünü görme süresinin uzun oluşu, • projenin bitmeyeceği ve• sürekli gider merkezi haline geldiği düşüncesini yaygınlaştırmaktadır.

Helezonik (Sarmal) Model

RiskAnalizi

RiskAnalizi

RiskAnalizi

RiskAnalizi

Proto-tip 1

Prototip 2Prototip 3

İşinPrototipi

Öninceleme

AnaliziİşinGenel Kavramı

GeliştirmePlanı

Birleştirme ve Test Planı

YazılımGereksinimi

Gereksinimonaylama

ÜrünTasarımı

Tasarımı testEtme ve onay

DetaylıTasarım

Kodlama

Modül TestiBirleştirme testi

Kabul testiServis

Simulasyon ve Modelleme

Amaca, Alternatiflere ve Sınırlamalara karar verme

Alternatifleri değerlendirme ve risk analizi

Bir sonraki fazın planlanması ve kullanıcı değerlendirmesi

Geliştirme ve bir sonraki ürünü onaylama

onay ekseni

Planlama Risk Analizi

ÜretimKullanıcı Değerlendirme

Helezonik (Sarmal) Model• Sarmal modeli aynı safhalara geri

dönülmesinin bir zorunluluk olduğunu vurgular,

• Sarmal modeli şelale modelinde yok sayılan riskleri göz önünde bulundurur,

• Proje çevrimlere ayrılır ve her bir çevrimin riskleri ayrı ayrı ele alınır.

• Çağdaş modellere son derece yakındır.

Helezonik (Sarmal) Model1. Planlama

Üretilecek ara ürün için planlama, amaç belirleme, bir önceki adımda üretilen ara ürün ile bütünleştirme

2. Risk AnaliziRisk seçeneklerinin araştırılması ve risklerin

belirlenmesi

3. ÜretimAra ürünün üretilmesi

4. Kullanıcı DeğerlendirmesiAra ürün ile ilgili olarak kullanıcı tarafından yapılan

sınama ve değerlendirmeler

Helezonik (Sarmal) Model• Risk Analizi Olgusu ön plana çıkmıştır.

• Her döngü bir fazı ifade eder.

Helezonik (Sarmal) Model• Dezavantajları:

• Yavaş ilerleyen bir süreçtir• Çok fazla işgücü maliyeti gerektirir• 1-2-4 no’lu (planlama, risk analizi, kullanıcı değerlendirme) safhalarda uygulama geliştiricilerin büyük çoğunluğu boşta kalır ve genel verimlilik düşer

• Örnek: Windows NT 4.0 (yaklaşık 1400 çevrim)

PROTOTİP MODELİ

• Gereksinimler hızlıca toplanarak işe başlanılır.

• Geliştiriciler ve kullanıcılar aynı masa etrafında buluşarak

• yazılımdan elde edilecek bütün çıktılara, • bu çıktılar için gerekli girdilerin nasıl sağlanacağına,

• nasıl korunacağına, • hangi işlemlere uğrayacağına karar verirler.

PROTOTİP MODELİ

• Daha sonra hızlıca yapılan bir tasarım ile yazılımın kullanıcıya yansıyacak yönünü aktaran bir prototip üretilir.

• Prototip kullanıcının kullanımına ve değerlendirilmesine sunulur.

• Bu değerlendirmelere bakılarak prototip üzerinde gerekli değişiklikler yapılır.

PROTOTİP MODELİ

• Prototipin yeni hali kullanıcı tarafından yeniden değerlendirilir.

• Böylece kullanıcının istediği yazılıma iyice yaklaşılmış bir prototip üzerinde yazılımın neler yapacağı konusunda kullanıcı ile anlaşmaya varılır.

PROTOTİP MODELİ

• Doğrusal modelin döngüsel versiyonudur.

• Bu modelde, gereksinim analizi ve prototipleme için tasarım yapıldıktan sonra,geliştirme süreci başlatılır.

• Prototipleme yaratıldıktan sonra, müşteriye değerlendirme için verilir.

PROTOTİP MODELİ

• Müşteri paketi test eder ve düşüncelerini, ürünü müşterinin tam beklentilerine göre düzenleyen geliştiriciye iletir.

• Sınırlı sayıdaki yinelemelerden sonra, son yazılım paketi müşteriye verilir.

• Bu metodolojide, yazılım müşteri ve geliştirici arasında periyodik bilgi gidip gelmeleri sonucunda gelişir

HIZLI UYGULAMA GELİŞTİRME MODELİ

• Çok kısa süreler içinde ortaya çıkartılan kapsamı daraltılmış alt sistemlere ilişkin yazılımlardır.

• Gerçekleştirimin hızlı yapılabilmesi genelde bileşen tabanlı olmasını gerektirir.

• Hazır bileşenler gereksinimleri karşılayabiliyorsa 60-90 gün içinde çalışan bir program ortaya çıkartılabilir.


• Belgelemeyi azaltmak fikrine dayanır

• Her çevrim sonunda çalışan bir prototip teslim edilir

• Çalışan prototip her türlü belgelemeden daha iyidir fikrini temel alır.


• Safhalar ve etkinlikler ayrılmıştır

• Problemler ayrılır ve her çevrimde bir ya da birkaçı çözülür

• Yazılım evrimleşerek istenene ulaşılır

• Sarmal modelinden en büyük farkı her çevrimin süresinin kısıtlı olmasıdır.


Geliştirme

Değerlendirme

zaman

2 ay 2 ay2 ay

1 hafta

1 hafta

1 hafta

1.Prototip hazır

2.Prototip hazır

3.Prototip hazır


• Dezavantajı:• Müşterinin sürekli olarak küçük işlevsellikler eklemesine fırsat tanır.

• Taciz etmeye baştan niyetli bir müşterinin yazılımın sonsuza dek geliştirmesine yol açabilir.

V SÜREÇ MODELİ

KULLANICI MODELİSistem Tanımları Bitmiş Sistem

MİMARİ MODELSistem Sınanmış Sistem

Altsistem Sınanmış Altsistem

GERÇEKLEŞTİRİM MODELİ

Modül Sınanmış Modül

Gereksinimler

Sistem

V SÜREÇ MODELİ

• Sol taraf üretim, sağ taraf sınama işlemleridir.

• V süreç modelinin temel çıktıları;

• Kullanıcı Modeli Geliştirme sürecinin kullanıcı ile olan ilişkileri

tanımlanmakta ve sistemin nasıl kabul edileceğine ilişkin sınama belirtimleri ve planları ortaya çıkarılmaktadır.

• Mimari Model Sistem tasarımı ve oluşacak altsistem ile tüm sistemin

sınama işlemlerine ilişkin işlevler.

• Gerçekleştirim Modeli Yazılım modüllerinin kodlanması ve sınanmasına

ilişkin fonksiyonlar.

V SÜREÇ MODELİ

• Belirsizliklerin az, iş tanımlarının belirgin olduğu BT projeleri için uygun bir modeldir.

• Model, kullanıcının projeye katkısını arttırmaktadır.

• BT projesinin iki aşamalı olarak ihale edilmesi için oldukça uygundur:İlk ihalede kullanıcı modeli hedeflenerek, iş analizi ve kabul sınamalarının tanımları yapılmakta,

İkinci ihalede ise ilkinde elde edilmiş olan kullanıcı modeli tasarlanıp, gerçeklenmektedir.

ARTIRIMSAL MODEL

• Artırımsal model bir takvime bağlı olarak yazılımı kesim kesim geliştirip teslim etmeye dayanır.

• Her bir yeni kesim öncekinin üstüne bazı ek işlevlerin eklenmesini öngörür.

• Artırımsal model yazılım geliştirmenin kısıtlı sayıda çalışanla işin yapılmasını sağlama gibi bir üstünlüğü vardır.

ARTIRIMSAL MODEL

• Üretilen her yazılım sürümü birbirini kapsayacak ve giderek artan sayıda işlev içerecek şekilde geliştirilir.

• Öğrencilerin bir dönem boyunca geliştirmeleri gereken bir programlama ödevinin 2 haftada bir gelişiminin izlenmesi (bitirme tezleri).

• Uzun zaman alabilecek ve sistemin eksik işlevlikle çalışabileceği türdeki projeler bu modele uygun olabilir.

• Bir taraftan kullanım, diğer taraftan üretim yapılır.

ARTIRIMSAL MODEL

Genel GereksinimBelirlenmesi

GereksinimleriArtırımlara Bölme

Sistem Mimarisini Tanımlama

Sistem ArtırılımınınYapılması

ArtırılımınOnaylanması

ArtırılımınBirleştirilmesi

Sistemin Onaylanması

SonSistem

Bitmemiş Sistem

EVRİMSEL MODEL

Coğrafik olarak geniş alana yayılmış, çok birimli organizasyonlar için önerilmektedir

Her aşamada üretilen ürünler, üretildikleri alan için tam işlevselliği içermektedirler.

EVRİMSEL MODELEşzamanlıAktiviteler

Tanımlamaİlk

Sürüm

GenelTanımlama

Son Sürüm

Geliştirme

Test Etme

AraSürümler

EVRİMSEL MODEL

• Çok birimli banka uygulamaları.

• Önce sistem geliştirilir ve Şube-1’e yüklenir.

• Daha sonra aksaklıklar giderilerek geliştirilen sistem Şube-2’ye yüklenir.

• Daha sonra geliştirilen sistem Şube-3’e,…. yüklenir.

• Belirli aralıklarla eski şubelerdeki güncellemeler yapılır.

Yeniden Kullanılabilir Model

• Organizasyon tarafından daha önce hazırlanmış veya dışarıdan temin edilmiş yazılımların kullanılması ile geliştirme yapılması son yıllarda popülaritesi artan bir yaklaşımdır.

• Organizasyonların olgunlukları arttıkça, bu tür uygulamalar yapmak için altyapı kurmaktadırlar.

KAYNAKÇA

• Güngören, B. (2005). UML ile Nesne Tabanlı Çözümleme ve Tasarım. Seçkin Yayıncılık. Ankara

• Ocak, Ş. & Yıldıztekin, M. (2011). Güvenli Yazılım Geliştirme Süreç Modellerinin Karşılaştırılması Uygulamaları. Elektrik-Elektronik Bilgisayar Sempozyumu (FEEB 2011). 338-342.

• Yılmaz, G. (2007). Yazılım Mühendisliği Bölüm – 2 Yazılım Geliştirme Yaşam Döngüsü. Ders notu.

• Yazılım Mühendisliği Rhxo Teknoloji Grubu. http://www.rhxo.com.tr/surecler/yazilim-muhendisligi/

http://www.rhxo.com.tr/surecler/yazilim-muhendisligi/

http://www.rhxo.com.tr/surecler/yazilim-muhendisligi/

yazilim gelİ ş tİrme süreç modellerİ

Documents