INGINERIA SOFTWARE = tratează întregul proces de dezvoltare și întreținere a unui produs software • Mai multe dintre tehnicile care se aplică în… [626061]

Capitolul 8
INGINERIA SOFTWARE

INGINERIA SOFTWARE = tratează întregul proces de dezvoltare și întreținere a unui produs software
• Mai multe dintre tehnicile care se aplică în acest domeniu sunt similare celor utilizate de inginerii care
lucrează în industrie.
• Din acest motiv domeniul poartă numele de “inginerie software”.
• Se aplică la sisteme software de mari dimensiuni, a căror complexitate depășește capacitatea de
memorare pe termen scurt cu care suntem înzestrați – sisteme de gestiune economică, sisteme de
comandă a legăturilor telefonice sau sisteme de securitate pentru clădiri (bănci, birouri).
• În dezvoltarea acestor sisteme complexe apar probleme noi, cum ar fi cele legate de:
– implicarea pe termen lung a unui număr foa rte mare de persoane, pe parcursul procesului
specificațiile se pot modifica sau personalul se poate schimba (prin transfer, promovare, etc.).
– personal sau de managementul proiectelor, mai apropiate de domeniul științelor economice
decât de informatică.
– aspecte juridice legate de dreptul de proprietate și de garanțiile oferite pentru produsele
software.

Ingineria software ca disciplină
Aspecte ce pot să apară pe parcursul dezvoltării unui produs software:
• Cum putem estima resursele financiare și uma ne sau timpul necesar realizării proiectului?
• Cum putem împărți proiectul în componente mai ușor de controlat și cum ne asigurăm că
aceste componente sunt compatibile?
• Cum asigurăm comunicarea între cei care realizează diferitele componente?
• Cum pute m măsura stadiul de realizare?
• Cum rezolvăm numeroasele detalii care apar pe parcurs?

Deși ingineria e un domeniu cu reguli bine precizate, ingineria software nu poate prelua multe
dintre tehnicile utilizate deja în alte discipline datorită deosebirile foarte mari dintre software și celelalte
specialități:
Ø Dacă în alte domenii putem vorbi de toleranțele permise în funcționarea unui produs – despre
produsele software nu putem vorbi în aceeași termeni; un program funcționează corect sau incorect

Ø O alt ă deosebire constă în lipsa unor sisteme cantitative (metrici) care să ne permită
măsurarea proprietăților unui sistem informatic – ce metrică am putea folosi pentru măsurarea calității
unui produs software?
Ø În cazul dispozitivelor mecanice calitatea est e exprimată sub forma timpului mediu de bună
funcționare, care este o măsură a uzurii – produsele software nu se uzează, de aceea în ingineria
software nu putem aplica această metodă de evaluare a calității.
Ø Imposibilitatea măsurării cantitative a propri etăților produselor software este unul dintre
motivele pentru care ingineria software nu este încă bine fundamentată, așa cum sunt ingineria
mecanică și cea electrică – în timp ce aceste domenii se bazează pe legile fizicii, ingineria software nu are
încă o bază la fel de solidă.
Ciclul de viață al unui produs software
• Conceptul fundamental al ingineriei software îl constituie ciclul de viață al produselor.

• Tiparul nu este specific produselor software, el putând fi generalizat pentru majoritatea
produ selor industriale, cu diferența că în cazul acestora din urmă, etapa de modificare se numește etapa
de reparare sau de întreținere.
• Așa cum am mai arătat, produsele software nu se uzează. În schimb, ele trec prin faza de
modificare.
• Indiferent de motivul pentru care un produs informatic intră în faza de modificare, acest stadiu
presupune ca o persoană (adesea alta decât autorul programului) să studieze programul și
documentația aferentă până când ajunge la un grad de înțelegere care să îi permită efectuarea
modificărilor.
• Experiența arată că un minim de efort în timpul dezvoltării unui produs informatic poate să
ușureze mult sarcina modificării produsului, atunci când acest lucru devine necesar.
• Este limpede acum de ce majoritate a cercetărilor în domeniul ingineriei software se
concentrează pe faza de dezvoltare a produselor; eforturile investite în această fază aduc cele mai mari
beneficii pentru toate fazele ulterioare de viață.

