UNIVERSITATEA POLITEHNICA BUCUREŞTI

FACULTATEA DE AUTOMATICĂ ŞI CALCULATOARE

DEPARTAMENTUL CALCULATOARE

PROIECT DE DIPLOMĂ
Gestiunea Proiectelor

Coordonator ştiinţific: Absolvent:

Prof. dr. ing. Florin Rădulescu Balaș Ioan-Alexandru

BUCUREŞTI
2014
 Cuprins
1. Introducere ..................................................................................................................................... 6
1.1 Prezentarea contextului ........................................................................................................... 6
1.2 Scopul lucrării ............................................................................................................................ 6
1.3 Sumar ........................................................................................................................................ 7
2. Prezentare generală ....................................................................................................................... 8
2.1 Proiect ....................................................................................................................................... 8
2.2 Cerință ...................................................................................................................................... 8
2.3 Gestiunea proiectelor ............................................................................................................... 9
2.4 Etapele unui proiect ............................................................................................................... 11
2.4.1 Identificare ............................................................................................................... 11
2.4.2 Planificare................................................................................................................. 11
2.4.3 Implementare .......................................................................................................... 11
2.4.4 Monitorizare și control............................................................................................. 12
2.4.5 Încheiere .................................................................................................................. 12
2.5 Abordări ale dezvoltării produselor software ........................................................................ 14
2.5.1 Modelul Waterfall .................................................................................................... 14
2.5.2 Modelul Agile ........................................................................................................... 14
2.5.2.1 Etapele unei iterații Agile ...................................................................................... 15
2.6 Soluții software de gestiune a proiectelor .............................................................................. 16
2.6.1 Jira ............................................................................................................................ 16
2.6.2 Mantis BT ................................................................................................................. 16
3. Arhitectură și proiectare .............................................................................................................. 17
3.1 Clasa User ................................................................................................................................ 17
3.1.1 Rolurile utilizatorului ................................................................................................ 17
3.2 Clasa Project ............................................................................................................................ 18
3.2.1 Stările unui proiect ................................................................................................... 19
3.3 Clasa Task ................................................................................................................................ 19
3.3.1 Prioritatea unei cerințe ............................................................................................ 19
3.3.2 Tipul unei cerințe ..................................................................................................... 20
3.3.3 Starea unei cerințe ................................................................................................... 20
3.4 Clasa Note ............................................................................................................................... 20
3.5 Clasa Attachemen.................................................................................................................... 21
3.6 Clasa Post ................................................................................................................................ 21
3.7 Clasa Comment ....................................................................................................................... 22
4. Detalii de implementare .............................................................................................................. 24
4.1 Modelul de proiectare MVC .................................................................................................... 24
4.2 Implementarea bazei de date ................................................................................................. 24
4.2.1 Entity Framework ..................................................................................................... 25
4.2.1.1 Code First .............................................................................................................. 25
4.3 Implementarea funcționalităților ............................................................................................ 27
4.3.1 LINQ.......................................................................................................................... 28
4.3.2 Rolul clasei Account ................................................................................................. 28
4.3.3 Rolul clasei FileUpload ............................................................................................. 29
4.3.4 Rolul clasei Home ..................................................................................................... 29
4.3.5 Rolul clasei Note....................................................................................................... 30
4.3.6 Rolul clasei Project ................................................................................................... 30
4.3.7 Rolul clasei Task ....................................................................................................... 30
 4.3.8 Implementarea modulului de comunicare ............................................................. 31
4.3.8.1 SignalR ................................................................................................................... 32
4.3.9 Implementarea modulului de statistică ................................................................... 32
5. Testare și evaluare ....................................................................................................................... 34
6.Concluzie și viitoare îmbunătățiri .................................................................................................. 36
6.1 Concluzie ................................................................................................................................ 36
6.2 Viitoare îmbunatățiri . ............................................................................................................. 36
Lista imaginilor

Fig. 1 Tipuri de dependență a cerințelor ..................................................................................... 9

Fig. 2 Etapele unui proiect ....................................................................................................... 13
Fig. 3 Etapele unei iterații Agile................................................................................................ 15
Fig. 4 Modificarea stării unei cerințe ........................................................................................ 20
Fig. 5 Diagrama bazei de date .................................................................................................. 23
Fig. 6 Modul de comunicare .................................................................................................... 31
Fig. 7 Exemplu de reprezentare grafică a statisticilor................................................................. 33
Fig. 8 Notă și scor performanțe ................................................................................................ 34
Fig. 9 Statistici YSlow............................................................................................................... 34
Fig. 10 Notă și scor performanțe – după optimizare .................................................................. 35
Fig. 11 Statistici YSlow – după optimizare ................................................................................. 35

Lista tabelelor
Tab. 1 Ariile gestiunii proiectelor ............................................................................................. 10
Tab. 2 Descrierea rolurilor unui utilizator ................................................................................. 18

Lista listărilor
List. 1 Structura clasei Project .................................................................................................. 25
List. 2 Script SQL de creare a tabelei Project ............................................................................. 25
List. 3 Exemplu de folosire FluentAPI ....................................................................................... 26
List. 4 Structura clasei AppContext........................................................................................... 26
List. 5 Detaliile bazei de date ................................................................................................... 27
List. 6 Structura clasei BaseController ...................................................................................... 27
List. 7 Încărcarea cerințelor folosind LINQ ................................................................................ 28
List. 8 Declararea unui pachet de script-uri JS ........................................................................... 35
 5

Abstract

Nevoia de a mări rata de succes a proiectelor a determinat realizarea unui set de tehnici
ce au ca scop planificarea din timp a pașilor necesari pentru atingerea rezultatului dorit și
gestiunea fiecărui pas pentru a putea lua cele mai bune decizii atunci când situații neașteptate
au loc. Această lucrare are ca scop prezentarea unui proiect ce oferă funcții esențiale atunci când
vine vorba de gestiunea proiectelor.
 6

CAPITOLUL 1

Introducere
1.1 Prezentarea contextului

Majoritatea proiectelor pot începe ca simple cerințe ce par a fi ușor de îndeplinit însă, pe
măsură ce dezvoltarea avansează, situații neașteptate pot îndruma un proiect spre eșec.
Incapacitatea de a înțelege cerințele unui client, clienți ce nu au un scop exact, depășirea bugetului,
nerespectarea termenelor limită sau modificarea acestora, sunt elemente ce pot determina starea
finală a unui proiect. În funcție de modul de abordare al fiecărei firme, proiectele pot fi încheiate cu
succes chiar daca unul sau mai multe din elementele enumerate își fac apariția în una din etapele
dezvoltării proiectului.

Pentru a ușura munca persoanelor responsabile cu succesul unui proiect, a fost creeat un
set de tehnici și abilități ce sunt recunoscute în general ca practici bune atunci când vine vorba de
realizarea unui proiect reușit. Popularitatea actuala a tehnicilor de gestiune a proiectelor este o
dovadă a eficienței lor atunci când vine vorba de îndeplinirea cerințelor unui proiect, indiferent de
complexitatea acestuia. Gestiunea proiectelor a devenit una din etapele obligatorii atunci când este
necesară realizarea unor proiecte de calitate înaltă, respectând termeni limită impuși de client,
indiferent de domeniu.

Cu toate că sunt recunoscute în general ca practici bune, aplicarea tuturor tehnicilor de

gestiune a proiectelor nu întorc aceleași rezultate pentru toate proiectele. Datorită numarului mare
de domenii ce au ca scop realizarea de proiecte și a diverșilor factori precum: dimensiunea, timpul
necesar realizării, structurii echipelor de dezvoltare, etc. , este necesară realizarea unei evaluări ce
va avea ca rezultat alegerea tehnicilor ce se potrivesc cel mai bine cu problema propusă.

1.2 Scopul lucrării

Pentru a ușura munca echipei de gestiune a proiectelor și a managerului de proiect, au fost
realizate soluții software ce permit planificarea, organizarea și monitorizarea proiectelor. În funcție
de complexitatea proiectului pot fi folosite programe de gestiune a proiectelor ce oferă
funcționalități mai complexe precum gestiunea bugetului, gestiunea calității sau gasirea căii critice a
unui proiect.

Scopul acestei lucrări este realizarea unei aplicații software web ce ofere unei echipe
mijloacele necesare pentru a duce un proiect la bun sfârșit.
 7

1.3 Sumar

Capitolul 2 răspunde unor întrebări precum: Ce este un proiect? Ce este o cerință? Care
sunt etapele unui proiect? Ce abordări există în industria software atunci când vine vorba de
gestiunea proiectelo? Ce produse software folosite în scopul gestiunii proiectelor există pe piață?

