Modele de dezvoltare a

programelor
Etapele dezvoltrii programelor

Modele de dezvoltare









Modelul cascad (waterfall)

Modelul n V
Modelul incremental
Prototipizarea
Modelul n spiral
Modelul RUP
Modele de dezvoltare Agile

Pentru dezvoltarea unui program avem nevoie de:

nelegerea clar a cerinelor
 un set de metode i instrumente de lucru
 un plan de aciune


Planul de aciune se numete model de dezvoltare

Dezvoltarea unui anumit program const ntr-un set de

pai ce se fac pentru a-l realiza

Lund n considerare tipul pailor ce se efectueaz, se

creeaz un model de lucru ce poate fi aplicat unei serii
mai largi de proiecte
Planul de aciune este numit model deoarece poate fi
privit ca un ablon al dezvoltrii de programe

Etapele dezvoltrii programelor

analiza cerinelor

proiectarea arhitectural

proiectarea detaliat

scrierea codului (implementare)

integrarea componentelor

validare

verificare

ntreinere

Etapele dezvoltrii programelor

Analiza cerinelor

Se stabilete ce anume vrea clientul ca

programul s fac

Scopul este nregistrarea cerinelor

manier ct mai clar i mai fidel
 claritatea
 fidelitatea

ntr-o

se refer la lipsa ambiguitii

se refer la nregistrarea ct mai exact

(posibil cuvnt cu cuvnt)

Etapele dezvoltrii programelor

Proiectarea arhitectural

Din motive de complexitate, programele mari nu pot fi

concepute i implementate ca o singur bucat
Programul va trebui construit din module sau componente
Proiectarea arhitectural mparte sistemul ntr-un numr
de module mai mici i mai simple, care pot fi abordate
individual

Etapele dezvoltrii programelor

Proiectarea detaliat

Se realizeaz proiectarea fiecrui modul al

aplicaiei, n cele mai mici detalii

Scrierea codului

Proiectul detaliat este transpus ntr-un limbaj de

programare

n mod tipic, aceasta se realizeaz modular, pe

structura rezultat la proiectarea arhitectural

Etapele dezvoltrii programelor

Integrarea componentelor

Modulele programului sunt combinate n produsul final

Rezultatul este sistemul complet

Modelul big-bang
componentele sunt dezvoltate i testate individual
componentele sunt integrate n sistemul final
avnd n vedere c funcionarea corect a componentelor individuale

a fost testat, integrarea ar trebui s fie o formalitate

din pcate, componentele nu pot fi testate exhaustiv, iar cnd acestea
lucreaz mpreun pot s apar situaii pe care o anumit component
nu le-a ntlnit n procesul de testare sau conflicte ntre anumite
componente (de exemplu, conflicte de partajare a resurselor)

s-a constatat c atunci cnd se aplic acest model, timpul de

testare explodeaz, proiectul devenind greu de controlat
denumirea de big-bang

Etapele dezvoltrii programelor

Modelul incremental
Acest model propune crearea unui nucleu al aplicaiei i
integrarea a cte o component la un moment dat, urmat
imediat de testarea sistemului obinut

Astfel, se poate determina mai uor unde anume apare o

problem n sistem

Acest tip de integrare ofer de obicei rezultate mai bune dect

modelul big-bang

Etapele dezvoltrii programelor

Validare

n procesul de validare ne asigurm c programul ndeplinete

cerinele utilizatorului

Construim produsul corect (Are we building the right product)?

Un exemplu de validare este testul de acceptare, n care produsul

este prezentat clientului; clientul spune dac este mulumit cu
produsul sau dac mai trebuie efectuate modificri

Verificare

n procesul de verificare ne asigurm c programul este stabil i c

funcioneaz corect din punctul de vedere al dezvoltatorilor

Construim corect produsul (Are we building the product right)?

Etapele dezvoltrii programelor

ntreinere


Dup ce programul este livrat clientului, mai devreme sau mai

trziu sunt descoperite defecte sau erori ce trebuie reparate

Pot aprea schimbri n specificaiile utilizatorilor, care vor

diverse mbuntiri

ntreinerea const n gestionarea acestor probleme

Analiza
cerinelor

Modelul cascad (waterfall)

Proiectarea
sistemului
Proiectarea
detaliat
Scrierea
codului
Testarea unitilor i
testarea la integrare
Testarea
sistemului
Testarea de
acceptare
Operarea i
ntreinerea

