İÇİNDEKİLER

KISIM 1: YAZILIM MÜHENDİSLİĞİNE GİRİŞ

BÖLÜM 1: GİRİŞ

PROFESYONEL YAZILIM GELİŞTİRME

- Yazılım Mühendisliği

- Yazılım Mühendisliği Çeşitliliği

- İnternet Yazılım Mühendisliği

YAZILIM MÜHENDİSLİĞİ ETİĞİ

DURUM ÇALIŞMALARI

- Bir İnsülin Pompası Kontrol Sistemi

- Ruh Sağlığı İçin Bir Hasta Bilgi Sistemi

- Bir Kır Hava İstasyonu

- Okullar İçin Sayısal Bir Öğrenme Ortamı

 KISIM 1
YAZILIM MÜHENDİSLİĞİNE GİRİŞ
1.BÖLÜM
GİRİŞ
Yazılım mühendisliği devletin, toplumun ve ulusal ve uluslararası iş dünyası ve kurumların işleyişi için gereklidir. Modern dünyayı yazılım
olmadan yürütemeyiz. Ulusal altyapılar ve servisler bilgisayar tabanlı sistemler tarafından kontrol edilir ve elektrikli ürünlerin çoğu
bilgisayar ve kontrol yazılımı içerirler.

Endüstriyel üretim ve dağıtım, iktisadi sistem gibi tamamen bilgisayarlaştırılmıştır. Eğlence, müzik endüstrisi dahil, bilgisayar oyunları, film
ve televizyon, yazılım yoğunlukludur. Hâlâ çok sayıda kötü giden yazılım projesi ve “yazılım arıza”ları raporlanmaktadır. Yazılım mühendisliği
modern yazılım geliştirme için yetersiz olmakla eleştirilmektedir.

Fakat kanımca, bir çok yazılım arızası iki etmenin sonucudur:

1. Artan sistem karmaşıklığı.

2. Yazılım mühendisliği yöntemlerini kullanmadaki başarısızlık.

Yazılım mühendisliği kavramı ilk olarak 1968’de o zaman yazılım krizi (Nauyr ve Randell 1969) olarak
adlandırılan konuları tartışmak için düzenlenen bir konferansta önerilmiştir. Program geliştirmedeki
birbirinden farklı yaklaşımların büyük ve karmaşık yazılım sistemlerinin geliştirilmesinde ölçeklenmediği
anlaşılmıştı . Yazılım sistemleri güvenilir olmamakta, beklenenden daha fazla maliyetle geç teslim
edilmekteydi.
1970’ler ve 1980’ler boyunca, yapısal programlama , bilgi saklama ve nesneye yönelik geliştirme gibi
çeşitli yeni yazılım mühendisliği teknikleri ve yöntemleri geliştirilmiştir. Günümüzdeki yazılım
mühendisliğinin temeli olan araçlar ve standart gösterimler geliştirilmiştir.
 PROFESYONEL YAZILIM GELİŞTİRME

• Birçok kişi program yazar. İşteki insanlar işlerini kolaylaştırmak için hesap çizelgesi (spreadsheet) programları yazarlar; bilim adamları ve
mühendisler deneysel verilerini işlemek için program yazarlar; amatörler kendi ilgileri ve merakları için program yazarlar.

• Ancak çoğu yazılım geliştirme, yazılımın iş amaçları için geliştirildiği, diğer cihazlara dahil edilmek üzere veya bilgi sistemleri ve bilgisayar
destekli tasarım sistemleri gibi yazılım ürünleri olarak geliştirildiği profesyonel bir etkinliktir.

• Temel farklılıklar, profesyonel yazılımın geliştiricisinden ayrı bir kişi tarafından kullanılmasının amaçlanması ve genellikle yazılımın
bireyler yerine takımlar tarafından geliştirilmesidir. Yazılım tüm yaşamı boyunca değiştirilir ve bakımı yapılır.

• Yazılım mühendisliğinin, bireysel programlamadan çok profesyonel yazılım geliştirmeyi desteklemesi amaçlanmıştır. Program
spesifikasyonu, tasarımı ve evrimi gibi normal kişisel yazılım geliştirme için önemli olmayan teknikler içerir.
Yazılım nedir?
Bilgisayar programları ve ilişkili belgeleme. Yazılım ürünleri belirli bir müşteri için
geliştirilebilir veya genel bir pazar için geliştirilebilir.
İyi yazılımın özellikleri nelerdir?
İyi yazılım kullanıcıya gereken fonksiyonelliği ve performansı sağlamalı ve bakımı
yapılabilir, güvenilebilir ve kullanılabilir olmalıdır.
Yazılım mühendisliği nedir?
Yazılım mühendisliği yazılım üretiminin başlangıçtaki ilk fikirden işletim ve bakıma kadar
olan tüm yönleriyle ilgilenen bir mühendislik disiplinidir.
Temel yazılım mühendisliği etkinlikleri nelerdir?
Yazılım spesifikasyonu, yazılım geliştirme, yazılım doğrulama ve yazılımın evrimi.
Yazılım mühendisliği ve bilgisayar bilimleri arasındaki fark nedir?
Bilgisayar bilimleri teori ve temeller üzerine odaklanır; yazılım mühendisliği ise kullanışlı
yazılım üretim ve tesliminin uygulamalarıyla ilgilenir.
Yazılım mühendisliği ve sistem mühendisliği arasındaki fark nedir?
Sistem mühendisliği donanım, yazılım ve süreç mühendisliği dahil olmak üzere bilgisayar
tabanlı sistem geliştirmenin tüm yönleriyle ilgilenir. Yazılım mühendisliği bu daha genel
sürecin parçasıdır.
Yazılım mühendisliği ile ilgili esas zorluklar nelerdir?
Artan çeşitlilikle başa çıkma, daha kısa teslim süresi talepleri ve güvenilir yazılım
geliştirme.
Yazılım mühendisliğinin maliyetleri nelerdir?
Yazılım maliyetlerinin kabaca %60'ı geliştirme maliyetleridir, %40'ı sinama maliyetleridir.
Özel ısmarlama yazılım için, evrim maliyetleri genellikle geliştirme maliyetlerini aşar.
En iyi yazılım mühendisliği teknikleri ve yöntemleri nelerdir?
Tüm yazılım projelerinin profesyonel olarak yönetilmesi ve geliştirilmesi gerekir ama
farklı sistem türleri için farklı teknikler uygundur. Örneğin oyunlar her zaman bir dizi
prototip kullanılarak geliştirilmeliyken, hayati tehlike arz eden kontrol sistemleri tam ve
analiz edilebilir bir spesifikasyonun geliştirilmesini gerektirirler. Her şey için iyi olan
yöntemler ve teknikler yoktur.
İnternet yazılım mühendisliğinde ne değişiklik yapmıştır?
İnternet sadece çok büyük, çok dağıtık servis-tabanlı sistemlerin geliştirilmesine yol
açmamıştır, aynı zamanda yazılımın ekonomisini değiştiren mobil cihazlar için bir
uygulama (app) endüstrisi yaratılmasını desteklemiştir.
 Yazılım Mühendisliği

Yazılım mühendisliği sistem spesifikasyonunun ilk aşamalarından sistemin kullanıma verildikten sonraki bakımına kadar yazılım üretiminin
tüm yönleriyle ilgilenen bir mühendislik disiplinidir. Bu tanımda iki anahtar ifade vardır:

a) Mühendislik Disiplini
b) Yazılım Üretiminin Tüm Yönleri

Yazılım mühendisliği iki nedenden dolayı önemlidir:

1. Kişiler ve toplum, gittikçe daha fazla gelişmiş yazılım sistemlerine güvenmektedirler. Emniyetli ve güvenilir sistemleri ekonomik ve hızlı
olarak üretebilmeliyiz.

2. Genellikle, uzun vadede, profesyonel yazılım sistemleri için yazılım mühendisliği yöntemlerini ve tekniklerini kullanmak, kişisel bir
programlama projesiymiş gibi sadece programlar yazmaktan daha ucuzdur. Yazılım mühendisliği yöntemini kullanmamak sınama, kalite
güvence ve uzun dönemli bakım için daha yüksek maliyetlere neden olur.
İyi yazılımın gerekli özellikleri . Kabul edilebilirlik.
Güvenilebilirlik ve güvenlik. Verimlilik. Bakım kolaylığı.
 Yazılım Mühendisliği Çeşitliliği

Yazılım mühendisliği, yazılım üretiminde yazılım müşterilerinin ve üreticilerinin gereksinimleri kadar pratikteki maliyet, zamanlama ve
güvenilirlik konularını da dikkate alan sistematik bir yaklaşımdır. Kullanılan yöntemler, araçlar ve teknikler yazılımı geliştiren kuruluşa,
yazılımın türüne ve geliştirme sürecine katılan kişilere bağlıdır.

Herhalde hangi yazılım mühendisliği yöntemlerinin ve tekniklerinin en önemli olduğunun belirlenmesinde en önemli faktör geliştirilen
uygulamanın türüdür. Çok farklı uygulama türleri vardır:

6.
3. Gömülü 7. Veri
2. Etkileşimli 4. Deste Modelleme
1. Bağımsız Kontrol 5. Eğlence Toplama ve 8. Sistemlerin
İşlem-Tabanlı İşleme ve
Uygulamalar Sistemleri Sistemleri Analiz Sistemleri
Uygulamalar Sistemleri Simülasyon
Sistemleri
İçin Sistemler
 İnternet Yazılım Mühendisliği

▪ İnternet’in ve World Wide Web’in geliştirilmesinin hepimizin yaşamlarında derin etkileri olmuştur. Başlangıçta, web evrensel olarak
erişilebilen bir bilgi deposuydu ve yazılım sistemleri üzerinde küçük bir etkisi olmuştu.