FAZA DE DEZVOLTARE
• Prima fază din ciclul de vi ață al produselor informatice, dezvoltarea are următoarele etape:
analiza, proiectarea, implementarea și testarea.
Analiză  Proiectare  Implementare  Testare
1. Analiza
Ø Etapa în care se constată că ar fi utilă o aplicație informatică și se ia decizia de zvoltării unui sistem
software.
Ø După luarea deciziei de dezvoltare a unui sistem informatic începe adevărata analiză, al cărei scop
principal este identificarea necesităților utilizatorului potențial al sistemului.
Ø Unul dintre rezultatele formale ale f azei de analiză îl reprezintă un set de cerințe pe care noul sistem
ar trebui să le satisfacă.
Ø După ce sunt identificate cerințele, ele sunt transformate în specificații tehnice.
2. Proiectarea
Ø Sunt dezvoltate detal iile tehnice ale sistemului.
Ø Sistemul este descompus în componente mai ușor de controlat, numite module. Prin modularizare se
înțelege tehnica împărțirii unui produs software în componente mai ușor de controlat, care realizează
fiecare o parte din funcți unile sistemului
Ø Prin proiectarea modulară, este suficient să avem în vedere pentru fiecare modul doar detaliile
corespunzătoare acestuia.
Ø Proiectarea modulară ajută și la întreținerea sistemului.
3. Implementarea
Ø Se referă la scrierea efectivă a p rogramelor,
Ø Crearea fișierelor de date și dezvoltarea bazelor de date.
4. Testarea
Ø Fiecare modul al sistemului este testat în timpul implementării.
Ø Într -un sistem bine proiectat, fiecare modul poate fi testat în mod independent, utilizându -se versiun i
simplificate ale celorlalte module pentru a se simula interacțiunile dintre modulul țintă și celelalte
module ale sistemului.
Ø Testarea și depanarea unui sistem sunt operații foarte greu de dus la bun sfârșit. Sistemele de mari
dimensiuni pot conține fo arte multe erori, chiar și după efectuarea celor mai complexe teste. Multe
dintre ele vor rămâne neobservate pe toată durata de viață a produsului.
Ø Eliminarea unor astfel de erori este unul dintre principalele țeluri ale ingineriei software, iar faptul c ă
ele sunt încă destul de răspândite arată că în acest domeniu mai sunt multe de făcut.

TEHNICI ȘI INSTRUMENTE DE DEZVOLTARE
• În ultimii ani, tehnicile ingineriei software au fost determinate în mare măsură de dezvoltarea
instrumentelor specifice ingine riei software asistate de calculator (Computer Aided Software
Engineering – CASE) – sisteme software care oferă asistență pentru realizarea și actualizarea unor
documente, diagramele fluxului de date, diagramele relațiilor între entități și dicționarele de date.
• Aceste documente sunt utilizate pentru modelarea sistemului care se proiectează.
• Unele sisteme CASE cuprind chiar generatoare de cod, care, dacă se dau specificațiile pentru o
anumită parte a sistemului, creează programe într -un limbaj de nivel înalt care implementează acea
parte.
• Utilizarea instrumentelor automate reduce semnificativ efortul necesar pentru parcurgerea fazelor de
analiză, proiectare și implementare, astfel că este acum mult mai ușor să se revină și să se modifice
deciziile care s-au dovedit eronate.
• Ca rezultat al aplicării acestei tehnici, dezvoltarea sistemelor informatice a încetat să mai fie un proces
strict secvențial, în care mai întâi se încheie o fază și abia apoi se trece la faza următoare.
• Procesul a devenit unul în care analiza, proiectarea și construirea prototipurilor se îmbină, astfel încât
ca urmare a rezultatelor obținute în urma testării prototipului, proiectul poate fi modificat.
• Tehnicile ingineriei software apărute în anii `70 și `80 sunt în general in strumente utile pentru
construirea unor sisteme bazate pe paradigma de programare iterativă.
• În schimb, în sistemele software bazate pe paradigma orientată spre obiecte structura generală este
aceea a unui ansamblu de obiecte ⇒ a dus la c ăutarea unor noi tehnici de dezvoltare a produselor
software.

Câteva abordări metodologice în dezvoltarea software
• O metodologie de lucru pentru un produs software reprezintă modul de structurare, planificare și
control al procesului de dezvoltare.
• Pentru a înțelege mai bine ce înseamnă o metodologie de lucru, iată câțiva termeni ce sunt utilizați
frecvent în acest domeniu:
– Metodologie (sau metodă) – o anumită colecție de principii și/sau practici
– Familie de metodologii – un set de metode alternative care coexist ă
– Framework – un schelet (pentru metode) care trebuie dezvoltat/personalizat înainte de
utillizare
– Model – o descriere (pentru metode) care trebuie implementată de o metodă, familie sau
framework.

