Yazılım Kalite Yönetimi - Hızlı Kılavuz

Kaliteli yazılım, makul ölçüde hatasız veya hatasız, zamanında ve belirlenen bütçe dahilinde teslim edilen, gereksinimleri ve / veya beklentileri karşılayan ve bakımı yapılabilen bir yazılımı ifade eder. Yazılım mühendisliği bağlamında, yazılım kalitesi her ikisini de yansıtır.functional quality Hem de structural quality.

• Software Functional Quality - Fonksiyonel gereksinimlere veya spesifikasyonlara dayalı olarak belirli bir tasarımı ne kadar iyi karşıladığını yansıtır.

• Software Structural Quality - Sağlamlık veya sürdürülebilirlik gibi işlevsel gereksinimlerin sağlanmasını destekleyen işlevsel olmayan gereksinimlerin ele alınması ve yazılımın doğru üretilme derecesi ile ilgilenir.

• Software Quality Assurance- Yazılım Kalite Güvencesi (SQA), nihayetinde kaliteli yazılım ürünleri ile sonuçlanan yazılım mühendisliği süreçlerinde kaliteyi sağlamak için bir dizi faaliyettir. Faaliyetler, ürün üreten süreçleri oluşturur ve değerlendirir. Süreç odaklı eylemi içerir.

• Software Quality Control- Yazılım Kalite Kontrolü (SQC), yazılım ürünlerinde kaliteyi sağlamaya yönelik bir dizi faaliyettir. Bu faaliyetler, üretilen gerçek ürünlerdeki kusurları belirlemeye odaklanır. Ürün odaklı eylemi içerir.

Yazılım Kalitesi Zorluğu

Yazılım endüstrisinde, geliştiriciler, diğer endüstriyel ürün üreticilerinin genellikle yaptığı gibi, yazılımın hatasız olduğunu asla beyan etmezler. Bu fark aşağıdaki nedenlerden kaynaklanmaktadır.

Ürün Karmaşıklığı

Ürünün izin verdiği çalışma modu sayısıdır. Normalde, bir endüstriyel ürün, makine ayarlarının farklı kombinasyonlarıyla yalnızca birkaç binden daha az çalışma moduna izin verir. Bununla birlikte, yazılım paketleri milyonlarca işletim olasılığına izin verir. Bu nedenle, tüm bu operasyonel olanakların doğru bir şekilde sağlanması, yazılım endüstrisi için büyük bir zorluktur.

Ürün Görünürlüğü

Endüstriyel ürünler görünür olduğundan, kusurlarının çoğu üretim sürecinde tespit edilebilir. Ayrıca endüstriyel bir üründe parça bulunmaması üründe kolaylıkla tespit edilebilir. Bununla birlikte, disketlerde veya CD'lerde depolanan yazılım ürünlerindeki kusurlar görünmezdir.

Ürün Geliştirme ve Üretim Süreci

Endüstriyel bir üründe, aşağıdaki aşamalarda kusurlar tespit edilebilir -

• Product development - Bu aşamada, tasarımcılar ve Kalite Güvence (QA) personeli, kusurlarını tespit etmek için ürün prototipini kontrol eder ve test eder.

• Product production planning- Bu aşamada üretim süreci ve araçları tasarlanır ve hazırlanır. Bu aşama aynı zamanda geliştirme aşamasında fark edilmeyen kusurları tespit etmek için ürünü inceleme fırsatı sunar.

• Manufacturing- Bu aşamada, ürünlerin kendi arızalarını tespit etmek için QA prosedürleri uygulanır. Üretimin ilk döneminde tespit edilen üründeki kusurlar, genellikle ürünün tasarımında veya malzemelerinde veya üretim araçlarında, ileride üretilen ürünlerde bu tür kusurları ortadan kaldıracak şekilde bir değişiklik ile düzeltilebilir.

Ancak, yazılım söz konusu olduğunda, kusurların tespit edilebildiği tek aşama geliştirme aşamasıdır. Yazılım olması durumunda, yazılım kopyalarının üretimi ve yazılım kılavuzlarının basımı otomatik olarak yapıldığından ürün üretim planlama ve üretim aşamalarına gerek kalmaz.

Yazılım ürünlerinde diğer endüstriyel ürünlere göre kusurların tespitini etkileyen faktörler aşağıdaki tabloda gösterilmektedir.

Karakteristik	Yazılım Ürünleri	Diğer Endüstriyel Ürünler
Karmaşıklık	Milyonlarca operasyonel seçenek	bin operasyonel seçenek
ürünün görünürlüğü	Görünmez Ürün Kusurları görerek tespit etmek zor	Görünür Ürün Görerek kusurların etkili tespiti
Geliştirme ve üretim sürecinin doğası	Kusurları yalnızca bir aşamada kusur edebilir	aşağıdaki aşamaların tümünde kusurları tespit edebilir Ürün geliştirme Ürün üretim planlaması Manufacturing

Yazılımın karmaşıklık ve görünmezlik gibi bu özellikleri, yazılım kalite güvence metodolojisinin geliştirilmesini ve başarılı bir şekilde uygulanmasını oldukça profesyonel bir zorluk haline getirir.

Yazılımı etkileyen çeşitli faktörler, yazılım faktörleri olarak adlandırılır. Genel olarak iki kategoriye ayrılabilirler. Faktörlerin ilk kategorisi, mantıksal hataların sayısı gibi doğrudan ölçülebilenlerdir ve ikinci kategori, sadece dolaylı olarak ölçülebilen faktörleri kulüpler. Örneğin, sürdürülebilirlik ancak her bir faktör, içeriği ve kalite kontrolünü kontrol etmek için ölçülecektir.

Yıllar içinde çeşitli yazılım kalite faktörleri modelleri ve bunların sınıflandırılması önerilmiştir. McCall tarafından önerilen klasik yazılım kalite faktörleri modeli 11 faktörden oluşmaktadır (McCall ve diğerleri, 1977). Benzer şekilde 12 ila 15 faktörden oluşan modeller Deutsch ve Willis (1988) ve Evans ve Marciniak (1987) tarafından önerilmiştir.

Tüm bu modeller McCall'ın modelinden önemli ölçüde farklı değildir. McCall faktör modeli, yazılım gereksinimlerini sınıflandırmak için pratik, güncel bir yöntem sağlar (Pressman, 2000).

McCall'ın Faktör Modeli

Bu model, tüm yazılım gereksinimlerini 11 yazılım kalite faktörüne göre sınıflandırır. 11 faktör üç kategoriye ayrılmıştır - ürün operasyonu, ürün revizyonu ve ürün geçiş faktörleri.

• Product operation factors - Doğruluk, Güvenilirlik, Verimlilik, Bütünlük, Kullanılabilirlik.

• Product revision factors - Sürdürülebilirlik, Esneklik, Test Edilebilirlik.

• Product transition factors - Taşınabilirlik, Yeniden Kullanılabilirlik, Birlikte Çalışabilirlik.

Ürün Çalıştırma Yazılım Kalite Faktörleri

McCall'ın modeline göre, ürün çalıştırma kategorisi, yazılımın günlük işleyişini doğrudan etkileyen gereksinimlerle ilgilenen beş yazılım kalite faktörü içerir. Bunlar aşağıdaki gibidir -

Doğruluk

Bu gereksinimler, yazılım sisteminin çıktısının doğruluğu ile ilgilidir. İçerirler -

• Çıktı görevi

• Hatalı verilerden veya hatalı hesaplamalardan olumsuz etkilenebilecek gerekli çıktı doğruluğu.

• Eksik verilerden etkilenebilecek çıktı bilgilerinin tamlığı.

• Olay ile yazılım sistemi tarafından yanıt arasındaki zaman olarak tanımlanan bilginin güncelliği.

• Bilgilerin kullanılabilirliği.

• Yazılım sistemini kodlama ve belgeleme standartları.

Güvenilirlik

Güvenilirlik gereksinimleri servis arızasıyla ilgilenir. Yazılım sisteminin izin verilen maksimum arıza oranını belirlerler ve tüm sisteme veya bir veya daha fazla ayrı işlevine başvurabilirler.

Verimlilik

Yazılım sisteminin farklı işlevlerini yerine getirmek için gereken donanım kaynakları ile ilgilenir. İşlem yeteneklerini (MHz cinsinden verilir), depolama kapasitesini (MB veya GB cinsinden verilir) ve veri iletişim yeteneğini (MBPS veya GBPS olarak verilir) içerir.

Ayrıca, taşınabilir bilgisayarlarda bulunan bilgi sistemi birimleri veya dışarıya yerleştirilmiş meteorolojik birimler gibi sistemin taşınabilir birimlerinin yeniden şarj edilmesi arasındaki süreyi de ele alır.

Bütünlük

Bu faktör, yazılım sistemi güvenliği ile ilgilenir, yani yetkisiz kişilerin erişimini engellemek, ayrıca okuma ve yazma izni verilecek insan grupları arasında ayrım yapmaktır.

Kullanılabilirlik

Kullanılabilirlik gereksinimleri, yeni bir çalışanı eğitmek ve yazılım sistemini çalıştırmak için gereken personel kaynakları ile ilgilidir.

Ürün Revizyonu Kalite Faktörleri

McCall'ın modeline göre, ürün revizyon kategorisine üç yazılım kalite faktörü dahil edilmiştir. Bu faktörler aşağıdaki gibidir -

Sürdürülebilirlik

Bu faktör, yazılım arızalarının nedenlerini belirlemek, hataları düzeltmek ve düzeltmelerin başarısını doğrulamak için kullanıcılar ve bakım personeli tarafından ihtiyaç duyulacak çabaları dikkate alır.

Esneklik

Bu faktör, yazılımın uyarlanabilir bakım faaliyetlerini desteklemek için gereken yetenek ve çabalarla ilgilenir. Bunlar, yazılımı değiştirmeden mevcut yazılımı ek koşullara ve müşterilere uyarlamayı içerir. Bu faktörün gereksinimleri, hizmetini iyileştirmek ve firmanın teknik veya ticari ortamındaki değişikliklere uyarlamak için yazılımda değişiklikler ve eklemeler gibi mükemmel bakım faaliyetlerini de destekler.

Test edilebilirlik

Test edilebilirlik gereksinimleri, yazılım sisteminin test edilmesinin yanı sıra çalışmasıyla ilgilidir. Sistemin tüm bileşenlerinin çalışır durumda olup olmadığını öğrenmek ve tespit edilen hatalar hakkında bir rapor almak için önceden tanımlanmış ara sonuçları, günlük dosyalarını ve ayrıca sistem başlatılmadan önce yazılım sistemi tarafından gerçekleştirilen otomatik teşhisleri içerir. Bu gereksinimlerin bir başka türü, yazılım arızalarının nedenlerini tespit etmek için bakım teknisyenleri tarafından uygulanan otomatik teşhis kontrolleriyle ilgilidir.

Ürün Geçiş Yazılımı Kalite Faktörü

McCall'ın modeline göre, yazılımın diğer ortamlara uyarlanması ve diğer yazılım sistemleriyle etkileşimi ile ilgilenen ürün geçiş kategorisine üç yazılım kalite faktörü dahil edilmiştir. Bu faktörler aşağıdaki gibidir -

Taşınabilirlik

Taşınabilirlik gereksinimleri, bir yazılım sisteminin farklı donanım, farklı işletim sistemleri ve benzerlerinden oluşan diğer ortamlara uyarlanmasına yöneliktir. Yazılım, farklı durumlarda aynı temel yazılımı kullanmaya devam edebilmelidir.

Tekrar Kullanılabilirlik

Bu faktör, halihazırda geliştirilmekte olan yeni bir yazılım projesinde bir proje için orijinal olarak tasarlanmış yazılım modüllerinin kullanımı ile ilgilidir. Ayrıca gelecekteki projelerin belirli bir modülden veya halihazırda geliştirilen yazılımın bir grup modülünden yararlanmasını da sağlayabilirler. Yazılımın yeniden kullanımının geliştirme kaynaklarından tasarruf etmesi, geliştirme süresini kısaltması ve daha kaliteli modüller sunması beklenmektedir.

Birlikte çalışabilirlik

Birlikte çalışabilirlik gereksinimleri, diğer yazılım sistemleri veya diğer ekipman ürün yazılımları ile arayüzler oluşturmaya odaklanır. Örneğin, üretim makinelerinin donanım yazılımı ve test ekipmanı, üretim kontrol yazılımı ile arayüz oluşturur.

Software Quality Assurance(SQA), yazılım mühendisliği süreçlerinde kaliteyi sağlamaya yönelik bir dizi faaliyettir. Geliştirilen yazılımın tanımlanan veya standartlaştırılmış kalite spesifikasyonlarını karşılamasını ve bunlara uymasını sağlar. SQA, Yazılım Geliştirme Yaşam Döngüsü (SDLC) dahilinde, istenen kalite önlemlerini karşıladığından emin olmak için geliştirilen yazılımı rutin olarak kontrol eden devam eden bir süreçtir.

SQA uygulamaları, kullanılan temel yazılım geliştirme modeline bakılmaksızın, çoğu yazılım geliştirme türünde uygulanmaktadır. SQA, yazılımı test etmek için yazılım test metodolojilerini birleştirir ve uygular. Tamamlandıktan sonra kaliteyi kontrol etmek yerine, SQA süreçleri, yazılım tamamlanana kadar geliştirmenin her aşamasında kaliteyi test eder. SQA ile yazılım geliştirme süreci, yalnızca mevcut / önceki aşama gerekli kalite standartlarına uygun olduğunda sonraki aşamaya geçer. SQA genellikle, yazılım kalitesi yönergeleri ve uygulama stratejileri oluşturmaya yardımcı olan bir veya daha fazla endüstri standardı üzerinde çalışır.

Aşağıdaki faaliyetleri içerir -

• Süreç tanımı ve uygulaması
• Auditing
• Training

Süreçler şunlar olabilir -

• Yazılım Geliştirme Metodolojisi
• Proje Yönetimi
• Konfigürasyon yönetimi
• Gereksinim Geliştirme / Yönetim
• Estimation
• Yazılım Tasarımı
• Test vb.

Süreçler tanımlandıktan ve uygulandıktan sonra, Kalite Güvencesi aşağıdaki sorumluluklara sahiptir:

• Süreçlerdeki zayıflıkları tespit edin
• Süreci sürekli iyileştirmek için bu zayıflıkları düzeltin

SQA Sisteminin Bileşenleri

Bir SQA sistemi her zaman çok çeşitli SQA bileşenlerini birleştirir. Bu bileşenler aşağıdaki altı sınıfa ayrılabilir -

Ön proje bileşenleri

Bu, proje taahhütlerinin gerekli kaynaklar, program ve bütçe dikkate alınarak açıkça tanımlandığını garanti eder; geliştirme ve kalite planları doğru bir şekilde belirlenmiştir.

Proje yaşam döngüsü aktiviteleri değerlendirmesinin bileşenleri

Proje yaşam döngüsü iki aşamadan oluşur: geliştirme yaşam döngüsü aşaması ve işletme-bakım aşaması.

Geliştirme yaşam döngüsü aşaması bileşenleri, tasarım ve programlama hatalarını tespit eder. Bileşenleri aşağıdaki alt sınıflara ayrılmıştır: İncelemeler, Uzman görüşleri ve Yazılım testi.

İşletme-bakım aşamasında kullanılan SQA bileşenleri, temel olarak bakım görevlerini iyileştirme işlevselliği için uygulanan özel bakım bileşenlerinin yanı sıra geliştirme yaşam döngüsü bileşenlerini içerir.

Altyapı hatası önleme ve iyileştirmenin bileşenleri

Kuruluşun tamamında uygulanan bu bileşenlerin temel amacı, kuruluşun birikmiş SQA deneyimine dayalı olarak hata oranını ortadan kaldırmak veya en azından azaltmaktır.

Yazılım kalite yönetiminin bileşenleri

Bu bileşen sınıfı, geliştirme ve bakım faaliyetlerinin kontrolü ve esas olarak program ve bütçe hatalarını ve bunların sonuçlarını önleyen veya en aza indiren erken yönetimsel destek eylemlerinin tanıtımı gibi çeşitli hedeflerle ilgilenir.

Standardizasyon, sertifikasyon ve SQA sistem değerlendirmesinin bileşenleri

Bu bileşenler, organizasyon içinde uluslararası profesyonel ve yönetsel standartları uygular. Bu sınıfın temel hedefleri, uluslararası mesleki bilginin kullanılması, örgütsel kalite sistemlerinin diğer kuruluşlarla koordinasyonunun geliştirilmesi ve kalite sistemlerinin başarılarının ortak bir ölçeğe göre değerlendirilmesidir. Çeşitli standartlar iki ana grupta sınıflandırılabilir: kalite yönetim standartları ve proje süreci standartları.

