Sunteți pe pagina 1din 37

Metodologii pentru dezvoltarea

sistemelor încorporate
<Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

Curs: 2h / săptămână
Proiect: 1h / săpămână

Evaluare
Pe parcurs
Proiect 25%
Teme de casă [3] 25%
Finală
Colocviu 50%

Documentaţie
automatica.ac.tuiasi.ro - intrare ca vizitator cu parola: studan1sciMDSI

2
<Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

Bibliografie
***, (2003), PRJ270: Essentials of Rational Unified Process, IBM Corp.
J. Highsmith, (2009), Agile Project Management: Creating Innovative Products, 2nd
ed., Addison Wesley.
A. Cockburn, (2004), Crystal Clear a Human-Powered Methodology for Small Teams,
Addison Wesley.
M. Cohn, (2009), Succeeding with Agile: Software Development using Scrum,
Addison Wesley.
K. Schwaber, (2004), Agile Project Management with Scrum, Microsoft Press.
***, http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
Kim H. Pries, Jon M. Quigley, (2008), Project management of complex and
embedded systems : ensuring product integrity and program quality

3
<Metodologii pt. dezv. sist. încorporate>
Introducere <Florin Ostafi>

Modelarea procesului de dezvoltare


 se furnizează echipei proiectului o înţelegere comună a activităţilor,
resurselor şi constrângerilor implicate în procesul de dezvoltare
 crearea unui model permite găsirea inconsistenţelor, redundanţelor şi
omisiunilor procesului şi a părţilor constitutive ale acestuia
 modelul trebuie să reflecte scopurile dezvoltării
 construirea unui software de calitate
 găsirea defectelor în fazele timpurii ale dezvoltării
 satisfacerea cerinţelor de cost şi de timp pentru realizarea proiectului

Modele de dezvoltare a sistemelor software


 pot fi aplicate unor serii mai largi de proiecte
 se ţine cont de specificul fiecărui proiect în parte

4
<Metodologii pt. dezv. sist. încorporate>
Modelul în cascadă <Florin Ostafi>

Analiza Modelul cascadă


cerinţelor Avantaj principal: o sarcină complexă este împărţită în mai
Modelul
mulţi paşi,în
cecascadă cu reacţie
sunt mai uşor de administrat Dezavantaje
Proiectarea  Clientul trebuie să aştepte instalarea sistemului
 se poate influenţa rezultatul obţinut într-un
arhitecturală pentru a vedea cum funcţionează acesta
stadiu precedent
 Într-un anume stadiu al dezvoltării nu se poate
Proiectarea  un model realist ar trebui să ofere posibilitatea
influenţa rezultatul obţinut într-un stadiu precedent
detaliată ca de lapentru
un anumit nivel săo problemă
se poată găsită
reveni la
a se remedia
oricare dintre nivelurile anterioare
Scrierea codului

Testarea unităţilor şi
testarea la integrare

Testarea
sistemului

Testarea de
acceptare

Operarea şi
întreţinerea

5
<Metodologii pt. dezv. sist. încorporate>
Modelul în cascadă <Florin Ostafi>

Analiza Validare
cerinţelor Modelul în cascadă cu prototipizare
 Prototipizarea în faza de analiză a
Proiectarea Verificare cerinţelor permite asigurarea faptului că
arhitecturală cerinţele sunt consistente şi fezabile
Proiectarea
 Prototipizarea în faza de proiectare
detaliată
permite
Scrierea • evaluarea unor strategii
codului alternative de proiectare
Prototipizare
• stabilirea strategiei potrivite
Testarea unităţilor şi
pentru proiect
testarea la integrare

Prototipul - produs dezvoltat Testarea


parţial care permite clientului şi sistemului
dezvoltatorilor să analizeze
aspectele funcţionale majore ale Testarea de
acceptare
sistemului şi să decidă dacă
sistemul propus este suficient de Operarea şi
apropiat de cel cerut întreţinerea

6
<Metodologii pt. dezv. sist. încorporate>
Modelul în V <Florin Ostafi>

Modelul în V - variaţie a modelului în cascadă care pune în


