În 1982, Departamentul de Apărare al SUA a format o comisie a cărei sarcină principală era să studieze problemele apărute în timpul dezvoltării produselor software în organizațiile departamentale. Ca urmare a activităților comisiei, în decembrie 1984 a fost creat Institutul de Ingineri de Dezvoltare software(Institutul de inginerie software, SEI) cu sediul la Universitatea Carnegie Mellon din Pittsburgh.

1987 SEI publică: scurta descriere structuri CMM; metode de evaluare a proceselor de dezvoltare software; metode de evaluare a maturității proceselor de producție de software; chestionar pentru a identifica gradul de maturitate al proceselor (pentru efectuarea independentă, audit internși audit extern).

1991 Lansarea CMM v1.0.

1992 Lansarea CMM v1.1.

1997 Lansarea următoarei versiuni (îmbunătățite) de CMM.

Metodologia CMM a fost dezvoltată și dezvoltată în SUA ca mijloc de a selecta cei mai buni producători de software pentru a îndeplini comenzile guvernamentale. Pentru a face acest lucru, trebuia să creeze criterii de evaluare a maturității proceselor cheie ale companiei de dezvoltare și să determine un set de acțiuni necesare pentru îmbunătățirea ulterioară a acestora. Ca urmare, metodologia sa dovedit a fi extrem de utilă pentru majoritatea companiilor care doresc să îmbunătățească calitativ procesele existente de proiectare, dezvoltare și testare. softwareși să reducă gestionarea acestora la algoritmi și tehnologii ușor de înțeles și de implementat descrise într-un singur standard.

SMM a devenit de facto un astfel de standard. Utilizarea acestuia face posibilă plasarea dezvoltării software pe o bază industrială, creșterea controlabilității proceselor cheie și a culturii de producție în ansamblu și garantarea muncii de înaltă calitate și finalizarea proiectelor la timp. Baza pentru crearea SMM a fost propunerea de bază că problema fundamentală a „crizei” în procesul de dezvoltare a software-ului de înaltă calitate nu este lipsa de noi metode și instrumente de dezvoltare, ci incapacitatea companiei de a organiza procese tehnologice. si gestioneaza-le.

Pentru a evalua gradul de pregătire al unei întreprinderi de a dezvolta un produs software de înaltă calitate, SMM prezintă concept cheie maturitatea organizației (Maturitate). O organizație este considerată imatură dacă:

• nu există o planificare pe termen lung și de proiect;
• procesul de dezvoltare a software-ului și componentele sale cheie nu au fost identificate, implementarea procesului depinde de condițiile actuale, de manageri și executanți specifici;
• metodele și procedurile nu sunt standardizate sau documentate;
• rezultatul nu este predeterminat de criterii reale care decurg din indicatorii planificați, utilizarea tehnologiilor standard și metricii dezvoltate;
• procesul de elaborare a unei soluții are loc spontan, în pragul art.

În acest caz, există o mare probabilitate ca probleme neașteptate să apară, bugetul să fie depășit sau proiectul să nu fie livrat la timp. Într-o astfel de companie, de regulă, managerii și dezvoltatorii nu gestionează procesele - sunt forțați să rezolve problemele curente și care apar spontan. Să remarcăm că majoritatea companiilor rusești se află în acest stadiu de dezvoltare.

Principalele caracteristici ale unei organizații mature:

• compania are proceduri clar definite și documentate pentru managementul cerințelor, planificare activitati ale proiectului, managementul configurației, crearea și testarea produselor software, mecanisme dovedite de management al proiectelor;
• aceste proceduri sunt rafinate și îmbunătățite în mod constant;
• estimările privind timpul, complexitatea și costul muncii se bazează pe experiența acumulată, metrici dezvoltați și indicatori cantitativi, ceea ce le face destul de precise;
• cele externe au fost actualizate și create standarde interne privind procesele și procedurile cheie;
• există reguli obligatorii pentru pregătirea software-ului metodologic și a documentației utilizatorului;
• tehnologiile se schimbă ușor de la proiect la proiect, bazate pe abordări și tehnici stabile și dovedite;
• se folosește la maximum experiența organizatorică și de producție acumulată în proiectele anterioare, modulele software și bibliotecile de software;
• Noile tehnologii sunt testate și implementate în mod activ, iar eficiența lor este evaluată.

CMM definește cinci niveluri de maturitate tehnologică a unei companii, prin care clienții pot evalua potențialii solicitanți pentru un contract, iar dezvoltatorii pot îmbunătăți procesele de creare de software.

Fiecare nivel, cu excepția primului, constă din mai multe zone cheie de proces (Procesul cheie

Modele de îmbunătățire

Îmbunătățirea proceselor de cerințe

Paradigma managementului calității ca modalitate de organizare a producției a apărut cu mult timp în urmă. Ideile conținute în grupul de standarde ISO9000 1) sunt înrădăcinate, în special, în astfel de invenții „sovietice” precum suport propuneri de raționalizare, mentorat etc.

ÎN concept modernÎntr-o organizație de afaceri orientată spre proces, procesul de îmbunătățire continuă a calității ocupă una dintre pozițiile cheie.

În ceea ce privește industria software-ului, pe lângă seria ISO9000, cele mai dovedite standarde de calitate sunt SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), Bootstrap, TickIT.

