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
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.
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.
Avantaje:
Dezavantaje:
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.
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
