OUTLINE

1.
2.
3. Etik problemler
4.
5.
6.
7.
8.
9.
10. -modelleri
11.
12.
13.
14.
15.
16.
2
 En temelde 0-

3
 -

4
 -

5
 -
Legacy Software):

6
 -

esnektir:

uyarlanabilir:

gibidir:

7
 -

uygulanabilir.

8
 -

9
1. Umum

2.

3.

4. Muhakeme

10
5.

benimseyi pdestekleyeceklerdir.
6. Meslek

7.

8. Kendisi

11
Olabilecek Problemler:

1.
2. -Kritik bir sistemi yeterli testlerini

3.

12
 Hedef:

13
 patterns)

14
1. (Analysis)
2. (Design)
3. (Implementation)
4. (Testing)
5. (Maintenance)

15
 (NYP'deki

Requirement Specification(Gereksinim Belirtimi)

16
TASARIM:

17
SINAMA:

18
BAKIM:

porting)

19
BAKIM:
-
(Refactoring / Software re-engineering)

20
 1-
Prokeler %70-

-60

21
 Makine Seviyesi (01110110011)

Orta Seviye (C , C++ , C),

Cobol, Pascal, Basic),
Dbase, Clipper, VBasic, Paradox,
Access, FileMaker)

22
 -1
CASE (Computer Aided Software Engineering)

Integrated Programming
Support Environments

23
 -2

24
 -3

25
 -4

Generation Language: 4GL) grafik

konusudur.

Yine de algoritmik
26
 -modelleri - 1

1.

2.

3.

27
 -modelleri - 2

:
1. Sequential / Waterfall)
2.

3.
4.

1.
2.
Eksiler:
1. eldesi
2.
3.

28
 -modelleri - 3

29
 -modelleri - 4

Sorunlar:
yeni istekte bulunursa
yeniden dizayn edilecektir.

eder. M

kabul etmek zorunda kalabilir.

denebilir.
30
 -modelleri - 5

1.
2.

1.
2.

Eksiler:
1.
2.

1.

31
 -modelleri - 6

32
 -modelleri - 7

bir durum olur.

33
 -modelleri - 8

veya tek yolu olabilir. Bu durumlarda prototip tercih edilir:

K
T

34
 -modelleri - 9

Rapid Application Development):

bir model.

1.
2.
3.

1.
Eksiler:
1.

2.
3.

35
 10. -modelleri - 10

Based

1. Engineering)
2. Qualification)
3.
4. Composition)

Eksiler:
1.
2.

uygulanabilir.

36
10. -modelleri - 11

Based

37
 10. -modelleri - 12

/ Yinelemeli / Incremental / Iterative Modeller:

Kodlama

1.

2.
Eksiler:

-Kazan Modeli

38
10. -modelleri - 13

/ Yinelemeli / Incremental / Iterative Modeller:

39
 10. -modelleri - 14

Sarmal (Spiral) Model:

Temeli:

uygundur.

1. Planlama:

2.
3.
4.

1.
2.

Eksiler:
1.
2.
3.

40
 10. -modelleri - 15

Sarmal (Spiral)
Model:

41
 10. -modelleri - 15

Sarmal (Spiral) Model:

42
10. -modelleri - 16

- Kazan-Kazan Modeli (WINWIN

Model):

43
10. -modelleri - 16

Agile

Tekrarlanan

44
10. -modelleri - 17

Agile

Edmonds

waterfall modeline tepki

Waterfall,

Snowbird
Agile
Agile Alliance

Agile Principles

45
 10. -modelleri - 18

Agile
Manifesto:
1.
2.

3.

4.

http://www.agilemanifesto.org

46
 10. -modelleri - 19

Agile
Agile Prensipleri - 1,

kalite o kadar artar.

eksiklikler giderilir.

47
 10. -modelleri - 20

Agile
Agile Prensipleri - 2,

48
 10. -modelleri - 21

Agile
Agile Prensipleri - 3,

getirilir.

49
 10. -modelleri - 22

Agile
Agile Prensipleri - 4,

50
 10. -modelleri - 23

Agile
Agile Prensipleri - 5,

- -

