2 Rapid software development

Universitatea Politehnica Bucuresti - Facultatea de Automatica si Calculatoare

Instrumente ca parte a procesului de Instrumente ca parte a procesului de dezvoltare softwaredezvoltare softwaredezvoltare softwaredezvoltare software

Rapid software developmentRapid software development

Ciprian DobreCiprian [email protected]

Instrumente pentru dezvoltarea programelor – Curs 2 1


SumarSumarSu aSu a

• Metode Agileg– SCRUM

eXtreme Programming– eXtreme Programming• Testare – JUnit• Rapid Application Development• Prototipare• Prototipare

2Instrumente pentru dezvoltarea programelor – Curs 2


Metode AgileMetode Agile

“We are uncovering better ways of developing software by doing it and helping others do it. Th h this k h t l : Through this work we have come to value:

•Individuals and interactions over processes and tools•Working software over comprehensive documentation•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. “

3

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

Instrumente pentru dezvoltarea programelor – Curs 2


Procese adaptive vs. predictiveProcese adaptive vs. predictiveocese adapt e s p ed ct eocese adapt e s p ed ct eAdaptive Predictive

• Categorie uşoară, ‘agile’• Control prin feedback

• Categorie grea, ‘traditional’ • Control prin planificare

• Multe iteraţii scurte (săptămâni)

• Scară mică (<10 dezvoltatori)

• Câteva iteraţii lungi (luni)• Scară mare (>30 dezvoltatori)• Documente scrise

• Comunicare faţă-în-faţă• Centrate pe cod şi oameni• Egalitariene

• Centrate pe reguli• Autoritariene

g

• Probleme:– Rezultatele de lungă durată

• Probleme:– Inflexibilitate la modificările

cerinţelorRezultatele de lungă durată puţin predictibile

– Haos asociat cowboy-coding

ţ– Efort mărit de Integrare şi

testare– Birocraţia asociată ‘Control

freak’

4

• E.g. XP freak• E.g. waterfall



Rapid Software DevelopmentRapid Software Developmentap d So t a e e e op e tap d So t a e e e op e t

• 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 reprezintă o cerinţă critică pentru sistemele software.

• 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)



CerinCerinţţeeCeCe ţţee

• Mediu în continuă schimbare => este imposibil de ajuns la un set de cerinţe stabil şi consistent (modificări ale cerinţelorstabil şi consistent (modificări ale cerinţelor on-the-fly)M d l l d d l î dă• Modelul de dezvoltare în cascadă se dovedeşte nepractic în astfel de situaţii

• Mai adecvată este o abordarebazată/orientată pe specificaţii şi livrarebazată/orientată pe specificaţii şi livrare iterative

S ft l li t ( i) id6

– Software-ul livrat (mai) rapidInstrumente pentru dezvoltarea programelor – Curs 2


Raportul Haos:Raportul Haos:Raportul Haos:Raportul Haos:• Început în 1994, studiul a evaluat peste

35 000 de proiecte software35.000 de proiecte software• Situația la nivelul anului 2000:

Sursa: Standish “Chaos” Report, Jim Johnson lecture at XP2002 conference, http://www.xp2003.org/xp2002/talksinfo/johnson.pdf



Caracteristicile proceselor RADCaracteristicile proceselor RADCa acte st c e p ocese oCa acte st c e p ocese o• Procesele de specificare, proiectare şi

implementare sunt concurenteimplementare sunt concurente– Nu există specificaţie detaliată

D t ţi i tă ii t i i lă– Documentaţia proiectării este minimală

• Sistemul este dezvoltat într-o serie de incremente– Utilizatorii finali evaluează fiecare incrementare– Propuneri pentru incrementările următoare

• Interfeţele utilizator sunt de obicei dezvoltate folosind un sistem de dezvoltare interactiv



Un proces de de oltare iteratiUn proces de de oltare iterati ăăUn proces de dezvoltare iterativUn proces de dezvoltare iterativăă



Avantajele dezvoltAvantajele dezvoltăării incrementalerii incrementalea taje e de o ta taje e de o tăă c e e ta ec e e ta e

• Livrarea rapidă a produselor/serviciilor către clienţi. Fiecare incrementare livrează clienţilor ţfuncţionalitatea având următoarea “cea mai mare” prioritate.p

• Antrenarea utilizatorilor în dezvoltarea sistemului• Antrenarea utilizatorilor în dezvoltarea sistemului. Utilizatorii sunt implicaţi în dezvoltare => sistemul este dezvoltat în jurul cerinţelor impuse;este dezvoltat în jurul cerinţelor impuse; utilizatorii sunt mai devotaţi sistemului



Problemele dezvoltProblemele dezvoltăării incrementalerii incrementale• Probleme de management

– Progresul poate fi greu de apreciat g p g p– Problemele sunt greu de rezolvat deoarece nu există nici o

documentaţie care să demonstreze corectitudinea implementăriiimplementării.

• Probleme contractuale– Contractul în mod normal include o specificaţie; fără o p ţ ;

specificaţie trebuie folosite forme diferite de contractare.• Probleme de validare

Fă ă ifi i bl b i i l– Fără o specificaţie contra a ce probleme ar trebui sistemul testat?

• Probleme de mentenanţăProbleme de mentenanţă– Schimbările continue tind să corupă structura software-ului– Costuri mari implicate pentru modificarea şi actualizarea p p ş

software-ului în cazul apariţiei unor cerinţe noi



PrototypingPrototypingototyp gototyp g• Pentru unele sisteme mari dezvoltarea iterativă

incrementală poate fi nepractică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 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 cerinţelor;validarea cerinţelor;– În procesul de proiectare pentru explorarea opţiunilor şi

dezvoltarea unui design UI;– În procesul de testare pentru rularea unor verificări back-to-back

12

– În procesul de testare pentru rularea unor verificări back-to-back.



D lt i t lD lt i t lăă i t tii t tiDezvoltarea incrementalDezvoltarea incrementalăă şşi prototipareai prototiparea

Sistemul livratDezvoltare

incrementală

Cerinţe

Throw-away Prototipul executabil +Throw-awayprototyping

Prototipul executabil + Specificaţia sistemului

Demo13Instrumente pentru dezvoltarea programelor – Curs 2

Demo…


Obiective conflictualeObiective conflictualeOb ect e co ctua eOb ect e co ctua e

• Obiectivul dezvoltării incrementale îl constituie• Obiectivul dezvoltării incrementale î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 prototyping” este y p yp gde a valida sau deriva cerinţele sistemului– Procesul de prototipare începe cu acele cerinţe ce sunt

îcel mai puţin înţelese.



Metode agileMetode agileetode ag eetode ag e• Insatisfacţiile cu overhead-ul implicat de metodele de

proiectare au condus la crearea Metodelor Agileproiectare au condus la crearea Metodelor Agile.

• Metodele 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ă schimbarespre a satisface cerinţele în continuă schimbare.

M t d l il t d t î i l i t l d• Metodele agile sunt adecvate în special sistemelor de business de mărime mică şi medie sau produselor PC.



Agile Software DevelopmentAgile Software Developmentg e So t a e e e op e tg e So t a e e e op e t• A apărut în anii 1990 ca reacţie la metodele tradiţionale

“greoaie” de dezvoltaregreoaie de dezvoltare• Presupune multe iteraţii scurte (săptămâni) şi

‘prototiparea’:prototiparea :

Analiza Proiect Implementare Testare PrototipIteraţie#1 Analiza Proiect Implementare Testare Prototip

Analiza Proiect Implementare Testare Prototip

#1

#2

Analiza Proiect Implementare Testare Prototip#3

• Control prin feedback: re-evaluarea şi revizia proiectului după fiecare iteraţie

…

16

după fiecare iteraţie



Principiile metodelor agilePrincipiile metodelor agilec p e etode o ag ec p e etode o ag e

Principiul Descrierep

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 sistemuluide 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 şi exploatate. Echipa trebuie lăsată să-şi exercite propriile metode de lucru fără un proces prescriptiv.metode de lucru fără un proces prescriptiv.

Adoptarea schimbării Cerinţele sistemului sunt în permanentă schimbare şi sistemul trebuie proiectat a.î. să acomodeze aceste schimbări.

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 complexităţii din sistem.

17

p ţ



PracticiPractici AgileAgilePracticiPractici AgileAgile• Delimitări Sandbox / Environment



Problemele metodelor agileProblemele metodelor agileob e e e etode o ag eob e e e etode o ag e• Dificil de menţinut interesul clienţilor implicaţi în

procesul de dezvoltareprocesul de dezvoltare

• Membrii echipei pot fi neadecvaţi pentru interesul i t î d lt i t l i t dintens în dezvoltarea proiectului cerut de metodele agile

• Prioretizarea schimbărilor poate fi dificilă atunci când sunt mai mulţi acţionari implicaţi

• Menţinerea simplităţii necesită muncăsuplimentară

• Contractele pot fi o problemă (similar altor metode de dezvoltare iterativă)

19

)



