Yazılım kalitesi yazılım mühendisliğinin sürekli bir endişesidir ve birçok bilgi alanında tartışılmaktadır.

• Phil Crosby: Kalite, kullanıcı gereksinimlerini karşılamaktır.
• Watt Humphrey: Kalite, mükemmel bir kullanılabilirlik düzeyine ulaşıyor.
• IBM Şirketi:"piyasa odaklı kalite" ifadesini icat etti.
• Baldridge'in kriteri:"müşteri odaklı kalite".
• ISO 9001 Kalite Yönetim Sistemi: Kalite, doğal özelliklerin gereksinimleri karşılama derecesidir.

Kabul edilebilir kalite- bu, kullanıcıları tatmin edebilen ve belirtilen tasarım kısıtlamaları dahilinde ulaşılabilen, yaratılan ürünün (hizmetin) istenen mükemmellik derecesidir.

Proje faaliyetlerinde kalite:

• Gereksinim yönetimi (fonksiyonel olmayan gereksinimlerin bir kategorisi olarak “kalite nitelikleri”);
• Test etme (arızalar arasındaki süre, MTTF - Arızaya Kadar Ortalama Süre, yani algılanan sistem arızaları arasındaki ortalama süre vb. gibi metrikler).

"Kabul edilebilir kalite" belirli bir SLA - Hizmet Düzeyi Sözleşmesi içindeki hizmet düzeyiyle karşılaştırılabilir. Yani, kabul edilebilir kalite olarak kabul edilebilir<количественно выраженный>Müşteri ve yüklenici arasında, yüklenici tarafından oluşturulan ürünün özelliklerine ilişkin olarak,<решения задач>müşteri, diğer proje kısıtlamalarını (özellikle, genellikle "kalite maliyeti" - "kalite maliyeti" olarak adlandırılan maliyet) dikkate alarak.

Şekil "Bilgi Alanı - Yazılım Kalitesi"

Şekil "Kalite yönetim sistemi modeli"

Yazılım Kalitesinin Temelleri

Kalite gereksinimleri (orijinal - kalite gereksinimlerinde) ve mühendislere kaliteyi neyin oluşturduğuna dair net bir iletişim üzerinde anlaşmaya varıldı<получаемого продукта>, kalitenin birçok yönünün tartışılmasını ve resmi tanımını gerektirir.

Mühendislerin, geliştirilmekte veya sürdürülmekte olan yazılımla ilgili olarak kalite kavramını, kalitenin özelliklerini ve anlamını anlamaları gerekir.

Buradaki önemli fikir, yazılım gereksinimlerinin gerekli yazılım kalite özelliklerini tanımlaması ve aynı zamanda bu özellikleri ölçme ve formüle etme yöntemlerini etkilemesidir.<соответствующие>Kabul şartları.

Yazılım mühendisliği kültürü ve etiği (Yazılım Mühendisliği Kültürü ve Etiği)

Yazılım mühendislerinden, yazılım kalitesi konularını görevlerinin bir parçası olarak almaları beklenir.<профессиональной>kültür.
Etik, yazılım kalite güvencesinde, mühendislerin kültür ve tutumlarında önemli bir rol oynayabilir<к своей работе>. IEEE Computer Society ve ACM, mühendislerin kalite ve bağımsızlık konusundaki tutumlarını güçlendirmelerine yardımcı olmak için sekiz ilkeye dayalı bir etik kodu ("etik kuralları") ve profesyonel uygulama geliştirmiştir.<в решении вопросов обеспечения достойного качества создаваемых программных продуктов>günlük işlerinde.

Kalitenin Değeri ve Maliyetleri

Aslında "kalite" kavramı ilk bakışta göründüğü kadar açık ve basit değildir. Herhangi bir mühendislik ürünü için birçok<интерпретаций>kalite, belirli “koordinat sistemine” bağlı olarak. Bu bakış açılarının birçoğunun bir yazılım ürünü için gereksinimlerin geliştirilmesi aşamasında tartışılması ve tanımlanması gerekir. Kalite özellikleri değişen derecelerde gerekli olabilir, olmayabilir veya belirli gereksinimler getirebilir, tüm bunlar belirli bir uzlaşmanın sonucu olabilir.

Kalite maliyeti şu şekilde ayrılabilir:

• uyarı maliyeti<дефектов>(önleme maliyeti),
• değerleme maliyeti,
• iç başarısızlık maliyeti,
• dış başarısızlık maliyeti.

Yazılım projelerinin arkasındaki itici güç değeri olan bir yazılım yaratma arzusudur. Yazılımın değeri maliyet olarak ifade edilebilir veya edilmeyebilir. Müşteri genellikle, yazılım geliştirmenin ana hedeflerine ulaşılırsa geri dönüşü beklenen maksimum maliyet yatırımı hakkında kendi fikrine sahiptir. Müşterinin ayrıca yazılımın kalitesiyle ilgili belirli beklentileri olabilir. Bazen müşteriler kalite sorunları ve bununla ilişkili maliyet hakkında düşünmezler. Kalite özellikleri tamamen dekoratif mi yoksa yazılımın ayrılmaz bir parçası mı? Bu gibi durumlarda neredeyse her zaman olduğu gibi, yanıt muhtemelen ortada bir yerde yatmaktadır ve müşterinin karar verme sürecine ne ölçüde dahil olduğu ve müşterinin maliyetleri ve belirli bir kalite düzeyine ulaşmakla ilişkili faydalar. İdeal olarak, bu kararların çoğu gereksinimler sürecinde verilmelidir, ancak bu sorunlar yazılımın yaşam döngüsü boyunca ortaya çıkabilir. hiç yok<“стандартных”>Bu tür kararların nasıl alınması gerektiğine ilişkin kurallar. Ancak mühendisler çeşitli alternatifler ve bunların maliyetlerini sunabilmelidir.

Modeller ve Kalite Özellikleri

ISO/IEC, ilgili üç yazılım kalite modelini tanımlar (ISO 9126-01 Yazılım Mühendisliği - Ürün Kalitesi, Bölüm 1: Kalite Modeli):

• iç kalite,
• dış kalite ve
• operasyon sürecinde kalitenin yanı sıra bir dizi ilgili yazılım kalite değerlendirme çalışması (ISO14598-98 Yazılım Ürün Değerlendirmesi).

Yazılım mühendisliği süreç kalitesi

Kalite yönetimi (yazılım kalite yönetimi) ve yazılım mühendisliği süreçlerinin kalitesi (yazılım mühendisliği süreç kalitesi) oluşturulan yazılım ürününün kalitesiyle doğrudan ilişkilidir.

İki ana yazılım kalite standardı vardır.

• BT'yi işaretleyin- yazılım projelerinin bir eki olarak genel kalite yönetim sistemi ISO 9001-00'in dikkate alınmasıyla ilgilidir.
• Bir diğer önemli standart ise CMMI Yazılım Mühendisliği Süreci bilgi alanında tartışılan , sürecin nasıl iyileştirileceği konusunda rehberlik sağlar. CMMI'nin süreç alanları (yetkinlik alanları) doğrudan kalite yönetimi ile ilgilidir:
  • süreç ve ürün kalite güvencesi, CMMI “Destek” süreç kategorisi,
  • doğrulama (doğrulama, “Mühendislik” kategorisi) ve
  • sertifika (onaylama, “Mühendislik” kategorisi).

Aynı zamanda, CMMI sınıflandırır gözden geçirmek ve denetim doğrulama yöntemleri olarak, ancak bağımsız süreçler olarak değil.

Bu standartlar hala tamamlayıcı olarak kabul edilir ve ISO 9001 sertifikası üst düzey CMMI olgunluk seviyelerine ulaşılmasına yardımcı olur.

Yazılım ürün kalitesi

Her şeyden önce, mühendisler belirlemeli yazılım oluşturma amacı. Bu bağlamda, müşteri gereksinimlerinin birincil olduğunu ve yalnızca işlevsellik (fonksiyonel gereksinimler) değil, kalite gereksinimleri de içerdiğini hatırlamak özellikle önemlidir. Bu nedenle mühendisler, her zaman açıkça sunulmayan kalite gerekliliklerini çıkarmaktan ve bunların önemini ve bunları gerçekleştirmedeki zorluk derecesini tartışmaktan sorumludur. Kalite ile ilgili tüm süreçler (örneğin, montaj, test ve kalite iyileştirme) bu gereksinimler göz önünde bulundurularak tasarlanmalı ve ek maliyetlerin (yazılım maliyetinin önemli bir parçası olarak) yükünü taşımalıdır.

ISO 9126-01 (Yazılım Mühendisliği - Ürün Kalitesi, Bölüm 1: Kalite Modeli) burada açıklanan üç modelden ikisi için, kalitenin ilgili karakteristiklerini ve "alt-karakteristiklerini" ve ayrıca yazılım ürünlerinin kalitesini değerlendirmek için faydalı metrikleri tanımlar.

"Ürün" teriminin anlaşılması, nihai yazılım ürününü oluşturmak için kullanılan tüm süreçlerin çıktısı olarak oluşturulan tüm yapay ürünleri içerecek şekilde genişletilmiştir. Ürün örnekleri şunlardır (ancak bunlarla sınırlı değildir):

• sistem gereksinimlerinin tam belirtimi (sistem gereksinimleri belirtimi),
• sistemin yazılım bileşenleri için yazılım gereksinimlerinin belirtilmesi (yazılım gereksinimleri belirtimi, SRS),
• modeller,
• test dokümantasyonu,
• kalite analiz çalışmaları sonucunda oluşturulan raporlar.

Kalite terimi en sık son ürün ve sistemin çalışma sırasındaki davranışı ile ilgili olarak kullanılmasına rağmen, tüm yazılımlarda ara sonuçlar / yaşam döngüsü ürünleri için belirtilen kalite özelliklerine uygunluğun da değerlendirilmesini şart koşmak iyi bir mühendislik uygulamasıdır. mühendislik süreçleri.

Kalite iyileştirme

Yazılımın kalitesi, yinelemeli bir sürekli iyileştirme süreci ile geliştirilebilir. Bu, aynı anda çalışan birçok süreci yönetme sürecinde kontrol, koordinasyon ve geri bildirim gerektirir:

1. yaşam döngüsü süreçleri
2. arızaları/kusurları tespit etme, düzeltme ve önleme süreci ve
3. kalite iyileştirme süreçleri.

Yazılım mühendisliğine uygulanabilir teoriler ve kavramlar temel kalite iyileştirme. Örneğin, "kaliteyi inşa etme" ilkesini oluşturan hataların önlenmesi ve erken teşhisi, sürekli iyileştirme (sürekli iyileştirme) ve müşteri gereksinimlerine dikkat edilmesi (müşteri odaklılık). Bu kavramlar, bir ürünün kalitesinin, onu oluşturmak için kullanılan süreçlerin kalitesiyle doğrudan ilişkili olduğuna inanan kalite uzmanlarının çalışmalarına dayanmaktadır.

gibi yaklaşımlar TKY(Toplam Kalite Yönetimi - toplam kalite yönetimi) ve PDCA(Planla, Yap, Kontrol Et, Önlem Al - Planlama, Eylem, Kontrol Et, Müdahale / Düzeltme), kalite ile ilgili hedeflere ulaşmak için kullanılan araçlardır. Yönetim desteği, süreçlerin yürütülmesine, ürünlerin değerlendirilmesine ve gerekli tüm verilerin elde edilmesine yardımcı olur. Ek olarak, geliştirilen iyileştirme programı (genellikle bir birimin veya organizasyonun çalışmasını bir bütün olarak hedefleyen ve kapsayan iyileştirme programı), iyileştirmeye yönelik tüm eylemleri ve projeleri ayrıntılı olarak tanımlar.<отдельных аспектов деятельности>ilgili görevlerin başarılı bir şekilde çözülmesiyle bu tür projelerin gerçekleştirilebileceği belirli bir süre içinde. Aynı zamanda, yönetim desteği, tüm iyileştirme projelerinin hedeflerine ulaşmak için yeterli kaynağa sahip olduğu anlamına gelir. Yönetim desteği, ekipte aktif etkileşimin uygulanmasıyla yakından ilgilidir ve potansiyel sorunların (ve iyileştirme programının veya bireysel projelerinin uygulanmasına pasif veya hatta aktif muhalefetin) ortaya çıkmasını önlemelidir. Çalışma gruplarının oluşturulması, orta düzey yöneticilerin desteği ve proje düzeyinde tahsis edilen kaynaklar “Yazılım Mühendisliği Süreci” Bilgi Alanında tartışılmaktadır.

Yazılım Kalite Süreçleri

Yazılım kalite yönetimi (SQM, Yazılım Kalite Yönetimi) süreçlerin, ürünlerin ve kaynakların tüm yönleri için geçerlidir. SQM, süreçleri, süreç sahiplerini ve ayrıca süreçler için gereksinimleri, süreçlerin ölçümlerini ve sonuçlarını ve ayrıca geri bildirim kanallarını tanımlar.

Kalite yönetim süreçleri birçok aktiviteyi içermektedir. Bazıları doğrudan kusurları bulmanıza izin verirken, diğerleri daha ayrıntılı araştırma yapmanın tam olarak nerede önemli olabileceğini belirlemenize yardımcı olur, ardından yine hataları doğrudan tespit etmek için çalışma yapılır. Her iki amaca da ulaşmak amacıyla birçok eylem de gerçekleştirilebilir.

Yazılım kalite planlaması şunları içerir:

1. İstenilen ürünün kalite özellikleri açısından tanımlanması.
2. Gerekli ürünü elde etmek için planlama süreçleri.

Bu süreçler, kendi başına SQM süreçlerinden farklıdır, bu da bu planları fiilen uygulamak yerine planlı kalite performansını değerlendirmeye odaklanır. Kalite yönetimi süreçleri, ürünün müşteri ve paydaş ihtiyaçlarını ne kadar iyi karşılayacağını, müşteri ve paydaşlara değer sağlayacağını ve belirtilen yazılım gereksinimlerini karşılamak için gereken kalitede olacağını ele almalıdır.

SQM, hem nihai hem de ara ürünleri değerlendirmek için kullanılabilir. Özel SQM süreçlerinden bazıları 12207 standardında tanımlanmıştır:

• Kalite güvence süreci;
• Doğrulama süreci;
• Doğrulama işlemi;
• Ortak inceleme süreci;
• denetim süreci.

Tüm bu süreçler kalite arayışını destekler ve ayrıca olası hataların aranmasına yardımcı olur. Ancak, odaklandıkları şeyde farklılık gösterirler.

SQM süreçleri görev ve tekniklerden oluşur yazılım geliştirme planlarının nasıl gerçekleşmeye başladığını ve ara ve nihai ürünlerin belirtilen gereksinimleri ne kadar iyi karşıladığını değerlendirmek için tasarlanmıştır. Bu görevlerin sonuçları, uygun düzeltici önlem alınmadan önce yöneticilere rapor edilir. SQM süreci, raporlama verilerinin doğru olduğuna dair güven temelinde yönetilir.
Bu Bilgi Alanında açıklandığı gibi, SQM süreçleri yakından ilişkilidir. Üst üste gelebilirler ve hatta bazen üst üste gelebilirler. Süreçleri öğrenilen uygulamalar ve halihazırda üretilmiş ürünler bağlamında değerlendirdikleri için, doğaları gereği reaktif görünüyorlar. Ancak, paydaşlar tarafından talep edilen niteliklere ve kalite seviyelerine ulaşmak için gerekli süreçler ve prosedürler olarak proaktif olarak planlama aşamasında önemli bir rol oynarlar.<проекта>yazılım.

Risk yönetimi, kaliteli yazılım sağlamada da önemli bir rol oynayabilir. “Düzenli” (periyodik değil, kalıcı olarak; orijinal - disiplinli) risk analizinin dahil edilmesi ve<соответствующих>kontrol teknisyeni<рисками>yazılım yaşam döngüsü süreçlerinde, kaliteli bir ürün üretme potansiyelini artırabilir. Risk yönetimi hakkında daha fazla bilgi Yazılım Mühendisliği Yönetimi bilgi alanında bulunabilir.

Yazılım Kalite Güvencesi (SQA)

SQA süreçleri yazılım ürünlerinin ve proje yaşam döngüsü süreçlerinin belirtilen gereksinimleri karşıladığının teyidini sağlar. Bu onay, planlama (planlama), ayarlama temelinde gerçekleştirilir.<работ>kaliteyi yazılımın ayrılmaz bir parçası haline getirmeyi amaçlayan bir dizi eylem (gerçekleştirme) ve yürütme (gerçekleştirme).
Böyle bir görüş, sorunun açık ve kesin bir formülasyonunun yanı sıra, ilgili gereksinimler için gereksinimlerin olduğu gerçeğini ima eder.<программному>karar. SQA, tüm aşamalarda çeşitli faaliyetlerin uygulanması yoluyla geliştirme ve bakım sürecinde kalite güvencesi sağlar.<жизненного цикла>, herhangi bir karmaşık aktivitede neredeyse kaçınılmaz olan sorunları erken bir aşamada tanımlamanıza olanak tanır.

Risk yönetimi yazılım kalite güvencesi için ciddi bir ek araçtır.

SWEBOK tarafından formüle edilen SQA, süreçlere odaklanır. SQA'nın rolü, süreçlerin uygun şekilde planlanmasını, verilen plana göre süreçlerin yürütülmesine devam edilmesini ve ölçüm sonuçlarının ilgililere aktarılması ile süreçlerin gerekli ölçümlerinin yapılmasını sağlamaktır. partiler (kuruluş yapıları ve bireyler).

