pr8 PDF

Platformă de e‐learning și curriculă
gș e‐content
pentru învățământul superior tehnic
 Instrumente pentru Dezvoltarea Programelor
p g
8. Instrumente software si paradigma Rapid software
p g p
development.
Platformă de e‐learning și curriculă e‐content pentru
învățământul superior tehnic
Sumar
 Metode Agile
SCRUM
eXtreme Programming
 Testare – JUnit
 Rapid Application Development
 Prototipare
IDP – Instrumente pentru Dezvoltarea Programelor 2
Metode Agile
“We
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
•Individuals and interactions over processes and tools

•Working software over comprehensive documentation
•Customer collaboration over contract negotiation
•Responding to change over following a plan
That is, while there is value in the items on

the right, we value the items on the left more. “
(The Agile Manifesto) - http://agilemanifesto.org/

Procese adaptive vs. predictive
p p
Adaptive Predictive
• Categorie uşoară, ‘agile’ • Categorie grea, ‘traditional’

• Control prin feedback • Control prin planificare
• Multe iteraţii scurte • Câteva iteraţii lungi (luni)
(săptămâni) • S ă mare (>30
Scară ( 30 dezvoltatori)
d lt t i)
• Scară mică (<10 dezvoltatori) • Documente scrise
• Comunicare faţă-în-faţă • Centrate pe reguli
• Centrate pe cod şi oameni • Autoritariene
• Egalitariene
• Probleme:
• Probleme: – Inflexibilitate la modificările
– Rezultatele de lungă durată cerinţelor
puţin predictibile – Efort mărit de Integrare şi
– Haos asociat cowboy-coding testare
– Birocraţia asociată ‘Control
Control
freak’
• E.g. XP
• E.g. waterfall
R id S f
Rapid Software Development
D l
 Adaptarea continuă a organizaţiei
Adaptarea continuă a organizaţiei
Oportunităţi noi de business
Modificarea mediului de business, competiţia
 Fapt: Rapiditatea dezvoltării şi livrării cel mai des
Fapt: Rapiditatea dezvoltării şi livrării cel mai des
reprezintă o cerinţă critică pentru sistemele software.
 Fapt: Organizaţiile sunt dispuse să accepte calitate mai
Fapt: Organizaţiile sunt dispuse să accepte calitate mai
slabă a software‐ului dacă este posibilă dezvoltarea
rapidă a unor funcţionalităţi critice (speed‐to‐market,
time to market)
time‐to‐market)
C i
Cerinţe
 Mediu în continuă schimbare =>
M di î i ă hi b
este imposibil de ajuns la un set de cerinţe stabil şi consistent
(modificări ale cerinţelor on the fly)
(modificări ale cerinţelor on‐the‐fly)
 Modelul de dezvoltare în cascadă se dovedeşte nepractic în
astfel de situaţii
astfel de situaţii
 Mai adecvată este o abordare bazată/orientată pe specificaţii şi
livrare iterative
Software‐ul livrat (mai) rapid
Raportul Haos:
l
 Început în 1994, studiul a evaluat peste 35.000 de proiecte software
 Situația la nivelul anului 2000:
Sursa: Standish “Chaos” Report, Jim Johnson lecture at XP2002 conference,
p
http://www.xp2003.org/xp2002/talksinfo/johnson.pdf
C
Caracteristicile proceselor RAD
i i il l RAD
 Procesele de specificare, proiectare
p ,p şşi implementare
p sunt
concurente
Nu există specificaţie detaliată
Documentaţia
Documentaţia proiectării este minimală
 Sistemul este dezvoltat într‐o serie

într‐o serie de incremente
de incremente
Utilizatorii finali evaluează fiecare incrementare
Propuneri pentru incrementările următoare
 Interfeţele utilizator sunt de obicei dezvoltate folosind un

sistem
it d d
de dezvoltare
lt i t
interactiv
ti
Un proces de dezvoltare iterativă
Avantajele dezvoltării incrementale
 Livrarea rapidă a produselor/serviciilor către clienţi.
Fiecare incrementare livrează clienţilor funcţionalitatea având
următoarea “cea mai mare” prioritate.
 Antrenarea utilizatorilor în dezvoltarea sistemului. Utilizatorii
sunt implicaţi în dezvoltare =>> sistemul este dezvoltat în jurul
sunt implicaţi în dezvoltare sistemul este dezvoltat în jurul
cerinţelor impuse; utilizatorii sunt mai devotaţi sistemului
Problemele dezvoltării incrementale

Problemele dezvoltării incrementale
 Probleme de management
Progresul
Progresul poate fi greu de apreciat
poate fi greu de apreciat
Problemele sunt greu de rezolvat deoarece nu există nici o
documentaţie care să demonstreze corectitudinea implementării.
 Probleme contractuale
Contractul în mod normal include o specificaţie; fără o specificaţie
trebuie folosite forme diferite de contractare.
 Probleme de validare
Fără o specificaţie contra a ce probleme ar trebui sistemul testat?
 Probleme de mentenanţă
Schimbările continue tind să corupă structura software‐ului
Costuri mari implicate pentru modificarea şi actualizarea
software‐ului în cazul apariţiei unor cerinţe noi
P
Prototyping
i
 Pentru unele sisteme mari dezvoltarea iterativă incrementală
poate fi nepractică
Ex: mai multe echipe lucrează în diverse locaţii la acelaşi proiect
 Prototiparea
Un sistem experimental este dezvoltat ca bază pentru formularea
cerinţelor
Sistemul
Sistemul experimental nu mai e necesar după ce se ajunge la un consens
experimental nu mai e necesar după ce se ajunge la un consens
cu privire la specificaţiile de implementat
 Un prototip poate fi folosit în:
Procesul de inginerie a cerinţelor pentru a ajuta la stabilirea şi validarea
P ld i i i i ţ l t j t l t bili i lid
cerinţelor;
În procesul de proiectare pentru explorarea opţiunilor şi dezvoltarea unui
g ;
design UI;
În procesul de testare pentru rularea unor verificări back‐to‐back.
Dezvoltarea incrementală şi prototiparea
Dezvoltare
Sistemul livrat
incrementală
Cerinţe
Throw-away Prototipul executabil +

prototyping Specificaţia sistemului
D
Demo…
Obi i
Obiective conflictuale
fli l
 Obiectivul dezvoltării incrementale îl constituie
