Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  


AccessAdobe photoshopAlgoritmiAutocadBaze de dateC
C sharpCalculatoareCorel drawDot netExcelFox pro
FrontpageHardwareHtmlInternetJavaLinux
MatlabMs dosPascalPhpPower pointRetele calculatoare
SqlTutorialsWebdesignWindowsWordXml

Modele de dezvoltare

calculatoare

+ Font mai mare | - Font mai mic



DOCUMENTE SIMILARE

Trimite pe Messenger
Istoria firmei Microsoft
Internet cu implicatii la proiectarea sistemelor
Lista serviciilor de ecran INT 10h
GLOBALIZAREA SI RISCUL SECURITATII INFORMATIILOR
Clase in OOP
Comunicarea si sincronizarea inter-proces
Criptarea
Informatica medicala in prelucrarea si analiza semnalelor si imaginilor
Cum functioneaza FrontPage
Aplicatii pentru prelucrat de texte


­­Modele de dezvoltare

Criza software si necesitatea modelelor de dezvoltare

“Atat timp cat nu au existat masinile de calcul programarea nu a reprezentat nici o problema; atunci cand aveam cateva calculatoare slabe programarea era o problema minora iar azi cand avem calculatoare gigantice, programarea a devenit, de asemenea, o problema de dimensiuni gigantice.




In acest sens, industria electronica nu numai ca nu a rezolvat nici macar o singura problema, ci dimpotriva, a creat problema utilizarii propriului sau produs”

Principalele probleme legate de industria informatica sunt legate de:

dificultatea evaluarii corecte a costurilor de dezvoltare

calitatea slaba a produsului final

depasirea termenelor de livrare

costurile mari de intretinere

Fig.

Sursa: Datamation, 15 Feb.1990

Fig. 3

Sursa: Sodhi, 1990

Fig. 3-1 In doua decenii de dezvoltare costurile de mentenanta s-au dublat

Fig. 3-2: Variatia ponderii ocupate de etapele de dezvoltare in total proiect, exprimata in costuri arata ca o crestere de numai 5% a eforturilor de analiza a cerintelor si de testare poate reduce la zero costurile de distributie si evaluare.

Criza software este determinata de insasi natura produsului care fiind:

complex poate genera probleme de comprehensibilitate

necorporal este dificil de masurat si evaluat

supus permanent modificarilor este dificil de gestionat si controlat

Ingineria informatica trebuie sa gaseasca rezolvari pentru aceste probleme pentru a putea produce sisteme care sa satisfaca cerintele utilizatorilor, sa fie flexibile si adaptabile in timpul si cu resursele planificate. Pentru aceasta este nevoie de principii, metode, standarde si tehnici ingineresti si de instrumente, practici tehnice si manageriale de dezvoltare.

Modele de dezvoltare

Evolutia spectaculoasa a complexitatii sistemelor cerute de beneficiari si a exigentelor privind calitatea a impus aparitia continua a unor modele de dezvoltare. Filozofia “divide et impera” a fost aplicata si activitatilor de constructie sisteme informatice nu numai pentru a putea controla mai bine evolutia, dar si pentru a extinde conceptul de satisfactie a beneficiarului la nivelul proceselor de dezvoltare.

Evolutia modelelor de dezvoltare de sisteme informatice au reflectat nevoile in schimbare ale beneficiarilor. Cu cat acestia au cerut rezultate mai rapide, cu atat a crescut implicarea in procesul de dezvoltare si in includerea de masuri pentru determinarea riscului si a eficientei sistemului. Suplimentar instrumentele software si hardware utilizate in industrie s-au schimbat si continua sa se schimbe in mod substantial. Platformele hardware si retelele din ce in ce mai rapide au venit in sprijininul utilizarii unui sistem de operare mai inteligent si mai rapid care a deschis calea catre noi limbaje si baze de date si aplicatii mai puternice decat cele precedente. Aceste schimbari numeroase si rapide in mediul de dezvoltare a sistemului au dat nastere la noi modele de proces mai practice care au inlocuit modelele mai vechi devenite inoperante.