Deci ce Metode Agile există?Deci ce Metode Agile există?Deci ce Metode Agile există?Deci ce Metode Agile există?

– Extreme Programming (XP) (Kent Beck, Ward g g ( ) ( ,Cunningham, Ron Jeffries)

– Scrum (Jeff Sutherland, Mike Beedle, KenScrum (Jeff Sutherland, Mike Beedle, Ken Schwaber)

– DSDM – Dynamic Systems Development Method– DSDM – Dynamic Systems Development Method (Community owned)Crystal (Alistair Cockburn)– Crystal (Alistair Cockburn)

– ASD – Adaptive Software Development (Jim Hi h ith)Highsmith)

– XBreed (Mike Beedle) ( )



D i i lt d âtD i i lt d âtDeci mai mult decât …Deci mai mult decât …



StudiuStudiu de de cazcaz::MetodeleMetodele dede dezvoltaredezvoltare SCRUMSCRUMMetodeleMetodele de de dezvoltaredezvoltare SCRUM SCRUM



Ce înseamnă SCRUM?Ce înseamnă SCRUM?Ce înseamnă SCRUM?Ce înseamnă SCRUM?• Posibil asta:



SCRUMSCRUM• Proces de dezvoltarea iterativ-incrementală

• Include un set de practici si roluri predefinite (“Pig” și “Chicken”)

– Product Owner• Vocea clientului

• Definește cerințele business

• Deține “product backlog”

– Scrum Master• Administrează procesul SCRUM

• 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 SCRUMEchipa SCRUMEchipa SCRUMEchipa SCRUM• Auto-organizată• Membrii nu au roluri bine definite

– Pot lucra în oricare activitate și grup.Pot lucra în oricare activitate și grup.• Membrii echipei SCRUM sunt

cunoscuți ca Pigscunoscuți ca Pigs– Sunt devotați pentru livrarea scopului

SprintSprint• Persoanele implicate dar care nu sunt

devotate proiectului sunt Chickensdevotate proiectului sunt Chickens – Participă la întâlnirile Scrum doar ca

observatoriobservatori



“You’re Fired!”“You’re Fired!”You re Fired!You re Fired!

O metrică simplă:O metrică simplă:

Dacă poți fi concediat pentru eșecul proiectului –ești pig.

Dacă îți păstrezi job-ul, în ciuda eșecului proiectuluiciuda eșecului proiectului –ești chicken.



Practici SCRUMPractici SCRUMPractici SCRUMPractici SCRUM• Product Backlog

Set prioretizat (funcție de importanță) de cerințe– Set prioretizat (funcție de importanță) de cerințe funcționale

• Sprint– Perioadă cuprinsă între 2 și 4 săptămâniPerioadă cuprinsă între 2 și 4 săptămâni– Nimeni nu poate modifica Spring Backlog-ul î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 unFinal: rezultatul este în general însoțit și de un

demo



ExempluExemplu -- Product BacklogProduct BacklogExemplu Exemplu Product BacklogProduct Backlog



Practici SCRUMPractici SCRUMPractici SCRUMPractici SCRUM• Sprint Planning Meeting

Ș di ță d l l d i iil i i d it i d B kl– Ședință ce conduce la luarea deciziilor privind ce itemi de Backlog sunt incluși în următorul Sprint

• Sprint Backlogp g– Itemii ce se urmăresc a fi rezolvați într-un Sprint

Product BacklogProduct Backlog

Capabilităţile Echipeip

Condiţii Business

Stabilitate ReviewConsider Organize

Next Sprint Goal

Sprint BacklogTehnologică

Incredement Executabil al

Organize Sprint Backlog


Executabil alProdusului


ExempluExemplu -- Sprint BacklogSprint BacklogExemplu Exemplu -- Sprint BacklogSprint Backlog



Ciclurile de dezvoltare SCRUMCiclurile de dezvoltare SCRUMCiclurile de dezvoltare SCRUMCiclurile de dezvoltare SCRUM

24 hoursDaily Scrum

Meeting

30 daysBacklog tasks

Meeting

30 days

Sprint Backlog

Backlog tasksexpandedby team

P d B klPotentially Shippable

P d t I tProduct BacklogAs prioritized by Product Owner

Product Increment


*Sursa: Schwaber, K. and Beedle, M. 2001 Agile Software Development with Scrum


Întâlniri…Întâlniri…Întâlniri…Întâlniri…• Daily Scrum

– Întâlnire zilnică de lucru în timpul SPRINT-ului.– Începe la ore fixe.– Toți sunt bineveniți, dar doar “pigs” pot vorbi.– În timpul întâlnirii fiecare membru răspunde la:

– 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ă

t i i ti itățil ?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

ti itățil t i t i i dactivitățile, cu accent pe integrare și suprapuneri de activități.Participă câte o persoană delegată din fiecare echipă– Participă câte o persoană delegată din fiecare echipă.

– Agenda similară cu cea a Daily Scrum, dar mai apar și alte patru întrebări:alte patru întrebări:

Ce a făcut echipa de la ultima întâlnire?– Ce a făcut echipa de la ultima întâlnire?– Ce va face echipa până la următoarea întâlnire?– Există ceva ce poate încetini activitatea echipei?Există ceva ce poate încetini activitatea echipei?– Există modificări în modul de lucru sau componența echipei?



Întâlniri…Întâlniri…Întâlniri…Întâlniri…• Sprint Planning Meetingp g g

– La începutul unui nou Sprint.Se selectează activitățile ce vor fi făcute în– Se selectează activitățile ce vor fi făcute în cadrul Sprint-ului curent => Sprint BacklogS id tifi ă i i ă l l d ă– 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:

• Sprint Review MeetingS• Sprint Retrospective



Avantaje SCRUMAvantaje SCRUMAvantaje SCRUMAvantaje SCRUM• SCRUM facilitează crearea unor echipe self-

i torganizate• Încurajează co-locarea membrilor echipei și• Comunicația verbală între membrii echipei



Oracle SupportOracle Support KMKMOracle Support Oracle Support –– KM KM


Mai multe…Mai multe…Mai multe…Mai multe…Recomandări bibliografice:g• http://www.scrumalliance.org/• Cartea “Agile Software Development with• Cartea Agile Software Development with

SCRUM” - Ken Schwaber, Mike BeedleC t “A il P j t M t ith SCRUM”• Cartea “Agile Project Management with SCRUM” - Ken Schwaber

• http://www.controlchaos.com/ - Site-ul lui Schwaber


Studiu de Caz: eXtreme ProgrammingStudiu de Caz: eXtreme Programming

Instead of cowboy coders we have Instead of cowboy coders we have software sheriffs; working together as a software sheriffs; working together as a

i k h d d i h i k h d d i h team, quick on the draw, armed with a team, quick on the draw, armed with a few rules and practices that are light, few rules and practices that are light,

concise, and effective.concise, and effective.(J D W ll (J D W ll (James D. Wells, (James D. Wells,

extremeprogramming.org)extremeprogramming.org)



eXeXtreme treme PProgramming (1)rogramming (1)

• Una dintre cele mai cunoscute metode Agile –b d b tă t ti i d l t

ee t e et e e og a g ( )og a g ( )

abordare bazată pe tactici duse la extrem:

• If testing is good, let everybody test all the time• If code reviews are good, review all the timeg• If design is good, refactor all the time• If integration testing is good, integrate all the timeIf integration testing is good, integrate all the time• If simplicity is good, do the simplest thing that

could possibly workcould possibly work• If short iterations are good, make them really,

really shortreally short



eXtreme Programming (2)eXtreme Programming (2)e t e e og a g ( )e t e e og a g ( )• XP=eXtreme Programming: Nomen est omen,

b d t tă dabordare centrată pe cod• Cultura XP: mai mult decât a face ca proiectulCultura XP: mai mult decât a face ca proiectul

să meargăS b ă• Se bazează pe – îmbunătăţirea constantă a codului– includerea utilizatorului în echipa de dezvoltare – programare pairwiseprogramare pairwise



eXtreme Programming (3)eXtreme Programming (3)e t e e og a g (3)e t e e og a g (3)

• Noi versiuni pot fi construite chiar de mai multe ori pe zi

• Incrementele sunt livrate la fiecare 2 săptămânip• Toate testele trebuie să fie executate pentru

fiecare buildfiecare build

S t d ti i l t d lt t i i• Set de practici uzuale pentru dezvoltatori şi manageri ce încurajează– 5 valori – 12 practici/reguli



Cele 5 valori XPCele 5 valori XPCe e 5 a oCe e 5 a o1. Comunicare

– Teamwork: vederi consistente asupra sistemuluiTeamwork: vederi consistente asupra sistemului– Mediu de lucru deschis: dezvoltatori, manageri, clienţi– Conversaţii verbale, informale, faţă-în-faţă

2. Feedback2. Feedback– 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, , p

3. Simplitate– Construirea celor mai simple lucruri care funcţionează pe moment– Nimic nu se construieşte ce ar putea fi nefolositor mai târziuş p– Proiectele simple facilitează comunicarea mai uşoară

4. Curaj– De a schimba şi de a sfărâma, “embrace change”

Cost ofchangeş , g

– Mai bine modifică pe loc (cheaper)– Niciodată nu te da bătut (Never give up!)

5. Respect pentru echipă şi munca proprie Point of timei hi j

g

42

p p p ş p pwithin project



Cele 12 practici XP (1)Cele 12 practici XP (1)Ce e p act c ( )Ce e p act c ( )Fine scale feedback1 Pair Programming1. Pair Programming

– Programarea în echipe de câte doi: driver şi navigator2. Planning Game: metoda de planificare a proiectului împreună cu

clientulclientul3. Test Driven Development

– Întâi se scriu cazuri de test, ulterior codul programului– Pentru fiecare defect se introduce un nou caz de testPentru fiecare defect se introduce un nou caz de test

4. Whole Team: echipa de clienţi, dezvoltatori, manageri

Shared understandingShared understanding5. Folosirea unui Coding Standard de comun acceptat6. Collective Code Ownership

Toată lumea este responsabilă de întreg codul şi oricine poate– Toată lumea este responsabilă de întreg codul şi oricine poate modifica în oricare parte a codului

7. Simple Design8 System Metaphor

43

8. System Metaphor– Numirea părţilor din program folosind nume consistente, intuitive



Cele 12 practici XP (2)Cele 12 practici XP (2)Continuous process9 C ti I t ti

Ce e p act c ( )Ce e p act c ( )

9. Continuous Integration– Lucru cu ultimele versiuni ale codului

Integrarea schimbărilor locale ASAP– Integrarea schimbărilor locale ASAP10.Refactoring

– Îmbunătăţirea proiectului când este posibilÎmbunătăţirea proiectului când este posibil– Înlăturarea complexităţii inutile

11.Small Releases

Programmer welfareg12.Sustainable Pace

– Nu se lucrează în regim Overtime – mai degrabă se difi fi l d i hi l fi lmodifică graficul de proiect sau chiar scopul final



Terminologia XPTerminologia XPe o og ae o og a• User story

Funcţionalităţile pe care sistemul trebuie să le ofere utilizatorilor– 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

R l i t l bil i l t ă “ t i ”• Release: sistem rulabil ce implementează “user stories”-urile importante

• SpikeSp e– Prototip folosit ca proof-of-concept– Explorează fezabilitatea unei abordări a implementării

• Iteration• Iteration– Fază a implementării, de durata 1-3 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

45

p– Fie time / #stories



Etapele dezvoltEtapele dezvoltăării XPrii XPtape e de o ttape e de o tăă

UUserStories

DefectsProject velocity

ReleasePlanning TestsIteration

N tN SmallRelease

NextIteration

NewUser Story

UncertainEstimates

ConfidentEstimates

= is followed by

res lt goes into

46

46Spike = result goes into



User StoriesUser Stories



Scenariile cerinScenariile cerinţţelorelor

• În XP cerinţele utilizatorilor sunt specificate sub f ă d ii i d i

Sce a e ceSce a e ce ţţe oe o

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ăscrisă de client în terminologia acestuia, fără sintaxă tehnică.

• Echipa de dezvoltare le transpune în task-uri deEchipa de dezvoltare le transpune în task uri de implementare

• Task-urile constituie baza planificării dezvoltării şiTask urile constituie baza planificării dezvoltării şi a costurilor estimate

• Clientul alege scenariile ce pot fi incluse în noileClientul alege scenariile ce pot fi incluse în noile versiuni ale produsului, pe baza prorităţilor şi a estimărilor de planificarep



Ex: Story card for document Ex: Story card for document downloadingdownloading

i i i iDownloading and printing an article

First, you select the article that you want from a displayed list. You then ha e to tell the s stem ho o ill pa for it this can eitherthen 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 you have submitted this, the article you want is downloaded onto your computeronto your computer.

You then choose a printer and a copy of the article is printed. You tell the system if printing has been successful.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.

49

y y p



ExempluExempluStory card-urile cuprind e p ue p uS o y ca d u e cup dcel mai adesea

aproximativ trei fraze, scrise pe 4x6 cardsscrise pe 4x6 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: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.

I'll put on my "Development" hat tomorrow and estimate this. Tomorrow or 'mañana'?

When a demo license expires, the license dialog re-appears the next time JeraWorks is run.

50

Tomorrow or 'mañana'?



XP XP şşi schimbareai schimbareaşş sc ba easc ba ea• În mod tradiţional un dezvoltator software este considerat

înţelept atunci când proiectează soluţii luând înî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 pentruse 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 anticipateadevărat anticipate.

• XP propune îmbunătăţirea constantă a codului(refactoring) pentru a face modificările mai uşor de(refactoring) pentru a face modificările mai uşor de integrat în proiect



Testarea Testarea îîn abordarea XPn abordarea XPesta eaesta ea abo da eaabo da ea

• Dezvoltare bazată pe abordarea “test-first”• Dezvoltarea incrementală a testelor pornind de la

scenarii• Includerea utilizatorilor în dezvoltarea şi validarea

testelortestelor• Toate componentele testelor sunt rulate folosind

instrumente de testare automatăinstrumente de testare automată• Testarea executată cu fiecare versiune nouă



Ex: Ex: Task cards for document Task cards for document d l did l didownloadingdownloading

Task 1: Implement principal workflow

Task 2: Implement article catalog and selectionTask 2: Implement article catalog and selection

Task 3: Implement payment collection

Payment may be made in 3 different ways. The userselects which way they wish to pay. If the userhas a library subscription, then they can input thesubscriber key which should be checked by thesubscriber key which should be checked by thesystem. Alternatively, they can input an organisationalaccount number. If this is valid, a debit of the costof the article is posted to this account. Finally, theymay input a 16 digit credit card number and expirymay input a 16 digit credit card number and expirydate. This should be checked for validity and, ifvalid a debit is posted to that credit card account.



Descrierea cazului de testDescrierea cazului de testesc e ea ca u u de testesc e ea ca u u de test

Test 4: Test cr edit card validity

Input:A t i ti th dit d b d t i t tiAstring representing the credit card number and two integers representingthe month and year when the card expiresTests:Check that all bytes in the string are digitsCheck that the month lies between 1 and 12 and theyear is greater than or equal to the current year .Using the first 4 digits of the credit card number ,check that the card issuer is valid by looking up thecheck that the card issuer is valid by looking up thecard issuer table. Check credit card validity by submitting the cardnumber and expiry date information to the cardissuerOutput:Output:OK or error message indicating that the card is invalid



TestTest--first developmentfirst developmentestest st de e op e tst de e op e t• Scrierea testelor înaintea codului poate duce la

clarificarea cerinţelor ce se vor implementateclarificarea cerinţelor ce se vor implementate

• Testele sunt scrise sub formă de programe• 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 unei noi funcţionalităţi în proiect– Verificare că noua funcţionalitate nu a introdus erori în

proiect

55

proiect



Pair programmingPair programminga p og a ga p og a g

• În abordarea XP programatorii lucrează în p gechipe, conlucrând la scrierea codului

• Doi oameni lucrând la o aceaşi maşină, cu o ş şsingură tastatură şi un singur mousesingur mouse

• Două roluri: – implementare – strategie

56

g



AvantajeAvantajea tajea taje• dezvoltarea simţului proprietăţii asupra codului

ă â di ti ţ l f it l i t• răspândirea cunoştinţelor referitoare la proiect între toţi membrii echipei de dezvoltare

• deoarece fiecare linie de cod este vizualizată de• 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

î d i i di i i l ă i d d taceea în care doi indivizi lucrează indepedent



Reguli şi practici simplificateReguli şi practici simplificateegu ş p act c s p cateegu ş p act c s p cate

• Planning• User Stories

• Designing• Simplicity

• Release Planning• Small Releases

• System Metaphor• CRC cards

• Measure Project Velocity• Divide project to iterations

• Spike solutions• YAGNI

• Iterations Planning• Move People around

• Refactor

• Stand up meeting



Reguli şi practici simplificateReguli şi practici simplificateegu ş p act c s p cateegu ş p act c s p cate

Coding Testing• Coding• Customer available• Code standards

• Testing• Unit test everything• All tests pass beforeCode standards

• Test-Driven• Pair Programming

All tests pass before release

• Bug== new testA t t t• Sequential change

integration• Integrate often

• Acceptance tests

• Integrate often• Collective code

ownership• Don’t optimize early• No overtime



Harta XP Harta XP -- ProiectProiecta taa ta o ecto ect



Harta XP Harta XP –– IteraţieIteraţiea taa ta te aţ ete aţ e



Harta XP Harta XP -- DezvoltareDezvoltarea taa ta e o ta ee o ta e



Harta XP Harta XP –– Drepturi comune asupra Drepturi comune asupra coduluicodului



PracticilePracticile XPXP sunt intersunt inter dependentedependentePracticile Practicile XP XP sunt intersunt inter--dependentedependente

On-site Customer Planning game

40 Hour Week

Metaphor

RefactoringSimple Design

Short Releases

TestingPair Programming

Collective OwnershipCoding Standards

Continuous Integration

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


E l d I l tE l d I l t XPXPExemplu de Implementare Exemplu de Implementare XPXP



Exemplul de Programare Exemplul de Programare XP :XP :

Acesta este un exemplu foarte primitiv de folosire a metodologiei de Acesta este un exemplu foarte primitiv de folosire a metodologiei de programare XP pentru revitalizarea unui proiectprogramare XP pentru revitalizarea unui proiect..

• Structura proiectului– Proiect: Customizarea unui Sistem de Contabilizare a Muncii existent.Proiect: Customizarea unui Sistem de Contabilizare a Muncii existent.– Utilizatorul principal: Resursele umane– Echipa de proiect: Programer1, Programer2, Senior Programmer, DBA,

Project ManagerProject Manager.– Managerul de proiect deţine: Project plan, project source code, project user

requirements.– 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.



• Diagrama originală de• Diagrama originală de structură a proiectului.

Orice comunicaţie între– Orice comunicaţie între utilizatori şi programatori trece prin manager.

– Proprietatea asupra codului: monopol.



• Problemele apărute:• Problemele apărute:– În absenţa oricărui membru al echipei

munca încetineşte sau chiar se opreştemunca încetineşte sau chiar se opreşte.– Este imposibil de menţinut munca altui

programator;programator;– Testarea sistemului şi obţinerea de

feedback necesită timp îndelungat;feedback necesită timp îndelungat;– Programatorii şi utilizatorii sunt confuzi cu

privire la interpretarea cerinţelor şiprivire la interpretarea cerinţelor şi implementare;Fieare parte a sistemului este deţinută de– Fieare parte a sistemului este deţinută de către un membru al echipei;



Când o persoană pleacă este• Când o persoană pleacă este dificil de menţinut munca acelei persoane. Atunci când

i l d ă

UserP1, P2, P3and R.

R

mai multe de o persoană pleacă proiectul stă să moară dacă nu se iau măsuri critice în structura proiectului.

• După trei luni de dezvoltareProg1

Pro 2

P2

• După trei luni de dezvoltare trei oameni părăsesc proiectul. Acesta arată acum

tf lP1

P3

astfel:

Data



• Implementare XP cu număr limitat de resurse umane pdisponibile pentru revitalizarea proiectului:

P t î t l ă î hi i i t l l– 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 t d d d d P d t l i l tistandard 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 schimbări şi cerinţe de implementare.

– User stories sunt folosite pentru descrierea cerinţelor şi testarea implementării.

– Toate acestea au făcut dezvoltarea, modificarea, testarea şi integrarea mai uşoare şi rapide.



• Noua diagramă de

User

P1, P2, P3R and Data

oua d ag a ă deproiect după aplicarea metodelor XP.– Comunicare directă între

utilizatori şi programatori. – Acces direct la oricare

resursă a proiectului. – Drepturi colective asupra

proiectului.

Prog1

Pro 2p

ProLead



QuizQuizQuizQuiz1. Explicaţi cum duc principiile metodelor

agile la o dezvoltare accelerată a aplicaţiilor software.ţ

2 Când aţi recomanda să nu se folosească2. Când aţi recomanda să nu se folosească metodele agile pentru dezvoltarea de sisteme software?sisteme software?



SCRUM și eXtreme ProgrammingSCRUM și eXtreme ProgrammingSCRUM și eXtreme ProgrammingSCRUM și eXtreme Programming• SCRUM este adesea folosit ca un wrapperpp

peste eXtreme Programming



Dezvoltarea Orientată Dezvoltarea Orientată sprspre Testaree Testare

It works fine on MY computer.It’s a feature.fThat’s weird…It’s never done that before.It must be a hardware problemIt must be a hardware problem.It worked yesterday.It’s just some unlucky coincidence.

(top replies by programmers when their programs don’t work, from

t t ti )

74

extremetesting)



TestareaTestarea –– parte a parte a procesuluiprocesuluisoftwaresoftware



Cine testează?Cine testează?C e testea ăC e testea ă

• 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 deresponsabili de scrierea testelor înainte de codare

• Utilizatorii sistemului ce validează aplicaţia• Utilizatorii sistemului ce validează aplicaţia



Ce se testează?Ce se testează?Ce se testea ăCe se testea ă

• Testarea considerând programul un ‘black-box’• Cazuri de test bazate pe specificaţiile sistemului

– Cerinţe 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ă?• e.g. Face pe cât de repede ar trebui să facă?

• Planificarea testării poate începe din primele faze ale procesului softwareale procesului software

• Testerii accesează aplicaţia prin aceleaşi interfeţe pe care le folosesc şi clientul sauinterfeţe pe care le folosesc şi clientul sau utilizatorul



Ce se testează?Ce se testează?• Black-box testing – testarea funcționalității

aplicației

Ce se testea ăCe se testea ă

aplicației• White-box testing (glass box testing) – testarea

structurii interne a aplicațieistructurii interne a aplicației– Obiectivele constau în testarea implementării interne a

software-ului şi verificarea dacă aceasta este conformă ifi ţiilcu specificaţiile

– Testerii au nevoie să acceseze codul şi dezvoltă cazurile de test în funcţie de structura programuluiţ p g

– Codul de test legat de biblioteci şi chiar aplicaţia software

Cel mai adesea nit tests• Cel mai adesea – unit tests– Testează părţi ale sistemului software– Verificare – componentele sunt funcţionale şi robuste– Verificare – componentele sunt funcţionale şi robuste



Planuri de testarePlanuri de testarea u de testa ea u de testa e

• Scrise înainte ca testele să fie dezvoltate– Chiar înainte de scrierea codului!

• Conţin Test CasesConţin Test Cases– Descrierea testului

Date folosite pentru testare– Date folosite pentru testare– Rezultate aşteptate– ....



Planuri de testarePlanuri de testareTest no. 23Purpose: Test correct addition of campaign and advertsStep no. Test description Test data Expected result

23.1 Create a new Campaign

Campaign added to database. Campaign estimated Cost is set

$0 00to $0.0023.2 Add advert 1 to

CampaignAdvert estimated

Advert added to the database.Campaign estimated cost is set

cost=$500Ca pa g est ated cost s setto $500

23.3 .....

........ .....



Datele de testDatele de testate e de testate e de test

• Programe de test pentru stabilirea prezenţei defectelor de sistem – încearcă spargereasistemului

• Datele de test testează aplicaţia software la limită– Valori extreme (numere foarte mari, string-uri lungi)a o e e e ( u e e oa e a , s g u u g )– Valori out of range sau aproape de limite (0, -1, 0.999)– Combinaţii invalide de valori (age = 3, marital status =Combinaţii invalide de valori (age 3, marital status

married)– Valori fără sens (valori negative)( g )– Încărcări mari (sunt cerinţele de performanţă

satisfăcute?)



Nivele de testareNivele de testaree e de testa ee e de testa e

• Bottom up– Unit testing (clase individuale)

– Integration testing (clasele funcţionează corect împreună)– Integration testing (clasele funcţionează corect împreună)

– Subsystem testing (subsistemul funcţionează corect şi li ă f ţi lit t tă)livrează funcţionalitatea cerută)

– System testing (întregul sistem funcţionează fără interacţii nedorite între subsisteme)

– Acceptance testing (sistemul funcţionează aşa cum este dorit de către utilizatori şi în conform cu specificaţiile)



Etapele testăriiEtapele testăriitape e testătape e testă• Etapa 1

T t d l l ( l l ) i l ( i d– Testarea modulelor (claselor), apoi a programelor (cazuri de folosire), apoi a suitei (aplicaţia)

• Etapa 2 (Alpha Testing sau Verificarea)p ( p g )– Execuţia programelor într-un mediu simulat şi testarea intrărilor şi

ieşirilor– Etapa anterioară release-ului– 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 şi recuperării din diverse erori– Reseale unui grup restrâns

• Etapa 4 (Gamma)• Etapa 4 (Gamma)• Release-ul către public



JUnitJUnitnu CppUnit pentru C++



Unit TestsUnit TestsU t estsU t ests

• Testarea segmentelor individuale de codg

• Facilitează refacerea codului la un moment ulterior şi• Facilitează refacerea codului la un moment ulterior şi asigurarea că modulul încă funcţionează corect (e.g. Regression Testing)Regression Testing)

• 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



JUnitJUnit• Filozofie:

JU tJU t

– “Any program feature without an automated test simply doesn’t exist.” - Extreme Programming Explained, Kent BeckBeck

• Gratis, open source (GPL’d)• Integrat în Eclipse

– Interfaţă graficăInterfaţă grafică

– Posibilitatea selectării testelor ce se vor a fi rulate

– Suport pentru suite de teste

• http://www.junit.orgp j g



Ce este un test JUnit?Ce este un test JUnit?Ce este u test JU tCe este u test JU t

• Teste de unităţi sunt scrise în clase de test• De exemplu, clasa Stack

– Clasa Stack are push, pop, count, …C asa S ac a e pus , pop, cou ,– Clasa TestStack are testPush, testPop

• Ce se adaugă? Aserţiuni• Ce se adaugă? Aserţiuni.– Un pachet de metode ce verifică diverse

proprietăţi:proprietăţi:• Egalitatea variabilelor• Identitatea obiectelorIdentitatea obiectelor

– Aserţiunile sunt folosite pentru a determina verdictul cazului de test

87

verdictul cazului de test



Clasa StackClasa StackC asa StacC asa Stacpublic class Stack {

int[] elements;int[] elements;int topElement = -1;

public Stack() {public Stack() {this(10);

}

public Stack(int size) {elements = new int[size];

}

public boolean isEmpty() {p p yreturn topElement == -1;

}}

88

}



Testarea JUnitTestarea JUnitesta ea JU testa ea JU t• Teste – subclase ale junit.framework.TestCase

M t d l î “t t” t t t d ăt• Metodele ce încep cu “test” sunt executate de către TestRunnerEx teste pentru constructori:

public class TestStack extends TestCase {

• Ex. – teste pentru constructori:

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

}

public void testSizeConstructor() {public void testSizeConstructor() {Stack test = new Stack(5);assertTrue(test.isEmpty());

}}}



AserţiuniAserţiunise ţ use ţ u

• Aserţiunile sunt definite în clasa specială JUnit A tAssert– Dacă aserţiunile sunt adevărate se continuă

ţi t d iexecuţia metodei.– Dacă oricare aserţiune este falsă se opreşte

execuţia metodei iar rezultatul cazului de test vaexecuţia metodei, iar rezultatul cazului de test va fi “fail”.Dacă se aruncă orice excepţie în timpul execuţiei– Dacă se aruncă orice excepţie în timpul execuţiei metodei rezultatul cazului de test va fi “error”.Dacă nici o aserţiune nu a fost încălcată pe– Dacă nici o aserţiune nu a fost încălcată pe durata execuţiei întregii metode cazul de test va fi trecut (pass).

90

fi trecut (pass).



Clasa AssertClasa AssertC asa sse tC asa sse tassertTrue()assertFalse()assertEquals()

tN tE l ()assertNotEquals()assertSame()assertNotSame()assertNotSame()assertNull()assertNotNull()assertNotNull()fail()

Pentru o listă completă de metode & argumente consultaţi şihttp://junit.sourceforge.net/javadoc/

91

p j g j



Setarea testelorSetarea testelorSeta ea teste oSeta ea teste o• Înainte de fiecare test se execută metoda setUp():

import junit.framework.TestCase;

public class StackTrace extends 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);}

}



