YAZILIM MÜHENDİSLİĞİ-1

Transkript

1 YAZILIM MÜHENDİSLİĞİ-1 BÖLÜM 2: YAZILIM YAŞAM DÖNGÜSÜ MODELLERİ Bölüm Kapsamında İncelencek Konular: Teoride yazılım geliştirme Winburg örnek olay incelemesi Winburg örnek olay incelemesinden çıkarttığımız dersler Teal Tractors örnek olay incelemesi Iteration and Incrementation (Tekrarlıyarak Aşamalı Büyüme) Winburg örnek olayını tekrar inceleme Iteration and Incrementation ın riskleri ve diğer yönleri Iteration and Incrementation yönetimi Diğer yaşam döngüsü (life-cycle) modelleri Yaşam döngüsü (life-cycle) modellerinin karşılaştırılması Gerçek dünyada yazılım, bir işe sıfırdan başlayarak, gereksinimler, analiz, tasarım ve gerçekleştirme adımlarının doğrusal olarak tanımlanmasıyla geliştirilmektedir

2 Pratikte yazılım geliştirme iki nedenden dolayı oldukça farklıdır. Bu nedenler; Yazılım geliştiricileri sonuçta insandır ve hata yapabilirler. Yazılım ürünü geliştirilirken, müşterinin gereksinimleri değişebilir. (moving target problem) - 2 -

3 WINBURG Mini Case Study Hindistan ın Winburg kentinde, kent merkezindeki trafik tıkanıklığının azaltılması amacıyla kent e genel bir taşımacılık sistemi kurulması için belediye başkanı ikna edilir. Yalnızca otobüslerin kullanımı için bir trafik şeridi oluşturulur ve evden işe yolculuk edenler, "sür ve park et" kampanyasına teşvik edilerek, iş yerlerine gidenlerin şehir merkezi dışında ki otoparklara arabalarını park etmeleri ve işe buradan otobüsler vasıtasıyla 1 dolar ücret vererek gitmeleri sağlanacaktır. Herbir otobüs yanlızca 1 doları kabul eden bilet makinesine (fare machine) sahip olacaktır. Yolcular, otobüse binerken bilet makinesinin içindeki yuvaya kâğıt parayı yerleştireceklerdir. Sensorlar bilet makinesinin içindeki kâğıt parayı tarayacaktır. Makine içinde yüklü olan yazılım, görüntü tanıma algoritmalarını kullanarak, yolcunun makine içindeki yuvaya yerleştirdiği kâğıt paranın gerçek olup olmadığına karar verecektir. Burada önemli olan nokta, yolcu kâğıt para yerine, kâğıt para ebatında bir gazete parçasıda koyabilir. Makinenin bunu ayırt etmesi gerekiyor, yoksa makine kazanç sağlamaz zarar eder. Aksine, eğer makine düzenli olarak gerçek kâğıt dolarları da reddederse, yolcular otobüsü kullanmaya isteksiz olacaklardır. İlaveten, bilet makinesi hızlı olmalıdır. Bilet makinesi, kâğıt doların gerçek olup olmadığına saniye gibi sürede karar verirse, bu yolcuların otobüse binmelerinin zaman almasına neden olacağından, yolcular otobüsü kullanmaya isteksiz olacaklardır. Bu nedenle, bilet makinesi yazılımı için gereksinimler, 1 saniyeden daha az bir ortalama bekleme zamanı ve en az % 98 doğruluk içerir. Episode 1: İlk sürüm uygulandı. % 2 hata yapma olasılığı tespit edildi ve sistemin yavaş olduğu farkedildi

4 Episode 2: Bir hata bulundu. Bir uygulama (implementasyon) hatasından dolayı sistem çok yavaşladı (deneyim eksikliğine bağlı olarak %98 doğruluğu başarmak için çift duyarlıklı sayılar kullanılmıştır). Uygulamada (implementasyon) değişiklikler meydana geldi. (tek duyarlıklı sayılar kullanılacaktır) Episode 3: Gereksinimler değişti ve daha hızlı bir algoritma kullanıldı. (önceden karmaşık bir görüntü tanıma algoritması kullanılmıştı, ortalama bekleme süresi 4,5 saniyenin üzerindeydi) Episode 4: Yeni tasarım uyarlanmıştır. Geliştirme (development) safhası sona ermiştir. (% 98 başarıdan memnun değil, % 99,5 başarı bekleniyor. Tasarım (design) değişiyor, bununla birlikte uygulama (implementasyon) da değişiyor.) Epilogue: Birkaç yıl sonra benzer problemler yeniden beliriyor. (Bilet makinesi içindeki sensorlar demode oluyor, yöneticiler donanımı yükseltmeye karar veriyorlar. Yeni donanım beraberinde yeni bir yazılımı gerektiriyor... vs.) Sonuç olarak eski yazılımı ve donanımı emekliye ayırıyoruz