Modelul cascad

Nu se stipuleaz cum se fac paii menionai anterior

(metodologie, notaii), ci doar ordinea efecturii lor

Avantaj principal


O sarcin complex este mprit n mai muli pai mici, ce sunt

mai uor de administrat; fiecare pas are ca rezultat un produs
bine definit:

documente de specificaie
model etc.

Dezavantaje
Clientul trebuie s atepte instalarea sistemului pentru a vedea
cum funcioneaz acesta
 ntr-un anume stadiu al dezvoltrii nu se poate influena
rezultatul obinut ntr-un stadiu precedent pentru a se remedia o
problema gsit


Exemplu: la testare se poate descoperi o eroare de proiectare

Analiza
cerinelor

Modelul cascad cu reacie

se poate influena rezultatul obinut ntr-un
stadiu precedent

Proiectarea
sistemului
Proiectarea
detaliat

Scrierea
codului
Testarea unitilor i
testarea la integrare
Testarea
sistemului
Testarea de
acceptare
Operarea i
ntreinerea

Modelul cascad

n modelul de dezvoltare n cascad lipsete conceptul de

prototipizare
Prototipul este un produs dezvoltat parial care permite clientului i
dezvoltatorilor



Prototipizarea n faza de analiz a cerinelor permite asigurarea

faptului c cerinele sunt consistente i fezabile


n acest fel se pot face modificri n stadiul de analiz a cerinelor i nu

n faza de testare, care ar presupune, evident, costuri mult mai ridicate

Prototipizarea n faza de proiectare permite




s analizeze aspectele funcionale majore ale sistemului

s decid dac sistemul propus este suficient de apropriat de cel cerut

evaluarea unor strategii alternative de proiectare

stabilirea strategiei potrivite pentru proiect

Adesea, interfaa utilizator este construit i testat sub form de

prototip pentru a permite clienilor s neleag cum va arta
sistemul i, de asemenea, pentru a permite dezvoltatorilor s
neleag cum dorete clientul s interacioneze cu sistemul

Modelul cascad
Analiza
cerinelor

Validare

Modelul cascad
cu prototipizare

Proiectarea Verificare
sistemului
Proiectarea
detaliat
Scrierea
codului
Prototipizare

Testarea unitilor
i testarea la
integrare
Testarea
sistemului
Testarea de
acceptare
Operarea i
ntreinerea

Operarea i
ntreinerea

Modelul n V
Validare cerine

Analiza
cerinelor

Proiectarea
sistemului

Testarea de
acceptare

Testarea
sistemului
Verificare proiectare

Proiectarea
detaliat

Testarea unitilor i
testarea la integrare

Scrierea
codului

Modelul n V

Testarea componentelor i testarea la integrare pot fi

utilizate pentru verificarea proiectrii detaliate.


Altfel spus, n timpul celor dou etape ale testrii precizate mai sus
programatorii i membrii echipei de testare se pot asigura c
fiecare aspect al proiectrii detaliate a fost implementat corect n
cod.

Similar, testarea sistemului verific dac toate elementele

proiectrii sistemului sunt corect implementate.

Testarea de acceptare verific dac toate cerinele clientului au

fost implementate.

Dac se gsete o problem n timpul verificrii i validrii,

atunci se execut din nou etapa corespunztoare din
ramura din stnga a modelului pentru a elimina problema
aprut.

Modelul incremental
Analiza
cerinelor
Livrare 1
Proiectare

Implementare

Instalare

ntreinere
Livrare 2

Proiectare

Implementare

Instalare

ntreinere

Livrare i
Proiectare

Implementare

Instalare

ntreinere

Modelul incremental

Modelul de dezvoltare
modelului n cascad

incremental

este

similar

Se identific cerinele sistemului i apoi se repet

activitile de dezvoltare la fiecare livrare nou
Modelul incremental pleac totui de la o presupunere
nerealist i anume aceea c att sistemul ct i
cerinele software rmn stabile


Este evident faptul c cerinele tind s evolueze datorit

schimbrilor tehnologice i a experienei

Prototipizarea

O problem general care apare la dezvoltarea unui program este s

