Sunteți pe pagina 1din 11

INTRODUCERE

Ingineria software a parcurs o cale lung ncepnd cu 1968, an n care acest termen a fost utilizat pentru prima oar la o conferin NATO. Iar de atunci software-ul a ptruns n viaa fiecruia dintre noi n diverse moduri, aa cum puini anticipaser chiar cu un deceniu n urm. Aadar cunoaterea noiunilor de baz legate de teoria i practica ingineriei software este esenial pentru nelegerea tehnicilor de construire a unui software performant i de asemenea a metodelor de evaluare a riscurilor i oportunitilor pe care software-ul le ofer vieii noastre de zi cu zi. n anul 1946 Goldstine i von Neumann apreciau c 1000 de instruciuni reprezint o limit superioar rezonabil pentru complexitatea problemelor ce pot fi concepute ca rezolvabile cu ajutorul calculatorului. Dup ce a prevzut c nici un program pentru calculatoare personale nu va necesita vreodat mai mult de 64 KB de memorie RAM, Bill Gates a admis n 1995 c lucrurile sau schimbat n ultimele dou decenii. Urmtoarele exemple ofer o imagine asupra gradului de complexitate la care au ajuns programele: Sistemul de rezervare a biletelor pentru compania aerian KLM coninea, n anul 1992, dou milioane de linii de cod n limbaj de asamblare; Sistemul de operare System V versiunea 4.0 (UNIX) a fost obinut prin compilarea a 3700000 linii de cod; Programele scrise pentru naveta spaial NASA au circa 40 de milioane de linii de cod obiect;

Pentru realizarea sistemului de operare IBM OS360 au fost necesari 5000 de ani-om. Pentru a contracara ceea ce se prefigura ca fiind o criz a programrii, a fost propus n anul 1968 termenul de ingineria software (software engineering), ntr-un mod oarecum provocator. Se dorea ca arta programrii s mprumute din rigoarea stiinelor inginereti pentru a putea livra programe la timp i n mod economic. Definiii: IEEE Standard Glossary of Software Engineering Terminology (1990, 1991) Aplicarea unei abordri sistematice, disciplinate, cuantificabile la realizarea, operarea i ntreinerea software-ului. Fritz Bauer (1968) Stabilirea i utilizarea unor principii inginereti n scopul realizrii n mod economic produse software fiabile care funcioneaz eficient pe maini reale. Morven Gentlemen (1990) Utilizarea metodologiilor , instrumentelor i tehnicilor de rezolvare a problemelor practice care apar n construcia , instalarea , ntreinerea i evoluia produselor software. Stephen Schach (1990) O disciplin avnd drept obiectiv producia unui software de calitate, livrat la termen, cu respectarea bugetului i care satisface cerinele stabilite. Boehm (1979) Aplicarea practic a cunotinelor tiinifice n proiectarea i construcia programelor i a documentaiei asociate necesare pentru dezvoltarea, operarea i ntreinerii acestora. Dennis (1975) Ingineria software este aplicarea principiilor, aptitudinilor i arta proiectrii si construciei programelor i sistemelor de programe.