5 Yaşam Döngü Modeli (Life-Cycle Model): Bir yazılımın geliştirilmesi ve bakımı süresince icra edilen adımlar topluluğuna yaşam döngü modeli denir. Evolution- Tree Life-Cycle Model, Waterfall Life-Cycle Model, Iterative and Incremental Life-Cycle Model, Code and Fix Life-Cycle Model, Rapid-Prototyping Life-Cycle Model, Open-Source Life-Cycle Model. Çağlayan Modeli (basitleştirilmiş bir versiyonu) Doğrusal yaşam döngüsü modelinde daima geribesleme döngüleri vardır. Çağlayan modelinde, Evolution-Tree Model deki gibi olayların sırası gösterilmez. Design esnasında bir hata bulunduğunda, requirements taki bir hata buna neden olmuş olabilir. Böyle bir durumda geliştirici, design dan analysis e, buradan da requirement safhasına geri dönebilir. Hatayı düzelttikten sonra sırasıyla tekrar design safhasına geri dönebilir

6 Evrimsel-ağaç modeli çağlayan modelinin geliştirilmiş bir şeklidir. Gerçekleştirilecek büyük bir proje küçük parçalara ayrılır. Parçalara ayrılan sistem yavaş bir şekilde geliştirilir. Gereksinimler, tasarım, kodlama, sınama aşamaları paralel veya teker teker gerçekleştirilir. Her parça için küçük çapta bir çağlayan modeli uygulanır. Evolution-Tree Life-Cycle Model de olayların sırası kesin olarak bellidir. Evolution-Tree Life-Cycle Model de, herbir episodun sonunda elimizde çalışan bir ürün (product) var. Buna baseline (dayanak) denir. Örneğin; Episode 4 ün sonunda, Requirements 4, Analysis 4, Design 4, Implementation

7 Gerçek dünyada yazılım geliştirme, Winburg mini case study den daha karmaşıktır. Değişikliklere her zaman ihtiyaç vardır. - Bir yazılım ürünü, sürekli değişim içindeki gerçek dünyanın bir modelidir. - Sonuç olarak yazılım geliştiricileri insandır, bu yüzden hata yapabilirler

8 TEAL TRACTORS Mini Case Study Teal Tractors Incorporation, Amerika Birleşik Devletlerinin birçok bölgesinde traktör satmaktadır. Şirket yazılım bölümünden, şirket faaliyetlerini bütün bakış açılarıyla ele alabilen yeni bir yazılım ürünü geliştirmesini talep eder. Örneğin yazılım ürünü, satışlardan toplanan gelir miktarını ve envanteri ele alabilmeli, ayrıca bütün gerekli muhasebe fonksiyonlarını yerine getirebilmelidir. Bu yazılım ürünü uygulanırken, Teal Traktörleri, bir Kanadalı traktör şirketini satın alır. Teal Traktörlerinin yönetimi; kazancını arttırmak için, Kanada gerçekleştirilen işlemlerin, ABD işlemleri içinde birleştirilmesine karar verir. Geliştirilmekte olan yazılım ürününün tamamlanmadan önce değiştirilmek zorunda olduğu ifade edilir. İhtiyaç duyulan değişiklikler aşağıdaki maddeleri içerir; İlave satış bölgeleri eklenebilmelidir. Ürün Kanada da uygulanan vergi sistemiyle baş edebilmeli ve diğer iş yerlerinden daha farklı bir bakış açısı izlemelidir. Program bu yeni vergiler göre yapılmalıdır

9 USD & CAD gibi iki farklı para birimini ele alarak, yazılım ürünü genişletilmelidir. Bu değişiklikler şirket için iyi, ama yazılım ürünü için bir felaket olur. Bu değişiklikleri yapmak istediğimizde yazılım ürününü değiştirmek zor ve problem olabilir. Eğer yazılım ürününün design ı yaparken ileride değişiklik olabilecek şekilde yapılırsa, sorun en aza inmiş olur. (geliştirilebilir design = extensible design) - 9 -

