You are on page 1of 14

39

3
DEZVOLTAREA PRODUSELOR SOFTWARE

3.1. Instrumente integrate de inginerie software


Pentru instrumente integrate de inginerie software, în literatura franceză de specialitate se foloseşte terminologia
de atelier de inginerie software. Noţiunea de Atelier implică o idee suplimentară şi anume aceea de ansamblu de
instrumente integrate. Ancheta AFCET - CXP 1992 asupra practicii de inginerie software în Franţa dă următoarea
definiţie :
Un Atelier de Inginerie Software (AIS) este un ansamblu integrat de instrumente articulate în jurul unui referenţial
care permite automatizarea fazelor ciclului de viaţă al software-ului.
Această definiţie face referinţă la ciclul de viaţă al software-ului, care va fi definit ulterior cu mai multă precizie.
Foarte pe scurt este vorba despre diferitele faze prin care trece software-ul de la concepţie până la punerea în
exploatare, trecând prin scrierea şi punerea la punct a programelor .
Se poate presupune din definiţia de mai sus că un AIS trebuie să automatizeze toate fazele din ciclul de viaţă al
unui produs software, ceea ce în practică conduce la a rezerva numele de atelier de inginerie software pentru un număr
foarte restrâns de instrumente. Astfel, un ansamblu de instrumente poate fi bine articulat în jurul unui referenţial unic, dar
nu poate fi, în această manieră, bine integrat. Din contra, diferite instrumente pot fi bine integrate, fără a utiliza un
referenţial unic, ceea ce este, fără îndoială, dificil de realizat. Se ajunge în acest mod la următoarea definiţie:
Se numeşte Atelier de Inginerie Software un ansamblu de instrumente integrate care acoperă o bună parte din
ciclul de viaţă şi care pun în operă software-ul.
Cerinţele utilizatorilor pentru instrumentele integrate sunt astăzi foarte pretenţioase. Acestă integrare se loveşte de
mai multe inconveniente şi anume:
- Absenţa unui standard : De exemplu: AD/Cycle n-a justificat speranţele puse în el, PCTE rămâne limitat la
"universul" UNIX şi n-a pătruns într-o manieră semnificativă în lumea gestiunii, IRDS a dat naştere la câteva "punţi" între
produse, dar influenţa sa este limitată.
- Existenţa mai multor instrumente performante dar neintegrate: furnizorii de astfel de instrumente ezită destul de
mult să investească în vederea integrării cu alte produse, iar absenţa unui standard face să nu fie asigurată perenitatea.
- Cele câteva instrumente în stare să asigure o acoperire a întregului ciclu de viaţă al unui produs software sunt
rareori performante în totalitatea funcţiilor lor; în general în jurul unui nucleu, care este un instrument şi care reprezintă
de fapt competenţa lui, furnizorii au dezvoltat module (funcţii) ce lipseau pentru asigurarea unei acoperiri mai mari a
ciclului de viaţă. Dar aceste componente sunt în general de un nivel inferior componentelor de origine. Pentru a evita
aceste neplăceri mulţi furnizori specialişti în instrumente de concepţie preferă să apeleze la o alianţă cu alţi furnizori
specializaţi în instrumente de realizare. Rezultatul poate fi bun, dar integrarea de produse rezultate din această alianţă
se cere verificată.

3.2. Direcţii de studiu într-un atelier de inginerie


software
Vom renunţa la termenul de atelier de inginerie software şi vom discuta numai despre instrumente pentru inginerie
software. Problema pentru un utilizator este de a şti dacă un instrument este adecvat nevoilor sale sau nu. Deşi nu este
uşor de comparat şi studiat produse care prin funcţionalitate sunt atât de diferite, se pot totuşi stabili câteva criterii de
comparaţie cum ar fi :
- Ciclul de viaţă al software-ului: Un instrument poate acoperi o parte mai mare sau mai mică din ciclul de viată.
- Metodele: Majoritatea instrumentelor se bazează pe metode sau suportă diferite metode. Acestea pot fi mai
aproape sau mai departe de cele utilizate deja în serviciile de informatică şi, în consecinţă, s-ar putea ca utilizarea noului
instrument să ia destul timp.
40
- Calitatea: Unul din scopurile propuse atunci când se utilizează un instrument de inginerie software este de a
realiza produse de calitate mai bună. Dar calitatea vizează diferite aspecte, care sunt câteodată contradictorii între ele şi
nu în egală măsură importante.
- Productivitatea: Un alt scop propus al instrumentului este de a produce software repede. Dar când se vorbeşte
de productivitate nu cumva ea este în contradicţie cu calitatea ?
- Măsuri şi modele: Este bine să se vorbească despre calitate şi productivitate, dar este şi mai bine ca acestea să
se poată măsura. Există modele de cost şi fiabilitate, dar puţine instrumente dispun de mijlocul pentru a-şi măsura
propria eficacitate.
- Instrumente: Nu este inutil atunci când studiem un mediu de inginerie software să avem în minte mai multe astfel
de instrumente. Aceasta va permite de a detecta rapid care este domeniul de utilizare, care sunt punctele lui forte, sau
care, din contra, lipsesc în cazul mediului studiat.

