Yazılım Gereksinim Dokümanı Kalitesinin İşlevsel Büyüklük Ölçümüne Etkisi

Transkript

1 Yazılım Gereksinim Dokümanı Kalitesinin İşlevsel Büyüklük Ölçümüne Etkisi Gökçen Yılmaz Erdir Ungan Onur Demirörs Enformatik Enstitüsü, Orta Doğu Teknik Üniversitesi, 06531, Ankara, Türkiye gokcen, erdir, Özetçe İşlevsel yazılım büyüklüğü, iş gücü ve maliyet kestirimi gibi yazılım proje yönetimi aktivitelerinin en önemli girdisini oluşturmaktadır. Bu nedenle işlevsel büyüklük ölçümlerinin doğruluğu ve güvenilirliği büyük önem taşımaktadır. Ölçümlerin doğruluğu ölçücülerin deneyim seviyesine ve yazılım dokümanlarının niteliğine doğrudan bağlıdır. Bu çalışmada; çoklu bir durum çalışması yaparak ölçümlerde sıklıkla karşılaşılan hataları irdeledik. Bu hatalara neden olan etmenleri inceleyerek, hataları bu etmenlere göre sınıflandırdık. Bu etmenlerin İşlevsel Büyüklük Ölçümlerine (İBÖ) etkilerini araştırdık ve bu etkileri en aza indirmek için bir gözden geçirme yöntemi oluşturduk. 1. Giriş Yazılım Büyüklük Ölçümü iş gücü ve maliyet kestirimi, planlama, proje takip ve izleme ve süreç iyileştirme gibi yazılım proje yönetimi aktiviteleri için temel oluşturmaktadır. İşlevsellik kavramı, 1970 lerin sonunda Albrecht tarafından yazılımların büyüklüğünü ölçmek amacı ile ortaya atıldığından beri yazılım uygulamalarının büyüklüğünü ölçmek amacıyla kullanılan bir yöntem olarak popülerlik kazanmıştır [1]. İş gücü ve maliyet kestirimlerinin doğru yapılabilmesi için, işlevsel büyüklük ölçümlerinin doğruluğu çok önemlidir. Yazılım büyüklük ölçümleri, belirli standartlara göre yapılmasına rağmen ölçümlerin doğruluğu ölçücülerin kalitesi, yazılım dokümanlarının kalitesi ve ölçüm sürecinin kalitesi gibi etmenlere bağlıdır. İşlevsel yazılım büyüklük ölçümü yazılım gereksinim dokümanları temel alınarak gerçekleştirilirler. Ancak yapılan çalışmalarda, aynı doküman için farklı ölçücüler tarafından bulunan ölçüm sonuçlarının farklılık gösterebildiği görülmüştür [5][7][8]. Bu farklılık İBÖ yönteminin, yazılım büyüklüğünü temsil etmesinde sorunlara neden olmaktadır. Ancak, işlevsel büyüklüğü girdi olarak kullanan yazılım yönetimi aktivitelerinin başarılı olabilmesi için yazılım büyüklük ölçümünün tekrarlanabilir ve doğru yapılmış olması gerekmektedir. Bu nedenle işlevsel büyüklük ölçümünün güvenilirliği çok önemlidir. Araştırma grubumuzda, işlevsel büyüklük ölçümlerinde sıklıkla yapılan hataları bulmak ve ölçümlerin doğruluğunu arttırmak için daha önce bir dizi çalışma gerçekleştirilmiştir. Bu çalışmalarda temel odak noktası ölçüm yöntemlerinin yazılım dokümanlarına uygulandığı ölçüm fazı olmuştur. Bu çalışmada da işlevsel büyüklük ölçümlerinde meydana gelen hatalara etki eden faktörler araştırılmaktadır. Ancak, bu sefer, diğer yazılım mühendisliği aktivitelerinin, ölçümlerin doğruluğu üzerindeki etkisi de araştırılmıştır. Çalışmada, işlevsel büyüklük ölçümünün temel girdisi olan yazılım gereksinimlerinin oluşturduğu analiz fazı ve onun çıktılarına odaklanılmıştır. Çalışmada, sıklıkla yapılan hatalar ve bu hataların kaynakları araştırılmıştır. Çalışma sonunda, ölçümlerin doğruluğunu arttırmak için hata önleme ve hata tespit etme olmak üzere iyi boyutta öneriler sunulmuştur. Bu amaçlar doğrultusunda COSMIC İBÖ yöntemi kullanılarak iki basamaklı bir durum çalışması gerçekleştirilmiştir [13]. ISO/IEC [14] tarafından onaylanmış bir yöntem olması ve farklı yazılım alanlarında yöntem ve örneklere sahip olması nedeni ile İBÖ metodu olarak COSMIC seçilmiştir [15]. Durum çalışmasının birinci bölümünde, bir grup katılımcı belirli bir yazılım problemi için yazılım gereksinimlerini araştırarak, yazılım gereksinim dokümanlarını oluşturmuştur. İkinci kısmında ise başka bir grup katılımcı oluşturulan bu yazılım dokümanlarını temel alarak yazılımın işlevsel büyüklüğünü ölçmüşlerdir. Daha sonra bu ölçüm sonuçları değerlendirilmiş ve analiz fazındaki hataların ölçüm sonuçları üzerindeki etkileri araştırılmıştır. Bir sonraki bölüm İBÖ hakkında geçmiş araştırmaları özetlemektedir. Üçüncü kısımda, çalışmanın hedeflerinden bahsedilmiş dördüncü kısımda ise çalışmanın amaçlarını gerçekleştirmek üzere yapılmış olan durum çalışmasının detayları anlatılmıştır. Durum çalışmasının tasarımı, gerçekleştirilmesi ve sonuçları bu bölümde anlatılmıştır. Beşinci bölümde ise çıkarımlar ve sonuçlar verilmiştir. 2. İlgili Çalışmalar Yazılım büyüklük ölçümü araştırmalarının geçmişi boyunca kolay uygulanabilir, tekrarlanabilir, güvenilir, nesnel ve anlamlı bir yazılım ölçüm yöntemi geliştirmek ana hedef olmuştur. Yaygın olarak kullanılan ilk büyüklük ölçümü Kod Satır sayısıdır. Kod Satır sayısı yöntemi ile ölçmek kolay ve nesnel olmasına rağmen, ölçülen büyüklük yazılımın geliştirildiği teknolojiye göre (geliştirme ortamı, kullanılan dil vb.) değişiklik göstermektedir. Bu durum farklı yazılımların büyüklüklerinin karşılaştırılmasında sorun yaratmaktadır [12]. Ayrıca, Kod Satır Sayısı yöntemi ile ölçüm yapabilmek için yazılımın kaynak koduna ihtiyaç duyulmaktadır. Kaynak kod yazılım geliştirildikten sonra ortaya çıktığından Kod Satır sayısı ölçümü yazılım projesinin erken aşamalarındaki yazılım yönetimi gereksinimlerini karşılayamamaktadır. İkinci en çok kullanılan ölçüm yöntemi ise Fonksiyon Nokta Analizidir(FNA). FNA, işlevsel kullanıcı gereksinimlerinin sayısal bir değer ile ifade edilmesini sağlar[11]. FNA ilk olarak 1979 yılında IBM araştırmacısı olan Allan Albrecht tarafından kullanılmıştır [1]. FNA, yazılım proje yaşam döngüsünde daha erken fazlarda kullanılabilmesi nedeni ile Kod Satır Sayısı yönteminden daha popüler bir hale gelmiştir. Ancak FNA, Kod Satır Sayısı yöntemine göre uygulaması daha zor olduğu ve daha az nesnel olduğu için eleştirilmiştir. Herhangi bir ölçüm yönteminin en önemli özelliği güvenilir olmasıdır. İBÖ yöntemini kullanarak ölçülen yazılım büyüklük ölçümlerinin güvenilirliğini arttırmak üzerine birçok araştırma yapılmıştır yılında; Kemerer ve Porter yazılım büyüklüğü ölçümlerinin güvenirliliğini arttırmak amacı ile bir durum çalışması yapmışlardır. Bu durum çalışmasının sonunda az sayıdaki etmenin bile ölçüm sonuçlarını büyük oranda etkilediği görülmüştür. Sonuç olarak Kemerer, yazılım 78