1. Proiectarea descendentă (top -down)
• Cel mai utilizat concept asociat cu proiectarea sistemelor informatice
• Ideea de bază – primul pas trebuie să fie obținerea unei scurte descrieri a soluției, care urmează a fi
detaliată ulterior.
• Pasul următor constă rafinarea descrierii simplificate, care trebuie detaliată și împărțită în
componente. – În acest mod, problema inițială va fi împărțită în mai multe probleme mai simple, ale
căror soluții luate împreună oferă o soluție pentru problema inițială.
• În abordarea clasică, iterativă, rezultatul proiectării descendente este un sistem ierarhizat care poate fi
transpus adesea direct într -o structură modulară.
• În schimb, mediile orientate spre obiecte utilizează proiectarea descendentă în procesul de stabilire a
tipurilor de obiecte care sunt nece sare și în proiectarea elementelor interne ale acestora.

2. Proiectarea Ascendentă
• Metodologie opusă care pornește invers: se identifică mai întâi activitățile simple din cadrul sistemului
și apoi se determină modul în care pot fi utilizate ca instrume nte abstracte pentru rezolvarea
problemelor de mai mare complexitate.
• Multă vreme această metodă a fost considerată inferioară proiectării descendente, dar astăzi ea
câștigă din ce în ce mai mult teren – ea tinde să caute o soluție structurată ierarhic: procesul de
împărțire a activităților conduce în mod natural la un proiect în care un modul principal utilizează
submodule care se bazează la rândul lor pe alte submodule etc.
Un proiect poate avea două module care interacționează de la egal la egal

• Sau poate există un modul ierarhic superior, care se folosește de modulul subordonat pentru a efectua
o anumită activitate

Cele mai importante metodologii pentru crearea de software
• Modelul Waterfall sau modelul Cascadă: Modelul Waterfall reprezintă un proces de implementare
secvențial, utilizat deseori în procesul de dezvoltare software. Are mai multe faze: Cerințe, Proiect are,
Implementare, Integare și Întreținere.

Modelul Waterfall sau modelul Cascada
• În faza de Cerințe sunt stabilite toate cerintele posibile ale sistemului ce se doreste implementa t.
Cerintele sunt culese de la utilizator prin consultarea acestuia, dupa care este analizata posibilitatea de
incorporare a lor in produsul dorit. La final este redactat un document cu aceste cerinte, ce va servi ca
ghid pentru fazele urmatoare ale proiec tului.
• În etapa de Proiectare sunt studiate cerintele de la prima etapa si este elaborat designul proiectului.
Aceasta faza ajuta in specificarea cerintelor de sistem si hardware, precum si in definirea arhitecturii de
ansamblu. Rezultatul acestei etape se concretizeaza in redactarea unui document ce cuprinde
specificatiile de proiectare.
• În continuare, se trece la etapa de Implementare. Dupa terminarea proiectarii, munca este divizata in
module si incepe adevarata implementare a codului. Sistemul este dezvoltat mai intai in mici programe,
numite “unitati”, care vor fi apoi integrate in faza urmatoare. Fiecare unitate este dezvoltata si testata,
pentru a ne asigura ca respecta specificatiile.
• În faza de Integrare, toate unitatile dezvolate in faza ante rioara sunt integrate si testate pentru a
verifica daca se coordoneaza, iar sistemul, privit ca un intreg, se comporta conform cu specificatiile.
Dupa testarea cu succes, produsul este livrat la beneficiar.

• Ultima faza a modelului Waterfall este teoretic o faza ce nu are un termen de finalizare. In general,
problemele unui software apar dupa ce el incepe sa fie utilizat, astfel incat problemele vor fi rezolvate
dupa lansarea produsului.

Printre avantajele acestui tip de model, se pot mentiona:
– Documentatia si proiectarea structurii reprezinta un avantaj atunci cand apar noi membrii in echipa
– Este un model usor de utilizat si simplu
– Fiecare faza are un rezultat asteptat, datorat rigiditatii modelului
– Etapele sunt implementate individual, pe rand.
– Este recomandat pentru proiectele mici, in care cerintele sunt foarte bine intelese.