Capitolul 3 va prezenta arhitectura aplicației și câteva detalii legate de proiectarea

acesteia

Capitolul 4 cuprinde detalii legate de implementarea aplicației: soluții software folosite,

modul în care acestea funcționează, funcționalități oferite utilizatorului

Capitolul 5 prezintă rezultate obținute de aplicație în în urma rulării unor teste de

determinare a performanței aplicațiilor web

Capitolul 6 va cuprinde concluzia la care s-a ajuns după încheierea dezvoltării aplicației și
moduri în care aceasta poate fi îmbunătățită pe viitor
 8

CAPITOLUL 2

Prezentare generală
2.1 Proiect
Termenul de proiect este folosit pentru a descrie un ansamblu de elemente ce au ca scop
obținerea unui produs sau a unui serviciu. Datorită nevoii de a obține un rezultat, un proiect este
încadrat într-o perioadă finită de timp, având stabilite o data de start și o data de stop. Această
perioadă de timp poate varia, în funcție de complexitatea proiectului, de la perioade scurte de timp
(un număr de zile) până la perioade lungi sau foarte lungi de timp (ani de zile).

Cu toate că termenul de proiect este destul de general, rezultatele obținute la finalul

fiecăruia sunt unice. Chiar dacă două proiecte au ca scop obținerea unui rezultat asemănător, ele
diferă ca și context: o altă echipă, alte unelte puse la dispoziție, alt buget, etc.

Se poate spune că un proiect a fost încheiat cu success atunci când s-a ajuns la rezultatul
dorit în perioada de timp stabilită. Nerespectarea termenelor limită și alți factori precum:
înțelegerea greșită a cerințelor clientului, calitatea scăzută a lucrului realizat, neînțelegeri între
membrii unei echipe ce dezvoltă o parte a proiectului, depășirea bugetului, etc. pot determina
încheierea unui proiect ce nu întoarce rezultatul dorit.

2.2 Cerință

Lucrul în echipă este o componentă importantă a unui proiect, permițând dezvoltarea în

paralel a unor părți distincte ale acestuia. Pentru a facilita lucrul în echipă, proiectele sunt împărțite
în cerințe. Cerințele reprezintă activități ce trebuiesc îndeplinite pentru a se ajunge la un rezultat.
Îndeplinirea tuturor cerințelor duce la încheierea cu success a proiectului.

Cerințele sunt atribuite unei echipe iar aceasta trebuie sa le îndeplinească înaintea
termenului limită. Având în vedere faprul că realizarea unui proiect este limitată de timp ,și cerințele
sunt încadrate într-un interval definite de o data de start și o data de stop . Nerespectarea
termenelor limită pot avea consecințe grave asupra întregului proiect.

Făcând parte dintr-un proiect, cerințele nu pot fi întotdeauna privite ca entități

independente. De multe ori se poate întâmpla ca doua sau mai multe cerințe să împartă un set de
resurse ce pot cuprinde echipe, servicii, unelte, etc. . De aceea este important să se ia în calcul toate
modurile prin care cerințele depind unele de altele pentru a putea determina cea mai bună ordine
de abordare a lor.

În figura de mai jos se pot observa patru moduri în care cerința B poate depinde
de cerința A:
 9

 FS: Cerința B nu poate începe înainte ca Cerința A sa fie încheiată

 SS: Cerința B nu poate începe până când cerința A nu a început
 SF: Cerința B nu poate fi încheiată până când Cerința A nu a început
 FF: Cerința B nu poate încheiată până când Cerința A nu a fost încheiată

Fig. 1 Tipuri de dependență a cerințelor

Un exemplu în care o cerință B nu poate începe fără ca cerința A sa se fi încheiat este cel în
care cerința A reprezintă implementarea iar cerința B reprezintă testarea implementării. O echipă nu
poate începe testarea finală a unei funcționalități până când aceasta nu a fost considerate încheiată.

Datorită dependențelor, nerespectarea termenelor limită pentru una din cerințe poate avea
ca efect întârzierea tuturor celorlalte cerințe, ducând la necesitatea recalcularii intervalelor alocate
sau, în unele cazuri, la încheierea proiectului. Pentru a putea evita sau ameliora efectul unor astfel
de situații, se folosesc tehnici de gestiune a proiectelor.

2.3 Gestiunea proiectelor

Gestiunea proiectelor reprezintă aplicarea cunoștințelor, abilităților, uneltelor și tehnicilor

de planificare a activităților pentru a duce un proiect la bun sfârșit. Funcțiile gestiunii proiectelor
includ preziviune, organizare, direcționare, coordonare, control și evaluare.

Principalele obiective ale gestiunii proiectelor sunt:

 identificarea cerințelor
 luarea în calcul a nevoilor și îngrijorarilor clientului pe parcursul dezvoltării
proiectului
 echilibrarea constrângerilor legate de buget, timp, calitate, pentru a putea oferi un
produs final bun

Datorită diferitelor elemente ce sunt implicate în realizarea unui proiect precum timp, cost,
calitate, activități, oameni, etc., gestiunea acestuia poate părea un lucru dificil. Pentru a-l ușura,
gestiunea proiectelor este împărțită în mai multe arii de expertiză, așa cum se poate observa în Tab.
1. Deși pot părea separate la început, ariile sunt strâns legate între ele, modificări produse în una din
ele putând influența negativ (sau pozitiv) o altă arie sau chiar pe toate. Spre exemplu, decizia de a
 10

reduce costul poate avea impact negativ asupra timpului alocat proiectului. Reducând timpul,
calitatea nu poate rămâne aceeași , fiind necesare compromisuri.

Arie a gestiunii Descriere

proiectelor
Integrare Principalul scop al acestei arii este să identifice și să coordoneze toate celelalte arii.
Anticiparea diverselor probleme, rezolvarea lor, alegeri legate de alocarea resurselor și
realizarea compromisurilor în cazul unor obiective concurente, sunt câteva din lucrurile
concrete realizate de această arie a gestiunii proiectelor.
Scop Determinarea lucrurilor necesare pentru a putea termina proiectul și împărțirea în
1
cerințe a proiectului. Toate acestea sunt trecute în documentul WBS (work breakdown
structure) ce are o importanță foarte mare pe tot parcursul proiectului.
Timp Identificarea activităților, ordonarea lor în funcție de dependențe, estimarea resurselor
pentru fiecare activitate, estimarea duratei unei activități și realizarea
programului(orar). Realizeaza și controlul asupra programului.
Cost Se ocupă cu planificarea și estimarea costurilor pentru a putea respecta bugetul.
Calitate Identificarea standardelor de calitate ce se aplică proiectului și modul de implementare
a acestor standarde. Monitorizarea calității și identificarea factorilor ce duc la scăderea
acesteia precum și aplicarea activităților de menținere a calității.
Resurse umane Această arie se ocupă cu organizarea și gestiunea echipei ce va lucra la proiect. Echipa
de gestiune a proiectelor face parte din echipa proiectului. Sunt identificate roluril
necesare și recrutate persoane calificate pentru a ocupa aceste roluri. Este urmărit
nivelul de performanță a membrilor echipei, se colectează feedback-ul și se
coordoneaza schimbări pentru a mări eficiența echipei.
Comunicare Scopul acestei arii este de a identifica informațiile necesare bunei funcționări a
proiectului și oferirea acestor informații în timp util persoanelor ce au nevoie de ele.
Risc Realizarea unui plan ce identifică riscuri ce pot afecta proiectul, dar și soluții pentru
rezolvarea fiecurui risc identificat.
Achiziție Achiziția de servicii, bunuri necesare realizării activităților proiectului.

Tab.1 Ariile gestiunii proiectelor

Pentru a putea realiza o gestiune cât mai completă a unui proiect, este recomandată
implicarea întregii echipe în procesul de management. Chiar dacă echipa de management este
specializată în tehnici de gestiune a proiectelor, se poate întâmpla ca membrii acesteia să nu fie
destul de familiarizați cu elemente extrem de specifice ale actualului proiect și evaluarea lor să nu fie
apropiată de realitate.Implicând beneficiarii în gestiunea scopului proiectului va micșora posibilitatea
ca cerințele acestora sa fie înțelese greșit și îi va face mai încrezători în reușita proiectului.

