SISTEME INFORMATICE DE GESTIUNE

• CONSIDERENTE TEORETICE PRIVIND SISTEMELE INFORMATICE

• METODOLOGII DE REALIZARE A SISTEMELOR INFORMATICE
• ANALIZA SISTEMELOR INFORMATICE
• PROIECTAREA SISTEMELOR INFORMATICE
• IMPLEMENTAREA SISTEMELOR INFORMATICE
• EXPLOATAREA ŞI ÎNTREŢINEREA SISTEMELOR INFORMATICE
• PROIECTAREA ORIENTATĂ OBIECT

CONSIDERENTE TEORETICE PRIVIND SISTEMELE INFORMAŢIONALE

1. DEFINIREA SISTEMELOR INFORMAŢIONALE

Conceptul de bază al analizei si proiectării sisteme1or î1 constituie noţiunea de sistem. Acest

concept este folosit in mod frecvent in diferite domenii de activitate existând astfel: sisteme de afaceri,
sisteme politice, sisteme informatice, sisteme de producţie, sisteme biologice, sisteme educaţionale etc.
Toate aceste sisteme au in comun faptul că sunt alcătuite dintr-un număr de elemente ce interacţionează
atât intre ele cât şi cu mediul înconjurător in vederea realizării unui obiectiv.
Noţiunea de sistem este una foarte generală, cuprinzătoare, practic, in orice domeniu de activitate
se are de a face, intr-o formă sau alta, cu sisteme.
Conceptul de sistem a apărut intr-o forma embrionară in filozofia antică greacă afirmând că
“întregul este mai mult decât suma părţilor componente”, Aristotel a dat o primă definiţienoţiunii de
sistem.
Noţiunea de sistem are un caracter relativ, in sensul că orice sistem poate fi descompus în
subsisteme şi la rândul său, poate fi privit ca un subsistem al unui sistem mai complex. Astfel de
exemplu, o întreprindere poate fi descompusă in sisteme (secţii, ateliere, locuri de muncă) şi la rândul
ei, întreprinderea poate fi privită ca un subsistem al unei ramuri, sau al economiei naţionale. Pe acest
principiu de descompunere a sistemului real in subsisteme, se bazează analiza şi proiectarea sistemelor
informatice pentru a studia conexiunile dintre subsisteme in raport cu obiectivele lor şi in funcţie de
resursele existente. după care sunt reintegrate intr-un nou sistem mai performant, a cărui reproiectare
constituie obiectivul principal al analizei si proiectării sistemelor.
Prima definiţie riguroasă a conceptului de sistem aparţine fondatorului teoriei generale a
sistemelor (TGS), Ludwing von Berthalanffy, care considera că „sistemul este o mulţime de elemente
intre care există relaţii sau raporturi neîntâmplătoare care interacţionează in vederea realizării unui
obiectiv comun, care poate fi o lege a naturii sau un obiectiv stabilit de către om”.
In teorema generală a sistemelor există o legitate. Formulată pentru prima data de Churchmann,
care afirmă că orice sistem poate fi considerat in alte condiţii ca subsistem, fapt ce evidenţiază
caracterul relativ al acestor două concepte de baza in analiza şi proiectarea sistemelor informatice.
In general pentru a putea defini un sistem din orice domeniu de activitate trebuie stabilite cu
precizie elementele componente şi conexiunile existente intre elementele sistemului pe de o parte. şi
intre sistem şi mediu pe de altă parte. Precum si obiectivul sistemului.
Un sistem este un ansamblu de elemente care ascultă de un pachet de reguli de funcţionare bine
definite, in vederea îndepliniri unui anumit scop. Orice sistem este caracterizat prin aceea că este legat
de mediul ambiant. Are o anumită structură, funcţionează după anumite reguli şi urmăreşte un anumit
scop. Datele se găsesc intr-o circulaţie permanentă intre oameni care transmit informaţii si cei care le
primesc. Acest drum se numeşte flux informaţional. In ceea ce priveşte scopul sau obiectivul
sistemului, acesta trebuie văzut ca raţiunea pentru care a fost construit sistemul. Motivul pentru care au
fost grupate elementele respective.
 Un sistem, in absenţa obiectivului său, reprezintă numai o mulţime de elemente interconectate.
La rândul ei o mulţime de elemente neconectate nu va avea nici o semnificaţie pentru analiza şi
proiectarea sistemelor.
Elementele unui sistem sunt entităţi de tipuri si caracteristici diferite, cum ar fi oameni
echipamente. Procese de producţie, tehnologii, organizare etc.. Implicate intr-o mulţime de activităţi
specifice sistemului. Entitatea este un element de abstractizare a realităţii caracterizat prin atributele
care o descriu si o definesc funcţional. Elementele sistemului pot fi ele insele considerate ca sisteme in
sensul definirii acestui concept.
Sistemul alcătuit din unul sau mai multe elemente îl putem considera ca subsistem al unui
sistem mai complex (hipersistem/suprasistem). Apare astfel, problema existenţei şi definirii unor
elemente primare simple, despre care să nu mai putem afirma că sunt sisteme sau subsisteme, ci doar
elemente componente ale unui sistem/subsistem. Si evident, in celălalt sens, apare problema existentei
Si definirii unui hipersistem care să includă toate sistemele existente. iar el să nu mai fie inclus intr-un
alt sistem de ordin superior. Este clar că răspunsul la cele două probleme este negativ, şi că numai in
mod abstract. Imaginative, din necesităţi practice de cercetare, vom considera existenţa acestor cazuri-
limită de sisteme.
Relaţiile dintre elemente includ şi comunicaţiile dintre ele si limitează comportamentul acestora
in cadrul sistemului. In acest sens, sistemul trebuie izolat pentru a pune in evidenţă restricţiile care
există , care acţionează şi influenţează comportamentul elementelor din sistem. in descrierea unui
sistem se vor evidenţia totdeauna elementele componente, relaţiile dintre acestea şi scopul sistemului.
În domeniul economiei, întreprinderea poate fi definită ca un sistem alcătuit dintr-o mulţime de
elemente (oameni, maşini, materii prime, instalaţii, energie, informaţii etc.), intre care există o serie de
relaţii tehnologice, economice, sociale. informaţional-decizionale, interumane etc. si care au ca obiectiv
predeterminat realizarea unor produse si/sau servicii a căror desfacere trebuie să asigure obţinerea unui
profit ce trebuie maximizat.
Astfel, o întreprindere productivă, considerata ca sistem in cadrul analizei, poate fi descompusă
structural in subsisteme care să reprezinte secţii, ateliere, locuri de muncă, procese. activităţi, operaţii,
dar din punct de vedere funcţiona1, subsisteme care să reprezinte funcţiile de bază ale acesteia cum ar
fi: studiul pieţei, aprovizionare. producţie, desfacere, financiar-contabil, gestiunea calităţii, revizii-
reparaţii etc.
Tehnica de descompunere a sistemelor in elementele lor componente, este numită de
compoziţie funcţională/structurală şi reprezintă un instrument fundamental ce vizează îndeosebi
aspectele analitice din cadrul analizei şi proiectării sistemelor.
Elementele-atomi ale unui sistem sunt conectate intre ele in timp şi spaţiu, prin intermediul unor
fluxuri informaţional-decizionale şi a unor fluxuri de resurse materiale. umane, tehnologice etc. într-o
varietate de moduri. realizând aşa numitele relaţii/conexiuni care pot fi fizice, logice-temporale,
cauzale, continue, tranzacţionale, interne, externe etc.
Legătura/conexiunea reprezintă interacţiunea dintre două componente. evoluţia uneia
depinzând de stările celeilalte. Identificarea acestora nu este uşor de realizat, ea depinzând decisiv de
observatorul sistemului, care introduce un anumit grad de subiectivitate numit principiul incertitudinii.
Conform acestui principiu un acelaşi sistem poate fi descris in mod diferit de doi observatori.
Astfel, dacă un sistem tehnic poate fi in general descris la fel de către observatori cu nivele de
pregătire apropiate, nu acelaşi lucru se poate întâmpla când ei sunt diferiţi din punct de vedere obiectiv
sau subiectiv, in ceea ce priveşte viziunea pe care o au asupra sistemului. Astfel, in timp ce
economistul, va evidenţia in special conexiunile financiar-contabile, informaticianul pe cele referitoare
la fluxurile informaţionale, iar tehnicianul pe cele privind fluxurile tehnologice, analistul de sistem,
care are o pregătire complexă, are sarcina de a reliefa si analiza aspectele relevante ale tuturor tipurilor
de conexiuni existente in sistem.
In cadrul unui sistem pot să existe atât conexiuni cu caracter intern intre subsisteme, care să
reliefeze aspecte tehnologice, informaţional-decizionale, financiar-contabile etc. cât si conexiuni cu
caracter extern care se manifestă intre subsisteme şi mediul sistemului.
Conexiunea sistemului cu mediul său este reliefată de mulţimea elementelor care alcătuiesc
vectorul de intrare (imput-uri) şi vectorul de ieşire (output-uri). Complexitatea conexiunilor la nivel de
sistem este data de complexitatea rezultatului compunerii conexiunilor interne, existente intre
subsisteme şi mediu, respectiv, intre sistem si mediul acestuia.
Orice sistem este supus unor schimbări permanente in cadrul ciclului de viaţă, care pun in
evidentă conceptul de sistem dinamic. Această caracteristică provine din influenţa schimbărilor asupra
interacţiuni1or dintre elementele componente şi a conexiunilor dintre sistem si mediu, in vederea
atingerii obiectivelor sistemului. Sistemul interacţionează cu mediul său, care este format din elemente
ce nu fac parte din sistem, dar care ii pot influenţa. Distincţia dintre sistem şi mediu este realizată de
conceptul de graniţă/frontieră, care la rândul ei poate fi considerată un sistem format dintr-o mulţime de
elemente al căror comportament este exclusiv determinat atât de obiectivele sistemului cat si de
comportamentul unor elemente vecine din mediu sau din interiorul sistemului.
In timp ce graniţa unui sistem poate fi de natură fizică, este mai bine să se determine o graniţă
in termenii cauză-efect. Dacă un anumit aspect al unui sistem, este complet determinat de influenţe din
afara sistemului. atunci acel aspect este in afara graniţelor sistemului. In terminologia sistemică, tot
ceea ce este in afara graniţelor sistemului, dar care îl poate influenta, constituie mediul sistemului.
 Mediul unui sistem cuprinde toate elementele aflate in afara graniţelor sale, dar care au influenţe
directe sau indirecte in stabilirea obiectivelor, obţinerea resurselor necesare. adoptarea şi aplicarea
deciziilor etc., menite să favorizeze sau să perturbe desfăşurarea normală a activităţilor sistemului
considerat.
De exemplu mediul unei firme productive este format din piaţă, bănci, instituţii
guvernamentale, alte firme, etc., cu care aceasta se află in re1aţii economico-financiare.

Piaţă

Sistem Instituţii
(firmă) Guvernamentale
Bănci

Alte firme

Mediul unei firme

In funcţie de probabilitatea producerii evenimentelor putem considera:

• medii deterministe (certe), in care probabilitatea producerii evenimentelor poate fi maxima
(evenimente certe),
• medii cu perturbaţii (riscante), in care probabilitatea de realizare a evenimentelor sunt
cunoscute;
• medii turbulente (incerte), in care probabilităţile de realizare a evenimentelor sunt
necunoscute.
2. SISTEME INFORMAŢIONALE ECONOMICE

Abordarea duală a raportului mediu-unitate economică, facilitează eforturile de proiectare a

unor sisteme economice eficiente şi competitive.
De cele mai multe ori o activitate economică sau de altă natură este însoţită de un flux
informaţional.
In cadrul unui sistem (unitate economică sau de altă natură), putem pune in evidenţă două tipuri
de activităţi: cea de bază şi cea auxiliară, de natură informaţională. Separând elementele care participă
la activitatea informaţională de cele care participă la activitatea de bază, productivă, vom obţine două
sisteme: sistemul de bază si sistemul informaţional.
Sistemul informaţional poate fi definit ca un instrument indispensabil, constituit din mijloace,
metode şi oameni prin care se asigură desfăşurarea activităţilor specifice procesului informaţional:
înregistrarea, transmiterea, prelucrarea, selecţionarea şi păstrarea informaţiilor despre resursele
existente, despre eventualele perturbaţii şi abateri de la traiectoria fixată.
Într-o formă mai detaliată, putem spune că sistemul informaţional reprezintă din ansamblu de
fluxuri şi circuite informaţionale organizate intr-o concepţie unitară, care utilizează modele, proceduri,
resurse umane si materiale pentru culegerea, înregistrarea şi/sau transmiterea datelor şi a informaţiilor
prin intermediul cărora se asigură interconexiunile dintre sistemul de conducere şi sistemul condos,
dintre mecanismul social-economic pe care îl deserveşte si mediul social economic extern, având drept
scop final realizarea obiectivelor proprii unităţi economice in condiţii de maximă eficienţă.
Un sistem informaţional modern trebuie să asigure: informarea la toate nivelele operativitatea
informării, selectarea informaţiilor adaptabilitatea la modificări (modificarea cererilor de informaţii, a
datelor de intrare, a structurii organizatorice, a metodelor de prelucrare a datelor), precizia si exactitatea
informaţiilor.
Apariţia şi dezvoltarea mijloacelor informatice permiţând automatizarea gestiunii informaţiei a
impulsionat cercetările asupra naturii si structurii sistemului informaţional.
Sistemul informaţional reprezintă latura dinamică a sistemului managerial, făcând legătura intre
sistemul conducător şi cel condus in cadrul unităţii economice, dar şi intre aceasta şi mediul in care-si
desfăşoară activitatea. Sistemul informaţional permite cunoaşterea situaţiei existente intr-o unitate
economică. a celei trecute, dar si anticipări ale evoluţiei viitoare. contribuind la elaborarea şi
îndeplinirea obiectivelor stabilite. Prin intermediul sau se obţin informaţiile necesare fundamentării
deciziilor implementării acestora, precum si cele necesare adaptării sistemului unităţii economice la
modificările interne si externe ei.
Abandonarea concepţiei tradiţionale in favoarea uneia noi, moderne, se explică prin
conştientizarea faptului că o utilizare corespunzătoare a informaţiilor permite raţionalizarea distribuţiei
mărfurilor in condiţiile în care este evident mai avantajos, mai ieftin, să mişti informaţia decât marfa.
Este unanim acceptată idea ca orice mişcare a mărfii generează o mişcare de informaţii. Proiectarea şi
realizarea unui sistem informaţional capabil sa capteze informaţii utile unei unităţi economice, permite
o mai bună adaptare a acesteia la mediu, oferind chiar posibilitatea adoptării unei strategii active de
influenţate a mediului în sensul dorit.
Sistemul informaţional economic cuprinde: modul de organizare şi culegere a datelor; sistemul
de indicatori; clasificarea produselor şi activităţilor; metodologia de calcul a indicatorilor purtătorii de
informaţii; modul şi reţeaua de transmitere a datelor; modul de prelucrare a informaţiilor; mijloacele şi
modul de stocare a datelor; căile de valorificare a informaţiilor.
In cadrul sistemului informaţional, o serie de activităţi se desfăşoară (sau se pot desfăşura)
automat cu ajutorul tehnicii de calcul.
Sistemul automatizat de prelucrare a datelor, ca o subliniere a perfecţionării şi îmbunătăţirilor
radicale care au fost aduse procesului de prelucrare şi furnizare a informaţiilor pentru a cărui
desfăşurare se utilizează tot mai multe elemente de automatizare, poartă denumirea de sistem
informatic. Acesta este parte componentă a sistemului informaţional prin care se asigură prin utilizarea
calculatoarelor electronice, culegerea, transmiterea, prelucrarea şi stocarea datelor in vederea exercitării
cu eficientă superioară a principalelor atribute ale conducerii: previziune, planificare, urmărire-control,
organizare şi comandă (decizie).
Obiectivele principale ale sistemelor informatice economice constau in:
• creşterea operativităţii in informarea conducerii si luarea deciziilor la toate nivelurile.

• creşterea eficienţei economice in toate domeniile de activitate.

• reducerea volumului documentelor şi corespondenţei scrise utilizarea eficientă a personalului cu
înaltă calificare prin eliberarea sa de activităţile de rutină.
Sistemul informatic preia şi dezvoltă o parte din baza informaţională şi operaţiile de prelucrare ale
sistemului unităţii economice, putând fi privit din acest punct de vedere ca un subsistem informaţional
automatizat.
Sistemul informatic asigură memorarea şi prelucrarea automata a unei părţi a informaţiilor dintr-o
unitate economică, pentru a asigura următoarele cerinţe:
• asigurarea, simplificarea şi ameliorarea lucrărilor şi procedurilor informaţionale care presupun
simpla execuţie a unor operaţii şi prelucrări de rutină;
• asistarea şi sprijinirea procesului de conducere, şi in mod deosebit a procesului decizional.
Având in vedere că decizia aparţine omului, sistemul informatic are rolul de a-i furniza toate
elementele necesare si de a-i permite să facă alegerea deciziei optime pe baza unui maxim de
informaţii. De asemenea, sistemul informatic poate servi ca instrument de simulare, permiţând
evaluarea rapidă a consecinţelor previzibile ale fiecărei decizii şi adoptarea celei mai eficiente.
Informatizarea poate cuprinde, in mod obiectiv, numai acele părţi din sistemul informaţional care
sunt formalizabile prin definirea unor funcţii de transformare a intrărilor în ieşiri.
Cercetările din domeniul modelării matematice a proceselor economice, cat si cele din domeniul
inteligentei artificiale conduc la lărgirea continuă a ariei de utilizare a informaticii in cadrul unităţilor
economice.
Utilizarea calculatorului pentru rezolvarea unui grup omogen de lucrări sau probleme ale unităţii
beneficiare constituie o aplicaţie informatică cu menţiunea ca un sistem informatic poate cuprinde una
sau mai multe aplicaţii informatice. Aria unei aplicaţii informatice este determinată de omogenitatea
funcţională a prelucrărilor realizate si de delimitarea dintre procesele formalizabile şi cele
neformalizabile.
In cadrul unui sistem informatic pot exista mai multe aplicaţii care folosesc aceleaşi informaţii sau
informaţii generate de alte aplicaţii. În asemenea situaţii, pentru a evita introducerea repetată a
informaţiilor comune, se apelează la integrarea sistemului.
Un sistem informatic integrat asigură preluarea unică a fiecărei informaţii si difuzarea acestora
tuturor aplicaţiilor care o solicită.
Integrarea sistemelor informatice se poate realiza pe următoarele căi:
• memorarea fiecărei informaţii. astfel încât, să corespundă integral tuturor cerinţelor specifice ale
aplicaţiilor si să fie disponibilă pentru fiecare dintre ele.
• transmiterea informaţiilor între aplicaţii sub forma fişierelor de interfaţă prin care se asigură
joncţiunea dintre aplicaţii.
Integrarea poate fi realizată la nivelul unui sistem informatic specific unei unităţi economice, sau
între sisteme informatice aparţinând unor unităţi intre care există relaţii de subordonare-coordonare şi
care pot fi dispersate teritorial (de exemplu o sucursală cu filialele sale se găseşte in relaţii de
subordonare -coordonare).
Din punct de vedere fizic integrarea poate fi realizată prin intermediul unei reţele de calculatoare,
să asigure distribuirea colecţiilor de date memorate între unităţile economice ce se află in relaţii de
subordonare, in vederea furnizării necesarului de informaţii pentru fiecare dintre acestea.
In aceste condiţii, integrarea conduce la arhitecturi de sisteme informatice ierarhizate, cu
prelucrare, manipulare si stocare distribuită a datelor, in care prelucrarea interactivă şi in timp real are o
pondere tot mai însemnată.

1.3 LOCUL ŞI ROLUL SISTEMULUI INFORMAŢIONAL ÎN CONDUCEREA

ORGANIZAŢIILOR ECONOMICE

Pentru înţelegerea sistemelor informaţionale este necesar să amintim şi alte caracteristici

importante ale acestora. Astfel, un sistem există şi funcţionează într-un mediu ce conţine alte sisteme.
Dacă un sistem constituie una dintre componentele unui sistem mai mare, atunci reprezintă un
subsistem, iar sistemul mai mare este mediul lui. Întreprinderile sunt sistemele organizaţionale în care
resursele (intrări) sunt transformate prin diferite procese specifice (prelucrări) în bunuri şi servicii
(ieşiri)1 (fig.1.1)
control
Sistem decizional

comunicare

feed-back
Sistem informaţional

comunicare

Resurse economice Procese organizaţionale Produse şi servicii

— oameni realizare de produse şi — produse
— bani servicii marketing — servicii
— materiale desfacere
Fig. 1.1 alteorganizaţional
Sistemul procese — plăţi
— utilaje — informaţii
— energie Sistem operaţional — alte rezultate
Figura 1.4 Sistemul organizaţional

Figura 1.4 Sistemul organizaţional

Aşadar, putem considera ansamblul activităţilor din cadrul unei întreprinderi ca fiind rezultatul
Figura 1.4 Sistemul
acţiunii conjugate a trei subsisteme (pe careorganizaţional
pentru simplificare le vom numi sisteme,
interschimbabilitatea noţiunilor fiind admisă):
• sistemul de conducere (de management sau decizional), ce are rolul de a conduce
activităţile ce se desfăşoară în cadrul întreprinderii pentru realizarea obiectivelor stabilite,
constituind regulatorul întregului sistem;
• sistemul operaţional (condus sau de execuţie), ce are menirea de a executa operaţiunile din
cadrul activităţii declanşate ca urmare a unei decizii, folosind resursele stabilite conform
obiectivelor;
• sistemul informaţional (de legătură), ce asigură legătura în ambele sensuri între cele două
sisteme.
Sistemul informaţional oferă elemente pentru cunoaşterea modului de desfăşurare a
fenomenelor şi proceselor de natură economică şi socială dintr-o organizaţie. Atunci când apare o
problemă care trebuie rezolvată, în domeniul producţiei, al vânzărilor, al personalului, sistemul
informaţional ajută la evaluarea situaţiei existente, la depistarea cauzelor care o provoacă. El reprezintă

1
O’Brien J. A., „Introduction to Information Systems”, 8th Ed. Irwin, 1997.
un sprijin pentru managerii de la orice nivel ierarhic şi asigură o intervenţie operativă şi competentă în
organizarea şi dirijarea activităţilor, o exercitare corespunzătoare a controlului aplicării deciziilor luate.
Un sistem informaţional modern trebuie să asigure:
informarea la toate nivelele;
operativitatea informării;
selectarea informaţiilor;
adaptabilitatea la modificări (modificarea cererilor de informaţii, modificarea datelor de intrare,
modificarea structurii organizatorice, modificarea metodelor de prelucrare a datelor );
precizia şi exactitatea informaţiilor.
1.4 RAPORTUL DINTRE SISTEMUL INFORMAŢIONAL ŞI SISTEMUL INFORMATIC
Apariţia echipamentelor electronice de calcul au permis automatizarea sistemului informaţional
determinând, implicit, apariţia conceptului de sistem informatic.
În acest context, sistemul informatic a fost definit ca „un ansamblu coerent structurat, format
din echipamente electronice de calcul şi comunicaţie, procese, proceduri automate şi manuale, inclusiv
structurile organizatorice şi salariaţii, care folosesc calculatoarele ca instrumente de prelucrare
automată a datelor, în cadrul domeniului concret de activitate a agentului economic, în scopul
maximizării profitului realizat din acţiunea economică”.
Sistemul informatic reprezintă, de fapt, un sistem informaţional în care procesele informaţionale
se realizează integral sau prin utilizarea cu preponderenţă a mijloacelor automatice. În cazul în care
doar o parte din operaţiunile întregului sistem informaţional sunt prelucrate şi dezvoltate prin
intermediul calculatorului, adică automatizării, avem de-a face cu un sistem informaţional automatizat,
raportul dintre sistemul informaţional şi cel informatic fiind de întreg-parte .
INFORMAŢIONAL
SISTEMUL

SISTEMUL DE MANAGEMENT

SISTEMUL
INFORMATIC

Sistemul informatic imprimă valenţe sporite sistemului informaţional sub aspect calitativ şi
cantitativ. Astfel, se manifestă o creştere a capacităţii de calcul, sub aspectul volumului datelor de
SISTEMULde
prelucrat şi a operaţiunilor OPERAŢIONAL
efectuat, creşterea exactităţii informaţiilor, sporirea operativităţii şi
complexităţii sistemului de informare.
Schematic, prin prisma activităţilor, un sistem informatic poate fi reprezentat prin triada: intrări
– prelucrări – ieşiri(fig.1.3).
 Prelucrări Ieşiri
▪ hardware ▪
Intrări
▪ software liste/rapoar
▪ date
▪ resurse te
▪ informaţii
umane ▪ grafice
▪ operaţiuni
▪ stocare ▪ indicatori
date ▪ alte ieşiri

Control
▪ analize Feed - back
▪ decizii
Fig. 1.3 Structura unui sistem
informatic

Din reprezentarea grafică se observă componentele de bază ale oricărui sistem informatic, şi
anume: resursele umane, resursele hardware, resursele software, resursele de date şi resursele de reţele.
Resursele hardware cuprind totalitatea mijloacelor tehnice de culegere, transmitere, stocare şi
prelucrare a datelor.
Resursele software includ totalitatea programelor pentru funcţionarea sistemului informatic, în
concordanţă cu funcţiunile şi obiectivele ce i-au fost stabilite. Se au în vedere atât programele de bază
(SOFTWARE-ul de sistem), cât şi programele aplicative (SOFTWARE-ul aplicativ).
Resursele umane reprezintă toate categoriile de utilizatori care au acces la baza de date în
diverse faze ale ciclului de viaţă al acesteia.
Resursele de date cuprind datele supuse prelucrării, fluxurile informatice, sistemele şi
nomenclatoarele de coduri. Principalele structuri ale acestuia sunt bazele de date ce se regăsesc sub
forma colecţiilor de fişiere, tabele şi alte depozite de date, precum şi relaţiile dintre acestea.
Resursele de reţele se referă la totalitatea echipamentelor şi tehnologiilor de comunicaţie a
datelor între sisteme.
În tabelul 1.1 este prezentată o sinteză pe care am realizat-o cu privire la resursele sistemului
informatic şi produsele informaţionale.

Tabelul 1.1 Resursele sistemului informatic şi produsele informaţionale

Resurse umane
Specialişti – analişti de sistem, programatori, operatori.
Utilizatori finali – orice altă persoană care utilizează sistemele informatice.
Resurse hardware
Calculatoare – microcalculatoare (calculatoare personale), minicalculatoare, calculatoare
miniframe.
Alte dispozitive – ecrane video, tastatură, mouse, scanner, imprimantă, plotter
Medii de stocare – dischete, benzi magnetice, discuri magnetice, optice, CD-ROM, DVD, cartele
de plastic, formulare de hârtie.
Resurse software
Programe – sisteme de operare, aplicaţii pentru procesarea textelor, calcul tabelar, prezentare,
pachete de aplicaţii pentru gestiunea clienţilor, salariilor.
Proceduri – proceduri pentru introducerea datelor, de corectare a erorilor.
Resurse de date
Descrieri ale produselor.
Înregistrări privind clienţii.
Fişe ale angajaţilor.
Baze de date cu stocurile, partenerii firmei etc.
Resurse de reţele
Medii de comunicaţii – cabluri UTP, coaxiale sau din fibră optică, sisteme cu microunde, sisteme
de comunicaţii prin satelit.
Suport de reţea – procesoare de comunicaţii (modem, router, server, hub), software de control şi
de acces la reţea (sisteme de operare de reţea, navigatoare Internet).
Produse informaţionale
Rapoarte pentru management, documente şi situaţii cuprinzând text, grafice.
Elemente audio şi video.
Analizând aceste componente, putem spune că performanţele unui sistem informatic se pot
aprecia în principal, pe baza următoarelor cerinţe:
• să fie o colecţie de date corect proiectată şi implementată;
• să conţină programe aplicative de transformare a datelor în informaţii;
• să ofere informaţii centralizate pentru managementul producţiei.

2. METODOLOGII DE REALIZARE A SISTEMELOR INFORMATICE

2.1. METODE DE ABORDARE A SISTEMELOR INFORMATICE

Elaborarea unui produs informatic constituie o activitate deosebit de complexă. O asemenea
activitate nu se poate desfăşura decât pe baze metodologice riguroase, generatoare de eficienta şi
eficacitate în management şi în plan economic.
 Etapele de realizare a unui sistem informatic: analiză, proiectare, implementare sunt unanim
recunoscute de toţi realizatorii de sisteme informatice. Nu se pune în discuţie denumirea etapelor sau
succesiunea lor, ci modul de grupare a activităţilor necesare procesului de elaborare a unui sistem
informatic. Din aceste considerente etapele de realizare a unui sistem informatic sunt tratate în detaliu
sau mai superficial, în functie de contextul în care au aparut şi în functie de modul concret de realizare
a unui sistem informatic.
Un aspect comun pentru aceste etape şi activităţi este faptul că trecerea de la o etapă la alta se
face numai dupaă o analiză de fond a modului de realizare a sarcinilor, etapelor parcurse şi avizării de
către factorii de răspundere ai beneficiarului a rezultatelor obţinute.
De asemenea, orice etapă, parcursă deja, se finalizează cu activităţi de pregătire a etapei
următoare, prin elaborarea sau actualizarea planului de lucru.
Se desprinde concluzia, că realizarea unui sistem informatic impune folosirea unor resurse
materiale, umane şi financiare, iar utilizarea eficientă a acestora nu se poate realiza decât apelând la
cele mai performante şi moderne metodologii de realizare a sistemelor informatice.
Putem defini metodologia de realizare a unui sistem informatic ca “o implementare fizica a
ciclului de viata a sistemelor care include:
activităţi pas cu pas pentru fiecare etapă de lucru;
regulile individuale şi de grup pentru fiecare activitate;
standardele de calitate în fiecare activitate;
instrumentele şi tehnicile utilizate în fiecare activitate.”
O metodologie de realizare a unui sistem informatic este o mulţime de concepte fundamentale,
reguli de notaţie, ce sunt utilizate împreună cu mulţimea proceselor şi a regulilor empirice recomandate
pentru construirea modelelor şi implementarea lor. Altfel spus, o metodologie este o expresie a ciclului
de viata considerat ca fiind cel mai adecvat pentru dezvoltarea unui sistem dat.”
Din aceste definitii, constatam că o metodologie de realizare a unui sistem informatic
trebuie să cuprindă:
modul de abordare a sistemelor informatice;
modalităţi de derulare a ciclului de viata a sistemelor informatice;
metode şi tehnici de realizare a sistemelor informatice;
modalităţi de conducere a proiectului (planificare, organizare, urmărire).
Principalele metode de abordare a sistemelor informatice
Metodele de abordare a sistemelor informatice s-au transformat şi evoluat în paralel cu
dezvoltarea tehnologiilor informaţionale, a sistemelor informaţionale şi a organizaţiilor.
Multitudinea metodelor de abordare, determinată de caracteristicile activităţilor necesare
realizării sistemelor informatice, au fost comentate (caracterizate) de mulţi autori de specialitate, dar le
vom descrie pe cele considerate mai edificatoare.
 Autorii Yourdon şi Argila efectuează o trecere în revistă nu a metodelor, aşa cum le-am intitulat
noi anterior, ci a şcolilor.
De la forma incipienta a anilor 1950-1960, ce ar putea fi botezată …a programelor inteligibile,
referirea în mod evident fiind o trimitere la neputinţă înţelegerii de către majoritatea utilizatorilor
calculatoarelor a programelor scrise în cod – maşină sau în “criptatele” limbaje de asamblare, s-a ajuns
la un important moment de progres: modularizarea programelor.
Din curentul “gândirii modulare” s-a desprins şcoala descompunerii funcţionale. De fapt,
autorii consideră că aceasta ar fi prima şcoală veritabilă de abordare a sistemelor, în fiecare modul
existând câte o funcţie.
Alta şcoală, concurentă celei amintite anterior, pune la baza modulelor, datele. Crezul ei este
formulat astfel: “Fiecare modul trebuie să aibă încapsulată o structură de date”. Numai că proiectanţii
aplicaţiilor în timp real aveau altă opinie, şi anume: “Fiecare modul trebuie să recunoască şi să
răspundă unui eveniment”.
Analizând şcolile prezentate, putem spune că ele sunt orientate spre funcţii, spre date şi spre
evenimente. Pe acest fond, Yourdon şi Argila afirmă că apare o a patra şcoală, cu crezul: ”Fiecare
modul corespunde unui şi numai unui singur obiect din lumea reală” Autorii ajung la concluzia că
structurarea programelor nu va mai fi efectuată în funcţie de metodele de analiză, ci, în varianta
orientată-obiect, ea se va efectua în concordanţă cu problema de rezolvat. Virtual, orice componentă a
ciclului de viaţă al ingineriei softului poate fi încapsulata ca un obiect reutilizabil.
Istoricul şcolilor de mai sus este precedat de o altă grupare a metodelor de analiză, realizată tot
de Yourdon, însă în echipă cu Peter Coad. Cei doi autori prezintă patru modalităţi de abordare a
analizelor, considerate ca instrumente ale gândirii utilizate pentru a ajuta la formularea cerinţelor. Cele
patru metode sunt orientate spre funcţii, procese, informaţii (date), ultima fiind cea orientată obiect.
Autorii fac menţiunea că nu se pune problema desfiinţării metodelor vechi, ci a incorporării celor mai
bune idei ale primelor trei metode în una mai cuprinzătoare, atotcuprinzătoare – analiza orientată –
obiect
Într-o versiune proprie, David Brown sistematizează metodele de abordare a sistemelor
informatice în:
metode timpurii nesistematizate (1950 – începutul anilor 1960);
metode orientate-ieşiri (sfârşitul anilor 1960);
metode orientate-proces, prin apelarea la diagramele fluxurilor de date, DFD (anii
1970);
metode orientate-date, prin folosirea diagramelor entitate-relaţie, DER (anii1980);
metode orientate-obiect (anii 1990).
D. Oprea, consideră că metodele ar putea fi grupate, prin prisma celor mai mulţi autori, astfel:
metode orientate spre funcţii, numite şi metode ale descompunerii funcţionale;
 metode orientate spre fluxuri de date, deci spre procese, deoarece diagramele fluxurilor de