evidenţă legătura dintre activităţile de testare şi cele de
analiză şi proiectare Operarea şi
întreţinerea

Analiza Validare cerinţe Testarea de


cerinţelor acceptare

Proiectarea Testarea
arhitecturală sistemului
Verificare proiectare

Proiectarea Testarea unităţilor şi Dacă se găseşte o problemă în timpul


detaliată testarea la integrare
verificării şi validării, atunci se execută
din nou etapa corespunzătoare din
ramura din stânga a modelului pentru
Scrierea codului a elimina problema apărută

7
<Metodologii pt. dezv. sist. încorporate>
Modelul incremental <Florin Ostafi>

Modelul incremental
Se identifică cerinţele sistemului şi apoi se repetă
activităţile de dezvoltare la fiecare livrare nouă
Analiza
cerinţelor

Livrare 1
Proiectare Implementare Instalare Întreţinere

Livrare 2
Proiectare Implementare Instalare Întreţinere

Livrare i
Proiectare Implementare Instalare Întreţinere

8
<Metodologii pt. dezv. sist. încorporate>
Modelul în spirală <Florin Ostafi>

Cost cumulativ

Determinare obiective, Evaluare alternative


alternative, constrângeri (prin prototipuri)
Modelul în spirală Identificare şi rezolvare riscuri

Combină avantajele: Analiza risc (AR)

 modelului în cascadă AR

 dezvoltării incrementale AR Prototip (PR3) Prototip


AR PR2 operaţional
START
 prototipizării PR1
Plan Simulare, modele
Concept
cerinţe Proiectare
Proiectare detaliată
Validare software
Problema principală a Plan dezvoltare Testare
cerinţe
dezvoltării programelor este unităţi
Plan integrare, Validare/verificare
riscul, acesta fiind acceptat, Integrare şi
plan testare software
evaluat şi diminuat. Testare de testare
Implem. acceptare
Planificare faza următoare Dezvoltare

9
<Metodologii pt. dezv. sist. încorporate>
RUP <Florin Ostafi>

Modelul RUP (Rational Unified Process)


Etapa inginerească
 Metodă (tehnică)
de dezvoltare/management iterativă
 Se
Etapa dedezvoltă
producţie
planuri, se stabilesc cerinţele şi arhitectura sistemului, rezolvând problema riscurilor ce
evaluări periodice ale obiectivelor şi replanificarea pe baza acestor evaluări
pot apărea la dezvoltarea proiectului.
 Se construieşte o versiune livrabilă în contextul furnizat de etapa anterioară.
 arhitectură şi componente
 Se încheie cu o arhitectură de bază.
 Construcţia,
Produsul este implementat
testarea în principalactivităţilor
şi implementarea în fazele desunt
Elaborare şi Construcţie
realizate de echipe de dimensiuni mai mari.
 soluţionare timpurie a riscurilor
 Proiectarea este realizată de echipe de dimensiuni mici.

Etapa inginerească Etapa de producţie


Iniţiere (Pornire) Elaborare (Rafinare) Construcţie Tranziţie

timp

Milestone Milestone Milestone Milestone


Obiective Arhitectură Capabilitate Livrare
operaţională iniţială produs

10
<Metodologii pt. dezv. sist. încorporate>
RUP <Florin Ostafi>

Etapa inginerească Etapa de producţie


Iniţiere (Pornire) Elaborare (Rafinare) Construcţie Tranziţie

timp

Milestone Milestone Milestone Milestone


Obiective Arhitectură Capabilitate Livrare
operaţională iniţială produs
Faza de Iniţiere
Faza
 de echipa
Scop: Elaborare
de dezvoltare stabileşte obiectivele esenţiale ale proiectului.
Faza
 de Construcţie
 Rezultate:
Scop: se hotărăşte arhitectura sistemului, se stabileşte echipa de lucru, se elimină situaţiile cu risc mare.
 Faza
Scop:de Tranziţiecerinţelor neimplementate încă şi dezvoltarea completă a sistemului.
adăugarea
  enumerare a cerinţelor principale, posibil în formă de cazuri de utilizare;
Rezultate:
 Rezultate:
Scop: se adaugă noi caracteristici, însă accentul se pune pe îmbunătăţirea şi rafinarea celor existente pe baza
 imagine de ansamblu
un prototip evoluţionar asupra arhitecturii
al arhitecturii programului;
sistemului;
reacţiilor de la client.
  Sistemul propriu-zis;
 descriere
teste
 Sfârşitul careaverifică
obiectivelor
acestei activităţi
proiectului;
funcţionarea
şi a întreguluisistemului;
proces de dezvoltare are loc atunci când:
  Teste;
 Obiectivele
un plande
cazuri preliminar
utilizare de dezvoltare.
care descriufazei
majoritatea funcţionalităţilor sistemului;
propuse în cadrul de pornire sunt îndeplinite;
 Manuale
 Riscurile de utilizare.
determinate de extragerea cerinţelor trebuie identificate înainte de pornirea proiectului
 un plan de proiect
 Clientul este detaliat pentru
satisfăcut. iteraţiile următoare;

11
<Metodologii pt. dezv. sist. încorporate>
RUP <Florin Ostafi>

Iniţiere Elaborare Construcţie Tranziţie


Iteraţie Iteraţie Iteraţie Iteraţie Iteraţie Iteraţie Iteraţie Iteraţie
preliminară Arhitectură Arhitectură Dezvoltare Dezvoltare Dezvoltare Tranziţie Tranziţie

Livrabile

Iteraţia: Secvenţă distinctă de activităţi bazate pe un plan stabilit şi pe criterii de evaluare din care rezulta un livrabil
(intern sau extern).
 Reprezintă punctul la care proiectul este evaluat şi sunt realizate ajustările necesare.
 Scop: dezvoltarea unui program funcţional care să poată fi prezentat clientului, iar clientul să îl poată
evalua.
 Durata depinde de tipul de proiect la care se lucrează, de experienţa echipei etc.
 Este de preferat ca iteraţiile să fie cât mai scurte.
 Livrabil: versiune stabilă, completă şi executabilă a sistemului.
 Faza de iniţiere poate să nu necesite un livrabil executabil

12
<Metodologii pt. dezv. sist. încorporate>
RUP <Florin Ostafi>

Disciplinele şi fazele RUP

 Aceste discipline nu sunt


separate în timp (cum se
presupune, de exemplu, în
cazul modelului în cascadă) ci
se execută în paralel, pe
parcursul întregului proiect

13
<Metodologii pt. dezv. sist. încorporate>
PMBOK <Florin Ostafi>

PMBOK – A Guide to Project Management Body of Knowledge


standard în managementul proiectelor -  Project Management Institute (PMI) 
stabileşte principii şi practici pentru managementul proiectelor
un inventar al ideilor pentru managementul de proiect
5 grupuri de procese, 9 domenii, 44 procese

Grupuri de procese:
Iniţiere
Planificare
Execuţie
Monitorizare şi control
Închidere

14
<Metodologii pt. dezv. sist. încorporate>
PMBOK <Florin Ostafi>

Domenii

Managementul obiectivelor
Managementul timpului
Managementul riscurilor
Managementul calităţii
Managementul costurilor
Managementul resurselor umane
Managementul comunicării
Managementul achiziţiilor
Managementul integrării

15
PMBOK <Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

Domenii Grupuri de procese


Iniţiere Planificare Execuţie Monitorizare şi Închidere
control
Managementul Realizare “Project Realizare Plan de Execuţie proiect Monitorizare şi Închidere
integrării Charter” - autorizare. pr. Management al control proiect proiect
Realizare “Scope Proiectului Control integrare
statement” preliminar schimbări
Managementul Planificare obiective Verificare obiective
obiectivelor Definire obiective Control obiective
Creare WBS
Managementul Definire activităţi Control orar
timpului Secvenţiere activităţi
Estimare resurse
activităţi
Estimare durată activităţi
Realizare orar
Managementul Estimare costuri Control costuri
costurilor Bugetare costuri

Managementul Planificare calitate Asigurare Control calitate


calităţii calitate

16
<Metodologii pt. dezv. sist. încorporate>
PMBOK <Florin Ostafi>

Domenii Grupuri de procese