Printre dezavantajele acestui tip de model, se numara:
– Culegerea specificatiilor in etapa de Cerinte este foarte importanta pentru a proiecta si implementa
produsul corespunzator. Cerintele pot fi adaugate si dupa finalul acestei etape, fapt ce influenteaza in
mod negativ dezvoltarea.
– Problemele din cadrul unei etape nu sunt niciodata rezolvate complet in cadrul aceleiasi etape
– Partitionarea in etape a proi ectului nu este flexibila
– Intrucat clientul poate adauga noi cerinte, acestea nu pot fi implementate in aceeasi editie a
produsului, va fi nevoie de costuri suplimentare pentru implementarea cerintelor nou adaugate.
– Este dificil sa se faca o estimare c orecta a timpului si costului alocat pentru fiecare etapa.
– Un produs functional finit este obtinut tarziu, comparativ cu momentul de inceput al proiectului.

Modelul Prototip:
• Scopul modelului Prototip este de a contracara primele două limitări ale mo delului Waterfall, discutat
mai sus. In loc de a stabili definitiv cerințele înainte de a putea începe cu proiectarea și implementarea,
este lansat un prototip pentru a înțelege cerințele. Acesta este dezvoltat pe baza cerințelor cunoscute în
prezent. Dezv oltarea prototipului conține fazele de proiectare, implementare și testare, dar acestea nu
sunt foarte riguroase sau formale. Prin intermediul prototipului, clientul înțelege mai bine modul în care
lucrează produsul, întrucât interacționează cu acesta pe p arcursul întregului ciclu de dezvoltare. Acest
model este preferat în cadrul sistemelor mari și complicate, pentru care este dificilă înțelegerea
cerințelor de la început. În astfel de situații, accesul clientului la prototip furnizează un aport substanția l
în înțelegerea și definirea specificțtiilor.

• Avantajele acestui tip de model sunt:
– Utilizatorii sunt implicați direct în dezvoltare
– Întâmpină tendința utilizatorilor de a -și modifica cerintele, pe parcursul ciclului de implementare
– Întrucat es te lansat un model functional al sistemului, utilizatorii pot întelege mai bine modul de
functionare
– Erorile pot fi detectate mult mai devreme
– Feedback -ul utilizatorului este mult mai rapid, fapt ce duce la obținerea de soluții mai bune
– Timpul și cos turile reduse

• Printre dezavantaje , merită menționate:
– Acest model poate crește complexitatea sistemului, sau acesta se poate extinde dincolo de limitele
stabilite inițial
– Analiza insuficientă a proiectului ca un întreg
– Programatorii pot deveni ataș ați de un prototip în a cărui dezvoltare au investit mult timp și vor tinde
să transforme prototipul într -un produs final chiar și atunci când arhitectura de bază nu este cea
potrivită
– Consumul excesiv de timp utilizat pentru implementarea unui prototip.

Modelul Spirală:
Pașii unei iterații din modelul Spirală pot fi generalizatț astfel:
1. Cerințele sistemului sunt definite cât de detaliat se poate. Acest lucru presupune de obicei
intervievarea unui număr de utilizatori reprezentând utilizatorii intern i și externi ai sistemului precum și
alte aspecte.
2. Este creat un design preliminar pentru noul sistem. Această faza este cea mai importantă a modelului.
În această etapă, toate alternativele posibile (și disponibile), care pot ajuta în dezvoltarea unui proiect
eficient din punct de vedere a costului sunt analizate și sunt decise strategiile de abordare.
3. Este construit un prim prototip al noului sistem din design -ul preliminar. Acesta este de obicei un
sistem la scară redusă și reprezintă o aproximare a caracteristicilor produsului final.
4. Un al doilea prototip este dezvoltat, asfel:
a. Evaluarea primului prototip în termeni de puncte forte, puncte slabe și riscuri
b. Definirea cerintelor pentru al doilea prototip
c. Planificarea și proiectarea celui de al doilea prototip
d. Construirea și testarea
celui de al doilea prototip
• Avantaje : – Presupune o atitudine
pro-activă asupra riscurilor, cu o
presupunere explicită a riscurilor și
a rezolvării lor
– Foarte flexibil
• Dezavantaje : – Aproape imposibil
de estimat de la început timpul și
costurile necesare.