10 Moving Target Problem (Değişen Hedef Problemi): Bir yazılım geliştirilirken müşterinin gereksinimlerinde sürekli değişiklik olursa buna moving target (değişen hedef) problemi denir. Değiştirme nedenleri iyi olsa bile, yazılım ürünü bu değişikliklerden kötü olarak etkilenebilir. Yazılım ürününde yapılan herhangi bir değişiklik, potansiyel olarak bir regresyon hatasına neden olabilir. Eğer değişikliklerden dolayı çok fazla hata varsa, bütün yazılım ürünü tekrar design ve tekrar implement e olur

11 Değişim kaçınılmaz olur. - Büyüyen, gelişen şirketler sürekli değişim içindedir. - Değişimler için bireysel isteklerin yeterli bir açıklaması varsa, değişim hakkında hiçbir şey yapılamaz. Moving target problemi için çözüm yoktur. Moving target probleminden dolayı, asıl yazılım ürünlerinin yaşam döngüsü, şekil 2.1'in idealleştirilen yaşam döngüsü zincirinden ziyade, evrimsel ağaç modeline (şekil 2.2) veya çağlayan modeline (şekil 2.3) benzer. Bu gerçeğin önemli bir sonucu, Iteration ve Incrementation için zorunluluktur

12 Iteration and Incrementation (Tekrarlama ve Büyüme) Gerçek hayatta analiz safhasından bahsedemeyiz. Analiz safhasının işlemleri bütün life-cycle ın üzerine yayılır. Benzer olarak Şekil 2.2 de implementasyonun 4 farklı versiyonu gösterilmektedir. Yazılım geliştirme iteratif bir süreçtir. Her süreçte sonuca biraz daha yaklaşılmaktadır. Iteration olmadan yazılım mühendisliği çalışmaz. Her modelde (waterfall, rapid prototype,...) iterasyon vardır. Her iteration da (tekrarlamada), product büyüyor

13 Miller ın kanununa göre insan, bir birim zamanda sadece 7 ± 2 ayrı birime konsantre olabilir. Bu kısıtlamayı aşmak için Adım Adım İyileştirme (Stepwise Refinement) kullanılır. Elimizde çok fazla bilgi varsa, biz bu bilgileri adım adım arıtmalıyız. Önce çok önemli kabul edilen 7 parça ile çalışıyoruz. Sonuçta herşeyin üzerinde çalışılacak, ama adım adım ilerlenecek. Bu artan bir süreçtir. Böylelikle bütün bilgileri kullanmış oluyoruz

14 Önce bir parçasını yapalım; Increment A: Sonunda çalışan bir program var. Increment B: Yeni bir şey ilave etmek istiyoruz. Daha fazla analiz yapıyoruz. Design ve implementasyona da başlıyoruz. Increment C: Requirement bitiyor. Analysis neredeyse bitiyor. Design ve implementasyon yoğun bir şekilde gerçekleşiyor. Kodlama fazla olduğundan test te fazla yapılıyor. Increment D: Ürünü teslim ederken yapılan testler yoğunlukta. Her increment içersinde iterasyon olabilir. Sonuç olarak life-cycle ın başında requirements workflow ağırlıklı (predominates) olarak yapılıyor. Life-cycle ın sonunda ise implementation ve test workflow ları ağırlıklı (predominates) olarak yapılıyor

15 Iteration and incrementation, birbirlerini birlikte kullanırlar. - Tek bir requirements phase veya design phase yoktur. - Onun yerine, her safhanın çeşitli örnekleri vardır. Herbir bileşen, ilk olarak gereksinimler, sonra analiz,..., vs. gibi parça parça inşa edilir. Her büyüme (increment), çeşitli uyarlamalar (sürümler) boyunca devam eder. Burada herbir episode bir incrementation a karşılık geliyor

16 Büyümelerin sayısı değişecektir. Dört olmak zorunda değildir. Büyümenin sayısı, üründen ürüne değişir. Şekil 2.4, bir yazılım ürününün, nasıl geliştirildiğinin tam bir temsili değildir. Onun yerine, şekil 2.4, bir iterasyondan bir diğerine üzerinde durulan noktanın nasıl değiştirildiğini gösterir. Örneğin, şekil 2.2'in ilk iterasyonunda, dört safhanın her biri, dikkate alınır, oysa ikinci iterasyonda bir tek implementasyon dikkat alınıyor

17 Gerçek dünyada şekil 2.1 deki gibi sıralı aşamalar mevcut değildir. Bunun yerine, beş temel işakışı (workflows) bütün life-cycle boyunca gerçekleştirilir. - Requirements workflow - Analysis workflow - Design workflow - Implementation workflow - Test workflow

