9.DERS Yazılım Geliştirme Modelleri

Transkript

1 9.DERS Yazılım Geliştirme Modelleri 1

2 Yazılım Geliştirme Yaşam Döngüsü ve Modeller Herhangi bir yazılımın, üretim aşaması ve kullanım aşaması birlikte olmak üzere geçirdiği tüm aşamalar olarak tanımlanabilir. Yazılım işlevleri ve ihtiyaçlar sürekli değiştiği ve geliştiği için bir döngü biçiminde düşünüle bilir. Yazılım yaşam döngüleri tek yönlü, doğrusal olarak düşünülmemelidir. 2

3 Yazılım Yaşam Döngüsü Temel Adımları PLANLAMA ANALİZ TASARIM GERÇEKLEŞTİRİM BAKIM 3

4 Planlama Personel ve donanım gereksinimlerinin çıkarıldığı, fizibilite çalışmasının yapıldığı ve proje planının oluşturulduğu aşamadır. Analiz Sistem gereksinimlerinin ve işlevlerinin ayrıntılı olarak çıkarıldığı aşama. Var olan işler incelenir, temel sorunlar ortaya çıkartılır. 4

5 Tasarım Belirlenen gereksinimlere yanıt verecek yazılım sisteminin temel yapısının oluşturulduğu aşamadır. Gerçekleştirim Kodlama, test etme ve kurulum çalışmalarının yapıldığı aşamadır. Bakım Hata giderme ve yeni eklentiler yapma aşaması (teslimden sonra) 5

6 Gelişigüzel Model Herhangi bir kuraldan bağımsız, yalnızca geliştiren kişiye bağımlı modeldir. Bazı durumlarda geliştiren kişi belirli bir zaman sonra kendisin bile anlayamadığı bir modeldir. Bundan dolayı yer yer değiştirme zorluğu yaşanabilir. geçirilmiştir. 60 lı yıllarda tek kişinin ürettiği programlar bu yöntemle Basit öğrenci projelerin de bu metot kullanıla bilir. hayata 6

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

8 BAROK Modeli Yaşam döngüsü temel adımlarının doğrusal bir şekilde geliştirildiği model. 70 li yıllarda kullanılan model. 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ımlanmamıştır. 8

9 Çağlayan Modeli 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 9

10 Çağlayan Modeli Yaşam döngüsü temel adımları en az bir kez izlenir. 70 li yılların ortalarında yapısal programlama ile kullanılmaya başlanan bu modelin kullanımı günümüzde azalmıştır. Belgeleme üretimin doğal bir süreç olarak algılar. İyi tanımlı projeler ve üretimi az zaman gerektiren projeler için uygundur. Belirsizlik oranı düşükse ve az zaman alacağı öngörülüyorsa (küçük boyutlu yazılımlar,personel takip,bütçe vb.) kullanımı önerilir. 10

11 Çağlayan Modelde Yaşanacak Sorunlar Günümüzde yapılan gerçek yaşamdaki projelerin çok azı yineleme gerektirmez Yazılımın kullanıcının kullanımına sunma süresi oldukça uzundur. Sonradan çıkan ihtiyaçları karşıma imkanı oldukça zordur. Buda sistemin maliyetini artılır. 11

12 Yazılım üretim ekipleri bir an önce program yazma, çalıştırma ve sonucu görme eğilimindir. Bu modelle yapılan ürün elde etme süresi uzun olduğu için ekip mutsuzlaşmaktadır. Kod yazma dışında kalan kısıma önem vermemektedirler. Ü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. 12

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

14 V Süreç Modeli Sol taraf üretim, sağ taraf sınama işlemlerini içerir V süreç modelinin temel çıktıları üç bölümde inceler; 1. Kullanıcı Modeli 2. Mimari Model 3. Gerçekleştirim Modeli 14

15 Kullanıcı Modeli: Geliştirme sürecinin kullanıcı ile olan ilişkileri tanımlar. Sistemin nasıl kabul edileceğine ilişkin sınama durumlarını ve planları ortaya koyar. Mimari Model: Sistem tasarımı ve oluşacak alt-sistem ile tüm sistemin sınama işlemlerini içerir Gerçekleştirim Modeli: Yazılım modüllerinin kodlanması ve sınanmasına ilişkin fonksiyonları içerir 15

