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ă intern produse software cu ei 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 siguranță, care vizează reducerea costului total al resurselor pentru proiectare, implementare și întreținere. instrumente 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 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 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;
• 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 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ă managementul de bază al proiectului:
  • 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:

• să stabilească starea propriilor 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. Acesta 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; etapele de determinare a 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 standardISO, ș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 funcționare 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]$

Calitatea produselor software este poate una dintre cele mai grave probleme din industria software. Calitatea este mult mai mult decât lipsa erorilor. Implică un set de caracteristici diferite: fiabilitate, hackabilitate, adaptabilitate, compatibilitate, menținere, portabilitate, eficiență etc.Nu este de mirare că există o asemenea varietate de standarde de calitate în industria software.

Calitatea era ușor de măsurat: ori am fost plătiți, ori nu.
Dean Leffingwell, Don Widrig.
Managementul cerințelor software

CMM/CMMI

Poate cel mai faimos standard de calitate ar trebui considerat Modelul de maturitate a capacității (CMM) - un model de evaluare a nivelului de maturitate al proceselor de dezvoltare împreună cu derivatele sale. A fost creat de SEI (Software Engineering Institute), care este finanțat de Departamentul de Apărare al SUA și este o unitate structurală a Universității Carnegie Mellon. Primul versiunea oficială standardul a fost publicat în 1993, deși lucrările la el au început mult mai devreme - principalele sale prevederi au fost publicate încă din 1986.

Succesul CMM a fost predeterminat de mai mulți factori. Acest standard a fost unul dintre primele, ținând cont inițial de specificul dezvoltării software. S-a dovedit a fi destul de simplu și transparent atât pentru înțelegere, cât și pentru utilizare, și a reglementat „ce”, și nu „cum” să facă, și, prin urmare, a fost potrivit pentru diverse metodologii de dezvoltare și nu a impus nicio restricție privind standardele de documentare, instrumente, mediul și limbile folosite în proiecte. Și, poate, principalul factor care a predeterminat popularitatea CMM a fost cooperarea SEI cu Departamentul de Apărare al SUA, ceea ce a însemnat de facto utilizarea standardului în implementarea proiectelor comandate de acest departament.

Modelul CMM (Tabelul 1) prevede cinci niveluri de maturitate, fiecare dintre acestea corespunzând anumitor domenii cheie de proces (Key Process Areas, KPA).

Tabelul 1. Straturi model CMM

număr de nivel	Numele nivelului	Domenii cheie de proces
1	Elementar	Dacă organizația se află la acest nivel, atunci nu există zone cheie de proces pentru aceasta
2	recurente	Managementul configurației software Asigurarea calității produselor software Managementul contractelor cu contractant Monitorizarea progresului proiectului Planificarea proiectelor software Managementul cerințelor.
3	Hotărât	Evaluări experți.Coordonarea interacțiunilor dintre echipele de proiect.Ingineria produsului software.Managementul cuprinzător al software-ului.Program de formare a personalului.Definirea procesului organizațional.Sfera de aplicare a procesului organizațional.
4	Gestionate	Managementul calitatii software.Managementul proceselor bazat pe metode cantitative
5	Optimizabil	Managementul schimbării proceselor.Managementul schimbărilor tehnologice.Prevenirea defectelor

Împărțirea pe nivele și definirea KPA pentru fiecare dintre acestea permite implementarea consecventă a CMM, folosind standardul ca ghid, care poate asigura îmbunătățirea continuă a procesului de dezvoltare.

Standardul CMM s-a dovedit a fi de mare succes, iar ulterior a fost creată o serie întreagă de standarde pe baza acestuia (Tabelul 2). Mai mult, a primit un nou nume - SW-CMM (Capability Maturity Model for Software), care reflectă mai exact poziția sa într-o familie destul de mare de standarde.

Tabelul 2. Dezvoltarea standardelor CMM

Denumirea standardului	Descriere
CMM de inginerie de sistem (SE-CMM)	Se concentrează pe probleme de inginerie de sistem - dezvoltarea produsului (analiza cerințelor, proiectarea și integrarea sistemelor de produse) și producția acestora (planificarea și operarea liniei de producție)
CMM de încredere (T-CMM)	Proiectat pentru a servi sisteme software sensibile și închise care necesită asigurare software de înaltă calitate
Inginerie de securitate a sistemului CMM (SSE-CMM)	Se concentrează pe aspectele de securitate ale ingineriei software, asigură un proces de dezvoltare securizat, inclusiv securitatea membrilor echipei de creație
Oameni CMM (P-CMM)	Ia în considerare problemele de dezvoltare a personalului în organizațiile de software
CMM pentru achiziție software (SA-CMM)	Acoperă achiziția de produse software de la organizații externe
Dezvoltare integrată de produse CMM (IPD-CMM)	Servește ca mediu pentru integrarea eforturilor de dezvoltare în toate etapele ciclului de viață și din fiecare departament din cadrul companiei

