Sunteți pe pagina 1din 67

Managementul Proiectelor Software

Universitatea Politehnica Bucureti


Facultatea de Automatic i Calculatoare
Catedra Calculatoare
Conf. Dr. Ing. Costin-Anton Boiangiu
costin.boiangiu@cs.pub.ro

Managementul Proiectelor Software


Capitolul 1. Introducere

INTRODUCERE

Cuprins Capitolul 1 - Introducere


Dimensiunea unui proiect software
Planificarea proiectului
Execuia proiectului
nchiderea proiectului
Procesul de dezvoltare
Particularitile proiectelor software
Noiuni de baz despre management
Etapele unui proiect

INTRODUCERE

Noiuni introductive
Un proiect software are dou dimensiuni principale:
Ingineria proiectului
Se ocup cu dezvoltarea efectiv a proiectului
Se concentreaz pe aspecte precum design, cod, testare

Managementul proiectului

Planificarea i controlul activitilor de inginerie n scopul


atingerii obiectivelor proiectului
Costuri
Timpi de execuie
Calitate

Dimensiunea unui proiect software


Proiecte mici :

Echipe mici
Durat de cteva sptmni
Testare efectuat de un numr redus de persoane
Metode informale de management i dezvoltare
email-uri
cteva termene limit
comunicare verbal, informal

Dimensiunea unui proiect software


Proiecte mari:
Echipe mari; durat cteva luni
Task-urile sunt efectuate cu atenie; metode bine cunoscute
Fiecare produs intermediar este documentat riguros i verificat
Task-urile sunt planificate i urmrite pas cu pas
Rigurozitate i formalitate crescut
Sunt folosite design pattern-uri pentru a permite aspectul unitar al codului i
a uura modificrile; de ex: MVP, MVC
Comunicarea poate avea loc att ntre membrii echipei, ct i cu clientul

INTRODUCERE

Proces
O secven de pai ce trebuie urmai pentru a executa cu
succes o activitate (un task):

mprirea aplicaiei n sub-task-uri i atribuirea acestora n


funcie de competenele fiecrui membru al echipei

ntr-o organizaie

Reunete experiena inginerilor i a managerilor de proiect

(experiena dobndit din execuia cu succes a unor proiecte anterioare).

Eseniale pentru

Planificarea cu succes a unui proiect


Pentru evitarea unor capcane ce pot duce la eecul
proiectului.

Task-urile se execut concurent

=> dup un interval de timp prestabilit, toi membrii echipei


au task-urile gata i le pot uni n aplicaia finalizat

INTRODUCERE

Avantajele utilizrii proceselor


Un cumul de cunotine colective
Rol esenial n estimarea succesului / eecului unui
proiect
Nici o organizaie nu poate nva din experienele trecute
fr a defini i folosi procese
Dac nu ai fi mprit aplicaiile precedente n procese
Ar fi foarte greu de gsit soluii pentru procesele actuale

Definirea a ceea ce trebuie fcut i cum = 80% din totalul


de munc ntr-un proiect obinuit (planificare)
Procese definite riguros => doar 20% (munc)

Procesul de management al
proiectului
Trei etape principale:
1

Planificarea proiectului

Execuia proiectului

nchiderea proiectului

INTRODUCERE

1. Planificarea proiectului
Activiti administrative i de pornire
Planificarea i orarul proiectului

Definirea obiectivelor proiectului


Estimarea costurilor i a efortului
Definirea unui plan de msurare a proiectului
Identificarea riscurilor i a modului de evitare / recuperare

Obinerea acordului de la managementul superior

Dac nu se obine aprobare trebuie regndit planificarea

Definirea i revizuirea planului de management al


configuraiilor
Realizarea unei echipe i stabilirea responsabilitilor
fiecruia

INTRODUCERE

poz

INTRODUCERE

poz

INTRODUCERE

poz

INTRODUCERE

1. Planificarea proiectului

Documentul Cerintelor Software (Software Requirements


Document - SRD):
Reflect punctul de vedere al dezvoltatorului cu privire la
produsul de dezvoltat
Furnizeaz o baz pentru estimarea costurilor i a
planificrii activitilor
Este folosit n testele de sistem

INTRODUCERE

poz

INTRODUCERE

poz

INTRODUCERE

poz

INTRODUCERE

