V. Ilyin.

Șeful serviciului de calitate al companiei TopSBI

„Dacă faci ceva

greșit - nu este necesar
așteptați-vă la rezultatul corect.”

Înțelepciunea populară chineză

Soluție cuprinzătoare la problemele de asigurare a calității instrumente software presupune dezvoltarea și implementarea unui anumit sistem de management al calității (Sistemul de management al calității - QMS). În practica mondială, cel mai răspândit este sistemul bazat pe cerințele standardelor internaționale. Seria ISO 9000, deoarece definește cu exactitate cele mai generale cerințe, inclusiv pentru sistemele software, și astfel, în general, deja predetermina maturitatea inițială a proceselor care este necesară pentru a se conforma cu multe modele și standarde industriale din domeniul IT .

Dar întrebarea dacă introducerea unui sistem de calitate și certificarea de succes garantează lansarea unui produs de calitate trebuie să primească un răspuns sincer - „nu”.

Subliniind că ISO 9000 este o „idee grozavă”, Gartner Group recomandă ca certificarea ISO 9001 să fie privită doar ca un punct de plecare pe drumul către calitate (1).

Acesta stabilește un fel de „schelet” al sistemului calității, iar umplerea acestui sistem cu „mușchi” (conținut profesional bazat pe standarde și metodologii deja speciale, precum CMM) poate oferi un nivel de calitate care să corespundă pieței în creștere. cerințe.

În legătură cu cele de mai sus, atât din punct de vedere metodologic, cât și din punct de vedere practic, mulți experți în domeniul managementului calității consideră oportună construirea unei strategii de dezvoltare a companiilor IT astfel:

Mai întâi, dezvoltați și implementați un QMS bazat pe modelul ISO 9001: 2000. (La urma urmei, majoritatea companiilor care se află acum la nivelurile 4 și 5 ale SW-CMM, au trecut mai întâi prin a-și aduce procesele în conformitate cu modelul ISO. După cum arată practica, acest lucru cea mai bună opțiuneîn ceea ce priveşte gestionarea dezvoltării SMC şi reducerea riscurilor).

Și abia apoi începe să dezvolte și să implementeze procesele cheie ale modelului SW-CMM și mai departe, dacă este necesar, modelul CMMI.

Pentru a înțelege cum este cu adevărat corect, să comparăm aceste modele.

1. Analiza solicitanților.

Vom duce la îndeplinire scurtă recenzie cele mai populare standarde care pot fi folosite de o companie IT pentru a-și optimiza procesele de afaceri.

ISO 9001. Cel mai popular, și mai ales în Europa, este ISO 9001 (2)

În același timp, metodic, în deplină concordanță cu disciplina construcției sisteme complexe, standardul ISO 9001 prevede, pe de o parte, construcția sistem organizatoric„de sus în jos”: de la scopurile întreprinderii și politicile acesteia – până la structura organizatorică și formarea proceselor de afaceri, iar pe de altă parte – dezvoltarea iterativă a sistemului organizațional prin mecanismele de măsurare și îmbunătățire.

În termeni mai simpli, „calitate”, conform seriei de standarde ISO 9000, este o situație în care consumatorii primesc de la un producător produse care îndeplinesc cerințele lor directe și așteptările latente. Prin urmare, managementul calității, în conformitate cu ISO 9000, presupune utilizarea așa-numitului. „abordare proces”, atunci când cel mai optim lanț de „procese-transformare” este modelat și implementat, asigurându-se că nevoile consumatorilor sunt percepute de producător și concretizate în orice produs fără distorsiuni.

Această serie binecunoscută de standarde ISO 9000 a fost folosită cu succes de multe organizații de software. O noua versiune standardele acestei serii au fost lansate în anul 2000 și conțin deja concepte precum abordarea procesului, analiza și măsurarea, îmbunătățirea proceselor, împrumutate din modelul CMM și absente anterior în versiunile anterioare ale ISO 9000. Cu toate acestea, trebuie menționat că standardele ale acestei serii sunt universale - nu sunt concentrate pe nicio industrie anume, nu țin cont de specificul sferei IT și, în acest sens, desigur, în ceea ce privește gradul de concretizare, sunt vizibil inferioare SMM. În plus, ISO 9000 nu implică gradări (nivele) de conformitate și, astfel, face dificilă determinarea capacităților „adevărate” ale unei organizații și, în consecință, - modalități de dezvoltare ulterioară a acestora.

CMM(Capability Maturity Model) a fost dezvoltat de Institutul de Inginerie Software de la Universitatea Carnegie Mellon (SUA) și descrie un model de maturitate pentru procesele de dezvoltare software la întreprinderi (3). În cadrul acestui model, pentru fiecare companie se poate compara un anumit nivel (unul din cinci posibil), indicând calitatea atinsă a procesului de dezvoltare software. Deoarece aceste standarde au fost dezvoltate în primul rând pentru a eficientiza procesul de selecție a contractorilor pentru Departamentul Apărării al SUA, ele se concentrează pe procesele de management al proiectelor software, în timp ce aspectele tehnice ale dezvoltării sunt mai puțin acoperite.

Există 316 de practici cheie în SW-CMM v.1.1 (Model de maturitate a capacităților pentru software). Practicile cheie sunt ceea ce ar trebui implementat în întreprindere și la care echipa de evaluare a procesului va acorda atenție. Aceștia sunt uniți în zona - Key Practices Areas (KPA) - acesta este deja un set de procese interconectate care, atunci când sunt realizate în comun, duc la atingerea unui anumit set de obiective.

CMMI(Capability Maturity Model Integration) - dezvoltarea în continuare a modelului CMM. În CMMI-SE / SW Versiunea 1.02 (CMMI for Systems Engineering / Software Engineering), poate cea mai acceptabilă pentru dezvoltatori sisteme software, - numărul practicilor cheie a ajuns deja la 417.

Creșterea practicilor cheie este legată de scopul însuși al dezvoltării CMMI - modelul ar trebui să ajute la evitarea problemelor asociate cu utilizarea diferitelor modele CMM din industrie.

(Din 1991, CMM-urile au fost dezvoltate pentru o varietate de aplicații, cele mai semnificative fiind:

Model de maturitate a capabilităților pentru software (SW-CMM)
- model de maturitate a procesului pentru reinginerirea sistemului (Electronic Industries Alliance Interim Standard - EIA / IS 731)
- model de maturitate a proceselor de dezvoltare integrată a produsului Integrated Product Development Capability Maturity Model - IPD-CMM)

Pe baza acestor modele a fost construit CMMI. El a absorbit cele mai bune dintre aceste modele, eliminând ambiguitatea în interpretarea unor concepte din cauza prezenței multor modele - prin urmare, numărul practicilor cheie a crescut semnificativ).

Este clar că acesta s-a dovedit a fi un model mult mai „greu” - vezi. Orez. unu, care, de altfel, nu a fost încă suficient testat în practică (a apărut abia în 2002). În acest sens, în opinia mea, la implementarea modelului, există posibile riscuri mari asociate atât cu pierderi nejustificate în viteza de dezvoltare a software-ului, cât și cu o creștere simultană neechivocă a costurilor cu forța de muncă pentru funcționarea (și suportul) KPA implementat. - vedea. Fig 1. Pentru mine, ca practician care a construit deja un SMC în trei profiluri diferite de companii IT, mi se pare că modelul CMMI este în mod clar dezechilibrat între necesar și suficient - personalul companiei IT (și acestea , de regulă, sunt în mare parte „artişti de cod”), pur şi simplu nu va „accepta pentru executare” un asemenea număr de reglementări controlate (există un risc foarte mare de a construi un „sat Potemkin”)!

Orez. 1 Comparația compoziției KPA în modelele CMM și CMMI.

În plus, evaluarea pentru CMMI va fi semnificativ mai scumpă, de când a fost autorizată SEI Evaluator principal" Până acum vor fi foarte puține, iar aceste servicii vor fi mult mai scumpe decât la evaluarea conformității cu modelul CMM.

Mai mult decât atât, mulți experți străini în domeniul managementului calității, (cu părerea cărora sunt pe deplin de acord în acest moment), sunt mai degrabă sceptici cu privire la CMMI în contextul utilității sale pentru implementarea în organizațiile mici și mijlocii (acestea sunt organizațiile care sunt doar tipice pentru Rusia). Există chiar o opinie că după un timp SEI va trebui fie să lanseze un SW-CMM v.2 adaptat, fie să facă niște pași similari. Acestea. în cazul în care piața nu acceptă modelul și astfel de condiții prealabile sunt deja în vigoare la momentul scrierii acestui articol, atunci SEI va trebui să se adapteze la cerințele pieței.

În legătură cu cele de mai sus, pare oportun să analizăm echilibrul deja menționat al necesarului și suficient în toate aceste modele de bază de SMC.

Să o desenăm în următoarele coordonate (vezi. Orez. 2) :

gradul de reglare a proceselor de dezvoltare - să desemnăm acest concept - RP,

probabilitatea de a obține rezultatele planificate - să desemnăm acest concept - PQ.

În fig. 2 prezintă o evaluare expertă a echilibrului gradului de reglementare și a probabilității de a obține rezultatele planificate, realizată de autor pe baza rezultatelor practicii de introducere a cerințelor acestor modele în dezvoltarea și implementarea sistemelor software ( software).

În termeni matematici, mărimea derivatei este: F (Q) = dPQ \ dRQ(creșterea eficienței în atingerea calității dPQ cu o creștere a costului timpului de lucru pentru a sprijini îndeplinirea cerințelor dRQ), scade, respectiv, în următoarea succesiune : ISO 9000, CMM, CMMI.

Prin urmare, Fig. 2 explică clar și simplu:

popularitatea modelului ISO 9000,

corectitudinea metodologiei: mai întâi ISO și abia apoi, dacă este necesar, CMM,

oarecare scepticism cu privire la eficacitatea modelului CMMI.

Orez. 2 Analiza echilibrului dintre gradul de reglementare și probabilitatea de a obține rezultatele planificate (conform evaluării expertului autorului)

Să luăm acum în considerare încă un ghid care este utilizat pe scară largă în companiile IT și care va fi menționat mai jos atunci când vom analiza problemele practicii de implementare a SMC.

Acest PMBoK(Ghid pentru Management de proiect Corpul de cunoștințe) este proiect de proiect Management Institute, care a absorbit cunoștințele acumulate în domeniul managementului de proiect. Ultima versiune a documentului a fost publicată în 2000 și, în același timp, a primit statutul de standard al Institutului American de Standardizare ANSI (deși standardele ANSI și IEEE sunt considerate oficial americane, majoritatea sunt de facto de natură internațională). O caracteristică importantă a PMBоK este că ia în considerare managementul de proiect într-un sens general, fără referire la domenii specifice, cum ar fi IT, și, prin urmare, nu poate fi aplicat independent - mai jos vom analiza ce efect dă acest lucru atunci când este utilizat împreună cu ISO 9000.

Să luăm acum în considerare modul în care cerințele standardului deja popular ISO 9001: 2000 se raportează la proprietățile generale ale modelului CMM din ce în ce mai popular. {3}- cm. Orez. 3.

Orez. 3. Corespondența dintre proprietățile generale ale CMM și elementele ISO 9001: 2000

Fiecare nivel al SMM, așa cum sa menționat mai sus, este caracterizat de un set domenii ale proceselor cheie - KPA (Key Process Areas) - cm. Fig. 3. Atingerea tuturor obiectivelor din interior KPA pentru un anumit nivel, CMM determină conformitatea organizației cu acel nivel. Dacă cel puțin o țintă este cel puțin una KPA pentru nivelul CMM nu este atins, atunci organizația nu poate îndeplini acest nivel CMM. KPA poate fi împărțit în trei categorii: directori generali , organizatoric și furnizarea (cm. Orez. 4).