18 Beş temel işakışının (workflows) tamamı, bütün life-cycle boyunca gerçekleştirilir. Buna rağmen, zamanların çoğunda bir workflow baskın olur. Örneğin; life-cycle ın başında requirements workflow u ağırlıklı (predominates) olarak yapılıyor. Life-cycle ın sonunda ise implementation ve test workflow ları ağırlıklı (predominates) olarak yapılıyor. Planlama ve dokümantasyon aktiviteleri life-cycle boyunca gerçekleştirilir. Test etmenin, her iterasyon esnasında ve özellikle her iterasyon sonunda önemli bir aktivite olduğu farkedilmektedir. Üstelik yazılım tamamlandığı andan itibaren bir bütün olarak test edilir

19 Tekrarlama (iteration), herbir incrementation (büyüme) boyunca yapılır. Iteration ların (tekrarlama) sayısı değişecektir. Şekil 2.5 deki gibi üç olmak zorunda değildir. Iteration ların (tekrarlama) sayısı, üründen ürüne değişir

20 Bir sonraki slide ta iterative-and-incremental life-cycle model üzerine evolution-tree model i ekledik. O slide üzerinde evolution-tree model in sürekli test yaptığını farzederek test workflow unu çıkarttık

21 Herbir episode, bir increment e karşılık gelmektedir. Her increment, her workflow u kapsamaz. Increment B tamamlanmamıştır. Kesikli çizgi, örnekleri üçünde de corrective maintenance (düzeltici bakımı) ifade etmektedir

22 Iteration and Incrementation ın Riskleri ve Diğer Yönleri: Iteration ve incrementations kullanılarak geliştirilmiş bir proje, küçük projelerden (her increment bir proje) meydana gelmiş projeler bütünü olarak kabul edilir ve her increment in sonunda baseline (kısmi product) ortaya çıkıyor. Her bir küçük proje aşağıdaki artifact leri (yazılım bileşenleri) içerir. o Requirements artifacts o Analysis artifacts o Design artifacts o Implementation artifacts o Testing artifacts En sonunda yazılım ürünü tamamlanarak, ortaya çıkıyor

23 Her küçük proje esnasında; Artifact leri genişletebiliriz. (incrementation-büyütme) Artifact leri kontrol edebiliriz. (test workflow ları sayesinde) Eğer gerekliyse, ilgili artifact leri değiştirebiliriz. (iteration) Her bir iterasyon küçük bir eksiksiz çağlayan modeli (waterfall life-cycle model) olarak da düşünülebilir. Her iterasyon boyunca, yazılım ürününün bir kısmını seçeriz. Sistemin mimarisini, sistemin başında tespit ederiz. Bileşenlerin ortaya çıkışındaki ağaç şekli; requirements, analysis, design, implementation

24 Yazılım ürününün doğru olup olmadığını kontrol etmek için birçok seçeneğimiz var. - Her iterasyon test workflow unu içine dâhil eder. - Hatalar erkenden bulunur ve düzeltilir. Mimariğinin sağlamlılığı (robustness) life-cycle ın erken safhalarında belirlenir. - Architecture (mimari); çeşitli modül bileşenleri ve bunların birbirleriyle nasıl uyum içinde olacağı, - Robustness (sağlamlık); programın büyümeye ve değişikliklere karşı ne derece duyarlı olduğunun tespit edilmesini sağlayan özelliktir. Bu duyarlılığı programa hatalı veri vererek sağlıyoruz. Robustness önemli bir aşama. Ürün ne derecede sağlam ya da değil. Yeterli veri verildiğinde ürün ne şekilde tepki verecek. Bu aşamada sistemin ne derece akıllı olduğunu tespit ederiz

25 Riskleri erken safhada tespit edip, çözüm bulabiliyoruz. - Riskler yazılım geliştirme ve bakımı içinde her zaman olmaktadır. Her zaman risk söz konusudur, yanlış karar pahalıya mal olur. Elimizde yazılım ürününün başlangıcından beri çalışan bir model olacak ve istenirse müşteriye kısmi olarak ürün teslim edilebilecektir. Bu model bize erken safhalarda hataları bulmamız konusunda yarar sağlar. Iterative-and-incremental life-cycle model, waterfall model kadar disipline edilmiş bir modeldir. Çünkü iterative-and-incremental life-cycle model, sırayla uygulandığından waterfall model dir. Herbir increment, bir mini çağlayan projesidir

26 Birkaç yüz satırdan oluşan programlar için kullanılabilir. İlk safhada yazılım ürününün ilk sürümünü geliştiriyoruz. Direkt implementasyon var. Sistemi, en son istediğimiz şekle sokuncaya kadar devamlı geliştiriyoruz. (Loop) Bakım var ama çok zor. Çünkü sisteme ait dokümantasyon yok. Retirement safhası var

