Ciclu de viata 3

RATIONAL
UNIFIED
PROCESS
 Rational Unified Process
• Produs comercial ( Rational Corporation) -> sustinut de
IBM (2003) - > model incremental
• Se ofera un “framework” suport, tool-uri, template-uri
(costuri ):
– “RequisitePro templates” (urmarire a cerintelor)
– “Word Templates” pentru “Use Cases”
– “Project Templates”pentru MP
• Orientat pe obiecte
• Dezvoltare interactiva
• Management al specificatiilor
• Arhitectura bazata pe componente
• UML (Unified Modeling Language) modelare vizuala
• Folosit pentru sisteme complexe
 Rational Unified Process
• Etape de dezvoltare:
– Inception Phase
– Elaboration Phase
– Construction Phase
– Transition Phase
• Bazat pe procese descrise de:
– Actori, ‘cine?’
– Activitati, ‘cum?’
– Artefacte, ‘ce?’
– Flux, ‘cand?’
 Rational Unified Process
• Fluxuri de activitati de baza:
– Modelarea proceselor de afaceri
– Cerinte
– Analiza si design
– Implementare
– Testare
– Implementare
• Fluxuri de activitati suport:
– Management de proiect
– Management al configuratiilor si schimbarii
– Mediu
 Inception Phase

• Se stabileste obiectivul principal

• Se identifica cerintele initiale
• Analiza cost – profit
• Analiza de risc
• Definire scop proiect
• Definire arhitecturi posibile si selectare varinata
• Dezvoltare “Prototip de test”
• Scenariu initial (incomplet) “Use Case Model”
 Elaboration Phase
• Analiza cerintelor
– Analiza Use Case
• Use Case (80% realizata )
• Model Use Case (80% realizat) -> UML
• Scenarii
– Diagrame de secventa si colaborare
– Diagrame de clase, activitati, stare …..
– Model domenial (Domain model)
– Plan de risc refacut
– Documentatie arhitectura
Martin Fowler
Domain model:
An object model of the domain that incorporates both behavior and data.
 Construction Phase
• Implementare si design detaliat
– Se adauga treptat functionalitati
– Stabilitatea aplicatiei creste cu fiecare pas
– Se implementeaza toate detaliile
– Se continua analiza cerintelor
 Transition Phase
• Transferul sistemului catre utilizator
– fabricare,
– expeditie,
– instalare,
– training,
– suport tehnic
– mentenanta
• Echipa de mantenanta ia locul echipei de dezvoltare
• Alpha, Beta, produs final, Updates
• Integrarea cu sisteme existente (legacy systems)
INTERNATIONAL
STANDARD
ISO/IEC 12207
SOFTWARE LIFE
CYCLE
PROCESSES
 ISO/IEC 12207
• Standard international pentru ingineria de software
– defineste procesul, activitatea si task-urile asociate cu un
anumit ciclu de viata, de la crearea sa pana cand
inceteaza sa mai fie folosit.
• Obiectivele principale
– structura comuna pentru cumparatori, furnizori,
dezvoltatori, personal de intretinere, operatori, manageri
si tehnicieni implicati
– limbaj comun.
• Standard ce defineste toate sarcinile necesare
dezvoltarii si intretinerii software-ului.
 Ce reprezinta?
• Standard pentru:
– procesele din ciclul de viata al software-ului.
– realizarea unui cadrul comun pentru a vorbi
aceeasi limba in cadrul disciplinei software.
• Un acord international asupra caror activitati
intra in proiectarea unui software.
• Procesele din ciclul de viata al software-ului:
– Arhitectura de nivel inalt a proceselor
– Activitati si sarcini
– Modelate pentru orice organizatie sau proiect
– Un ‘inventar’ de procese din care se poate alege
 Si ce nu reprezinta...
• NU este un standard al produsului
– Nu masoara calitatea produsului
• NU are caracter prescriptiv
– Nu specifica cum trebuie facute lucrurile
• NU este un standard de metoda
– Nu se adreseaza unui anumit ciclu de viata sau
unor instrumente
 ISO/IEC 12207
Procese
primare Procese de suport ale
ciclului de viata
•Achizitie •Auditul
•Resurse •Organizare /Configurare Procese
•Dezvoltare organizationale
•Referinte
•Operare •Documentare
•Intretinere Management
•Garantia calitatii
Infrastructura
•Solutionarea problemelor
Imbunatatire
•Verificare
Instruire
•Validare
 ISO 12207
• Standardul ISO 12207 stabileste procesele din
cadrul ciclului de viata
– Fiecarui proces i se asociaza un set de rezultate.
– exista
• 23 de Procese,
• 95 de Activitati,
• 325 de Task-uri
• 224 de Rezulate
 ISO 12207