MODELUL AGILE
E cea mai en vogue, pe trend, metodologie utilizată în industria IT.
• Agile este o familie de metodologii de project management în ingineria software, bazată pe
dezvoltarea incrementală și care îmbrățișează ș i promovează schimbările ce evoluează de -a lungul
întregului ciclu de viață al unui proiect.
• Aceste metodologii se caracterizează prin divizarea problemei în subprobleme mici și planificarea lor
pe durate scurte. Se evită planificarea în detaliu pe terme n lung, deoarece inerent în dezvoltarea de
software apar întârzieri frecvente din cauza schimbărilor și detalierii cerințelor clientului.
• Scopul principal este ca, la terminarea fiecărui ciclu de dezvoltare (denumit iterație, și a cărui durată
este de ob icei ordinul câtorva săptămâni) să existe o versiune cât de cât funcțională (deși incompletă) a
software -ului dezvoltat (cu număr minim de buguri).
• O altă caracteristică importantă este comunicarea frecventă între membrii echipei, care, în multe
cazuri, se întâlnesc într -o scurtă ședință zilnică, denumită stand -up sau scrum în care fiecare prezintă pe
scurt progresul său în ultima zi de lucru și problemele cu care s -a confruntat. Acestora li se alătură și un
reprezentant al clientului, care trebuie să fie informat de aspectele dezvoltării, pentru a ști ce modificări
este realist să ceară și cât de mult ar putea costa ele. Astfel, toată lumea are cunoștințe despre fiecare
aspect al dezvoltării aplicației și poate prelua munca altuia sau ajuta pe altcineva.

Principiile metodelor AGILE
1. Satisfacerea clienților, prin livrarea rapidă de software utilizabil;
2. Întâmpinarea modificării specificațiilor, chiar și târziu în implementare;
3. Software -ul utilizabil este livrat frecvent (la nivel de săptămâni);
4. Software -ul utilizabil reprezintă principala măsură a progresului;
5. Dezvoltare susținută, capabilă să păstreze un pas constant;
6. Cooperare apropiată între dezvoltatori și clienți;
7. Conversația față -în-față este cel mai bun mod de comunicare;
8. Pro iectele sunt construite de indivizi motivați, credibili;
9. Simplitate;
10. Echipe organizate individual;
11. Adaptare la circumstanțe schimbătoare;
12. Atenția constantă pentru excelenta tehnică și design bun.

Modelul Agile:
De-a lungul timpului au apăr ut diverse metode la baza cărora stau unele dintre aceste valori și principii.
Ele au fost denumite metode agile, iar printre ele se numără:
• Scrum
• Programarea extremă (XP)
• Proces unificat agil (AUP)
• Modelare agilă
• Proces unificat esențial (EssUP)
• Proces unificat deschis (OpenUP)
• Metoda de dezvoltare dinamică a sistemelor (DSDM)
• Dezvoltare bazată pe caracteristici (FDD)
• Crystal

Metoda SCRUM
• Scrum este o metodă Agile de management a proiectelor IT. În plus SCRUM este un proces iterativ ș i
incremental pentru dezvoltarea software acolo unde cerințele se schimbă rapid. La sfîrșitul fiecărei
iterații, echipa de proiect produce un produs software cu un set parțial de funcționalități, dar care se
poate livra la client. Scrum este o abordare car e stabilește principii simple de management de proiect.
Se folosește de obicei cu practicile de Extreme Programming. Scrum este un proces care îmbuntățește
comunicarea și cooperarea în echipă.
• Această metodologie a fost prima dată descrisă în 1986 de Hir otaka Takeuchi și Ikujiro Nonaka, ca o
metodă flexibilă și rapidă pentru dezvoltare de soft. Principiul acestei metodologii, este împărțirea
proiectului în etape de lucru (sprint -uri), în urma cărora se finalizează un set de funcționalități care intră
în exploatare. Această metodologie presupune ca oamenii implicați să fie buni organizatori ai propriului
timp.
Organizare SCRUM
• Ședinte dedicate planificării sprinturilor
(în functie de anvergura proiectului, un
sprint poate varia între 5 si 30 de zile).
Scopul acestor ședinte este prioritizarea
taskurilor și stabilirea celor incluse în
următorul sprint. Din momentul stabilirii,
funcționalitățile se “îngheață”
• Sedințe zilnice (cu o durată de max. 15
minute). Scopul acestor ședinte este

identificarea tasku rilor îndeplinite în ziua precedentă, a taskurilor planificate pentru ziua în curs și a
problemelor apărute. Această ședință are un caracter mult mai informal.

