Prof conf dr. Haller Piroska [620578]

UNIVERSITATEA DE MEDICINA, FARMACIE, STIINTE
TEHNOLOGIE DIN TARGU-MURES
FACULTATEA DE STIINTE SI LITERE
Program de studiu: INFORMATICA
LUCRARE DE LICENTA
Coordonator stiintific:
Prof conf dr. Haller Piroska
ABSOLVENT: [anonimizat] 2019 –

Cuprins
Capitolul 1.Introducere– Contextul proiectului ……………………………………………
1.1. Motiva ia i contextul lucrării……………………………………………………………………………………….. ț ș
1.2. Con inutul lucrării………………………………………………………………………………………………………. ț
Capitolul 2. Obiectivele Proiectului……………………………………………………………….
2.1. Obiective principale…………………………………………………………………………………………………….
2.2. Obiective secundare……………………………………………………………………………………………………..
Capitolul 3. Studiu Bibliografic……………………………………………………………………..
3.1.Introducere în principiile agile ……………………………………………………………………………………….
3.2 Abordarea Scrum…………………………………………………………………………………………………………..
3.2.1Introducere……………………………………………………………………………………………………………..
3.2.1 Roluri în Scrum………………………………………………………………………………………………………
3.2.3 Terminologia Scrum………………………………………………………………………………………………..
3.3 JIRA……………………………………………………………………………………………………………………………..
3.3.1 Backlog-ul………………………………………………………………………………………………………………
3.3.2 Sprint-ul i planificarea să……………………………………………………………………………………….. ș
3.3.3 Întâlnirile zilnice……………………………………………………………………………………………………..
3.3.4 Finalizarea Sprintului………………………………………………………………………………………………
3.3.5 Revizuirea Sprintului……………………………………………………………………………………………….
3.3.6 Retrospectivă Sprintului………………………………………………………………………………………….
Capitolul 4. Analiză i Fundamentare Teoretică……………………………………………… ș
4.1 Arhitectură client-server………………………………………………………………………………………………….
4.2 Cerintele sistemului………………………………………………………………………………………………………..
4.2.1 Cerintele functionale………………………………………………………………………………………………
4.2.2 Cerinte non-functionale………………………………………………………………………………………….
4.4.Tehnologii folosite………………………………………………………………………………………………………….
4.4.1 TypeScript………………………………………………………………………………………………………………
4.4.2 Angular 7……………………………………………………………………………………………………………….
4.4.3 HTML…………………………………………………………………………………………………………………..
4.4.4 CSS………………………………………………………………………………………………………………………

Capitolul 1. Introducere – Contextul proiectului
1.1 Motiva ia i contextul lucrării ț ș
Managementul proiectelor software reprezintă o problema deosebit de importantă, întrucât
fiecare companie, care se ocupă cu dezvoltatul de sisteme software, ia în vedere acest lucru, în
momentul în care î i doresc să se dezvolte cât mai eficient.În acest fel, au luat na tere diferite platfome ș ș
pentru a simplifică gestionarea lor.
Majoritatea platformelor deja existente pentru managementul proiectelor, nu au reu it să aibă un ș
design simplu, fără a încarcă interfa ă i având componente u or de identificat de către utilizator.În ț ș ș
felul acesta, aplica ia propusă tinde să aibă altă abordare mai plăcută i mai aerisită decât cele deja ț ș
existente, având un set de func ionalită i de baza. ț ț
Am ales această tema, întrucât consider că e esen ial atunci când ai un proiect să îl po i gestiona ț ț
cu mai multă u urin ă, când sunt implicate una sau mai multe echipe, indiferent despre ce proiect este ș ț
vorba.A adar, am ales tool-ul JIRA dezvoltat de compania australiană Atlassian întrucât aduce multe ș
beneficii, prin aplicarea principiilor Agile.
1.2 Con inutul lucrării ț
Primul capitol prezintă contextul lucrării de licen ă, precum i scopul acesteia. ț ș
Al doilea capitol subliniază obiectivele principale i secundare, ce anume î i propune platforma ș ș
să îmbunătă ească fa ă de ce este deja existent dar i o scurtă introducere a conceptelor de baza. ț ț ș
Capitolul trei face referire la studiul bibliografic, acesta fiind extrem de important pentru
intelegrea conceptelor care urmează a fi implementate.Aici sunt prezentate principiile Agile,
terminologia JIRA, câteva dintre platformele deja existente pe pia ă.În cadrul platformelor sunt ț
prezentate punctelor ări, cum proiectează în mod vizual principiile Agile dar i care sunt beneficiile i ț ș ș
costurile asociate.
În al patrulea capitol, sunt specificare cerin ele func ionale i non-func ionale, cu exemple ț ț ș ț
semnificative, este descrisă la modul general arhitectură sistemului dar i tehnologiile i limbajele ș ș
abordate în realizarea proiectului.