Fairley (1985) Ingineria software este disciplina tehnic i managerial avnd ca obiect producia sistematic i ntreinerea produselor informatice care sunt realizate i modificate n timp n condiii economice. O definiie cuprinztoare a fost prezentat de Bruegge i Dutoit n Object-Oriented Software Engineering [2000] conform creia Ingineria software este: activitate de modelare - probleme complexe sunt tratate prin modelare, atenia fiind concentrat asupra detaliilor semnificative si ignornd restul. modelul - o abstractizare a realitii analiza - construcia unui model al domeniului problemei proiectarea - construirea unui model pentru domeniul soluiei n metodele OO, modelul domeniului soluiei este o extensie a modelului domeniului problemei, astfel nct structura software-ului reflect structura problemei. activitate de rezolvare a problemelor - modelele folosite pentru a cuta o soluie acceptabil sunt: efectuarea de experimente reutilizarea unor soluii model (reuses pattern solutions) evoluia incremental a sistemului spre o variant acceptat de client revizuirea rspunsului la schimbri activitate de achiziionare de informaie-n modelare aplicaiei i a domeniului soluiei, se colecteaz datele, se organizeaz in informaii i se formalizeaz n cunotine. Aceast activitate este neliniar n sensul c achiziia de noi informaii poate invalida cunotinele precedente i se caracterizeaz prin: dezvoltare bazata pe risc - identificarea componentelor cu risc mare pentru a evita surprizele ulterioare dezvoltare pe probleme (issue-based development) - execuia in paralel a activitilor de dezvoltare, organizarea fcndu-se innd cont de problemele care sunt nc nerezolvate dezvoltare iterativa proiectarea si implementarea la nceput a prilor cu risc ridicat (dificile) activitate raional-logic realizatorii de software trebuie s neleag contextul n care au fost luate deciziile i logica ce st in spatele lor pentru a nelege implicaiile unei schimbri propuse atunci cnd decizia este reanalizat; util n cazul unor sisteme care s schimb n mod frecvent precum i util in etapa de ntreinere Clasificarea aplicaiilor software Sisteme de operare i software de sistem Software timp real restricii timp de rspuns Sisteme informatice baze de date Software tiinific Software inclus (ascensoare, telefoane, aparatur casnic)

Anthony Wasserman identific opt noiuni fundamentale ce formeaz baza operativ a disciplinei Ingineria sistemelor software: 1. Abstractizarea o descriere a problemei la un anumit nivel de generalizare ce ne permite s ne concentrm atenia asupra aspectelor cheie ale problemei fr a ne pierde n detalii. 2. Metode i Notaii n proiectare i analiz - cnd se lucreaz n echip, comunicarea ntre membrii echipei i documentarea n procesul de dezvoltare face necesar stabilirea unui sistem de notaie comun. 3. Prototipizare - construirea unei versiuni miniaturale a sistemului, de obicei cu funcionalitate limitat, care ajut utilizatorul s identifice cerinele eseniale ale sistemului i demonstreaz fezabilitatea unui anumit mod de abordare/proiectare; utilizat n special pentru proiectarea interfeelor utilizator. 4. Arhitectura sistemului (software) - descrierea sistemului ca o mulime de uniti arhitecturale i stabilirea legturilor ntre uniti. 5. Procesul software organizarea i disciplina n activitile ce se desfoar n timpul procesului de dezvoltarea software-ului contribuie la calitatea software-ului i rapiditatea cu care este dezvoltat. 6. Refolosirea - evidenierea prilor comune cu alte aplicaii i refolosirea unor componente dezvoltate anterior. 7. Msurtori - descrierea cantitativ a mbuntirii proceselor, resurselor i metodelor permite compararea progresului intre proiecte disparate i ajut la analiza i luarea deciziilor. 8. Instrumente i Mediu integrat (Tools and Integrated Environment) instrumentele CASE (computer-aided software engineering) sunt proiectate pentru a spori dezvoltarea soft-ului dar rareori se adreseaz unui ciclu ntreg de dezvoltare a software-ului

Complexitatea sistemelor software deriv din 4 elemente: 1) complexitatea domeniului problemei. Problemele care cer o rezolvare software sunt deosebit de complexe, ncepnd chiar cu specificaiile care pot fi contradictorii (ex: specificaiile pentru construirea unui robot). Funcionalitatea acestor sisteme este suficient de greu de neles i la aceasta se mai adaug i cerinele nefuncionale pe care trebuie s le ndeplineasc sistemul: performan, utilitate, fiabilitate, cost, etc. Aceast complexitate provine i din nenelegerile care exist ntre proiectanii sistemului i utilizatorii si: utilizatorii, de obicei, nu-i pot exprima clar cerinele ntr-o form pe care proiectanii s o neleag. Uneori, ei au doar o vag idee despre ceea ce doresc de la un sistem. Practic, aceste probleme apar deoarece fiecrui grup i lipsesc cunotinele despre domeniul celuilalt grup. Utilizatorii i proiectanii au perspective diferite de a vedea soluia problemei. Chiar i atunci cnd utilizatorii tiu ceea ce doresc, lipsesc instrumentele pentru extragerea precis a cerinelor lor. Calea obinuit prin care aceste specificaii sunt exprimate const n a scrie mult text, incluznd ocazional i diverse figuri. Dar aceste documente sunt greu de neles, sunt deschise la diverse interpretri, i deseori, conin elemente care sunt mai degrab de proiectare dect de specificaiile eseniale ale problemei. Complicaii mai mari apar atunci cnd specificaiile sistemului se modific n timpul dezvoltrii lui. Sistemele mari tind s evolueze de-a lungul timpului, o condiie ce impropriu este denumit ntreinere. Mai precis, ntreinerea nseamn corectarea erorilor. Evoluia nseamn

