YAZILIM MÜHENDİSLİĞİ

2. KONU
YAZILIM SÜREÇLERİ
Konular
• Yazılım Yaşam Döngüsü (Çekirdek Süreçler)
• Belirtim Yöntemleri
• Yazılım Süreç Modelleri
• Gelişigüzel Model
• Barok Model
• Çağlayan Modeli
• V Modeli
• Spiral Model
• Evrimsel Geliştirme Süreç Modeli
• Artırımsal Geliştirme Süreç Modeli
• Araştırma Tabanlı Süreç Modeli
• Metodolojiler
Yazılım Süreci
• Bir yazılım sistemini geliştirmek için gerekli olan
aktiviteler kümesidir.
• Birçok farklı yazılım süreç modeli bulunmaktadır fakat
hepsi şunları içermeli:
• Tanımlama: Sistemin ne yapması gerektiğinin belirlenmesi
• Tasarım ve Gerçekleştirim: Sistemin organizasyonunun
belirlenmesi gerçekleştirilmesi
• Doğrulama: Müşterinin istediği şeyleri yapıp yapmadığının
kontrolü
• Evrim: Değişen müşteri isteklerine göre sistemin değiştirilmesi
• Bir yazılım süreç modeli gerçek bir sürecin özet gösterimi
olarak tanımlanabilir.
Yazılım Süreç Tanımlamaları
• Yazılım süreçleri; veri modeli belirleme, kullanıcı
arayüzü tasarımı gibi aktiviteler ve bu
aktivitelerin sırası ile ilgili tanımlamaları içerir.
• Yazılım süreç tanımlamaları şunları içerebilir:
• Süreç aktivitesinin sonunda elde edilecek ürünler
• Süreçte yer alan kişilerin sorumluluklarını gösteren
roller
• Süreç öncesinde belirlenen ve süreç sonrasında
yerine getirilip getirilmediği kontrol edilen koşullar
Plan tabanlı ve çevik (agile) süreçler
• Plan tabanlı süreçler, süreç aktivitelerinin önceden
planlandığı ve ilerlemenin bu plana göre ölçüldüğü
süreçlerdir.
• Çevik süreçlerde planlama artırımlı şekilde yapılır ve bu
nedenle sürecin, değişen müşteri ihtiyaçlarını
karşılayacak şekilde değiştirilmesi kolaydır.
• Pratikte, uygulanabilirliği en yüksek olan süreç modelleri
plan tabanlı ve çevik yaklaşımlardan unsurlar barındıran
modellerdir.
• Doğru ya da yanlış yazılım süreç modeli yoktur.
Yazılım süreç çerçeve modelleri
• Yazılım geliştirirken yazılım süreçlerini tanımlayan farklı yaklaşımlar
bulunmaktadır. Yazılım süreç çerçevelerini genişleterek veya adapte
ederek spesifik yazılım mühendisliği süreçleri oluşturulmuştur.
• Genel Süreç Modelleri
• Çağlayan (waterfall) modeli: Geliştirme, doğrulama ve evrimsel odaklı bir
süreçler vardır. Plan tabanlı bir modeldir. Tanımlama ve geliştirme
aşamaları ayrıdır.
• Artırımlı (Incremental development) geliştirme: Tanımlama, geliştirme ve
doğrulama aşamaları ard arda gelir. Plan tabanlı veya çevik olabilir.
Sistem, her sürüm bir önceki sürüme işlevsellik ekleyen bir dizi sürüm
(artış) olarak geliştirilmiştir.
• Entegrasyon ve Yapılandırma-Tekrar kullanım tabanlı yazılım mühendisliği
(Integration and configuration) : Bu yaklaşım, yeniden kullanılabilir
bileşenlerin veya sistemlerin mevcudiyetine dayanır. Sistem geliştirme
süreci, bu bileşenleri yeni bir ortamda kullanmak üzere yapılandırmaya
ve bunları bir sisteme entegre etmeye odaklanır.Sistem, var olan
bileşenlerden inşa edilir. Plan tabanlı veya çevik olabilir.
Çağlayan (waterfall) modeli:

Analiz(Requirements definition)

Tasarım(System and software design)

Geliştirme -birim Test (Implementation and

unit testing)

Geliştirme - entegrasyon testi (Integration

and system testing)

