Sunteți pe pagina 1din 10

Specializarea

„Sisteme informaţionale pentru afaceri”

1. Maloş Simona Elena


2. Mihai Catalin
Membrii echipei 3. Mocanu Andrei
4. Şpaiuc Andreea Alexandra
1. Rezumat

Modelul în spirală reprezintă o abordare realistă a dezvoltării sistemelor informatice


de dimensiuni mari. El foloseşte prototipul ca mecanism de reducere a riscului şi totodată
menţine abordarea sistematică a ciclului de viaţă clasic, încorporând-o într-un cadru iterativ
care reflectă lumea reală. Acest model, însă, este relativ nou şi nu a fost folosit pe scară largă
ca cel literar sau cel cu prototip. Va mai trece un timp până când eficenţa acestei noi
paradigme importante să poată fi determinată cu precizie.

2. Scurtă prezentare a modelului spirală

Modelul spirală este un model elaborat de Barry W. Boehm în 1988 pentru a descrie
tradiţionalul ciclu de viată al sistemelor informatice; de asemenea, el conţine o strategie a
managementului şi evaluări ale riscului. Modelul preia numele de la reprezentarea grafică în
formă de spirală, aşa cum apare în diagramă. B.W.Boehm s-a ocupat de aşa-zisele modele
tradiţionale încă din anul 1981, iar din 1986 anunţă modelul spirală şi publică rezultatele
cercetării în 1988. El se bazează pe doua convingeri:
 natura iterativă a dezvoltării şi nevoia de planificare şi evaluare a riscurilor fiecărei
iteraţii;

 deficienţa înregistrată la modelul V, în care validarea se efectuează prea tarziu, îl face


să propună realizarea acesteia cât mai devreme posibil, de cât mai multe ori, prin
construirea prototipurilor.

3. Prezentarea detaliată a modelului spirală pe etape şi activităţi de programare


specifice

Modelul spirală este un model care presupune o dezvoltare incrementată folosind modelul
cascadă (“waterfall”) pentru fiecare pas, cu scopul de a controla riscurile. În modelul spirală,
programatorii definesc şi implementează caracteristicile în ordinea descrescătoare a
priorităţilor.
Modelul spirală, se bazează pe acelaşi principiu ca şi modelul evolutiv. Modelul
presupune construirea mai multor prototipuri succesive în condiţiile realizării unei analize a
riscului pe fiecare nivel. Fazele de dezvoltare sunt reluate la fiecare iteraţie în aceeaşi
succesiune şi presupun:
 Analiza riscurilor
 Realizarea unui prototip
 Simularea şi testarea prototipului
 Determinarea cerinţelor în urma rezultatelor testării
 Validarea cerinţelor
 Planificarea ciclului următor
Ultimul ciclu conduce la realizarea versiunii finale a sistemului informatic.
În centrul spiralei este plasată cunoaşterea cerinţelor şi estimarea costurilor la nivel
preliminar.
Evoluţia SI urmează desfăşurarea spiralei înregistrând acumulări succesive ale
costurilor şi este marcată de succesiunea prototipurilor, fiecare dintre acestea valorificând
acumulările realizate la nivelul prototipului anterior. Interacţiunea dintre faze nu este reliefată
direct atâta timp cât modelul prevede o succesiune continuă a rafinării legate de decizii pe
care riscurile proiectului le asociază cu următoarea detaliere.
Modelul evidenţiază atenţia acordată planificării, căutării de soluţii alternative,
evaluării riscurilor şi validării soluţiilor pentru fiecare prototip, văzut ca un stadiu distinct în
realizarea sistemului informatic.
În ingineria software, un prototip este folosit atât pentru validarea cât şi pentru
identificarea cererilor utilizatorilor, pentru verificarea soluţiei de proiectare şi a oferi baza
dezvoltării ulterioare a proiectului de sistem informatic. Apelarea la utilizarea prototipului
este consecinţa faptului că un model funcţional este mai uşor de înţeles de către viitorul
utilizator decât un set de diagrame însoţite de documentaţie.
Fig. 1. Modelul în spirală1
Prototipul funcţional presupune proiectarea sistemului, realizarea primului prototip
funcţional, verificarea măsurii în care răspunde cererilor formulate de utilizator şi rafinarea
acestei prime soluţii, prindezvoltări viitoare care adaugă noi funcţionalităţi până la obţinerea
variantei finale a sistemului. Modelul a fost îmbunătăţit de R.G.Williams, R.F.Wirfs-Brock.
B.Henderson-Sellers şi J.M. Edwards care spun că deşi este descris ca o spirală, el este, de
fapt, o descriere liniară, în care unele activităţi pot fi reluate. Ivar Jacobson îl îmbunătăţeşte,
în 1990, prin modelul spirală ierarhic şi Rumbaugh, în 1992, prin modelul vârtej de apă
(whirlpool-like).
În varianta Boehm, echipa de dezvoltare şi utilizatorii se angajează treptat în proiect,
diminuând riscurile la nivel de prototip. De asemenea, de bun augur este valorificarea
experienţei anterioare în planificarea activităţilor din prototipul următor. Facem menţiunea că
modelul cascadă se va regasi în fiecare iteraţie. Aşadar, după cunoaşterea cerinţelor şi