Introducerea activă a metodelor de management al calității în Occident a început la începutul anilor 1960. Standardele din seria ISO9000 se bazează pe filozofia abordărilor CPI (Continuous Process Improvement) și TQM (Total Quality Management). Redresarea economică a Japoniei postbelice s-a datorat în mare măsură ideilor încorporate în TQM.

Calitatea este un termen care pentru unii înseamnă nevoia de a face ceea ce își dorește consumatorul, pentru alții înseamnă ceea ce îi satisface nevoile. Managementul calității, așa cum este definit în ISO 9001:2000, se bazează în primul rând pe ideea că oamenii au rezultate mai bune dacă știu ce fac. .

Prin urmare, înainte de a începe orice acțiune, ar trebui să obțineți răspunsuri la întrebările: ce trebuie făcut, cine va verifica ceea ce s-a făcut, cum ar trebui făcut și cum să determinați că lucrarea este finalizată? De asemenea, trebuie să luați în considerare modul în care veți gestiona procesul și cum poate fi îmbunătățit.

Principiile de bază ale ISO9000:

• Concentrare pe nevoile clienților;
• Rolul de conducere activ al managementului;
• Implicarea interpreților în procesele de îmbunătățire;
• Implementarea abordării procesului;
• Abordare sistematică a managementului;
• Asigurarea imbunatatirilor continue;
• Luarea deciziilor bazate pe fapte;
• Relații reciproc avantajoase cu furnizorii.

Avantajul incontestabil al standardelor acestui grup se datorează faptului că acestea au fost testate în multe întreprinderi din întreaga lume. Cu toate acestea, recomandările acestor standarde sunt destul de generale și nu țin cont de specificul întreprinderilor din industria IT. Pentru a realiza acest lucru, au fost dezvoltate abordări specializate, discutate mai jos.

Standardul CMM (Capability Maturity Model) a fost dezvoltat de Institutul de Inginerie Software (SEI) de la Universitatea Carnegie Mellon.

Scopul standardului este de a evalua nivelul de maturitate al organizației de dezvoltare software. Există cinci niveluri: inițial, repetabil, definit, gestionat și optimizare (pentru mai multe detalii, vezi). Acest standard a devenit cunoscut pe scară largă; un număr semnificativ de companii IT occidentale sunt certificate conform CMM.

În 2000, SEI a lansat CMMI-SE/SW, un model integrat pentru îmbunătățirea atât a software-ului, cât și a capabilităților de proiectare a sistemului.

CMMI-SE/SW are două forme. Reprezentarea în etape corespunde structurii SW-CMM cu clarificări minore ale denumirilor nivelurilor. Cinci niveluri de maturitate conțin 22 de zone procese tehnologice, prezentat în tabelul 14.1. (CMU/SEI, 2000a). Reprezentarea continuă are o viziune diferită: aceleași 22 de domenii sunt structurate în 4 categorii: managementul proceselor, managementul proiectelor, construcția și suportul (CMU/SEI, 2000b).

În loc de niveluri de maturitate, vizualizarea continuă definește șase niveluri de capacitate pentru fiecare zonă de proces. Această viziune permite fiecărei organizații să decidă pentru ce nivel de capacitate se califică în fiecare dintre cele 22 de domenii de proces.

Ca și în CMM, în acest standard la nivelul 2 există o zonă numită „Managementul cerințelor”, dar, spre deosebire de standardul anterior, la nivelul 3 există și o zonă separată „Ingineria cerințelor”. Plasarea acestei zone la Nivelul 3 nu implică faptul că cerințele pentru proiectele organizației care nu ating nivelul 2 nu trebuie să fie colectate și documentate. Gestionarea cerințelor este văzută ca ajutând la crearea unor proiecte mai previzibile și mai puțin haotice, care este esența CMM Nivelul 2. Prin adoptarea unui proces de gestionare a schimbării și verificarea stării cerințelor, o organizație se poate concentra mai mult pe dezvoltarea cerințelor de înaltă calitate.

Tabelul 14.1.
Nivel de maturitate	Nume	Zonele de proces
	Elementar	(Nu)
	A reușit	Managementul cerințelor Planificarea proiectelor Monitorizarea și controlul proiectelor Gestionarea acordurilor cu furnizorii Măsurare și analiză Asigurarea calității procesului și a produselor Gestionarea configurației
	Hotărât	Cerințe Inginerie Soluție tehnică Integrarea produsului Verificare Procesul de validare Focalizare Procesul organizațional Definiție Învățare organizațională Management integrat de proiect Managementul riscului Analiza și rezoluția problemelor
	Condus cantitativ	Performanța procesului organizațional Managementul cantitativ al proiectelor
	Optimizarea	Inovații organizaționale și implementarea lor Analiză și rezoluție aleatoare

Zona procesului de management al cerințelor

Subiectele cheie includ modul în care echipa de dezvoltare ar trebui să înțeleagă cerințele și să rezolve problemele cu clienții, să implice membrii proiectului în lucrul cu cerințele și să gestioneze schimbarea. Spre deosebire de SW-CMM, urmărirea (una dintre proprietățile cheie ale cerințelor) este inclusă în zona de proces luată în considerare. Standardul discută următoarele calități de rutare:

• asigurarea înregistrării surselor de cerințe de nivel scăzut sau secundare;
• urmărirea fiecărei cerințe până la cerințele secundare și plasarea acesteia în funcții, obiecte, procese și executanți;
• stabilirea legăturilor orizontale între cerinţe aparţinând aceluiaşi tip.

Cerințe Zona de proces de inginerie