SQA için organizasyon - insan bileşenleri

SQA organizasyon tabanı, yöneticileri, test personelini, SQA birimini ve SQA mütevellileri, SQA komitesi üyeleri ve SQA forum üyeleri gibi yazılım kalitesiyle ilgilenen kişileri içerir. Ana hedefleri, SQA bileşenlerinin uygulanmasını başlatmak ve desteklemek, SQA prosedürlerinden ve metodolojisinden sapmaları tespit etmek ve iyileştirmeler önermektir.

Ön proje Yazılım Kalitesi Bileşenleri

Bu bileşenler, bir projeye başlamadan önce atılan ön adımların iyileştirilmesine yardımcı olur. İçerir -

• Sözleşme İnceleme
• Geliştirme ve Kalite Planları

Sözleşme İnceleme

Normalde, bir müşteri ile müzakere edilen bir sözleşme için veya bir donanım ürününün içine yerleştirilecek bir ürün yazılımı geliştirmek için bir dahili sipariş için bir yazılım geliştirilir. Tüm bu durumlarda, geliştirme birimi üzerinde mutabık kalınan bir işlevsel şartnameye, bütçeye ve takvime bağlıdır. Bu nedenle, sözleşme gözden geçirme faaliyetleri proje teklifi taslağının ve sözleşme taslaklarının ayrıntılı bir incelemesini içermelidir.

Özellikle, sözleşme gözden geçirme faaliyetleri şunları içerir:

• Müşterinin gereksinimlerinin açıklanması

• Projenin takviminin ve kaynak gereksinimi tahminlerinin gözden geçirilmesi

• Profesyonel personelin önerilen projeyi gerçekleştirme kapasitesinin değerlendirilmesi

• Müşterinin yükümlülüklerini yerine getirme kapasitesinin değerlendirilmesi

• Geliştirme risklerinin değerlendirilmesi

Geliştirme ve Kalite Planları

Bir organizasyonla veya aynı organizasyonun iç departmanıyla yazılım geliştirme sözleşmesi imzalandıktan sonra, projenin bir geliştirme planı ve entegre kalite güvence faaliyetleri hazırlanır. Bu planlar, mevcut teklif ve sözleşmenin temelini oluşturan önceki planlara dayalı olarak ek ayrıntıları ve gerekli revizyonları içerir.

Çoğu zaman, teklifin sunulması ile sözleşmenin imzalanması arasında birkaç ay geçmesi gerekir. Bu dönemlerde personel mevcudiyeti, profesyonel yetenekler gibi kaynaklar değişebilir. Planlar daha sonra, ara dönemde meydana gelen değişiklikleri yansıtacak şekilde revize edilir.

Proje geliştirme planında ele alınan ana konular şunlardır:

• Schedules
• Gerekli insan gücü ve donanım kaynakları
• Risk değerlendirmeleri
• Örgütsel sorunlar: ekip üyeleri, alt yükleniciler ve ortaklıklar
• Proje metodolojisi, geliştirme araçları vb.
• Yazılım yeniden kullanım planları

Projenin kalite planında ele alınan ana konular şunlardır:

• Uygun ölçülebilir terimlerle ifade edilen kalite hedefleri

• Her proje aşamasına başlama ve bitirme kriterleri

• İnceleme listeleri, testler ve diğer planlanmış doğrulama ve doğrulama faaliyetleri

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çümler, 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ı ölçümler 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 metriklerinden çok süreç ve ürün ölçümleriyle 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çütleri

Ü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 havayolu trafik kontrol sistemleri, aviyonikler ve silahlar gibi güvenlik açısından kritik sistemlerde 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 dayanarak, analizin amacına bağlı olarak küçük farklılıklar içeren 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 testi 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
• Faz bazlı 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 kusur 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 araştırıp 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 birçok düzeltme henüz sisteme 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.

Faz bazlı 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

Şu şekilde tanımlanabilir -

$$DRE = \frac{Defect \: removed \: during \: a \: development\:phase }{Defects\: latent \: in \: the\: product} \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 hale gelme hızı ile 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{Number \: of \: problems \: closed \: during \:the \:month }{Number \: of \: problems \: arrived \: during \:the \:month} \times 100\%$$

BMI 100'den büyükse, birikmiş yığının 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 süresi ve kişinin müşteriye olan bağlılığını karşılama becerisidir.

Geciken düzeltme yüzdesi

Aşağıdaki gibi hesaplanır -

$Percent \:Delinquent\: Fixes =$

$\frac{Number \: of \: fixes \: that\: exceeded \: the \:response \:time\:criteria\:by\:ceverity\:level}{Number \: of \: fixes \: delivered \: in \:a \:specified \:time} \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 düzelttikten sonra yeni bir kusur enjekte ettiyse kusurludur. Görev açısından kritik yazılımlar için, hatalı düzeltmeler müşteri memnuniyeti açısından zararlıdır. Hatalı düzeltmelerin yüzdesinin ölçüsü, 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, kusurlu 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.

Ölçüm, bir şeyi ölçmek eylemidir. Diğer nesneler veya olaylarla karşılaştırılabilen, bir nesnenin veya olayın bir özelliğine bir sayı atanmasıdır.

Resmi olarak, gerçek dünyadaki varlıkların niteliklerine, onları açıkça tanımlanmış kurallara göre tanımlayacak şekilde, sayıların veya sembollerin atandığı süreç olarak tanımlanabilir.

Günlük Yaşamda Ölçüm

Ölçüm yalnızca profesyonel teknoloji uzmanları tarafından değil, aynı zamanda hepimiz tarafından günlük yaşamda da kullanılır. Bir dükkanda fiyat, bir öğenin değerinin bir ölçüsü olarak hareket eder. Benzer şekilde, boy ve beden ölçüleri de kumaşın tam oturup oturmayacağını garanti edecektir. Böylece ölçüm, bir öğeyi bir başkasıyla karşılaştırmamıza yardımcı olacaktır.

Ölçüm, varlıkların nitelikleri hakkındaki bilgileri alır. Varlık, kişi gibi bir nesnedir veya gerçek dünyadaki bir yolculuk gibi bir olaydır. Bir öznitelik, bir kişinin boyu, bir yolculuğun maliyeti vb. Gibi bir varlığın bir özelliği veya özelliğidir. Gerçek dünyada, şeyleri ölçmeyi düşünsek bile, aslında bu şeylerin özelliklerini ölçüyoruz.

Nitelikler çoğunlukla sayılar veya sembollerle tanımlanır. Örneğin fiyat rupi veya dolar sayısı olarak, giyim bedeni ise küçük, orta, büyük olarak belirtilebilir.

Bir ölçümün doğruluğu, ölçüm cihazına ve ölçümün tanımına bağlıdır. Ölçümleri aldıktan sonra onları analiz etmeliyiz ve varlıklar hakkında sonuçlar çıkarmalıyız.

Ölçüm doğrudan bir nicelemedir, oysa hesaplama, bazı formülleri kullanarak farklı ölçümleri birleştirdiğimiz dolaylı bir işlemdir.

Yazılım Mühendisliğinde Ölçüm

Yazılım Mühendisliği, yazılım ürünlerini yönetmeyi, maliyetlendirmeyi, planlamayı, modellemeyi, analiz etmeyi, belirlemeyi, tasarlamayı, uygulamayı, test etmeyi ve bakımını içerir. Bu nedenle ölçüm, yazılım mühendisliğinde önemli bir rol oynar. Bir yazılım ürününün niteliklerini ölçmek için titiz bir yaklaşım gerekli olacaktır.

Geliştirme projelerinin çoğu için,

• Yazılım ürünlerimiz için ölçülebilir hedefler belirleyemiyoruz
• Yazılım projelerinin bileşen maliyetini anlayamıyoruz ve ölçemiyoruz
• Ürettiğimiz ürünlerin kalitesini ölçmüyor veya tahmin etmiyoruz

Bu nedenle, yazılım ürünlerini kontrol etmek için özelliklerin ölçülmesi gereklidir. Her ölçüm eylemi, açıkça tanımlanmış ve kolayca anlaşılabilir belirli bir hedef veya ihtiyaç tarafından motive edilmelidir. Ölçüm hedefleri spesifik olmalı, yöneticilerin, geliştiricilerin ve kullanıcıların bilmesi gerekenlere göre denenmelidir. Projenin, ürünün, süreçlerin ve kaynakların durumunu değerlendirmek için ölçüm gereklidir.

Yazılım mühendisliğinde ölçüm, aşağıdaki üç temel faaliyet için gereklidir:

• Geliştirme ve bakım sırasında neler olduğunu anlamak
• Projede neler olduğunu kontrol etmek için
• Süreçleri ve hedefleri iyileştirmek için

Temsili Ölçüm Teorisi

Ölçüm, bize her türlü ölçüm hakkında geliştirme ve muhakeme için zemin hazırlayan kuralları anlatır. Bu, deneysel dünyadan biçimsel ilişkisel dünyaya doğru bir haritadır. Sonuç olarak, ölçü, bir varlığı karakterize etmek için bu eşleme tarafından bir varlığa atanan sayı veya semboldür.

Ampirik İlişkiler

Gerçek dünyada, olayları sayı atayarak değil, karşılaştırarak anlarız.

Örneğin, yüksekliği karşılaştırmak için 'daha uzun', daha yüksek 'terimlerini kullanırız. Dolayısıyla, bu "daha uzun", "daha yüksek" yükseklik için ampirik ilişkilerdir.

Aynı küme üzerinde birden fazla ampirik ilişki tanımlayabiliriz.

Örneğin, X, Y'den daha uzundur. X, Y, Z'den çok daha uzundur.

Ampirik ilişkiler tekli, ikili, üçlü vb. Olabilir.

X uzun, Y uzun değil, tekli ilişkiler.

X, Y'den daha uzun bir ikili ilişkidir.

Gerçek dünyadaki ampirik ilişkiler, resmi bir matematiksel dünya ile eşleştirilebilir. Çoğunlukla bu ilişkiler kişisel tercihleri ​​yansıtır.

Bu deneysel ilişkileri matematiksel dünyayla haritalamak için kullanılan bazı haritalama veya derecelendirme tekniği aşağıdaki gibidir:

Likert Ölçeği

Burada, kullanıcılara hemfikir olmaları veya katılmamaları gereken bir ifade verilecektir.

For example - Bu yazılım iyi performans gösteriyor.

Kesinlikle katılıyorum	Katılıyorum	Ne katılıyorum ne katılmıyorum	Katılmıyorum	Kesinlikle Disgaree

Zorunlu Sıralama

Verilen alternatifleri 1'den (en iyi) n'ye (en kötü) doğru sıralayın.

Örneğin: Aşağıdaki 5 yazılım modülünü performanslarına göre sıralayın.

Modül Adı	Sıra
Modül A
Modül B
Modül C
Modül D
Modül E

Sözel Frekans Ölçeği

For example - Bu program ne sıklıkla başarısız oluyor?

Her zaman	Sıklıkla	Ara sıra	Nadiren	Asla

Sıra Ölçeği

Burada kullanıcılara bir alternatifler listesi verilecek ve birini seçmeleri gerekecek.

For example - Bu program ne sıklıkla başarısız oluyor?

• Hourly
• Daily
• Weekly
• Monthly
• Yılda birkaç defa
• Yılda bir ya da iki kez
• Never

Karşılaştırmalı Ölçek

Burada kullanıcının farklı seçenekleri karşılaştırarak bir numara vermesi gerekmektedir.

Very superiorAbout the sameVery inferior

12345678910

Sayısal Ölçek

Burada kullanıcının önemine göre bir sayı vermesi gerekmektedir.

UnimportantImportant

12345678910

Haritalama Kuralları

Eşlemeyi gerçekleştirmek için alan, aralık ve eşlemeyi gerçekleştirecek kuralları belirlememiz gerekir.

For example - Etki Alanı - Gerçek dünya

• Range - Tam sayılar, gerçek sayılar gibi matematiksel dünya

• Rules - Yükseklik ölçmek için ayakkabı giyilip giyilmeyecek

Benzer şekilde, yazılım ölçümü durumunda, ifadenin kontrol listesi belirtilecek kod satırlarında yer alacaktır.

Temsili Ölçme Koşulu

Temsili koşul, bir ölçüm eşlemesinin (M) varlıkları sayılarla ve deneysel ilişkileri sayısal ilişkilerle, deneysel ilişkiler koruyacak ve sayısal ilişkilerle korunacak şekilde eşlemelidir.

Örneğin: 'Daha uzun' ampirik ilişki '>' sayısal ilişkiyle eşleştirilir. Yani, X is taller than Y, if and only if M(X) > M(Y)

Belirli bir küme üzerinde birçok ilişki olabileceğinden, temsili koşul da bu ilişkilerin her biri için çıkarımlara sahiptir.

Tekli ilişki için 'uzun', sayısal ilişkiye sahip olabiliriz

X > 50

Temsili koşul, herhangi bir önlem için M,

X is tall if and only if M(X) > 50

Resmi Ölçümün Temel Aşamaları

Ölçmenin temel aşamaları şu şekilde özetlenebilir:

Modeller, gerçek dünyadaki varlıkların sayısal öğelerinin davranışını yorumlamak ve bunları ölçmek için kullanışlıdır. Ölçüm sürecine yardımcı olmak için, haritalama modeli, bir eşleme alanı modeli ile desteklenmelidir. Bir model aynı zamanda bu varlıkların özniteliklerle nasıl ilişkili olduğunu ve özelliklerin nasıl ilişkili olduğunu da belirtmelidir.

Ölçüm iki türdendir -

• Doğrudan ölçüm
• Dolaylı ölçüm

Doğrudan Ölçüm

Bunlar, başka herhangi bir varlık veya niteliğin katılımı olmadan ölçülebilen ölçümlerdir.

Aşağıdaki doğrudan önlemler genellikle yazılım mühendisliğinde kullanılır.

• LOC'ye göre kaynak kodun uzunluğu
• Geçen süreye göre test amacının süresi
• Kusurları sayarak test sürecinde keşfedilen kusurların sayısı
• Bir programcının bir programda geçirdiği zaman

Dolaylı Ölçüm

Bunlar, başka herhangi bir varlık veya nitelik açısından ölçülebilen ölçümlerdir.

Aşağıdaki dolaylı önlemler genellikle yazılım mühendisliğinde kullanılır.

$$\small Programmer\:Productivity = \frac{LOC \: produced }{Person \:months \:of \:effort}$$

$\small Module\:Defect\:Density = \frac{Number \:of\:defects}{Module \:size}$

$$\small Defect\:Detection\:Efficiency = \frac{Number \:of\:defects\:detected}{Total \:number \:of\:defects}$$

$\small Requirement\:Stability = \frac{Number \:of\:initial\:requirements}{Total \:number \:of\:requirements}$

$\small Test\:Effectiveness\:Ratio = \frac{Number \:of\:items\:covered}{Total \:number \:of \:items}$

$\small System\:spoilage = \frac{Effort \:spent\:for\:fixing\:faults}{Total \:project \:effort}$

Tahmin için Ölçüm

Projeye uygun kaynakları tahsis etmek için, projeyi geliştirmek için gereken çabayı, zamanı ve maliyeti tahmin etmemiz gerekir. Tahmin için ölçüm her zaman, tahmin edilecek nitelikleri şimdi ölçebileceğimiz başka bir nitelikle ilişkilendiren matematiksel bir model gerektirir. Dolayısıyla, bir tahmin sistemi, bilinmeyen parametreleri belirlemek ve sonuçları yorumlamak için bir dizi tahmin prosedürü ile birlikte matematiksel bir modelden oluşur.

Ölçüm ölçekleri, ampirik ilişki sistemini temsil etmek için kullanılan eşleştirmelerdir. Esas olarak 5 çeşittir -

• Nominal ölçek
• Sıra Ölçeği
• Aralık Ölçeği
• Oran ölçeği
• Mutlak Ölçek

Nominal ölçek

Öğeleri bir sınıflandırma şemasına yerleştirir. Sınıflar sipariş edilmeyecektir. Her varlık, özniteliğin değerine göre belirli bir sınıfa veya kategoriye yerleştirilmelidir.

İki ana özelliği vardır -

• Ampirik ilişki sistemi yalnızca farklı sınıflardan oluşur; sınıflar arasında bir düzen kavramı yoktur.