Modelele de dezvoltare sunt utilizate pentru a ghida analiza, proiectarea, dezvoltarea si intretinerea sistemelor informatice.. Pentru ca un proces de dezvoltare sa fie considerat flexibil trebuie sa contina un set minimal de trei atribute:

dezvoltarea este impartita intr-un numar de sub-cicluri, fiecare dintre ele avand drept sarcina sa produca un subset din functiile pe care trebuie sa le aiba produsul final

oferirea unui prototip catre clienti intr-un stadiu incipient al dezvoltarii

procesul de dezvoltare cuprinde mecansime care sa asigure reactia rapida asupra schimbarilor de proiectare in desfasurare

Exista mai multe tehnici si metode utilizate pentru a controla ciclul de viata a unui proiect de dezvoltare sistem informatic Chiar daca diferitele modele de dezvoltare sunt gandite pentru a solutiona probleme practice specifice, ele prezinta multe similaritati in ceea ce priveste obiectivele si activitatile desfasurate. Activitatile tipice desfasurate de-a lungul ciclului de viata al unui proiect de dezvoltare sistem informatic sunt:

conceptualizarea sistemului

studiu de necesitate

dimensionarea resurselor necesare si aprobarea lansarii proiectului

definirea sistemului

specificatia de cerinte software

proiectarea de nivel inalt (specificatia de arhitectura)

proiectarea detaliata

dezvoltare de cod (programare)

integrarea si testarea software

integrarea si testarea sistemului

instalarea la beneficiar

testarea si acceptanta la beneficiar

instruirea si livrarea documentatiei

implementare (operare)

intretinere

Toate modelele de dezv sunt combinatii ale activitatilor enumerate mai sus diferentiindu-se intre ele prin metodele de control, buclele de reglare si sincronizarea activitatilor. Folosind o figura de stil putem afirma ca un model de dezvoltare este o foaie de parcurs pentru software.

Modele de dezvoltare de baza:

Modelul ad-hoc

Modelul de dezvoltare in cascada

Modelul de dezvoltare evolutiv

Modelul de dezvoltare sisteme formale

Modelul de dezvoltare bazat pe reutilizare

Modele de dezvoltare hibride:

Modelul de dezvoltare incrementala

Modelul de dezvoltare in spirala

Modelul de dezvoltare ad-hoc

Primele sisteme au fost dezvoltate in principal in baza experientei de programare a membrilor echipei de lucru. Cu toate dezavantajele sale legate de inconsistenta planificarii bugetelor functionalitatii si calitatii produsului acest model este inca folosit si astazi in special pentru proiectele mici.

Codul este scris direct, utilizat pina cand este potrivit pentru utilizare. Din cauza multiplelor iteratii codul este din ce in ce mai putin structurat. Din cauza lipsei unor cerinte explicite este improbabil ca produsul va satisface nevoile beneficiarului. Nu are o documentatie de dezvoltare, nu are testare regresiva, de aceea intretinerea este dificila si costisitoare. Cu toate acestea este cel mai utilizat model de dezvoltare!!

Modelul in cascada

Modelele de dezvoltare au aparut ca raspuns fie la caracteristicile procesului industrial automatizat fie la noile tehnologii de proiectare. Cel mai raspandit model de dezvoltare este modelul in cascada (Royce 70) care presupune definirea cerintelor pentru sistemul informatic urmata de un proces iterativ de executie si control divizat in etape de proiectare, implementare, testare, integrare si livrare. Pentru proiectele in care termenii de referinta nu specifica in detaliu cerintele sistem pe fondul unei dinamici ridicate a proceselor de reforma sau al lipsei convergentei de viziuni utilizator, activitatile care caracterizeaza acest model pot fi combinate cu cele de realizare de prototipuri.

Definitia 3