Cu toate acestea, aplicarea practică a standardelor din seria CMM a arătat că acestea nu oferă succes necondiționat în dezvoltarea de software. Aceste standarde nu erau bine coordonate între ele - implementarea simultană a diferitelor modificări ale CMM ar putea fi o provocare și i-a derutat pe specialiștii organizațiilor care s-au confruntat cu aceasta.

De asemenea, o problemă semnificativă a CMM este necesitatea „alinierii” tuturor proceselor. Dacă o organizație încearcă să certifice la un anumit nivel, atunci trebuie să se asigure că nivelul corespunzător este aplicat tuturor proceselor sale. Chiar dacă specificul, metodologia sau caracteristicile de dezvoltare nu au anumite procese de efectuat, certificarea impune acest lucru.

O altă problemă este cauzată de poziția pe care standardele CMM au luat-o în industria software-ului modern. Întrucât o organizație cu un nivel înalt în conformitate cu CMM trebuie să ofere performanțe mai mari ale produselor software decât cele certificate la niveluri inferioare, standardul a ajuns să fie folosit ca criteriu de selecție pentru participarea la licitații pentru proiecte de dezvoltare software sau de externalizare. Cererea de organizații certificate a dat naștere unei propuneri de „certificare rapidă și nedureroasă”.

Această situație a devenit posibilă datorită deficiențelor procesului de certificare. Nu întreaga organizație în ansamblu este supusă certificării, ci doar un anumit proiect. Nimic nu împiedică o organizație să creeze un proiect „demonstrativ” care să îndeplinească toate cerințele nivelurilor înalte ale standardului CMM, să obțină nivelul corespunzător de certificare și să declare că toate produsele îndeplinesc un astfel de nivel al standardului.

Rezolvați majoritatea problemelor CMM este proiectat nou standard SEI - Capability Maturity Model Integrated (CMMI) - Un model integrat pentru evaluarea nivelului de maturitate al proceselor de dezvoltare. Standardul CMMI a fost creat inițial astfel încât să combine opțiunile CMM existente și să elimine orice contradicții în aplicarea sa practică în diverse domenii de activitate ale companiilor de înaltă tehnologie.

Pentru a elimina nevoia de „aliniere” a proceselor organizației și de a fi mai adaptat la nevoile sale de business, și nu invers, standardul CMMI are două forme de prezentare - cea clasică, multinivel, corespunzătoare CMM, iar noul, continuu. Forma continuă de prezentare nu ia în considerare nivelurile de maturitate (Maturity Levels), ci nivelurile de capacitate, care sunt evaluate pentru zonele de proces individuale (Process Areas, PA). În tabel. 3 oferă o mapare a nivelurilor de maturitate ale standardului CMM, precum și nivelurile de maturitate ale prezentării CMMI stratificate și nivelurile de capacitate ale prezentării continue CMMI.

SEI se îndepărtează de CMM și promovează activ CMMI în schimb, promițând să întărească controlul asupra procesului de certificare, introducând noi clase pentru a reduce costurile și a-l face mai atractiv pentru organizațiile mai mici; asigurarea compatibilităţii cu standardele ISO. Cu toate acestea, adevărul rămâne: în condițiile moderne, prezența unui certificat de un anumit nivel de CMM / CMMI nu este un factor atât de semnificativ ca acum câțiva ani și este acceptată fără întrebări suplimentare, cu excepția, poate, în proiectele realizate de ordin guvernamental.

Adnotare: Gama de idei care stau la baza probabil cea mai cunoscută metodologie pentru îmbunătățirea proceselor de dezvoltare software, CMM, este studiată în detaliu. 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, iar rezultatul a fost Model 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 feedback cantitativ din proces și prin implementarea de idei și tehnologii 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 într-o manieră eficientă, deși poate în mod 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.

Organizațiile care lucrează în domeniul dezvoltării, livrării, implementării și întreținerii software-ului și integrării sistemelor simt din ce în ce mai mult că competitivitatea lor se bazează pe calitate și costuri reduse, fabricabilitate.

