Tema 6.

Metode de proiectare

Metodele de proiectare a sistemelor informaționale pot fi clasificate:

- după gradul de utilizare a instrumentelor de automatizare,
- soluții de proiectare standard
- adaptabilitatea la modificările propuse.
Deci, în funcție de gradul de automatizare, metodele de proiectare sunt împărțite în:
- manual, în care proiectarea componentelor sistemelor informaționale este realizată fără
utilizarea unor instrumente software speciale și programare în limbaje algoritmice;
computerizate, care generează sau configurează decizii de proiectare bazate pe utilizarea
instrumentelor software speciale.
În funcție de gradul de utilizare a soluțiilor tip de proiectare, se disting următoarele
metode de proiectare:
- Proiectare canonică (individuală), când deciziile de proiectare sunt elaborate „de la zero” în
conformitate cu cerințele beneficiarului pentru sistemul dorit . Se caracterizează prin faptul că
toate tipurile de lucrări de proiectare sunt axate pe crearea de proiecte individuale pentru fiecare
obiect care reflectă în maximă măsură toate caracteristicile sale;
- Proiectare tip, care implică configurarea sistemului informațional din soluții de proiectare
standard (module software). Se realizează pe baza experienței acumulate în dezvoltarea de
proiecte individuale.
Proiectele tip, ca generalizare a experienței pentru anumite grupuri de sisteme organizaționale și
economice sau tipuri de lucrări, în fiecare caz sunt asociate cu multe caracteristici specifice și
diferă în gradul de acoperire a funcțiilor de management, a lucrărilor efectuate și a documentației
de proiect în curs de dezvoltare.
În funcție de gradul de adaptabilitate a soluțiilor de proiectare, se disting:
- Metoda de reconstrucție, când adaptarea soluțiilor de proiectare este realizată prin reproectarea
componentelor corespunzătoare (reprogramarea modulelor software);
- Metoda parametrilor, când deciziile de proiectare sunt configurate (generate) în conformitate
cu parametrii variabili;
- Metoda de restructurare a modelului atunci când se schimbă modelul zonei cu probleme, pe
baza cărora deciziile de proiectare sunt regenerate automat
Combinarea diferitelor metode determină natura tehnologiilor de proiectare sisteme
informaționale utilizate, printre care există două clase principale:
- Tehnologia canonică și
- tehnologie industriala.
La rândul său, tehnologia de proiectare industrială este divizată în două subclase:
- automatizate (folosind tehnologii CASE) și
- proiectare tip (orientat parametric sau model).
Trebuie de menționat că utilizarea tehnologiilor industriale nu exclude utilizarea în anumite
cazuri a metodei canonică.
Aplicarea oricărei metode de proiectare presupune proiectarea sistemului informațioal pe cele
trei nivele (fig. 6.1.)
 Modelarea Modelarea obiect
Modelul structural orientată
conceptual funcțională UML
IDEF0, IDEF3, DFD

Modelarea
Modelul logic informațională
IDEF 1x

Sisteme de
Modelul fizic gestionare a
Bazelor de date

Figura 6.1. Nivele de proiectare

6.1. Principii de abordare în proiectare sisteme informaţionale

Există cel puţin 10 principii economice şi 6 principii tehnologice (figura 6.2):
- principiul utilităţii;
- principiul eficienţă economică a sistemului;
- principiul respectare standarde;
- principiul abordare sistemică;
- principiul de integrare;
- principiul inovare;
- principiul de decompoziţie a sistemului informaţional;
- principiul de decompoziţie a procesului de proiectare;
- principiul de participare utilizator;
- principiul de eficienţă a activităţii de proiectare.
 Utilitatea S I

Eficiență economică

Principii de abordare Economice și de

proiectare S I organizare Respectare standarde

tehnologice Abordare sistemică

Principiu de
modelare sistem inegrare

Principiu modularitate Inovare

Decompoziție Sistem
Principiu de Informațional
adaptabilitate

Principiu de Decompoziție procese

Sistem deschis de proiectare

Principiu de
intelectualizare Participare utilizator

Principiu interfață
prietenoasă Eficiență a activității
de proiectare

Fig.6.2. Principii de abordare în proiectarea sistemelor informaţionale

i.Principiile economice
Principiul utilităţii - nu există sisteme informaţionale care să poată afirma că sunt
„ideale” din punct de vedere al utilităţii oferite utilizatorilor. Cu toate acestea, produsele software
cu o utilitate percepută mai bună sunt preferate cu regularitate de către cumpărători, iar utilitatea
percepută bună este de regulă o expresie a unui proces de concepţie şi execuţie care a ţinut cont
cu consecvenţă de nevoile publicului. În principiu, dacă se doreşte realizarea unui sistem
informatic cu o utilitate percepută ridicată, procesul de design trebuie să debuteze prin stabilirea
obiectivului primar al acelui produs software, identificarea publicului-ţintă şi a competitorilor
existenţi la nivelul publicului-ţintă, în special a celora care sunt la momentul respectiv lideri pe
piaţă.
Principiul eficienţă economică a sistemului - presupune că sistemul nou creat va
asigura îndeplinirea tuturor cerinţelor formulate de beneficiar faţă de acest sistem.
Principiul respectare standarde - presupune aplicarea standardelor internaţionale şi
naţionale, precum şi a recomandărilor ce reglementează etapele, fazele şi acţiunile la
proiectarea sistemelor informaţionale, la codificarea informaţiei, la elaborarea şi crearea
documentaţiei, aplicarea procedurii standarde pentru schimbul de informaţii dintre componentele
sistemului şi elaborarea interfaţă a utilizatorului etc.
Principiul abordare sistemică – presupune determinarea şi abordarea tuturor proceselor,
fenomenelor, conexiunile şi interacţiunile atât dintre ele, cât şi cu mediul ambiant.
 „Întregul este mai mult decât suma părţilor componente”. Acest principiu cere
aplicarea ideologiei unice faţă de părţile componente ale sistemului – partea funcţională,
selectarea sistemului de programare, sistemului de codificare informaţie, structura bazei de date,
asigurarea compatibilităţii şi interoperabilităţii componentelor. Principiul abordare sistemică
presupune ordinea de proiectare „de sus în jos”, adică de la general spre particular. La început se
rezolvă sarcinile generale ale sistemului şi se formulează cerinţele funcţionale care ulterior vor fi
elaborate într-o consecutivitate. Abordarea sistemică presupune determinarea emergenţei, adică
determinarea a noi proprietăţi ale sistemului ce nu au fost formulate anterior.
Principiul de integrare - presupune crearea sistemelor informaţionale cu funcţionalităţi
extinse. Adică, subsistemele SI au o bază informaţională comună. Acest principiu de regulă duce
spre integrarea subsistemelor într-un sistem corporativ.
Principiul inovare - identificarea funcţiilor anterior nerezolvate şi rezolvarea lor.
Principiul de decompoziţie - duce la ridicarea calităţii SI prin elaborarea mai multor
subsisteme, în special, dacă avem de construit un sistem informaţional de amploare cu
participarea a mai multor grupuri de proiectanţi şi programatori.
Principiul de participare utilizator – în special, în etapa elaborării prototipurilor
participarea primelor persoane, participarea responsabililor de proces etc.
Principiul de eficienţă a activităţii de proiectare – presupune că preţul proiectării
trebuie să fie mai mic decât preţurile de piaţă, termenele de realizare să fie respectate aşa cum
este stipulat de condiţiile Contractului.

ii. Principii tehnologice

- principiul de modelare sistem;
- principiul de modularitate;
- principiul de adaptabilitate;
- principiul de sistem deschis;
- principiul de intelectualizare;
- principiul de sistem prietenos (friendliness).

