SISTEME INFORMATICE

INTEGRATE

Echipa de proiect:
Dascălu Diana-Elena
Popa Silviu
Tittes-Gherman Petru-Vlad
Vasile Vlad
 Cuprins
1. IMPLEMENTAREA MANAGEMENTULUI RISCULUI (RSKM) ÎN SDLC (SYSTEMS
DEVELOPMENT LIFE CYCLE) SYSTEM DEVELOPMENT LIFE CYCLE PHASES ..........................3
Introducere ................................................................................................................................................3
Faza 1 – Definirea scopului general ale conceptelor şi limitărilor acestora ..............................................4
Faza 2 - Analiza sistemului, planificarea cerinţelor ..................................................................................6
Faza 3 – Designul sistemelor.....................................................................................................................7
Faza 4 – Dezvoltare ...................................................................................................................................8
Faza 5 – Integrare şi testare .......................................................................................................................9
Faza 6 – Lansarea ................................................................................................................................... 11
Faza 7 – Mentenanţa............................................................................................................................... 12
Concluzii: ............................................................................................................................................... 13
2. INTEGRAREA MODELULUI CMMI FOLOSIND O COMBINAŢIE DE METODE AGILE ŞI RUP
.................................................................................................................................................................... 14
Despre CMMI ........................................................................................................................................ 14
Despre Agile ........................................................................................................................................... 16
Despre RUP ............................................................................................................................................ 18
Concluzii: ............................................................................................................................................... 20
3. NIVELUL DE MATURITATE AL UNEI COMPANII ........................................................................ 21
Introducere ............................................................................................................................................. 21
Stabilirea nivelului de maturitate pentru firma “Compania” .................................................................. 23
Identificarea zonelor de proces din modelul CMMI necesare pentru a trece la nivelul următor ........... 25
Etapele necesare atingerii nivelului următor CMMI .............................................................................. 25
Beneficiile implementării CMMI ........................................................................................................... 26
Concluzii ................................................................................................................................................ 27
Bibliografie............................................................................................................................................. 28

2
 1. IMPLEMENTAREA MANAGEMENTULUI RISCULUI (RSKM) ÎN
SDLC (SYSTEMS DEVELOPMENT LIFE CYCLE) SYSTEM
DEVELOPMENT LIFE CYCLE PHASES

Introducere

Faza 1 – Definirea scopului general ale conceptelor şi limitările acestora

 Se defineşte scopul şi limitările conceptelor
 Se face analiza cost/beneficiu
 Se realizează studiile de fezabilitate
Faza 2 – Analiza sistemului, planificarea cerinţelor
 Definirea scopurilor produsului în funcţii şi operaţii pentru sistem
 Cerinţe obţinute din documentaţia de la client, şedinţe cu clienţii, chestionare
 Reutilizarea/Alegerea sistemelor existente pentru reutilizare-identificare părţi pozitive,
negative
 Analiza sistemului propus: riscuri + posibile îmbunătăţiri la punctele negative găsite
anterior
Faza 3 – Designul sistemelor
 Feature-uri şi operaţii descrise în detaliu – reguli, diagrame, pseudocod şi documentaţii
iniţiale
Faza 4 – Dezvoltare
 Faza principala de scriere a codului
Faza 5 – Integrare şi testare
 Integrarea tuturor pieselor într-un mediu de test specializat – verificare pentru erori,
probleme de interoperabilitate, compatibilitate
Faza 6 – Lansare
 Fază a proiectului în care produsul intră în producţie şi este folosit în viaţa reală.
Faza 7 – Mentenanţa
 Rezolvarea problemelor pe o perioada mai lungă de timp

3
 Într-un proces de dezvoltare software bazat pe modelul SDLC, managementul riscului
trebuie să aibă în vedere diferiţi parametri pentru fiecare etapa. Este nevoie de un sistem robust
care să poată acoperi o plaja larga de nevoi şi să fie suficient de adaptabil pentru schimbările care
se pot produce subit în timpul dezvoltării. De aceea, este dificilă formarea unui şablon care să
poată fi aplicat cu succes în mod identic pentru fiecare etapa SDLC; mai degrabă vom încerca să
stabilim o strategie de bază care se va dezvolta în funcţie de nevoie.
Tabel 1.1. Strategia generală
Determinarea surselor de  Determinarea contextului şi condiţiilor în care apare un risc
risc precum şi potenţiale consecinţe
Etapa de analiza a  Stabilirea unor criterii care să descrie riscurile (probabilitate,
riscurilor severitate, posibile consecinţe, etc.)
 În acest pas se pot defini nivelele care descriu riscul acceptabil
sau nivelul la care se va produce o escaladare
Împărţirea pe categorii a  Se vor folosi criteriile determinate la pasul 2 pentru stabilirea
riscurilor unor categorii de riscuri
 Se pot defini categorii de priorităţi pentru a determina prioritatea
tratării riscurilor apărute
Stabilirea unor strategii  Se va efectua o monitorizare a riscurilor pentru a putea observa
folosite pentru a atenua când se depăşesc anumite nivele acceptabile
riscurile înainte ca  Stabilirea unei limite de timp n care se va face tratarea unui risc
acestea sa apară sau să  Determinarea resurselor necesare
devină critice  Urmărirea amănunţită a procesului de rezolvare a unui risc

Vom analiza fiecare etapă a modelului SDLC şi vom aplica această strategie pentru
fiecare din ele.

Faza 1 – Definirea scopului general ale conceptelor şi limitărilor acestora

Primul pas în SDLC este posibil şi cel mai deschis la riscuri datorita faptului că nu există
alte limitări decât propria experienţă a persoanelor care definesc conceptele/tehnologiile care vor
fi aplicate într-un nou proiect.
Sursele de risc:
 Cerinţe neclare/nerezonabile din partea clientului
 Crearea unui design nefezabil, imposibil de încadrat în bugetul financiar şi în bugetul
de timp
 Crearea unui design care se bazează pe tehnologii nepotrivite pentru proiect
 Designul impune utilizarea unor tehnologii nefamiliare echipei
 Sub/Supra-estimarea numărului de oameni necesari implementării precum şi a
rolurilor care trebuiesc acoperite
4
  Dacă proiectul presupune utilizarea unor tehnologii/echipamente oferite de către
