ăde e learning șși curriculăe content pentru învățământul ...

Platformă de e‐learning și curriculă e‐content g șpentru învățământul superior tehnic

Instrumente pentru Dezvoltarea Programelorp g

8. Instrumente software si paradigma Rapid software p g pdevelopment.

Platformă de e‐learning și curriculă e‐content pentru învățământul superior tehnic

SSumar

Metode AgileSCRUMeXtreme Programming

Testare – JUnit

Rapid Application Development

Prototipare

2IDP – Instrumente pentru Dezvoltarea Programelor


Metode Agile

“We are uncovering better ways of developing 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 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. predictiveAdaptive Predictive

p p

• Categorie uşoară, ‘agile’• Control prin feedback• Multe iteraţii scurte

(săptămâni)

• Categorie grea, ‘traditional’ • Control prin planificare• Câteva iteraţii lungi (luni)

S ă ( 30 d lt t i)(săptămâni)• Scară mică (<10 dezvoltatori)• Comunicare faţă-în-faţă• Centrate pe cod şi oameni

• Scară mare (>30 dezvoltatori)• Documente scrise• Centrate pe reguli• AutoritarieneCentrate pe cod şi oameni

• Egalitariene

• Probleme:

• Autoritariene

• Probleme:– Inflexibilitate la modificările

– Rezultatele de lungă durată puţin predictibile

– Haos asociat cowboy-coding

Inflexibilitate la modificările cerinţelor

– Efort mărit de Integrare şi testare

– Birocraţia asociată ‘Control


• E.g. XPBirocraţia asociată Control freak’

• E.g. waterfall


R id S f D lRapid Software Development

Adaptarea continuă a organizaţieiAdaptarea continuă a organizaţieiOportunităţi noi de businessModificarea mediului de business, competiţia

Fapt: Rapiditatea dezvoltării şi livrării cel mai desFapt: 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 iCerinţe

M di î i ă hi b Mediu în continuă schimbare =>

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ţiiastfel de situaţii

Mai adecvată este o abordare bazată/orientată pe specificaţii şi livrare iterativeSoftware‐ul livrat (mai) rapid



lRaportul Haos:

Î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,


phttp://www.xp2003.org/xp2002/talksinfo/johnson.pdf


C i i il l RADCaracteristicile proceselor RAD

Procesele de specificare, proiectare şi implementare suntp , p ş pconcurenteNu există specificaţie detaliatăDocumentaţia proiectării este minimalăDocumentaţia proiectării este minimală

Sistemul este dezvoltat într‐o serie de incremente Sistemul este dezvoltat într‐o serie de incrementeUtilizatorii finali evaluează fiecare incrementarePropuneri pentru incrementările următoare

Interfeţele utilizator sunt de obicei dezvoltate folosind un i t d d lt i t ti


sistem de dezvoltare interactiv


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 jurulsunt implicaţi în dezvoltare > sistemul este dezvoltat în jurul cerinţelor impuse; utilizatorii sunt mai devotaţi sistemului



Problemele dezvoltării incrementaleProblemele dezvoltării incrementale Probleme de managementProgresul poate fi greu de apreciatProgresul poate fi greu de apreciat Problemele sunt greu de rezolvat deoarece nu există nici o documentaţie care să demonstreze corectitudinea implementării.

Probleme contractualeContractul în mod normal include o specificaţie; fără o specificaţie trebuie folosite forme diferite de contractare.

Probleme de validareFă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 iPrototyping

Pentru unele sisteme mari dezvoltarea iterativă incrementală poate fi nepracticăEx: mai multe echipe lucrează în diverse locaţii la acelaşi proiect

PrototipareaPrototipareaUn sistem experimental este dezvoltat ca bază pentru formularea cerinţelorSistemul experimental nu mai e necesar după ce se ajunge la un consensSistemul 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:P l d i i i i ţ l t j t l t bili i lidProcesul de inginerie a cerinţelor pentru a ajuta la stabilirea şi validarea cerinţelor;În procesul de proiectare pentru explorarea opţiunilor şi dezvoltarea unui design UI;


