Yazılım Kalite Ölçütleri

Yazılım ölçümleri üç kategoriye ayrılabilir -

• Product metrics - Boyut, karmaşıklık, tasarım özellikleri, performans ve kalite seviyesi gibi ürünün özelliklerini açıklar.

• Process metrics - Bu özellikler, yazılımın geliştirme ve bakım faaliyetlerini iyileştirmek için kullanılabilir.

• Project metrics- Bu ölçütler, proje özelliklerini ve yürütülmesini tanımlar. Örnekler arasında yazılım geliştiricilerin sayısı, yazılımın yaşam döngüsü boyunca personel düzeni, maliyet, zamanlama ve üretkenlik yer alır.

Bazı metrikler birden çok kategoriye aittir. Örneğin, bir projenin süreç içi kalite ölçütleri hem süreç ölçütleri hem de proje ölçütleridir.

Software quality metricsürün, süreç ve projenin kalite yönlerine odaklanan yazılım ölçümlerinin bir alt kümesidir. Bunlar, proje ölçütlerinden çok süreç ve ürün ölçütleriyle daha yakından ilişkilidir.

Yazılım kalitesi ölçümleri ayrıca üç kategoriye ayrılabilir -

• Ürün kalite ölçümleri
• İşlem içi kalite ölçümleri
• Bakım kalitesi ölçümleri

Ürün Kalite Ölçütleri

Bu ölçümler aşağıdakileri içerir -

• Başarısızlık için ortalama zaman
• Kusur Yoğunluğu
• Müşteri Sorunları
• Müşteri memnuniyeti

Başarısızlık için ortalama zaman

Başarısızlıklar arasındaki zamandır. Bu metrik çoğunlukla hava yolu trafik kontrol sistemleri, aviyonikler ve silahlar gibi güvenlik açısından kritik sistemlerle kullanılır.

Kusur Yoğunluğu

Kod satırları veya işlev noktası vb. Olarak ifade edilen yazılım boyutuna göre hataları ölçer, yani birim başına kod kalitesini ölçer. Bu metrik, birçok ticari yazılım sisteminde kullanılmaktadır.

Müşteri Sorunları

Müşterilerin ürünü kullanırken karşılaştıkları sorunları ölçer. Hata problemleri ile birlikte hataya yönelik olmayan problemleri içeren, müşterinin yazılımın problem alanına bakış açısını içerir.

Problemler ölçüsü genellikle şu terimlerle ifade edilir: Problems per User-Month (PUM).

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

Nerede,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

PUM genellikle yazılım piyasaya sürüldükten sonraki her ay için ve ayrıca yıllara göre aylık ortalamalar için hesaplanır.

Müşteri memnuniyeti

Müşteri memnuniyeti genellikle beş puanlık ölçek aracılığıyla müşteri anket verileriyle ölçülür -

• Çok Menmun Kalmak
• Satisfied
• Neutral
• Dissatisfied
• Çok memnuniyetsiz

Ürünün genel kalitesinden ve belirli boyutlarından memnuniyet genellikle çeşitli müşteri anketleri yöntemleriyle elde edilir. Beş puanlık ölçekli verilere dayalı olarak, analizin amacına bağlı olarak küçük farklılıkları olan birkaç metrik oluşturulabilir ve kullanılabilir. Örneğin -

• Tamamen memnun müşterilerin yüzdesi
• Memnun müşteri yüzdesi
• Memnun olmayan müşterilerin yüzdesi
• Memnun olmayan müşterilerin yüzdesi

Genellikle bu memnuniyet yüzdesi kullanılır.

Süreç İçi Kalite Ölçütleri

Süreç içi kalite ölçütleri, bazı kuruluşlar için resmi makine testleri sırasında kusur gelişinin izlenmesiyle ilgilenir. Bu metrik şunları içerir -

• Makine testi sırasında kusur yoğunluğu
• Makine testi sırasında hatalı varış şekli
• Aşama tabanlı kusur giderme modeli
• Kusur giderme etkinliği

Makine testi sırasında kusur yoğunluğu

Biçimsel makine testi sırasındaki hata oranı (kod sistem kitaplığına entegre edildikten sonra test), sahadaki hata oranıyla ilişkilidir. Test sırasında bulunan daha yüksek kusur oranları, yüksek test hatası oranı olağanüstü bir test çabasından kaynaklanmadıkça, yazılımın geliştirme sürecinde daha yüksek hata enjeksiyonu yaşadığının bir göstergesidir.

KLOC veya işlev noktası başına bu basit hata ölçüsü, yazılım hala test edilirken kalitenin iyi bir göstergesidir. Aynı geliştirme organizasyonundaki bir ürünün sonraki sürümlerini izlemek özellikle yararlıdır.

Makine testi sırasında hatalı varış şekli

Test sırasındaki genel kusur yoğunluğu, yalnızca kusurların özetini sağlayacaktır. Kusur gelişlerinin modeli, sahadaki farklı kalite seviyeleri hakkında daha fazla bilgi verir. Aşağıdakileri içerir -

• Test aşaması sırasında zaman aralığına göre (örneğin, hafta) rapor edilen kusur varışları veya kusurlar. Burada bunların tümü geçerli kusurlar olmayacak.

• Rapor edilen problemler üzerinde problem tespiti yapıldığında geçerli kusur gelişlerinin modeli. Bu gerçek kusur modelidir.

• Kusur biriktirme fazla mesai kalıbı. Bu metriğe ihtiyaç vardır çünkü geliştirme organizasyonları bildirilen tüm sorunları hemen inceleyip düzeltemez. Bu bir iş yükü beyanı ve aynı zamanda bir kalite ifadesidir. Geliştirme döngüsünün sonunda kusur biriktirme listesi büyükse ve sisteme henüz pek çok düzeltme entegre edilmemişse, sistemin kararlılığı (dolayısıyla kalitesi) etkilenecektir. Hedeflenen ürün kalitesi seviyelerine ulaşıldığından emin olmak için yeniden test (regresyon testi) gereklidir.