CMM nu definește toate procesele legate de dezvoltarea software; evidențiază doar pe cele care sunt necesare pentru atingerea nivelului SMM și sunt incluse în KPA... Fiecare KPA este împărțit în 5 caracteristici comune: Comentariu de efectuat; Abilitatea de a performa; Activități desfășurate; Măsurare și Analiză; Verificarea implementării

proprietate generala" Acțiuni efectuate " descrie acțiunile care trebuie efectuate pentru atingerea scopurilor KPA, celelalte patru proprietăți generale descriu factorii formali care fac parte din procesul cultura organizationala... împlinirea deplină a tuturor practica cheie a tuturor proprietăţilor comune asigură realizarea scopurilor KPA... Practicile de operare cheie descriu ce ar trebui să devină un flux de lucru (sau un element de proces sau o parte a unei infrastructuri), dar nu definesc o modalitate de a realiza ( tehnologii specifice sau tehnici), deși sunt date linii directoare generale pentru unele tehnici. Pentru conditii diferite același rezultat poate fi obținut în moduri diferite. Este mai degrabă principii generale muncă decât acțiune concretă.

Implementarea secvențială a proprietăților comune implementează de fapt un ciclu de îmbunătățire a proceselor de afaceri (Buisness-process Improvement - BPI-cm. Orez. 5.), adică îmbunătățirea continuă a proceselor de afaceri (BP).

Orez. 5. Ciclul de îmbunătățire continuă a proceselor de afaceri conform modelului CMM și ISO 9000:2000.

Dorința de a obține un certificat de conformitate în cel mai scurt timp posibil obligă firmele de consultanță și specialiștii în managementul calității să folosească flexibilitatea și cadrul cerințelor tuturor modelelor de nivel înalt enumerate în propriile scopuri „mercenare”.
Ca urmare a acestei forțari a evenimentelor, o organizație, de exemplu, care a primit un certificat conform ISO 9000: 2000, are doar setul minim necesar de procese pentru conformitatea cu ISO 9001 și nu toate procesele de care compania are nevoie pentru a le asigura. functioneaza eficient – ​​vezi. Orez. 2... În plus, nivelul de detaliu al proceselor poate să nu fie suficient pentru o înțelegere clară a ceea ce se întâmplă în interiorul proceselor și cine este responsabil pentru ce sarcini din cadrul procesului.
V cel mai bun caz doar câteva proiecte de testare au trecut prin noile proceduri și, după ceva timp, devine clar că acestea trebuie corectate și completate. Adesea, imediat după certificarea SMC, procesele sunt uitate până la următorul audit de supraveghere, uitându-se în același timp de cheltuielile cheltuite. resurse financiare si entuziasmul personalului.
Într-adevăr, atunci când acționează ca auditor independent, este foarte dificil să se demonstreze că nivelul acceptat de detaliu al procesului nu este în mod clar suficient pentru funcționarea eficientă a SMC al companiei. Însă este extrem de dificil să demonstrezi contrariul în timpul alocat auditului conform ISO 9000 (aceasta poate fi folosit cu mare succes atunci când te opune auditorului). Practica arată că este imposibil să construiți rapid procese eficiente chiar și la al 3-lea nivel de maturitate (precum și procese bazate pe ISO 9000).
Pentru a realiza acest lucru, nu este suficient să descriem pur și simplu procesele ținând cont de cerințele modelului ales. Cea mai mare provocare este că trebuie reproiectează cultura producţiei în cadrul organizaţiei .

Și este imposibil să faci asta printr-o decizie puternică a conducerii. Acesta este motivul pentru care abordarea definită în CMM este pur și simplu mai viabilă și mai realistă decât modelele ISO 9000-cm. Orez. 5.

Să ne gândim acum cum, în practică, puteți construi un SMC compatibil cu ambele modele.

O evaluare de specialitate a gradului de acoperire a proceselor cheie CMM cu cerințele ISO 9000: 2000, în conformitate cu evaluarea autorilor CMM înșiși (4), este prezentată în Fig. 6.

Evaluarea propriu-zisă a fost efectuată de aceștia în două coordonate:

gradul de menținere (în%) conformitatea proceselor de dezvoltare (SWP) cu nivelul de maturitate din cadrul CMM - " Securitate ";

gradul de fezabilitate (în%) a unei astfel de disponibilitate, care este prevăzut de ISO 9000: 2000 - " oportunitate".

După cum se vede din Orez. 6, Cerințele ISO 9000: 2000 creează oportunitate reală pentru a atinge chiar și nivelul de maturitate SWP superior (CMM Level 5).

Totuși, în sensul de a asigura deja maturitatea SWP cel puțin al treilea nivel (CMM Nivel 3), SMC conform modelului ISO 9000: 2000 trebuie să fie ușor modificat - și anume, să dezvolte și să implementeze încă două proceduri organizaționale ( Definirea procesului organizatoricși focalizare) și procedură management general (Management software integrat ), al cărui conținut nu este dificil pentru nicio companie IT.

Dar este posibil și necesar să mergem mai departe (CMM Nivelul 4) - de exemplu, evaluarea autorului acestui articol (în aceleași coordonate - disponibilitate și capabilități) este prezentată între paranteze, ceea ce corespunde QMS conform ISO 9000: Modelul 2000, în care peisajul proceselor al SMC este completat cu managementul proiectelor de procese în conformitate cu cerințele celuilalt standard menționat anterior PM Bok- acest lucru vă va ajuta să creșteți semnificativ maturitatea chiar și a acestora SWP, Cum:

Monitorizarea progresului proiectelor (urmărirea și supravegherea proiectelor software);

• Planificarea proiectelor (Planificarea proiectelor software);

Management software general (Gestionare software integrat);

Managementul cantitativ al procesului.

Orez. 6. Evaluarea de către experți a gradului de acoperire a proceselor cheie CMM cu cerințele ISO 9000: 2000

După cum se vede din Fig. 6., modelul CMM din punct de vedere al principiilor stabilite în acesta este foarte apropiat de QMS construit conform standardului ISO 9001: 2000 și completat de procese de management de proiect în conformitate cu PM BoK..

Pentru a nu face muncă în plus cu certificare simultană conform ISO 9000 și evaluare ulterioară conform CMM, vă recomand ca atunci când vă definiți procesele de producție să includeți (sau poate să le limitați - până la urmă, asta este pentru o companie de IT și există procese de producție!) printre ele pe toate necesare în modelul CMM KPA. Astfel, compania în același timp:

îndeplinește cerințele ISO 9001: 2000 privind implementarea abordării procesuale;

toate documentele necesare CMM procese ( KPA);

implementează în același timp o serie de cerințe atât de importante ISO 9001: 2000 Cum:

controlul procesului bazat pe metrici (Managementul proceselor cantitative);

Managementul furnizorilor pe baza managementului subcontractelor ( Gestionarea subcontractelor software );

analiza cerințelor Consumatorului pe baza y cerinţele de management ( Managementul cerințelor );

managementul resurselor umane bazat pe Programe de formare a personalului (Program de formare );

managementul comunicarii bazat pe Construire model formal procesele organizatorice ( Definirea procesului organizatoric );

lansează mecanismul de îmbunătățire (Planificați-Efectuați-Verificați -Acțiune) toate procesele descrise (SWP) prin implementarea secvenţială a tuturor celor cinci Aspecte comune-cm. Orez. 5.

Astfel, dacă utilizați KPA CMM ca BP și utilizați cerințele pentru procedurile de management de proiect pentru dezvoltarea sistemelor software PM BoK, atunci QMS construit în acest fel poate fi estimat la CMM Nivel 4 - cm. Orez. 7.

Orez. 7. Schema de realizare a CMM Nivelul 4 la utilizarea modelului QMS conform ISO 9000 și manualul PM BoK 2000.

În concluzie, din motive de claritate (stilizată de autor), vă prezint o schemă de funcționare a SMC al unei companii IT cu implementarea consecventă a modelelor ISO 9000 și CMM – vezi. Orez. opt.

Orez. 8. Diagrama de funcționare a SMC cu implementarea secvențială a modelelor ISO 9000 și CMM (stilizat de autor)

Este important să înțelegem aici că atât CMM, cât și ISO 9001: 2000 sunt în sine doar instrumente pentru îmbunătățirea continuă.

Astfel, certificarea conform standardului ISO 9001:2000 și confirmarea certificatului ar trebui să contribuie la creșterea calității proceselor companiei, unde criteriul de evaluare a creșterii calității proceselor este intrarea companiei la un nou nivel. BPI, adică evaluarea lor se bazează deja pe model și anume CMM {3}.

Literatură

„Evaluarea calității software-ului”, V. Lipaev, Sinteg, 2001

ISO 9001: 2000. Sistemul de management al calității. Cerințe.

Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Modelul de maturitate a capabilităților pentru software (SW-CMM), versiunea 1.1. // CMU / SEI-93-TR-024, - Februaru, 1993.

Adnotare: Gama de idei care stau la baza, probabil, cea mai cunoscută metodologie de îmbunătățire a proceselor de dezvoltare software - CMM este studiată în detaliu. Se analizează logica și structura SMM. Este prezentată legătura HMM cu modelele de proces studiate anterior.

Un instrument practic minunat construit în interior abordare procesuala la descrierea activității organizarea designului , în special, organizația în curs de dezvoltare Sisteme de informare, demonstrează metodologia SMM. CMM înseamnă Capability Maturity Model, care înseamnă aproximativ „model de maturitate a sistemului de management”. În literatură, CMM este denumit mai frecvent modelul de maturitate organizațională și și eu voi urma această tradiție.

Istoria apariției SMM este următoarea. La sfarsitul anilor 80. secolul trecut, Departamentul de Apărare al SUA a ordonat Institutului de Inginerie Software 1ing. SEI - Institutul de Inginerie Software Universitatea Carnegie Mellon lucrează la stabilirea unui sistem de criterii de selecție a subcontractanților în proiecte de dezvoltare software. Lucrarea a fost finalizată în 1991 și a rezultat modelul CMM. Este necesar să facem imediat o rezervă că modelul nu conține niciun fel financiar, economic, politic, organizatoric criterii de selecție subcontractantul, precum și criteriile pentru posibilitatea de admitere la muncă secretă (probabil, astfel de sarcini nu au fost stabilite). Vorbim doar despre criteriile care descriu capacitatea unui potential subcontractant in ceea ce priveste dezvoltarea sistemelor software.

Structura CMM

Creatorii modelului au luat procesele organizației ca bază pentru evaluarea capacității unei organizații de a efectua o muncă de calitate, care (abilitatea) a fost numită maturitate. Apoi au făcut mai multe presupuneri non-triviale, care au fost ulterior acceptate și recunoscute drept corecte de mulți specialiști IT (și poate majoritatea dintre ei).

Ipoteza 1... Există niveluri calitativ diferite de maturitate organizarea designuluiîn curs de dezvoltare Sisteme de informare(există cinci astfel de niveluri în modelul HMM).

Ipoteza 2... Orice organizație de dezvoltare este interesată să treacă la un nivel superior de maturitate (nu doar pentru a-și crește șansele în lupta pentru contracte cu Ministerul Apărării, ci și pentru a se îmbunătăți).

