05.04.2007 Viaceslav Pankratov

Astăzi se vorbește mult despre calitate softwareȘi sisteme de informare, se efectuează cercetări pentru a demonstra relația dintre calitatea și eficiența proceselor automate de afaceri. Calitatea software-ului este transformată dintr-un concept abstract și intangibil într-o metrică cuprinzătoare pentru evaluarea unei soluții software, a proiectului de implementare a acesteia, a procesului de creare și a nivelului de utilizare a sistemelor informaționale în general. De ce depinde calitatea programelor și cum o puteți influența?

Astăzi se vorbește mult despre calitatea software-ului și a sistemelor informaționale și se fac studii care demonstrează relația dintre calitatea și eficiența proceselor automate de afaceri. Calitatea software-ului este transformată dintr-un concept abstract și intangibil într-o metrică cuprinzătoare pentru evaluarea unei soluții software, a proiectului de implementare a acesteia, a procesului de creare și a nivelului de utilizare a sistemelor informaționale în general. De ce depinde calitatea programelor și cum o puteți influența?

Este evident că calitatea software-ului depinde direct de calitatea procesului său de producție. Prin gestionarea procesului de productie si monitorizarea indicatorilor de eficienta a tuturor etapelor tehnologice ale acestuia, puteti influenta calitatea produsului produs. Vorbind despre caracteristicile programelor, putem evidenția metrici cantitative ușor de înțeles și analizat, legate de calitatea codului programului (complexitatea ciclomatică a codului - complexitatea structurii modulului, de exemplu, numărul de rute independente în el); numărul de linii de cod clasificate ca artefacte ale depozitului de proiect etc.; teste (acoperirea ramurilor de cod și modulelor cu scripturi de testare, raportul dintre numărul de erori găsite înainte și după lansarea produsului, dinamica detectării erorilor etc.); care acoperă cerințele pentru conformitatea cu recomandările pentru interfețele aplicațiilor ș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. De fapt, cum, de exemplu, se poate evalua și măsura eficiența unei anumite metode de dezvoltare dacă practic nu există proiecte de dezvoltare a două sisteme software identice și, cu atât mai mult, nu există două echipe de dezvoltare identice ca experiență și abilități? Nu se poate judeca după rezultatul final: pe lângă condițiile procesului de producție a software-ului (metodologia utilizată, structura echipei de proiect, metodele de comunicare cu clientul), condițiile proiectului (termene limită, costuri și volume de resurse) variază adesea foarte mult. O examinare mai detaliată a procesului de testare software - componenta tehnologică a procesului de producție - relevă problema alegerii metricilor de eficiență a testării.

Pe lângă evaluarea 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 am răspuns la întrebările „cine” și „când”, trebuie să căutăm răspunsuri la întrebările „cum, cum”, „cum să măsurăm rezultatele”, „cum să controlăm”, „cum să lucrăm mai eficient”, de asemenea. ca „cum se gestionează și se dezvoltă procesul pe baza datelor și experienței obținute”.

În practica de zi cu zi - atunci când lucrează cu instrumente specifice - specialiș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 atinse ale procesului de dezvoltare a acestuia. Ca urmare, credința în puterea de softwareîmbunătățirea calității în practică devine baza deciziilor nefondate cu privire la introducerea de metodologii sau automatizarea proceselor de dezvoltare, începând cu implementarea unor soluții software specifice. Cu toate acestea, mijloacele moderne de automatizare a proceselor de dezvoltare sunt platforme atât de flexibile și personalizabile încât necesită un studiu preliminar aprofundat 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), certificatul de facto al maturității procesului de dezvoltare recunoscut în industria software. Prin analogie cu lumea dezvoltării software și cu modelele de maturitate existente ale proceselor acestora, să ne uităm la modelele de maturitate ale procesului de testare.

Testarea modelului 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, este posibil să se rezolve două sarcini principale ale dezvoltării procesului: înțelegerea și înregistrarea procesului curent de testare și identificarea zonelor care necesită îmbunătățiri. 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 modificări - orice structură sau modificări procedurale imposibil fără voința politică a conducerii. Pe lângă obținerea suportului managerial și a resurselor necesare, efectuarea de modificări în procesul de testare necesită o planificare atentă, ca orice altă activitate de proiect.

Consultantul de testare Terry Wetherill 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);

Evaluarea și testarea propusă a domeniilor cheie de proces SW-CMM (SW-CMM KPA).