client; probleme de aprovizionare sau lipsă documentaţiei pentru aceste
tehnologii/echipamente
Analiza riscurilor:
 În această etapă, toate riscurile au o posibilitate ridicată de a apărea iar severitatea lor
este critică, datorită faptului că orice eroare se va perpetua pe tot parcursul
proiectului; posibile consecinţe includ ratarea totală a proiectului
 Oricare din riscuri trebuie identificat urgent şi tratat imediat
Categoriile de risc:
 Se pot observa 2 categorii de risc aici:
 Externe
 Cererile clientului
 Echipamentul/tehnologiile clientului (dacă este cazul)
 Interne – toate celelalte
 Riscurile externe au o prioritate mai mare deoarece în cazul în care sunt lăsate netratate
sau cel puţin eforturile de a le tratata nu sunt documentate – ele pot duce la eşecul
proiectului fără ca vină să aparţină echipei/firmei, iar aceştia/aceasta să sufere
consecinţele aferente
 Diminuarea/tratarea riscurilor:
 Orice cerere a clientului trebuie analizată şi, dacă e nevoie – stabilit unui subset de riscuri
urmat evaluarea separată a acestora
 Orice cerere care nu poate fi implementată sau doar parţial implementată trebuie imediat
identificată şi renegociată
 Primirea unor asigurări (care pot fi arhivate/păstrate) din partea clientului că tehnologiile
primite din partea lor vor fi funcţionale, livrate din timp şi vor sosi cu un minim de
instrucţiuni de utilizare/documentaţie
 Riscurile interne pot fi ameliorate prin:
o Consultarea unor experţi pe temele proiectului
o Analiza unor proiecte similare dezvoltate în trecut
o Consultarea unor documente anterioare de management al riscului
o Analiza lecţiilor învăţate din trecut bazate pe experienţa dezvoltatorilor

5
 Faza 2 - Analiza sistemului, planificarea cerinţelor

Din momentul în care exista o viziune clară asupra sistemului – este bine să se facă o
analiză pentru posibile părţi reutilizabile – care poate duce la scăderea riscului de repetare a
greşelilor – şi definirea cerinţelor în concordanţă cu viziunea clientului.
Sursele de risc:
 Reutilizarea unor componente complet incompatibile cu noul sistem
 Subestimarea de timp necesară adaptării unor componente pentru noul sistem
 Formularea unor cerinţe care nu sunt clare
 Formularea incompletă a cerinţelor
 Cerinţele nu sunt în conformitate cu viziunea clientului sau a sistemului
Analiza riscurilor:
Deşi reutilizarea unor componente mai vechi poate duce la probleme legate de
compatibilitate; se poate câştiga timp/eficienţă dacă se refolosesc părţi robuste şi bine testate
Trebuie gândit bine care este balanţa risc/beneficiu în reutilizarea componentelor
anterioare.
Cerinţele trebuiesc tratate cu seriozitate maximă deoarece prin implementarea şi
urmărirea lor se poate dovedi uşor împlinirea termenilor unui contract
Categoriile de risc:
Există două categorii de risc:
 De tip moştenire (legacy, legate de reutilizarea vechilor componente)
 Legate de cerinţe
Atenuarea/Reducerea/Tratarea riscurilor:
 Şedinţe de consultare cu managerii/inginerii care au contribuit la componentele care
se doresc a fi reutilizate
 Existenţa unei persoane dedicate care să se ocupe de gestiunea cerinţelor (ex:
Reqiurement Engineer)
 Impunerea unui sistem de urmărire a cerinţelor implementate (Câte au fost
implementate, în ce măsură şi de către care componenta - ex: ReqM2)
 Fiecare inginer să îşi asume documentarea cerinţelor îndeplinite şi raportarea mai
departe a stării acestora
 Spre sfârşitul etapei, o serie de şedinţe cu reprezentaţii clientului pentru a ne asigura
că sistemul şi cerinţele se apropie de viziunea lor

6
 Faza 3 – Designul sistemelor

Scrierea documentului de design este o sarcină care ar trebui să revină celor mai
experimentaţi membri ai echipei; multe greutăţi care apar în proiect pot veni datorită unui design
fragil care nu respecta practicile recomandate.
Sursele de risc:
 Lipsa de experienţă a persoanei/persoanelor care scriu documentul de design
 Lipsa de experienţă a persoanei/persoanelor care scriu documentul în folosirea
programului în care se face designul (ex: UML, CVI, Proteus)
 Scrierea superficiala a documentaţiei
 Omiterea designului unor feature-uri
 Conflicte între designeri vis-à-vis de modul de abordare
Diminuarea/tratarea riscurilor:
 Probabilitatea apariţiei acestor riscuri depinde pe deplin de experienţa
arhitectului(ilor); lipsa acesteia poate fi cea mai mare problemă
 Severitatea poate fi notată ca având un nivel semnificativ deoarece deşi designul
poate fi schimbat sau îmbunătăţit pe parcurs, se poate pierde mult timp reparând ceea
ce ar trebui să fie corect de la bun început – risc mare pentru depăşirea bugetului de
timp.
 Din comoditate/lipsă de timp se poate omite documentarea unor feature-uri
considerate mai puţin importante – mai târziu se poate constata ca nimeni nu ştie cum
ar trebui implementate şi cum ar trebui să interacţioneze cu restul sistemului
 Trebuie întotdeauna urmărit, în cazul în care există mai mult de un designer, că există
o colaborare armonioasă între aceştia şi nu apar design-uri paralele sau incompatibile
Categorii de risc:
 Experienţa neadecvată – categorie care include riscurile cele mai mari deoarece pot
duce la pierderi semnificative de bani/timp
 Eroarea umană – riscurile ce apar din omiterea realizării unor design-uri sau
realizarea lor incompleta; mai puţin critice deoarece omisiunile pot fi ameliorate pe
parcurs însă ar trebui să existe planuri de diminuare (ex: alocare buget/timp pentru
probleme neprevăzute)
Măsuri:
 Utilizarea celor mai experimentaţi membri pentru realizarea designului

7
  Review-uri la document de către restul echipei
 Familiarizarea temeinică cu limbajul de design al fiecărui membru din echipă
 Fiecare design, documentaţie, schemă etc., trebuie legată la o cerinţă pentru a ne
asigura că fiecare cerinţă a clientului este acoperită de către un feature
 Aplanarea oricărui conflict de natură umană; încurajarea lucrului în echipă

Faza 4 – Dezvoltare