SQA planı geliştirilmekte olan ürünün, verilen tasarım kısıtlamaları altında mümkün olan en yüksek kalite seviyesi ile belirtilen kullanıcı gereksinimlerini karşılamasını sağlamak için kullanılacak araçları tanımlar.

Bunu başarmak için, her şeyden önce, kalite hedeflerinin açıkça tanımlanması ve anlaşılması (ve ayrıca, herhangi bir hedef ve ilgili gereksinimler için bir ön koşul olan, açık bir şekilde yorumlanması) gereklidir. Bu, mutlaka ilgili yönetim planlarına yansıtılmalıdır.<проектом>, geliştirme ve bakım.

Kalite güvencesi için belirli faaliyetler ve görevler, maliyet ve ilgili kaynaklar için gereksinimleri, yönetim bakış açısından hedefleri ve yönetim, geliştirme ve bakım planları tarafından belirlenen hedefler bağlamında karşılık gelen programı detaylandırarak yapılandırılmıştır. SQA planı, proje kontrolünde uygulanan belgeleri, standartları, uygulamaları ve sözleşmeleri ve bu yönlerin verilen plana uygunluğu ve yeterliliği sağlamak için nasıl test edileceğini ve izleneceğini tanımlar.
SQA planı, araçlar, teknikler ve metodolojiler, fiziksel medya güvenliği sorunları, eğitim ve SQA sorunlarıyla ilgili raporlama ve belgeler gibi ölçümleri, istatistiksel teknikleri, sorun raporlamayı ve düzeltici eylem prosedürlerini tanımlar.

Buna ek olarak, SQA planı ayrıca, aşağıda açıklanan diğer faaliyet türleri ile ilgili kalite güvence faaliyetleri konularını da ele almaktadır.<различных>bu yazılım projesi için gerekli özel ve/veya çoğaltılmış/hazır yazılım çözümlerinin (ticari kullanıma hazır, COTS) tedarikini, kurulumunu, bakımını da içeren yazılım geliştirme planları. SQA planı, yazılım kabul kriterlerini ve kalite güvencesi için gerekli raporlama ve yönetim faaliyetlerini içerebilir.<и контролю над>İşler.

Doğrulama ve Doğrulama (V&V)

Yazılım doğrulama ve doğrulama, yazılım ürünlerini yaşam döngüsü boyunca değerlendirmeye yönelik disiplinli bir yaklaşımdır. Doğrulama ve validasyon çalışmaları çerçevesinde yapılan çalışmalar, kalitenin yazılımın ayrılmaz bir özelliği olarak sağlanması ve kullanıcı gereksinimlerinin karşılanmasına yöneliktir.
V&V, yazılım kalitesi sorunlarını doğrudan ele alır ve herhangi bir kusuru tespit etmek için uygun test tekniklerini kullanır. V&V ara ürünler için kullanılabilir, ancak ara "adımlara" karşılık geldiği ölçüde<соответствующих>yaşam döngüsü süreçleri.

V&V süreci, belirli geliştirme ve bakım çalışmalarının ürününün (sonucunun) bu çalışmalar çerçevesinde formüle edilen gereksinimleri ne ölçüde karşıladığını ve nihai ürünün belirlenen hedefleri ve kullanıcı gereksinimlerini ne ölçüde karşıladığını belirler.

Doğrulama- ilgili faaliyet çerçevesinde elde edilen ürünün verilen spesifikasyonları karşılaması anlamında, ürünün doğru şekilde geliştirilmesini sağlama girişimi (ürün doğru şekilde inşa edilmiştir; genellikle ara ürünler için, bazen nihai ürün için), önceki aktivite sürecinde.
sertifika- hedefe ulaşmak açısından doğru ürünün (doğru ürün yapılır; genellikle nihai ürün bağlamında) yaratılmasını sağlama girişimi.

Her iki süreç - doğrulama ve tasdik– geliştirme ve bakımın erken aşamalarında başlayın. Hem hemen önceki sonuçlar (ara ürünler) bağlamında hem de ilgili spesifikasyonları karşılama açısından temel ürün yeteneklerinin araştırılmasını (incelenmesini) sağlarlar. V&V planlamasının amacı, doğrulama ve doğrulama süreçlerine yeterince kaynak sağlanmasını ve rollerin ve sorumlulukların açıkça atanmasını sağlamaktır. Ortaya çıkan V&V planı belgeleri ve<детально>çeşitli kaynakları, rolleri ve faaliyetleri ve kullanılan teknikleri ve araçları açıklar.
Plan ayrıca doğrulama ve yeterlilik faaliyetlerinin yönetim, iletişim (etkileşim), politika ve prosedürler ve bunların etkileşimini de ele almaktadır. Ek olarak, kusurlar hakkında raporlama ve belgelendirme gereklilikleri konularını yansıtabilir.

Değerlendirme (inceleme) ve denetim (İnceleme ve Denetimler)

Beş tür değerlendirme ve denetim:

• Yönetim incelemeleri
• Teknik incelemeler (teknik incelemeler)
• Denetimler
• “Geçişler”
• Denetimler (denetim)

Yönetim İncelemeleri

Yönetim değerlendirmelerinin amacı gelişimi izlemektir.<проекта/продукта>planların ve programların durumunun belirlenmesi, gereksinimlerin onaylanması ve kaynakların tahsis edilmesi veya belirlenen hedeflere ulaşmak için kullanılan yönetim yaklaşımlarının etkinliğinin değerlendirilmesi.

Yönetim değerlendirmeleri, bir yazılım projesinin yürütülmesi sırasında gerektiğinde değişiklik yapma ve düzeltici eylemlerde bulunma kararlarını destekler.

Yönetim değerlendirmeleri, planların, çizelgelerin ve gereksinimlerin yeterliliğini belirlerken aynı zamanda ilerlemelerini veya tutarsızlıklarını da izler. Bu değerlendirmeler ürün üzerinde gerçekleştirilebilir, denetim raporları, durum (geliştirme) raporları, V&V raporları ve çeşitli plan türleri - proje risk yönetimi / proje yönetimi, konfigürasyon yönetimi, güvenlik şeklinde kaydedilebilir.<использования>yazılım (güvenlik), risk değerlendirmesi vb.

Teknik İncelemeler

Teknik değerlendirmelerin amacı, bir yazılım ürününün kullanım amacına uygunluğunu belirlemek için incelemektir. Amaç, onaylanmış spesifikasyonlar ve standartlar ile tutarsızlıkları belirlemektir. Teknik değerlendirmeleri sağlamak için aşağıdaki rollerin dağıtılması gereklidir: karar verici; gözden geçirme lideri; kayıt memuru (kaydedici); ve değerlendirme faaliyetlerini destekleyen (doğrudan yürüten) teknik personel.

Teknik değerlendirme, mutlaka aşağıdaki girdi verilerini gerektirir:

• Hedef Açıklamaları
• Spesifik yazılım ürünü (değerlendirilmekte olan)
• Belirli bir proje planı (proje yönetim planı)
• Ürünle ilgili sorunların (soruların) listesi
• Teknik değerlendirme prosedürleri

Takım<технической оценки> önceden belirlenmiş bir değerlendirme prosedürünü takip eder. Nitelikli (teknik açıdan) kişiler, ürüne genel bir bakış sağlar (geliştirme ekibini temsil eder). Ders çalışma<продукта> bir veya daha fazla toplantı sırasında (ürünü sunanlar ile değerlendirmeyi sağlayanlar arasında) gerçekleştirilir. Teknik değerlendirme, öngörülen tüm ürün araştırma faaliyetleri tamamlandıktan sonra tamamlanır.

Denetimler

Denetimlerin amacı, bir yazılım ürünündeki anormallikleri tespit etmek ve tanımlamaktır. Teftişler ve değerlendirmeler (yönetimsel ve teknik) arasında iki büyük fark vardır:

1. Denetim ekibinin herhangi bir üyesiyle ilgili olarak yönetici pozisyonunda (yönetici) bulunan kişiler denetimlere katılmamalıdır.
2. Denetim, denetim teknikleri konusunda eğitimli tarafsız (projeden ve hedeflerinden bağımsız) bir lider tarafından yönetilmelidir.

Yazılım denetimleri, mutlaka bunu gerektirmeyen değerlendirmelerin aksine, her zaman ara veya nihai ürünün yazarlarını içerir. Teftişler (geçici organizasyon birimleri - gruplar, ekipler olarak) bir lider, bir kayıt memuru, bir gözden geçiren ve birkaç (2'den 5'e kadar) müfettişleri içerir. Denetim ekibinin üyeleri, konu alanı, tasarım yöntemleri, dil vb. gibi farklı uzmanlık alanlarında (farklı uzmanlık alanlarına sahip) uzmanlaşabilir. Belirli bir zaman aralığında (aralık) denetimler, ürünün ayrı küçük bir parçasıyla (çoğu durumda, bireysel işlevsel veya diğer özelliklere odaklanarak; genellikle bireysel iş kurallarından, işlevsel gereksinimlerden veya kalite özelliklerinden başlayarak) gerçekleştirilir. , Yazarın notu). Her ekip üyesi, denetim toplantısından önce yazılım ürününü ve diğer girdileri incelemeli, belki de ürünün küçük parçalarına veya bir bütün olarak ürüne farklı analitik teknikler uygulamalı, ikinci durumda, arayüzler gibi yalnızca bir yönünü dikkate almalıdır. . Bulunan herhangi bir anormallik belgelenmeli ve bilgiler denetim liderine iletilmelidir. Denetim sürecinde lider oturumu yönetir<инспекции>ve her şeyi kontrol eder<члены команды>muayene için hazırlanmıştır.

Teftişlerde kullanılan yaygın bir araç, yönlerle ilgili anormallikleri ve soruları içeren bir kontrol listesidir.<программного продукта>ilgi çekenler. Ortaya çıkan sayfa genellikle anormallikleri sınıflandırır ve eksiksizliği ve doğruluğu için ekip tarafından değerlendirilir. Denetimi tamamlama kararı, üç kriterden birine (herhangi birine) göre verilir:

1. Benimseme<продукта>işleme ihtiyacı olmadan veya çok az ihtiyaç duyarak
2. Benimseme<продукта>geri dönüştürülmüş parçaları kontrol ederek
3. Yeniden inceleme ihtiyacı

Çoğu durumda daha fazla çalışma gerektiren ve dolayısıyla daha uzun süren teknik değerlendirme ve denetimin aksine, teftiş toplantıları genellikle birkaç saat sürer.

gözden geçirmeler

Çalıştırmanın amacı, bir yazılım ürününü değerlendirmektir. İzleyiciyi yazılım ürünüyle tanıştırmak (eğitmek) için bir koşu gerçekleştirilebilir.

Koşunun ana hedefleri şunlardır:

• anomalileri aramak
• Ürün geliştirme
• Alternatif uygulama yollarını tartışmak
• Standartlara ve spesifikasyonlara uygunluğun değerlendirilmesi

Tarama, incelemeye benzer, ancak genellikle daha az resmi bir şekilde gerçekleştirilir. Temel olarak, kalite güvencesinin unsurlarından (tekniklerinden) biri olarak, mühendisler tarafından diğer ekip üyeleri için çalışmaları hakkında onlardan geri bildirim almak için bir çalışma organize edilir.

Denetimler

Yazılım denetiminin amacı yazılım ürünleri ve süreçlerinin geçerli düzenlemelere, standartlara, yönergelere, planlara ve prosedürlere uygunluğunun bağımsız bir değerlendirmesidir.

Denetim, katılımcıların baş denetçi, başka bir denetçi, kaydedici ve başlatıcı gibi belirli roller üstlendiği resmi olarak organize edilmiş bir faaliyettir. Değerlendirilen kurum/kuruluş biriminin bir temsilcisi denetimde yer alır. Denetim sonucunda uygunsuzluk durumları belirlenir ve ekibin ihtiyacı olan rapor oluşturulur.<разработки>düzeltici eylemde bulunmak.

Değerlendirmeler ve denetimler için çeşitli resmi adlar (ve sınıflandırmalar) olsa da, bu tür faaliyetlerin geliştirme veya bakım sürecinin herhangi bir aşamasında hemen hemen her ürün üzerinde gerçekleştirilebileceğini belirtmek önemlidir.

Pratik Hususlar

Yazılım Kalite Gereksinimleri

Etki faktörleri

SQM faaliyetlerinin ve tekniklerinin planlanması, yönetimi ve seçimi, aşağıdakiler de dahil olmak üzere çeşitli faktörlerden etkilenir:

• Yazılımın üzerinde çalışacağı sistemin kapsamı (güvenlik açısından kritik<людей>), iş için kritik, vb.)
• Sistem ve yazılım gereksinimleri
• Sistemde hangi bileşenler kullanılıyor - ticari (harici) veya standart (dahili)
• Belirli bir bağlamda hangi yazılım mühendisliği standartları uygulanabilir?
• Geliştirme ve bakımın yanı sıra kalite güvencesi ve iyileştirme (ürün ve süreçler) için kullanılan yöntemler ve yazılım araçları nelerdir?
• Tüm süreçler için bütçe, personel, proje faaliyetlerinin organizasyonu, planlar ve programlar
• Hedef kullanıcılar kimlerdir ve sistemin amacı nedir?
• Sistem Bütünlük Seviyesi

Bu faktörler hakkındaki bilgiler, SQM süreçlerinin tam olarak nasıl organize edileceğini ve belgeleneceğini, hangi SQM çalışmasının seçileceğini (proje, ekip, organizasyon birimi, organizasyon içinde standartlaştırılmış), hangi kaynaklara ihtiyaç duyulduğunu ve yönlendirilen çabalara getirilen kısıtlamaların neler olduğunu etkiler. kalite güvencesi.

güvenilirlik

Garanti- garanti<высокой>güvenilirlik, arızalardan güvenlik.
Bir sistem arızasının son derece ciddi sonuçlara yol açabileceği durumlarda (bu tür sistemler bazen İngilizce kaynaklarda “yüksek güvenilirlik” veya “yüksek bütünlük sistemi” olarak adlandırılırken, Rusça'da bazen “yüksek güvenilirlik sistemleri”, “yüksek kullanılabilirlik” vb. .), genel (kümülatif) sistem güvenilirliği (donanım, yazılım ve insan kombinasyonu olarak), ana işlevsellik ile ilgili olarak ana ve öncelikli kalite gereksinimidir.<системы>.

güvenilirlik yazılım, hata toleransı, kullanım güvenliği (güvenlik - insan sağlığı, iş, mülk vb. için kabul edilebilir bir risk bağlamında güvenlik), bilgi güvenliği veya güvenliği (güvenlik - bilgilerin yetkisiz işlemlerden korunması, aşağıdakiler dahil) gibi özellikleri içerir. okuma erişiminin yanı sıra, bilgilerin yetkili kullanıcılara, kendileri için belirlenen haklar kapsamında erişilebilirliğini garanti etmenin yanı sıra, kolaylık ve kullanım kolaylığı (kullanılabilirlik). Güvenilirlik aynı zamanda güvenilirlik açısından da tanımlanabilen bir kriterdir.

Gelişmiş güvenilirlik sistemlerine ilişkin kapsamlı literatür, bu konunun tartışılmasında önemli bir rol oynamaktadır. Aynı zamanda, geleneksel mekanik ve elektrik sistemleri (yazılım içermeyenler dahil) alanından gelen ve tehlike, risk, sistem bütünlüğü vb. kavramlarını tanımlayan terminoloji kullanılır.

Yazılımın bütünlük seviyeleri

Yazılım Bütünlük Düzeyi bir yazılım arızasının olası sonuçlarına ve böyle bir arızanın meydana gelme olasılığına göre belirlenir. Güvenliğin farklı yönleri (kullanım ve bilgi güvenliği) önemli olduğunda, tehlike analizi teknikleri (kullanım güvenliği, emniyet bağlamında) ve tehdit analizi teknikleri (bilgi güvenliği, güvenlikte) iş planlarının geliştirilmesinde kullanılabilir. olası kaza kaynaklarını belirleme alanı. Benzer sistemlerin arıza geçmişi, en faydalı arıza tespit tekniklerinin belirlenmesine de yardımcı olabilir.<всесторонней>yazılım kalite değerlendirmeleri.

Belirli projeler bağlamında yazılım bütünlüğünün daha ayrıntılı bir değerlendirmesinde, sadece SQM süreçlerine (özellikle denetim ve belgelendirme dahil resmi süreçlere) değil, (uygun kaynakları tahsis ederek ve gerekli çalışmaları yaparak) özel dikkat göstermek gerekir. aynı zamanda gereksinim yönetimi (kriter bütünlüğü açısından), risk yönetimi (hem geliştirme aşamasında hem de işletim ve bakım aşamasında risk planlaması dahil), tasarım (güvenilirliği artırmak için) , zorunlu olarak, genellikle pilot projeler, gösteri stantları vb. oluşturulması yoluyla, kullanım için planlanan mimari ve teknolojik çözümlerin derin bir analizini ve doğrulanmasını ve test edilmesini (emülasyonu da dahil olmak üzere sistemin davranışsal özellikleri hakkında kapsamlı bir çalışma sağlamak için) içerir. işletim sırasında sistemin kullanılması gereken çalışma ortamı / konfigürasyon).

Kusur Karakterizasyonu