date se întrebuinţează pentru descrierea proceselor. Deseori, în formă lapidară, aceste
metode sunt denumite orientate - date.
metode orientate spre informaţii sau date, orientate-informaţii, probabil şi datorită
popularizării puternice a ingineriei informaţiei a lui James Martin, dar şi a diagramelor
entitate - relaţie ale lui Chen;
metode orientate-obiect.
Oricum, după cum afirmă James Martin şi James Odell: ,,există multe metode de realizare a
sistemelor; ele vor exista întotdeauna şi trebuie să existe întotdeauna. Diferite activităţii pot avea
caracteristici diferite care să necesite moduri diferite de abordare. Provocarea constă în selecţia şi
integrarea acestor metode’’. De fapt, referindu-se numai la metodele orientate-obiect, Hoffer, George şi
Valacich, în 1996, inventariau cel puţin 13 sisteme de notaţie, deşi, în 1994, T.F. Hutt lansase deja o
carte în care erau destul de detaliat descrise caracteristicile a peste 20 de metode orientate-obiect.
Steve Skidmore, citând cercetarea lui Ian Graham, în 1997, spune că au fost identificate
probabil 60 de metode complet orientate - obiect. Comentariile sunt de prisos.
Caracteristicile esenţiale ale principalelor metode de abordare a sistemelor
După prezentarea principalelor opinii exprimate în literatura de specialitate cu privire la
evoluţia şi clasificarea metodelor de abordare a sistemelor informaţionale, vom face o scurtă prezentare
a principalelor abordări în dezvoltarea sistemelor informaţionale. În acest sens, vom urma gruparea
prezentată în finalul paragrafului anterior şi care se regăseşte de altfel, în mod explicit sau implicit, în
majoritatea opiniilor exprimate în literatura de specialitate.
Metoda descompunerii funcţionale (orientate-funcţii)
Dintre autorii remarcabili care au abordat descompunerea funcţională îi enumerăm pe câţiva,
cum ar fi DeMarco, Yourdon şi Constantine, Jackson, Page-Jones, Warnier-Orr, Dahl, Marco & Mc
Gowan.
Descompunerea funcţională este cea care anunţă apariţia proiectării structurate şi analizei
structurate. Ea a fost concepută cu scopul controlării complexităţii prin operaţiuni de tipul devide et
impera. Fiecare funcţie este descompusă în subfuncţii ş.a.m.d., până când se obţin forme uşor de
transpus în instrucţiunile limbajelor de programare.
Şi în cazul descompunerii funcţionale conceptele specifice au fost introduse mai întâi în
programarea structurată (Dahl, 1972) şi apoi în proiectare, urmată de analiză. Aceeaşi situaţie este
întâlnită şi în varianta orientării - obiect.
Descompunerea funcţională (DF) este văzută ca o sumă de funcţii, subfuncţii şi interfeţe
funcţionale, sub forma unei ecuaţii:

DF=Funcţii
+Subfuncţii
 +Interfeţe funcţionale.

Printr-o astfel de reprezentare se ilustrează modul în care recunoaştem o descompunere

funcţională. Obiectul îl constituie prelucrările necesare în noul sistem. Analistul va specifica
prelucrările şi interfeţele funcţionale.
Metoda are ceva puncte tari:
simplitate - fiind o cale naturală de rezolvare a unei probleme;
obţinerea destul de lejeră a cerinţelor utilizatorului;
generarea de soluţii pe diferite niveluri de abstractizare (sistem, subsistem, funcţie,
subfuncţie).
Ca puncte slabe sunt descrise:
concentrarea eforturilor spre funcţii conduce la culegerea multor date redundante;
inexistenţa unor reguli precise de descompunere;
evidenţierea anevoioasă a interacţiunilor non-ierarhice din sistemele complexe.
Disfuncţionalităţile metodei au fost mult anihilate prin soluţii ingenioase de tipul coeziunii şi
cuplării, introduse spre sfârşitul anilor ’80 de Page & Jones şi Yourdon/Constantine.
Metoda fluxului de date(orientate-procese)
O altă metodă şi în acelaşi timp o altă modalitate de reprezentare a domeniului problemei şi
responsabilităţilor sistemului printr-o specificaţie tehnică este metoda orientată spre procese, deseori
descrisă ca ,,analiza structurată‘’.
Ecuaţia metodei este:
Metoda fluxului de date = Fluxul (şi controlul) datelor
+ Transformările (şi controlul) datelor
+ Stocarea (şi controlul) datelor
+ Terminatori
+ Specificaţii de proces
+ Dicţionarul datelor.

Prin această metodă, analiştii efectuează reprezentarea lumii reale prin linii ale fluxurilor în
analiza structurată. Se vorbeşte despre o metodă ,,veche”, cu reprezentanţii De Marco - 1978 şi Gane &
Sarson - 1977, şi despre o metodă ,,modernă“ de analiză structurată, lansată în dezbateri la nivelul
anului 1982 şi prin materiale editate în 1984 - reprezentative fiind lucrările autorilor McMenamin &
Palmer, din 1984, şi a lui Yourdon, Analiza modernă structurată, din 1989. În ultima variantă sunt
definite cu claritate evenimentele din lumea reală la care sistemul trebuie să răspundă, o formă
embrionară a actualelor interacţiuni dintre utilizator şi sistem, bazate pe mesaje. De asemenea, printr-o
documentaţie suplimentară, sunt incluse fluxurile datelor şi transformărilor la nivel inferior prin
intermediul dicţionarului de date, respectiv al specificaţiilor proceselor.
 Cum metoda orientată pe procese are încă un mare grad de asemănare cu descompunerea
funcţională, criticile metodei descrise anterior se raportează şi în cazul de faţă. Oricum, după cum se va
vedea ulterior, multe elemente ale acestei metode sunt preluate de către metodele orientate-obiect.
Metode orientate spre informaţii (orientate-date)
Două realizări remarcabile în domeniu au dat tonul unei noi orientări în abordarea sistemelor:
modelarea datelor cu ajutorul diagramelor entitate-relaţie, de către Peter P. Chen (1976) şi ingineria
informaţiei, în viziunea lui James Martin. Acestora li s-au adăugat alte reuşite de esenţă.
Termenul ,,obiect’’ este lansat la mijlocul anilor ‘70 într-o formă ,,originală‘’, nestandard, dacă
ne gândim fie la semnificaţiile anterioare ale lui , fie la cele curente , firesc , din domeniul abordării
sistemelor. Aşa cum este el folosit de Chen , de cei ce se ocupă cu modelarea informaţiilor (cum ar fi
Flavin, în 1981) sau de cei ce tratează modelarea semantică a datelor (Shlaer & Mellor, în 1988),
obiectul este un simbol prin care se reprezintă una sau mai multe ,,ocurenţe’’ (cazuri) ale ,,entităţilor”
lumii reale.
Metoda este identificată prin următoarea ecuaţie:
Modelarea informaţiilor = Obiecte
+Atribute
+Relaţii
+Supertipuri/Subtipuri
+Obiecte asociative
Coad şi Yourdon spun că şi în acest caz se poate vorbi despre existenţa a două strategii.
Strategia veche se bazează pe conceperea listei atributelor gruparea lor în obiecte, stabilirea de
relaţii între ,,ocurenţe” (cazuri), folosirea supertipurilor/subtipurilor pentru extragerea atributelor
comune şi definirea obiectelor asociative pentru reliefarea relaţiilor sigure.
Noua strategie este destul de apropiată de precedenta, cu excepţia primului pas, care îşi propune
mai întâi să identifice obiectele lumii reale şi apoi urmează descrierea lor cu ajutorul atributelor.
Specialiştii apreciază salturile înregistrate, însă , în acelaşi timp fac inventarul conceptelor
inexistente, cum ar fi: servicii,moştenire,structură.
Metode orientate-obiect
Întrucât acest subiect necesită multe descrieri preliminare, deocamdată nu vom face decât o
foarte sumară prezentare. Sintagma ,,orientat - obiect” este destul de greu de definit din cauza
accepţiunilor diferite ce i-au fost date de diversele discipline. Numai în domeniul informaticii există
vreo trei variante: una folosită în modelarea informaţiilor , alta în programare şi a treia, cea de faţă,
utilizată în analiza şi proiectarea sistemelor, de cele mai multe ori identică semnificaţiei din
programare. Fiind un domeniu relativ nou, este normal să existe o mare diversitate de opinii până şi
asupra termenului ,,obiect”.
 Pentru a continua regula prezentării ecuaţiei ce caracterizează metoda, o vom reda în cele ce
urmează:

Orientat-Obiect = Clase şi Obiecte

+ Moştenire
+ Comunicaţii prin mesaje.

Conceptele de obiect şi clasă sunt independente: un obiect aparţine unei clase (este o instanţă a
clasei), iar o clasă este o grupare logică a obiectelor care au aceeaşi structură şi un comportament
similar.
Un obiect este o abstractizare a datelor elementare şi poate fi descris astfel:

Obiect = Identitate
+ Comportament
+ Stare.

Identitatea obiectului se realizează printr-un identificator al obiectului, care este un atribut

invariabil ce permite ca obiectul să fie referit independente de celelalte obiecte. Identificatorul este
generat de sistem la crearea obiectului.
Starea obiectului este o valoare care poate fi simplă (de exemplu, un literal) sau structură(de
exemplu, o listă). în ultimul caz, ea poate fi compusă din valori simple, referinţe la alte obiecte sau
valori care sunt structurate ele însele.
Comportamentul unui obiect este definit printr-un set de operaţiuni ce-i pot fi aplicate şi este
descris în clasa căreia îi aparţine obiectul.
În concluzie, obiectul este o abstractizare a datelor elementare, caracterizat printr-un
identificator unic, invariabil, o clasă căreia îi aparţine şi o stare reprezentată printr-o valoare simplă sau
structură.

2.2 MODELE ALE CICLULUI DE VIAŢĂ A SISTEMULUI INFORMATIC

Mutaţiile din domeniul tehnologiilor informaţionale şi al metodelor de abordare a sistemelor s-
au reflectat şi în ciclul de viaţă al dezvoltării sistemelor, fie prin schimbările etapelor acestuia, fie prin
modificarea ordinii de parcurgere a lor. Indiferent de numele şi de numărul etapelor ciclului de viaţă al
dezvoltării sistemelor, o problemă mult mai importantă este aceea a ordinii şi felului cum se parcurg
etapele respective, ceea ce în literatura de specialitate se tratează sub numele de „modele ale ciclului de
viaţa a sistemului informatic”.

În practică se regăsesc următoarele tipuri de modele:

model cascadă;
 model V;
model incremental;
model spirală;
model evolutiv;
model tridimensional;
model X;
model fântână arteziană;
model pinball;
model minge de baseball;
model piramidă.
Modelul cascadă este unul de referinţă asigurând trecerea de la o etapă la alta în ordinea
secvenţială a posibilităţii revenirii la etapele anterioare sau parcurgerii în paralel a mai multor etape.
(Fig 2.1)

Definirea
cerinţelor

Analiză

Proiectare

Implementare

Testare

Utilizare şi
întreţinere

Utilizare şi întreţinere
Avantaje:
controlează toate fazele în sensul ca ele au o ordine strictă şi aria lor de
întindere e clară;
modelul este uşor de însuşit de membrii echipei de proiectare;
fiecare etapă este însoţită de documentaţie.
Dezavantaje:
sistemul informatic se predă după parcurgerea tuturor etapelor ceea ce
înseamnă un interval mare de timp, în care pretenţiile utilizatorului se pot
schimba;
modelul nu corespunde unei abordări dinamice;
 nu este deschis schimbărilor.
Modelul V este o variantă a celui cascadă prin care se introduc conceptele de componente,
subsisteme, aplicându-se teste explicite la nivel ierarhic pentru creşterea controlului asupra modului în
care se desfăşoară etapele, obţinând în felul acesta o latură a literei V. (Fig 2.2)

Definirea
Validare
cerinţelor

Proiectare sisteme Testare sisteme

Proiectare subsistemelor Testare

(componente) subsisteme

Fig 2.2 Codificare/Asamblare

componente
Prima latură se parcurge descendent şi conţine etapele propriu-zise ale unui sistem informatic,
iar a II-a se parcurge ascendent şi cuprinde toate etapele de verificare şi validare.
Modelul incremental este o altă formă a modelului cascadă: până la etapa de proiectare nu
există diferenţe. După aceea se efectuează descompunerea proiectului în subproiecte. Faţă de modelul
V, oferă posibilitatea atingerii scopului final în două variante: sistemul global livrat la sfârşit sau
componente livrate distinct. (Fig 2.3)

Instalare
Definirea Proiectare componenta 1
cerinţelor componenta 1

Întreţinere
Implementare componenta 1
Analiza
componenta 1

Arhitectura Instalare
sistemului Proiectare componenta n
componenta n

Întreţinere
Implementare componenta n
componenta n
Fig 2.3
Avantaje:

perioade de realizare scurte pentru că livrarea se face pe componente;

lucrul în echipă oferă posibilitate de realizare a mai multor proiecte.
Dezavantaje:

imposibilitatea aplicării modelului în orice condiţii, uneori neexistând

posibilitatea descompunerii în componente;
costurile de asamblare sunt mult mai mari prin realizarea testelor multiple.

Modelul spirală (Fig 2.4)se bazează pe două convingeri:

natura iterativă a dezvoltării şi nevoia de planificare şi evaluare a riscurilor
fiecărei iteraţii.
deficienţa înregistrărilor la modelul V în care validarea se efectuează prea
târziu.

Prototip
1
Prototip
2
Prototip
3
Prototip
Fig 2.4 4

În orice iteraţie se va regăsi modelul cascadă.

Avantaje:

posibilitatea evaluării riscurilor în diferite momente ale proiectului;

simplificarea etapei de evaluare în ceea ce este necesar în etapa (prototipul)
următoare inclusiv prin prisma costurilor.
Dezavantaje:
 echipa de realizare trebuie să aibă un înalt nivel de profesionalism;
flexibilitate în acţiune.
Modelul evolutiv constă în descompunerea proiectului în părţi, fiecare cu o valoare deosebită
pentru client. Aceste părţi sunt realizate şi livrate în mod iterativ şi contribuie la sporirea
performanţelor sistemului. (Fig 2.5)
Părţile obţinute pentru completare nu sunt foarte detaliate tocmai în vederea adaptărilor şi
modificărilor ulterioare.
Oricare din aceste segmente luate în studiu trece prin toate etapele de dezvoltare a sistemului.
Reuşita modelului constă în crearea unei arhitecturi deschise elaborării prin participarea tuturor
utilizatorilor.
Studiul iniţial
Descompune
re în
segmente

Segment 1 Segment n
Def. cerinţe Implementare Def. cerinţe Implementare
Analiză Testare Analiză Testare
Proiectare Utilizare Proiectare Utilizare
Fig 2.5
Modelul 3D redă dezvoltarea sistemului printr-o reprezentare grafică în spaţiu. Pe o axă avem
ciclul de viaţă al sistemului (CVS), pe a II–a ciclul de viaţă al proiectului (CVP) şi pe ultima ciclul
abstractizării (CA). (Fig 2.6)

CA
Sistem generaţia I
Nivel conceptual
Sistem generaţia II
Nivel logic
Sistem generaţia III
Nivel fizic

Studiu preliminar
CV
S
Studiu detaliat
T1 T2
T3
Studiu tehnologic

CVP Fig 2.6

 Ciclul de viaţă al sistemului – principalele perioade după care se fac schimbări majore, creşterea
volumului de date, modificări tehnologice, modificări structurale.
Modelul X (Fig 2.7) îşi propune să extindă performanţele obţinute prin modelul cascadă şi prin
modelul V. Acesta introduce noţiunea de model al livrării, fiecare proces sau etapă a dezvoltării
sistemelor poate fi privit şi urmărit ca o iteraţie sau evoluţie spre soluţia acceptată.
Modelele livrării sunt independente. Din punct de vedere tehnic. Acest lucru a făcut posibilă
exprimarea în partea superioară a „X”-lui a responsabilităţilor softului curent şi în cea inferioară a
componentelor fizice ale softului.
Modelul X exprimă două categorii de cicluri de activitate: una derulantă înainte care
sintetizează sistemul nou şi una înapoi pentru dobândirea sistemului şi a componentelor sale pentru o
posibilă reutilizare.
Obţinerea viziunii şi
Livrare sisteme
cerinţelor
Specificaţia sistemului
Testare
Proiectare şi testare
sisteme
arhitectură sistem

Selecţie şi adaptare Constr, testare Achiziţie

componente

Asamblare

Fig 2.7 Biblioteca Rafinare

componentă componentă
Modelul fântână arteziană (Fig 2.8) îşi are originea în cel cascadă, dar reprezintă o variantă
îmbunătăţită înBiblioteca
sensul că perioada de timp pentru finalizare e mai scurtă şi componentele sale pot fi
Biblioteca
domeniului structură Biblioteca structură
reutilizate în modele similare.
Biblioteca Restabilire domeniu
aplicaţiei

Studiu

Fond software
 Fig 2.8

Modelul pinball (Fig 2.9) constă în deplasarea aleatoare a unei bile în mediul orientat obiect
redat sugestiv sub forma unui teren de pinball.

I I
M N
P Găsire T
L clase R
E Definire Determinare Definire E
M agregări atribute subsistem T
E Aflare I
N metode N
T E
A Gasire RE
R relaţii
E PRO
I
Definire Codificare
PRO Testare Definire ECT
colaborări
I moştenire
ECT

Fig 2.9
Modelul minge de baseball (Fig 2.10) sau dezvoltare concurentă: principiul lui este acela al
proiectării în paralel a activităţilor: analiză orientată obiect, proiectare şi programare orientată obiect.
Pentru ca modelul să dea rezultate echipa trebuie să fie formată din experţi în domeniul analizei,
administrării datelor, cel al interacţiunii umane şi medii şi limbaje de programare.

00 00
A D

00P
 Fig 2.10

Modelul piramidă (Fig 2.11) se aplică în exclusivitate mediilor orientate obiect. Arată că
etapele unui ciclu de viaţă înseamnă trecerea spre mai multe detalii, pornindu-se de la nivelul superior
al planificării spre analiza domeniului, proiectarea şi construirea lui.

Planificarea Analiza
întreprinderii domeniului
întreprinderii

Proiectare
sistem

Construcţia
Fig 2.11 componentelor
obiectului
2.3 CLASIFICAREA METODOLOGIILOR DE REALIZARE A SISTEMELOR
INFORMATICE
Folosirea eficientă a resurselor şi necesitatea realizării unor sisteme informatice performante au
impus ordonarea într-o succesiune bine stabilită pe etape şi subetape a acestui proces determinând
conturarea unor metodologii de realizare a sistemelor informatice.
O metodologie de realizare a unui sistem informatic stabileşte componentele procesului de
realizare: etapele, subetapele, activităţile şi conţinutul lor; fluxul executării componentelor, metodelor,
tehnicile şi instrumentele de realizare
O metodologie de realizare a unui sistem informatic trebuie să cuprindă:
Etapele/procesele de realizare a sistemului infomatic cuprind subetape, activităţi şi
sarcini;
Fluxul realizării acestor etape/procese;
Modalităţile de desfăşurare a ciclului de viaţă a sistemului informatic;
Modul de abordare al sistemelor;
Strategiile de lucru/metodele de realizare;
Tehnicile, procedurile, instrumentele, normele şi standardele utilizate;
 Modalităţile de conducere a proiectului şi modul de utilizare a resurselor financiare,
umane şi materiale.
O primă clasificare a metodologiilor se poate face după gradul de generalizare:
Metodologii generale au un grad înalt de generalitate putând fi folosite pentru
realizarea sistemelor informatice din diferite domenii.
Enumerăm câteva metodologii generale:
 SSADM (Stuctured System Analysis and Design Methodology);
 MERISE (Methode d’Etude et de Realization, Informatique pour les Systemes
d’Entreprise);
 OMT (Object Modeling Technique);
 RUP (Rational Unified Process).
Metodologiile cadru cuprind elemente aplicabile exclusiv numai unor produse
software.
Metodologii specializate sunt cele dezvoltate şi utilizate pentru implementarea unui
singur produs software. Enumerăm câteva metodologii specializate:
 AIM (pentru Oracle E Business Suite)<
 POIS (pentru Sun Systems);
 Extract (pentru Extract);
 Signature (pentru Scala);
 ASAP (pentru SAP).

A II-a clasificarea a metodologiilor se face după modul de abordare a sistemelor:

Metodologiile cu abordare structurată
Metodologiile cu abordare orientată obiect
Metodologiile cu abordare structurată au ca principiu de lucru împărţirea sistemului în
subsisteme pe baza funcţiilor sistemului sau în funcţie de date.
Aceste metodologii propun modelarea datelor separat de modelarea procedurilor. Modelarea
sistemului se face plecând de la ideea că sistemul nu este izolat, ci există în cadrul unui mediu cu care
interacţionează. Sistemul reacţionează la evenimentele transmise din mediu printr-un răspuns. Sistemul
este afectat de mediu, dar nu controlează mediul.
Sistemul este structurat după diverse criterii în subsisteme până când se ajunge la nivel
elementar, punându-se în evidenţă relaţiile dintre subsistemele identificate. Abordarea acestor
subsisteme se face din puct de vadere: static, funcţional şi dinamic. În final rezultă modelul logic şi
modelul fizic. Modelul fizic al sistemului prezintă structura tehnică a sistemului, iar modelul logic al
sistemului arată ce face sistemul, fiind mai stabil în timp şi independent de implementare.
Metodologiile structurate prezintă avantaje din care prezentăm câteva:
planificarea proiectului în subsisteme;
 un mediu bine structurat este flexibil din punct de vedere al coportamentului, are
obiective clare, o arie de cuprindere cunoscută;
modificarea unei activităţi nu conduce la reluarea integrală a studiului.
Metodologiile cu abordare orientată obiect permit construirea sistemelor informatice folosind
conceptele tehnologiei orientate pe obiecte.
Tehnologia orientată obiect a apărut odată cu apariţia limbajelor de programare orientate pe
obiecte.
Dintre metodologiile orientate obiect de realizare sistemelor informatice enumerăm:
OOD (Object Oriented Design) – o metodologie similară metodologiei OMT,
dezvoltând analiza şi proiectarea iterativă – elaborată de Gray Booch;
OOA (Object Oriented Analysis) – elaborată de Peter Coad şi Edward Yourdon;
OOSD (Object Oriented Structured Design) – o metodologie elaborată de Wasserman;
OOSA (Object Oriented System Analysis) – o metodologie de proiectare a sistemelor în
timp real propusă de Sally Shlaer şi Steven Mellor;
OMT (Object Modeling Technique) eleborată de James Rumbaugh şi Michael Blaha.
Toate aceste metodologii prezentau o serie de neajunsuri precum multiple diferenţe de
simboluri, notaţii sau tipuri de diagrame. Aceste aspecte generau dificultăţi în privinţa înţelegerii,
preluării şi folosirii lor de diferite grupuri de utilizatori, în crearea de noi sisteme sau în procesul de
mentenanţă a sistemelor.
Marea parte a acestor probleme au fost rezolvate prin introducerea unui standard cu privire la
simboluri, notaţii, tipuri de diagrame numit UML (Unified Modeling Language).
Unii analişti programatori utilizează doar un subset al UML-ului, alţii folosesc întreg setul
UML, utilizând diagramele de stare şi de activitate pentru a modela sisteme în timp real şi diagrama de
implementare pentru a modela sisteme distribuite.
Metodologiile orientate obiect prezintă avantaje din care prezentăm câteva:
Datele şi prelucrările nu sunt reprezentate distinct, ci încapsulat în clase de obiecte,
mîrinduse coerenţa rezultatelor analizei;
Modele utilizate sunt flexibile şi uşor de întreţinut;
Îmbunătăţirea comunicaţiei între utilizatori, analişti, proiectanţi şi programatori;
Reutilizarea rezultatelor analizei, proiectării şi implementării;
Reprezentarea explicită a elementelor comune tuturor componentelor sistemului.

2.4 METODE ŞI TEHNICI DE REALIZARE A SISTEMELOR INFORMATICE

Metodele utilizate în proiectarea sistemelor informatice reprezintă modul unitar sau maniera în
care analiştii de sistem, programatorii realizează procesul de analiză a sistemului informaţional -
decizional existent, proiectarea şi introducerea sistemului informatic. Metoda are un caracter general, în
cadrul ei aplicându-se anumite tehnici de lucru.
 Tehnicile de lucru utilizate în proiectarea sistemelor informatice reprezintă felul în care se
acţionează eficient şi rapid, în cadrul unei metode, pentru soluţionarea diferitelor probleme ce apar în
procesul de proiectare.
În activitatea de realizare a sistemelor informatice unele dintre metode şi tehnici sunt specifice
activităţii de analiză, proiectare sau programare,altele sunt generale şi pot fi utilizate în toate etapele de
realizare a sistemelor informatice.
Dintre metodele şi tehnicile utilizate în realizarea sistemelor informatice enumerăm:
Metoda descendentă (Top-Down);
Metoda ascendentă (Bottom-Up);
Metoda LCS/LCP (Logical Construction of System / Programs)
Tehnica concordanţei intrări-ieşiri
Tehnica HIPO;
Metoda descendentă (Top-Down)
Metoda constă în descompunerea unui sistem complex pe niveluri ierarhice, succesiv, până la
module elementare, simple şi relativ independente care sunt controlate de module coordonatoare.
Metoda are ca cerinţă de aplicare modularizarea sistemului, obiectivul principal fiind realizarea
modularizării de sus în jos, rezultând şi obiectivele specifice: crearea posibilităţii de realizare în paralel
a componentelor sistemului informatic şi eliminarea din sistem a redundanţelor. Rezultatul realizării
modularizării este modulul.
Modulul terminal este cel care nu mai poate fi descompus. Orice modul se poate integra cu un
alt modul formând noi module şi poate fi integrat mediului din care provine.
Procesul de descompunere se repetă până când toate modulele sunt considerate terminale.
Descompunerea are la bază următoarele reguli:
Nivelul zero de descompunere sau punctul iniţial de pornire îl reprezintă modul
neterminal sau coordonator;
Pentru toate modulele neterminate ale unui nivel se aplică descompuneri succesive în
paşi de sus în jos;
Descompunerea este terminată când modulele ultimului nivel sunt terminale.
Această metodă prezintă avantajul că oferă în orice moment o imagine de ansamblu asupra
problemei de rezolvat şi nu este necesară cunoaşterea apriorii a domeniului problemei, aceasta
realizându-se pe parcurs.
Prezintă dezavantajul unei analize complexe, laborioase, care antrenează un personal numeros
şi conduce la prelungirea timpului de realizare a sistemului iar strecurarea unor erori sau imprecizii în
definirea structurii şi a relaţiilor dintre componentele sistemului afectând activitatea până în momentul
respectiv.
Metoda ascendentă (Bottom-Up)
Metoda constă în agregarea modulelor de jos în sus punând în evidenţă legăturile dintre ele
până se ajunge la un singur modul.
Modularea şi abordarea sistemică sunt conceptele care stau la baza acestei metode, aceleaşi ca
la metoda de abordare descendentă.
Regulile care stau la baza metodei sunt:
Nivelul de agregare iniţial este nivelul la care se află modulele terminale;
Agregarea se face succesiv de jos în sus;
Când se obţine un nivel de agregare se realizează integrarea modulelor de nivel inferior
în module de nivel superior;
Agregarea este terminată când la un nivel de agregare se obţine un singur modul.
Avantajul folosirii acestei metode ar fi acela că sistemul informatic se dezvoltă treptat, în
corelaţie cu cerinţele beneficiarului. Beneficiarul beneficiază de rezultatele prelucrării automate a
datelor mai repede, se familiarizează cu noul sistem gradat. Se reduce riscul realizării unui sistem
neoperaţional în momentul punerii în aplicaţie.
Dezavantajul acestei metode rezultă din gradul de integrare redus al modulelor datorită lipsei
unei concepţii iniţiale de ansamblu, ceea ce face necesară reproiectarea unor componente.
Metoda LCS/LCP (Logical Construction of System / Programs)
Această metodă este cunoscută şi sub denumirea de metoda Warnier sau ”Legi de
concepere/construire a sistemelor/programelor”, această metodă are la bază un ansamblu de principii de
structurare a modulelor în funcţie de structura datelor de ieşire. Ea permite specificarea condiţiei de
executare şi a numărului de efectuări ale procedurilor care sunt structurate până la nivelul elementar.
Tehnica concordanţei intrări-ieşiri este o tehnică ce se utilizează atât la analiză, cât şi la
proiectare.
Plecând de la informaţiile necesare fundamentării deciziilor se determină mulţimea
informaţiilor primare ale sistemului respectiv. Pe baza sistemului de decizii identificat se determină în
continuare informaţiile de ieşire din sistemul informaţional, necesare fundamentării acestor decizii.
Această metodă de determinare a informaţiilor de intrare pe baza celor de ieşire este utilă în
cazul sistemelor complexe, cu multe informaţii.
Abordarea analizei poate fi făcută şi plecând de la intrări şi ajungând la ieşirile sistemului
informaţional.
Metoda prezintă dezavantajul că nu este posibilă punerea în evidenţă a tuturor legăturilor dintre
datele primare existente în sistem.
Tehnica HIPO este concepută pentru abordarea ierarhizată a sistemului informaţional urmărind
descrierea fluxului INTRĂRI – PRELUCRĂRI – IEŞIRI.
Această tehnică se concretizează în elaborarea unei documentaţii care este alcătuită din:
HIPO general;
 HIPO de detaliu;
HIPO de întreţinere.
HIPO general prezintă structura funcţională a sistemului şi stă la baza proiectării şi a
comunicării în cadrul echipei de proiectare a sistemului.
HIPO de detaliu prezintă o descriere generală şi de detaliu a structurii tuturor
fişierelor/entităţilor/relaţiilor folosite.
HIPO de întreţinere prezintă documentaţia corectată şi completată după testarea şi
implementarea sistemului informatic.
Fiecare documentaţie în parte trebuie să conţină:
Tabela de conţinut care conţine structura funcţională ierarhică cu legături între
componente. Descompunerea ierarhică trebuie să respecte concepţia de bază a acestei
tehnici (INTRĂRI – PRELUCRĂRI – IEŞIRI) şi să permită asocierea, pentru fiecare
nivel descompus, a cel puţin o diagramă generală.
Diagrama generală prezintă funcţiile importante ale sistemului conţinând reprezentarea
grafică a fluxului INTRĂRI – PRELUCRĂRI – IEŞIRI cu detalierea acestor funcţii.
Diagrama de detaliu prezintă descrierea analitică a fiecărei funcţii majore din diagrama
generală, prin descompunerea acestora până la ultimul nivel de obţinere a tuturor
informaţiilor privind fluxurile INTRĂRI – PRELUCRĂRI – IEŞIRI şi ultimele relaţii de
flux de pe ultimul nivel de detaliere.

2.5 ELABORAREA PLANULUI DE REALIZARE A SISTEMELOR INFORMATICE

Organizarea şi conducerea proiectelor (managementul proiectelor)
Organizarea şi conducerea proiectelor, cunoscută în literatura de specialitate sub titulatura de
Managementul proiectelor (în limba engleză Project Management), se ocupă de planificarea,
coordonarea şi controlul activităţilor complexe şi diverse din cadrul proiectelor.
Majoritatea proiectelor au o caracteristică comună, şi anume, prezenţa în pregătirea şi realizarea
lor a elementelor de risc şi incertitudine. Funcţia acestei tehnici este de a prognoza cât mai multe
obstacole şi probleme ce pot apărea şi de a planifica, organiza şi controla activităţile astfel încât
proiectul să fie realizat cu succes în ciuda tuturor riscurilor.
Scopul managerului proiectelor este de a contribui la realizarea proiectelor în perioada de timp
stabilită şi la încadrarea resurselor folosite în bugetul stabilit iniţial.
Managerul de proiect
Planificarea şi coordonarea întregii activităţi privind realizarea proiectului informatic revine
managerului de proiect. Acesta reprezintă persoana cea mai autorizată să decidă care este cea mai bună
strategie pentru realizarea proiectului, care este cea mai bună organizare a echipei, prin poziţionarea
membrilor acesteia în posturile adecvate pentru a-şi indeplini sarcinile cât mai bine şi mai eficient.
 Pentru dobândirea unui cât mai mare succes, managerul de proiect trebuie să dea dovadă de o
