Daıtık Kalite Güvencesi

Transkript

1 Daıtık Kalite Güvencesi Cemal YILMAZ 1 Adam PORTER 4 1, 4 Bilgisayar Bilimleri Bölümü, Maryland Üniversitesi, College Park 1 [email protected] 4 [email protected] Çaatay ÇATAL 2 2 TÜBTAK, Marmara Ara. Merk., Biliim Teknolojileri Enstitüsü, Gebze,Kocaeli 2 [email protected] Oya KALIPSIZ 3 3 Bilgisayar Mühendislii Bölümü, Yıldız Teknik Üniversitesi, Beikta, stanbul 3 [email protected] Özet Kalite güvencesi aktiviteleri, çou durumda gelitirici ekip tarafından sadece gelitirme ortamında gerçekletirilmektedir. Birçok sistem için bu yaklaım, çeitli sorunlara neden olduundan kullanıcıyı da kalite güvencesi aktiviteleri içine alan araçlar ve süreçler gelitirilmektedir. Ancak; yapılan bu çalımalar sadece belirli koullar altında çalımakta ve kalite güvence sürecinin etkin, ölçeklenebilir olmasını salayacak olan denetim, ibirlii, koordinasyon ilemlerini içermemektedir. Bu nedenle; genel amaçlı kalite güvence sürecini salayacak olan bir yapının kurulması, bu yapı üzerinde kalite güvence senaryolarının iletilmesi, çeitli araçlarla bu yapının desteklenmesi gerekmektedir. Açıklanan gereksinimler neticesinde, Skoll projesi balatılmıtır. Bu çalımada; Skoll projesi kapsamında yapılan analizlerin özeti verilmeye çalıılmı, Türkiye deki aratırmacıların bu alandaki teknolojiler ve aratırma konularında bilgilendirilmesi amaçlanmıtır. Bunun yanı sıra, Skoll mimarisine 3. parti araçların eklenmesi durumunda elde edilecek kazanımlar bu çalıma neticesinde ortaya konulmutur. Abstract Quality assurance activities are mainly performed by developer team in only developer site. Since this approach produces various problems for many systems, tools and processes are being developed by including the user in the QA process. However; these tools work on the limited conditions and do not include control, cooperation, and coordination policies to make the QA process effective and scalable. For this reason; it is necessary to create a general purpose QA framework, operate QA scenarios on this framework and support it with various tools. Skoll project has been started for these reasons. In this study; it is tried to summarize the analysis of Skoll project and it is intended to inform Turkish researchers on these technologies and research subjects. Furthermore; as a result of this study, it is showed that there will be some benefits when 3 rd party tools are integrated to this framework. 1. Giri Yazılım kalitesi; yazılım proje planı ile kalite kontrolü yöntem ve araçlarının belirlenmesi, gelitirme süreci durak noktalarında gözden geçirme, kaynak programın test edilmesi gibi üretim

