Uygulama Geli tirmede Verimlilik için Entegre Uygulama Ya am Döngüsü Yönetimi ve Dinamik Kalite Kontrolü

Transkript

1 Uygulama Gelitirmede Verimlilik için Entegre Uygulama Yaam 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, TUBTAK Yerlekesi, Gebze/Kocaeli Özet Uygulama kullanlarn (iç ve d müterilerin) memnuniyetini üst düzeyde tutmak için isteklerini hedef sürelerinde ve maliyetlerinde, gereksinimler dorultusunda ve olabildiince az hatal olarak gerçekletirmek yazm ekiplerinin temel hedeflerindendir. Uygulama gelitirme sürecinin sistematik bir yaklamla ele alnmas, yönetilebilir bir proje ve yazm 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. Yazm süreç ve proje yönetimi konusundaki teknoloji, süreç, araç, yaklam ve metodolojilerin incelenip, yazm gelitiren organizasyonun ihtiyaçlar ve kültürü dorultusunda özümsenip, dinamik olarak düzenlenebilen ve süreçler aras n baarld bir Uygulama Yaam Döngüsü Yönetim(UYDY) Sisteminin hazrlanmas ve uygulanmas bu hedefleri gerçekletirmede kritik öneme sahiptir. Bunun yan sra, yazm süreçlerinin her aamasnda sistematik bir ekilde hedefe uygun metriklerin toplanp, sürekli olarak süreci daha verimli klacak ekilde izlenmesi UYD nün kalitesini arttracaktr. Yönetilebilir, ölçülebilir ve izlenir bir yazm süreci COBIT, BDDK, SOX, CMMI gibi bankack ve BT sektörüne yönelik denetim ve sertifikasyonlarla, iç denetimlerin daha yönetilir olmas da salamaktadr. 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 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 iletmelerin gittikçe artan oranda odakland konularn banda gelmektedir. süreçlerinin tanmlanmas, düzenlenmesi ve yeniden yaplanmas tüm i kollarnda görülmektedir. Türk bankack sektöründe de bu yönde son 30 ylda hemen tüm bankalarda ciddi çalmalar yaplm ve teknolojinin geliimine paralel olarak i süreçleri ve verimlilik sorgulanr olmu ve verimliliini arttlmas yönünde birçok çalma yaplmr. [1] Öte yandan teknoloji kullan ve teknolojiye dayal ürün gelitirme finansal araçlarn da vazgeçilmez bir parças haline gelmitir. Finans sektöründeki herhangi bir ürünün, rekabette öne geçmeyi hedefleyen bir pazarlama stratejisinin içinde teknoloji ve yazm olmaksn kullanlmas imkansz gibidir. Yazm teknolojileri sadece operasyonel verimlilii arttp,

2 sürekli tekrar eden iler hzlandrarak maliyetleri düürmekle kalmayp, doru ve hzl ekilde ürün gelitirilmesiyle pazarlamann da bir parças olmu ve letmeyi bir adm öne geçirmede etkili olacak bir faktör olmutur. Uygulama kullanlarn veya sahiplerinin isteklerinin toplanp, projelendirilip, hedef sürelerinde ve maliyetlerinde, gereksinimler dorultusunda ve doru çalr bir biçimde gerçekletirmek için uygulama gelitirme sürecinin sistematik bir yaklamla ele alnmas yazm organizasyonlar için kaçlmaz olmutur. Dier birçok bilim ve teknolojik alana göre henüz daha genç olan yazm dünyasnda da uygulama yaam döngüsü yönetimi, proje yönetimi gibi kavramlar son llarda daha sistematik biçimde ele alnm bu konu yazm endüstrisinde bir dal olmu ve bu konuda birçok teknoloji firmas ürünler gelitirmitir. [2] Çeitli proje yönetim metotlarelale, Spiral, RUP, Agile vb.) ve CMMI, SPICE, ISO gibi yazm olgunluk modelleri bu süreci yönetmeye ve iyiletirmeye yönelik olarak ortaya çkan modellerden öne çkanlardr. Burada anlatlan entegre UYD, proje yönetim metodolojilerinden ve olgunluk modellerinden bamsz olup, IBTECH te kullanlan yap örneinde, istenen yapn tanmlanp, uyarlanp, kullanlabildii dinamik bir yapr. Araçlarla salanm entegre bir UYD, istenen metriklerin toplanmas salamakta, süreci daha verimli klacak ekilde yönetilmesi için, sistemin izlenerek, metriklerinin karlalarak, i hedefleri dorultusunda sürecin kalitesinin arttlmasnda da faydal olmaktadr. IBTECH içinde yer alan uygulama yaam döngüsü yönetimi, yazm endüstrisinde gelien eilimler dorultusunda, yukardaki hedefleri karlamaya yönelik olarak dinamik biçimde düzenlenmektedir. Bu dinamizmi salamak için de sürecin sadece prosedürlerle yönetilmesi yerine entegre bir üretim hatt kurulmutur. Mevcut baz araçlarn kullanlmasn yan sra iç kaynaklarla gelitirilen yazmlarla, yazm gelitirme süreci seçilen proje metodolojisi dorultusunda birbirini takip eden süreç admlarna dönütürülerek takip edilmektedir. Bu dokümanda IBTECH te kullanlan yazm süreçleri, her süreç sonunda ortaya çkan çktlar, süreci salamak için gerekli araçlarn özelliklerini ve ölçümlenen metrik kriterleri anlatlacaktr. 2. Uygulama Yaam Döngüsü Rolleri Uygulama yaam 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 sorumluluu net olarak tarif etmeye çalmaktadr. Örnein popülerlii son yllarda artan Çevik yöntemlerden Scrum rollerini net olarak belirlemitir. [3] IBTECH içerisinde de yazm süreci içerisinde yer alan önemli roller ada tanmlanmr. Organizasyonlarda uygulanan metodoloji ve organizasyon yapna göre farkl roller olabilir. Entegre UYDY farkl rolleri tanmlayp, yetki ve sorumluklar tanmlayarak, yönetebiliyor olmalr. birimi sorumlusu Portföy Yöneticisi Proje Yöneticisi Analisti Yazm Mimar Yazm Gelitirici Fonksiyonel Testçi Sürüm Yöneticisi Yazm Konfigürasyon Yöneticisi 3. Entegre Uygulama Yaam Döngüsü Yönetimi UYDY farkl organizasyonlarda farkl biçimde düünülebilir. Burada UYDY süreçleri ve kapsam için daki süreç admlar detaylandlmr. steklerinin Toplanmas steklerinin projelendirilmesi ve planlanmas Gereksinimlerin toplanmas ve yönetilmesi Analizi Uygulama Tasar Yazm Gelitirme Yazm yaplandrma ve sürümün hazrlanmas Test Yönetimi Uygulamann gerçek ortama alnmas Problem Yönetimi Yazm Konfigürasyon Yönetimi Tüm bu süreç admlar tek platformda yönetebilir duruma getirmek sistemin yönetilebilirliini kolaylarmakta ve istenen metriklere de her açdan ulalmas salamaktadr. Ancak sürekli gelien teknoloji ve yazm dünyasnda zaman içinde çkan ihtiyaçlar dorultusunda organizasyonlar farkl zamanlarda, farkl kiilerce deerlendirilip satn alnan, sürecin sadece bir veya birkaç yönetmeye yarayan araçlar kullanmakta, bu da tüm süreci yöneten birçok aracn organizasyon içinde yer almas getirmektedir. Çou zamanda bir sürecin birden fazla araç içerisinde