serie de calităţi deosebite. Calitatea primordială a managerului trebuie să fie abilitatea de a motiva
oamenii cu care lucrează, indiferent de mijloacele folosite pentru a realiza acest deziderat.
Personalul care participă la proiect va aprecia managerul care dovedeste competenţă, ia decizii
clare, dă instrucţiuni clare, ştie să asculte şi acceptă sfaturile bune, care este entuziast şi încrezător,
care impune respectul celorlalti prin propriul exemplu de conduită.
Rolul managerului este să planifice, să organizeze, să coordoneze, să controleze şi să conducă.
Aceste sarcini pot fi grupate în cinci categorii, evidenţiate în figura 2.12

Analiza cost-beneficiu
Evaluare
economica Prezentare rapoarte

Planificare timp
Planificare
Planificare resurse

Inregistrare actiuni
Controlul
Managerul Control realizari
progreselor
proiectului
Raportare progrese

Selectie si pregatire
Conducere
personal Conducere si coordonare

Planificare cu
implicarea clientilor
Relatii cu
Raportare progrese
clientii
Rezolvare probleme
curente

Figura 2.12 Sarcinile managerului de proiect

Se are în atenţie modelarea noului sistem în aşa fel încât acesta să satisfacă cerinţele
utilizatorilor. Aceasta înseamnă nu numai livrarea proiectului în stare de funcţionare, la timp, cu costuri
minime, dar mai ales ca acesta să satisfacă pretenţiile pentru care a fost creat şi care îl vor folosi în
viitor. De aceea se va pune mare accent pe importanţa implicării utilizatorilor în timpul studiului,
analizei, proiectării şi implementării sistemului informatic, precum şi pe încurajarea participării în
realizarea efectivă a acestuia prin idei furnizate conducătorului de proiect.
Planificarea proiectelor informatice
Planificarea are drept scop îndeplinirera obiectivelor proiectelor, obiective precizate mai jos:
Performanţă şi calitate. Rezultatul final trebuie să corespunda scopului. În acest sens,
standardele de calitate joacă un rol important.
Încadrarea în bugetul alocat. Neîncadrarea în buget poate conduce la reduceri ale profitului şi
la rate de eficienţă mai scazută ale investiţiei.
Încadrarea în durata de realizare. Trebuie urmărit ca toate etapele proiectului să se încheie la
momentul prevăzut, pentru a permite încheierea proiectului la sau înaintea datei prestabilite. Dacă se
depăşeşte durata de realizare pot apărea două aspecte negative: se depăşeşte, cu mare probabilitate
bugetul alocat şi se afectează planificarea resurselor pentru următoarele proiecte. Obiectivele sunt
corelate între ele ca în fig. 2.12

Performanţa

Cost Timp (durata)

Figura 2.12 Triunghiul obiectivelor proiectelor

Triunghiul arată corelatia dintre cele trei obiective. În unele situaţii, anumite priorităţi pot face
ca unul sau altul din aceste obiective să capete o importanţă mai mare decât celelalte.
Principalii paşi în planificarea proiectelor
În tabelul 2.13 se prezintă aceşti paşi şi metodele de realizare a lor
Tabelul 2.13
Pasul Metoda de realizare
1. Definirea obiectivelor Studiu de fezabilitate având ca rezultat
tehnice: o specificaţie tehnică
financiare Estimarea costurilor pentru soluţia
 de programare în tehnică propusă, având ca rezultat un
timp buget al proiectului
Evidenţierea derulării programului pe
o diagramă. Duratele activităţilor se
pot determina din experienţa unor
proiecte trecute
2.Impartirea proiectului în Pregatirea listei activităţilor necesare şi
părţi ce pot fi organizate a departamentelor sau organizaţiilor
şi conduse responsabile
3. Decizia, la nivel de Folosirea diagramelor tip bara pentru
detaliu, privind ceea ce proiectele simple sau a analizelor tip
trebuie făcut şi în ce reţea pentru proiectele capitale sau
succesiune complexe
4. Estimarea duratelor Considerarea timpului necesar derulării
fiecărei activităţi unei anumite activităţi. Nu se iau în
considerare resursele, la nivelul acestui
pas
5. Uutizarea duratelor Utilizarea diagramelor tip bară pentru
activitatilor pentru proiectele simple şi a analizelor tip
estimarea duratei reţea pentru proiectele complexe. Dacă
proiectului şi a rezultatele nu sunt acceptabile, se pot
importantei fiecarei face modificări în estimări sau în
activitati pentru obiectivele legate de durate.
obiectivele proiectului
legate de timp
6. Punerea de acord a Alocarea resurselor având în vedere
programului cu resursele diagramele tip bară, pentru proiectele
ce pot fi procurate mici, şi analizele tip reţea pentru
proiectele capitale sau complexe.

7. Atribuirea sarcinilor Este necesară cunoaşterea individuală a

participanţilor la proiect fiecărui participant la proiect din punct
de vedere al competenţei tehnice, al
vitezei de lucru, al calităţii muncii pe
care o depune şi al altor calităţi
speciale

Desfăşurarea în timp a proiectului

 Pentru ca managementul unui proiect să fie cât mai eficient, elementele planului de realizare a
proiectului trebuie estimate cât mai corect şi aranjate într-o secvenţă logică de derulare cât mai coerentă
şi logică.
În prima fază se procedează la inventarierea şi întocmirea listei de activităţi care trebuie
executate.
Lista de activităţi trebuie să fie cât mai cuprinzătoare şi pentru elaborarea ei se poate recurge la
o sesiune de braistorming cu alţi conducători de proiecte şi cu conducerea firmei beneficiare. Cu
această ocazie se va urmări în mod deosebit menţionarea activităţilor, nu şi succesiunea acestora.
În faza următoare, activităţile inventariate vor fi descompuse în subactivităţi stabilind
succesiunea logică a lor şi apoi planificate în timp.
Pe baza normativelor existente, dar mai ales a experienţei acumulate, se trece la stabilirea
duratei activităţilor din listă. Durata fiecărei activităţi depinde de etapa de realizare în care ne găsim.
Unitatea de exprimare a duratei este, de regulă, ziua sau săptămâna şi este recomandat ca durata unei
activităţi să fie multiplu de acea unitate.
În cazul proiectelor foarte simple, este posibil ca durata acestora sa fie egală cu suma duratelor
activităţilor componente. Aceasta se poate întâmpla când o singură persoană se ocupa de analiză,
proiectare, programare şi implementare. Situaţia normală însă este când lucrează o echipă formată din
mai multe persoane şi fiecare are câte o sarcină distinctă. Durata generală depinde de
intercondiţionările dintre aceste sarcini şi de ordinea în care sunt realizate. Numărul de activităţi care se
pot realiza în paralel depinde de numărul de membri care sunt în echipă şi de faza în care se găseşte
proiectul.
După estimarea duratei activităţilor, lista activităţilor se poate completa cu duratele
corespunzătoare şi apoi se face cunoscută tuturor membrilor echipei astfel încât distribuirea sarcinilor
să fie pe cât posibil echitabilă.
Pentru planificarea în timp a proiectului se utilizează mai multe metode, tehnici şi instrumente,
având un caracter general de aplicabilitate, nu numai pentru proiectele informatice. Cele mai utilizate
sunt “diagramele tip bară” – derivate din mai cunoscutele “diagrame Gantt”, numite astfel dupa
inginerul american Henry Gantt(1861-1919) – sau analizele tip retea.

A. Diagrame Gantt (tip bară)

Diagramele de planificare tip bara sunt usor de realizat şi interpretat şi, de asemenea, se
adapteaza usor la diversele cerinte de planificare. Limitările acestuia sunt legate de numărul de
activităţi care pot fi desenate fizic pe o foaie de hârtie şi de numarul de interacţiuni şi dependenţe între
aceste activităţi. Fiecare activitate este reprezentată de o linie proporţională cu durata ei. Odată ce au
fost listate toate activităţile şi reprezentate duratele lor prin linii proporţionale se poate vedea durata
totală a proiectului sau a unei faze a acestuia.
 O limitare importantă a acestor diagrame constă în dificultatea de a aloca resurse activităţilor cu
menţinerea interdependentelor şi fără supraîncarcarea personalului.
Atunci când proiectele sunt foarte mari şi necesită replanificări de operatii, se reprezintă doar
activităţile de înalt nivel şi separat se fac diagrame pentru descompunerea fiecarei activităţi de nivel
inalt.
În figura 2.14 se prezintă graful Gantt pentru un proiect de realizare a unui sistem informatic.
Datorită numărului mare de activităţi şi a dependenţelor dintre acestea, s-a recurs numai la
reprezentarea activităţilor de înalt nivel.
Proiectarea sistemelor informatice
2005Iulie 2005August 2005Septembrie
2005Mai 2005Iunie
2005Aprilie
 prelucrărilor3. Modelarea datelor şi
Nume activitate

5. Proiectarea fizică
4. Proiectarea logică

6. Implementarea

7. Livrarea sistemului
1. Investigarea activităţilor

2. Determinarea cerinţelor

Fig. 2.14 Graful Gantt

Analize tip reţea
Aceste metode de planificare a timpului permit punerea în evidenţă a interdependenţelor dintre
diferitele operaţii în cadrul proiectelor complexe.
Cele mai cunoscute metode sunt:
B1 – analiza drumului critic (DC);
B2 – programul de evaluare şi revizuire tehnică (PERT – Programme Evaluation and Review
Tehnique, în limba engleza).
Utilizarea lor pe scară largă a apărut în anii ’50, la acea vreme fiind utilizate cu succes în
proiectele de apărare ale forţelor armate ale S.U.A.
În general, pentru realizarea acestor reţele se folosesc două grupe de sisteme de notare şi
reprezentare.
 Sistemul activitatilor notate pe săgeţi (Figura2.15). Sistemul se foloseste pentru ambele
metode (DC şi PERT).

activitate
1 2

Figura 2.15 Sistemul activităţilor notate pe săgeţi

1 şi 2 sunt două evenimente din cadrul proiectului

Pe săgeată se trece activitatea(operaţia) necesară a se derula pentru a trece de la evenimentul 1
la 2.

 Sistemul activităţilor notate în noduri. În continuare, pentru exemplificare, vom folosi

primul sistem de reprezentare.
B1. Analiza drumului critic (DC)
Constă din realizarea unei diagrame tip reţea.
Deosebiri faţă de diagramele tip bară:
nu sunt proiectate pentru a oferi orizontul de timp;
doresc să ofere informaţii clare asupra relaţiei şi interdependenţei fiecărei activităţi cu
celelalte activităţi ale proiectului.
Figura 2.16 prezintă cea mai simplă diagramă tip reţea. Fiecare cerc reprezintă un eveniment în
cadrul proiectului. Săgeata care leagă evenimentele 4 şi 5 reprezintă activitatea care trebuie să aibă loc
înainte ca evenimentul 5 să se declare ca fiind realizat.

2 4 5

Figura 2.16 Diagrama tip retea

Diagrama din figura 2.16 arată, de asemenea, că activitatea ce conduce la evenimentul 5 nu

poate începe până ce toate activităţile ce preced evenimentul 4 nu au fost realizate. Deasupra săgeţilor
se poate scrie şi durata activităţii respective.
În figura 2.17 se prezintă activităţile şi evenimentele unui proiect mai complex. În acest
exemplu există mai multe posibilităţi de realizare a proiectului (evenimentul 6), fapt uzual în
majoritatea proiectelor.
Avem trei căi posibile de realizare a proiectului, unele dintre ele trecând printr-o “activitate
fictivă”, 4 → 3. Activităţile fictive nu reprezintă o operaţie efectivă şi au întotdeauna durata 0. Ele
reprezintă o restricţie sau o linie de dependenţă dintre diferite activităţi.

1 5
1 2
2 3
1 3 5 4
0 9
1 6

0 5 2 9
5 6
4 5
 5 7
Figura 2.17 Drumul critic

În exemplul nostru, începutul activităţii 3 → 6 depinde atât de realizarea activităţii 2 → 3, cât şi

de realizarea activităţii 1 → 4. Altfel spus, activitatea 3 → 6 nu poate începe până nu au avut loc
evenimentele 3 şi 4.
Deasupra săgeţilor reprezentând activităţile, s-au trecut şi duratele lor de realizare, estimate în
zile. Durata proiectului reprezintă suma duratelor activităţilor pentru fiecare din cele trei drumuri
posibile şi depinde de drumul ales. Evenimentul 3 poate avea loc cel mai devreme după 3 zile (1+2=3),
dacă se consideră drumul 1 → 2 → 3. Dar încheierea evenimentului 3 nu poate avea loc înainte de ziua
a 5-a datorită drumului mai lung ce trece şi prin activitatea fictivă 4 → 3. Prin însumarea, de la stânga la
dreapta, a duratelor activităţilor precedente, pe drumul cel mai lung, se determină durata minimă de
realizare a fiecărui eveniment (notată deasupra fiecărui cerc reprezentând un eveniment). Urmând
această procedură în reţeaua noastra, rezultă că durata minimă de realizare a proiectului este de 9 zile.
Să considerăm drumul ce trece prin evenimentul 5. Durata cea mai scurtă de realizare a lui este
ziua a 6-a, cu trei zile înainte de cea mai scurtă durată de încheiere a proiectului. Este evident că
începutul activităţii 5 → 6 se poate amâna cu o zi, ea durând două zile, fără a se mări durata de realizare
a proiectului. Rezultă că realizarea evenimentului 5 poate avea loc cel mai devreme în ziua a 6-a şi cel
mai târziu în ziua a 7-a. Acest lucru este indicat în figura 2.17 prin scrierea sub cercul evenimentului a
datei celei mai târzii de realizare a sa. Acest rezultat se poate obţine şi prin scăderea perioadelor de
realizare a evenimentelor pornind de la dreapta spre stânga.
Concluzia este că, pornind de la dreapta spre stânga în reţeaua noastră de evenimente şi
activităţi, putem obţine cel mai târziu moment la care trebuie realizate diferite evenimente.
Pentru activitatea care ne conduce de la evenimentul 5 la 6 avem:
durata: 2 zile;
cea mai devreme dată pentru începere: ziua a 6-a;
cel mai devreme posibil sfârşit: ziua a 8-a (6+2);
cel mai târziu posibil sfârşit: ziua a 9-a;
marja de timp posibilă: 1 zi.
În momentul în care pe diagramă au fost indicate duratele cele mai mici şi cele mai mari pentru
realizarea unui eveniment, se poate găsi cel puţin un lanţ de evenimente pentru care durata de realizare
cea mai scurtă corespunde cu durata de realizare cea mai lungă a proiectului. Acest drum cu marja de
timp zero, legând aceste evenimente, se numeşte drum critic şi este reprezentat cu săgeţi îngroşate în
figura 2.17.
 Evenimentele prin care trece drumul critic se numesc evenimente critice. Chiar dacă toate
activităţile sunt importante, activităţilor critice trebuie să li se acorde prioritate în ceea ce priveşte
alocarea resurselor şi atenţia managerilor.
B2. Metoda PERT
Metoda PERT este similară metodei DC. Reţeaua de evenimente şi activităţi se construieşte
identic. Diferenţa apare atunci când se ia în considerare factorul timp.
Metoda PERT ia în considerare trei durate pentru fiecare activitate:
durata optimistă;
durata cea mai probabilă;
durata pesimistă.
Cu ajutorul acestora se determină o valoare aşteptată pentru durata de realizare a fiecarei
activităţi.
Metoda PERT oferă o durată de realizare a proiectului şi o probabilitate de atingere a acestuia.
Planificarea resurselor
Analizele utilizate pentru planificarea timpului nu pot pune în evidenţă şi volumul resurselor
necesare la un moment dat pentru derularea proiectului.
În general există şase categorii de resurse care trebuie evaluate şi planificate de către managerul
de proiect, şi anume:
resursele umane;
echipamentele şi materialele;
serviciile;
transportul;
instalaţiile necesare pentru realizarea proiectului;
resursele financiare.
Unele proiecte pot necesita numai o parte din aceste resurse, altele pot necesita toate cele şase
categorii de resurse ş.a.m.d.
Resursele umane, echipamentele şi materialele sunt de mare importanţă pentru performanţele
oricui proiect.
3. Planificarea resurselor umane
Din acest punct de vedere, sunt de interes aspectele referitoare la categoria, numărul şi
organizarea oamenilor, elaboreaza grafice de personal (figura 2.18). În aceste grafice se reprezintă
necesarul de personal în funcţie de timp, pentru o anumită activitate.

Numar de
persoane

Figura 2.18 Grafice teoretice de personal

 Numar mediu
de persoane

Timp

Graficul, de exemplu de formă trapezoidală în mod teoretic, se poate realiza estimând necesarul
de personal pentru fiecare zi şi aşa mai departe, pâna la sfârşitul activităţii respective. Prin împărţirea
numărului total de ore necesare pentru lucru la durata lucrătoare, se poate obţine numărul mediu de
persoane. În practică, graficele de personal pot avea alura unui clopot, a unei curbe în forma literei “s”
etc., în funcţie de categoria de personal avută în vedere.
O metodă convenabilă de extindere a personalului necesar pentru un proiect este consultarea
unor subcontractanţi sau consultanţi. Această soluţie este deseori folosită în practică. Se mai utilizează
soluţia de a angaja persoane numai pentru acel proiect.
a) Planificarea resurselor materiale
Elementul de bază al acestei planificări este planul de achiziţii al proiectului. Printre datele
esenţiale pentru elaborarea acestui plan amintim: sondaje asupra situaţiei pieţei, trenduri privind
preţurile, disponibilitatea materialelor.
Planificarea serviciilor şi a unor sisteme de control (al derulării în timp a costurilor proiectului
etc.) este indispensabilă în cazul achiziţiei de calculatoare şi a softului necesar. Serviciile pot implica
pregătirea spaţiilor unde va lucra echipa de proiectare sau instalaţiile necesare pentru amplasamentul
proiectului.
b) Planificarea resurselor financiare
Managerul de proiect are autoritatea de a aproba toate cheltuielile necesare pentru realizarea
proiectului. Planificarea greşită a resurselor financiare poate stopa execuţia noului sistem informatic.
Planificarea riguroasă şi profundă a resurselor constituie baza a tot ceea ce urmează în derularea
unui proiect. Managerul de proiect trebuie să se pregătească asiduu pentru a putea planifica toate
aspectele proiectului şi activităţile de zi cu zi aferente.

Controlul proiectelor
Prin controlul proiectelor trebuie să se urmărească progresele realizate în dezvoltarea
proiectelor, în raport de obiectivele stabilite. Trebuie să ne asigurăm că proiectul va fi finalizat la data
prevăzută în contract, că se încadrează în bugetul specificat şi că furnizează ce s-a stabilit, la o calitate
ridicată.
Controlul constă din două părţi:
 urmărirea;
luarea măsurilor.
Urmărirea proiectelor
Este cunoscut faptul că niciodată lucrurile nu evoluează aşa cum sunt planificate.
Factorii care produc modificări în derularea proiectelor pot fi următorii:
estimările făcute la planificarea proiectului pot fi greşite;
cerinţele se pot schimba;
termenul final se poate schimba (de obicei, mutându-se mai devreme);
bugetul se poate micşora;
prioritatea proiectului se poate schimba;
rezistenţa la schimbări;
greşelile oamenilor.
Gradul de complexitate a proiectelor sunt factori care determină metoda de control şi raportare.
Din acest punct de vedere distingem mai multe situaţii posibile: proiecte simple, proiecte de
dimensiune medie şi proiecte complexe.

ANALIZA SISTEMULUI INFORMAŢIONAL

Complexitatea şi multitudinea sistemelor informatice impune efectuarea unor analize prin care
se determina principalele disfunctionalitati informationale şi consecintele lor manageriale, economice
şi umane.
Concomitent se evidentiaza şi aspectele pozitive ale sistemului informational curent şi se
evalueaza problemele pe care trebuie sa le rezolve viitorul sistem. În analiza sistemului informational
trebuie sa regasim aspectele:
- aria de intinderea a sistemului informational care va deveni sistemul obiect pentru conceperea
şi realizarea unui sistem informatic.
- reflectarea activitatilor şi operatiilor economice specifice sistemului informational
- surprinderea modificarilor ce se impun în organizarea şi functionarea unui sistem informatic.
- fundamentarea unei solutii de principiu care sa precizeze activitatea şi operatiile ce urmeaza a
fi informatizate, costul antecalculat al sistemului.
Etapa de analiza cuprinde 3 tipuri de activitate:
- identificarea problemelor de solutionat şi determinarea cerinţelor sistemului.
- Structurarea cerinţelor (modelarea proceselor şi modelarea conceptuala a datelor)
- Generarea şi alegerea variantelor de proiectare.
 3.1 IDENTIFICAREA PROBLEMELOR DE SOLUTIONAT ŞI
DETERMINAREA CERINŢELOR

E faza de debut a analizei de ale carei rezultate depinde calculul şi functionalitatea sistemului.
Analiza isi incepe activitatea prin culegerea şi inregistrarea de date şi informatii referitoare la
componentele sistemului informational.
La analiza şi interpretarea acestora au în vedere ca fiecare din componentele sistemului
informational au anumite caracteristici:
- date:
a) forma de reprezentare letrica sau cifrica
b) natura domeniului la care se refera (fenomene, procese, rezultate,actiuni)
- informatiile sunt valoroase şi utile cand li se cunoaste:
a) provenienta
b) destinatia
c) frecventa de generare şi utilizare
d) directia vehicularii
e) gradul de prelucrare
f) natura proceselor reflectate
- circuitele informationale sunt conditionate de:
a) scopul informatie (documentare în vederea fundamentarii unei decizii, avertizari asupra
modificarii unei anumite stari, sau sunt date istorice).
b) pozitia în structura şi natura relatiilor dintre factorii emitatori şi receptori (ascendente sau
descendente, relatii functionale sau relatii de reprezentare).
c) viteza de prelucrare a informatiilor şi capacitatea canalelor de comunicatie (echipamente de
prelucrare, resurse umane).
d) structura organizatorica a sistemului de conducere.
- fluxul informational caracterizat prin configuratia şi lungimea traseului informational, prin
viteza de deplasare a informatiilor, prin volumul informational, calitate, diabilitate, cost.
- proceduri informationale tratate prin aspectele:
a) suportii tehnici utilizati
b) succesiunea operatiilor tratate
c) metode şi procedee de culegere, inregistrare, transmitere şi prelucrare a informtiei.
d) complexitatea operatiilor impicate
e) formalizarea atributelor.
- mijloacele de tratare a informatiilor abordate ca sistem tehnic al sistemului informational sunt
caracterizate prin:
a) costuri
b) tipuri sau categorii
c) performante tehnico-functionale
d) numarul
e) structura

Determinarea cerinţelor sistemului

Determinarea cerinţelor sistemului este o activitate esenţială în aflarea situaţiei existente şi a

ceea ce se doreşte în viitor. Culegerea informaţiilor este posibilă prin metode tradiţionale sau moderne.
Metodele tradiţionale de colectare a cerinţelor sistemului sunt :
o interviuri individuale
 o anchete realizate prin chestionare
o intervievarea grupurilor de oameni cu interese comune
o observarea personalului in momente bine definite pentru a vedea modul in care sunt
folosite informaţiile pentru exercitarea sarcinilor de serviciu
o studierea documentaţiei firmei pentru a se cunoaşte conţinutul rapoartelor, al politicilor
spre care se îndreaptă prelucrarea datelor
Metodele moderne mai des utilizate sunt:
 sesiunile JAD (Joint Application Design)
 sistemele de sprijinire a grupurilor de lucru
 prototipizarea
 RAD (Rapid Application Development)

Intervievarea
Interviul este procesul comunicării directe de stabilire a unei relaţii cu o finalitate
precisa, predeterminata, proces conceput pe alternanta rolurilor si care implica formulări de întrebări si
obţinerea de răspunsuri.
Cuvântul proces semnifica dinamism, interacţiune continua cu multe variabile de lucru,
cu acţiune înlănţuita, după un anumit sistem de derulare.
Cuvântul diadic, pornind de la diada, scoate in relief faptul ca interviul este o
interacţiune persoană-cu-persoană intre doua părţi sau doua componente, evitându-se astfel faptul ca la
interviu pot participa mai multe persoane, dar niciodată mai mult de doua părţi : cea care ia interviul si
cea intervievata.
Cuvântul relaţii sugerează o legătura interpersonală intre părţile interviului.
Finalitate, precisă predeterminata înseamnă că cel puţin o persoană vine de la interviu cu
un anumit scop si vrea să abordeze un anumit subiect.
Alternanţa rolurilor are conotaţia împărtăşirii gândurilor, a simţămintelor şi informaţiilor
printr-o schimbare continuă a rolurilor.
Dacă numai una dintre părţi vorbeşte si cealaltă ascultă se poate vorbi despre un discurs
(speech), si nu despre interviu. Se considera ca aproximativ 70% din timpul total al interviului aparţine
intervievatului si 30% celui ce ia interviul(anchetator). Sunt si tipuri de interviuri in care se pot inversa
rolurile, cum ar fi cazul interviurilor pentru oferirea de informaţii sau promovarea unei vânzări.
Formularea de întrebări şi obţinerea răspunsurilor constituie procesele esenţiale ale
interviului. Puţine sunt interviurile care sa nu necesite o structurare prealabila a întrebărilor.

Chestionarele
Spre deosebire de interviuri, chestionarele sunt mai puţin costisitoare şi intr-un timp relativ
scurt, pot oferi un volum mare de informaţii necesare analizei sistemului.
Deoarece conceperea chestionarului este mai mult o arta decât o ştiinţă, specialiştii s-au străduit
sa-si prezinte experienţa sub forma unor reguli, recomandate îndeosebi începătorilor, cei cu state vechi
le pot utiliza drept elemente de comparaţie pentru a-si evalua paşii întregii proceduri. Din aceste motive
se considera de bun augur descrierea paşilor parcurşi pentru conceperea unui chestionar :
- pasul 1 : Ce informaţii vor fi căutate ?
În primul pas al chestionarului se stabilesc informaţiile care trebuie sa fie obţinute, operaţie
declanşată în faza embrionară a cercetării de întreprins. Neglijenţa manifestata în această etapă va
conduce la obţinerea unor informaţii nerelevante.
- pasul 2 : Stabilirea tipului de chestionar şi a metodei de administrare
 După identificarea informaţiilor de căutat, cel ce concepe chestionarul trebuie să specifice
modul în care le va obţine. Decizia se va referi la structura si modul de formulare a întrebării, după care
se va pune problema administrării chestionarului. : prin poştă, telefonic sau cu operator(o persoană
special desemnată pentru această operaţiune).
- pasul 3 : Determinarea conţinutului fiecărei întrebări
- pasul 4 : Stabilirea modului de redactare a răspunsului pentru fiecare întrebare
Dacă se merge pe o varianta fixă, proiectantul trebuie să decidă dacă va folosi întrebări închise
sau dacă va merge pe varianta opţiuni multiple, două opţiuni sau a scalei de valori.
- pasul 5 : Formularea întrebărilor
De modul în care sunt formulate întrebările, practic depinde succesul chestionarului.
- pasul 6 : Stabilirea secvenţei întrebărilor
- pasul 7: Validarea caracteristicilor tehnice ale chestionarului
- pasul 8 : Reevaluarea paşilor 1-7 şi revizuirea lor (dacă este cazul).
- Pasul 9 : Efectuarea pretestului şi revizuirea finală (dacă este cazul).
De regulă, chestionarele sunt administrate pe hârtie, dar ele pot fi efectuate cu sau fără operator
uman, direct, prin telefon, sau chiar pe dischetă, sau prin intermediul serviciilor oferite de calculatoare.
Chestionarele, în cea mai mare parte, se bazează pe întrebări cu schemă fixă de răspuns, iar
atunci când conţin întrebări cu o formulare vagă au ca scop aflarea părerilor celor chestionaţi, pentru a
putea fi surprinse cât mau multe cazuri

Eşantionarea
Întrucât colectivităţile depăşesc întotdeauna numărul celor ce sunt chestionaţi, o problema
esenţială o constituie stabilirea eşantionului chestionat. De regula, se folosesc următoarele 4 metode
sau combinaţii ale lor :
1. cei adecvaţi eşantionului : ei pot fi oameni care îşi desfăşoară activitatea intr-un anumit
loc, cei care sunt motivaţi sa dea răspunsuri sau cei care vor sa dea răspunsuri sau cei care
vor sa fie intervievaţi.
2. un grup aleator :daca exista o lista a utilizatorilor unui sistem simplu, se selectează fiecare
a n-a persoana, in care n este o raţie de selecţie. O alta modalitate consta in selecţia
persoanelor pe baza ordonării lor după a 2-a, a 3-a litera a numelui sau a prenumelui sau
prin generarea aleatoare a numerelor cu ajutorul calculatorului.
3. un eşantion precizat: pot fi numai persoanele care îndeplinesc anumite criterii.
4. un eşantion stratificat: daca sunt mai multe categorii de persoane, din fiecare, după criterii
aleatoare, vor fi selectaţi cei eşantionaţi. De exemplu: dintre utilizatori, conducători,
informaticieni.

Observarea directă a utilizatorilor

Nu întotdeauna consultarea persoanelor conduce la obţinerea celor mai bune rezultate, chiar si
atunci când acestea afirma ca oferă cele mai sigure informaţii sau au impresia ca deţin adevărul absolut
asupra sistemului analizat. Părerile sunt subiective.
 Desfăşurarea operaţiunii de observare directa depinde si de acceptul sau bunele intenţii ale
organizaţiei supuse analizei. Uneori, chiar daca exista un astfel de accept, prezenta analiştilor printre
angajaţi ii determina pe aceştia din urma sa manifeste un comportament anormal, cu scopul de a crea o
anumita impresie. Astfel pot fi emoţionaţi, stresaţi, se pot forţa sa efectueze lucrările mai repede, sa
simuleze ocuparea completa a timpului de munca. Alteori, daca au un alt obiectiv ei pot lucra mai încet,
pot bruia noul sistem s.a.
Aşadar, observarea presupune pentru analişti selecţia unei palete foarte largi de probleme.

Analiza procedurilor de lucru si a altor documente

Documentele ce pot fi studiate sunt de o mare diversitate. Dintre documentele mai des solicitate
fac parte : declararea misiunii si strategiei organizaţiei, cunoaşterea obiectivelor acesteia, a planurilor
de afaceri, a studiilor de fezabilitate, a structurii organizatorice (organigrama), a regulamentelor de
organizare si funcţionare, a celor de ordine interioara, a normelor interne de fabricaţie, a standardelor
folosite, a fiselor posturilor, a corespondentei interne si externe, a rapoartelor de analiza rezultate din
studii anterioare s.a.
Un prim tip de documente se refera la procedurile de lucru pentru activităţile individuale sau
ale grupurilor. Prin ele se descrie modul in care se exercita o anumita activitate, prezentându-se si
datele si/sau informaţiile pe care le solicita sau le generează.
Un al doilea tip de documente ce este studiat de analiştii de sistem îl constituie formularele
utilizate de către unitate pentru toate tranzacţiile interne si externe care au loc.
Al treilea tip îl constituie rapoartele generate de sistemul actual.
Al patrulea tip se regăseşte numai in sistemele de prelucrare automata a datelor si se refera la
documentaţia folosită in sistemul informatic.
Ca efect al tendinţelor de mărire a timpului de analiză a sistemelor existente, în ultimii ani s-a
efectuat trecerea spre tehnicile moderne, unele dintre ele care preiau din ce în ce mai puţine elemente
ale sistemelor existente.
Sesiunile JAD pun laolaltă toate forţele interesate în dezvoltarea sistemelor: utilizatorii cheie,
managerii şi analiştii de sistem implicaţi în analiza sistemului curent. Din acest punct de vedere JAD
este similar interviului la nivel de grup. Totuşi, în sesiunile JAD ce urmează o anumită secvenţă de
derulare a activităţilor pe baza unor roluri bine definite.
Prototipizarea este un proces iterativ prin care analiştii şi utilizatorii pun în discuţie o versiune
rudimentară a unui sistem informaţional, care va fi într-o continuă schimbare, în funcţie de reacţia
utilizatorului. Prototipul este văzut şi testat de utilizator, având posibilitatea să precizeze ce ar mai dori,
dar şi să-şi genereze această formă nouă, firesc, cu ajutorul specialiştilor din preajmă.
RAD este o metodologie de realizare a sistemelor informaţionale care promite sisteme mai
bune, mai ieftine şi realizate mai rapid. O primă explicaţie constă în celor mai buni proiectanţi de
sisteme şi a celor mai reprezentativi utilizatori , care, împreună, în timp real, lucrează la realizarea
sistemului.
Diferenţa majoră a RAD faţă de JAD constă în faptul că prototipul devine elementul
fundamental al noului sistem - ecranele afişate în timpul prototipitării devin ecrane ale sistemului, şi
nu modele ale unui posibil sistem.
Plecând de la aceste obiective, suportul hardware şi software al noului sistem informatic trebuie
să îndeplinească următoarele cerinţe:
 Asigurarea suportului informaţional prin crearea şi întreţinerea unei baze de date sigure şi