2 sürecinde kalite kontrolü ve ürünün kullanıcıya teslimi sırasında da kabul muayenesi ile gerçekletirilir [1]. Test yoluyla hatalar bulunup düzeltildii gibi, yazılımın spesifikasyonlara uygun olarak ilemlerini yerine getirdii ve performans gereksinimlerini gerçekletirdii kanıtlanmı olmaktadır. Ayrıca; bir bütün olarak yazılımın güvenilirlii ve kalite özellikleri ortaya konmaktadır [2]. Gelitirilen sistem için kalite faktörlerinin deerlendirilmesi zor bir problemdir. Bu amaçla farklı metrikler tanımlanarak, her metrie bir not verilebilir [3]. Kalite güvence kapsamındaki performans analizleri, testler, modüllerin zamanlama profillerinin çıkarılması gibi aktiviteler çou durumda gelitirici ekip tarafından sadece gelitirme ortamında gerçekletirilmektedir. Bu yöndeki etkinliklerin faydası; kalite güvence ekipleri tarafından bulunan hataların kolayca anlaılarak, gerekli çözümlerin kısa sürede gelitirici ekip tarafından oluturulabilmesidir. Gelitirici ekibin koda tam olarak sahip olması, gereksinim analizinden testlere kadar tüm yazılım mühendislii süreçlerinin aynı ekip tarafından gerçekletirilmesi, tespit edilen hatanın aynı koullarda oluturulabilir olması gelitirici ortamında kalite güvencesi aktivitelerini kolaylatırmaktadır. Ancak; testlerin, performans analizlerinin ve dier aktivitelerin gelitirici ortamında yapılması, harcanan zamana balı olarak kalite güvence maliyetlerinde artıa neden olmaktadır. Gelitirilen yazılımın farklı platformlar için çalıması gerektii durumlarda, yapılacak olan testleri, analizleri göz önüne alırsak yapılan masrafların göz ardı edilemeyecek derecede olduunu görebiliriz [4, 5, 6]. Bununla birlikte; gelitirme ortamında kullanılan test senaryoları, iletim sistemleri, giri verilerindeki i yükü, yazılım versiyon farklılıkları kullanıcıdaki yazılım üzerinde oluabilecek tüm durumları içermeyebilir. Bunun neticesinde; hiç beklenmedik ekilde yazılımda sorunlar çıkabilmektedir. Örnein; son yıllarda performans kriterinin temel alındıı, daıtık sistemler, gerçek zaman sistemleri, ara katman yazılımları, gömülü sistemler, doal dil ileme araçları gibi yazılımlar farklı donanımlar, derleyeciler kullanılarak oluturulmakta ve bu yazılımların farklı iletim sistemlerinde çalıması beklenmektedir [6]. Performansın temel ölçüt olduu bu sistemlerde, hizmet kalitesini arttırmak için birçok konfigürasyon seçenei sunulmaktadır. Kullanıcı; i yükünü saptama, iletim sisteminin özel desteklerini etkinletirme, kullanmadıı özellikleri kapatma gibi kendi ihtiyaçlarına göre gerekli konfigürasyon parametrelerini belirleyerek yazılımı etkin ekilde çalıtırabilir. Yüksek seviyede deiiklie izin veren bu sistemler sayesinde, belirlenen özellikler neticesinde yazılımın kullanıldıı ortamda yüksek performans alınması mümkün olmaktadır. Ancak; gözden kaçan bir parametrenin yazılımın çalımasını bozabilecei de açık bir gerçektir. Son yıllarda yazılım sektöründeki deiimlerle birlikte, kullanıcının da kalite güvencesi etkinliklerine katılması gereklidir. Bu deiimler aaıda açıklanmaktadır [5]: Maliyet ve zaman kısıtları: Günümüz yazılım endüstrisinde, artan rekabete balı olarak ürünlerin en kısa zamanda piyasaya sunulması gerekmektedir. Bunun yanında; gelitirme ve kalite güvencesi için yapılan masrafların da azaltılması beklenmektedir. Kullanıcıların parametrelerin seçimi gibi üzerinde deiiklik yapmak durumunda olduu yazılımlara para ödemekteki isteksizlii göz önüne alınırsa, kalite güvencesi adımlarının kullanıcı tarafından da yapılması gerektii söylenebilir. Kullanıcıya özel deiiklik: Performansın temel ölçüt olduu sistemler, yazılımın çalıtıı ortama, beklentilere göre deitirilebilmelidir. Bu ortamı iletim sistemi olarak ele alırsak; yapılacak olan testlerin fazlalıını ve getirecei maliyet artıını hesaba katarak kullanıcıyı bu aktivitelerin içine almamız gerektii sonucunu çıkarabiliriz.