Modelul de dezvoltare in cascada este ciclul de viata a unui sistem software in care dezvoltarea se desfasoara liniar prin fazele analiza specificatie de cerinte, proiectare, implementare, testare, integrare si mentenanta

Modelul in cascada este cea mai veche metoda de dezvoltare structurata a sistemelor informatice. Cu toate ca in ultimii ani acest model a fost foarte criticat ca fiind prea rigid fata de dinamica ridicata a schimbarii cerintelor utilizator acest model este inca folosit pe scara larga. El este considerat un model generic pentru multe alte modele de dezvoltare software. Imbunatatit pe baza experientei castigate in proiecte guvernamentale de larga avergura, modelul in cascada a dat nastere modelului in spirala (Boehm ’88) incluzand elementele de dezvoltare pe baza de prototip si analiza riscului dezvoltarii. Cea mai importanta caracteristica a modelului in spirala este faptul ca fiecare ciclu de dezvoltare se incheie cu o examinare realizata de actorii cheie ai partilor implicate in proiect. Modelul in cascada este considerat depasit pentru tehnologia OO.

Modelul in cascada este cel mai adesea folosit in dezvoltare deoarece prezinta o structura buna a activitatilor si defineste clar furniturile intermediare. Prin adaptare si imbunatatire el poate acoperi o gama larga de necesitati de dezvoltare. O prezentare schematica a activitatilor de dezvoltare  sisteme informatice bazata pe paradigmul planificare executie control este prezenata in Fig. 3-3.


Fig. 3

Modelul in cascada consta din urmatoarele etape:

Analiza si definirea cerintelor

Se refera la considerarea tuturor aspectelor legate de proiect sau functiile sistemului care se informatizeaza cu scopul de a determina modul in care acestea se interrelationeaza pentru a decide care dintre acestea vor fi incorporate in sistem si la definirea cerintelor de sistem

Proiectarea sistemului

Inglobeaza partea de proiectare de nivel inalt si de proiectare detaliata

Programarea si testarea componentelor

Se refera la translatarea in cod masina a specificatiei detaliate de proiectare si la verificarea eficientei interne (respectarea procedurilor de dezvoltare impuse de tehnolog) si eficacitatii externe (masura in care se realizeaza functiile din specificatie) a componentelor software

Integrarea si testarea

Se refera la asamblarea componentelor software si la verificarea eficientei interne si a eficacitatii externe a produsului rezultat

Operarea si intretinerea sistemului

Se refera la exploatarea in conditii reale si la activitatile de mentenanta ale sistemului.

Avantajele modelului



Dezavantajele modelului

Permite separarea departamentala si un control managerial bun asupra dezvoltarii

Este mai usor de planificat

Dezvoltarea se produce secvential, fara suprapuneri si refaceri.

Proiectare structurala buna

proiectele reale urmeaza rareori fluxul secvential propus de model, multe dintre faze se suprapun

in majoritatea cazurilor la inceputul proiectelor exista un nivel ridicat de incertitudine privitor la obiectivele si cerintele sistemului iar modelul nu poate face fata acestui nivel de incertitudine pentru ca nu permite reflectii si revizii

utilizarea modelului in cascada intarzie aparitia primei versiuni operationale de sistem

Modele de dezvoltare evolutiva

Modelele cu dezvoltare evolutiva presupun o implementare initiala care este supusa comentariilor beneficiarului si rafinata pana cand aceasta satisface cerintele (Fig. 3-4).


Fig. 3

Exista doua tipuri de dezvoltare evolutiva:

Dezvoltare de prototip

Obiectivul principal este capturarea cerintelor beneficiarului

Se concentreaza pe cerintele neclare si redefineste cerintele pe masura ce proiectul evolueaza

Explorare

Porneste de la cerinte bine definite

Adauga caracteristici noi la produs pe masura ce beneficiarul propune cerinte noi.

Modelul cu dezvoltare de prototip