În capitolul cinci este vorba despre proiectarea i implementarea, unde este detaliată structura ș
aplica iei, cum a fost gândită, cum au fost folosite anumite principii i tehnologii dar i modalitatea de ț ș ș
comunicare între componentele sistemului.
Capitolul ase este dedicat manualului de instalare i utilizare al aplica iei.Aici va fi expus un ș ș ț
manual de instalare pentru tehnologiile folosite, precum i cum trebuie folosită aplica ia. ș ț
În ultimul capitol, se prezintă modalită i de dezvoltare ulterioară precum i îmbunătă irile care s-ar ț ș ț
putea aduce.
Capitolul 2. Obiectivele Proiectului
2.1 Obiective principale
Platforma pentru managementul proiectelor software are rolul de a gestiona proiectele, timpul i ș
sarcinile persoanelor implicate în dezvoltarea diferitelor produse, lucrând în stilul JIRA, stil care se
bazează pe existen a mai multor iteratii în realizarea unui proiect.Prin intermendiul acestei platforme, ț
utilizatorii vor putea să î i aloce un anumit interval de timp i să analizeze rezultatele ob inute, pentru a ș ș ț
realiza următoarele planificare de Sprint.
Majoritatea platformelor de pe pia ă au câteva obiecte importante pentru abordarea JIRA.Printre ț
acestea se află prezen a unui panou de JIRA la care au acces to i utilizatorii din cadrul proiectului.Prin ț ț
intermediul lui se pot vedea taskurile ultimului Sprint sau cele din Backlog, în cazul în care Sprint-ul s-
a terminat.
2.2 Obiective secundare
În prezent, se află pe pia ă o multitudine de platforme pentru managementul proiectelor ț
software, cu o intefata complexă, care oferă oportunitatea de a realiza diverse opera îi, precum ț
integrarea extensiilor pentru procesul de management.Platforma propusă în această lucrare vine să
simplifice modul în care utilizatorii interac ionează cu interfa ă, fiind mult mai simplă pentru proiectele ț ț
de dimensiuni medii i mici.În plus, poate fi utilizată de o varietate de utilizatori de la studen ii de la ș ț
facultate până la companiile de IT.

Platforma permite crearea mai multor proiecte, fiecare având atribuit o anumită echipa, acest
lucru fiind realizat de către administrator.În cadrul tuturor proiectelor, vor există sarcini care trebuie
îndeplinite de către angaja i, iar pentru o bună organizare a sarcinilor se folose te abordarea JIRA. ț ș
JIRA e un principiu utilizat pentru împăr irea i organizarea sarcinilor în sub-taskuri cât mai ț ș
mici, care se pot realiza într-o perioada de timp predefinită, numită Sprint.Pentru o evolu ie cât mai ț
vizibilă i cât mai bună, un Sprint trebuie să dureze între 2 i 4 săptămâni.Înainte de a începe un Sprint ș ș
are loc o edin a de planificare în care se stabilesc sarcinile care intră în următoarea iteratie i timpul ș ț ș
alocat fiecăreia.
Platforma are 3 roluri importante: Project managerul, responsabil pentru prioritizare,
planificare, comunicarea cu clien îi i angaja ii, echipa de dezvoltare care se ocupă de sarcinile din ț ș ț
Sprint i administrator.Primele 2 tipuri vor fi asignate de către administrator, în momentul creării ș
echipelor pentru proiecte.
În cadrul sprinturilor trebuie stabilită pentru fiecare sarcina o anumită perioada de timp în care
să fie realizată.Ea poartă denumirea de "Story Point" – SP.Fiecare echipa va putea să stabilească o
coresponden ă între SP i numărul zilelor de lucru.Coresponden ă e specifică pe echipa i se păstrază pe ț ș ț ș
întreagă durata a procesului de dezvoltare al proiectului.Pe lângă asta, platforma permite prioritizarea
sarcinilor, prioritate dată de Product Owner.În acest fel, echipa va ti care taskuri sunt urgen e i trebuie ș ț ș
realizate în cel mai scurt timp.
În plus, există un "Backlog", care reprezintă lista de taskuri care urmează să fie implementate în
următoarele sprinturi.
Pentru fiecare utilizator, după autentificare, va apărea un "Dashboard" unde vor fi afi ate ș
ultimele actualizări ale sarcinilor care îi sunt atribuite.
Todotata, în cadrul Sprintului curent. Se va putea vizualiza un "Burndown chart" adică graficul
evolutiv al taskurilor fa ă de un anumit etalon.Cu ajutorul acestui grafic, pe baza statisticilor se va ti ț ș
cum să se organizeze mai bine echipa în sprinturile viitoare.
Prin utilizarea acestei aplica ii, muncă în echipa va fi îmbunătă ită, va fi mult mai bine ț ț
organizată i structurată întrucât fiecare persoană î i va cunoa te sarcinile, ce rol are i momentul în ș ș ș ș
care va trebui să le termine.De asemenea, de la un Sprint la altul se va putea vedea evolu ia modului de ț
interac iune al echipei dar i randamentul ei. ț ș