SQM süreçleri kusur tespiti sağlar. Kusur özelliklerinin tanımlanması, ürünün anlaşılmasında önemli bir rol oynar, süreci veya ürün düzeltmesini kolaylaştırır ve proje yöneticilerini ve müşterileri süreç veya ürünün durumu (durumu) hakkında bilgilendirir. Kusurların (arızaların) birçok taksonomisi (sınıflandırmaları ve yapılandırma yöntemleri) vardır. Kusurların (anormallikler) karakterizasyonu, değerlendirme lideri genellikle uygun toplantılarda tartışmak üzere değerlendirme ekibinin üyeleri tarafından oluşturulan bir anormallik listesi sunduğunda, denetimlerde ve değerlendirmelerde de kullanılır.

Evrimin (ve yeni ortaya çıkışının) arka planına karşı, yeni yazılım teknolojileriyle birlikte tasarım yöntemleri ve dilleri, yeni kusur sınıfları ortaya çıkıyor. Bu, önceden tanımlanmış kusur (arıza) sınıflarını yorumlamak (ve düzeltmek) için büyük bir çaba gerektirir. Kusurları takip ederken, mühendis sadece sayılarıyla değil aynı zamanda türleriyle de ilgilenir. Kusurların türe göre dağılımı, kullanılan teknolojiler ve mimari çözümler açısından sistemin en zayıf unsurlarını belirlemek için özellikle önemlidir, bu da derinlemesine çalışma ihtiyacına yol açar, özel pilot projelerin oluşturulması, ek kavram kanıtı (POC), yeni teknolojileri kullanırken sık kullanılan bir yaklaşımdır), üçüncü taraf uzmanların katılımı vb. Sınıflandırma olmaksızın kendi başına bilgi, sorunların çözümlerini belirlemek için bunları uygun türler halinde gruplandırmak gerektiğinden, hataların nedenlerini keşfetmek için genellikle işe yaramaz. Soru, mühendisler ve bir bütün olarak organizasyon için anlamlı olacak bir kusur sınıflandırması tanımlamaktır.

SQM, yazılım geliştirme ve bakımının tüm aşamalarında bilgi toplanmasını sağlar. Genellikle “kusur” dediğimizde aşağıda tanımlandığı gibi “arıza”yı kastediyoruz. Ancak, farklı kültürler ve standartlar bu terimler için farklı anlamlara sahip olabilir.

Bu tür kavramların kısmi tanımları aşağıdaki gibidir:

• Hata(hata):"Doğru sonuç ile hesaplanmış sonuç arasındaki fark...<полученным с использованием программного обеспечения>”
• Arıza:“Bir bilgisayar programında yanlış adım, süreç veya veri tanımı”
• Başarısızlık (başarısızlık): “<Некорректный>eksikliği sonucunda elde edilen sonuç”
• İnsan/kullanıcı hatası (hata):“Yanlış bir sonuca yol açan insan eylemi”

Bu konuyu tartışırken, bir kusur, bir yazılım hatasının sonucunu ifade eder. Güvenilirlik modelleri, yazılımın testi veya kullanımı sırasında toplanan arıza verileri temelinde oluşturulur. Bu tür modeller, gelecekteki arızaları tahmin etmek ve testi durdurma kararına yardımcı olmak için kullanılabilir.

Kusurları tespit etmeye yönelik SQM çalışmasının sonuçlarına dayanarak, incelenen üründeki kusurları gidermek için önlemler alınır. Ancak konu bununla sınırlı değil. İlgili SQM çalışmasının sonuçlarından tam olarak yararlanmak için başka olası eylemler de vardır. Bunlar arasında - analiz ve özetleme (özetleme)<по обнаруженным несоответствиям/дефектам>, ürün ve süreci iyileştirmek, kusurları takip etmek ve sistemden çıkarmak için (gerekli düzeltici eylemlerin uygulanması üzerinde yönetimsel ve teknik kontrol ile) nicelleştirme tekniklerinin (metriklerin elde edilmesi) kullanılması. Buna karşılık, özellikle süreç iyileştirme için bilgi kaynağı, SQM sürecidir.

İlgili SQM tekniklerinin uygulanması sırasında bulunan tutarsızlıklar ve kusurlar hakkındaki veriler, kayıplarını önlemek için kaydedilmelidir. Bazı teknikler için (örneğin, teknik değerlendirme, denetim, teftişler), bu tür bilgilerin, konular (ilave değerlendirme gerektirenler dahil) ve alınan kararlar ile birlikte tam olarak kaydedilmesi için bir kayıt memurunun (kaydedici) bulunması zorunludur. Uygun otomasyon araçlarının kullanıldığı durumlarda, kusurlar hakkında gerekli çıktı bilgilerini de sağlayabilirler (örneğin, kusur durumlarına ilişkin özet istatistikler, sorumlu uygulayıcılar vb.). Hata verileri, değişiklik talepleri (SCR, yazılım değişikliği talebi) şeklinde toplanabilir ve kaydedilebilir ve daha sonra belirli veritabanlarına girilebilir (örneğin, daha fazla analiz ve süreç iyileştirme için projeler arası / geçmiş istatistikleri izlemek amacıyla) ), hem manuel hem de otomatik olarak uygun analiz araçlarından (bir dizi modern tasarım aracı ve özel araç, ürün ve süreçlerin kalitesini sağlamak için önemli olan uygun ölçümleri kullanarak kod ve modelleri analiz etmenize olanak tanır). Hata raporları organizasyon/organizasyon birimi veya yapının yönetim kademesine gönderilir (proje, ürün, süreç, personel, bütçe vb. ile ilgili uygun kararların alınması için).

Yazılım Kalite Yönetim Teknikleri

SQM teknikleri birkaç kategoriye ayrılabilir:

• statik
• insan kaynaklarının yoğun kullanımını gerektiren teknikler
• analitik
• dinamik

Statik teknikler

Statik teknikler şunları içerir:<детальное>proje belgelerinin, yazılımın ve yazılım ürünüyle ilgili diğer bilgilerin yürütülmeden incelenmesi (incelenmesi). Bu teknikler, otomasyonun ne ölçüde kullanıldığına bakılmaksızın, aşağıda tartışılan diğer "toplu" değerlendirme veya "bireysel" inceleme faaliyetlerini içerebilir.

İnsan yoğun teknikler

Değerlendirme ve denetleme de dahil olmak üzere bu tür bir tekniğin biçimi, resmi toplantılardan gayri resmi toplantılara veya ürünün koduna atıfta bulunmadan ürünle ilgili tartışmalara kadar değişebilir. Tipik olarak, bu tür bir teknik, en az iki ve çoğu durumda birden fazla uzmanın yüz yüze etkileşimini içerir. Aynı zamanda, bu tür toplantılar ön hazırlık gerektirebilir (neredeyse her zaman toplantıların içeriğinin tanımı, yani tartışılacak konuların listesi ile ilgili). Bu tür tekniklerde kullanılan kaynaklar, incelenen eserler (ürün, dokümantasyon, modeller, vb.) ile birlikte çeşitli kontrol listelerini ve analitik tekniklerin sonuçlarını (aşağıda tartışılmıştır) ve test çalışmasını içerebilir. Bu teknikler örneğin 12207 standardında değerlendirme (inceleme) ve denetim (denetim) tartışılırken tartışılmaktadır.

Analitik teknikler

Yazılım mühendisleri genellikle analitik teknikler kullanır. Çevik yöntemler ve yaklaşımlar açısından, bireyler ve etkileşimler<непосредственное>ekip üyelerinin iletişimi ve sürekli etkileşimi.

Bazen birkaç mühendis aynı tekniği ancak ürünün farklı bölümlerinde kullanır. Bazı teknikler, kullanılan araçların özelliklerine dayanırken, diğerleri “manuel” çalışmayı içerir. Birçoğu kusurları doğrudan bulmaya yardımcı olabilir, ancak çoğu zaman diğer teknikleri desteklemek için kullanılırlar. Bir dizi teknik, genel kalite analizinin ayrılmaz bir unsuru olarak çeşitli uzmanlık türlerini (değerlendirme) de içerir. Bu tür tekniklerin örnekleri, karmaşıklık analizi, kontrol akışı analizi (veya kontrol akışı analizi) ve algoritmik analizdir.

Her analiz türünün belirli bir amacı vardır ve tüm türler her projeye uygulanamaz. Destek tekniğine bir örnek, bir sistem tasarımının doğru bir şekilde uygulanamayacak, test edilemeyecek veya sürdürülemeyecek kadar karmaşık olan kısımlarını belirlemek için yararlı olan karmaşıklık analizidir. Karmaşıklık analizinin sonucu, test senaryoları (test senaryoları) geliştirmek için de kullanılabilir. Kontrol mantığı analizi gibi arıza bulma teknikleri başka durumlarda da kullanılabilir. Kapsamlı algoritmik mantığa sahip yazılımlar için, özellikle yanlış bir algoritmanın (uygulaması değil, mantığın, yazarın notu) feci sonuçlara yol açabileceği durumlarda (örneğin, güvenlik için aviyonik yazılım) algoritmik tekniklerin uygulanması son derece önemlidir. kullanım sorunları – güvenlik belirleyici bir rol oynar).

Diğer, daha resmi analitik teknik türleri, resmi yöntemler olarak bilinir. Gereksinimleri ve tasarımı kontrol etmek için kullanılırlar (kuşkusuz, sadece ara sıra, günümüzün gerçek endüstriyel yazılım geliştirme uygulamasında). Doğrulama, kritik yazılım parçalarına uygulanır (genel olarak konuşursak, resmi yöntemlerle çok az ilgisi vardır - bu, maliyetleri en aza indirirken kabul edilebilir kaliteye ulaşmanın doğal bir yoludur). Çoğu zaman, belirli gereksinimler gibi kritik görev sistemlerinin kritik parçalarını doğrulamak için kullanılırlar.<информационной>güvenlik ve güvenilirlik.

dinamik teknikler

Yazılım geliştirme ve sürdürme sürecinde, çeşitli dinamik tekniklere yönelmek gerekir. Temel olarak, bunlar test teknikleridir. Bununla birlikte, simülasyon, model kontrolü ve sembolik yürütme teknikleri dinamik teknikler olarak kabul edilebilir (sembolik yürütme, genellikle, davranışın genel senaryosu düşünüldüğünde öykünülmüş girdi ve çıktıyla birlikte yürütülen mantık açısından "kukla" modüllerin kullanımını içerir). çok modüllü sistemler; bazen bu terim seçilen kaynağa bağlı olarak diğer teknikleri ifade eder).

Kodun görüntülenmesi (okunması) genellikle statik bir teknik olarak düşünülür, ancak deneyimli bir mühendis kodu doğrudan okuma "sürecinde" çalıştırabilir (örneğin, başka birinin kodunu tanımak veya değerlendirmek için etkileşimli adım adım hata ayıklama araçlarını kullanarak) ). Bu nedenle, bu teknik dinamik olarak tartışılabilir. Tekniklerin sınıflandırılmasındaki bu tür farklılıklar, bir kişinin bir organizasyondaki rolüne bağlı olarak, aynı teknikleri farklı şekillerde benimseyebileceğini ve uygulayabileceğini açıkça göstermektedir.

Organizasyona bağlı olarak<ведения>proje, SQA ve V&V süreçlerinde yazılım sistemlerinin geliştirilmesi sırasında belirli test faaliyetleri gerçekleştirilebilir. SQM planı test sorunlarını ele aldığından, bu konu testle ilgili bazı yorumları içerir.

Test yapmak

Doğrulama süreçleri<качества> SQA ve V&V'de açıklanan<планах>, aşağıdakiler için yazılım gereksinimleri spesifikasyonu ile ilişkili herhangi bir çıktıyı (ara ve nihai dahil) inceleyin ve değerlendirin:

• izlenebilirlik,
• tutarlılık (tutarlılık),
• tamlık / eksiksizlik (tamlık),
• doğruluk
• ve doğrudan yürütme<требований>(verim).

Bu doğrulama ayrıca geliştirme ve bakım süreçlerinden, sonuçların toplanmasından, analizinden ve nicelleştirilmesinden elde edilen çıktı ürünlerini de kapsar. SQA faaliyetleri, uygun (belirli bir proje bağlamında ihtiyaç duyulan) test türlerinin planlanmasını, geliştirilmesini ve uygulanmasını ve V&V - test planlarının, stratejilerin, senaryoların ve prosedürlerin geliştirilmesini sağlar.<тестирования>.
Test konuları, Test bilgisi alanında ayrıntılı olarak tartışılmaktadır. Projede kullanılan verilerin kalitesinden sorumlu oldukları için SQA ve V&V tarafından belirlenen hedefleri iki tür test takip eder:

• Projede kullanılan araçların değerlendirilmesi ve test edilmesi
• Oluşturulan üründe kullanım için bileşenlerin ve COTS ürünlerinin (COTS - rafta satılan ticari, kullanıma hazır ürün) uygunluk testi (veya uygunluk testlerinin değerlendirilmesi).

Zaman zaman, bağımsız V&V kuruluşları, test sürecini izleme ve belirli durumlarda gerçek performansı belgeleme (veya daha yaygın olarak belgeleme/kaydetme) becerisine ihtiyaç duyabilir.<тестов>belirlenmiş prosedürlere uygun olarak gerçekleştirilmelidir. Öte yandan, testin kendisini değerlendirmek için V&V'ye başvurulabilir: planların ve prosedürlerin yeterliliği, sonuçların uygunluğu ve doğruluğu.

Bir V&V organizasyonunun gözetimi altında yürütülen başka bir test türü, üçüncü taraf testleridir. Bu tür üçüncü taraf, ürünün geliştiricisi değildir ve ürünün geliştiricisi ile hiçbir şekilde ilişkili değildir. Ayrıca, üçüncü taraf, genellikle uygun yetkiye sahip olarak akredite edilmiş bağımsız bir değerlendirme kaynağıdır (örneğin, uygunluğu bağımsız bir uzman tarafından değerlendirilen ve eylemleri standart yaratıcısı tarafından onaylanan belirli bir standardın geliştirme organizasyonu) . Bu tür testlerin amacı, ürünün belirli bir dizi gereksinime (örneğin bilgi güvenliği) uygunluğunu kontrol etmektir.

Yazılım Kalite Ölçümü

Yazılım ürünü kalite modelleri genellikle, üründe bulunan her bir kalite özelliğinin düzeyini belirlemek için ölçümler içerir.

Kalite özellikleri doğru seçilirse bu tür ölçümler kaliteyi (kalite seviyesini) birçok yönden destekleyebilir. Metrikler, karar verme sürecini yönlendirmeye yardımcı olabilir. Metrikler, süreçlerdeki sorunlu alanları ve darboğazları belirlemeye yardımcı olabilir. Metrikler, mühendislerin çalışmalarının kalitesini değerlendirmeleri için bir araçtır - hem SQA tarafından tanımlanan amaçlar için hem de daha uzun vadeli bir iyileştirme süreci açısından.<достигаемого>kalite.
Dahili karmaşıklığın artması, yazılımın karmaşıklığı, kalite soruları, yazılımın çalışıp çalışmadığı gerçeğinin çok ötesine geçer. Soru, nicelleştirilmiş kalite hedeflerine ne kadar iyi ulaşıldığıdır.

SQM'yi doğrudan destekleyen metrikler olan birkaç başka konu daha vardır. Testin ne zaman durdurulacağına karar vermede yardım içerirler. Bu bağlamda güvenilirlik modelleri ve örneklerle karşılaştırma (belirli bir kaliteye örnek olarak kabul edilen standartlar - kıyaslamalar) faydalı görünmektedir.

SQM sürecinin maliyeti aşağıdakilerden biridir:<проблемных>Projenin (proje çalışmasının) nasıl organize edileceğine karar verme sürecinde her zaman ortaya çıkan sorular. Genellikle, bir kusurun tam olarak ne zaman keşfedildiğini ve kusurun yaşam döngüsünde daha önce bulunmuş olması durumundaki duruma kıyasla onu düzeltmek için ne kadar çaba gerektiğinin belirlenmesine dayanan genel maliyet modelleri kullanılır. Tasarım verileri, maliyetin daha net bir resmini sağlamaya yardımcı olabilir.

Son olarak, SQM raporlamasının kendisi, yalnızca süreçlerin kendileri (yani mevcut durumları, yazarın notu) hakkında değil, aynı zamanda tüm yaşam döngüsü süreçlerinin nasıl iyileştirilebileceği hakkında da yararlı bilgilere sahiptir.

Her ne kadar nicel değerlendirmeler olarak (bu durumda, ölçüm süreci hakkında değil, değerlendirmelerin sonuçlarından bahsediyoruz) kalite özelliklerinin kendi başlarına yararlı olabilmesine rağmen (örneğin, karşılanmayan gereksinimlerin sayısı ve bu gereksinimlerin oranı) , yapabilirler<эффективно>Metrik değerlerin yorumlanmasını kolaylaştıran matematiksel ve grafiksel teknikleri uygular. Bu tür teknikler, örneğin aşağıdaki gibi oldukça doğal olarak sınıflandırılır:

• İstatistiksel yöntemlere dayalı (örneğin, Pareto analizi, normal dağılım vb.)
• İstatistiksel Testler
• Moda analizi
• Tahmin (ör. güvenilirlik modelleri)