Principiul de modelare sistem - se determină relaţiile dintre mărimile caracteristice, se

construieşte un model simplificat, o imagine a procesului considerat. Modelarea sistemelor se
realizează în scopul obţinerii unor informaţii suplimentare sau a specializării personalului,
folosindu-se diferite instrumente şi tehnici.
Modelul este o reprezentare simplificată, aproximativă a sistemului real. Nu e de regulă
nici posibil, nici necesar să se realizeze o descriere amănunţită a tuturor mecanismelor interne. E
suficient ca modelul să mimeze, să se comporte suficient de aproape de sistemul real.
Modelul trebuie să aibă o formă utilizabilă (care nu este un scop în sine). El constituie o
bază pentru analiză, luarea deciziilor şi în acest sens modelul trebuie să fie de o complexitate
suficientă pentru a reflecta toate procesele.
Există mai multe tipuri de modele, şi anume:
- modele fizice (empirice sau la scară redusă – de exemplu, se elaborează o tehnologie în
domeniul chimiei, un micropilot, se încearcă procesul tehnologic pe acest model fizic şi se trag
concluzii);
- modele fenomenologice (conceptuale – sistemele respective sunt descrise prin anumite
legi), ¾ modele funcţionale (formale – sistemul este reprezentat prin relaţii funcţionale, scheme
funcţionale);
 - modele matematice (analitice).

Principiul de modularitate - este procesul de partiţionare a unui sistem în componente

individuale (module), ceea ce permite reducerea complexităţii sistemului prin definirea unor
graniţe bine stabilite şi documentate.

Modularitatea constă în partiţionarea sistemului în module care pot fi elaborate separat,

dar care au conexiuni cu alte module ale sistemului. Modulele servesc ca şi containere în care
sunt declarate clasele şi obiectele sistemului.

Principiul de adaptabilitate - adaptabilitatea presupune corelarea formei de prezentare, a

gradului de prelucrare cu nivelul de pregătire, gradul de informare, poziţia ierarhică deţinută de
către receptor.
Principiul de sistem deschis - caracterul deschis/parţial deschis al sistemelor: un sistem
care are legături cu mediul prin cel puţin o intrare şi o ieşire este considerat un sistem deschis, în
timp ce absenţa uneia din legături (de intrare sau de ieşire) determină caracterul parţial-deschis al
acestuia. În absenţa ambelor legături cu mediul, sistemul este izolat. Această proprietate
caracteristică face o distincţie clară între sistemele biologice şi cele economice care, putându-se
organiza, îi sporesc ordinea interioară şi, prin urmare, îi micşorează entropia pe baza schimbului
permanent de substanţă, energie, informaţii cu mediul lor.
Caracterul antientropic al sistemelor cu structură cibernetică este legat în special de
posibilitatea perfecţionării conducerii şi a reducerii gradului de dezorganizare internă a
sistemelor deschise prin ameliorarea proprietăţilor structurale şi a celor informaţional
decizionale, precum şi prin intensificarea schimbului de informaţii şi a tranzacţiilor cu mediul.

Principiul de intelectualizare - intelectualizarea activităţilor de proiectare a sistemelor

informaţionale presupune includerea în acest proces a unor factori noi de elaborare şi
implementare a unor principii noi de utilizare, interpelarea şi funcţionarea sistemelor
informaţionale.

Principiul de sistem prietenos - un design compact şi o interfaţă prietenoasă, interfaţă

simplă, dar modernă şi foarte uşor de folosit. Un grad înalt de uzabilitate.
Practic, usability denotă gradul de uşurinţă în utilizare a unui obiect, interfaţă etc. Usability,
din definiţia sa, nu este perfectă şi măsurabilă, nu este o ştiinţă exactă, motiv pentru care şi
atingerea perfecţiunii este imposibilă.

a. Metode de proiectare
În funcţie de nivelul de utilizare a instrumentelor şi a soluţiilor-tip, metodele de proiectare
ale SI se împart în două categorii:
- proiectarea canonică;
- proiectarea-tip.
Proiectarea canonică. Proiectarea canonică presupune elaborarea sistemelor fără
utilizarea unor soluţii gata sau mijloace instrumentale speciale (elaborare de la zero), dar după
careva reguli sau canoane.
Proiectarea-tip. Proiectarea-tip presupune crearea sistemului informaţional din elemente-
tip existente care aplică:
 - tehnologii de proiectare automatizată;
- tehnologii de proiectare-tip;
- tehnologii de proiectare-tip pe parametri;
- tehnologii de proiectare-tip pe modele.

METODE DE PROIECTARE
SISTEME INFORMAȚIONALE

PROIECTARE
CANONICĂ
PROIECTARE
TIP

PROIECTARE TIP
pe ELEMENTE PROIECTARE TIP
pe SUBSISTEME
PROIECTARE TIP
pe OBIECTE

Fig. 6.3. Clasificare metode de proiectare

6.2. Proiectarea canonică

Stadiile şi etapele proiectării canonice. Scopurile şi obiectivele etapei preproiect.
Modelele activităţii întreprinderii (“cum este” şi “cum trebuie să fie”). Componenţa lucrărilor
în etapa elaborării proiectului tehnic. Documentaţia de proiect.
Organizarea proiectării canonice este orientată spre utilizarea modelului cascadă al
ciclului de viaţă. Etapele sunt standardizate în ISO 12207.
În funcţie de complexitatea obiectului automatizării şi problemele care trebuie soluţionate
prin crearea unui SI concret, etapele pot fi de complexitate diferită.
Este permis a combina etapele succesive şi chiar a exclude unele etape în orice fază a
proiectului.
Mai mult, următoarea etapă a lucrărilor poate începe până la sfârşitul etapei precedente.
Etapele creării sistemelor informaționale (fig. 6.4), executate de organizaţiile participante,
sunt fixate în contracte şi sarcini tehnice de executare a lucrărilor.
 Fig.6.4. Etape de proiectare a sistemelor informaţionale

6.2.1. Etapa 1. Studiul SI existent şi definirea cerinţelor noului sistem

- cercetarea SI şi motivarea necesităţii creării unui sistem nou;
- formularea cerinţelor faţă de sistemul nou;
- elaborarea raportului privind lucrările îndeplinite.
Studiul sistemului existent cuprinde un grup de activităţi care urmăresc cunoaşterea:
- performanţelor tehnico-funcţionale ale sistemului informaţional atât în ansamblul său,
cât şi pentru elementele de structură ale acestuia;
- a cerinţelor informaţionale ale conducerii;
- cunoaşterea lipsurilor şi restricţiilor pe care le prezintă sistemul existent faţă de aceste
cerinţe.
De modul de realizare a acestor activităţi depinde întregul proces de realizare a sistemului
informatic.
Studiul sistemului existent constă în următoarele:
- definirea caracteristicilor generale ale (unităţii de informatizare) obiectului social-
economic;
- studiul activităţilor de bază desfăşurate în sistemul obiectului social-economic;
- studiul sistemului de conducere a obiectului;
- studiul sistemului informaţional existent;
- identificarea metodelor şi mijloacelor tehnice.
Definirea caracteristicilor generale ale obiectului de informatizare presupune:
- cunoaşterea profilului, obiectivelor agentului economic;
- cunoaşterea locului în sfera serviciilor şi sfera producţiei;
- cunoaşterea relaţiilor de cooperare cu alţi agenţi economici;
- cunoaşterea specificului activităţii de bază (producţie, servicii);
- cunoaşterea nivelului tehnic;
- cunoaşterea principalilor indicatori economici şi evoluţia lor;
- dezvoltarea, modernizarea etc.
 Studiul activităţilor desfăşurate în sistemul obiectului social-economic, modul de