3 Daıtık ve artımlı gelitirme: Gelitirme süreçleri günümüzde, e zamanlı çalıabilmeyi salamak için daıtık olarak gerçekletirilebilmektedir. Kimi zaman corafi olarak daıtıklık söz konusu iken, farklı iletme birimleri arasında da bu daıtıklık kavramından yararlanılmaktadır. Artımlı yazılım gelitirmede ise, her gün yazılıma birkaç parça eklendii için hata olasılıı artmaktadır. Oracle, Apache gibi çou yazılımda yüzlerce konfigürasyon parametresi bulunmaktadır. Bu parametrelerin tüm iletim sistemlerinde denenmesi durumundaki i gücünü dikkate alırsak, kullanıcıyı da içine alan kalite güvencesinin vazgeçilmez olduu sonucunu çıkarabiliriz. Kullanıcının da kalite güvencesi aktiviteleri içinde yer aldıı veya bu aktivitelerin kullanıcı tarafına kaydıı kalite güvencesi türü daıtık kalite güvencesi olarak tanımlanmaktadır. Asıl amaç; kullanıcıya yük olmadan kullanıcının kaynaklarından yararlanarak yazılım kalitesini arttırmaktır. Deien dünyada; bir yazılım sisteminin milyonlarca kullanıcısı olabilmekte ve bu kullanıcıların çou internet e balı durumdadır. Bu kullanıcı kaynaklarından yararlanarak yazılım kalitesi arttırılabilir mi sorusuna yanıt aranmaya çalıılmakta ve bu yönde çalımalar sürdürülmektedir. 2. Mevcut Yaklaımlar ve Araçlar Daıtık kalite güvencesini gerçekletirebilmek için imdiye kadar birçok çalıma yapılmı ve bazı araçlar gelitirilmitir. Bu kapsamda; Netscape Kalite Geribesleme Etmeni, Microsoft XP hata raporlama sistemi gibi çevrimiçi hata raporlama sistemleri oluturulmu ve sistemde sorun olması durumunda sistemin içinde bulunduu durum bilgisini otomatik olarak alabilmeleri salanmıtır. Bu tür araçlar yazılım kalitesini arttırmasına ramen, sınırlı çözümler sunmaktadır: Kalite güvencesinde kullanıcı katılımı salanarak otomatik olarak hataların raporlanabildii araçlar, kalite güvencesinin sadece bir kısmını gerçekletirebilmektedir. Örnein; bu tür araçlarla sadece programın çalımasının çöktüü andaki hata alınabilmektedir. Kalite güvencesine ilikin tüm aktivitelerin bu tür araçlarla belgelenmesi mümkün olmamaktadır. Bunun sonucunda, gelitiriciler kalite güvencesi sürecinde tam olarak denetimi salayamamaktadır. ACE+TAO, Mozilla gibi birçok bilinen projede de son kullanıcılara sunulan testler sayesinde, kullanıcıların kendi ortamlarında bu testleri yapması salanarak kurulumun baarılı olup olmadıı anlaılmaktadır. Hatalar, Bugzilla izleme sistemi ile raporlanmaktadır ve bu sistem, CVS gibi konfigürasyon yönetim araçları ile tümleik çalıabilmekte, ileri raporlama yetenekleri sunmaktadır. Bu sistemin, kalite güvence sürecini belgelemede katkısı olmasına ramen, sistemin hangi bölümlerinin test edilecei son kullanıcıya bırakılmaktadır. Ancak çou durumda, kullanıcı bu test sonuçlarını hata çok kritik deilse gelitiricilere bildirmezler. Türkiye de de birçok kurum ya da firma Bugzilla hata takip sistemini kullanmaktadır. TÜBTAK-UEKAE tarafından balatılmı olan ulusal daıtım projesi (ULUDA) kapsamında gelitirilen PARDUS ürününün de bir hata takip sistemi mevcuttur [7]. Temelinde Bugzilla uygulamasının çalıtırıldıı bu takip sistemi, Uluzilla olarak adlandırılmaktadır. Kullanıcı hesabı üzerinden; gelitirme istekleri yapılabilir, hata raporlanabilir, oy kullanılabilir ve yorum yapılabilir. Hata veya dier konulara ilikin haberler, kayıt sırasında verilen e-posta adresine gelmektedir. Mevcut araçlarla yapılan testlerin sonuçlarına göre, sistemin adaptif olarak test edilmesi veya testlerden örenme mekanizmaları ile sonuçların çıkarılması mümkün olmamaktadır. Örnein; belirli konfigürasyon parametresinde hata veren bir sistem, bu parametrelere yakın deerlerde de hata vermesi olasıdır. Ancak; mevut araçlarla bu tür ilemler gerçekletirilememektedir.