2 büyüklük ölçümünün güvenilirliğini arttırmak için bir prosedür tanımlamıştır [2] yılında Kemerer, E-R yaklaşımı ile işlevsel büyüklük ölçme ve standart IFPUG FSA yöntemi ile işlevsel büyüklük ölçme tekniklerini karşılaştıran bir çalışma yapmıştır. Çalışmanın sonucunda standart IFSUG FSA yaklaşımı, E-R yaklaşımı ile desteklenirse ölçücüler için daha güçlü bir ölçüm yöntemi yaratılmış olacaktır kanısına varılmıştır [3] yılında Abrahao, nesne yönelimli yazılım sistemlerini İBÖ yöntemi ile ölçmeye yönelik araştırmalar yapmıştır. Standart IFPUG yöntemi ve nesne yönelimli FN yöntemi, ISO te [18] bahsedilen tekrar edilebilirlik ve doğruluk kriterlerine göre karşılaştırılmıştır. Bu çalışmanın sonucunda Nesne yönelimli FN yönteminin, standart IFPUG yöntemine göre daha güvenilir olduğu sonucuna ulaşılmıştır [6]. O. Turetken 2008 yılında IFPUG ve COSMIC yöntemlerinin benzer ve farklı yönlerini karşılaştırmak amacı ile çoklu durum çalışması gerçekleştirmiştir. Bu çalışmanın sonucuna göre aynı yazılım uygulaması için farklı grup temel işlevsel bileşenler belirlenebilmektedir [4]. O.Turetken in başka bir çalışmasında ise 3 farklı grup aynı yazılım gereksinim dokümanını ve farklı standartları (COSMIC, IFSUG ve MkII) kullanarak yazılım uygulamasının büyüklüğünü ölçmüşlerdir. Çalışmanın sonucunda ölçüm sonuçları birbirinden farklı olduğu gözlenmiş, bu nedenle farklı yaklaşımların ölçüm sonuçlarında farklılıklara yol açabildiği belirlenmiştir [5] yılında Ö.Ö. Top, yazılım endüstrisinde sıklıkla karşılaşılan hataları tespit etmek ve ölçümlerin güvenilirliğini arttırmak için endüstriyel projelerden faydalanarak çoklu bir durum çalışması gerçekleştirmiştir [7]. Ayrıca, E.Ungan farklı ölçücülerin İBÖ sonuçları arasındaki farklılıkları ortaya koyduğu bir çalışma gerçekleştirmiştir [8] yılında E. Ungan bir önceki çalışmasının devamı olarak ölçümlerde sıklıkla yapılan hataları tespit etmiş ve İBÖ sonuçlarının farklılaşmasına sebep olan etmenleri tespit etmiştir. İBÖ sonuçlarında iyileşme sağlamak için önerilerde bulunmuştur. Çalışmada yapılan önerileri başka bir durum çalışması ile geçerlemiş ve COSMIC ölçümlerinin doğruluğunda ilerleme kaydetmiştir[19]. Ayrıca 2010 yılında Common Software Measurement International Consortium (COSMIC), Guideline for Assuring the Accuracy of Measurements adlı bir standart yayınlanmıştır. Bu standart ölçüm hatalarına sebep olan temel faktörleri vurgulamaktadır. Ayrıca ölçücülerin hata yapmalarını önleyici bazı önemli bilgiler içermektedir [10]. Bütün bu çalışmalar, daha güvenilir ve yararlı ölçüm yöntemleri ortaya çıkarmak ve İBÖ metotlarının daha objektif olmasını sağlamak amacı ile gerçekleştirilmiştir. Önceki çalışmalarımızda bulduğumuz ölçüm hataları ve bireylerin ölçüm sonuçlarındaki farklılıkların kaynaklarını; Ölçüm metotlarını uygulamadaki hatalar ve Yazılım dokümanlarından kaynaklanan hatalar olmak üzere ikiye ayırabiliriz. Bu çalışmada bu iki etkinin ayrı ayrı gözlemlenebilmesi hedeflenmiştir. 3. Çalışmanın Amacı Bu çalışmanın amacı üç bölüm altında toplanabilir: Yazılım gereksinim analizinin işlevsel büyüklü ölçümünün verimliliği üzerindeki etkisini araştırmak, COSMIC ölçümleri sırasında meydana gelen ortak hataları saptamak, Ölçüm hatalarının oluşmasını önlemek ve ölçümlerdeki hataları bulmaya yardımcı olmak üzere bir kontrol listesi hazırlamak Analiz Aktiviteleri Kalitesinin İBÖ Verimliliğine etkisi Yazılım büyüklük ölçüm yöntemlerinin ana hedefi, yazılım büyüklüğünün nicel olarak ifade edilmesidir. Farklı ölçüm yöntemleri, yazılım büyüklüğünü temsil etmek için farklı yazılım yaşam döngüsü kavramlarını kullanmaktadır. Örneğin, kod satır sayısı tabanlı ölçümler, yazılım kaynak kodunu, Nesne Puan ve benzeri tasarım büyüklük ölçümleri ise tasarım verilerini (UML grafikleri, iş modelleri vb.) temel almaktadır. İBÖ yöntemlerinde ise genellikle yazılım gereksinim dokümanı (YGD) temel alınarak yapılmaktadır. Başka bir deyişle, yazılım gereksinim dokümanının büyüklüğü, yazılım probleminin büyüklüğü olarak tanımlanır. Ancak, gereksinim dokümanı, gereksinim belirleme ve veri analizi gibi aktivitelerin sonucunda oluşturulmaktadır. Bu aktivitelerin yetersiz olması ölçüm sonuçlarını olumsuz yönde etkilemektedir. Yazılım problemi ile yazılım modeli arasındaki bu boşluk İBÖ yönteminin yazılım büyüklüğünü ölçmedeki etkinliğini azaltabilmektedir. Bu durumlardan ayrı olarak; ölçüm kurallarının yazılım gereksinim dokümanına uygulanması sırasında da hatalar meydana gelmektedir. Bu; hatalar gereksinim tanımlama ve büyüklük ölçümü arasında başka bir boşluk oluşturmaktadır. Şekil 1, işlevsel büyüklük ölçüm sürecindeki bu kavramsal boşlukları göstermektedir. Bu çalışmada, gereksinim dokümanındaki hataların işlevsel büyüklük ölçümü üzerindeki etkilerini araştırıyoruz. Analiz fazından kaynaklanan ölçüm hataları (Boşluk1) ve ölçüm fazından kaynaklanan ölçüm hatalarını (Boşluk2) karşılaştırmayı hedefliyoruz. Hedeflenen Nicel Karşılık Gereksinim Oluşturma Yazılım Problemi Boşluk 1 YGD Boşluk 2 Ölçüm (İşlevsel Büyüklük) Boşluk 1 Veri Analizi Şekil 1 İşlevsel Büyüklük Ölçümü Genel Bakış 79