3.3. Paradigmele dezvoltării software-ului


Există mai multe abordări pentru dezvoltarea software-ului, bazate pe ideea ciclului de viaţă expus anterior, sau
pe alte idei radical diferite. Cele mai bine cunoscute modele de proces, numite paradigmele de dezvoltare software,
sunt:
- modelul în cascadă
- modelul de dezvoltare exploratorie
- modelul de dezvoltare evolutivă
- modelul în spirală.
Primele trei au fost foarte des utilizate, mai ales primul (modelul în cascadă).
Modelul în spirală, sugerat de Boehm în 1988, merită de asemenea atenţie. Există şi alte modele, cum ar fi:
- abordarea pe baza transformării formale ;
- dezvoltarea orientată pe obiecte

3.3.1. Modelul în cascadă


Ciclul de viaţă, aşa cum s-a văzut deja, este o modelare convenţională a succesiunii etapelor prin care trece un
produs software, de la concepţie până la mentenanţă. Diferitele etape pot varia uşor de la o metodă la alta, dar în linii
mari se regăsesc întotdeauna cele reprezentate în fig.3.1, numită modelul în cascadă.
O deficienţă a modelului în cascadă este aceea că din punct de vedere vizual nu reprezintă un ciclu.
Reprezentarea într-o astfel de manieră este prezentată în fig.3.2.
41

Fig.3.1. Modelul în cascadă după B. Meyer

Modelul în cascadă este adecvat pentru o clasă foarte largă de sisteme software şi a fost aplicat cu succes
pentru multe produse software.
Acesta permite o abordare sistematică în care fiecare etapă este bine definită şi produce la rândul ei o ieşire
care devine intrare pentru următoarea etapă.
Principalele avantaje ale acestei metode sunt:
- o abordare disciplinată pentru dezvoltarea software-ului ;
- cerinţa ca documentaţia care rezultă să fie verificată la fiecare fază a ciclului de dezvoltare ;
- asigurarea şi monitorizarea calităţii la fiecare etapă.
Totuşi există un neajuns major în această abordare, şi anume:
Abordarea liniară sistematică din modelul în cascadă, cu iteraţii limitate numai la etapele imediate anterioare,
poate genera tendinţa ca după un număr mic de iteraţii să se “îngheţe” dezvoltarea acelei părţi şi să se continue cu
stadiile următoare. Consecinţa este că sistemul livrat utilizatorului nu execută ceea ce acesta doreşte. Există încă două
critici pentru acest model:
- Este dificil, dacă nu chiar imposibil câteodată, de a produce solicitări de specificare care să fie complete şi corecte ;
- Nu este pus la dispoziţia utilizatorului un model de lucru, înainte de faza de implementare şi testare. Neajunsurile
acestui model au permis dezvoltarea modelului exploratoriu şi evolutiv.
42

Fig.3.2. Ciclul de viaţă reprezentat ciclic

3.3.2. Modelul exploratoriu


Acest model se bazează pe ideea dezvoltării unui model de lucru (un prototip lent) al sistemului, care să permită
utilizatorului să-l experimenteze şi apoi pe baza comentariilor pe care acesta le face să poată să se modifice sistemul.
Fig.3.3 ilustrează această abordare. Respectiva abordare se mai numeşte şi “build-and-fix” şi se potriveşte pentru
programele mici, dar este nesatisfăcătoare pentru produsele software pe scară largă.
Totuşi, programarea exploratorie este utilă atunci când sunt imposibil de stabilit specificaţiile sistemului. Inteligenţa
artificială este unul dintre domeniile în care această abordare este potrivită.
Chiar dacă proiectarea şi implementarea sunt utilizate în manieră clasică, în unele momente este important ca
proiectantul să utilizeze tehnici şi mecanisme care să permită dezvoltarea rapidă şi iterativă a sistemului. Aceasta se
poate obţine prin:
- utilizarea de limbaje de nivel înalt ca LISP, PROLOG
- sisteme hardware dedicate
- instrumente CASE şi alte instrumente de dezvoltare a software-ului.
În această abordare, verificarea este imposibilă, astfel încât validarea de către utilizator a sistemului trebuie să
demonstreze că produsul software este potrivit cu dorinţele utilizatorului. Trebuie de asemenea avut în vedere că
produsul final nu are o structură bine definită şi în acest caz mentenanţa unui astfel de produs devine dificilă şi scumpă.
Aceasta este principala raţiune pentru care respectiva metodă nu trebuie aplicată pentru sistemele mari cu viaţă lungă.
O altă modalitate de a construi sisteme software este de a utiliza o metodă în care produsul este proiectat,
dezvoltat şi testat în timp ce este construit. Se construieşte, iniţial parţial, un subsistem care manifestă funcţionalităţile
de mai târziu. La început este construită şi implementată numai o parte (un subsistem).
Dacă ea lucrează corect, altă componentă este proiectată, testată şi integrată în sistemul existent. Procesul
continuă astfel până când întregul sistem este complet şi testat.
Această abordare evită efectul “big-bang” în care nimic nu se întâmplă mult timp şi când brusc, într-o zi, sistemul
este complet. Acest mod de abordare se numeşte dezvoltare incrementală şi se foloseşte în prototipizare.
43