Ipoteza 3... Tranziția este posibilă doar la nivelul următor în ordine. Este imposibil să „sari” peste nivel (mai exact, riscurile pentru organizație cresc dramatic).

Astfel, nivelurile formează o „scăriță” de-a lungul căreia se ridică organizația ca propria dezvoltare... Fiecare nivel este caracterizat de o anumită compoziție și proprietăți ale proceselor organizației. „Scara nivelurilor” SMM a câștigat acceptare și distribuție pe scară largă. Așa arată.

Nivelul 1 „Începător”... Procesul de producție în ansamblu este caracterizat ca fiind creat de fiecare dată pentru un anumit proiect și uneori chiar ca haotic. Sunt definite doar câteva procese, iar succesul proiectului depinde de eforturile indivizilor.

Nivelul 2 „Repetabil”... Au fost stabilite principalele procese de management de proiect, permițându-vă să urmăriți costurile, să monitorizați programul de lucru și funcționalitatea celui creat. soluție software... Disciplina de proces stabilită pentru a reproduce succesele anterioare în proiecte similare de dezvoltare a aplicațiilor.

Nivelul 3 „Definit”... Procesul de fabricație este documentat și standardizat atât pentru munca de management, cât și pentru proiectare. Acest proces este integrat în procesul de producție standard al organizației. Toate proiectele folosesc o versiune personalizată aprobată a procesului standard de producție al organizației.

Nivelul 4 „Gestionat”... Sunt colectați indicatori cantitativi detaliați ai procesului de producție și a calității produsului creat. Atat procesul de productie cat si produsele sunt cuantificate si monitorizate.

Nivelul 5 „Optimizare”... Îmbunătățirea continuă a procesului se realizează prin intermediul cantitativ părere cu procesul și implementarea ideilor și tehnologiilor avansate în ea.

În ciuda laxismului, definiția de mai sus este intuitiv cel mai adesea neobișnuită. Mai mult decât atât, specialiștii cu experiență înțeleg de ce tranzițiile sunt posibile numai la un nivel adiacent, precum și de ce în general merită să te străduiești pentru o astfel de tranziție. În același timp, modelul HMM nu conține nicio fundamentare cantitativă sau cel puțin formală a unei astfel de abordări, ceea ce, însă, nu îi slăbește câtuși de puțin meritele.

Mai mult, după cum se spune, este o chestiune de tehnologie. Se determină structura modelului (Fig. 7.1), se dau definiții și se începe munca minuțioasă pentru a descrie cu acuratețe fiecare proces la fiecare nivel. Pentru a aprecia valoarea practică a ceea ce s-a făcut, vom parcurge o parte din acest drum.

Orez. 7.1.

În fig. 7.1 există următoarele concepte.

Grup de proces cheie... După cum se precizează în (Paulk, et al., 1995), „fiecare grup de procese cheie definește un bloc de activități conexe, în urma implementării cărora se realizează un set de obiective semnificative pentru creșterea productivității producției. proces. De exemplu, pentru un grup de procese cheie." Managementul cerințelor„(vezi Figura 7.2) scopul este de a alinia cerințele unui proiect de dezvoltare software între client și dezvoltator.”

CMM nu procese individuale... În schimb, există activități separate, numite practici de bază (vezi mai jos), care sunt legate între ele în ceea ce privește I/O și servesc drept material de pornire pentru procesele de construcție. CMM nu oferă îndrumări cu privire la modul în care sunt structurate procesele, adică modul în care practicile cheie sunt legate în secvențe logice. Seturile de practici de bază sunt numite grupuri de procese de bază.

Orez. 7.2.

Grupurile de procese cheie din CMM sunt mapate la niveluri de maturitate (Fig. 7.2), adică toate practicile de la nivel interacționează numai între ele și nu interacționează cu practicile de la alte niveluri. Acest lucru ne permite să garantăm performanța deplină a tuturor proceselor la un anumit nivel și, prin urmare, să corelăm nivelul cu stadiul finalizat de dezvoltare a organizației.

Adjectivul „cheie” implică faptul că există grupuri de procese(adică, un set de practici) care nu sunt cheie din punctul de vedere al unui anumit nivel de maturitate, adică nu au legătură cu atingerea obiectivelor acestui nivel (vezi mai jos). CMM nu acoperă totul grupuri de procese privind dezvoltarea și întreținerea de software. Descrie doar acele grupuri care sunt identificate ca determinanți cheie ai productivității procesului de producție.

Goluri... Obiectivele din SMM nu sunt asociate cu procese, ci cu grupuri de procese cheie. După cum sa menționat mai sus, obiectivele sunt atinse prin implementarea practicilor cheie. În CMM, atingerea unui obiectiv înseamnă că, în primul rând, după finalizarea practicilor cheie, se obține rezultatul dorit și, în al doilea rând, se dovedește a fi destul de stabil. Modul în care sunt îndeplinite obiectivele grupului cheie de procese poate diferi de la proiect la proiect, în funcție de diferențele de domeniul subiectului sau mediu.

Dacă aceste obiective sunt realizate pentru toate proiectele, atunci aceasta înseamnă că organizația a atins nivelul de maturitate al procesului de producție, care este legat de acest grup procese cheie.

Capitol... Secțiunile (există cinci la fiecare nivel și sunt întotdeauna aceleași) reprezintă proprietățile grupurilor de procese cheie care trebuie implementate la nivelul corespunzător. Aceste proprietăți descriu modul în care procesele sunt implementate și cât de legalizate sunt în organizație, adică sunt aprobate oficial și în concordanță cu procedurile, politicile și alte procese corporative. Acestea sunt cele cinci secțiuni.

Obligatii de indeplinit

Descrieți acțiunile pe care organizația trebuie să le întreprindă pentru a se asigura că procesul este stabilit și stabil. Obligațiile de conformitate privesc de obicei stabilirea politicilor organizaționale și sprijinul din partea conducerii superioare.

Cerințe preliminare

Descrieți condițiile preliminare care trebuie îndeplinite de un proiect sau organizație pentru implementarea competentă a procesului de fabricație; de obicei se referă la resurse, structuri organizatoriceși pregătirea necesară.

Operatii efectuate

Secțiunea „Operațiuni efectuate” descrie munca substanțială care trebuie efectuată la acest nivel. Operațiunile efectuate includ de obicei realizarea de planuri și executarea de operațiuni specifice, efectuarea și urmărirea lucrărilor și luarea de măsuri corective, după cum este necesar.

Măsurători și analize

Secțiunea „Măsurători și

„Fiecare grup de procese cheie este exprimat prin Practici cheie, a căror implementare contribuie la atingerea obiectivelor Grupului. Practicile cheie descriu infrastructura și operațiunile care contribuie cel mai mult la implementarea și stabilirea eficientă a Grupului de procese cheie.

Fiecare practică cheie constă dintr-o singură propoziție, adesea extinsă cu o descriere mai detaliată, care poate include exemple și clarificări. Practici cheie, uneori numite practici cheie nivel superior, stabilesc politici de bază, proceduri și operațiuni pentru un grup de procese cheie. Componente descriere detaliata adesea numiți sub-practicieni”.

Practicile cheie descriu CE trebuie făcut, dar nu ar trebui luate ca dogme care indică CUM se ating obiectivele. Obiectivele grupului de proces de bază pot fi atinse prin practici alternative. Interpretarea practicilor cheie ar trebui să fie rezonabilă, permițând atingerea obiectivelor grupului de procese cheie mod eficient, deși poate formal și diferit de CMM-ul recomandat.

O privire asupra activităților de management IT, în care în loc de procese sunt luate în considerare componentele acestora - practici cheie, iar procesele sunt prezente doar virtual, deoarece ceva ce poate fi construit din practici cheie pare oarecum exotic la prima vedere. Până în prezent, sarcina de îmbunătățire a managementului IT a fost rezolvată prin introducerea de procese gata făcute din modelul de proces de referință. Acum, există multe niveluri care conțin practici cheie disparate (adică, neintegrate în procese) și secvența recomandată de progres prin niveluri. Guvernanța IT, conform CMM, se îmbunătățește pe măsură ce treceți la un nivel mai înalt de maturitate. Ce se întâmplă cu un astfel de progres?

În definițiile nivelurilor (vezi Fig. 7.2) a apărut un astfel de concept precum „proces de producție”. Este prezent și în definiția unui grup de procese cheie, iar aceasta nu este o coincidență întâmplătoare. Procesul de fabricație sau, așa cum se numește în mod potrivit în CMM, Standard Proces de fabricație Organizațiile (SPO) este unul dintre conceptele centrale ale întregului model.

În noiembrie 1986, Institutul de Inginerie Software din SUA (SEI), împreună cu Mitre Corporation, a început să dezvolte un studiu de maturitate a proceselor de dezvoltare a software-ului, care a fost menit să ajute la îmbunătățirea proceselor interne.

Elaborarea unui astfel de sondaj a fost determinată de o solicitare din partea guvernului federal al SUA pentru o metodă de evaluare a subcontractanților pentru dezvoltarea de software. Adevărata problemă a fost incapacitatea de a gestiona proiecte mari... În multe companii, proiectele au fost finalizate cu întârzieri semnificative și depășind bugetul planificat. A fost necesar să se găsească o soluție la această problemă.

În septembrie 1987, SEI a lansat un rezumat al proceselor de dezvoltare software care descriu nivelurile de maturitate ale acestora și un chestionar pentru a identifica zonele din companie de îmbunătățit. Cu toate acestea, majoritatea companiilor au considerat acest chestionar ca model finit, drept urmare, după 4 ani, chestionarul a fost transformat într-un model real, Capability Maturity Model for Software (CMM). Prima versiune a CMM (Versiunea 1.0), lansată în 1991, a fost revizuită în 1992 de participanții la un workshop la care au participat aproximativ 200 de specialiști în software și membri ai comunității dezvoltatorilor.

Ca urmare, a fost eliberat Standard CMM, Versiunea 1.1, care este încă folosită activ în întreaga lume.

Orez. 1. Impactul global al utilizării SMM

Motivele acestui interes pentru SMM sunt clare. În ciuda faptului că atât dezvoltatorii de software, cât și conducerea lor sunt adesea foarte conștienți de problemele lor permanente, nu se pot pune de acord cu privire la schimbările de care are nevoie compania în primul rând. Fără dezvoltarea unei strategii unificate pentru a face îmbunătățiri, managementul nu poate găsi înțelegere reciprocă cu angajații săi cu privire la sarcinile cu cea mai mare prioritate pentru îmbunătățire. Pentru a obține rezultatul maxim din eforturile depuse pentru îmbunătățirea proceselor, este necesar să existe o strategie de dezvoltare etapizată care să îmbunătățească maturitatea proceselor de dezvoltare treptat, într-un mod evolutiv.

Îmbunătățirea continuă a procesului se bazează pe cultivarea treptată a culturii unei companii, nu pe inovații revoluționare. CMM oferă un cadru pentru această îmbunătățire incrementală, împărțit în 5 niveluri de maturitate a procesului. Aceste 5 niveluri reprezintă o scară de evaluare a nivelului de maturitate al proceselor de dezvoltare software dintr-o companie și de măsurare a parametrilor acestora.

Orez. 2. Principiul creșterii consistente a nivelului de maturitate: oportunități de dezvoltare a organizației

Iată principalele caracteristici ale fiecărui nivel:

1. Inițial - Procesul de dezvoltare este haotic. Doar câteva dintre procese au fost identificate, iar succesul proiectelor depinde de performanții individuali.
2. Repetabil - Sunt stabilite principalele procese de management de proiect: urmarirea costurilor, programului si functionalitatii. A simplificat unele dintre procesele necesare pentru a replica realizările anterioare pe proiecte similare (proiecte cu aplicații similare).
3. Definit - Procesele de dezvoltare software și management de proiect sunt descrise și implementate în sistem unificat procesele companiei. Toate proiectele folosesc un proces organizațional standard de dezvoltare și suport software, adaptat pentru un anumit proiect.
4. Gestionat - Colectați date cantitative detaliate despre performanța și calitatea procesului de dezvoltare produs final... Se analizează semnificația și dinamica acestor date.
5. Optimizare - Îmbunătățirea continuă a procesului se bazează pe date cantitative ale procesului și pe pilotarea de noi idei și tehnologii.

Introducere în SW-CMM

(Îmbunătățirea maturității proceselor de dezvoltare a software-ului pe baza Modelului de maturitate a capacității software-ului Institutului de inginerie software)

Cursul este destinat:
Pentru șefii companiilor de software, șefii de departamente și proiecte de dezvoltare software și specialiștii în calitate care sunt interesați de:

îmbunătățirea transparenței proceselor de producție existente;

creșterea productivității proceselor și a companiei în ansamblu;

reducerea costului de producție și a volumului producției „ascunse” existente;

cresterea reputatiei companiei in mediul profesional;

deschiderea de noi piețe pentru produse.

2.1 Costul, durata și rezultatele obținute. Statistica industriei
2.2 Rentabilitatea investiției în CMM

3.1 TQM (Total Quality Management), SPI (Software Process Improvement) și cele mai bune practici de afaceri ca bază a CMM
3.2 Noțiuni de bază TQM. Aplicarea abordărilor TQM în producția de produse software
3.3 Beneficiile și riscurile inerente modelului de îmbunătățire a procesului CMM
3.4 Conceptul de proces. Componentele principale ale abordării procesului
3.5 Niveluri de maturitate a procesului

9.1 Sistem de standarde pentru industria IT (Foaie de parcurs)
9.2 Relația ISO cu CMM, Rational Unified Process, Project Management
9.3 Aplicarea CMM pentru organizații mici
9.4 Ce lipsește în SMM
9.5 Documente și procese

10.1 Prezentare finală a modelului SW-CMM. Distribuție în lume. Principalele dificultăți
10.2 CMMI (Capability Maturity Model Integration) - dezvoltarea în continuare a modelului CMM

Un set de diapozitive, materiale pentru exerciții practice, materiale suplimentare pentru auto-studiu.

Un set complet de documente despre SW-CMM (textul standardului, metode de evaluare, materiale statistice despre industrie, exemple de documente)

Curs practic despre tehnologia implementării modelului SW-CMM în companiile IT

Scurtă adnotare:
Acest curs are scopul de a ajuta companiile în mod independent și competent să planifice și să desfășoare lucrări privind implementarea unui model de îmbunătățire a maturității proceselor, pentru a ajuta la evitarea greșeli tipiceși probleme de implementare.

Cursul este destinat:
Cursul este destinat managerilor de intreprinderi si departamente implicate in dezvoltarea software, manageri de proiect, manageri de calitate si altora interesati de imbunatatirea calitatii dezvoltarilor lor si de certificarea procesului acestora conform CMM.

Revizuirea standardelor recunoscute de management al calității pentru IT (ISO 9000, SW-CMM, CMMI, TickIT, SPICE)

17. La CMM prin ISO?

5 etape evolutive în managementul proceselor organizaționale. Explicația modelului de maturitate a capacității funcţionalitate). CMM

Modelul de maturitate a capacității CM-CEI model organizatoric, care descrie 5 etape (nivele) evolutive la care sunt controlate procesele din organizație.

Rațiunea din spatele modelului de maturitate a capacității, conceput inițial pentru dezvoltarea de software, este că o organizație trebuie să fie capabilă să accepte și să-și susțină aplicațiile software. Modelul sugerează, de asemenea, pași și inițiative concrete care vor ajuta organizația să crească la următorul nivel.

Cele 5 etape ale modelului de maturitate a capacității

Inițial (procesele sunt ad-hoc, haotice sau, de fapt, sunt puține definite) Repetabil (procesele de bază sunt stabilite și există o disciplină pentru a adera la aceste procese) Definit (toate procesele sunt definite, documentate, unificate și integrate) Gestionate (procesele sunt măsurată prin agregarea datelor detaliate de proces și calitatea acestora) Optimizarea ( dezvoltare continuă proces utilizând feedback cantitativ și testând idei și tehnologii noi)

Model de dezvoltare software

CMM descrie principiile și practicile care stau la baza conceptului de maturitate a procesului software. Acestea sunt concepute pentru a ajuta firmele de dezvoltare și marketing de software să îmbunătățească sofisticarea proceselor lor software într-un mod evolutiv. De la procese ad-hoc, haotice, până la procese software mature și disciplinate. Accentul este pus pe identificarea domeniilor cheie de proces și a celor mai bune practici pe care le pot constitui procesele software disciplinate. Conceptul de maturitate CMM creează un context în care:

Practicile pot fi repetate. Dacă nu repeți o operație, atunci nu ar trebui să o îmbunătățiți. Există reguli, proceduri și practici care obligă o organizație să fie implementată și implementată în mod consecvent. Cele mai bune practici pentru organizarea muncii de producție pot fi diseminate rapid în rândul grupurilor. Practicile sunt definite pentru a permite schimbul între proiecte, oferind astfel o anumită standardizare pentru organizație. Abaterile în performanța acestor metode sunt minimizate. Scopurile cantitative sunt stabilite pentru obiective; iar măsurătorile sunt stabilite, produse și menținute pentru a constitui baza pentru evaluare. Practicile sunt îmbunătățite continuu pentru a îmbunătăți capacitatea (optimizare).

Modelul de maturitate a capacității este util nu numai pentru dezvoltarea software-ului, ci și pentru descrierea nivelurilor evolutive ale organizațiilor în general și descrierea nivelului de management pe care organizația l-a implementat sau dorește să-l atingă.

Structura modelului de dezvoltare a funcționalității

Nivelurile de maturitate sunt un concept stratificat care oferă consistența disciplinei necesară pentru a obține o îmbunătățire continuă. Este important de remarcat aici că organizația își dezvoltă capacitatea de a evalua consecințele unei noi practici, tehnologie sau instrument. Prin urmare, nu este vorba de acceptarea acestor inovații, ci mai degrabă de modul în care aceste eforturi inovatoare influențează practicile existente. Sprijină proiecte, grupuri și organizații, oferindu-le baza pentru a face alegeri informate. Domenii cheie de proces - O zonă cheie de proces (KPA) definește un grup de activități conexe care, atunci când sunt realizate împreună, ating un număr de obiective importante. Obiective - Obiectivele unui domeniu cheie de proces descriu prevederile care trebuie să existe pentru acea zonă cheie de proces. Reglementările trebuie implementate într-o manieră eficientă și fiabilă. Măsura în care obiectivele sunt îndeplinite arată ce fel de oportunitate a stabilit organizația la acel nivel de perfecțiune. Obiectivele subliniază domeniile de activitate, limitele și scopul fiecărui domeniu cheie de proces. Caracteristici comune - Caracteristicile comune includ practici care implementează și instituționalizează domenii cheie de proces. Aceste 5 tipuri caracteristici generale Acestea includ: Angajamentul față de conformitate, Capacitatea de a se conforma, Inițiativele efectuate, Măsurarea și Analiza și Controlul implementării. Practici cheie - Practicile cheie descriu infrastructura și elementele de practică care contribuie cel mai eficient la implementarea și instituționalizarea domeniilor cheie ale procesului.

Criterii de definire a procesului

Criteriile de definire a unui proces sunt un set de elemente de proces care trebuie incluse în descrierea unui proces software pentru ca oamenii să le folosească în practică. Pentru a stabili criteriile trebuie să puneți întrebarea - „Ce informații despre procesul programului sunt necesare pentru documentare?”

Introducere

Cea mai importantă parte a sistemelor complexe moderne sunt produsele software - o componentă intelectuală. Produsele software sunt acum folosite pentru a rezolva probleme de management în aproape toate sferele activității umane: în economie, social, militar și alte domenii. Asigurarea calității înalte a produselor software autohtone în timpul dezvoltării și livrării lor în masă pentru diverse domenii de aplicare în țară și pe piața mondială a devenit obiectiv strategic.

În prezent, există două domenii aproape independente de standardizare în ingineria software și asigurarea calității produselor software, care pot fi numite condiționat profiluri de standarde ISO ( Organizația Internațională standardizare) și modele de maturitate SEI (US Software Engineering Institute). Primele sunt suficient de complet reprezentate în [,], iar cele doua - în [,]. Conținutul principal al articolului este dedicat modelelor de maturitate.

Pentru a asigura competitivitatea în lumea produselor software complexe și posibilitatea exportului lor de succes, acestea trebuie să fie dezvoltate și certificate în conformitate cu cerințele profilurile standardelor internaționale pe bază ISO 9000: 2000 sau modele de maturitate - CMMI: 2003(Capability Maturity Model Integration - Model integrat pentru evaluarea maturității ingineriei software). Aceste două direcții sunt metodologic foarte apropiate și se intersectează parțial prin legături reciproce.

Îmbunătățirea indicatorilor tehnici și economici și a calității produselor software, precum și prevenirea erorilor și a defectelor este asigurată prin utilizarea tehnologiilor și sistemelor moderne de inginerie software. proiectare asistată de calculator... Acestea sunt tehnologii de înaltă performanță, care economisesc resursele pentru crearea de complexe de programe de înaltă calitate, fiabilitate și siguranță, care vizează reducerea costului total al resurselor pentru proiectarea, implementarea și întreținerea instrumentelor software (PS). Pentru aceasta, în primul rând, este necesar să se aplice metode și instrumente de analiză și proiectare care să ofere concretizarea și reprezentarea cât mai exactă a scopurilor, scopurilor și funcțiilor încă de la început. ciclu de viață sisteme software (ciclului de viață) și prevenirea răspândirii posibilelor defecte ale sistemului la etapele ulterioare de dezvoltare. Astfel de tehnologii de inginerie software fac posibilă excluderea sau reducerea semnificativă a nivelului erorilor de sistem, algoritmice și software din produsele software transferate pentru funcționare. În plus, sunt eficiente la modificarea și menținerea PS, precum și la schimbare Mediul extern.

Pentru a certifica calitatea, fiabilitatea și siguranța sistemelor complexe, critice, sunt supuse produselor software utilizate în acestea certificare centre de testare sau laboratoare certificate, orientate către probleme. O astfel de testare este necesară atunci când programele controlează procese complexe, critice sau procesează informații atât de importante încât defectele sau calitatea insuficientă pot cauza daune semnificative. Testele de certificare trebuie să stabilească conformitatea complexelor software cu cerințele documentației și să le permită să funcționeze în limitele modificărilor parametrilor mediului extern, investigate în timpul verificărilor efectuate. Aceste tipuri de teste sunt caracterizate de cea mai mare rigoare și profunzime a verificărilor și ar trebui efectuate de specialiști independenți de dezvoltatori și clienți (utilizatori).