• Sınıfların herhangi bir farklı numaralandırma veya sembolik temsili kabul edilebilir bir ölçüdür, ancak sayılar veya sembollerle ilişkili büyüklük kavramı yoktur.

Sıra Ölçeği

Öğeleri sıralı bir sınıflandırma şemasına yerleştirir. Aşağıdaki özelliklere sahiptir -

• Ampirik ilişki sistemi, niteliğe göre sıralanan sınıflardan oluşur.

• Sıralamayı koruyan herhangi bir eşleştirme kabul edilebilir.

• Rakamlar yalnızca sıralamayı temsil eder. Bu nedenle toplama, çıkarma ve diğer aritmetik işlemlerin bir anlamı yoktur.

Aralık Ölçeği

Bu ölçek, sınıflandırmayı ayıran aralıkların boyutu hakkındaki bilgileri yakalar. Bu nedenle, nominal ölçekten ve sıra ölçekten daha güçlüdür.

Aşağıdaki özelliklere sahiptir -

• Sıralı ölçek gibi düzeni korur.

• Farklılıkları korur ama oranı korumaz.

• Bu ölçekte toplama ve çıkarma yapılabilir ancak çarpma veya bölme yapılamaz.

Bir öznitelik aralık ölçeğinde ölçülebilirse ve M ve M’ temsil koşulunu sağlayan eşleşmelerdir, bu durumda her zaman iki sayı bulabiliriz a ve b öyle ki,

M = aM '+ b

Oran ölçeği

Bu, en kullanışlı ölçüm ölçeğidir. Burada oranları yakalamak için ampirik bir ilişki vardır. Aşağıdaki özelliklere sahiptir -

• Sıralamayı, varlıklar arasındaki aralıkların boyutunu ve varlıklar arasındaki oranı koruyan bir ölçüm eşlemesidir.

• Özniteliklerin toplam eksikliğini temsil eden bir sıfır öğesi vardır.

• Ölçüm eşlemesi sıfırdan başlamalı ve birimler olarak bilinen eşit aralıklarla artmalıdır.

• Tüm aritmetik işlemler uygulanabilir.

Burada haritalama şeklinde olacak

M = aM’

Nerede ‘a’ pozitif bir skalerdir.

Mutlak Ölçek

Bu ölçekte, bir öznitelik için yalnızca bir olası ölçü olacaktır. Dolayısıyla, olası tek dönüşüm kimlik dönüşümü olacaktır.

Aşağıdaki özelliklere sahiptir -

• Ölçüm, varlık kümesindeki öğelerin sayısı sayılarak yapılır.

• Öznitelik her zaman "varlıktaki x oluşumlarının sayısı" biçimini alır.

• Yalnızca bir olası ölçüm eşlemesi vardır, yani gerçek sayım.

• Tüm aritmetik işlemler elde edilen sayıma göre gerçekleştirilebilir.

Ampirik Araştırmalar, herhangi bir aracın, tekniğin veya yöntemin bilimsel araştırmasını içerir. Bu araştırma esas olarak aşağıdaki 4 ilkeyi içermektedir.

• Bir araştırma tekniği seçmek
• Hipotezi belirtmek
• Değişken üzerindeki kontrolün sürdürülmesi
• Araştırmayı anlamlı kılmak

Bir Araştırma Tekniği Seçmek

Yazılım mühendisliğinde deneysel araştırmanın temel bileşenleri şunlardır:

• Survey
• Vaka Analizi
• Resmi deney

Anket

Anket, ilişkileri ve sonuçları belgelemek için bir durumun geriye dönük olarak incelenmesidir. Her zaman bir olay meydana geldikten sonra yapılır. Örneğin, yazılım mühendisliğinde, eğilimleri veya ilişkileri belirlemek için kullanıcıların belirli bir yönteme, araca veya tekniğe nasıl tepki verdiklerini belirlemek için anketler yapılabilir.

Bu durumda, elimizdeki durum üzerinde hiçbir kontrolümüz yoktur. Bir durumu kaydedebilir ve benzer bir durumla karşılaştırabiliriz.

Vaka Analizi

Bir faaliyetin sonucunu etkileyebilecek temel faktörleri belirlediğiniz ve ardından etkinliği belgelediğiniz bir araştırma tekniğidir: girdileri, kısıtlamaları, kaynakları ve çıktıları.

Resmi Deney

Sonuç üzerindeki etkilerini belgelemek için kilit faktörlerin belirlendiği ve manipüle edildiği, bir faaliyetin titiz bir kontrollü araştırmasıdır.

Aşağıdaki yönergelere göre belirli bir soruşturma yöntemi seçilebilir -

• Etkinlik zaten gerçekleşmişse, anket veya vaka çalışması yapabiliriz. Henüz gerçekleşmediyse, vaka çalışması veya resmi deney seçilebilir.

• Sonucu etkileyebilecek değişkenler üzerinde yüksek düzeyde kontrolümüz varsa, o zaman bir deney kullanabiliriz. Değişken üzerinde herhangi bir kontrolümüz yoksa, vaka çalışması tercih edilen bir teknik olacaktır.

• Daha yüksek seviyelerde çoğaltma mümkün değilse, o zaman deney yapmak mümkün değildir.

• Çoğaltma maliyeti düşükse, deney yapmayı düşünebiliriz.

Hipotezin Belirtilmesi

Belirli bir araştırma tekniğinin kararını artırmak için, araştırmanın amacı test etmek istediğimiz bir hipotez olarak ifade edilmelidir. Hipotez, programcının araştırmak istediği davranışı açıkladığını düşündüğü geçici teori veya varsayımdır.

Değişkenler Üzerindeki Kontrolü Sürdürmek

Hipotezi belirttikten sonra, onun gerçeğini etkileyen farklı değişkenlere ve onun üzerinde ne kadar kontrolümüz olduğuna karar vermeliyiz. Bu çok önemlidir, çünkü deney ve vaka çalışmaları arasındaki temel ayırıcı, davranışı etkileyen değişken üzerindeki kontrol derecesidir.

Resmi deneydeki kontrol durumunu deneysel olandan ayırt etmek için projeyi karakterize edebilen ve aynı zamanda değerlendirme sonuçlarını etkileyebilen faktör olan bir durum değişkeni kullanılır. Kontrolü deneyden ayırt edemezsek, vaka çalışması tekniği tercih edilecektir.

Örneğin, programlama dilindeki bir değişikliğin projenin üretkenliğini etkileyip etkilemeyeceğini belirlemek istiyorsak, o zaman dil bir durum değişkeni olacaktır. Şu anda Ada ile değiştirmek istediğimiz FORTRAN'ı kullandığımızı varsayalım. Daha sonra kontrol dili FORTRAN ve deneysel olan Ada olacaktır.

Araştırmayı Anlamlı Hale Getirme

Bir deneyin sonuçları genellikle vaka çalışması veya anketten daha genelleştirilebilir. Örnek olay incelemesinin veya anketin sonuçları normalde yalnızca belirli bir kuruluş için geçerli olabilir. Aşağıdaki noktalar, bu tekniklerin çeşitli soruları yanıtlamadaki etkinliğini kanıtlamaktadır.

Uygun teoriler ve geleneksel bilgelik

Tek bir organizasyonda geleneksel bilgeliğin ve diğer birçok standardın, yöntemin veya aracın etkililiğine ve faydasına uymak için vaka çalışmaları veya anketler kullanılabilir. Bununla birlikte, resmi deney, iddiaların genellikle doğru olduğu durumları araştırabilir.

İlişkileri keşfetmek

Kaynakların ve yazılım ürünlerinin çeşitli özellikleri arasındaki ilişki, bir vaka çalışması veya anket ile önerilebilir.

Örneğin, tamamlanan projelerin araştırılması, belirli bir dilde yazılmış bir yazılımın diğer dillerde yazılmış bir yazılıma göre daha az hatası olduğunu ortaya çıkarabilir.

Bu ilişkileri anlamak ve doğrulamak, gelecekteki tüm projelerin başarısı için çok önemlidir. Bu ilişkilerin her biri bir hipotez olarak ifade edilebilir ve ilişkilerin ne derece geçerli olduğunu test etmek için resmi bir deney tasarlanabilir. Genellikle, belirli bir özelliğin değeri, diğer özellikleri sabit veya kontrol altında tutarak gözlemlenir.

Modellerin doğruluğunun değerlendirilmesi

Modeller genellikle bir faaliyetin sonucunu tahmin etmek veya bir yöntem veya aracın kullanımına rehberlik etmek için kullanılır. Bir deney veya vaka çalışması tasarlarken özellikle zor bir problem sunar çünkü onların tahminleri genellikle sonucu etkiler. Proje yöneticileri genellikle tahminleri tamamlanma hedeflerine dönüştürür. Bu etki, maliyet ve zamanlama modelleri kullanıldığında yaygındır.

Güvenilirlik modelleri gibi bazı modeller sonucu etkilemez, çünkü ortalama arıza süresi olarak ölçülen güvenilirlik, yazılım sahada kullanıma hazır olana kadar değerlendirilemez.

Doğrulama önlemleri

Bir özelliğin değerini yakalamak için birçok yazılım ölçüsü vardır. Bu nedenle, belirli bir önlemin yakalaması beklenen nitelikteki değişiklikleri yansıtıp yansıtmadığını test etmek için bir çalışma yapılmalıdır. Doğrulama, bir ölçümün diğeriyle ilişkilendirilmesiyle gerçekleştirilir. Doğrulamak için aynı zamanda etkileyen faktörün doğrudan ve geçerli bir ölçüsü olan ikinci bir ölçü kullanılmalıdır. Bu tür önlemler her zaman mevcut değildir veya ölçülmesi kolay değildir. Ayrıca, kullanılan ölçümler, ölçülen faktörün insan kavramlarına uygun olmalıdır.

Yazılım ölçümü çerçevesi üç ilkeye dayanmaktadır:

• İncelenecek varlıkların sınıflandırılması
• İlgili ölçüm hedeflerinin belirlenmesi
• Kuruluşun ulaştığı olgunluk düzeyinin belirlenmesi

İncelenecek Varlıkların Sınıflandırılması

Yazılım mühendisliğinde, esas olarak üç sınıf varlık mevcuttur. Onlar -

• Processes
• Products
• Resources

Tüm bu varlıkların hem iç hem de dış varlıkları vardır.

• Internal attributestamamen süreç, ürün veya kaynakların kendisi açısından ölçülebilenlerdir. Örneğin: Boyut, karmaşıklık, modüller arası bağımlılık.

• External attributessadece çevre ile ilişkisi açısından ölçülebilenlerdir. Örneğin: Bir kullanıcının yaşadığı toplam arıza sayısı, veritabanında arama yapmak ve bilgi almak için geçen süre.

Varlıkların her biri için ölçülebilen farklı özellikler aşağıdaki gibidir -

Süreçler

Süreçler, yazılımla ilgili faaliyetlerin koleksiyonlarıdır. Aşağıda, bir işlem için doğrudan ölçülebilen bazı dahili özellikler verilmiştir -

• Sürecin veya faaliyetlerinden birinin süresi

• Süreç veya faaliyetlerinden biriyle ilişkili çaba

• Süreç veya faaliyetlerinden biri sırasında ortaya çıkan belirli bir türdeki olayların sayısı

Bir sürecin farklı dış nitelikleri maliyet, kontrol edilebilirlik, etkinlik, kalite ve istikrartır.

Ürün:% s

Ürünler yalnızca yönetimin teslim etmeyi taahhüt ettiği öğeler değil, aynı zamanda yazılım yaşam döngüsü boyunca üretilen herhangi bir yapı veya belgedir.

Farklı dahili ürün özellikleri boyut, çaba, maliyet, belirtim, uzunluk, işlevsellik, modülerlik, yeniden kullanım, fazlalık ve sözdizimsel doğruluktur. Bu boyut, çaba ve maliyetin ölçülmesi diğerlerine göre nispeten kolaydır.

Farklı harici ürün özellikleri, kullanılabilirlik, bütünlük, verimlilik, test edilebilirlik, yeniden kullanılabilirlik, taşınabilirlik ve birlikte çalışabilirliktir. Bu özellikler yalnızca kodu değil, aynı zamanda geliştirme çabasını destekleyen diğer belgeleri de tanımlar.

Kaynaklar

Bunlar, bir süreç aktivitesi için gerekli olan varlıklardır. Yazılım üretimi için herhangi bir girdi olabilir. Personeli, malzemeleri, araçları ve yöntemleri içerir.

Kaynaklar için farklı iç özellikler yaş, fiyat, boyut, hız, bellek boyutu, sıcaklık vb .'dir. Farklı dış özellikler üretkenlik, deneyim, kalite, kullanılabilirlik, güvenilirlik, rahatlık vb.

İlgili Ölçüm Hedeflerini Belirleme

Belirli bir ölçüm, yalnızca süreci veya sonuç ürünlerinden birini anlamaya yardımcı olursa faydalı olacaktır. Süreç veya ürünlerdeki iyileştirme ancak proje süreçler ve ürünler için açıkça tanımlanmış hedeflere sahip olduğunda gerçekleştirilebilir. Süreç olgunluk çerçevesi bağlamında belirli bir proje için önerilen ölçütleri oluşturmak için hedeflerin net bir şekilde anlaşılması kullanılabilir.

Hedef – Soru – Metrik (GQM) paradigması

GQM yaklaşımı, aşağıdaki üç adımı içeren bir çerçeve sağlar:

• Geliştirme veya bakım projesinin ana hedeflerini listelemek

• Hedeflere ulaşılıp ulaşılmadığını belirlemek için cevaplanması gereken her hedeften soruları türetmek

• Soruları yeterince cevaplayabilmek için neyin ölçülmesi gerektiğine karar verin

GQM paradigmasını kullanmak için önce kuruluşun genel hedeflerini ifade ederiz. Ardından, hedeflere ulaşılıp ulaşılmadığını belirleyebilmemiz için cevapları bilinecek şekilde sorular oluştururuz. Daha sonra, her soruyu yanıtlamak için her soruyu hangi ölçüme ihtiyacımız olduğuna göre analiz edin.

Tipik hedefler üretkenlik, kalite, risk, müşteri memnuniyeti vb. Açısından ifade edilir. Hedefler ve sorular hedef kitleleri açısından oluşturulmalıdır.

Basili & Rombach, hedefleri, soruları ve ölçütleri oluşturmaya yardımcı olmak için bir dizi şablon sağladı.

• Purpose - Anlamak, değerlendirmek, yönetmek, mühendislik yapmak, öğrenmek, iyileştirmek vb. İçin (süreci, ürünü, modeli, metrik vb.) Example: Ürünü öğrenmek için karakterize etmek.

• Perspective - Geliştirici, yönetici, müşteri vb. Bakış açısından (maliyet, etkinlik, doğruluk, kusurlar, değişiklikler, ürün ölçüleri vb.) Example: Kusurları müşterinin bakış açısından inceleyin.

• Environment - Ortam şunlardan oluşur: süreç faktörleri, insan faktörleri, problem faktörleri, yöntemler, araçlar, kısıtlamalar vb. Example: Bu yazılımın müşterileri, araçlar hakkında hiçbir bilgisi olmayan kişilerdir.

Ölçüm ve Süreç İyileştirme

Normalde ölçüm aşağıdakiler için yararlıdır:

• Süreci ve ürünleri anlamak
• Bir temel oluşturmak
• Sonuca erişmek ve tahmin etmek

SEI tarafından verilen sürecin olgunluk seviyesine göre ölçüm türü ve ölçüm programı farklı olacaktır. Aşağıda, her bir olgunluk düzeyinde uygulanabilecek farklı ölçüm programları bulunmaktadır.

Level 1: Ad hoc

Bu seviyede girdiler yanlış tanımlanırken çıktılar beklenir. Girdiden çıktıya geçiş tanımsız ve kontrolsüzdür. Bu süreç olgunluğu seviyesi için, ölçüm için bir başlangıç ​​noktası sağlamak üzere temel ölçümlere ihtiyaç vardır.

Level 2: Repeatable

Bu seviyede, sürecin girdi ve çıktıları, kısıtlamaları ve kaynakları belirlenebilir. Tekrarlanabilir bir süreç aşağıdaki diyagramla açıklanabilir.

Girdi ölçüleri, gereksinimlerin boyutu ve değişkenliği olabilir. Çıktı, sistem boyutu, personel çabası açısından kaynaklar ve maliyet ve program açısından kısıtlamalar açısından ölçülebilir.

Level 3: Defined

