CursuriManagementulProiectului

PLANIFICAREA CICLULUI DE VIATA 1

Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com

Every software-development effort goes through a lifecycle,which consists of all the activities between the time that version 1.0 of a

system begins life as a gleam in someones eye and the time that version 6.74b finally takes its

last breath on the last customers machine.

Steve McConnell,

Rapid Development, 1996

INTRO - CITAT


The goal is often not to achieve what you said you would do at the beginning of the

project, but to achieve the maximum

possible within the time and resources

available.

Roger Sherman,

Microsoft, 1995

INTRO - CITAT


PLANIFICAREA CICLULUI DE VIATA

Componente de baza:

Etapele si ordinea lor

Produse intermediare la fiecare faza

Review pentru fiecare faza

Clasificare metode:

Liniare

Iterative

Incrementale

Agile

Adaptive


ALEGEREA CICLULUI DE VIATA


ALEGEREA CICLULUI DE VIATA Criteriu Motivatie

Buget Folosirea unei metodologii poate afecta bugetul prin adaugarea de costuri legate de metoda si de

management

Dimeniune echipa Metodele adreseaza si dimeniunea echipei

Timpul alocat Timpul poate fi o constrangere. Calitatea poate fi influentata de timpul alocat.

Tehnologia folosita Hardware sau Software

Documentatia Unele metode sunt axate pe documentatie altele o evita pe cat posibil. Documentatia ofera feedback echipei de management

Training Echipa poate necesita cursuri pentru intelegerea metodei.

Best practices/lessons

learned Difera in functie de metoda folosita

Tehnici de aplicare si

tools Disponibilitatea acestor elemente este importanta

pentru alegere.

Procesele existente Maturitatea proceselor va infuenta ritmul proiectului


PLANIFICAREA CICLULUI DE VIATA

Waterfall (Clasic)

Code and Fix

Prototype: Throw away and evolutionary

V

Incremental

COTS-Commercial Off-the-Shelf Software

Spiral

Iterativ

RAD - Rapid Application Development

Design to Schedule / Tools

Staged Delivery

Evolutionary delivery

Agile XP: eXtreme Programming

Scrum

Rational Unified Process


STUDIU DE CAZ

Programmer produces code he believes is bug-free.

Product is tested. 20 bugs are found.

Programmer fixes 10 of the bugs and explains to the testing department that the other 10 arent really bugs.

Testing department finds that five of the fixes didnt work and discovers 15 new bugs.

Repeat three times steps 3 and 4.

Due to marketing pressure and an extremely premature product announcement based on overly-

optimistic programming schedule, the product is released.

Users find 137 new bugs.

Original programmer, having cashed his royalty check, is nowhere to be found.

Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.

Original programmer sends underpaid testing department a postcard from Fiji. Entire testing

department quits.

Company is bought in a hostile takeover by competitor using profits from their latest release,

which had 783 bugs.

New CEO is brought in by board of directors. He hires a programmer to redo program from

scratch.

Programmer produces code he believes is bug-free.

http://thejokeshop.org/2010/01/software-development-lifecycle/


Waterfall (Cascada)


WATERFALL (CASCADA)

Propus in 1970 de W.W. Royce

Bunicul tuturor modelelor

Secventa liniara fazele nu se suprapun

Toata planificarea de la inceput

Analiza acerintelor

Arhitectura Implementare Testare

Mentenenta Nu trebuie omisa


MODEL WATERFALL (CASCADA)

Idee Produs

Analiza Arhitectura

Cerinte

Implementare Testare

Validare Validare Validare

Validare


WATERFALL (CASCADA) -

REALITATE

Idee Produs

Analiza Arhitectura

Cerinte


Validare Validare Validare

Validare

$ $

$ $ $


Avantaje

Insiruire logica a secventelor

Scalabilitate

Orientat pe documentare

Puncte fixe de review / milestone

WATERFALL (CASCADA)


Dezavantaje

Necesita specificatii / cerinte foarte bine definite

de la inceput

Lipsa de flexibilitate (secventa rigida inceput ->

final)

Rezultatele se vad la final

Aparitia de probleme intre secvente

WATERFALL (CASCADA)


WATERFALL (CASCADA) SASHIMI

Concept

Cerinte

Arhitectura

Arhitectura detaliata

Codare

Testare

Suprapunere etape

Watterfall Modificat versiunea 1


WATERFALL (CASCADA) SASHIMI

Catacteristica: etape suprapuse

Avantaje

Reduce timpul

Reduce documentatia

Functioneaza bine daca exista o continuitate a

resursei umane

Dezavantaje

Milestones greu de definit

Procese dificil de planificat si urmarit

Dificultati in comunicare


WATERFALL (CASCADA) MODIFICAT

Watterfall Modificat versiunea 2

Idee Produs

Analiza Arhitectura

Cerinte


V&V V&V V&V

Validare

V&V = Verification and Validation

Validation: Are we building the right product?

Verification: Are we building the product right? Diferenta


Citat : Chris Kemerer

Reality of Waterfall

1. Enthusiasm

2. Disillusionment

3. Panic & Hysteria

4. Search for the Guilty

5. Punishment of the Innocent

6. Praise & Honors for the non-participants

WATERFALL (CASCADA)

Studiu de caz


Code-and-Fix


CODE-AND-FIX

Code-like-Hell

Specificatii (poate), Cod (DAAAAA), Release (poate)

Cod Test Cod Test

Problema -> Rezolva -> Incepe din nou

Design (high level)

Cod Test Cod Test..

Cod -Test Cod Test Documenteaza

Mentenanta: Test Code -Test

COD TEST