Liderii unor astfel de organizații nu sunt întotdeauna capabili să-și formeze o strategie de îmbunătățire și dezvoltare a tehnologiei activităților companiei lor; în mod clar nu există destui specialişti pe piaţa muncii cu calificările necesare. În același timp, experiența internațională în domeniul îmbunătățirii proceselor tehnologice de dezvoltare și operare a software-ului nu a fost suficient de generalizată și oficializată de mulți ani. Abia la începutul anilor 1990, Institutul American de Inginerie Software (SEI) a format un model de maturitate tehnologică a organizațiilor CMM (Capability Maturity Model), determinând nivelurile de maturitate tehnologică și a acestora. trăsături distinctive. Pe parcursul unui deceniu, CMM a fost testat într-un număr de organizații, eficacitatea și fiabilitatea sa au fost verificate prin organizații de comandă, furnizori de software, companii de dezvoltare de software personalizat și programare offshore.

Astăzi, în vest, o companie de dezvoltare întâmpină practic mari dificultăți în obținerea comenzilor dacă nu este certificată de către SMM. Clienții cer garanții privind fabricabilitatea antreprenorului, garanții că antreprenorul nu poate oferi un serviciu de calitate scăzută.

Evaluarea maturității tehnologice a companiilor poate fi utilizată:

clientul atunci când selectează cei mai buni performanți (de exemplu, într-o licitație);

· companiile de software să evalueze sistematic starea proceselor lor tehnologice și să selecteze domenii pentru îmbunătățirea acestora;

· companiile care decid să treacă printr-o atestare pentru a evalua „dimensiunea dezastrului”, i.e. starea ta actuală;

auditorii să determine procedura standard de certificare și să efectueze evaluările necesare;

· firme de consultanta implicate în restructurarea companiilor și furnizorilor de servicii de tehnologia informației și servicii conexe.

Pe măsură ce maturitatea tehnologică a unei organizații crește, procesele de creare și întreținere a software-ului devin mai standardizate și mai consistente. În același timp, formalizarea proceselor face posibilă standardizarea rezultatelor așteptate ale implementării acestora și asigurarea predictibilității rezultatelor implementării proiectului.

Maturitatea procesului (maturitatea procesului software)- acesta este gradul de manevrabilitate, controlabilitate și eficacitate a acestora. Creșterea maturității tehnologice se referă la potențialul de creștere a rezistenței procesului și indică gradul de eficiență și coerență în utilizarea proceselor de dezvoltare și întreținere a software-ului în întreaga organizație. Utilizarea reală a proceselor este imposibilă fără documentarea și aducerea lor în atenția personalului organizației, fără monitorizarea și îmbunătățirea constantă a implementării acestora. Capacitățile proceselor bine concepute sunt complet definite. Creșterea maturității tehnologice a proceselor înseamnă că eficiența și calitatea rezultatelor implementării lor pot crește constant.

În organizațiile care au atins maturitatea tehnologică, procesele de creare și întreținere a software-ului iau statutul de standard, sunt fixate în structurile organizaționale și determină tacticile și strategia de producție. Introducerea lor în statutul de lege presupune necesitatea construirii infrastructurii necesare și crearea celei necesare cultură corporatistă industrii care mențin metodele, operațiunile și procedurile adecvate pentru a face afaceri, chiar și după ce cei care au creat totul părăsesc organizația.

Modelul CMM dezvoltă prevederile privind sistemul calității organizației, formând criteriile de perfecționare a acestuia - cinci niveluri de maturitate tehnologică, care, în principiu, pot fi atinse de către organizația de dezvoltare. Cel mai înalt - al patrulea și al cincilea nivel - este de fapt o caracteristică a organizațiilor care au stăpânit metodele de dezvoltare colectivă, în care procesele de creare și întreținere a software-ului sunt complet automatizate și susținute tehnologic.

Din 1990, SEI, cu sprijinul agențiilor guvernamentale americane și al organizațiilor de dezvoltare software, a dezvoltat și îmbunătățit constant acest model, ținând cont de toate cele mai recente realizări în domeniul creării și întreținerii software.

SMM este un material metodologic care definește regulile de formare a unui sistem de management pentru crearea și întreținerea de software și metode pentru îmbunătățirea treptată și continuă a culturii de producție. Scopul SMM este de a oferi organizațiilor de dezvoltatori instructiunile necesare asupra alegerii unei strategii de imbunatatire a calitatii proceselor prin analiza gradului de maturitate tehnologica a acestora si a factorilor care afecteaza cel mai mult calitatea produselor. Concentrându-se pe un număr mic dintre cele mai critice operațiuni și îmbunătățind sistematic eficiența și calitatea executării acestora, o organizație poate astfel obține o îmbunătățire continuă constantă a culturii de creare și întreținere a software-ului.