İstatistiksel teknikler ve istatistiksel testler, genellikle incelenen yazılım ürününün en sorunlu alanlarının bir "anlık görüntüsünü" sağlar (ve bu arada, aynı şey genellikle süreçler için de geçerlidir). Ortaya çıkan grafikler ve çizelgeler, karar vericilere kaynakların odaklanması gereken alanları belirlemede görsel olarak yardımcı olur.<проекта>. Trend analizinin sonuçları, örneğin test sırasında programın ihlal edildiğini gösterebilir; ya da geliştirme sürecinde düzeltici önlem alınana kadar belirli sınıfların arızalarının giderek daha sık hale gelmesi. Tahmin teknikleri, test sürelerinin planlanmasında ve arızaların tahmin edilmesinde yardımcı olur.

Yazılım Kalite Özellikleri

Hareketlilik— Yazılımın bir ortamdan diğerine taşınma yeteneği ile ilgili bir dizi özellik.
NOT Ortam, organizasyonel, teknik veya yazılım ortamlarını içerebilir.

Güvenilirlik— Yazılımın belirli bir süre boyunca belirli koşullar altında performans düzeyini koruma yeteneğiyle ilgili bir dizi özellik.

Notlar:

1. Yazılımın amortismanı veya eskimesi yoktur. Güvenilirlik sınırlamaları gereksinimler, tasarım ve uygulamadaki hatalardan kaynaklanır. Bu hatalardan kaynaklanan arızalar, yazılımın nasıl kullanıldığına ve önceden seçilen yazılım sürümlerine bağlıdır.
2. ISO 8402'nin tanımında "güvenilirlik", "bir elemanın gerekli bir işlevi yerine getirme yeteneği"dir. Bu Uluslararası Standartta yetenek, yazılım kalitesinin özelliklerinden yalnızca biridir. Bu nedenle güvenilirlik tanımı, "gerekli işlevi yerine getirmek" yerine "performans düzeyini korumak" şeklinde genişletilmiştir.

Pratiklik (Kullanılabilirlik)- Kullanım için gerekli olan işin kapsamı ve bu tür bir kullanımın belirli veya amaçlanan bir kullanıcı grubu tarafından bireysel olarak değerlendirilmesi ile ilgili bir dizi nitelik.

Notlar:

1. "Kullanıcılar", etkileşimli yazılımın doğrudan kullanıcılarının çoğunluğu olarak yorumlanabilir. Kullanıcılar, yazılımın kullanımından etkilenen veya yazılımın kullanımına bağlı olan operatörleri, son kullanıcıları ve dolaylı kullanıcıları içerebilir. Kullanılabilirlik, kullanıma hazırlık ve sonuçların değerlendirilmesi de dahil olmak üzere, yazılımı etkileyebilecek tüm kullanıcı çalışma koşullarında dikkate alınmalıdır.
2. Bu Uluslararası Standartta belirli bir yazılım ürünü öznitelikleri seti olarak tanımlanan kullanılabilirlik, verimlilik ve verimsizlik gibi diğer özelliklerin kullanılabilirliğin bileşenleri olarak kabul edildiği ergonomi açısından tanımdan farklıdır.

sürdürülebilirlik— Belirli değişiklikleri (değişiklikleri) gerçekleştirmek için gereken işin kapsamı ile ilgili bir dizi nitelik.
NOT Değişiklik, yazılımın çevredeki, gereksinimlerdeki ve çalışma koşullarındaki değişikliklere yönelik düzeltmeleri, geliştirmeleri veya uyarlamalarını içerebilir.

işlevsellik— Bir dizi işlevin özü ve bunların belirli özellikleriyle ilgili bir dizi nitelik. İşlevler, belirtilen veya ima edilen ihtiyaçları karşılayan işlevlerdir.

Notlar:

1. Bu öznitelikler kümesi, yazılımın ihtiyaçları karşılamak için ne yaptığını karakterize ederken, diğer kümeler esas olarak ne zaman ve nasıl yapıldığını tanımlar.
2. Bu özellikte, belirlenen ve beklenen ihtiyaçlar için kalite tanımına ilişkin bir not dikkate alınır.

Yeterlik— Yazılım performans düzeyi ile belirli koşullar altında kullanılan kaynak miktarı arasındaki ilişkiyle ilgili bir dizi nitelik.
NOT Kaynaklar, diğer yazılım ürünlerini, donanımları, malzemeleri (örneğin baskı kağıdı, disketler) ve operatörlerin, bakımcıların veya bakım personelinin hizmetlerini içerebilir.

Yazılım ürün kalitesi

Yazılım ürününün kalitesi (yazılım kalitesi)- bir yazılım ürününün belirtilen veya ima edilen ihtiyaçları karşılama yeteneği ile ilgili tüm özellik ve karakteristikleri kapsamı.

Her kalite özelliğinin önemi yazılım sınıfına göre değişir. Örneğin, güvenilirlik, kritik sistem yazılımlarıyla mücadele için en önemli, zaman açısından kritik gerçek zamanlı sistem yazılımları için verimlilik ve son kullanıcı diyalog yazılımı için kullanılabilirlik en önemli şeydir.

Her bir kalite özelliğinin önemi de benimsenen bakış açılarına göre değişmektedir.

Kullanıcı Görünümü

Kullanıcılar esas olarak yazılımın uygulanması, performansı ve kullanım sonuçları ile ilgilenirler. Kullanıcılar yazılımı, içindekileri veya yazılımın nasıl oluşturulduğunu öğrenmeden değerlendirir.

Kullanıcı aşağıdaki sorularla ilgilenebilir:

• Gerekli fonksiyonlar yazılımda mevcut mu?
• Yazılım ne kadar güvenilir?
• Yazılım ne kadar etkili?
• Yazılım kullanıcı dostu mu?
• Yazılım ve diğer ortamları taşımak ne kadar kolay?

Geliştirici Görünümü

Oluşturma süreci, kullanıcı ve geliştiricinin, gereksinimleri ve kabulü oluşturmak için kullandıklarıyla aynı yazılım kalite özelliklerini kullanmasını gerektirir. Yazılım satış için geliştirildiğinde, kalite gereksinimleri beklenen ihtiyaçları yansıtmalıdır.

Geliştiriciler, kalite gereksinimlerini karşılaması gereken yazılımları oluşturmaktan sorumlu olduklarından, nihai ürünün kalitesi kadar ara ürünlerin kalitesiyle de ilgilenirler. Geliştirme döngüsünün her aşamasında ara ürünlerin kalitesini değerlendirmek için geliştiriciler, aynı özellikler için farklı ölçümler kullanmalıdır, çünkü aynı ölçümler yaşam döngüsünün tüm aşamaları için geçerli değildir.

Örneğin, kullanıcı verimliliği yanıt süresi açısından anlar, geliştirici ise tasarım belirtimini rota uzunluğu, gecikme ve erişim açısından kullanır. Bir ürünün dış arayüzüne uygulanan metrikler, ürünün yapısına uygulanan metriklerle değiştirilebilir.

Yönetici tanıtımı

Yönetici, belirli bir kalite özelliğinden çok genel kaliteyle ilgilenebilir ve bu nedenle ticari gereksinimleri yansıtan değerlerin bireysel özellikler için önemini belirlemesi gerekecektir.
Yönetici, kaliteyi sınırlı bir maliyet, insan gücü ve zaman sınırı içinde optimize etmek istediklerinden, planlı gecikme veya maliyet aşımları gibi kontrol edilebilirlik kriterlerine karşı kalite iyileştirmeyi karşılaştırma ihtiyacı duyabilir.

Yazılım ürünü kalite değerlendirmesi

Aşağıdaki şekil, yazılım kalitesini değerlendirmek için gereken ana adımları göstermektedir.

Şekil "Değerlendirme sürecinin modeli"

Değerlendirme süreci üç aşamadan oluşur: kalite gereksinimlerinin oluşturulması (tanımı), değerlendirmeye hazırlık ve değerlendirme prosedürü. Bu süreç, her bir yazılım ürünü bileşeni için herhangi bir uygun yaşam döngüsü aşamasında uygulanabilir.
İlk aşamanın amacı, kalite özellikleri açısından gereksinimleri belirlemektir. Gereksinimler, söz konusu yazılım ürünü için dış ortamın ihtiyaçlarını ifade eder ve geliştirme başlamadan önce belirlenmelidir.
İkinci aşamanın amacı, değerlendirme için temel hazırlamaktır.
Üçüncünün sonucu, yazılım ürünlerinin kalitesi hakkında bir sonuçtur. Genel kalite daha sonra zaman ve maliyet gibi diğer faktörlerle karşılaştırılır. Yönetimin nihai kararı, kontrol edilebilirlik kriteri temelinde verilir. Sonuç, yönetimin yazılım ürününü kabul etme veya reddetme veya serbest bırakma veya serbest bırakmama kararıdır.

Proses kalite modeli

Geliştirme süreci, ürünün kalitesinin ölçülebilmesini sağlayacak şekilde yapılandırılmalıdır. Yapılan çalışmalar, geliştirme sürecinin kalitesi ne kadar yüksekse, bu süreçte geliştirilen yazılımların kalitesinin de o kadar yüksek olduğunu göstermektedir. Projenin her aşamasında kalite, öncelikle sürecin olgunlaşmasının doğrudan bir sonucu olarak ve ikinci olarak, bir önceki aşamada üretilen daha kaliteli bir ara ürünün kullanılması nedeniyle artar. Aynı zamanda, olgun süreçler için yaşam döngüsü sürecinde kalitenin büyümesini sağlamak için ikinci nedenin öneminin çok daha önemli olduğu vurgulanmaktadır. Bütün bunlar bir model şeklinde temsil edilebilir.

Şekil "Geliştirme sürecinin kalitesinin kavramsal modeli"

Bundan aşağıdaki sonuçları takip edin:
Birincisi, karmaşık üretimde kalite bir üründe kümülatif bir şekilde birikir, bu sayede erken aşamalarda yapılan kaliteye yapılan katkı, nihai ürün üzerinde sonraki aşamalara göre daha güçlü bir etkiye sahiptir. Bu, tüm programlama uygulamaları tarafından onaylanır, örneğin, sistem tasarım kusurlarının yüksek kodlama kalitesi ile telafi edilemeyeceği bilinmektedir.
Bu nedenle, karmaşık bir sistem inşa etme kalitesini yönetmek için, kullanılan geliştirme süreçlerinin olgunluk derecesini ve şeffaflığını ölçerek üreticilerin seçilmesi gerekir. Yüklenicinin geliştirme sürecinin kalitesini ölçmek, genel kalite yönetiminin önemli bir parçasıdır ve kabul testi sırasında üretilen nihai ürünün kalitesini ölçmekten daha önemlidir.
İkincisi, kalite testi ve ölçümü, yaşam döngüsünün tüm aşamalarında yapılmalıdır. Erken bir aşamada oluşturulmuş kaliteli verilerin çıkarılması, tam sonuçlar mevcut değilse çok pahalı olabilir.

Kalite özelliklerinin uygulanmasına ilişkin kılavuz

1 Uygulanabilirlik

2 Yazılım kalitesi kavramları

2.1 Kullanıcı tanıtımı
2.2 Geliştirici görünümü
2.3 Liderin sunumu

3.1 Kalite gereksinimlerinin belirlenmesi

3.2 Değerlendirme için hazırlık

3.2.1 Kalite ölçütlerinin seçimi (göstergeler)
3.2.2 Sıralama seviyelerinin tanımlanması
3.2.3 Değerlendirme kriterlerinin belirlenmesi

3.3 Derecelendirme prosedürü

3.3.1 Ölçüm
3.3.2 Sıralama
3.3.3 Değerlendirme

1. Giriş

2 Kapsamlı kalite göstergelerinin tanımı

2.1 İşlevsellik

2.1.1 Uygunluk
2.1.2 Doğruluk
2.1.3 Birlikte çalışabilirlik
2.1.4 Uyumluluk
2.1.5 Güvenlik

2.2 Güvenilirlik

2.2.1 Stabilite (Vade)
2.2.2 Hata toleransı
2.2.3 Kurtarılabilirlik

2.3 Kullanılabilirlik

2.3.1 Anlaşılabilirlik
2.3.2 Öğrenilebilirlik
2.3.3 Kullanım kolaylığı (Çalışabilirlik)

2.4 Verimlilik

2.4.1 Zaman davranışı
2.4.2 Kaynak davranışı

2.5 Sürdürülebilirlik

2.5.1 Analiz edilebilirlik
2.5.2 Değiştirilebilirlik
2.5.3 Kararlılık
2.5.4 Test edilebilirlik

2.6 Taşınabilirlik

2.6.1 Uyarlanabilirlik
2.6.2 Uygulama kolaylığı (Kurulabilirlik)
2.6.3 Uygunluk
2.6.4 Değiştirilebilirlik

Notlar:

1. Birlikte çalışabilirlikle olası bir karışıklığı önlemek için uyumluluk yerine değiştirilebilirlik kullanılır.
2. Belirli bir yazılım aracıyla değiştirilebilirlik, aracın söz konusu yazılım aracıyla değiştirilebilir olduğu anlamına gelmez.
3. Değiştirilebilirlik, uygulama kolaylığı ve uyarlanabilirlik özelliklerini içerebilir. Kavram, öneminden dolayı ayrı bir alt karakter olarak tanıtıldı.

proje kalitesi

Kalite, projenin üstlenildiği hedefleri karşılamasını sağlayan tüm proje faaliyetlerini içerir. Bu nedenle kalite yönetimi hem projeye hem de projenin ürününe uygulanabilir.
Kalite kritik öneme sahiptir, çünkü hedefleri dile getirir ve sabitler, onları belgelendirir (resmi hale getirir).
Bu nedenle kalite, proje yapısı yönetiminin kritik bir bileşenidir.
Kalite için her şey ölçülebilir.

Proje Kalite Yönetimi

Kalite yönetimi organizasyonun bir bölümünde yoğunlaşırsa, evrensel hale gelmez. Proje yöneticisi, kalite yönetiminin yönlerini devredebilir. Proje yöneticisi nihai sorumluluğu elinde tutar.

Kalite ilkeleri (ISO 9001)

1. Tüketici Odaklılık
2. Yönetim sorumluluğu
3. İnsanların Katılımı
4. süreç yaklaşımı
5. Yönetime sistem yaklaşımı
6. Sürekli gelişme
7. Gerçeklere dayalı karar verme
8. Tedarikçilerle karşılıklı yarar sağlayan ilişkiler

Şekil "ISO 9000 ve PMBoK'da kalite yönetimi anlayışındaki farklılıklar"

Proje Kalite Yönetimi (PMI): Alt Süreçler

• Kalite planlaması
• Kalite güvencesi
• Kalite kontrol

Kalite planlaması

Aşamalardan biri, belirli bir projeye hangi mevcut standartların uygulanacağını ve bunlara nasıl uyulacağını belirlemektir. Kalite planlamasının çıktısı, projeye uygulanabilir tüm kalite standartlarının bir listesidir. Ekte, bu standartların gerekliliklerinin nasıl karşılanacağına dair bir tavsiye listesi bulunmaktadır.

Kalite Planlama Süreci: Girdiler

• Kalite politikası. Bir kuruluşun kaliteyi nasıl tanımladığına ilişkin ilkeleri içeren ancak kaliteye nasıl ulaşılacağını içermeyen bir belge.
• Proje içeriği (kapsam). Proje sonucunda nelerin yapılması gerektiğini ve dolayısıyla kalite yönetim süreçlerinde nelerin izlenmesi gerektiğini tanımlar. Bu belge, proje kapsam planlama sürecinin çıktısıdır.
• Ürün Açıklaması. Kalite planlamasını etkileyebilecek teknik ayrıntıları ve diğer önemli hususları içerir.
• Standartlar ve düzenlemeler. Belirli bir alan veya projeyle ilgili standartların ve düzenlemelerin listesi.
• Diğer Belgeler.

Kalite planlama süreci: araçlar ve teknolojiler

• Fayda/maliyet analizi. Kalite maliyeti tartışmasıyla ilgili. Bu aracın amacı, kalite eksikliğinin gerçek maliyetini kalite güvencesinin faydalarıyla karşılaştırmaktır.
• Karşılaştırmak. Diğer projelerle karşılaştırma yoluyla iyileştirme fikirleri üretmek için kullanılır. Karşılaştırma sadece diğer dahili projelerle değil, en iyilerle yapıldığında en etkilidir.
• Diyagramlar. Farklı öğelerin nasıl etkileşime girdiğini göstermek için kullanılır. Sebep ve sonuç diyagramı da dahil olmak üzere birçok diyagram türü vardır.
• Denemeler kurma. Bir projenin nihai sonucu üzerinde hangi değişkenlerin en fazla etkiye sahip olduğunu belirlemek için durum senaryolarını kullanın.
• Kalitenin maliyeti.

Kalite planlama süreci: çıktılar, sonuçlar

• Kalite yönetim planı. Proje yönetim ekibinin kalite politikasını nasıl uygulayacağını açıklar. Aşağıdaki alanları kapsamalıdır:
• Tasarım kontrolü.
• Belge kontrolü.
• Malzeme alımının kontrolü.
• Denetimler.
• Test kontrolü (test).
• Kontrol ve ölçüm ekipmanı üzerinde kontrol.
• Düzeltici eylem.
• Kalite kayıtları.
• Denetimler (plan ve prosedür)
• Belgelenmiş prosedürler ve çalışma talimatları. Süreçleri ve sürecin, alt sürecin ve gerçekleştirilen bireysel faaliyetlerin kalitesinin nasıl ölçüleceğini ayrıntılı olarak tanımlayın.
• Kontrol sayfaları. Hiçbir şeyin atlanmadığını kontrol etmek için soru listeleri.

