V. İlyin.

TopSBI Firmasının Kaliteli Hizmet Başkanı

"Eğer bir şey yaparsan

yanlış - gerekli değil
doğru sonucu bekleyin."

Çin halk bilgeliği

Kalite güvence sorunlarına kapsamlı çözüm yazılım araçları belirli bir kalite yönetim sisteminin (Kalite Yönetim Sistemi - KYS). Dünya pratiğinde en yaygın olanı, uluslararası standartların gerekliliklerine dayanan sistemdir. ISO serisi 9000, çünkü yazılım sistemleri de dahil olmak üzere en genel gereksinimleri tam olarak tanımlar ve bu nedenle genel olarak BT alanındaki birçok endüstri modeli ve standardına uymak için gerekli olan süreçlerin başlangıç ​​olgunluğunu önceden belirler. .

Ancak, bir kalite sisteminin başlatılmasının ve başarılı bir belgelendirmenin kaliteli bir ürünün piyasaya sürülmesini garanti edip etmediği sorusu dürüstçe cevaplanmalıdır - "hayır".

ISO 9000'in “harika bir fikir” olduğunu vurgulayan Gartner Group, ISO 9001 sertifikasının kaliteye giden yolda yalnızca bir başlangıç ​​noktası olarak görülmesini tavsiye ediyor (1).

Kalite sisteminin bir tür "iskeletini" oluşturur ve bu sistemi "kaslar" (zaten özel, endüstri standartları ve CMM gibi metodolojilere dayalı profesyonel içerik) ile doldurmak, büyüyen pazarı karşılayan bir kalite seviyesi sağlayabilir. Gereksinimler.

Yukarıdakilerle bağlantılı olarak, hem metodolojik hem de pratik açıdan, kalite yönetimi alanındaki birçok uzman, BT şirketlerinin gelişimi için aşağıdaki gibi bir strateji oluşturmanın uygun olduğunu düşünmektedir:

İlk olarak, ISO 9001: 2000 modeline dayalı bir KYS geliştirin ve uygulayın. (Sonuçta, şu anda SW-CMM'nin 4. ve 5. seviyelerinde olan çoğu şirket, önce süreçlerini ISO modeline uygun hale getirdi. Uygulamada görüldüğü gibi, bu en iyi seçenek KYS'nin gelişimini yönetmek ve riskleri azaltmak açısından).

Ve ancak o zaman SW-CMM modelinin ve ayrıca gerekirse CMMI modelinin temel süreçlerini geliştirmeye ve uygulamaya başlayın.

Bunun nasıl gerçekten doğru olduğunu anlamak için bu modelleri karşılaştıralım.

1. Başvuru sahiplerinin gözden geçirilmesi.

gerçekleştireceğiz kısa inceleme bir BT şirketi tarafından iş süreçlerini optimize etmek için kullanılabilecek en popüler standartlar.

ISO 9001. En popüler ve özellikle Avrupa'da ISO 9001 (2)'dir.

Aynı zamanda, metodik olarak, yapı disiplinine tam olarak uygun olarak karmaşık sistemler, ISO 9001 standardı, bir yandan inşaat organizasyon sistemi"yukarıdan aşağıya": işletmenin hedeflerinden ve politikalarından - organizasyonel yapıya ve iş süreçlerinin oluşumuna ve diğer yandan - organizasyon sisteminin ölçüm ve iyileştirme mekanizmaları yoluyla tekrarlanan gelişimine.

Daha basit bir ifadeyle, "kalite", ISO 9000 serisi standartlara göre, tüketicilerin doğrudan gereksinimlerini ve gizli beklentilerini karşılayan bir üreticiden ürün aldığı bir durumdur. Bu nedenle, kalite yönetimi, ISO 9000'e uygun olarak sözde kullanımını içerir. "Süreç yaklaşımı", en optimal "dönüşüm-süreçler" zinciri modellendiğinde ve uygulandığında, tüketici ihtiyaçlarının üretici tarafından algılanmasını ve herhangi bir üründe bozulma olmadan somutlaştırılmasını sağlar.

Bu iyi bilinen ISO 9000 standartları serisi, birçok yazılım kuruluşu tarafından başarıyla kullanılmıştır. Yeni bir versiyon Bu serinin standartları 2000 yılında yayınlandı ve halihazırda süreç yaklaşımı, analiz ve ölçüm, süreçlerin iyileştirilmesi, CMM modelinden ödünç alınan ve daha önce ISO 9000'in önceki sürümlerinde bulunmayan gibi kavramları içeriyor. bu dizinin evrenseldir - belirli bir endüstriye odaklanmazlar, BT alanının özelliklerini dikkate almazlar ve bu anlamda, elbette, somutlaştırma derecesi açısından, belirgin şekilde daha düşüktürler. SMM. Ek olarak, ISO 9000, herhangi bir uygunluk derecelendirmesi (seviyesi) anlamına gelmez ve bu nedenle, bir organizasyonun "gerçek" yeteneklerini ve buna bağlı olarak - daha fazla geliştirme yollarını belirlemeyi zorlaştırır.

CMM(Yetenek Olgunluk Modeli), Carnegie Mellon Üniversitesi'ndeki (ABD) Yazılım Mühendisliği Enstitüsü tarafından geliştirilmiştir ve geliştirme süreçleri için bir olgunluk modelini tanımlar. yazılım işletmelerde (3). Bu model çerçevesinde, her şirket için, yazılım geliştirme sürecinin ulaşılan kalitesini gösteren belirli bir seviye (olası beşten biri) karşılaştırılabilir. Bu standartlar öncelikle ABD Savunma Bakanlığı için yüklenicilerin seçim sürecini kolaylaştırmak için geliştirildiğinden, geliştirmenin teknik yönleri daha az ele alınırken yazılım proje yönetimi süreçlerine odaklanırlar.

SW-CMM v.1.1'de (Yazılım için Yetenek Olgunluk Modeli) 316 Temel Uygulama vardır. Temel Uygulamalar, işletmede uygulanması gereken ve süreç değerlendirme ekibinin nelere dikkat edeceğidir. Bu alanda birleşmişlerdir - Temel Uygulama Alanları (KPA) - bu zaten ortaklaşa gerçekleştirildiğinde belirli bir dizi hedefe ulaşılmasına yol açan birbiriyle ilişkili bir dizi süreçtir.

CMMI(Yetenek Olgunluk Modeli Entegrasyonu) - CMM modelinin daha da geliştirilmesi. CMMI-SE / SW Sürüm 1.02'de (Sistem Mühendisliği / Yazılım Mühendisliği için CMMI), geliştiriciler için belki de en kabul edilebilir olanı yazılım sistemleri, - Temel Uygulamaların sayısı şimdiden 417'ye ulaştı.

Temel Uygulamalardaki artış, CMMI geliştirmenin amacı ile ilgilidir - model, çeşitli endüstri CMM modellerinin kullanılmasıyla ilgili sorunlardan kaçınmaya yardımcı olmalıdır.

(1991'den beri, CMM'ler çeşitli uygulamalar için geliştirilmiştir, en önemlileri şunlardır:

Yazılım için Yetenek Olgunluk Modeli (SW-CMM)
- sistem yeniden yapılandırması için süreç olgunluk modeli (Electronic Industries Alliance Interim Standard - EIA / IS 731)
- entegre ürün geliştirme süreçlerinin olgunluk modeli Entegre Ürün Geliştirme Yeteneği Olgunluk Modeli - IPD-CMM)

Bu modellere dayanarak, CMMI inşa edildi. Bu modellerin en iyilerini özümsemiş, birçok modelin varlığı nedeniyle bazı kavramların yorumlanmasındaki belirsizliği ortadan kaldırmıştır - bu nedenle önemli uygulamaların sayısı önemli ölçüde artmıştır).

Bunun çok daha "ağır" bir model olduğu ortaya çıktı - bkz. Pirinç. bir dahası, pratikte henüz yeterince test edilmemiş (sadece 2002'de çıktı). Bu bağlamda, bence, modeli uygularken, hem yazılım geliştirme hızındaki haksız kayıplarla hem de uygulanan KPA'nın işletilmesi (ve desteklenmesi) için işgücü maliyetlerinde eşzamanlı bir artışla ilişkili olası büyük riskler vardır. - görmek. Şekil 1. Bana göre, BT şirketlerinin üç farklı profilinde bir KYS oluşturmuş bir uygulayıcı olarak, CMMI modelinin gerekli ve yeterli - BT şirketinin personeli (ve bunlar) arasında açıkça dengesiz olduğu görülüyor. , kural olarak, çoğunlukla "kod sanatçıları") bu kadar çok sayıda kontrollü düzenlemeyi "yürütmeyi kabul etmeyecek" ("Potemkin köyü" inşa etme riski çok yüksek!)

Pirinç. 1 CMM ve CMMI modellerinde KPA bileşiminin karşılaştırılması.

Ek olarak, CMMI için Değerlendirme, yetkilendirildiği için önemli ölçüde daha pahalı olacaktır. SEI Baş Değerlendirici"Şimdiye kadar bunlardan çok azı olacak ve bu hizmetler CMM modeline uygunluğun değerlendirilmesinden çok daha pahalı olacak.

Ayrıca, kalite yönetimi alanındaki birçok yabancı uzman (şu anda görüşlerine tamamen katılıyorum), küçük ve orta ölçekli kuruluşlarda uygulama için yararlılığı bağlamında CMMI hakkında oldukça şüphecidir (bunlar, sadece Rusya için tipiktir). Hatta bir süre sonra SEI'nin ya uyarlanmış bir SW-CMM v.2 yayınlaması ya da benzer adımlar atması gerektiğine dair bir görüş var. Şunlar. piyasa modeli kabul etmezse ve bu ön koşullar bu yazının yazıldığı sırada zaten mevcutsa, SEI'nin piyasa gereksinimlerine uyum sağlaması gerekecektir.

Yukarıdakilerle bağlantılı olarak, tüm bu temel KYS modellerinde daha önce bahsedilen gerekli ve yeterli dengesinin analiz edilmesi uygun görünmektedir.

Aşağıdaki koordinatlarda çizelim (bkz. Pirinç. 2) :

geliştirme süreçlerinin düzenleme derecesi - hadi bu kavramı belirleyelim - RP,

planlanan sonuçlara ulaşma olasılığı - hadi bu kavramı belirleyelim - PQ.

İncirde. 2, bu modellerin gereksinimlerini yazılım sistemlerinin geliştirilmesi ve uygulanmasına sokma uygulamasının sonuçlarına dayanarak yazar tarafından yürütülen, düzenleme derecesi dengesi ve planlanan sonuçlara ulaşma olasılığı konusunda uzman bir değerlendirmeyi gösterir ( yazılım).

Matematiksel olarak, türevin büyüklüğü: F (Q) = dPQ \ dRQ(kaliteye ulaşmada verimlilik artışı dPQ gereksinimlerin yerine getirilmesini desteklemek için çalışma süresinin maliyetinde bir artış ile dRQ), sırasıyla aşağıdaki sırayla azalır : ISO 9000, CMM, CMMI.

Bu nedenle, Şekil. 2 açık ve basit bir şekilde açıklar:

ISO 9000 modelinin popülaritesi,

metodolojinin doğruluğu: önce ISO ve ancak o zaman gerekirse CMM,

CMMI modelinin etkinliği hakkında bazı şüpheler.

Pirinç. 2 Düzenleme derecesi ile planlanan sonuçlara ulaşma olasılığı arasındaki dengenin analizi (yazarın uzman değerlendirmesine göre)

Şimdi BT şirketlerinde yaygın olarak kullanılan ve KYS uygulama pratiğine ilişkin sorunları analiz ederken aşağıda bahsedilecek olan bir kılavuzu daha ele alalım.

Bu PMBoK(Kılavuz Proje Yönetimi Bilgi Gövdesi) proje projesi Proje yönetimi alanında birikmiş bilgiyi özümseyen Yönetim Enstitüsü. Belgenin son versiyonu 2000 yılında yayınlandı ve aynı zamanda Amerikan Standardizasyon Enstitüsü ANSI standardı statüsünü aldı (ANSI ve IEEE standartları resmi olarak Amerikan olarak kabul edilse de, çoğu fiili olarak uluslararası niteliktedir). PMB®K'in önemli bir özelliği, BT gibi belirli konu alanlarına atıfta bulunmadan proje yönetimini genel anlamda ele alması ve bu nedenle bağımsız olarak uygulanamamasıdır - aşağıda bunun ISO 9000 ile birlikte kullanıldığında ne gibi bir etki yarattığını ele alacağız.

Şimdi, zaten popüler olan ISO 9001: 2000 standardının gereksinimlerinin, giderek daha popüler hale gelen CMM modelinin genel özellikleriyle nasıl ilişkili olduğunu ele alalım. {3}- santimetre. Pirinç. 3.

Pirinç. 3. CMM'nin genel özellikleri ile ISO 9001: 2000'in unsurları arasındaki uyum

Yukarıda bahsedildiği gibi SMM'nin her seviyesi, bir set ile karakterize edilir. kilit süreçlerin alanları - KPA (Key Process Areas) - santimetre. Şekil 3.İçindeki tüm hedeflere ulaşmak KPA belirli bir seviye için, CMM organizasyonun o seviyeye uygunluğunu belirler. En az bir hedef en az bir ise KPA CMM düzeyine ulaşılmadığı için kuruluş bu CMM düzeyini karşılayamaz. KPAüç kategoriye ayrılabilir: genel müdürler , örgütsel ve sağlama (santimetre. Pirinç. 4).