realizare a funcţiunilor unităţii economice se face astfel:
a) Pe baza ”statutului” de funcţionare a unităţii social-economoce şi se studiază:
1) activităţile şi sarcinile din cadrul acestor funcţiuni;
2) atribuţiile ce le revin subdiviziunilor unităţii economice;
3) modul de realizare a activităţilor funcţionale din cadrul unităţii economice.
b) În cazul activităţii de producţie se prezintă:
1) fluxul de producţie, amplasarea locurilor de muncă, amplasarea depozitelor, regimul
de funcţionare etc.;
2) tipurile de produse, structura lor, ciclurile de realizare;
3) modul de organizare a producţiei, mişcarea internă a producţiei, controlul calităţii
lucrărilor, stocarea producţiei;
4) resursele existente;
5) capacităţile;
6) asigurarea tehnică / proiectarea de produse noi;
7) normele tehnice;
8) asigurarea cu materiale necesare;
9) sistemul existent de planificare a producţiei.
c) Studiul sistemului de conducere se referă la următoarele:
1) identificarea caracteristicilor sistemului de conducere existent;
2) sistemul de indicatori cantitativi, valorici şi calitativi;
3) structura organizării conducerii;
4) caracteristicile rezultate din ”statutul” de funcţionare a societăţii, tipuri de decizii,
modul de realizare a deciziilor, controlul îndeplinirii deciziilor.
a) Studiul sistemului informaţional presupune:
1) elaborarea schemei fluxului informaţional global (cu punerea în evidenţă a
principalelor activităţi şi a legăturilor statice şi dinamice dintre acestea);
2) estimarea cantitativă şi calitativă a informaţiilor de intrare-ieşire, modul de culegere şi
prelucrare;
3) identificarea principalilor algoritmi, regulilor de calcul şi a punctelor şi regulilor de
control;
4) cunoaşterea principalelor restricţii ale sistemului informaţional;
5) situaţia raţionalizării fluxurilor şi a documentelor din unitatea economică, studii
elaborate, stadiul lor de implementare;
6) sistemul de codificare utilizat, restricţii;
7) performanţele şi limitele sistemului informaţional existent.
Identificarea metodelor şi mijloacelor tehnice utilizate pentru prelucrarea datelor în
cadrul sistemului informaţional existent se face evidenţiind:
- mijloacele tehnice existente în dotarea unităţii economice (modul de utilizare,
cheltuielile de exploatare, personalul implicat, performanţele);
- existenţa unor aplicaţii proiectate şi/sau implementate.
Determinarea cerinţelor sistemului - activitate esenţială în aflarea situaţiei existente şi a
ceea ce se doreşte în viitor. Rezultatul activităţii de determinare a cerinţelor sistemului se
concretizează în diferite forme ale informaţiilor colectate, cum sunt:
- copii ale interviurilor;
- însemnări efectuate în timpul observării şi analizei documentelor;
 - interpretări ale răspunsurilor la chestionare;
- seturi de formulare;
- rapoarte;
- descrieri ale posturilor de lucru s.a., precum şi rezultate ale prelucrărilor efectuate de
calculator, cum ar fi prototipurile.

Rezultatele prezentate după această activitate pot fi rezumate astfel:

Informaţii obţinute în urma conversaţiilor cu utilizatorii sau prin observarea
activităţilor prestate de aceştia: copii sau sinteze ale interviurilor, răspunsurile la chestionare sau
interpretări ale acestora, însemnări şi rezultate din observarea activităţilor, procese-verbale ale
şedinţelor ce au avut loc în acest scop.
Informaţii scrise care există în unitate: misiunea şi strategia afacerii, exemplare ale
formularelor, rapoartelor şi machetelor de ecrane, manuale ale procedurilor, descrieri ale
posturilor de lucru, manuale de instruire, scheme de sisteme şi documentaţia sistemului existent,
rapoartele consultanţilor.
Informaţii obţinute cu ajutorul calculatorului: rezultate ale sesiunilor JAD (Joint
application design), copii ale fişierelor sesiunilor grupului de sprijinire a sistemului, conţinutul
depozitelor şi rapoartele existente în CASE, ecrane şi rapoarte rezultate din prototipurile
sistemului ş.a.
Analiza situaţiei şi identificarea cerinţelor sistemului nou
Cercetarea sistemului existent constă în următoarele:
- identificarea caracteristicilor generale ale obiectului automatizării;
- studiul activităţilor de bază desfăşurate în sistem;
- studiul sistemului de conducere;
- studiul sistemului informaţional;
- identificarea metodelor şi mijloacelor tehnice.
Definirea caracteristicilor generale ale organizaţiei pentru care va fi elaborat noul
sistem implică:
- cunoaşterea profilului, obiectivelor organizaţiei;
- cunoaşterea specificului activităţii de bază (producţie, servicii);
- cunoaşterea locului în sfera serviciilor şi/sau sfera producţiei;
- cunoaşterea relaţiilor de cooperare cu alţi agenţi economici;
- cunoaşterea nivelului tehnic;
- cunoaşterea principalilor indicatori de performanţă şi evoluţia lor;
- dezvoltarea, modernizarea etc.
Studiul activităţilor desfăşurate în sistemul economic, modul de realizare a
funcţiunilor unităţii economice se face astfel: pe baza statutului de funcţionare a organizaţiei se
studiază:
- fluxul de producţie, amplasarea locurilor de muncă, depozitelor etc.;
- tipurile de produse, structura lor, ciclurile de realizare;
- modul de organizare a producţiei, stocarea producţiei, transporturile interne, controlul
de calitate;
- resursele existente: capacităţi; asigurarea tehnică; proiectarea de produse noi, norme
tehnice;
- asigurarea cu materiale necesare;
- sistemul existent de programare a producţiei.
 Studiul sistemului de conducere se referă la următoarele:
- identificarea caracteristicilor SC existent;
- sistemul de indicatori cantitativi şi valorici;
- organizarea conducerii;
- caracteristicile rezultate din statutul de funcţionare a societăţii, tipuri de decizii, modul
de lucru a deciziilor.

Studiul sistemului informaţional presupune:

- elaborarea schemei fluxului informaţional global (cu punerea în evidenţă a
principalelor activităţi şi a legăturilor statice şi dinamice dintre acestea);
- estimarea cantitativă şi calitativă a informaţiilor de intrare-ieşire, modul de culegere şi
prelucrare a datelor;
- identificarea principalilor algoritmi, regulilor de calcul, a punctelor şi regulilor de
control;
- cunoaşterea principalelor restricţii ale sistemului informaţional;
- situaţia raţionalizării fluxurilor şi a documentelor din organizaţie, studii elaborate,
stadiul lor de implementare;
- sistemul de codificare utilizat, restricţii;
- performanţele şi limitele sistemului informaţional existent.
Formularea cerinţelor sistemului nou este o activitate esenţială în cunoaşterea situaţiei
existente şi a ceea ce se doreşte în viitor. Rezultatul activităţii de determinare a cerinţelor
sistemului se concretizează în diferite forme ale informaţiilor colectate, cum ar fi:
- copii ale interviurilor;
- însemnări efectuate în timpul observării şi analizei documentelor;
- interpretări ale răspunsurilor la chestionare;
- seturi de formulare, rapoarte;
- descrieri ale posturilor de lucru ş.a.;
- rezultate ale prelucrărilor efectuate de calculator cum ar fi prototipurile.
Activităţile enumerate pot fi executate total cu forţele achizitorului sau prin contractarea
unor servicii din partea unei organizaţii de consultanţă.

Rezultatele prezentate după etapa 1