Arhitectura Proceselor
• Scopul
– Obiective de nivel inalt in
realizarea procesului si finalitatile
probabile ale implementarii
efective a procesului.
• Procesul
• Rezultate
– Un set de activitati inrudite, care
– Un rezultat al indeplinirii cu succes
transforma intrarile in iesiri
al scopului procesului.
– 25 de procese (18 + 7 noi)
– 224 de frezultate
• Activitate
– Set detaliat de task-uri
– 95 de activitati
• Task
– Atiune ce cuprinde intrare/iesire
– 325 de sarcini
Procesele din ciclul de viata
al unui software

PROCESE PRIMARE
PROCESE SUPORT

PROCESE ORGANIZATIONALE
 Procesele din ciclul de viata
al unui software
PROCESE PRIMARE
Achizitie Dezvoltare
Pregatirea achizitiei Analiza si designul sistemului
Selectia furnizorilor
Gestiunea furnizorilor Analiza cerintelor software
Preluare in gestiune (acceptare) Designul software
Implementare software
Resurse Integrare software
Testare software
Detalierea cerintelor Integrarea si testarea sistemului

Operare
Operarea sistemului
Suport client Intretinere
 Procesele din ciclul de viata
al unui software
PROCESE DE SUPORT

Documentatie

Managementul configuratiei

Asigurarea calitatii
Verificare
Validare
Review
Audit

Rezolvarea problemelor
 Procesele din ciclul de viata
al unui software
PROCESE DE ORGANIZARE

Management Managementul calitatii

Management de proiect Managementul riscului

Imbunatatiri Monitorizare Alinierea organizationala

Stabilirea proceselor
Evaluarea proceselor Infrastructura
Imbunatatirea proceselor Managementul resurselor umane
Reutilizare
 Perspectiva ISO/IEC 12207
Proces
Proces
Proiect Instalare
Acceptanta si suport

Analiza de cerinte
Arhitectura
Sistem Integrare
Testare

Cerinte Testare

Arhitectura Integrare
Software
Arhitectura Programare
detaliata si testare
 Implementarea procesului
• Defineste sau selecteaza un model de ciclu de
viata software
• Selecteaza, ajusteaza, si utilizeaza standarde,
metode, instrumnete si limbaje de programare
• Dezvolta planuri pentru desfasurarea activitatilor
din cadrul procesului de dezvoltare.
• Sub-Procese (ex)
– Implementarea procesului
– Explicitarea cerintelor
– Analiza cerintelor sistemului
 Explicitarea cerintelor
• Scop:
– Sa identifice si sa urmareasca nevoile si cerintele dinamice ale
clientului de-a lungul vietii produsului si/sau serviciului
– Explicitarea cerintelor poate fi facuta de catre beneficiarul sau de catre
dezvoltatorul sistemului.
• Sarcini:
– Identificarea cerintelor clientului
– Reevaluare pentru a intelege nevoile clientului
– Acordul asupra cerintelor
– Stabilirea cerintelor de baza ale clientului
– Gestiunea modificarilor in cerintele clientului
• Finalitati:
– Cerintele clientului;
– Schimbarea registrelor de cerinte.
 Analiza cerintelor sistemului
• Scop:
– Sa transforme cerintele definite intr-un set de norme tehnice de dorit
care vor ghida designul sistemului.
• Sarcini:
– Analiza cerintelor sistemului
– Verificarea cerintelor sistemului
– Normarea si comunicarea cerintelor sistemului
• Finalitati:
– Cerintele sistemului; cerinte de interfata
– Registrul de urmarire
– Raportul de verificare
SCRUM
 SCRUM
• Scrum
– Reprezintă o metoda
incrementala de dezvoltare de
produse din categoria
metodelor agile
– SCRUM termen preluat din
rugby © PierreSelim / Wikimedia Commons / CC-BY-SA-3.0

– Bazele metodei scrum au fost puse de cercetătorii Takeuchi

and Nonaka in 1986
– A fost folosita prima data in 1993 de Jeff Sutherland la Easel
Corporation si fundamentata in de Ken Schwaber in 1997
– a devenit populara in anii 2000 ca o metoda alternativa de
management a proiectelor software
 SCRUM
– 2001 “Agile Software Development with Scrum”
Ken Schwaber & Mike Beedle
– se abate de la metodologia conventionala a
managemnetului de proiect
• nu exista o strucutra WBS (Work Breakdown Structure),
• deciziile de planificare au fost complet descentralizate
– rezultat al evolutiei mai degraba decat a unui
model deliberat pe o baza teoretica noua.
– avantaje in productivitate, durata si satisfactia
clientului.
 Principii SCRUM
• Ciclul de viata al dezvoltatii software
– Colectarea si analiza cerintelor
– Design/Proiectare
– Implementare
– Testare
– Livrare
• Rezultatul unei etape devine punct de pornire
pentru etapa urmatoare
– Fiecare etapa produce un rezultat previzibil si bine definit
– Aplicarea procesului rezulta in obtinerea de iesiri
repetabile
 Principii SCRUM
