MP All

Management de proiect - Curs 1
Management
de proiect
1
Cuprins
• Definire “Proiect” si “Management de proiect”
• Componentele managementului de proiect
• Etapele managementului de proiect
• Succes si esec in mangementul de proiect
Introducere
http://in4mation.co.uk
/humour/project.htm
DEFINIRE
“PROIECT”
“MANAGEMENT DE PROIECT”
Definirea unui proiect
• Def. conform standardului UK 6079-2:2000
– Un proiect reprezinta un proces unic ce consta intr-un set de
activitati coordonate si controlate, cu inceput si sfarsit bine
definit, intreprins pentru a atinge un obiectiv in concordanta
cu cerinte clare, incluzand constrangeri temporare , de cost si
resurse.
• Def. conform standardului SUA ANSI/PMI 99-001-2008

– Un proiect reprezinta o
activitate temporara, realizata
cu scopul de a crea un produs,
serviciu sau rezultat.
Definirea unui proiect
Un Proiect se refera, in sens general, la:
o ansamblul operatiunilor desfasurate intr-o organizatie, in
vederea realizarii unui obiectiv.
Definire: Management de
proiect
Definitie
(conform PMBOK: A Guide to the Project Management Body of
Knowledge)
• Managementul de proiect reprezinta aplicarea cunostintelor,
competentelor, calificarilor, tehnicilor si instrumentelor in
coordonarea activitatilor unui proiect pentru atingerea
obiectivelor asumate.
Caracteristici ale unui proiect
Caracteristici ale unui proiect:
o presupune efectuarea unei activitati temporare
o are un inceput si un final
o unic – in general, nu presupune activitati de rutina
o are un rezultat bine definit:
o produs, serviciu ( sau alt tip de rezultat),
o Modalitatea de prezentare / predare este denumita generic
“livrabil”.
o finalul este reprezentat de atingerea ( sau nu ) a
obiectivelor, in contextul dat
o are alocate resurse: financiare, umane, materiale
Caracteristici ale unui proiect
Timp
Resurse
Finante
REZULTAT
COMPONENTELE MANAGEMENTULUI
DE PROIECT
Componentele
managementului de proiect
• Managementul de proiect presupune:
– Initializarea proiectului,
– Planificarea proiectului,
– Executia proiectului,
– Monitorizarea si controlul proiectului
– Incheierea proiectului
• PROIECT
– planificare
• MANAGEMENT
– rezultatul obtinut este cel descris in etapa
de planificare
Componentele
managementului de proiect
• Abordarea managementului de proiect din perspectiva
sistemica presupune urmatoarele componente:
– Subsistem organizational
– Subsistem de control
– Subsistem informational
– Subsistem metodologic
– Subsistem cultural si de mediu
– Subsistem de planificare
– Subsistem uman
– Sistem tehnologic
Management de proiect
• Subsistem organizational
– Utilizarea resurselor organizatiei
• Ex: Buget, echipamente
– Utilizarea structurilor functionale ale organizatiei
• Ex: Departamente, echipe de lucru
– Matrice organizationala
• Ex: roluri, functii
• Subsistem de control
– Standarde de performanta
– Masurarea performantei
• Ex: Evaluari periodice
– Mecanism de feedback
• Ex: rapoarte de activitate
– Masuri de corectare
• Subsistem informational:
– Gestiunea informatiei pentru planificare si monitorizare
– Informatie formala si informala
– Sisteme suport decizie
• Subsistem metodologic
– Metode de evaluare si estimare a planificarii
– Metode de estimare a costurilor si resurselor
– Metode de evaluare a riscului si a calitatii
• Subsistem uman
– Cunostinte
– Tehnica de management si leadership
– Comunicatie, set de valori, motivatie
• Subsistem cultural si de mediu
– Filozofie de management
– Context social: perceptii, atitudini, prejudecati, presupuneri, experiente,
valori ….
– Comportamente: actiuni, reactii
– Educatie, training, munca in echipa
• Subsistem de planificare:
– Identificarea necesarului de resurse
– Alocarea resurselor pe toata durata proiectului
– Plan de realizare: componente ale proiectului
– Plan complet de proiect
• Subsistem tehnologic
– Tehnologia aplicata in proiect
– Managementul cunostintelor
Componente ale managementului de proiect:
• Managementul integrarii componentelor proiectului
• Managementul continutului
• Managementul resurselor
– Managementul timpului alocat
– Managementul financiar
– Managementul resurselor materiale si achizitii
– Managementul resurelor umane
• Managementul calitatii
• Managementul comunicarii
• Managementul de risc
• Managementul grupului tinta
Conform Project Management Institute (PMI) Conform PMBOK. Ref 1
• Evolutia tehnologiei a dus la completarea componentelor
managementului de proiect cu elemente preluate din
domenii conexe:
– Managementul calitatii totale
– Inginerie concurenta
– Managemetul schimbarii
– Managementul lantului de aprovizionare
– Managementul proceselor de afaceri
– Analiza cost – beneficii (ROI: Return Of Investment)
• Managementul calitatii totale (Total Quality Management)
– Actiunile ce trebuie intreprinse pentru ca un rezultat sa
indeplineasca asteptarile clientului.
• Inginerie Concurenta (Concurrent Engineering):
– Organizarea activitatilor in paralel pentru a imbunatati
performanta fara a genera riscuri suplimentare.
• Managementul schimbarii (Scope Change Control):
– Controlul schimbariilor ce vor afecta rezultatul final oferind
valoare adugata.
• Management de risc (Risk Management):
– Identificarea, cuantificarea si raspunsul la situatii de risc
“Methodologies do not manage projects; people do.

It is the corporate culture that executes the methodology”
Beneficii ale managementului de proiect:

– “time to market” mai bun
– Reducere a riscului asociat
– Imbunatatirea procesului de luare a deciziilor
– Client multumit
– Timp investit in productie si nu in birocratie
Proiect vs portofoliu
Nivel tactic Nivel operational

Nivel strategic
Subproiect
Proiect
Portofoliu Subproiect
Proiect
Subproiect
Program Proiect
Subproiect 20
Program (nivel tactic)
o un grup de proiecte din aceeasi arie, conduse coordonat,
pentru a obtine beneficii suplimentare.
Subproiecte:
o componente ale unui proiect ce pot fi mai usor controlate
Portofoliu (nivel strategic):

o colectie de proiecte sau programe, nu neaparat
interdependente, grupate impreuna pentru a eficientiza
managementul in concordanta cu obiective strategice de
afacere. 21
• Infrastructura necesara pentru managementul de portofolii:
– 1. Sistem de management de portfoliu
– 2. Sistem de management de proces
– 3. Sistem de management organizational
– 4. Sistem de management al performantei
• Etapele managementului de portfoliu

– Proces de pregatire (business case)
– Proces de selectie
– Proces de prioritizare
– Proces de planificare si alocare de resurse la nivel de organizatie
ETAPELE UNUI PROIECT
Etapele unui proiect
Probleme ce trebuie adresate:
Asteptarile clientilor
Capacitatea clientilor
Intelegerea cerintelor
Necesitatile curente
Management al schimbarii
Resursele
Management de risc
Initierea proiectului
Management de calitate
Rol si responsabilitati
Estimari
Implicare management
Monitorizare
Pierdere de personal cheie
Etapele unui proiect
Activitate
Idea proiectului
Initializare
Doc
Schita
de proiect
Planul de proiect
Doc
Plan
Implementarea de proiect
Monitorizare
proiectului
Produs
Doc
Finalizare Serviciu
Timp
proiectului Livrabile
Etapele unui proiect in cadrul
unei organizatii
Fezabilitate /
Creaza Idee Solutie Impact Risc Resurse
Analiza Analiza Selectare Prioritati

Selecteaza Constrangeri
de cost de risc solutie strategice
Etape Resurse Solutie tehnica Risc

Planifica
Schimbare Comunicare Calitate
Implementeaza /
Monitorizare Schimbare Raportare Vizibilitate
Management
Relocare Lectii
Inchide Documente Arhive
resurse invatate
Idea proiectului
Sponsor
• Toate proiectele au un sponsor.
• Sponsorul reprezinta o persoana sau entitate ce
indeplineste urmatoarele caracteristici:
– identifica o necesitate de schimbare
– are autoritatea necesara de a schimba
– Este capabil sa finanateze sau sa atraga surse de
finantare
Nothing is impossible for the person who doesn’t have to do it.
Idea proiectului
▪ Sponsorul poate avea:

- Definitie clara a obiectivelor proiectului
- Imagine corecta asupra cerintelor proiectului
versus -Viziune incomplet asupra proiectului

- Cerinte de proiect slab definite sau structurate
▪ Sponsorul trebuie:
▪ Asistat in definirea clara a obiectivului / rezultatelor proiectului
▪ Definirea coerenta cerintelor proiectului
Idea proiectului
Grup de lucru:
-Initiatori
-Stakeholder
-Consultanti
Idee
Contract Schita
de
Oprotunitate de afaceri / proiect
Schita
Business Opportunity
de proiect
Caz de afaceri /
Business Case Schita
stake-
holder
Necesitate
Factori interni
organizatiilor
Factori externi Stakeholder
organizatiilor
Idea proiectului
Schita de proiect (project charter):

•Un document care autorizeaza in mod formal proiectul
Include:
▪Necesitatea proiectului “business need”
▪Descrierea proiectului
▪Obiectivele proiectului
▪Desemneaza echipa de proiect
▪Identificat rezultate, buget, durata
Contractul poate reprezentat schita de proiect

30
Idea proiectului
Schita de proiect poate cuprinde:
• Mandatul
• Scop si obiective
• Descriere
• Rezultate
• Beneficii
• Timp
• Control
• Prioritizare
• Realizare “sanity check”
• Permisiune de incepere
Idea proiectului
Necesitate
De unde pornim?
Cerinte
Specificatii Constangeri
Rezultate / Livrabile
Definitii
Cerinte: O descriere documentata formal a nevoilor sponsorului
ce vor fi adresate in cadrul proiectului
Specificatii: O descriere detaliata a functionalitatilor ce vor fi
implemetate
32 in proiect / trasturilor proiectului
Idea proiectului
Identificarea cerintelor:
•De ce facem proiectul?

•Care este rolul dumneavoastră în afacere şi proiect?
•Ce funcţionalitatea şi rezultatele sunt necesare ?
•Cine sunt părţille implicate.?
•Ce fel de impact financiar are acest proiect asupra organizaţiei
dumneavoastră?
•Poate infrastructura existenta sprijini nevoile dumneavoastra?
•Ce sprijin din exterior este necesar?
•Cum definim succesul?
•Cat timp dureaza?
•Sunt alte produse similare aflate deja în dezvoltare sau operare?
•Care este criteriului de finalizare?
33
Urmatorul pas este catalogarea in cerinte si constrangeri
Planul de proiect
Grup de lucru:
-Echipa de planificare de proiect
-Stakeholder
-Consultanti externi
Management al integrarii
Plan de
Resurse umane
Plan de
Plan de
calitate
comunicare
risc
Schita Plan de Plan

Buget
de achizitii de
proiect
proiect
Plan de desfasurare
Plan de activitati
-interne organizatiilor
Constrangeri -de parteneriat
-mediu de afaceri
Echipa de planificare de proiect este formata din:
- Manager de proiect - Consilieri tehnici
- Consilier financar - Consilier juridic
Implementare proiect
Monitorizare
iteratii Management de calitate Doc
Management al comunicarii
Plan
de Management de cost Serviciu
proiect
Achizitii Resurse umane Produs
iteratii Implementare activitati Livrabile
Management al
schimbarii
SUCCES SI ESEC IN MANGEMENTUL
DE PROIECT
Criterii de succes pentru un proiect:
▪ Sa se finalizeze conform graficului stabilit
Criterii de ▪ Sa se finalizeze in parametrii de buget
▪ Sa se finalizeze cu resursele umane
succes allocate
▪ Sa produca rezultate conforme cu criteriile
de performanta
▪ Sa indeplineasca cerintele clientului –
acceptanta
▪ Sa nu afecteze desfasurarea altor activitati
din companie
▪ Sa nu afecteze cultura organizationala
Criterii ▪ Principalele motive de insucces in
pentru cadrul proiectelor sunt:
▪ Neindeplinirea a cel putin un
esec criuteriu de success ?

▪ Managementul de proiect defectuos
▪ Managementul resurseri umane
– Oameni
• motivare, lipsa calificare, eroi, prea
tarziu, angajatul problema, politica
Criterii companiei, neintelegeri client-
dezvoltator
– Proces
pentru • planificare optimista, management de
risc, defecte in planificare, “voi recupera”
esec – Produs
• dezvoltare – cercetare, mai mult decat
poti
– Technologie
• schimbarea de tool-uri in mijlocul
proiectului, insuficienta cunoastere a
tool-urilor, supraestimarea
39
Succes si esec in mangementul
de proiect Studiu de caz
• Project Management Performance Statistics
• What is the average failure rate of a project? Among successful projects,
what factors have the biggest impact on success? Let’s see!
• Project performance has been rising globally. In 2018, nearly 70% of
projects met their original goals or business intent, while nearly 60%
were completed within the original budget. Both these figures are up
from 62% and 50% respectively in 2016. (PMI)
• IT projects are notoriously difficult to manage. A survey published in HBR
found that the average IT project overran its budget by 27%. Moreover,
at least one in six IT projects turns into a “black swan” with a cost overrun
of 200% and a schedule overrun of 70%. (HBR)
• Poorly training project managers, attempting too many projects, and a
lack of project funding are the top three project management challenges
in Wellingtone’s survey. (Wellingtone)
https://medium.com/crowdbotics/hips-dont-lie-15-project-management-stats-you-can-t-ignore-6f655060ef30
de proiect Studiu de caz
• Among IT projects, failure rate corresponds heavily to project size. An
IT project with a budget over $1M is 50% more likely to fail than one
with a budget below $350,000. For such large IT projects, functionality
issues and schedule overruns are the top two causes of failure (at 22%
and 28% respectively). (Gartner)
• A PwC study of over 10,640 projects found that օnly 2.5% of companies
complete their projects 100% successfully. The rest either failed to meet
some of their original targets or missed the original budget or deadlines.
These failures extract a heavy cost — failed IT projects alone cost the
United States $50-$150B in lost revenue and productivity. (Gallup)
• Among IT projects, project performance varies significantly. While
software projects have an average cost overrun of 66%, the same figure
for non-software projects is 43%. However, 133% of non-software
projects fail to meet their stated benefits, compared to just 17% for
software projects. (McKinsey)
• 17% of IT projects can go so bad that they can threaten the very existence
of the company. (McKinsey)
https://medium.com/crowdbotics/hips-dont-lie-15-project-management-stats-you-can-t-ignore-6f655060ef30
de proiect
Sponsor
Echipa de proiect
este un criteriu
important pentru Manager de
proiect
success sau esec
Echipa Echipa
Echipa suport
functionala administrativa
de proiect
Manager de proiect:
Managerul de • Face lucrurile sa se intample
• Priveste lucrurile cum se intampla
proiect (MP) • Nu stie sau nu ii pasa de ce se intampla
•Capacitate de a asculta •Integritate

Calitati •Capacitate de a analiza •Organizator
ale MP: imaginea de ansamblu •Receptiv “open-minded”
•Implicarea in detalii •Constient ca poate gresi
•Capacitatea de a decide •Pozitiv
•Determinare •Entuziast
•Capacitate de comunicare •Orientat spre rezolvarea
•Conducere prin exemplu problemelor
de proiect
• Tehnici de management: Aptitudini

– Consistenta
• Leadership
– Echitatea
– Viziunea • Capacitate de analiza
– Acceptarea de noi idei • Gandire sistemica
– “Empowerment” • Negociere
– Mesajele • Mentoring
– Managementul de personal
• Expertiza tehnica si de
– Managementul dezvoltarii companiei
proces
– Integrarea
– Performanta
Management de proiect - Curs 2
Ideea
proiectului
Structuri organizationale
Ideea proiectului si inovarea

Cuprins
Ciclul de viata al produselor
Structurarea ideii de proiect

Managementul de proiect si organizatia
De ce ?
• Managementul de proiect presupune
Pentru a obtine rezultatele
urmatoarele elemente principale: dorite in mod eficient.
• Planificare
• Organizare
• Alocare de resurse
• Monitorizare / control
• Actiuni de corectie Resurse ale unei companii:
• Resursa umana
• Resursa financiara
Resursele nu sunt direct controlate de • Echipamente
• Facilitati
managerul de proiect • Resurse materile
• IT
Organizatia = grup de oameni care isi coordoneaza
activitatile pentru a atinge obiectivele stabilite
(obiective organizationale)
Elemente cheie
Structura Autoritatea
Responsabilitate Raspundere
organizationala (Authority) este puterea de
(Responsibility) este obligatia
persoanelor asociata cu
(Accountability) masura
indeplinirii satisfacatoare a
decizie oferita persoanelor executarea activitailor
unei activitati
alocate
Structura unei organizatii este reprezentata sub forma

unui Diagrame Organizationale ( Organization Charts )
• Pozitiile de management dintr-o organizatie:

• “Top management” sau “Senior management” sau “Executive
management” sau “Management team”
• Stabileste strategii
• “Middle management” Top
• Realizeaza planuri
• “Supervisors” Middle
• Implementeaza planurile
• Implementare
Opertation
Structura verticala
vs
Structura orizontala
• Echipa de management sau “C-level”:
• Chief Executive Officer (CEO)
• Raspunde de intreaga companie si raporteaza direct catre presedinte
( chairman ) si consiliu de administratie ( board of directors )
• Chief Financial Officer (CFO)
• “Senior vice-president”, se ocupa de analiza financiara, evaluarea
performanetelor financiare si executia bugetara
• Chief Procurement Officer (CPO)
• Rol in coordonarea achizitiilor si a lantului de aprovizionare
• Chief Operations Officer (COO)
• “Senior vice-president”, conduce departamentele de marketing,
vanzari, productie si resurse umane. and
• Chief Legal Affairs (CLA):
• Conduce departamantul juridic
• Chief Information Officer (CIO)

• Gestioneaza resursele tehnologice ( in general IT ) necesare
functionarii companiei
• Chief Technology Officer (CTO)
• Raspunde de problemele stiintifice si tehnice dintr-o companie.
• Chief Revenue Officer (CRO)
• Raspunde de activitatile generatoare de venit dintr-o companie,
inclusive de integrarea afacerii.
• Chief Visionary Officer (CVO)
• Coordoneaza activitatile legate de formarea sau actualizarea
componentelor viziunii si strategia companiei.
Alte functii “c-level”:
chief chief business chief

chief brand chief sales chief marketing
administrative development communications
officer (CBO), officer (CSO), officer (CMO),
officer (CAO), officer (CBDO), officer (CCO),
chief human
chief risk officer chief creative chief compliance chief audit chief diversity
resources
(CRO), officer (CCO), officer (CCO), executive (CAE), officer (CDO),
officer (CHRO),
chief chief information

chief content chief accounting chief analytics chief strategy
commercial security officer
officer (CCO), officer (CAO), officer (CAO), officer (CSO)
officer (CCO), (CISO),
• Dupa modul de organizare se pot enumera urmatoarele structuri:

• Structura traditionala
• Structura departamantala
• Structura organizationala cu depatament de legatura
• Structura organizationala cu coordonator de proiect
• Structura de organizare orientata catre produs
• Organizare matriciala
• Organizare matriciala modificata
Structura traditionala Management
Vanzari si
Divizie Financiar Suport Inginerie …
marketing
…
Departament
Sectiune
Echipa
Structura traditionala
Avantaje Dezavantaje
• Buget si control al costurilor relativ simplu. • Nu exsita o singura persoana
• Continuitate in proceduri, politici, raspunzatoare pentru tot proiectul
responsabilitati. • Deciziile favorizeaza de obicei cel mai
• Control al resursei umane: un singur sef puternic grup
pentru fiecare angajat • Nu este orientat client
• Canalele de comunicatie sunt verticale si • Motivarea si inovarea sunt scazute
bine definite
Divizie Manager divizie
Management
departamantal
Departament Departament … Departament
Departament
…
Sectiune
Echipa
Depatament de legatura
Management
Divizie …
Vanzari si … Departament
Financiar Inginerie
marketing Legatura
Structura organizationala
Coordonator de proiect
Manager Divizie
Manager
proiect
Manager de Manager de Manager de

departament departament departament
Organizare orientata produs
Manager
Manager de
Manager de produs … Manager de produs
produs
…
Exemplu de structura de
organizare orientate
catre produs
Organizare matriciala Manager

general
Divizie Divizie … Divizie

…
Manager proiect
Manager proiect
Manager proiect
Exemplu: Proiect vs organizatie

Manager
Organizare general
matriciala
modificata Divizie de Divizie Divizie … Divizie
management de
proiect …
Manager
proiect
Manager
proiect
Manager
proiect
Exemplu de
organizare matriciala
Ideea proiectului si
inovarea
Ideea proiectului
• Proiectul poate incepe ca o:

• Necesitate
• Idee de afacere
• Idee de produs
• Formare profesionala
• Solutie socio-economica
• …
Ce reprezinta inovarea?
• Inovația reprezinta atat procesul cat și rezultatul creării a ”ceva” nou,

cu valoare determinata.
• ”Innovation involves the whole process from opportunity
identification, ideation or invention to development, prototyping,
production marketing and sales, while entrepreneurship only needs
to involve commercialization” (Schumpeter).
• Inovația = Inventie + exploatare (Ettlie)

De obicei inovarea se refera la produse sau procese noi,
dar recent inovarea se aplica si la modele de afaceri, mai
precis la modul în care o firmă oferă plus-valoare.
Astfel inovația a fost extinsa la:

Ce • un produs nou,
reprezinta • Un serviciu nou
• un nou proces,
inovarea? • deschiderea unei noi piețe,

• nou mod de organizare a afacerii
• noi surse de aprovizionare
•…
Inovarea se poate realiza si prin combinare

Aspecte Concurența
financiare • Exemplu: piata,
produse
Migrarea valorii
• reducerea costurilor,
creșterea eficienței,
Factori
determinanti Reglementarea
pietei
Necesitatea
socio-economica
Responsabilitate
sociala
pentru
inovare
Schimbari
Creșterea
Schimbări economice
așteptărilor
sociale • Criza economica
clienților
Disponibilitatea
tehnologiilor
Tipuri de inovare
• Inovarea la nivel de produs

• Exemplu: Dezvoltarea unui produs nou sau îmbunătățit
• Inovarea la nivel de proces

• Exemplu: Dezvoltarea unui nou proces de fabricație
• Inovarea organizațională
• Exemplu: O nouă diviziune a muncii, o nou sistem intern de comunicatii;
• Inovarea la nivel de management

• Exemplu: managementul calității totale (tqm)
Tipuri de inovare
• Inovarea în producție
• Exemplu: sistem de fabricație, software de planificare a producției
• Exemplu: sistem de inspecție
• Inovarea comerciala / de marketing

• Exemplu: Noi modalități de finanțare, noi modalități de vânzări: marketing direct
• Inovarea la nivel de servicii;

• Exemplu: Internet banking etc.
Ciclul de viata al
produselor
Ciclul de viata al produselor
Concepere Proiectare
Design detaliat
Specificație
Validarea și analiza
Design conceptual
Instrument de proiectare
Dezvoltare Service
Vinzare
Planul de
fabricație Livrare Reciclare
Fabricare Utilizare
Asamblare Mentenanta /
Testare suport
PLM
viziune Capgemini
https://www.capgemini.com/service/digital-services/digital-engineering-and-
manufacturing-services/product-lifecycle-management/
CICLUL DE DEZVOLTARE
AL PRODUSELOR
Etape:
1. Generarea ideii si analiza ideii
2. Dezvoltarea conceptului și testarea
acestuia
3. Dezvoltarea strategiei de marketing
4. Studiu de fezabilitate
5. Dezvoltare produsului - prototip
6. Teste de marketing
7. Comercializare
ETAPA 1
IDENTIFICAREA OPORTUNITĂȚII ȘI
GENERAREA IDEII
• GENERAREA IDEII
• apar noi oportunități de produs
• se generează idei de produse noi pe baza nevoilor clientului.
• angajații proprii identifica oportunități și idei.
• Rolul marketingului
• reduce incertitudinea
• surprinderea corectă a punctelor de vedere ale clienților, furnizorilor și angajaților
• Provocări ale evaluarii nevoile clientului:
• Clienții încă își formează preferințele și își pot schimba opiniile până la lansarea produsului
• poate fi dificil pentru clienți să-și structureze și să-și exprime adevăratele preferințe
• Procesele aferente poate fi intruzive,
• In procesul de colectare de informații pot interveni propriile prejudecăți ale analistilor.
• Tehnici de colectare a datelor:
• Interviuri experimentale
• Design empatic sau observație a comportamentului utilizatorilor
Ref:
http://www.mit.edu/~hauser/Papers/Chapter%208%20Hauser_Dahan%20Book%20Chapter%20on%20New%20Products.p
df
ETAPA 2:
CONCEPTUL PRODUSULUI
• CONCEPTUL DE PRODUS
• modul de abordare si solutiile la nevoile clientilor.
• metodele formale pentru analiza si generarea de concepte noi de produse,
• Idei modelate, analizate și perfecționat în oportunități viabile.
• Importanta este varietatea de idei.
• Metode:
• brainstorming
• idei compatibile si stimulentele,
• analiza morfologică
• relații forțate,
• abordări sistemice,
• perspective diferite și
• analiza arhivistica si documentarea solutiilor existente
ETAPA 2:
• Definirea conceptului
• informațiile necesare pentru a înțelege nevoile relevante ale clienților
• explică / dovedește modul de a răspunde la nevoile clientilor
• motivarea utilizarii produsului de catre client ( rațional sau emoțional )
• definește și comunică beneficiile conceptului (concept’s core benefit proposition CBP),
beneficiile cheie ale produsului, bazate atât pe nevoile clienților, cât și pe concurență.
• Prezentarea conceptului:
• Definirea pieței țintă și a potentialilor clienți.
• Identificarea competiției și formarea unei strategiide competitive.
• Dezvoltare tehnică preliminara a produsului și testarea
• Estimarea resurselor necesare.
• Crearea unui plan de afaceri preliminar.
ETAPA 2:
• Evaluarea conceptului
• analiza sondajelor,
• Exemplu: un eșantion reprezentativ de respondenți sunt rugati sa evalueze un
numar de concepte
• cercetării piețele testelor de laborator (laboratory test markets LTM).
• modelarea pietei de desfacere
• Estimarea si predictia
• estimarea potențialuli de venituri și profit
• clasifica conceptele:
• merită în mod clar dezvoltarea ulterioară,
• merită renunțat
• Este nevoie de mai multe date.
• Exemplu de rezultat: prognoză de vânzări.
ETAPA 3:
DEZVOLTAREA STRATEGIEI DE MARKETING
• Plan de marketing
• distribuția produselor
• stabilire a prețului
• promovarea produselor
• Canale de distributie:
• Angro.
• cumpara produse de la producători, în cantități mari, și vinde către comercianții
• Agenți.
• piețele internaționale - comenzi pentru produse și comisioane de la producător
• Comercianții cu amănuntul. (Retail)
• relație directa cu clienții - diferite produse și mărci în stoc
• Internetul - E-commerce
• Vânzări directe.
• direct de la fabrica producatorului
ETAPA 5:
Dezvoltarea produsului
• Tehnici
• CAD/CAM,
• Computer Aided Design / Manufacturing
• Design pentru X,
• Proiectare industriala
• “Reengineering”
• Imbunatatirea procesului de productie
• “Reverse Engineering”
• Analiza produselor competitiei
• “Bill of Material (BOM)”
• Componentele produsului: nume, cod, cantitate, UM, info ansamblare ….
Structurarea ideii de
proiect
Model de afacere
Schita de proiect
Definiție:
• Un model de afaceri descrie modul în care o
organizație creează, furnizează și captează
Model de valoare.
afacere • Poate fi descris prin 9 elemente de bază:

segmente de clienți, propuneri de valoare,
canale, relații cu clienții, fluxuri de venituri,
resurse cheie, activități cheie, parteneriate
cheie și structura costurilor.
Model de afacere - CANVAS
• Business Model Canvas

• este un șablon de management strategic și start-up pentru dezvoltarea de noi
modele sau documentarea modelelor de afaceri existente.
• instrument vizual
• elemente care descriu propunerea de valoare, infrastructura, clienții și finanțele
unei companii.
• modalitate organizată de a vă prezenta ipotezele
Business CANVAS
• Prima etapa aferenta ciclului de viata al unui
proiect este schita de proiect
• Schita de proiect are ca scop:
Schita de • Prezentarea ideilor intr-un cadru
proiect structurat
• Definirea si imbunatatirea conceptelor
• Colaborarea
• Evaluarea preliminara a fezabilitatii
Schita de proiect
• Schita de proiect cuprinde urmatoarele:
Stakeholders -
Lista de
Context Obiective Durata rol si
rezultate
responsabilitati
Presupuneri Schita de plan

Milestones Schita de buget Riscuri
Constrangeri de comunicare
Lista de
Aprobari
STUDIU DE
CAZ
Schita de
proiect
https://www.smartsheet.com/blog/project-charter-templates-and-guidelines-every-
STUDIU DE
CAZ
Schita de
proiect
https://www.smartsheet.com/blog/project-charter-templates-and-guidelines-every-
business-need
STUDIU DE CAZ
Schita de proiect
Initializare
- schita de proiect
STUDIU DE CAZ
Schita de proiect
MANAGEMENT DE PROIECT - Curs 3
Managementul
continutului unui
proiect – parte 1
1
Cuprins
• Componentele
managementului
de continut
• Definirea scopului si
obiectivelor
• Definirea cerintelor
• Plan de activitati (
WBS )
• Validarea continutului
Definire
“Management de continut
• Continutul (scopul, eng: scope)
– Se refera la intreaga activitate desfasurata (descriere, metode)
pentru a crea rezultatele proiectului
• Livrabil ( eng: deliverable )

– Rezultat al unui pproiect: produs, serviciu, studiu, plan ……..
• Managementul de continut ( eng: Project scope management )

– Include metodele necesare definirii si organizarii elementelor ce
sunt sau nu sunt incluse intr-un proiect
Managementul de continut
• Definirea continutului este procesul in care se specifica criteriile
pentru finalizarea cu succes a proiectului.
• Declaratia de continut / descrierea proiectului : “scope statement”

– Document de cerinte “user acceptance requirements”
– Obiectivele proiectului
– Specificatiile generale ale rezultatului
– Etapele principale ce trebuie parcurse
– Lista de livrabile principale
Managementul de continut
Scop Obiective
Descrierea Diagrame de
Program
activitatilor retea
Buget
Schimbare Raportare Monitorizare

Componentele
managementului de continut
• Planificarea continutului ( eng: Scope planning):
– Metode de definire si validare a continutului.
• Initializare
– Ideia proiectului structurata sub forma unei schite de proiect (eng:
project charter)
• Definirea continutului ( eng: Scope definition ):
– Dezvoltarea si Completarea schitei de proiect
– Identificarea cerintelor si/sau specificatiilor
– Identificarea rezultatelor
• Definirea activitatilor (eng: WBS) :
– Identificarea activitailor necesare obtinerii rezultatelor
• Verificarea continutului (eng: Scope verification ):
– Validarea continutului documentului.
• Controlul continutului ( eng: Scope control ):
– Definirea metodelor de modificare a continutului proiectului
Declaratia de continut
• Declaratia de continut (“ Scope Statement ”) poate cuprinde:
– Scopul proiectului / Abstract
– Necesitatea proiectului
– Obiectivele proiectului
– Descrierea domeniul de aplicare / produsului / tehnologiei ………
– Livrabile
– Criterii de acceptare
– Excluderi
– Constrângeri
– Presupuneri / Ipoteze
Cuprins
• Componentele
managementului de
continut
• Definirea scopului
si obiectivelor
• Plan de activitati (
WBS )
Scopul proiectului
• Scopul reprezinta o afirmatie ce furnizeaza contextul general a ceea
ce incearca proiectul sa realizeze sau beneficiile aduse.
• “The Purpose / Mission / Goal”
• Scopul = motivul pentru care realizati proiectul
• Trebuie sa raspundeti la urmatoarele intrebari:
– Despre ce este vorba in proiect ? (pe scurt)
– Cine sunt partile interesate ( “stakeholders” ) ?
– De ce este necesar proiectul?
– Contextul proiectului?
Goals provide an overall philosophy, a concise statement to the purpose of

the whole project
Scopul proiectului
• Scop
– bine definit,
– concis
– concret,
– adreseaza rezultatele ce doresc a fi atinse si nu metodele prin care
acestea vor fi atinse.
• Scopul proiectului este foarte important deoarece trebuie sa

transmita finantatorului rezultatele proiectului si stadiul in care se
va afla problema dupa finalizarea proiectului.
Obiectivele proiectului
• SCOP SI OBIECTIV au semnificatii diferite în planificare.
• general vs specific
• Un obiectiv este un câstig concret care trebuie obtinut dupa o

perioada de timp data.
• Obiectivul permite obtinerea scopului, convertind un plan general
într-o serie de pasi specifici si usor manevrabili.
Objectives relate directly to the goals and say what you are going to do, but
not how you are going to accomplish your goals.
The Methods or Procedures section describes how
• “The project objective consists of the business benefits that an

organization expects to achieve as a result of spending time and
exerting effort to complete a project.”
http://infolific.com/technology/definitions/pm-definitions/project-objective/
• Obiectivele reprezinta afirmatii concrete ce descriu elementele ce

trebuie atinse in cadrul proiectului.
• Obiectivele trebuie formulate in asa fel incat sa poata fi evaluate
(indeplinit sau nu) la finalul proiectului.
• O tehnica pentru formularea unui obiectiv este respectarea

principiului
• SMART,  SMART
– SPECIFIC,
 Specific,
– MASURABIL,
– POATE FI ATINS,  Measurable,
– RESURSE,  Attainable/Achievable
– TIMP.  Realistic,
 Time-bound.
Mod de redactare:
Obiectivul proiectului este

[imbunatatirea, cresterea, …….] [rezultat al proiectului]
cu [%, cifra] pana la [data calendaristica]
– Exemplu: Obiectivul proiectului este cresterea vanzarilor companiei

cu 20% pana la 31.12.2013
– De obicei (!!!) se evita folosirea termenilor vagi de tipul eficientiza,
maximiza, minimiza si a perioadelor vagi de timp: trimestru,
toamna, aprilie
– Beneficiu
• Obiectivul se refera la:
– Cine va face ce, cand si cum va fi rezultatul masurat
At the end of the three-day training session (when),

workshop participants (who) will infuse quantitative
reasoning into one course (what) as determined by a
survey distributed and reviewed by a panel of
knowledgeable faculty members.
to construct a new Art Gallery

Studiu de caz
Increase attendance from the local community (what and
who) within the next five years (when) at the scheduled art
exhibits, as indicated by daily registers of attendees.
Affect the level of art appreciation (what) within the local

community (who) by offering an annual series of four
regularly scheduled lectures (when) as measured by pre-
and post-surveys of audience members.
Cercetare: Determine the impact of contaminated sewage water on

the xxx fish population in Barnegat Bay.
Identify the needs of the fish industry in preventing the
loss of these fish due to contamination.
Formulate guidelines for the wastewater treatment plant
to meet the needs of the fish industry and the xxx fish.
• Se recomanda ca obiectivul general / principal al proiectului sa

respecte urmatoarele:
– maxim 200 de caractere
– exprima ce se doreste a fi realizat în cadrul respectivului proiect.
– Beneficiile obtinute in urma finalizarii acestuia
• Obiectivul general poate fi descries folosind 2-4 obiective

specifice, formulate astfel încât rezultatul lor sa conduca la
realizarea obiectivului general.
• Tipuri de obiective ale proiectului:

– Obiective principale
• motivul pentru care realizati proiectul
– Obiective secundare
• beneficiile pe care le aduce proiectul odata cu parcurgerea unor etape
dar nu motivatia intregului proiectului
– Non-obiective
• beneficiile ce nu vor fi atinse in timpul sau la finalizarea proiectului
Exemple
• “Obiectivul proiectului: Creşterea capacităţii de inovare prin
transferul în producţie a rezultatelor CDI cu rezultate aplicabile
direct în economie.”
• „Obiectivul specific al proiectului: Stimularea inovării în cadrul

firmei X prin transferul în producţie a unui produs inovativ în
scopul producţiei şi comercializării. “
Exemple 1
• Obiectivul nr. 2: Evaluarea legăturilor dintre parametrii de intrare și
modelele finale (ex.: câmpul de temperaturi, câmpul de curgeri,
distribuția eforturilor, deformările corticale), în particular în lumina
ipotezelor noastre de lucru. Ne vom concentra asupra efectelor
reologiei și a parametrilor folosiți în paleoreconstrucții, ce exercită
efecte de prim ordin asupra evoluției tectonice.
• Obiectivul nr. 3: Explorarea implicațiilor modelelor noastre numerice

