Yazm Dorulama Sürecinde Gereksinim Yönetim Arac Kullan Using Requirement Management Tool in Software Verification Process Dervi, Akyüz Yazm Test Birimi ASELSAN MGEO, Ankara dakyuz@mgeo.aselsan.com.tr Özet Bu bildirinin amac gereksinim yönetim araçlarn etkin kullann yazm dorulama süreci boyunca salad kolaylklar vurgulamak, süreç boyunca elde edilen Yazm Test Plan, Yazm Test Tan, Yazm Test Raporu ve Gözden Geçirme Kaytlarn daha az gücü harcanarak gerçekletirilebildii konusunda kazanlan faydalar paylamaktr. Gereksinim yönetim aracn etkin kullan, kullanlan aracn süreç içerisindeki aktiviteleri yar otomatik veya otomatik hale getirmesi bakndan önem tamaktadr. Bildiride ASELSAN Mikro elektronik, Güdüm ve Elekro-Optik (MGEO) grubunda Yazm Dorulama Sürecinde tanml akn daha hzl gerçeklemesi için gereksinim yönetim aracndaki kullanlan yöntemler anlatlmr. Süreç içerisindeki aktivitelerden ve bu aktivitelerin otomatikletirilmesi ve igücü harcamadan tekrar edilebilmesi için yaplan çalmalardan bahsedilmitir. Abstract This paper emphasize the advantages of effective using requirement management tools in software verification process. This paper share the experience of developing verification process outputs (Software Test Plan, Software Test Definition, Software Test Report and Review Reports) with less labour. Effective using of requirement management tools automate or semiautomate the software process activities. This paper explains the details of using requirement management tools in order to improve the software verification process that is using in ASELSAN Microelectronics, Guidance and Electro-Optics (MGEO) Group. In this paper automating software process and activities are explained in detail. 1. Giri Gereksinim yönetimi, proje yaam döngüsü içinde sürekli olarak yaayan bir aktivitedir. Gereksinim yönetimi tanmlama, analiz etme, izlenebilirlik kurma ve deiklikleri kontrol altna alma gibi kabiliyetlerle ilgilidir [1]. Gereksinimlerin güncel tutulmas, deikliklerin tüm proje ekibi tarafndan fark edilip gerekli güncellemelerin gerçekletirimi, farkl seviyeler arasndaki izlenebilirliin takibi ve eriim haklar gibi yazm yaam döngüsünde sürekli olarak karlalan faaliyetler gereksinim yönetimi araçlarn gelitirilmesi ihtiyac dourmutur [2]. Gelitirilen yazm projelerinin daha kapsaml ve karmak olmas ile birlikte on binlerce yazm ihtiyaçlarn ortaya çkmas ve bu ihtiyaçlarn ksa sürede içerisinde gerçekletirimi ciddi bir gereksinim yönetimiyle mümkün olmaktadr. Yazm yaam döngüsünde gereksinimlerin analiz ve çözümlenmesinden balayarak yazn tasar, yazn gelitirilmesi, yazn dorulamas ve yazn bakn her aamasnda gereksinim yönetimi süreklilik gösterir [3]. Yazm yaam döngüsünde yazm dorulama, gereksinim yönetimine direk olarak ba olan bir süreçtir. Yazm yaam döngüsünde yer alan dorulama aktiviteleri, tüm proje ekibinin dâhil olduu, sistem gereksinimlerinden balayarak kalifikasyona kadar canl kalan bir özellie sahiptir. Dorulama süreçlerinde gerçekletirilen aktiviteler adaki gibi ralanabilir [4]. Yazm test plann hazrlanmas Yazm gereksinimlerinin hazrlanmas Yazm konfigürasyon sürecinin dahil edilmesi Yazm test durumlarn oluturulmas Gözden geçirme toplantlarn düzenlenmesi ve kaytlarn tutularak konfigürasyon altna alnmas Test sonuçlarn raporlanmas
Süreç çktlarn kalite birimine aktarlmas Dorulama süreçlerinde gerçekletirilen aktivitelerin büyük ksmn kaytlar tutulduu için süreç çktlar gelitiren yazm test mühendisleri, yazm test liderleri zaman snt yaayabilmektedir. Bildiride süreç içerisinde toplanan kaytlarn en az i gücü harcanarak tutulmas konusuna odaklanlmr. Kazanlan zamann test durumlarn tasarlanmas, yazm test tekniklerinin etkin olarak uygulanmas, test durumlarn otomatik olarak gelitirilmesi ve koturulmas için harcanmasna dikkat çekilmitir. Bu sayede toplamdaki süreç performansn ve yazm kalitesinin arttlmas hedeflenmitir. 2. Yazm Dorulama Aktivitelerin Otomatik Hale Getirilmesi ASELSAN MGEO gurubunda Yazm Dorulama Süreci, ekil-1 deki aktan görüldüü üzere yazm test plan oluturulduktan sonra yazm gereksinimlerinin oluturulmas ile balar. lgili projelerde sorumlu olan yazm dorulama mühendisleri gelitirilen gereksinimleri inceler. Yazm tasarm, kalite ve yazm dorulama ekiplerinin katyla yazm gereksinimleri gözden geçirme toplant yazm gereksinimlerini gelitiren kii tarafndan düzenlenir. Gereksinimlerin uygunluu deerlendirilerek gereksinimlerin revize edilmesi veya sürecin devam ettirilmesi kararlar. Yazm Test durumlar oluturulur, test durumlarn uygunluu deerlendirilir ve hatal olan yerler yazm dorulama ekipleri tarafndan düzeltilerek testlerin koturulmas ve test raporlarn oluturulup gözden geçirilerek yaynlanmas salanr. maliyetinin ucuz olmas bakndan proje baar için önem tamaktadr[5]. Hata Maliyeti G. Geçirme Birim Test Sistem Entg. Testi Sistem Testi ekil 2: Yazm Gelitirme Sürencideki Hata Düzeltme Maliyeti Çok sayda gereksinimin incelenmesi, gözden geçirme toplantlar için ön hazrlklarn yaplarak bulunan eksik veya hatalarn kayt altna alnmas zaman alan ralardr. Gereksinim yönetim aracnda kayt altnda tutulan gereksinimlerin sahip olduu nitelikler arasnda gereksinim, bak veya açklama olma özellii (Requirement Property), dorulama yöntemi (Verification Method), izlenebilirlii (Traceability), gereksinimin türetilmi olup olmad (Derived) saylabilir. Gereksinimin kendi içerisindeki tutarl, birbirleri ile tutarl, açkl, doruluu, sahip olduu özelliklere uygunluu, dorulanabilir olmas, izlenebilir olmas dikkat edilmesi gereken unsurlardr [6]. Gelitirilen gereksinimleri anlayp bahsedilen unsurlara göre deerlendirebilmek zaman ve kaynak tlamas bulanan bir ortamda her zaman baaryla gerçeklemeyebilir. Konfigürasyon Test Plan Gereksini mler Gözden Geçirme Test Durumlar Gözden Geçirme Test Raporu Test Koturma ASELSAN MGEO bünyesinde gereksinim yönetim arac olarak IBM Rational DOORS uygulamas kullanlmaktadr. Süreç çktlar gelitirilen ekil-3 de gösterildii gibi modüller oluturularak veritabannda tutulmaktadr. Modüller nesnelerden, nesnelere ait niteliklerden, balardan, seviyelerden, metinlerinden ve görünümlerden oluur. zlenebilirlik ID Dorulama Yöntemi Önek-1 SRS-1 Test ekil 1:Yazm Dorulama Süreci Ak Diyagram Gereksinimlerin gözden geçirilmesi ile gereksinimlerde olabilecek hatalar bulunur. Dorulama sürecinde gereksinimlerde ortaya çkan hatalar yazn erken safhasnda bulunmas ve ekil-2 de gösterildii üzere Önek-12 SRS-2 Demo Önek-127 SRS-5 Analiz Önek -89 SRS-9 Kod nceleme ekil 3: Modül Yap ve Modül Nitelikleri
Uygulamann gereksinim yönetimi kapsamnda getirdii temel kolaylklar adaki gibi sralanmr [7]. Sunucu altnda proje klasörleri oluturulmas Proje klasörleri içerisinde proje modüllerinin oluturulmas Proje modülleri için nitelikler (Attribute) ve niteliklere ait tip tanmlamalarn yaplmas Modüller arasnda izlenebilirliinin kurulmas Oluturulan modüllerin kullanlan ofis programlarna dönütürülebilmesi Modül içerisindeki nesnelerin belirli seviyelere göre sralanmas Modül için farkl görünümler (SRS view, TRR view gibi) oluturulmas Modül içindeki nesnelerin özelliklere göre filtreleme, sralama ve arama yaplmas Modül basamaklarn tutulmas (Baseline) ve aralarndaki farklklarn filtrelenmesi Seçilen modül nesnelerinin ve görünümün farkl modüllere kopyalanabilmesi Elle çekilen balardan izlenebilirlik kolonunun oluturulabilmesi Yukarda sralanan temel yeteneklerin haricinde dorulama sürecinde ihtiyaç duyulan faaliyetleri kolaylarmak için kullanlan aracn genileyebilir olmas önem kazanmaktadr [2]. DXL (DOORS extension Language) DOORS uygulamasn destekledii bir betik (Script) dilidir. C ve C++ dillerinin temel yetenekleri DXL dilinde de mevcuttur. Herhangi bir metin editörü ile DXL betik gelitirilebilir. ekil-4 de DXL betiinden bir kesit verilmitir. ekil 4: DXL Betik Örnei Gereksinim yönetimi kapsamnda ihtiyaç duyulabilecek özel durumlar gelitirilen DXL betikleri ile karlanabilir. ASELSAN MGEO dorulama sürecindeki zaman gerektiren bir takm aktivitelerin otomatik hale getirilmesi için DXL betik dilinin kullanlmas planlanmr. Bu kapsamda DXL betikleri gözden geçirme toplantlarndaki kontrol listelerin karlanmasnda, hazr filtreler oluturmada, izlenebilirliklerin otomatik olarak oluturulmasnda, modül içerisindeki neselerin sralanmasnda, modül içerisinde bulunan kolonlarn yeni bir nitelik olarak kopyalanmasnda kullanlmaktadr. DXL betik kullanarak yaplabilecek yetenekler daki gibi sralanmr [8]. Nesneler üzerinde gezinerek, okuma, yazma ve silme Modül oluturma ve silme Modüllere ait niteliklere erime, deerini okuma, yazma ve silme Nesnelere veya niteliklere koullar ve döngüler tanmlayabilme Eriim haklarn kontrolü Yazma zamannda ihtiyaca özgü tetikler ekleyebilme Arayüz oluturup kullan ile etkileim kurma Balarn kurulmas, düzenlenmesi, silinmesi Koullu filtreler oluturularak sonuçlarn raporlanabilmesi ortamdan veri okuma, d ortama veri yazma. 2.1. Gözden Geçirme Toplantlarnda Betik Kullan Hata maliyetin azalmas salayan, yazn dier safhalarna ba olarak projenin baarna dorudan etki eden gözden geçirme toplantlar yazm dorulama aktiviteleri içerisinde ilk sralardadr. Gözden geçirmelerin artan önemi ve getirdii faydalar nedeniyle ASELSAN MGEO bünyesinde gereksinim yönetiminin bir parças olan Review Manager web ara yüz program gelitirilmitir. Bu araç ile gözden geçirmelerin formal bir ortamda tutulmas salanmr. Toplant srasnda veya sonrasnda çkartlan düzeltici, düzenleyici görevler (Action Items) sorumlu kiilere atanp, kaytlarn sunucu üzerinde tutulmas salanmr. Sorumlu kiilerin gerekli düzeltmeyi yapmas ve kendisine atanan görevin durumunu kapatmas ve kalite mühendislerinin kapatlan görevi onaylamas için altyap oluturulmutur. Bu önlemler gözden geçirmelerin uygulanabilirliini ve proje takvimine uygunluunu artran çalmalar olmutur. ASELSAN MGEO da uygulanmakta olan dorulama sürecinde balama kriteri olan ve sürecin dier ktlar dorudan etkileyen Yazm Gereksinim Özellikleridir. Gözden geçirilmi bir Yazm Gereksinim Özelliklerinde belirsizlikler, tutarszlklar, eksiklikler, mantksal hatalar, mulâk ifadeler bulunmamalr [4]. Bu özelliklerin salanabilmesi için Yazm htiyaçlar Gözden Geçirme toplant yapr.
Yazm ihtiyaçlar gözden geçirme toplantnda katmclar gereksinimleri ada verilen kstaslara göre deerlendirir. Sistem gereksinimleri ile ilikilendirilmesi Sistem gereksinimleri ile tutarl olmas Dier yazm gereksinimleri ile tutarl olmas Test edilebilir olmas Tasarlanabilir olmas Gereksinimleri iletim ve bakn yaplabilir olmas Gereksinimlerin gözden geçirilmesi srasnda Yazm Gereksinimleri Gözden Geçirme Kontrol Listesi kullanr. Burada önem kazanan davran, dokümann deerlendirilmesini yapacak olan katmcn (Yazm Test Mühendisi, Yazm Mühendisi, Tasarm Kalite Mühendisi, Proje Lideri) toplant öncesi hazrlklar sa süre içerisinde tamamlam olmasr. Katmclarn dier projelerde yazm gelitirme, yazm test durumlar gelitirme, proje yönetimi gibi sürekli yapt faaliyetler dnda gelen toplant istekleri için zaman planlamas yapp, detayl çalma yapmas her zaman mümkün olmayabilir. Bu durum gözden geçirmelerin baar azaltmaktadr [9]. Projenin geliimi ve ilerleyii açndan önem tayan bu faaliyetin yüzeysel olarak geçilmesi pahalya mal olabilecek riskler tamaktadr. Kontrol listelerinin kullan katmclar yönlendirmesi bakndan pozitif bir etki olarak deerlendirilebilir. Kontrol listelerinin otomatikletirilmesi ise bu kapsamda yüzeysellii derinletiren bir kazanm salar. 1. Yazm Gereksinim Özellikleri ile Sistem Gereksinimleri Arasndaki zlenebilirliin Kontrolü: Kontrol listesinde bulunan Tüm yazm gereksinimleri sistem seviyesi gereksinimleri kapsyor mu? (Are all Requirement allocated to software from the System Specification covered and defined? ) sorunun cevab filtre tanmlayarak verilebilir. Bu kontrolü yaparken her seferinde filtre tanmlamak yerine tek seferde gelitirilen betik uygulamas ile gereksinim özellii olup, sistem seviyesi ile balanmam gereksinimlerin numaralar raporlanabilir ve böylece bulunan eksiklikler kontrol listesine eklenebilir. 2. Gereksinim Olmad Halde Test Türü, Dorulama Yöntemi Gibi Niteliklerin Belirtilmesi: Gereksinim olmayan açklamalarn, baklarn test türü, dorulama yöntemi gibi niteliklerin uygulanabilir olmamasna karn, bu niteliklerin Test, Analiz, Kod nceleme gibi bir nitelie sahip olmas hatalr. Bu tür uyumazlklar doküman bütünlüünü bozan, üst ve alt seviye ile olan balantlar etkileyen faktörlerdir. Bu tür hatalarn olumasndaki tecrübe edilen sebep gereksinimleri gelitirilen kiilerin tanmladklar niteliklerin varsaylan deer olarak unutmalarr. Bu hatalarn düzeltilmesi de betik ile mümkündür. Gereksinim olmayan bir nesnenin test türü ve dorulama yöntemi otomatik olarak istenilen türe çekilebilir. 3. DSB (Daha Sonra Belirlenecektir) ve TBD (to be determined) gibi fadelerin Tespiti: Kontrol listesinde bulunan Gereksinimler tam m, metin içerisinde daha sonra belirlenecektir gibi ifadeler bulunuluyor mu? (Are requirements complete; there are no to be determined remaining in the text? ) sorusunun cevab ve tamamlanmam ihtiyaçlarn projenin tasarm ve dorulama fazlarnda problem olmas önlemesi için betik gelitirilmitir. Bu betik ile daha sonra belirlenecek ihtiyaçlarn gereksinim numaralarn otomatik olarak raporlanmas ve kontrol listesine eklenmesi salanmr. 4. Mulâk fadelerin Tespiti: Kontrol listedinde bulunan Gereksinimlerde mulâk ifadeler bulunuyor mu? (Are requirements free of vague qualifiers? ) sorusu cevaplanmalr. Minimum, maksimum, optimum, mümkünse, olabilir, belki, tüm, en iyi, en kötü, en uygun, biraz, tahminen, uygunsa gibi ifadeler içeren gereksinimler özellikle dorulama aamasnda test edilebilirlii büyük oranda azaltmaktadr. Gereksinimlerde mulâk ifadelerin bulunmas, gereksinimlerin tam, bütün, tutarl ve doru olmas gerekliliine ters dümektedir ve test durumlar gelitiren test mühendisleri için ciddi bir problem oluturur. Gözle yaplan kontrollerde gereksinim sayna ba olarak kontrol için yeteri kadar zaman ayrlmamas durumunda mulâk ifadeler yakalanmayabilir. Bu ifadeler gelitirilen betik ile otomatik olarak tespit edilebilir, inceleme yapan kiinin de deerlendirmesiyle gereksinim numaralar raporlanr ve gereksinimlerin sorumlu kii tarafndan netletirilmesi salanr. 5. Gereksinim Nitelii Olan ve Test Edilemeyen Gereksinimlerin Kontrolü: Proje ekipleri tarafndan gelitirilen ve süreçte tanml modüllerin sahip olduu niteliklerin genel amac yaplan ileri kontrol altna alarak kolaylarmak olsa bile bazen niteliklerin doru kullanlmay projelerde karmakla sebep olabilmektedir. Gereksinim nitelii olan, test türü ve dorulama yöntemi nitelii olmayan gereksinimlerin incelenmesi ve test edilebilirlii konusunda karar verilmesi gereklilii vardr. Bu durumda olan nesnelerin otomatik olarak incelenmesi betik kullanlarak salanmr. Dorulama yöntemi
(Inspection, Analysis, Demonstration, Test) belirlenmemi fakat gereksinim nitelii olan nesneler yine betik kullanlarak Tüm gereksinimler için dorulama yöntemi tanml m? (Is the Verification method identified for each requirement? ) sorusuna cevap olabilir. 6. Aralk Deerlerinin Kontrolü: Yazm test mühendisleri tarafndan gelitirilen test durumlarn koturulmas sonrasnda test sonuçlar incelendiinde kalan testlerin daha çok yazn sr ve/veya sr ndaki deerlerdeki hatal davranlardan kaynakland görülmektedir. Aralk deerlerinin belirtilmemi olmas tasar yapan yazm gelitiricinin kalan senaryoyu düünememi veya unutmu olmasndan kaynakland görülmütür. Yazn çalmas srasnda meydana gelen kritik hatalar ve yazm performansndaki dü aralk deerlerinin, aralk d deerlerin gereksinimlerde net olarak belirtilmesi gerekliliini göstermitir. Bunun önüne geçmek dokümann tümünün bu gözle incelenmesi ile mümkün olsa bile zaman alan bir aktivite olmasndan dolay gereksinim yönetim arac betik dili kullanlarak otomatik yaplmaya çallmr. Kullanlan betik ile aralklar, birimler, aralk d belirtilmemi gereksinimler tespit edilmeye çallm ve gereksinim numaralar raporlanmr. 7. Ksaltmalarn Kontrolü: Ksaltmalar dokümann anlarl, açkl ve profesyonellii bakndan önem tamaktadr. Eksik, yanl veya sras bozuk olarak yazlm ksaltmalar yüzünden doküman inceleyen kii veya kurum tarafndan gereksinimler anlalmayabilir. Binlerce sayfa teknik bir doküman düünüldüünde doküman genelinde kullanlan saltmalarn eksiksiz olarak kontrol edilmesi zaman alacak bir urar. Betik kullanlarak ksaltmalar otomatik olarak incelenerek hatalar düzeltilmek üzere raporlanabilir. 2.2. zlenebilirliin Betik ile Kurulmas zlenebilirlik konusunda günümüze kadar birçok çalma yaplmr. zlenebilirliin doru ve hzl bir ekilde nasl kurulabilecei konusu sklkla karlalan çalmalardr [10, 11, 12, 13, 14]. Bildiride bu çalmalarn detaylarna deinilmemi, izlenebilirliin betik ile nasl kurulabildii (ekil-5) anlatlmr. Sistem seviyesinde gelitirilen sistem gereksinimlerinden yazm gereksinimleri oluturulur. Oluturulan yazm gereksinimleri, sistemin yazm için tanmlad her bir sistem gereksinimini karlamak durumundadr [4]. Yazm gereksinimleri eksiksiz olarak oluturulduktan sonra dorulama metodu ve test türü olan her bir yazm gereksinimi için yazm test durumu gelitirmek gereklidir. Gelitirilen test durumlar ilgili olduu yazm gereksinimine izlenebilir olmalr. Yazm test modülünde bulunan izlenebilirlik niteliinde, yazm gereksinim özellikleri modülündeki ilgili gereksinim numaralar bulunur. Gereksinim özelliklerinin izlenebilirlik niteliinde ise sistem seviyesi gereksinimlerin numaralar bulunur. Gereksinim yönetimi yaplarak balar kurulup ba modülleri oluturulur. Balarn elle kurulmas çok uzun zaman alan bir urar. Bu ihtiyac karlamak için betik gelitirilmitir. Gelitirilen betik kaynak modülde verilen izlenebilirlik niteliinin ad, hedef modülün yolunu ve ad, kaynak modülde izlenebilirlik niteliinde kullanlan öneki parametre alarak balar otomatik olarak kurar. Proje boyutuna göre haftalarca sürebilecek i, dakikalar içerisinde, hatasz olarak gerçekletirilir. Buna ek olarak izlenebilirlik niteliinde hatal olarak girilmi gereksinim numaralar varsa bu hatalar bulur ve bulunan hatalar raporlar. Bu sayede modüller arasnda hatal izlenebilirliin olmad garanti altna alr. Kaynak Modül Bilgileri Hedef Modül-1 Hedef Modül-2 Hedef Modül-n ekil 5: zlenebilirliin Kurulmas Yazm gereksinim veya yazm test modülünden birden fazla modüle ba kurmak gerektiinde, her bir modül için parametreleri ayrca verip betii tekrar koturmak gerekli ve yeterlidir. 2.3. Test Durumlar Gelitirirken Betik Kullan Yazm test mühendisleri tarafndan Test Durumu -1, Test Durumu-2 gibi alt baklar halinde devam eden ve yüzlerce ve hatta bazen binlerce test durumlarndan oluan test modülleri oluturulmaktadr. Her modül içerisinde baklarn ve nesnelerin seviyeleri vardr. lgili ban seviyesine göre bir seviyeden sonraki baklar veya nesne içerii istee göre düzenlenebilir. Test durumlarn arasnda benzerlikler varsa ve test durumlarndaki geçiler birkaç davrann, modun veya mesaja ait alanlarn demesi ile gerçekleiyorsa, test durumlar nesne seviyesi ile birlikte kopyalanarak, yeni test durumlar gelitirilebilir. Yeni test durumlarnda
oluabilecek ve detirilmesi manta dayanan bir geçi bulunuyorsa bu durum betik kullanlarak otomatik hale getirilir. Test durumlarn ve test durumlarna ait test admlarn sralanmas bu geçilere örnek verilebilir. ekil-6 da üçüncü seviyede bir baa (6.1.6) ait olan test durumlar sralanmr. Sral test durumlar test admlarndan oluur. Test durumu 1 kopyalanarak Test durumu 25 in altna konulmak istendiinde Test durumlar sralamas kayacaktr. Test durumlarn baz koullarda sistemin modlarna ba olarak sral olma zorunluluu vardr. Ard ardna koturulmas gereken testlerin olmas, test durumunun gelitirme zamannda unutulmu olmas veya daha sonradan eklenmi bir gereksinimin olmas var olan test durumlar arasna yeni test durumlarn eklenmesine sebep olabilir. Ekleme ilemi tamamlandktan sonra test durumlarna ait baa çift klama ile sralama düzeltilebilir. gereksinimlerinin birbirinden bamsz olarak düünülmesi yapsall ve uygulanabilirlii artr [15]. Tablo-1 de yapsal ara yüz gereksinimlerinin alanlar ve açklamalar gösterilmitir. ID Kaynak Yön Format Durum lk Deer Tablo 1: Yapsal ara yüz gereksinimi Alan Açklama Biricik olmal Gereksinimin kayna Gelen, giden, gelen ve giden Mesaj format Periyodik, ayrk, periyodik olmayan Mesajn ilk deeri Fonksiyonel gereksinimlerin yapsal olarak tanmlanmas da tablo yöntemi ile mümkündür. Tablo- 2 de fonksiyonel gereksinimlerinin alanlar ve açklamalar gösterilmitir. Tablo 2: Yapsal fonksiyonel gereksinimi ekil 6: ral Test Durumlar Alan ID Kaynak Girdiler ktlar Koul Fonksiyon Açklama Biricik olmal Gereksinimin kayna Gereksinimin girdileri Gereksinimin çktlar Gereksinimin koulu Gereksinimin yetenei 2.4. Modül ablonunda Betik Kullan Modüller arasndaki izlenebilirlik betik ile kurulabildii gibi, modüller arasnda sürükle brak ile ba çekilip, daha sonra çekilen balar sergileyen izlenebilirlik kolonu oluturulabilir. Bu ilem srasnda modüller arasndaki izlenebilirlii tutan bir ba modülü oluur. Oluturulan kolon, ba modülü olduu sürece modülde görünürdür. Ba modülünün silinmesi, üzerine yazlmas veya baka bir sebepten kaybolmas durumunda izlenebilirlik kolonu kaybolacaktr. Kolon içeriinin yeni bir nitelie kopyalanmas ve ba modülünden bamsz olarak kullanlmas betik ile mümkündür. 3. Dorulama Sürecinde Gereksinim Yönetiminin Gelecei Yazm gereksinimlerin formal bir dil kullanlarak gelitirilmesi 20 yldr uralan bir çalma alandr. Bu alanda birçok gereksinim gelitirme dili uygulamaya gelitirilmitir. Birçok çalma olmasna, çeitli dillerin gelitirilmesine ramen günümüzde gereksinimler yapsal bir nitelie sahip deildir [15]. Yapsal gereksinimler, bir takm tanml kalplara uyularak gelitirilebilir. Fonksiyonel ve ara yüz Yapsal gereksinimler gelitirilerek dorulama sürecinde kazanabilecek faydalar adaki gibi ralanmr [16]. 4. Sonuç Yapsal gereksinimlerde tanml alanlarn olmas, gereksinimlerin kaynak, yön, ilk deer gibi niteliklerinin unutulmadan eksiksiz olarak yazlmas salar. Gereksinimlerim kiiye baml klarak, gereksinimlerden belirsiz, mulâk, çelien ve anlam bütünlüü olmayan ifadeler temizlenir. Yapsalln verdii kararlkla yazm test durumlarn otomatik olarak gelitirilmesi için bir altyap oluturur. Gereksinimlerin gelitirilmesi, incelenmesi, hatalarn tespiti için daha az i gücü harcanmas salar. Bu bildiride gereksinim yönetiminden bahsedilmi, gereksinim yönetimi araçlarn etkin kullann yazm dorulama sürecinde getirdii kazanmlar anlatlmaya çallmr. Dorulama süreci içerisindeki aktivitelerin betik kullan ile hzlandlabilecei konusunda kazanlan tecrübeler paylalmr.
Test aktivitelerinin DXL betik kullan ve kullanlmadan, yaklak on bin adet gereksinimi bulunun bir yazm gereksinimi doküman üzerindeki baz sonuçlar Tablo-3 de verilmitir. Tablo 3: Elle Yaplan ve Otomatik Test Aktivitelerinin Karlarmas Test Aktiviteleri Elle Otomatik (DXL ile) zlenebilirlik Kurulumu için ~5 ~20 dakika Harcanan Zaman gün Gereksinim Niteliklerinin Kontrolü için Harcanan Zaman ~4 saat ~5 dakika Belirsiz fadelerin Tespiti için Harcanan Zaman ~4 saat ~5 dakika Büyük çapl projelerin ksa sürede tamamlanmas için otomatik kod üretme gibi yazm gelitirme alannda yaplan çalmalarn yazm dorulama alanna da yansmas gerektii düünülmütür. Gereksinimlerin yapsal bir özellik kazanmas bu anlamda atlabilecek önemli bir adm olarak deerlendirilmitir. ASELSAN MGEO bünyesinde yazm test grubu olarak test durumlarn sistem üzerinde otomatik koturulmas salanmr. Test durumlarn otomatik olarak gelitirilmesi ve koturulmas ise yapsal gereksinimlerin yönetimi ile mümkün olaca planlanmr. Workshop on Traceability in Emerging Forms of Software Engineering, Edinburgh, Scotland, 2002. [11] Watson R., Smarter Requirements Management with Intelligent Traceability, White Paper, Telelogic North America Inc., Irvine, CA, 2003. [12] Stehle G., Requirements Traceability for Real-Time Systems, Proceedings of EuroCASE II, London, England, 1990. [13] Egyed A., Gru nbacher P., Automating Requirements Traceability: Beyond the Record & Replay Paradigm, Proceedings of the 17th IEEE International Conference on Automated Software Engineering, Edinburgh, Scotland, 2002. [14] Gotel O., Finkelstein A., An Analysis of the Requirements Traceability Problem, Proc. 1st IEEE International Conference on Requirement Engineering, Colorado, 1994. [15] Cunnig S.J., Rozenblit J.W., Automatic Test Case Generation from Requirements Specifications for Realtime Embedded Systems, Proc. of the 1999 IEEE SMC 99, 1999. [16] Cunnig S.J., Test scenario generation from structural requirements specification, presented at Symposium on Engineering of Computer-Based Systems (ECBS '99), Nashville, TN, USA, 1999. 5. Kaynaklar [1] Berenbach B., Paulish D., Kazmeier J., Rudorfer A., Software & Systems Requirements Engineering: In Practice.McGraw-Hill, 2009. [2] Hoffman M., Kuhn N., Weber M., Bittner M., Requirements for requirements management tools, Proceedings of the Requirements Engineering Conference 12th IEEE International Washington, DC, USA. IEEE Computer Society, 2004. [3] Ghezzi C., Jazayeri M., Mondrioli D., Fundamentals of Software Engineering, Prentice-Hall, 1991. [4] Hilderman V., Baghi T., Avioncis Certification A Complete Guide to D0-178 (Software) D0-254 (Hardware), Avionics Communications Inc., 2007. [5] Everett G. D., McLead R., Software Testing, Testing Across the Entire Development Life Cycle, IEEE Press, Publication., 2007. [6] Wiegers K. E., Software Requirements, Microsoft Press, 1999. [7] IBM Rational Doors 9.2 User s Manual. [8] IBM Rational Doors 9.2 DXL Reference Manual. [9] Özbek M., Kurt A., Gürbüz A., Yazm Projelerinde Gözden Geçirmeleri Baarz Klan Faktörler, Yazm Kalitesi ve Yazm Gelitirme Araçlar Sempozyumu, 2008. [10] Alexander I., Toward Automatic Traceability in Industrial Practice, Proceedings of the 1st International