CMM este un model descriptiv în sensul că descrie atributele esențiale (sau cheie) care determină la ce nivel de maturitate tehnologică se află o organizație. Este un model normativ în sensul că o descriere detaliată a metodologiilor stabilește nivelul de organizare necesar pentru realizarea proiectelor de complexitate și durată variată în cadrul contractelor cu agențiile guvernamentale SUA. CMM nu este o prescripție, nu prescrie cum ar trebui să se dezvolte o organizație. CMM descrie caracteristicile organizației pentru fiecare nivel de maturitate tehnologică, fără a oferi instrucțiuni cu privire la modul de trecere de la un nivel la altul. O organizație poate dura câțiva ani pentru a trece de la primul la al doilea nivel și foarte puțin timp pentru a trece de la un nivel la altul. Procesul de îmbunătățire a tehnologiei de dezvoltare software se reflectă în planurile strategice ale organizației, structura acesteia, tehnologiile utilizate, cultura socială generală și sistemul de management.

La fiecare nivel se stabilesc cerințe în baza cărora se realizează stabilizarea celor mai semnificativi indicatori ai proceselor. Atingerea fiecărui nivel de maturitate tehnologică este rezultatul apariției unui anumit număr de componente în procesele de dezvoltare software, ceea ce duce la rândul său la creșterea productivității și calității acestora. Pe fig. Figura 1.7 prezintă cinci niveluri de maturitate tehnologică CMM.

Orez. 1.7. Cinci niveluri de maturitate tehnologică SMM

Inscripțiile de pe săgeți definesc caracteristicile proceselor de îmbunătățire la trecerea de la un nivel la altul.

Nivelurile de la al doilea până la al cincilea pot fi caracterizate prin operațiuni care vizează standardizarea și (sau) modernizarea proceselor de creare a software-ului și prin operațiunile care alcătuiesc procesele de creare a acestuia în sine. În același timp, primul nivel este, parcă, o bază, un fundament pentru o analiză comparativă a nivelurilor superioare.

La nivelul 1 (inițial), procesele de bază de creare și întreținere a software-ului sunt aleatorii și haotice. Succesul proiectului depinde în totalitate de eforturile individuale ale personalului. La acest nivel, de regulă, organizația nu are un mediu stabil necesar pentru crearea și întreținerea software-ului.

Succesul proiectului în acest caz, de regulă, depinde în întregime de gradul de energie și experiență a managementului și nivel profesional interpreți. Se poate întâmpla ca un lider energic să depășească toate obstacolele din procesul de proiect și să realizeze lansarea unui produs software cu adevărat viabil. Dar după ce un astfel de lider își părăsește postul, nu există nicio garanție că următorul astfel de proiect va avea succes. În absența nivelului necesar de management al proiectelor, nici măcar tehnologia avansată nu va putea salva situația.

Procesele de la primul nivel se caracterizează prin imprevizibilitatea lor datorită faptului că componența, scopul și succesiunea lor în procesul de implementare a proiectului se modifică aleatoriu în funcție de situația actuală. Ca urmare, fondurile alocate sunt cheltuite în exces și programul de lucru este perturbat. Formarea unor persoane capabile și informate în organizații este o condiție prealabilă de bază pentru succes la toate nivelurile de maturitate, dar la primul nivel este singura modalitate de a obține rezultate pozitive.

La nivelul 2 (nivelul proceselor repetabile), procesele de management de proiect asigură controlul continuu al costului proiectului, al programului și al funcțiilor efectuate. Disciplina proiectului este de așa natură încât este posibil să se prezică succesul proiectelor pentru a crea produse software similare.

La acest nivel, planificarea munca de proiectare iar managementul proiectelor noi se bazează pe experiența unor proiecte similare finalizate cu succes. Caracteristica principală a celui de-al doilea nivel este prezența unor procese de management de proiect eficiente formalizate și documentate, care permite utilizarea experienței pozitive a proiectelor finalizate cu succes. Procesele eficiente sunt cele care sunt documentate, utilizate efectiv, măsurabile și care pot fi actualizate. Este esențial ca personalul să fie instruit în utilizarea lor.