3 3.2. COSMIC Ölçümlerinde Yapılan Ortak Hatalar Önceki çalışmalarımızda [7][8], ölçüm sonuçlarında gözlenen farklılıklar aşağıdaki gibi kategorize edilmiştir: Ölçüm yöntemi hakkında eksik bilgi, Gereksinim dokümanı oluşturulurken yapılan varsayımlar, Basit hatalar. Benzer olarak, yeni yayınlanmış olan COSMIC Guideline for Assuring the Accuracy of Measurements [10] dokümanında COSMIC ölçüm doğruluğunu etkileyen faktörler üç ana başlık altında tanımlanmaktadır: Ölçücünün kalitesi, Yazılım dokümanlarının kalitesi, Ölçüm sürecinin kalitesi. Bu çalışmada, bu faktörlere dayanan hatalar bulunmaya çalışılmıştır. Bu hatalar Şekil 1 de gösterilen gereksinim dokümanı ile işlevsel büyüklük ölçümü arasındaki boşluğu oluşturmaktadır Ölçüm hatalarını önlemek ve tespit etmek için kontrol listesi COSMIC Guideline for Assuring the Accuracy of Measurements [10] yazılım büyüklük ölçümlerinin kalitesini arttırmak için bazı güvence etkinlikleri içermektedir. Kalite güvence etkinlikleri Hata- Tespiti ve Hata-Önleme olmak üzere ikiye ayrılır. Bu kontrol mekanizmalarının her ikisi için de birer kontrol listesi hazırlanmıştır. Hata Önleme kontrol listesi COSMIC metodunun [13] önemli noktalarını özetleyip, ölçülecek dokümanların içermesi gereken bilgileri vurgulamaktadır. Hata-Tespiti kontrol listesi, COSMIC ölçümleri sırasında sıklıkla yapılan hataları önlemek amacı ile oluşturulmuştur. Bu çalışmanın amaçlarından biri de, endüstride uygulanacak yazılım büyüklük ölçümleri için hızlı çözümler sunabilecek detaylı bir kontrol listesi oluşturmaktır. Kontrol listeleri oluşturulurken COSMIC Guideline for Assuring the Accuracy of Measurements [10] standardı referans olarak alınmıştır. Hata-Tespiti konusunda otomasyon fırsatları ise ilerideki çalışmalarda incelenecektir. 4. Durum Çalışması Çalışmada gerçekleştirilen durum çalışması iki basamaktan oluşmaktadır. Birinci basamakta, bir grup katılımcıya müşteri gereksinimleri verilmiştir. Bu katılımcılardan, müşteri gereksinimlerine göre yazılım gereksinim dokümanını hazırlamaları istenmiştir. Çalışmanın ikinci basamağında; ilk basamakta oluşturulan gereksinim dokümanlarından en iyisi, ikinci bir grup katılımcıya verilmiştir. Bu katılımcılardan yazılım gereksinim dokümanına göre COSMIC metodunu kullanarak yazılımın işlevsel büyüklüğünün ölçmeleri istenmiştir. Bu bölüm durum çalışmasının tasarım, hazırlık, yürütme ve değerlendirme gibi detaylarını içermektedir. Ancak ana vurgu çalışmanın hedeflerine uygun olarak, durum çalışmasının ikinci basamağına olacaktır. Çalışmanın amacı yazılım analizindeki hataları tespit etmekten ziyade, büyüklük ölçümündeki hataları tespit etmek olduğundan, yazılım gereksinim dokümanının hazırlanışı ve seçme sürecinin detayları bu bildiri için kapsam dışında bırakılmıştır Durum Çalışmasının Tasarımı Gereksinim analiz aktivitesinin kalitesinin COSMIC ölçümüne etkisini araştırmak üzere; ölçüm sürecine müşteri gereksinimlerinden yola çıkarak başlanmış ve gereksinim analizini başka bir adım olarak durum çalışmasına eklenmiştir. Bölüm 3,1 de anlatıldığı üzere analiz fazındaki hataların (Boşluk1) ve ölçüm fazındaki hataların (Boşluk2) belirlenmesi hedeflenmiştir. Bunun için, katılımcı ölçümlerinin iki farklı referans cevap anahtarı ile karşılaştırması planlanmıştır. Öncelikle ölçüm uzmanlarından oluşan bir grup, adım 1 in sonunda oluşturulmuş gereksinim dokümanını ölçerek bir cevap anahtarı oluşturmuştur (Cevap Anahtarı 2). Katılımcıların ölçüm sonuçları bu cevap anahtarı referans alınarak değerlendirilmiştir. Bu değerlendirmede ölçüm fazında meydana gelen hatalar (Boşluk 2) tespit edilmiştir. Bunun yanı sıra, aynı ölçüm uzmanları, müşteri gereksinimlerinden başlayarak bütün süreci yeniden işletmiş ve aynı müşteri gereksinimlerinden kendi yazılım gereksinim dokümanlarını oluşturmuştur. Daha sonra bir kez de bu dokümana göre ölçüm gerçekleştirmiş ve ayrı bir cevap anahtarı oluşturmuşlardır (Cevap anahtarı 1). Katılımcıların ölçümlerinin doğruluğu bir kez de bu anahtar referans alınarak değerlendirilmiştir. Bu, değerlendirme, sürecin en başından itibaren geçilen aşamaları içeren bir kıyaslama olduğundan, hem analiz fazında (Boşluk 1) hem de ölçüm fazında (Boşluk 2) oluşan hatalar tespit edilmiştir. Analiz ve ölçüm fazında oluşan hataların etkilerini ayrıştırabilmek ve karşılaştırabilmek amacı ile bu iki değerlendirmede ortaya çıkan hata oranları karşılaştırılmıştır. Şekil 2, çalışmanın akışını ve sonuçlar için kullanılan değerlendirme temellerini göstermektedir Durum Çalışmasının Yürütmesi Adım 1: Gereksinim Dokümanının Hazırlanması Durum çalışmasının birinci basamağında; müşteri gereksinimi olarak gerçek bir yazılım problemi betimlenmiştir. Katılımcılara bir gereksinim taslağı verilmiştir. Problemi analiz etmeleri ve kullanım durumlarını da içeren bir yazılım gereksinim dokümanı oluşturmaları istenmiştir. Sözü geçen yazılım, web tabanlı bir İnsan Kaynakları ve İş Emri Yönetim Sistemi dir. Sistem 4 kullanıcı tipini desteklemekte ve çalışan bilgilerini, iş emirlerini, iş gücü kayıtlarını, eğitim ve seminerleri, duyuruları yönetmekte ve raporlamaktadır. Katılımcılar Orta Doğu Teknik Üniversitesi Enformatik Enstitüsü Bilişim Sistemleri yüksek lisans programı öğrencileridir. Katılımcıların en iyi performanslarını gösterdiklerinden emin olmak için bu alıştırma aynı zamanda notlandırılmıştır. Katılımcılar 4 er kişilik 5 grup oluşturmuşlardır. Daha sonra katılımcılara, İnsan Kaynakları ve İş Emri Yönetim Sistemi hakkında temel bilgiler içeren teknik olmayan bir müşteri gereksinim taslağı verilmiştir. Taslak, kullanıcı bakış açısından gerekli işlevsellikleri içermektedir. Bu taslağa göre, katılımcılardan analiz gerçekleştirerek yazılım gereksinim dokümanı hazırlamaları beklenmiştir. Gerçek bir yazılım yaşam döngüsü adımlarını takip etmek için, her YGD başka bir grup tarafından denetlenmiş ve bulgular sonucunda gerekli değişiklikler dokümanlara yansıtılmıştır. Oluşturulan bu YGD ler COSMIC ölçüm uzmanları tarafından karşılaştırılmış ve en güvenilir ve tutarlı olan doküman büyüklük ölçümü için seçilmiştir. Karışıklığı önlemek amacı ile bu YGD, bu çalışmada Üretilmiş YGD (Ü- YGD) olarak adlandırılmıştır. 80