ne asigurm c utilizatorul obine exact ceea ce vrea
Prototipizarea vine n sprijinul rezolvrii acestei probleme
nc din primele faze ale dezvoltrii, clientului i se prezint o versiune
funcionala a sistemului; aceast versiune nu este ntregul sistem,
ns este o parte a sistemului care cel puin funcioneaz
Prototipul ajut clientul n a-i defini mai bine cerinele i prioritile
Prin intermediul unui prototip clientul poate nelege ce este posibil i
ce nu din punct de vedere tehnologic
Prototipul, este de obicei produs ct mai repede stilul de
programare este de obicei (cel puin) neglijent; ns scopul principal al
prototipului este de a ajuta n fazele de analiz i proiectare i nu
folosirea unui stil elegant

Prototipizarea

List
revizuiri
prototip
revizuit

List
revizuiri

List
revizuiri

verificare
client/utilizator

Prototip
cerine
Cerine sistem (pot fi
informale sau incomplete)

Prototip
proiect

Prototip
sistem

Testare

Sistem livrat

Prototipizarea

Prototipuri:

de aruncat (throwaway)
scopul este exclusiv obinerea unei specificaii
nu se acord nici o importan stilului de programare i de lucru, punndu-se

accent pe viteza de dezvoltare

odat stabilite cerinele, codul prototipului este aruncat, sistemul final fiind
rescris (posibil chiar n alt limbaj de programare)

evoluionar
scopul este de a crea un schelet al aplicaiei care s poat implementa n

prim faz o parte a cerinelor sistemului

pe msur ce aplicaia este dezvoltat, sunt adugate noi caracteristici
scheletului existent
n contrast cu prototipul de aruncat, aici se investete un efort considerabil
ntr-un design modular i extensibil, precum i n adoptarea unui stil elegant de
programare

Prototipizarea

Avantajele prototipizrii

permite dezvoltatorilor s elimine lipsa de claritate

a specificaiilor
ofer utilizatorilor ansa de a schimba
specificaiile ntr-un mod ce nu afecteaz drastic
durata de dezvoltare
ntreinerea este redus deoarece validarea se
face pe parcursul dezvoltrii
se poate facilita instruirea utilizatorilor finali
nainte de terminarea produsului

Prototipizarea

Dezavantajele prototipizrii

deoarece prototipul ruleaz ntr-un mediu artificial,

anumite dezavantaje ale produsului final pot fi scpate din
vedere de clieni
clientul nu nelege de ce produsul necesit timp
suplimentar pentru dezvoltare, avnd n vedere c
prototipul a fost realizat att de repede
deoarece au n fiecare moment ansa de a face acest
lucru, clienii schimb foarte des specificaiile
poate fi nepopular printre dezvoltatori, deoarece implic
renunarea la propria munc

Modelul n spiral

ncearc s rezolve problemele modelului n cascad,

pstrnd avantajele acestuia:

planificare
faze bine definite
produse intermediare

De asemenea, se poate folosi prototipizarea dac se

consider necesar
Modelul n spiral definete urmtorii pai n dezvoltarea
unui produs:

studiul de fezabilitate
analiza cerinelor
proiectarea arhitecturii software
implementarea

Modelul n spiral
Modelul n spiral recunoate c problema principal a dezvoltrii
programelor este riscul, acesta fiind acceptat, evaluat i
diminuat.
Exemple de riscuri:









cerine incomplete, vag formulate sau greit nelese;

schimbarea cerinelor clientului
personal neexperimentat, greit dimensionat, fluctuant;
estimri greite ale bugetului i orarului de livrare;
dependena de alte proiecte;
interfaare necorespunztoare;
subestimarea nivelului de dificultate;
lansarea unui program rival pe pia de ctre o firm concurent.

Modelul n spiral
Cost cumulativ

Evaluare alternative
(prin prototipuri)
Identificare i rezolvare riscuri

Determinare obiective,
alternative, constrngeri

Analiza risc (AR)

AR
AR
START

Plan
cerine

AR

PR

Concept

PR

Prototip (PR)

Prototip
operaional

Simulare, modele
Proiectare
Proiectare detaliat
software
Testare
uniti

Plan dezvoltare Validare

cerine
Integrare, Validare/verificare
Integrare i
plan testare software
Testare detestare
Implem. acceptare

Planificare faza urmtoare

Dezvoltare

Rational Unified Process (RUP)

Metod de management iterativ - conducerea unui

proiect pe baza evalurii periodice a obiectivelor i
replanificarea pe baza acestor evaluri.
Un management iterativ bun presupune:
 Luarea