îl constituie livrarea
unui sistem funcţional către utilizatorii finali
Dezvoltarea începe cu cerinţele ce sunt cel mai bine înţelese.
 Obiectivul abordării “throw‐away

throw‐away prototyping
prototyping” este
este de
de
a valida sau deriva cerinţele sistemului
Procesul de prototipare
p p începe
p cu acele cerinţe ce
ţ sunt cel
mai puţin înţelese.
M d
Metode agile
il
 Insatisfacţiile cu overhead‐ul
ţ implicat de metodele de
p
proiectare au condus la crearea Metodelor Agile.
 Metodele agile:
Focus pe cod, nu pe design;
Bazate pe o abordare iterativă a dezvoltării software;
Focus pe livrarea rapidă de software funcţional care evoluează spre a
satisface cerinţele în continuă schimbare
satisface cerinţele în continuă schimbare.
M
Metodele agile sunt adecvate în special sistemelor de business
d l il d î i l i l d b i
de mărime mică şi medie sau produselor PC.
A il S f
Agile Software Development
D l
 A apărut în anii 1990 ca reacţie la metodele tradiţionale
“
“greoaie” de dezvoltare
”d d l
 Presupune multe iteraţii scurte (săptămâni) şi ‘prototiparea’:
Iteraţie
#1 Analiza Proiect Implementare Testare Prototip
#2 A li
Analiza P i
Proiect Implementare Testare P
Prototip
i
#3 Analiza Proiect Implementare Testare Prototip
…
 Control
Control prin feedback: re‐evaluarea şi revizia proiectului după
prin feedback: re evaluarea şi revizia proiectului după
fiecare iteraţie
P i i iil
Principiile metodelor agile
d l il
Principiul Descriere
Implicarea clientului Clientul trebuie să fie implicat în procesul de dezvoltare. Rolul

său este de a furniza şi prioretiza noi cerinţe ale sistemului şi
de a evalua iteraţiile sistemului.
Livrarea incrementală Software-ul este dezvoltat în incremente, clientul având rolul

de a specifica cerinţele ce sunt incluse în fiecare increment.
Oameni nu procese Capabilităţile echipei de dezvoltare trebuie să fie recunoscute

şii exploatate.
l t t Echipa
E hi ttrebuie
b i lă
lăsată
tă să-şi
ă i exercite
it propriile
iil
metode de lucru fără un proces prescriptiv.
Adoptarea schimbării Cerinţele sistemului sunt în permanentă schimbare şi sistemul

trebuie
b i proiectat
i a.î.
î să acomodeze
d aceste schimbări.
hi b i
Menţinerea simplităţii Focus pe simplitate atât în software-ul dezvoltat, cât şi în

procesul de dezvoltare folosit. Pe cât posibil se recomandă
eliminarea
li i complexităţii
l ităţii din
di sistem.
i t
Practici Agile
l
 Delimitări Sandbox / Environment
/
P bl
Problemele metodelor agile
l d l il
 Dificil de menţinut interesul clienţilor implicaţi în procesul de
dezvoltare
 Membrii
Membrii echipei pot fi neadecvaţi pentru interesul intens în
echipei pot fi neadecvaţi pentru interesul intens în
dezvoltarea proiectului cerut de metodele agile
 Prioretizarea schimbărilor poate fi dificilă atunci când sunt mai
mulţi acţionari implicaţi
li i i i li i
 Menţinerea simplităţii necesită muncă suplimentară
 Contractele pot fi o problemă (similar altor metode de
dezvoltare iterativă)
Deci ce Metode Agile există?
d l ă?
 Extreme Programming
i (XP) (Kent Beck, Ward Cunningham, Ron
( )( k d h
Jeffries)
 Scrum (Jeff Sutherland, Mike Beedle, Ken Schwaber)
(Jeff Sutherland Mike Beedle Ken Schwaber)
 DSDM – Dynamic Systems Development Method (Community
owned))
 Crystal (Alistair Cockburn)
 ASD – Adaptive Software Development (Jim Highsmith)
Adaptive Software Development (Jim Highsmith)
 XBreed (Mike Beedle)
Deci mai mult decât …
Studiu de caz:
Metodele de dezvoltare SCRUM
Ce înseamnă SCRUM?
î ă ?
 Posibil asta:
P ibil
SCRUM
 Proces de dezvoltarea iterativ‐incrementală
 Include un set de practici
I l d td ti i si roluri
i l i predefinite (“Pig”
d fi it (“Pi ” și “Chicken”)
i “Chi k ”)
Product Owner
•Vocea clientului
•Definește cerințele business
•Deține “product backlog”
Scrum Master
•Administrează procesul SCRUM
p j g ( )
•Aproximativ Project Manager (dar nu există acest rol)
Team
•Aproximativ 7 persoane (grupul de lucru)
•Are responsabilitatea livrării produsului
•Abilități diverse pentru efectuarea activităților (proiectant, dezvoltator, tester, etc.)
Echipa SCRUM
h
 Auto‐organizată
 Membrii nu au roluri bine definite
Pot lucra în oricare activitate și grup.
 Membrii echipei SCRUM sunt cunoscuți ca
g
Pigs
Sunt devotați pentru livrarea scopului Sprint
 Persoanele implicate dar care nu sunt
Persoanele implicate dar care nu sunt
devotate proiectului sunt Chickens
Participă
Participă la întâlnirile Scrum
la întâlnirile Scrum doar ca
doar ca
observatori
“
“You’re Fired!”
’ d!”
O metrică simplă:
Dacă poți fi concediat
pentru eșecul
p ș proiectului
p –
ești pig.
Dacă îți păstrezi job-ul
job ul, în
ciuda eșecului proiectului –
ești
ș chicken.
Practici SCRUM
• Sprint
– Perioadă cuprinsă între 2 și 4 săptămâni
– Nimeni nu p poate modifica Spring
p g Backlog-ul g în
timpul Sprint-ului
– Rezultat final: un increment potențial funcțional
((software funcțional
ț și
ș testat))
– Final: rezultatul este în general însoțit și de un
demo
 Product Backlog
Set prioretizat (funcție de importanță) de cerințe
funcționale
Exemplu ‐
l Product Backlog
d kl
Practici SCRUM
 Sprint Planning Meeting
Ședință ce conduce la luarea deciziilor privind ce itemi
Ș ț p de Backlogg sunt
incluși în următorul Sprint
 Sprint Backlog