g ;În procesul de testare pentru rularea unor verificări back‐to‐back.


Dezvoltarea incrementală şi prototiparea

DezvoltareSistemul livrat

Cerinţe

Dezvoltare incrementală

Throw-awayprototyping

Prototipul executabil + Specificaţia sistemului

D13IDP – Instrumente pentru Dezvoltarea Programelor

Demo…


Obi i fli lObiective conflictuale

Obiectivul dezvoltării incrementale îl constituie livrareaObiectivul dezvoltării incrementale îl constituie livrareaunui sistem funcţional către utilizatorii finaliDezvoltarea începe cu cerinţele ce sunt cel mai bine înţelese.

Obiectivul abordării “throw‐away prototyping” este de Obiectivul abordării throw‐away prototyping este de a valida sau deriva cerinţele sistemuluiProcesul de prototipare începe cu acele cerinţe ce sunt celp p p ţmai puţin înţelese.



M d ilMetode agile

Insatisfacţiile cu overhead‐ul implicat de metodele de ţ pproiectare 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ă schimbaresatisface cerinţele în continuă schimbare.

M d l il d î i l i l d b i


Metodele agile sunt adecvate în special sistemelor de business de mărime mică şi medie sau produselor PC.


A il S f D lAgile Software Development A apărut în anii 1990 ca reacţie la metodele tradiţionale “ ” d d l“greoaie” de dezvoltare

Presupune multe iteraţii scurte (săptămâni) şi ‘prototiparea’:Iteraţie

Analiza Proiect Implementare Testare Prototip

A li P i P i

Iteraţie#1

#2 Analiza Proiect Implementare Testare

Analiza Proiect Implementare Testare

Prototip

Prototip

#2

#3

Control prin feedback: re evaluarea şi revizia proiectului după

…


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


P i i iil d l ilPrincipiile metodelor agilePrincipiul 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 i l t t E hi t b i lă tă ă i it iilşi exploatate. Echipa trebuie lăsată să-şi exercite propriile

metode de lucru fără un proces prescriptiv.

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

Menţinerea simplităţii Focus pe simplitate atât în software-ul dezvoltat, cât şi înprocesul de dezvoltare folosit. Pe cât posibil se recomandăli i l ităţii di i t


eliminarea complexităţii din sistem.


lPractici Agile

Delimitări Sandbox / Environment/



P bl l d l ilProblemele metodelor agile

Dificil de menţinut interesul clienţilor implicaţi în procesul de dezvoltare

Membrii echipei pot fi neadecvaţi pentru interesul intens înMembrii 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 l i i i i li imulţi acţionari implicaţi

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

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



d l ă?Deci ce Metode Agile există?

i ( ) ( k d h Extreme Programming (XP) (Kent Beck, Ward Cunningham, Ron Jeffries)

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

DSDM – Dynamic Systems Development Method (Community owned))

Crystal (Alistair Cockburn)

ASD Adaptive Software Development (Jim Highsmith) ASD – Adaptive Software Development (Jim Highsmith)

XBreed (Mike Beedle)



Deci mai mult decât …



Studiu de caz:Metodele de dezvoltare SCRUM



î ă ?Ce înseamnă SCRUM?

P ibil Posibil asta:



SCRUMSCRUM Proces de dezvoltarea iterativ‐incrementală

I l d t d ti i i l i d fi it (“Pi ” i “Chi k ”) 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)p j g ( )

Team

•Aproximativ 7 persoane (grupul de lucru)


•Are responsabilitatea livrării produsului

•Abilități diverse pentru efectuarea activităților (proiectant, dezvoltator, tester, etc.)


hEchipa SCRUM

Auto‐organizată

Membrii nu au roluri bine definite Pot lucra în oricare activitate și grup.

Membrii echipei SCRUM sunt cunoscuți ca PigsgSunt devotați pentru livrarea scopului Sprint

Persoanele implicate dar care nu sunt Persoanele implicate dar care nu sunt devotate proiectului sunt Chickens Participă la întâlnirile Scrum doar ca