Fig.3.3 Modelul dezvoltării exploratorii

3.3.3. Modelul dezvoltării evolutive


3.3.3.1. Prototipizarea
Modelul în cascadă, prezentat mai înainte, nu include faza de prototipizare. Experienţa a marcat într-adevăr
importanţa deosebită pe care o are această fază în producerea unui sistem informatic corect. În funcţie de caz, prototipul
poate pur şi simplu să clarifice fazele descrise deja, sau eventual, să evidenţieze necesitatea uneia noi.
De aceea se disting două abordări ale prototipizării, şi anume: prototipul rapid şi jetabil, iar al doilea prototipul lent
şi recuperabil. În versiunea prototipului jetabil se construieşte un prototip rapid, cât mai repede posibil. Acesta permite să
se testeze reacţia utilizatorului, neservind la rafinarea specificaţiilor. El nu va fi niciodată folosit în faza de realizare.
Opusul este prototipul recuperabil, care este mai mult o dezvoltare incrementală: în locul construirii în totalitate a
unui program, apoi a altuia şi aşa mai departe (aşa cum se procedează când nu se prototipizează), se constuieşte
fiecare program în paşi succesivi . Se constuieşte 20% din primul program, 20% din al doilea, 20% din al treilea, acest
procent reprezentând de exemplu afişajul pe ecran, câteva mici controale pentru a putea face utilizatorului o
demonstraţie şi a aştepta reacţiile lui, în ideea implementării lor imediate. Se ajunge astfel la o dezvoltare incrementală
a sistemului.
Tabelul 3.1
Rezultatul etapelor ciclului de viaţă după B. Meyer
Etapă Rezultat
Faza de exploatare:
- dosar de întreţinere
- decizii (nu se face, se cumpără, se face, etc).
- buget aproximativ
Studiu preliminar Faza conceptuală:
- caiet de sarcini
- plan general al proiectului
- buget precis
- definirea restricţiilor
Specificare Document de specificaţie (funcţii şi performanţe)
Prima versiune a manualului de utilizare
Plan detailat al restului proiectului
Plan de validare (test)
Concepţia generală Definirea principalelor structuri de date
Descompunerea sistemului în module
3.3 Paradigmele dezvoltării software -ului
44
Descrierea rolului fiecărui modul
Concepţia detaliată Descrierea detaliată a structurilor de date şi de module
Scrierea Testare de programe, fiecare modul verificat separat
programelor
Validarea
individuală
Validare globală Evidenţa remedierilor
Remedii Rapoarte de inspecţii şi de validare
Difuzare Versiuni de programe şi de documentaţie adaptată
Punere în diferitelor categorii de utilizatori
Exploatare
Exploatare Programe în funcţiune
Mentenanţă Rapoarte de incidente şi corectare

Este clar că prototipizarea se găseşte undeva la frontiera dintre concepţia detaliată şi scrierea programelor. Modul
de lucru cu prototipizare incrementală face cele două faze interdependente, în contrast cu prototipul rapid, care din
contra serveşte la a formaliza cât mai mult posibil şi deci la a termina cât mai complet faza de specificare detaliată.
Prototipul jetabil face parte în totalitate din concepţia detaliată. El se "aruncă" apoi şi se scriu alte programe .
În multe cazuri este de dorit să se meargă cu prototipizarea până la nivelul concepţiei generale, dacă de exemplu
ergonomia sistemului este un factor determinant pentru utilizatori, sau pentru alte opţiuni care au un impact important
asupra concepţiei aplicaţiei. O descriere mai detaliată a ceea ce conţine şi mai ales ceea ce se produce în fiecare fază
se găseşte în tabelul 3.1.
În cele ce urmează, se va utiliza ca model de referinţă pentru descrierea etapelor ciclului de viaţă, modelul
tradiţional al cascadei.

3.3.3.2. Dezvoltarea evolutivă


Acest model, cunoscut de asemenea sub numele de prototip rapid, încearcă să rezolve neajunsul modelului în
cascadă legat de faptul că până la construirea produsului final nu se ştie cu exactitate ce a dorit într-adevăr utilizatorul.
Dezvoltarea evolutivă este similară abordării exploratorii, dar scopul acestei dezvoltări este de a stabili cerinţele
utilizatorului, mai ales atunci când este dificil de făcut acest lucru, sau când documentele de specificaţii existente sunt
ambigui sau incomplete. Această tehnică este în esenţă o metodă de analiză a specificaţiilor.
45