CODE-AND-FIX

Avantaje Fara un managemet excesiv

Nu necesita experienta

Dezavantaje Control inexistent al proceselor si a calitatii

Foarte riscant

Avantajos pentru prototipuri sau teste


CODE-AND-FIX

Probleme

Structura codului dupa faze succesive

cod-fix1

Codul bine scris nu indeplineste in mod

obligatoriu si necesitatile clientului

Codul este greu de depanat in lipsa

metodologiilor de testare


Prototiparea Evolutiva Exploratorie


METODA PROTOTIPARII

O metoda folosita atunci cand:

cerintele generale sunt cunoscute dar cerintele

specifice sunt neclare sau dificil de identificat

exista o incertitudine asupra cerintelor

sistemului

sistemul este complex

interfata cu utilizatorul este complexa

Permite:

experimentarea cu mai multe solutii

interactiunea utilizatorului cu sistemul


PROCESUL DE PROTOTIPARE

Metoda prototiparii:

versiune initiala a sistemului este construita

repede si ieftin

evaluare a sistemului din primele versiuni

rezultatele evaluarii ajuta la rafinarea

cerintelor

iteratii succesive



Cerinte

Arhitectura

Implementare

Testare

ANALIZA

Decizie

Arhitectura

Implementare

Testare

Mentenata



Prototiparea evolutiva (Evolutionary prototyping)

Obiectiv:

sistem functional

Se realizeaza un prototip si se rafineaza (evolueaza)

pana in la forma finala.

Prototiparea exploratorie (Throw-away prototyping)

Obiectiv:

obtinerea sau validarea cerintelor

testarea unei idei sau tehnologii

Implementare practica a unui sistem cu scopul de a

ajuta la identificarea cerintelor sau a explora o

implementare. Prototipul astfel obtinut este aruncat.



PROTOTIPAREA EXPLORATORIE

Prototiparea exploratorie (Throw-away

prototyping)

Dup finalizarea implementarii cerinele de sistem,

aruncai prototipul.

Proiectarea i implementarea sistemului conform cerinelor

utiliznd cele mai bune tehnici de inginerie software.

Clientul trebuie s neleag c prototipul nu este realizat

pentru a servi ca un sistem functional.

Costul asociat unui prototip i efortul de dezvoltare a sa se

justifica prin testarea functionarii solutiei astfel

propuse



PROTOTIPAREA EVOLUTIVA

Prototiparea evolutiva (Evolutionary

prototyping)

Utilizai ultimul prototip ca punct de plecare pentru

proiectarea sistemului.

Prototiparea evolutiva trebuie s fie planificata de la

nceput.

Necesitatea de a identifica inca din faza de planificare

daca costul prototiparii se justifica, adica este mai

mic dect costul de dezvoltare directa a sistemului,

pornind de la cerinele.




Etape

1) Identificare cerinte de baza (de pot ignora anumite

detalii)

2) Dezvoltarea prototipului initial

3) Review (client, utilizator) si feedback

4) Imbunatatirea si extinderea functionalitatilor

prototipului

5) Se repeta pasii 3 si 4 pana la obtinerea unei

versiuni de prototip acceptata


REZUMAT

Cerinte

Prototip evolutiv

Prototip exploratoriu

Sistem

Specificatii

sau

Componenta

Rezultat



THROW AWAY PROTOTYPE

Final necunoscut

Scopul : Cercetarea in domeniu

Dezavantaje

Rezultatele se vad la sfarsit: Merge sau nu ?

Calitatea

Poate fi realizat !!

Evrika !!

Am gasit cerintele

Vs




Folosit pentru reducerea riscurilor legate de cerinte

Prototipul este dezvoltat si apoi este aruncat dar anumite componente pot fi inglobate in solutia finala

Acest prototip nu este solutia finala deoarece:

Anumite caracteristici ale sistemului nu au fost

tratate

Efectul anumitor interactiuni nu este luat in calcul

Nu exista cerinte bine definite

Structura sistemului nu este definita

Lipsa documentatiei

Lipsa standardelor de calitate




Cerinte

initiale Implementare Evaluare

Specificatii

Metoda de dezvoltare

PRODUS FINAL

De obicei

incomplete



EVOLUTIONARY PROTOTYPE

Diferente fata de modelul anterior

Se specifica un produs final

Caracteristicile produsului evolueaza pana la un

rezultat final predeterminat.

Concept Prototip

initial Prototip

final




Cerinte Arhitectura Versiune

Prototip

Evaluare

Decizie

Produs




Vs

Corect ?




Functioneaza atunci cand: Exista cerinte cu evolutie dinamica in decursul

proiectului

Client care nu se angajaza

Domeniu al problemei de rezolvat vag definit

Asigura un progres vizibil

Nu functioneaza atunci cand: Este necesara o estimarea temporara ->dificila

Este necesar termenul de finalitatea proiectului -> greu de datat

Poate reprezenta o scuza pentru a aplica code-and-fix




Avantaje:

Se obtine o versiune functionala foarte repede

Implicarea utilizatorului

Dezavantaje:

Probleme de management:

esimare durata dificila

etapele pot fi cele din modelul waterfall

Probleme de sistem: schimbarile dese pot

afecta sistemul


Modelul Incremental


MODELUL INCREMENTAL

Dezvoltarea produsului in incremente

Fiecare increment aduce (teoretic) mai multa

functionalitate

Arhitectura Cerinte Increment

1

Increment

n

Sistem final


MODELUL INCREMENTAL

DESCRIERE

Sistemul este dezvoltat in incremente dupa finalizarea

arhitecturii generale.