Participă la întâlnirile Scrum doar ca observatori


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

O metrică simplă:

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

Dacă îți păstrezi job-ul înDacă îți păstrezi 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 poate modifica Spring Backlog-ul în p p g g

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



l d klExemplu ‐ Product Backlog



Practici SCRUM Sprint Planning Meeting

Ședință ce conduce la luarea deciziilor privind ce itemi de Backlog sunt Ș ț p gincluși în următorul Sprint

Sprint BacklogIt ii ă fi l ți î t S i tItemii ce se urmăresc a fi rezolvați într‐un Sprint

Product Backlog

Capabilităţile Capabilităţile Echipei

Condiţii Business ReviewConsider

Next Sprint GoalStabilitate Tehnologică

Incredement E l l

Consider Organize Sprint Backlog


Executabil alProdusului


Exemplu ‐ Sprint Backlog



Ciclurile de dezvoltare SCRUMCiclurile de dezvoltare SCRUM

24 hoursDaily Scrum

Meeting

30 daysBacklog tasksexpanded

Sprint Backlogexpandedby team

Product BacklogAs prioritized by Product Owner

Potentially ShippableProduct Increment



Î âlÎntâlniri…

Daily Scrum Daily Scrum

Întâlnire zilnică de lucru în timpul SPRINT‐ului.Începe la ore fixe.Începe 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 de activitățiaccent pe integrare și suprapuneri de activități.Participă câte o persoană delegată din fiecare echipă.Agenda similară cu cea a Daily Scrum dar mai apar și alteAgenda 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ă ceva ce poate încetini activitatea echipei?


Există ceva ce poate încetini activitatea echipei?Există modificări în modul de lucru sau componența echipei?


Î âlÎntâlniri…

Sprint Planning Meetingp g gLa începutul unui nou Sprint.Se selectează activitățile ce vor fi făcute în cadrul Sprint‐ului curent => Sprint BackloggSe 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 Retrospectivep p



Avantaje SCRUM SCRUM facilitează crearea unor echipe self‐organizate

Î j ă l b il hi i i Încurajează co‐locarea membrilor echipei și

Comunicația verbală între membrii echipei



O l S t KMOracle Support – KM



Mai multe…

Recomandări bibliografice:Recomandări bibliografice:

http://www.scrumalliance.org/

Cartea “Agile Software Development with SCRUM” ‐ Ken Schwaber, MikeCartea Agile Software Development with SCRUM Ken Schwaber, Mike Beedle

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 Instead of cowboy coders we have Instead of cowboy coders we have software sheriffs; working together as a software sheriffs; working together as a

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 effectiveconcise and effectiveconcise, and effective.concise, and effective.(James D. Wells, (James D. Wells,

extremeprogramming.org)extremeprogramming.org)



eXtreme Programming (1)

di l i d il b d b ă Una dintre cele mai cunoscute metode Agile – abordare bazată pe tactici duse la extrem:

If testing is good let everybody test all the timeIf testing is good, let everybody test all the time

If code reviews are good, review all the time

If design is good refactor all the time If design is good, refactor all the time

If integration testing is good, integrate all the time

If i li it i d d th i l t thi th t ld ibl If simplicity is good, do the simplest thing that could possibly work

If short iterations are good, make them really, really short


If short iterations are good, make them really, really short


X P i (2)eXtreme Programming (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 coduluiincluderea utilizatorului în echipa de dezvoltare programare pairwiseprogramare pairwise



X P i (3)eXtreme Programming (3) Noi versiuni pot fi construite chiar de mai multe ori pe

izi

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 managerice încurajeazăj5 valori12 practici/reguli



C l 5 l i XPCele 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 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

3 Si lit t3. Simplitate 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 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!) Point of time

change


g p5. Respect pentru echipă şi munca proprie

Point of timewithin project


C l 12 i i XP (1)Cele 12 practici XP (1)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 clientul3. Test Driven Development3. Test Driven Development

Î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 understanding5. Folosirea unui Coding Standard de comun acceptat6 C ll i C d O hi6. Collective Code Ownership

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