Bu seviyede ara faaliyetler tanımlanır ve bunların girdileri ve çıktıları bilinir ve anlaşılır. Tanımlanan işlemin basit bir örneği aşağıdaki şekilde açıklanmaktadır.

Ara faaliyetlerin girdisi ve çıktısı incelenebilir, ölçülebilir ve değerlendirilebilir.

Level 4: Managed

Bu düzeyde, erken proje faaliyetlerinden gelen geri bildirimler, mevcut faaliyetler için ve daha sonra proje faaliyetleri için öncelikleri belirlemek için kullanılabilir. Süreç faaliyetlerinin etkinliğini ölçebiliriz. Ölçüm, genel sürecin özelliklerini ve ana faaliyetler arasındaki ve arasındaki etkileşimin özelliklerini yansıtır.

Level 5: Optimizing

Bu seviyede, faaliyetlerden alınan önlemler, ölçüm geri bildirimlerine yanıt olarak süreç etkinliklerini kaldırıp ekleyerek ve süreç yapısını dinamik olarak değiştirerek süreci iyileştirmek için kullanılır. Böylece süreç değişikliği, organizasyonu ve projeyi olduğu kadar süreci de etkileyebilir. Süreç, sensörler ve monitörler olarak hareket edecek ve uyarı işaretlerine yanıt olarak süreci önemli ölçüde değiştirebiliriz.

Belirli bir olgunluk seviyesinde, o seviye ve altındaki tüm seviyeler için ölçümleri toplayabiliriz.

Olgunluk Düzeyini Belirleme

Süreç olgunluğu yalnızca görünür olanı ölçmeyi önerir. Bu nedenle, süreç olgunluğunun GQM ile kombinasyonu en yararlı önlemleri sağlayacaktır.

• Şurada: level 1, projenin kötü tanımlanmış gereksinimleri olması muhtemeldir. Bu seviyede, ihtiyaç özelliklerinin ölçülmesi zordur.

• Şurada: level 2, gereksinimler iyi tanımlanmıştır ve her gereksinimin türü ve her türdeki değişiklik sayısı gibi ek bilgiler toplanabilir.

• Şurada: level 3ara faaliyetler, her faaliyet için giriş ve çıkış kriterleri ile tanımlanır

Hedef ve soru analizi aynı olacaktır, ancak metrik olgunluğa göre değişecektir. Süreç ne kadar olgunlaşırsa ölçümler o kadar zengin olacaktır. GQM paradigması, süreç olgunluğuyla uyumlu olarak, yöneticilere ölçüm programlarının tasarlanmasında yardımcı olan çeşitli araçlar için temel olarak kullanılmıştır.

GQM, özniteliğin ölçülmesi ihtiyacının anlaşılmasına yardımcı olur ve süreç olgunluğu, onu anlamlı bir şekilde ölçüp ölçemeyeceğimizi gösterir. Birlikte ölçüm için bir bağlam sağlarlar.

Yazılım sisteminin ölçümünün doğrulanması iki adımdan oluşur -

• Ölçüm sistemlerini doğrulama
• Tahmin sistemlerini doğrulama

Ölçüm Sistemlerini Doğrulama

Ölçüler veya ölçüm sistemleri, bir veya daha fazla niteliğini sayısal olarak karakterize ederek mevcut bir varlığı değerlendirmek için kullanılır. Bir ölçü, ölçmeyi iddia ettiği özniteliği doğru bir şekilde karakterize ediyorsa geçerlidir.

Bir yazılım ölçüm sisteminin doğrulanması, temsil koşulunun karşılandığını göstererek ölçünün iddia edilen özniteliğin uygun bir sayısal karakterizasyonu olmasını sağlama sürecidir.

Bir ölçüm sistemini doğrulamak için hem varlıkları tanımlayan resmi bir modele hem de ölçtüğümüz özelliği koruyan sayısal bir eşlemeye ihtiyacımız var. Örneğin, iki program P1 ve P2 varsa ve bu programları birleştirmek istiyorsak, o zaman herhangi bir ölçününm bunu tatmin edecek uzunlukta,

m (P1 + P2) = m (P1) + m (P2)

Bir program P1 programdan daha uzun P2, sonra herhangi bir ölçü m ayrıca tatmin etmeli,

m (P1)> m (P2)

Programın uzunluğu kod satırları sayılarak ölçülebilir. Bu sayı yukarıdaki ilişkileri karşılarsa, kod satırlarının uzunluk için geçerli bir ölçü olduğunu söyleyebiliriz.

Bir ölçüyü doğrulamak için resmi gereklilik, ölçüm teorisi anlamında belirtilen niteliği karakterize ettiğini göstermeyi içerir. Doğrulama, ölçücülerin doğru bir şekilde tanımlandığından ve kurumun gerçek dünya davranışıyla tutarlı olduğundan emin olmak için kullanılabilir.

Tahmin Sistemlerini Doğrulama

Tahmin sistemleri, ilişkili tahmin prosedürleri ile matematiksel bir modeli içeren gelecekteki bir varlığın bazı özelliklerini tahmin etmek için kullanılır.

Belirli bir ortamda tahmin sistemlerinin doğrulanması, tahmin sisteminin doğruluğunu deneysel yollarla, yani model performansını belirli bir ortamda bilinen verilerle karşılaştırarak oluşturma sürecidir. Deney ve hipotez testini içerir.

Doğrulama için kabul edilebilir doğruluk derecesi, tahmin sisteminin deterministik mi yoksa stokastik mi olduğuna ve değerlendirmeyi yapan kişiye bağlıdır. Bazı stokastik tahmin sistemleri diğerlerinden daha stokastiktir.

Stokastik tahmin sistemlerinin örnekleri, yazılım maliyeti tahmini, efor tahmini, zamanlama tahmini vb. Gibi sistemlerdir. Bu nedenle, bir tahmin sistemini resmi olarak doğrulamak için, ne kadar stokastik olduğuna karar vermeli ve ardından tahmin sisteminin performansını bilinen verilerle karşılaştırmalıyız.

Yazılım ölçütleri, bir dereceye kadar ölçüm içeren birçok faaliyeti içeren bir ölçü standardıdır. Üç kategoriye ayrılabilir: ürün ölçümleri, süreç ölçümleri ve proje ölçümleri.

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

• Process metricsyazılım geliştirme ve bakımı iyileştirmek için kullanılabilir. Örnekler, geliştirme sırasında kusur gidermenin etkililiğini, hatanın gelişini test etme modelini ve düzeltme işleminin yanıt süresini içerir.

• Project metricsProje ö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ı ölçümler 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.

Yazılım Metriklerinin Kapsamı

Yazılım ölçümleri, aşağıdakileri içeren birçok etkinliği içerir -

• Maliyet ve çaba tahmini
• Verimlilik ölçüleri ve modeli
• Veri toplama
• Miktar modelleri ve ölçüler
• Güvenilirlik modelleri
• Performans ve değerlendirme modelleri
• Yapısal ve karmaşıklık metrikleri
• Yetenek - olgunluk değerlendirmesi
• Ölçümlere göre yönetim
• Yöntem ve araçların değerlendirilmesi

Yazılım ölçümü, belirli bir aşamada yazılım proje maliyetlerini tahmin eden modellerden program yapısı ölçümlerine kadar uzanan bu faaliyetlerin çeşitli bir koleksiyonudur.

Maliyet ve Çaba Tahmini

Çaba, programın boyutu, geliştiricilerin kapasitesi ve yeniden kullanım düzeyi gibi bir veya daha fazla değişkenin fonksiyonu olarak ifade edilir. Yazılım yaşam döngüsünün erken aşamalarında proje maliyetini tahmin etmek için maliyet ve iş gücü tahmin modelleri önerilmiştir. Önerilen farklı modeller -

• Boehm'in COCOMO modeli
• Putnam'ın ince modeli
• Albrecht'in fonksiyon noktası modeli

Verimlilik Modeli ve Ölçüler

Verimlilik, değer ve maliyetin bir fonksiyonu olarak düşünülebilir. Her biri farklı ölçülebilir büyüklük, işlevsellik, zaman, para vb. Olarak ayrıştırılabilir. Bir üretkenlik modelinin farklı olası bileşenleri aşağıdaki diyagramda ifade edilebilir.

Veri toplama

Herhangi bir ölçüm programının kalitesi açıkça dikkatli veri toplamaya bağlıdır. Toplanan veriler, yöneticilerin gelişimin ilerlemesini ve problemini anlayabilmesi için basit çizelge ve grafiklere ayrılabilir. Veri toplama, ilişkilerin ve eğilimlerin bilimsel araştırılması için de gereklidir.

Kaliteli Modeller ve Ölçüler

Verimliliğin anlamsız olduğu ürün kalitesinin ölçülmesi için kalite modelleri geliştirilmiştir. Bu kaliteli modeller, doğru üretkenliği ölçmek için üretkenlik modeliyle birleştirilebilir. Bu modeller genellikle ağaç benzeri bir şekilde inşa edilir. Üst dallar, güvenilirlik ve kullanılabilirlik gibi önemli üst düzey kalite faktörlerine sahiptir.

Böl ve yönet yaklaşımı kavramı, yazılım kalitesini ölçmek için standart bir yaklaşım olarak uygulanmıştır.

Güvenilirlik Modelleri

Çoğu kalite modeli, bir bileşen faktörü olarak güvenilirliği içerir, ancak güvenilirliği tahmin etme ve ölçme ihtiyacı, güvenilirlik modellemesi ve tahmininde ayrı bir uzmanlaşmaya yol açmıştır. Güvenilirlik teorisindeki temel sorun, bir sistemin sonunda ne zaman başarısız olacağını tahmin etmektir.

Performans Değerlendirmesi ve Modelleri

Yanıt süreleri ve tamamlanma oranları gibi dışarıdan gözlemlenebilir sistem performans özelliklerini ve algoritmaların verimliliği gibi sistemin dahili çalışmasını içerir. Kalitenin başka bir yönüdür.

Yapısal ve Karmaşıklık Metrikleri

Burada, uygulama öncesinde mevcut olan yazılım temsillerinin yapısal özelliklerini ölçüyoruz. Daha sonra kalite güvencesini, kalite kontrolünü ve kalite tahminini desteklemek için ampirik olarak öngörücü teoriler oluşturmaya çalışıyoruz.

Yetenek Olgunluk Değerlendirmesi

Bu model, araçların kullanımı, standart uygulamalar ve daha fazlası dahil olmak üzere birçok farklı geliştirme özelliğini değerlendirebilir. Her iyi yüklenicinin kullanması gereken temel uygulamalara dayanmaktadır.

Metriklere Göre Yönetim

Yazılım projesini yönetmek için ölçüm hayati bir role sahiptir. Projenin yolunda olup olmadığını kontrol etmek için kullanıcılar ve geliştiriciler ölçüm tabanlı tablo ve grafiğe güvenebilirler. Standart ölçümler ve raporlama yöntemleri seti, müşterilerin genellikle yazılım terminolojisine hakim olmadığı bir ürüne yazılım yerleştirildiğinde özellikle önemlidir.

Yöntem ve Araçların Değerlendirilmesi

Bu, deneysel tasarıma, sonucu etkilemesi muhtemel faktörlerin uygun şekilde tanımlanmasına ve faktör özelliklerinin uygun şekilde ölçülmesine bağlıdır.

Yazılım metrikleri, bir dereceye kadar ölçüm içeren birçok faaliyeti içeren bir ölçü standardıdır. Yazılım ölçümündeki başarı, toplanan ve analiz edilen verilerin kalitesindedir.

İyi Veri nedir?

Toplanan veriler, aşağıdaki soruların yanıtlarını üretebiliyorsa, iyi bir veri olarak kabul edilebilir:

• Are they correct? - Bir veri, metrik tanımının tam kurallarına göre toplanmışsa doğru kabul edilebilir.

• Are they accurate? - Doğruluk, veriler ile gerçek değer arasındaki farkı ifade eder.

• Are they appropriately precise? - Kesinlik, verileri ifade etmek için gereken ondalık basamak sayısıyla ilgilenir.

• Are they consistent? - Bir ölçüm cihazından diğerine önemli bir fark göstermiyorsa, veriler tutarlı olarak kabul edilebilir.

• Are they associated with a particular activity or time period? - Veriler belirli bir faaliyet veya dönem ile ilişkilendirilmişse, verilerde açıkça belirtilmelidir.

• Can they be replicated?- Normalde, anketler, vaka çalışmaları ve deneyler gibi araştırmalar farklı koşullar altında sıklıkla tekrarlanır. Bu nedenle, verilerin kolayca kopyalanması da mümkün olmalıdır.

Veriler Nasıl Tanımlanır?

Ölçüm amacıyla toplanan veriler iki türdendir -

• Raw data- Ham veriler, süreç, ürün veya kaynakların ilk ölçümlerinden elde edilir. Örneğin: Bir organizasyondaki çalışanların haftalık zaman çizelgesi.

• Refined data - İyileştirilmiş veriler, öznitelikler için değer türetmek için ham verilerden temel veri öğelerinin çıkarılmasıyla elde edilir.

Veriler aşağıdaki noktalara göre tanımlanabilir -

• Location
• Timing
• Symptoms
• Sonuç
• Mechanism
• Cause
• Severity
• Cost

Veriler Nasıl Toplanır?

Verilerin toplanması, insan gözlemi ve raporlamayı gerektirir. Yöneticiler, sistem analistleri, programcılar, testçiler ve kullanıcılar satır verilerini formlara kaydetmelidir. Doğru ve eksiksiz veri toplamak için aşağıdakiler önemlidir:

• Prosedürleri basit tutun

• Gereksiz kayıttan kaçının

• Çalışanları verileri kaydetme ihtiyacı ve kullanılacak prosedürler konusunda eğitin

• Veri yakalama ve analiz sonuçlarını orijinal sağlayıcılara derhal ve çalışmalarında yardımcı olacak faydalı bir biçimde sunun

• Merkezi bir toplama noktasında toplanan tüm verileri doğrulayın

Veri toplamanın planlanması birkaç adım içerir -

• GQM analizine göre hangi ürünlerin ölçüleceğine karar verin

• Ürünün konfigürasyon kontrolü altında olduğundan emin olun

• Tam olarak hangi özelliklerin ölçüleceğine ve dolaylı önlemlerin nasıl türetileceğine karar verin

• Ölçü seti netleştiğinde ve ölçülecek bileşen kümesi belirlendiğinde, ölçüm sürecine dahil olan her bir faaliyeti tanımlamak için bir şema oluşturun

• Formları işlemek, verileri analiz etmek ve sonuçları raporlamak için bir prosedür oluşturun

Veri toplama planlaması, proje planlaması başladığında başlamalıdır. Gerçek veri toplama, geliştirmenin birçok aşamasında gerçekleşir.

For example - Proje personeli ile ilgili bazı veriler projenin başlangıcında toplanabilirken, efor gibi diğer veri toplama, proje başlangıcında başlar ve işletme ve bakım ile devam eder.

Veriler Nasıl Saklanır ve Çıkarılır

Yazılım mühendisliğinde veriler bir veritabanında depolanmalı ve bir Veritabanı Yönetim Sistemi (DBMS) kullanılarak kurulmalıdır. Aşağıdaki şekilde bir veritabanı yapısı örneği gösterilmektedir. Bu veritabanı, bir organizasyonun farklı departmanlarında çalışan farklı çalışanların ayrıntılarını saklayacaktır.

Yukarıdaki diyagramda, her kutu veri tabanındaki bir tablodur ve ok, bir tablodan diğerine çoktan bire eşlemeyi gösterir. Eşlemeler, verilerin mantıksal tutarlılığını koruyan kısıtlamaları tanımlar.

Veritabanı tasarlandıktan ve verilerle doldurulduktan sonra, verileri analiz için çıkarmak için veri işleme dillerini kullanabiliriz.

İlgili verileri topladıktan sonra uygun bir şekilde analiz etmemiz gerekiyor. Analiz tekniğini seçerken dikkate alınması gereken üç ana öğe vardır.

• Verinin doğası
• Deneyin amacı
• Tasarım konuları

Verinin Doğası

Verileri analiz etmek için, verilerin temsil ettiği daha büyük nüfusa ve bu verilerin dağılımına da bakmalıyız.

Örnekleme, popülasyon ve veri dağıtımı

Örnekleme, büyük bir popülasyondan bir veri kümesi seçme işlemidir. Örnek istatistikler, bir grup deneysel denekten elde edilen ölçümleri açıklar ve özetler.

Popülasyon parametreleri, tüm olası özneler ölçülürse elde edilecek değerleri temsil eder.

