Buna ziua,
Va trimitem alaturat informatii mai multe(si partial modificate) despre
proiectul pe care il sustinem la dumneavoastra.
Costin GRIGORE (raiser@home.ro)
Mihai CHIRCU (mchircu78@yahoo.com)
Sorin OSTAFIEV (sostafiev@softwin.ro)
Dorim sa facem o aplicatie web-based care sa se constituie intr-un
portal de informatii pentru toti oamenii dintr-o facultate (pentru inceput
utlizatorii sa fie doar profesori-elevi).
Aplicatia demo se va baza pe un mediu in care sa se poata adauga diverse
componente numite "portleti". Acestia sunt componente care pot face
cereri de informatii catre mediul de portleti si apoi pe baza acestuia pot
genera un content grafic specific. O pagina web este dinamic construita din
portleti total independenti. Exista deasemenea si portleti container al carui
rol este doar acela de manageri de layout. Un exemplu de site care ar putea fi
realizat usor cu aceasta arhitectura este: http://eclipse-plugins.2y.net/eclipse/index.jsp
Concret, dorim sa realizam serverul de portleti si urmatorii portleti:
a)
portleti generici
-
portlet welcome
-
portlet contact
-
portlet login
-
portlet reclama
-
portlet meniu
-
portlet generic insert/update/select informatii din baza de date (i se
da doar tabela) - va fi folosit ca prim model pentru orice alt portlet, bazat
pe baza de date, customizat.
-
portlet anunturi1 ( specializare a portletului generic pe o
tabelaanunturi )
-
portlet anunturi2 ( rescriere (alta interfata) pentru acces specific la
tabela anunturi )
-
portlet upload
-
portleti de layout
b)
portleti specifici
-
portlet universitate (listeaza facultatile)
-
portlet facultate (listeaza specializarile)
-
portlet specializari (listeaza materii/pe ani)
-
portlet materie (curs/seminar/laborator)
-
contact
-
anunturi
-
note
-
referinte
-
portlet teme
-
enunturi
-
upload
-
note
Modelul de dezvoltare ales este unul de tip Rapid
Development, si anume un model Evolutionary Prototype, inspirat in principal de
Extrame Programming.
Asa cum este
definit, Extrame Programming recomanda 12 practici, din care, insa, vor vor fi
adoptate doar o parte.
Dupa [1] practicile XP sunt urmatoarele:
1.
on-site customer
2.
small releases
3.
metaphor
4.
testing
5.
simple design
6.
refactoring
7.
pair programming
8.
planning game
9.
sustainable development
10. collective ownership
11. coding standards
12. continous integration
Conform cu modelul Evolutionary prototype trebuie sa
existe o faza de culegere a cerintelor. Aceasta faza va fi insa minimala si va
fi utilizata doar pentru estimari de principiu, conform cu practicile XP.
Cerintele detaliate vor fi specificate inaintea fiecarui task planificat pentru
dezvoltare in iteratia urmatoare.
Practica on-site customer va fi una virtuala
deoarece echipa noastra va avea si acest rol. Pe rand fiecare din noi va juca
jocul clientului care doreste o anumita functionalitate ceilalti doi jucand
rolul de tehnicieni. “Clientul” va trebui sa se exprime doar in termini
nontehnici pentru a comunica cu developerii.
Practica small releases va fi adoptata in
intregime dorindu-se ca o data pe saptamana, la sfarsitul saptamanii, sa se
faca un “release de piata”. Deci ciclul de iteratie este de 1 saptamana.
Ca metafora avem portletul care este o
componenta care are ca intrari informatii specificate si genereaza content
grafic. Intreaga arhitectura este un container de astfel de componente grafice.
Testarea
va fi facuta prin teste unitare si teste de acceptanta. Testele vor fi scrise
inainte de a se dezvolta fiecare functionalitate. Deasemenea la gasirea unui
bug vor fi scrise mai intai testele care il pun in evidenta urmand abia apoi
corectarea implementarii respectivei functionalitati. Testarea se face automat
; chiar din etapa de specificatii construindu-se bateri de teste pentru
functionalitatile ce vor fi implementate.
Designul va respecta in general practica simple
design, cu mentiunea ca va fi necesar un design initial, de dimensiuni mai
mari pentru creearea containerului de portleti. Designul va evolua de-a lungul
dezvoltarii proiectului si datorita refactoringului recomandat de XP. Se
cauta solutiile cele mai simple si codul trebuie sa reflecte acest lucru. In
orice moment nu trebuie sa existe concepte sau cod nefolosite activ in proiect.
Orice dezvoltare viitoare va fi integrata cu actuala solutie printr-un eventual
refactoring, de un mare ajutor fiind testele automate a functionalitatilor.
In ceea ce priveste practica pair programming,
aceasta nu va fi folosita deoarece echipa nu va lucra in acelasi loc decat
pentru cateva sedinte de design initiale si in alte cazuri speciale. Se
experimenteaza in felul acesta o solutie de dezvoltare a aplicatiilor bazata pe
oameni la distanta. Exista un plugin aflat in faza de dezvoltare finala, in
ide-eul pe care vrem sa-l folosim, pentru programare pair la distanta.
Comunicarea va fi asigurata prin conferinte permanente online. Alte solutii
care pot suplini incapacitatea de a programa pair, sunt sugerate de [1] inspectii si masuratori ale codului.
Pentru planning game avem doua posibilitati:
a) la inceputul fiecarei iteratii noi hotaram care
sunt cele mai importante features pe care le dorim implementate, sau
b) intr-o varianta mult mai dinamica, dumneavoastra
alegeti din lista de taskuri altele, eventual cu cerintele modificate.
Jocul poate fi modelat atat prin cerinta speciala de
features cat si prin specificarea unor termene pana la care trebuie
implementate cele mai importante features.
Pentru respectarea principiului de sustainable
development, care stipuleaza ca un dezvoltator are o limita maxima a
efortului peste care daca trece o face pe seama randamentului si moralului,
avem in vedere propunerea unor release-uri de principiu permitandu-se lipsa
unor feature-uri cerute in ultimul release-plan.
Proprietatea asupra codului este colectiva (collective
ownership), oricine putand mofica/aduaga la nevoie orice bucata de cod, in
felul acesta eliminandu-se redundantele.
Acest principiu impreuna cu cel de standarde de
dezvoltare(coding standards) si integrare continua (continuous
integration)urmaresc cresterea producticitati, prin reducerea efotului investit
in documentiea ampla, sau in implementarea unor facilitate nefolosite momnetan
dar create pentru a preintampina evetualele modificari viitoare.
Standardele privind modul cum se scrie codul sursa
trebuie sa fie usor de inteles, acesta reprezentand in cele mai multe cazuri
singura documentatie disponibila.
Acest model este un model hibrid Evolutionary
Prototype si Spirala cu spirala cuprinzand nu numai faza de dezvoltare ci si
cea de design. In plus testele Q/A (unitare si acceptanta) sunt eliminate prin
teste automate, iar cicli de dezvoltare sunt mult mai scurti.
Modelul
ales se preteaza bine proiectelor in care cerintele si/sau specificatiile se
modifica dinamic si permanent, cu comunicare directa, fara documente multe.
Deasemenea avand in vedere marimea, timpul si complexitatea proiectului, acest
model este de dorit. Adoptarea lui a fost influentata si de overheadul mediu pe
care il impune.
[1] Extreme
Programming – Rapid Development for Web-Based Applications (http://sern.ucalgary.ca/~milos/papers/2002/MaurerMartel2002d.pdf)
[3] xprogramming.com
[4] jUnit (http://www.junit.org)