În faza de scriere a codului responsabilitatea majoră aparţine inginerilor software care

sunt responsabili să se familiarizeze cu designul şi să implementeze în mod corect şi cât mai
eficient sarcinile repartizate.
Surse de risc:
 Sarcini incorect estimate (subestimate, supraestimate, deloc estimate)
 Sarcini incorect organizate (ex: se încearcă implementarea mai multor feature-uri în
decursul unei singure sarcini în loc să se împartă pe parcursul mai multor sarcini)
 Sarcini incorect prioritizate
 Înţelegerea în mod greşit a designului de către ingineri urmată de o implementare
incorecta
 Omiterea scrierii documentaţiei
 Omiterea dezvoltării testelor
 Nerespectarea regulilor de codare/hardware impuse
 Ingineri blocaţi pe o problemă unde nu găsesc soluţii
 Lipsa sincronizării între ingineri (mâna stângă nu ştie ce face mâna dreaptă)
 Lipsa referatelor de analiză – schimbările nu sunt analizate de încă o persoană pentru
posibile probleme
Analiza riscurilor:
 Majoritatea riscurilor apărute în aceasta etapa nu pot fi complet evitate; trebuie în
schimb ca estimările şi planificarea să ia mereu în calcul apariţia oricărei dintre
acestea
 Riscurile, luate individual, au un nivel mediu de importanţă deoarece se pot face
adaptări necesare relativ repede, însă cumulate ele pot duce la blocarea dezvoltării –
trebuie stabilit un prag unde stabilizarea software-ului/hardware-ului existent este mai
important decât implementarea de feature-uri noi

8
  Orice risc care re-apare constant necesită o reevaluare a proceselor folosite şi
adaptarea acestora.
Categorii:
 Organizaţionale – care nu sunt legate de implementarea codului ci de felul în care
sunt organizate/plănuite sarcinile şi de comunicarea între ingineri
 Dezvoltare – orice problemă apărută ca o consecinţă a implementării defectuoase a
designului
Tratarea riscurilor:
 Folosirea unui soft specializat pentru organizarea sarcinilor şi planificare (ex: JIRA)
 Folosirea unui program pentru generarea documentaţiei (ex: Doxygen, JavaDoc etc.)
 Folosirea unui program pentru rapoartele de analiză (ex: Crucible)
 Repartizarea unor persoane a căror singura atribuţie este să urmărească ca procesele
(planificări sarcini, estimări, analize) sunt urmate în mod corect
 Verificarea frecventă a priorităţilor în funcţie de dorinţele clientului
 Şedinţe (scurte de preferat) zilnice pentru a sincroniza inginerii şi a afla în mod rapid
despre orice blocaj individual
 Nu se fac schimbări fără analize făcute de cel puţin 2 persoane (din care una este de
preferat un arhitect/inginer senior)
 Fiecare feature are o sub-sarcina care impune implementarea de teste şi scrierea de
documentaţie; sarcina părinte nu se poate considera rezolvată până aceste puncte nu
sunt îndeplinite

Faza 5 – Integrare şi testare

Etapa de integrare constă în integrarea controlată a modulelor proiectului într-un trunchi

central pentru a minimiza riscul unei regresii sau a erorilor critice. Testarea are responsabilitatea
de a se asigura ca trunchiul principal al proiectului trece toate testele – ideal printr-un mediu de
testare automat sau, în cazul unor scenarii de complexitate majoră, a testării manuale.
Surse de risc:
 Lipsa dedicată a tester-ilor în echipă (şi implicit supra-aglomerarea cu responsabilităţi
a inginerilor)
 Inexistenţa unui sistem de integrare continuă (ex: Jenkins, TeamCity) care asigură
rularea continuă a testelor la fiecare schimbare efectuată de programatori şi alertarea
acestora în cazul în care apare o defecţiune
9
 Nu există compilări/teste pentru mai multe sisteme de operare sau tipuri de
microcontrolere (după necesităţile proiectului)
 Ignorarea testelor picate
 Întreruperea serverului pe care rulează testele (lucru care poate duce şi la un blocaj în
care programatorii nu pot comite noi schimbări)
 Nu se face actualizarea testelor odată cu actualizarea produsului (schimbările de
comportament pot determina şi schimbarea scenariilor de testare)
 Nu se testează scenarii care reflectă realitatea la care va fi supus produsul final
 Lipsa testelor de stres maxim/minim (condiţiile de stres trebuie şi ele să reflecte
realitatea la care este supus produsul final)
 Nu se menţine o arhivă (cu tot cu documentaţie) a componentelor integrate şi a
momentului integrării lor (cu scopul de livrare numai unor părţi către client sau
testare numai anumitor părţi)
 Probleme de interoperabilitate-compatibilitate software-hardware sau hardware-
hardware
 Inexistenţa aparatelor/softului necesar simulării cât mai realiste a scenariilor dorite de
client
Analiza riscurilor:
 Instruirea întregii echipe în respectarea protocoalelor de testare trebuie să fie unul
dintre primele acţiuni ale managementului proiectului
 Este nevoie ca orice risc apărut în această etapă să fie tratat ca având o prioritate
semnificativă deoarece etapa de testare/integrare este ultima barieră înainte ca erorile
să fie vizibile clientului
Categorii de risc:
 Riscuri logistice (lipsă instrumente/echipamente)
 Riscuri de (ignorarea/nu se urmează procedurile de testare/integrare)
Tratarea riscurilor:
 Mediul de integrare continuă trebuie să fie pus pe picioare chiar şi înainte de a avea
un produs funcţional
 Stabilirea unui test manager şi a unui integration manager a căror responsabilitate
include asigurarea faptului că procedurile de testare şi integrare sunt urmărite
 Fiecare modul nou integrat va avea propria grupă de teste

10
  Legarea fiecărei cerinţe de la client de cel puţin un test – se va face apoi o clasificare
după importanţa fiecărei cerinţe deoarece în cazul în care mai multe teste încep să nu
mai funcţioneze corect să se cunoască prioritatea de reparare
 Escaladarea imediată (până la client dacă va fi nevoie) în cazul în care nu se poate
obţine hardware-ul/software-ul necesar testării
 Crearea unui server de rezervă care va prelua integrarea continuă în caz de nevoie
 Niciun programator nu are voie să efectueze schimbări asupra produsului cât timp
acesta este instabil (teste care eşuează, nu rulează, există erori critice)