CaCazuri multiple de testzuri multiple de testCaCa u u t p e de testu u t p e de test

• Mai multe clase de test pot fi rulate psimultan

• Încă un exemplu:• Încă un exemplu:



Folosirea unei suite pentru executarea Folosirea unei suite pentru executarea i l i di l i d

• AllTests execută toate testele din StackTest şi QueueTest

mai multor cazuri de testmai multor cazuri de testş

• Eclipse generează clasa în mod automat– Din meniul File se selectează New apoi Other În fereastra de dialogDin meniul File se selectează New, apoi Other. În fereastra de dialog

se selectează “JUnit Test Suite”



Rularea testelor JUnitRularea testelor JUnit• Se pot executa uşor din Eclipse

Se poate descărca Junit de la http://www junit org/ şi• Se poate descărca Junit de la http://www.junit.org/ şi rula din linia de comandă



Test vsTest vs.. TestCase vsTestCase vs.. TestSuiteTestSuiteest sest s estCase sestCase s estSu teestSu te

• “TestCase” este o clasă• Un test este reprezentat de o metodă

O “ ită d t t ” t t tă d• O “suită de teste” este reprezentată de o colecţie de teste (posibil înrudite) ce sunt rulate ca un grup

• Nu există diferenţe între rularea unei suite• Nu există diferenţe între rularea unei suite de teste şi a unui caz de test.