Itemii
It ii ce se urmăresc a fi rezolvați într‐un Sprint
ă fi l ți î t S i t
Product Backlog
Capabilităţile
Echipei
Condiţii Business Review Next Sprint Goal
Consider
Stabilitate
Organize Sprint Backlog
Tehnologică
Incredement
E
Executabill all
Produsului
Exemplu ‐ Sprint Backlog
Ciclurile de dezvoltare SCRUM

Ciclurile de dezvoltare SCRUM
24 hours
Daily Scrum
Meeting
Backlog tasks 30 days

expanded
Sprint Backlog by team
Potentially Shippable
Product Backlog Product Increment
As prioritized by Product Owner
Î âl
Întâlniri…
 Daily Scrum
Daily Scrum
Întâlnire zilnică de lucru în timpul SPRINT‐ului.
Începe
Începe la ore fixe.
la ore fixe.
Toți sunt bineveniți, dar doar “pigs” pot vorbi.
În timpul întâlnirii fiecare membru răspunde la:
p p
Ce ai făcut de ieri?
Ce planuri ai pentru ziua de astăzi?
Ce probleme prevezi că pot apărea ce ar putea să te împiedici să termini cu
succes activitățile?
Întâlniri…
Întâlniri
 Scrum of scrums
Întâlnire zilnică, de obicei după Daily Scrum.
Întâlniri ce permit echipelor diferite să discute activitățile, cu
accent pe integrare și suprapuneri
accent pe integrare și suprapuneri de activități.
de activități
Participă câte o persoană delegată din fiecare echipă.
Agenda similară cu cea a Daily Scrum, dar mai apar și alte
Agenda similară cu cea a Daily Scrum dar mai apar și alte
patru întrebări:
Ce a făcut echipa de la ultima întâlnire?
Ce va face echipa până la următoarea întâlnire?
Există
Există ceva ce poate încetini activitatea echipei?
ceva ce poate încetini activitatea echipei?
Există modificări în modul de lucru sau componența echipei?
Î âl
Întâlniri…
 Sprint Planning Meeting
p g g
La începutul unui nou Sprint.
Se selectează activitățile ce vor fi făcute în cadrul Sprint‐ului curent => Sprint
Backlogg
Se identifică și se comunică volumul de muncă preconizat a fi făcut în timpul
Sprint‐ului curent
 La sfărșitul Sprint‐ului mai apar două întâlniri:
La sfărșitul Sprint‐ului mai apar două întâlniri:
 Sprint Review Meeting
 Sprint Retrospective
p p
Avantaje SCRUM
 SCRUM facilitează crearea unor echipe self‐organizate
 Încurajează co‐locarea membrilor echipei și
Î j ă l b il hi i i
 Comunicația verbală între membrii echipei
O l S
Oracle Support –
t KM
KM
Mai multe…
Recomandări bibliografice:
Recomandări bibliografice:
 http://www.scrumalliance.org/
 Cartea
Cartea “Agile
Agile Software Development with SCRUM
Software Development with SCRUM” ‐ Ken Schwaber, Mike
Ken Schwaber, Mike
Beedle
 Cartea “Agile Project Management with SCRUM” ‐ Ken Schwaber
 http://www.controlchaos.com/ ‐ Site‐ul lui Schwaber
Studiu
Studiu de Caz: eXtreme Programming
de Caz: eXtreme Programming
Instead of cowboy coders we have

software sheriffs; working together as a
team, quick on the draw, armed with a
few rules and practices that are light,
concise and effective.
concise, effective
(James D. Wells,
extremeprogramming.org)
eXtreme Programming (1)
 Una dintre cele mai cunoscute metode Agile –
di l i d il abordare bazată
b d b ă
pe tactici duse la extrem:
 If testing is good,
If testing is good let everybody test all the time
let everybody test all the time
 If code reviews are good, review all the time
 If design is good,
If design is good refactor all the time
all the time
 If integration testing is good, integrate all the time
 If
If simplicity is good,
i li it i d do the simplest thing that could possibly
d th i l t thi th t ld ibl
work
 If short iterations are good,
If short iterations are good, make them really, really short
make them really, really short
X P i (2)
 XP=eXtreme Programming: Nomen est omen, abordare centrată pe
cod
 Cultura XP: mai mult decât a face ca proiectul să meargă
 Se bazează pe
îmbunătăţirea constantă a codului
includerea utilizatorului în echipa de dezvoltare
programare pairwise
programare pairwise
X P i (3)
 Noi versiuni pot fi construite chiar de mai multe ori pe
zii
 Incrementele sunt livrate la fiecare 2 săptămâni
 Toate testele trebuie să fie executate pentru fiecare
build
 Set de practici uzuale pentru dezvoltatori şi manageri
ce încurajează
j
5 valori
12 practici/reguli
C l 5 l i XP
Cele 5 valori XP
1. Comunicare
 Teamwork: vederi consistente asupra sistemului
 Mediu de lucru deschis: dezvoltatori, manageri, clienţi
 Conversaţii verbale, informale, faţă‐în‐faţă
2 Feedback
2.
 Găsirea unor modificări necesare ASAP pentru evitarea cheltuielilor
 Din partea clientului, prin prototipuri şi comunicări incipiente
 Testare, code review, estimări ale echipei
3 Simplitate
3. Si lit t
 Construirea celor mai simple lucruri care funcţionează pe moment
 Nimic nu se construieşte ce ar putea fi nefolositor mai târziu
 Proiectele simple facilitează comunicarea mai uşoară Cost of
4. Curaj change
 De a schimba şi de a sfărâma, “embrace change”
 Mai bine modifică pe loc (cheaper)
 Niciodată nu te da bătut (Never give up!)
g p Point of time
5. Respect pentru echipă şi munca proprie within project
C l 12
Cele 12 practici XP (1)
i i XP (1)
Fine scale feedback
1
1. Pair Programming
Pair Programming
 Programarea în echipe de câte doi: driver şi navigator
2. Planning Game: metoda de planificare a proiectului împreună cu clientul
3. Test Driven Development
Test Driven
 Întâi se scriu cazuri de test, ulterior codul programului
 Pentru fiecare defect se introduce un nou caz de test