Faza 6 – Lansarea

Lansarea produsului este în principal făcut de client întrucât produsul livrat trebuie
integrat în hardware-ul/software-ul proprietar clientului. În cazul în care este vorba de un proiect
intern, lansarea este ultima fază după care produsul va funcţiona în mediul real.
Surse de risc:
 Lansarea unui modul/revizie care are erori critice
 Sistem defectuos de raportare a erorilor apărute (lipsă marcatorilor de timpi, trace-uri
incomplete)
 Dacă exista feedback de la cei care încearcă produsul în teren (ex: de la şoferi sau
operatori utilaje), raportarea de comportamente normale ca defecte sau raportarea
inexacta a comportamentelor
 Testare/raportare de erori pe software/hardware învechit (livrate acum multă vreme,
depăşit de o variantă mai nouă care are deja îmbunătăţiri semnificative)
Analiza riscurilor
 Deoarece pot apărea erori neaşteptate sau foarte greu de anticipat, este important să
existe măsuri de precauţie specială când se face testarea în teren
Categorii
 Riscuri externe
Tratarea riscurilor:
 Stabilirea unor revizii de referinţă sau punct de referinţă (milestone) unde stabilitatea
software-ului este satisfăcătoare/optimă – cele mai noi schimbări vor fi comparate
contra acestora pentru a stabili gradul de îmbunătăţire/regresie
 Existenţa unei echipe instruite în utilizarea hardware-ului/ software-ului

11
 Existenţa unui şablon de raportare a unui defect (timp, condiţii, alte informaţii
relevante)
 Existenta/implementarea unui sistem de urmărire eficient; orice defect raportat ar
trebui să fie însoţit de trace-uri
 Fiecare defect raportat va avea specificată versiunea de hardware/software folosită

Faza 7 – Mentenanţa

Surse de risc:
 Pierderea programatorilor/tester-ilor care au realizat implementarea; lipsa de
cunoştinţe a sistemului
 Problemele raportate sunt greu de reprodus datorită diferenţei dintre simulările în care
lucrează dezvoltatorii şi hardware-ul pe care rulează produsul
 Probleme raportate ca fiind rezolvate de către dezvoltatori însă nu şi de către cei care
testează produsul.
 Dacă este vorba de un client extern – dificultatea comunicării dintre responsabilii cu
mentenanţa şi testerii clientului
 Introducere de noi regresii prin reparaţiile efectuate
 Cerinţe pentru schimbări de funcţionalitate care implică risc mare de introducere de
regresii
 Depăşirea bugetului de bani/timp alocat mentenanţei pentru a rezolva o eroare critică
Analiza riscurilor:
 Riscul cel mai mare în timpul perioadei de mentenanţa îl reprezintă introducerea de
regresii, orice acţiune care implică un risc de regresie trebuie tratat cu mare grijă
deoarece se poate înrăutăţi performanţa fără să se ştie exact de ce
 Cerinţele care implică schimbări mari trebuiesc discutate în contextul iniţial al
contractului (dacă firma se angajează ca în timpul perioadei de mentenanţă să
implementeze/schimbe componente majore; câte astfel de schimbări se pot cere, etc.)
sau în contextul risc (de regresii) contra beneficiu (îmbunătăţiri posibile)
Categorii de risc:
 Riscuri de regresie
 Riscuri logistice (depăşire bugete, plecarea oamenilor experimentaţi din proiect)
Tratarea riscurilor

12
 Trebuie încercată menţinerea coeziunii echipei – inginerii (sau o parte dintre
inginerii) care au făcut implementarea să continue şi pe timpul perioadei de
mentenanţă
 Trebuie făcută o prioritizare a sarcinilor după importanţa şi complexitatea
schimbărilor precum şi un sistem de urmărire a acestora
 Orice schimbare efectuată în decursul perioadei de menentenanţă trebuie să poată fi
inversată la fel de uşor
 Orice schimbare rezolvată într-un mediu de simulare trebuie confirmată de încă o
persoană pe hardware-ul din viaţa reală înainte de a se trece mai departe
 Trebuie gândită o strategie pentru felul în care se face repararea unui defect (limita de
timp înainte de escaladare, împărţirea acestora pe categorii şi repartizarea la
responsabilii care au cele mai multe cunoştinţe pe acea categorie; raportare zilnică a
stării unei probleme critice apărute)
 Dacă se aprobă schimbări majore în această fază, trebuie să fie urmărite apariţia
riscurilor specifice etapei de dezvoltare

Concluzii:

 Întotdeauna orice proiect trebuie să aibă un plan de management al riscului.

 Riscurile identificate trebuiesc prioritizate iar potenţialele soluţii trebuiesc prioritizate
şi ele la rândul lor.
 Întotdeauna tratarea riscurilor trebuie să ia în considerare elementul uman (nu toate
măsurile se pot implementa sau vor fi implementate exact ca pe hârtie).
 Riscurile trebuiesc re-evaluate constant.
 Daca se hotărăşte ca un risc să fie lăsat netratat – trebuie în cel mai rău caz analizat
care ar putea fi impactul asupra bugetului şi dacă există resursele necesare, ajustării
planificării financiare pentru un astfel de scenariu.
 O singură persoană nu poate anticipa toate riscurile; trebuie valorificată întreaga
experienţă a echipei.

13
 2. INTEGRAREA MODELULUI CMMI FOLOSIND O COMBINAŢIE DE
METODE AGILE ŞI RUP

Despre CMMI

În încercarea de a îmbunătăți modul în care companiile și organizațiile conduc afacerile,

au fost create multe modele, standarde și tehnologii. Din păcate, majoritatea acestor modele sunt
destinate să îmbunătățească activități specifice pentru organizații specifice și nu realizează o
abordare sistematică a problemelor generale cu care se întâlnesc multe companii.
Pentru a întâmpina problemele prevăzute anterior, CMMI (Compability Maturity Model
Integration) vine cu o serie de reguli generale și modele care se referă la întregul ciclu de viață al
unui produs de la idee, implementare, până la distribuire și întreținere.
Modelul CMMI descrie o suită de cinci niveluri ce califică gradul în o companie sau
organizație urmărește anumite procese comune și repetabile pentru îndeplinirea sarcinilor.
Nivelul cel mai de jos al suitei descrie companii fără procese repetabile, unde mare parte din
activitate este haotică și se desfășoară ad-hoc. Capătul cel mai de sus descrie companiile care
utilizează procese definite și repetabile, care colectează măsurători pentru a le ajuta să-și
amelioreze permanent procesele și caută căi creative de a face lucrurile mai bine pe o bază de
continuitate.
Cele cinci niveluri ale modelului CMMI sunt prezentate în figura Fig. 2.1 și detaliate în
continuare.