Informaţii scrise care există în unitate: misiunea şi strategia afacerii, exemplare ale
formularelor, rapoartelor şi machetelor de ecrane, manuale ale procedurilor, descrieri ale
posturilor de lucru, manuale de instruire, scheme de sisteme şi documentaţia sistemului existent,
rapoartele consultanţilor.
Informaţiile obţinute în urma conversaţiilor cu utilizatorii sau prin observarea activităţilor
prestate de aceştia: copii sau sinteze ale interviurilor, răspunsurile la chestionare sau interpretări
ale acestora, însemnări şi rezultate din observarea activităţilor, procese-verbale ale şedinţelor ce
au avut loc în acest scop.
Informaţii obţinute cu ajutorul calculatorului: copii ale fişierelor sesiunilor grupului de
sprijinire a sistemului, conţinutul depozitelor şi rapoartele existente în CASE ecrane şi rapoarte
rezultate din prototipurile sistemului ş.a.
Materialele create vor fi folosite pentru următoarele:
- motivarea necesităţii elaborării şi implementării graduale a sistemului nou;
 - elaborarea sarcinii tehnice pentru crearea sistemului;
- perfectarea proiectului tehnic şi proiectului de lucru.
Raport special – studiul de fezabilitate a proiectului - poate fi parte componentă a acestor
rezultate. În acest raport vor fi clar definite beneficiile achizitorului, dacă va decide finanţarea
proiectului, termen în care produsul finit va fi lansat în exploatare, costurile aferente, modalitatea
şi graficul achitărilor, efectul economic şi timpul de recuperare a cheltuielilor.

6.2.2. Studiul de fezabilitate. Acest document va include cel puţin:

- constrângerile, riscurile, factorii critici care pot influenţa succesul;
- condiţiile de exploatare a viitorului sistem: arhitectura sistemului, resursele tehnice şi
logice, condiţiile de funcţionare, personalul de exploatare şi utlizatorii sistemului;
- termenele de finalizare a etapelor, forma de primire–predare a lucrărilor, resursele
implicate, măsurile de protecţie a informaţiei;
- descrierea funcţiilor sistemului;
- posibilităţile de dezvoltare viitoare a sistemului;
- obiectele informaţionale ale sistemului;
- interfeţele şi modalitatea de partajare a funcţiilor între om şi sistem;
- cerinţele privind componentele program şi informaţionale, SGBD;
- indicaţii privind lucrările care nu vor fi realizate în cadrul proiectului dat.
Va fi stabilită lista activităţilor, automatizarea cărora este recomandată şi ordinea în care
aceasta va avea loc.
Funcţiile planificate pot fi clasificate conform formatului MuSCoW: Must have – funcţii
obligatorii; Should have – funcţii dorite; Could have – funcţii posibile; Won't have – funcţii
lipsă.
Realizarea funcţiilor din categoria a doua şi a treia este limitată de cadrul temporal şi
financiar: va fi realizat tot ce este obligatoriu şi la maximum ce este dorit şi posibil în ordinea
priorităţilor.
Este foarte importantă ultima categorie de funcţii, deoarece este necesar să se stabilească
graniţele proiectului şi să se concretizeze explicit funcţiile care vor fi lipsă.
Analiza situaţiei şi identificarea cerinţelor sistemului nou. Modelele activităţii
organizaţiei vor fi de două categorii:
- modelul “cum este” (“as-is”) care reflectă procesele business existente în organizaţie;
- modelul “cum va fi” (“to-be”) care reflectă modificările necesare ale proceselor
business la introducerea SI.
Implicarea testerelor începând cu etapa de analiză. Vor participa:
- la soluţionarea problemelor legate de obţinerea caracteristicilor comparative ale
platformelor tehnice, ale sistemelor de operare, SGBD, alte medii de funcţionare;
- la elaborarea planului de lucru asociat fiabilităţii şi testării SI.
Rezultatele primei etape servesc la elaborarea Concepţiei (etapa 2) şi Sarcinii tehnice (etapa
3) a viitorului sistem informaţional.

6.2.3. Etapa 2. Elaborarea Concepţiei Sistemului Informaţional

Această etapă presupune următoarele lucrări:
- studii şi executarea lucrărilor de cercetare necesare;
- studierea obiectului automatizării;
 - elaborarea versiunilor Concepţiei discutate în grupul de lucru format din reprezentanţii
beneficiarului şi executorului;
- perfectarea versiunii finale a Concepţiei şi aprobarea ei de către conducere.
În reglementarea tehnică al Republicii Moldova RT 38370656 - 002:2006: Concepţia este
documentul iniţial, elaborat la crearea sistemului, care conţine rezultatele îndeplinirii lucrărilor
de cercetare ştiinţifică şi experimentală şi serveşte drept bază pentru elaborarea ulterioară a
documentaţiei tehnice.
În funcţie de scopurile propuse, se elaborează Concepţia de bază sau cadru.
Concepţia-cadru se elaborează în cazul când sistemul descris constă dintr-o multitudine
de sisteme independente sau interconectate, pentru care ulterior vor fi elaborate concepţii de
bază.
Concepţia-cadru se deosebeşte de cea de bază printr-o expunere rezumativă a materialului
sau prin lipsa capitolelor/ subcapitolelor separate, care sunt obligatorii pentru Concepţia de bază.
Destinaţia concepţiei constă în prezentarea viziunii generale asupra sistemului, funcţiilor
îndeplinite de sistem, descrierii spaţiului de drept şi informaţional, funcţional şi interacţiunii cu
alte sisteme informaţionale.
Concepţia sistemului informaţional conţine 10 capitole:
1. Introducere
2. Generalităţi
3. Spaţiul juridico-normativ al funcţionării sistemului
4. Spaţiul funcţional al sistemului
5. Structura organizaţională a sistemului
6. Documentele sistemului
7. Spaţiul informaţional al sistemului
8. Spaţiul tehnologic al sistemului
9. Asigurarea securităţii informaţionale
10. Încheiere

6.2.4. Etapa 3. Sarcina tehnică

Etapa elaborării Sarcinii tehnice (ST) include activităţi de elaborare prin iteraţii a
versiunilor ST, discutarea şi perfectarea lor, coordonarea şi aprobarea de către conducere.
În RT 38370656 - 002:2006, Sarcina tehnică (etapa 3) este documentul care determină
scopurile şi obiectivele, cerinţele şi datele principale de intrare necesare pentru elaborarea
sistemului informaţional.

La elaborarea ST vor fi soluţionate următoarele probleme:

- stabilirea scopului creării ST, determinarea funcţiilor şi a subsistemelor;
- elaborarea şi fundamentarea cerinţelor privind subsistemele;
- elaborarea şi fundamentarea cerinţelor privind baza informaţională, resursele;
- matematice, program şi tehnice (inclusiv, mijloacele de comunicaţie şi transmitere a
datelor);
- identificarea cerinţelor generale ale sistemului proiectat;
- determinarea listei lucrărilor de creare a sistemului şi a executorilor;
- determinarea etapelor creării sistemului şi termenelor de execuţie a acestora;
- calcularea preliminară a costurilor pentru crearea sistemului şi determinarea nivelului
de eficienţă economică a implementării lui.
 Structura Caietului de sarcini:
1. Generalităţi
2. Destinaţia şi scopurile creării /modernizării sistemului informaţional
3. Descrierea obiectului automatizării
4. Cerinţe funcţionale faţă de sistem
5. Componenţa şi conţinutul lucrărilor de creare a sistemului
6. Modul de testare / verificare şi predare / primire a sistemului
7. Cerinţe referitoare la componenţa şi conţinutul lucrărilor de pregătire a obiectului
automatizării pentru lansarea în exploatare a SI
8. Cerinţe privind documentaţia
9. Surse normative şi legale

