Cumhuriyet Üniversitesi Yazılım Mühendisliği Dersi

... konulu sunumlar: "Cumhuriyet Üniversitesi Yazılım Mühendisliği Dersi"— Sunum transkripti:

1 Cumhuriyet Üniversitesi Yazılım Mühendisliği Dersi
Bölüm 11 Yazılım Geliştirme Süreç Modelleri (Yinelemeli (Iterative) modeller) Halil ARSLAN Abdulkadir ŞEKER

2 Bölümün hedefleri Model karşılaştırmaları Protatipleme ve çeşitleri
Tahmine dayalı modeller Yinelemeli modeller Artırımlı modeller Çevik modeller Protatipleme ve çeşitleri Spiral Modeli Birleştirilmiş Süreç Modeli Cleanroom Modeli

3 Tamine Dayalı/Yinelemeli Modeller
Tahmine dayalı modeller beklenmedik değişimlere uyum sağlamakta zorlanırlar. Küçük değişimleri yansıtmak kolaydır ama büyük değişimlerde zor. Tahmine dayalı modeller başlangıçta ne yapılacağına karar vermek için fazlaca çalışma gerektirir. Gereksinim ve tasarım aşamasından sonra genellikle değişim zor olur. Değişiklik büyük olduğunda projeye yeniden başlamak gerekebilir. Tahmine dayalı modeller uzun vadeli planlar içerdiğinden değişikliklerde kayıp çok daha fazla olur. 5 yıllık bir projenin 3. yılında değişim sonucu proje iptalinde kayıp çok fazla olur. Tahmine dayalı modeller belirsiz gereksinimler için de dezavantajlıdır. Yinelemeli modeller uygulamayı aşamalı olarak oluşturur. Ardından program yeni özellikler ekleyerek uygulama bitene kadar yinelemeleri sürdürür.

4 Tamine Dayalı/Yinelemeli Modeller
Yinelemeli modellerde, uygulama aşamalı olarak tasarlanır ve kısa süreli artışlar gerektirir. Kullanışlı olan en küçük program parçası oluşturulmaya çalışılır. Herbir artış nispeten daha kısa süreler gerektirdiği için iptal durumlarında daha az kayıpla karşılaşılır. Projenin yanlış yöne gittiğine karar verilirse, yalnızca en son artış durdurulur ve tüm projeyi iptal etmek yerine yeni bir artış başlatılır. Yinelemeli modeller belirsiz gereksinimleri tahmine dayalı modellere göre daha iyi idare eder. Bazı gereksinimler net değilse net olan bileşenler tamamlanır ve belirsiz olan gereksinimler daha sonraya ertelenebilir. Çoğunlukla bazı bileşenler tamamlandıkça belirsiz gereksinimler netleşmeye başlar.

5 Model Karşılaştırması
Hedeflenen projenin 3 özelliğinin olduğu varsayılsın; Tahmine dayalı model (predictive): Tüm özellikleri tam uygunlukla aynı anda sağlar. Yinelemeli model (Iterative): İlk olarak tüm özellikleri düşük (ama kullanılabilir) bir uygunlukla sağlar. Daha sonraki yinelemlerde, tüm özellikler için tam uygunluk sağlanana kadar devam eder. Artırımlı model (Incremental): Başlangıçta kullanılabilir bir uygulama için mümkün olan en az sayıda özelliği sağlar. Ancak mevcut olan tüm özellikler tam uygunlukla sağlanır. Çevik model (Agile): Başlangıçta düşük uygunlukla en az özellikler sağlanır. Sonraki sürümler mevcut özelliklerin doğruluğunu geliştirir ve yeni özellikler ekler. Sonraki görselde tüm modeller 3 özelliği de tam uyumlulukla yerine getirmeyi hedefler ancak aralarındaki farklılık bunu nasıl gerçekleştirdikleridir.

6 Model Karşılaştırması