Fig.3.4 Modelul prototipului rapid

Plecând de la stabilirea în mare a specificaţiilor, inginerul software construieşte un prototip rapid şi lasă clientul să-
l experimenteze. În momentul în care clientul este satisfăcut, proiectantul poate trece la elaborarea documentului cu
specificaţiile produsului, care este apoi folosit în construcţia software-ului utilizând, de exemplu, un model în cascadă
(fig.3.4).
Când se construieşte un prototip, proiectarea şi implementarea se realizează în faze diferite de timp.
Cele două abordări pot fi combinate în mod util aşa cum se arată în fig. 3.5. În acest caz, stadiul de analiză a
cerinţelor din cadrul modelul în cascadă a fost înlocuit de stadiul necesar al prototipizării iar bucla de feedback a
dispărut.
Punctul forte al acestui model combinat este acela că, în acest mod dezvoltarea software-ului devine, în mod
esenţial, un proces complet liniar. Datorită completitudinii specificaţiilor utilizatorului, buclele de reacţie (feedback) din
stadiile precedente par a fi, din ce în ce mai puţin, necesare.
46

Fig.3.5. Modelul integrat “cascadă şi prototipizare”

3.3.4. Modelul în spirală


În cazul modelului în cascadă, analizat anterior, unul dintre reproşurile aduse modelului este acela că se
concentreză punerea la punct a unui produs informatic pe corectarea codului, în timp ce cele mai costisitoare erori
provin, aşa cum s-a amintit deja, din faza de concepţie.
Prototipizarea nu aduce la acestă critică decât un răspuns parţial, şi anume: permite de a rafina mai bine
specificaţiile, dar punerea la punct se realizează numai din punctul de vedere al codului şi nu şi al specificaţiilor.
Modelul în spirală (fig.3.6), cunoscut şi sub numele de “modelul bazat pe risc”, a fost introdus în 1988 de Boehm.
47

Fig.3.6. Modelul în spirală

Ideile de bază în această abordare sunt:


- în primul rând, recunoaşterea că există multe riscuri care pot apare în diverse stadii ale dezvoltării software-ului;
- în al doilea rând, determinarea diferitelor căi de minimizare a riscurilor identificate în timpul utilizării prototipului
şi, de asemenea, a altor tehnici adecvate.
Riscul reprezintă “orice” funcţionează rău, sau “o situaţie” care necesită o atenţie deosebită. De exemplu : riscul
ca specificaţia să nu fie completă, sau riscul ca staff-ul să nu fie suficient de instruit în utilizarea unor tehnici/instrumente
de lucru, sau riscul ca timpul sau banii să nu fie suficienţi pentru o anumită activitate.
Ideea este ca înainte de a trece la un nou stadiu să se iniţieze o analiză a riscului care să cuprindă:
- determinarea obiectivelor, alternativelor şi restricţiilor pentru acel stadiu;
- identificarea oricărui risc implicat în acel stadiu;
- analiza diferitelor căi pentru rezolvarea riscurilor identificate;
- analizele alternativelor pentru atingerea obiectivelor stadiului respectiv.
Un alt reproş care i se aduce modelului în cascadă se referă la abordarea statică, în care nu se poate începe o
fază dacă precedenta nu este terminată şi nu este adaptată imprejurărilor în care evoluţiile sunt rapide.
Modelul în spirală a avut ca scop să răspundă la această critică. În acest model punerea la punct este efectuată
asupra specificaţiilor: specificaţiile nu sunt toate închegate, dar prototipuri din ce în ce mai avansate au fost prezentate
utilizatorului, până la soluţia completă. Se ajunge astfel, prin etape incrementale succesive, la produsul software final.
Aceste tehnici de dezvoltare, dintre care cele mai cunoscute sunt RAD (Rapid Application Developement) şi JAD
(Joint Application Development), presupun că se dispune de o specificare direct executabilă pe maşină, sau de
generatoare care pot să producă direct cod plecând de la specificaţii de nivel înalt.
Or dacă această abordare dă rezultate bune pentru sistemele de mică complexitate, nu se dispune, pentru
moment, de limbaje sau instrumente de specificare care să fie totodată suficient de generale încât să permită
specificarea unui sistem de gestiune complexă, şi suficient de formale încât să poată să genereze automat, sub o formă
sau alta, cod executabil.
Modelul în spirală prezintă mai multe puncte de interes, şi anume:
- Permite o abordare iterativă mai bună : dacă se consumă prea mult timp pentru a elabora specificaţiile, deja
condiţiile s-au schimbat când s-a ajuns la realizare.
- Permite o abordare interactivă mai bună: utilizatorul este implicat în permanenţă în proiect, într-o manieră
interactivă.
3.4. Metode şi calitate
48
- Atrage atenţia asupra distincţiei care se face între eroarea de codificare şi eroarea de concepţie : chiar dacă
detecţia erorii se face în faza de punere la punct a proiectului, ea trebuie corijată la nivelul fazei de concepţie, dacă de
aici provine eroarea. Un punct forte îl constituie de asemenea faptul că riscul poate fi condus.