CMMI-SE/SW descrie trei seturi de tehnici de inginerie a cerințelor:

• tehnici care definesc un set complet de cerințe ale clienților, care sunt apoi utilizate pentru a dezvolta cerințele pentru un produs (identificarea nevoilor părților interesate din proiect; traducerea nevoilor și constrângerilor în cerințele clienților);
• tehnici care definesc un set complet de cerințe pentru un produs (stabilirea componentelor produsului; plasarea cerințelor pentru componentele produsului; determinarea cerințelor de interfață);
• tehnici pentru obținerea cerințelor secundare, înțelegerea cerințelor și validarea acestora (stabilirea conceptelor și scenariilor operaționale; determinarea funcționalității necesare a sistemului; analiza cerințelor secundare; estimarea costului, calendarul și riscul creării unui produs; aprobarea cerințelor).

Atât CMM, cât și CMMI stabilesc obiectivele pe care un proiect sau o organizație de dezvoltare software ar trebui să se străduiască să le atingă în diferite domenii de proces. De asemenea, ei recomandă tehnici pentru a ajuta la atingerea acestor obiective.

CMMI-SE/SW reglementează relațiile dintre managementul cerințelor, ingineria cerințelor și alte domenii de proces (Figura 14.1).

Prin utilizarea unui proces definit de dezvoltare software, organizațiile au o schiță consecventă a procesului pe care o pot adapta nevoilor specifice. Nevoile incompatibile de adaptare și standardizare pot fi tratate prin construirea structurii procesului ca fiind formată din module standard sau pași „de bază”, precum și reguli folosite pentru a descrie și stabili relațiile dintre acești pași. În acest caz, adaptarea se realizează prin combinarea lor în modele de proces.

De obicei, managementul calității proiectelor software se bazează pe cunoștințe din trei surse:

Inginerie software (ACM, IEEE);

Management de proiect (PMI);

Calitate (ASQ).

Institutul de Inginerie Software (SEI) de la Universitatea Carnegie Mallon reunește toate aceste trei surse.

Modelul de maturitate a capacității (CMM) servește drept „cadru” pentru procesul de dezvoltare a software-ului. Acest model se bazează pe acțiuni practice și reflectă cele mai bune rezultate ale indivizilor care lucrează pentru îmbunătățirea procesului de dezvoltare software și efectuează analize evaluative ale acestui proces. În cele ce urmează ne vom referi la modul în care managementul calității proiectelor software se încadrează în modelul SEI CMM. Deoarece modelul HMM este bine cunoscut în comunitățile de dezvoltare software, nu este nevoie în mod special de a oferi definiția acestuia. Vom prezenta doar o scurtă descriere a acestuia pentru a demonstra necesitatea utilizării unui ciclu de viață în procesul de dezvoltare. Mai jos este o scurtă descriere generalizată a nivelurilor de dezvoltare a capabilităților funcționale ale modelului SMM.

Modelul CMM este o diagramă în care etapele de dezvoltare corespund cinci niveluri de dezvoltare a funcționalității, pe baza cărora se realizează îmbunătățirea continuă a procesului de dezvoltare. Vorbind despre nivelul de dezvoltare al funcționalității, ele înseamnă de obicei o etapă de dezvoltare strict definită care vizează obținerea unui proces complet de dezvoltare software. Prin împărțirea modelului CMM în cinci niveluri, se acordă prioritate activităților de îmbunătățire necesare pentru a finaliza dezvoltarea funcționalității procesului. Aceste cinci niveluri pot fi descrise pe scurt, atribuindu-le următoarele caracteristici.

Original. Procesul de dezvoltare software poate fi descris ca ad-hoc, ad-hoc sau uneori haotic. Doar un număr mic de procese pot fi identificate, iar succesul depinde de efortul individual și de acțiunile decisive luate.

Repetitiv. Procesele de bază de management de proiect sunt create pentru a urmări costurile, programarea și funcţionalitate. Aici se respecta ordinea necesara de executie a procesului, menita sa reproduca realizarile obtinute anterior in timpul implementarii unor proiecte similare.

Hotărât. Toate proiectele folosesc o versiune dovedită, personalizată a procesului standard de dezvoltare software al organizației.

A reușit. Sunt colectați indicatori detaliați ai procesului de dezvoltare a software-ului și caracteristicile de calitate ale produsului. Procesul de dezvoltare software este gestionat la nivel cantitativ.

Nivel de optimizare.Îmbunătățirea continuă a procesului de dezvoltare se realizează pe cale cantitativă părere.

Această conexiune se realizează prin procesul în sine, precum și prin idei și tehnologii inovatoare. Fiecare nivel de maturitate este împărțit în mai multe zone cheie de proces care indică ce acțiuni mai trebuie luate pentru a îmbunătăți procesul de dezvoltare a software-ului. Fiecare zonă cheie de proces (KPA) definește un set de activități interconectate necesare pentru optimizarea procesului respectiv.

Domeniile KRA de nivelul 2 se referă la probleme care apar în timpul implementării unui proiect software care sunt asociate cu crearea controalelor de bază de management al proiectelor. În această etapă a discuției, trebuie să știm că procesul iterativ (nivelul 2) permite optimizarea structurării și managementului în organizație. Având această definiție creează un limbaj comun și ușurează tranziția atunci când includ dezvoltatori în proces, mai ales dacă au experiență limitată în acest domeniu.