FrameworkFramework--ulul JUnitJUnitFrameworkFramework ulul JUnitJUnitTest

run(TestResult)

run(TestResult)

TestSuiterun(TestResult)

TestCaseTestResult

run(TestResult)addTest()

run(TestResult)runTest()setup()

tearDown()

fTests

fName

*suite(): TestSuite

AnotherTestClassTestele noastre.

*suite(): TestSuite

ATestClass

97

suite(): TestSuite*suite(): TestSuite



Rapid Application DevelopmentRapid Application Development

Two hours minimum, sir, at top warp speed At out present rate two daysspeed. At out present rate, two days...

Damn... Maximum warp, then.(Star Trek: Next Generation: Captains’

H )Honor)



Dezvoltarea rapidă de aplicaţiiDezvoltarea rapidă de aplicaţiie o ta ea ap dă de ap caţe o ta ea ap dă de ap caţ

• Metodele agile au captat atenţie dar alte g p ţabordări ale dezvoltării rapide de aplicaţii au fost folosite de mai mulţi aniau fost folosite de mai mulţi ani

• Acestea sunt proiectate pentru dezvoltarea d li ţii b i i t t d t ide aplicaţii business orientate spre date şi se bazează pe programarea şi prezentarea informaţiilor provenind dintr-o bază de date