4 Şekil 2 Durum Çalışmasının Akışı Daha sonra, aynı İnsan Kaynakları ve İş Emri Yönetim Sistemi gereksinim taslağından yola çıkarak yazarların ve COSMIC ölçüm uzmanlarının da içinde bulunduğu bir grup uzman ikinci bir YGD oluşturmuştur. Bu YGD bu çalışmada Referans YGD (R- YGD) olarak isimlendirilmiştir. Ü-YGD işlevsel ve işlevsel olmayan gereksinimleri içermektedir. Dokümanda kullanıcı ara yüzleri, UML sınıf diyagramı şeklinde oluşturulmuş basit bir veri analizi ve kullanım durumları bulunmaktadır. R-YGD, kullanım durumu ve kullanıcı ara yüzlerinin yanında daha detaylı bir veri analizi içermektedir. Ü- YGD ana iş nesnelerini gösteren bir sınıf diyagramı içerirken R-YGD 3. Normal Formda bulunan bir varlık ilişki (E-R) diyagramı içermektedir. Ek olarak kullanılan Ü-YGD üretilenleri arasında en iyisi olmasına rağmen, sınıf diyagramı ve kullanım durumları arasında çelişkiler bulunmaktadır. R-YGD, Ü-YGD ye göre daha net ve daha tutarlıdır. R-YGD de belirtilmiş olan bazı işlevselliklerin Ü- YGD de bulunmadığını tespit edilmiş, farklı bir deyiş ile Ü-YGD de bahsedilen işlevselliklerin R-YGD dekilerin bir alt kümesi olduğu belirlenmiştir. Ayrıca, Ü-YGD de geçen kullanım durumları R-YGD de geçenlerden daha az detaylıdır Adım 2: Ölçüm Durum çalışmasının ikinci basamağında; çalışmanın birinci basamağında elde edilmiş olan Ü-YGD bir grup katılımcı tarafından ölçülmüştür. Ortak hataları bulmak amacı ile bu ölçümler toplanmış ve değerlendirilmiştir. Ü-YGD de belirtilmemiş bir özelliğin ölçümde kullanılmasını engellemek amacı ile çalışmanın ikinci adımı için birinci adımdaki katılımcılardan farklı katılımcılar seçilmiştir. Bu durum yazılım gereksinim dokümanlarının ölçüm üzerindeki etkilerinin incelenebilmesine olanak sağlamaktadır. Ayrıca, endüstride analiz çalışması ve büyüklük ölçümü farklı kişiler tarafından gerçekleştirilmektedir. Çalışmanın ikinci basamağında, ölçümü gerçekleştiren kişilerin, analizi yapan kişilerden farklı seçilmesine rağmen, katılımcı profillerinin yakın olmasına gayret edilmiştir. İkinci adımı gerçekleştiren katılımcılar aynı üniversite ve bölümden bir başka dersin öğrencileri arasından seçilmiştir. İki gurubun endüstri ve akademik bilgi birikim seviyeleri çalışmayı etkilemeyecek derecede yakındır. Ölçümden önce, Ü-YGD ve R-YGD nin her ikisi de COSMIC ölçüm uzmanları tarafından tartışılmış ve ölçülmüştür. Bu sonuçlar yazarlar tarafından gözden geçirilmiştir. Ü-YGD ve R-YGD nin uzmanlar tarafından ölçümlerine sırasıyla Cevap anahtarı 1 ve Cevap Anahtarı 2 adları verilmiştir ve bunlar katılımcıların ölçümlerini değerlendirirken temel oluşturmuşlardır. Uzmanlarca yapılan ölçümlere göre, R-YGD ölçümü 83 fonksiyonel süreç ve 366 veri hareketi içerirken, Ü- YGD 55 fonksiyonel süreç ve 259 veri hareketi içermektedir. Cevap anahtarı 1 ve Cevap Anahtarı 2 arasındaki Fonksiyonel Süreç (FS) ve Veri Hareketi (VH) farkları sırası ile 28 ve 107 dir. Bu farkların çoğu Ü-YGD de belirtilmeyen işlevselliklerden kaynaklanmaktadır. Ölçümden önce; katılımcılara 3 saatlik ders ve etkileşimli bir çalıştay içeren COSMIC eğitimi verilmiştir. Çalıştay sonunda katılımcılara ölçmeleri için küçük bir pilot proje verilmiştir. Bu ölçümler sonucunda %60 ın üzerinde başarı gösteren öğrenciler katılımcı olarak seçilmiştir. Katılımcılar 3 er kişilik 2 grup oluşturmuşlardır. Daha sonra her iki gruba da aynı İnsan Kaynakları ve İş emri Yönetim Sistemi nin Ü-YGD si ölçüm için verilmiştir. COSMIC yöntemi kullanılarak katılımcılardan sitemin ölçülmesi istenmiştir. Ölçümler; COSMIC ve IFPUG yöntemleri ile ölçüm gerçekleştirmeyi kolaylaştıran CUBIT adlı program kullanılarak gerçekleştirilmiştir. [16] Katılımcıları zaman baskısından kurtarmak amacı ile ölçüm için bir hafta verilmiştir ve katılımcılar bir hafta sonunda CUBIT ölçüm raporlarını teslim etmişlerdir. İkinci adım da katılımcıların tam katılımını sağlamak amacı ile notlandırılmıştır. Ölçüm raporlarının toplanmasından sonra, her ölçüm öncelikle Ü-YGD nin cevap anahtarına (Cevap 81

5 Anahtarı 1) göre daha sonra da R-YGD nin cevap anahtarına (Cevap Anahtarı 2) göre değerlendirilmiştir. Her katılımcının ölçüm rapor, Ü-YGD cevap anahtarına göre birden fazla kez kontrol edilmiştir. Her bir ölçüm dokümanında öncelikle Fonksiyonel Süreç, daha sonra da Veri Hareketleri kontrol edilmiştir. İkincil olarak ilgi nesneleri kontrol edilmiş ve son olarak da sıklıkla yapılan hatalar tespit edilmeye çalışılmıştır.. Aynı adımlar, R-YGD cevap anahtarı (Cevap anahtarı 1) kullanılarak da gerçekleştirilmiştir. Ölçüm raporlarını bu şekilde tekrar tekrar gözden geçirmek hataların sınıflandırılmasına yardımcı olmuş ve hataların oluşumundaki olası benzerliklerin görülmesini sağlamıştır. 5. Bulgular Yukarıda bahsedilen hatalar, COSMIC Guideline for Assuring the Accuracy of Measurements [10] standardında bahsedilen hata sebeplerine dayanarak kategorize edilmiştir. Ölçücünün Kalitesi Sayılmış bir FS nin tekrar sayılması, Ölçülmüş bir Veri Hareketinin birden fazla kullanımı, Seç, Ara, Kaydet, Bul gibi operasyonların farklı bir FS olarak tanımlanması, Aynı VH nin birden fazla kez sayılması, Sistem sınırları içerisindeki veri hareketlerinin de ölçülmesi, CRUDL (Create-Retrieve-Update-Delete-List) (Oluştur, Getir, Güncelle, Sil, Listele) operasyonlarının birleştirilmesi, Açılır listenin düzgün kullanılmaması, Kullanıcı ara yüzü parçalarının ve sistem kullanıcılarının ilgi nesnesi (OOI) olarak değerlendirilmesi, Aynı Kullanıcı Gereksinimine ait birleştirilmiş FS ler, VH nin ilgisi olmayan bir ilgi nesnesi (OOI) ile ilişkilendirilmesi, Fazladan varsayılan işlevsellikler. Yazılım Dokümanlarının Kalitesi Bir ilgi nesnesinin özniteliği olmayan veriler kullanılması, İlgi nesnelerinin alt varlıklarının unutulması, Veri analizinde ve İlgi Nesnesi belirlenmesinde hatalar. Ölçüm Sürecinin Kalitesi Güncelleme/Silme öncesi Listeleme işlevsel süreçlerinin unutulması, Güncelleme Öncesi Detaylı sorgulama işlevsel sürecinin unutulması, Listeleme işlevsel sürecini Güncelleme/Silme işlevsel sürecinin bir parçası olarak tanımlama. Her faktör için hataların COSMIC büyüklük karşılıkları toplanmış ve toplam hatalar içindeki yüzdelik dilimleri hesaplanmıştır. Tablo 1 hataların COSMIC büyüklüklerini ve bölüm 3,1 de anlatılan iki bilgi boşluğundan kaynaklanan hata sebeplerini özetlemektedir. Aşağıdaki Tablo 1, katılımcının toplam hatalı VH sayılarını göstermektedir. Cevap Anahtarı 1, uzmanlarca yazılmış Gereksinim Dokümanı üzerinden uzmanlarca yapılmış ölçüme göre hazırlanmıştır. Cevap Anahtarı 2 ise, katılımcıların hazırladığı Gereksinim Dokümanı üzerinden uzmanlarca yapılmış ölçüme göre hazırlanmıştır. Bu nedenle, Cevap Anahtarı 2 ye göre yapılan değerlendirmeler, Boşluk 2 den kaynaklanan hataları, Cevap Anahtarı 1 e göre yapılan değerlendirmeler ise hem Boşluk 1 hem de Boşluk 2 den kaynaklanan hataları göstermektedir. Bu yüzden, bu iki cevap anahtarına göre bulunan hatalar arasındaki farklılık, Boşluk 1 den kaynaklanan hataları yani, yazılım probleminden yazılım gereksinimlerini oluşturma sırasındaki hataları vermektedir. Hata Sebebi CFP Karşılığı Cevap Anahtarı 2 Cevap Anahtarı 1 Tüm Hatalar İçindeki Oranı CFP Karşılığı Tüm Hatalar İçindeki Oranı Ölçücünün Kalitesi ,44% ,68% Yazılım Dokümanının Kalitesi ,69% ,92% Ölçüm Sürecinin Kalitesi ,87% ,40% Toplam ,00% ,00% Tablo 1 Hata büyüklüğü ve hata sebepleri Verilerden de görülebileceği gibi, Cevap Anahtarı 1 e göre yapılan değerlendirmede çok daha fazla hata bulunmuştur. Bu fark katılımcılar tarafından hazırlanan Gereksinim Dokümanındaki eksikliklerden kaynaklanmaktadır. Dikkat çekici bir diğer nokta da, katılımcıların hazırladığı Gereksinim dokümanı temel alınarak yapılan ölçümlerde dokümandan kaynaklanan hatalar %20 seviyesindeyken, uzmanların hazırladığı Gereksinim Dokümanı ile yapılan karşılaştırmada bu hataların oranı %50 yi geçmektedir. Bu durum, Gereksinim Dokümanlarının kalitesini yükseltmenin, ölçüm doğruluğunu arttırmakta diğer bütün etmenlerden daha önemli olduğunu göstermektedir. 6. Çalışmanın Kısıtları Çalışma tek bir yazılım gereksinim dokümanı üzerinde gerçekleştirildiğinden, sonuçların daha büyük veya farklı projelere genelleştirilip genelleştirilemeyeceği araştırılmalıdır. Ancak bulunan sonuçlar diğer çalışmalarımızda elde edilen sonuçlar ile benzerlik göstermektedir. 82

