Özet. Maliyet ve bütçe tahminleri, süreç kıyaslama ve proje kontrolü gibi yazılım proje yönetimi aktivitelerinin pek çoğu yazılım işlevsel büyüklük ölçümlerine bağlı olduğu için bu değerin ölçümü ve güvenilirliği çok önemlidir. Bu sebeple, İşlevsel büyüklük ölçümlerin güvenilirliğini artırmak için, ölçüm sürecinin sonunda büyüklük dokümanları kontrol edilmeli ve gözden geçirilmelidir. Ancak, ölçümlerdeki hataları tespit etmek için yapılan ve kişilere bağlı olan manüel gözden geçirme yöntemi zaman ve emek alıcı bir işlemdir. Ayrıca ölçümlerde var olan hataları gözden kaçırma olasılığı da bulunmaktadır. Bu tür sorunları aşmak için, büyüklük dokümanlarını otomatik olarak kontrol eden bir araç geliştirilmesine ihtiyaç vardır. Bu amaçla, bu çalışmada günümüzün en çok kullanılan COSMIC İşlevsel Büyüklük Ölçüm yöntemi için bir yazılım aracı, R-COVER geliştirilmiştir. Bu makalede, bu aracın geliştirilme süreci ve aracın hataları doğru olarak tespit etme açısından verimliliğini gösteren vaka çalışmalarının ilk sonuçları sunulmuştur. Araç ilk olarak Yönetim Bilişim Sistemleri projeleri için geliştirilmiş olup, ileride yapılacak güncellemeler ile gerçek zamanlı ve gömülü sistem yazılımları gibi pek çok yazılım türüne yönelik kullanılabilecektir.
Yazılım proje aktiviteleri ve planları büyüklük ölçümlerine dayandığı için ölçümlerin
güvenilir ve doğru olması çok kritiktir. Ölçüm sonuçlarının kalitesini artırmak için
araştırmacılar, ölçüm sonuçlarındaki tekrarlanabilirliği arttıran yeni kılavuzların
oluşturulması [
Ölçümlerdeki hataların tespiti için gerekli süreyi azaltmak, ölçüm doğrulamayı
standardize etmek, hataların gözden kaçma olasılığını ortadan kaldırarak, insan
kaynaklı ölçüm hatalarını önlemek için bu hataları otomatik olarak yakalayan ve ölçüm
yapan uzmanları yönlendiren özel bir araca gereksinim vardır. Literatürde, COSMIC
İBÖ [
Bu araştırmada, bu amaçla geliştirdiğimiz "R-COVER Aracı" geliştirme
faaliyetleri ve sonuçları sunulmuştur. Hata tespiti yapılacak yazılım cinsleri için öncelikle hata
kategorileri belirlenmiş ve bu Hata Kategorilerine (HK) bağlı olarak [
Çalışmanın geri kalanı şu şekilde düzenlenmiştir; bölüm 2’de ilgili literatür araştırmaları özetlenmiş, bölüm 3’te ise çalışmanın amaçları ve yapılan vaka çalışması verilmiştir. Vaka çalışmalarının sonuçları bölüm 4’te sunulurken, çalışmanın geçerliliğini tehdit eden faktörler bölüm 5’te anlatılmıştır. Son olarak sonuçlar ve gelecekte yapılabilecek olası çalışmalar ise bölüm 6'da verilmektedir. 2
Yazılım büyüklüğünü ölçmek için kullanılan metriklerden birisi olan Fonksiyon
Nokta, 1979 yılında Albrecht tarafından öne sürülmüştür [
COSMİC İBÖ son yıllarda sıklıkla kullanılan büyüklük ölçüm yöntemlerinden
biridir. Şuanda ISO tarafından onaylanmış 5 adet yöntem bulunmaktadır. Bunlar;
ISO/IEC 19761 (ISO/IEC, 2003b), ISO/IEC 20926 [
Mevcut veri tabanımızda, aracın hata tespit doğruluğunu belirlemek için yapılacak
olan durum çalışmasında kullanılabilecek COSMIC İBÖ metodu ile ölçülmüş çok
sayıda projeye ait ölçüm dokümanları bulunmaktadır. Bu nedenle çalışma kapsamında
popüler, tüm yazılım tipleri için uygulanabilir ve dünyaca kabul edilen son
metotlardan biri olarak COSMIC İBÖ yöntemi [
COSMIC İBÖ’mü ile yazılım gereksinim dokümanı temel alınarak yazılımın
işlevselliği ölçülür. COSMIC İBÖ’nün Fonksiyonel Kullanıcı Gereksinimi (FKG),
Fonksiyonel Süreç (FS), Veri Hareketi (VH), İlgi Nesnesi (İN), Veri Grubu (VG) ve Veri
Özniteliği (VÖ) olmak üzere 6 ana bileşeni bulunmaktadır. Yönteme göre bu
bileşenlerden VÖ’nin belirlenmesi diğer bileşenler gibi zorunlu tutulmamış, ölçüm
uzmanının inisiyatifine bırakılmıştır [
FKG yazılımın ne yapacağını tanımlayan kullanıcı gereksinimlerinin alt kümesidir. FS, bir grup VH’inden meydana gelmiş FKG’lerinin temel parçasıdır. İN, fonksiyonel kullanıcı açısından tanımlandığında verini saklandığı varlıktır. İlgi nesneleri veri tabanında tablolara denk gelmektedir.
VG ise herhangi bir ilgi nesnesi ile ilişikli olan ve bir grup veri özniteliğinin bir araya gelmesinden oluşmuş veri kümeleridir.
VÖ, kullanıcı açısından anlam taşıyan, bir veri grubunun en küçük parçasıdır.
VH, fonksiyonel kullanıcılar ve uygulama arasında veri taşırlar. Şekil 1’de görüldüğü gibi 4 FS tipi bulunmaktadır. Büyüklük hesaplanırken her FS için ―Giriş‖ ―Çıkış‖ ―Okuma‖ ―Yazma‖ işlemlerinin sayısı göz önünde bulundurulur. Fonksiyonel kullanıcılar ―kişi‖, makine, ya da bir başka yazılım olabilir.
Şekil 1. VH tipleri ve bunların FS ve VG ile olan ilişkisi [
Kemerer ve Porter, işlevsel büyüklük ölçümlerindeki farklı değerlerin kaynağını
bulmak için IFPUG yöntemini kullanarak bir vaka çalışması yapmış ve işlevsel
büyüklük ölçümlerinin güvenilirliğini artırmak için tavsiyeler vermiştir. Temel
önerilerinden birisi, ölçüm süreci ve insan hatası maliyetini azaltmak için işlevsel büyüklük
ölçüm sürecinin otomatik hale getirilmesidir [
2009 yılında, Ungan ve arkadaşları ölçüm yapan uzmanlar arasındaki farklılıkları
saptamak için İBÖ’leri içindeki farklılıkları tespit eden deneysel bir çalışma
yapmıştır. Çalışmanın sonuçlarına göre COSMIC ölçümlerindeki farklılıklar bireylerin farklı
yorumlar ve varsayımları ile ölçüm yöntemlerindeki temel kurallarının uygulanması
sırasında ortaya çıkmaktadır. Bu çalışma, farklı bilgi ve deneyim düzeyine sahip farklı
ölçüm uzmanlarının işlevsel büyüklük ölçüm varyasyonlarına neden olabileceğini
göstermiştir [
Tunalılar ve Demirörs, büyüklük ölçüm sürecini, efor kestirimi metodolojisi
(EFES) ile tanımlamışlardır. Bu metodolojinin gereklerini tanımlarken, bazı
durumlarda ortak fikir birliği oluşturmak için standart kılavuzların yeterli olmadığını
vurgulamışlar, ölçüm sürecini iyileştirmek için, yazılım firmalarına, standart kılavuzlara ek
olarak, kurumsal ölçüm prosedürü, şablon ve şirketin proje uygulama tiplerine özel
uyarlama notları oluşturmayı tavsiye etmişlerdir. Bu şablonlar gelecekte ölçüm
uzmanlarını desteklemek için kullanılmak üzere nadir görülen durumları ya da
varsayımları kaydetmektedir [
COSMIC güvenilirliğini belirlemek ve sık karşılaşılan COSMIC hatalarını
gözlemlemek için, Top [
Ölçümlerin doğruluğunu arttırmak için 2011 yılında, "Ölçüm Doğruluğunun
Sağlanması için Kılavuz" isimli bir rehber yayınlanmıştır [
2010 yılında, Yılmaz ve arkadaşları, YGD’larının kalitesinin İBÖ’lerine etkisi
üzerine yapılmış bir çalışmanın ilk sonuçlarını sunmuştur. Bu çalışma, yazılım
gereksinim dokümanlarının COSMIC İBÖ’lerinin güvenilirlik ve doğruluğu için ölçüm
yöntemleri kadar önemli olduğunu göstermiştir. Ayrıca, çalışmada ―Ölçüm
Doğruluğunun Sağlanması için Kılavuz‖ [
3.1
Aracın Geliştirilmesi
Şekil 2’de gösterildiği üzere; hata yakalama aracının bir hata tespit yaklaşımı baz
alınarak, projelerin İBÖ’lerinin tutulduğu bir ortama entegre olarak geliştirilmesi
planlanmıştır. Hata tespit yaklaşımının oluşturulması için, işlevsel büyüklük ölçüm
metodunun kendisi [
Hata tespit aracının entegre olarak çalışacağı ortamın kurulması, Hata kategorilerinin belirlenmesi Hata tespit yaklaşımının geliştirilmesi
Hata yakalama algoritmalarının ve R-COVER aracının oluşturulması
için yazılım projelerinin İBÖ’lerinin bulunduğu bir ortam gereklidir. Bunun yanında
hata yakalama aracının geliştirilmesi tamamladıktan sonra, aracın hataları yakalama
doğruluğu ve verimliliği de pek çok projenin ölçümlerinin bulunduğu bu ortamda test
edilerek araç iyileştirilebilecektir. Bu amaçla, farklı alanlardaki yazılım proje bilgileri
ve ölçümlerinin bulunduğu bir veri tabanı gereklidir. CUBIT [
Hata kategorilerinin belirlenmesi: Ortamın seçiminden sonra, hata yakalama
aracının hata tespit işlemi bir "temel‖e dayandırılmalıdır. Geliştirilecek olan araç, bu
temeli esas alarak İBÖ’lerindeki hataları otomatik olarak bulabilmelidir. Bu amaçla,
önceden yapılmış araştırmalarda [
Hata kategorilerinin belirlenmesi için, YBS uygulama tipi ve ilgili İBÖ’leri
seçilmiştir. Bu seçimin sebebi CUBIT ortamının çok sayıda YBS projelerine ait
ölçüm bilgilerinin bulunmasıdır. Belirlenmiş bir YBS projesine ait yazılım gereksinim
dokümanını 10 farklı ölçüm uzmanı ölçmüştür. Bu ölçümler kullanılarak toplamda 23
hata kategorisi tanımlanmıştır. Hata Kategorilerini (HK) oluşturmak için izlenilen
yöntem ve süreçlerin detayları bir önceki araştırmamızda belirtilmiştir [
Hata kategorilerinin belirlenmesi ve hataların ortaya çıkış nedenleri araştırıldıktan sonra, her bir hata kategorisinin yapısı sırası ile tüm ölçüm dokümanlarında analiz edilmiştir. Aynı hata kategorisine ait ölçüm hataları, farklı dokümanlarda da bulunuyorsa hataların otomatik tespiti için bu yapı yeterli ise, yani YGD bilgisine ihtiyaç duyulmadan tespiti sağlanacaksa, ilgili hata kategorisi için hata yapısı olarak tanımlanmıştır. Bu hata yapıları daha sonra aracın geliştirilmesi sırasında algoritmaları oluşturmak için kullanılmıştır. Algoritmaların temelini oluşturan hata yapıları Tablo 1’de belirtildiği gibi İstatistiksel, Anlamsal ve Sözdizimsel olmak üzere 3 sınıf altında toplanabilir.
Hata tespit yaklaşımının geliştirilmesi. Bu çalışmada Tablo 1’deki hata kategorileri tipindeki hataları otomatik olarak tespit etmek için bir yaklaşım geliştirilmiştir ve bu yaklaşım da kısaca ―R-COVER yaklaşımı‖ olarak isimlendirilmiştir. Hata kategorileri YBS uygulamalarının COSMIC İBÖ’leri temel alınarak tespit edildiği için, bu yaklaşım özellikle YBS uygulamalarının İBÖ’leri için geçerlidir. R-COVER yaklaşımı ve hata kategorileri, hata tespit aracının temelini oluşturmaktadır.
R-COVER yaklaşımı, standart COSMIC İBÖ yönteminin [
Hata Kaynağı
Hata yapısı ÖS-K
Anlamsal ÖS-K
Anlamsal ÖS-K
Anlamsal 1 2 3 4 5 6 7 8 9 11 12 Anlamsal Anlamsal Anlamsal Anlamsal Anlamsal İst.
İst.
Anlamsal 10
Güncelleme öncesi silme listeleme unutulmuş Silme öncesi listeleme
unutulmuş Güncelleme öncesi oku
ma unutulmuş Yazma/Silme/Güncelleme tipindeki FS'lerde "W" tipinde VH unutulmuş Listeleme tipindeki FS "W" tipinde VH içerir Bir FS birden fazla aynı
VH içerir Her FS en az 2 VH'den
oluşur Her FS en az 1 "W" veya "X" tipinde VH içerir Her FS en az 1 "E" VH
içerir Listeleme tipindeki FS, Güncelleme/Silme tipindeki FS'lerin içinde öl
çülmüş Yazma/Silme/Güncelleme FS'leri tek bir FS olarak
ölçülmüş Anlamsal 13
VG tekrarı Sözd.
14
Kullanıcı ara yüz parçaları ve sistem kullanıcıları VG/İN olarak düşünül
müş bilgi mutlaka olmalıdır. Çünkü, ölçümlerde veri özniteliği bilgileri boş bırakılırsa, İN’ne yönelik hatalar tespit edilemez.
Hata Kategorisi
Referans
Kapsamı
Tanımı Ö-K
Anlamsal
FS tekrarı
[
Genel
[
YBS özel YBS özel YBS özel YBS özel Genel Genel Genel Genel Genel YBS özel YBS özel Genel Genel Genel İki farklı FS aynı (VG, VH) ikililerine sahipse ve aynı işlevselliği temsil ediyorsa, FS'lerden biri fazla olabilir Güncelleme tipindeki bir FS için, Listeleme tipindeki
FS'in ölçümü unutulmuş
olabilir.
Silme tipindeki bir FS için, Listeleme tipindeki FS'in ölçümü unutulmuş olabilir.
Güncelleme tipindeki bir FS için, Okuma tipindeki FS'in ölçümü unutulmuş
olabilir.
Yazma/Silme/Güncelleme FS'lerinde Y tipinde VH
ölçülmemiş olabilir Listeleme tipindeki FS'te W tipindeki VH yanlış ölçül
müş olabilir Bir FS'te birden fazla aynı VH bulunuyorsa, bu VH'lerin bazıları fazladan ölçül
müş olabilir Bir FS'te 1 veya daha az
VH bulunamaz Bir FS'te Wveya X tipinde
VH yoksa Bir FS'te E tipinde en az 1
VH yoksa Listeleme tipindeki FS, güncelleme veya silme tipindeki FS içinde ölçül
müş olabilir 3 farklı FS (Yazma/Silme/Güncelleme) tek bir FS olarak ölçülmüş
olabilir Birden fazla aynı VG
mevcut olabilir Ölçüm uzmanı "ekran","düğme","menü" gibi kullanıcı arayüzü bölümlerini İN veya VÖ olarak düşünerek FS olarak ölç
müş olabilir İN'lerini isimlendirirken "kaydet", "seç", "bul" gibi filleri kullanmış olabilir Ayrıca, R-COVER yaklaşımımızda, ―FS tipi‖ isimli ―yeni bir işlevsel büyüklük bileşeni‖ tanımlanmıştır. Bu yeni bileşenin örneği Şekil 2’de YBS uygulamaları için gösterilmiştir: ―Silme‖, ―Yazma‖, ―Okuma‖ ―Güncelleme‖, ve ―Listeleme". Herhangi bir FS tipine uymaması durumu için ―Diğer‖ olmak üzere bir FP tipi daha eklenmiştir.
kalama aracımız CUBIT’in bir modülü olarak geliştirileceği için, CUBIT’in E-R şeması ve mevcut veri tabanı yapısı fonksiyonel süreç tipi ve veri özniteliği büyüklük bileşenleri göz önünde bulundurularak incelenmiştir. ―VÖ‖ büyüklük bileşeni CUBIT’in mevcut veri tabanı tablolarında bulunmaktadır ancak, ―FS tipi‖ yeni tanımlanmış bir büyüklük bileşeni olduğu için veri tabanına eklenmesi gerekmiştir. Bu nedenle CUBIT’in bazı veri tabanı tablolarına FS tipi alanı eklenerek, CUBIT veri tabanı ve E-R şeması güncellenmiştir.
Şekil 3. HK1’in sözde kodu
Tablo 1’de gösterilen 3 farklı hata yapısına göre farklı algoritmalar geliştirilmiştir. ―İstatistiksel‖ kontrol yapan algoritmalar, bu hesaplamaları yapabilmek için CUBIT veri tabanındaki yazılım projelerinin büyüklük ölçümlerini kullanmaktadır. ―Anlamsal‖ hata yapıları oluşturan hata kategorilerine ait hataları yakalamak için ölçüm dokümanlarını anlamsal olarak kontrol eden algoritmalar oluşturulmuştur. ―Sözdizimsel‖ hata yapılarına sahip hataları yakalamak için ise dokümanları sözdizimsel olarak kontrol eden algoritmalar oluşturulmuştur.
Şekil 4. FS ve VH hataları sonuç ekranı Hata yakalama algoritmalarının geliştirilmesi için her bir hata kategorisi için tespit edilen hata yapıları kullanılarak öncelikle sözde (pseudo) komut, daha sonra ilgili algoritmaları oluşturulmuştur. Bir sözde kod örneği Şekil 3’te verilmiştir. Bu sözde kod, HK1 için oluşturulmuştur. Bu sözde koddan oluşturulan algoritma, eğer iki farklı fonksiyonel süreç aynı (VG, VH) çiftlerini taşıyorsa ve iki fonksiyonel sürecin büyüklükleri aynı ise ölçümde HK1 tipinde bir hata olduğuna dair uyarı vermektedir. Aslında iki farklı fonksiyonel süreç aynı (VG, VH) ikililerine sahip olabilir, burada belirleyici olan bileşen fonksiyonel süreçlerin tipidir.
Araç kullanıcıya, uyarı ve hata mesajı olmak üzere 2 farklı mesaj vermektedir. Hata mesajı, COSMIC İBÖ yönteminin en temel kurallarının yanlış kullanılması sonucunda verilmektedir. Uyarı mesajlarının hepsinde ölçüm hatası olmayabilir. Ölçüm uzmanlarının uyarı mesajlarındaki hataları düzeltmeden önce YGD’larını kontrol etmeleri gerekir. R-COVER aracının ürettiği bir sonuç raporu Şekil 4’te sunulmuştur. 3.2
Durum Çalışmasının Planı. Aracın hata yakalama doğruluğunu ve verimini tespit etmek için, 7 farklı YBS uygulamasının 26 COSMİC İBÖ’ü ile 17 gerçek zamanlı ve gömülü yazılım projesinin ölçümleri kullanılmıştır. Durum çalışması sırasında farklı verim testleri için YBS uygulamalarının ölçümleri 3 ayrı grupta toplanırken, gerçek zamanlı ve gömülü yazılım projelerinin İBÖ’leri 1 grup altında toplanmıştır. Aracın hata yakalama doğruluk ve performansını farklı durumlarda gözlemlemek için, deneyimli ve deneyimsiz ölçücüler tarafından ölçülmüş çok çeşitli COSMIC İBÖ’ler durum çalışmasına dahil edilmiştir. Tablo 2’de hangi grupta hangi projenin olduğu ve kaç adet işlevsel büyüklük ölçümü kullanıldığı özetlenmektedir.
Gru p G1 G2
Prj No v e Adı
Ref. Ana htar
Firma
Uygula ma Tipi Ölçümler in Sayısı Endüstriden alınmış gerç G3 5,[3P-r7o]je AAnnaahhttaarr37- Firma A YBS 5 3 yıl deneyimli ek proje aörlaçcüımlerinde test etmek
Gerçek Farklı uygulama alanları G4 17[8,-P2r4o]je AAnnaahhttaarr284- Firma B za mveanlı 17 5 yıl deneyimli nda aracınliğuiyngiulanabilir
Gömülü test etmek Şekil 5’te gösterildiği gibi, aracın hata tespit doğruluğunu gözlemlemek için, uzmanlar tarafından manüel olarak gözden geçirme yöntemi ile bulunmuş hata sonuçları ile aracın bulduğu hataların her ölçüm için tek tek kontrol edilmesi planlanmıştır.
Ölçüm dokümanlarındaki hataların kayıt altında tutulması için, aracı çalıştırırken ve gözden geçirme yöntemi sırasında kullanılmak üzere ―Hata İşaretleme Formu‖ oluşturulmuştur. Her bir ölçüm dokümanındaki hatalar gözden geçirme yöntemi ve araç ile tespit edilirken, hatalar bu forma girilecektir. Hata İşaretleme Formunun bir kısmı örnek olması için Tablo 3’te verilmiştir.
Uzman gözden geçirme süreci. Gözden geçirme sürecine başlamadan önce, işlevsel büyüklük ölçüm dokümanlarındaki hataları tespit etmek için her farklı yazılım projesi için referans olarak kullanılabilecek doğruluğu onaylanmış COSMIC işlevsel büyüklük ölçümüne ihtiyacımız vardır. Tablo 2’de her grup için kaç adet referans olarak kullanılacak cevap anahtarı oluşturulduğu bilgisi verilmiştir. Örneğin, G1’de Proje1 bulunmaktadır ve bu proje için Ref. Anahtar1 oluşturulmuştur. Bu grupta toplamda 10 işlevsel büyüklük ölçümü bulunmaktadır. Bu ölçümler Proje1’in yazılım gereksinim dokümanı kullanılarak 10 farklı ölçücü tarafından gerçekleştirilmiştir. Ölçüm dokümanları sistemde Excel formatında bulunduğundan referans cevap anahtarları da excel formatında hazırlanmıştır.
Şekil 5. Durum çalışmasının akışı Gözden geçirme sürecinin hata kategorileri bazında sürdürülmesi öngörülmüştür. Örneğin, Hata Kategorisi 1 tipindeki hataların varlığının kontrolüne ilk ölçüm dokümanından başlayarak, son ölçüm dokümanına gelinceye kadar devam edilecek, her hata bulunduğunda ilgili ölçüm dokümanı için ―Hata İşaretleme Formuna‖ kayıt edilecektir. Hata kategorisi-1 için bu süreç tamamlandığında, aynı süreci uygulamak üzere hata kategorisi 2’ye geçilecektir.
Tablo 3. G1 ölçümlerinin hata işaretleme formundan bir kesit 1 2
Hata Kategorileri
FS tekrarı
Güncelleme öncesi listeleme unutulmuş 15 İlgi nesnelerinin isimleri fiil içeriyor
Kontrol Tipi Toplam
Manüel 60 Araç 62 ÖD1 ÖD2 4 16 0 16 Manüel Araç Manüel Araç 17 27 66 64 1 5 0 0 1 1 1 1 … … … … … … … ÖD10 11 11 1 0 2 0
Aracın Çalıştırılması. Aracı kullanarak hata tespiti yapmadan önce, CUBIT veri tabanında bulunan Tablo 2’de gösterilen şekilde gruplandırılmış bütün işlevsel büyüklük ölçümlerinin R-COVER yaklaşımda belirtilen kurallara uygunluğunun kontrol edilmesi gerekmektedir. Bu kuralları ihlal eden eksikler varsa, ölçümler veri tabanında güncellenir.
Her bir ölçüm dokümanı için, her bir fonksiyonel sürecin FS tipi bilgisinin tespit edilip veri tabanında güncellenmesi gerekmektedir. Ayrıca, tanımlanmamış VÖ’ler tespit edilecek ve CUBIT veri tabanına girilecektir. FS tiplerinin ve VÖ’lerinin tespiti için her bir projenin yazılım gereksinim dokümanı kullanılmalıdır.
Bu çalışmamızda aracın etkisini görmek amacıyla, G1 ölçümleri için manüel ve otomatik R-COVER araç kullanımı eforunun karşılaştırılması da planlanmıştır. Bileşenleri tespit etmek için harcanacak efor, bu yöntemlerin performans kıyaslaması için kayıt altında tutulmuştur.
Aracın çalışması için gerekli her bir ölçümün eksik bilgileri CUBIT veri tabanında güncellendikten sonra, araç sırası ile her bir ölçüm dokümanı için çalıştırılmalıdır.
Durum Çalışmasının Uygulanması. Planlamaya uygun olarak 2 aktivite şeklinde uygulanmıştır.
Uzman gözden geçirme süreci. Gözden geçirme sürecinin ilk adımı olarak, her projenin güvenilir ve doğru bir işlevsel büyüklük ölçümü gerçekleştirilmiş, daha sonra bu ölçümler ölçüm deneyimine ve COSMIC sertifikasına sahip uzman bir ölçücü tarafından kontrol edilmiştir. Bulunan hatalar düzeltilmiş ve her farklı yazılım projesi için güvenilir bir referans işlevsel büyüklük ölçümü hazırlanmıştır.
Durum çalışmasının planı kısmında anlatıldığı gibi gözden geçirme yöntemi ile ölçümlerdeki hata tespitlerine G1 ölçümlerinden başlanmıştır. Gözden geçirme yöntemini kullanarak hata tespiti için harcanan süreler sadece G1 grubu ölçümleri için kayıt altında tutulmuştur ve bu süreler Tablo 5’te verilmektedir. G1 ölçüm dokümanlarında 15 hata kategorilerinin kontrolü tamamladıktan sonra, aynı süreç diğer gruplar için gerçekleştirilmiştir.
Aracın Çalıştırılması. Araç çalıştırılmadan önce yazılım projeleri ölçümleri CUBIT veri tabanında R-COVER yaklaşımına göre güncellenmiştir. Bu nedenle YBS uygulamalarının olduğu G1, G2 ve G3 gruplarında bulunan yazılım proje ölçümlerinin fonksiyonel süreçlerinin tipleri ve ilgi nesnelerinin veri öznitelikleri belirlenmiş, bu bileşenler CUBIT veri tabanında güncellenmiştir. Ancak G4’teki gerçek zamanlı ve gömülü yazılım projelerinin FS tiplerini belirlemeye çalışırken bazı zorluklarla karşılaşılmıştır. R-COVER yaklaşımın tanımladığı fonksiyonel süreçlerin tiplerinin (Yazma, Silme, Güncelleme, Listeleme, Okuma ve Diğer) gerçek zamanlı ve gömülü sistemlerin ölçümlerinde geçerli olmadığı bu uygulamalarda fonksiyonel süreç tiplerinin bu tanımlı tiplerden tamamen farklı olduğu fark edilmiştir. Bu nedenle, G4’teki ölçümlerin sadece veri öznitelikleri CUBIT veri tabanında güncellenmiştir. Aracın hata tespit doğruluğunu ve verimli çalışmasını analiz etmek için, uzman gözden geçirme süreci sonunda bulunan hatalar ile aracın bulduğu hatalar karşılaştırılmıştır. Analiz sonuçları bölüm 4’te özetlenmiştir. 4
Tablo 4, G1, G2 ve G3 ölçümleri için gözden geçirme yöntemi ile bulunmuş hata sonuçları ile aracın bulduğu hata sonuçlarının karşılaştırılmasını göstermektedir. G4 gerçek zamanlı ve gömülü yazılım projelerinin ölçümlerini içerdiği için bu grubun ölçümlerindeki hata sonuçlarını YBS uygulamaları ile birlikte değil kendi içinde ayrıca değerlendirmek daha uygundur.
Tablo 4’teki ―aynı hataların tespiti‖ kolonu gözden geçirme yöntemi sonucunda bulunan hatalar ile aracın bulduğu hataların aynı olma oranını, ―Tespit edilemeyen hatalar‖ kolonu gözden geçirme yöntemi ile bulunmuş ancak aracın bulamadığı hataların oranını ve son olarak ―Yanlış bulunan hatalar‖ kolonu ise gözden geçirme yöntemi sonucunda bulunamamış ancak aracın fazladan bulduğu hataların oranını göstermektedir.
Proje1 ve Proje2 hem deneyimsiz ölçücüler (öğrenciler) tarafından ölçüldüğü hem de benzer süreçler sonucunda ortaya çıktığı için, G1 ve G2 ölçüm dokümanlarında bulunan hata sonuçlarının birbiri ile tutarlı olması beklenmekteydi. Ancak Tablo 4’e göre aracın gözden geçirme yöntemi ile bulunan hatalar ile aynı hataları bulma oranı G2’de daha yüksektir. Bunun nedeni araştırıldığında G1 ölçüm dokümanlarında hemen hemen her hata kategorisinden hatanın bulunduğu ve hata sayısının çok olduğu ortaya çıkmıştır. G2 ölçümlerinde ise daha az hata olduğu görülmüştür. Bu nedenle, aracın doğru hata tespit etme oranı G2 ölçümlerinde daha yüksektir.
Gözden geçirme yöntemi ve araç tarafından herhangi bir hata tespiti yapılamamış ise, bu hata kategorisi aracın doğru hata tespiti hakkında fikir vermemiştir. Bu kategoriler ise Tablo 4’te ―N/A‖ olarak belirtilmektedir.
Tablo 4. G1, G2 ve G3 için aracın doğru hata tespit etme verimliliği [
Aynı hataların tespiti
Tespit edilemeyen hatalar
Yanlış bulunan hatalar G1
YBS uygulamaları işlevsel büyüklük ölçümleri için tanımlanan FS tipleri, gerçek zamanlı ve gömülü yazılım büyüklükleri için kullanılamamıştır. Bu nedenle araç G4 ölçümleri için anlamlı hata tespitleri yapamamıştır. Örneğin, G4 ölçümleri araç tarafından doğrulanırken, HK1 ve HK7 için bulunan hata sayıları ile diğer hata kategorilerinin hata sayıları arasında büyük bir fark olduğu ortaya çıkmıştır. Bunun sebebi incelendiğinde, HK1 Ve HK7’ye ait hata uyarıların hepsinin yanlış olduğu gözlemlenmiştir. FS tipleri G4 ölçümleri için CUBIT veri tabanında boş bırakıldığı için aracın yanlış uyarı verdiği ortaya çıkmıştır. FS tiplerinin gerçek zamanlı ve gömülü sistemlerin ölçümleri için belirlenmiş ve veri tabanında güncellenmiş olmasın bağlı olarak; gerçek zamanlı ve gömülü sistemlerin İBÖ için aracımızın hata tespit sonuçlarının doğru olması öngörülebilir.
Her hata kategorisi için aracın davranışı incelendiğinde, hata kategorilerinin Genel ve YBS uygulamaları için özel olmak üzere 2’ye ayrılması gerektiği ortaya çıkmıştır. Hangi hata kategorisinin genel, hangilerinin YBS uygulamaları için özel olduğu bilgisi Tablo 1’de belirtilmiştir.
Bulgular ve Tablo 4, 23 hata kategorisinden 15’ine ait hataların ve YGD bilgisi olmadan otomatik olarak ve kolaylıkla tespit edilebileceğini bize göstermiştir.
Uzman gözden geçirme ve aracın çalıştırılma süreci birkaç işlemden oluşmaktadır. Her bir işlem için harcanan efor Tablo 5’te verilmiştir. Efor adam*saat cinsinden kaydedilmiştir. G1 ölçümleri için uzman gözden geçirme süreci için harcanan efor 116 adam * saattir. Aracı kullanmak için gerekli ön hazırlık ve aracın hata tespiti için harcanan efor 9 adam * saattir. R-COVER aracı COSMIC İBÖ’lerindeki hataların tespiti için harcanan efordan büyük bir tasarruf sağlar.
İşler Cevap anahtarı hazırlama Uzman gözden geçirme için Hata İşaretleme Formunun hazırlanması Hata kategorilerinin belirlenmesi ve seçilmesi Uzman gözden geçirme süreci İstatistiksel hesaplamalar Uzman gözden geçirme (Toplam) FS tiplerinin belirlenmesi ve CUBIT veri tabanında güncellenmesi Veri özniteliklerinin belirlenmesi ve CUBIT veri tabanında güncellenmesi Aracın çalıştırılması (10 ölçüm dokümanı için) Aracın çalıştırılması (Toplam) 5
Efor (dk) 860
Efor (saat)
14 510 Durum çalışmasının uzman gözden geçirme süreçleri, bu makalenin bir yazarı tarafından yapılmıştır. 3 yıllık deneyime ve COSMİC ölçüm sertifikasyonuna sahiptir. Çalışmadaki hataları en aza indirgemek için 5 yıl ölçüm deneyimi olan ve COSMIC İBÖ sertifikasına sahip bir uzman yazara kritik noktalarda yardım etmiş, 9 yıllık bir başka COSMİC ölçüm uzmanı tarafından sonuçlar gözden geçirilmiştir. Belirlenen hata kategorileri ve R-COVER aracı, kısıtlı sayıda YBS uygulamalarının COSMIC İBÖ’lerinden yola çıkılarak geliştirilmiştir. Aracın daha farklı uygulama alanları veya daha çok sayıda YBS uygulamasının ölçümünde çalıştırılması hata tespitlerinde benzer sonuçlar yaratmayabilir.
Bu çalışmada, COSMIC İBÖ’lerin güvenilirlik ve doğruluğunu arttırmak için, COSMIC İBÖ’leirndeki ölçüm hataların otomatik olarak yakalanmasına olanak sağlayan, bir yaklaşım öne sürülmüş, bu yaklaşım temel alınarak R-COVER aracı geliştirilmiştir. Araç YBS uygulamalarının COSMIC İBÖ’lerindeki hataların, yazılım gereksinim dokümanındaki herhangi bir bilgiye ihtiyaç duyulmadan otomatik olarak yakalanmasını sağlar.
Sonraki çalışmamızda, R-COVER aracının uygulandığı yazılım uygulama alanlarının genişletilmesi planlanmıştır. Yaklaşım ve araç COSMIC İBÖ’lerindeki hataları tespit etmeye yönelik olarak geliştirilmiştir. Ancak, IFPUG, UniFSM gibi farklı işlevsel büyüklük ölçüm metotları ile ölçülmüş İBÖ’lerdeki hataları bulmaya yönelik olarak da ileride eklemeler yapılacaktır.