Managementul proiectelor

Curs, anul II Calculatoare

Instructori:
Prof.dr.ing. Mihai Mocanu

Asist.dr.ing. Anca Ion

E-mail: mocanu@software.ucv.ro
Cabinet 303
Consultaii: Miercuri 12:00-14:00
Pagina curs: http://software.ucv.ro/~mocanu_mihai/
(folosii intrarea corespunztoare curs, cerei user si passw)

Fundamente necesare
Comunicare si Internet
Proiectare si programare procedurala
Programare structurata
Proiectare si programare orientata pe obiecte
Algoritmi si structuri de date
Metode si tehnici de programare
Inginerie software*

Obiectivele cursului
Intelegerea necesitatii mngm. proiectelor IT
Introducerea conceptelor generale de team
work si team building in inginerie
Descrierea elementelor ce formeaza cadrul PM
Consolidarea cunotinelor tehnice

nelegerea diferenei: program vs. produs software

Abilitatea de a proiecta si implementa (sub)sisteme:
orice proiect mic tb sa poata fi integrat ulterior intrun proiect mare
Abilitatea de a reconstrui si analiza proiectarea unui
sistem software existent

Obiective (cont.)
Introducerea temelor etice si profesionale in
ingineria software
Introducerea metodelor avansate de dezvoltare
software si evitarea erorilor conceptuale
nsuirea cunotinelor manageriale necesare

tiina de a produce un sistem software de mare

calitate in cadrul unui buget (cost si timp) alocat...
...in condiii de complexitate mare si schimbri frecv.

Confruntarea cu realitile domeniului

Atingerea stadiului de excelenta in inginerie
software

Structura cursului
Introducere, concepte generale

Ce este un proiect, produs, proces software?

Care este contextul dezvoltrii software?

Zone de cunotine/ procese in managm. de proiect

Procese de dezvoltare software

Modele generice: cascada (waterfall); transformri formale ale

specificaiilor; dezvoltri evolutive, iterative, incrementale;
procese agile, XP
Definirea unui proces de dezvoltare software

Procese Rational(e) si UML (Unified Modeling Language)

Studii de caz si exemple

Referine bibliografice (incl. web-based)

A Guide to the Project Management Body of Knowledge
(PMI Standards), 1996, 2004

Guide to the Software Engineering Body of Knowledge

(SWEBOK), 2001
Erich Gamma, Richard Helm, Ralph Johnson, John
Vlissides - Design Patterns: Elements of Reusable
Object-Oriented Software, Addison-Wesley, 1996
Ian Sommerville - Software Engineering, 7th Ed., 2004
Ph. Kruchten The Rational Unified Process -An
Introduction, Addison-Wesley, 1999
Alistair Cockburn Agile Software Development, 2nd Ed.,
Addison Wesley, 2001
Alte materiale gasiti pe pagina cursului (sect. Resurse)

Notarea
20% teste de evaluare continua (T)
20% activitate (teme, referate) (A)
20% evaluare continua la laborator (L)
40% examen prin lucrare scrisa (E)
Trebuie s obinei cel puin 50% (cate 10 p) la
evalurile continue (de tip T, A sau L) pentru a putea
susine examenul scris (E).
Trebuie sa acumulai apoi cel puin 50% din punctajul
aferent lucrrii scrise E (20 p) pentru a promova
examenul.

Introducere
I.

Necesitatea managementului de
proiect IT
II. Concepte generale de teamwork
III. Dezvoltare software si management

Istoria lansarii unui proiect*

Vineri seara: Directorul general al companiei se
gandeste, inainte de a pleca sa vizioneze meciul
echipei preferate din loja sa de la stadion, ca ar fi
bine sa aiba un nou sistem de contabilitate. Il suna
pe Hank, de la IT noul departament ce ocupa
etajul inferior in sediul companiei, si il informeaza
pe scurt ce vrea, adaugand la final Oh, and by the

way, this means that you are the project manager

for this assignment. It would be great if you could
start on Monday. Have a nice weekend.

Actiunea de vineri seara

Tipul de la IT guy se uita fix la telefonul din
mana sa. Este foarte confuz: Care nou sistem
de contabilitate? Ce-i aia manager de proiect?
Care luni? Dupa primul pachet de sase, mai
tarziu, in aceeasi seara, lucrurile se limpezesc
si Hank se simte mult mai relaxat. Sigur ca
poate face asta. Va obtine un sistem. Il va
instala. Nimica toata. Dupa cateva telefoane
luni dimineata proiectul va porni singur. In
timp ce isi toarna inca un rand de brewskie,
Hank se simte plin de putere.

Luni dimineata
Luni, Hank contacteaza mai intai departamentul
de contabilitate, sa-si faca o idee precisa despre
ceea ce trebuie obtinut. Will any accounting

system serve the purpose, or do they need a

specific kind? Who knows? Dar luni dimineata
lucrurile nu merg chiar dupa plan. Hank ramane in
biroul celor 5 colegi contabili pentru 4 ore, si pe
masura ce trece timpul are din ce in ce mai putin
idee despre ceea ce se discuta. Tot ce a obtinut in
urma acestei intalniri sunt alte nume in alte 5
departamente ce folosesc sistemul curent de
contabilitate

