Acasă » Control » Modelul de maturitate a capacității (CMM). Standarde ISO, SW-CMM

Modelul de maturitate a capacității (CMM). Standarde ISO, SW-CMM

Modele de îmbunătățire

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

Paradigma managementului calitatii, ca modalitate de organizare a productiei, a aparut cu mult timp in urma. Idei incluse în grupul de standarde ISO9000 1) , sunt înrădăcinate, în special, în astfel de invenții „sovietice” precum suport pentru propuneri de raționalizare, mentorat etc.

În conceptul modern al unei organizații de afaceri orientate pe procese, 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 de succes 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. Filosofia abordărilor CPI (Continuous Process Improvement) și TQM (Total Quality Management) au stat la baza standardelor din seria ISO9000. Creșterea economiei Japoniei postbelice s-a datorat în mare parte ideilor întruchipate în TQM.

Calitatea este un termen care pentru unii înseamnă nevoia de a face ceea ce își dorește consumatorul, pentru alții – ceea ce îi satisface nevoile. Managementul calității, așa cum este definit în ISO 9001:2000, se bazează în primul rând pe faptul că oamenii au rezultate mai bune atunci când ș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:

Concentrați-vă pe nevoile clienților;
Rolul de conducere activ al managementului;
Implicarea interpreților în procesele de îmbunătățire;
Implementarea abordării procesului;
Abordarea sistemelor la conducere;
Asigurarea imbunatatirii 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 la multe întreprinderi din lume. Cu toate acestea, recomandările acestor standarde sunt de natură destul de generale și nu țin cont de specificul întreprinderilor IT. Pentru aceasta, au fost dezvoltate abordări specializate, discutate mai jos.

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

Scopul standardului este de a evalua nivelul de „maturitate” (niveluri de maturitate) al organizației – dezvoltator de software. Se disting 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 se conformează structurii SW-CMM cu rafinamente minore la numele nivelurilor. Cele cinci niveluri de maturitate conțin cele 22 de zone ale fluxului de lucru prezentate î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, proiectarea și suportul (CMU/SEI, 2000b).

Într-o perspectivă continuă, în loc de niveluri de maturitate, sunt definite șase niveluri de capacitate pentru fiecare zonă de proces. Această vizualizare permite fiecărei organizații să decidă ce nivel de capacitate are nevoie î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ă de Dezvoltare a cerințelor. Plasarea acestei zone la nivelul 3 nu implică faptul că cerințele pentru proiectele organizaționale care nu ating nivelul 2 nu trebuie colectate și documentate. Managementul cerințelor este văzut ca o modalitate de a ajuta 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 poate pune mai mult accent pe dezvoltarea cerințelor de înaltă calitate.

Tabelul 14.1.
nivelul de maturitate	Nume	Zonele de proces
	Elementar	(Nu)
	A reușit	Managementul cerințelor Planificarea proiectelor Monitorizarea și controlul proiectului Managementul acordului cu furnizorii Măsurarea și analizarea procesului și asigurarea calității produsului Managementul configurației
	Hotărât	Dezvoltarea cerințelor Soluție tehnică Integrarea produsului Verificarea procesului de validare Focalizarea procesului de organizare Definirea procesului de organizare Învățare organizațională Management integrat de proiect Managementul riscului Analiza și rezolvarea problemelor
	gestionate cantitativ	Performanţă procesele organizatorice Management cantitativ de proiect
	Optimizarea	Inovații organizaționale și implementarea lor Analiză și rezoluție aleatoare

Zona de proces 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 părțile interesate din proiect î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 considerată. Următoarele calități ale urmăririi sunt discutate în standard:

furnizarea unei evidențe a surselor cerințelor de nivel scăzut sau secundare;
urmărirea fiecărei cerințe până la cerințele secundare și aranjarea acesteia în funcție de funcție, obiect, proces și lucrător;
stabilirea de legături orizontale între cerinţe aparţinând aceluiaşi tip.

Zona de proces de inginerie a cerințelor

Trei seturi de tehnici de dezvoltare a cerințelor sunt descrise în CMMI-SE/SW:

tehnici care definesc un set complet de cerințe ale clienților, care sunt apoi utilizate pentru a dezvolta cerințele pentru produs (identificarea nevoilor părților interesate din proiect; convertirea nevoilor și constrângerilor în cerințe ale clienților);
tehnici care determină setul complet de cerințe pentru produs (instalarea 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 confirmarea acestora (stabilirea conceptelor și scenariilor operaționale; determinarea funcționalității cerute a sistemului; analiza cerințelor secundare; evaluarea costului, timpul și riscul creării unui produs; aprobarea cerințelor).

Atât CMM, cât și CMMI articulează obiectivele pe care un proiect sau o organizație de dezvoltare software ar trebui să se străduiască să le atingă în domenii diverse proceselor. De asemenea, recomandă tehnică contribuind la atingerea acestor obiective.

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

05.04.2007 Viaceslav Pankratov

Se vorbește mult în aceste zile despre calitatea software-ului și sisteme de informare, se efectuează studii care demonstrează dependența de calitate și eficiență a proceselor de afaceri automatizate. Calitatea software-ului dintr-un concept abstract și intangibil se transformă într-o metrică cuprinzătoare pentru evaluarea unei soluții software, a unui proiect de implementare a acesteia, a procesului de creare și a nivelului de utilizare a sistemelor informaționale în ansamblu. Ce determină calitatea programelor și cum o poți influența?

Astăzi se vorbește mult despre calitatea software-ului și a sistemelor informaționale, se fac cercetări care demonstrează dependența de calitate și eficiență a proceselor automate de afaceri. Calitatea software-ului dintr-un concept abstract și intangibil se transformă într-o metrică cuprinzătoare pentru evaluarea unei soluții software, a unui proiect de implementare a acesteia, a procesului de creare și a nivelului de utilizare a sistemelor informaționale în ansamblu. Ce determină calitatea programelor și cum o poți influența?

Evident, calitatea software-ului depinde direct de calitatea procesului său de producție. Prin gestionarea procesului de producție și monitorizarea indicatorilor de performanță din toate etapele sale tehnologice, este posibilă influențarea calității produsului. Vorbind despre caracteristicile programelor, putem evidenția metrici cantitative care sunt ușor de înțeles și analizat, legate de calitatea codului programului (complexitatea codului ciclomatic - complexitatea structurii modulului, de exemplu, numărul de rute independente în aceasta); numărul de linii de cod atribuite artefactelor depozitului de proiectare etc.; teste (care acoperă ramuri de cod și module cu scripturi de testare, raportul dintre numărul de erori găsite înainte și după lansarea produsului, dinamica detectării erorilor etc.); acoperirea cerințelor pentru conformitatea cu recomandările pentru interfața aplicației și platformele de operare. Cu toate acestea, la trecerea la nivelul procesului de asigurare a calității programelor dezvoltate, apar anumite dificultăți în înțelegerea calității acestui proces. Într-adevăr, cum să evaluăm și să măsori, de exemplu, eficacitatea uneia sau alteia metode de dezvoltare, dacă practic nu există proiecte de dezvoltare pentru două sisteme software identice și, cu atât mai mult, nu există două echipe de dezvoltare care să fie identice ca experiență și aptitudini? Judecat de rezultat final nu este posibil: pe lângă condițiile de proces pentru producția de software (metodologia utilizată, structura echipei de proiect, metodele de comunicare cu clientul), condițiile proiectului (termeni, cost și volum de resurse) variază adesea foarte mult. O analiză mai detaliată a procesului de testare a software-ului - o componentă tehnologică a procesului de producție - dezvăluie problema alegerii metricilor de eficiență a testelor.

Pe lângă o evaluare directă a nivelului actual de eficiență al unui anumit proces, există o sarcină mai interesantă - creșterea nivelului de eficiență sau, după cum se spune, nivelul de maturitate proceselor. Când sunt rezolvate problemele de bază ale planificării și desfășurării lucrărilor de testare în integrare cu procesul de dezvoltare software, apare sarcina de a găsi scheme organizatorice și procedurale optime pentru efectuarea muncii. După ce a răspuns la întrebările „cine” și „când”, trebuie să căutați răspunsuri la întrebările „cum, în ce fel”, „cum se măsoară rezultatele”, „cum se controlează”, „cum se lucrează mai eficient”, și, de asemenea, „cum să gestionați și să dezvoltați procesul bazat pe date și experiență.

În practica de zi cu zi - atunci când lucrează cu instrumente specifice - profesioniștii IT și managerii de proiect își dezvoltă o opinie puternică despre natura tehnologică a tuturor problemelor asociate cu calitatea software-ului și nivelurile de maturitate ale procesului de dezvoltare software care sunt atinse. Drept urmare, credința promovată de furnizor în puterea software-ului de îmbunătățire a calității în practică devine terenul propice pentru decizii nerezonabile de implementare a metodologiilor sau automatizarea proceselor de dezvoltare, începând cu implementarea unor soluții software specifice. in orice caz facilitati moderne automatizarea proceselor de dezvoltare sunt platforme atât de flexibile și personalizabile încât necesită un studiu preliminar profund al componentei procesului cu implementarea ulterioară și adaptarea la condițiile specifice de producție.

În 1980, s-a dezvoltat Institutul de Inginerie Software de la Universitatea Carnegie Mellon modelul de maturitate al procesului de dezvoltare software(Capability Maturity Model for Software, CMM), care a fost ulterior dezvoltat în CMMI (Capability Maturity Model Integration), un certificat de facto al nivelului de maturitate de dezvoltare recunoscut în industria software. Prin analogie cu lumea dezvoltării software și cu modelele existente ale maturității proceselor acestora, vom lua în considerare modele ale maturității procesului de testare.

Modelul de maturitate de testare

Modelul de maturitate pentru testarea software-ului este o abordare sistematică a dezvoltării procesului de testare, care oferă un sistem de elemente de procese eficiente și modalități de atingere a obiectivelor specifice procesului. Pe baza modelului de maturitate, pot fi rezolvate două sarcini principale ale dezvoltării procesului: înțelegerea și fixarea procesului de testare curent și identificarea zonelor de îmbunătățire. Practica arată că schimbările de proces sunt posibile numai pe baza unei înțelegeri clare de către conducere a necesității de a face astfel de schimbări - orice schimbare structurală și procedurală este imposibilă fără voința politică a managementului. Pe lângă faptul că primesc suport de management și resursele necesare, efectuarea de modificări în procesul de testare a lucrărilor necesită o planificare clară, ca orice altă activitate de proiect.

Consultantul de testare Terry Weatheril a fost unul dintre primii care au comparat modelele existente de maturitate de testare în 2001 și a identificat șase modele:

Modelul de maturitate de testare (TMM);

Modelul de maturitate pentru testarea software-ului (TMMSW);

Îmbunătățirea procesului de testare (TPI);

Test Organization Maturity (TOM);

Programul de evaluare a testelor (TAM);

Evaluare și testare propuse SW-CMM domenii cheie de proces (SW-CMM KPA).

Apoi au fost aduse modificări fundamentale la unele modele; Astfel, modelul TOM (a fost creat și dezvoltat de Gerrard Consulting) oferă un set actualizat de metrici care descriu procesul de testare în sine (durata iterațiilor de testare, raportul dintre scenariile de testare și cerințele funcționale etc.), care sunt colectate. și analizate în etapa de descriere a procesului existent.

Printre cele șase modele de maturitate de testare a software-ului, practicienii și consultanții identifică două: TMMSW, dezvoltat la Institutul de Tehnologie din Illinois și TPI, propus de Sogeti. Ambele modele s-au răspândit în primul rând datorită simplității lor, precum și a practicilor propuse de audit intern care pot fi efectuate de specialiștii unei companii care a pornit pe calea îmbunătățirii proceselor. Luați în considerare structura modelelor de maturitate de testare software folosind modelul TMM ca exemplu.

Modelul TMMSW, ales de Thomas Staab, unul dintre consultanții de top în domeniul testării software, este cel mai interesant de aplicat, deoarece, alături de ușurința de înțelegere și utilizare a practicilor, permite organizațiilor să efectueze evaluări (evaluare) pe proprii și se apropie treptat de obiectivele lor de dezvoltare, controlând rezultatele intermediare. În munca noastră, am optat și pentru acest model, având în vedere impopularitatea practicii de atragere a competenței terților în rândul companiilor IT autohtone (companiile încearcă să economisească proiecte de investitii, care în esență sunt proiecte de consultanță, precum și proiecte care aduc beneficii indirecte, care includ modificări de proces), și vă invităm să faceți cunoștință cu experiența noastră, care demonstrează disponibilitatea companiilor de a efectua în mod independent schimbările interne folosind proprii specialiști. . Iterația abordării este un punct cheie pentru multe companii atunci când aleg unul sau altul model de maturitate, deoarece vă permite să controlați calendarul proiectului pentru implementarea modificărilor procesului.

Modelul TMMSW a fost dezvoltat de un grup de specialiști condus de Ilene Barnstein în 1996 ca o extensie și o completare la modelul SW-CMM. Avantajele sale includ corespondența dintre nivelurile de maturitate ale proceselor de testare a software-ului și nivelurile de maturitate ale proceselor de dezvoltare în modelul SW-CMM. De asemenea, modelul TMMSW poate fi utilizat în integrare cu CMMI, recomandările ISO-9001 și ISO/IEC Std 12207, care vă permit să obțineți certificare formală și, cu monitorizare constantă sub formă de audituri și recertificări, să rămâneți la un anumit nivel de calitate. . Pe de o parte, această caracteristică a TMMSW permite implementarea modificărilor de proces în departamentul de testare software sub forma unui proiect dedicat la o scară mai mică decât implementarea CMMI în întreaga organizație (care economisește bani și oferă transparență); pe de altă parte, această abordare elimină costul adaptării și împerecherii mai multor modele. Apropo de un fel de relație cu CMMI, aș dori să subliniez că acest model este destul de răspândit în lumea IT și a câștigat un grad ridicat de încredere în sine, ceea ce face mult mai ușor pentru management să motiveze costul unei schimbări de proces proiect.

Modelul TMMSW oferă mai ușor planificarea, implementarea și monitorizarea procesului de îmbunătățire. Printre deficiențele modelului, se remarcă literatura limitată: cartea Practical Software Testing: A Process-oriented Approach, publicată de Springer Professional Computing, este poate singura lucrare semnificativă pe această temă.

Modelul TMMSW, ca și CMM, are cinci niveluri de maturitate.

Nivelul 1 - haotic. Procesul de testare a software-ului este haotic în natură, ceea ce distinge majoritatea companiilor start-up. Procesul de testare nu este definit ca o activitate dedicată și nu este separat de procesul de depanare a codului. Testarea se face după ce codul este generat și sistemul este construit sau asamblat. Scopul testării este să arate că aplicația funcționează. Acest nivel se caracterizează prin personal neinstruit, lipsă de resurse și instrumente. Software-ul este lansat fără acordul oficial al testatorilor. Obiectivele de nivel nu sunt definite.

Nivelul 2 - faza de dezvoltare. Testarea software-ului este separată de codificare și este evidențiată ca fază următoare. Scopul principal al testării este de a demonstra că aplicația îndeplinește cerințele. Există abordări de bază și practici de testare. Obiective de nivel: definiți sarcinile de dezvoltare și testare, creați proceduri adecvate, inițiați procesul de planificare a testelor, stabiliți și descrieți procedurile și tehnicile de testare de bază.

Nivelul 3 - integrat. Procesul de testare este integrat în ciclu de viață dezvoltare de software. Obiectivele testului se bazează pe cerințe. Există o organizare a testării, iar testarea în sine este alocată activitate profesională. Obiective de nivel: de a identifica testarea într-un grup separat și de a defini un program de pregătire tehnică, de a integra procesul de testare în ciclul de viață al dezvoltării și, de asemenea, de a controla procesul de testare în sine.

Nivelul 4 - control și măsurare. Testarea este un proces măsurabil și controlat. Procesele sunt critice inspecții(revizuirea) artefactelor proiectului (planuri și scenarii de testare, mesaje de eroare, rapoarte de stare a versiunii finale etc.) se referă la activitățile de testare. Produsul este testat pentru conformitatea cu parametrii de calitate precum fiabilitatea, gradul de utilizare, mentenabilitatea. Scripturile de testare sunt înregistrate, stocate în sistemul de management al testelor și pot fi reutilizate împreună cu seturile de date de testare. Defectele detectate nu sunt doar remediate, ci și analizate în funcție de criterii formale: criticitate, „greutatea” defectului, importanță, durata de viață etc. Obiective de nivel: Implementarea programelor de revizuire critică și audit la nivel de organizație/unitate la egalitate cu un program de testare măsurată. Evaluarea calității în curs produse software.

Nivelul 5 - optimizarea procesului, prevenirea erorilor și controlul calității. Testarea este un proces definit și controlat. Costul testării împreună cu indicatorii de performanță poate fi determinat. Testarea ca proces se pretează la schimbări care îl afectează în mod clar pozitiv. Sunt implementate și utilizate practici de prevenire a erorilor și de control al calității. Testarea automată este utilizată ca abordare principală în testare. Proiectarea testelor, analiza rezultatelor obținute, prelucrarea descrierilor erorilor, precum și a metricilor legate de testare, se realizează cu ajutorul instrumentelor adecvate. Abordarea reutilizarii practicilor de proces este larg răspândită. Obiective de nivel: optimizarea procesului de testare, prevenirea erorilor și controlul calității.

Toate nivelurile de maturitate enumerate, cu excepția primului, includ obiective de dezvoltare, care, la rândul lor, conțin sub-obiective, adică vă permit să operați nu numai cu sarcini de nivel înalt de management al calității procesului de dezvoltare software, ci și să formulați operaționale. sarcini pentru toți executanții din proiect. Controlul și analiza performanței sarcinilor se realizează prin acoperirea așa-numitelor matrice ATR (Activități - Sarcini - Responsabilități) - artefacte la nivel de proiect cu care participanții la proiect pot lucra fără pregătire prealabilă sau instruire pe termen lung. Matricele ATR definesc activitățile și sarcinile care trebuie efectuate în fiecare etapă specifică a implementării modelului și servesc atât ca „foaie de parcurs”, cât și ca un fel de „listă de verificare” pentru procesul de implementare a schimbării. Prezența artefactelor de design oferite de modelul în sine este adesea un criteriu esențial pentru succesul unui proiect de adaptare și implementare a modelului. Fiecărei activități din matricea ATR îi este atribuită o sarcină de control, care este efectuată de manageri, dezvoltatori/testeri sau clienți/utilizatori. Menționăm în special că controlul asupra proiectului de schimbare nu este atribuit unui grup selectat de oameni sau unei anumite persoane din proiect, ci este o funcție generală a proiectului, în care sunt interesați participanții la proiect de toate nivelurile.

Până la cel de-al cincilea nivel de maturitate al proceselor de testare a software-ului, nu sunt necesare instrumente speciale sau soluții integrate, spre deosebire de maturitatea proceselor de dezvoltare, unde instrumentele pentru colectarea și analiza cerințelor și controlul versiunilor, de exemplu, sunt conditie necesara atingerea unui anumit nivel de maturitate a procesului de dezvoltare în ansamblu. La al cincilea nivel al modelului TMMSW este posibilă utilizarea anumitor instrumente de analiză statistică a codului care permit rezolvarea uneia dintre sarcinile țintă ale acestui nivel de maturitate - prevenirea erorilor prin identificarea secțiunilor de cod care conțin erori logice în absența operatorilor de eliberare a resurselor sau a căutării. pentru variabile neutilizate sau matrice de memorie. Cu toate acestea, utilizarea unui instrument special nu este obligatorie nici la acest nivel; de exemplu, abordarea când există doi testeri per codator, dintre care unul este un dezvoltator de mai mulți nivel inalt- ocupat cu sarcinile de revizuire a codului critic, vă permit, de asemenea, să rezolvați problema prevenirii erorilor.

Utilizarea unor metodologii specifice sau urmarea oricăreia dintre metodologiile alese (RUP, MSF sau Scrum) nu garantează, de asemenea, atingerea calității produsului sau succesul proiectului, deoarece metodologia de dezvoltare software funcționează doar pentru un anumit tip de proiect. În mod similar, pentru procesul de testare software, nicio metodologie fără adaptare la condițiile unui anumit proiect nu oferă un rezultat garantat. Modelul de maturitate a procesului este tocmai practica atingerii anumitor niveluri de calitate a procesului care este interesant pentru aplicare, care este o structură de obiective și abordări pentru atingerea acestora, permițându-vă să utilizați „în interior” o metodologie de dezvoltare aproape arbitrară (cu adaptare corespunzătoare) și un set de instrumente. Modelul explică „ce și cum” să faci, dar nu „ce și în ce ordine”.

Practică

Prin punerea în practică a recomandărilor modelelor de maturitate ale procesului de testare, compania nu numai că poate vedea progrese în formatul metricilor colectate, dar poate simți cu adevărat schimbările calitative în modul de lucru în sine. Există mai multe semne ale schimbărilor de proces care sunt resimțite atât de conducere și membrii echipei, cât și de clienții și consumatorii produsului în curs de dezvoltare.

Proces controlat în timp de lansare a versiunilor cu un anumit nivel de calitate. Nu vorbește despre calitatea ideală a produsului fabricat sau absenta totala defecte - vorbim de încredere în starea versiunii lansate, atât din partea echipei de proiect, cât și a echipei de testare.

Regularitate și repetabilitate previzibilă a tuturor etapelor proiectului.În condițiile nivelurilor inițiale de maturitate ale proceselor de testare a software-ului, activitățile de testare urmează ca etapa finală a muncii și adesea „sufer” din cauza timpului limitat și a lipsei de resurse, ceea ce afectează direct stabilitatea versiunilor lansate și calitatea acestora. Odată cu trecerea la niveluri superioare ale modelului de maturitate a procesului de testare, activitățile de testare sunt din ce în ce mai integrate în dezvoltarea și lansarea versiunilor de produs, ceea ce afectează pozitiv alocarea resurselor și a timpului necesar pentru finalizarea lucrării.

O schimbare a unui astfel de indicator calitativ care caracterizează procesul de dezvoltare și lansare a software-ului, ca numărul de defecte găsite după lansarea versiunii produsuluiîn operaţie experimentală sau chiar de producţie. Acest indicator este foarte semnificativ pentru personalul managerial și serviciile. suport tehnic, care poate confirma dinamica pozitivă a îmbunătățirii calității software-ului prin efectuarea unei analize cantitative și calitative a cererilor înregistrate de la clienți sau utilizatori. Puncte pozitive, conform estimărilor noastre, sunt asociate cu îmbunătățiri practice în etapa de planificare și control al testării, deoarece defecțiunile deseori ratate sunt cauzate tocmai de lipsa de timp pentru planificarea și monitorizarea lucrărilor de testare efectuate.

Literatură

Terry Weatherill, În labirintul de modele de maturitate de testare. Journal of Software Testing Professionals, 2001.

Thomas Staab, Folosind SW-TMM pentru a îmbunătăți procesul de testare. Wind Ridge International.

Viaceslav Pankratov ([email protected] ) - CEO Compania QAExpert (Kiev, Ucraina).

Pe lângă standardele naționale și internaționale, există mai multe abordări ale certificării procesului de dezvoltare. Cele mai faimoase dintre ele din Rusia sunt, aparent, CMM și CMMI.

CMM (Capability Maturity Model) este un model de maturitate al proceselor de dezvoltare software, care este conceput pentru a evalua nivelul de maturitate al procesului de dezvoltare într-o anumită companie. Conform acestui model, există cinci niveluri de maturitate a procesului de dezvoltare. Primul nivel corespunde dezvoltării „cum merge”, când dezvoltatorii merg la fiecare proiect ca o performanță. Al doilea corespunde unor procese mai mult sau mai puțin bine stabilite, atunci când este posibil cu suficientă încredere să contam pe un rezultat pozitiv al proiectului. Al treilea corespunde prezenței proceselor dezvoltate și bine descrise utilizate în dezvoltare, iar al patrulea corespunde utilizării active a metricilor în procesul de management pentru stabilirea obiectivelor și monitorizarea realizării acestora. În cele din urmă, al cincilea nivel se referă la capacitatea companiei de a optimiza procesul după cum este necesar.

Cerințe CMM și CMMI

După apariția CMM, au început să se dezvolte modele de maturitate specializate pentru crearea sistemelor informaționale, pentru procesul de selectare a furnizorilor și altele. Pe baza acestora, a fost dezvoltat un model integrat CMMI (Capability Maturity Model Integration). În plus, s-a încercat în CMMI să depășească neajunsurile CMM care se manifestase până atunci - o exagerare a rolului descrierilor formale ale proceselor, când prezența anumitor documentații era apreciată mult mai mult decât doar una bine stabilită, dar nu procesul descris. Cu toate acestea, CMMI se concentrează și pe utilizarea unui proces foarte formalizat.

Astfel, baza modelelor CMM și CMMI este formalizarea procesului de dezvoltare. Acestea vizează dezvoltatorii să implementeze un proces descris în detaliu în regulamente și instrucțiuni, care, la rândul lor, nu pot decât să necesite dezvoltarea unei cantități mari de documentație de proiect pentru un control și raportare adecvate.

Relația dintre CMM și CMMI cu dezvoltarea iterativă este mai indirectă. În mod oficial, niciunul dintre ei nu a propus cerințe specifice pentru aderarea la o abordare în cascadă sau iterativă. Cu toate acestea, potrivit unor experți, CMM este mai compatibil cu abordarea în cascadă, în timp ce CMMI permite și o abordare iterativă.

Desigur, RUP este o metodologie iterativă. Deși formal execuția obligatorie a tuturor fazelor sau un număr minim de iterații nu este indicată nicăieri în RUP, întreaga abordare este axată pe faptul că există destul de multe. Numărul limitat de iterații nu vă permite să profitați din plin de RUP. În același timp, RUP poate fi folosit și în proiecte aproape în cascadă, care includ într-adevăr doar câteva iterații: una în faza de construire și cealaltă în faza de transfer. Apropo, acesta este numărul de iterații care este de fapt utilizat în proiectele cu cascadă. La urma urmei, testarea și operațiune de probă sisteme presupune efectuarea de corecții, care pot implica anumite activități legate de analiză, proiectare și dezvoltare, adică, de fapt, sunt o trecere în plus prin toate fazele de dezvoltare.

Metodologia RUP

În ceea ce privește formalitatea metodologiei, RUP prezintă utilizatorului o gamă foarte largă de posibilități. Dacă faceți toate lucrările și sarcinile, creați toate artefactele și destul de formal (cu un evaluator oficial, cu pregătirea unei revizuiri complete sub forma unui document electronic sau pe hârtie etc.) efectuați toate revizuirile, RUP poate întoarce a fi o metodologie extrem de formală, grea. În același timp, RUP vă permite să dezvoltați doar acele artefacte și să efectuați numai acele lucrări și sarcini care sunt necesare într-un anumit proiect. Și artefactele selectate pot fi executate și revizuite cu un grad arbitrar de formalitate. Este posibil să se solicite un studiu detaliat și o execuție atentă a fiecărui document, furnizarea unei revizuiri la fel de atent executate și formalizate și chiar, urmând vechea practică, să se aprobe fiecare astfel de revizuire la consiliul științific și tehnic al întreprinderii. Sau vă puteți limita la un e-mail sau o schiță pe hârtie. În plus, mai există întotdeauna o posibilitate: să formezi un document în capul tău, adică să te gândești la problema relevantă și să iei o decizie constructivă. Și dacă această decizie vă privește numai pe dvs., atunci limitați-vă, de exemplu, la un comentariu în codul programului.

Astfel, RUP este o metodologie iterativă cu o gamă foarte largă de soluții posibile în ceea ce privește formalizarea procesului de dezvoltare.

Să rezumam partea a doua a articolului. RUP, spre deosebire de majoritatea celorlalte metodologii, vă permite să alegeți gradul de formalizare și iterare a procesului de dezvoltare într-o gamă largă, în funcție de caracteristicile proiectelor și de organizația în curs de dezvoltare.

Și de ce acest lucru este atât de important - vom discuta în partea următoare.

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; pe piaţa muncii a specialiştilor calificările necesare clar nu suficient. Totodata, in domeniul imbunatatirii proceselor tehnologice de dezvoltare si operare software, experienta internationala ani lungi a fost insuficient generalizată şi formalizată. 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. a lui starea curenta;

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

firme de consultanta implicate in restructurarea companiilor si a furnizorilor de servicii tehnologia Informatieiș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 structuri organizatoriceși determină tacticile și strategia de producție. Introducerea lor în drept implică necesitatea de a construi infrastructura necesară și de a crea cultura de producție corporativă necesară care să asigure că metodele, operațiunile și procedurile adecvate pentru a face afaceri sunt menținute 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 material metodic, definirea regulilor de formare a unui sistem de management pentru crearea și întreținerea software-ului și a metodelor de îmbunătățire treptată și continuă a culturii de producție. Scopul CMM este de a oferi organizațiilor de dezvoltare instrucțiunile necesare pentru alegerea unei strategii de îmbunătățire a calității proceselor prin analiza gradului de maturitate tehnologică a acestora și a factorilor care afectează 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 creare a software-ului se reflectă în planuri strategice organizație, 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ă, baza, fundația pentru analiza comparativa niveluri 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ță al managementului și de nivelul profesional al interpreților. 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. Cu absenta nivelul cerut managementul de proiect, chiar și tehnologia avansată nu poate 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. Capacitate de antrenament şi profesioniști cunoscătoriîn organizații este principala condiție prealabilă pentru succes la toate nivelurile de maturitate, dar la primul nivel este singura oportunitate de a obține cel puțin orice rezultat pozitiv.

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 CMM conține 18 astfel de grupuri, cea mai recentă versiune a modelului CMMI conține 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. Pe măsură ce proiectele cresc și devin mai complexe, atenția se schimbă de la aspecte tehnice implementarea lor pe aspecte organizatorice si 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 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 de a ajuta managementul și specialisti 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 a acestuia, datele de intrare, standardele și procedurile de execuție, mecanismele de verificare (de exemplu, opiniile experților), 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 analiza cantitativă ș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 interna reprezintă 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 tehnologii organizatorice, 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.

ultima versiune CMM 1.1 se adresează în principal companiilor mari implicate în implementarea proiectelor mari, dar poate fi folosit și de grupuri de două sau trei persoane sau programatori individuali pentru a finaliza proiecte mici (până la trei luni). În astfel de cazuri, modelul CMM poate juca un rol vital, deoarece 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. Acest 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, precum prototipul, metodele formale și structurale, instrumentele 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. Companiile mai mici consideră acest model 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ă linie separatăîn bugetul organizaţiei şi defineşte 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 prezintă relația dintre diferitele tipuri de sisteme software și procesele de îmbunătățire a dezvoltării acestora.

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

Cunoașterea tipului de produs dezvoltat va face corespondența între sisteme 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 administratie speciala proces de îmbunătățire, ca și în crearea unor sisteme cu viață lungă.

Mulți procese tehnologice au în prezent suport CASE, deci pot fi apelați 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, mijloace standard suport (instrumente de prototipare, compilatoare, instrumente de depanare, procesoare de text 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 dezvoltă propriile tehnologii pentru crearea de software, uneori aceste tehnologii devin disponibile public ș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ă bunul simț sugerează altfel. 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ă, iar pe de altă parte, intenționează să intre pe viitor la nivel internațional, unde certificarea SMM este foarte de dorit.

În 1982, Departamentul de Apărare al SUA a format o comisie a cărei sarcină principală era să studieze problemele care apar în dezvoltarea produselor software în organizațiile departamentului. Ca urmare a activităților comisiei, Institutul de Inginerie Software (SEI) a fost înființat în decembrie 1984 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 identificarea gradului de maturitate al proceselor (pentru independente, 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 instrument de selectare a celor mai buni furnizori de software pentru a onora comenzile guvernamentale. Pentru a face acest lucru, trebuia să creeze criterii pentru evaluarea maturității proceselor cheie ale companiei dezvoltatoare și să determine setul de acțiuni necesare pentru îmbunătățirea lor ulterioară. Ca urmare, metodologia s-a dovedit a fi extrem de utilă pentru majoritatea companiilor care doresc să se îmbunătățească calitativ procesele existente proiectarea, dezvoltarea, testarea instrumentelor software și reducerea managementului 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. Aplicația sa permite plasarea dezvoltării software pe o bază industrială, sporind controlabilitatea proceselor cheie și a culturii de producție în general, garantând lucrări de înaltă calitate și execuție a proiectelor la timp. La baza creării CMM a stat poziția de bază conform căreia problema fundamentală a „crizei” procesului de dezvoltare a software-ului de calitate nu este lipsa de noi metode și instrumente de dezvoltare, ci incapacitatea companiei de a organiza și gestiona procesele tehnologice.

Pentru a evalua gradul de pregătire a întreprinderii de a dezvolta o calitate software HMM introduce conceptul cheie maturitatea organizatiei(Maturitate). imatur O organizație este considerată a fi:

nu există o planificare pe termen lung și de proiect;
procesul de dezvoltare a software-ului și componentele sale cheie nu sunt 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 metricile dezvoltate;
procesul de elaborare a unei soluții are loc spontan, în pragul art.

În acest caz, există o mare probabilitate de probleme neașteptate, depășirea bugetului sau nerespectarea termenelor pentru proiect. Într-o astfel de companie, de regulă, managerii și dezvoltatorii nu gestionează procesele - sunt forțați să se ocupe de rezolvarea problemelor curente și care apar spontan. Rețineți că pe această etapă dezvoltarea este majoritatea companiilor rusești.

Caracteristici principale matur organizatii:

compania are proceduri bine 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;
au actualizat standarde externe și au creat standarde interne pentru procese cheieși proceduri;
sunt obligatorii pentru toate regulile de proiectare a programului metodologic și a documentației utilizatorului;
tehnologiile variază ușor de la proiect la proiect pe baza unor abordări și metodologii stabile și dovedite;
experiența organizatorică și de producție acumulată în proiectele anterioare, modulele de programe, bibliotecile de software sunt utilizate la maximum;
noile tehnologii sunt testate și introduse în mod activ, eficacitatea lor este evaluată.

SMM definește cinci niveluri maturitatea tehnologică a companiei, conform căreia clienții pot evalua potențialii solicitanți pentru un contract, iar dezvoltatorii pot îmbunătăți procesele de dezvoltare software.

Fiecare dintre niveluri, cu excepția primului, este format din mai multe domenii cheie de proces(Procesul cheie