Roluri SCRUM
• Stakeholderi
• Product Owner – reprezintă interesul stakeholderilor, asigură f inanțarea proiectului și dezvoltă lista de
cerințe -Proprietarul – este cel care stabilește cerințele proiectului și participă la întâlnirile organizate la
finalul fiecăror perioade fulger. Din cauza faptului că implicarea proprietarului nu este constantă el
poate face parte și din grupul găinilor.
• Scrum Master – acest rol poate fi asociat managerului de proiect, care are drept scop împărțirea și
prioritizarea sarcinilor – Maestrul Scrum – este cel care acționează ca un intermediar între proprietar și
echipă. Maestrul protejează echipa, are grijă ca toate sarcinile din perioada fulger să fie îndeplinite la
timp și stabilește regurile proiectului.
• Echipa – dezvoltă și implementează funcționalitățile – este implicată în mod direct în procesul de
analiză, d esign, implemnetare și testare și toate sarcinile trebuie duse la capat corect de către membrii
săi.

• Modelul Scrum sugerează că proiectele progresează printr -o serie de sprinturi. În conformitate cu o
metodologia agilă, sprintarea este încadrată într -un timp (time -boxed) de nu mai mult de o lună, cel mai
frecvent de două săptămâni.
• Metodologia Scrum pledează pentru o întâlnire de planificare la începutul unui sprint, unde membrii
echipei își dau seama la cât de multe elemente care pot angaja, și apoi creează un backlog – o listă a
sarcinilor care urmează a fi efectuate în timpul sprintului.
• În timpul unei sprint agil Scrum, echipa Scrum preia un mic set de caracteristici și îl trece de la idee la
funcționalitate codificată și testată. La sfârșit, ac este caracteristici sunt efectuate, adică codate, testate
și integrate în produsul sau sistemul de evoluție .
• În fiecare zi de sprint, toți membrii echipei trebuie să participe la o întâlnire Scrum, inclusiv
ScrumMaster -ul și proprietarul produsului . Ac eastă întâlnire este time -boxed la nu mai mult de 15 de
minute. În acest timp , membrii echipei împărtășeasc ceea ce au lucrat în ziua anterioară, stabilesc ce se
va lucra în acea zi, și identifică orice obstacole care stau în calea progresului .
• Model ul Scrum vede scrum -urile de zi cu zi ca o modalitate de a sincroniza munca membrilor echipei în
timp ce discută despre activitatea de sprint.
• La sfârșitul unui sprint, echipa efectuează o revizuire a sprint -ului în care echipa arată noua
funcționalitate la PO sau la orice stakeholder care dorește să ofere feedback -ul, care ar putea influența
sprinturile următoare .
• Această buclă de feedback în dezvoltarea de software Scrum poate duce la modificări ale
funcționalității proaspat livrate, dar poate duce l a fel de probabil la revizuirea sau adăugarea de
elemente la backlog -ul de produsului .
• O altă activitate în managementul de proiect Scrum este retrospectiva sprint de la sfârșitul fiecărui
sprint. Întreaga echipă participă la această reuniune, inclusiv ScrumMaster și PO. Reuniunea este o
oportunitate de a reflecta asupra sprint -ului care s -a încheiat, și de a identifica oportunități de
îmbunătățire.

Modularizarea
• Prin modularizare se înțelege tehnica împărțirii unui produs software în componente mai ușor de
controlat, care realizează fiecare o parte din funcțiunile sistemului.
• Unul din principalele instrumente de reprezentare a structurii modulare a sistemelor software bazate
pe paradigma iterativă este schema de structură.
• În această schemă modul ele sunt reprezentate prin dreptunghiuri, iar legăturile dintre ele prin săgeți.
• Într -un fel, putem spune că schema de structură ne oferă o imagine a diviziunii muncii în cadrul
sistemului.

