Introducere

Cea mai importantă parte a sistemelor complexe moderne sunt produsele software - componenta intelectuală. Produsele software sunt acum folosite pentru a rezolva probleme de management în aproape toate domeniile activității umane: în economie, social, militar și alte domenii. Securitate Calitate superioară produse software autohtone cu lor dezvoltare în masă si furnizarea pentru diverse aplicatii in tara si pe piata mondiala a devenit un 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 (International Standards Organization) și modele de maturitate SEI (US Software Engineering Institute). Primele sunt destul 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 de evaluare a maturității ingineriei software). Aceste două direcții sunt metodologic foarte apropiate și se intersectează parțial prin referințe reciproce.

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

Pentru a certifica calitatea, fiabilitatea și siguranța utilizării sistemelor complexe, critice, produsele software utilizate în acestea sunt supuse certificare centre sau laboratoare de testare certificate, orientate către probleme. Astfel de teste ar trebui efectuate atunci când programele gestionează procese complexe, critice sau procesează informații atât de importante încât defectele acestora sau calitatea insuficientă pot cauza daune semnificative. Testele de certificare ar trebui să stabilească conformitatea complexelor software cu cerințele documentației și să le permită să funcționeze în limitele modificărilor parametrilor mediului extern studiați în timpul testelor. Aceste tipuri de teste sunt caracterizate de cea mai mare severitate ș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 de testare a pachetelor de software pentru conformitatea cu cerințele standardizate ale clienților, probleme de testare special concepute și generatoare pentru formarea lor, precum și calificarea și autoritatea înalte a testatorilor. Aplicare la întreprinderi-dezvoltatori de produse software, sisteme de calitate certificate pentru asigurarea ciclului de viață al PS pe baza cerințelor 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ă aleagă contractori de implementare care dețin certificate care atestă aplicarea sistemelor de asigurare a calității bazate pe profiluri de standarde internaționale adaptate sau modele de maturitate.

Lacunele în predarea metodelor de inginerie software lasă un câmp larg pentru arbitrariul specialiștilor în evaluarea calității muncii lor, precum și pentru apariția a numeroase defecte și erori în proiectele software. Complexitatea și responsabilitatea tot mai mare a sarcinilor moderne rezolvate de programe, precum și posibilele daune din calitatea insuficientă a rezultatelor acestora, au crescut semnificativ relevanța metodelor de stăpânire pentru o descriere completă, standardizată a cerințelor pentru caracteristicile de calitate și metodele de măsurare. valorile lor reale, atinse în diferite etape ale ciclului de viață al software-ului. Nevoia specialiştilor de a cunoaşte conceptele, definiţiile şi metodele de evaluare a caracteristicilor calităţii 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 dezvoltatorilor din contracte de a furniza software de înaltă calitate în intervalele de timp convenite nu sunt adesea respectate. Adesea, acest lucru se întâmplă din cauza faptului că clientul și antreprenorul evaluează nivelul de calitate în funcție de criterii diferite, și nu sunt de acord cu această problemă, iar abordarea de evaluare a calității programelor nu este suficient de formalizată. În plus, uneori există o lipsă a capacității 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 - realizarea proceselor de proiect. gestionabil, 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 aplicării pachetelor software complexe, ținând cont de resursele disponibile pentru asigurarea și îmbunătățirea acestei calități.

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 semnificativă în CMMI este acordat proceselor de dezvoltare și contabilizării iterațiilor la schimbarea cerințelor clienților, trasabilitatea acestora la funcții, componente, teste și documente de proiect. Recent, au apărut informații despre modernizarea versiunii SEI a versiunii 2003. CMMI-1.1 pe baza experienței acumulate și a feedback-ului de la întreprinderi. Se presupune că va lansa în 2006 o versiune nouă, semnificativ îmbunătățită a modelului 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 obligatorie pentru o evaluare oficială a calității (certificarea) tehnologiei întreprinderii în domeniul ingineriei software. Perioada de valabilitate a 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 conceput pentru a oferi continuu evaluarea unui complex de procese în Zona specifica crearea de software sau pe etape evaluarea și îmbunătățirea maturității întreprinderii, precum și pentru organizarea ciclului de viață al complexelor de programe în general. Modele CMMI să ofere asistență specialiștilor în organizarea și îmbunătățirea produselor lor, precum și în eficientizarea și deservirea proceselor de dezvoltare și întreținere a PS. Conceptul acestor modele acoperă managementul și evaluarea maturității sistemelor complexe, ingineria software, precum și procesele de creare a produselor software integrate și îmbunătățirea dezvoltării acestora. Componentele modelelor continue și fazate 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:

• cuvânt înainte;
• 1 sectiune - introducere;
• Sectiunea 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 cele patru categorii de procese din secțiunea 7, prezentarea lor generală și schemele de interacțiune ale proceselor CMMI:
  • administrarea procesului;
  • management - management de proiect;
  • inginerie (tehnologie);
  • a sustine;
• Secțiunea 6 - Utilizarea modelului CMMI- recomandari succinte pentru utilizatori cu privire la aplicarea modelului si instruire; se notează compatibilitatea și conformitatea proceselor model 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, ocupă aproximativ 500 de pagini din totalul documentului, adică 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/ingineria software-ului/dezvoltarea integrată a produselor și a proceselor, versiunea 1.1, reprezentare continuă (CMMI-SE/SW/IPPD, V1.1, Continuu). Inginerie integrată a sistemelor/Inginerie software/Model de evaluare a maturității procesului de dezvoltare și produse integrate - vedere continuă. În acest model, a șaptea secțiune constă din procese:

• administrarea procesului:
  • organizarea instruirii;
  • organizarea transformării (schimbă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 (atestare, aprobare);
• a sustine:
  • managementul configurației;
  • analiza și luarea deciziilor privind schimbările;
  • analiza cauzei principale și rezolvarea problemelor (eliminarea defectelor).

Cele cinci anexe oferă:

DAR- alcătuirea surselor și documentelor literare utilizate, care însă nu menționează standarde ISO;

LA- abrevieri;

DIN- terminologie bazată pe glosar ISO folosit doar în 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- proiect.

În acest model, atenția este concentrată pe procesele organizaționale, pe planificarea, gestionarea și controlul proceselor de implementare a proiectelor software, pe dezvoltarea și gestionarea cerințelor pentru produsele software. Următoarele sunt exemple de detalii în CMMI unii dintre ei.

Planificarea proiectuluiîn acest, precum și în al doilea model include:

• evaluarea dimensiunii (scalei) posibile a produsului software;
• evaluarea complexității funcțiilor și caracteristicilor proiectului PS;
• definirea modelului și etapelor ciclului de viață al pachetului software;
• studiul de fezabilitate al proiectului - determinarea costului, intensității forței de muncă și a duratei ciclului de viață al stației;
• elaborarea unui program de lucru în etape și a bugetului proiectului;
• analiza, identificarea și evaluarea riscurilor proiectului;
• planificarea și gestionarea documentației proceselor și produselor în ciclul de viață al proiectului 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 pentru 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.

Procese de dezvoltare a cerințelor la un produs software sunt similare cu procesele din ambele modele și includ:

• identificarea nevoilor reale ale clientului și utilizatorilor pentru funcțiile și 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 proiectului suită de software;
• descompunerea cerințelor inițiale de bază pentru funcțiile PS într-un set de cerințe pentru componentele și testele pachetului software;
• formalizarea cerințelor pentru interfețele dintre componente, cu mediul de operare și extern;
• dezvoltarea conceptului de produs software și scenarii de utilizare a acestuia;
• dezvoltarea cerințelor pentru caracteristicile generalizate de adecvare funcțională și utilizarea funcțiilor produsului software în scopul propus.

Managementul Cerintelor ambele modele includ:

• realizarea unei înțelegeri clare a cerințelor pentru proiectul PS de către client și dezvoltatori;
• obținerea 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 pentru proiectul PS convenite între client şi dezvoltator;
• asigurarea corectitudinii modificărilor de la cerințele generale pentru proiectul PS la cerințele pentru componente și procese particulare;
• identificarea și identificarea discrepanțelor între procesele de dezvoltare a proiectelor și cerințele clienților.

A doua varianta prezinta documentul: Integrarea modelului de maturitate a capabilităților (CMMI) pentru ingineria sistemelor/ingineria software-ului/dezvoltarea integrată a produselor și a proceselor, versiunea 1.1, reprezentare în etape (CMMI-SE/SW/IPPD, V1.1, în etape). Inginerie integrată a sistemelor/Inginerie software/Model de evaluare a maturității procesului de dezvoltare și produse integrate - introducere î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 se caracterizează printr-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 recomandat să fie limitat 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 reprezentării calității proceselor;
  • managementul cantitativ al întregului proiect și al resurselor;
• al cincilea nivel- optimizare, imbunatatire continua:
  • organizarea, inovarea, managementul cantitativ al proceselor și furnizarea de resurse;
  • 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 superior de maturitate toate procesele nivelurile inferioare anterioare. În ambele versiuni ale modelului, fiecare proces de bază evidențiat mai sus este comentat cu recomandări detaliate pentru implementarea sa practică, care conțin descrieri de aproximativ 20–30 de pagini unificate în structură:

• obiectivele generale ale procesului de atins;
• observații introductive și o descriere generală a funcțiilor procesului;
• obiective specifice procesului;
• administrarea procesului;
• dezvoltarea cerințelor procesului;
• interacțiune și interfețe cu alte procese;
• scopuri practice - rezultatele solicitate ale 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 în ceea ce privește domeniul de aplicare, conținutul și caracterul complet al descrierilor proceselor de bază sunt similare cu o serie de standarde pentru Profilul ciclului de viață PS prezentat în. Comandarea ș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 produse software în ceea ce privește calitatea prevăzută a proceselor și rezultatele activităților lor și pregătirea pentru certificare pentru respectarea unui anumit nivel de maturitate al modelului CMMI - 1.1.

Accent pe modele CMMI este dat proceselor de management ale proiectului PS. Aceste cerințe și procese ale modelelor corespund practic recomandărilor reglementate și detaliate din standarde. ISO 9001:2000și principalele componente ale profilului standardelor complexe ale ciclului de viață PS [ , ]. Cerințe pentru procese din secțiunile funcționale 4-8 din standarde ISO 9001, ISO 9004, ISO 90003 un număr de secțiuni adecvate ca conținut pot fi comparate în model CMMI(în Fig. 1, zona de suprapunere a conținutului). Comunitatea proceselor și cerințelor constă în asemănarea: compoziția, terminologia, structura, lista proceselor de management recomandate, planificarea, 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 susținerii și reglementării întregului ciclu de viață al proiectelor software mari, deficiențele modelelor CMMI privind profilul standardelor existente ISO poate include următoarele:

Un amplu raport tehnic a fost elaborat și aprobat inițial în 1998 pentru a determina nivelurile de maturitate ale proceselor de asigurare a ciclului de viață al PS prezentate mai sus. ISO 15504, constând din nouă părți și multe aplicații. Se conturează modelul de maturitate CMM si opt principii de baza inginerie software bazată pe standard ISO 9000:2000. Apoi în ISO acest document a suferit o revizuire radicală, reducerea, simplificarea structurii și conținutului, menținând în același timp pe deplin obiectivele și conceptul, și a fost aprobat ca standardîn cinci părți.

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

• a stabili starea proprie procese tehnologiceși îmbunătățirea acestora;
• pentru a determina adecvarea proceselor proprii pentru a îndeplini cerințele specifice sau clase de cerințe ale clienților;
• în vederea adecvării sale pentru performanţă anumite tratate cu clienții PS și sisteme.

Standardul contribuie la: autoevaluarea maturității întreprinderilor, asigurarea managementului adecvat al proceselor atestate, determinarea profilului evaluărilor proceselor și, de asemenea, se potrivește oricărui scop și dimensiune a sistemului de operare și a sistemelor. Aplicarea standardului vizează dezvoltarea întreprinderilor și a specialiștilor cultura de îmbunătățire continuă a maturității tehnologiei asigurarea ciclului de viață al PS care îndeplinește obiectivele de afaceri ale proiectelor și optimizarea utilizării resurselor disponibile. Evaluarea maturității procesului de întreprindere oferă o oportunitate de a le compara și selecta, 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 vânzători și dezvoltatori: capacitatea de a determina maturitatea actuală și potențială a proceselor, domeniilor și priorităților ciclului de viață al propriilor software și sisteme pentru îmbunătățirea procesului;
• pentru evaluatorii de înmatriculare: un cadru pentru desfășurarea și îmbunătățirea proceselor de evaluare.

Aprobarea în standard este tratată în doua aspecte: pentru a îmbunătăți procesele ciclului de viață al PS și a sistemelor unei anumite întreprinderi și pentru a determina dacă maturitatea declarată a proiectului sau a proceselor de sprijin al întreprinderii corespunde proceselor efective 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 informații generale despre procesele de certificare a maturității software-ului și sistemelor și recomandări pentru utilizarea părților standardului. Conturat Cerințe generale pentru certificare, terminologie, structură, se determină domeniul de aplicare al părților rămase ale standardului.

Partea 2 - Efectuarea (producția) certificării. Include cerințe detaliate pentru desfășurarea proceselor de certificare ca bază pentru îmbunătățirea și determinarea nivelului de maturitate al proceselor tehnologice pentru asigurarea ciclului de viață al PS și al sistemelor. Documentul definește procese de realizare a atestării, modele de procese recomandate pentru atestare și verificarea proceselor astfel încât acestea să fie obiective, semnificative și reprezentative.

Partea 3 - Ghid pentru producerea certificării. Oferă o privire de ansamblu asupra tehnologiei pentru efectuarea proceselor de evaluare 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 certificatorilor; verificarea conformității atestării la cerințele declarate. Instrumentele de validare pot fi utilizate de întreprinderi în planificarea, gestionarea, monitorizarea, controlul și îmbunătățirea produselor și sistemelor software, în achiziționarea, dezvoltarea, aplicarea și întreținerea acestora.

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

Partea 5 - Exemplu de model de procese de atestare pentru conformitatea cu cerințele prezentate în partea 2. Un document extins (162 de pagini) oferă exemple practice ale părților anterioare ale standardului pentru organizarea, evaluarea și îmbunătățirea evaluărilor maturității procesului ciclului de viață pentru diferite domenii de aplicații, proiecte software și întreprinderi.

În implementarea practică a proiectelor și asigurarea ciclului de viață al software-ului complex, este uneori dificil pentru dezvoltatori și furnizori să identifice și să evidențieze avantajele modelelor de aplicare. CMMI. În funcție de tradițiile întreprinderii și de caracteristicile unui proiect mare, este adesea recomandabil să se utilizeze PS ca principal profil standardelorISO, și pentru evaluarea clienților nivelul de maturitate managementul, suportul organizatoric și tehnologic al proiectelor PS aplică recomandări specifice CMMI. Aceste linii directoare pot fi utilizate eficient în certificarea calitatii procesului la întreprinderile care furnizează ciclul de viață al PS, ca alternativă sau împreună cu certificarea conform unui set de standarde de management ISO 9000, în funcție de specificul proiectului și de cerințele solicitantului de certificare a unui produs software sau tehnologie pentru asigurarea ciclului 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 experți - inspectori calificați, atestați. Pentru certificarea întreprinderii-dezvoltator și rezultatele 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 ciclului de viață al PS. Procesele și documentele enumerate mai jos sunt concepute pentru proiecte mari și pot fi reduse prin acord între dezvoltatori, clienți și certificatori în cazuri mai simple.

Lucrările 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 fezabilitatea acreditării. Dacă rezultatele testelor sunt pozitive, se întocmește și se eliberează un certificat de acreditare.

Reglementări privind organismul sau laboratorul de certificare este documentul principal care stabilește tematica de acreditare, statutul juridic, funcțiile, structura, drepturile și obligațiile, metodele, mijloacele și organizarea testelor. Pașaportul laboratorului de certificare (centru) trebuie să conțină informații despre echipament informatică necesare pentru testare, pe 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 a principiilor, o descriere a metodelor și procedurilor asociate cu implementarea principalelor funcții și sarcini ale organismului de certificare sau laboratorului, asigurând calitatea testelor și încrederea în rezultatele evaluărilor, testelor și examinărilor. Manualul de calitate include de obicei secțiuni [ TWLSC$

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

Pentru evaluarea produselor sau proceselor supuse certificării, solicitantul trimite o cerere la organismul de certificare în forma adoptată în sistemul de certificare. Organismul de certificare efectuează lucrări de pregătire și organizare a certificării produsului la cerere. Această lucrare include:

• selectarea unei scheme de certificare ținând cont de specificul produselor (volum, tehnologie, cerințe ale documentelor de reglementare etc.) și propunerile dezvoltatorului;
• determinarea numărului și ordinii de prelevare și a componentelor de testat, dacă acest lucru nu este specificat în standarde;
• selectarea și identificarea unui laborator de testare acreditat pentru efectuarea testelor;
• intocmirea unui proiect de contract pentru executarea lucrarilor.

Partea pregătitoare a lucrării privind certificarea 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, selecția și studierea documentelor de reglementare în vigoare pentru produsele declarate pentru certificare se efectuează metode de testare și evaluare a rezultatelor.

Solicitantul ia deciziile finale care elemente ale sistemului calității, domenii și tipuri de activități organizatorice și tehnice sunt supuse verificării în timpul certificării într-un interval de timp dat. Solicitantul trebuie să creeze condiții și să depună documente pentru a asigura procesele de verificare. El poate depune organismului de certificare rapoarte de testare efectuate în timpul dezvoltării și producerii produselor, documente privind testele efectuate de laboratoare de testare terțe și alte documente care indică conformitatea tehnologiei sau produselor cu cerințele stabilite. Pe baza analizei dovezilor documentate de conformitate a produselor sale cu cerințele stabilite, prezentate odată cu cererea, organismul de certificare poate decide reducerea sferei de aplicare a testelor 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ă nu este posibil să se efectueze teste la unitatea de testare a unui laborator acreditat, testele pot fi efectuate de către personalul acestui laborator la producătorul sau consumatorul acestui produs utilizând instalațiile proprii ale laboratorului de testare sau instalațiile de testare disponibile de la furnizor. .

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

• analiza și selecția de către dezvoltatorul sau clientul (solicitantul) a unui organism competent în acest domeniu și a unui laborator autorizat pentru efectuarea testelor de certificare;
• depunerea de către solicitant a unei cereri de testare către organismul de certificare și adoptarea de către certificatori a unei decizii privind cererea, alegerea unei scheme de certificare, încheierea unui acord de certificare;
• identificarea cerințelor pentru sistemul calității întreprinderii și/sau pentru versiunea produsului software de testat;
• efectuarea testelor de certificare a sistemului de calitate al companiei sau a versiunii produsului software de către laboratorul de certificare;
• analiza rezultatelor obținute și luarea deciziilor de către laborator și/sau organism 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 o licență de utilizare a mărcii de conformitate și de eliberare a 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;
• realizarea de către solicitant a măsurilor corective în cazul încălcării conformității proceselor sistemului calității și/sau produselor cu cerințele stabilite și în cazul aplicării incorecte a mărcii de conformitate.

La verificarea responsabilității conducerii dezvoltatorului pentru calitatea produsului, trebuie să se stabilească că întreprinderea sau proiectul are o politică documentată, obiective și obligații în domeniul calității, precum și gradul în care această politică este înțeleasă, implementată și menținută. în stare de lucru 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. Trebuie verificată disponibilitatea cerințelor, procedurilor, instrumentelor și personalului instruit pentru implementarea practică a proceselor sistemului calității, precum și relevanța și documentarea sistematică a tuturor componentelor, cerințelor și prevederilor sistemului calității, care este un proces integrat pe tot parcursul ciclul 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;
• existența ș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 testare 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, specialiștii laboratorului de testare trebuie să efectueze examinarea gradului de aplicare efectivă a sistemului calităţii la întreprindere. Testarea începe cu dezvoltarea unui program de testare a 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 ar trebui să conțină o listă de lucrări, detaliată în conformitate cu specificul întreprinderii dezvoltatoare și care să includă o analiză a completității și calității documentelor sursă transmise și a gradului de aplicare practică a acestora. în proiectarea, dezvoltarea și livrarea software-ului. 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 prezenței specialiștilor-elaboratori de documente relevante la locul de muncă și asupra caracterului complet al 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 implementarea acestor lucrări.

Metode de verificare a calității dezvoltării ar trebui furnizate resursele necesare pentru implementarea programului de testare, metode de planificare și dezvoltarea procedurilor private de testare. 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; suport tehnic testare și raportare. Trebuie indicate hardware-ul și software-ul utilizat în timpul testelor și procedurii de testare, precum și rezultatele așteptate ale verificărilor. Ar trebui dezvoltate metode de control al corecțiilor, acțiuni de corectare a defectelor, dacă o astfel de solicitare este primită de serviciul de management al auditului. Serviciul de management al programului de testare ar trebui să stabilească proceduri pentru menținerea confidențialității oricăror informații de testare, precum și a datelor deținute de evaluatori.

Rapoarte de testare transmisă solicitantului și organismului de certificare. Solicitantul poate depune la organismul de certificare rapoarte de testare, ținând cont de termenii de valabilitate a acestora, efectuate în timpul dezvoltării și producerii produselor, sau documente privind încercările efectuate de laboratoare de testare autohtone sau străine acreditate sau recunoscute în sistemul de certificare. Pe baza protocoalelor de testare de certificare se evaluează rezultatele obținute și se fundamentează concluziile trase cu privire la conformitatea sau neconformitatea produselor cu cerințele documentelor de reglementare.

Concluzie asupra rezultatelor testelor de certificare este dezvoltat de certificatori și conține informații generalizate despre rezultatele testelor și motivele pentru eliberarea unui certificat. În cazul obținerii unor rezultate negative la testele de certificare, se ia decizia de a refuza eliberarea unui certificat de conformitate. După finalizarea produsului certificat sau a sistemului de calitate, testele pot fi repetate. Rezultatele analizei stării tehnologiei sau calității produsului sunt întocmite printr-un act, care oferă estimări pentru toate pozițiile Programului de testare și conține concluzii, inclusiv o evaluare generală a stării producției și a produselor, necesitatea măsurilor corective. Actul este utilizat de organismul de certificare împreună cu rapoartele de testare, o cerere pentru emiterea și determinarea perioadei de valabilitate a unui certificat pentru un produs software, frecvența controlului inspecției și, de asemenea, pentru elaborarea măsurilor corective.

Pe baza rezultatelor testelor de certificare și a examinării documentației, se ia decizia de a elibera un certificat. În cazul obținerii rezultatelor negative la testele de certificare, se ia o decizie refuzul de a elibera un certificat conformitate. În plus, propunerile pot fi trimise întreprinderii solicitante pentru a elimina presupusele cauze ale rezultatelor negative ale testelor, după finalizarea produselor certificate, testele pot 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 experților. și îl înregistrează. Atunci când efectuează 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 despre acest lucru organismul de certificare pentru a decide asupra necesității unor teste suplimentare. După înregistrare, certificatul intră în vigoare și este transmis întreprinderii solicitante. Concomitent cu eliberarea unui certificat, întreprinderea solicitantă poate fi eliberată licență pentru dreptul de a folosi marca 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 de inspecție se efectuează sub formă de periodic și inspecții neprogramate respectarea cerințelor 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 dezvoltatorului. La determinarea frecvenței și a amplorii inspecției, se iau în considerare următorii factori: gradul de pericol potențial al produsului software, stabilitatea producției, volumul de lansare, disponibilitatea și aplicarea unui sistem de calitate în timpul dezvoltării, informații. privind rezultatele testelor produsului și producției acestuia efectuate de producător, organele de control și supraveghere de stat.

Rezultatele controlului inspecției sunt întocmite printr-un act, care evaluează rezultatele testelor prin probe și ale altor verificări, face o concluzie generală despre starea producției produselor certificate și posibilitatea menținerii valabilității certificatului eliberat. Actul este stocat în organismul de certificare, iar copiile sale sunt trimise dezvoltatorului și organizațiilor care au participat la controlul de inspecție. Pe baza rezultatelor controlului inspecției, 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 produselor cu cerințele documentelor de reglementare controlate în timpul certificării. , precum și în următoarele cazuri:

• modificări fundamentale ale modelului de maturitate, profilului standardelor, reglementărilor produsului sau metodei 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 detectate și poate confirma , fara a re-testa intr-un laborator acreditat, conformitatea produsului sau proceselor cu documentele normative. Dacă acest lucru nu se poate face, atunci valabilitatea certificatului este anulată și licența pentru dreptul de utilizare a mărcii de conformitate este anulată. Informațiile despre suspendarea sau anularea certificatului sunt aduse de către organismul de certificare care l-a eliberat solicitantului, consumatorilor și altor organizații interesate. Valabilitatea certificatului și dreptul de a eticheta produsele cu marca de conformitate pot fi reînnoite dacă întreprinderea dezvoltatoare îndeplinește următoarele condiții:

• identificarea cauzelor 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. SMMI sau un profil standard adaptat pe baza ISO 9000:2000, precum și create pe baza lor, descrierea postului specialişti ai întreprinderii-dezvoltator. Solicitantul trebuie să pregătească și să prezinte laboratorului de testare un set de documente convenite între client și dezvoltator și aprobate pentru a verifica fiabilitatea, suficiența compoziției și manopera 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 bazate pe ISO 9000:2000 sau modele de maturitate SMMI, 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, pregătite de conducerea proiectului pentru certificarea calității acestuia;
• documentele de raportare ale testatorilor care reflectă rezultatele auditului (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 să fie prezentat împreună cu documentația relevantă. Lista și conținutul aproximativ al grupelor acestor documente sunt concentrate 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 conform acordului între solicitant, certificator și conducerea întreprinderii auditate, în conformitate cu caracteristicile proiectelor software. Unele documente pot fi combinate în rapoarte integrate cu o responsabilitate clară a anumitor specialiști pentru implementarea lor.

Documente de bază ale sistemului calității întreprinderii și ciclului de viață al software-ului

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 secțiuni și recomandări ale standardelor ISO 12207, ISO 15504, modificările acestora și ghidurile de aplicare, selectate î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 secțiuni și recomandări ale standardului ISO 900003, selectat în timpul adaptării și obligatoriu pentru utilizare în sistemul calității unei întreprinderi care produce un produs software.
4. Caracteristici de bază și atribute de calitate ale proiectului PS, identificate, adaptate și specificate pe baza standardelor ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. Versiune adaptată și ediție aprobată a manualului de management al întreținerii și configurării pe baza recomandărilor 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 tuturor activităților manageriale, de executare și de verificare a personalului implicat în 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 întreprinderii-dezvoltator în domeniul sistemului calității, criteriilor de calitate pentru procesele și produsele de dezvoltare, livrare și susținere a întregului ciclu de viață al software-ului.
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 de testare a aplicației și de evaluare a 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. Metodologia de gestionare a configurației, aprobare, stocare, protecție, copiere a versiunilor de produse software și a documentelor însoțitoare, precum și acumularea și stocarea datelor privind caracteristicile de calitate înregistrate în arhiva întreprinderii pe durata ciclului de viață al versiunilor de produse software.

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

1. Un raport privind disponibilitatea, relevanța și execuția sistematică a documentației adaptate cerințelor și prevederilor sistemului calității întreprinderii, care asigură un proces integrat de asigurare a calității pe întreg ciclul de viață al produsului 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 metodelor de efectuare a inspecțiilor și rapoarte documentate privind rezultatele calității obținute de îndeplinire a cerințelor acordului 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 PS.
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ță al 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ării caracteristicilor reale ale ciclului de viață al sistemului software și al 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 -- Profiluri pentru standardele ciclului de viață al software-ului. -- Jet Info, Newsletter, N 12, 2005

K. Milman, S. Milman -- SMMI este un pas în viitor. -- sisteme deschise., N 5-6 (2005), N2 (2006), 2005, 2006

Evaluarea și certificarea maturității proceselor de creare și întreținere a instrumentelor software și a sistemelor informatice ISO IEC TR 15504-CMMI. Pe. din engleza -- M.: Carte și afaceri, 2001

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

V.V. Lipaev -- Metode de asigurare a calității software-ului la scară largă.-- M.: RFBR. SINTEG, 2003

"; antisursă: „Produsele software sunt acum folosite pentru a rezolva probleme de management în aproape toate domeniile 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 pe piața mondială a devenit o sarcină strategică."; condiție: 1]$

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

Un instrument practic minunat creat în cadrul abordarea procesuala la descrierea activității organizarea designuluiîn special, organizaţia care se dezvoltă Sisteme de informare , demonstrează metodologia HMM. CMM înseamnă Capability Maturity Model, care înseamnă aproximativ „model de maturitate a sistemului de management”. În literatura de specialitate, CMM este mai frecvent menționat ca un model de maturitate organizațională și voi urma și această tradiție.

Istoria apariției SMM este următoarea. La sfârşitul anilor '80. secolul trecut, Departamentul de Apărare al SUA a comandat Institutul de Inginerie Software 1Eng. SEI - Institutul de Inginerie Software Universitatea Carnegie Mellon lucrează la un sistem de criterii de selectare a subcontractanților în proiecte de dezvoltare software. Lucrarea a fost finalizată în 1991 și a rezultat CMM. Trebuie să facem imediat o rezervă că modelul nu conține niciun fel financiar, economic, politic, organizatoric criterii de selecție subcontractant, precum și criteriile pentru posibilitatea de admitere la muncă secretă (probabil, astfel de sarcini nu au fost stabilite). Vorbim doar de criterii 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 (capacitate) a fost numită maturitate. Apoi au făcut niște presupuneri non-triviale, care au fost ulterior acceptate și recunoscute drept corecte de mulți profesioniș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 contractele Ministerului 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ă „săriți” peste nivel (mai precis, riscurile pentru organizație cresc brusc în același timp).

Astfel, nivelurile formează o „scără” 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. SMM „Scara de nivel” a fost acceptată și diseminată pe scară largă. Iată cum arată ea.

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 soluției software care este creată. A stabilit disciplina de proces necesară pentru a reproduce succesele trecute în proiecte similare de dezvoltare a aplicațiilor.

Nivelul 3 „Definit”. Procesul de producție este documentat și standardizat pentru ambele munca manageriala 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 de operare standard 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 fabricatie cat si produsele sunt evaluate si controlate din punct de vedere cantitativ.

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 acesta.

În ciuda lipsei de rigoare, definiția de mai sus intuitiv, cel mai adesea, nu ridică obiecții. În plus, specialiștii cu experiență înțeleg de ce tranzițiile sunt posibile doar la nivelul următor, precum și de ce 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 chiar formală a unei astfel de demersuri, ceea ce, însă, nu îi scade meritele.

Mai mult, după cum se spune, este o chestiune de tehnologie. Structura modelului este definită (Figura 7.1), sunt date definiții și începe munca minuțioasă pentru a descrie cu acuratețe fiecare proces la fiecare nivel. Pentru a evalua valoarea practică a ceea ce sa făcut, să parcurgem o parte a acestui drum.

Orez. 7.1.

Pe fig. 7.1 conține următoarele concepte.

Grupul 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 căruia se atinge un set de obiective care sunt semnificative pentru creșterea productivității procesului de producție. Pentru de exemplu, pentru un grup de procese cheie " Managementul Cerintelor„(Vezi Figura 7.2) scopul este de a reconcilia cerințele proiectului de dezvoltare software între client și dezvoltator.”

Nu există procese individuale în CMM. În schimb, există lucrări individuale, numite practici cheie (vezi mai jos), conectate între ele prin intrări și ieșiri și care servesc drept material sursă pentru procesele de construcție. CMM nu oferă îndrumări cu privire la modul în care ar trebui să fie structurate procesele, adică legarea practicilor cheie în secvențe logice. Seturile de practici cheie sunt numite grupuri de procese cheie.

Orez. 7.2.

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

Adjectivul „cheie” implică faptul că există grupuri de procese(adică seturi de practici) care nu sunt cheie în ceea ce privește un anumit nivel de maturitate, adică nu sunt legate de atingerea obiectivelor acestui nivel (vezi mai jos). Modelul HMM nu descrie totul grupuri de procese referitoare la dezvoltarea și întreținerea de software . Acesta descrie numai acele grupuri care sunt identificate ca factori determinanți cheie ai productivității procesului de producție.

Goluri. Obiectivele din CMM 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 scopului înseamnă că, în primul rând, după implementarea practicilor cheie, se obține rezultatul dorit și, în al doilea rând, se obține destul de consistent. Modul în care sunt atinse obiectivele Grupului de proces cheie poate diferi de la proiect la proiect datorită diferențelor 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 corelat cu acest grup de procese cheie.

Capitol. Secțiunile (există cinci dintre ele 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 în ce măsură sunt legalizate în organizație, adică aprobate oficial și coordonate cu procedurile, politicile și alte procese corporative. Iată cele cinci secțiuni.

Obligații de executare

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 performanță se referă de obicei la stabilirea politicilor organizaționale și a sprijinului din partea managementului de vârf.

Cerințe preliminare

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

Operațiuni în curs

Secțiunea Operațiuni în curs descrie munca de fond care trebuie efectuată la acest nivel. Operațiunile efectuate includ de obicei crearea de planuri și implementarea de operațiuni specifice, executarea ș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 unui grup de procese cheie.

Fiecare practică cheie constă dintr-o singură propoziție, adesea urmată de o descriere mai detaliată, care poate include exemple și clarificări. Practicile cheie, uneori denumite practici cheie de nivel superior, stabilesc politicile, procedurile și operațiunile de bază pentru un grup de procese cheie. Componentele descrierii detaliate sunt adesea denumite sub-practici.”

Practicile cheie descriu CE trebuie făcut, dar nu ar trebui luate ca dogme despre CUM trebuie atinse obiectivele. Obiectivele grupului cheie de procese 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, ca 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ă un set de niveluri care conțin practici cheie disparate (adică, neintegrate în procese) și o secvență recomandată pentru trecerea prin niveluri. Managementul IT, conform CMM, se îmbunătățește pe măsură ce trece la un nivel mai ridicat de maturitate. Ce se întâmplă cu această promoție?

În definițiile nivelurilor (vezi Figura 7.2), a apărut un astfel de „proces de producție”. Este prezent și în definiția unui grup de procese cheie, iar aceasta nu este o coincidență. Procesul de fabricație, sau așa cum este numit în mod adecvat în CMM, Standardul Proces de fabricație Organizațiile (OSS) este unul dintre conceptele centrale ale întregului model.

În noiembrie 1986, Institutul American de Inginerie Software (SEI), împreună cu Mitre Corporation, a început să dezvolte o Evaluare a Maturității Procesului de Dezvoltare a Software-ului, care a fost menită să ajute la îmbunătățirea proceselor interne.

Dezvoltarea acestei revizuiri 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 livrate semnificativ cu întârziere și peste buget. A fost necesar să se găsească o soluție la această problemă.

În septembrie 1987, SEI a lansat scurtă recenzie procese de dezvoltare software cu o descriere a nivelurilor de maturitate ale acestora, precum și un chestionar menit să identifice zonele din companie în care au fost necesare îmbunătățiri. Cu toate acestea, majoritatea companiilor au considerat acest chestionar ca pe un model gata făcut, în urma căruia, după 4 ani, chestionarul a fost transformat într-un model real, Modelul de Maturitate a Capabilității pentru Software (CMM). Prima versiune a CMM (Versiunea 1.0), lansată în 1991, a fost revizuită în 1992 de către participanții la ședința de lucru, la care au participat aproximativ 200 de specialiști în software și membri ai comunității dezvoltatorilor.

1. Elementar. Statutul cel mai primitiv al organizației. Organizația este capabilă să dezvolte software. Organizația nu are un proces explicit conștient, iar calitatea produsului este în întregime determinată de abilitățile individuale ale dezvoltatorilor. Unul ia inițiativa și echipa îi urmează instrucțiunile. Succesul unui proiect nu garantează succesul altuia. La finalul proiectului nu sunt înregistrate date privind costurile forței de muncă, programul și calitatea.
2. repetabil. Într-o oarecare măsură, procesul este monitorizat. Se înregistrează costurile cu forța de muncă și planurile. Funcționalitatea fiecărui proiect este descrisă în scris. La mijlocul anului 1999, doar 20% dintre organizații aveau nivelul 2 sau mai mare.
3. Instalat. Au un definit, documentat și proces stabilit munca independent de indivizi. Adică de acord standarde profesionale, iar dezvoltatorii le implementează. Astfel de organizații sunt capabile să prezică în mod destul de fiabil costurile proiectelor similare cu cele finalizate anterior.
4. Gestionate. Ei pot prezice cu exactitate timpul și costul muncii. Există o bază de date cu măsurători acumulate. Dar nu există schimbări odată cu apariția noilor tehnologii și paradigme.
5. Optimizat. Există o procedură continuă pentru găsirea și stăpânirea metodelor și instrumentelor noi și îmbunătățite.

Dezvoltare

Utilizarea modelului în practică a relevat ambiguitatea abordărilor pentru atingerea unor niveluri mai înalte de organizare a proceselor de dezvoltare software. Prin urmare, până în 2002, se dezvoltă recomandări pentru îmbunătățirea procesului de dezvoltare, care sunt numite CMMI (integrarea modelului de maturitate a capacității). În prezent ultima versiune CMMi - 1.3 (publicat noiembrie 2010) .

Vezi si

Legături

Forumul studenților MIT > Secțiunea principală > Teste > Simulare sisteme de control

Vedere versiunea completa: Simularea sistemelor de control

Am rezolvat toate modulele, am trecut totul cu 4, iar finalul cu 2, acum peste trei zile voi incerca sa trec din nou, nu a fost o singura intrebare identica. Am încercat să corectez testul final, dar verifică, nu pot garanta corectitudinea. Expun tot ce am, poate cineva o va trece mai bine decât mine. Dacă cineva are o a doua, a treia încercare, pune, dacă nu te superi, disciplina, într-adevăr foarte dificil.:eek:

Testul final 100 din 100

Rezultatul este diferit de fiecare dată?

Mai multe întrebări care nu sunt enumerate aici și m-au prins. Nu am căutat răspunsuri, pentru că fără el am trecut de 4. Cine vrea să fie confuz, încărcați aici răspunsurile pentru restul 🙂

Modulul 1:
Ce nu ar trebui să fie considerat un semn distinctiv al unui proces de afaceri?

Valoare adăugată

Alege un singur răspuns:
Un produs al unui proces care întruchipează obiectivele stabilite anterior

Alege un singur răspuns:

În finală (a trecut pe 4.

Ce este modelul de maturitate a capacității? (CMM)

Aceste întrebări + cele deja pe forum):
1. Alegeți afirmația corectă.
Alege un singur răspuns:
Procesul de afaceri al diviziilor constă din diverse lanțuri valorice (UNSURE)
Un proces de afaceri end-to-end constă din procese de afaceri diverse organizatii
Procesul de afaceri interfuncțional, de regulă, constă din procesele de afaceri ale departamentelor

2. Ce nu este un element al diagramei de flux universale a procesului de afaceri?
Alege unul sau mai multe răspunsuri:
Resurse de proces
Riscuri
Activitati de management al proceselor de afaceri
Factori de mediu
Activitate de conversie a intrărilor în ieșiri

3. Resurse materiale ca element de bază al proceselor sunt:
Alege un singur răspuns:
Subiecți activi de activitate uniți în sisteme care interacționează între ele și alte resurse
Acțiuni de control direcționate de subiecții de activitate asupra obiectelor de activitate, care determină scopurile și rezultatele proceselor
Facilități și activități pasive utilizate pentru a efectua procese (NU SIGUR)

28.03.2014, 10:07

Modulul 1:
Ce nu ar trebui să fie considerat un semn distinctiv al unui proces de afaceri? Alegeți unul sau mai multe răspunsuri:
Conversia intrărilor în ieșiri
Livrarea produsului către un consumator extern
Valoare adăugată
Formarea plusului și/sau a valorii de utilizare

Rezultatele ca elemente de bază ale proceselor sunt:
Alege un singur răspuns:
Subiecți activi de activitate uniți în sisteme care interacționează între ele și alte resurse
Un produs al unui proces care întruchipează obiective stabilite anterior Facilități și activități pasive utilizate pentru realizarea proceselor
Ansamblul de obiecte materiale, energetice și informaționale necesare pentru finalizarea procesului

Ce este feedback-ul în cadrul unui proces de afaceri?
Alege un singur răspuns:
Influență intenționată și conștientă asupra procesului, menită să asigure rezultatul dorit
Analiza si compararea rezultatelor procesului cu obiectivele stabilite anterior
Impactul asupra sistemului de obiecte și factori ai mediului, care sunt surse de diferite tipuri de abateri în funcționarea sistemului
asa am raspuns! dar tot a iesit 4

În final - Aceste întrebări + cele care există deja:
1 Selectați deficiențele structurilor design-țintă din listă.

2 Selectați exemple de utilizare a comenzilor din listă.
Căni de calitate
Comitete
Echipe de lucru

3 Selectați din listă condițiile de aplicare a structurilor organizatorice organice.
Lucrătorii sunt motivați de nevoi complexe
Obiectivele sunt neclare și se schimbă dinamic
Puterea este pusă la îndoială și testată, necesită confirmare din partea subordonaților

4 Selectați din listă beneficiile structurilor organizaționale bazate pe proiecte.
subordonarea directă a angajaților față de managerul de proiect și astfel se realizează lipsa de ambiguitate a direcției eforturilor acestor angajați

5 procese suport:
Furnizați implementare eficientă procesele principale

Nota finala 5
Intrebarea 1
Alegeți din lista de exemple de utilizare a comenzilor.

Căni de calitate
Comitete
Echipe de lucru

intrebarea 2
Pentru ce sunt folosiți intermediarii în cadrul structurii funcționale?

Să integreze activitățile diferitelor divizii structurale

Întrebarea 3
Numiți tipurile de relații din modelul SADT:
Control
mecanism de ieșire
Feedback de intrare

Întrebarea 4
Care dintre următoarele procese de afaceri este cel mai scurt?
Procesul de afaceri al diviziei

Întrebarea 5
Ce metode, metodologii și instrumente pot fi folosite pentru a crea modele de informații despre procesele de afaceri?

Metodologia Gein-Sarson
Limbajul de modelare al lui Chen și Barker

Întrebarea 6
Care reprezentare a procesului de afaceri corespunde celui mai scăzut nivel (dintre cele enumerate)?

Operațiuni de proces de afaceri

Întrebarea 7
Durata procesului de afaceri:

Este subiectivă

Întrebarea 8
Resursele materiale ca element de bază al proceselor sunt:

Mijloace și obiecte de activitate pasive utilizate pentru realizarea proceselor

Întrebarea 9
Selectați din listă beneficiile structurilor organizaționale bazate pe proiecte.

Se implementează subordonarea directă a angajaților față de managerul de proiect și astfel se realizează lipsa de ambiguitate a direcției eforturilor acestor angajați.

Întrebarea 10
Selectați din listă beneficiile structurilor organizaționale matrice.

Posibilitate de personalizare flexibilă structura organizationalaîntr-un spectru larg: de la matrice slabă la puternică

Întrebarea 11
Ce include a doua buclă a managementului sistemului de afaceri?

Subsistemul de control al operațiunii
subsistem de management al dezvoltării

Întrebarea 12
Modelul general de proces al unui sistem de afaceri include următoarele elemente:

Ieșire
proces
Intrare
Perturbare

Întrebarea 13
Ce standard IDEF vă permite să modelați activități, fluxuri și starea obiectelor?

Întrebarea 14
Care sunt puterile managerului de proiect într-o structură matriceală puternică?

Mediu spre ridicat

Întrebarea 15
Ce se poate atribui principalelor elemente ale proceselor investiționale și financiare?

Investitorii
Creditorii

Întrebarea 16
Selectați din listă deficiențele structurilor design-țintă.

Fabricabilitate redusă în zonele funcționale

Control Systems Modeling.rar (http://mti.prioz.ru/krfilesmanager.php?do=downloadfile&dlfileid=107)

Care este ordinea dominanței în diagramele SADT?
Răspuns: Cele mai dominante funcții sunt situate în colțul din stânga sus.

ajuta 3training cine o are pliz

Adăugat după 1 minut
Cer 3 training de la oricine are Modelare sisteme de control

vBulletin® v3.8.7, Copyright 2000-2018, vBulletin Solutions, Inc.

Traducere pe care o poți spune:

Metodologia de dezvoltare a SI. Model de maturitate CMM/CMMI.

În 1991, Institutul de Inginerie Software al Universității

Carnegie Mellon (Software Engineering Institute, SEI) a creat modelul de maturitate CMM (Capability Maturity Model) pentru dezvoltarea produselor software. De-a lungul timpului, a fost lansată o întreagă familie de modele:

SW-CMM - pentru produse software, SE-CMM - pentru ingineria sistemelor, Acquisition CMM - pentru achiziții, People CMM - pentru managementul resurselor umane, ICMM - pentru integrarea produselor.

O varietate de modele s-au dovedit a fi destul de dificil de înțeles și implementat. De când au fost creați grupuri diferite specialiști, conținutul acestor modele nu a fost întotdeauna în concordanță între ele, precum și cu

cerințele standardelor internaționale. Prin urmare, în 2002, SEI a publicat un nou model CMMI (Capability Maturity Model Integration), combinând modele lansate anterior și ținând cont de cerințele

standarde internaționale. CMMI este un set de modele (metodologii) pentru îmbunătățirea proceselor din organizații de diferite dimensiuni și activități. CMMI distinge următoarele grupuri de domenii de îmbunătățire: managementul proceselor, managementul proiectelor, domeniile de inginerie, servicii

zone. În acest caz, toate domeniile sunt specificate sub formă de cerințe care determină nu modul în care sunt implementate, ci cerințele de interfață. De aici rezultă două consecințe.

Consecința 1. CMMI permite diverse implementări și nu este o metodologie de dezvoltare software precum MSF, Scrum, RUP, etc. Aceasta din urmă poate fi folosită în implementarea sa. De exemplu, există un șablon de proces special în VSTS pentru CMMI numit MSF pentru CMMI.

Corolarul 2. CMMI este folosit pentru a certifica companiile pentru maturitatea proceselor lor. Inițial, la sfârșitul anilor 80 și începutul anilor 90, CMM (atunci nu încă CMMI) a fost creat tocmai ca mijloc de certificare

subcontractanții federali. Și abia mai târziu, după ce s-a răspândit în lume, a început să fie folosit și apoi sa concentrat pe îmbunătățirea proceselor. Mai notăm unul caracteristică importantă CMMI. Este destinat nu numai dezvoltării de sisteme software. Mulți companii mari nu produc software, ci produse țintă, în care software-ul este inclus ca parte integrantă.

De exemplu, aviație, industria aerospațială. Adică dezvoltarea de software

are loc împreună cu lucrări de inginerie de alte tipuri. Și se întâmplă adesea ca într-un proiect să fie implicate mai mult de două tipuri diferite de inginerie. Sarcina CMMI este de a oferi astfel de proiecte și companii o singură platformă pentru organizarea procesului de dezvoltare.

Spre deosebire de modelul CMM clasic, care era strict ierarhic și permitea doar îmbunătățirea secvențială a proceselor pe nivele, modelul CMMI are două dimensiuni - secvenţial, cum ar fi

la fel ca în CMM, și continuă, permițând îmbunătățirea proceselor din organizație într-o oarecare măsură într-o manieră arbitrară. Aici ne vom concentra asupra model secvenţial. Are 5 niveluri

maturitatea procesului (fig. 1).

Primul nivel(nivelul de maturitate 1) este nivelul la care, prin definiție, se află orice companie. La acest nivel, dezvoltarea software-ului este mai mult sau mai puțin haotică.

Nivel administrat(nivel de maturitate 2) - politicile și procedurile de organizare a proceselor aprobate la nivel de companie apar deja aici. Dar întreaga amploare a proceselor există doar în cadrul proiectelor individuale.

Un anumit nivel(nivel de maturitate 3) - aici apare un proces standard la nivelul intregii companii in ansamblu.

Ce este Capability Maturity Model (CMM)? Ce sunt nivelurile CMM?

Acesta este un set mare și în continuă creștere de active de proces: șabloane de documente,

Modele de ciclu de viață, instrumente software, practici etc. Orice proces specific se obține prin tăierea din acest standard.

Nivel cantitativ(nivelul de maturitate 4) presupune apariția unui sistem de măsurători în companie, care au loc pe baza unui proces standard și permit managementul cantitativ al dezvoltării.

Nivel de optimizare(nivelul de maturitate 5) implică îmbunătățirea continuă a proceselor de dezvoltare, atât incrementale, incrementale, cât și revoluționare. În același timp, aceste schimbări nu sunt forțate, ci probleme și dificultăți proactive. Procesul este îmbunătățit de la sine și în mod constant au fost implementate mecanisme adecvate.

Mulți cunosc abrevierea CMMI, mulți știu că acesta este un model, adică. un set de recomandări cu privire la modul de îmbunătățire a proceselor legate, de exemplu, de dezvoltarea de software. Dar puțini oameni știu că există mai multe modele CMMI. Cel mai faimos dintre ele este CMMI for Development (CMMI-DEV), care este într-adevăr conectat în multe privințe cu activitățile companiilor de dezvoltare (adică acele companii și organizații care dezvoltă și furnizează un anumit produs software sau alt software și hardware complex). soluţie).

Dar cum rămâne cu cei care livrează nu un produs, ci servicii (de exemplu, suport pentru produse cu o pondere nesemnificativă a dezvoltării în costurile totale cu forța de muncă sau fără costuri cu forța de muncă)? Pentru ei există și un set de recomandări – modelul CMMI pentru Servicii (CMMI-SVC). Pentru departamentele IT, de exemplu, acest model (mai precis, recomandările sale) poate ajuta la înțelegerea a ceea ce trebuie făcut, astfel încât, de exemplu, aceleași recomandări ITIL să devină un proces normal, și nu un fel de „practică sacră”.

Modelul de maturitate a capacității (CMM)

Este curios că recomandările acestui model sunt destul de universale și nu se „închid” doar pe Tehnologia de informație. Introducerea pilot a practicilor acestui model a avut loc... într-unul dintre spitalele din Statele Unite (la urma urmei, îngrijirea medicală este tot un serviciu).

Cu toate acestea, oricare dintre modelele enumerate este mai bine de învățat. Iar dacă sunt câteva sute de oameni instruiți în modelul CMMI-DEV pentru întregul CSI (aproximativ 250-300 de persoane), atunci sunt doar 6 oameni instruiți în modelul CMMI-SVC în CSI. Vorbim de cei instruiți, nu de instructori. Tocmai aceasta a fost problema principală până în decembrie 2011: pentru CMMI-DEV, în întreaga lume a existat un singur instructor vorbitor de limbă rusă certificat de SEI (dezvoltator de modele CMMI), iar pentru alte modele nu a existat deloc! Acum a apărut și un astfel de instructor după modelul CMMI-SVC (de unde primii 6 instruiți). Acest instructor este autorul acestei publicații, care este disponibil să răspundă la orice întrebări despre modelele menționate și despre pregătirea formală. Cere!

Acest material este o înregistrare privată a unui membru al comunității Club.CNews.
Editorii CNews nu sunt responsabili pentru conținutul acestuia.

Vom lua în considerare evoluția modelelor de asigurare a calității pe baza „modelului de maturitate a procesului” sau „modelului de îmbunătățire a capacității” CMM (Capability Maturity Model). Chiar dacă modelul SMM are ca scop asigurarea calitatii software-ului, aspectele metodologice ale acestuia sunt aplicabile modelelor de asigurare a calitatii oricarui produs (bunuri, lucrari, servicii).

Principalul în model SMM este conceptul de maturitate organizaţională.

imatur este considerată o organizație în care procesul de dezvoltare software depinde doar de performeri și manageri specifici, iar deciziile sunt adesea luate „din mers”. În acest caz, există o probabilitate mare de depășire a bugetului sau eșec în livrarea proiectului și, prin urmare, managerii sunt nevoiți să se ocupe doar de rezolvarea problemelor imediate.

Matur Se consideră că o organizație îndeplinește următoarele condiții:

• – există proceduri bine definite pentru crearea de produse software și managementul proiectelor, care sunt rafinate și îmbunătățite în proiecte pilot prin analiza componentelor „cost – profit”;
• – estimările privind timpul și costul executării lucrării se bazează pe experiența acumulată și, prin urmare, sunt destul de precise;
• – firma dispune de standarde pentru procesele de dezvoltare, testare si implementare a software-ului, reguli de proiectare a codului final de program, componente, interfete etc. Toate acestea constituie infrastructura şi cultură corporatistă care sprijină procesul de dezvoltare software.

Deci standardul SMM este un model de asigurare a calității care constă în criterii de evaluare a maturității unei organizații și rețete pentru îmbunătățirea proceselor existente. În model SMM sunt definite cinci niveluri de maturitate ale organizațiilor, ale căror caracteristici sunt prezentate în fig. 5.3.

Orez. 5.3. Cinci niveluri de maturitate a modeluluiSMM

Primul nivel (nivel inițial) stă la baza dezvoltării întreprinderii la următoarele niveluri. Se crede că la nivelul întreprinderii entry-level a organizației nu există condiții stabile pentru crearea de software de înaltă calitate. În consecință, rezultatul oricărui proiect depinde în totalitate de calitățile personale ale managerului și de experiența programatorilor. Aceasta înseamnă că succesul într-un singur proiect poate fi repetat doar dacă aceiași manageri și programatori sunt alocați următorului proiect. Dacă totuși, managerii sau programatorii care au acumulat experiență în proiecte părăsesc întreprinderea, atunci calitatea software-ului produs scade brusc odată cu plecarea lor.

Trebuie recunoscut că la nivel inițial, în situații stresante, o mare dependență de factorul uman procesul de dezvoltare se reduce la scrierea codului și la testarea minimă a acestuia.

Realizarea celui de-al doilea nivel repetabil (nivel repetabil) este determinată de implementarea tehnologiei de management de proiect la întreprindere. Planificarea și managementul proiectelor în întreprindere se bazează pe experiența acumulată, există și sunt utilizate standarde pentru software-ul dezvoltat, a căror conformitate este controlată de un grup special de asigurare a calității. Se crede că al doilea nivel poate oferi atât oportunități de îmbunătățire ulterioară (tranziție la al treilea nivel), și nu exclude posibilitatea unei reveniri regresive a calității procesului de dezvoltare software la nivelul inițial în condiții critice.

Al treilea, un anumit nivel (definit stânga) caracterizat prin faptul că procesul standard de creare și întreținere a software-ului este pe deplin documentat, de la dezvoltarea software până la managementul proiectelor. Ipoteza introducerii acestui nivel este că în procesul de standardizare, întreprinderea trece la cele mai eficiente practici și tehnologii. Pentru a crea și menține funcționarea standardelor de dezvoltare software și management de proiect într-o organizație, ar trebui creat un grup special. O condiție prealabilă pentru atingerea celui de-al treilea nivel este prezența în întreprindere a unui program de dezvoltare profesională continuă și formare a angajaților. Se crede că pornind de la acest nivel, organizația încetează să mai depindă de calitățile anumitor dezvoltatori și nu tinde să coboare la un nivel inferior în situații stresante.

Pe a patra, nivel gestionat (nivel gestionat)întreprinderea stabileşte indicatori cantitativi de calitate – atât pentru produsele software cât şi pentru procesele de creare a acestora în general. Astfel, se realizează un management mai bun al proiectului prin reducerea abaterilor diferiților indicatori de proiect. În același timp, variațiile semnificative (de semnal) ale proceselor de dezvoltare software implementate și variațiile aleatorii (zgomote) ale procesului sunt separate.

A cincea (cel mai mare), nivel de optimizare (nivel de optimizare) caracterizat prin faptul că măsurile de îmbunătățire sunt aplicate nu numai proceselor existente, ci și pentru a evalua eficacitatea introducerii de noi tehnologii. Sarcina principală a întreprinderii la acest nivel este îmbunătățirea continuă a proceselor existente. În același timp, îmbunătățirea procesului ar trebui să contribuie la prevenire posibile erori si defecte. În același timp, ar trebui să se lucreze pentru a reduce costul dezvoltării software.

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

Modelul de maturitate a capacității CM-CEI este un model organizațional care descrie cele 5 etape (nivele) evolutive la care sunt gestionate procesele dintr-o organizație.

Creat inițial pentru dezvoltarea de software, scopul modelului de maturitate a capacității este că o organizație ar trebui să fie capabilă să accepte și să-și susțină aplicațiile software. Modelul sugerează, de asemenea, pași și inițiative concrete pentru a 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, puține dintre ele sunt definite) Repetabil (procesele de bază sunt stabilite și există disciplină pentru a respecta acele procese) Definit (toate procesele sunt definite, documentate), unificat și integrat) Gestionat ( procesele sunt măsurate prin agregarea datelor detaliate despre procese și calitatea acestora) Optimizare (dezvoltarea continuă a procesului prin feedback cantitativ și testarea de noi idei și tehnologii)

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 de software și vânzări să îmbunătățească sofisticarea proceselor lor software într-un mod evolutiv. Pornind de la procese ad-hoc, haotice, trecând la procese software mature și disciplinate. Accentul este pus pe identificarea domeniilor cheie de proces și a practicilor exemplare care pot constitui procese software disciplinate. Conceptul de maturitate CMM creează un context în care:

Practicile pot fi repetate. Dacă nu repetați o operațiune, atunci nu ar trebui să o îmbunătățiți. Există reguli, proceduri și practici care obligă o organizație să implementeze și să execute consecvent. Cele mai bune practici pentru organizarea muncii de producție pot fi partajate rapid între grupuri. Practicile sunt definite pentru a permite schimbul între proiecte, oferind astfel o anumită standardizare pentru organizație. Abaterile în executarea acestor metode sunt minimizate. Obiectivele cantitative sunt stabilite pentru sarcini; 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 de software, ci și pentru descrierea nivelurilor evolutive ale organizațiilor în general și descrierea nivelului de management pe care o organizație l-a implementat sau dorește să-l atingă.

Structura modelului de dezvoltare a caracteristicilor

Nivelurile de maturitate sunt un concept stratificat care oferă consistența disciplinei care este necesară pentru a obține o îmbunătățire continuă. Este important de menționat că o organizație își dezvoltă capacitatea de a evalua consecințele unei noi practici, tehnologie sau instrument. Prin urmare, nu este o chestiune de acceptare a acestor inovații, ci mai degrabă de modul în care aceste eforturi inovatoare afectează practicile existente. Sprijină proiecte, grupuri și organizații, oferindu-le o bază 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-un mod eficient și sigur. Măsura în care obiectivele sunt îndeplinite indică ce fel de capacitate a stabilit organizația la acel nivel de excelență. Obiectivele delimitează domeniul de aplicare, limitele și scopul fiecărei zone cheie de proces. Caracteristici generale - Caracteristicile generale includ practici care implementează și instituționalizează domenii cheie de proces. Aceste 5 tipuri caracteristici generale includ: angajamentul de a performa, capacitatea de a performa, inițiativele de realizat, măsurarea și analiza și controlul implementării. Practici cheie - Practicile cheie descriu elementele și practicile de infrastructură care contribuie cel mai eficient la implementarea și instituționalizarea domeniilor cheie de proces.

Criterii pentru definirea unui proces

Criteriile pentru definirea unui proces sunt un set de elemente de proces care trebuie incluse într-o descriere a procesului software pentru ca oamenii să le folosească în practică. Pentru a seta criteriile, trebuie să puneți întrebarea - „Despre ce informații proces software necesare pentru documentare?