Capitolul 3. Studiu Bibliografic
3.1 Introducere în principiile agile
Metodologie de management de proiecte ce încearcă să mic oreze riscurile de dezvoltare i ș ș
timpul de execu ie prin implementarea proiectelor în formă flexibilă i interactivă. ț ș
Această metodologie a fost ini ial dezvoltată pentru industria software pentru a îmbunătă i ț ț
procesul de dezvoltare pentru a se identifica cât mai repede problemele, defectele i pentru a putea fi ș
rezolvate cât mai repede cu putiin ă.Oferă dezvoltatorilor i echipelor o modalitate foarte rapidă de a ț ș
furniza un produs calitativ, prin sesiuni interactive i scurte. ș
Agile e potrivit pentru organiza iile care doresc să transforme modul în care gestionează ț
proiectele i func ionează în anasamblu. ș ț
În cadrul agile se află 12 principii importante:
1.Prioritatea cea mai mare este satisfacerea clientului, lucru care se realizează prin intermediul
livrărilor la timp i continuu. ș
2.Schimbările aducătoare de avantaje sunt bine venite mereu, chiar dacă sunt prezentate în
stadiul de dezvoltare al proiectelor.
3.Un produs sau un serviciu este livrat des.
4.Dezvoltatorii i stakeholderii colaborează pentru o bună dezvoltare a aplica iei ș ț
5.Echipa este obligată să aibă la dispozi ie toate tool-urile necesare i de asemenea suport dacă ț ș
este necesar pentru îndeplinirea tuturor obiectivelor proiectului.
6.Întâlnirile cât mai des fa ă în fa ă pentru clarificarea nelamuririlor. ț ț
7.Succesul e realizat prin finalizarea produsului.
8.Ritmul de în elegere i dezvoltare între păr ile implicate trebuie să fie continuu i constant. ț ș ț ș
9.Îmbunătă irea abordării Agile prin utilizarea unui design potrivit i a concentrării pe ț ș
tehnologiile utilizare.
10.Simplitate cât mai mult posibil.
11.Echipele trebuie să se auto-organizeze.
12.Echipele ar trebui să folosească intervale regulate de timp pentru îmbunătă irea eficien ei. ț ț

Avantajele abordării agile:
• Cre terea transparen ei ș ț
• Cre terea productivită ii ș ț
• Cre terea flexibilită ii ș ț
• Oferirea unor servicii de calitate superioară
• Scăderea riscului de omitere a unor obiective
• Cre terea angajamentului i satisfac iei stakeholderilor ș ș ț
Dezavantajele acestei metode:
Agile nu e o metodă universală, care să se potrivească pentru orice proiect i din acest motiv ș
trebuie o analiză detaliată pentru a identifica cea mai bună metodologie pentru fiecare proiect în
parte.În cazul în care managerul de proiect i echipa nu au expeienta sau clientul nu definete de la ș
început ceea ce dore te sau nu e sigur de ce anume vrea, metodă Agile poate să nu func ioneze a a cum ș ț ș
s-a dorit intital.Pe întreagă durata a procesului de dezvoltare , agile favorizează echipele de proiecte,
dezvoltatorii i obiectivele clien ilor dar nu ia în considerare experien ă utilizatorului final. ș ț ț
Din cauza proceselor sale mai pu în formale i mai flexibile agilul nu poate fi întotdeauna u or ț ș ș
de abordat în cadrul organiza iilor mari fiindcă acestea au o abordare tradi ională, în care există prea ț ț
multă rigiditate sau prea multă flexibilitate în cadrul proceselor sau echipelor.
Pentru a combate aceste dezavantaje, se pot îmbină mai multe abordări, creându-se o nouă
abordare hibridă.Această ajută la cre tea gradului de adaptabilitate în cazul mai multor ramuri de ș
activitate sau pentru particularizarea unei metodologii pentru un anumit proiect.
Metodologiile cele mai des întâlnite sunt:
•Scrum
•Kanban
•Scrumbban
•RAD