• Control empiric a procesului:
– pregatire pentru neprevazut
– control prin inspectii frecvente si adaptari
– procese imperfect definite care genereaza rezultate
imprevizibile si irepetabile
• Adaptarea
– Procesul in cadrul caruia s-au detectat probleme se va
modifica astfel incat sa se limiteze sau sa rezolve
problemele
– Rezultatul care prezinta probleme de calitate (cerinte,
performante …) va fi remediat cu prioritate
 Principii SCRUM
• Transparenţa
– Procesul si artefactele trebuie sa fie accesibile
conform necesitatilor
– Libaj comun pentru a putea comunica
• Inspecţia
– Monitorizare cu caracter regulat al artefactelor
– Monitorizare cu caracter regulat al progresul
– Analiza variaţiilor.
– Nu trebuie pus accent pe monitorizare. Accentul
este pus pe executie
 Cadrul Scrum
Roluri :
Proprietarul produsului,
ScrumMaster,
Echipa

Ceremonii:
Artefacte :
Planificarea Sprint,
Backlog produs,
Sprint Review,
Sprint Backlog,
Retrospectiva Sprint
Burndown Chart
Reuniuni zilnice
 Proprietarul produsului,
Roluri Scrum Master,
Echipa
 Roluri Scrum
Scrum Master
– Responsabil de implementarea Scrum
• Intelegere, adoptie, relatii
– “servant-leader”
– Interfata intre management si echipa Scrum
– Responsabil cu indepartarea impedimentelor ce
determina stagnarea progresului echipei Scrum
– Trebuie sa ia decizii rapide bazate pe date
incomplete
• De obicei un inginer cu experienta
 Roluri Scrum
Product Owner (Proprietarul produsului)
– responsabil de produs
– Coordoneaza Echipa de Dezvoltare din perspectiva
realizarii produsului
– Singurul detinator al ”Product Backlog”
• Modificarile la portofoliul trebuie sa fie aprobate de proprietarul
produsului
• Responsabil de conținutul și prioritatea cerintelor din Product
Backlog
– Are un rol apropiat de al unui lider tehnic sau manager de
proiect
 Roluri Scrum
Echipa Scrum
• Toate competențele necesare realizarii produsului:
– Membrii de baza: Designeri, Testeri, Programator …
– Marime recomandata 5 – 10 persoane
– Extinsa: QA, Programatori, Designeri UI , etc.
• Membrii trebuie implicatii full-time
– Pot exista exceptii (ex. System Admin, etc.)
• Echipele se auto-organizeaza
– Nu se accepta divizarea – organizarea in grupuri
– In mod ideal – fara titluri …. In realitate posibil
– Responsabilitatea este a intregii echipe nu doar a unui membru
• Calitatea de membru se poate modifica numai intre sprinturi
 Sprint
• Interval de timp asociat dezvoltării unui set de
funcționalități
• Durează, de obicei intre 14 si 30 zile
• Funcționalitățile cu prioritățile cele mai mari
din Product Backlog sunt implementate sub
denumirea de Sprint Backlog
• Estimările Sprint sunt actualizate odată ce
sunt finalizate sarcinile sau când apar altele
noi
 Sprint
• Un sprint presupune dezvoltarea continua a
produsului cu potențial de transfer la finalul
ciclului
• Nici o influenta exterioara NU poate interfera
cu echipa Scrum in timpul Sprint-ului
• Fiecare Sprint incepe cu Sedinta Zilnica de
Scrum
 Nici o schimbare in cadrul
sprint

SCHIMBARE

Intrari Sprint Testare cod

Planifica durata sprint in functie de cat de

mult poti evita modificarea acestuia
 SCRUM
Daily
SCRUM

Story Sprint Review

Time Planning Meeting
session Meeting

Analysis, Design,
Evolution, Testing
Sprint Backlog

Standards
Architecture Technology
Design
 Planificarea Sprint,
Sprint Review,
CEREMONII Retrospectiva Sprint
Reuniuni zilnice
 Ceremonii

Sprint Sprint Sprint

Planning Review retrospective

Daily
Scrum
 Ceremonii

Sedinta de planificare Sprint

– Crearea “Sprint backlog” pe baza “Product
Backlog”
– Durata: maxim 8 ore (sprint 1 luna)
– Participanti:
• Proprietarul produsului, Scrum Master, Echipa Scrum
• Discutii:
– Ce se va face in acest Sprint ?
– Cum se va face ?
– Obiectiv sprint
 Ceremonii
• Pre-Proiect/Kickoff Meeting
• O forma speciala a Sedintei de planificare a
Sprint
• Sedinta inaintea demararii proiectului
 Ceremonii
Sedinta zilnica Scrum (Daily Scrum)
– Durează intre 5 - 15 minute
– Care sunt realizările de la ultima reuniune?
• Ce ați făcut ieri?
– Care sunt impedimentele pentru activitățile
următoare?
• Ce obstacole aveți de depășit?
– Ce se va realiza pana la următoarea ședința?
• Ce veti face azi?
– Toți participa, numai cei avizați își spun părerea
 Ceremonii