Gestiunea timpului alocat proiectului este una din ariile în care prezența echipei de
dezvoltare este necesară. Impunând termene limită fără a cunoaște capacitatea unei echipe de a le
respecta poate creea tensiuni în interiorul ei daca timpul acordat este mult prea mic sau poate
micșora eficiența ei atunci când timpul acordat este mult prea mare. Discutând împreună cu
membrii echipei atunci când se determină intervalul stabilit pentru fiecare din cerințe, poate avea ca
rezultat obținerea unor timpi realiști, atunci când fiecare membru al echipei își cunosc capacitațile și
limitările.

1
https://www.workbreakdownstructure.com/
 11

Managerul de proiect este persoană răspunzătoare de succesul proiectului și de aceea este

una din cele mai importante componente ale unei echipe. El este implicat pe tot parcursul procesului
de gestiune a proiectului și de aceea este necesar ca acesta că cunoască elementele specifice fiecărei
arii implicate. Rolul său este mult mai important la începutul unui proiect atunci când este necesară
realizarea planului ce va expune toți pașii necesari pentru a îndeplini toate cerințele beneficiarilor.

Datorită importanței sale, un manager de proiect poate fi persoana ce determină succesul

sau eșecul unui proiect. Incapacitatea de a înțelege cerințele beneficiarilor, lipsa legăturii cu echipa
de dezvoltare și cunoașterea acesteia precum și alegeri slabe atunci când intervin situații
neașteptate sunt câteva din caracteristicile unui manager ce nu poate duce un proiect la capăt
respectând restricțiile de cost, timp și scop.

2.4 Etapele unui proiect

Fiecare proiect este caracterizat de un ciclu de viață ce reprezintă intervalul de timp în care
proiectul trece de la faza de idee la faza finală, în care contractul este încheiat. Abordarea generală
atunci când vine vorba de ciclul de viață al unui proces cuprinde cinci etape(procese).

2.4.1 Identificare

În această etapă se decide începerea unui nou proiect și un manager de proiect este ales.
Sunt identificați clienții și scopul proiectului este definit.

Rezultatul acestei etape este un document ce conține scopul, obiectivele, principalii

clienți/beneficiari și rolurile participanților. Acceptarea acestui document reprezintă autorizarea
formală a proiectului.

2.4.2 Planificare

Etapa de planificare are ca scop estimarea efortului necesar finalizării proiectului, definirea
și detalierea obiectivelor și acțiunile necesare pentru îndeplinirea lor. Această etapă trebuie să ia în
calcul elemente ce fac parte din toate ariile de gestiune, precum costul, timpul, calitatea, etc.

Pe măsură ce sunt descoperite noi elemente sau cerințe ale unui proiect, partea de
planificare suferă modificări. Sunt necesare evaluări repetate de fiecare dată când intervin
modificări, procesul de planificare fiind unul iterativ.

2.4.3 Implementare

Această etapă impune coordonarea resurselor și a persoanelor implicate în proiect pentru

a se ajunge la rezultatul dorit. Aici sunt implementate și integrate cerințele proiectului, așa cum sunt
prezentate în planul proiectului.

În această etapă pot interveni cele mai multe schimbări. Aceste schimbări pot fi
determinate de întâlnirea unui risc neprevăzut, modificări aduse timpului acordat uneia din cerințe
sau resurse ce devin indisponibile sau limitate. Fiecare din aceste modificări impune realizarea unei
noi analize și găsirea unei noi soluții ce poate schimba planul proiectului.
 12

2.4.4 Monitorizare și control

Etapa de monitorizare și control cuprinde procesele ce au ca scop identificarea din timp a

posibilelor probleme ce pot apărea în timpul dezvoltării proiectului și luarea măsurilor ce duc la
redresarea procesului de implementare.

Procesul de monitorizare este unul continuu, oferind echipelor metode de identificare a

stării proiectelor prin intermediul rapoartelor, măsurării progresului și a prezicerilor viitoarelor
puncte cheie ale proiectului. Raportarea include de obicei informații legate de timp, starea actuală a
cerințelor sau noi riscuri identificate.

2.4.5 Încheiere

Etapa finală a oricărui proiect presupune acceptarea de către beneficiari a rezultatului

obținut și încheierea formală a tuturor activităților ce țin de proiect. La finalizarea unui proiect este
necesară realizarea unui document ce conține informații legate de noi riscuri întâlnite și lecțiile
învățate în timpul dezvoltării proiectului. Acest document are ca scop îmbunătățirea proceselor de
gestiune a viitoarelor proiecte ale echipei.
 13

Fig.2 Etapele unui proiect

 14

2.5 Abordări ale dezvoltării produselor software

2.5.1 Modelul Waterfall

Modelul Waterfall este primul model de dezvoltare software folosit la scară largă. Este un
model liniar ce necesită finalizarea unei etape pentru a putea trece la următoarea.

Principalele etape ale acestui model sunt:

 definirea cerințelor
 proiectarea sistemului
 implementarea
 testarea
 realizarea mentenanței

Denumirea Waterfall provine de la modul linear în care etapele proiectului “curg”,

rezultatul unei etape fiind folosite ca date de intrare pentru următoarea etapă.

Acest model de dezvoltare este adoptat în special atunci când proiectul este unul de scurtă
durată, în care nu există variabile când vine vorba de cerințe iar cadrul dezvoltării este unul fix.
Principalele avantaje ale acestui model sunt simplitatea, ușurința de înțelegere, terminarea pe rând
a fiecărei etape fără ca acestea să se suprapună, prezența unei documentații detaliate.

Modelul Waterfall nu este recomandat pentru dezvoltarea unor proiecte de lungă durată.
Fiind liniar, modelul nu oferă un rezultat decât la terminarea ciclului, în cazul proiectelor mai mari
aceasta însemnând dupa luni sau ani de zile. Acest lucru implică asumarea unor riscuri extrem de
mari, identificarea unei probleme neprevăzute ne putând fi tratate în timp util.

2.5.2 Modelul Agile

Modelul Agile reprezintă un set de practici recomandate ce sunt bazate pe iterații și

dezvoltare incrementală. Un proiect este împărțit în iterații a căror durată poate varia de la una până
la 4 săptămâni. Rezultatul fiecărei iterații este o componentă software funcțională ce poate fi oferită
beneficiarilor mijloacele de a urmări dezvoltarea proiectului îndeaproape pentru a putea evalua și
oferi feedback.

Spre deosebire de modelul Waterfall, Agile nu impune dezvoltarea unei documentații

riguroase sau planificarea în detaliu a fiecărei cerință. Documentația este minimă iar planificarea se
face la începutul fiecărei iterații și expune doar funcționalitățile ce trebuiesc implementate în
actualul ciclu. Modul de implementare rămâne la latitudinea echipei care va reacționa în mod
dinamic la schimbările ce pot apărea în interiorul unei iterații.
 15

2.5.2.1 Cele 12 principii ale modelului Agile2

I. Satisfacerea nevoilor clientului prin oferirea continuă a produselor software de

calitate
II. Acceptarea modificării cerințelor chiar și în etapele finale de dezvoltare
III. Oferirea frecventă de software funcțional
IV. Cooperarea între dezvoltatori și cei ce se ocupă de partea financiară
V. Proiectele sunt dezvoltate de indivizi motivați
VI. Comunicarea față în față a informațiilor în cadrul echipei de dezvoltare
VII. Principalul element ce poate cuantifica progresul unui proiect este software-ul
funcțional
VIII. Păstrarea unui ritm constant atunci când vine vorba de dezvoltarea software
IX. Atenția acordată unui design bun
X. Simplitate
XI. Echipe ce se pot organiza singure
XII. Adaptarea modului de muncă pentru a spori eficiența

2.5.2.1 Etapele unei iterații Agile

Etapele unei iterații sunt: planificarea, analiza cerințelor, proiectare, dezvoltare, testare (unit
testing și test de acceptare).

Fig.3 Etapele unui iterații Agile

Deși popularitatea modelului Agile continuă să crească, acest model nu poate fi aplicat pe
toate proiectele. Lipsa unui manager de proiect ce deține cuoștințele necesare dezvoltării după

2
http://agilemanifesto.org/principles.html
 16

modelul Agile poate crea haos în cadrul echipei de dezvoltare. Lipsa documentației crează o
dependență individuală puternică și face dificilă introducerea unor noi membri ai echipei ce nu sunt
familiari cu tehnologia dezvoltată. Având în vedere faptul că interacțiunea cu beneficiarii este unul
din principiile de baza Agile, eventuale neclarități legate de cerințele acestora pot îndruma
dezvoltarea unui proiect pe calea greșită.