1. Generalităţi:
- denumirea completă a sistemului şi abrevierea;
- codul (numărul) temei sau al contractului;
- denumirea organizaţiei executoare şi a beneficiarului, rechizitele lor;
- lista documentelor în baza cărora este creat sistemul;
- termene (executare) de începere şi finalizare a lucrărilor;
- informaţii despre surse şi modalitatea de finanţare;
- ordinea de perfectare şi prezentare a rezultatelor creării sistemului informaţional, a
părţilor sistemului sau a unor module separate
2. Destinaţia şi scopurile creării /modernizării sistemului informaţional:
a) categoria activităţilor de automatizare;
b) lista obiectelor pentru care va fi utilizat sistemul;
c) denumirea şi valorile solicitate ale indicatorilor:
1) tehnici;
2) tehnologici;
3) economici etc. care vor fi atinşi odată cu implementarea sistemului.
3. Descrierea obiectului automatizării:
- informaţii succinte despre obiectul automatizării;
- informaţii despre condiţiile de exploatare şi caracteristicile mediului ambiant.
3. Cerinţe funcţionale faţă de sistem
Cerinţe privind sistemul în totalitate:
- cerinţe referitoare la structura şi modul de funcţionare a sistemului (lista
subsistemelor, niveluri ierarhice, gradul de centralizare, modul de schimb informaţional,
regimurile de funcţionare, interacţiunea cu alte sisteme, perspectivele de dezvoltare);
- cerinţe privind personalul (roluri, calificarea, regimul de lucru, organizarea instruirii,
utilizatorii);
- indicatori asociaţi destinaţiei sistemului (adaptabilitatea la modificările sistemului de
conducere şi a valorilor parametrilor, scalabilitatea);
- cerinţe privind fiabilitatea, securitatea, ergonomia, transportabilitatea, exploatarea,
deservirea tehnică şi reparaţia, protecţia contra unor influenţe externe, drepturi de autor,
standardizare şi unificare.
Cerinţe referitoare la funcţionalităţi (pe subsisteme):
- lista activităţilor automatizate;
 - cadrul temporal de realizare a fiecărei funcţii;
- cerinţe privind calitatea realizării fiecărei funcţii, forma de prezentare a ieşirilor,
exactitatea şi autenticitatea datelor;
- lista şi criteriile de stabilire a căderilor (refuz serviciu).
Cerinţe referitoare la resurse:
- matematice (componenţa şi sfera utilizării modelelor şi metodelor matematice,
algoritmilor existenţi şi noi);
- informaţionale (componenţa, structura şi organizarea datelor, schimbul intern de date,
compatibilitatea informaţională cu alte sisteme, clasificatoarele utilizate, SGBD, controlul
datelor şi folosirea masivelor de date, procedurile de conferire a valabilităţii juridice
documentelor la ieşire);
- lingvistice (limbajele de programare, limbile de interacţiune a utilizatorilor cu
sistemul, sistemele de codare, limbajele pentru intrări/ieşiri);
- tehnice;
- metrologice;
- organizaţionale (structura şi funcţiile departamentelor de exploatare, protecţia contra
unor acţiuni eronate);
- metodice (documentaţia normativ-tehnică).

5. Componenţa şi conţinutul lucrărilor de creare a sistemului:

- lista stadiilor şi a etapelor;
- termene de executare;
- lista organizaţiilor executoare;
- modalitatea şi ordinea expertizării documentaţiei tehnice;
- programul de asigurare a fiabilităţii;
- programul de asigurare metrologică.

6. Modul de testare / verificare şi predare / primire a sistemului:

- tipurile, componenţa, volumul şi metodele de testare;
- cerinţe generale privind acceptarea lucrărilor pe etape;
- statutul comisiei de predare/primire.
-
6. Cerinţe referitoare la componenţa şi conţinutul lucrărilor de pregătire a obiectului
automatizării pentru lansarea în exploatare a SI:
- transformarea informaţiilor de intrare în formă maşinolizibilă (digitizare);
- modificările ce trebuie introduse în structura obiectului automatizării;
- termene şi modalitate de selectare şi instruire a personalului.

6. Cerinţe privind documentaţia:

- lista documentelor elaborate;
- lista documentelor pe suporţi magnetici.
9. Surse normative şi legale:
- legislaţie, standarde, documente şi materiale informaţionale în baza cărora a fost elaborat
ST şi sistemul informaţional.

6.2.5. Etapa 4. Proiectul tehnic

 Proiectul tehnic este documentul care include soluţiile generale sistemice de proiect,
algoritmii de soluţionare a problemelor, estimarea eficienţei economice a implementării
sistemului automatizat şi lista activităţilor pentru pregătirea implementării.
În cadrul acestei etape sunt executate lucrări experimentale şi de cercetare pentru alegerea
finală a soluţiilor principale de proiect şi calcularea eficienţei economice a implementării
sistemului.
Lucrări efectuate la elaborarea Proiectului tehnic:
- elaborarea soluţiilor de proiect pentru sistem şi părţile sistemului;
- elaborarea documentaţiei de proiect pentru sistem şi părţile lui;
- perfectarea documentaţiei de furnizare a componentelor;
- elaborarea sarcinilor pentru proiectarea părţilor conexe ale proiectului.
Proiectul tehnic conţine 9 capitole:
1. Notă explicativă
2. Structura funcţională şi organizaţională a sistemului
2. Enunţul problemei şi algoritmii de soluţionare
3. Organizarea bazei informaţionale
4. Albumul cu formele documentelor
5. Resursele matematice
6. Mijloacele tehnice necesare
7. Calculul eficienţei economice a sistemului
8. Măsuri privind pregătirea obiectului pentru implementarea sistemului
9. Borderoul documentelor
1. Nota explicativă va conţine:
- cadrul justificativ pentru elaborarea sistemului;
- lista organizaţiilor executoare;
 caracteristica succintă a obiectului cu lista indicatorilor tehnico-economici principali de
funcţionare şi legăturile cu alte obiecte;
 informaţii succinte privind soluţiile principale de proiect.