complete:

- crearea şi actualizarea în timp real a imaginii procesului în memoria internă şi accesul

transparent pentru utilizatori şi aplicaţii la această imagine;
- crearea şi actualizarea în timp real a bazei de date cu evoluţia în timp a procesului precum
şi accesul distribuit la datele înregistrate;
- completarea în timp real a bazei de date cu evenimentele din sistem şi accesul distribuit la
informaţii;
- arhivarea şi întreţinerea arhivelor cu istoricul procesului şi evenimentelor precum şi accesul
distribuit la datele din arhivă.

Asigurarea unui flux informaţional coerent:

- circulaţia selectivă a informaţiilor existente în imaginea internă a procesului către utilizatori,
în funcţie de specificul activităţilor;
- gestiunea automată a fluxului de date pe orizontală şi pe verticală(în interiorul şi între
nivelele ierarhice) în vederea întreţinerii bazelor de date;
- gestiunea dinamică a înregistrărilor în baza de date ţinând cont de durata de viaţa impusă
pentru acestea.

Prezentarea informaţiilor către utilizatori

Prin intermediul staţiilor de lucru, utilizatorul poate avea acces la informaţiile din sistem în
concordanţă cu sarcinile pe care acesta la are în ierarhia de funcţii. Accesul la sistem se face
numai prin identificarea utilizatorului după nume şi parola de protecţie, numai pentru funcţiile
specifice postului său.

Comunicarea transparentă pentru utilizatori între echipamentele din sistem

Suportul de comunicaţie trebuie astfel conceput încât pentru orice utilizator echipamentele
interconectate să fie văzute ca un singur calculator „uriaş”.

Integrarea cu alte aplicaţii existente sistemului informaţional

Utilizarea unor legături de comunicaţie dedicate, pentru activităţile de conducere operativă.
Accesul la informaţii, utilizând serviciile intranet.

Disponibilitatea şi funcţionarea degradată în cazul căderii unor componente şi siguranţa

păstrării informaţiilor
- Posibilitatea de intervenţie pentru întreţinere sau depanare asupra unor componente ale
sistemului fără afectarea funcţionării de ansamblu.
- Funcţionarea în regim de rezervare activă a componentelor vitale ale sistemului: canale de
comunicaţie dublate, servere de baze de date cu mai multe procesoare şi memorii externe RAID.
- Replicarea componentelor vitale ale bazei de date în locaţii diferite, pentru a evita pierderea
datelor în caz de defect.
-Accesul la funcţiile specifice de la orice staţie de lucru în cazul indisponibbilităţii celor
destinate implicit pentru funcţiile respective.

Configurabilitatea şi posibilitatea de extindere

 Abordarea realizării sistemului în etape succesive impune existenţa unor funcţii de bază care să
permită:
Extinderea sistemului prin adăugarea de noi componente fizice şi logice.
Modificarea interactivă a bazelor de date care descriu componentele logice din sistem
Adăugarea de noi aplicaţii care au acces la informaţiile din sistem.

3.2 STRUCTURAREA CERINŢELOR SISTEMULUI

Structurarea cerinţelor sistemului e etapa cea mai complexa din cadrul analizei şi se
structureaza pe 2 activitati:
- modelarea proceselor;
- modelarea datelor.

Sisteme – subsisteme
informationale/proceduri
informationale

Documentare şi analiza

Informatii Proceduri şi
şi legile reguli de
dintre ele gestiune

Modelare

Modelul conceptual Modelul conceptual

al datelor al prelucrarilor

Etapa de analiza pentru structurarea cerinţelor sistemului e o etapa de modelare conceptuala şi

se poate realiza sub trei aspecte:
 - structural
- dinamic
- functional

1.Analiza de sistem
Scopul acestei activităţi este de a evidenţia cerinţele aplicaţiei şi resursele utilizate (studiul),
precum şi de a evalua aceste cerinţe prin modelare (analiza).
STUDIUL situaţiei existente se realizează prin:
- definirea caracteristicilor generale ale unităţii;
- identificarea activităţilor desfăşurate;
- identificarea resurselor existente (informaţionale, umane, energetice, echipamente,
financiare etc.)â
- identificarea necesităţilor de prelucrare.
ANALIZA sistemului existent urmează investigării (studiului) şi utilizează informaţiile obţinute
de aceasta.

aliza este o activitate de modelare (conceptuală) şi se poate realiza sub trei aspecte: structural,
dinamic şi funcţional.
a) Analiza structurală evidenţiază, la nivel conceptual, modul de structurare a datelor şi a
legăturilor dintre ele. Cea mai utilizată tehnică este entitate-asociere.
Aceasta conţine:
1) Identificarea entităţilor: fenomene, procese, obiecte concrete sau abstracte (substantivele din
prezentarea activităţii descrise) (exemple de entităţi: Persoane, Produse, Beneficiari).
2) Identificarea asocierilor dintre entităţi ca fiind legăturile semnificative de un anumit tip
(verbele din prezentarea activităţii descrise).
3) Identificarea atributelor ce caracterizează fiecare entitate în parte (exemple de atribute:
Marca, Nume, Adresă).
4) Stabilirea atributelor de identificare unică a realizărilor entităţii, drept chei.
Rezultatul analizei structurale este modelul static (structural), numit şi diagramă entitate-
asociere.
b) Analiza dinamică evidenţiază comportamentul elementelor sistemului la anumite
evenimente. Una dintre tehnicile utilizate este diagrama stare-tranziţie.
Aceasta presupune:
1) Identificarea stărilor în care se pot afla componentele sistemului.
2) Identificarea evenimentelor care determină trecerea unei componente dintr-o stare în alta.
3) Stabilirea tranziţiilor admise între stări
4) Construirea diagramei stare-tranziţie
Rezultatul analizei dinamice: modelul dinamic
c) Analiza funcţională evidenţiază modul de asigurare a cerinţelor informaţionale (fluxul
prelucrărilor) din cadrul sistemului, prin care intrările sunt transformate în ieşiri. Cea mai
utilizată tehnică este diagrama de flux a datelor.
Conform acestei tehnici se delimitează:
1) Aria de cuprindere a sistemului.
2) Se identifică sursele de date.
3) Se identifică modul de circulaţie şi prelucrare a datelor.
4) Se identifică apoi rezultatele obţinute.
Rezultatul analizei funcţionale: modelul funcţional.
 Urmare a operaţiunii de culegere a cerinţelor sistemului este activitatea de structurare a
cerinţelor prin metode specifice: modelarea proceselor, modelarea logicii proceselor şi modelarea
conceptuală a datelor.
Indiferent de metodologiile folosite în realizarea unui sistem, toate apelează la operaţiunea de
modelare logică a datelor şi prelucrărilor sub formă de diagrame.
Există mai multe tipuri de diagrame, utilizabile în diverse etape ale ciclului de viaţă al
sistemului sau pentru anumite activităţi. În practică, cele mai multe produse apelează la două tehnici de
redare a diagramelor fluxurilor de date: Gane & Sarson şi Yourdon & DeMarco.
Prin analiza diagramelor fluxurilor de date se pot reliefa următoarele aspecte:
- fluxuri de date redundante, apărute, de regulă, prin apelarea la nume diferite pentru acelaşi tip
de date;
- date care intră în prelucrări dar nu sunt folosite;
- datele ce sunt actualizate identic în mai multe locuri.
Modelarea datelor prin DER prezintă caracteristicile şi structura datelor independent de modul
în care acestea sunt memorate în calculator. Modelul se creează iterativ. De cele mai multe ori,
operaţiunea are loc la nivel de organizaţie, prin apelarea la o categorie foarte largă de date, neglijându-
se detaliile exagerate. Doar în etapele următoare când se trece la definirea proiectului, are loc
construirea unui model entitate-relaţie, prin care să se scoată în evidenţă aria de întindere a proiectului.
În timpul structurării cerinţelor, un model entitate-relaţie reprezintă cerinţele conceptuale da
date pentru sistemul luat în discuţie. După ce sunt descrise complet intrările şi ieşirile sistemului în
cadrul proiectării logice, modelul conceptual al datelor, redat sub forma entitate-relaţie, este rafinat
înainte de a fi trecut într-un format logic (de regulă, un model relaţional al datelor) din care se definesc
bazele de date şi are loc proiectarea fizică a acestora.
Diagrama entitate-relaţie, după cum reiese şi din denumirea numelui diagramei, evidenţiază
entităţile da date (obiectele despre care se solicită păstrarea datelor) şi relaţiile ce există între ele.
Întotdeauna crearea unei DER presupune găsirea răspunsului la întrebarea: „Care sunt entităţile
despre care sunt necesare datele de stocat?” Răspunsul este destul de simplu. Depinde de aria de
extindere a sistemului analizat.
După ce se identifică entităţile, se continuă cu împerecherea lor, fiecare cu fiecare pentru a
descrie ce relaţii există între ele.
Definirea conceptului de entitate

De regulă, entităţile sunt obiecte sau evenimente (fenomene sau procese ). Obiectele se
caracterizează printr-o existenţa de-a lungul timpului, iar evenimentele îşi fac simţită prezenţa la un
moment dat.
Trebuie însă făcută distincţia între tipurile entităţilor şi cazurile/instanţele entităţii.
Tipul entităţii, cunoscut şi sub numele de clasa entităţii, este o colecţie de entităţi care au
proprietăţi sau caracteristici comune. Fiecărui tip de entitate i se asociază un nume. Cât timp numele
reprezintă o clasă sau un set de cazuri, el este singular. Şi încă o convenţie. Cum referirea generală la
elementele ce pot fi catalogate ca entităţi se face prin noţiunea de obiect, referirea la acesta se va realiza
printr-un substantiv la singular. Se vor folosi majuscule plasate în interiorul dreptunghiului
corespunzător entităţii.
O instanţiere a entităţii sau instanţă, este o manifestare singulară a unui tip de entitate. Un tip
de entitate ce descrie o singură dată prin modelul datelor, în timp ce mai multe cazuri ale acelui tip de
entitate pot fi reprezentate prin datele stocate în bazele de date.

Atribute
 Un atribut se defineşte ca fiind o proprietate a unei entităţi sau a unei corespondenţe,
caracterizată printr-un nume şi un tip. Fiecare atribut care a fost selecţionat la definirea conţinutului
unei entităţi este o caracteristică semnificativă pentru domeniul studiat.
Ca şi numele tipurilor entităţilor, numele atributelor sunt substantive scrise cu majuscule,
plasate în interiorul elipselor, legate de entitatea căreia i se asociază.

ATRIBUT21 ATRIBUT31

ATRIBUT11 ENTITATE ATRIBUT4

Cheie candidat şi cheie primară

Fiecare tip de entitate trebuie să aibă un atribut sau un set de atribute prin care să se efectueze
diferenţierea unui caz de acelaşi tip.
O cheie candidat este un atribut sau o combinaţie de atribute prin care se poate identifica în
mod unic un caz(o instanţă) al tipului entităţii respective.
Sunt entităţi care pot avea două sau mai multe chei-candidat. Atunci când sunt mai multe chei-
candidat, proiectantul trebuie să decidă care din el va fi folosită drept cheie-primară.
O cheie-primară este o cheie candidat care a fost selectată pentru a servi ca identificator de
cazuri în cadrul unui tip de entitate.
Selecţia cheii-primare trebuie să se efectueze după mai multe proceduri:
 Se alege o cheie-candidat care să nu-şi schimbe propria valoare în timpul vieţii cazului/instanţei
entităţii respective.
 Se alege acea cheie-candidat care, pentru fiecare caz /instanţă al/a entităţii, garantează faptul că
atributul sau grupul de atribute are o valoare corectă şi nu este nulă.
 Se vor evita aşa-zisele chei-secrete, care preiau în structura lor părţi ale unor atribute care
semnifică clasificări, locuri, coduri ş.a., întrucât ele se pot schimba uşor şi des.
 Se vor prefera formele scurte în locul celor complexe, formate din mai multe atribute, dacă este
posibil.
În reprezentările din DER, în elipsa sau elipsele aferente atributului sau atributelor ce formează
cheia primară, numele respectiv se subliniază.
Relaţiile entităţilor

Relaţiile reprezintă liantul între componentele unei diagrame entitate-relaţie.

O relaţie este o asociere între cazurile/instanţele uneia sau mai multor tipuri de entităţi care
prezintă interes pentru organizaţie. Ele se pot simboliza printr-un romb. De regulă, relaţiile sunt redate
prin verbe.
Între entităţi, luate două câte două, se pot generaliza trei tipuri de relaţii: unu-la-unu(1:1), unu-
la-multe(1:m) si multe-la-multe (m:m).
Ansamblul datelor de legătură dintre fişiere se determină pe baza asocierilor pe care le impun
grupărilor de date prezentate în liste şi algoritmul de calcul.
Nu toate datele comune mai multor fişiere pot servi drept date de legătură, pentru ca o dată
comună mai multor fişiere să fie dată de legătură, este necesar ca ea să îndeplinească rolul de
identificare pentru cel puţin unul din fişiere.

3.3 ANALIZA DEFICIENŢELOR INFORMAŢIONALE MAJORE

 Studiile efectuate asupra sistemelor informaţionale din cadrul firmelor au reliefat existenţa unor
deficienţe tipice, relativ frecvente, reflectare a unor erori în conceperea şi implementarea lor, a căror
cunoaştere şi preîntâmpinare este esenţială.

Distorsiunea – prima dintre deficienţele tipice, constă în modificarea parţială neintenţionată a

conţinutului, a mesajului unei informaţii pe parcursul culegerii, prelucrării şi transmiterii de la emiţător
la receptor. Dintre cauzele multiple care generează distorsiunea menţionăm ca foarte frecvente:
diferenţele în pregătirea persoanelor implicate în vehicularea informaţiei, folosirea de suporţi
informaţionali necorespunzători pentru înregistrarea informaţiilor, manipularea neglijentă a suporţilor
de informaţii în procesul transmiterii lor beneficiarilor, utilizarea de mijloace necorespunzătoare pentru
înregistrarea şi transmiterea informaţiilor etc.

Filtrajul, a doua deficienţă informaţională majoră, se deosebeşte de distorsiune prin aceea că

modificarea parţială sau totală a mesajului sau conţinutului informaţiilor are loc în mod intenţionat.
Cauza filtrajului este una singură: intervenţia pe parcursul înregistrării, transmiterii şi prelucrării
informaţiilor a unor persoane, care au interesul ca beneficiarul informaţiei să primească un mesaj
schimbat. Această deficienţă cronică a sistemului informaţional se manifestă în special când unii
manageri sunt incorecţi sau nu-şi exercită integral atribuţiile de control.
Efectul negativ atât al distorsiunii, cât şi al filtrajului este dezinformarea parţială sau integrală a
beneficiarului de informaţii. Când dezinformarea se produce la nivelul managerilor, aceasta se reflectă
în diminuarea calităţii deciziilor. Când dezinformarea se produce la nivelul executanţilor, efectele
immediate se resimt pe palnul realizării proceselor cu caracter operaţional, impietând asupra cantităţii,
calităţii şi perioadei de obţinere şi furnizare a produselor şi serviciilor. În ambele situaţii, efectele pe
termen lung sunt scăderea eficienţei, concomitent cu deteriorarea într-o anumită măsură a climatului de
muncă, a relaţiilor dintre personalul implicat ş.a.

Redundanţa este o altă deficienţă majoră tipică a sistemului informaţional, care constă în
înregistrarea, transmiterea şi prelucrarea repetată a unor informaţii. Cauza majoră a acestei
disfuncţionalităţi informaţionale o reprezintă absenţa coordonării sau coordonarea defectuoasă a
anumitro segmente ale sistemului managerial. Redundanţa se produce mai ales când nu se respectă
principiul unităţii de decizie şi acţiune, când mai mulţi manageri se adresează nemijlocit cu cereri de
informaţii unor compartimente, fără ca personalul managerial responsabil nemijlocit de activitatea lor
să fie informat şi să intervină. Efectele redundanţei, care se manifestă adesea sub forma cererii
aceloraşi informaţii de către diferiţi beneficiari, dar sub alte forme, constau într-o apreciabilă risipă de
timp şi adesea de mijloace materiale din partea celor implicaţi.

În categoria deficenţelor majore se înscrie şi supraîncărcarea circuitelor informaţionale cu

informaţii, prin care desemnăm vehicularea prin ele a unei cantităţi de informaţii ce-i depăşeşte
capacitatea de transport, ceea ce duce la blocarea şi/sau întârzierea ajungerii unei părţi din informaţii la
adresant. Printre cauzele care o generează menţionăm – în afara redundanţei – nerespectarea
caracterului piramidal al sistemului informaţional. Prin caracter piramidal al sistemului informaţional
înţelegem transmiterea şi agregarea selectivă a informaţiilor pe verticala sistemului de management
corespunzător sferei obiectivelor, competenţelor şi responsabilităţilor circumscrise subdiviziunilor
organizatorice. La originea acestei situaţii se află proiectarea defectuoasă a sistemului informaţional,
insuficienta pregătire a unor manageri şi executanţi, tendinţa unora de a-şi “umfla” realizările, de a-şi
populariza excesiv acţiunile etc.
Fără îndoială că elementele menţionate nu epuizează gama deficienţelor cronice ale sistemului
informaţional, dar constiuie, de regulă, maladiile cele mai frecvente, a căror cunoaştere, identificareşi
eliminare constituie o componentă de bază a raţionalizării sistemului informaţional al organizaţiilor.
 3.4 ANALIZE DE FEZABILITATE

Elaborarea unui sistem poate costa milioane de dolari şi se poate realiza pe parcursul a trei până
la şase ani pentru a fi complet. Din aceste motive, este normal ca factorii de conducere să demareze
proiectarea unui sistem după ce se efectuează studii de fezabilitate.
Un studiu de fezabilitate are rolul de a asigura informaţiile obiective necesare pentru a cunoaşte
dacă un proiect poate fi demarat sau nu, sau dacă un proiect deja început mai poate fi continuat.
Proporţiile şi durata studiilor de fezabilitate variază, în funcţie de mărimea şi natura sistemului de
implementat.
Echipele de studiu trebuie să includă atât persoane cu înalte cunoştinţe tehnice, cât şi persoane
cu bogate cunoştinţe şi experienţă în activităţile unităţii studiate. Dacă unitatea nu dispune de
personalul adecvat pentru partea tehnică a studiului, atunci va putea angaja din afară specialişti. De
asemenea, echipele trebuie să aibă în structură atât reprezentanţi ai conducerii, cât şi ai echipelor de
control intern sau revizie internă. Nu în ultimul rând, trebuie ca din echipă să facă parte reprezentanţii
utilizatorilor.
Când este propus un proiect, se efectuează un studiu preliminar de fezabilitate pentru a se stabili
dacă proiectul atinge obiectivele propuse de unitate. Analiza, în prima ei fază, poate fi oricât de
subiectivă, întrucât proiectul nu este prezentat cu lux de amănunte. Însă, îndată ce se obţine o situaţie
mai clară despre sistem, despre natura problemei de rezolvat, precum şi despre doleanţele utilizatorilor,
măsurarea preliminară a fezabilităţii poate fi determinată odată cu faza de analiză a sistemului. Când
proiectanţii oferă două sau trei variante de elaborare a sistemului, numai studiile de fezabilitate o pot
scoate în relief pe cea optimă.
După ce a avut loc proiectarea primară a sistemului, pot fi determinate în detaliu elementele de
cost al proiectării, implementării şi exploatării. Este ultima şansă a unităţilor de a mai putea renunţa la
sistem, înaintea implementării.
De fiecare dată, studiile de fezabilitate trebuie să aibă la bază documentaţie completă. Aceasta
va conţine:
• definirea problemei(o scurtă descriere a proiectului şi explicarea a ceea ce îşi propune el să
realizeze);
• descrierea cerinţelor sistemului;
• descrierea soluţiilor sistemului propus;
• explicaţia critică a motivării studiului întreprins;
• cuantificarea tuturor costurilor materialelor şi beneficiile aferente;
• listă a costurilor şi beneficiilor necuantificabile.
Tipurile analizelor de fezabilitate
Se conturează câteva dimensiuni ale fezabilităţii, care trebuie să fie evaluate prin studiul de
fezabilitate întreprins, incluzând fezabilitatea tehnică, economică, de exploatare(operaţională), a
legalităţii şi a programării în timp.
Fezabilitatea tehnică. Problema fundamentală este: poate fi implementat sistemul planificat în
organizaţia respectivă folosind tehnologia existentă? Oferă unitatea condiţii persoanelor care vor
proiecta, implementa şi exploata sistemul propus?
Fezabilitatea economică trebuie să răspunde la două întrebări. Prima: justifică sistemul propus
banii, alte resurse şi costurile necesare pentru a fi implementat? A doua: are unitatea fondurile necesare
pentru elaborarea şi implementarea sistemului, date fiind cerinţele de capital şi pentru alte proiecte
existente? Pentru a răspunde la aceste întrebări, trebuie să fie estimate şi analizate diverse costuri şi
beneficii asociate fiecărei variante.
Fezabilitatea exploatării porneşte de la o primă întrebare, şi anume: este posibil ca noul sistem
să fie utilizat de către persoanele cărora le este adresat. Răspunsul poate fi dat doar în condiţiile din
întreprindere, de ceea ce se întâmplă cu persoanele din sistem înainte de implementarea celui nou, în
sensul participării efective , motivate de realizarea lui, precum şi de dorinţa lor de transformare. Tot
aici intră o multitudine de factori comportamentali.
Fezabilitatea legalităţii urmăreşte să determine dacă se pot înregistra conflicte între sistemul
propus şi posibilitatea organizaţiei în care se face implementarea de a nu avea conflicte faţă de
obligaţiile legale. De asemenea, sistemul trebuie să respecte toate statule, deciziile, regulamentele,
legile şi alte acte normative şi juridice, atât în profil teritorial, cât şi naţional şi internaţional.
Fezabilitatea programării răspunde în primul rând la întrebarea: poate fi proiectat şi
implementat sistemul în timpul alocat ? Dacă răspunsul este nu, sistemul trebuie să fie modificat sau va
fi luată în studiu o altă variantă, sau data implementări va fi schimbată.
Fezabilitatea economică: determinarea costurilor şi a beneficiilor proiectelor
Deoarece economiştii contabili sunt familiarizaţi cu problema calculaţiei costurilor, ei vor avea
o contribuţie majoră la o evaluare corectă a acestora. Cadrul de bază îl va constitui modelul bugetelor
de capital. Un astfel de model presupune estimarea cu o mare rigurozitate a costurilor iniţiale, a celor
din timpul exploatării, precum şi a altor consumaţiuni de valori, a economiilor şi beneficiilor pentru
fiecare an de utilizare a sistemului. Dacă sunt prezentate mai multe variante; cei ce se ocupă de viitorul
sistem o vor alege pe cea mai valoroasă, prin prisma, termenului de recuperare, a valorii nete prezente.

3.5 GENERAREA ŞI ALEGEREA VARIANTELOR DE PROIECTARE

Concluziile la care ajunge echipa de analisti după parcurgerea celor 2 etape, de determinare si
structurare a cerintelor, se vor regasi în cel putin 2 si maxim 6 variante de solutii pentru problema
analizata.
In practica, numarul de solutii propuse de specialisti este de 3, intrucit prin el pot fi surprinse
solutii extreme, dar si de mijloc.
Varianta 1 este cea mai simpla si se caracterizeaza astfel:
- e cea mai conservatoare în privinta costurilor, efortului depus şi tehnologiilor implicate.
- e puternic orientata spre realizarea pe hartie a fluxului informational sau spre eliminarea
redundantelor din procesele curente.
- ofera solutii pentru tot ce a solicitat utilizatorul implicand modificari putine în sistemul
informational existent.
Varianta 2, cea mai complexa, ofera multiple solutii pentru problema studiata şi se
caracterizeaza prin:
- ofera cele mai performante sisteme, bazate pe cele mai moderne tehnologii.
- sunt orientate spre functionalitate.
- resursele umane şi financiare sunt incadrate în anumite limite.
- utilizatorul primeste toate solutiile posibile pentru rezolvarea problemelor dar nu
intotdeauna poate opta pt o astfel de varianta datorita resurselor limitate.
- sistemul implementat va fi un sistem deschis
Varianta 3 este cea de compromis intre cele 2:
- obiectivul central il constituie functionalitatea de inalt nivel.
- restrictiile legate de costuri dispar.
În generarea acestor variante se tine cont conditiilor esentiale ale activitatii:
- atingerea functiilor obligatorii ale noului sistem
- respectarea restrictiilor impuse,
dar şi de unele aspecte practice ca:
a) daca sistemul poate fi realizat cu forte proprii
b) daca selectia pentru implementarea sistemului e optima
c) selectia softului şi hardului
 d) limitele organizatiei.
Fiecare varianta va contine:
a) prezentarea generala a proiectului din care sa rezulte aria de cuprindere a proiectului,
gradul de distributie a sistemului, nivelul lui de automatizare, necesarul de resurse, planificarea
calendaristica.
b) descrierea sistemului vizeaza configuratia sistemului determinata de realizarea cerintelor si
de restrictiile impuse.
In ceea ce priveste cerintele, acestea pot fi de 2 feluri:functionale si nefunctionale
Cerintele functionale se refera la functiunile pe care sistemul informatic trebuie sa le
implementeze, cu precizarea ca , in proportie de 80-90%, se vor implementa functiunile
sistemului actual, la care se vor adauga functiuni cerute de beneficiar sau analist pentru
asigurarea pervformantelor dorite.
Cerintele nefunctionale tin de caracteristicile tehnice ale sistemului informatic, cum ar fi:
tehnologiile de prelucrare, performantele si securitatea sistemuli, siguranta si arhivarea datelor.
In vederea asigurarii acestor cerinte, descrierea sistemului va contine urmatoarele elemente:
- specificarea obiectivelor in functie de performantele urmarite;
- stabilirea functiilor obligatorii ale noului sistem si a restrictiilor impuse;
- stabilirea minimului necesar de informatii solicitate de noul sistemconcretizate in: definirea
principalelor intrari/iesiri, definirea solutiilor de organizare a datelor, definirea variantelor tehnologice
de prelucrare, definirea restrictiilor informationale si de control;
- prezentarea problemelor legate de de realizarea sistemuli informatic, cum ar fi: precizarea
modalitatilor de realizare a sistemului informatic(daca sistemul va fi realizat cu forte proprii),
precizarea prioritatilor in realizarea o9biectivelor sistemului informatic, specificarea cerintelor speciale
privind flexibilitatea, compatibilitatea cu alte sisteme, gradul de generalizare a sistemului.
c) analiza cost beneficiu presupune estimarea duratei de realizare, a resurselor necesare si
efectelor economice directe si indirecte care se vor obtine din exploatarea sistemului. In functie de
aceasta analiza se calculeaza indicatorii de eficienta economica si se apreciaza daca este profitabila
proiectarea noului sistem informatic.
d) analiza impactului introducerii sistemului prezinta aspecte ale oportunitatii implementarii
noului sistem.
Se realizeaza o analiza a modificarilor pe care le aduce in structura organizatorica, deoarece
eliminarea unor functiuni ale sistemului actual implica desfiintarea unor posturi de lucru, birouri,
servicii, departamente, iar introducerea d enoi functiuni duce la infiintarea de noi posturi. Tot aici este
analizat comportamentul organizatoric – daca sistemul implementat poate fi utilizat de persoanele
carora le este adresat.
 4. PROIECTAREA SISTEMELOR INFORMATICE

Proiectarea unui sistem informatic se realizează în funcţie de complexitatea şi gradul de

detaliere a problemelor ce trebuie rezolvate se împart în 2 etape:
- proiectarea de ansamblu sau generală sau logică în care se stabileşte componenţa de ansamblu
a sistemelor, adică modul de descompunere şi componente, care sunt intrările şi ieşirile, care sunt
modelele de organizare a datelor, care sunt colecţiile de date, etc….
- proiectarea de detaliu care va detalia fiecare componentă a sistemului şi va descrie modul de
stocare şi accesare a datelor.

4.1 PROIECTAREA DE ANSAMBLU / GENERALĂ / LOGICĂ

Proiectarea de ansamblu îşi propune să definească sistemul informatic din punct de vedere
funcţional şi structural. Aceasta înseamnă că se identifică componentele, după care se vor descrie atât
din punct de vedere structural, cât şi funcţional.
Criteriile avute în vedere la proiectarea generala a unui sistem sunt :
a) obiectivele avute în vederea de organizarea respectivă,
b) posibilităţi de modificare a ieşirilor,
c) aria de întindere pe noul sistem, costurile şi termenele de realizare.
Structura de ansamblu a unui sistem informatic e formată din intrări, ieşiri şi prelucrări.
Intrările sunt reprezentate de:
 • tranzacţii externe care redau dinamica operatiilor economice, provin din exteriorul sistemului
informatic electronic de calcul şi sunt furnizate de proceduri automate. Exemplu: înregistrarea
unei operaţii de aprovizionare cu marfă;
• tranzacţii interne care redau modificările structurale din cadrul bazei de date; sunt asigurate
exclusiv în cadrul sistemului informatic prin intermediul procedeului de exploatare sau de
actualizare a bazei de date. Exemplu: totalul facturilor primite de la un furnizor care actualizează
soldul furnizorului respectiv.
Prelucrările sunt asigurate de un ansamblu de proceduri automate care realizează actualizarea
şi exploatarea colecţiilor de date ca urmare a tranzacţiilor interne şi externe în vederea obţinerii
rapoartelor, listelor, situaţiilor de ieşire ale sistemului informatic.
Ieşirile sistemului informatic sunt rezultatul prelucrării bazei de date şi sunt redate în funcţie de
conţinutul lor şi de structura lor sub formă de indicatori sintetici, rapoarte, liste, situaţii de ieşire,
grafice, stocare pe suporturi.
Pentru determinarea necesarului de date de intrare se utilizează mai multe metodologii care
determină anumite variante de abordare a proiectării de ansamblu.
Astfel, în funcţie de complexitatea obiectivelor stabilite, de aria de cuprindere a noului sistem
informatic, de posibilităţile de modificare a ieşirilor, de costurile şi termenele de realizare a sistemului
informatic, se folosesc următoarelor variante de abordare a proiectării de ansamblu:
Prima varianta de abordare, pe baza principiului ieşiri-intrări asigură determinarea conţinutului
bazei informaţionale în funcţie de obiectivele stabilite de unitatea beneficiară. În această variantă
ieşirile sunt reflectate de obiectivele informaţionale solicitate, în timp ce intrările sunt reflectate de
conţinutul bazei informaţionale.
Avantajul acestei metode constă în furnizarea unui conţinut complet al bazei informaţionale
determinată iniţial şi pe baza stabilirii listelor de ieşire.
Dezavantajul este legat de imposibilitatea emiterii de noi situaţii de ieşire, deoarece varianta nu
poate genera la ieşire decât conţinutul bazei informaţionale De asemenea, nu poate genera alţi
indicatori rezultaţi ca urmare a aplicării unui algoritm de calcul asupra conţinutului bazei
informaţionale.
A doua variantă, pe baza principiului intrări - ieşiri determină conţinutul bazei informaţionale
independent de ieşirile solicitate urmând să se asigure atât cerinţele imediate cât de perspectivă.
Avantajul constă în determinarea unei baze informaţionale complete, cu menţiunea însă că
unele atribute nu vor fi poate niciodată utilizate în prelucrările sistemului informatic.
Dezavantajul rezidă din cheltuielile mari de realizare a bazei informaţionale, cheltuieli
determinate de studierea tuturor activităţilor desfăşurate şi de supradimensionarea acesteia.
A treia variantă, mixtă îmbină avantajele celor două variante prezentate şi le minimizează
dezavantajele.
În practica economică, datorită vehiculării unui număr foarte mare de documente de intrare, la
proiectarea sistemelor informatice se foloseşte varianta de abordare pe baza principiului ieşiri - intrări
Activităţile desfăşurate în cadrul proiectării de ansamblu sunt:
• stabilirea obiectivelor noului sistem informatic.
• proiectarea rapoartelor, listelor, situaţiilor de ieşire
• proiectarea bazei informaţionale.
STABILIREA OBIECTIVELOR SISTEMULUI INFORMATIC
Obiectivele sistemului informatic reprezintă scopuri imediate şi de perspectivă care vor
determina structura, funcţionalitatea şi conexiunile noului sistem informatic şi care vor asigura
minimizarea perturbaţiilor apărute în desfăşurarea activităţilor, contribuind astfel la maximizarea
eficienţei economice şi a rentabilităţii unităţii beneficiare.
 Determinarea obiectivelor noului sistem are la bază ideea potrivit căreia acest sistem este