Instrumente de dezvoltare RADInstrumente de dezvoltare RADst u e te de de o ta est u e te de de o ta e

• Limbaje de programare a bazelor de datej p g• Generare de interfeţe

L ăt i li ţii• Legături cu aplicaţii • Generare de rapoartep



Un mediu de dezvoltare RADUn mediu de dezvoltare RADU ed u de de o ta eU ed u de de o ta e

Sisteme Generator de Officeinterfeţe

Generator detLimbaj de rapoarteLimbaj de

programare DB

Database Management System

Mediu de dezvoltare

Database Management System

Mediu de dezvoltarerapidă de aplicaţii



Generarea de interfeGenerarea de interfeţţeeGe e a ea de te eGe e a ea de te eţţee

• Multe aplicaţii se bazează pe formulare complexe– Dezvoltarea unor formulare manual reprezintă o

activitate consumatoare de timp şi resurse• Mediile de dezvoltare RAD includ suport pentru

generarea de ecrane, precum:g– Definirea interactivă de formulare folosind tehnici

drag&drop;– Legarea de formulare în care sunt specificate secvenţe

de prezentare a acestora;– Verificarea de formulare în care sunt definite plaje de

valori pentru câmpuri ale formularelor.



Programarea vizualProgramarea vizualăăog a a ea uaog a a ea ua ăă

