Modelarea - Notiunea de modelare, Modelul Cascada, Modelul V, Modelul Incremental, Modelul Spirala, Extreme Programming



Modelarea



Notiunea de modelare

Modelul Cascada

Modelul V



Modelul Incremental

Modelul Spirala

Extreme Programming



Obiective:

a.     Intelegerea notiunii de modelare

b.    Aprofundarea modelului V.

c.     Aprofundarea modelului Incremental

d.    Aprofundarea modelului Spirala.

e.     Aprofundarea modelului Extreme Programming.


Recomandari privind studiul:

Studierea modelelor prezentate in vederea utilizarii lor pe parcursul celorlalte capitole. Asimilarea conceptelor de baza legate de modele si de tipurile de modele care sunt necesare in capitolele urmatoare



Rezultate asteptate:

Studentii trebuie sa fie capabili sa isi prezinte cunostintele teoretice de natura coerenta si consistenta.

Studentii trebuie sa poata prezenta orice model studiat.


Intrebari:

a.     Ce este un model?

b.    Prezentati modelul V.

c.     Prezentati modelul Incremental

d.    Prezentati modelul Spirala.

e.     Prezentati modelul Extreme Programming.

f.      Realizati o paralela intre oricare doua tipuri de modele si prezentati argumente pro si contrarea in favoare autilizarii unuia sau celuilalt.



Modelarea


Modelarea: metoda utilizata in stiinta si tehnica constand in reproducerea schematica a unui obiect sau sistem sub forma unui sistem similar sau analog in scopul studierii proprietatilor si transformarilor sistemului original.


Modelarea informatiilor = Obiecte + Atribute + Relatii + Supertipuri/Subtipuri +Obiecte asociative.


Modelul Cascadei


  1. Cum a aparut Modelul Cascadei

Modelul cascada este considerat ca fiind primul model introdus si folosit pe scara larga in ingineria soft. Inovatia introdusa de acest model consta in impartirea pentru intaia oara, a procesului de dezvoltare a programelor, in faze distincte.

Modelul cascada impune o abordare sistematica, secventiala, a dezvoltarii softului, abordare care porneste de la sistem si parcurge etape de analiza, proiectare, programare, testare si intretinere. Modelul are in vedere intregul ciclu de viata al produsului, exista evaluari pentru fiecare etapa si posibilitati de revenire la etape sau de reluare a ciclului de viata, intr-o faza de evolutie ulterioara.

Originea termenului “cascada” o g asim intr-un articol publicat in anul 1970 de catre W.W. Royce. Partea interesanta este ca Royce propunea in acel articol o abordare iterativa a dezvoltarii softului si nici macar nu a folosit termenul de “cascada”, el descriind ceea ce azi cunoastem ca fiind modelul “cascada” ca fiind o metoda riscanta un adevarat “magnet” pentru erori. In ciuda intentiilor lui Royce de a modifica modelul cascada intr-un model iterativ, utilizarea sa ca un proces pur secvential este inca populara, iar pentru unii “modelul cascada” a ajuns sa defineasca orice abordare inflexibila si non-iterativa de dezvoltare a produselor software. Majoritatea acestor persoane vad “modelul cascada” ca fiind naiv si nepotrivit pentru procesele din “lumea reala”, si totusi nu este chiar asa.


  1. Fazele Modelului Cascada

DEFINIREA SI ANALIZA CERINTELOR

 







Modelul Cascadei („The Waterfall Model”)