▪ Bu sistemler yerel bilgisayarda çalıştı ve sadece bir organizasyondan erişilebilirdi. 2000 yılı civarında web değişmeye başladı ve
tarayıcılara gittikçe daha fazla fonksiyonellik eklendi.

▪ Bunun anlamı, özel amaçlı bir kullanıcı arayüzü yerine, bu sistemlerin bir web tarayıcı aracılığıyla erişilebildiği yerde web tabanlı
sistemler geliştirilebilirdi.

▪ Bu durum web üzerinden erişilen ve yenilikçi servisler sunan çok büyük çeşitlilikte yeni sistemlerin geliştirilmesine yol açtı. Bunlar
genellikle kullanıcının ekranında görüntülenen reklamlarla desteklendi ve kullanıcılardan doğrudan ödeme içermedi.
 YAZILIM MÜHENDİSLİĞİ ETİĞİ

Diğer mühendislik disiplinleri gibi, yazılım mühendisliği, bu alanda çalışan kişilerin özgürlüğünü sınırlayan sosyal ve yasal bir çerçevede
yürütülür. Bir yazılım mühendisi olarak, mesleğinizin sadece teknik becerilerin uygulanmasından daha geniş sorumluluklar içerdiğini kabul
etmelisiniz.

Yeteneklerinizi ve becerilerinizi dürüst olmayan bir şekilde veya yazılım mühendisliği mesleğine itibarsızlaştıracak şekilde
kullanmamalısınız. Ancak kabul edilebilir davranışların standartlarının yasalara bağlı olmadığı fakat daha zayıf mesleki sorumluluk
kavramına bağlı olduğu alanlar vardır. Bunların bazıları:

3. Fikri Mülkiyet 4. Bilgisayarın Kötü

1. Gizlilik 2. Yeterlilik
Hakları Kullanımı
Yazılım Mühendisliği Etik kurallar ve Profesyonel uygulamalar
ACM/IEEE-CS Yazılım Mühendisliği Etiği ve Profesyonel Uygulamalar Ortak
Çalışması
ÖNSÖZ
Kuralların kısa sürümü istekleri yüksek bir soyutlama düzeyinde özetler; tam
sürümde eklenen ifade- ler örnekler verir ve bu isteklerin profesyonel
yazılım mühendisleri olarak davranışımızı nasıl değiştir- diğini ayrıntılandırır.
Bu istekler olmadan, ayrıntılar yasaya benzeyebilir ve bıktırıcı olabilir;
ayrıntılar olmadan istekler kulağa iyi ama boş gelebilir; istekler ve ayrıntılar
birlikte uyumlu kurallar oluştururlar. Yazılım mühendisleri yazılımın analiz,
spesifikasyon, tasarım, geliştirme, test ve bakımını yararlı ve saygı duyulan
bir meslek olarak yapma sorumluluğunu üstlenirler. Bu sorumlulukla
uyumlu olarak, toplumun sağlığı, güvenliği ve refahı için yazılım
mühendisleri aşağıdaki sekiz ilkeye sadık kalacaklar- dir:
1. TOPLUM - Yazılım mühendisleri toplumun ilgisiyle tutarlı hareket
edeceklerdir. 2. MÜŞTERİ ve İŞVEREN - Yazılım mühendisleri toplumun
ilgisiyle tutarlı olarak müşterilerin ve işverenin ilgisine en uygun şekilde
davranacaklardır.
3. ÜRÜN - Yazılım mühendisleri ürünlerinin ve ürünlerle ilgili değişikliklerin
mümkün olan en yüksek mesleki standartları karşılamasını sağlarlar.
4. DEĞERLENDİRME - Yazılım mühendisleri kendi mesleki
değerlendirmelerinde bütünlüğü ve bağımsızlığı sağlayacaklardır.
5. YÖNETİM - Yazılım mühendisliği yöneticileri ve liderleri yazılım geliştirme
ve bakımının yönetimine etik bir yaklaşıma uyacak ve onu daha da
geliştireceklerdir.
6. MESLEK - Yazılım mühendisleri toplum ilgisiyle tutarlı olarak mesleğin
bütünlüğünü ve itibarını geliştireceklerdir.
7. MESLEKTAŞLAR - Yazılım mühendisleri meslektaşlarına karşı adil ve
destekleyici olacaklardır.
8. KENDİSİ - Yazılım mühendisleri mesleklerinin uygulamalarını göz önüne
alarak yaşam boyu öğrenmeye katılacak ve mesleklerinin uygulanmasında
etik bir yaklaşım izleyeceklerdir.
 DURUM ÇALIŞMALARI

Yazılım mühendisliği kavramlarını örnekle açıklamak için dört farklı tür sistemden örnekler kullanıyorum. Bu kitaptaki anahtar mesajlardan
biri yazılım mühendisliği uygulamasının üretilen sistemin türüne bağlı olması olduğu için kasten tek bir durum çalışması kullanmadım. Bu
nedenle emniyet, güvenilirlik, sistem modelleme, yeniden kullanım vb. gibi kavramları tartışırken uygun bir örnek seçiyorum. Durum
çalışmaları olarak kullandığım sistem türleri:

3. Sensör Tabanlı
1. Gömülü Sistem 2. Bilgi Sistemi Veri Toplama 4. Destek Ortamı
Sistemi
 Bir İnsülin Pompası Kontrol Sistemi

İnsülin pompası pankreasın (bir iç organ) işleyişini taklit eden medikal bir sistemdir. Bu sistemi kontrol eden yazılım bir sensörden bilgi
toplayan ve kullanıcıya kontrollü olarak insülin dozu veren bir pompayı yöneten bir gömülü sistemdir. Diyabetli kişiler bu sistemi kullanırlar.

Diyabet, kişinin pankreasının insülin adı verilen hormonu yeterli miktarlarda üretemediği bir durumdur. İnsülin kandaki glikozu (şeker)
metabolizma için kullanır.

Diyabetin geleneksel tedavisi genetik olarak üretilmiş insülinin düzenli enjeksiyonlarını içerir. Diyabetliler düzenli olarak kan şekeri
düzeylerini dışsal bir ölçü kullanarak ölçerler ve enjekte etmeleri gereken insülin dozunu tahmin ederler.
İnsülin pompasının donanım mimarisi
İnsülin pompasının etkinlik diyagramı
ZihinSaS sistem organizasyonu
 Ruh Sağlığı İçin Bir Hasta Bilgi Sistemi

• Ruh sağlığını desteklemek için bir hasta bilgi sitemi (ZihinSaS sistemi), ruh sağlığı problemleri olan hastalar ve aldıkları tedaviler
hakkında bilgi tutan bir tıbbi bilgi sistemidir.

• ZihinSaS sistemi (Şekil 1.6) kliniklerde kullanımı amaçlanmış bir hasta bilgi sistemidir. Merkezileştirilmiş bir hasta bilgi veri tabanı kullanır
fakat bir dizüstü bilgisayarda çalışabilecek şekilde tasarlanmıştır, bu nedenle güvenli ağ bağlantısı bulunmayan sitelerden erişilip
kullanılabilir.

• Sistem tam bir tıbbi kayıt sistemi değildir ve bu nedenle diğer tıbbi koşullar hakkında bilgi tutmaz. Fakat diğer klinik bilgi sistemleriyle
etkileşebilir ve veri değişimi yapabilir. Sistemin iki amacı vardır:

1. Sağlık servis yöneticilerinin yerel ve devlet hedeflerine göre performansının değerlendirebilmesi için yönetim bilgisi oluşturmak.
2. Hastaların tedavisini desteklemek için tıbbi personele zamanında veri sağlamak.
 Bir Kır Hava İstasyonu

Kır hava istasyonları, hava istasyonlarından veriler toplayan ve işlenmesi için diğer sistemlere sunulan daha büyük bir hava bilgi sistemin
(Şekil 1.7) parçasıdırlar. Şekil 1.7’deki sistemler şunlardır:

Hava istasyonunun çevresi

 Okullar İçin Sayısal Bir Öğrenme Ortamı

Birçok öğretmen eğitimi desteklemek için etkileşimli yazılım sistemlerinin kullanılmasının hem artırılmış öğrenci motivasyonu hem de
öğrencilerde daha derin bir bilgi düzeyi ve anlayış oluşturabileceğini iddia ederler.

Fakat bilgisayar destekli öğrenme için en iyi strateji konusunda genel bir anlaşma yoktur ve öğretmenler öğrenmeyi desteklemek için
pratikte bir çok farklı etkileşimli, web tabanlı araç kullanırlar. Sistem, tüm sistem bileşenlerinin değiştirilebilir servisler olarak düşünüldüğü
bir servis tabanlı sistemdir.

Sistemde üç tür servis vardır:

1. Yardımcı servisler,
2. Uygulama servisleri,
3. Konfigürasyon servisleri.
Sayısal bir öğrenme ortamının
(eOgren) mimarisi
 İÇİNDEKİLER

BÖLÜM 2: YAZILIM SÜREÇLERİ

YAZILIM SÜREÇ MODELLERİ

- Çağlayan Modeli

- Artırımlı Geliştirme

- Bütünleştirme ve Konfigürasyon

SÜREÇ ETKİNLİKLERİ

- Yazılım Spesifikasyonu

- Yazılım Tasarımı ve Gerçekleştirimi

- Yazılım Geçerleme

- Yazılım Evrimi

DEĞİŞİMLE BAŞ ETME

- Prototip Geliştirme

- Artırımlı Teslimat

SÜREÇ İYİLEŞTİRME
 2.BÖLÜM
YAZILIM SÜREÇLERİ
Yazılım süreci, bir yazılım sisteminin üretimiyle sonuçlanan ilgili etkinlikler dizisidir. Farklı şirketlerde kullanılan süreçler, geliştirilen yazılımın
türüne, yazılım müşterisinin gereksinimlerine ve yazılımı yazan kişilerin yeteneklerine bağlı olarak değişmektedir.