İşletme –Bakım (Operation and

maintenance)
Çağlayan/Şelale (waterfall) modeli
• Aşamalar:
• İhtiyaç analizi: Sistemin hizmetleri, kısıtlamaları ve hedefler,
sistem kullanıcılarına danışılarak belirlenir. Daha sonra
ayrıntılı olarak tanımlanırlar ve bir sistem özelliği olarak işlev
görürler.
• Sistem ve yazılım tasarımı: Sistem tasarım süreci,
gereksinimleri donanım veya yazılım sistemlerine tahsis eder.
Genel bir sistem mimarisi oluşturur. Yazılım tasarımı, temel
yazılım sistemi soyutlamalarını ve bunların ilişkilerini
tanımlamayı ve açıklamayı içerir.
• Geliştirme ve birim testi:Bu aşamada, yazılım tasarımı bir dizi
program veya program birimi olarak gerçekleştirilir. Birim
testi, her birimin spesifikasyonlarını karşıladığını doğrulamayı
içerir.
Çağlayan (waterfall) modeli
• Entegrasyon ve sistem testi: Bireysel program birimleri
veya programlar, yazılım gereksinimlerinin
karşılandığından emin olmak için eksiksiz bir sistem
olarak entegre edilir ve test edilir. Test edildikten sonra
yazılım sistemi müşteriye teslim edilir.
• Uygulama ve bakım:Normalde, bu en uzun yaşam
döngüsü aşamasıdır. Sistem kurulur ve pratik kullanıma
açılır. Bakım, yaşam döngüsünün önceki aşamalarında
keşfedilmemiş hataları düzeltmeyi, sistem birimlerinin
uygulanmasını iyileştirmeyi ve yeni gereksinimler
keşfedildikçe sistem hizmetlerini geliştirmeyi içerir.
Çağlayan (waterfall) modeli
• Prensip olarak, çağlayan modelindeki her aşamanın
sonucu, onaylanan ("imzalanan") bir veya daha fazla
belgedir. Bir sonraki aşama, bir önceki aşama bitene
kadar başlamamalıdır. Yüksek üretim maliyetlerinin söz
konusu olduğu donanım geliştirme için bu mantıklıdır.
Ancak, yazılım geliştirme için bu aşamalar örtüşür ve
bilgileri birbirine besler. Tasarım sırasında gereksinimlerle
ilgili sorunlar belirlenir; kodlama sırasında tasarım
sorunları bulunur vb. Uygulamada yazılım süreci asla
basit bir doğrusal model değildir, bir aşamadan diğerine
geri bildirim içerir.
Çağlayan (waterfall) modeli
• Bir süreç aşamasında yeni bilgiler ortaya çıktıkça, önceki
aşamalarda üretilen belgeler gerekli sistem değişikliklerini
yansıtacak şekilde değiştirilmelidir. Örneğin, bir gereksinimin
uygulanmasının çok pahalı olduğu keşfedilirse, gereksinim
belgesi bu gereksinimi ortadan kaldıracak şekilde
değiştirilmelidir. Ancak, bu müşteri onayı gerektirir ve genel
geliştirme sürecini geciktirir.
• Sonuç olarak, hem müşteriler hem de geliştiriciler, yazılım
belirtimini erken dondurabilir ve böylece üzerinde başka
değişiklik yapılmaz. Ne yazık ki, bu, sorunların daha sonra
çözülmesi, göz ardı edilmesi veya programlanması anlamına
gelir. Gereksinimlerin erken dondurulması, sistemin
kullanıcının istediğini yapmayacağı anlamına gelebilir.
Tasarım sorunları uygulama hileleriyle aşıldığı için kötü
yapılandırılmış sistemlere de yol açabilir.
Çağlayan (waterfall) modeli
• Son yaşam döngüsü aşamasında (işletme ve bakım)
yazılım kullanıma açılır. Orijinal yazılım
gereksinimlerindeki hatalar ve eksiklikler keşfedilir.
Program ve tasarım hataları ortaya çıkar ve yeni
işlevsellik ihtiyacı belirlenir. Bu nedenle, sistemin yararlı
kalması için gelişmesi gerekir. Bu değişiklikleri yapmak
(yazılım bakımı), önceki süreç aşamalarını tekrarlamayı
içerebilir.
• Gerçekte, yazılım esnek olmalı ve geliştirilirken değişime
uyum sağlamalıdır. Değişiklikler yapıldığında erken
taahhüt ve sistem yeniden çalışmasına duyulan ihtiyaç,
çağlayan modelinin yalnızca bazı sistem türleri için
uygun olduğu anlamına gelir:
Çağlayan (waterfall) modeli
• 1. Yazılımın donanım sistemleriyle arayüz
oluşturması gereken gömülü sistemler. Donanımın
esnekliğinden dolayı, yazılımın işlevselliğine ilişkin
kararları, uygulamaya geçirilene kadar ertelemek
genellikle mümkün değildir.
• 2. Kritik sistemler Yazılım spesifikasyonu ve
tasarımının kapsamlı emniyet ve güvenlik analizine
ihtiyaç duyarlar. Bu sistemlerde, bu analizin
yapılabilmesi için şartname ve tasarım belgeleri
eksiksiz olmalıdır. Spesifikasyon ve tasarımdaki
güvenlikle ilgili problemlerin uygulama aşamasında
düzeltilmesi genellikle çok pahalıdır.
Çağlayan (waterfall) modeli
• 3. Büyük yazılım sistemleri birkaç ortak şirket
tarafından geliştirilen geniş mühendislik
sistemlerinin bir parçasıdır. Sistemlerdeki
donanımlar benzer bir model kullanılarak
geliştirilebilir ve şirketler, donanım ve yazılım için
ortak bir model kullanmayı daha kolay bulur.
Ayrıca, birkaç şirketin dahil olduğu durumlarda,
farklı alt sistemlerin bağımsız olarak
geliştirilmesine izin vermek için eksiksiz
spesifikasyonlara ihtiyaç duyulabilir.
Çağlayan (waterfall) modelinin problemleri
• Gayri resmi ekip iletişiminin mümkün olduğu ve
yazılım gereksinimlerinin hızla değiştiği
durumlarda çağlayan modeli doğru süreç modeli
değildir. Yinelemeli geliştirme ve çevik yöntemler
bu sistemler için daha iyidir.
• Bu modelin en önemli eksikliği, süreç devam
ediyorken bir değişikliği adapte etmekteki
zorluktur.
• İlkesel olarak, bir sonraki aşamaya geçmeden
önce bir önceki aşamanın tamamlanmış olması
gerekir.
Çağlayan (waterfall) modelinin problemler
• Projeyi esnek olmayan alt aşamalara ayırmak,
müşteri ihtiyacındaki değişikliğe cevap vermeyi
zorlaştırır
• Bundan dolayı bu model yalnızca çok iyi
tanımlanmış ve anlaşılmış ihtiyaçlar üzerinde ve
hemen hemen hiç değişiklik olmayan durumlarda
kullanışlıdır. Ancak, çok az iş alanı stabil ihtiyaçlara
sahiptir.
Artırımlı (Incremental) geliştirme

Tanımlama İlk Sürüm

Specification Initial Version

Genel (Taslak) Geliştirme Ara Sürümler

Tanımlama Intermediate versions
Development
Outline
description

Test Etme/ Son Sürüm

Onaylama Final verison
Validation
• Artımlı geliştirme, bir başlangıç uygulaması
geliştirme, kullanıcılardan ve diğerlerinden geri
bildirim alma ve gerekli sistem geliştirilene kadar
yazılımı çeşitli sürümler aracılığıyla geliştirme
fikrine dayanır. Tanımlama, geliştirme ve
doğrulama faaliyetleri, faaliyetler arasında hızlı
geri bildirim ile ayrı değil, iç içe geçmiştir.
Artırımlı (Incremental) geliştirmenin faydaları
• Değişen müşteri gereksinimlerini karşılamanın maliyeti
azaltılır.
• Yeniden yapılması gereken analiz ve dokümantasyon miktarı,
şelale modelinde gerekenden çok daha azdır.
• Yapılan geliştirme çalışmaları hakkında müşteri geri bildirimi
almak daha kolaydır.
• Müşteriler, yazılımın gösterimleri hakkında yorum yapabilir ve
ne kadarının uygulandığını görebilir.
• Kullanılabilir yazılımın müşteriye daha hızlı teslimi ve dağıtımı
mümkündür.
• Müşteriler, bir şelale modeline göre mümkün olandan daha
erken bir zamanda yazılımı kullanabilir. Yazılım teslim süresi
çağlayan modeline göre daha kısadır
Artırımlı (Incremental) geliştirmenin problemleri
• Süreç görülebilir değildir.
• Yöneticiler, süreçle ilgili düzenli olarak bilgi almak ister.
Eğer sistem çabuk bir biçimde geliştiriliyorsa, sistemin
her bir versiyonu için yöneticilere sunulacak raporlar
hazırlamak maliyet-etkin olmaz.
• Her bir değişiklik sistemin yapısında bozulmalara neden
olur. Yazılımı iyileştirmek için yeniden düzenlemeye
yeterince zaman ve para harcanmadıkça, düzenli değişim
yapısını bozma eğilimindedir. Daha fazla yazılım
değişikliğini dahil etmek giderek daha zor ve maliyetli
hale geliyor.
Entegrasyon ve Yapılandırma- Integration and configuration

• Sistemlerin mevcut bileşenlerden veya uygulama