Iniţiere Planificare Execuţie Monitorizare şi Închidere
control
Managementul Planificare resurse Angajare personal Conducere echipă
resurselor umane Dezvoltare echipă proiect
umane

Managementul Planificare Distribuire Raportare performanţă


comunicări comunicare informaţii Încheiere administrativă

Managementul Planificare Monitorizare şi control


riscurilor management riscuri riscuri
Identificare riscuri
Analiza calitativă
Analiza cantitativă
Planificare
răspunsuri la risc

Managementul Planificare achiziţii şi Solicitare oferte Administrare contracte Încheiere


achiziţiilor solicitări furnizori contracte
Planificare Selecţie oferte
contractare

17
<Metodologii pt. dezv. sist. încorporate>
PRINCE 2 <Florin Ostafi>

PRojects IN Controlled Environments - proiecte în medii controlate


Metodă de management de proiect sponsorizată de guvernul Marii Britanii
Marcă înregistrată a CCTA - Central Computer and Telecommunications Agency -
Agenţia Centrală pentru Computere şi Telecomunicaţii
Primul standard PRINCE a fost publicat în 1990 de Centrul de Sisteme Informatice
al guvernului Marii Britanii, CCTA
A fost creat în special pentru departamentele guvernamentale care se ocupă de
proiecte de tehnologie informatică
Deşi sponsorizat de guvern, standardul a fost lăsat şi la dispoziţia organizaţiilor
neguvernamentale
Prima versiune a PRINCE se ocupa în special de proiectele IT
În 1994, CCTA, care controlează dezvoltările PRINCE, a hotărât să realizeze o
versiune revizuită, PRINCE2, cu un spectru mai larg decât proiectele IT

18
<Metodologii pt. dezv. sist. încorporate>
PRINCE 2 <Florin Ostafi>

PRINCE oferă avantaje managerilor şi directorilor unui proiect sau ai unei


organizaţii prin
folosirea controlabilă a resurselor
posibilitatea de a administra cu mai multă eficienţă riscul afacerii şi al proiectului

PRINCE înglobează cele mai bune practici stabilite şi dovedite în


managementul proiectului
Metoda este larg recunoscută şi înţeleasă, oferind un limbaj comun pentru toţi
participanţii la proiect
PRINCE încurajează recunoaşterea oficială a responsabilităţilor in cadrul unui
proiect şi se concentrează asupra rezultatelor proiectului:
ce ?
de ce ?
când ?
pentru cine ?

19
<Metodologii pt. dezv. sist. încorporate>
PRINCE 2 <Florin Ostafi>

PRINCE oferă proiectelor următoarele avantaje:


un start, un conţinut şi o încheiere controlate şi organizate
verificări periodice ale modului în care progresează proiectul pe baza prevederilor
planului şi a justificării economice
puncte de decizie flexibile
elemente automate de control managerial asupra eventualelor abateri de la plan
implicarea conducerii şi a persoanelor interesate de proiect pe toată durata
acestuia, la momentul şi locul potrivit
canale de comunicare adecvate între proiect, managementul proiectului şi restul
organizaţiei

20
<Metodologii pt. dezv. sist. încorporate>
PRINCE 2 <Florin Ostafi>

Managerii de proiect care folosesc PRINCE sunt capabili:

să stabilească termenii de referinţă ca o premisă obligatorie pentru începerea


proiectului
să folosească o structură definită pentru delegare, autoritate şi comunicare
să împartă proiectul în etape uşor de administrat, pentru o planificare mai precisă
să-şi asigure angajarea conducerii în ceea ce priveşte resursele, ca parte
integrantă a aprobărilor de continuare a lucrărilor
să întocmească rapoarte de management periodice şi concise
să restrângă şedinţele şi întrevederile cu conducerea şi grupurile interesate de
proiect la numărul minim necesar, dar în punctele vitale din cursul proiectului

21
<Metodologii pt. dezv. sist. încorporate>
PRINCE 2 <Florin Ostafi>

Persoanele care vor fi direct implicate în utilizarea rezultatelor