Apoi au fost aduse modificări fundamentale la unele modele; Astfel, modelul TOM (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 descrierii procesului existent.

Dintre cele șase modele de maturitate pentru testarea software-ului, practicienii și consultanții evidențiază două: TMMSW, dezvoltat la Institutul de Tehnologie din Illinois și TPI, propus la Sogeti. Ambele modele s-au răspândit în primul rând datorită simplității lor, precum și a practicilor propuse audituri interne, care poate fi produs de specialiști dintr-o companie care a luat calea îmbunătățirii proceselor. Să luăm î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 utilizat deoarece, alături de ușurința de înțelegere și utilizare a practicilor, permite organizațiilor să efectueze evaluări pe cont propriu și se apropie treptat de obiectivele lor de dezvoltare, monitorizarea rezultatelor intermediare. În munca noastră, am ales și acest model, având în vedere impopularitatea practicii de a atrage competențe terțe în rândul companiilor IT autohtone (companiile încearcă să economisească proiecte de investitii, care sunt în esență 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ă, demonstrând disponibilitatea companiilor de a efectua în mod independent schimbările interne folosind proprii specialiști. Abordarea iterativă 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 schimbărilor de proces.

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 standardul ISO/IEC Std 12207, care vă permit să fiți supus unei certificări oficiale ș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 în formatul unui proiect dedicat de o scară mai mică decât implementarea CMMI în întreaga organizație (care economisește bani și asigură transparență); pe de altă parte, această abordare elimină costurile de adaptare și cuplare a mai multor modele. Vorbind despre relația particulară 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, ceea ce face mult mai ușor să motivați managementul să cheltuiască pe un proiect pentru implementarea schimbărilor de proces.

Modelul TMMSW oferă mai ușor planificarea, implementarea și monitorizarea procesului de îmbunătățire. Printre dezavantajele 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, oferă cinci niveluri de maturitate.

Nivelul 1 este haotic. Procesul de testare a software-ului este haotic, ceea ce este tipic pentru 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 este efectuată după ce codul este creat ș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 și practici de testare de bază. Obiective de nivel: definiți sarcinile de dezvoltare și testare, creați proceduri adecvate, inițiați procesul de planificare a testelor, înregistraț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 testării se bazează pe cerințe. Există o organizație de testare, iar testarea în sine este alocată activitate profesională. Obiective de nivel: evidențiați testarea în grup separatși să definească un program de pregătire tehnică, să integreze procesul de testare în ciclul de viață al dezvoltării și să supravegheze procesul de testare în sine.

Nivelul 4 - control și măsurare. Testarea este un proces măsurat și controlat. Procese critice examene(revizuirea) artefactelor proiectului (planuri și scripturi de testare, mesaje de eroare, rapoarte finale privind starea versiunii etc.) se referă la activitățile de testare. Produsul este testat pentru conformitatea cu parametri de calitate precum fiabilitatea, gradul de utilizare și mentenabilitatea. Cazurile de testare sunt înregistrate, stocate într-un sistem de management al testelor și pot fi reutilizate împreună cu seturile de date de testare. Defectele detectate nu sunt doar înregistrate, ci și analizate după criterii formale: criticitatea, „greutatea” defectului, importanța, durata de viață etc. Obiective de nivel: Implementarea programelor de revizuire critică și audit la nivel de organizație/diviziune în tandem cu un program de testare măsurată. Se evaluează calitatea produselor 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 este susceptibilă de schimbări, care în mod clar au un impact pozitiv asupra acesteia. Sunt implementate și utilizate practici de prevenire a erorilor și de control al calității. Testarea automată este utilizată ca abordare principală de testare. Proiectarea testelor, analiza rezultatelor obținute, prelucrarea descrierilor erorilor, precum și metricile legate de testare, sunt realizate folosind instrumente 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 subobiective, adică vă permit să operați nu numai cu sarcini de nivel înalt de management al calității procesului de dezvoltare a software-ului, ci și să formula sarcini operaționale pentru toți executanții din proiect. Monitorizarea și analiza implementării 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 îndelungată. Matricele ATR definesc activitățile și sarcinile care trebuie îndeplinite în fiecare etapă specifică de implementare a 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 propuse 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 mod special că controlul asupra proiectului pentru efectuarea modificărilor nu este atribuit unui grup dedicat 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 la toate nivelurile.

Până la cel de-al cincilea nivel de maturitate al proceselor de testare a software-ului, nu este necesară utilizarea oricăror 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 o 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 analize statistice cod care vă permite să rezolvați una 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 căutând variabile neutilizate sau matrice de memorie. Cu toate acestea, utilizarea unui instrument special nu este obligatorie nici la acest nivel; de exemplu, o abordare în care există doi testeri per codator, dintre care unul este un dezvoltator de mai mulți nivel inalt- angajat în sarcini critice de inspecție a codului, care ne permit, de asemenea, să rezolvăm problema prevenirii erorilor.

Aplicarea unor metodologii specifice sau urmarea oricăreia dintre metodologiile selectate (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 maturității procesului este tocmai ceea ce face interesantă aplicarea practicii atingerii anumitor niveluri de calitate a procesului, care reprezintă o structură de obiective și abordări pentru atingerea acestora, permițând utilizarea „în interiorul” unei metodologii de dezvoltare aproape arbitrare (cu adaptare corespunzătoare). ) și un set de instrumente. Modelul explică „ce și cum” să faci, dar nu „ce și în ce ordine”.

Practică

Punând în practică recomandările de testare a modelelor de maturitate a procesului, o companie poate nu numai să vadă progrese în formatul de metrici colectate, ci și să simtă cu adevărat schimbări calitative în modul de lucru în sine. Există mai multe semne de schimbări 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.

Un proces controlat în timp pentru lansarea versiunilor cu un anumit nivel de calitate. Nu este vorba de calitatea ideală a produsului lansat sau de absența completă a defectelor - vorbim despre încrederea în starea versiunii lansate, atât din partea echipei de proiect, cât și a grupului de testare.

Regularitate și repetabilitate previzibilă a tuturor etapelor proiectului.În condițiile nivelurilor inițiale de maturitate a proceselor de testare a software-ului, activitățile de testare urmează ca etapă finală a muncii și adesea „sufer” din cauza termenelor limitate și a lipsei de resurse, ceea ce afectează direct stabilitatea versiunilor lansate și calitatea acestora. Pe măsură ce treceți la nivelurile superioare ale modelului de maturitate a procesului de testare, activitățile de testare sunt din ce în ce mai integrate în procesul de dezvoltare și lansare a versiunilor de produs, ceea ce are un efect pozitiv asupra alocării resurselor și 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 descoperite după lansarea unei versiuni de produsîntr-un mod experimentat sau chiar operatiune de productie. Acest indicator este foarte semnificativ pentru management și servicii suport tehnic, care poate confirma cu fapte dinamica pozitivă a creșterii nivelului calității software-ului prin efectuarea unei analize cantitative și calitative a cererilor înregistrate de la clienți sau utilizatori. Aspectele pozitive, conform estimărilor noastre, sunt asociate cu îmbunătățiri practice în etapa de planificare și control al testării, deoarece defectele deseori ratate sunt cauzate tocmai de lipsa de timp pentru planificarea și controlul 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).

Calitatea produselor software este poate una dintre cele mai grave probleme din industria software. Calitatea este mult mai mult decât lipsa erorilor. Acesta presupune un set de caracteristici variate: fiabilitate, rezistență la hacking, adaptabilitate, compatibilitate, mentenanță, portabilitate, eficiență etc. Nu este de mirare că există o asemenea varietate de standarde de calitate în industria software.

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

CMM/CMMI

Probabil 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. Prima versiune oficială a standardului a fost lansată în 1993, deși lucrările la acesta au început mult mai devreme - principalele sale prevederi au fost publicate în 1986.

Succesul CMM a fost determinat de mai mulți factori. Acest standard a fost unul dintre primii care a luat inițial în considerare specificul creării de 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” se face și, prin urmare, a fost potrivit pentru diverse metodologii de dezvoltare și nu a impus nicio restricție privind standardele de documentare, instrumente, mediu. și limbi utilizate î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 la implementarea proiectelor comandate de acest departament.

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

Tabelul 1. Niveluri ale modelului CMM

Nivelul nr.	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	Repetitiv	Managementul configurației software.Asigurarea calității produselor software.Gestionarea contractelor contractante.Monitorizarea derulării proiectelor.Planificarea proiectelor software.Managementul cerințelor.
3	Hotărât	Evaluări experți Coordonarea interacțiunilor dintre echipele de proiect Ingineria produsului software Managementul software integrat Program de formare a personalului Definirea procesului organizațional Domeniul de aplicare al procesului organizațional
4	A reușit	Managementul calitatii software.Managementul proceselor bazat pe metode cantitative
5	Optimizabil	Managementul schimbării proceselor Managementul schimbării proceselor Prevenirea defectelor

Împărțirea pe niveluri și definirea KPA-urilor pentru fiecare 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), reflectând mai exact poziția sa într-o familie destul de mare de standarde.