Baza certificării ar trebui să fie programe și metode detaliate și eficiente pentru testarea complexelor software pentru conformitatea cu cerințele standardizate ale clienților, probleme de testare special concepute și generatoare pentru formarea lor, precum și calificări înalte și autoritate a testatorilor. Aplicarea sistemelor de calitate certificate pentru a asigura ciclul de viață al produselor software pe baza cerințelor întreprinderilor de dezvoltare software ISO 9000: 2000 sau CMMI: 2003, garantează un management al calității ridicat și durabil al proceselor și produselor ciclului lor de viață și, de asemenea, permite în multe cazuri facilitarea certificării produsului software final. Prin urmare, clienții proiectelor software complexe tind să selecteze contractori executori care dețin certificate care confirmă aplicarea sistemelor de asigurare a calității bazate pe profiluri adaptate ale standardelor internaționale sau modelelor de maturitate.

Lacunele în predarea metodelor de inginerie software lasă o marjă largă pentru arbitrariul specialiștilor în evaluarea calității muncii lor, precum și pentru apariția a numeroase defecte și erori în proiectele software. Creșterea complexității și responsabilității provocări moderne, rezolvate de programe, precum și posibilele prejudicii din calitatea insuficientă a rezultatelor acestora, au crescut semnificativ relevanța stăpânirii metodelor unei descrieri complete, standardizate a cerințelor pentru caracteristicile de calitate și a metodelor de măsurare a valorilor reale, atinse ale acestora. în diferite etape ale ciclului de viață al unui sistem software. Necesitatea specialiştilor de a cunoaşte conceptele, definiţiile şi metodele de evaluare a caracteristicilor calitative ale produselor software a crescut brusc.

Creșterea rapidă și complicarea complexelor software duce la crearea unor echipe mari de programare cu o diviziune profesională a muncii, în care este necesară reglementarea activităților coordonate ale grupurilor de specialiști pe un singur proiect. Promisiunile contractuale ale dezvoltatorilor de a furniza software de înaltă calitate în intervalul de timp convenit nu sunt adesea îndeplinite. Acest lucru se întâmplă adesea din cauza faptului că clientul și antreprenorul evaluează nivelul de calitate în funcție de criterii diferite și nu au niciun acord în această problemă, iar abordarea de evaluare a calității programelor nu este suficient de formalizată. În plus, uneori lipsește capacitatea de a evalua în mod corespunzător resursele necesare pentru realizarea unor programe de înaltă calitate. Ca urmare, calitatea produselor software rămâne adesea scăzută, nesigură și necompetitivă pe piața internațională. Prin urmare, cea mai importantă problemă în dezvoltarea și aplicarea multora sisteme moderne este formarea și educarea specialiștilor în domeniul ingineriei software, utilizarea standardelor internaționale care contribuie la calitatea înaltă a software-ului și la evaluarea fiabilă a acestuia cu scopul principal de a realiza procese de proiect. gestionate iar rezultatele sunt previzibil... Este necesar să se poată oficializa cerințele și să se realizeze valori specifice ale caracteristicilor calității funcționării și utilizării complexelor complexe de programe, ținând cont de resursele care sunt disponibile pentru a asigura și îmbunătăți această calitate.

Modelul de maturitate CMMI - 1.1, rafinează și îmbunătățește modelele anterioare CMM(a se vedea), și, de asemenea, ia în considerare parțial cerințele de bază ale standardelor internaționale existente în domeniul managementului software. Atenție considerabilă în CMMI se concentrează pe procesele de dezvoltare și contabilizarea iterațiilor atunci când cerințele clienților se modifică, urmărindu-le în funcții, componente, teste și documente de proiect. V În ultima vreme au existat informații despre modernizarea versiunii 2003 de către Institutul SEI CMMI - 1.1 pe baza experienței și a feedback-ului de la companii. Este planificată să lanseze în 2006 o nouă versiune a modelului, semnificativ modernizată CMMI - 1.2, după care versiunea 1.1 ar trebui eliminată treptat. Până la sfârșitul anului 2007, utilizatorii ar trebui să treacă la versiunea CMMI - 1.2, iar pe viitor va deveni obligatoriu pentru evaluarea (certificarea) formală a calității a tehnologiei întreprinderilor din domeniul ingineriei software. În acest caz, valabilitatea certificatului va fi limitată la trei ani. Clienții și dezvoltatorii de sisteme software mari ar trebui să se pregătească pentru aceste modificări înainte de publicarea oficială a versiunii 1.2 de către SEI.

Structura și conținutul Modelului de Maturitate CMMI - 1.1

Două opțiuni de model CMMI - 1.1 creat pentru a oferi continuu evaluarea unui set de procese într-o anumită zonă de dezvoltare software sau pentru pe etape evaluarea și îmbunătățirea maturității întreprinderii, precum și pentru organizarea ciclului de viață al complexelor software în general. Modele CMMI acorda asistenta specialistilor in organizarea si imbunatatirea produselor lor, precum si in eficientizarea si mentinerea proceselor de dezvoltare si intretinere a sistemelor software. Conceptul acestor modele acoperă managementul și evaluarea maturității sistemelor complexe, ingineria software și procesele de creare a produselor software integrate și de îmbunătățire a dezvoltării acestora. Componentele modelelor continue și etapizate sunt în mare măsură similare și pot fi selectate și aplicate într-o compoziție și o secvență de utilizare diferită, în funcție de proprietățile și caracteristicile proiectelor specifice.

Opțiunile de descriere a modelului sunt construite conform unei singure scheme, care include secțiuni generale:

• prefaţă;
• Secțiunea 1 - introducere;
• Secțiunea 2 - Modelul componentelor;
• Secțiunea 3 - Terminologie;
• Secțiunea 4 - conținutul nivelurilor și principalele componente ale fiecărei versiuni a modelului (dezvoltarea obiectivelor și procedurilor);
• Secțiunea 5 - structura interacțiunii proceselor; Sunt adnotate patru categorii de procese din secțiunea 7, prezentarea lor generală și schemele de interacțiune a proceselor CMMI:
  • administrarea procesului;
  • management - management de proiect;
  • inginerie (tehnologie);
  • a sustine;
• Secțiunea 6 - utilizarea modelului CMMI- recomandări scurte pentru utilizatori cu privire la utilizarea modelului și instruire; se notează compatibilitatea și conformitatea proceselor modelului cu procesele reglementate ale modelului CMM anterior din părțile 2 și 3 ale standardului ISO 15504.
• Secțiunea 7 este ultima, cea mai mare din fiecare standard, este nevoie de aproximativ 500 de pagini din volumul total al documentului, care este de peste 700 de pagini. Această secțiune oferă recomandări detaliate pentru implementarea fiecăruia dintre procesele enumerate în ea, care iau în considerare caracteristicile unui anumit model.

Prima varianta Modelul (continuu) reflectă documentul: Integrarea modelului de maturitate a capabilităților (CMMI) pentru ingineria sistemelor / inginerie software / dezvoltare integrată de produse și procese, versiunea 1.1, reprezentare continuă (CMMI-SE / SW / IPPD, V1.1, Continuu). Model integrat de evaluare a maturității pentru ingineria sistemelor / inginerie software / produse integrate și procese de dezvoltare - prezentare continuă... În acest model, a șaptea secțiune este alcătuită din procese:

• administrarea procesului:
  • organizarea instruirii;
  • organizarea transformării (modificărilor) proceselor;
  • organizarea de inovații și extinderi;
• management de proiect:
  • Planificarea proiectului;
  • monitorizarea si controlul proceselor de proiect;
  • Managementul riscurilor;
  • managementul cantitativ al proiectelor;
• inginerie (tehnologie):
  • managementul cerințelor;
  • dezvoltarea cerințelor;
  • solutii tehnice;
  • integrarea produsului;
  • verificare;
  • validare (certificare, aprobare);
• a sustine:
  • managementul configurației;
  • analiza și luarea deciziilor pentru schimbări;
  • analiza cauzelor si rezolvarea problemelor (eliminarea defectelor).

Cinci anexe prevăd:

A- alcătuirea literaturii și documentelor utilizate, care însă nu menționează standarde ISO;

V- abrevieri;

CU- glosar bazat pe terminologie ISO aplicat în doar patru standarde ISO 9000, ISO 12207, ISO 15504: 1-9, ISO 15288;

D - descrieri de cerințe și propuneri pentru formarea componentelor modelului pe niveluri de maturitate;

E - lista participanților la dezvoltare CMMI- proiectul.

În acest model, atenția este concentrată pe procesele organizaționale, pe planificarea, managementul și controlul implementării proiectelor software, pe dezvoltarea și managementul cerințelor pentru produsele software. Mai jos sunt exemple de granularitate în CMMI unii dintre ei.

Planificarea proiectului atât în ​​acest model, cât și în cel de-al doilea model, include:

• evaluare dimensiune posibilă(scale) produsului software;
• evaluarea complexității funcțiilor și caracteristicilor proiectului PS;
• determinarea modelului și etapelor ciclului de viață al unui complex de programe;
• studiul de fezabilitate al proiectului - determinarea costului, intensității forței de muncă și a duratei ciclului de viață al PS;
• elaborarea unui program de lucru în etape și a bugetului proiectului;
• analiza, identificarea și evaluarea riscurilor proiectului;
• planificarea și documentarea managementului proceselor și produselor în ciclul de viață al unui proiect PS;
• planificarea și repartizarea resurselor tehnice și umane pe etape ale ciclului de viață al PS;
• planificarea furnizării cunoștințelor și calificărilor unei echipe de specialiști pentru implementarea proiectului;
• generalizarea și analiza setului de planuri pentru proiectul PS;
• coordonarea lucrărilor și resurselor în funcție de etapele ciclului de viață de către dezvoltator cu clientul proiectului PS;
• documentarea planului de lucru și aprobarea acestuia de către managerul dezvoltatorului de proiect.

Procesele de dezvoltare a cerințelor la produsul software sunt similare cu procesele din ambele modele și includ:

• identificarea nevoilor reale ale clientului si utilizatorilor pentru functiile si caracteristicile produsului software;
• dezvoltarea și coordonarea între client și dezvoltator a cerințelor inițiale, de bază, pentru funcțiile produsului software;
• determinarea resurselor disponibile și a limitărilor complexului de programe de proiect;
• descompunerea cerințelor inițiale de bază pentru funcțiile sistemelor software într-un set de cerințe pentru componentele și testele unui pachet software;
• formalizarea cerințelor pentru interfețele dintre componente, cu mediul operațional și extern;
• dezvoltarea conceptului de produs software și a scenariilor de utilizare a acestuia;
• dezvoltarea cerințelor pentru caracteristicile generalizate de adecvare funcțională și utilizarea funcțiilor produsului software în scopul propus.

Managementul cerințelorîn ambele modele include:

• realizarea unei înțelegeri neechivoce a cerințelor pentru proiectul PS de către client și dezvoltatori;
• primirea de către client de la dezvoltatori a obligațiilor de a îndeplini toate cerințele sale pentru produsul software;
• gestionarea modificărilor cerinţelor la proiectul PS convenite între client şi dezvoltator;
• asigurarea trasabilității corectitudinii modificărilor de la cerințele generale pentru proiectul PS la cerințele pentru componente și procese private;
• identificarea și identificarea neconcordanțelor între procesele de dezvoltare a proiectului și cerințele clienților.

A doua varianta prezinta documentul: Integrarea modelului de maturitate a capabilităților (CMMI) pentru ingineria sistemelor / ingineria software / dezvoltarea integrată a produselor și a proceselor, versiunea 1.1, reprezentare în etape (CMMI-SE / SW / IPPD, V1.1, Staged). Model integrat de evaluare a maturității pentru ingineria sistemelor complexe / inginerie software / produse integrate și procese de dezvoltare - prezentare în etape... Modelul se bazează pe menținerea conceptului de cinci niveluri de maturitate CMM[,]. Compoziția proceselor o repetă practic pe cea dată mai sus pentru prima versiune a modelului, dar într-o secvență puțin diferită și cu adaosuri relativ mici.