Cu toate acestea, a avea un proces repetabil (Nivelul 2) nu duce neapărat la un proces bine conceput. În general, îmbunătățirea procesului are loc atunci când o organizație atinge nivelul 3. Nivelul 3 abordează atât execuția proiectului, cât și problemele organizaționale, deoarece organizația creează infrastructura pentru a sprijini inginerie software și management eficient al tuturor proiectelor. Două domenii ale KPA, definirea organizării proceselor și managementul integrat al programului, aparțin domeniului subiectului cicluri de viață.

Scopul definirii structurii organizaționale a procesului KRA la nivelul 3 este de a dezvolta și menține un set ușor de utilizat de proprietăți utile procesului de dezvoltare software care îmbunătățesc eficiența procesului într-o serie de proiecte. Definiția procesului include dezvoltarea și menținerea unui proces standard de dezvoltare al unei anumite organizații, precum și proprietățile valoroase ale procesului asociate. Scopul definirii unei structuri de proces organizațional este de a dezvolta și menține un proces de dezvoltare software standard pentru o anumită organizație.

Activitățile care formează procesul de construire a unei structuri organizaționale includ documentarea și menținerea caracteristicilor descriptive cicluri de viață de dezvoltare a software-ului. Scopul managementului software integrat al zonei KPA la nivelul 3 este de a integra activitățile de inginerie software și management într-un proces de dezvoltare software coerent și definit, care rezultă dintr-o adaptare a procesului standard de dezvoltare software al organizației și a proprietăților valoroase ale procesului asociate descrise în „ Definirea procesul la nivelul structurii sale”.

Modelul CMM se referă la un grup de modele de procese software dezvoltate dintr-o bază largă susținută de comunitatea de dezvoltare software. Deoarece avem de-a face cu un model, există o simplificare a procesului de inginerie propriu-zis. Reprezentând un standard, modelul CMM identifică capacitățile unei organizații aparținând categoriei unui anumit grad de maturitate.

Organizațiile care folosesc acest model ca mecanism de măsurare și îmbunătățire a proceselor trebuie să utilizeze o interpretare adecvată a domeniilor de cunoaștere a proceselor în ceea ce privește obiectivele de afaceri. Când este utilizat ca instrument de evaluare și măsurare a procesului, modelul devine o foaie de parcurs pentru îmbunătățirea cu succes a procesului. În general, modelul CMM poate fi văzut ca un set de concepte de inginerie și management clar definite bazate pe principii de asigurare dovedite. În procesul de dezvoltare a software-ului, când cunoștințele trebuie evaluate și protejate în mod corespunzător, trebuie acordată o atenție considerabilă principiilor asigurării calității. Modelul SMM Nu este o colecție de rețete pentru toate ocaziile. Nu specifică modul în care organizația ar trebui să stabilească atributele procesului. De asemenea, utilizarea sa nu garantează succesul imediat. Procesul de implementare a îmbunătățirilor necesită timp și efort continuu în întreaga organizație. În acest caz, managementul executiv și fondurile alocate sunt de o importanță deosebită. Modelul SMM cu greu poate fi clasificat ca o metodologie universală, când „o dimensiune se potrivește tuturor ocaziilor”. Primul pas în utilizarea acestui model este să personalizați nivelurile de maturitate ale aplicației pentru a se potrivi organizației și mixului de proiecte. SEI a dezvoltat alte modele de maturitate a capabilităților care se aplică forței de muncă a organizației, procesului de achiziție de software, ingineriei sistemelor, procesului de dezvoltare a produsului software integrat și procesului software personal.

Întrucât software-ul, ca orice alt capital, poate fi reprezentat sub forma cunoștințelor materializate și, de asemenea, datorită faptului că cunoștințele sunt inițial nesistematizate, incerte și, în mare, incomplete, orice program poate fi reprezentat ca un proces de învățare socială. . Acest proces este implementat sub formă de dialog, în timpul căruia cunoștințe necesare se concretizează sub forma unui produs software finit. În același timp, se realizează comunicarea între utilizatori și dezvoltatori, se realizează interacțiunea dintre utilizatori și instrumentele necesare (tehnologie). Procesul este iterativ, instrumentele utilizate formând mediul în care au loc comunicațiile. Fiecare noua runda de dialog contribuie la dobandirea de cunostinte din ce in ce mai utile de la specialistii implicati.

Una dintre principalele aplicații ale modelului HMM este de a determina ce înseamnă ca un proces să atingă un anumit grad de maturitate. Când se aplică software-ului, putem spune că un proces matur are următoarele atribute:

Specific - indică „metoda necesară îndeplinirii sarcinii”;

Documentat – dezvoltat în așa fel încât să poată fi cunoscut și utilizat în viitor;

Învățat - Învățare bazată pe documentare;

Practic - poate fi folosit în practică și nu depozitat;

Menținută - accesibilă, revizuită și îmbunătățită;

Controlat - modificările sunt aprobate de „participanții afacerii comune”;

Verificat - procesul este efectuat corect;

Verificat - se realizează exact procesul care este necesar;

Măsurat - performanța măsurată este folosită ca bază pentru controlul și îmbunătățirea procesului;

Capacitate de îmbunătățire - flexibilitate și capacitate de schimbare.

Ingineria produsului software este o zonă cheie de proces pentru Nivelul 3, adică. "anumit". Înainte de 1968, termenul „inginerie software” nu era folosit deloc. Ingineria software este aplicarea practică a cunoștințelor științifice în procesul de proiectare și dezvoltare programe de calculator. Acest proces se mai numește dezvoltare de software sau producerea de programe.