3 yer almasyla araç seçimi ve kark ve yetersiz olmaktadr. Tüm bu nedenlerden dolay yukarda ad geçen tüm süreçleri entegre etmek ve yönetilebilir bir sistem kurmak kritik olmakta, bunu salamak için de bütünsel bir yaklam gözetip her admda izlenmesi istenen kriterlerin organizasyon tarafndan net olarak ifade edilmesi gerekmektedir. da her süreç ad, IBTECH içindeki yaklak 10 la varlan çalmalar sonucunda elde edilen deneyimler ve bu konudaki eilimler takip edilerek, detaylandlmr. Süreçler, birbirleriyle etkileim içindedirler ve UYD içinde birbirleriyle iç içe, geçili, paralel veya dier bir süreci bekleyerek yaamaktadrlar. Buradaki ayrrma; sadece süreçleri anlatm ve çktlar net olarak ifade içindir. Birimi Sorumlusu Porttföy/Proje Yönetcisi Analisti steklerinin Toplanmas steklerinin projelendirilmesi ve planlanmas Gereksinimlerin toplanmas ve yönetilmesi Analizi 3.1. isteklerinin toplanmas birimlerinin mevcut sistemde bir deiklik, iyiletirme veya tamamen yeni bir i isteinde bulunmas durumunda bu isteini Bilgi Teknolojisi(BT) birimlerine iletmesi için bir yap kurulmutur. Web ortamnda çalan bir i ak (Workflow) uygulamayla da tüm i istekleri izlenebilmekte, hangi statü de olduu her an gözlenebilmektedir. Bu sayede isteklerin tasnifi, takibi kolaylkla yaplabilmektedir. Talepleri i biriminin süzgecinden geçirmek amacyla her birimde, birimin seçtii bir BT Temsilcisi (Genellikle yönetici) belirlenmitir. Her i istei sistemde tanmlandnda tek(unique) bir numara alr ve girilen tarih ve girii yapan kullan kaydedilir. istei öncelikle i birimi temsilcisinin deerlendirmesinden geçip, ondan sonraya BT ye aktarr. Burada beklenen i biriminin bu talebi kendi içinde detayl deerlendirmesi, fayda maliyet analizini yapmas ve ilgili ekiplerle ve BT portföy yöneticileri ile de bilgi al verii yapp talebi BT ye yönlendirmesidir. BT de her i biriminin i isteklerini deerlendiren ve i birimiyle sürekli etkileim içinde olan Portföy Yöneticileri atanmr. istekleri öncelikle uygulamayla ilikili portföy yöneticisi onayna düer. Portföy yöneticisi eksik, anlalmaz bulduu talepleri talebi girene geri gönderebilir veya kabul eder. Sistem her aamada ilgili kiilere ile bilgilendirme yapar. Uygulama Mimar Yazm Gelitirici Analisti Birimi Sorumlusu UYDY Araçlar Uygulama Tasar Proje Yönetim Arac Varlk Kütüphanesi Kaynak Kütüphanesi Yazm Gelitirme Yazm yaplandrma ve sürümün hazrlanmas Test Yönetimi Uygulamann gerçek ortama alnmas Problem Yönetimi ekil 1: Uygulama Yaam Döngüsü Süreç Çktlar ve dier süreçlerle Süreç sonunda sistemde özel, tek(unique) bir koda sahip, giri yapldnda veya onaylandnda girilen her tür bilgisi saklanan bir kayt yaratlm olur. Sürecin dier süreçlerle talep kodu (demand code) üzerinden yapr Entegrasyon ve Metrikler için gerekli isteini talep eden kii ve onaylayan temsilci, istein ilikili olduu uygulamay, önceliini, bitirilmesi beklenen tarihi, ilikili olabilecek dier ekipleri, talebin detayl açklamas ve faydalar tanmlar. Tüm saklanp, dier sistemlerle entegre olduunda daki gibi baz örnek metrik raporlar ve birçok kombinasyonuna ulalabilir. isteklerinin talebe dönütüünde tahmin edilen süresi ve gerçekletiririm süresi. kategorisi baznda i istekleri ve aylk tamamlanma raporu. Birim baznda istenen/tamamlanan belirli periyottaki i istekleri.