n considerare a riscurilor nc din faza

incipient a proiectului;

 Utilizarea
 Evaluri

unei abordri intite pe arhitectura produsului;

obiective.

Rational Unified Process

Proces
iterativ

Modelul
Waterfall
 Bazat pe cerine

 Bazat pe arhitectur i componente

 Soluionare trzie a riscurilor

 Soluionare timpurie a riscurilor

Analiza
cerinelor

Proiectare Implement.
i testare
uniti

Integrare

Testare
sistem

Rational Unified Process

Procesul iterativ poate fi descompus n dou etape :

Etapa inginereasc (tehnic)
 Se dezvolt planuri, se stabilesc cerinele i arhitectura
sistemului, rezolvnd problema riscurilor ce pot aprea
la dezvoltarea proiectului.
 Se ncheie cu o arhitectural executabil de baz.
 Proiectarea este realizat de echipe de dimensiuni mai
mici.

Etapa de producie
 Se construiete o versiune utilizabil a n contextul
furnizat de etapa anterioar.
 Construcia, testarea i implementarea activitilor sunt
realizate de echipe de dimensiuni mai mari.

Rational Unified Process

RUP Diferene ntre etape

Aspecte din ciclul de
via

Etapa inginereasc

Etapa de producie

Reducere riscuri

Orar, fezabilitate
tehnic

Cost

Produse

Arhitectura de baz

Livrabil de baz

Activiti

Analiz, proiectare,
planificare

Implementare, testare

Evaluri

Demonstraii, inspecii,
analize

Testare

Economie

Rezolvarea creterii
costurilor

Exploatarea economiilor

Management

Planificare

Operaii

Rational Unified Process

Etapa inginereasc
Iniiere (Pornire)

Etapa de producie

Elaborare (Rafinare)

Construcie

Tranziie

timp
Milestone
Obiective

Milestone
Arhitectur

Milestone
Capabilitate
operaional iniial

Milestone
Livrare
produs

n ciclul de dezvoltare iterativ:



Fiecare faz descrie starea proiectului;

Fiecare faz are importana sa i include activiti n proporii diferite;

Faz: timpul dintre dou milestone-uri majore ale proiectului, de-a lungul
cruia sunt atinse obiective bine definite i sunt luate decizii de trecere sau nu
la faza urmtoare;

Produsul este implementat n principal n fazele de Elaborare i Construcie.

Rational Unified Process

Iniiere

Elaborare

Construcie

Tranziie

timp
Milestone
Obiective

Faza de Iniiere

Scop: echipa de dezvoltare stabilete obiectivele eseniale ale

proiectului.
Rezultate:


enumerare a cerinelor principale, posibil n form de cazuri de

utilizare;

imagine de ansamblu asupra arhitecturii programului;

descriere a obiectivelor proiectului;

un plan preliminar de dezvoltare.

Riscurile determinate de extragerea cerinelor trebuie identificate

nainte de pornirea proiectului

Rational Unified Process

Iniiere

Elaborare

Construcie

Tranziie

timp
Milestone
Arhitectur

Faza de Elaborare

Scop: se hotrte arhitectura programului, se stabilete echipa de

lucru, se elimin situaiile cu risc mare.
Rezultate:


un prototip evoluionar al arhitecturii programului;

teste care verific funcionarea programului;

cazuri de
sistemului;

utilizare

care

descriu

majoritatea

un plan de proiect detaliat pentru iteraiile urmtoare;

funcionalitilor

Rational Unified Process

Iniiere

Elaborare

Construcie

Tranziie

timp
Milestone
Capabilitate
operaional iniial

Faza de Construcie

Scop: adugarea cerinelor neimplementate nc i dezvoltarea

complet a sistemului.
Rezultate:


Programul propriu-zis;

Teste;

Manuale de utilizare.

Rational Unified Process

Iniiere

Elaborare

Construcie

Tranziie

timp
Milestone
Livrare
produs

Faza de Tranziie

Scop: programul este mbogit mai departe cu caracteristici, ns

accentul se pune pe mbuntirea i rafinarea celor existente pe baza
reaciilor de la client
Sfritul acestei activiti i a ntregului proces de dezvoltare are loc
atunci cnd:


Obiectivele propuse n cadrul fazei de pornire sunt ndeplinite;

Clientul este satisfcut.

Rational Unified Process