Primul nivel este caracterizată de o incertitudine semnificativă în compoziția și conținutul proceselor în diverse proiecte relativ simple, prin urmare, nu este comentată în document. Prin urmare, la clarificarea și detalierea conținutului proceselor într-o versiune etapizată CMMI se recomandă limitarea patru niveluri principale:

• al doilea nivel- formalizează management de bază proiecte:
  • managementul cerințelor;
  • Planificarea proiectului;
  • monitorizarea si controlul proiectelor;
  • gestionarea acordurilor cu furnizorii;
  • măsurarea și analiza proceselor și produselor;
  • asigurarea calitatii proceselor si produselor;
  • managementul configurației;
• al treilea nivel- contine standardizarea principalelor procese:
  • dezvoltarea cerințelor;
  • solutii tehnice;
  • integrarea produsului;
  • verificare;
  • validare (certificare);
  • continutul proceselor organizationale;
  • definirea proceselor organizatorice;
  • organizarea instruirii;
  • managementul integrat al proceselor și produselor proiectului;
  • Managementul riscurilor;
  • integrarea echipei de dezvoltare;
  • management integrat al furnizorilor;
  • analiza si rezolvarea problemelor (eliminarea defectelor);
  • organizarea mediului pentru integrare;
• al patrulea nivel- defineste managementul cantitativ:
  • organizarea prezentării calității proceselor;
  • managementul cantitativ al întregului proiect și al resurselor;
• al cincilea nivel- optimizare, imbunatatire continua:
  • organizare, inovare, proces cantitativ și managementul resurselor;
  • analiza cauzelor defectelor, imbunatatirea calitatii si managementul proceselor si produselor.

Aplicațiile din a doua versiune a modelului sunt similare ca compoziție cu aplicațiile de mai sus pentru primul model. Se recomandă aplicarea la fiecare nivel de maturitate superior toate procesele nivelurile inferioare anterioare. În ambele versiuni ale modelului, fiecare evidențiată mai sus, procesul de bază este comentat cu recomandări detaliate pentru implementarea sa practică, care conțin descrieri unificate de aproximativ 20-30 de pagini în structură:

• obiectivele generale ale procesului de atins;
• observații introductive și descriere generala funcții de proces;
• obiectivele specifice ale procesului;
• administrarea procesului;
• dezvoltarea cerințelor procesului;
• interacțiunea și interfețele cu alte procese;
• scopurile practice sunt rezultatele necesare activităților procesului;
• planificarea acțiunilor într-un anumit proces;
• analiza și validarea (aprobarea) rezultatelor implementării procesului;
• monitorizarea si controlul procesului.

Aceste recomandări pentru volumul, conținutul și caracterul complet al descrierilor proceselor de bază sunt similare cu o serie de standarde pentru ciclul de viață al PS prezentate în. Raționalizarea și evaluarea completității proceselor utilizate în conformitate cu nivelurile de maturitate, vă permite să stabiliți potențialul de producție al întreprinderilor - dezvoltatori de software în funcție de calitatea preconizată a proceselor și a rezultatelor activităților lor și pregătirea pentru certificare pentru conformitatea cu un un anumit nivel de maturitate a modelului CMMI - 1.1.

O atenție deosebită la modele CMMI este dat proceselor de management al proiectului PS. Aceste cerințe și procese model sunt strâns aliniate cu liniile directoare specificate și detaliate din standarde. ISO 9001: 2000și principalele componente ale profilului standardelor ciclului de viață pentru sisteme software complexe [,]. Cerințe pentru procese din clauzele funcționale 4-8 din standarde ISO 9001, ISO 9004, ISO 90003 pot fi comparate un număr de secțiuni din model care sunt adecvate ca conținut CMMI(în Figura 1 există o suprapunere de izolare). Comunitatea proceselor și cerințelor constă în asemănarea: compoziție, terminologie, structură, o listă a proceselor de management recomandate, planificare, contabilizarea resurselor disponibile, implementarea proceselor de inginerie software, evaluarea și organizarea specialiștilor.

Figura 1. Comunitatea proceselor și cerințelor standardelor și modelelor de maturitate

Din punctul de vedere al suportului și reglementării întregului ciclu de viață al proiectelor software mari în dezavantajele modelelor CMMI pe profilul standardelor existente ISO includ următoarele:

Pentru a determina nivelurile de maturitate de mai sus ale proceselor de asigurare a ciclului de viață al sistemului software, a fost elaborat un amplu raport tehnic și aprobat inițial în 1998. ISO 15504, constând din nouă părți și multe aplicații. Prezintă modelul de maturitate CMMși opt principii de bază ale ingineriei software bazate pe standard ISO 9000: 2000... Apoi în ISO acest document a suferit o revizuire radicală, reducerea, simplificarea structurii și conținutului, cu păstrarea deplină a scopurilor și conceptului, și a fost aprobat ca standardîn cinci părți.

Standard ISO 15504: 1-5: 2003-2006 reglementează evaluarea și atestarea maturității proceselor de creare, întreținere și îmbunătățire a instrumentelor și sistemelor software realizate de întreprinderi:

• să stabilească starea propriilor procese tehnologice și să le îmbunătățească;
• pentru a determina caracterul adecvat al propriilor procese pentru a îndeplini cerințele specifice sau clasele de cerințe ale clienților;
• în scopul adecvării sale pentru îndeplinirea anumitor contracte cu clienții PS și sisteme.

Standardul contribuie la: autocertificarea maturității întreprinderilor, asigurarea managementului adecvat al proceselor certificate, determinarea profilului evaluărilor proceselor și, de asemenea, este potrivit pentru orice domenii de aplicare și dimensiuni ale sistemelor și sistemelor software. Aplicarea standardului vizează dezvoltarea întreprinderilor și a specialiștilor cultura îmbunătățirii continue a maturității tehnologiei asigurarea ciclului de viață al PS care îndeplinește obiectivele de afaceri ale proiectelor și optimizează utilizarea resurselor disponibile. Atestarea maturității proceselor întreprinderii oferă posibilitatea comparării și selecției acestora, care sunt de preferat pentru anumite proiecte:

• pentru clienți, cumpărători, utilizatori de produse și sisteme software: capacitatea de a determina maturitatea actuală și potențială a proceselor ciclului de viață al furnizorului;
• pentru furnizori și dezvoltatori: capacitatea de a determina maturitatea actuală și potențială a propriilor procese ale ciclului de viață al software-ului și sistemelor, domeniile și prioritățile de îmbunătățire a proceselor;
• pentru evaluatorii de maturitate: o bază pentru desfășurarea și îmbunătățirea proceselor de atestare.

Aprobarile din standard sunt abordate in doua aspecte: pentru a îmbunătăți procesele ciclului de viață al PS și a sistemelor unei anumite întreprinderi și pentru a determina conformitatea maturității declarate a proceselor de asigurare a proiectului sau întreprinderii cu procesele reale utilizate. Acest lucru se reflectă în următoarele cinci părți ale standardului ISO 15504: 1-5: 2003-2006.

Partea 1 - Concept și vocabular. Conține informatii generale privind procesele de atestare a maturității software-ului și sistemelor și recomandări de utilizare a unor părți din standard. Sunt precizate cerințele generale pentru atestare, terminologie, structură, se determină domeniul de aplicare al părților rămase ale standardului.

Partea 2 - Executarea (producerea) atestarii. Include cerințe detaliate pentru procesele de atestare ca bază pentru îmbunătățirea și determinarea nivelului de maturitate al proceselor tehnologice pentru asigurarea ciclului de viață al software-ului și sistemelor. Documentul definește procesele de realizare a atestării, modelele de procese de atestare recomandate și de verificare a proceselor astfel încât acestea să fie obiective, semnificative și reprezentative.

Partea 3 - Manual pentru producerea atestatului. Oferă o privire de ansamblu asupra tehnologiei pentru efectuarea proceselor de atestare a maturității și interpretarea implementării cerințelor. Acesta reflectă: performanța certificării; instrumente de măsurare pentru determinarea proceselor de maturitate; selectarea și aplicarea instrumentelor de certificare; evaluarea competenței evaluatorilor; verificarea conformității certificării cu cerințele declarate. Instrumentele de certificare pot fi utilizate de întreprinderi în planificarea, managementul, monitorizarea, controlul și îmbunătățirea produselor și sistemelor software, în achiziționarea, dezvoltarea, aplicarea și întreținerea acestora.

Partea 4 - Îndrumări ale utilizatorilor pentru procesele de îmbunătățire și determinarea maturității procesului pe aceste două aspecte. Se recomandă o serie de pași, care includ: aplicarea rezultatelor proceselor de calificare; stabilirea obiectivelor pentru atestarea maturității; determinarea datelor inițiale pentru atestare; evaluarea posibilei reduceri a riscurilor rezultate; pași pentru îmbunătățirea proceselor; etapele de determinare a nivelului de maturitate; compararea rezultatelor analizei de atestare cu cerinţele.

Partea 5 - Un exemplu de model al proceselor de validare pentru conformitatea cu cerințele prezentate în partea 2. Documentul amplu (162 de pagini) oferă exemple de aplicare practică a părților anterioare ale standardului pentru a organiza, evalua și îmbunătăți atestarea maturității proceselor ciclului de viață pentru diverse domenii de utilizare, proiecte software și întreprinderi.

În implementarea practică a proiectelor și asigurarea ciclului de viață al sistemelor software complexe, este uneori dificil pentru dezvoltatori și furnizori să identifice și să izoleze avantajele modelelor de utilizare. CMMI... În funcție de tradițiile întreprinderii și de caracteristicile unui mare proiect PS, adesea este recomandabil să se folosească un profil standardelorISO, și pentru evaluarea de către clienți nivelul de maturitate management, suport organizatoric si tehnologic al proiectelor PS pentru aplicarea recomandarilor specifice CMMI... Aceste recomandări pot fi utilizate în mod eficient atunci când certificarea calitatii procesului la întreprinderile care furnizează servicii pe ciclul de viață, ca alternativă la sau împreună cu certificarea conform unui set de standarde de management ISO 9000, în funcție de specificul proiectului și de cerințele solicitantului pentru certificarea unui produs software sau tehnologie pentru a asigura ciclul de viață al acestuia.

Organizarea certificării produselor software

Certificarea constă într-o serie de procese organizaționale care compun sistem de certificare Aceste procese sunt susținute de proceduri și documente reglementate și trebuie efectuate de inspectori experți calificați, certificați. Pentru certificarea întreprinderii dezvoltatoare și a rezultatelor activităților sale - produse software, modele CMMI sau profiluri standard ISO[,] se recomandă o anumită disciplină, care să fie adaptată la caracteristicile specifice ale obiectelor și mediului extern al ciclului de viață al sistemului software. Procesele și documentele enumerate mai jos sunt axate pe proiecte mari, iar compoziția acestora poate fi redusă prin acord între dezvoltatori, clienți și certificatori în cazuri mai simple.

Activitatea de certificare începe cu acreditarea unui organism sau a unui laborator de testare, formarea și depunerea unei cereri și a unui set de documente către Organismul Central de Certificare pentru a lua o decizie cu privire la oportunitatea acreditării. Dacă rezultatele testelor sunt pozitive, se eliberează și se eliberează un certificat de acreditare.