Sedinta zilnica Scrum (Daily Scrum)
– NU este o etapa de rezolvare a problemelor
– NU este o cale de a aduna informatii despre CINE
dezvolta programul
– Este o sedinta in care membrii echipei isi iau
angajemente unul fata de calalalt si fata de Scrum
Master
– Este o metoda buna pentru ca Scrum Master sa
poata sa urmareasca progresul echipei.
 Ceremonii
Sedinta zilnica Scrum (Daily Scrum)
• De ce zilnic?
– “Cum reusim sa intarziem un proiect un an intreg?”
• “Fiecare la timpul sau.”
– Fred Brooks, The Mythical Man-Month.
• Putem sa inlocuim sedintele Scrum cu raporturi de
etapa prin e-mail?
– Nu
• Toata echipa intrevede zilnic imaginea de ansamblu
• Intri in competitie cu colegii sa faci ceea ce iti propui
 Ceremonii
Sedinta de Evaluare Sprint – Sprint review

• Echipa prezinta realizarile Sprint-ului

• Ia de regula forma unei demonstratii a unor
functionalitati noi sau arhitecturi detaliate

Doua componente:

Informala Formala
Pregatire a intalnirii formale Participanti: Clienti, Management
Proprietarul produsului, Alti invitati
 Ceremonii
Sedinta de Evaluare Sprint – Sprint review
• Scop:
– analiza incrementul
– Actualizarea Product Backlog-ul (dacă este necesar).
• Echipa Scrum şi cei implicați discuta ceea ce s-a realizat în
Sprint.
• Participanţii discuta acțiunile următoare
• Aceasta este o întâlnire informală
• Prezentarea rezultatului
– feedback
– încurajează colaborarea.
• Durata:
– 4 ore pentru Sprint-urile de o lună.
– Mai putin de 4 ore pentru sprinturi mai scurte
• Scrum Master-ul este facilitatorul evenimentui.
 Ceremonii
Adaptat: The Scrum Guid; The Definitive Guide to Scrum: The Rules of the
Game, Ken Schwaber and Jeff Sutherland

Sedinta de Evaluare Sprint – Sprint review

• Cuprinde:
– Product Owner-ul explică care elemente din Product Backlog au fost
"Finalizate" și care nu au fost "Finalizate";
– Echipa de Dezvoltare discută despre ceea ce a mers bine în timpul
Sprint-ului, problemele de care s-a lovit și modul în care acele probleme
au fost soluționate;
– Echipa de Dezvoltare demonstrează lucrările care au fost "Finalizate" şi
răspunde la întrebări cu privire la Increment;
– Product Owner-ul discută Product Backlog-ul așa cum se prezintă la
momentul respectiv. Preconizează datele posibile de finalizare bazate pe
progresele înregistrate până în present
– Întregul grup discuta ceea ce urmează să facă în continuare,
– Se discuta despre valoarea adaugata a produsului,
– Se discuta organizarea în timp, bug
 Ceremonii
Sedinta retrospective Sprint– Sprint Retrospective
• Numai echipa Scrum
• Sedinta cu scop de Feedback
• Trei intrebari:
– Start
– Stop
– Continua
• A nu se sari peste ea cel putin la primele 4-5 sprinturi
– Dureaza aproximativ 3 ore
– Ofera feedback la management
– Ofera feedback pentru urmatorul Sprint
 Ceremonii
Sedinta retrospective Sprint– Sprint Retrospective
• Scop:
– auto-analiza
– Analiza a sprint-ului: oameni, relații, proces, şi
instrument
– ientificare îmbunătăţiri
– un plan pentru îmbunătăţiri care urmează să fie
adoptate în cadrul Sprint-ului următor.
• Are loc după Sprint Review şi înainte de
Planificarea Sprint-ului următor (Sprint Planning).
• Scrum Master-ul este facilitator-ul evenimentului
 • O lista de funcționalități , pe
care le va îndeplini
produsul, ordonata dupa
prioritatea asociata.
• Face referire la:
– Caracteristici noi
– Îmbunătățiri ale
caracteristicilor deja existente
Product Backlog – Prototipuri
– Documentație
– Eliminarea bug-urilor
– Training
• Nu se finalizeaza – ramane
deschis pe parcursulu
proiectului
– Product Owner-ul gestioneaza
modificarile
 Product Backlog

The Product Backlog is an ordered list of

everything that might be needed in the product
and is the single source of requirements for any
changes to be made to the product.
K Schwaber & J Sutherland, The Scrum Guide, 2011.
 Portofoliu(Backlog)
Studiu de caz Exemplu cerinta:
Ca un [rolul utilizatorului final],
eu vreau [dorinta] asa incat
[rationamentul]
 Product Backlog
Studiu de caz
 Product Backlog
• Afirmarea simpla a ceea ce se cere:
“Ca si
<tipul utilizatorului> STORY
dorec sa
<indeplinirea unei actiuni>
astfel incat sa pot
<atingerea unui rezultat>.
Exemplu:
“Ca si manager al Serviciului Clienți, doresc sa cunosc durata
medie de așteptare astfel încât sa pot asigura personalul necesar
la centrul de preluare a apelurilor.
 • Permit proprietarului