4. Whole Team: echipa de clienţi, dezvoltatori, manageri
Shared understanding
5. Folosirea unui Coding Standard de comun acceptat
6
6. C ll i C d O
Collective Code Ownership
hi
 Toată lumea este responsabilă de întreg codul şi oricine poate modifica în oricare
parte a codului
7. Simple Design
8. System Metaphor
 Numirea părţilor din program folosind nume consistente, intuitive
C l 12
Cele 12 practici XP (2)
i i XP (2)
Continuous process
9. Continuous Integration
 Lucru cu ultimele versiuni ale codului
 Integrarea schimbărilor locale ASAP
10. Refactoring
 Îmbunătăţirea proiectului când este posibil
 Înlăturarea complexităţii inutile
p ţ
11. Small Releases
Programmer welfare
12. Sustainable Pace
 Nu
Nu se lucrează
se lucrează în regim
în regim Overtime – mai degrabă se modifică
se modifică
graficul de proiect sau chiar scopul final
T
Terminologia XP
i l i XP
 User story
User story
Funcţionalităţile pe care sistemul trebuie să le ofere utilizatorilor
Scrise de obicei pe o cartelă în câteva fraze
Ar trebui să necesite 1‐3 săptămâni pentru implementare
 Release: sistem rulabil ce implementează “user stories”‐urile
importante
 Spike
Prototip folosit ca proof‐of‐concept
ca proof of concept
Explorează fezabilitatea unei abordări a implementării
 Iteration
Fază
Fază a implementării, de durata
a implementării de durata 1 1‐3
3 săptămâni
săptămâni
Conţine task‐uri, fiecare de durata 1‐3 zile
 Project velocity: folosit ca unitate de estimare a progresului
Fie #stories / timp
/ p
Fie time / #stories
E
Etapele dezvoltării XP
l d l ă ii XP
User Project velocity Defects
Stories
Release
Planning Iteration Tests
New Next Small

User Story Iteration
Release
Uncertain Confident = is followed by
Estimates Estimates
Spike = result goes into

46
User Stories
S
Scenariile cerinţelor
iil i l
 În XP cerinţele utilizatorilor sunt specificate sub formă
În XP cerinţele utilizatorilor sunt specificate sub formă
de scenarii scrise pe carduri
Un user story este o scurtă descriere a ce se doreşte, scrisă de
client în terminologia acestuia, fără sintaxă tehnică.
li t î t i l i t i fă ă i t ă t h i ă
 Echipa de dezvoltare le transpune în task‐uri de
implementare
 Task‐urile constituie baza planificării dezvoltării şi a
costurilor estimate
 Clientul alege scenariile ce pot fi incluse în noile
versiuni ale produsului, pe baza prorităţilor şi a
estimărilor de planificare
E St
Ex: Story card for document downloading
df d td l di
Downloading and printing an article
First, you select the article that you want from a displayed list. You
then have to tell the system how you will pay for it – this can either
be through a subscription, through a company account or by credit
card.
After this, you get a copyright form from the system to fill in and,
when
h you haveh submitted
b itt d this,
thi the
th article
ti l you wantt is
i downloaded
d l d d
onto your computer.
You then choose a pprinter and a copy

py of the article is pprinted. You
tell the system if printing has been successful.
If the article is a print-only article, you can’t keep the PDF version
so it is automatically deleted from your computer.
computer
E
Exemplu
l Story card-urile cuprind
cel mai adesea
aproximativ trei fraze,
scrise pe 4x6
4 6 cards
cards.
"Tell me the story and write down the name of the story and a paragraph or two."
License Enforcement
When run for the first time, JeraWorks puts up a license dialog, and will not proceed until
the user enters either:
• a valid non-time-limited (paid) license certificate or

• a valid time-limited (demo) license that has not yet expired.
A valid license is stored so the user doesn't have to re-enter it on subsequent runs.
License info is displayed on the splash screen.
When a demo license expires, the license dialog re-appears the next time JeraWorks is run.
I'll put on my "Development" hat tomorrow and estimate this.

Tomorrow or 'mañana'?
XP i hi b
XP şi schimbarea
 ÎÎn mod tradiţional
d di i l un dezvoltator
d l software este
f considerat
id
înţelept atunci când proiectează soluţii luând în considerare
posibile extensii şi modificări ulterioare.
se recomandă pierderea timpului şi un efort mai mare pentru anticiparea
schimbărilor pentru că acest lucru poate duce la costuri mai reduse în
viitor în ciclul de dezvoltare
 Abordarea XP susţine că tot acest efort este inutil
în realitate, schimbările ce pot interveni nu pot fi niciodată cu adevărat
anticipate.
anticipate
 XP propune îmbunătăţirea constantă a codului (refactoring)
pentru a face modificările mai uşor de integrat
p ş g în proiect
p
T
Testarea în abordarea XP
î b d XP
 Dezvoltare bazată pe abordarea “test‐first”
p
 Dezvoltarea incrementală a testelor pornind de la
scenarii
 Includerea utilizatorilor în dezvoltarea şi validarea
testelor
 Toate componentele testelor sunt rulate folosind
instrumente de testare automată
instrumente de testare automată
 Testarea executată cu fiecare versiune nouă
Ex: Task cards for document downloading
Task 1: Implement principal workflow
Task 2: Implement article catalog and selection
Task 3: Implement payment collection
Payment may be made in 3 different ways. The user

selects which wayy they y wish to ppay
.yIf the user
has a library subscription, then they can input the
subscriber key which should be checked by the
system. Alternatively, they can input an organisational
account number. If this is valid, a debit of the cost
of the article is posted to this account.
account Finally
Finallythey
, they
may input a 16 digit credit card number and expiry
date. This should be checked for validity and, if
valid a debit is posted to that credit card account.
D
Descrierea cazului de test
i l id
Test 4: Test cr edit card validity
Input:
A string representing the credit card number and two integers representing
the month and yyear when the card expires
p
Tests:
Check that all bytes in the string are digits
Check that the month lies between 1 and 12 and the
year is greater than or equal to the current year .
U i the
Using h first
fi 4 digits
di i off the
h credit
di cardd number
b ,
check that the card issuer is valid by looking up the
card issuer table. Check credit card validity by submitting the card
number and expiry date information to the card
issuer
Output:
OK or error message indicating that the card is invalid
T
Test‐first development
fi d l
 Scrierea testelor înaintea codului poate duce la clarificarea