4 Yukarıda açıklanan eksikliklerin düzeltilmedii bir kalite güvence sürecinin, etkin olarak çalıması mümkün deildir. Bu nedenle; daha genel amaçlı bir yapı kurularak, bu yapı üzerinde yukarıda açıklanan gereksinimlerin karılandıı araçlarla daıtık kalite güvencesi gerçekletirilmelidir. 3. SKOLL 3.1 Giri Skoll projesi [8], genel amaçlı kullanılabilecek daıtık kalite güvence sürecinin genel yapısını oluturmak için balatılmıtır. Temel amaç; dünya üzerindeki kullanıcıların hesaplama kaynaklarından yararlanarak yazılım kalitesini daıtık ve sürekli bir biçimde gelitirebilmektir. Bu kapsamda; daıtık, sürekli sürecin (DCQA-distributed continuous quality assurance) tüm dünyada binlerce kullanıcı makinesi üzerinde yönetildii fikri, Skoll projesinin balangıç noktası olmutur. Skoll içerisinde görevler; test, performans deerlendirme gibi kalite güvence aktiviteleridir. Bu aktiviteler, alt görevlere ayrılır. Örnein; bir alt görev regresyon testleri yaparken, baka bir alt görev zorlama (stress) testlerini gerçekletirebilir. Skoll içinde, hesaplama düümleri gönüllü son kullanıcıların makinelerine karılık gelmektedir. Böylece; farklı iletim sistemlerinde sistemin test edilme imkanı ortaya çıkmaktadır [8]. Buraya kadar açıklanan kısımlar, Skoll un ana fikrini ortaya koymaktadır. Bu bölümün geri kalan kısmında, daha detaylı bilgi verilecek, Bölüm 3.2 de Skoll mimarisi, Bölüm 3.3 de Skoll konfigürasyon modeli ve Bölüm 3.4 de Akıllı Yönlendirme Etmeni (Intelligent Steering Agent-ISA) açıklanacaktır. 3.2 SKOLL Mimarisi Daıtık sürekli kalite güvence sürecini gerçekletirmek için, Skoll istemci/sunucu mimarisi [8] kullanır. stemciler, web tabanlı kayıt formunu kullanarak sunucunun içinde bulunan Sunucu Kayıt Yöneticisi ile sunucuya kayıt olurlar. Kullanıcılar; iletim sistemi, derleyici gibi istemci platformunun özelliklerini kayıt formu ile belirtirler. Bu bilgi sunucu veritabanında saklanır ve Akıllı Yönlendirme Etmeni tarafından kullanılır. ISA bölüm 3.4 de daha detaylı olarak açıklanacaktır. Kayıt ileminin ardından istemciye sistem üzerinde tek olan bir numara ve konfigürasyon ablonu verilir. ablon son kullanıcılar tarafından deitirilerek sunucudan gelecek i konfigürasyonları için sınırlandırma getirilebilir. Temel olarak i konfigürasyonu; bir yazılım projesi ile ilikili olan uygulama kodu, konfigürasyon parametreleri, oluturma (build) komutları ve regresyon/performans testleri gibi kalite güvencesine özgü kodları içeren bir betiktir (script). konfigürasyonu aynı zamanda; istemcinin kendisine atanmı olan kalite güvencesi alt görevini yerine getirebilmesi için, ortam deikenlerinin atanması, CVS den yazılımın çekilmesi, loglamanın balatılması/durdurulması, sistem komutlarının çalıtırılması gibi yardımcı olacak komutları içermektedir. Skoll istemcileri periyodik olarak, sunucudan i konfigürasyonu talebinde bulunurlar. Sunucu ise istemci platformu, geçerli konfigürasyon uzayının bilgisi ve önceki kalite güvencesi aktivitelerinin sonuçlarına göre düzenlenmi bir i konfigürasyonu ile cevap verir. Skoll istemcisi i konfigürasyonu sunucudan alınca, komutları aldıı sırada birer birer iletir. Skoll istemci/sunucu mimarisi ekil 1 de gösterilmektedir [8]. Skoll un istemci mimarisi ise, 4 bileenden olumaktadır. Bu bileenler; Yazılım stemci Deposu (Software Repository Client), Oluturma Yöneticisi (Build Manager), Konfigürasyon Yöneticisi (Configuration Manager) ve Test Yöneticisidir (Test Manager). CVS istemci bileeni, yazılımı CVS deposundan indirmekten sorumludur. Versiyon ve modül ismi gibi bilgiler i konfigürasyonu içinde gönderilir. Sunucudan gelen komutlar içerisinde, konfigürasyon parametresi ve bu parametrenin tanımlı olduu balık

5 dosyası yer almaktadır. Oluturma yöneticisi, kayıt sırasında formda belirtilen derleyiciyi kullanarak yazılımı oluturur. Bu ilemin ardından, Test Yöneticisi gerekli test ilemlerini balatır. Her i konfigürasyonu için, Skoll istemcisi tüm aktiviteleri bir günlük (log) dosyasına yazar. Test ileminin bitmesinden sonra bu dosya, sunucuya gönderilir ve sunucu içindeki Sunucu Kalite Güvence Süreç Sonuçları Yöneticisi (Server QA process results acquisition manager) tarafından dosya incelenerek veritabanına kayıt edilir. Sunucu Skor Tahtası Yöneticisi (Server Scoreboard Manager) ise web tabanlı bir form ile belirli bir i konfigürasyonundaki sonucu istemciye gösterebilmektedir. Skoll istemcisi de ekil 2 de gösterilmektedir [8]. ekil 1: Skoll stemci/sunucu Mimarisi Bileenleri ekil 2: Skoll stemci Bileenleri 3.3 Konfigürasyon Uzayı Modeli Skoll projesinin en önemli adımlarından birisi de, kalite güvence sürecine ilikin konfigürasyon uzayının bir modelinin oluturulmasıdır [5]. Model, kalite güvencesi alt görevleri için tüm geçerli konfigürasyonları kapsamaktadır. Seçenekler ve bu seçeneklere izin verilen deerler arasında oluturulan ikili çiftlerin kümesi konfigürasyonları oluturmaktadır. Vi: konfigürasyon seçenei Ci: konfigürasyon seçeneinin deeri {(V1,C1), (V2,C2),...,(Vn,Cn)} kümesi ise olası tüm konfigürasyonları vermektedir. Uygulamada tüm konfigürasyonlar anlamlı olmayabilir. Örnein; bir konfigürasyon seçenei bir derleyicide desteklenmezken baka bir derleyici ise bu destei sunabilmektedir. Bu nedenle; bir seçenein baka bir seçenee balı olarak kısıtlanmasını salayan seçenekler arası kısıtlar adı verilen