Se pot dezvolta cerinte si specificatii pentru fiecare

increment.

Fiecare increment include functionalitati ale sistemului:

Implicarea utilizatorului

poate testa fiecare increment

Stabileste prioritatea functionalitatilor si ordinea incrementelor

Sistem functional odata cu primele incremente

Aduce un plus de control si structura fata de metoda

prototiparii

Reduce riscul de implementare a cerintelor eronate


MODELUL INCREMENTAL

IMPLEMENTARE 1

Cerinte sistem

Arhitectura Implementare

increment

Integrare

increment

Sistem

complet Sistem final

Va

lid

are

Validare


MODELUL INCREMENTAL

IMPLEMENTARE 2

Analiza de

sistem Cerinte Arhitectura

Increment

1


Cod

Integrare

Implementare

Operare si mentenanta

Verificare

Testare unitate

Verificare sistem

Testare sistem

Increment

n

Sistem


MODELUL INCREMENTAL

IMPLEMENTARE 3

Cerinte

Design

Implementare

V0.1

V0.2

V0.3

V0.4

V0.9

V1

Dem

o1

Dem

o2

Dem

o3

Dem

o4

Dem

o9

Dem

o


MODELUL INCREMENTAL

Avantaje

Fiecare incrementare aduce un produs functional

Feedback de la client pentru fiecare increment

divide and conquer

Costuri initiale scazute -> Mai rapid

Dezavantaje

Definire a unui sistem functional de la inceput

Interfata intre module

Costul final nu este mic


Modelul V


MODELUL V

Model axat pe testare si validare

Varianta de Waterfall / Cascada

Verificare:

Rezultatele unei etape corespund cu specificatiile si cerintele

stabilite.

Build the thing right.

Validare

Sistemul produs corespunde nevoilor si asteptarilor

utilizatorului.

Build the right thing.


MODELUL V

Planificarea

proiectului

(productiei)

Identificarea

cerintelor si

specificatiilor

Arhitectura

globala

Arhitectura

detaliata

Codare

Testare a

modulelor

Integrare si

testare

Productie,

operare si

mentenata

Testare a

sistemului si

acceptanta


MODELUL V

Avantaje:

Incurajaza testarea si validarea pentru fiecare etapa -

> orice produs (deliverable) trebuie testat

Alegerea optima pentru sisteme ce necesita un grad

mare de risc

Dezavantaje:

Nu avantajaza abordarea iterativa

Schimbarile sunt greu de implementat

Nu are implementat o analiza a riscului


Commercial Off-The-

Shelf software (COTS)


COMMERCIAL OFF-THE-

SHELF SOFTWARE (COTS)

Decizie: Dezvolta sau cumpara?

Pasi:

Identifica variantele

Verifica bibliotecile sau modulele

Cumpara

Foloseste

Scrie daca nu gasesti


COMMERCIAL OFF-THE-SHELF

SOFTWARE (COTS)

Cerinte

Arhitectura Oferta

Compromis


COTS - TIPURI

Biblioteci

anchor COTS

Limbaje pentru dezvoltare

Aplicatii ce se pot lega cu alte aplicatii

Islands of COTS SW

Pachete COTS ca module

Necesita integrare


COTS

Cerinte Arhitectura Implementare Testare

Analiza

Identificare

Arhitectura

aplicatie

Integrare Codare

legaturi

Codare Testare

sistem

Testare

acceptanta

Dezvoltare sistem COTS



SOFTWARE (COTS)

Trebuie adresate probleme legate de:

Functionalitate

Performanta

Interoperabilitate

Evolutie a produsului

Vanzator

Securitate

Actualizari



SOFTWARE (COTS)

Avantaje

Disponibil imediat

Cost scazut

Dezavantaje

Concesii legate de:

arhitectura

cost

plan

securitate

Nu intodeauna indeplineste criteriile


Waterfall (Clasic)

Code and Fix

Prototype: Throw away and evolutionary

V

Incremental

COTS-Commercial Off-the-Shelf Software

Spiral

RAD - Rapid Application Development

Design to Schedule / Tools

Staged Delivery

Evolutionary delivery

Metode Agile XP: eXtreme Programming


Studiu de caz - istoric


Modelul spirala

Definit de Barry Boehm

Combina elemente din modelele:

evolutionary,

incremental,

prototyping

Primul model ce explica importanta si eficienta

iteratiilor

Termenul spirala se refera la iteratii succesive pornind dintr-un punct central


Studiu de caz - diagrama Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com

Scopul: identificarea riscului de la inceput si

evaluarea in fiecare etapa

In teorie, riscul este redus cu fiecare ciclu al

spiralei, pe masura ce produsul devine mai rafinat.

Primele spirale sunt mai ieftine

Numarul de spirale este variabil

Ficare spirala:

Incepe cu design-ul

Se incheie cu opiniile clientului despre progresul facut si

directiile de urmat


Avantaje

Poate fi combinat cu alte modele

Cu cresterea costurilor scade riscul

Oientarea spre managementul de risc genereaza

avertismente la fiecare

Dezavantaje

Complex

Creste volumul de munca pentru management

Creste costul proiectului


Este recomandat pentru:

Proiecte cu grad mare de risc

Cerinte slab intelese

Arhitectura slab inteleasa

Potentiale probleme de performanta

Probleme cu intelegerea tehnologiei

In combinatie cu alte metode:

Se poate incheia cu Waterfall

Poate include alte modele ca iteratii


Pasii Waterfall pentru arhitectura

Celelalte etape urmeaza pasi:

Stage 1, 2, ..., n

Detailed Design

Code Construction & Unit Testing