cerinţelor ce se vor implementate
 Testele sunt scrise sub formă de programe, putând fi

executate automat
 Un test include o verificare a unei funcţionalităţi
 Toate testele anterioare şi cele noi sunt rulate automat

odată cu introducerea
cu introducerea unei noi funcţionalităţi în proiect
în proiect
Verificare că noua funcţionalitate nu a introdus erori în proiect
P i
Pair programming
i
• Doi oameni lucrând la o aceaşi
maşină, cu o singură tastatură şi
un singur mouse
• Două roluri:
– implementare
– strategie
 În abordarea XP
programatorii lucrează în
echipe, conlucrând la scrierea
codului
A
Avantaje
j
 dezvoltarea simţului proprietăţii asupra codului
dezvoltarea simţului proprietăţii asupra codului
 răspândirea cunoştinţelor referitoare la proiect între
toţi membrii echipei de dezvoltare
 deoarece fiecare linie de cod este vizualizată de mai
multe persoane, serveşte şi ca proces de verificare
informală
 încurajează refactorizarea
 Măsurătorile arată că productivitatea dezvoltării
folosind această abordare este comparabilă cu aceea în
care doi indivizi lucrează indepedent
d i i di i i l ăi d d
R
Reguli şi practici simplificate
li i i i i lifi
 Planning • g g
Designing
 User Stories • Simplicity
 Release Planningg • System Metaphor
• CRC cards
 Small Releases
• Spike solutions
 Measure Project Velocity
Measure Project Velocity
• YAGNI
G
 Divide project to iterations • Refactor
 Iterations Planning
Iterations Planning
 Move People around
 Stand up meeting
d
R
Reguli şi practici simplificate
li i i i i lifi
 Coding
 Customer available
Customer available • Testing
 Code standards • Unit test everything
• All tests pass before
 Test‐Driven
Test Driven release
 Pair Programming • Bug== new test
• Acceptance tests
 Sequential
Sequential change
change
integration
 Integrate often
 Collective code ownership
 Don’t optimize early
 No overtime
H
Harta XP ‐
XP Proiect
P i
H
Harta XP –
XP Iteraţie
I i
H
Harta XP ‐
XP Dezvoltare
D l
Harta XP Drepturi comune asupra codului
Harta XP – Drepturi comune asupra codului
Practicile XP sunt inter‐dependente
i il i d d
On-site Customer Planning game
40 Hour Week
Metaphor
Simple Design
Refactoring
Sh t R
Short Releases
l
Pair Programming Testing
Coding Standards
Collective Ownership Continuous Integration
Sursa: Beck, Extreme Programming Explained: Embrace Change, 1999

Exemplu de Implementare XP
e p u de p e e ta e
Exemplul de Programare XP :
Acesta este un exemplu foarte primitiv de folosire a metodologiei de
programare XP pentru revitalizarea unui proiect.
 Structura proiectului
Structura proiectului
Proiect: Customizarea unui Sistem de Contabilizare a Muncii existent.
Utilizatorul principal: Resursele umane
Echipa de proiect: Programer1, Programer2, Senior Programmer, DBA, Project
Manager.
Managerul de proiect deţine: Project plan, project source code, project user
requirements.
i t
Prog1 deţine Part P1; Prog2 deţine Part P2; Senior deţine Part P3; DBA deţine
obiectele Database;
Contactul cu utilizatorul în cadrul echipei: project manager.
C t t l tili t l î d l hi i j t
 Diagrama originală de
Diagrama originală de
structură a proiectului.
Orice comunicaţie între
utilizatori şi programatori trece
prin manager.
Proprietatea asupra
codului: monopol.
Problemele apărute:
p
În absenţa oricărui membru al echipei munca
încetineşte sau chiar se opreşte.
Este imposibil de menţinut munca altui programator;
Testarea sistemului şi obţinerea de feedback necesită
timp îndelungat;
timp îndelungat;
Programatorii şi utilizatorii sunt confuzi cu privire la
interpretarea cerinţelor şi implementare;
Fieare parte a sistemului este deţinută de către un
membru al echipei;
 Când o persoană pleacă este
dificil de menţinut munca acelei
persoane Atunci când mai multe
persoane. Atunci când mai multe P1, P2
P1 P2, P3
and R.
User R
de o persoană pleacă proiectul
stă să moară dacă nu se iau
măsuri critice în structura
ăsu c ce s uc u a P2
proiectului. Prog1
Pro 2
P3
 D
După trei luni de dezvoltare trei
ăt il id d lt t i P1
oameni părăsesc proiectul.
Acesta arată acum astfel:
Data
 Implementare XP cu număr limitat de resurse umane disponibile
pentru revitalizarea proiectului:
Pentru început se lucrează în perechi şi se preia controlul asupra codului
lăsat de programatorul senior.
Se începe munca la codul fiecăruia în perechi. Promovarea unui standard
de codare. Promovarea dreptului colectiv asupra proiectului.
Dezvoltarea de unit tests, teste de integrare, user tests cu fiecare
implementare. Utilizatorii sunt disponibili cu feedback referitor la
f f
schimbări şi cerinţe de implementare.
User stories sunt folosite pentru descrierea cerinţelor şi testarea
implementării.
l ă
Toate acestea au făcut dezvoltarea, modificarea, testarea şi integrarea
mai uşoare şi rapide.
 Noua diagramă de proiect
după aplicarea metodelor
XP.
Comunicare directă între P1, P2, P3
utilizatori şi programatori.
ş p g R and Data
User
Acces direct la oricare
resursă a proiectului.
Drepturi colective asupra
Drepturi colective asupra
proiectului. Pro 2
Prog1
Pro
Lead
SCRUM și eXtreme Programming
 SCRUM este adesea folosit ca un wrapper
SCRUM d f l i peste eXtreme
X P
Programming
i
Dezvoltarea Orientată spre Testare
It worksk fine
fi on MY computer.
t
It’s a feature.
That’s weird…
It’ss never done that before.
It before
It must be a hardware problem.
It worked yesterday.
It’ss just some unlucky coincidence
It coincidence.
(top replies by programmers when their

programs
p g don’t work,, from
extremetesting)
T t
Testarea – parte a procesului
t l i software
ft
Ci
Cine testează?
ă?
 Cazul ideal – echipe de specialişti independeţi
 Adesea – analiştii responsabili de statbilirea cerinţelor şi analiză
 În eXtreme Programming (XP) programatorii sunt responsabili
