1.
Arhitectura si managementul
proiectelor

2.
1/19
Arhitectura si managementul proiectelor
Mihai Oaida
• alumni Infoeducatie
• student ETC Timisoara
• web developer
• freelancer
• instructor Tehnologii Web
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" />

3.
Agenda
• arhitectura unui proiect
• teme conexe
– organizarea sursei
– documentatia
– backup-uri
– prezentarea proiectului
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" />
Arhitectura si managementul proiectelor
2/19

4.
• analiza cerintelor
• proiectarea tehnica
• stabilirea deadline-ului
• implementarea proiectului
• validare/testare
• intretinere
• update
Arhitectura si managementul proiectelor
Arhitectura unui proiect
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 3/19

5.
Arhitectura si managementul proiectelor
Proiectarea cerintelor
• ideea initiala
• brainstorming
• definirea specificatiilor proiectului
• confruntarea specificatiilor cu scopul proiectului
si ideea initiala
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 4/19

6.
Arhitectura si managementul proiectelor
Proiectarea tehnica
• alegerea limbajului / platformei
• definirea modulelor
• intocmirea specificatiilor de codare / organizare
fizica
• pentru fiecare segment de proiect se stabileste
un deadline si o prioritate
prioritatile se stabilesc dupa raportul cost / impact
• impartirea lucrului la persoanele care se ocupa
de proiect
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 5/19

7.
Arhitectura si managementul proiectelor
Stabilirea deadline-ului
• suma deadline-urilor pentru segmentele
proiectului
• timpul de testare si debugging
• timp de rezerva (in case s...)
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 6/19

8.
Arhitectura si managementul proiectelor
Implementarea proiectului
• se implementeaza fiecare segment in ordinea
prioritatii
• segmentele se testeaza
• se organizeaza sesiuni de lucru pentru fiecare
segment/subsegment si se finalizeaza
• la fiecare faza de asamblare
– proiectul se confrunta cu specificatiile
– se face o testare generala
– verificarea progresului
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 7/19

9.
Arhitectura si managementul proiectelor
Validare/Testare
• pentru web
– codul xhtml, css se valideaza
– se testeaza pe cat mai multe browsere.
– se testeaza functionalitatea fara css / javascript /
imagini
– se elimina warning-urile si notice-urile.
– se valideaza intrarile (post, get , files) si iesirile din
script
• pentru soft
– se acopera exceptiile
– se valideaza fluxurile de intrare / iesire (socketuri /
fisiere)
• se testeaza modulele cu datele previzibile
• se testeaza cu datele imprevizibile.
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 8/19

10.
Arhitectura si managementul proiectelor
Intretinere
• introducerea de continut
• adaugarea de functionalitati noi
• eliminarea erorilor ramase
• optimizarea
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 9/19

11.
Arhitectura si managementul proiectelor
Update
• presupune proiectarea scalabila a
proiectului
• trebuie sa treaca prin toate etapele unui proiect
• nu trebuie sa influenteze module cu care nu
este interconectat
• pe cat posibil nu trebuie sa cauzeze pierderi de
date
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 10/19

12.
Arhitectura si managementul proiectelor
Organizarea sursei
• Web
– css si javascript in fisiere separate
– se folosesc clase sau id-uri , cat mai putin posibil
inline css
– modulele pe server in fisiere separate
• Soft
– organizare pe functionalitati in
directoare / fisiere
– evitati fisiere mari (ex : 1000 linii)
– design patterns
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 11/19

13.
Arhitectura si managementul proiectelor
Reguli de codare
• numele variabelelor se denumesc cat mai scurt
si cat mai sugestiv
• numele variabelelor au urmatoare forma:
alaBalaPortocala
• numele constantelor au urmatoarea forma
DB_USER
• codul se indenteaza cu 4 spatii sau tab
Ex : if(isset($_POST[’add’])){
addNewsProcess();
}
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 12/19

14.
Arhitectura si managementul proiectelor
Documentatia
• o varianta initiala sunt specificatiile
• documentatia pentru fiecare functie de baza :
descriere, paramentrii
• explicatii legate de organizarea proiectului
• la inceputul fiecarui fisier se va scrie data
creerii si a ultimei modificari , numele
programatorului , modulul si proiectul
• scopul documentatiei
1.pentru update-uri
2.pentru celelalte personae care lucreaza la proiect
3.in cazul in care proiectul este continuat de alte
persoane
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 13/19

15.
Arhitectura si managementul proiectelor
Backup-uri
• se fac periodic , fie la fisiere separate fie la
proiect ca si ansablu
• se pun intr-o locatie sigura (chiar mai multe
locatii)
• fiecare backup are o data exact si eventual o
mica descriere
• scop backup-ului
1.In cazul in care se distruge varianta de lucru
2.In cazul in care se vrea sa se revina la vechea
varianta
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 14/19

16.
Arhitectura si managementul proiectelor
Prezentarea proiectului #1
• se intocmeste o documentatie de prezentare
• project managerul este cel mai potrivit pentru
rolul de prezentator
• se detaliaza doar partile critice
• se organizeaza o lista cu functionalitati ce vor fi
demonstrate.
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 15/19

17.
Arhitectura si managementul proiectelor
Prezentarea proiectului #2
• nu trebuie parcurs TOT proiectul si nu trebuie
aratat ca TOTUL merge
• NU este NICIODATA destutul timp pentru a
prezenta TOT proiectul
• trebuie sa dai impresia ca l-ai prezentat pe
TOT
• TOATE intrebarile se pun la SFARSIT
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 16/19

18.
Arhitectura si managementul proiectelor
Prezentarea proiectului #3
• trebuie captata atentia , publicul se plictiseste
repede
Aceasta se poate obtine prin interactivitate
• prezentare cu voce tare , siguranta pe sine ,
atitudine impunatoare.
• balbaiala si pauzele de genu “aa” sunt semne
de nesiguranta si neincredere.
• prezentatorul trebuie sa se uite la sala , pe cat
posibil in ochii publicului
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 17/19

19.
Arhitectura si managementul proiectelor
Intrebari?
<lector nume="Mihai Oaida" email="mihai.oaida@gmail.com" /> 18/19