6 kavram ortaya konulmutur. Bu kısıtlar (Pi Pj) olarak gösterilmekte ve Pi doru ise Pj de doru olması gerekir eklinde deerlendirilmektedir. Geçerli bir konfigürasyon, seçenekler arası kısıtlardan hiçbirini ihlal etmemesi gerekir. Skoll projesi kapsamında; geçerli konfigürasyon uzaylarını tanımlamak için bir araç oluturulmutur. Tablo 1 de görüldüü gibi, bazı seçenekler arasında kısıtlar mevcut olabilir. Örnein; tablodaki gibi AMI seçili iken, CORBA_MSG de seçili olmalıdır. Bu tablo, ACE+TAO projesi üzerine yapılan çalımadan alınmıtır [8]. Tablo1: Seçenekler ve Kısıtlar Seçenek Seçenek Deeri Yorum DERLEYC {gcc2.96, Derleyici SUNCC5_1} AMI {1=Evet, 0=Hayır} Etkinletirme özellii CORBA_MSG {1=Evet, 0=Hayır} Etkinletirme özellii Kısıtlar AMI=1 CORBA_MSG= Akıllı Yönlendirme Etmeni (Intelligent Steering Agent-ISA) Skoll projesinin en önemli özelliklerinden birisi de ISA dır. Bir önceki alt bölümde, geçerli konfigürasyon uzayını tanımlamak için bir araçtan bahsetmitik. Bu bölümün ana teması da, bu uzayda nasıl hareket etmemiz gerektiini belirlemektir. Bu nedenle; Akıllı Yönlendirme Etmeni (ISA) oluturulmutur. ISA, istemci makinelere alt görev atamasında bulunmaktadır. ISA yeni bir konfigürasyon seçince; istemciye bu i konfigürasyonunu gönderir ve istemci ilemi gerçekletirdii zaman oluturduu sonuçları ISA ya gönderir. Varsayılan durumda; ISA bu sonuçlarla ilgilenmez. Ancak; çou kez gelen bu sonuçlardan örenme ileminin gerçekletirilmesi istenir. Skoll sürecinin en önemli özelliklerinden birisi; kullanıcılardan gelen bilgilere göre ISA nın örenebilmesi ve global Skoll sürecini adapte ederek daha etkin hale getirmesidir. ACE+TAO projesinin incelenmesi sırasında 3 farklı adaptasyon stratejisi kullanılmıtır [8]. En Yakın Komu Stratejisi: Örnein; bir test senaryosunun baarısız olduu durumda, gelitiriciler benzer konfigürasyonların baarısız olup olmayacaını belirlemek isteyeceklerdir. Bir konfigürasyon seçenei baarısız olduu durumda, ilgili konfigürasyon kayıt edilir ve baarısız olan konfigürasyondan örnein 1 birim uzaklıktaki konfigürasyonların test edilmesi salanır. 1 birim uzaklik ile belirtilen durum; tüm konfigürasyonlar içerisinden, baarısız olan konfigürasyona göre, sadece 1 seçenein deerinin farklı olduu konfigürasyonların seçilmesidir. Amaç; baarısız olan konfigürasyonların oluturduu alt uzayların sınırlarındaki konfigürasyonları test etmektir. Bu bilgi daha sonra, hata karakterizasyon süreci (fault characterization process) tarafından, hataya neden olan seçenekleri belirlemek için kullanılır. Farklı açık kaynak kodlu projelerde yapılan incelemeler sonucu, bu stratejinin oldukça etkin çalıtıı ve olası hataları bulabildii ortaya konulmutur [8]. Geçici Kısıtlar:Testler sırasında hataya yol açan bir konfigürasyon tespit edildii ve bu hatanın kısa sürede çözülemedii durumlarda geçici kısıtlar tanımlamak mümkündür. Problem çözüldüü zaman, bu kısıtlar ortadan kaldırılır.