Prima apariție a software-ului răspândit datează din 1890. În acest moment, cărțile perforate ale lui Hermann Cholerite (1860-1929), Massachusetts Institute of Technology, Cambridge, Massachusetts, au apărut la Centrele Americane de Recensământ.

În același timp, a avut loc prima depășire a costurilor din vina „calculatoarelor”. Rezultatele centrelor de recensământ din SUA au fost inițial tabulate folosind ajutoare mecanice; tabulatoare mecanice de Herman Hollerith. În același timp, a început să se dezvolte producția de carduri perforate. Fondurile cheltuite pentru tabelarea datelor din centrul de recensământ au fost cu 98% mai mari decât costurile similare suportate în trecut. Acest lucru se datorează parțial deoarece șablonul utilizat pentru a tabula datele a fost conceput în detaliu, iar cantitatea de date tabulată a depășit minimul suma necesară. Deși procesul în sine a fost accelerat semnificativ. În același timp, au apărut cărți perforate, care au fost citite electric.

Revenind la modelul HMM, observăm că la nivelul 2 procesul de dezvoltare software poate fi reprezentat ca un set de „cutii negre” cu anumite puncte de control (etape). După cum se arată în Fig. 2.1, cerințele sunt incluse în proces și „curg” fără probleme într-un set de „cutii negre”.

Orez. 2.1. Procesul de nivelul 2

Sunt generate rezultate de calcul pentru fiecare casetă, iar etapele și etapele de referință sunt utilizate pentru a monitoriza procesul de dezvoltare a produsului software. Aceasta este urmată de faza de implementare a politicilor, standardelor și procedurilor. Evaluarea cantitativă a acestei experiențe se face folosind sistemul metric elementar utilizat în acest proiect. Controlul se realizează prin aplicarea practicilor formale implicate în procesul de management al proiectului. De asemenea, sunt urmărite costurile, programele și un set de proprietăți funcționale. Principalele subiecte ale procesului sunt cerințele software și produsele de lucru, iar integritatea acestora este controlată cu ajutorul unui sistem de management al configurației. Proiectele se caracterizează prin relații strânse cu suportul pentru clienți. Este dezvoltată și capacitatea de a implementa procese software.

La nivelul 3, adică „definit”, procesul standard utilizat pentru dezvoltarea și întreținerea software-ului în organizație este documentat și utilizat în mod consecvent, ceea ce este reprezentat schematic în Fig. 2.2.

Orez. 2.2. Procesul de nivelul 3

În cadrul proiectelor, procesele software standard ale organizației sunt ajustate pentru a le face mai specifice. Procesele de management și inginerie software sunt de asemenea integrate. Capacitățile de a efectua un proces standard sunt standard, iar echipa de dezvoltare este responsabilă pentru activitățile efectuate în proiectul software. Următoarele sunt zonele KRA pentru al treilea nivel de maturitate:

1 Domeniul de aplicare proces organizatoric;

2) definirea procesului organizatoric;

3) ingineria produsului software;

4) management cuprinzător al software-ului;

5) interacțiunea între grupuri;

6) evaluări ale experților;

7) program de antrenament.

La Nivelul 3, procesul de dezvoltare software urmează un proces bine definit. Este necesară o conștientizare a rolurilor și responsabilităților în timpul procesului. Procesul de producție al unui produs software este afișat în timpul execuției procesului software.

Nivelul 4 (Fig. 2.3), i.e. „gestionat” include două domenii ale KPA: managementul proceselor cantitative și managementul calității software.

Orez. 2.3. Proces de nivel 4

Datorită utilizării sistemului metric extins, se acumulează rezultatele evaluărilor detaliate ale procesului de dezvoltare software și ale asigurării calității produselor software. Se efectuează evaluarea și controlul cantitativ al proceselor și produselor software. Procesul de management se bazează pe criterii obiective formulate pentru a lua decizii și a evalua performanța în limitele specificate.

La Nivelul 5 („optimizare”), zonele KPA se concentrează pe etapele managementului schimbărilor tehnologice, managementului schimbărilor proceselor și prevenirii defectelor. Prin îmbunătățirea continuă a procesului, se oferă feedback cantitativ procesului de dezvoltare software. La acest nivel, organizația poate testa noi idei și tehnologii care îmbunătățesc calitatea produsului software, care este descris schematic în Fig. 2.4.

Orez. 2.4. Proces de nivel 5

Prin modificări controlate ale unui proces existent, este introdusă o abordare organizațională pentru a permite îmbunătățirea continuă a procesului. Organizarea acestor schimbări este importantă din următoarele motive:

1) procesul trebuie să fie în concordanță cu tradițiile culturale ale organizației;

2) conducerea este obligată să contribuie la creşterea gradului de cultură;

3) cultura ar trebui să promoveze introducerea modelelor și recompenselor.

Pentru a rezuma, modelul CMM este un fel de „foaie de parcurs” care garantează îmbunătățirea reușită a procesului. Interpretarea și aplicarea acestuia se realizează în contextul obiectivelor de afaceri ale organizației. În prezent, modelul CMM este cea mai comună metodă în organizațiile de dezvoltare de software (și această tendință este tipică pentru multe țări și o mare varietate de domenii de aplicare). Acest model este normativ, nu prescriptiv și se caracterizează și printr-o marjă mare de stabilitate. Dezvoltarea și suportul său este realizată de mulți dezvoltatori uniți într-o comunitate de profesioniști.