7 Protatip (ilk örnek) Bir protatip, görülmek istenilen bazı davranışları gösteren basitleştirilmiş bir modeldir. Bir yazılım protatipi, oluşturmak istenilen uygulamanın bir kısmını taklit eden bir programdır. Protatiplerle ilgili iki önemli özellik; Nihai uygulama gibi çalışmasına gerek olmaması, Nihai uygulamanın tüm özelliklerini içermesini gerektirmemesidir. Gereksinimlerin toplanması aşamasında müşteriye bitmiş uygulamanın nasıl görüneceği noktasında bir protatip sunulabilir. Oluşturulan protatipler hazır veriler ve örnek ekranlar içerebilir. Böylece müşteri protatipi kullandıktan sonra gereksinimleri iyileştirmek ve somutlaştırmak için geri dönüşler sağlayabilir. Protatipler yatay (çok özellik) yada dikey (az özellik ama derin) olarak hazırlanabilir.

8 Protatip Çeşitleri Üç çeşit protatip hazırlanabilir. Kullan-at, Evrimsel ve Artırımsal. Kullan-at protatip, Sistemin bazı özelliklerini incelemek için kulanılır ve daha sonra atılır. Evrimsel protatip, Uygulamanın bazı özelliklerini içerir ve proje ilerledikçe bu özellikler iyileştirilir. Protatip bitmiş uygulamaya dönüşünceye kadar iyileştirilmeye ve yeni özellikler eklenmeye devam eder. Artırımsal protatip, Bitmiş uygulamanın özelliklerini ayrı ayrı içeren bir protatip kolleksiyonu oluşturulur. Daha sonra bitmiş uygulamayı oluşturmak için bu protatipler birleştirilir. Evrimsel ve Artırımsal protatipte bitmiş uygulama protatip kodu içerir. Bu nedenle protatip oluşturma aşamasında da iyi programlama teknikleri kullanmak gerekir. Artırımsal protatip, daha uzun zaman gerektirmekle birlikte farklı ekiplerin aynı proje parçaları üzerinde çalışabilmesine olanak sağlar.

9 Protatip – Avantaj/Dezavantaj
Protatiplemenin ana avantajları; Geliştirilmiş gereksinimler: Protatipler, müşterilerin bitmiş uygulamanın nasıl görüneceğini görmelerine olanak sağlar. Bu da, projenin başındaki gereksinimleri değiştirmek için geri bildirim sağlamasını kolaylaştırır. Müşteriler sorunları tespit edebilir ve daha önce değişiklik talep edebilir. Ortak vizyon: Protatipler, müşterilerin ve geliştiricilerin, bitmiş uygulamanın aynı önizlemesini görmelerini sağlar. Böylece uygulamanın ne yapması gerektiği ve neye benzemesi gerektiği konusunda ortak bir vizyona sahip olmaları daha kolaydır. Daha iyi tasarım: Protatipler (özellikle dikey protatipler), geliştiricilerin, uygulamanın belirli parçalarının neler içerdiğini görmelerine ve bunları hızlıca keşfetmelerine izin verir. Geliştiriciler, tasarımı geliştirmek ve son kodu daha iyi ve sağlam hale getirmek için protatiplerden öğrendiklerini kullanabilirler.

10 Protatip – Avantaj/Dezavantaj
Protatiplemenin bazı dezavantajları ise; Daralan vizyon: Müşterilere (geliştiricilere) bir prototip gösterildiğinde, daha işe yarar olası alternatifleri düşünmeleri engellenebilir. Müşteri sabırsızlığı: İyi protatipler müşterinin protatipi bitmiş bir uygulama gibi algılamasına neden olabilir. Planlama baskısı: Müşteri bittiğini düşündüğü bir protatip gördüğünde planlamayı kısaltmak için ekibi zorlayabilir. Yükseltilmiş beklentiler: Bazen protatipler uygulamada olmayan özellikleri gösterebilirler. Bazı özellikler sonraki sürümler için düşünülmüş olabilir. Koda bağlama: Protatip kodu üzerinden devam eden geliştirmeler, düşük kaliteye sahip protatip kodlarında son uygulamanın kalitesiz kodlar içermesine neden olur. Bitmeyen protatipler: Bazen, geliştiriciler protatipin daha iyi görünmesi ve aslında gerekli olmayan daha fazla özellik içermesi için çok fazla zaman harcayabilir. Örneğin, bir protatip nadiren veritabanı kullanır.