CMM, yazılım geliştirme ile ilgili tüm süreçleri tanımlamaz; sadece SMM seviyesine ulaşmak için gerekli olanları vurgular ve bunlar KPA... Her biri KPA 5 Ortak Özelliklere ayrılmıştır: Gerçekleştirilecek yorum; Gerçekleştirme kabiliyeti; Gerçekleştirilen Faaliyetler; Ölçüm ve Analiz; Uygulamanın Doğrulanması

Genel özellik " Yapılan İşlemler " hedeflere ulaşmak için gerçekleştirilmesi gereken eylemleri açıklar KPA diğer dört genel özellik, süreci sürecin bir parçası yapan biçimsel faktörleri tanımlar. organizasyon kültürü... Hepsinin eksiksiz yerine getirilmesi anahtar uygulama tüm ortak özelliklerin, hedeflere ulaşılmasını sağlar KPA... Temel işletim uygulamaları, bir iş akışının (veya bir süreç unsurunun veya bir altyapının parçasının) nasıl olması gerektiğini tanımlar, ancak bunu başarmanın bir yolunu tanımlamaz ( özel teknolojiler veya teknikler), ancak bazı teknikler için genel yönergeler verilmiştir. İçin farklı koşullar aynı sonuca farklı yollarla ulaşılabilir. daha doğrusu Genel İlkeler somut eylemden çok iş.

Ortak özelliklerin sıralı uygulanması, aslında iş süreçlerini iyileştirme döngüsünü uygular (İş Süreci İyileştirme - BPI-santimetre. Pirinç. 5.), yani iş süreçlerinin sürekli iyileştirilmesi (BP).

Pirinç. 5. CMM modeline ve ISO 9000: 2000'e göre iş süreçlerinin sürekli iyileştirme döngüsü.