Scopul inițial al dezvoltării standardului a fost de a crea o metodologie care să permită marilor organizații guvernamentale din SUA să selecteze cei mai buni furnizori DE. Pentru a face acest lucru, a fost planificat să se creeze o descriere cuprinzătoare a modalităților de evaluare a proceselor și metodelor de dezvoltare software pentru îmbunătățirea lor ulterioară. Drept urmare, autorii au reușit să atingă un astfel de nivel de detaliu și detaliu încât standardul a fost potrivit și pentru companiile de dezvoltare obișnuite care doresc să îmbunătățească procesele existente.

Conceptul principal al standardului este maturitatea organizațională. O organizație în care procesul de dezvoltare a software-ului depinde doar de interpreți și manageri specifici, iar deciziile sunt adesea pur și simplu improvizate din mers este considerată imatură. În acest caz, există o probabilitate mare de a depăși bugetul sau de a rata termenul limită pentru proiect și, prin urmare, managerii sunt nevoiți să se ocupe doar de rezolvarea problemelor imediate.

Pe de altă parte, o organizație matură are proceduri bine definite pentru crearea produselor software și gestionarea proiectelor. Aceste proceduri sunt rafinate și îmbunătățite, după cum este necesar, prin proiecte pilot sau analize cost/beneficiu. Estimările privind timpul și costul pentru finalizarea lucrării se bazează pe experiența acumulată și sunt destul de precise. În sfârșit, compania are standarde pentru procesele de dezvoltare, testare și implementare software, reguli pentru proiectarea codului final al programului, componente, interfețe etc. Toate acestea constituie infrastructuraȘi cultură corporatistă, sprijinind procesul de dezvoltare software.

Acestea sunt premisele de bază ale standardului CMM. Putem spune că standardul în ansamblu constă în criterii de evaluare a maturității unei organizații și rețete pentru îmbunătățirea proceselor existente. Aceasta este o diferență fundamentală față de modelul adoptat de ISO 9001, deoarece ISO 9001 precizează doar conditiile necesare pentru a atinge un anumit nivel minim de organizare a proceselor si nu se dau recomandari pentru existenta in continuare a proceselor.

Modelul CMM definește cinci niveluri de maturitate organizațională. Ca urmare a certificării, companiei i se atribuie un anumit nivel, care ulterior poate fi crescut sau (teoretic) scăzut. În fig. 1 enumeră câteva tehnologii a căror implementare este necesară diferite niveluri maturitatea organizatiei. Rețineți că fiecare nivel următor include toate caracteristicile cheie ale celor anterioare.

Orez. 1. Cinci niveluri de maturitate în modelul CMM

Nivelul inițial este descris în standard ca bază pentru compararea cu nivelurile ulterioare. La o întreprindere entry-level, nu există condiții stabile pentru crearea de software de înaltă calitate. Rezultatul oricărui proiect depinde în totalitate de calitățile personale ale managerului și de experiența programatorilor, iar succesul unui proiect poate fi repetat doar dacă aceiași manageri și programatori sunt numiți pentru următorul proiect. În plus, dacă astfel de manageri sau programatori părăsesc întreprinderea, atunci odată cu plecarea lor, calitatea produselor software produse scade brusc. În situații stresante, procesul de dezvoltare se reduce la scrierea codului și la testarea minimă.

Pentru a atinge un nivel repetabil, tehnologiile de management de proiect trebuie implementate la nivelul intreprinderii. În același timp, planificarea proiectele se bazează pe experiența acumulată, există standarde pentru software-ul în curs de dezvoltare (și respectarea acestor standarde este asigurată) și există o echipă specială de asigurare a calității. Dacă este necesar, organizația poate lucra cu subcontractanți. În condiții critice, procesul tinde să alunece înapoi la nivelul inițial.

Urmează un nivel definit, care se caracterizează prin faptul că procesul standard de creare și întreținere a software-ului este documentat (incluzând atât dezvoltarea software-ului, cât și managementul proiectelor). Se înţelege că în procesul de standardizare are loc o tranziție către cele mai eficiente practici și tehnologii. Un grup special trebuie creat în cadrul organizației pentru a crea și menține standardul. In cele din urma, condiție prealabilă Pentru a atinge acest nivel, întreprinderea dispune de un program de dezvoltare profesională continuă și de formare a angajaților. De la acest nivel, organizația încetează să mai depindă de calitățile dezvoltatorilor specifici și nu tinde să coboare la un nivel inferior în situații stresante.

La nivel de manager, organizația stabilește indicatori cantitativi calitate – atât pentru produse software, cât și pentru produse în general. Astfel, managementul de proiect îmbunătățit se realizează prin reducerea variației diferiților indicatori de proiect. Procedând astfel, variațiile semnificative ale performanței procesului pot fi distinse de variațiile aleatorii (zgomot), în special în zonele bine dezvoltate.

În sfârșit, nivelul de optimizare se caracterizează prin faptul că măsurile de îmbunătățire sunt aplicate nu numai proceselor existente, ci și pentru evaluarea eficienței introducerii de noi tehnologii. Sarcina principală a întregii organizații la acest nivel este îmbunătățirea continuă a proceselor existente. În același timp, îmbunătățirea procesului ar trebui să ajute în mod ideal la prevenire posibile greșeli sau defecte. În plus, ar trebui depuse eforturi pentru a reduce costul dezvoltării software, de exemplu, prin crearea și reutilizarea componentelor.