System Testing

Release


Concept

Arhitectura

Analiza cerinte

Design

detaliat Test Cod

Design

detaliat Test Cod

Design

detaliat Test Cod

PRODUS R

1

Release 1

R

2 PRODUS

Release 1

PRODUS

Release n

R

n


Caracteristici:

Produsul este livrat in etape

Cerintele sunt organizate in functie de prioritate

Planificare initiala cuprinde datele la care se fac livrarile

si functionalitatile incluse

Orice livrare intermediara presupune:

functionalitati implementate integral

un produs ce poate fi livrat catre client

Reduce riscul de a nu livra nimic functional

Progresul este vizibil odata cu implementarea proiectului

Faciliteaza respectarea bugetului proiectului


Cerinte bine definite si acceptate de client

Stabilirea de prioritati pentru functionalitati

Arhitectura bine definita

Clientul accepta sa implementeze versiuni pana la finalizarea produsului

Posibilitatea de a livra module din produsul final

Asigurarea calitatii fiecarei versiuni

Release 1 Release 2 Final Product


Avantaje Produsul (intermediar) este livrat mai repede Versiuni beta interne sau externe Implica clientul in testare Implica echipa de vanzari si marketing

Problemele sunt descoperite mai repede Flexibilitate Progres si probleme vizibile de la inceput Documentatie mai putina, planificare simplificata

Dezavantaje Cerintele sunt validate tarziu si sunt greu de schimbat

Lipsa unei arhitecturi flexibile poate crea probleme


Metode de dezvoltare cu urmatoarele caracteristici:

Planul de proiect este definitivat de la inceput

Arhitectura generala este dezvoltata de la inceput

Aplica principii din metoda Staged Delivery

Versiunile intermediare (stages) cuprind functionalitatile

cu prioritatea cea mai mare

Nu toate versiunile (stages) vor fi livrate


Concept

Arhitectura

Analiza cerinte

Design

detaliat Test Cod

Design

detaliat Test Cod

Design

detaliat Test Cod

Data de livrare

a produsului

Functionalitati cu prioritate mare

Functionalitati cu prioritate medie

Functionalitati cu prioritate mica

PRODUS

S

T

A

G

E


Avantaje

Produsul este livrat la o data stabilita

Cele mai importante aspecte sunt realizate mai intai

Dezavantaje

Etapele nefinalizate


Diferente fata de evolutionary prototyping

Accent pe dezvoltarea, la inceput, a unui sistem cu

putine functionalitati

Accent pe vizibil: front end

evolutionary

prototyping staged delivery

Evolutionary Delivery


Concept

Cerinte

Arhitectura

generala

Versiune finala EVOLIUTIE


Cerinte Design Plan

Ciclu 1

Ciclu 2

Ciclu 3

Test

Plan

Design

Cod

Test Test

utilizator

Implicare client

Implicare

client


Avantaje

Tine cont de cererile clietului

Rezultate tangibile

Dezavantaje

Planificare

Code & Fix

Folosit la proiecte ce necesita un timp scurt


Manifest:

Oamenii si interactiile preferate poceselor si

instrumentelor

Software functional preferat documentarii

Colaborarea cu clientul preferata negocieroii

contractului

Raspunsul dinamic la schimbari fata de urmarirea

planului

usor (documentatie) & orientare client

http://agilemanifesto.org/


Adaptive Software Development (ASD)

Feature Driven Development (FDD)

Crystal Clear

Dynamic Software Development Method (DSDM)

Rapid Application Development (RAD)

Scrum

Extreme Programming (XP)

Rational Unify Process (RUP)

Prototyping


Cerinte initiale

Arhitectura initiala

Iteratie 1

Iteratie2

Iteratie n

Validare

Lectii invatate

Validare

Lectii invatate

Finalizare

Lectii invatate


Pun accent pe:

Control vizual

Echipe cu performanta ridicata

Test-driven development

Control adaptiv

Feature-driven development

Leadership si comunicare vs comanda si control

Folcalizare de la C(ost) spre R(evenue)

Lectii invatate / experienta


Dezvoltare

de model

Identificare

functionalitati

Planifica

functionalitati

Design bazat

pe

functionalitati

Dezvoltare

bazata pe

functionalitati

Versiune client

Analiza / Design

Design / Implememntare

Versiune finala


1. Joint Requirements Planning (JRP)

2. Joint Application Design (JAD) diferite definitii si denumiri pentru JAD,

Un lucru in comun ----sesiunea facilitata

3. Constructie

4. Cutover

Recomandat pentru sisteme ce folosesc multe date primite ca input


JAD o procedura ce acelereaza proiectarea solutiilor intormationale. Intalnirile grupului sunt

foarte bine structurate si se concentreaza pe modul

in care sistemul va functiona.

JRP un subgrup din JAD in care intalnirile grupului sunt foarte bine structurate si sunt efectuate pentru

a defini mai clar cerintele. Se concentreaza pe ceea

ce sistemul va face.


Dezvoltat de Chuck Morris

and Tony Crawford de la

IBM spre sfarsitul anilor

70 ca o metoda pentru colectarea cerintelor

pentru sisteme distribuite

geografic.

In 1984, IBM formalizeaza

JAD in urma publicarii

brosurii cu imaginea de

asambru a JAD.


Executiv

Facilitator

Utilizatori si Manageri

Selectati de sponsor

Scribi

Echipa IT

Echipa care va lucra la

proiect David Castillo Dominici

http://www.freedigitalphotos.net


Au o durata de 3-5 zile cu diferite sesiuni

Pot ajunge pana la 2 saptamani