Mümkün olan en kısa sürede bir uygunluk belgesi alma arzusu, danışmanlık şirketlerini ve kalite yönetimi uzmanlarını, listelenen tüm üst düzey modellerin gereksinimlerinin esnekliğini ve çerçevesini kendi "paralı asker" amaçları için kullanmaya zorlar.
Olayların bu zorlamasının bir sonucu olarak, örneğin ISO 9000: 2000'e göre bir sertifika almış bir kuruluş, şirketin yapması gereken tüm süreçlere değil, ISO 9001'e uyum için yalnızca gerekli minimum süreçlere sahiptir. etkili bir şekilde işlev - bkz. Pirinç. 2... Ek olarak, süreçlerin ayrıntı düzeyi, süreçler içinde neler olup bittiğinin ve süreç içindeki hangi görevlerden kimin sorumlu olduğunun net bir şekilde anlaşılması için yeterli olmayabilir.
V en iyi senaryo sadece birkaç test projesi yeni prosedürlerden geçti ve bir süre sonra bunların düzeltilmesi ve eklenmesi gerektiği ortaya çıktı. Genellikle, KYS'nin onaylanmasından hemen sonra, harcanan zamanı unuturken, bir sonraki denetim denetimine kadar süreçler unutulur. finansal kaynaklar ve personelin coşkusu.
Gerçekten de, bağımsız bir denetçi olarak hareket ederken, sürecin kabul edilen ayrıntı düzeyinin, şirketin KYS'sinin etkin işleyişi için açıkça yeterli olmadığını kanıtlamak çok zordur. Ancak ISO 9000'e göre denetim için ayrılan süre içinde bunun aksini kanıtlamak son derece zordur (bu, denetçiye karşı çıkıldığında çok başarılı bir şekilde kullanılabilir). Uygulama, 3. olgunluk düzeyinde bile (ISO 9000'e dayalı süreçlerin yanı sıra) etkili süreçleri hızlı bir şekilde oluşturmanın imkansız olduğunu göstermektedir.
Bunu başarmak için, seçilen modelin gerekliliklerini göz önünde bulundurarak süreçleri basitçe tanımlamak yeterli değildir. En büyük zorluk, yapmanız gereken organizasyon içindeki üretim kültürünü yeniden tasarlamak .

Ve bunu liderliğin güçlü iradeli bir kararıyla yapmak imkansızdır. Bu nedenle CMM'de tanımlanan yaklaşım, ISO 9000-cm modellerinden daha uygulanabilir ve gerçekçidir. Pirinç. 5.

Şimdi pratikte her iki modelle uyumlu bir KYS'yi nasıl oluşturabileceğinizi ele alalım.

CMM yazarlarının kendilerinin (4) değerlendirmesine uygun olarak, ISO 9000: 2000 gereklilikleri ile temel CMM süreçlerinin kapsam derecesinin bir uzman değerlendirmesi, aşağıda gösterilmiştir. Şekil 6.

Gerçek değerlendirme onlar tarafından iki koordinatta gerçekleştirildi:

geliştirme süreçlerinin (SWP) sürdürülebilirlik derecesi (% olarak) CMM içindeki olgunluk düzeyiyle - " güvenlik ";

ISO 9000: 2000 - " tarafından sağlanan bu tür kullanılabilirliğin fizibilite derecesi (% olarak) fırsat".

görüldüğü gibi Pirinç. 6, ISO 9000: 2000 gereksinimleri yaratır gerçek fırsatüst (CMM Seviye 5) SWP olgunluk seviyesine bile ulaşmak için.

Bununla birlikte, SWP'nin en az üçüncü (CMM Seviye 3) seviyesinin halihazırda olgunluğunun sağlanması anlamında, ISO 9000: 2000 modeline göre KYS'nin biraz değiştirilmesi gerekiyor - yani, iki organizasyon prosedürü daha geliştirmek ve uygulamak için ( Organizasyon süreci tanımı ve odaklanma) ve prosedür Genel Müdürlük (Entegre yazılım yönetimi ), içeriği herhangi bir bilişim şirketi için zor olmayan.

Ancak daha ileri gitmek mümkündür ve gereklidir (CMM Seviye 4) - örneğin, yazarın bu makaleye ilişkin değerlendirmesi (aynı koordinatlarda - kullanılabilirlik ve yetenekler), ISO 9000'e göre KYS'ye karşılık gelen parantez içinde gösterilir: KYS'nin süreç ortamının, yukarıda bahsedilen diğer standardın gerekliliklerine uygun olarak süreç proje yönetimi ile desteklendiği 2000 modeli PM Kitap- bu, bu türlerin bile olgunluğunu önemli ölçüde artırmanıza yardımcı olacaktır. SWP, nasıl:

Projelerin ilerlemesini izleme (Yazılım proje takibi ve gözetimi);

• Projelerin planlanması (Yazılım proje planlaması);

Genel yazılım yönetimi (Entegre yazılım yönetimi);

Nicel süreç yönetimi.

Pirinç. 6. ISO 9000: 2000 gereklilikleri ile kilit CMM süreçlerinin kapsam derecesinin uzman değerlendirmesi

görüldüğü gibi Şekil 6., içinde belirtilen ilkeler açısından CMM modeli, ISO 9001: 2000 standardına göre inşa edilen ve proje yönetim süreçleri ile tamamlanan KYS'ye çok yakındır. PM BoK..

yapmamak için ekstra iş ISO 9000'e göre eşzamanlı sertifikasyon ve ardından CMM'ye göre değerlendirme ile, üretim süreçlerinizi tanımlarken, bunların arasında gerekli olan her şeyi dahil etmenizi (veya belki sınırlandırmanızı - sonuçta bu bir BT şirketi içindir ve üretim süreçleri vardır!) CMM KPA modelinde. Böylece, şirket aynı zamanda:

gereksinimleri karşılar ISO 9001: 2000 süreç yaklaşımının uygulanması hakkında;

gerekli tüm belgeler CMM süreçler ( KPA);

aynı zamanda bir dizi önemli gereksinimi uygular ISO 9001: 2000 nasıl:

metrik tabanlı süreç kontrolü (Kantitatif süreç yönetimi);

Taşeron yönetimine dayalı tedarikçi yönetimi ( Yazılım taşeron yönetimi );

y'ye göre Tüketici gereksinimlerinin analizi yönetim gereksinimleri (İhtiyaç Yönetimi );

dayalı insan kaynakları yönetimi Personel eğitim programları (Eğitim programı );

dayalı iletişim yönetimi Resmi model oluşturma organizasyonel süreçler ( Organizasyon süreci tanımı );

iyileştirme mekanizmasını başlatır (Planla-Uygula-Kontrol Et -Eylem) açıklanan tüm süreçler (SWP) beşinin de sıralı uygulanması yoluyla Ortak özellikler-santimetre. Pirinç. 5.

Bu nedenle, bir BP olarak KPA CMM'yi kullanırsanız ve yazılım sistemlerinin geliştirilmesi için proje yönetimi prosedürlerinin gereksinimlerini kullanırsanız PM BoK, o zaman bu şekilde inşa edilen KYS şu şekilde tahmin edilebilir: CMM Seviye 4 - cm. Pirinç. 7.

Pirinç. 7. ISO 9000 ve PM BoK 2000 kılavuzuna göre KYS modelini kullanırken CMM Seviye 4'e ulaşma şeması.

Sonuç olarak, açıklık nedenleriyle (yazar tarafından stilize edilmiştir), ISO 9000 ve CMM modellerinin tutarlı bir şekilde uygulanmasıyla bir BT şirketinin KYS'sinin işleyişine ilişkin bir şema sunuyorum - bkz. Pirinç. sekiz.

Pirinç. 8. ISO 9000 ve CMM modellerinin sıralı uygulamasıyla KYS'nin işleyişinin şeması (yazar tarafından stilize edilmiştir)

Burada hem CMM'nin hem de ISO 9001: 2000'in kendi içlerinde sürekli iyileştirme için sadece araçlar olduğunu anlamak önemlidir.

Bu nedenle, ISO 9001:2000 standardına göre belgelendirme ve belgenin teyidi, şirket proseslerinin kalitesinin büyümesine katkıda bulunmalıdır, burada proseslerin kalitesinin büyümesini değerlendirme kriteri şirketin yeni bir seviyeye girişidir. BPI, yani, değerlendirmeleri zaten modele dayalıdır, yani CMM {3}.

Edebiyat

"Yazılım kalitesinin değerlendirilmesi", V. Lipaev, Sinteg, 2001

ISO 9001: 2000. Kalite yönetim sistemi. Gereksinimler.

Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Yazılım için Yetenek Olgunluk Modeli (SW-CMM), sürüm 1.1. // CMU / SEI-93-TR-024, - Februaru, 1993.

Dipnot: Yazılım geliştirme süreçlerini iyileştirmek için muhtemelen en iyi bilinen metodolojinin altında yatan fikir yelpazesi - CMM ayrıntılı olarak incelenmiştir. SMM'nin mantığı ve yapısı analiz edilir. HMM'nin daha önce çalışılan süreç modelleriyle bağlantısı gösterilmektedir.

İçinde yerleşik harika bir pratik araç süreç yaklaşımı etkinliğin açıklamasına tasarım organizasyonu , özellikle, gelişen organizasyon Bilgi sistemi, SMM metodolojisini gösterir. CMM, kabaca "yönetim sistemi olgunluk modeli" anlamına gelen Capability Maturity Model'in kısaltmasıdır. Literatürde CMM daha çok örgütsel olgunluk modeli olarak anılır ve ben de bu geleneği takip edeceğim.

SMM'nin ortaya çıkış tarihi aşağıdaki gibidir. 80'lerin sonlarında. geçen yüzyılda, ABD Savunma Bakanlığı, Yazılım Mühendisliği Enstitüsü'ne 1eng emretti. SEI - Yazılım Mühendisliği Enstitüsü Carnegie Mellon Üniversitesi, yazılım geliştirme projelerinde taşeron seçimi için bir kriterler sistemi oluşturmaya çalışıyor. Çalışma 1991 yılında tamamlandı ve sonuç CMM modeli oldu. Modelin herhangi bir finansal, ekonomik, politik, organizasyonel içerik içermediğine dair derhal bir çekince yapılması gerekmektedir. Seçim kriterleri taşeron ve gizli çalışmaya kabul edilme olasılığı kriterleri (muhtemelen bu tür görevler belirlenmemiştir). Sadece potansiyel bir alt yüklenicinin yazılım sistemleri geliştirme kabiliyetini tanımlayan kriterlerden bahsediyoruz.

CMM yapısı

Modelin yaratıcıları, bir kuruluşun (yetenek) olgunluk olarak adlandırılan kaliteli iş yapma yeteneğini değerlendirmek için kuruluşun süreçlerini temel aldı. Ardından, daha sonra birçok BT uzmanı (ve belki de çoğu) tarafından adil olarak kabul edilen ve tanınan birkaç önemsiz varsayımda bulundular.

varsayım 1... Niteliksel olarak farklı olgunluk seviyeleri vardır tasarım organizasyonu gelişmekte Bilgi sistemi(HMM modelinde bu tür beş seviye vardır).

varsayım 2... Herhangi bir geliştirme kuruluşu, daha yüksek bir olgunluk düzeyine geçmekle ilgilenir (yalnızca Savunma Bakanlığı ile sözleşmeler için mücadele etme şansını artırmak için değil, aynı zamanda kendini geliştirmek için).

varsayım 3... Geçiş sadece sırayla bir sonraki seviyeye mümkündür. Seviyeyi "atlamak" imkansızdır (daha doğrusu, kuruluş için riskler önemli ölçüde artar).

Böylece, seviyeler, organizasyonun yükseldikçe üzerinde yükseldiği bir "merdiven" oluşturur. kendi gelişimi... Her seviye, organizasyonun süreçlerinin belirli bileşimi ve özellikleri ile karakterize edilir. SMM "seviye merdiveni" yaygın bir kabul ve dağıtım kazanmıştır. Göründüğü şey bu.

Seviye 1 "Başlangıç"... Bir bütün olarak üretim süreci, her seferinde belirli bir proje için yaratılıyor ve hatta bazen kaotik olarak nitelendiriliyor. Sadece birkaç süreç tanımlanmıştır ve projenin başarısı bireylerin çabalarına bağlıdır.

Seviye 2 "Tekrarlanabilir"... Ana proje yönetimi süreçleri oluşturulmuştur, bu da maliyetleri izlemenize, çalışma programını ve oluşturulanların işlevselliğini izlemenize olanak tanır. yazılım çözümü... Benzer uygulama geliştirme projelerinde önceki başarıları tekrarlamak için süreç disiplini oluşturdu.

Seviye 3 "Tanımlanmış"... Üretim süreci, hem yönetim çalışmaları hem de tasarım için belgelenir ve standartlaştırılır. Bu süreç, kuruluşun standart üretim sürecine entegre edilmiştir. Tüm projeler, kuruluşun standart üretim sürecinin onaylanmış özelleştirilmiş bir versiyonunu kullanır.

4. Seviye "Yönetilen"... Üretim sürecinin ayrıntılı nicel göstergeleri ve oluşturulan ürünün kalitesi toplanır. Hem üretim süreci hem de ürünler nicelleştirilir ve izlenir.

Seviye 5 "Optimizasyon"... Sürekli süreç iyileştirme nicel yöntemlerle elde edilir geri bildirim içindeki ileri fikir ve teknolojilerin süreci ve uygulanması ile.

Gevşekliğe rağmen, yukarıdaki tanım sezgisel olarak çoğu zaman sakıncalı değildir. Ayrıca, deneyimli uzmanlar, geçişlerin neden yalnızca bitişik bir seviyeye mümkün olduğunu ve ayrıca neden genellikle böyle bir geçiş için çabalamaya değer olduğunu anlıyorlar. Aynı zamanda, HMM modeli, böyle bir yaklaşımın herhangi bir nicel veya en azından resmi doğrulamasını içermez, ancak bu, onun esasından en ufak bir eksiltmez.

Ayrıca, dedikleri gibi, bir teknoloji meselesidir. Modelin yapısı belirlenir (Şekil 7.1), tanımlar verilir ve her aşamada her süreci doğru bir şekilde tanımlamak için özenli bir çalışma başlar. Yapılanların pratik değerini anlamak için bu yolun bir kısmından geçeceğiz.

Pirinç. 7.1.

İncirde. 7.1 aşağıdaki kavramlar vardır.

Anahtar süreç grubu... (Paulk ve diğerleri, 1995)'de belirtildiği gibi, "her bir anahtar süreç grubu, üretimin verimliliğini artırmak için önemli olan bir dizi hedefe ulaşılan uygulamanın bir sonucu olarak bir ilgili faaliyetler bloğunu tanımlar. süreç. Örneğin, bir grup anahtar süreç için." İhtiyaç Yönetimi"(bkz. Şekil 7.2) amaç, bir yazılım geliştirme projesinin gereksinimlerini müşteri ve geliştirici arasında uyumlu hale getirmektir."

CMM değil bireysel süreçler... Bunun yerine, G/Ç açısından birbiriyle ilişkili olan ve yapı süreçleri için kaynak malzeme görevi gören, temel uygulamalar (aşağıya bakınız) adı verilen ayrı faaliyetler vardır. CMM, süreçlerin nasıl yapılandırıldığı, yani temel uygulamaların mantıksal sıralarda nasıl birbirine bağlandığı konusunda rehberlik sağlamaz. Temel uygulama kümelerine çekirdek süreç grupları denir.

Pirinç. 7.2.

CMM'deki kilit süreç grupları, olgunluk seviyelerine eşlenir (Şekil 7.2), yani seviyedeki tüm uygulamalar yalnızca birbirleriyle etkileşime girer ve diğer seviyelerdeki uygulamalarla etkileşime girmez. Bu, belirli bir seviyede tüm süreçlerin tam performansını garanti etmemize ve dolayısıyla seviyeyi organizasyonun gelişiminin tamamlanmış aşamasıyla ilişkilendirmemize izin verir.

"Anahtar" sıfatı, süreç grupları belirli bir olgunluk düzeyi açısından önemli olmayan, yani bu düzeydeki hedeflere ulaşılmasıyla ilgili olmayan (yani, bir dizi uygulama) (aşağıya bakınız). CMM her şeyi kapsamaz süreç grupları Yazılımın geliştirilmesi ve bakımı ile ilgili. Yalnızca üretim sürecinin üretkenliğinin temel belirleyicileri olarak tanımlanan grupları tanımlar.

Hedefler... SMM'deki hedefler, süreçlerle değil, kilit süreç gruplarıyla ilişkilidir. Yukarıda belirtildiği gibi, hedeflere temel uygulamaların uygulanması yoluyla ulaşılır. CMM'de bir hedefe ulaşmak, öncelikle temel uygulamaları tamamladıktan sonra istenen sonucun elde edilmesi ve ikinci olarak oldukça kararlı olduğu anlamına gelir. Anahtar süreç grubunun hedeflerine ulaşma şekli, projedeki farklılıklara bağlı olarak projeden projeye farklılık gösterebilir. konu alanı veya çevre.

Bu hedefler tüm projeler için gerçekleştiriliyorsa, bu, organizasyonun üretim sürecinin olgunluk düzeyine ulaştığı anlamına gelir. bu grup anahtar süreçler.

Bölüm... Bölümler (her düzeyde beş tane vardır ve bunlar her zaman aynıdır), ilgili düzeyde uygulanması gereken kilit süreç gruplarının özelliklerini temsil eder. Bu özellikler, süreçlerin nasıl uygulandığını ve kuruluşta ne kadar yasallaştırıldığını, yani resmi olarak onaylandığını ve kurumsal prosedürler, politikalar ve diğer süreçlerle tutarlı olduğunu açıklar. Bunlar beş bölümdür.

Yerine getirilmesi gereken yükümlülükler

Sürecin yerleşik ve istikrarlı olmasını sağlamak için kuruluşun yapması gereken eylemleri tanımlayın. Uyum yükümlülükleri genellikle kurumsal politikaların oluşturulması ve üst yönetimin desteği ile ilgilidir.

Önkoşullar

Üretim sürecinin yetkin bir şekilde uygulanması için bir proje veya kuruluş tarafından karşılanması gereken ön koşulları tanımlayın; genellikle kaynaklara atıfta bulunur, Örgütsel yapılar ve gerekli eğitim.

Yapılan işlemler

"Yapılan işlemler" bölümü, bu düzeyde gerçekleştirilmesi gereken önemli işleri açıklar. Gerçekleştirilen operasyonlar tipik olarak planlar yapmayı ve belirli operasyonları yürütmeyi, iş yapmayı ve izlemeyi ve gerektiğinde düzeltici önlem almayı içerir.

Ölçümler ve analiz

"Ölçümler ve

"Her Kilit Süreç Grubu, yürütülmesi Grubun hedeflerine ulaşılmasına katkıda bulunan Kilit Uygulamalar tarafından ifade edilir. Kilit Uygulamalar, Anahtar Süreç Grubunun etkin bir şekilde uygulanmasına ve kurulmasına en fazla katkıda bulunan altyapı ve operasyonları tanımlar.

Her Temel Uygulama, genellikle örnekler ve açıklamalar içerebilen daha ayrıntılı bir açıklama ile genişletilen tek bir cümleden oluşur. Anahtar uygulamalar, bazen anahtar uygulamalar olarak adlandırılır Üst düzey, bir grup kilit süreç için temel politikalar, prosedürler ve operasyonlar oluşturun. Bileşenler Detaylı Açıklama genellikle alt uygulayıcılar olarak adlandırılır. "

Temel Uygulamalar NE yapılması gerektiğini tanımlar, ancak hedeflere NASIL ulaşılacağını belirten dogmalar olarak alınmamalıdır. Çekirdek süreç grubunun amaçlarına alternatif uygulamalar yoluyla ulaşılabilir. Kilit uygulamaların yorumlanması, anahtar süreçler grubunun hedeflerine ulaşılmasına izin verecek şekilde makul olmalıdır. etkili yol, belki resmi olarak ve önerilen CMM'den farklı olsa da.

Süreçler yerine bileşenlerinin dikkate alındığı, temel uygulamalar ve süreçlerin yalnızca sanal olarak sunulduğu, temel uygulamalardan oluşturulabilecek bir şey ilk bakışta biraz egzotik göründüğü için BT yönetimi faaliyetlerine bir bakış. Şimdiye kadar, BT yönetimini iyileştirme görevi, referans süreç modelinden hazır süreçlerin getirilmesiyle çözülmüştür. Şimdi, farklı (yani süreçlere entegre edilmemiş) temel uygulamaları ve seviyeler arasında önerilen ilerleme sırasını içeren birçok seviye vardır. CMM'ye göre BT yönetişimi, siz daha yüksek bir olgunluk düzeyine geçtikçe gelişir. Böyle bir ilerleme ile ne olur?

Seviye tanımlarında (bkz. Şekil 7.2) "üretim süreci" gibi bir kavram ortaya çıktı. Aynı zamanda bir grup kilit sürecin tanımında da mevcuttur ve bu tesadüfi bir tesadüf değildir. Üretim süreci veya CMM'de uygun bir şekilde adlandırıldığı gibi, Standart Üretim süreci Organizasyonlar (DPT), tüm modelin merkezi kavramlarından biridir.

Kasım 1986'da ABD Yazılım Mühendisliği Enstitüsü (SEI), Mitre Corporation ile birlikte, iç süreçlerini iyileştirmeye yardımcı olması amaçlanan bir Yazılım Geliştirme Süreçleri Olgunluk Anketi geliştirmeye başladı.

Böyle bir anketin geliştirilmesi, ABD federal hükümetinden yazılım geliştirme için taşeronları değerlendirmek için bir yöntem talebiyle başlatıldı. Asıl sorun yönetememekti büyük projeler... Birçok şirkette projeler önemli gecikmelerle ve planlanan bütçenin üzerinde tamamlandı. Bu soruna bir çözüm bulmak gerekiyordu.

Eylül 1987'de SEI, olgunluk seviyelerini tanımlayan yazılım geliştirme süreçlerinin bir özetini ve şirkette iyileştirilecek alanları belirlemek için bir anket yayınladı. Ancak, çoğu şirket bu anketi bitmiş model Bunun sonucunda 4 yıl sonra anket gerçek bir model olan Yazılım için Yetenek Olgunluk Modeli'ne (CMM) dönüştürülmüştür. 1991 yılında piyasaya sürülen CMM'nin ilk versiyonu (Sürüm 1.0), 1992 yılında yaklaşık 200 yazılım uzmanının ve geliştirici topluluğu üyesinin katıldığı bir çalıştayda katılımcılar tarafından revize edildi.

Sonuç olarak serbest bırakıldı CMM standardı, Versiyon 1.1, tüm dünyada halen aktif olarak kullanılmaktadır.

Pirinç. 1. SMM kullanmanın küresel etkisi

SMM'ye olan bu ilginin nedenleri açıktır. Hem yazılım geliştiriciler hem de yönetimleri, süregelen problemlerinin çoğu zaman çok iyi farkında olmalarına rağmen, ilk etapta şirketin hangi değişikliklere ihtiyaç duyduğu konusunda anlaşamazlar. İyileştirmeler yapmak için birleşik bir strateji geliştirmeden yönetim, iyileştirme için en yüksek öncelikli görevler hakkında çalışanları ile karşılıklı anlayış bulamaz. Süreçleri iyileştirmek için harcanan çabalardan maksimum sonucu elde etmek için, geliştirme süreçlerinin olgunluğunu aşamalı olarak evrimsel bir şekilde iyileştirecek aşamalı bir geliştirme stratejisine sahip olmak gerekir.

Sürekli süreç iyileştirme, devrim niteliğindeki yeniliklere değil, bir şirketin kültürünün kademeli olarak yetiştirilmesine dayanır. CMM, bu artımlı iyileştirme için 5 süreç olgunluğu düzeyine bölünmüş bir çerçeve sağlar. Bu 5 seviye, bir şirketteki yazılım geliştirme süreçlerinin olgunluk seviyesini değerlendirmek ve parametrelerini ölçmek için bir ölçeği temsil eder.

Pirinç. 2. Olgunluk düzeyinde sürekli artış ilkesi: organizasyonun gelişimi için fırsatlar

Her seviyenin ana özellikleri şunlardır:

1. Başlangıç ​​- Geliştirme süreci kaotiktir. Süreçlerden sadece birkaçı tanımlanmıştır ve projelerin başarısı bireysel sanatçılara bağlıdır.
2. Tekrarlanabilir - Ana proje yönetimi süreçleri oluşturulmuştur: izleme maliyetleri, zamanlama ve işlevsellik. Benzer projelerde (benzer uygulamalara sahip projeler) önceki başarıları tekrarlamak için gereken bazı süreçleri kolaylaştırdı.
3. Tanımlı - Yazılım geliştirme ve proje yönetimi süreçleri şurada tanımlanır ve uygulanır: birleşik sistemşirket süreçleri. Tüm projeler, belirli bir projeye uyarlanmış standart bir yazılım geliştirme ve destek organizasyon süreci kullanır.
4. Yönetilen - Geliştirme süreci performansı ve kalitesi hakkında ayrıntılı nicel veriler toplayın son ürün... Bu verilerin önemi ve dinamikleri analiz edilir.
5. Optimizasyon - Sürekli süreç iyileştirme, nicel süreç verilerine ve yeni fikirlerin ve teknolojilerin pilot uygulamasına dayanır.

SW-CMM'ye Giriş

(Yazılım Mühendisliği Enstitüsü Yetenek Olgunluk Modeli'ne dayalı olarak yazılım geliştirme süreçlerinin olgunluğunun iyileştirilmesi)

Kurs aşağıdakilere yöneliktir:
Yazılım şirketlerinin başkanları, departman ve yazılım geliştirme projelerinin başkanları ve aşağıdakilerle ilgilenen kalite uzmanları için:

mevcut üretim süreçlerinin şeffaflığının iyileştirilmesi;

süreçlerin ve bir bütün olarak şirketin verimliliğini artırmak;

üretim maliyetini ve mevcut "gizli" üretim hacmini azaltmak;

profesyonel ortamda şirketin itibarını artırmak;

ürünler için yeni pazarlar açmak.

2.1 Maliyet, süre ve elde edilen sonuçlar. endüstri istatistikleri
2.2 CMM'de yatırım getirisi

3.1 TKY (Toplam Kalite Yönetimi), SPI (Yazılım Süreç İyileştirmesi) ve CMM'nin temeli olarak En İyi İş Uygulamaları
3.2 Temel konseptler TKY. Yazılım ürünlerinin üretiminde TKY yaklaşımlarının uygulanması
3.3 CMM süreç iyileştirme modelinin doğasında bulunan faydalar ve riskler
3.4 Süreç kavramı. Süreç yaklaşımının ana bileşenleri
3.5 Süreç olgunluk seviyeleri

9.1 BT endüstrisi için standartlar sistemi (Yol Haritası)
9.2 CMM, Rational Unified Process, Proje Yönetimi ile ISO ilişkisi
9.3 Küçük Kuruluşlar için CMM Uygulaması
9.4 SMM'de ne eksik
9.5 Belgeler ve süreçler

10.1 SW-CMM modeline son bakış. Dünyadaki dağıtım. ana zorluklar
10.2 CMMI (Yetenek Olgunluk Modeli Entegrasyonu) - CMM modelinin daha da geliştirilmesi

Bir dizi slayt, pratik alıştırmalar için materyaller, kendi kendine çalışma için ek materyaller.

SW-CMM ile ilgili eksiksiz bir belge seti (standart metni, değerlendirme yöntemleri, sektörle ilgili istatistiksel materyaller, belge örnekleri)

BT şirketlerinde SW-CMM modelini uygulama teknolojisi üzerine uygulamalı kurs

Kısa açıklama:
Bu kurs, şirketlerin bağımsız ve yetkin bir şekilde süreçlerin olgunluğunu iyileştirmek için bir modelin uygulanmasına ilişkin çalışmaları yürütmelerine yardımcı olmayı amaçlamaktadır. tipik hatalar ve uygulama sorunları.

Kurs aşağıdakilere yöneliktir:
Kurs, yazılım geliştirme ile ilgili işletme ve departman yöneticileri, proje yöneticileri, kalite yöneticileri ve geliştirmelerinin kalitesini iyileştirmek ve CMM süreçlerini belgelendirmekle ilgilenen diğer kişilere yöneliktir.

BT için tanınan kalite yönetimi standartlarının gözden geçirilmesi (ISO 9000, SW-CMM, CMMI, TickIT, SPICE)

17. ISO aracılığıyla CMM'ye?

Organizasyonel süreçlerin yönetiminde 5 evrimsel aşama. Yetenek Olgunluk Modelinin Açıklaması işlevsellik). CMM

Yetenek Olgunluk Modeli CM-CEI organizasyon modeli, kuruluştaki süreçlerin kontrol edildiği 5 evrimsel aşamayı (seviyeyi) tanımlar.

Orijinal olarak yazılım geliştirme için tasarlanan Yetenek Olgunluk Modelinin arkasındaki mantık, bir organizasyonun yazılım uygulamalarını kabul edip destekleyebilmesi gerektiğidir. Model ayrıca, organizasyonun bir sonraki seviyeye büyümesine yardımcı olacak somut adımlar ve girişimler önermektedir.

Yetenek Olgunluk Modelinin 5 Aşaması

Başlangıç ​​(süreçler ad hoc, kaotik veya aslında birkaç tanesi tanımlanmıştır) Tekrarlanabilir (temel süreçler oluşturulur ve bu süreçlere bağlı kalmak için bir disiplin vardır) Tanımlanmış (tüm süreçler tanımlanır, belgelenir, birleştirilir ve entegre edilir) Yönetilen (süreçler, ayrıntılı süreç verileri ve bunların kalitesi toplanarak ölçülür) Optimizasyon ( Sürekli gelişim nicel geri bildirim kullanan ve yeni fikirleri ve teknolojileri test eden süreç)

Yazılım geliştirme modeli

CMM, yazılım süreci olgunluğu kavramının altında yatan ilke ve uygulamaları tanımlar. Yazılım geliştirme ve pazarlama şirketlerinin yazılım süreçlerinin karmaşıklığını evrimsel bir şekilde geliştirmelerine yardımcı olmak için tasarlanmıştır. Özel, kaotik süreçlerden olgun, disiplinli yazılım süreçlerine. Odak noktası, disiplinli yazılım süreçlerinin oluşturabileceği kilit süreç alanlarını ve en iyi uygulamaları belirlemektir. CMM olgunluk kavramı, aşağıdakileri içeren bir bağlam oluşturur:

Uygulamalar tekrar edilebilir. Bir işlemi tekrarlamazsanız, iyileştirmemelisiniz. Bir organizasyonu uygulamaya ve tutarlı bir şekilde uygulamaya zorlayan kurallar, prosedürler ve uygulamalar vardır. Üretim çalışmasını organize etmek için en iyi uygulamalar gruplar arasında hızla yayılabilir. Uygulamalar, projeler arasında değiş tokuşa izin verecek şekilde tanımlanır, böylece kuruluş için bir miktar standardizasyon sağlanır. Bu yöntemlerin performansındaki sapmalar en aza indirilir. Hedefler için nicel hedefler belirlenir; ve ölçümler, değerlendirmenin temelini oluşturmak üzere oluşturulur, üretilir ve sürdürülür. Yetenekleri (optimizasyon) geliştirmek için uygulamalar sürekli olarak geliştirilmektedir.

Yetenek olgunluk modeli sadece yazılım geliştirme için değil, aynı zamanda genel olarak organizasyonların evrimsel seviyelerini ve organizasyonun uyguladığı veya ulaşmak istediği yönetim seviyesini tanımlamak için de faydalıdır.

İşlevsellik Geliştirme Modeli yapısı

Olgunluk seviyeleri, sürekli iyileştirme sağlamak için gereken disiplin tutarlılığını sağlayan katmanlı bir kavramdır. Burada, kuruluşun yeni bir uygulamanın, teknolojinin veya aracın sonuçlarını değerlendirme yeteneğini geliştirdiğini belirtmek önemlidir. Dolayısıyla, bu yeniliklerin kabul edilmesi değil, bu yenilikçi çabaların mevcut uygulamaları nasıl etkilediği meselesidir. Projeleri, grupları ve organizasyonları, onlara bilinçli seçimler yapmaları için temel vererek destekler. Anahtar süreç alanları - Anahtar süreç alanı (KPA), birlikte gerçekleştirildiğinde bir dizi önemli hedefe ulaşan bir grup ilgili faaliyeti tanımlar. Hedefler - Bir kilit süreç alanının amaçları, o anahtar süreç alanı için var olması gereken hükümleri tanımlar. Düzenlemelerin etkin ve güvenilir bir şekilde uygulanması gerekmektedir. Hedeflere ne ölçüde ulaşıldığı, organizasyonun bu mükemmellik düzeyinde ne tür bir fırsat hazırladığını gösterir. Hedefler, her bir kilit süreç alanının faaliyet alanlarını, sınırlarını ve amacını ana hatlarıyla belirtir. Ortak özellikler - Ortak özellikler, kilit süreç alanlarını uygulayan ve kurumsallaştıran uygulamaları içerir. Bu 5 tür Genel özellikleri Bunlar: Uyum Taahhüdü, Uyum Yeteneği, Gerçekleştirilen Girişimler, Ölçüm ve Analiz ve Uygulama Kontrolü. Temel Uygulamalar - Kilit Uygulamalar, kilit süreç alanlarının uygulanmasına ve kurumsallaşmasına en etkin şekilde katkıda bulunan altyapı ve uygulama unsurlarını tanımlar.

Süreci tanımlama kriterleri

Bir süreci tanımlama kriterleri, insanların bunları pratikte kullanabilmeleri için bir yazılım sürecinin tanımına dahil edilmesi gereken bir süreç unsurları topluluğudur. Kriterleri belirlemek için şu soruyu sormanız gerekir: "Belgeleme için program süreci hakkında hangi bilgilere ihtiyaç var?"

Tanıtım

Modern karmaşık sistemlerin en önemli parçası, entelektüel bir bileşen olan yazılım ürünleridir. Yazılım ürünleri artık insan faaliyetinin neredeyse tüm alanlarındaki yönetim sorunlarını çözmek için kullanılmaktadır: ekonomi, sosyal, askeri ve diğer alanlarda. Yurtiçinde ve dünya pazarında çeşitli uygulama alanları için toplu geliştirme ve teslimat sırasında yerli yazılım ürünlerinin yüksek kalitede olmasını sağlamak stratejik amaç.

Şu anda, yazılım mühendisliğinde neredeyse bağımsız iki standardizasyon alanı ve şartlı olarak ISO standart profilleri olarak adlandırılabilecek yazılım ürünlerinin kalite güvencesi vardır ( Uluslararası Organizasyon standardizasyon) ve SEI (ABD Yazılım Mühendisliği Enstitüsü) olgunluk modelleri. Birincisi [,] içinde ve ikincisi - [,] içinde yeterince tam olarak temsil edilir. Makalenin ana içeriği olgunluk modellerine ayrılmıştır.

Karmaşık yazılım ürünleri dünyasında rekabet gücünü ve başarılı ihracat olasılıklarını sağlamak için, gereksinimlere uygun olarak geliştirilmeli ve sertifikalandırılmalıdır. uluslararası standartların profilleri temelde ISO 9000: 2000 veya olgunluk modelleri - CMMI: 2003(Yetenek Olgunluk Modeli Entegrasyonu - Yazılım mühendisliğinin olgunluğunu değerlendirmek için entegre model). Bu iki yön, metodolojik olarak çok yakındır ve karşılıklı bağlantılar yoluyla kısmen kesişir.

Yazılım ürünlerinin teknik ve ekonomik göstergelerinin ve kalitesinin iyileştirilmesi ile hata ve kusurların önlenmesi, modern yazılım mühendisliği teknolojileri ve sistemlerinin kullanılmasıyla sağlanır. Bilgisayar destekli tasarım... Bunlar, yazılım araçlarının (PS) tasarımı, uygulanması ve bakımı için toplam kaynak maliyetini düşürmeyi amaçlayan yüksek kaliteli, güvenilir ve güvenli program kompleksleri oluşturmak için yüksek performanslı, kaynak tasarrufu sağlayan teknolojilerdir. Bunun için öncelikle hedeflerin, amaçların ve işlevlerin somutlaştırılmasını ve en baştan itibaren en doğru şekilde temsil edilmesini sağlayan analiz ve tasarım yöntem ve araçlarının uygulanması gerekmektedir. yaşam döngüsü(Yaşam döngüsü) yazılım sistemleri ve olası sistem kusurlarının sonraki geliştirme aşamalarına yayılmasının önlenmesi. Bu tür yazılım mühendisliği teknolojileri, işletim için aktarılan yazılım ürünlerindeki sistem, algoritmik ve yazılım hatalarının düzeyini hariç tutmayı veya önemli ölçüde azaltmayı mümkün kılar. Ek olarak, PS'yi değiştirirken ve bakımını yaparken ve ayrıca değiştirirken etkilidirler. dış ortam.

Karmaşık, kritik sistemlerin kalitesini, güvenilirliğini ve güvenliğini belgelemek için, bunlarda kullanılan yazılım ürünleri, sertifika sertifikalı, problem odaklı test merkezleri veya laboratuvarlar. Bu tür testler, programlar, kusurların veya yetersiz kalitenin önemli hasara neden olabilecek kadar önemli olan karmaşık, kritik süreçleri veya bilgileri işlediğinde gereklidir. Sertifikasyon testleri, yazılım komplekslerinin dokümantasyon gereksinimlerine uygunluğunu sağlamalı ve gerçekleştirilen kontroller sırasında incelenen dış ortamın parametrelerindeki değişikliklerin sınırları içinde çalışmalarına izin vermelidir. Bu tür testler, en yüksek titizlik ve kontrol derinliği ile karakterize edilir ve geliştiricilerden ve müşterilerden (kullanıcılardan) bağımsız uzmanlar tarafından gerçekleştirilmelidir.

Belgelendirmenin temeli, standartlaştırılmış müşteri gereksinimlerine uygunluk için program komplekslerini test etmek için ayrıntılı ve etkili programlar ve yöntemler, bunların oluşumu için özel olarak tasarlanmış test problemleri ve jeneratörler ve ayrıca test uzmanlarının yüksek nitelikleri ve yetkisi olmalıdır. Yazılım geliştirme işletmelerinde gereksinimlere göre yazılım ürünlerinin yaşam döngüsünü sağlamak için sertifikalı kalite sistemlerinin uygulanması ISO 9000: 2000 veya CMMI: 2003, yaşam döngülerindeki süreçlerin ve ürünlerin yüksek, sürdürülebilir kalite yönetimini garanti eder ve ayrıca birçok durumda nihai yazılım ürününün sertifikalandırılmasını kolaylaştırır. Bu nedenle, karmaşık yazılım projelerinin müşterileri, uluslararası standartların uyarlanmış profillerine veya olgunluk modellerine dayalı kalite güvence sistemleri uygulamalarını onaylayan sertifikalara sahip yürütme yüklenicilerini seçme eğilimindedir.

Yazılım mühendisliği yöntemlerinin öğretilmesindeki boşluklar, uzmanların çalışmalarının kalitesini değerlendirmede keyfi olmaları ve ayrıca yazılım projelerinde çok sayıda kusur ve hatanın ortaya çıkması için geniş bir marj bırakmaktadır. Artan karmaşıklık ve sorumluluk modern zorluklar Programlar tarafından çözülen ve sonuçlarının yetersiz kalitesinden kaynaklanan olası hasarlar, kalite özellikleri için gereksinimlerin eksiksiz, standart bir açıklaması ve gerçek, elde edilen değerleri ölçme yöntemlerine hakim olmanın alaka düzeyini önemli ölçüde artırdı ​PS yaşam döngüsünün çeşitli aşamalarında. Uzmanların yazılım ürünlerinin kalite özelliklerini değerlendirme kavramlarını, tanımlarını ve yöntemlerini bilme ihtiyacı keskin bir şekilde artmıştır.

Yazılım komplekslerinin hızlı artışı ve karmaşıklığı, uzman gruplarının koordineli faaliyetlerini tek bir projede düzenlemenin gerekli olduğu profesyonel bir iş bölümü ile büyük programlama ekiplerinin oluşturulmasına yol açmaktadır. Geliştiricilerin, üzerinde anlaşmaya varılan zaman dilimi içinde yüksek kaliteli yazılım sunmaya yönelik sözleşme taahhütleri genellikle karşılanmaz. Bu genellikle, müşteri ve yüklenicinin kalite seviyesini farklı kriterlere göre değerlendirmesi ve bu konuda herhangi bir anlaşmaya sahip olmaması ve programların kalitesini değerlendirme yaklaşımının yeterince resmileştirilmemesi nedeniyle olur. Ayrıca, yüksek kaliteli programlara ulaşmak için gereken kaynakları gerektiği gibi değerlendirme yeteneği bazen eksiktir. Sonuç olarak, yazılım ürünlerinin kalitesi genellikle düşük, güvenilmez ve uluslararası pazarda rekabetçi değil. Bu nedenle pek çok uygulamanın geliştirilmesinde ve uygulanmasında en önemli sorun modern sistemler yazılım mühendisliği alanında uzmanların yetiştirilmesi ve yetiştirilmesi, yazılımların yüksek kalitesine katkıda bulunan uluslararası standartların kullanılması ve proje süreçlerinin yapılması ana hedefi ile güvenilir bir şekilde değerlendirilmesidir. yönetilen ve sonuçlar tahmin edilebilir... Bu kaliteyi sağlamak ve geliştirmek için mevcut kaynakları dikkate alarak, gereksinimleri resmileştirebilmek ve işleyiş kalitesinin özelliklerinin ve karmaşık program komplekslerinin kullanımının belirli değerlerini elde edebilmek gerekir.

CMMI Olgunluk Modeli - 1.1, önceki modelleri iyileştirir ve iyileştirir CMM(bkz.) ve ayrıca yazılım yönetimi alanındaki mevcut uluslararası standartların temel gereksinimlerini kısmen dikkate alır. büyük dikkat CMMI geliştirme süreçlerine ve müşteri gereksinimleri değiştiğinde yinelemelerin muhasebeleştirilmesine, bunları işlevlere, bileşenlere, testlere ve proje belgelerine göre izlemeye odaklanır. V Son zamanlarda SEI Enstitüsü tarafından 2003 versiyonunun modernizasyonu hakkında bilgi vardı CMMI - 1.1 işletmelerden gelen deneyim ve geri bildirimlere dayanmaktadır. 2006 yılında modelin yeni, önemli ölçüde modernize edilmiş bir versiyonunun piyasaya sürülmesi planlanmaktadır. CMMI - 1.2, bundan sonra sürüm 1.1 aşamalı olarak kaldırılmalıdır. 2007'nin sonunda, kullanıcılar sürüme geçmelidir. CMMI - 1.2 ve gelecekte yazılım mühendisliği alanındaki işletmelerin teknolojisinin resmileştirilmiş kalite değerlendirmesi (belgelendirmesi) için zorunlu hale gelecektir. Bu durumda, sertifikanın geçerliliği üç yıl ile sınırlı olacaktır. Büyük yazılım sistemlerinin müşterileri ve geliştiricileri, SEI tarafından sürüm 1.2'nin resmi olarak yayınlanmasından önce bu değişikliklere hazırlık yapmalıdır.

CMMI Olgunluk Modelinin yapısı ve içeriği - 1.1

İki model seçeneği CMMI - 1.1 sağlamak için yaratıldı sürekli belirli bir yazılım geliştirme alanındaki bir dizi süreci değerlendirmek veya aşamalı işletmenin olgunluğunu değerlendirmek ve geliştirmek ve ayrıca genel olarak yazılım komplekslerinin yaşam döngüsünü düzenlemek için. Modeller CMMI uzmanlara ürünlerini organize etme ve iyileştirmede ve ayrıca yazılım sistemleri geliştirme ve bakım süreçlerini düzene koyma ve sürdürmede yardım sağlar. Bu modellerin konsepti, karmaşık sistemlerin olgunluğunun yönetimini ve değerlendirilmesini, yazılım mühendisliğini ve entegre yazılım ürünleri oluşturma ve bunların gelişimini iyileştirme süreçlerini kapsar. Sürekli ve aşamalı modellerin bileşenleri büyük ölçüde benzerdir ve belirli projelerin özelliklerine ve özelliklerine bağlı olarak farklı bir kompozisyon ve kullanım sırasında seçilebilir ve uygulanabilir.

Model açıklama seçenekleri, genel bölümleri içeren tek bir şemaya göre oluşturulmuştur:

• önsöz;
• Bölüm 1 - giriş;
• Bölüm 2 - Bileşen Modeli;
• Bölüm 3 - Terminoloji;
• Bölüm 4 - seviyelerin içeriği ve modelin her versiyonunun ana bileşenleri (hedeflerin ve prosedürlerin geliştirilmesi);
• Bölüm 5 - süreçlerin etkileşiminin yapısı; Bölüm 7'deki dört süreç kategorisi, bunların genel görünümü ve CMMI süreçlerinin etkileşim şemaları açıklanmıştır:
  • süreç yönetimi;
  • yönetim - proje yönetimi;
  • Mühendislik teknolojisi);
  • destek;