Farklı yazılım süreçleri olmasına karşın, bu süreçlerin hepsi, Bölüm 1’de giriş yaptığım temel yazılım mühendisliği etkinliklerini bir şekilde
içermelidir:

1. Yazılım spesifikasyonu Yazılımın fonksiyonelliği ve uygulanmasındaki kısıtlamalar tanımlanmalıdır.

2. Yazılım geliştirme Spesifikasyonu karşılayan yazılım üretilmelidir.

3. Yazılım geçerleme Müşterinin istediğini gerçekleştirdiğinden emin olmak için yazılım geçerlenmelidir.

4. Yazılım evrimi Yazılım, değişen müşteri ihtiyaçlarını karşılamak için evrim geçirmelidir.
 YAZILIM SÜREÇ MODELLERİ

Her süreç modeli, süreci belli bir açıdan ele aldığından söz konusu süreç ile ilgili yalnızca kısmi bilgi sağlar. Örneğin, bir süreç etkinlik
modeli, etkinlikler ve bunların sıralamasını göz önüne serebilir; ancak bu etkinliklerde yer alan kişilerin rollerini ortaya koymayabilir.

Bu genel modeller, farklı yazılım geliştirme yaklaşımlarını açıklamak için kullanılan yazılım süreçlerinin üst-düzey, soyut tanımlamalarıdır. Bu
modeller, daha belirli yazılım mühendislik süreçleri yaratmak amacıyla genişletilebilen ya da uyarlanabilen süreç çerçeveleri olarak da
düşünülebilir. Bu bölümde ele alacağım genel süreç modelleri aşağıda yer almaktadır:

1. Çağlayan modeli
2. Artırımlı geliştirme
3. Bütünleştirme ve konfigürasyon.
Rational Birleşik Süreci (RBS) (İng. The Rational Unified Process-RUP)

Rational Birleşik Süreci (RBS), burada sözü edilen genel süreç modellerinin hepsini bir araya getirerek
yazılımın prototiplemesini ve artırımlı teslimini destekler (Krutchen 2003). RBS, genel olarak üç pers- pektifle
açıklanmaktadır: Modelin zaman içerisindeki evrelerini gösteren dinamik perspektif, süreç etkinliklerini ortaya
koyan statik perspektif ve süreçte kullanılabilecek iyi uygulamaları öneren uygulama perspektifi. RBS, şu
evrelerden oluşmaktadır: sistemin iş durumunun ortaya koyulduğu başlangıç evresi; gereksinim ve mimarinin
geliştirildiği detaylandırma evresi; yazılımın gerçekleştirildiği inşa etme evresi; ve sistemin uygulamaya
konulduğu kullanıma geçiş evresi.
Çağlayan modeli
 Çağlayan Modeli

Yazılım geliştirme sürecinin yayınlanmış ilk modeli, büyük askeri sistem mühendisliklerinde kullanılan süreç modellerinden yola çıkarak
geliştirilmiştir. Bu model, yazılım geliştirme sürecini Şekil 2.1’de gösterildiği şekilde aşamalar halinde ortaya koyar. Bir evreden diğerine art
arda akış söz konusu olduğundan bu model çağlayan modeli ya da yazılım yaşam döngüsü olarak bilinmektedir.

Çağlayan modelinin aşamaları, temel yazılım geliştirme etkinliklerini yansıtmaktadır:

1. 3. 4.
Gereksinimlerin 2. Sistem ve Gerçekleştirim Bütünleştirme 5. İşletim ve
Analizi ve Yazılım Tasarımı ve Birim ve Sistem Bakım
Tanımlanması Sınama Sınama
Boehm'in sarmal süreç modeli
Yazılım mühendisliğinin öncülerinden olan Barry Boehm, risk-güdümlü bir artırımlı süreç modeli
önermiştir. Bu süreç, bir etkinlikler dizisinden ziyade sarmal olarak gösterilmektedir (Boehm
1988).
Sarmaldaki her döngü, yazılım sürecindeki bir evreyi temsil eder. Örneğin, en içteki döngü sistem
fizibilitesiyle, bir sonraki gereksinimlerin tanımıyla, ondan sonraki sistem tasarımıyla, vb. ilgili
olabi- lir. Sarmal model, değişimden kaçınmayı değişime tolerans ile birleştirir. Değişikliklerin
proje riskle- rinin bir sonucu olduğunu varsayarak bu riskleri azaltmak için belirgin risk yönetim
etkinlikleri içerir.
 Artırımlı Geliştirme
Artırımlı geliştirme; başlangıç gerçekleştirimi, kullanıcı ve diğer kişilerden geri bildirim alma ve gereken sistem geliştirilene kadar pek çok
versiyon yoluyla yazılımın evrim geçirmesi fikrine dayanır (Şekil 2.2). Spesifikasyon, geliştirme ve geçerleme etkinlikleri ayrı değil, birbirine
geçmiş durumdadır ve etkinlikler arasında hızlı geri bildirimler söz konusudur.