asupra studiului structurii și evoluției zonei seismice Vrancea. Vom
studia consecințele modelării numerice în stabilirea distribuției și
evoluției câmpului de eforturi. Vom investiga de asemenea legătura
dintre resultatele modelărilor și evoluția spațio-temporală a
vulcanismului în Carpații Orientali.
Validarea modelelor obținute se va realiza cu ajutorul observațiilor de
teren obținute pe infrastructura XY.
Exemple 2
• Proiectul ELI-NP urmăreşte realizarea următoarelor obiective principale:
– Construirea clădirilor infrastructurii (estimată să fie demarată la începutul anului
2013 şi finalizată la sfârşitul anului 2014).
– Achiziţionarea celor două Echipamente (două lasere de mare putere şi sistemul
fascicul gama) ca urmare a procedurilor de achiziţii publice în conformitate cu
legislaţia în vigoare. Construirea acestora se aşteaptă să fie demarată în prima parte
a anului 2013 iar finalizarea procedurilor de recepție în prima parte a anului 2017.
– Întocmirea memoriilor tehnice (Technical Design Report – TDR) pentru experimente
şi laboratoarele auxiliare.
– Promovarea viitoarelor oportunităţi de cercetare multidisciplinară pentru utilizatorii
ELI-NP.
– Implementarea strategiei de resurse umane concepute pentru a asigura forţa de
muncă necesară din punct de vedere calitativ şi cantitativ.
– Definirea şi implementarea condiţiilor necesare pentru funcţionarea ulterioară.
• Principalul obiectiv al fazei de implementare a Proiectului este de a asigura livrarea
şi punerea în funcţiune la timp a celor două lasere de mare putere şi a sistemului
fascicul gama, sincronizarea tehnică dintre acestea şi integrarea lor în cadrul
construcţiei. În plus, se va realiza proiectarea şi dezvoltarea zonelor dedicate
experimentelor ELI-NP.
Exemple 3
• Obiectivul general al proiectului constă în contribuţia la realizarea
priorităţilor reformei administraţiei publice în raport cu
descentralizarea si deconcentrarea serviciilor publice, cu
debirocratizarea actului administrativ, prin:
• 1. întărirea capacităţii administrative a Consiliului Judeţean Timiş;
• 2. facilitarea accesului cetăţenilor la furnizarea de servicii
electronice specifice administraţiei publice locale;
• 3. optimizarea managementului resurselor materiale şi umane în
cadrul Consiliului Judeţean Timiş .
• Această contribuţie trebuie să conducă la alinierea cu
standardele europene în respectul valorilor transparenţei,
predictibilităţii, responsabilităţii, adaptabilităţii şi eficienţei
promovate de acestea.
Exemple 4
• Obiectivele specifice identificate ca fiind realizabile prin
implementarea proiectului propus sunt urmatoarele:
– Furnizarea de servicii publice prin mijloace electronice;
– Facilitarea accesului cetatenilor, exponentilor mediului de afaceri si
a institutilor administratiei publice la serviciile publice furnizate de
catre institutie;
– Cresterea gradului de informare a publicului;
– Cresterea transparentei activitatilor desfasurate de catre institutie;
– Cresterea eficientei activitaţilor interne ale instituţiei;
– Cresterea eficientei furnizarii de servicii publice si a calitatii
serviciilor publice furnizate.
Cuprins
• Componentele
managementului de
continut
obiectivelor
• Definirea
cerintelor
• Plan de activitati ( WBS )
Lista de cerinte
• Cerintele unui proiect presupun identificarea sau formularea
problemei ce trebuie rezolvata:
1. Care este problema? (simptome)
2. Care este (in realitate) problema? (reducerea la componenta
principala)
3. De unde apare problema (sursa și cauza)
4. A cui este problema?
• Cele mai intalnite probleme legate de cerinte:

– Clientul nu stie ce vrea Comportament
– Cerintele sunt neclare
I Cutie neagra O
Lista de Studiu de caz
Unambiguous
cerinte Complete
Consistent
• Procesul de achizitie a cerintelor Measurable
presupune: Testable
Traceable
1. Identificare
Design Free
2. Analiza - Clarificare Understandable
3. Modelare Concise
4. Specificare Necessary
5. Validare Feasible/Attainable
Verifiable
Validatable
• Caracteristici ale cerintelor: Modifiable
– Clare Relevant
– Complete Correct
– Utilizabile Prioritized
Stable
Implementation - independent
Lista de cerinte
IEEE Recommended Practice for Software
Requirements Specifications IEEE Std 830-1998
1.Introduction
Purpose
Document Conventions
Intended Audience and Reading Suggestions
Product Scope
References
2.Overall Description
Product Perspective
Product Functions
User Classes and Characteristics
Operating Environment
Design and Implementation Constraints
User Documentation
Assumptions and Dependencies
http://www.cse.msu.edu/~cse870/IEEEXplore-SRS-template.pdf
Lista de cerinte
3.External Interface Requirements
User Interfaces
Hardware Interfaces
Software Interfaces
Communications Interfaces
4.System Features
System Feature 1
System Feature 2 (and so on)
5.Other Nonfunctional Requirements

Performance Requirements
Safety Requirements
Security Requirements
Software Quality Attributes
Business Rules
6.Other Requirements
Analiza cerintelor
• 1. Cerinte specifice individuale, definite tinand cont
de:
– corectitudine, non-ambiguitate, consistenta, grad de
importanta si/sau stabilitate, repetabilitate, modificabilitate si
urmarire
• 2. Cerintele specifice trebuie organizate logic si clar.
• 3. Fiecare cerinta trebuie redactata in asa fel incat
implementare ei sa poate fi usor verificata prin metoda
descrisa.
• 4. Trebuie mentionate sursele unei anumite cerinte.
Cerinte
• O clasificare a cerintelor specifice:
– - Cerinte functionale
– - Cerinte de performanta
– - Constrangeri de design
– - Atributii
– - Cerinte legate de interfetele cu exteriorul
Cerintele functionale
• Cerintele functionale
– Functii ale produsului ( ce va face produsul ),
– ce intrari vor fi transformate in iesiri si ce operatii sunt necesare
pentru aceasta.
• Se recomanda redactarea cerintelor pentru fiecare functie, sub
forma:
– obiectiv
– intrari:
• Ex: valori, cerinte legate de utilizator, interfete specifice
– operatii:
• Ex: verificarea validitatii, raspuns la conditii anormale, tipuri de procesare
– iesiri:
• Ex: destinatii, valori, temporizare, mesaje de eroare, interfete necesare
Interfete
• Interfete cu utilizatorul
– caracteristicile in cazul interfetei cu utilizatorii umani
– Exemplu: daca utilizatorul opereaza prin intermediul unui display,
trebuie specificate urmatoarele:
– formate ale ecranului suportate
– incadrarea in pagina si continutul unor eventuale raporturi
sau meniuri
– programarea relativa a intrarilor si iesirilor
– disponibilitatea unor eventuale taste de functii
programabile
• Interfete hardware
– specifica caracteristicile logice ale fiecarei interfete intre produs si
componentele hardware ale sistemului (ce dispozitive sunt
suportate si protocoalele respective –diagrama bloc necesara)
Interfete
• Interfete software
– Se detaliaza caracteristicile legate de:
• utilizarea altor produse software
• Interfetele cu alte sisteme
– Exemplu:
• un sistem de gestionare a datelor,
• un pachet de calcul
• Interfete de comunicare
– specificarea interfetelor de comunicare,
• Exemplu: protocoalele de retea.
Cerintele de performanta
• definirea cerintelor numerice statice si dinamice
• Cerintele numerice statice pot include, de exemplu :
– numarul de terminale suportate
– numarul de utilizatori simultani suportati
– numarul de fisiere si inregistrari ce trebuie gestionate
– marimea fisierelor si tabelelor
• Cerintele numerice dinamice pot include, de exemplu:
– numarul de tranzactii, de sarcini si cantitatea de date procesata
intr-un interval de timp, atat pentru conditii de functionare
normale cat si pentru functionare la suprasarcina.
Constrangeri
• Constrangeri legate de design
– pot fi impuse de
• alte standard,
• limitarile hardware
• mediul de operare.
• Standarde de complianta
– specificarea cerintelor derivate din standarde sau reglementari in
vigoare.
• formatul raportului
• denumirea datelor
• proceduri de evidenta
• audit
Caracteristici privind calitatea
• Caracteristici de calitate aplicabile aplicatiilor:

– Corectitudine
• gradul in care un program satisface specificatiile si obiectivele
utilizatorului
– Eficienta
– cantitatea de resurse de calcul pentru indeplinirea functiei
– Flexibilitate
• efortul necesar modificarii programului
– Securitate
• gradul in care poate fi controlat accesul persoanelor/aplicatiilor
neautorizate
– Interoperabilitate
• efortul necesar pentru conecta un sistem cu un altul
Caracteristici privind calitatea
– Intretinere
• efortul necesar remedierii unei erori in timpul functionarii.
– Portabilitate
• efortul necesar transferului datelor de la un sistem la un altul
– Incredere
• gradul in care programul indeplineste sarcina
– Reutilizare
• gradul in care poate fi reutilizat de o alta aplicatie
– Testare
• efortul necesar testarii conform cerintelor
– Accesibilitate
• efortul necesar invatarii, operarii, pregatirii intrarilor si interpretarii
iesirilor
Exemplu de redactare cerinte
Cerinte specifice
1 Cerinte functionale
1.1.Cerinta functionala 1
1.1.1. Introducere
1.1.2. Intrari
1.1.3. Procesare
1.1.4. Iesiri
1.2. Cerinta functionala 2
….
1.n.Cerinta functionala n
Exemplu de redactare cerinte
2. Cerintele interfetelor externe

2.1. Interfete cu utilizatorul
2.2. Interfete hardware
2.3. Interfete software
2.4. Interfete de comunicare
3. Cerinte de performanta
4. Constrangeri de design
4.1. Standarde de complianta
4.2. Limitari hardware
5. Caracteristici de calitate
5.1…
6. Alte cerinte
Exemple
• ID: FR1
• TITLE: Download mobile application
• DESC: A user should be able to download the mobile application
through either an application store or similar service on the mobile
phone. The application should be free to download.
• RAT: In order for a user to download the mobile application.
• DEP: None
• ID: QR1
• TITLE: Prominent search feature
• DESC: The search feature should be prominent and easy to find for the
user.
• RAT: In order to for a user to find the search feature easily.
• DEP: none
Managementul
continutului unui
proiect – parte 2
1
Cuprins
• Componentele
obiectivelor
Planul de activitati
• Planul de activitati cuprinde urmatoarele elemente:
– Descrierea activitatilor “statement of work (SOW)”
• Descriere narativa detaliata a activitatilor proiectului
– Specificatiile proiectului
– Lista “milestone”
• Momemnte de timp pentru evaluare / verificare inaintea unor activitati importante: rol in
identificarea problemelor
– Descompunerea activitatilor “work breakdown structure (WBS)”
WBS (WORK BREAKDOWN STRUCTURE)
- O descompunere ierarhica, orientata catre livrabile, a activitatilor
ce urmeaza a fi intreprinse de catre echipa de proiect, in scopul
atingerii obiectivelor propuse → predarea livrabilelor.
- Fiecare nivel descrescator presupune o descriere mai detaliata in
raport cu precedentul nivel.
- Tipuri:
- WBS orientat verb – actiuni ce trebuie intreprinse
- WBS orientat subiect – componente ale livrabilelor
- WBS orientat catre timp – imparte proiectul in faze, doar fazele
apropriate fiind descrise in detaliu
The 100% Rule...states that the WBS includes 100% of the work defined by the
project scope and captures ALL deliverables – internal, external, interim – in
terms of the work to be completed, including project management
WORK BREAKDOWN STRUCTURE
• WBS oferă o descriere clară a rezultatelor proiectului.
– Ce trebuie făcut nu procesul sau programul.
• WBS este:
– o structura bazata pe rezultat si componente ale rezultatului
– o descompunere ierarhică a activitatii intreprinse in cadrul proiectului
– o reprezentare grafică / schemă / text
– Intreaga activitatea asa cum este descrisa in scopul proiectului si cuprinde toate rezultatele
proiectului
Modalitati de realizare a WBS
• Modele
– Se poate porni de la un model existent – template
(structura nu si informatii)
– Multe organizatii au propriul model
• Top – down
– Obiectivul este descompus in componente
– Se foloseste, de obicei, o reprezentare pe nivele de
complexitate
• Bottom – up
– Se incepe cu actiunile specifice si se organizeaza catre
obiective/ rezultate
– Se utilizeaza agregarea pe componente
• Analogia
– Se porneste de la modele existent si se modifica in functie de necesitati
– Influentata de gradul de similitudine al obiectivelor
– Necesita existenta unur documente din proiecte precedente
• Mind-mapping
– Colectie de idei legate intre ele
• Mind-mapping
STUDIU DE CAZ
Mind-mapping
STUDIU DE CAZ
Tipuri de proiect
Impactul asupra activitatilor
• PM Tradițional
– Activitati in succesiune liniara
• PM Incremental
– Rezultatele sunt predate in etape reducand riscul
• PM Iterativ
– Proiectul evolueaza cu fiecare iteratie ( ciclu )
– Elemente care urmează să fie clarificate
• PM Adaptiv
– scopul si obiectivele proiectului evolueaza
– cicluri: obiective și cerințe revizuite în fiecare ciclu
• PM Hibrid
– Implica utilizatori - revizuirea cerințelor
Pas 1
Selectia elementelor initiale pentru descrierea planului de realizare:

a. Lista rezultatelor (deliverables / products) proiectului.
b. Stabilirea etapelor de baza, preluate din descrierea obiectivelor
proiectului.
c. Crearea unei liste de activitati pornind de la modele existente
d. Crearea listei de activitati folosind metodologii de dezvoltare
Pas 2
- Definirea activitatilor pe baza elementelor identificate la pasul 1

- Stabilirea succesiunii logice
- Descrierea activitatilor
- Descompunerea fiecarei activitati in task-uri ( in functie de complexitate )
- Unde ne oprim in granularizare (descompunerea activitatii):

- Regula “40 de ore” – elementul de baza (activitatea atomica) nu poate
avea o durata mai mica de 40 de ore (norma pe saptamana)
- Regula “4%” – elementul de baza trebuie sa cuprinda minim 4% din
activitatea intregului proiect
- Un element trebuie asociat cu o componenta a rezultatului
Plan de realizare
Lista de activitati Arbore de activitati
Doua modalitati 1. Activitate ……

de reprezentare: 1.1 Activitate …….
•Lista 1.1.1 Activitate …….
•Arbore 1.1.1 Activitate …….
1.2 Activitate ……
2. Activitate ……
3. Activitate ……
• Reguli de urmat:
– Activitatile primare ( Top Level WBS ) trebuie asociate cu cate un
livrabil
– Livrabilele se denumesc folosind substantive:
• ex: Prototip; Lista de cerinte
– Activitatile se denumesc adugand un verb in fata numelui
livrabilului:
• Ex: Realizarea prototipului ; Actualizarea listei de cerinte
– Se evita folosirea cuvintelor ambigue
– Managementul dicteaza ( in functie de complexitatea proiectului)
finalul descompunerii activitatilor in component (task-uri) – nivelul
de granularizare. De obicei se folosesc 3- 4 nivele.
• Reguli de urmat:
– Activitatile se pot grupa in functie de structura de executie (echipa
de implementare, department ….)
– In unele cazuri ( tipul de proiect poate interzice ) este indicat sa se
adauge ca activitate si managementul de proiect
– Atentie la complexitatea unei activitati.
– Activitatile nu trebuie sa se repete sau sa duca la acelasi rezultat
• Ciclul de viata al unui proiect versus lista de activitati
Idee /
Studiu de
Necesitate de
fezabilitate
afacere
Plan de
activitati
Plan de
proiect
Initializare /
Alocare Implementare Finalizare
resurse
Evaluare
Monitorizare
rezultate
– arbore de activitati
STUDIU DE CAZ
– arbore de activitati
STUDIU DE CAZ
Arbore de activitati STUDIU DE CAZ
– lista de activitati
STUDIU DE CAZ
– lista de activitati
STUDIU DE CAZ
Activitatile proiectului
Pachet de lucru
• Pachetul de lucru (work package) este o forma de organizare de tip “sub-proiect” sau
componenta de proiect
• Fiecare Pachetul de lucru presupune posibilitatea de management independent a
activitatii
• Organizare sub forma de table cu 4 componente
• “Work packages are the lowest level in a WBS decomposition where an activity duration
can be reliably estimated and managed. A Work Package can be created where a Project
Manager (PM) deems it necessary to help develop the project Schedule.”
• Guidelines: Project Schedule Project Management Office (PMO), Charleton
University, Canada
Pachet de lucru
Un pachet de lucru include:
Pachet de lucru
Exemplu WP – model FP7
WP include
1. Denumire
2. Timp
3. Participanti
4. Efort
Componenta 1 - centralizator
Pachet de lucru
WP include
Componenta 2 - obiective 5. Obiectiv general
6. Obiective specifice
Pachet de lucru
Componenta 3 - descriere
WP include
7. Descrierea activitatii
8. Activitati si task-uri
Cod asociat
Pachet de lucru
WP include
9. Livrabile
10. Momentul livrarii
Componenta 4 - livrabile
Luna de
predare
Cod asociat
Exemplu
Plan Realizare model PN2
Produs software
Product Lifecycle
Etape generice
Concepere Proiectare
Specificație Design detaliat
Design conceptual Validarea și analiza
Instrument de proiectare
Dezvoltare Service
Planul de fabricație Vinzare
Fabricare Livrare
Asamblare Utilizare
Testare Mentenanta /
suport
Reciclare
Plan de activitati in constructii - WBS
• 1.0 System Design • 2.0 Construction
– 1.1 System Engineering – 2.1 Site Development
– 1.2 Site Development – 2.2 Civil Structures
– 1.3 Civil Structures – 2.3 Thermal Systems
– 1.4 Thermal Systems – 2.4 Flow Systems
– 1.5 Flow Systems – 2.5 Storage Systems
– 1.6 Storage Systems
– 2.6 Electrical Systems
– 1.7 Electrical Systems
– 2.7 Mechanical Systems
– 1.8 Mechanical Systems
– 2.8 Instrument & Control Systems
– 1.9 Environmental Systems
– 1.10 Instrumentation & Control – 2.9 Environmental Systems
Systems – 2.10 Temporary Structure
– 1.11 Auxiliary Systems – 2.11 Auxiliary Systems
STUDIU DE CAZ
Plan de activitati in constructii - WBS
STUDIU DE CAZ
• 3.0 Legal & Regulatory
– 3.1 Licensing (non-government)/Permitting (government)
– 3.2 Environmental Impact
– 3.3 Labor Agreements
– 3.4 Land Acquisition
– 3.5 Other Legal/Regulatory Requirements
• 4.0 Project Management
– 4.1 Project Plan Development
– 4.2 Status Reports
– 4.3 Data Management
– 4.4 Configuration Management
– 4.5 Meetings (Minutes)
– 4.6 Contract Administration
• 5.0 System Test/Startup
Plant de activitati telecom- WBS
STUDIU DE CAZ
• 1.0 Concept/Feasibility
– 1.1 Develop Concept/Marketing Plan
– 1.2 Conduct Market Analysis & Scope
– 1.3 Conduct Technical Analysis
– 1.4 Develop Prototype
– 1.5 Prepare Product Development Plan/Cost/Schedule
• 2.0 Requirements
– 2.1 Develop End-User Requirements
– 2.2 Develop Application Requirements
– 2.3 Develop Infrastructure (Systems) Requirements
– 2.4 Develop Operations/Maintenance Requirements
– 2.5 Develop Service Requirements
• 3.0 Decision
– 3.1 Present Prototype
– 3.2 Present Financial & Schedule
– 3.3 Present Technical Capabilities
– 3.4 Obtain Financial Commitment
– 3.5 Go/No-Go Decision (Milestone)
STUDIU DE CAZ
• 4.0 Development
– 4.1 Develop End-User Systems
– 4.2 Develop Application
– 4.3 Develop Infrastructure Systems & Network
– 4.4 Develop Operations/Maintenance Structure
– 4.5 Develop Service Plan
• 5.0 Test
– 5.1 Develop Test Plans for Each Aspect/Element
– 5.2 Conduct Tests
– 5.3 Validate Results
– 5.4 Perform Corrective Action (as necessary)
– 5.5 Conduct Retesting
– 5.6 Revalidate Results
STUDIU DE CAZ
• 6.0 Deploy
– 6.1 Conduct Trial in a Non-Penalty Environment
– 6.2 Conduct First Live Test in First Action Site
– 6.3 Complete Deployment
• 7.0 Life-Cycle Support
– 7.1 Conduct Customer Training & Education
– 7.2 Perform Turnover to Customer
– 7.3 Obtain Customer Acceptance
– 7.4 Perform Support & Maintenance
Cuprins
• Componentele
obiectivelor
Validarea continutului
• Validarea continutului presupune activitati de inspectie:
– Examinarea
– Validarea conform unor unitati de masura
– Compararea rezultatelor cu cerintele
• Activitatile effectuate presupun:
– Review (intern sau extern)
• Evaluare a unor experti diferiti de cei care au lucrat la plan
– Audit
• Urmarirea respectarii unor reguli
• Rezultat: Acceptanta (Formal acceptance)
Managementul
Timpului
Cuprins
1. Managementul timpului
2. Definirea activitatilor
3. Stabilirea secventei de activitati
4. Metode de estimare
5. Realizarea planului de activitati
6. Controlul planului de activitati
MANAGEMENTUL TIMPULUI
Managementul timpului
Componente
1 2 3
Stabilirea Estimarea duratei
Definirea
secventei de si a resurselor
activitatilor
activitati activitatilor
Realizarea
Controlul planului
planului de
de activitati
activitati
4 5
DEFINIREA ACTIVITATILOR
Definirea activitatilor
• Definirea activitatilor se realizeaza folosind
elemente identificate in sectiunea
“Management de continut”
– Lista de livrabile
– WBS (Descompunerea livrabilelor in componente)
– Lista de activitati
• Definirea activitatilor presupune si descrierea
modului de implementare a activitatilor
(metode, modele ….)
• WBS (Descompunerea livrabilelor in componente)
– Reprezinta o descompunere, pe nivele de
complexitate, a rezultatelor unui proiect
– Rezultat:
• work package = componenta a unui livrabil
• Lista de activitati
– Prezinta activitatile necesare obtinerii rezultatelor
proiectului
– Rezultat:
• Lista de activitati
Plant de activitati software-
WBS
STUDIU DE CAZ
• 1.0 Project Management – 1.3 Administration

– 1.1 Planning • 1.3.1 Standards
• 1.1.1 Develop Project Charter – 1.3.1.1 Document
• 1.1.2 Define Scope Performance Standards
• 1.1.3 Develop Resource Plan – 1.3.1.2 Document
• 1.1.4 Develop Communication Plan Reporting Standards
• 1.1.5 Develop Risk Plan – 1.3.1.3 Document
• 1.1.6 Develop Change Control Plan Naming Conventions
• 1.1.7 Develop Quality Plan
– 1.3.1.4 Document
• 1.1.8 Develop Purchase Plan Housekeeping Standards
• 1.1.9 Develop Cost Plan
• 1.3.2 Program Office
• 1.1.10 Develop Organization Plan
• 1.1.11 Develop Project Schedule – 1.3.2.1 Develop Program
Office Charter
– 1.2 Meetings
– 1.3.2.2 Assign Program
• 1.2.1 Conduct Kickoff Meeting
Office Resources
• 1.2.2 Weekly Status Meeting
• 1.2.3 Monthly Tactical Meeting
• 1.2.4 Project Closing Meeting
WBS
STUDIU DE CAZ
• 2.0 Product Requirements -2 .4 Hardware

– 2.1 Software Requirements 2.4.1 Create Draft
• 2.1.1 Create Draft Software Requirements Hardware Requirements
• 2.1.2 Review Draft Software Requirements 2.4.2 Review Draft
• 2.1.3 Update Draft Software Requirements Hardware Requirements
• 2.1.4 Review Final Software Requirements 2.4.3 Hardware
• 2.1.5 Software Requirements Approved Requirements Approved
– 2.2 User Documentation - 2.5 Implementation &
• 2.2.1 Create Draft User Documentation Future Support
• 2.2.2 Review Draft User Documentation
• 2.2.3 Update Draft User Documentation
• 2.2.4 Review Final User Documentation
• 2.2.5 User Documentation Approved
– 2.3 Training Program Materials
• 2.3.1 Create Initial Training Requirements
• 2.3.2 Review & Approve Training Requirements
• 2.3.3 Create Initial Training Materials
• 2.3.4 Review & Approve Training Materials
• 2.3.5 Conduct Trial Course Delivery
• 2.3.6 Update and Finalize Training Materials
WBS
STUDIU DE CAZ
• 3.0 Detail Software Design • 5.0 Integration & Test

– 3.1 Create Initial Software – 5.1 Software
Design – 5.2 System Test Plan
– 3.2 Review Initial Software – 5.3 System Test Cases
Design – 5.4 System Test Results
– 3.3 Update Initial Software – 5.5 Acceptance Test Plan
Design – 5.6 Acceptance Test Cases
– 3.4 Review Final Software Design – 5.7 Acceptance Test Results
– 3.5 Software Design Approved – 5.8 User Documentation
• 4.0 System Construction – 5.9 Training Program Materials
– 4.1 Configure Software – 5.10 Hardware
– 4.2 Customize User – 5.11 Implementation & Future
Documentation Support
– 4.3 Customize Training Program
Materials
– 4.4 Install Hardware
– 4.5 Implementation & Future
Support
• Rezultate:
– Lista de activitati finala
– Descriere a activitatilor
– Lista “Milestone”
STABILIREA SECVENTEI DE ACTIVITATI
Secventa de activitati
• Identifica si documenteaza relatia dintre
activitatile proiectului
• Utilizeaza metode logice de reprezentare
• Se poate realiza
– Utilizand aplicatii software
– Utilizand diagrame scrise
– Mix
Metode
• Diagrama de precedenta
– Precedence diagramming method (PDM)
– Activity–On-Node
• Diagrama de sageti
– Arrow diagram method (ADM)
– Activity–On-Arrow
• Diagrame conditionale
– Design Structure Matrix (DSM)
• Diagrame de retea
Metode
Diagrama de precedenta
• Doua blocuri utilizate in reprezentare:
– Noduri ( cel mai des Dreptunghiuri) pentru:
Activitati
– Sageti pentru relatiile intre activitati
2 6
1 4 7 8
3 5
Metode
• Relatiile intre activitati:
– Finish-to-start (FS)
• Activitatea A trebuie finalizata
inaintea inceperii Activitatii B
– Start-to-start (SS)
• Activitatea A trebuie inceputa
inaintea inceperii Activitatii B
– Finish-to-finish (FF)
• Activitatea A trebuie finalizata
inaintea finalizarii Activitatii B
– Start-to-finish (SF)
• Activitatea A trebuie sa
inceapa pentru ca Activitatea B
sa se finalizeze
Metode
Metode
Diagrama de sageti
• Doua blocuri utilizate in reprezentare:
– Noduri ( cel mai des cercuri) pentru relatiile intre activitati
(conexiunea intre activitati)
– Sageti pentru Activitati
– Utilizeaza relatii de tip Finish-to-start (FS)
– Se pot introduce activitati generice (sageti punctate fara
durata) pentru a ilustra dependent dintre activitati
Corelare
A (20 zile)
Metode
Design Structure Matrix (DSM)
• Reprezentare bidimensionala (matrice) a
activitatilor din punct de vedere structural si
functional
• Activitatea 3 necesita
informatii de la 8 si 11
• Activitatea 1 furnizeaza
informatii catre 2.
http://www.sigmazone.com/
QuantumXLDSM.htm
Metode
Metode
Cluster de
activitati
Metode
1.Testare 3.Implementar 4.Testare de

functionalitati e solutii acceptanta
2.Testare
interfata
Metoda DSM permite

tratarea buclelor
ESTIMAREA DURATEI SI A RESURSELOR
ACTIVITATILOR
Estimarea
O estimare reprezinta:
• O evaluare a resurselor sau rezultatelor din punct de vedere cantitativ

• De obicei aplicata:
• Resursa umana (“effort”, ore de munca + salariu pe ora )
• Cost (Buget proiect)
• Durata
• Folosita de obicei impreuna cu:
• un grad de precizie
• un clasificator (ex: preliminar, conceptual, de fezabilitate, final)
• Gradul de complexitate / profunzime depinde de decizia ce urmeaza a fi
luata pe baza acestei estimari
“O estimare este doar o estimare” .

Estimarea
Ce nu reprezinta o estimare
O estimare NU reprezinta:
• O strategie economica sau de marketing
• O modalitate precisa de determinare a pretului produselor
• O modalitate de satisfacere a cerintelor sponsorilor. (Prezentati
realitatea. NU taiati cheltuieli din estimari )
• Software sau Tool-uri
• Drumul cel mai scurt (Fiti realisti in ceea ce priveste timpul alocat
activitatilor)
“Gradul de precizie al estimarii poate fi validat abia dupa

finalizarea activitatilor proiectului”
Estimarea
• Un document de descriere al estimarior trebuie sa includa:
– Scopul efortului (muncii) de estimare
– Presupunerile folosite
– Resursele estimate: personal, resurse materiale,durata
• Cat de repede poate fi finalizata activitatea cu resursele
existente?
• Ce nivel de pregatire (“skill”) este necesar pentru activitate?
• Cheltuielile directe si indirecte
– Riscul asociat si cheltuielile legate de reducerea riscului
proiectului
• Documentatie:
• O estimare ne-documentata exista doar “in mintea
estimatorului”
Metode de estimare
• Exista multe metode si teorii pentru estimarea timpului si a
efortului necesar in realizarea unui proiect.
• Motive:
• Complexitatea rezultatelor
• Productivitatea individuala
• Neprevazutul
• Cerintele nerealiste
Nici una dintre acestea garanteaza 100% succesul
27
Metode de estimare
Macro-estimari:
• Metoda matematica
– presupune folosirea uneor ecuatii rezultate din analiza
unor esantioane de proiecte. Aceste ecuatii depind de
dimensiunea proiectului. (ex PERT Program Evaluation and
Review Technique)
• Metoda comparativa
– presupune identificarea unui grup de proiecte similare,
etragerea de informatii si folosirea acestora ca baza de
plecare pentru estimare
• Metoda analogiei
– presupune identificarea unui proiect , foarte apropiat ca
atribute si folosirea datelor pentru proiectul curent.
Metode de estimare
Micro-estimari:
• Divizunea activitatii – presupune estimarea

parametrilor fiecarei activitati de baza (task),
asa cum au fost identificate in WBS.
Estimarea resurselor
- Estimarea resurselor reprezinta procesul de

estimare calitativa si cantitativa a necesarului
de materiale, resurse umane, echipamente in
scopul realizarii fiecarei activitati
Estimarea duratei
• Estimarea duratei reprezinta procesul de
aproximare a numarului de de perioade de
timp necesare pentru realizarea individuala a
activitatilor, pe baza resurselor estimate
Estimarea programului de
lucru
• Programul de lucru reprezinta procesul de
analiza a secventierii activitatilor, a duratei,
necesarului de resurse, in functie de
constrangerile de timp.
Estimarea costurilor
• Reprezinta procesul de aproximare a
resurselor financiare necesare in vederea
realizarii tuturor activitatilor proiectului
Definirea estimarii pentru
proiecte
▪ Definitii:
▪ Termeni uzuali folositi in MP (proiecte in limba engleza)
▪ “
▪ Effort
▪ is the number of labor units required to complete a task. It is
usually measured in staff hours, or person-hours
▪ Level of effort (LOE)
▪ describes the activities that are necessary to support a project that
cannot be scheduled
▪ Duration
▪ is the number of work periods, excluding holidays or other
nonworking periods, required to complete an activity or other
project element
• “
Metode de estimare
- Cele mai des intalnite metode de estimare
sunt:
- Estimarea top-down
- Estimarea bottom-up
- Estimarea prin analogie
- Estimarea parametrica
- Judecata expertilor
- In continuare sunt prezentate cateva metode
de estimate.
Metode de estimare
Estimarea prin analogie
• Utilizeaza date din proiecte similare finalizate cu
suces
• Se bazeaza pe o analiza a datelor si pe judecata
expertilor
• Depinde de gradul de similitudine al proiectelor
– Motto: “We did this before”
• Avantaje
– Cost scazut
– Nu necesita un interval mare de timp pentru finalizare
• Dezavantaje:
– Estimare grosiera
Metode de estimare
Estimarea prin analogie
• In cazul in care proiectele au un grad mai mic

de similitudine:
– Se face o estimare bazata pe experienta anterioara
sau cunoștințele expertilor
– Se poate extrapola o estimare ținând cont de
diferențele specifice care există în proiectul
propus.
– Se poate ajunge insa la “educated guess ”
Metode de estimare
Lectii invatate
• folosește conceptul de estimare prin analogie,
• construiește o bază de cunoștințe structurată,
folosită pentru a descrie experiența acumulata
din multe proiecte
• modalitate de clasificare a proiectelor si
activitatilor
• modalitate de cuantificare a numeroaselor
variabile care afectează timpul și efortul.
Metode de estimare
Top Down
• Se estimeaza sau se impune o durata a
proiectului
• Pe baza listei de activitati se face o impartirea
a timpului
• Pentru fiecare activitate se estimeaza un
interval de timp.
– Exemplu: dezvoltarea va fi de 50% din total,
testarea va fi de 25%.
• Se estimeaza timpul necesar fiecarei
componente a activitatilor
Metode de estimare
Bottom up
• Pe baza listei de activitati se face o estimare a
timpului necesar executiei.
• Se estimeaza, mai intai, timpul necesar pentru
fiecare componente a activitatilor (cea mai
mica subdiviziune)
• Se aduna estimarile facute si se obtine durata
unei activitati
• Se aduna estimarile facute pentru activitati si
se obtine durata intregului proiect
Metode de estimare
Top-down meets bottom-up
• Se estimeaza sau se impune o durata a
proiectului.
• Pe baza listei de activitati se face o impartirea a
timpului
• Simultan se estimeaza timpul necesar pentru
fiecare componente a activitatilor (cea mai mica
subdiviziune)
• Estimările individuale sunt apoi adunate,
obtinandu-se durata unei activitati.
• Se compara duratele estimate pentru fiecare
activitate si se ajusteaza corespunzator
Metode de estimare
Estimarea parametrica
• Utilizeaza metode matematice
• Se bazeaza pe prelucrare statistica a datelor din alte
proiecte si/sau pe utilizarea unor formule matematice
Durata activitatii = efort x resursa alocat
Durata activitatii = unitati de efort estimate x ore/unitate de efort
Exemplu:
1. Se estimeaza un efort de 101 unitati
2. Se estimeaza o unitate de effort echivalent a 10 ore
3. Durata activitatii = 1010 ore
Metode de estimare
Estimarea in 3 puncte
• Probabil
– Ex: Durata unei activitati se calculeaza tinand cont de
resursele disponibile in cazul cel mai probabil,
productivitatea lor, dependentele de alti participanti,
eventualele intreruperi, etc..
• Optimist
– Ex: Durata unei activitati este calculata in cazulul cel mai
fericit “best-case scenario”.
• Pesimist.
– Ex: Durata unei activitati este calculata in cazulul cel mai
nefericit “worst-case scenario”.
• La final se face o medie (aritmetica, ponderata etc) a