Popülasyon veya örnek, ortalama, medyan ve mod gibi merkezi eğilim ölçüleri ve varyans ve standart sapma gibi dağılım ölçüleri ile tanımlanabilir. Aşağıdaki grafikte gösterildiği gibi birçok veri seti normal olarak dağıtılmıştır.

Yukarıda gösterildiği gibi, veriler ortalama hakkında eşit olarak dağıtılacaktır. bu normal bir dağılımın önemli özellikleridir.

Verilerin çarpık olduğu başka dağılımlar da mevcuttur, böylece ortalamanın bir tarafında diğerinden daha fazla veri noktası vardır. Örneğin: Verilerin çoğu ortalamanın sol tarafında mevcutsa, dağılımın sola doğru çarpık olduğunu söyleyebiliriz.

Deneyin Amacı

Normalde deneyler yapılır -

• Bir teoriyi doğrulamak için
• Bir ilişkiyi keşfetmek için

Bunların her birine ulaşmak için, hedef resmi olarak hipotez açısından ifade edilmeli ve analiz hipotezi doğrudan ele almalıdır.

Bir teoriyi doğrulamak için

Soruşturma, bir teorinin doğruluğunu keşfetmek için tasarlanmalıdır. Teori genellikle belirli bir yöntem, araç veya tekniğin kullanımının konular üzerinde belirli bir etkiye sahip olduğunu ve onu bir şekilde diğerinden daha iyi hale getirdiğini belirtir.

Dikkate alınması gereken iki veri durumu vardır: normal data ve non-normal data.

Veriler normal bir dağılımdan alınmışsa ve karşılaştırılacak iki grup varsa, öğrencinin t testi analiz için kullanılabilir. Karşılaştırılacak ikiden fazla grup varsa, F-istatistikleri adı verilen genel bir varyans testi analizi kullanılabilir.

Veriler normal değilse, veriler Kruskal-Wallis testi kullanılarak derecelendirilerek analiz edilebilir.

Bir ilişkiyi keşfetmek için

Araştırmalar, bir değişkeni veya birden çok değişkeni tanımlayan veri noktaları arasındaki ilişkiyi belirlemek için tasarlanmıştır.

Bir ilişki hakkındaki soruları yanıtlamak için üç teknik vardır: kutu grafikleri, dağılım grafikleri ve korelasyon analizi.

• Bir box plot bir dizi veri aralığının özetini temsil edebilir.

• Bir scatter plot iki değişken arasındaki ilişkiyi temsil eder.

• Correlation analysis iki öznitelik arasında gerçek bir ilişki olup olmadığını doğrulamak için istatistiksel yöntemler kullanır.

  • Normal dağıtılan değerler için kullanın Pearson Correlation Coefficient iki değişkenin yüksek oranda ilişkili olup olmadığını kontrol etmek için.

  • Normal olmayan veriler için verileri sıralayın ve Spearman Rank Correlation Coefficientbir ilişki ölçüsü olarak. Normal olmayan veriler için bir başka ölçü deKendall robust correlation coefficient, veri noktası çiftleri arasındaki ilişkiyi araştıran ve kısmi bir korelasyonu tanımlayabilen.

Sıralama çok sayıda bağlı değer içeriyorsa, chi-squared testbir olasılık tablosunda değişkenler arasındaki ilişkiyi test etmek için kullanılabilir. Benzer şekilde,linear regression değişkenler arasındaki ilişkiyi tanımlamak için bir denklem oluşturmak için kullanılabilir.

İkiden fazla değişken için, multivariate regression kullanılabilir.

Tasarım Hususları

Analiz teknikleri seçilirken araştırmanın tasarımı dikkate alınmalıdır. Aynı zamanda, analizin karmaşıklığı seçilen tasarımı etkileyebilir. Birden fazla grup, Öğrenci'nin iki gruplu T testi yerine F istatistiklerini kullanır.

İkiden fazla faktör içeren karmaşık faktöriyel tasarımlar için, daha karmaşık bir ilişki ve önem testi gereklidir.

İstatistiksel teknikler, bir değişken setinin diğerleri üzerindeki etkisini hesaba katmak veya zamanlama veya öğrenme etkilerini telafi etmek için kullanılabilir.

Dahili ürün öznitelikleri, yazılım ürünlerini yalnızca ürünün kendisine bağlı olacak şekilde tanımlar. Dahili ürün özelliklerini ölçmenin ana nedeni, geliştirme sırasında ürünlerin izlenmesine ve kontrol edilmesine yardımcı olmasıdır.

Dahili Ürün Özelliklerini Ölçme

Ana dahili ürün özellikleri şunları içerir: size ve structure. Boyut, bunları yürütmek zorunda kalmadan statik olarak ölçülebilir. Ürünün boyutu, onu yaratmak için gereken çabayı bize anlatır. Benzer şekilde ürünün yapısı da ürünün bakımının tasarlanmasında önemli bir rol oynar.

Boyutu Ölçmek

Yazılım boyutu üç özellik ile tanımlanabilir -

• Length - Ürünün fiziksel ölçüsüdür.

• Functionality - Ürünün kullanıcıya sağladığı fonksiyonları anlatır.

• Complexity - Karmaşıklık gibi farklı türlerdendir.

  • Problem complexity - Altta yatan sorunun karmaşıklığını ölçer.

  • Algorithmic complexity - Sorunu çözmek için uygulanan algoritmanın karmaşıklığını ölçer

  • Structural complexity - Algoritmayı uygulamak için kullanılan yazılımın yapısını ölçer.

  • Cognitive complexity - Yazılımı anlamak için gereken çabayı ölçer.

Bu üç özelliğin ölçümü şu şekilde açıklanabilir:

Uzunluk

Tahmin için gereken eforu tahmin etmek için boyut ölçümü yararlı olan üç geliştirme ürünü vardır. Özellikler, tasarım ve kodlardır.

Özellikler ve tasarım

Bu belgeler genellikle metin, grafik ve özel matematiksel diyagram ve sembolleri birleştirir. Tasarımın uzunluğunu tahmin etmek için spesifikasyon ölçümü kullanılabilir ve bu da kod uzunluğunun bir öngörücüsüdür.

Belgelerdeki diyagramlar, etiketli digraflar, veri akış diyagramları veya Z şemaları gibi tek tip sözdizimine sahiptir. Şartname ve tasarım belgeleri metinlerden ve diyagramlardan oluştuğundan, uzunluğu, metin uzunluğunu ve diyagram uzunluğunu temsil eden bir çift sayı ile ölçülebilir.

Bu ölçümler için, atomik nesneler farklı diyagram ve sembol türleri için tanımlanmalıdır.

Veri akış diyagramları için atomik nesneler süreçler, harici varlıklar, veri depoları ve veri akışlarıdır. Cebirsel belirtimler için atomik varlıklar türler, fonksiyonlar, işlemler ve aksiyomlardır. Z şemaları için atomik varlıklar, spesifikasyonda görünen çeşitli çizgilerdir.

Kod

Kod, prosedürel dil, nesne yönelimi ve görsel programlama gibi farklı şekillerde üretilebilir. Kaynak kod program uzunluğunun en yaygın olarak kullanılan geleneksel ölçüsü, Kod Satırlarıdır (LOC).

Toplam uzunluk,

LOC = NCLOC + CLOC

yani

LOC = Non-commented LOC + Commented LOC

Kod satırının yanı sıra, Maurice Halsted tarafından önerilen boyut ve karmaşıklık gibi diğer alternatifler de uzunluğu ölçmek için kullanılabilir.

Halstead'in yazılım bilimi, bir programın farklı özelliklerini yakalamaya çalıştı. Uzunluk, kelime haznesi ve hacim gibi farklı boyut görüşlerini yansıtan üç dahili program özelliği önerdi.

Bir program tanımlayarak başladı Poperatörler veya işlenenler tarafından sınıflandırılan bir simge koleksiyonu olarak. Bu belirteçler için temel metrikler şunlardı:

• μ₁ = Benzersiz operatör sayısı

• μ₂ = Benzersiz işlenenlerin sayısı

• N₁ = Operatörlerin Toplam Oluşumu

• N₂ = Benzersiz operatör sayısı

Uzunluk P olarak tanımlanabilir

$$N = N_{1}+ N_{2}$$

Kelime dağarcığı P dır-dir

$$\mu =\mu _{1}+\mu _{2}$$

Programın hacmi = uzunlukta bir program yazmak için gereken zihinsel karşılaştırma sayısı N, dır-dir

$$V = N\times {log_{2}} \mu$$

Bir programın program seviyesi P hacim V dır-dir,

$$L = \frac{V^\ast}{V}$$

Nerede, $V^\ast$ potansiyel hacim, yani minimum boyut uygulamasının hacmidir. P

Seviyenin tersi zorluktur -

$$D = 1\diagup L$$

Halstead teorisine göre bir tahmin hesaplayabiliriz L gibi

$${L}' = 1\diagup D = \frac{2}{\mu_{1}} \times \frac{\mu_{2}}{N_{2}}$$

Benzer şekilde, tahmini program uzunluğu, $\mu_{1}\times log_{2}\mu_{1}+\mu_{2}\times log_{2}\mu_{2}$

P'yi oluşturmak için gereken çaba,

$$E = V\diagup L = \frac{\mu_{1}N_{2}Nlog_{2}\mu}{2\mu_{2}}$$

Ölçü birimi nerede E anlamak için gerekli olan temel zihinsel ayrımlardır P

Uzunluğu ölçmek için diğer alternatifler şunlardır:

• Program metni için gereken bilgisayar deposu bayt sayısı açısından

• Program metnindeki karakter sayısı açısından

Nesneye yönelik geliştirme, uzunluğu ölçmenin yeni yollarını önerir. Pfleeger vd. bir dizi nesnenin ve yöntemin, kod satırlarını kullananlara göre daha doğru verimlilik tahminlerine yol açtığını buldu.

İşlevsellik

Bir ürünün doğasında bulunan işlevsellik miktarı, ürün boyutunun ölçüsünü verir. Yazılım ürünlerinin işlevselliğini ölçmek için pek çok farklı yöntem vardır. Bir sonraki bölümde böyle bir yöntemi ─ Albrecht'in Fonksiyon Noktası yöntemini ─ tartışacağız.

İşlev noktası ölçümleri, bir yazılım uygulamasının çeşitli işlevlerini ölçmek için standartlaştırılmış bir yöntem sağlar. İşlevselliği kullanıcının bakış açısından, yani kullanıcının karşılığında ne istediği ve ne aldığı temelinde ölçer. Fonksiyon noktası analizi, kullanıcının bakış açısından yazılım geliştirmeyi ölçmek için standart bir yöntemdir.

İlk olarak Albrecht tarafından tasarlanan İşlev Noktası ölçüsü, 1986'da Uluslararası İşlev Noktası Kullanıcıları Grubu'nun (IFPUG) başlamasıyla artan popülerlik kazandı. 2002'de IFPUG İşlev Noktaları uluslararası bir ISO standardı oldu - ISO / IEC 20926.

Fonksiyon Noktası nedir?

FP (Function Point)bir yazılım uygulamasını ölçmek için en yaygın işlevsel tip ölçüsüdür. İki veri işlevi türüne ve üç işlem işlev türüne bölünmüş beş kullanıcı tarafından tanımlanabilen mantıksal "işlev" e dayanmaktadır. Belirli bir yazılım uygulaması için, bu öğelerin her biri, dosya referansları veya mantıksal alanlar gibi karakteristik öğeleri sayılarak ölçülür ve ağırlıklandırılır.

Ortaya çıkan sayılar (Ayarlanmamış FP) Eklenen, Değiştirilen veya Silinen işlev kümeleri halinde gruplandırılır ve nihai FP sayısını elde etmek için Değer Ayarlama Faktörü (VAF) ile birleştirilir. Her sayım türü için ayrı bir son formül kullanılır: Uygulama, Geliştirme Projesi veya Geliştirme Projesi.

Albrecht'in Fonksiyon Noktası Yönteminin Uygulanması

Şimdi Albrecht'in Function Point yönteminin nasıl uygulanacağını anlayalım. Prosedürü aşağıdaki gibidir -

Bileşenlerin sayısını belirleyin (EI, EO, EQ, ILF ve ELF)

• EI- Harici girişlerin sayısı. Bunlar, türetilen verilerin sınırdan dışarıdan içeriye geçtiği temel süreçlerdir. Örnek bir kütüphane veritabanı sisteminde, mevcut bir kullanıcının kütüphane kartı numarasını girin.

• EO- Harici çıkış sayısı. Bunlar, türetilen verilerin sınırın içinden içeriden dışarıya geçtiği temel süreçlerdir. Örnek bir kütüphane veritabanı sisteminde, bir kullanıcıya ödünç verilen kitapların bir listesini görüntüleyin.

• EQ- Dış sorguların sayısı. Bunlar, bir veya daha fazla dahili mantıksal dosyadan ve harici arayüz dosyalarından veri alınmasına neden olan hem giriş hem de çıkış bileşenlerine sahip temel süreçlerdir. Örnek bir kütüphane veritabanı sisteminde, şu anda hangi kitapların bir kullanıcıya ödünç verildiğini belirleyin.

• ILF- Dahili günlük dosyalarının sayısı. Bunlar, tamamen harici girdilerle korunan uygulama sınırları içinde yer alan, mantıksal olarak ilişkili verilerin kullanıcı tarafından tanımlanabilen gruplarıdır. Örnek bir kütüphane veritabanı sisteminde, kütüphanedeki kitapların dosyası.

• ELF- Harici günlük dosyalarının sayısı. Bunlar, yalnızca referans amacıyla kullanılan ve tamamen sistemin dışında bulunan, mantıksal olarak ilişkili verilerin kullanıcı tarafından tanımlanabilen gruplarıdır. Örnek bir kütüphane veritabanı sisteminde, kütüphanenin faturalama sistemindeki işlemleri içeren dosya.

Ayarlanmamış Fonksiyon Noktası Sayısını (UFC) hesaplayın

• Her bileşeni şu şekilde değerlendirin: low, average, veya high.

• İşlemler için (EI, EO, and EQ), derecelendirmeye göre FTR ve DET.

  • FTR - Güncellenen veya başvurulan dosyaların sayısı.

  • DET - Kullanıcı tarafından tanınan alanların sayısı.

  • Aşağıdaki tabloya göre bir EI 2 dosya ve 10 veri öğesi referans olarak average.

FTR'ler	DET'ler
	1-5	6-15	>15
0-1	Düşük	Düşük	Ortalama
2-3	Düşük	Ortalama	Yüksek
>3	Ortalama	Yüksek	Yüksek

• Dosyalar için (ILF and ELF), derecelendirmeye göre RET ve DET.

  • RET - Bir dosyadaki kullanıcı tarafından tanınabilen veri öğelerinin sayısı ILF veya ELF.

  • DET - Kullanıcı tarafından tanınan alanların sayısı.

  • Aşağıdaki tabloya göre bir ILF 10 veri öğesi içeren ve 5 alan şu şekilde sıralanır: high.

RET'ler	DET'ler
	1-5	6-15	>15
1	Düşük	Düşük	Ortalama
2-5	Düşük	Ortalama	Yüksek
>5	Ortalama	Yüksek	Yüksek

• Derecelendirmeleri şuna dönüştür: UFCs.

Değerlendirme	Değerler
	EO	EQ	EI	ILF	ELF
Low	4	3	3	7	5
Average	5	4	4	10	7
High	6	5	6	15	10

Son Fonksiyon Nokta Sayısını (FPC) hesaplayın

• Hesaplama değeri ayarlama faktörü (VAF) 14 genel sistem özelliğine göre (GSC).