16 V Süreç Modeli Avantajları Belirsizliklerin az, iş tanımlarının açıkça yapıldığı için BT projeleri için uygun bir modeldir. Model, kullanıcının geri beslemeler verdiği için projeye katkısını arttırmaktadır. BT projesinin iki aşamalı olarak uygulaması için uygundur: İlk aşamada kullanıcı modeli hedeflenerek, iş analizi ve kabul sınamalarının tanımları yapılmakta, İkinci aşamada ise ilkinde elde edilmiş olan kullanıcı modeli tasarlanıp, gerçekleştirilmektedir 16

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

18 Helozonik Spiral Model Bu modelde Risk Analizi önemli bir konuma gelmiştir. Her döngü bir fazı ifade eder. Yinelemeli artımsal bir yapı takip edilmiştir. Prototip yaklaşımı ön plana çıkmıştır. 18

19 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 durumların belirlenmesi Üretim Ara (prototip) ürünün üretilmesi Kullanıcı Değerlendirmesi Ara ürünlerin kullanıcı tarafından kullanılarak test edilmesi 19

20 Helezonik modelin avantajları Kullanıcı Katkısı : Üretim süreci boyunca ara ürün üretme ve üretilen ara ürünün kullanıcı tarafından denenmesi temeline dayanır. Yazılımı kullanacak kişilerin sürece katılması ileride meydana gelecek durumların önceden tespiti demektir. Yönetici Bakışı : Yöneticiler ve proje çalışanları iç içe çalışmaktadır. Bundan dolayı yöneticiler proje takibini daha kolay yapmaktadır. Yazılım Geliştirici (Mühendis) Bakışı :Yazılımın kodlanması ve sınanması daha erken başlar 20

21 Evrimsel Geliştirme Modeli Eşzamanlı Aktiviteler Tanımlama İlk Sürüm Genel Tanımlama Geliştirme Ara Sürümler Test Etme Son Sürüm 21

22 Evrimsel Geliştirme Modeli İlk tam ölçekli modeldir. Coğrafik olarak geniş alana yayılmış, çok birimli organizasyonlar için önerilmektedir (banka uygulamaları). Her aşamada üretilen ürünler, üretildikleri alan içinde tam işlevselliği sahiptir. Pilot uygulama alanlarında sistemi kullan, test et, güncelle diğer birimlere taşı prensibi geçerlidir. Modelin başarısı ilk evrimin başarısına bağımlıdır. 22

23 Evrimsel Geliştirme Örnek Durum Çok birimli sistem uygulamalarında kullanılır. Önce sistem bütün özellikleri ile geliştirilir ve uygulama alanı 1 yüklenir. Uygulama 1 alanındaki aksaklıklar tespit edilerek giderilir. Geliştirilen sistem uygulama alanı 2 yüklenir ve çalıştırılır. Daha sonra geliştirilen sistem diğer alanlara yüklenerek takip edilir. Belirli aralıklarla eski uygulama alanları kontrol edilerek gerekli güncellemeler yapılır. En sonunda son sürümü elde edilir. 23

24 Artırımsal Geliştirme Modeli Genel Gereksinim Belirlenmesi Gereksinimleri Artırımlara Bölme Sistem Mimarisini Tanımlama Sistem Artırılımının Yapılması Artırılımın Onaylanması Artırılımın Birleştirilmesi Sistemin Onaylanması Son Sistem Bitmemiş Sistem 24

25 Artırımsal Geliştirme Modeli İlk başta çekirdek yapıda olan ilk sürüm oluşturulur. Daha sonraki artırımlarda isterlerin bir kısmı daha gerçekleştirilerek çekirdek ürüne yeni işlevler kazandırılır. Her ürün bir öncekinden daha fazla işleve sahiptir. Öğ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 25

26 Araştırma Tabanlı Model Yap-at prototipi olarak ta bilinir. Araştırma ortamları bütünüyle belirsizlik üzerine çalışan ortamlardır. Yapılan işlerden edinilecek sonuçlar belirgin değildir. Geliştirilen yazılımlar genellikle sınırlı sayıda kullanılır ve kullanım bittikten sonra işe yaramaz hale gelir ve atılır. Model-zaman-fiyat kestirimi olmadığı için sabit fiyat sözleşmelerinde uygun değildir. 26