proiectului vor putea:
să participe la toate deciziile privind proiectul
dacă doresc, să se implice deplin în evoluţia de zi cu zi a proiectului
să participe la verificările calitative pe toată durata proiectului
să se asigure că cerinţele lor sunt satisfăcute in mod corespunzător

Pentru persoanele din conducere, PRINCE foloseşte conceptul de


management prin excepţii:
Conducerea este pe deplin informată asupra stadiului în care se
află proiectul, fără să fie nevoie să participe la şedinţele periodice,
care consumă mult timp

22
<Metodologii pt. dezv. sist. încorporate>
PRINCE 2 <Florin Ostafi>

Elemente comune ale proiectelor conform PRINCE2

Componente - oferă cunoştinţele fundamentale necesare pentru înţelegerea


termenilor folosiţi într-un proces
De exemplu, poate fi vorba de un proces din care rezultă un plan. Un plan este o componentă
PRINCE, iar secţiunea Componente explică ce se înţelege printr-un plan, ce trebuie să conţină un plan
şi ce tipuri de planuri sunt utilizate în metoda PRINCE

Procesele - acţiuni pe care cineva trebuie să le întreprindă în anumite momente


ale derulării proiectului
De exemplu, la un moment dat, managerul de proiect trebuie să întocmească un plan pentru etapa
de iniţiere. Procesul conturează ce trebuie făcut şi de ce este nevoie pentru a fi adus la îndeplinire; dar
explicarea noţiunii de plan de etapă este găsită în partea de Componente. Utilizatorul trebuie să caute
în mai multe secţiuni despre componente, întrucât într-una dintre ele se discută despre planuri, iar în
alta despre etape.

Tehnici

23
<Metodologii pt. dezv. sist. încorporate>
PRINCE 2 <Florin Ostafi>

Componente Cod Procese Tehnici

ORGANIZARE SU LANSAREA PROIECTULUI

PLANIFICARE PE PRODUS
PLANURI IP INIŢIEREA PROIECTULUI

TIPURI DE CONTROL DP DIRECŢIONAREA PROIECTULUI

MANAGEMENTUL CONTROLUL SCHIMBĂRII


ETAPE SB
FRONTIERELOR ETAPEI
MANAGEMENTUL
RISCULUI CS CONTROLUL ETAPEI
TEHNICI DE VERIFICARE A
CALITATE MANAGEMENTUL PREDĂRII CALITĂŢII
MP
PRODUSULUI
MANAGEMENTUL
CONFIGURAŢIEI CP ÎNCHEIEREA PROIECTULUI
TEHNICI DE ARHIVARE A
PROIECTULUI
CONTROLUL SCHIMBĂRII PL PLANIFICAREA

24
PRINCE 2 versus PMBOK <Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

PMBOK PRINCE 2
Focalizată pe domeniile de risc principale; nu
Completă se pretinde a fi completă;
Strict prescriptivă, în special în structura
Descriptivă în principal; prescriptivă la un nivel proceselor, dar adaptabilă la proiecte de orice
înalt dimensiune
Este necesară adaptarea la necesităţile Este necesară adaptarea la necesităţile
proiectului proiectului

Axată pe cerinţele clienţilor Axată pe justificarea economică

Proprietar clar al proiectului


Sponsori şi persoane interesate - stakeholders
Direcţionare de către conducerea companiei

Standard Internaţional US Standard UK

25
PRINCE 2 versus PMBOK <Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

Domenii PMBOK Componente PRINCE 2

Integrare Procese şi componente combinate,


Controlul schimbării
Obiective, Timp, Costuri Planuri, Etape

Calitate Calitate, Managementul configuraţiei

Risc Risc

Comunicare Tipuri de control

Resurse umane Organizare (limitată)

Achiziţii Neacoperită

26
PRINCE 2 versus PMBOK <Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

Grupuri de procese Procese PRINCE 2: nivel de Procese PRINCE 2: nivel de


PMBOK proiect etapă
Managementul frontierelor etapei,
Iniţiere Lansare, Direcţionare
Direcţionare
Managementul frontierelor etapei,
Planificare Iniţiere, Planificare
Planificare
Execuţie / Monitorizare Control etapă, Managementul predării
Etapă cu etapă
şi control produsului, Direcţionare