produsului sa creeze cerințe
independente de modul de
implementare;
• Permite scrierea cerințelor din
punctul de vedere al
diferitelor tipuri de utilizatori
• Permite utilizatorilor si echipei
Product Backlog SCRUM sa vorbească nu atât
despre sistem in sine, cat
despre cum il vor utiliza
• Reprezintă o “promisiune a
unei viitoare conversații”
• Pot fi scrise atât de persoane
din domeniul tehnic cat si de
persoane din afara acestui
domeniu de activitate
 Product Backlog
INVEST
I– N– V–
independent negociabil valorificabil

E – estimabil S – simplu T – testabil

Relatari utile de la utilizatori in jurul cuvantului

“ce, nu “cum”
 Product Backlog
DEEP
Detailed
Estimated
Appropriately

Emergent Prioritized
 Product Backlog
Sprint Backlog
Product Backlog
Extragere
sprint backlog

Poate contine:
1.Features
2.Bugs
3.Technical work
4.Knowledge acquisition

Prioritate

Introduce
cerinta
noua
 Product Backlog
Sprint Backlog

Task 1.1
Sprint
Backlog 1
Product Task 1.2
Backlog
Sprint
Task 2.1
Backlog 2
 Product Backlog
• Proprietarul produsului colaboreaza cu grupul
tinta pentru a defini si a scrie relatarile
utilizatorilor:
– Intalniri individuale
• Echipa detinatorului produsului, compusa din experti in
cerinte precum si analisti economici
• Echipa Scrum
• “Story Time session”
• Oricine poate adauga elemente in “Product
Backlog”, dar numai proprietarul (Product
Owner) poate stabili prioritatea finala.
 “Story Time session”
• Scopul unei sesiuni de relatare (“Story Time
session” ) este de a o imbunatati “Porduct
Backlog”
• Aceste sesiuni pot servi la:
– scrierea povestilor utilizatorilor -> functionalitati
– Imbunatatirea relatarilor de la utilizatori
– Fragmentarea relatarilor / Lungimea relatarilor
– Adaugarea criteriilor de acceptare a unei relatari
• Planificarea urmatorului sprint
 Criterii de acceptanta
• Stabilirea “limitelor” povestii
– ce este/nu este vizat
• Sunt negociabile
• Ajuta sa identificam cand o relatare e completa
• Provin din dialogul intre echipa si proprietarul
produsului in cadrul sedintelor de relatare si de
planificare
• Necesita abilitatea de pune intrebari pertinente
 Tehnici de Estimare
“Product Backlog”
• Diverse metode de estimare a duratei unei
povesti (story):
– Valoare absoluta (ore)
– Valoare relativa (complexitate)
• Estimarile sunt converite in “story points”,
– “story points” = estimare cantitativa specifica
fiecarei echipe
• Viteza echipei = media “story points” asociata
povestilor finalizate de o echipa
 Estimare absoluta vs relativa
• Estimati lungimea in (m): Estimare
– Furnica, Boeing 747, Basculanta, absoluta
Pod Cernavoda, Miriapod
• Aranjati dupa lungime, in ordine
crescatoare: Estimare
– Furnica, Boeing 747, Basculanta, relativa
Pod Cernavoda, Miriapod

Definire miriapod:
“expert knowledge”
 Tehnici de Estimare
“Product Backlog”
• Tehnici de estimare a duratei:
– Ore (foarte rar)
– “Planning Poker”
• Fiecare membru al echipei primeste un set de carti
• Se estimeaza prin ridicarea cartii alese
• Se finalizeaza cand membrii echipei sunt de acord
– Zile ideale ( “Ideal days”)
– “T-shirt sizes”
• Se asociaza dimensiuni (XS, S, M, L, XL, XXXL )
 Exemplu
Planning Poker
 Tehnici de Estimare
“Product Backlog”
• Tehnici de estimare a duratei (cont):
– Sirul Fibonacci
• ( 1,2,3,5,8,13,21…)
• Se interpreteaza ca factor de complexitate
– Gruparea - “Affinity Mapping”
• Se stabilesc grupe de complexitate
• Cerintele se grupeaza in functie de complexitate
– Ordonarea
• Se stabileste o scara de masura (exemplu low -> high)
• Se aseaza cerintele in ordine prin mutari succesive
 Tehnici de Estimare
“Product Backlog”
• Tehnici de estimare a duratei (cont):
– Bucket System
• Se stabileste o scara (de obicei nu liniara)
• Stabilirea unei referinte: pentru primele cateva cerinte
se citeste cerinta cu cerinta si echipa stabileste un
punctaj conform scalei
• Dividem et imperat: Fiecare membru al echipei alege
cerinte din lista de cerinte si le plaseaza conform scarii
alese
• Se verifica rezultatul
 Remaining Effort in Hours

5/
3/
2

