Corafi Daıtık Yazılım Gelitirme Ortamında Yazılım Konfigürasyon Yönetimi Hayrullah KALE 1 R. Bülent GÖKALP 2 1,2 Barı Kartalı Projesi, HAVELSAN A.. ANKARA 1 e-posta: hkale@havelsan.com.tr 2 e-posta: bgokalp@havelsan.com.tr Özet Günümüz i dünyasında yazılım gelitirme ortamlarının daha esnek olması zorunluluk haline gelmitir. Corafi olarak birbirinden uzak grupların birlikte yazılım gelitirmeleri bunun bir örneidir. Bu bildiride yazılım konfigürasyon yönetimininin corafi daıtık yazılım gelitirmeyi nasıl desteklemesi gerektii, Barı Kartalı Projesi nde edinilen tecrübeler ııında, sunulmaktadır. Abstract The complexity of today s enterprise software development requires a flexible approach for the development environment. The need of close cooperation among geographically distributed sites during the development is an example to this requirement. In this paper, we will show how the software configuration management should support a distributed software development environment using the experience gained during the Peace Eagle Project. 1. Giri HAVELSAN, BARI KARTALI (BK) Havadan Erken hbar Komuta ve Kontrol Uçaı nın temininde, Görev Yazılımları ve Yer Destek Sistemleri konusunda, yerli alt yüklenici sorumluluunu üstlenmitir. HAVELSAN, uçak ve yer destek sistemleri için gelitirilecek Türk Hava Kuvvetleri ne özel yazılımların gelitirilmesinde, modifikasyonunda ve entegrasyonunda görev aldıı gibi, aynı zamanda bu yazılımların testini ve BOEING tarafından temin edilen 737 AEW&C ana sistem yazılımına entegrasyonunu da gerçekletirecektir. HAVELSAN sistem çözümleme sürecinden balayarak test ve deerlendirmeye kadar projenin tüm mühendislik süreçlerinde yer almaktadır. HAVELSAN, proje kapsamında toplam olarak yaklaık 200.000 satır kaynak kod boyutunda, 12 yazılım modülünü (yazılım parçacıı) gelitirmi/modifiye etmi olacaktır. Görev bilgisayarı yazılımı kapsamında BOEING in ve HAVELSAN ın yazılım gerçekletirme sorumlulukları bulunmaktadır. Bu kapsamda mevcut kod üzerinde iki taraf da modifikasyon
yapmaktadır. Bunun dıında HAVELSAN yazılımın bir kısmını kendisi tasarlayıp gelitirmektedir. BOEING in yazılım ekibi Seattle da, HAVELSAN ın yazılım ekibi ise Ankara da bulunmaktadır. Yukarıda bahsedilenler ııında bakıldıında, BK Projesi yazılım gelitirme faaliyetlerinin etkin bir Yazılım Konfigürasyon Yönetimi ile desteklenmesi gerekmektedir. Aaıdaki paragraflarda bu kapsamda uygulanan model ve süreçlerin bir kısmı anlatılmaktadır. 2. Yazılım Gelitirme 2.1 leyiten Çıkar (Checkout)/ leyie Sok (Checkin) Modeli Genelde sürüm yönetimi araçları leyiten Çıkar-Degitir-leyie Sok modeliyle çalımaktadır. Balangıç durumda dosya çalıma alanında salt okunabilir halde bulunur. Gelitirici bir dosyada deiiklik yapmak isterse o dosyayı ileyiten çıkarır, bu durumda dosya çalıma alanında yazılabilir hale gelir. Deiiklikler yapıldıktan sonra dosya ileyie sokulur. Bu durumda dosyanın yeni bir sürümü oluur[1]. Bu durum ekil 1 de gösterilmektedir. ekil 1. leyiten Çıkar/leyie Sok Modeli BK projesinde Rational ClearCase konfigürasyon yönetim aracı ve Rational ClearQuest deiiklik yönetim araçları tümleik olarak kullanılmaktadır. Bir dosyanın ileyie sokulabilmesi için mutlaka yazılım deiiklik süreci kapsamında onaylanmı bir Yazılım Deiiklik stei (YD) ile ilikilendirilmesi gerekmektedir (bu durum bir betik ile zorunlu hale getirilmitir). Bunun anlamı; Deiiklik yapmak isteniyorsa YD yazıp Yazılım Konfigürasyon Kontrol Kurulu ndan (YKKK) onay almak zorunludur, aksi halde deiiklik yapılamaz. 2.2 Yan Dal Kullanımı ile E Zamanlı Yazılım Gelitirme Bu projede -bazı durumlarda- birden fazla kullanıcının aynı dosya üzerinde aynı anda deiiklik yapması gerekmektedir. Örnein bir grup sonraki daıtım için gerekli kodlama çalımalarını yürütürken baka bir grup daıtımı yapılan sürümdeki hataları gidermek için gerekli kodlama iini yürütmek durumunda kalmaktadır[2]. Bu durum için ekil 2 deki örüntü kullanılmaktadır.
ekil 2. Yan Dal ile E Zamanlı Yazılım Gelitirme 2.3 Corafi Daıtık Yazılım Gelitirme Yazılım Konfigürasyon Yönetimi aracı olarak ClearCase MultiSite kullanılmaktadır. BOEING in sorumlu olduu VOB lar (ClearCase in Veri Tabanı) HAVELSAN a, HAVELSAN ın sorumlu olduu VOB lar ise BOEING e çoklanmıtır. ekil-3 te bu durum gösterilmitir. ekil 3. HAVELSAN ve BOEING arasındaki Corafi Daıtık yapı ki taraf ayrı yan dallar üzerinde çalımaktadır. VOB un sahibi birletirme sorumluluunu yüklenmi durumdadır. Sıklıkla VOB ların elenmesi yapılmaktadır. ekil 4 te corafi daıtık yapıda gelitirme örüntüsü görülmektedir.
ekil 4. Corafi daıtık yapıda gelitirme örüntüsü 3. Yazılım Deiiklik Süreci Proje ekibi ihtiyaç duyduunda yazılımın deitirilmesi için istekte bulunabilir. Bu istek BOEING ya da HAVELSAN ekibinden gelebilir. Bu istekler karı tarafı etkiledii durumda, karı tarafın karar sürecinde bulunması zorunluluu vardır. Bu deiikliklerin belirli bir süreç içerisinde sonuçlandırılması ve izlenebilmesi için ClearQuest Multisite deiiklik yönetim aracı kullanılmaktadır. 3.1 Roller ve Sorumluluklar Yazılım Konfigürasyon Yönetimi Sorumlusu (YKYS), yazılım gelitirme sürecine katkıda bulunan tüm kullanıcılara rol ve sorumluluk atar. Bu rol ve sorumluluklar Tablo 1. deki gibidir.
Tablo 1. Rol ve Sorumluluklar Rol Adı stek Sahibi Teknik Lider Çözümleyici YKKK Üyeleri Test Mühendisi Yazılım Kalite Sorumlusu Yazılım Konfigürasyon Yönetimi Sorumlusu Açıklama YD yi Yazılım Deiiklik Süreci nin tarif ettii ekilde bildiren kii. Ürün ya da Ürün Grubu Sorumlusu olan ve çözümleyiciyi belirleyip atamasını yapan kullanıcı. YD ile ilgili süreç tamamlanıncaya kadar Teknik Liderin takibi ve sorumluluu altındadır. YD için çözümleme yapması istenen teknik sorumlu. Çözümleme sonunda düzeltici faaliyet mutlaka tanımlanmı olmalıdır. YD leri çözümleme sonucunu dikkate alarak deerlendirip nihai kararı veren kuruldur. Bu kurulun asil üyelerinin kimler olacaı Yazılım Konfigürasyon Yönetimi Planı nda (YKYP) yer almalıdır. BK projesinde BOEING temsilcisi kurulun asil üyesidir. Test faaliyetlerini yürütmekten sorumlu kullanıcı. Süreç kapsamında Yazılım Kalite Güvence gereklerinin uygulanmasından sorumlu kullanıcı. Bu süreç kapsamında, YKKK ya idari ve teknik destek verir. ClearQuest in yönetiminden ve raporlamadan sorumludur. 3.2 Öncelik ve Önem Tanımları Deiiklik yönetimi süreci kapsamında kullanılan YD lerin öncelik ve önem tanımları Tablo 2 ve Tablo 3 te verilmitir. Tablo 2. YD Öncelik Tanımları Öncelik 1 Öncelik 2 Öncelik 3 Öncelik 4 Öncelik 5 Bir problem: 1. Bir gereksinimin karılanması engelleniyorsa, 2. Kullanıcının faaliyetini engelliyorsa, 3. Personel güvenliini etkiliyorsa Takip eden ara sürüm daıtımında mutlaka yer almalıdır.örnein daıtım 4.3 te, ana daıtım 4 ara daıtım 3 tür. Bu durumda problem 4.4 te mutlaka giderilmelidir. Bir problem: Baarımı düüren ve ilevsel olarak olumsuz bir etkisi oluyorsa ve çözüm bilinmiyorsa, takip eden ara sürüm daıtımında mutlaka yer almalıdır. Bir problem: Baarımı düüren ve ilevsel olarak olumsuz bir etkisi oluyorsa ve çözüm biliniyorsa, takip eden ana sürüm daıtımında mutlaka yer almalıdır. Örnein daıtım 4.3 te, ana daıtım 4 ara daıtım 3 tür. Bu durumda problem 5.0, 5.1, 5.2 de yer alabilir. levsellik ya da baarım açısından bir sıkıntı yok ancak kullanımı zorlatıran ya da kısıtlayan bir durum ise. Dier tüm problemler.
Tablo 3. YD Önem Tanımları Önem 1 Önem 2 Önem 3 Önem 4 Kritik: Operasyonel ya da görev e ilikin yetenein kullanılması engelleniyorsa. Gerekli: Performansı düürüyor ve operasyonel ya da görev olarak negatif bir etkisi varsa. Sakıncalı: Operasyonel ya da performans açısından bir sıkıntı yok ancak operatöre sıkıntı veren bir durum varsa. Dier 3.3 Yazılım Deiiklik stei YD ClearQuest te bir kayıt tipi olarak bulunur ve Yazılım Konfigürasyon Yönetimi (YKY) kontrolü altında bulunan yazılım ürünlerinin deiikliklerinin yönetilmesi için kullanılır. 3.3.1 YD Süreç Akı Tanımı YD aama modeli, YD nin tüm yaam döngüsünü yansıtan bir modeldir. Bu model 10 aamadan olumaktadır. ekil 5 te YD süreç akıı görülmektedir. ekil 5. YD Süreç Akıı YD nin aama geçii bir aamadan dierine eklinde olmaktadır. Bu aamaların açıklamaları Tablo 4 te verilmitir. Her aama geçiinde ilgili kiilere otomatik olarak e-posta gönderilmektedir.
Tablo 4. YD Akı Tanımları Süreç Adımı: Süreç Tanımı Adım 0 YD Yaratılması Bir YD herhangi bir proje personeli tarafından balatılabilir. Kullanıcı problemi detaylı ekilde girer. Bu bir test sonucu ise, testin seviyesi, altsistem, yazılım ve ilgili dokumanlar da girilmelidir. Ayrıntılar girildikten sonra YD giri tuuna basılarak YD veritabanina Kayıt aamasında kaydedilmi olur. Bununla birlikte Proje yöneticisine ve Teknik liderlere otomatik olarak e-posta gönderilir. Adım 1 Teknik lider YD nin sorumluluk alanına girip girmediine bakar. Kendi sorumluluunda Kayıt ise, Aaıdaki hususları gözeterek YD yi inceler: Problem tanımının yeterli olup olmadıına bakar. Önem seviyesini belirler. Öncelik seviyesini belirler. Daha önceki bir YD ile aynı olup olmadıına bakar. Bunun sonucunda aaıdaki iki karardan birini verir: (1) YD yi Çözümleme aamasına alır ya da (2) YD yi reddeder. Adım 2 Çözümleme Adım 3 YKKK Adım 4 Gerçekleme Adım 5 Dorulama Adım 6 Erteleme Adım 7 Kapatma Adım 8 Çakıma Adım 9 ptal Adım 10 Red Atanmı olan Çözümleyici problem için bir düzeltici faaliyet belirler. Bu kapsamda YD ye dokuman ekleyebilir. Çözümleme sonuçlanınca Teknik lider YD nin aamasını YKKK ya getirir. YKKK YD nin gereinin yapılmasına karar verebilir, bunun dıında çözümlemeyi yeterli bulmayıp ek çözümleme için geri gönderebilir ya da YD yi reddedebilir. Son kararı verme sorumluluu kurul bakanına aittir.dier üyeler bakana yardımcı olmakla yükümlüdürler. YKYS YD yi Gerçekleme aamasına getirir. Teknik Lider bu ii yapması için bir ya da birden fazla kiiyi görevlendirir. Düzeltici faaliyet tamamlandıktan sonra Teknik Lider YD yi Dorulama aamasına getirir. Çözümleyici, test sorumlusu, kalite sorumlusu ve YKYS ninde katıldıı YKKK toplantısında dorulaması yapılan YD ler kapatılmaya hazırdır. Bazı durumlarda (Takvim problemi olmayan, özel test gerektiren v.b.) YD Erteleme aamasında tutulur. Haftalık YKKK toplantılarında bu YD lerde deiiklik gerekip gerekmediine bakılır. Testi ve dorulaması yapılan YD YKKK kararıyla YKYS tarafından Kapatma aamasına getirilir. Teknik lider ya da YKKK YD nin daha önceki bir YD ile aynı olduuna karar vermise bu aamaya getirir. Daha sonra YKKK kararıyla YD ptal aamasına getirilir., YD Teknik Lider tarafından Kayıt aamasından itibaren ptal aamasına getirilebilir. Daha sonra bu YD Red aamasına getirilir. YD içerik olarak,gereksinim olarak ve baka nedenlerle uygun bulunmayabilir bu durumda Red aamasına getirilir.
4. Gecelik na Süreci Görev Bilgisayarı Yazılımı, yazılım bileen parçalarından oluan sektörlere ayrılmıtır, her sektör ClearCase VOB unda ya da VOB larında bulunan belirli dizinlerden meydana gelmektedir. Her sektörün gelitirme takımı baımsız olarak kodlama ve birim testi faaliyetlerini yürütür. Yazılımın tamamının derlenmesi yaklaık 12 saati bulmaktadır. Böyle bir durumda yazılımın tamamını derleyen bir gecelik ina kaçınılmazdır. Bir kaynak dosyanın gecelik inaya girmesi isteniyorsa gelitirici tarafından o dosyanın istenen revizyonuna [BLD]DAILY formatında bir etiket eklenir, burada [BLD] program ina numarasıdır. Gecelik ina bir betik ile balatılır. Bu betik önce tüm [BLD]DAILY etiketi olan revizyonlara DEV[BLD] etiketini ekler. Her gecelik ina baımsız olarak belirli bir ina görünümünde (ClearCase çalıma sahası) yapılır. na Takımı içerisindeki sektör sorumlusu, tümleik ina ya (tüm sektörlerin bir arada derlenmesi) girecek dosyaların revizyonlarına bir betik yardımıyla [SECTOR][BLD] formatında bir label ekler.entegrasyon ina ya balamadan önce tüm [SECTOR][BLD] etiketi olan yerlere NEXT[BLD] etiketini ekler. Entegrasyon ina her çaramba NEXT[BLD] etiketi olan dosyalar kullanılarak yapılır. na sonucunda oluan hatalar sektör sorumluları tarafından deerlendirilir ve gerek görülürse gün içerisinde yeni bir ina yapılır. ekil 6 da ina süreç akıı görülmektedir. ekil 6. Tüm na Akıı ÇAR PER CU PZT SAL ÇAR PER CU PZT SAL ÇAR PER CU PZT SAL Kodu Gelitir 1TDAILY olarak etiketle 1TDAILY -- > DEV1T Her gece DEV1T -- > [SECTOR]1T [SECTOR]1T -- > NEXT1T NEXT1T nin entegrasyon testi KEY Anahtar Developer Gelitirici Gecelik Nightly Build na Build na Takımı Team Key Geçi Transition Noktası Point NEXT leri MCMP yapmak için iaretle NEXT1T -- > MCMP1T MCMP1T Olgun ve Kullanıma hazır
na takımı NEXT ina sının anaçizgi olmasına karar verirse tüm NEXT[BLD] etiketi olan yerlere MCMP[BLD] etiketi eklenir. Her hafta ina görünümleri temizlenir ve yeniden ina yapılır. Gelitirici istedii ina görünümünden istedii derlenmi kısımları kendi çalıma alanına getirir. 5. Sonuç Projenin balangıcında Yazılım Konfigürasyon Yönetimi gereksinimleri belirlenmeli, bu gereksinimleri tam olarak karılayan, uygulanabilir süreçler tanımlanmalı ve bu kapsamda uygun araçlar -Konfigürasyon Yönetimi, Deiiklik Yönetimi vb- belirlenmelidir. Proje personeline süreçler ve araçların kullanımı konularında eitimler verilmelidir. Projeye yeni katılan her personelin bu eitimi alması salanmalıdır. Bu eitimler süreçlerin ve araçların etkin kullanımı için çok önemlidir Proje Yönetimi tarafından uygulamanın takibi ciddiyetle yapılmalıdır. Süreçler sürekli iyiletirmeye açık olmalıdır. Yukarıda bahsedilen model ve süreçler, bu prensipler ııında Barı Kartalı Projesinde baarı ile uygulanmaktadır. Yazılımın ilk daıtımı baarıyla yapılmı olup, u anda 2. daıtım için çalımalar devam etmektedir. Kaynakça [1]. Gupta A., ClearCase Multisite: Supporting Geographically-Distributed Software Development, 19 Eylül 2004. [2] Berczuk S. ve Appleton B., Software Configuration Management Patterns: Effective Teamwork, Practical Integration, 2002.