6 Çalışmada uzman ölçücüler yerine, deneyimsiz ölçücüler kullanılmıştır. Bu durum, deneyimli ölçücülere kıyasla daha büyük oranda hata oluşmasına neden olmuş olabilir. Uzmanlar tarafından oluşturulan yazılım gereksinim dokümanında (R-YGD) ve bu dokümana göre yapılmış olan büyüklük ölçümünde de (Cevap Anahtarı 1) hatalar bulunabilir. Çalışmada, bu gereksinim dokümanı ve cevap anahtarı hatasız ve referans olarak kabul edilmiştir. Büyüklük ölçümü yapılmadan önce katılımcılara verilen COSMIC eğitiminin süresi yeterli görülmeyebilir. Ancak endüstride benzeri hizmet içi eğitimler benzeri sürelerde verilmektedir bu nedenle verilen eğitimin çalışmanın amacını kısıtlayıcı bir etmen olduğu düşünülmemektedir. 7. Sonuç Durum çalışmasının sonuçlarına göre katılımcıların ölçümlerindeki Veri Hareketi ve İşlevsel süreçler Cevap anahtarı 1 ve Cevap anahtarı 2 ye karşılaştırıldığında aralarında büyük farklar bulunmaktadır. Bu farkın sebebi yazılım gereksinim dokümanlarının yetersiz olmasıdır. Sektörde geliştirilen çoğu uygulamanın yazılım dokümanlarının durumu durum çalışmasındaki gibidir. Genellikle, yazılım dokümanları işlevsel büyüklük ölçümü hakkında bilgi seviyesi yetersiz kişilerce hazırlanmaktadır ve bu durum ölçüm sonuçlarını olumsuz yönde etkileyebilmektedir. Hazırlanan yazılım dokümanları, büyüklüğü ölçülen sistemi gerektiği şekilde yansıtmazsa, sistemin büyüklüğü sağlıklı bir şekilde belirlenemez. Bu durumu ortadan kaldırmak için yazılım dokümanları, işlevsel büyüklük hakkında bilgi sahibi olan kişiler tarafından oluşturulursa ölçüm sonuçları daha güvenilir olarak bulunabilir. Durum çalışmasında belirtilen sıklıkla yapılan hataların yapılmaması için ölçüm yapan kişilerin ölçüm yönteminde iyi eğitilmiş olmaları da ayrıca önemlidir. Bazı ölçüm örnekleri COSMIC Guideline for Sizing Business Application Software kılavuzunda belirtilmiştir [17]. Çalışma sonunda, ölçüm sürecinin sonunda daha güvenilir ve daha doğru ölçümler elde etmek amacı ile bu çalışma ve önceki çalışmalarda bulunan ve COSMIC güvenilirlik kavuzunda belirtilen en sık yapılan hataları birleştirerek bir kontrol listesi oluşturulmuştur. Ölçüm sürecinden önce ve sonra kullanmak koşulu ile bu yöntemler Hata-Tespiti ve Hata-Önleme olarak ikiye ayrılmıştır. Hata Önleme: Ölçüm sırasında hata meydana gelmemesi için, yazılım dokümanlarının, ölçücülerin ve ölçüm sürecinin kalitesinin arttırılması gerekmektedir. Ölçümü yapan kişiler yazılım dokümanlarının anlaşılırlığından doğan hataları engellemek amacı ile Yazılım Gereksinim Dokümanını ölçüm amaçlarına uygunluğu açısından gözden geçirmelidir. Ölçüm yapan kişilerin kalitesi ise COSMIC eğitimleri ile ve ölçme konusunda deneyim kazanmaları ile arttırılabilir. Son olarak, ölçüm sürecinin kalitesi, ölçüm için hazırlanmış bir araç kullanarak, arttırılabilir. Hata-Tespiti: Bu yöntem ile sıklıkla karşılaşılan hataların ölçüm sonuçlarındaki varlığı kontrol edilir ve bu sayede ölçüm gerçekleştikten sonra ölçümün doğruluğu arttırılır. Kontrol Listesi: Hata Önleme: 1. Yazılım dokümanı yazılımın amacını içeriyor mu? 2. Fonksiyonel kullanıcılar yazılım dokümanında belirtilmiş mi? 3. Bütün fonksiyonel gereksinimler belirtilmiş midir? Bu gereksinimler anlaşılır ve nesnel midir? 4. Kullanım durumları gereksinimleri tam olarak yansıtıyor mu? a. Eksik kullanım durumu bulunuyor mu? b. Kullanım durumları anlaşılır mı? 5. E-R (Varlık ilişkileri) diyagramı kontrol edildi mi? (3. Normal Form da mı?) 6. E-R diyagramı ile kullanım durumlarında belirtilen varlıklar arasında herhangi bir tutarsızlık bulunuyor mu? 7. Ölçümü yapacak kişiler COSMIC (veya kullanılan diğer bir ölçüm yöntemi) eğitimi aldılar mı? (Ölçüm deneyimleri var mı?) 8. Ölçüm amacı net olarak belirlendi mi? 9. Ölçümün kapsam ve katmanları net bir şekilde tanımlandı mı? Hata-Tespiti: Bulgular bölümünde; Ölçücünün Kalitesi, Yazılım dokümanının kalitesi, Ölçüm sürecinin kalitesi başlıkları altında vurgulanan faktörlerin varlığı kontrol edilmelidir. (Örn. Seç, Ara, Kaydet, Bul gibi operasyonların farklı bir FS olarak tanımlanmış mıdır? ) 8. Kaynakça [1] Albrecht, A. J., October 1979, Measuring application development productivity, in Proceedings of IBM Applications Development Symposium, Monterey, California. [2] Kemerer, C.F., Porter, B.S., Nov "Improving the Reliability of Function Point Measurement: An Empirical Study," IEEE Transactions on Software Engineering, vol. 18, no. 11, pp [3] Kemerer, C F, 1993, Reliability of function points measurement: a field experiment Comm. ACM 36 (2). [4] Turetken, O., Demirors, O., Ozcan Top, O., & Ozkan, B., 2008, The Effect of Entity Generalization on Software Functional Sizing: A Case Study, A. Jedlitschka and O. Salo (Eds.): PROFES 2008, LNCS 5089, pp , Springer-Verlag Berlin Heidelberg. [5] Turetken, O., Ozcan Top, O., Ozkan, B., Demirors, O., 2008, The Impact of Individual Assumptions on Functional Size Measurement. R. Dumke et al. (Eds.): IWSM / MetriKon / Mensura 2008, LNCS 5338, pp Springer Berlin Heidelberg [6] Abrahao S, Poels G, Pastor O., 2004, Assessing the reproducibility and accuracy of functional size measurement methods through experimentation, Proceedings ISESE