Modelul în cascadă (simplificat)

Modelul în spirală (simplificat)

Fig. 3.7. Modelele în cascadă şi în spirală

- Este foarte important ca toate riscurile să fie identificate şi analizate. Aceasta presupune să se identifice riscurile
potenţiale, să existe cunoştinţe şi experienţă pentru găsirea căilor de rezolvare. Deoarece foarte puţini proiectanţi de
software ştiu să rezolve astfel de probleme, analiza riscului ar putea deveni foarte scumpă.
- În acest caz, analiza riscului devine o deficienţă a acestui model. Această metodă este adecvată sistemelor
mari, cu viaţă lungă.

3.4. Metode şi calitate

3.4.1. Metode
Este foarte adevărat că nu s-au aşteptat instrumentele de inginerie software pentru pentru a utiliza metode de
proiectare, cum ar fi programarea structurată de exemplu, care, chiar dacă n-a fost în totalitate aplicată, a schimbat
incontestabil maniera de realizare a programelor.
Metodele apărute au obiective diverse (unele sunt orientate spre specificaţii, altele spre concepţie, sau spre
realizare, altele orientate mai mult înspre date, altele, din contra orientate asupra tratărilor efectuate asupra datelor.
Unele au un grad de generalitate mai mare, altele mai mic, unele sunt destinate aplicaţiilor de gestiune, altele,
aplicaţiilor tehnico-ştiinţifice.
Ecuaţia "instrumente- metode" se complică şi mai mult dacă se ţine cont de diferitele domenii în care se aplică.
De exemplu, se tinde să se creadă despre concepţia orientată pe obiecte că este cea mai bună pregătire a unei realizări
care utilizează programarea pe obiecte, dar nu este singura .

3.4.2. Calitatea
Unul dintre principalele obiective ale unui instrument de inginerie software este de a realiza software de mai bună
calitate. Tabelul 3.2 elaborat de Mayer, prezintă cu titlu de exemplu zece factori de calitate ai software-ului. Aceşti factori
pot fi contradictorii, cum ar fi de exemplu portabilitatea şi integritatea care aduc adesea prejudicii eficacităţii, dar oferă o
platformă comună de comparare şi evaluare a produselor software.
Calitatea va fi adesea rezultatul unui compromis. Când se lucrează fără un instrument de realizare, acest
compromis se face într-o manieră inconsistentă de către programator, ceea ce nu este de dorit.
Când se lucrează cu un instrument software, aceasta se face într-o manieră mai mult sau mai puţin voluntară, de
către constructorul instrumentului software respectiv.
Între eficacitate şi fiabilitate, majoritatea instrumentelor au ales deja, dar mai trebuie ca nivelul de compromis care
a fost adoptat să fie şi acceptat de cei care cumpără instrumentul software respectiv.
Validitatea este aptitudinea software-ului de a-şi îndeplini corect funcţiile.
Transpusă în planul concepţiei, această aptitudine ajută ca specificaţiile definite să reflecte într-adevăr cerinţele
utilizatorilor.
49
Fiabilitatea este aptitudinea produsului software de a funcţiona în condiţii anormale, în conformitate cu
specificaţiile sale de proiectare (definiţie dată de Mayer). De exemplu, rezistenţa la introducerea de date incorecte,
reluări posibile în caz de pană a sistemului (software sau hardware), posibilităţile de a lucra când totuşi sistemul este
degradat, etc. Acest factor nu este independent de contextul tehnic în care se utilizează aplicaţia software.

Tabelul 3.2
Factorii de apreciere ai calităţii - B. Mayer
Factor Definiţii
0 1
Validitate Aptitudinea produsului software de a îndeplini exact funcţiile
sale, definite prin caietul de sarcini şi prin specificare.
Fiabilitate Aptitudinea produsului software de a funcţiona în condiţii
Anormale
Extensibilitate Uşurinţa cu care un software se pretează la o modificare sau
la o extindere a funcţiilor solicitate.
Reutilizibiltate Aptitudinea unui produs software de a fi reutilizat, în totalitate sau şi
parţial, într-o nouă aplicaţie.
Compatibilitate Uşurinţa cu care un sistem poate fi combinat cu altele
Eficacitate Utilizarea opţională a resurselor materiale (procesoare,
memorie internă şi externă, protocoale de comunicaţie, etc)
Portabilitate Uşurinţa cu care un produs poate fi transferat pe medii
diferite hardware şi software.
Verificabilitate Uşurinţa cu care se pregătesc procedurile şi testele de validare
(în particular “jocurile de încercare”) şi procedurile de
detectare a erorilor care urmează unui incident în exploatare.
Integritate Aptitudinea software-ului de a-şi proteja codul şi datele de
accesări neautorizate.
Uşurinţa de Facilitatea de înţelegere, de utilizare, de pregătire a datelor, de
utilizare interpretare a erorilor, de revenire în caz de utilizare eronată.

Extensibilitatea este posibilitatea de a modifica cu uşurinţă software-ul, în ideea adăugării de noi funcţii
sistemului . Este un factor de calitate dificil de măsurat, pentru că adesea se leagă de nivelul limbajului de programare
(de exemplu, este mai uşor de modificat în Cobol decât în limbaj de asamblare, este mai uşor de modificat în Pascal
decât în Cobol).
Reutilizarea este aptitudinea software-ului de a putea fi utilizat în aplicaţii noi. Conceptul nu este nou, de multă
vreme se fac subprograme generale de tratare a datelor, sau schelete de programe care să automatizeze diverse funcţii.
Propietatea de moştenire apărută în abordarea orientată pe obiecte a permis ca metodele scrise pentru un obiect
să poată fi moştenite de un altul.
Compatibilitatea, a nu se confunda cu portabilitatea, reprezintă uşurinţa cu care un produs software poate fi
combinat cu altele. Este nevoie în unele situaţii să se achiziţioneze aplicaţii din exterior (care vor deveni subsisteme în
aplicaţia care se realizează) şi care trebuie să funcţioneze împreună cu aplicaţiile deja existente.
Eficacitatea este utilizarea optimală a resurselor materiale. De când există Informatica, puterea maşinilor se
dublează la fiecare 18 luni, dar tot este insuficient pentru a putea ignora problemele de performanţă.
Pe de o parte, se realizează aplicaţii din ce în ce mai sofisticate care presupun calculatoare performante, pe de
altă parte gradul de putere al maşinii este consumat pentru confortul utilizatorului : pe un Macintosh sau un PC sub
Windows, mai mult de 80% din capacitate este utilizată pentru a trata interfaţa grafică, şi numai 20% rămân pentru a
putea fi utilizaţi de aplicaţie.
Portabilitatea este uşurinţa cu care un produs software poate fi transferat pe un alt hardware sau sistem de
operare.
Acesta este un criteriu pe care furnizorii de instrumente îl pun în faţă, pentru că permite diminuarea dependenţei
utilizatorului de hardware.
Verificabilitatea este facilitatea prin care se pregătesc procedurile de tratare şi validare a sistemului. Este un
criteriu interesant la care trebuie reflectat puţin: se poate cu uşurinţă verifica dacă un sistem merge sau nu, se pot
construi teste de încercări care să garanteze că o parte din software sau tot sistemul funcţionează ?
Când ne confruntăm cu o problemă de testare a unui software care nu este cunoscut şi nici nu a mai fost realizat
până atunci, nu este uşor de stabilit dacă rezultatul furnizat de sistem este corect sau nu.
3.5 Productivitatea
50
Integritatea este aptitudinea sistemului de a-si proteja codul şi datele de utilizări neautorizate; este mai mult
o caracteristică generală de mediu în care trebuie să funcţioneze sistemul, decât o caracteristică directă furnizată prin
instrumentul software. Dar, instrumentul trebuie eventual să suplinească carenţele mediului de dezvoltare.
Facilitatea de utilizare reprezintă tot ceea ce este legat de ergonomia aplicaţiei, de uşurinţa cu care este utilizat.
Nu este acelaşi lucru pentru utilizator dacă înţelege intuitiv şi repede modul în care funcţioneză sistemul sau îi trebuie
trei luni pentru a-l face operaţional.
De asemenea, nu este acelaşi lucru dacă primeşte un mesaj de eroare clar, sau trebuie să consulte un manual
pentru a-i înţelege semnificaţia.
Ergonomia este pe punctul de a deveni un criteriu foarte important pentru funcţionalitatea însăşi a sistemului,
pentru că, fără îndoială, se consideră drept “competenţă“ a unui sistem dacă el se achită corect de sarcina sa (criteriul
de validitate).

3.5. Productivitatea
Al doilea obiectiv al unui instrument software este de a produce software cât mai repede posibil . Cum calitatea şi
productivitatea acoperă aspecte diferite, ele presupun adesea un compromis. Dacă se vizează productivitatea în
mentenanţă, va trebui fără îndoială să se investească mai mult în concepţie, pentru a găsi structuri de date mai generale
şi să se determine ceea ce poate fi parametrizat.
Dar aceasta se va face în detrimentul termenului de livrare al software-ului.
Dacă, din contra, obiectivul este să fie “ceva“ care funcţionează, modul de abordare este altul. Sunt situaţii în nu
există altă alegere sau sunt cazuri extreme care pot justifica existenţa chiar a două instrumente de dezvoltare, unul care
să producă mai repede, dar care furnizează un cod mai puţin eficient sau mai puţin mentenabil, celălalt care permite să
se lucreze mai riguros, atunci când este timp pentru aceasta.
Productivitatea are punct de conflict cu calitatea atunci când se atinge un nivel minim al acesteia din urmă, sub
care nu se poate coborâ.
Productivitatea unui proiect trebuie să se măsoare în mod global, la capătul mai multor ani de utilizare care să
includă toate fazele, de la concepţie la mentenanţă. În practică, se întâmplă relativ rar să se măsoare productivitatea în
afara fazei de realizare, ceea ce este cu certitudine interesant, dar nu reprezintă decât o mică parte din ceea ce trebuie
măsurat.
Cu cât productivitatea de realizare a unui proiect este mai mare, cu atât timpul de livrare al produsului scade şi
implicit şi costul produsului va fi mai mic. Mai mult, interesul producătorilor de software pentru achiziţionarea de
instrumente performante de lucru care să mărească productivitatea va fi în continuă creştere.
3.6. Măsurători şi modele
Ingineria software se vrea un demers stiinţific. Una dintre caracteristicile ştiinţei moderne este aceea că se
cunoaşte bine ceea ce se poate şi şti, şi măsura.
Astfel, calitatea şi productivitatea unui instrument software trebuie să poată fi verificată prin date cantitative. Dacă
aceasta este tot timpul cazul productivităţii, acest lucru se întâmplă foarte rar în cazul calităţii.

3.6.1. Măsurarea calităţii


În 1986 Bertrand Meyer a furnizat câteva indicaţii asupra modelelor de fiabilitate. În practică unele domenii din
ingineria software se pretează, mai mult decât altele, la măsurători statistice. De exemplu, un atelier de servicii de
Informatică poate să cunoască numărul şi tipul de cereri de intervenţie care se fac pe un produs software pentru
aplicaţiile sale şi să verifice dacă introducerea unui instrument software permite să se micşoreze acest număr.
În aceeaşi manieră, într-un domeniu mai restrâns cum este cel al gestiunii schimbărilor, este relativ uşor de verificat
dacă introducerea unui instrument a permis diminuarea numărului de incidente datorate implementării defectuoase sau
incomplete.

3.6.2. Măsurarea costului


Cei mai mulţi autori nu sunt interesaţi în privinţa modelelor de cost. Cel mai cunoscut pare să fie modelul COCOMO
a lui Boehm. Se dă în acest caz o idee destul de precisă a numărului de ore/om necesare pentru producerea unui
software care să reprezinte un număr de linii. S-ar părea că lucrurile sunt destul de simple în ceea ce priveşte
măsurarea, dacă instrumentul software permite să se mărească numărul de linii de cod produs pe lună/om.
În practică lucrurile nu sunt atât de simple deoarece:
3.7 Componentele unui atelier software (instrumente CASE)
51
Nu se proiectează practic niciodată aceeaşi aplicaţie de două ori, însă gradul diferit de dificultate poate infuenţa
productivitatea. Totuşi, experienţa arată că în privinţa proiectelor de dimensiuni comparabile, în condiţii tehnice şi cu
echipe de asemenea comparabile, se obţin rezultate apropiate. Cu instrumente moderne de realizare, nu totul se traduce
sub formă de linii echivalente de cod.
De exemplu, cum se pot compara o instrucţiune SQL cu 20 de linii Codasyl necesare pentru a exprima aceaşi
funcţie într-o bază de date ?
Adesea produsul software rezultat din utilizarea unui instrument include reutilizarea de programe generate sau
scrise iniţial cu ajutorul unui instrument software.
Generatoarele de cod au o manieră tenace de a produce mai multe linii de cod decât produce manual un
programator ( mediu dotat). Dacă un programator care scrie 1000 de linii de cod pe lună produce 10 000 linii cu ajutorul
unui instrument, nu se poate spune că a deveni subit de 10 ori mai productiv, deoarece, trebuie să se ştie la câte linii
scrise manual corespund celelalte 10 000 de linii.
În plus, nu trebuie uitat faptul că acele linii de cod trebuie testate nu numai din punctul de vedere al sintaxei, ci şi
al corectitudinii logicii.
În concluzie, dacă dorim să ştim ceea ce vrem să obţinem de la un instrument software (calitate şi productivitate),
dacă dispunem de câteva elemente care să poată fi măsurate, ne rămâne un drum lung de parcurs pentru a obţine o
măsură ştiinţifică (adică repetabilă în timp, predictibilă şi cu o marjă de eroare cunoscută) a acestor caracteristici.
3.7. Componentele unui atelier software
(instrumente CASE)
Nu există definiţii universal acceptate în ceea ce priveşte componentele unui atelier software, nici în ceea ce
priveşte vreo tipologie bine stabilită în privinţa instrumentelor de inginerie software.
Urmărind ciclul de viaţă, se pot evidenţia instrumentele următoare: instrumente de specificare şi de concepţie,
instrumente de realizare, gestionare de schimbări şi reconfigurări, instrumente de îmbunătăţire a aplicaţiilor, instrumente
de gestiune a proiectului şi dicţionare.

3.7.1. Instrumente de specificare şi de concepţie


- Editoarele de modele permit de a concepe şi de a specifica aplicaţiile. Ele sunt adesea în dublă interfaţă, textuală
şi grafică. Editoarele de modele se completează adesea cu instrumente de verificare care să permită controlarea
coerenţei şi completitudinii modelelor, şi cu instrumente de documentare.
- Generatoarele de machete permit generarea de formate ecran sau de etape de pornire a unui model de tratare
sau a unui model de date.
- Prototipurile, vecine cu generatoarele de machete, merg puţin mai departe în materie de tratare. Multe
instrumente permit scrierea unui scenariu, execuţia lui în faţa utilizatorului, dându-i iluzia de aplicaţie reală care va fi,
mai târziu, la dispoziţia sa. Se utilizează adesea instrumente de realizare pentru a efectua prototipizarea, dar multe
instrumente de concepţie posedă propriul lor mecanism de prototipizare. Acesta este cazul când se realizează un
prototip jetabil.
- Simulatoarele permit să se estimeze resursele necesare în funcţionarea sistemului. Le regăsim adesea sub formă
de instrumente interne în cazul marilor producători de software.

3.7.2. Instrumente de realizare


Se regăsesc sub numele de instrumente de realizare odată cu limbajele de programare, generatoarele de cod şi
tot ceea ce poate servi la punerea la punct a programelor, oricare ar fi maniera în care ele au fost obţinute.
- Limbajele de programare: se disting limbaje procedurale (ex. Fortran, Cobol, Pascal), limbaje funcţionale (Lisp şi
derivatele sale), limbaje logice (Prolog), limbaje orientate pe obiect (Smalltalk, C++).
- Generatoarele de cod: aceste instrumente generează, plecând de la specificaţii, programe într-unul din limbajele
de mai sus, pentru o parte sau pentru toată aplicaţia. Modul de lucru al generatoarelor este fie prin meniuri, fie cu
descrieri în limbaje de programare de nivel înalt, sau combinând cele două procedee. Ele pot fi mai mult sau mai puţin
orientate pe anumite tipuri de funcţionalităţi, de exemplu interfeţe grafice sau editări batch.
- Limbajele numite de generaţia a patra: ele acoperă acelaşi domeniu cu generatoarele de cod dar cu o tehnologie
diferită, mergând de la interpretare pură la tehnici mixte interpretare/compilare.
-Generatoarele de baze de cunoştinţe ( generatoarele de sisteme expert ): ele acoperă la fel domeniul
generatoarelor de cod, dar sunt legate de un motor inferenţial şi sunt dedicate mai mult aplicaţiilor de inteligenţă
artificială de tip diagnoză.
- Instrumente de punere la punct: sunt deseori integrate în instrumentele de realizare, alteori, nu. Ele permit,
printre altele, stabilirea punctelor de reluare în program şi schimbarea valorilor variabilelor în cursul execuţiei.
- Analizoarele de cod: permit identificarea principalelor componente ale unui program, permiţând astfel să apară
logica generală, identificarea "codului mort" (secvenţa de instrucţiuni care nu s-a executat niciodată).
52
- Instrumente de optimizare a codului, adesea legate de analizori, dar nu obligatoriu, permit identificarea
secvenţelor care trebuie penalizate sau eventual modificate.
- Genetaroarele de jocuri de încercare permit realizarea jocurilor de încercare prin generarea de numere
aleatoare, plecând de la date de producţie, etc.
- Monitoarele de test permit să se înregistreze derularea unui test sub formă de scenariu şi reluarea lui, permiţând
astfel verificările de non regresie. Cele mai sofisticate permit chiar modificarea scenariilor.

3.7.3. Gestionarele de schimbări (sau reconfigurări)


Permit girarea evoluţiei programelor, a diferitelor lor versiuni, urmărirea impactului modificărilor între diferitele
componente logice, garantarea transferului între medii (test, asigurarea calităţii, producţie).

3.7.4. Instrumente de îmbunătăţire a aplicaţiilor (reverse


engineering)
Aceste instrumente permit de a relua o aplicţie şi de a o redocumenta.
- Convertizoarele de baze de date permit, ca plecând de la o descriere fizică, să se regăsească modelul
conceptual.
- Restructurarea codului permite de a "înţelege" ceea ce face un program, de a-i prezenta logica şi de a reface
codul existent până la nivelul concepţiei.
- Instrumentele de re-inginerie permit re-generarea aplicaţiei, ca de altfel, re-analizarea, re-documentarea,
optimizarea.

3.7.5. Instrumente de gestiune a proiectului


Acest gen de instrument există deja în industrie, dar proiectele informatice au un mare grad de specificitate, ceea
ce face dificilă utilizarea acelora care n-au fost în mod specific concepute pentru a genera proiecte informatice.

3.7.6. Dicţionarele
Dicţionarele sunt inima, elementul central în conceperea şi realizarea unui proiect. În practică, în absenţa unui
standard, se constată că unele instrumente nu au dicţionare pentru tot ce există în sistem. Unicitatea dicţionarului este
punctul forte al atelierului de inginerie software integrat.