acestor 3 cazuri.
Metode de estimare
Metoda Delphi
Necesita selectia de experti in domeniul proiectului
1. Selecteaza grupul de experti
2. Prezinta proiectul si cerinta de estimare
3. Estimarea expertilor
4. Centralizarea estimarilor
5. Se repeat pasul 3 si 4
6. Finalizarea
• Se combină metoda celor trei puncte și metoda
Delphi pentru a obține metoda “Wideband Delphi”
– La fiecare iteratie fiecare estimare persoană va contine:
estimarea probabila, pesimista si optimista
– Se aplica metoda celor trei puncte
Metode de estimare
Metoda Delphi
• Pas 1: Selecteaza grupul de experti - factori
– Complexitatea proiectului
– Cunostintele din domeniu
– Disponibilitatea
• Pas 2: Prezinta proiectul si cerinta de estimare
– Se prezinta: obiectivele, continutul, constrangerile
cerintele legate de estimare
– Se raspunde la eventualele intrebari
• Pas 3: Estimarea expertilor
– Expertii vor formula estimari legate de durata activitatilor
– Estimarile sunt bazate pe experienta expertilor
– Estimarile se trec intr-un tabel
Metode de estimare
Metoda Delphi
• Pas 4: Centralizarea estimarilor
– Estimarile sunt centralizate
– Se calculeaza o medie
– Extreme sunt prezentate expertilor
• Pas 5: Se repeat pasul 3 si 4
– Se repeat pana la convergenta valorilor
• Pas 6: Finalizarea
– in momentul in care se obtine acordul expertilor
Metode de estimare
Aspecte importante
• Estimarea de durata a activitatii va lua in
considerare urmatoarele aspecte:
– Se calculeaza / estimeaza productrivitatea pe zi
– Se compenseaza cu factorul de complexitate in cazul
echipelor numeroase sau activitatii in parale
– Se compenseaza pentru resursa temporara / part-time
– Se estimeaza resursele disponibile pentru fiecare
activitate
– Se considera zilele libere
– Se identifica potentialele intarzieri
– Se identifica constrangerile de resursa
– Se documenteaza toate presupunerile
Factor de complexitate
Doing something 10 times as big is 1000 times more complex!
• Complexitatea poate fi definita printr-un

factor de complexitate
Factor de complexitate = 2n-1 unde n = nr de entitati
– Entitatea poate fi reprezentata de orice
componenta din proiect
• Nr de membrii ai unei echipe
• Nr de sisteme
• Nr de locatii
Factor de complexitate
Simplu Complicat Complex Haotic
Complexitate la
nivel de proiect
Structural Functional Incertitudine
Dimeniune Interoperabilitate Procese interoperabilitate Metode obiective

Procesul de estimare
Obiectivele Modelul de Plan de

estimarii estimare estimare
Detaliile
proiectului
Risc Estimare
Includere in
planul de
proiect
Documentare Validare Finalizare

Validarea unui proces de
estimare
• Pentru a valida o estimare:
▪ Corelati cu scopul proiectului
▪ Verificati ca ati inclus toate activitatile
▪ Verificati sursa datelor folosite
▪ Comparati cu proiecte similare
▪ Revizuiti metoda de estimare folosita
▪ Verificati daca estimarile sunt in conformitate cu
obiectivele de business
▪ Folositi si alete metode de estimare pentru a valida
rezultatele
Estimarile trebuie validate inainte de a fi considerate complete
REALIZAREA PLANULUI DE ACTIVITATI
Realizarea planului de activitati
• Planul de activitati reprezinta un document ce

contine
– Lista de activitati
– Secventa de activitati
– Estimarea duratei pentru fiecare activitate
– Lista “milestone”
– Modalitati grfice de reprezentare: Gantt, Pert ….
Realizarea planului de activitati
• Metode des folosite pentru reprezentarea