7 [7] Top, O.O., Demirors, O., Ozkan, B., 2009, Reliability of COSMIC Functional Size Measurement Results: A Multiple Case Study on industry Cases, Software Engineering and Advanced Applications, SEAA '09. 35th Euromicro Conference, pp , Aug [8] Ungan, E., Demirors, O., Top,O O., Ozkan B., 2009, An Experimental Study on the Reliability of COSMIC Measurement Results, Software Process and Product Measurement, pp , Springer Berlin / Heidelberg. [9] Fenton, N.E. and Pfleeger, S.L., 1996, Software Metrics: A Rigorous and Practical Approach, Second Edition, International Thomson Computer Press. [10] The Common Software Measurement International Consortium (COSMIC):Guideline for Assuring the Accuracy of Measurements, 2011, Version 1.0. [11] ISO/IEC : Information Technology Software Measurement - Functional Size Measurement - Part 1: Definition of Concepts 1998, updated in 2007 [12] Gencel, Ç., Buglione, L., Demirors, O., Efe, P., 2006, A Case Study on the Evaluation of COSMIC-FFS and Use Case Points 3rd Software Measurement European Forum (SMEF 2006), pp [13] The Common Software Measurement International Consortium (COSMIC): COSMIC Method, 2009, Version 3.0.1, Measurement Manual. [14] ISO/IEC 19761: COSMIC Full Function Points Measurement Manual, 2003, v [15] [16] [17] The Common Software Measurement International Consortium (COSMIC): Guideline for Sizing Business Applications Software Using COSMIC- FFS, 2005, Version 1.0. [18] ISO/IEC TR : Information Technology Software Measurement - Functional Size Measurement - Part 3: Verification of Functional Size Measurement Methods, [19] Ungan, E., Demirors, O., Top,O O., Ozkan B., 2010, Evaluation of Reliability Improvements for COSMIC Size Measurement Results, IWSM / MetriKon / Mensura, Stuttgart, Germany 84