1
Sursa Oxford Dictionary of Computing
efectuarea studiilor de fezabilitate, se realizează sistemul, se integrează şi instalează printr-o
singură livrare în varianta modelului cascadă.
Dintre avantajele modelului, în afară de posibilitatea evaluării riscurilor în diferite
momente, ar mai fi de amintit :
- simplificarea operaţiunilor de evaluare a ceea ce este necesar în etapa urmatoare,
inclusiv prin prisma costurilor,
- încurajarea prototipizării
- minimizarea specificaţiilor elaborate inutil,
- riscul scăzut în realizarea greşelilor
- bun suport al clientilor, control managerial
- concentrare pe asigurarea calităţii
- concentrarea pe componentele realizate
- concentrarea pe eliminarea neregulilor apărute la început.
Printre dezavantaje, menţionăm:
- nesiguranţa clienţilor
- necesitatea de cunoştinţe în domeniul asigurării riscurilor.
Nu ca dezavantaje, ci mai dregrabă ca elemente ce condiţionează folosirea modelului,
putem încadra profesionalismul echipei de dezvoltare şi flexibilitatea în acţiune, inclusiv în
alocarea de fonduri, dar şi în definirea activităţilor de întreprins.

Fig. 2 Modelul spirală pe activităţi


Cele patru cadrane reprezintă patru perioade standard pentru fiecare ciclu :
- pregătirea
- minimizarea riscului
- dezvoltarea
- planificarea
Principalele activităţi ale primelor doua cadrane (pregătirea şi gestiunea riscului) sunt :
- stabilirea obiectivelor ;
- determinarea alternativelor şi a restricţiilor ;
- obţinerea informaţiilor pentru evaluarea riscurilor prin: prototipizare, simulare,
evaluare, verificarea referinţelor, modelare
- alegerea celor mai bune alternative.

Principalele activităţi ale cadranelor 3 şi 4 (dezvoltare şi planificare) sunt :


- dezvoltarea ciclului de viaţă al produsului bazat pe riscuri ;
- stabilirea continuităţii şi planificarea următorului nivel ;
- alocarea resurselor ;
- câştigarea încrederii

3. Elemente de asigurare a calităţii software în cadrul modelului de elaborare

ASIGURAREA CALITĂŢII – Ansamblul activităţilor planificate şi sistematice