Kalite güvencesi

Kalite Güvence Süreci- bu, projenin (ürün, hizmet) kalite gereksinimlerini karşılaması için gerekli öngörülen tüm süreçlerin uygulanmasını sağlamak için planlı sistematik önlemlerin benimsenmesidir.
Kalite güvencesi, kalite yönetiminin ana alt sürecidir. Bu aktivite proje boyunca gerçekleştirilir.

Kalite Güvence Süreci: Girdiler

• Çalışma talimatları. Kalite planlama sürecinin bir diğer çıktısı.
• Kalite kontrol ölçümlerinin sonuçları. Kalite kontrol sürecinin çıktısı.

Kalite Güvence Süreci: Araçlar ve Teknikler

Kalite planlama araçları ve teknikleri. Bunlara maliyet ve fayda analizi, karşılaştırmalar, çizelgeler, deneyler ve kalite maliyetlendirmesi dahildir.

Kalite denetimleri

"Öğrenilen dersleri" doğrulayan yapılandırılmış "incelemeler". Kalite denetimi türleri şunlardır:

• iç dış,
• sistem / ürün / süreçler / organizasyon,
• planlı / düzenli,
• özel ve sofistike.

Kalite Güvence Süreci: Çıktılar

Kalite iyileştirme. Proje sahiplerine ek faydalar sağlamak için projenin etkinliğini ve verimliliğini artıracak eylemlerde bulunmayı içerir.

Kalite kontrol

izleme Kabul edilen kalite standartlarına uygunluklarını belirlemek ve yetersiz performansın nedenlerini ortadan kaldırmanın yollarını belirlemek için belirli sonuçlar.

Kalite Kontrol Süreci: Girdiler

• Çalışma sonuçları. Sonuçlar her zaman projenin işbirliği, yürütülmesi ve yeniden planlanması sürecinde ortaya çıkar.
• Kalite yönetim planı. Kalite planlama sürecinin çıktısı.
• Çalışma talimatları. Kalite planlama sürecinin çıktısı.
• Kontrol listeleri.

Kalite kontrol: araçlar ve teknikler

• Denetimler. Sonucun gereksinimleri karşıladığından emin olmak için ölçme, test etme, test etme gibi faaliyetleri dahil edin.
• Kontrol çizelgesi. Çalıştırma Grafikleri, süreç ortalamalarının her iki tarafına da yansıyan üst ve alt sınırları istatistiksel olarak tanımlar.
• Diyagramlar: Ishikawa, Pareto.
• İstatistiksel örnek.
• Moda analizi.

« Araçları kullanma amacı– sonuçları veya değişiklikleri yakalayın, grafiksel olarak görüntüleyin ve ardından sorunları uygun bir şekilde tanımlayın ve düzeltin.”

Kalite Kontrol Süreci: Çıktılar

• Kalite iyileştirme. Kalite güvence sürecinden çıkın.
• Karar vermek. İncelenen nesnenin kabul veya reddedilmesine bağlı olarak kararlar verilir.
• Düzeltici eylem. Uygun olmayan bir varlığı eşleştirmek için yapılan eylem.
• Tamamlanmış kontrol listeleri.
• İşlem kurulumu.

Referanslar

• http://sorlik.blogspot.com, Sergey Orlik, 2004-2005
• Genelt A.E. "Yazılım Geliştirmenin Kalite Yönetimi" disiplini üzerine eğitim ve metodolojik el kitabı 2007, St. Petersburg

Yazılım kalitesine yaklaşımlar

Yazılım kalitesine farklı yaklaşımları iki boyut kullanarak sınıflandıralım.

Birinci boyut ya ürün ya da süreç odaklıdır. Yazılımın kalitesini artırmak için, örneğin daha kullanıcı dostu hale getirerek ürünün kalitesine odaklanabilirsiniz. Alternatif bir yaklaşım, süreç ne kadar iyi olursa yazılımın kalitesinin de o kadar iyi olduğunu varsayarak geliştirme sürecini iyileştirmektir.

İkinci boyut ya uygunluk ya da iyileştirme ile ilgilidir. Uygunluk, belirli bir standarda uygunluk olarak anlaşılır. İyileştirme, kaliteyi iyileştirmek için daha iyi yöntemlere ve en iyi uygulamalara geçmeyi amaçlar.

ISO 9126, kalitenin niteliklerini ve özelliklerini tanımlayan ve bu özellikleri nicelleştirmek için alınan önlemler de dahil olmak üzere bir ürün kalite standardıdır;

örneğin "uygulamanın iyileştirilmesi", yazılım konfigürasyon yönetiminin, denetimlerin, testlerin vb. iyileştirilmesidir;

ISO 9000, kalite sistemleri için gereksinimleri bildiren bir dizi standarttır. Yazılım geliştirme açısından, "Yazılımın geliştirilmesi, teslimi ve bakımında ISO 9001'in uygulanmasına ilişkin yönergeler" en yararlı olanlardır;

Yazılım geliştirme sürecini iyileştirme yöntemleri, bir bilgisayar şirketinin bu ölçekteki yerini belirleyebilecek bazı düzeyler ve uyumluluk gereksinimleri sunar. En iyi bilinen ve popüler iki yöntem şunlardır:

yazılım geliştirme süreci olgunluk modeli - Yazılım Mühendisliği Enstitüsü (SEI) tarafından önerilen Yazılım için Yetenek Olgunluk Modeli (CMM);

fırsatları belirlemek ve yazılım geliştirme sürecini iyileştirmek. ISO/IEC 15504 Yazılım Süreci İyileştirme ve Yetenek belirleme (SPICE).

Kaliteye ulaşmanın altında iki ana varsayım yatar.

• Kalite, geliştiricilerin ihtiyaçlarını karşılamakla başlar.
• Kalite, kullanıcı memnuniyeti ile kanıtlanmıştır.

Kaliteye ulaşma yaklaşımları aşağıdaki gibidir:

• kalifiye geliştiriciler, süreçlere tam bağlılık ve başarılı teknolojik yaklaşımlar sayesinde kaliteye ulaşılır;
• kalite, tüm eylemlerin ve değişikliklerin tam olarak anlaşılmasıyla elde edilir. Neyin, neden ve nasıl yapıldığı tam olarak anlaşılmadan programa tek bir satır eklenmemeli veya değiştirilmemelidir;
• kalite, programın kullanıcıya sunulmadan önce kapsamlı bir şekilde test edilmesiyle elde edilir;
• kaliteye ulaşılması planlanmalıdır;
• Kaliteye ulaşmak her geliştiricinin sorumluluğundadır.

Yazılım Kalite Özellikleri

Şu anda, yazılım kalitesi için genel kabul görmüş bir kriter bulunmamaktadır.

ISO 9000-3, madde 6.4.1

Kalitenin klasik tanımı, geliştirilen yazılım ürününün kendi spesifikasyonunu teyit etmesi ve spesifikasyonun müşterinin almak istediği özelliklere odaklanması gerektiğidir.

Modern standartlar, kalite kavramını netleştirir, kullanıcıların belirtilen ihtiyaçlarını karşılama yeteneğini etkileyen bir dizi özellik ve özellik sunar. Bu tür bir dizi özelliği sıralayalım [Zhogolev 1996].

İşlevsellik (uygunluk, doğruluk, birlikte çalışabilirlik, tutarlılık, güvenlik). İşlevsellik, bir yazılım ürününün, kullanıcıların belirtilen veya ima edilen ihtiyaçlarını karşılayan bir dizi işlevi yerine getirme yeteneğidir. Bu tür işlevler kümesi, yazılım ürününün dış açıklamasında tanımlanır.

Güvenilirlik (bütünlük, kararlılık, kurtarılabilirlik).

Kolaylık (anlaşılabilirlik, geliştirme verimliliği, ergonomi). Kolaylık, kullanıcının ilk verileri hazırlama, yazılım ürününü kullanma ve elde edilen sonuçları değerlendirme çabalarını en aza indiren ve ayrıca belirli veya ima edilen bir kullanıcı için olumlu duygular uyandıran bir yazılım ürününün özellikleridir.

Verimlilik (zaman ve kaynaklar açısından). Verimlilik, belirli koşullar altında yazılım ürünü tarafından kullanıcıya sağlanan hizmetlerin düzeyinin kullanılan kaynak miktarına oranıdır.

Sürdürülebilirlik (analiz kolaylığı, değişkenlik, kararlılık, doğrulanabilirlik). Sürdürülebilirlik, bir yazılım ürününün, içindeki hataları ortadan kaldırmak ve değişen kullanıcı ihtiyaçlarına göre değiştirmek için değişiklik yapma çabasını en aza indiren özellikleridir.

Taşınabilirlik (uyarlanabilirlik, kurulum esnekliği, standart ve düzenlemelere uygunluk, değiştirilebilirlik). Taşınabilirlik, bir yazılım ürününün bir ortamdan diğerine, özellikle bir donanım mimarisinden diğerine taşınabilme yeteneğidir.

İyi kalite (rasyonel organizasyon, düşüncelilik). En ilginç iki özelliğe daha yakından bakalım.

Güvenilirlik, bir programın belirli işlevleri, belirli koşullar altında, belirli bir süre boyunca yeterince yüksek bir olasılıkla hatasız olarak yerine getirme yeteneğidir. Güvenilir bir yazılım ürünü, içindeki hataların varlığını dışlamaz. Burada, belirli koşullar altında pratik uygulamadaki hataların oldukça nadir görülmesi önemlidir. Güvenilirlik derecesi, bir yazılım ürününün belirli bir süre boyunca hatasız çalışma olasılığı ile karakterize edilir.

Güvenilirliği sağlamak için aşağıdaki yaklaşımlar vardır:

• hata uyarısı;
• hata kendini algılama;
• hataların kendi kendine düzeltilmesi;
• hata toleransının sağlanması.

Programın iyiliği, programın yeterince düşünülmüş bir kontrol akışları ve bilgi akışları organizasyonu ile makul ve rasyonel olarak organize edilmiş olması ve fazla karmaşık olmaması gerçeğinde yatmaktadır. Kalite faktörü kavramı, bir programın içsel değerlerini teknik bir bakış açısıyla değerlendirmek için Pottosin [Pottosin 1997] tarafından tanıtıldı. Pottosin, programlar için dört sınıf kalite kriteri sunar.

Programların karmaşıklığını değerlendirmenin farklı yolları (metrikler) ile ilişkili nicel kriterler. Sayısal özelliklere örnekler verelim.

Programların uzunluğunu, hacmini, düzeyini ve entelektüel içeriğini değerlendiren bir dizi formül içeren Halsted önlemleri [Halsted 1981].

Programın kontrol grafiğinin karmaşıklığının tahmini. Bir program parçası, m - n + 2'ye eşit olan kontrol grafiğinin döngüsel sayısı ile değerlendirilebilir; burada m, yayların sayısıdır ve kontrol grafiğinin köşelerinin sayısıdır. Siklomatik sayının 10'u geçmemesi gerektiğine inanılmaktadır.

Programın modüler bölümünün tahmini. Böyle bir değerlendirme birçok kriterden oluşmalıdır. Örneğin, bir modülün karmaşıklığı, içinde tanımlanan prosedürlerin karmaşıklığı ve tanımlanan varlıkları içe ve dışa aktarmak için modülün diğer modüllerle olan bağlantılarının karmaşıklığı ile tahmin edilir.

Programın kökeni ve yaratılış disiplini ile ilgili genetik kriterler.

Programda yönetim organizasyonunun değerlendirilmesine ilişkin yapısal kriterler ve yönetim organizasyonunun program metnine yansıması.

Program metninin programın amacına nasıl karşılık geldiğinin değerlendirilmesiyle ilgili pragmatik kriterler. İyi programlarda olmaması gereken, örneğin hesaplama fazlalığı gibi bir fazlalıklar listesi formüle edilmiştir.

Geliştirme sürecinin kalitesinin değerlendirilmesi

Aynı programdan hem verimlilik hem de esneklik talep etmek -

çekici ve mütevazı bir eş aramak gibi.

Görünüşe göre, iki şeyden birinde durmalıyız.

D.Weinberg

Bu bölümün başında, bir yazılım ürününün kalitesini değerlendirmek için kullanılabilecek iki yaklaşım olduğunu belirtmiştik.

• Nihai ürünün kalitesini değerlendirin.
• Geliştirme sürecinin kalitesini değerlendirin.

Nihai ürünün kalitesini test ederek ve çalıştırarak değerlendirebilirsiniz. Programdaki ana çalışma tamamlandıktan sonra bunun için zaman ayrılmalıdır. Ancak ikinci yaklaşım, şirketin uzun vadeli stratejisinin bir parçası haline gelmelidir.

Yazılım Geliştirme Süreci Olgunluk Modeli