sistemlerinden (bazen COTS-Hazır ticari sistemler olarak
adlandırılır) entegre edildiği yazılımın yeniden
kullanımına dayanır.
• Yeniden kullanılan öğeler, davranışlarını ve işlevlerini bir
kullanıcının gereksinimlerine uyarlayacak şekilde
yapılandırılabilir.
• Yeniden kullanım artık birçok türde iş sistemi oluşturmak
için standart bir yaklaşımdır.
Tekrar kullanım tabanlı yazılım mühendisliği
• Var olan veya ticari olarak temin edilebilen (COTS -
Commercial-off-the-shelf) bileşenlerin bir araya getirilmesi ile
üretilen sistemlerdir.
Süreç aşamaları
• Gereksiminlerin Belirlenmesi: Sistem için ilk gereksinimler
önerilmiştir. Bunların ayrıntılı olarak detaylandırılması
gerekmez, ancak temel gereksinimlerin ve arzu edilen sistem
özelliklerinin kısa açıklamalarını içermelidir.
• Yazılım araştırma ve değerlendirme: Yazılım gereksinimlerinin
bir taslağı verildiğinde, gereken işlevselliği sağlayan bileşenler
ve sistemler için bir arama yapılır. Aday bileşenler ve
sistemler, temel gereksinimleri karşılayıp karşılamadıkları ve
genel olarak sistemde kullanıma uygun olup olmadıkları
değerlendirilir.
• Gereksinim İyileştirmesi: Bu aşamada, keşfedilen yeniden
kullanılabilir bileşenler ve uygulamalar hakkındaki bilgiler
kullanılarak gereksinimler rafine edilir. Gereksinimler, mevcut
bileşenleri yansıtacak şekilde değiştirilir ve sistem özelliği
yeniden tanımlanır. Değişikliklerin imkansız olduğu
durumlarda, alternatif çözümler aramak için bileşen analizi
faaliyetine yeniden girilebilir.
• Bileşenleri kullanarak sistemin tasarlanması- Uygulama
sistemi yapılandırması: Gereksinimleri karşılayan kullanıma
hazır bir uygulama sistemi mevcutsa, yeni sistemi oluşturmak
için kullanılmak üzere yapılandırılabilir.
• Bileşen uyarlaması ve entegrasyonu: Kullanıma hazır bir
sistem yoksa, tek tek yeniden kullanılabilir bileşenler
değiştirilebilir ve yeni bileşenler geliştirilebilir. Bunlar daha
sonra sistemi oluşturmak için entegre edilir.
Tekrar kullanım tabanlı yazılım mühendisliği
Yazılım bileşen tipleri
• Web servisleri
• Paket haline getirilmiş yazılım nesneleri
• Belirli bir amaç için konfigüre edilebilen ve yalnız başına
çalışabilen yazılım sistemleri (COTS)
• Konfigürasyon ve entegrasyona dayalı yeniden kullanıma
yönelik yazılım mühendisliği, geliştirilecek yazılım
miktarını azaltma ve böylece maliyet ve riskleri azaltma
gibi bariz bir avantaja sahiptir. Genellikle yazılımın daha
hızlı teslim edilmesini de sağlar.
• Ancak gereksinimlerden ödün verilmesi kaçınılmazdır ve
bu durum, kullanıcıların gerçek ihtiyaçlarını karşılamayan
bir sisteme yol açabilir. Ayrıca, yeniden kullanılabilir
bileşenlerin yeni sürümleri onları kullanan kuruluşun
kontrolü altında olmadığı için sistem evrimi üzerindeki
kontrolün bir kısmı kaybedilir.
Süreç Aktiviteleri (Process Activities)
• Gerçek yazılım süreçleri, bir yazılım sistemini belirleme,
tasarlama, uygulama ve test etme genel amacı ile teknik,
işbirlikçi ve yönetimsel faaliyetlerin serpiştirilmiş dizileridir.
Genel olarak, işlemler artık araç desteklidir. Bu, yazılım
geliştiricilerin kendilerine yardımcı olması için gereksinim
yönetim sistemleri, tasarım modeli düzenleyicileri, program
düzenleyicileri, otomatikleştirilmiş test araçları ve hata
ayıklayıcılar gibi bir dizi yazılım aracını kullanabilecekleri
anlamına gelir.
• Tanımlama, geliştirme, doğrulama ve evrimden oluşan dört
temel süreç faaliyeti, farklı geliştirme süreçlerinde farklı
şekilde düzenlenir. Waterfall modelinde sıralı olarak organize
edilirken artımlı geliştirmede serpiştirilirler. Bu faaliyetlerin
nasıl yürütüldüğü, geliştirilmekte olan yazılımın türüne,
geliştiricilerin deneyim ve yeterliliğine ve yazılımı geliştiren
organizasyonun türüne bağlıdır.
Yazılım tanımlama (İhtiyaç Mühendisliği)
• Hangi hizmetlerin gerekli olduğunun tespit edildiği ve
sistemin geliştirilmesi ve uygulaması üzerindeki kısıtların
ortaya konulması
• İhtiyaç mühendisliği süreci aktiviteleri (müşteri ile anlaşma)
• 1. Uygulanabilirlik çalışması (Feasibility study)
• Teknik ve finansal olarak bu sistemi geliştirmek mümkün mü?
• 2. İhtiyaçları belirleme ve analiz etme (Requirements
elicitation and analysis)
• Sistemin paydaşlarının sistemden beklentileri nelerdir?
• 3. İhtiyaçları tanımlama
• İhtiyaçların detaylıca tanımlanması
• 4. İhtiyaçların doğrulanması
• İhtiyaçların doğruluklarının kontrol edilmesi
İhtiyaç mühendisliği süreci
Yazılım tasarım ve gerçekleştirme
• Sistem ihtiyaçlarının çalıştırılabilir (executable) bir sistem
haline getirilmesi
• Yazılım tasarımı
• İhtiyaçları cevap verebilecek bir yazılım yapısı tasarlama
• Gerçekleştirim
• Tasarlanan yapının çalıştırılabilir bir sistem haline
getirilmesi ;
• Tasarlama ve gerçekleştirme faaliyetleri yakından ilgilidir
ve iç içe geçmiş şekilde yapılabilir.
Tasarım sürecinin genel bir modeli
Tasarım aktiviteleri
• Mimari tasarım, bütün bir sistemin yapısının, ana
bileşenlerinin (alt sistem veya modüllerin) ve bunlar
arasındaki ilişkilerin yapısı
• Arayüz tasarımı, sistem bileşenleri arasındaki arayüzlerin
tasarlanması
• Bileşen tasarımı, her bir sistem bileşeninin nasıl
çalışacağının tasarlanması.
• Veritabanı tasarımı, sistemin kullanacağı veri yapılarının
tasarlanması ve bunların bir veritabanında nasıl
tutulacağının belirlenmesi.
Yazılım doğrulama
• Tetkik ve Tasdik (Verification and validation - V & V), bir
sistemin daha önceden belirlenmiş olan ihtiyaçları
karşılayıp karşılamadığını belirlemek üzere gerçekleştirilir.
• Kontrol, gözden geçirme ve sistem testini kapsar
• Sistem testi, sistem tarafından kullanılacak olan gerçek
veriler ile gerçekleştirilir.
• Test, en yaygın kullanılan doğrulama aktivitesidir
Test aşamaları
Test aşamaları
• Geliştirme veya bileşen testi
• Birbirinden ayrı bileşenler ayrı ayrı test edilir;
• Bir bileşen, fonksiyon, nesne vb. olabilir.
• Sistem testi
• Sistemin bütün olarak test edilmesi.
• Kabul testi
• Müşteri ihtiyaçlarının karşılandığını göstermek için
müşterinin verileri ile sistemin test edilmesi
Plan tabanlı bir süreçteki test aşamaları
Yazılım evrimi
• Yazılım, doğası gereği esnektir ve değişebilir.
• Değişen iş hayatı koşulları ile değişen ihtiyaçların yazılım
tarafından desteklenmesi gerekir.
• Yazılım geliştirme ile evrim (bakım, güncelleme) arasında
bir sınır olmasına rağmen, yeni sistemlerde bu sınır
gittikçe belirsizleşmekte.
Yazılım evrimi
• Yazılım süreçleri, yazılım üretimindeki aktivitelerdir.
Yazılım süreç modeller ise bu süreçlerin özet bir
gösterimidir.
• Çağlayan modeli, artırımlı model gibi yazılım süreç
modelleri, yazılım süreçlerinin organizasyonunu
tanımlayan modellerdir.
• İhtiyaç mühendisliği, yazılım tanımlama sürecidir.
• Tasarım ve gerçekleştirim, belirlenen ihtiyaçların çalışır
bir yazılım sistemi haline getirilmesi ile ilgilenir.
• Yazılım doğrulama, yazılımın daha önceden tanımlanan
işleri yapabildiğinin ve kullanıcı isteklerini karşıladığının
doğrulanmasıdır.
• Yazılım evrimi, yeni ihtiyaçları karşılamak üzere yazılım
üzerinde yapılan değişikliklerdir.
Değişikliklerle baş etmek
• Bütün büyük yazılım projelerinde değişiklik kaçınılmazdır.
• Değişen iş gereksinimi
• Yeni yazılım geliştirme teknolojileri
• Değişen platformlar
• Değişiklik, yeniden çalışmak demektir. Yeniden çalışmak
yalnızca kodları değiştirmek değil. yeniden analiz,
yeniden tasarım…
Yeniden çalışma maliyetini azaltmak
• Prototipleme
• Ana hatları tamamlanmış bir sürümü müşteriye göster;
istediği değişiklikleri yap.
• Artırımlı geliştirme
• Değişiklikleri, artırım aşamalarında yap.
• Mümkün değilse, yalnızca bir artırıma indirgemeye çalış.
Yazılım prototipleme
• Tasarım opsiyonlarını ve ana hatları gösteren taslak
sürüme prototipleme denir.
• Prototipleme başka nelere yarar?
• İhtiyaç mühendisliği sırasında ihtiyaçların elenmesi ve
doğrulanması
• Tasarım sürecinde arayüz alternatiflerinin
değerlendirilmesi
• Test aşamasına, testlerin arka arkaya yapılması
Prototiplemenin faydaları
• Sistem kullanılabilirliğini arttırır.
• Sistemi, kullanıcının gerçek ihtiyaçlarına yaklaştırır
• Tasarım kalitesini arttırır
• Sürdürülebilirliği arttırır
• Geliştirme eforunu azaltır
Prototiplemenin aşamaları
Prototip geliştirme
• Programlama dilleri veya görsel araçlarla yapılabilir.
• Şunları içerebilir
• Prototipleme, ürünün iyi anlaşılmamış alanlarına
odaklanmalı
• Hata kontrolü gibi detayları prototipte bulunmayabilir
• Fonksiyonel olmayan (güvenilirlik, güvenlik)
ihtiyaçlardansa fonksiyonel ihtiyaçlara odaklan
Prototipleri atın
• Son ürünün geliştirmesinde prototipi kullanmayın
• Fonksiyonel olmayan sistem gereksinimlerini karşılamak
imkansız olabilir.
• Prototipler genelde dokümante edilmezler
• Prototipin yapısı, hızlı değişikliklerden dolayı çabucak
bozulur
• Prototipler, kalite standartlarını sağlamayabilir.
Artırımlı geliştirme
• Sistemi bütün olarak teslim etmek yerine, her seferinde
bazı fonksiyonları tamamlayarak teslim etmek.
• Kullanıcı istekleri önceliklendirilir ve en öncelikli istekler
ilk artırımlarda yapılır.
Artırımlı geliştirme ve teslim
• Artırımlı geliştirme
• Sistemi artırarak geliştir ve her artırımdan önce eldeki
ürünü test et
• Artırımlı teslim
• Her artırımı müşterinin kullanımına sun
• Yazılımın kullanılması sayesinde daha gerçekçi
değerlendirme sağlar
Artırımlı teslim
Artırımlı teslimin avantajları
• Sistemin fonksiyonelliği erken aşamalarda başlar.
• İlk artırımlar prototip işlevi görürler ve sonraki artırımlar
için öncelikli gereksinimlerin belirlenmesini sağlarlar
• Projenin tamamen başarısız olma riski düşer
• En çok testin, en öncelikli sistem hizmetleri için yapılması
sağlanır
Artırımlı teslimin problemleri
• Birçok sistem, sistemin değişik parçalarının ortak olarak
kullanacağı fonksiyonelliği gerektirir
• Artırımlı geliştirmenin temeli, sistem tanımlamasının
geliştirme aşamasında yapılmasıdır.
• Sistem tanımlamasının tamamı, son artırımda bitirilmiş
olur. Bu duruma müşterinin ikna edilmesi zor olabilir.
Yazılım Yaşam Döngüsü
1. 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.
2. Analiz
Sistem gereksinimlerinin ve işlevlerinin ayrıntılı olarak çıkarıldığı aşama. Var olan işler incelenir, temel
sorunlar ortaya çıkarılır.
mantıksal; önerilen sistemin yapısı anlatılır,
3. Tasarım
Belirlenen gereksinimlere yanıt verecek yazılım sisteminin temel yapısının oluşturulduğu aşamadır.
mantıksal; önerilen sistemin yapısı anlatılır,
fiziksel; yazılımı içeren bileşenler ve bunların ayrıntıları.
4. Gerçekleştirim
Kodlama, test etme ve kurulum çalışmalarının yapıldığı aşamadır.
5. Bakım
Hata giderme ve yeni eklentiler yapma aşaması.
Belirtim Yöntemleri
• Bir çekirdek sürece ilişkin fonksiyonları yerine
getirmek veya çekirdek süreçler arası geçişlerin
belirtilmesinde kullanılan yöntemler, Belirtim
Yöntemleri olarak adlandırılır.
• yazılım yaşam döngüsündeki çekirdek süreçlerin
geliştirme aşamasında hangi sırada uygulanacağını
tanımlayan modellere Süreç Modelleri denir.
Belirtim Yöntemleri
• Süreç Akışı İçin Kullanılan Belirtim Yöntemleri
• Süreçler arası ilişkilerin ve iletişimin gösterildiği yöntemler
(Veri Akış Şemaları, Yapısal Şemalar, Nesne/Sınıf Şemaları).