3.2 Abordarea Scrum
3.2.1 Introducere
Scrum e un model agile de gestionare a proiectelor informatice complexe.E o metodă iterativă
intruat, în timp ce infrastructură e dezvoltată, sunt livrate piese func ionale către cumpărători, în a a fel ț ș
încât, rganizatiile lor pot începe să utilizeze păr i ale sistemului în prima parte a ciclului de dezvoltare. ț
3.2.1 Roluri în Scrum
Cele 3 roluri în scrum sunt: Product Owner, Scrum master i echipa de dezvoltare. ș
Product Owner-ul e cel mai important în organizarea proiectului.E cel care are autoritatea de a
decide func ionalită ile care vor fi implementate precum i ordinea acestora.Totodată, se asigura că ț ț ș
scopul este bine definit i că fiecare membru al echipei tie foarte bine ce are de făcut i ceea ce trebuie ș ș ș
să ob ină.El colaborează cu Scum master-ul i echipa de dezvoltare. ț ș
Scrum Master-ul este un îndrumător, care face cunoscută metodologia Scrum, ajutând membrii
echipei să pună în practică principiile i conceptele care sunt folosite în cadrul Scrum.Neavând ș
autoritate asupra echipei, acesta o protejează de impedimentele externe care pot afecta eficientă.
i echipa de dezvoltare e formată dintr-un număr restrâns de persoane, între 5-7 persoane de Ș
preferat având diverse responsabiliati i abilită i.Scopul lor este de a îndeplini ceea ce le-a fost asingat ș ț
de către Product Owner.Ei stabilesc cum să rezolve taskurile din Backlog făcându-le estimări, î i ș
distribuie între ei responsabilită ile i au discu ii zilnice pentru a- i monitoriza evolu ia. ț ș ț ș ț
3.2.3 Terminologia Scrum
Precum se poate sesiza, în cadrul abordării Scrum există anumi i pa i i termeni specifici, a ț ș ș
căror semnifica ie trebuie bine cunoscută de fiecare membru în parte. ț
Scrum este un principiu care este utilizat i pentru organizarea i împăr irea sarcinilor în taskuri ș ș ț
care pot fi realizate într-o perioada de timp predefinită, a a numitul Sprint.Pentru o evolu ie cât mai ș ț
rapidă, sprintul trebuie să dureze între 1 i 4 săptămâni.Înaintea fiecărui sprint se face o edin a unde se ș ș ț
planifică i se stabilesc sarcinile care întră în Sprint Backlog i timpul alocat fiecăruia. ș ș

O dată pe zi are loc o edin a numită stand-up, unde fiecare membru al echipei discuta despre ș ț
taskurile pe care le are i dacă a întâmpinat dificultă i. ș ț
Dacă se dore te vizualizarea progresului în Sprint, se va putea vizualiza un burndown chart, ș
adică graficul sarcinilor finalizate în raport cu evolu ia a teptată. ț ș
Totodată, cele 3 roluri importante: Product Owner acesta fiind responsabil cu planificarea,
prioritizarea i comunicarea cu clien ii i angaja ii.Echipa de dezvoltare care se ocupă cu sarcinile din ș ț ș ț
Sprint i Scrum master responsabil pentru o mai bună în elegere a ceea ce înseamnă Scrum. ș ț
3.3. JIRA
Este o platforma foarte populară în managementul proiectelor, această fiind folosită în cadrul
multor companii pentru a asigura că cerin ele sunt îndeplinite pornind de la concept până la stadiul ț
final, acesta fiind lansare în produc ie.Platforma este des utilizată de către echipele care lucrează în ț
stilul Agile deoarece permite utilizatorilor să planifice, să urmareaza i să lanseze o aplica ie foarte ș ț
facil.Pe lângă asta, Jira oferă un se de grafice, care prezintă starea curentă a sprintului.
Jira utilizează o abordare Scrumban hibridă.Această combină Scrum-ul cu Kanban-ul, fiind un sistem
flexibil de gestiune a proiectelor.Acest sistem colec ionează toate datele existente i permite ț ș
utilizatorilor să facă diferite analize i statistici.Totodată, se pot integra pluginuri pentru BitBucket sau ș
Gît care permit crearea de commituri pe baza de ticket-ului curent de lucru.
În cadrul Sprinturilor, se pot adaugă diverse permisiuni pentru utilizatori, liderilor de echipa,
utilizatorilor, pentru a avea un control cât mai bun i o organizare optimă, care să se modeleze pe ș
necesită ile proiectului.În organizarea de tip Kanban accentul se pune pe realizarea task-urilor ț
prioritare, Jira sare în ajutor i le ordonează după acest indice.Importantă task-urilor se poate seta prin ș
utilizarea unor flaguri de diferite culori.În momentul schimbării priorită ii unui task, Jira anun ă imediat ț ț
că trebuie adăugat un comentariu care să motiveze ac iunea realizată. ț
Costul pentru această platforma variază în func ie de numărul persoanelor implicate.Există un ț
pachet pentru echipele mici, de 10 persoane aproximativ sau alte op iuni pentru echipele cu personal ț
variabil.