Model, beş kurumsal olgunluk düzeyi tanımlar (http://www.sei.cmu.edu/cmm).

İlk seviye. Bu seviyede, geliştirme süreci, yönetim süreçlerinin sanal yokluğu ile karakterize edilir. Projenin başarısı, proje katılımcılarının bireysel çabalarına, kişisel niteliklerine ve hatta kahramanlıklarına bağlıdır.

Tekrarlanabilir seviye Bu olgunluk düzeyinde şirket, maliyeti, proje programını ve işlevselliği izlemek için temel yönetim süreçlerine sahip olmalıdır. Seviye, proje yönetiminin birikmiş deneyime dayanması ve daha önce elde edilen başarıların benzer uygulamalarda tekrarlanması ile karakterize edilir.

Belli bir seviye. Yazılım geliştirme süreci (hem yönetim hem de mühendislik faaliyetleri düzeyinde) tüm organizasyon düzeyinde belgelenir, standartlaştırılır ve entegre edilir. Süreç, bireysel geliştiricilerin bireysel niteliklerine bağlı olmaktan çıkar ve kriz durumlarında daha düşük seviyelere kayamaz.

yönetilen seviye Şirket, geliştirme süreci ve ürün kalitesi için ayrıntılı nicel göstergeler belirler. Hem geliştirme süreci hem de ürünler anlaşılabilir ve kontrol edilebilir.

optimizasyon seviyesi. Sürecin mevcut sonuçlarının analizine ve yenilikçi fikir ve teknolojilerin uygulanmasına dayalı olarak geliştirme sürecinin sürekli iyileştirilmesi.

Fırsatların Belirlenmesi ve Yazılım Geliştirme Sürecinin İyileştirilmesi

Bu model, olgunluk modeline çok yakındır, ancak yetenek seviyeleri sadece bir bütün olarak organizasyona değil, aynı zamanda bireysel süreçlere de uygulanabilir. Bu tip modellere genellikle sürekli denir. Sürekli modellerde, bir süreç düşük olgunluk düzeyinde, diğeri ise yüksek olgunluk düzeyinde olabilir. Standart, altı süreç olgunluğu seviyesi tanımlar.

Seviye 0: İşlem çalışmıyor.

Seviye 1. Süreç devam ediyor.

Seviye 2. Yönetilen süreç.

Seviye 3. Kurulan süreç.

Seviye 4. Öngörülebilir süreç.

Seviye 5. Optimizasyon süreci.

Süreçlerin kalitesinin değerlendirilmesi ve iyileştirilmesi sırasında aşağıda açıklanan görevler [Terekhov, Tunon 1999] gerçekleştirilir.

Belirli bir kuruluşta var olan yazılım geliştirme sürecinin standartta açıklanan modelle karşılaştırılması. Sonuçların analizi, sürecin güçlü ve zayıf yönlerini, iç risklerini belirlemeyi mümkün kılar.

Mevcut fırsatların belirlenmesine dayalı olarak bu süreci iyileştirme olasılığının değerlendirilmesi.

Süreci iyileştirmek için formüle edilmiş hedefler temelinde belirlenen görevlerin teknik uygulaması. Bundan sonra, tüm iş döngüsü tekrar başlar.

Savunma Bakanlığı'nın rolü hakkında

Tarihsel olarak, savunma açısından önemli projelerin geliştirilmesi için sipariş aldıklarını iddia eden kuruluşlarda makul değerlendirme prosedürleri ve müteakip teknolojik süreçlerin geliştirilmesini elde etmek için geliştirme sürecinin kalitesini değerlendirmek için modellerin oluşturulduğunu unutmayın. Modeller, karmaşık ve gerçek zamanlı sistemler geliştiren şirketlere uygulanabilir. Bunlar, yazılım kusurlarının kritik olabileceği uzun yaşam döngüsüne sahip sistemlerdir.

"Yeterince iyi" yazılım

Dün Seattle'da Bill Gates beta sürümünün yayınlanmasından bahsettikten sonra

Microsoft'un yeni programı bir depremle sarsıldı.

Kullanıcılar, ürünün son sürümünün piyasaya sürüleceğinin duyurulmasını dehşetle bekliyor.

Yeterince iyi yazılım, Edward Yordon tarafından teşvik edilmektedir [Yordon 2001]. Bu kavramı, zaman, bütçe ve insan kaynakları konusunda ciddi kısıtlamalarla sınırlanan "kötü projelere" uyguladığını vurguluyoruz (bkz. Kısım 1.6). Çoğu umutsuz projede, müşteri yeterince ucuz, yeterince iyi performans gösteren, doğru özelliklere sahip, yeterince kararlı ve yakında hazır olacak bir sistemden memnun olabilir. Aslında bu özellikler "yeterince iyi" yazılımın tanımı olarak kabul edilebilir.

"Yeterince iyi" bir yazılımın bile oluşturulmasının zor olduğu ortaya çıktı. İşte bunu açıklayan nedenler dizisinin bir kısmı [Yordon 2001].

Çoğu zaman kalite, yalnızca kusurlar (hatalar) açısından tanımlanmaya çalışılır. Kullanıcı açısından, belirli bir tarihe hazır olmak gibi hususlar da aynı derecede önemlidir.

Az sayıda hatanın daha iyi kaliteye eşdeğer olduğu varsayılır ve kullanıcı bu kaliteyi tercih eder. Bununla birlikte, bazen kullanıcı daha hızlı çalışma karşılığında bazı hatalara katlanmak ve taviz vermeye isteklidir.

Geliştirme ekibinin morali ve yeterli çalışma koşulları gibi faktörleri göz ardı etmek.

James Bach, "yeterince iyi" bir yazılım oluşturmak için aşağıdaki ön koşulları listeler:

• faydacı strateji - belirsiz durumlarda nicel analiz ve net kazancı maksimize etme sanatı;
• evrimsel strateji - sadece projenin yaşam döngüsü ile ilgili olarak değil, aynı zamanda insanlar, süreçler ve kaynaklar ile ilgili olarak da düşünülür;
• kahraman ekipler güçlü parlak programcılar değil, etkili işbirliği yapabilen sıradan yetenekli uzmanlardır;
• dinamik altyapı - bürokrasinin ve siyasetin egemenliğinin karşıtı;
• dinamik süreçler - evrimsel bir ortamda çalışmayı destekleyen süreçler.

Ne yazık ki, "yeterince iyi" yazılım nadiren gerçekten yeterince iyidir. Niklaus Wirth, bunun "kişinin işinden duyduğu kişisel gururun kaybolduğu zamanımızın ruhunun üzücü tezahürünün bir sonucu" olduğunu belirtiyor. Ona göre, "kişi kendini tamamen ona vermezse, kişisel tatmin yoksa, ayrıca ondan zevk almazsa yüksek kaliteli iş bekleyemez."

Bazı şirketlerin, ürünlerinin kullanıcılarının entelektüel seviyelerini düşürme eğiliminde olduklarına dair ilginç bir gözlem, birçok programcı tarafından yapılmıştır. Teknik becerileri, yazılım ürününün gerçek yönlerini (örneğin, kalite, karmaşıklık, değer) belirlemeye izin vermeyen kişilerle çalışmak şirketler için son derece karlı. İşin "basitleştirilmesinin" arkasına saklanarak ve kullanıcılar için bilgisayarların kullanılabilirliğini artıran şirketler, yazılımı sürekli olarak aşırı yüklemekte ve kullanıcının gerçekten nasıl çalıştığını anlamasını ve profesyonel olmasını son derece zorlaştıracak şekilde yazılımı karmaşıklaştırmaktadır.

Bilgi teknolojisi standardizasyonu

Standart, bir anlaşmadan kaynaklanan bir donanım veya yazılım bileşeninin genel kabul görmüş tanımıdır. Profil, belirli bir göreve odaklanan bir dizi yasal ve/veya olgusal standarttır [Kozlov 1999].

Standartlar şu şekilde sınıflandırılabilir:

• gereksinim ayarı türüne göre:
• nesne için gereksinimlerin belirlenmesi;
• süreç için gereksinimlerin belirlenmesi;
• ölçeğe göre:
• Uluslararası;
• durum;
• sanayi;
• işletmeler;
• yasal kayıt derecesine göre:
• yasal olarak kabul edildi;
• aslında çalışıyor.

Bilgi teknolojisi standardizasyon süreci, üç ana organizasyon grubu tarafından desteklenmektedir. BM yapısının bir parçası olan uluslararası kuruluşlar. Uluslararası Standardizasyon Organizasyonu (ISO), standardizasyon için uluslararası bir organizasyondur.

ISO hakkında

1947'de 25 ülkenin temsilcileri, ana görevi uluslararası standartların geliştirilmesini ve birleştirilmesini koordine etmek olacak bir organizasyon oluşturmaya karar verdi. Yeni organizasyona Uluslararası Standardizasyon Örgütü (ISO) adı verildi. Tam ad ile kısaltma arasındaki tutarsızlık, "ISO"nun "eşit" anlamına gelen Yunanca bir önek olmasından kaynaklanmaktadır.

Uluslararası Elektroteknik Komisyonu (IEC) - Uluslararası Elektroteknik Komisyonu.

Uluslararası Telekomünikasyon Birliği-Telekomünikasyon (ITU-T) - uluslararası telekomünikasyon birliği - telekomünikasyon. 1993 yılına kadar bu organizasyona Uluslararası Telgraf ve Telefon Danışma Komitesi adı verildi - telefon ve telgraf üzerine uluslararası bir danışma komitesi.

Endüstriyel mesleki veya idari kuruluşlar.

Elektrik ve Elektronik Mühendisleri Enstitüsü (IEEE) - Elektrik ve Elektronik Mühendisleri Enstitüsü.

İnternet Faaliyet Kurulu (IAB), İnternet faaliyetleri için yönetim kuruludur.

endüstriyel konsorsiyum.

Nesne Yönetim Grubu (OMG) - nesne yönetimi grubu.

X/Open, bir grup bilgisayar satıcısı tarafından organize edilen bir konsorsiyumdur.

Açık Yazılım Vakfı (OSF), bir açık kaynak temelidir.

1987 yılında, ISO ve IEC, bilgi teknolojisi standardizasyonu alanındaki faaliyetlerini birleştirdi ve tek bir yapı oluşturdu - Ortak Teknik Komite 1 (JTC1) - ortak teknik komite 1. Bu komite, aşağıdakiler alanında bir temel standartlar sistemi oluşturmak üzere tasarlanmıştır. bilgi Teknolojisi.

Yazılım kalitesini yöneten standartları ele almadan önce, her türlü ürünün kalitesiyle ilgili genel konuları tartışmak gerekir. Genel konular, alandaki tanımları ve terminolojiyi, kalitenin temel kavramlarını, ürün kalite güvencesinde dokümantasyonun rolünü ve uluslararası kalite standartlarının seçimini ve uygulanmasını içerir. Şüphesiz Uluslararası Standardizasyon Örgütü tarafından geliştirilen ISO 9000 serisinin uluslararası standartları, kalite alanında ana standartlar haline gelmiştir. Aşağıdaki alt bölüm, ISO 9000 serisi standartlar ışığında yukarıda listelenen genel konuları ele almaktadır.

1.1 ISO 9000 serisi standartların temelleri

İlk olarak, ISO 9000 serisi standartlar, Uluslararası Standardizasyon Örgütü'nün (ISO) 176 Kalite Yönetimi ve Kalite Güvencesi Teknik Komitesi tarafından geliştirilen tüm uluslararası standartları ifade eder. Seri şu anda 9000 ila 9004 (ISO 9000 ve ISO 9004'ün tüm bölümleri dahil), 10001 ila 10020 (tüm parçalar dahil) ve ISO 8402 Uluslararası Standartlarını içermektedir. Aşağıda bu seriyi oluşturan ana standartların adları verilmiştir.

ISO 9000-1-94 Kalite yönetimi ve kalite güvence standartları. Bölüm 1. Başvurmayı seçmek için yönergeler.

ISO 9000-2-93 Kalite yönetimi ve kalite güvence standartları. Bölüm 2: ISO 9001, ISO 9002 ve ISO 9003'ün uygulanması için genel yönergeler.

ISO 9000-3-91 Kalite yönetimi ve kalite güvence standartları. Bölüm 3: Yazılımın geliştirilmesi, teslimi ve bakımında ISO 9001'in uygulanması için yönergeler.

ISO 9000-4-93 Kalite yönetimi ve kalite güvence standartları. Bölüm 4. Genel güvenilirlik programının yönetimi için yönergeler.

ISO 9001-94 Kalite sistemleri. Tasarım, geliştirme, üretim, kurulum ve serviste kalite güvencesi için bir model.

ISO 9002-94 Kalite sistemleri. Üretim, kurulum ve serviste kalite güvencesi modeli.

ISO 9001-94 Kalite sistemleri. Bitmiş ürün denetimi ve son testte kalite güvencesi modeli.

ISO 9004-1-94 Kalite yönetimi ve kalite sistem öğeleri. Bölüm 1. Yönergeler.

ISO 9004-2-91 Kalite yönetimi ve kalite sistem unsurları. Bölüm 2. Servis Yönergeleri.

ISO 9004-3-93 Kalite yönetimi ve kalite sistem öğeleri. Bölüm 3. İşlenmiş malzemeler için yönergeler.

ISO 9004-4-93 Kalite yönetimi ve kalite sistem öğeleri. Bölüm 4. Kalite iyileştirme yönergeleri.

ISO 10011-1-90 Kalite sistemleri. Denetimler için yönergeler. Bölüm 1. Kontroller.

ISO 10011-2-91 Kalite sistemleri. Denetimler için yönergeler. Bölüm 2. Kalite sistemlerinin uzman denetçileri için yeterlilik kriterleri.

ISO 10011-3-91 Kalite sistemleri. Denetimler için yönergeler. Bölüm 3. Denetim programlarının idari yönetimi.

ISO 10012-1-92 Ölçüm ekipmanının kalite güvencesi. Gereksinimler. Bölüm 1. Ölçüm ekipmanı için metrolojik destek sistemleri.

ISO 10013 Kalite kılavuzları. Geliştirme hükümleri. (Yayın aşamasında).

ISO 8402-94 Kalite yönetimi ve kalite güvencesi. Sözlük.

Kuruluşlar, yazılım dahil ürün üreticileri arasındaki mevcut artan rekabet, bu ürünler için daha katı kalite gereksinimlerinin oluşturulmasına yol açmaktadır. Rekabetçi olmak için kuruluşlar, gelişmiş ürün kalitesine ve daha iyi müşteri memnuniyetine yol açan etkili sistemler uygulamalıdır. Teknik şartnamelerde yer alan doğru formüle edilmiş ve eksiksiz müşteri gereksinimleri, kuruluşun tedarik ve destek sisteminde eksiklikler olduğundan, bu gereksinimlerin tam olarak karşılanacağını henüz garanti etmemektedir. Bu düşünce, kalite sistemleriyle ilgili standartların geliştirilmesine ve ürünler için müşteri gereksinimlerinin tamamlanmasına yol açtı. ISO 9000 serisindeki Uluslararası Standartlar, kalite sistem standartları için ortak bir çerçeve sağlamayı amaçlamaktadır. Kalite sistemi altında, ISO 8402'ye göre, kuruluş tarafından üretilen ürünlerin kalitesinin genel yönetiminin uygulanması için gerekli bir dizi organizasyon yapısı, yöntem, süreç ve kaynak anlaşılır.

Bir kuruluşun kalite yönetim sistemi, ürün kalite politikasını, kuruluşun amaçlarını ve sorumluluklarını tanımlayan ve bunları kalite sistemi içinde kaliteyi planlama, kontrol etme, sağlama ve iyileştirme yoluyla uygulayan bir kuruluş tarafından kullanılan genel yönetim fonksiyonunun yönleridir. Kuruluşun amacına ek olarak, kalite yönetim sistemi ürettiği ürünlerden ve bu kuruluşun özelliği olan üretim yöntemlerinden etkilenir. Aynı alanda faaliyet gösteren kuruluşların üretim yöntemlerinin farklı olması ve kuruluşun hedeflerinin her zaman aynı olmaması nedeniyle bu kuruluşların kalite sistemleri örtüşmemektedir. Kalite yönetim sisteminin temel amacı, ürün kalitesini iyileştirmek için sistemleri ve süreçleri iyileştirmektir.

ISO 9000 serisi, bir kalite sistemine hangi unsurların dahil edilmesi gerektiğini belirtirken, kuruluşun kendisi, belirli hedefler, ürünler ve süreçler ile kuruluş tarafından kullanılan belirli yöntemleri dikkate alarak bunları uygulamalıdır.

Ek olarak, ISO 9000 serisinin yönergeleri ve gereksinimleri, ulaşılacak kalite sistem hedefleri açısından ifade edilir ve bu hedeflere nasıl ulaşılacağını belirtmez, bu yöntemlerin seçimini kuruluşun yönetimine bırakır. Bu serinin standartları, kalite sistemleri için gereksinimleri, ürünler için müşteri gereksinimlerinden ayırır. Kalite sistem gereksinimleri, ürün spesifikasyonlarını tamamlayıcı niteliktedir. Örneğin, ISO 12207, yazılım geliştirme yaşam döngüsünü belirtir. Kalite güvence sürecine (ISO 12207'nin 2.3'ü) karşılık gelen süreçler ve kalite modelleri, ISO 9000 serisi standartlarda belirtilmiştir.

ISO 9000-1, herhangi bir kuruluş tarafından sağlanan tüm ürün türlerini kapsayan dört genel ürün kategorisi tanımlar:

Teknik araçlar.

Yazılım.

işlenmiş malzemeler.

ISO 9000 serisi uluslararası standartlarda belirtilen kalite sistemleri gereksinimleri, dört genel ürün kategorisinin tümü için geçerlidir, ancak terminoloji ve kalite yönetim sistemlerinin bazı hükümleri ve yönleri farklı olabilir. Bu, ISO 9004 - 2 ve ISO 9004 - 3 standartlarının başlıklarından görülebilir. Herhangi bir kuruluşun en az iki kategoride ürün sunduğu unutulmamalıdır. Örneğin, bir yazılım geliştirme kuruluşu ayrıca müşterilerine geliştirilen yazılımın bakımı için hizmetler sağlar.

ISO 9000 serisinin uluslararası standartlarının yönergelerinin ve gereksinimlerinin amacı, ürün kalitesinin anahtarı olan dört açıdan gereksinimleri karşılamaktır.

1. Ürünler için müşteri ihtiyaçlarını belirleyerek kalite. Birinci husus, pazarın gereksinimlerini ve fırsatlarını karşılamak için ürünlerin tanımlanması ve modernizasyonu yoluyla kalitedir.

2. Tasarım yoluyla kalite. İkinci yön, pazarın taleplerini ve fırsatlarını karşılamalarına yardımcı olan özelliklerin ürünlere dahil edilmesi yoluyla kalitedir. Başka bir deyişle, tasarımla kalite, bir ürünün değişen üretim ve uygulama koşulları altında düzgün çalışmasını etkileyen tasarım özellikleridir.

3. Tutarlı tasarım yoluyla kalite. Üçüncü yön, tasarıma sürekli uyumun sürdürülmesi, projeye özgü özelliklerin uygulanması yoluyla kalitedir.

4. Bakım yoluyla kalite. Dördüncü yön, istenen özellikleri korumak için gerektiğinde ürünlerin çalışması sırasında bakımı yoluyla kalitedir.

ISO 9000 serisi standartlar, idari kontrol için genel yönergeleri ve dört açıdan dış kalite güvencesi gerekliliklerini bütünüyle sağlar.

ISO 9000 serisindeki uluslararası standartlar, tüm işlerin süreçlerle yapıldığı anlayışına dayanmaktadır (bkz. Şekil 1). Her sürecin girdi faktörleri vardır. Sürecin çıktısı sonuçtur - somut ve soyut ürünler. Sürecin kendisi değer katan bir dönüşümdür (veya olmalıdır). Her süreç, bir dereceye kadar insanları ve/veya diğer kaynakları içerir. Bir çıktı, örneğin bir program, bir bankacılık hizmeti, herhangi bir ana ürün kategorisinin bitmiş (veya ara) ürünü olabilir. Girişte, sürecin çeşitli aşamalarında ve çıktıda ölçüm yapma imkanları vardır.

Şekil 2'de gösterildiği gibi, girdiler ve çıktılar çeşitli tiplerde olabilir: ürünle ilgili (Şekil 2'deki düz çizgiler) (örneğin, hammaddeler, bitmiş ürün) ve bilgiyle ilgili (kesik çizgiler) (örneğin, ürün gereksinimler, bilgi özellikleri). Bu şekil, tedarik zincirindeki alt tedarikçi ve müşteri süreçleri ile tedarikçi süreçlerini temsil etmektedir. Bu ağın yapısında çeşitli girişler ve çıkışlar farklı yönlerde hareket eder. Buradaki "ürün" terimi, dört ana ürün kategorisinin tümüne atıfta bulunmaktadır.

İdari kalite yönetimi, organizasyondaki süreçlerin yönetimi yoluyla gerçekleştirilir. Süreç yönetiminin iki yönü vardır:

ürünlerin veya bilgilerin içinde taşındığı sürecin kendisinin yapısının ve işleyişinin yönetimi;

yapı içindeki ürünlerin veya bilgilerin kalite kontrolü.

Çoğu organizasyonun karmaşık yapısı göz önüne alındığında, temel süreçleri izole etmek ve süreçleri kalite yönetimi hedeflerine dayalı olarak basitleştirmek ve sıralamak önemlidir. Karmaşık bir süreç ağı örneği, ISO/IEC 12207 ve DO-178'e göre yazılım geliştiren bir kuruluştur.

Şekil.1.1 Tüm işler süreçler kullanılarak gerçekleştirilir.

süreçler

Tedarikçi

tüketici

Gereksinimler

girdi faktörleri

Çıktı Faktörleri

Durum ve özellikler

Ürün:% s

Durum ve özellikler

Ürün:% s

Gereksinimler

Geri bildirim

Geri bildirim

alt tedarikçi