Încheiere Încheiere proiect Managementul frontierelor etapei

27
Metodologii Agile <Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

Proces de dezvoltare rezistent la


schimbări

Se utilizează atunci când:


 Cerinţele sunt stabile
 Tehnologia este bine
Metodele inginereşti planifică procesul cunoscută şi matură
de dezvoltare software în cele mai  Totul se întâmplă după
mici detalii aşteptări
 Nu se ia în considerare nimic
nou şi/sau necunoscut
 Au mai fost realizate astfel de
proiecte

Riscul de a le utiliza într-un mediu


dinamic este foarte mare

28
Metodologii Agile <Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

Metodologiile AGILE
 pregătite pentru schimbări – metode adaptive
 orientate spre oameni mai degrabă decât spre proces
 rolul proceselor este de a ajuta echipa de dezvoltare în a-şi face treaba

 XP | Extreme Programming
 DSDM | Dynamic System Development Method
 FDD | Feature Driven Development
 SCRUM

 Crystal Clear
 Adaptive Software Development
 Lean Software Development
 RAD - Rapid application development
 TDD - Test Driven Development

29
Metodologii Agile <Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

Principiile AGILE
 Inovare continuă – asigurarea cerinţelor curente ale clientului
 Adaptabilitatea produsului - asigurarea cerinţelor viitoare ale clientului
 Îmbunătăţirea timpului de lansare pe piaţă – pătrunderea pe piaţă la
timpul potrivit şi îmbunătăţirea rentabilităţii investiţiei
 Adaptabilitatea personalului şi a proceselor – răspuns rapid la
schimbările produsului şi afacerii
 Rezultate sigure – asigurarea creşterii şi profitabilităţii afacerii

Declaraţia de Interdependenţă Manifestul AGILE

www.apln.org http://www.agilemanifesto.org

30
Metodologii Agile <Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

Manifestul AGILE
1. Satisfacerea clientului este obiectivul prioritar al dezvoltării unui sistem software.
2. Schimbarea cerinţelor este acceptată chiar în fazele târzii ale dezvoltării
sistemului. Procesele Agile utilizează schimbările în avantajul competitiv al
clientului.
3. Livrarea frecventă de software funcţional, cu frecvenţa de livrare săptămânală
sau lunară, cu preferinţă pentru termene de livrare cât mai reduse.
4. Stakeholderii şi dezvoltatorii trebuie să lucreze împreună în fiecare zi la proiect.
5. Recunoaşterea şi exploatarea competenţelor membrilor echipei de dezvoltare.
Echipa trebuie lăsată să-şi dezvolte modurile proprii de lucru.
6. Cea mai eficientă metodă de a transmite informaţiile spre şi în interiorul echipei
de dezvoltare este discuţia faţă în faţă.

31
Metodologii Agile <Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

Manifestul AGILE
7. Scrierea programului este principalul scop al unui proiect software; softul livrat este
principala măsură a progresului.
8. Procesele Agile promovează dezvoltarea susţinută. Sponsorii, dezvoltatorii şi
utilizatorii trebuie să fie capabili să colaboreze indiferent de circumstanţe.
9. Softul se dezvoltă incremental, clientul specificând care sunt cerinţele ce trebuie
incluse în fiecare increment.
10. Concentrare pe simplitate atât în programele dezvoltate cât şi în procesul de
dezvoltare. Oricând este posibil, trebuie eliminată complexitatea din sistem.
11. Cele mai bune specificaţii, arhitecturi şi modele de proiectare sunt produse de
echipele auto-organizate.
12. La intervale regulate de timp, echipa reflectează asupra posibilităţilor de
îmbunătăţire a eficienţei şi îşi ajustează corespunzător comportamentul.

32
Metodologii Agile <Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

Abordarea AGILE Abordarea tradiţională

 Indivizi şi interacţiuni  Procese şi instrumente


 Realizarea de soft  Documentaţie cuprinzătoare
 Colaborarea cu clientul  Contract negociat
 Receptivitate la schimbări  Urmărirea unui plan

Lider AGILE Lider tradiţional

 Valoare  Constrângeri

 Echipă  Taskuri

 Adaptare  Conformare

33
Metodologii Agile <Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