Iniiere

Elaborare

Construcie

Iteraie
preliminar

Iteraie
Iteraie
Arhitectur Arhitectur

Iteraie
Dezvoltare

Iteraie
Dezvoltare

Tranziie
Iteraie
Dezvoltare

Iteraie
Tranziie

Iteraie
Tranziie

Livrabile executabile

Un proiect bazat pe RUP evolueaz n pai numii iteraii.

Iteraia: Secven distinct de activiti bazate pe un plan stabilit i pe criterii de evaluare
din care rezulta un livrabil executabil (intern sau extern).


Reprezint punctul la care proiectul este evaluat i sunt realizate ajustrile necesare.

Livrabil: versiune stabil, complet i executabil a sistemului.

Scopul unei iteraii este s dezvolte un program funcional care s poat fi prezentat
clientului, iar clientul s l poat evalua.
ntinderea n timp a unei iteraii depinde de tipul de proiect la care se lucreaz, de
experiena echipei etc.

Este de preferat ca iteraiile s fie ct mai scurte.

Observaie: faza de iniiere poate s nu necesite un livrabil executabil

Rational Unified Process

Disciplinele i fazele RUP

Rational Unified Process

Aceste activiti nu sunt separate n timp (cum se presupune,

de exemplu, n cazul modelului n cascad)

Activitile sunt executate n paralel, pe parcursul ntregului

proiect

Cantitatea de cod scris la nceputul proiectului este mic, ns

nu zero

Pe msur ce proiectul evolueaz, cele mai multe dintre cerine

devin cunoscute, ns noi cerine sunt identificate: aceasta
nseamn c activitatea cerine se regsete pe ntreaga durat
de via a procesului, ns apare cu pregnan la nceputul
acestuia

Pe msur ce procesul de dezvoltare evolueaz, importana

anumitor activiti scade sau crete, ns este permis ca aceste
activiti s se execute la orice moment al dezvoltrii

Rational Unified Process

Aplicaii ale ciclului de via iterativ

Produce livrabile n fiecare iteraie



Identic scenarii de realizat sau de refcut pe baza riscurilor celor mai

mari ale proiectului
Atribuie taskuri clare echipei pentru a putea ndeplini condiiile de
livrare. Pentru atribuirea taskurilor se folosesc Cazurile de Dezvoltare
descriu procesul de dezvoltare al proiectului. Dac acesta nu este
realizat, atunci managerul de proiect trebuie s determine:



Livrabile interne i externe

Taskurile pentru echipa de dezvoltare

Relaiile care exist ntre taskuri si artefacte

Stabilirea de jaloane i puncte de analiz adecvate

Foreaz nchiderea unei iteraii prin integrare i livrare a livrabilelor

executabile

Rational Unified Process

Fiecare livrabil trebuie marcat de:



Creterea capabilitii, constnd n implementarea

funcionaliti suplimentare de-a lungul fiecrei iteraii

O profunzime mai mare, constnd ntr-o implementare mai

complet a produsului

O stabilitate mai mare, constnd n reducerea numrului de

schimbri ale produsului

O iteraie presupune:


Terminarea muncii planificate pentru iteraie

O evaluare a proiectului la sfritul fiecrei iteraii

unor

Rational Unified Process

Durata unei iteraii poate varia funcie de

obiectivele proiectului
 faza proiectului
n general, iteraiile din faza de Elaborare sunt mai mari dect iteraiile din faza de
Construcie.
n interiorul unei faze, iteraiile au n general aceeai lungime.


Numr total de iteraii

[I,E,C,T]

Mic

[0,1,1,1]

Tipic

[1,2,2,1]

Mare

[1,3,3,2]

Foarte mare

10

[2,3,3,2]

Pentru majoritatea proiectelor durata unei iteraii este ntre 1 lun i 2 luni.

Iteraiile mai mari de 6 sptmni au nevoie probabil de jaloane intermediare.



Reducerea obiectivelor unei iteraii duce la reducerea duratei i la o nelegere mai

clar a scopurilor.

Iteraiile mai mici de o lun trebuie planificate cu atenie. n general, iteraiile scurte sunt
mai convenabile n faza de Construcie unde gradul de includere de noi funcionaliti i
gradul de noutate sunt mici. Iteraiile scurte pot s nu necesite analiz formal i
proiectare.

Rational Unified Process