dedicat procesului decizional, deoarece numai cu un management performant se pot obţine efecte
economice ridicate, cu eforturi cât mai reduse.
Din acest motiv, obiectivele unui sistem informatic pot fi grupate în două categorii:
• Obiective generale ce trebuie să asigure cunoaşterea exactă şi operativă a activităţii
desfăşurate de unitatea economică;
• Obiective specifice care vor sigura condiţiile necesare realizării obiectivelor generale.
Obiective generale
Obiectivele generale ale unui sistem informatic urmăresc generarea şi furnizarea operativă şi
selectivă, către toate nivelele de conducere, a unor date cu caracter strategic, tactic, operativ şi
funcţional, pentru asigurarea atributelor conducerii şi ale funcţiilor unităţilor economice. În raport de
aceste aspecte, obiective generale pot fi:
• de conducere (manageriale);
• funcţionale.
Obiectivele de conducere vizează probleme cu caracter global şi structural, de conducere ale
unităţii economice şi se axează pe:
• realizarea în condiţii de maximă eficienţă a întregii activităţi;
• realizarea globală şi structurală a indicatorilor economico-financiari (cifra de afaceri, valoarea
adăugată, profitul brut şi net, capitalul propriu, capacitatea de plată, rata rentabilităţii, eficienţa
utilizării fondurilor fixe etc.), calculul şi planificarea „rezultatelor”, planificarea financiară a
investiţiilor, previzionarea activelor circulante şi a surselor de finanţare, previzionarea activităţii
de trezorerie, inclusiv utilizarea bugetului general al unităţii economice;
• perfecţionarea structurilor şi a activităţii de producţie în vederea asigurării unui optim global;
• asigurarea unui fundament informaţional superior pentru fundamentarea şi implementarea
strategiilor şi politicilor unităţii economice;
• realizarea unei funcţionalităţi superioare de ansamblu a sistemului decizional;
• facilitarea introducerii şi utilizării anumitor tehnici, metode şi sisteme manageriale;
• degrevarea conducerii de procesele decizionale de rutină, formalizarea prin noul sistem a
informaţiilor sintetice necesare derulării relaţiilor informaţionale cu organismele de stat şi cu alte
regii autonome sau societăţi comerciale;
• creşterea operativităţii şi gradului de fundamentare şi adoptare a deciziilor.
Obiectivele funcţionale au în vedere informatizarea activităţilor esenţiale şi specifice ale
unităţii economice în vederea asigurării funcţiilor sale fundamentale: cercetare-dezvoltare, comercială,
producţie sau exploatare, financiar- contabilitate, personal.
1. Activitatea de cercetare-dezvoltare vizează strategiile de dezvoltare a produselor şi
tehnologiilor precum şi cele de dezvoltare a unităţii economice în ansamblul său. Informatizarea
acestor activităţi presupune informatizarea următoarelor subactivităţi:
• proiectare produselor;
• proiectarea în domeniul tehnologiilor şi echipamentelor;
• determinarea capacităţii de producţie şi utilizare eficientă a acesteia;
• elaborarea normativelor şi normelor de consum pentru resurse materiale şi energetice;
• elaborarea normativelor şi normelor de muncă şi a consumurilor specifice de manoperă.
2. Activitatea de producţie desfăşurată în cadrul unor compartimente are în vedere elementele
specifice fiecărei subactivităţi, din punct de vedere informatic, după cum urmează:
• definirea ingredientelor şi proceselor ce sunt utilizate în producţia continuă;
• definirea secţiilor, operaţiilor şi ordonarea lor, care intervin în fabricarea unui produs;
• definirea materialelor şi (sub)ansamblelor folosite pentru fabricarea unui produs;
 • gestiunea calităţii;
• previziunea produselor;
• program de producţie;
• planificarea cerinţelor materiale;
• planificarea cerinţelor capacităţii;
• planificarea cerinţelor de manoperă;
• planificare resurse.
3. Activitatea comercială este reprezentată prin trei subactivităţi: aprovizionare, desfacere,
marketing. Sistemul informatic va trebui sa soluţioneze optim următoarele aspecte specifice:
Subactivitatea de aprovizionare
• determinarea necesarului de resurse materiale şi energetice;
• contractarea necesarului de aprovizionat.
Subactivitatea de desfacere
• situaţia necesarului de livrat conform contractelor;
• situaţia cantitativ şi valorică a livrărilor ;
• urmărirea ritmicităţii livrărilor în scopul onorării contractelor.
Subactivitatea de marketing
• studierea caracteristicilor tehnico-economice, inclusiv a tehnicilor de comercializare a
produselor concurente, furnizate de alte societăţi comerciale din tară sau străinătate;
• evoluţia pieţelor de desfacere în vederea realizării relaţiilor valutar-financiar şi de distribuire a
produselor proprii;
• cooperarea cu alte societăţii comerciale din ţară sau străinătate în vederea promovării
produselor pe terţe pieţe
4. Activitatea financiar-contabilă desfăşurată în cadrul compartimentelor specifice presupune
rezolvarea din punct de vedere informatic a unor elemente specifice după cum urmează:
Subactivitatea financiară
• elaborarea bugetului general al unităţii economice pe an financiar, şi desfacere pe subunităţi.
• gestiunea creditului clienţi pune în evidenţă sumele datorate de clienţi, ce rezultă din datele
generate de cumpărările şi plăţile acestuia;
• gestiunea numerarului colectează informaţii privind toate intrările şi ieşirile de numerar din
organizaţie, în mod periodic sau chiar în timp real.
• gestiunea portofoliului (titlurilor) de plasament evidenţiază surplusul de numerar investit în
hârtii de valoare pe termen scurt (fie cu un grad de risc scăzut-bonuri de tezaur, certificate de
trezorerie, fie cu un grad de risc mai ridicat dar şi cu posibilităţi mai mari de câştig), astfel încât
sumele rezultate să poată fi disponibile atunci când sunt necesare fonduri.
Subactivitatea contabilă se desfăşoară în două circuite:
• Contabilitatea financiară (sintetică), reflectă starea patrimonială a unităţii economice prin
intermediul activului, datoriile (obligaţiile), capitalul propriu şi rezultatele nete obţinute pe
parcursul unei perioade de gestiune.
• Contabilitatea de gestiune (analitică), oferă informaţii care reflectă cheltuielile şi veniturile pe
purtători de valoare şi resursele repartizate spre gestionarea la nivelul fiecărei structuri
organizatorice.
Subactivitatea de control financiar, la nivelul unităţii economice urmăreşte analiza şi controlul
gestiunii patrimoniului regiei automate sau societăţii comercială prin instrumente proprii, în scopul
prevenirii şi sesizării încălcării normelor legale de utilizare a resurselor umane, materiale şi băneşti.
 5. Activitatea de personal acoperă întreaga gamă de activităţii legate de evidenţa personalului,
salarizarea, perfecţionarea calificării personalului şi presupune rezolvarea sub aspect informatic a
următoarelor sarcini:
Subactivitatea de evidenţă a personalului trebuie să asigure:
• evidenţa personalului pe meserii, în funcţie de vechime, pe locuri de muncă, pe diferite
intervale de timp;
• verificarea încadrării personalului pe meserii, funcţii şi locuri de muncă;
• evidenţa mişcării de personal (angajării, promovări, transferări, pensionari, concedii)
Subactivitatea de salarizare asigură:
• înregistrarea orelor lucrate pe baza fişelor de partaj sau a foilor colective de prezenţă, prin care
se determină numărul orelor care va fi luat în calcul la stabilirea salariilor pentru o lună. Poate să
apară situaţia în care se vor folosi fişele de manoperă;
• calculul drepturilor salariale se particularizează în funcţie de modul de plată al fiecărei
organizaţii;
• -evidenţierea obligaţiilor de plată ale salariaţilor, fie sub forma impozitelor şi contribuţiilor fie
sub forma reţinerilor datorate către firme sau bănci.
Subactivitatea de perfecţionare a calificării personalului se particularizează de la o firmă la alta,
în funcţie de specificul obiectivului de activitate şi de criteriile de evaluare stabilite la nivelul politicii
de personal şi urmăreşte:
• performanţele salariaţilor, pe faza unor criterii de evaluare stabilite în funcţie de specificitatea
activităţii desfăşurate. Pe baza evaluărilor de performanţe conducerea poate stabili nivelul
salariului pentru fiecare angajat, posibilitatea de promovare, necesităţile de instruire ş.a.
• înregistrarea pregătirilor profesionale şi a instruirilor la care au participat salariaţii, urmărindu-
se prelucrarea datelor necesare elaborării programului de îmbunătăţire a aptitudinilor şi
performanţelor profesionale ale salariaţilor;
• stabilirea priorităţilor în angajarea a noi categorii de salariaţi, astfel încât activitatea unităţii
economice să se desfăşoare, la cel mai înalt grad de tehnicitate.
Obiectivele specifice
Obiectivele specifice asigură condiţiile realizării obiectivelor generale şi trebuie să ţină seama
de aspectele concrete din realitatea unităţii economice studiate, cum ar fii:
• mărimea unităţii economice;
• structura sa organizatorică;
• ponderea acesteia într-o ramură de activitate;
• gradul de participare al unităţii economice la derularea operaţiunii de export-import,
cooperarea internaţională;
• alte elemente ce pot conduce la alte tipuri de obiective cu o nuanţare specifică.
Obiectivele generale şi specifice ale unui sistem informatic pot urmări şi alte aspecte, cum ar
fi:
• asigurarea proiectării automate a datelor în condiţii de eficienţă economică;
• optimizarea fluxurilor şi circuitelor informaţionale;
• furnizarea automată a informaţiilor cu caracter sintetic şi analitic destinate conducerii şi
structurilor organizatorice pentru crearea condiţiilor informaţionale necesare realizării
obiectivelor de conducere, tehnologice şi informatice;
• utilizarea eficientă a unităţilor centrale a calculatoarelor printr-o alocare dinamică a spaţiului
de memorie;
 • realizarea celei mai adecvate si operative metode de introducerea datelor în vederea
minimizării timpului de încărcare a colecţiilor de date, în vederea obţinerii la termenele stabilite a
tuturor situaţiilor de ieşire în care se concretizează obiectivele noului sistem.

PROIECTAREA RAPOARTELOR/LISTELOR/SITUAŢIILOR DE IEŞIRE

Datele de ieşire sunt informaţii livrate de sistemele de prelucrare autonomă a datelor
utilizatorului sub forma unor mesaje, rapoarte, grafice etc.

Ieşirile noului sistem informatic sunt stabilite de către conducerea unităţii economice, în
colaborare cu echipa de realizare a sistemului, ca urmare a analizei obiectivelor sistemului proiectat, în
proiectarea lor ţinându-se seama de următoarele aspecte:
1) Destinaţia situaţiei şi momentul când se estimează, se poate obţine nivelul de detaliere al
informaţiei, respectiv informaţii mai analitice pentru nivele de bază şi mai sintetice la nivelele
superioare.
2) Existenţa în situaţie a tuturor informaţiilor necesare, avându-se în vedere în acelaşi timp, ca
pe cât posibil, o informaţie să nu apară inutil în mai multe situaţii.
Structura informaţională şi formatul ieşirii sunt determinate, în principiu, de următoarele reguli:
• respectarea specificaţiilor cadrului legislativ în vigoare
• proiectarea se va face în concordanţă cu activităţile specifice obiectivelor sistemului;
• conţinutul va fi redat sintetic sau analitic şi cu o frecvenţă precizată în legislaţie;
Formatul de afişare, dispozitivul periferic folosit şi beneficiile ieşirilor sistemului informatic
sunt stabilite în raport cu solicitările sistemului de management, sistemului operant, sistemelor
informatice externe.
Criteriile utilizate pentru determinarea formatului, conţinutului, dispozitivului periferic şi
beneficiarilor ieşirilor noului sistem, au impus structurarea acestora în următoarele categorii:
A. Rapoartele/listele/situaţiile de ieşire conţin indicatori sintetici şi analitici, al căror conţinut
reflectă starea, dinamica şi tendinţa fenomenelor şi proceselor economice ce fac obiectul procesului de
prelucrare a datelor din sistemul proiectat. Reprezentarea datelor se face, de regulă , în format de tabel.
Anumite rapoarte au formatul stabilit prin respectivul cadru legal.
B. Indicatorii sintetici redau fenomene şi procese economico-financiare prin intermediul unor
date succinte utilizate în special informării operative şi demersului decizional.
C. Graficele redau sub formă sinoptică starea şi evoluţia unui fenomen economico-financiar în
scopul informării conducerii sau compartimentelor unităţii economice, adoptării unor decizii operative,
prin care să asigure fenomenul de feed – back al activităţii economico-financiare analizate.
D. Ieşirile către alte sisteme sunt de fapt transmisii de date on-line, prin intermediul unei reţele
locale de calculatoare, sau off-line, prin intermediul suporturilor magnetice(disc flexibil, disc magnetic,
bandă magnetică).
PROIECTAREA BAZEI INFORMAŢIONALE
Baza informaţională conţine nucleul informaţional format din totalitatea atributelor necesare
prelucrărilor specifice sistemului informatic şi structura informaţională reprezentată de entităţi între
care se stabilesc corespondenţe şi legături.
Proiectarea bazei informaţionale presupune:
A. Determinarea conţinutului bazei informaţionale şi a algoritmilor utilizaţi;
B. Determinarea structurii bazei informaţionale.
C. Normalizarea relaţiilor
A. Determinarea conţinutului bazei informaţionale şi a algoritmilor utilizaţi
Conţinutul bazei informaţionale se determină în funcţie de variantele de abordare a proiectării
generale alese.
În varianta ieşiri-intrări conţinutul bazei informaţionale se determină în funcţie de obiectivele
propuse concretizate în situaţiile de ieşire. Baza informaţională se va constitui pe baza ieşirilor
solicitate şi va fi modificată pe tot parcursul exploatării sistemului în concordanţă cu dinamica
fenomenelor şi proceselor din unitatea beneficiară.
Această variantă se aplică în cazul realizării sistemelor informatice mari şi mijlocii caracterizate
printr-o complexitate ridicată a ieşirilor informaţionale şi implicit a obiectivelor avute în vedere.
În varianta intrări-ieşiri conţinutul bazei informaţionale presupune cunoaşterea datelor de intrare
şi dinamismul ieşirilor solicitate. Se aplică în cazul realizării sistemelor informatice de dimensiuni
mici.
Sistemele informatice din domeniul economic presupun realizarea unor obiective delimitate şi
fundamentate în strânsă legătură cu cadrul legislativ-normativ care impune natura ieşirilor
informaţionale, motiv pentru care în majoritatea cazurilor determinarea conţinutului şi structurii bazei
informaţionale se face pe varianta ieşiri-intrări.
Determinarea conţinutului bazei informaţionale prin varianta ieşiri-intrări presupune studierea
mulţimii atributelor din situaţiile de ieşire în funcţie de modul de obţinere în urma prelucrării automate.
Pentru proiectarea corectă a conţinutului bazei informaţionale este necesară îndeplinirea
concomitentă a următoarelor condiţii:
• mulţimea atributelor de ieşire este formată din submulţimea atributelor preluate reunită cu
submulţimea atributelor calculate;
• submulţimea operanzilor primari intersectată cu submulţimea atributelor preluate corespunde
atributelor comune ce se găsesc în ambele submulţimi;
• submulţimea atributelor de intrare este reprezentată corect de nucleul informaţional ce
constituie conţinutul bazei informaţionale.
B. Determinarea structurii bazei informaţionale
Structura bazei informaţionale de intrare reprezintă gruparea conţinutului acestuia (atributele de
intrare într-un ansamblu de entităţi inclusiv corespondenţele (legăturile) dintre acestea).
Structura bazei informaţionale de intrare este efectuată prin intermediul unui model de
reprezentare care asigură independenţa logică şi fizică a prelucrărilor faţă de colecţiile de date în care
va fi transpusă baza informaţională. Această proprietate asigură implicit independenţa relativă a
proiectării generale faţă de soluţiile tehnice adoptată în cadrul proiectării de detaliu.
În mod concret, gruparea atributelor de intrare în entităţi informaţionale şi reflectarea
corespondenţelor (legăturilor) dintre acestea se realizează gradat printr-un proces de modelare ce
permite definirea riguroasă a structurii bazei informaţionale. Acest proces de modelare are la bază
modelul de reprezentare entitate – atribut – corespondenţă. Acest model consideră baza informaţională
de intrare ca un ansamblu finit de entităţi informaţionale, caracterizate în mod unic, printr-o mulţime
specifică de atribute şi un ansamblu de corespondenţe (legături) stabilite între entităţi sau chiar în
interiorul acestora. În acest context corespondenţele pot fi definite ca asocieri între realizările aceleiaşi
entităţi sau realizările entităţilor diferite
Modelul conceptual al datelor redat sub forma diagramei entitate-asociere, este rafinat înainte
de a fi trecut într-un format logic (de regulă, un model relaţional al datelor) din care se definesc bazele
de date şi are loc proiectarea fizică a acestora (procesul de modelare a datelor este descris în vol. I
“Analiza şi modelarea datelor”).
Optimizarea structurii bazei informaţionale
 Definirea entităţilor, atributelor, legăturilor dintre colecţiile de date au drept scop depistarea şi
înlăturarea disfuncţionalităţilor ce ar putea afecta performanţele bazei informaţionale.
Optimizarea structurii bazei informaţionale are în vedere asigurarea unei flexibilităţi adecvate,
eliminarea redundanţelor dintre atribute şi crearea modalităţilor necesare unei actualizări permanente a
colecţiilor de date.
Prin optimizarea bazei informaţionale se asigură o flexibilitate ridicată şi o simplificare a
structurii bazei informaţionale. Astfel, entităţile complexe sunt descompuse în entităţi elementare sau
atributele sunt compuse în entităţi.
C. Normalizarea relaţiilor
Procesul de normalizare a relaţiilor este util în activitatea de proiectare a structurii logice şi a
bazei de date relaţionale şi constă în eliminarea neajunsurilor ce apar în exploatarea efectivă a bazei de
date, neajunsuri introduse de dependente incorecte, existente între datele relaţionale.
Din punctul de vedere al influenţei asupra performanţelor în exploatare a bazei de date,
normalizarea afectează negativ eficienţa cu care sunt rezolvate interogările. Aceasta pentru că
informaţiile care într-o bază de date nenormalizată ar putea fi regăsite într-o singură relaţie, în cazul
unei baze normalizate necesită, de cele mai multe ori, cuplarea a două sau mai multe relaţii. De aceea
normalizarea este considerată necesară şi utilă doar în ipoteza că operaţiile de adăugare, ştergere şi
actualizare sînt frecvent utilizate. Aşadar normalizarea îmbunătăţeşte integritatea datelor prin reducerea
redundanţei şi a inconsistenţei în detrimentul eficienţei unor operaţii de regăsire a datelor.
E. F. Codd a arătat ca într-o anumită formă relaţiile posedă proprietăţi nedorite pe care le-a
numit anomalii de actualizare şi le-a structurat astfel:
• anomalii de ştergere se referă la faptul că ştergând un tuplu dintr-o tabelă, pe lângă datele ce
trebuie eliminate se şterg şi cele necesare.
• anomalii de adăugare constau în faptul că anumite date noi care trebuie introduse într-o tabelă
fac parte din tupluri incomplete, motiv pentru care nu pot fi introduse.
• anomalii de modificare semnifică faptul ca e dificil de schimbat o valoare a unui atribut când
ea apare în mai multe tupluri ale relaţiei.
Pentru a elimina aceste anomalii Codd a stabilit trei forme normale pentru relaţii şi a introdus
noţiuni de normalizare care se bazează pe dependenţa funcţională între atributele unei relaţii. Ulterior,
alţi cercetători au mai completat formele normale cu încă două forme normale plus una suplimentară.
Primele patru nivele sînt definite în termenii dependenţelor funcţionale, şi sunt: prima, a doua, a
treia formă normală şi forma normală Boyce-Codd (notate FN1, FN2, FN3 şi FNBC). A patra formă
normală (FN4) şi a cincea formă (FN5) normală sînt definite în termenii dependenţelor multivalorice.
Diferitele nivele de normalizare impun condiţii din ce în ce mai restrictive asupra relaţiilor. Astfel o
relaţie aflată pe un anumit nivel de normalizare satisface toate restricţiile cerute de nivele inferioare de
normalizare. Deci o relaţie în FN4, este şi în FN3, FN2 ş.a.m.d.
Formalizarea atributelor
Activitatea de formalizare a atributelor presupune studierea documentelor de intrare şi
adaptarea lor la cerinţele sistemului informatic, iar multitudinea de atribute sunt codificate.
A. Adaptarea documentelor de intrare la cerinţele sistemului informatic
Documentele de intrare reflectă starea şi dinamica fenomenelor şi proceselor economice
desfăşurate în unitatea respectivă. Ele reprezintă principala sursă de date pentru crearea şi actualizarea
colecţiilor de date.
Dacă aceste documente nu corespund integral din punct de vedere al conţinutului şi al formei cu
structura bazei informaţionale şi cu restricţiile impuse de sistemul informatic proiectat, vor suferi
modificări de conţinut şi de formă.
Modificările de conţinut constau în :
 • adăugarea rubricilor de coduri acolo unde nu sunt prevăzute, insistându-se pe codurile ce
specifică natura operaţiilor reflectate şi a celor care servesc pentru identificarea şi asocierea
colecţiilor de date(exemplu: cod_material, cod_produs, nr._marcă);
• modificarea şi regruparea rubricilor aferente atributelor ce vor conţine date care să se
introducă în acelaşi loc în toate documentele. În acest mod se formează o zonă comună tuturor
documentelor, păstrându-se însă individualitatea fiecărui document.
Modificările de formă ale documentelor de intrare sunt impuse de necesitatea creşterii
facilităţilor de preluare directă a datelor prin intermediul videoterminalului şi vizează următoarele
aspecte:
• toate atributele care se introduc de la terminal se vor grupa astfel încât să fie înlăturată
dispersarea lor pe toată suprafaţa terminalului;
• atributele se vor ordona asigurându-se întâi prezenţa atributelor de identificare, apoi a celor
informative şi terminând cu cele cantitativ-valorice;
• atributele ce se preiau din colecţiile de date nu se vor intercala cu atributele care au un caracter
constant sau rezultă din calcule(de exemplu, din documentul de intrare “bon de consum” nu se
vor prelua atributele constante: preţ unitar, unitate de măsură, inclusiv atributele rezultate din
calcule, deşi ele sunt consemnate în documentele pentru efectuarea controlului în gestiune).
Pe lângă aceste modificări se vor stabili şi regulile de completare şi utilizare a documentelor de
intrare, se stabilesc numărul de exemplare, circuitul fiecărui exemplar, frecvenţa şi termenul de
introducere a datelor în colecţiile de date.
De asemenea, se precizează responsabiltăţile pentru completare şi verificare, semnăturile care
validează conţinutul documentelor de intrare, inclusiv persoanele împuternicite în acest sens. Aceste
specificaţii sunt folosite pentru proiectarea sistemului informatic şi sunt trecute în documentaţia
finalizată în etapa de implementare.
B. Codificarea atributelor
Activitatea de codificare trebuie să realizeze corelaţia între specificul activităţii unităţii
beneficiare şi particularităţile sistemului informatic proiectat.
Necesitatea de codificare este impusă de cerinţele de grupare si ierarhizare a atributelor care
oferea multiple soluţii (posibilităţi de prelucrare a datelor) regăsite in colecţiile de date care constituie
baza informaţională.
Codificarea atributelor constă în atribuirea, manuală sau automată, într-o formă sistematizată,
de coduri fiecărui element din sistemul informatic proiectat.
Prin codificarea atributelor se asigură următoarele avantaje:
• folosirea intensivă a memoriei externe prin înlocuirea atributelor cu coduri numerice,
alfabetice sau alfanumerice;
• realizarea unei ierarhizări a atributelor în funcţie de criteriile specifice prelucrării prin care se
poate obţine o ordonare a acestora în raport cu cerinţele de selectare a atributelor din baza
informaţională sau de obţinere a gradelor de total sau subtotal pentru situaţiile de ieşire;
• reducerea erorilor prin folosirea codului care simplifică scrierea în comparaţie cu folosirea
denumirilor explicite ale atributelor.
• utilizarea intensiva a suporturilor direct admisibile a memoriei interne, ceea ce permite
optimizarea accesului de diverse valori a atributelor concomitent cu minimizarea timpului de
prelucrare a viitoarelor colecţii de date.
• confidenţialitatea datelor, precum si integritatea acestora, ceea ce oferă bazei de date(B.D) o
securitate si o protecţie in timpul prelucrării
Pentru ca un sistem de codificare să fie eficient în procesul de prelucrare a datelor, se urmăresc
următoarele:
1) Cerinţele si funcţiile codificării.
2) Tipurile de coduri utilizate intr-un sistem informatic
3) Realizarea codificării propriu-zise
1) Cerinţele si funcţiile codificării
Cerintele codificării sunt redate de proprietăţile esenţiale ale unui cod pentru ca acesta să
asigure un sistem de codificare eficient şi viabil. Cele mai importante proprietăţi sunt:
• unicitatea codului, presupune existenta unui singur simbol pentru un atribut al bazei
informationale si pentru atribuirea unei valori unice a fiecarui atribut,proprietate care trebuie
asigurata la nivelul intregului sistem informatic
• stabilitate si suplete in timp, exprima necesitatea utilizarii unui tip de cod pe toata perioada de
utilizarii bazei de date (B.D) inclusiv posibilitatea extinderii expresiilor valorice in functie de
dinamica valorilor bazei informationale.
• comoditatea utilizării codului-se refera la facilitatea operaţiilor de codificare şi de detectare a
erorilor, precum şi corectare a acestora. Atribuirea codurilor trebuie să fie uşor de înţeles şi
aplicat astfel încât personalul unităţii beneficiare sa asimileze intr-un timp foarte scurt noul
sistem de coduri
• concizia codului se refera la necesitatea unui număr redus de caractere pentru reprezentarea
elementelor codificate, astfel încât să se asigure o viteză mare de prelucrare şi o reducere a
procentelor de erori în procedurile manuale de introducere a datelor.
Pentru realizarea acestor cerinţe codificarea atributelor constă în atribuirea manuală sau
automată, într-o formă sistematizată a unor coduri fiecărui atribut din baza informaţională.
Funcţiile codificării
Trebuie să permită caracterizarea directă a fiecărui atribut ce va fi supus codificării,
identificarea formală a acestora, controlul valorilor posibile atribuite, posibilitatea de manipulare a
atributelor codificate.
Funcţia de caracterizare, exprimă intr-o formă concisă, unică şi stabila în timp conţinutul semantic
al fiecărui atribut, prin intermediul codurilor asociate(exemplu: în loc de Facultatea de Management
Financiar Contabil se poate utiliza codul FMFC).
Funcţia de identificare, oferă posibilitatea regăsirii mai rapide a atributelor, decât prin folosirea
complexă a semanticii atributului. Aceasta funcţie crează posibilitatea ulterioara de selectare a
anumitor atribute prin intermediul cărora se vor identifica in mod unic atributele solicitate prin
intermediul cheilor primare si externe.
Funcţia de control asigură existenţa unui caracter care ataşează în ultimă poziţie din dreapta
structurii codului pe baza căruia prin metode matematice (aritmetica si geometrica) au algoritmi
specifici ,se poate verifica integral corectitudinea simbolurilor care intră în componenta codurilor.
Funcţia de manipulare a atributelor codificate, facilitează introducerea eficientă a codurilor in
memorie, reduce timpul de prelucrare a acestora, facilitează uşurinţa folosirii atributelor de către
toate compartimentele funcţionale implicate in realizarea sistemului informatic respectiv.
2) Tipologia codurilor
Diversitatea şi complexitatea conţinutului bazei informaţionale de intrare, precum şi
multitudinea proceselor de prelucrare a atributelor componente, au condus la apariţia unei game variate
de coduri, grupate în mai multe categorii, în funcţie de următoarele criterii de clasificare:
a) Natura caracterelor;
b) Controlul erorilor;
c) Structura simbolului;
d) Lungime;
 e) Modul de elaborare(atribuire).

a) Natura caracterelor ce intră în componenţa codului determină următoarele coduri:

• numerice: formate numai din cifre;
• alfabetice: formate numai din litere:
• alfanumerice: formate din cifre, litere şi eventual caractere speciale.

b) Controlul erorilor se realizează prin intermediul unui caracter de control, cifră sau literă,
situat la dreapta structurii codului. Acest caracter de control face parte din structura codului şi va avea
aceeaşi valoare atâta timp cât valorile
De asemenea, caracterul de control asigură fie detectarea automată a erorilor introduse (coduri
autodetectoare de erori), fie şi corectarea automată a acestora (coduri autocorectoare de erori).
Codurile autodetectoare de erori se bazează pe existenţa caracterului de control care asigură
detectarea automată a erorilor introduse prin compararea caracterului de control care însoţeşte codul
respectiv cu caracterul de control determinat de calculator atunci când respectivul cod este utilizat.
Pentru calculul caracterului de control se folosesc mai multe metode, dintre care cele mai
cunoscute sunt:
• metoda aritmetică;
• metoda geometrică;
• metoda literei de control.
c) Structura simbolului
Coduri secvenţiale se formează prin atribuirea unui şir de caractere fiecărui element al mulţimii
stabilind o corespondenţă (in ordine crescătoare) între elementele acestora şi mulţimea numerelor
naturale. Fiecărui element supus codificării i se asociază un cod crescător, imediat disponibil. De
exemplu: unei persoane angajate i se atribuie marca 123, este precedată de marca 122 şi succedată de
marca 124.
Codul de semnificatie mnemonica se formează prin utilizarea unor simboluri recunoscute de
standardele în vigoare sau prin atribuirea unor consoane rezultate din abrevierea elementului respectiv
(de exemplu OL pentru oţel laminat).
Codul de semnificaţie descriptivă se formează prin combinarea iniţialelor desemnate pentru
denumirea elementului respectiv cu particularităţile tehnico-constructive ale acestuia. Acest tip de
coduri este utilizat in special in nomenclatoarele de coduri speciale cu posibilităţile de extindere pentru
particularităţile tehnice semnificative (de exemplu: Codurile complexe conţin atribute ce aparţin unor
mulţimi distincte, dar sunt folosite în comun în viitoarele prelucrări.
În această categorie se include codurile ierarhizate juxtapuse.
Codurile de ierarhizare redau numărul maxim de operaţii, al fiecărui tip de atribut în cadrul
treptelor de ierarhizare.
Codurile juxtapuse se realizează prin concatenarea codurilor ierarhice sau secvenţiale in
vederea utilizării grupate sau utilizării individuale a atributelor codificate in raport de cerinţele statice
sau dinamice de prelucrare.
Exemplu: codificarea personalului unei unităţi economice poate avea un cod juxtapus, rezultat
din concatenare valorilor distincte ale atributelor (atelier de producţie, secţie de producţie, marcă)
d) Lungimea codurilor este dată de numărul maxim de caractere folosite de un cod. Asfel
avem:
• coduri de lungime fixă: cu aceiaşi lungime efectivă pentru toate valorile atributelor codificate
(exemplu: Codul ţărilor RO, DL, SW).
 • coduri de lungime variabilă: au lungimi diferitepentru anumite valori efective ale atributelor
(exemplu: Acronimul folosit pentru codurile societăţilor comerciale cu lungimea maximă de
caractere).
e) Modul de atribuire a codului se referă la modalitatea în care se realizează practic
codificarea: manual sau automat.
Codificarea manuală este utilizată pentru orice tip de cod şi se realizează de operatori umani
prin scrierea codurilor pe documentele primare.
Codificarea automată este utilizată numai pentru acele tipuri de coduri pentru care se poate
defini un algoritm de codificare programabil. De asemenea , această modalitate de codificare solicită
standardizarea denumirii atributelor codificate şi eventual redactarea unor programe sau rutine de
recunoaştere.
3) Realizarea codificării
Activitatea de codificare se realizează prin parcurgerea următoarelor faze:
• pregătirea activităţilor de codificare;
• codificarea atributelor bazei informaţionale;
• întocmirea nomenclatoarelor de coduri;
• întreţinerea nomenclatoarelor de coduri.
Pregătirea activităţilor de codificare presupune următoarele operaţii:
• analizarea conţinutului şi structurii bazei informaţionale în vederea stabilirii acestor atribute ca
sunt sau ar trebui codificate;
• studierea volumului atributelor codificabile, a tipului de cod utilizat, inclusiv a modului de
realizare a codificării.
În cazul unei codificării fără pregătire prealabilă, activitatea se reduce la o analiză sumară
asupra volumului de atribute. Dacă se optează pentru codificare cu pregătire prealabilă este necesară
ordonarea atributelor codificabile, analiza particularităţilor conţinutului bazei informaţionale şi alegerea
codului:
• ordonarea atributelor codificabile se poate realiza prin sortarea identificatorilor atributelor,
ceea ce presupune clasificarea atributelor pe nivele ierarhice în scopul definirii grupelor de
codificare precum şi reguli precise de introducere a acestora în baza informaţională;
• analiza particularităţilor conţinutului bazei informaţionale, presupune determinarea
dimensiunii mulţimii de codificat şi estimarea evoluţiei ulterioare. Pentru aceasta este necesară să
se precizeze responsabilităţile de gestionare a bazei informaţionale, modul de utilizare concretă a
codurilor în documente de intrare şi ieşire, frecvenţa de utilizarea, precum şi gradul de acomodare
a utilizatorilor cu sistemul de coduri propus;
• alegerea codului se face în corespondenţă cu valorile efective potenţiale ale atributelor,
metoda de introducere şi validare a codurilor, metode de codificare, costul şi timpul de realizare a
activităţii de codificare;
• codificarea este subordonată cerinţelor şi restricţiilor sistemului informatic, deoarece acesta va
stabili cerinţele de informare pe nivele ierarhice, elemente ce determină fundamental tipul, aria de
utilizare şi gradul de generalitate al codului proiectat;
• costul şi timpul de realizare a activităţii de codificare determină soluţia acelor tipuri de coduri
care implică cheltuieli reduse şi un timp minim de realizare a nomenclatoarelor de coduri;
• examinarea posibilităţii preluării în noul sistem informaţie a codurilor deja folosite, dată fiind
obişnuinţa folosirii acestor tipuri de coduri, dar şi scurtarea perioadei de implementare
experimentare a sistemului informatic proiectat.
 4.2 Proiectarea de detaliu/fizică