de scrierea testelor înainte de codare
 Utilizatorii sistemului ce validează aplicaţia
C
Ce se testează?
ă?
 Testarea considerând programul un ‘black‐box’
p g
 Cazuri de test bazate pe specificaţiile sistemului
Cerinţe
Cerinţe funcţionale
funcţionale
•Face ceea ce trebuie să facă?
Cerinţe non‐funcţionale
•e.g. Face pe cât de repede ar trebui să facă?
 Planificarea testării poate începe din primele faze ale
procesului software
 Testerii accesează aplicaţia prin aceleaşi interfeţe pe
care le folosesc şi clientul sau utilizatorul
C
Ce se testează?
ă?
 White box testing = glass box testing
 Obiectivele constau în testarea implementării interne a
software‐ului şi verificarea dacă aceasta este conformă
cu specificaţiile
 Testerii au nevoie să acceseze codul şi dezvoltă cazurile
de test în funcţie de structura programului
Codul de test legat de biblioteci şi chiar aplicaţia software
 Cel mai adesea – unit tests
Testează părţi ale sistemului software
Verificare – componentele sunt funcţionale şi robuste
Planuri de testare
 Scrise înainte ca testele să fie dezvoltate
Chiar înainte de scrierea codului!
 Conţin Test Cases
Descrierea testului
Date folosite pentru testare
Rezultate aşteptate
....
Planuri de testare
Planuri de testare
Test no. 23
Purpose: Test correct addition of campaign and adverts
Step no. Test description Test data Expected result
23.1 Create a new Campaign added to database.

Campaign Campaign estimated Cost is set
to $0.00
23.2 Add advert 1 to Advert Advert added to the database.
Campaign estimated Campaign estimated cost is set
cost=$500 to $500
23.3 .....
........ .....
D l d
Datele de test
 Programe de test pentru stabilirea prezenţei defectelor
g p p ţ
de sistem – încearcă spargerea sistemului
 Datele de test testează aplicaţia software la limită
Datele de test testează aplicaţia software la limită
Valori extreme (numere foarte mari, string‐uri lungi)
Valori out of range
f g sau aproape de limite (0, ‐1, 0.999)
p p ( , , )
Combinaţii invalide de valori (age = 3, marital status =
married)
Valori fără sens (valori negative)
Încărcări mari (sunt cerinţele de performanţă satisfăcute?)
Ni l d
Nivele de testare
 Bottom up
Unit testing (clase individuale)
Integration
Integration testing
testing (clasele funcţionează corect împreună)
(clasele funcţionează corect împreună)
Subsystem testing (subsistemul funcţionează corect şi livrează
funcţionalitatea cerută)
funcţionalitatea cerută)
System testing (întregul sistem funcţionează fără interacţii
nedorite între subsisteme)
nedorite între subsisteme)
Acceptance testing (sistemul funcţionează aşa cum este dorit de
către utilizatori şi în conform cu specificaţiile)
către utilizatori şi în conform cu specificaţiile)
E
Etapele testării
l ă ii
 Etapa 1
Testarea modulelor (claselor), apoi a programelor (cazuri de folosire), apoi
a suitei (aplicaţia)
 Etapa 2 (Alpha Testing sau Verificarea)
(Alpha Testing sau Verificarea)
Execuţia programelor într‐un mediu simulat şi testarea intrărilor şi ieşirilor
Etapa anterioară release‐ului
 Etapa 3 (Beta Testing sau Validarea)
Testarea într‐un mediu real şi verificarea timpilor de răspuns, a
performanţei sub load
pe o a ţe sub oad şşi recuperării din diverse erori
ecupe ă d d e se e o
Reseale unui grup restrâns
 Etapa 4 (Gamma)
•Release‐ul către public
Junit
U i T
Unit Tests
 Testarea segmentelor individuale de cod
g
 Facilitează
Facilitează refacerea codului la un moment ulterior şi asigurarea
refacerea codului la un moment ulterior şi asigurarea
că modulul încă funcţionează corect (e.g. Regression Testing)
 Simplifică integrarea: ajută la eliminarea nesiguranţei
Simplifică integrarea ajută la eliminarea nesiguranţei
 Fără unit tests
Integrarea codului poate fi un coşmar
Modificarea codului poate fi un coşmar
JU i
JUnit
 Filozofie:
“Any program feature without an automated test simply doesn’t
exist.” ‐ Extreme Programming Explained, Kent Beck
 Gratis, open source (GPL
Gratis open source (GPL’d)
d)
 Integrat în Eclipse
Interfaţă grafică
Posibilitatea selectării testelor ce se vor a fi rulate
Suport pentru suite de teste
 http://www.junit.org
p j g
C
Ce este un test JUnit?
JU i ?
 Teste de unităţi sunt scrise în clase de test
Teste de unităţi sunt scrise în clase de test
 De exemplu, clasa Stack
Clasa
Clasa Stack are push, pop, count, …
Stack are push pop count
Clasa TestStack are testPush, testPop
 Ce
Ce se adaugă? Aserţiuni.
se adaugă? Aserţiuni
Un pachet de metode ce verifică diverse proprietăţi:
•Egalitatea variabilelor
g
•Identitatea obiectelor
Aserţiunile sunt folosite pentru a determina verdictul cazului
de test
Cl
Clasa Stack
S k
public class Stack {
int[] elements;
int topElement = -1;
public Stack() {
this(10);
}
public Stack(int size) {

elements = new int[size];
}
public boolean isEmpty() {

return topElement == -1;
}
}
T t
Testarea JUnit
JU it
• Teste – subclase ale junit.framework.TestCase
• Metodele ce încep cu “test”
test sunt executate de către
TestRunner
• Ex. – teste p
pentru constructori:
public class TestStack extends TestCase {
public void testDefaultConstructor()

p () {
Stack test = new Stack();
assertTrue(“Default constructor”, test.isEmpty());
}
public void testSizeConstructor() {

Stack test = new Stack(5);
assertTrue(test.isEmpty());
}
}Instrumente pentru Dezvoltarea Programelor
IDP – 88
A
Aserţiuni
i i
 Aserţiunile sunt definite în clasa specială JUnit Assert