Luni dupa-amiaza
numele din 7 companii ce schimba informatii cu
acest sistem, si 3 biblioraft-uri enorme cu dosare,
memo-uri, documente, xerox-uri, si foi scrise de
mana ce exprima exact de ce are nevoie
departamentul de contabilitate. Hank isi petrece
restul zilei de luni stabilind contacte cu cele 5
departamente si 7 companii. Dupa aceasta scurta
runda de comunicare, poate adauga alte 20 de
nume potentiale la lista celor ce vor avea de-a
face cu noul sistem de contabilitate, cu care
trebuie sa discute.

Luni seara
Reflectand la toate evenimentele zilei, Hank se
hotaraste sa schimbe abordarea pentru ziua
urmatoare
Mai intai, se va uita chiar in sistemul contabil
aflat in exploatare si cu siguranta isi va face mai
rapid o idee despre ce se vrea
De asemenea, va discuta si cu colegii sai din
departamentul IT si-I va ruga sa-l ajute sa puna
proiectul pe drum drept.

Marti
Hank ia de la departamentul IT alte 2 dosare mari ce
contin politicile de implementare: ce tehnologii si
arhitecturi trebuie sa utilizeze noul sistem, ce
documentatie de suport trebuie inclusa etc.
Oh, si in plus inca 10 nume de persoane ce ar putea
avea ceva de zis despre noul sistem
Concluzie: Un proiect care a inceput atat de simplu
un om, o cerinta, dupa doar 2 zile s-a transformat in
ceva nefiresc de mare; Hank are deja o lista cu peste
40 de persoane ce trebuie implicate si consultate si 5
bibliorafturi cu dosare continand ceva mai mult sau
mai putin apropiat de cerintele unui sistem!

Esenta mngm.de proiect, in gen.

A sti care este dinamica unui proiect, cum si de
ce lucreaza oamenii = 80% acoperire
Trebuie sa ne punem la punct cu partea tehnica
si sa incepem sa progresam
O problema de care trebuie insa tinut cont in
derularea unui proiect este ca sunt implicate mai
multe persoane, cu interese diferite, ale caror
cerinte trebuie satisfacute
Resursele (bani, timp, oameni) sunt insa limitate
In final, mngm. de proiect este un joc de stabilire
a prioritatilor si de negociere a compromisurilor

Problema specifica a mngm.software

Fapte:
Creterea costurilor software, concomitent cu
scderea preului hardware-ului !
Software-ul poate face aproape orice !?

Flexibilitatea sa e lucrul cel mai bun / cel mai rau ?

Flexibilitatea software-ului determina dificultatea

managementului (planificare, monitorizare, control)
Creterea costurilor de meninere a software-ului
fata de cele de dezvoltare - este oare de dorit ca
sistemele software sa aib un ciclu de viata lung?

Problema mngm.pr.softw (cont.)

Lipsa de predictibilitate a fost baza crizei software
din anii 70 inreg. pentru majoritatea proiectelor:
Calitate inacceptabila

Insatisfacia clienilor

Depirea bugetelor

Depirea termenelor

Funcionalitate eronata sau redusa

Documentaie inexistenta

Rspunsul
Impunerea unor modele de dezvoltare
software mai riguroase
Apariia succesiva, analiza critica si
evoluia paradigmelor de programare
(structurata, funcionala, OO etc.)
Dezvoltarea tehnicilor de testare
Aparitia ingineriei software, ca domeniu
de interes si disciplina de predare!

II. Concepte generale de teamwork

Care sunt principalele probleme legate de
lucrul in echipe

Definitii
Ce nelegei prin termeni ca:

echipa

echipa de proiect?

ncercai sa definii, lucrnd eventual cu

colegul de lng voi, in timp scurt, aceti
termeni

Definiii tipice
O echipa poate fi definita ca grup de persoane ce
lucreaz mpreuna pentru atingerea unui scop comun
O echipa de proiect, in inginerie, poate fi definita ca
grup de ingineri cu nsuiri complementare in mod
tipic multi-disciplinare ce sunt dedicai unui scop
comun si care rspund solidar pentru rezultate

Inginerii lucreaz in general in echipa deci, pentru

ca rezultatele muncii lor sa fie cele dorite, echipele
trebuie sa fie bune
Din nou, ncercai sa gasiti 5 argumente, pentru care
trebuie sa avem echipe si acestea trebuie sa fie bune

De ce este necesar o echipa?

Asigurarea conducerii
mprirea responsabilitilor
Abiliti mai numeroase si variate
mprirea sarcinii de lucru
Direcionarea capabilitilor spre un
domeniu
Asigurarea sinergiei
Existenta unui scop comun
Mai buna fundamentare a deciziilor

Ce implic lucrul in echipa