3.3.1 Backlog-ul
Pe baza cerin elor primite de la clien i, project managerul trebui să prioritizeze sarcinile, să le ț ț
ordoneze în func ie de importantă i să le grupeze sub formă unei liste numite Product Backlog.În acest ț ș
fel, sarcinile cele mai importante se vor află în partea de sus a listei, iar cele mai pu în prioritare în ț
partea de jos.În cazul proiectelor noi, sunt trecute în Backlog, caracteristicile care întrunesc viziunea
owner-ului asupra proiectului, iar în cazul proiectelor care se află în dezvoltare, sunt trecute trăsături
noi care se doresc să fie implementate.Backlog-ul e o lista variabilă deoarece se pot adaugă pe parcurs
diverse, elementele pot fi terse, adăugate, prioritatea li se poate modifică i pot fi editate. ș ș
Înainte de finalizarea prioritizării, dimensiunea este exprimată prin "Story Points".Fiecare
echipa trebuie să stabilească o coresponden ă între SP i numărul zilelor de lucru cu normă întreagă.De ț ș
exemplu, 1SP poate corespunde pentru 2 zile.Această coresponden ă se păstrează pe durata întregului ț
proces de dezvoltare a proiectului.
3.3.2 Sprint-ul i planificarea să ș
Un sprint este o perioada de timp prestabilită timp în care ehcipa realizează anumite
sarcini.Fiecare sprint începe printr-o edin a de planificare.Pe parcursul acesteia, echipa i project ș ț ș
managerul discuta despre ce vor lucra în continuare i stabilesc sarcinile care vor întră în Sprint. ș
În timpul sprintului nu se fac modificări care să pună în pericol obiectivul Sprintului,
obiectivele legate de calitate nu scad iar scopul sprintului poate fi clarificat i renegogiat între echipa i ș ș
project manager.
Durata unui Sprint în mod obi nuit de 30 de zile.Această poate varia de la 1 până la maxim 4 ș
săptămâni pentru o mai bună urmarie a rezultatelor ob inute.După începerea sprintul, project ț
managerului lasă echipa să î i indeplindeasca sarcinile intervenind doar în cazul în care apar ș
impedimente.
3.3.3 Intalnirile zilnice
În fiecare zi a sprintului, în mod normal, membrii echipei se întâlnesc la o edin a numită "stand ș ț
up" care durează 15 minute sau mai pu în.O abordare comună a realizării stand-up-ului este că fiecare ț
participant să răspundă la următoarele 3 întrebări:
Ce am realizat de la ultimul stand-up?