Dacă aserţiunile sunt adevărate se continuă execuţia
metodei.
Dacă oricare aserţiune este falsă se opreşte execuţia
metodei, iar rezultatul cazului de test va fi “fail”.
Dacă se aruncă orice excepţie în timpul execuţiei
D ă ă i i î i l i i
metodei rezultatul cazului de test va fi “error”.
Dacă nici o aserţiune nu a fost încălcată pe durata
Dacă nici o aserţiune nu a fost încălcată pe durata
execuţiei întregii metode cazul de test va fi trecut
(pass).
Cl
Clasa Assert
A
assertTrue()
assertFalse()
assertEquals()
assertNotEquals()
assertSame()
assertNotSame()
assertNull()
assertNotNull()
f il()
fail()
Pentru o listă completă de metode & argumente consultaţi şi
p g ţ ş
http://junit.sourceforge.net/javadoc/
S
Setarea testelor
l
 Înainte de fiecare test se execută metoda setUp():
import junit.framework.TestCase;
public class StackTrace extends TestCase {

Stack test;
public void setUp() {

test = new Stack(5);
( )
for (int k=1; k<=5; k++)
test.push(k);
}
public void testPushPop() {

for (int k=5; k>=1; k--)
assertEquals(“Pop fail on element “+k, test.pop(), k);
}
}
C
Cazuri multiple de test
i li l d
 Mai multe clase de test pot fi rulate simultan
 Încă un exemplu:
Folosirea unei suite pentru executarea mai multor
Folosirea unei suite pentru executarea mai multor
cazuri de test
 AllTests execută toate testele din StackTest şi QueueTest
 Eclipse generează clasa în mod automat
Din meniul File se selectează New, apoi Other. În fereastra de dialog se selectează
Î
“JUnit Test Suite”
R l
Rularea testelor JUnit
t t l JU it
 Se pot executa uşor din Eclipse
 Se
Se poate descărca Junit de la http://www.junit.org/
poate descărca Junit de la http://www junit org/ şi rula din linia
şi rula din linia
de comandă
T
Test vs. T C
TestCase vs. T S i
TestSuite
 “TestCase” este o clasă
 Un test este reprezentat de o metodă
 O “suită de teste” este reprezentată de o colecţie de teste
( ibil î dit )
(posibil înrudite) ce sunt rulate ca un grup
t l t
 Nu există diferenţe între rularea unei suite de teste şi a unui caz
de test
de test.
Framework‐ul JUnit
Test
run(TestResult)
( )
TestResult TestCase TestSuite

run(TestResult) run(TestResult)
runTest() addTest() fTests
setup()
tearDown()
fName
ATestClass AnotherTestClass
Testele
este e noastre.
oast e
*suite(): TestSuite *suite(): TestSuite
Rapid Application Development

Rapid Application Development
Two hours
T h minimum,
i i sir,
i at top warp
speed. At out present rate, two days...
Damn... Maximum warp, then.
(Star Trek: Next Generation: Captains
Captains’
Honor)
D
Dezvoltarea rapidă de aplicaţii
l idă d li ii
 Metodele
Metodele agile au captat atenţie dar alte abordări ale dezvoltării
agile au captat atenţie dar alte abordări ale dezvoltării
rapide de aplicaţii au fost folosite de mai mulţi ani
 Acestea sunt proiectate pentru dezvoltarea de aplicaţii business
p p p ţ
orientate spre date şi se bazează pe programarea şi prezentarea
informaţiilor provenind dintr‐o bază de date
I
Instrumente de dezvoltare RAD
d d l RAD
 Limbaje de programare
de programare a bazelor
a bazelor de date
de date
 Generare de interfeţe
 Legături
L ăt i cu aplicaţii
li ţii
 Generare de rapoarte
U
Un mediu de dezvoltare RAD
di d d l RAD
Generator de Sisteme
interfeţe Office
Generator de
Limbaj de rapoarte
programare DB
Database Management System
Mediu de dezvoltare
rapidă de aplicaţii

G
Generarea de interfeţe
d i f
 Multe aplicaţii se bazează pe formulare complexe
p ţ p p
Dezvoltarea unor formulare manual reprezintă o activitate
consumatoare de timp şi resurse
 Mediile de dezvoltare RAD includ suport pentru generarea de
ecrane, precum:
Definirea interactivă de formulare folosind tehnici drag&drop;
D fi i i t ti ă d f l f l i d t h i i d &d
Legarea de formulare în care sunt specificate secvenţe de
prezentare a acestora;
prezentare a acestora;
Verificarea de formulare în care sunt definite plaje de valori
pentru câmpuri ale formularelor.

P
Programarea vizuală
i lă
 Limbaje de scripting precum Visual Basic suportă
Limbaje de scripting precum Visual Basic suportă
programarea vizuală
Prototipul este dezvoltat prin crearea de interfeţe utilizator
pornind de la elemente standard definite şi furnizând asocieri
între componente şi aceste elemente
 Mediile RAD oferă o mare gamă de componente pentru
a suporta acest tip de dezvoltare
 Acestea pot fi ajustate pentru a se armoniza cu
cerinţele specifice ale aplicaţiilor

P
Programarea vizuală
i lă şi refolosire
i f l i
M
Menu componentt
Date component
File Edit Views Layout

y Options
p Help
p
General
12th January 2000 Index
Range checking
3.876
script
User prompt
component +
Draw canvas script
component
Tree display
component

P bl
Probleme cu dezvoltarea vizuală
d l i lă
 Dezvoltarea
D l î
în echipă
hi ă este dificil
difi il de coordonat.
d d
 Nu există o arhitectură explicită a sistemului.
 Dependenţele complexe dintre părţi ale programului pot cauza
probleme de mentenanţă.

COTS
 O abordare a dezvoltării rapide constă în configurarea
şi legarea unor sisteme existente “off the shelf”
 De exemplu, un sistem de gestiune a cerinţelor poate fi

construit folosind:
O bază de date pentru stocarea cerinţelor;
Un procesor
p word pentru
p capturarea
p cerinţelor
ţ şşi a
formularelor de rapoarte;
Un spreadsheet pentru gestionarea istoriei dezvoltării.

Documente compuse
 Pentru unele aplicaţii un prototip poate fi creat
Pentru unele aplicaţii un prototip poate fi creat
pornind de la dezvoltarea unui document compus.
 Acesta este un document conţinând elemente active
(ex. un spreadsheet) ce permite calculele utilizatorului.
 Fiecare element activ are o aplicaţie asociată ce este