7. Simple Design


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


C l 12 i i XP (2)Cele 12 practici XP (2)Continuous process9. 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 inutilep ţ

11.Small Releases

Programmer welfare12.Sustainable Pace Nu se lucrează în regim Overtime mai degrabă se modifică


Nu se lucrează în regim Overtime – mai degrabă se modificăgraficul de proiect sau chiar scopul final


T i l i XPTerminologia XP

User storyUser storyFuncţionalităţile pe care sistemul trebuie să le ofere utilizatorilorScrise de obicei pe o cartelă în câteva frazeAr trebui să necesite 1‐3 săptămâni pentru implementare

Release: sistem rulabil ce implementează “user stories”‐urileimportante Spike

Prototip folosit ca proof of conceptPrototip folosit ca proof‐of‐conceptExplorează fezabilitatea unei abordări a implementării

IterationFază a implementării de durata 1‐3 săptămâniFază a implementării, de durata 1 3 săptămâniConţine task‐uri, fiecare de durata 1‐3 zile

Project velocity: folosit ca unitate de estimare a progresuluiFie #stories / timp


/ pFie time / #stories


E l d l ă ii XPEtapele dezvoltării XP

User DefectsProject velocityStories

Release

DefectsProject velocity

ReleasePlanning TestsIteration

SmallRelease

NextIteration

NewUser Story Release

UncertainEstimates

ConfidentEstimates

= is followed by


46Spike = result goes into


User Stories



S iil i lScenariile cerinţelor

În XP cerinţele utilizatorilor sunt specificate sub formă În XP cerinţele utilizatorilor sunt specificate sub formă de scenarii scrise pe carduriUn user story este o scurtă descriere a ce se doreşte, scrisă de li t î t i l i t i fă ă i t ă t h i ăclient în terminologia acestuia, fără sintaxă tehnică.

Echipa de dezvoltare le transpune în task‐uri de implementareimplementare 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 d f d t d l diEx: Story card for document downloading

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 creditbe 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, h h b itt d thi th ti l t i d l d dwhen you have submitted this, the article you want is downloaded

onto your computer.

You then choose a printer and a copy of the article is printed. You p py ptell 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


so it is automatically deleted from your computer.


E lExemplu Story card-urile cuprind cel mai adesea

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

• 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 bXP şi schimbarea

Î d di i l d l f id În mod tradiţional un dezvoltator software este consideratînţelept atunci când proiectează soluţii luând în considerareposibile extensii şi modificări ulterioare.se recomandă pierderea timpului şi un efort mai mare pentru anticipareaschimbă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 anticipateanticipate.

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


p ş g p


T î b d XPTestarea în abordarea XP

Dezvoltare bazată pe abordarea “test‐first”p

Dezvoltarea incrementală a testelor pornind de la scenariiscenarii

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: 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 userselects which way they wish to pay. If the usery y p yhas a library subscription, then they can input 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 Finallytheyof the article is posted to this account. Finally, theymay 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.



D i l i dDescrierea cazului de test

Test 4: Test cr edit card validityTest 4: Test cr edit card validity

Input:Astring representing the credit card number and two integers representingthe month and year when the card expiresy pTests: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 .U i h fi 4 di i f h di d bUsing the first 4 digits of the credit card number ,check 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 cardissuerissuerOutput:OK or error message indicating that the card is invalid



T fi d lTest‐first development

Scrierea testelor înaintea codului poate duce la clarificareacerinţelor ce se vor implementate

Testele sunt scrise sub formă de programe, putând fiexecutate 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


odată cu introducerea unei noi funcţionalităţi în proiectVerificare că noua funcţionalitate nu a introdus erori în proiect


P i iPair programming

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

• Două roluri: – implementare – strategie

În abordarea XP programatorii lucrează în

strategie

programatorii lucrează în echipe, conlucrând la scriereacodului



A jAvantaje

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ăinformală încurajează refactorizarea

Măsurătorile arată că productivitatea dezvoltării folosind această abordare este comparabilă cu aceea în