4 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 barndrmakta ve i birimlerle iletiimin ve planlamann balangç aamas olarak doru sonuca ulamak için kritik bir aama olmaktadr. Bu süreçte yer alan alt süreçler Proje Yönetimi, Deiklik Yönetimi ve Efor Tahminieklinde sralanabilir. birimlerinden gelen talepler BT de portföy yöneticileri tarafndan karlanr. Portföy yöneticisi talebi ilgili i analisti ve yazm mimar ile paylar. Ön analiz yapr. in kapsam, boyutu ve maliyeti tahmin edilmeye çalr. Daha önce bildirilen benzer talepler ve projeler incelenir. Yürüyen bir proje kapsamnda deiklik olup olmad incelenir. Benzer talepler varsa birletirilip deerlendirmeye alnarak veya farl yanlar varsa parçalanarak deiklikler yönetilmektedir. Organizasyon içinde maliyeti etkileyen girdi parametrelerinin netletirilmesi(tecrübe, anket vb.) ve tahmin srasnda ilgili kiilerce bu girdiler dorultusunda tahmin yapan bir sistem kurmak, tahminde doruluu arttr. Maliyet tahmini yaprken metodolojik yaklamak ve örenen bir sistem kurmak, kiisel tecrübenin kullanlmas yannda, elde edilen sonuçlarn sistematik olarak saklanmas, tahminde sürekli iyilemeyi getirir. IBTECH içerisinde proje sonunda beklenen uygulama çktlarn lineer olarak gerektirdii efor tahmin sistemi uzun zaman kullanlm, imdilerde örenen algoritmalarla ve gerçekletirimin sürekli olarak sistemdeki veriyi besledii bir yapya Boaziçi üniversitesinden Softlab ile beraber geçilmeye çallmaktadr. Efor tahmini sonucunda farkl büyüklükteki i isteklerine farkl yaklamak önemlidir. Her i isteini ayn ekilde planlamak, ayn proje metodolojisiyle yönetmek gerçekletirimde ntlara sebep olabilir. Bu nedenle talep için gereksinim duyulan eforla ilikili olarak projeler kategorize edilmektedir. IBTECH te 15 adam i gününe kadar olan iler Talep, adam gün sürenler Küçük Proje, 40 adam günden uzun süren projeler Büyük Proje olarak adlandlmaktadr. Bunun dnda i kolunun ve istein durumuna göre bu projeler için farkl alt kategoriler de belirlenmektedir. Projenin tipine, kategorisine göre ihtiyaç duyulan süreçler ve çktlar farklk göstermektedir. Tüm projelerde ayn proje yönetim biçimini uygulamak ve ayn sürecin izlenmesini beklemek pratikte ntlar yaatmaktadr. Bu nedenle farkl tipte projeler için süreç aklar tanmlanm ve projelerin bu süreçleri içerecek ekilde ilerlemesi ve çktlar üretmesi beklenmektedir. Mevcut proje tiplerinin yeni bir projeye uymamas durumunda yeni bir proje süreci oluturulmaktadr. Projeler için proje yöneticisi ve ekibi belirlenir, lgili BT ekibinin kaynak yöneticileri kaynak durumlarna ve elemanlarn uzmanlamasna göre projede çalacak ekip elemanlar belirler. Proje tanmlanr ve plan yapr, kaynaklar ilgili görevlere atanr ve proje balatr. Küçük projelerin gerçekletirimini portföy yöneticileri, kaynak yöneticileri ile takip eder. birimi baznda yaratlan bir proje altnda, küçük projeler olarak takibi yapr. Her bir küçük projenin izlemesi gereken bir yaam döngüsü vardr. Talepler(ksa süren i istekleri) daha hzl bir biçimde ele alr. birimlerine paralel bir organizasyonla kurulan yazm kaynak yöneticileri; taleplerin gerçekletirimini yapar. Her bir talebin izlemesi gereken bir yaam döngüsü vardr Süreç Çktlar ve dier süreçlerle Proje tan proje yönetim aracna tanmlanr ve özgün, tek(unique) proje kodu oluturulur. Projede yaplacak ve bir önceki süreçte anlatlan i istekleri ile proje ilikilendirilir. Entegre bir UYD için bu ilikinin kurulmas önemlidir. Projenin hangi uygulama süreç yönetim tipinde yönetilecei tanmlanr ve her süreç ad için ihtiyaç duyulan roldeki kiiler atanr. Proje tanm, amaç ve ekibinin olduu tanm doküman oluturulur. Görevlerin hiyerarik olarak tanmland ve kaynaklarn atand Proje plan hazrlanr. Proje planndaki her bir görevin tek kiiye verilecek ekilde parçalanmas ve sonrasnda bu görevlerin proje yönetim aracnda tanmlanmas önemlidir. Bu olduu takdirde görevlerin(task) durumu, projede çalan yazm gelitiricisi ve dier ekip görevlilerince çalma annda güncellenebilir. Proje yönetimi srasnda dier birçok çkt organizasyonun ihtiyacna, proje yönetim metodolojisine, projenin UYD tipine göre belirlenebilir. (Proje kapsam doküman, Risk doküman vb.) Entegrasyon ve Metrikler için gerekli