Proiectarea fizică a sistemelor informatice este concretizată într-un ansamblu de baze de date,
proceduri de pregătire şi introducere a datelor, actualizare şi obţinere a rezultatelor, precum şi reguli
tehnice de utilizare şi exploatare a întregului sistem.
Proiectarea fizică a sistemelor informatice este caracterizată printr-o serie de trăsături
specifice:
Alegerea sistemului optim de gestiune a datelor şi a sistemului de calcul care vor asigura
realizarea funcţionalităţii sistemului informatic definit în proiectarea logică;
Transformarea entităţilor din baza informaţională defînite în proiectarea logică, în colecţii de
date ce urmează a fi organizate în baze de date;
Proiectarea structurală şi funcţională a datelor organizate în baze de date la nivelul aplicaţiilor;
Elaborarea strategiei de definire a procedurilor de actualizare şi exploatare-listare a bazelor de
date, precum şi specificarea măsurilor de securitate şi protecţie.
Proiectarea fizică a sistemelor informatice are un caracter preponderent tehnic şi solicită un
volum mare de muncă, iar activităţile desfăşurate sunt influenţate direct de soluţia aleasă de gestiune a
colecţiilor de date, sistemul electronic de calcul şi sistemul de operare.
Proiectarea fizică implică parcurgerea următorilor paşi:
• Proiectarea fişierelor fizice şi a bazelor de date - descrierea modului în care vor fi stocate şi
accesate datele în/din memoriile secundare şi cum se va asigura controlul lor pentru a oferi o
securitate maximă.
• Proiectarea structurii sistemelor şi a programelor - se descriu programele sau modulele
acestora care să fie în strânsă concordanţă cu diagramele fluxurilor de date şi cu celelalte piese
ale documentaţiei realizate în etapele anterioare.
• Proiectarea strategiilor de prelucrare distribuită - se vor prezenta modalităţile în care
utilizatorul poate să dispună de datele şi facilităţile de prelucrare oferite de reţelele de
calculatoare.
Proiectarea fişierelor fizice şi a bazelor de date îşi propune să asigure trecerea de la descrierea
logică a datelor la una tehnică, de stocare a datelor. Totuşi, proiectarea fizică se concretizează în
specificaţii folosite ulterior de programatori şi alţi specialişti implicaţi în construirea sistemului (în
timpul implementării), prin crearea fişierelor, defînirea modurilor de organizare a acestora, precum şi a
bazelor de date.
Proiectarea fizică a fişierelor şi bazelor de date are două obiective:
1. Transpunerea relaţiilor dintr-un model de reprezentare logică a datelor într-un proiect tehnic.
Un astfel de proiect va conţine formatele sub care vor fi reprezentate atributele, modul de
grupare a acestora din una sau mai multe relaţii în una sau mai multe înregistrări fizice, alegerea
modului de organizare a fiecărui fişier cu înregistrări fizice, precum şi proiectarea metodelor de
accesare a datelor din unul sau mai multe fişiere.
2. Selectarea tehnologiilor folosite pentru stocarea datelor
Tehnologiile înclud diverse funcţii ale sistemelor de operare, numite metode de acces şi sisteme
de gestiune a bazelor de date. Fiecare tehnologie va fi specifică unei anumite arhitecturi a sistemului.
Concret activităţile din cadrul proiectării fizice sunt
1. Alegerea tipului de suport şi modalităţilor de prezentare a ieşirilor informaţionale;
2. Proiectarea machetelor de editare/vizualizare a ieşirilor;
3. Proiectarea procedurilor şi a programelor.
1. Alegerea Sistemului de Gestiune a Bazei de Date
Un sistem de Gestiune a Bazelor de Date (SGBD) este acel sistem de programe care facilitează
şi supervizează introducerea de informaţii în baza de date, actualizarea şi extragerea datelor din bază,
controlul şi autorizarea accesului la date, precum şi asigurarea unei independente între structura bazei
de date şi programele de aplicaţii.
Funcţiile mai importante ale unui Sistem de Gestiune a Bazelor de Date sunt:
1. Funcţia de descriere a datelor permite definirea structurii bazei de date cu ajutorul limbajului
de definire. Definirea datelor poate fi realizată la nivel logic, conceptual şi fizic. La nivelul acestei
funcţii se descrie multitudinea atributelor (câmpurilor) din cadrul structurii bazei de date, legăturile
dintre entităţile bazei de date sau dintre atributele aceleiaşi entităţi se definesc eventualele criterii de
validare a datelor, metodele de acces la date, aspectele referitoare la asigurarea integrităţii şi
confidenţialităţii datelor. Rezultatele acestei funcţii se vor concretiza în schema bazei de date ,
memorate în cod intern.
2. Funcţia de manipulare a datelor este cea mai complexă funcţie şi realizează următoarele
activităţi:
• Crearea (încărcarea) bazei de date;
• Adăugarea de noi înregistrări (tupluri);
• Suprimarea unor înregistrări;
• Modificarea valorilor corespunzătoare unor câmpuri;
• Căutarea, sortarea şi editarea parţială sau totală a unei înregistrări virtuale.
Funcţia de manipulare se realizează prin intermediul limbajului de manipulare a datelor.
3. Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor
utilizatorilor cu baza de date.
În cadrul realizării acestei funcţii, apar mai multe categorii de utilizatori:
• Utilizatori ,,liberi” sau conversaţionali, numiţi şi utilizatori finali, constituiţi din beneficiarii de
informaţii care folosesc limbajele de interogare a bazei de date într-o formă simplistă, sunt
neinformaticienii.
• Utilizatori programatori, care utilizează limbajele de manipulare, realizând complexe de
exploatare a bazei de date.
• Administratorul bazei de date apare ca un utilizator special şi are rol hotărâtor în ceea ce
priveşte funcţionarea optimă a întregului ansamblu.
4. Funcţia de administrare a bazei de date apare ca o funcţie complexă şi este de competenţa
administratorului bazei de date.
Esenţial este faptul ca utilizatorii au acces rapid, eventual, simultan la date
Pornind de la modelele realizate prin activitatea de analiză, se poate proiecta structura BD,
parcurgând două subactivităţi: alegerea SGBD-ului, proiectarea funcţiilor BD.
a). Alegerea SGBD-ului se face ţinând cont de două aspecte: cerinţele aplicaţiei (utilizatorului)
şi performanţele tehnice ale SGBD-ului.

Cerinţele aplicaţiei se referă la:

• volumul de date estimat a fi memorat şi prelucrat în BD;
• complexitatea problemei de rezolvat;
• ponderea şi frecvenţa operaţiilor de intrare/ieşire;
• condiţii privind protecţia datelor;
• operaţii necesare pe baza de date (încărcare/validare, actualizare, regăsire etc.)
• particularităţi ale activităţii pentru care se realizează baza de date.
• performanţele tehnice ala SGBD-ului se referă la:
• modelul de date pe care-l implementează;
• ponderea utilizării SGBD-ului pe piaţă şi tendinţa;
• configuraţia de calcul minim cerută,
 • limbajele de programare din SGBD;
• facilităţi de utilizare oferite pentru diferite categorii de utilizatori;
• limitele SGBD-ului;
• optimizări realizate de SGBD;
• facilităţi tehnice;
• lucrul cu mediul distribuit şi concurenţa de date;
• elemente de multimedia;
• elemente de CASE;
• interfeţe de comunicare;
• autodocumentarea;
• instrumente specifice oferite.
b) Proiectarea funcţiilor BD se realizează prin: proiectarea schemelor BD, proiectarea
modulelor funcţionale specializate.
Proiectarea colecţiilor de date
Se realizează pornind de la rezultatele modelării conceptuale (analiza de sistem) şi ţinând cont
de modelul de date implementat de SGBD-ul ales. Se vor proiecta schemele: conceptuală, externă
internă.
Proiectarea schemei structurale porneşte de la identificarea setului de date necesar sistemului.
Aceste date sunt apoi integrate şi structurate într-o schemă (exemplu: pentru BD relaţionale cea mai
utilizată tehnică este normalizarea).
Proiectarea schemei externe are rolul de a specifica viziunea fiecărui utilizator asupra BD.
Pentru acest lucru, din schema conceptuală se identifică datele necesare fiecărei viziuni. Datele
obţinute se structurează logic în subscheme ţinând cont de facilităţile de utilizare şi de cerinţele
utilizatorului. Schema externă devine operaţională prin construirea unor viziuni (view) cu SGBD-ul şi
acordarea drepturilor de acces. Datele într-o viziune pot proveni din una sau mai multe colecţii şi nu
ocupă spaţiul fizic.
Proiectarea schemei interne presupune stabilirea structurilor de memorare fizică a datelor şi
definirea căilor de acces la date. Acestea sunt specifice fie SGBD-ului (scheme de alocare), fie
sistemului de operare.
Proiectarea schemei interne înseamnă realizarea operaţiilor:
• estimarea spaţiului fizic pentru BD şi definirea unui model fizic de alocare (a se vedea dacă
SGBD-ul permite explicit acest lucru);
• definirea unor indecşi pentru accesul direct, după cheie, la date;
.2 Proiectarea machetelor de editare/vizualizare a ieşirilor
La proiectare trebuie să se ţină seama de o serie de consideraţii practice, cum ar fi:
• Respectarea unor cerinţe ale factorilor de decizie privind macheta situaţiei finale. O serie de
cerinţe ale conducerii finale obligă proiectantul la o anumită structurare şi machetare a situaţiilor
finale. Totodată, se are în vedere faptul că unele situaţii finale sunt destinate raporturilor externe
ale unităţii cu alte organizaţii economico-sociale.
• Restricţii tehnice. În proiectarea situaţiilor finale intervin o serie de restricţii datorate
caracteristicilor şi performanţelor tehnice ale echipamentelor periferice, şi anume:
o numărul maxim de caractere pe linie;
o numărul maxim de linii pe pagină/ecran;
o facilităţile de imprimare.
 • Elemente de eficienţă. În proiectarea situaţiilor finale nu trebuie să scape atenţiei şi aspectele
de eficienţă economică privind: reducerea tipului calculator consumat cu editarea propriu-zisă a
situaţiilor, economie de hârtie de imprimantă.
Pentru a nu irosi timp de calculator cu editarea unor situaţii finale voluminoase se recomandă
mai întâi rularea unor programe scurte care să verifice cheile de control aplicate. Numai dacă aceste
chei sunt corecte, eventual verificate şi de utilizator,se poate lansa editarea analitică a situaţiilor finale.
Programele care editează situaţii finale voluminoase trebuie prevăzute cu posibilitatea de întrerupere
sau editarea lor sub forma unui fişier ASCII sau text pe hard-disk, urmând imprimarea ulterioară a
acestui fişier, total sau parţial.
• Lizibilitate - spaţiere. Este necesar ca situaţia să fie autoexplicativă. Pentru aceasta antetul va
conţine informaţii şi coduri ce vor indica sursa de emitere a raportului, exprimând clar, sintetic,
conţinutul raportului şi perioada la care se referă. Capul de tabel, împreună cu titlul şi antetul, se
afişează pe următoarele pagini numai dacă au intervenit schimbări în cadrul caracteristicilor de
grupare faţă de prima pagină, astfel se imprimă doar numerotarea coloanelor de tabel. Totalurile
se separă de informaţiile care se repetă pe linii succesive se imprimă o singură dată.
• Utilizarea formularelor pretipărite. Aceasta implică utilizarea unei hârtii de imprimantă ce
cuprinde elemente fixe ale situaţiei finale, cum ar fi antetul, titlul, capul de tabel,o diminuare a
uzurii imprimantelor, devenind mai estetice şi mai uşor de parcurs de utilizatori.
• Utilizarea monitoarelor. Monitoarele oferă posibilitatea afişării situaţiilor finale, atât în regim
alfanumeric, cât şi în regim grafic, alegerea modului de lucru facându-se prin intermediul unor
comenzi sau comutatori. Reprezentarea informaţiilor de ieşire sub formă grafică este preferat de
factorii de decizie de pe nivelurile de conducere superioare, dat fiind gradul de sintetizare a
informaţiilor pe ecran, la proiectarea videoformatelor de ieşire se iau în considerare şi facilităţile
oferite de monitoare, şi anume:
• Regimul de lucru (defilare ecran, pagină sau linie);
• Regimul de afişare (normal, mai luminos, cu intermitenţe, invers video);
• Regimul de semnalizare sonoră (normal, semnal sonor după afişarea unui câmp).
.3 Proiectarea procedurilor şi a programelor
Se ţine cont de concepţia generală a BD, precum şi de schemele proictate anterior. În
acest sens, se proiectează:
• fluxul informaţional;
• modulele de încărcare şi manipulare a datelor;
• interfeţele specializate;
• integrarea elementelor proiectate cu organizarea şi funcţionarea BD.
Procedurile de utilizare şi interpretare sunt absolut necesare utilizatorilor finali. Ele conţin
instrucţiuni, paşi, criterii de control care uşurează utilizarea şi interpretarea informaţiilor. De obicei el
însoţesc situaţiile finale.
Proiectarea programelor
Cu etapa de proiectare a programelor se încheie procesul de construire a sistemului. urmând
apoi implementarea practică a acestuia. În cadrul analizei au fost identificate procesele elementare şi
ulterior funcţiile sistemului informatic. În cadrul proiectării, acestea se detaliază, cu tranziţia către
codul sursă, aceasta realizându-se după alegere limbajului de programare pentru implementarea
sistemului.
Pe baza cerinţelor din activităţile precedente se poate stabili necesarul de progran pentru
sistemul informatic. Pentru acest lucru se determină categoriile de programe lista programelor necesare
în sistemul informatic.
 A. Categoriile de programe necesare reprezintă o primă evaluare. Pentru a stabili aceste
categorii se au în vedere sursele de obţinere a programelor:
• componente din software-ul de bază al calculatorului;
• proceduri utile din software-ul aplicativ existent;
• interfeţe de legătură;
• programe originale.
a) Componente din software-ul de bază al calculatorului.
Proiectantul trebuie să cunoască diferite sisteme de operare în diferite versiuni, restricţiile de
exploatare şi facilităţile oferite de acestea, pentru a putea realiza un stuc comparativ. Trebuie să se ţină
cont, de asemenea, de flexibilitatea şi portabilitai: pachetelor de programe din cadrul sistemului de
operare.
Din această categorie fac parte: compilatoarele, utilitarele (shell-uri pentru manipulare fişiere şi
alte operaţii speciale, editoare de texte), SGBD-uri, biblioteci de programe (matematice, grafice, de
comunicaţie etc).
b) Proceduri utile din software-ul aplicativ existent. Din cadrul aplicaţii informatice existente se
pot selecţiona anumite module care acoperă integral sau parţial module din cadrul sistemului proiectat
în acest moment. De cele mai multe ori este necesar un proces de adaptare, în sprijinul căruia vine
tehnologia de realizare a sistemelor deschi:care prevede încă din cadrul proiectării posibilitatea de
adaptare şi refolosire a componentelor din sistem. Tehnologiile informatice de tipul abordării orientate
obiect sau inteligenţa artificială permit abordarea reutilizării modelelor conceptuale, a datelor,
cunoştinţelor sau obiectelor şi a modulelor de program. Evidenţa componentelor de mai sus utilizate în
diferite aplicaţii, analiza, compararea lor au condus la biblioteci reutilizabile în diferite aplicaţii. Acest
efort îndreaptă spre o standardizare în domeniu.
O altă direcţie de realizare a sistemelor informatice ţinând cont de software-ul existent este cea
dată de proiectarea asistată de calculator, aceasta fiind o soluţie rapidă şi foarte utilă în faza de încercări
şi testări a programelor. Pentru elaborarea propriu-zisă a programelor soluţia generatoarelor este, de
multe ori, rigidă şi cu mică portabilitate, ceea ce contravine sistemelor deschise.
c) Interfeţe de legătură. Programele existente din categoriile de mai sus pot corespunde ca
funcţionalitate pentru sistemul proiectat, dar pot fi incompatibile din punct de vedere al datelor de
intrare/ieşire, din punct de vedere al formei de prezentare sau a structurii. Pentru rezolvarea acestor
probleme se realizează interfeţele de legătură care realizează conversii şi adaptări, eventual anumite
prelucrări intermediare, parametrizări etc. Echipa de proiectanţi trebuie să evalueze efortul realizării
acestor interfeţe, care trebuie să fie mai mic decât efortul scrierii programelor corespunzătoare.
Interfeţele trebuie să valorifice fondul de programe existent şi să micşoreze efortul de programare în
proiect.
d) Programe originale. Acestea sunt create conform cerinţelor şi restricţiilor rezultate din
activităţile precedente. Elaborarea programelor se va face utilizând tehnici de programare (structurată,
modulară etc), care contribuie la creşterea eficienţei, lizibilităţii şi calităţii în activitatea de programare.
B. Lista programelor necesare în sistemul informatic este utilă, în general, pentru managerul
echipei de programatori. Această listă se poate realiza în urma analizei categoriilor de programe
necesare identificate mai sus şi a cerinţelor rezultate din celelalte faze ale proiectării.
În cadrul acestei liste se încadrează Lista programelor existente şi lista programelor de realizat.
Lista programelor existente conţine modulele de program reutilizabile în proiectul curent, din
alte surse
Lista programelor de realizat conţine programele care trebuie realizate de proiectanţi.
Programele sunt indicate aici la nivel global, eventual tipul de program necesar, urmând ca ulterior să
se detalieze
Activităţi de proiectare a programelor
A. Definirea problemei de rezolvat
Se are în vedere:
• cerinţele informaţionale ale conducerii
• cerinţele legate de evoluţie sistemului informatic.
B. Descompunerea problemei în operaţii
După cum se ştie, o problemă este o expresie logică de forma: dându-se o serie de condiţii
iniţiale, să se determine scopul. În cazul nostru este vorba de o problemă economică în care se dă o
mulţime de factori economici, o mulţime de operatori de transformare, care acţionează conform unor
criterii pentru scopul de a atinge anumite obiective.
Pe de altă parte, orice problemă este un proces ce se poate reprezenta sub forma unei secvenţe
de subprobleme, ce trebuie rezolvate. În cazul sistemelor informatice se realizează o descompunere de
la vârf spre bază (metoda top-down) până se ajunge la operaţii elementare, folosind tehnica
modularizării. Se obţine astfel, aplicând diferite criterii de descompunere, un arbore de componente.
Criteriul principal care se realizează descompunerea este cel al funcţionalităţii.
Modulele funcţionale cele mai întâlnite sunt:
• Modul director. Supraveghează, comandă (dirijează), şi controlează execuţia tuturor celorlalte
module din sistem.
• Modul de încărcare/validare date. Pentru cazul folosirii bazelor de date există posibilitatea ca
aceste module să fie realizate prin generatoare oferite de sistemul de gestiune a bazelor de date
sau prin proceduri realizate de programator.
• Modul de actualizare. Cuprinde cele trei operaţii: adăugare, modificare, ştergere pentru fiecare
colecţie de date sau obiecte.
• Modul de interogare. Cuprinde rezolvarea cererilor de regăsire instantanee (interactive),
obţinerea de liste cu rezultate intermediare sau finale, obţinerea de rapoarte finale, obţinerea de
statistici asupra datelor.
• Modul de prelucrare. Realizează prelucrări asupra înregistrărilor sau obiectelor, asupra datelor
de intrare sau de ieşire, calcule matematice. Acest modul implementează cea mai mare parte din
algoritmii sistemului informatic.
• Modul de administrare. Are funcţii utile administratorului de sistem, cum ar fi
salvări/restaurări, reorganizări, protecţie şi securitate pentru date şi obiecte. Tot aici intră
procedurile pentru diferite optimizări: accese, adresări, calcule etc.
• Cele mai des întâlnite module/proceduri operaţionale (executive) sunt:
• Proceduri prelucrative. Realizează operaţii elementare de acces, de calcul,matematice, operaţii
auxiliare, putând fi înglobate în oricare dintre modulele de mai sus dar în special în modulul de
proiectare şi în cel de interogare.
• Proceduri comunicative (de utilizare). Realizează interfaţa de utilizare printr-un dialog între
program şi utilizator. Se construiesc meniuri, videoformate sau numai simplu mesaje. Procedurile
comunicative care se realizează strict cu scopul de a realiza legături între module/proceduri se
numesc proceduri monitor. Un modul director poate conţin una sau mai multe proceduri monitor.
• Proceduri mixte. Au atât rol prelucrativ, cât şi de comunicaţie. Dat fiind caracterul operaţional
indivizibil al procedurii, cele mixte sunt mai rare.
• Rezumând, modularizarea se realizează în trei etape:
• descompunerea întregului în părţi componente;
• definirea şi conturarea modulelor (nume, tip, funcţie);
• stabilirea legăturilor între module în concordanţă cu cerinţele globale a întregului.
La nivelul bazei de date se pot proiecta:
a. Proceduri şi funcţii stocate în baza de date
 La apelul procedurilor/funcţiilor se părăseşte execuţia programului apelant (principal) se face
salt la modulul indicat (programul apelat) prin nume, se execută subprogramul, apoi se revine la
programul principal la următoarea instrucţiune de după cea de apel. Sunt proiectate următoarele
elemente: numele procedurii/funcţiei; parametrii de intrare şi de ieşire; algoritmul conţinut.
b. Pachete. Un pachet este un obiect care încorporează un set de variabile, proceduri şi funcţii.
Practic, pachetul reuneşte un ansamblu de prelucrări efectuate asupra aceluiaşi domeniu sau aceloraşi
obiecte. Se vor proiecta toate funcţiile şi proceduriile din cadrul său.
c. Script-uri declanşate la actualizarea bazei de date. Acestea se stochează în dicţionarul bazei
de date şi vor fi disponibile tuturor celor care au drept de acces la baza de date. Permite să se
implementeze reguli de gestiune complexe şi să se intensifice (măsuri suplimentare) protecţia datelor.
In Oracle poartă denumirea de triggeri.
Script-urile pot fi declanşate înainte/după inserare (after/before insert), modificare (after/before
update), ştergere (after/before delete). De asemenea, script-urile se pot rula pentru fiecare dintre
înregistrările care au fost actualizate sau o singură dată pentru un proces de actualizare.
La nivelul aplicaţiei se proiectează procesele prin identificarea:
• evenimentului declanşator, care poate fi: execuţia unei instrucţiuni, clic de mouse, apăsarea
unei taste, apariţia unei erori etc;
• tratamentului efectuat, adică acţiunea care se desfăşoară. Această acţiune se poate realiza
înainte de declanşarea evenimentului (procese de tip pre), în timpul evenimentului (procese de tip
on) sau după terminarea evenimentului (procese de tip post).
C. Documentarea pachetului de programe
Este etapa care pregăteşte toate elementele necesare realizării propriu-zise a modulelor de
program. Pe baza arborelui de structură identificat în etapa precedentă, se realizează următoarele etape:
eşalonarea în timp a realizării programelor, realizarea schemei de sistem, realizarea schemei
logice/preudocodului, realizarea specificaţiilor de programare.
a. Realizarea eşalonării în timp a realizării programelor
Graficul de eşalonare a realizării şi testării produsului program are rolul de a afecta resursele de
timp şi umane fiecărui modul, încadrându-ne într-o perioadă dată (disponibilă).
În acest sens, se porneşte de la arborele de module, completându-se pentru fiecare
modul/procedură astfel:
• se identifică modulele predecesoare şi următoare;
• se stabileşte durata de realizare;
• se stabileşte termenul de începere şi de terminare;
• se indică numărul de programatori.
Pentru alocarea de mai sus se are în vedere atât realizarea, cât şi testarea produsului program.
Pentru o realizare rapidă şi corectă se recomandă utilizarea software-ului specializat pentru
managementul proiectelor (Microsoft Project, Primavera etc.)
b .Realizarea schemei de sistem pe module
Pentru fiecare modul se construieşte o schemă de sistem, care conţine modulul de program şi
echipamentele periferice pe care acesta le accesează la citire (intrare) şi scriere (ieşire), precum şi
fişierele sau tabelele corespunzătoare.
c. Realizarea schemei logice/pseudocodului
Pentru realizarea acestei etape se parcurg următoarele activităţi:
• Precizarea operaţiunilor pe care le efectuează modulul, precum şi succesiunilor acestora.
Aceste operaţii rezultă din scopul modulului, încadrarea lui în graficul de eşalonare şi în schema
de sistem;
• Construirea setului de date de test, în funcţie de datele de intrare în modul şi de încadrarea lui
în produsul program. Datele de test trebuie să acopere toate ramurile modulului.
 • Stabilirea parametrilor de intrare /ieşire. Pentru fiecare modul se identifică parametrii de
intrare, de ieşire şi de intrare/ieşire, precizându-se tipul, lungimea şi funcţia lor.
• Elaborarea algoritmului de prelucrare pe modul se realizează pornind de algoritmii identificaţi
în activitatea de modelare a noului sistem, prin adăugarea elementelor specifice modulului,
rezultate din precizarea operaţiilor şi condiţiilor pe care le efectuează modulul. Algoritmul este
testat folosind setul de date de test identificat anterior.
• întocmirea efectivă a schemei logice / pseudocodului.
• Schema logică dă o reprezentare grafică a algoritmului prin simboluri specifice, fiind
independentă de limbajul de programare utilizat sau de calculatorul pe care va fi realizat
programul. Se utilizează tehnica programării structurate, reprezentând cele trei structuri
fundamentale de program: secvenţială, alternativă şi repetitivă.
d. Realizarea specificaţiilor de programare pe module.
Având ca bază schema de sistem şi schema logică, respectiv pseudocodul pentru un anumit
modul, se întocmesc specificaţiile de programare.

5. IMPLEMENTAREA SISTEMELOR INFORMATICE

Implementarea sistemelor informatice este o etapă a ciclului de viaţă al dezvoltării sistemelor
informatice care se regăseşte în toate metodologiile de realizare a sistemelor informatice.
Implementarea sistemului informatic este acea etapă în care se realizează efectiv trecerea de la
vechiul sistem de lucru la cel nou. Este o etapă foarte dificilă, deoarece necesită conlucrarea strânsă dintre
realizatorii sistemului informatic şi beneficiarii acestuia. Este etapa în care sistemul este supus la cea mai
dificilă testare, cea a condiţiilor reale de funcţionare. Acum pot apărea cazuri care nu au fost prevăzute de
proiectanţi, la care sistemul nu este protejat.
Implementarea sistemului constă în punerea în practică a specificaţiilor logice şi are în vedere:
• corelarea modulelor din punct de vedere al funcţiilor logice realizate (invocări, utilizări);
• crearea interferenţei dintre module conform standardelor de intrare/ieşire;
• ordinea în care modulele sunt codificate, testate şi implementate;
• calitatea datelor şi destinaţia rapoartelor;
• cerinţele fişierelor şi ale bazei de date (număr, conţinut, tipuri de date, tipuri de acces, tipuri de
înregistrări, etc.);
• ordonanţa activităţilor de implementarea, instalarea şi de instruire specifice sistemului
considerat.
În cadrul acestei etape se testează, se verifică şi se asimilează de către beneficiar toate soluţiile
stabilite în etapele anterioare şi se validează rezultatele obţinute.
Mai întâi este necesară o pregătire a mediului în care va fi implementat sistemul informatic,
ceea ce poate însemna: instruirea personalului care urmează să exploateze sistemul, asigurarea
condiţiilor organizatorice necesare funcţionării sistemului, asigurarea resurselor hardware necesare,
asigurarea fondului informaţional.
Implementarea începe în momentul în care toate componentele au fost testate individual şi
permit ansamblarea fiecărei aplicaţii şi a întregului sistem informatic. Aceste componente înglobează,
pe de o parte, procedurile manuale folosite pentru pregătirea şi testarea documentelor în vederea
prelucrării, efectuarea corecţiilor, interpretarea şi utilizarea rezultatelor, iar, pe de altă parte,
procedurile prin intermediul cărora are loc realizarea efectivă a funcţionalităţii sistemului informatic.
În timpul implementării, numeroase activităţi vor fi executate simultan. De aceea, ele trebuie să fie
planificate şi programate de către o echipă de implementare formată din utilizatori, manageri şi
specialişti în proiectarea sistemelor.
Planificarea implementarii, firesc, începe anterior demarării unei astfel de acţiuni. De fapt,
problemele implementării sunt abordate chiar la începutul proiectului, iar aspectele conceptuale şi
strategiile implementării şi conversiei sistemelor trebuie luate în discuţie în fiecare stadiu al ciclului de
viaţă al sistemelor. Totuşi, planurile detaliate de implementare nu pot fi finalizate până când
conducerea nu aprobă proiectul noului sistem.
Un plan de implementare evidenţiază toate activităţile necesare, ajutând pe cei ce-l întocmesc să
fie siguri că totul a fost prezentat corect. Prin el se vor consemna toate activităţile de efectuat, precum şi
timpul alocat. Responsabilităţile de execuţie trebuie să fie foarte clare. De asemenea, trebuie estimate
costurile fiecărei activităţi astfel încât să poată fi elaborat un buget special. În acelaşi timp trebuie
determinate reperele de execuţie în Planificarea
timp, pentru a se putea exercita controlul. Mai dificil este de estimat
momentul când se va finaliza implementarea. De fiecare dată utilizatorii sunt cei care îşi dau acceptul
implementarii
final, iar procesul, teoretic, poate fi considerat ca desfăşurându-se pe o perioadă nedefinită.
Planul de implementare este revizuit şi modificat la intervenţiile comitetului de informatizare, ale
utilizatorilor, ale conducătorilor sistemului, înainte de a începe operaţiunea de implementare.
Fazele procesului de implementare a sistemelor sunt redate în figura de mai jos :
Pregătirea
Realizarea şi locurilor de muncă; Selectarea şi
testarea instalarea şi instruirea
programelor testarea personalului
echipamentelor

Finalizarea
Testarea
documentaţi
sistemului
ei

Conversia de la
vechiul la noul
sistem
 Fig.5.1 Fazele procesului de implementare a sistemelor

5.1 Realizarea si testarea programelor

Realizarea programelor a fost descrisă în capitolul anterior, motiv pentru care nu vom descrie decât
modul de testare a programelor
Etapa de testare a sistemului are ca scop eliminarea (pe cît posibil) a erorilor şi neajunsurilor
sistemului informatic. Ea se aplică atât programelor individuale ale sistemului, cât şi sistemului în
ansamblul său (pentru testarea legăturilor între module). Metodele de testare depind atât de nivelul la
care se aplică, cât şi de tipul erorilor căutate.
Într-un sistem informatic se pot distinge următoarele tipuri de erori:
Erori de sintaxă, sunt acele tipuri de erori ce sunt detectate în faza de compilare şi sunt
datorate construcţiei greşite a unei instrucţiuni (lipsa unei paranteze, scrierea greşită a numelui unei
funcţii etc.);
Erori de rulare (de execuţie) care sunt detectate la rularea programului şi sunt datorate
folosirii incorecte a comenzilor şi funcţiilor limbajului (chiar scrise corect din punct de vedere
sintactic).
Exemple de asemenea erori sunt: folosirea unei variabile neiniţializate, încercarea de a scrie
într-o fereastră la coordonate mai mari decât dimensiunea acesteia etc.;
Erori de algoritm – programul nu generează erori nici la compilare, nici la rulare, dar
rezultatele obţinute nu sunt cele aşteptate, corecte;
 Erori de utilizare –sistemul funcţionează corect, dar utilizatorul îl foloseşte greşit.