Genel Sistem Karakteristiği		Kısa açıklama
GSC 1	Veri iletişimleri	Uygulama veya sistem ile bilgi aktarımı veya değişimine yardımcı olacak kaç iletişim tesisi var?
GSC 2	Dağıtılmış veri işleme	Dağıtılmış veriler ve işleme fonksiyonları nasıl ele alınır?
GSC 3	Verim	Yanıt süresi veya işlem hacmi kullanıcı için gerekli miydi?
GSC 4	Yoğun olarak kullanılan yapılandırma	Uygulamanın yürütüleceği mevcut donanım platformu ne kadar yoğun bir şekilde kullanılıyor?
GSC 5	İşlem oranı	İşlemler günlük, haftalık, aylık vb. Ne sıklıkla yapılır?
GSC 6	Çevrimiçi veri girişi	Bilgilerin yüzde kaçı çevrimiçi olarak giriliyor?
GSC 7	Son kullanıcı verimliliği	Uygulama, son kullanıcı verimliliği için mi tasarlanmış?
GSC 8	Çevrimiçi güncelleme	Çevrimiçi işlemle kaç ILF güncellenir?
GSC 9	Karmaşık işlem	Uygulama, kapsamlı mantıksal veya matematiksel işleme sahip mi?
GSC 10	Tekrar Kullanılabilirlik	Uygulama bir veya daha fazla kullanıcının ihtiyacını karşılayacak şekilde mi geliştirildi?
GSC 11	Kurulum kolaylığı	Dönüştürme ve kurulum ne kadar zor?
GSC 12	Operasyonel kolaylık	Başlatma, yedekleme ve kurtarma prosedürleri ne kadar etkili ve / veya otomatiktir?
GSC 13	Birden çok site	Uygulama, birden çok kuruluş için birden çok siteye kurulmak üzere özel olarak tasarlanmış, geliştirilmiş ve desteklenmiş miydi?
GSC 14	Değişimi kolaylaştırın	Uygulama, değişimi kolaylaştırmak için özel olarak tasarlanmış, geliştirilmiş ve desteklenmiş midir?

• Her birini tartın GSC güçlü etkiye etkisi olup olmadığına göre 0 ile 5 arasında bir ölçekte.

• Hesaplayın FPC aşağıdaki gibi -

  FPC = UFC * (0.65+ (toplam (GSC) * .01))

Karmaşıklık

Karmaşıklık, boyutun ayrı bir bileşenidir. İki çeşittir -

• Complexity of a problem - Soruna en uygun çözüm için gereken kaynak miktarıdır.

• Complexity of a solution- Belirli bir çözümü uygulamak için ihtiyaç duyulan kaynaklardır. İki yönü vardır. Bunlar aşağıdaki gibidir -

  • Time complexity - Kaynak bilgisayar saatidir.

  • Space complexity - Kaynak bilgisayar belleğidir.

Karmaşıklığı Ölçme

Karmaşıklığın bir yönü verimliliktir. Algoritma olarak modellenebilen herhangi bir yazılım ürününü ölçer.

Örneğin: Belirli bir problemin tüm örneklerini çözmek için bir algoritma, f(n) hesaplamalar, o zaman f(n) Karmaşıklığa sahip diğer her algoritma için problemi çözüyorsa, asimptotik olarak optimaldir f dır-dir O(g). O halde, verilen sorunun karmaşıklığı büyüktür -O problemin çözümü için asimptotik olarak optimal algoritmanın.

Bir yazılımın yapısal özelliklerinin ölçülmesi, geliştirme çabasının tahmin edilmesi ve ürünün bakımı için önemlidir. Gereksinimlerin, tasarımın ve kodun yapısı, bir ürünü diğerine dönüştürürken, bir ürünü test ederken veya erken dahili ürün ölçümlerinden harici yazılım özelliklerini tahmin ederken ortaya çıkan zorluğu anlamaya yardımcı olur.

Yapısal Önlem Türleri

Yazılımın yapısı üç bölümden oluşmaktadır. Onlar -

• Control-flow structure - Bir programda komutların yürütüldüğü sıradır.

• Data-flow structure - Programla etkileşim halindeki verinin davranışıdır.

• Data structure - Oluşturma, değiştirme veya silme algoritması ile birlikte listeler, kuyruk, yığınlar veya diğer iyi tanımlanmış yapılar şeklindeki veri öğelerinin organizasyonudur.

Kontrol-Akış Yapısının Ölçülmesi

Kontrol akışı ölçüleri genellikle yönlendirilmiş grafikle modellenir, burada her düğüm veya nokta program ifadelerine karşılık gelir ve her yay veya yönlendirilmiş kenar, bir ifadeden diğerine kontrol akışını gösterir. Bu grafiklere kontrol akış grafiği veya yönlendirilmiş grafik denir.

Eğer ‘m’ akış grafiği modeli açısından tanımlanan yapısal bir ölçüdür ve eğer program A yapısal olarak programdan daha karmaşıktır B, sonra ölçü m(A) daha büyük olmalı m(B).

Veri Akışı Yapısını Ölçme

Veri akışı veya bilgi akışı, modüler (modüller içindeki bilgi akışı) veya modüler (tek tek modüller ve sistemin geri kalanı arasındaki bilgi akışı) olabilir.

Verilerin sistemde hareket etme şekline göre aşağıdaki şekilde sınıflandırılabilir:

• Local direct flow - Bir modül ikinci bir modülü çağırırsa ve ona bilgi aktarırsa veya çağrılan modül, arayana bir sonuç verirse.

• Local indirect flow - Çağrılan modül, daha sonra ikinci çağrılan modüle iletilen bilgileri döndürürse.

• Global flow - Bilgi bir modülden diğerine küresel bir veri yapısı aracılığıyla akıyorsa.

Bilgi akışı karmaşıklığı Henry ve Kafura'ya göre şu şekilde ifade edilebilir:

Information flow complexity (M) = length (M) × fan-in (M) × (fan-out (M))²

Nerede,

• Fan-in (M) - Bilginin M tarafından alındığı veri yapılarının sayısı M + 'da sonlanan yerel akışların sayısı.

• Fan–out (M) - M + 'dan kaynaklanan yerel akışların sayısı, M tarafından güncellenen veri yapılarının sayısı.

Veri Yapısını Ölçme

Veri yapısı hem local ve global.

Locally, her veri öğesindeki yapı miktarı ölçülecektir. Tek tek veri yapılarının özelliklerini analiz etmek ve ölçmek için grafik teorik bir yaklaşım kullanılabilir. Tamsayılar, karakterler ve Boole'lar gibi basit veri türleri asal sayılar olarak görülüyor ve daha karmaşık veri yapıları oluşturmamızı sağlayan çeşitli işlemler göz önünde bulunduruluyor. Veri yapısı ölçüleri daha sonra, çeşitli işlemlerle ilişkili asal sayılar ve değerler açısından hiyerarşik olarak tanımlanabilir.

Globally, kullanıcı tanımlı değişkenlerin toplam sayısı ölçülecektir.

SQA standartlarının geliştirilmesinde birkaç ulusal ve uluslararası standart enstitüsü, profesyonel ve endüstri odaklı kuruluşlar yer almıştır.

Aşağıdaki enstitüler ve kuruluşlar, SQA ve yazılım mühendisliği standartlarının ana geliştiricileridir -

• IEEE (Elektrik ve Elektronik Mühendisleri Enstitüsü) Bilgisayar Topluluğu
• ISO (Uluslararası Standardizasyon Örgütü)
• DOD (ABD Savunma Bakanlığı)
• ANSI (Amerikan Ulusal Standartlar Enstitüsü)
• IEC (Uluslararası Elektro Teknik Komisyonu)
• ÇED (Elektronik Endüstrileri Derneği)

Bu kuruluşlar, yazılım geliştirme ve bakım kuruluşlarında gerçekleştirilen profesyonel ve yönetsel faaliyetlerin kalitesine güncel uluslararası standartlar sağlar.

Ayrıca bağımsız profesyonel kalite denetimleri aracılığıyla SQA sertifikası sağlarlar. Bu dış denetimler, SQA sistemlerinin geliştirilmesinde ve bunların uygulanmasındaki başarıları değerlendirir. Periyodik denetimlerden sonra verilen sertifika ancak bir sonraki denetime kadar geçerli olacaktır ve bu nedenle yenilenmesi gerekmektedir. Şu anda, ISO 9000 Sertifikasyon Hizmeti, Avrupa ve diğer ülkelerde SQA sertifikasyonunun en önde gelen sağlayıcısıdır.

Ayrıca bir kuruluşun SQA sistemi ve işleyişinin öz değerlendirmesi için araçlar sağlarlar. Yazılım Mühendisliği Enstitüsü (SEI), Carnegie Mellon Üniversitesi ve ISO / IEC Std 15504 tarafından geliştirilen Kapasite Olgunluk Modeli (CMM) bu yaklaşımın örnekleridir.

SQA Standartları

Yazılım kalite güvence standartları iki ana sınıfa ayrılabilir -

• Sertifikasyon ve değerlendirme metodolojileri (kalite yönetim standartları) dahil olmak üzere yazılım kalite güvence yönetim standartları

• Yazılım proje geliştirme süreci standartları (proje süreç standartları)

Kalite Yönetim Standartları

Bunlar, kuruluşun SQA sistemine, altyapısına ve gereksinimlerine odaklanırken, yöntem ve araç seçimini kuruluşa bırakır. Kalite yönetimi standartları ile kuruluşlar, yazılım ürünlerinin kabul edilebilir bir kalite düzeyine ulaşmasını sürekli olarak temin edebilir.

Example - ISO 9000-3 ve Yetenek Olgunluk Modeli (CMM)

Proje Süreç Standartları

Bunlar, yazılım geliştirme ve bakım projelerinin uygulanmasına yönelik metodolojilere odaklanır. Bu standartlar aşağıdakileri içerir -

• Atılacak adımlar
• Tasarım dokümantasyonu gereksinimleri
• Tasarım belgelerinin içeriği
• Tasarım incelemeleri ve inceleme sorunları
• Yazılım testi yapılacak
• Test konuları

Doğal olarak, özellikleri nedeniyle, bu sınıftaki birçok SQA standardı, yazılım mühendisliği standartları olarak hizmet edebilir ve bunun tersi de geçerlidir.

Bu iki standart sınıfının özellikleri aşağıdaki tabloda özetlenmiştir.

Özellikler	Kalite Yönetim Standartları	Proje Süreç Standartları
Hedef birim	Yazılım geliştirme, bakım ve belirli SQA birimlerinin yönetimi	Yazılım geliştirme ve bakım proje ekibi
Esas odak	SQA sistemlerinin organizasyonu, altyapısı ve gereksinimleri	Yazılım geliştirme ve bakım projelerini yürütmek için metodolojiler
Standardın amacı	"Ne" başarılacak	"Nasıl performans
Standardın hedefi	Tedarikçinin yazılım kalitesini sağlamak ve yazılım süreci yeteneğini değerlendirmek	Tedarikçinin yazılım kalitesini güvence altına almak ve yazılım süreci kapasitesini değerlendirmek Belirli bir yazılım projesinin kalitesini sağlamak.
Örnekler	ISO 9000-3 SEI'nin CMM'si	ISO / IEC 12207 IEEEStd 1012-1998

ISO 9001 Sertifikası

ISO (Uluslararası Standardizasyon Örgütü), ulusal standartlar kuruluşlarının dünya çapında bir federasyonudur. ISO teknik komiteleri Uluslararası Standartları hazırlar. ISO, elektroteknik standardizasyonla ilgili tüm konularda Uluslararası Elektroteknik Komisyon (IEC) ile yakın işbirliği içindedir.

Uluslararası Standartlar, ISO / IEC Direktifleri, Bölüm 2'de verilen kurallara göre hazırlanır. Teknik komiteler tarafından benimsenen Uluslararası Standartların Taslağı, oylama için üye kuruluşlara gönderilir. ISO 9001, Teknik Komite ISO / TC 176, Kalite yönetimi ve kalite güvencesi, Alt Komite SC 2, Kalite sistemleri tarafından hazırlanmıştır.

Süreç Yaklaşımı

Bu Uluslararası Standart, müşteri gereksinimlerini karşılayarak müşteri memnuniyetini artırmak için bir kalite yönetim sistemini geliştirirken, uygularken ve iyileştirirken bir süreç yaklaşımının benimsenmesini teşvik eder. Bir kuruluşun etkili bir şekilde çalışması için, birbiriyle bağlantılı çok sayıda faaliyeti belirlemesi ve yönetmesi gerekir. Kaynakları kullanan ve girdilerin çıktılara dönüştürülmesini sağlamak için yönetilen bir faaliyet veya faaliyetler dizisi bir süreç olarak kabul edilebilir.

Çoğunlukla bir işlemin çıktısı doğrudan bir sonrakinin girdisini oluşturur. Bir organizasyon içinde bir süreçler sisteminin uygulanması, bu süreçlerin tanımlanması ve etkileşimleri ile birlikte ve bunların istenen sonucu üretmek için yönetimi olarak adlandırılabilir.“process approach”.

Süreç yaklaşımının bir avantajı, süreçler sistemi içindeki münferit süreçler arasındaki bağlantı üzerinde ve bunların kombinasyonu ve etkileşimi üzerinde sağladığı sürekli kontroldür. Bir kalite yönetim sistemi içinde kullanıldığında, böyle bir yaklaşım aşağıdakilerin önemini vurgular:

• Gereksinimleri anlamak ve karşılamak
• Süreçleri katma değer açısından düşünmek gerekiyor
• Süreç performansı ve etkinliğinin sonuçlarını elde edin
• Nesnel ölçüme dayalı süreçlerin sürekli iyileştirilmesi

ISO 9001 - Yazılım Uygulaması: TickIT Girişimi

TickIT, ISO 9001'i TickIT girişimi olarak bilinen yazılım endüstrisinin özelliklerine uyarlamak için bir metodolojinin geliştirilmesini teşvik etmek için İngiltere Ticaret ve Sanayi Bakanlığı ile işbirliği içinde İngiltere yazılım endüstrisi tarafından 1980'lerin sonunda başlatıldı.

TickIT ayrıca bilgi teknolojisi (BT) konusunda uzmanlaşmıştır. Ticari yazılım geliştirme ve bakım hizmetlerinin tamamını kapsar. Şu anda BSI DISC Departmanı (İngiliz Standartları Enstitüsü) tarafından yönetilen ve bakımı yapılan TickIT, İngiltere ve İsveç'teki BT kuruluşlarının sertifikasyonu için akredite edilmiştir.

Faaliyetleri şunları içerir:

• Yazılım endüstrisinin ISO 9001 sertifikasını yayma çabalarını destekleyen TickIT Kılavuzunun yayınlanması. ISO / IEC 12207 ve ISO / IEC 15504 referanslarını içeren mevcut kılavuz (5.0 sürümü, TickIT, 2001) tüm TickIT müşterilerine dağıtılmaktadır.

• Yazılım kalite sistemlerinin denetime dayalı değerlendirmelerinin gerçekleştirilmesi ve kuruluşlara yönetimlerinin yanı sıra yazılım geliştirme ve bakım süreçlerinin iyileştirilmesi konusunda danışmanlık.

• ISO 9000 sertifika denetimlerini gerçekleştirin.

Denetime dayalı değerlendirmeler ve sertifika denetimleri gerçekleştiren TickIT denetçileri, Uluslararası Sertifikalı Denetçiler Sicili (IRCA) tarafından kaydedilir. Kayıtlı IRCA denetçilerinin, diğer şeylerin yanı sıra, yönetim ve yazılım geliştirmede deneyime sahip olması gerekir; ayrıca bir denetçinin kursunu başarıyla tamamlamaları gerekir.

Kayıtlı baş denetçilerin, TickIT denetimlerini yürütme ve yönetme konusunda kanıtlanmış bir deneyime sahip olması gerekir.

Bir yazılım süreci değerlendirmesi, bir organizasyon tarafından kullanılan yazılım süreçlerinin bir süreç modeline dayalı olarak disiplinli bir incelemesidir. Değerlendirme, mevcut uygulamaların tanımlanmasını ve nitelendirilmesini, güçlü ve zayıf yönlerin tanımlanmasını ve mevcut uygulamaların, kötü (yazılım) kalite, maliyet ve programın önemli nedenlerini kontrol etme veya bunlardan kaçınma becerisini içerir.

Bir yazılım değerlendirmesi (veya denetimi) üç tipte olabilir.

• Bir self-assessment (first-party assessment) bir kuruluşun kendi personeli tarafından dahili olarak gerçekleştirilir.

• Bir second-party assessment harici bir değerlendirme ekibi tarafından gerçekleştirilir veya organizasyon bir müşteri tarafından değerlendirilir.

• Bir third-party assessment harici bir tarafça veya (örneğin, bir tedarikçinin bir müşteriyle sözleşmelere girme kabiliyetini doğrulamak için üçüncü bir tarafça değerlendirilen bir tedarikçi) tarafından gerçekleştirilir.

Yazılım süreç değerlendirmeleri, açık ve işbirliğine dayalı bir ortamda gerçekleştirilir. Kuruluşun yazılım süreçlerini iyileştirmek için kullanması içindir ve sonuçlar kuruluş için gizlidir. Değerlendirilen kuruluşun değerlendirme ekibinde üyeleri olmalıdır.

Yazılım Süreci Olgunluk Değerlendirmesi