Fiecare nivel al CMM, începând cu al doilea, este caracterizat de prezența unui număr de așa-numite grupuri de procese cheie (KPA). Modelul HMM conține 18 astfel de grupuri, ultima versiune Modele CMMI - 20 de grupuri. Nivelul 2 CMM se caracterizează prin prezența următoarelor procese în organizație (numele lor corespund CMMI):

managementul cerințelor;

managementul configurației;

Planificarea proiectului;

monitorizarea si controlul proiectului;

managementul contractelor;

măsurare și analiză;

asigurarea calitatii procesului si produsului.

Procesele de la al doilea nivel pot fi caracterizate ca ordonate datorită faptului că sunt planificate în avans și implementarea lor este strict controlată, datorită căruia se realizează predictibilitatea rezultatelor proiectului. Odată cu creșterea și complexitatea proiectelor, atenția se mută de la aspectele tehnice ale implementării acestora la aspectele organizatorice și manageriale. Executarea proceselor necesită ca oamenii să lucreze mai eficient și mai coerent, ceea ce, la rândul său, necesită studiul celor mai bune practici documentate pentru a îmbunătăți excelența profesională.

La nivelul 3 (nivelul proceselor standardizate), procesele de dezvoltare software sunt documentate, standardizate și reprezintă un singur sistem tehnologic care este obligatoriu pentru toate departamentele organizației. Toate proiectele folosesc o singură tehnologie pentru crearea și întreținerea software-ului care a fost testat, aprobat și ridicat la statutul de standard.

La acest nivel, la procesele de nivelul 2 se adaugă următoarele procese:

specificatiile necesare;

integrarea produsului;

verificare;

certificare;

standardizarea proceselor organizatorice;

· educație;

management integrat de proiect;

· Managementul riscurilor;

Analiza si luarea deciziilor.

Principalul criteriu de utilizare și, dacă este necesar, de ajustare a proceselor la acest nivel este acela de a ajuta managementul și specialiștii tehnici în îmbunătățirea eficienței implementării proiectelor. La acest nivel se creează un grup special în organizația responsabilă de alcătuirea operațiunilor care alcătuiesc procesele - grupul de procese de inginerie software (SEPG).

Pe baza unei singure tehnologii pentru fiecare proiect, se pot dezvolta propriile procese, ținând cont de caracteristicile acestuia. Astfel de procese în CMM sunt numite „procese de dezvoltare software orientate pe proiect” (procesul software definit de proiect).

Descrierea fiecărui proces include condițiile de execuție, datele de intrare, standardele și procedurile de execuție, mecanismele de verificare (de exemplu, evaluări inter pares), datele de ieșire și condițiile de terminare. Descrierea procesului include, de asemenea, informații despre instrumentele necesare pentru a-l finaliza și o indicație a rolului responsabil pentru executarea acestuia.

Scopul principal al nivelului 4 (nivelul proceselor gestionate) este controlul curent asupra proceselor. Conducerea trebuie să se asigure că procesele sunt efectuate cu calitatea specificată. Pot exista pierderi inevitabile și vârfuri temporare ale rezultatelor măsurate care necesită intervenție, dar în general sistemul trebuie să fie stabil.

La nivelul 4, se adaugă următoarele procese:

managementul performanței și productivității;

Management cantitativ de proiect.

La acest nivel, se aplică în practică o evaluare detaliată a calității atât a proceselor de creație, cât și a produsului software în sine. În acest caz, se aplică criterii de evaluare cantitativă.

În cadrul întregii organizații se dezvoltă un singur program de control cantitativ al productivității creării software-ului și al calității acestuia. Pentru a facilita analiza proceselor, este creată o bază de date unică de procese pentru crearea și întreținerea software-ului pentru toate proiectele derulate în organizație. Se dezvoltă metode universale cuantificare productivitatea proceselor și calitatea implementării acestora. Acest lucru permite efectuarea analiza cantitativași evaluarea proceselor de creare și întreținere a software-ului.

Rezultatele proceselor de la al patrulea nivel devin previzibile, deoarece sunt măsurabile și variază în cadrul restricțiilor cantitative date. La acest nivel, devine posibilă planificarea în avans a calității specificate a proceselor și a produselor finale.

Scopul principal al nivelului 5 (nivelul proceselor optimizate) este îmbunătățirea și modernizarea consecventă a proceselor de creare și întreținere a software-ului. În scopul modernizării planificate a tehnologiei de dezvoltare software, în organizație este creată o unitate specială, ale cărei principale responsabilități sunt colectarea de date privind implementarea proceselor, analiza acestora, modernizarea proceselor existente și crearea de noi procese. , verificarea lor pentru proiecte pilotși acordându-le statutul de standarde ale întreprinderii.