Şekil 1.2 Ürünler ve bilgilerle ilişkili akışların varlığında tedarik zincirindeki süreçlerin ilişkisi.

Herhangi bir kuruluş, süreçler ve arayüzler ağını tanımlamalı, kurmalı ve yönetmelidir. Kuruluş, bir süreç ağının uygulanması yoluyla ürünlerinin sabit bir kalite seviyesini yaratır, geliştirir ve sürdürür. Bu, ISO 9000 serisi standartların kavramsal temelidir.Ürün kalitesini sağlamak için prosesler ve bunların arayüzleri gözden geçirilmeli ve sürekli iyileştirilmelidir.

Herhangi bir organizasyonun kalite sistemlerini değerlendirirken, ISO 9000-1, değerlendirilen her ağ süreci hakkında üç önemli soru sormanızı önerir.

Bu süreçler tanımlanmış ve prosedürleri belgelenmiş mi?

Bu süreçler tam olarak uygulanıyor mu ve belgeleniyor mu?

Bu süreçler beklenen sonuçların elde edilmesinde etkili midir?

Bir değerlendirmenin sonucu, sırasıyla yaklaşım, uygulama ve sonuçla ilgili bu sorulara verilen bir dizi cevaptır. Bir kalite sistem değerlendirmesi, kapsanan alana göre değişiklik gösterebilir ve farklı faaliyetleri içerebilir.

Sistematik olarak yürütülen bu tür faaliyetlerin en önemli türlerinden biri, kuruluşun yönetimi tarafından ISO 9001, 9002, 9003'e uygun olarak yürütülen kalite sisteminin durumunun ve yeterliliğinin değerlendirilmesidir. kalite sisteminin değerlendirilmesi süreci, verimliliğinde ve ekonomisinde bir artışa yol açmalıdır. Bu tür sonuçlara ilişkin bilgi kaynağı, aynı zamanda kalite sisteminin iç ve dış denetimlerinin sonuçlarıdır.

Kuruluşun kendisi tarafından yürütülen dahili kalite incelemeleri (Birinci Bölüm), etkili yönetim incelemesi ve düzeltici, önleyici ve iyileştirme eylemi için bilgi sağlar.

Ürünlerin müşterileri (ikinci taraf) ve bağımsız kuruluşlar (üçüncü taraf) tarafından gerçekleştirilen dış denetimler, sırasıyla müşterinin tedarikçiye güvenini ve sertifikanın alınmasını sağlar, böylece kuruluşun ürünlerinin bir dizi potansiyel tüketicisine güven sağlar.

ISO 9000 standart ailesinin uygulanabileceği durumlar ve tedarikçinin seriyi kullanma şekli de dikkate alınmalıdır.

ISO 9000 serisindeki Uluslararası Standartların aşağıdaki dört durumda uygulanması amaçlanmıştır.

1. Kalite yönetimi için kılavuz olarak. Bu durumda kalite sisteminin ürün kalite gerekliliklerini ekonomik ve optimal bir şekilde karşılayabilmesi için kendi etkinliğini arttırması gerekmektedir.

2. Birinci ve ikinci taraflar arasındaki sözleşme şartlarına göre. Bu durumda müşteri, belirli bir kalite güvence modelini belirtirken, kalite sisteminin belirli unsurlarının ve süreçlerinin tedarikçinin kalite sisteminin bir parçası olmasını ister.

3. İkinci bir tarafça onaylandığında veya kaydedildiğinde. Bu, kalite sisteminin müşteri tarafından değerlendirildiği durumdur. Tedarikçi, ürününün standarda uygun olduğuna dair resmi onay alabilir.

4. Bir üçüncü şahıs tarafından onaylandığında veya tescil edildiğinde. Bu durumda, kalite sistemi belgelendirme kuruluşu tarafından değerlendirilir ve kuruluş, ürünlerinin tüm tüketicileri için böyle bir kalite sistemini sürdürmeyi kabul eder.

Tedarikçi, ISO 9000 standart ailesini kullanmanın iki yönteminden birini kullanmayı seçebilir: "yönetim güdümlü yöntem" ve "paydaş güdümlü yöntem". İkinci yöntem en yaygın olarak kabul edilir.

Paydaş motive yöntemini kullanırken, tedarikçi, müşterilerin acil gereksinimlerine yanıt olarak ilk olarak bir kalite sistemi sunar. Kalite sistemi ISO 9001, 9002, 9003 gerekliliklerine uygun olmalıdır. Kuruluşun yönetimi bu yöntemde öncü rol oynar, ancak dış paydaş (tüketiciler) itici güçtür.

Yönetimin motive ettiği yöntemi kullanırken, gelecekteki pazar ihtiyaçlarını ve eğilimlerini belirleme çabalarını başlatan kuruluşun yönetimidir. Ürün kalitesini iyileştiren bir kalite sisteminin ilk kurulumu için kılavuz ISO 9004-1'dir (ve ISO 9004'ün diğer bölümleri). Ayrıca tedarikçi, sertifika almak için kalite sisteminin yeterliliğini göstermek için bir kalite güvence modeli olarak ISO 9001, 9002 veya 9003'ü uygulayabilir. Bu şekilde uygulanan kalite sistemi, ilk uygulanandan daha geniş kapsamlı ve verimlidir.

ISO 9000 serisi standartlar, değer katan bir faaliyet olarak dokümantasyonun hazırlanmasını ve kullanılmasını vurgular. Uygun dokümantasyon, aşağıdaki kalite güvence faaliyetlerinde önemli bir rol oynar:

gerekli ürün kalitesinin elde edilmesinde;

kalite sistemlerinin değerlendirilmesi;

kalite iyileştirmede;

ulaşılan kalite seviyesinin korunmasında.

İç ve dış denetimler için prosedürlerin belgelenmesi, süreçlerin tanımlandığına, prosedürlerin onaylandığına ve kontrol altında olduğuna dair kanıt sağlar. Yalnızca bu koşullarda denetimler, kuruluşun süreç ağının uygulanmasının ve yürütülmesinin yeterliliğinin tam bir değerlendirmesini garanti eder.

Ayrıca dokümantasyon, ürün kalitesinin iyileştirilmesinde önemli bir rol oynar. Prosedürler belgelenir, uygulanır ve takip edilirse nasıl yapıldığını belirlemek mümkündür.

Yazılım dahil her türlü ürünün tasarımı, geliştirilmesi, üretimi, kurulumu ve bakımında kalite güvencesi için bir model tanımlayan ISO 9001 standardı aşağıda daha ayrıntılı olarak ele alınacaktır.

Yazılım mühendisliği alanındaki ana kalite standardı şu anda ISO/IEK 9126 standardıdır ve yazılım kalite gereksinimlerinin isimlendirmesini, niteliklerini ve ölçütlerini tanımlar. Nispeten yakın zamanda, bu standart yazılım kalite modellemesinde belirleyici faktörlerden biri haline geldi ve bu güne kadar öyle kaldı.

Buna ek olarak, bu özelliklerin nasıl değerlendirilebileceğini yöneten bir dizi ISO/IEK 14598 standardı yayımlanmıştır. Birlikte SQuaRE olarak bilinen kaliteli bir model oluştururlar.

Genel yaklaşım, önce en yüksek soyutlama düzeyindeki küçük bir kalite nitelikleri kümesini tanımlamak ve daha sonra yukarıdan aşağıya bir yönde bu nitelikleri alt nitelik kümelerine ayırmaktır. ISO/IEK 9126 standardı bu yaklaşımın tipik bir örneğidir.

SQuaRE modeli çerçevesinde, kalitenin aşağıdaki 6 ana özelliği ayırt edilir:

1. işlevsellik(doğruluk, tutarlılık, birlikte çalışabilirlik, güvenlik, uygunluk). Fonksiyonel gereksinimler geleneksel olarak yazılım spesifikasyonu, modelleme, uygulama ve doğrulamanın odak noktası olmuştur. Sistemin davranışını tanımlayan zorunlu kipte ifadeler olarak formüle edilirler. Resmi yöntemlerin kullanılması, sistemin gerçek davranışının gerekli olandan neredeyse sıfıra sapma düzeyini getirmeyi mümkün kılar. Bu, işlevsel gereksinimlerin uygun biçimsel hesapların tümceleri olarak ifade edilmesiyle sağlanır, böylece doğrulama kesin bir kanıta indirgenir.

2. Güvenilirlik(kararlılık, tamlık, kurtarılabilirlik). Güvenilirlik göstergeleri, ortamdaki veya sistemin kendisindeki bir arıza nedeniyle işleyen parametrelerin normal değerlerinin ötesine geçtiğinde sistemin davranışını karakterize eder. Güvenilirliğin niteliklerini değerlendirirken, olasılık teorisi ve matematiksel istatistik yöntemleri kullanılır. Güvenilirlik gereksinimleri, kritik can güvenliği sistemlerinin geliştirilmesinde özellikle önemlidir. Biçimsel yöntemlerin kullanılması, iç hataların sayısını azaltmaya (yani sistemin bütünlüğünü artırmaya) yardımcı olsa da, genel olarak güvenilirliği sağlamak, çeşitli sistem türlerinin özelliklerini dikkate alan özel yaklaşımlar gerektirir.

3. Kolaylık(öğrenme verimliliği, ergonomi, anlaşılırlık). Sistemin kolaylık gereksinimlerine uygunluğunu değerlendirmek son derece zordur. Önerilen yaklaşımlar, kullanıcılar tarafından sistemde uzmanlaşmak için harcanan normatif emek birimlerinin (standart saat) tüketimini ölçmenin yanı sıra, bulanık mantık yöntemlerinin kullanılması da dahil olmak üzere uzman değerlendirmelerinin yürütülmesini ve analiz edilmesini içerir. Biçimsel yöntemlerin kullanılması bağlamında, en iyi çözüm, orijinal konu alanının yapısını en doğru şekilde yansıtabilen biçimciliklere başlangıçta odaklanmak gibi görünmektedir. Örneğin, bilgisayar sistemleri oluştururken, gelecekteki bir kullanıcının bakış açısından formalizmin yeterliliği için kriter, bilgisayar teknolojilerinin getirdiği kavramsal kısıtlamalara bağlı olmayan soyut bir matematiksel dilin desteklenmesidir.

4. Yeterlik(kaynak ve zaman açısından). Performans öznitelikleri geleneksel olarak yazılım sistemlerinin kalitesinin en önemli nicel göstergeleri arasında yer almıştır. Değerleri, yazılım ve donanım tarafından operasyonel belgelerde sabitlenmeye tabidir. Bu değerleri ölçmek için oldukça gelişmiş bir araç takımı bulunmaktadır. Sistemin kendisi ve çevresi için bu göstergelerin değerlerine dayalı olarak sistem performans göstergelerinin integral değerlerini tahmin etmek için teknikler de geliştirilmiştir. Verimliliği sağlamak için resmi yöntemlerin seçimine özel dikkat gösterilmelidir. Aynı zamanda, performans ve kaynak yoğunluğu arasında yakın bir ilişki olmasına rağmen, genel durumda bu gereksinimlerin her birinin sağlanmasına yönelik yaklaşımların farklı nitelikte olduğu akılda tutulmalıdır.

5. Sürdürülebilirlik ( analiz kolaylığı, değişkenlik, kararlılık ). Bakım yapılabilirlik gereksinimleri, öncelikle, işletim personeli tarafından harcanan sistemi sürdürme ve yükseltme çabasını en aza indirmeyi amaçlar. Bunları değerlendirmek için, standart bakım prosedürlerini gerçekleştirme maliyetlerini tahmin etmek için çeşitli yöntemler kullanılır. Uzun ömürlü sistemleri sürdürmenin bütünleyici maliyeti, geliştirme maliyetlerini önemli ölçüde aşabilir. Geliştirme resmi yöntemler kullanılarak yapıldığında bakım büyük ölçüde basitleşir, çünkü belirli bir anlamda kapsamlı bir dizi teknolojik dokümantasyon ve doğrulama testi vardır.

6. taşınabilirlik ( uyarlanabilirlik, standartlar ve düzenlemelere uygunluk, kurulum esnekliği, değiştirilebilirlik ). Sistemlerin taşınabilirliği, sistem ortamının işleyişi için gerekli olan bileşenlerini seçmedeki serbestlik derecesini karakterize eder. Taşınabilirliğin değerlendirilmesi, BT alanındaki hızlı ilerleme nedeniyle olası ortam seçenekleri listesinin temel eksikliği, dinamizmi tarafından engellenmektedir. Resmi yöntemler kullanılarak geliştirilen sistemler yüksek düzeyde taşınabilirliğe sahip olma eğilimindedir. Özellikle, böyle bir sistem bazı hedef teknolojik platformları desteklemiyorsa, bir "klon" oluşturulması, soyut modelinin hedef programlama araçları kullanılarak uygulanması, sistemin veya platformun kendisinin değiştirilmesinden önemli ölçüde daha az maliyet gerektirir.

Bu standart çerçevesinde oluşturulan kalite modeli, ürünün genel özelliklerine göre belirlenir. Nitelikler, sırayla, rafine edilebilir, başka bir deyişle, hiyerarşik olarak kalite alt özelliklerine bölünebilir. Bu nedenle, örneğin, sürdürülebilirlik özelliği, analiz kolaylığı, değişkenlik, kararlılık, test edilebilirlik gibi alt özelliklerle temsil edilebilir.

Ve son olarak, hiyerarşinin alt seviyesi, yazılımın doğru bir şekilde tanımlanabilen ve ölçülebilen özelliklerini doğrudan temsil eder. Kalite gereksinimleri de kalite modeli üzerindeki kısıtlamalar olarak gösterilebilir. Bu durumda, ürünün kalitesinin değerlendirilmesi aşağıdaki şemaya göre gerçekleşir. İlk olarak, yazılım ürününün nitelikleri değerlendirilir. Bunu yapmak için, bir metrik seçilir ve özniteliğin uygulanan kısıtlamalara olası uyum derecesine bağlı olarak bir değerlendirme ölçeği derecelendirilir. Her bir öznitelik değerlendirmesi için, derecelendirme genellikle yeniden seçilir ve buna dayatılan kalite gereksinimlerine bağlıdır. "Ölçülen" nitelikler seti, alt karakteristikleri ve özellikleri değerlendirmek için ve ürünün kalitesinin bir sonucu olarak kriterlerdir.

Bilet 26 27

Yazılım kalitesi, gereksinimlere uygunluk derecesi olarak yazılımın (SW) bir özelliğidir. Aynı zamanda, gereksinimler oldukça geniş bir şekilde yorumlanabilir, bu da kavramın bir dizi bağımsız tanımına yol açar. En yaygın olarak kullanılan tanım, kalitenin "içsel özelliklerin gereksinimlere uygunluk derecesi" olduğu ISO 9001'dir.

Kaynak kodu kalitesi

Kod kalitesi çeşitli kriterlere göre belirlenebilir. Bazıları sadece insan bakış açısından önemlidir. Örneğin, bir programın metninin nasıl biçimlendirildiği bilgisayarla tamamen ilgisizdir, ancak sonraki bakım için büyük önem taşıyabilir. Kullanılan dile özgü kuralları tanımlayan ve kodun okunabilirliğini artıran bir dizi kural belirleyen mevcut kodlama standartlarının çoğu, hata ayıklama ve güncelleme dahil olmak üzere gelecekteki yazılım bakımını kolaylaştırmayı amaçlamaktadır. Kodun "iyi" yazılıp yazılmadığını belirleyen, yapısallık - kodun mantıksal olarak bir dizi yönetilebilir bloğa bölünme derecesi gibi başka kriterler de vardır.

Kod okunabilirliği

Bakım, test, hata ayıklama, hata düzeltmeleri, değişiklikler ve taşınabilirlik kolaylığı

Düşük kod karmaşıklığı

Düşük kaynak kullanımı: bellek ve CPU zamanı

Doğru istisna işleme

Derlerken ve bağlarken birkaç uyarı

Kod kalitesini iyileştirme yöntemleri: yeniden düzenleme.

Kalite Faktörleri

Yazılım kalite faktörü, genellikle müşteriyle yapılan bir sözleşmede açıklanmayan, ancak yine de programın kalitesini artıran arzu edilen bir gereklilik olan bir program için işlevsel olmayan bir gerekliliktir.

Kalite faktörlerinden bazıları:

anlaşılırlık

Yazılımın amacı, programın kendisinden ve belgelerden açıkça anlaşılmalıdır.

Programın gerekli tüm bölümleri sunulmalı ve tam olarak uygulanmalıdır.

kısalık

Gereksiz, yinelenen bilgi yok. Kodun tekrar eden bölümleri, ortak bir prosedür çağrısına dönüştürülmelidir. Aynı şey belgeler için de geçerli.

taşınabilirlik

Programı farklı bir ortama uyarlama kolaylığı: farklı bir mimari, platform, işletim sistemi veya sürümü.

tutarlılık

Program ve belgeler boyunca aynı kurallar, biçimler ve kurallar kullanılmalıdır.

sürdürülebilirlik

Yeni gereksinimleri karşılamak için programı değiştirmenin ne kadar zor olduğu. Bu gereklilik aynı zamanda programın iyi belgelenmesi, fazla karışık olmaması ve kaynak kullanımında (bellek, işlemci) büyümeye yer olması gerektiğini belirtir.

test edilebilirlik

Programın kabul özelliklerini kontrol etmenize izin verip vermediği, performansı ölçme yeteneğinin desteklenip desteklenmediği.

Kullanım kolaylığı