activitatilor si estimarea duratei:
– Diagrama Gantt
– Critical Path Method (CPM)
– PERT - program (or project) evaluation and review
technique
Metode
Diagrama Gantt
• De tip Bar Chart:
– Diagrama care utilizeaza o reprezentare a
activitatilor sub forma de “bare”
Metode
Diagrama Gantt
• Realizarea unei diagrame Gantt presupune:
1. Realizarea listei de activitati
2. Identificarea relatiilor intre activitati
(precedenta)
3. Asocierea duratei unei activitati
4. Asezarea activitatilor in ordine cronologica (dupa
data de inceput) sub forma unui “timeline”.
5. Trasarea barelor orizontale (dimensiunea duratei
unei activitati)
6. Trasarea barelor orizontale de grupare in etape
Metode
Diagrama Gantt
Pas Pas
1 A1.1 A1.2 A1.3 2
2014 Pas
Mar Apr Mai Iun
3
A1
A1.1
A1.2
A1.3
A1.4
Metode
Diagrama Gantt
• Aplicatii pentru realizarea diagramei Gantt:
– Microsoft Project
– Gantt Project (http://www.ganttproject.biz/)
– Open Proj (http://sourceforge.net/projects/openproj/)
– Gantter (http://www.gantter.com/) - online
– Tom’splanner (http://www.tomsplanner.com/) – online
– etc ….
Metode
CPM
• O cale intr-o rețea de activitati de proiect:
– START A-B-C-H-M FINAL
• Calea este caracterizata de lungime:
– suma duratelor (estimate) ale activitățile pe calea
• Durata unui proiect este data de calea cea mai
lunga de la START la FINAL = Cale critica
– Cale critica START A-B-C-J-M FINAL
– Durata estimata a proiectului = lungimea = 33
saptamani
Metode
CPM
• Metoda “” presupune:
1. Realizarea unei diagrame de secventa (de obicei
de tip “Activity on Node” )
2. Stabilirea unor intervale de timp asociate fiecarei
activitati
1. Durata estimata
2. Early Start / Early Finish
3. Late Start / Late Finish
4. Slack time
3. Completarea diagramei cu intervalele de timp
asociate
Metode
CPM
• Pas 2: Pentru fiecare activitate se stabilesc urmatoarele
intervale de timp
– Durata estimata
– Early Start / Early Finish
• Early Finish = Early Start + durata
• Early Start = max (Early Finish al activitatilor precursor )
• Se calculeaza de la inceput la final
– Late Start / Late Finish
• Late Start = Late Finish – durata
• Late Finish = Early Finish pentru ultima activitate a proiectului
• Late Finish = min (Late Start al activitatilor succesor)
• Se calculeaza de la final la inceput
– Pentru calea critica Early = Late
– Slack time
– Slack Late Finish - Early Finish
Metode
CPM
Studiu de caz
http://www.math.upatras.gr/~
tsantas/DownLoadFiles/Hillier
&Lieberman_7th-
edition_Chapter10.pdf
Metode
CPM
Studiu de caz
http://www.math.upatras.gr/~
tsantas/DownLoadFiles/Hillier
&Lieberman_7th-
edition_Chapter10.pdf
Metode
CPM / PERT
• “ PERT Three-Estimate Approach “
– Probabil ( Most likely estimate (m) )
– Optimist ( Optimistic estimate (o) )
– Pesimist ( Pessimistic estimate (p) )
• Se bazeaza pe distributia Beta pentru a calcula
𝑜+4𝑚+𝑝
– media ( M ) calculata cu formula M =
6
2 2 𝑜−𝑝 2
– variatia (σ ) calculata: σ =
6
– Intreaga distributie se afla intre M- 3 σ si M+ 3 σ
Metode
CPM / PERT
• Fie T = timpul total asociat activitatilor de pe
calea critica
• σ asociat pentru calea critica = suma (σ asociat
fiecarei activitati de pe calea critica)
• Se calculeaza variabila standard a normei:
𝑇−𝑀
Z= si se verifica cu tabelul de probabilitati
σ
asociat distributiei => probabilitatea ca
proiectul sa se finalizeze la timp
Metode
CPM / PERT
Studiu de caz
http://www2.kimep.k
z/bcb/omis/our_cour
ses/is4201/Chap14.p
df
Metode
CPM / PERT
Studiu de caz
22-week schedule
CONTROLUL PLANULUI DE ACTIVITATI
Controlul planului de activitati
• Presupune:
– Analiza programului realizat
– Identificarea factorilor care pot duce la
schimbarea programului
• Ex: nu presupuneti ca echipa va lucre la capacitate
maxima
– Se determinarea in timpul implementarii:
• Aparitia factorilor de schimbare
• Schimbarii propriuzise
• Managementul schimbarii
Controlul planului de activitati
• Metode
– Sistem de management al performantelor
• Se bazeaza pe metodele de estimare descrise anterior
• Decizia schimbarii se bazeaza pe estimarile legate de
intarzierea activitatilor
– Sistem de control al schimbarilor de program
• Proceduri pentru schimbarea programului
– Actualizarea planului
• Rar proiectele se vor desfasura conform planului
CURS 6 - 7
Managementul Resurselor Umane
Cuprins
◼ Managementul resurselor umane
◼ Planificarea HR
◼ Teorii organizationale
◼ Alocarea echipei de proiect
◼ Dezvoltarea cunostintelor echipei de
proiect
◼ Managementul echipei de proiect
MANAGEMENTUL
RESURSELOR UMANE
Managementul strategic al
Resurselor Umane
Planificarea RU
Recrutare
Selecţie
Organizarea şi
proiectarea muncii
Formare şi dezvoltare
Evaluarea performanţelor
Compesare
Relaţiile de muncă
Management HR
Definitie:
◼ Include procese:
◼ necesare utilizarii in mod optim a resursei umane
intr-un proiect
◼ de organizare a echipei de proiect
◼ de conducere si management a echipei de proiect
◼ de monitorizare a performantelor
Management HR
HR -> presupune alocarea resurselor reale
Două elemente de baza:

▪decizia privind resursele alocate pentru
implementarea proiectului
▪obţinerea resurselor ce vor lucra în
proiect.
Importanţa
strategică a HR
◼ Poate stabili avantaje competitive pentru o
organizație durabilă
◼ Deficit de 500 milioane lucrători
◼ Necesită o schimbare fundamentală a modului în
care manageri percep angajaţii
◼ Parteneri şi Investiţii
◼ Externalizarea anumitor tranzacții RU
◼ Procurement
◼ Atunci, ce face Departamentul RU?
Management HR
Evaluarea Evaluarea
resurselor nevoilor
umane actuale viitoare
Satisfacerea
nevoilor
în curs
Management HR
Componete:
◼ Dezvoltarea planului de resurse umane
◼ Obtinerea si alocarea echipei de proiect
◼ Dezvoltarea echipei de proiect
◼ Managementul echipei de proiect
Planulu de Alocarea Dezvoltarea Management

RU RU RU RU
RESURSA UMANA IN CADRUL
ORGANIZATIEI
Resursa umana in cadrul
organizatiei Studiu de caz
https://managementmania.com/en/organizational-architecture
Forme de organizare
Teoria Mintzberg
◼ Structura simplă
◼ Numar restrans de manageri,
◼ supraveghere directă
◼ “Machine bureaucracy”
◼ Managementul ia decizii, pe care managerii și
angajații de la niveluri inferioare le îndeplinesc.
◼ Fabrici - standardizarea proceselor de lucru
◼ Divizie
◼ divizia are autonomie
◼ Rezultatele și măsura performanțelor unitara
◼ “Professional bureaucracy”
◼ decizii luate de profesioniști
◼ Coordonare bazata pe competențe ale lucrătorilor
◼ “Adhocracy”
◼ proiecte inovatoare – coordonare bazata pe Salameh, Abdallah. (2011). On Process Tailoring
- An Agile Example.
colaborare
Forme de organizare
Teoria Mintzberg
Studiu
de caz
Forme de organizare
Teoria Mintzberg
Studiu Forme de organizare
de caz Teoria Mintzberg
https://www.adb.org/sit
es/default/files/publicati
on/29644/organization
al-configurations.pdf
https://www.adb.org/sit
es/default/files/publicati
on/29644/organization
al-configurations.pdf
Modelul DIKW
Modelul DIKW
◼ Date
◼ sunt doar o multime de semnale sau simboluri.
◼ set neorganizat și neprocesat.
◼ inutil fara a avea asociat un inteles (ex: 3,5 ? Vs 3,5 Celsius)
◼ Informatii
◼ date structurate, cu inteles.
◼ aplicarea de sisteme pentru organizarea și clasificarea datelor
◼ Informațiile = date cu sens.
◼ Utilitatea informatiilor nu este o certitudine !
Information Society: There is debate about an exact definition of information society

but in general terms it refers to society in which the creation, distribution, diffusion,
use, integration, and manipulation of information is a significant economic, political,
and cultural activity.
E-Inclusion: European Perspectives Beyond the Digital Divide, Bridgette Wessels (University of Sheffield, UK)
Source Title: Encyclopedia of E-Business Development and Management in the Global Economy
Modelul DIKW
◼ Cunostinte (knowledge)
◼ def: Fapte, informații și abilități dobândite prin experiență sau
educație; înțelegerea teoretică sau practică a unui subiect
◼ def: Conștientizarea sau familiaritatea dobândită prin
experiența unui fapt sau a unei situații
◼ def: Cunoașterea este o structură mentală, făcută din
învățarea acumulată și din analiza sistematică a informației.
◼ organizarea informațiilor in sensul utilitatii.
◼ informațiile ajuta la identificarea relațiilor, cunoașterea permite
identificarea tiparelor.
◼ permite constructia de modele predictive și a perspectivelor
Knowledge societies are about capabilities to identify, produce, process, transform,
disseminate and use information to build and apply knowledge for human development.
A knowledge society serves to transform information into resources that allow society to take
effective action Towards Knowledge Societies — ISBN 92-3-104000-6 — © UNESCO 2005
Modelul DIKW
◼ Intelepciunea (wisdom)
◼ detectarea și înțelegerea tiparelor, dar și înțelegerea
profundă a „De ce ?” în spatele acestor tipare.
◼ Înțelepciunea se referă la viitor: se bazează pe
cunoaștere și modele de model
◼ deocamdată, aceasta este o abilitate pură a omului
Wisdom is the synthesis of knowledge and experiences into insights that

deepen one's understanding of relationships and the meaning of life. In other
words, knowledge is a tool, and wisdom is the craft in which the tool is used.
https://philoscifi.com › 2010/09/26 › knowledge-vs-wisdom
http://www.theitsmreview.com/2016/04/dikw-model-
knowledge-management/
https://towardsdatascience.com/rootstrap-dikw-model-32cef9ae6dfb
Calificare (Skill)
◼ abilitate, facilitate sau dexteritate care este dobândită
sau dezvoltată prin formare sau experiență.
◼ abilitatea, provenind din cunoștințele, practica,
aptitudinea cuiva, de a face ceva bine
◼ o abilitate și capacitate dobândită printr-un efort
deliberat, sistematic și susținut de a desfășura în mod
facil și adaptativ activități complexe sau funcții de
muncă care implică idei (abilități cognitive), lucruri
(abilități tehnice) și / sau oameni (abilități
interpersonale).
◼ o calificare este ceva învățat pentru a putea îndeplini
una sau mai multe funcții.
Competenta
(Competency)
◼ Un grup de abilități, angajamente, cunoștințe și abilități conexe
care permit unei persoane să acționeze eficient într-un loc de
muncă sau într-o situație.
◼ Implică capacitatea de a satisface cerințe complexe, prin
utilizarea și mobilizarea resurselor psiho-sociale (inclusiv
abilități și atitudini) într-un context particular.
◼ Un model măsurabil de cunoștințe, abilități, comportamente și
alte caracteristici pe care o persoana le detine si ii permit să
îndeplinească cu succes roluri sau funcții profesionale.
◼ Competențele specifică „cum?” (vs ce?) se pot îndeplini
sarcini de serviciu sau ce trebuie sa faca o persoana pentru a
indeplini cu succes un task.
Competenta
(Competency)
Studiu de caz
◼ To effectively write a computer program one needs good analytical,

logical, and interpretive ability as well as the skill to write the
program in a specific language.
◼ So, learning Java, C++, C#, etc. is a Skill.
◼ But underlying the ability to use that skill effectively is analytical,
logical and interpretive ability – those are Competencies.
◼ However, without the underlying Competence, it is virtually
impossible to write an effective program – irrespective of the
language.
http://www.talentalign.com/wp-content/uploads/kalins-pdf/singles/skills-vs-competencies-whats-the-difference.pdf
Skill worker vs
Knowledge worker
◼ Skill worker (angajati calificati)
◼ se bazează pe abilități si calificari
◼ o utilitate mult mai mare în ceea ce privește dezvoltarea lor -
abilitățile se schimbă foarte, foarte lent în timp,
◼ Knowledge worker
◼ angajati de nivel înalt care aplică cunoștințe teoretice și analitice,
dobândite prin formare pentru a dezvolta produse și servicii.
◼ cele mai valoroase active ale unei organizații din secolul XXI,
datorită nivelului ridicat de productivitate și creativitate.
◼ includ profesioniști din domeniile tehnologiei informației,
farmaciști, contabili, ingineri, arhitecți, avocați, medici, oameni de
știință, analiști financiari, proiectati etc.
“knowledge worker” was first coined by Peter Drucker in his book, The Landmarks of
Tomorrow (1959).
Caracteristici ale
“Knowledge Workers”
◼ Cunoașterea teoretică si
aplicata
◼ Accesarea și aplicarea
informațiilor
◼ Abilități de comunicare
◼ motivaţie
◼ atenție tehnică, lucru în
primul rând cu informații.
◼ aptitudinile includ: analiza
datelor, înțelegerea
tendințelor și practicarea
gândirii convergente.
Ley, Tobias & Ulbrich, Armin & Scheir, Peter & Lindstaedt, Stefanie & Kump, Barbara & Albert, Dietrich. (2008).
Modeling competencies for supporting work-integrated learning in knowledge work. J. Knowledge Management.
12. 31-47. 10.1108/13673270810913603.
Caracteristici ale
“Learning Workers”
◼ “Conceptul conform căruia o diplomă universitară de
patru ani este singura cale care duce la o angajare
semnificativă și profitabilă este depășită.” (discutie)
◼ “În multe privințe, este un ideal care nu poate ține
pasul cu progresul tehnologic rapid care afectează
angajatorii și angajatii dintr-oi varietate de industrii.”
◼ Learning Workers: oameni care sunt capabili să
învețe lucruri noi și să aplice aceste învățări în diferite
scenarii și medii.
◼ În esență, a fi capabil să „înveți cum să înveți.” Acest
lucru este mult mai valoros decât „a ști” orice.
https://www.c4lpt.co.uk/blog/2015/05/04/from-knowledge-worker-to-learning-worker/
Caracteristici ale
“Learning Workers”
Studiu de caz
◼ “The traditional way to learn and teach was largely guided and
dictated by organizations who set out training programs,
manuals, and set courses. Technology has connected
employees and information together anywhere, anytime, and
on any device. This means that learning and teaching can
happen between employees without official corporate training
programs or manuals. Have a question? Tap into the
collective intelligence of your company. Want to show
someone how to do something? Whip out your smartphone,
film it, and upload it to your organization’s collaboration
platform for your peers to see.”
◼ Jacob Morgan
Caracteristici ale
“Learning Workers””
◼ “learn how to learn” inseamna:
◼ cum să-ți construiești un obicei de învățare continuă și să

ții ochii și urechile în permanență deschise și să înveți de la
tot ce te înconjoară
◼ cum să extragi învățarea din experiențele de muncă.
◼ cum să fii la curent cu ceea ce se întâmplă în industria și
profesia ta - nu doar mergând la o conferință anuală sau
citind câteva reviste din industrie - asta îți spune ce se
întâmplă acum, nu ceea ce se întâmplă în continuare - >
rețelele profesionale de socializare
◼ “învățarea serendipitous” - învățarea accidentală,
neplanificată, care are loc zilnic, ca urmare a unor alte
lucruri.
PLANIFICAREA
RESURSELOR UMANE
Planificarea resurselor
umane
◼ Identificarea interfetelor din proiect:
◼ Interfata organizational
◼ Implicarea unor resurse umane din departamente
diverse
◼ Interfata tehnica
◼ Implicarea in proiect a echipelor din domenii tehnice
inrudite sau diferite
◼ Ex: architect, constructor / programator, analist
economic
◼ Interfata interpersonala
◼ Relatia intre membrii proiectului
◼ Comunicare formala sau informala
Planificarea resurselor
umane
◼ Identificarea necesarului de resurse
◼ Conform activitatilor proiectului
◼ Din resursele companiei / Angajari
◼ Identificarea constrangerilor
◼ Structura organizationala: departamente
◼ Contractul de munca
◼ Modele de organizare de succes
◼ Resursele umane disponibile / Competenta
◼ Angajarea / externalizarea
Procesul de alocare a resurselor
Planificare Estimare Alocare
Scop Necesar Angajati

Ce trebuie realizat? Cat ? Pe cine?
Ore
Persoane
Competente Optimizare
Ce se cere? Cum?
Roluri
Ce competente /
atribute ?
Nevoia de resurse va varia pe parcursul proiectului.
1. De obicei, primele etape necesită participarea intensă a conducerii

organizaţiei.
2. Pentru proiectarea detaliata: analişti şi proiectanti.
3. Dezvoltarea va necesita de obicei un număr mult mai mare de personal

junior, mai mult pentru a face lucrul efectiv.
4. Testarea participarea conducerii plus un număr semnificativ de

utilizatori.
Nevoia de resurse va varia pe parcursul proiectului.
1. De obicei, primele etape necesită participarea intensă a

conducerii organizaţiei.
2. Pentru proiectarea detaliata: analişti şi proiectanti.
3. Dezvoltarea va necesita de obicei un număr mult mai mare de

personal junior, mai mult pentru a face lucrul efectiv.
4. Testarea participarea conducerii plus un număr

semnificativ de utilizatori.
Logistica
▪ parcare,
▪ autorizația de securitate și acces fizic la zonele de muncă,
▪ birou,
▪ telefon,
▪ PC cu conexiune la internet,
▪ Facilitati: xerox.......
▪ locuri pentru masa, cafea, toaletă etc.
◼ În cazul în care lucrează departe de casă: cazare, masa, transport.
◼ Timp pentru integrare
Planul de resurse umane
◼ Componente:
❑ Rol, responsabilitati & competente
◼ Diagrama de organizare a proiectului
◼ Reprezentare grafica a echipei
◼ Plan de management al resursei umane
◼ Obtinerea resursei umane
◼ Cand, cum, extern/intern
◼ Calendar de utilizare a resursei umane
◼ Training
◼ Motivare
◼ Criterii de acordare
◼ Reguli / Protectia muncii
Nothing is impossible for the
person who doesn’t have to do it.
◼ Rol = Cine, Ce face ?
◼ Responsabilitate = Cine decide ce ?
◼ Responsibility Assignment Matrix
(RAM).
◼ Rolurile stabilite
in echipa de
implementare
difera in functie
de natura
proiectului si de
la organizatie la
organizatie
Exemplu model DSDM

RAM
http://pmtips.net/responsibility-assignment-matrix/
Staffing Management Plan
◼ Planul de resurse umane trebuie sa

includa:
◼ Modalitatea de implicare in proiect
◼ Efortul depus in proiect (ore)
◼ Momentul de implicare in proiect
◼ Necesitatea resursei
◼ Modalitatea de iesire din proiect
Staffing Management
Plan
http://www.state.co.us/Y2K/Tracking_Version_1.1.html
Organizational Chart
◼ Stabileste relatiile intre persoanele din
echipa de proiect
◼ Stabileste modalitatile de comunicare
◼ Stabileste modalitatile de raportare
◼ Poate fi asociata cu organizational
breakdown structure (OBS)
◼ Stabileste relatiile intre departamente
Organizational Chart
Planificarea resurselor si
programare
Iniţial, managerul de proiect va identifica

necesarul teoretic de resurse.
Estimările vor fi formulate, nu doar pentru

efortul de ansamblu, dar si pentru categoria
specifica a resursei.
Planificarea resurselor si
programare
Este necesara corelarea cu realitatea
organizationala:
▪Exista astfel de oameni?
▪Daca nu, se pot angaja ?
▪Cand sunt disponibili ?
▪Este practica utilizarea resursei part-time in
proiect?
▪Cine autorizeaza utilizarea resursei?
▪Cum se ajunge la acord daca resursa umana
este utilizata si in alte proiecte?
ORGANIZAREA SI MOTIVAREA
RESURSEI UMANE
Modele de motivare HR
Maslow’s Hierarchy of Needs
Crestere personala, cunostinte,

implinire
Respect, apreciere, parerea celorlalti
Creaturi sociale: iubure, aprobare,

prieteni
Siguranta si stabilitate in viata,
munca si cultura
Necesitatea de a trai, aer, apa,
haine, mancare, adapost ….
1 ◼ Nevoi fiziologice
◼ sunt necesare pentru supraviețuire.
◼ oamenii lipsiți de hrană, dragoste, stimă sau siguranță ar
considera mâncarea drept cea mai mare nevoie a lor.
◼ exemple: aerul, apa, mâncarea, îmbrăcămintea și adăpostul
2 ◼ Nevoi de siguranță
◼ Odată satisfăcute nevoile fizice, siguranța individuală are
prioritate.
◼ Includ:
◼ Securitate personală
◼ Securitate financiara
◼ Sănătate și bunăstare
◼ Siguranța legata de sanitate: accidente / boli
3 ◼ Nevoi sociale
◼ strat al nevoilor interpersonal.
◼ sentimente de apartenență.
◼ deficiențele sociale: neglijența, evitarr, ostracizare …. pot afecta
capacitatea unui individ de a forma și menține relații emoțional:
prietenie, intimitate, familie
◼ oamenii au nevoie să iubească și să fie iubiți
◼ probleme: singurătate, anxietate socială și depresie
◼ pot depăși uneori nevoile fiziologice și de securitate.
4 ◼ Stima / respect
◼ dorința umană de a fi acceptat și apreciat de alții.
◼ angajeare: pentru a obține recunoaștere și pentru a avea o
activitate sau activități care să ofere persoanei un sentiment de
contribuție, să se simtă autoapreciat, fie că este vorba de o
profesie sau un hobby.
◼ Dezechilibrele pot determina: scăderea respectului de sine sau
complex de inferioritate.
◼ Versiunea „inferioară” -> necesitatea respectului din partea
celorlalți.
◼ poate include: statutul, faima, prestigiul, recunoasterea
◼ Versiunea „superioară” -> necesitatea respectului de sine. De
exemplu, persoana poate avea nevoie de putere, competență,
stăpânire, încredere în sine, independență și libertate.
◼ are prioritate față de versiunea „inferioară” deoarece se bazează pe
experiență
◼ nu sunt niveluri stricte, separate, ci strâns legate de altele
5 ◼ Auto-actualizare
◼ potențialul deplin al unei persoane și realizarea acestui potențial.
◼ dorința de a realiza tot ce se poate
◼ Exemplu: antreprenor de success, angajat model, părinte ideal,
atlet premiat, inventator.
◼ Pentru acest nivel persoana nu trebuie doar să realizeze nevoile
anterioare, ci să le stăpânească.
Herzberg’s Theory of Motivation (1)
◼ Teoria lui Herzberg încearcă să descopere nevoile
psihologice ale angajaților și să sporească
satisfacția angajaților
◼ Succesul depinde de:
◼ Agenti de igiena (Hygiene Factors )
◼ Asociati cu asteptarile individuale
◼ Conditii de munca inclusiv relatii de munca
◼ Salariu
◼ Securitate / Viata personala
◼ Statut / senzatia de a apartine de ceva
◼ Agentii de igiena nu motiveaza in mod direct dar
lipsa are efectul opus.
◼ Satisfacție pozitivă creată de condițiile specifice
ale postului.
◼ Agenti de motivare
◼ Motivatii / oportunitati:
◼ provocarea
◼ responsabilitate,
◼ apreciere,
◼ recunoastere,
◼ educatie / perfectionare
◼ Oamenii caută satisfacerea nevoilor

psihologice de nivel superior ->motivare
◼ Agentii de motivare sunt cei mai importanti
◼ Herzberg propune un model de motivație cu doi factori:

◼ un set de caracteristici duce la satisfacția lucrătorilor
◼ un set de caracteristici duce la nemulțumire
◼ satisfacția și nemulțumirea sunt independente
◼ Conducerea trebuie să actioneze asupra ambelor
caracteristici O creștere a satisfacției NU duce la
scăderea nemulțumirilor.
◼ Dacă conducerea dorește să:
◼ crească satisfacția la locul de muncă, ar trebui să se
preocupe de natura muncii în sine.
◼ reducă nemulțumirea, atunci trebuie să se concentreze pe
îmbunătățirea mediului de muncă.
◼ Natura muncii (caracteristicile postului) pe care o îndeplinește
aparent au capacitatea de motivare.
◼ absența acestora nu pare să ducă la nefericire și nemulțumire.
◼ Aparent nemulțumirea rezultă din factori legați de locul de
muncă
◼ Exemplu: politicile companiei, supravegherea, problemele tehnice,
salariul, relațiile interumane la locul de muncă și condițiile de
muncă.
◼ Aplicare:
◼ locuri de muncă care să sporească și să motiveze angajații dincolo
de simpla îndeplinire a unei cote zilnice sau săptămânale.
◼ sisteme de recompense
◼ “recunoașterea simplă” este adesea suficientă pentru a motiva
angajații
◼ motivația, cât și igiena sunt la fel de importante, dar o igienă bună
va duce doar la performanțe medii
David McClelland
◼ trei tipuri de nevoi de motivare:
◼ de realizare / achievement (n-ACH)
◼ autoritate / de putere (n-POW)
◼ afiliere (n-affil)
◼ cei mai mulți oameni posedă și prezintă o

combinație a acestor caracteristici.
Teoria echitatii a lui Adams
◼ sentimentul de echitate, care stă la baza motivației
◼ depinde de comparația facuta de fiecare angajat cu
alti angajati aflati in situație similară.
◼ Baza comparatiei: raportul recompensă / investiții
◼ Teoria explica de ce motivația este determinatat

nu numai de salariu și de condițiile de munca
◼ Echitatea nu depinde doar de raportul intrare-ieșire
◼ depinde de comparația dintre raportul nostru și
raportul altora.
Adams’ Equity Theory diagram - job motivation
Studiu de caz
Scales ‘calibrated’ and measured against

comparable references in the market place
What I put into my job: time, effort, What I get from my job: pay, bonus,
ability, loyalty, tolerance, flexibility, perks, benefits, security, recognition,
integrity, commitment, reliability, interest, development, reputation,
heart and soul, personal sacrifice, etc praise, responsibility, enjoyment, etc
inputs outputs
People become demotivated, reduce input and/or seek change/improvement whenever they
feel their inputs are not being fairly rewarded. Fairness is based on perceived market norms.
© design alan chapman 2001-7 based on J S Adams’ Equity Theory, 1963. More free online learning materials are at
www.businessballs.com .
Teoria dezvoltarii -Erikson
◼ oamenii experimenteaza opt "stagii de criza psiho-
sociala", care afectează în mod semnificativ
dezvoltarea și personalitatea
◼ Termenul "psiho-social" este derivat din cele două
cuvinte sursă
◼ psihologic (sau rădăcina, referitor la minte, personalitate
◼ social (relații externe, mediu)
◼ Trecerea cu succes prin fiecare criză implică
"atingerea" unui raport sănătos sau echilibrat între cele
două dispozițiile opuse
◼ Erikson a numit aceste rezultate echilibrate "Virtuți de
bază" sau "Forță de bază".
Studiu de caz
Approximate Psychosocial Significant Existential

Virtues Examples
Age crisis relationship question
Infancy0-23 Basic trust vs. Can I trust the
Feeding,
Hope Mother
months mistrust world? abandonment
Early Toilet training,
Autonomy vs. Is it okay to be
childhood2–4 Will Parents clothing
shame and doubt me?
years themselves
Is it okay for me Exploring, using
Preschool age4–
Purpose Initiative vs. guilt Family to do, move, and tools or making
5 years
act? art
Can I make it in
School age5–12 Industry vs. Neighbors, the world of
Competence School, sports
years inferiority school people and
things?
Adolescence13– Identity vs. role Who am I? Who Social
Fidelity Peers, role model
19 years confusion can I be? relationships
Early
Intimacy vs. Romantic
adulthood20–39 Love Friends, partners Can I love?
isolation relationships
years
Adulthood40–64 Generativity vs. Household, Can I make my Work,
Care
years stagnation workmates life count? parenthood
Ego integrity vs. Is it okay to have
Maturity65-death Wisdom Mankind, my kind Reflection on life
despair been me?
https://en.wikipedia.org/wiki/Erikson%27s_stages_of_psychosocial_development
http://web.cortland.edu/andersmd/ERIK/welcome.HTML
Macnow, Alexander Stone, ed. (2014). MCAT Behavioral Science Review. New York City: Kaplan Publishing. p. 220. ISBN 978-1-61865-485-4.
McGregor’s Theory of X and Y
◼ Doi factori motivationali in opozitie X si Y:
◼ Teoria X – factori motivationali externi:
◼ Factori motivationalie externi, de exemplu: supravegherea, recompensele,
penalitățile și regulile, creaza rezultate comportamentale dorite
◼ Ipoteza:
◼ in general angajatii nu vor sa munceasca, trebuie supravegheati, nu sunt
capabili sa obtina rezultate
◼ managerii trebuie sa ia masuri de corectie, incluzand amenintari si alte masuri
de control
◼ Solutie:
◼ conducerea va stabili obiective, va supraveghea execuția și va oferi
recompense
◼ managementul autoritar: angajații pot fi motivați extern de existența
supravegherii sau pedepsei
◼ recompensele sunt pozitive pentru performanțe puternice și negative pentru
performanțe proaste
◼ recompense: motivați extern de absența supravegherii sau pedepsei.
◼ reduce animozitatea și anxietatea.
McGregor’s Theory of X and Y
◼ Teoria Y - factori motivationali interni:
◼ motivații interni: pasiunea, satisfacția la locul de muncă,
responsabilitatea și auto-valoarea
◼ Ipoteza:
◼ Angajatii vor sa lucreze, vor sa obtina performante, apreciaza respectul
si nevoia de a se autodepasi
◼ angajații se bucură de o provocare și se străduiesc să adauge valoare
pentru a contribui la o comunitate.
◼ Solutie:
◼ managerul nu controlează în totalitate
◼ construirea unor relații “de prietenie” între conducere și angajați și
eliminarea autorității
◼ construirea proceselor organizaționale pentru a crea aliniere
◼ Probleme:
◼ poate fi ușor să se piarda orientarea catre atingerea obiectivelor
◼ posibilitatea angajaților mai puțin motivați să profite de un mediu de
lucru relaxat.
William Ouchi Theory Z
◼ Teoria Z: (William Ouchi – completare la X si Y)
◼ Exemplul japonez – management participativ:
◼ managementul cu grad ridicat de încredere în lucrătorii săi
◼ lucrătorii vor participa la deciziile companiei într-o mare
măsură
◼ Factori motivationali:
◼ implicare, oportunitate, promovare
◼ Se accentueaza: increderea, calitatea, decizia
colectiva, valori culturale
◼ Angajatii cresc constant in ierarhica a companiei
◼ promovare lenta in favoarea pregatirii temeinice
◼ Angajat “pe viata”
William Ouchi Theory Z
◼ Secretul succesului japonez:
◼ „… stil de management care se concentrează pe o filozofie
puternică a companiei, o cultură corporativă distinctă,
dezvoltarea pe termen lung a personalului și luarea de decizii
prin consens” (Ouchi, 1981).
◼ Ipoteze:
◼ Angajatii construiesc relații de lucru cu cei pentru care lucrează,
cu cei cu care lucrează și cu cei care lucrează pentru ei.
◼ Angajatii au nevoie sa fie susținuți de companie
◼ Angajatii apreciază un mediu de lucru în care valorile sunt
considerate la fel de importante ca munca în sine. Exemplu:
familia, cultura și tradițiile
◼ Angajatii orienati catre ordine, disciplină, o obligație morală de a
lucra sustinut și coeziune cu colegii lor de muncă.
◼ Angajatii vor lucra mai mult, atâta timp cât se poate avea
încredere în conducere pentru a-i sprijini și a se asigura de
bunăstarea lor
Teoria rezultatului
◼ Angajatii sunt orientati catre beneficiu
◼ Angajatii se vor comporta in concordanta cu:
◼ asteptarile pe care le au
◼ rezultatul pe care doresc sa il obtina
◼ Motivatia este constituita de:
◼ Atractivitatea beneficiului
◼ Munca este rasplatita
Teoria impunerii
◼ “Reinforcement”
◼ descrie patru mecanisme de interventie
pentru a modifica comportamentul
angajatilor.
◼ metode de creștere a comportamentelor
dorite,
◼ metode de reducere a comportamentelor
nedorite.
Studiu de caz
https://saylordotorg.github.io/text_organizational-behavior-v1.1/s09-theories-of-motivation.html
Thamhain si Wilemon’s
Influence on Projects
Managerul de proiect:
◼ Autoritatea: legitimitate ierarhica
◼ Atribuirea: alocarea de activitai
◼ Buget: autorizarea de fonduri in puterea sa
◼ Promovarea: pozitia in organizatie, pozitia sociala
◼ Banii: salariu, beneficii
◼ Penalitati: posibilitatea de a penaliza
◼ Competitia: o activitate placuta vs o activitate
neplacuta
◼ Expertiza: implicarea in alte activitati
◼ Prietenia: relatiile stabilite
Ce ajuta si ce distruge?
◼ Succes, managerul influenteaza prin:
◼ Expertiza
◼ Competitie
◼ Competenta
◼ Esec managerul influenteaza prin:
◼ Autoritate
◼ Duritate
◼ Bani
◼ Penalitati
Putere
◼ Puterea reprezinta abilitatea de a infuenta
comportamente si actiuni.
◼ Tipuri:
◼ Coerciv – constrangere
◼ Legitimate
◼ Expert
◼ Beneficiu / premiere
◼ Exemplu Everyone asks for a strong project
manager – when they get them they
don’t want them.
Eficenta
◼ Eficienta se poate imbunatati prin:
◼ Caracter proactiv
◼ Vizualizare a finalizarii
◼ Ordonare in functue de prioritati
◼ Quid pro quo
◼ Intelege pentru a fi inteles
◼ Sinergie
◼ Perfectionare
ALOCAREA
ECHIPEI DE PROIECT
◼ Separarea responsabilitatilor intr-un
proiect presupune organizarea a doua
echipe:
◼ Echipa de management
◼ Echipa de implementare
Echipa de management
Sponsor
Manager de
proiect
Echipa Echipa
Echipa suport
functionala administrativa
Echipa de proiect
◼ Manager de proiect / Manager adjunct
◼ Asistent de proiect
◼ Creaza, consolideaza, coordoneaza planificare
proiectului.
◼ Proceseaza fisele de pontaj.
◼ Genereaza rapoarte privind desfasurarea
proiectului.
◼ Manager de activitate / echipa
◼ Coordoneaza activitatea echipei de implementare
◼ Monitorizeaza desfasurarea activitatii.
◼ Manager al schimbarii
◼ Coordoneaza schimbarile la nivel procedural sau
organizational: identifica, evalueaza, planifica,
coordoneaza si tine evidenta schimbarilor.
◼ Manager de formare
◼ Identifica, dezvolta, organizeaza, achizitioneaza si
monitorizeaza activitatile de formare a resursei umane
◼ Arhitect
◼ Monitorizeaza dezvoltarea solutiiilor de afacere:
aplicatii, procese, proceduri, servicii, facilitati
◼ Arhitect de tehnologie
◼ Monitorizeaza implemetarea proiectului din punct
de vedere al tehnologiilor.
◼ Manager al configuratiilor
◼ Asigura managementul versiunilor livrabilelor
◼ Manager de calitate
◼ Monitorizeaza respectarea planului de calitate.
◼ Avizeaza livrabilele
◼ Manager organizational / resurse umane
◼ Defineste sau modifica structuri organizationale
◼ Defineste atributii si cerinet pentru rolurile din
cadrul proiectului
◼ Evalueaza resursa umana
◼ Consultant juridic
◼ Responsabil financiar
◼ Gestioneaza bugetul proiectului.
◼ Asigura legatura cu departamentul financiar si
supervizeaza activitatea financiara.
Personal auxiliar
◼ Specialist in comunicare
◼ Cordoneaza comunicarea externa si interna proiectului.
◼ Identifica nevoile de comunicare si imagine, creaza
comunicate, evalueaza impactul
◼ Specialist in securitate
◼ Asigura securitatea datelor si livrabilelor.
◼ Identifica, defineste si monitorizeaza livrabilele din punct
de vedere al necesitatilor legate de securitate
◼ Manager al bazelor de date
◼ Web master
◼ Dezvolta si actualizeaza portalul web al proiectului
Personal auxiliar
◼ Secretara
◼ Suport grafic
◼ Creaza continut vizual: prezentari, diagrame, imagini,
continut vizual web
◼ Suport tehnic
◼ Instaleaza si administreaza echipamente si software:
PC, servere, retele.
◼ Administrator
◼ Se ocupa de activitatile curente: control procedural,
comunicatii, intalniri, management de resurse si
achizitii pentru servicii, materiale, resurse, sali, etc
Tipuri de persoane
Roluri destructive
Critica pe cei implicati, ataca

Agresorul
statutul colegilor
Inceraca sa preia controlul, “stie

Dominatorul
tot”, manipuleaza
Gaseste greseli in MP, nu

Avocatul
asculta
Cel care schimba Primul cu o idee, schimba

subiectul subiectul, nu termina
Tipuri de persoane
Roluri destructive
Cel care cauta Se lauda, isi arata pozitia,

recunostinta sustine propriile idei
Nu se face remarcat, e timid,

Lasul
ascunde info, speriat
Cel care Critica, respinge pareri, opinii

blocheaza personale
Tipuri de persoane
Roluri pozitive
Atitudine proactiva, dispus sa

Initiatorul
incerce
Cel care Are atitudine pozitiva, lauda efortul

incurajaza
Cel care ofera Este informat, stie unde sa caute,

informatia are experienta
Cel care cauta Cauta, se documenteaza,

informatia intreaba
Tipuri de persoane
Roluri pozitive
Pacificatorul Apropie perspective diferite
Negociatorul Supune la vot, cauta compromisul
Deschizatorul Crere alte opinii, cauta alte

de porti solutii
Cel care Ofera o mai buna perspectiva,

clarifica explica
Managerul de proiect
◼ Exercitarea autoritatii de catre PM:
• Competente profesionale superioare
Expertiza • Expertiza / cunostinte
• Recompensa motiveaza
Recompensa
• Respect
Referinta • Conduce prin exemplu
• Pozitia / ierarhia
Legitimitate • Reduce implicarea angajatilor
• Angajatul este motivate prin pedeapsa

Coercitiv
Managerul de proiect
◼ Tipuri de conducere:
◼ Autoritar . .
◼ Democratic
◼ “laissez-faire”
Combinatii
posibile
Tehnica de management
◼ Urmatoarele activitati desfasurate de manager:
◼ Planificarea
◼ Organizarea
◼ Alocarea de resurse
◼ Controlul
◼ Conducerea
◼ Controlul presupune:
◼ Masurarea
◼ Evaluarea
◼ Corectarea
Tehnica de management
◼ Conducerea = executia (prin delegare) a planului presupune
◼ Alocarea resurei
◼ Formarea resursei
◼ Supravegherea / Monitorizarea
◼ Delegarea de responsabilitate
◼ Motivarea
◼ Consultarea
◼ Coordonarea
◼ Autoritatea (Authority)
◼ dreptul de a lua decizii pentru indeplinirea obiectivelor
◼ Responsabilitatea (Responsibility)
◼ Alocarea unei sarcini specifice
◼ Raspunderea (Accountability)
◼ Acceptarea esecului sau a succesului
Obtinerea
echipei de proiect
 Predictia
 Selectia in avans
 Negocirea pentru alocare
 Manageri
 Alte proiecte
 Organizatii externe, subcontractare
 Echipe virtuale
 Angajari The same work under the same
conditions will be estimated differently
by ten different estimators or by one
estimator at ten different times.
Obtinerea echipei de
proiect (Staffing Pool)
◼ Experienta:
◼ activitate similara finalizata cu succes
◼ Motivare:
◼ Exista motivare pentru participare la proiect
◼ Colaborare
◼ Cum se integreaza in echipa
◼ Disponibilita
◼ Va fi disponibil cand este nevoie ?
◼ Cunostinte
◼ Nivel de cunostinte / competenta
Obtinerea echipei de
proiect
◼ Am gasit decalajul, cum umplem acest
gol?
◼ Cat de mult timp este necesar pentru
identificarea persoanei potrivite?
◼ Urmarirea pasilor necesari pentru a angaja
un nou membru in cadrul echipei de
proiect.
Mobilizarea resursei
Obtinerea resurselor pentru un proiect necesită abilitati
diferite de management de proiect.
Necesita un sprijin puternic al sponsorul proiectului si o

atentie constanta a managerului de proiect
Resurele necesare sunt, de obicei, ocupate cu norma

intreaga in departamentele in care lucreaza.
Nivelul de integrare este problematic in cazul in care

angajatii vor lucra o fractiune de norma intrega in proiect.
Recrutare
◼ Procesului de localizare,
identificarea şi atragerea de
candidaţi
◼ Pentru activităţi curente sau
viitoare
◼ Activităţi critice pentru
companie
◼ Ce surse se folosesc pentru

recrutare?
Recrutare
◼ Pasi pentru recrutare
◼ Anunt recrutare – fisa postului
◼ Selectie
◼ Interviu
◼ Test
◼ Verificare referinte
◼ Angajare
Selecţia
◼ Exercitarea predicţiei
◼ Perfect, Imperfect
◼ Exerciţiu de luare a deciziilor
◼ Scopul este de a angaja persoana (ele) în măsură să
satisfacă nevoile de organizare.
◼ Legată de strategie
Selecţia
◼ Există modalităţi prin care managerii se
pot asigura că decizia atinge rezultatul
dorit? (data şi ora din nou)
◼ Da, utilizând instrumentele de RU care sunt
sigure şi valide
◼ Fiabiltatea:
◼ Gradul cu care fiecare instrument de selecţie
măsoară aceleaşi în mod constant
◼ Poate fi un test sau un interviu
Valabilitate
◼ Relaţia dintre instrumentul Selecţie şi criteriul
adecvat
◼ Ce măsoară tehnica de selecție şi cât de bine
măsoară ?
◼ Elementele masurate trebuie să fie
◼ relevante pentru locurile de muncă
◼ Dovedite (referinte, certificari ....)
◼ EX: Abilităţile de redactare pentru un functionar
care introduce date.
Eficienta interviurilor
◼ Elemente legate de eficienta interviurilor:
◼ Cunoştinţe anterioare
◼ Atitudinea celui care conduce interviul
◼ Ordinea interviului
◼ Informaţii negative
◼ “Primele cinci minute”
◼ Cuprinsul interviului
◼ Valabilitatea interviului
◼ Interviu structurat versus interviu nestructurat
Tipuri de interviuri
◼ Non-directive
◼ Ȋntrebări generale
◼ Raspuns discutabil
◼ Structurate
◼ Comisie multidisciplinara
◼ Studiu de caz
◼ Descriere comportamentala – situatie in care a fost
implicat
Teste Scrise
◼ Inteligenţă
◼ Aptitudini generale
◼ Abilităţi
◼ Cunostinte
◼ Interese
Verificarea referintelor
◼ Potentialul angajator urmăreşte să verifice
informaţiile
◼ Este important să existe întrebări bine
construite
◼ Se poate externaliza?
◼ Multe companii folosesc firme de recrutare
◼ Cât de departe poţi ajunge?
◼ Outsourcing
Orientare
◼ Procesul de introducere a angajaţilor în
organizaţie
◼ Familiarizarea noului angajat cu locul de
muncă la unitate
◼ Suport pentru angajat pentru înţelegerea
de valori şi comportamente acceptabile
DEZVOLTAREA
CUNOSTINTELOR
ECHIPEI DE PROIECT
Dezvoltarea
echipei de proiect
◼ Dezvoltare de aptitudini interpersonale
◼ Training / certificare
◼ Team-building
◼ Reguli de organizare
◼ Co-locatia
◼ Merite & beneficii
◼ Evaluare de performanta – metrici de
performanta
Meyers-Briggs Type
Indicator (MBTI)
◼ MBTI = determinarea
tipului de personalitate
si posibilelor relatii
◼ 4 dimensiuni
◼ Extrovertit/Introvertit (E/I)
◼ Sensatie/Intuitie (S/N)
◼ Ganditor/Sensibil (T/F)
◼ Judecata/Perceptie (J/P)
Social Styles
Formare şi Dezvoltare
◼ Experienţa de învăţare, care solicită o
modificare relativ permanentă
◼ Implică schimbarea de competenţe,
cunoştinţe, atitudini sau comportamente
Formarea angajaţilor
Ce deficiențe, în termeni
de competenţe, cunoştinţe, Care sunt
abilităţi şi comportamente? Exista o nevoie obiectivele
pentru formare strategice de
organizare?
Ce sarcini trebuie
îndeplinite pentru
Care sunt atingerea obiectivelor?
comportamentele
necesare
MANAGEMENTUL
ECHIPEI DE PROIECT
Managementul
echipei de proiect
◼ Rapoarte de activitate si performanta
◼ Structura de raportare a activitatii
◼ Observatie
◼ Evaluarea performantelor
◼ Management al conflictelor
What is not on paper has not been said.

Conflictele in echipa
Studiu de caz
Solutionarea conflictelor
Metoda 1 = cercetarea cauzelor si analiza solutiilor
Problema Cercetare
Solutii
Metoda 2 = compromis
Problema Cercetare
Solutie Solutie
1 2
Metoda 3 – restrangerea problemei
Problema
Problema Diminuare
Metoda 4 – fortarea unei solutii temporare
Problema Solutie
FORTA
imediata
Metoda 5 – retragerea
Solutie
Problema Retragere
imediata
Managementul
Performaţei
◼ Integrarea practicilor de management care
include evaluarea formală a performanţei
angajatului.
◼ Cât de des?
◼ Include stabilirea de standarde de performanță și
evaluare a performanţei
◼ Reprezinta mijloace care să asigure obiectivele
organizatorice
Metode de evaluare a performanţei
Eseu scris Incidente critice
Graphic
BARS Multiperson
Rating Scales
Reviziure la
MBO 360-grade
Metode de actiune pentru
performanţa scăzută
◼ Formare
◼ Disciplină
◼ Coaching
◼ Disponibilizare
Premieri
◼ Scop:
◼ să atragă şi să păstreze
◼ aă furnizeze un stimulent pentru a obtine
performanta in activitate
◼ atructurat pentru a se asigura că nivelurile de
remunerare sunt percepute echitabile
Factori care influenţează
premierile
Exploatare angajatului Profitabilitatea
şi performanţă companiei
Locuri de munca
Marimea efectuate
companiei
Nivelul
premierilor
Locatia şi beneficiilor Tipuri de afaceri
georgrafica
Filosofia de Munca – Unificare

management sau capital
- intensiv
Sănătatea şi Siguranţă
◼ Angajatorii sunt responsabili de asigurarea
unui mediu de lucru sănătos şi sigur
◼ Angajaţii urmeaza instrucţiunile şi cerințele
legale
Relaţiile de muncă
◼ Relatia dintre angajati si organizatie
◼ Negocierea colectivă este un proces de
negociere a termenilor și condițiilor contractului
de muncă
◼ Negociere produce un document scris numit
contract colectiv de munca
MANAGER VS LIDER
Rolul
Mangerului de proiect
◼ Actualizeaza cerintele, in urma unor verificari regulate, in
concordanta cu necesitatile clientului.
◼ planifica proiectul stabilind metode ce permit evaloarea performantei
și controlul schimbării.
◼ Asigura legatura intre utilizatorii finali, sponsori, management si
echipa de proiect
◼ gestioneaza progresul proiectului, atingerea obiectivelor, rezolvarea
problemelor si atenuarea riscurilor.
◼ gestioneaza tehnologia, oamenii și schimbarea pentru a atinge
obiective si creaza un mediu de lucru potrivit necesitatilor
◼ Gestioneaza rezultatele proiectului astfel incat sa fie obtinute la timp
cu bugetul alocat.
◼ Gestioneaza incertitudinea, schimbările, ambiguitatea, surprizele
◼ Raporteaza activitatea catre sponsor
Lider vs manager
◼ Abilitati si cunostinte
◼ Interactiunea cu oamenii
(“People skills”)
◼ Cunostinte tehnice in
domeniul proiectului
◼ Cunostinte de
management
◼ Adaptabilitate
<a href="https://www.freepik.com/free-photos-vectors/infographic">Infographic
vector created by Vectorpocket - Freepik.com</a>
Lider vs manager
Interactiunea cu oamenii
“Manage by example” Comunicare verbal
/ nonverbala
Pozitiv
Created by Dooder - Freepik.com
Lider vs manager
Spirit de echipa
Created by Pressfoto - Freepik.com

Proactiv
Created by Sapann-Design - Freepik.com
Integritate
Lider vs manager
◼ Intelegator
◼ “Underpromise, then over-deliver”
◼ Deschis
◼ Capacitatea de a asculta
◼ Consistenta
◼ Incredere
◼ Etica
Cunostinte tehnice in
domeniul proiectului
◼ tipuri de probleme tehnico
◼ Spatiul problemei si spatial
solutiilor
◼ Calitate și performanta
◼ Rolul membrilor echipei de
proiect
◼ Resurse externe
◼ Outsourcing
◼ Subcontractare
◼ Consultanta
Cunostinte de
management
◼ Management de proiect
…
◼ Stabileste prioritatile
◼ Gandire critica
◼ Solutionare probleme
◼ Formare echipa
◼ Negociere
◼ Management al
Managementul Costurilor
Managementul Achizitiilor
Curs 8
Cuprins
• Managementul Costurilor
• Estimarea costurilor
• Determinarea bugetului
• Controlul Costurilor
MANAGEMENTUL COSTURILOR
• Managementul Costurilor
– reprezinta procesul de estimare si control al costurilor,
– rezultat dorit: proiect finalizat in limita bugetului
disponibil.
• Procesele aferente Managementului Costurilor
sunt:
– Planificarea managementului costurilor
– Estimarea Costurilor
– Determinarea Bugetului
– Controlul Costurilor
MANAGEMENTUL COSTURILOR
Estimarea Constructia Controlul
Costurilor Bugetului costurilor
• Estimarea • Analiza • Indicatori de
Planificare
costurilor cerintelor performanta

activitatilor financiare • Cash flow
• Justificarea • Repartizarea • Modificari
estimarilor bugetului
conform
duratei
proiectului
Principii de baza
• Profit
– venit – cheltuieli (simplificat)
– Proiecte generatoare de venit vs proiecte non-profit
• Cash Flow
– flux al banilor
– alimentarea conturilor proiectului
– diferenta intre incasarile curente si platile curente
• Costuri sau beneficii tangibile
– Costuri / beneficii ce pot fi calculate cu relative precizie
• Costuri sau beneficii intangibile
– Costuri / beneficii ce nu pot fi calculate cu precizie
Cuvinte cheie
• Costuri sau beneficii directe
– Costuri / beneficii ce pot fi associate rezultatelor proiectului
(obiectivelor proiectului)
• Costuri sau beneficii indirecte
– Costuri / beneficii ce nu pot fi asociate direct rezultatelor
proiectului
– Aceste costuri trebuie insa luate in calcul
• Rezerva
– Rezerva de contingenta – sume rezervate pentru situatii de risc
prevazute
– Rezerva de management – sume rezervate pentru situatii
neprevazute
ROI (return on investment)
• ROI
– măsură utilizată pentru a compara eficiența investiției
• Formula ROI este:
– 100 x (venit - costul investiției) / costul investiției
Beneficii tangibile Beneficii intangibile

• Baza de calcul pentru ROI (nu se iau in calcul)
Exemple: • creșterea satisfacției clienților
• Reducere cost • servicii îmbunătățite
• Reducere timp • crestere a gradul de utilizare
• Vanzari suplimentare • procese automatizate / acces rapid
la informatie
• suport îmbunătățit
• Managementul Costurilor se realizeaza in
concordanta cu:
- Cerintele stakeholderilor
- Necesarul de resurse
- Analiza performantelor financiare
- Predictia performantelor financiare
- Profit
- Flux al banilor (Cash Flow)
PLANIFICAREA COSTURILOR
Etapa de Planificare
• Inainte de inceperea celor 3 procese aferente
Managementului Costurilor, se introduce
etapa de planificare.
• Etapa presupune
– realizarea un plan de management al costurilor
necesar etapelor de planificare, structurare,
estimare si control al costurilor
– Proces are stabileste politicile, procedurile si
documentele de planificare, management, executie
bugetara si control al costurilor.
Livrabil:
• Planul de management al costurilor
– Descrie aspect de baza ala managementului costurilor
in cadrul unui proiect. Stabileste modul de
reprezentare, raportare si control al costurilor unui
proiect.
• Etapa de planificare poate cuprinde:
- Precizia acceptata in cazul estimarilor
- Unitatea monetara folosita ( Lei / Euro / Dolari)
- Procedurile organizationale de lucru
- Preaguri de control al costurilor (depasiri)
- Metode de masurare a performantelor finaciare
- Modalitati de raportare (format, circuit, perioade)
- Descrierea proceselor de management al costurilor
ESTIMAREA COSTURILOR
- Estimarea costurilor unui proiect se realizeaza
in paralel cu desfasurarea proiectului, pe
durata intregului ciclu de viata al proiectului
- Se tine cont de
- toate resursele implicate in proiect
- cursul valutar
- Managementul schimbarilor
- Managementul riscurilor …
Estimarea costurilor are ca punct de plecare:
• Declaratia de continut
– WBS
• Plan de activitati
• Planul de resurse umane
• Plan de risc
• Factori organizationali
– Conditii economice, lectii invatate
PAS 1
Metode de estimare a costurilor

De unde se incepe?
Plan de scop Politici de

organizatie
Plan de Plan de realizare
proiect Resurse umane
Plan de achizitii
Plan de risc
PAS 2
Ce metode folosim?
Software ce imbina metode

Judecata bazata pe expertiza Estimare prin comparatie
Estimare bazata pe consultarea

Estimare prin analogie
expertilor
Estimare “bottom-up” Estimare parametrica
Estimare “top down” Metoda celor 3 puncte
Estimare hibrida Estimare bazata pe calitate

PAS 3
Ce rezulta?
Buget
Raport de
metoda Plan de realizare
Actualizare plan Resurse umane
proiect
Plan de achizitii
Metode de
1
estimare
Estimare top-down
Total
Top
20.000
down
WP1 WP2
12.000 8.000
T1.1
5.000
Metode de
2
estimare
Estimare bottom - up
Proiect
up
Activitate 6.000
Task 1.000 5.000 Bottom

Metode de
estimare 3
Estimare prin
analogie
Costuri ce vor fi
asemanatoare si in
cazul proiectului
actual
Se poate defini un procent

se similitudine ce se aplica
global tuturor categoriilor de
costuri
Metode de
4
estimare
Estimarea parametrica
Se folosește o rată unitară și se
înmulțește cu numărul de unități.
Exemplu:
Costul de constructie: 120
lei/mp
Costul de realizarea a unui
proiect de 100 lei plan /
schita
https://www.smartsheet.com/ultimate-guide-project-cost-estimating
Metode de
5.1
estimare
Costul calității
• Costul calității (cost of quality) se referă la
costurile totale necesare pentru aducerea
produselor sau serviciilor la specificatiile
definite de management.
• Pentru a determina costul calității, se combina
costurile conformității cu cele ale
neconformității.
• Cost of Quality (COQ) = Cost of Poor Quality
(COPQ) + Cost of Good Quality (COGQ)
Metode de
5.2
estimare
Costul calității
• Costul neconformității
– Costuri interne (defecte gestionate în cadrul organizației)
• Resturi, refacere, re-inspecție
– Costuri externe (defecte care ajung la consumator)
• Raportare evenimente adverse, garanție, corecții și îndepărtări,
răspundere pentru produs, pierderea reputației mărcii
• Costul conformității
– Costuri de evaluare (control de calitate in cadrul
organizației)
• Inspecție (produs), Testare (acceptare), Audituri de calitate,
calibrare
– Costuri de prevenire (activități de eliminare a defectelor)
Identificarea categoriilor de cheltuieli
• Un buget de proiect cuprinde: Personal Echipamente
– Costuri directe
– Costuri indirecte
• Acestea se pot imparti dupa: Cost al proiectului
– categoriile de cheltuieli,
– tipurile specifice de cost,
Materiale
– tipurile de costuri lunare,
– costurile totale in functie de categorie, Suport
– cheltuielile totale lunare, costurile totale.
1 Costuri directe
• “Costurile directe sunt acele costuri efectuate de către
organizatie, care pot fi atribuite unei anumite activităţi
individuale din cadrul proiectului şi pentru care poate fi
demonstrată legătura cu activitatea în cauză. “- Ghidul
solicitantului POS
• Costurile directe sunt alcatuite din:
– Costuri directe de personal
– Costuri cu subcontractarea
– Costuri cu terte parti
– Alte costuri directe
Costuri directe
• Costuri directe de personal
• Salarii
– Conform contractului de munca
– Se bazeaza pe un tarif ora
– Include costurile de management
• Contributii salariale catre bugetul de stat
• Costuri cu subcontractarea; Costuri cu terte parti
• anumite parti ale proiectului pot fi contractate
• Subcontractorul poate fi considerat terta parte
Costuri directe
• Alte costuri directe
– Costurile cu deplasarile: transport, cazare, diurna
– Costurile cu amortizarea activelor ( echipamentelor,
infrastructura … )
– Costurile cu inchirierea sau leasing-ul
– Costurile pentru achizitia de bunuri sau servicii
• Include: consumabile si accesorii, IPR, publicitate
– Costurile capitalizate si de exploatare
• costurile suportate pentru infiintarea si / sau reînnoirea
infrastructurii de cercetare
– Costurile de exploatare
• Functionarea infrastructurii de cercetare (definite ca atare)
Costuri directe
• mijloc fix
– orice imobilizare corporală, care este deţinută pentru a fi
utilizată în producţia sau livrarea de bunuri sau în
prestarea de servicii, pentru a fi închiriată terţilor sau în
scopuri administrative,
• dacă are o durată normală de utilizare mai mare de un an şi
• o valoare mai mare decât limita stabilită prin hotărâre a
Guvernului;
• Valoarea de intrare (valoarea fiscală) a mijloacelor fixe
în patrimoniu
– HG nr. 276/2013, această valoare este de 2.500 ron
– 1.800 ron (12.02.2007 – 30.06.2013)
(ANAF http://static.anaf.ro/static/10/Anaf/AsistentaContribuabili_r/Definitii.htm)
Costuri directe
• Mijloace fixe:
– terenurile, inclusiv investițiile pentru amenajarea acestora,
– construcțile,
– instalațiile tehnice, mijloacele de transport, animalele și
plantațiile,
– mobilierul, aparatura birotică
• Nu intra in aceasta categorie:
– Piesele de schimb
– sculele, instrumentele și dispozitivele
– construcțiile și instalațiile provizori incluzand prototipul
Costuri directe
• Amortizarea
– reprezintă procesul de repartizare a valorii de intrare
asupra întregii sale durate de utilizare.
– Elemente de intrare: tip, valoare, durata de
amortizare
– Metodele de amortizare folosite sunt:
• Amortizarea liniară
– Valoare constanta pe parcursul duratei de amortizare
• Amortizarea accelerată
– In primul an se amortizeaza o valoare de pana la 50% din total
• Amortizarea degresivă
– Amortizare mai mare la inceput
Costuri directe
• Amortizarea liniară
– Valoare: 4000 ron
– durata de utilizare 4 ani
– Amortizarea anuală v-a fi: 4000/4=1000 ron/an.
– Lunar 1000/12=63,33 ron/lună
• Amortizarea accelerata
– Anul 1: A = 50% x 20.000 = 10.000 lei
– A1 = 10.000/12 = 833,33 ron/lună
– A2-5 = 10.000/4 = ron/an.
– A2-5l = 2.500 /12 = 208,33 ron/lună
2 Costuri indirecte
• “ acele costuri eligibile care nu pot fi identificate
de către organizatie ca fiind direct atribuite
proiectului, dar care pot fi identificate şi
justificate prin sistemul contabil ca fiind angajate
în legătură directă cu costurile directe eligibile
atribuite proiectului. “ - Ghidul solicitantului POS
• Se pot calcula
– Ca procent din cheltuielile directe
• Se accepta un procent variind intre 5-25%
• In anumite cazuri poate ajunge si la 80-90%
Costuri Indirecte
• Exemple
– Salarii persona administrativ / auxiliar
– electricitate
– încălzire
– alimentare cu apă
– Servicii de curăţenie
– Servicii de telefoni / posta / fax / curier
– Servicii de internet
– …..
Studiu de caz
Tipuri de cost (exemple)

• Costuri indirecte ("overheads"):
– Facilities & Administrative (F&A) Costs
• Administrative computing
• Central Administration
• General Accounting
• ƒHuman Resources
• ƒPayroll Accounting
• Departmental administration
• • Mailing costs (routine)
• Selected publications/subscriptions
• Building depreciation
• Interest expense related to buildings
• Maintenance/operations of facilities
• Purchasing/procurement costs
• Utilities
Studiu de caz
– proiecte europene
• Direct costs:
– actual*,
– directly attributed to and during the duration of the
project
– recorded in accounts of beneficiary
– in accordance with its usual accounting and
management principles
• Indirect costs ("overheads"):
– No indirect costs on subcontracting
Studiu de caz
• Non - eligible Costs
– Exclusion principle : any cost not fulfilling all of the
conditions of eligible costs
• Indirect taxes:
– VAT, duties, …
– Interests owed, Exchange losses, bank charges …
• Calculation of Indirect Costs
– Indirect costs = percentage of direct costs
– Actual overhead
– simplified method
– Flat rate of 20% of direct costs
Studiu de caz
Modalitatea de calcul a salariului
• Salariul primit in cadrul unui proiect poate fi:
– Salariu fix – numar de ore constant pe luna
– Salariu variabil
• Numar de ore variabil pe luna
• Prime sau bonusuri in functie de rezultate
• salariul se calculeaza pe baza unui pontaj in
care se specifica numarul de ore lucrate
pentru proiect si activitatea prestata
• In cazul completarii unui pontaj salariul se
calculeaza ca:
– Nr ore lucrate x tariful orar
• Denumiri utilizate in calculul salariilor:
– Salariul brut
• reprezinta suma de bani inregistrata in contractul de munca.
– Salariul net
• reprezinta diferenta intre salariul brut si cheltuielile
deductibile (contributii obligatorii si cheltuieli profesionale).
– Costul salarial
• Salariul brut + contibutiile datorate de angajator
• Suma totala platita de angajator pentru un angajat
Calcul salariu
Pentru a usura
calculele se poate
folosi o aplicatie
web – calculator
de salarii
!!!
Calculul final trebuie
validat de un
contabil
http://www.calculator-salarii.ro
Contractul de munca http://www.legislatiamuncii.ro
http://www.itmgiurgiu.ro/formulare/tipuri_contracte.pdf
Contractul de munca (CIM)

• După criteriul duratei pot fi :
– contracte individuale de muncă încheiate pe perioadă
nedeteminată
– contracte individuale de muncă încheiate pe perioadă
determinată
• După criteriul timpului pot fi :
– contracte individuale de muncă cu normă întreagă de 8 ore
– contracte individuale de muncă cu timp parţial (minim 2 ore /zi
şi 10 ore /săptămână).
• După locul unde se desfăşoară activitatea pot fi :
– contracte individuale de muncă încheiate pentru o activitate ce
se desfăşoară la sediul societăţii sau în alte incinte ale societăţii
– contracte individuale de muncă încheiate pentru activitate ce se
desfăşoară la domiciliul salariatului .
Considerente practice
• Inceputul proiectului va presupune o perioada de
“orientare” de 5-10% din durata care trebuie luata in
considerare la estimarea duratelor activitatilor de
inceput. Aceasta perioada nu poate fi justificata sau
inclusa in buget, este o LECTIE PRACTICA.
• costurile de management se pot calcula ca procent
din costurile de implementare (10 % - 20% )
• pentru asistenta la schimbari se poate aloca o rezerva
de 10%
• colectarea de date si pontaje ~ 2% din durata
proiectului
Considerente practice
• In practica unele estimarile sunt calculate ca
procent din durata proiectului:
– Elaborarea solutiei 15%
– Managementul solutiei: 20%
– Finalizare: 10%
• Redactarea de documente tehnice (de calitate
!!) poate presupune o rata de redactare de 1-3
pagini pe zi.
Rezerva
• Rezerva (contingency)
– Modalitate de a cuantifica neprevazutul
• Se poate adauga:
– La fiecare estimare de cost
– La fiecare categorie de cost
– La valoarea intregului proiect
• Poate fi exprimata
– Direct: in bugetul proiectului
– Indirect: inclusa in valoarea estimate a fiecarei cheltuieli
• Se foloseste doar daca bugetul proiectului nu permite exprimarea
directa
Exemplu de
buget
-Deviz cadru pentru
proiecte de cercetare din
programul PN3
CATEGORII DE CHELTUIELI (COSTURI)
1. Resurse umane
2. Participanţi
3. Alte tipuri de costuri, din care:
alte
3.1. Cheltuieli de tip FEDR ( max. 10% ptr. axele 1-5, sau max. 15%
pentru axa 6, din valoarea totala eligibila a proiectului - 0.15%
Exemplu de
4. Rezervă de contingenţă - maxim 5% din (1+2+3)
5. Total cheltuieli directe (1+2+3+4)
- 3.94%
buget
6. Total cheltuieli indirecte/cheltuieli generale de administraţie (proiecte
strategice: max. 5% pt.pers.juridice de drept public, sau max.7%
pt.pers.juridice de drept privat; proiecte de grant: max. 15% pt. toate
categoriile de beneficiari, din total cheltuieli directe, mai putin
cheltuielile de tip FEDR) - 3.95%
Exemplu buget
-Deviz cadru pentru proiecte de
6.1.Salarii
6.2.Alte costuri
cercetare din programul
6.3.Utilitati POSDRU
7. VALOAREA ELIGIBILĂ A PROIECTULUI ( 5+6 ), din care:
Contributie proprie
Barem CGA 5%
Diferenta necheltuita CGA

Exemplu de
buget
-Deviz cadru pentru proiecte
de cercetare din programul
POSCCE
Exemplu de
• - buget
-Deviz cadru pentru proiecte

de cercetare din programul
POSCCE – continuare
Exemplu de buget
Exemplu de buget
http://searchdatamanagement.techtarget.com/feature/IT-project-management-The-cost-estimating-process
Exemplu de buget
Tipuri de estimari
• Estimare grosiera
– In fazele initiale ale planificarii proiectului
– Se incadreaza intre -25% si +75% din valoarea reala
• Estimare de buget
– In faza de planificare
– Asociata, de obicei, cu metoda “top-down”
• Estimarea finala
– La finalul fazei de planificare
– Asociata, de obicei, cu metoda “bottom-up”
CONTROLUL COSTURILOR
Controlul costurilor
• Controlul financiar incepe odata cu finalizarea bugetului de
catre managerul de proiect si este realizat pe toata durata
proiectului, pana la finalizarea acestuia,
– accent pe inceputul si finalul fiecarei etape.
– datorita managementului schimbarilor si al riscului, pot aparea
modificari in bugetul proiectului atat dpdv financiar cat si al timpului.
• Majoritatea organizatiilor realizeaza controlul financiar la nivel
anual,
– exista proiecte in care este nevoie de un control lunar sau semestrial.
1. Autorizare
2. Colectarea costurilor si raportare a datelor
3. Analiza costurilor
4. Raportarea: client si de management
Colectarea costurilor si raportare a
datelor
• Colectarea costurilor are la baza documentele
contabile aferente cheltuielilor efectuate
• Aceste documente se pot considera documente
justificative ale efectuarii platii si se impart in:
– Documente care stau la baza efectuării plăţii
– Documente care atestă efectuarea plăţii
• In continuare sunt prezentate tipuri de
documente justificative conform Ghidului
Solicitantului pentru programul POS
Documente justificative
• Salarii şi asimilate acestora
– Documentul care stă la baza efectuării plăţii
• contract individual de muncă
• fişe de pontaj, fişele de post
• raport de activitate pentru experţii proiectului
• stat de salarii
– Documentul care atestă efectuarea plăţii
• ordin de plată, registru de casă ….;
• dispoziţia de plată (în cazul plăţilor în numerar);
• extras de cont
• Transport de persoane
• ordinul de deplasare
• Transport cu autoturismul personal
– bon fiscal de combustibil, cu înscrierea pe verso a numărului de
înmatriculare a autoturismului şi a persoanei care efectuează deplasarea,
inclusive CUI-ul firmei
– declaraţie privind consumul de carburant
• Transport cu autoturismul de serviciu
– foaia de parcurs
– bonuri fiscale de combustibil
– declaraţie privind consumul de carburant
• Transport cu avionul/trenul/navigaţie fluvială
– biletele/tichetele de călătorie
– factura
• Diurnă
• ordinul de deplasare, continând clar data şi ora
plecării/sosiri;
• Cazare
• Documentul care stă la baza efectuării plăţii
– factură de cazare cu menţionarea numelor tuturor persoanelor
cazate, a duratei cazării şi a tarifului perceput
• Materiale consumabile
• contract (daca este cazul)
• factură sau bon fiscal
• avizul de însoţire a mărfii
• nota de recepţie
• procesul verbal de predare-primire
• bonul de consum
• certificate de garantie
– Documentul care atesta efectuarea platii
• ordine de plată
• dispozitia de plata/chitanţa
• extras de cont
• Costul programat
– Budgeted cost for work scheduled (BCWS)
– este suma bugetata pentru volumul de lucru programat sa
fie realizat, intr-o anumită perioada de timp.
• Costul efectuat
– Budget cost for work performed (BCWP)
– este suma bugetata a costurilor realizate, intr-o perioada
de timp data.
• Cost real
– Actual cost for work performed (ACWP)
– este suma raportata ca fiind cheltuita
• Variatia de cost
– Cost variance (CV)
– CV = BCWP – ACWP
– Negativ = depasire de costuri
• Variatia planificata
– Schedule variance (SV)
– SV = BCWP – BCWS
– Negativ = in urma
• Exemplu
– BCWS = 2000 lei
– BCWP = 1200 lei
– ACWP = 1000 lei
MANAGEMENTUL ACHIZITIILOR
• Etape
– Planificarea achizitiilor
– Gestionarea achizitiilor
– Controlul achizitiilor
– Finalizarea achizitiilor
• Proiectele mici nu au nevoie de un
departament de achizitii pentru a realiza
achizitiile.
– managerul de proiect este responsabil cu
managementul achizitiilor in conformitate cu
bugetul proiectului.
• Proiectele mari au nevoie de departamente de
achizitii
– managementul achizitiilor
• Departamentul de achizitii
– Este responsabil de achizitia diferitelor produse, servicii si
facilitati in cadrul proiectului.
– Are rolul de a efectua achizitiile conform unui set de
proceduri bine stabilit.
• Proceduri interne
• Legislatie: legea achizitiilor publice
– Responsabilul de achizitii are rolul de a:
• monitoriza procesul de achizitie,
• asigura livrarea in timp util,
• Receptiona produsele
• transmite spre plata factura conform ofertei alese.
• Pentru a putea efectua o achizitie este necesar ca:
– Costul produsului / serviciului sa se regaseasca in bugetul
proiectului.
– Fondurile necesare achitarii valorii produsului / serviciului sa fie
disponibile (cash - flow)
– Produsul/ Serviciul sa fie disponibil pe piata,
– Cel mai mic pret sa fie identificat si selectat,
– Produsul sa poata fi furnizat la o data stabilita conform planului
de realizare,
• Achizitiile trebuie efectuate conform planului de realizare,
– nu mai devreme si nici mai tarziu pentru a nu mari costurile.
Planificarea achizitiilor
• Tipuri de achizitii:
Fara restrictii semnificative
– Achizitii din fonduri pivate
– Achizitii din fonduri publice
Principiile care stau la baza atribuirii contractelor de achiziţie
publică şi a organizării concursurilor de soluţii sunt:
a) nediscriminarea;
b) tratamentul egal; Legea achizitiilor
c) recunoaşterea reciprocă;
d) transparenţa; publice
e) proporţionalitatea;
f) asumarea răspunderii.
Legea achizitiilor publice, LEGE Nr. 98/2016
din 19 mai 2016 – actualizata 2019
• ART. 68 Procedurile de atribuire reglementate de prezenta lege, aplicabile pentru atribuirea
contractelor de achiziţie publică/acordurilor-cadru sau organizarea concursurilor de soluţii cu
o valoare estimate egală sau mai mare decât pragurile prevăzute la art. 7 alin. (5), sunt
următoarele:
• a) licitaţia deschisă;
• b) licitaţia restrânsă;
• c) negocierea competitivă;
• d) dialogul competitiv;
• e) parteneriatul pentru inovare;
• f) negocierea fără publicare prealabilă;
• g) concursul de soluţii;
• h) procedura de atribuire aplicabilă în cazul serviciilor sociale şi al altor servicii specifice;
• i) procedura simplificată.
Legea achizitiilor publice, LEGE Nr. 98/2016 http://anap.gov.ro/web/wp-
din 19 mai 2016 content/uploads/2016/05/L98_2016.pdf
Gestionarea achizitiilor
Legera achizitiilor publice prevede urmatoarele proceduri de atribuire:
– Licitatia deschisa
• «ART. 71 În cadrul procedurii de licitaţie deschisă orice operator economic are
dreptul de a depune ofertă în urma publicării unui anunţ de participare»
– Licitatia restransa
• « ART. 76 În cadrul procedurii de licitaţie restrânsă orice operator economic
are dreptul de a depune o solicitare de participare în urma publicării unui
anunţ de participare, urmând ca numai candidaţii care îndeplinesc criteriile de
calificare şi selecţie stabilite de autoritatea contractantă să aibă dreptul de a
depune oferta în etapa ulterioară. »
– Dialogul competitiv
• “ART. 86 În cadrul procedurii de dialog competitiv orice operator economic are
dreptul de a depune o solicitare de participare în urma publicării unui anunţ de
participare, urmând ca numai candidaţii care îndeplinesc criteriile de calificare
şi selecţie stabilite de autoritatea contractantă să aibă dreptul de a participa la
etapa de dialog, iar candidaţii rămaşi la sfârşitul etapei de dialog au dreptul de
a depune oferte finale.”
Legea achizitiilor publice, LEGE Nr. 98/2016 http://anap.gov.ro/web/wp-
din 19 mai 2016 content/uploads/2016/05/L98_2016.pdf
– Parteneriatul pentru inovare
• “ART. 95 … orice operator economic are dreptul de a depune o solicitare de
participare în urma publicării unui anunţ de participare, urmând ca numai
candidaţii care îndeplinesc criteriile de calificare şi selecţie stabilite de
autoritatea contractantă să aibă dreptul de a depune oferte iniţiale în etapa
ulterioară, pe baza cărora autoritatea contractantă va desfăşura negocieri în
vederea îmbunătăţirii acestora.”
– Negocierea fără publicare prealabilă
• “ART. 104 … dacă în cadrul unei proceduri de licitaţie deschisă ori licitaţie
restrânsă organizate pentru achiziţia produselor, serviciilor sau lucrărilor
respective nu a fost depusă nicio ofertă/solicitare de participare sau au fost
depuse numai oferte/solicitări de participare neconforme,… “
• “dacă lucrările, produsele sau serviciile pot fi furnizate numai de către un
anumit operator economic”
• “ca o măsură strict necesară, atunci când perioadele de aplicare a procedurilor
de licitaţie deschisă, licitaţie restrânsă sau negociere competitivă nu pot fi
respectate din motive de extremă urgenţă, determinate de evenimente
imprevizibile şi care nu se datorează sub nicio formă unei acţiuni sau inacţiuni
a autorităţii contractante”
http://www.licitatii.ro/ghid-achizitii-publice/
• Legera achizitiilor publice (continuare)
– Concursul de solutii
• “ART. 105 Concursul de soluţii poate fi organizat în una dintre următoarele
modalităţi: a) în cadrul unei proceduri de atribuire a unui contract de achiziţie
publică de servicii; b) ca o procedură de atribuire distinctă, cu premii sau plăţi
acordate participanţilor.”
– Procedura simplificată
• “ART. 113 (1) Autoritatea contractantă are dreptul de a aplica procedura
simplificată în condiţiile prevăzute la art. 7 alin. (2). (2) Procedura simplificată
se iniţiază prin publicarea”
– sistem dinamic de achiziţii - procesul de achiziţie organizat în
integralitate prin mijloace electronice şi deschis, pe întreaga sa
perioadă de valabilitate, oricărui operator economic care îndeplineşte
criteriile de calificare şi selecţie, pentru achiziţii de uz curent, ale căror
caracteristici general disponibile pe piaţă satisfac necesităţile
autorităţii contractante; - > acord-cadru
• Exemplu de cuprins pentru un formular de
atribuire:
– Sectiunea I - Instrucțiuni pentru ofertanți
– Sectiunea II - Caiet de sarcini
– Sectiunea III - Formulare
– Sectiunea IV- Model contract (orientativ)
Exemplu de cuprins pentru un formular de atribuire:
• Sectiunea I - Instrucțiuni pentru ofertanți