Acest model a fost dezvoltat pornind de la observatia ca este dificil sa cunosti toate cerintele de la inceputul unui proiect. In mod uzual beneficiarii sistemului stiu ce obiective vor sa atinga cu acel sistem, dar nu pot inca preciza nivelul de rafinare al datelor, caracteristicile si performantele in detaliu ale sistemului.

Definitia 3

Modelul cu dezvoltare de prototip este un model care furmizeaza o versiune de sistem cu functionalitate redusa si performante limitate inca din fazele de inceput ale dezvoltarii. Prototipul este utilizat apoi pentru rafinarea cerintelor si dezvoltarea sistemului[3].

Modelul dezvoltarii de prototip permite obtinerea de rezultate chiar in conditiile unor informatii sumare. In cadrul acestui model proiectantul construieste o versiune simplificata a sistemului si o prezinta spre evaluare clientului ca parte a procesului de dezvoltare. Reactia beneficiarului la sistem sprijina rafinarea cerintelor sistem. Este aplicabila proiectelor mici sau la nivelul subsistemelor.

Exista trei metode utilizate in cadrul modelului cu dezvoltare de prototip:

crearea celor mai importante interfete fara ca acestea sa fie insotite de programare in scopul de a-i da utilizatorului sentimentul de cum va arata sistemul

dezvoltare unei versiuni prescurtate a sistemului care realizeaza un set limitat de functii

utilizarea unui sistem care exista sau componente de sistem care demonstreaza anumite functii care vor fi incluse in sistemul dezvoltat

Modelul cu dezvoltare de prototip cuprinde urmatoarele etape:

Definirea cerintelor

similar cu faza de conceptualizare a modelului in cascada, dar nu asa de cuprinzatoare

Proiectare

informatia privitor la cerintele initiale imediat ce este colectata este integrata rapid in proiectul existent al modelului de dezvoltare cu prototip

Creare / modificare model

informatia din proiectare este rapid inglobata in modelul cu dezvoltare de prototip; acest lucru poate insemna crearea/ modificarea informatiei pe hartie, o noua codificare sau modificari la codul existent

Evaluare

modelul este prezentat clientului pentru revizuire pentru comentarii si sugestii

Rafinarea modelului

dezvoltatorul de program revizuieste modelul pentru a-l face mai eficient

Implementarea sistemului

in cele mai multe cazuri sistemul este rescris odata ce cerintele au fost intelese; uneori procesul iterativ produce un sistem de lucru care poate fi fundamentul pentru sistemul integral functional

Avantajele modelului

Dezavantajele modelului

Beneficiarul este multumit pentru ca este asistat in formularea cerintelor

Flexibilitate in modificarea cerintelor

Prototipurile sunt vizuale si nu introduc ambiguitati

Datorita naturii ad-hoc procesele sunt greu de urmarit

Sunt necesare instrumente speciale pentru dezvoltare rapida care adesea pot fi incompatibile cu platformele de dezvoltare propriuzise.

Modelul cu dezvoltare de prototip poate conduce la asteptari false - clientul crede in mod gresit ca sistemul este terminat in timp ce in fapt nu este; versiunea de pre-implementare a unui sistem nefiind altceva decat o structura unidimensionala; dezvoltarea propriuzisa nu este inca facuta.

Modelul cu dezvoltare de prototip poate conduce la un sistem proiectat simplist, putin structurat. Scopul principal al modelului este dezvoltarea rapida, deci proiectarea sistemului poate suferi intrucat sistemul este construit dintr-o serie fara o consideratie globala a integrarii tuturor componentelor;

Costurile de documentare sunt mai mari

O varianta populara a modelului cu dezvoltare de prototip este dezvoltarea rapida de aplicatii (RAD – Rapid Application Development). RAD introduce timpi stricti pentru fiecare faza de dezvoltare si utilizeaza instrumente de aplicare rapide care permit o dezvoltare rapida.

Modelul cu explorare