modificarea cerinelor i meninerea nseamn folosirea unor mijloace extraordinare de a pstra n utilizare un sistem vechi i depit. 2) dificultatea de a administra procesul de dezvoltare Scopul principal al echipei de software e de a construi iluzia simplitii, de a feri utilizatorul de vasta complexitate a problemei. Volumul mare de munc determin folosirea unei echipe de dezvoltare a softului. Mai muli membri n echip nseamn o mai complex comunicare ntre ei, deci o coordonare mai dificil, mai ales atunci cnd echipa este dispersat geografic. ntr-o echip de dezvoltare, cheia coordonrii e de a menine mereu unitatea i integritatea proiectului. 3) flexibilitatea sistemului Sistemul software va trebui s fie flexibil. Acest lucru l foreaz pe proiectant de a dezvolta blocurile primitive din care va construi apoi abstractizrile de la nivelele superioare. n timp ce domeniul construciilor industriale ofer standarde pentru calitatea materialelor, puine astfel de standarde exist n software-ul industrial. Ca urmare, dezvoltarea softului rmne o munc intens laborioas. 4) problemele de caracterizare a comportrii sistemelor discrete n aplicaiile foarte mari, pot exista sute sau mii de variabile. Colecia de variabile, valorile lor, adresele lor i stiva de apeluri ale fiecrui proces din sistem, reprezint starea curent a sistemului la un moment dat. Sistemele discrete (care nu pot fi descrise prin funcii continue), prin natura lor, au un numr finit de stri posibile. n marile sisteme, acest numr este imens. De aceea, se ncearc proiectarea prilor de sistem astfel nct comportarea uneia s aib impact minim asupra celorlalte. Totui, orice eveniment extern sistemului soft l poate plasa ntr-o nou stare, i, mai mult, maparea de la o stare la alta nu e ntotdeauna determinist. n cele mai rele cazuri, un eveniment extern poate corupe starea sistemului pentru c proiectanii au uitat s considere anumite interaciuni dintre evenimente (ex: sistemul computerizat, comun pentru cabina de comand i cabina pasagerilor, ntr-un avion ). Deoarece nu avem nici instrumentele matematice i nici capacitatea intelectual de a modela complet comportarea marilor sisteme discrete, trebuie s ne rezumm la acceptarea unui nivel acceptabil de ncredere n corectitudinea lor, dovedit n timpul testrilor atente. Referitor la factorul uman n procesul de dezvoltare a softului, acesta trebuie s ia n consideraie foarte multe detalii n acelai timp. Experiene psihologice au artat c un individ poate nelege simultan 7 2 uniti de informaii i c exist o limitare a vitezei de procesare a creierului la 5 secunde pentru acceptarea unei noi informaii. i atunci apare urmtoarea problem: complexitatea softului ce ni se cere s-l proiectm crete dar factorul uman prezint incapaciti serioase de a face fa acestei probleme. Sugestia lui Dijkstra este: Tehnica de a stpni complexitatea este tiut din antichitate: divide i cucerete . n proiectarea unui sistem, este esenial descompunerea lui n subsisteme din ce n ce mai mici, fiecare din ele putnd fi construit independent. n felul acesta este rezolvat i constrngerea impus de capacitatea uman de cunoatere: pentru a nelege un anumit nivel al unui sistem e nevoie de a nelege numai cteva pri n acelai timp.

