Yazılım Ölçümü ve Güvenirliği PDF

6.KALİTE ÖLÇÜM ve DEĞERLENDİRMELERİ Bölüm Hedefi Yazılım kalite ölçütlerinin incelenmesi Yazılım ölçütlerinin test adımlarında kullanımının anlaşılması Kalite Güvenirliğinin kestirimini ve modellerini tanima  6.1. Yazılım Ölçümü Yazılım üretimi ölçülemez ise ko...

6.KALİTE ÖLÇÜM ve DEĞERLENDİRMELERİ Bölüm Hedefi Yazılım kalite ölçütlerinin incelenmesi Yazılım ölçütlerinin test adımlarında kullanımının anlaşılması Kalite Güvenirliğinin kestirimini ve modellerini tanima  6.1. Yazılım Ölçümü Yazılım üretimi ölçülemez ise kontrol edilememektedir. (Tom De Marco) Yöneticiler ve yazılım mühendisleri açısından ölçme gereksinimleri farklıdır. Yöneticiler: – Yazılım üretimi için maliyetin ne olacağına – Farklı bölüm çalışanlarının ücretlerini belirlemek için personel üretkenliğini ölçmeye – Farklı projelerde geliştirilen yazılım ürünlerini kıyaslayabilmek için yazılım kalitesini ölçmeye – Projeler için ölçülebilir hedefler belirlenmesi örneğin, yazılım sisteminin nasıl güvenilir olması. – Şirkette kullanımına başlamak üzere, yöntem veya yazılım geliştirme araçlarının etkinliğinin ölçülmesine gereksinim duymaktadırlar.  6.1. Yazılım Ölçümü Yazılım Mühendislerinin: Süreç ölçümleri ile sistemin kalitesini izlemeye örneğin, tasarım süresince yapılan değişiklikler veya farklı gözden geçirme ya da test adımlarında bulunan hatalar, Kesin ölçülebilir terimlerle kalite ve performans gereksinimlerini belirlemeye Sertifika için ürün ve süreç özelliklerini ölçmeye. (Örneğin modüllerin 100 kod satırdan fazla olmamasına) Var olan ürünler ve uygulanan süreçlerden faydalanarak gelecekteki ürün geliştirmeler için tahmin yapabilmeye gereksinimleri vardır.  YAZILIM ÖLÇÜMÜ HALSTEAD,kaynak programın kalite güvencesini kestirmek üzere, m - programda bulunan farklı işleç (operatör)sayısı k - programda bulunan farklı işlenen (operand) sayısı M - işleç yinelenmelerinin toplamı K - işlenen yinelenmelerinin toplamı saptanarak, aşağıdaki gibi olarak hesaplanan ölçütlerin kullanılmasını önermektedir. Oransal hacmin, daima birden küçük bir sayı olarak bulunması gerekmektedir Program uzunluğu : U = m log2m + log2k Program hacmi : H = (M+K) log2(m+k) Program gücü (program effort): G = H/O  YAZILIM ÖLÇÜMÜ McCABE ; programın kontrol akışı biçiminde gösterimine dayalı olarak, karmaşıklık derecesini belirlemektedir (Şekil - 6.1). Program grafı veya akış grafı (program graph, flow graph) adı verilen bu çizim, kontrol akışını göstermektedir. İçerisinde harf yazılı her daire, bir veya çok sayıda kaynak program deyiminden oluşan bir görevi temsil etmektedir. McCABE, bir modüle ait yazılım karmaşıklığının ölçümünde, program grafındaki döngü karmaşıklığını esas almaktadır. Graf içerisindeki kapalı bölgeler ile graf dışında kalan bölge sayılmakta ve bu sayı, modülün karmaşıklığını vermektedir. Örneğin, Şekil-3.1'de bu bölgeler R1..R5 olarak gösterilmiş ve V(G) = 5 bulunmuştur.  1 2 R1 3 R2 4 10 5 R6 R3 12 11 R4 6 13 R5 7 8 9 Şekil-6.1Ortalama alma yöntemine ait akış grafı, (R 2,.. R5 , graf içindeki kapalı bölgeler, R1, graf dışında kalan bölge ,  McCABE ölçüsü, en yüksek modül büyüklüğünü saptamakta da kullanılabilmektedir. Çok sayıdaki programlama projesi üzerinden derlenen bilgilere göre, model büyüklüğünün en çok V(G) = 10 olması gerektiği belirlenmiştir. Döngü karmaşıklığının bu sayıyı aşması halinde, modülün sınanması işlemi büyük ölçüde zorlaşmaktadır  6.3.Yazılım Güvenirliği Tüm yazılımların aynı kalitede ve aynı bileşenlerle aynı sonucu vermesi beklenen bir durum değildir. Ayrıca, bir yazılımı tümüyle test etmek de mümkün değildir. 1000 kodluk bir ticari programda en az 1 kod satırı hatalı çıkmakta olduğu bilinmektedir. Kalite güvenirliği; geçmiş bilgilere ve sınamaya dayalı olarak, Başarı oranı = Başarılı süre / Toplam işletim süresi formülü ile kestirilmektedir.  6.3.1. Yazılım Güvenirliliği Modelleri Yazılım güvenirliliğinin ve geçerliliğinin ölçülmesi için 1980’lerde 100’e yakın model geliştirilmiştir. En yaygın olan dört model: – Schneidewind Model – Jelinski/Moranda Model – Musa Basic - Musa/Okumoto Log. Poison Execution-time Model – Littlewood-Verrall Model  Yazılım Güvenirliliği Modelleri Güvenirlik modelleri, istatistiki verilere dayanarak yazılımın güvenirliliğini saptamaktadır. Bu modellerin çalıştırılması sonucunda, Toplam hata sayısı Güvenirlilik düzeyi Sistemde yapılan revizyon sonucunda kalan hata sayısı vs. Gibi değerler elde edilmektedir.  6.3.1.1. Yazılım Güvenirlik Modeli Değerlendirme Bir yazılım birden fazla modele göre test edilmeli ve sonuçlar karşılaştırılmalıdır. Model değerlendirilirken şu sorulara cevap aranmalıdır; Modele göre yazılım ne kadar geçerlidir? Modeli kullanarak yazılımın güvenirliliğinin ölçümü ne kadar kolaydır? Modeli kullanmak için yazılımın ne kadarına ihtiyaç vardır? Modeli yazılım ölçümünde kullanmak kolay ve anlaşılır mı? Model dış etkenlerden etkileniyor mu?  6.3.2.Yazılım Güvenirliği Sağlama Adımları Bell laboratuarlarında yapılan bir çalışma ile yazılım güvenirliğini sağlamak için en iyi yöntemlere odaklanılmış ve yazılımın gelişiminden müşteriye teslimine kadar 25 aktivite belirtilmiştir; – Olabilirlilik&Gereksinimler İşlevsel Profili Belirlemek Hataları tanımlamak ve sınıflandırmak Müşteri güvenirlilik ihtiyaçlarını tanımlamak Organizasyonu yönetmek – Tanımlamak&Uygulamak Bileşenler arasından güvenirliliği belirlemek İşlevsel kaynaklara odaklanmak Hatalı kodlamaları görmek Yazılım güvenirliliğini ölçmek 6.3.2.Yazılım Güvenirliği Sağlama Adımları – Sistem Testi – Testleri yönetmek – Testleri gözlemlemek – İhtiyaç duyulan ek testleri belirlemek – Test edilen objelerin güvenirliliğini geçerlemek – Teslim&Bakım Yazılımı kullanıma sunmak Yazılımın güvenirliliğini kontrol altında gözlemlemek Müşteri memnuniyetini izlemek Ürüne rehberlik etmek ve ilerleme kaydetmek  Nesneye Yönelik Test Nesneye yönelik yazılımlarda test stratejileri ve test teknikleri diğer yazılımlardan farklıdır. Nesneye yönelik yazılımlarda, sistem gereksinim tanımları, sınıf modelleri, sistem tasarımı ve nesne tasarımındaki hataların, kodlama sürecinden önce test edilerek belirlenmesi gerekir. Analiz ve tasarım modellerinin test edilmesi için, çalıştırılabilir olmaması nedeniyle klasik yöntemler yerine formal teknik gözden geçirmeler kullanılır. Nesneye Yönelik Analiz ve Tasarım Modellerinin Test Edilmesi Bu düzeyde doğruluk ve tutarlılık için gözden geçirme yapılır. Doğruluk, – Modellerin mantıksal doğruluk düzeyi incelemesi, – Sözdizimsel doğruluk kontrolu, – Gerçek dünyaya uyumluluk kontrolu İle sağlanır, Tutarlılık ise, Sınıf-Sorumluluk-İşbirliği (CRC) ve nesne ilişki modeli ile her sınıfın diğer sınıflarla ilişkilerinin test edilmesi ile kontrol edilebilir.  2. Nesneye Yönelik Yazılım Testi NY yazılımlarda, birim kavramı da sınıf veya nesne olarak değişmektedir. Sınıflar, test-case tasarımları için doğal birer birimdir. NY yazılımlarda birim test, sınıf testi olarak tanımlanmaktadır. Birim Testi algoritma ayrıntılarına ve veri akışına, sınıf test ise, paketlenmiş işlemler ve durum değişimlerine odaklanır. OO yazılımlar hiyerarşik kontrol yapılarına sahip olmadıkları için, bütünlük testinde, yukarıdan aşağıya veya aşağıdan yukarıya test stratejileri uygulanmaz. Kullanım Temelli veya Thread-Temelli bütünlük Testleri kullanılmaktadır.  Nesneye Yönelik Yazılım Kabul Testi Kabul veya Sistem testi aşamasında sınıf ilişkilerindeki ayrıntılar önemli değildir ve diğer yazılımlar gibi kullanıcı bakış açısıyla gereksinimlerin karşılanmasına sağlanır. Değerlendirme için, kara kutu testi kullanılır ve gereksinim analizinde hazırlanan kullanım senaryolarından faydalanılabilir. Test-case ler OO Analiz aşamasında oluşturulan “Nesne-Davranış” ve “Olay-Akış” diyagramlarından sayesinde hazırlanabilir.  Bölümlemeli Sınıf Testi Amaç test case sayısını azaltarak sınıfların test edilmesidir. Girdi ve çıktılar kategorize edilerek her kategori için test-case oluşturulur. Miras (inheritance) Özelliğinin test üzerine etkisi Miras alınan metodlar, yeni bir kullanımda olacakları için, yeniden test edilmelidir. Çok biçimlilik (Polymorphism Özelliğinin test üzerine etkisi Çok biçimli bileşenlerin olası tüm bağlanma (binding) durumları için ayrı bir test yapılmalıdır.