100
200
300
400
500
600
700
800
900

0
5/ 00
5/ 2
2
5/ 002
7/
2
5/ 00
9/ 2 752
5/ 200
11 2
/
5/ 20
762

13 02
/
5/ 200
664

15 2
/
5/ 200
17 2
/
5/ 20
Progress

619

19 02
/
5/ 200

Date
21 2
/
304

5/ 20
23 02
/
5/ 200
25 2
/
5/ 20
264

27 02
Sprint Burndown Chart

/
5/ 200
180

29 2
/
5/ 20
31 02
/2
00
2
104
20
 Release Burndown Chart
• Predarea se va face la data stabilita?
– Axa X: sprinturi
– Axa Y: numarul de ore ramase
• Efortul ramas poate fi luat in calcul
• Product Burndown Chart
– Este o privire de ansamblu asupra progresului
proiectului
 De ce Functioneaza?
• Cele mai multe ipoteze ale modelului definit
sunt eliminate
• Ofera feedback constant

“Ceea ce se “De ce nu poate fi

poate face” facut”
 “Business value”
Valoarea comerciala asociata dezvoltarii unui
proiect:
• ROI (“Return on Investment”)
• Reducere de cost
• Reducere de efort
• Oportunitate de crestere
• Primul pe piata (“First-to-market”)
• Cost de oportunitate
• Cost renuntarii la proiect
 • Pune accent pe munca in
echipa
– Echipa se dezvolta si
contribuie pe parcursul
porcesului
– Echipa devine autonoma si
se straduieste pentru
excelenta
Avantaje SCRUM • In functie de etapa, rotatia
1 intre lideri ofera o natura
distribuita de executie a
proiectului
• Echipa de management poate
urmarii de aproape progresul
echipei si poate intervenii
oricand e nevoie
• Companiile uneori invata
datorita obstacolelor create de
practici stabilite
 • Creeaza un mediu deschis de
munca si incurajeaza feedback-
ul
• Evaluarea efortului si
mijloacele de recompensare
sunt bazate pe performanta
echipei
Avantaje SCRUM • Reduce nevoia pentru sedinte,
2 autorizatii si rapoarte
• Model iterativ care duce la o
livrare la fiecare 30 de zile
• Poate actiona ca un invelis
pentru practici aflate deja in
desfasurare
 • Premisa de baza ca echipa este
dedicata proiectului.
– Daca echipa nu este dedicata
atunci procesul se prabuseste
• Nivelul de confort al
managementului in delegarea
de sarcini
• Impactul emotional datorat
Dezavantaje SCRUM esecului in cazul in care
proiectul nu se finalizeaza
• Marimea echipei este
restrictionata datorita
implicarii tuturor membrilor
echipei
• Potrivita pentru dezvoltarea de
noi produse
– nu pentru imbunatatirea unui
produs deja existent
• Bazat pe experienta
 TEST DRIVEN
DEVELOPMENT
 Test Driven Development
• “Test-driven Development is a programming
practice that instructs developers to write new
code only if an automated test has failed, and
to eliminate duplication. The goal of TDD is
clean code that works”
[Mansel&Husted: JUnit in Action]
 Test Driven Development
• “Test Driven Development is the craft of producing
automated tests for production code, and using that
process to drive design and programming

• For every bit of functionality, you first develop a test

that specifies and validates what the code will do.

• You then produce exactly as much code as necessary to

pass the test. Then you refactor (simplify and clarify)
both production code and test code”
[Agile Alliance]
http://www.agiledata.org/essays/tdd.html
 Test Driven Development
• Metoda de dezvoltare software TDD
– implica scrierea unor teste pentru verificarea
functionalitatilor componentelor aplicatiei.
– metoda des intalnita in companiile ce dezvolta
software.
– imbunatateste calitatea aplicatiei software.
• TDD impune creearea de metode de testare
inainte de construirea solutiei propriu zise.
• Se inspira din metodele Agile si din eXtreme
Programming (XP)
 Test Driven Development
STUDIU DE CAZ
TDD
=
Test first
+
Automated (Unit) Testing
RED
GREEN
REFACTOR
GREEN
Test Driven Development
 Test Driven Development
• TDD este o metoda in care se vor scrie intai
testele si apoi se va implememnta codul
propriuzis.
• Reprezinta o “intentie” de a realiza
• Testul va avea rol de specificatie a codului (Ce
face?)
• Testul este vazut ca o analiza a functionalitatii
sistemului
 Test Driven Development
• Refactorizare
– restructurare,
– simplificare,
– imbunatatire
• Refactorizarea este o metoda foarte buna
pentru a descompune codul.
 Test Driven Development
• Regression testing
– Codul nou si schimbarile facute pot afecta
functionarea aplicatiei
– “Affect” sometimes means “break”
– Regresie = revenire la o versiune precedenta
• Regression testing = testare a regresiei
codului
– Asigura stabilitatea aplicatiei
 Test Driven Development
STUDIU DE CAZ

• 1. Write a single test