In unele situatii este foarte dificil, daca nu imposibil, sa se identifice unele dintre cerintele sistemului la inceputul proiectului. Ariile teoretice ca Inteligenta Artificiala sunt candidate in utilizarea modelului cu explorare, pentru ca o mare parte din munca se bazeaza pe estimare si ipoteze. In aceste cazuri, se face o presupunere de cum ar putea sa lucreze modelul si apoi se fac iteratii rapide pentru a incorpora schimbarile sugerate pana cand se construieste un sistem utilizabil. Validarea se bazeaza pe adecvarea rezultatelor obtinute si nu pe acoperirea cerintelor initiale.

Etapele modelului cu explorare sunt urmatoarele:

Dezvoltarea unei specificatii initiale

folosind orice informatie disponibila se creaza o scurta specificatie de sistem si se creaza un punct de plecare rudimentar

Constructia / modificarea sitemului

Se creeaza un sistem pe baza informatiei disponibile la momentul constructiei

Testarea sistemului

sistemul este testat pentru a vedea ce face, ce se poate invata din el si cum se poate imbunatati

Implementarea sistemului

dupa iteratii repetate cand apar primele rezultate satisfacatoare sistemul este implementat

Avantajele modelului

Dezavantajele modelului

Beneficiarul este multumit pentru ca este asistat in formularea cerintelor

Flexibilitate in modificarea cerintelor

Este limitat in utilizarea unor limbaje de nivel inalt care permite o dezvoltare rapida

Este dificil de masurat sau prevazut eficienta din punct de vedere cost

Dezvoltarea de software initiala este adesea construita pentru a fi distribuita publicitar asteptarea in a produce o proiectare solida de sistem poate fi uneori problematica

Modelul de dezvoltare formala

Definitia 3

Modelul de dezvoltare formala este un model care descrie structura si metodologia unui proces software cu ajutorul unei metode algoritmice sau prin intermediul unui limbaj de descriere abstracta a proceselor[4].



Modelul de dezvoltare formala este similar modelului in cascada dar dezvoltarea modelului se face prin transformarea matematica formala a specificatiei in program executabil. Specificatia de cerinte este rafinata intr-un formalism detaliat exprimat prin notiuni matematice. Este inglobata in metoda de dezvoltare Cleanroom.

Proiectarea, implementarea si testarea sunt inlocuite de o serie de transformari matematice. Aplicabilitatea ei se refera la sistemele care au cerinte de siguranta foarte speciale.

Avantajele modelului

Dezavantajele modelului

Nu necesita testare

Conformitatea cu specificatia este foarte usor de verificat

Deoarece necesita o expertiza speciala metoda este arareori folosita.

Ea ridica in special probleme la descrierea formala a interfetei utilizator.

Cererile de modificare necesita transformari si validari noi.

Nu este scalabila

Modelul cu reutilizare

Premiza de baza pentru modelul cu reutilizare a sistemului consta in utilizarea unor componente existente. Modelul cu reutilizare este potrivit pentru mediul de calcul orientat pe obiect.

Definitia 3

Modelul cu reutilizare este un model care configureaza si specializeaza un software pre-existent integrandu-l intr-un sistem viabil[5].

In cadrul modelului cu reutilizare bibliotecile de module software pun la dispozitie module care pot fi utilizate in orice sistem. Aceste componente sunt de doua tipuri: module procedurale si module de baze de date. La constructia sistemului dezvoltatorul va ‘imprumuta’ module din biblioteca de module si le va plasa intr-o procedura care realizeaza o functie. Daca modulul necesar nu exista, dezvoltatorul va construi unul si-l va plasa si in biblioteca de module pentru a fi disponibil pentru utilizari viitoare (Fig. 3-5).


Fig. 3

Modelele de dezvoltare orientate pe obiect au fost introduse in anii ’80 reprezentand o mutatie majora de gandire in dezvoltarea software. Pentru proiecte de larga anvergura Branson si Herness propun in ’92 un model in opt etape asistat de mecanisme de urmarire, inspectii, un set de tehnologii si reguli pentru realizarea de prototipuri si testare. Etapele modelului cu reutilizare sunt urmatoarele:

Definirea cerintelor

Se colecteaza cerintele sistemului initiale; aceste cerinte in mod uzual sunt un subset din cerintele sistemului complet

Definirea obiectelor

Se identifica obiectele care pot sprijini componentele sistemului

Colectarea obiectelor

Se descarca copii ale modulelor necesare din biblioteca de module

Crearea obiectelor clientului

Obiectele necesare care nu exista in libraria de module se creaza

Asamblarea prototipului

O versiune prototip este evaluata pentru a se determina daca este adecvata nevoilor si cerintelor clientului

Rafinarea cerintelor

Cerintele sunt rafinate si o versiune mai detaliata a prototipului este creata

Rafinarea obiectelor

Obiectele sunt rafinate pentru a reflecta schimbarile in cerinte.

Avantajele modelului

Dezavantajele modelului

costuri si riscuri reduse

livrare rapida

Modelul cu reutilizare este limitat in mediul de dezvoltare orientat pe obiect.

Necesita o baza de componente destul de larga

Necesita un management strict si eficient al configuratiilor

Potentiale probleme de compatibilitate intre diferite versiuni

Modelul incremental

Dezavantajele modelului in cascada au determinat eforturi pentru gasirea unor solutii care sa furnizeze rezultate mai rapide care sa aiba nevoie de mai putina informatie la lansare si sa ofere mai multa flexibilitate.

Definitia 3

Modelul incremental este un model care furnizeaza o versiune operationala care contine functiile principale sistem urmata, la intervale regulate de timp de versiuni imbunatatite si la capacitati sporite[6].

Developing systems through incremental release requires first providing essential operating functions, then providing system users with improved and more capable versions of a system at regular intervals

Dezvoltarea incrementala imparte proiectul in parti mai mici care sa permita obtinerea unor rezultate mai rapide precum si a unor reactii mai valoroase din partea utilizatorilor. De fapt fiecare iteratie este un miniproces in cascada in care reactia de la o faza furnizeaza informatie vitala pentru proiectarea urmatoarei faze. Produsele software rezultate la iesirea fiecarei etape pot fi introduse in productie imediat ca versiuni incrementale (Fig. 3-6).


Fig. 3

Avantajele modelului

Dezavantajele modelului

Produsele livrate incremental produc introducerea timpurie a serviciilor sistemului care va integra gradual toate functiile solicitate

Scade riscul global al proiectului

Cerintele sunt implementate potrivit nivelului lor de prioritate

desi implicarea utilizatorilor finali este benefica pt rezultatele finale ale proiectului ea presupune alocarea de resurse de timp considerabile din partea inginerilor de dezvoltare si poate sa atraga intarzierea proiectului

greutatea dezvoltarii proiectului se muta in zona abilitatilor de comunicare si coordonare

in scopul eliminarii posibilelor confuzii create de cererile de imbunatatire formulate dupa incheierea fiecarei faze este necesar un sistem de gestiune a cererilor de modificare f bine pus la punct

cresterea volumului de cerinte utilizator datorita faptului ca pe masura ce sistemul se dezvolta acestia intuiesc posibilitatile de imbunatatire a serviciilor oferite de sistemul informatic si incarca sarcina proiectantului

Un numar de modele de proces au evoluat din abordarea iterativa. Toate aceste metode produc un produs soft devreme in proces in scopul de a obtine reactie din partea utilizatorilor sistemului sau a altor membri din echipa de proiectare. Unele din aceste metode sunt descrise in cele ce urmeaza.

Modelul in spirala [Boehm]

Definitia 3

Modelul de dezvoltare in spirala este un model generator de procese comandate de risc. Este utilizat pentru a sprijini proiectarea concurenta multi-partita a sistemelor software intensive