7 Alt görevleri Bitirme/Deitirme: Bir test senaryosunun baarısız olduu durumda, sürekli test etmeye devam etmek gereksiz yere zaman kaybına yol açacaktır. Ayrıca çok fazla bilgi de elde edilemeyecektir. Bu nedenle o alt göreve geçici olarak ara vermekte fayda vardır. 4. SKOLL Çalıma Adımları Üst seviyede, Skoll süreci aaıdaki ekilde çalımaktadır [8, 9]. Gelitiriciler konfigürasyon modelini ve adaptasyon stratejilerini oluturur. ISA, otomatik olarak modeli planlama problemi haline dönütürür. Ayrıca; gelitiriciler genel kalite güvencesi alt görev kodunu oluturur ve bu kod i konfigürasyonları oluturulurken özelletirilebilir. Kullanıcı kayıt formunu kullanarak sunucudan, Skoll istemcisini ve konfigürasyon ablonunu elde eder. stemci periyodik olarak veya istek üzerine sunucudan bir i konfigürasyonu talebinde bulunur. Sunucu; içerisinde ISA bir plan olutururarak i konfigürasyonlarını istemciye döndürür. stemci i konfigürasyonunu yürütür ve sonuçları sunucuya döndürür. Sunucu bu sonuçları inceler ve tüm adaptasyon stratejilerini çaırarak global sürecin adaptasyonunu salar. Periyodik olarak sunucu sanal skor tahtası oluturur ve bu tahta alt görev sonuçlarını gösterir. 5. Yapılabilirlik Çalıması Bu bölümde; Skoll üzerinde gelitirilmi olan çeitli süreçler tanımlanmaktadır. 5.1 alt bölümü ACE+TAO kütüphanesinin Skoll ile analizini, 5.2 hata karakterizasyon sürecini, 5.3 temel etkileri sahneleme sürecini açıklamaktadır. ACE+TAO kütüphanesi, performansa duyarlı daıtık yazılım uygulamaları için kullanılmaktadır. ACE, platformdan baımsız a uygulaması gerçekletirmek için kullanılırken TAO da ACE üzerine oluturulmu CORBA ORB gerçeklemesidir [7, 8, 10]. ki proje, 2 Milyondan fazla kod satırı içermektedir. Ayrıca, kütüphane içinde test amaçlı kullanılacak projeler mevcuttur. ACE+TAO projelerinin bakımı, corafi olarak farklı yerlerde bulunan 140 gelitirici tarafından gerçekletirilmektedir. ACE+TAO kütüphaneleri bulunan hatalarla birlikte her gün iyiletirilmekte ve güncellemeler yapılamaktadır. Regresyon testleri sayısı 100 ü aan makinede yapılmaktadır. ACE in platformdan baımsız a uygulaması gelitirilmede kullanılması sebebi ile, tüm platformlarda tüm konfigürasyon deerlerini denemek çok zordur. Bu nedenle, Skoll projesinin bu noktada fayda salayacaı düünülmütür Balangıç Çalıması Skoll projesi, ACE+TAO projesi üzerinde denenerek mevcut durumu analiz edilmitir. ACE+TAO kurulumu için 17 tane derleme zamanı seçenei saptanmı ve 35 seçenekler arası kısıt ortaya konmutur. Bu konfigürasyon uzayı, geçerli konfigürasyon içermektedir. Konfigürasyonun çok geni olması sebebi ile, en yakın komu adaptasyon stratejisi kullanılmıtır [8]. 500 konfigürasyon testinden sonra, alt görevi bitirme stratejisi her konfigürasyonun derleme için baarısız olduunu ortaya koymutur. ACE+TAO gelitiricileri ile iletiime geçtikten sonra CORBA mesajlaması ile ilgili 7 seçenein probleme yol açtıı saptanmıtır. Bu seçeneklerin kontrolünün derleme anından balama aamasına taınmasına karar verilmitir. Bu nedenle, modelden 7 seçenek çıkarılarak 10 seçenek ve 7 kısıttan oluan yeni bir model elde edilmitir. Bu model de, 89 geçerli konfigürasyon içermektedir. Yapılan analiz sonunda bu 89