i
invocată atunci când este selectat elementul.
tă t i â d t l t t l t l
 Documentul reprezintă integratorul diverselor aplicaţii.

L
Legarea aplicatiilor
li iil

Software Prototyping

Back testing
k
Date de test
Prototip de Sistemul
sistem aplicaţie
Comparator
de rezultate
Raport al
diferenţelor

Procesul de prototipare
ld
Stabilirea Definirea
obiectivelor funcţionalităţii Dezvoltarea Evaluarea
prototipului prototipului prototipului prototipului
Planul Definiţia Prototipul Raport de

prototipului funcţionalităţii executabil evaluare

Prototipuri Throw‐away
h
 Prototipurile sunt aruncate după dezvoltare deoarece ele nu

constituie o bună bază pentru sistemul final:
Poate fi imposibil ca sistemul să includă cerinţele non‐
funcţionale;
Prototipurile
P t ti il suntt în general nedocumentate;
î l d t t
Structura prototipului este în general degradată de procesele
de modificări rapide
p aplicate;
p ;
Prototipul nu satisface standarde de calitate înaltă ce ar putea
fi impuse de organizaţie.

Sumar
 O abordare iterativă a dezvoltării software conduce la livrarea mai
rapidă a aplicaţiei
rapidă a aplicaţiei
 Metodele agile sunt metode de dezvoltare iterativă ce urmăresc
reducerea overhead‐ului de dezvoltare şi producerea rapidă de
software
 Programarea extremă include practici precum testarea sistematică,
îmbunătăţirea continuă şi includerea clientului în ciclul de dezvoltare
 Mediile de dezvoltare rapidă includ limbaje de programare a bazelor de
date, instrumente pentru generarea de formulare şi legături cu aplicaţii
office
 Un prototip throw‐away este folosit pentru explorarea cerinţelor şi a
opţiunilor de proiectare
 În abordarea bazată pe prototipuri throw‐away
p p p y se începe cu cerinţele
p ţ
cel mai puţin înţelese; în dezvoltarea incrementală se începe cu
cerinteţele cel mai bine înţelese
Resurse
Carti
Extreme Programming Explained – Kent Beck
Refactoring – Martin Fowler
Planning Extreme Programming – Kent Beck et al
Extreme Programming Installed – Ron Jeffries et al
Extreme Programming Examined – Giancarlo Succi et al
Extreme Programming in Practice – Robert C. Martin et al
E t
Extreme Programming
P i E Explored
l d – William
Willi C
C. W
Wakek
Extreme Programming Applied – Ken Auer et al
The Costs and Benefits of Pair Programming – Alistair Cockburn et al
Web Sites
http://www.testdriven.com
http://www.xprogramming.com
p // p g g
http://AgileAlliance.com
http://ExtremeProgramming.org
http://www.junit.org
http://www.xprogramming.com
http://www.refactoring.com
http://www.pairprogramming.com
http://dotnetjunkies.com/WebLog/darrell_norton
http://www.peterprovost.org
htt // bl
http://weblogs.asp.net/nunitaddin
t/ it ddi
http://weblogs.asp.net/jamesnewkirk
http://www,iserializable.com

pr8 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

pr8 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Platformă de e‐learning și curriculă

•Individuals and interactions over processes and tools

That is, while there is value in the items on

(The Agile Manifesto) - http://agilemanifesto.org/

• Categorie uşoară, ‘agile’ • Categorie grea, ‘traditional’

 Sistemul este dezvoltat într‐o serie

 Interfeţele utilizator sunt de obicei dezvoltate folosind un

Problemele dezvoltării incrementale

Throw-away Prototipul executabil +

 Obiectivul abordării “throw‐away

#3 Analiza Proiect Implementare Testare Prototip

Implicarea clientului Clientul trebuie să fie implicat în procesul de dezvoltare. Rolul

Livrarea incrementală Software-ul este dezvoltat în incremente, clientul având rolul

Oameni nu procese Capabilităţile echipei de dezvoltare trebuie să fie recunoscute

Adoptarea schimbării Cerinţele sistemului sunt în permanentă schimbare şi sistemul

Menţinerea simplităţii Focus pe simplitate atât în software-ul dezvoltat, cât şi în

Ciclurile de dezvoltare SCRUM

Backlog tasks 30 days

Instead of cowboy coders we have

New Next Small

Spike = result goes into

You then choose a pprinter and a copy

• a valid non-time-limited (paid) license certificate or

License info is displayed on the splash screen.

I'll put on my "Development" hat tomorrow and estimate this.

Task 1: Implement principal workflow

Task 2: Implement article catalog and selection

Task 3: Implement payment collection

Payment may be made in 3 different ways. The user

 Testele sunt scrise sub formă de programe, putând fi

 Un test include o verificare a unei funcţionalităţi

 Toate testele anterioare şi cele noi sunt rulate automat

On-site Customer Planning game

Pair Programming Testing

Sursa: Beck, Extreme Programming Explained: Embrace Change, 1999

(top replies by programmers when their

23.1 Create a new Campaign added to database.

public Stack(int size) {

public boolean isEmpty() {

public void testDefaultConstructor()

public void testSizeConstructor() {

public class StackTrace extends TestCase {

public void setUp() {

public void testPushPop() {

TestResult TestCase TestSuite

Rapid Application Development

Database Management System

IDP – Instrumente pentru Dezvoltarea Programelor 100

IDP – Instrumente pentru Dezvoltarea Programelor 101

IDP – Instrumente pentru Dezvoltarea Programelor 102

File Edit Views Layout

IDP – Instrumente pentru Dezvoltarea Programelor 103

IDP – Instrumente pentru Dezvoltarea Programelor 104

 De exemplu, un sistem de gestiune a cerinţelor poate fi

IDP – Instrumente pentru Dezvoltarea Programelor 105

IDP – Instrumente pentru Dezvoltarea Programelor 106

IDP – Instrumente pentru Dezvoltarea Programelor 107

IDP – Instrumente pentru Dezvoltarea Programelor 108

IDP – Instrumente pentru Dezvoltarea Programelor 109

Planul Definiţia Prototipul Raport de

IDP – Instrumente pentru Dezvoltarea Programelor 110

 Prototipurile sunt aruncate după dezvoltare deoarece ele nu

IDP – Instrumente pentru Dezvoltarea Programelor 111