• 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 elementeelemente

• Mediile RAD oferă o mare gamă de componente t t t ti d d ltpentru a suporta acest tip de dezvoltare

• Acestea pot fi ajustate pentru a se armoniza cu cerinţele specifice ale aplicaţiilor



Programarea vizualProgramarea vizualăă şşi refolosirei refolosireog a a ea uaog a a ea ua ăă şş e o os ee o os e

Menu componentDate component

File Edit Views Layout Options Help

GeneralIndex12th January 2000 Index

Range checkingscript

User prompt

12th January 2000

3.876

Draw canvascomponent

p pcomponent +

script

Tree displaycomponent

104

component



Probleme cu dezvoltarea vizualProbleme cu dezvoltarea vizualăăob e e cu de o ta ea uaob e e cu de o ta ea ua ăă

• Dezvoltarea în echipă este dificil de pcoordonat.

• Nu există o arhitectură explicită a• Nu există o arhitectură explicită a sistemului.

• Dependenţele complexe dintre părţi ale programului pot cauza probleme deprogramului pot cauza probleme de mentenanţă.



COTSCOTSCO SCO S

• 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ţelorDe exemplu, un sistem de gestiune a cerinţelor poate fi construit folosind:– O bază de date pentru stocarea cerinţelor;– O bază de date pentru stocarea cerinţelor;– Un procesor word pentru capturarea cerinţelor şi a