8 konfigürasyonundan sadece 29 unun hatasız derlendiini, 60 tanesinde hata olduunu ortaya koymutur. Bu çalımanın yapılmasının nedeni; kütüphaneyi gelitiren ekibin, tüm parametrelerin kütüphanenin kurulumunda etkisini incelememi olması ve kütüphaneyi kullanacakların bu parametreleri istedikleri gibi deitirmesi durumunda istenmeyen sonuçların önceden tespit edilmesini salamaktır. Derleme aamasında olduu gibi benzer testler, çalıma anındaki seçenekler için de gerçekletirilmitir. Skoll projesinin, ACE+TAO gibi büyük kütüphanelerin analizinde kullanılabilecei sonucuna varılmıtır. Birçok hata tespit edilerek gelitiriciler tarafından düzeltilmitir [11] Hata Karakterizasyon Süreci (Fault Characterization Process) Sistem üzerinde hataya yol açan konfigürasyon seçeneklerinin saptanması ve hatanın tam olarak belirlenebilmesi için hata karakterizasyonu ilemi gerçekletirilmelidir. Bu amaçla; hata karakterizasyon süreci oluturulmutur. Bu sürecin amacı; hataya yol açan konfigürasyon alt uzaylarını gelitiriciler için doru olarak tanımlamaktır. Örnein; hangi ayarların spesifik hatalara neden olduunu ortaya koymak için kullanılabilir. Bu ileme, hata karakterizasyonu (fault characterization) adı verilir. Örnein; hata karakterizasyon sürecini CORBA gerçeklemesinde kullanarak, yürütebilir dosyanın Linux da çalıması durumunda (CORBA Mesajlama Desteinin etkin fakat Asenkron Mesajlama Optimizasyonu etkin deilse) soket balantılarının zaman aımına uradıı tespit edilmitir. Bu bilgi sistem gelitiricilerine verilerek hatanın gerçek sebebi hızlıca belirlenmitir. Otomatik olarak hatayı karakterize eden model ile, arama uzayını inceleyerek gelitiricilerin ii oldukça kolaylatırılmıtır. Otomatik oluturulan hata karakterizasyonu modelleri yararlı olmasına karın, tüm konfigürasyon uzayının test edilmek zorunda olması bu yaklaımın ölçeklenebilirliini bozmaktadır. Bu bölümde, alternatif bir strateji önerilmekte ve deerlendirilmektedir. Temel fikir konfigürasyon uzayını sistematik olarak örneklemek, sadece seçilen konfigürasyonları test etmek ve sonuç verisi üzerinde hata karakterizasyonunu gerçekletirmektir. Kullanılan örnekleme yaklaımı, kapsayan dizi (covering array) adı verilen matematiksel bir nesnenin hesaplanmasına dayanmaktadır [6]. Kapsayan diziler, sıkça programların test giri kombinasyonları için kullanılmıtır. Yapılan aratırmada, bu diziler sistem konfigürasyon seçeneklerine uygulanmıtır [6]. Kapsayan dizileri; hata karakterizasyon modellerinde kompleks konfigürasyon uzaylarını incelemek için örnekleme stratejisi olarak kullanmak; tüm testleri yaparak elde edilen sonuçlar kadar doru sonuçlar üretebilir ancak daha az sayıda konfigürasyonla test yapılacaı için daha az zaman harcanacaktır. Bu sayede %50-99 oranında konfigürasyon sayısında azalma salanmıtır Temel Etkileri Sahneleme Süreci (Main effects screening process) Performansa duyarlı sistemler gelitirirken, yapılan deiikliklerin sistemin performansını ne ölçüde etkiledii önemli bir problemdir. Bu problemi çözebilmek için; öncelikle sistemin performansını etkileyen parametreler belirlenmelidir. Temel etkileri sahneleme; sistem deiiklii sonucunda geni konfigürasyon uzayı karısında performans azalmasının hızlıca tespit edildii bir tekniktir. Bu teknii; performansı yüksek oranda etkileyen konfigürasyon uzayının küçük bir alt kümesini belirleme eklinde deneysel bir tasarım sorusuna dönütürmek mümkündür. Bu noktadan; sistemin deitii her zaman, bu önemli seçeneklerin tüm kombinasyonlarını test eder ve böylece tüm konfigürasyon uzayında performansın güvenilir tahmini yapılır. Önemli seçenekler zamanla deiebilecei için süreci yeniden balatarak önemli seçenekler tekrar ayarlanabilir [12]. Çok geni kullanıcı topluluu tarafından kullanılan ACE+TAO projesi üzerinde bu süreç denenmitir. Bu sayede; temel etkileri sahneleme sürecinin,