Fig. 2.1. Nivelele modelului CMMI

14
 1. Ad-hoc, în care organizația are doar câteva procese comune. Succesul proiectelor depinde
de puterea și abilitățile angajaților. Organizația oferă puțin ca mediu de suport pentru a
ajuta ca procesele să fie de succes. Cele mai multe companii sunt la acest nivel.
2. Project management standardizat, în care organizația a implementat procese standardizate
de project management și utilizează aceste procese comune în toate proiectele.
3. Dezvoltarea unor aplicații software standardizate, nivel în care se realizează o
standardizare în procesele de dezvoltare, similar cu ce se face la nivelul de project
management. Aceasta include procese de dezvoltare software, livrabile, instrumente, etc.
Comune și repetabile.
4. Gestionarea feedback-ului, nivel in care se realizează colectarea de măsurători sub toate
aspectele project managementului și proceselor de dezvoltare. Se creează o arhivă a
măsurătorilor și a lecțiilor cheie învățate din istoricul proiectelor care pot fi sursă de
îmbunătățire pentru proiectele viitoare.
5. Optimizare / ameliorare continuă, la acest nivel se creează o buclă de derulare a
proceselor, de măsurare și de ameliorare continuă. Se utilizează permanent măsurătorile,
feedback-ul și creativitatea pentru optimizarea proceselor.
CMMI este considerat ca fiind cel mai răspândit model conceput pentru îmbunătățirea
proceselor interne de dezvoltare. Printre caracteristicile acestui model se numără:
 Flexibilitatea, deoarece procesele sunt definite în concordanță cu obiectivele propuse
 Modularitatea, modelul este împărțit pe arii de procese și niveluri
 Scalabilitatea, modelul se poate folosi în diverse proiecte indiferent de dimensiunea
acestora.
 Comprehensibilitatea, modelul deține o bună integrare a noutăților de inginerie
 Modelul are un parcurs evolutiv, procesele pot fi implementate incremental în funcție
de dimensiunea organizației și de aspectele pe care acestea se focusează la momentul
respectiv
CMMI oferă cele mai recente dar și cele mai bune practici pentru produse și servicii de
dezvoltare și întreținere. Acest model de maturitate al proceselor este utilizat de către companii
din diverse domenii de activitate, de diverse dimensiuni. Acesta permite organizațiilor corelarea
într-un mod mai explicit a activităților de management și inginerie în cadrul obiectivelor de
afaceri, incorporarea lecțiilor învățate de la zone suplimentare (de măsurare, de gestionare a
riscurilor), abordarea funcțiilor organizaționale adiționale critice pentru produsele și serviciile
lor.
Beneficiile aduse unei companii atât în cadrul proiectelor, cât și în cadrul organizației de
către acest model sunt:
15
  Timp redus pentru lansarea unui produs pe piață
 Efort de dezvoltare redus
 Clienți mulțumiți
 Calitate crescută
 Angajați cu moral ridicat
 Îmbunătățește programul și aduce o predictibilitate pentru buget
 Productivitatea
 Mai puține task-uri de reluat
Principalele obiective ale CMMI sunt:
 Să elimine neconcordanțele
 Să reducă duplicarea
 Să crească atât claritatea cât și înțelegerea
 Să furnizeze terminologie comună
 Să furnizeze un stil consistent
 Să stabilească niște reguli uniforme de construcție
 Să mențină componentele comune
 Să asigure coerența
Avantajul CMMI constă în faptul că se pune la dispoziție un model de lucru strict, cu
reguli clare și fiecare proces se monitorizează cu ajutorul indicatorilor de performanță putând fi
îmbunătățit, pentru a oferi rezultate și mai bune.
Dezavantajul folosirii acestui model este timpul mare petrecut pentru menținerea
procesului.

Despre Agile

Agile este o abordare de management care favorizează schimbarea, mai degrabă decât
planificarea metodică și funcționează după câteva principi care ne sugerează cum să abordăm
proiectele pentru un maxim de eficiență și rapiditate.
În mod obișnuit, proiectele de dezvoltare software pot fi abordate în două moduri
distincte:
 Cascadă: se referă la faptul de a planifica totul în avans, pentru ca mai apoi să se
construiască conform planului pentru întregul an
 Agile: se referă la faptul de a planifica ce se va construi în următoarele săptămâni,
apoi se adaptează de la acel punct.
16
Valorile și practicile Agile:
 Indivizii și interacțiunile au întâietate asupra proceselor și instrumentelor.
Specialiștii preferă autonomia. Așadar, în domeniul de dezvoltare software este mai
important ca oamenii să rezolve problemele prin colaborare, decât prin a-i forța să
adopte o procedură, de dragul de a satisface o politică internă. Momentul în care ne
putem da seama că un proces nu funcționează este atunci când oamenii nu mai
colaborează eficient. Oamenii sunt motorul din spatele fiecărui proiect, iar dacă ei nu
mai pot interacționa din cauza ierarhiei sau a protocoalelor complexe și lungi, atunci
ei petrec mai mult timp pe protocoale și procese decât făcându-și treaba.
 Software funcțional înaintea documentației complexe. În managementul
tradițional, fazele se întâmplă în secvențe, iar dacă o parte este greșită, fiecare dintre
celelalte faze vor avea de suferit. De aceea, managementul de tip cascadă are nevoie
de o documentație bogată. Însă proiectele de tip Agile susțin că lucrurile se pot
schimba. Chiar este important să petrecem o bună parte din timp făcând modificări
peste modificări documentației? Ce contează cel mai mult este să avem un produs pe
care utilizatorii să îl poată testa. Dacă avem de ales între a repara o eroare și a face un
raport despre ea, a o repara este cel mai de folos proiectului.
 Colaborarea cu clientul deasupra negocierilor contractuale. Contractele creează