Aşama tabanlı kusur giderme modeli

Bu, test sırasında hata yoğunluğu metriğinin bir uzantısıdır. Teste ek olarak, tasarım incelemeleri, kod incelemeleri ve test öncesi resmi doğrulamalar dahil olmak üzere geliştirme döngüsünün tüm aşamalarında kusurları izler.

Programlama hatalarının büyük bir yüzdesi tasarım sorunları ile ilgili olduğundan, ön uçtaki sürecin kusur giderme kapasitesini artırmak için resmi incelemeler veya işlevsel doğrulamalar yapmak yazılımdaki hataları azaltır. Aşama tabanlı kusur giderme modeli, geliştirme sürecinin genel kusur giderme yeteneğini yansıtır.

Tasarım ve kodlama aşamaları için ölçülerle ilgili olarak, kusur oranlarına ek olarak, birçok geliştirme kuruluşu, süreç içi kalite yönetimi için denetim kapsamı ve denetim çabası gibi ölçütleri kullanır.

Kusur giderme etkinliği

Aşağıdaki gibi tanımlanabilir -

$$ DRE = \ frac {Kusur \: kaldırıldı \: \: a \: geliştirme \: aşama} {Kusurlar \: gizli \: içinde \: the \: ürün} \ times 100 \% $$

Bu metrik, tüm geliştirme süreci için, kod entegrasyonundan önce ön uç için ve her aşama için hesaplanabilir. Denirearly defect removal ön uç için kullanıldığında ve phase effectivenessbelirli aşamalar için. Metriğin değeri ne kadar yüksekse, geliştirme süreci o kadar etkili olur ve bir sonraki aşamaya veya sahaya geçen kusurlar o kadar az olur. Bu metrik, yazılım geliştirme için kusur giderme modelinin temel bir konseptidir.

Bakım Kalite Ölçütleri

Bu aşamada ürünün kalitesini değiştirmek için pek bir şey yapılamasa da, mükemmel düzeltme kalitesi ile kusurları en kısa sürede ortadan kaldırmak için yapılabilecek düzeltmeler aşağıdadır.

• Bekleme listesi ve birikim yönetimi dizinini düzeltin
• Yanıt süresini ve yanıt verme süresini düzeltin
• Geciken düzeltme yüzdesi
• Kaliteyi düzelt

Bekleme listesi ve birikim yönetimi dizinini düzeltin

Düzeltme birikimi, hata gelişlerinin oranı ve bildirilen sorunlar için düzeltmelerin kullanılabilir olma oranıyla ilgilidir. Her ayın sonunda veya her haftanın sonunda kalan, bildirilen sorunların basit bir sayısıdır. Bir eğilim grafiği biçiminde kullanan bu metrik, bakım sürecini yönetmek için anlamlı bilgiler sağlayabilir.

Backlog Management Index (BMI), açık ve çözülmemiş sorunların birikmesini yönetmek için kullanılır.

$$ BMI = \ frac {Sayı \: /: sorun \: kapalı \: \: \: ay boyunca {Sayı \: \: sorun \: geldi \: \: \: ay} \ zamanlar 100 \% $$

BMI 100'den büyükse, birikimin azaldığı anlamına gelir. BMI 100'den azsa, birikim artar.

Yanıt süresini ve yanıt verme süresini düzeltin

Düzeltme yanıt süresi metriği, genellikle tüm sorunların açılıştan kapanışına kadar geçen ortalama süre olarak hesaplanır. Kısa düzeltme yanıt süresi müşteri memnuniyetine yol açar.

Düzeltme duyarlılığının önemli unsurları, müşteri beklentileri, kararlaştırılan düzeltme zamanı ve kişinin müşteriye olan bağlılığını karşılama becerisidir.

Geciken düzeltme yüzdesi

Aşağıdaki gibi hesaplanır -

$ Yüzde \: Geciken \: Düzeltmeler = $

$ \ frac {Sayı \: / \: düzeltmeler \: bu \: aşıldı \: \: yanıt \: zaman \: ölçütler \: \: ceverity \: düzey} {Sayı \: \: düzeltmeler \: teslim edildi \: içinde \: a \: belirtilen \: zaman} \ times 100 \% $

Kaliteyi Düzelt

Sabit kalite veya hatalı onarım sayısı, bakım aşaması için bir başka önemli kalite ölçüsüdür. Bir düzeltme, bildirilen sorunu çözmediyse veya orijinal sorunu çözüp yeni bir kusur enjekte ettiyse kusurludur. Görev açısından kritik yazılımlar için, hatalı düzeltmeler müşteri memnuniyeti için zararlıdır. Hatalı düzeltme yüzdesi metriği, hatalı bir zaman aralığındaki tüm düzeltmelerin yüzdesidir.

Hatalı bir düzeltme iki şekilde kaydedilebilir: Bulunduğu ay kaydedin veya düzeltmenin teslim edildiği ay kaydedin. İlki bir müşteri ölçüsüdür; ikincisi bir süreç ölçüsüdür. İki tarih arasındaki fark, hatalı düzeltmenin gizli dönemidir.

Genellikle gecikme ne kadar uzun olursa, etkilenen müşteriler o kadar fazla olacaktır. Kusurların sayısı büyükse, yüzde metriğinin küçük değeri iyimser bir resim gösterecektir. Bakım süreci için kalite hedefi, şüphesiz, kusurlu sıfır kusurlu düzeltmedir.