• Süreç Tanımlama Yöntemleri

• Süreçlerin iç işleyişini göstermek için kullanılan yöntemler
(Düz Metin, Algoritma, Karar Tabloları, Karar Ağaçları, Anlatım
Dili).

• Veri Tanımlama Yöntemleri

• Süreçler tarafından kullanılan verilerin tanımlanması için
kullanılan yöntemler (Nesne İlişki Modeli, Veri Tabanı Tabloları,
Veri Sözlüğü).
Yazılım Süreç Modelleri
✓Yazılım üretim işinin genel yapılma düzenine ilişkin
rehberlerdir.
Süreçlere ilişkin ayrıntılarla ya da süreçler arası ilişkilerle
ilgilenmezler.
1. Gelişigüzel Model
2. Barok Modeli
3. Çağlayan (Şelale) Modeli
4. V Modeli
5. Spiral Model
6. Evrimsel Model
7. Artırımsal Model
8. Araştırma Tabanlı Model
9. Çevik Yöntemler
Software Development Life Cycle (SDLC)
Gelişigüzel Model
• Herhangi bir model ya da yöntem yok.
• Geliştiren kişiye bağlı.
• İzlenebilirliği ve bakımı oldukça zor.
• Genellikle tek kişilik üretim ortamı.
• Karmaşık olmayan yazılım sistemleri.
Barok Model
✓Analiz
✓Tasarım
✓Kodlama
✓Modül Testleri
✓Altsistem Testleri
✓Sistem Testi
✓Belgeleme
✓Kurulum
Barok Model
• Yaşam döngüsü temel adımlarının doğrusal bir
şekilde geliştirildiği 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.