27 Yazılım geliştirmenin en kolay yoludur. En pahalısıdır. (Kodlamadan sonra bir yazılım ürünündeki değişikliklerin maliyetini düşünürsek, bu maliyet çok yüksektir. Buna ilave olarak, şartname ve tasarım dokümanı olmaksızın, ürünün bakımını yapmak fazkasıyla zordur.) Daha önce dediğimiz gibi, birkaç yüz satırdan oluşan programlar için kullanılabilir. Oldukça boyutlu ürünler için tamamen kabul edilemezdir. Yazılım geliştirmek kolay olduğu için ne yazık ki birçok yazılım projesinde bu model kullanılır

28 En eski, en tanınmış ve en temel modeldir. Bu modelde oluşturulacak sistemlerin her birini bir proje olarak ele almak gerekmektedir. Bu model bazı hükümet standartlarına girmiştir. Baştan tanımlanmış sistemler için daha çok tercih edilmektedir. Yazılımın üretilmesi aşamasında, yazılımcı ile müşteri çok sık bir araya gelmediği durumlarda uygulanan bir modeldir. Müşterinin istekleri farklılaşmayacaksa yani müşteri istekleri esnek değilse bu modelin kullanılması uygundur. Çağlayan modelinde işler aşama aşama yapılır. Bir aşama bitmeden diğer aşamaya geçilmez

29 Geridönüşüm loopları söz konusu, Her safhada dokümantasyon yazılmalı. Her şeyin dokümanının olması gerekir. Eğer bir safhada dokümantasyon ve test olmamışsa, o safhanın tamamlandığı kabul edilmez. (documentation-driven) Avantajları: - Dokümantasyon sağlıyor. - Bakımı kolaydır. - Development ya da design esnasında bir hata varsa kolay bir geri dönüş sağlar. Dezavantajları: - Requirements safhasında oluşturulan, specification dokümanı; detaylı, uzun, okunması ve anlaşılması müşteri için zordur. (Bu doküman formal, teorik bir dile sahiptir.) - Müşteri şartname dokümanını anlamayacağı için, ihtiyacı dışında bir şeyi kabul edebilir

30 Waterfall model ile benzerlikleri var, fakat waterfall daki gibi geriye dönüş yok. Lineer bir modeldir. Rapid Prototype da kullanıcı ile geliştirici arasında uzlaşma sağlandığında, geliştiriciler sistemin mimarisi hakkında bilgi sahibi olurlar. Böylelikle requirment safhasına gerek kalmaz. Requirement safhası yerine Rapid Prototype var!!! Rapid Prototype ile ürün hızlı bir şekilde geliştirilir. Kullanılan programlama dili bunu sağlamalıdır. Burada amaç; kullanıcının gereksinimlerini ortaya çıkarmaktır. Ana fonksiyonları gösterecek olan bir product geliştirilir, burada detaylar yoktur, sadece anahtar fonksiyonlar vardır. Yani, database kullanmak zorunda değilsiniz. Fonksiyonlar uygun veri giriş/çıkışlarıyla kullanıcıya gösterilmesi gerekir. Rapid Prototype ı kullanıcılara kullandırıp, gerçekten istenen ürünü sağlayıp sağlamadığı anlaşılıyor

31 Bir nevi Rapid Prototype ile requirement lar tespit ediliyor. Requirement doğru olduğu için, analysis çok daha kolay oluyor. Herşeyin mükemmel olmasıyla geriye dönüşlere (feedback loop) gerek kalmıyor. İleri ki safhalar hakkında bilgin oluyor. Program geliştirilirken, Rapid Prototype ta kullanılan programlama dilinden farklı bir programlama dili kullanılır. Rapid Prototype müşteri ile developer (geliştirici) arasındaki anlaşmazlıkları önler. Sistem geliştirildiğinde moving target problem ortadan kalkar. Çağlayan modelinin ve prototipleme yaklaşımının birleşmiş şekli olarak düşünülebilir

32 Proje dört ana başlığa ayrılır ve her başlık kendi içerisinde daha detaylı bir bakış açısıyla çözülmeye çalışılır. Her bir aşama için planlama geliştirme risk çözümleme, üretim ve kullanıcı değerlendirmesi yapılır. Risk analizi, gözlem, yaşam döngüsü planı, seçeneklerin değerlendirilmesi kısımları vardır. Her aşamada bir prototip oluşturulur. Bu prototipler geliştirilerek son prototip ortaya çıkartılır