Condiii pentru creterea numrului de iteraii

Iniiere
Lucrul cu funcionaliti noi
Mediu necunoscut
Obiective cu grad mare de
volatilitate
Decizii make-buy
Construcie
Cantitate mare de cod de scris i
verificat
Tehnologii sau instrumente de
dezvoltare noi

Elaborare
Lucrul cu sisteme noi (caracteristici
arhitecturale noi)
Elemente arhitecturale netestate
Nevoia de prototipuri ale sistemului
Tranziie
Necesitatea unor variante alpha i
beta
Schimbarea clienilor
Livrare incremental ctre client

Rational Unified Process

Prima Iteraie

Prima iteraie este n general cea mai grea



Necesit participarea i consensul liderilor de proiect

Trebuie rezolvate problemele de integrare i de organizare a

echipei

Pentru a fi siguri de succes trebuie ca n prima iteraie s se

ncerce asigurarea unei minime funcionaliti. n caz contrar:


Terminarea primei iteraii va fi ntrziat

Va exista presiunea reducerii numrului

pierzndu-se avantajele abordrii iterative

de

iteraii,

Rational Unified Process

Strategii de iterare
Wide and Shallow

Se
analizeaz ntregul domeniu al
problemei dar se iau n considerare doar
detaliile de suprafa.


S
o
l
u

i
e

Se definesc n linii mari arhitectura sistemului i serviciile i

mecanismele cheie oferite de componentele arhitecturale.


Se definesc toate cazurile de utilizare i

majoritatea se completeaz la un nivel
de detaliu ridicat pentru o nelegere
exact a problemei.

Problem

Se definesc interfeele, dar detaliile interne se detaliaz doar dac

trebuie luat n considerare un risc.

Majoritatea iteraiilor - faza de Construcie

Rational Unified Process

Strategii de iterare
Problem

Narrow and Deep

Se analizeaz o poriune a domeniului

problemei


Cazurile de utilizare se definesc i se

completeaz n detaliu

S
o
l
u

i
e

Se definete arhitectura necesar asigurrii

comportrii dorite a sistemului
Se proiecteaz i se implementeaz sistemul
Iteraiile care urmeaz se focalizeaz pe analizarea, proiectarea i
implementarea domeniilor verticale suplimentare

Hibrid

Mixtur a strategiilor anterioare

Rational Unified Process

Profiluri ale riscului

Avantaj major al RUP: se iau n considerare la nceput riscurile majore

ale proiectului
Risc: Eveniment incert care are o probabilitate semnificativ de a
afecta succesul milestone-urilor majore.
Iniiere

Elaborare

Construcie Tranziie

Expunerea la risc

Mare

Mic

Profil risc proiect convenional (cascad)

Profil risc - proiect iterativ

Ciclul de via al proiectului

Rational Unified Process

Profiluri ale riscului

Dezvoltarea iterativ produce n primul rnd arhitectura sistemului,

deci:


Integrarea apare ca activitate de verificare a fazei de proiectare;

Defectele de proiectare sunt detectate i rezolvate la nceputul

ciclului de via.

Are loc o integrare continu, evitndu-se integrarea de tip big bang

la sfritul proiectului.
Permite o abordare mai bun a conceptului de calitate deoarece o
mare parte a caracteristicilor sistemului (performan, tolerana la
defecte) sunt tangibile la nceputul procesului


Problemele sunt corectate fr a periclita intele de cost i orarul

proiectului

Rational Unified Process

Diminuarea riscurilor prin dezvoltarea interativ

Dezvoltarea iterativ permite diminuarea a dou riscuri inerente proiectelor
software:
Modificarea cerinelor - obiectivele produsului (cerinele) se schimb pe
parcursul dezvoltrii proiectului.


Descriere:


Stakeholderii i utilizatorii i dau seama de ceea ce vor mai exact pe

msur ce studiaz specificaiile documentate.
Echipa se focalizeaz pe descoperirea obiectivelor pot aprea
obiective pe parcurs.
Dezvoltatorii realizeaz c nu pot satisface, d.p.d.v. economic, unele
cerine.

Strategie de diminuare a riscului:



Validarea frecvent a strii curente a cerinelor i a specificaiilor

produsului evaluri iterative
Ajustri frecvente al direciei proiectului astfel nct produsul s
satisfac cerinele stakeholderilor ajustri iterative ale obiectivelor
produsului