La certificare Conformitatea tuturor domeniilor cheie este evaluată pe o scară de 10 puncte. Pentru a te califica cu succes în acest domeniu cheie, trebuie să obții cel puțin 6 puncte. Domeniul cheie este evaluat pe baza următorilor indicatori:

• Interesul conducerii în acest domeniu (dacă este planificată implementarea practică a acestui domeniu cheie, managementul înțelege necesitatea acestui domeniu etc.).
• Cât de larg este utilizată această zonă în organizație (de exemplu, un scor de 4 puncte corespunde unei aplicații fragmentate).
• Succesul utilizării acestei zone în practică (de exemplu, un scor de 0 puncte corespunde absenței complete a oricărui efect și se acordă un scor de 8 puncte dacă există un rezultat pozitiv sistematic și măsurabil în aproape întreaga organizație).

În principiu, un singur proces sau unitate a unei organizații poate fi certificat; de exemplu: divizia de dezvoltare software a IBM este certificată la nivelul cinci. Apropo, sunt foarte puține companii în lume care se pot lăuda că au cel de-al cincilea nivel de CMM în cel puțin una dintre diviziile lor - sunt doar 50. Pe de altă parte, există câteva mii de companii certificate conform Nivelul 3 sau 4, adică există un decalaj colosal între nivelul de maturitate optimizat și nivelurile anterioare. Cu toate acestea, se observă un decalaj și mai mare între numărul de organizații entry-level și numărul omologilor lor mai avansati - conform unor estimări, peste 70% din toate companiile de dezvoltare sunt la primul nivel al CMM.

O întrebare interesantă este relația dintre nivelurile CMM și Standardul ISO 9001: La ce nivel de CMM trebuie să fie o organizație pentru a obține certificarea ISO 9001? La prima vedere, pentru aceasta trebuie să aveți cel puțin nivelul 3 sau 4 de CMM. Cu toate acestea, există exemple de organizații de nivel 1 care au un certificat ISO 9001. Unul dintre motivele unor astfel de absurdități este nivel inalt abstracții ale ISO 9001 și libertatea de interpretare asociată auditor. Uneori, destul de ciudat, auditorilor le lipsește familiaritatea de bază cu practicile actuale de dezvoltare software. Un raport mai detaliat despre relația dintre ISO 9001 și CMM este dat în articol.

Unele aspecte importante, cum ar fi selecția, dezvoltarea și păstrarea angajaților competenți, au rămas în afara domeniului de aplicare al CMM. Cu toate acestea, aceste întrebări sunt extrem de importante, deoarece, după cum se menționează în articol, „...și în urmă cu 20-30 de ani se știa că doi programatori care stăteau la mese alăturate și primeau același salariu puteau scrie programe care diferă ca viteză de calcul, spune de 10 ori.” Apropo, situația din Rusia este și mai complicată în comparație cu țările occidentale - programatorii ruși nu numai că se pot muta la un alt loc de muncă, ci și se pot muta în altă țară cu un salariu mai mare!

Desigur, selecția angajaților este deosebit de importantă pentru organizațiile de nivel întâi, deoarece angajații pentru ei sunt o garanție naturală a calității. Dar chiar și la niveluri mai mari de maturitate, „factorul uman” își păstrează importanța. Prin urmare, în 1995, a fost publicat standardul People CMM, care este o completare la Software CMM și are o structură în general similară. Implementarea acestui standard în paralel cu CMM-ul obișnuit oferă organizației un întreg set de proceduri de evaluare și dezvoltare a întregului sistem de angajare, formare și reținere a angajaților calificați. Într-o formă interesantă, deși oarecum excentrică, ideile People CMM sunt formulate de unul dintre autorii săi principali într-un articol.

Pe lângă People CMM, au apărut câteva alte modele care completează CMM, de exemplu în achiziția de software sau dezvoltarea de sisteme mari. Pentru a integra pe deplin aceste modele și a reduce costurile totale ale implementării lor, a fost întreprins proiectul de integrare CMM (de dragul implementării sale, lansarea versiunii 2.0 a CMM a fost chiar anulată în 1998).

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

Un instrument practic minunat creat în cadrul unei abordări procesuale pentru descrierea activităților unei organizații de proiectare, în special, a unei organizații care 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 des 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 ordonat Institutului de Inginerie Software 1ing. SEI - Institutul de Inginerie Software al Universității Carnegie Mellon lucrează la crearea unui sistem de criterii de selectare a subcontractanților în proiectele de dezvoltare software. Lucrarea a fost finalizată în 1991, iar rezultatul a fost modelul CMM. Este necesar să faceți imediat o rezervă că modelul nu conține niciun fel financiar, economic, politic, criterii organizatorice selectarea unui subcontractant, precum și criteriile pentru posibilitatea de acces la lucrări clasificate (probabil astfel de sarcini nu au fost stabilite). Vorbim doar despre criterii care descriu capacitățile unui potențial subcontractant în ceea ce privește dezvoltarea sistemelor software.

Structura CMM

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

Ipoteza 1. Există niveluri calitativ diferite de maturitate ale unei organizații de proiectare care dezvoltă sisteme informaționale (există cinci astfel de niveluri în modelul CMM).