• Informații generale
• Obiectul contractului
• Legislația aplicată
• Cerințe minime de calificare
• Modul de elaborare și prezentare și depunere a ofertelor
• Evaluarea ofertelor
• Atribuirea și semnarea acordului-cadru
• Căi de atac
Exemplu de cuprins pentru un formular de atribuire:
• Sectiunea II - Caiet de sarcini

– Specificaţii tehnice
• Caracteristicile generale
• Descrierea produsului ( caracteristici minimale )
• Cantităţi
– Certificarea calităţii produselor
– Condiţii de recepţie si punerea in functiune
– Modul de livrare
MANAGEMENT DE RISC
Cuprins
 Managementul de risc
 Identificarea riscului
 Analiza riscurilor
 Raspunsul la risc
 Monitorizarea riscului
Managementul de risc
Definire
 Riscul este o măsură a
 probabilității
 consecinței neindeplinirii obiectivelor proiectului.
 Riscul are două componente principale pentru un

anumit eveniment:
o probabilitate de apariție a acestui eveniment
 impactul evenimentului respectiv
 Risc = f(probabilitate, impact)

Definire
▪ Riscul este un eveniment sau conditie posibila, care
in cazul aparitiei are un impact pozitiv sau negativ
asupra a cel putin un obiectiv al proiectului.
▪ Elemente ce pot fi afectate: timp, cost, scop, calitate

▪ Aparitia unei situatii de risc poate avea una sau
mai multe cauze
▪ Riscul implică noțiunea de incertitudine.

Definire
▪ Componente:
▪ Eveniment - ce se poate intampla in urma aparitiei unei situatii de risc
▪ Probabilitate – cat de des poate sa apara situatia de risc
▪ Impact – in ce masura este afectat proiectul
▪ Managementul riscului reprezinta “actiunea” sau

“practica” de a gestiona riscul.
▪ Daca un eveniment se poate produce cu probabilitate

de 100%, acesta devine o constrangere nu un risc
Probabilitate
mare Risc asociat mare
Risc asociat mediu
Risc asociat
Probabilitate mic
mica
Impact Impact
mic mare
 Managementul riscului include:

 planificarea pentru risc,
 evaluarea (identificarea si analizarea) riscurilor,
 dezvoltarea de strategii de actiune,
 monitorizarea riscurilor.
Proces asociat managementului de risc
Plan Impact Probabilitate
de risc Lista
Planificare de Prioritate
riscuri
Lista
Identificare ordonata
de riscuri
Analiza
Lista de
gestiune a
Raspuns riscurilor
Monitorizare
Rapoarte
de risc
 Planificarea riscului este:
 procesul de dezvoltare si documentare a unei strategii
organizate, cuprinzătoare, si interactive
 asociat cu metode pentru:
◼ identificarea si analizarea problemelor de risc,
◼ elaborarea planurilor de tratare a riscurilor,
◼ monitorizarea si analiza modului în care riscurile s-au
schimbat.
Componentele managementului de risc
 Evaluarea riscului este:

 procesul de identificare si analiza a sectiunilor din proiect si
procesului tehnologic pentru a creste probabilitatea de
atingere a costul ui, performanțelor, si obiectivele de
program.
 Identificarea riscurilor este:procesul de examinare a
sectiunilor din proiect si procesului tehnologic pentru a
identifica si documenta riscul asociat.
 Analiza riscului este procesul de examinare a fiecarei
probleme de risc identificate pentru a estima probabilitatea
unui risc si prezice impactul asupra proiectului.
 Raspunsul la risc este:
 procesul care identifică, evaluează, selectează si
implementează una sau mai multe strategii pentru a aduce
riscul la niveluri acceptabile având în vedere constrângerile
si obiectivele programului.
 implementat prin: descriere a ceea ce trebuie făcut,
momentul cand trebui să fie realizat, responsabilul, costul si
programul asociat.
 realizat prin strategia de raspuns ce cuprinde optiunile si
modelitatea de actiune.
 cacterizat de opțiunile de raspuns la risc ce includ:
prevenirea, evitarea, controlul (atenuare = “mitigation” )
si de transfer.
 Monitorizarea a riscului este:

 procesul care urmăreste sistematic si evaluează
performanțele acțiunii de manipulare a riscului în
funcție de măsurători stabilite de-a lungul procesului
 asociata cu actualizarea strategiilor de manipulare a
riscurilor.
Identifica
presupune un proces
continuu, desfasurat pe
toata durata Monitorizare Analizeaza
proiectului
Planifica
raspunsul
Identificarea riscului
Identificarea riscurilor
Tehnici de identificare
Orice sursă de informație care permite recunoasterea
unei probleme potențiale poate fi folosita pentru
identificarea riscurilor.
O serie de tehnici de identificare sunt prezentate in
continuare:
 Tehnici care adreseaza riscuri financiare
 Estimările de cost de referință
 Analiza de cost
 Analiza Earned Value
 Analiza costurilor asociate ciclului de viață
 Studii / analize comerciale
 Tehnici care adreseaza riscuri generale de proiect
 Analiza documentatiei / descrierii proiectului
 Planul / descompunere activitatilor / rezultatelor - WBS
 Analiza ipotezelor de lucru / presupunerilor
 Brainstorming
 Analiza bazata pe experienta proprie
 Liste de verificare / Liste de riscuri
 Modele de risc / Analiza de decizie
 Diagrame (de exemplu, diagrame de influenta)
 Analiza expertilor
 Lecții învățate
 Intalniri in echipa / Interviuri
 Analiza SWOT – strength, weakness, opportunities, threats
 Metoda Delphi – prin consens
 Tehnici care adreseaza riscuri tehnice
 Documentație de inginerie de sistem
 Măsurarea performanței tehnice (TPM)
 Planificare ciclului de viata al produsului / serviciului
 Analiza Tehnica
 Documentatie despre tehnologiiile utilizate

Clasificarea riscurilor
In continuare se vor prezenta o serie de clasificari ale
ricurilor intalnite in cadrul proiectelor
Clasificarea riscurilor din punct de vedere al strategie de
afaceri
 Riscuri de afaceri
 Riscuri ce pot fi asigurate:
 Daune directe asupra proprietatii

 Prierderi indirecte, cauzate de terte parti externe proiectului
 Juridice
 Resursa umana
 Clasificare conform “Project Management Institute” :
Externe Inprevizibile:
• reglementari legislative, forta majora, “acts of God”.
Externe Previzibile:
• dobanzi la credite, materiale disponibile.
Interne (Nontehnice):
• resursa umana, cash flow, siguranta, sanatate.
Tehnic
Performanta
Calitate
Risc financiar
Afaceri, organizatie, managemet
Riscuri externe proiectului

Clasificarea riscul de proiect în funcție de sursa
acesteia
 Scursa obiectiva
 Experienta documentata din alte proiecte realizate

 Lectii invatate
 Documentatie de evaluare a programelor
 Analiza date de performanta asociate proiectului
 Sursa subiectiva:
 Experienta a expertilor
 Interviuri realizate cu experti
 Clasificare a riscurilor conform Software
Engineering Institute’s (SEI) presupune o lista
structurata dupa clasa -> element -> atribut
 “Taxonomy Based Questionnaire (TBQ)”
 Clasificare:
Clasa
element element
atribut atribut atribut

SEI Risk Taxonomy Studiu de caz
Exemplu
 [144] Is the schedule realistic?
 (Yes) (144.a) Is the estimation method based on historical data?
 (Yes) (144.b) Has the method worked well in the past
 [17] Does any of the design depend on unrealistic or

optimistic assumptions?
 [7] Are you able to understand the requirements as written?

 (No) (7.a) Are the ambiguities being resolved satisfactorily?
 (Yes) (7.b) There are no ambiguities or problems of interpretation
Exemplu
Product Engineering
 Requirements  Testability  4. Integration and
 Stability  Hardware Test
 Completeness Constraints  Environment
 Clarity  Non-Development  Product
Software System
 Validity 
 3. Code and Unit 5. Engineering
 Feasibility Test

 Precedent Specialties
 Feasibility Maintainability
 Scale 
 Testing  Reliability
 2. Design  Coding /
 Functionality Implementation  Safety
 Difficulty  Security
 Interfaces  Human Factors
 Performance  Specifications
http://www.sersc.org/journals/IJSEIA/vol7_no1_2013/5.pdf
Exemplu - continuare
Development Environment
 Development  System Support  4. Management

Process  Deliverability Methods
 Formality  3. Management  Monitoring
 Suitability Process  Personnel
 Process Control  Planning Management
 Familiarity  Project  Quality Assurance
 Product Control Organization  Configuration
 Management Management
 2. Development
System Experience  5. Work Environment
 Capacity  Program Interfaces  Quality Attitude
 Suitability  Cooperation
 Usability  Communication
 Familiarity  Morale
 Reliability http://www.sersc.org/journals/IJSEIA/vol7_no1_2013/5.pdf
Studiu de caz
SEI Risk Taxonomy
Exemplu - continuare
Program Constraints
 1. Resources  3. Program Interfaces

 Schedule  Customer
 Staff  Associate Contractors
 Budget  Subcontractors
 Facilities  Prime Contractor
 2. Contract  Corporate Management
 Type of Contract  Vendors
 Restrictions  Politics
 Dependencies
http://www.sersc.org/journals/IJSEIA/vol7_no1_2013/5.pdf
Exemple de riscuri
 Riscuri tehnice:
 Schimbari de tehnologie
 Proiectare
 Performanta
 Riscuri legate de legislatie

 Licente
 Brevete
 Contractare
 Achizitie
The top 10 risks to a Project are:
Studiu de caz 1. Inadequate sponsorship
2. Poor / slow decision making
The top 10 risks to a Project are: 3. Poor / no scope definition
1. User involvement 4. Inadequate attention to
2. Executive support change management
3. Requirements inflation (or 5. Lack of co-operation
scope creep) between business areas /
4. Schedule flaws departments
5. Unrealistic expectations 6. Poor use of consultants
6. Staff turnover 7. Inappropriate resources
7. Project management 8. Unrealistic expectations
8. Specification breakdown 9. Inadequate knowledge
9. Technology and uncertainty transfer to your people
10. Not knowing what is at stake 10. Poor project management
http://www.vbhconsulting.com/Articles/Top%20 http://www.advantageinternational.com/
IT%20Project%20Risks%20and%20What%20t www/content/default.aspx?cid=670&fid
o%20do%20about%20them-3.pdf =725
Analiza riscurilor
Analiza riscurilor
Analiza riscurilor presupune asocierea unor elemente
de masura pentru probabilitate si impact
O scara de masura des utilizat are la baza 3 niveluri:

 Risc ridicat (High Risk):
 impact substantial asupra costurilor, performantei, si

programului.
 Atentia totala a echipei de management
 Necesita actiuni imediate

Analiza riscurilor
 Risc mediu (Medium Risk):
 impact mediu asupra costurilor, performantei, si
programului.
 Atentia echipei de management
 Risc scazut (Low Risk):

 impactminim asupra costurilor, performantei, si
programului.
 Nu necesita atentie deosebita a echipei de management
Metode de evaluare a riscurilor
 Matricea de risc
 Tabel de risc
 Analiza defectului
 Fault Tree Analysis (FTA)
 Failure Mode & Effect Analysis (FMEA)
Matrice de riscuri
Impact Categorie
Source: MIL-STD-882D
Catastrophic I
Critical II
Marginal III
Negligible IV
Probabilitate Level
Frequent A continuu
Probable B Frecventa mare
Occasional C Frecventa medie
Remote D Improbabil – dar
poate apare
Improbable E Improbabil – dar
posibil
Matricea de risc
Tabel risc - raspuns
Risc Probabilitate Impact Raspuns
R1. Membrii High Low Planificati necesarul de resurse in asa fel incat
echipei pleca sau sa tineti cont de evenimentul de risc.
se îmbolnăvesc Planificati rezerva
Analiza defectelor
 Se pot identifica doua tipuri de relatii:
 Inductiv
◼ Relatie eveniment consecinta / efect
 Deductiv
◼ Relatie eveniment cauza
E Cauza
Inductiv E Consecinta
Deductiv
Fault Tree Analysis
 FTA
 este o metoda analitica deductiva
 Scop: analiza de fiabilitate si siguranta
 utilizata pentru sisteme dinamice complexe
 Dezvoltata de
 Bell
Telephone in 1961
 modificata de Boeing
Fault Tree Analysis
 Structura a arborelui de defect
Eveniment
Poarta principal
logica
Eveniment
intermediar
Eveniment
de baza
Fault Tree Analysis
Secventa de activitati pentru realizarea diagramei
 Definire
 Definirea evenimentelor nedorite

 Definirea componetelor sistemului (scopul analizei)
 Definirea evenimentelor intermediare (granularitate)
 Definirea starii initiale ale sistemului
 Constructie diagrama
 Analiza
 Interpretare a rezultatelor
Fault Tree Analysis
 Blocuri utilizate
Eveniment
principal OR
Eveniment
nedefinit AND
Eveniment
de baza Transfer din
diagrama
Studiu de caz
Studiu de caz
Studiu de caz
Studiu de caz
Studiu de caz
Failure Mode and Effect Analysis
 FMEA
 Metoda inductiva folosita la nivel de componenta
 Defineste, identifica si elimina defectele, problemele si
erorile dintr-un sistem in faza de proiectare
 Metoda sistematica prin care se identifica modalitatile de
aparitie a defectelor
 Fiecare defect este evaluat din perspectiva

 Efect asupra sistemului
 Probabilitate de aparitie
 Impact
 Metoda de detectie
Failure Mode and Effect Analysis
 Secventa de activitati FMEA:
 Selectia sistemului sau procesului
 Selectia unei echipe de analiza
 Identificarea componentelor
 Identificarea cauzelor pentru defect
 Evaluarea cantitativa a fiecarei cauze
Component Failure Failure Failure Likelihood Likelihood Severity Risk Actions to

Mode Causes Effects of of Profile Reduce
Occurrence Detection Number Occurrence
(RPN) of Failure
Probabilistic Risk Assessment
 PRA
 Analiza a probabilitatii sau frecventei de aparitie a
unie consecinte a unui eveniment (sau alta consecinta) si
a impactului
 Metoda cantitativa de reprezentare a riscului
asociat
 Datele asociate metodei se obtin din analize
realizate folosind alte metode
1. Arbore de evenimente Stare finala

Eveniment B =𝐴∩𝐵∩𝐶
succes
= 𝐴 ∩ 𝐵 ∩ 𝐶ҧ
= 𝐴ҧ ∩ 𝐵ത ∩ 𝐶
Eveniment A
esec
= 𝐴ҧ ∩ 𝐵ത ∩ 𝐶ҧ
Eveniment B
Eveniment c
2. Diagrama de defecte -> FTA

http://www.nrc.gov/about-nrc/regulatory/risk-
informed/rpp/pra-tutorial.pdf
Arbore de decizie
Raspunsul la risc
Raspunsul la risc
 procesul care identifică, evaluează, selectează si
implementează una sau mai multe strategii pentru
a aduce riscul la niveluri acceptabile având în
vedere constrângerile si obiectivele programului.
 strategia de raspuns cuprinde
◼ Solutiipropuse: mecanism de tratare a impactului sau de
reducere a probabilitatii de aparitie
◼ prevenirea, evitarea, controlul si transferul.
◼ Modelitatea de actiune: momentul cand trebuie actionat,
responsabilul, costul si activitatile asociate
Raspunsul la risc
Metode de raspuns la situatii de risc:
 Asumare
 "Știucă există un risc și sunt constient de posibilele

consecințe. Sunt dispus să asteptăm si să vedem ce se
întâmplă. Accept riscul daca apare. “
 Evitare:
 "Nu voi accepta această opțiune din cauza rezultatelor
potențial nefavorabile. Se va modifica, fie arhitectura,
fie cerințe care conduc la problema. “
Raspunsul la risc
Metode de raspuns la situatii de risc (continuare):
 Control (mitigation):
 "Eu voi lua măsurile necesare pentru a controla acest

risc prin reevaluare continua și elaborarea unor planuri
de urgență sau alternative.”
 Transfer:
 "Voi împărtăsi acest risc cu ceilalți prin asigurare sau
garanție sau transfer al întregului risc. S-ar putea lua în
considerare, de asemenea, împărțirea riscului (
hardware și / sau software) folosind metode care
împart riscul. "
Raspunsul la risc
Metode de raspuns la situatii de risc (continuare):
 Impartire a riscului
 Riscul se poate imparti intre entitatile implicate

 Exploatarea (pozitiv)
 Incazul apatritiei unei oportunitati generate de un
eveniment de risc
Raspunsul la risc
Tehnici de evitare a riscului
 Tehnici de evitare a riscului
 Adăugarea de resurse
 Extinderea timpului alocat.
 Abordare cunoscuta vs inovatoare.
 Evitarea necunoscutului (echipa / subcontractor).
 Cerințe clare.
 Management al comunicarii
 Acces / analiza informații
 Expertiză externa.
 Domeniul de aplicare redus

Raspunsul la risc
Tehnici de control a riscului
 Tehnici de control a riscului
 Adoptarea de procese cu grad scazut de complexitate,
 Efectuarea unui numar extins de teste
 Alegerea un subcontractor mai stabil.
 Adăugarea de resurse
 Adăugarea de timp
 Dezvoltarea unui prototip (reduce riscul de nereusita

sau de scalare)
 Redundanța sistem
Monitorizarea riscului
 Metode de control al riscului tehnic:
 proiectare alternativa:
 evenimente demonstrative
 proiectare de experimente
 prototipare timpurie
 dezvoltarea incrementală:
 Control al parametrilor cheie
 screening de fabricație
 Metode de control al riscului tehnic (continuare):
 Verificarea procesului
 Review, walk-through, si inspectii:
 design robust
 Eforturile de maturare a tehnologiei:
 Testati-Analizati-Fixati (TAAF): TAAF Test-Analyze-and-

Fix
 Studii de piata:
 Metode de control al riscului tehnic (continuare):
 modelare / simulare:
 eforturile de dezvoltare multiple:
 “Open Systems”
 Utilizarea machetelor:
 Utilizarea de elemente standard / reutilizarea

software:
Managementul Comunicarii
Curs
CUPRINS
• Managementul comunicarii
• Identificarea partilor interesate
• Realizarea Planului de comunicare
• Implementarea Planului de comunicare si
Managementul comunicarii
• Managementul performantelor comunicarii
MANAGEMENTUL COMUNICARII
Comunicarea
in cadrul proiectului
- Reprezinta procesul de generare, colectare,
distribuire, depozitare si furnizare de informatii in
cadrul unui proiect.
- Comunicarea cu membrii echipei si celelalte parti
implicate (stakeholder) reprezinta o prioritate pentru
managerul si echipa de management a unui proiect.
- Comunicarea eficienta creaza o legatura de colaborare
intre partile implicate (stakeholder), indiferent de
cultura, expertiza, experienta sau interese.
❑ include toate procesele necesare pentru a
colecta, genera, disemina, inmagazina si livra
informatiile in cadrul unui proiect
❑ necesita o planificare a comunicarii
❑ procesul de determinare a informatiilor si cerintelor de
comunicare ale stakeholder-ilor.
❑ stabilirea unor legaturi de comunicare adecvate
❑ crearea unui plan de management al comunicarii
❑ crearea unei strategii de comunicare, a unui set de
principii, valori si obiective pentru a asigura coerenta
planului de comunicare
5
Etapele Managementului Comunicarii
• Identificarea partilor interesate ( categorii stakeholder )

1
• Realizarea Planului de comunicare

2
• Implementarea Planului de comunicare

3
• Managementul comunicarii cu categoriile stakeholder

4
• Managementul performantelor comunicarii

5
Tipuri de comunicare in
cadrul unui proiect
Interna (in cadrul proiectului) si externa (clientii, alte
proiecte, presa, publicul)
Formala (rapoarte, memo) si informala (e-mail, intalniri ad-

hoc)
Verticala (in cadrul organizatiei) si orizontala (de tip peer-to-

peer)
Oficiala (rapoarte oficiale, newsletter) si neoficiala
Scrisa, verbala si non-verbala (limbajul trupului, vizuala, …)

Abilitati necesare pentru
comunicarea eficienta
• Sa asculti
• Sa pui intrebarile potrivite
• Sa intelegi mesajul transmis
• Sa identifici si sa extragi informatia de care ai nevoie
• Sa convingi
• Sa negociezi ( in asa fel incat interlocutorii sa fie
multumiti )
• Sa rezolvi conflictele
• Sa identifici pasii urmatori
• Sa ai o atitudine proactiva
IDENTIFICAREA PARTILOR INTERESATE
(CATEGORII STAKEHOLDER )
Identificarea
categoriilor stakeholder
• Este necesara identificarea
– categoriilor stakeholder inca de la inceputul
proiectului
– necesitatilor, intereselor, asteptarilor, importantei si
influentei fiecarei categorii implicate in procesul
comunicarii
• Strategia de abordare
– determina nivelul de implicare al categoriilor
stakeholder
– trebuie revizuita periodic datorita schimbarilor ce pot
interveni
Identificarea
categoriilor Stakeholder
Pas 1
Identificare Pas 2
Schita de proiect Analiza
Pas 3
Planul de proiect Planificare
Analiza categoriilor
Plan de comunicare stakeholder
intern al organizatiei Lista categoriilor
Consultarea stakeholder
Plan de comunicare expertilor in
extern al organizatiei comunicare Lista necesitatilor de
comunicare pentru
fiecare categorie
stakeholder
Identificarea
- Reprezinta procesul de colectare si
analiza a informatiilor calitative si
cantitative pentru a determina
interesele, asteptarile si influenta
acestora.
- Pasul 1: Identificarea categoriilor

stakeholder, rolul acestora precum si
nivelul de cunostinte.
- Pasul 2: Analiza impactului pe care

acestia il pot genera
- Pasul 3: Atribuirea de roluri in functie de

rezultatul analizei
Identificarea
• Principalele grupuri de audienta:
▪ echipa de proiect si alti participanti la proiect
▪ echipa de management
▪ beneficiarii, utilizatorii finali
▪ finantatorul
▪ audienta externa: (ex :clienti, furnizori, partneri, organisme
de reglementare, etc.)
• In fiecare grup de audienta exista numeroase

subgrupuri cu nevoi diferite .
REALIZAREA
PLANULUI DE COMUNICARE
Planul de comunicare
- Reprezinta procesul de determinare a informatiilor
necesare si identificarea unei abordari de comunicare
in functie de necesitatile categoriilor stakeholder;
- Cine ?
- Ce informatie foloseste ?
- Cum se transmite ?
- Cand o foloseste ?
- Cum o foloseste ?
- Identificarea informatiei si comunicarea ei intr-un mod

util reprezinta un factor important in succesul unui
proiect.
- Comunicarea defectuoasa reprezinta un risc
major in implementarea proiectului.
- Comunicatia eficienta este facilitata prin
furnizarea stricta a informatiei necesare.
- Planul de comunicare trebuie inceput inca din
faza incipienta a proiectului – schita de proiect, si
dezvoltat odata cu planului de proiect.
- Realizarea planului de comunicare presupune
alocarea de resurse, timp, buget.
Strategii de Comunicare
▪ Comunicarea informatiilor se face in timpul cel
mai scurt (posibil)
▪ Comunicarea va fi axata pe categoriile stakeholder
▪ In cazul etapei de implementare se pune accent pe
comunicarea “fata-in-fata”
▪ Inchiderea buclei (feedback) este necesara pentru
a clarifica nelamuririle si a evalua impactul
comunicarii
▪ Exprima opiniei fara a-si compromite pozitia sau
cariera
Strategii de Comunicare
▪ Mesaje comunicate trebuie sa fie clare si simple
▪ Furnizarea informatiilor necesare pentru
implementarea proiectului si nu a altor
informatii inutile sau redundante
▪ Folosirea mangementului de risc pentru a educa
si implica categoriile stakeholder
▪ Consultarea categoriilor stakeholder in procesul
de decizie
▪ Incurajarea echipei in a pune intrebari
Cerinte de comunicare
Cei 5Ws (Why, What, When, Where, Who) si 1H (How)
https://www.randallreilly.com/the-5-ws-of-digital-marketing/
• Identificarea factorilor organizationali
– Cultura, organizare, metodologie de MP,
infrastructura, resurse umane, procedure, risc …
• Identificarea proceselor in cadrul organizatiei:
– Financiar, vanzari, MP …
• Identificarea obstacolelor in comunicare
https://www.pmi.org/learning/library/effective-communication-better-project-management-6480
• Analiza cerintelor de comunicare implica:
– Categoriile stakeholder
– Informatiile ce se vor comunica
– Formatulfolosit pentru structurarea informatiilor
• Comunicatia de face prin intermediul canalelor de
comunicatie existente
– determina complexitatea comunicatiilor in cadrul unui
proiect.
• Numarul total de canale de comunicatii este
n(n-1)/2
, unde n reprezinta numarul de stakeholderi implicati.
Selectia Expertilor
• Se identifica expertii in comunicare fie din
cadrul companiei fie din exterior
• Se creaza un grup de consultare ce poate
include:
- Experi in comunicare
- Echipa de management
- Reprezentati ai partenerilor de proiect
- Departamente din cadrul organizatiei
(contabilitate, juridic, resurse umane …)
- Categorii stakeholder cheie
- Manageri cu experienta in proiecte similare
Pas 1
Identificare
documente
Pas 2
Analiza metode
Registrul stakeholderilor Pas 3
Analiza cerintelor de Realizare
Strategia de
comunicare
management a
stakeholderilor
Tehnologia de
comunicare Planul de management
Procese de comunicare
organizationale al comunicarii
Metode si Modele de
comunicare Modificarile ale planului
proiectului
Metode de comunicare
Factorii care pot afecta proiectul:
- Urgenta asociata transmiterii informatiilor
- Disponibilitatea tehnologiilor de transmitere a informatiilor
- Durata proiectului
- Mediul de lucru
Modele de comunicare
• Comunicare interactiva
– schimb de informatii multidirectional
• Comunicare de tip push
– destinata celor care doresc sa obtina informatiile - scrisori, memo,
email, fax, voice mails, presa
• Comunicare de tip pull
– audienta la scara larga, volume mari de informatii - intranet, e-
learning, depozite de cunostinte
Modele de comunicare
1. Modelul Shannon and Weaver
1 Expeditor
Destinatar 5
3
2 Mesaj
Dispozitiv
codare Dispozitiv
decodare
Perturbatii
Dispozitiv 4
decodare
6 Feedback
Dispozitiv
decodare
Ref 1 Canal de comunicatii

1. Modelul Shannon and Weaver
• Comunicarea presupune:
– Un expeditor
– O metoda de codare
– Un mesaj
– O metoda de decodare
– Un destinatar
+ perturbatii
+ feedback
• Ex: un e-mail poate fi citit doar daca avem acces
la o aplicatie
2. Cei 7 C din Comunicatii
• 1. Clar (Clarity)
• 2. Credibil (Credibility)
• 3. Continut (Content)
• 4. Context
• 5. Continuitate (Continuity)
• 6. Capabilitate (Capability)
• 7. Canal de comunicatie (Channels)
3. Efectul Hawthorne
• Studiile originale care au dat naștere efectului Hawthorne au fost
întreprinse la fabrica electrică de telefonie Western Electric de la
Hawthorne, în apropiere de Chicago, între 1924 și 1933.
• Creșteri ale productivității au fost observate la un grup selectat de
lucrători care au fost supusi la diverse modificări ale mediului lor,
cum ar fi orele de lucru, nivelurile de iluminare și timpii de pauză.
• S-a constatat că nivelul de lumină nu a făcut nicio diferență în
productivitate, creșterea productivitatii fiind legata de schimbarile
produse de la un nivel scăzut la un nivel ridicat,
• S-a observat că acest efect a avut loc atunci când orice variabilă a
fost modificata și aceasta modificare a contribuit la schimbarea
comportamentului.
• Concluzie: productivitatea a crescut pentru că angajatii erau
conștienți că erau sub observație sau li se acorda atentie
• 4. Teoria difuziei
• Oamenii – creature ale obișnuinței.
– Ființelor umane nu le place schimbarea.
• Există cinci etape în cadrul procesului de difuzie:
– 1. Conștientizare - Individul este conștient de „ea”.
– 2. Interes - vrea să învețe mai multe.
– 3. Evaluare - solicită altora feedback.
– 4. Trial - Utilizează un eșantion etc.
– 5. Adopție - Acum un utilizator / credincios.
Decision process innovation (Rogers, 1983, p. 165).
• In cazul comunicatiei verbale este important:
– Tonul vocii si inflexiunile
– Feedback referitor la conversatie
– Ascultarea participativa
– Intelegerea
– Comunicatia nonverbala - gesturile
Communication Methods
• Project Workbook
• Face-to-face meetings Metode de comunicare
• Audio-, Video, and Data-Conferencing in interiorul proiectului
• Via the Internet
• Seminars and Workshops
• Project Newsletters
• Status Reports
• Specification Documents
• Minutes of Meetings
• Bulletin Boards
Studiu de caz
• Memos
• Brown-Bag Lunches
• Hallway Discussions
Canal de comunicare: Faţă în faţă
Verbal
• Conversatia informala - mod de a a masura reactia

• “Zvonurile bune se raspandesc repede”
Intalniri
• Scop si durata bine definite

• Plan al intalnirii bine definit - agenda
Workshops
• Schimb liber de idei.

• Se poate lucra in mod colaborativ.
Canal de comunicare: Faţă în faţă
Cursurile de instruire
• Informatii detaliate , audienta cu nevoi specifice,

• Interactiv si va permite evaluarea gradului de succes.
Evenimente
• Realizate pentru a obtine o mare audienta.

