Sunteți pe pagina 1din 57

Metode de dezvoltare software

Procese de dezvoltare software

06.03.2017

Alin tefnescu
Procese de dezvoltare software

Prezentare bazat pe materiale de: Florentin Ipate (FMI UniBuc) - note de curs
i Ian Sommerville: Software Engineering 9th edition
Procese de dezvoltare software n practic

de la https://weblogs.java.net/blog/chet/archive/2008/01/crystal_methodo.html
Varianta detaliat

de la geek-and-poke.com
Cerine Procesul de dezvoltare
cascad (waterfall)

Design

Implementare

Testare

Mentenan
Etapele procesului cascad

n analiza i definirea cerinelor: Sunt stabilite serviciile, constrngerile i


scopurile sistemului prin consultare cu utilizatorul. (ce trebuie s fac
sistemul).

n design: Se stabilete o arhitectur de ansamblu i funciile sistemului


software pornind de la cerine. (cum trebuie s se comporte sistemul).

n implementare i testare unitar: Designul sistemului este transformat ntr-


o mulime de programe (uniti de program); testarea unitilor de program
verific faptul c fiecare unitate de program este conform cu specificaia.

n integrare i testare sistem. Unitile de program sunt integrate i testate


ca un sistem complet; apoi acesta este livrat clientului.

n operare i mentenan. Sistemul este folosit n practic; mentenana


include: corectarea erorilor, mbuntirea unor servicii, adugarea de noi
funcionaliti.
Avantaje i dezavantaje

n fiecare etap nu trebuie sa nceap nainte ca precedenta s fie ncheiat


n fiecare faz are ca rezultat unul sau mai multe documente care trebuie
aprobate
n bazat pe modele de proces folosite pentru productia de hardware
Avantaj: proces bine structurat, riguros, clar; produce sisteme robuste

n Probleme:
dezvoltarea unui sistem software nu este de obicei un proces liniar;
etapele se ntreptrund
metoda ofer un punct de vedere static asupra cerinelor
schimbarile cerinelor nu pot fi luate n considerare dup aprobarea
specificaiei
nu permite implicarea utilizatorului dup aprobarea specificaiei

Concluzie: Modelul cascad trebuie folosit atunci cand cerinele sunt bine
nelese i cnd este necesar un proces de dezvoltare clar i riguros.
Procesul incremental

Idee: un sistem de succes de mare dimensiune ncepe cu un sistem de


succes de mic dimensiune care apoi crete puin cte puin (Gilb, 1988)
Procesul incremental

n sunt identificate cerinele sistemului la nivel nalt, dar, n loc de


a dezvolta i livra un sistem dintr-o dat, dezvoltarea i livrarea
este realizat n pri (incremente), fiecare increment
ncorpornd o parte de funcionalitate.

n cerinele sunt ordonate dup prioriti, astfel nct cele cu


prioritatea cea mai mare fac parte din primul increment, etc.

n dup ce dezvoltarea unui increment a nceput, cerinele pentru


acel increment sunt ngheate, dar cerinele pentru noile
incremente pot fi modificate.
Procesul incremental (detaliat)
Avantajele procesului incremental
Avantaje
n clienii nu trebuie s atepte pn ce ntreg sistemul a fost livrat pentru a
beneficia de el. Primul increment include cele mai importante cerine, deci
sistemul poate fi folosit imediat.
n primele incremente pot fi prototipuri din care se pot stabili cerinele pentru
urmtoarele incremente.
n se micoreaz riscul ca proiectul s fie un eec deoarece prile cele mai
importante sunt livrate la nceput.
n deoarece cerinele cele mai importante fac parte din primele incremente,
acestea vor fi testate cel mai mult.
Probleme
n dificulti n transformarea cerinelor utilizatorului n incremente de mrime
potrivit.
n procesul nu este foarte vizibil pentru utilizator (nu e suficient documentaie
ntre iteraii).
n codul se poate degrada n decursul ciclurilor.
Exemple de procese incrementale

Exist multe variante de procese de dezvoltare incrementale:


n Unified Process cu varianta Rational Unified Process (RUP)
n procese de dezvoltare n spiral introduse de Boehm
n procese de dezvoltare agile. Exemple:
programare extrem (XP - extreme programming)
scrum
Rational Unified Process
Boehm spiral model
de la n-ix.com

Metodologii agile

Prezentare bazat pe Ian Sommerville: Software Engineering 9th edition


Procese agile n practic

de la dilbert.com
Metodologii agile

n Metodele de dezvoltare software expeditive" dezvoltate la


mijlocul anilor 1990 ca o reacie la aa-numitele metode
elaborate", care au fost caracterizate drept puternic
reglementate i rigide (v. modelul cascad)
n Puin istorie:
criza software 1960: depirea timpilor de livrare i a
bugetelor, conjugate cu nivelul sczut al calitii soluiilor.
- soluia #1: metodele structurate (80)
- soluia #2: metodologiile orientate obiect (OO)
- soluia #3: mbunatirea proceselor software (CMM)
- soluia #4: metodologiile agile
Metodologii agile