Imbunatatit pe baza experientei castigate in proiecte guvernamentale de larga avergura, modelul in cascada a dat nastere modelului in spirala (Boehm ’88) incluzand elementele de dezvoltare pe baza de prototip si analiza riscului dezvoltarii. Cea mai importanta caracteristica a modelului in spirala este faptul ca fiecare ciclu de dezvoltare se incheie cu o examinare realizata de actorii cheie ai partilor implicate in proiect.



Modelul in spirala a fost proiectat cu intentia de a cuprinde cele mai bune trasaturi ale modelelor cascada si cu dezvoltare de prototip si introduce o noua componenta – managementul riscului Termenul spirala descrie procesul care are loc in dezvoltarea unui sistem. Similar cu modelul de dezvoltare pe baza de prototip este dezvoltata o versiune initiala a sistemului si apoi repetitiv modificata bazat pe evaluarile primite de la client. Caracteristicile sistemului sunt definite si dezvoltate in ordinea descrescatoare a prioritatilor. Spre deosebire de modelul de dezvoltare de prototip dezvoltarea fiecarei versiuni a sistemului este proiectata cu grija utilizand pasii implicati in modelul in cascada. Cu fiecare iteratie in jurul spiralei (pornind de la centru in spre exterior) se construiesc versiuni mai complete ale sistemului. Acest model de dezvoltare este potrivit pentru proiecte mari, complexe, avand costuri mari (Fig. 3-7).

Are doua trasaturi principale distinctive:

abordarea ciclica a gradului de definire si implementare a unui sistem care creste incremental

existenta unui set de puncte decizionale care asigura angajarea partilor implicate in proiect pentru a furniza solutii sistem fezabile si mutual avantajoase.


Fig. 3

Fiecare ‘turnanta’ este precedata de analiza de risc. Daca riscurile sunt excesive, dezvoltarea este oprita. O ‘turnanta’ corespunde unei faze si unghiului de progres in cadrul fazei. Raza spiralei arata costurile cumulative.

Evaluarea riscului este inclusa ca o treapta in procesul de dezvoltare ca o modalitate de evaluare a fiecarei versiuni de sistem pentru a determina daca dezvoltarea continua sau nu. Daca clientul decide ca riscul identificat este prea mare procesul poate fi intrerupt. De exemplu, daca este identificata o crestere substantiala a costurilor sau timpul de realizare a proiectului in cadrul unei faze, clientul si programatorul pot decide daca are sens continuarea proiectului in aceste conditii.

Modelul in spirala are urmatoarele faze:

Obiectivele proiectului

Similar cu faza de conceptualizare a modelului in cascada; se determina obiectivele, se identifica posibile obstacole si se autorizeaza diferite abordari

Evaluarea riscului

Se examineaza posibile alternative si se identifica problemele / riscurile; rezolvarea riscurilor este evaluata si autorizata in considerarea continuarii proiectului; uneori modelul cu dezvoltare cu prototip este utilizat pentru clarificarea nevoilor.

Proiectare si productie

Sunt determinate cerintele detaliate si este dezvoltat software-ul

Planificare si management

Clientul are posibilitatea sa analizeze rezultatul fiecarei versiuni create in faza de proiectare si sa–si trimita obiectiile programatorului.

Avantajele modelului

Dezavantajele modelului

Considerarea explicita a riscului de proiect. In fiecare ciclu de dezvoltare se evalueaza solutii alternative

Procesele in fiecare faza de dezvoltare au un grad mai mare de rafinare.

componenta de evaluare a riscului face ca acest model sa fie mai costisitor de implementat decat modelele predecesoare

poate introduce intarzieri mari de dezvoltare.

Crearea si combinarea modelelor

In multe cazuri parti si proceduri din diferite modele de proces sunt integrate pentru a sprijini dezvoltarea sistemului. Acest lucru se intampla pentru ca cele mai multe modele au fost proiectate pentru a crea un cadru de lucru pentru realizarea succesului numai in anumite circumstante. Cand circumstantele se schimba dincolo de limitele modelului rezultatele obtinute prin utilizarea acestuia nu mai sunt predictibile. Cand apare aceasta situatie uneori este necesara adoptarea sau combinarea de diferite modele pentru a se face acomodarea la noile circumstante.