d i i di i i l ă i d d


care doi indivizi lucrează indepedent


R li i i i i lifiReguli şi practici simplificate Planning • Designing User Stories

Release Planning

g g• Simplicity• System Metaphorg

Small Releases

Measure Project Velocity

• CRC cards• Spike solutions

GMeasure Project Velocity

Divide project to iterations

Iterations Planning

• YAGNI• Refactor

Iterations Planning

Move People around

d


Stand up meeting


R li i i i i lifiReguli şi practici simplificate Coding Customer available • Testing Customer available Code standards Test Driven

• Testing• Unit test everything• All tests pass before

release Test‐Driven Pair Programming Sequential change

release• Bug== new test• Acceptance tests Sequential change

integration Integrate often Collective code ownership Don’t optimize early


No overtime


H XP P iHarta XP ‐ Proiect



H XP I iHarta XP – Iteraţie



H XP D lHarta XP ‐ Dezvoltare



Harta XP Drepturi comune asupra coduluiHarta XP – Drepturi comune asupra codului



i il i d dPracticile XP sunt inter‐dependente

On-site Customer Planning game

40 Hour Week

Metaphor

RefactoringSimple Design

Sh t R lShort Releases

TestingPair Programming

Collective OwnershipCoding Standards

Continuous Integration


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


Exemplu de Implementare XPe 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 proiectuluiProiect: Customizarea unui Sistem de Contabilizare a Muncii existent.Utilizatorul principal: Resursele umaneEchipa de proiect: Programer1, Programer2, Senior Programmer, DBA, Project Manager.Managerul de proiect deţine: Project plan, project source code, project user

i trequirements.Prog1 deţine Part P1; Prog2 deţine Part P2; Senior deţine Part P3; DBA deţine obiectele Database;C t t l tili t l î d l hi i j t


Contactul cu utilizatorul în cadrul echipei: project manager.


Diagrama originală deDiagrama 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 UserP1 P2 P3

Rpersoane. Atunci când mai multe de o persoană pleacă proiectul stă să moară dacă nu se iau măsuri critice în structura P2

P1, P2, P3and R.

ăsu c ce s uc u aproiectului.

D ă t i l i d d lt t i

Prog1

Pro 2

P3

P2

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

P1

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

f fimplementare. Utilizatorii sunt disponibili cu feedback referitor la schimbări şi cerinţe de implementare.User stories sunt folosite pentru descrierea cerinţelor şi testarea

l ăimplementării.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 utilizatori şi programatori. User

P1, P2, P3R and Dataş p g

Acces direct la oricare resursă a proiectului. Drepturi colective asupra

User

Drepturi colective asupra proiectului.

Prog1

Pro 2

ProLead



SCRUM și eXtreme Programming

SCRUM d f l i X P i SCRUM este adesea folosit ca un wrapper peste eXtreme Programming



Dezvoltarea Orientată spre Testare

It k fi MY tIt works fine on MY computer.It’s a feature.That’s weird…It’s never done that beforeIt s never done that before.It must be a hardware problem.It worked yesterday.It’s just some unlucky coincidenceIt s just some unlucky coincidence.

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


p g ,extremetesting)


T t t l i ftTestarea – parte a procesului software



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 sistemuluiCerinţe funcţionaleCerinţ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ă?

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 programuluiCodul de test legat de biblioteci şi chiar aplicaţia software

Cel mai adesea – unit testsTestează părţi ale sistemului software


Verificare – componentele sunt funcţionale şi robuste


Planuri de testare

Scrise înainte ca testele să fie dezvoltateChiar înainte de scrierea codului!

Conţin Test CasesDescrierea testuluiDate folosite pentru testareRezultate aşteptate....



Planuri de testarePlanuri de testare

Test 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 to $0.00

23.2 Add advert 1 to Campaign

Advert estimated cost=$500

Advert added to the database.Campaign estimated cost is set to $500

23.3 .....


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


D l dDatele 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 sau aproape de limite (0, ‐1, 0.999)f g 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 dNivele de testare 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 livrează funcţionalitatea cerută)funcţionalitatea cerută)