formularelor de rapoarte;formularelor de rapoarte;– Un spreadsheet pentru gestionarea istoriei dezvoltării.



Software PrototypingSoftware Prototyping



Back testingBack testingBack testingBack testing

Date de test

Prototip desistem

Sistemul aplicaţie

ComparatorComparatorde rezultate

Raport aldiferenţelor



Procesul de prototipareProcesul de prototipareProcesul de prototipareProcesul de prototipare

Stabilirea obiectivelorprototipului

Definireafuncţionalităţii

prototipuluiDezvoltareaprototipului

Evaluareaprototipuluiprototipului prototipului

Raport deevaluare

Planulprototipului

Definiţiafuncţionalităţii

Prototipulexecutabil



PrototipuriPrototipuri ThrowThrow--awayawayPrototipuri Prototipuri ThrowThrow awayaway• 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 sunt în general nedocumentate;– Structura prototipului este în general degradatăStructura prototipului este în general degradată

de procesele de modificări rapide aplicate;– Prototipul nu satisface standarde de calitatePrototipul nu satisface standarde de calitate

înaltă ce ar putea fi impuse de organizaţie.



SumarSumarSu aSu a• O abordare iterativă a dezvoltării software conduce la

livrarea mai rapidă a aplicaţieilivrarea mai rapidă a aplicaţiei• Metodele agile sunt metode de dezvoltare iterativă ce