11 Spiral Spiral model, 1986 yılında Barry Boehm tarafından tanımlanmıştır. Proje ekibinin, projenin çeşitli bölümleri için hangi geliştirme yaklaşımını benimseyeceğine karar vermesine yardımcı olmak için risk odaklı bir yaklaşım kullanır. Örneğin, tüm gereksinimler açık değilse, bunları geliştirmek için yinelemeli bir yaklaşım kullanılabilir.

12 Spiral Spiral yaklaşımı, dört temel aşamadan oluşmaktadır;
1. Aşama: Planlama aşamasıdır. Mevcut döngünün hedefleri belirlenir. Hedefler için alternatifler ve kısıtlar tanımlanır. 2. Aşama: Risk analizi aşamasıdır. Bu döngünün hedefine ulaşmasını engelleyebilecek risk faktörleri belirlenir. Riskler çözümlenir ve hedefe ulaşmak için protatipler hazırlanır 3. Aşama: Mühendislik aşamasıdır. Protatip üzerinden modele özgü sorunlar çözülür, çözümler modele yansıtılır, ve değerlendirilir. Somut çıktılar elde edilir. 4. Aşama: Değerlendirme aşamasıdır. Projenin paydaşları ile ilerleme değerlendirilir. İlgili aşamalar her çevrimde tekrarlanarak proje tamamlanır. İstenildiği kadar çevrim gerçekleştirilebilir. Her çevrim sonunda bir protatip elde edilir.

13 Spiral Spiral etrafındaki ilk çevrimde proje gereksinimleri oluşturulur. Ekip alternatifleri inceler, en büyük riskleri tanımlar (müşterilerin performans gereksinimleri belirsiz olabilir), riskleri giderir ve bir prototip gereksinim seti oluşturur. Ekip üyeleri daha sonra gereksinimleri analiz etmek ve doğru olduklarını doğrulamak için protatip oluşturur. Bu noktada, doğrulanmış gereksinimler gerçek gereksinimler haline gelir. Spiral etrafında bir sonraki çevrim uygulama tasarımını oluşturur. Ekip tasarım alternatiflerini değerlendirir, büyük riskleri tanımlar ve çözümler. Protatip tasarım oluşturur. Ekip üyeleri tasarımı analiz eder ve mantıklı olduğunu doğrular. Prototip tasarım daha sonra tasarım haline gelir. Spiral etrafındaki son çevrim, uygulamanın geliştirilmesidir. Ekip uygulama alternatiflerini değerlendirir. Riskleri tanımlar ve bunları çözer. Ekip daha sonra programın nasıl çalışacağını gösteren bir operasyonel prototip oluşturur. Her şeyin yolunda olduğunu doğrulamak için prototip kullanılır ve daha sonra uygulama oluşturulur. Bu çevrimde, uygulama adımları; ayrıntılı tasarım, programlama, birim testi, entegrasyon testi ve kabul testine ayrılmıştır. Bu örnek, gerçekleştirmek istenebilecek her çevrimi içermez. Örneğin, ayrı kullanıcı arayüzü tasarımı veya veritabanı tasarımı çevrimleri yapılmak istenebilir.

14 Spiral Spiral model geliştirildikten sonra pekçok düzenleme yapılmıştır. Bir spiral birbiri ardına yürütülen bir dizi şelale modeli değildir. Bir uygulamanın farklı sürümlerini oluşturmak için çoklu spiraller kullanılabilir. Faaliyetlerin tek bir çevrimi takip etme zorunluluğu yoktur. Örneğin, kullanıcı arayüz ve veritabanı tasarımını, genel bir proje çevriminde ayrı spiraller olabilir. Yeni öğeler eklenebilir, kaldırılabilir veya belirli bir çevrimsel modelde farklı sprirallerde uygulanabilir. Gerçekleştirmek istenen faaliyetler projeye bağlıdır. Boehm, spiral döngülerinin takip etmesi gereken altı özelliği şöyle tanımlar; Görevler aynı anda tanımlanabilir. Herşey sıralı olmak zorunda değildir. Her döngüde aşağıdaki 4 görev gerçekleştirilir. Tüm paydaşların hedefleri göz önünde bulundurulur. Paydaşların hedeflerini karşılamak için alternatifler tanımlanır ve değerlendirilir. Belirlenen yaklaşımın riskleri tanımlanır ve çözülür. Paydaşların mevcut döngünün sonuçlarının doğru olduğuna karar verdiğinden emin olunur. Bir sonraki çevrime geçmek için paydaşlardan onay alınır.

