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

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:

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:

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.

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:

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‑

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:

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.