System testing (întregul sistem funcţionează fără interacţiinedorite î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 l ă iiEtapele testării Etapa 1

Testarea modulelor (claselor), apoi a programelor (cazuri de folosire), apoi a suitei (aplicaţia)

Etapa 2 (Alpha Testing sau Verificarea)Etapa 2 (Alpha Testing sau Verificarea)Execuţia programelor într‐un mediu simulat şi testarea intrărilor şi ieşirilorEtapa 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 eroripe o a ţe sub oad ş ecupe ă d d e se e oReseale unui grup restrâns

Etapa 4 (Gamma)


•Release‐ul către public


JunitJunit



U i TUnit Tests

Testarea segmentelor individuale de codg

Facilitează refacerea codului la un moment ulterior şi asigurarea Facilitează 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 iJUnit Filozofie: “Any program feature without an automated test simply doesn’t exist.” ‐ Extreme Programming Explained, Kent Beck

Gratis open source (GPL’d) Gratis, open source (GPL 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 JU i ?Ce este un test JUnit?

Teste de unităţi sunt scrise în clase de test Teste de unităţi sunt scrise în clase de test

De exemplu, clasa StackClasa Stack are push pop countClasa Stack are push, pop, count, …Clasa TestStack are testPush, testPop

Ce se adaugă? AserţiuniCe se adaugă? Aserţiuni.Un pachet de metode ce verifică diverse proprietăţi:

•Egalitatea variabilelorg•Identitatea obiectelor

Aserţiunile sunt folosite pentru a determina verdictul cazului


de test


Cl S kClasa Stack

public class Stack {int[] elements;int topElement = -1;

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

}

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

}

public boolean isEmpty() {return topElement == -1;

}


}}


T t JU itTestarea JUnit• Teste – subclase ale junit.framework.TestCase• Metodele ce încep cu “test” sunt executate de către• Metodele ce încep cu test sunt executate de către

TestRunner• Ex. – teste pentru constructori:

public class TestStack extends TestCase {

public void testDefaultConstructor() {

p

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

}

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


assertTrue(test.isEmpty());}

}


A i iAserţiuni Aserţiunile sunt definite în clasa specială JUnit AssertDacă 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”.D ă ă i i î i l i iDacă 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 durataDacă nici o aserţiune nu a fost încălcată pe durata execuţiei întregii metode cazul de test va fi trecut (pass).



Cl AClasa AssertassertTrue()assertFalse()assertEquals()assertNotEquals()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 lSetarea testelor Î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 i l i l dCazuri multiple de test

Mai multe clase de test pot fi rulate simultan

Încă un exemplu:



Folosirea unei suite pentru executarea mai multorFolosirea 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 t t l JU itRularea testelor JUnit Se pot executa uşor din Eclipse

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



T T C T S iTest vs. TestCase vs. 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 ) t l t(posibil înrudite) ce sunt rulate ca un grup

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



Framework‐ul JUnit

run(TestResult)

Test

( )

run(TestResult)addTest()

TestSuiterun(TestResult)

runTest()setup()

TestCase

fTests

TestResult

setup()tearDown()

fName

AnotherTestClassTestele noastre.ATestClass


*suite(): TestSuiteeste e oast e

*suite(): TestSuite


Rapid Application DevelopmentRapid Application Development

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

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

Honor)



D l idă d li iiDezvoltarea rapidă de aplicaţii

Metodele agile au captat atenţie dar alte abordări ale dezvoltării Metodele 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 d d l RADInstrumente de dezvoltare RAD

Limbaje de programare a bazelor de date Limbaje de programare a bazelor de date

Generare de interfeţe

L ăt i li ţii Legături cu aplicaţii

Generare de rapoarte



U di d d l RADUn mediu de dezvoltare RAD

Sisteme Office

Generator de interfeţe

Generator derapoarteLimbaj de

programare DB

Database Management System

Mediu de dezvoltarerapidă de aplicaţii



G d i fGenerarea de interfeţe