Artırımlı geliştirme
Artırımlı geliştirmeyle ilgili sorunlar
Artırımlı geliştirmenin pek çok avantajı olmasına karşın sorunsuz olduğu söylenemez. Karşılaşılan
zor- lukların başlıca nedeni, büyük kuruluşların zaman içerisinde evrim gösteren bürokratik
prosedürlere sahip olması ve daha gayriresmî olan yinelemeli veya çevik süreçler ile bu
prosedürler arasında bir uyumsuzluğun söz konusu olmasıdır.
Bazen bu prosedürlerin iyi gerekçeleri bulunmaktadır. Örneğin, yazılımın dış yasal düzenlemelere
(örn., Amerika Birleşik Devletleri'nde Sarbanes Oxley muhasebe kanunu) uygunluğunu sağlayan
prose- dürler mevcuttur. Bu prosedürleri değiştirmek mümkün olmadığından süreç ile
uyuşmazlıklar kaçınıl- maz olabilmektedir.
Yeniden kullanıma yönelik yazılım mühendisliği
 Bütünleştirme ve Konfigürasyon

Yazılım projelerinin büyük çoğunluğunda, yazılımın bir kısmı yeniden kullanılmaktadır. Bu genellikle proje üzerinde çalışan kişilerin ihtiyaç
duyulana benzer kodları bilmesi ya da araması sonucu gayriresmî şekilde meydana gelir. Bu kodlar bulunup gerekli kısımlarında değişiklik
yapıldıktan sonra geliştirilen yeni kodlara entegre edilir.

Yazılım bileşenlerinin aşağıda verilen üç türü sık olarak yeniden kullanılmaktadır:

1. Belli bir ortamda kullanma amaçlı konfigüre edilen, tek başına kullanılabilen uygulama sistemleri. Bu genel-amaçlı sistemler pek çok
özelliğe sahip olmakla birlikte bunların belirli bir uygulamada kullanılması için adaptasyonu gerekir.

2. Java Spring benzeri bir bileşen çerçevesiyle entegre edilmek üzere, bileşen ya da paket olarak geliştirilen nesne derlemeleri.

3. Servis standartlarına göre geliştirilen ve internet üzerinden uzaktan çağırma için kullanılan web servisleri.
Yazılım geliştirme araçları
Yazılım geliştirme araçları, yazılım mühendisliği süreç
etkinliklerini desteklemek amacıyla kullanılan programlardır.
Bunlar arasında gereksinim yönetim araçları, tasarım editörleri,
yeniden üretim destek araçları, derleyiciler, hata ayıklayıcılar,
hata izleyiciler ve sistem inşa araçları yer almaktadır.
Yazılım araçları, bazı etkinlikleri otomatikleştirerek ve
geliştirilen yazılım hakkında bilgi sağlayarak sürece destek
vermektedir. Örneğin:
■ Gereksinim spesifikasyonunun ya da yazılım tasarımının
parçası olan grafik sistem modellerinin geliştirilmesi
Bu grafik modellerden kod üretimi
■ Kullanıcı tarafından etkileşim halinde oluşturulan grafik
arayüz tanımları kullanılarak kullanıcı arayüzünün oluşturulması
■ Çalıştıran program hakkında bilgi sağlayarak hataların
ayıklanması
■ Programlama dilinin eski bir versiyonunda yazılmış
programların otomatik olarak daha güncel bir versiyona
çevrilmesi
Yazılım araçları, Etkileşimli Geliştirme Ortamları ya da EGO
olarak adlandırılan çerçevede bir araya getirilebilir. Bu çerçeve,
araçların birbiriyle iletişim kurmasını ve entegre biçimde
çalışmasını kolaylaştı- racak ortak bir olanaklar dizisi
sunmaktadır.
 SÜREÇ ETKİNLİKLERİ

Gerçek yazılım süreçleri, genel hedefi bir yazılım sisteminin spesifikasyonu, tasarımı, gerçekleştirimi ve sınanması olan iç içe geçmiş teknik,
işbirliğine dayalı ve yönetimsel etkinlikler dizisidir. Günümüzde süreçler genellikle araçlar tarafından desteklenmektedir.

Bir başka deyişle yazılım geliştiriciler, gereksinim yönetim sistemleri, tasarım model editörleri, program editörleri, otomatikleştirilmiş test
araçları ve hata ayıklayıcıları gibi çeşitli yazılım araçlarından faydalanabilmektedir.

Dört temel süreç etkinliği olan spesifikasyon, geliştirme, geçerleme ve evrim, farklı geliştirme süreçlerinde farklı olarak düzenlenir. Bu
etkinlikler çağlayan modelinde art ardayken, artırımlı geliştirmede iç içe geçmiş durumdadır.
 Yazılım Spesifikasyonu
Yazılım spesifikasyonu ya da gereksinim mühendisliği, sistemin sunması gereken servislerin anlaşılması ve tanımlanması, sistemin işletim ve
geliştirimi üzerindeki kısıtlamaların belirlenmesi sürecidir. Bu aşamada yapılan hatalar sistem tasarımı ve gerçekleştiriminde daha sonra
kaçınılmaz sorunlara yol açtığından gereksinim mühendisliği, yazılım sürecinde kritik öneme sahiptir.

Gereksinim mühendisliği süreci

Tasarım sürecinin genel bir modeli
 Yazılım Tasarımı ve Gerçekleştirimi

Yazılım geliştirmenin gerçekleştirim aşaması, çalıştırılabilir bir sistemin müşteriye teslim amaçlı geliştirilmesi sürecidir. Bu süreç kimi zaman,
yazılım tasarımı ve programlamayla ilgili ayrı etkinlikler içerir.

Ancak, çevik geliştirme yaklaşımı kullanıldığı durumlarda, tasarım ve gerçekleştirim iç içe geçmiş durumdadır ve bu süreçte, biçimsel
tasarım belgeleri üretilmez. Doğal olarak, yazılım tasarımı hâlâ yapılmaktaysa da bu tasarım gayriresmî olarak beyaz tahta ve programcı
defterlerine kaydedilir.

Test aşamaları
 Yazılım Geçerleme

Yazılım geçerleme ya da genellikle kullanılan ifadesiyle doğrulama ve geçerleme (D & G), bir sistemin hem spesifikasyonuna uygun
olduğunun hem de müşterisinin beklentilerini karşıladığının gösterilmesini amaçlar. Başlıca geçerleme tekniği, sistemin temsili test verileri
kullanılarak çalıştırıldığı program testidir.

Plan-güdümlü yazılım sürecinde test aşamaları

 Yazılım Evrimi

Yazılımın esnekliği sayesinde her geçen gün daha fazla yazılım, büyük ve karmaşık sistemlere dahil edilmektedir. Donanım üretimiyle ilgili
bir karar alındıktan sonra donanım tasarımında değişiklik yapmak oldukça masraflıdır. Ancak, sistem geliştirme esnasında ya da sonrasında
herhangi bir zamanda, yazılımda değişiklik yapmak mümkündür. Kapsamlı değişiklikler bile, sistem donanımına yapılan benzer
değişikliklerden önemli ölçüde az maliyete sahiptir.

Yazılım sisteminin evrimi

 DEĞİŞİMLE BAŞ ETME

Büyük yazılım projelerinde değişim kaçınılmazdır. İşletmelerdeki dış baskı, rekabet ve değişen yönetim öncelikleri karşısında sistem
gereksinimleri değişmektedir. Yeni teknolojiler ortaya çıktıkça tasarım ve gerçekleştirmeye yönelik yeni yaklaşımlar mümkün hale
gelmektedir. Bu nedenle, hangi yazılım süreç modeli kullanılırsa kullanılsın, geliştirilen yazılımı değişime uydurabilmesi büyük önem
taşımaktadır.

Yeniden çalışmanın maliyetini düşürmede aşağıdaki iki yaklaşım kullanılabilir:

1. Değişimi öngörme

2. Değişime tolerans
 Prototip Geliştirme

Prototip, kavramların gösterilmesi, tasarım seçeneklerinin değerlendirilmesi ve sorunlar ile olası çözümleri hakkında daha fazla bilgi
edinilmesi amacıyla kullanılan yazılım sisteminin erken bir versiyonudur.

Yazılımın prototipi, yazılım geliştirme sürecinde gerek duyulabilecek değişimleri öngörmeye yardımcı olmak amacıyla kullanılabilir:

1. Gereksinim mühendisliği sürecinde prototip, sistem gereksinimlerinin çıkarılması ve geçerlenmesinde yardımcı olur.

2. Sistem tasarım sürecinde prototip, yazılım çözümlerinin araştırılması ve sistem için bir kullanıcı arayüzü geliştirilmesi için kullanılabilir.
Prototip geliştirme
Artırımlı teslimat
 Artırımlı Teslimat

Artırımlı teslimatın avantajları şu şekildedir:

1. Müşteriler, erken artırımları prototip olarak kullanarak sonraki sistem artırımlarında gereksinimlerin daha bilgili olarak belirlenmesi için
deneyim kazanırlar. Prototiplerin aksine, artırımlar gerçek sistemin parçası olduğundan bütün sistem hazır olduğunda, yeniden
öğrenme ihtiyacı söz konusu değildir.

2. Müşterilerin sistemden değer elde edebilmek için, tüm sistemin teslimatını beklemeleri gerekmez. İlk artırım en kritik gereksinimleri
karşıladığından müşteriler, yazılımı hemen kullanmaya başlayabilir.

3. Bu süreç, artırımlı geliştirmenin sisteme dahil edilecek değişiklikleri nispeten daha kolay hale getirmesi faydasına sahiptir.
 SÜREÇ İYİLEŞTİRME

Günümüzde, giderek daralan sürelerde teslim edilmesi beklenen, daha ucuz ve

daha iyi yazılıma yönelik sürekli bir talep söz konusudur. Bu nedenle yazılım
şirketleri, yazılım süreç iyileştirmeyi yazılımlarının kalitesini arttırma, maliyetleri
düşürme ya da geliştirme süreçlerini hızlandırmanın bir yolu olarak görmeye
başlamıştır.

Süreç iyileştirme döngüsü

Yetenek olgunluk seviyeleri
 İÇİNDEKİLER

BÖLÜM 3: ÇEVİK YAZILIM GELİŞTİRME

ÇEVİK YÖNTEMLER

ÇEVİK GELİŞTİRME TEKNİKLERİ

- Kullanıcı Öyküleri

- Yeniden üretim

- Test-Önce Geliştirme

ÇEVİK PROJE YÖNETİMİ

ÇEVİK YÖNTEMLERİ ÖLÇEKLEME

 3.BÖLÜM
ÇEVİK YAZILIM GELİŞTİRME
Hızlı yazılım geliştirme, çevik yazılım geliştirme ya da çevik yöntemler olarak bilinir hale gelmiştir. Çevik yöntemler, kullanılabilir yazılımın
çabuk bir şekilde üretilebilmesi düşüncesi ile tasarlanmıştır. Önerilen tüm çevik yöntemler bir dizi ortak özelliği paylaşır:

1. Spesifikasyon, tasarım ve uygulama süreçleri iç içe geçmiştir. Detaylı sistem spesifikasyonu ve tasarım dokümantasyonu yoktur ya da
sistemi geliştirmek için kullanılan uygulama ortamı tarafından otomatik olarak oluşturulur.

2. Sistem bir dizi artım ile geliştirilir. Son-kullanıcılar ve diğer sistem paydaşları her artımın belirlenmesi ve değerlendirilmesi süreçlerine
katılırlar.

3. Geliştirme sürecini desteklemek üzere kapsamlı araç desteği alınır. Bu araçlar otomatik test araçlarını, yapılandırma yönetimini ve
sistem bütünleştirmeyi destekleyen ve kullanıcı arayüzü geliştirmeyi otomatikleştiren araçları içerebilir.
Plan- güdümlü ve çevik geliştirme
 ÇEVİK YÖNTEMLER

1980’lerde ve 1990’ların başında daha iyi yazılım geliştirmenin en iyi yolunun dikkatli proje planlama, resmi kalite güvence, yazılım araçları
ile desteklenen analiz ve tasarım yöntemlerinin kullanımı, kontrollü ve katı yazılım geliştirme süreçleri ile mümkün olduğuna dair yaygın bir
görüş vardı. Bu görüş havacılık ve devlet sistemleri gibi geniş ve uzun-yaşam süreli projeler geliştiren yazılım mühendisliği topluluğu
kaynaklıydı.

Bu plan-güdümlü yaklaşım farklı şirketlerde çalışan büyük takımlar tarafından kullanıldı. Takımlar genellikle coğrafi olarak ayrıktı ve yazılım
üzerinde uzun süreler çalışmaları gerekiyordu. Bu tür bir yazılıma, örnek olarak, proje başladıktan 10 yıl sonra, teslimi gerçekleştirilebilen
modern bir uzay aracının kontrol sistemi verilebilir.
 Çevik yöntemlerin ilkeleri

Müşterinin katılımı
Müşteriler geliştirme süreci boyunca geliştirme takımı ile yakın biçimde çalışmalıdır. Rolleri yeni gereksinimleri sağlamak, önceliklendirmek ve
sistem artımlarını değerlendirmektir.

Değişimin Benimsenmesi
Sistem gereksinimlerinin değişimi kaçınılmazdır, sistem bu değişiklikleri kabul edecek şekilde tasarlanmalıdır.

Artımlı teslim
Yazılım müşterinin her artım için belirlediği gereksinimlerin dahil edildiği artımlarla geliştirilir.

Sadeliğin sürdürülmesi
Hem geliştirilen yazılımda hem de yazılım geliştirme sürecinde sadeliğe odaklanın. Mümkün olduğu sürece sistemin karmaşıklığını azaltmaya
çalışın.

Süreçler değil, insanlar

Yazılım geliştirme takımının yetenekleri bilinmeli ve bu yeteneklerden faydalanılmalıdır. Takım üyeleri detaylı tarif veren süreçleri takip etmek
yerine kendi çalışma yaklaşımlarını geliştirme konusunda özgür bırakılmalıdır.
UP yayım döngüsü
 ÇEVİK GELİŞTİRME TEKNİKLERİ

Uç programlama ortaya çıktığı yıllarda tanıttığı bir dizi çevik pratikle tartışmalara neden olmuştu. Bu pratikler Şekil 3.4’te listelenmiştir ve
çevik manifestodaki yansımaları aşağıda verilmiştir:

1. Artımlı yazılım geliştirme, küçük ve sık yayımlarla (release) desteklenir. Gereksinimler, bir artımda olması gereken fonksiyonlara karar
vermede temel oluşturacak olan ve basitçe yazılmış kullanıcı öyküleri ya da senaryoları şeklinde ifade edilir.

2. Müşterinin katılımı geliştirme takımına sürekli olarak dahil edilmesi ile sağlanır. Müşteriyi temsil eden kişiler geliştirmede yer alır ve
sistem için kabul testlerini tanımlamaktan sorumludur.

3. Süreçler değil kişiler, eş programlama, sistem kodunun ortak sahipliği ve fazla mesai içermeyen sürdürülebilir çalışma saatleri ile
desteklenir.
Uç programlama pratikleri
 Kullanıcı Öyküleri

• Yazılım gereksinimleri daima değişir. Bu değişikliklerle baş edebilmek

için çevik yöntemler farklı gereksinim mühendisliği etkinliklerine sahip
değildir.

• Daha ziyade, çevik yöntemler gereksinimlerin ortaya çıkarılma sürecini

geliştirme süreci ile bütünleştirirler.

• Bunu daha kolay yapabilmek için bir sistem kullanıcısı tarafından

deneyimlenebilecek senaryoları ifade eden “kullanıcı öyküleri” fikri
geliştirilmiştir.
 Yeniden Üretim

• Geleneksel yazılım mühendisliğinin en temel kurallarından biri, değişiklik için tasarım yapma gerekliliğidir. Yani, sistemi tasarlarken
değişikliklerin kolaylıkla uygulanabilmesi için, ileride oluşabilecek değişikliler göz önünde bulundurulmalıdır.

• Fakat Uç Programlama, değişim göz önünde bulundurularak yapılan tasarıma dair çabaların çoğunlukla boşa harcandığını ileri sürerek
bu prensibi göz ardı etmiştir. Değişiklikle baş edebilmek amacıyla, programın daha genel olması için harcanan zamana değmemektedir.
Sıklıkla, öngörülen değişiklikler gerçekleşmemekte ya da öngörülenden tamamen farklı değişiklik talepleri oluşmaktadır.
 Test-Önce Geliştirme

Tüm testler başarılı bir şekilde çalıştırılmadan geliştirme süreci devam etmez. UP testinin önemli noktaları şunlardır:

1. Test Önce Geliştirme

2. Senaryolardan Yola Çıkarak Artımlı Test Geliştirme

3. Test Geliştirme Ve Geçerleme Aşamalarına Kullanıcıların Dahil Edilmesi

4. Otomatik Test Çerçevelerinin Kullanılması

 ÇEVİK PROJE YÖNETİMİ

Her yazılım işinde, yöneticiler neler olup bittiğini, projenin hedeflerini karşılayıp karşılayamayacağını ve yazılımın tahmin edilen bütçe ile
zamanında teslim edilip edilmeyeceğini bilmek ister.

Yazılım geliştirmede plan-güdümlü yaklaşımlar bu ihtiyacı gidermek için geliştirilmiştir. Plan-güdümlü bir yaklaşım, yöneticinin
geliştirilecek her şeyi ve geliştirme süreçlerini devamlı olarak görebilmesini gerektirir.

Çevik yöntemleri önce benimseyen kişilerin önerdiği resmi olmayan planlama ve kontrol yöntemleri, iş gereksinimlerinden biri olan
görünürlük ile çelişmiştir. Takımlar kendi kendilerine organize olabilir, proje belgesi üretmez ve geliştirmeyi kısa döngüler şeklinde planlar.
Scrum terminolojisi
Scrum Spint döngüsü
Dağıtık scrum
 ÇEVİK YÖNTEMLERİ ÖLÇEKLEME

Çevik yöntemler aynı odada birlikte çalışabilecek ve resmi olmayan şekillerde iletişim kurabilecek küçük programlama takımları için
geliştirilmiştir. Aslında küçük ve orta ölçekli sistemlerin ve yazılım ürünlerinin geliştirilmesinde kullanılmaktaydılar. Küçük şirketler, resmi
süreçler ve bürokrasi olmadan, çevik yöntemleri hevesle erken benimseyenlerden oldular.

Çevik yöntemleri ölçekleme ile ilgili konular:

1. Yöntemlerin tek bir takım tarafından geliştirilmeyecek kadar büyük olan sistemler için büyük ölçeğe göre uyarlanması.

2. Yöntemlerin büyük şirketlerde çok uzun yıllar yazılım geliştirme deneyimi olan özelleşmiş geliştirme takımları için küçük ölçeğe göre
uyarlanması.
 Çevik prensipler ve organizasyon pratikleri

Müşterinin katılımı
Bu geliştirme takımı ile zaman geçirme isteğine ve zamanına sahip ve tüm sistem paydaşlarını temsil edebilecek bir müşteriye sahip olmaya bağlıdır.
Çoğunlukla müşteri temsilcileri zamanlarını başka işlere de ayırdıkları için geliştirme takımında tam zamanlı olarak yer alamazlar. Örneğin
geliştirilecek sistemde denetleyici kurum gibi dış paydaşlar olduğu zaman, onların görüşlerini çevik takımlara yansıtmak zordur.
Değişimin benimsenmesi
Özellikle çok sayıda paydaşın olduğu sistemlerde değişiklikleri önceliklendirmek çok zor olabilir. Tipik olarak, her paydaş farklı değişikliklere farklı
öncelikler atayacaktır.
Artımlı teslim
Hızlı artımlar ve kısa-vadeli planlama, uzun vadeli planlama döngüleri olan iş planları ve pazarlama ile daima örtüşmeyebilir. Pazarlama yöneticileri
etkin pazarlama kampanyaları düzenleyebilmek için ürün özelliklerini aylar öncesinden bilmeye ihtiyaç duyabilir.
Sadeliğin sürdürülmesi
Teslim takvimlerinin baskısı nedeniyle, takım üyeleri arzu edilen sistem sadeleştirmelerini gerçekleştirmeye zaman bulamayabilir.
Süreçler değil, insanlar
Takım üyelerinin her biri, çevik geliştirme için tipik olan yoğun katılım sağlamaya uygun karakterde olmayabilir ve bu nedenle diğer takım üyeleri ile
iyi bir şekilde iletişim kuramayabilir.
Plan-güdümlü ya da çevik geliştirme seçimini etkileyen faktörler
Büyük proje özellikleri
IBM’ in Çeviklik Ölçekleme modeli
 İÇİNDEKİLER

BÖLÜM 4: GEREKSİNİM MÜHENDİSLİĞİ

FONKSİYONEL VE FONKSİYONEL OLMAYAN GEREKSİNİMLER

GEREKSİNİM MÜHENDİSLİĞİ SÜRECİ

GEREKSİNİMLERİN AÇIĞA ÇIKARILMASI

GEREKSİNİMLERİN SPESİFİKASYONU

GEREKSİNİMLERİN DOĞRULANMASI

GEREKSİNİMLERİN DEĞİŞİMİ
 4.BÖLÜM
GEREKSİNİM MÜHENDİSLİĞİ
Kullanıcı gereksinimleri ve sistem gereksinimleri aşağıdaki gibi tanımlanabilir:

1. Kullanıcı gereksinimleri sistemin kullanıcıya ne tür servisler sunacağı ve hangi kısıtlamalar altında çalışmak zorunda olduğunun doğal
dilde ve çizimler ile ifadesidir. Kullanıcı gereksinimleri gerekli sistem özelliklerinin genel olarak anlatıldığı ifadelerden sistem
işlevselliğinin ayrıntılı ve kesin olarak tariflendiği ifadelere kadar değişebilir.

2. Sistem gereksinimleri yazılım sisteminin fonksiyonlarının, servislerinin, işletme kısıtlarının çok daha ayrıntılı açıklamasıdır. Sistem
gereksinimleri dokümanı (bazen fonksiyonel spesifikasyon olarak adlandırılır) tam olarak ne gerçekleştirileceğini tanımlamalıdır. Sistemi
satın alan ve yazılım geliştiriciler arasındaki kontratın bir parçası olabilir.
Kullanıcı ve sistem gereksinimleri
Farklı gereksinim tanımlamalarının okuyucuları
Olabilirlik çalışmaları
 FONKSİYONEL VE FONKSİYONEL OLMAYAN GEREKSİNİMLER

Yazılım sistemi gereksinimleri genellikle fonksiyonel ve fonksiyonel olmayan gereksinimler olarak sınıflandırılır:

1. Fonksiyonel gereksinimler Bunlar sistemin sunması gerekli servislerin, sistemin belli girdilere nasıl tepki vermesi gerektiğinin, belli
durumlarda sistemin nasıl davranması gerektiğinin ifadesidir. Fonksiyonel gereksinimler bazı durumlarda sistemin ne yapmaması
gerektiğini de açıkça belirtebilir.

2. Fonksiyonel olmayan gereksinimler Bunlar sistemin sunduğu servisler ve fonksiyonlar üstündeki kısıtlamalardır. Zaman kısıtlamalarını,
geliştirme süreci üstündeki kısıtlamaları ve standartlarla dayatılan kısıtlamaları içerirler. Fonksiyonel olmayan gereksinimler genellikle
tek tek sistem olanakları ve servislerinden çok, sistemin bütününe uygulanır.
Alan gereksinimleri
Fonksiyonel olmayan gereksinim tipleri
ZihinSaS sistemi için fonksiyonel olmayan gereksinim örnekleri
Fonksiyonel olmayan gereksinimlerin spesifikasyon ölçütleri
 GEREKSİNİM MÜHENDİSLİĞİ SÜRECİ

İkinci bölümde tartıştığım gibi, gereksinim mühendisliği üç temel eylem içerir. Bunlar, paydaşlar ile etkileşerek gereksinimleri keşfetmek
(açığa çıkartmak ve analiz); bu gereksinimleri standart biçime çevirmek (tanımlama); ve gereksinimlerin gerçekten kullanıcının istediği
sistemi tanımladıklarını kontrol etmektir (doğrulamak).

Şekil 2.4’te bunları ardışık süreçler olarak göstermiştim. Bununla birlikte, pratikte gereksinim mühendisliği eylemlerin dönüşümlü çalıştığı
yinelemeli bir süreçtir. Şekil 4.6 bu dönüşümü gösterir.

Eylemler bir sarmal etrafında yinelemeli bir süreç olarak düzenlenmiştir. GM sürecinin çıktısı sistem gereksinimleri dokümanıdır. Bir
döngüde her eylem için harcanan zaman ve emek tüm sürecin evresine, geliştirilen sistemin tipine ve ayrılmış bütçeye bağlıdır.
Gereksinim mühendisliği sürecinin sarmal görüntüsü
 GEREKSİNİMLERİN AÇIĞA ÇIKARILMASI

Gereksinimlerin açığa çıkarılması sürecinin amaçları paydaşların yaptıkları işin ve yeni sistemi bu işi desteklemek için nasıl
kullanabileceklerinin anlaşılmasıdır. Paydaşlardan gereksinimleri açığa çıkarmak ve anlamak birkaç nedenden ötürü zor bir süreçtir:

1. Paydaşlar genellikle çok genel gereksinimler dışında bir bilgisayar sisteminden ne istediklerini bilmezler; sistemin ne yapmasını
istediklerini dile getirmekte zorlanabilirler; yapılabilir ve yapılamaz şeyleri bilmedikleri için gerçekçi olmayan isteklerde bulunabilirler.

2. Bir sistemdeki paydaşlar doğal olarak gereksinimleri kendi terimleri ve işlerinin üstü kapalı bilgisi ile ifade eder.

3. Değişik gereksinimlere sahip farklı paydaşlar gereksinimlerini farklı yollardan ifade edebilir.

4. Politik etkenler bir sistemin gereksinimlerini etkileyebilir. Yöneticiler kuruluşta etkilerini arttıracak sistem gereksinimleri talep edebilir.
Gereksinimlerin açığa çıkarılması ve analizi süreci
Bakış açıları
Gereksinimlerin analizi için etnografya ve prototip hazırlama
 GEREKSİNİMLERİN SPESİFİKASYONU

Gereksinimlerin spesifikasyonu kullanıcı ve sistem gereksinimlerini bir gereksinim dokümanı içinde yazma sürecidir. İdeal olarak, kullanıcı
ve sistem gereksinimleri açık, kesin, kolay anlaşılır, tam ve tutarlı olmalıdır. Pratikte, bunu elde etmek neredeyse imkânsızdır. Paydaşlar
gereksinimleri farklı şekillerde yorumlar ve çoğu zaman gereksinimlerde içsel çelişkiler ve tutarsızlıklar vardır.

Kullanıcı gereksinimleri gereksinim dokümanında neredeyse her zaman uygun diyagramlar ve tablolar ile desteklenmiş doğal dilde yazılır.
Sistem gereksinimleri de doğal dilde yazılabilir, ancak formlar, grafiksel ya da matematiksel sistem modelleri üstüne kurulu diğer
gösterimler de kullanılabilir. Şekil 4.11 sistem gereksinimlerini yazmak için olası gösterimleri özetler.
 Sistem gereksinimleri yazmak için gösterim

Doğal dil cümleleri

Gereksinimler numaralanmış cümleler kullanılarak doğal dilde yazılır. Her cümle bir gereksinimi açıklamalıdır.

Yapısal doğal dil

Gereksinimler doğal dilde standart bir form ya da şablon üstüne yazılır. Her alan gereksinimin bir yönü ile ilgili bilgi sağlar.

Grafik gösterim
Metin açıklamaları ile desteklenmiş grafik modeller sistemin fonksiyonel gereksinimlerini tanımlamak için kullanılır. UML (Unified modeling
language) kullanma durumu ve sıra diyagramları sıklıkla kullanılır.

Matematiksel spesifikasyonlar
Bu gösterimler sonlu makineler ya da kümeler gibi matematiksel kavramlara dayanır. Bu kesin spesifikasyonlar bir gereksinim dokümanında
belirsizliği azaltsa da, pek çok müşteri resmi bir spesifikasyonu anlamaz. Bunun istediklerini ifade ettiğini kontrol edemezler ve onu bir sistem
sözleşmesi olarak kabul etmeye isteksizdirler. (Bu yaklaşımı sistem güvenilebilirliğini içeren Bölüm 10'da tartışıyorum.)
Gereksinim spesifikasyonu için doğal dil kullanmanın
problemleri
ZihinSaS sistemi için kullanım durumları
 GEREKSİNİMLERİN DOĞRULANMASI

Gereksinimlerin doğrulanması müşterinin gerçekten istediği sistemi tanımlayan gereksinimlerin kontrol edilmesi sürecidir. Gereksinim
problemlerinin bulunması ile ilgilendiği için açığa çıkarma ve analiz ile örtüşür. Gereksinimlerin doğrulanması süreci sırasında gereksinim
dokümanındaki gereksinimler üstünde farklı tip kontroller uygulanmalıdır. Bu kontroller aşağıdakileri içerir:

1. Geçerlik 2. Tutarlılık 3. Tamlık 4. Gerçekçilik 5. Doğrulanabilirlik

Kontrolleri Kontrolleri Kontrolleri Kontrolleri Kontrolleri
Gereksinim incelemeleri
 GEREKSİNİMLERİN DEĞİŞİMİ

Büyük yazılım sistemleri için gereksinimler her zaman değişir. Bu sistemlerin genellikle “şeytani” problemleri (bütünüyle tanımlanamayan
problemleri) adreslemek üzere geliştiriliyor olması sık değişikliklerin bir nedenidir.

Problemler tam olarak tanımlanamadıkları için, yazılım gereksinimlerinin eksik olması kesin gibidir. Yazılım geliştirimi süreci sırasında
paydaşların problemi anlayışları sürekli değişir (Şekil 4.18). Bu durumda sistem gereksinimleri bu problem anlayışındaki değişikliği
yansıtmak için değişmek zorundadır.

Gereksinimlerin evrimi
Kalıcı ve uçucu gereksinimler

Gereksinim değişimi yönetimi

 İÇİNDEKİLER

BÖLÜM 5: SİSTEM MODELLEME

BAĞLAM MODELLERİ

ETKİLEŞİM MODELLERİ

YAPISAL MODELLER

DAVRANIŞSAL MODELLER

MODEL GÜDÜMLÜ MİMARİ

 5.BÖLÜM
SİSTEM MODELLEME
 BAĞLAM MODELLERİ

Sistem tanımlamanın erken bir safhasında sistemin sınırlarına karar vermeniz gerekir ki bu neyin geliştirilmekte olan sistemin içinde
kaldığına, neyin ise dışarıda bırakılacağına karar vermektir. Bu iş, paydaşlarla birlikte sistemin hangi işlevleri içereceğine karar vermek ve
sistemin operasyonel çevresindeki işleme ve çalışma biçimlerini belirlemek ile ilgilidir.

Bazı iş süreçleri için otomasyon desteği vermek isterken bazı başka süreçleri elle yapmak veya başka sistemlerle desteklemek
isteyebilirsiniz. Sistemin işlevlerinin bazı var olan sistemlerle çakışmasını kontrol etmek ve yeni işlevlerin nerede gerçekleştirilmesi
gerektiğine karar vermelisiniz. Maliyeti ve sistem gereksinimleri ile tasarımı anlamak için gereken zamanı azaltmak için bu kararlar sürecin
başlarında alınmalıdır.
ZihinSaS sisteminin bağlamı
İstemsiz alıkoymanın süreç modeli
Veri aktar kullanım durumu
 ETKİLEŞİM MODELLERİ

Tüm sistemler bir tür etkileşim gerektirir. Etkileşim, kullanıcı girdi ve çıktılarını içeren kullanıcı etkileşimi olmanın yanı sıra geliştirilmekte
olan sistem ile ortamdaki diğer sistemler arasında ve nihayet sistemin bileşenleri arasında yer alan etkileşimdir.

Kullanıcı etkileşimi modelleme kullanıcı gereksinimlerini belirlemeyi sağlaması nedeniyle önemlidir. Sistemler arası etkileşimi modellemek
iletişim problemlerini göz önüne getirir. Bu kısımda etkileşim modellemeye yönelik birbiriyle ilintili iki yaklaşım tartışılacaktır.

1. Kullanım durumu modelleme: Genellikle sistem ile dış faktörler arasındaki (insan kullanıcı veya başka bir sistem) etkileşimin
modellenmesidir.

2. Sıra diyagramları: Sistem bileşenleri arasındaki (dış faktörler dâhil) etkileşimin modellenmesidir.
Veri aktar kullanım durumunun tablo gösterimi
Tıbbi resepsiyonist içeren kullanım durumları
Hasta bilgisi görüntüle için sıra diyagramı
 YAPISAL MODELLER

• Yapısal modeller bir sistemin organizasyonunu o sistemi oluşturan bileşenler ve bileşenler arasındaki ilişkiler cinsinden gösterirler.

• Yapısal modeller sistem tasarımını gösteren statik modeller olabildikleri gibi sistemin çalışma esnasındaki organizasyonunu gösteren
dinamik modeller de olabilir.

• Bu ikisi aynı şey değildir; bir sistemin etkileşimli iş parçacıkları biçimindeki dinamik organizasyonu sistem bileşenlerini içeren statik
modelden çok farklı olabilir.

• Bir sistemin yapısal modellerini, sistem mimarisini tasarlarken ve tartışırken yaratırız. Bunlar tüm sistem mimarisinin modelleri
olabilirler veya sistem içindeki nesneler ve bunların ilişkilerini içeren daha detaylı modeller olabilirler.
UML sınıfları ve bağlar

ZihinSaS sistemindeki sınıflar ve bağlar

Bir Konsültasyon sınıfı
Bir genelleşme hiyerarşisi
Detaylandırılmış bir genelleştirme hiyerarşisi
 DAVRANIŞSAL MODELLER

Davranışsal modeller bir sistemin işleyişi sırasındaki dinamik davranışının modelleridir. Sistem, çevresinden gelen bir uyarana tepki
verdiğinde ne olduğunu veya ne olması gerektiğini gösterirler. Bu uyaranlar veri veya olaylar olabilir:

1. Sistem tarafından işlenecek olan veri erişilebilir hale gelir. Verinin mevcudiyeti işlemi tetikler.

2. Sistemin işleyişini tetikleyecek bir olay olur. Olaylar kendilerine bağlı verilere de sahip olabilirler fakat buna her zaman rastlanmaz.

Pek çok iş sistemi veri tarafından güdülen veri-işleme sistemleridir. Göreceli az sayıda dış olay işleme gereksinimi ile birlikte genellikle
sisteme girilen veri tarafından kontrol edilirler. İşlevleri veri üzerinde bir dizi etkinlik sonrasında çıktı üretmeyi içerir.
İnsülin pompasının çalışma biçimini gösteren etkinlik modeli
Sipariş işleme
Bir mikrodalga fırının durum diyagramı
Mikrodalga fırın için
durumlar ve uyaranlar
 MODEL GÜDÜMLÜ MİMARİ

Model güdümlü mimari, UML modellerinin bir alt kümesini kullanarak bir sistemi betimleyen, model odaklı bir yazılım tasarım ve
gerçekleştirim yaklaşımıdır. Burada farklı soyutlama derecelerindeki modeller yaratılır. Prensip olarak yüksek düzeyli platformdan bağımsız
bir modelden insan eli değmeden çalışan bir program oluşturmak mümkündür.

MDA metodu üç çeşit soyut sistem modelinin üretilmesini tavsiye eder:

1. Bir bilgisayardan bağımsız model (BBM)

2. Bir platformdan bağımsız model (PBM)

3. Bir Platforma özgü model (PÖM)

MDA dönüşümleri
Çoğul platforma özgü modeller
Executable UML
Model güdümlü mühendisliğin arkasındaki asıl fikir modellerden koda tam otomatik dönüşümün
mümkün olabilmesidir. Buna ulaşabilmek için şekilsel modelleri, anlamları açık biçimde tanımlanmış ve
çalıştırılabilir koda derlenebilecek biçimde kurabilmek gereklidir. Ayrıca şekilsel modellere bu modellerde
tanımlanan işlemlerin nasıl gerçekleştirildiği hakkında bilgiler eklemek için bir yönteme ihtiyaç vardır. Bu,
UML 2'nin çalıştırılabilir UML veya xUML adı verilen bir alt kümesini kullanarak mümkündür (Mellor ve
Balcer 2002).
 İÇİNDEKİLER

BÖLÜM 6: MİMARİ TASARIM

MİMARİ TASARIM KARARLARI

MİMARİ GÖRÜNÜMLER

MİMARİ DESENLER

UYGULAMA MİMARİLERİ

- Hareket İşleme Sistemleri

- Bilgi Sistemleri

- Dil İşleme Sistemleri

 6.BÖLÜM
MİMARİ TASARIM
• Mimari tasarım bir yazılım sisteminin nasıl yapılandırılması gerektiğini anlamak ve sistemin genel yapısını tasarlamaktır. Bölüm 2’de
açıkladığım yazılım geliştirme sürecinde yazılım tasarımı aşamasının ilk basamağı mimari tasarımdır.

• Bu basamak tasarım ile gereksinim mühendisliği arasındaki kritik bağlantıdır, çünkü sistemin ana yapısal bileşenlerini ve bu bileşenler
arasındaki ilişkileri belirlemektedir. Mimari tasarım sürecinin çıktısı bir sistemin haberleşen bileşenler olarak nasıl yapılandığını anlatan
bir mimari modeldir.
Bir paketleme robotu yönetim sisteminin mimarisi
Mimari tasarım kararları
 MİMARİ TASARIM KARARLARI

• Mimari tasarım bir sistemin fonksiyonel olan ve olmayan gereksinimlerini karşılayan bir sistem organizasyonunu tasarladığınız yaratıcı
bir süreçtir. Kalıplaşmış bir mimari tasarım süreci yoktur.

• Süreç, geliştirilen sisteme, sistem mimarının geçmişine, tecrübesine ve sistemin kendine özgü gereksinimlerine bağlı olarak
şekillenmektedir.

• Sonuç olarak kanımca mimari tasarımı bir etkinlikler dizisi olarak görmek yerine alınması gereken bir kararlar serisi olarak görmek en
doğrusudur.

• Mimari tasarım sürecinde sistem mimarları sistemi ve geliştirme sürecini ciddi olarak etkileyen birçok yapısal karar almak zorundadırlar.
Bilgilerine ve tecrübelerine dayanarak Şekil 6.2’de gösterilen sorulara cevap aramak durumunda kalırlar.
 MİMARİ GÖRÜNÜMLER

Bu bölümün girişinde bir yazılım sisteminin mimari modelinin, yazılım gereksinimleri veya tasarımı konulu bir tartışmayı doğru noktaya
odaklamak için kullanılabileceğini açıklamıştım. Buna alternatif olarak bir tasarımı sistemin daha detaylı bir tasarımına ve gerçekleştirimine
taban oluşturabilecek biçimde belgelemek amacıyla da kullanılabilir. Bu bölümde her iki kullanım ile de ilgili iki konuya değineceğim:

1. Bir sistemin mimarisini tasarlarken ve belgelerken hangi görünümler veya perspektifler kullanışlıdır?

2. Mimari modelleri ifade etmek için hangi gösterim biçimleri kullanılmalıdır?

Bir şekilsel model bir sistemin yalnızca bir tek görünümünü veya perspektifini gösterebilir; bu nedenle tek bir diyagramda bir sistemin
mimarisine ilişkin bütün bilgilerin gösterilmesi imkânsızdır. Bir sistemin nasıl modüllere ayrıştığını, çalışma zamanı süreçlerin nasıl
etkileştiklerini veya sistem bileşenlerinin bir ağ üzerinde farklı dağılma biçimlerini gösterebilir.
Mimari görünümler
 MİMARİ DESENLER

Desen fikri; yazılım sistemleri hakkındaki bilgiyi sunmanın, paylaşmanın ve yeniden kullanmanın bir yolu olarak, yazılım mühendisliğinin
birçok alanında benimsenmiştir. Bu akımı tetikleyen nesneye yönelik tasarım desenleri konusunda yazılmış bir kitap.

Bu kitap aynı zamanda bir dizi farklı desen tipinin ortaya çıkması için işaret fişeği işlevi görmüştür. Bunlar arasında organizasyonel tasarım
için olan desenler, kullanılabilirlik desenleri, iş birlikli etkileşim desenleri, ve yapılandırma yönetimi desenleri vardır.

Mimari desenler 1990’larda “mimari stiller” adı altında öne sürülmüştür. 1996 ile 2007 arasında desen tabanlı yazılım mimarisi konulu çok
detaylı beş ciltlik bir el kitabı serisi yayımlanmıştır.
Model Görünüm Kumanda (MGK) deseni
Model-Görünüm-Kumanda’nın yapılanması
Web application architecture using the MVC pattern
Katmanlı mimari deseni
Ambar deseni
Bir IDE(EGO) için ambar mimarisi
İstemci-sunucu deseni
Film kütüphanesi için istemci/sunucu mimarisi

Chapter 6 Architectural design 18

Boru ve süzgeç deseni
Boru ve süzgeç mimarisi örneği

Chapter 6 Architectural design 20

 UYGULAMA MİMARİLERİ

Uygulama sistemleri iş dünyasına ilişkin veya kurumsal bir ihtiyacı karşılamayı amaçlarlar. Tüm işlerin ortak bazı yönleri vardır; insanları işe
alırlar, fatura keserler, hesap tutarlar vs. Aynı sektörde faaliyet gösteren meslekler ortak sektöre özel uygulamaları kullanırlar.

Dolayısıyla tüm telefon şirketleri genel iş fonksiyonlarının yanı sıra çağrıları bağlayan ve ölçen, ağı yöneten ve abonelerine fatura çıkaran
sistemlere ihtiyaç duyarlar. Sonuç olarak bu işlerde kullanılan uygulama sistemlerinin de birçok ortak yanı vardır.

Bu ortaklıklar belirli tipteki yazılım sisteminin yapısını ve organizasyonunu betimleyen yazılım mimarilerinin geliştirilmesine öncülük
etmiştir. Uygulama mimarileri belirli bir sistem sınıfının esas özelliklerini paketler.

Hareket işleme uygulamalarının yapısı

 Hareket İşleme Sistemleri

Hareket işleme sistemleri bir veri tabanından bilgi taleplerini veya veri tabanı üzerinde güncelleme taleplerini işlemek üzere tasarlanmış
sistemlerdir. Kullanıcı perspektifinden bir hareketi, belirli bir amacı, örneğin “Londra’dan Paris’e uçuşların zamanlarını bulmak” gibi bir
amacı sağlayan tutarlı bir işlemler dizisidir.

Kullanıcı hareketi veri tabanının değiştirilmesini gerektirmedikçe bunu teknik olarak bir veri tabanı hareketi olarak paketlemek
gerekmeyebilir. Bir kullanıcı hareketinin gerçek bir örneği bir müşterinin ATM aracılığıyla hesabından para çekme talebidir.
Bir ATM sisteminin yazılım mimarisi
 Bilgi Sistemleri

• Paylaşılan bir veri tabanı ile etkileşimi gerektiren bütün sistemler

hareket tabanlı bilgi sistemleri olarak görülebilirler.

• Bir bilgi sistemi; bir kütüphane kataloğu, bir uçuş tarifesi veya bir
hastanedeki hasta kayıtları gibi büyük bir bilgi tabanına kontrollü
bir biçimde erişilmesine izin verir.

• Bilgi sistemleri hemen her zaman kullanıcı arayüzünün bir Web

tarayıcısı olarak gerçekleştirildiği Web tabanlı sistemlerdir. Şekil
6.18 bir bilgi sisteminin çok genel bir modelidir.

Katmanlı bilgi sistemi mimarisi

 Dil İşleme Sistemleri

Dil işleme sistemleri bir dili alternatif bir gösterim biçimine çevirir ve programlama dilleri söz konusu ise aynı zamanda sonuçta oluşan kodu
çalıştırabilir de. Derleyiciler bir programlama dilini makine koduna çevirirler.

Diğer dil işleme sistemleri XML veri gösterimini bir veri tabanını sorgulayan komutlara veya alternatif bir XML temsiline çevirebilir. Doğal dil
işleme sistemleri bir doğal dili diğerine çevirebilir; örneğin Fransızcayı Norveçceye.

Şekil 6.20’de bir programlama dili için bir dil işleme sistemine ait mümkün olan bir mimari gösterilmiştir. Kaynak dil komutları çalıştırılacak
olan programı tanımlar ve bir çevirmen bunları soyut bir makinenin komutlarına çevirir.
Bir dil işleme sisteminin mimarisi
Bir dil işleme sistemi için bir ambar mimarisi
 İÇİNDEKİLER

BÖLÜM 7: TASARIM VE GERÇEKLEŞTİRME

UML KULLANARAK NESNE YÖNELİMLİ TASARIM

- Sistem Bağlamı ve Etkileşimler

- Mimari Tasarım

- Nesne Sınıfı Belirleme

TASARIM DESENLERİ

GERÇEKLEŞTİRİM KONULARI

AÇIK KAYNAK GELİŞTİRME

 7.BÖLÜM
TASARIM VE GERÇEKLEŞTİRME
 UML KULLANARAK NESNE YÖNELİMLİ TASARIM

Bir nesne yönelimli sistem kendi yerel durumlarını koruyan ve bu durumlar üzerinde operasyonlar sağlayan karşılıklı etkileşen nesnelerden
oluşmaktadır. Durumun gösterimi özeldir ve nesnenin dışından doğrudan erişilemez.

Nesne yönelimli tasarım süreçleri nesnelerin sınıflarının ve bu sınıflar arasındaki ilişkilerin tasarımını içermektedir. Bu sınıflar sistemdeki
nesneleri ve onların aralarındaki etkileşimleri tanımlamaktadır.

Tasarım çalışan bir program olarak gerçekleştirildiği zaman nesneler bu sınıf tanımlamalarından dinamik olarak yaratılmaktadır. Nesneler
hem veri hem de bu veriyi işlemek için operasyonlar içermektedir. Nesneler bu nedenle bağımsız varlıklar olarak anlaşılabilir ve
değiştirilebilirler.
Bir Sistem Tasarımını Kavramdan Detaylı Nesne Yönelimli Bir Tasarım Haline Geliştirmek İçin Aşağıdakileri Yapmanız Gerekmektedir:

1. Bağlamı ve sistem ile olan dış etkileşimleri anlamalı ve tanımlamalı.

2. Sistem mimarisini tasarlamalı.

3. Sistemdeki başlıca nesneleri belirlemeli.

4. Tasarım modelleri geliştirmeli.

5. Arayüzler belirlenmeli.
Hava durumu istasyonu için sistem bağlamı
 Sistem Bağlamı ve Etkileşimler

Sistemin sınırlarını belirlemek, size hangi özelliklerin tasarlanmakta olan sistemde gerçekleştirileceği ve hangi özelliklerin diğer bağlantılı
sistemlerde olduğu hakkında karar vermenize yardımcı olacaktır. Bu durumda, fonksiyonelliğin tüm hava durumu istasyonlarına ilişkin
kontrol sistemi ile hava durumu istasyonu içindeki gömülü yazılım arasında nasıl dağıtılacağına karar vermeniz gerekmektedir.

Sistem bağlam modelleri ve etkileşim modelleri, bir sistem ile onun ortamı arasındaki ilişkilere ait birbirini tümleyen görünümler
sunmaktadır:

1. Bir sistem bağlam modeli, geliştirilmekte olan sistemin ortamında yer alan diğer sistemleri gösteren yapısal bir modeldir.

2. Bir etkileşim modeli, sistemin kullanımı sırasında ortamı ile nasıl etkileşimde bulunduğunu gösteren dinamik bir modeldir.
Kullanım durumu tanımı- Hava durumu raporla
Hava durumu istasyonu kullanım durumları
 Mimari Tasarım

Yazılım sistemi ile bu sistemin ortamı arasındaki etkileşimler bir kez tanımlandıktan sonra, bu bilgiyi sistem mimarisini tasarlamak için temel
olarak kullanırsınız. Şüphesiz ki, bu bilgiyi mimari tasarım prensipleri hakkındaki temel bilginizle ve daha ayrıntılı alan bilgisi ile
birleştirmeniz gerekir. Sistemi oluşturan ana bileşenleri ve aralarındaki etkileşimleri belirledikten sonra, sistem organizasyonunu katmanlı
veya istemci/sunucu model gibi bir mimari desen kullanarak tasarlayabilirsiniz.

Hava durumu istasyonunun

üst düzey mimarisi
 Nesne Sınıfı Belirleme

Nesne yönelimli tasarımın gelişmeye başladığı 1980’lerden beri, nesne yönelimli sistemlerdeki nesne sınıflarının belirlenmesi için çeşitli
yollar önerilmiştir:

1. Geliştirilecek sistemin doğal dille yapılmış tanımının bir dilbilgisel analizinin kullanılması. Nesneler ve öz nitelikler isimler iken, fiiller
operasyon ve servislerdir.

2. Hava taşıtı gibi uygulama alanında yer alan somut varlıkların, müdür gibi rollerin, istek gibi olayların, toplantılar gibi etkileşimlerin,
ofisler gibi lokasyonların, firmalar gibi organizasyonel birimlerin ve vb. kullanılması.

3. Sistemin kullanımına ilişkin çeşitli senaryoların sırayla belirlendiği ve analiz edildiği senaryo tabanlı analiz kullanımı. Her senaryo analiz
edildikçe, analizden sorumlu olan takım gerekli nesneler, öz nitelikler ve operasyonları belirlemelidir.
Hava durumu istasyonu nesneleri
Veri toplanmasını tanımlayan sıra diyagramı
 TASARIM DESENLERİ

Tasarım desenleri, bina tasarımının özü itibariyle hoşa giden ve etkin ortak desenleri olduğunu öneren Christopher Alexander tarafından
ortaya konan fikirlerden türetilmiştir. Desen, çözümün farklı ortamlarda yeniden kullanılabilmesi için yapılan bir problem tanımı ve
çözümünün özüdür. Desen ayrıntılı bir spesifikasyon değildir. Aksine, deseni biriktirilmiş bir bilgelik ve deneyim ve ortak bir problem için
denenmiş bir çözüm olarak düşünebilirsiniz.

Desenler hakkında bilgi sağlamaya adanmış Hillside Grubu web sitesinden (hillside. net/patterns/) bir alıntı, desenlerin yeniden
kullanımdaki rolünü aşağıdaki gibi özetlemektedir:

“ Desenler ve desen dilleri en iyi pratikleri, iyi tasarımları tanımlamanın yollarıdır ve deneyimi diğer kişilerin bu deneyimi yeniden
kullanabileceği şekilde yansıtmaktadır.”
Gözlemci desenine ilişkin bir UML modeli
 GERÇEKLEŞTİRİM KONULARI

Yazılım mühendisliği, yazılım geliştirmede sistemin ilk gereksinimlerinin alınmasından konuşlandırılan sistemin bakım ve yönetimine kadar
yer alan tüm etkinlikleri içermektedir.

Bu sürecin önemli bir aşaması şüphesiz ki yazılımın çalıştırılabilir bir sürümünü oluşturduğunuz gerçekleştirim aşamasıdır. Gerçekleştirim,
üst veya alt düzey programlama dilleri ile programlar geliştirme veya hazır sistemleri organizasyonun gereksinimlerini karşılamak için uygun
hale getirme ve uyarlamayı içermektedir.
Yazılım yeniden kullanımı
Yapılandırma yönetimi
Konakçı hedef geliştirme
 AÇIK KAYNAK GELİŞTİRME

• Açık kaynak geliştirme, bir yazılım sisteminin kaynak kodunun yayınlandığı ve gönüllülerin geliştirme sürecine katılım için davet
edildikleri yazılım geliştirme yaklaşımıdır.

• Kökleri, kaynak kodların kişilerin özel mülkiyeti değil de diledikleri zaman denetlemeleri ve değiştirebilmeleri için kullanıcılara her
zaman açık olması gerektiğini savunan açık yazılım kuruluşuna (Free Software Foundation) (www.fsf.org) dayanmaktadır.

• Kodun kullanıcılarından ziyade küçük bir çekirdek grup tarafından kontrol edilip, geliştirileceği varsayımı bulunmaktaydı. Açık kaynak
yazılımlar, bu düşünceyi daha geniş bir gönüllü geliştiriciler topluluğunu bir araya toplamak için İnternet’i kullanmak yoluyla
genişletmiştir.

• Bu geliştiricilerin bir çoğu aynı zamanda kodun kullanıcılarıdır. Prensip olarak, açık kaynaklı projeye katkı veren herhangi bir kişi en
azından hataları raporlayabilir, düzeltebilir ve yeni özellikler ve fonksiyonellikler önerebilir.