• Aşamalar arası geri dönüşlerin nasıl yapılacağı

tanımlı değil.
Çağlayan Modeli

Analiz

Tasarım

Geliştirme -birim Test

Geliştirme - entegrasyon testi

İşletme -Bakım
Çağlayan (waterfall) modelinin aşamaları
• Aşamalar:
• İhtiyaç analizi
• Sistem ve yazılım tasarımı
• Geliştirme ve birim testi
• Entegrasyon ve sistem testi
• Uygulama ve bakım
• Bu modelin en önemli eksikliği, süreç devam
ediyorken bir değişikliği adapte etmekteki zorluktur.
• İlkesel olarak, bir sonraki aşamaya geçmeden önce bir
önceki aşamanın tamamlanmış olması gerekir.
Çağlayan Modeli
• Yaşam döngüsü temel adımları baştan sona en az bir kez
izleyerek gerçekleştirilir.
• İyi tanımlı projeler ve üretimi az zaman gerektiren yazılım
projeleri için uygun bir modeldir.
• Geleneksel model olarak da bilinen bu modelin kullanımı
günümüzde giderek azalmaktadır.
• Barok modelin aksine belgeleme işlevini ayrı bir aşama olarak
ele almaz ve üretimin doğal bir parçası olarak görür.
• Barok modele göre geri dönüşler iyi tanımlanmıştır.
• 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.
Çağlayan Modeli
• Gerçek yaşamdaki projeler genelde yineleme gerektirir.
• Genelde yazılımın kullanıcıya ulaşma zamanı uzundur.
• Gereksinim tanımlamaları çoğu kez net bir şekilde
yapılamadığından dolayı, yanlışların düzeltilme ve eksiklerin
giderilme maliyetleri yüksektir.
• 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.
• Ü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
Çağlayan (waterfall) modelinin problemleri
• Projeyi esnek olmayan alt aşamalara ayırmak,
müşteri ihtiyacındaki değişikliğe cevap vermeyi
zorlaştırır
• Bundan dolayı bu model yalnızca çok iyi tanımlanmış
ve anlaşılmış ihtiyaçlar üzerinde ve hemen hemen hiç
değişiklik olmayan durumlarda kullanışlıdır.
• Ancak, çok az iş alanı stabil ihtiyaçlara sahiptir.
V Süreç Modeli

Kullanıcı Modeli

Mimari Model

Gerçekleştirim Modeli

ZAMAN
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.
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çekleşmektedir.
Spiral Model
Spiral Model
Tasarımı doğrusal bir süreç olarak gören diğer modellerin
aksine, bu model spiral bir süreç olarak görür. Bu, yineleyici
tasarım döngülerini genişleyen bir spiral olarak temsil
ederek yapılır.
Genellikle iç çevrimler, gereksinim tanımının rafine
edilmesi için prototipleme ile birlikte ihtiyaç analizinin
erken evresini ve dış spiraller yazılım tasarımını aşamalı
olarak temsil eder.
Her helezonda, tasarım çabalarını ve bu yineleme için ilgili
riski değerlendirmek için bir risk değerlendirme aşaması
vardır. Her spiralin sonunda, mevcut spiralin gözden
geçirilebilmesi ve bir sonraki aşamanın planlanabilmesi için
gözden geçirme aşaması vardır.
Spiral Model
Her tasarım sarmalının altı ana faaliyeti altı temel görevle temsil edilmektedir:
1. Müşteri İletişimi
2. Planlama
3. Risk Analizi
4. Yazılım Tasarımı
5. Üretim-dağıtım
6. Müşteri onayı
Avantajları
1. Risk analizi yapmaktadır.
2. Bu yazılım tasarım modeli, büyük yazılım projelerini tasarlamak ve yönetmek için
daha uygundur.
Dezavantajları
1. Risk analizi yüksek uzmanlık gerektirir.
2. Kullanması pahalı model
3. Küçük projeler için uygun değildir.
Evrimsel Geliştirme Süreç Modeli
• İlk tam ölçekli modeldir.
• 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.
• Pilot uygulama kullan, test et, güncelle diğer
birimlere taşı.
• Modelin başarısı ilk evrimin başarısına bağımlıdır
Evrimsel Geliştirme Süreç Modeli

İlk
Tanımlama Sürüm

Genel Ara
Tanımlama Geliştirme Sürümler

Son
Test Etme
Sürüm
Evrimsel Geliştirme Süreç Modeli
• Ç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.

EKSİKLERİ
• Değişiklik denetimi

• Konfigürasyon Yönetimidir
• Sürüm Yönetimi
• Değişiklik Yönetimi
• Kalite Yönetimi
Artırımsal Geliştirme Süreç Modeli
• Ü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

Artırımsal Geliştirme Süreç Modeli

Genel Gereksinimleri Sistem

Gereksinim Artırımlara Mimarisini
Belirlenmesi Bölme Tanımlama

Sistem Artırılımın Artırılımın Sistemin Son