cultura în care schimbarea nu este o opțiune. Agile creează cultura unde schimbarea
este așteptată. Însă cum controlăm schimbarea? Printr-o corelare strânsă cu clienții.
Agile presupune că avem acces nelimitat la clienții noștri și că întotdeauna putem
discuta cu ei. În contextul în care dezvoltatorii rezolvă probleme în mod natural, ei au
nevoie și de perspectiva clientului pentru a înțelege în detaliu care este problema
reală. Contractele sunt folositoare, însă au un efect neplăcut: oamenii tind să fie
preocupați de a livra proiectul în timpul și banii stabiliți, mai mult decât să
îndeplinească scopul de business. Mai departe, când echipa este presată de timp,
rezultatul este frustrare, panică și o calitate mai mică a produsului. Mai mult, când
semnăm un contract în primele faze ale proiectelor, tindem să aproximăm greșit
timpul petrecut pe proiect. Însă tot va fi nevoie să ne încadrăm în termene chiar dacă
ele nu au de a face cu nevoile reale. De aceea, Agile favorizează colaborarea cu
clientul și livrarea proiectului în mai multe etape. Asta lasă timp echipei să descopere
ceea ce nu știa despre proiect.
 Răspuns la schimbare înaintea urmării unui plan strict. Cu cât alocăm mai mult
timp planificării, cu atât ne împotrivim mai mult schimbărilor pentru că, la urma
urmei este mult mai important să construiești ceva ce ai nevoie decât să urmezi cu
17
 sfințenie un plan. Dezvoltatorii pot urî câteodată atunci când codul lor are eroare sau
nu funcționează, dar clienții urăsc mai mult atunci când nu primesc produsul de care
au nevoie. De aceea, Agile încurajează echipele să “taie” proiectele în bucăți mai
mici, care se pot livra, astfel încât să nu fie nevoie în alte cazuri să refacă părți mari
din el. Mai mult, există o serie de elemente ale managementului de tip Agile, care îl
definesc și îl deosebesc de orice alt tip de management:
 O cultură unde schimbarea este așteptată
 Dezvoltare progresivă
 Lansări frecvente
 Procese scurte de feedback
 Un înalt grad de implicare a clientului

Despre RUP

RUP (Rational Unified Process) este o metodă iterativă dezvoltată de către Rational
Software, o colecție de procese ce descriu ciclul de dezvoltare al produselor software care pune
accent pe descrierea proceselor sub forma unor diagrame – în contrast cu celelalte modele și
utilizează UML ca limbaj de descriere.
RUP definește șase principii de urmat:
1. Dezvoltă software-ul în mod iterativ
2. Gestionează cerințele
3. Utilizează arhitecturi bazate pe componente
4. Modelează în mod vizual aplicațiile
5. Verifică calitatea software-ului
6. Gestionează schimbările în software
Procesele definite de RUP (Fig. 2.2.):
 Inițializare
 Elaborare
 Construcție
 Tranziție

18
 Fig. 2.2. Fazele metodei RUP

Faza de inițializare cuprinde un document de viziune, un model Use – case inițial (10-
20% complet), un plan de proiect cuprinzând fazele și iterațiile, o analiză a riscurilor, un model
business dacă e necesar și unul sau mai multe prototipuri.
Faza de elaborare este cea mai critică fază a proiectului. Cele mai importante componente
ale sistemului sunt dezvoltate acum. În această etapă avem un model Use-case 80% complet. Se
realizează capturarea cerințelor suplimentare, se stabilesc arhitectura generală a procesului, un
prototip executabil, modelul de business și riscurile revizuite, planul de realizare al proiectului și
opțional un manual preliminar de utilizare.
În faza de construcție sunt construite și integrate în produs restul componentelor
nerealizate în faza anterioară. Toate componentele sunt testate iar rezultatul trebuie să fie un
produs pregătit pentru a fi livrat utilizatorului. Este realizat și un manual de utilizare.
In etapa finală, de tranziție, produsul este instalat / livrat utilizatorului, utilizatorul
testează produsul, raportează defectele, urmând ca acestea să fie fixate. Această fază poate fi
foarte simplă sau foarte complexă, depinzând de tipul produsului.
Fiecare fază din RUP poate fi descompusă în iterații. Avantajele metodelor iterative sunt:
 Gestionarea mai bună a riscurilor
 Controlarea mai simplă a schimbărilor
 Calitate mai bună
Dacă ar fi să facem o comparație între cele trei metode de management am putea pune în
evidență următoarele aspecte:

19
 Tabel 2.1. Analiză comparativă metode de management
CMMI Agile RUP
Îmbunătăţirea Îmbunătăţirea softului
Cerere Îmbunătăţirea softului
procesului în mod iterativ
Acurateţea
Focus Procesul existent Procese si produse noi
documentaţiei
Îmbunătățiri
Scopuri principale Produs finit Produs finit
organizaționale
Procese de
Standardizarea Nu include Calitatea
management

Concluzii:

Designul AGILE reprezintă un proces care se bazează pe aplicarea continuă a

principiilor agile și a design pattern-urilor astfel încât designul aplicației rămâne în mod constant
simplu, curat și cât se poate de expresiv.
RUP este o modalitate foarte bună de a începe. Este un cadru bun, cu toate instrumentele
și informațiile necesare pentru o organizație. Cadrul a fost ușor de personalizat pentru a răspunde
nevoilor. Lucrul minunat pe care l-am descoperit a fost că integrarea este cheia.
CMMI asigură un model interconectat și prin urmare stabil, cu o acoperire mai mare a
ciclului de viață al unui produs decât orice alt produs de îmbunătățire a procesului. Combină
software engineering și systems engineering în product engineering, oferind companiilor un set
integrat și puternic de unelte. CMMI susține colaborarea dintre systems engineering și software
engineering, ajutând organizațiile să se concentreze pe produsul finit și pe procesele asociate.
Permite nu numai flexibilitate în implementarea unui model care să se potrivească mai bine cu
obiectivele unei organizații, ci și o terminologie comună, arhitectură și metode de evaluare.

20
 3. NIVELUL DE MATURITATE AL UNEI COMPANII

Introducere

