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

Slides:



Advertisements
Benzer bir sunumlar
ALPER LAÇİN SERDAR TAŞAN
Advertisements

Sistem Analizi ve Planlama
Kalite Kavramı.
Ender Topuz Ford Otosan - Yazılım mimarı
Maltepe Üniversitesi Mühendislik Fakültesi
BEP BİREYSELLEŞTİRİLMİŞ EĞİTİM PROGRAMI.
TÜRKİYE AFET MÜDAHALE PLANI
END3061 SİSTEM ANALİZİ VE MÜHENDİSLİĞİ
SÜREÇ YÖNETİMİ Dr. Selami ERARSLAN İstanbul 2011.
Bireyselleştirilmiş Eğitim Programı (BEP) Nedir?
KADINLARIN VE KADIN SİVİL TOPLUM KURULUŞLARININ GÜÇLENDİRİLMESİ HİBE PROGRAMI GÜÇLÜ KADIN GÜÇLÜ TOPLUM PROJESİ STRONG WOMEN STRONG SOCIETY PROJECT TR2009/ /69.
Yazılım Proje Yönetimi
KALİTE YÖNETİMİ (EĞİTİMDE).
YENİ ÜRÜN GELİŞTİRME ve ÜRÜN YAŞAM SÜRECİ STRATEJİLERİ
ÖLÇME VE DEĞERLENDİRME
İSTANBUL ÜNİVERSİTESİ VATAN YAZILIMEVİ
Yerel ihtiyaçlara uygun kalite güvencesi:
AKDENİZ ÜNİVERSİTESİ TOPLAM KALİTE YÖNETİMİ ÜST DÜZEY YÖNETİCİ SEMİNERİ 1-2 MART 2003 ANTALYA.
Afyon Kocatepe Üniversitesi
FMEA Failure Mode and Effects Analysis-Hata Türü ve Etkileri Analizi
END3061 SİSTEM ANALİZİ VE MÜHENDİSLİĞİ
BİREYSELLEŞTİRİLMİŞ EĞİTİM PROGRAMI
END3061 SİSTEM ANALİZİ VE MÜHENDİSLİĞİ
Kalite Yönetim Prensipleri (Devam)
«MESLEKİ EĞİTİMDE KALİTE GÜVENCESİ»
Strateji Geliştirme Başkanlığı
Grup üyeleri: Selen ERGÜ Galip Kaya Nazgül BARPİEVA
ISO/TS 16949:2009 (Hafta 9) ISO 9001:2008’E GÖRE FARKLAR.
PROJE GELİŞTİRME yorum, araş.gör.levent yılmaz gençlik grubu KOLAY SİSTEM YÖNTEMİ.
ÇOK KATMANLI MİMARİLER. Katman: Ortak işi yapan kodların bir yerde toplanması Örneğin hemen hemen her projemizde veri tabanı kullanırız, bunun için veritabanı.
Süreç Yönetimi.
ISO 9001:2015 KALİTE YÖNETİM SİSTEMİ ŞARTLAR
Bölümün Amacı Bu bölüm, kurumsal kültür ve etik değerler ile bunların örgütlerden nasıl etkilendiğine dair görüşleri incelemektedir.
ŞEKİL 13.1 “Temel Dönüşüm” “İmalat Şirketine Yönelik Süreç”
Bölümün Amacı Bu bölümün amacı, örgütlerin peşinde koştukları hedeflerin türlerini ve yöneticilerin bu hedeflere ulaşmak için kullandıkları rekabetçi.
Konu: Kritik Süreçlerin Belirlenmesi
Kurumsal ve Gelişmiş Stratejik Planlama Çözümü.
YENİKENT AHMET ÇİÇEK TEKNİK VE ENDÜSTRİ MESLEK LİSESİ TOPLAM KALİTE YÖNETİMİ ÜST DÜZEY YÖNETİCİ SEMİNERİ 2010 ANKARA Nihat BÜLBÜL.
SİSTEM VE YAZILIM Bilgisayar sistemleri donanım, yazılım ve bunları işletmek üzere gerekli işlemlerden oluşur. Yazılım, bilgisayar sistemlerinin bir bileşeni.
Fen, Teknoloji, Mühendislik ve Matematik
BE P BİREYSELLEŞTİRİLMİŞ EĞİTİM PROGRAMI. BEP ; özel eğitim gereksinimi olan her birey için yazılı olarak geliştirilmiş ve özel eğitim gereksinimi olan.
Toplam Kalite Yönetimi
İZLEME ve DEĞERLENDİRME
Proje Oluşturma ve Yönetimi
 Projeler üç nedenle sona erdirilirler. 1. Proje amaçlarına ulaşılmış ve başarılı olarak tamamlanmıştır. 2. Projenin durdurulması gerekmektedir. 3. Proje.
TOPLAM KALİTE YÖNETİMİ
 Bir projeyi yönetmek üzere görevlendirilen ve projeyi, mümkün olan en yüksek üretkenlik, en düşük belirsizlik ve risk ile yürütmekten sorumlu kişidir.
Bilgisayar Mühendisliğindeki Yeri
ÇEVİK (Agile) SÜREÇLER Değişen gereksinimler, teknik riskler gibi önceden belirlenemeyen durumlara ve yazılım ürününü etkileyebilecek her tür değişikliğe.
Sistem Analizi ve Tasarımı
KAYNAK KİTAPLAR Software Engineering / Ian Sommerville. Addison- Wesley, 2010, 9th ed. Software Engineering: A Practitioner's Approach / Roger S. Pressman.
Bölüm 4 : VERİ MADENCİLİĞİ
Tedarik ziNCİRLERİ yÖNETİmi
AKREDİTASYON SÜRECİ: ANA KONULAR VE İŞLEYİŞ
ADIYAMAN ÜNİVERSİTESİ
ISO 9001:2015 standardı – 8. Maddenin Tanıtımı
TKY UYGULAMASI.
Kalite Yönetim Prensipleri (Devam)
Yrd.Doç.Dr. Çağdaş Erkan AKYÜREK
ERP Projesinin Aşamaları İzmir. ERP Projesinin Aşamaları SatışSatış - Başlangıç – Kurulum – Analiz – Plan – Uyarlama – Eğitim – Geliştirme.
Yazılım Geliştirme Yaşam Döngüsü
Problem Çözme Yaklaşımları
YER TEMİZLEME MAKİNASI
ONTOLOJİ GELİŞTİRME ALANINDA ÇEVİK YAKLAŞIMLAR
Yazılım Geliştirme Yaşam Döngüsü
Yazılım Mühendisliği Temel Süreçler - Sistem Analizi
BENZETİM 2. Ders Prof.Dr.Berna Dengiz Sistemin Performans Ölçütleri
Yükseköğretim Kalite Kurulu DIŞ DEĞERLENDİRME SÜRECİ
İLERİ VERİ TABANI UYGULAMALARI
Sunum transkripti:

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

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

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.

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.

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.

Model Karşılaştırması

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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