implementate în cadrul sistemului şi modelului de asigurarea calităţii şi demonstrate atât cât
este necesar, pentru furnizarea încrederii corespunzătoare că o entitate va satisface condiţiile
referitoare la calitate. Pentru a fi eficientă asigurarea calităţii implică, o evaluare permanentă a
factorilor care influenţează gradul de comparare a proiectului sau specificaţiilor cu aplicaţiile
prevăzute, precum şi verificări şi audituri ale operaţiilor de producţie, montaj şi inspecţie. “A
da încredere” poate implica furnizarea de dovezi
Calitatea tinde sa devină unul din cuvintele cheie ale succesului economic în lumea de
azi. În esenţa sa demersul pentru calitate este simplu. Trebuie sa ne concentram nu asupra
produsului ci asupra proceselor si sa le îmbunatatim. Problema software-ului nu deriva numai
din complexitatea sa ci si din natura sa abstractă. Calitatea sa poate fi controlata prin creşterea
"vizibilităţii" paşilor intermediari ai proceselor.
Abordarea calităţii în software pune un mare accent pe fazele timpurii ale elaborării
produsului cum ar fi captarea specificaţiilor care ajung să ocupe 40% din întregul proces.
Acestea faze preliminare sunt cele mai puţin înţelese dar între ele cea mai ignorată şi
paradoxal cea mai importantă pe zi ce trece este cea a inovării.
O altă cerinţă a QA este orientarea pe proces şi nu pe produsul final. Fiecare proces şi
subproces este analizat, schematizat şi îmbunătaţit. Creativitatea şi inovaţia este în cadrul
procesului proiectării din ce în ce mai necesar de a fi definită şi formalizată pentru a fi
îmbunătăţită. şi un rol important, daca nu în definirea, măcar în problematizarea acestui
proces l-a avut "Ingineria Software" care a inclus procesul creator în descrierea procesului
dezvoltării produselor program.

4. Analiza gradului de implicare a unităţilor/ grupurilor de testare în activităţile


şi etapele modelului.
Modelul în spirală poate descrie cum un produs se dezvoltă pentru a forma o noua
versiune şi cum o nouă versiune se dezvoltă incremental de la un prototip la un produs
complet.

Fig. 3 Modelul în spirală


Modelul propune aceleaşi etape de realizare, dar fiecare ciclu de dezvoltare începe
prin studiul de fezabilitate, apoi continuă cu specificarea cerinţelor şi analiza, proiectarea şi
implementarea.
Pe de altă parte fiecare din etapele amintite anterior se realizează printr-o succesiune
de activităţi:
- determinarea obiectivelor etapei, a alternativelor şi restricţiilor;
- evaluarea alternativelor, identificarea riscurilor şi rezolvarea lor;
- dezvoltarea şi verificarea următorului nivel al produsului;
- întocmirea planului urmatoarei etape, ales pe baza riscurilor.
Atât etapele cât si activitatile lor componente sunt evaluate având drept criteriu de
baza costurile implicate.
Modelul în spirală are următoarele caracteristici:
- conţine aproape toate caracteristicile celorlalte modele;
- celelalte modele pot fi considerate sau sunt cazuri particulare ale acestuia;
- evaluează riscurile oricarei abordari în toate etapele de dezvoltare a produselor software, iar
pe baza acestora alege abordarea corectă.
Dezvoltarea produselor software conţine în mod uzual toate fazele şi activităţile
prezentate anterior, chiar dacă ele poartă diferite nume în diferite metodologii şi dezvoltarea
decurge incremental pe parcursul acestor etape, scenariu de dezvoltare care se poate aplica
indiferent de metoda de realizare utilizată. Putem caracteriza dezvoltarea produsului ca
pornind iniţial dintr-o fază nebuloasă, dar care se stabilizează în următorii paşi în subsecvenţe.
Metodele de dezvoltare trebuie să ajute ca procesul de dezvoltare să fie stabil pe cât posibil.
Se presupune că trebuie lucrat în etapa de analiză până când se va înţelege sistemul în
totalitate, dar nu atât de mult încât să considerăm detaliile care vor fi modificate pe parcursul
proiectării.
Acest lucru poate însemna că cea mai mare durată este alocată analizei, ceea ce este valabil în
unele modele de implementare a ciclului de viaţă prezentate anterior, cu variaţii de la un
model la altul.
O împarţire a timpului alocat etapelor proiectului precum şi a relaţiei timp/efort pe
etape se poate reprezenta ca în figura.
Fig. 4 Diagrama efort - timp
Iniţial un grup redus de persoane efectuează analiza şi proiectarea. Aceste activităţi se
realizează iterativ. Cu cât structura sistemului se stabilizează, un numar mai mare de oameni
sunt antrenaţi în implementare şi testare. De obicei activităţile de analiză şi proiectare sunt
clarificate atunci când începe testarea, deoarece în acest stadiu nu sunt posibile decât puţine
modificări în ceea ce s-a realizat în etapa de analiză şi proiectare.
Dezvoltările din ultimii ani în domeniul tehnologiei informaţiei, mai ales în cel al
metodelor şi tehnicilor de realizare a produselor software precum şi în cel al instrumentelor
care asistă acest proces în toate etapele sale, au facut posibile noi abordari ale ciclului de
viaţă. Procesul de dezvoltare a sistemelor de informaţii şi a produselor software, văzut ca un
proces industrial, presupune, asa cum s-a amintit anterior, existenţa unor principii, procese şi
practici ale ingineriei sistemelor, aplicaţiilor şi produselor program. Toate acestea sunt
asigurate prin existenţa unor instrumente software - suport de dezvoltare.
Implementând metodologiile de realizare bazate pe structura funcţională sau pe
structura datelor şi/sau metodologiile orientate obiect, instrumentele pentru inginerie software
asistată de calculator permit construirea, verificarea, validarea, stocarea şi reutilizarea
diferitelor modele componente ale aplicaţiilor şi produselor program.
Asigurând dezvoltarea, începând de la modelele de analiză-proiectare şi până la
generarea automată de cod pentru modele, aceste produse pentru inginerie software asigură
din punct de vedere calitativ produsele realizate şi permit respectarea şi/sau reducerea
termenelor de livrare a produselor.
În ceea ce priveşte costurile, pentru a închide triunghiul amintit, calitate-termene-
costuri, e greu de realizat o evaluare globală, acest lucru fiind posibil doar în fiecare caz
concret şi la un anumit moment de timp prin balansarea intereselor firmei elaboratoare de
software cu cerinţele şi costurile pieţei de software la un moment dat.