• Mesajul trebuie realizat si transmis in colaborare cu experti in comunicare.
Evenimente sociale
• Realizate pentru dezvoltarea spiritului de echipa

• Pot fi folosite pentru a transmite mesaje.
Canal de comunicare: Electronic
Email
• Cel mai simplu mod de comunicare. Grupuri care primeasc mesaje tematice.
• Problema: multi oameni nu au timp sa citeasca tot sau ignora mesajele
• Un mesaj transmis de un superior este citit. -> mesaje importante
Portal web
• Ofera detalii despre proiect

• Un mijloc de comunicare cu cei interesati (feedback, forum, blog)
• Poate exista individual sau integrat in portalul organizatiei
Sisteme colaborative
• Continut: Enterprise Content Management System, baze de cunostinte, server de doc.

• Platforme colaborative: voce/video/share: Skype, Google Talk, Docs, TeamSpeak, …….
Canal de comunicare: Electronic
Video
• Un clip video bine realizat va avea un impact puternic.

• Necesita timp si costuri ridicate pentru o calitate buna
• Publicul tinta trebuie convins sa le vizioneze.
CD-DVD
• Pot contine mesaje video, demonstratii sau informaţii generale.

• Distribuţia şi utilizarea se fac cu respectarea drepturilor de copyright
• Grupul tinta are acces la calculatoare configurate corespunzator
Stream Video
• Caracteristici similare cu un clip video dar poate fi vizionat mult mai usor
• Probleme: largime de banda corespunzatoare , software specializat.
Canal de comunicare: Publicatii
Ziarul companiei/ buletinul informativ
• Mesaje generale pot fi distribuite in suportul media de stiri al companiei.

• Nu este un mijloc bun pentru informatii detaliate daca nu sunt relevante pentru cititori.
• Pot fi folosite si pentru recunoasterea meritelor sau ca un stimulent,
Presa, reviste specializate, communicate de presa
• Poate fi necesara anuntarea unor evenimente catre clienti, furnizori, investitori sau
grupul tinta.
• Comunicatiile externe trebuie realizate impreuna cu departamenteul de marketing sau
cel de comunicare (PR)
Anunturi, Pliante , Postere
• Pliantele si posterele sunt materiale folosite pe scara larga pentru diseminare

• Sunt materiale relevante in cadrul unor evenimente, conferinte, targuri ….
Canal de comunicare: Publicatii
Cadouri promotionale
• Diferite tipuri de “cadouri promotionale” pot fi folosite sa promoveze proiectul si/sau sa

transmita informatii specifice.
• De exemplu: tricouri, pixuri, stilouri, stick memorie etc Valoare mica – impact mare
Scrisori
• Cel mai sigur mod de a atrage atentia unei persoane este scrisoarea personalizata
• Efectul este mai puternic daca scrisoarea este semnata de un superior.
• Doar pentru mesaje foarte importante altfel valoarea adaugata va scadea iar grupul
tinta ar putea fi iritat.
Manuale, documentatie de procedura
• Manuale detaliate, ghiduri de utilizare, liste ... sunt necesare in majoritatea aplicatiilor.
• Utile in format electronic
• Comunicarea activa:
– Face to Face (fata in fata)
– Video conference (video -conferinta)
– Telephone conference (tele -conferinta)
– Webinars (seminar folosind platforme web)
– Telefon
– Stand Up presentations (prezentare)
• Comunicarea pasiva: A webcast is a media presentation
distributed over the Internet using
– Pod cast streaming media technology to
distribute a single content source to
– Web cast many simultaneous
listeners/viewers.
– Email
– Intranet bulletin boards A podcast is a digital medium
consisting of an episodic series
– Blog of audio, digital radio, PDF, or
ePub files subscribed to and
– Website downloaded through web
syndication or streamed online
– Project Newsletter - paper based to a computer or mobile device.
– Table top presentation

Realizarea
Planului de Comunicare
• Cerinte minimale pentru redactarea planului de
comunicare:
▪ Cerintele de comunicare si asteptarile legate de proiect
▪ Cum si in ce format este comunicata informatia
▪ Cand si unde se realizeaza fiecare comunicatie
▪ Cine este responsabil pentru furnizarea fiecarui tip de
comunicatie
Continutul documentului
Continutul minimal al planului de comunicare:
1• Identificare actori:
– Categoriile stakeholder
– Cerintele de comunicare ale categoriilor
stakeholder
2• Scopul comunicarii
– Informatiile necesare pentru comunicare (format,
limba, continut, nivelul de detaliu)
– Motivele pentru distribuirea informatiilor
Continutul documentului 2
3• Planificarea comunicarii
– Timpul asociat si perioada de distribuire a
informatiilor
– Persoana responsabila pentru comunicare
– Persoana responsabila pentru autorizarea
transmiterii materialelor
– Persoanele sau grupurile care vor primi informatia
– Resursele alocate, incluzand timpul si bugetul
Continutul documentului
4• Metode de comunicare
– Metodele si tehnologiile folosite pentru schimbul
de informatii
– Restrictiile de comunicare
5• Managementul schimbarii
– Metodele de modificare a planului de comunicare
Matricea de comunicare
Exemplu 1 – matrice individuala
Exemplu 2 – matrice de comunicare pentru intalniri de proiect

Lista de activitati de comunicare
http://www.interreg4c.eu/uploads/media/pdf/resources_Project_Communication_Guide.pdf
Exemplu 3 – matrice de comunicare pentru rapoarte
Report Description Frequency Owner Internal/ Comments/

Name Purpose External Distribution List
< Report <Communication <Weekly> <Joe Smith> <Internal> <comments>
Name> of project progress
and deliverable
status>
Plan de comunicare
Exemplu
http://www.imi-protect.eu/documents/PROTECTCommunicationStrategyandPlan.pdf
Plan de comunicare
Exemplu
Plan de comunicare
Exemplu
http://www.projectmanagementdocs.com/template/Communications-Management-Plan.pdf
IMPLEMENTAREA PLANULUI DE
COMUNICARE
MANAGEMENTUL COMUNICARII
Implementarea
Planului de comunicare
• Modalitati de comunicare in timpul proiectului:
– Notificarea categoriilor stakeholder
– Feedback-ul primit de la stakeholder
– Rapoarte de proiect
– Rapoarte de progres (individuale sau de echipa)
– Proces verbal, minuta a intalnirilor
– Prezentari de proiect
– Inregistrari video, audio legate de proiect
– Documentatie pe baza lectiilor invatate
Implementarea
Planului de comunicare
Pas 1
Identificare
Planul de management Pas 2

al comunicarii Implementare
Raportarea
performantelor Metodele de Pas 3
distribuire a Actualizare
Procesele informatiei
organizationale
Metode si Modele de
comunicare
Modificarile din
documentul
proiectului
Comunicarea
pe parcursul proiectului
• Modele furnizor-client definite
in planul de comunicare:
– feedback, bariere de
comunicare
• Tehnici de facilitare
– depasirea obstacolelor
• Mediu de comunicare utilizat
(media):
– transmitere orala sau in scris
– face-to-face versus e-mail Ref 2
Comunicarea
• Stilul de scris
– ton activ sau pasiv, structura
propozitiilor, alegerea
cuvintelor
• Tehnici de management al
intalnirilor
– stabilirea unei agende de
intalniri, conducerea intalnirii
• Tehnici de prezentare
– limbajul trupului, aspectul fizic Ref 3
Comunicarea
• Comunicarea trebuie gestionata in mod proactiv pe
parcursul proiectului.
• Fiecare organizatie poate sa aleaga metode preferate
de comunicare.
• Se vor respecta cerintele legale sau practice pentru:
– discriminare,
– accesul persoanelor cu handicap
– confidentialitatea / protectia datelor,
– drepturi de autor
– limbi straine,
– legislatia muncii
Comunicarea
• Succesul comunicarii trebuie evaluat .
– Se evalueaza cat din informatia transmisa a fost
perceputa.
– Activitatile necesare pentru remediere.
– interventie imediata,
– actualizarea Planului de Comunicare pentru
etapele urmatoare.
Comunicarea
la finalul proiectului
• In mod generic, comunicarea se afla intr-un punct
maxim la finalul proiectului.
• Efortul aferent Managementului Schimbarii

Organizationale se afla tot intr-un punct de
maxim.
• Comunicarea va fi necesara si dupa finalizarea

proiectului, pe o perioada variabila de timp
MANAGEMENTUL
PERFORMANTELOR COMUNICARII
Managementul
performantelor comunicarii
• Reprezinta procesul de colectare, analiza si
distribuire a informatiilor legate de
comunicare proiectului dpdv al
performantelor.
• Procesul de raportare implica:

– colectarea periodica de informatii
– analiza informatiilor colectate
Managementul
performantelor comunicarii
Pas 1
Identificare
Planul de management Pas 2
al comunicarii Analiza / Procesare
Pas 3
Implementare
Achizitia datelor legate
Sisteme de raportare
de performanta
Analiza variantei
Masurarea Raportarea
performantelor performantelor
Metode de predictie
Bugetului Management al
Metode si Modele de
comunicare schimbarii
Performantele comunicarii
Metode utilizate
• Analiza Variantei
– Se refera la diferentele intre performantele
initiale (planificate) si cele actuale (realizate).
– Diferentele apar in urma:
• verificarii calitatii informatiei colectate,
• determinarea modificarilor aparute in schimbul de
informatii in raport cu planul initial
• determinarea impactului modificarilor asupra
proiectului
Performantele comunicarii
Metode
• Metode bazate pe expertiza
- metoda Delphi, predictia prin analogie
• Sisteme de raportare
- pachete software
- modele de documente de raportare
Managementul
performantelor - Rezultat
• Un raport complet privind performantele va
include:
- analiza performantelor anterioare
- stadiul actual al riscurilor
- munca efectuata
- munca ce va fi depusa in viitor
- schimbarile aparute
- rezultatele analizei variantei
- predictiile efectuate (incluzand timpul si costul)
Referinte
• Referinte imagini
1. FreeDigitalPhotos.net, ddpavumba, published on 14 May 2012
Stock Image - image ID: 10083023
2. FreeDigitalPhotos.net, ddpavumba, published on 27 September 2013
3. FreeDigitalPhotos.net, sheelamohan, published on 20 January 2012
Management de Calitate
Curs 11
Cuprins
▪Managementul calităţii
▪Planificarea calităţii
▪Asigurarea calităţii
▪Controlul calităţii
▪Auditul de calitate
2
Managementul calităţii
3
Definirea calitatii
• In “Joseph M. Juran, Quality Handbook, 5th edition”, calitatea se

definește ca:
• “freedom from deficiencies.”
• “Project Management Institute” si ISO 9000:2000, definesc

calitatea ca:
• “the degree to which a set of inherent characteristics fulfill
requirements.”
• gradul in care un set de caracteristici inerente indeplineste
cerintele
Definirea calitatii Stakeholder
Nevoi
• International Organization for Standardization Dorinte
(ISO), Quality Management and Quality Assurance Asteptari
• “the totality of characteristics of an entity that

bear on its ability to satisfy stated or implied
needs.”
Analiza
▪ Calitatea este totalitatea particularitatilor şi
caracteristicilor unui produs sau serviciu care determina
capacitatea acestuia de a satisface nevoile declarate
sau implicite ale utilizatorului.
Cerinte
proiect
Definirea calitatii
Obiective ale programelor de calitate pot fi:

- “Fitness” pentru utilizare. (Poate fi utilizat produsul sau serviciul?)
- “Fitness” pentru scop. (Produsul sau serviciul realizat indeplineste
scopul prevazut?)
- Satisfactia clientului. (Produsul sau serviciul realizat satisface asteptarile
clientului?)
- Conformitatea cu cerintele. (Podusul sau serviciul respecta cerintele?)
Managementul calitatii
• Este gresit sa presupunem ca in cadrul implementarii unui proiect se

doreste obtinerea unui nivel de calitate absolut.
• Nivelul de calitatea ar trebui sa fie considerata ca parte din:

• activitatea de definire a proiectului
• strategia (de afaceri) organizatiei Calitatea nu este o
• Nivelul de calitate este decis, in general, de:
cerinta absoluta !
• sponsorul proiectului
• echipa de conducere a organizatiei
• Deciziile in privinta calitatii nu sunt doar o problema a produsului final- ele pot
afecta scopul si abordarea proiectului.
▪ Vrei ceva extraordinar sau ceva rapid, inaintea competitorilor?
▪ Vrei o solutie completa sau te multumesti cu o solutie partiala si revii
sa o termini ulterior?
TIMP
Triunghiul calitatii
Alternativele se exclud reciproc –
nu poti realiza ceva extraordinar, COMPROMIS
complet, ieftin si rapid.
COST CALITATE
Calitatea poate fi abordata din urmatoarele perspective:

• Produs
• Defecte
• Proces
• Stakeholder
• Sistem
Definirea Managementului de
Calitate al proiectului
Managementul de calitate al proiectului include toate
activitatile desfasurate de companie, politicile de calitate,
obiectivele si responsabilitatile astfel incat proiectul sa
satisfaca nevoilele pentru care a fost intreprins.
Implementarea managementului de calitate:

• prin politicile, procedurile si procesele de planificare,
asigurare si control al calitatii
•prin activitati de imbunatatire a calitatii desfasurate pe
parcursul proiectului.
10
Obtinerea calitatii
• Calitatea poate fi dobandita atunci cand:

▪ este realizat si implementat un sistem de management al calitatii
proiectului care include procese de:
▪ planificarea calitatii
▪ asigurarea calitatii
▪ controlul calitatii
• Aspecte importante:
▪ Cerintele clientilor sunt gestionate si gradul de indeplinire masurat
▪ Sunt realizate periodic evaluari de proiect
Procesele
Managementului Calitatii proiectului
▪Planificarea calitatii – Este un proces de identificare a standerdelor de calitate

relevante pentru proiect si determinarea modului in care vor fi indeplinite
▪Asigurarea calitatii (Quality Assurance QA) – Este procesul de efectuare a

activitatilor planificate, sistematice de calitate pentru a se asigura ca proiectul
utilizeaza toate procesele necesare pentru a indeplini cerintele.
▪Controlul calitatii (Quality Control QC) – Este procesul de monitorizare a

rezultatelor specifice ale proiectului pentru a determina daca respecta
standarde importante de calitate si identifica moduri pentru a elimina cauzele
performantelor nesatisfacatoare
Procesele
▪ Planificarea calitatii este un proces cheie in dezvoltarea
planului de management de proiect si ar trebui realizat in
paralel cu alte procese de planificare din proiect
▪ Asigurarea calitatii ofera o baza pentru o alta activitate

importanta a calitatii, procesul de imbunatatirea continua
▪ Controlul calitatii se desfasoara pe toata durata proiectul

impreuna cu standardele de calitate care includ procesele
proiectului si obiectivele produsului.
Procesele
Planificare Executie Finalizare
Control de
Plan de calitate P Asigurare C
calitate
Componente ale Managementului
Calitatii
Componente Descriere
Plan de Calitate Definirea si stabilirea nevoilor pentru calitate si abordarile specifice pentru a
le indeplini
Cerinte de calitate Actiuni specifice ce se vor realiza
pentru fiecare etapa Livrabilele ce vor rezulta
Aplicarea metodelor Pe parcursul activitatii va fi urmarita abordarea de calitate planificata.
de calitate
Evaluarea calitatii Inainte de finalizarea unei etape,
pentru fiecare etapa Evaluare pentru a determina daca standardele de calitate au fost atinse.
Evaluarea calitatii Inainte de finalizarea proiectului
proiectului Evaluare si aprobare a conformitatii rezultatului cu cerintele de calitate
definite
Responsabili pentru calitate
• Managerul de Project isi asuma intreaga responsabilitate

pentru calitatea proiectului.
• Se poate delega Managementul de Calitate catre un
Responsabil de calitate
• Toti participantii au un rol in obinerea rezultatelor.
• Dezvoltarea unei culturi a calitatii in echipa.
• Daca trebuie facuta o alegere intre calitate si progresul
proiectului ar trebui sa fie o decizie de afacere.
Responsabilitati pentru calitate
• Personal implicat in procesul de management al calitatii:

• Manager de calitate
• Echipa de calitate
• Lideri de echipa
• Evaluarea Managementului Calitatii va fi realizate de analisti
independenti din afara echipei de proiect.
Responsibilitatile pentru calitate trebuie stabilite si

comunicate tuturor participantilor la proiect.
Planificarea calităţii
18
Planul de Management al Calitatii
• Planificarea calitatii este un concept larg, acoperind multe

aspecte legate de realizarea calitatii.
• Planul de Managementul Calitatii
• – descrie modul in care echipa de management a proiectului
implementeaza politica de calitate a organizatiei
▪ Ofera date pentru intreg planul de management al proiectului si
trebuie sa adreseze si controlul calitatii (QC), asigurarea
calitatii (QA), si procesul de imbunatatire continua
▪ Trebuie sa includa toate aspectele calitatii pentru a asigura baza
pentru deciziile legate de calitate ce vor fi luate in timpul
implementarii proiectului.
Obiectivele Planificarii Calitatii
▪ Identifica strandardele de calitate relevante proiectului si determina cum

vor fi indeplinite
▪ Intocmeste un document: planul de management al calitatii care:
▪ Descrie cum va fi implementata politica de calitate si sistemul de
calitate al proiectului
▪ Ofera considerentele de calitate pentru intreg planul de proiect
▪ Adreseaza controlul calitatii, asigurarea calitatii, si imbunatatirea
calitatii proiectului
▪ Defineste indicatori relevanti pentru calitate ce vor fi evaluati in etapele
controluli calitatii si metode de evaluare. (Controlul Calitatii)
▪ Dezvolta liste de control pentru a verifica ca un set de etape de
calitate au fost efectuat. (Asigurarea Calitatii)
Continut Descriere
Obiective Care sunt obiectivele?
In ce masura este calitatea o cerinta preferata in detrimentul costului,
functionalitatii etc?
Cerinte Cerinte specifice care vor fi adresate
Metode de Calitate Abordari si metode
Standarde Standarde folosite.

Formatul si gradul de detaliere a livrabilelor
Proceduri Proceduri specifice pentru sarcinile din proiect
Planul de Managementul Calitatii este adesea un document dinamic.

Odata cu progresul proiectului va fi necesara actualizarea cu decizii de
calitate si schimbari.
• Componentele planului de calitate depind de particularitatile proiectului:

❑ echipa de implementare
❑ tehnologiile folosite
❑ cultura organizationala
❑ politicile de caliatate
❑ clientii
❑ cultura locala
• Componentele planului de calitate vor fi infuentate de decizii

strategice legate de investitia in calitate.
Planul de Management al Calitatii are ca puncte de pornire:

1 • activitatile ce urmeaza a fi intreprinse
• pentru fiecare activitate se asociaza:
• metode, tehnici si proceduri de asigurare a calitatii
• standardele de calitate
• dependentele
• datele initiale necesare desfsurarii
• Aceasta abordare ofera:

• un ghid pentru echipa de implementare
2 • livrabilele ce urmeaza a fi obtinute

• pentru acestea se asociaza:
• formate si standarde de prezentare
• natura, descrierea si scopul livrabilelor,
• autorul / dezvoltatorul livrabilelor,
• evaluator al calitatii livrabilelor
• persoana care va aproba livrabilele,
• permisiuni atasate livrabilelor si cerinte de securitate
• Aceasta abordare ofera:

• o lista de verificare pentru evaluarea de la finalul etapei
Componente ale planului de calitate
• Specificații ale rezultatului

• Standarde asumate
• Metrici pentru evaluarea indeplinirii specificațiilor
• Metrici pentru evaluarea indeplinirii standardelor
• Autorizarea etapelor proiectului
• Instrumente și tehnici pentru asigurarea calitatii
• Instrumente și tehnici pentru controlul calitatii
• Activități de asigurare si control al calitatii
Model de cuprins
• Introduction • Quality Assurance
• Quality Objectives • Project Processes
• Quality Management Approach • Process Quality standards
• Quality Control • Quality Assurance Activities
• Project deliverables • Roles and responsibilities
• Deliverable Quality Standards • Tools
• Quality Control Activities • Reporting
Ref: http://www.project-next.eu/en/
Proceduri de calitate
• sunt seturi de reguli create pentru a fi urmarite de catre
echipa de implementare
• in cadrul planului de calitate se asociaza sau se definesc
proceduride calitate (de ex. controlul documentatiei,
managementul configuratiilor, proceduri de testare).
• Angajatii au tendinta de a ignora procedurile
• Managerul de proiect si liderii de echipa trebuie sa:
❑ incurajeze implicarea in calitatea muncii realizate
❑ promoveze necesitatii asigurarii calitatii pe tot parcursul unei activitati
Livrabile :
▪ formatul documentelor folosite in proiect este unitar
▪ se defineste o conventie unica de clasificare si denumire a
livrabilelor si documentelor
▪ documentele finale se redacteaza in aceeasi limba
▪ Corelarea sectiunilor proiectului
▪ tehnicile utilizate sunt aceleasi pentru toate aspectele proiectului (ex.
tehnica de estimare, tehnica de modelare)
▪ se specifica standardele folosite in planul de calitate
Echipa de management al calităţii :

▪ formata din:
▪ Managerul de proiect
▪ Managerul de calitate
▪ Echipa de proiect
▪ Poate fi extinsa:
▪ Client
▪ Alte entităţi implicate în proiect
▪ Agenţii de reglementare a calităţii
Nivelul de calitate
• Managementul defineşte rolul şi efortul de calitate asociate activitățiilor
proiectului şi este responsabil pentru asigurarea şi controlul calităţii.
• Finanţatorul sau clientul nominalizează nivelul de calitate acceptat, acest
aspect reprezentând o decizie de afaceri.
Echipa de management implementare

• Angajatul îşi asumă responsabilitatea pentru respectarea cerințelor
postului, în sensul în care:
• ştie ce paşi trebuie făcuţi pentru îndeplinirea cerințelor
• ştie cum să îndeplinească activitatea alocată
• are uneltele necesare
• poate măsura gradul de îndeplinire a activităţii
• poate corecta problemele pe parcurs
Metode si tehnici
• Analiza cost – beneficiu
• Costul calitatii (Cost of Quality COQ)
• Benchmarking
• Proiectare de experimente
Booyabazooka original png by Wapcaplet -
Scheme logice DanielPenfield - Own work
Diagrama cauza-efect
• Analize statistice
Instrumente
• Diagrama cauza-efect
• Scheme logice
• Lista de verificare
• Diagrame Pareto
• Histograme
• Grafice de proces DanielPenfield - Own work Diagrame Pareto
Grafice de proces
Costul Calitatii
▪ Costul calitatii (Cost of Quality - COQ) este costul total al efortului de

atingere a cerintelor asociate unui produs sau serviciu,
▪ Presupune costul asociat activitatii de asigurare a conformitatii cu
cerintele si cel asociat activitatii de remediere a neconformitatii cu
cerintele.
▪ Costuri de prevenire si evaluare (cost de conformitate) include costurile
de QP, QC si QA pentru a asigura conformitatea cu cerintele
▪ Costuri de esec (cost de nonconformitate) include costurile de refacere de
produse, componente, si procese care sunt neconforme, costuri de
garantie, rebuturi si pierderea reputatiei.
▪ Costul unui sitem de calitate este vazut ca un cost negativ deoarece
greselile au fost in mod traditional acceptate ca un cost de afaceri.
Planificarea evaluarii calitatii
• Planul de calitate va include la finalul fiecarei etape :

▪ evaluarea activitatilor efectuat conform criteriilor declarate in plan
▪ nivelul de acceptanta a rezultatelor
▪ metode de identificarea a abaterilor de la planificare:
▪ Este inclusa in managementul schimbariii -> impact ?
▪ Nu a fost planificata dar intra in categoria riscurilor acceptabile
▪ Se va remedia la un moment ulterior
▪ Trebuie remediat inainte de finalizare.
• Raportul de evaluare a calitatii trebuie aprobat si predat managerului de proiect

si/sau sponsorului proiectului .
Atentie daca sunt identificate probleme importante la finalul etapei este prea tarziu sa fie remediate fara a
avea efecte adverse asupra costului si timpului. -> necesitatea asigurarii calitatii pe toata durata etapei
Planificarea imbunatatirii calitatii
• Evaluarea calitatii
• masura in s-au realizat in mod adecvat livrabilele planificate
• Rata de succes a proiectelor in cadrul organizatiei poate fi

imbunanatita prin identificarea unor aspectele ce pot fi implementate
mai bine in proiectele ulterioare:
• lectiile invatate,
• planificarea de imbunatatiri,
• imbunatatirea tehnicilor de estimare,
Planificarea imbunatatirii calitatii
• Managementul calității totale (Total quality management - TQM)

• este o tehnică sau strategie de management de proiect
• o filozofie a calității este încorporată în toate fazele proiectului de la concepție
până la finalizare.
• folosit în industrie
• necesită analiza etapelor unui proiect din perspectiva calitatii
• necesită implicarea coordonata a intregii echipe.
• managamentul comunicarii este un aspect esential.
• Standarde si proceduri bine definite
• echipa trebuie să respecte planul
Asigurarea calităţii
36
Assurance vs. Control Studiu de caz
• Quality assurance is often confused with quality

control; quality control is done at the end of a
process oractivity to veryfy that quality standards
have been met.
• Quality control by itself does not provide quality,
although it may identify problems and suggest ways
to improving it. In contrast, quality assurance is a
systematic approach to obtaining quality standards.
• Quality assurance is something that must be
planned for from the earliest stages of a project,
with appropriate measures taken at every stage.
https://www.pm4dev.com/resources/free-e-books/5-project-quality-management/file.html
• Managerul de proiect si echipa de asigurare a calitatii:

• lucreaza impreuna pentru a asigura respectarea procesele si procedurile de
management definite
• Identifica toate problemelor nerezolvate de neconformitate
• iau masuri pentru cresterea eficientei si eficacitatii proiectului pentru a oferi
beneficii suplimentare stakeholder-ilor (Imbunatatirea Calitatii)
• Imbunatatire Continua (CI) = Adoptarea de noi activitati si eliminarea
celor care aduc un plus de valoare scazut
• Obiectivul este cresterea eficacitatii prin reducerea ineficientei si pierderilor
(munca, timp, efort, materiale etc)
• Termenul Japonez = Kaizen, format din cuvintele “Kai” = schimbare si “zen” =
bun
Componente ale proceselor de asigurare a calitatii

• Resursa umana
• Instruirea membrilor echipei de proiect
• Proces
• Sistem de gestionare a configurației
• Identificarea configurației
• Analiza a proiectelor
• Implementarea proceselor legate de calitate
• Liste de verificare
• Inspecție
Componente ale proceselor de asigurare a calitatii (continuare)

• Rezultat
• Clasificarea cerintelor
• Analiza modului de defecţiune și a efectelor acesteia (FMEA - “Failure mode
and effect analysis”)
• Modelare și prototipare
• Teste de laborator
• Experimente in mediu de functionare
Instrumente
• Diagrame de afinitate
• Diagrame decizionale Diagrame de afinitate
(Process Decision Program
Charts)
• Diagrame arbore
• Matricile de prioritate
• Diagrama rețelei de activități
• Diagrame matriceale
PM World Journal Project Quality Management for Project Managers

Vol. IV, Issue VII – July 2015 T. D. Jainendrakumar Process Decision Program Charts
• Ciclul de activitati Planifica-
Imbunatatire Continua Realizeaza- Verifica – Actioneaza
• proiectat sa incurajeze
imbunatatire continua si este
baza pentru imbunatatirea
calitatii
• Concept:
• Planifica: Planifica munca,
• Realizeaza: Efectueaza
planul,
• Verifica: Verifica rezultatul
• Actioneaza : Actioneaza
pentru a imbunatatii
Karn G. Bulsuk (http://www.bulsuk.com). performanta
Cilcul de activitati este continuat pe baza rezultatelor,
rezultatele unei etape sunt intrarile urmatoarei etape 42
Imbunatatire Continua
Fig: Johannes Vietze

Controlul calităţii
44
Controlul Calitatii
• Controlul calitatii
• este realizat in toate etapele din ciclul de viata al proiectului
• este efectual, in general, de un department de control al calitatii
sau de alte echipe de control care au primit aceste responsabilitati
• Rezultatele include atat produsul final, livrabilele
intermediare, cat si performante asociate costului si
programului
• Evaluarea rezultatelor controlului calitatii se face pe baza
controlului statistic al calitatii.
Controlul Calitatii
❑ Aplicarea metodelor de calitate si control este urmarita

continuu, nu doar evaluata la sfarsitul unei etape.
❑ Statutul activitatilor si livrabilelor poate fi urmarit din listele
pregatite pentru etapa.
❑ Se urmareste progresul etapei (ex. nu a inceput, in
desfasurare, finalizat, predat), si rezultatul unor evaluari si
recenzii specifice.
❑ Finalizarea unei etape este avizata de responsabilul de calitate
pe baza evaluarii de calitate
Obiective ale Controlului Calitatii
▪ Imbunatatirea calitatii
▪ Identificarea defectelor conform cerintelor sau specificatilor de
calitate
▪ Completarea listelor de verificare care devin parte din
inregistrarile proiectului
▪ Ajustari de proces = actiuni corectoare sau preventive imediate
ca rezultat al controluli de calitate
Evaluarea calitatii
▪ Evaluarea calitatii = Recenzii (REVIEW) de tip:

▪ Management
▪ “Peer”
▪ Centre de competenta
▪ Fitness sau Audit
• Colectarea de date cantitative pentru analiza este baza unui

management proactiv bazat pe FAPTE si nu pe ASTEPTARI
Auditul calităţii
49
Managementul Calitatii vs.
Auditul de Calitate
▪ Prin Managementul Calitatii, ne referim la toate activitatile care au ca
scop obtinerea nivelului dorit de calitate.
▪ Prin Auditul de Calitate ne referim la controale de procedura si rezultat
care asigura ca participantii urmaresc in mod corespunzator procedurile
declarate in planul de calitate iar rezultatul indeplineste cerintele.
• Conceptele sunt inrudite dar nu trebuie confiundate.

• In particular, Auditul de Calitate se refera la abordarea de calitate care
e prevazuta in standardele de calitate precum standardele ISO-900x.
Auditul de Calitate
▪ Un audit de calitate este o recenzie structurata si independenta cu scopul de a

determina daca activitatile proiectului sunt conforme cu politicile, procesele si procedurile
companiei si proiectului
▪ Obiectivele auditului de calitate sunt sa identifice politici, procese si proceduri
ineficiente folosite in proiect
▪ Efortul ulterior pentru a corecta aceste deficiente ar rezulta in reducerea costului
de calitate si cresterea procentului de acceptarea a produsului sau serviciului de catre
client sau sponsor
▪ Auditul de calitate confirma implementarea schimbarilor solicitate si aprobate, actiuni de
corectare, reparatii de defectiuni si actiuni preventive
Exemplu
STUDIU DE CAZ
Under control
CLASS A: Minor problems might exist, but the project manager has an effective
plan for resolution; no major existing potential problems have been
identified
Currently under control
CLASS B:
Existing or potential problems must be resolved to avoid deterioration
Significant problems
CLASS C: Corrective plans required immediately. Probably will exceed estimates
or budgets; aggressive management action essential to regain control
Major problems
CLASS D: Definite financial impact, serious problems with client acceptance, or
negative impact on client's business.; thorough management
evaluation required; executive call on client
52
Principiul Auditului de Calitate
Principiile Auditului de Calitate, sunt bazate pe standardele de calitate

Aceste standarde nu creaza calitate prin simpla existenta.
Fiecare companiei ar trebui sa defineasca proceduri cuprinzatoare prin care

produsele si serviciile pot fi livrate consecvent la nivelul de caltate dorit.
Maximum de calitate este rareori dorit deoarec costul poate fi prea mare si durata
de obtinere poate fi prea lunga -> decizie de afaceri.
Produsul sau serviciul “mediu” ofera un compromis sensibil intre calitate si
cost.
Procedurile create de companii pe baza standardelor de calitate ar trebui sa
livreze calitatea care este cautata.
53
Functionarea
Auditului de Calitate
Auditul de calitate afecteaza intregul ciclu de viata:

▪Standarde predefinite vor avea impact asupra modului in care
proiectul este planificat
▪Cerintele de calitate vor fi identificate in avans pentru etape si livrabile
specifice
▪Proceduri specifice vor fi urmarite pe parcursul tututor etapelor
▪ Metode de calitate trebuie definite si urmarite
▪Livrabile si etape finalizate vor fi evaluate pentru conformitate.
Cadru de baza si set de reguli ce trebuie aplicate la procesele

de management al calitatii.
54
Analiza Auditului de Calitate
Astfel de evaluari sunt deseori aplicate la sfarsitul etapei

sau finalizarea proiectului.
Desigur, principalul dezvantaj al unei astfel de evaluari este ca adesea
e mult prea tarziu pentru a afecta rezultatul proiectului.
In acest caz accentul se pune pe invatarea lectiei si imbunatatirea

elementelor administrative.
55
Ghid de bune practici
▪Calitatea este planificata, nu examinata
▪Dezvoltarea unei echipe pentru managementul calitatii unui
proiect faciliteaza desfasurarea proiectului in conformitate cu
cerintele clientului
▪Folosirea unor instrumente este esentiala in executia
programelor de calitate; aceste unelte asista managerul de
proiect in identificarea deviatiilor de la standarde.
▪Costul de calitate include si costul de conformitate si costul
de nonconformitate
▪Ciclul de activitati Planifica- Realizeaza-Verifica-
Actioneaza aduce imbunatatire continua si este baza pentru
imbunatatirea calitatii
56
pentru dezvoltarea de aplicatii software
Planificarea ciclului de viata a aplicatiilor software 1

CUPRINS
 Introducere
 Planificarea ciclului de viata
 Modele:
 Waterfall
 Code-and-Fix
 Prototiparea
 Modelul V
 Commercial Off-The-Shelf software
 Modelul Incremental
INTRODUCERE
 Ciclul de viata al unei aplicatii software cuprinde
urmatoarele etape:
Cerinte Requirements
Arhitectura / Design Design
Implementare Construction
Testare Testing /Debugging
Instalare Deployment
Mentenanta Maintenance
 Modul de organizare al acestor etape a determinat

aparitia unor metode de planificare.
INTRODUCERE
Citat
“Every software-development effort goes

through a ‘lifecycle,’which consists of all the
activities between the time that version 1.0 of a
system begins life as a gleam in someone’s eye
and the time that version 6.74b finally takes its
last breath on the last customers machine.”
Steve McConnell,
Rapid Development, 1996
INTRODUCERE
Citat
“The goal is often not to achieve what you

said you would do at the beginning of the
project, but to achieve the maximum
possible within the time and resources
available.”
Roger Sherman,
Microsoft, 1995
Metode de planificare a ciclului
de viata al aplicatiilor software
PLANIFICAREA CICLULUI DE VIATA
 Componente de baza ale planificarii:
 Etapele si ordinea lor
 Produse intermediare asociate cu fiecare etapa
 Validare a rezultatelor intermediare
 Clasificare metodelor de planificare:

 Liniare
 Iterative
 Incrementale
 Agile
 Adaptive
ALEGEREA CICLULUI DE VIATA
Criteriu Motivatie
Buget Folosirea unei metodologii poate afecta bugetul

prin adaugarea de costuri legate de metoda si de
management
Dimeniune echipa Metodele adreseaza si dimeniunea echipei
Timpul alocat Timpul poate fi o constrangere. Calitatea poate

fi influentata de timpul alocat.
Tehnologia folosita Hardware sau Software
Documentatia Unele metode sunt axate pe documentatie altele

o evita pe cat posibil. Documentatia ofera
“feedback” echipei de management
Criteriu Motivatie
Training Echipa poate necesita cursuri pentru

intelegerea metodei.
Best practices/lessons Difera in functie de metoda folosita

learned
Tehnici de aplicare si Disponibilitatea acestor elemente este

“tools” importanta pentru alegere.
Procesele existente Maturitatea proceselor va infuenta ritmul

proiectului
PLANIFICAREA CICLULUI DE VIATA
Metode de dezvoltare a sistemelor Metode de dezvoltare de prototip:
software: • Prototype: Throw away and
• Metode liniare : evolutionary
• Waterfall (Clasic)
• V
• Metode iterative
Metode de dezvoltare rapida:
• V
• RAD - Rapid Application
• Spiral
Development
• Evolutionary delivery
• Design to Schedule / Tools
• Staged Delivery
• Rational Unified Process
• Metode incrementale Metode de dezvoltare
• Metode agile complementare:
• XP: eXtreme Programming • COTS-Commercial Off-the-
• Scrum Shelf Software
• Code and Fix
Waterfall (Cascada)
WATERFALL (CASCADA)
 Propus in 1970 de W.W. Royce
 “Bunicul” tuturor modelelor
 Secventa liniara – fazele nu se suprapun
 Toata planificarea de la inceput
Analiza
Arhitectura Implementare Testare
acerintelor
Nu trebuie omisa Mentenenta

MODEL WATERFALL (CASCADA)
Idee Produs
Cerinte
Validare
Analiza Arhitectura Implementare Testare
Validare Validare Validare

WATERFALL (CASCADA) -
REALITATE
Idee Produs
Cerinte $ $ $
Validare
Validare Validare Validare
$ $
WATERFALL (CASCADA)
Avantaje
 Insiruire logica a secventelor
 Scalabilitate
 Orientat pe documentare
 Puncte fixe de review / milestone

WATERFALL (CASCADA)
Dezavantaje
 Necesita specificatii / cerinte foarte bine definite
de la inceput
 Lipsa de flexibilitate (secventa rigida inceput ->
final)
 Rezultatele se vad la final
 Aparitia de “probleme” intre secvente

WATERFALL (CASCADA)– SASHIMI
Concept
Cerinte
Arhitectura
Suprapunere etape
Arhitectura detaliata
Codare
Testare
Watterfall Modificat versiunea 1

WATERFALL (CASCADA)– SASHIMI
 Catacteristica: etape suprapuse
 Avantaje
 Reduce timpul
 Reduce documentatia
 Functioneaza bine daca exista o continuitate a
resursei umane
 Dezavantaje
 Milestones greu de definit
 Procese dificil de planificat si urmarit
 Dificultati in comunicare
WATERFALL (CASCADA)–
MODIFICAT
Idee Produs
Cerinte
Validare
V&V V&V V&V

V&V = Verification and Validation
Validation: Are we building the right product? Diferenta
Verification: Are we building the product right?
Watterfall Modificat versiunea 2

Code-and-Fix
CODE-AND-FIX
 “Code-like-Hell”
 Specificatii (poate), Cod (DAAAAA), Release
(poate)
COD TEST
 Cod –Test –Cod –Test………

Problema -> Rezolva -> Incepe din nou
 Design (high level)
 Cod –Test –Cod –Test…..
Cod -Test –Cod –Test –Documenteaza
 Mentenanta: Test –Code -Test
CODE-AND-FIX
 Avantaje
 Fara un managemet excesiv
 Nu necesita experienta
 Dezavantaje
 Control inexistent al proceselor si a calitatii
 Foarte riscant
 Avantajos pentru prototipuri sau teste

CODE-AND-FIX
Probleme
 Structura codului dupa faze succesive
cod-fix1
 Codul bine scris nu indeplineste in mod
obligatoriu si necesitatile clientului
 Codul este greu de depanat in lipsa
metodologiilor de testare
Metoda Prototiparii
•Evolutiva
•Exploratorie
METODA PROTOTIPARII
 O metoda folosita atunci cand:
 cerintele generale sunt cunoscute dar cerintele
specifice sunt neclare sau dificil de identificat
 exista o incertitudine asupra cerintelor
sistemului
 sistemul este complex
 interfata cu utilizatorul este complexa
 Permite:
 experimentarea cu mai multe solutii

 interactiunea utilizatorului cu sistemul
PROCESUL DE PROTOTIPARE
 Metoda prototiparii:
 versiune initiala a sistemului este construita
repede si ieftin
 evaluare a sistemului din primele versiuni
 rezultatele evaluarii ajuta la rafinarea
cerintelor
 iteratii succesive
 Prototiparea evolutiva (Evolutionary prototyping)
 Obiectiv:
 sistem functional
 Se realizeaza un prototip si se rafineaza (evolueaza)

pana in la forma finala.
 Prototiparea exploratorie (Throw-away prototyping)
 Obiectiv:
 obtinerea sau validarea cerintelor
 testarea unei idei sau tehnologii
 Implementare practica a unui sistem cu scopul de a

ajuta la identificarea cerintelor sau a explora o
implementare. Prototipul astfel obtinut este “aruncat”.
REZUMAT
Rezultat
Prototip evolutiv Sistem
Cerinte
Specificatii
Prototip exploratoriu sau
Componenta
Arhitectura
Cerinte
finala
Arhitectura Implementare
Decizie
Implementare Testare
ANALIZA
Testare Mentenata
PROTOTIPAREA EXPLORATORIE
 Prototiparea exploratorie (Throw-away
prototyping)
 După finalizarea implementarii cerințele de sistem,
aruncați prototipul.
 Proiectarea și implementarea sistemului conform cerințelor
utilizând cele mai bune tehnici de inginerie software.
 Clientul trebuie să înțeleagă că prototipul nu este realizat
pentru a servi ca un sistem functional.
 Costul asociat unui prototip și efortul de dezvoltare a sa se
justifica prin testarea functionarii solutiei astfel
propuse
THROW AWAY PROTOTYPE
Poate fi realizat !! Vs
Evrika !!
Am gasit cerintele
 Final necunoscut
 Scopul : Cercetarea in domeniu
 Dezavantaje
➢ Rezultatele se vad la sfarsit: Merge sau nu ?
➢ Calitatea
 Folosit pentru reducerea riscurilor legate de cerinte
 Prototipul este dezvoltat si apoi este “aruncat” dar
anumite componente pot fi inglobate in solutia finala
 Acest prototip nu este solutia finala deoarece:
 Anumite caracteristici ale sistemului nu au fost

tratate
 Efectul anumitor interactiuni nu este luat in calcul
 Nu exista cerinte bine definite
 Structura sistemului nu este definita
 Lipsa documentatiei
 Lipsa standardelor de calitate
Cerinte
Implementare Evaluare
initiale
De obicei
incomplete Specificatii
Metoda de dezvoltare
PRODUS FINAL
PROTOTIPAREA EVOLUTIVA
 Prototiparea evolutiva (Evolutionary
prototyping)
 Utilizați ultimul prototip ca punct de plecare pentru
proiectarea sistemului.
 Prototiparea evolutiva trebuie să fie planificata de la
început.
 Necesitatea de a identifica inca din faza de planificare
daca costul prototiparii se justifica, adica este mai
mic decât costul de dezvoltare directa a sistemului,
pornind de la cerințele.
 Etape
1) Identificare cerinte de baza (de pot ignora anumite
detalii)
2) Dezvoltarea prototipului initial
3) Review (client, utilizator) si feedback
4) Imbunatatirea si extinderea functionalitatilor
prototipului
5) Se repeta pasii 3 si 4 pana la obtinerea unei
versiuni de prototip acceptata
EVOLUTIONARY PROTOTYPE
Diferente fata de modelul anterior
 Se specifica un produs final
 Caracteristicile produsului evolueaza pana la un