Erorile cel mai simplu de detectat, sunt cele de compilare, ele fiind sesizate automat la
compilarea unui fişier sursă, urmează apoi erorile de rulare, care sunt de asemenea detectate şi sesizate
automat, dar la execuţia programului în cauză. La detectarea unei astfel de erori compilatorul
furnizează un mesaj de eroare care ne indică natura şi eventual cauza erorii respective, cât şi linia din
fişierul sursă în care apare. Nu întotdeauna mesajul oferit de compilator este unul explicit. De multe ori
ni se indică un mesaj de eroare, oarecum incorect, generând confuzie şi îngreunând depana-rea. Acest
lucru se datorează unor erori care sunt consecinţe ale altor erori nedetectate anterior.
Erorile de algoritm sunt mai greu de detectat decât celelalte două tipuri prezentate anterior,
datorită faptului că sistemul nu mai oferă nici un fel de mesaje de avertizare. Din punctul de vedere al
SGBD-ului, programul funcţionează corect, utilizatorul, fiind cel nemulţumit de rezultatele obţinute.
Erorile de utilizare sunt acele erori datorate folosirii incorecte a sistemului, chiar dacă el este
corect conceput. Sistemul informatic trebuie să fie cât maibine protejat contra unor astfel de erori,
adică:
să nu permită utilizatorului introducerea unor date greşite, lucru posibil prin implementarea
unor proceduri de validare cât mai performante, mai compete;
să pună la dispoziţia utilizatorului numai acele opţiunicare au sens la un moment dat
(celelalte să fie dezactivate);
să avertizeze utilizatorul în cazul detectării intenţiei de execuţie a unor operaţii suspecte a fi
greşite (cele despre care avem certitudinea că sunt greşite să nu fie permise deloc);
să ofere cât mai multe informaţii de ajutor prin intermediul unul subsistem de ajutor
permanent;
să posede o documentaţiecât mai clară, explicită, completă, la nivelul celui mai slab pregătit
utilizator etc.
Cu toate măsurile de precauţie luate de proiectant aceste erori nu pot fi eliminate complet
datorită acelor situaţii de natură subiectivă, care nu pot fi controlate în totalitatede sistem, ci se bazează,
total sau parţial, pe gândirea utilizatorului.
Un alt criteriu de clasificare a erorilor dintr-un sistem informatic este acela al nivelului la care
apar aceste erori. Din acest punct de vedere putem avea următoarele tipuri de erori:
la nivelul sistemului de operare – aceste erori se datorează configurării greşite a
sistemului de operare sau SGBD-ului, sau incompatibilităţii dintre acestea
De exemplu eroarea <prea multe fişiere deschise simultan> ţine de configurarea sistemului de
operare (DOS-ului) şi anume de stabilirea unui număr prea mic de fişiere permis a fi deschise simultan
(FILES=<n>în CONFIG. SYS);
în interiorul modulelor, programelor independente-pot fi erori de compilare, de rulare
sau de algoritm şi pot fi depistate prin rularea independentă a modului respectiv;
la nivelul sistemului de ansamblu – sunt erorile ce ţin de legătura dintre module şi se
obţin atunci când fiecare modul în parte lucrează bine, dar când modulele sunt încorporate în sistemul
integrat între ele apar incompatibilităţi;
erorile sau neajunsurile de proiectare – sunt erori ce ţin de concepţia de ansamblu a
sistemului.
Un exemplu de astfel de erori, este omiterea unui câmp la proiectarea unei baze de date, câmp
în care urmau să fie memorate date necesare sistemului.Aceste erori sunt mai mult neajunsuri ale
sistemului informatic. Ele apar mai ales la încercarea de adăugare a unei noi facilităţi sistemului, care
solicită date noi, neprevăzute la proiectare, sau care nu se potriveşte cu metodele şi tehnicile folosite în
sistem.
Efortul necesar eliminării unei erori este direct proporţional cu nivelul erorii respective. Cu
alte cuvinte, cu cât nivelul la care apare eroarea este mai ridicat, cu atât efortul de detectare şi de
înlăturare a sa este mai mare.
 Testarea este efectuată, de regulă, de personal specializat, care coordonează întreaga activitate.
La testare un rol important revine şefului echipei de programare care trebuie să integreze fiecare modul
testat separat şi apoi să testeze întregul program. Întotdeauna testarea va produce mai multe versiuni de
module şi de produse program, ultima fiind cea acceptată. La fiecare versiune se face oevaluare şi se se
operează corecţia.
Testarea nu se încheie decât atunci când se efectuează lansarea prelucrării de către întreaga
aplicaţie informatică cu un set complet de date. Acest set va include toate datele posibile, corecte şi
eronate pentru a urmări reacţia întregului pachet de programe. În această testare globală se urmăreşte:
validarea datelor de intrare şi a rezultatelor, dialogul din sistemul informatic, modul de operare la
execuţie. Se urmăresc atât aspectele formale cât şi cele de fond.
În literatura de specialitate sunt enumerate şapte categorii de teste ale softului. Acestea se
diferenţiază în funcţie de modul în care acestea angajează tehnici dinamice sau statice, precum şi în
funcţie de modul de efectuare, automat sau manual.
Testarea statică înseamnă verificarea programelor sursă fără ca acestea să fie executate, iar cea
dinamică înseamnă şi execuţia programului sursă.
Testarea automată este efectuată sub controlul calculatorului, în timp ce testarea manuală se
desfăşoară sub controlul omului.
Sintetic, cele şapte categorii de teste sunt redate în tabelul de mai jos:

Tip testare Manuală Automată

Statică Examinări Validarea sintactică
Dinamică Execuţia de probă Testarea pe componente
Verificare de birou Testarea integrităţii
Testarea sistemului

Examinările sunt activităţi prestate de grupuri de persoane cu scopul depistarii manuale a apariţiei
unor erori binecunoscute în codurile programelor sursă. Prin urmărirea atentă a instrucţiunilor programelor
sursă se depistează între 60 şi 90% dintre erorile ce pot apărea în acestea.
Execuţia de probă, spre deosebire de examinarea liniilor programelor sursă, care nu urmăreşte şi
efectul fiecărei instrucţiuni, îşi propune să descopere erorile regăsite în fiecare cod al programului sursă.
Execuţia de probă trebuie efectuată cât mai des, pe parcursul finalizării unor părţi din lucrare(program).
Rolul execuţiei de probă este de a depista, şi nu de a corecta erori.
Verificarea de birou este un proces informal, prin care programatorul sau o altă persoană care înţelege
logica programului îl parcurge, linie cu linie, cu un creion şi o foaie de hârtie. Verificarea nu presupune
neaparat şi execuţia pe calculator, ci programatorul urmăreste cu atenţie efectul fiecărei instrucţiuni a
programului.
Validarea sintactică este singura tehnică de verificare automată statică executată, de regulă, de către
compilatoare. Rolul acestora este de a scoate la iveală erorile programului sursă fără însă a-l executa.
Toate celelalte tehnici automate presupun şi execuţia codului instrucţiunilor.
Testarea pe componente este, deseori, cunoscută şi ca testarea modulelor, deoarece fiecare modul este
testat de sine stătător.
 Testarea integrităţii este o continuare a celei descrise anterior, întrucât ea se efectuează cu scopul
verificării modului în care se intercondiţionează modulele, cu alte cuvinte se testează un grup de module.
Testarea integrităţii este graduală. În primul rând, se testează modulul coordonator, adică modulul-
rădăcina dintr-o structură arborescentă, şi doar unul dintre modulele subordonate. După ce sunt testate
modulele subordonate aflate pe acelaşi nivel, se efectuează trecerea la alt nivel, inferior celui anterior. În
final, se testează tot programul. În mod similar se va proceda cu întregul sistem.
Testarea sistemului diferă de cele descrise anterior prin faptul că în locul modulelor se testează
programele. Operaţiunea este efectuată de personalul specializat în sisteme informatice, sub
coordonarea şefului de proiect, sau de către utilizatori, sub controlul specialiştilor în informatică.
După ce testele sistemului au fost încununate cu succes, sistemul este supus testării de acceptare,
într-un mediu similar celui în care va fi pus în funcţiune şi de către persoanele care îl vor întrebuinţa.
Un test complet de acceptare constă în efectuarea testării alfa şi a testării beta.
Testarea alfa utilizează date reprezentative, dar nereale, iar testarea beta se bazează pe date reale şi
se execută în mediul curent, concret de lucru al utilizatorului.
Testarea alfa, cuprinde câteva teste edificatoare, dupa cum urmează :
• testarea regenerării sau refacerii forţeaza execuţia softului astfel încât să înregistreze eşecuri
pentru a se verifica modul în care sistemul revine la normal ;
• testarea securităţii verifică dacă mecanismele de protecţie aflate în sistem acţionează
corespunzator împotriva posibilelor atacuri ;
• testarea la suprasolicitări determină modul în care sistemul execută operaţiunile în condiţii de
lucru diferite (cu configuraţii de echipamente variate, cu anumite reţele, sisteme de operare ş.a.).
Testarea beta se derulează cu exerciţii proprii utilizatorilor şi cu datele
concrete ale acestora. Ea este un fel de repetiţie generală înaintea instalării.
Posibilele erori ale softului se pot datora :
• incorectei contorizări a numărului de execuţii ale unor bucle ;
• introducerii incomplete a datelor ;
• realizării unor interfeţe eronate între module;
• depăşirii dimensiunilor unor tablouri(masive) de date ş.a.
Pentru aprecierea calităţii softului s-au propus mai mulţi indicatori :
• rata defectelor pe oră, zi, săptamână sau lună ;
• rata defectelor pe echipamentele de bază ale softului;
• timpul mediu între două defecţiuni;
• mărimea zonei afectate de defecte;
• numărul compilărilor sau al execuţiilor unor componente ale sistemului care funcţionează
corect din prima încercare ;
• defecte cumulate pe versiune;
• oportunitatea răspunsului la defecte sau a timpului afectat îndepărtării lor ;
• satisfacţia beneficiarului privind calitatea intervenţiei pentru remedierea defectelor soft.
Din toate aceste modalităţi de evaluare, cantitativă şi calitativă, rezultă că preocupările pentru
utilizarea unui soft de calitate trebuie să existe la toate nivelurile ierarhice ale organizaţiei.

5.2 Instalarea sistemului

Această fază asigură verificarea funcţionalităţii sistemului cu date reale, motiv pentru care se
pot folosi anumite tactici şi strategii în funcţie de succesiunea de implementare a componentelor
noului sistem.
Strategiile de implementare presupun compararea vechiului sistem cu cel proiectat sau cu un
alt sistem informatic luat drept etalon. În funcţie de aceste elemente funcţionarea experimentală poate
funcţiona în cinci variante.
1) Implementarea directă cu date curente a sistemului proiectat, presupune renunţarea la
vechiul sistem brusc, în vederea reducerii termenului şi a minimizării cheltuielilor cu implementarea.
Avantajele acestei metode sunt costul mai scăzut şi o certitudine a implementării, în schimb riscurile
sunt mai mari, datorită faptului că activitatea sistemului economic se bazează acum pe sistemul
informatic, iar o defecţiune în acesta din urmă putând duce la blocarea activităţii. De aceea această
strategie nu se recomandă în cazul activităţilor critice, în flux continuu, care nu suportă întârzieri.

Vechiul sistem
Noul sistem
2) Implementarea paralelă se face cu date curente sau anterioare pentru a se realiza o
comparaţie între sistemul vechi faţă de cel nou, sau între noul sistem şi sistemul etalon. Această
strategie asigură un risc minim pentru beneficiar, deoarece eventualele neajunsuri în funcţionarea
sistemului informatic nu conduc la blocarea activităţii din unitatea economică, în schimb este foarte
costisitoare, toacmai datorită faptului că, pentru o perioadă de timp trebuie suportate costurile
funcţionării ambelor sisteme.

Perioada de
implementare

Veciul sistem
Noul sistem

1) Implementarea pilotată urmăreşte lansarea în experimentare a sistemului proiectat începând

cu acele subsisteme ce au frecvenţă maximă de utilizare, folosindu-se date din perioade anterioare şi
curente. Sistemul informatic se instalează pe o unitate pilot, mai mică decât cea reală, dar care are
caracteristicile definitorii ale acesteia. Această strategie se încadrează între cele două anterioare, atât
din unctul de vedere al costurilor, cât şi al riscurilor.

Unitate pilot
 Veciul sistem
Noul sistem
4) Implementarea compartimentală este utilizabilă în unităţile economice în care
structurile organizatorice prezintă autonomie prin prisma fluxurilor informaţionale.
În această variantă condiţia esenţială o constituie realizarea anterioară a proiectării de ansamblu
şi a celei de detaliu pe compartimente, caz în care rezultatele implementării pot fi comensurate direct
pe structurile organizatorice implicate.
5) Implementarea combinată poate fi abordată datorită avantajelor pe care le prezintă
celelalte variante prin folosirea implementării paralele cu cea pilotată.
Alegerea strategiei de implementare depinde de natura activităţii desfăşurate în sistemul
informatizat, de disponibilitaăţile materiale ale beneficiarului, de riscurile ce pot şi se acceptă a fi
asumate de beneficiar etc.

5.3. Verificarea performanţelor sistemului informatic proiectat

Această fază presupune exploatarea efectivă a sistemului cu date reale în vederea îndeplinirii
parametrilor proiectaţi, a termenelor de execuţie şi duratei de exploatare.
În finalul acestei faze se face evaluarea sistemului şi validarea rezultatelor obţinute, pentru a
verifica în ce măsură sunt satisfăcute obiectivele propuse şi dacă rezultatele noului sistem justifică
cheltuielile făcute cu introducerea şi realizarea lui.
Funcţionarea sistemului depinde de specificaţiile logice, care evidenţiază anumite aspecte de
natură logică ale funcţiilor sistemului (legături între intrări şi ieşiri, consideraţii asupra volumului de
date şi a frexvenţei lor, decizii de actualizare şi de întreţinere, modul de operare), precum şi de
specificaţiile fizice care în mod cert sunt mai importante pentru operatori.
Interpreterea şi transpunerea corectă a specificaţiilor logice pot să conducă la îndeplinirea
aşteptărilor scontate pentru viitor, în ciclul de viaţă al noului sistem, referitoare la întreţinere, noile
interfaţe lae sistemului, realocarea de funcţii în cadrul firmei etc, îsoţite de reorganizarea
corespunzătoare de personal calificat.
Evaluarea sistemului se face pe baza specificaţiilor logice şi fizice. Specificaţiile fizice au în
vedere volumul, frecvenţa, acurateţea, şi eroarea informaţiilor. Specificaţiile logice conţin rareori
indicatori necesari pentru evaluarea sistemului, însă arată modul în care sunt corelate elementele
resursei de informare şi evidenţiază unde şi când funcţionează aceste legături.
De exemplu, dacă specificaţiile logice arată că prelucrarea poate să înceapă numai după ce s-a
strâns un număr suficient de mare de facturi, acest fapt ne ajută să observăm cât de bine este satisfăcut
acest criteriu şi când este rezonabilă testarea pentru prelucrarea facturilor.
De asemenea, detaliile legăturilor logice, cum ar fi succesiunea de intrări-ieşiri sau de invocări
de module, ne ajută să descoperim de unde provine ineficienţa.
Pe baza datelor provenite din exploaterea sistemului informatic, se determină eficienţa
economică şi se cuantifică raportul între performanţă şi cost.
Indicatorii eficienţei economice se calculează în toate etapele de realizare a sistemului
informatic, acordându-se o atenţie deosebită la sfârşitul primului an de exploatare efectivă.
În etapa de implementare se corectează indicatorii eficienţei economice estimaţi, în timp ce în
etapa de exploatare efectivă se calculează eficienţa economică reală pe baza rezultatelor obţinute de
unitatea beneficiară.

5.4. Elaborarea documentaţiei de utilizare a sistemului informatic proiectat.

 În funcţie de modul de implementare a sistemului, pot apare anumite modificări în concepţia
acestuia, ca urmare a unor neajunsuri semnalate. Aceste modificări trebuie operate în structura
sistemului proiectat şi în documentaţia acestuia pentru a evita eventualele dificultăţi în exploatarea şi
întreţinerea ulterioară.
La terminarea fiecărei faze de dezvoltare a proiectului, liderul de proiect redactează un raport
care detaliază activităţile, constatările şi rezultatele acelei faze, precum şi planurile pentru fazele
următoare, document ce va fi supus spre avizare de către beneficiar.
Documentaţia se elaborează la momente specifice în timpul realizării proiectului, fie ca
urmare a directivelor utilizate, care în general sunt proceduri bazate pe documentaţie.
Definitivarea întregii documentaţii de utilizare şi exploatare a sistemului se concretizează în
întocmirea manualului de prezentare, utilizare şi operare.
Manualul de prezentare cuprinde concepţia generală a sistemului şi o prezentare succintă a
aplicaţiilor componente, făcându-se precizări în legătură cu restricţiile şi limitele sistemului sau
aplicaţiilor, inclusiv performanţele şi posibilităţile de extindere a acestora.
Manualul de utilizare este întocmit pentru fiecare aplicaţie, şi asigură descrierea generală a
aplicaţiei, datele de intrare, condiţiile de validare, restricţiile şi erorile ce pot apare, condiţiile de
reluare, şi se adresează personalului implicat în utilizarea noului sistem.
Manualul de operare conţine informaţii referitoare la exploatarea efectivă a sistemului
proiectat prin intermediul sistemului de calcul.

6. EXPLOATAREA ŞI ÎNTREŢINEREA SISTEMULUI INFORMATIC

6.1 Exploatarea sistemului informatic
După ce implementarea a luat sfârşit, începe etapa de exploatare şi întreţinere a sistemului
informatic. Acum sistemul informatic funcţionează la parametri normali prevăzuţi de proiectanţi.
Activitatea de exploatare se reduce la execuţia curentă a operaţiilor de culegere a datelor, transmitere,
validare şi prelucrare a acestora, construirea şi consultarea situaţiilor de informare-raportare.
Exploatarea curentă şi menţinerea în funcţiune a sistemului informatic presupun punerea în
stare operaţională a calculatorului şi a perifericelor, după care se continuă cu următoarele operaţii:
• restaurarea bibliotecilor de programe şi a bazei de date specifice noului sistem de pe copiile de
siguranţă obţinute la prelucrarea precedentă;
• lansarea în execuţie a programelor pentru crearea şi actualizarea bazelor de date, obţinerea
listelor de control şi eliminarea erorilor;
• exploatarea bazei de date în vederea obţinerii situaţiilor de ieşire;
 • verificarea corectitudinii rezultatelor obţinute prin control de verosimilitate sau sondaj;
• stocarea pe dischete a ultimei versiuni a bazei de date în vederea conservării acestora până la
prelucrarea următoare.
În funcţie de experienţa dobândită în perioada exploatării noului sistem şi de rezultatele
obţinute ca urmare a informatizării activităţii unităţii beneficiare se pot efectua reorganizări în structura
serviciilor funcţionale, prin trecerea anumitor activităţi dintr-un compartiment într-altul, reconsiderarea
unor centre de decizie etc.
Exploatarea curentă şi menţinerea în funcţiune a sistemelor informatice, asigură funcţionarea
acestuia pe toată durata lui de execuţie. Ea încetează în situaţia în care se renunţă la sistemul existent în
funcţiune pentru a se trece la utilizarea altui sistem mai evoluat şi eficient.

6.2 Procesul de întreţinere a sistemelor informatice

Din totalul cheltuielilor generate de sistemele informaţionale ale unităţilor, cea mai mare parte
revine etapei de întreţinere, şi ca atare, personalul antrenat în întreţinere este cel mai numeros.
Întreţinerea începe odată cu instalarea sistemului şi se referă nu numai la echipamente, ci şi la software
şi la procedurile economice utilizate pe timpul exploatării aplicaţiilor din sistem.
Întreţinerea sistemului informatic constă în totalul activităţilor desfăşurate pentru asigurarea
funcţionării sistemului la parametri normali, corectarea, eliminarea tuturor erorilor care apar pe parcurs,
dar şi introducerea în sistem a unor îmbunătăţiri, perfecţionări, modernizări etc., menite să crească
nivelul parametrilor de funcţionare ai sistemului economic.
Un aspect important se referă la durata etapei de întreţinere, după unele păreri ar fi de 5 ani,
după altele 10 sau mai mulţi. Răspunsul poate varia de la un caz la altul, tendinţa fiind de creştere a
perioadei de întreţinere şi implicit a costurilor aferente.
Pe timpul întreţinerii un grup de persoane se va ocupa de colectarea cererilor de întreţinere
lansate de utilizatori sau de alte părţi implicate în exploatarea sistemului sau verificarea modului în care
acesta funcţionează. Activităţile implicate de întreţinerea sistemului sunt:
• obţinerea cererilor de întreţinere;
• transformarea cererilor în propuneri de schimbări;
• proiectarea schimbărilor;
• implementarea schimbărilor.
Perfecţionarea sistemului informatic presupune:
• folosirea de tehnică de calcul care să permită înregistrarea directă a datelor de intrare la locul
şi-n momentul producerii lor;
• perfecţionarea sistemului de operare prin optimizarea programelor şi a tehnicii de operare;
• optimizarea şi parametrizarea programelor care să asigure portabilitatea acestora;
• utilizarea reţelelor de calculatoare pentru realizarea obiectivelor din unitatea economică
beneficiară.
 Întrucât cheltuielile de întreţinere au o pondere substanţială în structura costurilor totale ale
sistemelor, considerăm relevantă prezentarea tipurilor de întreţinere: corectivă, adaptativă, perfectivă,
conform fig.

12% 5%
Adaptiva
8%
Perfectiva
Preventiva
Corectiva
75%

Întreţinerea corectivă constă în efectuarea unor lucrări de reparaţii pentru îndepărtarea unor
defecte produse în timpul proiectării, scrierii programelor sau implementării sistemului. În majoritatea
cazurilor, întreţinerea corectivă intervine imediat ce se pune în funcţiune noul sistem sau o componentă
a acestuia. Cât timp o astfel de întreţinere îşi propune doar să îndepărteze defecte, ea nu adaugă valoare
decât într-o pondere derizorie, în pofida celor 75 de procente alocate întreţinerilor corective din totalul
activitătilor de întreţinere a sistemului.
Întreţinerea adaptativă presupune efectuarea unor schimbări în sistem, condiţionate de: intenţia
de îmbunătăţire a performanţelor funcţionale; adaptarea la schimbările organizaţionale; deplasarea
sferei de activitate a unităţii în alt mediu.
Dacă întreţinerea corectivă presupune o intervenţie cât mai urgentă în urma sesizărilor venite
din sistem, cea adaptivă nu este la fel de presantă, întrucât factorii care o condiţionează nu au apariţii
spontane. O altă diferenţă constă în faptul că întreţinerea adaptivă, spre deosebire de cea corectivă,
adaugă valoare organizaţiei.
Întreţinerea perfectivă are ca scop efectuarea unor schimbări pentru îmbunătăţirea diverselor
prelucrări, modificarea cu scopul folosirii mai uşoare a interfeţelor sau pentru a i se adăuga noi
elemente, care însă nu sunt strict necesare. O astfel de operaţiune de întreţinere constituie mai curând o
dezvoltare a sistemului şi face parte din categoria activităţilor care adaugă valoare organizaţiei.
Întreţinerea preventivă se efectuează cu scopul diminuării substanţiale a posibilităţilor de
defectare a sistemului, adaugă valoare organizaţiei.
Costurile mentenanţei unui sistem sunt influenţate de câteva elemente principale:
• în fazele de evaluare / proiectare nu pot fi luate în considerare toate scenariile privind
funcţionarea sistemului;
• un sistem mare este proiectat şi implementat de către mai multe echipe, în perioade diferite,
ceea ce implică o bună coordonare a activităţii lor şi poate conduce la generarea unor soluţii a
căror integrare ridică uneori probleme în timpul exploatării;
• dezvoltarea unui sistem informatic este un proces de durată şi pe parcursul proiectării şi
implementării pot să apară modificări majore în ceea ce priveşte : legislaţia, performanţele
 echipamentelor şi produselor programului, orientarea activităţii organizaţiei, forma de
proprietate, strategia managerială;
• personalul care deserveşte sistemul, câştigă experienţă şi înţelege din ce în ce mai bine ce ar
trebui să facă, uneori în opoziţie cu ce face.
Activitatea de mentenanţă trebuie evaluată pentru a observa dacă, la un moment dat, cheltuielile
implicate nu depăşesc limitele acceptabile. Dacă la un moment dat se constată că beneficiarele sunt
puternic afectate de cheltuielile cu mentenanţa, se poate concluziona că sistemul nu mai răspunde
necesităţilor şi este necesară înlocuirea sa parţială sau totală. În felul acesta se reia ciclul de viaţă al
dezvoltării sistemului.
6.3 Documentaţia necesară exploatării şi întreţinerii sistemului informatic
Exploatarea noului sistem informatic se va realiza conform instrucţiunilor de exploatare
prevăzute în manualul de utilizare. Aceste instrucţiuni se adresează în principal utilizatorilor finali,
adică beneficiarilor propriu-zişi ai sistemului informatic şi pot fi completate cu procedurile de
autodocumentare cuprinse în produsul program.
Manualul de utilizare şi exploatare cuprinde următoarele instrucţiuni de utilizare şi exploatare:
Instrucţiuni de utilizare
- proceduri de codificare a datelor prin care se dau instrucţiuni despre modul de întocmire a
codurilor. Aici se explică sistemul de codificare utilizat şi structura codurilor. De asemenea se
precizează criteriile de validare pentru fiecare cod şi eventualele codificări automate pe care le face
sistemul;
- proceduri de încărcare/validare date, prin care se dau instrucţiuni despre popularea colecţiilor
de date. Aici se precizează documentele primare din care se preiau datelor şi modul de completare al
acestora. Prin comparaţie se prezintă machetele de intrare şi videoformatele aferente documentelor
primare. Se precizează şi corelaţiile care trebuie să eyxiste între diferitele date încărcate. Toate aceste
instrucţiuni sunt utile utilizatorului pentru actualizarea datelor din colecţiile de date. Pentru alegerea
colecţiei de date pe care se va lucra, precum şi a operaţiei care se va efectua, utilizare a sistemului de
meniuri oferit de produsul program;
- proceduri de obţinere a situaţiilor de ieşire, prin care se dau instrucţiuni despre modul de
afişare şi interpretare a rapoartelor, listelor etc. Se prezintă pentru fiecare situaţie de ieşire macheta,
conţinutul, periodicitatea de obţinere şi se dau exemple. Instruţiunile vizează nu numai modul de
obţinere a situaţiilor de ieşire, dar şi interpretarea acestora. Se precizează semnificaţia datelor conţinute
în situaţia de ieşire şi eventualele corelaţii dintre date şi cheile de control.. În final se indică modul de
difuzare şi arhivare a situaţiilor de ieşire;
- alte proceduri speciale prin care se dau instrucţiuni despre eventualel conversii, interfeţe,
comunicaţii cerute de produsul program.
Instrucţiuni de exploatare
- eşalonarea în timp a procedurilor utilizate. Rezultatul este un grafic de exploatare a
procedurilor care trebuie să semene cât mai mult cu sistemul de meniuri al produsului program.
Ambele trebuie să ghideze utilizatorul în exploatarea produsului program: ordines operaţiilor,
succesiunea lor în timp, semnificaţia lor etc.
- proceduri privind datele de intrare. Se dau instrucţiuni privind primirea, controlul, restituirea şi
păstrarea documentelor din care se preiau datele de intrare. De asemenea, se indică modul de pregătire
a datelor de intrare pentru încărcare: reguli de încărcare, de validare, de verificare.
Proceduri de asamblare lucrări. Se dă o listă a procedurilor automate şi se dau legăturile dintre
acestea. Se ajunge astfel la o schemă funcţională a procedurilor. Schema va oferi variante de prelucrare
şi va indica facilităţi şi restricţii de exploatare a produsului program.
Proceduri de operare. Se dau instrucţiuni privind pregătirea rulării şi apelului produsului
program (mod de apel şi ieşire, parolă de acces, fişiere necesare etc). Se indică o listă a mesajelor
apărute la exploatare, precum şi modul de acţiune al utilizatorului(răspunsuri, reluări etc). Se dau
indicaţii privind operarea cu sistemul de meniuri, cu videoformatele şi ferestrele produsului program.
Proceduri privind situaţiile de ieşire. Se dau instrucţiuni privind obţinerea rezultatului şi
controlul de formă şi fond. Se indică numărul de exemplare necesare şi suportul tehnic de informaţie pe
care se va obţine fiecare situaţie de ieşire. Se specifică destinaţia şi modul de arhivare a rapoartelor.
Întreţinerea sistemului informatic va avea la bază documentaţia întocmită în fiecare fază de
realizare a acestuia. Documentaţia astfel realizată va constitui, pe de o parte, un mijloc de comunicare
între diferitele categorii de personal de specialitate în informatică antrenate în realizarea diferitelor
etape de proiectare a sistemului, iar pe de altă parte, după implementarea acestuia va constitui suportul
necesar întreţinerii sistemului de la specificaţia de cerinţe până la planul de test şi testarea finală a
acestuia, dintre care amintim:
Specificaţiile de cerinţe ale sistemului;
Arhitectura generală a sistemului cu evidenţierea intrărilor, procedurilor de control şi validare a
datelor, colecţiile de date, procedurile de editare a situaţiilor de informare/raportare, ieşirile sistemului,
resursele hardware/software folosite etc.;
Arhitectura programelor şi schemelor logice de realizare a fiecărui program;
Videoformatele de intrare/ieşire;
Programele sursă, listate şi comentate;
Specificaţiile de validare a datelor care descriu cum fiecare program e validat şi cum se leagă
informaţiile de validare cu cerinţele informaţionale ale utilizatorilor;
Un ghid de întreţinere de sistem care descrie care părţi din sistem depind de hardware şi care de
software.
 7. PROIECTAREA ORIENTATĂ OBIECT A SISTEMELOR INFORMATICE

7.1 Concepte utilizate în abordarea obiectualăa proiectării sistemelor informatice

Dintre conceptele care stau la baza modelării orientată obiect cele mai importante sunt:
 obiectul;
 încapsularea;
 persistenţa;
 tipul;
 clasa;
 moştenirea;
 polimorfismul;
  identitatea.
Obiectul
Obiectul este o abstractizare a entităţii lumii reale şi se caracterizează prin:
• stare;
• comportament.
Starea unui obiect este definită de valorile atributelor sale. Un atribut este definit printr-un
nume şi poate lua valori elementare (numeric, alfanumeric, etc.) sau complexe (structuri de multiple
referinţe spre alte obiecte, tipuri utilizatori etc.). Comportamentul unui obiect este definit de setul de
operaţii şi metode aplicabile obiectului respectiv.
Fiecare obiect are un nume care coincide, de obicei, cu numele entităţii reprezentate. Metodele
şi atributele nu sunt vizibile din exteriorul obiectului.
Un obiect răspunde la mesaje. Mesajul este unitatea de comunicaţie dintre obiecte. Mesajele
cuprind: numele mesajului, numele obiectului ţintă şi argumentele necesare, dacă există. Când un
obiect primeşte un mesaj una din procedurile sale este apelată. Procedura realizează apoi o operaţie
care poate returna un rezultat. Mesajele sunt implementate prin intermediul metodelor.
Încapsularea
Încapsularea constă în capacitatea obiectelor de a conţine la un loc atât date cât şi operaţii dintre
care numai o parte sunt vizibile din exterior.
Un obiect este compus din două părţi:
• interfaţa – permite unui utilizator extern să solicite obiectului executarea unei acţiuni;
• o parte ascunsă, de implementare – reprezentată de starea internă şi de metodele obiectului.
Încapsularea ascunde utilizatorului complexitatea unui obiect, oferind o imagine simplificată
care îi permite să rezolve mai uşor problemele complexe.
Persistenţa
Persistenţa este proprietatea obiectelor care determină existenţa mai îndelungată a acestora faţă
de procesul care le-a creat; este proprietatea prin care starea bazei de date asigură execuţia unui proces
pentru a fi refolosit ulterior în alt proces.
Tipul
Tipul sintetizează elementele comune ale unui set de obiecte cu aceleaşi caracteristici.
Tipul abstract de date are două componente:
• interfaţa – este vizibilă utilizatorului şi constă într-o listă de operaţii
• implementarea – presupune descrierea structurii interne a datelor obiectului şi realizarea
procedurilor de implementare a operaţiilor interfeţei.
Clasa
Noţiunea de clasă are aceeaşi semnificaţie cu cea de tip, însă este deosebită de aceasta, prin
faptul că este asociată cu faza de execuţie. O clasă este un tip abstract de date care defineşte atât
structura obiectelor din clasa respectivă, cât şi mulţimea metodelor existente pentru aceste obiecte.
Obiectele din aceeaşi clasă au aceleaşi atribute şi aceleaşi metode şi răspund la acelaşi mesaj.
Clasele sunt organizate ierarhic. Orice subclasă moşteneşte metodele şi structura clasei din care
face parte.
Moştenirea
Moştenirea este procesul prin care toate atributele şi metodele unei clase sunt preluate de o altă
clasă înrudită, numită subclasă. Clasa de la care atributele şi metodele sunt moştenite se numeşte
supraclasă.
 Prin intermediul moştenirii se pot exprima relaţii deosebit de utile între clase: clasificarea,