Rational Unified Process

Diminuarea riscurilor prin dezvoltarea iterativ

Nemulumirea stakeholderilor acetia nu sunt de acord cu produsul
livrat.


Descriere:


Stakeholderii descoper c produsul nu are unele dintre

caracteristicile cerute.

Strategie de diminuare a riscului:



Furnizarea unor pre-livrabile ale versiunilor produsului

prezentare iterativ
Stakeholderii trebuie s participe i s aprobe schimbrile n
specificaiile produsului implicarea iterativ

Metodologii Agile
Proces de dezvoltare rezistent la
schimbri

Metodele inginereti planific

procesul de dezvoltare software
n cele mai mici detalii

Se utilizeaz atunci cnd:

 Cerinele sunt stabile
 Tehnologia este bine cunoscut
i matur
 Totul se ntmpl dup ateptri
 Nu se ia n considerare nimic
nou i/sau necunoscut
 Au mai fost realizate astfel de
proiecte
Riscul de a le utiliza ntr-un
mediu dinamic este foarte
mare

Metodologii Agile
Metodologiile AGILE
 pregtite pentru schimbri metode adaptive
 orientate spre oameni mai degrab dect spre proces
 rolul proceselor este de a ajuta echipa de dezvoltare n a-i face
treaba










XP | Extreme Programming
DSDM | Dynamic System Development Method
FDD | Feature Driven Development
Scrum
Crystal Clear
Adaptive Software Development
Lean Software Development
RAD - Rapid application development
TDD - Test Driven Development

Metodologii Agile
Principiile AGILE



Inovare continu asigurarea cerinelor curente ale clientului

Adaptabilitatea produsului - asigurarea cerinelor viitoare ale
clientului
mbuntirea timpului de lansare pe pia ptrunderea pe
pia la timpul potrivit i mbuntirea rentabilitii investiiei
Adaptabilitatea personalului i a proceselor rspuns rapid la
schimbrile produsului i afacerii
Rezultate sigure asigurarea creterii i profitabilitii afacerii

Declaraia de Interdependen
www.apln.org

Manifestul AGILE
http://www.agilemanifesto.org

Metodologii Agile
Manifestul AGILE
1. Satisfacerea clientului este obiectivul prioritar al dezvoltrii unui
sistem software.
2. Schimbarea cerinelor este acceptat chiar n fazele trzii ale
dezvoltrii sistemului. Procesele Agile utilizeaz schimbrile n
avantajul competitiv al clientului.
3. Livrarea frecvent de software funcional, cu frecvena de livrare
sptmnal sau lunar, cu preferin pentru termene de livrare
ct mai reduse.
4. Stakeholderii i dezvoltatorii trebuie s lucreze mpreun n fiecare zi
la proiect.
5. Recunoaterea i exploatarea competenelor membrilor echipei de
dezvoltare. Echipa trebuie lsat s-i dezvolte modurile proprii de
lucru.
6. Cea mai eficient metod de a transmite informaiile spre i n
interiorul echipei de dezvoltare este discuia fa n fa.

Metodologii Agile
Manifestul AGILE
7. Scrierea programului este principalul scop al unui proiect software;
softul livrat este principala msur a progresului.
8. Procesele Agile promoveaz dezvoltarea susinut. Sponsorii,
dezvoltatorii i utilizatorii trebuie s fie capabili s colaboreze
indiferent de circumstane.
9. Softul se dezvolt incremental, clientul specificnd care sunt cerinele
ce trebuie incluse n fiecare increment.
10. Concentrare pe simplitate att n programele dezvoltate ct i n
procesul de dezvoltare. Oricnd este posibil, trebuie eliminat
complexitatea din sistem.
11. Cele mai bune specificaii, arhitecturi i modele de proiectare sunt
produse de echipele auto-organizate.
12. La intervale regulate de timp, echipa reflecteaz asupra
posibilitilor de mbuntire a eficienei i i ajusteaz
corespunztor comportamentul.

Metodologii Agile

Abordarea AGILE





Indivizi i interaciuni
Realizarea de soft
Colaborarea cu clientul
Receptivitate la schimbri

Lider AGILE




Valoare
Echip
Adaptare

Abordarea tradiional





Procese i instrumente
Documentaie cuprinztoare
Contract negociat
Urmrirea unui plan

Lider tradiional




Constrngeri
Taskuri
Conformare