1. Definirea si analiza cerintelor (Requirement Analysis & Definition Toate cerintele sistemului care trebuiesc indeplinite sunt colectate in aceasta faza. Ca si in alte modele de procese, cerintele sunt impartite in cerinte functionale si constrangeri pe care sistemul trebuie sa le respecte. Cerintele trebuie sa fie colectate prin analiza nevoilor clientului si verificarea lor pentru a fi valide si posibile de implementat. Scopul este generarea Documentului de Specificatie a Cerintelor care este utilizat ca si input pentru urmatoarea faza.


2. Design-ul sistemului (
System Design Sistemul trebuie sa fie bine descris inainte ca implementarea sa inceapa. Aceasta implica un design arhitectural care defineste si descrie principalele parti si componente ale sistemului, ale interfetei si interactiunilor. Cu aceasta hardware-ul necesar este definit si software-ul este impartit pe componente.  Aceasta implica definirea sau selectia unei platforme, unui sistem de operare, a altor componente hardware periferice, etc. Componentele software trebuie sa fie definite astfel incat sa intalneasca nevoile clientilor. Scopul acestei faze este de a genera un Document pentru Arhitectura Sistemului (System Arhitecture Document) care sa serveasca ca si input pentru faza de design software a dezvoltarii, dar si ca input pentru design-ul hardware sau selectia activitatilor. De obicei in aceasta faza unele documente sunt generate, unul pentru fiecare disciplina, astfel incat software-ul va primi un document cu arhitectura software.


3. Design-ul Software (Software Design Bazat pe arhitectura sistemului care a definit principalele parti software, design-ul software le va imparti in module de cod. Vor fi descrise interfetele si interactiunile modulelor precum si functionalitatile lor. Toate modurile sistemului (startup, shutdown, conditiile de eroare si diagnosticul) trebuie sa fie luate in considerare dar si activitatea si starile acestuia trebuiesc definite. Output-ul acestei faze este un Document de Design Software care este si baza implementarii ce urmeaza a fi facuta.


4. Implementarea (Codarea=Coding Bazata pe Documentul pentru Arhitectura Sistemului munca este de a seta modulele sau unitatile definite si astfel procesul de codare incepe. Sistemul este in primul rand dezvoltat din parti mici numite unituri. Ele sunt independente, din punct de vedere functional si sunt integrate apoi in pachetul software complet.


5. Integrarea si Verificarea Software (Software Integration & Verification Fiecare unitate este prelucrata independent si poate fi testata pentru functionalitatea sa. Aceasta se numeste Testarea Unitatii. Aceasta doar verifica daca modulele sau uniturile se incadreaza in specificatii. Aceasta implica teste functionale la nivel de interfata a modulelor, dar si teste mai detailiate in structura interna a modulelor software. In timpul integrarii, uniturile care sunt prelucrate si testate pentru functionalitatile lor sunt combinate. Modulele sunt integrate intr-un sistem complet si sunt testate pentru a vedea daca toate functioneaza conform previziunilor.


6. Verificarea Sistemului (System Verification Dupa ce s-au obtinut rezultatele bune la teste asupra sitemului complet acestea se confrunta cu cerintele initiale. Aceasta va include hardware-ul si mediul original.


7. Operarea si mentinerea (Operation & Maintenance Sistemul este predat clientului care il va utiliza pentru prima data. Clientul va verifica daca cerintele lui au fost implementate dar si daca acestea sunt cele initiale. In cazul in care trebuie sa se faca schimbari se vor face astfel incat sistemul sa fie utilizabil si sa indeplineasca dorintele clientului.




  1. Avantaje si Dezavantaje

Avantaje:

  • Controlul total asupra fazelor
  • Usor de insusit de catre membrii echipei de proiectare
  • Fiecare faza este insotita de o documentatie completa

Dezavantaje:

  • Sistemul poate fi predat dupa parcurgerea etapelor, deci necesita mult timp de lucru
  • Nu corespunde intentiilor de abordare dinamica
  • Nu este deschis schimbarilor ce apar pe parcurs
  • Este intr-o contradictie flagranta cu procesul liber, prin incercari, care este adesea vital pentru rezolvarea creativa a problemelor


  1. Modele Cascada modificate.

Ca raspuns la problemele modelului cascada “pur” au fost introduse o serie de  modele cascada modificate menite sa inlature o parte din criticile aduse modelului original.

Aceste modele modificate folosesc aceleasi faze ca si modelul cascada pur, insa nu intr-un mod discontinuu. Acest fapt permite ca unele faze sa se suprapuna ori de cate ori este necesar. O alta functionalitate noua introdusa de aceste modele o constituie posibilitatea impartirii modelului pe mai multe subproiecte dupa o anumita faza.

Exemple de modele cascada modificate:

Modelul “sashimi”

Denumit asa deoarece suporta suprapunerea fazelor, asemenea pestelui japonez sashimi, a fost initiat de catre Peter DeGrace, si de cele mai multe ori este denumit simplu: “modelul cascada cu faze suprapuse” sau “modelul cascada cu feedback”. Deoarece fazele acestui model se suprapun descoperirea si tratarea erorilor este mai usoara si se poate realiza in cadrul fazelor modelului cascada.

Cascada cu prototipuri (Prototyping waterfall)

Acest model se bazeaza pe crearea unui sistem de exemple, prototipuri, care sa ajute la descoperirea rapida a erorilor. Un dezavantaj al acestui model il constituie faptul ca crearea unui astfel de prototip necesita un timp destul de indelungat.

Cascada cu borne (Milestone waterfall)

Presupune crearea aplicatiilor pe mai multe faze, versiuni, in fiecare faza introducandu-se cate o functionalitate cheie. Acest model este excelent pentru demonstrarea conceptelor in cazul folosirii unor tehnologii noi, reduce considerabil riscurile prin introducerea functionalitatilor cu cel mai mare grad de risc in primele versiuni.

Alte modele alternative

Modelul cascada cu subproiecte si modelul cascada cu reducerea riscurilor sunt alte versiuni de modele cascada modificate. In unele privinte chiar si modelul spirala poate fi privit ca un model cascada cu iteratie.



  1. Argumente Pro si Contra

Argumente pro modelul in cascada.


Timpul petrecut in primele faze ale productiei de software poate duce la o mai mare economie in cadrul ciclului de viata al unui produs soft. Este de preferat sa depistam si sa reparam o eroare in primele faze ale ciclului, decat mai tarziu. McConnell estimeaza ca un defect in faza de specificatie a cerintelor nedetectabil pana in faza de implementare sau de mentenanta costa de 50 pana la 200 de ori mai mult decat ar fi costat in faza de specificare a cerintelor.


Unul dintre principalele argumente pe care le au sustinatorii acestei metode este faptul ca este mai usor de schimbat proiectul in cadrul fazei de proiectare decat sa asteptam luni de zile si sa vedem ca ce am lucrat trebuie refacut datorita unui design gresit.


Unii specialisti prefera acest model pentru simplitate si pentru faptul ca prezinta o abordare mai structurata, progresand liniar prin faze usor de inteles. Datorita acestui fapt, modelul in cascada este folosit ca exemplu de inceput in multe carti si cursuri de inginerie soft.


Modelul in cascada este folosit de o multime de companii de mare anvergura ca de exemplu Departamentul de defensiva al SUA sau NASA in cadrul proiectelor de cercetare sau pentru alte scopuri.


Argumente contra modelului in cascada.


Modelul cascada este contestat de unii specialisti ca fiind greu de realizat in mod practic, pentru ca este imposibil sa realizezi perfect o faza a ciclului de viata al unui produs software pentru a putea trece ulterior la urmatoarea. De exemplu, clientii nu stiu intodeauna exact  ce au nevoie inainte de a vedea un prototip functionabil al programului. De asemenea, acestia pot sa schimbe in orice moment cerintele sau sa doreasca altceva, astfel incat programatorii si analistii nu au control deplin asupra situatiei, ei depinzand de client. Daca schimbam cerintele dupa ce am terminat faza de proiectare vom fi nevoiti sa refacem proiectarea din nou.


Ideea ce sta la baza modelului cascade este „masoara de doua ori si taie o data”. Cei ce se opun modelului sustin ca ideea nu este buna datorita faptului ca cerintele problemei „masurate” se schimba constant datorita modificarilor de cerinta sau a altor factori.


Principalele critici aduse acestui model sunt :


multe programe software sunt supuse modificarii datorita factorilor externi (ex. clienti) astfel incat acestea trebuie sa fie adaptabile nevoilor acestora;

daca analistii si programatorii nu sunt foarte competenti este dificil de a stii  exact de ce este nevoie in fiecare faza de dezvoltare a programelor, fiind necesar feed-back de la fazele superioare pentru a putea rezolva cerintele de la fazele inferioare;

este dificil de estimat timpul si costurile necesare pentru fiecare faza de dezvoltare;

este o pierdere de resurse de a avea doar personal specializat sa rezolve anumite sarcini legate de exemplu  de implementare, care sa nu faca nimic in timpul fazei de proiectare.


Alte modele


1. Modelul V

Modelul V este o varianta a modelului cascada, prin care se introduc conceptele de sistem si componente (subsisteme), aplicandu-se teste explicite la un sistem ierarhic pentru cresterea controlului asupra modului in care se desfasoara etapele.

Tocmai aceasta inlesnire constituie o latura a literei V. Prima este latura din stanga, parcursa descendent, si contine treptele propriu-zise, iar cea de-a doua latura, din dreapta, se parcurge ascendent, pe ea realizandu-se verificarile si validarile elementelor create anterior. Acest model puncteaza cu mai multa claritate separarile dintre ceea ce implica participarea utilizatorului, modelul arhitectural si cel al implementarii. Utilizatorul este implicat doar in fazele din partea superioara a V-ului.

Arhitectura sistemului este surprinsa in partea de mijloc a literei, iar partea inferioara a ei se refera la faze de implementare, care ar putea consta fie din asamblarea componentelor soft, fie din codificarea unor componente. Modelul se preteaza si in mediul orientat-obiect, deoarece incurajeaza prototipizarea, reutilizarea unor structuri superioare. El ofera un control puternic asupra sistemului in curs de realizare, prin structurile ierarhice si modulare pe care le promoveaza, ceea ce il face utilizabil si in cazul sistemelor complexe. Modelul devine si mai puternic daca promoveaza iteratia, adica reluarea unor faze, activitati sau subactivitati. De fapt, acesta este stilul adoptat de cei trei autori ai UML - (Booth, Jacobson si Rumbaugh), modelul iterativ-incremental, anuntat de anumite performante ale modelului V.

In cadrul acestui model se face, de asemenea, distinctie evidenta intre verificare si validare. Prima se refera la testarea sistemului, in diverse stadii ale lui, daca s-a construit corect din punct de vedere logic, in timp ce validarea va scoate in evidenta faptul ca sistemul, in forma lui finala, raspunde sau nu cerintelor initiale. Tocmai din aceasta cauza, i se reproseaza ca lasa validarea prea tarziu, dupa ce sistemul s-a construit, ceea ce il face ineficient. In forma lui consacrata, modelul ii apartine lui Ould, care il lanseaza in 1990, anumite forme fiind folosite si de Rumbaugh, inca din 1991. El utilizeaza doar latura din stanga V-ului, fazele descendente, in care un lot esential revine tratarii sistemului pe componente. Cea mai vadita preluare a filosofiei modelului V este regasita in modelul X (Hodgson).



2. Modelul incremental

Modelul incremental este o alta varianta a modelului cascada care promoveaza ideea proiectarii si realizarii independente a componentelor dupa definirea arhitecturii globale a sistemelor informatice.

Proiectarea si realizarea sistemelor informatice (SI) se face astfel in conformitate cu principiile metodelor top-down. Sistemul va putea fi livrat beneficiarului si structurat pe etape pe masura realizarii componentelor (in functie de prioritatile formulate de beneficiar) dar, intr-o astfel de abordare pot aparea dificultati legate de integrarea componentelor in sistemul final.





Din figura de mai sus se observa faptul ca primele doua etape – definirea cerintelor si analiza - sunt identice cu cele doua etape de inceput ale modelului cascada, insa din momentul definirii arhitecturii SI fiecare componenta isi urmeaza propriul ciclu de viata. Spre deosebire de modelul in V care presupune integrarea componentelor, testarea si validarea acestora, de aceasta data se ofera si posibilitatea livrarii independente a componentelor sistemului catre beneficiar fara a se exclude si posibilitatea livrarii sistemului final avand toate componentele integrate. Din descrierea de pana acum rezulta cateva dintre avantajele modelului:

*      se incadreaza in principiul arhicunoscut „divide et impera', prin posibilitatea abordarii unor parti ale intregului;

*      sistemul poate fi livrat si pe componente realizate la perioade scurte de timp;

*      proiectul sau sistemul final poate fi realizat de mai multe echipe sau persoane datorita modularizarii lui.

Dintre dezavantaje pot fi enumerate:

*      imposibilitatea aplicarii lui in toate cazurile, uneori neexistand elementele necesare descompunerii intregului;

*      componentele pot fi realizate numai dupa ce intregului sistem i se defineste arhitectura, totul derulandu-se dupa principiile metodelor top-down, ceea ce inseamna inca o conditie dura: cunoasterea si formularea cerintelor din faza incipienta de abordare a sistemului;

*      fiind posibil de realizat pe parti, eforturile de integrare a acestora in intreg sunt destul de mari, vorbindu-se chiar despre o asa-zisa testare multipla de sisteme, cu trimitere la faptul ca de fiecare data cand se adauga o noua componenta sistemul poate fi considerat unul nou.



3. Modelul spirala

Modelul spirala este lansat de unul dintre specialistii cu preocupari mai vechi legate de ciclul de viata, B.W. Boehm. Acesta s-a ocupat de asa-zisele modele traditionale inca din anul 1981, iar in 1986 anunta modelul spirala si publica rezultatele cercetarii sale in 198837. El se bazeaza pe doua convingeri:

*      natura iterativa a dezvoltarii si nevoia de planificare si evaluare a riscurilor fiecarei iteratii;

*      deficienta inregistrata la modelul V, in care validarea se efectueaza prea tarziu, il face sa propuna, dimpotriva, realizarea acesteia cat mai devreme posibil, de cat mai multe ori, prin construirea prototipurilor, conform modelului simplificat din figura .

Ciclul 1 – Analiza preliminara

1. Obiective, alternative, constrangeri

2. Analiza riscului si prototipul

3. Conceperea operatiilor

4. Cerintele si planul ciclului de viata

5. Obiective, alternative, constrangeri

6. Analiza riscului si prototipul

Ciclul 2 – Analiza finala

7. Simulare, modele, benchmark-uri

8. Cerinte software si validare

9. Plan de dezvoltare

10. Obiective, alternative, constrangeri

11. Analiza riscului si prototipul

Ciclul 3 – Proiectarea

12. Simulare, modele, benchmark-uri

13. Proiectarea produsului software, validare si verificare

14. Integrare si plan de test

15. Obiective, alternative, constrangeri

16. Analiza riscului si prototipul operational

Ciclul 4 – Implementarea si testarea

17. Simulare, modele, benchmark-uri

18. Proiectare detaliata

19. Cod

20. Integrarea unitatilor si testarea acceptarii

21. Lansarea produsului


Modelul este imbunatatit de R.G. Williams, R.F. Wirfs-Brock iar Ivar Jacobson il amelioreaza, in 1990, prin modelul spirala ierarhic si Rumbaugh, in 1992, prin modelul vartej de apa (whirlpool-like). In varianta Boehm, echipa de dezvoltare si utilizatorii se angajeaza treptat in proiect, diminuand riscurile la nivel de prototip. De asemenea, de bun augur este valorificarea experientei anterioare in planificarea activitatilor din prototipul urmator. Facem mentiunea ca modelul cascada se va regasi in fiecare iteratie. Deci dupa cunoasterea cerintelor si efectuarea studiilor de fezabilitate, se realizeaza sistemul, se integreaza si instaleaza printr-o singura livrare, in varianta modelului cascada.


Avantaje


*      Se bazeaza pe ideea perfectionarii incrementale ale metodologiei secventiale

*      Permite feedback-ul de la fiecare echipa in ceea ce priveste complexitatea sau corectitudinea cerintelor: exista etape in care pot fi corectate eventualele greseli

*      Clientul poate arunca o privire asupra rezultatului si poate oferi informatii importante mai ales in faza dinaintea lansarii produsului

*      Procesul de dezvoltare se poate adapta mai bine progresului tehnologic: pe masura ce apar noi solutii, ele pot fi incorporate in arhitectura produsului

*      Recunoaste ca problema principala a dezvoltarii programelor este riscul


Exemple de riscuri


*      In timpul unui proces indelungat de dezvoltare, cerintele noi ale clientului sunt ignorate

*      Clientul schimba cerintele

*      firma concurenta lanseaza un program rival pe piata

*      Un dezvoltator/arhitect paraseste echipa de dezvoltare

*      echipa nu respecta un termen de livrare pentru o anumita componenta


Dezavantaje


*      Fiecare ciclu produce un efort mai mare de munca pentru ciclul urmator, ceea ce incarca orarul planificat si poate duce la eliminarea unor functii sau la o calitate scazuta

*      Lungimea sau numarul de cicluri poate creste foarte mult

*      Scaderea responsabilitatii



*      Nu exista termene limita precise; ciclurile continua fara o conditie clara de terminare

*      Echipa de proiectare nu poate realiza o arhitectura completa

*      Echipa de implementare poate fi pusa in situatia nedorita in care arhitectura si cerintele sistemului sunt in permanenta schimbate


4. Extreme Programming

Extreme Programming = programare extrema

Metoda de programare „agila”, potrivita dezvoltarii rapide de aplicatii




Figura 4. Modelul XP



Principiile metodelor agile

l        Implicarea clientului

Clientul trebuie implicat pe tot parcursul procesului de dezvoltare. Rolul sau este de a fixa prioritatile, cerintele si de a evalua iteratiile sistemului

l        Livrarea incrementala

Programul este dezvoltat incremental, clientul indicand cerintele care trebuie incluse la fiecare iteratie

l        Oamenii nu procesul

Abilitatile echipei de dezvoltare trebuie recunoscute si exploatate. Echipa trebuie lasata sa-si contureze propriile modalitati de lucru, fara a i se da retete

l        Acceptarea schimbarii

Echipa trebuie sa se astepte ca cerintele sa se schimbe iar proiectarea sistemului trebuie facuta astfel incat sa se adapteze usor la aceste schimbari

l        Mentinerea simplitatii

Concentrare pe simplitate atat in programele dezvoltate cat si in procesul de dezvoltare. Oricand este posibil, trebuie eliminata complexitatea din sistem.


Problemele metodelor agile

l        Este dificila mentinerea interesului clientilor implicati in proces

l        Membrii echipei pot fi incapabili sa se adapteze la implicarea intensa caracteristica metodelor agile

l        Cand exista mai multi factori de decizie, este dificila prioritizarea schimbarilor

l        Mentinerea simplitatii necesita lucru suplimentar

l        Contractele pot fi o problema in cazul dezvoltarii iterative


XP considera ca dezvoltarea programelor nu inseamna ierarhii, responsabilitati si termene limita, colaborarea oamenilor din care este formata echipa. Acestia sunt incurajati sa isi afirme personalitatea, sa ofere si sa primeasca cunostinte.

XP considera ca dezvoltarea de programe inseamna in primul rand scrierea de programe, nu documente, sedinte si rapoarte.


Carta drepturilor dezvoltatorului

l       Ai dreptul sa stii ceea ce se cere, prin cerinte clare, cu declaratii clare de prioritate

l       Ai dreptul sa spui cat iti va lua sa implementezi fiecare cerinta, si sa iti revizuiesti estimarile in functie de experienta

l       Ai dreptul sa iti accepti responsabilitatile, in loc ca acestea sa-ti fie atribuite

l       Ai dreptul sa faci treaba de calitate in orice moment

l       Ai dreptul la liniste, distractie si la munca productiva si placuta


Carta drepturilor clientului

l       Ai dreptul la un plan general, sa stii ce poate fi facut, cand, si la ce pret

l       Ai dreptul sa vezi progresul intr-un sistem care ruleaza si care se dovedeste ca functioneaza trecand teste repetabile pe care le specifici tu

l       Ai dreptul sa te razgandesti, sa inlocuiesti functionalitati si sa schimbi prioritatile

l       Ai dreptul sa fii informat de schimbarile in estimari, suficient de devreme pentru a putea reduce cerintele astfel ca munca sa se termine la data prestabilita. Poti chiar sa te opresti la un moment dat si sa ramai cu un sistem folositor care sa reflecte investitia pana la acea data

l       Echipa de dezvoltare nu are o structura ierarhica; fiecare contribuie la proiect folosind maximul din cunostintele sale

l       Proiectul este in mintea tuturor programatorilor din echipa, nu in documentatii, modele sau rapoarte

l       Cerintele clientului sunt exprimate ca scenarii sau povestiri (“user stories”)

l       Acestea sunt scrise pe biletele iar echipa de dezvoltare le imparte in sarcini de implementare (care stau la baza planificarii orarului de lucru si a estimarii costurilor)

l       La orice moment, un reprezentant al clientului este disponibil pentru clarificarea cerintelor


Caracteristici

l       Scrierea de cod este activitatea cea mai importanta

l       La fiecare pas se face numai ce este absolut necesar in momentul urmator

l       Codul se scrie cat mai simplu si se optimizeaza (refactoring) de cate ori e posibil

l       Se scrie mai intai cod de test

l       Daca apare necesitatea rescrierii sau eliminarii codului, aceasta se face fara mila

l       Modificarile aduse codului sunt integrate continuu (de cateva ori pe zi)

l       Se programeaza in echipa (programare in perechi); echipele se schimba la sfarsitul unei iteratii (1-2 saptamani)

l       Se lucreaza 40 de ore pe saptamana, fara lucru suplimentar


Concluzii


Alegerea unei metodologii de dezvoltare trebuie sa tina seama de natura fiecarui proiect:


*      Bugetul

*      Marimea echipei

*      Tehnologia utilizata

*      Instrumentele si metodele

*      Termenele limita

*      Procesele existente deja













Copyright © Contact | Trimite referat


Ultimele referate adaugate
Mihai Beniuc
   - Mihai beniuc - „poezii"
Mihai Eminescu Mihai Eminescu
   - Mihai eminescu - student la berlin
Mircea Eliade Mircea Eliade
   - Mircea Eliade - Mioara Nazdravana (mioriţa)
Vasile Alecsandri Vasile Alecsandri
   - Chirita in provintie de Vasile Alecsandri -expunerea subiectului
Emil Girlenu Emil Girlenu
   - Dragoste de viata de Jack London
Ion Luca Caragiale Ion Luca Caragiale
   - Triumful talentului… (reproducere) de Ion Luca Caragiale
Mircea Eliade Mircea Eliade
   - Fantasticul in proza lui Mircea Eliade - La tiganci
Mihai Eminescu Mihai Eminescu
   - „Personalitate creatoare” si „figura a spiritului creator” eminescian
George Calinescu George Calinescu
   - Enigma Otiliei de George Calinescu - geneza, subiectul si tema romanului
Liviu Rebreanu Liviu Rebreanu
   - Arta literara in romanul Ion, - Liviu Rebreanu











Scriitori romani