Ciclul de viat al unui produs software


Produsul software este un produs similar oricrui alt produs. El are atribute fizice ca orice alt produs fizic, i deci, el are o "via" similar cu cea a altor produse. De aceea, produsul software poate fi privit din punctul de vedere al unui ciclu de via, acesta reprezentnd toate fazele din cursul procesului de dezvoltare a unui sistem software, ncepnd de la conceperea sistemului i pn la retragerea sa din folosin. Fazele clasice n procesul de dezvoltare sunt: definirea cerinelor utilizatorilor

definirea specificaiilor software programarea sistemului implementarea testarea documentarea

Problemele ingineriei software


Satisfacerea cerinelor clienilor. Problema fundamental a ingineriei software este ndeplinirea cerinelor clientului. Aceasta trebuie realizat nu punctual, nu n acest moment, ci ntr-un mod flexibil i pe termen lung. Ingineria software se ocup cu toate etapele dezvoltrii programelor, de la extragerea cerinelor de la client pn la ntreinerea i retragerea din folosin a produsului livrat. Pe lng cerinele funcionale, clientul dorete (de obicei) ca produsul final s fie realizat cu costuri de producie ct mai mici. De asemenea, este dezirabil ca aceasta s aib performana ct mai bun (uneori direct evaluabil), un cost de ntreinere ct mai mic, s fie livrat la timp, i s fie sigur. Prezentm n continuare o statistic privind gradul de satisfacere a cerinelor pentru proiecte software mari. Aceasta pare s justifice orice disciplin a muncii care s mbunteasc aceste cifre.
5% 5%

livrate dar nefolosite 20% 45% pltite dar nelivrate abandonate sau ref cute folosite dup modific ri folosite a a cum au fost livrate

25%

Figura 1. Gradul de satisfacere a cerinelor pentru proiecte software mari

Nerespectarea cerinelor poate avea efecte serioase. Un sistem de livrare a insulinei pentru diabetici poate provoca moartea pacientului dac nu funcioneaz corect. Funcionarea incorect a unui sistem de control al unui satelit poate provoca pagube de milioane de dolari. Un program este sigur dac funcioneaz i continu s funcioneze fr ntreruperi i fr a efectua operaii nedorite. Un program are o greeal (bug) dac nu se comport corect. Se presupune c dezvoltatorul tia ce ar fi trebuit programul s fac, iar comportamentul greit nu este intenionat.

Costul produsului. Cheltuielile pentru producerea sistemelor software sunt imense. Se apreciaz c ele au depit suma de 140 bilioane $ la nivelul anului 1985 i urmau s creasc de atunci cu 12% pe an. Costul este influenat de cerinele impuse pentru funcionarea acestuia (exemplu: necesitatea de a se executa n timp real - timpul tipic de rspuns este de ordinul microsecundelor). De asemenea, timpul mare de via i frecventele modificri cerute pentru meninerea sistemului sau pentru adugarea unor noi faciliti vor mri costurile generale. Se estimeaz c cel mai mare volum al cheltuielilor (60%-80%) se nregistreaz n cazul ntreinerii softului. Totodat, cu ct produsul soft este mai complex, mai mare, cu att costurile totale vor crete. Figura 2 se bazeaz pe un numr de studii care demonstreaz distribuia tipic a timpului consumat pentru crearea unui sistem software.

20%

40%

Testare Analiz Proiectare Implementare

35% 5%

Figura 2: Distribu ia efortului pentru ob inerea produsului soft

Dup cum se vede, cel mai mult timp e dedicat proiectrii i implementrii sistemului.

36% erori de implemetare erori de specificare i analiz

64%

Figura 3: Erori tipice n produsul soft