n scopul metodelor agile este de a reduce cheltuielile n procesul


de dezvoltare a software-ului (de exemplu, prin limitarea
documentaiei) i de a rspune rapid cerinelor n schimbare.

n aceste metode:
se concentreaz mai mult pe cod dect pe proiectare
se bazeaz pe o abordare iterativ de dezvoltare de software
produc rapid versiuni care funcioneaz, acestea evolund
repede pentru a satisface cerine n schimbare.

n n 2001, este publicat i semnat de mai muli practicieni


Manifestul Agil, care exprim succint principiile metodelor agile.
Agile Manifesto

http://agilemanifesto.org/iso/ro/
Noi scoatem la iveal modaliti mai bune de dezvoltare de
software prin experien proprie i ajutndu-i pe ceilali.
Prin aceast activitate am ajuns s apreciem:
n indivizii i interaciunea naintea proceselor i uneltelor
n software-ul funcional naintea documentaiei vaste
n colaborarea cu clientul naintea negocierii contractuale
n receptivitatea la schimbare naintea urmririi unui plan
Cu alte cuvinte, dei exist valoare n elementele din dreapta, le
apreciem mai mult pe cele din stnga.
Cele 12 principii ale manifestului agil
http://agilemanifesto.org/iso/ro/principles.html

1. Prioritatea noastr este satisfacia clientului prin livrarea


rapid i continu de software valoros.
2. Schimbarea cerinelor este binevenit chiar i ntr-o faz
avansat a dezvoltrii. Procesele agile valorific
schimbarea n avantajul competitiv al clientului.
3. Livrarea de software funcional se face frecvent, de
preferin la intervale de timp ct mai mici, de la cteva
sptmni la cteva luni.
4. Clienii i dezvoltatorii trebuie s colaboreze zilnic pe
parcursul proiectului.
Cele 12 principii ale manifestului agil
http://agilemanifesto.org/iso/ro/principles.html

5. Construiete proiecte n jurul oamenilor motivai. Ofer-le


mediul propice i suportul necesar i ai ncredere c
obiectivele vor fi atinse.
6. Cea mai eficient metod de a transmite informaii nspre i
n interiorul echipei de dezvoltare este comunicarea direct,
fa n fa.
7. Software funcional este principala msur a progresului.
8. Procesele agile promoveaz dezvoltarea durabil.
Sponsorii, dezvoltatorii i utilizatorii trebuie s poat
menine un ritm constant pe termen nedefinit.
Cele 12 principii ale manifestului agil
http://agilemanifesto.org/iso/ro/principles.html

9. Atenia continu pentru excelen tehnic i design bun


mbuntete agilitatea.
10. Simplitatea arta de a maximiza cantitatea de munc
nerealizat este esenial.
11. Cele mai bune arhitecturi, cerine i design se obin de
ctre echipe care se auto-organizeaz.
12. La intervale regulate, echipa reflecteaz la cum s devin
mai eficient, apoi i adapteaz i ajusteaz
comportamentul.
Aplicabilitatea metodelor agile

n n companiile care dezvolt produse software de


dimensiuni mici sau mijlocii.
n n cadrul companiilor unde se dezvolt software pentru uz
intern (proprietary software), deoarece exist un
angajament clar din partea clientului (intern) de a se implica
n procesul de dezvoltare i deoarece nu exist o mulime de
reguli i reglementri externe care afecteaz software-ul.
n datorit orientrii lor pe echipe mici i bine integrate, exist
probleme n scalarea metodelor agile pentru sistemele mari
(dei i n acest caz se pot realiza anumite componente ale
sistemului n mod agil).
Posibile probleme cu metodologiile agile

n dificultatea de a pstra interesul clienilor implicai n acest


procesul de dezvoltare pentru perioade lungi
n membrii echipei nu sunt ntotdeauna potrivii pentru
implicarea intens care caracterizeaz metodele agile
n prioritizarea modificrilor poate fi dificil atunci cnd exist
mai multe pri interesate
n meninerea simplitii nu e ceva simplu :-)
n contractele pot fi o problem ca i n alte metode de
dezvoltare incremental
Metodologii agile

Exemple de metodologii agile:


n Extreme Programming (XP) - 1996
n Adaptive Software Development (ASD)
n Test-Driven Development (TDD)
n Feature Driven Development (FDD)
n Behavior Driven Developement (BDD)
n Crystal Clear
n Scrum - 1995
n etc.
Programare extrem

de la spottedpaint.com
Programare extrema (XP)

n poate cea mai cunoscut metod agil.