• Bölüm 6 - modeli kullanma CMMI- modelin kullanımı ve eğitim hakkında kullanıcılar için kısa öneriler; modelin süreçlerinin, standardın 2. ve 3. bölümlerinde önceki CMM modelinin düzenlenmiş süreçleriyle uyumluluğu ve uygunluğu not edilir ISO 15504.
• Bölüm 7, her standartta en sonuncusu, en büyüğüdür, 700 sayfadan fazla olan belgenin toplam hacminin yaklaşık 500 sayfasını alır. Bu bölüm, belirli bir modelin özelliklerini dikkate alan, içinde listelenen süreçlerin her birinin uygulanması için ayrıntılı öneriler sunar.

İlk seçenek(Sürekli) model belgeyi yansıtır: Sistem Mühendisliği / Yazılım Mühendisliği / Entegre Ürün ve Süreç Geliştirme için Yetenek Olgunluk Modeli Entegrasyonu (CMMI), Sürüm 1.1, Sürekli Temsil (CMMI-SE / SW / IPPD, V1.1, Sürekli). Sistem Mühendisliği / Yazılım Mühendisliği / Entegre Ürünler ve Geliştirme Süreçleri için Entegre Olgunluk Değerlendirme Modeli - sürekli sunum... Bu modelde yedinci bölüm süreçlerden oluşur:

• süreç yönetimi:
  • eğitim organizasyonu;
  • süreçlerin dönüşümünün (değişikliklerinin) organizasyonu;
  • yenilikleri ve uzantıları organize etmek;
• proje Yönetimi:
  • proje planlaması;
  • proje süreçlerinin izlenmesi ve kontrolü;
  • Risklerin yönetimi;
  • nicel proje yönetimi;
• Mühendislik teknolojisi):
  • ihtiyaç Yönetimi;
  • gereksinimlerin geliştirilmesi;
  • teknik çözümler;
  • ürün entegrasyonu;
  • doğrulama;
  • doğrulama (belgelendirme, onay);
• destek:
  • konfigürasyon yönetimi;
  • değişiklikler için analiz ve karar verme;
  • nedenlerin analizi ve sorunların çözümü (kusurların giderilmesi).

Beş ek şunları sağlar:

A- standartlardan bahsetmeyen, ancak kullanılan literatürün ve belgelerin bileşimi ISO;

V- kısaltmalar;

İLE- terminolojiye dayalı sözlük ISO sadece dört standartta uygulandı ISO 9000, ISO 12207, ISO 15504: 1-9, ISO 15288;

D - olgunluk seviyelerine göre model bileşenlerinin oluşturulması için gereksinimlerin ve tekliflerin tanımları;

E - geliştirmedeki katılımcıların listesi CMMI- proje.

Bu modelde, organizasyonel süreçlere, yazılım projelerinin uygulanmasının planlanmasına, yönetimine ve kontrolüne, yazılım ürünleri için gereksinimlerin geliştirilmesi ve yönetimine odaklanılır. Aşağıda ayrıntı düzeyi örnekleri verilmiştir. CMMI bazıları.

Proje planlaması bunda ve ikinci modelde şunları içerir:

• değerlendirme olası boyut yazılım ürününün (ölçek);
• PS projesinin işlevlerinin ve özelliklerinin karmaşıklığının değerlendirilmesi;
• bir program kompleksinin yaşam döngüsünün modelinin ve aşamalarının belirlenmesi;
• projenin fizibilite çalışması - PS'nin yaşam döngüsünün maliyetinin, emek yoğunluğunun ve süresinin belirlenmesi;
• aşamalı bir çalışma takvimi ve proje bütçesinin geliştirilmesi;
• proje risklerinin analizi, tanımlanması ve değerlendirilmesi;
• bir PS projesinin yaşam döngüsündeki süreçlerin ve ürünlerin yönetiminin planlanması ve belgelenmesi;
• PS'nin yaşam döngüsünün aşamalarına göre teknik ve insan kaynaklarının planlanması ve dağıtımı;
• projenin uygulanması için bir uzman ekibinin bilgi ve niteliklerinin sağlanmasının planlanması;
• PS projesi için bir dizi planın genelleştirilmesi ve analizi;
• geliştirici tarafından PS projesinin müşterisi ile yaşam döngüsü aşamalarına göre işlerin ve kaynakların koordinasyonu;
• iş planının belgelenmesi ve proje geliştirici yöneticisi tarafından onaylanması.

Gereksinim geliştirme süreçleri yazılım ürünü için her iki modeldeki süreçlere benzer ve şunları içerir:

• yazılım ürününün işlevleri ve özellikleri için müşterinin ve kullanıcıların gerçek ihtiyaçlarının belirlenmesi;
• yazılım ürününün işlevleri için ilk, temel gereksinimlerin müşteri ve geliştiricisi arasında geliştirilmesi ve koordinasyonu;
• proje kompleksinin mevcut kaynaklarının ve sınırlamalarının belirlenmesi;
• yazılım sistemleri işlevleri için temel ilk gereksinimlerin bir yazılım paketinin bileşenleri ve testleri için bir dizi gereksinime ayrıştırılması;
• operasyonel ve dış çevre ile bileşenler arasındaki arayüz gereksinimlerinin resmileştirilmesi;
• bir yazılım ürünü kavramının ve kullanımı için senaryoların geliştirilmesi;
• işlevsel uygunluğun genelleştirilmiş özellikleri için gereksinimlerin geliştirilmesi ve yazılım ürününün işlevlerinin amaçlanan amacı için kullanılması.

İhtiyaç Yönetimi her iki modelde şunları içerir:

• müşteri ve geliştiriciler tarafından PS projesi gereksinimlerinin açık bir şekilde anlaşılması;
• yazılım ürünü için tüm gereksinimlerini yerine getirme yükümlülüklerinin geliştiricilerden müşteri tarafından alınması;
• müşteri ve geliştirici arasında kararlaştırılan PS projesinin gereksinimlerindeki değişikliklerin yönetimi;
• PS projesi için genel gereksinimlerden bileşenler ve özel süreçler gereksinimlerine kadar olan değişikliklerin doğruluğunun izlenebilirliğinin sağlanması;
• proje geliştirme süreçleri ve müşteri gereksinimleri arasındaki tutarsızlıkların belirlenmesi ve tanımlanması.

İkinci seçenek belgeyi sunar: Sistem Mühendisliği / Yazılım Mühendisliği / Entegre Ürün ve Süreç Geliştirme için Yetenek Olgunluk Modeli Entegrasyonu (CMMI), Sürüm 1.1, Aşamalı Temsil (CMMI-SE / SW / IPPD, V1.1, Aşamalı). Karmaşık Sistemler Mühendisliği / Yazılım Mühendisliği / Entegre Ürünler ve Geliştirme Süreçleri için Entegre Olgunluk Değerlendirme Modeli - aşamalı sunum... Model, beş olgunluk düzeyi kavramının sürdürülmesine dayanmaktadır. CMM[,]. İşlemlerin bileşimi, modelin ilk versiyonu için yukarıda verilenleri pratik olarak tekrar eder, ancak biraz farklı bir sırayla ve nispeten küçük eklemelerle.

İlk seviyeçeşitli nispeten basit projelerdeki süreçlerin bileşiminde ve içeriğinde önemli belirsizlik ile karakterize edilir, bu nedenle belgede yorum yapılmaz. Bu nedenle, aşamalı bir versiyonda süreçlerin içeriğini netleştirirken ve detaylandırırken CMMI sınırlandırılması tavsiye edilir dört ana seviye:

• ikinci seviye- resmileştirir temel yönetim projeler:
  • ihtiyaç Yönetimi;
  • proje planlaması;
  • proje izleme ve kontrol;
  • tedarikçilerle yapılan anlaşmaların yönetimi;
  • süreçlerin ve ürünlerin ölçümü ve analizi;
  • süreçlerin ve ürünlerin kalite güvencesi;
  • konfigürasyon yönetimi;
• üçüncü seviye- ana süreçlerin standardizasyonunu içerir:
  • gereksinimlerin geliştirilmesi;
  • teknik çözümler;
  • ürün entegrasyonu;
  • doğrulama;
  • doğrulama (sertifika);
  • organizasyonel süreçlerin içeriği;
  • organizasyonel süreçlerin tanımı;
  • eğitim organizasyonu;
  • proje süreçlerinin ve ürünlerinin entegre yönetimi;
  • Risklerin yönetimi;
  • geliştirme ekibinin entegrasyonu;
  • entegre tedarikçi yönetimi;
  • sorunların analizi ve çözümü (kusurların giderilmesi);
  • entegrasyon için ortamın organizasyonu;
• dördüncü seviye- nicel yönetimi tanımlar:
  • süreçlerin kalitesinin sunumunun organizasyonu;
  • tüm proje ve kaynakların nicel yönetimi;
• beşinci seviye- optimizasyon, sürekli iyileştirme:
  • organizasyon, yenilik, nicel süreç ve kaynak yönetimi;
  • kusurların nedenlerinin analizi, kalitenin iyileştirilmesi ve süreçlerin ve ürünlerin yönetimi.

Modelin ikinci versiyonundaki uygulamalar, kompozisyon olarak birinci model için yukarıdaki uygulamalara benzer. Her daha yüksek olgunluk seviyesinde uygulanması tavsiye edilir. tüm süreçlerönceki düşük seviyeler. Modelin her iki versiyonunda, her biri yukarıda vurgulanmıştır, temel süreç, yaklaşık 20-30 sayfa boyutunda birleşik açıklamaları içeren pratik uygulaması için ayrıntılı önerilerle yorumlanmıştır:

• ulaşılacak sürecin genel hedefleri;
• giriş açıklamaları ve Genel açıklama süreç fonksiyonları;
• sürecin belirli hedefleri;
• süreç yönetimi;
• süreç gereksinimlerinin geliştirilmesi;
• diğer süreçlerle etkileşim ve arayüzler;
• pratik hedefler, süreç faaliyetlerinin gerekli çıktılarıdır;
• belirli bir süreçte eylemleri planlamak;
• süreç uygulamasının sonuçlarının analizi ve doğrulanması (onay);
• sürecin izlenmesi ve kontrolü.

Temel süreçlerin tanımlarının hacmi, içeriği ve eksiksizliği için bu öneriler, sunulan PS'nin yaşam döngüsü için bir dizi standarda benzer. Olgunluk seviyelerine göre kullanılan süreçlerin eksiksizliğinin düzenlenmesi ve değerlendirilmesi, işletmelerin - yazılım geliştiricilerin tahmin edilen süreçlerin kalitesine ve faaliyetlerinin sonuçlarına göre üretim potansiyelini ve uygunluk için sertifikaya hazır olma durumunu belirlemenize olanak tanır. belirli bir model olgunluğu seviyesi CMMI - 1.1.

