Uygulama Geliştirmede Verimlilik için Entegre Uygulama Yaşam
advertisement
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 [email protected] Ö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.