Modelul CMMI (Capability Maturity Model Integration) descrie principii şi bune practici
asociate cu maturizarea proceselor de dezvoltare software şi este destinat organizaţiilor care
doresc să urmeze calea de la procese ad-hoc la procese standardizate. Modelul este organizat pe
5 niveluri de maturitate:
1. Iniţial
Procesele software sunt improvizate, uneori chiar haotice. Puţine procese sunt definite iar
succesul depinde de eforturile individuale;
2. Gestionat (engl. “managed”)
Sunt stabilite procese manageriale de bază pentru a monitoriza costurile, graficul de lucru şi
funcţionalitatea. Există disciplina necesară pentru a repeta succesele anterioare pentru proiecte
similare;
3. Definit
Procesele software pentru activităţile de management şi cele tehnice sunt documentate şi
integrate într-un proces standard al organizaţiei. Toate proiectele folosesc o versiune adaptată şi
aprobată a standardului;
4. Gestionat cantitativ (engl. “quantitatively managed”)
Sunt colectate măsurători detaliate despre procesele software şi calitatea produselor. Atât
procesele software cât şi produsele sunt înţelese şi controlate din punct de vedere cantitativ;
5. În optimizare (engl. “optimizing”)
Este facilitată îmbunătăţirea continuă a proceselor prin reacţii (“feedback”) cantitative din cadrul
proceselor şi prin includerea unor idei şi tehnologii inovatoare.
Procesele cheie pentru fiecare nivel
1. Prin definiţie, pentru nivelul 1 nu există procese cheie.
2. Procesele cheie pentru nivelul 2 se concentrează asupra stabilirii funcţiilor manageriale
de bază:
 Aria de inginerie:
o Managementul cerinţelor;
21
  Aria de management de proiect:
o Planificarea proiectelor;
o Monitorizarea şi controlul proiectelor;
o Managementul acordurilor cu furnizorii (Gestionarea achiziţiilor de
produse de la furnizori externi);
 Aria de suport:
o Măsurători şi analize;
o Asigurarea calităţii proceselor şi produselor;
o Managementul configuraţiei.
3. Procesele cheie pentru nivelul 3 se referă atât la probleme legate de proiect cât şi la cele
organizaţionale, întrucât organizaţia stabileşte infrastructura de lucru şi instituţionalizează
procesele de ingineria programării şi de management pentru toate proiectele. Scopul principal
este standardizarea proceselor.
 Aria de inginerie:
o Dezvoltarea cerinţelor (Transformarea nevoilor clientului în cerinţe prin
consolidarea informaţiilor insuficiente, rezolvarea conflictelor etc.);
o Soluţia tehnică (Reprezintă efortul tehnic principal de proiectare şi
implementare);
o Integrarea produsului (Asamblarea produsului din componentele sale);
o Verificarea;
o Validarea;
 Aria de management de proiect:
o Definirea proceselor organizaţionale;
o Activităţile organizaţionale de instruire;
o Management de proiect integrat (Implicarea tuturor părţilor interesate
relevante);
o Managementul riscului;
 Aria de suport:
o Analiza deciziilor şi rezoluţiile (engl. “Decision Analysis and Resolution”
– Analiza alternativelor cu ajutorul unui proces de evaluare formal pe
baza unor criterii bine definite).
4. Procesele cheie ale nivelului 4 se concentrează pe înţelegerea cantitativă a proceselor şi
produselor:
 Aria de management de proiect:

22
 o Performanţele proceselor organizaţionale (Stabilirea unor modele de
evaluare cantitativă a proceselor organizaţiei);
o Managementul de proiect cantitativ (Managementul în vederea îndeplinirii
obiectivelor cantitative stabilite de calitate şi performanţă).
5. Procesele cheie ale nivelului 5 acoperă problemele referitoare la îmbunătăţirea continuă
şi măsurabilă a proceselor legate de software:
 Aria de management de proiect:
o Inovarea organizaţională şi desfăşurarea (engl. “Organizational Innovation
and Deployment”);
 Aria de suport:
o Analiza cauzală şi rezoluţiile (engl. “Causal Analysis and Resolution” –
Identificarea cauzelor defectelor şi luarea de măsuri pentru prevenirea
lor).

Stabilirea nivelului de maturitate pentru firma “Compania”

Firma are 120 de angajaţi şi 10 proiecte active structurate conform tabelului 1

Tabel 3.1.Structură proiecte active

Tip proiect Nr. proiecte Nr persoane/proiect
Mare 5 10*5=50
Mic 5 5*5=25
Total 10 75

Pentru stabilirea nivelului de maturitate se aplică un chestionar: Pentru început se

realizează o evaluare iniţială a organizaţiei pentru a identifica zonele de proces care sunt atinse
cu un efort minimal.
Pe baza caietului de sarcini s-au observat următoarele zone de interes:
 proiecte bine structurate până la managementul proiectelor
 utilizarea unei versiuni simplificate de RUP
 un număr relativ mic de proiecte efectuate în cadrul unui ciclu
 formarea nu este în permanenţă oferită personalului tehnic
 conducerea nu este implicată în definirea şi aplicarea politicilor globale
Se impune adresarea unui set de întrebări în vederea eliminării necunoscutelor:
1. Există o relaţie stabilă, clară şi bine definită între companie şi furnizorii sau partenerii
externi? Există acorduri în care sunt stipulate clar drepturile şi obligaţiile tuturor
părţilor implicate?
23
 2. Organizaţia deţine în structură o funcţie specifică care se ocupă cu măsurarea şi
analiza progresului la nivel de proiect?
3. Există o funcţie specifică de asigurare a calităţii produselor, oferirea de rezultate în
mod constant, pentru o creştere a fiabilităţii acestora?
4. Firma deţine un mecanism de gestiune a cerinţelor care este capabil de a identifica
neconcordanţele dintre acestea?
5. Sunt acoperite cele trei obiective principale de control ale proiectului:cost, timp,
calitate?
După cum este menţionat anterior, organizaţia utilizează o versiune simplificată
de RUP, iar pentru proiectele mici, se utilizează Agile. În concluzie s-a observat faptul că
organizaţia se orientează după modelul AUP- Agile Unified Process. Acesta este descris în
următoarele etape:
1. Iniţială:obiectivul este de a înțelege cerinţele iniţiale ale proiectului, determinarea
unei arhitecturi a soluției software,obţinerea finanţării iniţiale, identificarea criteriilor de
acceptanţă ale părţilor implicate;
2. Elaborare: obiectivul este de a elabora o arhitectură optimă a soluţiei software;
3. Construcţie:obiectivul este de a construi un software care este funcţional, ulterior
putând fi livrate funcţionalităţi care aduc valoare clientului;
4. Tranziția: Obiectivul este de a valida şi instala Soluția software în mediul de
producţie;
Procesele software prezente în cadrul Agile Unified Process sunt următoarele:
1. Modelare: are ca obiective adunarea şi înţelegerea cerinţelor de business ale
organizaţiei, identificarea problemei pe care proiectul încearcă să o rezolve, elaborarea unei
soluţii software viabilă pentru această problemă. Sunt atinse următoarele zone de proces:PP-
planificarea proiectului;
2. Implementare: obiectivul îl reprezintă transformarea modelelor şi cerinţelor create
în cod executabil, apoi realizarea unei testări minimale a codului scris. Sunt atinse următoarele
zone de proces: RD- Cerinţele dezvoltării; TS- Soluţia tehnică;
3. Testare: evaluarea şi asigurarea calităţii soluţiei software, găsirea
defectelor,validarea funcţionării sistemului software conform specificaţiilor, verificarea gradului
de satisfacere a cerinţelor. Sunt atinse următoarele zone de proces: VER-verificare; VAL-
validare; PPQA-asigurarea calităţii proceselor şi a produselor;
4. Instalare: obiectivul îl reprezintă realizarea unui plan de instalare, punerea în
funcţiune a soluţiei software, atribuirea accesului utilizatorilor finali la aplicaţie. Sunt atinse
următoarele zone de proces PI-integrarea produselor;
24
 5. Managementul configuraţiei: obiectivul este de a asigura în mod organizat