15 Spiral Boehm, spiral döngülerinin takip etmesi gereken altı özelliği şöyle tanımlar; Harcanacak eforu belirlemek için riskler kullanılır. Örneğin kötü kod riskini azaltmak için yeterli kod incelemesi gerçekleştirilir. Ayrıntı düzeyini belirlemek için riskler kullanılır. Örneğin uygulamanın müşteri beklentilerini karşılamama riskine karşı gereksinimlere yeterince zaman ayrılır. Ancak esnekliği kısıtlamamak için aşırıya gidilmemelidir. Projenin ilermemesini izlemek için kilometre taşları kullanın. Bunlar; Yaşam Döngüsü Hedefleri: Paydaşlar, projenin teknik ve yönetim yaklaşımının tüm paydaşların hedeflerini tatmin edecek şekilde tanımlandığını kabul ettiğinde ulaşılır. Yaşam Döngüsü Mimarisi: Paydaşların proje yaklaşımının, hedefleri karşılayabileceği ve önemli riskleri ortadan kaldırdığı/hafiflettiği konusunda hemfikir olduğunda ulaşılır. İlk Operasyonel Kapasite: İlk kullanım içim tatmin edecek yeterli hazırlık olduğunda ulaşılır. Hazırlıklar, projeyi başarılı hale getirmek için gereken her şeyi içerir. Örneğin, uygulama hazır ve test edilmiş, kullanıcılar eğitilmiş. Kod yazılması gibi kısa vadeli konular yerine sisteme ve yaşam döngüsüne odaklanın. Bu, büyük resme odaklanmanıza yardımcı olacaktır.

16 Spiral avantaj/dezavantaj
Bazı temel avantajları; Spiral, paydaşlara gözden geçirme ve karar verme konusunda avantaj sağlar. Riskler doğru şekilde tanımlanır ve çözülürse, nihai başarı mümkündür. Değişimi makul ölçüde karşılar. Riskler çıkarıldığında gerekli zamanlama ve efor tahmini daha doğru olur. Bazı dezavantajları; Karmaşıktır. Genellikle basit yaklaşımlardan daha fazla kaynak gerektirir. Risk analizi zor olabilir. Özellikle düşük riskli projeler için komplikasyon her zaman çabaya değer değildir. Paydaşların, bir çevrimin başarıyla tamamlandığından emin olması için periyodik olarak projeyi gözden geçirmek için zamana ve beceriye sahip olması gerekir. Zaman ve efor tahminleri, çevrimler bittiğinde daha kesin hale gelir, ancak başlangıçta bu tahminler iyi olmayabilir. Küçük projelerle iyi işlemez. Bu nedenlerden dolayı, spiral yaklaşım, yüksek riskli ve belirsiz/değişken gereksinimlere sahip projeler için daha faydalıdır.

17 Birleştirilmiş Süreçler (Unified Process)
Birleştirilmiş süreçler aslında bir model değildir. Projelere uygun şekilde özelleştirilebilecek yinelemeli bir uygulama geliştirme çerçevesi sunar. Birleştirilmiş süreç yaklaşımı dört aşamaya ayrılmıştır; Başlangıç (Inception): Proje fikri ortaya çıkar. Risklerin tanımlandığı, başlangıç programının oluşturulduğu, projenin genel hedeflerinin belirlendiği kısa bir aşamadır. Ayrıntı içermez. Detaylandırma (Elaboration): Proje gereksinimleri belirlenir. Kullanıcı senaryoları, mimari diyagram ve sınıf hiyerarşisi belirlenir. Temel hedef riskleri tanımlamak ve ele almaktadır. Bu aşama en önemli riskleri ele alan bir kaç iterasyon içerir. İnşaa (Construction): Bu aşamada kod yazılır, test edilir ve hatalar ayıklanır. Bu aşama her biri kullanıcılara yüksek kaliyede çıktılar sunan birkaç iterasyona bölünebilir. İterasyonlar öncelikle en önemli özelliklere odaklanır. Geçiş (Transition): Bu aşamada proje, müşteri ve bakım ekibine aktarılır. Geribildirimlerle iyileştirmeler yapılabilir yada yeni bir sürüm yayınlanabilir.