Se poate observa că atât modelul Agile cât și modelul Waterfall au avantaje și dezavantaje
însă este dovedit faptul că, atunci când modelul ales este cel ce se potrivește cel mai bine unui
proiect, rata de succes a acestuia crește considerabil. Este datoria managerului de proiect să decidă
ce model de dezvoltare software se mulează cel mai bine pe tipul proiectului și pe abilitățile echipei
de dezvoltare.

2.6 Soluții software de gestiune a proiectelor

Pentru a ușura procesul de gestiune a proiectelor, au fost dezvoltate produse software ce

pot ajuta la organizarea cerințelor și a bugetului, planificarea proiectului, comunicarea între membrii
echipei, monitorizarea stării proiectului și raportarea diverșilor parametri. Variind de la soluții
disponibile ca programe PC sau ca aplicații web, ele sunt folosite în majoritatea mediilor de afacere.

Câteva exemple de produse software de management a proiectelor sunt: Jira, Clarizen,

Mantis BT, AtTask.

2.6.1 Jira

Jira este un produs software dezvoltat în Java de Atlasian, încă din 2002. Principalele
funcționalități oferite sunt: notificări email, introducerea și modificarea cerințelor, adăugarea de noi
proiecte, changelog, raportare, adăugarea de atașamente, sistem de workflow, etc.

Unul din cele mai mari avantaje ale Jira este faptul că aplicația poate fi folosită atât local,
folosind baza de date și puterea de procesare a clientului cât și ca SaaS (Software as a Service),
păstrarea datelor și procesarea lor fiind realizate pe serverele Jira.

Produsul este unul web, varianta locală fiind independentă de platforma pe care rulează
datorită dezvoltării în Java.

2.6.2 Matins BT

Mantis Bug Tracker este un produs software specializat pe bug tracking însă poate fi folosit și
ca ajutor pentru gestiunarea proiectelor. Este o aplicație web dezvoltată în PHP, ce poate fi rulată pe
majoritatea sistemelor de operare. Funcționalitățile oferite de Mantis sunt: notificări email,
introducerea și modificarea cerințelor, changelog, audit și raportare, etc.

Principalul avantaj Mantis este disponibilitatea sa, produsul putânt fi descărcat și instalat de
oricine.
 17

CAPITOLUL 3

Arhitectură și proiectare
Realizarea unei aplicații software de gestiune a proiectelor necesită introducerea
elementelor esenșiale procesului de gestiune și a unei interfețe simple și ușor de folosit pentru a
permite utilizatorilor accesul către toate funcționalitățile oferite.

3.1 Clasa User

Utilizatorul aplicației este beneficiarul principal al acesteia. El este cel ce interacționează cu

toate celelalte elemente, oferind informații legate de proiecte sau cerințe și, folosindu-se de
informațiile introduse de ceilalți utilizatori, determină următorii pași ce sunt necesari pentru a
permite proiectului să îndeplinească obiectivele propuse.

Un utilizator este caracterizat de:

 Idendificator unic: permite identificarea utilizatorului în interiorul aplicației
 Nume de utilizator: folosit la autentificare și afișarea în interfață a activitățillor
realizate de acest utilizator. Identificatorul unic este mult mai folositor în partea de
cod însă, pentru interfață, este nevoie de un identificator mai prietenos
 Parolă: în combinație cu numele de utilizator, este folosită pentru autentificarea
utilizatorului atunci când acesta dorește să folosească aplicația.
 Email: folosit pentru trimiterea notificărilor
 Nume și Prenume: informații formale
 Stare: poate lua una din două valori: activ sau inactiv; Un utilizator inactiv nu va
putea trece de procesul de autentificare, chiar daca combinația nume utilizator și
parolă este cea corectă
 Rol: tipul de acces pe care un utilizator îl are la nivelul aplicației

3.1.1 Rolurile utilizatorului

Indiferent de numărul de proiecte în care un utilizator este implicat, rolul acestuia este dat la
nivel de aplicație. Folosind această abordare, nu vor exista confuzii în privința gradului de acces pe
care un utilizator îl are atunci când interacționează cu aplicația, fiecare utilizator având atribuit un
singur rol.

Există 4 roluri ce pot fi atribuite unui utilizator:

 Administrator  Programator
 Manager de proiect  Reporter
 18

Rol Descriere
Administrator Cel mai important rol atribuit unui utilizator. De obicei există un singur utilizator în
interiorul unei aplicații ce deține acest rol.
Principalele drepturi deținute de un administrator: modificare informații utilizatori
(adresă email, nume, prenume), schimbarea stării unui utilizator, schimbarea rolului
unui utilizator, vizualizarea tuturor utilizatorilor.
Deține toate drepturile rolurilor ce au grad de prioritate mai mic.
Manager de proiect În interiorul aplicației pot exista mai mulți utilizatori ce dețin acest rol.
Principalele drepturi deținute de un manager de proiect : introducerea de noi proiecte,
3
editarea stării unui proiect .
Deține toate drepturile rolurilor ce au grad de prioritate mai mic.
Programator Rolul atribuit celor mai mulți utilizatori din interiorul aplicației.
Principalele drepturi deținute: adăugarea de noi cerințe, editarea cerințelor,
schimbarea stării unei cerințe, adăugarea de note, adăugarea de atașamente,
4
atribuirea ce cerințe unui utilizator .
Deține toate drepturile rolurilor ce au grad de prioritate mai mic.
Reporter Rolul de reporter este atribuit utilizatorilor ce au ca scop identificarea unor noi cerințe
și informarea echipei de dezvoltare .
Principalele drepturi deținute de un reporter: adăugarea de noi cerințe și atribuirea
acestora;
Împreună cu toate celelalte roluri, reporterii dețin dreptul de a folosi interfața de
comunicare.
Tab.2 Descrierea rolurilor unui utilizator

3.2 Clasa Project

De cele mai multe ori o aplicație are de gestionat mai multe proiecte în același timp,
numărul acestora depinzând de tipul și dimensiunea firmei în care este folosită. O firmă de produse
software poate avea în lucru zeci de proiecte, pe când una de construcții poate avea un singur
proiect activ. Pentru a putea permite gestiunea unor proiecte multiple, este necesară izolarea
acestora.

Un proiect este caracterizat de:

 Identificator unic: folosit pentru identificarea în cod a proiectului
 Nume unic: permite identificarea unui proiect în interiorul interfeței
 Descriere: poate conține informații detaliate legate de scopul proiectului și modului
de abordare sugerat de manager
 Stare
 Dată creare: reprezintă data la care proiectul a fost introdus în sistem
 Identificator utilizator: legătura cu utilizatorul ce a introdus proiectul în sistem

3
Un manager de proiect poate schimba doar starea unui proiect ce a fost creat de el
4
Cerințele nu pot fi atribuite utilizatorilor ce dețin rolul administrator sau reporter
 19

3.2.1 Stările unui proiect

Orice proiect poate trece printr-un total de 3 stări: deschis, suspendat și închis. Pentru a
permite adăugarea de noi cerințe și modificarea acestora, un proiect trebuie să fie deschis.
Suspendarea acestuia va bloca posibilitatea modificării componentelor până când va fi redeschis.
Închiderea unui proiect este permanentă și blochează posibilitatea modificării oricărui aspect al
proiectului.

3.3 Clasa Task

Unul din primii pași recomandați de tehnicile de gestiune a proiectelor este împărțirea unui
proiect în cerințe. Rezolvarea tuturor cerințelor unui proiect reprezintă încheierea acestuia cu
succes.
Împărțirea în cerințe oferă posibilitatea dezvoltării în paralel a funcționalităților unui proiect.

O cerință este caracterizată de:

 Identificator unic: folosit pentru identificarea în cod a unei cerințe
 Nume: identifică cerința în interfață
 Descriere: conține descrierea detaliată a problemei sau a funcționalității ce trebuie
implementată/rezolvată pentru a putea avansa în procesul de dezvoltare al
proiectului
 Dată creare: reprezintă data la care cerința a fost introdusă în sistem
 Dată modificare: ultima dată la care au fost făcute modificări asupra cerinței
 Tip acces: poate fi privat sau public. O cerință privată poate fi vazută și editată doar
de către persoana ce a raportat-o sau de persoana căreia i-a fost atribuită
 Dată start estimată: data la care se estimează că va începe dezvoltarea. Respectarea
acestei date crește șansele de reușită ale acestei cerințe
 Dată stop estimată: dată la care se estimează că cerința va fi rezolvată.