Ipoteza 2. Fiecare organizație de dezvoltare este interesată să treacă la un nivel superior de maturitate (nu doar pentru a-și crește șansele în competiția pentru contractele Departamentului Apărării, ci și în scopul propriei îmbunătățiri).

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

Astfel, nivelurile formează o „scara” de-a lungul căreia se ridică organizația ca propria dezvoltare. Fiecare nivel este caracterizat de o anumită compoziție și proprietăți ale proceselor organizației. „Scara nivelurilor” a SMM a primit recunoaștere și diseminare pe scară largă. Așa 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 procese de bază de management al proiectelor care vă permit să urmăriți costurile, să monitorizați programul de lucru și funcționalitatea soluției software create. A fost stabilită disciplina de proces necesară pentru a reproduce succesele anterioare în proiecte similare de dezvoltare a aplicațiilor.

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

Nivelul 4 „Gestionat” . Sunt colectați indicatori cantitativi detaliați ai procesului de producție și a calității produsului creat. Atat procesul de productie cat si produsele sunt 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 dată intuitiv de cele mai multe ori nu ridică obiecții. Mai mult, specialiștii cu experiență înțeleg de ce tranzițiile sunt posibile doar la nivelul vecin și este, de asemenea, clar de ce merită să ne străduim pentru o astfel de tranziție în general. În același timp, modelul HMM nu conține nicio justificare cantitativă sau chiar formală a acestei abordări, ceea ce, însă, nu-i scade în niciun fel avantajele.

Ce se întâmplă în continuare, după cum se spune, este o chestiune de tehnică. Se determină structura modelului (Fig. 7.1), se dau definiții și se începe munca minuțioasă pentru a descrie cu acuratețe fiecare proces la fiecare nivel. Pentru a evalua valoarea practică a ceea ce s-a făcut, vom merge parțial pe această cale.

Orez. 7.1.

În fig. 7.1 conține următoarele concepte.

Grup de procese cheie. După cum se precizează în (Paulk, et al., 1995), „fiecare grup de procese cheie definește un bloc lucrări conexe, în urma cărora se realizează un set de obiective semnificative pentru creșterea productivității procesului de producție. De exemplu, pentru grupul cheie de procese „Gestionarea cerințelor” (vezi Figura 7.2), scopul este de a conveni asupra cerințelor propuse pentru proiectul de dezvoltare software de către 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 construite procesele, adică modul în care practicile cheie ar trebui să fie legate î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 niveluri de maturitate (Fig. 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 ne permite să garantăm funcționalitatea deplină a tuturor proceselor la un anumit nivel și, prin urmare, să corelăm nivelul cu stadiul finalizat de dezvoltare a organizației.

Adjectivul „cheie” implică faptul că există grupuri de procese (adică seturi de practici) care nu sunt cheie din punctul de vedere al unui anumit nivel de maturitate, adică nu au legătură cu atingerea obiectivelor acestui nivel (vezi mai jos). Modelul CMM nu descrie toate grupurile de procese legate de dezvoltarea și întreținerea software-ului. Descrie numai acele grupuri care sunt identificate ca determinanți cheie ai productivității în procesul de producție.

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

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

Capitolul . 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 măsura în care sunt legalizate în organizație, adică aprobate oficial și în concordanță cu procedurile, politicile și alte procese corporative. Acestea sunt cele cinci secțiuni.

Obligații de performanță

Descrieți activitățile pe care o organizație trebuie să le desfășoare pentru a asigura stabilirea și stabilitatea unui proces. Angajamentele de implementare se referă în mod obișnuit la stabilirea politicilor organizaționale și a sprijinului din partea conducerii superioare.

Cerințe preliminare

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

Operațiuni efectuate

Secțiunea „Operațiuni efectuate” descrie munca de fond care trebuie efectuată la acest nivel. Operațiunile efectuate includ de obicei crearea de planuri și implementarea activităților specifice, executarea și monitorizarea lucrărilor și luarea de acțiuni corective, dacă 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 aduc cea mai mare contribuție la implementarea și stabilirea efectivă a grupului de procese cheie.

Fiecare practică cheie constă dintr-o propoziție, adesea extinsă într-o descriere mai detaliată, care poate include exemple și clarificări. Practicile de bază, uneori numite practici de bază de nivel superior, stabilesc politicile, procedurile și operațiunile de bază pentru un grup de procese cheie. Componente descriere detaliata numiți adesea sub-practicanți”.

Practicile de bază descriu CE trebuie făcut, dar nu ar trebui să fie luate ca dogme care declară CUM se ating obiectivele. Obiectivele unui grup de procese cheie pot fi atinse prin practici alternative. Interpretarea practicilor cheie trebuie să fie rezonabilă, permițând atingerea obiectivelor unui grup de procese cheie mod eficient, deși poate formal 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 la prima vedere oarecum exotică. Până acum, sarcina de îmbunătățire a managementului IT a fost rezolvată prin introducerea de procese gata făcute dintr-un model de proces de referință. Acum există multe niveluri care conțin practici cheie disparate (adică, neintegrate în procese) și o secvență recomandată de progresie prin niveluri. Guvernanța IT, conform CMM, se îmbunătățește pe măsură ce trece la niveluri mai înalte de maturitate. Ce se întâmplă cu o astfel de avansare?

În definițiile nivelurilor (vezi Fig. 7.2), a apărut un concept precum „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 cu exactitate în SMM, Standard Proces de fabricație Organizațiile (SPPO) sunt unul dintre conceptele centrale ale întregului model.