Măsurarea performanţei unui proiect AGILE

 Constrângerile rămân importante, dar nu ele definesc scopul proiectului. Valoare


 Constrângerile pot fi ajustate pentru a creşte valoarea furnizată clientului. (produs gata de
obiective
 Orarul poate cost
rămâne o constrângere fixată obiective lansare pe piaţă)
 orarul este fixat („timeboxed”)
 se pot ajusta obiectivele pentru a livra „dirijează”
 obiectivele cea mai mare valoare posibilă
proiectul  obiectivele pot varia
în interiorul constrângerilor
 costuldeşitimp.
orarul variază succesul - tot conformarea între
cost, orar şi obiective

cost orar orar Calitate Constrângeri


(produs fiabil, (cost, orar,
adaptabil) obiective)

“triunghiul de fier” “triunghiul de fier” “triunghiul”


clasic Agile Agile

34
Metodologii Agile <Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

AGILE versus PMBOK

Iniţiere Iniţiere – pentru autorizarea fazei /


proiectului
Planificare
Planificare – pentru determinarea
obiectivelor si stabilirea alternativelor
de lucru
Control
Execuţie – coordonare, gestionarea
oamenilor şi resurselor pentru
Execuţie
urmărirea planului
Control – monitorizarea variaţiilor faţă
de plan şi aplicarea corecţiilor necesare
Încheiere
Încheiere – formalizarea acceptării fazei /
Procesele PMBOK proiectului

35
Metodologii Agile <Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

AGILE versus PMBOK Viziunea – înlocuieşte iniţierea


 determinarea viziunii asupra
proiectului
Speculaţia – înlocuieşte
 determinarea obiectivelor şi
Viziune planificarea
constrângerilor
 dezvoltarea capabilităţilor
Explorarea – cumulează
 determinarea modului în care
şi/sau a unui
Proiectarea, plan de livrare şi
Implementarea
va lucra echipa
bazat pe funcţionalităţi care
Testarea
Speculaţie Plan livrare Explorare Adaptarea
să ducă la- îndeplinirea
revizuirea: viziunii
 planificarea şi livrarea unor
 rezultatelor livrate
versiuni testate (iteraţii
 rezultatelor curente
scurte)
Acţiune  performanţelor echipei
Story Adaptare  urmărirea reducerii riscurilor
Backlog adaptivă
“Story-uri” şi a incertitudinilor
Încheiere proiectului
– conţine activităţile
Completate
necesare închiderii proiectului

Produs final Încheiere

Fazele Agile
Sursa: J. Highsmith, Agile Project Management: Creating Innovative Products, Second Edition,
2009

36
Metodologii Agile <Metodologii pt. dezv. sist. încorporate>
<Florin Ostafi>

Grupuri Activităţi MP clasice Activităţi MP Agile


procese
Iniţiere  Definirea documentului de autorizare a  Definirea viziunii asupra proiectului
proiectului - “project charter”  Definire scopuri, borne de control principale
 Definire “project charter”
Planificare  Plan de management al proiectului  Planificare redusă la start; planificare continuă
 Definire obiective/cerinţe  Ghid de luare a deciziilor
 Proces de control al schimbării  Implicarea stakeholder-ilor
 Schimbările sunt aşteptate
Execuţie  Managerul de proiect direcţionează şi  Iteraţii scurte; livrare incrementală
administrează execuţia proiectului  Utilizatori integraţi în echipă; livrare rezultate
 Echipa livrează rezultate şi le supune spre  Managerul de proiect - lider şi ”facilitator”
acceptare utilizatorilor  Echipa este auto-organizată
Control  Raportare stare proiect  Întâlniri zilnice
 Monitorizare buget, obiective, orar,  Actualizare stare proiect cel puţin lunar
calitate, resurse, risc  Etapă formală de revizuire şi acceptare
 Acceptare livrabile  Înregistrare probleme şi acţiuni
 Valoare dobândită  Rata rentabilităţii
Încheiere  Lecţii învăţate  Lecţii învăţate la încheierea fiecărei iteraţii
 Închidere proiect  Încheierea proiectului la sfârşitul ultimei iteraţii

37