Programın sadeliği ve kullanım kolaylığı. Bu gereksinim öncelikle kullanıcı arabirimi için geçerlidir.

güvenilirlik

programların çalışmasında arıza ve arızaların olmaması, ayrıca kusurları ve hataları düzeltme kolaylığı:

yapılandırılmışlık

yeterlik

Programın görevlerini yerine getirirken kaynaklara (bellek, işlemci) ne kadar rasyonel davrandığı.

Emniyet

ISO 9126 (GOST R ISO / IEC 9126-93)- "Bilgi Teknolojisi. Yazılım ürünü değerlendirmesi. Uygulamaları için kalite özellikleri ve yönergeler. ISO 9126, yazılım kalitesinin (bundan böyle yazılım olarak anılacaktır) değerlendirme özelliklerini tanımlayan uluslararası bir standarttır. GOST 28195 standardının Rus analogu Standart, aşağıdaki sorunları tanımlayan 4 bölüme ayrılmıştır: kalite modeli; dış kalite ölçütleri; dahili kalite metrikleri; kullanılan kalite metrikleri

ISO 9126-1 standardının ilk bölümünde oluşturulan kalite modeli, yazılım kalitesini 6 yapısal özellik kümesinde sınıflandırır ve bunlar sırasıyla aşağıdaki gibi alt özellikler (alt özellikler) tarafından detaylandırılır:

İşlevsellik - Yazılım işlevselliğinin, kullanıcının gerektirdiği işlevsellik kümesiyle uyumluluğunu karakterize eden bir dizi nitelik. Aşağıdaki alt özellikler (alt özellikler) ile detaylandırılmıştır:

Kullanıma uygunluk

Doğruluk (doğruluk, doğruluk)

Etkileşim yeteneği (özellikle ağ)

güvenlik

Güvenilirlik - Yazılımın belirli bir süre boyunca belirli koşullar altında performans düzeyini koruma yeteneği ile ilgili bir dizi özellik. Aşağıdaki alt özellikler (alt özellikler) ile detaylandırılmıştır:

Tamamlama seviyesi (hata yok)

Kusurlara karşı dayanıklı

geri yüklenebilirlik

kullanılabilirlik

hazır olma

Pratiklik (uygulanabilirlik) - Belirli veya amaçlanan bir kullanıcı grubu tarafından bu tür bir performansın performansı ve bireysel değerlendirmesi için gereken işin kapsamı ile ilgili bir dizi özellik. Aşağıdaki alt özellikler (alt özellikler) ile detaylandırılmıştır:

anlaşılırlık

Kullanım kolaylığı

Öğrenilebilirlik

çekicilik

Verimlilik - Yazılım performans düzeyi ile belirli koşullar altında kullanılan kaynak miktarı arasındaki ilişkiyle ilgili bir dizi özellik. Aşağıdaki alt özellikler (alt özellikler) ile detaylandırılmıştır:

Zaman verimliliği

Kaynak kullanımı

Sürdürülebilirlik - Belirli değişiklikleri (değişiklikleri) gerçekleştirmek için gereken işin kapsamı ile ilgili bir dizi özellik. Aşağıdaki alt özellikler (alt özellikler) ile detaylandırılmıştır:

Analiz kolaylığı;

değişebilirlik

istikrar

test edilebilirlik

Taşınabilirlik - Yazılımın bir ortamdan diğerine taşınabilme yeteneği ile ilgili bir dizi özellik. Aşağıdaki alt özelliklerle detaylandırılmıştır (alt özellikler):

uyarlanabilirlik

Kurulum kolaylığı (kurulum)

Birlikte yaşama (yazışma)

ikame edilebilirlik

Alt Karakteristik Yazışmalar yukarıda listelenmemiştir, ancak tüm özelliklere aittir. Bu özellik, diğer standartlar veya özelliklerle çelişki olmadığını yansıtmalıdır. Örneğin, güvenilirlik ve pratiklik ile uyumluluk.

Her nitel alt karakter (alt karakter) (örn. uyarlanabilirlik) ayrıca niteliklere bölünür. Öznitelik, bir yazılım ürününde kontrol edilebilen veya ölçülebilen bir varlıktır. Özellikler, farklı yazılım ürünlerindeki çeşitliliklerinden dolayı standartta tanımlanmamıştır.

Standart, kullanımdaki kalite performans modelini vurgular. Kullanımda olan yazılım araçlarının (bundan sonra PS olarak anılacaktır) kalitesinin ana özellikleri tavsiye edilir:

Sistem verimliliği - "Yazılım ürününün amaçlanan amacı için uygulanması"

Verimlilik - "Belirli bir harici uygulama ortamında gerçekten sınırlı kaynaklarla elde edilen PS'nin ana görevlerini çözmede verimlilik"

Güvenlik - "Yazılım paketinin işleyişinin güvenilirliği ve kullanımından insanlar, iş ve dış ortam için olası risk"

PS uygulamasının amaçlarına uygun olarak kullanıcıların gereksinimlerinin ve maliyetlerinin karşılanması

ISO 9126-2.3 standardının ikinci ve üçüncü bölümleri, sırasıyla karmaşık yazılım sistemlerinin kalite özelliklerinin dış ve iç ölçülerinin resmileştirilmesine ayrılmıştır. İlgili metriklerin kullanımına ilişkin içeriği ve genel yönergeleri ve metrik türleri arasındaki ilişkileri özetler.

ISO 9126-4 standardının dördüncü bölümü, yazılım ürünlerinin alıcıları, tedarikçileri, geliştiricileri, bakımcıları, kullanıcıları ve kalite yöneticilerine yöneliktir. Üç tür metrik kavramını tekrarlar ve PS özelliklerinin önerilen ölçüm türlerini açıklar.

Ders 9. Yazılım kalitesi

Altında yazılım kalitesi Yazılımın oluşturulması ve bakımıyla ilgilenen kullanıcıların ve uzmanların belirli ihtiyaçlarını karşılamaya uygunluğunu belirleyen yazılım özellikleri kümesini anlayacağız. Yukarıdaki formülasyondan, yazılımın tüm özelliklerinin kalitesine dahil edilmediği, yalnızca bu yazılıma duyulan ihtiyaç tarafından belirlenen bütünlüklerinin dahil olduğu anlaşılmaktadır. Bir yazılım ürününün kalitesi "kullanıma uygunluk" olarak tanımlanabilir. Kalite, geliştirme süreci tarafından garanti edilmelidir. Bir yazılım ürününün kalite kontrolü, bir yazılım ürününün bir bütün olarak kullanımına uygunluğunu teyit eden sistematik bir faaliyettir. Kalite kontrolünün amacı, bir yazılım sisteminin kalitesinin nicel ölçümlerini vermektir.

Altında Emlak (karakteristik) Yazılım, geliştirme, çalıştırma ve bakım sırasında kendini gösteren yazılımın (programlar ve belgeler) nesnel bir özelliği olarak anlaşılacaktır. Yazılım özellikleri koşullu olarak işlevsel ve yapıcı olarak ayrılabilir. İşlevsel özellikler, programın uygulanmasının özelliklerini ve özelliklerini yansıtır ve amaçlanan amacına uygunluk derecesini belirler. Programı, gerçekte nasıl çalıştığına göre karakterize ederler. Bir programın tasarım özellikleri, işlevselliğinden ve amacından az çok bağımsızdır. Programı, gerçekte nasıl tasarlandığına göre karakterize ederler.

Yazılım kalitesinin objektif bir değerlendirmesi için özellikleri nicel olarak tanımlanmalıdır. kalite seviyesi Yazılım, kalitesinin bir parçası olan ve oluşturulması, çalıştırılması ve bakımı için belirli koşullarla ilişkili olarak kabul edilen bir yazılım özelliğinin nicel bir özelliğidir. Kalite göstergeleri ile birlikte nitel (sözlü) değerlendirmeler kullanılabilir. işaretler.

Nitelikli özelliklerin sayısına göre kalite göstergeleri bekar ve kapsamlı (grup). Tek bir gösterge, özelliklerden yalnızca birine atıfta bulunurken, karmaşık bir gösterge birkaç yazılım özelliğini karakterize eder.

Yazılım kalitesi göstergelerini belirleme yöntemleri farklıdır:

- yazılım hakkında bilgi edinme yollarıyla- ölçme, kayıt, organoleptik, hesaplama;

- bilgi kaynakları tarafından- geleneksel, uzman, sosyolojik.

ölçüm yöntemi araçları kullanarak yazılımın özellikleri ve özellikleri hakkında bilgi edinmeye dayanır. Örneğin, bu yöntemi kullanarak, yazılım miktarı belirlenir - programların kaynak metninin satır sayısı ve satır sayısı - yorumlar, operatör ve işlenen sayısı, yürütülen operatör sayısı, şube sayısı. program, giriş (çıkış) noktalarının sayısı, program dalının yürütme süresi, tepki süresi ve diğer göstergeler.

Kayıt Yöntemiörneğin arızaların ve arızaların zamanı ve sayısı, kontrolün diğer modüllere aktarıldığı zaman, işin başlangıç ​​ve bitiş zamanı gibi belirli olayların kaydedildiği ve sayıldığı test veya yazılım çalışması sırasında bilgi edinilmesine dayanır.

organoleptik yöntem duyuların (görme, işitme) algılarının analizinden elde edilen bilgilerin kullanımına dayanır ve kullanım kolaylığı, verimlilik vb. göstergeleri belirlemek için kullanılır.

Hesaplama yöntemi teorik ve ampirik bağımlılıkların kullanımına (geliştirmenin ilk aşamalarında), yazılımın test edilmesi, çalıştırılması ve bakımı sırasında biriken istatistiksel verilere dayanmaktadır. Hesaplama yöntemi kullanılarak hesaplamaların süresi ve doğruluğu, tepki süresi ve gerekli kaynaklar belirlenir.

uzman yöntemi problemin mevcut yöntemlerden herhangi biri ile çözülemediği veya diğer yöntemlerin çok daha zahmetli olduğu durumlarda kullanılır. Program belgelerinin görünürlük, eksiksizlik ve erişilebilirlik, öğrenme kolaylığı, yapı göstergelerinin belirlenmesinde uzman yönteminin kullanılması önerilir. Yazılım kalite göstergelerinin değerlerinin uzman yöntemle belirlenmesi, bu sorunu çözme konusunda yetkin bir grup uzman uzman tarafından, deneyim ve sezgilerine dayalı olarak gerçekleştirilir.

sosyolojik yöntemlerözel anket-anketlerin işlenmesine dayanmaktadır.

Yazılım kalite değerlendirmesi, yaşam döngüsünün aşamalarında gerçekleştirilir ve göstergelerin isimlendirilmesinin seçimini, bunların değerlendirilmesini ve temel değerlerle karşılaştırma sonucunda elde edilen göstergelerin değerlerinin karşılaştırılmasını içerir.

Kalite göstergeleri dört seviyeli bir sistemde birleştirilir. Her bir üst seviye, bileşen olarak daha düşük seviyelerin göstergelerini içerir. Seviyelerin her birine ek göstergelerin girilmesine izin verilir.

Kalite göstergeleri grupları için bütünleyici bir değerlendirme elde etme olasılığını sağlamak için, kalite faktörleri(Seviye 1): yazılım güvenilirliği, sürdürülebilirlik, kullanılabilirlik, verimlilik, çok yönlülük (esneklik) ve doğruluk. Her kalite faktörü belirli bir kümeye karşılık gelir Kalite kriterleri(karmaşık göstergeler - 2. seviye). Kalite kriterleri bir veya daha fazla tarafından tanımlanır metrikler(3. seviye). Kalite kriteri bir metrik tarafından tanımlanırsa, metriğin düzeyi atlanır. Metrikler şunlardan oluşur: değerlendirme öğeleri(tek göstergeler - 4. seviye) metrikte belirtilen özelliği tanımlar. Metrikte yer alan değerlendirme öğelerinin sayısı sınırlı değildir.

Tüm seviyelerdeki kalite göstergeleri için (faktörler, kriterler, metrikler, değerlendirici unsurlar), 0'dan 1'e kadar tek bir değerlendirme ölçeği benimsenmiştir.

Her bir üst seviyedeki kalite göstergeleri (değerlendirme unsurları seviyesi hariç), alt seviyenin kalite göstergeleri tarafından belirlenir.

Yazılım kalitesinin ana göstergelerini göz önünde bulundurun:

1. GÜVENİLİRLİK GÖSTERGELERİ. Yazılımın yeteneğini açıklayın

Teknik araçların arızalanması, giriş verilerindeki hatalar, bakım hataları ve diğer istikrarsızlaştırıcı etkilerden kaynaklanan işletim ortamındaki sapmalar durumunda program belgelerine uygun olarak belirtilen işlevleri yerine getirmek için belirli uygulama alanları:

1.1. operasyonel sürdürülebilirlik. Donanım arızaları, giriş verilerindeki hatalar ve bakım hatalarından kaynaklanan sapmaların meydana gelmesinden sonra programın devamını sağlama yeteneği;

1.2. Çalışma kapasitesi. Programın, teknik arızaların olmadığı durumlarda program belgelerine uygun olarak belirtilen modlarda ve işlenmiş bilgi hacimlerinde çalışabilme yeteneği.

2. DESTEK GÖSTERGELERİ. teknolojik özellikleri

program ve program belgelerindeki hataları ortadan kaldırmayı ve yazılımı güncel tutmayı kolaylaştıran hususlar:

2.1. yapısallık. Programın birbiriyle ilişkili tüm bölümlerinin "sıralama", "seçim", "tekrar" mantıksal yapılarını kullanarak tek bir bütün halinde düzenlenmesi;

2.2. Tasarımın sadeliği. Algılama ve anlama açısından en akılcı şekilde modüler bir yapı-program oluşturmak;

2.3. görünürlük. Kaynak modüllerin en kolay algılanan biçiminde kullanılabilirliği ve sunumu, ilgili program belgelerinde tam açıklamaları;

2.4. tekrarlanabilirlik. Yazılımda yer alan standart tasarım çözümlerinin veya bileşenlerinin kullanım derecesi.

3. UYGULAMA KOLAYLIĞI GÖSTERGELERİ. Yazılımın özelliklerini açıklayın

Çözülmekte olan görevlerin niteliği ve bakım personelinin kalifikasyonu için gereklilikler dikkate alınarak, yazılımın minimum işçilik maliyetiyle hızlı bir şekilde geliştirilmesine, uygulanmasına ve işletilmesine katkıda bulunmak:

3.1. Geliştirme kolaylığı. Politika belgelerinin ve programın, programın bir bütün olarak ve bölümlerinin işleyişinin mantığının anlaşılmasını kolaylaştıran bir biçimde sunulması;

3.2. Operasyonel politika belgelerinin mevcudiyeti. Operasyonel program belgelerinde programla kullanıcı etkileşiminin açıklamasının netliği, netliği ve eksiksizliği;

3.3. Kullanım ve bakım kolaylığı. Veri işleme sürecinin ve sonuçların sunulma biçimlerinin çözülmekte olan görevlerin doğasına uygunluğu.

4. PERFORMANS GÖSTERGELERİ. Ekonomik, bilgi işlem ve insan kaynaklarını dikkate alarak, kullanıcının veri işleme ihtiyacının memnuniyet derecesini karakterize ederler:

4.1. otomasyon seviyesi. Programın işlevsel yapısının rasyonelliğini, onunla kullanıcı etkileşimi ve bilgi işlem kaynaklarının kullanımı açısından dikkate alarak, veri işleme sürecinin işlevlerinin otomasyon düzeyi;

4.2. Geçici verimlilik. Programın belirli gereksinimleri karşılayan bir zaman aralığında belirli eylemleri gerçekleştirme yeteneği;

4.3. kaynak yoğunluğu. Yazılımın çalışması için gereken minimum bilgi işlem kaynakları ve bakım personeli sayısı.

5. EVRENSELLİK GÖSTERGELERİ. Yazılım uyarlanabilirliğini karakterize edin

kapsam veya diğer çalışma koşullarındaki bir değişiklikten kaynaklanan yeni işlevsel gereksinimlere:

5.1. Esneklik. Yazılımı çeşitli uygulama alanlarında kullanabilme;

5.2. Hareketlilik. Benzer bir sınıftaki bir bilgisayarda önemli ek işçilik maliyetleri olmadan yazılımı kullanma imkanı;

5.3. değiştirilebilirlik.Çalışma sırasında programda gerekli değişiklik ve iyileştirmelerin kolaylıkla yapılabilmesini sağlamak.

6. DOĞRULUK GÖSTERGELERİ. Yazılım uyumluluğu derecesini karakterize edin

Görev Tanımında belirlenen gereksinimler, veri işleme gereksinimleri ve sistem genelindeki gereksinimler:

6.1. Uygulamanın eksiksizliği. Belirtilen yazılım işlevlerinin uygulanmasının eksiksizliği ve yazılım belgelerindeki açıklamalarının yeterliliği;

6.2. Tutarlılık. Program belgelerinin ve program metninin çeşitli bölümlerinde aynı nesnelerin, işlevlerin, terimlerin, tanımların, tanımlayıcıların vb. açık, tutarlı açıklaması ve kullanımı;

6.3. mantıksal doğruluk. Sistem genelinde gereksinimlere sahip bir görevi gerçekleştirirken veri işleme sürecinin işlevsel ve yazılım uyumluluğu;

6.4. Doğrulama. Test sırasında olası program yürütme yollarının kontrol edilmesinin eksiksizliği.