Nerespectarea acestei date ar putea determina decalarea datei de start/stop a
celorlalte cerințe ce depind de statusul cerinței actuale sau de resurse pe care
aceasta le folosește (ex. membri ai echipei)
 Timp total estimat: reprezintă numărul de minute ce utilizatorul a estimat că vor fi
necesare pentru finalizarea cerinței
 Timp real: reprezintă timpul petrecut de persoana căreie i-a fost atribuită cerința în
vederea rezolvării ei. Pentru a calcula acest timp se însumează timpul trecut în toate
notițele adăugate unei cerințe.
 Identificator proiect: folosit pentru a identifica proiectul căruia îi aparține cerința
 Identificator user reporter: legătura cu utilizatorul ce a introdus cerința în sistem
 Identificator user atribuit: legătură cu utilizatorul căruia i-a fost însărcinată cerința
 Prioritate
 Tip
 Stare

3.3.1 Prioritatea unui cerințe

Pentru a putea aborda cerințele în funcție de importanța lor, a fost introdus un sistem de
priorități ce cuprinde 5 stări. Aceste stări sunt: prioritate foarte mică, mică, normală, mare, foarte
mare.
 20

Având două cerințe ce se suprapun ca și interval de dezvoltare, cea cu prioritatea mai mare
va fi aleasă ca cerință principală, cât timp ea nu depinde de finalizarea cerinței cu prioritate mai
mică. În caz contrar, prioritatea cerinței mai mici ar trebui ridicată la cel puțin aceeași prioritate ca
cerința ce depinde de ea.

3.3.2 Tipul unei cerințe

Datorită complexității unui proiect, cerințele acestuia nu pot fi considerate ca fiind identice
ca și tip. Unele cerințe presupun rezolvarea unei probleme întâlnite în timpul procesului de
dezvoltare, altele necesită implementarea unei noi funcționalități sau îmbunătățirea unui anumit
aspect al proiectului. Cele 3 tipuri ce pot caracteriza o cerință sunt: bugfix, îmbunătățire,
funcționalitate nouă.

Tipul unei cerințe este pur informativ însă, în funcție de componența echipei de dezvoltare,
poate căpăta un rol mai important. În cadrul unei echipe de dezvoltare pot exista grupuri de
persoane specializate pe rezolvarea bug-urilor întâlnite în aplicație sau pe optimizarea și
introducerea de noi funcționalități. Atribuind tipul corect de cerință echipei ce este specializată pe
acel tip, crește probabilitatea ca cerința sa fie rezolvată în timp util.

3.3.3 Starea unui cerințe

Stările ce îi pot fi atribuite unei cerințe sunt: succes, eșec, deschis, închis. Decizia proiectării
unui sistem cu 4 stări a fost luată pentru a oferi un modul de raportare mult mai detaliat atunci când
vine vorba de cerințe.

Cerințele aflate în lucru sunt marcate cu starea deschis pentru a permite editarea. Starea
închis este folosită pentru a semnala oprirea dezvoltării cerinței. În orice moment această stare
poate fi schimbată pentru a permite reluarea activităților de editare.

Fig. 4 Modificarea stării unei cerințe

Așa cum se poate vedea din Fig. 4, stările succes și eșec sunt finale. Marcarea unei cerințe cu
una din ele va bloca posibilitatea modificării acesteia. În acest fel, cerințe raportate ca fiind încheiate
cu succes vor fi identificate ca atare în toate celelalte rapoarte.

3.4 Clasa Note

Notițele reprezintă marcarea muncii depuse de către un programator pentru rezolvarea unei
cerințe. Atunci când s-au făcut progrese sau o anumită perioadă de timp a trecut, utilizatorul
 21

marchează aceste evenimente adăugând o notiță cerinței la care a lucrat. Adăugarea notițelor nu
este limitată doar utilizatorului căruia i-a fost atribuită cerința ci tuturor utilizatorilor ce dețin acest
drept.

O notiță este compusă din:

 Identificator unic: folosit pentru identificarea în cod a unuei notițe

 Identificator cerință: legătura cu cerința căreia i-a fost adăugată notița
 Titlu: numele dat notiței
 Descriere: informații legate de timpul petrecut pentru realizarea activității ce
urmează să fie notată. Aici sunt detaliate toate progresele înregistrate în timpul
petrecut realizării activității.
 Nume utilizator: numele utilizatorului ce a contribuit la munca depusă pentru
îndeplinirea cerinței
 Dată creare: data introducerii în aplicație
 Timp petrecut: numărul de minute petrecute de utilizator pentru a realiza
activitatea notată

Suma timpului înregistrat în notițelor unei cerințe va determina timpul real petrecut pentru
a finaliza cerința.

3.5 Clasa Attachment

Unul din cele mai importante roluri ale unui software de gestiune a proiectelor îl reprezintă
partajarea fișierelor. Datorită importanței planificării, documentele rezultate din această etapă
reprezintă baza pentru dezvoltarea oricărui produs software. Rolul de a face disponibile aceste
documente tuturor persoanelor implicate în dezvoltarea unei cerințe este îndeplinit de atașamente.

Un atașament cuprinde:
 Identificator unic: folosit pentru identificarea în cod a unuei notițe
 Identificator cerință: legătura cu cerința ce va conține noul atașament
 Cale fișier: calea la care atașamentul va fi salvat pe server
 Nume fișier: folosit pentru afișarea în interfață

Orice membru al echipei poate încărca sau descărca atașamente.

3.6 Clasa Post

Comunicarea între membrii unei echipei permite răspândirea mult mai ușoară a informațiilor
vitale bunului mers a proiectului. Calitatea muncii realizate de o echipă crește atunci când informații
și experiențe folositoare sunt împărțite între membrii ei. Comunicarea între membrii unei echipe va
fi realizată prin intermediul postărilor și a comentariilor.

O postare cuprinde:
 Identificator unic: folosit pentru identificarea în cod a unuei notițe
 Mesaj: informația
 Nume utilizator: numele utilizatorului ce a adăugat postarea
 22

 Identificator utilizator: legătura cu utilizatorul ce a adăugat postarea

 Dată adăugare: data la care postarea a fost adăugată

3.7 Clasa Comment

Comentariile reprezintă principalul mod de a oferii feedback unui utilizator ce a adăugat o

postare. Un comentariu poate conține o observație adusă unei postări sau noi detalii legate de
informația cuprinsă î interiorul unei postări.

Un comentariu cuprinde:
 Identificator unic: folosit pentru identificarea în cod a unuei notițe
 Mesaj: informația
 Nume utilizator: numele utilizatorului ce a adăugat comentariul
 Identificator postare: postarea căreia îi va fi adăugat comentariul
 23

Fig. 5 Diagrama bazei de date

 24

CAPITOLUL 4

Detalii de implementare
În acest capitol vor fi prezentate detaliile legate de implementarea tuturor componentelor
aplicației (bază de dată, acțiuni, interfață) și modului în care acestea interacționează.

4.1 Modelul de proiectare MVC

MVC (Model View Controller5) este un model de proiectare ce împarte aplicația în trei
componente distincte:
 Model: componenta logică a aplicației
 View: componenta ce se ocupă cu afișarea informațiilor
 Controller: componenta ce preia comenzile utilizatorului, procesează informațiile cerute
folosind modelul și întoarce rezultatul prin intermediul unui view corespunzător

Este un model foarte popular datorită ușurinței cu care permite testarea fiecărei
componente în parte și potențialului ce îl oferă dezvoltării în paralel, de către echipe diferite, a unei
singure aplicații.

Aplicația a fost proiectată folosind modelul MVC datorită clarității ce îl oferă structurii unui
proiect software și ușurinței cu care fiecare componentă poate fi testată individual. Implementarea
bazei de date este realizată prin intermediul modelelor și a clasei ce creează contextul bazei de date.
Interacțiunea cu utilizatorul se face prin intermediul controllerelor iar interfața este servită de către
view-uri.

4.2 Implementarea bazei de date

Datorită complexității aplicației, o abordare tradițională ,în care partea de cod și partea ce
ține de baza de date sunt complet separate, este ineficientă. Atunci când structura unei clase se
modifică, tabelele ce conțin informațiile ce țin de această clasă trebuiesc și ele modificate manual,
lucru ce necesită multă muncă și poate determina strecurarea greșelilor. Popularea unei obiect cu
informațiile din interiorul bazei de date este anevoioasă, fiind necesară folosirea unui obiect ajutător
precum DataSet sau DataTable pentru a putea aduce informațiile în cod și popularea
obiectului final parcurgând setul întors.

