Uygulama Geliştirmede Verimlilik için Entegre Uygulama Yaşam

Uygulama Geli tirmede Verimlilik için Entegre Uygulama
Ya am Döngüsü Yönetimi ve Dinamik Kalite Kontrolü
Integrated Application Lifecycle Management and Dynamic Quality
Control for Efficiency in Application Development
lker nan Çaynak
IBTECH A. ./Finansbank BT,
TUB TAK Yerle kesi,
Gebze/Kocaeli
ilker.caynak@ibtech.com.tr
Özet
Uygulama kullan lar n (iç ve d mü terilerin)
memnuniyetini üst düzeyde tutmak için isteklerini
hedef sürelerinde ve maliyetlerinde, gereksinimler
do rultusunda ve olabildi ince az hatal olarak
gerçekle tirmek
yaz m
ekiplerinin
temel
hedeflerindendir.
Uygulama geli tirme sürecinin sistematik bir
yakla mla ele al nmas , yönetilebilir bir proje ve
yaz m süreci kurmak ve bu süreci sürekli daha iyiye
götürmek bu hedef için vazgeçilmez unsurlar olarak
görülmektedir.
Yaz m süreç ve proje yönetimi konusundaki teknoloji,
süreç, araç, yakla m ve metodolojilerin incelenip,
yaz m geli tiren organizasyonun ihtiyaçlar ve
kültürü do rultusunda özümsenip, dinamik olarak
düzenlenebilen ve süreçler aras entegrasyonun
ba ar ld
bir
“Uygulama
Ya am
Döngüsü
Yönetim(UYDY) Sisteminin” haz rlanmas
ve
uygulanmas bu hedefleri gerçekle tirmede kritik
öneme sahiptir.
Bunun yan s ra, yaz m süreçlerinin her a amas nda
sistematik bir ekilde hedefe uygun metriklerin
toplan p, sürekli olarak süreci daha verimli k lacak
ekilde izlenmesi UYD’ nün kalitesini artt racakt r.
Yönetilebilir, ölçülebilir ve izlenir bir yaz m süreci
COBIT, BDDK, SOX, CMMI gibi bankac k ve BT
sektörüne yönelik denetim ve sertifikasyonlarla, iç
denetimlerin daha yönetilir olmas da sa lamaktad r.
management methodology and Software development
process are getting more important and indispensable.
It is very critical to search, follow and study
technologic, procedural and tool based improvements in
software
development
processes
and
project
management
methodologies
and
establishing
customized
“Integrated
Application
Lifecycle
Management (ALM)” system according to the software
organization’s needs and culture.
Furthermore, collecting and tracking metrics of each
process area in a systematic way, according to the
targets of the process will improve quality of the
Application Lifecycle. Having a manageable,
measurable and traceable software development process
provides manageable certification and audits processes
like COBIT, CMMI, SOX, BDDK and internal audits
that targets banking and IT sector.
1. Giri
Verimlilik i letmelerin gittikçe artan oranda
odakland
konular n ba nda gelmektedir.
süreçlerinin tan mlanmas , düzenlenmesi ve yeniden
yap lanmas tüm i kollar nda görülmektedir. Türk
bankac k sektöründe de bu yönde son 30 y lda hemen
tüm bankalarda ciddi çal malar yap lm
ve
teknolojinin geli imine paralel olarak i süreçleri ve
verimlilik sorgulan r olmu ve verimlili ini artt lmas
yönünde birçok çal ma yap lm r. [1]
Abstract
Realizing demands of an application, according to the
requirements of users, on time, inside of the budget
limits and releasing it with minimum defects are main
aims of software teams.
To reach those aims, having a systematic approach to
manage Application Life Cycle, a manageable project
Öte yandan teknoloji kullan
ve teknolojiye dayal
ürün geli tirme finansal araçlar n da vazgeçilmez bir
parças haline gelmi tir. Finans sektöründeki herhangi
bir ürünün, rekabette öne geçmeyi hedefleyen bir
pazarlama stratejisinin içinde teknoloji ve yaz m
olmaks n kullan lmas imkans z gibidir. Yaz m
teknolojileri sadece operasyonel verimlili i artt p,
sürekli tekrar eden i ler h zland rarak maliyetleri
dü ürmekle kalmay p, do ru ve h zl ekilde ürün
geli tirilmesiyle pazarlaman n da bir parças olmu ve
letmeyi bir ad m öne geçirmede etkili olacak bir
faktör olmu tur.
Uygulama
kullan lar n
veya
sahiplerinin
isteklerinin toplan p, projelendirilip, hedef sürelerinde
ve maliyetlerinde, gereksinimler do rultusunda ve
do ru çal r bir biçimde gerçekle tirmek için uygulama
geli tirme sürecinin sistematik bir yakla mla ele
al nmas yaz m organizasyonlar için kaç lmaz
olmu tur.
Di er birçok bilim ve teknolojik alana göre henüz daha
genç olan yaz m dünyas nda da uygulama ya am
döngüsü yönetimi, proje yönetimi gibi kavramlar son
llarda daha sistematik biçimde ele al nm bu konu
yaz m endüstrisinde bir dal olmu ve bu konuda
birçok teknoloji firmas ürünler geli tirmi tir. [2]
Çe itli proje yönetim metotlar elale, Spiral, RUP,
Agile vb.) ve CMMI, SPICE, ISO gibi yaz m olgunluk
modelleri bu süreci yönetmeye ve iyile tirmeye yönelik
olarak ortaya ç kan modellerden öne ç kanlard r.
2. Uygulama Ya am Döngüsü Rolleri
Uygulama ya am döngüsü yönetiminde süreç içerisinde
yer alan roller süreci yönetmek aç ndan çok
önemlidir. Birçok proje yönetim metodolojisi de
rollerini ve rollerin süreç içerisinde yer ald
sorumlulu u net olarak tarif etmeye çal maktad r.
Örne in popülerli i son y llarda artan Çevik
yöntemlerden Scrum rollerini net olarak belirlemi tir.
[3] IBTECH içerisinde de yaz m süreci içerisinde yer
alan
önemli
roller
a
da
tan mlanm r.
Organizasyonlarda
uygulanan
metodoloji
ve
organizasyon yap na göre farkl roller olabilir.
Entegre UYDY farkl rolleri tan mlay p, yetki ve
sorumluklar tan mlayarak, yönetebiliyor olmal r.
birimi sorumlusu
Portföy Yöneticisi
Proje Yöneticisi
Analisti
Yaz m Mimar
Yaz m Geli tirici
Fonksiyonel Testçi
Sürüm Yöneticisi
Yaz m Konfigürasyon Yöneticisi
3. Entegre Uygulama Ya am Döngüsü Yönetimi
Burada anlat lan entegre UYD, proje yönetim
metodolojilerinden ve olgunluk modellerinden ba ms z
olup, IBTECH’te kullan lan yap örne inde, istenen
yap n tan mlan p, uyarlan p, kullan labildi i dinamik
bir yap r. Araçlarla sa lanm entegre bir UYD,
istenen metriklerin toplanmas
sa lamakta, süreci
daha verimli k lacak ekilde yönetilmesi için, sistemin
izlenerek, metriklerinin kar la
larak, i hedefleri
do rultusunda sürecin kalitesinin artt lmas nda da
faydal olmaktad r.
IBTECH içinde yer alan uygulama ya am döngüsü
yönetimi, yaz m endüstrisinde geli en e ilimler
do rultusunda, yukar daki hedefleri kar lamaya
yönelik olarak dinamik biçimde düzenlenmektedir. Bu
dinamizmi sa lamak için de sürecin sadece
prosedürlerle yönetilmesi yerine entegre bir üretim hatt
kurulmu tur.
Mevcut baz araçlar n kullan lmas n yan s ra iç
kaynaklarla geli tirilen yaz mlarla, yaz m geli tirme
süreci seçilen proje metodolojisi do rultusunda birbirini
takip eden süreç ad mlar na dönü türülerek takip
edilmektedir.
Bu dokümanda IBTECH’te kullan lan yaz m
süreçleri, her süreç sonunda ortaya ç kan ç kt lar ,
süreci sa lamak için gerekli araçlar n özelliklerini ve
ölçümlenen metrik kriterleri anlat lacakt r.
UYDY farkl organizasyonlarda farkl biçimde
dü ünülebilir. Burada UYDY süreçleri ve kapsam için
daki süreç ad mlar detayland lm r.
steklerinin Toplanmas
steklerinin
projelendirilmesi
ve
planlanmas
Gereksinimlerin toplanmas ve yönetilmesi
Analizi
Uygulama Tasar
Yaz m Geli tirme
Yaz m
yap land rma
ve
sürümün
haz rlanmas
Test Yönetimi
Uygulaman n gerçek ortama al nmas
Problem Yönetimi
Yaz m Konfigürasyon Yönetimi
Tüm bu süreç ad mlar
tek platformda yönetebilir
duruma
getirmek
sistemin
yönetilebilirli ini
kolayla rmakta ve istenen metriklere de her aç dan
ula lmas
sa lamaktad r. Ancak sürekli geli en
teknoloji ve yaz m dünyas nda zaman içinde ç kan
ihtiyaçlar do rultusunda organizasyonlar farkl
zamanlarda, farkl ki ilerce de erlendirilip sat n al nan,
sürecin sadece bir veya birkaç
yönetmeye yarayan
araçlar kullanmakta, bu da tüm süreci yöneten birçok
arac n organizasyon içinde yer almas getirmektedir.
Ço u zamanda bir sürecin birden fazla araç içerisinde
yer almas yla araç seçimi ve entegrasyonu kar k ve
yetersiz olmaktad r. Tüm bu nedenlerden dolay
yukar da ad geçen tüm süreçleri entegre etmek ve
yönetilebilir bir sistem kurmak kritik olmakta, bunu
sa lamak için de bütünsel bir yakla m gözetip her
ad mda izlenmesi istenen kriterlerin organizasyon
taraf ndan net olarak ifade edilmesi gerekmektedir.
da her süreç ad , IBTECH içindeki yakla k 10
la var lan çal malar sonucunda elde edilen
deneyimler ve bu konudaki e ilimler takip edilerek,
detayland lm r.
Süreçler, birbirleriyle etkile im içindedirler ve UYD
içinde birbirleriyle iç içe, geçi li, paralel veya di er bir
süreci bekleyerek ya amaktad rlar. Buradaki ayr rma;
sadece süreçleri anlat m ve ç kt lar net olarak ifade
içindir.
Birimi
Birimi
Sorumlusu
Sorumlusu
Porttföy/Proje
Yönetcisi
steklerinin
steklerinin
Toplanmas
Toplanmas
steklerinin
steklerinin
projelendirilmesi
projelendirilmesi
ve
ve planlanmas
planlanmas
Gereksinimlerin
Gereksinimlerin
toplanmas
toplanmas
ve
ve yönetilmesi
yönetilmesi
Analisti
Analisti
Analizi
Analizi
Uygulama
Uygulama Tasar
Uygulama
Uygulama
Mimar
Mimar
UYDY
UYDY Araçlar
Araçlar
Proje
Proje Yönetim
Yönetim Arac
Arac
Varl
Varl kk Kütüphanesi
Kütüphanesi
Kaynak
Kaynak Kütüphanesi
Kütüphanesi
Yaz
Yaz m
m Geli
Geli tirme
Yaz
Yaz m
m
Geli
Geli tirici
tirici
Yaz m yap
yap land rma
rma
ve
ve sürümün
sürümün
haz
haz rlanmas
rlanmas
Test
Test Yönetimi
Yönetimi
Analisti
Analisti
Uygulaman
Uygulaman nn gerçek
gerçek
ortama al
al nmas
nmas
Birimi
Birimi
Sorumlusu
Sorumlusu
Problem
Problem Yönetimi
Yönetimi
ekil 1: Uygulama Ya am Döngüsü
3.1.
isteklerinin toplanmas
birimlerinin mevcut sistemde bir de iklik,
iyile tirme veya tamamen yeni bir i iste inde
bulunmas durumunda bu iste ini Bilgi Teknolojisi(BT)
birimlerine iletmesi için bir yap kurulmu tur. Web
ortam nda çal an bir i ak (Workflow) uygulamayla
da tüm i istekleri izlenebilmekte, hangi statü de oldu u
her an gözlenebilmektedir. Bu sayede isteklerin tasnifi,
takibi kolayl kla yap labilmektedir.
Talepleri i biriminin süzgecinden geçirmek
amac yla her birimde, birimin seçti i bir BT
Temsilcisi (Genellikle yönetici) belirlenmi tir.
Her i
iste i sistemde tan mland nda
tek(unique) bir numara al r ve girilen tarih ve
giri i yapan kullan kaydedilir.
iste i öncelikle i birimi temsilcisinin
de erlendirmesinden geçip, ondan sonraya BT’ye
aktar r. Burada beklenen i biriminin bu talebi
kendi içinde detayl de erlendirmesi, fayda
maliyet analizini yapmas ve ilgili ekiplerle ve BT
portföy yöneticileri ile de bilgi al veri i yap p
talebi BT’ye yönlendirmesidir.
BT’ de her i
biriminin i
isteklerini
de erlendiren ve i birimiyle sürekli etkile im
içinde olan Portföy Yöneticileri atanm r.
istekleri öncelikle uygulamayla ili kili portföy
yöneticisi onay na dü er. Portföy yöneticisi eksik,
anla lmaz buldu u talepleri talebi girene geri
gönderebilir veya kabul eder. Sistem her a amada
ilgili ki ilere e-mail ile bilgilendirme yapar.
3.1.1.
Süreç
entegrasyonu
Ç kt lar
ve
di er
süreçlerle
Süreç sonunda sistemde özel, tek(unique) bir koda
sahip, giri yap ld nda veya onayland nda girilen
her tür bilgisi saklanan bir kay t yarat lm olur.
Sürecin di er süreçlerle entegrasyonu talep kodu
(demand code) üzerinden yap r.
3.1.2.
bilgiler
Entegrasyon
ve
Metrikler
için
gerekli
iste ini talep eden ki i ve onaylayan temsilci, iste in
ili kili oldu u uygulamay , önceli ini, bitirilmesi
beklenen tarihi, ili kili olabilecek di er ekipleri, talebin
detayl aç klamas
ve faydalar
tan mlar. Tüm
bilgiler saklan p, di er sistemlerle entegre oldu unda
daki gibi baz örnek metrik raporlar ve birçok
kombinasyonuna ula labilir.
isteklerinin talebe dönü tü ünde tahmin edilen süresi
ve gerçekle tiririm süresi.
kategorisi baz nda i istekleri ve ayl k tamamlanma
raporu.
Birim baz nda istenen/tamamlanan belirli periyottaki i
istekleri.
3.2.
isteklerinin
maliyetlendirilmesi,
projelendirilmesi ve planlanmas (Proje Yönetimi)
Bu süreç proje yönetimi aç ndan birçok alt süreci
içinde bar nd rmakta ve i birimlerle ileti imin ve
planlaman n ba lang ç a amas olarak do ru sonuca
ula mak için kritik bir a ama olmaktad r. Bu süreçte
yer alan alt süreçler Proje Yönetimi, De iklik
Yönetimi ve Efor Tahmini eklinde s ralanabilir.
birimlerinden gelen talepler BT’ de portföy
yöneticileri taraf ndan kar lan r. Portföy yöneticisi
talebi ilgili i analisti ve yaz m mimar ile
payla r. Ön analiz yap r. in kapsam , boyutu ve
maliyeti tahmin edilmeye çal
r.
Daha önce bildirilen benzer talepler ve projeler
incelenir. Yürüyen bir proje kapsam nda de iklik
olup olmad
incelenir. Benzer talepler varsa
birle tirilip de erlendirmeye al narak veya farl
yanlar
varsa
parçalanarak
de iklikler
yönetilmektedir.
Organizasyon içinde maliyeti etkileyen girdi
parametrelerinin netle tirilmesi(tecrübe, anket vb.)
ve tahmin s ras nda ilgili ki ilerce bu girdiler
do rultusunda tahmin yapan bir sistem kurmak,
tahminde do rulu u artt r. Maliyet tahmini
yap rken metodolojik yakla mak ve ö renen bir
sistem kurmak, ki isel tecrübenin kullan lmas
yan nda, elde edilen sonuçlar n sistematik olarak
saklanmas , tahminde sürekli iyile meyi getirir.
IBTECH içerisinde proje sonunda beklenen
uygulama ç kt lar n lineer olarak gerektirdi i
efor tahmin sistemi uzun zaman kullan lm ,
imdilerde
ö renen
algoritmalarla
ve
gerçekle tirimin sürekli olarak sistemdeki veriyi
besledi i bir yap ya Bo aziçi üniversitesinden
Softlab ile beraber geçilmeye çal lmaktad r.
Efor tahmini sonucunda farkl büyüklükteki i
isteklerine farkl yakla mak önemlidir. Her i
iste ini ayn
ekilde planlamak, ayn proje
metodolojisiyle
yönetmek
gerçekle tirimde
nt lara sebep olabilir. Bu nedenle talep için
gereksinim duyulan eforla ili kili olarak projeler
kategorize edilmektedir. IBTECH’te 15 adam i
gününe kadar olan i ler Talep, 15-40 adam gün
sürenler Küçük Proje, 40 adam günden uzun süren
projeler Büyük Proje olarak adland lmaktad r.
Bunun d nda i kolunun ve iste in durumuna
göre bu projeler için farkl alt kategoriler de
belirlenmektedir.
Projenin tipine, kategorisine göre ihtiyaç duyulan
süreçler ve ç kt lar farkl k göstermektedir. Tüm
projelerde ayn proje yönetim biçimini uygulamak
ve ayn sürecin izlenmesini beklemek pratikte
nt lar ya atmaktad r. Bu nedenle farkl tipte
projeler için süreç ak lar tan mlanm
ve
projelerin bu süreçleri içerecek ekilde ilerlemesi
ve ç kt lar üretmesi beklenmektedir. Mevcut proje
tiplerinin yeni bir projeye uymamas durumunda
yeni bir proje süreci olu turulmaktad r.
Projeler için proje yöneticisi ve ekibi belirlenir,
lgili BT ekibinin kaynak yöneticileri kaynak
durumlar na ve elemanlar n uzmanla mas na göre
projede çal acak ekip elemanlar
belirler. Proje
tan mlan r ve plan yap r, kaynaklar ilgili
görevlere atan r ve proje ba lat r.
Küçük
projelerin
gerçekle tirimini
portföy
yöneticileri, kaynak yöneticileri ile takip eder.
birimi baz nda yarat lan bir proje alt nda, küçük
projeler olarak takibi yap r. Her bir küçük
projenin izlemesi gereken bir ya am döngüsü
vard r.
Talepler(k sa süren i istekleri) daha h zl bir
biçimde ele al r.
birimlerine paralel bir
organizasyonla
kurulan
yaz m
kaynak
yöneticileri; taleplerin gerçekle tirimini yapar. Her
bir talebin izlemesi gereken bir ya am döngüsü
vard r.
3.2.1.
Süreç
entegrasyonu
Ç kt lar
ve
di er
süreçlerle
Proje tan
proje yönetim arac na tan mlan r ve
özgün, tek(unique) proje kodu olu turulur. Projede
yap lacak ve bir önceki süreçte anlat lan i istekleri ile
proje ili kilendirilir. Entegre bir UYD için bu ili kinin
kurulmas önemlidir.
Projenin hangi uygulama süreç yönetim tipinde
yönetilece i tan mlan r ve her süreç ad
için ihtiyaç
duyulan roldeki ki iler atan r.
Proje tan m, amaç ve ekibinin oldu u tan m doküman
olu turulur. Görevlerin hiyerar ik olarak tan mland
ve kaynaklar n atand
Proje plan haz rlan r. Proje
plan ndaki her bir görevin tek ki iye verilecek ekilde
parçalanmas ve sonras nda bu görevlerin proje yönetim
arac nda tan mlanmas önemlidir. Bu oldu u takdirde
görevlerin(task) durumu, projede çal an yaz m
geli tiricisi ve di er ekip görevlilerince çal ma an nda
güncellenebilir.
Proje yönetimi s ras nda di er birçok ç kt
organizasyonun
ihtiyac na,
proje
yönetim
metodolojisine, projenin UYD tipine göre belirlenebilir.
(Proje kapsam doküman , Risk doküman vb.)
3.2.2.
bilgiler
Entegrasyon
ve
Metrikler
için
gerekli
Alt süreçler baz nda toplanacak a
daki bilgiler
projenin sonunda birçok metrik bilgisini ula lmas
sa layacakt r.
De iklik Yönetimi
iste inin de im tarihçesi, statüsü, de en konular,
yeni eklenenler, ç kanlar, isteyen ki i ve tarih gibi
bilgileri içermektedir.
Efor Tahmini
iste inin tahmin edilmesinde kullan lan girdiler ve
UYD her bir süreç için tahmin edilen adam/gün
maliyeti saklanmal r. Proje sonunda gerçekle en
de erler ile tahmin edilen de erler e le tirilmelidir.
Proje Yönetimi
Projedeki görevler; ki i ve süreç tipi baz nda kategorize
edilmeli,
tahmini
ve
gerçekle me
süreleri
saklanmal r.
UYD içindeki her bir süreçteki parçalar(Artifact); proje
ve/veya projedeki görev ile ili kilendirildi i takdirde,
proje baz nda tüm süreç ad mlar ile ilgili çok detayl
metrikler toplamak mümkün olmaktad r. Tüm süreç
temelde, i iste i ve proje emsiyesi alt nda takip
edilmektedir.
3.3. Gereksinimlerin toplanmas ve yönetilmesi
biriminin iletti i steklerin detayland lmas bu
amada yap lmaktad r.
birimleriyle ilgili i
analistleri gerçek gereksinimleri netle tirir.
birimleriyle istenen i iste inin detayland lmas
amac yla sürekli ileti im içinde olmak, toplant lar
yapmak, yönlendirmek ve istenenleri teyit etmek
bu a amada kritiktir.
ste in Fonksiyonel, teknik, kanuni, görsel tüm
gereksinimleri, k tlar , kurallar bu a amada i
birimlerinden
toparlan r
ve
i (kullan )
gereksinimi olarak kaydedilir. [4]
analisti yaz m mimar ile de görü erek i
gereksinimlerini sistemdeki çözümüyle ili kili
olarak Çözüm(sitem) gereksinimine çevirir. [4]
Çözüm gereksinimleri; kendi içerisinde farkl
tiplerle, takip amaçl olarak kategorize edilebilir.
ve Çözüm gereksinimleri aras nda izlenebilirlik
kurmak
önemlidir.
Çözüm
gereksinimleri
yarat lma sebebi olan
gereksinimi ile
ili kilendirilir.
Bu a amada i birimlerinden gereksinimlere
yönelik de iklik talepleri sürekli gelebilir. Yeni
talepleri eskilerle etkile imini göz önüne al p,
harmanlayarak ili kilendirmek önemlidir.
Gereksinim
yönetim
arac
kullanarak
gereksinimleri ve ili kileri tan mlamak bu süreci
kolayl kla yönetmek ve di er süreç ad mlarlar yla
entegre etmek için önemlidir.
3.3.1.
Süreç
entegrasyonu
Ç kt lar
ve
di er
süreçlerle
Gereksinimler proje baz nda tan mlan r.
gereksinimleri ve Çözüm gereksinimleri eklinde ayr
veya birle ik bir doküman ç kar.
Gereksinim arac n; proje yönetimi s ras nda
tan mlanan projeyi tan yarak, giri lerin yap labilmesine
olanak sa lamas , entegrasyonu kolayla
r.
gereksinimlerini, yarat lma sebebi olan i iste ine,
sistemsel olarak ba lamak entegrasyon aç ndan
önemlidir.
3.3.2.
bilgiler
Entegrasyon
ve
Metrikler
için
gerekli
Gereksinimlerin ait oldu u proje bilgisi, tarihçesi
(de im, tarih ve yazan bilgisi) tutulmas önemlidir.
iste i-i gereksinimi-çözüm gereksinimi ili kisinin
tutulmas , sürecin takibini kolayla
r.
Daha sonradan i gereksinimi-test plan -bulgu ili kisi
ve çözüm gereksinimi-analiz-tasar m parçalar ili kileri
kuruldu unda
tüm
süreç
izlenir
duruma
gelebilmektedir.
3.4.
Analizi
analizi ve gereksinimlerin toplan p yönetilmesi
süreçleri; birbiriyle iç içe geçen süreçlerdir. Bu süreçte
toplanan gereksinimler do rultusunda ve yaz m
mimarlar yla görü ülerek gereksinimin ihtiyaç duydu u
çözümler
modellenir,
detayl
olarak
yaz r,
somutla
r.
Öncelikle sistemin genel görünümü ve i leyi i
modellenip k saca anlat r. Analiz doküman n
ilk bak ta görülecek bu k m sistem genel olarak
anlamak ve i leyi i kavramak aç ndan önemlidir.
Detay k sm nda her bir gereksinimin kar
olan
çözüm netle tirilir. Ekran, rapor vb. kullan
ili kisi olan ara yüzler belirlenir ve i leyi in nas l
olaca
(Hesaplamalar, onaylar, muhasebesel
lemler vb.) detayl olarak yaz r.
Bu a amada modelleme sistemin anla rl
artt rmaktad r. UML ile modelleme genel bir
standart olmakla beraber, temelde önemli olan
sistemi aç klay net modellerin olmas r.
IBTECH içinde Nesneye Yönelik (Object OrientedOO) programlama dilleri (Java, C#) a
kl
olarak kullan lmakta oldu undan OO Modelleme
teknikleri de k smen kullan lm r.
analizi
modelinden uygulama tasar m modeli ve
sonras nda da kod iskeletlerinin üretilmesi, tam
entegrasyon için çok yararl r. Ancak bu yakla m
için i analizinin modellemesinde domain ve nesne
bazl modellemenin organizasyon içinde çok iyi
kavranmas ve benimsenmesi gereklidir.
Analiz dokümanlar üretildikten sonra, teyit amaçl
olarak i birimleriyle tekrar payla lmaktad r. Bu
lem öncesi analizin içerik ve standartlara
uygunluk aç ndan i analizi ekibi içindeki yetkin
ki ilerce kontrol edilmesi kaliteyi artt rmaktad r.
Küçük proje ve taleplerde talebin/projenin
boyutuna göre burada yap lacak analiz çal malar
sadele tirilebilir.
3.4.1.
Süreç
entegrasyonu
Ç kt lar
ve
di er
süreçlerle
Çözüme yönelik modellerden ve aç klamalar ile
gereksinimleri de içeren i analizi doküman olu ur.
analizinin de erlendirilip, gözden geçirilip, farkl
kriterlerle puanland gözden geçirme formlar olu ur.
analizi haz rlarken kullan lan arac n gereksinim
yönetimi arac yla ayn ortamda olmas veya entegre
olmas ; i analizindeki çözümü, ilgili gereksinimle
ili kilendirmek için önemlidir.
analizi doküman n hangi konu ba klar ndan
olu tu una dair bir standart varolup, UYD içinde yer
alan di er araçlarla entegre bir araç kullan larak
doldurulmakta ve kaynak kütüphanesi üzerinden tüm
tarihçesine ula labilmektedir.
3.4.2.
Entegrasyon ve Metrikler için gerekli bilgiler
analizi parçalar n(Artifact); tan mlanan proje
alt nda yer almas ve tarihçe, kullan , tarih,
kaynaklanan gereksinim ili kisinin saklanmas ,
sonradan ölçümlenmek istenen metriklere ula lmas
kolayla
r.
3.5. Uygulama Tasar
Uygulama tasar
projenin ba ndan itibaren UYD
içinde yer almas i isteklerin di er sistemler üzerindeki
etkisi, i in zamanlamas , ne kadar sürece i, nas l
çözüm getirilece i konular n netle mesi aç ndan
önemlidir.
Öncelikle sistemin genel görünümü ve i leyi i
tasar m aç ndan modellenip anlat r. Çözüm
alternatifleri listelenir ve uygun çözüm gözden
geçirmelerle kararla
r. Çözüm birden fazla
ekibi etkiliyorsa her ekip kendi bölümünü haz rlar
ve projenin mimar ile gözden geçirilerek ortak bir
çözüme ula r.
IBTECH’te
nesneye
yönelik
programlama
yap ld ndan S f(Class) ve S ral (Sequence)
diyagramlar UML kullan larak haz rlan r. Yeni
ve de en s flar s f diyagram nda yer al r.
Servise yönelik mimari (SOA) kullan ld
için;
de en ve yeni servisler için s ral diyagramlar
çizilir.
Yeni ve de en tablolar içeren veri modeli
tasar , birbirileriyle ili kileri ile tan mlan r.
Sistemin bütününe etkisi incelenip yan etkiler
belirlenir ve tasar m doküman na yaz r. Tablo ve
veri dönü ümündeki ihtiyaçlar belirlenir. Log,
rapor, ön d sistemlerle etkile imi, gün sonu
lemlerine etkisi gibi teknik ve bankac a özgü
spesifik etkiler detayl ca raporlan r.
Tasar m dokümanlar üretildikten sonra, içerik ve
standartlara uygunluk aç ndan uygulama mimari
ekibi içindeki yetkin ki ilerce kontrol edilmesi
kaliteyi artt rmaktad r.
3.5.1.
Süreç Ç kt lar ve di er süreçlerle
entegrasyonu
Çözümün tasar na yönelik genel yap , modeller,
aç klamalar ve yan etkileri içeren detayl tasar m
doküman olu ur.
Tasar n de erlendirilip, gözden geçirilip, farkl
kriterlerle puanland formlar olu ur.
Tasar m haz rlarken kullan lan arac n i analizi
arac yla ayn olmas veya entegre olmas ; tasar mdaki
modelleri, ilgili gereksinimler ve i analizi parçalar yla
ili kilendirmek için önemlidir. Arac n modelleme ve
editör i lemlerini beraber yap yor olmas tüm i lemleri
tek ortamda haz rlayabilmek ve takibi aç ndan
önemlidir.
Tasar m doküman n hangi konu bal klar ndan
olu tu una dair bir standart varolup, bir araçla
doldurulmaktad r. Tasar m parçalar , tan mlanan proje
alt nda yer almakta ve proje baz nda tüm tarihçesine
kaynak kütüphanesi üzerinden ula labilmektedir.
3.5.2.
bilgiler
Entegrasyon
ve
Metrikler
için
gerekli
Tasar m parçalar n tan mlanan proje alt nda yer
almas ve tarihçesinin kullan , tarih, kaynaklanan
gereksinim
ili kisinin
saklanmas
sonradan
ölçümlenmek istenen metrikleri kolayla
r.
Tasar m modelinde modellenen ve tasarlanan
parçalar n, varl k kütüphanesindeki tan mlarla (bile en,
servis, ekran, rapor vb. ) ili kili olarak yarat lmas ,
projede yarat lan de ikliklerin neler oldu u ve
adetleri gibi konularda ki bilgilere h zl ca ula lmas
sa lamaktad r.
3.6. Yaz m Geli tirme
Yaz m geli tirme süreci di er süreçlerden ç kan
bilgilerle, istenen, planlanan i iste inin, do ru çal r
ekilde haz rlanmas a amas r ve kritiktir. Yaz m
tasar , yap land rma ve sürüm haz rlanmas ve test
süreçleriyle iç içedir.
Yaz m geli tirme diline özgü standartlar,
kurallar ve metrikler belirlenmesi ve yaz
n bu
kurallara uygun yaz lmas n kontrolü önemlidir.
IBTECH’te Java ve C# için yaz lm standartlar ve
metrikler belirlenip bu kurallara uyum, otomatik
olarak araçlarla yaz
yapan ki i taraf ndan da,
kontrol eden taraf ndan da denetlenmektedir.
Yaz
n ikinci bir ki i taraf ndan gözden
geçirilmesi ve sadece standartlar aç ndan de il
mant ksal ve tasar msal aç dan da kontrolü
yap lmaktad r. Bu da yaz m sürecindeki kaliteyi
artt rmaktad r.
Yaz m geli tiricilerin, geli tirim yapt
i
koluyla ileti imi, toplant lara kat lmas , konuya
hakimiyeti yaz m kalitesini art r.
Yaz mla ilgili her tür bile en, ekran, servis,
rapor, sorgu gibi geli tirilen parçalar Varl k
Kütüphanesine kaydedilir. Bu UYD’ de yer alan
parçalar asar nda ili ki kurma ve kullan baz nda
yetkilendirme aç ndan çok yararl r.
Tüm kodlar s f, paket ve bile en baz nda kaynak
kütüphanesinde saklan r ve tüm versiyonlar na
ula labilir.
Birim testi kodlar haz rlanmas ve uygulanmas
ürünün kalitesini artt rmaktad r. Ancak yaz m
ekiplerince
birim
testlerinin
haz rlanmas
önceliklendirmede arkalara dü erek istenen
verimde yayg nla
lamamaktad r.
3.6.1.
Süreç
entegrasyonu
Ç kt lar
ve
di er
süreçlerle
Proje/talep kapsam nda geli tirilen yaz
n kaynak
kodlar ve birim test kodlar bu süreçte üretilmektedir.
Kodlar n de erlendirilip, incelendi i, farkl kriterlerle
puanland gözden geçirme formlar olu ur.
Kod da de iklik yaparken, de iklik nedeni olan i
iste i veya problem ile ili kilendirmek, ayr ca proje
yöneticisinin atad
görev ile de ili kilendirmek
süreçler aras entegrasyon aç ndan kritiktir.
3.6.2.
bilgiler
Entegrasyon
ve
Metrikler
için
gerekli
Yarat lan, de tirilen kodun, versiyon bilgisi ile
kaynakland
proje, yaz m geli tirici, tarih, i
iste i/problem veya test bulgusu ile ili kilendirilmesi
birçok metrik raporunu besleyen veriyi sa lar.
Kodlar n, kalitesine yönelik metrik ölçümleri kod
kalitesini artt r. IBTECH içinde yaz lan Java
projelerinin her versiyonu için versiyon tarihi ve ki i
bilgisi ile a
daki kod metrikleri ölçümlenip veri
taban nda saklamakta, bu ekilde sürekli olarak kod
geli imi izlenip raporlanabilmektedir. Bu metriklerle
rl kl olarak kodlar n kompleksli inin ölçümü ve o
do rultuda yeniden düzenlenmesi hedeflenmektedir.
Sisteme özgü, her bir metrik için ideal hedefler de
belirlenmi olup, bu ideale uymayan kodlar, Deploy
sisteminde
yetkili
onay yla
üretim
ortam na
geçebilmektedir. Organizasyonun yaz m hedefleriyle
ve kulland yaz m diliyle ili kili olarak kendi metrik
kriterlerini ve ideal rakamlar
belirlemesi daha
yararl r.
Proje Baz nda toplanan metrikler
Projedeki s f, metot say lar , kod ve yorum(Comment)
sat r say lar , Yorum/Kod sat oran , Maksimum iç ice
döngü(Max. nesting), S flardaki ortalama metot
say , S flardaki metotlar n ortalama kompleksli i,
flardaki ortalama kod ve yorum sat r say lar .
f Baz nda izlenen metrikler
Metot say , kod ve yorum sat r say lar , yorum/kod
sat
oran , maksimum iç içe döngü,
s ftaki
metotlar n toplam kompleksli i.
Metot Baz nda izlenen metrikler
Metot kompleksli i(Cyclomatic complexity), Kod ve
yorum sat r say lar , yorum/kod sat oran , maksimum
iç içe döngü.
3.7. Yaz m
haz rlanmas
yap land rma(build)
ve
sürüm
Yaz m yap land rmas (build) ve yeni sürümün
kar lmas otomatik olarak yap lmakta, bu ekilde
yaz m geli tiricilerin bu süreçteki verimlili i artmakta
ve daha kolay yeni sürüm ç kar p, gerçek ortamda
devreye alabilmektedirler.
Uygulama diline özgü yap land rma kodlar bu
lemden sorumlu yaz m ekibi taraf ndan
uygulama geli tirme ortam na eklenti bir uygulama
olarak haz rlanm
ve yaz m geli tiricilerin
kullan na sunulmu tur.
Yaz m
geli tiriciler
uygulama
geli tirme
ortam nda kodlar n çal
rl ndan emin
olduklar nda ilgili menüyü seçerek, uygulamalar
bile en baz nda yap land rmakta ve sonucunda
çal r(exceutable, binary) kodlar olu maktad r.
Çal r kodlar bile en baz nda s
lm dosyaya
çevrilerek,
kaynak
kütüphanesine
at p
versiyonlanmaktad r. Bu ekilde tüm çal r
kodlara
da
istenildi i
anda
kaynak
kütüphanesinden ula labilmektedir.
Birim testler de yap land rma ard ndan ko ulacak
ekilde çal
labilir. Bu da de tirilen parçan n
yan s ra, etkilenen di er kodlar n da test
edilmesinde faydal olur.
3.7.1.
Süreç
entegrasyonu
Ç kt lar
ve
di er
süreçlerle
Çal r kodlar bu süreç sonunda ortaya ç kan temel
kt r. Yap land rma sonras nda birim test kodlar
çal
lm sa, sonuçlar da bu süreçte üretilmi olur.
Yap land rma esnas nda hangi i iste i/problem ile
ili kili yap ld
seçmek, çal r kodlar n bir
versiyonunun neden yarat ld
sorgulamada ve
uygulamay
gerçek
ortama
almada
önem
kazanmaktad r.
3.7.2.
bilgiler
Entegrasyon
ve
Metrikler
için
gerekli
Yap land lan ve sürümü ç kan kodun, versiyon bilgisi,
yapan ki i, tarih bilgisi ile kaynakland
proje, i
iste i/problem veya test bulgular n ili kilendirilmesi
birçok metrik raporunu besleyen veriyi sa lar.
Birim testleri yap lm sa, ilgili sürüme ait birim test
sonuçlar n kaydedilmesi, sürümün birim test
sonuçlar n raporlan p, fonksiyon testleri s ras nda
kan bulgular ve üretim sonras ortaya ç kan
problemlerle kar la rmal raporlar al nmas na olanak
sa lar.
3.8. Test Yönetimi
Test yönetimi UYD içinde her süreçte ödevleri olmas
gereken bir süreçtir. Bu k mda a rl kl olarak
fonksiyonel testlerin yönetilmesi detayland lmas na
ra men di er testlerden de bahsedilmektedir.
olmas na ra men ihtiyaç duyulan test tipine
yönelik olarak yap labilir.
Performans testleri sistem ekipleri taraf ndan
performans
test
araçlar yla
yap lmaktad r.
Güvenlik testleri güvenlik ekibi taraf ndan
özellikle d ar ya aç lan, güvenilirli i önemli web
uygulamalar
güvenlik araçlar yla ve gözden
geçirmelerle kontrol etmektedirler.
Test bulgular n çözümünde testi yapan ile
bulguyu çözen aras nda bir döngü kurularak bulgu
çözülene kadar döngü çevrilir.
3.8.1.
Süreç
entegrasyonu
IBTECH içinde i analizi ve fonksiyonel test i
analistlerinin sorumlulu undad r. analistleri tüm
yaz m süreci içerisinde yer ald klar ndan test
edilecek
konuya
hakimiyetleri
yüksektir.
Fonksiyonel, performans, regresyon (onay),
yap sal, güvenlik vb tüm test tipleri için test
senaryolar n önceden haz rlanmas kritiktir. Bu
testler birim, sistem, entegrasyon ve kabul testleri
olarak küçükten büyü e do ru uygulanmaktad r.
[6]
deal yakla m gereksinimler toplan rken ve i
analizini haz rlarken, paralelde gereksinimler
do rultusunda test planlar n(Test senaryo ve
durumlar n) haz rlanmas r. IBTECH içinde de
test
senaryolar n
haz rlanmas ,
testlere
ba lanmadan i
analizi sürecinin sonundan
ba layarak yap lmaktad r.
Birim
testleri
yaz m
geli tiricilerin
sorumlulu unda
olup
a rl kl
fonksiyonel
ve
di er
süreçlerle
Bu süreçte test senaryolar , bulgular ve bulgular n
çözümüne ait tarihçe olu ur.
Test planlar ilgili projenin alt nda tan mlanmas ve
kaynakland
gereksinim ile ili kilendirilerek ProjeGereksinim-Test Durumu ili kisinin kurulmas
önemlidir.
Test sonuçlar n ve bulgu giri lerinin test durumu
baz nda girilmesi durumunda yukar daki ili ki
bulgularla da e le tirilerek Test durumu-Bulgu ili kisi
kurulmu olur.
3.8.2.
bilgiler
ekil 2: Test Derinlikleri ve Test Çe itleri
Ç kt lar
Entegrasyon
ve
Metrikler
için
gerekli
Test durumlar n aç klamas , ba ar kriteri, tarihçe,
test sonucu, yapan ki i, kaynakland
proje,
gereksinim vb.. bilgileri saklanmal r.
Bulgunun giren ve çözen ki ilerce girilen tüm
tarihçesinin
kaydedilmesi
bulgularla
ilgili
raporlamalarda yararl olur.
Bulgu döngüsünde, bulgunun aç klamas , önceli i,
sebebi, kritikli i, tarihi, giren ki i, statüsü, görüntüsü,
kaynakland
test durumu, gereksinim, proje vb..
bilgilerin taraflarca girilmesi ileriye yönelik metrikler
toplanmas aç ndan önemlidir.
3.9. Uygulaman n gerçek üretim ortam na al nmas
Uygulamalar n gerçek üretim ortam na al nmas birçok
UYD arac nda sürecin parças gibi ele al nmas henüz
çok yayg n de ildir. Bu operasyon için farkl araçlar
kullanmak daha yayg nd r. Ancak UYD yönetiminin
daha sa kl olmas için uygulamalar n geli tirme,
test, kullan
kabul ve üretim ortamlar na at lmas
ras nda di er süreçlerdeki ödevleri zorlama ve
yönetme aç ndan yönlendirici olmaktad r. Bu ekilde
UYD yönetiminin entegrasyonu ve kontrolü
prosedürlerle de il, entegre bir i ak
sisteminin
yürüyen i leyi i ile sa lanmaktad r. Bu i leyi le test
senaryolar haz rlanmam , bulgular çözülmemi ,
belirli kod metrikleri tutturmam , içindeki sorgusunun
çal ma süresi zaman a
na tak lm kodlar n üretim
ortam na al nmamas veya yetkili bir onay sonras
üretime al nmas , metrik kontrollü entegre süreç
yönetiminin örneklerinden baz lar r.
Üretim ortam na al m s ras nda at lacak kodlar n
büyüklük düzeyi(dosya, paket, proje veya birçok
projeden olu mas ) önemlidir.
Uygulamalar çal rken, yeni kodu üretim ortam na
almak da kritik bir süreçtir. Bunun için de
zl (hot) Deploy mekanizmalar ve da
k
sistemlere
da tma
çözümleri
üretmek
gerekmektedir.
Ayr ca kod aktar yla beraber ilgili kodun
paralelinde yap lan tablo, sorgu de iklikleriyle,
parametrik tan mlar n, ekran ve raporlar n ayn
anda üretime al nmas da bu yap içinde
kurulmu tur.
IBTECH’te belirli bir i i yapan kodlar bir Java
projesi, bile eni(komponent) alt nda toplanm
olup,
bile en
baz nda
versiyonlan p,
yap land larak üretim ortam na al nmaktad r.
Eski versiyon tekrar üretime at nca da uygulama
eski haline geri dönmü olmaktad r. Bu Deploy
mekanizmas Geli tirme ve Test ortam na kod
aktar
için de kullan lmakta olup, kodlar n
üretime al rken Geli tirme ve Test ortamlar na
gitmesi zorunludur.
Büyük proje geçi lerinde ve belirli periyotlarda
toplu halde bile enlerin üretim ortam na
al nabilmesi için sürümler tan mlanmakta ve
geçi ler bu sürümlerle yürütülmektedir.
ITIL sürecine göre problem sistemde olu an bir veya
daha fazla kesinti veya kalitedeki dü ün neden
oldu u durumdur.[6] Problemler bu anlamda
uygulaman n üretim ortam na al nmas ndan sonra son
kullan
taraf ndan bildirilen bulgular n baz lar r.
Problem
yönetim
araçlar
ço unlukla
UYD
araçlar ndan ba ms z ve sadece yaz m de il tüm BT
ürün ve süreçlerini kapsayan bildirimler için
kullan lmaktad r. Ancak yaz m kaynakl bildirilen
problemler nedeni ile UYD çal ma ba lamas sürekli
olarak ihtiyaç duyulan bir konudur. O nedenle UYD
yönetim araçlar n Problem yönetimini kapsamas
veya en az ndan entegre olabilmesi sürecin takibinde
önemlidir.
Kullan
taraf nda ya anan bir olay n(incident)
bildirilip belirli a amalardan geçtikten sonra
yaz m problemi olarak nitelendirilmesi ile UYD
aç ndan süreç ba lar. Bu durumda yukar da
anlat lan ve UYD yönetiminde yer alan tüm
sürecin veya bir k sm n problemin çözümü için
devreye girmesi gerekir.
Bu nedenle yukar da anlat lan tüm süreç
ad mlar nda süreci ba latan i biriminin iste inin
yerini bu durumda problem al r. Bunu
yönetebilmek için de UYD yönetim arac n
problem yönetim arac yla entegrasyonu gereklidir.
3.9.1.
Süreç
entegrasyonu
3.10.1.
Süreç
entegrasyonu
Ç kt lar
ve
di er
süreçlerle
Bu süreç sonunda uygulamalar üretim ortam na
al nm
olur.
iste i/Problem,
Talep/Proje
tamamlanm
olarak i aretlenip, kapat r. Üretim
ortam na al nma ile ilgili tüm Deploy kay tlar
saklan r.
3.9.2.
bilgiler
Entegrasyon
ve
Metrikler
için
gerekli
Deploy talebi s ras nda üretime al nacak bile en
versiyonu, talep eden ki i, tarih, statü, gidece i
sunucular, neden olan proje, i iste i/problem, vb..
bilgiler girilerek Deploy ile nelerin üretime al nd na
dair bilgiler sonras nda takip edilmek üzere kay t alt na
al nm olur.
Ayr ca yaz m mimar n yapt
Deploy iste i
sistemsel olarak yetkili ki ilerin onay ndan geçmesi
sa lan p tüm onaylar ve yap lan i ler kay t alt na
al nm olur.
Bütün bunlar üretim ortam na yaz mc lar n elle
ula mas
engelleyip, kontrollü geçi i sa lamaktad r.
Buna ek olarak, herhangi bir zamandaki geçi ; geçmi e
yönelik olarak tüm detaylar yla raporlanabilmektedir.
3.10.
Problem Yönetimi
Ç kt lar
ve
di er
süreçlerle
Problem tan mlan r ve yarat r. Problemin sisteme
özgü tek bir(unique) numaras olur. Problemle ilgili
UYD süreci ilerlerken her süreçte anlat lan i iste i ile
ili kilendirmenin yerine problem ile ili kilendirilme
al r. Problemi projeye ba lamak zordur, çünkü
herhangi bir projenin herhangi bir zaman nda yap lan
yeni sürümünden kaynaklan yor olabilir. Bundan
dolay proje ile ili kilendirme zorunlu bir seçenek
olarak görülmeyip, ili kili proje net olarak bilindi i
takdirde ili kilendirilmesi daha do ru olur.
3.10.2.
bilgiler
Entegrasyon
ve
Metrikler
için
gerekli
Problem numaras i iste i gibi UYD içinde ula r
durumdad r ve yaz msal bir de ikli e neden
oluyorsa,
de ikli in
kayna
olarak
aretlenmektedir.
Problemin numaras , aç klamas , tarihi, uygulama
kategorisi, tarihçesi, statüsü vb bilgiler kay t alt na
al nmas yaz m-problem ili kisi ile ilgili metrik
raporlar n al nmas sa lamaktad r.
3.11.
Yaz m Konfigürasyon Yönetimi
Yaz m
Konfigürasyon
yönetimi
disiplininin
sorumlulu u “Yaz m projelerindeki de imi en iyi
biçimde ele al p, yöneten“ olarak tan mlanmaktad r.[7]
UYD yönetiminde yaz m konfigürasyonlar n
yönetimini yaparken sadece kodlar n de il tüm süreçler
içerisinde yer alan parçalar n ve ç kt lar n
de ikliklerinin yönetilmesi önemlidir.
Bu nedenle bu k m a
da üç ayr ba k alt nda ele
al nm r.
3.11.1.
Varl k
Yönetimi
Kütüphanesi(Asset
management)
UYD yer alan tüm tan mlar n(proje, kod bile eni, s f,
metot, servis, sorgu mesaj, ekran, ekran etiketleri,
rapor, parametrik tan mlar vb ) yap ld
bir
kütüphanedir. Bu türden bilgiler veri taban na bir
uygulama arac
yla kaydedilmektedir. Bu sayede
tüm parçalar UYD süreçleri içerisinde ula labilir
olmakta ve tek kaynaktan yönetilebilmektedir.
Sistemin sa kl yürümesi aç ndan kritiktir.
3.11.2.
Kaynak
Yönetimi
Kütüphanesi(Source
Reposit oy)
Kaynak kütüphanesinde UYD süreci s ras nda ve
sonunda ortaya ç kan tüm parçalar saklan r.
Herhangi bir parçada yap lan herhangi bir de iklik,
versiyonlanarak saklanmal ve de ikli i yapan,
zaman ve sebebi gibi bilgileri kaydedebilmelidir.
Buna ek olarak bu arac n varl k kütüphanesi ve di er
UYD süreçlerinde yer alan araçlarla entegre olmas
sistemin iyi entegrasyonu için artt r. Güvenilir, h zl
ve kullan
n yetkisine dayanan kontrollerle
kullan lar n kütüphanede yer alan parçalara ula mas
da önemlidir.
3.11.3.
UYD Yönetim arac
UYD’nin her bir sürecinde yer alan kullan lar, sahip
olduklar roller, yetkiler vb.. sistemi yönetmeye yönelik
tan mlar n, her süreçte farkl araçlarda yap lmas
sistemin yönetilmesinde birçok problemi beraberinde
getirir. Bu nedenle merkezi bir yönetim arac n
olmas ve di er tüm süreçlerdeki araçlarla entegre
olmas sistemi yönetmeyi kolayla
r.
Tüm UYD sürecini yönetmek ve her bir süreci de kendi
içinde yönetebilmek için süreçler UYD arac nda i
ak lar (Workflow) olarak dinamik olarak tan mlan p
üretime al nmakta ve sistemi dinamik olarak yönetmek
çok h zl olmaktad r.
ekil 3: Entegre Uygulama Ya am Döngüsü
4. Sonuç
UYD’ nün iyi yönetilmesi, CMMI gibi olgunluk
modelleriyle ölçümlendirilmektedir. UYD’nin kaos
ortam nda olmas yaz
n i üzerindeki etkisi nedeni
ile finansal zararlara da neden olabilmekte, piyasadaki
rsatlar n da kaç lmas
getirebilmektedir.[8]
Verimli çal an bir UYD, teoride kurallar ve
prosedürlerle yönetilebilir görünmesine ra men,
UYD’nin kendisinin de esnek, h zl ve verimli olmas
için araçlarla desteklenmi , süreçlerin birbirleriyle
entegrasyonu sa lanm olmas her geçen gün daha
önemli olmakta ve fark edilmektedir.
Ayr ca sürecin sürekli olarak izlenmesi, gerekli
metriklerin toplanmas ve elde edilen sonuçlara göre
sürecin ve toplanan metriklerin tekrar gözden geçirilip
düzenlenmesi gerekmektedir.
IBTECH’te on y k sürede, her bir süreç ad
n
düzenlenmesi için çe itli ad mlar at lm , süreçler aras
entegrasyonun önemi UYD içinde yer alan ekiplerin
geri bildirimleri ile zaman içinde kazan lm ,
endüstrinin bu yönde giden e ilimi de incelenerek
gerek piyasada bulunan araçlarla gerekse içeride
yaz lan uygulamalarla bu entegrasyon peki tirilip,
kalitenin, kalite ekibinin sorumlulu unda de il,
herkesin ve sistemin kontrolünde oldu u bir yap
kurulmu tur.
5. Te ekkür
YKGS 2010 organizasyon komitesine bu sunumu
haz rlamam za ve deneyimlerimizi aktarmam za f rsat
verdi i için te ekkür ederiz. IBTECH yöneticilerine ve
çal anlar na geri bildirimleri ve aç k fikirleriyle,
böylesi bir yap n çok konu ulmad zamanlarda dahi
verdikleri destekleri için te ekkür ederiz.
6. Kaynaklar
[1] Öncü, S. ve Akta , R., ”Yeniden Yap land rma
Döneminde Türk Bankac k Sektöründe Verimlilik
De imi”, Celal Bayar Üniversitesi .B.F. MAN SA.,
Yönetim ve Ekonomi 14/1 (2007) 247-266.
[2] Dave West and Jeffrey S. Hammond. "The Forrester
Wave™: agile Development Management Tools Q2
2010 for Application Development & Delivery
Professionals", May 5, 2010.
[3] http://www.scrumalliance.org/pages/what_is_scrum
[4] International Institute of Business Analysis (IIBA), “A
Guide to the Business Analysis Body of Knowledge
(BABOK Guide)”, Version 2.0, 2009.
[5] International Software Testing Qualifications Board
(ISTQB), “Certified Tester Foundation Level
Syllabus”, Version 2007.
[6] http://wiki.en.itprocessmaps.com/index.php/Problem_Management.
[7] IEEE,
“Guide
to
Software
Configuration
Management”, IEEE Std. 1042-1987.
[8] CMMI Product Team, SEI, “CMMI® for
Development”, Version 1.2, August 2006.