Regulament privind organismul sau laboratorul de certificare este documentul principal care stabilește aria tematică de acreditare, statutul juridic, funcțiile, structura, drepturile și obligațiile, metodele, mijloacele și organizarea testelor. Pașaportul laboratorului (centrului) de certificare trebuie să conțină informații despre echipamentele cu echipamente informatice necesare testării, personal și personal, echipamente cu instrumente de testare, furnizarea de documente normative, tehnice și metodologice, precum și alte resurse necesare testării.

Quide de calitate conține o declarație de principii, o descriere a metodelor și procedurilor asociate cu implementarea principalelor funcții și sarcini ale organismului de certificare sau laboratorului, asigurând calitatea testelor efectuate și încrederea în rezultatele evaluărilor, testelor și examinărilor. Manualul de calitate include de obicei secțiuni [TWLSC $

• politica de asigurare a calității pentru testare și examinare;
• dotarea centrului cu materiale metodologice și software și instrumente de testare la zi;
• formalizarea cerințelor pentru obiectele de testare;
• politica în domeniul dotării tehnice a centrului și dezvoltării personalului;
• arhivarea și controlul asupra siguranței documentației rezultatelor certificării.

Solicitantul pentru evaluarea produsului sau procesului supus certificării va trimite o cerere organismului de certificare în forma adoptată în sistemul de certificare. Organismul de certificare efectuează, la cerere, lucrări privind pregătirea și organizarea certificării produselor. Această lucrare include:

• selectarea unei scheme de certificare ținând cont de specificul produsului (volum, tehnologie, cerințe ale documentelor de reglementare etc.) și propunerile dezvoltatorului;
• determinarea numărului și ordinii de prelevare și a componentelor care urmează să fie testate, dacă acest lucru nu este specificat în standarde;
• selectarea și determinarea unui laborator de testare acreditat care ar trebui să efectueze teste;
• intocmirea unui proiect de contract pentru executarea lucrarilor.

Partea pregătitoare a lucrării de certificare se încheie cu eliberarea unei decizii în forma adoptată în sistemul de certificare. Decizia, împreună cu proiectul de contract de executare a lucrărilor, se transmite solicitantului. La organizarea testelor de certificare se efectuează selecția și studiul documentelor de reglementare în vigoare pentru produsele declarate pentru certificare, metodele de testare a acestora și evaluarea rezultatelor.

Solicitantul ia deciziile finale care elemente ale sistemului calitatii, domenii si tipuri de activitati organizatorice si tehnice fac obiectul verificarii in timpul certificarii intr-un interval de timp dat. Solicitantul trebuie să creeze condiții și să depună documente care să susțină procesele de verificare. Acesta poate depune organismului de certificare rapoarte de testare efectuate în timpul dezvoltării și lansării produselor pentru producție, documente privind testele efectuate de laboratoare de testare terțe și alte documente care confirmă conformitatea tehnologiei sau produselor cu cerințele stabilite. Pe baza analizei dovezilor documentare furnizate odată cu cererea de conformitate a produselor sale la cerințele stabilite, organismul de certificare poate decide reducerea sferei încercărilor sau eliberarea unui certificat.

Testele sunt efectuate de laboratoare de testare acreditate să efectueze numai acele teste care sunt prevăzute în documentele lor de reglementare, de acreditare. Dacă este imposibil să se efectueze teste la baza de testare a unui laborator acreditat, testele pot fi efectuate de către personalul acestui laborator la producătorul sau consumatorul acestui produs folosind mijloacele proprii ale laboratorului de testare sau instrumentele de testare disponibile de la furnizor.

Procesul de certificare a produselor software și a sistemelor de calitate ale unei întreprinderi include:

• analiza și selecția de către dezvoltatorul sau clientul (solicitantul) a unui organism și a unui laborator certificat competent în acest domeniu să efectueze teste de certificare;
• solicitantul depune o cerere de testare la organismul de certificare, iar certificatorii iau o decizie cu privire la cerere, alegerea unei scheme de certificare, încheierea unui contract de certificare;
• identificarea cerințelor pentru sistemul calității întreprinderii și/sau pentru versiunea produsului software ce urmează a fi testat;
• efectuarea de teste de certificare a sistemului de calitate al întreprinderii sau versiunea produsului software de către laboratorul de certificare;
• analiza rezultatelor obținute și luarea unei decizii de către laborator și/sau organismul de certificare cu privire la posibilitatea eliberării unui certificat de conformitate solicitantului;
• eliberarea de către organismul de certificare către solicitant - un certificat și licență pentru utilizarea mărcii de conformitate și pentru eliberarea produselor certificate - versiuni ale produsului software;
• implementarea controlului de inspecție de către organismul de certificare a sistemului de calitate certificat al întreprinderii și/sau produselor;
• luarea de măsuri corective de către solicitant în cazul încălcării conformității proceselor sistemului calității și/sau produselor cu cerințele stabilite și în cazul utilizării incorecte a mărcii de conformitate.

Revizuirea responsabilității manageriale a dezvoltatorului pentru calitatea produsului ar trebui să determine dacă instalația sau proiectul are o politică de calitate documentată, obiective și angajamente și gradul în care politica este înțeleasă, implementată și menținută la toate nivelurile organizației. Trebuie stabilit că întreprinderea are un reprezentant al conducerii care, indiferent de alte atribuții, are autoritatea și responsabilitatea pentru implementarea continuă a cerințelor standardelor și documentelor de reglementare ale sistemului calității. Este necesar să se verifice disponibilitatea cerințelor, procedurilor, instrumentelor și personalului instruit pentru implementarea practică a proceselor sistemului calității, precum și relevanța și regularitatea documentației pentru toate componentele, cerințele și prevederile sistemului calității, care este un proces integrat de-a lungul ciclului de viață al PS. Verificări ale sistemului calității ar trebui să includă o definiție:

• disponibilitatea și completitudinea documentației tehnologice și conformitatea cu cerințele acesteia în practică;
• starea echipamentelor tehnologice și disponibilitatea unui sistem de întreținere a acestora;
• disponibilitatea și eficacitatea sistemului de control și testare;
• starea instrumentelor de măsurare și testare;
• disponibilitatea unui sistem pentru identificarea și eliminarea deficiențelor identificate în produse sau tehnologie.

Pe baza testelor se evalueaza rezultatele obtinute si se fundamenteaza concluziile privind conformitatea sau neconformitatea produselor sau proceselor cu cerintele documentelor de reglementare. Rapoartele de încercare sunt transmise organismului de certificare, precum și solicitantului la cererea acestuia. Rapoartele de încercare sunt supuse păstrării pe perioadele stabilite în regulile sistemelor de certificare a produselor și în documentele laboratorului de încercări, dar nu mai puțin de trei ani.

După primirea și verificarea completității și calității documentației de către specialiștii laboratorului de încercări, examinarea gradului de aplicare reală a sistemului calităţii la întreprindere. Testarea începe cu un program de audit al sistemului calității, care ar trebui să servească drept plan de lucru pentru lucrările ulterioare. Programul este un document de lucru intern al laboratorului de testare și trebuie să conțină o listă de lucrări, detaliată în conformitate cu specificul dezvoltatorului și cuprinzând o analiză a completității și calității documentelor sursă transmise și a gradului de aplicare practică a acestora în proiectarea, dezvoltarea și livrarea de sisteme software. Examinarea aplicării procedurilor sistemului calității este efectuată de laboratorul de testare la locurile de muncă ale întreprinderii care asigură ciclul de viață al PS. Se efectuează verificări asupra disponibilității specialiștilor-dezvoltatori ai documentelor relevante la locul de muncă și asupra completității utilizării prevederilor și recomandărilor acestora. Evaluările stării proiectului și auditurile interne ale sistemului calității, proceselor și/sau produselor ar trebui să fie efectuate de personal independent de cei direct responsabili de lucru.

Dezvoltarea metodologiilor de control al calității trebuie să fie dotate cu resursele necesare pentru realizarea programului de testare, metode de planificare și elaborarea procedurilor de inspecție privată. Metodele trebuie să conțină: obiectele și scopurile testării; indicatori de calitate evaluați; conditii si procedura de testare; metode de prelucrare, analiză și evaluare a rezultatelor testelor; testează suport tehnic și raportare. Hardware-ul și software-ul utilizat în timpul testelor și a procedurii de testare, precum și rezultatele așteptate ale testelor, trebuie indicate. Ar trebui dezvoltate metode de monitorizare a corecțiilor, acțiuni de corectare a defectelor, dacă o astfel de solicitare este primită de serviciul de management al inspecției. Serviciul de management al programului de testare ar trebui să dezvolte metode pentru menținerea confidențialității oricăror informații de testare, precum și a datelor deținute de experți.

Rapoarte de testare transmisă solicitantului și organismului de certificare. Solicitantul poate depune organismului de certificare rapoarte de testare, ținând cont de termenii de valabilitate a acestora, efectuate în timpul dezvoltării și lansării produselor pentru producție, sau documente privind încercările efectuate de laboratoare de testare autohtone sau străine, acreditate sau recunoscute în certificare. sistem. Pe baza protocoalelor de testare de certificare se evalueaza rezultatele obtinute si se fundamenteaza concluziile trase cu privire la conformitatea sau neconformitatea produselor cu cerintele documentelor de reglementare.

Concluzie asupra rezultatelor testelor de certificare este elaborat de certificatori și conține informații generalizate despre rezultatele testelor și justificarea oportunității eliberării unui certificat. În cazul rezultatelor negative ale testelor de certificare, se ia decizia de a refuza emiterea unui certificat de conformitate. După revizuirea produsului certificat sau a sistemului de calitate, testele pot fi repetate. Rezultatele analizei stării tehnologiei sau calității produsului oficializat printr-un act, care oferă evaluări pentru toate elementele Programului de testare și conține concluzii, inclusiv evaluare generală starea producției și a produselor, necesitatea măsurilor corective. Actul este utilizat de organismul de certificare, împreună cu rapoartele de testare, o cerere pentru eliberarea și determinarea perioadei de valabilitate a unui certificat pentru un produs software, frecvența controlului inspecției, precum și pentru elaborarea măsurilor corective.

Pe baza rezultatelor testelor de certificare și a examinării documentației, se ia o decizie de eliberare a unui certificat. În cazul rezultatelor negative ale testelor de certificare, se ia o decizie refuzul de a elibera un certificat conformitate. In plus, firmei solicitante i se pot transmite propuneri pentru eliminarea presupuselor cauze ale rezultatelor negative ale testelor, dupa finalizarea produsului certificat, testele putand fi repetate.

Organismul de certificare, după analizarea rapoartelor de încercare, evaluarea producției, certificarea sistemului calității, analizarea documentației specificate în decizia privind cererea, evaluează conformitatea produselor cu cerințele stabilite, întocmește un certificat pe baza avizului expertului și îl înregistrează. . Atunci când sunt aduse modificări ale documentației de proiectare sau operaționale care pot afecta calitatea sistemului sau a produsului software, certificat în timpul certificării, solicitantul trebuie să notifice organismul de certificare pentru a lua o decizie cu privire la necesitatea unor teste suplimentare. După înregistrare, certificatul intră în vigoare și este transmis companiei solicitante. Concomitent cu eliberarea certificatului, se poate elibera întreprinderea solicitantă licență pentru dreptul de utilizare a mărcii de conformitate.

Pentru produsele software certificate în timpul funcționării lor pe toată perioada de valabilitate a certificatului de conformitate, controlul de inspecție... Controlul inspecției se realizează sub formă de inspecții periodice și neprogramate de conformitate cu cerințele de calitate a tehnologiei și a produselor certificate. Obiectele controlului, în funcție de schema de certificare, sunt produsele certificate, sistemul calității sau stabilitatea producției a dezvoltatorului. La determinarea frecvenței și volumului verificarea inspecției sunt luați în considerare următorii factori: gradul de pericol potențial al produsului software, stabilitatea producției, volumul producției, prezența și aplicarea unui sistem de calitate în timpul dezvoltării, informații despre rezultatele testelor produsului și ale acestuia. producție efectuată de producător, autorități controlul statului si supraveghere.

Rezultatele controlului inspectiei oficializat printr-un act, care evaluează rezultatele testelor prin probe și ale altor inspecții, face o concluzie generală despre starea producției produselor certificate și posibilitatea menținerii valabilității certificatului eliberat. Actul este păstrat de organismul de certificare, iar copii ale acestuia sunt trimise dezvoltatorului și organizațiilor care au participat la controlul de inspecție. Pe baza rezultatelor controlului de inspecție, organismul de certificare poate suspenda sau anula valabilitatea certificatului și poate revoca licența pentru dreptul de utilizare a mărcii de conformitate în cazul neconformității produsului cu cerințele documentelor de reglementare controlate pe parcursul certificare, precum și în următoarele cazuri:

• modificări fundamentale în modelul de maturitate, profilul standardelor, reglementările produselor sau metoda de testare;
• modificări ale designului (compoziției), caracterului complet al produselor;
• schimbări în organizarea sau tehnologia dezvoltării și producției;
• nerespectarea cerințelor de tehnologie, metode de control și testare, sistem de calitate, dacă modificările enumerate pot determina nerespectarea produselor cu cerințele controlate în timpul certificării.

Decizia de suspendare a valabilității certificatului și a licenței pentru dreptul de utilizare a mărcii de conformitate nu se ia dacă, prin măsuri corective convenite cu organismul de certificare care l-a eliberat, solicitantul poate elimina cauzele de neconformitate descoperite și confirma, fara retestare intr-un laborator acreditat, conformitatea produsului sau proceselor cu documentele de reglementare. Dacă acest lucru nu se poate face, atunci valabilitatea certificatului este anulată, iar licența pentru dreptul de utilizare a mărcii de conformitate este anulată. Informațiile despre suspendarea sau anularea certificatului sunt aduse la cunoștința solicitantului, consumatorilor și altor organizații interesate de către organismul de certificare care l-a eliberat. Valabilitatea certificatului și dreptul de a marca produsele cu marca de conformitate pot fi reînnoite dacă întreprinderea dezvoltatoare îndeplinește următoarele condiții:

• identificarea motivelor nerespectării și eliminarea acestora;
• transmiterea către organismul de certificare a unui raport privind activitatea depusă pentru îmbunătățirea și asigurarea calității produsului;
• efectuarea de teste suplimentare ale produselor conform metodelor si sub controlul organismului de certificare si obtinerea de rezultate pozitive.

Documentarea proceselor și a rezultatelor certificării produselor software

Compoziția și conținutul documentației pentru certificarea sistemului calitățiiîntreprinderile depind de caracteristicile proiectării, dezvoltării și modificării software-ului, precum și de cerințele pentru calitatea acestora și de caracteristicile mediului tehnologic. Prin urmare, setul de documente necesar pentru fiecare întreprindere sau proiect ar trebui selectat și adaptat în raport cu aceste caracteristici. Indicatorii sistemului calității evaluați în timpul certificării sunt disponibilitatea documentelor relevante și îndeplinirea practică a cerințelor unui anumit nivel al modelului de maturitate CMMI sau un profil standard adaptat pe baza ISO 9000: 2000, precum și, create pe baza acestora, fișe de post de către specialiștii întreprinderii dezvoltatoare. Solicitantul trebuie să pregătească și să prezinte laboratorului de testare un set de documente convenit între client și dezvoltator și un set aprobat de documente pentru a verifica fiabilitatea, suficiența compoziției și calitatea fabricării acestora în conformitate cu documentele de reglementare.

Un set orientativ de documente de bază pentru certificare este format din trei grupuri:

• de bază reguli sisteme de calitate în conformitate cu nomenclatura și conținutul profilului standardelor pe baza ISO 9000: 2000 sau modele de maturitate CMMI, precum și programul, manualul și instrucțiunile întocmite de dezvoltatori pe baza acestora, prezentate testatorilor (experților) sistemului sau produselor calității întreprinderii auditate;
• documente sursă care caracterizează o anumită întreprindere sau proiect, precum și ciclul de viață al unui instrument software, întocmite de conducerea proiectului pentru certificarea calității acestuia;
• documente de raportare ale testatorilor, care reflectă rezultatele verificării (certificării) sistemului calității întreprinderii și/sau produsului software, prezentate organismului de certificare, solicitantului și conducerii întreprinderii auditate.

Produsul software sau sistemul de calitate al întreprinderii depus pentru certificare trebuie depus împreună cu documentația relevantă. Lista și conținutul aproximativ al grupelor acestor documente se concentrează pe cazul general al verificării sistemelor calității întreprinderilor care asigură ciclul de viață al produselor software mari. Setul de documente poate fi redus și adaptat prin acord între solicitant, certificator și conducerea întreprinderii auditate în conformitate cu caracteristicile proiectelor software. Unele documente pot fi combinate în rapoarte integrate cu responsabilitate clară a anumitor specialiști pentru implementarea lor.

Documente de bază ale sistemului calității întreprinderii și ciclul de viață al unui instrument software

1. Concept, terminologie, cerințe și îndrumări pentru îmbunătățirea performanței - sisteme de management al calității - ISO 9000: 2000 sau o versiune a modelului de maturitate CMMI.
2. Versiuni adaptate sau listă de clauze și recomandări de standarde ISO 12207, ISO 15504, modificările acestora și ghidurile de aplicare, evidențiate în timpul adaptării și obligatorii pentru utilizare în sistemul calității unei anumite întreprinderi sau proiect de produs software.
3. Versiune adaptată sau listă de clauze și recomandări ale standardului ISO 900003, alocate în timpul adaptării și obligatorii pentru utilizare în sistemul calității unei întreprinderi care produce un produs software.
4. Caracteristici de bază și atribute de calitate ale proiectului PS, evidențiate, adaptate și precizate pe baza standardelor ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. O versiune adaptată și o ediție aprobată a ghidului privind gestionarea întreținerii și configurației bazate pe recomandările standardelor ISO 14764, ISO 10007, ISO 15846.
6. Un set de fișe de post care definesc responsabilitatea, autoritatea și procedura de interacțiune a întregului management, efectuarea și verificarea muncii personalului care participă la procedurile sistemului calității întreprinderii pentru un anumit proiect PS.

Documente sursă care reflectă caracteristicile ciclului de viață al unui anumit instrument software

1. Descrierea caracteristicilor produselor software create la întreprindere, a sistemului și a mediului extern al ciclului lor de viață, necesare pentru adaptarea și pregătirea versiunilor de lucru ale standardelor și cerințelor proiectului PS și ale sistemului calității întreprinderii în conformitate cu recomandări ale standardelor ISO 12207, ISO 15504, ISO 90003și ISO 9126.
2. Descrierea obiectivelor, cerințelor și obligațiilor dezvoltatorului întreprinderii în domeniul sistemului calității, criteriilor de calitate pentru procesele și produsele de dezvoltare, livrare și susținere a întregului ciclu de viață al sistemului software.
3. Un set de documente operaționale furnizate clientului și utilizatorilor pentru a asigura ciclul de viață și utilizarea unei versiuni specifice a produsului software bazată pe standarde adaptate ISO 9294, ISO 15910, ISO 18019.
4. Instrumente de documentare și automatizare pentru proiectare, dezvoltare, modificare, control și testare utilizate pentru a asigura ciclul de viață al unui produs software.
5. Planuri și metode pentru testarea aplicației și evaluarea eficacității proceselor sistemului calității întreprinderii și a produsului software.
6. Metode de întreținere, identificarea componentelor produsului software și a documentației, analiza și aprobarea versiunilor de software și complexe de date.
7. O metodologie de gestionare a configurației, aprobare, stocare, protecție, copiere a versiunilor unui produs software și a documentelor însoțitoare, precum și acumularea și stocarea datelor privind caracteristicile de calitate înregistrate în arhiva unei întreprinderi pe parcursul ciclului de viață al versiunilor unui software produs.

Documentele de testare rezultate - certificarea sistemului calității întreprinderii și/sau a produsului software

1. Un raport privind disponibilitatea, relevanța și sistematicitatea documentației, adaptat la cerințele și prevederile sistemului calității întreprinderii, care asigură un proces integrat de asigurare a calității pe întreg ciclul de viață al unui produs software.
2. Rezultatele monitorizării și testării stării și aplicării sistemului calității efectuate periodic pentru a determina adecvarea și eficacitatea acestuia.
3. Raport privind disponibilitatea și menținerea procedurilor de inspecție și rapoarte documentate privind rezultatele calității obținute de îndeplinire a cerințelor contractului de certificare cu clientul.
4. Rezultatele înregistrării caracteristicilor de calitate realizate ale pachetului software: identificarea, acumularea, stocarea datelor înregistrate privind caracteristicile și atributele calității produsului software și componentelor acestuia.
5. Rezultatele implementării planului de dezvoltare, datele de intrare și ieșire documentate ale etapelor de dezvoltare și protocoale pentru verificarea implementării ciclului de viață al software-ului.
6. Rezultatele implementării practice a programului calității și implementării activităților reglementate în domeniul calității în toate etapele ciclului de viață PS.
7. Rezultatele certificării simulatoarelor de mediu și generatoarelor de teste, precum și o evaluare a suficienței acestora pentru efectuarea testelor de certificare a unui produs software.
8. Rezultatele analizei implementării planurilor și metodelor de testare, rapoarte de testare, evaluări ale conformității rezultatelor testelor cu cerințele, precum și rezultatele testelor aprobate de reprezentanții solicitantului, clientului și furnizorului.
9. Actul rezultatelor verificărilor caracteristicilor reale ale ciclului de viață al software-ului și ale sistemului de calitate al întreprinderii, concluzii despre conformitatea acestora cu cerințele de certificare a producției unui produs software.
10. Certificat al sistemului calității întreprinderii și/sau al produsului software și care asigură ciclul de viață al acestuia, licență de utilizare a mărcilor de conformitate.

Literatură

V.V. Lipaev - Profilele standardelor ciclului de viață al software-ului. -- Jet Info, Newsletter, N 12, 2005

K. Milman, S. Milman - СММI - un pas în viitor. -- Sisteme deschise., N 5-6 (2005), N2 (2006), 2005, 2006

Evaluarea si atestarea maturitatii proceselor de creare si intretinere software si sisteme informatice ISO IEC TR 15504-CMMI. Pe. din engleza -- M .: Carte și afaceri, 2001

V.V. Lipaev - Procese și standarde pentru ciclul de viață al software-ului complex. Director.- M .: SINTEG, 2006

V.V. Lipaev - Tehnici de asigurare a calității pentru software la scară largă.- M .: RFBR. SINTEZĂ, 2003

"; antisursă:" Produsele software sunt acum folosite pentru a rezolva probleme de management în aproape toate sferele activității umane: în economie, social, militar și alte domenii. Asigurarea calității înalte a produselor software autohtone în timpul dezvoltării și livrării lor în masă pentru diverse aplicații din țară și de pe piața mondială a devenit o sarcină strategică.”; Condiție: 1] $