rezultat final predeterminat.
Prototip Prototip
Concept
initial final
Versiune
Cerinte Arhitectura
Prototip
Evaluare
Decizie
Produs
STUDIU
PROTOTIPAREA EVOLUTIVA DE CAZ
TIPURI DE PROTOTIP http://it.toolbox.com/blogs/enterp
rise-solutions/prototyping-types-
of-prototypes-14927
General
Type of Prototype Typical Purpose When to Use
Characteristics
Analyze system High-level, overall Concept Definition
Concept Prototype
approaches vision Stage
Determine feasibility of Proof of concept for Concept Definition
Feasibility Prototype
various solutions specific issues Stage
Demonstrates outer
layer of human
Clarify scope and Function Definition
Horizontal Prototype interface only, such as
requirements Stage
windows, menus, and
screens
Demonstrates a
Refine database Later portion of
working, though
Vertical Prototype design, test key Function Definition
incomplete, system for
components early Stage
key functions
Demonstrates the
Determine useable
Functional typical order in which Function Definition
sequences for
Storyboarding information is Stage
presenting information
presented
 Functioneaza atunci cand:
 Exista cerinte cu evolutie dinamica in decursul
proiectului
 Client care nu se “angajaza”
 Domeniu al problemei de rezolvat “vag” definit
 Asiguraun progres vizibil
 Nu functioneaza atunci cand:
 Este necesara o estimarea temporara ->dificila
 Este necesar termenul de finalitatea proiectului ->
greu de datat
 Poate reprezenta o scuza pentru a aplica “code-and-
fix”
 Avantaje:
 Se obtine o versiune functionala foarte repede
 Implicarea utilizatorului
 Dezavantaje:
 Probleme de management:
 esimare durata dificila
 etapele pot fi cele din modelul “waterfall”
 Probleme de sistem: schimbarile dese pot

afecta sistemul
Modelul Incremental
MODELUL INCREMENTAL
 Dezvoltarea produsului in incremente
 Fiecare increment aduce (teoretic) mai multa
functionalitate
Increment Increment
Cerinte Arhitectura 1 n
Sistem final
MODELUL INCREMENTAL
DESCRIERE
 Este o combinație a unuia sau mai multor modele
Waterfall.
 Se pot dezvolta cerinte si specificatii pentru fiecare
increment.
 Fiecare increment include functionalitati ale sistemului:
 Implicarea utilizatorului
 poate testa fiecare increment
 Stabileste prioritatea functionalitatilor si ordinea incrementelor
 Sistem functional odata cu primele incremente

 Aduce un plus de control si structura fata de metoda
prototiparii
 Reduce riscul de implementare a cerintelor eronate
MODELUL INCREMENTAL
IMPLEMENTARE
1. cerințele sunt împărțite în sectiuni ce pot fi
implementate pe parcursul unui increment
2. sistemul este dezvoltat in incremente dupa finalizarea
arhitecturii generale.
3. fiecare modul este dezvoltat separate
 modelul cascadă este urmărit in mod individual pentru
fiecare modul.
 nu există / exista slabe dependențe de alte module,
4. fiecare modul dezvoltat ar putea fi livrat utilizatorilor
finali si utilizat de acestia.
5. modulele dezvoltate sunt integrate
6. se desfășoară până când se îndeplinesc toate cerințele
și se dezvoltă întregul sistem.
MODELUL INCREMENTAL
Tip Incremente integrate

1 in sistemul final
Cerinte sistem
Validare
Implementare Integrare
Arhitectura
increment increment
Validare
Sistem
Sistem final complet
MODELUL INCREMENTAL
INCREMENTE VERSIUNI FUNCTIONALE
Tip
2
Analiza de
Cerinte Arhitectura
sistem
Incremente
versiuni
Arhitectura detaliata functionale
Verificare
Cod
Testare unitate
Increment Increment
Integrare 1 n
Verificare sistem
Implementare
Testare sistem
Operare si mentenanta Sistem
MODELUL INCREMENTAL
VERSIUNI ALE SISTEMULUI
Tip Incremente versiuni
Cerinte 3 demo ale sistemului
Design
Implementare
V0.1
V0.2
V0.3
V0.4
V0.9
Demo1
Demo2
V1
Demo3
Demo4
Demo9
Demo
MODELUL INCREMENTAL
VERSIUNI ALE SISTEMULUI
Cerinte
Arhitectura Cerinte versiune Modificari

generala
Arhitectura
versiune
Implementare
Tip
4
Testare
Incremente Utilizare
versiuni ale
sistemului Versiune X
MODELUL INCREMENTAL STUDIU
DE CAZ
http://testingfreak.com/incremental-model-software-testing-advantages-disadvantages-incremental-model/
MODELUL INCREMENTAL
 Avantaje
 Fiecare incrementare aduce un produs functional
 Feedback de la client pentru fiecare increment
 “divide and conquer”
 Costuri initiale scazute -> Mai rapid
 Dezavantaje
 Definire a unui sistem functional de la inceput
 Interfata intre module
 Costul final nu este mic
Modelul V
MODELUL V
 Model axat pe testare si validare
Varianta de Waterfall / Cascada
 Verificare:
 Rezultatele unei etape corespund cu specificatiile si cerintele
stabilite.
 “Build the thing right.”
 Validare
 Sistemul produs corespunde nevoilor si asteptarilor
utilizatorului.
 “Build the right thing.”
MODELUL V
Planificarea Productie,
proiectului operare si
(productiei) mentenata
Identificarea Testare a
cerintelor si sistemului si
specificatiilor acceptanta
Arhitectura Integrare si
globala testare
Arhitectura Testare a
detaliata modulelor
Codare
MODELUL V
 Avantaje:
 Incurajaza testarea si validarea pentru fiecare etapa -
> orice produs (deliverable) trebuie testat
 Alegerea optima pentru sisteme ce necesita un grad
mare de risc
 Dezavantaje:
 Nu avantajaza abordarea iterativa
 Schimbarile sunt greu de implementat
 Nu are implementat o analiza a riscului
Commercial Off-The-
Shelf software (COTS)
COMMERCIAL OFF-THE-
SHELF SOFTWARE (COTS)
Decizie: Dezvolta sau cumpara?
Tipuri de aplicatii:
 Sisteme independente: “Turnkey systems”
 Construite in jurul unui singur produs
 Nu modifica functionalitatea produsului
 Sisteme intermediare: “Intermediate systems”
 Construite in jurul unui singur produs dar integreaza si alte
componente fie achizitionate fie dezvoltate
 Sisteme integrate: “Integrated systems”
 Integrarea unor aplicatii tip COTS
COMMERCIAL OFF-THE-SHELF
SOFTWARE (COTS)
Compromis
Cerinte
Oferta Arhitectura
COTS - TIPURI
 Componetat COTS
 aduce functionalitati implementate
 este testate
 se asigura suport tehnic
 Constrangeri ce trebuie luate in considerare:

 Acces la codul sursa
 Calitate
 Actualizari
 Training
COTS
Dezvoltarea unui sistem COTS
Cerinte Arhitectura Implementare Testare
Analiza Arhitectura Codare Testare

aplicatie
sistem
Testare
Codare
Identificare Integrare acceptanta
legaturi
ETAPE - COTS
 Etape ale COTS:
 Identificarea cerintelor
Cerinte
 Analiza cerintelor
Arhitectura
 Identificarea solutiilor COTS
 Selectia solutiilor COTS
 Arhitectura sistemului Selectie
Design
COST
 Dezvoltarea COTS
 Realizarea de interfete Interfete Cod
 Testare
 Dezvoltarea componentelor proprii Test Test

 Design detaliat + Programare
 Testare
Integrare
 Integrarea sistemului
 Testarea sistemului Testare
SOFTWARE (COTS)
 Trebuie adresate probleme legate de:

 Functionalitate
 Performanta
 Interoperabilitate
 Evolutie a produsului
 Vanzator
 Securitate
 Actualizari
SOFTWARE (COTS)
 Avantaje
 Disponibil imediat
 Cost scazut
 Dezavantaje
 Concesii legate de:
 arhitectura
 cost
 plan
 securitate
 Nu intodeauna indeplineste criteriile

 Waterfall (Clasic)
 Code and Fix
 Prototype: Throw away and evolutionary
 V
 Incremental
 COTS-Commercial Off-the-Shelf Software
 Spiral
 RAD - Rapid Application Development
 Design to Schedule / Tools
 Staged Delivery
 Evolutionary delivery
 Metode Agile
 XP: eXtreme Programming
Studiu de caz - istoric
 Modelul spirala
 Definit de Barry Boehm
 Combina elemente din modelele:
 evolutionary,
 incremental,
 prototyping
 Primul model ce explica importanta si eficienta
iteratiilor
 Termenul “spirala” se refera la iteratii succesive
pornind dintr-un punct central
Studiu de caz - diagrama
 Scopul: identificarea riscului de la inceput si
evaluarea in fiecare etapa
 In teorie, riscul este redus cu fiecare ciclu al
spiralei, pe masura ce produsul devine mai rafinat.
 Primele spirale sunt mai “ieftine”
 Numarul de spirale este variabil
 Ficare spirala:
 Incepe cu design-ul
 Se incheie cu opiniile clientului despre progresul facut si
directiile de urmat
 Avantaje
 Poate fi combinat cu alte modele
 Cu cresterea costurilor scade riscul
 Oientarea spre managementul de risc genereaza
avertismente la fiecare
 Dezavantaje
 Complex
 Creste volumul de munca pentru management
 Creste costul proiectului
Este recomandat pentru:
 Proiecte cu grad mare de risc
 Cerinte slab intelese
 Arhitectura slab inteleasa
 Potentiale probleme de performanta
 Probleme cu intelegerea tehnologiei
 In combinatie cu alte metode:

 Se poate incheia cu Waterfall
 Poate include alte modele ca iteratii
 Pasii“Waterfall” pentru arhitectura
 Celelalte etape urmeaza pasi:
Stage 1, 2, ..., n
 Detailed Design
 Code Construction & Unit Testing
 System Testing
 Release
Concept
Analiza cerinte
Release 1
Design R PRODUS
Arhitectura Cod Test
detaliat 1
Release 1
Design R
Cod Test PRODUS
detaliat 2
Release n
Design R
Cod Test n PRODUS
detaliat
 Caracteristici:
 Produsul este livrat in etape
 Cerintele sunt organizate in functie de prioritate
 Planificare initiala cuprinde datele la care se fac livrarile
si functionalitatile incluse
 Orice livrare intermediara presupune:
 functionalitati implementate integral
 un produs ce poate fi livrat catre client
 Reduce riscul de a nu livra nimic functional
 Progresul este vizibil odata cu implementarea proiectului
 Faciliteaza respectarea bugetului proiectului
 Cerinte bine definite si acceptate de client
 Stabilirea de prioritati pentru functionalitati
 Arhitectura bine definita
 Clientul accepta sa implementeze versiuni pana la
finalizarea produsului
 Posibilitatea de a livra module din produsul final
 Asigurarea calitatii fiecarei versiuni
Release 1 Release 2 Final Product

 Avantaje
 Produsul (intermediar) este livrat mai repede
 Versiuni beta interne sau externe
 Implica clientul in testare
 Implica echipa de vanzari si marketing
 Problemele sunt descoperite mai repede
 Flexibilitate
 Progres si probleme vizibile de la inceput
 Documentatie mai putina, planificare simplificata
 Dezavantaje
 Cerintele sunt validate tarziu si sunt greu de schimbat
 Lipsa unei arhitecturi flexibile poate crea probleme
 Metode de dezvoltare cu urmatoarele caracteristici:
 Planul de proiect este definitivat de la inceput
 Arhitectura generala este dezvoltata de la inceput
 Aplica principii din metoda “Staged Delivery”
 Versiunile intermediare (stages) cuprind functionalitatile
cu prioritatea cea mai mare
 Nu toate versiunile (stages) vor fi livrate
Concept
Analiza cerinte S
Functionalitati cu prioritate mare
T
Design A
Arhitectura Cod Test
detaliat G
E
Functionalitati cu prioritate medie
Design
Cod Test PRODUS
detaliat
Data de livrare
a produsului
Functionalitati cu prioritate mica
Design
Cod Test
detaliat
 Avantaje
 Produsul este livrat la o data stabilita
 Cele mai importante aspecte sunt realizate mai intai
 Dezavantaje
 Etapele nefinalizate
evolutionary
staged delivery
prototyping
Evolutionary Delivery
 Diferente fata de “evolutionary prototyping”

 Accent pe dezvoltarea, la inceput, a unui sistem cu
putine functionalitati
 Accent pe vizibil: “front end”
Concept
Cerinte
Arhitectura
generala
Versiune finala
EVOLIUTIE
Implicare client
Plan
Cerinte Design Plan
Implicare
Design client
Ciclu 1 Cod
Test
utilizator Ciclu 2 Test
Ciclu 3
Test
 Avantaje
 Tine cont de cererile clietului
 Rezultate tangibile
 Dezavantaje
 Planificare
 Code & Fix
 Folosit la proiecte ce necesita un timp scurt
Manifest:
 Oamenii si interactiile preferate poceselor si
instrumentelor
 Software functional preferat documentarii
 Colaborarea cu clientul preferata negocieroii
contractului
 Raspunsul dinamic la schimbari fata de urmarirea
planului
http://agilemanifesto.org/
“usor” (documentatie) &
orientare client
 Adaptive Software Development (ASD)
 Feature Driven Development (FDD)
 Crystal Clear
 Dynamic Software Development Method (DSDM)
 Rapid Application Development (RAD)
 Scrum
 Extreme Programming (XP)
 Rational Unify Process (RUP)
 Prototyping
Cerinte initiale
Arhitectura initiala
Validare
Iteratie 1 Lectii invatate
Iteratie2 Validare
Lectii invatate
Finalizare
Lectii invatate
Iteratie n
 Pun accent pe:
 Control vizual
 Echipe cu performanta ridicata
 Test-driven development
 Control adaptiv
 Feature-driven development
 Leadership si comunicare vs comanda si control
 Folcalizare de la C(ost) spre R(evenue)
 Lectii invatate / experienta
Analiza / Design
Dezvoltare Identificare Planifica

de model functionalitati functionalitati
Design / Implememntare
Design bazat Dezvoltare

pe bazata pe
functionalitati functionalitati
Versiune client
Versiune finala
 Rapid Application Development (RAD)
 Metoda de dezvoltare software dezvoltata de James
Martin la finalul anilor ’80.
 Reactie la metodele: Waterfall si Spirala
 Principii:
 Dezvoltare iterativa
 Prototip
 Utilizarea de aplicatii software support pentru procesele RAD:
“Computer-aided software engineering (CASE)”
 Metodologie – un set de metode, tehnici, aplicatii “la cheie”
 Roluri bine definite pentru echipa de proiect
 Metode de management de proiect incluse in metodologie
Etape ale RAD
1. Identificarea cerintelor
 Se utilizeaza tehnica Joint Requirements Planning (JRP)
2. Proiectarea aplicatiei impreuna cu utilizatorul

 se utilizeaza tehnica Joint Application Design (JAD)
 diferite definitii si denumiri pentru JAD,
 un lucru in comun ----sesiunea facilitate (workshop)
3. Dezvoltarea aplicatiei
4. Implementarea
 Denumita si “Cutover” sau “Deployment”
 Cuprinde testarea de catre utilizatori, training si instalare la client
Implementare
Constructie de
prototipuri
Prioritati dinamice
Evolutie catre Acceptare
Design Instalare
Cerinte produsul final
JAD Training
JRP
Methodologie
Echipa
Management
“Tools”
Prototip
Joint Joint Application Design

Requirements
Planning
Dezvoltare prototip
Versiunea i
Finalizare
Implementare
 Joint Application Development - JAD
 o procedura ce acelereaza proiectarea aplicatiilor
software.
 presupune dezvoltarea aplicatiilor impreuna cu clientul
 intalnirile de lucru sunt structurate si se focalizeaza pe

descrierea functionarii componentelor aplicatiei.
 Joint Requirements Planning –JRP
 o componenta a JAD utilizata pentru a defini cerintele
legate de aplicatie.
Etape ale JAD
 Etapa de planificare JAD
 Joint Requirements Planning –JRP
 Identificarea functionalitatilor aplicatiei din perspectiva
clientului
 Rezultate: obiective si plan de proiect
 Etapa de design
 Joint Application Design
 Design detaliat al aplicatiei impreuna cu clientul:
interfata utilizator, functionalitati detaliate, model de
date, dar NU si a arhitecturii functionale a aplicatie
 Utilizeaza prototipul ca mod de prezentare al aplicatiei
catre client in timpul workshop-urilor JAD
 Joint
Application
Development - JAD
 Dezvoltat de Chuck Morris
and Tony Crawford de la IBM
spre sfarsitul anilor ‘70 ca o
metoda pentru colectarea
cerintelor pentru sisteme
distribuite geografic.
 In 1984, IBM formalizeaza
JAD in urma publicarii
brosurii cu imaginea de
asambru a JAD.
Dezvoltarea colaborativă a aplicației ( eng: Joint
Application Development - JAD ) presupune
următoarele etape:
1. Etapa de planificare JAD
 Joint Requirements Planning –JRP
 Identificarea funcționalităților aplicației din perspectiva
clientului
 Rezultate: obiective şi plan de proiect
2. Etapa de pregătire a sesiunii JAD
 Se pregătește locația
 Se aloca participanții din partea echipei de implementare
3. Etapa de design
 Joint Application Design
4. Design detaliat al aplicației împreună cu
clientul: interfața
 utilizator, funcționalități detaliate, model de date, dar NU şi
a arhitecturii funcționale a aplicației
 Utilizează prototipul ca mod de prezentare a aplicației către
client în timpul workshop-urilor JAD
5. Finalizarea documentelor
 Se structurează ideile documentate in urma desfășurării
sesiunii
 Pentru achizitionarea cerintelor si dezvoltarea
aplicatiei se organizeaza intalniri de lucru (Workshop)
 Au o durata de 3-5 zile putand fi organizate si pe
sesiuni de lucru
 Pot ajunge pana la 2 saptamani
 Esterecomandat ca Workshop-urile sa nu fie la locul
de munca
 Workshop-urile se desfasoara in sali de dimeniune
adecvata numarului de participant si cu echipamente
multimedia
 Sali prea mari sau prea mici infuenteaza negativ
 Sponsor
 Doreste finalizarea cu
success a proiectului
 Facilitator
 Organizatorul workshop-ului
 Utilizatorisi Manageri din
partea clientului  Echipa IT
 Selectati de sponsor  Echipa care va lucra la
 Participarea managementului proiect
poate influenta negativ  Scribi
descrierea facuta de  Persoane nominalizate
utilizator pentru a nota cerintele
 Incep cu o prezentare a sponsorului
 Facilitatorul preia conducerea si parcurge agenda
 Odata cu inceperea discutiei despre functionalitatile
aplicatiei facilitatorul intretine discutia in limitele
scopului sesiunii
Workshop
 Organizarea prealabila a workshop-ului: agenda,
locatie, participanti, servicii suport …
 Facilitatori cu experienta
 Selectia participantilor
 Obiective clar definite
 Planificarea detaliata a agendei si urmarirea
acesteia
 Utilizarea restransa a limbajului tehnic
 Orentare catre producerea unui document ce
contine cerintele aplicatiei
Echipa IT
Utilizatori
si
manageri
Scrib
Facilitator
JRP
 SPONOR / CONDUCERE CLIENT:
 proprietarul sistemului
 capabili sa ia decizii si sa furnizeze resursele necesare
 participa obligatoriu la sesiunea de deschidere si
finalizarea a proiectului.
 LIDERUL/MANGERUL DE PROIECT:
 liderul echipei de dezvoltare
 raspunde la intrebarile legate de proiect cu privire la
domeniul de aplicare, timp, probleme de coordonare si
resurse.
 pot contribui la sesiuni atata timp cat nu inhiba ceilalti
participanti.
 FACILITATORUL / LIDERUL DE SESIUNE:
 conduce sedinta si organizeaza schimbul de idei
 Asigura respecatrea ordinii de zi a sedintei
 Identifica problemele care pot fi rezolvate in timpul
intalnirii si pe cele care vor fi rezolvate la urmatoarele
intalniri
 nu contribuie cu informatii sau pareri proprii legate de
dezvoltarea aplicatiei.
 OBSERVATORI:
 membri ai echipei de dezvoltare.
 vor observa desfasurarea sesiunii fara a interveni
 PARTICIPANTI:
 utiliozatori finali ai aplicatiei
 pot lua decizii legate de munca desfasurata
 sursa de informatii in cadrul sesiunii.
 SCRIBUL
 rol in documentarea intalnirii
 distribuie documente redactate in timpul intalnirii fara
a contribui cu informatii proprii.
 Reducerea timpului necesar dezvoltarii aplicatiei
 Imbunatatirea calitatii aplicatiei
 Implica utilizatori finali in ciclul de dezvoltare
 Reduce costurile aplicatiei
 Incurajaza implicarea clientului pe toata durata
proiectului
 Imbunatateste comunicarea si relatia intre client /
utilizatorii finali si echipa de dezvoltare
 Utilizeaza tehnici de modelare in timpul sesiunilor
JAD
 Daca se ignora pregatirea corespunzatoare a
intalnirilor, se va dovedi a fi o pierdere de timp si
fonduri
 Necesita sisteme ce pot fi modularizate
 Preia din dezavantajele metodei prototiparii
 Exista riscul sa nu se ajunga usor la o aplicatie finala
“XP is a lightweight methodology for small-to-
medium-sized teams developing software in the face
of vague or rapidly changing requirements”
Beck, Kent; Andres, Cynthia. Extreme
Programming Explained: Embrace Change
A fost propusa de Kent Beck in 1990
 Moto: “Embrace Change”
 Se bazeaza pe: Valori, Principii si Practici
 Caracteristici:
 Programare pe perechi
 Implementare bazata pe testare
 Planificare continua
 Fara ore suplimentare !!!
 Metoda “Lightweight”
 Politica pasilor marunti
 Realizarea testelor componentelor inainte de
programarea propriuzisa
 Testele se ruleaza la fiecare modificare relevanta
 Se realizeaza astfel o testare automata
 Se incepe cu o arhitectura simpla
 Programarea in perechi
 2 programatori la acelasi calculator
 Un programator tasteaza celalalt verifica codul introdus
 Rolurile se schimba regulat
 Integrarea si testarea regulata a sistemului
 Realizarea unui sistem functional din faza incipienta
 Implicarea clientului
 Verificarecontinua a codului
 Testare continua prin metode de testare automata
dezvoltate in paralel cu programarea
 Refactorizare zilnica
 Dezvoltarea aplicatiei prin iteratii dese si de
dimeniuni reduse
 Feedback
 Dezvoltare bazata pe teste: testele sunt dezvoltate
primele
 Implicarea clientului
 Programarea in perechi
 Proces de dezvoltare continuu
 Integrare continua
 Refactorizare
 Dezvoltarea bazata pe incremente
 Intelegere comuna
 Jocul de planificare, bazate pe descrierea facuta de
utilizatorilor
 Arhitectura simpla
 Metafora: analogie frecventa pentru sistem
 Drepturi de proprietate colective asupra codului
 Standarde de programare
 Dezvoltare
 Ritm sustinut: fara ore suplimentare
 Planning game.
 Clientul decide cuprinsul si calendarul versiunilor pe
baza estimarilor echipei.
 Echipa implememnteaza doar functionalitatile cuprinse
in povestile (“story”) din iteratia curenta
 Small releases.
 Sistemul intra in functiune inainte sa fie finalizat iar
actualizari apar oriunde in intervalul: o zi – o luna.
 Metafora
 Sistemul este definit de una sau mai multe metafore
intelese atat de echipa cat si de client.
 Programarea in pereche.
 Tot codul creat este scris de 2 persoane la acelasi
monitor/-tastatura - mouse.
“The metaphor just helps everyone on the project
understand the basic elements and their
relationships.
Words chosen to identify technical entities should
be consistently taken from the chosen metaphor. As
development proceeds and the metaphor matures,
the whole team will gain new inspiration from
examining the metaphor.”
 Beck, K.: Glossary. The XP Series. In: Extreme

Programming Explained. Addison-Wesley (2000)
 Arhitectura minimala.
 In orice moment sistemul va trece toate testele trecute
in etapele precedente
 Nu contine cod duplicat
 Foloseste nr. minim de clase si metode
 Teste.
 Programatorii scriu modalitati de testare pentru fiecare
portiune
 Clientii scriu teste functionale pentru fiecare “story”
 Toate testele rulate vor fi trecute
 Refactoring.
 Un sistem este dezvoltat prin transformari ale celui deja
existent mentinandu-se aceleasi rezultate ale testelor
 Integrare continua.
 Noul cod este integrat cu sistemul curent dupa doar
cateva ore.
 sistemul trebuie sa treaca de toate testele, altfel
schimbarile nu sunt aprobate
 Drepturi colective.
 Fiecare programator imbunatateste codul oriunde in
sistem la orice moment daca se iveste o oportunitate
 Client la locul faptei.
 Clientul este impreuna cu echipa tot timpul
 Saptamani de 40 de ore.
 Nimeni nu poate sa lucreze ore suplimentare, doua saptamani
la rand
 ore suplimentare frecvente = probleme ce trebuie adresate.
 Spatiu deschis de munca.

 Spatiu: camera mare impartita in compartimente (cubicles).
 Perechi de programatori lucreaza la calculatoare in centru.
 Reguli.
 Fiind parte din echipa, te angajezi sa respecti regulile.
 Echipa pate schimba aceste reguli la orice moment atat timp
cat sunt de acord sa evalueze efectele schimbarilor.
https://blogs.msdn.microsoft.com/jmeier/2014/06/06/extreme-
programming-xp-at-a-glance-visual/
 Ciclul de dezvoltare XP
1. Explorare (eng: Exploration / Product Life Cycles)
2. Release
3. Iteratii
4. Task-uri
5. Dezvoltare
6. Feedback
 Explorare
 Definire functionalitati
 Planificare
 Clientul formuleaza cerintele, acestea sunt descrise sub
forma unor “user storry”
 Livrabil: lista de cerinte
 Release
STUDIU DE CAZ
 Avantaje
 Proiecte mici si medii ->Lightweight
 Echipa ”sudata”
 Accent pe produs
 Iterativ
 Testare pentru specificatii si calitate
 Dezavantaje
 Proiectele mari cer documentatie
 Experienta pentru a nu ajunge la code&fix
 Programarea pe perechi costa
 Modele de testare complexe
Ciclu de viata 3
RATIONAL
UNIFIED
PROCESS
Rational Unified Process
• Produs comercial ( Rational Corporation) -> sustinut de
IBM (2003) - > model incremental
• Se ofera un “framework” suport, tool-uri, template-uri
(costuri ):
– “RequisitePro templates” (urmarire a cerintelor)
– “Word Templates” pentru “Use Cases”
– “Project Templates”pentru MP
• Orientat pe obiecte
• Dezvoltare interactiva
• Management al specificatiilor
• Arhitectura bazata pe componente
• UML (Unified Modeling Language) modelare vizuala
• Folosit pentru sisteme complexe
• Etape de dezvoltare:
– Inception Phase
– Elaboration Phase
– Construction Phase
– Transition Phase
• Bazat pe procese descrise de:
– Actori, ‘cine?’
– Activitati, ‘cum?’
– Artefacte, ‘ce?’
– Flux, ‘cand?’
• Fluxuri de activitati de baza:
– Modelarea proceselor de afaceri
– Cerinte
– Analiza si design
– Implementare
– Testare
– Implementare
• Fluxuri de activitati suport:
– Management de proiect
– Management al configuratiilor si schimbarii
– Mediu
Inception Phase
• Se stabileste obiectivul principal

• Se identifica cerintele initiale
• Analiza cost – profit
• Analiza de risc
• Definire scop proiect
• Definire arhitecturi posibile si selectare varinata
• Dezvoltare “Prototip de test”
• Scenariu initial (incomplet) “Use Case Model”
Elaboration Phase
• Analiza cerintelor
– Analiza Use Case
• Use Case (80% realizata )
• Model Use Case (80% realizat) -> UML
• Scenarii
– Diagrame de secventa si colaborare
– Diagrame de clase, activitati, stare …..
– Model domenial (Domain model)
– Plan de risc refacut
– Documentatie arhitectura
Martin Fowler
Domain model:
An object model of the domain that incorporates both behavior and data.
Elaboration Phase Domain
model
STUDIU DE CAZ
http://www.slideshare.net/grahammcleod/bri
ef-introduction-to-domain-modeling
Construction Phase
• Implementare si design detaliat
– Se adauga treptat functionalitati
– Stabilitatea aplicatiei creste cu fiecare pas
– Se implementeaza toate detaliile
– Se continua analiza cerintelor
Transition Phase
• Transferul sistemului catre utilizator
– fabricare,
– expeditie,
– instalare,
– training,
– suport tehnic
– mentenanta
• Echipa de mantenanta ia locul echipei de dezvoltare
• Alpha, Beta, produs final, Updates
• Integrarea cu sisteme existente (legacy systems)
INTERNATIONAL
STANDARD
ISO/IEC 12207
SOFTWARE LIFE
CYCLE
PROCESSES
ISO/IEC 12207
• Standard international pentru ingineria de software
– defineste procesul, activitatea si task-urile asociate cu un
anumit ciclu de viata, de la crearea sa pana cand
inceteaza sa mai fie folosit.
• Obiectivele principale
– structura comuna pentru cumparatori, furnizori,
dezvoltatori, personal de intretinere, operatori, manageri
si tehnicieni implicati
– limbaj comun.
• Standard ce defineste toate sarcinile necesare
dezvoltarii si intretinerii software-ului.
Ce reprezinta?
• Standard pentru:
– procesele din ciclul de viata al software-ului.
– realizarea unui cadrul comun pentru a vorbi
aceeasi limba in cadrul disciplinei software.
• Un acord international asupra caror activitati
intra in proiectarea unui software.
• Procesele din ciclul de viata al software-ului:
– Arhitectura de nivel inalt a proceselor
– Activitati si sarcini
– Modelate pentru orice organizatie sau proiect
– Un ‘inventar’ de procese din care se poate alege
Si ce nu reprezinta...
• NU este un standard al produsului
– Nu masoara calitatea produsului
• NU are caracter prescriptiv
– Nu specifica cum trebuie facute lucrurile
• NU este un standard de metoda
– Nu se adreseaza unui anumit ciclu de viata sau
unor instrumente
ISO/IEC 12207
Procese
primare Procese de suport ale
ciclului de viata
•Achizitie •Auditul
•Resurse •Organizare /Configurare Procese
•Dezvoltare organizationale
•Referinte
•Operare •Documentare
•Intretinere Management
•Garantia calitatii
Infrastructura
•Solutionarea problemelor
Imbunatatire
•Verificare
Instruire
•Validare
ISO 12207
• Standardul ISO 12207 stabileste procesele din
cadrul ciclului de viata
– Fiecarui proces i se asociaza un set de rezultate.
– exista
• 23 de Procese,
• 95 de Activitati,
• 325 de Task-uri
• 224 de Rezulate
ISO 12207
Arhitectura Proceselor
• Scopul
– Obiective de nivel inalt in
realizarea procesului si finalitatile
probabile ale implementarii
efective a procesului.
• Procesul
• Rezultate
– Un set de activitati inrudite, care
– Un rezultat al indeplinirii cu succes
transforma intrarile in iesiri
al scopului procesului.
– 25 de procese (18 + 7 noi)
– 224 de frezultate
• Activitate
– Set detaliat de task-uri
– 95 de activitati
• Task
– Atiune ce cuprinde intrare/iesire
– 325 de sarcini
Procesele din ciclul de viata
al unui software
PROCESE PRIMARE
PROCESE SUPORT
PROCESE ORGANIZATIONALE
al unui software
PROCESE PRIMARE
Achizitie Dezvoltare
Pregatirea achizitiei Analiza si designul sistemului
Selectia furnizorilor
Gestiunea furnizorilor Analiza cerintelor software
Preluare in gestiune (acceptare) Designul software
Implementare software
Resurse Integrare software
Testare software
Detalierea cerintelor Integrarea si testarea sistemului
Operare
Operarea sistemului
Suport client Intretinere
al unui software
PROCESE DE SUPORT
Documentatie
Managementul configuratiei
Asigurarea calitatii
Verificare
Validare
Review
Audit
Rezolvarea problemelor
al unui software
PROCESE DE ORGANIZARE
Management Managementul calitatii
Management de proiect Managementul riscului
Imbunatatiri Monitorizare Alinierea organizationala