Multe aplicaţii se bazează pe formulare complexep ţ p pDezvoltarea unor formulare manual reprezintă o activitate consumatoare de timp şi resurse

Mediile de dezvoltare RAD includ suport pentru generarea de ecrane, precum:

D fi i i t ti ă d f l f l i d t h i i d &dDefinirea interactivă de formulare folosind tehnici drag&drop;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 i lăProgramarea vizuală

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 i lă i f l iProgramarea vizuală şi refolosire

M t

File Edit Views Layout Options Help

Menu componentDate component

y p p

GeneralIndex

Range checkingscript

12th January 2000

3.876

Draw canvascomponent

User promptcomponent +

script

Tree display


component


P bl d l i lăProbleme cu dezvoltarea vizuală

D l î hi ă difi il d d Dezvoltarea în echipă este dificil de coordonat.

Nu există o arhitectură explicită a sistemului.

Dependenţele complexe dintre părţi ale programului pot cauzaprobleme de mentenanţă.



COTSCOTS 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 ficonstruit folosind:O bază de date pentru stocarea cerinţelor;Un procesor word pentru capturarea cerinţelor şi a p p p ţ şformularelor de rapoarte;Un spreadsheet pentru gestionarea istoriei dezvoltării.



DDocumente compuse

Pentru unele aplicaţii un prototip poate fi creatPentru 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 tă t i â d t l t t l t linvocată atunci când este selectat elementul. Documentul reprezintă integratorul diverselor aplicaţii.



L li iilLegarea aplicatiilor



Software Prototyping



kBack testing

Date de test

Prototip desistem

Sistemul aplicaţie

Comparatorde rezultate

Raport aldiferenţelor


diferenţelor


l dProcesul de prototipare

Stabilirea DefinireaStabilirea obiectivelorprototipului

Definireafuncţionalităţii

prototipuluiDezvoltareaprototipului

Evaluareaprototipului

Raport deevaluare

Planulprototipului

Definiţiafuncţionalităţii

Prototipulexecutabil



hPrototipuri Throw‐away

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;P t ti il t î l d t tPrototipurile sunt în general nedocumentate;Structura prototipului este în general degradată de proceselede modificări rapide aplicate;p p ;Prototipul nu satisface standarde de calitate înaltă ce ar puteafi impuse de organizaţie.



SSumar O abordare iterativă a dezvoltării software conduce la livrarea mai rapidă a aplicaţieirapidă a aplicaţiei Metodele agile sunt metode de dezvoltare iterativă ce urmăresc reducerea overhead‐ului de dezvoltare şi producerea rapidă de softwaresoftware 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 se începe cu cerinţele


p p p y p ţcel mai puţin înţelese; în dezvoltarea incrementală se începe cu cerinteţele cel mai bine înţelese


RResurseCarti

Extreme Programming Explained Kent BeckExtreme Programming Explained – Kent BeckRefactoring – Martin FowlerPlanning Extreme Programming – Kent Beck et alExtreme Programming Installed – Ron Jeffries et alExtreme Programming Examined – Giancarlo Succi et alExtreme Programming in Practice – Robert C. Martin et alE t P i E l d Willi C W k

Web Siteshttp://www.testdriven.comhttp://www.xprogramming.com

Extreme Programming Explored – William C. WakeExtreme Programming Applied – Ken Auer et alThe Costs and Benefits of Pair Programming – Alistair Cockburn et al

p // p g ghttp://AgileAlliance.comhttp://ExtremeProgramming.orghttp://www.junit.orghttp://www.xprogramming.comhttp://www.xprogramming.comhttp://www.refactoring.comhttp://www.pairprogramming.comhttp://dotnetjunkies.com/WebLog/darrell_nortonhttp://www.peterprovost.orghtt // bl t/ it ddi


http://weblogs.asp.net/nunitaddinhttp://weblogs.asp.net/jamesnewkirkhttp://www,iserializable.com

ăde e learning șși curriculăe content pentru învățământul ...

Documents

Transcript of ăde e learning șși curriculăe content pentru învățământul ...