Workshop-urile vor fi desfasurate departe de locul

de munca

Salile de sedinte sunt bine echipate

Instrumentele cazului,procesare de text, spreadsheet,

etc

Sali de sedinte cu dimensiune adecvata

Sali prea mari vor spori confortul participantilor


nokhoog_buchachon

Utilizatori

si

manageri

Scrib

Facilitator

JRP

Echipa IT

http://www.freedigitalphotos.net


Componente:

CONDUCERE:

proprietarul sistemului

capabili sa ia decizii si sa furnizeze resursele necesare

sesiunea de deschidere si finalizarea a proiectului.

LIDERUL/MANGERUL DE PROIECT:

liderul echipei de dezvoltare

raspunde la intrebarile legate de proiect cu privire la

domeniul de aplicare, timp, probleme de coordonare si

resurse.

pot contribui la sesiuni atata timp cat nu inhiba ceilalti

participanti.


FACILITATORUL/LIDERUL DE SESIUNE:

conduce sedinta si directioneaza schimbul de idei

mentine grupul pe ordinea de zi a sedintei

este responsabil cu identificarea problemelor care pot fi

rezolvate in timpul sedintei si cele care sunt pastrate

pentru sfarsitul de sedinta pentru investigatii ulterioare

si rezolutii.

deserveste participantii si nu contribuie la sedinta cu

informatii.

OBSERVATORI:

membri ai echipei de dezvoltare.

vor sta in spatele participantilor si vor observa in liniste

desfasurarea sesiunii.


PARTICIPANTI:

Clienti in zona de afaceri care sunt afectati de proiect

in mod direct sau indirect,

experti in domeniul lor si pot lua decizii legate de

munca lor

sursa de informatii in cadrul sesiunii.

SCRIBUL/MODELATOR/INREGISTRATOR/

Expert in documentatie:

Inregistreaza si publica procedurile sedintei fara a

contribui cu informatii la sedinta.


Incep cu cateva cuvinte din partea executivului

Facilitatorul preia conducerea si parcurge agenda

Factori critici de succes si oportunitati strategic

Odata cu inceperea discutiei facilitatorul intretine

discutia in limitele scopului sesiunii


Facilitatori calificati si cu experienta

Prezenta oamenilor potriviti

Obiective clar definite

Pregatiri premergatoare workshop-ului

Planificarea detaliata a agendei si urmarirea

acesteia

Folosirea minima a termenilor tehnici

Producerea rapida a documentului final


Cerinte JRP

Arhitectura JAD

Implementare Constructie de

prototipuri

Prioritati dinamice

Evolutie catre

produsul final

Acceptare

Instalare

Training

Methodologie

Echipa

Management

Tools


Reducerea timpului necesar dezvoltarii sistemului

Imbunatatirea calitatii si productivitatii sistemului Implica utilizatori finali in ciclul de viata de dezvoltare

Reduce costurile sistemului

Incurajaza dreptul la proprietate, acceptarea rapida si angajamentul clientului pe toata durata proiectului

Imbunatateste comunicarea si relatia intre zona de afaceri / utilizatorii finali si echipa de dezvoltare

Utilizeaza tehnici de modelarea

Accent pe cod nu pe documentare


Daca pregatirile corespunzatoare pentru sesiuni nu

sunt realizate, se va dovedi a fi o pierdere de timp

si fonduri

Nu este o metoda infailibila pentru a obtine

informatii

Necesita sisteme ce pot fi modularizate

Exista riscul sa nu se ajunga la un final


Programare pe perechi

Implementare bazata pe testare

Moto: Embrace Change

Planificare continua

Fara overtime! (nu zau!)

Metoda Lightweight

Politica pasilor marunti


http://en.wikipedia.org/wiki/File:XP-feedback.gif


Intreaga echipa: clientul

face parte din echipa

Metafora: analogie

frecventa pentru sistem

Jocul de planificare, bazate

pe povestirile utilizatorilor

Design simplu

Livrare rapida

(2 saptamani)

Testate de clienti

Programare in pereche

Dezvoltare bazata pe

teste: testele sunt

dezvoltate primele

Imbunatatirea design-ului

(refactoring)

Drepturi de proprietate

colective asupra codului

Integrare continua

Ritm sustinut:

fara ore suplimentare

Standarde de programare


STUDIU DE CAZ

http://www.extremeprogramming.org/map/project.html


STUDIU DE CAZ


Planning game.

Clientul decide cuprinsul si calendarul versiunilor pe

baza estimarilor echipei.

Echipa implememnteaza doar functionalitatile cuprinse

in povestile (story) din iteratia curenta

Small releases.

Sistemul intra in functiune inainte sa fie finalizat iar

actualizari apar oriunde in intervalul: o zi o luna.

Metafora

Sistemul este definit de una sau mai multe metafore

intelese atat de echipa cat si de client.


The metaphor just helps everyone on the project understand the basic elements and their

relationships.

Words chosen to identify technical entities should

be consistently taken from the chosen metaphor. As

development proceeds and the metaphor matures,

the whole team will gain new inspiration from

examining the metaphor.

Beck, K.: Glossary. The XP Series. In: Extreme

Programming Explained. Addison-Wesley (2000)


Arhitectura minimala.

In orice moment sistemul va trece toate testele trecute

in etapele precedente

Nu contine cod duplicat

Foloseste nr. minim de clase si metode

Teste.

Programatorii scriu modalitati de testare pentru fiecare

portiune

Clientii scriu teste functionale pentru fiecare story

Toate testele rulate vor fi trecute


Refactoring.