Artırılımının Onaylanması Birleştirilmesi Onaylanması Sistem
Yapılması

Bitmemiş Sistem
Araştırma Tabanlı Süreç Modeli
• 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.
The Rational Unified Process(RUP)
• Rasyonel Birleşik Süreç (RUP); Doğrusal ve yinelemeli
modellerin bir kombinasyonu olan bu model çevik bir yazılım
geliştirme sürecidir. Rasyonel Birleşik Süreç, 4 aşamadan
oluşur. Başlangıç aşamasında projenin yapısı belirlenir. Sistem
gereksinimlerini belirlemek ve tasarım oluşturmak için
detaylandırma aşamasına geçilir. Bu aşamada ürün analizleri
yapılarak projenin temeli atılır. İnşaat aşamasına geçilir ve bu
artık yapım aşamasıdır. Yazılım sistemi bütünüyle
oluşturulmaya başlanır. Kodlar uygulanır ve test edilir.
Oluşturulan ürün, geçiş aşamasına gelerek kullanıcıya sunulur
ve geri bildirim istenir.
• Rasyonel birleşik süreç, istikrarlı ve esnek çözümler üretilebilir
bir modeldir.
• Kullanım alanları; Büyük ve riskli projeler, yüksek kaliteli
yazılımlar vb.
The Rational Unified Process
• UML ve ilgili süreçler üzerinde çalışan modern bir genel
süreç modeli
• Daha önceden açıkladığımız 3 tane genel süreç modelinin
farklı yönlerini bir araya getirir.
• 3 bakış açısı ile süreç tarif edilir
• Aşamaları zamana göre gösteren bakış açısı
• Süreç aktivitelerini gösteren statik bakış açısı
• İyi uygulamaları öneren pratik bir bakış açısı
RUP aşamaları
• Başlangıç
• Sistemin olurluğunu kanıtla
• Ayrıntılandırma
• Problemin alanını belirle ve sistem mimarisini geliştir
• İnşa
• Sistem tasarımı, programlama ve test.
• Geçiş
• Sistemi, çalışacağı ortamda yayınla.
RUP iterasyonu (süreçteki tekrarlar)
• Aşama içi iterasyon
• Artırımlı geliştirmenin sonucu olarak her aşama iteratiftir.
• Aşamalar arası iterasyon
• RUP modelindeki döngüde gösterildiği gibi bütün
aşamaların kümesi artırımlı şekilde harekete geçirilebilir.
Rational Unified Process’de Statik İş Akışları
• İşin Modellenmesi
• Kullanım senaryoları ile iş süreçlerinin modellenmesi.
• İhtiyaçlar
• Sistemle etkileşecek olan kullanıcı tiplerinin tespiti ve
sistem ihtiyaçlarını modellemek için kullanım
senaryolarının kullanılması.
• Analiz ve Tasarım
• Mimari modeller, bileşen modelleri, nesne modelleri ve
diziliş modelleri kullanılarak bir tasarım modelinin
yaratılması ve dokümante edilmesi.
Rational Unified Process’de Statik İş Akışları
• Gerçekleştirme
• Sistemdeki bileşenler, alt sistemlerin gerçekleştirilmesi
şeklinde yapılandırılıp gerçekleştirilirler. Tasarım
modellerinden otomatik kod oluşturan araçlar bu
aşamanın hızlanmasını sağlayabilir.
• Test
• Test, gerçekleştirim ile birlikte yürütülen iteratif bir
süreçtir. Sistem testi ise gerçekleştirimin bitmesinden
sonra yapılır.
Rational Unified Process’de Statik İş Akışları
• Yayınlama
• Ürünün bir sürümünün oluşturulması, kullanıcılara
dağıtılması ve çalışma alanına yüklenmesi.
• Konfigürasyon ve değişim yönetimi
• Bu yardımcı iş akışı sistem değişikliklerini yönetir.
• Proje yönetimi
• Bu yardımcı iş akışı sistem gelişim sürecini yönetir.
• Çevre
• Bu iş akışı, yazılım geliştirme ekibine uygun yazılım
geliştirme araçlarının temin edilmesi ile ilgilenir.
RUP’un kullandığı iyi uygulamalar (good practice)
• Yazılımı İteratif Geliştir
• Her bir küçük sürümü müşteri ihtiyacının önceliğine göre
geliştir ve en öncelikli ihtiyaçları ilk ulaştır.
• İhtiyaçları Yönet
• Müşteri ihtiyaçlarını açık bir biçimde belgelendir ve
ihtiyaçlardaki değişiklikleri takip et.
• Bileşen Tabanlı Mimariler Kullan
• Sistem mimarisini yeniden kullanılabilir bileşenlerin bir
kümesi olarak organize et.
RUP’un kullandığı iyi uygulamalar (good practice)
• Yazılımı Görsel Olarak Modelle
• Yazılımın statik ve dinamik bakış açılarını oluşturmak için
grafiksel UML modelleri kullan.
• Yazılımın Kalitesini Doğrula
• Yazılımın gerekli kalite standartlarını sağladığından emin
ol.
• Yazılım Değişikliklerini Kontrol Et
• Bir tane değişiklik yönetim sistemi ve konfigürasyon
yönetim sistemi kullanarak yazılımdaki değişiklikleri
yönet.
• Fazlası için: ITIL, IBM Tivoli…
Agile(Çevik)
• Seçtiğimiz SDLC modellerinin geri kalanı Agile çatısı altındadır.
Günümüzde kuruluşların %70'inden fazlası BT projelerinde şu
veya bu Çevik yaklaşımı kullanıyor. Genel olarak Agile'ın
merkezinde yinelemeli geliştirme, yoğun iletişim ve erken
müşteri geri bildirimi bulunur.
• Her Çevik yineleme genellikle birkaç hafta sürer ve eksiksiz bir
çalışan yazılım sürümü sunar. Bu grubun modelleri,
uygulamanın işleyen bir bölümünü hızlı bir şekilde sunmaya
daha fazla odaklanır. Ayrıntılı yazılım belgelerine (ayrıntılı
gereksinim belirtimi, ayrıntılı mimari açıklaması) daha az,
yazılım test faaliyetlerine daha çok önem verirler. Bu, hızlı
geliştirmeyi teşvik eder, ancak destek ekibine yazılım
transferini önemli ölçüde uzatır ve ayrıntılı yazılım açıklaması
olmadığında sorunu bulmak için daha fazla zaman
harcandığından bakımını daha karmaşık hale getirir.
Agile(Çevik)
• Agile, hem ekip genelinde hem de müşterilerle yakın
işbirliği içinde çalışmakla ilgilidir. Her yinelemenin
sonunda, paydaşlar geliştirme ilerlemesini gözden geçirir
ve yatırım getirisini (ROI) artırmak ve kullanıcı ihtiyaçları
ve iş hedefleriyle uyumu sağlamak için gelecekteki
yineleme için görevlerin önceliğini yeniden değerlendirir.
Agile(Çevik Yöntemler)
• Buna göre, sık sürümler Çevik modellerin karakteristiğidir. Ayrıca, kolay
düzeltmeler ve değişiklikler, hızlı güncellemeler ve özellik ekleme ile
sürekli yazılım iyileştirmesine olanak tanır ve kullanıcıların ihtiyaçlarını
daha iyi karşılayan uygulamaların sunulmasına yardımcı olur. Bununla
birlikte, ayrıntılı planlama eksikliği ve değişikliklere açıklık, proje için
gereken bütçeyi, zamanı ve insanları doğru bir şekilde tahmin etmeyi
zorlaştırır.
• Kullanım durumları:
• Son kullanıcıların erken geri bildirimi gerektiğinde, neredeyse tüm
başlangıç girişimleri.
• İş gereksinimlerinin güvenle ayrıntılı yazılım gereksinimlerine
dönüştürülemediği özel yazılım geliştirme alanındaki orta ölçekli
projelerin çoğu.
• Küçük işlevsel parçalara kolayca bölünebilen ve her yinelemede artımlı
olarak geliştirilebilen büyük projeler.
• Agile farklı türlerde kullanılır. Günümüzde en yaygın alt türleri Scrum,
Extreme Programming ve Kanban'dır.
Scrum
• Scrum muhtemelen en popüler Çevik modeldir.
Yinelemeler ("sprintler") genellikle 2-4 hafta
uzunluğundadır ve öncesinde ayrıntılı planlama ve önceki
sprint değerlendirmesi yapılır. Sprint aktiviteleri
tanımlandıktan sonra herhangi bir değişikliğe izin
verilmez.
Extreme Programming (XP)
• Extreme Programming (XP) ile tipik bir iterasyon 1-2
hafta sürer. Model, takımın henüz ilgili yazılım parçasıyla
çalışmaya başlamamış olması durumunda, yinelemenin
başlatılmasından sonra bile değişikliklerin uygulanmasına
izin verir. Bu tür bir esneklik, kaliteli yazılımların
sunulmasını önemli ölçüde zorlaştırır. Sorunu azaltmak
için XP, ikili programlama, test güdümlü geliştirme ve test
otomasyonu, sürekli entegrasyon (CI), küçük sürümler,
basit yazılım tasarımı ve kodlama standartlarını takip
etmek için kurallar gerektirir.
Kanban
• Kanban'a gelince, onun temel ayırt edici özelliği, belirgin
yinelemelerin olmamasıdır. Kullanılırsa, son derece kısa
tutulurlar ("günlük sprintler"). Bunun yerine, planın
görselleştirilmesine vurgu yapılır. Ekip, tüm proje
faaliyetlerini, bunların sayısını, sorumlu kişileri ve ilerlemeyi
net bir şekilde gösteren Kanban Panosu aracını kullanır. Bu tür
artan şeffaflık, en acil görevlerin daha doğru bir şekilde
tahmin edilmesine yardımcı olur. Ayrıca, modelin ayrı bir
planlama aşaması yoktur, bu nedenle herhangi bir zamanda
yeni bir değişiklik talebi sunulabilir. Müşteri ile iletişim devam
ediyor, iş sonuçlarını istedikleri zaman kontrol edebiliyorlar ve
proje ekibi ile toplantılar günlük bile olabiliyor. Model, doğası
gereği yazılım desteği ve geliştirme projelerinde sıklıkla
kullanılmaktadır.
Metodolojiler
Metodoloji: Bir BT projesi ya da yazılım yaşam döngüsü
aşamaları boyunca kullanılacak birbirleriyle uyumlu
yöntemler bütünü.