Pentru implementarea bazei de date și a modulului de comunicare cu aceasta, aplicația

folosește EntityFramework.

5
http://msdn.microsoft.com/en-us/library/dd381412%28v=vs.108%29.aspx
 25

4.2.1 Entity Framework

Entity Framework este o platformă ORM (Object Relational Mapping) ce permite

dezvoltatorilor să lucreze într-un mod mult mai eficient cu baza de date.

4.2.1.1 Code First

Folosind abordarea code first, întreaga structură a bazei a fost definită în cod, folosind
modelele de bază ale claselor User, Project, Task, Note, Attachment, Post și Comment. Fiecare din
aceste clase păstrează structura gândită în partea de proiectare.

public class Project

{
public int id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
public DateTime CreatedOn { get; set; }
public ProjectState State { get; set; }
public int CreatedByUser { get; set; }
public User CreatedBy { get; set; }
public List<Task> Tasks { get; set; }
}
List. 1 Structura clasei Project

În List. 1 este prezentată clasa Project scrisă în limbajul C#. Se poate observa că proprietățile
clasei sunt tipuri specifice C# (int, string, DateTime) sau alte obiecte (Users, Task). Există un set de
convenții ce permit platformei EF să introducă anumite modificări fără a fi necesară intervenția
directă a dezvoltatorului. Declararea proprietății id va notifica EF că aceasta este cheia primară a
tabelei ce va rezulta din clasa Project.

Tasks și Users sunt proprietăți de navigare ce conțin entități ce se găsesc în relație directă cu
entitatea Project. Lista Tasks conține toate task-urile ce au ca cheie externă id-ul proiectului iar User
conține utilizatorul al cărui cheie primară este egală cu valoarea cheii externe CreatedByUser a
proiectului.

CREATE TABLE [dbo].[Post] (

[Id] INT IDENTITY (1, 1) NOT NULL,
[Message] NVARCHAR (MAX) NULL,
[Username] NVARCHAR (MAX) NULL,
[UserId] INT NOT NULL,
[DatePosted] DATETIME NOT NULL,
CONSTRAINT [PK_dbo.Post] PRIMARY KEY CLUSTERED ([Id] ASC),
CONSTRAINT [FK_dbo.Post_dbo.User_UserId] FOREIGN KEY ([UserId])
REFERENCES [dbo].[User] ([UserID]) ON DELETE CASCADE
);
List. 2 Script SQL de creare a tabelei Project
 26

Structura tabelei rezultate din clasa Project este prezentată în List. 2. Toate proprietățile au
fost introduse ca și coloane iar tipurile lor au fost convertite în tipuri specifice bazelor de date SQL.
Se poate observa partea în care coloana Id este marcată ca fiind cheia primară a acestei tabele.
Toate aceste acțiuni au fost realizate de platforma EF.

Clasa Project nu respectă convențiile EF de marcare a unei proprietăți ca și cheie externă.

Dacă proprietatea CreatedByUser ar fi fost numită UserId, EF ar fi înțeles automat că aceasta este o
cheie externă și ar fi marcat-o în baza de date. Chiar daca convenția nu a fost respectată, se poate
observa că proprietatea CreatedByUser este cheie externă. Acest lucru este posibil prin intermediul
Fluent API ce permite realizarea unor mapări mult mai complexe decât cele acoperite de convențiile
Entity Framework.

modelBuilder.Entity<User>()
.HasMany(u => u.Projects)
.WithRequired(p => p.CreatedBy)
.HasForeignKey(p => CreatedByUser)
.WillCascadeOnDelete(false);
List. 3 Exemplu de folosire Fluent API

Bucata de cod prezentată în List. 3, conține o mapare realizată prin intermediul FluentAPI.
Pentru entitatea Users este marcată proprietatea de navigare Projects ce reprezintă o listă a
proiectelor asociate unui utilizator. Legătura este făcută prin intermediul proprietății de navigare
CreatedBy ce conține entitatea User ce a creat proiectul și proprietatea CreatedByUser ce reprezintă
cheia externă ce face legătura între proiect și utilizator.

Pentru a putea putea interacționa cu informațiile din baza de date, este necesară folosirea
clasei System.Data.Entity.DbContext6. Aceasta se ocupă de gestionarea entităților, persistarea lor
pe durata rulării unei aplicații, încărcarea datelor din bază și salvarea modificărilor.

Pentru comunicarea cu baza de date aplicația folosește clasa AppContext ce moștenește

System.Data.Entity.DbContext. În List. 4 se poate observa structura acestei clase.

public class AppContext : DbContext

{
public AppContext()
: base("AppContext")
{
;
}

public DbSet<User> Users { get; set; }

public DbSet<Task> Tasks { get; set; }
public DbSet<Project> Projects { get; set; }
public DbSet<Note> Notes { get; set; }
public DbSet<Attachment> Attachments { get; set; }
public DbSet<Post> Posts { get; set; }
public DbSet<Comment> Comments { get; set; }
}
List. 4 Structura clasei AppContext

6
http://msdn.microsoft.com/en-us/library/system.data.entity.dbcontext%28v=vs.103%29
 27

Constructorul clasei AppContext primește ca parametru numele unui connection string ce

identifică adresa bazei de date cu care va comunica. Declararea acestui string se face în interiorul
fișierului Web.config al aplicației.

<connectionStrings>
<add
name="AppContext"
connectionString="Data Source=(LocalDb)\v11.0;Initial Catalog=AppDb;Integrated
Security=SSPI;"
providerName="System.Data.SqlClient" />
</connectionStrings>
List. 5 Detaliile bazei de date

Proprietățile de tip DbSet conțin colecțiile de entități cu care se va lucra în interiorul

contextului. Pentru a adăuga, edita sau șterge un utilizator, se vor executa operații pe proprietatea
DbSet<User> Users a clasei AppContext.

4.3 Implementarea funcționalităților

Funcționalitățile aplicației sunt oferite prin intermediul claseler controller ce oferă

utilizatorului posibilitatea de a interacționa cu datele aplicației. Datorită numărului destul de mare
de funcționalități oferite, aplicația folosește mai multe controllere. Acestea sunt:
 Account
 FileUpload
 Home
 Note
 Project
 Statistics
 Task

Așa cum am văzut în secțiunea anterioară, pentru a avea acces la baza de date trebuie să
folosim clasa AppContext. Pentru a împărți obiectul de tip AppContext între toate controllerele, a
fost implementată clasa BaseController.

public class BaseController : Controller

{
public static AppContext db = new AppContext();

public BaseController()
{
;
}

~BaseController()
{
db.Dispose();
base.Dispose();
}
}
List. 6 Clasa BaseController
 28

Această clasă are ca scop oferirea unui context static tutoror controllerelor prin intermediul
moștenirii. Toate controllerele moștenesc BaseController!
~BaseController() este destructorul clasei și este apelat pentru a asigura eliberarea memoriei
și închiderea conexiunilor cu baza de date.

4.3.1 LINQ

LINQ (Language Integrated Query) este o funcționalitate a platformei .NET ce permite

realizarea de interogări asupra bazelor de date SQL, fișierelor XML sau a colecțiilor de obiecte ce
extind clasa Ienumerable (List, Stack, Queue, etc.).

Aplicația folosește LINQ pentru realizarea tuturor interogărilor din cod. În List. 7 este
ilustrată o interogare a bazei de date pentru a obține ultimele 10 cerințe ordonate după data
modificării.

db.Tasks
.Select(u => u)
.Where(t => !t.Private || t.CreatedBy.Username ==
User.Identity.Name || t.AsignedTo.Username ==
User.Identity.Name)
.OrderByDescending(t => t.LastModified)
.Take(10)
.ToList();
List. 7 Încărcarea cerințelor folosind LINQ

Cuvintele cheie Select și Where sunt cunoscute tuturor persoanelor ce au lucrat cu

interogări SQL și îndeplinesc aclași același rol și în LINQ. Metoda .ToList() execută interogarea și
întoarce o listă de obiecte, în accest caz, de tipul cerință.

4.3.2 Rolul clasei Account

Clasa Account are ca rol oferirea funcționalităților ce țin de utilizatori.

Afișare (Index)
Afișarea tuturor utilizatorilor înregistrați în aplicație. Această acțiune este disponibilă doar
utilizatorilor ce dețin rolurile Administrator sau ProjManager.

Autentificare (Login)
Pentru a putea folosi aplicația, fiecare utilizator trebuie să își confirme identitatea. Acest
lucru se face prin intermediul unui nume de utilizator și a unei parole. Metoda de autentificare va
căuta în baza de date perechea (nume,parolă) și , dacă aceasta este validă și utilizatorul este activ,
va confirma identitatea utilizatorului.