La ce doresc să lucrez până la următorul stand-up?
Care sunt obstacolele sau impedimentele care îmi îngreunează progresul?
Prin răspunderea la aceste întrebări, toată lumea are o imagine de ansamblu cu ce se
întâmplă.Întâlnirea zilnică este necesară întrucât ajută că echipa de dezvoltare să gestioneze muncă
rapid i flexibil. ș
Sprintul poate fi anulat în cazul în care intă Sprintului devine depă ită.În general, un Sprint ar ț ș
trebui să fie anulat dacă nu mai are sens în circumstan ele date.Sprintul poate fi anulat de către project ț
manager dar din cauza duratei scurte al lor, anularea are rar sens.Când un Sprint este anulat, toate
elementele "Finalizate" ale Backlog-ului sunt revizuite.Toate elementele incomplete ale Backlog-ului
sunt reestimate i repuse înapoi.Anularea Sprintului consumă resurse întrucât toată lumea trebuie să se ș
regrupeze într-o altă edin a de planificare a Sprintului pentru a începe un alt Sprint. ș ț
3.3.4 Finalizarea Sprintului
Prin finalizarea unui Sprint, rezultatul e văzut că o partea din produs care e aproape gata pentru
a fi dat clientului.Pentru fiecare echipa finalizarea sarcinilor are o interpretare diferită, luându-se în
considerare calitatea ob inută dar i măsură în care produsul poate fi livrat după Sprint. ț ș
În stadiile incipiente de dezvoltare a unui produs, defini ia minimală pentru finalizarea unui Sprint ț
constă în realizarea unei por iuni are este proiectată, construit, testată i documentată.Lucrul acesta ț ș
ajută la generarea feedback-ului, echipa tiind cum să procodeze pentru următorul sprint, ce sarcini să ș
facă în continuare i cum să le abordeze. ș
3.3.5 Revizuirea Sprintului
edin a de revizuire a Sprintului se ine la finalul Sprinutlui pentru a adapta Backlog-ul dacă e Ș ț ț
necesar.La lista participan ilor este inclusă toată echipa care a participat la proiect.În revizuirea ț
Sprintului se include faptul că project managerul explică care elemente din Backlog au fost finalizate i ș
care nu.Echipa discuta ce a func ionat bine în timpul Sprintului, care au fost problemele de care s-au ț
lovit i cum au fost rezolvate, ace tia fac un demo cu ceea ce s-a finalizat i răspund întrebărilor legate ș ș ș
de sprint
Project managerul discuta Backlog-ul a a cum este în momentul actual.El preconizează datele posibile ș
de finalizare, care se bazează pe progresul înregistrat până acum.Întregul grup colaborează legat de

ceea ce urmează să implementeze ulterior, pentru că revizuirea Sprintului să furnizeze date de intrare
valoroase pentru următoarea sesiune de planificare a Sprintului.
3.3.6 Retrospectiva Sprintului
Retrospectivă Sprintului reprezintă o oportunitate pentru echipa să se inspecteze pe ea însă i ș
pentru a avea un sprint viitor cât mai bun.Această are loc după revizuirea să i înainte următoarei ș
sesiuni de planificare a Sprintului.Pentru un sprint de o luna durata este de 3 otr iar pentru sprinturile
mai mici durata este una mai mică.Project managerul î i înva ă echipa să nu depă ească limita de timp ș ț ș
definită i participa la edin a că un membru egal al echipei.Prin această retrospectivă a sprintului se ș ș ț
inspectează modul în care ultimul sprint a func ionat, se identifica i se ordonează elementele majore ț ș
care au mers bine i se creează un plan pentru punerea în aplicare a îmbunătă irilor în modul în care î i ș ț ș
desfă oară activitatea echipa. ș
Project managerul încurajează echipa să îmbunătă ească procesul de dezvoltare i practicile ț ș
pentru că dezvoltarea să fie cât mai eficientă pentru sprintul următor.Pe întreagă durata a retrospectivei,
echipa stabile te diverse modalită i de cre tere a calită ii. ș ț ș ț
Capitolul 4. Analiză i Fundamentare Teoretică ș
4.1 Arhitectură client-server
Întrucât aplica ia propusă poate fi folosită o varietate de utilizatori din cadrul unei anumite ț
companii, cea mai potrivită arhitectură este cea de client-server.
Arhitectură client-server reprezintă descompunerea aplica iei în două componente distincte: o ț
componentă client i o componentă server.Componentă client se execut pe o sta ie de lucru de la care ș ț
preia date de la un utilizator, le structurează i transmite cereri de realizare a unor servicii de către ș
componentă server pe baza lor.De cealată parte, server-ul a teaptă cereri de la clien i.Atunci când ș ț
această recep ionează o cere o procesează i returnează rezultatul clientului, iar clientul va comunica ț ș
aceste rezultate utilizatorului prin intermediul interfe ei sale. ț
Elementele caracteristice ale arhitecturilor client-server sunt:

Serviciul client/server care reprezintă o rela ie între procese care se execută pe calculatoare ț
separate.Server-ul furnizează ni te servicii, în timp ce clientul este un consumator de sevicii.În esen ă ș ț
tehnologia client-server furnizaza o separare clară a functionalitatilor pe baza ideii de serviciu.
Resursele partajate, un server poate servi mai mul i clien i în acela i timp controlând accesul ț ț ș
acestora la resursele partajate.
Protocoalele asimetrice între server i clien i: există o rela ie 1-n.Clien ii sunt cei care ini iază ș ț ț ț ț
comunicarea cu un server prin cererea unui serviciu.Serverele sunt entită i pasive care a teaptă cererile ț ș
clien ilor i transmit acestora doar replici la cererile recep ionate. ț ș ț
Transparen ă loca iei, serverul e un proces care poate fi localizat pe acela i calculator că i ț ț ș ș
clientul sau pe unul remote, aflat în re ea.În general se ascunde lcientului informa iile referitoare la ț ț
pozi ia serverului în cadrul unei re ele, redirectand cererile de servicii atunci când e necesar.Un ț ț
program poate fi client, server sau ambele.
Comunica ia bazată pe mesaje, un mesaj specifică server-ului serviciul cerut.Determinarea ț
modului în care este satisfăcută cererea cade în responsabilitatea server-ului.Server-ele pot di
modificate, actualizate i/sau optimizate fără afectarea clien ilor acestora, atâta timp cât interfa ă ș ț ț
rămâne aceea i. ș
Scalabilitatea: sistemele client-server pot fi scalate pe orizontală sau verticală.Scalarea
orizontală reprezintă influen area strictă a performan ei la cre tea sau scăderea numărului de clien i. ț ț ș ț
Integritatea: datele i codul server-ului sunt re inute centralizat, ceea ce implică o actualizare i ș ț ș
securizare eficiente a datelor partajate.În acela i timp, clien ii rămân independen i de server. ș ț ț
În cazul aplica iilor web, comunicarea se bazează pe request-urile HTTP(Hyper Text Transfer ț
Protocol).
Procesul de comunicare prin HTTP se realizează astfel: utilizatorul introduce un URL în
browser-ul pe care îl folose te.Acesta trimite o cerere către serverul care hosteaza site-ul i a teaptă un ș ș ș
răspuns.Serverul analizează cererea, o interpretează i trimite un răspuns corespunzător.Acesta este ș
preluat de câtre client i prezentat utilizatorului. ș
Metodele de tip HTTP sunt:
POST se folose te canse se face o cerere de creare a unei înregistrări noi în baza de date ș
GET utilizată pentru citirea datelor din baza de date
PUT actualizează datele sau le înlocuie te cu altele noiembrie ș
DELETE terge informa ii din baza de date ș ț

4.2 Cerintele sistemului
4.2.1 Cerintele functionale
Pentru a stabili cât mai precis cerintele de baza, e nevoie de o analiza cât mai detaliata
pentru conceptele de baza.Aici voi prezenta pe scurt cerintele functionale pentru aplica ia aleasa. ț
Cerintele sunt:
autentificarea
crearea de utilizator
modificarea informa iilor utilizatorilor ț
stergerea utilizatorilor
crearea proiectelor
stergerea proiectelor
asignarea leader-ului pe proiect
asignarea dezvoltatorilor pe proiect
căutarea utilizatorilor în lista
căutarea proiectului în lista
vizualizarea task-urilor
creare board
stergere board
asignarea utilizatorilor pe un anumit board
crearea sprinturilor în cadrul unui board
crearea Sprinturilor în cadrul unui board
adaugarea de task-uri în Backlog
stergerea de task-uri din Backlog
vizualizarea Backlog-ului
căutarea după numele unui task
vizualizarea task-ului din sprint
pornirea sprintului
finalizarea sprintului
stergerea sprintului
adaugarea de task-uri în sprint
stergerea task-ului din sprint