5 Alt süreçler baznda toplanacak adaki projenin sonunda birçok metrik bilgisini ulalmas salayacaktr. Deiklik Yönetimi isteinin deim tarihçesi, statüsü, deen konular, yeni eklenenler, çkanlar, isteyen kii ve tarih gibi i içermektedir. Efor Tahmini isteinin tahmin edilmesinde kullanlan girdiler ve UYD her bir süreç için tahmin edilen adam/gün maliyeti saklanmalr. Proje sonunda gerçekleen deerler ile tahmin edilen deerler eletirilmelidir. Proje Yönetimi Projedeki görevler; kii ve süreç tipi baznda kategorize edilmeli, tahmini ve gerçekleme süreleri saklanmalr. UYD içindeki her bir süreçteki parçalar(artifact); proje ve/veya projedeki görev ile ilikilendirildii takdirde, proje baznda tüm süreç admlar ile ilgili çok detayl metrikler toplamak mümkün olmaktadr. Tüm süreç temelde, i istei ve proje emsiyesi altnda takip edilmektedir Gereksinimlerin toplanmas ve yönetilmesi biriminin ilettii steklerin detaylandlmas bu amada yaplmaktadr. birimleriyle ilgili i analistleri gerçek gereksinimleri netletirir. birimleriyle istenen i isteinin detaylandlmas amacyla sürekli iletiim içinde olmak, toplantlar yapmak, yönlendirmek ve istenenleri teyit etmek bu aamada kritiktir. stein Fonksiyonel, teknik, kanuni, görsel tüm gereksinimleri, ktlar, kurallar bu aamada i birimlerinden toparlanr ve i(kullan) gereksinimi olarak kaydedilir. [4] analisti yazm mimar ile de görüerek i gereksinimlerini sistemdeki çözümüyle ilikili 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 arasnda izlenebilirlik kurmak önemlidir. Çözüm gereksinimleri yaratlma sebebi olan gereksinimi ile ilikilendirilir. Bu aamada i birimlerinden gereksinimlere yönelik deiklik talepleri sürekli gelebilir. Yeni talepleri eskilerle etkileimini göz önüne alp, harmanlayarak ilikilendirmek önemlidir. Gereksinim yönetim arac kullanarak gereksinimleri ve ilikileri tanmlamak bu süreci kolaylkla yönetmek ve dier süreç admlarlaryla entegre etmek için önemlidir Süreç Çktlar ve dier süreçlerle Gereksinimler proje baznda tanmlanr. gereksinimleri ve Çözüm gereksinimleri eklinde ayr veya birleik bir doküman çkar. Gereksinim aracn; proje yönetimi srasnda tanmlanan projeyi tanyarak, girilerin yaplabilmesine olanak salamas, kolaylar. gereksinimlerini, yaratlma sebebi olan i isteine, sistemsel olarak balamak entegrasyon açndan önemlidir Entegrasyon ve Metrikler için gerekli Gereksinimlerin ait olduu proje bilgisi, tarihçesi (deim, tarih ve yazan bilgisi) tutulmas önemlidir. istei-i gereksinimi-çözüm gereksinimi ilikisinin tutulmas, sürecin takibini kolaylar. Daha sonradan i gereksinimi-test plan-bulgu ilikisi ve çözüm gereksinimi-analiz-tasarm parçalar ilikileri kurulduunda tüm süreç izlenir duruma gelebilmektedir Analizi analizi ve gereksinimlerin toplanp yönetilmesi süreçleri; birbiriyle iç içe geçen süreçlerdir. Bu süreçte toplanan gereksinimler dorultusunda ve yazm mimarlaryla görüülerek gereksinimin ihtiyaç duyduu çözümler modellenir, detayl olarak yazr, somutlar. Öncelikle sistemin genel görünümü ve ileyii modellenip ksaca anlatr. Analiz dokümann ilk bakta görülecek bu km sistem genel olarak anlamak ve ileyii kavramak açndan önemlidir. Detay ksmnda her bir gereksinimin kar olan çözüm netletirilir. Ekran, rapor vb. kullan ilikisi olan ara yüzler belirlenir ve ileyiin nasl olaca (Hesaplamalar, onaylar, muhasebesel lemler vb.) detayl olarak yazr. Bu aamada modelleme sistemin anlarl arttrmaktadr. UML ile modelleme genel bir standart olmakla beraber, temelde önemli olan sistemi açklay net modellerin olmasr. IBTECH içinde Nesneye Yönelik (Object Oriented- OO) programlama dilleri (Java, C#) akl olarak kullanlmakta olduundan OO Modelleme teknikleri de ksmen kullanlmr. analizi modelinden uygulama tasarm modeli ve sonrasnda da kod iskeletlerinin üretilmesi, tam entegrasyon için çok yararlr. Ancak bu yaklam 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 paylalmaktadr. Bu

6 lem öncesi analizin içerik ve standartlara uygunluk açndan i analizi ekibi içindeki yetkin kiilerce kontrol edilmesi kaliteyi arttrmaktadr. Küçük proje ve taleplerde talebin/projenin boyutuna göre burada yaplacak analiz çalmalar sadeletirilebilir Süreç Çktlar ve dier süreçlerle Çözüme yönelik modellerden ve açklamalar ile gereksinimleri de içeren i analizi doküman oluur. analizinin deerlendirilip, gözden geçirilip, farkl kriterlerle puanland gözden geçirme formlar oluur. analizi hazrlarken kullanlan aracn gereksinim yönetimi aracyla ayn ortamda olmas veya entegre olmas; i analizindeki çözümü, ilgili gereksinimle ilikilendirmek için önemlidir. analizi dokümann hangi konu baklarndan olutuuna dair bir standart varolup, UYD içinde yer alan dier araçlarla entegre bir araç kullanlarak doldurulmakta ve kaynak kütüphanesi üzerinden tüm tarihçesine ulalabilmektedir Entegrasyon ve Metrikler için gerekli analizi parçalarn(artifact); tanmlanan proje altnda yer almas ve tarihçe, kullan, tarih, kaynaklanan gereksinim ilikisinin saklanmas, sonradan ölçümlenmek istenen metriklere ulalmas kolaylar Uygulama Tasar Uygulama tasar projenin bandan itibaren UYD içinde yer almas i isteklerin dier sistemler üzerindeki etkisi, iin zamanlamas, ne kadar sürecei, nasl çözüm getirilecei konularn netlemesi açndan önemlidir. Öncelikle sistemin genel görünümü ve ileyii tasarm açndan modellenip anlatr. Çözüm alternatifleri listelenir ve uygun çözüm gözden geçirmelerle kararlar. Çözüm birden fazla ekibi etkiliyorsa her ekip kendi bölümünü hazrlar ve projenin mimar ile gözden geçirilerek ortak bir çözüme ular. IBTECH te nesneye yönelik programlama yapldndan Sf(Class) ve Sral(Sequence) diyagramlar UML kullanlarak hazrlanr. Yeni ve deen sflar sf diyagramnda yer alr. Servise yönelik mimari (SOA) kullanld için; deen ve yeni servisler için sral diyagramlar çizilir. Yeni ve deen tablolar içeren veri modeli tasar, birbirileriyle ilikileri ile tanmlanr. Sistemin bütününe etkisi incelenip yan etkiler belirlenir ve tasarm dokümanna yazr. Tablo ve veri dönüümündeki ihtiyaçlar belirlenir. Log, rapor, ön d sistemlerle etkileimi, gün sonu lemlerine etkisi gibi teknik ve bankaca özgü spesifik etkiler detaylca raporlanr. Tasarm dokümanlar üretildikten sonra, içerik ve standartlara uygunluk açndan uygulama mimari ekibi içindeki yetkin kiilerce kontrol edilmesi kaliteyi arttrmaktadr Süreç Çktlar ve dier süreçlerle Çözümün tasarna yönelik genel yap, modeller, açklamalar ve yan etkileri içeren detayl tasarm doküman oluur. Tasarn deerlendirilip, gözden geçirilip, farkl kriterlerle puanland formlar oluur. Tasarm hazrlarken kullanlan aracn i analizi aracyla ayn olmas veya entegre olmas; tasarmdaki modelleri, ilgili gereksinimler ve i analizi parçalaryla ilikilendirmek için önemlidir. Aracn modelleme ve editör ilemlerini beraber yapyor olmas tüm ilemleri tek ortamda hazrlayabilmek ve takibi açndan önemlidir. Tasarm dokümann hangi konu balklarndan olutuuna dair bir standart varolup, bir araçla doldurulmaktadr. Tasarm parçalar, tanmlanan proje altnda yer almakta ve proje baznda tüm tarihçesine kaynak kütüphanesi üzerinden ulalabilmektedir Entegrasyon ve Metrikler için gerekli Tasarm parçalarn tanmlanan proje altnda yer almas ve tarihçesinin kullan, tarih, kaynaklanan gereksinim ilikisinin saklanmas sonradan ölçümlenmek istenen metrikleri kolaylar. Tasarm modelinde modellenen ve tasarlanan parçalarn, varlk kütüphanesindeki tanmlarla (bileen, servis, ekran, rapor vb. ) ilikili olarak yaratlmas, projede yaratlan deikliklerin neler olduu ve adetleri gibi konularda ki e hzlca ulalmas salamaktadr Yazm Gelitirme Yazm gelitirme süreci dier süreçlerden çkan le, istenen, planlanan i isteinin, doru çalr ekilde hazrlanmas aamasr ve kritiktir. Yazm tasar, yaplandrma ve sürüm hazrlanmas ve test süreçleriyle iç içedir. Yazm gelitirme diline özgü standartlar, kurallar ve metrikler belirlenmesi ve yazn bu kurallara uygun yazlmasn kontrolü önemlidir. IBTECH te Java ve C# için yazlm standartlar ve metrikler belirlenip bu kurallara uyum, otomatik

7 olarak araçlarla yaz yapan kii tarafndan da, kontrol eden tarafndan da denetlenmektedir. Yazn ikinci bir kii tarafndan gözden geçirilmesi ve sadece standartlar açndan deil mantksal ve tasarmsal açdan da kontrolü yaplmaktadr. Bu da yazm sürecindeki kaliteyi arttrmaktadr. Yazm gelitiricilerin, gelitirim yapt i koluyla iletiimi, toplantlara katlmas, konuya hakimiyeti yazm kalitesini artr. Yazmla ilgili her tür bileen, ekran, servis, rapor, sorgu gibi gelitirilen parçalar Varlk Kütüphanesine kaydedilir. Bu UYD de yer alan parçalar asarnda iliki kurma ve kullan baznda yetkilendirme açndan çok yararlr. Tüm kodlar sf, paket ve bileen baznda kaynak kütüphanesinde saklanr ve tüm versiyonlarna ulalabilir. Birim testi kodlar hazrlanmas ve uygulanmas ürünün kalitesini arttrmaktadr. Ancak yazm ekiplerince birim testlerinin hazrlanmas önceliklendirmede arkalara düerek istenen verimde yaygnlalamamaktadr Süreç Çktlar ve dier süreçlerle Proje/talep kapsamnda gelitirilen yazn kaynak kodlar ve birim test kodlar bu süreçte üretilmektedir. Kodlarn deerlendirilip, incelendii, farkl kriterlerle puanland gözden geçirme formlar oluur. Kod da deiklik yaparken, deiklik nedeni olan i istei veya problem ile ilikilendirmek, ayrca proje yöneticisinin atad görev ile de ilikilendirmek süreçler aras entegrasyon açndan kritiktir Entegrasyon ve Metrikler için gerekli Yaratlan, detirilen kodun, versiyon bilgisi ile kaynakland proje, yazm gelitirici, tarih, i istei/problem veya test bulgusu ile ilikilendirilmesi birçok metrik raporunu besleyen veriyi salar. Kodlarn, kalitesine yönelik metrik ölçümleri kod kalitesini arttr. IBTECH içinde yazlan Java projelerinin her versiyonu için versiyon tarihi ve kii bilgisi ile adaki kod metrikleri ölçümlenip veri tabannda saklamakta, bu ekilde sürekli olarak kod geliimi izlenip raporlanabilmektedir. Bu metriklerle rlkl olarak kodlarn kompleksliinin ölçümü ve o dorultuda yeniden düzenlenmesi hedeflenmektedir. Sisteme özgü, her bir metrik için ideal hedefler de belirlenmi olup, bu ideale uymayan kodlar, Deploy sisteminde yetkili onayyla üretim ortamna geçebilmektedir. Organizasyonun yazm hedefleriyle ve kulland yazm diliyle ilikili olarak kendi metrik kriterlerini ve ideal rakamlar belirlemesi daha yararlr. Proje Baznda toplanan metrikler Projedeki sf, metot saylar, kod ve yorum(comment) satr saylar, Yorum/Kod sat oran, Maksimum iç ice döngü(max. nesting), Sflardaki ortalama metot say, Sflardaki metotlarn ortalama komplekslii, flardaki ortalama kod ve yorum satr saylar. f Baznda izlenen metrikler Metot say, kod ve yorum satr saylar, yorum/kod sat oran, maksimum iç içe döngü, sftaki metotlarn toplam komplekslii. Metot Baznda izlenen metrikler Metot komplekslii(cyclomatic complexity), Kod ve yorum satr saylar, yorum/kod sat oran, maksimum iç içe döngü Yazm yaplandrma(build) ve sürüm hazrlanmas Yazm yaplandrmas (build) ve yeni sürümün karlmas otomatik olarak yaplmakta, bu ekilde yazm gelitiricilerin bu süreçteki verimlilii artmakta ve daha kolay yeni sürüm çkarp, gerçek ortamda devreye alabilmektedirler. Uygulama diline özgü yaplandrma kodlar bu lemden sorumlu yazm ekibi tarafndan uygulama gelitirme ortamna eklenti bir uygulama olarak hazrlanm ve yazm gelitiricilerin kullanna sunulmutur. Yazm gelitiriciler uygulama gelitirme ortamnda kodlarn çalrlndan emin olduklarnda ilgili menüyü seçerek, uygulamalar bileen baznda yaplandrmakta ve sonucunda çalr(exceutable, binary) kodlar olumaktadr. Çalr kodlar bileen baznda slm dosyaya çevrilerek, kaynak kütüphanesine atp versiyonlanmaktadr. Bu ekilde tüm çalr kodlara da istenildii anda kaynak kütüphanesinden ulalabilmektedir. Birim testler de yaplandrma ardndan koulacak ekilde çallabilir. Bu da detirilen parçann yan sra, etkilenen dier kodlarn da test edilmesinde faydal olur Süreç Çktlar ve dier süreçlerle Çalr kodlar bu süreç sonunda ortaya çkan temel ktr. Yaplandrma sonrasnda birim test kodlar çallmsa, sonuçlar da bu süreçte üretilmi olur. Yaplandrma esnasnda hangi i istei/problem ile ilikili yapld seçmek, çalr kodlarn bir versiyonunun neden yaratld sorgulamada ve uygulamay gerçek ortama almada önem kazanmaktadr.

8 Entegrasyon ve Metrikler için gerekli Yaplandlan ve sürümü çkan kodun, versiyon bilgisi, yapan kii, tarih bilgisi ile kaynakland proje, i istei/problem veya test bulgularn ilikilendirilmesi birçok metrik raporunu besleyen veriyi salar. Birim testleri yaplmsa, ilgili sürüme ait birim test sonuçlarn kaydedilmesi, sürümün birim test sonuçlarn raporlanp, fonksiyon testleri srasnda kan bulgular ve üretim sonras ortaya çkan problemlerle karlarmal raporlar alnmasna olanak salar Test Yönetimi Test yönetimi UYD içinde her süreçte ödevleri olmas gereken bir süreçtir. Bu kmda arlkl olarak fonksiyonel testlerin yönetilmesi detaylandlmasna ramen dier testlerden de bahsedilmektedir. ekil 2: Test Derinlikleri ve Test Çeitleri IBTECH içinde i analizi ve fonksiyonel test i analistlerinin sorumluluundadr. analistleri tüm yazm süreci içerisinde yer aldklarndan test edilecek konuya hakimiyetleri yüksektir. Fonksiyonel, performans, regresyon (onay), yapsal, güvenlik vb tüm test tipleri için test senaryolarn önceden hazrlanmas kritiktir. Bu testler birim, sistem, entegrasyon ve kabul testleri olarak küçükten büyüe doru uygulanmaktadr. [6] deal yaklam gereksinimler toplanrken ve i analizini hazrlarken, paralelde gereksinimler dorultusunda test planlarn(test senaryo ve durumlarn) hazrlanmasr. IBTECH içinde de test senaryolarn hazrlanmas, testlere balanmadan i analizi sürecinin sonundan balayarak yaplmaktadr. Birim testleri yazm gelitiricilerin sorumluluunda olup arlkl fonksiyonel olmasna ramen ihtiyaç duyulan test tipine yönelik olarak yaplabilir. Performans testleri sistem ekipleri tarafndan performans test araçlaryla yaplmaktadr. Güvenlik testleri güvenlik ekibi tarafndan özellikle darya açlan, güvenilirlii önemli web uygulamalar güvenlik araçlaryla ve gözden geçirmelerle kontrol etmektedirler. Test bulgularn çözümünde testi yapan ile bulguyu çözen arasnda bir döngü kurularak bulgu çözülene kadar döngü çevrilir Süreç Çktlar ve dier süreçlerle Bu süreçte test senaryolar, bulgular ve bulgularn çözümüne ait tarihçe oluur. Test planlar ilgili projenin altnda tanmlanmas ve kaynakland gereksinim ile ilikilendirilerek Proje- Gereksinim-Test Durumu ilikisinin kurulmas önemlidir. Test sonuçlarn ve bulgu girilerinin test durumu baznda girilmesi durumunda yukardaki iliki bulgularla da eletirilerek Test durumu-bulgu ilikisi kurulmu olur Entegrasyon ve Metrikler için gerekli Test durumlarn açklamas, baar kriteri, tarihçe, test sonucu, yapan kii, kaynakland proje, gereksinim vb.. i saklanmalr. Bulgunun giren ve çözen kiilerce girilen tüm tarihçesinin kaydedilmesi bulgularla ilgili raporlamalarda yararl olur. Bulgu döngüsünde, bulgunun açklamas, öncelii, sebebi, kritiklii, tarihi, giren kii, statüsü, görüntüsü, kaynakland test durumu, gereksinim, proje vb.. in taraflarca girilmesi ileriye yönelik metrikler toplanmas açndan önemlidir Uygulamann gerçek üretim ortamna alnmas Uygulamalarn gerçek üretim ortamna alnmas birçok UYD aracnda sürecin parças gibi ele alnmas henüz çok yaygn deildir. Bu operasyon için farkl araçlar kullanmak daha yaygndr. Ancak UYD yönetiminin daha sakl olmas için uygulamalarn gelitirme, test, kullan kabul ve üretim ortamlarna atlmas rasnda dier süreçlerdeki ödevleri zorlama ve yönetme açndan yönlendirici olmaktadr. Bu ekilde UYD yönetiminin ve kontrolü prosedürlerle deil, entegre bir i ak sisteminin yürüyen ileyii ile salanmaktadr. Bu ileyile test senaryolar hazrlanmam, bulgular çözülmemi, belirli kod metrikleri tutturmam, içindeki sorgusunun çalma süresi zaman ana taklm kodlarn üretim

9 ortamna alnmamas veya yetkili bir onay sonras üretime alnmas, metrik kontrollü entegre süreç yönetiminin örneklerinden bazlarr. Üretim ortamna alm srasnda atlacak kodlarn büyüklük düzeyi(dosya, paket, proje veya birçok projeden olumas) önemlidir. Uygulamalar çalrken, yeni kodu üretim ortamna almak da kritik bir süreçtir. Bunun için de zl(hot) Deploy mekanizmalar ve dak sistemlere datma çözümleri üretmek gerekmektedir. Ayrca kod aktaryla beraber ilgili kodun paralelinde yaplan tablo, sorgu deiklikleriyle, parametrik tanmlarn, ekran ve raporlarn ayn anda üretime alnmas da bu yap içinde kurulmutur. IBTECH te belirli bir ii yapan kodlar bir Java projesi, bileeni(komponent) altnda toplanm olup, bileen baznda versiyonlanp, yaplandlarak üretim ortamna alnmaktadr. Eski versiyon tekrar üretime atnca da uygulama eski haline geri dönmü olmaktadr. Bu Deploy mekanizmas Gelitirme ve Test ortamna kod aktar için de kullanlmakta olup, kodlarn üretime alrken Gelitirme ve Test ortamlarna gitmesi zorunludur. Büyük proje geçilerinde ve belirli periyotlarda toplu halde bileenlerin üretim ortamna alnabilmesi için sürümler tanmlanmakta ve geçiler bu sürümlerle yürütülmektedir Süreç Çktlar ve dier süreçlerle Bu süreç sonunda uygulamalar üretim ortamna alnm olur. istei/problem, Talep/Proje tamamlanm olarak iaretlenip, kapatr. Üretim ortamna alnma ile ilgili tüm Deploy kaytlar saklanr Entegrasyon ve Metrikler için gerekli Deploy talebi srasnda üretime alnacak bileen versiyonu, talep eden kii, tarih, statü, gidecei sunucular, neden olan proje, i istei/problem, vb.. girilerek Deploy ile nelerin üretime alndna dair sonrasnda takip edilmek üzere kayt altna alnm olur. Ayrca yazm mimarn yapt Deploy istei sistemsel olarak yetkili kiilerin onayndan geçmesi salanp tüm onaylar ve yaplan iler kayt altna alnm olur. Bütün bunlar üretim ortamna yazmclarn elle ulamas engelleyip, kontrollü geçii salamaktadr. Buna ek olarak, herhangi bir zamandaki geçi; geçmie yönelik olarak tüm detaylaryla raporlanabilmektedir Problem Yönetimi ITIL sürecine göre problem sistemde oluan bir veya daha fazla kesinti veya kalitedeki düün neden olduu durumdur.[6] Problemler bu anlamda uygulamann üretim ortamna alnmasndan sonra son kullan tarafndan bildirilen bulgularn bazlarr. Problem yönetim araçlar çounlukla UYD araçlarndan bamsz ve sadece yazm deil tüm BT ürün ve süreçlerini kapsayan bildirimler için kullanlmaktadr. Ancak yazm kaynakl bildirilen problemler nedeni ile UYD çalma balamas sürekli olarak ihtiyaç duyulan bir konudur. O nedenle UYD yönetim araçlarn Problem yönetimini kapsamas veya en azndan entegre olabilmesi sürecin takibinde önemlidir. Kullan tarafnda yaanan bir olayn(incident) bildirilip belirli aamalardan geçtikten sonra yazm problemi olarak nitelendirilmesi ile UYD açndan süreç balar. Bu durumda yukarda anlatlan ve UYD yönetiminde yer alan tüm sürecin veya bir ksmn problemin çözümü için devreye girmesi gerekir. Bu nedenle yukarda anlatlan tüm süreç admlarnda süreci balatan i biriminin isteinin yerini bu durumda problem alr. Bunu yönetebilmek için de UYD yönetim aracn problem yönetim aracyla gereklidir Süreç Çktlar ve dier süreçlerle Problem tanmlanr ve yaratr. Problemin sisteme özgü tek bir(unique) numaras olur. Problemle ilgili UYD süreci ilerlerken her süreçte anlatlan i istei ile ilikilendirmenin yerine problem ile ilikilendirilme alr. Problemi projeye balamak zordur, çünkü herhangi bir projenin herhangi bir zamannda yaplan yeni sürümünden kaynaklanyor olabilir. Bundan dolay proje ile ilikilendirme zorunlu bir seçenek olarak görülmeyip, ilikili proje net olarak bilindii takdirde ilikilendirilmesi daha doru olur Entegrasyon ve Metrikler için gerekli Problem numaras i istei gibi UYD içinde ular durumdadr ve yazmsal bir deiklie neden oluyorsa, deikliin kayna olarak aretlenmektedir. Problemin numaras, açklamas, tarihi, uygulama kategorisi, tarihçesi, statüsü vb kayt altna alnmas yazm-problem ilikisi ile ilgili metrik raporlarn alnmas salamaktadr.

10 3.11. Yazm Konfigürasyon Yönetimi Yazm Konfigürasyon yönetimi disiplininin sorumluluu Yazm projelerindeki deimi en iyi biçimde ele alp, yöneten olarak tanmlanmaktadr.[7] UYD yönetiminde yazm konfigürasyonlarn yönetimini yaparken sadece kodlarn deil tüm süreçler içerisinde yer alan parçalarn ve çktlarn deikliklerinin yönetilmesi önemlidir. Bu nedenle bu km ada üç ayr bak altnda ele alnmr Varlk Kütüphanesi(Asset management) Yönetimi UYD yer alan tüm tanmlarn(proje, kod bileeni, sf, metot, servis, sorgu mesaj, ekran, ekran etiketleri, rapor, parametrik tanmlar vb ) yapld bir kütüphanedir. Bu türden veri tabanna bir uygulama aracyla kaydedilmektedir. Bu sayede tüm parçalar UYD süreçleri içerisinde ulalabilir olmakta ve tek kaynaktan yönetilebilmektedir. Sistemin sakl yürümesi açndan kritiktir Kaynak Kütüphanesi(Source Repositoy) Yönetimi Kaynak kütüphanesinde UYD süreci srasnda ve sonunda ortaya çkan tüm parçalar saklanr. Herhangi bir parçada yaplan herhangi bir deiklik, versiyonlanarak saklanmal ve deiklii yapan, zaman ve sebebi gibi i kaydedebilmelidir. Buna ek olarak bu aracn varlk kütüphanesi ve dier UYD süreçlerinde yer alan araçlarla entegre olmas sistemin iyi için arttr. Güvenilir, hzl ve kullann yetkisine dayanan kontrollerle kullanlarn kütüphanede yer alan parçalara ulamas da önemlidir UYD Yönetim arac UYD nin her bir sürecinde yer alan kullanlar, sahip olduklar roller, yetkiler vb.. sistemi yönetmeye yönelik tanmlarn, her süreçte farkl araçlarda yaplmas sistemin yönetilmesinde birçok problemi beraberinde getirir. Bu nedenle merkezi bir yönetim aracn olmas ve dier tüm süreçlerdeki araçlarla entegre olmas sistemi yönetmeyi kolaylar. Tüm UYD sürecini yönetmek ve her bir süreci de kendi içinde yönetebilmek için süreçler UYD aracnda i aklar(workflow) olarak dinamik olarak tanmlanp üretime alnmakta ve sistemi dinamik olarak yönetmek çok hzl olmaktadr. 4. Sonuç ekil 3: Entegre Uygulama Yaam Döngüsü UYD nün iyi yönetilmesi, CMMI gibi olgunluk modelleriyle ölçümlendirilmektedir. UYD nin kaos ortamnda olmas yazn i üzerindeki etkisi nedeni ile finansal zararlara da neden olabilmekte, piyasadaki rsatlarn da kaçlmas getirebilmektedir.[8] Verimli çalan bir UYD, teoride kurallar ve prosedürlerle yönetilebilir görünmesine ramen, UYD nin kendisinin de esnek, hzl ve verimli olmas için araçlarla desteklenmi, süreçlerin birbirleriyle salanm olmas her geçen gün daha önemli olmakta ve fark edilmektedir. Ayrca 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 yk sürede, her bir süreç adn düzenlenmesi için çeitli admlar atlm, süreçler aras n önemi UYD içinde yer alan ekiplerin geri bildirimleri ile zaman içinde kazanlm, endüstrinin bu yönde giden eilimi de incelenerek gerek piyasada bulunan araçlarla gerekse içeride yazlan uygulamalarla bu entegrasyon pekitirilip, kalitenin, kalite ekibinin sorumluluunda deil, herkesin ve sistemin kontrolünde olduu bir yap kurulmutur. 5. Teekkür YKGS 2010 organizasyon komitesine bu sunumu hazrlamamza ve deneyimlerimizi aktarmamza frsat

11 verdii için teekkür ederiz. IBTECH yöneticilerine ve çalanlarna geri bildirimleri ve açk fikirleriyle, böylesi bir yapn çok konuulmad zamanlarda dahi verdikleri destekleri için teekkür ederiz. 6. Kaynaklar [1] Öncü, S. ve Akta, R., Yeniden Yaplandrma Döneminde Türk Bankack Sektöründe Verimlilik Deimi, Celal Bayar Üniversitesi.B.F. MANSA., Yönetim ve Ekonomi 14/1 (2007) [2] Dave West and Jeffrey S. Hammond. "The Forrester Wave : agile Development Management Tools Q for Application Development & Delivery Professionals", May 5, [3] [4] International Institute of Business Analysis (IIBA), A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0, [5] International Software Testing Qualifications Board (ISTQB), Certified Tester Foundation Level Syllabus, Version [6] [7] IEEE, Guide to Software Configuration Management, IEEE Std [8] CMMI Product Team, SEI, CMMI for Development, Version 1.2, August 2006.