n Extreme Programming (XP) are o abordare "extrem" de
dezvoltare incremental:
noile versiuni pot fi construite de mai multe ori pe zi;
acestea sunt livrate clienilor la fiecare 2 sptmni;
toate testele trebuie s fie executate pentru fiecare
versiune i o versiune e livrabil doar n cazul n care
testele au rulat cu succes.
Informaii: http://www.extremeprogramming.org
XP i principiile agile

n dezvoltarea incremental este susinut prin intermediul


livrrii de software n mod frecvent cu mici incremente.
n implicarea clientului nseamn angajamentul full-time al
clientului cu echipa de dezvoltare.
n oameni, nu procese prin programare n doi (pereche de
programatori), proprietatea colectiv i un proces care s
evite orele lungi de lucru.
n receptivitate la schimbare prin livrri frecvente.
n meninerea simplitii prin refactoring constant de cod.
Valorile XP

n Simplitate (Simplicity)
n Comunicare (Communication)
n Reacie (Feedback)
n Curaj (Courage)
n Respect (Respect)
Practici XP

n procesul de planificare (The Planning Game)


n client disponibil pe tot parcursul proiectului (On-Site Customer)
n implementare treptat (Small Releases)
n limbaj comun (Metaphor)
n integrare continu (Continuous Integration)
n proiectare simpl (Simple Design)
n testare (Testing)
n rescriere de cod pentru mbuntire (Refactoring)
n programare n pereche (Pair Programming)
n drepturi colective (Collective Ownership)
n 40 ore/sptmn (40-Hour Week)
n standarde de scriere a codului (Coding Standard)
Planificare

n Joc de planificare a livrrilor: clieni i


dezvoltatori.
n Joc de planificare a iteraiilor: doar
dezvoltatorii
n Clientul nelege domeniul de aplicare,
prioritile, nevoile business ale versiunilor
care trebuie livrate:
sorteaz cartonaele cu sarcini dup
prioriti
n Dezvoltatorii estimeaz riscurile i eforturile:
sorteaz cartonaele dup risc
dac o sarcin ia mai mult de 2-4 sptmni,
e distribuit pe mai multe cartonae
Livrri frecvente

n livrri ct de des este posibil, cu condiia s existe o plus-valoare


pentru client
n acest lucru asigur feedback-ul rapid
n clientul are funcionalitatea esenial ct mai curnd posibil
n timp ntre livrri de la o sptmn pn la o lun
(proiectele non-XP au termene de jumtate de an sau mai mult)
Metafora

n metafora este de fapt cuvntul-cheie XP pentru ceea ce ali


ingineri numesc arhitectura sistemului
n se evit cuvntul arhitectur pentru a sublinia faptul c nu avem
de-a face doar cu structura general a sistemului
n metafora sugereaz o coeren general, uor de comunicat,
plus mai mult maleabilitate
Integrare continu

n codul este integrat i testat n cel mult cteva ore sau o zi de


cnd este scris.
n de exemplu, atunci cnd dezvoltatorii au terminat o parte din
implementare:
o integreaz cu codul existent
ruleaz teste i corecteaz eventualele probleme
dac toate testele sunt pozitive, adaug modificrile n
sistemul care se ocup cu managementul codului surs.
Proiectare simpl

n principiul de baz: proiectez cel mai simplu lucru care


funcioneaz acum. Nu proiecta i pentru mine, pentru c
s-ar putea s nu fie nevoie

n deci, proiecteaz doar pentru a satisface cerinele i nimic


n plus
Testare

n se testeaz tot ceea ce ar putea fi problematic.


n programatorii scriu teste unitare folosind un cadru de testare
automatizat (de exemplu, JUnit) pentru a minimiza efortul de
scriere i verificare a testelor.
n clienii, cu ajutorul dezvoltatorilor, scriu teste funcionale.
n de multe ori, se aplic metoda test-driven development:
se scriu teste naintea codului pentru a clarifica cerinele.
testele sunt scrise ca programe n loc de date, astfel nct
acestea s poat fi executate automat.
fiecare test include o condiie de corectitudine.
toate testele anterioare i cele noi sunt rulate automat atunci
cnd sunt adugate noi funcionaliti, verificnd astfel c noua
funcionalitate nu a introdus erori.
mbuntirea codului

n mbuntirea codului prin refactoring este foarte important


deoarece XP recomand nceperea implementarii foarte repede.

n simplificarea codului duce la o mai bun nelegere a lui, astfel


compensnd lipsa documentaiei n anumite situaii.

n exemplu (three strikes and you refactor) eliminarea duplicrii:


daca o bucat de cod similar apare n trei locuri, se scrie codul
respectiv ntr-o metod care e folosit n cele trei locuri.
Programarea n echipe de doi

n tot codul este scris de dou persoane folosind un singur


calculator

