Yazılım Tasarımı Kalitesi. L 12 Nesneye. Tasarım Kalitesi Nitelikleri

Benzer belgeler
Nesneye Dayalı Yazılım Metrikleri ve Yazılım Kalitesi. Ural ERDEMİR, Umut TEKİN, Feza BUZLUCA

YAZILIM TASARIMI KALİTESİ (ÖLÇME VE DEĞERLENDİRME)

Mobil Uygulamaların Kalite Özelliklerinin Ölçümü

YZM211 YAZILIM TASARIMI

Bilgisayarda Programlama. Temel Kavramlar

JAVA RMI ve Hibernate teknolojileri kullanılarak çok amaçlı bir yazılım altyapısı hazırlanması

YZM 2108 Yazılım Mimarisi ve Tasarımı

SPSS E GİRİŞ SPSS TE TEMEL İŞLEMLER. Abdullah Can

Yazılım Mühendisliği Bölüm - 3 Planlama

ALGORİTMA ANALİZİ. Cumhuriyet Üniversitesi Bilgisayar Mühendisliği Bölümü

Yazılım İnşası ve Evrimi (SE 556) Ders Detayları

Y I L D I Z T E K N I K Ü N İ V E R S İ T E S İ MÜHENDİSLİĞİ

Yazılım Mimari Tasarımından Yazılım Geliştirme Çatısının Üretilmesinde Model Güdümlü Bir Yaklaşım

Bileşen kalitesi ölçümünde statik kod analizi yaklaşımı

Yaz.Müh.Ders Notları #6 1

Tablo 26. Kullanılabilir Gelire göre Sıralı %20 lik Grupların Toplam Tüketim Harcamasından Aldığı Pay

SİSTEM VE YAZILIM. o Bilgisayar sistemleri donanım, yazılım ve bunları işletmek üzere gerekli işlemlerden oluşur.

İçerik. Giriş. Başlangıç Teminatı Geriye Dönük Testi. Hesap Bazında Geriye Dönük Test. Ürün Bazında Geriye Dönük Test. BİAŞ PP Geriye Dönük Test

Tarih Saat Modül Adı Öğretim Üyesi. 01/05/2018 Salı 3 Bilgisayar Bilimlerine Giriş Doç. Dr. Hacer Karacan

BİYOİSTATİSTİK Korelasyon Analizi Yrd. Doç. Dr. Aslı SUNER KARAKÜLAH

Uygulamaların mobil ve masaüstü sürümlerinin kodtabanlı karşılaştırılması: keşifsel bir çalışma

Çoktan Seçmeli Değerlendirme Soruları Akış Şemaları İle Algoritma Geliştirme Örnekleri Giriş 39 1.Gündelik Hayattan Algoritma Örnekleri 39 2.Say