Un sistem este dezvoltat prin transformari ale celui deja existent mentinandu-se aceleasi rezultate ale testelor

Programarea in pereche.

Tot codul creat este scris de 2 persoane la acelasi monitor/-tastatura - mouse.

Integrare continua.

Noul cod este integrat cu sistemul curent dupa doar cateva ore.

sistemul trebuie sa treaca de toate testele, altfel schimbarile nu sunt aprobate

Drepturi colective.

Fiecare programator imbunatateste codul oriunde in sistem la orice moment daca se iveste o oportunitate


Client la locul faptei.

Clientul este impreuna cu echipa tot timpul

Saptamani de 40 de ore.

Nimeni nu poate sa lucreze ore suplimentare, doua saptamani

la rand

ore suplimentare frecvente = probleme ce trebuie adresate.

Spatiu deschis de munca.

Spatiu: camera mare impartita in compartimente (cubicles).

Perechi de programatori lucreaza la calculatoare in centru.

Reguli.

Fiind parte din echipa, te angajezi sa respecti regulile.

Echipa pate schimba aceste reguli la orice moment atat timp

cat sunt de acord sa evalueze efectele schimbarilor.


Avantaje

Proiecte mici si medii ->Lightweight

Echipa sudata

Accent pe produs

Iterativ

Testare pentru specificatii si calitate

Dezavantaje

Proiectele mari cer documentatie

Experienta pentru a nu ajunge la code&fix

Programarea pe perechi costa

Modele de testare complexe


Ciclu de viata 3


Cuprins


ISO SOFTWARE LIFE CYCLE PROCESSES

SCRUM

Test Driven Development

KANBAN


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 Templatespentru MP

Orientat pe obiecte Dezvoltare interactiva Management al specificatiilor Arhitectura bazata pe componente UML (Unified Modeling Language) modelare vizuala Folosit pentru sisteme complexe



Etape de dezvoltare: Inception Phase

Elaboration Phase

Construction Phase

Transition Phase

Bazat pe procese descrise de: Actori, cine?

Activitati, cum?

Artefacte, ce?

Flux, cand?



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


Rational Unified Process Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com

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.


Elaboration Phase Domain model

http://www.slideshare.net/grahammcleod/brief-introduction-to-domain-modeling

STUDIU DE CAZ


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


Standarde disponibile Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com

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 Croit 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

Achizitie Resurse Dezvoltare Operare Intretinere

Procese primare

Auditul Organizare /Configurare Referinte Documentare Garantia calitatii Solutionarea problemelor Verificare Validare

Procese de suport ale ciclului de viata

Management Infrastructura Imbunatatire Instruire

Procese organizationale


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.

Rezultate

Un rezultat al indeplinirii cu succes al scopului procesului.

224 de frezultate

Procesul

Un set de activitati inrudite, care transforma intrarile in iesiri

25 de procese (18 + 7 noi)

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 ORGANIZATIONALE

PROCESE PRIMARE PROCESE SUPORT



Achizitie Pregatirea achizitiei Selectia furnizorilor Gestiunea furnizorilor Preluare in gestiune (acceptare)

Resurse

Operare Operarea sistemului Suport client

Detalierea cerintelor

Dezvoltare

Analiza si designul sistemului

Analiza cerintelor software

Designul software

Implementare software

Integrare software

Testare software

Integrarea si testarea sistemului

Intretinere

PROCESE PRIMARE



PROCESE DE SUPORT

Documentatie

Managementul configuratiei

Rezolvarea problemelor

Asigurarea calitatii Verificare Validare Review Audit



Management Managementul calitatii

Managementul riscului

Imbunatatiri Stabilirea proceselor Evaluarea proceselor Imbunatatirea proceselor

Alinierea organizationala

Infrastructura Managementul resurselor umane

Management de proiect

Reutilizare

Monitorizare

PROCESE DE ORGANIZARE


Proiect

Sistem

Software

Proces Instalare

Acceptanta si suport

Perspectiva ISO/IEC 12207

Proces

Analiza de cerinte Arhitectura Integrare Testare

Cerinte

Arhitectura Integrare

Testare


Programare 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 a aparut in ultima jumatate a anilor 90 ca o metoda

alternativa de management a proiectelor software 2001 Agile Software Development with Scrum

Ken Schwaber & Mike Beedle se abate de la doctrina 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.


Motivatie scrum

Ciclul de viata al dezvoltatii software Colectarea si analiza cerintelor

Design/Proiectare

Implementare

Testare

Livrare

Iesirea unei etape serveste ca intrare pentru etapa urmatoare Fiecare etapa produce o iesire previzibila si definita

Aplicarea procesului rezulta in obtinerea de iesiri repetabile


Motivatie scrum

Control empiric a procesului:

pregatire pentru neprevazut

control prin inspectii frecvente si adaptari

procese imperfect definite care genereaza rezultate imprevizibile si irepetabile


Cadrul Scrum

Roluri :

Proprietarul produsului,

ScrumMaster,

Echipa

Ceremonii:

Planificarea Sprint,

Sprint Review,

Retrospectiva Sprint

Reuniuni zilnice

Artefacte :

Backlog produs,

Sprint Backlog,

Graficul de Finalizare (Burndown Chart)


Elemente Scrum

Scrum Master

Interfata intre management si echipa Scrum

De obicei un inginer cu experienta

Responsabil cu indepartarea impedimentelor ce determina stagnarea progresului echipei Scrum

Trebuie sa ia decizii rapide bazate pe date incomplete


Elemente Scrum

Product Owner (Proprietarul produsului)

Singurul detinator al Product Backlog

Modificarile la portofoliul trebuie sa fie aprobate de proprietarul produsului