Alte studii au artat c cerinele, specificaiile i analiza produsului determin cele mai multe erori n sistem (64% fa de 36%) (Figura 3). Mai mult, aceste erori nu sunt descoperite de ctre cei care dezvolt sistemul ci de ctre cei care le testeaz i/sau de ctre utilizatori. Cu ct aceste erori sunt evideniate mai trziu, cu att ele implic un mai mare volum de munc i cost. Cel mai mare efort este concentrat n faza de dezvoltare a ciclului de via al produsului dei cea mai mare rat de ntoarcere o prezint fazele anterioare acestui punct (cerinele, specificaiile sistemului, analiza).

Varietatea din practic se refer la faptul c exist multe tehnici pentru producerea sistemelor software. Ca rezultat, ele sunt dificil de coordonat, variaz mult n ceea ce privete costul, flexibilitatea i ntreinerea lor. i totui exist sute de tehnici, automate sau nu, menite s ajute la coordonarea, dezvoltarea sau ntreinerea sistemelor software. O fireasc ntrebare care se pune este dac vreuna din aceste tehnici chiar merge. Studiile realizate au artat c aplicarea acestor tehnici au determinat scderea costurilor i obinerea unor sisteme mai flexibile. n realitate, problema este c prea puini le folosesc. Este uimitor ct de puin este folosit tehnologia ingineriei software n realitate. Se pare c ori nimeni nu citete aceste studii, ori nu exist interes de a le folosi acolo unde ele ar putea aduce cele mai mari beneficii. n primul rnd, nimeni nu crede c aplicarea unor tehnici de ingineria programrii, i n special a celor automate, ar salva ntr-adevr nite bani n al doilea rnd, eforturile pentru cercetarea, dezvoltarea i aplicarea acestor tehnici sunt fragmentare. Exist multe tehnici, dar ele sunt unice n general, nu pot fi folosite mpreun cu alte tehnici, sau nu merg pentru probleme reale. O alt problem este lipsa de consisten: nu exist un vocabular general acceptat n domeniul ingineriei programrii. Nu exist nici un proces sau model unic, general acceptat, de dezvoltare a sistemelor software. Fiecare companie are modul su propriu de a produce sisteme software. Lipsa productivitii. n domeniul ingineriei software, termenul de productivitate este nc nebulos. Ea ar putea nsemna: un volum mai mare de cod scris de ctre o persoan

micorarea costului produsului soft

creterea calitii produsului Probabil, productivitatea ar trebui vzut ca o sum a tuturor acestor factori. Studiile efectuate asupra acestui subiect au artat c productivitatea depinde de 30 variabile (pregtirea personalului, complexitatea produsului, cerinele produsului, timpul de predare, utilitarele folosite pentru producerea softului, calitatea managementului, limbajul de programare utilizat ). n general, exist o slab productivitate n producerea sistemelor software datorit lipsei de personal pregtit pentru aceasta i datorit cererii crescnde de produse soft. Un alt motiv pentru care problema productivitii nu e uor de rezolvat e pluralitatea scopurilor. Nu exist nici un beneficiu dac personalul a fost suficient de pregtit ca s predea produsul la timp dar acesta este att de slab ca performan nct e inutilizabil sau dac va fi nevoie de mult mai muli bani pentru a-l putea face s mearg. Un proiect software i propune de multe ori scopuri contradictorii: este dificil de a realiza un produs flexibil, eficient, utilizabil, extensibil, modificabil, etc. simultan (in unele sisteme, o mai mare siguran a acestuia nseamn mai multe verificri care determin un timp mai mare de execuie sau poate nsemna o proiectare mai flexibil a sistemului. Acestea pot mri costul produsului, timpul de producere i pot face sistemul mai greu de ntreinut.) O not final: un studiu interesant efectuat de Bell Laboratories a artat c doar aproximativ 13% din timpul unui programator este investit n programare. S-a estimat c 33% din timpul su e dedicat scrierii documentaiei. Dac se pune deci problema creterii productivitii, acesta ar putea fi un punct demn de luat in consideraie. In capitolele urmtoare se va examina o abordare a problemelor cu care se confrunt azi domeniul ingineriei programrii, prin utilizarea mediilor de dezvoltare a sistemelor software. Se sper ca prin aceasta s se reduc varietatea practicilor, s se creasc productivitatea i, n final, s se micoreze costul produsului. Pn n prezent s-au fcut pai importani n tehnologia ingineriei software pe toate fronturile: analiza cerinelor produsului, strategiile de implementare, modelele de cost, etc. Fiecare