2. Structura funcţională şi organizaţională a sistemului va conţine:
- justificarea subsistemelor, lista şi destinaţia lor;
- lista lucrărilor îndeplinite în cadrul fiecărui subsistem, caracteristica succintă şi conţinutul
lucrărilor;
- schema legăturilor informaţionale dintre subsisteme şi lucrări în cadrul unui subsistem.
3. Enunţul problemei şi algoritmii de soluţionare va conţine:
- metoda, periodicitatea şi timpul de rezolvare, metodele de colectare şi transmitere a
datelor, relaţia cu alte sarcini, natura utilizării rezultatelor;
- modelul economic şi modelul matematic al problemei (prezentarea structurală şi
detaliată);
- informaţii normative (conţinutul şi forma de prezentare);
- informaţii privind interconexiunile cu alte sarcini şi procese;
- informaţii pentru decizii ulterioare referitoare la problema dată;
- informaţii cu privire la efectuarea modificărilor (modul de introducere a schimbărilor şi
lista informaţiilor care fac obiectul modificărilor);
- algoritmul de soluţionare a problemei (modelul proceselor, secvenţe şi paşi, schemă,
formule de calcul);
 - studiu de caz (set de formulare ale documentelor de intrare completate, documente
convenţionale de ieşire cu informaţii acumulate şi stocate, formulare ale documentelor de ieşire
completate cu rezultatele soluţionării problemei conform algoritmului elaborat).
4. Organizarea resurselor informaţionale va conţine:
- sursele de informaţii externe şi interne şi modul de transfer de la proces la proces;
- setul de indicatori utilizaţi de sistem;
- lista de documente, termene şi periodicitatea intrării;
- soluţiile principale de proiect privind organizarea fondului;
- componenţa bazei informaţionale, inclusiv rechizitele, ontologia şi taxonomia
informaţiei, marja de valori a datelor şi lista documentelor bazei informaţionale;
- lista masivelor, volumul lor, modalitatea şi frecvenţa corectării informaţiilor;
- structura fondului cu descrierea legăturilor dintre elementele constitutive, cerinţe
referitoare la tehnologia creării şi operării fondului;
- metodele de păstrare, căutare, modificare şi control;
- determinarea volumelor şi fluxurilor informaţionale;
- exemplu de control la introducerea unor modificări;
- propuneri privind unificarea documentaţiei.
5. Albumul cu formele documentelor va conţine:
- formele şi documentele primare;
- formele şi documentele interne;
- formele şi documentele de ieşire.
6. Resursele matematice:
- justificarea structurii resurselor matematice;
- justificarea alegerii mediului de programare (platforma de programare);
- lista resurselor program de sistem (sisteme de operare, SGBD).
7.Mijloacele tehnice necesare:
- descrierea şi motivarea schemei procesului tehnologic de prelucrare a datelor;
- justificarea alegerii structurii complexului tehnic şi grupurilor funcţionale ale acestuia;
- motivarea cerinţelor privind echipamentele speciale;
- motivarea cerinţelor privind reţelele de transport date;
- setul de acţiuni pentru asigurarea fiabilităţii funcţionării echipamentelor.
8.Calculul eficienţei economice a sistemului va conţine:
- devizul de cheltuieli pentru exploatarea sistemului;
- calculul eficienţei economice anuale obţinute din optimizarea structurii organizaţiei;
- diminuarea costurilor şi a pierderilor;
- îmbunătăţirea deciziilor administrative.
7. Măsuri privind pregătirea obiectului pentru implementarea sistemului va conţine:
- lista măsurilor organizaţionale pentru perfecţionarea proceselor business;
- lista lucrărilor pentru implementarea sistemului care sunt necesare în etapa proiectării
tehnice cu indicarea termenelor şi responsabililor.
9.Borderoul documentelor

6.2.6. Etapa 5. Proiectarea de detaliu

La elaborarea Proiectului de detaliu se vor desfăşura activităţile:
- elaborarea soluţiilor de preproiect pentru sistem şi părţile componente ale sistemului;
- scrierea codurilor de programe, testarea şi corectarea lor;
 - elaborarea documentaţiei de detaliu pentru sistem şi a părţilor componente.

6.2.7. Etapa 6. Implementarea codului şi perfectarea documentaţiei

- scrierea şi testarea codului modulelor;
- integrarea modulelor şi testarea subsistemelor şi a sistemului;
- elaborarea documentaţiei de lucru pentru sistem şi părţile lui.
În această etapă este creat produsul program şi elaborată documentaţia însoţitoare.
Documentaţia va include informaţiile necesare şi suficiente pentru îndeplinirea lucrărilor
de implementare a sistemului informaţional, cât şi pentru menţinerea nivelului caracteristicilor
funcţionale.
Calitatea este identificată prin testare.
Sunt stabilite următoarele tipuri de testări: preliminară, de exploatare-pilot şi testarea
finală. La necesitate pot avea loc testări suplimentare atât pentru întregul sistem, cât şi pentru
părţile componente.
În funcţie de legăturile interne ale componentelor şi obiectul automatizării, testările pot fi
autonome sau complexe. Testările autonome (de detaliu) includ unele părţi ale sistemului. Ele
sunt executate gradual, odată cu finalizarea unei părţi pentru darea în exploatare experimentală
(pilot). Testările complexe sunt executate pentru grupuri de părţi sau pentru întreg sistemul.
Pentru planificarea testărilor este creat documentul “Programul şi metodica testărilor”.
Responsabilul de crearea documentului este fixat în Contract sau Sarcina tehnică. Documentul
poate include teste sau exemple de control (în calitate de anexe).

6.2.8. Etapa 7. Lansarea în exploatare care presupune

- pregătirea obiectului automatizării;
- instruirea personalului;
- completarea sistemului cu toate componentele necesare;
- executarea lucrărilor de construcţie şi montare;
- lucrări de lansare şi depanare;
- testări preliminare;
- exploatarea-pilot;
- testare de primire-predare.

6.2.9. Etapa 8. Mentenanţa SI care presupune

- îndeplinirea lucrărilor în conformitate cu obligaţiunile de garanţie;
- deservirea postgaranţie.

6.3. Inginerie sistemelor informaționale bazată pe componente.

1.3.1. Proiectarea-tip
Mai poate fi numită ingineria softului bazată pe componente (Component Based Software
Engineering - CBSE).
CBSE – presupune proiectarea sistemelor software utilizând componente reutilizabile.
Crearea sistemului informațional se realizează din elemente existente apriori.
Metoda de proiectare cu utilizarea elementelor tipizate este bazată pe utilizarea soluţilor
de proiect reutilizabile (soluţie de proiect replicabilă). Condiţia principală pentru utilizarea unor
astfel de metode este capacitatea de a descompune sistemul informaţional proiectat în
componente (subsisteme, module software, complexe de sarcini etc.), pentru implementarea
cărora pot fi alese soluţii tip de proiect.
Suplimentar faţă de funcţionalitatea reală a software-ului şi hardware-ului, soluţiile-tip
trebuie să fie însoţite de documentaţia necesară în care este prezentată o descriere detaliată a
acestor soluţii (inclusiv procedurile de ajustare) în care se încadrează cerinţele sistemului
proiectat existente pe piaţă, care vor fi adaptate necesităților unei anumite companii.
Soluţie de proiect tirajată (SPT) pot fi clasificate în funcţie de nivelul decompoziţiei a
sistemului informațional:
- SPT pe elemente;
- SPT pe subsisteme;
- SPT pe obiecte.
1.3.1. Abordarea orientată pe parametri,
etape:
- determinarea criteriilor de estimare a SPT pentru soluţionarea problemelor în cauză;
- analiza şi evaluarea SPT accesibile conform criteriilor formulate;
- selectarea şi achiziția celei mai potrivite SPT;
- racordarea (adaptarea) parametrilor SPT procurate la cerințele sistemului proiectat.
La o astfel de abordare, soluţia de proiect tirajat este văzută ca o „cutie neagră”:
Flux informaţional (FI) - sunt datele primare procesate şi necesare pentru a obţine
rezultate.
Bloc funcţional - procesează datele primare şi formalizează rezultatul funcţionării
pachetului.
Flux de parametri (FP) - este informaţia necesară pentru ajustarea pachetului la
condiţiile concrete de funcţionare.
Blocul procesare parametri  - setul de module ce interpretează parametrii.
Blocul de adaptare - interacţionează cu blocul funcţional şi poate adăuga module sau să
le modifice.
Criterii de estimare a SPT:
- destinaţia şi posibilităţile pachetului;
- caracteristici şi proprietăţi ale pachetului;
- cerinţele pentru hardware şi software;
- documentaţia pachetului;
- factori de ordin financiar;
- caracteristici de instalare;
- caracteristici de exploatare;
- asistenţa furnizorului;
- calitatea pachetului şi experienţa de utilizare;
- perspectivele de dezvoltare a pachetului.

1.3.1. Instrumente CASE pentru analiză si proiectare structurată. Metodologia CASE.

CASE metod privind realizarea sistemelor informatice
Termenul CASE (Computer Aided Software Engineering) a fost introdus pentru prima
dată în anul 1987 de John Manley şi a desemnat instrumentele informatice concepute pentru a fi
utilizate în etapele de analiză şi proiectare, oferind facilităţi de reprezentare grafică specifice
acestor etape.
 Prin instrumente CASE înţelegem aplicaţiile software care-i sprijină pe analişti,