Bir yazılım süreci değerlendirmesinin kapsamı, organizasyondaki tüm süreçleri, yazılım süreçlerinin seçilen bir alt kümesini veya belirli bir projeyi kapsayabilir. Standart tabanlı süreç değerlendirme yaklaşımlarının çoğu, her zaman süreç olgunluğu kavramına dayanmaktadır.

Değerlendirme hedefi kuruluş olduğunda, bir süreç değerlendirmesinin sonuçları, aynı yöntemin birbirini izleyen uygulamalarında bile farklılık gösterebilir. Farklı sonuçların iki nedeni vardır. Onlar,

• Araştırılan organizasyon belirlenmelidir. Büyük bir şirket için, çeşitli organizasyon tanımları mümkündür ve bu nedenle, gerçek değerlendirme kapsamı, birbirini izleyen değerlendirmelerde farklılık gösterebilir.

• Aynı organizasyon gibi görünen şeylerde bile, organizasyonu temsil etmek için seçilen proje örnekleri kapsam ve sonucu etkileyebilir.

Hedef değerlendirme birimi proje düzeyinde olduğunda, değerlendirme projenin başarısına veya başarısızlığına katkıda bulunan tüm anlamlı faktörleri içermelidir. Belirli bir süreç olgunluk modelinin yerleşik boyutları ile sınırlı olmamalıdır. Burada, proje verileriyle doğrulanan uygulama derecesi ve etkinliği değerlendirilir.

Bir kuruluş genel bir uzun vadeli iyileştirme stratejisine girişmek istediğinde süreç olgunluğu alakalı hale gelir. Yazılım proje değerlendirmeleri objektif olması için bağımsız değerlendirmeler olmalıdır.

Yazılım Süreç Değerlendirme Döngüsü

Paulk ve meslektaşlarına (1995) göre, CMM tabanlı değerlendirme yaklaşımı altı adımlı bir döngü kullanır. Onlar -

• Bir ekip seçin - Ekibin üyeleri, yazılım mühendisliği ve yönetimi konusunda bilgili profesyoneller olmalıdır.

• Değerlendirilecek saha temsilcileri, standart süreç olgunluk anketini doldururlar.

• Değerlendirme ekibi, anket yanıtlarının bir analizini gerçekleştirir ve CMM kilit süreç alanlarına göre daha fazla araştırmayı gerektiren alanları belirler.

• Değerlendirme ekibi, sitenin izlediği yazılım sürecini anlamak için bir saha ziyareti gerçekleştirir.

• Değerlendirme ekibi, kuruluşun yazılım sürecinin güçlü ve zayıf yönlerini tanımlayan bir bulgu listesi oluşturur.

• Değerlendirme ekibi bir Anahtar Süreç Alanı (KPA) profil analizi hazırlar ve sonuçları uygun hedef kitleye sunar.

Örneğin, değerlendirme ekibi yetkili bir SEI Baş Değerlendiricisi tarafından yönetilmelidir. Ekip, dört ila on ekip üyesinden oluşmalıdır. En az bir ekip üyesi değerlendirilen organizasyondan olmalıdır ve tüm ekip üyeleri SEI'nin CMM'ye Giriş kursunu (veya eşdeğeri) ve SEI'nin CBA IPI ekip eğitim kursunu tamamlamalıdır. Ekip üyeleri de bazı seçim kurallarına uymalıdır.

Veri toplamayla ilgili olarak, CBA IPI dört yönteme dayanır -

• Standart olgunluk anketi
• Bireysel ve grup görüşmeleri
• Belge incelemeleri
• Taslak bulguların değerlendirmeye katılanlarla birlikte incelenmesinden geri bildirim

İRİ KARİDES

Süreç İyileştirme için Standart CMMI Değerlendirme Yöntemi (SCAMPI), CMMI model gereksinimlerini karşılamak için geliştirilmiştir (Yazılım Mühendisliği Enstitüsü, 2000). Ayrıca CBA IPI'ye dayanmaktadır. Hem CBA IPI hem de SCAMPI üç aşamadan oluşur -

• Plan ve hazırlık
• Değerlendirmeyi yerinde gerçekleştirin
• Sonuçları bildir

Plan ve hazırlık aşamasındaki faaliyetler şunları içerir:

• Değerlendirme kapsamını belirleyin
• Değerlendirme planını geliştirin
• Değerlendirme ekibini hazırlayın ve eğitin
• Katılımcıların kısa bir değerlendirmesini yapın
• CMMI Değerleme Anketini yönetin
• Anket yanıtlarını inceleyin
• İlk belge incelemesini gerçekleştirin

Yerinde değerlendirme aşamasına yönelik faaliyetler şunları içerir:

• Açılış toplantısı düzenleyin
• Röportajlar yapın
• Bilgileri birleştirin
• Taslak bulguların sunumunu hazırlayın
• Taslak bulguları sunun
• Nihai bulguları birleştirin, derecelendirin ve hazırlayın

Raporlama sonuçları aşamasının faaliyetleri şunları içerir:

• Nihai bulguları sunun
• Bir yönetici oturumu düzenleyin
• Değerlendirmeyi tamamlayın

Yazılım kalite güvencesi için IEEE tanımı aşağıdaki gibidir -

"Bir öğe veya ürünün yerleşik teknik gereksinimlere uyduğuna dair yeterli güven sağlamak için gerekli tüm eylemlerin planlı ve sistematik bir modeli. Ürünlerin geliştirildiği veya üretildiği süreci değerlendirmek için tasarlanmış bir dizi faaliyet."

SQA Faaliyetlerinin Amaçları

SQA faaliyetlerinin hedefleri aşağıdaki gibidir -

Yazılım geliştirmede (süreç odaklı)

• Yazılımın işlevsel teknik gereksinimlere uyacağına dair kabul edilebilir bir güven düzeyinin sağlanması.

• Yazılımın yönetimsel planlamaya ve bütçe gereksinimlerine uyacağına dair kabul edilebilir bir güven düzeyinin sağlanması.

• Yazılım geliştirme ve SQA faaliyetlerinin iyileştirilmesi ve daha verimli hale getirilmesi için faaliyetlerin başlatılması ve yönetilmesi.

Yazılım bakımında (ürün odaklı)

• Yazılım bakım faaliyetlerinin işlevsel teknik gereksinimlere uygun olacağına dair kabul edilebilir bir güven düzeyi ile garanti etmek.

• Yazılım bakım faaliyetlerinin yönetimsel planlamaya ve bütçe gereksinimlerine uygun olacağına dair kabul edilebilir bir güven seviyesi ile garanti etmek.

• Yazılım bakımı ve SQA faaliyetlerinin verimliliğini iyileştirmek ve artırmak için faaliyetler başlatmak ve yönetmek. Bu, maliyetleri düşürürken işlevsel ve yönetsel gereksinimlere ulaşma olasılığını geliştirmeyi içerir.

Kalite Güvencesi için Organizasyon

Organizasyon yapısı içinde faaliyet gösteren kalite güvence organizasyonel çerçevesi aşağıdaki katılımcıları içerir -

Yöneticiler

• Üst düzey yönetim yöneticileri, özellikle yazılım kalite güvencesinden doğrudan sorumlu yönetici

• Yazılım geliştirme ve bakım departmanı yöneticileri

• Yazılım test departmanı yöneticileri

• Geliştirme ve bakım projelerinin proje yöneticileri ve ekip liderleri

• Yazılım test ekiplerinin liderleri

Testçiler

• Yazılım test ekiplerinin üyeleri

SQA uzmanları ve ilgili uygulayıcılar -

• SQA mütevellileri
• SQA komite üyeleri
• SQA forum üyeleri
• SQA birimi ekip üyeleri

Sadece yazılım test departmanının yöneticileri ve çalışanları, SQA görevlerinin yerine getirilmesinde tam zamanlı olarak görevlendirilir. Diğerleri, zamanlarının bir kısmını, yönetim işlevlerinin veya profesyonel görevlerinin yerine getirilmesi sırasında ya da başkalarında gönüllü olarak, çoğunlukla bir SQA komitesi, bir SQA forumu veya SQA mütevellileri olarak kalite sorunlarına ayırırlar.

Temel olarak, yazılım geliştirme organizasyonlarında üç seviyeli bir yönetim yapısı mevcuttur -

• Üst yönetim
• Departman yönetimi
• Proje Yönetimi

Yazılım Kalitesinde Üst Yönetim Sorumlulukları

Yazılım Kalitesinin sağlanmasında üst yönetimin sorumlulukları şunlardır:

• Şirketin yazılım ürünlerinin ve yazılım bakım hizmetlerinin kalitesini sağlamak

• Müşteri memnuniyetinin yanı sıra ürün ve hizmet kalitesinin önemini her kademedeki çalışanlara iletmek

• Tatmin edici işleyişi ve müşteri gereksinimlerine tam uyumu sağlayın

• Kuruluşun SQA sistemi için kalite hedeflerinin oluşturulduğundan ve hedeflerine ulaşıldığından emin olun

• SQA sistemini organizasyonun müşterileri, rekabeti ve teknolojisi ile ilgili büyük iç ve dış değişikliklere uyarlamak için gerekli değişikliklerin planlanmasını başlatmak ve uygulanmasını denetlemek

• Kriz durumlarının çözümünü desteklemek ve zararları en aza indirmek için doğrudan müdahale edin

• SQA sistemlerinin gerektirdiği kaynakların kullanılabilirliğini sağlayın

Sorumluluklarını yerine getirmek için üst yönetim tarafından aşağıdaki adımlar atılabilir -

• Kuruluşun yazılım kalite politikasını oluşturmak ve güncellemek.

• Yazılım kalitesi konularından sorumlu olmak üzere SQA Başkan Yardımcısı gibi yöneticilerden birini atamak

• Yazılım kalitesi sorunları ile ilgili olarak performansın düzenli yönetim incelemelerinin yapılması

Yazılım Kalite Politikası

Kuruluşun yazılım kalitesi politikası aşağıdaki gereksinimleri bildirmelidir -

• Kuruluşun amaç ve hedeflerine uygunluk

• Genel yazılım kalite güvence kavramlarına bağlılık

• Kuruluş tarafından benimsenen kalite standartlarına bağlılık

• Yazılım kalite güvencesi için yeterli kaynakları tahsis etme taahhüdü

• Kuruluşun kalitesinin ve üretkenliğinin sürekli iyileştirilmesine bağlılık

Yazılım Kalitesinden Sorumlu Yönetici

Yazılım kalitesi konularından sorumlu yöneticinin sorumlulukları şu şekilde sınıflandırılabilir:

• Yıllık SQA faaliyetleri programı ve bütçesi hazırlama sorumluluğu

• SQA sistem geliştirme planlarının hazırlanması sorumluluğu

• Yıllık SQA düzenli faaliyetler programının ve planlanan SQA geliştirme projelerinin uygulamasının genel kontrolü

• SQA konularının üst yönetime sunumu ve savunuculuğu

Yıllık SQA Faaliyetleri Programının Hazırlanma Sorumluluğu

Bu, yöneticinin şunları yapmasını gerektirir:

• Önümüzdeki yıl için sistemin SQA hedeflerini belirleyin

• Yıllık faaliyetler programı için SQA birimi tarafından hazırlanan teklifleri gözden geçirin ve teklifin SQA sistemi için belirlenen hedefleri yerine getirme potansiyelini doğrulayın

• Faaliyet programının önümüzdeki yıl için planlanan alt yüklenici hizmetleri ve yazılım satın alımlarının özelliklerine ve kapsamına uygun olup olmadığının belirlenmesi

• SQA programının uygulanması için planlanan insan gücünün ve diğer kaynakların yeterliliğinin belirlenmesi

• Yıllık SQA faaliyetleri programının ve bütçesinin son halini onaylayın

SQA Sistem Geliştirme Planlarının Hazırlanması Sorumluluğu

Bu planlar teknolojik değişikliklere olduğu kadar müşteri taleplerine ve rekabete uyarlanabilmelidir. Sorumluluklar şunları içerir:

• Yakın gelecekte kuruluşun yazılım kalitesini etkilemesi beklenen eğilimlerin gözden geçirilmesi

• Yeni araçlara ve SQA standartlarına uygun yeni prosedürlerin hazırlanması gibi SQA uyarlamaları için önerileri gözden geçirin

• Deneyimli yazılım geliştirme ekipleri ve yeni işe alınan ekip üyeleri için eğitim programlarının hazırlanması

• Eğitim programlarının başarısının yanı sıra yeni araç ve standartların değerlendirilmesine uygun yazılım kalitesi ölçütlerinin geliştirilmesi

• Planları ve bütçeleri dahil planlanan SQA geliştirme projelerinin son versiyonunun onaylanması

Yıllık SQA Programının Uygulanmasının Genel Kontrolü

Sorumlu yönetici şunlardan sorumludur:

• Yıllık faaliyet programının genel denetimi

• SQA adaptasyon projelerinin ilerlemesinin gözden geçirilmesi

• Ekiplerin hedeflerinin belirlediği kalite kazanımlarını gerçekleştirmek için alınan eylemlerin genel denetimi (periyodik raporlara dayalı olarak)

• İç kalite denetimlerine dayalı olarak SQA prosedürlerine ve standartlarına uygunluğun incelenmesi

• Yazılım geliştirme proje programlarına ve bütçelerine uyumun genel takibi

• Dış ve iç müşterilere kaliteli bakım hizmetlerinin sağlanmasının genel takibi

SQA Konularının Üst Yönetime Sunumu ve Savunuculuğu

Kaliteyi artırmak ve SQA sistemi zorluklarını çözmek için gerektirir -

• Önerilen yıllık faaliyet programı ve bütçesinin nihai onayına ilişkin sunum

• İlgili bütçelerle birlikte planlanan SQA adaptasyon projelerinin nihai onayına yönelik sunum

• Kuruluşun yazılım kalitesine adanmış periyodik yönetim gözden geçirme toplantılarının başlatılması ve liderliği

• Şiddetli kalite hataları, ciddi profesyonel kadro eksiklikleri nedeniyle projelerin başarılı bir şekilde tamamlanmasına yönelik tehditler, SQA birimindeki yönetimsel krizler gibi özel yazılım kalitesi olaylarına adanmış yönetim düzeyinde tartışmaların başlatılması

SQA için Departman Yönetim Sorumlulukları

Orta yönetimin kalite güvence sorumlulukları şunları içerir:

• Yazılım kalite yönetim sisteminin yönetimi (kalite sistemi ile ilgili görevler)

• Belirli bir yöneticinin yetkisi altındaki birimler veya ekipler tarafından gerçekleştirilen proje ve hizmetlerle ilgili görevlerin yönetimi (proje ile ilgili görevler)

Kalite sistemi ile ilgili sorumluluklar

Bunlar, departman düzeyinde gerçekleştirilecek SQA faaliyetlerini içerir -

• SQA birimi tarafından hazırlanan önerilen programa dayalı olarak, departmanın yıllık SQA faaliyetleri programının ve bütçesinin hazırlanması

• SQA birimi tarafından hazırlanan önerilen plana dayalı olarak departmanın SQA sistemleri geliştirme planlarının hazırlanması

• Bölümün yıllık SQA faaliyetleri programının ve geliştirme projelerinin performansının kontrolü

• Departmanın SQA konularının üst yönetime sunumu

Proje ile ilgili Sorumluluklar

Bunlar, kuruluşun prosedürlerine ve yetki dağılımına göre değişir; genellikle içerirler -

• CAB, SCM ve SCCA organları dahil olmak üzere departmanın birimlerindeki kalite güvence prosedürlerine uygunluğun kontrolü

• Sözleşme inceleme sonuçlarının ve teklif onaylarının detaylı takibi

• Planlanan gözden geçirme faaliyetlerinin birim performansının gözden geçirilmesi; proje belgelerinin onaylanması ve proje aşamasının tamamlanması

• Yazılım testlerinin ve test sonuçlarının takibi; projenin yazılım ürünlerinin onayı

• Yazılım geliştirme proje programları ve bütçe sapmalarının ilerlemesinin takibi

• Program, bütçe ve müşteri ilişkileri zorluklarını çözmede proje yöneticilerine tavsiye ve destek

• Bakım hizmetleri sunumunun kalitesinin takibi

• Proje risklerinin ve çözümlerinin detaylı takibi

• Projenin müşteri şartlarına uygunluğunun ve müşteri memnuniyetinin takibi

• Büyük yazılım değişiklik siparişlerinin ve proje özelliklerinden önemli sapmaların onaylanması

Yazılım kalitesine ilişkin proje yönetimi sorumlulukları

