Se prezinta arhitectura generala a unui proiect, de la analizarea cerintelor pana la activitatea de mentenanta si update. La fiecare pas sunt expuse probleme de ordin managerial si, daca este cazul, solutii.

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