• 2. Compile it. It shouldn’t compile because you’ve not
• written the implementation code
• 3. Implement just enough code to get the test to
compile
• 4. Run the test and see it fail
• 5. Implement just enough code to get the test to pass
• 6. Run the test and see it pass
• 7. Refactor for clarity and “once and only once”
• 8. Repeat Extreme Programming Explored (The Green Book),
Bill Wake
Test Driven Development
STUDIU DE CAZ
 Test Driven Development
Avantaje
• Eficienta
• Imbunatatirea rezultatelor testarii
• Reducerea aparitiei defectelor
• Programatorul se ocupa si de testare
• Disponibilitate la schimbare
KANBAN
• Rather than focusing on being Agile which
may (and should) lead to being successful,
Kanban focuses on becoming successful,
which may lead to being Agile.

Kanban for Software Engineering

David Joyce
 Kanban
• Kanban este un dispozitiv de semnalizare ( de regula un
card introdus intr-un plic transparent de plastic)
– contine intructiunile pentru mutarea sau crearea de parti
intr-un sistem de productie de tip “pull”
– inventat si dezvoltat ca parte a Toyota Production System
• Scopul Kanban este de a minimiza WIP
– WIP = Work-In-Process sau inventarul, intre procese
– procesul de constructie produce parti numai daca procesul
de consum are nevoie de ele.
• “Pull” inseamna ca lucratorii din linia de consum “trag”
partile de care au nevoie din procesele de asamblare.
 Kanban
• In limba japoneza:
– Kan inseamna “semnal”
– Ban inseamna “card” sau “tabla”
• Un card Kanban reprezinta un semnal ce
determina o actiune
• Kanban se refera la un “card de semnalizare”
– Kanban exista pretutindeni. Data viitoare cand vei
comanda o cafea la un fastfood, vei remarca
implementat un sistem Kanban
– Paharul de cafea inscriptionat reprezinta sistemul
Kanban!
 Kanban
• In timp ce aceasta este incorect din punct de vedere
tehnic, termenul de tabla Kanban a fost introdus in
vocabularul Agile si Software Development fiind deja
pus in uz.
• Kanban in productie reprezinta inspiratia din spatele
a ceea ce noi numim in prezent Kanban pentru
Ingineria Software.

INPUT Proces OUTPUT

Intrarea este determinata de iesire

https://norulesjustwords.files.wordpress.com/2012/04/from_push_to_pull.gif
 Principii
Principiile de baza Kanban pentru Ingineria Software (1):
• Vizualizați fluxul de lucru
– impărțiți în componente,
– scrieți descrierea fiecarei componente pe un card și puneți-l
pe tabla KANBAN
– Utilizați coloane pentru a crea un flux de lucru.
– La inceput se aloca si respecta rolurile si responsabilitatile
• Limitați WIP
– stabiliți limite explicite pentru câte elemente pot fi în
desfășurare
– Incepe cu ce stii sa faci
– Valoarea Pull (cu limita pentru WIP)
 Principii
Principiile de baza Kanban pentru Ingineria Software (2):
• Măsurați ciclul de dezvoltare
– timpul mediu pentru a finzliza o componenta,
– optimizați procesul pentru a reduce timpul.
– Proces de dezvoltare previzibil
• Cresterea eficientei
• Portofoliu Kanban fixat – KANBAN backlog
• Calitatea integrata in produs
– nu inspectata in produs
• Echipa monitorizeaza in mod continuu imbunatatirea
celor de mai sus
 Kanban - Desfasurare
• Vizualizarea mersului activitatii
– Imparte lucrul in bucati, scrie fiecare elemenet pe un card
si afiseaza-l pe perete
– Foloseste coloane pentru a ilustra unde se gaseste fiecare
element in cadrul fluxului activitatilor
• Limiteaza WIP (work in progress)
– atribuie limite explicite pentru cate elemente se pot
desfasura simultan pentru fiecare stare a activitatii.
• Masoara durata lead (durata medie pentru finalizarea
fiecarui element, denumita uneori “durata ciclului”)
• Optimizeaza procesul pentru a face acest inerval cat
mai mic si predictibil cu putinta.
 Kanban - Desfasurare
• Vizualizarea mersului activitatii – tabela Kanban
– Colane din tabela Kanban: Backlog - Requirements - Design -
Development - Testing - Acceptance - Deploy – Support
– Elemente asociate unei componente: “Creation Date - Deadline
- Created by - Priority -Task Type - Description -Notes -
Definition or Requirements for “Complete/Finished” - History”
• Limitele WIP pentru fiecare fază a procesului,
– Se scriu deasupra coloanelor din tabela Kanban
• Echipa ar trebui să analizeze regulat in cadrul unor intalniri
– Metricile utilizate: timp …,
– ce au realizat,
– modificările necesare procesului
• Metoda Kanban nu propune un program pentru aceste
întâlniri.
 Tabela Kanban
STUDIU DE CAZ

