Professional Documents
Culture Documents
2022 05 98
2022 05 98
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
17
SINAMA:
18
BAKIM:
porting)
19
BAKIM:
-
(Refactoring / Software re-engineering)
20
1-
Prokeler %70-
-60
21
Makine Seviyesi (01110110011)
22
-1
CASE (Computer Aided Software Engineering)
Integrated Programming
Support Environments
23
-2
24
-3
25
-4
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
denebilir.
30
-modelleri - 5
1.
2.
1.
2.
Eksiler:
1.
2.
1.
31
-modelleri - 6
32
-modelleri - 7
33
-modelleri - 8
34
-modelleri - 9
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
1.
2.
Eksiler:
-Kazan Modeli
38
10. -modelleri - 13
39
10. -modelleri - 14
uygundur.
1. Planlama:
2.
3.
4.
1.
2.
Eksiler:
1.
2.
3.
40
10. -modelleri - 15
Sarmal (Spiral)
Model:
41
10. -modelleri - 15
42
10. -modelleri - 16
43
10. -modelleri - 16
Agile
Tekrarlanan
44
10. -modelleri - 17
Agile
Edmonds
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,
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
63
10. -modelleri - 34
Agile
64
10. -modelleri - 35
Agile
Scrum:
-4 hafta) .
65
10. -modelleri - 36
Agile
66
10. -modelleri - 37
67
10. -modelleri - 38
Incomplete).
Initial/Performed
tekrarlanabilir.
Defined
QuantitativelyManaged
Optimized
68
10. -modelleri - 39
CMMI-
CMMI-
CMMI-ACQ (Acquistion
1987-1997: CMM
1998-: CMMI
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
(entegrasyon)
71
10. -modelleri - 42
CMMI ve CASE
72
10. -modelleri - 43
Gereksinim
Analizi
Sistemin Sistem
Program
Teslim
Sistem Program
Testi
Testi Testi
73
11. -1
feasibility)
gereklidir.
74
11. -2
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
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
82
11. -9
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
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
-Bir satisKalemi
-satisKalemi satis
-satisKalemi.miktar
-satisKalemi
108
- 10
DESIGN BY CONTRACT
109
- 11
ACTIVITY DIAGRAMS
multithreaded)
111
- 13
ACTIVITY DIAGRAMS
112
- 14
ACTIVITY DIAGRAMS
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
124
-2
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
128
-6
129
-7
FPi
FPi
-orta-
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
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
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
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
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
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
151
- 13
:
Hata : Bulunan hata .
ve sonra bulunan ,
sahiptir.
Hata giderme :
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
155
17
156
18
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
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
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
164
26
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
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
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
.
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
.
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
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
186
- 16
187
- 17
188
- 18
ileTest
annotation
TestCase
gerekmemektedir.
@Test(expected=SomeException.class)
publicvoidtestTheException() throwsException {
doSomethingThatCreatesTheException();
}
189