urmăresc reducerea overhead-ului de dezvoltare şi prod cerea rapidă de soft areproducerea 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 dea 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 proiectarecerinţelor şi a opţiunilor de proiectare

• În abordarea bazată pe prototipuri throw-away se începe cu cerinţele cel mai puţin înţelese; în dezvoltarea

111

ţ p ţ ţincrementală se începe cu cerinteţele cel mai bine înţelese



ResurseResurseWeb Sites

http://www.testdriven.comhttp://www xprogramming com

esu seesu se

http://www.xprogramming.comhttp://AgileAlliance.comhttp://ExtremeProgramming.orghttp://www.junit.orghttp://www.xprogramming.comhttp://www.xprogramming.comhttp://www.refactoring.comhttp://www.pairprogramming.com

Blogshttp://dotnetjunkies.com/WebLog/darrell nortonp j g _http://www.peterprovost.orghttp://weblogs.asp.net/nunitaddinhttp://weblogs.asp.net/jamesnewkirkhttp://www,iserializable.com

BooksBooksExtreme Programming Explained – Kent BeckRefactoring – Martin FowlerPlanning Extreme Programming – Kent Beck et alExtreme Programming Installed Ron Jeffries et alExtreme Programming Installed – Ron Jeffries et alExtreme Programming Examined – Giancarlo Succi et alExtreme Programming in Practice – Robert C. Martin et alExtreme Programming Explored – William C. WakeExtreme Programming Applied Ken Auer et alExtreme Programming Applied – Ken Auer et alThe Costs and Benefits of Pair Programming – Alistair Cockburn et al



Temă pentru acasăTemă pentru acasăTema constă în răspunsul la următoarele întrebări:

Temă pentru acasăTemă pentru acasă

• Explicaţi de ce rata de productivitate a programatorilor ce lucrează în perechi este aproximativ aceeaşi ca a doi programatori lucrând individual. Sugeraţi patru motive.g ţ p

• Un manager software este implicat în dezvoltarea unui sistem pentru translatarea cerinţelor software în specificaţii software formale. Comentaţi avantajele şi dezavantajele următoarelor strategii de d ltdezvoltare:

– Dezvoltarea unui prototip throw-away, evaluare, review al cerinţelor de sistem.Dezvoltarea sistemului final în C.Dezvoltarea sistemului precând de la cerinţele existente folosind Java– Dezvoltarea sistemului precând de la cerinţele existente folosind Java, modificarea acestora pentru adaptarea ulterioară a unor cerinţe modificate venite din partea utilizatorului.

– Dezvoltarea sistemului folosind dezvoltarea incrementală cu un utilizator i li t î hi d d ltimplicat în echipa de dezvoltare.

Răspunsurile se încarcă în format PDF pe site, până pe data de 07.03.2012.


2 Rapid software development

Documents

Transcript of 2 Rapid software development