Stabilirea proceselor
Evaluarea proceselor Infrastructura
Imbunatatirea proceselor Managementul resurselor umane
Reutilizare
Perspectiva ISO/IEC 12207
Proces
Proces
Proiect Instalare
Acceptanta si suport
Analiza de cerinte
Arhitectura
Sistem Integrare
Testare
Cerinte Testare
Arhitectura Integrare
Software
Arhitectura Programare
detaliata si testare
Implementarea procesului
• Defineste sau selecteaza un model de ciclu de
viata software
• Selecteaza, ajusteaza, si utilizeaza standarde,
metode, instrumnete si limbaje de programare
• Dezvolta planuri pentru desfasurarea activitatilor
din cadrul procesului de dezvoltare.
• Sub-Procese (ex)
– Implementarea procesului
– Explicitarea cerintelor
– Analiza cerintelor sistemului
Explicitarea cerintelor
• Scop:
– Sa identifice si sa urmareasca nevoile si cerintele dinamice ale
clientului de-a lungul vietii produsului si/sau serviciului
– Explicitarea cerintelor poate fi facuta de catre beneficiarul sau de catre
dezvoltatorul sistemului.
• Sarcini:
– Identificarea cerintelor clientului
– Reevaluare pentru a intelege nevoile clientului
– Acordul asupra cerintelor
– Stabilirea cerintelor de baza ale clientului
– Gestiunea modificarilor in cerintele clientului
• Finalitati:
– Cerintele clientului;
– Schimbarea registrelor de cerinte.
Analiza cerintelor sistemului
• Scop:
– Sa transforme cerintele definite intr-un set de norme tehnice de dorit
care vor ghida designul sistemului.
• Sarcini:
– Analiza cerintelor sistemului
– Verificarea cerintelor sistemului
– Normarea si comunicarea cerintelor sistemului
• Finalitati:
– Cerintele sistemului; cerinte de interfata
– Registrul de urmarire
– Raportul de verificare
SCRUM
SCRUM
• Scrum
– Reprezintă o metoda
incrementala de dezvoltare de
produse din categoria
metodelor agile
– SCRUM termen preluat din
rugby © PierreSelim / Wikimedia Commons / CC-BY-SA-3.0
– Bazele metodei scrum au fost puse de cercetătorii Takeuchi

and Nonaka in 1986
– A fost folosita prima data in 1993 de Jeff Sutherland la Easel
Corporation si fundamentata in de Ken Schwaber in 1997
– a devenit populara in anii 2000 ca o metoda alternativa de
management a proiectelor software
SCRUM
– 2001 “Agile Software Development with Scrum”
Ken Schwaber & Mike Beedle
– se abate de la metodologia conventionala a
managemnetului de proiect
• nu exista o strucutra WBS (Work Breakdown Structure),
• deciziile de planificare au fost complet descentralizate
– rezultat al evolutiei mai degraba decat a unui
model deliberat pe o baza teoretica noua.
– avantaje in productivitate, durata si satisfactia
clientului.
Principii SCRUM
• Ciclul de viata al dezvoltatii software
– Colectarea si analiza cerintelor
– Design/Proiectare
– Implementare
– Testare
– Livrare
• Rezultatul unei etape devine punct de pornire
pentru etapa urmatoare
– Fiecare etapa produce un rezultat previzibil si bine definit
– Aplicarea procesului rezulta in obtinerea de iesiri
repetabile
Principii SCRUM
• Control empiric a procesului:
– pregatire pentru neprevazut
– control prin inspectii frecvente si adaptari
– procese imperfect definite care genereaza rezultate
imprevizibile si irepetabile
• Adaptarea
– Procesul in cadrul caruia s-au detectat probleme se va
modifica astfel incat sa se limiteze sau sa rezolve
problemele
– Rezultatul care prezinta probleme de calitate (cerinte,
performante …) va fi remediat cu prioritate
Principii SCRUM
• Transparenţa
– Procesul si artefactele trebuie sa fie accesibile
conform necesitatilor
– Libaj comun pentru a putea comunica
• Inspecţia
– Monitorizare cu caracter regulat al artefactelor
– Monitorizare cu caracter regulat al progresul
– Analiza variaţiilor.
– Nu trebuie pus accent pe monitorizare. Accentul
este pus pe executie
Cadrul Scrum
Roluri :
Proprietarul produsului,
ScrumMaster,
Echipa
Ceremonii:
Artefacte :
Planificarea Sprint,
Backlog produs,
Sprint Review,
Sprint Backlog,
Retrospectiva Sprint
Burndown Chart
Reuniuni zilnice
Proprietarul produsului,
Roluri Scrum Master,
Echipa
Roluri Scrum
Scrum Master
– Responsabil de implementarea Scrum
• Intelegere, adoptie, relatii
– “servant-leader”
– Interfata intre management si echipa Scrum
– Responsabil cu indepartarea impedimentelor ce
determina stagnarea progresului echipei Scrum
– Trebuie sa ia decizii rapide bazate pe date
incomplete
• De obicei un inginer cu experienta
Roluri Scrum
Product Owner (Proprietarul produsului)
– responsabil de produs
– Coordoneaza Echipa de Dezvoltare din perspectiva
realizarii produsului
– Singurul detinator al ”Product Backlog”
• Modificarile la portofoliul trebuie sa fie aprobate de proprietarul
produsului
• Responsabil de conținutul și prioritatea cerintelor din Product
Backlog
– Are un rol apropiat de al unui lider tehnic sau manager de
proiect
Roluri Scrum
Echipa Scrum
• Toate competențele necesare realizarii produsului:
– Membrii de baza: Designeri, Testeri, Programator …
– Marime recomandata 5 – 10 persoane
– Extinsa: QA, Programatori, Designeri UI , etc.
• Membrii trebuie implicatii full-time
– Pot exista exceptii (ex. System Admin, etc.)
• Echipele se auto-organizeaza
– Nu se accepta divizarea – organizarea in grupuri
– In mod ideal – fara titluri …. In realitate posibil
– Responsabilitatea este a intregii echipe nu doar a unui membru
• Calitatea de membru se poate modifica numai intre sprinturi
Sprint
• Interval de timp asociat dezvoltării unui set de
funcționalități
• Durează, de obicei intre 14 si 30 zile
• Funcționalitățile cu prioritățile cele mai mari
din Product Backlog sunt implementate sub
denumirea de Sprint Backlog
• Estimările Sprint sunt actualizate odată ce
sunt finalizate sarcinile sau când apar altele
noi
Sprint
• Un sprint presupune dezvoltarea continua a
produsului cu potențial de transfer la finalul
ciclului
• Nici o influenta exterioara NU poate interfera
cu echipa Scrum in timpul Sprint-ului
• Fiecare Sprint incepe cu Sedinta Zilnica de
Scrum
Nici o schimbare in cadrul
sprint
SCHIMBARE
Intrari Sprint Testare cod
Planifica durata sprint in functie de cat de

mult poti evita modificarea acestuia
SCRUM
Daily
SCRUM
Story Sprint Review

Time Planning Meeting
session Meeting
Analysis, Design,
Evolution, Testing
Sprint Backlog
Standards
Architecture Technology
Design
Planificarea Sprint,
Sprint Review,
CEREMONII Retrospectiva Sprint
Reuniuni zilnice
Ceremonii
Sprint Sprint Sprint

Planning Review retrospective
Ceremonii
Sedinta de planificare Sprint

– Crearea “Sprint backlog” pe baza “Product
Backlog”
– Durata: maxim 8 ore (sprint 1 luna)
– Participanti:
• Proprietarul produsului, Scrum Master, Echipa Scrum
• Discutii:
– Ce se va face in acest Sprint ?
– Cum se va face ?
– Obiectiv sprint
Ceremonii
• Pre-Proiect/Kickoff Meeting
• O forma speciala a Sedintei de planificare a
Sprint
• Sedinta inaintea demararii proiectului
Ceremonii
Sedinta zilnica Scrum (Daily Scrum)
– Durează intre 5 - 15 minute
– Care sunt realizările de la ultima reuniune?
• Ce ați făcut ieri?
– Care sunt impedimentele pentru activitățile
următoare?
• Ce obstacole aveți de depășit?
– Ce se va realiza pana la următoarea ședința?
• Ce veti face azi?
– Toți participa, numai cei avizați își spun părerea
Ceremonii
– NU este o etapa de rezolvare a problemelor
– NU este o cale de a aduna informatii despre CINE
dezvolta programul
– Este o sedinta in care membrii echipei isi iau
angajemente unul fata de calalalt si fata de Scrum
Master
– Este o metoda buna pentru ca Scrum Master sa
poata sa urmareasca progresul echipei.
Ceremonii
• De ce zilnic?
– “Cum reusim sa intarziem un proiect un an intreg?”
• “Fiecare la timpul sau.”
– Fred Brooks, The Mythical Man-Month.
• Putem sa inlocuim sedintele Scrum cu raporturi de
etapa prin e-mail?
– Nu
• Toata echipa intrevede zilnic imaginea de ansamblu
• Intri in competitie cu colegii sa faci ceea ce iti propui
Ceremonii
Sedinta de Evaluare Sprint – Sprint review
• Echipa prezinta realizarile Sprint-ului

• Ia de regula forma unei demonstratii a unor
functionalitati noi sau arhitecturi detaliate
Doua componente:
Informala Formala
Pregatire a intalnirii formale Participanti: Clienti, Management
Proprietarul produsului, Alti invitati
Ceremonii
• Scop:
– analiza incrementul
– Actualizarea Product Backlog-ul (dacă este necesar).
• Echipa Scrum şi cei implicați discuta ceea ce s-a realizat în
Sprint.
• Participanţii discuta acțiunile următoare
• Aceasta este o întâlnire informală
• Prezentarea rezultatului
– feedback
– încurajează colaborarea.
• Durata:
– 4 ore pentru Sprint-urile de o lună.
– Mai putin de 4 ore pentru sprinturi mai scurte
• Scrum Master-ul este facilitatorul evenimentui.
Ceremonii
Adaptat: The Scrum Guid; The Definitive Guide to Scrum: The Rules of the
Game, Ken Schwaber and Jeff Sutherland

• Cuprinde:
– Product Owner-ul explică care elemente din Product Backlog au fost
"Finalizate" și care nu au fost "Finalizate";
– Echipa de Dezvoltare discută despre ceea ce a mers bine în timpul
Sprint-ului, problemele de care s-a lovit și modul în care acele probleme
au fost soluționate;
– Echipa de Dezvoltare demonstrează lucrările care au fost "Finalizate" şi
răspunde la întrebări cu privire la Increment;
– Product Owner-ul discută Product Backlog-ul așa cum se prezintă la
momentul respectiv. Preconizează datele posibile de finalizare bazate pe
progresele înregistrate până în present
– Întregul grup discuta ceea ce urmează să facă în continuare,
– Se discuta despre valoarea adaugata a produsului,
– Se discuta organizarea în timp, bug
Ceremonii
Sedinta retrospective Sprint– Sprint Retrospective
• Numai echipa Scrum
• Sedinta cu scop de Feedback
• Trei intrebari:
– Start
– Stop
– Continua
• A nu se sari peste ea cel putin la primele 4-5 sprinturi
– Dureaza aproximativ 3 ore
– Ofera feedback la management
– Ofera feedback pentru urmatorul Sprint
Ceremonii
Sedinta retrospective Sprint– Sprint Retrospective
• Scop:
– auto-analiza
– Analiza a sprint-ului: oameni, relații, proces, şi
instrument
– ientificare îmbunătăţiri
– un plan pentru îmbunătăţiri care urmează să fie
adoptate în cadrul Sprint-ului următor.
• Are loc după Sprint Review şi înainte de
Planificarea Sprint-ului următor (Sprint Planning).
• Scrum Master-ul este facilitator-ul evenimentului
• O lista de funcționalități , pe
care le va îndeplini
produsul, ordonata dupa
prioritatea asociata.
• Face referire la:
– Caracteristici noi
– Îmbunătățiri ale
caracteristicilor deja existente
Product Backlog – Prototipuri
– Documentație
– Eliminarea bug-urilor
– Training
• Nu se finalizeaza – ramane
deschis pe parcursulu
proiectului
– Product Owner-ul gestioneaza
modificarile
Product Backlog
The Product Backlog is an ordered list of

everything that might be needed in the product
and is the single source of requirements for any
changes to be made to the product.
K Schwaber & J Sutherland, The Scrum Guide, 2011.
Portofoliu(Backlog)
Studiu de caz Exemplu cerinta:
Ca un [rolul utilizatorului final],
eu vreau [dorinta] asa incat
[rationamentul]
Product Backlog
Studiu de caz
Product Backlog
• Afirmarea simpla a ceea ce se cere:
“Ca si
<tipul utilizatorului> STORY
dorec sa
<indeplinirea unei actiuni>
astfel incat sa pot
<atingerea unui rezultat>.
Exemplu:
“Ca si manager al Serviciului Clienți, doresc sa cunosc durata
medie de așteptare astfel încât sa pot asigura personalul necesar
la centrul de preluare a apelurilor.
• Permit proprietarului
produsului sa creeze cerințe
independente de modul de
implementare;
• Permite scrierea cerințelor din
punctul de vedere al
diferitelor tipuri de utilizatori
• Permite utilizatorilor si echipei
Product Backlog SCRUM sa vorbească nu atât
despre sistem in sine, cat
despre cum il vor utiliza
• Reprezintă o “promisiune a
unei viitoare conversații”
• Pot fi scrise atât de persoane
din domeniul tehnic cat si de
persoane din afara acestui
domeniu de activitate
Product Backlog
INVEST
I– N– V–
independent negociabil valorificabil
E – estimabil S – simplu T – testabil
Relatari utile de la utilizatori in jurul cuvantului

“ce, nu “cum”
Product Backlog
DEEP
Detailed
Estimated
Appropriately
Emergent Prioritized
Product Backlog
Sprint Backlog
Product Backlog
Extragere
sprint backlog
Poate contine:
1.Features
2.Bugs
3.Technical work
4.Knowledge acquisition
Prioritate
Introduce
cerinta
noua
Product Backlog
Sprint Backlog
Task 1.1
Sprint
Backlog 1
Product Task 1.2
Backlog
Sprint
Task 2.1
Backlog 2
Product Backlog
• Proprietarul produsului colaboreaza cu grupul
tinta pentru a defini si a scrie relatarile
utilizatorilor:
– Intalniri individuale
• Echipa detinatorului produsului, compusa din experti in
cerinte precum si analisti economici
• Echipa Scrum
• “Story Time session”
• Oricine poate adauga elemente in “Product
Backlog”, dar numai proprietarul (Product
Owner) poate stabili prioritatea finala.
“Story Time session”
• Scopul unei sesiuni de relatare (“Story Time
session” ) este de a o imbunatati “Porduct
Backlog”
• Aceste sesiuni pot servi la:
– scrierea povestilor utilizatorilor -> functionalitati
– Imbunatatirea relatarilor de la utilizatori
– Fragmentarea relatarilor / Lungimea relatarilor
– Adaugarea criteriilor de acceptare a unei relatari
• Planificarea urmatorului sprint
Criterii de acceptanta
• Stabilirea “limitelor” povestii
– ce este/nu este vizat
• Sunt negociabile
• Ajuta sa identificam cand o relatare e completa
• Provin din dialogul intre echipa si proprietarul
produsului in cadrul sedintelor de relatare si de
planificare
• Necesita abilitatea de pune intrebari pertinente
Tehnici de Estimare
“Product Backlog”
• Diverse metode de estimare a duratei unei
povesti (story):
– Valoare absoluta (ore)
– Valoare relativa (complexitate)
• Estimarile sunt converite in “story points”,
– “story points” = estimare cantitativa specifica
fiecarei echipe
• Viteza echipei = media “story points” asociata
povestilor finalizate de o echipa
Estimare absoluta vs relativa
• Estimati lungimea in (m): Estimare
– Furnica, Boeing 747, Basculanta, absoluta
Pod Cernavoda, Miriapod
• Aranjati dupa lungime, in ordine
crescatoare: Estimare
– Furnica, Boeing 747, Basculanta, relativa
Pod Cernavoda, Miriapod
Definire miriapod:
“expert knowledge”
Tehnici de Estimare
• Tehnici de estimare a duratei:
– Ore (foarte rar)
– “Planning Poker”
• Fiecare membru al echipei primeste un set de carti
• Se estimeaza prin ridicarea cartii alese
• Se finalizeaza cand membrii echipei sunt de acord
– Zile ideale ( “Ideal days”)
– “T-shirt sizes”
• Se asociaza dimensiuni (XS, S, M, L, XL, XXXL )
Exemplu
Planning Poker
Exemplu
Planning Poker – T-shirt
Tehnici de Estimare
• Tehnici de estimare a duratei (cont):
– Sirul Fibonacci
• ( 1,2,3,5,8,13,21…)
• Se interpreteaza ca factor de complexitate
– Gruparea - “Affinity Mapping”
• Se stabilesc grupe de complexitate
• Cerintele se grupeaza in functie de complexitate
– Ordonarea
• Se stabileste o scara de masura (exemplu low -> high)
• Se aseaza cerintele in ordine prin mutari succesive
Tehnici de Estimare
• Tehnici de estimare a duratei (cont):
– Bucket System
• Se stabileste o scara (de obicei nu liniara)
• Stabilirea unei referinte: pentru primele cateva cerinte
se citeste cerinta cu cerinta si echipa stabileste un
punctaj conform scalei
• Dividem et imperat: Fiecare membru al echipei alege
cerinte din lista de cerinte si le plaseaza conform scarii
alese
• Se verifica rezultatul
Exemplu
Bucket System
http://www.agileadvice.com/2013/07/30/referenceinformation/agile-
estimation-with-the-bucket-system/
Remaining Effort in Hours
5/
3/
20
100
200
300
400
500
600
700
800
900
0
5/ 02
5/
20
5/ 02
7/
20
5/ 02
9/ 752
2
5/ 00
11 2
/2
5/ 00
13 2
762
/2
5/ 002
15
664
/2
5/ 002
17
/2
5/ 00
Progress
19 2
619
/2
5/ 002
Date
21
/2
304
5/ 00
23 2
/2
5/ 002
25
/2
5/ 00
27 2
264
Sprint Burndown Chart
/2
5/ 002
29
180
/2
5/ 00
31 2
/2
00
2
104
20
Release Burndown Chart
• Predarea se va face la data stabilita?
– Axa X: sprinturi
– Axa Y: numarul de ore ramase
• Efortul ramas poate fi luat in calcul
• Product Burndown Chart
– Este o privire de ansamblu asupra progresului
proiectului
De ce Functioneaza?
• Cele mai multe ipoteze ale modelului definit
sunt eliminate
• Ofera feedback constant
“Ceea ce se “De ce nu poate fi

poate face” facut”
“Business value”
Valoarea comerciala asociata dezvoltarii unui
proiect:
• ROI (“Return on Investment”)
• Reducere de cost
• Reducere de efort
• Oportunitate de crestere
• Primul pe piata (“First-to-market”)
• Cost de oportunitate
• Cost renuntarii la proiect
• Pune accent pe munca in
echipa
– Echipa se dezvolta si
contribuie pe parcursul
porcesului
– Echipa devine autonoma si
se straduieste pentru
excelenta
Avantaje SCRUM • In functie de etapa, rotatia
1 intre lideri ofera o natura
distribuita de executie a
proiectului
• Echipa de management poate
urmarii de aproape progresul
echipei si poate intervenii
oricand e nevoie
• Companiile uneori invata
datorita obstacolelor create de
practici stabilite
• Creeaza un mediu deschis de
munca si incurajeaza feedback-
ul
• Evaluarea efortului si
mijloacele de recompensare
sunt bazate pe performanta
echipei
Avantaje SCRUM • Reduce nevoia pentru sedinte,
2 autorizatii si rapoarte
• Model iterativ care duce la o
livrare la fiecare 30 de zile
• Poate actiona ca un invelis
pentru practici aflate deja in
desfasurare
• Premisa de baza ca echipa este
dedicata proiectului.
– Daca echipa nu este dedicata
atunci procesul se prabuseste
• Nivelul de confort al
managementului in delegarea
de sarcini
• Impactul emotional datorat
Dezavantaje SCRUM esecului in cazul in care
proiectul nu se finalizeaza
• Marimea echipei este
restrictionata datorita
implicarii tuturor membrilor
echipei
• Potrivita pentru dezvoltarea de
noi produse
– nu pentru imbunatatirea unui
produs deja existent
• Bazat pe experienta
TEST DRIVEN
DEVELOPMENT
Test Driven Development
• “Test-driven Development is a programming
practice that instructs developers to write new
code only if an automated test has failed, and
to eliminate duplication. The goal of TDD is
clean code that works”
[Mansel&Husted: JUnit in Action]
• “Test Driven Development is the craft of producing
automated tests for production code, and using that
process to drive design and programming
• For every bit of functionality, you first develop a test

that specifies and validates what the code will do.
• You then produce exactly as much code as necessary to

pass the test. Then you refactor (simplify and clarify)
both production code and test code”
[Agile Alliance]
http://www.agiledata.org/essays/tdd.html
• Metoda de dezvoltare software TDD
– implica scrierea unor teste pentru verificarea
functionalitatilor componentelor aplicatiei.
– metoda des intalnita in companiile ce dezvolta
software.
– imbunatateste calitatea aplicatiei software.
• TDD impune creearea de metode de testare
inainte de construirea solutiei propriu zise.
• Se inspira din metodele Agile si din eXtreme
Programming (XP)
STUDIU DE CAZ
TDD
=
Test first
+
Automated (Unit) Testing
RED
GREEN
REFACTOR
GREEN
• TDD este o metoda in care se vor scrie intai
testele si apoi se va implememnta codul
propriuzis.
• Reprezinta o “intentie” de a realiza
• Testul va avea rol de specificatie a codului (Ce
face?)
• Testul este vazut ca o analiza a functionalitatii
sistemului
STUDIU DE CAZ
• Refactorizare
– restructurare,
– simplificare,
– imbunatatire
• Refactorizarea este o metoda foarte buna
pentru a descompune codul.
• Regression testing
– Codul nou si schimbarile facute pot afecta
functionarea aplicatiei
– “Affect” sometimes means “break”
– Regresie = revenire la o versiune precedenta
• Regression testing = testare a regresiei
codului
– Asigura stabilitatea aplicatiei
Avantaje
• Eficienta
• Imbunatatirea rezultatelor testarii
• Reducerea aparitiei defectelor
• Programatorul se ocupa si de testare
• Disponibilitate la schimbare
KANBAN
• Rather than focusing on being Agile which
may (and should) lead to being successful,
Kanban focuses on becoming successful,
which may lead to being Agile.
Kanban for Software Engineering

David Joyce
Kanban
• Kanban este un dispozitiv de semnalizare ( de regula un
card introdus intr-un plic transparent de plastic)
– contine intructiunile pentru mutarea sau crearea de parti
intr-un sistem de productie de tip “pull”
– inventat si dezvoltat ca parte a Toyota Production System
• Scopul Kanban este de a minimiza WIP
– WIP = Work-In-Process sau inventarul, intre procese
– procesul de constructie produce parti numai daca procesul
de consum are nevoie de ele.
• “Pull” inseamna ca lucratorii din linia de consum “trag”
partile de care au nevoie din procesele de asamblare.
Kanban
• In limba japoneza:
– Kan inseamna “semnal”
– Ban inseamna “card” sau “tabla”
• Un card Kanban reprezinta un semnal ce
determina o actiune
• Kanban se refera la un “card de semnalizare”
– Kanban exista pretutindeni. Data viitoare cand vei
comanda o cafea la un fastfood, vei remarca
implementat un sistem Kanban
– Paharul de cafea inscriptionat reprezinta sistemul
Kanban!
Kanban
• In timp ce aceasta este incorect din punct de vedere
tehnic, termenul de tabla Kanban a fost introdus in
vocabularul Agile si Software Development fiind deja
pus in uz.
• Kanban in productie reprezinta inspiratia din spatele
a ceea ce noi numim in prezent Kanban pentru
Ingineria Software.
INPUT Proces OUTPUT
Intrarea este determinata de iesire

https://norulesjustwords.files.wordpress.com/2012/04/from_push_to_pull.gif
Principii
Principiile de baza Kanban pentru Ingineria Software (1):
• Vizualizați fluxul de lucru
– impărțiți în componente,
– scrieți descrierea fiecarei componente pe un card și puneți-l
pe tabla KANBAN
– Utilizați coloane pentru a crea un flux de lucru.
– La inceput se aloca si respecta rolurile si responsabilitatile
• Limitați WIP
– stabiliți limite explicite pentru câte elemente pot fi în
desfășurare
– Incepe cu ce stii sa faci
– Valoarea Pull (cu limita pentru WIP)
Principii
Principiile de baza Kanban pentru Ingineria Software (2):
• Măsurați ciclul de dezvoltare
– timpul mediu pentru a finzliza o componenta,
– optimizați procesul pentru a reduce timpul.
– Proces de dezvoltare previzibil
• Cresterea eficientei
• Portofoliu Kanban fixat – KANBAN backlog
• Calitatea integrata in produs
– nu inspectata in produs
• Echipa monitorizeaza in mod continuu imbunatatirea
celor de mai sus
By Christoph Roser at AllAboutLean.com under the free CC-BY-SA 4.0 license.
PULL vs PUSH
Image copyright Christoph Roser on AllAboutLean.com.
A pull production system is one that explicitly limits the

amount of work in process that can be in the system. [...]
A push production system is one that has no explicit limit on
the amount of work in process that can be in the system.
(Hopp and Spearman "To Pull or Not to Pull")
Kanban - Desfasurare
• Vizualizarea mersului activitatii
– Imparte lucrul in bucati, scrie fiecare elemenet pe un card
si afiseaza-l pe perete
– Foloseste coloane pentru a ilustra unde se gaseste fiecare
element in cadrul fluxului activitatilor
• Limiteaza WIP (work in progress)
– atribuie limite explicite pentru cate elemente se pot
desfasura simultan pentru fiecare stare a activitatii.
• Masoara durata lead (durata medie pentru finalizarea
fiecarui element, denumita uneori “durata ciclului”)
• Optimizeaza procesul pentru a face acest inerval cat
mai mic si predictibil cu putinta.
Kanban - Desfasurare
• Vizualizarea mersului activitatii – tabela Kanban
– Colane din tabela Kanban: Backlog - Requirements - Design -
Development - Testing - Acceptance - Deploy – Support
– Elemente asociate unei componente: “Creation Date - Deadline
- Created by - Priority -Task Type - Description -Notes -
Definition or Requirements for “Complete/Finished” - History”
• Limitele WIP pentru fiecare fază a procesului,
– Se scriu deasupra coloanelor din tabela Kanban
• Echipa ar trebui să analizeze regulat in cadrul unor intalniri
– Metricile utilizate: timp …,
– ce au realizat,
– modificările necesare procesului
• Metoda Kanban nu propune un program pentru aceste
întâlniri.
Tabela Kanban
STUDIU DE CAZ
http://www.crisp.se/gratis-material-och-guider/kanban
Tabela Kanban STUDIU DE CAZ
Source: The Agileist

Tabela Kanban
Tabela Kanban
STUDIU DE CAZ
Tabela Kanban
STUDIU DE CAZ
Tabela Kanban
STUDIU DE CAZ
Tabela Kanban
STUDIU DE CAZ
Tabela Kanban
STUDIU DE CAZ
Tabela Kanban
STUDIU DE CAZ
MMF
• “Minimal Marketable Feature (MMF)”
– reprezinta un fragment de functionalitate care
indeplineste un sebset din cerintele clientului, si care
este capabila sa aduca valoare adaugata clientului
atunci cand este scoasa pe piata ca entitate
independenta
• M Denne & H Cleland-Huang, Software by Numbers
• Produsele software pot fi descompuse in MMF
– valoarea nu este perceputa ca un intreg, ci ca o serie
de caracteristici.
– functionalitatile sunt adesea livrate in mod separat.
– un produs software complex poate oferi valoare chiar
daca nu este complet.
Kanban
STUDIU DE CAZ
http://www.versionone.com/what-is-kanban/
Alegerea Ciclului de viata
• In functie de software
• Iterativ sau Incremental
• Intelegerea cerintelor ?
• Riscuri
• Deadline fix?
• Experienta echipei / clientului
Comparatie
Insusire a Modelului Cascada Code & Fix Spirala Cascada Prototip
Ciclului de Viata simpla modificat evolutiv
Lucreaza cu cerinte Slab Slab Excelent Acceptabil Excelent
putin intelese pana la
excelent
Lucreaza cu Slab Slab Excelent Acceptabil Slab pana la
arhitectura putin pana la acceptabil
inteleasa excelent
Produce sisteme cu Excelent Slab Excelent Excelent Acceptabil
grad mare de
siguranta
Produce un sistem cu Excelent Slab pana la Excelent Excelent Excelent
crestere extinsa Acceptabil
Gestioneaza riscurile Slab Slab Excelent Acceptabil Acceptabil
Poate fi constrans la Acceptabil Slab Acceptabil Acceptabil Slab
un program
predefinit
Comparatie
Insusire a Modelului Cascada Code & Fix Spirala Cascada Prototip
Ciclului de Viata simpla modificat evolutiv
Efort suplimentar mic Slab Excelent Acceptabil Excelent Acceptabil
Permite corectii Slab Slab pana la Acceptabil Acceptabil Excelent

intermediare excelent
Furnizeaza clientului Slab Acceptabil Excelent Acceptabil Excelent
vizibilitate asupra
progresului
Furnizeaza Acceptabil Slab Excelent Acceptabil Acceptabil

managementului pana la
vizibilitate asupra excelent
progresului
Grad de complexitate Acceptabil Excelent slab Slab pana la Slab

manager/dezvoltator acceptabil
Comparatie
Insusire a Modelului Staged Evolutionary Design to Design to COTS
Ciclului de Viata Delivery Delivery schedule tools
Lucreaza cu cerinte Slab Acceptabil Slab pana la Acceptabil Excelent
putin intelese pana la acceptabil
excelent
Lucreaza cu Slab Slab Slab Slab pana la Slab pana la
arhitectura putin excelent excellent
inteleasa
Produce sisteme cu Excelent Acceptabil Acceptabil Slab pana la Slab pana la
grad mare de pana la excelent excellent
siguranta excelent
Produce un sistem cu Excelent Excelent Acceptabil Slab N/A
crestere extinsa pana la
excellent
Gestioneaza riscurile Acceptabil Acceptabil Acceptabil Slab pana la N/A
pana la acceptabil
excellent
Comparatie
Insusire a Modelului Staged Delivery Evolutionary Design to Design to tools COTS
Ciclului de Viata Delivery schedule
Poate fi constrans la un Acceptabil Acceptabil Excelent Excelent Excelent
program predefinit
Efort suplimentar mic Acceptabil Acceptabil Acceptabil Acceptabil pana Excelent

la excelent
Permite corectii Slab Acceptabil pana Slab pana la Excelent Slab

intermediare la excelent acceptabil
Furnizeaza clientului Acceptabil Excelent Acceptabil Excelent N/A

vizibilitate asupra
progresului
Furnizeaza Excelent Excelent Excelent Excelent N/A
managementului
vizibilitate asupra
progresului
Grad de complexitate acceptabil Acceptabil Slab Acceptabil Acceptabil
manager/dezvoltator
Comparatie
Modelul Ciclului de Viata Metode Agile
Cerinte putin intelese Bun
Arhitectura putin inteleasa Slab
Produce sisteme cu grad mare de siguranta Acceptabil
Produce un sistem cu crestere extinsa Acceptabil
Gestioneaza riscurile Bun

Poate fi constrans de un program Bun
Efort suplimentar mic Bun
Permite corectii intermediare Bun
Vizibilitatea clientului Excellent

Vizibilitatea managerului Acceptabil
Gradul de complexitate manager/dezvoltator Slab

MP All

Î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

MP All

Încărcat de

Drepturi de autor:

Formate disponibile

Management de proiect - Curs 1

• Def. conform standardului SUA ANSI/PMI 99-001-2008

“Methodologies do not manage projects; people do.

Beneficii ale managementului de proiect:

Nivel tactic Nivel operational

Portofoliu (nivel strategic):

• Etapele managementului de portfoliu

Probleme ce trebuie adresate:

Analiza Analiza Selectare Prioritati

Etape Resurse Solutie tehnica Risc

▪ Sponsorul poate avea:

versus -Viziune incomplet asupra proiectului

Schita de proiect (project charter):

Contractul poate reprezentat schita de proiect

•De ce facem proiectul?

Schita Plan de Plan

iteratii Management de calitate Doc

iteratii Implementare activitati Livrabile

esec criuteriu de success ?

•Capacitate de a asculta •Integritate

• Tehnici de management: Aptitudini

Ideea proiectului si inovarea

Structurarea ideii de proiect

Structura unei organizatii este reprezentata sub forma

• Pozitiile de management dintr-o organizatie:

• Chief Information Officer (CIO)

chief chief business chief

chief chief information

• Dupa modul de organizare se pot enumera urmatoarele structuri:

Manager de Manager de Manager de

Organizare matriciala Manager

Divizie Divizie … Divizie

Exemplu: Proiect vs organizatie

• Proiectul poate incepe ca o:

• Inovația reprezinta atat procesul cat și rezultatul creării a ”ceva” nou,

• Inovația = Inventie + exploatare (Ettlie)

Astfel inovația a fost extinsa la:

inovarea? • deschiderea unei noi piețe,

Inovarea se poate realiza si prin combinare

• Inovarea la nivel de produs

• Inovarea la nivel de proces

• Inovarea la nivel de management

• Inovarea comerciala / de marketing

• Inovarea la nivel de servicii;

afacere • Poate fi descris prin 9 elemente de bază:

• Business Model Canvas

• Schita de proiect cuprinde urmatoarele:

Presupuneri Schita de plan

• Livrabil ( eng: deliverable )

• Managementul de continut ( eng: Project scope management )

• Declaratia de continut / descrierea proiectului : “scope statement”

Schimbare Raportare Monitorizare

Goals provide an overall philosophy, a concise statement to the purpose of

• Scopul proiectului este foarte important deoarece trebuie sa

• Un obiectiv este un câstig concret care trebuie obtinut dupa o

• “The project objective consists of the business benefits that an

• Obiectivele reprezinta afirmatii concrete ce descriu elementele ce

• O tehnica pentru formularea unui obiectiv este respectarea

Obiectivul proiectului este

– Exemplu: Obiectivul proiectului este cresterea vanzarilor companiei

At the end of the three-day training session (when),

to construct a new Art Gallery

Affect the level of art appreciation (what) within the local