Dezautentificare (Logoff)
Dezautentifică utilizatorul înregistrat în sesiunea curentă.
 29

Înregistrare (Register)
Metoda permite introducerea unor noi utilizatori în baza de date. Ea poate fi apelată de
oricine însă un utilizator înregistrat nu poate folosi contul până când administratorul nu confirmă
autenticitatea lui. Tot administratorul poate modifica rolul unui cont nou creat, rolul atribuit unui
nou cont fiind cel de reporter.

Editare utilizator (EditUser)

Editarea unui utilizator poate fi realizată doar de administrator sau de proprietarul contului.
Datorită importanței lor, unele informații (nume utilizator, parolă) nu pot fi modificate prin
intermediul acestei metode.

Resetare parolă (ReserPassword)

Metodă folosită pentru resetarea parolei unui utilizator. Pentru a-și reseta parola, un
utilizator este obligat să introducă actuala parolă pentru a confirma identitatea. În cazul în care
acesta a uitat actuala parolă, un administrator o poate reseta fără a fi nevoie de vechea parolă.

4.3.3 Rolul clasei FileUpload

Clasa FileUpload permite încărcarea și partajarea fișierelor ce țin de o cerință. Principalele

funcționalități oferite de această clasă sunt: încărcarea și afișarea documentelor. Acestea sunt
disponibile doar din interiorul interfeței de vizualizare a unei cerințe.

Încărcare atașament (UploadFile)

Permite adăugarea de atașamente unei cerințe active. Înainte de a fi salvat pe server
atașamentul este supus unei validări. Această validare se aplică asupra dimensiunii și a formatului
fișierului. Dimensiunea maximă a unui atașament este de 1,5 MB iar tipurile de fișier acceptate sunt:
txt, jpg, jpeg, png, xls, xlsx, doc, docx, pdf.

Descărcare atașament (DownloadFile)

Permite descărcarea unui atașament selectat de utilizator. Oricine se poate folosi de această
funcționalitate.

4.3.4 Rolul clasei Home

Clasa Home are ca rol colectarea și afișarea informațiilor de pe pagina principală a aplicației.
Aceste informații sunt disponibile doar utilizatorilor autentificați.

Afișare (Index)
Întoarce o listă de 10 cerințe și una de 10 proiecte, ambele ordonate dupa data ultimei
modificări. Principalul rol al acestor liste este acela de a informa utilizatorul care sunt cele mai noi
activități realizate de membrii echipei.
 30

4.3.5 Rolul clasei Note

Principalul rol al clasei Note este acela de a adăuga notițe cerințelor.

Crează (Create)
Adaugă o notiță pentru cerința selectată. Timpul introdus de utilizator estre transformat în
minute înainte ca notița să fie salvată.

4.3.6 Rolul clasei Project

Listare proiecte (Index)

Această metodă întoarce lista tuturor proiectelor introduse în aplicație.

Crează proiect (Create)

Oferă posibilitatea introducerii de noi proiecte în aplicație. Este rezervată doar utilizatorilor
ce dețin rolul de ProjManager sau Administrator.

Afișare proiect (ViewProject)

Afișare datelor unui proiect, împreună cu o listă de cerințe atașate.

Schimbare stare (ChangeState)

Permite schimbarea stării unui proiect pentru a marca finalul acestuia sau pentru
suspendarea lui până la un moment dat.

4.3.7 Rolul clasei Task

Adaugă cerință (Create)

Metoda ce perimite adăugarea unei noi cerințe proiectului. Accesul către această metodă
este oferit tuturor utilizatorilor aplicației, indiferent de rol.

Editează cerință (EditTask)

Oferă posibilitatea editării informațiilor unei cerințe. Pentru a putea edita o cerință aceasta
trebuie să fie creată de utilizatorul ce apelează această metodă dacă rolul acestuia este cel de
Reporter.

Afișează cerință (ViewTask)

Afișarea în interfață a detaliilor cerinței. Acestea cuprind toate notele și atașamentele
adăugate pentru acea cerință.

Listare cerințe (ViewTasks)

Metodă folosită pentru a afișa lista tuturor cerințelor din aplicație. Excepție de la regulă fac
cerințele private ce nu apar în listă decât utilizatorilor ce le-au creat sau cei cărora le sunt atribuite.
 31

4.3.8 Implementarea modulului de comunicare

Modulul de comunicare oferă utilizatorilor aplicației posibilitatea de a interacționa prin

intermediul mesajelor. Imediat ce s-a autentificat un utilizator poate să intre în secțiunea de mesaje
și să adauge postări sau comentarii la postările altor utilizatori. Afișarea postărilor și a comentariilor
se face în timp real, pentru a oferi accesul la informație tuturor utilizatorilor ce se află pe pagina de
mesaje. Pentru a oferi această funcționalitate am folosit SignalR.

Fig. 6 Modul de comunicare

 32

4.3.8.1 SignalR

SignalR este un API ce permite adăugarea funcționalităților ce oferiră conținut în timp real
utilizatorilor. Aceasta presupunere trimiterea de conținut dinspre server către client imediat ce noi
informații au fost adăugate, fără a aștepta un request de la client. Principala tehnologie pe care se
bazează este protocolul WebSocket, introdus în versiunea a 5-a a limbajului HTML.

WebSocket permite crearea unei conexiuni bidirecționale persistente între client și server,
oricare dintre aceștia putând iniția trimiterea de date în orice moment. Deoarece este o tehnologie
nouă, nu toate browserele au implementat-o încă. Cu toate acestea, atunci când detectează că
serverul sau clientul nu suportă WebSocket, SignalR folosește alte tehnologii pentru a oferi aceleași
funcționalități, fără a fi nevoie de efort în plus din partea dezvoltatorului.

4.3.9 Implementarea modulului de statistică

Pentru a oferi utilizatorilor opțiunea de a inspecta starea tuturor elementelor din aplicație, le
este pusă da dispoziție componenta de statistică și raportare. În această interfață utilizatorului îi
sunt prezentate statistici formate pe baza informațiilor din interiorul aplicației. Fig. 7 prezintă
diagramele ce corespund procentului de proiecte ce se află în una din posibilele stările și numărul de
task-uri ce au fost adăugate pentru fiecare proiect.

Interfața de statistică este împărțită în 3 regiuni:

 Statistici ale proiectelor
 Statistici ale cerințelor
 Statistici ale utilizatorului

Pentru desenarea tuturor diagramelor a fost folosită biblioteca DotNet.Highcharts 7 ce

este o extensie a Highcharts8. Highcharts este o bibliotecă scrisă în JavaScript ce permite adăugarea
de diagrame complexe în interiorul paginilor web. Introducerea unei diagrame în interiorul unei
pagini necesită folosirea exclusivă a limbajului JavaScript. Pentru a ușura munca dezvoltatorilor ce
lucrează cu ASP.Net, a fost dezvoltată biblioteca DotNet.Highcharts ce permite desenarea
diagramelor folosind cod C#.

Partea de cod ce are ca rezultat desenarea diagramei ce conține stările proiectelor se

găsește în anexa 1. Deși codul este scris în limbajul C#, rezultatul întors de metodă este
reprezentarea diagramei în JavaScript.

7
https://dotnethighcharts.codeplex.com/
8
http://www.highcharts.com/
 33

Fig. 7 Exemplu de reprezentare grafică a statisticilor

 34

CAPITOLUL 5

Testare și evaluare
Pentru testarea aplicației am folosit YSlow, extensie pentru Firebug realizată de dezvoltatorii
de la Yahoo!. Aceasta oferă unei pagini web o notă și un scor, în funcție de performanțele oferite.

Elemente ce pot influența pozitiv scorul acordat sunt:

 Numarul mic de cereri HTTP
 Adăugarea antetului expires pentru a permite păstrarea în cache a scripturilor și
imaginilor
 Comprimarea componentelor
 Reducerea duplicării de porțiuni CSS și JavaScript
 Număr redus de elemente DOM
 Reducerea dimensiunii cookie-urilor
 Etc.

Folosind ultima versiuena a browserului Firefox (30.0) și Firebug, scorul întors de YSlow a
fost de 83 puncte.

Fig. 8 Notă și scor performanțe

Principalele observații ce au redus scorul au fost:

 numarul mare de cereri HTTP

 omiterea antetului expires
 folosirea elementelor necomprimate