51
 10. -modelleri - 24

Agile
Agile Prensipleri - 6,

52
 10. -modelleri - 25

Agile
Agile Prensipleri - 7,

53
 10. -modelleri - 26

Agile
Agile Prensipleri - 8,
Sadelik-

54
 10. -modelleri - 27

Agile
Agile Prensipleri - 9,

55
 10. -modelleri - 28

Agile
Agile Prensipleri - 10,

56
 10. -modelleri - 29

Agile
Agile Prensipleri - 11,

freelance

57
10. -modelleri - 29

Agile

58
10. -modelleri - 29

Agile

59
10. -modelleri - 30

Agile

Scrum

60
10. -modelleri - 31

Agile

Kodlama

Planlama:

,
.
.

61
10. -modelleri - 32

Agile

Kodlama

Planlama (Devam):

62
10. -modelleri - 33

Agile

Kodlama

Keep It Simple, Stupid!)

CRC (Class-Responsibility-
incelenmesi.
Spike
solution).
Refactoring

63
10. -modelleri - 34

Agile

64
10. -modelleri - 35

Agile
Scrum:

-4 hafta) .

65
10. -modelleri - 36

Agile

66
10. -modelleri - 37

CMMI: Capability Maturity Model Integration

Engineering Institute of Carnegie-Mellon
University)

Ulusal belgelendirici firma: Denetik

67
10. -modelleri - 38

Incomplete).
Initial/Performed

Managed/Repeatable). Temel planlama ve

tekrarlanabilir.
Defined

QuantitativelyManaged

Optimized

68
10. -modelleri - 39

CMMI-
CMMI-
CMMI-ACQ (Acquistion

1987-1997: CMM
1998-: CMMI

2018: CMMI v2.0

Continuous
Staged

69
10. -modelleri - 40

MilSoft(Level5)

(Level 5)
ASELSAN (Level 3)
Cybersoft(Level 3)
Havelsan(Level 3)

Etiya
ICTerra

70
 10. -modelleri - 41

CMMI ve CASE

(CASE: Computer Aided Software Engineering tools

(entegrasyon)

71
 10. -modelleri - 42

CMMI ve CASE

(CASE: Computer Aided Software Engineering tools

(devam):

72
10. -modelleri - 43

Gereksinim
Analizi

Sistemin Sistem

Program
Teslim

Sistem Program
Testi

Testi Testi

73
11. -1

feasibility)

gereklidir.

74
 11. -2

Gereksinimler, SRS (Software Requirements Specification)

IEEE 830-
ISO/IEC/IEEE 29148:2011 Systems and Software
Engineering Life Cycle Processes Requirements
Engineering

en

artefact" denilmektedir.
75
11. -3

1. Inception)
2. Bilgi Toplama (Elicitation)
3. Elaboration)
4. Negotiation)
5. Specification)
6. Validation)
7.

76
11. -4

neden olan olaylar:

77
11. -5

ve etkilenebilecek herkes.

78
 11. -6

2. Bilgi Toplama:

79
11. -7

belirlenmesi ve

Normal gereksinimler

80
11. -8

81
11. -8

Formal technical review

82
11. -9

Yeni gereksinimler eklenmesi

83
11. - 10

izlenmesi gerekir.

Tracebility table).

84
12. -1

85
 -2

Mevcut uygulamalar

Uzman tavsiyeleri
Mevcut ve gelecekteki gereksinimler

86
 -3

Gereksinimlerin Belirlenmesi 1
Gereksinimler belgesi:

NextGenPOS

sunucuya iletilmelidir.

87
 -4

Gereksinimlerin Belirlenmesi 2

belgeler.

eylemler.

88
 -5

Dikkat

89
 -6

1.
2.
3.
4.

5.
6. Sistem toplam bedeli vergi iadesi ile birlikte hesaplar.
7.
8.
9.

10.
11.

90
 -7

1.
3-
1.
2.

use-
casediagrams).

91
 -8

92
 -9

UC-B extends UC-

UC-A includes UC-

93
 - 10

Includes

Extends

94
 - 11

1.
2.

3.

95
 - 12

encapsulation)