Spargerea unui proiect intr-un numar de sub-cicluri permite echipei de dezvoltare sa capete devreme o reactie legat de elementele critice pentru performantele sistemului si in felul acesta ajuta echipa sa reactioneze la probleme tehnice neprevazute prin reprogramarea muncii in fazele ulterioare ale proiectului. Oferirea unui prototip clientilor permite echipei sa primeasca o reactie timpurie asupra performantelor unui proiect in desfasurare in contectul final de utilizare.

Existenta mecanismelor pentru a primi o reactie rapida asupra impactului schimbarilor de proiectare in desfasurare asigura faptul ca versiunea curenta de proiectare este robusta si capabila sa raspunda rapid la informatia in schimbare pe masura ce se desfasoara.

Selectia unui model de proces potrivit depinde de doi factori: mediul organizational si natura aplicatiei. Frank Land de la London School of Economics sugereaza ca abordarea cea mai potrivita pentru analiza de sistem, proiectare, dezvoltare si implementare sa fie bazate pe relatia intre sistemul informatic si mediul sau organizational. S-au identificat patru categorii de relatii:

mediul care nu se schimba: cerintele informationale nu se schimba pentru durata de viata a sistemului. Cerintele pot fi formulate neambiguu si cuprinzator; un grad inalt de acuratete este necesar. In acest mediu, metodele formale ( modelele cascada si spirala) vor furniza completitudinea si precizia cerute de sistem

mediul turbulent: organizatia este intr-o continua schimbare si cerintele sistemului se schimba tot timpul; un model dezvoltat pe baza modelului in cascada va fi, in parte, demodat pana la implementarea lui. Multe sisteme cad in aceasta categorie. Metodele de succes le vor include pe acelea care incorporeaza dezvoltare rapida, reutilizare maxima si o proiectare modulara

mediul incert – cerintele sistemului sunt necunoscute sau incerte; nu se pot defini cu precizie cerintele inainte pentru ca situatia este noua sau sistemul folosit este intr-o mare masura inovativ.. In acest caz metodele de dezvoltare trebuie sa sublinieze necesitatea instuirii.Modelele de proces experimentale de tip cu dezvoltare de prototip sunt cele mai potrivite

mediul adaptiv – mediul se poate schimba ca reactie la dezvoltarea sistemului initiind o schimbare in cerinte; Sistemele cu instruire si sistemele expert sunt in aceasta categorie. Pentru aceste sisteme adaptarea este cheia si metodologia trebuie sa permita introducerea de noi reguli intr-un mod simplu.



E. W. Dijkstra, Turing Award Lecture, 1972

W. W. Royce, 'Managing the Development of Large Software Systems', Proceedings of IEEE WESCON, August 1970

Baltzer R., Cheatham T., Green C., Software technology in the 1990's: using a new paradigm, 1st. International Software Process Workshop, Egham, UK. 1984

***), Glossary, www.informatik.uni-bremen.de

Biggerstaff T., Special Issues on Software Reusability, IEEE Transactions on Software Engineering, vol. 10, #5,1984

Basili V., Turner A. J., Iterative Enhancement: A Practical Technique for Software Development, IEEE Transactions on Software Engineering, vol. 1, #4, December 1975

Barry Boehm, Spiral Development: Experience, Principles, and Refinements, Editor Wilfred J. Hansen, Special Report CMU/SEI-00-SR-08, ESC-SR-00-08, Iunie, 2000.

Barry Boehm, 'A Spiral Model of Software Development and Enhancement', ACM SIGSOFT Software Engineering Notes, August 1986






Politica de confidentialitate



DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 3130
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2022 . All rights reserved

Distribuie URL

Adauga cod HTML in site