18 Birleştirilmiş Süreçler (Unified Process)
Proje aşamalarında farklı iş türlerinin göreceli miktarları ve bu aşamalardaki iterasyonlar görülmektedir. Örneğin, programlama (Implementation), başlangıç ​​ve detaylandırma sırasında nispeten azdır, İnşaa iterasyonları sırasında çoğalır ve geçiş sırasında da biter.

19 Birleştirilmiş Süreçler avantaj/dezavantaj
Bazı temel avantajları; Detaylandırma, inşaa ve geçiş aşamalarına ilişkin yinelemeli yaklaşım, gereksinimlerin aşamalı olarak tanımlanabilmesini ve uygulanabilmesini sağlar. Detaylandırma iterasyonları, projenin başarı şansını artırmak için risklere odaklanır. Farklı geliştirme modellerini esnek bir şekilde yer alabilir. Örneğin, inşaa aşamasına bir şelale veya çevik yaklaşım kullanılabilir. Başlangıç ​​ve detaylandırma aşamaları, yeni geliştiricilerin daha sonra takıma katılabilmelerine yardımcı olabilecek pek çok belge üretir. Bazı dezavantajları; Karmaşıktır (her ne kadar spiral yaklaşımı kadar kafa karıştırıcı olmasa da). Karmaşık olduğu için, basit yaklaşımlardan daha fazla kaynak gerektirir. Risk analizi zor olabilir. Özellikle düşük riskli projeler için her zaman fazladan çaba harcamaya değmez. Küçük projeler için iyi işlemez. Bu nedenlerden dolayı, Birleştirilmiş Süreçler, spiral yaklaşımda olduğu gibi, yüksek riskli ve belirsiz/değişken gereksinimlere sahip projeler için daha faydalıdır.

20 Temiz Oda (Cleanroom) Cleanroom modeli, hata giderme yerine hata önleme işlemlerini vurgular. Buradaki amaç, hataların uygulamaya girmesini önlemek için uygulamayı dikkatle izlenen ve test edilen adımlarla oluşturmaktır. Modelin adı, bir üretim temiz odasının, toz ve diğer maddelerin üretim sürecine girmesini önleme mantığından esinlenmiştir. Aşağıda Cleanroom modelinin temel ilkeleri belirtilmiştir: Resmi yöntemlere dayalı kod üretimi: Kod, kodun tasarım modellerini karşıladığını göstermek için matematiksel yöntemler kullanılarak üretilir. Kod incelemeleri, kodun gereksinimi doğru bir şekilde gerçekleştirebildiğini doğrulamaya yardımcı olur. İstatistiksel kalite kontrol: Kod, aşamalı olarak üretilir. Her bir adımın kalitesi, projenin kabul edilebilir bir ilerleme kaydettiğinden emin olmak için ölçülür. İstatistiksel test: Uygulama kalitesini tahmin etmek için istatistiksel testler kullanılır. Bu süreç, sadece uygulamanın kalitesini değil, aynı zamanda kalite tahmini için bir güven düzeyi de hesaplayabilmek için bazı ciddi istatistiksel analizler gerektirir.

21 Bölüm sonu Neler öğrendik? Model karşılaştırmaları
Tahmine dayalı, Artırımlı, Yinelemeli, Çevik model karşılaştırması, Protatipleme ve protatip çeşitleri Yinelemeli modeller Spiral Birleştirilmiş süreçler Cleanroom