2. Execuia proiectului
Execuia proiectului dup planul propus
Monitorizarea conformitii cu procesele definite
Analiza defectelor i efectuarea de activiti de prevenire
a acestora
Monitorizarea performaelor la nivel de program
Efectuarea de review-uri la anumite etape critice i
replanificarea unor etape dac este necesar
Monitorizarea progresului proiectului

INTRODUCERE

3. nchiderea proiectului
Analiza datelor post-proiect
Etapa are loc dup ce clientul i-a dat acceptul pentru
produsul final

n cazul n care clientul dorete modificri n aplicaie dup


finalizarea ei, trebuie s se poat rezolva rapid
Codul trebuie s fie inteligibil (bine comentat)

Se urmrete stabilirea unor concluzii ca urmare a


experienei acumulate, pentru a mbunti procesele
folosite n viitor
Trebuie meninut un istoric al modificrilor
Software versioning

Rezult ntr-un raport de nchidere a proiectului

INTRODUCERE

Principiile fundamentale n MPS


1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

Procesul de dezvoltare bazat pe arhitectur


Modul de dezvoltare iterativ
Principalele riscuri confruntate ct mai devreme
Dezvoltarea bazat pe componente
Plan de management al schimbrilor
Model de evaluare bazat pe demonstraii
Coobiectiv al calitii i evaluarea corect a progresului
Notaii bazate pe modele
Procesul de dezvoltare configurabil i scalabil economic
Versiunile intermediare avnd nivele de detaliu din ce n ce mai
mari

INTRODUCERE

1. Procesul de dezvoltare
bazat pe arhitectur
Componentele arhitecturale - nelese foarte bine nainte
de a lua n considerare amnuntele de detaliu
Cerinele de la client trebuie nelese corect

Gradul de refacere / abandon a unor componente ar


trebui s scad sau s rmn constant n timpul
desfurrii unui proiect
Atenie sporit acordat arhitecturii la nceput
=> realizarea unei fundaii solide pentru 20% din elementele
responsabile de succesul proiectului (cazuri de utilizare,
erori, riscuri, etc.)

INTRODUCERE

2. Modul de dezvoltare iterativ


Framework de planificare ct mai dinamic
Exist mai multe prototipuri ale produsului

Scopul fiecrei iteraii este de a produce un rezultat


executabil prin care se pot demonstra o parte dintre
functionalitile viitorului produs
cu ct o iteraie este mai scurt cu att se obine feedback
mai repede

Rezolvarea problemelor critice foarte devreme

=> Dezvoltare mai predictibil & mai puine surprize


=> Expunerea la surse de cost i/sau ntrzieri neprevzute
reduse la maxim

Exemple: AGILE

INTRODUCERE

poz

INTRODUCERE

3. Principalele riscuri confruntate ct mai


devreme
Framework de planificare ct mai dinamic
+
Proces de dezvoltare iterativ
=> Management al riscului mult mai bun

Rezolvarea problemelor critice foarte devreme


=> Dezvoltare mai predictibil & mai puine surprize
=> Expunerea la surse de cost i / sau ntrzieri neprevzute
reduse la maxim

The sooner you begin coding the


later you finish.

poz

INTRODUCERE

4. Dezvoltarea bazat pe componente

Complexitatea dezvoltrii de software


Direct proporional cu numrul de elemente generate de
ctre membrii echipei

Diminuarea numrului acestora

Diminuarea complexitii procesului de management


Trebuie gsit echilibrul

INTRODUCERE

5. Plan de management al schimbrilor


Dinamica dezvoltrii iterative
Fluxurile de lucru concurente ale diferitelor echipe de
dezvoltare care folosesc aceleai componente
necesit linii de referin controlate foarte riguros

Verific cine e afectat de schimbarea pe care urmeaz s o


faci nainte s modifici!
Toat echipa trebuie s urmeze un tipar similar

INTRODUCERE

poz

INTRODUCERE

6. Model de evaluare bazat pe demonstraii


Integrarea apare foarte devreme n viaa unui proiect i se
continu pe parcursul ntregului proces de dezvoltare.
Rezultatele intermediare sunt elemente eseniale,
deoarece sunt tangibile i obiective

Fiecare component este testat individual (module driver i


ciot de la IP)

La final:
Componentele se mbin i
se testeaz din nou

INTRODUCERE

7. Evaluare obiectiv a calitii i corect a


progresului
Calitatea = totalitatea caracteristicilor prin care el
satisface o serie de necesiti definite sau impuse
Capacitatea de a putea fi folosit eficient i confortabil de ctre utilizatori

Indicatorii de progres i calitate deriv direct din