din acestea urmrete s reduc din: costul ridicat al softului, variaia din practic i lipsa productivitii. Totui, dup mai bine de 20 ani criza softului nu este rezolvat. Cererea pentru producerea sistemelor software crete mai repede dect productivitatea realizrii lui. Greeli care se fceau n anii 70 se repet n continuare. Incapacitatea noastr de a stpni complexitatea unui sistem rezult n ntrzierea proiectului, depirea cheltuielilor i deficiene n ceea ce privete ndeplinirea specificaiilor sistemului. E nevoie de utilitare mai bune, de tehnici i metode mai bune, i, ceea ce este cel mai important, e nevoie de educaie i antrenare n acest scop.

Principalele soluii abordate pentru rezolvarea crizei software-ului


S-au pus n eviden cteva probleme majore privind dezvoltarea ingineriei programrii: costul ridicat al softului, varietatea din practic i lipsa de productivitate. De asemenea, prpastia dintre potenialul echipamentelor hardware i performanele sistemelor software devine din ce n ce mai mare. Acest potenial pierdut afecteaz cel mai mult marile organizaii care sunt dependente de sisteme software foarte complexe. Mai ru dect att, aceste sisteme sunt defectuoase i structurate att de rigid nct nu permit modificri majore ulterioare fr reproiectarea lor. Cteva din neajunsurile practicilor curente n procesul de dezvoltare a sistemelor software sunt: realizarea unor specificaii inconsistente, incoerente i incomplete

realizarea unor sisteme nereutilizabile responsabiliti i ndatoriri slab definite i controlate slabe performane ale produsului final inexistena unei metrici pentru testarea calitii sistemului nici un mijloc pentru a coordona complexitatea documentaie care nu ofer nici un ajutor efectiv etc.

Rezumm n continuare principalele eforturi care s-au fcut n direcia obinerii unui sistem software robust, care ndeplinete toate cerinele utilizatorilor. 1. Programarea monolitic. Programele mici pot fi construite n stil monolitic, ca o singur procedur sau un set de instruciuni. De obicei, ele sunt scrise de un singur programator, care poate cuprinde mental ntreaga imagine a procedurii. Sistemele mari, ns, nu pot fi realizate n acest fel. Cu ct sistemul e mai complex, cu att vor fi necesare echipe mai mari iar volumul de comunicri ntre membrii echipei va crete corespunztor. 2. Programarea modular. Principiul pe care se bazeaz este de a mpri programele n componente mai mici, ce pot fi construite independent. Acesta e modul de lucru folosit n ultimii 40 ani. Suportul elementar pentru programarea modular l reprezint subrutina, concept introdus n 1950. 3. Programarea structurat. n anii 60 s-au fcut eforturi mari n direcia dezvoltrii unui stil de programare mai disciplinat, mai consistent, concretizndu-se ntr-o manier top-down de proiectare a programelor. Ea se bazeaz pe principiul descompunerii funcionale, n virtutea creia sistemul e vzut ca un set de sub-sisteme, fiecare sub-sistem fiind la rndul su descompus dup acelai principiu. Programarea structurat a adus mbuntiri semnificative n calitatea software-

ului n ultimii 20 de ani. O problem serioas ns este c nu ntotdeauna este posibil anticiparea proiectului sistemului complet, nainte de implementare, i n cazul unei erori, ntregul proiect trebuie revizuit n aceeai manier top-down. 4. CASE- Computer-Aided Software Engineering

