 

Tekirdağ Namık Kemal Üniversitesi Çorlu Mühendislik Fakültesi Yazılım Mühendisliği Dr. Rabia KORKMAZ TAN
Ders Kaynakları :
1. Yazılım Mühendisliği, Ian Sommerville, 10. Basımdan
Çeviri. Çeviri Editörü, Prof. Dr. N. Yasemin Topaloğlu
2. Software Engineering, Ian Sommerville, 9th edition,
Addison-Wesley
3. Software Engineering – A Practitioner–
s Approach, Roger S.
Pressman.
4. Ders Notları

Değerlendirme
 %30 vize %20 Proje %50 Final

2
■ Yazılım Mühendisliği
► Tanımlar, tarihçe, kapsam
 Bilgisayar programları ile bunlarla ilişkili yapılandırma ve
belgelerin bütünüdür.
► Genel yazılım
• Özellikleri pazardaki genel ihtiyaca göre belirlenerek geliştirilir.
• “Generic software”, “commercial-off-the-shelf (COTS) software”
• Örnek: MS Office yazılımı
► Müşteriye özel yazılım
• Özellikleri belirli bir müşterinin ihtiyacına göre belirlenerek geliştirilir.
• “Custom software”
• Örnek: Hava trafiği kontrol yazılımı

İhtiyaç

Yazılım
 Software
 Günümüz bilgisayar teknolojileri iki temel teoriye
dayanır
 Von-Neumann
 Turing Makineleri
 Yazılımı talep eden kişiyi doğru anlamak
İsteklerin zaman içinde değişebileceğinin farkında
olmak
 Problemlerin ve yeni eklentilerin yönetimini
yapabilmek
 Maliyeti düşürebilmek
 Yazılım ekibini doğru şekilde kurabilmek
Kullanılacak donanımı belirlemek
 Eskiden “yazılım geliştirme yaşam döngüsü” Şimdi
“sistem geliştirme”
 Analiz, Kod, Raporlama, Test …

 Yazılım denince sadece kod değil tüm sistem

anlaşılmalıdır
■ 1940’lar:
► Elle yazılan basit makine kodları
■ 1950’ler:
► Üretkenlik ve kaliteyi arttırmak için yazılan makro birleştiriciler ve yorumlayıcılar
► İlk kuşak derleyiciler
■ 1960’lar:
► Üretkenlik ve kaliteyi arttırmak için yazılan ikinci kuşak derleyiciler
► Yazılım Mühendisliği NATO Konferansı, 1968: “Yazılım mühendisliği” kavramının
tartışılması
► İlk büyük yazılım projeleri (1000 programcı)
► Büyük iş alanları için ana-bilgisayarlar ve ticari yazılımlar
■ 1970’ler:
► UNIX ve kod kütüphaneleri için araçlar
► Mini-bilgisayarlar ve küçük iş alanları için yazılımlar
■ 1980’ler:
► Kişisel bilgisayarlar ve iş istasyonları
► Ticari yazılımlar
■ 1990’lar:
► Avuç-içi bilgisayarlar ve web teknolojileri
► Teknolojideki gelişmeler sebebiyle düşen fiyatlar ve karmaşıklaşan iş talepleri
■ 2000’ler:
► Globalleşme sebebiyle artan talepler
► Bütünleşik geliştirme ortamları
■ 1960’lardan itibaren yazılım ürünlerine artan talepler karşısında otomasyonu da
içeren değişik çözümler uygulandıysa da yeterli üretim kapasitesine erişilemedi. Bu
yetersizlik, “yazılım krizi” söylemiyle dünya literatüründe yerini aldı.

■ Yazılım krizinin temel sebebi, üstel olarak artan talebe karşılık doğrusal hızla artış
gösteren üretim kapasitesidir. Diğer yandan yazılım projelerindeki başarısızlık oranı
da şaşırtıcı derecede yüksek olup bu krizi beslemektedir.

a: başarılı

b: büyük miktarda
değişikliklerden sonra
kullanılabilen

c: çok büyük
değişikliklerden sonra
kısmen kullanılabilen

d: parası ödendiği halde

kullanılamayan

Yazılım ürününe arz ve talep artışları Toplam maliyete göre yazılım başarısı
■ Yazılım ürünlerine olan talep ve yazılım ürünlerinden beklentiler
çok hızlı artıyor
► Boeing 777
• A.B.D. ve Japonya’da 1700 iş istasyonu
• 4,000,000 Kod Satırı
• “Kanatları olan yazılım”

► Beyaz eşyalar, cep telefonları, otomobiller

► Akıllı ev ve ofis sistemleri

►…
■ Denver havaalanı • Açılış 2 yıl gecikti
otomatik bagaj sistemi • $27 milyon maliyet aşımı
• $360 milyon gecikme maliyeti

■ Hava trafik kontrol (FAA • $5.6 milyar maliyet aşımı

• 8 yıl gecikme
modernizasyon) • 4 sistemden 2 tanesi iptal edildi, üçüncü
sistemin gereksinimlerinin %52’si karşılandı

■ Comanche • 10 yılda maliyeti 10 kat arttı, $34.4 milyon

Helikopteri • Gereksinimleri %74 azaltıldı
Kestirim
(C Satır) Önce Zamanında Gecikme İptal

13.000 6.06% 74.77% 11.83% 7.33%

130.000 1.24% 60.76% 17.67% 20.33%

1.300.000 0.14% 28.03% 23.83% 48.00% Referans:

“Patterns of
Software
Failure and
13.000.000 0.0% 13.67% 21.33% 65.00% Success”,
C. Jones

Büyük kapsamlı yazılım ürünleri için, mühendislik yaklaşımı zorunlu hale

gelmiştir!
■ Yazılım üretiminin tüm etkinliklerini kapsayan mühendislik disiplinidir.
► Sistem tanımlama gibi erken aşamalardan sistemin kullanımı
esnasındaki bakımına kadar uzanan etkinlikleri kapsar.
► Sadece teknik etkinlikleri değil, aynı zamanda yönetim etkinliklerini de
içerir.

İhtiyaç Yazılım
Mühendisliği
Yazılım
■ Yazılım Mühendisliği; yazılım ürününün geliştirilmesi, işletilmesi ve
bakımı için uygulanan; sistematik, disiplinli ve ölçülebilir yaklaşımdır.
[IEEE, 1990]

► Mühendislik, herhangi bir bilim alanındaki bilgi birikimini sistematik

olarak pratiğe geçirmeyi hedefler; bilimi ve matematiği kullanır.
• Yönetim parametreleri: İşlev, maliyet, zaman
• Kalite parametreleri: Dayanıklılık, bakım kolaylığı, güvenlik, kullanım kolaylığı, vb.

► Tekrarlanabilir başarılar için mühendislik yaklaşımı şarttır.

• Mühendislik öğretisi ile bir yöntem uygulandığında, benzer sonuçları her
zaman elde etme güvenliği vardır.
■ Yazılım Gereksinim Analizi
■ Yazılım Tasarım Yazılım
■ Yazılım Gerçekleştirme Programlama Geliştirme
Kapsamı
■ Yazılım Test
■ Yazılım Bakım
■ Yazılım Mühendislik Yönetimi
■ Yazılım Konfigürasyon Yönetimi
■ Yazılım Mühendisliği Süreçleri
■ Yazılım Mühendisliği Araç ve Yöntemleri
■ Yazılım Kalitesi
[“Guide to the Software Engineering Body of Knowledge”, 2004]
 Computer-Aided Software Engineering
 Yazılım mühendisliği işleri yapmaya yarayan
yazılımlar, başka bir deyişle bir yazılım projesini
yönetmeye yarayan yazılımlar
 Zaman çizelgesi
 İş dağıtımı
 Süreç tasarımı
 Bakış açısına bağlı
 Yazılım mühendisliği açısından
 Kullanıcı dostu (adaptasyon ve kullanım kolaylığı)
 Windows start butonu
 İnsanların varlık gösterebildiği projeler
 İnsanla uğraşıyor olmak
 Doküman yazmak
 Yazılım ekibine yeni katılanlar, ayrılanlar
 Yazılımın türü
 Generic
 Çok kapsamlı sektör araştırması
 Kişiye özel
 Bir önceki sistem Donanım farklılıkları İşletim sistemi
farklılıkları Etik problemler
 Yazılımın oluşturulmasından, kullanım süreci ve
sonrasına kadar olan zamanı kapsayan bir zaman dilimi
 Şelale Modeli (Waterfall)
 Sistem özelliklerinin ve taleplerin belirlenmesi
 Geliştirme
 Geliştirilen yazılımın sistem özelliklerine ve
taleplere uygunluğunun kontrolü
 Evrim
 Modelin olumsuz yönleri
 Bilgisayar dünyasına uygun değil
 İstekleri ve değişimleri etkin bir şekilde yönetemez
 Agile gibi metodolojiler bilgisayar dünyasına daha
uygun
Yazılım ürünü, müşterinin beklediği işlevsellik ve performansın yanı sıra,
aşağıdaki özellikleri de taşımalıdır.

 Bakım-yapılabilirlik (“maintainability”)
 Yazılım, değişen ihtiyaçlara göre değişebilir olmalıdır.

 Güvenilirlik (“dependability”)
 Yazılım, güvenilir olmalıdır.

 Etkinlik (“efficiency”)
 Yazılım, sistem kaynaklarının israfına sebep olmamalıdır.

 Kabul-edilebilirlik (“acceptability”)
 Yazılım, kullanıcıları tarafından kabul edilebilmelidir.
(Diğer bir deyişle; anlaşılabilir ve kullanılabilir olmalı, diğer sistemlerle uyumlu çalışabilmelidir.)
 Yazılım nasıl daha iyi olabilir? Farklı bakış açıları var.

CS SE
Matematik Yönetim

CE
Fizik
 Bilgisayar Bilimleri; bilgisayar ve yazılım sistemlerinin
temelinde yatan teoriler ve yöntemlerle ilgilenir.
► Algoritmalar ve veri yapıları, programlama dilleri, mimari, bilimsel hesaplama,
işletim sistemleri, bilgi ve veri yönetimi, grafik görüntüleme ve çoklu-ortam,
bilgisayar ağları, akıllı sistemler, vb.
(Fizik bilimlerinin, Elektrik ve Elektronik Mühendisliğinin temelinde yattığı gibi)

 Yazılım Mühendisliği; yazılım üretmenin pratik

problemleriyle ilgilenir.
► Bunu yaparken Bilgisayar Bilimlerinin sunduğu kavramsal altyapıyı kullanır.
► Bir yazılım mühendisinin, ilişkili uygulama alanına göre (örneğin veri-işleme,
animasyon, vb.), altta yatan bilgisayar bilimine hakim olması zorunludur.
■ Sistem Mühendisliği; yazılımın önemli rol oynadığı, karmaşık bilgisayar
sistemlerinin geliştirilmesi ve idamesi ile ilgilenir.
► Örnek: ATM sistemi
► Sistem Mühendisliği; sistemin genel çatısıyla ilgilidir.
• Sistemin kullanılacağı alana ilişkin süreçlerin analiz edilmesi, sistem
gereksinimlerinin tanımlanması, sistem mimarisinin oluşturulması, sistem
bileşenlerinin tümleştirilmesi gibi aşamaları içerir.
► Söz konusu bilgisayar sistemi; donanım, ağ, yazılım bileşenlerinden oluşur. Sistem
Mühendisliği, bileşenlere ilişkin mühendislik etkinliklerinin detaylarıyla pek
ilgilenmez.
• Bu tür sistemler için Yazılım Mühendisliği (kapsamındaki tüm etkinliklerle birlikte), Sistem
Mühendisliği altında ve onun bir parçası olarak uygulanır.
► Sistem Mühendisliği, Yazılım Mühendisliğine kıyasla çok daha eski bir
mühendislik disiplinidir.
■ Donanım mühendislikleri ile yazılım mühendisliğinin en belirgin
farkı ürünlerindedir.
► Yazılım ürünü diğer mühendislik ürünlerine oranla daha soyuttur.
► Yazılım projesi geliştirme ile sonlanırken donanım projelerinde ek
olarak imalat safhası vardır.
► Seri üretim, yazılım geliştirme içerisinde neredeyse hiçten ibarettir.
► Donanım ürünleri kullanıldıkça aşınır; yazılım ürünlerinde ise aşınma
olmaz. Yalnızca baştan beri gizli bulunan hatalar, yazılım kullanıldıkça
ortaya çıkar.

■ Donanım mühendisliklerinde maliyet odağı seri üretim ve

yıpranmayken, yazılım mühendisliğinde maliyet odağı geliştirmedir.
■ Kabaca söylersek, yazılım maliyetinin;
%60 : Geliştirme maliyeti,
%40 : Test maliyetidir (test maliyetine bulunan hataları düzeltmenin
maliyeti de dahildir.)

■ Müşteriye özel üretilen yazılımlar için idame (bakım) maliyeti, geliştirme

maliyetinin birkaç katına çıkmaktadır.
■ Heterojenlik (“heterogeneity”)
► Yazılım geliştirme için, heterojen platformları ve çalıştırma
ortamlarını destekleyecek teknikler geliştirmek

■ Teslim (“delivery”)
► Yazılımın zamanında teslimi için teknikler geliştirmek

■ Güven (“trust”)
► Yazılımın kullanıcıları tarafından güvenilebileceğini gösteren
teknikler geliştirmek
■ Yazılım mühendisliği, teknik yetkinliğin uygulanmasının
yanında, aşağıdaki konularda sorumluluk gerektirir:

► Gizlilik
• Örnek: Çalışanların ve müşterilerin gizlilik haklarına saygı göstermek

► Rekabet
• Örnek: Kendi yetkinliğiniz dışında iş kabul etmemek

► Özlük hakları
• Örnek: Patent, mülkiyet, vb. haklarına dikkat etmek

► Bilgisayarın amaç-dışı kullanımı

• Örnek: Başkasına ait bir makinede oyun oynayarak virüs
bulaştırmamak
■ Sektörde çalışanların yaklaşık yarısı “Bilgisayar Mühendisliği”
lisans eğitimine sahip
► Alana göre farklılık gösteren lisans dereceleri var
• Örneğin; Yönetim Bilgi Sistemleri uygulamaları için İşletme lisansı,
gömülü uygulamalar için Elektrik ve Elektronik Mühendisliği lisansı

■ Yazılım mühendisliği geniş kesimlerce bir meslek olarak

algılanmakta

■ Üniversitelerin Yazılım Mühendisliği lisans ve yüksek

lisans programları var
 Software Engineering, Ian Sommerville, 9th edition, Addison-Wesley
 http://web.firat.edu.tr/mbaykara/yazilimmuhendisligi.html

29
 
 Sistem geliştirmede nesneye yönelik yaklaşım,
Tümleştirilmiş Modelleme Dilinin (UML: Unified Modeling
Language) standartlaştırılmasıyla 1990’larda
yaygınlaşmaya başlamıştır. Klasik yaklaşımın tersine, veri
merkezli, sınıf modelleri üzerinde gerçekleştirilen bir
yaklaşımdır.

2
Nesneye yönelik analiz ve tasarım yöntemleri kullanıldığında;
 Kodların ve modüllerin yeniden kullanılabilirliği kolaylaşır,
 Geliştirme süresi kısalır,
 Üretkenlik artar,
 Yazılım kalitesi yükselir,
 Anlaşılabilirlik kolaylaşır.

3
Nesneye yönelik yaklaşım ile;
 Yazılım geliştirilirken çeşitli süreç modelleri uygulanabilir.
 Kabul görülen en iyi özellikler bir araya getirilerek, modelin
yapısına uygun birleşik (tümleştirilmiş) yazılım süreci
(Unified process:UP) ortaya atılmıştır.
 UP, tekrarlı ve artımlı bir süreç yapısı çizer,
 Tek bir model, analiz, tasarım, gerçekleştirme ve test
aşamalarında sürekli işlenir, değiştirilebilir ve iyileştirilebilir.

4
 Geleneksel yazılım geliştirme metotlarının eksikliklerini
mümkün olduğunca azaltan nesneye yönelik yaklaşım,
birkaç yeni problemi de beraberinde getirmiştir.
 Sistemin gerektirdiği çözüm ilişkisel bir veritabanı
kullanımı gerektiriyorsa, kavram ve uygulama arasında
belirgin farklar oluşur.
 Süreç içinde aşamaları birbirinden kesin olarak ayırmak
zordur.
 Bu da yazılım ölçümlerinin yapılabilmesini zorlaştırır.
 Ancak projenin küçük parçalara bölünerek yönetilmesi ve
yinelemeli-artımlı süreç bu problemi çözmeye yarar.

5
 Nesneye yönelik sistem analizi ve tasarımda UML bir
standart olarak yaygın kullanılmaktadır.
 UML,bir yöntem değil,modelleme dilidir.
 UML ile tasarım anlaşılır bir biçimde ortaya koyulabilir.
 Notasyon, ağırlıklı olarak çizimlerden oluşur.

6
• Bir kullanıcı için önemli olan sistemin nasıl
geliştiğinden çok, doğru çalışması ve istediği işi
yapmasıdır.
• Zamanla değişen istekler karşısında gerekli
değişikleri ve yenilikleri kolayca yapabilmenin yolu
sistemin daha tasarım aşamasında iyi
tanımlanmasıdır.
• Ayrıca analiz ve tasarım sırasında çizilen UML
diyagramları ile sistemin resmi çizilerek, müşteri ile
etkileşim içinde, projenin doğru yönde ilerlemesi
sağlanır.
7
 Gerçek dünyada nesneler, belli sorumlulukları yerine getiren
varlıklardır.
 Yazılımda ise değişik hizmetler veren ve özellikleri olan bir
varlık olarak düşünülebilir.
 Programcı gözüyle bakıldığında ise nesne, veri ve
fonksiyondan oluşan bir modülden başka bir şey değildir.

8
 Bilgisistemi geliştirmenin amacı, bir problemi
çözmektir.
 Nesneye yönelik yaklaşımda problemi oluşturan
nesneler, gerçekteki yapılarına benzer olarak
modellenir ve modellenen nesnelerin de özellikleri
ve davranışları olur.
 Gerçek hayattan bir örnek verirsek;
o Bahçemizdeki ağaç bir nesnedir.
o Yaprak türü, gövde uzunluğu, meyveleri, çiçekleri nesnemizin
özellikleri,
o Ağacın büyüyerek çiçek açması yaprak ve meyve vermesi de ağacın
davranışlarıdır.

9
 Nesneler birbirlerinden kimlik bilgileri ile ayrılırlar.
 Örneğin; aynı yemek takımına ait iki tabak tıpatıp
aynı gibi gözükse de üretim sırasında farklı seri
numaraları verildiyse farklı seri numaralarına sahip
farklı iki tabak olurlar.
 Nesneye yönelik yaklaşımın hedefi, gerçek hayatta
nesnelerin sahip olduğu durum, davranış, kimlik
gibi özellikleri örnekleme ve modellemeye
çalışmaktır

10
Yapısal UML Diyagramları
1. Sınıf Diyagramı (Class Diagram)
2. Bileşen Diyagramı ( Component Diagram)
3. Birleşik Yapı Diyagramı (Composite Structure Diagram)
4. Nesne Diyagramı (Object Diagram)
5. Paket Diyagramı (Package Diagram)
6. Yerleştirme Diyagramı (Deployment Diagram)
UML’in Davranış Diyagramları
1. Kullanım Senaryosu Diyagramı (Use-Case Diagram)
2. Faaliyet Diyagramı (Activity Diagram)
3. Durum Diyagramı (State Machine Diagram)
4. Etkileşim Diyagramları
1. Ardışıklık Diyagramı (Sequence Diagram)
2. Zamanlama Diyagramı (Timing Diagram)
3. Etkileşime Bakış Diyagramı (Interaction Overview Diagram)
4. İletişim Diyagramı (Communication (Collaboration) Diagram)11
 Aktör (Actor); Sistemin kullanıcılarını tanımlamak için kullanılır. Bir
insan, bir başka sistem veya bir cihaz olabilir.
 Kullanım Senaryosu (Use Case); sistemdeki aktörler için, belirli bir
sonuç değerini oluşturan, bir dizi eylem bütünüdür. İşlevsel
isteklerin anlaşılmasına yardımcı olan bir yöntemdir.
 Yapısal Elemanlar (Structural Elements); sistemde bulunan
yapıtaşlarını, yani sınıfları, nesneleri ve paketleri içeren statik
kısımlardır.
 Davranışsal Elemanlar (Behavioral Elements); kullanılan eylem
sözcükleri yardımıyla yazılım modelinin dinamik kısımlarını
tanımlar.
 Gruplama Elemanları (Grouping Elements); diğer adıyla paketler,
yazılım elemanlarını gruplamak amacıyla kullanılırlar. Paketlerin
içinde sınıflar, arayüzler, diyagramlar, hatta başka paketler
bulunabilir.
12
 Nesne (Object); yazılım modeli içindeki belirli ve sonlu sayıda
olan sistem elemanlarıdır. Nesnelerin karakterleri ve bu
karakterlerin üzerinde duran davranışları vardır. Nesneler bu
yapılarıyla (karakter, davranış) sistem üzerinde kendilerine
verilen görevi yerine getirirler.
 Sınıf (Class); nesnelerin sistem içerisinde oynadıkları rolü,
yani nesnelerin öznitelikleri ile iş yapan metotlarını kapsayan
yapılarını belirlerler. Sınıflar nesneler için bir kalıp görevi
görürler. Sistem içerisinde nesneler, bu kalıba göre
oluşturulurlar, belirli etkinlikleri yerine getirirler ve sonlanırlar.
Sınıflar, bir yandan varlıkların belirli özellikleri ve
davranışlarına odaklanarak soyutlama sağlarken diğer
yandan varlıkların bazı özelliklerini ve davranışlarını kapsayıp
dış dünyadan gizleyerek karmaşıklığı azaltırlar.
13
 Aktif Sınıf (Active Class); kendi başlarına var olabilen,
uygulamanın akışını kontrol edebilen nesneleri tanımlarlar.
 Arayüz (Interface); nesnelerin davranışlarını belirleyen
kurallar bütünü olarak düşünülebilir. Sınıflar, davranışları
belirleyen arayüz yordamlarını gerçekleştirirler.
 İşbirliği (Collaboration); belirli bir amaca yönelik kullanım
senaryolarının birleştirilmiş halidir.
 Bileşenler (Component); yazılım gereksinimlerinin belirli
kısımlarını gerçekleştiren modüllerdir.
 Düğüm (Node); sisteme hesaplanabilir ve ölçülebilir
durumda olan bir kaynak sunan fiziksel elemanlar.

14
 Sınıf, aynı özellik ve işlemlere sahip nesne kümesi için bir
tanımlayıcıdır. Nesnelerin oluşturulması için şablon olarak
da düşünülebilir.

15
 Sınıf Adı
Özellikler

İşlemler():

16
 Özellik bir tip-değer çiftidir. Sınıflarda özelliklerin tip
tanımları yapılır, nesnelerde ise bu özellikler değer taşırlar.

17
Özellik isimleri ve tiplerinin belirtildiği gösterim örnekleri;

Mimar Yapı
Ad: String Ad: String
Soyad: String Yer: String
Doğum Tarih: Date Yapım Tarihi: Date
Ölüm Tarihi: Date Yapan: Mimar

 Bir sınıfın özellikleri yalnızca basit veri tiplerinden oluşabileceği

gibi başka sınıftan tanımlanmış nesnelerde olabilir. Örneğin
“Mimar” sınıfı basit veri tiplerine sahipken, ”Yapı” sınıfının
“Yapan” adlı özelliği “Mimar” sınıfı tipindedir. Sınıflar
arasındaki bu ilişki, ”sahip olma” (has a) ilişkisi olarak 18
adlandırılır.
 Nesneler, birbirleriyle mesajlar yoluyla haberleşirler.
o Mesaj, sınıfta tanımlı bir işlemin harekete geçirilmesini
sağlar.
o Bir nesneyi kullanmak için iç yapısının bilinmesi gerekli
değildir ancak nesnenin dışarıya sunduğu hizmetlerin
nasıl kullanılacağının bilinmesi gerekir.
 Nesnenin özelliklerine direk erişim yapılmaması veri tutarlılığı
açısından önemlidir. Bunu sağlamak için sınıflar yazılırken
bazı üyeler gizlenir, dışarıdan erişimleri engellenir.

19
Bir sınıfın üyelerine erişim için üç etiket kullanılmaktadır.
Bunlar;
 Public (açık): Üyeler diğer nesnelerin kullanımına
açıktır. UML’de üyenin başına konulan “+” işareti ile
gösterilir.
 Private (özel): Üyeler sadece o sınıfın nesneleri
tarafından kullanılabilir. UML gösterimi “-” işaretidir.
 Protected (korumalı): Üyeler sadece o sınıfın nesneleri
ve alt sınıflarından türeyen nesneler tarafından
erişilebilir. UML gösterimi ise “#” işaretidir.

20
 Nesne, bilgi saklayan özelliklerinin yanı sıra bu özellikler
üzerinde işlem yapmaya yardımcı olan işlemleri de içerir.
 Bir işlemi gerçekleştirilen yordama ise, “metot” denir.
 Metotlar; kendisiyle aynı isimde olan mesajla aktif hale gelir,
bu mesajda metodun sahip olduğu parametrelerin alacağı
değerler de yer alır.

21
İşlemler nesnelerin birlikte çalışmasını sağlarlar
Yığın Liste

- içerik: Liste
+ add():
+ push(): + remove():
+ pop(): + first():
+ last():
 Bir işi gerçekleştirmek için, birçok nesne aralarında
mesajlaşarak işbirliği yaparlar. Yukarıda “Yığın”
sınıfı,”push()” işlemini yapabilmek için “Liste” sınıfının
“add()” hizmetinden yararlanır. 22
 İşlemlerin görülebilirliği de özelliklerin görülebilirliği ile aynı
esaslara dayanır.
 Nesne yönelimli bir programda dış dünyaya hizmet eden ve
haberleşen metotlar açık görünürlüğe sahip, sınıfın kendi iç
yapısında kullandığı işlemler ise özel görünürlüğe sahip olup
dışarıdan erişilemezler.

23
Statik = Sınıf Diyagramları (Class Diagram)

24
Public id : Integer = 0
Private mKod : HashTable

Private MoveLastRecord() : DataRow

25
 Nesneye yönelik bir uygulamanın analiz aşaması, temel
olarak sınıfların ve sınıflar arasındaki ilişkilerin belirlenmesi
esasına dayanır.

26
 Bağlantı, sınıflar arası ilişkilerin bir çeşididir.
 Sınıflardan türeyen nesneler arasında hizmet alışverişini
sağlar.
 Birbirleriyle haberleşecek nesneler bu bağlantıyı kullanırlar.
 Bağlantılarda genellikle iki sınıf yer alır; ancak tek sınıf da
kendi üzerinde bağlantıya sahip olabilir.

27
 Satış
Satış kalemi
Tarih: Date
miktar: int i..*
Kasiyer: Çalışan

 n1...n2 arası değişen tamsayılarla gösterilen çoğullama

sayısı, kaynak sınıfın bir nesnesiyle hedef sınıfın kaç
nesnesinin ilişkilendirilebileceğini gösterir.
 Sayısı kestirilemeyecek kadar çok çoğullama varsa, bu
sayı yerine “*” işareti kullanılır.
28
29
30
1 1 adet
* Belirsiz çokluk
0.. 1 Var ya da yok
1.. * 1 tane ya da sonsuz sayıda
m.. n 2 değer arasında
0.. * Hiç yok ya da sonsuz sayıda

31
32
 Kümeleme ve birleştirme, sınıflar arasındaki parça-bütün
ilişkileridir.
 Kümelemede (Aggregation) alt parçalar, sadece o sınıfa ait
üyeler değildir, kendi başlarına da kullanılabilirler. UML
diyagramlarında bağlantı çizgisinin ucuna içi boş bir dörtgen
çizilerek gösterilir.

33
 Bağımsız iyelik; Nesneler arasındaki bir tür parça bütün ilişkisidir.
Bilindiği gibi günlük hayatta karşılaşılan pek çok komplike varlık,
birden fazla alt parçanın birleşiminden oluşmaktadır.
 Aggregation (Kümeleme) ilişkisi; bu tür varlıklar ile onları
oluşturan parçaların modellenmesini sağlar.

34
35
 Liste
Yığın
Add():
push(): Delete():
pop(): Firt():
Last():

 “Liste” sınıfı, ”Yığın” sınıfına bağlı olmadan da

yaratılabilir ve kullanılabilir.
36
 Birleştirmede (Composition) ise alt parçalar, o nesneyi
meydana getirmek için oluşturulurlar ve kendi başına
kullanılamazlar.
 UML gösterimi, bağlantı çizgisinin ucuna çizilen içi dolu bir
dörtgendir.

37
 Composite Aggregation : Bağımlı iyelik
 Parça ve bütün arasında organik bağımlılık vardır.

38
 Ünite Bölüm
Kitap

 “Ünite” nesnesi olmadan,”Bölüm “ nesnesi tek başına olamaz.

 Aynı şekilde ”Kitap” sınıfına bağlanmayan “Ünite “ sınıfı da
olamaz.
 “Kitap” nesnesi yok edildiğinde ona bağlı tüm nesnelerde yok
olur.

39
 Genel tanımlar içeren ana bir sınıf ile daha özel
ayrıntılara sahip alt sınıflar arasındaki ilişki türüne
genelleştirme denir.
 Alt sınıf, üst sınıftan türetilir.
 Üst sınıfın özellikleri alt sınıfta aynen kullanılabilir.
 Böylece tanımlanmış olan özelliklerin tekrar
tanımlanmaları gerekmez.
 Tasarlanan sınıfların tekrar kullanılabilirliği artar.
 UML’ de genelleştirme, bağlantı çizgilerinin ucuna
içi boş bir üçgen çizilerek gösterilir.

40
 Müşteri
Ad:string
adres:string
Kredi hesapla():Money

Kurumsal müşteri Şahsi müşteri

krediDerecesi: int KredikartıTipi: string
Kredilimiti: Money
krediHesapla(): Money

41
42
 Çok şekillilik (Polymorphism), farklı sınıflardan
yaratılmış olan nesnelerin, aynı mesaja farklı
tepkiler vermesi olarak tanımlanabilir.
 Alt sınıfın miras aldığı bir işlem aynen kullanılabilir.
 Örneğin “Müşteri” sınıfında tanımlı kredihesapla()
metodu,”ŞahsiMüşteri” alt sınıfında kullanılır.
Ayrıca ”KurumsalMüşteri” sınıfında
“kredihesapla()” işleminin ise çok şekilli olduğu
söylenebilir.

43
 Soyut (Abstract) sınıf, üzerinden doğrudan nesne
tanımlayan sınıftır.
 Soyut sınıfın UML tanımı, sınıftan ya da soyut
işlemden önce yazılan <<abstract>> anahtar
kelimesidir.

44
 Bir sınıf içerisinde tanımlı olan bir işlem aynı isimle
ancak farklı tip veya sayıda değişik parametreler ile
tanımlanabilir. Buna aşırı yükleme (overloading)
denir.
 Örneğin toplama işlemine aldığı parametrelere göre
birçok farklı şekilde tanımlanır
o Integer topla(integer a,integer b)
o Float topla(integer a,float b)
o Float topla(float a,integer b)
o Float topla(float a,float b)

45
Yazılım geliştirme yaşam döngüsü açısından
nesneye yönelik sistem analizi, geleneksel yapısal
yaklaşımla aynı aşamalara sahiptir.

46
 Planlama, analiz, tasarım, gerçekleştirme aşamaları ve
aşamalarda gerçekleştirilen aktiviteler de aynıdır.
 Yapısal sistem geliştirmede işlemlerin tanımlanması ve
modellenmesi üstünde durulurken, nesneye yönelik yaklaşım
nesneler ve etkileşimleri vurgular.
 Her iki yaklaşım geliştirme aşamalarında modelleme üstünde
dursalar da, değişik açılardan ele alırlar. Ör; sistem analisti,
veri akış diyagramları yerine, etkileşim diyagramları kullanır.

47
 Bundan başka, geleneksel yaklaşımda kullanılan varlık-ilişki
diyagramları ile nesneye yönelik yaklaşımdaki sınıf
diyagramları, farklı gösterimler kullanmalarına karşın birçok
ortak kavram içerirler.
 İki yaklaşım arasındaki temel fark, sistem aktivitelerini
göstermek için kullanılan diyagramların farklılığı ve
çeşitliliğidir.

48
Nesneye yönelik yaklaşımda uygulamanın gereksinimlerini
tanımlamak için birbiriyle ilişkili ancak bağımsız iki diyagramdan
yararlanılır:
1)Sınıf (Class Diagram) diyagramı; Bir sistemdeki tüm nesnelerin sınıf
tanımlarını ve ilişkilerini göstermek için kullanılır. Aynı zamanda her
sınıfın özellikleri ve işlemleri de bu diyagramda belirtilir.
2)Kullanım senaryosu (Use Case Diagram) diyagramları; yeni
sistemdeki kullanımların, senaryoların belirlenmesi için kullanılır.
Genel olarak, sistemin nasıl kullanılacağını modeller. Sistemdeki olay
tablosunun bir özet gösterimi şeklindedir. Bu sayede sistemin
gerçekleştirmesi gereken fonksiyonlar belirlenmiş olur. Tek,
anlaşılabilir bir kullanım senaryosu diyagramı ile sistem
modelleneceği gibi, daha küçük diyagramlardan oluşmuş bir kullanım
senaryosu modeli de oluşturulabilir.
49
Tasarlanacak olan sistem analiz edilirken temel amaç,
çözülecek problemin doğru, mantıklı, anlaşılır ve test
edilebilir bir modelini oluşturmaktır. Problemin çözülmesi
analiz aşamasında gerçekleşmez. Buradaki hedef,
problemin tam olarak anlaşılmasıdır. Yazılım nesneleri gibi
tasarıma yönelik detaylarla bu aşamada ilgilenilmez.

50
 Bir sistemin davranışı dış olaylara verdiği tepkilerdir.
 UML’de, sistemin dışarıdan görülebilen ve test edilebilen
davranışları,kullanım senaryoları ile gösterilir.
 Senaryolar: Anlamlı bir sonuca ulaşmak için aktör ile
sistem arasında gerçekleşen olaylardır.
o Aktör ise bir senaryoyla etkileşime geçen kimse ya da şey, kısaca
sistemin kullanıcısıdır. Bir insan veya başka bir sistem olabilir.
o Aktör, senaryodan kullanabileceği bir sonuç bekler.

51
 Kullanım senaryosu modellemesi kolay anlaşılırdır, müşteri
ile iletişimi kolaylaştırır.
 Gerçeklenen sistemin isteklere uygun olup olmadığı
senaryolar ile test edilebilir.
 Nesneye yönelik analiz için uygun bir başlangıç oluşturulur.

52
 Aktörler: Senaryo ya da aktörlerden ilk olarak hangisinin
belirleneceği sistem analistinin vereceği karardır.
 Aktörler UML’de kullanım senaryosu diyagramları çizilirken
çöp adamlarla ifade edilir.
 Ancak aktör özelliklere ve işlemlere sahip olabileceğinden,
normal bir sınıf şeklinde de gösterilebilir.

53
 Aşağıdaki örnekte güncel bir uygulama olan internette
alışveriş için uygulamanın yapısı, teknik alt yapı, alışveriş
sırasında gerçekleştirilen işlemler üzerinde durulmuştur.
Sitenin genel yapısı:
 Site kahve satışı yapmaktadır.
 Hazır kahveler satın alınabileceği gibi, müşteri dilediği
çeşitleri harmanlayarak özel kahve siparişi de
verebilmektedir.
 Bir alışverişte birden fazla çeşit kahve siparişi verilebilir.

54
 Siparişi tamamlamak için müşteri teslimat ve ödeme
formlarını doldurur.
 Kredi kartı ve banka havalesi ile ödeme yapılabilir.
 Arka planda müşterinin bilgileri ve ödemesi doğrulanır.
 İstenen özelliklerdeki sipariş, kahve sağlayan depodan
alınır, fatura basılır ve müşteriye gönderilir.

55
 Aktörleri ve senaryoları belirlemek için öncelikle sistemin
sınırları belirlenmelidir. Bunun için ilk olarak sistemin genel
akışı adım adım özetlenir;
 Müşteri, hazır bir kahve seçer. Özellikleri ile fiyatı da
gösterilir.
 Müşteri istediği kahveleri harmanlayarak kendine özel bir
kahve oluşturabilir. Fiyat da seçilen kahvelere göre yeniden
hesaplanır.
 Müşteri 1. ve 2. adımları tekrarlayarak alışverişine devam
eder.

56
 Müşteri siparişini siteden verir. Siparişi tamamlamak için
teslimat ve fatura bilgileri, ödeme detaylarını içeren bir form
doldurur.
 Sipariş sisteme girilince, müşteri ve ödeme bilgileri
doğrulanır.
 İstenen özelliklerdeki kahve, sağlayıcı depodan alınır,
faturası basılır.
 Sipariş, fatura ile birlikte müşteriye gönderilir.

57
 Senaryo, bir aktöre fonksiyonel bir değer sunan bir
bütündür.
 Herhangi bir senaryoyla ilişkisi bulunmayan bir aktör
sistemde gereksizdir. Ancak hiçbir aktörle ilişkide olmayan
senaryolar bulunabilir.
 Kullanım senaryoları belirlenirken sistemin aktörlere karşı
sorumlulukları düşünülmelidir.

58
 Kullanım senaryolarının UML gösterimi elips şeklindedir.
 Senaryolarla ilişkide olan aktörler de diyagramda yer alır.
Genelde aktör ve senaryoların etkileşimde olması beklenir.
 Bir aktörün direk olarak bir başka aktörle etkileşimde olması
ise önerilmez. Aralarında mutlaka etkileşimi sağlayan bir
senaryo bulunmalıdır.

59
 <<extend>>
Özel kahve Kahve seçimi
oluşturma

Bilgi Girişi

Sipariş Teslimatı <<include>>

Depo
Müşteri
<<include>> Sipariş Verme

Fatura Basımı

Kahve sitesi sistemi için kullanım senaryosu diyagramı

60
 Kullanım senaryoları arasında 3 farklı ilişki tanımlanabilir.

 İçerme(Include-Use): Bir senaryoda kullanılan başka bir

senaryoyu belirtir.

 Genişletme(Extend): Senaryolar doğal akışlarına göre

hazırlanırlar. Özel durumlarda sapmalar olabilir. Bu gibi
senaryolarda genişletme ilişkisi ile gösterilir.

 Özelleştirme(Specialization): Sınıflar arası türeme ilişkileri

gibi, senaryolar da türetilebilir.
61
Her senaryo bir senaryo dokümanı ile ayrıca detaylandırılmalıdır.
Senaryo dökümanının yapısı;
 Senaryo adı
 İlgili aktörler
 Senaryonun gerçekleşebilmesi için gerekli ön koşullar
 Senaryo tamamlandığında sistemin ulaşacağı durumu tanımlayan
son koşullar
 Senaryonun temel akışı
 Özel durumlarda yürütülecek alternatif akışlar

62
Senaryo KS1 Sipariş verme

Birinci Aktör Müşteri

İlgililer ve Kahve sitesi:Müşterinin siparişi dogru ve eksiksiz kaydedilmeli,ödeme ve
Beklentileri teslimat bilgileri dogru alınmalı.
Depo:Siparişteki kahve miktarları doğru ve eksiksiz olmalı.

Ön Koşullar Müşteri alışveriş sitesinde olmalı,sunulan seçenekler ile istediği kahveyi

oluşturmalıdır.
Son Koşullar Ödeme ve teslimat bilgileri doğrulanmıştır.Müşterinin siparişi sistem
veritabanına teslimat yapılmak üzere kaydedilmiştir.
Ana Akış 1-Müşteri sipariş etmek istediğini belirtir.
2-Müşteri teslimat için adını ve adresini,teslimat bilgilerinden farklıysa
fatura bilgilerini girer.
3-Müşteri ödeme şeklini seçer ve gerekli ödeme bilgilerini girer.
4-Sistem sipariş için benzersiz bir tanımlayıcı kod üretir,müşteri hesap
bilgileri ile birlikte kaydeder.
Alternatif Akış 2a-3a:Müşteri gerekli tüm bilgileri sağlamadan siparişi tamamlar. Sistem
bir hata mesajı vererek eksik olan bilgilerin tamamlanmasını ister. 63
 Kullanım senaryoları, birçok uygulamanın
modellenmesinde genellikle yeterli olmaktadır.
 Ancak bazı senaryolar, karmaşık işlemler içerebilir. Bu
gibi durumlarda anlaşılabilirliği arttırmak için sözleşme
yazılır.
 Sözleşmeler, ön koşullar sağlandığında sistemin
işlemesi ile uygulama nesnelerinin alacağı son
durumları tarif eden yapılardır.

64
 Nesneye yönelik analizde sistemin iç durumu sınıf modeli ile
tanımlanır.
 Bu modellemede sınıflar ile birlikte özellikleri, işlemleri,
bağlantılar, bütünleşmeler, bileşimler ve genelleştirmeler de
yer alır.
 Nesneye yönelik sistem analizi sırasında kullanım
senaryosu modellemesi ile sınıf modellemesi paralel olarak
ilerler.
 Kullanım senaryoları ile sınıfların belirlenmesi kolaylaşırken,
sınıflar da gözden kaçırılan kullanım senaryolarının
belirlenmesini sağlar.
 Bu iki model ile uygulama alanının modeli oluşturulmuş
olur. 65
 Sınıf modellemesinde yer alan sınıflar, gerçek dünyayı
oluşturan kavramsal nesnelerdir.
 Yazılım sınıfları bu aşamada düşünülmese de, tasarıma
kılavuzluk eder.
 Sınıfları belirlemek için, kullanım senaryolarında yer alan
isimlerden ve isim tamlamalarından yararlanılır.
 Örnek olarak KS1 kullanım senaryosundaki isimler ve
tamlamaları verilmiştir.
o Müşteri sipariş etmek istediğini belirtir.
o Müşteri teslimat için adını ve adresini, fatura bilgilerini girer.
o Müşteri ödeme şeklini seçer ve ödeme bilgilerini girer.
o Sistem benzersiz tanımlayıcı kod üretir, müşteri hesap bilgileri
ile birlikte veritabanına kaydeder.
66
 Gereksinimlerde yer alan bir kavramın gerçekte bir sınıf
olarak gerçekleştirilip gerçekleştirilmeyeceği, birkaç
soru ile kesin olarak belirlenebilir:
o Kavramla ilgili veri saklanması gerekiyor mu?
o Değişik değerler alabilecek farklı özellikleri var mı?
o Kavramdan birçok nesne türeyebilir mi?
o Uygulamanın kapsama alanı içinde mi?
o Kavramın sınırları iyi çizilmiş mi, tanımı tam yapılabiliyor mu?
 Problemin çözümü tasarım sürecine bırakılır.

67
 Birsınıfın özellikleri, yaratılan nesnelere özgü değerler
alan verilerdir.
 Özellikler genellikle basit veri tiplerinden oluşur.
 Birden fazla alandan oluşan, üzerinde işlem yapılan,
kendi niteliklerine sahip olan kavramlar, bir sınıfın
özelliği değil ayrı bir sınıf olarak ifade edilmelidir.

68
 Bağlantılar nesnelerin işbirliği ilişkilerinin
çıkarılmasına yardımcı olmaktadır.
 Sistem gerçekleştirildiğinde sınıflar arasındaki
bağlantılar, bu sınıflardaki belirli özellikler ile temsil
edilir.
 Analiz aşamasında ise, bağlantılar çizgiler ve
çoğullama simgeleri ile gösterilir.

69
 Bağlantıların belirlenmesi için, sınıfların belirlenmesinde
olduğu gibi kullanım senaryolarından yararlanılır.
 Senaryolarda yer alan fiiller, olası bağlantılardır.
 Sistemin amacı dışındaki bağlantılar gereksizdir.
 Sistemin tasarımı ile ilgili bağlantılar dikkate alınmalıdır.
 Ayrıca senaryoda yer alan faaliyetler bağlantı değil etkileşimi
ifade eder. Bu yüzden bağlantı ilişkiyi temsil etmelidir.
 İki sınıf arasında birden fazla yol varsa, genellikle çözümde
fazlalık ilişki vardır.
 Gereğinden fazla bağlantı sınıf modellemesinin
anlaşılabilirliğini azaltır. 70
Sınıf Musteri, Urun, Siparis
Nitelik İsim, Soyisim, Adres, Teslimat Tarihi,
Ödeme Türü, Kart Numarası
Metot SiparisVer
71
 Sınıf diyagramı, kullanım senaryoları ile analizi yapılan
sistemin uygulama modelini gösterir.
 Bu diyagramda kavramsal sınıflar, aralarındaki ilişkiler
ve sınıfların nitelikleri yer alır.
 Sınıf diyagramlarında henüz işlemler bulunmamaktadır.
 İşlemlerin belirlenmesi, sınıfların sorumluluklarının
belirlenmesi demektir ve nesneye yönelik sistem
tasarım safhasını oluşturur.

72
 1 Kahve sitesi 1 Kahve
*
Tanım:String
* Birimfiyat:Money

Müşteri
ad:string
telefon:string 0..1 ÖzelKalem
email:string Sipariş İçerik:List
Sipariş Kalemi ÖzelFiyat:Money
tarih:date 1 1..*
1 Teslimadres:String miktar:int
durum:String
StandartKalem
stdFiyat:Money
1
0..1 1
Fatura Ödeme
Tarih:Date miktar:Money
adres:String tarih:Date
ID no:int tip:String

73
Şekil-11.3:Kahve sitesi sistemi için sınıf diyagramı
 Tasarım aşamasında analizi yapılarak modellenen sistemin
mantıksal çözümü oluşturulur.
 Kavramsal sınıflar baz alınarak yazılım sınıfları belirlenir. Asıl
önemli olan, sınıfların aralarındaki etkileşimlerin belirlenmesi ile
nesnelere sorumlulukların atanmasıdır.
 Sorumlulukları yerine getirmek üzere sınıflarda metotlar
oluşturulur.
 Nesneye yönelik sistem tasarımı sırasında nesnelerin birlikte
çalışmalarını göstermek amacıyla etkileşim diyagramları çizilir.
 Bunlar işbirliği (collaboration) ve ardışıllık (sequence)
diyagramlarıdır.
 Bunlarla birlikte sistemin son durumunun tasarım sınıf diyagramı
da çizilir
74
 <<Interface>>
KrediKartıOnayAdapter
onayAl(siparis:Sipariş):boolean

VisaAdapter MasterCardAdapter ???Adapter

onayAl(siparis:Sipariş):boolean onayAl(siparis:Sipariş):boolean

AmExAdapter

onayAl(siparis:Sipariş):boolean
75
Kahve sitesi sistemi için kredi kartı onay tasarımı
 Nesneye yönelik tasarım, senaryoları gerçeklemek üzere
sorumlulukların ilgili birimlere atanması ve nesneler arası
işbirliği oluşturulmasıdır. Etkileşim modellenmesi iki
diyagramla yapılır;
İşbirliği (Collaboration) Diyagramı: Hangi nesnelerin birlikte
çalışacağını, nasıl mesajlaşacağını, bir durumu yada
fonksiyonu nasıl gerçekleştireceklerini belirtir. Kullanım
senaryosu diyagramında belirtilen tüm durumlar için, ayrı
işbirliği diyagramları çizmek gerekir.
Ardışıllık (Sequence) Diyagramı: İşbirliği diyagramında
verilen bilginin daha detaylı açıklamalarından oluşur.
Nesneler arasındaki mesajlaşmaların sırası, diyagramdaki
diziliş sırası ile betimlenir.
76
İşbirliği diyagramında (Collaboration Diagram) mesajlar,
yollandıkları sıraya göre numaralandırılırlar. Bir mesajın
yollanması sebebiyle yollanan mesajlara, bağlı alt
numaralar verilir.

n4:Nesne n4:Nesne
1:mesaj1()

2:mesaj4() 1.1:mesaj2()

n4:Nesne n4:Nesne

İşbirliği diyagramında mesaj sıra numaraları

77
Ardışıllık diyagramlarında (Sequence Diagram) sıra
numarası kullanılmaz. Mesajlar yollandıkları sırada alt
alta çizilir.
n1:Nesne n2:Nesne n3:Nesne n4:Nesne

mesaj1()
mesaj2()

mesaj3()
mesaj4()

78
Tasarımda bir sorumluluğu yerine getirmek üzere
nesne kendi metotlarından birini çağırabilir. Bir
nesnenin kendi metotlarını çağırmasına kendine
mesaj denir.
1:mesaj()
n1:Nesne

n1:Nesne

mesaj()

79
 Bir mesajın sadece belirli bir koşul gerçekleştiğinde
gönderilmesi gerekebilir. İşbirliği diyagramında bu
durum mesajın başına eklenen şart ile gösterilir.

1:[şart=uygun] işlemYap()
n1:Nesne n2:Nesne

80
 n1:Nesne n2:Nesne

opt [şart=uygun]

81
 Bir işlemin yapılması için bir nesne grubuna mesaj
gönderilmesi gerekebilir. Bir nesne grubuna yollanan
mesaj yada mesajlar işbirliği diyagramında
“*”simgesiyle, ardışıllık diyagramında ise “loop”
çerçevesi içinde gösterilir.

82
 1 *: alttop=altToplamAl()
s:Sipariş :SiparişKalemi

İşbirliği diyagramı

s:Sipariş :SiparişKalemi

loop
alttop=altToplamAl()

Ardışıl diyagram 83
 1:[i=1..N] işlemYap()
n1:Nesne n2:Nesne

n1:Nesne n2:Nesne

loop [i=1..N]
1: işlemYap()

84
 Tasarımcının bir kullanım senaryosunda yer alan durumları
modelleyerek anlatması ile senaryolar gerçeklenir.
 Tasarımdaki en önemli girdi gerçekleştirilecek olan senaryolar
ve varsa bunlar için yazılan sözleşmelerdir.
 Senaryoların gerçeklenmesi ile işbirliği içinde çalışan
nesnelere sorumluluklar atanır.
 Senaryoların gerçeklenmesi adımında kullanılan girdiler
aşağıda görülmektedir.

Ardışıl
Senaryolar Diyagramlar
Sorumluluklar
İşbirliği
Sözleşmeler Sorumlulukları
Diyagramları
Tasarım n atanması
Kalıpları ve
Yazılım Sınıf
Prensipler
Diyagramları

85
 :Denetçi

yeniSipariş yarat
:Sipariş

Denetçi yarat skList:

List<SiparişKalemi>
Yaratıcı

Yaratıcı

86
87
88
 Başlangıç nesnesi tüm programın çalışmasını
denetleyen bir nesnedir. Başlangıç nesnesi
yaratıldığında ve başlangıçla ilgili diğer işlemler de
yerine getirildiğinde sistem harekete geçer.
 Başlangıç sorumluluklarına ana program ya da
sistemin ara yüz nesneleri de sahip olabilir. Sistemin
kullanıcı arayüzü ile olan ilişkisi de Denetçi nesnesi
üzerinden sağlanır. Bu sayede tasarlanan sistemin
kullanıcı arayüzünden bağımsız olması da sağlanır.

89
 Görünürlük, nesnenin referansa sahip olması olarak
tanımlanabilir. Dört çeşit görünürlük tipi bulunmaktadır. Bunlar;
• Özellik görünürlük: B nesnesi A nesnesinin bir özelliğidir. Bu
durumda A,B ye sahiptir.
• Parametre görünürlüğü: B nesnesi A nesnesinin bir metodunda
parametre olarak yer alır. Görünürlük sadece o metodun içinde ve
çalıştığı sürece geçerlidir. Metot bitince görünürlük ortadan
kalkar.
• Yerel görünürlük: B nesnesi A nesnesinin bir metodunda yerel
değişken olarak yer alır. Görünürlüğün geçerliliği metodun
çalışma süresi kadardır.
• Global görünürlük: B nesnesi ile A nesnesi aynı uzayda yer
aldığında olan görünürlük tipidir. A ve B nesneleri var oldukça
görünürlük devam eder.

90
Senaryoları gerçekleştirmek üzere etkileşim
diyagramlarının oluşturulmasına paralel olarak,
yazılım sınıflarını gösteren tasarım sınıf diyagramı da
çizilir. Tasarım sınıfı diyagramında yazılım sınıfları,
sınıfların özellikleri, özelliklerin tipleri, metotları,
metotların parametreleri ve erişim hakları gösterilir.
Yazılım sınıfları arasında bağımlılık, özellik
görünürlüğü dışındaki görünürlük tipleri sonucunda
oluşur. Sınıf diyagramında kesik çizgili ok ile
gösterilir.

91
KahveSitesi Kahve

Adres: String
1 KahveKatalog 1..*
Tanım: String
İsim: String Fiyat: Money
tanımAl() İd: in
Bul()

1 Sipariş

Denetçi Tamamlandı: boolean

1..* SiparişKalemi
Tamamlan() 1..*
Miktar: int
kahveEkle() siparişEkle()
ödemeYap()
toplamAl()
faturaBas()
1
1
Fatura Ödeme StandartKalem ÖzelKalem
İd : int stdFiyat : Money
Miktar : Money newAttr : int
Tarih :Date
Tarih : Date altToplamAl()
altToplamAl()
92

Kahve Sitesinin tasarım sınıf diyagramı

Örnek: Bir e-ticaret
uygulamasında sipariş

 Bir e-ticaret
projesinin önemli
nesnelerinden birisi
olan sipariş ve
onunla ilgili
nesneler verilen
UML diyagramında
olduğu gibi
modellenebilir.

93
Verilen diyagram aşağıdaki gibi yorumlanabilir:
• Bu projede iki tür müşteri bulunmaktadır; genelleştirme (generalization). Müşteriler
ya doğrudan İnternet’ten kendileri sipariş verebilir veya bir mağazaya gidip oradan
sipariş verebilirler.
• Müşteri nesnesi için bir koşul/kısıt (constraint) tanımlanmıştır. Bu koşula göre, ancak
ve ancak siteye üye girişi yapmış kişiler sipariş verebilir.
• Müşteri ile sipariş arasında ilişki vardır. Bir müşterinin 0 veya daha fazla sayıda
siparişi olabilir (0..*). Fakat bir sipariş ancak bir tek müşteriye (1) bağlı olabilir. Bir
siparişte en az 1 ürün vardır (1..*) ve bir sipariş en az bir ödeme şekline sahiptir
(1..*).
• Sipariş ile “sipariş detay” arasında oluşum (composition) bağıntısı vardır. Sözkonusu
sipariş silindiği zaman o siparişe ilişkin ayrıntı detay kayıtlar da silinir. “Sipariş detay”
ile ürün arasında içerim (aggregation) bağıntısı vardır. Bu durumda sipariş detay kaydı
silindiği zaman o kayıtla ilişkili ürün nesnesi silinmez.
• Bir müşterinin sistemde 0 (sıfır) veya daha fazla sayıda adresi tanımlı olabilir. Her
siparişin bağlı olduğu iki adres vardır. Bu adreslerden biri fatura adresi diğeri teslimat
adresi olarak kullanılır ve her sipariş için ancak 1 (bir) fatura adresi ve 1 (bir) teslimat
94
adresi tanımlanabilir.
BİLGİSAYAR SİSTEMLERİ
 
 Dış etkilere göre düzenli bir şekilde etkileşen ya da birbirinden
bağımsız olarak belirli bir yapı oluşturan, belli bir hizmeti görmek
üzere veri toplayan, işleyen veya üreten bir grup öğeye sistem
adı verilir.

 Bir sistemi oluşturan daha alt seviyede sistemlere ise altsistem

adı verilir.

2
 Sistem Çeşitleri:
o Doğal sistemler: Canlı ve cansız olarak ikiye ayrılabilirler.
• Canlı sistemler: Dünyada bildiğimiz tüm canlılar. Ör., Hücreler,
sinir sistemi, dolaşım sistemi.
• Cansız sistemler: Ör., güneş sistemi, coğrafi sistemler.

o İnsan yapısı sistemler: İnsanlara yarar sağlamak için

insanlar tarafından oluşturulur, düzenlenir ve
sürdürülürler. Ör., eğitim sistemi, ulaşım sistemi, maliye
sistemi

3
 Bilgiyi işlemeye yönelik olarak gerçekleştirilen her türlü
sisteme Bilgi Sistemi (Information System), bu alandaki
teknolojiye de Bilgi Teknolojisi (Information Technology – IT)
adı verilmektedir.

 Genel olarak bilgi sistemi denildiğinde bilgisayar donanımı,

yazılım, veri, kullanım yöntemi ve insanın oluşturduğu
sistemlerden söz edilmektedir. Tek başına bir bilgisayar bir
sistem olarak değerlendirilmez, ancak bir araç olarak
değerlendirilebilir.

4
Bilgi sistemlerinin çeşitleri:
1. Çevrimiçi Sistemler
2. Gerçek Zamanlı Sistemler
3. Karar Destek Sistemleri
4. Bilgi Tabanlı (Knowledge-based) Sistemler
5. Veritabanı Yönetim Sistemleri
6. Kişisel Bilgisayarlar
7. Ofis Otomasyonu
8. Atölye Otomasyonu
9. İletişim Sistemleri
10. Endüstriyel Sistemler
11. Kontrol Sistemleri

5
 Çevrimiçi Sistemler
 Çevrimiçi (on-line) sistemler dışarıdan aldıkları bilgileri işler
ve sonuçları gereken yerlere verirler.
 Etkileşimde bulunan kullanıcı bilgisayara uzaktan erişir.
Bunun için genellikle bir uçbirim kullanır.
 Bankaların ATM (Automatic Teller Machine) makinaları
çevrimiçi sistemlere en güzel örnektir.

İletişim Hatları

Merkezi Bilgisayar
Yerel Uçbirimler Uzak Uçbirimler 6
Gerçek Zamanlı (Real-time) Sistemler
 Dış dünya ile etkileşim sağlayan, olayları izleyip anında
çözümleyen, karşılığında bir kontrol işlemi yapan ve bu
işlemleri zaman kısıtlarına (Milisaniyeler veya mikrosaniyeler
bazında) bağlı olarak gerçekleştiren sistemler «gerçek
zamanlı» olarak adlandırılır.
Örneğin,
o Bir takip radarı ve bir uçaksavardan oluşan askeri bir savunma
sistemi,
o Bir nükleer reaktörün çekirdeğindeki ısı algılayıcıları ve işlem kontrol
düzeneklerini kontrol eden sistem,
o Bir savaş uçağını havada tutup özel manevralar yaptıran uçuş kontrol
sistemi.

7
 Tepki sürelerine göre gerçek zamanlı sistemler 3’e ayrılır:
o Gevşek gerçek zamanlı (Soft real-time) sistemler:
• Belirli bir işi belirli bir zaman kısıtı içinde tamamlayamazsa tüm sistem çökmez,
yalnızca başarımı düşer.
• Tepki süreleri genellikle 1 saniyenin altındadır. Ör., trafik kontrol sistemleri,
karar destek sistemleri, benzetim (simülasyon) sistemleri.
o Katı gerçek zamanlı (Hard real-time) sistemler:
• Ne olursa olsun verilen zaman kısıtı içinde verilen iş gerçekleştirilmelidir.
• Başarılamaması durumunda sistemin çökmesi ve hayati tehlikelerin doğma
olasılığı mevcuttur.
• Tepki süreleri birkaç mikrosaniye ile birkaç milisaniye arasındadır. Ör., Nükleer
santral kontrol sistemleri, savaş uçakları ve güdümlü mermi uçuş sistemleri,
hastanelerdeki yaşam destek üniteleri. Çoğunlukla özel donanım gerektirirler
ve oldukça yüksek maliyetlidirler.
o Sıkı gerçek zamanlı (Firm real-time) sistemler:
• Arada bir yerde durup küçük bir olasılıkla zaman kısıtının aşılmasının kabul
edilebileceği, kontrol altında tutulabilen sistemlerdir.
• Tepki süreleri birkaç milisaniyedir. Ör., Hassas deniz ve hava trafik kontrol
sistemleri, endüstriyel üretim ve makine kontrol sistemleri. 8
Karar Destek (Decision support) Sistemleri
 Bilgisayarlar kendi başlarına karar almazlar ancak insanlara
durum farkındalığı yaratıp gerekli hesaplamaları yaparak
karar almalarında yardımcı olurlar. Ör., çalışma tabloları,
istatistik çözümleme sistemleri.
 Karar destek sistemlerinin ortak özellikleri arasında veri
toplama, işleme ve sergileme yanında, bunlar üzerinde
matematiksel ve istatistiksel algoritmalar çalıştırarak çeşitli
sonuçlar elde etmek vardır.
 Sonuçları uygulama alanına özgü bir şekilde sergilemek de
yetenekleri arasındadır.

9
Bilgi Tabanlı (Knowledge-based) Sistemler (Uzman Sistemler)
 Bilgi tabanlı sistemler çok miktarda bilgiyi kullanarak belirli
bir görevi yerine getirirler.
 Bu sistemlere bazen uzman (expert systems) sistemler adı
da verilir.
 Uzman sistemler belirli bir uzmanlık alanında çalışan
insanlara yardımcılık yapabilecek kadar yüksek düzeyde bilgi
sağlarlar.
 Varılan karara nasıl ulaştıklarını, neden belirli bir yolu seçip
diğerlerini reddettiklerini belirtirler.
 Belirsiz veya eksik bilgilerle dahi belirli bir düzeye kadar
çalışabilip, kullanıcılara destek sağlarlar.

10
 Uzman sistemler üç modül halinde geliştirilirler:
o Uygulama alanına özgü bilgiler ve temel kurallar bir bilgi tabanı
(knowledge-base) içinde toplanırlar.
o Çıkarsama makinesi (inference engine) bu bilgi tabanının etkin bir
şekilde kullanılabilmesini sağlar.
o Kullanıcı arayüzü ise sistem ile kullanıcı arasındaki etkileşimi sağlar.

Problem
Çıkarım Kullanıcı
Kullanıcı
Makinesi Arayüzü
Çözüm

Uzman sistemler bilgisayar sistemleri

içinde yapay zeka alanına girerler. Bu
Bilgi Tabanı nedenler- çoğunlukla LISP ve PROLOG
gibi dillerle programlanırlar 11
Veritabanı Yönetim Sistemleri
 Büyük miktarda ve birbiri ile ilişkili
veriler veritabanlarında tutulurlar. Kullanıcı
 Bu verilere uygun şekilde erişebilmek (Yazılımcı veya İşletmen)
için veritabanı yönetim sistemi adlı Sorgulama ve Veri
sistemler kullanılmaktadır. İşleme Yazılımı

 Veritabanını yaratmak, veri girmek, var

Veri Erişim Yazılımı
olan verilerde değişiklik yapmak,
veriler üzerinde sorgulama yaparak Veritabanı
Veritabanı
sonuçları almak bu sistemlerin Tanımları
görevleridir.

12
 Veritabanı yönetim sisteminin kullanım amaçları:
o Her kullanım amacı için ayrı veriler tutmak yerine, verileri
bir arada ve ortak yapıda toplayarak fazla kopyaların
kullanımı sonucu oluşabilecek sorunları ortadan
kaldırmak.
o Paylaşılır verilerin güncelleştirilmesi sırasında
doğabilecek tutarsızlığın önüne geçmek.
o Kullanıcı özelliğine göre farklı arayüzler sağlamak.
o Birden çok kullanıcıya aynı anda hizmet vermek.
o Menü tabanlı veya doğal dil arayüzleri ile pratik kullanım
sağlamak.

13
o Çok karmaşık ilişkilere sahip verilerin uygun şekilde
depolanmasını ve erişilmesini sağlamak.
o Veri tanımlamaları için standart ve tutarlı yapılar, sergileme
ve raporlama yöntemleri belirlemek.
o Ekonomik bir şekilde genişleyebilme özelliği sağlamak.
o Uygulama geliştirmede zaman tasarrufu sağlamak.
o Verilerin sürekli güncellenebilmesini sağlayarak tüm
kullanıcıların istedikleri anda güncel verilere erişebilmesini
sağlamak.
o Saklanan verileri yedekleyerek koruma altına alabilmek.

14
Kişisel Bilgisayarlar
 Kişisel bilgisayarlar (PC) daha çok bireysel kullanım
amaçlarına hizmet eden paket programlar çalıştırırlar.
 Kişisel masaüstü yayıncılık, internet erişimi, kişisel kayıtların
tutulması, eğlence gibi birçok kullanım amaçları mevcuttur.
 Kendi başlarına bir sistem olarak değerlendirmek pek doğru
değildir; ancak özel amaçlı yazılımlarla belirli amaçlar için
kullanılmaları durumunda özel sistemler oluşturmaktadırlar.

15
Ofis Otomasyon Sistemleri
 Ofis otomasyonu, personel haberleşmesi, veri paylaşımı,
masaüstü yayıncılık, planlama gibi amaçlar için oluşturulan
ve genellikle bir ağ ile bağlanmış birden fazla bilgisayardan
oluşan sistemlerdir.

16
Atölye Otomasyon Sistemleri
 Üretim maliyetini azaltma, niteliği arttırma, değişik pazar
koşullarına uyum sağlama gerekliliği üretim sektöründe
otomasyonun önemini arttırmıştır.
 Atölye kontrol sistemleri en genel anlamda iş planlaması,
ilerleme görüntülenmesi, durum raporlanması ve düzeltici
etkinlikleri kapsar.
 Atölye denetimi; kullanıcıya gerçek zamanlı işlem denetimi
için gereken sistem durum raporunu hazırlar.

17
İletişim Sistemleri
 Çoğunlukla «telekom» olarak adlandırılan iletişim
teknolojisinde önceleri sadece donanım önemli iken
günümüzde donanım kadar yazılım da önem kazanmıştır.
 Gerek veri, gerekse ses ve görüntü aktarımında artık yazılım
da gerekmektedir. Örneğin günümüzde bir telefon santralinde
fiziksel kablolar yerine sanal bağlantı elemanları
kullanılmaktadır.
 Ses ve görüntü gerçek zamanlı olarak sayısal hale
getirilmekte, sıkıştırılarak uzak mesafelere çeşitli ortamlar
üzerinde taşınmakta ve sonra tekrar çözülerek hizmete
sunulmaktadır. Bu işlemler için de bilgisayar ve modemlerden
yararlanılmaktadır.
18
Endüstriyel Sistemler
 Pek çok endüstriyel sistem çeşitli kurallara göre bilgi işleyen
ve sonuçlarını çeşitli makinelere uygulayan sistemlerdir.
 Bilgisayar Destekli Üretim bu sistemler arasında önemli bir
yer tutar.
 Bu sistemlerin girdileri, bilgisayar ortamına hazırlanmış
model dosyalarıdır. Bu dosyalardaki verilere göre makine
parçalarına uygun komutlar gönderilerek ham malzemenin
işlenmesi ve ondan mekanik parça üretilmesi sağlanır.

19
Kontrol Sistemleri
 Kontrol sistemleri, çeşitli altsistemleri bir mantık ile birleştiren
ve bir merkezden idare edilmesini sağlayan otomasyon
sistemleridir.
 Sistemin ilgi alanındaki çevresinden çeşitli algılayıcılarla
toplanan veriler değerlendirilir, kullanan işletmenlere sistem
durumu hakkında işlenmiş verilere dayanan bilgiler verir,
gerektiğinde algılayıcıları, uygulayıcıları ve diğer altsistemleri
kontrol eder.
 Kontrol sistemlerinin çeşitleri:
o Askeri sistemler
o Trafik kontrol sistemleri
o Robotik
20
o Gömülü sistemler
 Bir bilgisayarlı sistemi oluşturan ana bileşenler, en genel
şekliyle, donanım, altyapı yazılımı ve uygulama yazılımıdır.

Uygulama Uygulama Yazılımları

Yazılımları Temel Çekirdek
Yazılımlar
Ara Katman Arayüzü

Altyapı Çeşitli Dağıtık İşlevler

Yazılımları
İletişim Katmanı

İşletim Sistemi
Bilgisayar Donanımı
Donanım
(İşlemci, bellek, ağ ve arayüz donanımları)
21
Sistem Mimarisi
1. Donanım
 Bilgisayar tabanlı bir sistem donanım adı verilen çeşitli
elektronik birimlerden oluşur. Günümüzde çoğu donanım
birimi piyasadan temin edilebilmektedir.
Hazır ticari ürün  Commercial-Off-The-Shelf (COTS)

 Büyük sayılabilecek dağıtık bir bilgisayar sistemini oluşturan

donanım öğeleri sunucu, işlemci birimleri, kullanıcı arayüz
birimleri, altsistem arayüz birimleri, ağ birimleri, uç birimler
ve altsistemlerden oluşur.

22
 Yazıcı Çizici

Sunucu
Kontrol Uç
Birimleri

Ağ Birimi

Altsistem
Arayüz
Birimleri
Kullanıcı Arayüz
Birimleri

Altsistemler
23
2. Altyapı Yazılımı
 Bilgisayarı çalıştırmak için gereken işletim sisteminden
başlamak üzere uygulama yazılımlarına arayüz hizmeti
veren her türlü yazılıma altyapı (sistem) yazılımı adı verilir.
 Bu yazılımların ortak özellikleri arasında bilgisayar
donanımına erişmeleri, çok sayıda kullanıcıya tutarlı bir
şekilde hizmet vermeleri ve bilgisayar özkaynaklarını en
uygun şekilde kullanarak iş sıralaması yapabilmeleri
sayılabilir.
 Altyapı yazılımları üç bölümde incelenebilir:
o İşletim sistemi
o Ara Katman Yazılımı
o Yardımcı yazılımlar

24
2.1 İşletim Sistemi;
 Bilgisayar donanımını kullanılır hale getirmek üzere merkezi
işlem birimi tarafından sürekli olarak koşturulan çekirdek
(kernel) yazılım grubudur.
 İşletim sistemi uygulama alanının gereklerine ve yazılım
gereksinimlerine uygun olmalıdır. Örneğin gömülü sistemler
için grafiksel arayüzü olan bir işletim sistemi gereksizdir.
 Gerçek zamanlı sistemlerin gereksinimlerini karşılayabilmek
için yine gerçek zamanlı işletim sistemleri kullanılmalıdır.
 Yazılım gereksinimleri yanında kullanılan donanımın
özellikleri, yani bilgisayar ve veri yolu mimarisi de kullanılacak
işletim sistemini etkiler.

25
2.2 Ara Katman Yazılımı:
 Donanım, ağ yapısı ya da işletim sistemi gibi yazılım yapısının
alt katmanlarında gerçekleşen hızlı teknolojik gelişmeler
nedeniyle değişim gereksinimi ortaya çıkmaktadır. Uygulama
yazılımları katmanında ise bu gereksinim daha az olduğu için
buraya yapılan yatırım korunmalıdır.
 Bunu sağlamanın yolu da değişim hızları farklı olan bu iki
katmanı birbirinden bir ara katman (middleware) kullanarak
ayırmaktır.
 Alt katmanlarda gerçekleşen değişiklikler sadece ara
katmanın ilgili bölümlerinin değiştirilmesi ile uygulama
yazılımlarından saklanır.

26
 Ara katman, standart bir arayüz ve geliştirme mantığı vererek
uygulama geliştiriciye alt düzeyde yaşanabilecek iletişim ve
eşzamanlılık sorunlarıyla ilgilenmeden dağıtık ve paralel
programlama olanağı sağlar.
 Ara katman yazılımı uygulama yazılımlarının hataya dayanıklı
olabilmeleri için gerekli programlama, iletişim, durum
izlemesi, geri kazanma (recovery), kritik veri saklama ve geri
alma gibi yapısal özellikleri desteklemelidir.

27
2.3 Yardımcı Yazılımlar:
 Eğer altyapı yazılımları belirli bir uygulama alanına hizmet
etmek üzere kullanılacaksa, bu alanın gereksinimleri göz
önüne alınarak daha yüksek düzeyde bir ara katman yazılımı
oluşturulabilir.
 Ara katman yazılımlarını her sistem için ayrı ayrı geliştirmek
yerine gereksinimlerin ortak yönlerini aynı ara katmanda
toplamak, bunları yardımcı yazılımlarla desteklemek, sonra da
aynı alandaki farklı sistemlere uygulamak çok etkin bir
yöntemdir.
 Yardımcı yazılımlara bir örnek, grafiksel kullanıcı arayüzü
geliştirmede kullanılacak yüksek düzey tasarım ve geliştirme
araçları ve kütüphaneleridir.
28
3. Uygulama Yazılımları
 Tamamen sistemin kullanılacağa alana özgü tanımlanmış
işlevleri yerine getirecek yazılım birimlerini içeren bileşene
uygulama yazılımı (application software) adı verilmektedir.
 Asıl yazılım geliştirme süreci bu bileşen için geçerlidir; çünkü
donanım geliştirmesi donanım uzmanları tarafından
yapılırken, yazılım uzmanları da uygun modellere göre önce
altyapı yazılımını sonra da uygulama yazılımlarını geliştirirler.
 Uygulama yazılımlarını tam olarak gruplandırmak, günümüzde
her türlü alanda yazılım geliştirildiği için oldukça güçtür.

29
Ancak kullanım alanlarına göre yazılımları gruplandırabiliriz:
o Özel Sistem Yazılımları
o Kişisel Bilgisayar Yazılımları
o İş Dünyası Yazılımları
o Mühendislik Yazılımları
o Bilimsel Yazılımlar
o Yapay Zeka Yazılımları
o Veritabanı Yönetim Sistemi Yazılımları
o İnternet Yazılımları
o Ar-Ge Yazılımları

30
 En klasik bilgi işleme yöntemi tek bir bilgisayar işlemcisi
üzerinde bir tek programa ilişkin ifadelerin ardışık olarak
yürütülmesi esasına dayanır.
 Günümüzdeki pek çok işletim sistemi ise artık birden fazla
programı beraberce çalıştırabilmektedir. Aynı bilgisayarda
birden fazla işlemci kullanılarak gerçek anlamda eşzamanlı
çalışma olanağı da sağlanmaktadır.

31
 Bir bilgisayar programında bilgi işleme yapabilen elemanlar
birer çalıştırma bağı, diğer adıyla iş parçacığı (execution
thread) ya da görev yürütürler.
 Bu görevlerin aynı işlemci üzerinde yürütülmesi ile paralellik ya
da koşutzamanlılık (concurrency), farklı bilgisayarlar üzerinde
yürütülmeleri ile de dağıtılmışlık (distribution) sağlanır.
 Uçbirimlerin birer operatör değil de ana sistemin etkileşimde
bulunduğu birer altsistem olmaları durumunda, merkezi
(central) ve dağıtık (distributed) olmak üzere iki farklı bilgi
işleme tipi ortaya çıkmıştır.

32
Merkezi Bilgi İşleme
 Bir tek bilgisayar tarafından her türlü hizmetin verilmesine dayanır.
 Hizmetler birer işletmen tarafından alınabileceği gibi birer altsistem tarafından da
alınabilir.
 Bu durumda ana bilgisayar zaman paylaşımlı olarak tüm istemcilere yanıt verir. Ana
bilgisayarda bulunan işlem birimlerinin sayısına göre tek işlemcili ve çok işlemcili
sistemler olarak ikiye ayrılır.
Süreçler Süreçler

Anakart
İşlemciler
Giriş-Çıkış
Kartları

33
Tek İşlemcili Sistem Çok İşlemcili Sistem
Dağıtık Bilgi İşleme
 Bazı yazılımlar üzerlerinde çalıştıkları bilgisayarların işlem
güçlerinden daha fazla yararlanabilmek için koşut zamanlı
(concurrent) olarak çalışmak üzere tasarlanmıştır.
 Dağıtık çalışmada temel ilke; problemi çok sayıda küçük
parçalara bölerek her birini farklı bilgisayar düğümlerinde
paralel olarak çalıştırarak daha çabuk sonuç almaktır.
 Dağıtık bilgisayarlar bir yerel alan şebekesi üzerinde
çalışıyorlarsa gevşek bağlı (loosely-coupled), aynı donanımı
paylaşan işlemciler şeklinde ise sıkı bağlı (tightly-coupled)
olarak adlandırılırlar. Her iki durumda da iş yapan süreçler
ve veriler işlemciler arasında paylaştırılırlar.

34
Paralel Bilgi İşleme
 Günümüzün ve geleceğin bilgisayar otomasyonu beklentileri
çok sayıda görevin paralel olarak yürütülmesini
gerektirmektedir. Bazı özel durumlar hariç bilgisayar
yazılımları paralel bilgi işlemeyi destekler. Bunun için
mikroişlemci üzerinde, işletim sistemi yanında, birden fazla
yazılım birimi yani süreç (process) yürütülür.
 Tek bir mikroişlemcinin gerçek anlamda paralel çalışması
mümkün değildir ancak bazı süreçler giriş/çıkış için beklerken
diğer hazır olan süreçlerin işlemciyi kullanması yoluyla bir tür
paralel çalışma elde edilebilir.
 En iyi paralel çalışma birden fazla işlemci veya bilgisayar
üzerinde farklı süreçlerin aynı anda yürütülmesi ile elde edilir.
35
 Bilgisayar ilk çıktığı zamanlarda yazılım ancak tek bir işlemci
üzerinde çalışmaktaydı.
 Daha sonra ana çatı (mainframe) bilgisayarları çok sayıda
kişiye aynı anda hizmet verebilmeye başladı. Bu
bilgisayarlarda birden fazla yazılım tek bir ana bilgisayarda
zaman paylaşımlı olarak koşmakta ve kullanıcılara
koşutzamanlı çalışma olanağı sağlamaktaydı.
 Bundan sonra paylaşılır diskler ve dizinlerden oluşan
mimariler kullanıldı. Bu mimarilerde yazılımlar kullanıcıların
kendi bilgisayarlarında çalışmakta ve bir ağ üzerinden ortak
olarak eriştikleri dosyaları (kütükleri) paylaşmaktaydı.

36
Günümüzde daha esnek ve yüksek başarım sağlayan çeşitli
mimariler kullanılmaktadır. Bunlar:
o Genel Yazılım Mimarisi
o İstemci – Sunucu (client-server) Mimarileri
• İki Katmanlı Mimari
• Üç Katmanlı Mimari
o Dağıtık Mimariler
o Yazılım Birimleri
• Kullanıcı Arayüz Yazılım Birimleri
• Bilgi İşleme Yazılım Birimleri
• Altsistem Arayüz Yazılım Birimleridir.

37
Genel Yazılım Mimarisi
Uygulama yazılımlarının düzeyi dikkate alınarak sistem yazılım
mimarisi üçe ayrılabilir.
Uygulama Yazılımı

Uygulama Yazılımı Ara Katman Yazılımı

Uygulama Yazılımı İşletim Sistemi İşletim Sistemi

Donanım Donanım Donanım

(a) (b) (c)

Doğrudan Çalıştırma Basit Mimari Karmaşık Mimari
38
Doğrudan Çalıştırma
 En basit mimari doğrudan donanım üzerinde çalışan ve
yalnızca makine kodundan oluşan uygulama yazılımıdır.
 Bu tür yazılımlar daha çok gömülü sistemler üzerinde
bulunurlar. Bir yonga içine gömülü firmware yazılımları bu
özelliktedir. EPROM içinde saklanan çamaşır makinesi
programı, mikrodalga fırın programı bunlara örnektir.
 Cihaz açıldığında uygulama yazılımı mikroişlemci üzerinde
çalışmaya başlar ve girdilere göre gerekli işleri yapar.

39
Basit Mimari
 Bilgisayar üzerinde belirli süreçlerin eşgüdüm içinde
yürütülmesi, sistem özkaynaklarının iyi denetlenmesi ve
çeşitli giriş/çıkış işlemleri isteniyorsa amaca uygun bir
işletim sistemi seçilir ve uygulama yazılımı bu işletim sistemi
üzerinde çalıştırılır.
Karmaşık Mimari
 Uygulama yazılımını çeşitli geliştirme ve bakım kolaylıkları
nedeniyle bir ara katman yazılımı ile alttaki işletim sistemi
ve donanımdan ayırmak, geliştirme ve işletim bakımından
çok yararlı olmaktadır.

40
İstemci – Sunucu (Client-Server) Mimarileri
 Ağ üzerinde haberleşen bilgisayarlardan oluşan dağıtık bilgi işleme
ortamlarının yaygınlaşmasıyla istemci-sunucu mimarileri de yaygın
hale gelmiştir. İstemci-sunucu mimarisi yazılıma özgü olduğu için
ister merkezi, ister dağıtık ortamda olsun donanımdan bağımsız
olarak kolaylıkla uygulanabilir.
 İstemci ve sunucu arasındaki veri iletişimi ve denetim genellikle iki
parçalı olarak geliştirilen ayrık yazılım bileşenleri ile sağlanır.

İstemci

Sunucu istek
İstemci

İstemci
Veritabanı 41
İstemci-Sunucu mimarilerinin üç temel yazılım bileşeni bulunur:
İstemci:
 Belirli bir isteği istemciden alıp sunucuya gönderen, sonra da
yanıtı alıp tekrar istemciye veren bileşendir.
 Genel olarak ayrı bir bilgisayar ya da uçbirim iş istasyonu
üzerinde çalışır.
 İstemci, bir insan olabileceği gibi başka bir yazılım da olabilir.
İstemci, kullanıcıdan gelen isteği oluşturan verilerin
doğrulanması, sonra da bu isteğin belirli iletiler halinde
sunucuya gönderilmesini sağlar.

42
Sunucu:
 Bir ya da daha fazla istemci tarafından gönderilen istekleri
yerine getirerek sonuçlarını geri gönderen yazılım
bileşenidir.
 Sunucu yazılımı genelde iş yapmadan istemciden istek
gelmesini bekler, gelen isteğe yanıt verir ve tekrar
beklemeye başlar.
 Sunucular görevlerine göre birkaç çeşit olabilir:
o Dosya sunucuları
o Ağ sunucuları
o Veritabanı sunucuları
o Web sunucuları
o Servis sunucuları

43
İşlem Yönetimi:
 Bir kısım sunucular ara-işlemler (transaction) ile
kullanıcıların isteklerini karşılarlar.
 Ara-işlemlerin en büyük yararı işlemin tamamının güven
içinde başlanıp bitirilmesidir.
 Hem istemci hem sunucu tarafında özel işlevleri olan ara-
işlem yöneticileri kullanılır.
 İstemciden bu yöneticiye gelen istekler işlemin kesilmeden
tamamlanması için gerekli önlemler alınarak sunucuya
gönderilir ve yanıt alındıktan sonra istemciye iletilir.
 İşlem yönetimi her uygulama için değişik olduğu için
uygulama mantığı adını alır.

44
İki Katmanlı (two-tier) Mimari
 İki katmanlı mimaride (two-tier) istemci sunucu mimarisinde bulunan üç
yazılım bileşeni iki katman üzerinde çalışır.
 Kullanıcı arayüzü ile ara-işlem yönetiminin bir kısmı birinci katmanda, yani
istemci bilgisayar üstünde, veritabanı yönetim sistemi ile ara-işlem
yönetiminin diğer kısmı da ikinci katmanda, yani sunucu bilgisayar
üzerinde bulunur.
 Bu mimaride işletim mantığı sunucu üzerinde olduğundan başka
sunucularla birlikte çalışırlık özelliği biraz düşüktür.
 İstemci ile sunucu arasında oluşan iletişim trafiği yüksek sayıda istemciyi
desteklemez. Yapılan her değişikliğin tüm kullanıcılara uygulanması gerekli
olduğundan bakımı kolay değildir.
İstemci İstemci İstemci İstemci İstemci

Sunucu Sunucu Sunucu

45
Üç Katmanlı (three-tier) Mimari
 Üç katmanlı (three-tier) mimaride üç yazılım bileşeni de üç ayrı katman
üzerinde bulunur.
 Kullanıcı arayüzü istemci bilgisayar üzerinde ve sunucudan bağımsız
olarak çalışır. İşlem yönetimi ayrı bir bilgisayar üzerinde bulunur ve asıl
veritabanı sunucusuna erişebilen bir uygulama sunucusu olarak görev
yapar.
 Bu mimaride kullanıcı, veritabanından tamamen bağımsız olup uygulama
sunucusu ile haberleşir, isteklerini ona iletir ve ondan yanıt alır.
 Uygulama sunucusu tüm mantığı üzerinde barındırır, veritabanı ile iletişim
kurar.
 Arayüz değişmedikçe uygulama sunucusu üzerinde yapılan değişiklikler
kullanıcıyı etkilemez.
 Benzer şekilde veritabanı da yalnızca verilerle ilgilenir, uygulama
mantığını içermez.
 Bu şekilde ayrık yapılanma ile bakım kolaylığı, genişleyebilirlik ve ortak
çalışabilirlik özellikleri artar.
46
 Üç katmanlı mimariler işlemlerin güvenilir şekilde yapılmasına
olanak sağlarken çok sayıda kullanıcıyı sorunsuzca
destekleyebilirler.
 Geliştirme ve test daha karmaşık, ancak bakım kolaydır.

İstemci İstemci İstemci İstemci İstemci

İşlem İşlem İşlem

Yönetimi Yönetimi Yönetimi

Sunucu Sunucu Sunucu Sunucu Sunucu

47
Dağıtık Mimariler
 Dağıtık geliştirilen yazılımlarda belirli bir istemci ya da sunucu
mantığı yoktur, ancak iletişimi kolaylaştırmak ve güvenilir hale
getirmek için genellikle bir ara katman kullanılır.
 Dağıtık yapı ile daha ucuz ve düşük özellikteki bilgisayarlar ile
toplamda daha yüksek bilgi işleme gücü elde edilir.
 Ağ üzerindeki her düğüm ayrı bir özkaynaktır, herhangi bir
düğümde koşan yazılım tarafından kolaylıkla erişilebilir.
 Bir düğümdeki yazılım birimleri diğer düğümlerdekilerle
haberleşerek gerçek anlamda koşutzamanlı, yani paralel çalışma
sağlarlar.
 Uygulamaların dağıtık çalışmak üzere tasarlanması ve
gerçekleştirilmesi gereklidir.
 Son zamanlarda bu alanda yapılan araştırmalar ile dağıtık veri
tabanları, dağıtık işletim sistemleri, programlama dilleri ve yürütme
ortamları geliştirilmektedir.
48
 Dağıtık mimari ile herhangi bir düğümde oluşan hata diğer
düğümlerdeki yazılım sistemini değil yalnızca o
düğümdekini etkiler.
 Düğümün tamamen devre dışı kalması halinde süreçler
sağlam düğümlere göç ettirilebilirler.
 Genel olarak daha esnek bir yapıya sahip olduklarından
rahatlıkla büyüme veya küçülme yapılabilir.

49
Yazılım Birimi Türleri
Orta ve büyük ölçekteki uygulama yazılımlarını, çeşitli yazılım
birimi türlerinin yardımıyla oluşturmak mümkündür.
Kullanıcı Arayüz Yazılım Birimleri

Hazır Ticari Paket

Bilgi İşleme Yazılım Birimleri
Yazılımlar

Altsistem Arayüz Yazılım Birimleri

Kullanıcı Arayüz Sistem Altsistem

Donanımı Donanımı Donanımı
50
Kullanıcı Arayüz Yazılım Birimleri:
 Genellikle grafik tabanlı olup kolay kullanıma olanak sağlayacak sergileme
ve kontrol menülerinden oluşur.
 Bu birimlerden oluşan arayüz katmanı, kullanıcı arayüz donanımlarını
(ekran, klavye, mouse, vb.) denetim altında tutarak sistemin insan ile
etkileşimini sağlar.
 Bilgi işleme birimlerine veri ve komut göndererek sistemin mantığını işletir,
gelen sonuçları sergiler.
 Ayrıca altsistem arayüz yazılım birimleri ile haberleşerek altsistemlere
kullanıcı isteklerini iletir.
 Bazen de hazır ticari yazılımları doğrudan kullanmak üzere arayüz
sağlarlar.
 Bir sistemdeki kullanıcı arayüz yazılım birimlerinin sayısı kullanıcı sayısı
kadar olmalı ve bağımsız çalışabilmelidirler.
 Bu birimler görsel niteliği yüksek ekranlar ve kullanıcı giriş/çıkış aygıtlarına
sahip bilgisayarlar üzerinde bulunmalıdır.

51
Bilgi İşleme Yazılım Birimleri:
 Sistemler bilgi işleme amacıyla geliştirilirler.
 İşlenecek bilgi dış dünyadan çeşitli şekillerde alınır, sistem
içinde çeşitli akışlardan geçer, gerekirse geçici veya kalıcı
olarak depolanır, üzerinde algoritmalar çalıştırılarak başka
bilgilere dönüştürülür ve çıktı olarak yine dış dünyaya verilir.
 Bilgi işleme, sistemde en az bir kopyası sürekli çalışan bir ya
da daha fazla yazılım birimi tarafından gerçekleştirilir.
 Bilgi işleme yazılım birimleri, sabit disk, yardımcı bellek veya
saklama birimleri gibi sistem donanımları ile iletişim halinde
olabilirler.
 Bu birimler, yüksek işlemci gücüne sahip bilgisayarlar
üzerinde koşmalıdırlar.
52
Altsistem Arayüz Yazılım Birimleri:
 Altsistemlerin bilgisayarla iletişimini sağlamak için üreticisinin
sağladığı donanım ve veri arayüzünün bilinmesi, ona uygun iletişim
protokolü dikkate alınarak yazılım geliştirilmesi gerekmektedir.
 Sistem geliştiricisi ile altsistemin üreticisi arasında bu tür bilgileri
içeren teknik anlaşmaya uygun arayüz yazılımı geliştirilir.
 Bu birimler, gerek bilgi işleme yazılım birimlerinden gerekse kullanıcı
arayüzü yazılım birimlerinden aldıkları verileri biçim dönüşümü
yaparak altsisteme aktarırlar; altsistemden gelen verileri de gerekli
dönüşümden geçirerek uygun bir şekilde ana sisteme aktarırlar, yani
altsistemi tümleştirirler (integration).
 Altsistem arayüz yazılım birimleri her altsistem için ayrı bir bilgisayar
üzerinde koşabileceği gibi bir bilgisayar üzerinde bir yada daha fazla
altsistemin tümleştirilmesi mümkündür. 53
 
● Temel varsayımlar
– İyi bir yazılım istiyorsak süreci iyi yönetmeliyiz
– İyi bir süreç yönetimi riskleri azaltır
● Risk yönetimi
– Bir yazılım projesinde neler yanlış gidebilir?
– Risk nasıl azaltılabilir?

2

●
Bir yazılım süreci, bir yazılım ürünü ortaya çıkarmak için
yapılması gereken, birbiri ile ilişkili işlemler bütünüdür.

●
Yazılım süreçleri farklılıklar gösterebilir ancak temel olarak dört
işi içermelidir:
– Yazılımı tanımlama (software specification) - Yazılımın ne
yapacağı, kısıtları tanımlanmalıdır.
– Yazılım tasarımı ve gerçekleştirim (software design and
implementation) – Yazılım, tanımına uygun olarak üretilmelidir.
– Yazılımın doğrulanması (software validation) – Yazılımın müşterinin
isteklerini karşılayabildiği doğrulanmalıdır.
– Yazılımın evrimi (software evolution) – Yazılım müşterinin değişen
ihtiyaçlarına cevap verecek şekilde değiştirilebilmelidir.

3
●
Süreci sadece veri modeli belirleme, kullanıcı
arayüzü tasarımı gibi aktiviteler içermez
●
Süreç şunları da içerebilir:
– Ürünler
– Roller
– Ön ve son koşullar

4
Uygunluk
analizi ve
planlama Gereksinimler

Tasarım

Gerçekleştirim İşletim ve Bakım

5
 Kaos (Herhangi bir modelin uygulanmadığı o dönem)
 Şelale (WaterFall) yazılım geliştirme modeli
 Artırımsal (Incremental) ve tekrar işlemeli (Iteratif) yazılım
geliştirme modeli
 Yalın yazılım geliştirme modeli
 Re-use (tekrar kullanımlı) yazılım geliştirme modeli
 Prototip yazılım geliştirme modeli
 Test güdümlü yazılım geliştirme modeli
 Temiz oda yazılım geliştirme modeli
 Yazılım kalite unsurları
 Kaos (Herhangi Bir Modelin Uygulanmadığı Dönem)
Herhangi bir metot veya model uygulanmayan zamanlardır. Kovboy
kodlaması da denilir.
Aşağıda herhangi bir modelin uygulanmadığı sorunlu bir proje örneği
verdik:
o Projede tutarlı dokümanlar hazırlanmamaktadır.
o Önce tüm yazılım kodlanır sonra hatalar düzeltilmeye çalışılır. Sistem
giderek bir canavara benzer.
o Bakım maliyetleri her geçen gün artar, yeni yazılımcılar sisteme
dokunmaya korkarlar.
o Kod taşınabilir değildir.
o Başarı bireylere bağlıdır, bireyler ayrılınca başarı dramatik biçimde düşer.
o Donanım seçimi iyi yapılmamıştır ve donanım ile yazılım iyi uyuşmamıştır,
donanım genelde büyüyen yazılıma dar gelir.
o Yanlış seçilen algoritmalar vardır ve geri dönülememektedir.
 Kaos (Herhangi Bir Modelin Uygulanmadığı Dönem) (devam)
o Yazılımda birkaç dil birden kullanılmıştır ve makine dili ile üretilen kod
bölgelerini kimse anlamamaktadır.
o Yazılım kurnaz yazılım numaraları ile doludur ve kısa bir alanı anlamak
saatleri ve hatta günleri almaktadır.
o Yazılım hala devam etmekteyse ne zaman biteceğini hiç kimse
bilmemektedir ve projeye sürekli adam alınmaktadır veya adamlar
ayrılmaktadır. Bu yüksek adam değişim oranı yüzünden projeye hakim
pek fazla adam kalmamıştır.
o Donanımcılar yazılımcıları ve yazılımcılar donanımcıları suçlamaktadırlar.
o Sistemin bir bölümü çalışmakta bir bölümü çalışmamaktadır. Önemli
bölümleri çalışmadığı halde ekip çok önemsiz ama müşterinin istediği
bir bölümde zaman kaybetmektedir.
o Projenin iptali bile gündemdedir.
 Şelale (WaterFall) Yazılım Geliştirme Modeli
o Şelale yazılım geliştirme modeli en klasik yazılım geliştirme modelidir.
o Bu modelde yazılım geliştirme işlemi kesin safhalara ayrılmıştır. Bu
safhalar kabaca aşağıdaki gibidir:
• Gereksinimlerin toplanması aşaması,
• Tasarım aşaması,
• Gerçekleştirme aşaması,
• Doğrulama aşaması,
• Bakım aşaması
o Genellikle yukarıdaki safhalar için önceden tahmini süreler belirlenir ve bu
sürelere sıkıca uyulmaya çalışılır.
o Şelale geliştirme modelinin en önemli özelliği safhaların ardarda
uygulanması ve bir safha bitmeden bir sonraki safhaya geçilmemesidir.
o Şu an gerçekleştirilen safhadan önceki safhalara da bu safhalar
tamamlanmış kabul edildiğinden normal koşullarda pek geri dönülmez.
o Her aşamada yoğun olarak dokümantasyon yazılır ve hatta bu
dokümantasyonlar safha geçişlerini belirler.
 Şelale (WaterFall) Yazılım Geliştirme Modeli (devam)
Şelale geliştirme modelinin aşamalarını biraz daha detaylı inceleyelim:
o Gereksinimlerin toplanması aşaması: Bu aşamada problem tanımlanır veya
kullanıcı isteği analiz edilir ve ilgili gereksinimler doküman olarak oluşturulur. Bu
aşamada müşteri veya kullanıcı ile işbirliği yapılır ve bir sözleşme mahiyetindeki
gereksinim ortaya çıkarılır. Bu gereksinim dokümanı diğer safhalar için bir ana
kurallar dizisi olarak oluşur ve bütün aşamalarda içindeki gereksinim maddelerine
aykırı bir şey olmadığı, çalışmaların bu gereksinimleri sağladığı teyit edilir.
o Tasarım aşaması: Bu aşamada detaylı bir tasarım yapılır. Tasarımın her biriminin
gereksinimlere uygunluğu kontrol edilir. Genelde herhangi bir kod yazılmaz. İleriki
aşamalarda bu tasarıma sıkıca uyulur.
o Gerçekleştirme aşaması: Kodlama bu aşamada yapılır. Yazılan kodların birim testleri
de bu aşamada yapılır. Yine her aşamada olduğu gibi gereksinimlerin sağlandığı
kontrol edilir.
o Doğrulama aşaması: Bu aşamada detaylı test dokümanları yazılır ve bu
dokümanlara göre testler yapılır. Her testin hangi gereksinimin gerçekleştiğini test
ettiği izleme matrisi denilen tablolar ile test dokümanlarında bulunur. Modüller birbiri
ile entegre edilir, karakutu ve saha testleri yapılır.
o Bakım aşaması: Bu aşamada sistem kullanıcının emrine verilmiştir ve bu sırada
oluşacak olan problemler giderilir.
 Şelale (WaterFall) Yazılım Geliştirme Modeli (devam)

Gereksinim
Toplanması

Tasarım

Gerçekleme

Doğrulama
(Test)

Bakım
 Şelale (WaterFall) Yazılım Geliştirme Modeli (devam)
 Şelale Yönteminin Avantaj ve Dezavantajları
o Şelale yöntemi yazılım geliştirmede düzenliliği teşvik eden bir modeldir ve eskiden
yazılım projelerinin kabusu olan kaos ortamının giderilmesinde büyük rol oynamıştır.
o Özellikle ciddi ve büyük projelerde düzen, dokümantasyon, detaylı tasarım yönlerinden
kendini kanıtlamış bir modeldir.
o Ancak sonraları modelin sorunları ve dezavantajları olduğu keşfedilmiş ve yeni model
arayışlarına gidilmiştir.
o Bu dezavantajlara değinecek olursak:
• Bir safha tamamlanmadan diğer safhaya geçilemediğinden bir safhada problem
oluştuğu ve o safha uzadığı zaman projelerin süresinin çok uzayabildiği görülür.
Özellikle gereksinimlerin toplanması veya hazırlık safhasında bir hayli zaman
kaybedilebilir.
• Safhalarda daha önce yapılmış safhalarla geçiş kuralları (örneğin eksik kalan işler
için geri dönmek gerekebilir) olmadığı için ya hiç geri bakılmaz ve önceki hatalar
düzeltilemez ya da geriye dönülür ve birçok iş zincirleme olarak büyük emeklerle
düzeltilir. Örneğin müşteri gereksinimi değiştiği zaman geri dönülmesi demek bu
tüm döngünün yeniden geçilmesi demektir.
• Oluşan hatalar tüm döngü boyunca her safhada tekrarlanacağı için özellikle
gereksinimlerde oluşan hatanın sisteme maliyeti çok yüksek olur.
• Tüm gereksinimlerin bir anda toplanması pratik değildir, ya bir şeyler eksik kalır ya
da belirsiz eksik gereksinimler ile sistemin güvenilirliği azalır.
• Müşteri geribeslemesi sadece proje başında yoğun olduğu için nihai ürünün
müşterinin isteğini karşılamaması riski büyüktür.
 Artırımsal (Incremental) ve Tekrar İşlemeli (Iteratif) Yazılım
Geliştirme Modeli
 Artırımsal (Incremental) ve Tekrar İşlemeli (Iteratif) Yazılım
Geliştirme Modeli
 Artırımsal (Incremental) ve Tekrar İşlemeli (Iteratif) Yazılım
Geliştirme Modeli
o Uzun ve kuralcı üretim safhaları olan Şelale (Waterfall) yönteminin
dezavantajları görülünce buna alternatif arayışları ortaya çıktı.
o Bu yüzden artırımsal ve tekrar işlemeli yazılım geliştirme yöntem grubu
ve bir takım alt sınıfları belirdi.
o Öncelikle geriye bir bakacak olursak Şelale yönteminin ana sıkıntısı
şudur:
• Şelale modelinde planlama, gerçekleştirim ve test safhaları sadece bir kez
yapılır ve bu süre çok uzundur, sonuçta herhangi bir sorun çıktığında geri
dönüp bunu telafi etmek mümkün olmaz veya maliyeti çok fazla olur.
• Şelale yöntemi en başta tahmin ve planlamaya dayalıdır, bu yüzden proje
başladıktan sonra değişiklik kararları almak çok zordur.
 Artırımsal (Incremental) ve Tekrar İşlemeli (Iteratif) Yazılım
Geliştirme Modeli (devam)
o Bu sorunu aşabilmek için temel olarak iki öneri yapılabilir:
• Safhaları kısa tutarak bir kaç kez tekrar etmek ve her döngüde yeni
özellikler eklemek (Artırımsal (Incremental) yazdım geliştirme)
• Proje planlarmı esnek, değiştirilebilir hazırlayıp proje esnasırtda
sürekli iyileştirmelere imkân tanımak (Tekrar İşlemeli (Iteratif)
yazdım geliştirme)
o Artırımsal ve Tekrar İşlemeli Yazılım Geliştirme Modelinin birçok değişik
yorumu ve uygulama örneği ya da diğer bir değişle alt modelleri
çıkmıştır.
o Bu alt modellerin her biri ana olarak bu iki kurala (yani Artırımsal
Geliştirme ve Tekrar İşlemeli Geliştirme kurallarına) uymakla beraber
kendi kurallarını ve çözüm önerilerini de getirmişlerdir. İlerleyen
kısımlarda bu alt modelleri inceleyeceğiz.
"Acaba ne zaman artırımsal geliştirme yöntemini kullanmalı? Artırımsal
geliştirme modelini sadece başarılı olmak istediğiniz projelerde
kullanmalısınız."
Martin Fowler – Extreme Programing'in Yaratıcısı
 Spiral Yazılım Geliştirme Modeli
o Şelale modeline en yakın fakat artırımsal olan yazılım geliştirme modeli
Spiral yazılım geliştirme modelidir.
o Spiral yazılım geliştirme modeli “prototip yazılım geliştirme modeli” ile
“şelale yazılım geliştirme modeli’nin her ikisinin de özelliklerini taşır.
o Şelale modelinden en önemli farkı bir tek döngü yerine birçok döngüden
oluşmasıdır.
o Spiral model ilk olarak Barry Boehm tarafından 1988’de önerilmiştir.
 Spiral Yazılım Geliştirme Modeli (devam)
o Spiral yazılım geliştirme modelindeki adımlar aşağıdaki gibi sıralanabilirler:
1. Yeni üretilecek sistemin gereksinimleri mümkün olan en detaylı biçimde planlanır. Bu
genellikle dış ve iç müşterilerin temsilcileri ve halihazırda bir sistem varsa onu inceleyerek
yapılır.
2. Yeni üretilecek sistem için bir ön tasarım hazırlanır.
3. Ön tasarımdan faydalanılarak yeni sistem için ilk prototip hazırlanır. Bu genellikle daha az
yetenekli ve nihai ürünün özelliklerini sadece kabaca taşıyan bir sistemdir.
4. Daha sonra ikinci bir prototipin yapılması için şu işlemler yapılır:
a. İlk prototip kuvvetli ve zayıf yönlerine göre, risklerine göre, incelenir
b. İkinci prototip için gereksinimler belirlenir,
c. İkinci prototip planlanır ve tasarlanır,
d. İkinci prototip üretilir.
5. Bu aşamada artık risk faktörleri rahatça belirlenebilir. Bütçe aşımlarının olup olmayacağı,
işletim giderlerinin miktarı, vb faktörler hesaplanır ve müşteri bu risk faktörlerine göre devam
etmeye veya projeyi sonlandırmaya karar verebilir.
6. Üretilmiş olan prototip bir önceki prototip gibi incelenir ve gerekliyse bir başka prototipin
daha yapımı için işe başlanır.
7. Böylece ürün tatmin edici oluncaya kadar yeni prototiplere devam edilir, müşteri üründen
memnun olunca bu prototip nihai ürün kabul edilir.
8. Son prototipe göre nihai ürün üretilir.

Üretilen ürün detaylıca test edilir.

 Spiral Yazılım Geliştirme Modeli
 Çevik (Agile) Yazılım Geliştirme Modeli
o Uzun ve kuralcı üretim safhaları olan Şelale (Waterfall) yönteminin
dezavantajları görülünce buna alternatif arayışları ortaya çıktı.
o Karşılaştırma yapabilmek için öncelikle Şelale yönteminin
dezavantajlarını kısaca hatırlayacak olursak:
• Şelale modeli yoğun planlama gerektiren bir yöntemdir,
• Planlamanın yoğun olması dokümantasyonun da yoğun olmasına yol
açar,
• Şelale modeli büyük ölçüde tahmin ağırlıklı bir yöntemdir,
• Şelale modelinin safhaları uzun olduğu için ve kontratlar
düzenlendiği için kolayca değişimle gidilemez.
 Çevik (Agile) Yazılım Geliştirme Modeli (devam)
o Diyelim ki bu dezavantajları yenmek istiyoruz ama bu değişimin yan
etkilerinden etkilenmek de istemiyoruz.
o Bu durumda yapılacak işlemler ve yan etkilerden kaçınma önlemleri
şöyle olabilir:
• Uzun vadeli planlamadan kurtulalım, ancak yan etkiden kaçınmak için:
• Değişikliklere çabuk tepki verebilmeliyiz.
• Ağır dokümantasyonu hafifletelim ancak bilgi kaybına uğramamak için:
• Her safhada (tam fonksiyonel olmasa da) çalışan, sağlıklı bir kod
bulundurmalıyız,
• Katı kontratlardan kurtulalım, ancak bu sırada zarara uğramamak için:
• Müşterilerle sürekli iletişim içinde olmalıyız
• Katı süreçlerden kurtulalım ancak bu arada bilgi akışım ve birikimini
devam ettirebilmek için:
• Geliştiriciler arası iletişimi maksimumda tutmalıyız.
 Çevik (Agile) Yazılım Geliştirme Modeli (devam)
o İşte birlikte kolayca hazırladığımız yukarıdaki çıkarımlar aslında Çevik
Yazılım Geliştirme Modelinin esaslarıdır. Bu esasları yazdım
literatüründeki resmi söylemi ile aktarırsak:
“Biz yazılım geliştirmenin daha iyi yöntemlerini bizzat uygulayarak veya
başkalarının uygulamasına yardımcı olarak gün yüzüne çıkarıyoruz. Bu
çaba sonucunda bizim için:
o Bireyler ve etkileşimler, süreçlerden ve gereçlerden,
o Çalışan yazılım, kapsamlı dokümantasyondan,
o Müşteri katılımı, kontrat pazarlıklarından,
o Değişime çabuk tepki verebilmek, bir plan izlemekten daha değerlidir.

Şöyle ki, “Yukarıdaki maddelerin sağ tarafında yazılı olan öğeler değerlidir
ancak sol taraftaki öğeler daha çok değerlidir.”
 Çevik (Agile) Yazılım Geliştirme Modeli (devam)
o Birçok sorunu çözmesine rağmen Çevik Programlamanın dezavantajları
da vardır:
• Yanlış uygulandığı zaman yani çeviklik kavramı yanlış anlaşıldığı zaman
personelin tükenmesi (Employee burnout) dediğimiz yan etkiyi doğurur.
• Ekip liderine çok fazla sorumluluk ve güç verildiğinde bu hem ekip liderini
hem de ekip üyelerini yıpratabilir.
• Çevik programlamanın her türlü yazılım problemini çözeceği
düşünüldüğünde hayal kırıklıklarına yol açar.
• Çevik programlama yazılım geliştiricilerin ve takımın disiplinli, düzenli ve
tecrübeli olmasını tercih eder dolayısıyla buna hazır olmayan
organizasyonlar, takımlar ve geliştiriciler için uygun değildir.
• Dokümantasyon tamamen ihmal edilebilir ve bunun sonuçları kötü olabilir.
• Büyük projelerde çok uygun değildir.
 Uç (Extreme) Programlama Yazılım Geliştirme Modeli
o Artırımsal programlamanın birçok alt tipi veya uygulaması vardır.
o Bunlardan biri de Uç Programlama (Extreme Programming) yazılım
geliştirme modelidir.
o Şelale yönteminin dezavantajlarından kaçınan bir yöntem olan Çevik
(Agile) Programlamadan bahsetmiştik.
o Uç Programlama (Extreme Programming) bunu iyice öteye taşır.
o Şelale yönteminin dezavantajlarından büyük ölçüde kaçınır ve yan
etkilere uğramamak için radikal önlemler alır.
 Uç (Extreme) Programlama Yazılım Geliştirme Modeli (devam)
o Çiftler halinde (Pair) programlama: Hız sağlar, uzun vadeli planlama eksiğini
doğru tasarım ve kod ile kapatır,
o Kod gözden geçirme toplantıları: Uzun vadeli planlama eksiğini doğru
tasarım ve kod ile kapatır,
o Tüm kod için birim testler: Uzun vadeli planlama eksiğini doğru kod ile
kapatır,
o Gerçekten gerekmedikçe özellik eklememek: Sadelik sayesinde değişime
ayak uydurmak için,
o Yatay yönetim şekli: Hız kazandırır,
o Kodda basitlik ve açıklık: Sadelik sayesinde değişime ayak uydurmak için,
o Müşteri değişikliklerine hoşgörü: Uzun vadeli planlama eksiğini kapatır,
o Müşteri ile iyi iletişim: Uzun vadeli planlama eksiğini kapatır,
o Programcılar arasında iyi iletişim: Hız kazandırır.
 Uç (Extreme) Programlama Yazılım Geliştirme Modeli (devam)
o Uç programlamanın ana özelliklerini sıralayacak olursak:
• Basitlik: Gerekli değişikliklere kolay ayak uydurabilmek için,
• Geri besleme: Gerekli değişiklikleri zamanında edinebilmek için,
• Cesaret: Kodda gerekli değişiklikleri yapabilmek için,
• Saygı: Uyumlu çalışma ortamım sağlamak için.
 Uç (Extreme) Programlama Yazılım Geliştirme Modeli (devam)
o Uç programlamanın eleştirilen yönleri de vardır:
• Uç programlama ile 10 kişinin altındaki ekiplerde verimli sonuçlar elde edilirken büyük
ekiplerde ve projelerde planlama eksiğinden dolayı kötü sonuçlar verebilmektedir.
Üstelik toplam kalite kurallarına göre mutlaka hazırlanması gereken dokümanlar “Biz Uç
Programlama yapıyoruz” mazereti altında yazılmamakta; ihmaller veya suistimaller
olabilmektedir.
• Uzun vadeli planlama yapılmadığı için hedef sapmaları, koda eklenmiş gereksiz özellikler
rahatlıkla oluşabilmektedir,
• Uç Programlamanın sürekli iletişim ve hatta sözlü iletişim gerektiren çalışma biçimine
(çok kaliteli yazılımcılar olsalar bile) herkes ayak uyduramamaktadır. Üstelik ekipteki
herkesin iyi anlaşamaması da olası bir durumdur,
• Sadece kısa vadeli planların olduğu bu ortamda gerçekten tecrübeli programcılar
gerekmektedir,
• Müşteri ile kontrat sorunları ve çıkan ürün özellikleri üzerinde sonradan sorunlar
çıkabilmektedir,
• Ana özelliklerden olan müşteri katılımı her zaman mümkün olmamaktadır,
• Uzun vadeli detaylı planlama olmadığı için proje tahminleri zorlaşmaktadır,
• Uç Programlama özellik ekleme temelli olduğu için görünür özellikler arasında olmayan
ama altyapı için gerekli olan önemli bazı proje yetenekleri kaçırılabilmektedir (Örneğin
gömülü bir projeye alelacele makine dili ile başlayıp zaman geçtikçe aslında işletim
sistemi ve yüksek seviyeli bir dil gerektiği gerçeği ile karşılaşmak gibi.)
 Uç (Extreme) Programlama Yazılım Geliştirme Modeli (devam)
o Uç Programlamanın en belirgin özelliği kısa iterasyonlara sahip olması ve hemen
her zaman çalışan bir sistemin (basit ve özelliksiz bile olsa) paydaşlara
sunulabilmesidir.
o Bu şekilde bir çalıştırılabilir programın olması, projenin gidişatının sürekli kontrol
altında tutulabilmesini sağlar. Oysa klasik yöntem olan şelale modelinde, son ana
kadar başarılı görünen bir yazılım, son inşa sonrasında hiç çalışmayabilir bile.

"Çalışan bir karmaşık sistem kaçınılmaz olarak çalışan basit bir sistemden
geliştirilmiştir. Tam ters ilişki de geçerli gibi görünüyor: Çöplük gibi bir sistemden
geliştirilen bir sistem de asla çalışmaz ve çalıştırılması becerilemez. En baştan çalışan
bir basit sistem kurarak işe başlamak zorundasınızdır."
Gali kanunu (Galls law)- John Gali

o Uç programlamanın bir diğer özelliği de YAGNI prensibidir. YAGNI “You ain’t gonna
need it” yani Türkçe karşılığı ile “İhtiyacın olmayacak ki" cümlesinin sözcüklerinin
baş harflerinden oluşur. Felsefi olarak bir özelliğin ancak gerçekten ihtiyaç
çıktığında koda eklenmesini önerir. İhtiyaç yokken belki ileride ihtiyaç olur diye
boşu boşuna kodu karmaşıklaştırmaya ve büyütmeye karşıdır.
 Spiral ve Çevik Yazılım Geliştirme Modelleri Arasındaki Farklar
 Spiral ve çevik yazılım geliştirme modelleri birbirleri ile karıştırılabilirler. Her ikisi de
artırımsal ve tekrar işlemeli yazılım geliştirme modelinin alt üyesidirler. Birbirlerine
benzemekle beraber aralarında bazı farklar vardır:
o Spiral modelde ön planlama daha ağırlıklıdır, iterasyonlar önceden planlanır.
Oysa Çevik yazılım geliştirmede sadece o anki iterasyon için detaylı plan yapılır,
diğer iterasyonlar için plan yapılmaz, belirsizlik zaten kabul edilen bir gerçektir.
o Spiral modelde “planla - gerçekle(kodla) - test et - düzelt” tipi bir yaklaşım varken
Çevik modelde testlerin mümkün olan en kısa zamanda hatta bazen iterasyonun
en başında hazırlanması düşünülür. Çevik modelde test kodlamadan daha
önceliklidir.
o Çevik modelde her iterasyon sonunda, öncelikli gereksinimlerin gerçeklendiği,
çalışabilir, tamamen test edilmiş, az özellikli ama hazır bir program üretilir. Spiral
Modelde bu şart değildir, ilk iterasyonlarda sadece bir prototip mahiyetindeki bir
ürün ortaya çıkabilir.
o Spiral model teknik bir üretkenlik yaklaşımı iken buna ek olarak Çevik Model
insan psikolojisini de göz önüne alan, sosyal içerikleri olan bir geliştirme
modelidir.
o Spiral model daha klasik bir yaklaşım olduğu için dokümantasyondan, kod içi
yorumlardan, planlardan ve gereksinimlerden taviz vermez, Çevik modelde ise
bu konular suistimale biraz daha açıktır.
 Scrum Yazılım Geliştirme Modeli
o Scrum küçük takımlar için bir yazılım geliştirme modelidir. Scrum yazılım
geliştirme modelinde takım elemanlarının sayısı 10’u geçmemelidir. Birden
fazla takım varsa bunların birbirinden bağımsız çalışabilmesi şartları
hazırlanmalıdır.
o Scrum, Amerikan futbolunda yeni hamleyi yapmak için bir arada,
kenetlenmiş olan takıma ve yaptıkları hamleye denir, bu yazılım yöntemi ve
yöntemi kullanan yazılım ekibi de buna benzetilmiştir.
o Projede ilk safha planlama safhasıdır. Bu safhada bir ürün mimarisi ve planı
geliştirilir ve şef yazılım mimarı seçilir. Projenin yapısından şef yazılım mimarı
sorumludur. Proje sırasında yazılım mimarisi değişebilir ancak değişsin veya
değişmesin mimariye proje boyunca uyulmaya çalışılır.
o Planlama safhasından sonra bir seri kısa geliştirme safhalarından geçilir.
Her safha “depar” (sprint) olarak adlandırılır ve projenin artırımsal olarak
ilerlemesini sağlar. Her bir safha (depar, sprint) genelde 1 ila 4 hafta
arasında sürer. Kapanış safhası ile proje sonlandırılır.
 Scrum Yazılım Geliştirme Modeli (devam)
o Yazılım takımı bütün görevleri “işlem maddesi” (backlog) olarak adlandırılan bir
listede tutar. Bu “işlem maddeleri” takımın ana güdüleyicisidir. Her depar
safhasından önce bu “işlem maddeleri” güncellenir, öncelikleri ayarlanır ve yazılım
takımı bu maddelerden gözüne kestirdiklerini yapmak için onay verir. Takımın her
üyesi kendisine düşen birkaç maddeyi depar sırasında tamamlamak için onay verir.
o Genelde bu depar süreleri hafta(lar) boyutunda olmalıdırlar. Büyük görevlerde ve süre
uzadıkça görevi tanımlamak ve iş sırasında rapor vermek güçleşmektedir. Bir depar
sırasında takım dışından kaynaklı bir değişikliğin takıma rica edilmesine izin verilmez.
o Her depar (geliştirim safhası, sprint) sırasında ürüne gözlenebilir, kullanılabilir veya
dışarı sunulabilir bir artım yapılmaya çalışılır. Her deparın ardında yatan felsefe
değerli bir işlevi ürüne katmaktır.
o Deparlar sırasında hedefin depar süresince bitirilmesine çalışılır. Depar süresinde
hedef bitmez ise deparın süresi asla değiştirilmez, bunun yerine gerekliyse hedef
yeniden tanımlanır veya küçültülür. Depar tarihleri ile oynamamak takım içinde genel
bir standardı sağlar.
o Depar sırasında, sıkça, takımın her üyesinin katıldığı toplantılar yapılır. Bunlar
genelde günlük toplantılar olarak organize edilir. Böylece projedeki olası kaymalar,
gecikmeler çok kısa zamanda tespit edilebilir. Toplantılara uzakta çalışan üyeler tele-
konferansla bile olsa çağrılır, böylece takım ruhu ayakta tutulur.
 Scrum Yazılım Geliştirme Modeli (devam)
o Scrum modelinde müşteri ile irtibatlı olan pazarlama birimi ile teknik
geliştirme birimi arasında sıkı iletişim ve birlikte çalışma olmalıdır.
Tahminlerin yapılmasında ve hedeflerin tutturulmasında bu çok önemlidir.
Proje sırasında hedeflerin öncelikleri bu iki ekip tarafından ayarlanarak proje
için hayati özelliklerin üründe bulunmasına çalışılır.
o Scrum şefi (şef yazılım mimarı) işlem maddelerini (backlog) hazırlar,
günceller ve depardan önce kullanılabilir duruma getirir. Ayrıca projedeki
ilerlemeyi ölçer, işlem maddelerinin tamamlandığını takip eder, riskleri
hesaplar ve acil önlemler alır. Serum toplantılarının kısa ve amaca odaklı
olmasını kontrol etmek de Scrum şefinin görevidir.
o Her scrum toplantısı 15-30 dakika arasında sürer. Toplantıda tamamlanan
işlem maddeleri, karşılaşılan engeller ve bunları çözmek için yapılan
planlardan söz edilir. Sorunların çözüm yöntemleri için hararetli tartışmalara
girilmez ve bunlar için sadece ilgili taraflarla başka toplantılar yapılır.
o Her depar sonunda tüm deparın sonucunu gözden geçirilir ve her konuda
değişiklik yapılabilir. En son depar ürününün teslimi için yapılır.
 Spiral ve Scrum Yazılım Geliştirme Modelleri Arasındaki Farklar
o Scrum yazılım geliştirme modelinin bileşenleri ve fikirleri aslında yeni
değildir.
o Scrum modeli Spiral Yazılım Geliştirme Modeline benzer. Basitçe, zaman
adımlarına bölünmüş, tipik bir artırımsal yazılım geliştirme modelidir.
o Klasik artırımsal modelden fazla olarak “işlem maddelerinin
durumunun, karşılaşılan engellerin ve bu engelleri aşmak için yapılan
planların konuşulduğu sık toplantılar” vardır.
o Bunun dışında Spiral modelin biraz daha hızlandırılmışı olarak kabul
edilebilir.
o Scrum toplamda bir kaç ay süren, her deparı (geliştirme safhası) birkaç
hafta süren, gereksinimleri başlangıçta tam belirli olmayan projeler için
uygundur.
 Birleşik İşlem (Unified Process) Yazılım Geliştirme Modeli
o Bir diğer artırımsal (ineremental) ve tekrar işlemeli (iterative) yazılım
geliştirme modeli de Birleşik İşlem yazılım geliştirme modelidir.
o Modelin en büyük özelliği İşlev ve kullanım öykülerini (Use Case) temel
öğe olarak almasıdır.
o Mimari temelli bir modeldir. Risklerin en kısa zamanda belirlenmesi ve
en büyük riske öncelik verilmesine önem verir.
o Dört tane ana safhası vardır:
• Yakalama safhası (Inception),
• Ayrıntılandırma safhası (Elaboration),
• Üretim safhası (Construction),
• Geçiş safhası (Transition).
 Birleşik İşlem (Unified Process) Yazılım Geliştirme Modeli
o Yakalama safhası projenin ön hazırlığıdır ve mümkün olduğunca kısa
olması istenir. Projenin hedefi, sınırları, riskleri, kullanıcı ve işlev öyküleri,
ana gereksinimleri bu safhada belirlenir. Kaba bir proje planı ve maliyet
tahmini yapılır. Proje için uygun aday mimariler belirlenir.
o Ayrıntılandırma safhasında sistem gereksinimleri detaylandırılır. Risk
faktörleri hesaplanır ve sistem mimarisi hazırlanır ve doğrulanır.
Doğrulama için projenin ana çatısı gerçeklenebilir. Türlü şemalarla
detaylar desteklenir.
o Üretim safhası en kapsamlı safhadır ve bu sırada ürünün detaylı üretimi
gerçekleştirilir. Üretim kısa zaman adımlarından oluşan yinelemelerle
gerçekleştirilir.
o Geçiş safhası ürünün sahaya sürülmesi, kurulması veya müşteri tarafına
sağlıklı biçimde iletilmesi safhasıdır. Burada ürün sonlandırılana kadar
çeşitli iyileştirme çalışmaları yapılabilir.
 Yalın Yazılım Geliştirme Modeli
o Yalın Yazılım Geliştirme modeli (Lean Software Development) endüstrideki
verimli kaynak kullanımı modelini yazılım projelerine de uygulamayı hedefler
(Hibbs 2008).
o Endüstride kullanılan verimli kaynak modeli esaslarını listeleyecek olursak:
• Gereksiz stoklama yoktur,
• Mümkün olduğunca otomasyon yapılır,
• İsraf yoktur, kaçınılacak israf maddeleri şunlardır:
• Hatalar: Klasik hatayı bul ve tamir et yöntemi yerine önleyici tedbirlerle
hatalar oluşmadan engellenmelidir,
• Aşırı üretim; Kaçınılması gereken diğer bir israftır,
• Taşıma: Parçaların işlemler arasında taşıma maliyetleri hesap edilmelidir,
• Bekleme: Parçalar veya insanların beklemesi maliyeti arttırır,
• Stok: Stok para akışını bozacağı için, ödeme dengesini bozar, maliyeti
arttırır, ayrıca alan ve çalışan maliyetini arttırır,
• Hareket: gereksiz yere ekipman veya insanların hareketi de zaman
kaybettirir,
• Gereksiz işleme: Müşterinin istediğinden daha fazla işleme yapmak
maliyetleri arttırır,
• İnsanların faydasız kullanımı: Maliyetleri arttırır.
 Yalın Yazılım Geliştirme Modeli (devam)
o Yukarıdaki verimlilik temelli modeli yazılım geliştirmeye de uygulamayı amaçlayan Yalın
Yazılım Geliştirme modeli aynı maddeleri şu şekilde yazılım için yorumlar:
• Tam zamanında işlem ve gereksiz stoklamadan kaçınmak: Bitmemiş, yarım durumda her
yazılım maliyeti arttırır bu sebeple yarım işlerden kaçınılır,
• Otomasyon: Teknolojinin sağladığı tüm gereçlerden faydalanılır, bu bağlamda otomatik kod
yazma, versiyon tutma, hata raporlama, tasarım programları yoğun biçimde kullanılır.
• İsraftan kaçınmak: Kaçınılacak israf maddeleri şunlardır:
• Hatalar: Tüm aşamalarda kalite içeri gömülür, gereksinimlerin hazırlanmasında,
tasarımın yapılmasında, vb hatalar minimuma indirilir ve böylece ürün çıktıktan sonra
oluşacak hatalar azaltılır, yani kalite tüm işlem süresine gömülür ve dağıtılır,
• Aşırı üretim, ekstra özelliklerden kaçınılmalıdır: Kullanıcının isteklerinin %80’inin
ürünün özelliklerinin %20’si ile karşılanabildiği göz önüne alınmalıdır,
• Taşıma: Bilgiler, dokümanlar toplantı raporları herkese aynı anda iletilmelidir,
müşteriden gelen bir gereksinim planlama bölümünden tasarımcıya ulaşana kadar
defalarca el değiştirmekte ve hatalarla dolmaktadır, kulaktan kulağa şeklindeki iletişim
biçimlerinden kaçınılmalıdır,
• Bekleme: Projeler çok iyi planlamak ve beklemeler en aza indirilmelidir,
• Stok: Yarım veya sürmekte olan birçok proje stok maliyetinin artması demektir, projeler
kısa ara hedeflere sahip olmalı ve sürüncemede bırakılmamalıdırlar,
• Hareket: Yazılımcılar sadece bir işle uğraşmalı birden fazla proje bir yazılımcıya
atanmamalı- dır, bir anda bir projeden diğer bir projeye adapte olma süresi çok fazladır,
• Gereksiz işleme: Gereksiz süreçler bir an önce elimine edilmelidir.
 Yalın Yazılım Geliştirme Modeli (devam)
o Yalın programlamanın bu esaslardan çıkardığı bazı öneriler de vardır:
• İnsanlara saygı gösterin: Yalın programlamanın esası kaynaklan iyi kullanmaktır
demiştik. İnsanlar da en önemli kaynaklar olduğuna göre insanlara saygı
göstermek, kendilerini yetiştirmelerine gelişmelerine destek olmak, fikirlerine
değer vermek ve iyi bir çalışma ortamı sağlamak Yalın Programlamanın temel
hedeflerindendir. İnsanlara değer vermek, insanların verimlilik kuralları içerisinde
aşırı yıpranmasını önler, yani katı verimlilik sistemini biraz daha insanileştirir,
• Araçlar kullanın: Versiyon kontrol araçları, otomatik script'ler kullanın,
• Otomatik test imkânlarını kullanın: Testlerinizi otomatikleştirin,
• Sürekli entegrasyon: Sürekli birleştirme yaparak süreci iyileştirin, birleştirmeyi en
sonda yapmayın ve sürece yayın,
• Daha az kod yazın: Kodda sürekli iyileştirme (refactoring) yapın ve kaliteli fakat
az kod yazın, daha çok kod daha çok problem demektir, yazılan her kod satırı
harcanan para demektir ve bu sebeple asla gereksiz kod yazılmamalıdır. Müşteri
gereksinimleri çok iyi irdelenmeli ve gerçekten gerekli olmayan gereksinim
çıkarılmalı ve dolaylı olarak gereksiz kodun yazılması engellenmiş olmalıdır.
• Kısa iterasyonlar yapın: Böylece süreci daha bir kontrol altında tutun,
• Müşteri katılımı: En baştan en sona kadar müşteri katılımını sağlayın.
 Re-use (Tekrar Kullanımlı) Yazılım Geliştirme Modeli
o Bu modelde sistem ve organizasyonun çoğu ürünü tekrar kullanılabilir modüllerden
faydalanılarak üretilir.

 Prototip Yazılım Geliştirme Modeli

o Bu modelde üretilecek modelin bir prototipi yapılır.
o Bu prototip sadece sistemi genel olarak görmek için yapılan hızlı ve özensiz
geliştirilmiş bir örnek olduğu için genelde bu prototipin gerçek sistemin kalitesini
etkilememesi için prototip kullanılmaz ve atılır.

"En kısa zamanda bir prototip yapınız."

Mike Gancarz ve arkadaşları, UNIX felsefesi maddelerinden
 Test Güdümlü Yazılım Geliştirme Modeli
o Bu yazılım modelinde öncelikle testler yazılır daha sonra bu testleri
geçebilecek özelliklere sahip kod yazılır.
o Genellikle otomatik testler ile çalışmak süreyi çok kısaltır.
o Bu modelin detaylarına inecek olursak:
• İlgili gereksinim için test kodunu yaz,
• Testin geçemediğini teyit et (henüz herhangi bir işlev
geliştirilmediğinden dolayı),
• İlgili özellik için kod yaz,
• Kodu test et ve geçtiğini göster,
• Gerekiyorsa kodda iyileştirme ve ayarlamalar yap,
• Kodu test et ve geçtiğini göster,
• Başa dön.
 Test Güdümlü Yazılım Geliştirme Modeli (devam)
o Test Güdümlü yazılım geliştirme modelinin uygulanmasının zor olacağı
alanlar da vardır. Örneğin:
• Grafiksel kullanıcı arabirimi testleri genellikle otomatik testler için uygun
değildir,
• Testleri yazmak bazen hedef koda kıyasla çok zaman alıcı olabilir,
• Test kodunun da bakımını yapmak gerektiğinden bakım maliyeti artar,
• Test kodunun sürekli güncel tutulması gereklidir ve bu zor olabilir,
• Testi yazan kişi ile hedef kodu yazan kişi aynı geliştirici ise hataları tespit
edemeyebilir,
• Test yazmak zaman kaybı olarak görülebileceğinden bu metoda karşı
psikolojik direnç gösterenler olabilir.
 Temiz Oda Yazılım Geliştirme Modeli
o Bu model son teknoloji yongaların üretildiği temiz odalardan esinlenerek
seçildiği için temiz oda modeli adını almıştır.
o Bu model kovboy tarzı kuralsız programlama tipinin neredeyse tam
tersidir. Modelin amacı neredeyse sıfır hata ile yazılım üretmektir.
o Bu amaca ulaşmak için:
• Ön-tasarımda bir hayli vakit harcanır,
• Kaliteyi sağlamak için istatistik! yöntemler yoğun olarak kullanılır,
• Gereksinimler çok net ve açık belirlenir.
o Bu modelde üründe hata çıkması ve düzeltilmesi (Error Correction)
beklenmez.
o Modelin ana fikri hatanın oluşmasını engellemektir (Error Prevention).
Kalite kaygısı düşünülerek harcanan çabalar bu modeli destekler.
o Temiz oda yazılım geliştirme modeli Şelale Modeli kadar kuralcı olsa da
yöntem olarak artırımsal (iteratif) yaklaşım benimsenmiştir, böylece
kalite her adımda denetlenebilmektedir.
 V-Modeli
o Modelin grafik gösterimi V harfine benzediği için model bu isimle anılır.
o Grafikte sol taraf tasarım, sağ taraf ise doğrulama aktivitelerini içerir.
Modelin ana ilkeleri şunlardır:
• Her işlem için karşılık gelen bir doğrulama aktivitesi olmalıdır.
• Geliştirme işlemi, gereksinimler sayesinde, ana hatları ile başlar, detaylara
inilir, daha sonra bu detaylar doğrulanarak birleştirilir ve sonuçta ürün elde
edilir.
 V-Modeli (devam)
o V-modeli geliştirme işlemine çok kabaca baktığı için, yinelemeli
(iteratif) bir yaklaşım sunmadığı için ve pratikte kullanılabilecek çok
fazla yöntem önermediği için eleştirilen bir modeldir.
o Bu model, belirsizlikleri az olan, yani iteratif yaklaşım gerektirmeyen,
çok düzenli projelerde kullanılabilir.
o Modelin bir avantajı test edilmemiş herhangi bir aşama
bırakmamasıdır.
o Diğer bir avantajı da iş akışında eksik kalan, atlanan bir aşama
bırakmamasıdır.
 Yazılım Kalite Unsurları
o Kalitenin birçok tanımı yapılmıştır. Bunlardan birkaçını sıralarsak:
• Kalite amaca uygunluktur.
• Kalite insanlar için değer taşımaktır.
o Yazılım kalitesini belirleyen birçok özellik vardır.
o Yazılım hemen hemen tamamen hatalarından arındırılmış olsa bile
kaliteli olmayabilir.
o Yani hatasızlık bir kalite ölçütüdür ancak kaliteyi belirleyen yegane
özellik değildir.
o Üstelik bu özelliklerden bazıları bir ürün için daha önemli iken bazıları
diğer bir ürün için daha önemli olabilir.
 Yazılım Kalite Unsurları
o Yazılım kalitesini belirleyen özellikler büyük ölçüde McCall (1977) ve Boehm’in (1978)
çalışmaları ile belirlendi.
o Bu bilgilerden de faydalanarak yazılım kalitesini belirleyen unsurları şöyle
sıralayabiliriz:
• Anlaşılırlık (Understandability): Gerek sistem yazılımı, gerekse dokümanlar
anlaşılır ve açık mı?
• Tamlık (Completeness): Tüm gerekli bileşenler gerçeklenmiş mi? Sistem
kaynakları yeterli mi?
• Doğruluk (Correctness): Sistem kendisinden beklenen işlevleri doğru olarak
yerine getiriyor mu?
• Taşınabilirlik (Portability): Yazılım başka bir platforma taşınabiliyor mu?
Taşınamıyorsa bu belirtilmiş mi?
• Sürdürülebilirlik-Bakım yapılabilirlik (Maintainability): Yazılımın ileride çıkabilecek
sorunları kolayca çözülebiliyor mu?
• Test edilebilirlik (Testability): Yazılım kolayca ve doğru olarak test edilebiliyor mu?
• Kullanıma uygunluk (Usability): Yazılım kullanıcı dostu mu?
• Güvenilirlik (Reliability) ve Sağlamlık (Robustness): Yazdım kendisinden
beklenenleri gerek süre gerekse koşullara bağlı olmaksızın doğru olarak yerine
getirebiliyor mu?
• Etkinlik (Efficiency): Yazılım (bellek, mikroişlemci kullanımı, haberleşme ağ
kullanımı gibi konularda) hem etkin biçimde yazılmış hem de etkin bir biçimde
 Yazılım Kalite Unsurları (devam)
• Güvenlik (Security): Yazılıma sadece yetkisi olan kullanıcılar erişebiliyor mu?
Yazılımın kendisi ve verileri yetkisiz erişime karşı korunuyor mu?
• Esneklik (Flexibility): Yazılıma gerektiği zaman yeni modüller veya işlevler kolayca
eklenebiliyor mu?
• Tekrar kullanılabilirlik (Reusability): Yazılımın modülleri veya tamamını başka
projelerde kullanmak mümkün mü?
• Tutarlılık (Consistency): Yazılımda kullandan değişken adları, matematiksel veya
çeşitli semboller ve ekrandaki elemanlar tutarlı ve birbiri ile uyumlu mu?
• Farkındalık (Conciseness): İlgili ürün yazılım kuralları, standartları gözetilerek,
yeniden düzenleme ve optimizasyon kurallarına uyularak ve farkında olunarak
yazılmış mı?
• Erişilebilirlik-Edinilebilirlik (Availability): Yazılıma piyasada veya herhangi bir
kanalla erişmek kolay mı?
• Kurulabilirlik (Installability): Yazılımı kurmak kolay mı?
• Uyumluluk (Compatibility): Yazılım diğer sistemlerle uyumlu olarak çalışabiliyor
mu?
"Bir programı güvenli, güvenilir ve hızlı yapmanın tek yöntemi onu küçük
yapmaktır."
Andrew S. Tanenbaum
 
Yazılım Mühendisliği
 Yazılım Mühendisliği, yazılım üretiminin mühendislik yöntemleriyle
yapılmasını öngören ve bu yönde yöntem, araç, teknik ve metodolojiler
üreten bir disiplindir.
 Bu bakımdan Yazılım Mühendisliği bir yöntemler kümesi, teknikler kümesi ya
da araçlar kümesi olarak değerlendirilebilir.
 Yazılım üretiminde Yazılım Yaşam Döngüsünde belirtilen aşamaların
sistematik olarak izlenmesi ve gerçekleştirilmesi yazılım mühendisliği için ön
koşuldur.
 Yazılım mühendisliği, yazılım üretimindeki karmaşıklıkları gidermeyi hedefler.
 Geçmişte kullanılan iş akış şemaları gibi yöntemler, günümüzde, yazılım
projelerinin boyutlarının büyümesinden dolayı yetersiz kalmıştır. Öte yandan
artık yazılım üretim işi, tek kişinin başarabileceği boyuttan çıkmış ve takım
işi biçimine dönüşmüştür. Yazılım mühendisliği bu olgular üzerine önem
kazanmıştır.
 Günümüzde, doğrudan yazılım mühendisi mezun eden
üniversite bölümleri yeni yeni oluşmaya başlamıştır. Daha
çok yüksek lisans eğitimi ile başlayan Yazılım Mühendisliği
disiplini, lisans düzeyine taşınmaktadır.
 "Yazılım Mühendisliği" ile "Mühendislik Yazılımı" terimlerinin
karıştırılmaması gerekir. Mühendislik yazılımları, daha çok
donanım bileşeni ile ilgisi olan (örneğin sürücüler vb.)
yazılımlardır. Yazılım mühendisliği ise, yazılım mühendisi
yetiştirmeyi amaçlayan bir disiplindir.
Yazılım Mühendisi
 Yazılım mühendisliği işini yapan kişidir.
 Değişik bilgisayar bilimi teknolojilerinin ve kişilerin bir bilgi ya da
yazılım sistemi oluşturmak amacıyla biraraya getirilmesinde bir
bütünleştirici gibi çalışır. Temel hedefi, söz konusu üretimin en az
maliyet ve en yüksek kaliteli biçimde yapılmasıdır.
 Yazılım mühendisi bir programcı değildir. Ancak programcının tüm
yeteneklerine sahiptir. Programcı, ağırlıklı olarak kodlama,
sınama işi ile ilgilenir. Yani programlarla ilgilenir. Yazılım
mühendisinin işi daha çok insanlarla ilişkiyi gerektirir. Yazılımın
daha çok mantıksal boyutuyla ilgilenir.
 Yazılım mühendisi ile sistem çözümleyici arasındaki belirgin fark
ise, sistem çözümleyicinin üretimin yalnızca çözümleme (analiz)
aşamasında, yazılım mühendisinin ise tüm aşamalarında yer
almasıdır.
 Analiz ve Planlama aşaması
 Gereksinimlerin belirlenmesi aşaması
 Ön ve detaylı tasarım aşaması
 Gerçekleme aşaması
 Test ve entegrasyon (birleştirme) aşaması
 Sonuçları değerlendirme aşaması
 Bakım aşaması

5
 Projeye başlarken öncelikle iyi bir analiz süreci yaşamak ve
planlama yapmak gereklidir.
 Öncelikle müşterinin ne istediğinin, nasıl bir sistem istediğinin tam
olarak anlaşılması gerekir.
 Müşterinin istediğinin ne olduğu tam olarak anlaşıldığında risk
analizi ve maliyet tahminleri yapılır.
 Detaylı gereksinimler de analiz ve planlama aşamasında oluşur.
 Gereksinimler bu aşamadan sonra değişmeyecek diye bir kural
yoktur, ancak bu aşamada ne kadar tutarlı bir gereksinim
dokümanı oluşturulur ve ona sadık kalınmaya çalışılırsa proje de o
kadar sağlıklı ve rahat gerçekleştirilir.
 Analiz ve planlama aşamasında sistemin nasıl test edileceğinin
planlaması da yapılmalıdır. Test edilmesi zor veya test edilme
imkanı bulunmayan bir sistem hiçbir zaman üretilmemelidir.
 Analiz ve planlama aşamasında bu konuların yanı sıra projeyi
gerçekleştirecek takım da oluşturulur.
6
 Her Şey İş Tanımı İle Başlar
o İş tanımı, projedeki tüm taraflara ve projede çalışan elemanlara
işin amacını ve kapsamını kabaca anlatan bir dokümandır.
o İş tanımı dokümanında şu iki konuya mutlaka değinilmelidir:
• İşin Amacı
• İşin Kapsamı
• Diğer Alanlar:
• İşin süresi
• İşin yapılacağı yer
• Teslim takvimi
• Teslim kalemleri
• Kabul kriterleri
• Ödeme koşulları
7
 Projeninbaşarısındaki etkenlerden biri projenin
amacının iyi anlaşılmasıdır
"Bir projeyi planlamaya başlamadan önce projeyi neden
yaptığınızı, yapma sebeplerinizi iyice anlamalısınız. Projeye
neden ihtiyacınız olduğunu kavramadan proje sonunda
başarılı olup olmadığınızı nasıl söyleyebilirsiniz ki?"
Kent Beck, Martin Fowler

8
 Projede Maliyet ve Süre Tahminleri
o Bir projenin yapılma sebebi kar etmektir ve bunu mümkün olan en kısa
sürede yapmaktır. Kar edilmeyecek bir projeye girmenin anlamı yoktur,
bu sebeple maliyet ve süre tahminlerinin doğru yapılması çok önemlidir.
o Proje süresi hesaplanırken genel eğilim iyimserliktir ve bu durum birçok
projenin batmasına sebep olur. – İyimserliğin genellikle iki kötü sonucu
vardır:
• Proje ekibi ne pahasına olursa olsun projeyi bitirir ama artık ekipten hayır
gelmez.
• Proje ekibi projeyi zamanında bitiremez, gecikme tazminatları, müşteri kaybı,
ekipte fazla ve sürekli stres gibi birçok zarar oluşur.

"İyimserlik programlama işinin bir meslek riskidir ve tedavisi geribeslemedir."

Kent Beck
"Kodun ilk yüzde 90'ını yazmak geliştirme zamanının yüzde 90'ını alır.
Kodun geri kalan yüzde 10 kısmını yazmak ise geliştirme zamanının diğer yüzde
90'ını alır."
9
Tom Cargill
 Günde kaç satır yazabilirim, Projeyi ne kadar sürede bitirebilirim?
o Normalde bir kişinin günde 50-60 satır kod yazabileceği öngörülür, fakat
bu sayı karmaşık yapıları olmayan kodlar için geçerlidir. Ortalamada ise
kişinin günde ortalama bir fonksiyon yazıp, biraz da test edebileceği
öngörülür. Yani ortalama 30 satırdan, yaklaşık ayda 1000 satır.
o Ancak çoğunlukla bu sayı tatiller, kod yazılmayan analiz, test, entegrasyon
gibi süreçleri çıkarırsak ortalama ayda 400 satıra düşer.
o Elbette 1000 satır kod üretip sonra aylarca çıkan sorunları çözmeye
çalışan proje ekipleri de mevcuttur.
 Kendinizden emin değilseniz proje içi ayırdığınız süreyi Pi sayısı
(3,14) ile çarpın
o Proje süresi tahmini için birden fazla yöntem kullanmamış ve çok detaylı
analizler yapmamışsanız proje süresi için yaptığınız tahmin Pi sayısı ile
çarpın.
o Genelde tahmin yapılırken sadece tasarım ve kodlama süreleri dikkate
alınır ancak; entegrasyon, kodun test edileme, sahaya kurulma, eğitim
hazırlama ve verilmesi, dokümanların hazırlanması, elemanların ani
ayrılması veya hastalanmaları ve tatil süreleri de proje süresini etkiler.
10
 Proje Büyüklüğünü Tahmin Etmek
o Benzerlik Yöntemi – Projeyi daha önce yapılmış projeler ile kıyaslayarak
tahminde bulunma yöntemidir. Yöntemi kullanabilmek için daha önceden
yapılmış kıyaslanabilecek projelerin olması gereklidir.

o Uzman Görüşü – Proje tahmininde uzmanlardan görüş alınır. Sonuç

değişken olabilir ve uzmanın tahmin ve konusundaki ustalığına bağlıdır.

o Tepeden Aşağı İnceleyerek Tahminde Bulunma Yöntemi – Sistem en

tepeden ve en genelden başlanıp detaylara inerek incelenir. Bu yöntemde
sistemin tanımının ve gereksinimlerinin çok iyi belirlenmiş olması gerekir.
Yöntemin dezavantajı, verilecek kararların mühendislik grubunun
başlangıçtaki düşünce ve tercihlerine çok bağlı olmasıdır.

11
 Proje Büyüklüğünü Tahmin Etmek (devam)
o Aşağıdan Tepeye İnceleyerek Tahminde Bulunma Yöntemi – Sistem en
küçük parçalarından başlanarak incelenir. Detaylı, zaman alıcı bir
yöntemdir. Üstelik parçaların büyüklüğü hesaplanırken bu parçaların
birleştirme maliyeti genelde unutulur. Bu yöntem kullanılarak projede
bir süre yol alındıktan sonra ilk parçaların yapılma süresi gözlenir.
Orantı kurularak tüm parçaların ne kadar zamanda gerçekleşeceği
hesaplanabilir ve ekibin ilerleme hızı ve dolayısıyla projenin süresi
gerçekçi bir biçimde hesaplanabilir.
o Maliyete Göre Tasarım – Bu yöntemde önerilen bütçeye göre ne
yapılabilecekse o tahmin edilip yapılmaya çalışılır. Mühendislik
temelinden uzak bir yöntemdir.
o Parametrik modeller kullanmak – Bu yöntemde detaylı mühendislik
hesapları yapılır ve tahmin yöntemleri kullanılır. Avantajı şudur;
hesaba dayalı bir işlem olduğu için erken sonuçlar alınabilir ve
sonuçlarda objektif olunabilir. Ancak doğru uygulanmadığında ya da
insanlar yöntemi suistimal ettiğinde çok iyimser tahminler üretebilir.
12
 Parametrik modeller kullanılarak yapılan tahminlerin
örnekleri:
o Kaynak kod satırı sayısı ile proje büyüklüğü tahmini
o İşlev noktaları sayısı ölçümü ile proje büyüklüğü tahmini
o İşi ana parçalara bölerek proje büyüklüğü tahmini
o Nesne temelli programlama yapılırken kullanılan yöntemler
• Nesne öğeleri sayısı temelli tahmin
• Kullanım senaryoları (Use Case) sayısı temelli tahmin
o COCOMO Tahmin Modeli
 Kalite, Hız, Ucuzluk Üçgeni
o Ürün kaliteli ve hızlı yapılırsa ucuz olamaz,
o Ürün kaliteli ve ucuz yapılırsa hızlı yapılamaz,
o Ürün hızlı ve ucuz yapılırsa kaliteli olamaz.

13
 Planlama ve İyi Bir Planlamanın Önemi
o Proje küçük de olsa mutlaka bir plan yapılmalıdır
o Plan içerisinde yapılacak ana işler, görev dağılımı, görevlerin başlangıç ve bitiş süreleri
yazılmaya gayret edilmelidir.
 Proje Adımlarını Belirleyin
o Proje adımının tanımı
o Bu adıma ulaşmak için gerekli süre
o Bu adıma ulaşmak için gerekli efor ve elemanlar
o Proje adımının başarı kriteri, yani bu adıma başarıyla ulaşıldığının objektif belirlenmesi,
o Aşamaların öncülleri, ardılları.
 Proje adımlarını dokümante ederken birçok yöntem vardır. Pert çizelgeleri (Program
Evaluation and Review Technique - İş Değerlendirme ve Gözden Geçirme Tekniği),
CPM Çizelgeleri (Critical Path Method - Kritik Patika Yöntemi), Gantt Çizelgeleri (Gantt
Chart) bunlardan bazılarıdır. Özellikle Gantt Çizelgeleri yazılım projelerini safhalara
ayırırken olmazsa olmaz yöntemlerden biridir. Gantt çizelgeleri basitçe iş parçalarını ve
bunların tahmini sürelerini aynı çizelge üzerinde, zaman ekseninde göstermekten
ibarettir.
14
 Proje İçin Gerekli Olan Kaynaklar
o Herhangi bir projeye başlayabilmek için aşağıdaki dört
kaynak olmazsa olmaz unsurlardır:
• İşgücü
• Donanım
• Zaman
• Para
o Bunun yanısıra aşağıdakiler de başarılı olmak için
neredeyse vazgeçilmezdir:
• Proje kapsam tanımı- Project Scope (Proje amacı, büyüklüğü,
gereksinimleri, paydaşlarının belirlenmesi ve başarı kriteri)
• Motivasyon
• Sağlıklı çalışma ortamı
• Kullanıcı geri beslemesi
15
 Risk Analizi
o Yazılım projeleri risk oranı yüksek projelerdir. Bu yüzden başarısızlık
oranları bir hayli yüksektir. Başarılı projeler:
• Zamanında tamamlanmış
• Bütçesini aşmamış
• Belirlenen gereksinimleri karşılayan projelerdir.

16
 Yazılım Projelerinde En Çok Rastlanan Riskler Nelerdir?
o Proje amaç, tanım ve kapsam riskleri
o Gereksinim riskleri
o Takvim riskleri
o Bütçe ve maliyet riskleri
o Planlama riskleri
o Gerçekleme riskleri
o Kalite güvence riskleri
o Kalite kontrol riskleri
o Organizasyondan kaynaklanan riskler
o Yönetimsel riskler
o Müşteri ve kullanıcılarla ilgili riskler
o Paydaşsal riskler
o Altyüklenici riskleri
o Sosyal riskler ve personel riskleri
o Teknolojik riskler
o Ticari riskler
o Politik ve yasal riskler
o Toplumsal riskler 17
 Riskleri Azaltmak İçin Ne Yapılmalıdır?

 Sorun: Gerçekçi olmayan takvim ve bütçeler.

 Çözüm: Takvimleri hazırlarken kodlamayı yapacak personelin fikrine mutlaka
başvurunuz. Bütçe hazırlarken geçmiş projelerden faydalanmayı ihmal etmeyiniz.
Bunun için bir proje veritabanı tutmanızın ve proje sonu değerlendirme
çalışmaları yapmanızın gerektiğini bir kez daha hatırlatalım. Takvim aşılması
sorununu yaşamamak için iletişim kanallarının mümkün olduğunca açık olması
ana şarttır. Ayrıca projede belirsizlik ne kadar fazla ise o kadar çok “tekrar
işlemeli/adımsal” (iteratif) ve “artırımsal” incremental) yaklaşımlara yönelmeli,
böylece projeyi denetlenebilir safhalara ayırmalısınız.

 Sorun: Personel sıkıntısı veya sık değişimi.

 Çözüm: Personel değişiminin zararlarından korunmak için tavsiye edebileceğimiz
iki yöntem vardır. Birincisi tahmin edilebileceği gibi personeli memnun etmektir.
İkinci yöntem ise personelin ne yapılırsa yapılsın değişebileceğini doğal kabul
edip çevik yöntemlerin önerdiği “çiftler halinde programlama” gibi personel kaybı
oluştuğunda bilgi kaybı oluşmasını da engelleyici önlemler almaktır. Kritik
bilgilerin birden fazla personel tarafından bilinmesi yararlıdır.
18
 Risklerin Erken Tespiti Hayat Kurtarır
o Riskleri erken tespit etmek için gerekli öğeleri sayarsak:
• Proje ekibinin iletişiminin iyi olması,
• Proje içerisinde bilgi akışının iyi olması,
• Deneyimli teknik proje yöneticisi,
• Risk yönetimi için görevlendirilmiş bir ekip veya program yöneticisi,
• Eski projelerin verilerinden faydalanmak,
• Tahmin yöntemleri kullanmak,
• Yetki ve sorumlulukları proje başında iyi belirlemek,
• Proje vizyonunu ve iş tanımını yazılı ve net biçimde yapmak,
• Proje gereksinimlerini proje boyunca her mümkün olduğu anda daha da
netleştirmek,
• Proje tipi daha belirsiz ise daha da iteratif (tekrar işlemeli/adımsal)
yöntemler kullanmak.
19
 Gereksinimlerin Belirlenmesi Aşaması
o Gereksinimler müşteri ve yazılım ekibi arasında yazılımın ne
yapacağı ve hangi özelliklere sahip olacağı konusunda bir
anlaşmadır. Gereksinimlerin doğru olarak belirlenmesi çok
önemlidir. Gereksinimler sırasında yapılan ve tespit edilemeyen bir
hatanın maliyeti sonraki aşamalarda giderek artar.
Hatanın bulunma zamanına göre hatanın düzeltme maliyeti
60

50

40

30

20

10

0
Hatanın Düzeltme Maliyeti
20
Gereksinimlerin Belirlenmesi Tasarım Kodlama Test Kurulum Sahada Çalışma
 Yazılım gereksinim dokümanının faydaları şunlardır:
o Müşteri ile yazılım ekibi arasındaki yanlış anlamaları yok eder, olası
uygunsuzlukların en başta tespit edilmesini sağlar.
o İşgücü, maliyet ve süre analizlerine ek bir temel teşkil eder ve doğru
yapılmalarını sağlar,
o Testler ve kabul kriterleri için temel teşkil eder,
o Diğer dokümantasyonlara temel teşkil eder,

 Gereksinimler ile ilişkili standartlar şunlardır:

o IEEE STD 1233-1998 Sistem Gereksinimleri için tavsiyeler
o IEEE STD 830-1998 Yazılım Gereksinimleri için tavsiyeler
o MIL-STD-498 Askeri Yazılım Geliştirme Standardı

21
 İyi Bir Gereksinim Dokümanı Hangi Özelliklere Sahip Olmalıdır?
o Doğru - Elbette gereksinim dokümanınızın doğru olmasını istersiniz.
Ancak önemli olan güncel tutarak uzun süre doğru kalmasını
sağlamaktır.
o Tartışmasız - : Bir gereksinim herkes tarafından aynı şekilde
yorumlanmalıdır. Bir gereksinimden herkes farklı bir şey
anlamamalıdır.
o Tam - Yazılımın gerçeklenmesi için gerekli tüm konulara ait
gereksinmelere değinmelidir.
o Tutarlı - Gereksinim dokümanı içindeki her madde diğer maddeler ile
uyumlu olmalıdır. Gerek mantık olarak gerekse yazım biçimi olarak
uyum sağlanmalıdır.
o Öncelik sıralı - Gereksinimler gerçeklenme önceliklerine göre
gruplanır ve sıralanırsa proje takvimi açısından çok değerli bir iş
yapılmış olur. Önemli gereksinimler önce, daha az önemliler daha
sonra gerçeklenir. Gereksinim dokümanında öncelik bilgisi de
verilmelidir. 22
 İyi Bir Gereksinim Dokümanı Hangi Özelliklere Sahip Olmalıdır?
(devam)
o Doğrulanabilir - Gereksinim olarak doğrulanması güç, muğlak ifadeler
kullanmayınız. Örneğin “Sistem hızlı cevap verecektir.” ifadesi yerine “Sistem
alınan mesajlara en fazla 100 ms içerisinde cevap mesajı gönderecektir.”
türünden ölçülebilir ifadeler yazın.
o Değişikliğe uygun - Gereksinim dokümanı içerisindeki gereksinimler ve
açıklamalar basit, ufak ve mümkün olduğunca birbirlerinden bağımsız
olmalıdır. Ayrıca bir gereksinim birçok yerde tekrarlanmamalıdır. Böylece
gereksinim dokümanı değiştirilmek istendiğinde kolayca değiştirilebilir.
o İzlenebilir - Gereksinimlerin gerek sistem gereksinimlerine gerekse testlere
olan ilgileri açıkça belirtilmelidir. Bir yazılım gereksiniminin hangi sistem
gereksiniminden doğduğu bilinirse gerçeklenme daha tutarlı ve hatasız
yapılabilir. Öte yandan hangi testin bu gereksinimi test ettiği bir yerde yazılı
olursa testler esnasında gözden kaçan yani test edilmemiş gereksinim
kalmaz.
o Gerçeklenebilir - Gereksinimlerin gerçekten gerçeklenebilir olduğunun
önceden düşünülmesi faydalıdır. Gereksinimler yazılırken bile bir ön
araştırma yapılıp bu gereksinimin eldeki imkânlarla başarılıp
başarılamayacağı düşünülmelidir. 23
 Gereksinimleri Hazırlarken ve Yazarken Nelere Dikkat Etmek
Gerekir?
o Gereksinimleri hazırlama safhasında aşağıdaki konulara
dikkat etmelisiniz:
• Öncelikle birçok projede kullanabileceğiniz standart bir
gereksinim dokümanı şablonunuz olsun.
• Müşteri ve konunun uzmanları ile sıkı bir iletişimde bulunun.
• Proje süresinin %20 ile %25’i gereksinimler için harcanmalıdır.
• Gereksinim dokümanını güncel tutun.
• Gereksinim dokümanını gözden geçirme işlemine sokun, başka
insanlara okutun, anlaşılıp anlaşılmadığını kontrol edin

24
 Gereksinimleri yazarken aşağıdaki konulara dikkat etmelisiniz:
o Tümcelerinizi kısa tutun,
o Edilgen tümceler kullanmamaya çalışın, çünkü edilgen yapıda özne olmadığı
için sorumluluğun kimde olduğu belli değildir,
o Gramer kurallarına dikkat edin,
o Gereksinim dokümanı içerisinde geçen terimler için terimler sözlüğü
oluşturun,
o Gereksinim dokümanı içerisinde geçen kısaltmalar için kısaltmalar sözlüğü
oluşturun,
o Gereksinim dokümanı içerisinde anlaşılması zor veya teknik olan konuları
tanım maddeleri olarak verin. Örneğin “Arayüz” kelimesi için “İki veya daha
fazla cihaz arasında veri iletişiminin sağlandığı donanım birimi” gibi bir
açıklama tüm paydaşları çok memnun edecektir,
o Tek bir gereksinim maddesini test etmek için üç-dört testten fazla test
yazmak zorunda kalıyorsanız muhtemelen o gereksinimi aslında birkaç
parçaya bölmeniz gerekiyordur
25
 Gereksinimleri yazarken aşağıdaki konulara dikkat etmelisiniz (devam):
o Ve/Veya kelimelerinin fazla geçtiği gereksinim maddeleri genelde özensizce
yazılmış maddelerdir,
o Negatif anlamlı tümcelerden kaçının,
o Gereksinimlerin seviyeleri birbirine yakın olmalıdır. Açıklayacak olursak bir
gereksinim tüm sistemi tarif ederken diğer bir gereksinim bir detayı tarif ediyorsa
bir sorun var demektir,
o Tekrar eden gereksinimlerden kaçının. Sadece açıklama kolaylığı sebebi ile
mecbur kalındığında tekrar eden gereksinimler kullanılmalıdır. Aksi taktirde
tekrar eden gereksinimler dokümanın bakım yapılabilirliğini fena halde azaltırlar,
o Gereksinimi yazan kişiler ile kodlamayı yapan kişiler mümkünse ayrı kişiler
olsunlar,
o Gereksinimi yazan kişilerin dil yeteneği ve iletişim becerisi çok gelişmiş olmalıdır,
o Tam anlaşılmayan veya belirsiz gereksinimlerin ileride size sorun çıkaracağından
emin olabilirsiniz,
26
 Gereksinimleri yazarken aşağıdaki konulara dikkat etmelisiniz
(devam):
o Yazılım gereksinimlerini sistem gereksinimlerine (veya ana kaynak üst
gereksinimlere) bağlayan izlenebilirlik tablosu (matrisi) oluşturun,
o Gerçekleme yöntemi ve tasarım detaylarını gereksinimler içine koymaktan
kaçının,
o Bir gereksinim maddesinde sadece bir gereksinimi belirtin,
o Gereksinimi yazarken nasıl test edileceğini de düşünün,
o Gereksinimin gerçek dünyada sağlanıp sağlanamayacağını kontrol edin,
o Sadece normal çalışmayı değil istisnai durumlarda alınacak tutumu da
gereksinimlerde belirtin,
• Sisteme uygun olmayan girdi girildiğinde sistemin davranışını belirtin,
• Sisteme (beklediği) girdi girilmediğinde sistemin davranışını belirtin,
• Sisteme beklenmedik bir bilgi beklenmedik bir zamanda girildiğinde
sistemin davranışını belirtin,
o Sistemin başlatılma ve kapatılma süreçlerindeki davranışını belirtin,
o Gereksinimlerin sistemin hangi mod ve durumlarına ait olduğunu belirtin.
27
 Peki bir gereksinim dokümanı neyi içermelidir?
o İşlev: Yazılımın ne yapması isteniyor? Amacı nedir?
o Kullanım senaryoları (Use Cases): Modern gereksinim dokümanları insan-makina
arasındaki kullanım senaryolarını da içerir.
o İş akışı: Hem modern hem de klasik gereksinim dokümanlarında akış
senaryoları, cihazların iletişim protokolleri, mesajlaşma akışına dair bilgiler yer
alır.
o Dış arayüzler:
• Yazılımın insanlarla olan arayüzü (ekranlar, sesler, vb)
• Yazılımın diğer cihazlarla, sistem donanımı ile ve diğer yazılımlarla olan
arayüzü.
o Performans: Hız, düzgün çalışma oranı, cevap verme süresi, vb.
o Yazılımın özellikleri: Taşınabilirlik, doğruluk, bakımı yapılabilirlik, güvenlik, vb
kriterler.
o Gerçekleme üzerindeki kriter ve kısıtlar: Uygulanan standartlar, uygulama yazılım
dilinin adı, veritabanı politikası, kaynak sınırlamaları, işletim ortamı, vb.
o İşe özel kurallar: Bu kısımda işin karakteristikleri, kendine has özellikleri anlatılır.
o Diyagramlar: Gereksinim dokümanında sadece gereksinim maddeleri bulunmaz,
ayrıca teknik detayları veya büyük resmi daha iyi anlamaya yarayan şemalar,28
şekiller, akış diyagramları da bulunmalıdır.
 Örnek: Açık Bir Gereksinim Maddesi Hazırlamak
İstek 1: Frene basınca araba dursun.

İlk deneme "geçiş, zaman belirsizliğine" sahip bir gereksinim maddesi:

Gerek 1: Frene basınca araba duracaktır.
İtiraz 1: Ne zaman duracak? Basar basmaz mı? Nasıl olacak o iş?

Aşağıda da iki gereksinim belirtilmiş, üstelik eksikler de var:

Gerek 1: Fren pedalına basınca fren pedalı aşağıya inecek ve araba
duracaktır.
İtiraz 1: Fren pedalı aşağıya inmezse ne olacak? Aşağıya inmesi ile
durmanın ne ilgisi var?

29
Aşağıda da koşul kalıbı belirsiz bir gereksinim var.
Gerek 1: Araba duracaktır.
Veya Gerek 1: Araba gerektiğinde duracaktır.
İtiraz 1: Gerektiğinde ne demek? Hangi koşulda duracak?

Bu sefer de başvuru belirsizliği sorununa sahip kötü hazırlanmış gereksinim

örneği:
Gerek 1: Araba bazı durumlarda duracaktır. Bu durumlar için Bölüm 1'e bakın.
İtiraz 1: Bölüm 1'de baktım çok bilgi var, nerede bu "bazı durumlar"?

Daha da yanlış gereksinim örneği, yine başvuru belirsizliği var.

Gerek 1: Araba bazı durumlarda duracaktır. Bu durumlar için frenle ilgili bölüme
bakın.
İtiraz 1: Frenle ilgili bölüme mi bakayım? Ama 100 sayfalık dokümanın yarısı
frenle ilgili zaten. Konu başlığında frenle ilgili mi yazıyor?

30
Şimdi de tasarımın gereksinimlerde yapılması hatasını görelim.
Gerek 1: Fren pedalına basınca hidrolikler harekete geçecektir.
Gerek 1: Hidrolikler harekete geçince tekerleklere basınç
iletilecektir.
Gerek 1: Hidroliklerin uyguladığı basınç tekerlekleri kilitleyecek ve
böylece araba duracaktır.
İtiraz 1: Peki ya fren mekanik olarak gerçeklenirse ne olacak?
Neden hidrolik kısıtlaması koyalım? Bırakalım işin nasıl yapılacağını
tasarımcı düşünsün.

Şimdi de iyi hazırlanmış bir gereksinim görelim.

Gerek 1: Fren pedalına basınca tekerlekler 7 saniye içerisinde
duracaktır.

31
 Bu aşamada yazılımın içerdiği tüm bileşenler ayrıntıları ile
tanımlanır ve tasarlanır.
 Tasarım aşaması zaman bakımından kritik bir aşamadır.
Gereğinden az zaman harcamak ileride büyük sorunlar
doğurur.
 Öte yandan bu aşamada gereğinden fazla zaman harcamak
projenin başarılabilmesini riske sokar.

32
 Kavramsal Sistem Tasarım Dokümanı Hazırlayın
o Kavramsal sistem tasarım dokümanı gereksinimler, kullanım senaryoları ve iş
tanımından yola çıkılarak hazırlanan ve sistem tasarımını büyük resimden
başlayıp daha detaylara inerek anlatan dokümandır.
o Öncelikle bu dokümanda sistemin somut ve soyut elemanlarını, onların
birbirleri ile bağlarını, sistemin dış dünya ile olan bağlarını anlatan sistem
mimari planı bulunmalıdır.
o Eğer varsa sistemin ekran pencerelerinin resimleri, rapor formatları bu
dokümanda belirtilir.
o Bu dokümanın birçok işlevi vardır, bunlar:
• Sistemin ana tasarımının çatısını oluşturmak, yanlış tasarımın önüne geçmek,
• Diğer yazılım ve donanım detay dökümanlarının hazırlanmasına temel teşkil
etmek,
• Yeni başlayan proje elemanlarının yetişmesine ve projeye adapte olmasına
yardımcı olmak,
• Eğitimlerin ve eğitim dokümanlarının hazırlanmasını kolaylaştırmak,
• Know-How’ı arttırarak sistemin bakımını kolaylaştırmak,
• Organizasyonun teknik ve teknik olmayan grupları arasında köprü görevi görmek33
 Projenin Sorumlulukları ve İş Dağılımı Çizelgesi Hazırlayın
o Büyük projelerde en büyük sorunlardan biri kimin hangi işi yaptığının
belli olmamasıdır.
o Özellikle bürü projelerde sorumluluklar ve iş dağılımı çizelgesinin
(matrisinin) olmaması önemli bir sorun olarak karşımıza çıkar.
o Böyle bir çizelge olmaması durumunda:
• Proje ekibi ile iş yapmak durumunda olanlar kiminle irtibat
kuracaklarını bilemezler,
• İşe yeni başlayanlar bilgiye kimden ulaşacaklarını bilemezler,
• İş vermek isteyen amirler iş yükünü ayarlayamazlar, doğru kişiye
doğru işi veremezler,
• Müşterinin sorunu bir türlü doğru teknik kişiye ulaşamadığından
çözüm süresi bir hayli uzar.

34
 Bu çizelge birkaç şekilde hazırlanabilir. Örneğin en basit
halinde:
Proje Lideri Ali
Kontrol Yazılımı Veli
Ekran Tasarımı Mehmet
Haberleşme Altyapısı Ayşe

 Diğer bir şekilde:

Ali Veli Mehmet Ayşe
Proje Lideri Asıl Yedek - -
Kontrol Yazılımı - Asıl Destek -
Ekran Tasarımı - - Asıl Yedek
Haberleşme Altyapısı - Yedek - Asıl
35
 Daha organizasyonel şekilde:
Proje Sahibi Selim
Proje Yöneticisi Salih
Proje Teknik Lideri Ali
Proje Yazılım Ekibi Veli, Mehmet, Ayşe
Müşteri İlişkileri Can
Konfigürasyon Sorumlusu Derya
Satınalma Sorumlusu Fatma
Müşterinin Temsilcisi Hasan
 Ayrıca ağaç dallanması şeklinde hiyerarşik proje sorumluluk
çizelgeleri de hazırlanabilir.

36
 Terimler ve Kısaltmalar Sözlüğü Hazırlayın, kullanacağınız
Birimleri/Limitleri Önceden Belirleyin
o Özellikle büyük ve çok insanın çalıştığı projelerde proje başladığında yapılması
gerçekten çok faydalı olan bazı alışkanlıklar vardır.
o Bunların bir kısmını verecek olursak:
• Tüm projede geçen kavramları, isimleri açıklayan bir terimler sözlüğü; örneğin
sistemlerin adları, sistemin yaptığı önemli işlerin açıklamaları, vb.
Not: Bunun güncel tutulması çok önemlidir.
• Projedeki kısaltmaların açılımları.
• Projede kullanılan birimler kılavuzu; örneğin uzaklık birimi olarak Kilometre mi
yoksa metre mi kullanılacağı, ağırlık olarak Kilogram mı yoksa Pound mu
kullanılacağı, hız ölçüsü olarak Metre/Saniye mi yoksa Km/Saat mi kullanılacağı
gibi.
• Birim zaman belirlenmesi ve kılavuzu; yani sistemin zaman bilgisinin ve artışının
nasıl çalışacağının belli olması; örneğin her birim 10 milisaniyedir, başlangıç saati
olarak Unix saati alınmıştır, göreceli saat olarak maksimum 200000 birimde tur
bindirilir ve bu 4 bayt içinde tutulur gibi.
Not: Yıl 2000 problemi benzeri problemler bir daha olmayacak ve sizin başınıza
gelmez zannetmeyiniz 37
 Kodlama Standartları ve Tavsiyeleri Oluşturup Onları Kullanın
o Koddaki hataları mümkün olan en erken zamanda tespit etmenin hata
düzeltme maliyetini 5 ila 100 kat düşürdüğü artık günümüzde bilinen bir
gerçektir.
o Hataları zamanında tespit etmenin en kolay ve verimli yollarından biri de
kod gözden geçirme (code review) toplantılarıdır.
o Kod gözden geçirme toplantıları yapabilmek için standart bir kod
üretilmesi gereklidir

38
 Kodlama standartlarının faydalarını inceleyecek olursak, standartlara
uyulduğunda:
o Bakım yapılabilirlik artar: Kodlama standartları okunabilirliği büyük ölçüde arttırır ve
karmaşıklığı azaltır. Bu sebeple kod yazıldıktan çok sonra bile kodu anlamak ve hatalarım
çözmek kolay olur.
o Yazılım elemanı bulmak kolaylaşır: Evet yanlış duymadınız kod standartlarına uymak
kodun karmaşıklığını azalttığı ve okunabilirliğini çoğalttığı için daha az kalifiye bir
yazılımcı da bu kodda eklemeler ve düzeltmeler yapabilir. Yetişmiş bir yazılımcı bulmak
çok zordur, kod standartlarına uyulduğunda daha az tecrübeli bir yazılımcı da rahatça bu
kod üzerinde çalışabilir.
o Kodun tekrar kullanımı kolaylaşır: Kodun anlaşılırlığı arttığı için başka projelerde bu kodu
kullanmak da kolaylaşır. Normal koşullarda bu tekrar kullanılan kodun eskiden birçok
teste tabi tutulmuş olduğunu kabul edersek ve şimdi eklendiği yerde de testlere tabi
tutulacağını düşünürsek koddaki hata oram bayağı düşük olur.
o Kalite kuruluşlarından onay almak kolaylaşır: Standartlara uymanın dolaylı bir yararı da
kalite kuruluşlarının denetlemelerinde daha yüksek puan alabilmek ve kalite belgelerine
güvenilir biçimde ulaşabilmektir.
o Dokümantasyon kolaylaşır: Standartlar yorum satırlarına da bir düzen getirdiği için daha
sonra bu yorumlardaki bilgilerden faydalanarak tutarlı dokümanlar hazırlanabilir.
Dokümantasyon ile kod arasındaki uyumsuzluklar minimuma iner. 39
 Kodlama standartlarının faydalarını inceleyecek olursak, standartlara
uyulduğunda (devam):
o Otomatik gözden geçirme gereçlerinin işi kolaylaşır: Standartlara uygun olarak
yazılmış bir kodu otomatik programlarla tarayıp değişik işlemler için kullanmak
kolaylaşır. Bu işlemler için örnek verirsek; satır sayısının hesaplanması,
hataların taranması, kodun karmaşıklığının hesaplanması, değişken
ilklendirilmemesi gibi hataların bulunması, vb.
o Kodun karmaşıklığı azalır: Standart kodlarda karmaşık yapıların kullanımına
izin verilmeyeceği için kodun karmaşıklığı azalır.
o Kodun güvenilirliği artar: Örnek vererek açıklayacak olursak gömülü
sistemlerde dinamik bellek ayrılmasına izin verilmeyeceği için gömülü
sistemlerin sahadaki korkulu rüyası olan null işaretçi hatalarına da rastlanmaz,
kritik bir sistemin sahadayken çökme ihtimali bir hayli azalır.
o Eğitim giderleri düşer: Projeye her yeni başlayan yazılımcı resmi veya gayri
resmi eğitim görür. Yani ya adı konmuş bir eğitim alır ya da kendisi projeyi hatta
kullanılan yazılım dilini öğrenmek için çalışır. Oysa standartlara uyularak yazılan
bir kod adeta bir eğitim kitabı gibidir; gerek yazılım dili gerekse projenin
detayları konusunda yeni başlayan elemana eğitim kaynağı olur. 40
 Kodlama standartlarının faydalarını inceleyecek olursak, standartlara
uyulduğunda (devam):
o Bilgi birikimi sağlanır: Standartlara uyulan bir kod gerek hazır kodlanmış
algoritmalarıyla, tasarım desenleri ile gerekse sık yapılan hataların çözümleri ile yeni
yazılımcıya önderlik eder.
o İzlenebilirlik artar: Standartlara uyulan kodlarda gerekirse kod parçası- karşıladığı
gereksinim gibi özellikler not edilebileceği için gereksinimlerin karşılanıp
karşılanmadığını izlemek kolaylaşır.
o Farklı kaynaklardan gelen kodlan bir arada kullanmak kolaylaşır: Kodlama standartları
uygulandığında isim uzayları (name space) uygulanacağından aynı isimli değişkenlerin
çakışması engellenmiş olur. Örneğin A firmasının ve B firmasının kaynak kodlarında
“kullanıcıAdı” diye bir değişken olsa bile farklı isim uzaylarında olacakları için derlemede
sorun olmayacak ve kodlar birlikte derlenebilecektir.
o Koddaki hata miktarı azalır: Genelde kodlama standartları her yazılım dili için özel
olarak hazırlanırlar. Bu sayede, kodun yazımı sırasında oluşan hataların en aza
indirilmesi amaçlanır.
 Kodlama standartlarınızı sadece bir proje için değil tüm projelerde kullanmak
üzere oluşturmalısınız. Projenin başından sonuna kadar standartlara uyumu
denetlemelisiniz, kodunuzu projenin en sonunda standartlara uydurmaya41
çalışmamalısınız.
 Ne Gerek Var Dokümana Ben Varım ya
o Yazılım geliştirme dokümanları yazılımın tekrar edebilen bir başarıyı
yakalayabilmesi için gerekli öğelerinden biridir. Bu dokümanlar
sayesinde;
• Yazılımın takibi kolaylaşır,
• İş bölümü sağlanır,
• Yazılımın bakımı kolaylaşır,
• Yeni elemanların eğitimi kolaylaşır,
• Yazılımın yönetiminin yapılması, örneğin bütçesinin ve takviminin
hazırlanması kolaylaşır,
• İstatistiki veriler hazırlamak kolaylaşır,
• Kullanıcıların yazılımı öğrenmesi ve kullanması kolaylaşır.

"Programlama alanında, dokümante edilmemiş bir programdan

daha değersiz bir şey yoktur."
Ed Yourdon 42
 Yazılım projelerinde standart yayınlayan kuruluşlar vardır ve
dokümantasyon biçimi ile ilgili önerilerde bulunurlar.
 Hepsinin doküman önerilerindeki ortak noktalarını bulmaya çalışırsak
bir yazılım projesinde hazırlanan dokümanlar şunlardır;
o Süreç dokümanları:
• Yazılım standartları
• Raporlar, hata bildirim formları, iş yapma tarif formları,
• Kalıcı teknik kaynaklar, kitaplar, makaleler,
• Anlık teknik kaynaklar, e-mailler, vb.
o Proje ve Ürün Dokümanları
• Gereksinim dokümanı
• İşlevsel tasarım dokümanı
• Detaylı tasarım dokümanı
• Test dokümanı
• Test raporu 43
 Yazılım geliştirirken hazırlanacak dokümanların uyması gereken
biçimleri ve niteliklerine ilişkin standartlar geliştirilmiştir.
o IEEE (Institute for Electrical and Electronic Engineering) enstitüsünün "IEEE
Standard for Software User Documentation” isimli standardında
dokümanların hazırlanmasına dair genel kurallar anlatılır.
o Yine ISO (The International Standards Organization) organizasyonu ve IEC
(The International Electrotechnical Commission) komisyonu ISO/IEC 18019-
2004 (Guidelines for the design and preparation of user documentation for
application software) yayınında içerik ve niteliğe ait kurallar ve ISO/IEC TR
9294 (Guidelines for the management of software documentation)
yayınında doküman yönetimine ait kurallar bulunabilir.
 Yeni çıkan “ISO/IEC 26514:2008 “Systems and software engineering
- Requirements for designers and developers of user documentation”
da doküman hazırlanırken dikkat edilmesi gereken kuralları anlatır.

" Siz bir düşüncenizi bir yere yazana kadar o düşünce bir fikir değildir."
Ivan Sutherland 44
 
 Gerçekleme aşaması kodun yazılmaya başlandığı aşamadır.
 Tasarımın belli bir seviyeye gelmiş olması gereklidir.
 Gerçekleme aşamasında büyük risklerden biri izlenebilirliğin iyi
olmamasıdır. Bu aşamada herhangi bir anda gerçeklemenin ne
kadarının bittiğini ve geriye ne kadarlık iş yükünün kaldığını
belirlemek zor ve yapılması da o kadar önemli bir iştir.
 Bu aşamada herhangi bir anda ne durumda olduğunuzu net
olarak bilirseniz, proje süresi hakkında çok gerçekçi
tahminlerde bulunabilir ve riskleri aşabilirsiniz.
 Hiçbir Şey Yapmayan Bir Kod Yazın
o Bir projede sistem üzerinde koşturulabilen bir programı görmek
(program çok az iş yapsa ve hatalarla dolu olsa bile) gerek moral
motivasyon gerekse büyük resmi anlamak açısından çok faydalıdır.
o Kodlamaya başladığınızda ilk işiniz bir iskelet oluşturmak olsun.
o Derleme ve bağlama işlemlerinizi geçtiğinden emin olduğunuz bu iskelet
üzerinden kodlamaya devam edin.
o Daha sonra henüz içleri boş olan ana işlevlerinizi kodlayın. Bu anda da
kodunuzun derleme ve bağlama işlemlerinde takılmadığını gösterin.
o İçleri boş da olsa ana işlevleri kodlamak tasarımınızın sağlamlığını da
teyit eder. Henüz hiçbir iş yapmayan bu kodunuzu mümkünse çalıştırın
ve işlevlerin birbirini sağlıklı bir şekilde çağırdığından emin olun.
o Bu aşamada hiçbir iş yapmayan işlevlerin içine ekrana bilgi verici satırlar
döken satırlar ekleyebilirsiniz. Böylece kod akışını tespit edebilirsiniz.
 Hiçbir Şey Yapmayan Bir Kod Yazın (devam)
o Özellikle çok kodlayıcılı sistemlerde iskelet oluşturarak kodlamanın çok
faydası vardır.
o Öncelikle motivasyon faydası vardır; çok az iş yapsa bile sonuçta
birşeylerin çalıştığını görmek ekip elemanlarının motivasyonunu
yükseltir.
o İkinci sebep de belli bir aşamadan sonra ekipteki her kodlayıcı kendi
kodunu bağımsız olarak kodlayabilecek ve test edebilecektir.
o Entegrasyon genelde çok zaman alıcı ve üstelik de planlara konulması
unutulan veya ihmal edilen bir safhadır. En başta iskelet oluşturup bu
iskelet sürekli derlenebilir ve çalıştırılabilir durumda tutulduğunda
entegrasyon süresinden de bayağı tasarruf edilir.
o Unutmayın ki tüm kod bir seferde yazılamaz. Programlar canlı
organizmalar gibi büyür ve gelişirler. Hiç kimsenin büyük bir adam/kadın
gibi dünyaya gelemeyeceği gibi programlar da önce bebek olarak
dünyaya gelmek zorundadır.
 Yazılım Sürüm Tutma Gereçleri – Konfigürasyon Yönetimi
o Mutlaka bir sürüm tutma yazılımı kullanın.
o Sürüm tutma yazılımları 3 ve daha fazla kişinin bulunduğu
projelerde kritik öneme sahiptir ve kullanılmaları kaçınılmazdır.
o Ancak tek başına bile çalışıyorsanız bir sürüm tutma yazılımı
kullanmanızı tavsiye ederim.
 Yazılımınızı Tek Bir Yerde Saklamayın
o Bilgisayarım çökecek mi diye düşünmeyin. Evet mutlaka çökecek.
Yazılımınızı mümkün olan en kısa periyotta yedekleyin.
o Modern editörlerin çoğu otomatik kaydetme (Autosave) özelliğine
sahiptir. Bu özelliği mutlaka açık duruma getirin ve örneğin her 10
dakika gibi bir saklama aralığı belirleyin.
 İyi Kod Basit Olandır ( KISS Prensibi – Keep It Simple)
o Kodu yeni mezun olmuş birine verin. Eğer birkaç gün içinde adapte
olabiliyor ve kodu değiştirebiliyorsa kodunuz iyi bir koddur, eğer kodu
değiştirmek için uzman bekliyorsanız iyi bir kod değildir.

"Zarafet (Basitlik, sadelik, açıklık) çöpe atılabilir bir lüks değil, aksine başarı
ve başarısızlık arasındaki seçimi belirleyen bir özelliktir."
Edsger W. Dijkstra – Dijkstra Algoritması'nın yaratıcısı
"Eğer bir programın genel yapısını duş alırken tüm özüyle kavrayamıyorsanız o
programı kodlamaya hazır değilsiniz demektir."
Richard Pattis - University of California, Irvine
"Yazılım tasarımını kurabilmek için iki yöntem vardır: Birinci yöntemde tasarım
o kadar basit yapılır ki ortada hiçbir eksiklik kalmaz, ve diğer yöntemde
tasarım o kadar karmaşık yapılır ki ortada hiçbir eksik fark edilmez. Elbette
ilk yöntem daha zordur."
C.A.R. Hoare – Quicksort'un yaratıcısı
 İyi Kod Anlaşılır Olandır
o Anlaşılır kod başkaları tarafından okunacağı düşünülerek yazılmış olan
koddur.
o Anlaşılır olması için mucizelere gerek yoktur; paragraf girintilerinin
düzenli olması, değişkenlerin iyi adlandırılmış olması, işlevlerin
(fonksiyonların) sadece tek işi yapması ve yine iyi adlandırılmış olmaları
vb. konulara dikkat etmek bile anlaşılırlığı gayet arttırır.

"Cinayet gizemlerini çözmeye "tamam" denilebilir ancak bir yazılım kodunu

çözmek ihtiyacını duymamalısınız. Yani kodu basitçe okuyabilmelisiniz."
Steve McConnell – "Code Complete" Kitabının Yazarı
 İyi Kod Değiştirilmesi ve Bakımı Kolay Olan Koddur
o Değiştirilmesi kolay ve güvenli kod "bakım yapılabilir" koddur.
o Projedeki en büyük maliyet öğelerinden biri bakımdır. Bakım yapılabilir kod
anlaşılır, bilgi verici, değişikliklere uyum sağlayabilir ve hata ayıklaması kolay
olan koddur."
o Kodun bakım yapılabilir ve sürdürülebilir olması için şunlara dikkat edilmelidir:
• Test kodu yazın
• Modüler tasarım yapın
• Kodlama standartları uygulayın
• Uygun isimler kullanın
• Sürekli-iyileştirme (Refactoring) yapın
• Kod tekrarını önleyin
• Mümkünse okunaklılığı performansa tercih edin
• Uzun metotlardan kaçının
• Standart algoritmalar ve haberleşme protokolleri kullanın
• Ne kadar zeki olduğunuzu kodda göstermeye çalışmayın
• Projenizi dokümante edin ve iyi yorumlar yazın
 İyi bir Kod Veri Yapıları İyi Kurulmuş Olandır
o Yazılıma yeni başlaynların yaptıkları ihmallerden biri de veri yapılarına gereken
önemi vermemek ve onları yeterince öğrenmemektir.
o Genellikle kısa bir sürede karmaşık algoritmaların kodlaması başarılabilirken,
veri yapılarını özümsemek ve beyinde sağlam bir yere oturtmak yılları almaktadır.
o Usta tasarımcılar genelde çok kaliteli algoritmalar bilen insanlar değildir, aksine
üniversiteden yeni mezun olmuş biri hesaplama ve algoritma kurmada daha
başarılı olabilir, ancak iş veri yapılarını kurmaya geldiğinde gerçekten de bilgi
birikimi ve tecrübe ön plana çıkmaktadır.
o Veri yapıları en az algoritmalar kadar önemlidir.
"İyi veri yapıları ve kötü kod, bu ilişkinin tam ters olduğu durumdan çok daha iyi
çalışır." Eric S. Raymond – Açık Kaynak Yazılımın Öncülerinden

"İddiam şu ki iyi programcı ve kötü programcı arasındaki fark o kişinin kodunu mu

yoksa veri yapılarını mı daha önemli gördüğüne bağlıdır. Kötü programcılar kodları
için kaygılanırlar. İyi programcılar ise veri yapıları ve onlar arasındaki ilişkiler için
kaygı duyarlar." Linus Torvalds
 İkinci Kodlama Sürümü İle İlgili Garip Olay ( Second System Effect – Fred
Brooks)
o Ürettiğiniz ufak, amaca uygun, hızlı çalışan birinci sistemi veya yazılım sürümünü başarı
ile teslim ettiniz.
o Ardından aynı sistemin daha gelişmişi olan ikinci sürümü üretmek için işe koyuldunuz
ancak ikinci sisteminiz kocaman hantal bir su aygırı olarak çıktı 
o Yeni sürümde birçok yeni özellik koydunuz ancak bu özellikler sistemi yavaş ve hantal
hale getirdi. Bu ikinci kez düzenlenmiş sistemlerde veya kodlama sürümlerinde sık
rastlanan bir olaydır.
o İnsanlar bu benim başıma gelmez diye düşünür ama dikkat etmezseniz başınıza kolayca
gelir. – (Brooks, 1995)
o İkinci sürümün garip çıkmasının birçok sebebi vardır. Bir sebebi birinci sürümün
başarısının getirdiği aşırı kendine güvendir. Birinci sistemde eksik kalan özellikleri koyma
çabası ile hantal, kullanışsız ve özellik çorbası bir sistem üretmek işten bile değildir.
o Aslında birinci sistemi yaparken gerçekten gerekli ve performansı bozmayacak özellikleri
sisteme koyduğunuz halde ikinci sistemde çok da gerekmeyecek, karmaşık özellikleri de
sisteme koyma hatasına düşülür.
o Diğer sebep de birinci sistemdeki başarının iyice irdelenmemesidir. Birinci sistem neden
başarılıdır? Örneğin birinci sistemde fazla özellik yoktur ve kullanması kolaydır. Örneğin
sistem kaynakları sisteme tam yetmiştir ve bu yüzden sistem performansı en tepededir.
Oysa şimdi ikinci sistemi yaparken bu koşulları bozduğumuzun farkında olmak gerekir.
 Bu da Olsun, Şu da Olsun (Feature Creep (Özellik Yığışımı))
o Bir programı bir ev gibi düşünecek olursak, yani benzetme yaparsak:
• Başlangıç ve ana ihtiyaçlar aşaması – Eve ilk taşındığımızda birçok eksik
vardır. Evi temel ihtiyaçları görecek şekilde donatırsınız.
• Olgunluk aşaması – Evdeki ana eksikleri gidermiş ve sizin için gerekli diğer
ihtiyaçları da sağlamış durumdasınızdır, ve hatta hayatı kolaylaştıracak bir
iki lüksünüz de vardır.
• Dolup taşma aşaması – Ev dolup taşmaktadır, bir şeyi yapmak için her
gereçten iki tane vardır, herkes bir şeyler hediye etmiştir ve gerçekten
hangisini kullanacağım diye kafanız karışmaktadır, evde hareket etmek
iyice zorlaşmıştır, zaman zaman kazalar meydana gelmektedir. Bir şeyleri
atmak istemektesinizdir ama birilerinden çekindiğiniz için
atamamaktasınızdır.
 Bu da Olsun, Şu da Olsun (Feature Creep (Özellik Yığışımı)) - devam
o İşte "Bu da olsun, şu da olsun" ya da İngilizce adı ile "Feature Creep"
yukarıdaki örnekteki gibi dolup taşma aşaması gibidir. Program birçok gereksiz
özellik ile dolup taşmakta, iyice yavaşlamış durumdadır. Kullanıcılar
menülerde kaybolmaktadır. Bazı menüler eski mantıkla, bazıları yeni mantıkla
yazılmıştır ve bir işi yapmak için birçok menü seçeneği vardır. İnsanların kafası
iyice karışmıştır. Bakım maliyeti zorlaşmıştır. En kötüsü de geliştirme süresi
kadar bir süre de bu ıvır zıvır ve gereksiz özellikleri gerçeklemek için
harcanmış ve maliyet kat kat artmıştır.
o Bu olay birçok projeyi başarısızlığa uğratan ana etkenlerden biridir. Sağlıklı
çalışan bir programınız varsa ona yeni eklemeler yapmadan önce iki kez
düşünün. Kullanıcıların kullanma alışkanlıklarından programın performans
kriterlerine kadar birçok konuyu gözden geçirin. Bu özellik gerçekten gerekli
mi diye kendinize mutlaka sorun. Eğer bütün bunlara cevabınız olumlu ise
ancak bu durumda özelliği gerçekleyin. Özellikle de kimsenin kullanmayacağı
özellikleri programınıza eklemekten kararlı bir biçimde kaçının.
"Tasarımda mükemmelliğe, daha fazla ekleyecek özellik kalmadığında değil, daha
fazla atılacak şey kalmadığında ulaşılır."
Antoine de Saint-Exupéry, "Küçük Prens"in Yazarı
 Scope Creep (Hedef Yığışımı)
o Literatürde birbirine çok yakın iki kavram vardır: Scope Creep (Hedef
Yığışımı) ve Feature Creep (Özellik Yığışımı).
o Eğer müşteri istekleri ve gereksinimleri sürekli değişiyor ve kontrolsüzce
artıyorsa buna Hedef Yığışımı adı verilir.
o Eğer proje takımı durmadan aslında pek de gerekli olmayan özellikleri
yazılıma ekleyip duruyorsa buna Özellik Yığışımı adı verilir.
o Sonuçta her ikisi de şişmiş bir yazılıma sebep olur. Bunların sonucunda
sistemde performans sorunları oluşur, karmaşık ve kullanması zor bir sistem
üretilmiş olur. Bütçe ve zaman aşımı oluşur. Kalite düşer. Rünün bakımı
zorlaşır.

"Karmaşıklığın temel bir nedeni şudur ki üreticiler kullanıcıların istediği hemen

her özelliği fazla incelemeden, üzerinde düşünmeden benimseyip
gerçekleştirmektedirler."
Niklaus Wirth – Pascal'ın Yaratıcısı
 Altın Harflerle Yazmaya Çalışmak (Gold Plating)
o Özellik yığışımına çok yakın diğer bir kavram da "Altın Harflerle
yazmaya çalışmak" kavramıdır.
o Aşırı mükemmeliyetçi bir yaklaşımdır.
o Gerçekleştiricilerin mükemmel bir sistem üretme amacına saplanıp
detaylarda boğulması ile sonuçlanır.
o Proje süreleri aksar, sistemin bir bölümü mükemmel iken diğer
kısımlarının üretimine hiç başlanmamış olabilir.
 Hata Bildirim Sistemi Kullanın
o Öncelikle bir hata bildirim sistemi (Bug Reporting System) kurun.
o Bu hata bildirim sistemi kağıtlarla yürüyen bir sistem olabileceği gibi daha
da iyisi bir program aracılığıyla işleyen bir sistem olmalıdır.
o Bu sistemde hata adı, hatanın detayları, oluşma koşulları, hatayı kimin
bildirdiği, hatanın düzeltim durumu, hatayı kimin düzelttiği, hatayı kimin
düzelmiş olarak kabul ettiği gibi bilgiler bulunmalıdır. En tercih edilen
durum hatayı açan kişinin kapatan kişi olmasıdır.
 Birim Testleri Yazmayı Alışkanlık Haline Getirin
o Birimler kullanıcıların mantıklı olarak bölebileceği ve tek bir işi yapan en
küçük parçalardır. Bu birim gerçekten tek bir işi yapan bir işlev (fonksiyon)
olabileceği gibi bir iş grubunu içeren bir dinamik bağlı kütüphane (DLL) de
olabilir. Birim testi sadece bir birimi test etmek için yazılmış olan testtir.
o İdealde birim testleri ilgili test edilecek birimden daha önce yazılmalıdır. Evet
yanlış duymadınız test kodu daha önce yazılmalıdır. Eğer buna zaman
bulamazsanız birim testleri kodla aynı zamanda yazılmalıdır. Birim testleri
koddan sonra yazsanız dahi hiç yazmamaktan iyidir.
o Birim test kodu, ilgili ürün kodunun içerisinde yer almaz. Ayrı dosyalarda, ayrı
modüllerde tutulurlar.
o Birim testlerinin tümünün başarılı olarak geçmesi yazılımın bütününün
başarılı olduğu anlamına gelmez. Bütünün başarı oranı entegrasyon,
kurulum ve saha testlerinde ortaya çıkacaktır.
o Birim testler özellikle gerileme kontrolünde (yani yeni kod eklediğimizde
başka birşeyi bozmuş muyuz kontrolünde) çok faydalıdır. Özellikle otomatik
birim testleri size günler kazandırır ve piyasaya bozuk ürün sunup müşterinin
size olan saygısını yitirmenize engel olur.
 Birim Testleri Yazmayı Alışkanlık Haline Getirin (devam)
o Birim testleri test aşamasında değil de gerçekleme aşamasında
incelememizin sebebi birim testlerin gerçekleme aşamasının en başından
başlanıp yazılması gereken testler olmasıdır.
o Birim testlerin dezavantajı test yazmak için de zaman harcanacak
olmasıdır, ancak bu zaman daha sonra birim testlerin sağlayacağı faydalar
ile telafi edilebilir. Birim testler çıkabilecek hata sayısını çok büyük oranda
azaltır.
o Diğer zorluk ise tüm ekibin birim test yazmaya başlamasıdır. Bir kişi bile
direnç gösterse onun yazdığı kısımlar birim testlerden geçmediği için eksik
kalır. Örnek verecek olursak herhangi bir modülü birim testlerinde ihmal
etmek, fren borularından sadece bir bozuk araba ile yola çıkmaya benzer.
o Birim testleri yazmak her zaman uygun yada yapılabilir olmayabilir. Örneğin
kullanıcı arabirimi (GUI) için birim test yazmak çoğu zaman zor hatta
imkansızdır.
o Birim testler her zaman günce tutulmalıdır. Birim testler de yazılımın bir
parçası imiş gibi onları korumalı, güncellemeli ve bakımını yapmalısınız; bu
da kuşkusuz ekstra maliyettir. Ancak tüm maliyete karşın birim testler size
çok yarar sağlayacaktır.
 Kod Gözden Geçirme Toplantısı
o Kod gözden geçirme toplantıları sisteminizde oluşacak hataları önceden
engellemenizi sağlar. Çok yararlı olan kod gözden geçirme toplantılarının
kullanımı önerilmektedir.
o Kod gözden geçirme toplantısında bulunacak kişiler ve görevlerini
listeleyecek olursak:
• Kodun kodlayıcısı,
• Moderatör (Toplantının yöneticisi)
• Okuyucu (Kodu veya dokümanları adım adım okumak veya izleyebilmek için)
• Yazıcı (İşlem maddelerini ve önerilen düzeltmeleri/iyileştirmeleri not etmek
için)
• Yorumcular (Her seviyeden yorum veren yazılımcılar ve öğrenim için katılan
yeni yazılımcılar)
"Gözden geçirme işlemleri üretkenliği, kaliteyi ve proje kararlılığını
(stabilitesini) büyük ölçüde arttırır."
Michael E. Fagan – Yazılım Test Uzmanı
 Mentorluk (Abilik, Ablalık)
o Genellikle yeni işe başlayan yazılımcılar bir iki kursa gönderildikten
sonra ve bazen hiç kursa bile gönderilmeden onlardan artık iş
çıkarmaları beklenir. Oysa örneğin bir iki kursa gitmiş bir işletmeciyi
şirketinizin mali hesaplarını yönettirir misiniz, veya bir iki kursa
gitmiş bir avukata kendinizi savunma görevini verir misiniz? Tabii ki
hayır. Yazılım işi de bu kadar ciddiye alınması gereken bir iştir. İyi bir
yazılımcının yetişmesi yıllar alır.
o İlk eğitimden sonra yazılımcı daha tecrübeli bir yazılımcı ile birlikte
ve hatta onun gözetiminde çalıştırılmalıdır. Yeni yazılımcının birlikte
çalışacağı mentor iletişim kabiliyeti yüksek, teknik olarak sağlam ve
mentorluk tecrübesi olan bir kişi olmalıdır.
o Ayrıca mentor sadece eğitimci değil projelerde aktif görev alan, proje
detaylarını bilen bir insan olmalıdır. Herhangi bir kişi mentorlük
yapamaz, bu özel yetenekler gerektirir.
o Mentor başına düşen yeni yazılımcı sayısı da fazla olmamalıdır.
 Test süreci en az kodlama süreci kadar önemli ve bir o kadar zaman
ayrılması gereken bir süreçtir.
 Testlerde test sonuçları yorumlanırken sadece testlerin geçip
kalmasına değil aynı zamanda altta yatan sebeplerin araştırılmasına
da önem gösterilmelidir.
 Bugün artık biliyoruz ki bir hata ne kadar geç tespit edilirse onu
düzeltmenin maliyeti de katlanarak artar.
 Yazılım testi bu kadar önemli bir işlev olduğu için de mutlaka ayrı bir
ekibin bu iş için görevlendirilmesi gereklidir.
 Yine tecrübelerimizle biliyoruz ki iyi yazılımcılar kendi kodları için
genellikle iyi testçiler değildirler, bunun en önemli sebebi de insanın
kendi hatalarını görememesidir, zaten kendi hatalarını görebilseydiler
kodu yazarken doğru yazarlardı.

"Bir kodlayıcı kendi kodunu test etmek için uygun bir seçim değildir."
Weinberg Yasası
 Testte dikkat edilecek konulardan bir diğeri de ürünün test ile
kapsanan kod miktarıdır. Yani testin kodun ne kadarındaki hatalarını
çıkarabildiğidir. Testin kalite unsurlarından biri de budur.
 Ancak yüzde yüz test ne yazık ki mümkün değildir. Yazılmın
karmaşıklığı ve dallanıp budaklanma özelliğinden dolayı kodunuzu ne
kadar test ederseniz test edin mutlaka hatalar kalacaktır. Bu sebeple
testlerde öncelik ve kapsam belirlemek önemlidir.

"Bir programda ne kadar çok hata bulduysanız (artık hata kalmadı

zannetmeyin) bir o kadar daha hata var demektir" :)
Anonim

"Testler yazılım hatalarının varlığını gösterir ancak ne yazık ki hataların

yokluğunu gösteremez."
Edsger W. Dijkstra
 Test sırasında dikkat edilmesi gereken bir diğer konu da testlerin
sürekliliğidir. Genelde testleri ürün hazırlandıktan sonra yapma gibi bir
hataya düşülür, oysa ki testler daha ürünün gereksinimleri hazırlanırken
yapılmaya başlanmalıdır.
 Bunun mutlaka klasik anlamda test olması gerekli değildir, gereksinim
gözden geçirmeleri de test sayılır.
 Daha sonra kod gözden geçirme toplantıları, otomatik kod tarayıcılarla
kodun taranması, birim testleri, tümleştirme testleri, sistem testleri, kabul
testleri, kurulum testleri, gerileme (regresyon) testleri gibi birçok testin
ürünün geliştirilme süresi boyunca yapılması gereklidir.

"Test süreci hem işlevi hem de yapıyı test etmelidir."

Anonim
 Yazılım testleri konusundaki standartları listeleyecek olursak:
o IEEE Standard for Softvvare Test Documentation (IEEE/ANSI Standard 829),
o IEEE Standard of Softvvare Unit Testing (IEEE/ANSI Standard 1008),
o IEEE Standard for Software Quality Assurance Plans’ (IEEE/ANSI Standard 730).
 Bir Hata Sadece Bir Kez Bir İnsan Tarafından Tespit Edilmelidir
o Programlama metodunun önerilerinden biri de budur ve gereksiz iş
tekrarını azaltmayı amaçlar, eresi şudur, bir hata tespit edildiğinde
derhal o hatayı belirleyen bir test yordamı yazılmalı ve otomatik test
listesine eklenmelidir.
o Daha sonra böyle bir hata oluşursa otomatik testler bu hatayı hemen
tespit edecek ve önceden not edilmiş olan çözüm uygulanacaktır. Bu
sayede bu durumda bir yazılımcı günlerini bu hatayı tespit etmek ve
düzeltmek için harcamayacaktır.
o Yararı çok olan bu tür testlere gerileme testleri (regresyon testleri) adını
veririz. Bu testleri yazılımın gerilemesine izin vermeyen testlerdir
anlamında düşünebilirsiniz.
"Bulunan her hata için ilişkili bir test yazılmalıdır. Bu test projenin ana test
kütüphanesine kalıcı olarak eklenmelidir."
Bertrand Meyer – Eiffel Programlama Dilinin Yaratıcısı
 Test Yapmanın Genel Kuralları
o Erken Test Edin - Sistemde çıkacak bir hatanın gereksinim aşamasında çıktığında bir
birimlik düzeltme maliyeti varsa kodlama sırasında aynı hata bulunduğunda onlarca
birim maliyetinin olduğunu ve ürün sahaya sürülüşünde aynı hatanın bulunması
durumunda binlerce kat fazla düzeltme maliyetinin olduğunu biliyoruz. Bu sebeple
testler mümkün olduğunca erken başlamalıdır. Gereksinimlerin toplanma aşamasında
gözden geçirme toplantıları olarak başlayan aktiviteler de testlerin bir parçasıdır.
o Sık Test Edin - Her vazılım sürümü ve iterasyonundan sonra mutlaka testler yapılmalıdır.
Gerileme (regresyon) testleri uygulanmalıdır. Gerileme testleri bir iterasyondan sonra
yapılan yeni eklemelerin sistemi bozup bozm adığını tespit etmek için yapılan testlerdir.
Testler projenin en başından en sonuna kadar biçim değiştirirler. En başta gereksinim
gözden geçirmeleri, teorik hesapların sağlamaları ve kontrolleri şeklinde başlayan testler
daha sonra klasik anlamdaki testler ile devam eder ve nihayet entegrasyon ve saha
testleri ile devam eder.
o Yeterince Test Edin - Bir sistemi tamamen ve tüm yönleri ile test etmek gerçekçi bir
yaklaşım değildir. Test etmenin bir maliyeti vardır. Testin getirisi maliyetinden yüksek
olduğu sürece test yapılır. Yeterince test yapmak ne kadar önemli ve faydalı ise fazla test
yapmak da o kadar maliyetlidir. Bu sebeple test getirisini maksimuma ulaştırmak için
çeşitli optimizasyon yöntemleri uygulanır. Örneğin:
• Sistemin en riskli alanları daha yoğun test edilir, öncelik sıraları uygulanır.
• Yeterince test yazılır ve bu testler tekrar tekrar kullanılabilir şekilde düzenlenir.
• Otomatik test yöntemleri kullanılır.
• İstatistiki hesaplamalar yapılır. Örneğin başlangıçtaki tahmini hata oranları, testlerin hata
bulma oranları ve testler sonuna kalan hataların tahmini miktarı gibi değerlerden faydalanılır.
 Projede Yapılabilecek Testler Nelerdir?
o Birim (Unit) testleri: Yazılımı oluşturan her parçanın tek olarak testidir. Bu
parçalar bir çalıştırılabilir program, bir dinamik kütüphane (dll), bir sınıf
(class) hatta bir özellik grubu bile olabilir.
o Birleştirme (Entegrasyon) testi: Yazılımı oluşturan birimler bir araya
getirildikten sonra uyumlu çalışıp çalışmadıklarını kontrol etmek için yapılır.
o Performans testi: Ürünün zorlu koşullarda sağlıklı çalışıp çalışmadığını
saptamak için yapılır. Çeşitli tipleri mevcuttur:
• Mutlu patika (Happy path) testi: Sistem zorlanmaz, sistemin beklediği en uygun
değerler sisteme girdi olarak verilir. Genelde sistemin daha tamamlanmadığı,
yeni yeni tümleştirilmeye çalışıldığı zamanlarda uygulanan yöntemdir. Daha sonra
diğer testler ile desteklenmesi gerekir.
• Çevresel ortam testi: Program değişik ortamlarda değişik makinelerle, değişik
insanlar tarafından kullanılır, hatta ürünün özelliğine göre sıcaklık, titreşim,
voltaj, vs değerler değiştirilerek ürün test edilir.
• Toparlama testi: Sistemin yazılım/donanım çökmelerinde, elektrik amalarında,
sıcaklık, nem, mekanik zorlama durumlarında veya diğer anormal durumlarda
dayanıp dayanmayacağım ve bu durumlarda geri toparlanıp toparlanmayacağını,
bunu başarabilme oranını ölçen bir testtir.
• Koşturma ortamı testi: Yazılımın sadece laboratuar sisteminde değil diğer birden
fazla koşturma ortamında sağlıklı çalıştığını test etmek için yapılır.
 Projede Yapılabilecek Testler Nelerdir? (devam)
• Uyumluluk testi: Yazılımın çeşitli donanım, (uygunsa) işletim sistemi, ağ (network), yazılım ile
uyumlu çalıştığının testidir.
• Uç değerler testi: Sistemin alabileceği maksimum ve minimum değerler sisteme girdi olarak
verilir.
• Hatalı kullanım testi: Sisteme yanlış, eksik bilgiler girilir, yanlış zamanda yanlış komutlar ve-
rilir, bu ve benzeri durumlarda sistemin çökmediği test edilir.
• Yükleme (Load) testi: Sistemin sınırları zorlanır, örneğin kayıt tutuluyorsa maksimum kayıt
miktarı yaratılır (veri yükleme), kullanıcı bağlanıyorsa maksimum kullanıcı ile bağlanılır, ha-
fızası zorlanır, varsa sabit diski zorlanır, vs.
• Rastgele değer testi: Rastgele değerler girildiğinde sistemin doğru çalıştığı teyit edilmeye ça-
lışılır. Diğer testlerin açıklarını kapatan bir sigorta gibidir. Özellikle uç değerler testinde düşü-
nülmemiş olan durumları iyi saptar. Örneğin öngördüğümüz maksimum değer ve minimum
değerlerde sistem sağlıklı çalışıyordur ama negatif bir değer verildiğinde sistem çöküyor ola-
bilir, uç değer testinde bu durum göz önüne alınmamışsa rastgele testlerde bu durum yakala-
nabilir.
• Kurulum/silinim testi: Yazılımın kurulum (installation) ve kaldırma işleminin (uninstallati- on)
sorunsuz olarak yapıldığının testidir. Yazılımı defalarca kurup silmek, değişik platformlarda,
değişik zamanlarda kurup silmek, değişik kod büyüklüklerinde, konfıgürasyonlarda veya
değişik versiyonlarla bu işlemi tekrarlamak örnek olarak verilebilir. Yazılımı yükseltmek (upg-
rade) de diğer bir örnek olabilir.
• Güvenlik testi: Sistemin yetkili olmayan kişilerce kullanılmaya izin vermeme yeteneği, yazılı-
mının ve verilerinin zarar görmeme yeteneği gibi testler yapılır
 Projede Yapılabilecek Testler Nelerdir? (devam)
o Kullanım Senaryoları testi (işlev testi): Ürünün değişik kullanım öykülerinde sağlıklı
çalışıp çalışmadığı test edilir. Bu kullanım öykülerinin şartları proje gereksinimlerinde
yazılı olabilir veya vazılması ihmal edilmiş olabilir, bu önemli değildir, zaten
amaçlardan biri de gereksinimlerde vazılı olmayan ama ürünün kalitesi için gerekli
olan özelliklerin varlığını test etmektir.
o Kullanım kolaylığı testi: Sistemin kullanıcı dostu olup olmadığı test edilir. Örneğin
sistemde ekran ve tuş takımı varsa genel kabul görmüş kısa yollara uyulup
uyulmadığı kontrol edilir. Yazılımcı ve testçiler zaten sistemi rahatça kullanabilecekleri
için bu testte kullanılmaz. Muhtemel kullanıcılar, hatta bazen herhangi bir insan
kullanılır.
o Yoldan geçen adam testi: Yazılımcılar ve testçiler sistemi normal kullanım şekline
göre kullandıkları için bazen kritik hataları bulamazlar. Oysa herhangi bir insana
sistemi kullandırdığınızda bazen sistemi hiç tahmin etmediğiniz şekilde çökertir. Bu
sebeple bu tip teste yoldan geçen adam testi denir.
o Kabul testi: Gereksinimlerin doğru olarak gerçeklenip gerçeklenmediğini test etmek
için yapılır.
o Saha, kullanım veya piyasaya sunum testi: Bu testlerde sistemin gerçekten çalışacağı
ortamlarda veya sistemi gerçekten kullanacak kişilerin kullanımı ile testler yapılır.
 Projede Yapılabilecek Testler Nelerdir? (devam)
o Gerileme (Regresyon) testi: Ürüne yeni özellik eklendiğinde performans
veya çalışma doğruluğunda bir gerileme olup olmadığını tespit etmek için
yapılır.
o Testlerin testi: Ürünü test etmek için kullanılan testlerin doğruluğunu
sorgulamak için yapılır. Bu testler dokümanlarda madde madde yazılı
testler olabileceği gibi test programları veya otomatik koşturulan testler
olabilir. Örneğin otomatik testleri test etmek için en çok kullanılan
yöntemlerden biri testlerden birisini bilinçli olarak kalacak şekilde
ayarlamaktır, yani bu test her seferinde başarısız sonuçlanmalıdır. Eğer bu
test başarılı sonuç verirse test ortamında gerçekten bir tutarsızlık olduğu
anlaşılır. Aynı şekilde diğer bir test de her zaman geçecek şekilde ayarlanır.
Eğer bu test bile geçmezse test ortamında bir sorun olduğu sonucuna
varılır.
"Yeni yazdığınız program sizin bilgisayarınızda sorunsuz çalışıyorsa bile o anki
haliyle yandaki bilgisayarda da sorunsuz çalışma olasılığı çok düşüktür."
Hakan Atbaş – Kitabın Yazarı
 Testler kapsamlarına göre de sınıflandırılırlar:
o Kara kutu (Black box) testi: Kara kutu testi gereksinimlerin karşılanıp
karşılanmadığını ve işlevi test eden bir test biçimidir. Sistemin iç
detayları ile ilgilenmez. Belli girdilere karşılık istenilen sonucun çıkıp
çıkmayacağı ile ilgilenir.
o Beyaz kutu (White box) testi: Kara kutu testinin tersine işlev yanısıra
sistemin iç işleyişi ve yapısını da test eden testlerdir. Herhangi bir
seviyede olabilirler ancak genel uygulamada birim testi seviyesinde
yapılırlar. Kod kapsaması, dallanma kapsaması gibi yolları içerebilir.
o Gri kutu (Gray box) testi: Sistemin iç yapısı da göz önüne alınır ancak
kara kutu testleri gibi yapılır. Kara kutu testlerinden farkı sisteme
normal koşullarda verilemeyecek girdilerin de sisteme verilebilecek
olmasıdır.
 Testler yapılış metotlarına göre de sınıflandırılırlar:
o Statik testler: Bu testler klasik anlamda testler değildirler, statik
testlerde kod koşturulmaz. Kod gözden geçirmeleri, gereksinim çelişme
ve uyum belirlemeleri, otomatik programlarla veya elle söz dizimi
(Syntax) kontrolü, anti-desen (anti-pattern) kontrolü bu kapsama girer.
o Dinamik testler: Kod koşturularak yapılan testlerdir, sisteme belli girdiler
verilerek sistemin davranışı gözlenir.
 Doğruluk Gösterimi (Verification) ve Geçerlilik Gösterimi
(Validation)
o Bir yazılım üretilirken hem süreç boyunca kontroller yapılır hem de süreç
sonunda testler yapılır.
o Ürünü doğru olarak üretmek için süreç boyunca yaptığınız kontroller
doğruluk gösterimi (verifikasyon) alanına girer.
o Ürünün müşterinin istediği ürün olup olmadığını kontrol etmek ise
geçerlilik gösterimi (validasyon) alanı içerisinde incelenir.
o Karıştırılan bu özellikler için aşağıdaki özlü söz faydalı olabilir:
• Ürünü doğru üretip üretmediğinizi kontrol etmek verifıkasyonun alanına girer.
• Doğru ürünü üretip üretmediğinizi kontrol etmek validasyonun alanına girer.
o Kimi zaman verifikasyonun kalite güvence faaliyetleri ve validasyonun ise
kalite kontrol faaliyetleri olarak tanımlandığı da olur.
 Projeye Başlarken Testlere de Başlayın, Projenin Bitmesini
Beklemeyin
o Yazılımda bulunacak hataların maliyet eğrisini incelediğimizde projeye
başlarken bulunan hataların düzeltme maliyeti 1 birim iken aynı hata
ancak proje sonu testleri sırasında bulunabilirse bu maliyet 10-100
birime çıkmakta ve proje sahaya sürüldükten sonra bulunacak hatayı
düzeltme maliyeti 50-1000 kadar çıkabilmektedir.
o Peki ne yapalım. Projeye başlarken, daha ortada yazılmış kod yokken mi
teste başlayalım. Cevabımız: başlayın, hemen başlayın.”
o Peki nasıl?
 Projeye Başlarken Testlere de Başlayın, Projenin Bitmesini
Beklemeyin
o Gereksinimlerin belirlenmesi sırasında müşteri ve ekibiniz arasında gözden
geçirme toplantıları yapın. Yazılımlardaki hataların çoğu sanıldığı gibi
kodlayıcının yaptığı hatalar değil gereksinimlerin belirlenmesi sırasında
yapılan hatalardır.
o Tasarıma zaman ayırın ve tasarım gözden geçirme toplantıları yapın. Bir
öneriye göre zamanın %40'ı gereksinmelerin belirlenmesi ve tasarım için
harcanmak, %20 si kodlama için harcanmalı diğer %40'ı ise test ve hata
düzeltimi için harcanmalıdır. Bu değerler her proje ve her organizasyon için
değişebileceğinden sadece tasarımın ne kadar önemli olduğunu vurgulamak
için belirtiyoruz.
o Kod yazımı esnasında mutlaka kod gözden geçirme toplantıları yapın.
Yazılım guruları test sırasında bulunan hatalar kadar hatanın bu
toplantılarda belirlenebildiğini söylüyorlar. Üstelik test sırasında tasarımdaki
sorunlar bulunamazken bu toplantılarda tasarıma ait sorunlar da
belirlenebiliyor.
"Eğer onu test edemiyorsanız onu üretmeyin (bile). Eğer onu test
etmiyorsanız atın gitsin."
Boris Beizer – Yazılım Mühendisi
 Projelerde Test Ekibi veya Elemanı Çalıştırmak
o Yazılım projelerinde test yapacak adam çalıştıralım mı?” diye sorarsanız. Bu
soruya cevabımız büyük bir “Evet” olur. Hatta mümkünse ayrı bir test
ekibinin olması gereklidir.
o “Peki yazılımcılardan bazılarını test elemanı olarak ayıralım mı?” diye
sorarsanız cevabımız şudur; “Genellikle yazılımcılardan pek iyi testçi olmaz”.
Test işi de bir kariyerdir. Bunu sakın unutmayın. Test etme yeteneğine sahip
bazı insanlar vardır ki diğer testçi ve yazılımcılardan kat ve kat daha fazla
sayıda ve kritik hataları tespit edebilirler.
o Yıllardan beridir yazılım yapan kişiler bile hala “Biz yazılımımızı doğru
yazıyoruz, testçi çalıştırmaya gerek kalmıyor.” diyebiliyorlar. Oysa ki hatasız
yazılım diye bir şey yoktur. Her yazılımın az ve ya çok mutlaka hataları vardır.

"Müşterilerinizi hatalarınızı bulan, üstelik bedava çalışan test elemanınız olarak

kullanmayın. Bu size prestij ve para kaybettirir."
Hakan Atbas – Kitabın Yazarı
 Otomatik Testler ve Kullanımları
o Bir yazılımın testleri insan tarafından veya otomatik bir sistem, program
tarafından yapılabilir. Otomatik testlerin yararları şunlardır:
• Güvenilirlik: Otomatik testlerde doğru olduğu kanıtlanmış bir test her zaman
koşturulabilir, yani insan hatası şansı pek yoktur.
• Tekrarlanabilirlik: Otomatik testler istenildiği zaman istenildiği kadar tekrar
edilebilir.
• Programlanabilirlik ve Dakiklik: Otomatik testlerde istenilen test adımı
istenilen anda yapabilir, zamanlaması iyidir.
• Kapsamlılık: Otomatik testler ile test kapsamını ayarlamak kolaydır.
• Kalitelilik: Otomatik testler yazılı olduğu için toplam kalite etkenidir.
• Hızlılık: Otomatik testler el ile yapılan testlerden daha hızlıdır.
• Düşük Maliyet: Otomatik testlerin yazılması maliyetlidir ancak testleri
kullanması neredeyse maliyetsizdir.
 Otomatik Testler ve Kullanımları (devam)
o Otomatik test ne zaman yapılır:
• Herhangi bir değişiklik sonunda tekrar test yapmak maliyetli olduğunda
(uzun sürmek vesaire)
• Herhangi bir değişiklik sonunda sisteme girecek bir hatanın maliyeti yüksek
olduğunda
• Tam kod kapsaması gerektiğinde
• Kritik sistemlerde insan hatasına tahammül olmadığında
• İnsan kullanılarak yapılması pratik olarak zor veya imkânsız olan testlerde,
örneğin bir sunucuya binlerce kişinin aynı anda bağlanmasını test etmek için
• Manuel olarak yapan insanın psikolojisini bozan tekrarlı, monoton testlerde,
• Her sürümden sonra yapılması düşünülen gerileme (regresyon) testlerinde.
Zaten gerileme testleri otomatik testlerin en verimli olduğu alandır.
 Otomatik Testler ve Kullanımları (devam)
o Otomatik test ne zaman yapılmaz:
• Grafik Kullanıcı Arabirimi (GUI) gibi sürekli ufak tefek değişikliklerin olduğu ve
aslında herhangi bir hata olmadığı halde testlerin sürekli yanlış sonuç vereceği
durumlarda,
• Test yazımının maliyetinin organizasyonun kaldırabileceğinden fazla olduğu
durumlarda, veya kar-zarar oranının düşük olduğu durumlarda, örneğin sadece
bir yıl daha kullanılacak eski bir yazılım için otomatik testler yazmaya girişmek
mantıklı olmayabilir,
• İnsan kullanımının gerekli olduğu yerlerde, örneğin web sayfası kullanım öyküsü
testi otomatik yapılmaz, insan gereklidir,
• Otomatik test yazımının ürünün geliştirme hızını yakalayamayacağı, örneğin bir
kaç aylık planı olan, iki üç kişi ile yazılan ve bir kez kullanılacak, acil geliştirilmesi
gereken bir yazılım için otomatik test geliştirmek pek de pratik değildir,
• Kalitesi çok kötü olan yazılımlarda otomatik testleri yapmak da sonucu
yorumlamak da bir dert olabilir, bu durumda deneyimli testçinin kendi
yöntemlerine güvenmekten başka bir çaresi kalmaz.
• Otomatik testlere teknik olarak imkân olmadığında, örneğin gömülü özel bir
sistemde otomatik test çok zor olabilir, bir grafik programında zor olabilir, üçüncü
el bileşenler kullanan bir programda testi koşturacak arabirim eksikliğinden
dolayı otomatik test imkânsız olabilir.
 Tümleştirme (Entegrasyon) ve Yazılımdaki Büyük Patlama (Big Bang)
Teorisi
o Diyelim ki yazılımınızı güzelce tasarladınız ve minik kolayca gerçeklenebilir
parçalara ayırdınız. Daha sonra da bu yazılım parçalarını kodladınız ve birim
testlerini yaptınız. İşte şu anda çok dikkat etmeniz gereken bir safhadasınız;
tümleştirme safhası.
o Yazılım sürecinde en sık yapılan hatalardan biri yazılımız, parçalarının yazılıp
bir araya getirildiğinde hiç sorun olmadan çalışacağını düşünmektir. Hatta
projelerde bu tümleştirme safhası için süre bile ayrılmadığı olur. Oysa ki
parçaları ne kadar dikkatli kodlarsanız kodlayın ve istediğiniz kadar birim
testi yapmış olun tümleştirme safhası sırasında sorunlar çıkacaktır
o Tümleştirme safhasında tüm modülleri birdenbire bir araya getirip bir arada
çalışmalarını bekleyerek kocaman bir test yaptığınızda evrenin
başlangıcındakine benzer bir patlama yaşarsınız, bu yüzden bu yanlış
yaklaşıma Big Bang yaklaşımı denilir.
o İşin doğrusu bir plan dahilinde kontrollü olarak parçalar, bir araya
getirmektir.
o Her parça eklendiğinde testler yapılmalı ve ancak testler geçtiğinde diğer bir
parça eklenmelidir.
o Bu tümleştirme safhası için mutlaka yeterince süre ayrılmalıdır.
 Yazılım Testinin Bazı İlkeleri
o Yazılım testi konusundaki kurallar yeni yeni geliştirilmeye
başlanmıştır.
o Şimdilerde popüler olan iki adet liste vardır.
• Bertrand Meyer’den “Testin Yedi İlkesi”,
• Diğer ustaların söylediklerinden derlenmiş olan “Testin Yedi İlkesi”.
 Yazılım Testinin Bazı İlkeleri
o Bertrand Meyer’den “Testin Yedi İlkesi”
• İlke 1: Tanım ilkesi - Bir programı test etmek, o programın hata yapmasını
(çakmasını) sağlamaktır.
• İlke 2: Testler ve spesifikasyonlar - Testler spesifikasyonların yerine geçemez.
• İlke 3: (Gerileme) (Regression) Testleri - Bulunan her hata için ilişkili bir test
yazılmalıdır. Bu test projenin ana test kütüphanesine kalıcı olarak eklenmelidir.
• İlke 4: Test geçti-kaldı kriteri olarak kontratlar. - Test-geçti-kaldı kriterleri bir
programın kontrat olarak parçası olmalıdır. Testin geçmesi veya kalması,
kontratın sağlandığının kontrolünü içeren otomatik bir süreç haline getirilmelidir.
• İlke 5: Manüel ve otomatik testler - Etkili bir test süreci hem manuel hem de
otomatik olarak hazırlanmış testleri içermelidir.
• İlke 6: Test stratejilerinin deneysel değerlendirilmesi - Her test stratejisini açık ve
net kriterler ile ve tekrar edilebilir test süreci ile objektif olarak değerlendirin.
• İlke 7: Değerlendirme kriteri - Bir test stratejisinin en önemli özelliği, zamanın
fonksiyonu olarak ortaya çıkarabildiği hata sayısıdır.
 Yazılım Testinin Bazı İlkeleri
o Ustalardan derlenmiş “Testin Yedi İlkesi”
• İlke 1: Test yazılım hatalarının varlığını gösterir ancak yokluğunu gösteremez.
(Edsger W. Dijkstra)
• İlke 2: Her şeyi test etmek imkânsızdır. (Zamanınız ve kaynaklarınız her şeyi test
etmeye yeterli değildir, risk analizi yaparak testleri makul seviyede tutmalısınız.)
• İlke 3: Erken test edin. (Test hazırlığı proje başında başlamalıdır, en sona
bırakılmamalıdır.)
• İlke 4: Hataların Kümelenmesi - Hataların büyük bir kısmı belli yazılım
modüllerinden çıkar. (Hataların çoğu veya önemlileri belli birkaç modülde
bulunur.)
• İlke 5: Tarım İlacı Paradoksu (Pesticide paradox): Testler kullanıldıkça daha az
hata tespit etmeye başlarlar. (Özellikle otomatik testler kullanıldıkça ilgili hatalar
düzeltileceği için artık pek fazla hata tespit edemezler. Test kütüphanenize zaman
zaman yeni testler de eklemelisiniz.)
• İlke 6: Test konuya göre hazırlanmalıdır. (Testler yazılım modülünün içeriğine,
kullanım alanına, kullanım şartlarına dikkat edilerek hazırlanmalıdır. Örneğin evde
kullanılacak bir cihaz için sıcaklık testleri çok önemli değilken askeri cihazlar için
sıcaklık ve ortam testleri en önemli testlerdendir.)
• İlke 7: Üründe hataların bulunmaması ürünün gereksinimleri karşıladığı ve kaliteli
olduğu anlamına gelmez.
 Organizasyonunuzdaki birim testler başarı ile bittikten, tüm
bileşenler birleştirildikten ve son testler de yapıldıktan sonra
artık farklı bir süreç başlar.
 Bu süreç ürünün niteliğine göre bireysel ürünler için piyasaya
sürüm safhası, organizasyonel ürünler için de teslim
aşamasıdır.
 Bireysel ürünler için pazarlama, satış gibi teknik olmayan
faaliyetler de ağırlık kazanır. Organizasyonel ürünler için ise
hala teknik zorluklar ana risktir.
 Bu safhanın en büyük özelliği bu safhanın çoğu zaman proje
takvimlerinde yer alandan daha fazla sürmesi ve hiç akla
gelmeyecek riskleri barındırmasıdır
 Kurulum, Devreye Alım ve Saha Testleri İçin Kaynak ve Süre Ayırın
o Entegrasyon yani birimleri birleştirme testleri bittikten sonra çoğu
organizasyon proje bitti zanneder. Hatta bazı anlaşmalarda kurulum, devreye
alım ve saha testleri düşünülmemiştir bile.
o Oysa bu süre proje süresi içinde hatırı sayılır bir yer tutar. Müşteri
memnuniyetini belirleyen aktivite de budur, çünkü müşteri sizin ne kadar
özveri ile kod yazdığınızdan, gece gündüz mesai yaptığınızdan, süper bir plan
yaptığınızdan haberdar değildir.
o Müşterinin gerçekten göreceği çalışmanız ve size vereceği kalite puanı sezin
bu süre içinde yaptığınız çalışmanın kalitesine ve verimliliğine bağlıdır.
o Müşteri memnuniyetini etkileyen iki önemli faktörden biri ekran düzeni ve
kullanımı ise diğer ana faktör de kurulum ve devreye alma aşamasının
kalitesidir.
 Sahada Hata Ayıklayabilmenin (Debug Edebilmenin) Güzelliği
o Sahada hata ayıklayabilmek ihtiyaç olduğunda hayat kurtaran bir
özelliktir.
o Sahada hata ayıklayabilmek için gerekli konfıgürasyonu mutlaka
hazırlayınız.
o Printf’ler ile veya mesaj kutuları ile hata ayıklamaya çalışmak saha stresi
altında hataları bulmak değil yeni hataları kodunuza eklemekle
sonuçlanabilir.
o Bu konuda size şunları önerebiliriz:
• Eğer sahadaki sisteminiz gömülü bir sistem ise bir emülatör edinin,
• Eğer sahadaki sisteminiz pahalı ve büyük bir sistem ise biraz daha masraf
edip lisans alarak geliştirme ortamınızı sahadaki bu sisteme de kurun,
• Eğer sahadaki sisteminiz ucuz ve küçük bir sistem ise kendinize hata
ayıklama imkânları olan yedek bir test sistemi kurun.
 Bu aşama çoğu zaman atlanan fakat gerçekten önemli bir aşamadır.
 Bu aşamada projenin genel bir değerlendirmesi yapılır.
 Proje sırasında yapılan yararlı uygulamalar, yapılan hatalar ve bunun
gibi birçok şey masaya yatırılır ve incelenir.
 Unutmayınız ki başarının sırları şudur:
o İyi bir planlama ve hazırlık evresi
o Çok çalışma
o Hatalardan ders alma

"Tecrübenin faydası olur mu? Hayır, (benzer) yanlışları yapmaya devam

ediyorsak olmaz."
W. Edwards Deming – Toplam Kalite Yönetimi Felsefesinin Yaratıcısı
 Proje Sonunda Değerlendirme Toplantısı Yapınız. Peki Bu Toplantı Nasıl Yapılır?
o Her ekibin en değerli bilgisi kendi edindiği tecrübelerdir. Proje sonu
değerlendirme toplantıları bu tecrübeleri oluşturmak ve ileriki projelerde daha
başarılı olmak için en uygun yollardan biridir.
o Birçok organizasyon bir kere değil defalarca aynı hataları yapmaktadır. Bu
sebeple proje sonunda bir değerlendirme toplantısı yapmak çok faydalıdır.
o Proje değerlendirme toplantısından sonra “Proje Sonrası Gözden Geçirme
Raporu” hazırlanmalı ve yazılmalıdır. Bu rapordaki bir hata kaydı, kişilerin
hatalarının kaydı niteliğinde olmamalıdır. Bu rapor ilerleme, düzeltme amaçlı bir
rapor olmalıdır.
o Proje bittiği için bazen ekip üyeleri nasıl olsa proje bitti diye görüş bildirmekten
çekinir veya üşenirler, bu durumu engellemek için değerlendirme toplantıları
daha proje devam ederken, projenin her ana basamağı sonunda yapılabilir.
o Proje sonu toplantısından sonra yapılan önemli bir hata raporun hazırlanıp rafa
kaldırılmasıdır. Oysa çalışma gruplarına işlem maddeleri açılmalı ve raporda sözü
edilen geliştirici ve düzeltici işlemler mutlaka uygulanmalıdır.

"İnsanları değil iş akışını düzeltin."

Anonim
 Bakım aşaması genellikle ürün sahadayken çıkabilecek yazılım hatalarını
düzeltmek için yapılan faaliyetler olarak tanımlanır.
 Ancak pratikte bu böyle olmaz. Kullanıcılar ürünü kullandıkça üründeki
eksiklikleri, ürünle ilgili isteklerini de raporlarlar ve bu yeni özellikler de
bakım faaliyetleri sırasında araya iliştirilmek zorunda kalınır.
 Ayrıca yazılım hatası olmayan ancak kullanıcının anlamakta güçlük çektiği
özelliklerin kullanıcıya tekrar tekrar açıklanması ve bunun gibi hizmet işleri
de bakım aşaması içerisine giriverir.
 Bakım konusunda yapılan en büyük yanlışlardan biri programın son halini
aldığı ve artık bakım ihtiyacı olmayacağıdır.
 Bakım aşaması genellikle ufak bir işmiş gibi değerlendirilir. Oysa yukarıda
da bahsettiğimiz gibi bakım aşamasının göze görünmeyen birçok iş kalemi
olduğu için aslında projedeki en yüksek maliyetli aşamalardan biridir.

"Ve şöyle dedi büyük usta...

Bir program üç satır bile olsa, onun bakımı bir gün mutlaka zorunlu olacak. "
Geoffrey James, The Tao Of Programming kitabından.
 Bakım Faaliyetleri
Bakım faaliyetleri birkaç dala ayrılır:
o Önleyici bakım faaliyetleri: Oluşan bir sorunun bir daha olmaması için
veya yeni fark edilen bir riskin kötü sonuçlar doğurmaması için kodda
yapılan değişikliklerdir.
o Düzeltici bakım faaliyetleri: Ortaya çıkan hataların düzeltilmesi için
yapılan faaliyetlerdir.
o Adapte edici bakım faaliyetleri: Çevresel etmenlerin değişimi ile (örneğin
çalışma koşullarının değişmesi, teknolojinin ilerlemesi, vb) yeni koşullara
kodun ayak uydurması için yapılan faaliyetlerdir.
o İlerletici bakım faaliyetleri: Yazılıma yeni özellikler eklenmesi, müşterinin
yeni isteklerinin koda eklenmesi için yapılan faaliyetlerdir.

"Bir insanın berbat yazılımı, diğer bir insan için tam zamanlı bir iş imkânıdır."
Jessica Gaston
 
 Yazılım Kalite Unsurları
o Kalitenin birçok tanımı yapılmıştır. Bunlardan birkaçını sıralarsak:
• Kalite amaca uygunluktur.
• Kalite insanlar için değer taşımaktır.
o Yazılım kalitesini belirleyen birçok özellik vardır.
o Yazılım hemen hemen tamamen hatalarından arındırılmış olsa bile
kaliteli olmayabilir.
o Yani hatasızlık bir kalite ölçütüdür ancak kaliteyi belirleyen yegane
özellik değildir.
o Üstelik bu özelliklerden bazıları bir ürün için daha önemli iken bazıları
diğer bir ürün için daha önemli olabilir.
 Yazılım Kalite Unsurları
o Yazılım kalitesini belirleyen özellikler büyük ölçüde McCall (1977) ve Boehm’in (1978)
çalışmaları ile belirlendi.
o Bu bilgilerden de faydalanarak yazılım kalitesini belirleyen unsurları şöyle
sıralayabiliriz:
• Anlaşılırlık (Understandability): Gerek sistem yazılımı, gerekse dokümanlar
anlaşılır ve açık mı?
• Tamlık (Completeness): Tüm gerekli bileşenler gerçeklenmiş mi? Sistem
kaynakları yeterli mi?
• Doğruluk (Correctness): Sistem kendisinden beklenen işlevleri doğru olarak
yerine getiriyor mu?
• Taşınabilirlik (Portability): Yazılım başka bir platforma taşınabiliyor mu?
Taşınamıyorsa bu belirtilmiş mi?
• Sürdürülebilirlik-Bakım yapılabilirlik (Maintainability): Yazılımın ileride çıkabilecek
sorunları kolayca çözülebiliyor mu?
• Test edilebilirlik (Testability): Yazılım kolayca ve doğru olarak test edilebiliyor mu?
• Kullanıma uygunluk (Usability): Yazılım kullanıcı dostu mu?
• Güvenilirlik (Reliability) ve Sağlamlık (Robustness): Yazdım kendisinden
beklenenleri gerek süre gerekse koşullara bağlı olmaksızın doğru olarak yerine
getirebiliyor mu?
• Etkinlik (Efficiency): Yazılım (bellek, mikroişlemci kullanımı, haberleşme ağ
kullanımı gibi konularda) hem etkin biçimde yazılmış hem de etkin bir biçimde
 Yazılım Kalite Unsurları (devam)
• Güvenlik (Security): Yazılıma sadece yetkisi olan kullanıcılar erişebiliyor mu?
Yazılımın kendisi ve verileri yetkisiz erişime karşı korunuyor mu?
• Esneklik (Flexibility): Yazılıma gerektiği zaman yeni modüller veya işlevler kolayca
eklenebiliyor mu?
• Tekrar kullanılabilirlik (Reusability): Yazılımın modülleri veya tamamını başka
projelerde kullanmak mümkün mü?
• Tutarlılık (Consistency): Yazılımda kullandan değişken adları, matematiksel veya
çeşitli semboller ve ekrandaki elemanlar tutarlı ve birbiri ile uyumlu mu?
• Farkmdalık (Conciseness): İlgili ürün yazdım kuralları, standartları gözetilerek,
yeniden düzenleme ve optimizasyon kurallarına uyularak ve farkında olunarak
yazılmış mı?
• Erişilebilirlik-Edinilebilirlik (Availability): Yazdıma piyasada veya herhangi bir
kanalla erişmek kolay mı?
• Kurulabilirlik (Installability): Yazdımı kurmak kolay mı?
• Uyumluluk (Compatibility): Yazdım diğer sistemlerle uyumlu olarak çalışabiliyor
mu?
"Bir programı güvenli, güvenilir ve hızlı yapmanın tek yöntemi onu küçük
yapmaktır."
Andrew S. Tanenbaum
 Kaliteli Kodlamada Dikkat Edilecek Noktalar ve İpuçları
Bu kısımda yazılımcılara daha kaliteli kod yazabilmeleri için her
seviyeden öneriler bulunmaktadır.
 Yazdığınız Her Modül İçin Ayrı Bir Test Programı Yazmalısınız
o Burada modülden kastımız herhangi bir projede kolaylıkla
kullanılabilecek bir kütüphane kod birimidir. Örneğin bir dll (Dynamically
Linked Library) bir modül olarak kabul edilebilir.
o O halde tekrar ana konuya gelecek olursak kodladığınız her modül
(örneğin .dll) için bir test programı yazmalı ve modülü bu test programı
içinden koşturmalısınız.
o Bu test programını yazmak için harcayacağınız süre inanın yazmazsanız
daha sonra çıkacak problemleri düzeltmek için harcayacağınız sürenin
yanında çok küçük kalır.
 Nasıl Yapılacağını Değil Ne Yapılacağını Kodlayın
o Kodunuzu gruplarken ne yapılacağına göre kodları gruplayın.
o Bir işin nasıl yapıldığını (yani detayları) kod içerisine yaymayın. İyi bir kod
alışveriş listesi gibi olmalıdır; “Bunu yap”, “Şunu yap”, “Onu yap” şeklinde
kodlanmalıdır.
o Örnek: Aşağıdaki kod birden ona kadar olan sayıların nasıl toplandığının
detaylarını gösteriyor, sanırım kodunuzu okuyanlar bu detayları çok da
merak etmiyorlardır, ilgilenenler de zaten detaylara bakacaktır.

// Birden herhangi bir sayıya kadar toplamı hesapla

int toplam = 0;
for (int i = 1; i <= 10; i++)
{
toplam = toplam + i;
}
 Nasıl Yapılacağını Değil Ne Yapılacağını Kodlayın (devam)
o Örnek: Oysa aşağıdaki kodda main işlevine bakarsak her satır sadece ne yapıldığını
belirtmekte. İşin nasıl yapıldığının detayları ise bir işlev içine gizlenmiş olarak derli toplu
durmaktadır.
int BirdenSayiyaKadarToplamDondur(int sayi)
{
int toplam = 0;
for (int i= 1; i <= sayi; i++)
{
toplam = toplam + i;
}
return toplam;
}
int main(void)
{
int sayilarToplami;
sayilarToplami = BirdenSayiyaKadarToplamDondur(10);
EkranaGoster(sayilarToplami);
YazicidaBastir(sayilarToplami);
}
 “Nesne Tabanlı Programlamada “Encapsulation” kavramı da yukarıda anlattıklarımızı destekler.
Detayların gizlenmesi ve işin adının, amacının ön plana çıkarılması günümüz programlamasında esas
bir amaçtır.
 Yorumların Kaynak Koda Oranı Ne Kadar Olmalı
o Yorum yazmamanın veya çok az yorum yazmanın kötü bir alışkanlık olduğu
zaten bildiğimiz bir konu. Kodda mutlaka ve mutlaka yorum satırları
bulunmalıdır.
o Bunun yanısıra çok fazla yorum yazmak da çok iyi bir alışkanlık değildir. Çok
fazla yorum yazmak zorunda kalıyorsanız bu sizin kodu sağlam, kendi
kendini anlatan biçimde yazamadığınız ve bu yüzden sürekli açıklamak
zorunda kaldığınız anlamına gelir.
o Eğer bir kodu sürekli açıklamak zorunda kalıyorsanız o kodda bir sorun var
demektir.
o Üstelik yorumların kod ile bütünlüğünü sağlamak da zaman alıcı ek bir iştir.
o Kodun bakımının yapıldığı gibi yorumların da bakımı yapılmalıdır.
o Peki ne kadar yorum satırı olmalı. Tecrübelere göre kod satırlarının en az
beşte biri kadar yorum satırı olmalıdır.
o En fazla da kod satırları sayısı kadar yorum satırı olmalı, yani bir kod satırına
karşılık bir yorum satırı olmalı. Bunu açıklayacak olursak önemli gördüğünüz
her noktada, işlev başlarında, dosya başlarında mutlaka o kodu yazmaktaki
niyeti açıklayan yorum satırları olmalıdır.
 Yorumda Ne Yazılır
o Yorumları programcı olmayan birinin de anlayabileceği şekilde yazın. Neyin
neden ve nasıl yapıldığını açıklayan yorumlar yazın.
o Kodun aynısını kendi dilinizde veya yabancı bir dilde aynen tekrar etmeyin.
o Yorumlarda o kod bölgesini yazmaktaki niyetinizi, ana amacınızı belirtin.
o Tecrübesiz bir programcı: Bir işlevi veya iş satırlarını göz önüne aldığımızda
tecrübesiz bir programcı yorum yazarken sadece “Ne” veya “Ne yapar”
sorusunun cevabını yazar.
o Oysa ne sorusunun cevabı çoğu zaman kodun kendisidir.
o Aşağıdaki kötü örnekte yazılan “ne yapıyor” sorusunun cevabı (eğer işlev adı
da zaten uygun verilmişse) okuyucunun çok az işine yarar.
// Benzetim yapar c = benzetimYap(int a, int b);
o O halde “Ne” ve “Ne yapar” sorularının cevapları zaten koddan anlaşılıyorsa
bunun üstüne bir de yorum yazmak faydasız, boşuna bir tekrar olabilir.
o “Ne” sorusuna cevap veren yorumlar sadece büyük bir kod bloğunun ne
yaptığını açıklamak için kullanılmalıdır.
 Yorumda Ne Yazılır (devam)
o Tecrübeli bir programcı: Aşağıdaki ve benzeri soruların cevaplarını yorum olarak
yazar:
• Bu kısmın anlamı nedir?
• Amacı nedir?
• Ne işe yarar?
• Neden (bu kod neden var veya neden bu işi yapıyor)?
• Neyi? Neye? Nereye? Nereden?
• Hangi?
• Ne zaman?
• Neye göre?
• Nasıl?
o “Neden” sorusuna cevap veren yorumlar en tercih ettiğimiz yorumlardır. Bu tip yorumlar kodun
amacının açıklandığı yorumlardır. Bu tip yorumların değişme olasılığı da az olduğu için (çünkü
kod değişir ama neden pek değişmez) bu yorumların bakımı da daha az emek ister.
o İyi bir örnek:
// Verilen iki şayi arasında abc algoritmasına göre en yakin
// değeri hesaplar. Bu değer ekranda yer bulma için gereklidir.
c = benzetimYap(int a, int b) ;
 Yorumda Ne Yazılır (devam)
o Yukarıdaki listede en sonda söylediğimiz “Nasıl?” sorusunun cevabını
yorumlarda yazıp yazmamak biraz tartışma konusudur.
o “Nasıl” sorusuna cevap yazmamayı savunan teze göre kod her zaman değişebilir
bu yüzden de nasıl sorusunun cevabı da sürekli değişir, bakımı zordur. Bu tür
yorumlarda yorum çürümesi, güncelliğini yitirmesi dediğimiz olaya sık rastlanır.
Üstelik anlaşılır ve sade yazılmış bir kod bloğunun zaten ta kendisi “Nasıl?”
sorusunun bizzat cevabıdır, o halde iyi bir kodda “Nasıl” sorusunu cevaplayacak
yorumlara da gerek yoktur.
o “Nasıl” sorusuna cevap yazmayı savunan tez ise kodun karmaşıklığında neyin
nasıl yapıldığının anlaşılmasının güçlüğünü işaret eder ve nasıl sorusunun
cevabının kodun minik bir özeti olarak yorum satırlarında bulunması gerektiğini
söyler.
o Bu kitabın yazarına göre kodu anlaşılır yazınız, ancak açıklama gereği duyarsanız
“Nasıl” sorusunun cevabını da yorum olarak yazabilirsiniz..
o Tabii ki yorum yazmak iyi bir alışkanlıktır ancak yorum yazmanıza gerek
olmayacak kadar açık ve sade kod yazmak enfes bir şeydir.
o Son olarak yazdığınız yorumların mutlaka kod ile uyumlu, doğru ve güncel olması
gerektiğini belirtelim ve bunu anlatan güzel bir söz ile bu konuyu sonlandıralım.
"Yorumlar yalan söyler ama kod yalan söylemez."
Ron Jeffries
 Kodunuzun İçinde Geleceğe Mektuplar Yazın
o Çok değil 6 ay sonra kodunuzu başka birinin yazdığı koddan ayırt
edemeyeceksiniz.
o Bu yüzden kodunuzda o an önemli bulduğunuz noktaları not etmekten
çekinmeyin. Örneğin yorum satırlarında karışık bir algoritmayı hangi mantıkla
gerçeklediğinize dair küçük bir not gelecekte sizi veya bir arkadaşınızı çok
rahat ettirecektir.
o Yorumlarla ilgili tavsiyeler:
• Değişkenler göz önüne alındığında her değişken bildirimi veya tanımı yaptığınızda
açıklayıcı bir kaç satır yorum yazınız.
• Ana kod bloklarının başında açıklayıcı bir yorum yazınız.
• Ana noktalarda kod akışını tarif eden yorumlar yazınız.
• Kabullenme veya varsayımlar yaptıysanız o noktada bunu not ediniz. (Zira bu
varsayımlar yanlış olabilir veya ileride değişebilir.)
• Hata çözdüyseniz o noktada bunu not ediniz. (Böylece tekrar aynı hataya
düşmezsiniz).
• Hüner, ustalık, hile veya ince ayar gerektirmiş olan noktalarda bunu not ediniz.
 Macar Notasyonu (Hungarian Notation) Hakkında
o Macar notasyonu düzenli kod yazmayı teşvik ettiği için bir zamanlar çok
moda oldu. Macar notasyonunun özü değişken, sabit, işlev vb adlarında
özellikle asıl isme ön ekler getirerek tip bilgisi, anlam bilgisi gibi özelliklerin
ilgili isme bakar bakmaz anlaşılmasını sağlamaktır.
o Macar notasyonunun birkaç dezavantajı vardır:
• Önüne birçok ek harf getirilmiş olan bir kelime okunduğu zaman çok anlamsız
olmaktadır.
• Ayrıca programda bir değişkenin tipi değişirse Macar notasyonu ile yazılmış o
değişkeni tüm dosyalarda aratıp yeni ismiyle değiştirmek bayağı zaman alıcı bir
iştir.
o Son yıllarda Macar notasyonunun sağladığı kolaylıklar kalktı ve
dezavantajları daha çok göze batar oldu. Şöyle ki birçok modern kod yazma
editörü (IDE) zaten imleci ilgili değişken, işlev, vb kelimelerin üzerine
getirdiğimizde bize birçok faydalı bilgiyi sağlamaktadır. Bu bilgiyi bir de
değişken, vb adlarında tekrar etmenin anlamı yoktur.
o Bu sebeple Macar notasyonunun katı ve sayıca fazla kuralları yerine biraz
daha esnek, kullanıcı dostu, kullanıma ve amaca uygun ve faydalı
isimlendirme gelenekleri kullanılmaya başlamıştır.
 Macar Notasyonu (Hungarian Notation) Hakkında (devam)
o Eğer kullanılmak istenirse Macar notasyonunun sadece Semantik
(Anlam katan) ekleri ve değişkenlerin scope’unu (kapsamını)
bildiren ekleri kullanılabilir.
o Tip bilgisi veren eklerinin kullanılmasına artık gerek yoktur.
o Örneğin bir hafıza alanı büyüklüğü için bc (buffer count) önekini
kullanabilirsiniz ama değişkenin karakter bir değer içerdiğini
belirtmek için c önekini kullanmaya gerek yoktur.
o Nesne yönelimli programlamada üye değişkenler için “m” önekinin
kullanılması scope (kapsam) belirlemek için iyi bir örnektir.
  Macar Notasyonu (Hungarian Notation) Hakkında (devam)
Önek (Prefix) Veri tipi (Data type)
b boolean.
f flag (bayrak).
by byte veya unsigned char.
c char.
dw DWORD, double word veya unsigned long.
fn fonksiyon, işlev. Örnek: Macar notasyonu
h handle. kullanarak yazılmış birkaç
i int (tamsayı). değişken adı.
l Long. lpszName //long pointer
n short int. //to zero-terminated
p işaretçi. //string
s string. lpcstr //long pointer to
sz ASCIIZ null sonlanmış karakter dizisi. //constant string
w WORD unsigned int. dwRange //Double Word
x,y short, iki kooordinat ekseni için kullanılır. hWnd //Handle
Macar Notasyonu eklerine örnekler tablosu
 Karmaşıklığı Artırmayın
o Bir kodu test etmek bazı zamanlarda aynı kodu yazmaktan biraz daha
kompleks bir iş olur.
o Eğer siz kodu yazarken zekânızın tüm kıvılcımlarım, bildiğiniz tüm
karmaşık teknikleri kullanırsanız büyük ihtimalle testi yazarken bu zeka
pırıltısına veya daha fazlasına ulaşamayacaksınız.
o Bu sebeple kodunuzu mümkün olduğunca basit ve anlaşılır yazmaya
özen gösterin.
o Büyük ihtimalle yazdığınız karmaşık koda daha sonra bir o kadar daha
kod eklenecektir.
o Bu durumda işin içinden çıkmak gerçekten de zor olacaktır.
o Bu sebeple mümkün olduğunca anlaşılır, basit, halk tabiri ile üç kağıt ve
oyunlar içermeyen sade kodlar yazınız.
  Süper Zekice Kod Yazmaya Çalışmayın
o Genellikle süper zeki insanlar değişik cin teknikler kullanarak çok hızlı
çalışan veya işi çok az satırda halleden kodlar yazabilmektedirler.
o Ancak daha sonra muhtemelen şu iki sorun olacak:
• Kodu değiştirmek gerektiğinde kod anlaşılmadığı için bir sürü özel
durum gerektiren daha uzun parçalar eklenecektir.
• Kod anlaşılmadığı için kodu test eden testçi (hatta geliştiricinin
kendisi) çok daha fazla zaman harcayacaktır.
Hata ayıklamak kod yazmaktan iki kat daha zordur. Bu yüzden, kodu yapabildiğiniz en zekice şekilde
yazarsanız, tanım olarak, muhtemelen hatalarını ayıklayabilecek kadar zeki olmayacaksınız.
Brian W. Kernighan
Herhangi bir ahmak bir bilgisayarın anlayabileceği kodu yazabilir, iyi programcılar (ise) insanların
anlayabileceği kodlar yazarlar.
Martin Fowler

Anlaşılırlık kuralı: Anlaşılırlık zekilikten daha önemlidir.

Eric S. Raymond, Unix Felsefesi üzerine
 Yazdığınız Kodu Sevin Ama Aşık Olmayın
o Özeleştiri yapma zamanı geldi. Biz yazılımcılar iletişim konusunda süper
yetenekli insanlar değiliz. Matematiksel zekâmızın tepede olması duygusal
zekâmızın en tepede olmasını gerektirmiyor.
o Yazılımcıların yaptığı en büyük hatalardan biri de kodlarına duygusal olarak
bağlanmak, herhangi bir eleştiri kabul etmemektir.
o Yazdıkları kodlarda bir yerlerde bir hatanın varlığı söylendiği zaman kendi
kişiliklerine karşı bir eleştiri hatta bir saldırı olarak kabul eden, gerçekten iyi
yazılımcı ama sosyal alanda çok zayıf bireyler olan birçok programcı var.
o “İletişim kurmak”, “eleştiriye açık olmak” ve “iyi bir dinleyici olmak” gibi
konularda eksiklerimiz olabileceğini (hatta olduğunu) baştan kabul edip bu
eksikleri gidermeye çalışmalıyız. Bu çabanızın yararını göreceksiniz.
o Kodunuz anne-babanız, en sevdiğiniz takım veya sevgiliniz değildir, canlı bile
değildir, kodunuz sorunluysa hemen terk edin, değiştirin. Tıpkı arabanız gibi.
o İyi bir yazılımcı olmak sadece program yazabilmek değildir, birçok özellik
daha ister.
o Aşağıdaki listeye bakın ve siz de kendinizce maddeler ekleyin. Sonra da bu
yönlerinizi geliştirmeye çalışın.
o İyi yazılımcı = İyi programcı+iyi dinleyici+iyi bir dilbilimci+mütevazi+………..
 Kendi Algoritmalarınız Yerine Varsa Evrensel Standart Algoritmalar
Kullanın
o Artık yazılım mühendisliği başlangıç aşamalarını çoktan geçti. Birçok
algoritma ve haberleşme protokolü standartlaşmış durumdadır.
(Algoritmadan kastımıza örnek verecek olursak sıkıştırma algoritmaları, ses,
video işleme algoritmaları, sıralama ve tarama algoritmaları olabilir.)
o Standart haline gelmiş algoritmalar binlerce hatta milyonlarca kişi ve cihaz
tarafından kullanılmış, sağlamlıkları test edilmiş algoritmalardır.
o Literatürü iyi takip etmeli ve çalıştığınız konuda bir algoritmanın geliştirilip
geliştirilmediğini öğrenmelisiniz. Eğer ilgilendiğiniz konuda standart bir
algoritma var ise mümkünse bunu kullanınız.
o Müşterinize direneceğiniz birkaç konu var ise bunlardan biri de bu konuda
taviz vermemektir. Elbette müşterinin çok özel ve mecburi ihtiyaçları olabilir,
ancak standart yöntemlerle bu algoritma ve protokol ihtiyaçlarını
halledebiliyorsanız lütfen yapınız.
o Bir keresinde bir müşteri TCP/IP algoritması için alternatif çözüm istemişti.
Böyle garip isteklerden kaçınıp müşteriyi ikna ediniz. Tekerleği yeniden
keşfetmek iyi değildir ve sanıldığı kadar kolay değildir.
 Ekran Kullanıcı İçin Bir Bulmaca Değildir
o Kullanıcı arabirimi veya ekran düzeni kullanıcının işini kolaylaştırdığı ölçüde
başarılıdır.
o Kullanıcı arabirimi hazırlarken başka bölümlerden insanlara denettirin ve
yorumlarını alın. Ancak bu yorumları alırken asla karşılık vermeyin, kendinizi
savunmaya geçmeyin. Sadece yorumlarını alın ve daha sonra bu
yorumlardan faydalanıp tasarımınıza çekidüzen verin.
o Ekran düzeni hem teknik bilgi hem de sanatsal bilgi gerektiren bir iştir.
Sanat yönetmeni çalıştırmak çoğu şirket için bir lükstür ancak alternatif
çözümler vardır. Örneğin bu işi en iyi yapan sanat yönü gelişmiş ve teknik
olarak deneyimli personelinizi bütün GUI’leri denetlemek için
görevlendirebilirsiniz. GUI gözden geçirme toplantıları yapabilirsiniz.
o Kullanıcıya geribesleme yapın. Örnek verirsek, bir sistemin kullanıcıyı
ilgilendiren bir davranışı sistemin modu değişince etkileniyorsa bu mod
değişikliğini kullanıcıya bildirin.
o Bu hem kullanıcı için yararlı hem de test kolaylığı için gereklidir.
o Kullanıcının programı kullanabilmek için aklında tutması gereken işlemleri
mümkün olduğunca azaltın.
 Ekran Kullanıcı İçin Bir Bulmaca Değildir (devam)
o Ekran tasarımının 8 altın kuralı (Shneiderman prensipleri)
• Tutarlılık ve uyum için çabalayın,
• Usta kullanıcılar için kısa-yollar sağlayın,
• Geribesleme ile bilgilendirme yapın,
• (Başlangıç, gelişme ve) kapanışı olan diyaloglar oluşturun,
• Kullanıcı hatasını önleme ve basitçe hatayı ele alma hizmeti sunun,
• Kolayca işlemleri geri alma imkânı sunun,
• Kontrolün kullanıcıda olduğu hissini uyandırın,
• Kullanıcının kısa-süreli hafıza yükünü azaltın (belleğinde tutması gerekenleri
azaltın)
o Kullanıcı arayüzü olan programlar için kullanıcının çok az bilgisayar bilgisi
olduğunu, herhangi bir kullanım kitapçığını okumayacağını hatta yardım
menüsünden faydalanma zahmetini bile göstermeyeceğini kabul etmek iyi
bir fikirdir.
o Şu üç pratik kural faydalı olabilir:
• Program kullanıcıyı en az şaşırtacak şekilde çalışmalıdır,
• Kullanıcı için yapılacak bir sonraki adım ve nasıl vazgeçileceği (buradan nasıl
çıkılacağı) her zaman açık ve anlaşılır olmalıdır,
• Program kullanıcıyı uyarmadan kullanıcının ahmakça bir şey yapmasına izin
vermemelidir.
 Kodunuz Centilmence ve Nazikçe Çöksün
o Çökmeyen kod diye bir şey yoktur. Uzun uğraşlar sonucunda ve titizce
yazılmış tüm çalışan programlar eninde sonunda bir gün oluşan bir sorun
yüzünden çökerler.
o Ancak bunu yaparken kaba olmak veya centilmen olmak arasında fark
vardır. Bunu sağlamak zor değildir.
o Program çöktüğü zaman log’lar tutmalı, hatanın yeri ve kaynağı hakkında
bilgi verici mesajlar göstermelisiniz.
o Çok kez kodlayıcıların bir istisna (exception) oluştuğunda kötü bir şey
olduğunu kullanıcıya bildirmek yerine ilgili hata mesajını hasıraltı ettiklerini
gözledik.
o Bu şekilde birkaç suistimal edici kullanımdan sonra kodda hata bulmak ve
ayıklamak neredeyse imkânsız hale gelir.
o Bu kanser olduğunu kabul etmeyip tedavi olup iyileşebilecekken bile tedavi
olmamaya benzer.
o Program çalışırken oluşabilecek tüm hataları gerçekçi bir biçimde
kabullenmek ve hatadan minimum zarar ve en az acı ile kurtulacak şekilde
hatayı işlemeliyiz.
 Kodunuz veya Projeniz Çökecekse Bir An Önce Çöksün
o Mutlaka kodunuza hata tespit edici rutinler koyun. Kendinizi mutlaka
test edin.
o Kodunuz eğer sorunlu ve çökecekse sizin ellerinizdeyken çöksün.
o Sahaya gittiğinde çöken bir kod size çok daha pahalıya patlayacaktır.
o Sahada hata ayıklamak inanılmaz zor ve de ayrıca pahalı bir iştir.
o Normalde olmaması gereken ama yine de olasılık dahilinde olan
sorunların kontrolünü kodunuzda yapın.
o Bir fonksiyona girdiğinizde parametreler limitler dahilinde mi gelmiş
kontrol edin.

Onarım Kuralı: Çökecekseniz (yani kodunuz çökecekse) gürültülü ve mümkün

olduğunca erken çökün.
Eric S. Raymond, Unix Felsefesi üzerine
 Kodunuz veya Projeniz Çökecekse Bir An Önce Çöksün (devam)
o Projelerde de aynı durum vardır.
o Eğer bir projede bir aksaklık var ise bunu ne kadar erken tespit
ederseniz o kadar iyidir.
o Projeniz iptal edilse bile bu projenizin başlarında olsun. Proje sahaya
sürüldükten sonra iptal edilen bir projenin getireceği zararı düşünmek
bile istemezsiniz.

“Batacaksan erken bat” felsefesi çok önemlidir. (Kısa iş süreçleriniz varsa

problemi kısa zamanda tespit edebilirsiniz.) Projede kısa süreli iterasyonlar
ile ilerlerken kazara yarım milyon doları batırmak gerçekten çok ama çok
zordur.
Coding Horror internet sitesinden
 Koddaki Bir Sorunun Oluşma İhtimali Varsa O Sorun Mutlaka
Oluşur
o Kod yazarken genellikle hepimiz açık kalan noktalar hakkında iyimser
tahminlerde bulunur ve sorunun oluşma ihtimali az deriz.
o Belki eskiden gerçekten de böyle davranmak doğruydu. Çünkü ihtimaller
azdı.
o Ancak günümüzün hızlı bilgisayarları ve yoğun kullanıcı potansiyeli ile
koddaki sorunlar hemen her zaman kısa sürede etkilerini
göstermektedir.
o Eğer bir sorunu düzeltmez ve hasıraltı edersek o sorun mutlaka gelip bizi
sonradan vurur.
 Bu Tablo, Bu Kod veya Bu Algoritma Artık Değişmeyecek Demeyin
Değişir
o Projede tablolar, kodlar, algoritmaların değişeceği gerçeği aslında bilimsel
bir teoriye de dayanmaktadır. Bu teorinin adı “Sıfır-Bir-Sonsuz” teorisidir
(İngilizce adıyla “Zero One or Infinity” (ZOI)).
o Bu teoriye göre bir şeye ya “hiç izin verilmez” ya “sadece bir kez izin verilir”
ya da “sonsuz kez izin verilir”.
o Yani bir şeye iki kez izin verelim diye bir durum yoktur, boşuna limit koymayın
nasıl olsa dahası da gelecektir, sonsuz kez izin verin diye düşünülür.

"Bir şey olabiliyorsa o şey olur."

Murphy Kanunu
"Kullanılan bir programda (mutlaka) değişiklikler (modifikasyonlar) yapılacaktır.
Bir program değiştirildiğinde (modifiye edildiğinde), eğer birileri aktif olarak bu
durumu engellemek için çalışmıyorsa, karmaşıklığı artacaktır."
Software Entropy, Lehman, 1985
 Bir Hata Oluştu Hatası
o Lütfen “Bir hata oluştu” şeklinde hata mesajları göstermeyin.
o Ayrıca “Hata: 1357911” şeklinde kullanıcının “Bu hata kodu asal sayılar
dizisine ne kadar da benziyor” çıkarımından başka bir çıkarım
yapamayacağı hata mesajları da göstermeyin.
 Test İçin Tasarım Yapın
o Tasarım yaparken her an “Ben bunu nasıl test ederim” diye düşünün.
o Test edemeyeceğiniz bir ürün tasarlamayın.
o En büyük sorun kodlamak değil yazdığınız kodu doğrulamaktır.

"Şeffaflık Kuralı: Gözden geçirme ve hata ayıklamayı kolaylaştırmak için

görünürlük temelli tasarım yapın."
Eric S. Raymond, Unix Felsefesi üzerine
 Tasarım Desenlerini Öğrenin ve Kullanın
o Genelde tasarım desenleri denilince nesne yönelimli programlama
(object oriented programing) akla gelse de nesne yönelimli olmayan
programlama çeşitlerinde de birçok tasarım deseni vardır.
o Tasarım deseninden kasıt önceden defalarca denenmiş ve belli bir
sorunun çözümü için uygun görülen yöntemlerden bahsediyoruz.
o Roma’yı yeniden keşfetmeye gerek yoktur, yazılım mühendisliği artık
bir sorunun nasıl daha iyi çözülebileceğine ilişkin yöntemleri
oluşturmuş ve oluşturmaktadır. Bu örnekleri öğrenip kullanmanız
önerilir.
 Kokan Kod (Code Smell)
o Kod içerisinde bir sorun olabileceğine dair belirtiler bulunan koda kokan kod
denir. İngilizce “Code Smell” denilen bu olaya Türkçe’de “Bu kodda bir bit
yeniği var” şeklinde bir karşılık uygun düşer.
o Kokan kod ile hatalı kodu birbirine karıştırmamak lazımdır. Kokan kod bir
sorunun kesin olarak varlığını işaret etmez ancak sorun olma ihtimalinin
yüksek olduğunu gösterir. Bazen bilinçli olarak yazılmış bir kod da koku
yayabilir ama gerçekte hiçbir sorunu yoktur.
o Kokan kod genellikle incelenip yeniden düzenlenmeye (refactoring) çalışılır.
Eğer büyük bir sorun varsa tasarım gözden geçirilir.
o Bazen performans sorunları veya anlaşılırlık gibi sebeplerle kokan koda izin
bile verilebilir, ancak yine de kokan kod adından da anlaşılacağı gibi iyi bir
incelemeyi hak eden, sorun içerme ihtimali çok yüksek olan bir kod
parçasıdır.
o Her geçen gün sorunlu olabilecek kodları tahmin etme ipuçları
keşfedilmektedir.
o Zaman zaman bu ipuçları birbirleri ile de çelişebilmektedir ve üstelik
yukarıda da belirttiğimiz gibi kodun kesin sorunlu olduklarını da bildirmezler.
 Kokan Kod (Code Smell) (devam)
o Yine de kokan koda bazı örnekler vermek gerekirse:
• Aşırı fazla veya hiç konmamış yorumlar: Derlenebilir kodların yorum satırları
içinde kaybolduğu kodlar veya koddan rahatlıkla anlaşılabilen konular için fazla
fazla yorum satırları ilgili kodda bir kalite sorunu olabileceğini gösterir.
• Tekrar eden kod: Üç kez veya daha fazla tekrar eden aynı kod alanını bir
fonksiyon içinde toplamak gerekir. Bu yapılmamış ise kodda bir kalite sorunu
olabilir.
• Aşırı benzer işlevler: Birbirlerine çok benzeyen, hatta aynı işi yapan birden fazla
fonksiyonlarınız varsa bu fonksiyonları overload etmeyi denemelisiniz.
• Fazla uzun işlev veya sınıf: Fazla uzun işlev veya sınıflar yazılım kodlanırken
üzerinde fazlaca düşünülmediğini, özenilmediğini, işin parçalara ayrılmadığını
akla getirir.
• Başka sınıfın işini yapmaya çalışan sınıf: Eğer yazdığınız bir class, başka bir
class’ın metotlarını çok sık kullanmaya başladıysa, belki de iki class’ı birlikte
düşünmelisiniz.
• Başka sınıfın işine karışan sınıf: Eğer yazılmış bir class başka bir class’ın işine
karışmaya başlamışsa, kendisini ilgilendirmeyen işler yapmaya kalkıyorsa,
kodunuz kokuyor dikkat!!!
• Tembel Sınıf: Malumunuz çok az kullanılan sınıf. Az kullanıldığı için ya hiç sorun
çıkarmaz, ya da çıkardığında sorunun nereden geldiğinin anlaşılması zor olabilir.
 Kokan Kod (Code Smell) (devam)
• Gereksiz kompleks yapı: Alt tarafı bir formdaki verileri veritabanına kayıt
edecek bir yapı için bin satır kod, onlarca sınıf, vs yazarak pireyi deve
yapmışsanız kodunuz kokuyordun
• Çok fazla parametre: Eğer bir işlevin 5-6 parametreden daha fazla
parametresi varsa bu işlevin tasarımında bir sorun var demektir.
Parametreler birbirleri ile ilişkili ise onları bir yapı veya nesne içinde
toplayarak bir parametre olarak geçiriniz ya da tasarımınızı gözden geçiriniz.
• Aşırı genelleme: Tasarım yaparken birçok şeyi düşünmek iyidir ama her şeyi
düşünmeye çalışmış bir tasarım başarısızlığa uğrar.
• Dev koşul bloğu: Eğer nesne yönelimli programlama yapıyorsanız ve koşul
bloklarınız (if- else veya switch-case gibi bloklar) giderek dev gibi büyüyorsa
nesne yönelimli programlamanın tasarım desenlerinden birini kullanmayı
deneyebilirsiniz.
o Yukarıdaki listeye sürekli yeni maddeler eklendiği için ve zamanla ve
teknoloji ile bazıları şekil değiştirip bazıları listeden çıktığı için listeyi
uzatmakta bir anlam görmüyoruz.
o İnternette fazlası ile kokan kod saptama önerileri bulabilirsiniz.
 
 Ayarları Ne Kadar Kurulabilir Bir Program (Configurability)
o Eski zamanlarda programlar konfigürasyona açık değildi. Programın kullandığı
değerler programın içinde kalıcı olarak ayarlanmıştı (yani çakılmıştı). Bu değerlerden
kastımız örneğin maksimum voltaj, hafıza limiti, minimum girilebilecek değer,
maksimum bekleme süresi gibi değerlerdir.
o Yakın zamanlarda bu durumu düzeltmek için “Değişikliğe kapalı ama eklemeye açık
programla” ilkesinden de güç alarak yazılımcılar programlarındaki her parametreyi
ayarlanabilir olarak kullanıcıya sunmaya başladılar. Ya ayar pencereleri ile ya da ayar
dosyaları ile bu imkân kullanıcıya sağlandı. Bu değişim önceleri iyi oldu, değiştirilmesi
neredeyse imkânsız olan eski tip programlardan bizi kurtardı.
o Bu durumun da dezavantajlarının olduğunun ortaya çıkması gecikmedi. Yeni
programlar artık o kadar çok ayar imkânı sağlıyordu ki bu labirent gibi ayar
pencereleri veya ayar dosyalarında kaybolup gidiyordunuz. Ayarlar bir bozuldu mu
düzeltene kadar canınız çıkıyordu. Üstelik çoğu zaman ayar dosyaları başlangıç
değerleri ile geldiği için kendinize has bir ayar yapmak için saatlerce uğraşmanız
gerekebiliyordu.
o Günümüzde size önereceğimiz yöntem şudur: “Programınızı yeterince ayar yapılabilir
üretin, ne eksik ne de fazla.” Eğer bazı önemli özelliklere ayar imkânı vermezseniz
kullanıcınız programdan verim alamaz ve zarar görür, eğer çok fazla özelliğe ayar
imkânı verirseniz kullanıcınız ayarları yapamaz ve yine zarar görür. Kullanıcının ayar
yapmasının anlamı olmayan veya ayarlamakta güçlük çekeceği özellikleri kendiniz
ayarlı olarak kullanıcıya sunun. Hatta mümkünse programınız kendini işletim sistemi
veya donanıma göre otomatik olarak ayarlayabilsin.
 Ne Zaman Assembly? Ne Zaman Yüksek Seviyeli Dil? Ne Zaman
Nesne Tabanlı Programlama?
o Pratik olarak edindiğimiz tecrübe şudur:
• 0 -10,000 satır arasında büyüklükteki kod Assembly dilinde yazılabilir
(Elbette isterseniz yüksek seviyeli bir dil de kullanabilirsiniz),
• 10,000-100,000 satır arasında yüksek seviyeli bir dil kullanmanızı
tavsiye ederiz,
• 100,000 satırdan daha büyük sistemlerde mümkün olduğunca yüksek
seviyeli ve nesne tabanlı (object oriented) bir dil kullanmalısınız.
o Yukarıdaki üçüncü madde için notumuz şudur. Eğer hız gerçekten sorun ise
yüksek seviyeli ancak nesne tabanlı olmayan bir dil kullanınız. Eğer hız
probleminiz yoksa ise tereddüt etmeden Nesne Tabanlı bir dil kullanınız.
o Benzer şekilde birinci madde için yorumumuz şudur. Eğer hız ve yer
probleminiz varsa kısmen veya tamamen Assembly dilini kullanabilirsiniz.
Ancak böyle bir problem yok ise tereddüt etmeden Yüksek Seviyeli bir dil
kullanınız.
 Yazdığınız Her Modülün Bir "Sanal Olarak Uygula" İşlevi Olmalıdır
o Diyelim ki on tane sayıyı küçükten büyüğe doğru sıralayan basit bir
modülünüz olsun.
o Bu modüle denemeGirdisiVer isimli bir işlev koymayı unutmayınız.
Örneğimizde bu işlev ile rastgele 10 sayı seçip bunlar ile modülün
sıralama işlevini çağırabilmelisiniz.
o Aslında bu örnekte bir test programı yazarak da bu işi halledebiliriz.
o Ancak modüllere her zaman test programından girdi vermek mümkün
olmayabilir.
o Örneğin dışarıdan bir TCP/IP mesajı alan bir modül düşünelim; donanım
olarak bu modüle uygun bir TCP/IP mesajı göndermek mümkün
olmayabilir.
o Bu durumda test programı ile mesaj enjekte etmek imkânı olmayacaktır.
o Oysa ki, modülümüzün içine gömülü olan “SanalBirMesajUygula()”
şeklinde bir fonksiyon olursa, bu sayede test programından bu fonksiyon
çağrılarak, modülümüzü sanki gerçek bir mesaj gelmiş gibi, kolayca test
edebiliriz.
 Üç Kez Tekrar Etmeme Kuralı (Rule Of Three)
o Yeni başlayanlara aynı kodu tekrar etmeyin diye sık sık tavsiyelerde
bulunulur. Bu haklı bir tavsiyedir. Angaryayı engellemek yönü yanında
çok daha önemli bir sebebi vardır.
o Kodda bir hata çıktığında genelde bir yerde düzeltilirken diğer yerde
düzeltmeyi yapmak unutulur.
o Bu sebeple programımızda aynı kod iki ayrı yerde gerekiyorsa bir
fonksiyon içine koymak gayet mantıklıdır.
o Buraya kadar tamam ancak bunun sınırı nedir.
o Her tekrar eden kodu bir fonksiyona mı alacağız?
o Eğer bir kod iki yerde geçiyorsa seçim size kalmıştır, ister fonksiyon
içine alırsınız ister almazsınız.
o Ancak eğer aynı kod programınızda en az üç yerde birden
geçiyorsa mümkünse lütfen bir fonksiyon içine alın.
 Başkalarının Kodunu Okuyun ve Başka Programcılarla Konuşun
o İyi bir programcı olmak için kod yazmak kadar başkalarının yazdıkları
kodları da okuyup incelemek zorundasınız.
o Bu kodlar gerek aynı projedeki kodlar olsun gerekse internetteki kodlar
olsun size yeni bakış açıları kazandıracaktır.
o Bunun yanısıra başka programcılar ile konuşup fikir alışverişinde
bulunmak da size yeni ufuklar açacaktır.
o Aynı şekilde siz de kodlarınızı başkalarına okutup fikirlerini almalısınız.
 Edinebildiğiniz En İyi ve Kendinizi Rahat Hissettiğiniz Bir
Editörü Kullanın
o Yazılım geliştirmek için bir IDE’ye yani yazılım geliştirme ortamına
veya kısaca bir editöre ihtiyacınız var.
o Bu mümkünse piyasadaki en iyi ve en çok tavsiye edilen editör
olsun.
 Ekran Seçimi
o Yazılım geliştirmek için uygun ekran nedir diye düşünürsek; koddaki
fonksiyonlarınızı daha rahat görebileceğiniz kadar boyu büyük ve iki
kod dosyasını karşılaştırabilecek kadar eni büyük bir editör seçmeye
özen gösterin.
o Yani ekranın hem eni hem de boyu makul oranda büyük olmalı.
o Çok geniş fakat kısa ekranlar sinema seyretmek için iyi fakat yazılım
yazmak için uygun değillerdir.
o Aynı şekilde çok yüksek ekranlar da yazı yazmak için iyi ama iki
yazılım dosyasını karşılaştırmak için iyi değillerdir.
o Bu sırada 22 inch ve daha büyük monitörler bu özellikleri sağladığı
için yazılımcıların gözdesi olmuş durumdadır.
 Veritabanına Her Şeyi Koymayın
o Veritabanı kullanmak bilgilerinize daha hızlı ulaşmak için iyi bir yöntemdir.
Ancak veritabanının hızı fiziksel olarak hızlı olduğundan değil kullandığı
algoritmalardan kaynaklanır.
o Aslında aynı bilgiyi bir dosyaya ve bir de veritabanına koyduğunuzu
varsayarsak dosyadaki bilgiye erişmek veritabanındaki bilgiye erişmekten
daha hızlıdır.
o Ancak arama yapmak, filtreler oluşturmak söz konusu olduğunda dosyadan
istenilen bilgiye erişim çok uzun zaman alabilir.
o Veritabanı programında gömülü olan ve yılların tecrübesi ile akıllıca yazılmış
algoritmalar ise bu işi çok kısa zamanda halleder. Bu bilgiler ışığında şu
tavsiyeye kulak verebiliriz:
o Veritabanına bilgi sisteminizdeki tüm bilgileri koymayın, sadece aranacak,
fıltrelenecek (veya aranma, fıltrelenme ihtimali olan) bilgileri koyun.
 Veritabanına Her Şeyi Koymayın (devam)
o Örneğin bir personel listesi tutacaksanız veritabanına personelin adını, sicilini,
telefonunu koymak gayet iyi bir fikirdir, ancak personelin fotoğraf dosyalarını
veritabanına koymayınız.
o Bu fotoğraf dosyalarını çok iyi bir isimlendirme uygulayarak sabit diskte
güvenilir bir yerde tutunuz.
o Resim, müzik, vb dosyalan veritabanına koymak çoğu zaman veritabanını
hantallaştırmaktan başka bir işe yaramaz.
o Şimdi de daha zor bir örnek verelim; Eğer söz konusu olan personelin
özgeçmiş bilgileri ise ne yapmalı.
o Veritabanımı tercih etmeli yoksa dosya olarak mı saklamalı.
o Kendinize bu durumda şu soruyu sormalısınız; “Bu bilgiler arama veya
fıltrelemede kullanılacak mı veya ileride kullanılma ihtimalleri var mı?”.
o Eğer cevabınız “Evet” ise özgeçmiş bilgilerini veritabanına koyun.
o Eğer cevabınız “Hayır” ise o zaman özgeçmişleri sabit diskte tutabilirsiniz.
o Şunu tekrar etmeyi uygun buluyorum; eğer dosyaları diskte tutarsanız
ulaşımın kolay ve tutarlı olması için çok düzenli bir isimlendirme geleneği
uygulamayı unutmayın. Örneğin “KimlikNo” veya
“AdSoyadDogumTarihiAyiriciNo” gibi.
 Aynı Değeri İki Ayrı Yerde Saklamayın
o İngilizce Single Source of Truth (SSOT) ya da Türkçe adı ile “Gerçeğe tek
kaynaktan ulaşılmalı” prensibi diyebileceğimiz bu kavram programcılığın tüm
alanlarında ama özellikle veritabanı uygulamalarında çok önemlidir.
o Örnekle açıklamak gerekirse bir değeri iki ayrı değişkende saklamak
karışıklığa yol açar ve bu karışıklık “Gerçeğe tek kaynaktan ulaşılmalı”
prensibine uyulmadığından kaynaklanır.
o Aynı şekilde veritabanında aynı değer için birden fazla kayıt tutmak da
karışıklığa yol açar. Özellikle silme değiştirme işlemlerinde kayıtlardan birisi
işlenip diğerinin işlenmesi unutulursa veya sorun olursa ilgili değer tutarsız
hale gelir.
o Veritabanı uygulamalarında normalizasyon işleminin amaçlarından biri de
“Gerçeğe tek kaynaktan ulaşılmalı” prensibi doğrultusunda tabloları
düzenlemeye dayanır.
o Normalizasyon işlemi ile tablolarda tekrarlar engellenir. Gerçekten geçerli
aksi yönde bir sebebiniz yok ise veritabanı tablolarınızı normalize ediniz,
normalizasyon için vereceğiniz ufak bir emeğin karşılığını fazlasıyla
alacaksınız.
 Kötü Kedi "goto" / Program Akışında Zor Virajlar
o Goto sözcüğü, bazı programlama dillerinde program akışında bir noktadan
diğer bir noktaya direk atlamaya yarayan bir anahtar sözcüktür. Programcılığa
başlayan herkes kısa bir zaman sonra “goto” kelimesinin ne kadar kötü,
sakınılması gereken, “tüh kaka” birşey olduğunu duyup bunu kabullenir.
Gerçekten de “goto” kelimesi yapısal programlamayı bozduğu için pek tercih
edilmez. Üstelik teorik olarak “goto” kullanmadan aynı programı yazmak
mümkündür.
o Peki hiç mi yararı yok bu “goto’nun. Hiç yararı yoksa programa dillerine neden
koyuyorlar. Aslında dünyadaki her şeyin zararı ve yararı olduğu gerçeği gibi
“goto’nun da yararlı olduğu yerler vardır. Bu anahtar sözcüğünü aşağıdaki iki
durum için hoş görebiliriz:
• Bir işlev içinden, hata oluştuğunda hata kontrolü (error handling) yaparak
çıkmak için işlevin en sonundaki hata kontrolü koduna gitmek için “goto”
kullanılabilir.
• Çok derin, iç içe if bloklarından (genelde bir hata olduğunda) ani olarak
kurtulabilmek için goto kullanılabilir.
o Tekrar etmek gerekirse bu her iki durum için de aslında “goto” kullanmadan
çözüm mümkündür, ancak bu çözüm kodu karmaşıklaştırıyor ve okunaklılığı
büyük ölçüde baltalıyorsa alternatif olarak “goto’yu kullanabiliriz.
 Kodum Release Modunda Çalışmıyor Ama Debug'da Çalışıyor; Nasıl
Olur?
o Bu sorunun sebebi çoğu kişinin ilk etapta suçladığı gibi derleyicinin
release ve debug modlarında farklı davranan bozuk bir derleyici olması
değildir. Genelde bu sorunun iki adet cevabı olur:
• Zamanlama hatası: Program çalıştığında debug ve release modunda tüm
işlemlerin aynı sırada yapıla-cağı diye bir kural yoktur. Özellikle de modern
derleyiciler kodu o kadar optimize ederler ki neredeyse hangi çok çekirdekli
(multi threaded) bir uygulamada hangi çekirdeğin önce hangisinin sonra
çalışacağını tahmin etmek çok zordur. Üstelik bazen bir çekirdek daha henüz
diğer çekirdek hazır olmadan hatta daha yaratılmadan çalışıp sistemi
kolayca çökertebilir. Bunun için kodunuza koruma önlemleri koymalısınız.
• İlklendirilmeyen Değişken: Derleyiciler debug modunda değişkenlere ilk
değer atama ve onları sıfırlama konusunda daha titiz davranırlar. Örneğin bir
boolean değişkeniniz olsun. Derleyici debug modunda bunun ilk değerini
False değerine (yani genelde sıfıra) çekerken, release modunda bu
değişkene hiç bir değer atamayabilir ve değişkenin değeri şansınıza göre
bazen True bazen de False olur. Bu da bize programımızın debug ve release
modunda farklı davranmasını çok güzel açıklar.
 Test Adımlarım Bir Kalıyor, Bir Geçiyor, Hadi İşin İçinden Çık
o Genelde bu sorunun iki adet cevabı olur:
• Zamanlama hatası: Test programınız çalıştığında test adımlarının
sırasıyla yapıldığını zannedersiniz. Ancak çoğu zaman bu böyle
değildir. Test programları yüksek seviyeli programlar oldukları için
sizin ekranda sıralı çalıştığını zannettiğiniz testler altyapı tarafından
farklı sıralarda çalıştırılıyor olabilir. Ayrıca test adımlarının bazıları
diğerlerinden uzun sürdüğü için yine sıra bozuluyor olabilir. Bunun
için test adımlarınız arasında bekleme süreleri koymak, önkoşul
koymak ve benzeri önlemleri almalısınız.
• İlklendirilme sorunu: Koşturduğunuz test ilk seferde kalıyor ve
diğer seferlerde geçiyorsa sorun ilklendirme sorunu olabilir. İlk test
sırasında daha ön ayarlar yapılmadığı için test kalıyor olabilir. İkinci
koşuşta ise farkında olmadan o ayarlar testin başarılı olarak
geçebileceği koşula geliyordur.
  Hata Yapmam Demeyin, Kod İçerisinde Birçok Şeyi Hatta
Kendinizi Bile Test Edin
o Kodunuzu yazdığınızda hata kontrol kodları koymayı unutmayın. Defansif
kodlama da denilen bu tarz kodlamaya en iyi açıklamanın bir örnekle
olacağını düşündük.
Hata kontrolü koymadan önce: Hata kontrolü koyduktan sonra:
void yeniüyeEkle(short yeniüyeSayisi) void yeniüyeEkle(short yeniüyeSayisi)
{ {
toplamüyeSayisi += yeniüyeSayisi; if (yeniüyeSayisi < 0)
uyeSayisiniGoruntule (); {
} // Hata mesajı göster
return;
}
toplamüyeSayisi += yeniüyeSayisi;
if (toplamüyeSayisi > 0)
uyeSayisiniGoruntule();
}
 Sadece Tek Bir Sorumluluk Prensibi
o Bir yazılım parçacığı sadece ve sadece bir işi tam ve iyi yapmalıdır. Bu
yazılım parçacığı bir işlev, prosedür veya nesne tabanlı programlamadaki bir
sınıf olabilir. Bu kurala uymak bakımı yapılabilir, tekrar kullanılabilir ve
kolayca test edilebilir kod yazmak için çok gereklidir.
o Örnek vermek gerekirse diyelim ki bu kurala uymadınız ve bir işlevde iki tane
işi yapıyorsunuz. Eğer birinci işin algoritması değişirse bu işlevin her iki
görevini de kullanan bütün yerleri yeniden test etmeniz gerekecektir. Oysa ki
bu iki işi iki adet farklı işleve koymuş olsaydık sadece birinci işlevi kullanan
yerleri yeniden test etmemiz gerekecekti.
o Aslında kural çok basit bir kural olduğu için bu kuralı hemen hemen yazılım
yapan herkes bilir. Sorun kuralı ihlal edip hataya düşmenin sıklığındadır. En
deneyimli yazılımcı bile bir üniteye birden fazla iş koyma hatasına düşer.
o Her kuralda olduğu gibi bu prensibin de suistimal edilmesi kötü sonuçlar
doğurur. Örneğin deneyimsiz bir programcı basit bir iş parçasını o kadar çok
alt parçalara ayırır ki kod okunaklılığını yitirir ve anlaşılmaz hale gelebilir.
 Yazılım Kütüphanesi Çoğu Zaman Sizden Daha Hızlıdır
o Yazılımcılarda kendine güvenden kaynaklanan kendi fonksiyonunu kendi
yazmaya yönelik bir eğilim vardır.
o İşimize uygun bir kütüphane fonksiyonu varsa (ve özellikle de bu
fonksiyon derleyicinin kütüphanesinde ise) bizim benzer
fonksiyonlarımızdan neredeyse her zaman daha hızlı çalıştığı
gözlenmiştir.
o Bunun sebebi derleyicinin kütüphanesindeki fonksiyonların binlerce kez
test edilmiş ve çok kez optimize edilmiş olmasıdır.
o Tavsiye edilen eğer kaynak kodun sizde bulunması ve güvenilir olması
gibi problemleriniz yok ise kütüphane fonksiyonlarının kullanılmasıdır.
 Optimizasyonu Sona Bırakın
o Kodun daha hızlı, daha verimli çalışması için, hafızada daha az yer
kaplaması için veya buna benzer çeşitli sebeplerle kodu optimize eder yani
kısaltır ve kesip biçeriz.
o Ancak lütfen optimizasyonu, kod yazarken değil, kod yazma işlemini
bitirdikten sonra, hatta testinizi yapıp kodunuzun sağlıklı çalıştığını
doğruladıktan sonra yapın.
o Yanlış anlaşılmaya yol açmayalım; Kodu gelişigüzel, paçavra gibi yazıp,
düzeltmeyi sonraya bırakın anlamında söylemiyoruz. Tabii ki her zaman
kodunuzu çok temiz, düzenli ve mümkün olduğunca kısa ve basit
yazmalısınız. Kastedilen optimizasyon amaçlı çabaları en sona bırakmanız
gerektiğidir.
o Bu tavsiyenin birçok sebebi var. En basit sebep çoğu zaman optimizasyon
kodu karmaşıklaştırır ve üstelik çoğu zaman kodun sadece çok kritik ve ufak
bir bölümünde yapılması gereklidir.
o Bu sebeple kod yazmayı ve testini bitirdikten sonra sadece hızlı veya verimli
çalışması gereken yerlerde optimizasyon yapmak daha akıllıca olacaktır.
o Optimizasyon yapmanın da bir süre maliyeti olduğunu unutmayınız.
 İyi Tasarım Optimizasyona Gerek Bırakmaz
o Optimizasyon yapan bir derleyici kullanmak veya kaynak kodu
kodlayıcının optimize etmesi projelerde sık rastlanan bir durumdur.
Optimizasyonun avantajları olduğu kadar dezavantajları da vardır. Tabii
ki optimizasyon bazı durumlarda gerçekten hayat kurtarıcı olabilir ancak
dezavantajları şunlardır:
• Kodun bakım yapılabilirliğini azaltır, aşırı optimizasyon tekniği uygulanmış
kodu anlamak genelde çok zordur,
• Derleyici çok kaliteli değilse veya biz optimizasyonun yan etkilerini tam
bilmiyorsak koda tespit edilmesi çok güç hatalar sokabilir, ayrıca kodda
optimizasyon yapılmazken uyur durumda bulunan yani ortaya çıkmayan,
zarar vermeyen hatalar optimizasyon yapıldığında birden ortaya çıkabilir.
• Optimizasyon ancak belli durumlarda uygulanabilir bir yöntem olduğu için
her zaman kullanılacak metodik bir teknik olarak benimsenemez, bir projede
optimizasyonla işinizi rahatça halledebilirken diğer bir projede bir çok
sebepten dolayı optimizasyonu kullanamayacağınızı görebilirsiniz,
optimizasyona bel bağlamak iyi bir şey değildir.
 İyi Tasarım Optimizasyona Gerek Bırakmaz (devam)
o O halde ne yapmalıyız? Nasıl bir tasarım yapmalıyız ki optimizasyona
ihtiyaç duymayalım? Optimizasyona ihtiyaç duyduğumuz sebepleri
listeleyelim ve olası çözümleri de verelim:
• Kaybolan depolama alanı (Bellek) veya kalıcı depolama alanı (disk)
yetersizliği durumu: Uzun zamandır tespit edilmiş olan bir gerçek var ki
donanım hemen her zaman yazılımdan daha ucuzdur ve her geçen gün
daha da ucuzlamaktadır. Bellek veya diğer depolama alanlarının maliyeti
birçok yazılım ekibinin işgücü maliyetinden ve gecikmiş bir projenin ceza
ödemelerinden her zaman daha ucuzdur.
• Mikroişlemci/Mikrodenetleyici hızının yetersizliği durumu: Bunun için daha
hızlı bir mikro- işlemci/mikrodenetleyici kullanmanızı önerebiliriz. Ancak asıl
önerimiz sadece yüksek hız gerektiren kod bölgelerine manuel veya
derleyicinin optimizasyonunu uygulamanızdır. Genelde bir yazılımda hız
sorunu yaratan bölgeler çok sınırlıdır. Kodu, kod kısımlarının işleyiş
zamanları açısından incelemeli ve gerçekten zaman alıcı ve hızlı çalışması
gereken kısımları tespit etmeli ve bu kısımları optimize etmelisiniz. Tüm bir
kodu optimize etmek zorunda kalıyorsanız lütfen tasarımınızı yeniden
gözden geçirin.
 Sürekli Düzenleme, Sürekli Temizlik ve Toplam Kalite
o The Pragmatic Programmer isimli kitapta yazar Kırık Camlar Teorisinden bahseder.
Biraz uyarlayarak özetleyecek olursak, eski bir bina düşünün, bahçeli bir köşk,
sahipleri bir süreliğine bir yere gitmiş olsun. Bu bina bir süre hiç dokunulmadan kalır.
Ta ki ilk penceresi kırılana kadar. İlk kırık pencere hemen onarılırsa bina yine bir süre
daha idare eder. Ancak ilk kırılan pencere bir hafta içerisinde onarılmaz ise kısa
zamanda içine hırsızlar, mahallenin top oynayan çocukları, eskiciler, tinerciler
doluşuverir. İşte günümüzde her yerde duymaya alıştığımız toplam kalite ilkesi de
buna benzer bir şeydir. Her birimiyle tıkır tıkır giden bir işletme başarıya koşar, ancak
en önemsiz gördüğünüz bir bölümde bir şeyler aksayınca bu diğer işlere hızla yansır.
o Kendi kodunuza dönecek olursak kodunuzun bir parçasını düzeltirken hem işinizi
yapın hem de kodda tertip ve düzen sağlayın. Bu refactoring olarak adlandırılır.
Gereksiz derece uzun yazılmış işlevleri kısaltın; kod tekrarını azaltmak için işlevler
kullanın; karmaşık algoritmaları basitleştirin; değişken isimlerini anlamlılaştırın; girinti
çıkıntıları kod standartlarına uygun hale getirerek okunaklılığı sağlayın; fazla
boşlukları alın; yorumlar ekleyin veya güncelleyin; kullanılmayan ve gerçekten
gereksiz olduğunu bildiğiniz değişkenleri silin. Buna benzer birçok işlem daha yapın.
Daha sonra yaparım demeyin, muhtemelen yapmaya zaman bulamayacaksınız ve
testlerden sonra koda dokunmaya korkacaksınız. Emin olun bu düzen birçok kod
hatasını daha yazarken görmenizi sağlayacak ve ileride hataların bulunmasını çok
kolaylaştıracak.
 Sürekli Düzenleme, Sürekli Temizlik ve Toplam Kalite (devam)
o Projenizde kodlamaya başladıktan sonra testlere kadar sürekli iyileştirme
(refactoring) yapabilirsiniz ve yapmalısınız. Optimizasyonu ise proje sonuna doğru
yapınız. Refactoring optimizasyon ile aynı şey değildir. Farklarını listeyecek olursak:
• Optimizasyon mükemmele yakın veya ulaşılabilecek en iyi noktaya yakın
olmak için yapılır,
• Refactoring daha iyi bir noktaya ulaşmak için yapılır,
• Optimizasyonun kodun sadece gerekli yerlerinde yapılması tavsiye edilir,
• Refactoring kodun her yerinde yapılabilir,
• Optimizasyon hemen sonuç almak için yapılır, size kazanç sağlar,
• Refactoring ise iyilik yapmak gibidir, hemen sonuç vermez ama bir gün
mutlaka size geri döner,
• Optimizasyon sonunda kodunuz daha okunaksız olabilir,
• Refactoring’in amaçlarından biri kodun daha okunaklı olmasıdır.
• Kodunuzu geliştirdikçe ve yeni özellikler ekledikçe kodun karmaşıklık
seviyesi artar. İlk başta çok kolay ve bakımı yapılabilen kodlar bir zaman
sonra hangi parçasının ne iş yaptığını belirleyemeyeceğiniz dev kod yığınları
haline gelebilir. Bunu engellemenin tek yolu da sürekli basitleştirici ve
düzenleyici türden refactoring yapmaktır. Yani bir yandan yeni eklemelerle
kod karmaşıklaştıkça siz de öte yandan refactoring ile onu sürekli
basitleştirmeli, sadeleştirmelisiniz.
 Büyük Diziler Tanımlamak
o Bazen çok büyük bir dizi tanımlamak zorunda kalabilirsiniz. Örneğin
birçok kayıdı hafızada tutup çabucak erişmek için buna ihtiyaç
duyabilirsiniz.
o Çok büyük bir dizi tanımlayacaksanız bunu stack’te değil heap’te yapın.
o Her derleyici ve işletim sistemi genellikle bir uygulama için stack
büyüklüğünü sınırlı tutar ki bu da tahmini olarak lokal değişkenlerinizin
tutabileceği yer kadardır. Derleyici stack büyüklüğünü ayarlarken çok
büyük dizileri Stack’te tutacağınızı genellikle öngörmemiştir. Bu
durumda Stack aşımı hatasına düşmemek için dizilerinizi heap’te
yaratmanızı tavsiye ederiz.
o Örneğin bu işlem C dilinde malloc ve C++ dilinde new sözcüğü ile
yapılabilir.
 Acaba Rastgele Sayılar Ne Kadar Rastgele?
o Rastgele sayıların sahip olması gereken iki ana özelliği vardır, diğer değişle
şu an bizi ilgilendiren iki ana özellik olmalı. Bunlar şunlardır:
• Tahmin edilmesi zor olmalı, yani gerçekten rastgele olmalı. (Unpredictability)
• Eşit dağıtılmış olmalı, yani herhangi bir sayının çıkma ihtimali sabit olmalı.
(Uniform distribution)
o Şimdi bilgisayarları göz önüne alacak olursak bilgisayarlar ile rastgele sayılar
üretmek gerçekten çok çok zor. Neden mi? Çünkü bilgisayar prensipte
öngörülebilir (deterministik) çalışsın diye üretilmiş bir makine, hatta hiç
rastgele çalışmasın, hep tutarlı çalışsın diye tasarlanmış bir makine. Bu olay
örnek verecek olursak sadece kırmızı, mavi, sarı ve yeşil ana renklerini bilen
bir ressama pembe gül çizdirmeye çalışmak gibi birşey.
o Bilgisayarla rastgele sayı üretmeye çalıştığımızda önümüzdeki seçenekler
şunlar:
• CPU saatinin veya kristalinin “tik-tak”ını kullanmak
• Önceden hazırlanmış (pseudo-random) rastgele sayı listesini veya algoritmasını
kullanmak.
o Her iki yöntemin de başta belirttiğimiz rastgele sayıların iki ana özelliğini
sağlamada zaafları vardır.
 Acaba Rastgele Sayılar Ne Kadar Rastgele? (devam)
o Sonuçta kısa sürelerde hızlı hızlı rastgele sayı üretilince CPU “tik-
tak”ından yararlanmak verimli olmuyor ve uzun sürelerde de
algoritma veya listeler verimli olmuyor.
o Bu sebeple günümüzdeki bilgisayarlarda genellikle iki basamaktan
oluşan hibrid bir çözüm kullanılır.
• Önce ana gereklilik olan “rastgele”liği sağlamak için CPU “tik-tak”ından
faydalanarak bir başlangıç sayısı (seed) bulunur.
• Sonra ana gereklilik olan “eşit dağıtık’lığı sağlamak için bu az önceki
başlangıç sayısı indeks veya girdi olarak kullanılır ve eşit dağıtılmış çok
uzun bir üsteden veya daha iyisi bir algoritmadan istenilen rastgele sayı
alınır.

 Kayan Noktalı Sayılar (Floating Point Numbers) Gerçek Baş Belaları
o Çeşitli dillerde single veya float gibi anahtar sözcüklerle temsil edilen tek
duyarlıklı kayan noktalı sayılar günümüzde neredeyse kullanım dışı kalmış,
sorun çıkaran özelliklerdir.
o Bu türden değişkenlere atanan sayılar büyüdükçe veya küçüldükçe
duyarlılıkları azalır. Örneğin kayan noktalı olarak tanımlanmış olan 9000000
ve 1.5 sayılarını toplayınca 9000001.5 yerine 9000002 buluruz. Bu kadar
küçük sayılarda bile kayan noktalı sayılarda yuvarlama yapılmaktadır.
o Mühendislik hesaplarında çift duyarlıklı kayan noktalı sayılar (örneğin C’de
double) kullanılarak bayağı bir duyarlılık elde edilebilir. Ancak her bir
kuruşun önemli olduğu bankacılık işlemlerinde böyle bir hata bile kabul
edilebilir değildir.
o Bankacılık işlemlerinde sayıları oluşturan rakamları BCD (Binary Coded
Decimal Number-İkili Kodlu Ondalık Sayı) olarak tutmak iyi bir yöntemdir.
o Diğer bir yöntem de liraları küsuratlı tutmak yerine birim olarak kuruş
kullanıp tipini tamsayı olarak belirleyerek işlemleri yapmaktır.
 Kayan Noktalı (Float) Değerleri Eşitlik (Eşitsizlik) Karşılaştırmasında
Kullanmayın
o Kayan noktalı (float) türden değişkenler iç özellikleri sebebi ile kendisine
atadığınız değeri tam olarak tutamazlar ve bu değere en yakın bir değeri
içlerinde tutarlar.
o Bu sebeple float türünden değişkenleri karşılaştırmalarda kullanırsanız
yanlış sonuçlar elde edersiniz.
o Bu türden değişkenlerin ancak hemen hemen birbirlerine eşit olduğunu
tespit edebilirsiniz.
o Bu durumda değişkenlerin birbirlerinden farklarının mutlak değerinin bir
epsilon değerinden küçük olduğunu kontrol etmeniz yeterlidir. Epsilon
matematikte küçük pozitif bir niceliği göstermek için kullanılan semboldür.
o Örnek: Kayan noktalı değişkenlerin karşılaştırmalarda kullanımları.
float a; float b;
if ( a == b ) { bir kod parçası } // Yanlış kullanım
float epsilon = 0.001;
if ( fabs ( a - b ) < epsilon ) { kod parçası } // Doğru kullanım
 Programlama Dilinizin Sağladığı, İstisnai Durum Ele Alma
(Exception Handling) Özelliğini, Kod Akışını Sağlamak İçin
Kullanmayın
o Birçok programlama dili istisnai durumlarda kontrolü sağlamak için
programcıya kolaylıklar ve mekanizmalar sağlar (exception handling).
Örneğin sıfıra bölme hatası oluştuğunda, bellek aşımı olduğunda istisnai
durum oluşturulur.
o Yeni başlayan birçok programcı bu kolaylığı bilmeden suistimal eder ve
istisnai durum deyimlerini kod akış anahtar sözcükleri gibi kullanır.
Örneğin diskteki bir dosya açılmadığında normalde fonksiyonun dönüş
değerini incelemeniz gereklidir ve buna göre akışınızı yönlendirmelisiniz.
o Oysa ki tecrübesiz programcılar dosya açma işlevini bir istisnai durum
bloğu içine koyarlar ve nasıl olsa dosya bulunamazsa istisnai durum
oluşur ve kodum da kilitlenmeden yoluna devam eder diye düşünürler.
o Oysa ki birçok başka sebeple dosya açılamamış olabilir. İşletim sistemi
istisnai durum vermeyebilir, vb.
o Öncelikle yanlış örneği sembolik kod olarak verelim:
try
{
dosya_isaretcisi= Dosya.DosyaAc("Dosya_Adi");
}
catch (Exception e)
{
// Olağanüstü bir durum
}
o Şimdi de doğru hazırlanmış örnek. Öncelikle dosyanın varlığı kontrol ediliyor. İstisnai durum
ise gerçekten çok istisnai bir durum için kullanılıyor:
try
{
int sonuc= Dosya.DosyaVarmi("Dosya_Adi");
if (sonuc==0) dosya_isaretcisi = Dosya.DosyaAc("Dosya_Adi");
else
DosyaBulunamadiYaz();
}
catch (Exception e)
{
// Olağanüstü bir durum
}
 Klasik Hata Kalıpları (Anti-Pattern'ler)
o Klasik hata kalıpları programları kodlarken veya tasarlarken, özellikle de
deneyimsiz yazılımcıların düştüğü, ancak en deneyimli yazılımcının bile
düşebileceği klasik hatalardır.
o Bu hata kalıplarından kastımız kodda bulunabilecek bug’lar değil fakat
uygulamalardaki, tasarımdaki veya yazılım yönetimindeki yöntem
hatalarıdır.
o Klasik bir hata kalıbının yapıldığı bir yazılım, “bakım zorluğu, taşınma
zorluğu, tekrar kullanım zorluğu, genişlemeye kapalılık, maliyet
yüksekliği” gibi, yazılımda istenmeyen kötü özelliklerden bir veya
birkaçına bürünür.
 Klasik Hata Kalıpları (Anti-Pattern'ler) (devam)
o Kopyala/Yapıştır Hata Kalıbı - Kopyala yapıştır hata kalıbı işlevler içinde
durabilecek kodlar yerine sürekli bir yerden kopyalanıp diğer yerlerde
kullanılan kodlar kullanma alışkanlığına denir. Yeni başlayan
programcılar varolan kodlara dokunmaktan çekindikleri için böyle bir
yönteme başvururlar. Tecrübeli programcılar ise işlev içine koymayı ihmal
ettikleri birçok hazır kodları bulunduğu için böyle bir yönteme
başvururlar. Bu stilin dezavantajı bir problem çıktığında bütün
kopyalanan yerlerde aynı hatanın düzeltilmesi gerekliliğidir.
o Anaç Nesne (God Object) - Büyük bir ana sınıf ve içerisinde birçok işlev
ve üye değişken var ise, bu durum ilgili sınıfın yeterince bölünemediği
anlamına gelir. Genellikle tasarımda sorunlar olduğuna işaret eder.
o Tasarım Deseni Çöplüğü - Bu programlama stilinde programcı her iş için
bir tasarım deseni kullanır. En basit işler için bile bir tasarım deseni
kullanıldığı için bir süre sonra programın anlaşılırlığı iyice kaybolur.
Gerçekten ana işin yapıldığı satırlar ile tasarım desenleri için kullanılan
satırları ayırt etmek imkânsız hale gelir.
 Klasik Hata Kalıpları (Anti-Pattern'ler) (devam)
o En Az Çaba İle Programlama Gafleti - Bu programlama tipinde programcı mümkün olan en
az çaba ile programlama yapar. En sık rastlanan örneği bir programcının programda bir x
işaretçisi null olduğu için program çaktığında oraya sadece “if (x! = null)” şeklinde bir günü
kurtarma çözümü koymasıdır. Bu programlama stili problemlerin gerçek sebebin
araştırılmayıp sadece günü kurtarma çabası ile birkaç satır eklenerek geçiştirilmesi
şeklinde özetlenebilir.
o Türet Türet Dur Hata Kalıbı (BaseBean) - Nesne yönelimli programlamada sık yapılan bu
klasik hata kalıbında kodun içerisi türetilmiş sınıflarla doludur. Bir sınıf bir kaç kez üst üste
türetilmiştir. Oysa her gerekli olan türetmeler kodu kolaylaştırırken tam tersine gereksiz
türetmeler kodun kullanılabilirliğini bir hayli azaltırlar. Gereksiz türetme işleminden
kaçınmanın yolları vardır. Eğer uygun ise türetme özelliği yerine sahip olma özelliğini
kullanmak çoğu zaman hayat kurtarır. Şöyle ki B sınıfı bir A’dır yerine B sınıfı bir A’ya
sahiptir (veya Ayı kullanır) şeklinde tasarlanacak uygulama hem daha kolay hem de daha
anlaşılır olur.
o Komite Kararı İle Tasarım - Birçok grup veya kişi bir araya gelir ve toplantılarla tasarımı
yapar. Ya herkesin bir parçasına katkıda bulunduğu ama bir şeye benzemeyen garip bir
tasarım ortaya çıkar ya da komitedeki en güçlülerin fi-kirlerine göre şekillenmiş ancak
teknik olarak iyice incelenmemiş bir tasarım ortaya çıkar. Birinci türünde tarafların her biri
kendi vizyonunun bir parçasını son ürüne sokabildiği için ortaya hiç kimsenin beğenmediği
ama düzeltilmesi için de kimsenin tartışacak enerjisinin kalmadığı bir ucube çıkar. İkinci
türünde ise komitedeki en güçlü lobinin vizyonuna göre şekillenmiş bir ürün ortaya çıkar
ancak birçok teknik aksaklıkları olduğu için sonuç hiç kimseyi memnun etmez. Üstelik
sonuçta komitedeki güçlü olan lobi mükemmel bir ürün çıktığını iddia eder. Olan kullanıcıya
olur.
 Neden Yazılım Hataları Vardır?
o İnsan hatası: Bu konuda yapabilecek şeyler elbette var ancak ne kadar önlem
alınırsa alınsın insanlar hata yapacağı için bu tür hataları sıfıra indirmek
mümkün görünmüyor. Bu hatalar gerek yönetici gerekse yazılımcı tarafından
yapılıyor olabilir.
o İletişim sorunları: Organizasyondaki iletişim eksikliği veya iletişimin hiç olmaması
yazılımlardaki hataları bir hayli arttırır. (Hower 2012)
o Karmaşık yazılım: Yazılım gereksiz yere karmaşıklaştıkça hatalar artar. (Hower
2012)
o Sürekli değişen gereksinimler: Gereksinimlerin sürekli değişmesi kodlama-test
döngüsünde tutarsızlıklara yol açar ve hatalar artar. (Hower 2012)
o Anlaşılmayan, yarım veya belirsiz olan gereksinimler: Gereksinimler anlaşılır
yazılmadığı zaman hata oranı artar.
o Zaman baskısı: Gerçekleştirme için ayrılan süre kısaltıldıkça hata oranı artar.
(Hower 2012)
o Dokümantasyon eksiği veya hataları: Kod içerisindeki yorumlar veya kodu
anlatan dokümanlara yeterince önem verilmediğinde yazılım hataları artar.
(Hower 2012)
o Ego: Proje ekibindeki insanların egosu büyüdükçe koddaki hatalar artar. (Hower
2012)
 Neden Yazılım Hataları Vardır? (devam)
o Kalitesiz yazılım geliştirme araçları: Yazılım geliştirme araçlarının kalitesi
arttıkça koddaki hata oranı düşer. Örneğin iyi bir IDE, editör veya hata
ayıklayıcı kullanıldığında hata yapma olasılığı azalır.
o Yetersiz, uygun olmayan donanım: Donanım yetersizse veya uygun değilse
yazılımda hata çıkma olasılığı artar.
o Eğitim azlığı: Personel eğitimsiz ise hata olasılığı artar.
o Kötü tasarım: Tasarım uygunsuz ise hata olasılığı artar. Genelde eğitim
azlığından kaynaklanır.
o Yanlış kullanılan teknoloji: Teknoloji yanlış kullanılırsa hata olasılığı artar.
Genelde eğitim azlığından kaynaklanır.
o Yetersiz test: Gerek zaman baskısı gerekse ihmalden dolayı yetersiz test
yapılması koddaki hata oranının yüksek çıkmasına sebep olur.
o Kötü kodlama alışkanlıkları: Bu tür alışkanlıklar da koddaki hata oranını
arttırır.
o İhmalkarlık: İhmalkarlık da önemli bir hata sebebidir.
o Fiziksel dünyanın teorik dünyaya uyuşmaması: Fiziksel dünyanın teorik
olarak hesaplanandan farklı davranması ve bunun zamanında tespit
edilememesi de örneğin iletişim hatlarındaki sorunların başında gelir.
 Yazılıma Yeni Başlayanların Sık Yaptıkları Hatalar
o Yazılıma yeni başlayanların en sık yaptıkları hataları aşağıda sayabiliriz:
• İlklendirilmemiş değişken
• Tampon bellek taşması
• Saçma yeri gösteren işaretçi (C ve benzeri işaretçi tanımlı diller)
• Görevlerin kilitlenmesi - Deadlock (multi-task programlarda)
• Sonsuz döngü
• Değişken taşması
• Bellek kayıtları bozulması (Memory Corruption)
• Belleğin boşlukta ve kullanım dışı kalması (Memory Leak)
• Döngü sayımı bir yanlış (Sıfır yerine birden saymaya başlamak, n-1 yerine ne
kadar saymak gibi)
• Düzeltme yaparken yeni hata oluşturmak, Yazılım Gerilemesi (Regression)
• Stack taşımı
• Ölçü birimi hataları (Örneğin inch olan bir değeri cm imiş gibi kullanmak)
• Tip çevrimlerinde hatalar
• Kullanıcı girişi kontrolünde hatalar
 Çalıştırılabilir Kodum Bir Bilgisayarda Çalışıyor Diğer Bir
Bilgisayarda Çalışmıyor
o Bu problemin birkaç sebebi olabilir, bunlara örnek vermek gerekirse:
• İki bilgisayarın güvenlik ayarlarının farklı olması (diske yazma hakkı, şebeke
güvenlik ayarları, vb),
• Programın konfigürasyon dosyalarının eksik olması,
• Kodun çalışması için Java Virtual Machine veya .Net framework gerekiyorsa
bunların eksik olması,
• Dinamik kütüphanelerin eksik olması (Windows için .dll uzantılı dosyaların
eksik olması)
 Ham Veriden Bilgiye Dönüşüm

Tekirdağ Namık Kemal Üniversitesi Çorlu Mühendislik Fakültesi Veri Yapıları Dersi Dr. Rabia KORKMAZ TAN
Ham Veriden Bilgiye Dönüşüm
 Veri ham olarak 1 ve 0’ lardan oluşan bir dizi
şeklindedir.
 Bit dizisinin anlamı bunun üzerine uygulanacak veri
yapısından ortaya çıkarılır; aynı bit yapısı değiştirilerek
farklı bilgi ortaya çıkmasına neden olur. Örneğin,
0100 0010 0100 0001 0100 0010 0100 0001
 Bit dizisi ham bir veridir; bunun içerdiği bilginin ortaya
çıkarılması için bu bit dizisinin formatının bilinmesi
gerekir. Bu format da veri yapısının kendisidir.
 Bu bit dizisinin farklı veri yapılarına göre farklı bilgiye
dönüştüğü birkaç örnek inceleyelim;
 Ham veriden bilgiye dönüşüm
 Bit dizilerinin ne anlama geldiği uygulanacak veri yapısından ortaya çıkarılır.
Aynı bit dizisinden veri yapısı (veri formatı) değiştirilerek farklı anlamlar
çıkarılabilir.
 Örnek:
0100 0010 0100 0001
ASCII formatı Her 8li gruba 1 karakter B A
BCD (Binary Coded Decimal) Her 4lü gruba 1 hane 4 2 4 1
İşaretsiz tamsayı Her 16lı gruba 1 tamsayı 16961

9
 ASCII Çevrimi
Bitler sekizerlik gruplara ayrılır ve herbir grup bir karaktere
karşılık düşer:

0100 0010 0100 0001 0100 0010 0100 0001

B A B A
 Örnek: 0100 0001 bit dizisi ASCII tabloya göre A harfine, ikili sayı
sistemine göre 65 sayısına
denk gelir.
 Genel olarak her programlama dili tarafından desteklenen temel veri
türleri:
◦ Tamsayı
◦ Karakter
◦ Gerçel sayı
◦ Sözcük

6
 İkili sistemdeki sayıyı ondalık sisteme çevirme

1 0 1 0 0 1 1

26 25 24 23 22 21 20

1 x 26 + 0 x 25 + 1 x 24 + 0 x 23 + 0 x 22 + 1 x 21 + 1 x 20

= 1 x 64 + 0 + 1 x 16 + 0 + 0 + 1x2 + 1x1

= 64 + 16 + 2 + 1
= 83

8
Örnek: 'S' harfinin ASCII değerini (83) ikili sayı sistemine göre yazma.
 Ondalık sayıyı ikili sisteme çevirme
Sayı 2’ye bölme Bölen Kalan Bit Sırası

83 83/2 41 1 0

41 41/2 20 1 1

20 20/2 10 0 2

10 10/2 5 0 3
8310 = 10100112
5 5/2 2 1 4

2 2/2 1 0 5

1 1/2 0 1 6

7
BCD (Binary Coded Decimal) Çevrimi
Bitler dörderlik gruplara ayrılır ve herbir grup bir haneye
karşılık düşer:

0100 0010 0100 0001 0100 0010 0100 0001

4 2 4 1 4 2 4 1
Tamsayılar
 Bir tamsayı bellekte en basit şekliyle ikili tabandaki doğal
karşılığı ile saklanır.
 Örnek: 3910 = 1001112

 Farklı şekillerde tamsayı formatları da bulunur:

◦ Doğal ikili sayı
◦ BCD kodlamalı
◦ 1’e tümleyen
◦ 2’ye tümleyen
 Doğal ikili kod: Sayının doğrudan ikili tabandaki karşılığı saklanır.
 S = bn-1 2n-1 + bn-2 2n-2 + … + b1 21 + b0 20
S10 = (bn-1 bn-2 … b1 b0)2

 Örnek: 8310 = 10100112

 Doğal ikili taban: Sayının iki tabanındaki karşılığıdır.

 1’e tümleyen: Sayının doğal ikili tabandaki karşılığının 1’e

tümlenmişidir. 1’lerin 0, 0’ların 1 ile değiştirilmesi ile elde edilir.

 2’ye tümleyen: Sayının doğal ikili tabandaki karşılığının 2’ye

tümlenmişidir. 1’lerin 0, 0’ların 1 ile değiştirilmesinden sonra sonuca 1
eklenmesi ile elde edilir.

 BCD(binary coded decimal) kodlamalı: yani ikili kodlanlanmış onluk

kodlamada [0,9] arasındaki rakamlar 4-bitlik doğal ikili kod ile temsil
edilir.
 BCD (Binary Coded Decimal) kodlama: [0, 9] arasındaki rakamlar 4
bitlik doğal ikili kod ile gösterilir. Bir tamsayı, her bir rakamına ait BCD
kodun kullanılmasıyla elde edilir.

Rakam BCD Kodu Rakam BCD Kodu

0 0000
1 0001
2 0010
3 0011
4 0100
5 0101
6 0110
7 0111
8 1000
9 1001

 Örnek: 123 → 0001 0010 0011

İşaretsiz Tamsayı (Unsigned Integer)
 Pozitif tamsayılardır.
 Sayının işaret bilgisi tutulmadığından n bitlik işaretsiz bir tamsayı 0 ile
2n -1 arasında bir değere sahip olabilir.

İşaretli Tamsayı (Signed Integer)

 Hem artı hem eksi sayılardır.
 Sayının işaret bilgisi de tutulacağından 1 bit işaret biti olarak
değerlendirilir.
 n bitlik bir işaretli tamsayıda n-1 bit mutlak değer, 1 bit işaret için
kullanılır.
 İşaretli tamsayı iki şekilde gösterilebilir:
◦ 1. Yöntem: Doğal ikili kodun en soluna işaret biti ekleyerek
(1 eksi, 0 artı)
◦ 2. Yöntem: 2’ye tümleyen şeklinde

Örnek: -6710 tamsayısını doğal ikili kod ve 2’ye tümleyen

yöntemleriyle gösterin. 6710 = (1000011)2 doğal ikili kodda
yazılış
1. Yöntem: -6710 = (11000011)2
2. Yöntem: Sayının artı değerinin (işaret bitli) 1’e
tümleyeni: 10111100 2’ye tümleyeni: 10111101
Tamsayının bit uzunluğu ve bölgesi

 Bir tamsayının bellekte ne kadar yer işgal edeceği teorik olarak

doğrudan sayının değerine bağlıdır.
 log2SAYI şeklinde hesaplanır, kesirli sonuçlar bir üst tamsayıya
yuvarlanır.
 Örnek: log25 = 2.3 → 3 bit
log2555 = 9.11 → 10 bit

 Uygulamalarda bu kullanım yerine, tamsayılar boylarına göre 8, 16,

32, 64, 128 bit olarak
sınıflandırılmış tamsayı türlerinden birine sokulur.
 Örnek: Sistemde tamsayının uzunluğu 32 bit ise 5 sayısı da 555 sayısı
da 32 bit ile gösterilir.
 Tamsayıların bit uzunluklarına göre aralıkları aşağıdaki
tabloda verilmiştir.

Tamsayı türü İşaretsiz İşaretli

8 bit [0, 255] [-128, 127]
16 bit [0, 65 535] [-32 768, 32 767]
32 bit [0, 4 294 967 295] [-2 147 483 648, 2 147
483 647]
64 bit [0, 264 – 1] [-263, 263 – 1]
128 bit [0, 2128 – 1] [-2128, 2128 – 1]
 Örnek: -6110 tamsayısını 16 bitlik doğal ikili ve 2’ye tümleme yöntemleriyle
gösteriniz.

1. Adım: 61 tamsayısının doğal ikili kodda karşılığı:

111101
2.Adım: 16 bit tamamlanana kadar soluna 0
eklenir. 0000 0000 0011 1101
Doğal ikili kod için 3. Adım: Eksi değer için en soldaki bit 1 yapılır.
1000 0000 0011 11012 = -6110
2’ye tümleyen için 3. Adım: 16 bitlik +6110 sayısının önce 1’e tümleyeni
bulunur. 1111 1111 1100 0010
2’ye tümleyen için 1’e tümleyene 1 eklenir:
1111 1111 1100 00112 = -6110
Gerçel Sayılar
 Tam kısma ek olarak kesri olan sayılardır; kesirli sayı veri yapısı
hem kesri olan gerçel sayıların gösterilmesinde hem de tamsayı
veri yapısıyla gösterilmeyecek kadar çok çok büyük veya çok çok
küçük sayıların gösterilmesinde kullanılır.

 Tamsayıların mutlak değerleri, doğrudan doğal ikili koda bağlı

olduğundan çok çok büyük sayıların gösterilmesi için fazla bit
uzunluğu gerekmekte ve veri yapısı gereği iki tamsayı arasındaki
değerler gösterilememektedir.

 Uygulamada bu iki duruma da gereksinim olmaktadır.

 Bilgisayar uygulamalarında kesirli sayıların gösterilmesi için

kullanılan veri yapıları :
 Kayan Noktalı
 Sabit Noktalı
Sabit Noktalı Sayı
 13.25 sayısının ikili tabandaki değeri nedir?

Sayı 2’ye bölme Bölen Kalan Bit Sırası

13 13/2 6 1 0

6 6/2 3 0 1

3 3/2 1 1 2

1 1/2 0 1 3

Sayı 2 ile çarpma Çarpım Çarpım 1 den Bit Sırası

büyük eşit ise
1 Küçük ise 0
0,25 2*0,25 0,50 0 0

0,50 2*0,50 1 1 1

 1310 = 11012
 13,2510 = 1101,012
Sabit Noktalı Sayı
 1101.01 = (?)10
1 1 0 1 . 0 1

23 22 21 20 2-1 2-2

1 x 23 + 1 x 22 + 0 x 21 + 1 x 20 + 0 x 2-1 + 1 x 2-2

=1x8 + 1x4 + 0x2 + 1x1 + 0 x 0,5 + 1 x 0,25

= 8 + 4 + 0 + 1 + + 0 + 0,25

=13.25
Kayan Noktalı Sayı
 Kayan noktalı sayılar gerçel sayıların bilgisayar ortamındaki gösterim
şekillerinden biridir.
 Gerçek dünyada sayılar sonsuza kadar giderken, bilgisayar ortamında
bilgisayar donanımının getirdiği sınırlamalardan dolayı bütün sayıların
gösterilmesi mümkün değildir. Bununla birlikte gerçekte sonsuza kadar
giden birtakım değerler bilgisayar ortamında ortamın kapasitesine
bağlı olarak yaklaşık değerlerle temsil edilirler.
 Bu sınırlamaların etkisini en aza indiren, sayıların maksimum miktarda
ve gerçeğe en yakın şekilde temsilini sağlayan sisteme Kayan Noktalı
Sayılar sistemi denir.
 Kayan noktalı gösterim, kesrin yerini gösteren nokta bilgisinin
kaymasıdır. Örnek:
 0,58 5,8 x 10-1 58 x 10-2 0,058 x 101
Kayan noktalı sayı formatı ve IEEE 754

 Kayan noktalı sayıların bit düzeyindeki veri yapısında bitlerin bir

kısmı üs, bir kısmı çarpan, 1 tanesi de işaret bitini gösterir.
 IEEE 754 standardına göre 32 bitlik kayan noktalı sayının bit haritası:

8 bit 23 bit
i üs k
İşaret biti

 Ç: Çarpan, T: Taban, Ü: Üs olmak üzere sayı şu şekilde gösterilir:

 ± Ç x T±Ü (Ç = 1+k)
 Taban bilgisi her sayı için aynı olduğundan (T = 2) saklanmasına gerek
yoktur.
 Kayan Noktalı Sayı
 Örnek: 3,14 şeklindeki Pİ sayısının 32 bitlik IEEE 754 formatına göre bit
haritasını çıkarınız.
 Çözüm: Bit haritasının çıkarılması için aşağıdaki formül kullanılır:

Sayı = (-1)i (1+k) 2üs - bias

i: sayının işaretinden çıkarılır (0 → pozitif, 1 → negatif).

(1 + k): Çarpan
Not: 1 ≤ Çarpan < 2 aralığında olmalıdır, bu nedenle k "0,…" şeklinde
başlayan bir ondalıklı sayıdır.
bias: 32 bitlik kayan noktalı sayı için değeri 127 olan bir sabittir.
Kayan Noktalı Sayı
1. Adım: Sayının işareti +
olduğundan i = 0
3,14 = (-1)0 (1+k) 2üs - bias

2. Adım: k değerini bulmak için:

üs – bias yerine n kullanılsın.
(-1)0 (1+k) 2n = 3,14 ⇒ 3,14 / 2n = 1+k

k’nın 0,… ile başlayan bir ondalıklı sayı olana kadar sayı sırayla 2n
değerlerine bölünür:
 n=1 3,14 / 21 = (1+k) ⇒ 1,57 = 1 + k ⇒ k = 0,57
Kayan Noktalı Sayı
 Bu aşamada IEEE 754’e göre 3,14 = 1,57 x 21 bulunur.

3. Adım: k = 0,57 üs – bias = 1 ⇒ bias=127

üs = 127 + 1 = 128 elde edilir.

 Bu adımlardan sonra sayının bit haritası aşağıdaki gibi çıkarılabilir:

i üs k
0 128 0,57

128 ve 0,57 sayılarının ikili tabandaki

karşılıkları: i = (0)10 = (0)2
üs = (128)10 = (10000000)2
k = (0,57)10 = ?2
 Kayan Noktalı Sayı
 Noktadan sonraki n.basamak qn-1 olarak adlandırılsın. Kesirli sayının ikili tabana
dönüşümü:
Kayan Noktalı Sayı
 Örnek: 0.085 sayısının 32 bitlik IEEE 754 formatına göre bit haritasını çıkarınız.
1. Adım: Sayı pozitif olduğundan:
0.085 = (-1)i (1+k) 2üs - bias ⇒ i=0

2.Adım: k = 0,... şeklinde bir tamsayı olarak bulunana kadar sayı 2n değerlerine bölünür:
0.085 / 2-1 = 0.17
0.085 / 2-2 = 0.34
0.085 / 2-3 = 0.68
0.085 / 2-4 = 1.36 ⇒ k = 0,36
i üs k
3. Adım: k = 0,36 üs – bias = -4 ⇒ üs = 127 - 4 = 123 0 123 0,36
0 01111011 ?
Kayan Noktalı Sayı
Çözüm:
Sayı = (-1)i (1+k) 2üs - bias

1.Adım: i = 1 ⇒ Sayı = (-1)1 (1+k) 2üs - 127

2.Adım: üs = 130 ⇒ Sayı = - (1+k) 23

3.Adım: k = 0, 0000 1100 0000 0000 0000 000 ikili sayısını ondalıklı sayıya döndürmek için:
k = 2-5 + 2-6 = 1 / 32 + 1 / 64 = 0.03125 + 0.015625 = 0.046875

4. Adım: Sayı = (-1)1 (1 + 0.046875) 23 = - 8.375

Kaynaklar
 Temel Bilgi Teknolojileri Kullanımı, Anadolu Üniversitesitesi Yayınları
 Algoritma Geliştirme Veri Yapıları Rıfat Çölkesen, PapatyaBilim Üniversite
Yayıncılığı
 http://class.ece.iastate.edu/arun/Cpre305/ieee754/ie4.html

5
9