n sunt dou roluri n aceast echip:


unul scrie cod i
cellalt l ajut gndindu-se la diverse posibiliti de
mbuntire:
merge abordarea curent?
care sunt testele care s-ar putea s nu funcioneze?
exist simplificri posibile?
Avantajele programrii n doi

n susine ideea de proprietate i responsabilitate n echip pentru


sistemul colectiv

n proces de revizuire mbuntit, deoarece fiecare linie de cod


este privit de cel puin dou persoane (four eyes principle)

n ajut la mbuntirea codului

n transfer de cunotine i training implicit (important cnd membrii


echipei se schimb)

n more fun?
Pair programming n practic
Drepturi colective asupra codului

n nu exist situaia n care cineva are anumite module pe care


nimeni altcineva nu le poate atinge.

n dac cineva vede o modalitate de a mbunti ceva, va face


toate modificrile necesare n sistem (desigur e nevoie de un
sistem bun de versionare i management al codului).
40 de ore pe sptamn

n sptmna de lucru de maxim 40 de ore

n oamenii au nevoie de odihna necesar pentru a munci eficient


i a produce cod de calitate nalt

n exist sptmni cnd e necesar s se lucreze mai mult, dar


aceasta trebuie s fie o excepie
Codul scris n mod standardizat

n ntreaga echip ader la un set unic de convenii cu privire la


modul n care codul este scris

n scopul este de facilita programarea n doi i proprietatea


colectiv a codului
Ciclul de dezvoltare XP
Planificare i iteraii XP
Lucrul cu codul n XP
Avantaje XP

n soluie bun pentru proiecte mici

n programare organizat

n reducerea numrului de greeli

n clientul are control (de fapt, toat lumea are control, pentru
c toi sunt implicai n mod direct)

n dispoziie la schimbare chiar n cursul dezvoltrii


Dezavantaje XP

n nu este scalabil
n necesit mai multe resurse umane pe linie de cod (datorit
d.ex. programrii n doi)
n implicarea clientului n dezvoltare (costuri suplimentare i
schimbri prea multe)
n lipsa documentelor oficiale
n necesit experien n domeniu (senior level developers)
n poate deveni uneori o metod ineficient (rescriere masiv
de cod)
SCRUM
Metoda Scrum

Scrum este o metod agil, care se axeaz mai mult pe


managementul dezvoltrii incrementale, dect pe practici
agile specifice.
sprint
zilnic
backlog-ul
produsului

sprint
(2-4 spt.)
backlog-ul
sprintului

de
la
so
fth
ou
se
edu
ca
tion
versiune
.co
m incremental
Scrum pe scurt

n un proprietar de produs creeaz


o list de sarcini numit backlog.
n dup aceasta, se planific care dintre sarcini vor fi
implementate n urmtoarea iteraie, numit sprint.
n aceast list de sarcini se numete sprint backlog.
n sarcinile sunt rezolvate n decursul unui sprint care are
rezervat o perioad relativ scurt de 2-4 sptmni.
n echipa se ntrunete zilnic pentru a discuta progresul (daily
scrum). Ceremoniile sunt conduse de un scrum master.
n la sfritului sprintului, rezultatul ar trebui s fie livrabil (adic
folosit de client sau vandabil).
n dup o analiz a sprintului, se reitereaz.
Scrum n practic

Learning Scrum
Roluri n SCRUM

n product owner (proprietar de produs) - definete backlogul


n scrum master - are grij de ntreg procesul
pigs
n membrii echipei
n utilizatori & stakeholders & manageri chickens
Daily (deadly?) Scrum
Tool-uri pentru metode agile i Scrum

Exist foarte multe tool-uri pentru metodele i practicile agile.

Cteva exemple:
http://pivotaltracker.com
http://agilescout.com/best-agile-scrum-tools/
https://www.scrumwise.com/scrum/#
http://www.acunote.com/how-it-works
etc.
Cteva exemple

Tehnicile agile sunt folosite n foarte multe companii, dei multe


dintre ele nu folosesc explicit termenul de agile.
Cteva referine:
n Google: http://georgekontopidis.com/blog/2011/googles-agile-practices/
n Facebook: http://www.facebook.com/note.php?note_id=409881258919
n SAP: http://scn.sap.com/community/agile-software-engineering
n Microsoft: http://stories.visualstudio.com/scaling-agile-across-the-enterprise/
n IBM: http://www.ibm.com/software/rational/agile/
O comparaie de final

Metode agile Metode cascad Metode formale

criticalitate sczut criticalitate ridicat criticalitate extrem

dezvoltatori seniori dezvoltatori juniori dezvoltatori seniori

cerine n schimbare cerine relativ fixe cerine limitate

echipe mici echipe mari echipe mici

cultur orientat cultur orientat cultur orientat spre


spre schimbare spre ordine calitate i precizie