La nivelul 5, se adaugă următoarele procese:

introducerea de inovații tehnologice și organizaționale;

analiza cauza-efect si rezolvarea problemelor. Procesele de creare și întreținere a software-ului se caracterizează prin

îmbunătățite în mod constant, pe măsură ce organizația face eforturi continue pentru a le moderniza. Această îmbunătățire se extinde atât la identificarea capacităților suplimentare ale proceselor utilizate, cât și la crearea de noi procese optime și utilizarea noilor tehnologii.

Inovațiile care pot aduce cele mai mari beneficii sunt standardizate și adaptate în sistemul tehnologic din întreaga organizație. Personalul implicat în implementarea proiectului analizează defectele și identifică cauzele apariției acestora. Procesele de dezvoltare software sunt evaluate pentru a preveni reapariția situațiilor care duc la defecte, iar rezultatele evaluării sunt luate în considerare în proiectele ulterioare.

Fiecare nivel ulterior oferă în plus o vizibilitate mai completă a proceselor de creare și întreținere a software-ului.

La primul nivel, procesele sunt amorfe („cutii negre”), iar vizibilitatea lor este foarte limitată. De la bun început, compoziția și scopul operațiunilor nu sunt practic definite, ceea ce creează dificultăți semnificative în determinarea stării proiectului și a progresului acestuia. Cerințele pentru execuția proceselor sunt stabilite în mod necontrolat. Dezvoltarea de software în ochii managerilor (în special a celor care nu sunt programatori înșiși) arată uneori ca magie neagră.

La al doilea nivel, se controlează îndeplinirea cerințelor utilizatorilor și crearea de software, deoarece este definită baza proceselor de management de proiect. Procesul de creare a software-ului poate fi privit ca o succesiune de „cutii negre” care pot fi controlate la punctele de tranziție de la o „cutie” la alta - etape fixe. Chiar dacă managerul nu știe ce se face „în interiorul cutiei”, se stabilește cu precizie care ar trebui să fie rezultatul procesului și se stabilesc punctele de control pentru începutul și sfârșitul acestuia. Prin urmare, managementul poate recunoaște problemele în punctele de interacțiune cu cutia neagră și poate răspunde la acestea în timp util.

La al treilea nivel este definită structura internă a „cutiilor negre”, adică. sarcinile care compun procesele. Structura internă este modul în care procesele standard dintr-o organizație sunt aplicate unor proiecte specifice. Legătura de management și executanții își cunosc rolurile și responsabilitățile în cadrul proiectului până la nivelul necesar de detaliu. Managementul este pregătit din timp pentru riscurile care pot apărea în timpul implementării proiectului. Deoarece procesele standardizate și documentate devin „transparente” pentru revizuire, angajații care nu sunt implicați direct în proiect pot primi informații exacte despre starea sa actuală în timp util.

La al patrulea nivel, execuția proceselor este strict legată de instrumente, ceea ce face posibilă determinarea caracteristicilor cantitative ale intensității muncii lor și ale calității execuției. Managerii, având o bază obiectivă de măsurători cantitative, au ocazia de a planifica cu acuratețe etapele și etapele proiectului, de a prezice progresul proiectului și pot răspunde prompt și adecvat la problemele emergente. Odată cu reducerea posibilelor abateri de la termenii, costul și calitatea dați în procesul de implementare a proiectului, capacitatea acestora de a prezice rezultate crește constant.

La al cincilea nivel, pentru a îmbunătăți calitatea produselor și a crește eficiența creării acestora, se lucrează în mod constant și sistematic pentru a crea noi metode și tehnologii îmbunătățite pentru crearea de software. Se atrage atenția nu numai asupra proceselor și tehnologiilor deja utilizate, ci și asupra proceselor și tehnologiilor noi, mai eficiente. Managerii pot cuantifica impactul și eficacitatea schimbărilor în dezvoltarea de software și tehnologia de întreținere.

Al patrulea și al cincilea nivel sunt rare în industria software-ului. Astfel, dacă câteva sute de companii din lume au ajuns la nivelul trei, atunci erau 62 de firme de nivelul cinci (conform datelor SEI pentru 2002) și 72 de al patrulea. Unii nu sunt interesați să-și facă publicitate tehnologiilor organizaționale, în timp ce alții efectuează certificarea pur și simplu sub presiunea clientului.