Lider tehnic sau manager de proiect


Elemente Scrum

Echipa Scrum Designeri, Testeri, Programator

Marime recomandata 5 10 persoane

Diversificata: QA, Programatori, Designeri UI , etc.

Membrii trebuie implicatii full-time Pot exista exceptii (ex. System Admin, etc.)

Echipele se auto-organizeaza Ce este de facut daca o echipa auto-organizeaza pe cineva afara din

echipa??

In mod ideal fara titluri dar posibil, ca exceptie

Calitatea de membru se poate modifica numai intre sprinturi


Ceremonii

Sedinta de planificare Sprint

Partea I: Crearea Product backlog

Stabilirea tintei Sprint-ului

Participanti: Proprietarul produsului, Scrum Master, Echipa Scrum

Partea a II-a: Participanti:

Scrum Master, Echipa Scrum

Crearea Scrum Backlog


Ceremonii

Pre-Proiect/Kickoff Meeting

O forma speciala a Sedintei de planificare a Sprint

Sedinta inaintea demararii proiectului


Sprint

Dureaza aproximativ 30 zile

Functionalitatile cu prioritatile cele mai mari din Product Backlog sunt implementate sub denumirea de Sprint Backlog

Estimarile Sprint sunt actualizate odata ce sunt finalizate sarcinile sau cand apar altele noi

Dezvoltarea continua a produslui cu potential de transfer


Sprint

Interval de timp in care este stabilita functionalitatea unui produs

Nici o influenta exterioara NU poate interfera cu echipa Scrum in timpul Sprint-ului

Fiecare Sprint incepe cu Sedinta Zilnica a Scrum


Nici o schimbare in cadrul sprint

Sprint Intrari Testare cod

Planifica durata sprint in functie de cat de mult poti evita modificarea acestuia

SCHIMBARE


SCRUM Daily

SCRUM

Sprint Planning Meeting

Review Meeting

Story Time session

Analysis, Design, Evolution, Testing

Architecture

Standards Technology

Design

Sprint Backlog


Ceremonii

Sedinta zilnica Scrum (Daily Scrum)

Dureaza intre 5 - 15 minute

Care sunt realizarile de la ultima reuniune?

Ce ati facut ieri?

Care sunt impedimentele pentru activitatile urmatoare?

Ce obstacole aveti de depasit?

Ce se va realiza pana la urmatoarea sedinta? Ce veti face azi?

Toti participa, numai cei avizati isi spun parerea


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.


Intrebari

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

Echipa prezinta realizarile Sprint-ului

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

Doi pasi: Informala

Regula: pregatire cu 2 ore in avans

Formala Clienti

Management

Proprietarul produsului

Alti ingineri


Ceremonii

Sedinta retrospectiva Sprint 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 4 ore

Ofera feedback la management

Ofera feedback pentru urmatorul Sprint


Product Backlog

O lista prioritizata de functionalitati pe care le cere proprietarul produsului. Caracteristici noi

Imbunatatiri ale caracteristicilor deja existente

Prototipuri

Documentatie

Eliminarea bug-urilor

Training

O simpla lista de dorinte daca nu se tine cont de prioritizare


Portofoliu(Backlog)

Istoric Ca un [rolul utilizatorului final], eu vreau [dorinta] asa incat [rationamentul]

Studiu de caz


Product Backlog

Afirmarea simpla a ceea ce se cere:

Ca si dorec sa astfel incat sa pot .

Exemplu: Ca si manager al Serviciului Clienti, doresc sa cunosc durata medie de asteptare astfel incat sa pot asigura personalul necesar la centrul de preluare a apelurilor.

STORY


Product Backlog

Permit proprietarului produsului sa creeze cerinte independente de modul de implementare;

Permite scrierea cerintelor din punctul de vedere al diferitelor tipuri de utilizatori

Permite utilizatorilor si echipei SCRUM sa vorbeasca nu atat despre sistem in sine, cat despre cum il vor utiliza

Reprezinta o promisiune a unei viitoare conversatii

Pot fi scrise atat de persoane din domeniul tehnic cat si de persoane din afara acestui domeniu de activitate


Product Backlog

I independent

N negociabil

V valorificabil

E estimabil

S simplu

T testabil

Relatari utile de la utilizatori in jurul cuvantului ce, nu cum


Product Backlog

Proprietarii 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


Estimare Product Backlog

Diverse metode de estimare a duratei unei povesti (story): Ore

Zile ideale ( Ideal days)

T-shirt sizes (XS, S, M, L, XL, XXXL )

Sirul Fibonacci ( 1,2,3,5,8,13,21) -> factor de complexitate

Estimarile sunt converite in story points, -> estimare cantitativa specifica fiecarei echipe

Viteza echipei = media story points asociata povestilor finalizate de o echipa

Metode de

estimare relativa


Estimare absoluta vs relativa

Estimati lungimea in (m):

Furnica, Boeing 747, Basculanta, Pod Cernavoda, Miriapod

Aranjati dupa lungime, in ordine crescatoare:

Furnica, Boeing 747, Basculanta, Pod Cernavoda, Miriapod

Estimare absoluta

Estimare relativa

Definire miriapod: expert knowledge


Sprint Burndown Chart

Progress

752 762

664619

304264

180104

200

100

200

300

400

500

600

700

800

900

5/3/2002

5/5/2002

5/7/2002

5/9/2002

5/11/2002

5/13/2002

5/15/2002

5/17/2002

5/19/2002

5/21/2002

5/23/2002

5/25/2002

5/27/2002

5/29/2002

5/31/2002

Date

Rem