componentele dezvoltate
ofer informaii importante n legatur cu trendul proiectului
i gradul de corelare al produsului cu cerinele iniiale
standardul ISO: fiabilitate, funcionalitate, eficien,
uurin de utilizare / ntreinere, portabilitate

INTRODUCERE

poz

INTRODUCERE

poz

INTRODUCERE

8. Notaii bazate pe modele

Utilizarea unor notaii inginereti n faza de design va


conduce la un control mai bun al complexitii, evaluri
intermediare mai obiective i mai corecte, precum i
analize ce pot fi automatizate

INTRODUCERE

9. Procesul de dezvoltare configurabil i


scalabil economic

Experiena Metodele

Uneltele

Tehnicile

trebuie folosite mpreun pentru a lrgi segmentul de


pia int
=> o ntoarcere a investiiei mult mai mare

INTRODUCERE

10. Versiunile intermediare avnd nivele de


detaliu din ce n ce mai mari
Cerinele unui proiect
Designul

trebuie s evolueze concomitent

Planificarea

Versiuni intermediare ce pot fi utile sunt de obicei


disponibile foarte devreme n timpul procesului de
dezvoltare

Good project management is not so


much knowing what to do and when, as
knowing what excuses to give and when.

"TODO: add functionality to show alert text after too


many tries at log in"
"make sure we don't try to do this before the saml
has been posted if (window.
registrationInitialSessionCallsComplete)"
"Attention: This file is generated once and can be
modified by hand"
"Fill In this with actual content. Lorem Ipsum"
"TODO: maybe modify the below to use a similar
method instead"

1. Sprints and Iterations Do Not an 'Agile' Project Make

Multe echipe folosesc "sprint" sau "iteration", doar pentru a introduce concepte agile.
Cuvinte cum ar fi "trei sprinturi de arhitectura, sase sprinturi de cod, doua sprinturi de
testare si dou sprinturi de mentenanta" este, de obicei, un indiciu ca ceva e n neregul.

2. The System Produced the Outcome, Not the Lack of Testing

Atata timp cat nu sunt bine definite fazele proiectului, nu ai cum sa stii unde te aflii. O
mare greseala a fost ca de la gasirea unui bug, se intra in faza de fixare.

3. Testing Should Be Part of the Delivery Process

Daca testarea nu are loc in procesul de dezvoltare atunci e pierdere de timp.

4. Do It Manually Before You Automate

Inaintea automatizarii proceselor de testare asigura-te ca manual au fost cu succes.

INTRODUCERE

Particularitile proiectelor software


Ce este un proiect?
Un proiect este in fapt o activitate planuita, nerepetitiva, ale
carei principale caracteristici sunt urmatoarele:
Planificarea
Activitile nu urmresc o anumit rutin
Anumite obiective trebuie atinse i anumite produse trebuie
realizate
Exist o durat de timp predeterminat (absolut sau relativ)
Munca este realizat n mai multe etape
Resursele disponibile au anumite constrangeri

Un proces - o serie de activiti numeroase i complexe

INTRODUCERE

Proiecte Software (Particulariti)


Invizibilitate - spre deosebire de un pod sau un drum care
sunt construite i progresul este vizibil imediat, n cazul
unui produs software progresul nu neaparat este evident
foarte repede
Complexitate - Produsele software sunt unele dintre
produsele cu cea mai mare complexitate per euro/dolar/lei
investii
Flexibilitate - Uurina cu care un produs software poate
fi modificat este unul dintre cele mai importante atu-uri
ale acestui tip de proiecte

INTRODUCERE

Categorii de produse software


Sisteme informaionale vs. sisteme embedded
n cazul sistemelor informaionale, produsul software are
interfete cu organizatia; sistemele embedded au interfete cu
alte masini.
Exemple:
Sistem informatic: sistem de gestiune a stocului
Sistem embedded: sistem de control automat al aerului
conditionat ntr-un depozit

INTRODUCERE

Categorii de produse software


Obiective vs produse

INTRODUCERE

Categorii de produse software


Obiective vs produse
Produsele software scopul: a crea un anumit produs, sau de a
atinge un anumit obiectiv.
Prima: urmrete
recomandarea unei
soluii software pentru a
satisface anumite cerine

A doua: dezvoltarea efectiv a


produsului software

INTRODUCERE