Este nevoie de zece ani sau mai mult pentru a atinge cele mai înalte niveluri de SMM. Dar chiar și nivelul 3 vă permite să intrați cu îndrăzneală pe arena internațională. Pentru a folosi SMM, o companie nu trebuie să caute angajați cu niște abilități unice, este suficient ca ea să înțeleagă ideea generală. Descrierea modelului CMM specifică în detaliu ce trebuie făcut pentru a se dezvolta în conformitate cu acest model. Orice manager din clasa de mijloc este capabil să urmărească acțiunile reglementate ale CMM.

Pe cea mai recentă versiune a SMM 1.1 se concentrează în principal companii mari, implicat în implementarea proiectelor mari, dar poate fi folosit și de grupuri de două sau trei persoane sau de programatori individuali pentru a finaliza proiecte mici (până la trei luni). În astfel de cazuri, modelul HMM poate juca un rol vital. rol important, întrucât primirea de noi comenzi este în mare măsură determinată de calitatea implementării proiectelor anterioare. Grupurile mici vor fi destul de mulțumite de nivelul 2, deoarece pentru un proiect mic, o abatere de la termenul limită de câteva săptămâni nu este importantă.

Din 2002, o versiune specială de integrare a CMMI a fost distribuită oficial. aceasta noua dezvoltare SEI, care acoperă toate aspectele activităților companiei: de la dezvoltarea și selecția unui contractor până la instruire, implementare și întreținere. În plus, modelul CMMI este extins cu abordări din ingineria sistemelor. Acest model include dezvoltări realizate în timpul proiectării versiunii CMM 2.0 (nu a fost finalizată), principalele modificări în care au vizat clarificarea proceselor pentru companiile de nivel al patrulea și al cincilea, ceea ce este cel mai relevant pentru proiectele americane de amploare.

Modelul CMM este destul de greu și important, dar nu trebuie folosit ca singura bază care determină întregul proces de dezvoltare a software-ului. A fost destinat în primul rând companiilor care dezvoltă software pentru Departamentul de Apărare al SUA. Aceste sisteme se caracterizează prin dimensiunea lor mare și durata de viață lungă, precum și prin complexitatea interfeței cu sisteme hardware și alte software. Echipe destul de mari de programatori lucrează la crearea unor astfel de sisteme, care trebuie să respecte cerințele și standardele dezvoltate de Ministerul Apărării.

Dezavantajele SMM includ următoarele:

1. Modelul se concentrează exclusiv pe managementul proiectelor, și nu pe procesul de creare a unui produs software. Modelul nu ia în considerare factori atât de importanți precum utilizarea anumitor metode, cum ar fi prototiparea, formala și metode structurale, instrumente de analiză statică etc.

2. Modelului îi lipsește analiza riscului și a deciziei, ceea ce împiedică detectarea problemelor înainte ca acestea să afecteze procesul de dezvoltare.

3. Sfera de aplicare a modelului nu este definită, deși autorii recunosc că este universal și potrivit pentru toate organizațiile. Cu toate acestea, autorii nu fac o distincție clară între organizațiile care pot implementa sau nu SMM în activitățile lor. Firme mici consideră că acest model este prea birocratic. Ca răspuns la aceste critici, au fost dezvoltate strategii de îmbunătățire a proceselor pentru organizațiile mici.

scopul principalÎn crearea modelului CMM, a fost intenția Departamentului de Apărare al SUA să evalueze capacitățile furnizorilor de software. Pe acest momentîn timp ce nu există cerințe clare pentru atingerea unui anumit nivel de dezvoltare a organizațiilor de dezvoltare. Cu toate acestea, este general acceptat că o organizație care a atins un nivel înalt are mai multe șanse să câștige o licitație pentru furnizarea de software. Ca alternativă la CMM, se propune o clasificare generalizată a proceselor de îmbunătățire a maturității tehnologice, care este potrivită pentru majoritatea organizațiilor și proiectelor software. Se pot distinge mai multe tipuri generale de procese de îmbunătățire.

1. proces informal. Nu are un model de îmbunătățire clar definit. Poate fi folosit cu succes de o echipă de dezvoltare separată

cov. Informalitatea procesului nu exclude activități formale precum managementul configurației, dar activitățile în sine și relațiile lor nu sunt predeterminate.

2. Proces gestionat. Are un model pregătit care ghidează procesul de îmbunătățire. Modelul definește activitățile, programul lor și relațiile dintre ele.

3. Proces metodic solid. Se presupune că au fost puse în aplicare anumite metode (de exemplu, metodele de proiectare orientate pe obiecte sunt aplicate sistematic). Pentru acest tip de proces, vor fi utile instrumentele de sprijin pentru proiectarea și analiza proceselor (CASE-tools).