Ultima inovaie n programarea structurat este ingineria software asistat de calculator. Cu ajutorul mediilor CASE se coordoneaz procesul de descompunere funcional, definind grafic diagrame nlnuite i verificnd c toate interaciunile sistemului reflect regulile impuse. Sistemele avansate CASE pot realiza un sistem complet din diagramele proiectate i din toate informaiile asociate lor. Totui, acest proces nu e chiar att de automatizat cum pare la prima vedere. Practic, CASE traduce proiectul unui sistem din form grafic ntr-o form textual. Experiena de pn azi artat c dezvoltarea unui proiect complet, grafic, poate fi la fel de costisitor din punct de vedere al timpului ca i programarea lui. 5. Limbajele de generaia a IV-a (4GL) reprezint o alt abordare a programrii automate. Ele includ o gam larg de utilitare pentru automatizarea unor aplicaii de rutin (crearea de menuri, generarea de rapoarte, etc.). Au avantajul c pot fi folosite i de ne-programatori. Nu pot fi folosite pentru sisteme mari i pentru meninerea programelor modificate Abordarea orientat-obiect Analiza orientat obiect este o metod relativ nou, de analiz bazat pe obiecte i clase. Un obiect este o entitate, o ncapsulare a unor valori de atribute i a unui set de operaii acionnd asupra acestora. O clas este o descriere a unui set de obiecte cu atribuii i servicii comune. 6.

Medii pentru dezvoltarea sistemelor software (Software Development Environments)


Un mediu pentru dezvoltarea sistemelor software este o colecie de utilitare software i hardware pentru producia de sisteme software ntr-un domeniu specific. Exist trei tipuri de astfel de medii: medii de programare - pentru programare, testare, depanarea programelor;

medii CASE - orientate spre fazele de definire a specificaiilor software i a proiectrii sistemelor; medii de inginerie software - dedicate produciei de sisteme software complexe, cu un ciclu ndelungat de via, a cror ntreinere cost mai mult dect dezvoltarea lor i care sunt produse de echipe i nu de programatori individuali;

Acestea furnizeaz suportul pentru toate activitile de dezvoltare i de management. n practic, graniele dintre aceste tipuri nu sunt bine delimitate. Mediile CASE - sunt destinate diferitelor fazelor din dezvoltarea sistemelor. Aceste medii sunt orientate spre un suport grafic care e folosit n diverse metode de proiectare. Ele pot suporta fie o singur metod, fie o gam de cteva din cele mai cunoscute metode. Componentele tipice ntr-un mediu CASE sunt: un sistem de editare a diagramelor pentru crearea diagramelor fluxurilor de date, a hrilor de structur, a diagramelor de tip entitate-relaie (entity-relationship), a dicionarelor de date, a arborilor de decizie, etc.; informaiile despre aceste identiti sunt nregistrate ntr-o baz de date central (enciclopedie);

faciliti de analiz i verificare n timpul crerii diagramelor; faciliti ce permit utilizatorului de a regsi informaiile; dicionarul de date, coninnd informaii despre entitile folosite n proiectul sistemului; faciliti de generare a rapoartelor care folosesc informaiile din baza central de date i genereaz documentaia sistemului; utilitare de generare a formatelor ecran i document; faciliti import-export pentru schimbul de informaii dintre baza central de date i alte utilitare de dezvoltare; unele medii CASE suport generatoare de cod pe baza informaiilor de proiectare nregistrate n dicionarul de date.

Unele din criticile care au fost aduse acestor medii sunt urmtoarele: nu exist o standardizare care s fac informaia interschimbabil dintre diverse medii CASE;

nu exist faciliti care s permit utilizatorului s modifice regulile implicite ale metodei pe care mediul o suport, i s o adapteze problemei sale specifice; nu sunt faciliti suficiente pentru crearea unei documentaii de calitate; facilitile oferite pentru realizarea diagramelor determin o greoaie creare a acestora (diagrame nu foarte complicate pot necesita cteva ore de lucru); este necesar un mod automatizat de creare i aranjare a diagramelor, dat fiind un text de intrare; suportul pentru specificaiile formale este srac; suportul pentru proiectarea orientat-obiect este srac; de aceea, avantajele productivitii i scderii costului sistemelor soft prin folosirea unor tehnici ca analiza orientat obiect sunt negate cel puin datorit unor utilitare inadecvate.