Proiectul ca un sistem
A. Sisteme, subsisteme i medii
B. Sistem = o mulime de pri interconectate
C. Orice sistem ns este de obicei parte a unui alt sistem,
moment n care reprezint de fapt un subsistem.
Mediul = tot ceea ce se afl n afara sistemului
- este reprezentat de toate elementele care:
1. pot influena sistemul
2. dar asupra crora sistemul n cauz nu are nici un control

INTRODUCERE

Sisteme deschise vs. sisteme nchise

INTRODUCERE

Sisteme deschise vs. sisteme nchise


Sisteme deschise
sunt acelea care interacioneaz cu mediul
exterior.
majoritatea sistemelor aparin acestei
categorii;
cele mai multe probleme n procesul de
dezvoltare a unui produs software fiind
chiar o urmare a incapacitii
dezvoltatorilor de a realiza ct de deschis
este un sistem n realitate

INTRODUCERE

Sisteme deschise vs. sisteme nchise


Sisteme nchise
sunt sisteme care nu interacioneaz cu mediul
i nu sunt influenate de acesta; doar
componentele din cadrul lor au importan
partea bun n organizarea sistemelor inchise
este sigurana c structura lor rmne aceeai
responsabilitile sunt distribuite ntotdeauna la
fel
este foarte puin flexibil i nu suport
modificri
fluxul de informaii este foarte mic i se
transmite numai ierarhic

INTRODUCERE

Sisteme sociotehnice
Orice proiect software necesit organizare:
din punct de vedere tehnologic
din punct de vedere al resurselor umane.

Ca urmare

managerii de proiect trebuie s aib


cunotine tehnice
capacitatea de a comunica eficient cu oamenii.

The first myth of management is that it


exists.

INTRODUCERE

Noiuni de baz
Ce este managementul?
Managementul implic urmtoarele activiti:

Planificarea

Organizarea

Monitorizarea

Controlul

Inovaia

Reprezentarea

Conducerea

Organizarea
personalului

INTRODUCERE

Noiuni de baz

respectarea termenelor
limit

Obinerea de accepturi
din partea
managementului
superior

rezolvarea conflictelor

managementul
constrngerilor asupra
resurselor

Principalele
probleme cu care se
confrunt un
manager

respectarea planului de
proiect stabilit de ctre
echip

comunicarea efectiv
cu membrii echipei

motivarea personalului

managementul
schimbrilor

stabilirea de obiective
realistice i msurabile

INTRODUCERE

Management?

INTRODUCERE

Management?

INTRODUCERE

Management?

INTRODUCERE

Management?

INTRODUCERE

Principalele probleme

INTRODUCERE

Principalele probleme
Atribuirea greit a persoanelor i a sarcinilor
Definirea unor termene limit i a unor planuri nerealiste
Ineficiena comunicrii ntre membrii echipei sau a
comunicrii cu clientul
Schimbrile aprute n cerinele iniiale sau n mediul de
dezvoltare
Lipsa tehnicilor i a resurselor necesare (umane,
financiare, etc.)

INTRODUCERE

Principalele probleme (2)


Alegerea unor criterii de reuit greite
Lipsa controlului calitii
Lipsa unei viziuni i a unor inte bine definite
Lipsa cunotinelor despre domeniul de aplicare a
produsului
Lipsa de standarde i msurtori privind calitatea

INTRODUCERE

Stakeholders
Persoanele care au un anumit interes n proiect
Trei categorii principale:

Trei pai:
identific prile interesate
prioritizeaz prile interesate
identific prile interesate principale

INTRODUCERE

Stakeholders (2)

INTRODUCERE

Participanii la proiect
Determin gradul de succes al proiectului
Deseori se pot afla n stare tensionat i chiar conflictual
Cunoaterea de ctre managerul de proiect a tuturor
participanilor ct i a rolului i a ateptrilor acestora va
duce la gsirea soluiilor de compromis care s nu
blocheze derularea proiectului i finalizarea sa

INTRODUCERE

Participanii la proiect (2)


Este bine s se deosebeasc din categoriile participanilor
participanii cheie, cei care vor determina gradul n care
proiectul finalizat a ntmpinat ateptrile participanilor
sau nu
Participanii implicai n proiect, pot fi persoane fizice sau
juridice

The life cycle of a troubled project

INTRODUCERE

Recapitulare
Proiect software
Ingineria proiectului
Managementul proiectului

Proces
Planificarea proiectului->Execuia proiectului>nchiderea proiectul
Riscuri
Modele
Sisteme
Participanii la proiect

INTRODUCERE

Mulumesc