4. Procesul de îmbunătățire directă. Are un obiectiv clar definit de îmbunătățire a procesului tehnologic, pentru care există o linie separată în bugetul organizației și sunt definite normele și procedurile de introducere a inovațiilor. O parte a unui astfel de proces este analiza cantitativă a procesului de îmbunătățire.

Această clasificare nu poate fi numită clară și exhaustivă - unele procese pot aparține simultan mai multor tipuri. De exemplu, informalitatea procesului este alegerea echipei de dezvoltare. Aceeași echipă poate alege o metodologie de dezvoltare specifică, având în același timp toate oportunitățile de îmbunătățire directă a procesului. Acest proces este clasificat informală, metodic solidă, îmbunătățire directă.

Necesitatea acestei clasificări se datorează faptului că oferă baza pentru îmbunătățirea cuprinzătoare a tehnologiei de dezvoltare software și permite organizației să aleagă diferite tipuri de procese de îmbunătățire. Pe fig. 1.8 arată relația dintre tipuri diferite sisteme software și procese pentru îmbunătățirea dezvoltării acestora.

Orez. 1.8. Aplicabilitatea proceselor de îmbunătățire

Cunoașterea tipului de produs dezvoltat va face corespondența între sistemele software și procesele de îmbunătățire prezentate în Fig. 1.8 util în alegerea îmbunătățirii procesului. De exemplu, trebuie să creați un program care să sprijine tranziția software-ului de la o platformă de computer la alta. Un astfel de program are o durată de viață destul de scurtă, astfel încât dezvoltarea sa nu necesită standarde și un management special al procesului de îmbunătățire, ca atunci când se creează sisteme cu viață lungă.

Multe fluxuri de lucru au acum suport CASE, astfel încât acestea pot fi apelate procese suportate. Procesele solide din punct de vedere metodic sunt susținute de instrumente de analiză și proiectare. Eficacitatea instrumentului de suport depinde de procesul de îmbunătățire aplicat. De exemplu, într-un proces informal, pot fi utilizate instrumente de suport tipice (instrumente de prototipare, compilatoare, instrumente de depanare, procesoare de texte etc.). Este puțin probabil ca instrumente de asistență mai specializate să fie utilizate în mod continuu în procesele informale.

Modelul SMM nu este unic. Aproape fiecare companie mare își dezvoltă propriile tehnologii de dezvoltare software, uneori aceste tehnologii devin publice și foarte populare. Popularitatea largă a modelului HMM este asociată cu acesta sprijinul statului, dar eficiența reală a SMM este criticată de mulți experți de top. Unul dintre principalele deficiențe ale HMM este asociat cu o cerință inutil de rigidă de a nu se abate de la principiile acestui model, chiar dacă bun simț sugerează contrariul. Asemenea pretenții de deținere a adevărului absolut nu pot decât să trezească suspiciuni, prin urmare, în rândul companiilor mici și mijlocii, abordările care lasă mult mai multă libertate creativității individuale și colective sunt mai populare. Tehnica SPMN considerată mai jos ocupă o poziție intermediară între rigid, „greu”, eficient pt organizații mari soluții precum SMM și cele mai flexibile tehnologii. Ea apare cea mai bună opțiune pentru companiile care, pe de o parte, doresc să-și eficientizeze activitate managerialăși, pe de altă parte, plănuiesc să ajungă în viitor nivel international unde certificarea CMM este foarte de dorit.

Î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 participanții la ședința de lucru, la care au participat aproximativ 200 de specialiști în software și membri ai societății de dezvoltatori.

1. Elementar. Cel mai primitiv statut 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ă, sunt introduse standarde profesionale agreate, iar dezvoltatorii le respectă. 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 (Capability Maturity Model Integration). În prezent, cea mai recentă versiune a CMMi este 1.3 (publicată în 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 o sa incerc 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 procesele de afaceri ale diferitelor organizații
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. Resursele 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
Părere la 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.

Există o oportunitate de a „personaliza” în mod flexibil structura organizațională într-o gamă largă: de la o matrice slabă la una 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. Să remarcăm încă o caracteristică importantă a CMMI. Este destinat nu numai dezvoltării de sisteme software. Multe companii mari nu lansează software, ci vizează produse, î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 modelului 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 pentru ca, de exemplu, aceleași recomandări ITIL să devină un proces normal, și nu un fel de „practică sacră”.

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