Tabelul 2. Dezvoltarea standardelor CMM

Nume standard	Descriere
CMM de inginerie de sistem (SE-CMM)	Se concentrează pe probleme de inginerie de sisteme - dezvoltarea produsului (analiza cerințelor, proiectarea și integrarea sistemului 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 proprietare care necesită o asigurare înaltă a calității software-ului
Inginerie de securitate a sistemului CMM (SSE-CMM)	Se concentrează pe aspectele de securitate ale ingineriei software, asigură un proces de dezvoltare sigur, inclusiv siguranța membrilor echipei
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ă probleme legate de achiziționarea de produse software de la organizații externe
Dezvoltare integrată de produse CMM (IPD-CMM)	Servește ca mijloc de integrare a eforturilor de dezvoltare în toate fazele 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 sarcină destul de complexă și să-i încurce pe specialiștii organizațiilor care l-au întâlnit.

De asemenea, o problemă semnificativă a CMM este necesitatea de a „alinia” toate procesele. Dacă o organizație încearcă să fie certificată la un anumit nivel, atunci trebuie să se asigure că toate procesele sale sunt la nivelul corespunzător. Chiar dacă specificul, metodologia sau caracteristicile de dezvoltare nu permit implementarea anumitor procese, 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 certificată la un nivel înalt în conformitate cu CMM ar trebui să ofere performanțe mai mari ale produselor software în comparație cu cele certificate la niveluri inferioare, standardul a devenit folosit ca criteriu de selecție pentru participarea la licitații de dezvoltare software sau proiecte de externalizare. Cererea de organizații certificate a dat naștere unei propuneri de „certificare rapidă și nedureroasă”.

Această situație a fost posibilă din cauza deficiențelor în procesul 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 „model” 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 acel nivel de standard.

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

Pentru a elimina nevoia de a „alinia” procesele unei organizații și de a fi mai adaptat nevoilor sale de business, și nu invers, standardul CMMI are două forme de prezentare - cea clasică, multi-nivel, corespunzătoare CMM, și noul , continuu. Forma continuă de prezentare nu ia în considerare nivelurile de maturitate, ci mai degrabă nivelurile de capacitate, care sunt evaluate pentru zonele individuale de proces (PA). În tabel 3 prezintă corespondența dintre nivelurile de maturitate ale standardului CMM, precum și nivelurile de maturitate ale vizualizării pe mai multe niveluri CMMI și nivelurile de capacitate de vizualizare continuă CMMI.

SEI se îndepărtează de CMM și, în schimb, promovează activ CMMI, 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: în conditii moderne prezența unui certificat de un anumit nivel de CMM/CMMI nu este un factor atât de important ca acum câțiva ani și este acceptat fără întrebări suplimentare, cu excepția proiectelor realizate în baza comenzilor guvernamentale.

În noiembrie 1986, Institutul de Inginerie Software (SEI) și Mitre Corporation au început să dezvolte un studiu privind maturitatea procesului de dezvoltare a software-ului care a fost menit să ajute la îmbunătățirea proceselor lor interne.

Dezvoltarea acestei revizuiri a fost determinată de o solicitare din partea guvernului federal al SUA de a oferi o metodă de evaluare a subcontractanților de dezvoltare de software. Adevărata problemă a fost incapacitatea de a gestiona proiecte mari. În multe companii, proiectele au fost finalizate semnificativ cu întârziere și peste buget. A fost necesar să se găsească o soluție la această problemă.

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

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

Dezvoltare

Folosirea modelului în practică a relevat ambiguitatea în abordările pentru atingerea unor niveluri mai înalte de organizare a proceselor de dezvoltare software. Prin urmare, până în 2002, au fost elaborate recomandări pentru îmbunătățirea procesului de dezvoltare, care sunt numite CMMI (Capability Maturity Model Integration). În prezent, cea mai recentă versiune a CMMi este 1.3 (publicată în noiembrie 2010).

Vezi si

Legături

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

Vedere versiunea completa: Simularea sistemelor de control

Am rezolvat toate modulele, am trecut totul cu un 4, iar finalul cu un 2, acum în trei zile voi încerca să o iau din nou, nu a fost o singură întrebare identică. Am încercat să corectez testul final, dar verifică-l, nu pot garanta acuratețea lui. Vă prezint tot ce am, poate cineva va trece mai bine decât mine. Dacă cineva are o a doua sau a treia încercare, dacă nu te superi, stabilește disciplina, este foarte dificil.:eek:

Testul final 100 din 100

rezultatul final este diferit de fiecare dată?

Sunt mai multe întrebări care nu sunt enumerate aici și care mi-au venit. Nu am căutat răspunsurile, pentru că fără el am trecut cu 4. Oricine vrea să se bată, încarcă aici răspunsurile pentru alții :)