accesul la livrabilele din proiect(documente, fişiere sursa, versiuni), dar şi de a gestiona
managementul schimburilor. Sunt atinse următoarele zone de proces: CM-Managementul
configuraţiei;
6. Managementul proiectului: obiectivul este de a coordona şi facilita activităţile
care au loc în proiect: managementul riscurilor, resurselor, al oamenilor, încadrarea proiectului în
limitările impuse de timp, respective buget. Sunt atinse următoarele zone de proces: REQM -
Gestionarea cerințelor; SAM- Managementul acordului cu furnizorii; RSKM-managementul
riscului;
7. Mediul de dezvoltare: obiectivul este de a crea un mediu prielnic pentru echipa de
proiect, pentru ca aceasta să poată dezvolta aplicaţia conform standardelor.
În cazul unor răspunsuri afirmative ale întrebărilor adresate, corelate cu parcurgerea
algoritmului de definire AUP este demonstrată apartenenţa organizaţiei COMPANIA la nivelul 2
de maturitate. Organizaţia prezintă o doză de disciplină în cadrul proceselor. Proiectele sunt
monitorizate, controlate şi revizuite. Există un mediu prielnic de repetare a succesului pentru
proiecte similare. Deficienţele sunt reprezentate de lipsă unei structuri ierarhice eficiente, lipsă
de servicii pentru formarea personalului tehnic, lipsă utilizării a mai multor standarde care să fie
folosite în funcţie de natura proiectului.

Identificarea zonelor de proces din modelul CMMI necesare pentru a trece la

nivelul următor

Zonele de proces necesare pentru atingerea nivelului de maturitate următor sunt:

 DAR - Analiza şi rezoluția deciziei
 IPM - Managementul integrat al produselor
 OT - Formare organizaţională
 OPF - Ţinta procesului organizaţional
 OPD - Definirea procesului organizaţional
Se observă o deficienţă în cadrul următoarelor arii de procese: Suport, Managementul
Proiectului, managementul proceselor.

Etapele necesare atingerii nivelului următor CMMI

Pentru atingerea nivelului 3 de maturitate este urmărită standardizarea organizaţiei.

Procesele trebuie să fie descrise mult mai riguros decât nivelul anterior, prin standard, metode,
25
unelte. Implicit trebuie ca ariile prezentate anterior să fie acoperite. Trecerea dintre cele două
nivele nu ar trebui să fie dificilă şi de lungă durată prin prisma faptului că zonele de proces din
cadrul ariei de inginerie sunt deja satisfăcute. Avansarea se va realiza prin îndeplinirea
următoarelor etape:
 realizarea proiectelor bazate pe şabloane standard;
 îmbunătăţirile proceselor să fie realizate în mod organizat, controlat;
 adoptarea unor metode de sortare şi personalizare a proiectelor, în funcţie de
natura lor;
 formalizarea procesului care presupune adoptarea unei decizii prin colaborare
eficientă între manageri şi părţile implicate în implementarea proiectului;
 îmbunătăţirea organigramei de funcţionare a organizaţiei.

Beneficiile implementării CMMI

Beneficiile implementării modelului CMMI prin parcurgerea nivelelor de maturitate sunt:

 Îmbunătățirea ciclului de timp
 Costul scăzut al calității
 Creşterea satisfacţiei clienţilor
 Îmbunătățirea calității (măsurată prin defecte).

26
 Concluzii

Am fost abordaţi de către firma “Compania” pentru a stabili nivelul de maturitate în care
se încadrează. Am început prin a analiza descrierea lor iniţială, am propus un set de întrebări.
Prin corelaţia rezultatelor s-a stabilit nivelul 2 de maturitate. În continuare s-au evidenţiat zonele
de proces deficitare, care îmbunătăţite fiind, pot asigura trecerea la nivelul de maturitate următor.
S-a observat ca zonele de proces din cadrul ariei de inginerie, specific nivelului de maturitate
următor, sunt atinse. Ca urmare trecerea dintre cele două nivele nu ar trebui să fie dificilă şi de
lungă durată. S-a evidenţiat faptul că efortul depus pentru avansarea pe axa maturităţii în cadrul
CMMI atrage beneficii precum Îmbunătățirea ciclului de timp, Costul scăzut al calității,
Creşterea satisfacţiei clienţilor, Îmbunătățirea calității (măsurată prin defecte).

27
 Bibliografie

1. http://www.software-quality-assurance.org/cmmi-organizational-training.html
2. http://www.trilex.ro/Metodologii/IT-Agile-AUP-RUP.htm
3. https://www.wibas.com/cmmi/measurement-and-analysis-ma-cmmi-dev
4. https://www.quora.com/What-are-key-differences-between-agile-and-rup-methodologies
5. https://www.wibas.com/cmmi/organizational-process-focus-opf-cmmi-dev
6. http://www.software-quality-assurance.org/cmmi-risk-management.html
7. https://en.wikipedia.org/wiki/Systems_development_life_cycle
8. https://en.wikipedia.org/wiki/Risk_management
9. Note de curs Sisteme informatice integrate

28