http://www.crisp.se/gratis-material-och-guider/kanban
Tabela Kanban STUDIU DE CAZ

Source: The Agileist

Tabela Kanban
Tabela Kanban
STUDIU DE CAZ
Tabela Kanban
STUDIU DE CAZ
Tabela Kanban
STUDIU DE CAZ
Tabela Kanban
STUDIU DE CAZ
Tabela Kanban
STUDIU DE CAZ
Tabela Kanban
STUDIU DE CAZ
 MMF
• “Minimal Marketable Feature (MMF)”
– reprezinta un fragment de functionalitate care
indeplineste un sebset din cerintele clientului, si care
este capabila sa aduca valoare adaugata clientului
atunci cand este scoasa pe piata ca entitate
independenta
• M Denne & H Cleland-Huang, Software by Numbers
• Produsele software pot fi descompuse in MMF
– valoarea nu este perceputa ca un intreg, ci ca o serie
de caracteristici.
– functionalitatile sunt adesea livrate in mod separat.
– un produs software complex poate oferi valoare chiar
daca nu este complet.
ALEGEREA CICLULUI DE VIATA
 Alegerea Ciclului de viata
• In functie de software
• Iterativ sau Incremental
• Intelegerea cerintelor ?
• Riscuri
• Deadline fix?
• Experienta echipei / clientului
 Comparatie
Insusire a Modelului Cascada Code & Fix Spirala Cascada Prototip
Ciclului de Viata simpla modificat evolutiv
Lucreaza cu cerinte Slab Slab Excelent Acceptabil Excelent
putin intelese pana la
excelent
Lucreaza cu Slab Slab Excelent Acceptabil Slab pana la
arhitectura putin pana la acceptabil
inteleasa excelent
Produce sisteme cu Excelent Slab Excelent Excelent Acceptabil
grad mare de
siguranta
Produce un sistem cu Excelent Slab pana la Excelent Excelent Excelent
crestere extinsa Acceptabil
Gestioneaza riscurile Slab Slab Excelent Acceptabil Acceptabil
Poate fi constrans la Acceptabil Slab Acceptabil Acceptabil Slab
un program
predefinit
 Comparatie
Insusire a Modelului Cascada Code & Fix Spirala Cascada Prototip
Ciclului de Viata simpla modificat evolutiv
Efort suplimentar mic Slab Excelent Acceptabil Excelent Acceptabil

Permite corectii Slab Slab pana la Acceptabil Acceptabil Excelent

intermediare excelent
Furnizeaza clientului Slab Acceptabil Excelent Acceptabil Excelent
vizibilitate asupra
progresului

Furnizeaza Acceptabil Slab Excelent Acceptabil Acceptabil

managementului pana la
vizibilitate asupra excelent
progresului

Grad de complexitate Acceptabil Excelent slab Slab pana la Slab

manager/dezvoltator acceptabil
 Comparatie
Insusire a Modelului Staged Evolutionary Design to Design to COTS
Ciclului de Viata Delivery Delivery schedule tools
Lucreaza cu cerinte Slab Acceptabil Slab pana la Acceptabil Excelent
putin intelese pana la acceptabil
excelent
Lucreaza cu Slab Slab Slab Slab pana la Slab pana la
arhitectura putin excelent excellent
inteleasa
Produce sisteme cu Excelent Acceptabil Acceptabil Slab pana la Slab pana la
grad mare de pana la excelent excellent
siguranta excelent
Produce un sistem cu Excelent Excelent Acceptabil Slab N/A
crestere extinsa pana la
excellent
Gestioneaza riscurile Acceptabil Acceptabil Acceptabil Slab pana la N/A
pana la acceptabil
excellent
 Comparatie
Insusire a Modelului Staged Delivery Evolutionary Design to Design to tools COTS
Ciclului de Viata Delivery schedule
Poate fi constrans la un Acceptabil Acceptabil Excelent Excelent Excelent
program predefinit

Efort suplimentar mic Acceptabil Acceptabil Acceptabil Acceptabil pana Excelent

la excelent

Permite corectii Slab Acceptabil pana Slab pana la Excelent Slab

intermediare la excelent acceptabil

Furnizeaza clientului Acceptabil Excelent Acceptabil Excelent N/A

vizibilitate asupra
progresului
Furnizeaza Excelent Excelent Excelent Excelent N/A
managementului
vizibilitate asupra
progresului
Grad de complexitate acceptabil Acceptabil Slab Acceptabil Acceptabil
manager/dezvoltator
 Comparatie
Modelul Ciclului de Viata Metode Agile
Cerinte putin intelese Bun
Arhitectura putin inteleasa Slab

Produce sisteme cu grad mare de siguranta Acceptabil

Produce un sistem cu crestere extinsa Acceptabil

Gestioneaza riscurile Bun

Poate fi constrans de un program Bun

Efort suplimentar mic Bun

Permite corectii intermediare Bun

Vizibilitatea clientului Excellent

Vizibilitatea managerului Acceptabil

Gradul de complexitate manager/dezvoltator Slab