proiectanţi, programatori, inclusiv personalul de testare şi întreţinere, să analizeze, să
proiecteze, să implementeze (cel puţin parţial), să modifice (extindă), respectiv să construiască
teste pentru sistemele informatice.
Un produs de tip CASE reprezintă, aşadar, o colecţie de metode, instrumente şi procese
utilizate în ingineria software asistată de calculator. Aceste produse oferă suport pentru
automatizarea metodelor şi tehnicilor folosite pe parcursul ciclului de dezvoltare de sisteme
informatice, de aplicaţii, de programe.
Prima etapa din metodologia CASE*METHOD privind realizarea sistemelor
informatice este definirea strategiei obiective.
O proiectare cu succes a produselor software presupune o bună formulare şi înţelegere a
problemei, evidenţiind necesităţile informaţionale ale organizaţiei. Această înţelegere poate
conduce la o distincţie netă între analiză („ce trebuie făcut?") şi proiectare („cum trebuie făcut?")
de sistem.
Obiectivul etapei de strategie este de a elabora analiza obiectului pentru care se crează
sistemul informațional.
Această etapă constituie o analiză detaliată, completă a organizaţiei, reprezentând baza
dezvoltării ulterioare a sistemului informatic.
Distribuţia subetapelor fazei strategiei trebuie să pună clar în evidenţă obiectivele
urmărite de organizaţie prin proiectarea noului sistem (figura 6.5).
Subetape:
- definirea direcţiilor de analiză: obiective, priorităţi, limite, factori de influenţă;
- întocmirea diagramei entitate–relaţie;
- definirea ierarhiei de funcţii;
- recomandări de proiectare;
- problemele organizaţionale şi tehnologice;
- definirea limitelor sistemului;
- definirea unei posibile arhitecturi a sistemului;
- aproximarea necesarului de resurse.
 Fig.6.5. Etape de proiectare a sistemelor informaţionale

Abordarea orientată pe model

Abordarea orientată pe model presupune adaptarea componentelor şi caracteristicilor SPT
conform obiectului automatizării. Depozitul cu metainformaţii conţine modelul obiectului
automatizării în baza căruia are loc configurarea produsului program. În consecinţă, abordarea
model-orientată presupune construirea modelului obiectului automatizării, utilizând instrumente
program speciale (Utilizarea instrumentelor CASE, SAP Business Engineering Workbench
(BEW), BAAN Enterprise Modeler). Depozitul include modelul de bază (de referinţă) al SI,
modele-tip pentru diferite clase de SI, modelele SI ale unor organizaţii concrete.

Utilizarea instrumentelor CASE.

Utilizarea instrumentelor CASE generează o serie de facilităţi, şi anume:
- pot deveni suport pentru mai multe metode de analiză;
- sprijină conducerea proiectului;
- ajută la realizarea de prototipuri;
- generează documentaţia;
- generează automat coduri.
Instrumentele CASE oferă sprijin utilizatorului prin metodologiile prestabilite pe care
acesta le poate urma în cadrul proiectului de modelare/implementare a sistemului informatic
dorit. Instrumentele acestuia oferă sprijin la realizarea diagramelor pentru:
- activităţi, care reprezintă comportamentul operaţiilor ce utilizează seturi de acţiuni;
- clasele care exprimă structura statică a unui sistem relativ la clasele şi relaţiile dintre
ele;
- colaborările care ilustrează interacţiunile dintre obiectele utilizate: structură spaţială ce
reprezintă domeniul fizic;
- componentele care descriu componentele software ale unei aplicaţii în mediul de
implementare;
- distribuire care prezintă locaţiile componentelor software pe componente hardware;
- obiecte care exprimă structura statică a unui sistem în funcţie de toate obiectele sale şi
relaţiile dintre ele;
- secvenţe care ilustrează interacţiunile dintre obiecte, utilizând o structură temporală de
reprezentare a proceselor;
- tranziţiile stărilor care reprezintă comportamentul claselor, utilizând maşini de stări;
- cazurile de utilizare care sunt reprezentări ale funcţionalităţii unui sistem, din punctul
de vedere al utilizatorilor săi.

Pentru realizarea tuturor funcțiilor necesare proiectării unui sistem informatic

complex, indiferent de metoda de analiză şi proiectare pentru care oferă
suport, arhitectura unui sitem CASE trebuie să conțină următoarele
componente:
- Editor de diagrame
- Analizor de structură (cu facilitati de round-trip engineering )
- Depozit central de date (repository)
- Generator de cod
- Generator de documentație
- Instrumente pentru inginerie inversată(reverse engineering)
- Instrumente de testare
- Instrumente pentru managementul proiectului
- Interfața utilizator

Fig.6.4. Componentele unui sistem CASE

1.3.1. Componentele unui sistem CASE

Editorul de diagrame (figura 6.4). - este componenta obligatorie a oricărui produs de
tip CASE şi permite construirea şi modificarea tuturor tipurilor de diagrame utilizate de
metodologia / metodologiile implementate prin CASE. Introducerea informaţiilor în editor poate
fi făcută în două moduri:
- de către utilizator, prin intermediul unei interfeţe;
- din repository, când acesta este actualizat prin reverse engineering.
Editorul de diagrame trebuie să satisfacă următoarele condiţii:
- să permită introducerea şi modificarea uşoară a tuturor entităţilor grafice descrise de
metoda de proiectare;
- suprafaţa grafică să fie de calitate, să permită operaţii de zoom, de grupare şi aliniere a
elementelor diagramei;
- să permită tipărirea eficientă a documentelor şi paginarea lor precum şi selectarea
informaţiilor ce vor fi tipărite;
- să dea posibilitatea de a decide entităţile ce vor fi cuprinse într-o pagină fără a trunchia
informaţiile;
- să permită construirea automată a unor tipuri echivalente de diagrame;
- pentru realizarea acestor facilităţi şi deoarece opţiunile şi comenzile de editare a
diferitelor diagrame sunt foarte numeroase, editorul de diagrame foloseşte în general bare de
comenzi, cutii de dialog sau meniuri senzitive de context.
Baza de informaţii (repository) este, de asemenea, o componentă obligatorie care are
drept rol acumularea şi stocarea în maniera organizată a tuturor informaţiilor introduse de
persoane diferite în momente diferite, eventual în locuri diferite. Repository este elementul
central, inima unui CASE, care trebuie să memoreze toate informaţiile despre proiecte şi să
permită ca pornind de la acestea să se creeze informaţie nouă care să fie la rândul ei plasată în
repository.
Pentru un proiect sunt verificate şi corelate toate informaţiile existente în repository cu
scopul de a asigura integritatea şi consistenţa lor. Mai exact diferitele tipuri de diagrame
reprezintă aceeaşi informaţie privită din diferite puncte de vedere, deci trebuie să aibă o legătură
logică între ele.
Datele introduse în anumite diagrame pot fi utilizate şi în alte tipuri de diagrame şi
depozitul de date este cel care asigură consistenţa informaţiei între diferitele diagrame.
Modificările efectuate asupra unei entităţi dintr-o diagramă sunt automat reflectate în
reprezentarea ulterioară a aceleiaşi entităţi în orice altă diagramă. Dintre caracteristicile şi în
acelaşi timp avantajele oferite de acest instrument sunt următoarele:
- documentaţia de realizare a oricărui proiect, în totalitatea ei, se găseşte în repository,
de unde poate fi tipărită integral sau parţial şi la cerere;
- documentaţia finală a produsului software este realizată pe baza informaţiilor despre
proiect, conţinute în repository;
- creşterea preciziei şi a acurateţei documentaţiei faţă de cazul în care aceasta este
realizată pe hârtie, deoarece sunt detectate erorile, inconsistenţele; ştiut fiind că mai cu seamă în
cazul aplicaţiilor şi produselor software complexe elaborate în cadrul unei echipe aceste aspecte
sunt greu de controlat, asigură lucrul în echipă şi în reţea, pe de o parte prin accesul controlat; al
membrilor echipei la componente de diferite niveluri ale proiectului, pe de altă parte, prin
gestionarea legăturilor dintre componentele ce formează arhitectura unei aplicaţii, a unui proiect.
Analizorul de structură este componenta care are drept rol depistarea şi eliminarea unor
erori dificil de localizat şi tratat în fazele ulterioare celei de introducere a informaţiilor.
Analizorul este în strânsă legătură cu editorul de diagrame şi cu repository şi funcţia lui este de a
compara ultimele date introduse cu cele existente pe repository şi de a semnala:
- introducerea în acelaşi domeniu de vizibilitate (diagramă, dicţionar de date etc.) a două
entităţi de acelaşi tip, cu acelaşi nume;
- verifică dacă toate entităţile referite sunt definite;
- semnalează relaţii de moştenire definite circular;
- verifică corectitudinea semantică a adnotărilor formale.
Instrumentele pentru reverse engineering (inginerie inversă) au rolul de a reveni din
fazele de sfârşit ale realizării aplicaţiei în fazele de început, adică actualizarea diagramelor în
raport cu modificările efectuate în cod. Acest lucru permite dezvoltarea interactivă a unui produs
software prin bascularea între proiectare şi implementare.
Generatorul de cod permite transformarea în cod, într-un anumit limbaj de programare, a
diagramelor realizate în faza de proiectare.
Browserul specializat este instrumentul pentru vizualizarea informaţiilor unei mulţimi de
entităţi cu structură complexă, entităţi între care există o multitudine de relaţii. El permite accesul
direct al utilizatorului la diagramele care descriu proiectele conţinute în repository şi pentru a
facilita accesul la informaţii dispune de opţiuni de filtrare şi căutare. Aceste posibilităţi fac
posibilă regăsirea rapidă a resurselor unui proiect şi reutilizarea unor module în cadrul diferitelor
proiecte în curs de dezvoltare.
Generatorul de documentaţie conţine modele de documente şi oferă utilizatorului
posibilitatea de a-şi concepe propriile documente în mod flexibil. Fiind legat de repository,
furnizează informaţii la zi referitoare la proiect. Orice modificare a unei diagrame dintr-un
proiect induce modificarea automată a documentului asociat. Pot fi generate rapoarte standard
pentru monitorizarea unui proiect şi pentru evaluarea informaţiilor de dezvoltare, dar pot fi
realizate şi rapoarte proprii ale utilizatorului.
Gestiunea configuraţiei, configuraţia însemnând proiectul aplicaţiei, codul şi
documentaţia, toate putând fi gestionate global. Acest lucru permite membrilor echipei de
dezvoltare să lucreze în paralel şi în acelaşi timp să folosească informaţia conţinută în modelul
global pentru a dezvolta orice proiect nou.