Çoğu proje yönetimi sorumluluğu prosedürler ve çalışma talimatlarında tanımlanmıştır; proje yöneticisi, tüm ekip üyelerinin söz konusu prosedürlere ve talimatlara uymasını sağlamaktan sorumlu kişidir.

Görevleri arasında, özellikle aşağıdakiler olmak üzere, profesyonel uygulamalı ve yönetsel görevler bulunmaktadır:

• Professional hands-on tasks

  • Proje ve kalite planlarının hazırlanması ve güncellemeleri

  • Ortak müşteri-tedarikçi komitesine katılım

  • İşe alım, eğitim ve talimat dahil olmak üzere proje ekibi kadrosunun yakından takibi

• Management tasks

  Proje yöneticileri aşağıdaki gibi takip sorunlarını ele alır:

  • Gözden geçirme faaliyetlerinin gerçekleştirilmesi ve sonrasında yapılan düzeltmeler

  • Yazılım geliştirme ve bakım biriminin performans, entegrasyon ve sistem test faaliyetleri ile düzeltme ve regresyon testleri

  • Kabul testlerinin performansı

  • Uzak müşteri sitelerinde yazılım kurulumu ve yazılım sisteminin müşteri tarafından yürütülmesi

  • Proje ekibi üyelerinin SQA eğitimi ve talimatı

  • Proje faaliyetlerine tahsis edilen programlar ve kaynaklar

  • Müşteri istekleri ve memnuniyeti

  • Değişen proje geliştirme riskleri, çözümlerin uygulanması ve sonuçların kontrolü

SQA biriminin yapısı, kuruluşun türüne ve büyüklüğüne göre değişir. Aşağıdaki şekil, standart bir yapı örneğini ve bir SQA ünitesi altındaki tüm bileşenleri göstermektedir. Bu bölümde, her bir alt birimin rollerini ve sorumluluklarını tartışacağız.

SQA Birimi Başkanı Tarafından Yapılan Görevler

SQA biriminin başkanı, SQA birimi ve alt birimleri tarafından gerçekleştirilen tüm kalite güvence görevlerinden sorumludur. Bu görevler aşağıdaki kategorilerde sınıflandırılabilir -

• Planlama görevleri
• Birimin yönetimi
• SQA mesleki faaliyetleri

Planlama Görevleri

• Birim için önerilen yıllık faaliyet programı ve bütçesinin hazırlanması

• Kuruluşun yazılım kalite yönetim sistemini planlamak ve güncellemek

• Yazılım geliştirme ve bakım departmanları için önerilen yıllık SQA etkinlik programlarının ve SQA sistem geliştirme planlarının hazırlanması

Yönetim Görevleri

• SQA ekibinin faaliyetlerinin yönetimi

• SQA faaliyet programının uygulanmasının izlenmesi

• Ekip üyelerinin, SQA komite üyelerinin ve SQA mütevellilerinin atanması

• Kuruluş içindeki yazılım kalitesi sorunlarının durumu ve aylık performans raporları gibi özel ve periyodik raporların hazırlanması

SQA Profesyonel Faaliyetleri

• Proje ortak komitelerine katılım
• Resmi tasarım incelemelerine katılım
• Spesifikasyonlardan sapmaların gözden geçirilmesi ve onaylanması
• Proje yöneticileri ve ekip liderleri ile istişare
• SQA komitelerine ve forumlarına katılım

Proje Yaşam Döngüsü SQA

Proje yaşam döngüsü alt birimiyle ilgili SQA görevleri iki gruba ayrılabilir -

• "Saf" yönetimsel takip ve onay görevleri (proje yaşam döngüsü kontrol görevleri)

• Profesyonel katkıların gerekli olduğu proje ekibi SQA faaliyetlerine "uygulamalı" veya aktif katılım (katılım görevleri)

Proje Yaşam Döngüsü Kontrol Görevleri

• Geliştirme ve bakım ekibinin SQA prosedürlerine ve çalışma talimatlarına uygunluğunun takibi

• Yazılım ürünlerinin ilgili prosedürlere göre onaylanması veya önerilmesi

• Yazılım bakım hizmetlerinin iç ve dış müşterilere teslimatının izlenmesi

• Müşteri memnuniyetini izlemek ve müşterinin kalite güvence temsilcileriyle iletişimi sürdürmek

Katılım Görevleri

Bu görevler şunları içerir:

• Sözleşme incelemeleri
• Proje geliştirme ve kalite planlarının hazırlanması ve güncellenmesi
• Biçimsel tasarım incelemeleri
• Taşeronların resmi tasarım incelemeleri
• Müşteri kabul testleri dahil yazılım testi
• Taşeronların yazılım ürünlerinin yazılım kabul testleri
• Yeni yazılım ürünlerinin kurulumu

SQA Altyapı İşlemleri Görevleri

SQA sistemleri, sorunsuz bir şekilde çalışmak için çeşitli altyapı bileşenlerini kullanır, yani -

• Prosedürler ve çalışma talimatları
• Kaliteli cihazları destekleme (şablonlar, kontrol listeleri)
• Personel eğitimi, eğitimi ve sertifikasyonu
• Önleyici ve düzeltici eylemler
• Konfigürasyon yönetimi
• Dokümantasyon kontrolü

Daha spesifik olarak, SQA alt biriminin bu bileşenlerle ilgili görevleri şunları içerir:

• Prosedürlerin, çalışma talimatlarının, şablonların, kontrol listelerinin ve benzerlerinin güncellenmiş versiyonlarının basılı kopya olarak ve / veya elektronik yollarla dolaşımlarıyla birlikte yayınlanması

• Yeni ve mevcut personele SQA prosedürlerine, çalışma talimatlarına ve benzer öğelere uyma ve bunların uygulanmasına ilişkin eğitim ve talimatların iletilmesi

• SQA mütevellilerine, diğer bileşenlerin yanı sıra, yeni ve revize edilmiş prosedürlerin yanı sıra geliştirme araçları ve yöntemleri hakkında talimat verilmesi

• Yeni ve revize edilmiş SQA prosedürlerinin uygulanmasının izlenmesi ve desteklenmesi

• Personel sertifikasyon faaliyetlerinin takibi

• CAB komitelerine katılım dahil olmak üzere önleyici ve düzeltici eylemler gerektiren konuların önerisi

• CCA komitelerine katılım dahil konfigürasyon yönetimi faaliyetlerinin takibi

• Dokümantasyon prosedürlerine ve çalışma talimatlarına uygunluğun takibi

SQA İç Denetim ve Sertifikasyon Görevleri

Yazılım kuruluşlarında veya yazılım kuruluşlarında gerçekleştirilen SQA denetim türleri aşağıdaki şekilde sınıflandırılabilir:

• İç denetimler

• Alt yüklenici ve tedarikçilerin SQA sistemlerini değerlendirmek için denetimleri

• Belgelendirme kuruluşları tarafından gerçekleştirilen dış denetimler

• Organizasyonu tedarikçi olarak kabul etmeden önce SQA sistemini değerlendirmek isteyen müşteriler tarafından gerçekleştirilen dış denetimler

İlk iki denetim sınıfı, SQA alt birimi tarafından başlatılır ve gerçekleştirilir, son ikisi ise dış kuruluşlar tarafından gerçekleştirilir.

SQA birimi, dahili SQA denetimleri için aşağıdaki görevleri gerçekleştirir

• Dahili SQA denetimleri için yıllık programların hazırlanması

• Dahili SQA denetimlerinin performansı

• Denetlenen ekipler ve diğer birimler tarafından yapılacak düzeltme ve iyileştirmelerin takibi

• İyileştirme tavsiyeleri de dahil olmak üzere denetim bulgularının durumuna ilişkin periyodik özet raporların hazırlanması

SQA birimi, taşeron ve tedarikçilerin denetimleri için aşağıdaki görevleri yerine getirir -

• Taşeron ve tedarikçilerin SQA denetimleri için yıllık programın hazırlanması

• Alt yükleniciler ve tedarikçilerin SQA denetimlerinin performansı

• Denetlenen alt yüklenici ve tedarikçiler tarafından yapılacak düzeltme ve iyileştirmelerin takibi

• Alt yükleniciler ve tedarikçilerin performansına ilişkin verilerin iç ve dış kaynaklardan toplanması

• Denetim raporlarına ve diğer iç ve dış kaynaklardan toplanan bilgilere dayalı olarak kuruluşun sertifikalı alt yüklenicilerinin ve tedarikçilerin SQA sistemlerinin periyodik değerlendirmesi. Değerlendirme raporu şunları içerir:

  • Taşeron ve tedarikçilerin sertifikalandırılmasına ilişkin öneriler

  • Belgelendirme kuruluşları tarafından gerçekleştirilen dış denetimler aşağıdaki görevleri içerir:

    • Sertifikasyon denetiminin içeriğinin ve programının koordinasyonu

    • Belgelendirme kuruluşları tarafından belirtilen belgelerin hazırlanması

    • Denetlenen ekiplere talimat verilmesi ve belgelendirme denetimleri için gerekli hazırlıkların yapılması

    • Sertifika denetimlerine katılım

    • Gerekli düzeltmelerin ve iyileştirmelerin yapıldığından emin olun

Kuruluşun müşterileri tarafından gerçekleştirilen SQA denetimleri şu görevleri gerektirir -

• Denetimin içeriğinin ve programının koordinasyonu

• Müşterinin denetçisi tarafından belirtilen belgelerin hazırlanması

• Denetlenen ekiplere talimat verilmesi ve SQA denetimleri için gerekli hazırlıkların kuruluşun müşterileri tarafından yapılması

• Denetimlere katılım

• Gerekli düzeltmelerin ve iyileştirmelerin yapıldığından emin olun

SQA Destek Görevleri

SQA destek hizmetlerinin tüketicilerinin çoğu kuruluş içinde yer almaktadır. Proje yöneticileri, ekip liderleri ve SQA mütevellilerini içerir. Görevleri şunları içerir:

• Proje planlarının ve proje kalite planlarının hazırlanması

• İnceleme ekiplerinde görevlendirme

• Tanımlanan yazılım geliştirme risklerini çözmek için önlemlerin seçimi

• Program gecikmelerini ve bütçe aşımlarını çözmek için önlem seçimi

• SQA ölçümleri ve yazılım maliyeti bileşenlerinin seçimi

• SQA bilgi sisteminin kullanımı

• SQA birimi tarafından biriktirilen arıza deneyimi verilerini yansıtan geliştirme metodolojileri ve araçları seçimi

SQA Standartları ve Prosedürleri Görevleri

SQA alt birimi, hangi SQA standartlarının benimseneceğine karar vermenin yanı sıra kuruluşun prosedürlerinin geliştirilmesi ve sürdürülmesinde yakından ilgilenir. Görevli yükümlülüklerini yerine getirmek için, SQA biriminin şunları yapması gerekir:

• Yeni prosedürlerin ve prosedür güncellemelerinin geliştirilmesi için yıllık bir program hazırlayın

• Uygun komitelere ve forumlara katılımla yeni prosedürlerin ve prosedür güncellemelerinin geliştirilmesinden sorumlu olun

• SQA ve yazılım mühendisliği standartlarındaki gelişmeleri ve değişiklikleri takip etmek; organizasyonla ilgili ek prosedürlerin ve değişikliklerin tanıtılması

• Kuruluş tarafından uygulanan standartların benimsenmesi veya silinmesi dahil olmak üzere, mesleki standartlardaki değişikliklere yanıt olarak prosedürlerin güncellemelerini ve uyarlamalarını başlatmak

SQA Mühendislik Görevleri

Profesyonel ilerlemelerin takibi, operasyonel zorlukların çözümü ve başarısızlıkların uzman analizi bu SQA alt biriminin acil hedefleridir.

Bu nedenle, ana mühendislik görevleri aşağıdakileri içerir -

• Yeni geliştirme araçları ve şu anda kullanılan geliştirme araçlarının yeni sürümleri ile ilgili olarak kalite ve üretkenlik yönlerinin test edilmesi

• Yeni geliştirme ve bakım yöntemlerinin ve yöntem iyileştirmelerinin kalite ve verimliliğinin değerlendirilmesi

• Halihazırda kullanılan yazılım geliştirme araç ve yöntemlerinin uygulanmasında karşılaşılan zorluklara çözüm geliştirilmesi

• Yazılım kalitesini ve ekip verimliliğini ölçmek için yöntemlerin geliştirilmesi

• Yazılım geliştirme hatalarının analizi ve önerilen çözümlerin formülasyonu sırasında CAB komitelerine teknolojik destek sağlanması

SQA Bilgi Sistemleri Görevleri

SQA bilgi sistemleri, SQA sistemlerinin işleyişini kolaylaştırmak ve iyileştirmek içindir. İlgili görevler şunları içerir:

• Yazılım geliştirme ve bakım birimleri için SQA bilgi sistemlerinin geliştirilmesi

  • aktivite verilerinin toplanması

  • Örneğin periyodik raporların, listelerin, istisna raporlarının ve sorguların işlenmesi

  • Örneğin periyodik raporların, listelerin, istisna raporlarının ve sorguların işlenmesi

• Yazılım kalite ölçütleri ve yazılım kalitesi maliyetleri tahminleri dahil olmak üzere, SQA biriminin yazılım geliştirme ve bakım birimleri tarafından sağlanan bilgileri işlemesini kolaylaştıran SQA bilgi sistemlerinin geliştirilmesi

• SQA bilgi sistemlerini güncelleme

• Kuruluşun SQA İnternet / Intranet sitesinin geliştirilmesi ve bakımı

SQA Mütevellileri ve Görevleri

SQA mütevellileri, öncelikle yazılım kalitesinin geliştirilmesinde yer alan üyelerdir. Bu üyeler, SQA bileşenlerinin başarılı bir şekilde uygulanması için gerekli olan dahili desteği sağlar.

Görevleri kuruluşlara göre değişebilir. Buna göre, birimle ilgili ve / veya organizasyonla ilgili görevler olabilir.

Birimle İlgili Görevler

• Yazılım kalitesi prosedürlerinin ve iş talimatlarının uygulanması sırasında karşılaşılan zorlukları çözmek için meslektaşları destekleyin

• İlgili SQA görevlerini yerine getirmede birim yöneticisine yardımcı olun

• Uyumluluğu teşvik edin ve SQA prosedürlerinin ve çalışma talimatlarının meslektaşlar tarafından uygulanmasını izleyin

• Önemli ve sistematik uyumsuzluk olaylarını SQA birimine bildirin

• SQA birimine ciddi yazılım kalitesi hatalarını bildirin

Organizasyonla İlgili Görevler

• Kuruluş çapında SQA prosedürlerinde ve çalışma talimatlarında değişiklikleri ve güncellemeleri tetikleyin

• Organizasyondaki geliştirme ve bakım süreçlerinde iyileştirmeleri tetikleyin

• İlgili birimlerde gözlemlenen tekrarlayan arızaların çözümleriyle ilgili CAB'ye başvuruları başlatmak

• Kuruluş genelinde SQA eğitim ihtiyaçlarını belirleyin ve SQA birimi tarafından yürütülecek uygun eğitim veya talimat programını önerin

SQA Komiteleri ve Görevleri

SQA komiteleri kalıcı veya geçici olabilir. Görevler organizasyondan organizasyona önemli ölçüde değişebilir.

• Permanent committees genellikle SCC (Yazılım Değişikliği Kontrolü), CA (Düzeltici Eylemler), prosedürler, yöntem geliştirme araçları ve kalite ölçütleriyle ilgilenir.

• Ad hoc committees Genellikle, belirli bir prosedürün güncellenmesi, bir yazılım arızasının analizi ve çözümü, hedeflenen bir süreç veya ürün için yazılım ölçütlerinin detaylandırılması, belirli bir sorun için yazılım kalite maliyetlerinin ve veri toplama yöntemlerinin güncellenmesi gibi genel ilgi alanına giren özel durumlarla ilgilenir.

Kalıcı SQA komiteleri, SQA organizasyon çerçevesinin ayrılmaz parçalarıdır; görevleri ve operasyonları genellikle kuruluşun SQA prosedürlerinde tanımlanır.

Yazılım kalitesi konularından sorumlu yönetici tarafından atanan üyeler, SQA Birimi başkanı, SQA alt birimleri, kalıcı SQA komiteleri veya başlatan başka herhangi bir organ ile geçici komiteler sorun başına kısa vadeli olarak kurulur. oluşumu ve işle ilgisi vardır. Bu organ aynı zamanda geçici komitenin görevlerini de tanımlar.