ain

ing

Eff

ort

in

Ho

urs


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 poate face

De ce nu poate fi 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


Pro

Pune accent pe munca in echipa Echipa se dezvolta si contribuie pe parcursul

porcesului Echipa devine autonoma si se straduieste pentru

excelenta

In functie de etapa, rotatia 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


Pro 2

Creeaza un mediu deschis de munca si incurajeaza feedback-ul

Evaluarea efortului si mijloacele de recompensare sunt bazate pe performanta echipei

Reduce nevoia pentru sedinte, 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


Contra

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 esecului in cazul in care proiectul nu se finalizeaza

Marimea echipei este restrictionata datorita implicarii tuturor membrilor echipei

Potrivita pentru dezvoltarea de noi produse si nu pentru imbunatatirea unui produs deja existent

Bazat pe experienta


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



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)



TDD

=

Test first

+

Automated (Unit) Testing

RED

GREEN

REFACTOR

GREEN

STUDIU DE CAZ



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



Refactorizare

restructurare,

simplificare,

imbunatatire

Refactorizarea este o metoda foarte buna pentru a descompune codul.



Refactorizare



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 Avantaje

Eficienta

Imbunatatirea rezultatelor testarii

Reducerea aparitiei defectelor

Programatorul se ocupa si de testare

Disponibilitate la schimbare


KANBAN


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!


Principii 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.

Proces INPUT OUTPUT

Intrarea este determinata de iesire


Principii Kanban

3 principii de baza

Incepe cu ce stii sa faci

Schimbarea se face evolutiv incremental

La inceput se aloca si respecta rolurile si responsabilitatile


Principii

Principiile de baza Kanban pentru Ingineria Software Limitarea Work in Process (WIP)

Valoarea Pull (cu limita pentru WIP)

Vizibilitate (Control Vizual)

Cresterea eficientei

Portofoliu Kanban prestabilit

Calitatea integrata in (nu inspectata in)

Echipa monitorizeaza in mod continuu imbunatatirea celor de mai sus


Kanban

STUDIU DE CAZ

http://www.infoq.com/articles/hiranabe-lean-agile-kanban


Kanban

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.


Tabela Kanban

http://www.crisp.se/gratis-material-och-guider/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.


Kanban

STUDIU DE CAZ

http://www.versionone.com/what-is-kanban/


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

Ciclului de Viata

Cascada

simpla

Code & Fix Spirala Cascada

modificat

Prototip

evolutiv

Lucreaza cu cerinte

putin intelese

Slab Slab Excelent Acceptabil

pana la

excelent

Excelent

Lucreaza cu

arhitectura putin

inteleasa

Slab Slab Excelent Acceptabil

pana la

excelent

Slab pana la

acceptabil

Produce sisteme cu

grad mare de

siguranta

Excelent Slab Excelent Excelent Acceptabil

Produce un sistem cu

crestere extinsa

Excelent Slab pana la

Acceptabil

Excelent Excelent Excelent

Gestioneaza riscurile Slab Slab Excelent Acceptabil Acceptabil

Poate fi constrans la

un program

predefinit

Acceptabil Slab Acceptabil Acceptabil Slab


Comparatie


Ciclului de Viata

Cascada

simpla

Code & Fix Spirala Cascada

modificat

Prototip

evolutiv

Efort suplimentar mic Slab Excelent Acceptabil Excelent Acceptabil

Permite corectii

intermediare

Slab Slab pana la

excelent

Acceptabil Acceptabil Excelent

Furnizeaza clientului

vizibilitate asupra

progresului

Slab Acceptabil Excelent Acceptabil Excelent

Furnizeaza

managementului

vizibilitate asupra

progresului

Acceptabil Slab Excelent Acceptabil

pana la

excelent

Acceptabil

Grad de complexitate

manager/dezvoltator

Acceptabil Excelent slab Slab pana la

acceptabil

Slab


Comparatie


Ciclului de Viata

Staged

Delivery

Evolutionary

Delivery

Design to

schedule

Design to

tools

COTS

Lucreaza cu cerinte

putin intelese

Slab Acceptabil

pana la

excelent

Slab pana la

acceptabil

Acceptabil Excelent

Lucreaza cu

arhitectura putin

inteleasa

Slab Slab Slab Slab pana la

excelent

Slab pana la

excellent

Produce sisteme cu

grad mare de

siguranta

Excelent Acceptabil

pana la

excelent

Acceptabil Slab pana la

excelent

Slab pana la

excellent

Produce un sistem cu

crestere extinsa

Excelent Excelent Acceptabil

pana la

excellent

Slab N/A

Gestioneaza riscurile Acceptabil Acceptabil Acceptabil

pana la

excellent

Slab pana la

acceptabil

N/A


Comparatie


Ciclului de Viata

Staged Delivery Evolutionary

Delivery

Design to

schedule

Design to tools COTS

Poate fi constrans la un

program predefinit

Acceptabil Acceptabil Excelent Excelent Excelent

Efort suplimentar mic Acceptabil Acceptabil Acceptabil Acceptabil pana

la excelent

Excelent

Permite corectii

intermediare

Slab Acceptabil pana

la excelent

Slab pana la

acceptabil

Excelent Slab

Furnizeaza clientului

vizibilitate asupra

progresului

Acceptabil Excelent Acceptabil Excelent N/A

Furnizeaza

managementului

vizibilitate asupra

progresului

Excelent Excelent Excelent Excelent N/A

Grad de complexitate

manager/dezvoltator

acceptabil Acceptabil Slab Acceptabil Acceptabil


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


Documents

CursuriManagementulProiectului