Modulul 1:
Ce nu ar trebui să fie considerat o trăsătură distinctivă a unui proces de afaceri?

Creșterea valorii

Selectați un răspuns:
Un produs de proces care întruchipează obiectivele stabilite anterior

Selectați un răspuns:

În finală (trecut la 4.

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

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

2. Ce nu este un element al unei diagrame universale a structurii procesului de afaceri?
Selectați unul sau mai multe răspunsuri:
Resurse de proces
Riscuri
Activitati de management al proceselor de afaceri
Factori Mediul extern
Activități de transformare a intrărilor în ieșiri

3. Resursele materiale ca element de bază al proceselor sunt:
Selectați un răspuns:
Subiecți activi de activitate uniți în sisteme care interacționează între ei și alte resurse
Controlează influențele direcționate de subiecții de activitate către obiectele de activitate, determinând scopurile și rezultatele proceselor
Mijloace pasive și obiecte de activitate utilizate pentru a efectua procese (NECER)

28.03.2014, 10:07

Modulul 1:
Ce nu ar trebui considerat o caracteristică distinctivă a unui proces de afaceri? Selectați unul sau mai multe răspunsuri:
Conversia intrărilor în ieșiri
Livrarea produsului către consumatori externi
Creșterea valorii
Formarea plusului și/sau a valorii de utilizare

Rezultatele ca elemente de bază ale proceselor sunt:
Selectați un răspuns:
Subiecți activi de activitate uniți în sisteme care interacționează între ei și alte resurse
Un produs proces care întruchipează scopurile stabilite anterior.Mijloace pasive și obiecte de activitate utilizate pentru realizarea proceselor.
Un set de obiecte materiale, energetice și informaționale necesare pentru finalizarea procesului

Ce este feedback-ul în cadrul unui proces de afaceri?
Selectați un răspuns:
Influență intenționată și conștientă asupra procesului, menită să asigure rezultatul dorit
Analiza și compararea rezultatelor procesului cu obiectivele stabilite anterior
Impactul asupra sistemului al obiectelor și al factorilor de mediu care sunt surse ale diferitelor tipuri de abateri în funcționarea sistemului
Asa am raspuns! dar tot a iesit 4

În rezumat - Aceste întrebări + cele care există deja:
1 Selectați din listă dezavantajele structurilor proiectare-țintă.

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

3 Selectați din listă condițiile de utilizare a structurilor organizatorice organice.
Lucrătorii sunt motivați de nevoi complexe
Obiectivele sunt vagi și se schimbă dinamic
Autoritatea este chestionată și testată și necesită confirmarea subordonaților

4 Selectați din listă avantajele structurilor organizaționale bazate pe proiecte.
subordonarea directă a angajaților față de managerul de proiect și obținându-se astfel neambiguitatea în direcția eforturilor acestor angajați

5 procese suport:
Asigurarea implementării eficiente a proceselor de bază

Scorul final 5
Intrebarea 1
Selectați exemple de utilizare a comenzilor din listă.

Căni de calitate
Comitete
Echipe de lucru

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

Să integreze activitățile diferitelor divizii structurale

Întrebarea 3
Numiți tipurile de relații din modelul SADT:
Control
Mecanism de ieșire
Părere prin intrare

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

Întrebarea 5
Ce metode, metodologii și instrumente pot fi folosite pentru a crea modele informaționale ale proceselor de afaceri?

Metodologia Gain-Sarson
Limbajul de modelare Chen și Barker

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

Operațiuni de proces de afaceri

Întrebarea 7
Durata procesului de afaceri:

Reprezintă o caracteristică subiectivă

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

Mijloace și obiecte de activitate pasive utilizate pentru realizarea proceselor

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

Se implementează subordonarea directă a angajaților față de managerul de proiect și astfel se realizează focalizarea neechivocă a eforturilor acestor angajați.

Întrebarea 10
Selectați din listă avantajele structurilor organizaționale matriceale.

Devine posibilă „personalizarea” flexibilă a structurii organizaționale într-o gamă largă: de la matrice slabă la matrice puternică

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

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

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

Ieșire
proces
Intrare
Perturbare

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

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

Mediu spre ridicat

Întrebarea 15
Ce poate fi considerat printre elementele principale ale proceselor investiționale și financiare?

Investitorii
Creditorii

Întrebarea 16
Selectați din listă dezavantajele structurilor de proiectare-țintă.

Fabricabilitate redusă în zonele funcționale

Modelarea sistemelor de control.rar (http://mti.prioz.ru/krfilesmanager.php?do=downloadfile&dlfileid=107)

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

ajuta 3instruirea cine are plz

Adăugat după 1 minut
Cer 3 training care au Modelare sisteme de control

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

Traducere: zCarot

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

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

Carnegie Mellon (Institutul de inginerie software, SEI) a creat Modelul de maturitate a capacității pentru dezvoltarea de produse software. De-a lungul timpului, a fost lansată o întreagă familie de modele:

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

Diferitele modele s-au dovedit a fi destul de complexe de înțeles și implementat. Deoarece au fost create de diferite grupuri de specialiști, conținutul acestor modele nu a fost întotdeauna în concordanță între ele, precum și cu

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

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

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

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

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

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

De exemplu, industria aviației și industria aerospațială. Adică dezvoltarea de software

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

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

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

maturitatea procesului (fig. 1).

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

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

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

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

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

Modele de ciclu de viață, software, practici etc. Orice proces specific este obținut prin eliminarea acestui standard.

Nivel controlat cantitativ(nivel de maturitate 4) presupune apariția unui sistem de măsurare în companie, care are loc pe baza unui proces standard și permite managementul cantitativ al dezvoltării.

Nivel de optimizare(nivelul de maturitate 5) presupune îmbunătățirea continuă a proceselor de dezvoltare, atât treptate, pas cu pas, cât și revoluționare. Mai mult, aceste schimbări nu sunt forțate, ci probleme și dificultăți proactive. Procesul este îmbunătățit pe cont propriu și în mod constant, au fost implementate mecanisme adecvate.

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

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

Model de maturitate a capacității (CMM)

Este curios că recomandările acestui model sunt destul de universale și nu sunt „limitate” doar la tehnologia informației. Implementarea pilot a practicilor acestui model a avut loc... într-unul dintre spitalele din SUA (la urma urmei, îngrijirea medicală este tot un serviciu).

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

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

Organizațiile care lucrează în domeniul dezvoltării, livrării, implementării și întreținerii software-ului și integrării sistemului simt din ce în ce mai mult că baza competitivității lor este calitatea, costul scăzut și fabricabilitatea producției.

Șefii unor astfel de organizații nu pot formula întotdeauna o strategie de îmbunătățire și dezvoltare a tehnologiei activităților companiei lor; În mod clar nu există destui specialiști cu calificările necesare pe piața muncii. Totodata, experienta internationala in domeniul imbunatatirii proceselor tehnologice pentru dezvoltarea si operarea software-ului ani lungi nu a fost suficient de 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), definind nivelurile de maturitate tehnologică și trăsăturile distinctive ale acestora. De-a lungul unui deceniu, SMM a fost testat într-un număr de organizații, eficacitatea și fiabilitatea sa au fost testate de organizații de comandă, furnizori de software, companii care dezvoltă software personalizat și programare offshore.

Astăzi, în Occident, o companie de dezvoltare practic întâmpină mari dificultăți în primirea comenzilor dacă nu este certificată conform CMM. Clienții solicită garanții ale eficienței tehnologice a companiei performante, garanții că antreprenorul nu poate oferi servicii de calitate scăzută.

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

· de către client la selectarea celor mai performanti (de exemplu, într-o licitație);

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

· companiile care decid să se supună certificării pentru a evalua „mărimea dezastrului”, i.e. starea ta actuală;

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

· firme de consultanta implicate in restructurarea companiilor si a serviciilor furnizorilor tehnologia Informatieiși servicii conexe.

Pe măsură ce maturitatea tehnologică a unei organizații crește, procesele de dezvoltare și întreținere software devin mai standardizate și mai consistente. În același timp, formalizarea proceselor ne permite să standardizăm rezultatele așteptate ale implementării acestora și să asigurăm predictibilitatea rezultatelor proiectului.

Maturitatea procesului software- acesta este gradul de controlabilitate, controlabilitate și eficiență a acestora. Creșterea maturității tehnologice semnifică potențialul de creștere a durabilității proceselor și indică gradul în care procesele de creare și întreținere a software-ului sunt utilizate în mod eficient și consecvent în întreaga organizație. Utilizarea efectivă a proceselor este imposibilă fără documentarea acestora și aducerea lor în atenția personalului organizației, fără monitorizarea și îmbunătățirea constantă a implementării lor. Capacitățile proceselor bine concepute sunt complet definite. Creșterea maturității tehnologice a proceselor înseamnă că eficiența și calitatea rezultatelor acestora pot crește constant.

În organizațiile care au atins maturitatea tehnologică, procesele de creare și întreținere a software-ului capătă statutul de standard și sunt înregistrate în structuri organizatoriceși determină tacticile și strategia de producție. Introducerea lor în lege presupune necesitatea construirii infrastructurii necesare și crearea celei necesare cultură corporatistă producții care asigură că metodele, operațiunile și procedurile de afaceri adecvate sunt menținute chiar și după ce cei care le-au creat toate părăsesc organizația.

Modelul CMM dezvoltă prevederi privind sistemul calității organizației, formând criterii pentru excelența acesteia - 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 - sunt 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 progrese în domeniul creării și întreținerii software.

SMM reprezintă material metodologic, care definește regulile de formare a unui sistem de management pentru crearea și întreținerea software-ului și metodele de îmbunătățire treptată și continuă a culturii de producție. Scopul SMM este de a oferi organizațiilor de dezvoltare instructiunile necesare asupra alegerii unei strategii de imbunatatire a calitatii proceselor prin analiza gradului de maturitate tehnologica a acestora si a factorilor care influenteaza cel mai mult calitatea produselor. Concentrându-se pe un număr mic dintre cele mai critice operațiuni și sporind sistematic eficiența și calitatea implementării acestora, organizația poate astfel obține o îmbunătățire constantă și continuă 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 tehnicilor stabilește nivelul de organizare necesar pentru realizarea proiectelor de complexitate și durată variată în cadrul contractelor cu agențiile guvernamentale SUA. SMM nu este o prescripție; nu prescrie cum ar trebui să se dezvolte o organizație. CMM descrie caracteristicile unei organizații 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 planurile strategice ale organizației, structura acesteia, tehnologiile utilizate, cultura socială generală și sistemul de management.

La fiecare nivel se stabilesc cerințe, a căror îndeplinire asigură stabilizarea celor mai semnificativi indicatori de proces. Atingerea fiecărui nivel de maturitate tehnologică este rezultatul apariției unui anumit număr de componente în procesele de creare a software-ului, ceea ce duce la rândul său la o creștere a productivității și calității acestora. În fig. Figura 1.7 prezintă cinci niveluri de maturitate tehnologică SMM.

Orez. 1.7. Cinci niveluri de maturitate tehnologică SMM

Inscripțiile de pe săgeți determină caracteristicile de îmbunătățire a proceselor atunci când se deplasează 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țiuni care alcătuiesc procesele de creare a software-ului în sine. În acest caz, primul nivel este ca o bază, o fundație pentru analiza comparativa niveluri superioare.

La nivelul 1 (inițial), principalele procese de creare și întreținere a software-ului sunt de natură aleatorie și sunt efectuate haotic. 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, de regulă, depinde în întregime de gradul de energie și experiență a managementului și de nivelul profesional al interpreților. Se poate întâmpla ca un manager energic să depășească toate obstacolele în cursul unui 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, garanția că următorul proiect similar va avea succes va dispărea. În absența nivelului necesar de management al proiectelor, nici măcar tehnologia avansată nu va putea salva situația.

Procesele de la primul nivel se caracterizează prin imprevizibilitatea lor datorită faptului că compoziția, scopul și succesiunea lor în timpul implementării 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 specialiş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 rezultate pozitive.

La Nivelul 2 (nivelul procesului repetabil), procesele de management al proiectelor asigură controlul continuu asupra costurilor proiectului, programelor și funcțiilor efectuate. Disciplina implementării proiectelor 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. Principala caracteristică a celui de-al doilea nivel este prezența unor procese de management de proiect eficiente formalizate și documentate, ceea ce face posibilă utilizarea experienței pozitive a proiectelor finalizate cu succes. Procesele eficiente sunt cele care sunt documentate, utilizate efectiv, măsurabile și susceptibile de modernizare. Este necesar ca personalul să fie instruit în utilizarea lor.

Fiecare nivel al SMM, începând cu al doilea, este caracterizat de prezența unui număr de așa-numite grupuri principale de procese (zone cheie de proces - 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 în organizare a următoarelor procese (numele lor corespund CMMI):

· managementul cerințelor;

Managementul configurației

· Planificarea proiectului;

· monitorizarea si controlul proiectului;

· gestionarea contractelor;

· măsurători și analize;

· asigurarea calitatii procesului si produselor.

Procesele de la al doilea nivel pot fi caracterizate ca fiind ordonate datorită faptului că sunt planificate în avans, iar execuția lor este strict controlată, obținându-se astfel predictibilitatea rezultatelor proiectului. Odată cu creșterea și complexitatea proiectelor, atenția se mută de la aspectele tehnice ale implementării acestora la aspectele organizaționale și aspecte de management. Executarea proceselor necesită ca personalul să lucreze mai eficient și mai colaborativ, ceea ce, la rândul său, necesită învățarea din cele mai bune practici documentate pentru a îmbunătăți performanța profesională.

La nivelul 3 (nivelul proceselor standardizate), procesele de creare de software sunt documentate, standardizate și reprezintă un singur sistem tehnologic, obligatoriu pentru toate departamentele organizației. Toate proiectele folosesc o tehnologie testată, aprobată și standardizată pentru crearea și întreținerea software-ului.

La acest nivel, următoarele procese sunt adăugate proceselor de nivelul 2:

· specificatiile necesare;

· integrarea produsului;

· verificare;

· certificare;

· standardizarea proceselor organizatorice;

· educație;

· management integrat de proiect;

· Managementul riscurilor;

· analiza si luarea deciziilor.

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

Bazat pe o singură tehnologie, fiecare proiect își poate dezvolta propriile procese ținând cont de caracteristicile sale. Astfel de procese în SMM sunt numite „procese de creare de software orientate spre 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, evaluarea inter pares), datele de ieșire și condițiile de terminare. Descrierea procesului include, de asemenea, informații despre instrumentele necesare pentru a-l efectua și o indicație a rolului responsabil pentru executarea acestuia.

Scopul principal al nivelului 4 (nivelul proceselor gestionate) este controlul continuu 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 ar trebui să fie stabil.

La nivelul 4 se adaugă următoarele procese:

· managementul performanței și productivității;

· managementul cantitativ al proiectelor.

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

Un program unificat pentru monitorizarea cantitativă a productivității creării de software și a calității acestuia este în curs de dezvoltare în întreaga organizație. Pentru a facilita analiza procesului, este creată o bază de date unificată a proceselor de creare și întreținere a software-ului pentru toate proiectele derulate în organizație. Sunt în curs de dezvoltare metode universale de evaluare cantitativă a productivității proceselor și a calității 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 limitele cantitative specificate. 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 creare a software-ului, în organizație este creată o unitate specială, ale cărei responsabilități principale sunt colectarea datelor privind execuția proceselor, analizarea acestora, modernizarea proceselor existente și crearea de noi procese, testarea acestora pe proiecte-pilot și dându-le statutul 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

la fel de constant îmbunătățite cu cât organizația face eforturi continue pentru a le moderniza. Această îmbunătățire se extinde atât asupra identificării caracteristici suplimentare procesele utilizate, precum și crearea de noi procese optime și utilizarea noilor tehnologii.

Inovațiile care pot aduce cele mai mari beneficii sunt standardizate și adoptate în sistemul tehnologic în întreaga organizație. Personalul implicat în proiect 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ă asupra 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, implementarea cerințelor utilizatorilor și crearea de software sunt controlate, deoarece este definită baza proceselor de management de proiect. Procesul de creare a software-ului poate fi considerat ca o secvență de „cutii negre” care pot fi controlate în 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 ce ar trebui să rezulte din proces și se definesc punctele de control pentru începerea și finalizarea acestuia. Prin urmare, conducerea poate recunoaște problemele la punctele de contact cu cutia neagră și poate răspunde la acestea în timp util.

La al treilea nivel se determină structura internă a „cutiilor negre”, adică. sarcinile care compun procesele. Structura interna reprezintă modul în care procesele standard ale unei organizații sunt aplicate unor proiecte specifice. Echipa de management și executanții își cunosc rolurile și responsabilitățile în cadrul proiectului până la gradul de detaliu necesar. Managementul este pregătit din timp pentru riscurile care pot apărea în timpul implementării proiectului. Deoarece procesele standardizate și documentate devin transparente, angajații care nu sunt direct implicați în proiect pot primi informații exacte și în timp util despre stadiul actual al proiectului.

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, sunt capabili să planifice cu acuratețe etapele și fazele proiectului, să prezică progresul proiectului și pot răspunde la problemele emergente în timp util și în mod adecvat. Pe măsură ce posibilele abateri de la timpul, costul și calitatea dat în timpul procesului de proiect scad, capacitatea acestora de a anticipa rezultatele 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 metode și tehnologii noi, îmbunătățite pentru crearea de software. Se atrage atenția nu numai asupra celor deja în uz, ci și asupra proceselor și tehnologiilor noi, mai eficiente. Managerii pot cuantifica impactul și eficacitatea schimbărilor în tehnologie pentru crearea și întreținerea software-ului.

Nivelurile patru și cinci 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 informațiilor SEI din 2002) și 72 de nivelul patru. toate companiile își anunță nivelul de maturitate. Unii nu sunt interesați să-și facă publicitate tehnologiilor organizaționale, 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 în siguranță pe arena internațională. Pentru a utiliza SMM, o companie nu trebuie să caute angajați cu abilități unice; trebuie doar să înțeleagă ideea generala. Descrierea modelului SMM 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 SMM.

