Produse software. Modele de maturitate ale procesului de testare prin SMM Software System Design Maturity Model

05.04.2007 Viaceslav Pankratov

Astăzi se vorbește mult despre calitate. softwareși sistemele informaționale, se efectuează studii 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?

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, de exemplu, să evaluăm și să măsurați eficacitatea uneia sau alteia metode de dezvoltare, dacă practic nu există proiecte de dezvoltare pentru două identice sisteme software, și cu atât mai mult, nu există două echipe de dezvoltare identice în ceea ce privește experiența și abilitățile? 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 model de maturitate a procesului de dezvoltare software (Maturitatea capacității Model for Software, CMM), care a fost ulterior dezvoltat în CMMI (Capability Maturity Model Integration), un certificat de facto al nivelului de maturitate al procesului 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.

Testează modelul de maturitate

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 testării (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 testului, raportul dintre scenariile de testare și cerințele funcționale etc.), care sunt colectate. și analizate în etapa de descriere a procesului existent.

Dintre 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 au devenit populare în primul rând datorită simplității lor, precum și a practicilor propuse. audituri interne, care poate fi produs 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 abordează treptat 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 extensie și 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 ciclul de viață al dezvoltării 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 astfel de metrici de calitate precum fiabilitatea, capacitatea 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 - un dezvoltator de nivel superior - este ocupat cu sarcinile de revizuire a codului critic, ne permite, de asemenea, să rezolvăm 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 este vorba despre calitatea ideală a produsului lansat sau despre absența completă a defectelor - este vorba despre încrederea în starea versiunii lansate, atât din partea echipei de proiectare, 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 de management și serviciile de suport tehnic, care pot confirma dinamica pozitivă de îmbunătățire a nivelului calității software-ului prin efectuarea unei analize cantitative și calitative a solicitărilor î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).

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

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

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

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

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

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

Orez. 5.3. Cinci niveluri de maturitate a modeluluiSMM

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

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

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

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

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

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

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

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

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

Structura CMM

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

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

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

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

Astfel, nivelurile formează o „scara” de-a lungul căreia organizația se ridică pe măsură ce se dezvoltă. Fiecare nivel este caracterizat de o anumită compoziție și proprietăți ale proceselor organizației. SMM „Scara de nivel” a fost acceptată și diseminată pe scară largă. Iată cum arată ea.

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

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

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

Nivelul 4 „Gestionat”. Sunt colectați indicatori cantitativi detaliați ai procesului de producție și a calității produsului creat. Atat procesul de fabricatie cat si produsele sunt evaluate si controlate din punct de vedere cantitativ.

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

În ciuda lipsei de rigoare, definiția de mai sus intuitiv, cel mai adesea, nu ridică obiecții. În plus, specialiștii cu experiență înțeleg de ce tranzițiile sunt posibile doar la nivelul următor, precum și de ce merită să te străduiești pentru o astfel de tranziție. În același timp, modelul HMM nu conține nicio fundamentare cantitativă sau chiar formală a unei astfel de demersuri, ceea ce, însă, nu îi scade meritele.

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

Orez. 7.1.

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

grup 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 un grup de procese cheie " Managementul Cerintelor„(Vezi Figura 7.2) scopul este de a reconcilia cerințele proiectului de dezvoltare software între client și dezvoltator.”

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

Orez. 7.2.

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

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

Goluri. Obiectivele din CMM nu sunt asociate cu procese, ci cu grupuri de procese cheie. După cum sa menționat mai sus, obiectivele sunt atinse prin implementarea practicilor cheie. În CMM, atingerea scopului înseamnă că, în primul rând, după implementarea practicilor cheie, se obține rezultatul dorit și, în al doilea rând, se obține destul de consistent. Modul în care sunt atinse obiectivele Grupului de proces cheie poate diferi de la proiect la proiect datorită diferențelor de domeniul subiectului sau mediu.

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

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

Obligații de executare

Descrieți acțiunile pe care organizația trebuie să le întreprindă pentru a se asigura că procesul este stabilit și stabil. Obligațiile de performanță se referă de obicei la stabilirea politicilor organizaționale și a sprijinului din partea managementului de vârf.

Cerințe preliminare

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

Operațiuni în curs

Secțiunea Operațiuni în curs descrie munca de fond care trebuie efectuată la acest nivel. Operațiunile efectuate includ de obicei crearea de planuri și implementarea de operațiuni specifice, executarea și urmărirea lucrărilor și luarea de măsuri corective, după cum este necesar.

Măsurători și analize

Secțiunea „Măsurători și

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

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

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

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

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

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

Liderii unor astfel de organizații nu sunt întotdeauna capabili să-și formeze o strategie de îmbunătățire și dezvoltare a tehnologiei activităților companiei lor; în mod clar nu există destui specialişti pe piaţa muncii cu calificările necesare. 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 în restructurarea companiilor și 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 SMM este de a oferi organizațiilor de dezvoltatori instructiunile necesare asupra alegerii unei strategii de imbunatatire a calitatii proceselor prin analiza gradului de maturitate tehnologica a acestora si a factorilor care afecteaza cel mai mult calitatea produselor. Concentrându-se pe un număr mic dintre cele mai critice operațiuni și îmbunătățind sistematic eficiența și calitatea executării acestora, o organizație poate astfel obține o îmbunătățire continuă constantă a culturii de creare și întreținere a software-ului.

CMM este un model descriptiv în sensul că descrie atributele esențiale (sau cheie) care determină la ce nivel de maturitate tehnologică se află o organizație. Este un model normativ în sensul că o descriere detaliată a metodologiilor stabilește nivelul de organizare necesar pentru realizarea proiectelor de complexitate și durată variată în cadrul contractelor cu agențiile guvernamentale SUA. CMM nu este o prescripție, nu prescrie cum ar trebui să se dezvolte o organizație. CMM descrie caracteristicile organizației pentru fiecare nivel de maturitate tehnologică, fără a oferi instrucțiuni cu privire la modul de trecere de la un nivel la altul. O organizație poate dura câțiva ani pentru a trece de la primul la al doilea nivel și foarte puțin timp pentru a trece de la un nivel la altul. Procesul de îmbunătățire a tehnologiei de 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 acestora pe proiecte-pilot și acordarea lor de statut de standarde de întreprindere.

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 avut ca scop 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 software. 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. Este posibil să identificăm mai multe tipuri comune procese de perfecţionare.

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 sistemele software și procesele de îmbunătățire prezentate în Fig. 1.8 util în alegerea îmbunătățirii procesului. De exemplu, trebuie să creați un program care să sprijine tranziția software-ului de la o platformă de computer la alta. Un astfel de program are o durată de viață destul de scurtă, astfel încât dezvoltarea sa nu necesită standarde și 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 asistență 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.

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

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

CMM/CMMI

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

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

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

Tabelul 1. Straturi model CMM

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

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

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

Tabelul 2. Dezvoltarea standardelor CMM

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

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

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

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

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

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

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

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