Participare efectiva la proiectarea in colaborare
Asumarea sarcinilor de lucru ca simplu membru
al unei echipe de proiect
Asumarea diferitelor roluri
Crearea si urmrirea unui plan de proiectare si
testare
Crearea ntregului set de documente asociate cu
un produs software
Terminarea unui proiect la timp

Exista motive pentru care NU ar

trebui sa lucram in echip?
Unele proiecte nereuite au fost atribuite
eecului lucrului in echipa
Deci echipele de proiect pot sa nu fie bune,
ntotdeauna
De ce?

ncercai sa gsii 5 motive, lucrnd cu cine

dorii timp de alte 2 min., pentru care echipele
de proiect nu pot fi ntotdeauna bune

De ce NU ntotdeauna in echipa?
Management defectuos
Lipsa de eficacitate
Lipsa de scop
Definirea proasta a rolurilor
Posibilitatea apariiei conflictelor
Comoditatea sociala/lipsa responsabilizrii
Timpi de decizie prea lungi

Un exemplu de eec
A team (of students ) had four members called Everybody,

Somebody, Anybody and Nobody. There was an important

job to be done. Everybody was sure that Somebody would do
it. Anybody could have done it, but Nobody did it. Somebody
got angry about that because it was Everybodys job.
Everybody thought Anybody could do it but Nobody realized
that Everybody wouldnt do it. It ended up that Everybody
blamed Somebody when Nobody did what Anybody could
have done.
Adapted from Gibbs, G. (1994) Learning in Teams: A Student
Guide. Great Britain: Oxford Centre for Staff Development. p7

Metode de constituire a echipelor

Asignarea membrilor de ctre un supervizor (profesorul)
Auto-asignarea

Avantaje: pot fi alei colegi cu afinitati comune, cu orar comun

Dezavantaj: necunoaterea sau supraestimarea abilitailor
proprii sau ale celorlali
Soluie: (auto)evaluarea

Alocarea aleatoare
Pe baza setului de competente necesar unui task
Pe baza locaiei apropiate

Avantaj: facilitarea ntlnirilor

Pe baza domeniului (topicilor) de interes

Dezvoltarea si performanta echipei

Pe msura lucrului la proiect(e), echipele pot
evolua dup o curba de tipul urmtor:

III. Dezvoltarea software

Relaia cu domeniile Project Management
si Software Engineering

FAQs - PM si SE (1)
Ce este software-ul? Categorii software
Ce nelegem prin inginerie software?
Care este diferena intre termenii software
engineering si computer science?
Care este diferena intre termenii software
engineering si system engineering?
Sunt necesare metodologii de dezvoltare si
pot fi elaborate modele de procese software?

Dezvoltarea software
Software = programe + documentaia asociata
Software-ul difer de obiectele materiale prin uurina

Copierii
Modificrii

Produsele software pot fi dezvoltate pentru:

Un client particular
Un segment de piaa general

Produsele software pot fi:

Generice dezvoltate pentru a fi vndute unor categorii

de clieni destul de largi/ diverse
Customizate dezvoltate pentru o singura categorie de
clieni conform cu specificaiile

Categorii de software

Libertatea (de expresie, distribuie)

Groupware software care permite unui grup de
oameni sa partajeze date sau sa urmreasc
informaii comune prin: email, BBS, Usenet,
chat, messenger, wiki etc.
Public Domain software fara
drepturi de autor, pe care oricine
l poate folosi; poate fi utilizat si
modificat fara restricii
Vezi:
http://www.gnu.org/philosophy/categories.html
http://www.opensource.org/

Preul
Freeware

Software gratuit
Are drepturi de autor
Poate avea restricii in modificare, redistribuire
Nu poate fi vndut

Shareware

Are drepturi de autor

Utilizat gratis o perioada de proba pe baza unui acord
Nu poate fi vndut, dar poate fi copiat si redistribuit
$0 shareware = free for non-commercial use,
poate fi asimilat cu freeware

Software liber (free software)

Caracterizat de libertate de expresie, nu de pre
1. Libertatea de a utiliza programul, n orice scop
2. Libertatea de a studia modul su de funcionare i de a-l

adapta nevoilor proprii

3. Libertatea de a redistribui copii, n scopul ajutorrii
colegiale
4. Libertatea de a mbunti programul, i de a difuza
mbuntirile, n folosul public

Accesul la codul surs este precondiie pentru 2 & 4

Aceste liberti sunt reale, dac sunt i irevocabile,
ct timp utilizatorii nu comit vreo fapt ilegal

Discuie
"Software liber" nu nseamn "non-comercial"

Un program liber poate fi utilizabil n scop comercial,

disponibil pentru dezvoltare i distribuie comercial

"Software comercial" nu nseamn proprietar

Exist software comercial liber dpdv al codului surs, ce

se poate modifica
Exist software non-comercial proprietar, ce nu se poate
modifica

OPIONAL: Putem organiza periodic ntlniri pentru a

dezbate unele dintre aceste probleme (posibil cursurile 4-6)


nscrieri prealabile (2 persoane/tema, pro si contra)


Exemple: open-source vs public-domain software
sau software-ul trebuie sa fie free sau nu sau
software-ul free este mai bun etc.