Instrumente folosite în dezvoltarea produselor software
• Diagrama Fluxului de Date – este o reprezentare grafică a drumului parcurs de date în cadrul
sistemului. Fiecare obiect are o etichetă care specifică numele obiectului reprezentat.
• Diagrama Relațiilor Între Entități – este o reprezentare grafică a bloc urilor elementare de informații din
cadrul sistemului (numite entități) și a relațiilor dintre ele.
• Dicționare De Date – este centralizatorul tuturor informațiilor referitoare la datele utilizate în cadrul
sistemului: identificatorul utilizat pentru fiec are element, valorile valide (tip numeric sau alfanumeric,
interval permis de valori, etc), locul de stocare (fișier sau bază de date, numele acesteia), locurile în care
elementul respectiv este folosit de către program, ce module conțin referiri la el).
Documentația
• Un sistem informatic al cărui mod de utilizare este greu de învățat și de întreținut nu este deloc
folositor.
• De aceea, documentația este o parte importantă a oricărui pachet software, și prin aceasta un subiect
important în ingineria sof tware.
• Documentația este elaborată în două scopuri.
a. Documentația de utilizare
Ø ea trebuie să descrie pachetul software și modul lui de utilizare;
Ø este destinată utilizatorului final al sistemului
Ø are un caracter mai puțin tehnic.
Ø ia forma unui manual care prezintă cele mai folosite caracteristici oferite de produsul respectiv și
instrucțiuni de instalare.
Ø este un instrument de marketing foarte important. O documentație de utilizare bună, împreună cu o
interfață bine proiectată, măresc accesib ilitatea produsului și prin aceasta sporesc vânzările.

b. Documentația de sistem
Ø descrie sistemul software astfel încât acesta să poată fi întreținut pe durata celorlalte perioade de
viață.
Ø are în mod inevitabil un caracter mult mai tehnic decât docum entația de utilizare.
Ø conține toate documentele elaborate în faza de dezvoltare a sistemului, inclusiv specificațiile conform
cărora a fost verificat sistemul, diagramele de flux și de relații între entități, dicționarul de date și
schemele de sistem, ca re reflectă structura sa modulară.

Dreptul de proprietate și garanții
• Inițial, legile privind drepturile de autor au fost elaborate pentru a proteja operele literare.
• În cazul unui produs software, ideea se exprimă prin algoritm.
• Spre deosebire îns ă de o poezie sau un roman, valoarea unui produs software nu constă în maniera
particulară în care este exprimat algoritmul, ci chiar în algoritm.
• Costurile fazei de dezvoltare a unui pachet software se concentrează tocmai în descoperirea unor
algoritmi, și mai puțin în reprezentarea acestora
• Aplicarea directă a legii drepturilor de autor va lăsa neprotejată tocmai investiția principală a
producătorului de software, permițând unei firme concurente să utilizeze liber algoritmul descoperit de
acest a, cu condiția ca reprezentarea să nu fie similară
• Legile referitoare la drepturile de autor au fost concepute astfel încât să protejeze mai degrabă
implementarea decât funcția, însă valoarea unui program constă adesea mai degrabă în funcție decât în
formă
• Este paradoxal: cu cât eforturile de dezvoltare a unui program sunt mai creative, cu atât legea
drepturilor de autor le protejează mai puțin.
• Noțiunea de patent software nu se aplică în România și în UE. În spațiul european softul se protejează
prin drept de autor.

Dreptul de proprietate și garanții
• În anii 1970 – 1980 au existat discuții aprinse pentru a decide dacă sistemul de drept de autor, sistemul
de patente sau un sistem sui generis ar trebui să asigure protecția programelor de calculato r (software).
Aceste discuții au condus la un principiu general acceptat, acela că programele de calculator trebuie
protejate de dreptul de autor, în timp ce aparatele care folosesc programe de calculator sau invenții
referitoare la software trebuie protej ate prin brevet de invenție (patent).
• Legea brevetelor de invenție și legea dreptului de autor asigură tipuri de protecție diferite. Prin dreptul
de autor este protejat doar modul de exprimare și nu ideile, procedurile, metodele de operare sau
conceptele matematice, în timp ce un patent este un drept exclusiv garantat în legatură cu o invenție,
reprezentând un produs sau un proces nou prin care se obține ceva sau oferă o soluție tehnică nouă
pentru a rezolva o problema. Dreptul de autor este garantat în ț ările semnatare ale Convenției pentru
protecția operelor literare și artistice (Convenția de la Berna) fără nici o formalitate. Un brevet de
invenție este în general eliberat după procedura de examinare de către o agenție guvernamentală (de
ex., OSIM – Oficiul de Stat pentru Invenții și Mărci).
• Protecția programelor de calculator prin dreptul de autor este garantată în majoritatea țărilor și este
armonizată prin tratatele internaționale. Legislația referitoare la brevetabilitatea programelor de
computer n u este încă agreată internațional însă în unele țări este aplicată efectiv.