generalizare, specializare.
Moştenirea poate fi implementată:
• static – presupune concatenarea câmpurilor moştenite în clasele respective;
• dinamic – presupune parcurgerea legăturilor de moştenire şi se realizează fără recopierea
câmpurilor moştenite.
Polimorfism
Polimorfismul semnifică posibilitatea unui obiect, instanţă a unei clase, să răspundă diferit la
primirea aceluiaşi mesaj.
Polimorfismul se poate asigura prin două căi:
• redefinirea metodelor moştenite în clasele derivate;
• crearea unor metode cu acelaşi nume dar cu parametrii deferiţi.
Identitatea
Identitatea unui obiect este proprietatea acestuia care îl distinge de alte obiecte. Astfel, spre
deosebire de modelul relaţional în care datele sunt identificate prin valori ale cheii primare desemnate
de utilizator, în modelul orientat obiect identificarea obiectelor este asigurată automat de sistem şi este
transparentă utilizatorului.
Două obiecte a şi b sunt identice dacă au acelaşi identificator, adică egalitatea obiectelor este de
fapt o egalitate de pointeri (se scrie a = b).
Două obiecte sunt egale dacă au aceleaşi valori (a = b). Aşadar
a = = b implică a = b, reciproca este falsă

7.2 Nivele de modelare în proiectarea orientată obiect

Un model orientat obiect are la bază obiecte. Un obiect încapsulează atât date cât şi
comportament, ceea ce înseamnă că analistul poate folosi abordarea orientată obiect atât pentru
modelarea datelor, cât şi pentru modelarea proceselor. Pentru că permite analistului de sistem să
surprindă ambele aspecte într-o singură reprezentare şi pentru că oferă şi alte beneficii, cum ar fi
mecanismul moştenirii şi reutilizarea codului, modelarea orientată obiect oferă un mediu puternic
pentru dezvoltarea sistemelor complexe. Teoria obiectelor, încapsularea, moştenirea şi polimorfismul
stau la baza dezvoltării obiectuale a sistemelor.
Referitor la consistenţa modelelor, în alte abordări - cum ar fi analiza şi proiectarea -,
structurată - modelele care se dezvoltă nu folosesc notaţii comune şi sunt slab conectate între ele,
tranziţia de la un model la altul făcându-se în mod abrupt. Abordarea orientată obiect oferă continuitate
în ceea ce priveşte tranziţia între modelele analizei, proiectării şi ale implementării. De exemplu,
trecerea de la analiza orientată obiect la proiectarea orientată obiect presupune îmbogăţirea modelului
de analiză cu detalii referitoare implementare şi nu dezvoltarea unui nou model.
Modelarea domeniului (mediului) - Domain Model
Pentru a aprofunda înţelegerea contextului în care va funcţiona sistemul se utilizează modelul
mediului (domeniului). Acest model cuprinde cele mai importante clase întâlnite în domeniul economic
pentru care se realizează sistemul informatic şi are un caracter de generalitate. Clasele se identifică fie
din cerinţele exprimate de beneficiar, fie din intervievarea unor experţi în domeniu. Este unul dintre
primele modele utilizate n analiza orientată obiect şi are menirea de a sistematiza expertiza din
domeniul analizat şi a o transmite sistemului informatic ce urmează a fi proiectat.
Sunt trei tipuri de clase care pot fi puse în evidenţă în acest model:
• clase ce modelează obiecte sau concepte utilizate în cadrul sistemului informaţional analizat,
cum ar fi comandă, contract, factură;
 • obiecte sau concepte din lumea reală pe care sistemul trebuie să le înregistreze şi să ţină cont
de ele, cum ar fi cursul de schimb al monedei de referinţă;
• evenimente ce intervin şi afectează starea sistemului, cum ar fi plasarea unei comenzi, plata
unei facturi.
Pentru descrierea acestui model vom utiliza preponderent diagrama claselor, dintre
instrumentele puse la dispoziţie de UML.
Scopul principal al acestui model este înţelegerea contextului sistemului. De aceea la
realizarea modelului mediului (domeniului) este de preferat si participe atât specialişti în modelare,
cât şi experţi din domeniul analizat. Din acest punct de vedere se remarcă asemănarea cu etapa de
analiză specifică metodologiilor structurate Aşa cum ştim deja, conform unui vechi principiu al analizei
sistemelor, în acest proces este de preferat să fie implicaţi cei mai buni specialişti în domeniu
(experţii). Modelul mediului va conţine cele mai importante clase ale domeniului. Odată cu întocmirea
diagramei claselor se întocmeşte şi un dicţionar al claselor în care se va preciza semnificaţia fiecărei
clase pentru a se folosi o terminologie unitară. Se preferă această formulă pentru a se evita obţinerea
unui model prea mare şi greu de utilizat.
Modelul mediului, format din diagrama claselor domeniului şi dicţionarul de termeni, poate fi
utilizat atât la dezvoltarea modelului cazurilor de utilizare, cât şi la identificarea claselor sistemului în
etapa de analiză.
Modelarea proceselor afacerii (prelucrărilor) - Business Model
Aceasta este o tehnică de modelare utilizată pentru a aprofunda înţelegerea proceselor specifice
unei organizaţii. Utilizând UML, modelarea afacerii se poate face din două perspective: fie prin
modelul cazurilor de utilizare, fie prin modelul obiectelor.
În cadrul modelării cazurilor de utilizare (business use-case model) se surprinde funcţionarea
sistemului din perspectiva utilizatorilor acestuia.
Modelul obiectelor (business-object model) surprinde prelucrările din interiorul sistemului.
Descrie în detaliu cum este tratat fiecare caz de utilizare. Realizarea cazurilor de utilizare se poate
evidenţia cu ajutorul diagramelor de interacţiune (diagrama de secvenţă, diagrama de colaborare) sau al
diagramei de activitate.
O entitate a sistemului existent (a afacerii) reprezintă un lucru pe care utilizatori, accesează,
consultă, manipulează, realizează sau utilizează în cadrul unui caz de utilizări. O unitate de lucru este
un set de astfel de entităţi care formează un întreg pentru utilizatorul final. Entităţile şi unităţile de lucru
sunt utilizate pentru a reprezenta aceleaşi concepte ca şi clasele din modelul mediului (comandă,
produs, factură, cont).
Fiecare utilizator, entitate sau unitate de lucru poate participa la realizarea mai multor cazuri de
utilizare.
Un astfel de model se dezvoltă în doi paşi:
• Realizarea modelului cazurilor de utilizare
• Detalierea modelului prin specificarea utilizatorilor, entităţilor şi a unităţilor lucru, dar şi a
regulilor care guvernează anumite procese sau obiecte.
Scopul este crearea unor utilizatori, entităţi şi unităţi de lucru care să rezolve problema
evidenţiată de cazul de utilizare, eficient - bine, rapid şi la cel mai scăzut cost posibil.
Modelarea mediului şi modelarea afacerii par întrucâtva asemănătoare, mai ale dacă ne
gândim că entităţile şi unităţile de lucru corespund claselor din modelul mediu.
Cele două abordări diferă în primul rând prin modul de documentare. Una se bazează pe
cunoştinţele unui expert în domeniu sau pe cunoştinţele despre sisteme similare, în timp ce a doua are
în vedere cerinţele beneficiarului. Orice clasă a modelului domeniului îşi regăseşte originea în
experienţa cunoscătorilor domeniului. Orice element al modelului afacerii (entitate sau unitate de lucru)
îşi regăseşte originea într-o cerinţă a beneficiarului. Acesta este şi motivul principal pentru care
utilizând cele două abordări, în mod normal, se obţin clase, atribute, metode şi asocieri diferite.
O altă deosebire ar fi că pornind de la analiza domeniului vom obţine mai multe informaţii
despre atributele claselor şi mai puţine despre comportamentul acestora
Evident, în cazul modelării afacerii se vor identifica atât entităţile şi unităţile de lucru
(clasele), cât şi utilizatorii (şi operaţiile pe care aceştia le întreprind).
Şi nu în cele din urmă, modelul afacerii fiind mult mai detaliat, va fi mai bine valorificat în
etapele ce vor urma. Se pot identifica mai bine actorii şi cazurile de utilizare ale sistemului proiectat, şi
fiecare dintre acestea va putea fi mai bine pus în corespondenţă cu cerinţele sistemului.
Dacă modelul mediului abordează cu precădere funcţionarea sistemului în contextul acestuia,
modelul afacerii îşi focalizează atenţia asupra utilizatorilor şi a modului cum sistemul îi deserveşte.
Modelarea cazurilor de utilizare
Un model al cazurilor de utilizare este format din actori şi cazuri de utilizare
Un actor este o entitate externă ce interacţionează cu sistemul (similar unei entităţi externe
dintr-o diagramă de flux a datelor). Actorul este ceva sau cineva care schimbă informaţie cu sistemul.
Un actor nu este obligatoriu să fie un utilizator uman. El poate fi şi un alt sistem sau un dispozitiv
hardware (exemplu, monitorul) cu care sistemul nostru interacţionează sau schimbă informaţii.
Un caz de utilizare este o secvenţă de acţiuni iniţiate de un actor, surprinzând un anumit mod de
a folosi sistemul. Nu trebuie făcută confuzie între actor al sistemului şi utilizator al sistemului. Un
utilizator este oricine foloseşte sistemul. Un actor este un rol pe care utilizatorul îl poate juca. Numele
actorului trebuie să indice acest rol. Un actor este un tip sau o clasă de utilizator. Acelaşi utilizator
poate juca mai multe roluri.
Actorii, fiind entităţi externe sistemului, nu pot fi descrişi în detaliu. Identificarea actorilor ajută
la identificarea cazurilor de utilizare - întrucât un caz de utilizare este iniţiat de un actor. Iată câteva
întrebări la care analistul de sistem trebuie să răspundă pentru a identifica cazurile de utilizare:
• Care sunt principalele acţiuni executate de fiecare actor?
• Actorul va citi sau va actualiza informaţia din sistem?
• Actorul va informa sistemul despre modificările petrecute în afara acestuia?
• Actorul va fi informat de modificările din sistem?
Să considerăm cazul unui sistem de înregistrare a studenţilor la cursurile oferite de un centru de
instruire. Entităţile externe sistemului sunt studentul care se înscrie la curs, secretara care face
înscrierea studenţilor la cursuri, casiera care încasează contravaloarea cursurilor şi instructorul care
predă cursurile
Un caz de utilizare este iniţiat întotdeauna de un actor şi poate interacţiona şi cu alţi actori, nu
numai cu cel care 1-a iniţiat. Cazul de utilizare trebuie să redea o funcţionalitate completă şi nu numai
o anumită acţiune a unei funcţionalităţi. Transmiterea unui formular de înscriere la un curs este parte a
procesului de înregistrare la curs, deci va fi inclus în cazul de utilizare „înregistrare la curs" şi nu se va
construi un caz separat pentru acţiunea transmitere formular de înscriere.
Diagrama cazurilor de utilizare arată care sunt toate cazurile de utilizare din sistem. dar nu
indică modul în care acestea sunt realizate de către actori. Modelul cazurilor de utilizare este completat
de o descriere textuală a fiecărui caz de utilizare, accentul punându-se pe interacţiunea cu alţi actori şi
mai puţin pe modul în care este executat în cadrul sistemului.
Modelarea cazurilor de utilizare permite analiza cerinţelor funcţionale ale sistemului, insistând
asupra a CE trebuie să facă un sistem existent sau un nou sistem, fără să considere şi CUM o să facă.
Modelul cazurilor de utilizare este dezvoltat în faza de analiză a ciclului de viaţă al sistemelor
orientate obiect, având rolul de a ajuta dezvoltatorii să înţeleagă cerinţele funcţionale ale sistemului.
Procesul este iterativ iar, stabilirea cerinţelor se face în urma discuţiilor cu beneficiarul sistemului.
Cazurile de utilizare controlează toate celelalte modele. Dacă cerinţele utilizatorului se modifică în
timpul dezvoltării, aceste modificări sunt vizibile mai întâi în modelul cazurilor de utilizare.
Modificările în cazurile de utilizare implică modificări şi în celelalte modele. Şi reciproca este valabilă,
adică în momentul în care se fac modificări în modele, acestea trebuie să se reflecte şi la nivelul
cazurilor de utilizare.

Modelarea structurii statice (diagrama claselor, diagrama obiectelor)

Diagrama claselor documentează structura statică a sistemului; mai exact precizează clasele
care există şi relaţiile dintre acestea, nu şi modul în care interacţionează pentru a asigura un anumit
comportament. Diagrama claselor poate, de asemenea, evidenţia şi alte aspecte ale structurii statice,
cum ar fi pachetele.
Construirea diagramei claselor presupune în primul rând identificarea claselor din sistem, acest
proces reprezintă o parte esenţială a proiectării sistemelor orientate obiect, de succesul acestuia
depinzând în mare parte succesul proiectului.
Criteriile de apreciere a unui model al claselor sunt:
• obiectele claselor din model trebuie să poată furniza întregul comportament cerut sistemului;
• un bun model al claselor conţine (pe cât posibil) clase stabile din domeniul obiectual, care nu
depind de funcţionalitatea particulară cerută la momentul proiectării.
Poate fi utilizată orice tehnică de obţinere a claselor atâta timp cât modelul obţinut respectă
criteriile enunţate. Implicit, dacă modelul obţinut nu respectă criteriile, nu va fi nimeni interesat de
tehnica utilizată, oricât de profesionistă ar fi aceasta.
În literatura de specialitate se propun două metode:
• modelarea orientată pe date (data driven design);
• modelarea orientată pe funcţiuni (responsibility driven design).
Primul tip de metode presupune identificarea tuturor datelor din sistem şi împărţirea Ior pe
clase, înainte de a considera funcţiunile acestor clase. Tehnica identificării substantivelor este cea mai
utilizată astfel de metodă. Al doilea tip de metode, orientate pe funcţiuni, presupune identificarea
tuturor funcţiunilor sistemului şi împărţirea lor pe clase, înainte de a considera datele acestor clase.
Tehnica identificării substantivelor presupune două etape:
• Identificarea claselor candidate, selectând din specificarea cerinţelor sistemului toate
substantivele şi frazele substantivale (se consideră substantivele la singular şi nu se aleg fraze ce
conţin „sau" ca unici candidaţi).
• Se elimină candidaţii consideraţi nepotriviţi din diverse motive şi se redenumesc clasele
rămase dacă este necesar.
Unele dintre motivele pentru care o clasă candidată ar putea fi considerată nepotrivită sunt:
Redundanţa - o clasă e prezentă sub mai multe denumiri. Este important să ne amintim însă că
obiecte similare pot să nu fie identice. Proiectantul decide dacă lucrurile sunt suficient de diferite
pentru a merita clase diferite.
De exemplu, dacă a fost selectată o pereche de genul „împrumut" şi „împrumut pe termen
scurt", acestea sunt diferite, dar numai la nivelul valorii atributelor. Se recomandă în acest caz alegerea
unui nume care să desemneze întreg conţinutul clasei.
Imprecizia - când nu se poate spune precis care e realitatea descrisă de substantivul respectiv.
Desigur, trebuie îndepărtată ambiguitatea înainte de a putea spune dacă substantivul reprezintă o clasă.
Eveniment sau operaţie - când substantivul se referă la ceva ce este făcut de sistem. Uneori
această situaţie este bine modelată de o clasă, dar nu este acesta cazul obişnuit.
Metalimbaj - unde substantivul face parte din modul de definire a cerinţelor. Vom utiliza
substantive ca „cerinţe" sau „sistem" ca parte a limbajului de modelare şi nu pentru a reprezenta obiecte
din domeniul problemei.
 Extern sistemului - atunci când substantivul este relevant pentru a descrie funcţionarea
sistemului, dar nu se referă la ceva din interiorul său.
Atribut - atunci când este clar că substantivul desemnează o realitate simplă, fără un
comportament interesant, care este de fapt un atribut al altei clase.
Diagrama obiectelor
Diagramele obiectuale conţin obiecte şi legături. Ca şi celelalte diagrame, pot conţine note şi
restricţii. Mai pot conţine anumite pachete sau subsisteme, fiecare fiind folosite pentru a grupa
elementele modelului.
Aceste diagrame se folosesc pentru modelarea statică a unui sistem, ca diagramele de clase, dar
din perspectiva unor instanţe reale sau prototip.
Crearea unei diagrame conceptuale se face într-un singur mod, modelând structura obiectelor.
Modelarea structurii obiectelor implică fotografierea obiectelor din sistem la un anumit moment.
Modelarea dinamicii sistemului
Pentru modelarea dinamicii sistemului, UML furnizează două tipuri de diagrame şi anume,
diagramele de interacţiune (diagrama de secvenţă şi diagrama de colaborare) şi diagramele de
comportament (diagrama de stare şi diagrama de activitate). Principala menire a acestor diagrame este
de a arata cum realizează sistemul un caz de utilizare sau un scenariu particular dintr-un caz de
utilizare. Pentru fiecare caz de utilizare se pot realiza mai multe scenarii (din descrierea cazului de
utilizare). Pentru fiecare astfel de scenariu se pot întocmi, nu este obligatoriu, o diagramă de secvenţă
sau o diagramă de colaborare (unele dintre instrumentele CASE pot obţine o diagramă din alta).
Acest tip de diagrame înlesneşte înţelegerea cazurilor de utilizare mai dificile. Ele pot, de
asemenea, susţine comunicarea în cadrul echipei de proiectare, în cazul în care de o aceeaşi interacţiune
se ocupă mai multe persoane sau grupuri de persoane. Nu e de aşteptat să se dezvolte astfel de
diagrame pentru fiecare caz de utilizare sau pentru fiecare operaţie, doar dacă beneficiile depăşesc
costurile. În cazul în care se dispune de un CASE ce poate utiliza aceste diagrame la generarea de cod,
atunci devine profitabil să dezvoltăm diagrame de interacţiune şi diagrame de comportament.
Diagramele de secvenţă descriu modul în care obiectele interacţionează şi comunică între ele.
Aceste diagrame permit focalizarea atenţiei asupra secvenţelor de mesaje, mai precis asupra mesajelor
care sunt trimise şi recepţionate de către obiecte.
Avantajul major al diagramelor de secvenţă, faţă de diagramele de colaborare, este posibilitatea
de a reprezenta grafic trecerea timpului, fiind deci indispensabile în căzul proiectării de sisteme în timp
real.
Diagramele de colaborare permit evidenţierea atât a interacţiunilor, cât şi a legăturilor dintre un
set de obiecte care colaborează. Atât diagramele de secvenţă, cât şi cele de colaborare vizualizează
interacţiunile, dar diagrama de secvenţă ia în considerare timpul, pe când cea de colaborare, spaţiul.
Ca şi diagramele de secvenţă, diagramele de colaborare pot fi utilizate pentru înscrierea
execuţiei unei operaţii, a unui caz de utilizare sau a unui scenariu de interacţiune în cadrul sistemului.
În acest tip de diagramă nu pot fi descrise mesajele concurente şi asincrone.
Până acum nu am amintit nimic despre modelarea „deciziei" unui obiect despre ceea ce să facă
la primirea unui mesaj. Diagramele de interacţiune pot reprezenta obiecte diferite ale aceleiaşi clase
care primesc acelaşi mesaj, dar răspund diferit. Acest comportament este rezonabil de cele mai multe
ori, întrucât comportamentul unui obiect poate fi afectat şi de valorile atributelor sale. Pentru a putea
implementa, întreţine sau testa o clasă este necesar să înţelegem relaţiile de dependenţă care există între
starea unui anumi: obiect şi reacţiile sale la mesajele primite sau la alte evenimente. Diagramele de
stare sunt acelea care înregistrează aceste dependenţe.
Pornind de aici, se pot folosi aproximativ aceleaşi notaţii pentru a descrie activităţ complexe. Se
consideră că trecerea de la o activitate la alta atunci când prima activitate s-a încheiat este similară cu
trecerea unui obiect dintr-o stare într-alta, semnificativ diferită de prima, atunci când acesta primeşte un
mesaj. Diagramele de activitate sunt o variaţiune a diagramelor de stare, adaptate pentru a evidenţia
conexiunile şi dependenţele dintre activităţi. Ele sunt extrem de folositoare atunci când se apreciază că
o activitate trebuie să execute o serie de task-uri diferite şi dorim să modelăm dependenţele esenţiale
dintre acestea, înainte de a decide în ce ordine să se execute.
Diagramele de stare au rolul de a captura ciclul de viaţă al obiectelor, subsistemelor şi
sistemelor, prin specificarea stărilor în care se poate găsi un obiect şi a evenimentelor (mesaje primite,
erori, condiţii care devin adevărate) care-i afectează starea de-a lungul execuţiei. O diagramă de stare
poate fi ataşată oricărei clase care are stări clar identificabile şi un comportament complex.
O diagramă de activitate constituie o variantă a diagramei de stare, cu un scop puţin diferit,
acela de a evidenţia acţiuni şi rezultate ale acestor acţiuni. De fapt, diagramele de activitate constituie o
cale alternativă de descriere a interacţiunilor.
Diagramele de activitate pot fi utilizate şi pentru a descrie cum se desfăşoară cazuri de utilizare
individuale şi cum depind de alte cazuri de utilizare.
Diagramele de activitate pot fi folosite în mai multe scopuri, şi anume:
• Ilustrarea acţiunilor care vor fi realizate atunci când este executată o operaţie. Acesta este şi
cel mai comun caz de utilizare a acestui tip de diagramă.
• Prezentarea activităţii interne a unui obiect.
• Identificarea acţiunilor care pot fi realizate în mod legat şi stabilirea modului în care aceste
seturi de acţiuni afectează obiectele din jur.
• Ilustrarea modului în care instanţa unui caz de utilizare poate fi realizată în termenii acţiunilor
sau modificărilor intervenite în starea obiectului.
• Ilustrarea modului în care este organizată munca actorilor, care este organizarea şi obiectele
folosite.

7.3 Dezvoltarea sistemelor informatice folosind procesul unificat (UML)

Proiectarea orientată obiect îşi găseşte justificarea în cerinţa imperioasă de a face faţă şi a oferi
soluţii superioare calitativ în special sistemelor informatice de mari dimensiuni şi nivel ridicat de
complexitate.
Interesul manifestat faţă de abordarea obiectuală, în programare mai întâi şi, prin forţa
lucrurilor, în proiectare şi apoi în analiză au condus, odată cu acumularea de suficientă experienţă
practică, la definirea de metode de dezvoltare orientate obiect. Printre acestea, cele care s-au bucurat de
cele mai bune aprecieri din partea utilizatorilor au fost OMT(Object Modeling Tehnique),
OOSE(Object-Oriented Software Engineering), UML(Unified Modeling Language).
UML este rezultatul unui efort de unificare la care au contribuit elemente dezvoltate de
numeroase cercetări şi metode. De altfel, documentul oficial defineşte UML drept o colecţie a celor
mai bune practici aplicate în modelarea sistemelor informatice de mari dimensiuni şi complexitate.
UML a fost definit pornind de la rolul esenţial pe care-l joacă modelarea în conceperea şi
realizarea de sisteme software. Un model este formulat într-un limbaj de modelare. Limbajul de
modelare include un ansamblu de concepte şi semantici fundamentale, o notaţie şi un set de reguli de
utilizare. Pentru un plus de rigoare şi claritate a definirii, conceptele de bază sunt, la rândul lor
modelate în UML. Această definire recursivă este denumită metamodelare. Metamodelele oferă o
descriere formală a tipurilor de elemente care pot participa la modelare (sau din care pot fi compuse
modelele) – numite simplu “elemente de modelare” – împreună cu sintaxa şi semantica notaţiei prin
care sunt referite şi folosite acestea. În alţi termeni, fiecare metamodel defineşte elementele de
modelare şi regulile după care se compun acestea în modele.
Notaţia folosită este formată din simboluri grafice. Aceasta conduce la utilizarea sintagmei de
modelare vizuală pentru UML şi justifică declararea sa drept “limbaj de vizualizare”. Paradigma
obiectuală, printre altele, avantajul că oferă un set de concepte ce pot fi aplicate uniform pe toate
nivelele de abstractizare, începând cu viziunea schematică iniţială şi până la viziunea terminală,
suficient de detaliată pentru a oferi toate amănuntele necesare traducerii directe în program sursă.
Aplicate în acest context, rigoarea şi consistenţa cu care sunt definite conceptele sale au făcut din UML
baza mai multor instrumente CASE, aşa cum este Rational Rose. Acestea nu numai că asistă analiza şi
proiectarea prin mijloace specifice, dar sunt capabile şi de generarea automată a unei părţi din codul
sursă, în mai multe limbaje la alegere. Există, prin urmare, posibilitatea, demonstrată practic, de a
defini reguli şi euristici de trecere de la structurile UML la construcţiile specifice unui limbaj de
programare sau altul.
Diversele metode obiectuale, inclusiv cele care ua stat la originea UML, preconizează diferite
procese de dezvoltare a sistemelor. Procesul este cel care prescrie activităţile şi ordinea în care trebuie
realizate, rezultatele de obţinut din fiecare activitate, criteriile de evaluare a calităţii şi de măsurare şi
control a progresului proiectului etc. Dincolo de specificitatea oferită de o metodă sau alta, procesul
trebuie adaptat de asemenea, la natura problemei de rezolvat, la cultura managerială a utilizatorului, la
caracteristicile echipei implicate în realizare ş.a.m.d. UML nu este o metodă de dezvoltare obiectuală.
Poate accepta şi poate fi însă folosit în diverse metode, chiar dacă acestea aplică procese diferite. A fost
astfel definit şi un proces de aplicare a UML în dezvoltarea de sisteme informatice, denumit, la rândul
său, unificat.
Procesul unificat poate fi caracterizat prin următoarele trăsături cheie:
• este iterativ şi incremental;
• este dirijat de cazurile de utilizare;
• este centrat pe arhitectură;
• este pilotat de riscuri.
Conform primei trăsături, dezvoltarea are loc prin mai multe iteraţii succesive, în fiecare dintre
acestea abordându-se doar o porţiune a sistemului său doar anumite aspecte ale proiectări şi realizării.
În felul acesta se renunţă la ideea de a defini în totalitate detaliile aferente unei anumite etape înainte de
a trece la următoarea. De această dată, se acceptă o definire parţială, pe baza căreia se construieşte un
produs la care se revine, într-o nouă iteraţie, cu modificări sau cu noi detalii sau funcţii – aspectul
incremental – până la obţinerea sistemului final. Progresul proiectului poate fi mai bine controlat, iar
experienţa acumulată în cursul unei iteraţii poate fi utilizată în cele care urmează.
Cazurile de utilizare constituie punctul central al edificiului: în stadiul iniţial, ele definesc
utilizatorii şi cerinţele acestora sub forma actorilor şi a interacţiunilor dorite ale acestora cu sistemul.
Aceleaşi cazuri de utilizare vor constitui punctul iniţial în definirea cerinţelor şi referinţa pentru
proiectare şi realizare, iar setul de teste prin care este verificat sistemul se va defini tot pe baza lor. Prin
posibilitatea de a regăsi permanent legătura cu cazul de utilizare în cursul întregului ciclu de dezvoltare,
se răspunde şi cerinţei de asigurare a trasabilităţii.

Diagrame
de
colaborare
Cazuri Diagrame Diagrame
de de de
utilizare clase activitate
Diagrame
de
secvenţe
Înlănţuirea diagramelor UML
Arhitectura se referă aici la structura de ansamblu a sistemului sub aspectul organizării sale în
subsisteme, a interacţiunii dintre acestea, a celor mai semnificative cazuri de utilizare etc. Pe baza
arhitecturii este posibilă planificarea şi lucrul în paralel a mai multor echipe diferite. Existenţa este
indispensabilă pentru a putea aplica dezvoltarea iterativă.
 Riscul desemnează în contextul de faţă, tot ceea ce ar putea împiedica realizarea sistemului. Pot
fi evidenţiate două categorii primare de risc: tehnice şi funcţionale. Sintagma “pilotat de riscuri”
exprimă faptul concret că definirea şi ordonarea iteraţiilor se face astfel încât riscurile identificate să fie
abordate şi elimanate cât mai devreme în cadrul ciclului de dezvoltare, începând cu cele mai grave.
Balize de evaluare

Studiul Elaborare Construcţia Tranziţia

preliminar a

Fazele ciclului de dezvoltare

Ciclul de dezvoltare
Ciclul de dezvoltare este compus din patru faze. Fiecare fază produce un anumit set de rezultate
care sunt elemente de intrare pentru următoarea, ceea ce conferă ansamblului un caracter de
confidenţialitate. Pentru fiecare fază, anumite rezultate sunt folosite drept balize de evaluare şi servesc
pentru a măsura progresul înregistrat de proiect.
Fazele ciclului de dezvoltare sunt următoarele: studiul preliminar, elaborarea, construcţia, şi
tranziţia.
Studiul preliminar (“inception” în terminologia de origine) urmăreşte definirea amplasării
viitorului sistem în cadrul activităţii organizaţiei. Aceasta include delimitarea ariei de cuprindere,
stabilirea obiectivelor, studiul fezabilităţii în contextul unuia sau mai multor modele de afaceri.
Rezultatul cheie al fazei este viziunea sistemului, care conţine o descriere foarte sintetică în care se
precizează ce este sistemul, cine îl va utiliza, ce facilităţi trebuie să asigure şi la ce restricţii trebuie să
răspundă. Viziunea constituie şi principala baliză de evaluare a studiului preliminar.
Elaborarea asigură colectarea şi precizarea cerinţelor funcţionale şi nefuncţionale ale viitorului
sistem. Cum utilizatorii sistemului şi cerinţele acestora sunt specificate prin intermediul cazurilor de
utilizare, modelul detaliat al acestora constituie unul dintre “artefactele” de bază şi, în acelaşi timp,
baliză de evaluare a fazei. Un alt rezultat esenţial, strâns legat de precedentul şi inclus în balizele de
evaluare de bază, este reprezentat de arhitectura sistemului.
Construcţia asigură obţinerea sistemului, incluzând deci analiza, proiectarea, programarea şi
testarea. Rezultatele ce servesc drept principale balize de evaluare cuprind întregul set de modele de
analiză şi proiectare, împreună cu totalitatea programelor elaborate.
Tranziţia asigură introducerea în exploatare a sistemului la utilizator. Aici se regăsesc
configurarea, instalarea, furnizarea documentaţiei, instruirea şi eventual formarea personalului.
Principala baliză de evaluare este versiunea finală a sistemului.
Sistemul informatic obţinut în urma parcurgerii celor patru faze poate solicita modificări
ulterioare pentru asigurarea evoluţiei sale. Pentru referirea la asemenea stadii evolutive, se foloseşte
termenul de generaţie. În consecinţă, la terminarea primului ciclu de dezvoltare, rezultă generaţia 1 a
produsului software respectiv. Obţinerea unei noi generaţii presupune reluarea ciclului, cu parcurgerea
celor patru faze.
Activităţi şi iteraţii
Structurarea în cele patru faze ale ciclului de dezvoltare corespunde perspectivei manageriale
asupra procesului, în care atenţia este concentrată asupra aspectelor financiare, strategice, de personal.
Aspectele tehnice legate de conceperea şi realizarea sistemului sunt proprii unei alte perspective a
aceluiaşi proces, structură în activităţi şi iteraţii.
 O activitate se realizează prin combinarea mai multor paşi. Pasul este componenta elementară şi
foloseşte anumite elemente de intrare pe care le modifică sau pe baza cărora realizează alte elemente
noi. Aceste intrări şi ieşiri sunt produse intermediare constând din documente, modele, programe etc.
Există cinci activităţi de bază: definirea cerinţelor, analiza, proiectarea, implementarea şi
testarea.
Definirea cerinţelor se concentrează asupra identificării cerinţelor funcţionale şi nefuncţionale
ale sistemului. Această etapă furnizează imaginea exterioară a sistemului, adică imaginea percepută de
către utilizatorii săi.
Analiza urmăreşte obţinerea unui model al problemei de rezolvat, aşa cum apare aceasta la
nivelul activităţii reale de afaceri. Modelul este însă formulat în termeni informatici, prin clase de
obiecte, operaţii, interacţiuni etc. şi ignoră orice detaliu tehnic sau de implementare.
Proiectarea extinde sau adaptează modelul anterior pentru a răspunde cerinţelor tehnice şi
restricţiilor configuraţiei de calcul în care va funcţiona sistemul. Este etapa în care sunt luate în
considerare şi rezolvate problemele de persistenţă, de intefaţă, de comunicare etc. păstrând însă
neschimbată structura şi comportamentul definite anterior, care exprimă logica domeniului.
Implementarea constă în scrierea, compilarea şi documentarea programelor pentru proiectul
definit în etapa precedentă.
Testarea asigură verificarea programelor realizate în etapa anterioară pentru a stabili măsura în
care acestea corespund cerinţelor funcţionale şi nefuncţionale, sunt sigure în funcţionare.
Activităţile enumerate se bucură de o accepţiune aproape unanimă. Cu toate acestea numeroşi
autori le combină sau le completează.
Fiind vorba despre acelaşi proces privit din perspective diferite, există o suprapunere a fazelor
şi activităţilor. Deosebit de semnificativ este faptul că activităţile se pot regăsi în totalitate, chiar dacă
în proporţii diferite, în fiecare din cele patru faze. Spre exemplu, sunt posibile activităţi de
implementare şi testare chiar şi în faza de studiu preliminar, pentru care metoda recomandă, de altfel,
recurgerea la prototipaj, ceea ce indivizualizează suficient de clar demersul aplicat.