Modellerde özel dikkat CMMI PS projesinin yönetim süreçlerine verilir. Bu gereksinimler ve model süreçler, standartlarda belirtilen ve ayrıntılı yönergelerle yakından uyumludur. ISO 9001: 2000 ve karmaşık yazılım sistemleri için yaşam döngüsü standartları profilinin ana bileşenleri [,]. Standartların 4-8 işlevsel maddelerinde yer alan işlemler için gereklilikler ISO 9001, ISO 9004, ISO 90003 modelde içerik olarak yeterli olan birkaç bölüm karşılaştırılabilir CMMI(Şekil 1'de bir kapsama örtüşmesi vardır). Süreçlerin ve gereksinimlerin ortaklığı benzerlikten oluşur: kompozisyon, terminoloji, yapı, önerilen yönetim süreçlerinin bir listesi, planlama, mevcut kaynakların muhasebeleştirilmesi, yazılım mühendisliği süreçlerinin uygulanması, uzmanların değerlendirilmesi ve organizasyonu.

Şekil 1. Standartların ve olgunluk modellerinin süreç ve gereksinimlerinin ortaklığı

Büyük yazılım projelerinin tüm yaşam döngüsünün desteklenmesi ve düzenlenmesi açısından modellerin dezavantajlarına kadar CMMI mevcut standartların profilinde ISOşunları içerir:

Yazılım sisteminin yaşam döngüsünü sağlama süreçlerinin yukarıdaki olgunluk seviyelerini belirlemek için kapsamlı bir teknik rapor geliştirildi ve ilk olarak 1998'de onaylandı. ISO 15504, dokuz bölümden ve birçok uygulamadan oluşan. Olgunluk modelini ortaya koyar CMM ve standarda dayalı yazılım mühendisliğinin sekiz temel ilkesi ISO 9000: 2000... Daha sonra ISO bu belge, amaç ve konseptin tam olarak korunmasıyla, yapı ve içeriğin radikal bir revizyonundan, azaltılmasından, basitleştirilmesinden geçmiş ve onaylanmıştır. Standart olarak beş parça halinde.

Standart ISO 15504: 1-5: 2003-2006 işletmeler tarafından gerçekleştirilen yazılım araçları ve sistemlerinin oluşturulması, bakımı ve iyileştirilmesi süreçlerinin olgunluğunun değerlendirilmesini ve onaylanmasını düzenler:

• kendi teknolojik süreçlerinin durumunu belirlemek ve geliştirmek;
• kendi süreçlerinizin belirli gereksinimleri veya müşteri gereksinimleri sınıflarını karşılamaya uygunluğunu belirlemek;
• PS ve sistemlerin müşterileri ile belirli sözleşmelerin yerine getirilmesine uygunluğu amacıyla.

Standart aşağıdakilere katkıda bulunur: işletmelerin olgunluğunun kendi kendini belgelendirmesi, sertifikalı süreçlerin yeterli şekilde yönetilmesinin sağlanması, süreç derecelendirmelerinin profilinin belirlenmesi ve ayrıca her türlü uygulama alanı ve PS ve sistem boyutları için uygundur. Standardın uygulanması, işletmeleri ve uzmanları geliştirmeyi amaçlamaktadır. teknoloji olgunluğunun sürekli iyileştirilmesi kültürü projelerin iş hedeflerini karşılayan ve mevcut kaynakların kullanımını optimize eden PS'nin yaşam döngüsünü sağlamak. Kurumsal süreçlerin olgunluğunun onaylanması, belirli projeler için tercih edilen karşılaştırma ve seçim imkanı sağlar:

• müşteriler, alıcılar, yazılım ürünleri ve sistemleri kullanıcıları için: tedarikçinin yaşam döngüsü süreçlerinin mevcut ve potansiyel olgunluğunu belirleme yeteneği;
• tedarikçiler ve geliştiriciler için: yazılım ve sistemlerin yaşam döngüsünün kendi süreçlerinin mevcut ve potansiyel olgunluğunu, süreç iyileştirme alanları ve önceliklerini belirleme yeteneği;
• olgunluk değerlendiricileri için: tasdik süreçlerini yürütmek ve geliştirmek için bir temel.

Standarttaki onaylar şurada ele alınmaktadır: iki yön: Belirli bir işletmenin PS ve sistemlerinin yaşam döngüsü süreçlerini iyileştirmek ve proje veya işletmeyi sağlama süreçlerinin beyan edilen vadesinin kullanılan gerçek süreçlere uygunluğunu belirlemek. Bu, standardın sonraki beş bölümünde yansıtılmaktadır. ISO 15504: 1-5: 2003-2006.

Bölüm 1 - Kavram ve kelime bilgisi. içerir Genel bilgi yazılım ve sistemlerin olgunluğunun tasdik süreçleri ve standardın bölümlerinin kullanımına ilişkin tavsiyeler hakkında. Onaylama, terminoloji, yapı için genel gereksinimler belirtilir, standardın geri kalan bölümlerinin kapsamı belirlenir.

Bölüm 2 - Onayın yürütülmesi (üretimi). Yazılım ve sistemlerin yaşam döngüsünü sağlamak için teknolojik süreçlerin olgunluk düzeyinin iyileştirilmesi ve belirlenmesi için bir temel olarak onay süreçleri için ayrıntılı gereksinimleri içerir. Belge, objektif, anlamlı ve temsili olmaları için tasdik gerçekleştirme süreçlerini, önerilen tasdik süreçlerinin modellerini ve süreç doğrulamasını tanımlar.

Bölüm 3 - Onay üretimi için el kitabı. Olgunluk tasdik süreçlerini gerçekleştirmek ve gereksinimlerin uygulanmasını yorumlamak için teknolojiye genel bir bakış sağlar. Şunları yansıtır: sertifikasyon performansı; olgunluk süreçlerini belirlemek için ölçüm araçları; sertifika araçlarının seçimi ve uygulanması; değerlendiricilerin yeterliliğinin değerlendirilmesi; Belgelendirmenin beyan edilen şartlara uygunluğunun doğrulanması. Belgelendirme araçları, işletmeler tarafından yazılım ürün ve sistemlerinin planlanması, yönetimi, izlenmesi, kontrolü ve iyileştirilmesinde, satın alınmasında, geliştirilmesinde, uygulanmasında ve bakımında kullanılabilir.

Bölüm 4 - Bu iki açıdan iyileştirme süreçleri ve süreç olgunluğu belirleme için kullanıcı kılavuzu. Aşağıdakileri içeren bir dizi adım tavsiye edilmektedir: yeterlilik süreçlerinin sonuçlarının uygulanması; olgunluğun tasdiki için hedefler belirlemek; tasdik için ilk verilerin belirlenmesi; ortaya çıkan risklerin olası azaltılmasının değerlendirilmesi; süreçleri iyileştirme adımları; olgunluk düzeyini belirleme adımları; tasdik analizinin sonuçlarının gereklilikler ile karşılaştırılması.

Bölüm 5 - Bölüm 2'de sunulan gereksinimlere uygunluk için doğrulama süreçlerinin örnek bir modeli. Kapsamlı belge (162 sayfa), çeşitli kullanım alanları, yazılım projeleri ve işletmeler için yaşam döngüsü süreçlerinin olgunluğunun onaylanmasını organize etmek, değerlendirmek ve geliştirmek için standardın önceki bölümlerinin pratik uygulamalarının örneklerini sağlar.

Projelerin pratik uygulamasında ve karmaşık yazılım sistemlerinin yaşam döngüsünün sağlanmasında, geliştiricilerin ve tedarikçilerin kullanım için modellerin avantajlarını belirlemesi ve izole etmesi bazen zordur. CMMI... İşletmenin geleneklerine ve büyük bir PS projesinin özelliklerine bağlı olarak, genellikle eksiksiz bir PS projesinin kullanılması tavsiye edilir. standartlar profiliISO ve müşteriler tarafından değerlendirilmek üzere olgunluk seviyesi Belirli önerileri uygulamak için PS projelerinin yönetimi, organizasyonel ve teknolojik desteği CMMI... Bu tavsiyeler şu durumlarda etkili bir şekilde kullanılabilir: süreç kalite sertifikası Bir dizi yönetim standardına göre sertifikasyona alternatif olarak veya sertifika ile birlikte yaşam döngüsü hizmetleri sunan işletmelerde ISO 9000, projenin özelliklerine ve başvuru sahibinin yaşam döngüsünü sağlamak için bir yazılım ürünü veya teknolojisinin sertifikasyonu gereksinimlerine bağlı olarak.

Yazılım ürünlerinin sertifikasyonu organizasyonu

Sertifikasyon, aşağıdakileri oluşturan bir dizi organizasyonel süreçten oluşur. Belgelendirme Sistemi Bu süreçler, düzenlenmiş prosedürler ve belgelerle desteklenir ve kalifiye, sertifikalı uzman denetçiler tarafından gerçekleştirilmelidir. Geliştirici işletmenin sertifikasyonu ve faaliyetlerinin sonuçları için - yazılım ürünleri, modeller CMMI veya standart profiller ISO[,] nesnelerin belirli özelliklerine ve yazılım sisteminin yaşam döngüsünün dış ortamına uyarlanması gereken belirli bir disiplin önerilir. Aşağıda listelenen süreçler ve belgeler büyük projelere odaklanmıştır ve daha basit durumlarda geliştiriciler, müşteriler ve onaylayıcılar arasındaki anlaşmayla bunların bileşimi azaltılabilir.

Belgelendirme çalışması, bir kuruluşun veya test laboratuvarının akreditasyonu, bir başvurunun oluşturulması ve sunulması ve akreditasyonun uygunluğu hakkında bir karar vermek için Merkezi Belgelendirme Kuruluşuna bir dizi belgenin sunulması ile başlar. Test sonuçları olumlu ise akreditasyon belgesi düzenlenir ve düzenlenir.

Belgelendirme kuruluşu veya laboratuvarına ilişkin yönetmelik akreditasyonun tematik alanını, yasal durumu, işlevleri, yapısı, hakları ve yükümlülükleri, yöntemleri, araçları ve testlerin organizasyonunu oluşturan ana belgedir. Sertifikasyon laboratuvarının (merkezin) pasaportu, test için gerekli bilgisayar ekipmanına sahip ekipman, personel ve personel, test araçlarına sahip ekipman, düzenleyici, teknik ve metodolojik belgelerin sağlanması ve ayrıca test için gerekli diğer kaynaklar hakkında bilgi içermelidir.

kaliteli gerçekleştirilen testlerin kalitesini ve değerlendirme, test ve muayene sonuçlarına güveni sağlayan bir ilke beyanı, belgelendirme kuruluşunun veya laboratuvarın ana işlev ve görevlerinin uygulanmasıyla ilgili yöntem ve prosedürlerin bir tanımını içerir. Kalite kılavuzu genellikle [TWLSC $

• test ve inceleme için kalite güvence politikası;
• merkezin güncel metodolojik materyaller ve yazılım ve test araçlarıyla donatılması;
• test nesneleri için gereksinimlerin resmileştirilmesi;
• merkezin teknik donanımı ve personel gelişimi alanındaki politika;
• Belgelendirme sonuçlarının belgelerinin güvenliğinin arşivlenmesi ve kontrolü.

Belgelendirmeye tabi ürün veya süreci değerlendirmek için başvuru sahibi, belgelendirme sisteminde kabul edilen formda belgelendirme kuruluşuna bir başvuru gönderir. Belgelendirme kuruluşu, talep üzerine ürün belgelendirmesinin hazırlanması ve organizasyonu ile ilgili çalışmalar yürütür. Bu çalışma şunları içerir:

• ürünün özelliklerini (hacim, teknoloji, düzenleyici belgelerin gereklilikleri vb.) ve geliştiricinin tekliflerini dikkate alarak bir sertifikasyon planının seçimi;
• standartlarda belirtilmemişse, test edilecek numune ve bileşenlerin sayısının ve sırasının belirlenmesi;
• testleri yapması gereken akredite bir test laboratuvarının seçilmesi ve belirlenmesi;
• işin yerine getirilmesi için bir taslak sözleşmenin hazırlanması.

Belgelendirme çalışmasının hazırlık kısmı, belgelendirme sisteminde kabul edilen biçimde bir kararın yayınlanmasıyla sona erer. Karar, işin yapılmasına ilişkin sözleşme taslağı ile birlikte başvuru sahibine gönderilir. Sertifikasyon testleri düzenlenirken, sertifika için beyan edilen ürünler için mevcut düzenleyici belgelerin seçimi ve incelenmesi, test yöntemleri ve sonuçların değerlendirilmesi gerçekleştirilir.

Başvuru sahibi, belirli bir zaman aralığında belgelendirme sırasında kalite sisteminin hangi unsurlarının, organizasyonel ve teknik faaliyetlerin alanları ve türlerinin doğrulamaya tabi olacağına dair nihai kararları verir. Başvuru sahibi, doğrulama süreçlerini desteklemek için koşullar oluşturmalı ve belgeler sunmalıdır. Üretim için ürünlerin geliştirilmesi ve piyasaya sürülmesi sırasında gerçekleştirilen test raporlarını, üçüncü taraf test laboratuvarları tarafından yapılan testlere ilişkin belgeleri ve teknolojinin veya ürünlerin belirlenen gerekliliklere uygunluğunu onaylayan diğer belgeleri belgelendirme kuruluşuna sunabilir. Belgelendirme kuruluşu, ürünlerinin belirlenmiş gerekliliklere uygunluğuna ilişkin başvuru ile birlikte sağlanan belgesel kanıtların analizine dayanarak, testlerin kapsamını daraltmaya veya bir sertifika vermeye karar verebilir.

Testler, yalnızca düzenleyici, akreditasyon belgelerinde belirtilen testleri yapmak üzere akredite edilmiş test laboratuvarları tarafından gerçekleştirilir. Akredite bir laboratuvarın test merkezinde testler yapmak mümkün değilse, test laboratuvarının kendi imkanları veya tedarikçiden temin edilebilecek test araçları kullanılarak bu ürünün üreticisi veya tüketicisinde bu laboratuvarın personeli tarafından testler yapılabilir.

Bir işletmenin yazılım ürünlerinin ve kalite sistemlerinin sertifikalandırılması süreci şunları içerir:

• sertifikasyon testlerini gerçekleştirmek için bu alanda yetkin bir kuruluş ve sertifikalı bir laboratuvarın geliştiricisi veya müşterisi (başvuru sahibi) tarafından analiz ve seçim;
• başvuru sahibi belgelendirme kuruluşuna test için bir başvuruda bulunur ve belgelendirme kuruluşları başvuru, belgelendirme planı seçimi, belgelendirme sözleşmesinin imzalanması hakkında karar verir;
• işletmenin kalite sistemi ve/veya test edilecek yazılım ürününün versiyonu için gereksinimlerin belirlenmesi;
• kuruluşun kalite sisteminin veya yazılım ürününün sürümünün belgelendirme testlerinin belgelendirme laboratuvarı tarafından gerçekleştirilmesi;
• elde edilen sonuçların analizi ve başvuru sahibine uygunluk belgesi verme olasılığı konusunda laboratuvar ve/veya belgelendirme kuruluşu tarafından karar verilmesi;
• sertifika kuruluşu tarafından başvuru sahibine verilmesi - uygunluk işaretinin kullanımı ve sertifikalı ürünlerin serbest bırakılması için bir sertifika ve lisans - yazılım ürününün sürümleri;
• işletmenin ve/veya ürünlerin belgelendirilmiş kalite sisteminin belgelendirme kuruluşu tarafından denetim kontrolünün uygulanması;
• kalite sistemi ve/veya ürünlerin süreçlerinin belirlenen şartlara uygunluğunu ihlal etmesi ve uygunluk işaretinin hatalı kullanılması durumunda başvuru sahibi tarafından düzeltici tedbirlerin alınması.

Geliştiricinin ürün kalitesi için yönetim sorumluluğunun gözden geçirilmesi, tesisin veya projenin belgelenmiş bir kalite politikasına, hedeflerine ve taahhütlerine sahip olup olmadığını ve ayrıca politikanın organizasyonun tüm seviyelerinde ne ölçüde anlaşıldığını, uygulandığını ve sürdürüldüğünü belirlemelidir. Kuruluşun, diğer görevleri ne olursa olsun, kalite sisteminin standartlarının ve düzenleyici belgelerinin gerekliliklerinin sürekli olarak uygulanması için yetki ve sorumluluğa sahip bir yönetim temsilcisine sahip olduğu belirlenmelidir. Kalite sistem süreçlerinin pratik uygulaması için gereksinimlerin, prosedürlerin, araçların ve eğitimli personelin mevcudiyetinin yanı sıra kalite sisteminin tüm bileşenleri, gereksinimleri ve hükümleri için dokümantasyonun uygunluğu ve düzenliliği kontrol edilmelidir. PS'nin yaşam döngüsü boyunca entegre süreç. Kalite sistem kontrolleri bir tanım içermelidir:

• teknolojik belgelerin mevcudiyeti ve eksiksizliği ve pratikte gereksinimlerine uygunluk;
• teknolojik ekipmanın durumu ve bunların bakımı için bir sistemin mevcudiyeti;
• kontrol ve test sisteminin mevcudiyeti ve etkinliği;
• ölçme ve test aletlerinin durumu;
• ürünlerde veya teknolojide tespit edilen eksiklikleri belirlemek ve ortadan kaldırmak için bir sistemin mevcudiyeti.

Testlere dayanarak, elde edilen sonuçlar değerlendirilir ve ürünlerin veya süreçlerin düzenleyici belgelerin gerekliliklerine uygunluğu veya uygunsuzluğu hakkındaki sonuçlar doğrulanır. Test raporları, belgelendirme kuruluşuna ve talebi üzerine başvuru sahibine sunulur. Test raporları, üç yıldan az olmamak üzere, ürün belgelendirme sistemleri kurallarında ve test laboratuvarının belgelerinde belirlenen süreler boyunca saklanmaya tabidir.

Test laboratuvarının uzmanları tarafından belgelerin eksiksizliği ve kalitesi alınıp kontrol edildikten sonra, kalite sisteminin gerçek uygulama derecesinin incelenmesi işletmede. Test, sonraki çalışmalar için bir iş planı olarak hizmet etmesi gereken bir kalite sistemi denetim programı ile başlar. Program, test laboratuvarının dahili bir çalışma belgesidir ve geliştiricinin özelliklerine göre detaylandırılmış ve sunulan kaynak belgelerin eksiksizliğinin ve kalitesinin bir analizini ve bunların pratik uygulama derecesini içeren çalışmaların bir listesini içermelidir. yazılım sistemlerinin tasarımı, geliştirilmesi ve teslimi. Kalite sistem prosedürlerinin uygulanmasının incelenmesi, PS'nin yaşam döngüsünü sağlayan işletmenin işyerlerinde test laboratuvarı tarafından gerçekleştirilir. İşyerinde ilgili belgelerin uzman-geliştiricilerinin mevcudiyeti ve hükümlerinin ve tavsiyelerinin kullanımının eksiksizliği üzerinde kontroller yapılır. Kalite sisteminin, süreçlerin ve/veya ürünlerin proje durum incelemeleri ve iç denetimleri, işten doğrudan sorumlu olanlardan bağımsız personel tarafından gerçekleştirilmelidir.

Geliştirme kalite kontrol metodolojileri test programı, planlama yöntemleri ve özel muayene prosedürlerinin geliştirilmesi için gerekli kaynaklar sağlanmalıdır. Yöntemler şunları içermelidir: testin nesneleri ve amaçları; değerlendirilmiş kalite göstergeleri; test koşulları ve prosedürü; test sonuçlarının işlenmesi, analizi ve değerlendirilmesi yöntemleri; teknik desteği ve raporlamayı test edin. Testler ve test prosedürü sırasında kullanılan donanım ve yazılım ile beklenen test sonuçları belirtilmelidir. Denetim yönetim hizmeti tarafından böyle bir talep alınırsa, düzeltmeleri izleme yöntemleri, kusurları düzeltmeye yönelik eylemler geliştirilmelidir. Test programı yönetim hizmeti, uzmanlar tarafından tutulan verilerin yanı sıra herhangi bir test bilgisinin gizliliğini korumak için yöntemler geliştirmelidir.

Test raporları başvuru sahibine ve belgelendirme kuruluşuna sunulur. Başvuru sahibi, üretime yönelik ürünlerin geliştirilmesi ve piyasaya sürülmesi sırasında gerçekleştirilen geçerlilik koşullarını dikkate alarak test raporlarını veya sertifikasyonda akredite veya tanınmış yerli veya yabancı test laboratuvarları tarafından yapılan testlere ilişkin belgeleri belgelendirme kuruluşuna sunabilir. sistem. Sertifikasyon test protokollerine dayalı olarak elde edilen sonuçlar değerlendirilir ve ürünlerin düzenleyici belgelerin gereklerine uygunluğu veya uygunsuzluğu hakkında çıkarılan sonuçlar doğrulanır.

Sertifikasyon testlerinin sonuçları hakkında sonuç sertifika verenler tarafından geliştirilmiştir ve test sonuçları ve sertifika verilmesinin tavsiye edilebilirliğinin gerekçesi hakkında genelleştirilmiş bilgiler içerir. Belgelendirme testlerinin olumsuz sonuçlanması durumunda, uygunluk belgesi vermeyi reddetme kararı verilir. Sertifikalı ürün veya kalite sistemi revize edildikten sonra testler tekrarlanabilir. Teknoloji durumu veya ürün kalitesi analizinin sonuçları bir kanunla resmileştirilmiş Test Programının tüm öğeleri için değerlendirmeler sağlayan ve aşağıdakiler de dahil olmak üzere sonuçları içeren Genel değerlendirmeüretim ve ürünlerin durumu, düzeltici önlemlere duyulan ihtiyaç. Yasa, belgelendirme kuruluşu tarafından, test raporları, bir yazılım ürünü için bir sertifikanın geçerlilik süresinin düzenlenmesi ve belirlenmesi için bir başvuru, denetim kontrolünün sıklığı ve ayrıca düzeltici önlemler almak için kullanılır.

Belgelendirme testlerinin sonuçlarına ve belgelerin incelenmesine dayanarak, bir sertifika verilmesine karar verilir. Belgelendirme testlerinin olumsuz sonuçlanması durumunda, bir karar verilir. sertifika vermeyi reddetme uyma. Ayrıca, başvuru sahibi işletmeye olumsuz test sonuçlarının iddia edilen nedenlerini ortadan kaldırmak için teklifler gönderilebilir, sertifikalı ürün tamamlandıktan sonra testler tekrarlanabilir.

Belgelendirme kuruluşu, test raporlarını inceledikten, üretimi değerlendirdikten, kalite sistemini belgelendirdikten, başvuru kararında belirtilen belgeleri inceledikten sonra, ürünlerin belirlenen şartlara uygunluğunu değerlendirir, uzman görüşüne dayalı olarak bir sertifika düzenler ve tescil eder. . Belgelendirme sırasında belgelendirilen sistem veya yazılım ürününün kalitesini etkileyebilecek tasarım veya operasyonel belgelerde değişiklik yapıldığında, başvuru sahibi ek testlerin gerekliliğine karar vermek için belgelendirme kuruluşunu bilgilendirmelidir. Kayıttan sonra sertifika yürürlüğe girer ve başvuran şirkete gönderilir. Sertifikanın düzenlenmesi ile eş zamanlı olarak, başvuru sahibi işletmeye ihraç edilebilir. lisans uygunluk işaretini kullanma hakkı için.

Sertifikalı yazılım ürünleri için uygunluk belgesinin geçerlilik süresinin tamamı boyunca işletimleri sırasında, muayene kontrolü... Denetim kontrolü, teknoloji ve sertifikalı ürünlerin kalitesi gerekliliklerine uygunluğun periyodik ve plansız denetimleri şeklinde gerçekleştirilir. Sertifikasyon şemasına bağlı olarak kontrol nesneleri, sertifikalı ürünler, kalite sistemi veya geliştiricinin üretim kararlılığıdır. Frekans ve hacim belirlenirken muayene kontrolü aşağıdaki faktörler dikkate alınır: yazılım ürününün potansiyel tehlike derecesi, üretimin kararlılığı, üretim hacmi, geliştirme sırasında bir kalite sisteminin varlığı ve uygulaması, ürün testlerinin sonuçları ve sonuçları hakkında bilgi. üretici, yetkililer tarafından gerçekleştirilen üretim devlet kontrolü ve gözetim.

Muayene kontrol sonuçları bir kanunla resmileştirilmiş Numune testleri ve diğer denetimlerin sonuçlarını değerlendiren , sertifikalı ürünlerin üretim durumu ve verilen sertifikanın geçerliliğini koruma olasılığı hakkında genel bir sonuca varır. Yasa, belgelendirme kuruluşu tarafından saklanır ve kopyaları geliştiriciye ve denetim kontrolünde yer alan kuruluşlara gönderilir. Belgelendirme kuruluşu, muayene kontrolünün sonuçlarına dayanarak, ürünün kontrol edilen düzenleyici belgelerin gerekliliklerine uygun olmaması durumunda, uygunluk işaretinin kullanım hakkı için belgenin geçerliliğini askıya alabilir veya iptal edebilir ve lisansı iptal edebilir. sertifika ve ayrıca aşağıdaki durumlarda:

• olgunluk modelinde, standartların profilinde, ürün düzenlemelerinde veya test yönteminde temel değişiklikler;
• tasarımdaki (kompozisyon) değişiklikler, ürünlerin eksiksizliği;
• geliştirme ve üretim organizasyonu veya teknolojisindeki değişiklikler;
• teknoloji gereksinimlerine, kontrol ve test yöntemlerine, kalite sistemine uyulmaması, listelenen değişiklikler ürünlerin sertifikasyon sırasında kontrol edilen gereksinimlere uygun olmamasına neden olabilir.

Uygunluk işaretini kullanma hakkı için sertifika ve lisansın geçerliliğini askıya alma kararı, başvuru sahibi, onu veren belgelendirme kuruluşu ile kararlaştırılan düzeltici önlemler yoluyla, uygunsuzluğun keşfedilen nedenlerini ortadan kaldırabilir ve akredite bir laboratuvarda yeniden test etmeden ürün veya süreçlerin düzenleyici belgelere uygunluğunu teyit edin. Bu yapılamazsa, sertifikanın geçerliliği iptal edilir ve uygunluk işaretini kullanma hakkı lisansı iptal edilir. Belgenin askıya alınması veya iptali ile ilgili bilgiler, belgeyi veren belgelendirme kuruluşu tarafından başvuru sahibinin, tüketicilerin ve diğer ilgili kuruluşların dikkatine sunulur. Sertifikanın geçerliliği ve uygunluk işaretine sahip ürünleri markalama hakkı, geliştirici işletme aşağıdaki koşulları yerine getirdiği takdirde yenilenebilir:

• uygunsuzluk nedenlerinin belirlenmesi ve ortadan kaldırılması;
• ürün kalitesini iyileştirmek ve sağlamak için yapılan çalışmalar hakkında bir raporun belgelendirme kuruluşuna sunulması;
• ürünlerin ek testlerinin metotlara göre ve belgelendirme kuruluşunun kontrolünde yapılması ve olumlu sonuç alınması.

Yazılım ürünlerinin sertifikasyon süreçlerinin ve sonuçlarının belgelenmesi

Kalite sisteminin belgelendirilmesi için belgelerin bileşimi ve içeriği işletmeler, yazılımın tasarımının, geliştirilmesinin ve değiştirilmesinin özelliklerine ve ayrıca kalite gereksinimlerine ve teknolojik ortamın özelliklerine bağlıdır. Bu nedenle, her bir işletme veya proje için gerekli belge seti bu özelliklere göre seçilmeli ve uyarlanmalıdır. Belgelendirme sırasında değerlendirilen kalite sisteminin göstergeleri, ilgili belgelerin mevcudiyeti ve olgunluk modelinin belirli bir seviyesinin gerekliliklerinin pratik olarak yerine getirilmesidir. CMMI veya buna dayalı uyarlanmış bir standart profili ISO 9000: 2000, ayrıca, geliştirici işletmenin uzmanları tarafından temel alınarak oluşturulan iş tanımları. Başvuru sahibi, düzenleyici belgelere uygun olarak güvenilirliğini, kompozisyonunun yeterliliğini ve üretim kalitesini kontrol etmek için müşteri ve geliştirici arasında üzerinde anlaşmaya varılan bir dizi belge ve onaylanmış bir belge seti hazırlamalı ve test laboratuvarına sunmalıdır.

Sertifikasyon için gösterge niteliğindeki temel belgeler seti üç gruptan oluşur:

• temel düzenlemeler kalite sistemlerine dayalı standartlar profilinin terminolojisine ve içeriğine uygun olarak ISO 9000: 2000 veya olgunluk modelleri CMMI, geliştiriciler tarafından bunlara dayalı olarak hazırlanan, denetlenen işletmenin kalite sisteminin veya ürünlerinin testçilerine (uzmanlarına) sunulan program, el kitabı ve talimatların yanı sıra;
• belirli bir işletmeyi veya projeyi karakterize eden kaynak belgeler ve ayrıca proje yönetimi tarafından kalitesinin belgelenmesi için hazırlanan bir yazılım aracının yaşam döngüsü;
• kuruluşun kalite sisteminin ve / veya yazılım ürününün doğrulama (belgelendirme) sonuçlarını yansıtan, belgelendirme kuruluşuna, başvuru sahibine ve denetlenen kuruluşun yönetimine sunulan testçilerin raporlama belgeleri.

Belgelendirme için sunulan işletmenin yazılım ürünü veya kalite sistemi, ilgili belgelerle birlikte sunulmalıdır. Bu belge gruplarının listesi ve yaklaşık içeriği, büyük yazılım ürünlerinin yaşam döngüsünü sağlayan işletmelerin kalite sistemlerinin kontrol edilmesinin genel durumuna odaklanmıştır. Belge seti, yazılım projelerinin özelliklerine uygun olarak başvuru sahibi, onaylayıcı ve denetlenen işletmenin yönetimi arasındaki anlaşma ile azaltılabilir ve uyarlanabilir. Bazı belgeler, uygulamaları için belirli uzmanların açık sorumluluğu ile entegre raporlarda birleştirilebilir.

Kurumsal kalite sisteminin temel belgeleri ve bir yazılım aracının yaşam döngüsü

1. Performans iyileştirme için konsept, terminoloji, gereksinimler ve rehberlik - kalite yönetim sistemleri - ISO 9000: 2000 veya CMMI olgunluk modelinin bir versiyonu.
2. Uyarlanmış versiyonlar veya madde listesi ve standart tavsiyeleri ISO 12207, ISO 15504 Uyarlama sırasında vurgulanan ve belirli bir işletme veya yazılım ürünü projesinin kalite sisteminde kullanılması zorunlu olan değişiklikleri ve uygulama kılavuzları.
3. Standardın uyarlanmış versiyonu veya maddelerinin ve tavsiyelerinin listesi ISO 900003 Adaptasyon sırasında tahsis edilen ve yazılım ürünü üreten bir işletmenin kalite sisteminde kullanılması zorunludur.
4. Standartlar temelinde vurgulanan, uyarlanan ve belirtilen PS projesinin temel özellikleri ve kalite nitelikleri ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. Standartların tavsiyelerine dayalı olarak bakım ve konfigürasyon yönetimine ilişkin kılavuzun uyarlanmış bir versiyonu ve onaylanmış bir baskısı ISO 14764, ISO 10007, ISO 15846.
6. Belirli bir PS projesi için kurumsal kalite sistemi prosedürlerine katılan personelin çalışmalarını gerçekleştiren ve kontrol eden tüm yönetimin etkileşimi için sorumluluk, yetki ve prosedürü tanımlayan bir dizi iş tanımı.

Belirli bir yazılım aracının yaşam döngüsünün özelliklerini yansıtan kaynak belgeler

1. PS projesinin standartlarının ve gereksinimlerinin çalışma sürümlerinin uyarlanması ve hazırlanması için gerekli olan işletmede oluşturulan yazılım ürünlerinin özelliklerinin, sistem ve yaşam döngülerinin dış ortamının tanımı ve kurumsal kalite sistemi. standart tavsiyeleri ISO 12207, ISO 15504, ISO 90003 ve ISO 9126.
2. Kurumsal geliştiricinin kalite sistemi alanındaki amaçlarının, gereksinimlerinin ve yükümlülüklerinin tanımı, yazılım sisteminin tüm yaşam döngüsünün geliştirilmesi, teslimatı ve desteklenmesi süreçleri ve ürünleri için kalite kriterleri.
3. Uyarlanmış standartlara dayalı olarak yazılım ürününün belirli bir sürümünün yaşam döngüsünü ve kullanımını sağlamak için müşteriye ve kullanıcılara sağlanan bir dizi operasyonel belge ISO 9294, ISO 15910, ISO 18019.
4. Bir yazılım ürününün yaşam döngüsünü sağlamak için kullanılan tasarım, geliştirme, değişiklik, kontrol ve test için dokümantasyon ve otomasyon araçları.
5. Uygulamayı test etmek ve kurumsal kalite sistemi ve yazılım ürününün süreçlerinin etkinliğini değerlendirmek için planlar ve yöntemler.
6. Bakım yöntemleri, yazılım ürünü bileşenlerinin ve belgelerinin tanımlanması, yazılım ve veri komplekslerinin sürümlerinin analizi ve onayı.
7. Bir yazılım ürününün sürümlerinin ve beraberindeki belgelerin konfigürasyon yönetimi, onaylanması, depolanması, korunması, kopyalanması ve bir yazılımın sürümlerinin yaşam döngüsü boyunca bir işletmenin arşivinde kayıtlı kalite özelliklerine ilişkin verilerin toplanması ve depolanması için bir metodoloji ürün.

Ortaya çıkan test belgeleri - işletmenin kalite sisteminin ve/veya yazılım ürününün belgelendirilmesi

1. Bir yazılım ürününün tüm yaşam döngüsü boyunca entegre bir kalite güvence süreci sağlayan, kurumsal kalite sisteminin gereksinimlerine ve hükümlerine uyarlanmış, dokümantasyonun mevcudiyeti, uygunluğu ve sistematikliği hakkında bir rapor.
2. Uygunluğunu ve etkinliğini belirlemek için periyodik olarak yürütülen kalite sisteminin durumu ve uygulamasının izlenmesi ve test edilmesinin sonuçları.
3. Muayene prosedürlerinin mevcudiyeti ve bakımı hakkında rapor ve müşteriyle yapılan sertifikasyon anlaşmasının gerekliliklerini karşılamanın elde edilen kalitesinin sonuçları hakkında belgelenmiş raporlar.
4. Yazılım paketinin elde edilen kalite özelliklerinin kaydının sonuçları: yazılım ürününün ve bileşenlerinin kalitesinin özellikleri ve nitelikleri hakkında kayıtlı verilerin tanımlanması, toplanması, depolanması.
5. Geliştirme planının uygulanmasının sonuçları, geliştirme aşamalarının belgelenmiş girdi ve çıktı verileri ve yazılım yaşam döngüsünün uygulanmasını doğrulamak için protokoller.
6. Kalite programının pratik uygulamasının sonuçları ve PS yaşam döngüsünün tüm aşamalarında kalite alanında düzenlenmiş faaliyetlerin uygulanması.
7. Çevresel simülatörlerin ve test üreticilerinin sertifikasyonu sonuçları ve bir yazılım ürününün sertifika testlerini gerçekleştirmek için yeterliliklerinin değerlendirilmesi.
8. Planların ve test yöntemlerinin uygulanmasına ilişkin analiz sonuçları, test raporları, test sonuçlarının gerekliliklere uygunluğunun değerlendirilmesi ve ayrıca başvuru sahibi, müşteri ve tedarikçi temsilcileri tarafından onaylanan test sonuçları.
9. Yazılımın yaşam döngüsünün gerçek özelliklerinin ve işletmenin kalite sisteminin kontrollerinin sonuçlarının eylemi, bunların bir yazılım ürününün üretiminin sertifikalandırılması gerekliliklerine uygunluğuna ilişkin sonuçlar.
10. İşletmenin ve/veya yazılım ürününün kalite sistemi belgesi ve yaşam döngüsünün sağlanması, uygunluk işaretlerinin kullanım lisansı.

Edebiyat

V.V. Lipaev - Yazılım yaşam döngüsü standartları profilleri. -- Jet Bilgisi, Bülten, N 12, 2005

K. Milman, S. Milman - СММI - geleceğe bir adım. -- Açık sistemler., N 5-6. (2005), N2. (2006), 2005, 2006

Yazılım ve bilgi sistemleri ISO IEC TR 15504-CMMI oluşturmak ve sürdürmek için süreçlerin olgunluğunun değerlendirilmesi ve onaylanması. Başına. İngilizceden -- M.: Kitap ve iş, 2001

V.V. Lipaev - Karmaşık yazılımların yaşam döngüsü için süreçler ve standartlar. Dizin.- E.: SINTEG, 2006

V.V. Lipaev - Büyük ölçekli yazılımlar için kalite güvence teknikleri.- M.: RFBR. SENTEG, 2003

"; antisource:" Yazılım ürünleri artık insan faaliyetinin neredeyse tüm alanlarındaki yönetim sorunlarını çözmek için kullanılıyor: ekonomi, sosyal, askeri ve diğer alanlarda. Yurtiçinde ve dünya pazarında çeşitli uygulama alanları için toplu geliştirme ve teslimat sırasında yerli yazılım ürünlerinin yüksek kalitede olmasını sağlamak stratejik bir görev haline gelmiştir. "; Durum: 1] $