curs_2_isp

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


Analiza cerinelor

Se stabilete ce anume vrea clientul ca programul s fac

Scopul este nregistrarea cerinelor ntr-o manier ct mai clar i mai fidel claritatea se refer la lipsa ambiguitii fidelitatea se refer la nregistrarea ct mai exact

(posibil cuvnt cu cuvnt)


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


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


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 programelorValidare 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)?


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

Proiectarea sistemului

Proiectarea detaliat

Testarea unitilor i testarea la integrare

Testarea sistemului

Testarea de acceptare

Operarea intreinerea

Scrierea codului

Modelul cascad (waterfall)

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

Modelul cascad

Modelul cascad cu reacie se poate influena rezultatul obinut ntr-un

stadiu precedent

Analiza cerinelor




Testarea sistemului



Scrierea codului

n modelul de dezvoltare n cascad lipsete conceptul de prototipizare

Prototipul este un produs dezvoltat parial care permite clientului i dezvoltatorilor s analizeze aspectele funcionale majore ale sistemului s decid dac sistemul propus este suficient de apropriat de cel cerut

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

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

Modelul cascad

Analiza cerinelor



Testarea unitilor i testarea la

integrare

Testarea sistemului



Scrierea codului

Prototipizare

Validare

VerificareModelul cascad

cu prototipizare

Modelul n V

Analiza cerinelor






Scrierea codului

Testarea sistemului

Verificare proiectare

Validare cerine

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

Modelul incrementalAnaliza

cerinelor

Proiectare Implementare ntreinereInstalareLivrare 1

Proiectare Implementare ntreinereInstalare

Proiectare Implementare ntreinereInstalare

Livrare 2

Livrare i

Modelul de dezvoltare incremental este similar modelului n cascad

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

Modelul incremental

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

Prototip cerine

Prototip proiect

Prototip sistem

Testare

List revizuiri

Sistem livratCerine sistem (pot fi informale sau incomplete)

List revizuiri

List revizuiri

prototip revizuit

verificareclient/utilizator

PrototipizareaPrototipuri:

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

Evaluare alternative(prin prototipuri)Identificare i rezolvare riscuri

Analiza risc (AR)

Determinare obiective, alternative, constrngeri

AR

ARAR

Simulare, modele

Prototip (PR)PR

PR

Prototip operaional

Proiectare detaliatTestare uniti

Integrare i testare

Implem.Testare de acceptare

Integrare, plan testare

Plan dezvoltare

Concept

Validare cerine

Proiectare software

Validare/verificaresoftware

Plan cerine

DezvoltarePlanificare faza urmtoare

Cost cumulativ

START

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 unei abordri intite pe arhitectura produsului;

Evaluri obiective.

Rational Unified Process

Analiza cerinelor Proiectare Implement.

i testare uniti Integrare Testare

sistem

Modelul Waterfall

Bazat pe cerine Soluionare trzie a riscurilor

Proces iterativ

Bazat pe arhitectur i componente Soluionare timpurie a riscurilor

Rational Unified ProcessProcesul 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 suntrealizate de echipe de dimensiuni mai mari.


RUP Diferene ntre etape

OperaiiPlanificareManagement

Exploatarea economiilorRezolvarea creterii costurilorEconomie

TestareDemonstraii, inspecii, analizeEvaluri

Implementare, testareAnaliz, proiectare, planificareActiviti

Livrabil de bazArhitectura de bazProduse

CostOrar, fezabilitate tehnicReducere riscuri

Etapa de producieEtapa inginereascAspecte din ciclul de via


timp

TranziieConstrucieElaborare (Rafinare)Iniiere (Pornire)Etapa de producieEtapa inginereasc

MilestoneObiective

MilestoneArhitectur

Milestone Capabilitate

operaional iniial

MilestoneLivrareprodus

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.


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

TranziieConstrucieElaborareIniiere

MilestoneObiective

timp


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 utilizare care descriu majoritatea funcionalitilor sistemului;

un plan de proiect detaliat pentru iteraiile urmtoare;


MilestoneArhitectur

timp


Faza de Construcie Scop: adugarea cerinelor neimplementate nc i dezvoltarea

complet a sistemului. Rezultate:

Programul propriu-zis; Teste;

Manuale de utilizare.


Milestone Capabilitate

operaional iniial

timp


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.


MilestoneLivrareprodus

timp


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

TranziieConstrucieElaborareIniiereIteraie Tranziie

Iteraie Tranziie

Iteraie Dezvoltare

Iteraie Dezvoltare

Iteraie Dezvoltare

Iteraie Arhitectur

Iteraie Arhitectur

Iteraie preliminar

Livrabile executabile


Disciplinele i fazele RUP


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


Aplicaii ale ciclului de via iterativ Produce livrabile n fiecare iteraie

Livrabile interne i externe

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:

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


Fiecare livrabil trebuie marcat de:

Creterea capabilitii, constnd n implementarea unor 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

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.

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.

[2,3,3,2]10Foarte mare[1,3,3,2]9Mare[1,2,2,1]6Tipic[0,1,1,1]3Mic[I,E,C,T]Numr total de iteraii

Condiii pentru creterea numrului de iteraii


Tranziie Necesitatea unor variante alpha i

beta Schimbarea clienilor Livrare incremental ctre client

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

Iniiere Lucrul cu funcionaliti noi Mediu necunoscut Obiective cu grad mare de

volatilitate Decizii make-buy


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 de iteraii,

pierzndu-se avantajele abordrii iterative


Strategii de iterareWide and Shallow Se analizeaz ntregul domeniu al

problemei dar se iau n considerare doar detaliile de suprafa. Se definesc toate cazurile de utilizare i

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

Problem

Soluie

Se definesc n linii mari arhitectura sistemului i serviciile i mecanismele cheie oferite de componentele arhitecturale. Se definesc interfeele, dar detaliile interne se detaliaz doar dac

trebuie luat n considerare un risc. Majoritatea iteraiilor - faza de Construcie


Strategii de iterareNarrow and Deep Se analizeaz o poriune a domeniului

problemei Cazurile de utilizare se definesc i se

completeaz n detaliu 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

Problem

Soluie


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.

E

x

p

u

n

e

r

e

a

l

a

r

i

s

c

Ciclul de via al proiectuluiMic

Mare

Profil risc proiect convenional (cascad)

Iniiere Elaborare Construcie Tranziie

Profil risc - proiect iterativ


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 bangla sfritul proiectului.

Permite o abordare mai bun a conceptului de calitate deoarece omare 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 ProcessDiminuarea riscurilor prin dezvoltarea interativDezvoltarea 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


Diminuarea riscurilor prin dezvoltarea iterativNemulumirea 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

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

Proces de dezvoltare rezistent la schimbri

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

Abordarea tradiional

Procese i instrumente

Documentaie cuprinztoare

Contract negociat

Urmrirea unui plan

Lider AGILE

Valoare

Echip

Adaptare

Lider tradiional

Constrngeri

Taskuri

Conformare

Metodologii Agile

curs_2_isp

Documents