editarea task-ului
vizualizarea task-ului sub forma de carduri
notificare prin email când are loc o modificare în cadrul unui task
crearea retrospectivei la final de sprint
adaugarea de comentarii la retrospectiva
4.2.2 Cerinte non-functionale
Utilizabilitatea
Aceasta reprezintă u urin a cu care un sistem popate fi învă at i utilizat, siguran a pe care o ș ț ț ș ț
inspira, totodata eficien a dar i atitudinea utilizatorilor în raport cu sistemul. ț ș
Unul din atributele utilizabilitatii este u urin a a înva a aplica ia utilizatorii noi, rapiditatea cu ș ț ț ț
care se familiarizeaza i eficien a cu care utilizatorii avansati se descurca. ș ț
Aplica ia propusa are o interfata simpla, deloc incarcata, în a a fel încât utilizatorii sa găsească ț ș
foarte repede informa iile de care au nevoie denumirile utilizate fiind cât mai u or de recunoscut ț ș
continand cuvinte cheie.
Securitatea
Întrucât aplica ia e dedicata utilizatii interne, datele angajatilor, a proiectelor în care organizatia ț
e implicata trebuie protejate.In acest fel, fiecare utilizator trebuie să fie autentificat pentru a putea folosi
aplica ia.Lucrul acesta se face pe baza unui token, care este unic pe sesiune pentru fiecare utilizator în ț
parte, unde exista o perioada de expirare pentru a nu fi folosit de către cei din exterior.Daca nu exista
acest token, request-urile către server nu voi putea fi realizate.
Extensibilitatea
Extensibilitatea unui sistem e caracteristica prin care determina în ce măsura poate fi exstins sau
reimplementat proiectul.Deoarece aplica ia a fost realizata pe layere, integrarea unor noi functionalitati ț
nu impune o mare dificultate, întrucât nu modifica comportamentul existent deja.

Performan a ț
Reprezintă o măsura care defineste fie volumul de procesari pe unitate de timp pe care o
aplica ie poate sa îl facă sau termenul care trebui respectat pentru a finaliza corect o aplica ie.Timpul de ț ț
răspuns la request-uri depinde de cantitatea de informa ii care e livrata i de complexitatea care se afla ț ș
în spatele prelucrarii datelor.
4.4.Tehnologii folosite
4.4.1 TypeScript
TypeScript este un limbaj de programare open-source, care este construit pe baza
JavaScript.Scopul este sa facă posibil i u or de utilizat bibliotecile existente în JS i de a adauga noi ș ș ș
functionalitati pe lângă cele existente.Se poate folosi pentru partea de client dar i pentru cea de ș
server.Desi este o extensie din JS, TypeScript trebuie să fie compilat în JS înainte sa poată rula într-un
mediu bazat pe JS.Astfel, se poate spune ca orice fisier cu extensia .js este un fisier .ts pentru ca dacă i
se schimba extensia poate fi compilat cu celelalte fisiere de tip .ts.
4.4.2 Angular 7
Angular este o platforma pentru crearea aplicatiilor web, bazata pe HTML i TypeScript.Fiind ș
scrisa în TypeScript, implementeaza functionalitatea sa de baza dar i o serie de biblioteci, ele fiind ș
importate în momentul în care se creeaza proiectul.
La baza unei aplica ii care este făcută în Angular se găsesc a a numitele NgModules, care ofera ț ș
un context de compilare pentru componentele sale.Intotdeauna va exista cel pu in un modul rădăcina, ț
numit AppModule care este folosit pentru pornirea aplica iei.Fiecare modul are asociata una sau mai ț
multe componente, ele fiind încărcate în momentul accesarii paginii asociate.
Spre deosebire de alte platforme pentru a creea partea vizuala, Angular e foarte accesibil i mai ș
simplu de abordat, fiind bine structurat i punând la dispozi ie o multitudine de componente.Din acest ș ț
motiv, am ales sa implementez componenta client folosind acest framework.

4.4.3 HTML
HTML sau HyperText Markup Language este un limbaj de marcare utilizat pentru crearea
paginilor web ce pot fi afisate într-un browser.Scopul este prezentarea informa iilor, specificatile fiind ț
dictate de World Wide Web Consortium sau W3C.HTML e o forma de marcare care e orientata către
prezentarea documentelor text pe o singura pagina, utilizand un soft de redare specializat, numit agent
utilizator HTML, cel mai bun exemplu de astfel de software fiind browserul web.
4.4.4 CSS
CSS sau Cascading Style Sheets este un limbaj pentru stilizare, pentru formatarea diferitelor
documente scrise într-un limbaj de markup precum HTML.Prin intermediul CSS-ului, se pot seta
culoarea textului, stilul fontului, al tabelelor, paragraele, se poate particulariza fundalul unei pagini
web, al unui buton, precum i multe altele.Un lucru important care îl aduce CSS, este faptul ca acela i ș ș
cod se poate refolosi pentru mai multe pagini.
Am ales CSS întrucât faciliteaza stilizarea paginilor web, care poate fi adaptata pentru mai
multe dispozitive.