Fig. 9 Statistici YSlow

 35

În Fig. 8 se poate observa că, pentru a încărca elementele paginii, sunt necesare 14 cereri
HTTP iar dimensiunea componentelor descărcate este de aproape 1MB atunci când acestea nu sunt
introduse în cache.

Pentru a micșora numarul de cereri trimise serverului, am folosit clasa BundleConfig în

interiorul aplicației. BundleConfig permite gruparea scripturilor CSS și a celor de JQuery și JavaScript
în pachete (ScriptBundle, StyleBundle).

bundles.Add(new ScriptBundle("~/bundles/bootstrap").Include(
"~/Scripts/bootstrap.js",
"~/Scripts/respond.js",
"~/Scripts/bootstrap-datepicker.js",
"~/Scripts/jquery.dataTables.js"
));
List. 8 Declararea unui pachet de script-uri JS

List. 8 prezintă gruparea unor script-urilor folosite în aplicație într-un pachet numit
bootstrap. Pentru a încărca acest pachet este suficientă apelarea lui în interfață prin intermediul
metodei Render, ca în exemplul @Scripts.Render("~/bundles/jquery"). Folosind
pachetul bootstrap, numărul de cereri HTTP trimise serverului pentru a încărca cele 4 fișiere JS a fost
redus de la 4 la o singură cerere.

Un alt avantaj adus de folosirea pachetelor de conținut este posibilitatea folosirii

optimizărilor. Proprietatea BundleTable.EnableOptimizations permite optimizarea
codului din interiorul unui pachet pentru a-i micșora dimensiunile, dacă îi este atribuită valoarea
true. Aceste optimizări constă în eliminarea tuturor spațiilor libere și a comentariilor din interiorul
fișierelor, fără a modifica funcționalitățile.

O nouă rulare a aplicației Yslow după introducerea optimizărilor a întors un scor de 98

puncte.

Fig. 10 Notă și scor performanțe – după optimizare

Numărul de cereri HTTP trimise serverului pentru descărcarea componentelor a fost

înjumătățit iar dimensiunea totală a elementelor descărcate a devenit de aproape 5 ori mai mică.

Fig. 11 Statistici YSlow – după optimizare

 36

CAPITOLUL 6

Concluzie și viitoare îmbunătățiri

6.1 Concluzie

Așa cum a fost prezentat și în acest document, gestiunea proiectelor este un domeniu
complex ce necesită cunoștințe avansate de management a timpului, calității și a resurselor umane.
Rezultatul unei gestiuni reușite este micșorarea efortului depus de echipa de dezvoltare și mărirea
ratei de succes a proiectelor. Soluțiile software oferă o gamă largă de funcționalități ce permit
automatizarea unora din acțiunile necesare în procesul de gestiune.

Fiind dezvoltat ca aplicație web, proiectul permite accesul tuturor utilizatorilor, indiferent
de sistemul de operare folosit, prin intermediul oricărui browser modern. Aplicația poate fi folosită
ca SaaS, permițând companiilor să folosească spațiul de stocare și puterea de procesare a unui
server comun sau ca aplicație locală, fiecare companie folosindu-și propriile resurse.

Funcționalitățile oferite de aplicație sunt:

 Adăugarea utilizatorilor și ierarhizarea lor folosind roluri.
 Posibilitatea adăugării proiectelor. Schimbarea stării acestora pentru a bloca accesul
sau a marca finalul lor. Încadrarea într-un interval de timp ce reprezintă ciclul de viață
al proiectului.
 Adăugarea cerințelor unui proiect. Posibilitatea editării informațiilor unei ceințe
pentru a marca diversele stări prin care aceasta poate trece.
 Adăugarea de note pentru a marca progresul obținut și timpul petrecut pentru
obținerea sa.
 Partajarea fișierelor între utilizatori pentru a oferi acces imediat la informație.
 Pagină ce permite comunicarea în timp real între toți membrii unui proiect.
 Pagină de statistică ce conține detalii legate de starea proiectelor, cerințelor și
utilizatorilor.
 Interfață grafică ce oferă accesul ușor către toate celelalte funcționalități.

Prezenta aplicția îndeplinește scopul proiectului, oferind echipelor de dezvoltare o soluție

web simplă și eficientă pentru gestiunea proiectelor software.

6.2 Viitoare îmbunătățiri

Aplicația oferă funcționalități elementare ce permit gestionarea proiectelor software.

Datorită numărului extrem de mare de tehnici ce pot fi folosite pentru a ajuta echipele de dezvoltare
să obțină rezultatele dorite, implementarea unei aplicații complete de gestiune a proiectelor este
aproape imposibilă.
 37

Câteva din funcționalitățile ce ar aduce îmbunătățiri aplicației sunt:

 Adăugarea unui calendar ce permite vizualizarea tuturor proiectelor și a cerințelor

dintr-un interval selectat. Posibilitatea de a oferi un calendar pentru fiecare utilizator
sau pentru fiecare proiect.

 Trimiterea de notificări pe telefon. Realizarea unei aplicații prin intermediul căreia

utilizatorul să primească notificări atunci când sunt aduse modificări proiectelor.
Sistemul va fi customizanil pentru a evita servirea de informații inutile utilizatorilor.

 Changelog. Păstrarea unui istoric și permiterea vizualizării acestuia pentru fiecare

proiect și cerință. Permite identificarea mult mai ușoară a tuturor modificărilor și
acțiunilor ce au survenit asupra unui proiect.

 Interfață de adăugare a resurselor. Resursele pot fi oameni, servicii, echipament

hardware, proiecte sau cerințe.

 Workflow. Permite construirea unui arbore ce ilustrează modul în care cerințele unui
proiect depind unele de altele. În acest mod se poate identifica grafic drumul ce trebuie
parcurs pentru a implementa cerințele în ordinea corectă. Necesită introducerea
conceptului de resursă.

 Exportarea rapoartelor în format .xlsx și .pdf

Având în vedere că acestă aplicație este de abia la început, pe măsură ce dezvoltarea

continuă, unele sau chiar toate funcționalitățile enumerate mai sus vor face parte din setul de unelte
disponibile pentru a oferi o soluție cât mai completă pentru problema gestiunii proiectelor.
 38

Anexa A

Desenarea unei diagrame folosind Dot.NET Highcharts

1 Highcharts chart1 = new Highcharts("chart1")

2 .InitChart(new Chart { PlotShadow = false })
3 .SetTitle(new Title { Text = "State of all projects" })
4 .SetTooltip(new Tooltip { Formatter = "function() { return
5 '<b>'+ this.point.name +'</b>: '+
6 Math.round(this.percentage).toFixed(2) +' %'; }" })
7 .SetPlotOptions(new PlotOptions
8 {
9 Pie = new PlotOptionsPie
10 {
11 AllowPointSelect = true,
12 Cursor = Cursors.Pointer,
13 DataLabels = new PlotOptionsPieDataLabels
14 {
15 Formatter = "function() { return '<b>'+
16 this.point.name +'</b>: '+
17 Math.round(this.percentage).toFixed(2) +' %'; }"
18 }
19 }
20 })
21 .SetSeries(new Series
22 {
23 Type = ChartTypes.Pie,
24 Name = "Project states",
25 Data = new Data(new object[]
26 {
27 new object[] { "Opened", allProjects.Where(p =>
28 p.State == ProjectState.Opened).Select(p =>
29 p.Count).FirstOrDefault()},
30 new object[] { "Closed", allProjects.Where(p =>
31 p.State == ProjectState.Closed).Select(p =>
32 p.Count).FirstOrDefault()},
33 new object[] { "Suspended", allProjects.Where(p =>
34 p.State == ProjectState.Suspended).Select(p =>
35 p.Count).FirstOrDefault()
36 }
37 })
38 })
39 .SetCredits(new Credits {Enabled = false});
 39

Bibliografie
[1] Andrew Stellman, Jennifer Green, “Applied Software Project Manager” (Gestiunea aplicată a proiectelor
software), O’Reily, 2005

[2] Project Management Institute Inc. , “A Guide To The Project Management Body Of Knowledge – Fourth
Edition” (Un ghid al cunoștințelor gestiunii proiectelor), Project Management Institute Inc.,
Pennsylvania, 2009

[3] ASP.NET MVC

http://www.asp.net/mvc/tutorials/older-versions/overview/asp-net-mvc-overview

[4] Entity Framework și Code First

http://www.msdn.microsoft.com/en-us/data/ee712907

[5] Detalii implementare SignalR

https://github.com/SignalR/SignalR/wiki