Bir metodoloji,
• bir süreç modelini ve
• belirli sayıda belirtim yöntemini içerir

Günümüzdeki metodolojiler; çağlayan, V ya da spiral

süreç modellerini temel almaktadır.
Bir Metodolojide Bulunması Gereken Temel
Bileşenler
• Ayrıntılandırılmış bir süreç • Konfigürasyon yönetim modeli
modeli
• Maliyet yönetim modeli
• Ayrıntılı süreç tanımları
• Kalite yönetim modeli
• İyi tanımlı üretim yöntemleri
• Risk yönetim modeli
• Süreçler arası ara yüz tanımları
• Değişiklik yönetim modeli
• Ayrıntılı girdi tanımları
• Kullanıcı arayüz ve ilişki modeli
• Ayrıntılı çıktı tanımları
• Standartlar
• Proje yönetim modeli
Bir Metodolojide Bulunması Gereken Temel
Bileşenler
• Metodoloji bileşenleri ile ilgili olarak bağımsız kuruluş
(IEEE, ISO, vs.) ve kişiler tarafından geliştirilmiş çeşitli
standartlar ve rehberler mevcuttur.

• Kullanılan süreç modelleri ve belirtim yöntemleri zaman

içinde değiştiği için standart ve rehberler de sürekli
güncellenmektedir.
Yourdon Yapısal Sistem Tasarım Metodolojisi
Yazılım Geliştirme Süreci
Ana İşlemler Destek İşlemler
• Gereksinim analizi • Proje izleme ve kontrol
• Tasarım • Yazılım kalitesinin sağlanması
• Kodlama • Teknik gözden geçirme
• Test • Yazılım belgelendirme yönetimi
• Bakım • Belge hazırlama
• Ölçüm
• Yeniden kullanılabilirlik yönetimi
• Risk yönetimi
Süreç İyileştirme
• Birçok yazılım şirketi, yazılımlarının kalitesini artırmanın,
maliyetlerini düşürmenin veya geliştirme süreçlerini
hızlandırmanın bir yolu olarak yazılım süreci iyileştirmeye
yönelmiştir.
• Süreç iyileştirme, ürün kalitesini artırmak ve / veya
maliyetleri ve geliştirme süresini azaltmak için mevcut
süreçleri anlamak ve bu süreçleri değiştirmek anlamına
gelir
İyileştirme Yolları
• Süreç olgunluk yaklaşımı, süreç ve proje yönetimini
iyileştirmeye ve iyi yazılım mühendisliği uygulamalarını
uygulamaya odaklanır.
• Süreç olgunluk seviyesi, organizasyonel yazılım geliştirme
süreçlerinde iyi teknik ve yönetim uygulamalarının ne
ölçüde benimsendiğini yansıtır.
• Çevik yaklaşım, yazılım sürecinde yinelemeli geliştirme ve
genel giderlerin azaltılmasına odaklanır.
• Çevik yöntemlerin temel özellikleri, işlevselliğin hızlı bir
şekilde sağlanması ve değişen müşteri gereksinimlerine
yanıt verme yeteneğidir
Süreç İyileştirme Döngüsü
Süreç İyileştirme Faaliyetleri
• Süreç ölçümü - Process measurement
• Yazılım sürecinin veya ürünün bir veya daha fazla özelliğini
ölçersiniz. Bu ölçümler, süreç iyileştirmelerinin etkili olup
olmadığına karar vermenize yardımcı olan bir temel oluşturur.
• Süreç analizi - Process analysis
• Mevcut süreç değerlendirilir ve süreç zayıflıkları ve
darboğazları belirlenir. Süreci tanımlayan süreç modelleri
(bazen süreç haritaları olarak adlandırılır) geliştirilebilir.
• Süreç değişimi - Process change
• Süreç değişiklikleri, belirlenen süreç zayıflıklarından bazılarını
ele almak için önerilmektedir. Bunlar tanıtılır ve döngü,
değişikliklerin etkinliği hakkında veri toplamak için devam
eder
Süreç Ölçümü
• Mümkün olan her yerde, nicel süreç verileri
toplanmalıdır
• Bununla birlikte, kuruluşların açıkça tanımlanmış süreç
standartlarına sahip olmadığı durumlarda, neyi
ölçeceğinizi bilmediğiniz için bu çok zordur. Herhangi bir
ölçümün mümkün olmasından önce bir sürecin
tanımlanması gerekebilir.
• Süreç iyileştirmelerini değerlendirmek için süreç
ölçümleri kullanılmalıdır
• Ancak bu, ölçümlerin iyileştirmeleri yönlendirmesi
gerektiği anlamına gelmez. İyileştirmenin itici gücü,
organizasyonel hedefler olmalıdır
Süreç Ölçütleri
• Süreç faaliyetlerinin tamamlanması için geçen süre
• Örneğin, bir etkinliği veya işlemi tamamlamak için takvim
süresi.
• Süreçler veya faaliyetler için gerekli kaynaklar
• Örneğin, kişi-gün cinsinden toplam çaba.
• Belirli bir olayın gerçekleşme sayısı
• Örneğin, keşfedilen kusurların sayısı
Yetenek Olgunluk Seviyeleri
Yetenek Olgunluk Seviyeleri
SEI Yetenek Olgunluk Modeli
• Başlangıç
• Aslında kontrolsüz
• Tekrarlanabilir
• Tanımlanan ve kullanılan ürün yönetimi prosedürleri
• Tanımlamak
• Tanımlanan ve kullanılan süreç yönetimi prosedürleri ve
stratejileri
• Yönetmek
• Tanımlanan ve kullanılan kalite yönetimi stratejileri
• Optimize etmek
• Tanımlanan ve kullanılan süreç iyileştirme stratejileri
Anahtar Noktalar
• Yazılım süreçleri, bir yazılım sisteminin üretilmesiyle ilgili
faaliyetlerdir. Yazılım süreç modelleri, bu süreçlerin soyut
temsilleridir.
• Genel süreç modelleri, yazılım süreçlerinin
organizasyonunu tanımlar.
• Bu genel modellerin örnekleri arasında "şelale" modeli,
arttırımsal geliştirme ve yeniden kullanıma yönelik
geliştirme yer alır.
• Gereksinim mühendisliği, bir yazılım tanımını geliştirme
sürecidir
Anahtar Noktalar
• Tasarım ve uygulama süreçleri, bir gereksinim tanımını
yürütülebilir bir yazılım sistemine dönüştürmekle ilgilidir.
• Yazılım onaylama, sistemin özelliklerine uygunluğunun
ve sistem kullanıcılarının gerçek ihtiyaçlarını karşıladığının
kontrol edilmesi sürecidir.
• Yazılım evrimi, mevcut yazılım sistemlerini yeni
gereksinimleri karşılayacak şekilde değiştirdiğinizde
gerçekleşir. Yazılım, kullanışlı kalması için gelişmelidir.
• Süreçler, değişimle başa çıkmak için prototip oluşturma
ve arttırımsal teslimat gibi faaliyetleri içermelidir.
Anahtar Noktalar
• Süreçler yinelemeli geliştirme ve teslimat için
yapılandırılabilir, böylece sistemi bir bütün olarak
bozmadan değişiklik yapılabilir.
• Süreç iyileştirmeye yönelik temel yaklaşımlar, süreç genel
giderlerini azaltmaya yönelik çevik yaklaşımlar ve daha iyi
süreç yönetimi ve iyi yazılım mühendisliği
uygulamalarının kullanımına dayalı olgunluğa dayalı
yaklaşımlardır.
• SEI süreci olgunluk çerçevesi, esasen iyi yazılım
mühendisliği uygulamalarının kullanımına karşılık gelen
olgunluk seviyelerini tanımlar
Hızlı Yazılım Geliştirme
• Hızlı geliştirme ve teslimat, çoğu yazılım sistemleri için en
önemli gereksinimdir.
• İşletmeler hızla değişen bir gereksinimle çalışır ve bir dizi
kararlı yazılım gereksinimi üretmek neredeyse
imkansızlaşır.
• Yazılım, değişen iş ihtiyaçlarını yansıtmak için hızla
gelişmelidir.
• Plan-odaklı geliştirme, bazı sistem türleri için gereklidir,
ancak bu iş gereksinimlerini karşılamaz.
• 1990’ların sonunda ortaya çıkan «çevik geliştirme
yöntemleri», çalışan yazılım sistemleri için teslimat
süresini kökten düşürmeyi amaçlamıştır
Çevik Geliştirm
• Program belirtimi, tasarımı ve uygulaması birbiriyle
ilişkilidir.
• Sistem, sürüm belirtimi ve değerlendirmesine dahil olan
paydaşlarla bir dizi sürüm veya artış olarak geliştirilmiştir.
• Değerlendirme için yeni sürümler sık sık
değerlendirilmelidir.
• Geliştirmeyi desteklemek için kapsamlı araç desteği (örn.
Otomatik test araçları) kullanılmalıdır.
• Çalışma koduna odaklanarak minimum dökümantasyon
sağlanmalıdır
Plan-Güdümlü ve Çevik Geliştirme
Plan-Güdümlü Çevik Geliştirme
• Yazılım mühendisliğine yönelik • Belirtim, tasarım, uygulama ve
önceden planlanan aşamaların testler birbiri ardına bırakılır ve
her birinde üretilecek çıktılarla geliştirme sürecinden elde
ayrı geliştirme aşamalarına edilen çıktılara, yazılım
dayanan plan odaklı bir geliştirme sürecinde bir
yaklaşımdır. müzakere süreci ile karar verilir
• Çağlayan modeli zorunlu
değildir - plan odaklı, kademeli
geliştirme mümkündür
• Yineleme, etkinlikler içinde
gerçekleşir.
KAYNAKLAR
• https://people.disim.univaq.it/~adimarco/teaching/swen
g14/
• https://www.scnsoft.com/blog/software-development-
models
• Ian Sommerville; “Software Engineering”, 10th Global Ed.,
Pearson, 2016.
• Jeffrey A. Hoffer, Joey F. George, Joseph S. Valacich;
“Modern Systems Analysis and Design”, 7th International
Ed., Pearson, 2014.
• https://akademik.adu.edu.tr/fakulte/muhendislik/person
el/sbasarici/courses
BAŞARILAR DİLERİZ.