BİLGİSAYAR PROGRAMLAMA (C#) DERS NOTU 1

sınanması zorunluluktur sınama mecburiyeti

Ortaokul Öğrencilerinin Sanal Zorbalık Farkındalıkları ile Sanal Zorbalık Yapma ve Mağdur Olma Durumlarının İncelenmesi

Yazılım Kalite Metriklerinin Kıyaslanması: Örnek Bir Olay İncelemesi. Comparison of Software Quality Metrics: A Case Study

BIM ĐN BĐLEŞENLERĐ BĐNA BĐLGĐ MODELLEMESĐ DERSĐ PROF. DR. SALĐH OFLUOĞLU 2. HAFTA TASARIM VE YAPIM YÖNETĐMĐ Y. LĐSANS PROGRAMI BEYKENT ÜNĐVERSĐTESĐ

Nesneye Dayalı Yazılımlarda Yapısal Değişimlerin Analizi ve Maliyetlerinin Hesaplanması

AHP ANALİTİK HİYERARŞİ PROSESİ AHP AHP. AHP Ölçeği AHP Yönteminin Çözüm Aşamaları

Kalıtım (Inheritance)

Memnuniyet Anketleri Uygulama Rehberi

Mobil Uygulama Yazılımlarında Yazılım Metriklerinin Kullanılması

NESNEYE YÖNELİK TASARIM SÜRECİ

Bileşen Tabanlı Yazılımlardaki Bağımlılıkların Azalması İçin Geliştirilen Kısıtlama Kontrolü Tasarım Kalıbı

5. PROGRAMLA DİLLERİ. 5.1 Giriş

Ders 5: ÖLÇME VE DEĞERLENDİRME. Prof. Dr. Tevhide Kargın

Nesne Tabanlı Yazılımların Yapısal Özelliklerinin Hata Yatkınlığı Üzerine Etkilerinin İncelenmesi

PROGRAMLAMA TEMELLERİ

YAZILIM SINAMA TEKNİKLERİ GENEL BİLGİLER

Görsel Programlama DERS 02. Görsel Programlama - Ders02/ 1

YAZILIM KALİTESİ İÇİN YİNELEMELİ ÖLÇME YÖNTEMİ

KAVRAM YANILGILARININ ÜÇ-AŞAMALI SORULARLA FARKLI BİR ŞEKİLDE DEĞERLENDİRİLMESİ

KORELASYON VE REGRESYON ANALİZİ. Doç. Dr. Bahar TAŞDELEN

Mühendislik Fakültesi Elektrik-Elektronik Mühendisliği C Programlama 1. Bölüm C# Programlamaya Giriş

Sağlık Sektöründe ISO 9126 nın Uygulanabilirliği

BÖLÜM 1 ÖLÇME VE DEĞERLENDİRMEDE TEMEL KAVRAMLAR

SE311 YAZILIM YAPIMI BÖLÜM 3 YAPIM TASARIMI. Yrd. Doç. Dr. Volkan TUNALI Mühendislik ve Doğa Bilimleri Fakültesi / Maltepe Üniversitesi

Java Temel Özellikleri

ÜAS DA SUNULAN BİLDİRİLER KAPSAMINDA İMALAT İŞLETMELERİNİN ÜRETİM SORUNLARINA BAKIŞI

KARŞILAŞTIRMA İSTATİSTİĞİ, ANALİTİK YÖNTEMLERİN KARŞILAŞTIRILMASI, BİYOLOJİK DEĞİŞKENLİK. Doç.Dr. Mustafa ALTINIŞIK ADÜTF Biyokimya AD 2005

Autodesk Robot Structural Analysis Professional İnşaat Müh. için Yapısal Modelleme, Analiz ve Tasarım çözümü

5. HAFTA PFS 107 EĞİTİMDE ÖLÇME VE DEĞERLENDİRME. Yrd. Doç Dr. Fatma Betül Kurnaz. KBUZEM. Karabük Üniversitesi

Eşdeğer Deprem Yüklerinin Dağılım Biçimleri

Akıllı Ortamlarda Sensör Kontrolüne Etmen Tabanlı Bir Yaklaşım: Bir Jadex Uygulaması

Tedarik Zinciri Yönetimi

Giriş: Temel Adımlar YAZILIM GELİŞTİRME YAŞAM DÖNGÜSÜ. Belirtim Yöntemleri. Belirtim Yöntemleri

1.Yazılım Geliştirme Metotları 1

4. Bölüm Programlamaya Giriş

Sınıf Nesne Kavramları C# Bileşenleri Özellikler, Olaylar, Metotlar

2. BASİT DOĞRUSAL REGRESYON 12

BİT in Temel Bileşenleri (Yazılım-1)

Yazılım Nedir? 2. Yazılımın Tarihçesi 3. Yazılım Grupları 4 Sistem Yazılımları 4 Kullanıcı Yazılımları 5. Yazılımın Önemi 6

İçerik. Giriş. Başlangıç Teminatı Geriye Dönük Testi. Hesap Bazında Geriye Dönük Test. Ürün Bazında Geriye Dönük Test

Sınıf Diyagramları Amaç: Sınıf Diyagramları Nasıl Çizilir?

Deniz Savunma Sistemleri Alanında Sistematik Yazılım Yeniden Kullanım Yaklaşımı

Sistem Analizi ve Tasarımı DERS2

DENİZ HARP OKULU BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜM BAŞKANLIĞI DERS TANITIM BİLGİLERİ

YAZILIM MÜHENDİSLİĞİNİN TEMELLERİ 9.Hafta. Bakım

Algoritma Geliştirme ve Veri Yapıları 2 Veri Modelleri. Mustafa Kemal Üniversitesi

Uygulama Geliştirme ve Yaygınlaştırma Süreçlerindeki Performans Değerlendirmesinde AHP Yönteminin Uygulanması

Yazılım Hata Kestirimi için Örnek Bir Model

BÖLÜM-1.BİLİM NEDİR? Tanımı...1 Bilimselliğin Ölçütleri...2 Bilimin İşlevleri...3

Java da Soyutlama ( Abstraction ) ve Çok-biçimlilik ( Polymorphism )

WEB KULLANILABİLİRLİĞİ

Yazılım Kalite Maliyeti Modeli

BMH-405 YAZILIM MÜHENDİSLİĞİ

YAZILIM MÜHENDİSLİĞİ TEKNOLOJİ FAKÜLTESİ / BİLGİSAYAR MÜHENDİSLİĞİ

3 KESİKLİ RASSAL DEĞİŞKENLER VE OLASILIK DAĞILIMLARI

İletişim Katmanı Yazılım Mimarisinin Kalite Analizi

Chapter 8 Yazılım Testi. Lecture 1. Chapter 8 Software testing

Ben Sine CANBOLAT Türk Hava Kurumu Üniverstesi nde araştırma görevlisi olarak çalışmaktayım. Sizlere «E-Devlet Yazılım Çerçevesi: Sektörel Kazanımlar

MALTEPE ÜNİVERSİTESİ MÜHENDİSLİK FAKÜLTESİ YAZILIM MÜHENDİSLİĞİ LİSANS PROGRAMI

Yaz.Müh.Ders Notları #6 1

ĐSTEMCĐ SUNUCU SĐSTEMLER DERSĐ FĐNAL ÇALIŞMASI SORULAR YANITLAR

Veri Erişim ve Yönetim Kütüphanesinin Servis Tabanlı Mimari ile Tasarlanması H. Doğan Köseoğlu, S.Bozbey

GİRİŞ. Bilimsel Araştırma: Bilimsel bilgi elde etme süreci olarak tanımlanabilir.

Object Oriented Programming Ders İzlence Formu

MESLEKİ TERMİNOLOJİ I 1. HAFTA YAZILIM MÜH. TEMEL KAVRAMLAR

THOMAS TÜRKİYE PPA Güvenilirlik, Geçerlilik ve Standardizasyon Çalışmaları Özet Rapor

C++ Dersi: Nesne Tabanlı Programlama

NESNE TABANLI PROGRAMLAMA

Türk Standartlari Enstitüsü'nün tanımladığı

BAZI İLLER İÇİN GÜNEŞ IŞINIM ŞİDDETİ, GÜNEŞLENME SÜRESİ VE BERRAKLIK İNDEKSİNİN YENİ ÖLÇÜMLER IŞIĞINDA ANALİZİ

1 PROGRAMLAMAYA GİRİŞ

PROGRAMLAMA DİLLERİ. Programlama Dilleri Programlama Dillerinin Önemi Dilleri Sınıflandırılması Anlambilim BNF Notasyonu Kontrol Deyimleri

Bilgiyi Keşfedin! Özelleştirme, Eklenti ve Veri Entegrasyonu Kurumsal Seviyede Yönetim ve Performans

VERİ TABANI YÖNETİM SİSTEMLERİ

Çoklu Bağlanım Çıkarsama Sorunu

BİLGİSAYAR PROGRAMLARININ TASARIMLARINDAKİ VE KODLARINDAKİ SORUNLARIN BELİRLENMESİ ALPER FİLİZ MEHMET ALİ SERT

DENİZ HARP OKULU BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜM BAŞKANLIĞI DERS TANITIM BİLGİLERİ

Transkript:

1 Nesneye Kalite Modelleri ISO/IEC'nin yazılım kalitesi modelleri belli bir yazılım tasarım yöntemine bağlı olmadan yazılımların kalitelerini ele alırlar. Bu tür genel yazılım kalitesi modellerinin yanı sıra doğrudan nesneye dayalı yazılımların kalite özelliklerini değerlendirmeyi hedefleyen modeller ve metrikler de bulunmaktadır. Yazılım kalitesinin ölçülmesindeki problemler ve hedefler: Çok sayıda (yüzlerce) metrik tanımlanmıştır ancak hepsi yararlı (kullanılabilir) bilgi sağlamamaktadır. Birçok metrik gerçek projelerde yeteri kadar sınanmamıştır. Metrikler alt düzeydeki, küçük taneli (fine grained) niteliklere karşı düşen sayılardır. Asıl hedef daha yüksek düzeyeli nitelikleri değerlendirmek olduğundan metrikler ancak bir model ile birlikte değerlendirilebilirler. Metriklerin eşik değerlerini (iyi/kötü değerler) belirlemek zordur. Metrikleri yazılım geliştirmenin erken evrelerinde (örneğin tasarım) elde etmek projenin ilerlemesinde kullanılmalarını sağlar. Nesneye dayalı tasarım bu konuda avantaj sağlar. Çünkü bu yönteme göre yazılım geliştirirken kodlamadan önce yazılımın yapısının tasarlanması gerekir. 5.1 QMOOD: Quality Model for Object-Oriented Design J. Bansiya and C. G. Davis, A hierarchical model for object-oriented design quality assessment, IEEE Transactions on Software Engineering, vol. 28, no. 1, pp. 4 17, Jan. 2002. Hiyerarşik katmanlı kalite modeli benimsenmiştir. Model, dört katman ve aralarındaki ilişkilerden oluşmaktadır. L 1 Kalitesi Nitelikleri L 2 L 12 Nesneye Özellikleri L 23 Nesneye Metrikleri L 34 L 3 L 4 Nesneye Bileşenleri L 1 : Kalitesi Nitelikleri (Design Quality Attributes): En üst düzey nitelikler L 2 : Nesneye Özellikleri (Object Oriented Design Properties) L 3 : Nesneye Metrikleri (Object Oriented Design Metrics) L 4 : Nesneye Bileşenleri (Object Oriented Design Components) 5.2 Düzey 1 (L 1 ): Kalitesi Nitelikleri (Design Quality Attributes) ISO/IEC 9126'daki işlevsellik (functionality), güvenilirlik (reliability), verimlilik (efficiency), kullanışlılık (usability), bakım kolaylığı (maintainability) ve taşınabilirlik (portability) temel alınmıştır. dan çok gerçekleme (implementation) ile ilgili olan güvenilirlik ve kullanışlılık listeden çıkartılmıştır. Taşınabilirlik (portability), genişletilebilirlik (extendibility) olarak değiştirilmiştir. Verimlilik (efficiency), etkinlik (effectiveness) olarak değiştirilmiştir. Bakım kolaylığı, anlaşılırlık (understandability) olarak değiştirilmiştir. Tekrar kullanılabilirlik (reusability) eklenmiştir. Esneklik (flexibility) eklenmiştir. QMOOD tasarım kalitesi niteliklerinin anlamları: QMOOD Kalitesi Nitelikleri (L1): İşlevsellik (functionality) Etkinlik (effectiveness) Anlaşılırlık (understandability) Genişletilebilirlik (extendibility) Tekrar kullanılabilirlik (reusability) Esneklik (flexibility) 5.3 5.4 Düzey 2 (L 2 ): Nesneye Özellikleri (Object Oriented Design Properties) özellikleri; bir yazılımdaki tasarım birimlerinin (sınıflar, metotlar vb.) iç niteliklerini, işlevlerini ve aralarındaki ilişkileri ele alarak doğrudan değerlendirilebilecek somut kavramlardır. QMOOD'taki tasarım özellikleri: Bu özellikler bir veya daha fazla tasarım metriği ile değerlendirilebilecek şekilde seçilmiştir. QMOOD'taki tasarım özellikleri (devamı): 5.5 5.6

2 Düzey 3 (L3): Nesneye Metrikleri (Object Oriented Design Metrics) metrikleri yazılımın tasarım aşamasında elde edilebilirler. Bu metrikler tasarım özelliklerinin değerlendirilmesinde doğrudan kullanılırlar. QMOOD'taki tasarım metrikleri: Bir kısmı önceki çalışmalardan alınmış, bir kısmı yeni oluşturulmuştur. QMOOD'taki tasarım metrikleri (devamı): 5.7 5.8 Düzey 4 (L4): Nesneye Bileşenleri (Object Oriented Design Components) Nesneye dayalı bir tasarımın yapısını belirleyen ve tanımlanabilen en temel bileşenler; nesneler, sınıflar ve aralarındaki ilişkilerdir. Buna göre nesneye dayalı bir tasarımın değerlendirilmesinde aşağıdaki bileşenler üzerinde çalışılabilir (metrikler elde edilebilir). Sınıflar (nesneler), nitelikler, metotlar, ilişkiler, sınıf hiyerarşileri. Bileşenlerin kaliteyi etkileyen özellikleri: Nitelikler: İsim, public/private/protected, static/constant, başlangıç değeri atanmış mı, boyut, tip, değer/işaretçi Metotlar: İsim, public/private/protected, parametre sayısı ve tipleri, static/dynamic, virtual/non-virtual, constructor/destructor, constant, inline Sınıflar: İsim, erişim tipi (Java), türetim tipi, taban sınıf mı, şablon mu, türetilmiş sınıf mı, türetim ağacındaki sırası, alt sınıf sayısı, nitelikleri, metotları, diğer sınıflarla ilişkisi, metotları arasındaki uyum Metrikleri ile özellikleri arasındaki ilişki (L23): 5.9 5.10 özellikleri ile kalite nitelikleri arasındaki ilişki (L 12 ): Birçok doküman incelenerek ve deneyimler kullanılarak sezgisel olarak belirlenmiştir. Design size Hierarchies Abstraction Encapsulation Coupling Cohesion Composition Inheritance Polymorphism Messaging Complexity Reusability Flexibility Understandability Functionality Extendibility Effectiveness özellikleri ile kalite nitelikleri arasındaki ağırlıklı ilişki: Ağırlıklar toplamları +1.0 ya da -1.0 olacak şekilde seçilmiştir. Reusability: +0.5*Design size -0.25*Coupling +0.25*Cohesion +0.5*Messaging Flexibility: +0.25*Encapsulation -0.25*Coupling +0.5*Composition +0.5Polymorphism Undarstandibility: -0.33*Design size -0.33*Abstraction +0.33*Encapsulation -0.33*Coupling +0.33*Cohesion -0.33*Polymorphism -0.33*Complexity Functionality: +0.22*Design size +022*Hierarchies +0.12*Cohesion +0.22*Polymorphism +0.22*Messaging Extendibility: +0.5*Abstraction -0.5*Coupling +0.5*Inheritance +0.5*Polymorphism Effectiveness: +0.2*Abstraction +0.2*Encapsulation +0.2*Composition +0.2*Inheritance +0.2*Polymorphism 5.11 5.12

3 özellikleri ile kalite nitelikleri arasındaki ağırlıklı ilişki: Reusability Flexibility Understandability Functionality Extendibility Effectiveness Design size +0.5-0.33 +0.22 Hierarchies +0.22 QMOOD Modelin geçerliliğinin sınanması (validation) Modelin geçerliliği iki aşamada sınanmıştır. 1. Kalite niteliklerinin geçerliliği 2. Toplam kalite değerinin geçerliliği Abstraction -0.33 +0.5 +0.2 Encapsulation +0.25 +0.33 +0.2 Coupling -0.25-0.25-0.33-0.5 Cohesion +0.25 +0.33 +0.12 1. Modeldeki Kalite niteliklerinin geçerliliğinin sınanması: Sınama için iki yazılım grubu kullanılmıştır. a. Microsoft Foundation Classes (MFC) b. Borland Object Windows Library (OWL) Composition +0.5 +0.2 Inheritance +0.5 +0.2 Polymorphism +0.5-0.33 +0.22 +0.5 +0.2 Messaging +0.5 +0.22 Complexity -0.33 Toplam +1.0 +1.0-1.0 +1.0 +1.0 +1.0 ın toplam kalitesi (Total Quality Index TQI) : Altı kalite niteliğinin değerleri toplanarak o projenin toplam kalitesini gösteren toplam kalite indeksi (Total Quality Index TQI) hesaplanır. 5.13 Her iki yazılım platformu da Windows tabanlı görsel yazılımlar geliştirmekte kullanılmıştır. MFC'nin 5 sürümü, OWL'nin 4 sürümü incelenmiştir. 5.14 Yazımların kalitesi ile ilgili beklentiler (varsayımlar) Aşağıdaki yorumlar gözlemlere dayanmaktadır: Bir yazılımın yeni sürümünün yayımlanmasının iki temel nedeni vardır: 1. Yazlıma yeni işlevler, özellikler, yetenekler katmak 2. Belirlenen hataları düzeltmek Yeni bir yazılımın erken sürümleri genellikle yazılıma yeni yetenekler kazandırmak için yayımlanır. Erken sürümlerde kullanışlılık ve kullanıcı dostu özellikleri de arttırılır. Bu nedenlerle erken sürümlerde yapısal değişiklikler büyük olur ve bir önceki sürüme göre toplam kalitedeki iyileşme de büyük olur. Yazılım olgunlaştıktan sonraki sürümlerde amaç genellikle hataları düzeltmek, yazılımın güvenirliliğini ve sağlamlığını arttırmaktır. Geç sürümlerin bir amacı da yazılımın karmaşıklığını azaltmak olmaktadır. Bu nedenlerle olgun bir yazılımın sürümleri arasındaki kalite artışı az olmaktadır. Modelin üretmesi beklenen sonuçlar Yazılımların sürümleri ile ilgili gözlemlere göre modelin geçerli olabilmesi için aşağıdakine yakın sonuçlar üretmelidir. Tekrar kullanılabilirlik (reusability), esneklik (flexibility), işlevsellik (functionality), genişletilebilirlik (extendibility), etkinlik (effectiveness) her sürümde belli bir oranda artmalı. Özellikle işlevsellik (functionality) ve etkinlik (effectiveness) ilk sürümlerde daha fazla artmalı. İlk sürümlerde anlaşılırlık (understandability ) düşmeli. Çünkü bu sürümlerde yazılıma yeni özelikler eklemek için sisteme bir çok sınıf, metot eklenecek. Yazılım olgunlaştıkça anlaşılırlık artmaya başlamalı. 5.15 5.16 Elde edilen metrik değerleri Hesaplanan Kalite Nitelikleri (normalize metrik değerleri kullanılmıştır) Bazı metrikler tüm yazılıma ilgili örneğin design size. Bazı metrikler bir sınıfla ilgili örneğin coupling, polymorphism Yorumlar: İlk sürümlere göre normalize edilmiş metrik değerleri Her yazılım kendi içinde ayrı ayı normalize edilmiştir. MFC 1.0'a göre ve OWL 4.0'a göre Beklendiği gibi tekrar kullanılabilirlik (reusability), esneklik (flexibility), işlevsellik (functionality), genişletilebilirlik (extendibility), etkinlik (effectiveness) her sürümde belli bir oranda artıyor. İlk sürümlerdeki artış oranı daha fazla (Bkz. 5.19 şekiller) Anlaşılırlık beklenenin dışında MFC'nin tüm sürümlerinde azalıyor. 5.0 sürümündeki azalma çok az olduğu için yazılımın bu sürümde olgunlaşmaya başladığı düşünülebilir. OWL 5.2 sürümünde anlaşılırlık bir önceki sürüme göre iyileşmeye başlıyor. 5.17 5.18

4 MFC için elde edilen kalite nitelikleri değerleri OWL için elde edilen kalite nitelikleri değerleri 2. Modelin toplam kalite ile ilgili geçerliliğinin sınanması Sınama Ortamı: Farklı konularda, farklı amaçlarla yapılan tasarımların karakteristikleri de farklı olacaktır. Bu nedene aralarında karşılaştırma yapılacak olan tasarımların aynı amaçlarla gerçeklenmiş olması gerekir. Sınamaları yapmak için orta boyutlarda (10-29 sınıf) bir C++ projesi seçilmiştir. Bu boyutlardaki bir projeyi insan gözüyle de değerlendirmek mümkündür. Proje olarak 14 farklı kişiye "COOL" adlı sanal bir programlama dili için yorumlayıcı (interpreter) yazdırılmıştır. Her yazılım iki sürümden oluşmaktadır. Önce belli gereksinimler verilere 1.0 sürümü yazdırılmış ardından ek istekler verilerek 2.0 sürümü yazdırılmıştır. Böylece ortaya kalitesi ölçülecek 14 farklı proje çıkmıştır. Modelin geçerliliğini sınamak için 13 kişiden oluşan bir değerlendirici grubu kullanılmıştır. Değerlendiricilerin ticari yazılımlar geliştirme ve nesneye dayalı tasarım konusunda iki ile yedi yıl arasında deneyimleri bulunmaktadır. 5.19 5.20 Sınama Yöntemi: Her değerlendiricinin tasarımlardaki 6 kalite niteliğini (Reusability, Flexibility, Understandability, Functionality,Extendibility, Effectiveness) ölçen kendilerine özgü sezgisel bir yöntem (heuristic) oluşturması isteniyor. Değerlendiriciler kendilerine verilen 14 projeyi kendi yöntemleri ile değerlendirmişlerdir. Bu değerlendirmede her proje için 6 kalite niteliğini kendi yöntemleri ile ölçüp bu 6 değeri toplayarak o proje için toplam kalite puanını (Total Quality Score TQS) hesaplamışlardır. Aynı kalite nitelikleri QMOOD yöntemiyle de hesaplanmıştır. Önce metrikler elde edilmiş ardından metrik değerleri modeldeki katsayılarla çarpılarak kalite niteliklerinin değerleri hesaplanmıştır. Son olarak da kalite niteliklerinin değeri toplanarak o projenin toplam kalitesini gösteren toplam kalite indeksi (Total Quality Index TQI) hesaplanmıştır. Projeler elde ettikleri puanlara göre kendi aralarında sıralanmıştır. Yüksek kaliteli proje 1. sırada, düşük kaliteli proje 14. sırada yer almıştır. 5.21 Sıralama sonuçları: 14 numaralı proje konusunda tüm değerlendiriciler aynı fikirdedir. 1, 2, 3, 5, 7 ve 10 numaralı projeler konusunda büyük ölçüde uzlaşma vardır. 13 numaralı proje konusunda anlaşmazlık vardır. Yazarlar bunu projedeki sınıf sayısının az olmasına bağlıyorlar ancak 1, 2, 14 numaralı projelerde daha az sınıf bulunmaktadır. 5.22 QMOOD ile elde edilen değerlerin ayrıntıları: Metrik değerleri: QMOOD ile elde edilen değerlerin ayrıntıları (devamı): QMOOD ile ölçülen toplam kalite indeksi (Total Quality Index TQI): Normalize edilerek sıralan metrik değerleri: TQI değerlerine göre projeler sıralanarak 5.22'deki tablo oluşturulmuştur. Burada TQI değerlerinin sırasal ölçekte (ordinal scale) ölçüm yaptığı düşünülmüştür. 5.23 5.24

5 Spearman sıralama korelasyonu katsayı sınaması (Spearman's rank correlation coefficient test): QMOOD ile yapılan sıralama ile değerlendiricilerin yaptığı sıralama arasındaki korelasyonun anlamlılığını sınamak için kullanılmıştır. Spearman sıralama korelasyonu katsayısının hesaplanması: E 1 ve E 2, n adet elaman ile ilgili yapılan bağımsız sıralama değerlendirmeleridir. Bu değerlendirmeler elemanlara 1'den n'ye kadar sayılar atarlar. d farkı E 1 ve E 2 değerlendirmelerinin aynı elemana atadıkları sıralama değerinin farkıdır. Spearman katsayısı: Sıralama korelasyonu sonuçları: QMOOD'un yaptığı sıralama 13 değerlendiricin yaptığı sıralamalarla ayrı ayrı karşılaştırılmıştır. r s katsayısı 0.55'ten büyükse anlamlı bir korelasyon olduğu kabul edilmiştir. Değerlendiriciler: 1 2 3 4 5 6 7 8 9 10 11 12 13 Σd 2 180 146 91 68 198 196 42 154 142 136 168 214 260 r s 0.60 0.68 0.80 0.85 0.56 0.57 0.91 0.66 0.69 0.70 0.63 0.53 0.43 r s > X X 0.55 1 6 1 1.00 1.00 12 ve 13 numaralı değerlendiricilerin yaptığı sıralama ile QMOOD'un sıralaması arasındaki korelasyon kabul edilebilir eşik değerinin altında kalmıştır. Bu iki değerlendiricinin yöntemleri incelendiğinde yazılımdaki sınıf sayısını dikkate almadıkları görülmüştür. 5.25 5.26