6. Concluzii

Modelul “spirală”, aparţinând aceluiaşi Boehm (1986), are ca principal scop


scurtarea perioadei de timp între formularea cerinţelor de către utilizator şi producerea unui
sistem util cu care fiecare utilizator poate interacţiona.
Modelul spirală s-a dezvoltat pentru a compensa cele mai bune caracteristici ale
ciclului clasic de viata (modelul cascadă) şi prototipuri, în acelaşi timp aducând un nou
element, analiza riscului, care lipsea paradigmelor precedente.
Cu fiecare iteraţie, în jurul spiralei (începând din centru şi mergând spre exterior),
progresiv, versiunile complete ale software-ului sunt construite.
Paradigma modelului spirală pentru inginerie software este momentan ceea mai
realistă aproximare a dezvoltării pe scara largă a sistemelor software-ului.
Modelul evidenţiază atenţia acordată planificării, căutării de soluţii alternative,
evaluării riscurilor şi validării soluţiilor pentru fiecare prototip, văzut ca un stadiu distinct în
realizarea sistemului informatic.

Bibliografie
1.Oprea, D., Meşniţă, G., Dumitriu, F. - Analiza sistemelor informaţionale, Editura
Universităţii "Alexandru Ioan Cuza" Iaşi, 2006
2. Boehm, B.W. – “A Spiral Model of Software Development and Enhancement”, in IEEE
Computer, 21(5), 1988
3. http://silviuonline.8k.ro/
4. http://www.armyacademy.ro/buletin/articole/
5. http://ti.stupizii.ro/an2/sem1-paradigme-de-programare/
6. http://www.stsc.hill.af.mil/crosstalk/2001/05/boehm.html
7. http://www.cs.usu.edu/~supratik/CS%205370/r5061.pdf
8. http://sunset.usc.edu/publications/TECHRPTS/1998/usccse98-512/usccse98-512.pdf