MDSI C1.pps

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
<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
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
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
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
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
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
Livrare i
8
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
<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
<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
<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
<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
<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
<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
<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
<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
<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
<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
<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

MDSI C1.pps

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

MDSI C1.pps

Încărcat de

Drepturi de autor:

Formate disponibile

Metodologii pentru dezvoltarea

Modelarea procesului de dezvoltare

Modele de dezvoltare a sistemelor software

Analiza Modelul cascadă

Prototipul - produs dezvoltat Testarea

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

Analiza Validare cerinţe Testarea de

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

Determinare obiective, Evaluare alternative

Combină avantajele: Analiza risc (AR)

 dezvoltării incrementale AR Prototip (PR3) Prototip

Modelul RUP (Rational Unified Process)

Etapa inginerească Etapa de producţie

Milestone Milestone Milestone Milestone

Etapa inginerească Etapa de producţie

Milestone Milestone Milestone Milestone

Iniţiere Elaborare Construcţie Tranziţie

Disciplinele şi fazele RUP

 Aceste discipline nu sunt

PMBOK – A Guide to Project Management Body of Knowledge

Domenii Grupuri de procese

Managementul Planificare calitate Asigurare Control calitate

Domenii Grupuri de procese

Managementul Planificare Distribuire Raportare performanţă

Managementul Planificare Monitorizare şi control

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

PRojects IN Controlled Environments - proiecte în medii controlate

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

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

PRINCE oferă proiectelor următoarele avantaje:

Managerii de proiect care folosesc PRINCE sunt capabili:

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

Persoanele care vor fi direct implicate în utilizarea rezultatelor

Pentru persoanele din conducere, PRINCE foloseşte conceptul de

Elemente comune ale proiectelor conform PRINCE2

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

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

Componente Cod Procese Tehnici

ORGANIZARE SU LANSAREA PROIECTULUI

TIPURI DE CONTROL DP DIRECŢIONAREA PROIECTULUI

MANAGEMENTUL CONTROLUL SCHIMBĂRII

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

Proprietar clar al proiectului

Standard Internaţional US Standard UK

Domenii PMBOK Componente PRINCE 2

Integrare Procese şi componente combinate,

Calitate Calitate, Managementul configuraţiei

Comunicare Tipuri de control

Resurse umane Organizare (limitată)

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

Încheiere Încheiere proiect Managementul frontierelor etapei

Proces de dezvoltare rezistent la

Se utilizează atunci când:

Riscul de a le utiliza într-un mediu

Declaraţia de Interdependenţă Manifestul AGILE

Abordarea AGILE Abordarea tradiţională

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

Lider AGILE Lider tradiţional

Măsurarea performanţei unui proiect AGILE

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

cost orar orar Calitate Constrângeri

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

AGILE versus PMBOK