96
 - 13

97
 - 14

98
 - 15

E-

99
 -1

ve metinleri
artefact" denilmektedir.

100
 -2

framework

101
 -3

102
 -4

Low coupling)
cohesion)

103
 -5

LOW COUPLING

104
 -6

HIGH COHESION

Genellikle:

105
 -7

Interactiondiagrams)
Sequencediagrams)
diagrams)
diagrams)
Statediagrams)

106
 -8

DESIGN BY CONTRACT

yoktur.

107
 -9

DESIGN BY CONTRACT

( barkod: String, adet: integer)

-Bir satisKalemi
-satisKalemi satis
-satisKalemi.miktar
-satisKalemi

108
 - 10

DESIGN BY CONTRACT

109
 - 11

Programlama" dersinde verildi.

110
 - 12

ACTIVITY DIAGRAMS

multithreaded)

111
 - 13

ACTIVITY DIAGRAMS

112
 - 14

ACTIVITY DIAGRAMS

Sinyal alma: Beklemelidir.

timer

bekler.
fork join

113
 - 15

ACTIVITY DIAGRAMS

114
 - 16

STATE DIAGRAMS
UYGULAMA ALANLARI

115
 - 17

STATE DIAGRAMS

116
 - 18

STATE DIAGRAMS

117
 - 19

STATE DIAGRAMS

118
 - 20

STATE DIAGRAMS
3)

119
 - 21

Modeli

120
 - 22

121
 - 23

Modeli

122
 - 24

NextGenPOS

123
 -1

(Measuring): Somut veya soyut bir sahip bir ,

veya bir veri olarak ifade etmek.
Benim boyum 163 santimetredir.
Hava 22 santigrat derecedir.
ara zordu.
(Metric): .
Mesafe : Bir labirentteki (Pisagor teoreminden) ve
.
: Santigrat ve Fahrenhayt
(Measurement): Belli bir eyleminin sonucu.
/ /
daha da zor
Measure ment ve ing son eklerini ben koydum
daha kolay
Yine de neyin isim, neyin , neyin eylem .
Neden ?
ile ilgili, yarayacak, elde etmek .

124
 -2

Yorumlama engeli (Intelligence barrier):

sonucu, elde etmek bir yol
sunmayabilir,
ya da yorumlama zor olabilir.
: galaksi rehberi'nde : 42!

125
 -3

zordur:
Bir , yorumlama engeli .
nedenleri:

nicel
neden ?
Ne kadar iyi bir ortaya anlamak
Ne kadar kestirmek
ne kadar zaman ve para anlamak
ilerleme : Proje

126
 -4

ve

temel :
( . gider, , komut , , bellek , hata )
( . , nitelik, , etkinlik, , )
Ortak ; verimlilik, kalite, gider ve belgelemenin

niceliklerden :
LOC = Line of Code (Kod )
KLOC = 1000 * LOC (K:Kilo)
Verimlilik = KLOC/( * ay)
Kalite = Hata/KLOC
Gider = Toplam gider/KLOC
Belgeleme = Belge /KLOC

127
 -5

Bir : Fonksiyon (FP:

FunctionPoint)
Tablo 1, 2 ve :

128
 -6

129
 -7

FPi
FPi
-orta-

FP = FPi (0.65 + 0.01 Fi)

Kalite = Hata/FP
Gider = Toplam gider/FP

130
 -8

131
 -9

McCall

Verimlilik/Etkinlik

McConnell'a

132
 - 10

1.
Correctness

