YazIlIm Gelİ ş tİrme Süreç modellerİ

1. YazIlImGelİştİrme Süreç modellerİ Sibel SOMYÜREK

2. YazILIMgelİş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.

3. YazILIMgelİş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.

4. YazILIMgelİş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.

5. YazILIMgelİş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ımsalModel • Evrimsel Model • Yeniden Kullanılabilir Model

6. Gelişigü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.

7. Barok Modeli • İnceleme • Analiz • Tasarım • Kodlama • Modül Testleri • Altsistem Testleri • Sistem Testi • Belgeleme • Kurulum

8. Barok Modeli • 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.

9. Çağlayan (Şelale) Modeli • Ş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.

10. Gereksinimlerin Tanımlanması Sistem ve Yazılım Tasarımı Kodlama ve Modül test etme Birleştirme ve Sistemi test etme Sistemin Bakım ve İdamesi Çağlayan (Şelale) Modeli ? ? ?

11. Çağlayan (Şelale) Modeli • 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.

12. Çağlayan (Şelale) Modeli • 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

13. Çağlayan (Şelale) Modeli • Ş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.

14. Çağlayan (Şelale) Modeli • 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.

15. Çağlayan (Şelale) Modeli • 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.

16. Çağlayan (Şelale) Modeli • 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.

17. Planlama Risk Analizi Amaca, Alternatiflere ve Sınırlamalara karar verme Alternatifleri değerlendirme ve risk analizi Risk Analizi Risk Analizi Risk Analizi İşin Prototipi Prototip 3 Prototip 2 Risk Analizi Proto- tip 1 Öninceleme Analizi onay ekseni Simulasyon ve Modelleme İşin Genel Kavramı Yazılım Gereksinimi Ürün Tasarımı Detaylı Tasarım Gereksinim onaylama Geliştirme Planı Kodlama Tasarımı test Etme ve onay Modül Testi Birleştirme ve Test Planı Birleştirme testi Bir sonraki fazın planlanması ve kullanıcı değerlendirmesi Geliştirme ve bir sonraki ürünü onaylama Kabul testi Servis Kullanıcı Değerlendirme Üretim Helezonik (Sarmal) Model

18. 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.

19. Helezonik (Sarmal) Model • Planlama Üretilecek ara ürün için planlama, amaç belirleme, bir önceki adımda üretilen ara ürün ile bütünleştirme • Risk Analizi Risk seçeneklerinin araştırılması ve risklerin belirlenmesi • Üretim Ara ürünün üretilmesi • Kullanıcı Değerlendirmesi Ara ürün ile ilgili olarak kullanıcı tarafından yapılan sınama ve değerlendirmeler

20. Helezonik (Sarmal) Model • Risk Analizi Olgusu ön plana çıkmıştır. • Her döngü bir fazı ifade eder.

21. 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)

22. Prototip Modeli • 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.

23. Prototip Modeli • 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.

24. Prototip Modeli • 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.

25. Prototip Modeli • 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. • Prototiplemeyaratıldıktan sonra, müşteriye değerlendirme için verilir.

26. Prototip Modeli • 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

27. HIZLI UYGULAMA GELİŞTİRME Modeli • Ç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.

28. HIZLI UYGULAMA GELİŞTİRME Modeli • 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.

29. HIZLI UYGULAMA GELİŞTİRME Modeli • 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.

30. HIZLI UYGULAMA GELİŞTİRME Modeli 2 ay 2 ay 2 ay Geliştirme zaman Değerlendirme 1 hafta 1 hafta 1 hafta 1.Prototip hazır 2.Prototip hazır 3.Prototip hazır

31. HIZLI UYGULAMA GELİŞTİRME Modeli • 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.

32. Gereksinimler Sistem KULLANICI MODELİ Sistem Tanımları Bitmiş Sistem MİMARİ MODEL Sistem Sınanmış Sistem Altsistem Sınanmış Altsistem GERÇEKLEŞTİRİM MODELİ Modül Sınanmış Modül V Süreç Modeli

33. V Süreç Modeli • 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.

34. V Süreç Modeli • 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.

35. ARTIRIMSAL MODEL • Artırımsal model bir takvime bağlı olarak yazılımı kesim kesimgeliştirip teslim etmeye dayanır. • Her bir yeni kesim öncekinin üstüne bazı ek işlevlerin eklenmesini öngörür. • Artırımsalmodel 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.

36. 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.

37. Gereksinimleri Artırımlara Bölme Genel Gereksinim Belirlenmesi Sistem Mimarisini Tanımlama Sistemin Onaylanması Son Sistem Artırılımın Birleştirilmesi Artırılımın Onaylanması Sistem Artırılımının Yapılması Bitmemiş Sistem ARTIRIMSAL MODEL

38. 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.

39. Eşzamanlı Aktiviteler Tanımlama İlk Sürüm Ara Sürümler Genel Tanımlama Geliştirme Son Sürüm Test Etme EVRİMSEL Model

40. 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.

41. 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.

42. 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/