9 güvenilir ekilde performans azalmasında anahtar kaynakları, geleneksel yöntemlerden daha az çabayla ortaya koyabilecei gösterilmitir [12]. 6. Yapılan Çalımalar ve Deerlendirme Skoll aratırma projesi olduu için, yapılabilirlik çalıması da ileride yapılabilecek olan çalımalar için yardımcı olacaktır. leriki çalımalar, daha çok deney ve alt yapının izlenmesi, fonksiyonelliin arttırılması üzerine younlaacaktır. Bu kapsamda; ACE+TAO projesi ile çalımaya devam edilecektir. 2 kıtada bulunan temel ACE+TAO gelitiricilerinin salayacaı yüzlerce makine ile farklı testler gerçekletirilecektir. Skoll konfigürasyon modelleri zenginletirilmektedir. Yeni hiyerarik modeller eklenerek, modele öncelik bilgisi katılacaktır. ISA yi iyiletirme çalımaları yapılmaktadır. Bu sayede; ISA maliyet modelleri ve olasılık bilgisine göre planlama yapmaya izin verecektir. Örnein; bir kullanıcının belirli platformlarda belirli sıklıkla istek gönderdii bilgisi oluturulabilirse, ISA bu bilgiyi i konfigürasyonu ayırırken kullanabilir. Bu çalımaların yanında, Skoll un otomatik testleri yapabilecek yetenekte bir mimariye sahip olması nedeni ile bu yönde de çalımalar yapılabilir: lk aamada, test amaçlı kullanılan mevcut araçların (3. parti araçlar) analizi yapılarak bu yapıya nasıl entegre edilecei saptanabilir. Arayüzler doru ekilde tanımlanarak, sistemdeki araçların deimesi durumunda da yeni araçlarla çalıabilmesi salanmalıdır. Bellek kaçakları (memory leak), modüllerin zamanlama profillerinin çıkarılması (profiling), kapsama analizi (pure coverage) gibi testleri yapan araçlar mevcut yapıya dahil edilerek tüm testlerin otomatik olarak yapılması yoluna gidilebilir. 3. parti araçlarının yapıya eklenmesi sayesinde, en basit uygumalardan en karmaık uygulamalara kadar testlerin otomatikletirilmesi söz konusu olacaktır. Bu sayede; kalite güvencesi noktasında firma içinde önemli aamalar kaydedilecektir. 7. Sonuç Bu çalımada; daıtık kalite güvencesi ele alınarak gereklilii ortaya konulmutur. Mevcut sistemlerdeki yetersizlikler, genel amaçlı bir kalite güvence sistemi için ihtiyaçlar incelenmitir. Bu kapsamda gelitirilmekte olan Skoll projesinin mimarisi, yararları, yapılabilirlik çalıması analiz edilmitir. Yakın zamanda Skoll projesinin çıktıları, gelitirilecek olan daıtık sistemlerde kolayca kullanılabilecek ve sistemlere olumlu katkılar salayacaktır. Kullanıcıyı da kalite güvencesinin içine alan bu yaklaım sayesinde daha kaliteli yazılımlar ortaya çıkması beklenmektedir. Bu çalıma neticesinde; Skoll projesi kapsamında imdiye kadar yapılmı olan çalımalar özetlenmi ve bu alanda Türkiye de çalıan aratırmacılara gerek teknolojik gerekse de kavramsal düzeyde bilgilendirme yapılmıtır. Bunun yanı sıra; 3. parti araçların Skoll mimarisine entegre edilerek, bu sayede basit uygulamalardan karmaıklara kadar her türlü sistemin kalite güvencesinde kullanılabilecei saptanmıtır.

10 Referanslar [1] O. Kalıpsız, Yazılım Mühendislii,.Ü Yayını, [2] O. Kalıpsız, Yazılım Gelitirme Sürecinde Kalitenin Salanması, T.B.D. 9. Ulusal Biliim Kurultayı, Eylül 1992, s [3] M. E. Sarıdoan, Yazılım Mühendislii, Papatya Yayıncılık, [4] C. Yilmaz, A. Memon, A. Porter, A. S. Krishna, D. C. Schmidt, A. Gokhale, ve B. Natarajan, Preserving Distributed System's Critical Properties--A Model-Driven Approach, IEEE Software Special Issue on the Persistent Software Attributes, Kasım [5] A. S. Krishna, D. C. Schmidt, A. Memon, A. Porter ve C. Yilmaz, A Distributed Continuous Quality Assurance Process to Manage Variability in Performance-intensive Software, OOPSLA '04 Workshop on Component And Middleware Performance. [6] C. Yilmaz, M. Cohen, ve A. Porter, Covering Arrays for Efficient Fault Characterization in Complex Configuration Spaces, Proceedings of the 2004 ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), Boston, Massachusetts, [7] Ulusal Daıtım Projesi (ULUDA), [8] A. Memon, A. Porter, C. Yilmaz, A. Nagarajan, D. C. Schmidt, ve B. Natarajan, Skoll: Distributed Continuous Quality Assurance, Proceedings of the 26th IEEE/ACM International Conference on Software Engineering (ICSE), Edinburgh, Scotland, Mayıs [9] A. Krishna, D. C. Schmidt, A. Porter, A. Memon ve D. Sevilla-Ruiz, Improving the Quality of Performance-intensive Software via Model-integrated Distributed Continuous Quality Assurance, The 8th International Conference on Software Reuse, ACM/IEEE, Madrid, Spain, Temmuz [10] C. Yilmaz, A. S. Krishna, A. Memon, A. Porter, D. C. Schmidt, A. Gokhale, ve B. Natarajan, A Model-based Distributed Continuous Quality Assurance Process to Enhance the Quality of Service of Evolving Performance-intensive Software Systems, Proceedings of the 2nd ICSE Workshop on Remote Analysis and Measurement of Software Systems (RAMSS), Edinburgh, Scotland, UK, Mayıs [11] C. Yilmaz and A. Porter ve D. C. Schmidt, Distributed Continuous Quality Assurance: The Skoll Project, in Workshop on Remote Analysis and Measurement of Software Systems (RAMSS), (Portland, Oregon), IEEE/ACM, Mayıs [12] C. Yilmaz, A. Krishna, A. Memon, Adam Porter, D. C. Schmidt, A. Gokhale, ve B. Natarajan, Main Effects Screening: A Distributed Continuous Quality Assurance Process for Monitoring Performance Degradation in Evolving Software Systems, 27th International Conference on Software Engineering, St. Louis, MO, Mayıs 15-21, 2005.