Etkinlik (Efficiency

Reliability

Integrity
Uyarlanabilirlik (Adaptability

Accuracy
yapabilmesi.
Robustness

Usability

133
 - 11

2.
1. Reusability

2. Maintainability

3. Esneklik (Flexibility

4. Portability

5. Okunabilirlik (Readability
6. (Understandablility

7. (Testability

134
 - 12

eyleminin gereken :
(Formulation): uygun bir
: programlama, NYP, vb.
: , , uygulama, vb.
Toplama (Collection): Tarif edilen verileri elde etme.
Hesaplama (Analysis): = elde edilmesi.
Matematiksel .
Hesaplama otomatik .
Yorumlama (Interpretation): Elde edilen anlamlar
.
Geri besleme/Kullanma (Feedback): ekibine
bildirilmesi ve ekibin kullanarak .

135
 - 13

Bir sahip arzu edilen :

Uygun matematiksel sahip :
bir . . 0-1 . Aksi halde bir
verilmeli.
(veya ters) sahip . Sonucun , iyi
bir sonuca ilerlemesi (gerilemesi) gelmeli.
Deneysel olarak
.

136
 - 14

1. Nesneye :
Kaliteli bir ilkelerine .
NYP'de ve kopukluk ,
ve kodlama da .
ekibi, 'kaliteli bir giden yolda' iz olup
anlayabilir.
Proje de, birlikte, kestirimlerde bulunabilir.
2. Chidamber ve Kemerer'in (CK metrics suite):
WMC: metot (Weighted Methods per Class).
DIT: (Depth of Inheritance Tree).
NOC: Alt (Number of Children)
RFC: eleman (Response For a Class)
Good (RFC=[0,50]), regular (RFC=[51,100]), bad (RFC>100)
CBO: (Coupling Between Objects)
LCOM: Uyum (Lack of COhesion in Methods)
Good (LCOM=0), regular (LCOM=[1-20]), bad (LCOM > 20).

137
 - 15

1. WMC:
C1 c1..cn.

:
Metot neye belirlenecek?
Belirlemedeki , ?
:
Bir belirler.
metodu olan :
fazla sorumluluk , uygun olabilir.
uyumun olup tekrar .
Uygulamaya , yeniden .

138
 - 16
1.
1. COMIAS (Cohesion Method Invocation Attribute Sharing . Uyum Metot

2. CBMC (Cohesion Based on Member Connectivity

Uyum)
2.
1. Halstead ( )
2. Binder'in
3.
1. IEEE Std. 982.1-1998'de olgunluk

1.
2.
3.

4.

1.
2.
139
 -1

projeleri oranda :
zorluklar.
kaynaklanan zorluklar: , , vb.
Kestirimdeki zorluklar.
zorluklar.
Teknolojideki .
Gereksinimlerdeki .
Politik .
Mali .
proje ,
.
proje ilgi :

Proje

140
 -2

proje ; teknikleri, genel

bilimi ile proje bilgi ve deneyiminin ara
kesitidir.

141
 -3

projesinin , uygulanacak
ve denetiminin , tipleri ve teknoloji
.
projeler:
: 1-2 (1-2 ay) projeler
: 2-3 (2-3 ay) projeler
Basit bir uygulama ile .
projeler:
5-20 bir ekip , 2-3 tamamlanabilmektedir.
alt sistemden .
sistemlerle gereksinimleri mevcuttur.
planlama ve kod zorunludur.

142
 -4

Temel bir yarar

.
Planlama :
Basitlik : zaman planlama
ortadan .
Geleneksel : Planlama proje bir yol belirler; harita ne kadar
ise kaybolma o kadar .
: gereklidir ancak harita proje .

143
 -5

PLANLAMA
Planlama ilkeleri:
Projenin belirleyin: Nereye bilmezseniz kaybolursunuz.
planlama eylemlerine : , ve
belirler (bu ) ancak korumak ekibi
yapar (aksi ).
yinelemelidir: Plan asla .
Bildiklerinizi kullanarak kestirimlerde bulunun: Bilginin , ve
kestirimin etkiler.
her risk ekleyin: Teknik, mali, , politik
riskler.
olun: veya robot .

144
 -6

PLANLAMA
Planlama ilkeleri:
Projenin belirleyin: Nereye bilmezseniz kaybolursunuz.
planlama eylemlerine : , ve
belirler (bu ) ancak korumak ekibi
yapar (aksi ).
yinelemelidir: Plan asla .
Bildiklerinizi kullanarak kestirimlerde bulunun: Bilginin , ve
kestirimin etkiler.
her risk ekleyin: Teknik, mali, , politik
riskler.
olun: veya robot .

145
 -7

1. :
Teknik ekibin bir teknik yetenekleri .
olarak insanlarla ilgili eylemlerde , sosyal ve
yetenekleri de .
2. bir teknik :
Teknik ekibi istekli .
ve , /
.
veya olabilir.
ve belli olsa da, ekibini kaliteli fikirler
edebilmelidir.
bir sorun .
Hem teknik hem de sorunlarla .
Sorunlara koyabilmeli ve ortaya uygun bir koyabilmelidir.
.
Sorumluluk alabilmelidir.

146
 -8

3. ekibi (teknik ekip):

ruhuna uygun :
birbirine .
ortak kenetlenebilmelidir.
birbirlerini tamamlayan yeteneklere sahip .
ruhunu bozan etkenler:
.
ortaya hayal ve
.
.
ve rollerinin belirsiz .

147
 -9

4. :
:
Geleneksel bir yetki ve kontrol bulunur.
deneyimlere benzer projelerde bir .
fikirler ortaya uygun .
Rastgele (Random) : Serbest .
bireysel ve teknik yeteneklerine kendi bir
.
fikirler ortaya en uygun .
Disiplin elde etmek zor olabilir.
: ve rastgele .
Kontrol bulunur ancak serbesttir.
Demokratik .
uygun.
(efficiency) zor olabilir.

148
 - 10

4. (devam):
synchronous

5.
ile.

149
 - 11

Proje :
( ).
Odak: Teknik .
: kalite tutmak
: , ekibini iyiye
.
:
.
Odak: .
: kalite .
: tutulan istatistiklere , hem teknik hem de
.

150
 - 12

Kalite ile ilgili etkenler:

: yetenek ve en etkendir.
: kaliteye olumsuz etki eder. artan zorluk
, .
Teknoloji: ve kalitesi.
Kalite: Olgunluk, yeterlilik, etkinlik, belgeler, vb.
: Ana etkenlerle de .
: , , vb.
: , , vb.
toplama ve gizlilik :
Bireysel : .
: .
Proje : .
Gizlilik :
, izleyebilmesi ancak denklerin birbirlerinin
ise bir .
, veya tehdit etmek .

151
 - 13

:
Hata : Bulunan hata .
ve sonra bulunan ,
sahiptir.
Hata giderme :

tesliminden bulunan hata ,

TS: Teslimden sonra ( ) bulunan hata
ve TS yerine, olan A(i) ve
A(i+1) . :
A(i): bulunan hata
A(i+1): bulunan hata .
: Bulunan hata proje boyutuna .
: Bir ile giderilmesi zaman.
: Bulunan , ciddilik , vb. gibi veriler
.
Ve kalite

152
 - 14

:
, .
boyutu ile yapmaya .
ve hedefleri belirleyip ona uygun .
Amaca .
SEI (Software Engineering Institute) ve nin
mevcuttur.
Ve daha
modelleri da gerektirir.

153
 15

proje yapabilmek
, daha projelerin kesin
almak gerekmektedir.
Planlama proje tahminleri %100 ve
.
Buna yine de, eski bilgi ve deneyim dayanarak,
bir tahminde bulunmak gerekmektedir.
Bu tahmin bu
incelenecektir:
1.
2.
3.
4.
1. COCOMO (Constructive Cost Model) Modeli
2. PNR Modeli
3. COCOMO II Modeli
154
 16

takdiri; daha ve maliyeti ile bitirme

bilinen projeleri yoluyla .
eski ve yeni projenin maliyet kalemleri
farklar olarak belirtilmektedir.
Bu , toptan bir gider ve tahmini
.
bir tahmin , deneyim sahibi
ve iki proje olarak
gerekmektedir.

155
 17

Bir ekibi kez

yinelenen takdir ortak bir tahmin
.
Bu sosyal bilimlerde bir anket
proje takdiri halidir.
:
"sistemi " belgelerini ve birer "tahmin formu" verir.
birbirinden habersiz, nedenleri ile birlikte tahminlerini olarak
bildirir.
ortanca ve tahmin vererek, yeni tahminde
ister.
Ortak bir kadar bu yinelenmektedir.

156
 18

Analiz ; veya olarak , en alt

her gider takdir etmeye .
Bu , ve/veya analiz .

157
 19

(devam)
Hesaplama:
Alt basamaktaki giderleri takdir edilir ve
.
Gider takdirinde, LOC/FP ve ( * ay) .
Gider kalemleri projelerde giderlerin
veya birden fazla tahminin
ile belirlenir:
E = ( a + 4m + b )/6
E: gider kalemi beklenen
a: en tahmin, m: en tahmin, b: en iyimser tahmin

158
 20

modeller, bir (y),

bir (x) ile kestirmek ile kurulan,
y = f (x) .
proje tahmininde genellikle; y = a bir
fonksiyon modeli . Bu fonksiyonda :
(x) :
Bin kod (KLOC), fonksiyon (FP), proje (T),
hacmi (H) .
Kestirilmesi istenilen (y) :
hacmi (H), proje (I), belge (B), KLOC olabilmektedir.
Fonksiyon (a ve b), uygulama (x ve y)
, en kareler belirlenmektedir.

159
 21

(devam)
model:
Walston-Felix; 4000-467000 kodlu olan 60 projesi
dayanarak istatistik
:
hacmi (ayda- /adam-ay): H = 5.2 KLOC0.91
Proje (ay): T = 4.1 KLOC0.36
veya : T = 2.47 H0.35
talebi ( ): I = 0.54 H0.06
Belge hacmi (sayfa): B = 49 KLOC1.01
iki daha olarak COCOMO ve COCOMO II
incelenecektir.

160
 22

H. Boehm; COCOMO (Constructive Cost Model) bir

proje tahmin modeli .
Model, olarak basamak halinde :
Temel COCOMO
sonraki .
Orta COCOMO
Temel modele EAF (Effort Adjustment Factor: )
serbest eklenir
sonraki .
COCOMO
her
fonksiyonlar .

161
 23

(devam)
Temel COCOMO
Bin kod (KLOC) dayanarak hacmi (H) kestirilmekte ve H serbest
de proje (T)
H
T
Boehm; 63 projesinin dayanak ve Delphi
uygulayarak, COCOMO modeli
:
Uygulama :
H
T
programlar :
H
T
Sistem :
H
T
162
 24

(devam)
Orta COCOMO
Temel modele EAF (Effort Adjustment Factor: )
serbest eklenir.
Boehm, Orta COCOMO da (EAF),
duruma 0,90-1.40 .
, bir mikro uzaktan ile
10.000 kodlu (embedded) sistem ,
EAF = 1.17 :
Hacmi : H * 1.17 = 66.8 / ay
Proje T = 9.6 ay

163
 25

Putnam-Norden-Rayleigh modelinde hacmi ( ,

H); bin kod (KLOC), teknoloji ( ) ve olarak
(t) istatistik fonksiyonu :
H=
teknoloji :
teknoloji 2000,
teknoloji 8000
Otomatik ortamda 12000 .
Eski verilere dayanarak da, en kareler ile kestirilebilinir.
PNR modeli, proje
, de
bu yana zamana (t)
kabul eder.

164
 26

Cocomo modelinin revize edilmesiyle

165
 27

.
UML modelleme .
sahip (model ve kod ) tercih edilir.
(version control systems)
(testing framework)
Bir (build system) ile tercih edilir.
kalemleri izleme (work item tracking)
IDE tercih edilir.
Java: IBM Rational Application Developer
.NET: Microsoft Team System

166
 28

1
Risk ile taktikleri:
Sonradan (Reactive): Risk bakmak.
(Proactive): Riskleri daha .
ve / .
Proactive .
Risk :
Tam bir yok.
:
: Belirli bir risk ortaya veya , risk %100 ortaya
diye bir yoktur.
: Risk ortaya istenmeyen ve .
Genel risk :
Proje riskleri
Teknik riskler
riskleri
risk ve risk bkz. SEI, ISO, ANSI,
makaleler, kitaplar, vb.

167
 29

2
Proje riskleri:
Proje tehdit eder.
zamanlama ileri tarihlere sarkar ve maliyet artar.
: riskleri, Zaman riskleri, Personel riskleri, vb.
Teknik riskler:
kalitesini ve bitirilmesini etkiler.
veya .
, , ve ile ilgili risklerdir.
: 'Son teknoloji' teknik riske sahiptir.
Bug'larvar ? tam ? Tam anlayabildik mi bu teknolojiyi? da bu
teknoloji hayatta olacak ?
riskleri:
Pazar riskleri: talep olur mu? . , makinesi
riskleri: Pazarlama ekibi biliyor mu?
MIS/MBA !

168
 30

Risk tablosu :
ekip veya risk ekibinin riskleri .
Risklerin belirleyin (proje, teknik, )
Herkes kendi risk riskleri alt .
. Teknik: Planlanandan daha yeniden , deneyimsizlik,
vb.
Risklerin belirleyin.
, orta, gibi kategoriler.
Risklerin etkilerinin
bir , haydi gayret, siz beni .
, .
Bu bilgilerden bir tablo .
ID, ad, , , etki.
Listeyi bir yerden sonra kesin ( ve etkileri ).
Ele riskler risk bilgi .
Bu sayfa risk bilgiler ve .
riskler ise alternatif planlar .

169
 31

170
 32

Etki: Ticari

satmak

171
 -1

1
bir , ortaya
.
, her , hatalara .
Gereksinimler ,
ile uygulama uyumsuzluklar,
,
,
vb.
, .
bir , erken belirlenmesine bulunacak ve
kalitesini .
Bir :
Planlama

Bilgi toplama ve

172
 -2

GENEL 2
genel :
ve sistem .
tek bilgisayar ibaret olmayabilir.
Sistemin , harici sistemler, vb. yer alabilir.
bireysel ,
kadar .
teknikleri
uygun .
Projenin teknikleri uygun .
hem ilgili , hem de
.
kurumlarda bir ekibi bulunabilir.
ve hata , ancak hata her
bir .
Resmi teknik sayesinde de hatalar
belirlenebilir.
Formal technical reviews, ileride .

173
 -3

Bir ilk olarak onu .

Bir en iyi olarak bilen, onu .
Her zamanda .
evinin bir ekibi bulunabilir (ITG: Independent Test Group).
Aksi halde projelerde ekipler, veya projenin alt ,
birbirlerinin .
, kendi , ve dahilinde
gerektirir.
Psikolojik bir eylemdir.
Bu nedenlerle kendi bulmaya ,
ispatlamaya .
teknik olmayan da (ileride ).
:
sonunda . mi siz onlardan ! Aksi
halde prestijiniz .

174
 -4

gereken konular:
, en gerektiren etkinlikleri
yer .
, bir olarak
.
ne kadar , tespit edilemeyen hatalar .
Hedefler belirlenmelidir:
Testlerin kapsama ,
ne kadar kaynak ,
zaman, ,
belirlenecek
hata ortalama (MTBF), hassasiyet, vb.
.
ve .

175
 -5

:
Kara kutu (Black-box testing): birimin bilinmez,
sadece birimin beklenen girdilere beklenen
.
Beyaz kutu (White-box testing): birimin bilinir ve
buna belirlenir.
:
(verification tests): ekibi .
Birim

(validation tests): Son .

Alfa
Beta

176
 -6

1
Birim (Unit testing)
En .
bireysel .
Ne zaman ?
Kodlamadan ( ),
kodlama ,
veya .
Kodlama veya .
Bir tek , bu
yerine kod gerekebilir.
Vekil, sahte, kod/ , vb.
Stub, dummy, surrogate, proxy, vb.
Vekil , sadece duyulan dek .
Vekil basit , ek kodlama .
Bu ,
.

177
 -7

SINAMALARI 2
Birim aranabilecek hata :
veri tiplerinin veya birbirinin yerine .
: yan etkileri

hatalar
veya sonsuz

vb.
hatalardan ders :
kodlama , ancak kariyeriniz boyunca
her hata bu aranabilecek hata listenize ekleyin.

178
 -8

3
(Integration testing)
birim , bir araya getirildiklerinde de
?
her her belirlenmesi beklenemez.
, kendi karar verme yetkilerini (initiative)
kullanabilir.
kararlar bile birbiri ile uyumlu olmayabilir.
birim ve birbirinden kesin
yoktur.

179
 -9

4
:
Tahribat (smoke testing)
ancak olma durumunda sistemin
(show-stopper errors).
.
gerekli (kod, ,
, vb.) bir araya getirilir (build) ve olarak .
Geriye (regression testing)
yeni bir veya , yenilenmesidir.
Hangi bir eklentinin geriye vermek gerekir.
ve masraf artar.
Otomatik masraflar .

180
 - 10

1
(validation testing):
Gereksinimler belgesinde olan yola ,
.
Son beklenmedik , teknik ekip
bilemez.
Fincan Pencereyi
Bir ne kadar incelerse, ondaki kusurlar o kadar bulunur ve
.

Alfa ve Beta olmak iki .

181
 - 11

2
(validation testing):
Gereksinimler belgesinde olan yola ,
.
Son beklenmedik , teknik ekip
bilemez.
Fincan Pencereyi
Bir ne kadar incelerse, ondaki kusurlar o kadar bulunur ve
.

Alfa ve Beta olmak iki .

Alfa :
, .
ekibinin denetiminde ve izlemesi ile .
en .
Beta :
kendi yeri , .
ekibi olmaz.
Bulunan hatalar ekibine ve resmi bir bildirilir.

182
 - 12

tek sistemin .
uygulamalar, ara katman , vb.
Sistemin her incelemeye :
Kurtarma (recovery) :
Hatalara (fault tolerant) sistemler .
Bir hata ortaya sistemin kendini toparlayarak devam edip
.
Kurtarma belli bir (MTTR: Mean Time To Repair).
(security) :
Tek kural: Kural yok!
Her sonunda !
Zorlama (stress) :
Normalin durumunda, sistemin nereye kadar
(performance) :
uygulamalarda sahiptir.
Program kendisinden bekleneni yapabilir ama yapamayabilir.

183
 - 13

HATA AYIKLAMA (DEBUGGING)

sonucunda bulunan hatalar .
ve hata kimileri angarya ayak
ikinci olarak nitelendirilebilir.
hatalar size ve kurumunuza prestij kaybettirir.
veya uzun hatalar ise daha prestij kaybettirir.
ve belirlenmesi
gerekir ki bu da bir yetenektir.
duyulan ve , hata kodlama yapmaktan daha zor ve daha
yetenek isteyen bir .
Bir noktada , biraz ara verip sorunu yeniden incelemeniz,
.
hata yeteneklerinden sonuna kadar .

184
 - 14

: Software review
, eylemlerinden daha az masrafla,
.
ile bulunabilecek hatalar ile
bulunamaz, ancak daha verimlidir.
resmi veya gayri resmi olabilir.
resmi daha etkili .
durumunda.
programlama da bir .
Resmi : Formal software review
.
bir (review leader) bulunur.
Bu konuda standartlar .
: IEEE 1028

185
 - 15

IEEE 1028 std. bir resmi :

: standart bir checklist
kullanarak, verimli bir gerekli .
: Sorumlu gerekli
ve standartlara uygun .
genel :
ve
emin olur.
Bireysel : bireysel olarak inceleme
. Bu malzemede hataya yol
bozukluklar (anomaly) .
Grup incelemesi: Bireysel belirlenen yer ve
zamandaki biraraya getirilir ve raporu .
: yazar veya atanacak bir /ekip,
belirlenen .
: inceler.

186
 - 16

jUnit, Java ile kodun birim bir

(framework)
diller de .
. C# csUnit
IDE :
Eclipseve ile geliyor.

187
 - 17

jUnit 3.X ileTest Case :

Her birim testi test .
Test test toplanabilir. TestAll.suite( ) metodu statiktir.
TestCase.setupmetodu her testXXX() yeniden .

188
 - 18

ileTest
annotation

TestCase
gerekmemektedir.

annotation koymak yeterlidir.

@Before
publicvoidsetUp(){ /*Preparations*/ }
@Test
publicvoidtestSomething() { /*Do test*/ }

@Test(expected=SomeException.class)
publicvoidtestTheException() throwsException {
doSomethingThatCreatesTheException();
}
189