Abordarea orientată pe model. Etapele realizării

Modelul de bază al sistemului informaţional din depozit include descrierea funcţiilor,
proceselor, obiectelor, regulilor business, structurii organizaţionale, pentru care pot fi utilizate
modele-tip.
Modelele-tip descriu configuraţiile sistemului informaţional pentru ramuri sau tipuri de
producţie.
Modelul unei întreprinderi concrete este construit sau prin alegerea unor fragmente ale
modelului de bază sau modelului-tip conform particularităţilor specifice ale întreprinderii
(BAAN Enterprise Modeler), sau prin adaptarea automatizată a acestor modele ca rezultat al
unor sondaje expert (SAP Business Engineering Workbench). Modelul construit al întreprinderii
este păstrat, sub forma unei metadescrieri, în depozit şi poate fi corectat la necesitate. În baza
acestui model are loc configurarea automată şi acordarea parametrilor sistemului.
Modelul funcţiilor business - decompoziţia ierarhică a activităţii întreprinderii.
Modelul proceselor business reflectă îndeplinirea lucrărilor pentru funcţiile la cel mai de
jos nivel. Pentru descrierea proceselor este utilizat modelul ЕРС – Event-driven Process Chain.
Modelele obiectelor business sunt utilizate pentru integrarea aplicaţiilor care realizează
diferite procese business.
Modelul structurii organizaţionale a întreprinderii - structură ierarhică sau matriceală
care include departamentele şi personalul.
Implementarea unui SI tip începe cu analiza cerinţelor, care sunt stabilite în etapa de
cercetare preproiect. După alegerea produsului program în baza modelelor de referinţă are loc
construirea modelului preliminar al SI, în care sunt reflectate toate particularităţile realizării SI
pentru întreprinderea dată. Modelul preliminar serveşte ca bază pentru alegerea modelului-tip al
sistemului şi determinarea listei componentelor, care vor fi realizate, utilizând alte resurse
program sau vor solicita crearea folosind instrumentele prezente în cadrul SI tip (de exemplu,
ABAP în SAP, Tools în BAAN).
Proiectarea sistemului informatic
În faza de proiectare a sistemului informatic vor fi preluate specificaţiile detaliate
elaborate în faza de analiză şi se vor definitiva structura bazei de date, modulele şi procedurile
funcţionale, formatele de intrare/ieşire şi ecranele aplicaţiei. Aceasta se va realiza în câteva
subetape:

Subetape:
- definirea arhitecturii sistemului;
- proiectarea modulelor;
- proiectarea fişierelor şi a bazei de date;
- detalierea dimensiunilor sistemului (aria de extindere);
- definirea modului de testare a sistemului;
 - întocmirea documentaţiei aproape de forma finală;
- revizuirea planului de dezvoltare a sistemului.
Proiectarea este un proces predominant iterativ, cu posibilitatea revenirii pe subetape,
când modul de finalizare a acestora nu este acceptat de către echipa de analiză–proiectare
(tabelul 6.1).

Tabelul 6.1. Avantajele și dezavantajele SPT

Clasa SPT
Avantaje
Realizarea SPT
SPT pe  abordare
elemente modulară pentru
Biblioteci de proiectarea și
programe documentarea SI
orientate pe
metode
SPT pe  nivel înalt de
subsisteme integrare a elementelor
Pachete de  permite
programe realizarea proiectării
aplicative modulare, adaptarea
parametrică a
componentelor program
pentru diferite obiecte
de gestiune
 asigură
diminuarea cheltuielilor
 documentare
bună a proceselor de
prelucrare a informației
SPT pe obiecte  integrarea
Proiecte SI de componentelor datorită
ramură unității metodologice și
informaționale,
compatibilității tehnice
și logice
 arhitectura
deschisă permite
utilizarea SPT pentru
diferite platforme
tehnice și logice
 scalabilitatea
permite configurarea SI
pentru un număr
variabil de posturi
Dezavantaje
 cheltuieli mari
de timp pentru
racordarea elementelor
eterogene ca rezultat al
incompatibilității
informaționale, logice
sau tehnice
 cheltuieli mari
de timp pentru
revizuirea SPT pentru
unele elemente
 adaptabilitate
insuficientă din punctul
de vedere al ingineriei
continue a proceselor
business
 probleme în
integrarea unor sisteme
diferite, în special în
cazul utilizării unor
soluții de la producători
diferiți
 pot apărea
probleme, generate de
legarea proiectului tip
de un obiect concret,
ceea ce poate conduce
în unele cazuri la
necesitatea modificării
structurii
organizaționale și
economice a obiectului
automatizării
  prin
configurare este
posibilă alegerea
componentelor

Instrumente CASE
• Vantage Team Builder (Westmount I–CASE);
• Designer/2000;
• Silverrun;
• ERwin+BPwin;
• S-Designor;
• CASE. Analitic;
• Rational Rose.