Unele din aceste deficiene au fost deja remediate. n prezent, mediile CASE sunt valabile pentru IBM-PC sau pentru sisteme UNIX Unele medii permit transferul de date de la i spre alte aplicaii i pot genera documente de calitate PostScript. n continuare e dificil transferarea informaiilor din baza central de date a unui mediu CASE ctre altul, ceea ce oblig pstrarea mediului cu care a fost construit un sistem pentru a putea continua ntreinerea acestuia. O deficien serioas a mediilor CASE, din punct de vedere al ingineriei sistemelor software pe scar larg, este dificultatea integrrii lor cu sistemele de coordonare al configuraiei (configuration management system). Sistemele foarte mari au un ciclu de via ndelungat, ca urmare ele se pot modifica mereu, existnd n versiuni diferite. Sistemul pentru coordonarea configuraiei permite regsirea unei anumite versiuni, permite construirea unui sistem din componente i menine legturile dintre aceste componente i documentaia lor. Mediile CASE furnizeaz faciliti pentru proiectarea sistemului software dar aceste proiecte nu sunt automat legate de codul surs rezultat i documentaia utilizatorului. Ca urmare, multiplele versiuni ale unui sistem nu pot fi uor coordonate. Avantajele mediilor CASE: cu toate c experiena n folosirea acestor medii nu e foarte ndelungat, unii utilizatori au declarat o reducere a timpului necesar n dezvoltarea sistemului i o cretere a productivitii; documentaia este actualizat dup orice modificare n proiectul i codul sistemului;

modificrile sunt mai uor de realizat; o modificare a cerinelor utilizatorilor determin o modificare simpl n codul surs, prin folosirea acestor medii; activitatea de ntreinere este mult simplificat, deoarece documentaia este realizat odat cu dezvoltarea sistemului i datorit unei abordri disciplinate pentru dezvoltarea sistemului; ofer un limbaj comun tuturor celor implicai n proiect.

Pe msur ce standardele pentru construirea acestor medii sunt definitivate i publicate, mediile CASE vor evolua spre mediile ingineriei software. Mediile de inginerie software - sunt colecii de utilitare software care acioneaz ntr-un mod integrat. Caracteristicile mediului de inginerie software:

Facilitile mediului sunt integrate. Toate utilitarele sunt interfaate cu un sistem de management al obiectelor (OMS), astfel nct ieirea unui utilitar reprezint intrarea n altul. Posibilitatea coordonrii mai multor versiuni ale aceluiai sistem software. Toate produsele rezultate n cursul procesului de dezvoltare pot face subiectul managementului de configuraie (care asigur asocierea corect a tuturor documentelor-specificaii, proiect, cod, documentaia utilizatorului, etc. - corespunztoare unei versiuni, completitudinea i consistena lor). Furnizeaz faciliti pentru suportarea tuturor activitilor de dezvoltare software (specificarea, proiectarea, implementarea, testarea, documentarea, depanarea, etc.).

Concluzii Se pare c un mediu pentru dezvoltarea sistemelor este mai util n perioada urmtoare finalizrii i predrii sistemului, perioad care reprezint 80% din cheltuielile totale ale sistemului i 90% din ciclul de via al acestuia. Folosirea mediilor de dezvoltare a sistemelor software pot ajuta n mare msur la rezolvarea problemelor cu care se confrunt procesul de realizare a produselor software. Dup o perioad de timp, cheltuielile pentru producerea sistemelor vor scdea iar calitatea produselor software va fi mbuntit. Ele nu reprezint totui un panaceu pentru aceast problem. Mediile de dezvoltare nu pot nlocui gndirea, nu pot garanta o coordonare eficient a proiectului, nu pot nlocui firetile erori umane, nu pot garanta c tim ceea ce dorim s facem, etc.