Cea mai recentă versiune a SMM 1.1 se adresează în principal companiilor mari care implementează proiecte mari, dar poate fi folosită și de grupuri de două sau trei persoane sau de programatori individuali pentru a finaliza proiecte mici (cu o durată de 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. Aceasta este o nouă dezvoltare a SEI, care acoperă toate aspectele activităților companiei: de la dezvoltarea și selecția unui contractor până la instruire, implementare și suport. În plus, modelul CMMI este extins prin abordări din ingineria sistemelor. Acest model a inclus 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 puternic și important, dar nu trebuie folosit ca singura bază care determină întregul proces de creare a software-ului. A fost destinat în principal 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. La crearea unor astfel de sisteme lucrează echipe destul de mari de programatori, care trebuie să respecte cerințele și standardele elaborate 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 importanți, cum ar fi utilizarea anumitor metode, cum ar fi prototipul, formal și metode structurale, instrumente de analiză statică etc.

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

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

Scopul principalÎn crearea modelului CMM, Departamentul de Apărare al SUA a intenționat să evalueze capacitățile furnizorilor de software. În prezent, 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 șanse mai mari de a câștiga o licitație pentru furnizarea de software. Ca alternativă la CMM, se propune o clasificare generalizată a proceselor pentru îmbunătățirea 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 acțiuni formale precum managementul configurației, dar acțiunile în sine și relațiile lor nu sunt predeterminate.

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

3. Proces bazat pe metodologie. Se presupune că au fost puse în aplicare anumite tehnici (de exemplu, tehnicile de proiectare orientate pe obiecte sunt aplicate sistematic). Instrumentele de sprijin pentru proiectarea și analiza proceselor (instrumentele CASE) sunt utile pentru acest tip de proces.

4. Procesul de îmbunătățire directă. Are un obiectiv clar definit de îmbunătățire a procesului tehnologic, pentru care există o linie separată în bugetul organizației și sunt definite standarde și proceduri de introducere a inovațiilor. O parte a acestui proces implică 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 o alegere a echipei de dezvoltare. Aceeași echipă poate alege o metodologie de dezvoltare specifică, având în același timp toate oportunitățile de a îmbunătăți direct procesul. Acest proces se încadrează în clasificare îmbunătățire informală, bazată pe metodologie, directă.

Necesitatea acestei clasificări se datorează faptului că oferă o bază pentru îmbunătățirea cuprinzătoare a tehnologiei de creare a software-ului și permite unei organizații să aleagă diferite tipuri de procese de îmbunătățire. În fig. 1.8 arată relațiile dintre tipuri diferite sisteme software și procese pentru îmbunătățirea dezvoltării acestora.

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

Cunoașterea tipului de produs dezvoltat va face potrivirea între sisteme softwareși procesele de îmbunătățire prezentate în Fig. 1.8, util atunci când alegeți un proces de îmbunătățire. De exemplu, trebuie să creați un program care să sprijine tranziția software-ului de la o platformă de computer la alta. Acest program are suficient Pe termen scurt funcționarea, prin urmare, dezvoltarea sa nu necesită standarde și management special al procesului de îmbunătățire, ca atunci când se creează sisteme de lungă durată.

Mulți procese tehnologice au în prezent instrumente de asistență CASE, astfel încât acestea pot fi apelate procese suportate. Procesele solide din punct de vedere metodologic sunt susținute de instrumente de analiză și proiectare. Eficacitatea unui instrument de asistență depinde de procesul de îmbunătățire utilizat. De exemplu, un proces informal poate folosi instrumente standard de 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 de creare de software, uneori aceste tehnologii devin disponibile public și foarte populare. Popularitatea largă a modelului SMM este asociată cu acesta sprijinul statului, dar eficiența reală a SMM este criticată de mulți experți de top. Unul dintre principalele dezavantaje ale HMM este asociat cu cerința prea strictă de a nu se abate de la principiile acestui model, chiar dacă bunul simț sugerează contrariul. Asemenea pretenții de deținere a adevărului absolut nu pot decât să provoace prudență, 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 discutată mai jos ocupă un loc intermediar între soluțiile rigide, „grele”, precum SMM, care sunt eficiente pentru organizațiile mari și cele mai tehnologii flexibile. Pare a fi cea mai bună opțiune pentru companiile care, pe de o parte, doresc să-și eficientizeze activitățile de management cât mai repede posibil și, pe de altă parte, planifică în viitor să ajungă nivel international, unde certificarea CMM este foarte de dorit.