Proiectarea sistemelor informaionale

C ONINUT

1.

INTRODUCERE

1.1.

NOIUNI

1.1.1.
1.1.2.
1.1.3.
1.1.4.
1.2.

1.3.

CICLUL

2.1.

3.

INFORMATICE

ALE CICLULUI DE VIA

MODELUL CASCAD
MODELUL SPIRAL
ALTE MODELE
CICLULUI DE VIA

PROCESELE CONFORM ISO/IEC 12207

CONINUTUL PROCESELOR PRIMARE
PROCESELE CONFORM ISO/IEC 15288
ALTE STANDARDE I REGLEMENTRI
PROCESELOR DE DEZVOLTARE A SISTEMELOR INFORMAIONALE

PROIECTAREA

3.1.1.
3.1.2.
3.1.3.
3.1.4.
3.1.5.

DE REALIZARE A SISTEMELOR INFORMATICE

DE VIA A PRODUSELOR PROGRAM

ORGANIZAREA

3.1.

SI

CONINUTUL METODOLOGIILOR DE REALIZARE A SISTEMELOR

METODE I TEHNICI DE REALIZARE A SI
CARACTERISTICI ESENIALE ALE PRINCIPALELOR METODE
INSTRUMENTE CASE

PROCESELE

2.2.1.
2.2.2.
2.2.3.
2.2.4.

INFORMATICE

PLANIFICAREA DE SISTEM
ANALIZA I FORMAREA CERINELOR
PROIECTAREA
IMPLEMENTAREA I TESTAREA
MENTENAN I ASIGURAREA SECURITII

MODELE

2.1.1.
2.1.2.
2.1.3.
2.2.

PROCESULUI DE CREARE A

METODOLOGII

1.3.1.
1.3.2.
1.3.3.
1.3.4.
2.

OBIECTUL I METODELE CURSULUI

SISTEME INFORMAIONALE I SISTEME
CLASIFICRI
SCURT ISTORIC

ETAPELE

1.2.1.
1.2.2.
1.2.3.
1.2.4.
1.2.5.

DE BAZ DIN PROIECTAREA SISTEMELOR INFORMAIONALE

CANONIC A

SI

ETAPELE PROIECTRII CANONICE

ANALIZA SITUAIEI I IDENTIFICAREA CERINELOR SISTEMULUI
ELABORAREA CONCEPIEI SI I SARCINII TEHNICE
PROIECTUL TEHNIC
DOCUMENTAIA

NOU

3.2.

PROIECTAREA

3.2.1.
3.2.2.
3.2.3.
4.

ANALIZA

SOLUII PROIECT TIP

ETAPELE REALIZRII
MODELE DE COMPONENTE
I MODELAREA SPAIULUI FUNCIONAL AL IMPLEMENTRII

4.1.

MODELUL

4.2.

ABLOANELE

4.2.1.
4.2.2.
4.2.3.

TIP

BUSINESS COMPLET AL COMPANIEI

MODELRII BUSINESS ORGANIZAIONALE

ABLONUL
ABLOANE
ABLONUL

4.3.

CONSTRUIREA

4.4.

MIJLOACE

5.

PENTRU ELABORAREA MISIUNII

PENTRU FORMAREA AFACERILOR
DE DESCRIERE FLUX-PROCES

MODELULUI ORGANIZAIONAL-FUNCIONAL AL COMPANIEI

INSTRUMENTALE PENTRU MODELAREA ORGANIZAIONAL

SPECIFICAREA

CERINELOR FUNCIONALE

5.1.

MODELE

5.2.

ELEMENTELE

DE BAZ ALE ABORDRII PROCESUALE

5.3.

SELECTAREA

I CLASIFICAREA PROCESELOR

5.3.1.
5.3.2.
5.3.3.
5.3.4.
5.3.5.

DE FLUX PROCESUALE

TIPURI DE PROCESE BUSINESS

PROCESELE DE BAZ
PROCESELE DE MANAGEMENT
PROCESELE DE ASIGURARE
MODELUL BUSINESS DE REFERIN

5.4.

ANALIZA

5.5.

REZULTATELE

6.

ACTIVITII NTREPRINDERII

METODOLOGIA

6.1.

MODELUL

6.1.1.
6.1.2.
6.1.3.
6.1.4.
6.1.5.
6.1.6.
6.2.

6.3.

ETAPEI DE ANALIZ

MODELRII DOMENIULUI OBIECTIV

STRUCTURAL AL DOMENIULUI OBIECTIV

STRUCTURA OBIECTUAL
STRUCTURA FUNCIONAL
STRUCTURA MANAGEMENTULUI
STRUCTURA ORGANIZAIONAL
STRUCTURA TEHNIC
MODELE DE INTEGRARE

METODOLOGII

6.2.1.
6.2.2.
6.2.3.
6.2.4.

SI

DE MODELARE STRUCTURAL A DOMENIULUI OBIECTIV

METODA IDEF0
METODA FLUXURILOR DE DATE
METODA OBIECT-ORIENTAT
COMPARAREA METODELOR

METODA

SINTETIC

7.

MODELAREA

PROCESELOR BUSINESS N

7.1.

MEDIUL

7.2.

CONSTRUIREA

7.2.1.
7.2.2.
7.2.3.
7.2.4.
7.2.5.
7.2.6.
7.2.7.
7.2.8.
7.2.9.

INSTRUMENTAL

BPWIN

MODELULUI

IDEF0

OBIECTIVUL MODELRII I PUNCTUL DE VEDERE

TIPURI DE DIAGRAME
TIPURI DE SGEI
CODURILE ICOM
SGEI LIBERE I SGEI LEGATE
TUNELAREA SGEILOR
NUMIREA ACTIVITILOR I DIAGRAMELOR
DIAGRAMELE ARBORELUI NODURILOR I FEO
CHENARUL DIAGRAMEI

7.3.

FUZIONAREA

7.4.

CREAREA

8.

BPWIN

I SEPARAREA MODELELOR

BPWIN

RAPOARTELOR N

MODELAREA

BPWIN (PARTEA 2)

PROCESELOR N

8.1.

ANALIZA

8.2.

PROPRIETI

DEFINITE DE UTILIZATOR

8.3.

DIAGRAMELE

FLUXURILOR DE DATE

8.4.

DESCRIEREA

PROCESELOR N

8.5.

MODELAREA

IMITAIONAL

9.

RESURSELE

9.1.

RESURSE

9.1.1.
9.1.2.
9.1.3.
9.1.4.
9.2.

10.1.

RESURSE

INFORMAIONALE ALE

SI

INFORMAIONALE EXTERNE
TEHNICO-ECONOMICE

INFORMAIONALE INTERNE

PROIECTAREA FORMELOR DE ECRAN

BAZA INFORMAIONAL I METODELE DE ORGANIZARE
CERINE I METODE DE ORGANIZARE A PSTRRII FIIERELOR

MODELAREA

RESURSELOR INFORMAIONALE

MODELAREA

10.1.1.
10.1.2.
10.1.3.
10.2.

IDEF3

NOIUNI DIN DOMENIUL CLASIFICRII INFORMAIEI

REGULI DE CLASIFICARE A PRODUSELOR
CODIFICAREA INFORMAIEI TEHNICO-ECONOMICE
SISTEMUL UNIFICAT DE DOCUMENTARE

9.2.1.
9.2.2.
9.2.3.
10.

COSTURILOR

ERD: NOIUNI DE
METODA IDEF1
METODA IDEF1X

MODELAREA

10.2.1.

DATELOR
BAZ

DATELOR N

DOCUMENTAREA

ERWIN

MODELULUI

10.2.2.
10.2.3.
10.3.

SCALABILITATEA
INTERFAA ERWIN

CREAREA

10.3.1.
10.3.2.
10.3.3.
10.3.4.
10.3.5.
10.3.6.
10.3.7.
10.4.

NIVELELE MODELULUI LOGIC

ENTITI I ATRIBUTE
RELAIA
TIPURILE ENTITILOR I IERARHIA
CHEI
NORMALIZAREA DATELOR
DOMENII

CREAREA

10.4.1.
10.4.2.
10.4.3.
10.4.4.
10.4.5.
10.4.6.
10.4.7.
10.4.8.
11.

REGULI DE VALIDARE I VALORI IMPLICITE

IDICI
TRIGGERE I PROCEDURI STOCATE
PROIECTAREA DEPOZITELOR DE DATE
CALCULAREA VOLUMULUI BD
PROIECTAREA DIRECT I INVERS
GENERAREA CODULUI PRII CLIENT N ERWIN
CREAREA RAPOARTELOR I GENERAREA DICIONARELOR
UML

DIAGRAMA USE CASE

DIAGRAMA DE ACTIVITATE
STATECHART DIAGRAM
DIAGRAMA CLASELOR

ETAPELE

11.2.1.
11.2.2.
11.2.3.
11.2.4.

1.

FOLOSIND

DIAGRAMELE UML

11.1.1.
11.1.2.
11.1.3.
11.1.4.
11.2.

MOTENIRII

MODELULUI FIZIC AL DATELOR

PROIECTAREA SI

11.1.

12.

MODELULUI LOGIC AL DATELOR

SI

CU AJUTORUL

UML

CREAREA MODELULUI CONCEPTUAL

ELABORAREA CERINELOR SISTEMULUI
ELABORAREA MODELELOR BD I APLICAIILOR
PROIECTAREA REALIZRII FIZICE A SISTEMULUI

STUDIU
STUDIU

PROIECTRII

DE CAZ

DE CAZ

COMPANIA MED

COMPANIA MED

""

-

1.1. 1.
1.2. 2.
1.3 3.
2.1. 4. DFD
3.1. 1.
3.2. 2. -
3.3. 3.
,
3.4. 4.
4.1. 1.

4.2. 2. -
4.3. 3.
4.4. 4.
4.5. 5.
4.6. 6.
4.7. 7.
4.8. 8.
4.9. 9.
4.10. 10.
4.11. 11.
4.12. 12.
4.13. 13.
4.14. 14.
4.15. 15.
4.16. 16.
4.17. 17.
5.1.
5.2. ()
5.3.
5.4.
5.5. ()
5.6.
5.7.

5.8.
5.9.
6.1. - " "
6.2. - "- ( )"
6.3. - ""
6.4. - " "
7.1.
7.2. - " , "
7.3. - - " "
7.4. - "
"
7.5. - " "
7.6. - ", , "
7.7. - ". "
7.8. - ". "

1.
2.
3.
4.
5.
6.
7.
8.

9.
9.1.
9.2.
9.3.
10.1. -
11.1.
11.2.
11.3.

1. Introducere
1.1.

Noiuni de baz din proiectarea sistemelor

informaionale
Obiectul i metodele cursului Proiectarea sistemelor informaionale. Noiune de sistem
informaional i sistem informatic. Clase de sisteme informaionale. Particularitile principale
ale proiectelor SI contemporane. Etapele crerii SI: planificarea sistemului, formarea
cerinelor, proiectarea conceptual, specificarea aplicaiilor, modelarea, integrarea i testarea.
Metode ale ingineriei software n proiectarea SI.

1.1.1.

Obiectul i metodele cursului

Suportul de curs este dedicat studierii metodelor i mijloacelor moderne de proiectare a

sistemelor informaionale (SI), inclusiv a unor instrumente din categoria proiectrii asistate de
calculator a produselor program (CASE Computer Aided Software Engineering). Vor fi
studiate componena i structura claselor SI ca obiecte de proiectare, tehnologiile moderne de
proiectare i metodele de demonstrare a eficienei utilizrii lor, etapele proiectrii SI,
particularitile etapelor n dependen de tehnologia proiectrii, scopurile i obiectivele
cercetrilor preproiect, metodele de modelare a proceselor informaionale, clasificri i
caracteristici generale ale instrumentelor CASE moderne.
Fundamentul tiinific al cursului este format din metodele analizei de sistem i modelrii, care
permit soluionarea urmtoarelor probleme:
asigurarea funcionalitii solicitate a sistemului i adaptarea la condiiile
variabile de funcionare;
proiectarea obiectelor, realizate n sistem;
implementarea programelor i interfeelor (forme de ecran, rapoarte), care vor
asigura vizualizarea rezultatelor interpelrilor la bazele de date;
luarea n consideraie a mediului i tehnologiei de realizare a proiectului:
topologia reelei, configurarea resurselor tehnice, arhitectura folosit etc.
Disciplina are ca scop familiarizarea studenilor cu tehnologiile informaionale de analiz a
sistemelor tehnice mari i metodele de proiectare a SI, bazate pe standarde internaionale,
nvarea principiilor construirii modelelor funcionale i informaionale, modalitilor de
analiz a rezultatelor obinute, utilizarea mijloacelor instrumentale de asistare a proiectrii SI.

1.1.2.

Sisteme informaionale i sisteme informatice

Din perspectiva sistemic, structura unei organizaii include trei componente principale (fig.
1.1):
Sistemul de conducere sau decizional (S.D.),
Sistemul informaional (S.I.),

Sistemul condus sau operaional (S.O.).

Fig. 1.1. Structura unei organizaii

Orice organizaie are nevoie de un sistem informaional pentru ai satisface necesarul de
informaie. Sistemul informaional este ansamblul de oameni, echipamente, produse program,
procese i date destinate s furnizeze informaii sistemului decizional, informaii necesare
pentru soluiionarea problemelor cu care se confrunt organizaia. Sistemul informaional face
legatura ntre sistemul de conducere i sistemul condus i este subordonat sistemului de
conducere.
Sistemul informatic este ansamblul structurat de elemente intercorelate funcional
destinate automatizrii proceselor de obinere a informaiilor i fundamentrii deciziilor.
Sistemul informatic este inclus n cadrul sistemului informaional, presupunnd partea
automatizat a acestuia.
Sistemul informaional cuprinde ansamblul informaiilor interne i externe utilizate n cadrul
organizaiei, precum i datele care stau la baza obinerii lor, procedurile de obinere i de
diseminare a informaiilor, personalul implicat n culegerea, transmiterea, stocarea i
prelucrarea datelor.
Sistemul informaional are dou componente:
componenta pentru stocarea (memorarea) informaiilor;
componenta pentru prelucrarea informaiilor.
Funciile unui sistem informaional sunt:
s colecteze informaii din sistemul operaional i cel decizional, precum i
informaiile ce provin din mediul extern;
s prelucreze informaiile la cererea sistemului operaional i sistemului
decizional;
s memoreze informaiile colectate, precum i informaiile rezultate din
prelucrare;
s asigure accesul la memorie n vederea comunicrii informaiilor stocate.
Sistemul operaional este compus din ansamblul procedurilor i persoanelor care
ndeplinesc sarcinile ce se desfoar n organizatie. n cadrul acestui sistem are loc
implementarea i realizarea strategiilor organizaiei.
Sistemul informatic este acea parte a sistemului informaional, care cuprinde culegerea,
prelucrarea i transmiterea automat a datelor i informaiilor din cadrul sistemului
informaional. Prin implementarea unor modele matematice i utilizarea tehnicii electronice de
calcul, sistemul informatic imprim valene sporite sistemului informaional sub aspect
cantitativ i calitativ. Are loc creterea capacitii de calcul sub aspectul volumului datelor
prelucrate i a operaiilor efectuate, nsoit de creterea exactitii informaiilor, sporirea
operativitii i complexitii situaiilor de informare - raportare. Toate aceste aspecte
determin o apropiere mai mare a decidentului de fenomenele i procesele economice pe care
acesta le are n atenie, cu multitudinea aspectelor economice pozitive ce deriv din acestea.

Sistemul informatic tinde spre a egala sistemul informational, ns acest lucru nu va fi posibil
datorit limitelor sistemului informatic. Tot timpul n cadrul sistemului informaional vor exista
o serie de activiti ce nu vor putea fi automatizate. Ins, dac acceptm includerea n sfera
sistemului informatic a activitii de conducere a proceselor tehnologice folosind
calculatoarele de proces, putem asista la automatizarea complet a procesului decizional i a
reglrii automate a procesului tehnologic. ntr-o astfel de situaie, sistemul informatic
depete sfera SI.

1.1.3.

Clasificri

Diversitatea problemelor rezolvate cu ajutorul SI a dus la apariia unor multiple tipuri de

sisteme, diferena constnd n principiile de creare i modalitatea de prelucrare a informaiilor.
Clasificarea de mai jos are la baz cele mai semnificative caracteristici care definesc
posibilitile funcionale i particularitile de construire a sistemelor moderne. n funcie de
tipul datelor, nivelul automatizrii, sfera utilizrii, mijloacele tehnice utilizate, modul de
funcionare a organizaiei etc., sistemele informaionale pot fi mprite n mai multe grupuri
sau clase (fig. 1.2).

Fig. 1.2. Clasificarea sistemelor informaionale

Conform tipului de date manipulate, SI se mpart n factografice i de procesare a
documentelor. Sistemele factografice pstreaz i proceseaz date structurate de tip
numeric i texte. Asupra acestor date pot fi executate diferite operaii. n SI de procesare a
documentelor informaia este prezent sub form de documente, care constau din denumiri,
descrieri, adnotri i texte (coninut). Cutarea n cadrul datelor nestructurate are loc cu
utilizarea caracteristicilor semantice. Funciile principale ale unor asemenea sisteme constau
n punerea la dispoziia utilizatorului a documentelor selectate, iar prelucrarea datelor are loc
ntr-o msur nesemnificativ.
n conformitate cu nivelul de automatizare a proceselor SI se mpart n sisteme cu
prelucrare manual, automat i automatizat.
n sistemele cu prelucrare manual mijloacele tehnice de procesare a informaiei sunt lips, iar
toate operaiile sunt ndeplinite de oameni.

n sistemele cu prelucrarea automat a informaiilor toate operaiile sunt executate fr

participarea omului.
Sistemele cu procesare automatizat presupun participarea i a omului, i a mijloacelor
tehnice, rolul principal n execuia operaiilor de rutin aparinnd calculatorului. Observm, c
aceast ultim categorie de sisteme corepsunde noiunii de sistem informaional.
n dependen de caracterul prelucrrii informaiei SI se mpart n sisteme n care sunt
preponderente operaiile de cutare i sisteme n care prevaleaz calculele.
Primele realizeaz introducerea, sistematizarea, pstrarea, extragerea informaiei la solicitarea
utilizatorului fr transformri prea complicate a datelor. Din aceast categorie sunt sistemele
informaionale bibliotecare, sistemele de rezervare i vnzare a biletelor sau camerelor de
hotel etc. n sistemele din categoria a doua, suplimentar, sunt prezente n mare msur
operaiile aritmetice sau logice de prelucrare a informaiei.
n dependen de modul de utilizare a informaiei la ieire SI se mpart n sisteme de gestiune
i sisteme de asistare a procesului de luare a deciziilor. Informaia rezultant din sistemele de
gestiune este transformat direct n aciuni ale omului sau chiar ale sistemului. Pentru aceste
sisteme sunt caracteristice calculele numerice i prelucrarea unor cantiti mari de date. Ca
exemplu, pot fi menionate SI de planificare a produciei, pentru gestiunea comenzilor sau de
eviden contabil.
Sistemele suport pentru procesul de luare a deciziilor produc informaii, care sunt acceptate de
om i pot fi luate n consideraie la formarea deciziilor, fr a iniia n mod obligator aciuni
concrete. Din aceast clas fac parte sistemele, care imit procesele intelectuale de prelucrare
a cunotinelor, de exemplu sistemele expert.
n dependen de sfera de utilizare exist urmtoarele clase ale SI:
SI de gestiune organizaional sunt destinate automatizrii funciilor personalului de
conducere a ntreprinderilor industriale, dar i a obiectelor din sfera prestrii serviciilor
(hoteluri, bnci, etc.).
Funciile principale ale acestor sisteme sunt: controlul operativ i reglarea, evidena operativ
i analiza, planificarea operativ i de perspectiv, evidena contabil, gestiunea vnzrilor
sau/i achiziiilor i alte sarcini economice sau organizaionale.
SI de gestiune a proceselor tehnologice automatizeaz funciile personalului responsabil
de executarea operaiilor tehnologice. n aceste sisteme sunt prezente mijloace performante
de msurare a parametrilor proceselor tehnologice (temperatura, presiunea, componena
chimic etc.), proceduri de control al valorilor parametrilor i de reglare a proceslor
tehnoloigce.
SI de proiectare asistat de calculator (CAD Computer Aided Design) automatizeaz
funciile inginerilor proiectani, constructorilor, arhitecilor, designer-ilor care creaz tehnologii
sau dispozitive tehnice noi. Fuciile principale ale acestor sisteme sunt executarea calculelor
inginereti, crearea documentaiei de proiect, incluisv documentaia grafic (scheme, desene,
planuri), modelarea obiectelor proiectate.
SI integrate (corporative, SIC) sunt utilizate pentru automatizarea tuturor funciilor unei
organizaii i acoper ntreg ciclul de lucrri de la planificarea activitii pn la livrarea
produciei. SIC includ o serie de module (subsisteme), care funcioneaz ntr-un spaiu
informaional unitar i ndeplinesc funciile de susinere a direciilor de activitate. Sarcinile
tipice realizate de subsistemele SIC sunt prezentate n tabelul 1.1.
Tabelul 1.1. Destinaia funcional a modulelor SIC
Subsistemul
Subsistemul
Evidena
Subsistemul
Subsistemul
Alte
Eviden
Marketing
Producere
subsisteme
resurselor
financiar
umane

Cercetarea pieei
i prognoza
vnzrilor

Planificarea volumelor

Gestiunea
vnzrilor

Controlul operativ i

Recomandri
privind produsele
noi

Analiza modului de

Analiza i stabilrea

Participare la formarea

preurilor

comenzilor clienilor
Gestiunea stocurilor

de lucru i elaborarea
planurilor calendar
gestiunea produciei

Evidena
comenzilor

funcionare a

Administrarea
portofoliului de
comenzi

Analiza i
prognoza
necesitilor n
resurse umane

Controlul activitii
companiei

Managementul
politicii de
creditare
Elaborarea planului
financiar

Meninerea arhivei

Depistarea
problemelor
operative
Analiza situaiilor
de gestiune
operativ i
strategic

echipamentelor

de personal
Analiza i
planificarea
pregtirii cadrelor

Analiza financiar
i prognozarea

Elaborare soluii
strategice

Gestiunea
bugetului, evidena
contabil i
calcularea
salariului

Analiza situaiei curente a pieei SI demonstreaz o tendin stabil de cretere a cererii n SI

corporative integrate, automatizarea unor funcii separate fiind considerat etap depit.
n tabelul 1.2 este prezentat lista unor produse program populare, la moment sisteme
informaionale de gestiune organizaional.
Tabelul 1.2. Clasificarea pieei sistemelor informaionale
Sisteme integrate
Sisteme integrate
Sisteme integrate mari
Sisteme locale
mici
medii
(corporative)

Concorde
MS-Business
SAP/R3 (SAP AG)
XAL Exact
Solutions - Navision,

Baan (Baan)
Axapta
NS-2000

BPCS (ITS/SSA)
Platinum PRO/MIS
J D Edwards

OEBS (Oracle E(Robertson & Blums)

Scala
Business Suite)
SunSystems
MFG-Pro

(QAD/BMS)
-
SyteLine

1C(COKA/SYMIX)

n dependen de nivelul la care sunt utilizate SI pot fi mprite n operaionale, pentru

specialiti, pentru management, de nivel strategic.
SI de nivel operaional sprijin executorii procesnd date despre tranzacii i evenimente
(conturi, facturi, salarii, credite, materii prime). Aceste sisteme realizeaz legtura ntre
organizaie i mediul extern. La acest nivel sarcinile, obiectivele, sursele de informaii i
algoritmii de procesare sunt cunoscute apriori i n mare msur sunt bine structurate.
SI pentru specialiti sprijin prelucrarea datelor i cunotinelor, sporesc performana
inginerilor i proiectanilor. Sarcina acestor sisteme este obinerea i integrarea informaiilor
noi n organizaie i acordarea ajutorului n prelucrarea documentelor pe hrtie.
SI pentru nivelul managementului sunt folosite de lucrtorii din veriga medie de conducere
pentru monitorizare, control, adoptare a deciziilor i administrare. Funciile principale sunt:
compararea indicatorilor cureni cu cei istorici,

elaborarea unor rapoarte pentru anumite intervale de timp,

asigurarea accesului la informaia din arhive, etc.
SI de nivel strategic susin procesul de luare a deciziilor pentru realizarea obiectivelor
strategice de dezvoltare a organizaiei. Ele sprijin managementul superior n rezolvarea
problemelor nestructurate i planificarea pe termen lung. Sarcina principal a acestor sisteme
este s asigure posibilitatea comparrii schimbrilor care au loc n mediul extern cu potenialul

organizaiei, s asiste procesul de adoptare a deciziilor n situaii complicate.

Din punctul de vedere al realizrii tehnice i logice pot fi evideniate cteva arhitecturi
tip: arhitectura tradiional file-server sau servere ale Bazelor de Date (client-server),
arhitectura SIC, bazat pe tehnologia Internet (aplicaii Intranet), arhitectura bazat pe
depozite de date (Data Warehouse).

1.1.4.

Scurt istoric

Industria sistemelor informaionale automatizate i are nceputurile n anii 1960, iar spre finele
secolului XX a cptat forme bine conturate. La prima etap metoda principal de proiectare a
SI era metoda de jos - n sus (bottom-up) conform creia sistemul era creat ca un set de
aplicaii, importante la moment, pentru susinerea activitii ntreprinderii (automatizarea
insular). Scopul principal al acestor proiecte nu era crearea unor produse reutilizabile
(tirajate), ci satisfacerea necesitilor curente ale unei instituii concrete. Aceast abordare mai
poate fi ntlnit, chiar dac mai rar, i astzi. n cadrul automatizrii insulare la un nivel
relativ bun este asigurat susinerea unor funcii, ns lipsete practic strategia automatizrii
complexe, iar combinarea unor subsisteme funcionale devine o problem separat, adesea
foarte complicat.
Prin crearea departamentelor de automatizare ntreprinderile au ncercat s rezolve
problemele cu fore proprii. ns modificrile permanente ale proceselor tehnologice,
procedurilor de lucru i a instruciunilor asociate, dificultile legate de modul diferit de
abordare a acelorai date de utilizatori diferii, conduceau la necesitatea perfecionrii
continue a produselor program pentru satisfacerea solicitrilor beneficiarilor. n consecin,
att lucrul programatorilor, ct i sistemele informaionale create, generau nemulumirea
conducerii i a utilizatorilor sistemului.
Urmtoarea etap este legat de contientizarea faptului, c exist necesitatea n mijloace
relativ standardizate de automatizare a activitii diferitor ntreprinderi i organizaii. Din ntreg
spectrul de probleme au fost evideniate cele mai vizibile: automatizarea evidenei contabile i
automatizarea proceselor tehnologice. Sistemele au nceput a fi proiectate de sus-n jos
(top-down), presupunnd c o aplicaie trebuie s satisfac necesitile mai multor
utilizatori.
Ideea utilizrii unui program universal introduce constrngeri substaniale privind posibilitile
dezvoltatorilor de sisteme la formarea structurii bazei de date, formelor de ecran sau alegerea
algoritmilor de calcul. Cerinele rigide, impuse de sus, diminueaz posibilitile de adaptare
flexibil a unui sistem, realizat pentru o ntreprindere oarecare, la activitile specifice ale unei
alte ntreprinderi cnd trebuie s se ia n consideraie particularitile evidenei analitice i
tehnologice, procedurile proprii de prelucrare a datelor, individualizarea interfeei pentru
fiecare post de lucru innd cont de funciile, tehnologiile, drepturile i responsabilitile unui
utilizator concret. La toate acestea se mai adaug faptul, c clienii naintau tot mai multe
cerine, generate de necesitatea crerii unor sisteme integrate de management i de
planificare a activitii ntreprinderii.
Etapa actual este caracterizat prin apariia unor opiuni noi, cum ar fi servicii program
bazate pe Internet, outsourcing, soluii customizabile de la consultani IT etc., care fac
alegerea unui SI mult mai complicat. Suplimentar, indiferent de metoda de dezvoltare,
lansarea unui sistem informaional nou genereaz nu doar beneficii, ci i riscuri. Cel mai mare
risc este atunci cnd o companie incearc s decid cum va fi consturit sistemul nainte de a
stabili ce trebuie s fac sistemul. Astfel a aprut necesitatea stringent de creare a unei
metodologii noi n proiectarea sistemelor informaionale. Scopul acestei metodologii era de a
reglementa procesul de proiectare a SI i de a asiguara gestiunea acestui proces, pentru a
garanta conformitatea cu cerinele referitoare la sistem, precum i la caracteristicile procesului
de dezvoltare. Principalele obiective, care trebuiau atinse prin noua metodologie erau:
s se asigure crearea de SI corporative integrate, n concordan cu scopurile i
obiectivele organizaiei, precum i cu cerinele privind automatizarea proceselor
business;
s se garanteze crearea unui sistem cu calitatea solicitat, n intervalul de timp

specificat i cu un buget de proiect stabilit;

s fie facilitat procesul de mentenan, modificare i extindere a capacitilor
sistemului;
s fie asigurat continuitatea dezvoltrii ntreprinderii, adic utilizarea n sistem
a infrastructurii informaionale existente.
Implementarea unei astfel de metodologii ar mai trebui s conduc la diminuarea nivelului de
complexitate a procesului de creare a SI din contul descrierii mai complete i mai exacte a
acestui proces, dar i utilizrii metodelor i tehnologiilor moderne de creare pe ntreg ciclul de
via a SI de la concepere pn la exploatare i ntreinere.

1.2.

Etapele procesului de creare a SI

Proiectarea SI acoper trei domenii de baz:

proiectarea obiectelor, care vor fi realizate n baza de date;
proiectarea programelor, formelor de ecran, rapoartelor, care vor asigura
vizualizarea rezultatelor interpelrilor la baza de date;
luarea n consideraie a mediului concret sau tehnologiei, i anume: topologia
reelei, configuraia resurselor tehnice, arhitectura (file-server, client-server, etc.).
Proiectarea SI ncepe cu determinarea obiectivelor proiectului. La nivel general obiectivul
proiectului poate fi soluionarea unui set de probleme interdependente, set care include la
momentul lansrii sistemului i pe ntreaga perioad de exploatare:
funcionalitatea dorit a sistemului i adaptabilitate la schimbarea condiiilor de
funcionare;
productivitatea solicitat;
timp de rspuns acceptabil;
fiabilitate i lipsa cderilor;
nivel suficient de securitate;
simplitate n utilizare i ntreinere.
Conform metodologiei moderne, procesul proiectrii SI include crearea i transformarea
succesiv a unui ir de modele coordonate pe etapele ciclului de via a sistemului. La fiecare
etap sunt create modele specifice etapei de organizare, referitoare la cerine ctre proiect,
referitoare la sistem sau aplicaii, etc. Modelele sunt create de ctre grupurile de lucru din
cadrul echipei proiectului, sunt acumulate i pstrate n depozitul (repozitoriul) proiectului.
Crearea modelelor, verificarea i validarea lor, prezentarea pentru utilizare colectiv are loc
folosind instrumente program speciale mijloace CASE.
Procesul de creare a SI include o serie de stadii i etape, limitate n timp i care au drept
finalitate crearea unui produs concret model, program, documentaie etc. Sunt evideniate
urmtoarele cinci etape ale ciclului de via a SI: planificarea, analiza, proiectarea,
implementarea, mentenana cu asigurarea securitii sistemului.

1.2.1.

Planificarea sistemului

Aceast etap ncepe de obicei cu o cerere formal ctre departamentul IT, numit solicitare
de sistem nou, n care sunt descrise problemele sau modificrile dorite a fi operate n
sistemul informaional existent sau ntr-un proces business. n multe companii planificarea
sistemelor IT este parte component a ntregului business-process de planificare a instituiei.
Atunci cnd managerii sau utilizatorii i elaboreaz planurile de activitate, ei includ de obicei
i anumite solicitri IT, care genereaz cerine de sistem. O cerin de sistem poate veni de la
un top manager, o echip de planificare, un ef de departament sau din partea
departamentului IT. Cerina poate fi foarte important sau relativ minor. O cerin important
poate conduce la necesitatea crerii unui nou sistem sau la modernizarea sistemului existent.
O cerin minor poate solicita o nou funcionalitate sau o simpl modificare a interefeei
utilizatorului.

Scopul acestei etape const n efectuarea unei anchete preliminare pentru a evalua o
oportunitate sau o problem din IT. Ancheta preliminar este un pas important, deoarece
rezultatul va afecta ntregul proces de dezvoltare. O parte cheie a anchetei preliminare este un
posibil studiu de fezabilitate, n care sunt analizate costurile i beneficiile anticipate i sunt
recomandate anumite aciuni, reieind din factorii tehnici, operaionali, economici i de timp.
Ancheta ar putea stabili c sistemul existent funcioneaz corect, dar utilizatorii au nevoie de
mai mult instruire. n unele situaii, s-ar putea recomanda o revizuire a proceselor business,
mai degrab dect o soluie IT. n alte cazuri, s-ar putea trage concluzia c o modificare
important a sistemului este necesar. n acest caz procesul de dezvoltare va continua, iar
urmtorul pas este etapa de analiz a sistemului.

1.2.2.

Analiza i formarea cerinelor

Scopul acestei etape este construirea modelului logic al sistemului nou. n cadrul primului pas modelarea cerinelor , are loc cercetarea proceselor i sunt documentate funcionalitile noului
sistem, solicitate de utilizatori. Modelarea cerinelor continu investigaiile ncepute la etapa
planificrii sistemului. Urmeaz modelarea proceselor business, care au loc n organizaie i
care realizeaz scopurile i obiectivele acesteia. Modelul organizaiei, descris n termeni de
procese i funcii business, permite formularea cerinelor principale ctre sistem. Mulimea
modelelor de descriere a cerinelor este apoi transformat ntr-un sistem de modele, care
descriu proiectul conceptual al SI.
Destinaia pailor care au loc la etapa de analiz este formarea cerinelor sistemului, care s
reflecte corect i exact scopurile i obiectivele organizaiei-client. Pentru a specifica procesul
de creare a SI, care satisface necesitile organizaiei, trebuie de clarificat i de formulat
explicit aceste necesiti. n acest scop trebuie identificate cerinele clientului ctre SI i
reflectarea lor n limbajul modelelor de elaborare a proiectului SI asigurnd conformitatea cu
scopurile i obiectivele organizaiei.
Identificarea i formularea cerinelor este una din sarcinile cele mai responsabile, dificil de
formalizat i extrem de complicate i costisitoare n cazul unor erori. Mijloacele instrumentale
i produsele program contemporane permit crearea relativ rapid a SI dac cerinele exist.
Dar adesea aceste sisteme nu satisfac clienii, solicit o mulime de perfecionri, ceea ce
conduce la creterea brusc a cheltuielilor. Cauz principal a acestei situaii este identificarea
incorect sau incomplet a cerinelor la etapa de analiz.
La ieirea etapei de analiz se va obine un document n care sunt incluse cerinele de sistem,
de management i de utilizare, informaii privind costurile i beneficiile, ca i posibile strategii
de dezvoltare alternative.

1.2.3.

Proiectarea

Scopul etapei de proiectare este de a crea un model fizic care va satisface toate cerinele
documentate ale sistemului. Aici sunt create, n primul rnd, modelele datelor. Tot acum va fi
proiectat interfaa cu utilizatorul i vor fi identificate ieirile necesare, intrrile i procesele. n
calitate de informaii iniiale proiectanii folosesc rezultatele analizei. Crearea modelului logic i
modelului fizic al datelor este partea principal la proiectarea bazei de date. Modelul
informaional, obinut la etapa de analiz, este transformat mai nti n modelul logic, apoi n
modelul fizic al datelor. Paralel cu proiectarea schemei BD are loc proiectarea proceselor n
scopul obinerii specificaiilor tuturor modulelor SI. Aceste dou procese de proiectare sunt
strns legate, or o parte a logicii-business de obicei este realizat n cadrul bazei de date
(constrngeri, triggere, proceduri ncorporate). Scopul principal al etapei de proiectare a
proceselor const n transformarea funciilor, identificate la etapa de analiz, n module ale SI.
La proiectarea modulelor sunt stabilite interfeele programelor: formatul meniului, forma
ferestrelor, tastele fierbini i apelurile associate, etc.
Ieirile etapei de proiectare sunt specificaiile pentru proiectarea sistemului, inclusiv schema
BD (prin utilizarea modelului entitate-relaie (ER), creat la etapa de analiz), specificaiile
modulelor sistemului (construite n baza modelelor funciilor), prezentate conducerii i
utilizatorilor pentru revizuire i aprobare. Participarea conducerii i a utilizatorilor este

esenial pentru a evita orice nenelegere cu privire la ceea ce noul sistem va face, cum se va
face, i ct va costa.
Suplimentar, la etapa de proiectare are loc elaborarea arhitecturii SI, care include n acest caz
alegerea platformei/platformelor i a sistemului/sistemelor de operare. ntr-un SI eterogen
calculatoarele pot funciona pe diferite platforme hard i sub comanda diferitor sisteme de
operare. Tot aici sunt cutate rspunsuri referitor la urmtoarele caracteristici ale arhitecturii:
tipul arhitecturii (file server sau client server?);
numrul de nivele (2 sau 3 nivele?: clientul, serverul BD, serverul aplicaiilor);
tipul BD - centralizat sau distribuit? n ultimul caz, vor fi stabilite mecanismele
de coordonare i actualizare;
omogenitatea BD: omogen - serverele BD de la acelai productor - sau
eterogen? n ultimul caz, care va fi modalitatea organizare a schimbului de date?;
paralelism: vor fi sau nu utilizate servere BD paralele pentru sporirea
productivitii?, etc.
Etapa de proiectare se incheie cu elaborarea proiectului tehnic al sistemului informaional.

1.2.4.

Implementarea i testarea

Pe parcursul etapei de implementare este construit noul sistem. Indiferent de metodele de analiz
utilizate analiza structural sau abordarea obiect-orientat, procedura este aceeai - programele
sunt scrise, testate, i documentate, iar sistemul este instalat. n cazul n care sistemul a fost
achizitionat ca un pachet, persoanele responsabile vor configura sistemul i vor efectua toate
modificrile necesare. Obiectivul etapei de implementare este de a pune la punct i asigura lansarea
n exploatare industrial a sistemului nou, cu utilizatori instruii i informaiile de exploatare i
mentenan documentate.
La ncheierea acestei etape sistemul este testat i acceptat pentru utilizare. Testarea este distribuit
n timp. La finalizarea lucrrilor de creare a unui modul al sistemului are loc testarea autonom
(sau de detaliu), care urmrete dou scopuri principale:
detectarea refuzurilor n funcionare a unui modul (cderi fatale);
stabilirea nivelului de corespundere specificaiilor (dac sunt prezente toate
funciile necesare, dac nu exist funcii redundante).
Dac testarea autonom trece cu succes, modulul este inclus n componena prii finalizate a
sistemului i grupul modulelor realizate sunt supuse testrii legturilor, care urmrete
verificarea corectitudinii influenelor reciproce.
Urmeaz testarea fiabilitii grupului de module cnd:
sunt imitate situaiile de refuz n funcionare;
este determinat timpul mediu ntre dou cderi succesive (MTBF - Mean Time
Between Failures).
Primul grup de teste stabilete ct de bine sistemul se restabilete dup cderile resurselor
program sau tehnice. Al doilea grup determin gradul de stabilitate a sistemului n regim
standard de lucru i permite determinarea valorii timpului mediu de bun funcionare. n setul
de teste de stabilitate sunt incluse teste, care imit sarcina de vrf la care poate fi supus
sistemul (stress-test).
Urmeaz testarea de sistem testarea pentru acceptarea intern a produsului care stabilete
nivelul lui de calitate. Aici sunt incluse teste de funcionalitate i de fiabilitate.
Ultima testare o reprezint testarea de primire-predare (de acceptare). Sistemul informaional
este prezentat beneficiarului, iar testarea va include un grup de teste, care modeleaz
procesele business reale pentru a demonstra conformitatea produsului realizat cu cerinele
tehnice.
Necesitatea monitorizrii procesului de creare a sistemelor informaionale, garantrii realizrii
obiectivelor proiectului i respectarea diferitor constrngeri (bugetare, de timp, etc.) a condus

la utilizarea larg a metodelor i mijloacelor ingineriei software: analiza structural, modelarea

obiect-orientat, instrumente CASE.

1.2.5.

Mentenan i asigurarea securitii

La acest etap personalul IT susine, mbuntete i protejeaz sistemul. Aici sunt depsitate
unele posibile erori, are loc adaptarea la schimbrile din mediul externObiectivul acestei etape
este de a maximiza rentabilitatea investiiei IT. Msurile de securitate au scopul de a proteja
sistemul de ameninrile externe i interne. Un sistem bine conceput trebuie s fie sigur, fiabil,
uor de ntreinut i scalabil.
Dezvoltarea SI este un proces n continu desfurare. Procesele business se schimb rapid,
iar sistemul informaional trebuie s fie actualizat constant sau nlocuit, dup mai muli ani de
funcionare.

1.3.

Metodologii de realizare a sistemelor informatice

Crearea sistemelor informatice include aciuni complexe, care mbin un numr mare de
activiti: analiz, proiectare, implementare, testare, exploatare, mentenan. n plus, reclam
resurse umane, materiale i financiare semnificative, pe o perioad considerabil de timp.
Folosirea eficient a acestor resurse, n scopul obinerii unui sistem informaional performant,
a impus ordonarea acestui proces complex ntr-o succesiune bine stabilit de etape i
subetape i utilizarea unor metode i tehnici adecvate. Acest lucru a dus la conturarea unor
metodologii de realizare a sistemelor informatice.

1.3.1.

Coninutul metodologiilor de realizare a sistemelor

informatice
Metodologiile de realizare a sistemelor informatice cuprind:
modalitatea de abordare a sistemelor;
regulile de formalizare a datelor i proceselor de prelucrare;
instrumentele folosite pentru concepia, realizarea i elaborarea documentaiei;
modalitatea de derulare a proiectului i aciunile specifice fiecrei etape (ciclul
de via);
stabilirea modului de lucru, rolului analitilor, proiectanilor i a raportului dintre
ei;
modalitile de administrare a proiectului (planificare, programare,
monitorizare).
Totodat, metodologiile au rolul de a indica modul de desfurare a acestui proces, stabilind:
componentele procesului de realizare a sistemului informatic (etape, subetape,
activiti, operaii) i coninutul lor;
ordinea n care are loc parcurgerea (executarea) componentelor;
metodele, tehnicile, procedeele, instrumentele, normele si standardele utilizate.
n funcie de modul de abordare i domeniul de aplicabilitate, metodologiile utilizate sunt:
metodologii din domeniul gestiunii: AXIAL (firma IBM), MERISE (Ministerul
Industriei - Franta), IE (James Martin), SSADM (Marea Britanie);
metodologii orientate obiect: OMT (General Electric - SUA), OOD (Michael
Jackson);
metodologii pentru managementul proiectelor de sisteme informatice: SDM/S,
METHOD/1 Arthur Andersen, NAVIGATOR (Ernst & Young - James Martin);
alte metodologii.

1.3.2.

Metode i tehnici de realizare a SI

La realizarea SI se utilizeaz metode, tehnici, instrumente i procedee de lucru.

Metodele utilizate n proiectarea SI reprezint modul unitar sau maniera comun n care
analitii de sistem, programatorii i alte categorii de persoane implicate, realizeaz procesele
de analiz a sistemului informaional-decizional existent, de proiectare i de lansare a

sistemului nou. Metoda are un caracter general, n cadrul ei aplicndu-se anumite tehnici de
lucru.
Tehnicile de lucru utilizate n proiectarea SI reprezint felul n care se acioneaz eficient i
rapid, n cadrul unei metode, pentru soluionarea problemelor ce apar n procesul de
proiectare. Prin aceste tehnici se mbin armonios cunotinele despre metode cu miestria
personal a celor chemai s aplice metodele si s utilizeze instrumentele adecvate.
Utilizarea metodelor, tehnicilor, instrumentelor i procedeelor de lucru n proiectarea SI se face
n conformitate cu o serie de principii i n limita unei metodologii de lucru, care se adopt n
funcie de situaia real la care se refer.
n abordrile incipiente se lucra cu probleme izolate. Ulterior s-a efectuat trecerea la abordarea
sistemic, odat cu abordarea funcional sau, mai bine zis, cu analiza i decompoziia
funcional (n fiecare modul exist cte o funcie) pn la abordarea obiect-orientat. Pe
parcurs s-au impus dou strategii de abordare i anume:
strategia top - down (de sus n jos);
strategia bottom up evolutiv (de jos n sus).
n strategia top down abordarea general este divizat n uniti componente prin rafinri
repetate, metoda de proiectare putnd fi descris sub forma unei diagrame ierarhice cu
module de control pe nivelele superioare i cu module detaliate pe nivelele inferioare.
Structura organizatoric a unei uniti economico-sociale numit organigrama unitii poate fi
reprezentat printr-o astfel de diagram ierarhic.
n strategia bottom up evolutiv, se pornete de la o tratare minimal care se extinde treptat
pe msura naintrii n realizarea sistemului.
n practic, de cele mai multe ori se utilizeaz o combinare a celor dou strategii.
Metodele de abordare a SI pot fi grupate prin prisma celor mai muli autori astfel:
metode orientate spre funcii, numite i metode ale descompunerii funcionale;
metode orientate spre fluxuri de date sau orientate spre procese, deoarece
diagramele fluxurilor de date se ntrebuineaz pentru descrierea proceselor;
metode orientate spre informaie sau date, aprute ca urmare a popularizrii
puternice a ingineriei informaiei a lui JAMES MARTIN, dar i a diagramelor entitaterelaie ale lui CHEN;
metode obiect orientate.

1.3.3.

Caracteristici eseniale ale principalelor metode

Informaia este abordat din trei perspective specifice sistemelor informaionale sau prin trei
dimensiuni: date, funcii, comportament.
Datele sunt surprinse din prisma structurii lor sub form de atribute i nseamn de fapt, ceea
ce are stocat i reflect structura static.
Funciile scot n eviden n mod limitat ceea ce face sistemul. Sistemul poate fi privit i ca un
proces, ntruct elementele sistemului despre care se pstreaz datele de rigoare sunt supuse
unor transformri funcionale, prin intermediul proceselor.
Comportamentul este invocat pentru a sugera dinamica sistemului i reprezint o alt
modalitate de percepie a sistemului, subliniind influena evenimentelor i proprietilor lui.
Dintre autorii remarcabili care au abordat descompunerea funcional trebuie remarcai
DeMarco, Yourdon i Constantine, Jackson, Page-Jones, Marco&Gowan, Warnier-Orr, Dahl .a.
Descompunerea funcional este cea care anun apariia proiectrii i analizei structurale.
Fiecare funcie este descompus n subfuncii, pn se obin structuri uor de transpus n
instruciunile limbajelor de programare.
Prin metoda fluxurilor de date (orientat pe procese) analitii efectueaz reprezentarea lumii
reale prin simboluri care reprezint fluxul datelor, transformrile datelor, stocarea datelor,
entiti externe, etc. Metoda orientat pe procese are un mare grad de asemnare cu
descompunerea funcional.

n cadrul metodei orientate spre informaii dou realizri importante n domeniu au dat tonul
unei orientri n abordarea sistemelor: modelarea datelor cu ajutorul diagramelor entitaterelaie (Peter P. Chen, 1976) i ingineria informaiei (James Martin).
Metoda orientat-obiect constituie o categorie particular a metodelor de dezvoltare software
n care clasa reprezint unitatea arhitectural fundamental. Clasa este o grupare logic a
obiectelor care au aceeai structur i un comportament similar.

1.3.4.

Instrumente CASE

Problema Proiectrii Asistate de Calculator a Sistemelor sau cu Ajutorul Calculatorului

Computer Aided Systems Engineering) a devenit foarte important la mijlocul anilor 1980,
cnd resursele tehnice s-au extins prin seria PC-urilor, iar reelele au devenit mai puternice,
permind crearea sistemelor distribuite. Obiectivul principal al CASE l constituie punerea n
practic a instrumentelor program de proiectare i realizare a softului cu ajutorul
calculatorului. Instrumentele oferite de CASE sunt utilizabile de la faza de definire a cerinelor
pn la ntreinerea fizic a produsului informatic. Analiza i proiectarea, bazate pe conceptele
i metodele structurale, reprezint elementele forte ale instrumentelor CASE, chiar dac n
ultimii ani atenia principal este acordat analizei, proiectrii i programrii orientate pe
obiecte.
Iniial, majoritatea produselor soft au fost construite n mod artizanal, fr posibilitatea testrii
complete, fiind nsoite de o documentaie precar. Instrumentele CASE implic utilizarea
calculatorului ca mijloc de susinere a activitilor de planificare, definire, proiectare i
realizare a softului. Ele se bazeaz pe logica structural, pe descompunerea funcional i
reprezentarea prin diagrame a fluxurilor de date ale aplicaiilor.
Potrivit principiilor conceptuale, sistemele CASE au fost concepute pentru a ncuraja abordarea
logicii structurale i pentru folosirea calculatorului ca un mod de tezaurizare a lucrrilor, dar i
ca o planet de desen, pe care pot fi plasate reprezentrile structurate ale sistemelor sau
aplicaiilor. Pe msura evoluiei lor, sistemele CASE au devenit mult mai complexe, permind
ca procesele de proiectare i realizare a aplicaiilor s se desfoare ntr-un mediu informatic
interactiv, oferind utilizatorilor un ntreg arsenal de instrumente i proceduri, prin care pot
proiecta, realiza, testa, documenta, ntreine, actualiza i exploata sistemul.
Utilizarea produselor de tip CASE a fost determinat de:
calitatea ndoielnic a aplicaiilor realizate n mod tradiional;
frustrarea utilizatorilor n ncercarea lor de a participa la procesul de proiectare i
realizare a aplicaiilor, datorit nivelului ridicat de cunotine informatice solicitate de
metodele tradiionale;
costuri deosebit de mari pentru ntreinerea i actualizarea softului funcional;
imposibilitatea rezolvrii tuturor cerinelor utilizatorilor;
limitarea posibilitii de reprezentare grafic a schemelor de realizare a noilor
proiecte.
Folosirea sistemelor CASE este motivat i de urmtoarele avantaje:
reducerea complexitii logicii de descriere a sistemului;
posibilitatea de a alege dintre mai multe variante de proiectare;
creterea vitezei de realizare a sistemelor;
realizarea succesiv a componentelor unui sistem;
creterea nivelului de integrare;
consolidarea disciplinei de proiectare;
oferirea unei interfee de proiectare;
folosirea depozitelor modularizate;
salvarea i refolosirea unor componente deja realizate;
simplificarea activitilor de proiectare i realizare a sistemelor/aplicaiilor.
Utilizarea sistemelor CASE a nceput cu introducerea diagramelor fluxurilor de date, care fac
posibil realizarea unui model al derulrii proceselor sistemului proiectat. A urmat folosirea
dicionarului de date ca un depozit al tuturor datelor privind sistemul sau aplicaia. Au aprut
ecranele predefinite pentru a prezenta ce poate s obin utilizatorul prin exploatarea

sistemului. S-a apelat la facilitile grafice, care pot folosi simbolurile logicii structurale i care
permit proiectantului s realizeze o diagram coerent a fluxurilor de date.

ntrebri de control
1. Care este tipul de date prelucrat n sistemele informaionale factografice?
Date structurate n form de text i numere
Imagini grafice
Documente, care includ denumiri, descrieri, adnotri i texte.
2. Pentru care tip de SI sunt caracteristice procedurile de cutare a datelor
fr procesri complicate?
Pentru sistemele informaionale de cutare
Pentru SI de conducere a proceselor tehnologice
Pentru SI operative.
3. Care funcii sunt prezente n SI de management organizaional?

4.

Msurarea parametrilor proceselor tehnologice

Controlul i gestiunea operaiilor de producere

Analiza financiar i prognozarea

Analiza i planificarea pregtirii cadrelor
Analiza modului de funcionare a echipamentelor

Calcule inginereti

Evidena operativ
Planificarea operativ i de perspectiv
Care funcii sunt prezente n subsistemul de marketing al SI corporativ?

Gestiunea vnzrilor.

5. Care funcii sunt prezente n subsistemele de producere ale SI corporativ?

Planificarea volumelor de lucru i elaborarea planurilor
calendaristice

6.
corporativ?

Analiza i planificarea pregtirii cadrelor

Analiza modului de funcionare a echipamentelor

Gestiunea vnzrilor
Managementul portofoliului cu comenzi.
Care funcii sunt prezente n subsistemele de management financiar ale SI

Managementul portofoliului cu comenzi

Gestiunea rezervelor
Evidena contabil i calcularea salariului
Controlul budetului
Gestiunea vnzrilor.
7. Formulai scopul metodologiei proiectrii SI
Reglementarea procesului de proiectare a SI i asigurarea
administrrii acestui proces pentru a garanta ndeplinirea cerinelor att fa de
sistem, ct i fa de caracteristicile procesului de elaborare a sistemului
Automatizarea evidenei contabile analitice i a proceselor
tehnologice

Formularea cerinelor privind asigurarea utilizrii complexe a

datelor corporative n managementul i planificarea activitii companiei.
8. Soluionarea cror probleme este facilitat de implementarea metodologiei

proiectrii SI?

Garantarea crerii unui sistem cu calitatea solicitat, la termen i

n bugetul stabilit
Asigurarea unei discipline corecte de ntreinere, modificare i
extindere a sistemului

Asigurarea proiectrii de-sus-n-jos a sistemului informaional.

9. Indicai componentele etapei de proiectare a SI

Specificarea cerinelor aplicaiilor
Instalarea bazei de date
Proiectarea obiectelor datelor
Alegerea arhitecturii SI
Implementarea codului program al aplicaiilor.

2. Ciclul de via a produselor program

Noiune de ciclu de via. Procesele ciclului de via: principale, auxiliare, organizaionale.
Coninutul i legturile reciproce ntre procesele ciclului de via. Modele ale ciclului de via:
cascad, cu control intermediar, spiral. Etapele ciclului de via. Standarde.
Metodologia proiectrii sistemelor informaionale descrie procesul de creare i mentenan a
sistemelor prin intermediul ciclului de via a SI, prezentndu-l ca o succesiune de etape i procese,
executate n cadrul etapelor. Pentru fiecare etap sunt determinate activitile executate i
succesiunea lor, rezultatele la ieire, metodele i mijloacele necesare pentru ndeplinirea
activitilor, rolurile i responsabilitile participanilor. Aceast descriere formal a vieii SI
permite planificarea i organizarea procesului de elaborare colectiv i asigur administrarea
acestui proces.
Ciclul de via este irul de evenimente i activiti, care au loc n procesul crerii i exploatrii SI.

2.1.

Modele ale ciclului de via

Modelul ciclului de via reflect diferite stri ale sistemului, pornind de la momentul apariiei
necesitii elaborrii pn la retragerea sistemului din exploatare. Modelul ciclului de via poate fi
privit ca entitatea, care include procesele, aciunile i sarcinile realizate n timpul elaborrii,
funcionrii i ntreinerii produsului program pe ntreaga perioad de existen a sistemului, de la
stabilirea cerinelor pn la retragerea din utilizare.
Modelele ciclului de via pot fi mprite n modele cascad (Waterfall) i modele iterative cu
variante succesive.

2.1.1.

Modelul cascad

Modelul cascad (fig. 2.1) stabilete executarea consecutiv a fazelor proiectului ntr-o ordine
strict. Include urmtoarele faze: Stabilirea cerinelor, Proiectarea, Realizarea/Implementarea i
testarea modulelor, Integrarea i testarea de sistem, Exploatarea i mentenana. Trecerea la faza
urmtoare semnific finalizarea complet a tuturor lucrrilor de la etapa precedent.

Fig. 2.1. Modelul Cascad

n faza de Stabilire a cerinelor sunt identificate toate cerinele posibile ale sistemului ce se dorete
implementat. Cerinele sunt culese de la utilizator prin consultarea acestuia, dup care este
analizat posibilitatea de incorporare a lor n produsul dorit. La final este redactat un document cu
aceste cerine (Sarcina Tehnic), ce va servi ca ghid pentru fazele urmtoare ale proiectului.
n etapa de Proiectare sunt studiate cerinele documentate la prima etap i este elaborat
proiectul tehnic al sistemului. Aceast faz ajut n specificarea cerinelor de sistem i hardware,
precum i n definirea arhitecturii de ansamblu. Rezultatul acestei etape se concretizeaz n
redactarea unui document ce cuprinde specificaiile de proiectare (Proiectul Tehnic).
Etapa Realizarea (implementarea) i testarea modulelor presupune divizarea sistemului n
module i implementarea codului. Sistemul este dezvoltat mai nti n mici programe, numite
uniti, module sau componente, care vor fi apoi integrate la faza urmtoare. Fiecare unitate
este dezvoltat i testat (testare de detaliu, autonom, unitar), pentru a ne asigura c respect
specificaiile. Componentele pot fi funcii, obiecte sau grupuri coerente de astfel de entiti.
n faza de Integrare i testare de sistem, toate unitile dezvolate n faza anterioar sunt integrate
i apoi testate pentru a verifica dac funcioneaz coordonat, iar sistemul, privit ca un ntreg, se
comport conform cu specificaiile. Dup testarea cu succes, produsul este livrat la beneficiar, etap
la care are loc testarea de acceptare - testarea cu datele clientului pentru a verifica dac sistemul
ndeplinete cerinele acestuia.
Ultima faz Exploatarea i mentenana - este o faz pentru care termenul de finalizare coiincide cu
retragerea din utilizare a sistemului. Problemele unui produs program (PP) apar dup ce el ncepe sa
fie utilizat i vor fi rezolvate dup lansarea lui prin activiti de mentenan.
Printre avantajele modelului cascad, se pot meniona:
Documentarea i proiectarea structurii sunt un avantaj dac apar noi membri n
echip;
Este un model simplu i uor de utilizat;
Fiecare faz are un rezultat ateptat, datorat rigiditii modelului;
Etapele sunt ndeplinite individual, secvenial (uor de urmrit).
Acest model este recomandat pentru proiecte mici n care cerinele sunt foarte bine nelese.
Printre dezavantajele acestui tip de model, se numr:
Culegerea specificaiilor n etapa Stabilire cerine este foarte important pentru a
proiecta i implementa produsul solicitat. Cu toate acestea, cerinele pot fi adugate i dup
finalul acestei etape, fapt ce influeneaz n mod negativ dezvoltarea;
De obicei, problemele din cadrul unei etape nu sunt rezolvate complet n cadrul
aceleiai etape;
Partiionarea n etape a proiectului nu este flexibil;
Clientul poate aduga noi cerine, care nu pot fi implementate n aceeai ediie a

produsului. Va fi nevoie de costuri suplimentare pentru implementarea cerinelor noi;

Este dificil s se fac o estimare corect a timpului i costului alocat pentru fiecare
etap;
Un produs funcional finit este obtinut trziu comparativ cu momentul de nceput al
proiectului.
O perfecionare a modelului cascad este modelul cu control intermediar sau cu reacie, n care au
fost introduse iteraii cu conexiuni inverse ntre etape (fig. 2.2). Coreciile, introduse ntre etape,
permit s se in cont de influenele reciproce ale rezultatelor la diferite etape; timpul de via a
fiecrei etape se extinde peste ntreaga perioad de elaborare.

Fig. 2.2. Modelul cu control intermediar

2.1.2.

Modelul spiral

Acest model a fost definit plecnd de la slbiciunile modelului cascad, n special lipsa de
flexibilitate la schimbrile cerinelor. Este centrat pe analiza riscurilor n mod incremental, repetnd
modelul cascad ntr-o serie de cicluri, ca n figura 2.3.
Caracteristic pentru modelul spiral este:
procesul este reprezentat sub form de spiral (n loc de secven de activiti
cu reluare);
fiecare bucl din spiral reprezint etapele unui proces;
nu exist faze fixe ca specificare sau proiectare buclele din spiral sunt alese
funcie de ceea ce este necesar;
riscurile sunt evaluate explicit i rezolvate de-a lungul procesului.
Sectoarele modelului spiral includ:
1. Stabilire obiective - sunt identificate obiectivele specifice etapei.
2. Evaluare i reducere risc - riscurile sunt evaluate i se realizeaz activiti pentru
reducerea riscurilor cheie.
3. Dezvoltare i validare - se alege un model de dezvoltare pentru sistem, care poate fi
oricare din modelele generice.
4. Planificare - proiectul este revzut i se planific urmtoarea etap a spiralei.

Fig. 2.3. Modelul spiral

Dezvoltarea produsului include proiectarea unitar, testarea autonom, integrarea. La prima iteraie
este construit un prim prototip al noului sistem din design-ul preliminar, care este de obicei un
sistem la scar redus i reprezint o aproximare a caracteristicilor produsului final.
Planificarea urmtorului ciclu presupune evaluarea de ctre client, planificarea dezvoltrii i a livrrii
ctre client. Urmtorul prototip este dezvoltat conform pailor:

Evaluarea prototipului precedent n termeni de puncte tari, puncte slabe

i riscuri;

Definirea cerinelor pentru urmtorul prototip;

Planificarea i proiectarea urmtorului prototip;
Construirea i testarea urmtorului prototip.

Modelul spiral este o mbuntire a modelului cascad deoarece prevede mai multe livrri i mai
multe posibiliti de implicare a clientului. Raza spiralei reprezint costul acumulat.
O versune modificat este modelul spiral WinWin, care adaug la nceputul fiecrui ciclu activiti
de identificare a prilor interesate n proiect (stakeholders) i condiiile lor de ctig (win
conditions).
La avantaje merit s fie subliniat atitudinea pro-activ asupra riscurilor cu o listare explicit a
riscurilor i a rezolvrii lor. De asemenea un avantaj important este flexibilitatea modelului.
La dezavantaje trebuie de menionat c este aproape imposibil de estimat de la nceput timpul de
execuie a proiectului i costurile necesare.

2.1.3.

Alte modele

La categoria alte modele pot fi menionate Rational Unified Process (RUP), Model Driven Architecture
(MDA), Modelul V (V model), modelul ESA (European Space Agency), Dezvoltarea Agile, Dezvoltare
pe baz de prototip (Prototyping) etc.

Modelul V (fig. 2.4) este o variant a modelului cascad, care pune n eviden corelarea dintre
activitile de specificare i cele de testare, nlnuirea n timp a activitilor fiind aceeai.

Fig. 2.4. Modelul n V

Partea din stnga reprezint lanul de specificare a sistemului, iar cea din dreapta lanul de
testare. Partea de jos a V-ului reprezint implementarea.
n acest model exist dou tipuri de dependene ntre etape:

cele reprezentate prin liniile, care formeaz V-ul i corespund nlnuirii i

eventualei iteratii din modelul cascad; etapele se deruleaz deci secvential, urmnd Vul de la stnga la dreapta;

cele reprezentate prin linii orizontale, care indic faptul c o parte din
rezultatele etapei din care pleac sageata sunt utilizate direct n etapa inta. De
exemplu, la terminarea etapei de proiectare arhitectural, testele de integrare trebuie
s fie complet descrise.
n dezvoltarea pe baz de prototip ideea este de a permite viitorilor utilizatori s exerseze cu o
prim versiune a sistemului, care poate fi obinut rapid prin tehnici de simulare sau de interpretare
a specificatiilor. n acest ultim caz, limbajele logico-funcionale sunt chemate s joace un rol
important.
Prototipul este o schi a viitorului sistem: el nu are performanele i nu rspunde exigenelor de
calitate ale unui produs finit. Prototipul ofer clientului functionaliti (nu n totalitate) ale viitorului
sistem i interfaa pentru utilizator. El este dezvoltat ntr-o manier iterativ. Cerinele sunt extrase
i validate iterativ prin utilizarea prototipului. La fiecare iteraie specificaia sistemului este
modificat i detaliat pn cnd prototipul satisface necesitile utilizatorilor.
Un prototip care este utilizat pentru a desprinde cerinele viitorilor utilizatori, este o "machet
exploratoare". Activitatea de prototipizare poate interveni de asemenea n etapa de proiectare,
pentru a experimenta i compara diferite variante. Astfel de prototipuri se numesc "machete
experimentale".
Scopul Modelului Prototip este de a contracara limitrile modelului Waterfall, legate de stabilirea
cerinelor. n loc de a stabili definitiv cerinele nainte de a putea ncepe proiectarea, este lansat un
prototip pentru a nelege cerinele. Acesta este elaborat pe baza cerinelor cunoscute n prezent.
Dezvoltarea prototipului conine fazele de proiectare, realizare i testare, dar acestea nu sunt foarte
riguroase sau formale. Prin intermediul prototipului clientul nelege mai bine modul n care lucreaz
produsul, ntruct interacioneaz cu acesta pe parcursul ntregului ciclu de dezvoltare. Acest model

este preferat n cadrul sistemelor mari i complicate, pentru care este dificil nelegerea cerinelor
de la nceput. n astfel de situaii, accesul clientului la prototip furnizeaz un aport substanial n
nelegerea i definirea specificaiilor.
Avantajele acestui model sunt:

Utilizatorii sunt implicai direct n dezvoltare;

Susine tendina utilizatorilor de a-i modifica cerinele pe parcursul

ciclului de implementare;

I ntruct este lansat un model funcional al sistemului, utilizatorii pot

inelege mai bine modul de funcionare;

Erorile pot fi detectate mult mai devreme;

Feedback-ul utilizatorului este mai rapid, fapt ce duce la obinerea de

soluii mai bune;

Timpul i costurile sunt reduse.

Printre dezavantaje, merit menionate:

Posibilitatea creterii complexitii SI, care se poate extinde dincolo de

limitele stabilite iniial;

Analiza insuficient a proiectului ca un tot ntreg;

Programatorii pot deveni ataai de un prototip n a crui dezvoltare au

investit mult timp i vor tinde s transforme prototipul ntr-un produs final chiar i atunci
cnd arhitectura de baz nu este cea potrivit;

Consumul excesiv de timp utilizat pentru implementarea unui prototip.

2.2.

Procesele ciclului de via

Fiecare etap de creare a SI include executarea unor anumite lucrri procese ale ciclului de via.
Un proces este definit ca un set de activiti interdependente, care transform intrrile sistemului n
ieiri. Descrierea unui proces include lista problemelor rezolvate, datele iniiale i rezultatele.

2.2.1.

Procesele conform ISO/IEC 12207

n conformitate cu standardul ISO/IEC 12207 procesele ciclului de via se mpart n trei categorii:
1. Procese primare: cinci procese, care formeaz partea de baz a ciclului de via a
produselor program. Partea de baz este cea care iniiaz i realizeaz dezvoltarea,
exploatarea sau meninerea produsului program. Componentele ei sunt achizitorul, furnizorul,
dezvoltatorul, exploatatorul i menintorul produsului program. Cele cinci procese primare
sunt:
o achiziie definete activitile achizitorului organizaia, care
achiziioneaz un sistem, un PP sau un serviciu soft;
o aprovizionare sau furnizare definete activitile furnizorului
organizaia, care livreaz sistemul, PP sau presteaz serviciul solicitat de achizitor;
o dezvoltare - definete activitile dezvoltatorului organizaia, care
identific i dezvolt produsul program;
o exploatare - definete activitile operatorului organizaie, care ofer
servicii de operare a unui sistem informatic n mediul su pentru utilizatorii si;
o ntreinere - definete activitile de mentenan a organizaiei care
ofer serviciul de ntreinere a PP, de gestionare a modificrilor pentru a-l menine
actualizat i operaional. Acest proces include activitile de migrare i de retragere
din uz a PP.
2. Procesele auxiliare includ opt procese, care susin executarea altor procese cu
scopul garantrii succesului i calitii finale. Un proces auxiliar este lansat n execuie la
necesitate de un alt proces. Procesele auxiliare sunt:
o documentarea definete activitile de nregistrare a informaiei

produse de un ciclu de via;

o managementul configuraiei - definete activitile de gestiune a
configuraiei;
o asigurarea calitii - definete activitile de asigurare obiectiv a
conformitii produselor program i proceselor cu specificaiile lor;
o verificarea - definete activitile (pentru achizitor, furnizor, sau o
persoan independent), pentru verificarea produselor program n profunzime, n
funcie de proiect;
o validarea - definete activitile (pentru achizitor, furnizor, sau o o
persoan independent), pentru validarea (atestarea) produselor program;
o revizuirea comun - definete activitile de evaluare a strii i
produselor unei activiti;
o auditarea - definete activitile pentru stabilirea conformitii cu
cerinele, planurile i clauzele contractuale;
o soluionarea problemelor - definete un proces de analizare i
ndeprtare a problemelor, indiferent de natura lor sau surs, probleme descoperite n
timpul dezvoltrii, funcionrii, ntreinerii etc.
3. Procesele organizaionale includ patru procese realizate de ctre o organizaie, care
stabilete i pune n aplicare o structur de baz format din procesele asociate ciclului de
via i de personal i care are grij de mbuntirea continu a acestei structuri i a
proceselor. Procesele organizaionale sunt:
o management - definete activitile de baz ale managementului,
inclusiv managementul de proiect, n timpul unui proces al ciclului de via;
o procesul de infrastructur - definete activitile de baz pentru
stabilirea structurii unui proces al ciclului de via;
o perfecionare - definete activitile de baz pe care o organizaie
(achizitorul, furnizorul, dezvoltatorul, operatorul, menintorul sau managerul unui alt
proces) le efectueaz pentru determinarea, msurarea, controlul, precum i
mbuntirea procesului ciclului su de via;
o instruire - definete activitile pentru furnizarea de personal instruit n
mod adecvat.
Pentru susinerea utilizrii practice a standardului ISO/IEC 12207 au fost elaborate o serie de
documente tehnologice: Ghid pentru ISO/IEC 12207 (ISO/IEC TR 15271:1998 Information technology
- Guide for ISO/IEC 12207) i Ghid de utilizare ISO/IEC 12207 la managementul proiectelor (ISO/IEC
TR 16326:1999 Software engineering - Guide for the application of ISO/IEC 12207 to project
management).

2.2.2.

Coninutul proceselor primare

Standardul ISO/IEC 12207 stabilete coninutul proceselor primare, auxiliare i organizaionale. n

tabelul 2.1 este prezentat situaia pentru procesele primare.
Tabelul 2.1. Coninutul proceselor primare conform ISO/IEC 12207
Proces
Intrare
Aciuni
Ieire
(executor)
Decizia
Studiu de fezbilitate
Achiziie
Iniierea
privind
lansarea
privind
oportunitatea
Pregtirea
(achizitor)
lucrrilor
de
implementrii
cererii de oferte
implementare a SI
Sarcina tehnic pentru
(licitaie)

Rezultatele
crearea
SI
Pregtirea i
analizei
activitii

Contract
de furnizare/
actualizarea
achizitorului
creare
a
SI
contractului
Actele de primire a
Rezultatele
Monitorizare
etapelor
lucrrilor
a furnizorului
analizei pieei
Actul testrilor de
Acceptarea
produselor program
primire/predare
i completarea

Planul de
furnizare/dezvoltare

Furnizare
(dezvoltatorul/
furnizorul))

Iniierea
Pregtirea
rspunsului la
cererea de oferte
Pregtirea
contractului
Planificarea
executrii
Executare i
control

Verificare i

evaluare
Furnizarea SI
Dezvoltare
(dezvoltatorul
)

Pregtirea
Analiza

cerinelor
Proiectarea
arhitecturii
Analiza
cerinelor ctre
software
Proiectarea
arhitecturii softului
Proiectarea
de detaliu a softului
Scrierea
programelor i
testarea
Integrarea
modulelor
Testarea de
calificare
Integrarea
de sistem
Testarea de
sistem
Instalarea
softului
Acceptarea

Test complex
al SI
Caietul de
sarcini
Decizia
conducerii de
participare
Rezultatele
licitaiei
Sarcina
tehnic
Planul de
management al
proiectului
SI elaborat

Decizia de participare
Oferta comercial/
cerere de participare la
licitaie
Contract de furnizare/
creare a SI
Planul de management
al proiectului
Realizarea/corectarea
Actul testrilor de
primire/predare

i documentat

ST pentru
elaborarea
sistemului
PT pentru
elaborarea
sistemului, modelul
ciclului de via
Subsistemel
e SI
Specificaiile
componentelor soft
Arhitectura
produselor program
Materialele
proiectrii de
detaliu a produselor
program
Planul de
integrare, testele
Arhitectura
SI, produselor
program,
documentaia SI,
testele

meninerii softului

Modelul utlizat al
ciclului de via, stadardele
de dezvoltare
Planul lucrrilor
Coninutul
subsistemelor, componentele
tehnice

Specificaiile

cerinelor referitor la
componentele program

Coninutul

componentelor program,
interfeele BD, planul de
integrare

Proiectul BD,

specificaiile interfeelor
componentelor program,
cerinele pentru teste
Codul modulelor
program, actele testrilor
unitare
Evaluarea coformitii
setului de programe
cerinelor ST
Evaluarea coformitii
produsului program, BD,
echipamentelor tehnice i
setului de documente
cerinelor ST

2.2.3.

Procesele conform ISO/IEC 15288

n anul 2002 a fost publicat standardul pentru procesele ciclului de via al sistemelor - ISO/IEC
15288 System life cycle processes. La elaborarea lui au participat specialiti din diferite domenii:

ingineria sistemelor, programare, managementul calitii, managementul resurselor umane,

securitate etc. A fost luat n consideraie experiena crerii sistemelor informaionale pentru
instituiile statului, uniti comerciale, organizaii academice sau militare. Stadardul este gndit
pentru un spectru larg de sisteme, dar destinaia principal este susinerea crerii sistemelor
informaionale. n conformitate cu standardul ISO/IEC 15288 ciclul de via include urmtoarele
grupuri de procese:
1. Procese contractuale:
o achiziie (soluii interne sau ale unui furnizor extern);
o

furnizare (soluii interne sau ale unui furnizor extern).

2. Procesele ntreprinderii:
o

managementul mediului extern;

management investiional;

managementul ciclului de via a produselor program;

managementul resurselor;

managementul calitii.

3. Procesele proiectului:
o

planificarea proiectului;

estimarea proiectului;

controlul proiectului;

administrarea riscurilor;

managementul configuraiei;

managementul fluxurilor informaionale;

adoptarea deciziilor.

4. Procesele tehnice:
o

identificarea cerinelor;

analiza cerinelor;

elaborarea arhitecturii;

implementarea;

integrarea;

verificarea;

transmiterea ctre beneficiar;

validarea (atestarea);

exploatarea;

meninerea;

retragerea din uz.

5. Procese speciale:
o

determinarea i realizarea legturilor reieind din sarcini i scopuri.

Etapele de creare a unui sistem propuse de standardul ISO/IEC 15288 difer un pic de cele din
ISO/IEC 12207. n tabelul 2.2 sunt prezentate etapele i rezultatele principale, care trebuie s fie
atinse la momentul finalizrii etapelor conform standardului ISO/IEC 15288.
Tabelul 2.2. Etapele crerii sistemelor conform ISO/IEC 15288


crt
1
2
3
4
5
6

Etap

Descriere

Elaborarea

Analiza necesitilor, formularea concepiei i alegerea soluiilor de

proiect

concepiei
Proiectarea
Realizarea
Exploatarea
Mentenana
Retragerea din uz

2.2.4.

Elaborarea proiectului tehnic al sistemului

Construirea sistemulu
Lansarea n exploatare i utilizarea sistemului
Asigurarea funcionrii sistemului
Terminarea utilizrii, demontarea, trecerea n arhiv a sistemului

Alte standarde i reglementri

n afara celor dou standarde internaionale, adoptate i de Republica Moldova, exist un ir de

standarde de facto (metodologii), care reglementeaz Ciclul de via a produselor program, iar n
unele cazuri i procesul de dezvoltare.
O contribuie semnificativ la teoria proiectrii i practica dezvoltrii sistemelor informaionale a
adus compania IBM, oferind la mijlocul anilor 1970, metodologia BSP (Business System Planning metodologia de planificare organizaional). Metoda de structurare a informaiei utilznd matricele
de intersecie a proceselor business, departamentelor funcionale, funciilor sistemelor de
prelucrare a datelor, obiectelor informaionale, documentelor i bazelor de date, propus n BSP,
este folosit astzi nu numai n proiectele IT, dar i n proiectele de reinginerie a proceselor
business, de modificare a structurii organizaionale. Cei mai importani pai ai procesului BSP,
consecutivitatea lor (obinerea susinerii conducerii de vrf, determinarea proceselor ntreprinderii,
stabilirea claselor de date, desfurarea interviurilor, prelucrarea i organizarea datelor
interviului), pot fi gsii n aproape toate metodele formale, precum i n proiectele realizate n
practic.
Dintre alte standarde, mai cunoscute, pot fi evideniate urmtoarele:
GOST 34.601-90 stabilete stadiile i etapele crerii sistemelor automatizate.
Conine descrierea lucrrilor pentru fiecare etap. Corespunde modelului cascad.
Custom Development Method (metod Oracle) pentru elaborarea sistemelor
informaionale aplicative material tehnologic, detaliat pn la nivelul formularelor de
documente de proiect pentru utilizarea n proiectele Oracle.
Rational Unified Process (RUP) propune un model iterativ de dezvoltare, care include
4 faze: lansarea, cercetarea, construirea i implementarea. Fiecare faz poate fi mprit n
etape (iteraii), n rezultatul crora este produs versiunea pentru utilizare intern sau
extern. Cele patru faze formeaz un ciclu de elaborare, fiecare ciclu se termin cu
generarea unei versiuni a sistemului. Dac dup un ciclu ordinar lucrul nu se termin,
continu dezvoltarea produsului obinut trecnd prin aceleai faze. Esena lucrului n cadrul
RUP const n crearea i dezvoltarea modelelor n baza UML.
Microsoft Solution Framework (MSF) are multe momente comune cu RUP. De
asemenea are patru faze: analiza, proiectarea, realizarea i stabilizarea. Procesul este
iterativ, presupune utilizarea modelrii obiect-orientate. n comparaie cu RUP, MSF ntr-o
msur mai mare este destinat dezvoltrii aplicaiilor business.
Extreme Programming (XP) - programarea extremal - cea mai nou metodologie,
aprut n anul 1996. La baza metodologiei st lucrul n echip, comunicarea efectiv ntre
client i executor pe ntreaga perioad de executare a proiectului. Dezvoltarea are loc prin
utilizarea prototipurilor perfecionate succesiv.
Dezvoltatorii de produse program din Republica Moldova trebuie s cunoasc i Reglementarea
Tehnic Procesele ciclului de via a software-ului RT 38370656- 002:2006. Aceast reglementare
este obligatorie la crearea sistemelor informaionale automatizate de importan statal. Se
orienteaz spre aplicarea tehnologiilor orientate pe obiecte i a mijloacelor contemporane de
management al proiectelor, de elaborare i suport a versiunilor. Agenii economici, care furnizeaz/
procur software pentru sistemele informaionale automatizate nestatale, pot aplica prezenta
reglementare tehnic n mod voluntar.

ntrebri de control
1. Ce reflect modelul ciclului de via a SI

2.

Procesele de organizare a implementrii SI

Evenimentele, care au loc cu sistemul n procesul crerii i utilizrii lui
Procesul proiectrii SI
Selectai proprietile modelului cascad al ciclului de via a produselor

program
Presupune executarea secvenial a tuturor etapelor proiectului ntr-o ordine
strict fixat
Presupune elaborarea iterativ, cu cicluri de feed back ntre etape
Trecerea la etapa urmtoare semnific finalizarea total a activitilor de la
etapa anterioar
Timpul de via a fiecrei etape se extinde pe ntreaga perioad de dezvoltare
3. Selectai proprietile modelului spiral al ciclului de via a produselor
program
Permite planificarea termenelor de finalizare a lucrrilor i a cheltuielilor
La fiecare ciclu al spiralei este creat versiunea urmtoare a produsului, sunt
precizate cerinele proiectului
Trecerea la etapa urmtoare semnific finalizarea total a activitilor de la
etapa anterioar
Cerinele proiectului sunt precizate constant
La fiecare ciclu al spiralei sunt planificate activitile ciclului urmtor.
4. Indicai proprietile modelului ciclului de via cu control intermediar
Timpul de via al fiecrei etape este extins pentru toat perioada de dezvoltare
Ia n consideraie influena reciproc a rezultatelor diferitor etape
Pentru fiecare etap este creat un set finalizat de documentaie de proiect, care
rspunde criteriilor de completitudine i coordonare
Trecerea la etapa urmtoare semnific finalizarea total a activitilor de la
etapa anterioar
5. Care model al ciclului de via se recomand a fi utilizat la crearea SI simple?
Modelul ciclului de via cu control intermediar?
Modelul cascad
Modelul spiral
6. Care model al ciclului de via reflect cel mai adecvat procesul de creare a
sistemelor complexe?
Modelul ciclului de via cu control intermediar?
Modelul cascad
Modelul spiral
7. Care procese fac parte din grupul proceselor primare conform ISO/IEC 12207
Aprovizionarea
Asigurarea calitii
Verificarea
Managementul configuraiei
Documentarea
Dezvoltarea
Achiziia

3. Organizarea proceselor de dezvoltare a sistemelor informaionale

Metodele de proiectare a SI. Proiectarea canonic. Stadiile i etapele proiectrii canonice.
Scopurile i obiectivele etapei preproiect. Modelele activitii ntreprinderii (cum este i
cum trebuie s fie). Componena lucrrilor la etapa elaborrii proiectului tehnic.
Documentaia de proiect. Proiectarea generic. Noiune de proiect generic, premisele tipizrii.
Obiectele tipizrii. Metodele de proiectare generic. Estimarea eficienei utilizrii soluiilor
tipizate. Soluie proiect tip. Metode i mijloace de proiectare prototipizat a SI.
I n funcie de gradul n care sunt utilizate soluiile tip, metodele de proiectare a SI se mpart
n:

metode canonice;
metode tip.

Proiectarea canonic presupune elaborarea sistemelor de la zero fr utilizarea unor soluii tip
sau mijloace instrumentale speciale, care s permit integrarea execuiei operaiilor
elementare. Altfel spus, proiectarea canonic reflect particularitile proiectrii manuale
(originale, individuale, la comand) i, de obicei, este recomandat pentru crearea unor
sisteme de dimensiuni mici.
Proiectarea tip presupune crearea sistemului informaional din elemente-tip existente.
Aceasta poate avea loc n cazul n care este posibil decompoziia sistemului proiectat n
componente constitutive (subsisteme, seturi de activiti, module program etc.). Pentru
realizarea proiectrii tip exist dou abordri: proiectarea orientat pe parametri i
proiectarea orientat pe modele.
Conform modalitii de adaptare a soluiilor, metodele de proiectare se mpart n metode cu
reprogramare, metode cu parametrizare i metode cu modificarea modelului. Metodele cu
reprogramare presupun crearea unor module program modificabile noi. Metodele cu
parametrizare presupun configurarea soluiilor de proiectare prin modificarea setrilor
modulelor software. Ultima categorie este bazat pe introducerea unor modificri n modelul
domeniului obiectiv cu generarea codului modulului modificat.

3.1.

Proiectarea canonic a SI

Organizarea proiectrii canonice a sistemelor informaionale este orientat n mare msur

spre utilizarea modelului cascad a ciclului de via. Etapele sunt standardizate n GOST
34.601-90.
n dependen de complexitatea obiectului automatizrii i problemele, care trebuie
soluionate prin crearea unui SI concret, etapele pot fi de complexitate diferit. Este permis de
a combina etape succesive i chiar de a exclude unele etape la orice faz a proiectului. Mai
mult, urmtoarea etap a lucrrilor poate ncepe pn la sfritul etapei precedente. Etapele
crerii SI sunt fixate n contracte i sarcini tehnice de executare a lucrrilor.

3.1.1.

Etapele proiectrii canonice

Etapa 1. Studiul SI existent i definirea cerinelor noului sistem

Aceast etap include activitile:
cercetarea SI existent i motivarea necesitii crerii unui sistem nou;
formarea cerinelor sistemului nou;
elaborarea raportului despre lucrul ndeplinit.
Etapa 2. Elaborarea Concepiei SI

La crearea Concepiei SI poate fi de folos anexa 3 a RT 38370656-002:2006. Pentru

elaborarea Concepiei vor fi ndeplinite urmtoarele activiti:
studierea obiectului automatizrii;
executarea lucrrilor de cercetare necesare;
elaborarea versiunilor Concepiei, discutate de grupul de lucru, format din
reprezentanii beneficiarului i executorului;
perfectarea versiunii finale a Concepiei i aprobarea ei de ctre Conducere.
Etapa 3. Sarcina tehnic
Etapa elaborrii Sarcinii tehnice (ST) include activiti de elaborare prin iteraii a versiunilor
ST, discutarea i perfectarea versiunilor, coordonarea cu i aprobarea de Conducere.
Etapa 4. Proiectarea de detaliu (Proiectul schi)
Activitile componente ale acestei etape sunt:
elaborarea soluiilor de preproiect pentru sistem i prile sistemului;
elaborarea documentaiei de detaliu pentru sistem i prile lui.
Etapa 5. Proiectul tehnic
Include activitile:
elaborarea
elaborarea
elaborarea
elaborarea

soluiilor de proiect pentru sistem i prile sistemului;

documentaiei de proiect pentru sistem i prile lui;
i perfectarea documentaiei de achiziie a componentelor;
sarcinilor pentru proiectarea prilor conexe ale proiectului.

Etapa 6. Implementarea codului i perfectarea documentaiei de lucru

Const din:

scrierea i testarea codului modulelor;

integrarea modulelor i testarea subsistemelor i a sistemului n totalitate;
elaborarea documentaiei de lucru pentru sistem i prile lui.

Etapa 7. Lansarea n exploatare

Include activitile:
pregtirea obiectului automatizrii;
instruirea personalului;
completarea sistemului cu toate componentele necesare (resurse tehnice i
program);
executarea lucrrilor de construcie i montare;
lucrri de lansare i depanare;
testri preliminare;
exploatare pilot;
testare de primire-predare.
Etapa 8. Mentenana SI
Presupune:

ndeplinirea lucrrilor n conformitate cu obligaiunile de garanie;

deservirea postgaranie.

3.1.2.

Analiza situaiei i identificarea cerinelor sistemului nou

Cercetarea sistemului informaional existent i motivarea necesitii crerii unui sistem nou
include determinarea modului n care funcioneaz SI curent i identificarea a ceea ce ar dori
utilizatorii s realizeze noul sistem. Studiul i analiza sistemului existent are ca obiectiv
principal stabilirea cerinelor informaionale ale conducerii n vederea realizrii unui sistem

informatic.
Studiul sistemului existent cuprinde un grup de activiti, care urmresc cunoaterea
performanelor tehnico-funcionale, att n ansamblul su, ct i pentru elementele de
structur ale acestuia, a cerinelor informaionale ale conducerii, cunoaterea lipsurilor i
restriciilor pe care le prezint sistemul existent fa de aceste cerine. De modul de realizare
a acestor activiti depinde ntregul proces de realizare a sistemului informatic.
Cercetarea sistemului existent const n:
identificarea caracteristicilor generale ale obiectului automatizrii;
studiul activitilor de baz desfurate n sistem;
studiul sistemului de conducere;
studiul sistemului informaional;
identificarea metodelor i mijloacelor tehnice.
Definirea caracteristicilor generale ale organizaiei pentru care va fi elaborat noul sistem
implic:
cunoaterea profilului, obiectivelor organizaiei;
cunoaterea specificului activitii de baz (producie, servicii);
cunoaterea locului n sfera serviciilor i/sau sfera produciei;
cunoaterea relaiilor de cooperare cu ali ageni economici;
cunoaterea nivelului tehnic;
cunoaterea principalilor indicatori de performan i evoluia lor;
dezvoltarea, modernizarea etc.
Studiul activitilor desfurate n sistemul economic, modul de realizare a funciunilor unitii
economice se face utiliznd statutul de funcionare i cercetnd activitatea de producie
(sistemul condus). De asemenea vor fi studiate activitile din sistemul de conducere i
sistemul informaional existent.
Pe baza statutului de funcionare se studiaz:
activitile i sarcinile din cadrul acestor activiti;
atribuiile ce revin subdiviziunilor;
modul de realizare a activitilor funcionale.
n cazul activitii de producie se prezint:
fluxul de producie, amplasarea locurilor de munc, depozitelor etc.;
tipurile de produse, structura lor, ciclurile de realizare;
modul de organizare a produciei, depozitarea, transporturile interne, controlul
de calitate;
resursele existente: capaciti, asigurarea tehnic, proiectarea de produse noi,
norme tehnice;
asigurarea cu materiale necesare;
sistemul existent de programare a produciei.
Studiul sistemului de conducere se refer la:
identificarea caracteristicilor sistemului de conducere existent;
sistemul de indicatori cantitativi i valorici;
organizarea conducerii;
caracteristicile rezultate din statutul de funcionare a organizaiei, tipuri de
decizii, modul de luare i realizare a deciziilor.
Studiul sistemului informaional presupune:
elaborarea schemei fluxului informaional global (cu punerea n eviden a
principalelor activiti i a legturilor statice i dinamice dintre acestea);
estimarea cantitativ i calitativ a informaiilor de intrare-ieire, modul de
culegere i prelucrare a datelor;
identificarea principalilor algoritmi, regulilor de calcul i a punctelor si regulilor
de control;
cunoaterea principalelor restricii ale sistemului informaional;
situaia raionalizrii fluxurilor i a documentelor din organizaie, studii

elaborate, stadiul lor de implementare;

sistemul de codificare utilizat, restricii;
performanele i limitele sistemului informaional existent.
Identificarea metodelor i mijloacelor tehnice utilizate pentru prelucrarea datelor n cadrul
sistemului informaional existent se face evideniind: mijloacele tehnice existente n dotarea
unitii economice (modul de utilizare, cheltuielile de exploatare, personalul implicat,
performane); existena unor aplicaii proiectate i/sau implementate.
Formarea cerinelor sistemului nou este o activitate esenial n aflarea situaiei existente i a
ceea ce se dorete n viitor. Rezultatul activitii de determinare a cerinelor sistemului se
concretizeaz n diferite forme ale informaiilor colectate, cum sunt copii ale interviurilor,
nsemnri efectuate n timpul observrii i analizei documentelor, interpretri ale
rspunsurilor la chestionare, seturi de formulare, rapoarte, descrieri ale posturilor de lucru
.a., precum i rezultate ale prelucrrilor efectuate de calculator, cum ar fi prototipurile.
Activitile enumerate pot fi executate total cu forele achizitorului sau prin contractarea unor
servicii din partea unei organizaii de consultan.
Odat cu finalizarea acestei etape apare posibilitatea de a determina abordrile tehnice
posibile i de a evalua costurile de realizare (cheltuieli pentru procurarea resurselor tehnice,
resursele program de sistem i produsele program noi).
Rezultatele prezentate dup aceast etap pot fi rezumate astfel:
Informaii scrise care exist n unitate: misiunea i strategia afacerii, exemplare
ale formularelor, rapoartelor i machetelor de ecran, manuale ale procedurilor,
descrieri ale posturilor de lucru, manuale de instruire, scheme de sisteme i
documentaia sistemului existent, rapoartele consultanilor;
Informaii obinute n urma conversaiilor cu utilizatorii sau prin observarea
activitilor prestate de acetia: copii sau sinteze ale interviurilor, rspunsurile la
chestionare sau interpretri ale acestora, nsemnri i rezultate din observarea
activitilor, procese verbale ale edinelor ce au avut loc n acest scop;
Informaii obinute cu ajutorul calculatorului: copii ale fiierelor sesiunilor
grupului de lucru al proiectului, coninutul depozitelor i rapoartele existente n CASE,
ecrane i rapoarte rezultate din prototipurile sistemului, .a.
Materialele, create vor fi folosite pentru:
motivarea necesitii elaborrii i implementrii graduale a sistemului nou;
elaborarea Sarcinii Tehnice pentru crearea sistemului;
perfectarea Proiectului Tehnic i Proiectului de lucru.
Un 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 finanarea
proiectului, termenul n care produsul finit va fi lansat n exploatare (planul calendaristic de
executare a lucrrilor), costurile aferente, inclusiv, modalitatea i graficul achitrilor, efectul
economic prognozat i timpul de recuperare a cheltuielilor.
Coninutul aproximativ al acestui document poate include:

constrngerile, riscurile, factorii critici, care pot influena succesul proiectului;

condiiile de exploatare a viitorului sistem: arhitectura sistemului, resursele

tehnice i logice, condiiile de funcionare, personalul de exploatare i utlizatorii

sistemului;
termenii de finalizare a etapelor, forma de primire-predare a lucrrilor, resursele
implicate, msurile de protecie a informaiei;
descrierea funciilor sistemului;
posibilitile de dezvoltare viitoare a sistemului;
obiectele informaionale ale sistemului;

interfeele i modalitatea de partajare a funciilor ntre om i sistem;

cerinele privind componentele program i informaionale, SGBD;

indicaii privind lucrrile, care nu vor fi realizate n cadrul proiectului dat.

De asemenea va fi stabilit lista activitilor, automatizarea crora este recomandat i

ordinea n care aceasta va avea loc. Funciile planificate pot fi clasificate conform formatului
MuSCoW, care se descifreaz astfel: Must have funcii obligatorii; Should have funcii
dorite; Could have funcii posibile; Won't have funcii lips.
Realizarea funciilor 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
prioritilor.
Este foarte important ultima categorie de funcii, deoarece este necesar s se stabileasc
graniele proiectului i s se concretizeze explicit funciile, care vor fi lips.
Modelele activitii organizaiei vor fi de dou categorii:
modelul cum este (as-is), care reflect procesele business existente n
organizaie;
modelul cum va fi (to-be), care reflect modificrile necesare ale proceselor
business la introducerea sistemului informaional.
Este preferabil implicarea testerilor ncepnd chiar cu etapa de analiz. Acetia vor participa
la:
soluionarea problemelor legate de obinerea caracteristicilor comparative ale
platformelor tehnice, ale sistemelor de operare, SGBD, alte medii de funcionare;
elaborarea compartimentului planului de lucru asociat fiabilitii i testrii SI.
Implicarea testerilor n etapele iniiale ale proiectului este preferabil pentru orice tipuri de
proiecte. Costurile eliminrii unor erori, generate la una din etapele iniiale, sunt prea marl, iar
prezena testerilor poate salva situaia.
Rezultatele primei etape servesc la elaborarea Concepiei (etapa 2) i Sarcinii Tehnice (etapa
3) a viitorului sistem informaional.

3.1.3.

Elaborarea Concepiei SI i Sarcinii Tehnice

Conform anexei 3, RT 38370656- 002:2006, Concepia este documentul iniial, elaborat la

crearea sistemului, care conine rezultatele ndeplinirii lucrrilor de cercetare tiinific i
experimental i servete drept baz pentru elaborarea ulterioar a documentaiei tehnice. n
dependen de scopurile propuse, Concepia poate fi de baz sau cadru. Concepia cadru se
elaboreaz n cazul, cnd sistemul descris const dintr-o multitudine de sisteme
interconectate sau independente, pentru care ulterior vor fi elaborate concepii de baz.
Concepia cadru se deosebete de cea de baz printr-o expunere rezumativ a materialului
sau prin lipsa capitolelor/subcapitolelor separate, care sunt obligatorii pentru concepia de
baz.
Destinaia Concepiei const n prezentarea viziunii generale asupra sistemului, funciilor
ndeplinite de sistem, descrierii spaiului de drept i informaional i interaciunii cu alte SI.
Conform RT 38370656- 002:2006, Concepia trebuie s conin urmtoarele capitole:
1. Introducere;
2. Generaliti;
3. Spaiul juridico-normativ al funcionrii sistemului;
4. Spaiul funcional al sistemului;
5. Structura organizaional a sistemului;
6. Documentele sistemului;
7. Spaiul informaional al sistemului;
8. Spaiul tehnologic al sistemului;
9. Asigurarea securitii informaionale;
10. ncheiere.

n conformitate cu anexa 4, RT 38370656- 002:2006, Sarcina Tehnic (etapa 3) este

documentul, care determin scopurile i obiectivele, cerinele i datele principale de intrare,
necesare pentru elaborarea SI. Prin elaborarea ST vor fi soluionate urmtoarele probleme:
stabilirea scopului crerii SI;
determinarea funciilor i a subsistemelor;
elaborarea i fundamentarea cerinelor privind subsistemele;
elaborarea i fundamentarea cerinelor privind baza informaional, resursele
matematice, program i tehnice (inclusiv, mijloacele de comunicaie i trasmitere a
datelor);
identificarea cerinelor generale ale sistemului proiectat;
stabilirea listei lucrrilor de creare a sistemului i listei executorilor;
determinarea etapelor crerii sistemului i termenilor de execuie a acestora;
calcularea preliminar a costurilor pentru crearea sistemului i determinarea
nivelului de eficien economic a implementrii lui.
Cerinele-tip referitor la componena i coninutul ST sunt prezentate n tabelul 3.1.
Tabelul 3.1. Compnena i coninutul ST (GOST 34.602- 89)
N
r
c
r
t
1

Coninut

Compartiment
Generaliti

Destinaia i scopurile crerii

(modernizrii) sistemului

Descrierea obiectului
automatizrii

denumirea complet a sistemului i abrevierea

codul (numrul) temei sau al contractului
denumirea executorului i a beneficiarului, rechizitele lor
lista documentelor n baza crora este creat sistemul
data de ncepere i finalizare a lucrrilor
informaii despre surselr financiare i modalitatea de

finanare
ordinea de perfectare i prezentare a rezultatelor crerii
SI, prilor sistemului sau a unor module separate
categoria activitilor de automatizare
lista obiectelor pentru care va fi utilizat sistemul
denumirea i valorile solicitate ale indicatorilor tehnici,
tehnologici, economici etc., care vor fi atini odat cu
implementarea sistemului
informaii succinte despre obiectul automatizrii
informaii despre condiiile de exploatare i caracteristicile
mediului ambiant

Cerine referitoare la sistem

Cerine privind sistemul n totalitate:

cerine referitoare la structura i modul de

funcionare a sistemului (lista subsistemelor, nivelele ierarhice,

gradul de centralizare, modul de schimb informaional, regimurile
de funcionare, interaciunea cu alte sisteme, perspectivele de
dezvoltare)

cerine privind personalul (roluri, calificarea,

regimul de lucru, organizarea instruirii, utilizatorii)

o indicatori asociai destinaiei sistemului

(adaptabilitatea la modificrile sistemului de conducere i a
valorilor parametrilor, scalabilitatea)

o cerine privind fiabilitatea, securitatea,

ergonomia, transportabilitatea, exploatarea, deservirea
tehnic i reparaia, protecia contra unor influene externe,
drepturi de autor, standardizare i unificare

Cerine referitoare la funcii (pe subsisteme):

lista activitilor automatizate

cadrul temporal de realizare a fiecrei

funcii

o cerine privind calitatea realizrii fiecrei

funcii, forma de prezentare a ieirilor, exactitatea i
autencitatea datelor
o lista i criteriile de stabilire a cderilor (refuz
serviciu)
Cerine referitoare la resurse:
o matematice - componena i sfera utilizrii
modelelor i metodelor matematice, algoritmilor existeni i
noi,
o informaionale - componena, structura i
organizarea datelor, schimbul intern de date,
compatibilitatea informaional cu alte sisteme,
clasificatoarele utilizate, SGBD, controlul datelor i folosirea
masivelor de date, procedurile de conferire a valabilitii
juridice documentelor la ieire,
o lingvistice - limbajele de programare, limbile
de interaciune a utilizatorilor cu sistemul, sistemele de
codare, limbajele pentru intrri/ieiri,
o program - independena de platform,
calitatea i metodele de control, utilizarea fondurilor de
algoritmi i programe,
o

tehnice,

metrologice,

organizaionale - structura i funciile

departamentelor de exploatare, protecia contra unor aciuni

eronate,

o
5

Componena i coninutul
lucrrilor de creare a
sistemului

metodice - documentaia normativ-tehnic.

lista stadiilor i a etapelor

termenii de execuie
lista orgaizaiilor executoare
modalitatea i ordinea expertizrii documentaiei

tehnice

programul de asigurare a fiabilitii

Modul de testare, verificare i

primire a sistemului

Cerine referitoare la
componena i coninutul
lucrrilor de pregtire a
obiectului automatizrii
pentru lansarea n exploatare
a SI

Cerine privind documentaia

Surse informaionale

programul de asigurare metrologic

tipurile, componena, volumul i metodele de testare

cerine generale privind acceptarea lucrrilor pe etape
statutul comisiei de primire
transformarea informaiilor de intrare n form
mainolizibil
modificrile introduse n obiectul automatizrii
termenii i modalitatea de selectare i instruire a
personalului

lista documentelor elaborate

lista documentelor pe supori magnetici
documente i materiale informaionale, n baza crora a
fost elaborat ST i sistemul

Proiectul schi include elaborarea soluiilor de preproiect pentru ntregul sistem i prile
componente. Acest etap nu este obligatorie. Dac soluiile principale de proiect au fost
determinate anterior sau sunt suficient de evidente pentru un sistem concret, etapa
proiectului schi poate fi exclus din lista lucrrilor.
De obicei, la etapa proiectului schi sunt stabilite:
funciile SI;

funciile subsistemelor, scopurile lor i efectul preconizat la implementare;

lista grupurilor de lucrri i a unor lucrri separate;
concepia i structura general a bazei informaionale;
funciile SGBD;

componentele sistemului de calcul i a celorlalte resurse tehnice;

funciile i parametrii principalelor resurse program.

La finalizarea acestor activiti este perfectat, coordonat i aprobat documentaia n volum

necesar pentru descrierea setului total de soluii proiect stabilite i suficient pentru
continuarea lucrrilor de creare a sistemului.
n baza Sarcinii Tehnice i a Proiectului schi este elaborat Proiectul Tehnic al SI (etapa 5).

3.1.4.

Proiectul tehnic

Este documentul, care include soliile generale sistemice de proiect, algoritmii de soluionare
a problemelor, estimarea eficienei economice a implementrii sistemului automatizat i lista
activitilor pentru pregtirea implementrii. n cadrul acestei etape sunt executate lucrri
experimentale i de cercetare pentru alegerea final a soliiilor principale de proiect i
calcularea eficienei economice a implementrii sistemului.
Componena i coninutul Proiectului Tehnic sunt prezentate n tabelul 3.2
Tabelul 3.2. Informaii referitoare la Proiectului Tehnic
N
r
cr
t
1

Coninut

Compartiment
Not explicativ

cadrul justificativ pentru elaborarea sistemului

lista executorilor
caracteristica succint a obiectului cu lista indicatorilor
tehnico-economici principali de funcionare i legtuarile cu alte
obiecte
informaii succinte privind soluiile principale de proiect

Structura funcional i
organizaional a
sistemului

justificarea subsistemelor, lista i destinaia lor

lista lucrrilor ndeplininte n cadrul fiiecrui subsistem,
caracteristica succint i coninutul lucrrilor

Enunul problemei i
algoritmii de soluionare

schema legturilor informaionale ntre subsisteme i

lucrri n cadrul unui subsistem
natur organizaional i economic a problemei
(denumirea, scopul, rezumat, metoda, periodicitatea i timpul de
rezolvare, metodele de culegere i transmitere a datelor, relaia cu
alte sarcini, natura utilizrii rezultatelor)
modelul economic i matematic al problemei (prezentarea
structural i detaliat)
informaii normative (coninutul i forma de prezentare)

informaii privind comunicarea cu alte sarcini

informaii pentru decizii ulterioare referitoare la problema

dat

informaii cu privire la modificri (modul de introducere a

schimbrilor i lista informaiilor care fac obiectul modificrilor)
algoritmul de soluionare a problemei (secvena de pai, schema,
formule de calcul)
studiu de caz (set de formulare ale documentelor de intrare
completate, documente convenionale de ieire cu informaii
acumulate i stocate, formulare ale documentelor de ieire,
completate cu rezultatele soluionrii problemei conform
algoritmului elaborat)
4

Organizarea bazei
informaionale

sursele de informaii i modul de transfer

setul de indicatori, utilizai de sistem
lista de documente, termenii i periodicitatea intrrii
soluiile principale de proiect privind organizarea fondului
componena bazei informaionale, inclusiv rechizitele,

definirea lor, marja de valori i lista documentelor bazei

lista masivelor, volumul lor, modalitatea i frecvena
corectrii informaiilor
structura fondului cu descrierea legturilor ntre
elementele constitutive, cernie referitoare la tehnologia crerii
i operrii fondului
metodele de pstrare, cutare, modificare i control
determinarea volumelor i fluxurilor informaionale
exemplu de control la introducerea unor modificri

5
6

Albumul cu formele
documentelor
Resursele matematice

Complexul de mijloace
tehnice

propuneri privind unificarea documentaiei

justificarea structurii resurselor matematice

justificarea alegerii mediului de programare
lista resuselor program de sistem
descrierea i motivarea schemei procesului tehnologic de

prelucrare a datelor

justificarea alegerii structurii complexului tehnic i

grupurilior funcionale ale acestuia

motivarea cerinelor privind echipamentele speciale
setul de aciuni pentru asigurarea fiabilitii funcionrii
echipamentelor
devizul de cheltuieli pentru exploatarea sistemului
calculul eficienei economice anuale obinute din
optimizarea structurii organizaiei, diminuarea costurilor i a
pierderilor, mbuntirea deciziilor administrative
lista msurilor organizaionale pentru perfecionarea
proceselor business

Calculul eficienei
economice a sistemului

Msuri privind pregtirea

obiectului pentru

implementarea
sistemului
1
0

lista lucrrilor pentru implementarea sistemului, care

sunt necesare la etapa proiectrii tehnice, cu indicarea
termenilor i responsabililor

Borderoul documentelor

3.1.5.

Documentaia

La finalizarea etapei proiectrii tehnice sunt identificate componentele produse n serie,

necesare pentru crearea SI. De asemenea sunt determinate cerinele tehnice i este elaborat
sarcina tehnic pentru producerea componentelor speciale.
n cadrul etapei 6 Implementarea codului i perfectarea documentaiei de lucru este creat
produsul program i toat documentaia nsoitoare. Documentaia va include informaiile
necesare i suficiente pentru ndeplinirea lucrrilor de implementare a SI, ca i pentru
susinerea nivelului caracteristicilor funcionale.
Calitatea caracteristicilor funcionale este identificat prin testare. Sunt stabilite urmtoarele
tipuri de testri (ncercri) ale SI: preliminare, de exploatare pilot i testarea final (de
primire). La necesitate pot avea loc testri suplimentare att pentru ntregul sistem, ct i
pentru prile componente.
n dependen de legturile interne ale componentelor i obiectul automatizrii, testrile pot fi
autonome sau complexe. Testrile autonome (de detaliu) includ unele pri ale sistemului. Ele
sunt executate gradual, odat cu finalizarea unei pri pentru darea n exploatare
experimental (pilot). Testrile complexe sunt executate pentru grupuri de pri sau pentru
ntreg sistemul.
Pentru planificarea testrilor este creat documentul Programul i metodica testrilor.
Responsabilul de crearea documentului este fixat n Contract sau ST. Documentul poate
include teste sau exemple de control (n calitate de anexe).
Testrile preliminare determin funcionalitatea sistemului i stabilirea posibilitii de primire
n exploatare pilot. Testrile preliminare trebuie executate dup depanarea i testarea PP i a
resurselor tehnice i prezentarea documentelor privind disponibilitatea lor pentru ncercri. De
asemenea, personalul va fi instruit sau cel puin va face cunotin cu documentaia de
exploatare.
Exploatarea pilot are drept scop determinarea valorilor reale ale caracteristicilor cantitative i
calitative ale sistemului, nivelului de pregtire a personalului pentru exploatarea sistemului i
stabilirea eficacitii reale, ca i introducerea unor modificri (la necesitate).
Testarea de primire este excutat pentru determinarea conformitii sistemului cu Sarcina
Tehnic, estimarea calitii exploatrii pilot i stabilirea posibilitii de primire a sistemului i
lansare n exploatare industrial.

3.2.

Proiectarea tip

Acest paragraf include definiiile principale i sarcina de elaborare a unui proiect, folosind
metoda proiectrii tip sau ingineria softului bazat pe componente (CBSE component based
software engineering).
CBSE este procesul de dezvoltare de software care pune accent pe proiectarea i construirea
sistemelor software utiliznd componente reutilizabile. Atfel spus, proiectarea tip presupune
crearea sistemului din elemente existente apriori. Accentul trece de la programare de
software la compunere de sisteme software, de la implementare la integrare. Cerina
fundamental pentru aplicarea metodei proiectrii tip este posibilitatea decompoziiei
sistemului proiectat n componente constitutive (subsisteme, seturi de activiti, module
program). Pentru realizarea componentelor identificate la etapa decompoziiei sunt alese
soluiile proiect tip, existente pe pia, care sunt adaptate la particularitile concrete ale
organizaiei.

3.2.1.

Soluii proiect tip

Soluia proiect tip (SPT) este o soluie tirajat (care poate fi utilizat de mai multe ori). n
dependen de nivelul decompoziiei sistemului exist urmtoarele clase de SPT:
SPT pe elemente soluii tip pentru o problem sau o categorie de resurse
(informaionale, program, tehnice, matematice, organizaionale);
SPT pe subsisteme rolul elementelor tipizate este ndeplinit de subsisteme
separate, create lund n consideraie completitudinea funcional i minimizarea
legturilor informaionale externe;
SPT pe obiecte proiecte tip de ramur, care includ setul complet de
subsisteme funcionale i resurse ale SI.
n afara elementelor funcionale (logice i tehnice) propriu-zise fiecare soluie tip presupune
existena documentaiei cu descrierea detaliat a SPT i procedurilor de adaptare n
conformitate cu cerinele sistemului elaborat.
Abordarea orientat pe parametri include urmtoarele etape:
alegerea criteriilor de estimare a SPT pentru soluionarea problemelor n cauz;
analiza i evaluarea SPT accesibile conform criteriilor formulate;

selectarea i procurarea celei mai potrivite SPT;

acordarea (reglarea) parametrilor SPT procurate.

Criteriile de estimare a SPT pot fi mprite n urmtoarele grupe:

destinaia i posibilitile pachetului;
caracteristici i proprieti ale pachetului;
cerinele pentru hardware i software;

documentaia pachetului;
factori de ordin financiar;
caracteristici de instalare;
caracteristici de exploatare;
asistena furnizorului pentru implementarea i meninerea pachetului;
evaluarea calitii pachetului i experiena de utilizare a acestuia;
perspectivele de dezvoltare a pachetului.

Abordarea orientat pe model const n adaptarea componentelor i caracteristicilor SPT

conform obiectului automatizrii. n acest caz tehnologia proiectrii trebuie s asigure
aceleai mijloace de lucru att cu modelul SI tip, ct i cu modelul organizaiei concrete.
n depozitul (repozitoriul) cu metainformaii SI tip conine modelul obiectului automatizrii n
baza cruia are loc configurarea produsului program. n consecin, abordarea modelorientat presupune, nainte de toate, construirea modelului obiectului automatizrii utiliznd
instrumente program speciale (SAP Business Engineering Workbench (BEW), BAAN Enterprise
Modeler etc.).
Este posibil, de asemenea, crearea sistemului n baza modelului tip al SI din repozitoriu,
model livrat mpreun cu produsul program i dezvoltat odat cu acumularea experienei de
proiectare a SI pentru diferite ramuri i tipuri de producie.
Depozitul include modelul de baz (de referin) al SI, modele tip pentru diferite clase de SI,
modelele SI ale unor organizaii concrete.

3.2.2.

Etapele realizrii

Modelul de baz (din depozit) al SI include descrierea funciilor bisiness, proceselor

business, obiectelor business, regulilor business, structurii organizaionale, pentru care pot fi
utilizate modelele tip.
Modelele tip descriu configuraiile SI pentru ramuri sau tipuri de producie concrete.

Modelul unei ntreprinderi este construit sau prin alegerea unor fragmente ale modelului de
baz sau ale modelului tip conform praticularitilor 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 pstrat, sub forma unei metadescrieri, n depozit i
poate fi corectat la necesitate. n baza acestui model are loc configurarea automat i
acordarea parametrilor sistemului.
Regulile business determin condiiile utilizrii corecte a componentelor SI i asigur
meninerea integritii sistemului creat.
Modelul funciilor business prezint decompoziia ierarhic a activitii ntreprinderii.
Modelul proceselor business reflect ndeplinirea lucrrilor pentru funciile de la cel mai jos
nivel al modelului funciilor business. Pentru descrierea proceselor este utilizat modelul LPE
(Lanul Procesului pilotat de Evenimente, - Event-driven Process Chain). Modelul
proceselor business permite executarea acordrii (reglrii) modulelor program aplicaii ale
sistemului informaional, conform cu particularitile concrete ale ntreprinderii.
Modelele obiectelor business sunt utilizate pentru integrarea aplicaiilor, care realizeaz
diferite procese business.
Modelul structurii organizaionale a ntreprinderii este o structur ierarhic tradiional, care
include departamentele i personalul.
Implementarea unui SI tip ncepe cu analiza cerinelor, care sunt stabilite la etapa de
cercetare preproiect. Dup alegerea PP n baza modelelor de referin are loc construirea
modelului preliminar al SI, n care sunt reflectate toate particularitile realizrii SI pentru
ntreprinderea dat. Modelul preliminar servete ca baz pentru alegerea modelului tip al
sistemului i determinarea listei componentelor, care vor fi realizate utiliznd alte resurse
program sau vor solicita crearea folosind instrumentele prezente n cadrul SI tip (ABAP n SAP,
Tools n BAAN).
Realizarea unui proiect tip presupune executarea urmtoarelor operaii:
setarea parametrilor globali ai sistemului;
desemnarea structurii obiectului automatizrii;
determinarea structurii datelor principale;
desemnarea setului de funcii i procese realizate;

descrierea interfeelor;
descrierea rapoartelor;
configurarea autorizrii accesului;
configurarea sistemului de arhivare.

n tabelul 3.3 sunt prezentate particularitile principale pentru diferite clase de SPT.
Tabelul 3.3. Avantajele i dezavantajele SPT
Clasa SPT
Realizarea
SPT
SPT pe
elemente
Biblioteci de
programe
orientate pe
metode
SPT pe
subsisteme
Pachete de
programe
aplicative

Avantaje

abordare modular
pentru proiectarea i
documentarea SI

nivel nalt de
integrare a elementelor
realizarea proiectrii
modulare, adaptarea
parametric a
componentelor program
pentru diferite obiecte de

Dezavantaje

cheltuieli mari de timp pentru

racordarea elementelor eterogene ca
rezultat al unor posibile incompatibiliti
informaionale, 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 utilizrii unor
soluii de la productori diferii

gestiune
diminuarea
cheltuielilor
documentare bun a
proceselor de prelucrare a
informaiei
integrarea
componentelor datorit
unitii metodologice i
informaionale,
compatibilitii tehnice i
logice
arhitectura deschis
permite utilizarea SPT pentru
diferite platforme tehnice i
logice
scalabilitatea permite
configurarea SI pentru un
numr variabil de posturi
prin configurare este
posibil alegerea
componentelor

SPT pe obiecte
Proiecte SI de
ramur

3.2.3.

pot aprea probleme, generate de

legarea proiectului tip de un obiect concret,
ceea ce poate conduce n unele cazuri la
necesitatea modificrii structurii
organizaionale i economice a obiectului
automatizrii

Modele de componente

Modelul obiect definete un standard pentru interoperabilitatea componentelor, asigur

interoperabilitatea componentelor dezvoltate n diferite limbaje de programare, aflate pe
platforme diferite. Un model de componente este o definiie de standarde pentru implementarea,
documentarea i repartizarea componentelor.
Modelul de componente specific modul n care trebuie definite interfeele i elementele ce
trebuie incluse n definiia unei interfee.
O list de modele standard pentru componentele software urmeaz mai jos:
1. OMG / CORBA (Common Object Request Broker Architecture) www.corba.org. Un
tutorialul poate fi gsit la http://java.sun.com/developer/onlineTraining/corba/corba.html.
2. Microsoft COM (Component Object Model)
http://www.microsoft.com/com/default.mspx
3. Sun JavaBeans / EJB (Enterprise Java Beans)
http://java.sun.com/javase/technologies/desktop/javabeans/index.jsp . Tutorial la
http://java.sun.com/docs/books/tutorial/javabeans/index.html

ntrebri de control
1. Care din activitile de mai jos sunt etape ale crerii SI?

Desfurarea activitilor de cercetare tiinific

Elaborarea sarcinii tehnice
Cercetarea obiectului
Crearea cerinelor sistemului informaional.

2. Care dintre etapele crerii SI de mai jos fac parte din proiectarea tehnic?

3.

Elaborarea soluiilor tehnice preliminare pentru sistem i prile lui

Elaborarea i adaptarea programelor

Elaborarea i perfectarea domentaiei pentru aprovizionarea cu piese

Elaborarea soluiilor tehnice pentru sistem i prile lui
La care etap are loc elaborarea i adaptarea programelor?
Proiectarea de detaliu
Proiectarea tehnic
Perfectarea documentaiei de lucru

4. Care din indicatorii de mai jos sunt reflectai n schema rutei de deplasare a

documentelor?
Algoritmii existeni de calculare a indicatorilor i metodele posibile de control
Cantitatea documentelor
Mijloacele existente de comunicaie
Locul n care are loc formarea indicatorului documentului
5. n care compartiment al sarcinii tehnice sunt indicate valorile solicitate ale
indicatorilor de fezabilitate a obiectului, care vor fi atini odat cu implementarea SI?
Cerinele sistemului
Destinaia i obiectivele crerii (dezvoltrii) sistemului
Caracteristica obiectului automatizrii
6. n care compartiment al proiectului tehnic este motivat necesitatea
subsistemelor SI?
Enunul problemei i algoritmii de soluionare
Structura funcional i organizaional a sistemului
Memoriul explicativ.
7. Formulai scopul metodologiei proiectrii SI
Reglementarea procesului de proiectare a SI i asigurarea administrrii acestui
proces pentru a garanta ndeplinirea cerinelor att fa de sistem, ct i fa de
caracteristicile procesului de elaborare a sistemului
Automatizarea evidenei contabile analitice i a proceselor tehnologice
Formularea cerinelor privind asigurarea utilizrii complexe a datelor corporative
n managementul i planificarea activitii companiei.
8. Din care categorie de soluii proiect tip face parte SGBD utilizat n SI?
SPT pe elemente
SPT pe subsisteme
SPT obiectuale
9. Ce reflect regulile business n cadrul proiectrii orientate pe model?
Decompoziia ierarhic a activitii funcionale a ntreprinderii
Structura ierarhic a relaiilor dintre subdiviziuni i personal.

4. Analiza i modelarea spaiului funcional al implementrii SI

Noiuni de baz din domeniul business modelrii organizaionale. Misiunea companiei, arborele
scopurilor i strategii de realizare. Descrierea static a companiei: business-potenialul
companiei, funcionalitile companiei, zonele de responsabililate ale managementului.
Descrierea dinamic a companiei. Modelele fluxuri procese. Modele ale structurilor de date.
Modelul business complet al companiei. abloane ale business modelrii organizaionale.
Construirea structurii organizaionale funcionale a companiei. Etapele elaborrii. Cadrul
normativ. Tehnologii informaionale pentru modelarea organizaional.

4.1.

Modelul business complet al companiei

Exist o serie de abordri n efectuarea analizei organizaionale, dar cea mai popular este
metoda cunoscut sub numele engineering. Analiza organizaional conform acestei metode
are loc dup o schem bine determinat cu utilizarea modelului business complet al companiei.
Compania este considerat sistem socio-economic deschis, creat pentru atingerea anumitor
obiective, element al setului de supersisteme externe, ierarhice deschise (piaa, instituiile
statului etc.) i subsisteme interne (secii, hale, brigzi etc.). Posibilitile companiei sunt
determinate de caracteristicile componentelor structurale i modul lor de organizare. n figura

4.1 este prezentat schema generalizat a business modelrii organizaionale. Construirea

modelului business ncepe cu descrierea modelului interaciunii companiei cu mediul extern
conform legii unitii i luptei contrariilor, adic cu definirea misiunii companiei.

Fig. 4.1. Schema generalizat a business modelrii organizaionale

Conform standardului ISO-15704 misiunea companiei include:
1. Activitile desfurate de ctre organizaie n scopul ndeplinirii funciei pentru
care a fost nfiinat, oferind clienilor produse sau servicii;
2. Mecanismul prin care organizaia i realizeaz scopurile i obiectivele.
Misiunea companiei pentru satisfacerea necesitilor solcial-relevante ale pieei este definit ca
un compromis ntre interesele pieei i ale companiei. n acest sens, misiunea ca atribut al unui
sistem deschis este dezvoltat, pe de o parte, reieind din conjunctura pieei i poziionarea
companiei n raport cu ali membri ai mediului extern, iar pe de alt parte reieind din
posibilitile obiective ale companiei i valorile sale subiective, ateptrile proprii i principiile
de care se conduce. Misiunea este o msur a aspiraiilor companiei i, n special, determin
preteniile de pia ale acesteia (obiect al luptei concurente). n baza misiunii este creat
arborele obiectivelor companiei - liste ierarhice de precizare si detalizare a misiunii.
Cu ajutorul arborelui obiectivelor este format arborele strategiilor - liste ierarhice de
precizare si detalizare a procedeelor de atingere a obiectivelor. La nivel corporativ sunt
dezvoltate strategiile de cretere, integrare i investiii. Blocul strategiilor business determin
strategiile de producere, de segmentare i promovare. Strategiile pentru resurse determin
atragerea resurselor materiale, financiare, umane i informaionale. Strategiile funcionale
stabilesc strategiile de organizare a managementului i a etapelor ciclului de via a produciei.
Tot aici sunt clarificate necesitile i obiectul relaiilor de parteneriat (subcontractare, prestare
servicii, promovare etc.).
Toate acestea permit asigurarea clienilor cu produse i/sau servicii n cantiti solicitate, la
locul potrivit, la momentul de timp dorit, cu o anumit calitate i la costuri minime. n lanul de
creare a valorilor compania va ocupa locul optimal din care posibilitile i potenialul ei vor fi
exploatate n cel mai bun mod. Aceasta va da posibilitatea crerii potenialului business al
companiei set de activiti comerciale, direcionate spre satisfacerea necesitilor unor
segmente concrete ale pieei. n continuare, reieind din particularitile canalelor de

distribuie este format ideea iniial referitor la structura organizatoric (sunt determinate
centrele de responsabilitate comercial). Apare nelegerea a ceea ce reprezint resursele de
baz, necesare pentru reproducerea nomenclaturii comerciale.
Potenialul business determin funcionalul companiei list de funcii business, funcii de
management i funcii de asigurare, necesare pentru meninerea la nivel adecvat a tuturor
activitilor. Suplimentar, mai sunt precizate resursele necesare (materiale, umane,
informaionale) i structura companiei.
Construirea potenialului business i a funcionalitilor companiei permite, prin utilizarea
matricei proieciilor, s fie stabilite zonele de responsabilitate a managementului.
Matricea proieciilor este un model reprezentat sub forma unui tabel bidimensional, care
stabilete sistemul de relaii ntre clasificatoare pentru toate combinaiile lor.

Matricea responsabilitii comerciale fixeaz responsabilitatea subdiviziunilor structurale

privind veniturile de la desfurarea activitii comerciale. Detalizarea ulterioar (prin stabilirea
centrelor de responsabilitate financiar) asigur construirea modelului financiar al companiei,
care, la rndul su, permite implementarea sistemului de management bugetar.
Matricea responsabilitii funcionale fixeaz responsabilitatea verigilor structurale (i a
unor specialiti) pentru executarea funciilor business la realizarea proceselor activitii
comerciale (aprovizionare, producere, realizare), ca i a funciilor de management, asociate
administrrii acestor procese (planificare, contabilitate, control marketing, finane,
management resurse umane). Detalizarea de mai departe a matricei (pn la nivelul de
responsabilitate a angajailor) permite obinerea responsabilitilor funcionale ale
personalului, care, mpreun cu descrierea drepturilor, obligaiunilor i mputernicirilor va
permite elaborarea pachetului de instruciuni fielor de post.
Descrierea potenialului business, funcionalitilor i matricelor de responsabilitate reprezint
descrierea static a companiei. n aceast descriere procesele, care au loc n companie,
sunt identificate, clasificate i repartizate pe executori (viitorii stpni ai acestor procese) la un
nivel general (sub form de funcii).
La aceast etap a modelrii business este format setul de regulamente interne fundamentale
i universal recunoscute ale companiei:
Dispoziia de baz privind structura organizatorico-funcional a companiei;
Setul de Dispoziii privind activiti separate (financiar, de marketing etc.);
Fiele de post.
Toate acestea fac activitatea companiei mai transparent prin delimitarea clar i fixarea
documentat a zonelor de reponsabilitate a managerilor.
Detalizarea ulterioar a modelului business are loc la etapa descrierii dinamice a companiei la
nivelul modelelor fluxurilor proceselor. Modelele fluxurilor de procese sunt modele, care
descriu procesul de transformare succesiv n timp a fluxurilor materiale i informaionale
atunci cnd are loc realizarea unei funcii business sau de management. Mai nti (la nivelul de
sus) este descris logica interaciunii participanilor n proces, apoi (la nivelul de jos)
tehnologia de lucru a specialitilor la posturile lor.
Modelarea business se ncheie cu elaborarea modelului structurilor de date, care determin
lista i formatul documentelor asociate proceselor companiei i stabilete formatele de
descriere a obiectelor mediului extern, a componentelor i regulamentelor companiei. Pentru
aceasta este creat un sistem de dicionare (cataloage, clasificatoare) n baza crora sunt
elaborate seturile documentelor i rapoartele necesare.
O astfel de abordare permite descrierea activitii unei companii folosind o mulime universal
de registre de management (scopuri, strategii, produse, funcii, verigi organizatorice etc.).
Structural, registrele de management reprezint clasificatoare ierarhice. Reunind
clasificatoarele n grupuri funcionale i fixnd elementele diferitor clasificatoare prin utilizarea

matricei proieciilor se obine modelul business complet (total) al companiei.

Are loc descrierea scopuri-procese a companiei care permite s fie obinute rspunsuri la
ntrebrile: de ce-ce-unde-cine-cum-cnd-cui-ct-sub ce form (fig. 4.2).

Fig. 4.2. Etapele principale ale descrierii scopuri-procese a companiei

Cu alte cuvinte, modelul busines complet al companiei este setul de modele informaionale
funcional orientate, care asugir rspunsuri reciproc relaionate la ntrebrile de
ce-ce-unde-cine-cum-cnd-cui-ct (fig. 4.3).
n concluzie: analiza organizaional presupune construirea unui set de modele informaionale
dependente reciproc, care include:
Modelul strategic de direcionare (rspunde la ntrebrile: de ce compania face
anume acest tip de business, de ce presupune c va fi competitiv, care obiective i
strategii trebuie de realizat);
Modelul funcional-organizaional (rspunde la ntrebarea cine-ce face i de ce

este responsabil );

Modelul funcional-tehnologic (rspunde la ntrebarea ce-cum se face);

Modelul procesual-pe roluri (rspunde la ntrebarea cine-ce-cum-cui);
Modelul cantitativ (rspunde la ntrebarea cte resurse sunt necesare);
Modelul structurilor de date (rspunde la ntrebarea care este forma de
descriere a regulamentelor companiei i a obiectelor mediului nconjurtor).

Fig. 4.3. Modelul business complet al companiei

Setul prezentat de modele asigur completitudinea necesar i precizia descrierii companiei i
permite elaborarea unor cerine clare privind sistemul informaional proiectat.

4.2.

abloanele modelrii business organizaionale

Tehnologia modelrii business organizaionale presupune utilizarea unor tehnici standardizate

pentru descrierea companiei.

4.2.1.

ablonul pentru elaborarea misiunii

Precum a fost menionat mai sus, orice companie, cu mediul nconjurtor la nivel micro sau
macro, reprezint o ierarhie de sisteme deschise, subiect-orientate, imbricate reciproc. Pe de o
parte, compania este parte a pieei, iar pe de alt parte i apr n lupt concurenial
interesele proprii. Misiunea este rezultatul poziionrii companiei printre participanii pieei.
Din aceast cauz nu este posibil descrierea misiunii doar prin analiza structurii interne a
companiei. Pentru descrierea modelului interaciunii companiei cu mediul exterior (definiia
misiunii companiei) este necesar:
s fie identificat piaa (super-sistemul), parte a creia este compania;
s fie determinate proprietile (necesitile) pieei;
s se determine destinaia (misiunea) companiei, reieind din rolul ei pe pia.
Suplimentar, dup cum a fost subliniat mai sus, misiunea reprezint compromisul ntre
necesitile pieei i dorina companiei de a satisface aceste necesiti. Cutarea
compromisului poate fi organizat folosind ablonul prezentat n figura 4.4.

Fig. 4.4. ablonul pentru elaborarea misunii (matricea proieciilor)

La elaborarea modelului misiunii companiei se recomand:
1. S se descrie baza competitivitii companiei set de caractersitici ale
companiei ca sistem social-economic. De exemplu:
o pentru obiect originalitatea tehnologiilor i exclusivitatea
resurselor (financiare, materiale, informaionale etc.)
o

pentru subiect cunotinele i aptitudinele personalului i

experiena managerilor.
Aceasta determin unicitatea resurselor i aptitudinilor companiei i formeaz poziia
pot.
2. S se identifice conjunctura pieei, adic s se determine dac exist cerere
efectiv la bunurile i serviciile propuse i nivelul de satisfacere a pieei de ctre
concureni. Aceasta permite s fie nelese necesitile pieei i s fie format poziia
trebuie.
3. S fie identificat prezena factorilor nsoitori i compensatori pentru tipul de
activitate ales din partea instituiilor statului n domeniul politicii i economiei.
4. S se estimeze perspectiva dezvoltrii tehnologiei n sfera aleas de activitate.
5. S se estimeze susinerea posibil sau opoziia organizaiilor nonguvernamentale
i structurilor guvernamentale.
6. S fie estimate rezultatele acestor aciuni lund n consideraie limitrile legale,
morale,etice etc. din partea personalului i s fie expus poziia vreau.
7. S fie evaluat nivelul cheltuielilor i veniturilor posibile.
8. S fie estimat posibilitatea realizrii unui compromis acceptabil pentru toate
prile i s se formuleze Misiunea companiei n conformitate cu ablonul din figura 4.5.

Fig. 4.5. ablonul pentru elaborarea misiunii

Misiunea, n sens larg, reprezint concepia de baz a activitii companiei, exprimat cu
ajutorul a opt poziii, care stabilesc relaiile reciproce ale companiei cu alte subiecte:
1. ce va obine clientul pentru satisfacerea necesitilor sale;
2. cine, pentru ce i cum poate fi partener al companiei;
3. care este baza construirii relaiilor cu concurenii (dac exist posibilitatea unor
compromisuri temporare);
4. ce va obine proprietarul i acionarii n rezultatul afacerii;
5.

ce vor obine managerii n rezultatul afacerii;

6.

ce va obine personalul n rezultatul afacerii;

7. n ce poate consta colaborarea cu organizaiile nonguvernamentale;

8. cum vor fi construite relaiile companiei cu statul (n particular, o posibil
participare n susinerea programelor de stat).

4.2.2.

abloane pentru formarea afacerilor

n conformitate cu Misiunea companiei sunt determinate necesitile social relevante la

satisfacerea crora sunt direcionate activitile companiei. Dezvoltarea potenialului business
al companiei poate fi realizat folosind ablonul formrii businessurilor, prezentat n figura 4.6.

Fig. 4.6. ablonul formrii businessurilor

n rezultat este format (aleas, descris) piaa de baz i produsul de baz, detalizarea crora
determin oferta companiei pe partea consumatorilor (grupurile de mrfuri i grupurile
omogene (relativ la produsele companiei) pentru satisfacerea cererii (segmentele pieei). Cu
ajutorul matricei proieciilor (fig. 4.7) este stabilit corespondena ntre grupurile de produse i
segmentele pieei i sunt determinate afacerile companiei (la intersecia liniilor i coloanelor
celulele matricei).

Fig. 4.7. ablonul formrii afacerilor (matricea proieciilor)

I n baza listei afacerilor, cu ajutorul matricei proieciilor este format clasificatorul funciilor
business al companiei (fig. 4.8).

Fig. 4.8. ablonul formrii funciilor business de baz

Pentru formarea funciilor de management principale mai nti sunt elaborate i aprobate dou
clasificatoare de baz Dispoziia privind componentele managementului (lista
instrumentelor /contururilor administrative) i Dispoziia privind etapele ciclului de
management (lan tehnologic de operaii, realizate succesiv de manageri atunci cnd
organizez activitile unui instrument/ contur administrativ). Analogic n continuare, folosind
matricea proieciilor, este format lista funciilor principale ale managementului. n fig. 4.9 sunt
prezentate exemple de clasificatoare n baza crora a fost construit matricea-generator al
funciilor principale ale managementului.

Fig. 4.9. ablonul formrii funciilor administrative principale

Proieciile matriceale din figurile 4.8 i 4.9 permit formularea funciilor cu orice nivel de
detaliere prin descriere mai amnunit a liniilor sau/i coloanelor.
Zonele de responsabilitate sunt formate cu ajutorul matricei proieciilor organizaionale
folosind ablonul din figura 4.10.

Fig. 4.10. ablonul repartizrii funciilor pe verigile organizaionale

Matricea proieciilor organizaionale este un tabel bidimensional cu titlurile liniilor formate din

verigile executorii, iar titlurile coloanelor denumirile funciilor, executate n companie. Pentru
fiecare funcie este determinat veriga executorie, responsabil de aceast funcie.
Procesul de completare a acestui tabel permite s se gseasc, pentru fiecare funcie,
subdiviziunea executorie sau colaboratorul responsabil. Analiza tabelului completat permite s
se determine golurile att pentru funcii, ct i pentru colaboratori, i s se rerepartizeze
raional lucrrile pe colaboratori. Toate acestea vor fi fixate n Dispoziia privind structura
organizaional a companiei document intern, n care sunt fixate: produsele i serviciile
companiei, funciile ndeplinite, verigile executorii, funciile de producere, repartizarea funciilor
pe responsabili.
Tabelul proieciilor funciilor pentru o organizaie de mrime medie poate conine n jur de 500
elemente (de exemplu, 20 verigi i 25 funcii). n cazul companiilor mari numrul elementelor
poate fi de ordinul ctorva mii.
n mod analogic are loc construirea matricei responsabilitii comerciale.

4.2.3.

ablonul de descriere flux-proces

ablonul de descriere flux-proces (fig. 4.11) asigur nelegerea procesului de transformare

succesiv a resurselor n produse ca rezultat al eforturilor executorilor, care activeaz n baza
regulamentelor.

Fig. 4.11. Modelul flux-proces

Modalitile de construire a modelelor proceselor vor fi prezentate mai jos.

4.3.

Construirea modelului organizaional-funcional al companiei

Modelul organizaional-funcional al companiei este construit n baza schemei funcionale a

activitii companiei (fig. 4.12).

Fig. 4.12. Schema funcional a companiei

n baza misiunii sunt formate obiectivele i strategiile companiei. Cu ajutorul lor este stabilit
setul necesar de produse i, ca i consecin resursele solicitate. Producerea bunurilor are loc
datorit prelucrrii resurselor n ciclul de producie de baz. Componentele sale formeaz
business-funciile necesare pentru achiziia resurselor, producerea i distribuirea produselor la
locul de vnzare. Pentru gestiunea procesului de producere este format setul de componente
de management, care genereaz o list de funcii de management. Pentru a susine procesele
de producere i de management sunt formate seturi de funcii de sprijin aferente (de
securitate, echipare tehnic, profilactic i reparaii, etc). Aceast abordare permite de a
descrie organizaia cu ajutorul unui set universal de registre de management (al obiectivelor,
strategiilor, produselor, funciilor, unitilor organizatorice, etc). Registrele administrative sunt
clasificatoare ierarhice. Combinnd clasificatoarele n grupuri funcionale i fixnd reciproc
elementele din diferite clasificatoare cu ajutorul proieciilor matriceale, poate fi obinut modelul
structurii organizaionale a companiei.
Pentru construirea modelului funcional-organizaional sunt utilizate dou tipuri de modele
elementare.
Modelele arborescente (clasificatoarele) liste ierarhice exacte ale obiectelor
administrative evideniate (verigi organizaionale, funcii, resurse, inclusiv mecanisme de
execuie a proceselor business, documente i structura lor, .a.m.d.). Fiecare element al unui
clasificator poate fi caracterizat suplimentar cu ajutorul unor atribute: tipul, scala utilizat,
comentarii etc. De facto, clasificatoarele reprezint un set de registre administrative, cu
informaii de obicei calitative, mulimea crora stabilete sistemul de coordonate pentru
descrierea activitii companiei. Cantitatea acestor liste-clasificatoare este determinat de
scopurile construirii modelului.
Modelele matriceale sunt proiecii, care determin un sistem de relaii pentru orice
combinaii ale clasificatoarelor. Legturile pot avea atribute suplimentare (direcie, denumire,
indice, scal i greutate).
I n modelul iniial (de nceput) sunt utilizate doar cteva clasificatoare ale domeniul obiectiv:

grupurile principale de produse i servicii ale companiei;

resursele de care are nevoie compania pentru producere;
funciile (procesele) ndeplinite n companie;
verigile organizaionale ale companiei.

n clasificatorul funciilor de obicei sunt evideniate trei compartimente de baz:

 funciile de baz funciile legate direct de procesul de transformare a resurselor

n produse i servicii;
funciile de management sau funciile de conducere cu ntreprinderea;
funciile de aprovizionare care asist activitile de producere, comercial i de
management.
Funcia principal a companiei este livrarea produselor i/sau prestarea serviciilor. Din aceast
cauz mai nti are loc descrierea formal, coordonarea i aprobarea de ctre conducerea
ntreprinderii a listei afacerilor (direciilor activitii comerciale), produselor i serviciilor. Din
acest clasificator contragenilor externi trebuie s le fie clar prin ce este interesant compania
pentru pia, iar pe plan intern cum este motivat necesitatea unei funcii concrete.
n rezultatul acestor operaii are loc identificarea setului de funcii (funcionalului) i este creat
terminologia unitar de descriere a funciilor companiei, care va fi coordonat cu toi managerii
relevani. Este important ca nivelul de detalizare a funciilor s corespund nivelului de
detalizare a verigilor n clasificatorul verigilor organizaionale. Dup formarea clasificatoarelor
principale, cu ajutorul proieciilor matriceale are loc fixarea funciilor pe verigi organizaionale.
Procesul formrii matricei proieciilor funciilor pe verigi organizaionale seamn cu jocul de
tic-tac-toe (fig.4.10).
Practica uzual de construire a modelelor structurii organizaionale susine dou nivele de
detalizare:
modelul agregat;
modelul detalizat.
Modelul agregat este modelul structurii organizaionale n care registrele de eviden sunt
limitate la 2-3 nivele de detaliere.
Scopul construirii acestui model este punerea la dispoziia conducerii superioare a informaiei
despre structura organizaional pentru realizarea analizei strategice i analizei privind
corespunderea structurii date strategiei i mediului nconjurtor al companiei. Modelul poate de
asemenea pus la dispoziia utilizatorilor externi (de exemplu, investitorilor poteniali sub form
de ilustrare a planului business, clienilor mari .a.).
Modelu detalizat este modelul structurii organizaionale cu o detalizare mai adnc a
registrelor de eviden, dect n modelele agregate. Nivelul de detalizare este determinat de
necesiti concrete ale companiei (crearea unor regulamente organizaionale).
Scopul construirii acestui model este prezentarea informaiilor despre repartizarea
obligaiunilor funcionale ntre subdiviziunile companiei, ca i despre organizarea proceselor
business n companie. Construirea modelului detalizat permite crearea diferitor regulamente
interne, cum ar fi Dispoziia despre structura organizaional (fig. 4.13).

Fig. 4.13. Schema elaborrii Dispoziiei despre structura organizaional-funcional

Mai jos este prezentat un exemplu de descriere a unor fragmente ale modelului organizaionalfuncional a unei ntreprinderi (fig. 4.14) i a unei uniti comerciale (fig. 4.15) Matricele
proieciilor prezentate servesc drept baz pentru evidenierea proceselor business ale
companiei i stabilirea posesorilor lor n cadrul urmtoarelor etape de creare a sistemului
informaional.

Fig. 4.14. Repartizarea funciilor pe subdiviziuni ( ntreprindere)

Fig. 4.15. Repartizarea funciilor pe subdiviziuni (unitate comercial)

Funciile subdiviziunilor unei ntreprinderi productoare sunt prezentate pentru urmtoarele
domenii funcionale:
management corporativ;
finane;
personal;
resurse materiale;
comenzi;
producere;
elaborare produse;
planificare;
aprovizionare/achiziii;
calitate;
furnizare/vnzri.
Pentru unitatea comercial au fost alese alte domenii funcionale (fig. 4.15).
Henry Fayol, acreditat ca iniiatorul conceptului, a considerat c sunt cinci funcii principale, n
cuvintele lui: "S conduci nseamn s prevezi, s planifici, s organizezi, s comanzi, s
coordonezi i s controlezi". Desigur c ali cercettori au venit cu alte listri, dar o cercetare a
literaturii de specialitate ne arat c funcii principale ale managementului sunt considerate
urmtoarele: planificarea, organizarea, supravegherea (comanda), motivarea, direcionarea,

coordonarea, controlul, comunicarea, investigarea, evaluarea, decizia, personal, reprezentarea

i negocierea.

4.4.

Mijloace instrumentale pentru modelarea

organizaional
Utilizarea tehnologiilor moderne pentru modelarea organizaional conduc la diminuarea
substanial a timpului necesar pentru modelare. La nceputul anilor 1990 au aprut primele
instrumente program dedicate problemelor de organizare a managementului ntreprinderilor.
Orgware o nou clas de programe era orientat pe soluionarea problemelor de
sistematizare, pstrare i prelucrare a informaiilor necantitative din business, care anterior
nu aveau susinere adecvat de calculator.
BIG-Master a fost primul produs rusesc, creat sub form de instrument de calculator pentru
susinerea concepiei de management, numit management regulat. Obiectivul principal al
Orgware era trecerea la proceduri i regulamente strict documentate. La baza paradigmei
computaionale a managementului regulat este pus abordarea: Trebuie de creat nu un
sistem de documente legate reciproc, ci un sistem de modele informaionale intercorelate, care
vor genera documentele necesare.
Baza conceptual a BIG-Master este abordarea procesual a organizrii activitii ntreprinderii.
La nivelul superior sistemul de procese este descris de arborele funciilor (pentru care adesea
este folosit termenul funcional ). Funciile la acest nivel sunt considerate procese
comprimate. Toate procesele-funcii trebuie, minimum, definite (adic identificate ca tip de
activitate cu obiectiv i rezultate) i clasificate pe tipuri (de baz, auxiliare, de management).
De asemenea, trebuie s fie repartizate responsabilitile i mputernicirile de administrare a
proceselor n baza regulamentelor. Pentru descrierea companiei BIG-Master utilizeaz la acest
nivel dou tipuri de modele: arborescente (clasificatoarele) i mariceale (proieciile).
La nivelul inferior procesele evideniate (procesele cheie) pot fi descrise sub forma unei
succesiuni de operaii tehnologice (obinerea rezultatelor). Pentru aceasta sunt utilizate
modelele flux ale proceselor business, destinaia crora este descrierea relaiilor orizontale n
cadrul ntreprinderii, care leag ntre ele obiectele descrise anterior, prin fluxuri informaionale
i materiale. Pentru analiza structural i proiectarea proceselor, descrise de modelele de flux,
BIG-Master utilizeaz tehnologia SADT (IDEF). Prezena mecanismului proieciilor matriceale
permite determinarea i descrierea proceselor companiei sub forma unui sistem interconectat
unitar.
Deoarece clasificatoarele au o structur ierarhic modelul business include relaiile funcieexecutor pentru toate nivelele de detalizare, ceea ce permite cu ajutorul generatorului de
rapoarte, configurarea pentru obinerea unor vederi asupra companiei referitor la o problem
concret de management. Sistemul de proiecii permite reflectarea n raport a oricror
caracteristici pentru un obiect concret (de exemplu, cerine privind calificarea personalului
implicat n proces). Suplimentar, vederea companiei poate fi legat cu orice coordonat, de
exemplu, document sau colaborator care sunt procesele i cum sunt implicai.
Clasificatoarele, proieciile i modelele flux ale proceselor business pot fi vizualizate n diferite
moduri. Pentru clasificatoare liste i arbori (grafuri orientate), pentru proiecii liste legate i
matrice transpuse, iar pentru modelele fluxurilor proceselor business diagrame IDEF0 (IDEF3)
i descriere textual, ceea ce faciliteaz nelegerea problemelor de ctre participani.
Construirea modelelor fluxurilor are loc sub forme obinuite tabelare.
n model este posibil formarea unui numr nelimitat de clasificatoare, proiecii i modele de
flux, si ca rezultat, rapoarte i documente pentru descrierea i crearea regulamentelor de
activitate.
Prezena n BIG-Master a instrumentelor de modelare este foarte util. Modelele matriceale
susin integrarea vertical descrierea sistem-obiectiv detaliat, conform ierarhiei i funciilor.
n modelul procesual domin abordarea funcional-tehnologic integrarea orizontal a
operaiilor business pe proceduri. Aceste posibiliti asigur simplitatea i comoditatea

modelrii organizaionale folosind instrumentul BIG-Master.

ntrebri de control

1. Definii noiunea Misiunea companiei

Activitile desfurate de ctre organizaie n scopul ndeplinirii funciei
pentru care a fost nfiinat, oferind clienilor produse sau servicii;
Arborele obiectivelor i strategiilor;

Mecanismul prin care organizaia i realizeaz scopurile i

obiectivele.

2. Definii noiunea Funcionalul companiei

list de funcii business i funcii de management;

list de funcii business, funcii de management i funcii de asigurare;
list de funcii business.

3. Definii noiunea Potenialul business al companiei

set de activiti comerciale, direcionate spre satisfacerea necesitilor unor
segmente concrete ale pieei;
list de funcii business, funcii de management i funcii de asigurare;
list de funcii business.
4. Care model rspunde la ntrebrile cine ce face n companie i cine de ce
este responsabil?

Modelul funcional-tehnologic;

Modelul funcional-organizaional;
Modelul procesual-pe roluri

5. Care model rspunde la ntrebrile de ce compania a ales anume acest

business, de ce consider c va fi competitiv, care obiective i strategii trebuie realizate
pentru aceasta?

Modelul funcional-organizaional;

Modelul funcional-tehnologic;
Modelul strategic de direcionare;
Modelul procesual-pe roluri;

6. Care model rspunde la ntrebrile cine-ce-cum-cui?

Modelul strategic de direcionare;

Modelul funcional-organizaional;
Modelul funcional-tehnologic;
Modelul procesual-pe roluri;
Modelul cantitativ;
Modelul structurilor de date.

7. Care model determin lista i formatul documentelor, asociate proceselor

companiei, desemneaz formatele de descriere a obiectelor mediului exterior, a
componentelor i regulamentelor?
Modelul strategic de direcionare;

Modelul funcional-organizaional;
Modelul funcional-tehnologic;
Modelul procesual-pe roluri;
Modelul cantitativ;
Modelul structurilor de date.

8. Care modele descriu procesul de transformare consecutiv n timp a

fluxurilor materiale i informaionale, care are loc la realizarea unei funcii business sau
de management?

Modelele funcionale;

Modelul fluxurilor de procese;

Modelul cantitativ;
Modelul structurilor de date.

9. Care sunt tipurile de modele elementare, utilizate pentru construirea

structurii organizaional-funcional?
Modele matriceale;
Modele arborescente (clasificatoarele);
Modele procesuale.

5. Specificarea cerinelor funcionale

Modele procesuale de flux. Abordarea procesual a organizrii activitii organizaiei. Legtura
dintre concepia abordrii procesuale i concepia organizrii matriceale. Elementele principale
ale abordrii procesuale: graniele procesului, rolurile cheie, arborele obiectivelor, arborele
funciilor, arborele indicatorilor. Evidenierea i clasificarea proceselor. Procesele de baz,
procesele auxiliare, procesele de management. Modele de referin. Studiul preprpoiect a
organizaiei. Anchetarea, sondajul, fotografia timpului de lucru al personalului. Rezultatele
studiului preproiect.

5.1.

Modele de flux procesuale

Elaborarea cerinelor sistemului proiectat are loc n baza descrierii statice i dinamice a
companiei. Descrierea static, prezentat mai sus, se produce la nivelul modelelor funcionale
i include potenialul business, funcionalul i matricele de responsabilitate.
Dezvoltarea ulterioar (detalizarea) a modelului business are loc la etapa descrierii dinamice a
companiei la nivelul modelelor de flux procesuale.
Modelele de flux procesuale sunt modelele, care descriu procesul de transformare succesiv n
timp a fluxurilor materiale i informaionale pentru realizarea unei funcii business sau de
management. La nivelul superior este descris logica interaciunii participanilor la proces, la
nivelul inferior tehnologia de lucru a specialitilor la posturile lor de lucru. Modelele de flux
procesuale rspund la nrebrile cine-ce-cum-cui (fig. 4.3).
Situaia la moment este caracterizat de trecerea de la modelul funcional tradiional de
activitate a companiei, construit pe principiile diviziunii muncii, specializrii nguste i
structurilor ierarhice rigide, la modelul procesual, bazat pe integrarea lucrrilor n jurul
proceselor business.
Dezavantajele principale ale abordrii funcionale sunt:
divizarea tehnologiilor de executare a lucrului pe segmente separate, adesea
independente ntre ele, executate de diferite subdiviziuni;
lipsa unei descrieri integre a tehnologiilor;
dificultatea reunirii (integrrii) celor mai simple sarcini ntr-o tehnologie, care
produce mrfuri sau servicii reale;
lipsa responsabilitii executorilor de rezultatul final;
costuri mari pentru coordonare, stabilirea interaciunilor, control .a.m.d.;
lipsa orientrii spre client.
Abordarea procesual deplaseaz accentele de la administrarea unor elemente structurale
separate la managementul proceselor business, care leag activitatea tuturor elementelor
structurale. Fiecare proces parcurge o serie de subdiviziuni, n ndeplinirea lui particip

specialiti din diferite secii ale companiei. Frecvent poate fi observat situaia n care nimeni
nu gestioneaz procesul propriu-zis, administrate sunt doar subdiviziunile. Mai mult, structura
companiei este construit fr a lua n consideraie optimizarea proceselor business, care
asigur funciile necesare. Abordarea procesual permite eliminarea fragmentrii activitilor,
decalajelor organizaionale i informaionale, dublarea, utilizarea neraional a resurselor
financiare, materiale i de personal.
Abordarea procesual a organizrii activitii intreprinderii presupune:
delegarea larg a mputernicirilor i responsabilitilor ctre utilizatori;
diminuarea nivelelor de luare a deciziilor;
combinarea principiului managementului pe obiecte cu organizarea lucrului n
grup;
atenie sporit la asigurarea calitii;
automatizarea tehnologiilor de exectuare a proceselor business.
I n standardul ISO 9000:2000 (p. 2.4) noiunea "Abordare procesual" este defint astfel:
"Orice activitate sau set de activiti n care sunt utilizate resurse pentru transformarea
intrrilor n ieiri poate fi considerat proces. Pentru o funcionare rezultativ organizaiile
trebuie s defineasc i s administreze multiple procese interdependente i care
interacioneaz. Frecvent ieirea unui proces formeaz intrarea altui proces. Identificarea i
managementul sistematic al proceselor utilizate n cadrul organizaiei i, n special,
interaciunii acestor procese poate fi considerat fiind abordare procesual.
Principiul de baz al abordrii procesuale definete structurarea sistemului business conform
activitii i proceselor business ale organizaiei, i nu conform structurii organizaionale.
Anume procesele business, care asigur rezultat relevant pentru consumator, prezint valoare
i pentru specialitii, care proiecteaz sistemele informaionale. Modelul procesual al companiei
este elaborat n conformitate cu urmtoarele poziii:

1. Nivelul superior al modelului trebuie s reflecte doar contextul diagramei

interaciunea unicului proces contextual modelat al companiei cu lumea extern.
2. La nivelul 2 vor fi reflectate procesle business grupate tematic i legturile lor
reciproce.
3. Fiecare activitate trebuie detalizat pn la procese business.
4. Descrierea unei operaii business elementar are loc folosind minispecificaiile.
Abordarea procesual solicit studierea complex a tuturor prilor vieii organzaiei bazele
juridice i regulile de activitate, structura organizaional, funciile i rezultatele executrii lor,
interfeele, asigurarea cu resurse, cultura organizaional. n rezultatul analizei va fi creat
modelul cum este. Cercetarea acestui model folosind diferite metode analitice permite s se
verifice ct de raionale sunt procesele business, s se determine dac o operaie anume este
orientat spre un produs final social relevant sau este o procedur birocratic redundant.
n timpul analizei proceselor business sunt cercetate detaliat sferele de responsabilitate ale
subdiviziunilor, conductorilor i angajailor. Sunt stabilite coordonatele proprietarilor
proceselor business, n rezultat procesele nceteaz s fie orfane, sunt create condiii pentru
dezvoltarea i implementarea sistemelor de stimulare i responsabilizare pentru rezultatele
finale, sunt determinate momentele i procedurile de transferare a responsabilitii. Analiza i
evaluarea proceselor business permite justificarea standardelor de performan a proceselor, a
riscurilor admisibile i a unui spaiu de libertate la luarea deciziilor, stabilirea unor normative
limit de cheltuieli de resurse pentru o unitate de efect.
Totui, o companie curat procesual este mai degrab ilustrarea organizrii corecte a
activitilor. n realitate, toate procesele business ale companiei au loc n cadrul structurii
organizaionale, care descrie competenele i relaiile funcionale.
Managementul activitilor curente are loc pe dou direcii:

managementul domeniilor funcionale, care susin mulimea proceselor business

integrate, divizate pe operaii,

managementul proceselor business integrate, obiectivul cruia este

direcionarea i coordonarea proceselor unificate pentru ndeplinirea comenzilor
operative ale clienilor i proiectelor proprii ale organzaiei (fig. 5.1).

Fig. 5.1. Schema managementului activitii companiei

Obiectivul principal al proiectrii organizaionale este determinarea compromisului optimal
ntre eficiena resurselor i eficacitatea proceselor. Specializarea rigid a subdiviziunilor
economisete resursele organizaiei, dar diminueaz calitatea realizrii proceselor. Crearea
unor echipe procesuale cu specialiti proprii pentru toate operaiile cheie diminueaz timpul
necesar i sporete exactitatea execuiei procesului, dar cost scump. Uneori organizaiile i
pot permite alegerea acestei ci, n special n cazurile n care este vorba despre procese cu
valoare ridicat pentru care clientul este gata s plteasc. Dar, de regul, este cutat un
compromis folosind structurile matriceale procesuale.
Atunci cnd compania ncepe s se orienteze spre procese foarte important devine rolul
proprietarilor proceselor integrate interfuncionale, care au tangene cu multe domenii
funcionale. n afar de aceasta, noua paradigm de activitate genereaz apariia unui numr
mare de procese de management, repartizate pe ntreaga companie (nu concentrate n uniti
organizaionale specializate): sistemul de calitate, buget, marketing .a.m.d. Din aceast cauz
considerarea exerciiului bugetar drept problem organizaional (nu numai financiar)
presupune delegarea mputernicirilor, adic a puterii (de care nu se refuz uor!).
Responsabilitatea adoptrii unor decizii financiare este delegat la nivele mai joase: ncheierea
unui contract de plat, achiziii, reduceri de pre sau creditare .a.m.d. Aceasta permite
simplificarea legturilor ntre subdiviziuni i diminuarea numrului de nivele verticale prin care
trec documentele, adic este o condiie necesar pentru realizarea schemei clasice de
reinginerie.
Ca i concluzie, orientarea spre procese implic modificarea structurii organizaionale, strutura
devenind mai plat, ceea ce ilustreaz legtura strns ntre descrierea vertical a
organizaiei (structur cu distribuirea responsabilitilor, mputernicirilor i relaiilor) i
descrierea orizontal sistem de procese.

5.2.

Elementele de baz ale abordrii procesuale

n cadrul abordrii procesuale o ntreprindere este considerat sistem business sistem, care
const dintr-o mulime de procese business intercorelate, obiectivul final al crora este
producerea de bunuri sau servicii.
Procesul business este neles ca set de activiti de diferite tipuri, care creeaz rezultat cu
valoare pentru consumator. Procesul business este un lan de lucrri (activiti, funcii)
rezultatul cruia este un bun sau un serviciu oarecare.
Fiecare proces business are graniele sale (v. p. 6 i 7) i roluri. Exist urmtoarele roluri cheie:

Proprietarul procesului este persoana responsabil de evoluia i rezultatele procesului n

totalitate. El trebuie s cunoasc procesul business, s urmreasc ndeplinirea i s
perfecioneze eficacitatea lui. Proprietarul procesului business trebuie s fie comunicabil, cu
entuziasm, s poat influena oamenii i s produc schimbri.
Liderul echipei este un colaborator cu cunotine n domeniul procesului business i caliti
personale pozitive.
Comunicatorul este lucrtorul care instruiete echipa n metodele de lucru, mpreun cu
liderul pregtete edinele echipei i analizeaz rezultatele lor.
Coordonatorul procesului lucrtorul reponsabil cu activitatea de coordonare a tuturor
prilor afacerii i care asigur legtura cu alte procese business. Coordonatorul trebuie s
posede capaciti administrative i s neleag obiectivele strategice ale ntreprinderii.
Membrii echipei sunt specialiti de diferite nivele ierarhice. Membrii echipei sunt susinui i
asigurai metodic de consultant i comunicator; mpreun cu liderul modeleaz, analizeaz i
estimeaz procesul business.
Echipa este unul din elementele de baz ale abordrii procesuale. Exist cteva tipuri de
echipe procesuale:
Echipa situaional lucreaz de obicei n baz constant i execut un lucru periodic
repetabil.
Echipa virtual este creat pentru dezvoltarea unui produs sau serviciu nou.
Managerul situaional specialist de calificare nalt, care poate ndeplini independent pn la
90% din volumul de lucru.
O sarcin important a abordrii procesuale este formarea echipelor procesuale. Pregtirea i
formarea echipei include:
cursuri de instruire;
formare practic (training) pentru asimilarea metodelor, metodicilor .a.;
testarea compatibilitii psihologice;
testarea aptitudinilor practice.
Schema care descrie modalitatea n care are loc atingerea unui set definit de obiective n
rezultatul ndeplinirii proceselor business se numete arbore al obiectivelor. Arborele
obiectivelor are, de obicei, form ierarhic. Fiecare obiectiv are propria pondere (cantitativ
sau calitativ) i propriul criteriu de accesibilitate.
Procesele business realizeaz funciile business ale ntreprinderii. Prin funcie business
nelegem un tip de activitate a ntreprinderii. Mulimea funciilor business reprezint
decompoziia ierarhic a activitii funcionale a ntreprinderii i se numete arbore al
funciilor.
Funciile business sunt legate de indicatorii de activitate a ntreprinderii, care formeaz
arborele indicatorilor. n baza indicatorilor de activitate este construit sistemul indicatorilor
de estimare a eficacitii ndeplinirii proceslor. Proprietarii proceselor controleaz procesele
business proprii utiliznd acest sistem de indicatori. Cei mai frecveni indicatori de msurare a
performanei proceselor business sunt:
cantitatea de produse de calitate stabilit ntr-un anumit interval de timp;
cantitatea de produse utilizate;
durata ndeplinirii operaiilor-tip .a.

5.3.

Selectarea i clasificarea proceselor

La descrierea procesual minimum dou probleme trebuie soluionate:

1. Identificarea ntregului sistem de domenii funcionale i a proceselor

companiei, ca i legturile reciproce ntre procese.

2. Selectarea proceselor integrate cheie i descrierea lor la nivelul fluxurilor.

Fiecare activitate a companiei este realizat ca proces, care are consumatorul su: extern
clientul sau intern colaboratorii sau subdiviziunile companiei, care realizeaz alte procese. La
etapa descrierii sistemice a proceselor este determinat relevana fiecrui proces, inclusiv are
loc eliminarea activitilor neclare. La aceast etap sunt selectate procesele cheie pentru
descrierea fluxurilor, necesare pentru crearea sistemului informaional al ntreprinderii.

5.3.1.

Tipuri de procese business

Cele mai frecvente sunt urmtoarele patru tipuri de procese business:

1. Procesele care creeaz cea mai mare plusvaloare (valoarea economic, care este
determinat prin contrapunerea cheltuielilor cu producia finit);
2. Procesele care creeaz cea mai mare valoare pentru clieni (valoarea de
marketing din contul diferenierii produciei).
3. Procesele cu cea mai intensiv interaciune ntre verigile de producie, care
creeaz costuri tranzacionale.
4. Procesele definite de standardele ISO 9000 ca fiind obligatorii pentru descrierea
i implementarea sistemului de management al calitii.
Un pas foarte important la structurarea unei companii este evidenierea i clasificarea
proceselor business. Sunt recomandate urmtoarele categorii de procese:
de baz (primare, principale);
de management;
de asigurare;
auxiliare;
de dezvoltare.
Figura 5.2 prezint modelul activitii unei companii la descrierea creia sunt utilizate
procesele de management, procesele business de baz i de asigurare.

Fig. 5.2. Modelul simplificat al activitii companiei

Procesele business de baz sunt procesele orientate pe producerea mrfurilor i prestarea
serviciilor, care reprezint valoare pentru clieni i asigur obinerea beneficiului.

5.3.2.

Procesele de baz

Procesele de baz formeaz ciclul de via al produciei companiei. Criteriul de eficacitate

al acestor procese este calitatea, exactitatea i punctualitatea executrii fiecrei comenzi.
Muli consumatori consider sporirea nivelului de calitate mai important dect diminuarea
preului. Un vnztor iscusit poate obine, n condiii de concuren, comanda pentru
executarea unor lucrri, ns doar calitatea produsului sau serviciului va determina dac
clientul va mai veni n viitor la acest vnztor. Procese din aceast categorie, ntr-o companie
cu activitate susinut, pot fi multe. Toate trebuie descrise pe lanuri producere-comerciale:

interaciunea primar cu clientul i determinarea cerinelor acestuia realizarea solicitrii

(cererii, comenzii, contractului) support post-vnzare i monitorizarea satisfacerii
necesitilor.
Procesul realizarea (solicitrii clientului) poate fi descompus n urmtoarele subprocese
procese de nivel mai jos:
elaborarea (proiectarea) produciei;

achiziii (bunuri, materiale, componente);

transportarea (achiziiilor);
descrcarea, primirea la depozit i pstrarea (cumprturilor);
producerea (conform ciclului tehnologic i logistica intern);
primirea la depozit i pstrarea (produciei finite);
start-up (lansare i ajustare);

prestare servicii (conform contractului sau individuale) .a.

Aceste lanuri de asemenea sunt relativ standardizate, de exemplu, n standardul ISO redacia
anului 1994 multe din aceste procese sunt obligatorii i trebuie certificate. Utiliznd proiecia
fiecrui business, produs sau serviciu (dintre cele selectate) pe clasificatorul standard (de mai
sus) al ciclului de via sau de producie putem verifica care lanuri business exist la
ntreprindere.
Pentru estimarea etapelor de lucru cu orice document putem utiliza de asemenea analiza
ciclului de via a documentului, care poate fi dup cum urmeaz:
prezint datele iniiale;
pregtete, elaboreaz;
completeaz;
corecteaz;
perfecteaz;
semneaz;
verific conformitatea cu cerinele stabilite;
vizeaz;
coordoneaz;
aprob;
accentueaz (ia n consideraie, utilizeaz);
pstreaz;
face o copie.
Aici poate fi utilizat propria matrice-generator n calitate de instrument pentru verificarea
completitudinii identificarea ciclului.
Pot fi de asemenea utilizate modelele de referin ale activitii unor companii analogice pot
fi comparate cu procesele din firmele concurente, lider al ramurii, i perfectate.

5.3.3.

Procesele de management

Procese de management sunt procesele, care acoper tot complexul de funcii de

management la nivelul fiecrui proces business i sistemului business n ntregime. Procesele
de management au drept obiectiv pregtirea i adoptarea deciziilor administrative. Deciziile
administrative pot fi luate pentru ntrega organizaie, pentru un domeniu funcional separat
sau pentru procese separate, de exemplu:
management strategic;
proiectarea organizaional (struturizarea);
marketing;
administrare financiar-economic;
logistica i organizarea proceselor;
managementul calitii;
personalul.

Alt sistematizare posibil a funciilor de management este legat de noiunea ciclu de

management i se bazeaz pe cinci funcii iniiale ale managementului: planificare, organizare,
administrare, coordonare i control. Cea mai frecvent greeal este amestecarea acestor
principii.
Pentru realizarea descrierii procesuale este extrem de important ca orice activitate
managerial s se desfoare n conformitate cu ciclul managerial care include:
colectarea informaiei;
elaborarea deciziei;
realizarea;
evidena;
controlul;
analiza;
reglarea.
Cele mai frecvente variante de detalizare sunt:
colectarea informaiei;

determinarea coninutului informaiei colectate;

stabilirea formelor de raportare;
elaborarea soluiei;
analiza alternativelor;
pregtirea variantelor decizionale;
adoptarea deciziei;
elaborarea criteriilor de estimare;
realizarea;
planificarea;
organizarea;
motivarea;
stimularea;
coordonarea
controlul ndeplinirii;
evidena rezultatelor;
compararea conform criteriilor;
analiza;
analiza informaiilor suplimentare;
diagnoza posibilelor cauze de deviere;
reglare;
reglare la nivelul realizrii (ntoarcere la p. 3);
reglare la nivelul elaborrii deciziilor (ntoarcere la p. 1, 2).

Fiecare din etapele de mai sus are executori caracteristici proprii manageri, care pot fi
divizai n trei categorii principale:
conductor (responsabil de adoptarea i organizarea ndeplinirii deciziilor);
specialist-analitic (responsabil de pregtirea deciziei i analiza devierilor);
executor tehnic (colectarea informaiilor, evidena, comunicaiile).
Conform unor abordri recente, pentru procesul de management sunt evideniate dou tipuri
de procese, asociate la dou tipuri de management, convenional notate managementul
resurselor i managementul organizrii, care difer prin obiectul administrat, modelele de
baz i, ceea ce este important pentru descrierea proceselor ciclurile manageriale proprii. n
aa mod, modelul activitii ntreprinderii este cu dou nivele (fig. 5.3).

Fig. 5.3. Modelul pe dou nivele al activitii ntreprinderii

Din acest model rezult, c ciclurile de planificare a resurselor trebuie reglamentate, adic
managementul resurselor poate fi efectuat doar utiliznd regulamente organizaionale special
elaborate.
La baza ciclului de management al resurselor sunt puse calculele sau modelarea
imitaional i controlul rezultatelor:
alegerea (sau receptarea de la un sistem de nivel superior) a criteriului obiectiv
de estimare a calitii deciziei;
colectarea informaiilor privind resursele ntreprinderii sau posibilitilor mediului
exterior;
calculul variantelor (pentru diferite ipoteze privind posibilele valori ale
parametrilor);
alegerea variantei optimale adoptarea deciziei (= planului de resurse);
evidena rezultatelor (i raportarea);
compararea cu criteriul adoptat de estimare (=controlul rezultatelor);
analiza cauzelor devierilor i reglarea ( ntoarcere la 1, 2 sau 3).
La baza ciclului de management organizaional st modelarea structural sau procesual i
controlul procedural:
determinarea componenei lucrrilor (funciilor separate, operaiilor);
selectarea executorilor (- distribuirea zonelor i nivelelor de responsabilitate);

proiectarea procedurilor (succesiunea i ordinea de execuie);

coordonarea i aprobarea regulamentului de execuie (- a procesului, planului de

aciuni);
raportarea despre executare;
controlul executrii (-control procedural);
analiza cauzelor devierilor i reglarea ( ntoarcere la 1, 2 sau 3).
Astfel, la anumii pai ai decompoziiei ntreprinderea trebuie s determine care sunt etapele
ciclului de management ce vor fi realizate pentru fiecare din activitile de management
selectate anterior. Aceasta poate fi verificat folosind matricea-generator, care repartizeaz
componentele managementului pe etape ale ciclului managerial.

5.3.4.

Procesele de asigurare

Procese de asigurare sunt procesele destinate s asigure posibilitatea desfurrii

proceselor de baz i auxiliare i care sunt orientate spre susinerea mijloacelor universale ale
acestora. De exemplu, procesul de asigurare financiar, procesul de asigurare cu personal,
procesul de asigurare juridic sunt procese secundare. Ele creeaz i menin condiiile
necesare pentru ndeplinirea funciilor principale i funciilor de management. Clienii

proceselor auxiliare se afl n interiorul companiei.

La nivelul superior de detaliere pot fi evideniate urmtoarele procese auxiliare stadard:
asigurarea producerii;
asistena tehnic i reparaia echipamentelor;
asigurarea cu resurse energetice i termice;
deservirea i reparaia cldirilor i construciilor;
asigurarea tehnologic;
asigurarea metrologic;
securitatea muncii;
controlul ecologic;
asigurarea managementului;
asigurarea informaional;
asigurarea circulaiei documentelor;
asigurarea comunicaional;
asigurarea juridic;
asigurarea securitii;
asigurarea tehnico-material a managementului;
asigurarea gospodreasc;
asigurarea cu servicii comunale;
asigurarea cu transport etc.
Pentru fiecare dintre subprocesele evideniate mai sus trebuie de asemenea s se determine,
care proces de baz sau de managemnt este consumatorul acestor servicii interne. Pentru
aceasta din nou vor fi utilizate matricele-generatoare, care pot fi construite separat pentru
procesele de baz (fig. 5.4) i procesele de management (fig. 5.5).

Fig. 5.4. Matricea-generator simplificat a proceselor business auxiliare

Divizarea acestor procese are loc pe lanuri tehnologice individuale. Multe procese auxiliare
sunt de tip standard pentru toate companiile sau pentru anumite tipuri de activitate: industrie,
comer, prestri servicii .a. ns, de obicei, aceast clas de funcii ntr-o msur mai mic
poate fi descris prin fluxuri procesuale. Majoritatea poate fi reglementat cu ajutorul
instruciunilor.

Fig. 5.5. Matricea-generator a funciilor business auxiliare

5.3.5.

Modelul business de referin

Ca i cadru de baz, care aduce mpreun i organizeaz toate cunotinele despre modelul de
afaceri, poate fi folosit modelul de referin. Modelul de referin este un model business
procesual eficient, creat pentru companii dintr-o ramur specific, pus n aplicare n practic i
destinat utilizrii n dezvoltarea / restructurarea proceselor de afaceri n alte ntreprinderi. De
fapt, modelele de referin sunt scheme etalon de organizare a afacerilor, concepute pentru
procese de afaceri specifice, bazate pe experiena real de punere n aplicare n diverse
companii din ntreaga lume. Acestea includ proceduri i metode de organizare a
managementului, verificate n practic. Modele de referin permit companiilor s nceap
dezvoltarea propriilor modele pe baza unui set existent deja de funcii i procese.
Modelul de referin al procesului de afaceri include un set de funcii legate logic. Pentru
fiecare funcie este specificat un executor, documentele de intrare i de ieire sau obiectele
informaionale. Elementele (funciile i documentele) modelului de referin conin referine la
obiectele SI, precum i documente i alte informaii (manuale de utilizare, dezvoltatorii
responsabili), situate n depozitul proiectului. De aici i numele - modelul de referin (n
englez, reference model).

5.4.

Analiza activitii ntreprinderii

Studiul de analiz a activitii intreprinderii este o etap foarte important i determinant

pentru proiectarea SI. Durata studiului este de 1-2 sptmni. n acest rstimp analistul va
studia maximum 2-3 tipuri de activiti (serviciul de personal, contabilitatea, departamentul
transporturi, marketing etc.).
Culegerea informaiilor pentru construirea modelului business complet al organizaiei adesea
se reduce la studierea fluxurilor informaionale i funciilor documentate ale subdiviziunilor, de
asemenea poate fi utilizat interviul i sondajul.
La lansarea studiului organizaia prezint, de obicei, un set de documente cu urmtoarea
componen posibil:

1. Informaii sintetice despre activitatea ntreprinderii:

Informaii privind activitatea de management, economico2.

financiar, de producere.
Informaii privind politica de eviden i raportare.
Managementul documentelor:
Registrul informaiilor de intrare (tab. 5.1).

 Registrul informaiilor interne (tab. 5.2).

Registrul informaiilor de ieire (tab. 5.4).
3. Informaii privind infrastructura informaional.
4. Informaii privind persoanele responsabile.
(Denumirea
ntreprinderii)
N Denumirea i
r.
destinaia

Tabelul 5.1. Registrul informaiilor de intrare

Caracterul prelucrrii documentelor
(Denumirea subdiviiunii)
Cine
prelucreaz

De la cine a venit

Complexitat
ea

Periodicitatea,
regulamentul

Cum a fost
obinut

documentului
(Denumirea ntreprinderii)
N Denumirea i destinaia
r.
documentului

(Denumirea ntreprinderii)
N Denumirea i destinaia
r.
documentului

Tabelul 5.2. Registrul informaiilor de interne

(Denumirea subdiviziunii) Caracterul prelucrrii documentelor
Cine
Cui va fi
Complexitat
Periodicitatea,
Cum a fost
prelucreaz
transmis ea
regulamentul
obinut

(Denumirea subdiviziunii)
Cine
Destinat
prelucreaz
ar

Tabelul 5.3. Registrul informaiilor de ieire

Caracterul prelucrrii documentelor
Complexitat
Periodicitate Cum a fost
ea
a,
regulamentu obinut
l

Listele cu ntrebri pentru interviuri i sondaje sunt alctuite pentru fiecare departament
studiat i este aprobat de conductorul companiei. Aceasta se face cu scopul:
prevenirii accesului la informaii confideniale;
consolidrii nivelului de direcionare a studiului;
minimizrii distragerii angajailor de la ndeplinirea sarcinilor de baz.
Lista general a ntrebrilor (cu detalizarea ulterioar) include urmtoarele puncte:
obiectivele principale ale subdiviziunii;
informaia colectat i nregistrat;
modul de raportare;
interaciunea cu alte subdiviziuni.
Anchetele pentru conductori i specialiti pot conine urmtoarele ntrebri:
Care (din punctul de vedere al departamentului DVS) trebuie s fie obiectivele
crerii sistemului informaional integrat?
Structura organizaional a departamentului.
Obiectivele departamentului.
Succesivitatea aciunilor pentru ndeplinirea lucrrilor.
Care sunt tipurile de organizaii externe (bnci, clieni, furnizori etc.) cu care
interacioneaz departamentul i care sunt schimburile de informaii?
Care este materialul de referin folosit?
Ct timp cheltuii (n minute) pentru executarea operaiilor de baz?
Care sunt zilele cu ncrcare maxim (periodicitatea pentru o lun, semestru, an,
etc.)?
Asigurarea tehnic a departamentului (claculatoare, reea, modem, etc.).
Produsele program pentru automatizarea proceselor business.
Care sunt rapoartele i periodicitatea pregtirii lor pentru conducere?
Specialitii cheie ai departamentului, care pot rspunde la orice ntrebare legat
de procesele business.
Caracteristicile obiectelor distribuite geografic.
Managementul documentelor la locul de lucru.
Datele colectate n aa mod, de obicei, nu acoper toate domeniile relevante de activitate
organizaional i posed un nivel nalt de subiectivism. Dar cel mai important este faptul, c

studiile de acest gen nu identific factorii stabili, legai de particularitile specifice ale
ntreprinderii, care pot fi influenai excluisv prin metode de ajustare funcional a sistemului
organizaional.
Analiza sondajelor conductorilor organizaiilor studiate arat, c punctul lor de vedere
referitor la structura organizaiei, obiectivele generale i locale ale funcionrii, obiectivele i
funciile departamentelor, ierarhia lucrtorilor adesea au un caracter contradictoriu. n plus,
aceste puncte de vedere difer de scopurile i normele declarate oficial sau contravin
activitilor efective.
Structura fluxurilor informaionale poate fi stabilit folosind formularele documentelor i
configuraia reelelor de calculatoare i a bazelor de date. ns structura microproceselor reale,
executate de personal n contactele informaionale (n mare parte nedocumentate) rmne
necunoscut. Rspunsuri la aceste ntrebri poate oferi o diagnosticare structuralfuncional, bazat pe metodele de fotografiere continu (sau eantionat), a timpului de
lucru a personalului. Scopul diagnosticrii const n obinerea unor cunotine de ncredere
despre organizaie i relaiile organizaionale ale elementelor sale funcionale. n acest sens,
cea mai important sarcin de diagnosticare funcional a structurilor organizatorice sunt:
clasificarea subiecilor funcionrii (categorii i grupuri de lucrtori);
clasificarea elementelor procesului de funcionare (aciuni, proceduri);
clasificarea direciilor (problemelor soluionate), obiectivelor funcionrii;
clasificarea elementelor fluxurilor informaionale;
cercetarea activitii personalului organizaiei;
studierea repartizrii (n timp i frecven) a caracteristicilor organizaionale:
proceduri, contacte, direcii de activitate, elemente ale fluxurilor informaionale
individual i n combinaie pentru categorii de lucrtori, tipuri de proceduri i direciile
lor (conform rezultatelor i logicii studiului);
identificarea structurii reale a relaiilor funcionale, informaionale, ierarhice,
temporale ntre conductori, colaboratori i departamente;
stabilirea structurii repartizrii timpului de lucru al conductorilor i personalului
conform funciilor, problemelor i obiectivelor organizaiei;
identificarea tehnologiilor-cheie de funcionare (proceselor informaionale,
inclusive i nedocumentate), stabilirea obiectivelor lor, n comparaie cu obiectivele
declarate ale organizaiei;
identificarea grupurilor omogene de lucrtori, conform specificului activitii,
obiectivelor i subordonrii reale, formarea modelului real al structurii organizaionale i
compararea cu structura declaratr;
determinarea cauzelor de necoinciden a structurilor relaiilor organizaionale
declarate i reale.
O fotografiere continu a timpului de lucru se numete observarea permanent i
nregistrarea caracteristicilor lucrtorilor n procesul fiuncionrii pe toat durata
zilei de lucru. Pe tot parcursul acestor activiti parametrii selectai sunt introdui nr-un tabel
pregtit din timp. Prezentm mai jos forma tabelului de lucru al analistului de sistem.

Imediat dup finalizarea procedurii de cercetare tabelul este completat cu caracteristici

suplimentare: ramura tehnologic, funcie de sistem, obiectul, aspectul, fonul emoional .a. O
parte a indicatorilor (notai cu stelu) vor fi completai n procesul studiului, restul dup.
Coninutul nregistrrilor va include:
numrul de ordine;

agentul (funcia lucrtorului studiat);

timpul ct a durat procedura;
procedura (denumirea setului de aciuni elementare, reunite prin obiectivul

problemei particulare soluionate;

coninutul (esena procedurii, care trebuie clasificat);
informaia (direcia de transmitere a informaiei ntre agent i contragent);

iniiativa (iniiatorul nceperii procedurii);

contragent (funcia lucrtorului care se afl n contact cu agentul);
relaia (de subordonare, forma de interaciune ntre agent i contragent) ;
problema (caracteristica verbal a problemei soluionate).

5.5.

Rezultatele etapei de analiz

Rezultatul etapei de cercetare va fi documentul Raport despre studiul expres al activitii

ntreprinderii, structura cruia este prezentat mai jos.

1. Descrierea succint schematic a proceselor business:

managementul achiziiilor i a rezervelor;
managementul producerii;
managementul vnzrilor;
managementul resurselor financiare.
2. Cerinele de baz i prioritile automatizrii.
3. Estimarea resurselor clientului, necesare pentru asigurarea proiectului.
4. Evaluarea posibilitii automatizrii, propuneri privind crearea sistemului
automatizat cu estimarea aproximativ a termenilor i costurilor.
Documentele, care fac parte din raport pot fi prezentate n form textual sau tabele, forma
aproximativ a crora este adus mai jos.
Nr.
crt
1.
2.
3.
4.
5.
6.
7.

Denumirea procesului
business
Vnzri: n reea, engros
Planul de achiziii
Plasare comenzii de
producere
Producere proprie
Achiziii de materii prime
Pli
Alte

Formular posbil pentru descrierea operaiilor procesului business:

Execut
or

Operai
e

Frecven
a

Documente de intrare
(documente
justificative)

Document de ieire (document creat)

Formular posbil pentru descrierea documentelor procesului business:

Document creat (document

Operai

la ieire)

Cine creeaz
(executorul)

Frecven
a

Documente justificative
(documente la intrare)

Cercetare preproiect permite soluionarea urmtoarelor probleme:

stabilirea prealabil a cerinelor sistemului nou;
determinarea structurii organizaiei;

identificarea listei funciilor-obiectiv;

analiza distribuirii funciilor pe departamente i colaboratori;
identificarea interaciunilor funcionale ntre departamente, fluxurilor

informaionale n i ntre subdiviziuni, influenelor informaionale externe ;

analiza mijloacelor de automatizare existente.
Informaiile, obinute n rezultatul cercetrilor preproiect, vor fi analizate folosind metodele
analizei structurale i/sau obiectuale i vor fi utilizate pentru construirea modelului activitii
organizaiei. Modelul organizaiei presupune construirea a dou tipuri de modele:
modelul cum este (as is), care reflect situaia existent n organizaie la
momentul cercetrii, permite nelegerea modului de funcionare a organizaiei date,
identificarea locurilor nguste cu formularea propunerilor privind perfecionrile
posibile;
modelul cum trebuie s fie (to be), care reflect modul de lucru cu utilizarea
tehnologiilor noi. Fiecare din cele dou modele include modele funcional i
informaional complete, ca i modelul care descrie dinamica comportamentului
organizaiei (la necessitate).

ntrebri de control
1. Definii noiunea Procese de management

,

-
,
-
,

.

2.
3.
4.
5.

Kjkjk
Lknlkn
Kjnln
knln

Kljk
kb
2. -
,
-
,
,
3.
,
,


,
4.
?


5. ?



6. ,

-?



7.

?
""

8.
?



9. ?

6. Metodologia modelrii domeniului obiectiv

Metodologii pentru modelarea domeniului obiectiv. Modelul structural al domeniului obiectiv. Structura
obiectual. Structura funcional. Structura conducerii. Structura organizaional. Metodologii orientate
funcional i orientate obiect de descriere a domeniului obiectiv. Metoda funcional IDEF. Metoda
funcional a fluxurilor de date. Metoda obiect-orientat. Compararea metodelor existente. Metoda
sintetic.

6.1.

Modelul structural al domeniului obiectiv

La baza proiectrii sistemelor informaionale st modelarea domeniului obiectiv. Pentru a

realiza un proiect al unui SI adecvat domeniului obiectiv (sub forma unor programe, care
lucreaz corect) este necesar s avem o imagine integr, sistemic a modelului, care
reflect toate aspectele funcionrii noului sistem informaional. n acest caz, prin noiunea de
model al domeniului obiectiv vom considera sistemul, care imit structura sau

funcionarea domeniului obiectiv cercetat i care respect cerina de baz corespunde

acestui domeniu.
Modelarea prealabil a domeniului obiectiv permite s fie diminuate timpul i termenele de
efectuare a lucrrilor de proiectare i s fie obinut un proiect mai efectiv i mai calitativ. Fr
modelarea domeniului obiectiv este mare probabilitatea erorilor, care pot s apar la
soluionarea problemelor strategice, erori ce vor conduce la pierderi i cheltuieli suplimentare.
Reieind din aceste considerente, metodologiile de proiectare moderne sunt bazate pe
tehnologia modelrii domeniului obiectiv.
Modelul domeniului obiectiv va respecta urmtoarele cerine:
formalizarea, care asigur descrierea univoc a structurii domeniului obiectiv;
comprehensibiltate pentru clieni i dezvoltatori bazat pe utilizarea unor
instrumente grafice de vizualizare a modelului;
realizabilitate, care presupune existena mijloacelor de realizare fizic a
modelului;
posibilitatea de evaluare a eficacitii realizrii modelului domeniului obiectiv n
baza unor metode acceptate i indicatori calculabili.
Pentru realizarea acestor cerine, de regul, este construit un sistem de modele, care reflect
aspectele structural i estimativ ale funcionrii domeniului obiectiv.
Aspectul structural presupune construirea:
structurii obiectuale, care reflect componena obiectelor materiale i
informaionale ale domeniului obiectiv, ce interacioneaz n cadrul proceselor;
structurii funcionale, care pune n eviden legturile reciproce ale funciilor
(aciunilor) atunci cnd obiectele sunt transformate;
structurii managementului, care reflect interaciunea unitilor organizaionale
ale ntreprinderii i a personalului;
structurii tehnice, care descrie topologia plasrii componentelor fizice i
modalitile de comunicare ntre ele.
Pentru reflectarea aspectului structural al modelului domeniului obiectiv sunt utilizate metode
grafice, care trebuie s garanteze prezentarea informaiilor despre componentele sistemului.
Cerina principal referitor la metodele grafice de documentare este simplitatea. Metodele
grafice trebuie s asigure posibilitatea decompoziiei structurale a specificaiilor sistemului cu
un grad maxim de detalizare i coordonarea descrierilor pentru nivele adiacente de
decompoziie.
Direct de modelare este legat problema alegerii limbajului de prezentare a soluiilor de
proiect, care s permit atragerea unui numr ct mai mare de viitori utilzatori la elaborarea
soluiei. Limbajul de modelare este notaia, de obicei grafic, care este utilizat pentru
descrierea proiectului. Notaia este setul de obiecte grafice, utilizate n model. Limbajul de
modelare, pe de o parte trebuie s fac soluiile proiectanilor nelese utlizatorului, iar pe de
alt parte, s pun la dispoziia proiectanilor mijloace suficient de formalizate i univoce
pentru identificarea soluiilor de proiect, care vor fi realizate sub forma unor seturi de
programe.
Imaginea grafic este adesea forma cea mai cuprinztoare de prezentare. Totui, proiectanii
ar trebui s fie contieni de faptul c metodele grafice nu ntotdeauna asigur succesul total
pentru o soluie de proiect de la enunul problemei pn la programe de calculator. Dificulti
pot s apar la trecerea de la etapa de analiz a sistemului la faza de proiectare, i n special
la programare.
Criteriul principal de adecvan a modelului structural al domeniului obiectiv este
completitudinea funcional a sistemului informaional elaborat.
Aspectele estimative ale modelrii domeniului obiectiv sunt legate de indicatorii de
eficacitate a proceselor automatizate, la care pot fi plasai:
timpul de soluionare a problemelor;

 preurile de cost pentru procesarea datelor;

fiabilitatea proceselor;
indicatori indireci de eficien, cum sunt volumul produciei, productivitatea
muncii, rulajul capitalului, rentabiltatea etc.
Pentru calcularea indicatorilor de eficacitate sunt utilizate, de obicei, metodele statice ale
analizei funcii-cost i metodele modelrii imitaionale.
La baza metodologiilor modelrii domeniului obiectiv al SI se afl principiile detalizrii
succesive a categoriilor abstracte. De obicei, modelele sunt construite pe trei nivele: extern
(determinarea cerinelor), conceptual (specificarea cerinelor) i intern (realizarea cerinelor).
La nivelul extern modelul rspunde la ntrebarea ce trebuie s fac sistemul, adic este
stabilit lista componentelor principale ale sistemului: obiecte, funcii, evenimente, untiti
organizaionale, mijloace tehnice. La nivelul conceptual modelul rspunde la ntrebarea cum
trebuie s funcioneze sistemul? Cu alte cuvinte, la acest nivel este determinat caracterul
interaciunii componentelor sistemului. La nivelul intern modelul rspunde la ntrebarea: care

sunt mijloacele tehnice i logice necesare pentru realizarea cerinelor sistemului ? De pe

poziiile ciclului de via a sistemului informaional nivelele descrise ale modelului sunt
construite respectiv la etapele de analiz a cerinelor, proiectrii logice (tehnice) i proiectrii
fizice. Vom analiza particularitile construirii modelului domeniului obiectiv pentru cele trei
nivele de detalizare.

6.1.1.

Structura obiectual

Obiectul este entitatea utilizat la executarea unei funcii sau operaii (transformare,
procesare, formare etc.). Obiectele pot fi statice sau dinamice: obiectele dinamice sunt
utilizate ntr-un singur ciclu de reproducere, de exemplu comenzile de produse, bonuri de
plat, pli. Obiectele statice sunt utilizate n mai multe cicluri de reproducere, de exemplu
echipamentele, personalul, rezervele materiale.
La nivelul extern de detalizare a modelului sunt evideniate tipurile principale de obiecte
materiale (de exemplu, materia prim, semifabricatele, produsele finite, serviciile) i
informaionale sau documente (de exemplu, comenzile, bonurile de trsur, conturile etc.).
La nivelul conceptual sunt specificate clasele de obiecte, determinate atributele i legturile
lor; are loc crearea unei imagini generale a structurii domeniului obiectiv.
La nivel intern modelul conceptual este reflectat sub form de fiiere ale bazei de date,
documente de intrare i ieire ale sistemului. Obiectele dinamice vor fi reprezentate prin
uniti de informaii variabile sau documente, iar obiectele statice prin uniti de informaii
convenional constante sub form de liste, nomenclatoare, liste de preuri, dicionare,
clasificatoare. Modelul bazei de date, n calitate de resurs informaional meninut
constant, reflect pstrarea informaiilor convenional-constante i informaiilor variabile
cumulate, utilizate n procesele informaionale repetitive.

6.1.2.

Structura funcional

Funcia (operaia) este convertorul intrrilor n ieiri. O secvena de funcii, legate reciproc pe
intrri i ieiri, se numete proces business. O funcie a procesului business poate genera
obiecte de orice natur (materiale, informaionale, financiare). Procesele business i procesele
informaionale, de regul, sunt inseparabile, adic funciile unui proces material nu pot fi
efectuate fr suport informaional. De exemplu, recepia produciei finite are loc n baza
documentului Ordin, care, la rndul su, genereaz documentul nsoitor Factur.
Funcia poate fi prezentat printr-o singur aciune sau o secven de aciuni. n ultimul caz
fiecrei funcii i poate corespunde un proces oarecare, care poate avea subprocese, .a.m.d.,
pn la momentul n care fiecare subfuncie va reprezenta o secven nedecompozabil de
aciuni.
La nivelul extern al modelrii este determinat lista funciilor business principale sau
tipurilor de procese business. De obicei funcii de acest tip sunt n jur de 15 20.

La nivelul conceptual funciile selectate sunt descompuse i sunt construite ierarhii de

funcii interdependente.
La nivelul intern structura procesului informaional este reflectat n calculator: sunt
stabilite structurile ierarhice ale modulelor program, care realizeaz funciile automatizate.

6.1.3.

Structura managementului

n setul de funcii ale procesului business sunt posibile secvene alternative sau ciclice n
dependen de condiiile n care are loc procesul. Aceste condiii sunt legate de evenimentele,
care au loc n mediul extern sau n interiorul proceselor, ca i de anumite stri ale obiectului
(de exemplu, comanda a fost acceptat, refuzat, transmis pentru introducerea unor
corectri). Evenimentele genereaz execuia funciilor, care, la rndul lor, modific starea
obiectelor i genereaz noi evenimente, .a.m.d., pn a ncheierea procesului business. n
acest caz vom spune, c secvena de evenimente reprezint o realizare concret a procesului
business.
Fiecare eveniment este descris din dou puncte de vedere: informaional i procedural. Un
eveniment informaional este prezent sub forma unui mesaj, care fixeaz faptul ndeplinirii
unei funcii de modificare a strii sau apariia unei stri noi. Un eveniment procedural
lanseaz execuia unei funcii noi, din aceast cauz pentru fiecare stare a obiectului trebuie
s fie specificat apelul acestei funcii. Evenimentele au rolul de legtur n execuia funciilor
proceselor business.
La nivelul extern este determinat lista evenimentelor externe, generate de interciunea
ntreprinderii cu mediul extern (plata impozitelor, procentelor pentru credite, contractelor
etc.), i lista indicaiilor-obiective (consecin a obiectivelor organizaiei), crora trebuie s
corespund procesele business (regulamentul de ndeplinire a proceselor, meninerea
nivelului necesar al rezervelor materiale, nivelul calitii produciei etc.).
La nivelul conceptual sunt stabilite regulile business, care determin condiiile de apelare a
funciilor la producerea unui eveniment sau trecerea procesului ntr-o stare anume.
La nivelul intern are loc formalizarea regulilor business sub form de triggere sau apelri ale
modulelor program.

6.1.4.

Structura organizaional

Prezint un set de uniti organizaionale, de regul, legate prin relaii ierarhice i procesuale.
Unitatea organizaional este subdiviziunea, care reprezint o reuniune de oameni (personal)
pentru ndeplinirea inui set de funcii comune sau procese business. ntr-o structur
organizaional funcional-orientat unitatea organizaional execut un set de funcii, care
fac parte dintr-un singur tip de procese i care au atribuie pentru diferite funcii de
management.
La nivelul extern este construit modelul structural al ntreprinderii sub form de ierarhie de
subordonare a unitilor organizaionale sau liste de subdiviziuni care interacioneaz.
La nivelul conceptual pentru fiecare subdiviziune este stabilit structura organizaional a
statelor (funciilor, rolurilor personalului).
La nivelul intern sunt stabilite cerinele referitoare la drepturile personalului de accesare a
funciilor automatizate ale SI.

6.1.5.

Structura tehnic

Topologia determin plasarea teritorial a resurselor tehnice n cadrul subdiviziunilor

ntreprinderii, iar comunicaiile modul tehnic de realizare a interaciunii subdiviziunilor
structurale.

La nivelul extern al modelului sunt determinate categoriile mijloacelor tehnice de prelucrare

a datelor i distribuirea lor pe subdiviziuni structurale.
La nivelul conceptual sunt identificate modalitile de organizare a comunicaiilor ntre
resursele tehnice ale subdiviziunilor structurale: deplasarea fizic a documentelor, suporilor
de memorie, schimbul de informaii prin canale de comunicaii etc.
La nivelul intern este construit modelul arhitecturii client-server al reelei de
calculatoare.

6.1.6.

Modele de integrare

Modelele descrise ale domeniului obiectiv sunt utilizate pentru proiectarea unor componente
separate ale SI: date, module program funcionale, module program de gestiune, interfee ale
utilizatorilor, structuri ale complexului tehnic. Pentru o proiectare calitativ a SI este necesar
s fie construite modele, care s integreze componentele. n cel mai simplu caz n calitate de
asemenea modele de interaciune pot fi utilizate matricele referinelor ncruciate: obiectefuncii, funcii-evenimente, uniti organizaionale-funcii, uniti organizaionaleobiecte, uniti organizaionale-mijloace tehnice .a.m.d. ns aceste matrice sunt greu de
neles i nu reflect particularitile realizrii interaciunilor.
O reflectare corect a interaciunilor componentelor SI este posibil prin modelarea
concomitent a componentelor, n special din punctul de vedere al obiectelor i funciilor.
Metodologia analizei structurale de sistem ajut semnificativ n rezolvarea acestor probleme.
Analiza structural este metoda de cercetare a sistemului, care ncepe cu o imagine de
ansamblu, iar apoi are loc detalierea printr-o structur ierarhic cu un numr tot mai mare de
niveluri. Pentru aceste metode este caracteristic:
divizarea pe nivele de abstractizare cu un numr limitat de elemente (de la 3 la
7);
un context limitat, care include doar detaliile eseniale ale fiecrui nivel;
utilizarea unor reguli formale stricte de notare;
apropiere succesiv de rezultat.
Analiza structural se bazeaz pe dou principii fundamentale - "dezbin si cucereste" i
principiul ordonrii ierarhice. Soluionarea problemelor dificile prin divizarea lor n mai multe
sarcini independente mici (aa-numitele "cutii negre") i organizarea acestor sarcini n
structuri arborescente ierarhice sporesc n mod semnificativ nivelul de nelegere a sistemelor
complexe. Mai jos sunt prezentate definiiile unor noiuni-cheie din domeniul analizei
structurale.
Operaie aciune elementar (indivizibil), excutat la un singur loc de lucru.
Funcie set de operaii, grupate n dependen de anumii indicatori.
Proces business set de funcii legate, n cadrul execuiei cruia sunt utilizate anumite
resurse i este creat un produs (obiect, serviciu, descoperire tiinific, idee), care prezint
valoare pentru consumator.
Subproces proces business element structural al unui oarecare proces business i care
prezint valoare pentru consumator.
Model business descriere grafic structurat a unei reele de procese i operaii, legate de
date, documente, uniti organizaionale i alte obiecte, care reflect activitatea existent sau
presupus a companiei.
Exist diferite metodologii de modelare structural a domeniului obiectiv, printre care trebuie
de evideniat metodologiile orientate pe funcii i orientate pe obiecte .

6.2.

Metodologii de modelare structural a domeniului

obiectiv
Procesul modelrii poate fi realizat n cadrul unor metode, care difer n primul rnd prin
modul de abordare a organizaiei modelate. n conformitate cu acest criteriu exist metode
funcionale (structurale) i metode obiect orientate.
n cadrul metodelor obiect-orientate organizaia modelat este considerat set de obiecte,
care interacioneaz uniti de producie. Obiectul este definit ca model informaional al
unei entiti din lumea real, care are proprieti i comportament specific. Scopul utilizrii
unei metode obiect orientate este identificarea obiectelor, care formeaz organizaia i
repartizarea ntre obiecte a responsabilitilor pentru aciunile executate n cadrul
organizaiei.

Metodele funcionale , dintre care cea mai cunoscut este metoda IDEF, consider organizaia
ca set de funcii , care transform fluxul de informaii la intrare n flux de ieire. Procesul de
transformare a informaiei consum anumite resurse. Diferena principal de la metoda
orientat pe obiecte const n separarea distinct a funciilor (metodele de prelucrare a
datelor) de datele propriu-zise.

Fiecare abordare are avantajele sale. Abordarea obiectual permite construirea unor sisteme
mai stabile la modificri, corespunde mai bine structurilor existente n organizaie. Modelarea
funcional se manifest mai bine atunci cnd structura organizaional este n proces de
modificare sau, n genere, este slab conturat. Abordarea care pleac de la funciile
ndeplinite este la nivel intuitiv mai bine neleas de executori ceea ce faciliteaz procesul
obinerii informaiilor necesare pentru analiz i stabilirea cerinelor.

6.2.1.

Metoda IDEF0

Formalizeaz dezvoltarea limbajului grafic pentru descrierea sistemelor funcionale SADT

(Structured Analysis and Design Technique). IDEF n calitate de standard a aprut n anul 1981
n cadrul unui program extins consacrat automatizrii ntreprinderilor industriale, numit ICAM
(Integrated Computer Aided Manufacturing). Familia stadardelor IDEF a motenit denumirea
chiar de la numele acestui program Icam DEFinition. Ultima redacie a fost publicat n
decembrie 1993 de Institutul Naional pentru Standarde al SUA (NIST).
Obiectivul este constrirea schemei funcionale a sistemului cercetat, schem care descrie
toate procesele relevante cu exactiatea suficient pentru modelarea univoc a activitii
sistemului.
La baza metodologiei se afl patru noiuni fundamentale: blocul funcional, arcul de
interfa, decompoziia i glosarul.
Blocul funcional (Activity Box) reprezint o funcie concret a sistemului cercetat. Conform
cerinelor standardului denumirea fiecrui bloc funcional trebuie s fie formulat n form de
verb (de exemplu, presteaz servicii). n cadrul unei diagrame blocul funcional este
reprezentat printr-un dreptunghi (fig. 6.1). Fiecare din cele patru laturi ale dreptunghiului are
un rol bine definit, inclusiv:
latura orizontal de sus are valoarea Gestiune (eng. Control);
latura vertical din stnga are valoarea Intrare (Input);
latura vertical din dreapta are valoarea Ieire (Output);
latura orizontal de jos are valoarea Mecanism (Mechanism).

Fig. 6.1. Blocul funcional

Arcul de interfa (Arrow) indic elementul sistemului, care este prelucrat de ctre blocul
funcional sau influeneaz funcia, reprezentat de acest bloc. Arcele de interfa sunt
numite frecvent fluxuri sau sgei.
Cu ajutorul arcelor de interfa sunt reprezentate diferite obiecte, care ntr-un mod sau altul
determin procesele, ce au loc n sistem. Astfel de obiecte pot fi elementele lumii reale
(detalii, vagoane, colaboratori etc.) sau fluxuril de date i informaii (documente, date,
instruciuni etc.).
n dependen de latura blocului funcional la care vine arcul el se va numi de intrare, de
ieire sau de control.
Conform standardului, orice bloc funcional trebuie s posede minimum un arc de control i un
arc de ieire un proces are loc conform anumitor reguli (arcul de control) i trebuie s
genereze obligator un rezultat (o ieire). n caz contrar blocul nu are sens.
Prezena obligatorie a arcelor de control este una din diferenele principale ale standardului
IDEF0 de metodologiile din clasa DFD (Data Flow Diagram) i WFD (Work Flow Diagram).
Decompoziia (Decomposition) este noiunea central (de baz) a standardului IDEF0.

Principiul decompoziiei este utilizat la divizarea unui proces complex n funcii componente.
Nivelul de detaliere este determinat de creatorul modelului.
Decompoziia permite prezentarea gradual structurat a modelului sistemului sub form de
structur ierarhic a unor diagrame separate, ceea ce face diagrama mai puin ncrcat i
mai uor de neles i de manipulat.
Pentru fiecare element al IDEF0 diagrame, blocuri funcionale, arce de interfa standardul
presupune crearea i ntreinerea unui set de definiii, cuvinte-cheie, rezumate narative etc.,
care caraterizeaz obiectul desemnat de elementul n cauz. Acest set de definiii se numete
glosar i descrie elementul dat. Glosarul completeaz limbajul grafic, asistnd diagramele cu
detalii suplimentare.
Un model IDEF0 ncepe cu prezentarea sistemului ca un tot ntreg un bloc funcional cu
arcele de interfa, care se extind dincolo de domeniul studiat. Aceast diagram cu un singur
bloc funcional se numete diagrama de context.
n textul explicativ al diagramei de context trebuie s fie indicat obiectivul (Purpose)
construirii diagramei sub form de descriere succint i fixat punctul de vedere (Viewpoint).
Determinarea i formalizarea obiectivului construirii modelului IDEF este un moment extrem
de important. De facto, obiectivul stabilete domeniile sistemului studiat asupra crora
trebuie focalizat atenia n primul rnd.
Punctul de vedere determin direciile principale de dezvoltare a modelului i nivelul
necesar de detalizare. Fixarea clar a punctului de vedere permite descrcarea modelului,
refuznd la detalizarea i cercetarea unor elemente separate, care nu sunt necesare reieind
din punctul de vedere ales. Alegerea corect a punctului de vedere reduce cheltuielile
temporale pentru construirea modelului final.

n procesul decompoziiei blocul funcional, care n diagrama de context reprezint sistemul

ca un tot ntreg, va fi supus (ntr-o alt diagram) detalizrii. Diagrama obinut, de nivelul 2,
include blocurile funcionale, ce reflect subfunciile principale ale blocului funcional din
diagrama de context, i se numete diagram-fiu (Child Diagram) n relaia cu diagrama de
context. Fiecare dintre blocurile funcionale, care aparin diagramei-fiu, se numete bloc-fiu
Child Box, respectiv blocul funcional predecesor se numete bloc printe (Parent Box), iar
diagrama la care acesta aparine diagram printe (Parent Diagram). Fiecare subfuncie a
diagramei fiu poate fi n continuare detalizat prin decompoziia analogic a blocul su. n
fiecare caz de decompoziie a blocului funcional toate arcele de interfa (care intr i care
ies) sunt fixate pe diagrama fiu. Prin aceasta se atinge integritatea structural a modelului
IDEF0.
n unele cazuri arcele de la un nivel superior nu are sens s fie luate n consideraie n
diagramele de nivel inferior sau invers arce de la un nivel inferior pot s nu fie reflectate n
diagramele de nivel mai nalt. Aceasta doar ar suprancrca diagramele i le-ar face mai
complicate pentru percepie. Pentru soluionarea unor probleme de acest gen n standardul
IDEF0 a fot introdus noiunea tunelare. Notaia tunel (Arrow Tunnel) sub form de dou
parateze rotunde n jurul nceputului arcului de intrefa semnific, c acest arc nu a fost
motenit de la blocul funcional printesc i a aprut (din tunel) doar n aceast diagram.
Aceeai notaie n jurul sfritului unui arc (sgeata) n imediata vecintate de blocul de
recepie semnific faptul, c n digarama-fiu a acestui bloc acest arc nu va fi luat n
consideraie (nu va fi prezent). Cel mai frecvent are loc situaia n care unele obiecte i arcele
respective ale lor nu sunt luate n consideraie la unele nivele intermediare. Se spune n
aceste cazuri, c obiectele mai nti intr n tunel, iar apoi, la necesitate se ntorc din
tunel.
De obicei modelele IDEF0 conin informaii complexe i concentrate. Pentru a limita
suprancrcarea lor i a pstra comoditatea folosirii, standardul ofer posibilitatea limitri
complexitii.
Se recomand ca o diagram s includ de la 3 pn la 6 blocuri funcionale, iar numrul de
arce de intrare la un bloc funcional, ca i de ieire dintr-un bloc funcional, s nu depeasc
4.
Standardul IDEF0 conine un set de proceduri, care permit elaborarea i coordonarea
modelului de grupuri mari de oameni, din diferite domenii de activitate a sistemului modelat.
Procesul de elaborare este iterativ i include urmtoarele etape:
Crearea modelului de un grup de specialiti din diferite domenii de activitate a
companiei. Ascest grup, n terminologia IDEF0, se numete Autori (Authors).
Construirea modelului de nceput este un proces dinamic n cadrul cruia autorii
chestioneaz persoanele competente referitor la structura diferitor procese, elabornd
modele ale activitii subdiviziunilor. n cadrul acestui proces vor fi cutate rspunsuri
la urmtoarele ntrebri:
Ce avem la intarea unei subdiviziuni?
o Care sunt funciile i n ce ordine ele sunt executate n cadrul
subdiviziunii?
o
o

Cine este responsabil de executarea unei funcii anume?

Care este rezultatul activitii subdiviziunii (ieirea)?

n baza documentelor existente i n rezultatul chestionrii este creat draftul modelului

(Model Draft)
Difuzarea draftului modelului pentru informare, coordonare i comentare. La
aceast etap are loc discutarea proiectului modelului de mai multe persoane
competente (n termeni IDEF0 cititori). Fiecare diagram este comentat n scris,
dup care este ntoars autorului. Autorul, de asemenea n scris, accept sau nu
critica, motivnd neacceptarea, i ntoarce maculatorul corectat pentru discuii
ulterioare. Acest ciclu continu pn la momentul n care autorii i cititorii ajung la

consens.
Aprobarea oficial a modelului este responsabilitatea conductorului grupului
de lucru i are loc n momentul atingerii consensului. Modelul final reprezint o imagine
coordonat privind ntreprinderea (sistemul) din punctul de vedere ales i obiectivul
stabilit.
Simplitatea limbajului grafic IDEF0 sporete lizibilitatea modelului, incluisv pentru persoane
fr o pragtire anterioar special i care nu au participat la elaborarea modelului.
Instrumentele IDEF0 sunt utlie i pentru demonstraii i prezentri. n baza modelului elaborat
pot fi organizate proiecte noi, focalizate pe modificarea controlat a modelului.

6.2.2.

Metoda fluxurilor de date

Obiectivul acestei metode este construirea modelului sistemului studiat sub form de
diagram a fluxurilor de date (Data Flow Diagram DFD), care asigur descrierea corect a
ieirilor (reacia sistemului n form de date) pentru intrri cunoscute (semnale la intrare prin
interefeele externe). Diagramele fluxurilor de date sunt instrumentul principal de modelare a
cerinelor funcionale ale sistemului proiectat.
La crearea diagramei fluxurilor de date sunt utuilizate urmtoarele noiuni principale: fluxuri
de date, procese (activiti) de transformare a fluxurilor de intrare n ieiri, entiti
externe i depozite de date (repozitorii).
Fluxurile de date sunt abstracii, utilizate pentru modelarea transferului de informaii (sau a
componentelor fizice) dintr-o parte a sistemului n alta. Pe o diagram fluxurile sunt
reprezentate de sgei, care au nume, iar orientarea lor indic direcia de deplasare a
informaiei.
Destinaia procesului (activitii) const n producerea fluxurilor de ieire din fluxurile de
intrare n conformitate cu aciunea, indicat de numele procesului. Numele unui proces
trebuie s fie un verb n forma indefinit urmat de un complement (de exemplu, recepionare
documente de livrare a produciei). Fiecare proces are un numr unic pentru a putea fi referit
n interiorul diagramei. Acest numr poate fi utilizat mpreun cu numrul diagramei pentru a
obine indicile unic al procesului n cadrul ntregului model.
Depozitul de date (repozitoriul) permite desemnarea datelor pentru sectoarele indicate,
care vor fi pstrate n memorie ntre procese. De facto, depozitul prezint seciuni
temporale ale fluxurilor. Informaia care se conine n depozit poate fi utilizat la orice
moment de timp dup culegere, datele pot fi luate din depozit n ordine arbitrar. Numele
unui depozit trebuie s corespund coninutului lui i s fie un substantiv.
Entitatea extern este un obiect material din afara contextului sistemului, care este surs
pentru sau receptor al datelor sistemului. Numele entitii externe trebuie s conin un
substantiv, de exemplu, depozit de mrfuri. Obiectele, reprezentate prin entiti externe, nu
vor participa n prelucrri de date.
n afara elementelor principale n DFD intr dicionarele de date i minispecifaciile procesrii.
Dicionarele de date sunt cataloage ale tuturor elementelor de date, prezente n DFD, inclusiv
fluxurile de date de grup sau individuale, depozitele i procesele, ca i toate atributele lor.
Minispecificaiile procesrii descriu procesele DFD de nivel inferior. De facto,
minipecificaiile reprezint algoritmii de descriere a activitilor, ndeplinite de procese:
mulimea tuturor minispecificaiilor formeaz specificaia total a sistemului.
Procesul de construire a unei DFD ncepe cu crearea diagramei principale de tip stea n care
este prezentat procesul modelat i toate entitile externe, cu care procesul interacioneaz.
Dac procesul principal este complicat el poate fi prezentat din start descompus ntr-o serie
de procese, care interacioneaz. Criterii de complexitate pot fi: existena unui numr mare
de entiti externe, multifuncionalitatea sau caracterul distribuit al sistemului. Entitile
externe vor fi evideniate pentru procesul principal. Pentru determinarea lor vor fi evideniai
furnizorii i consumatorii procesului principal, adic toate obiectele care interaioneaz cu

procesul principal. La aceast etap descrierea interaciunii const n alegerea unui verb, care
s reprezinte modul n care entitatea extern utilizeaz pe sau este utilizat de procesul
principal. De exemplu, pentru procesul principal evidena petiiilor cetenilor, entitatea
extern este cetean, descrierea interaciunii - depune petiie i primete rspuns.
Aceast etap este una important principial fiindc anume aici sunt stabilite graniele
sistemului modelat.
Pentru fiecare entitate extern este construit tabelul evenimentelor, care descrie
interaciunea entitii cu procesul principal. Tabelul evenimentelor include denumirea entitii
externe, evenimentul, tipul lui (ordinar/tipic pentru sistem sai excepional, adic realizat n
condiii speciale) i reacia sistemului.
La pasul urmtor are loc decompoziia procesului principal ntr-un set de procese
interconectate, care fac schimb de date. Fluxurile nu sunt concretizate, este determinat doar
caracterul interaciunii lor. Decompoziia este finalizat n momentul n care procesul devine
simplu, adic:
1. procesul are dou-trei fluxuri de intrare i de ieire;
2. procesul poate fi descris sub form de transformare a intrrilor n ieiri;
3. procesul poate fi descris sub forma unui algoritm secvenial.
Pentru procesele simple este elaborat minispecificaia descrierea formal a algoritmului de
transformare a intrrilor n ieiri.
Minispecificaiile vor respecta urmtoarele cerine: pentru fiecare proces este elaborat o
singur specificaie; specificaia determin n mod univoc fluxurile de intrare i de ieire
pentru procesul dat; specificaia nu determin modul de transformare a fluxurilor de intrare n
fluxuri de ieire; specificaia face referin doar la elementele existente fr a introduce
elemente noi; specificaia va utiliza n msura posibilitilor operaii i abordri standard.
Dup ce procesul principal a fost descompus vor fi construite pentru fiecare subproces tabele
analogice ale evenimentelor interne.
La urmtorul pas, dup determinarea tabelului complet al evenimentelor, vor fi evideniate
fluxurile de date cu care procesele fac schimb, i entitile externe. Cea mai simpl
modalitate este analiza tabelului evenimentelor. Evenimentele sunt transformate n fluxuri de
date de la iniiatorul evenimentului la procesul solicitat, iar reaciile n flux invers de
evenimente. Dup construirea fluxurilor de intrare i ieire n mod analogic sunt construite
fluxurile interne. Pentru evidenierea lor vor fi selectai furnizorii i consumatorii informaiilor
pentru fiecare proces intern. Dac un furnizor sau un consumator de informaii este un proces
de pstrare sau de solicitare de informaii, atunci va fi introdus depozitul de date, pentru care
acest proces servete drept interfa.
Dup construirea fluxurilor de date diagrama va fi verificat la completitudine i lipsa
contradiciilor. Completitudinea unei diagrame este asigurat dac n sistem nu exist procese
neutilizate n procesul de transformare a intrrilor n ieiri. Lipsa contradiciilor este asigurat
prin ndeplinirea unui set de reguli formale privind tipurile posibile de procese: pe diagram
nu poate fi un proces, care s lege dou entiti externe o astfel de interaciune trebuie
lichidat; nici o entitate nu poate direct primi din sau transmite informaii n depozit
depozitul de date este un element pasiv, gestionat cu ajutorul procesului de interfaare; dou
depozite de date nu pot s fac schimb direct de informaii astfel de depozite trebuie
comasate n unul singur.
n calitate de avantaje ale metodei DFD trebuie subliniate:
posbilitatea determinrii univoce a entitilor externe, analiznd fluxurile de
informaii din sistem i din afara lui;
posibilitatea proiectrii de sus n jos, prin aceasta simplificnd construirea
modelului to be;
prezena specificaiilor proceselor de nivel inferior, cea ce permite s se treac
de nonfinalizarea logic a modelului funcional i s se constriasc specificaiia
funcional complet a sistemului elaborat.

La dezavantaje: necesitatea introducerii artificiale a proceselor administrative (de conducere,

control sau gestiune), deoarece aciunile de conducere (fluxuri) i procesele de conducere din
punctul de vedere al DFD nu se deosebesc prin nimic de cele obinuite; lipsa noiunii de timp,
adic lipsa analizei intervalelor de timp la transforamrea datelor (toate constrngerile
temporale trebuie introduse n specificaiile proceselor).

6.2.3.

Metoda obiect-orientat

Diferena principial ntre abordarea funcional i cea obiectual const n modalitatea de

descompunere sistemului. n abordarea obiect-orientat este utilizat decompoziia
obiectual n care structura static este descris n termeni de obiecte i legturi ntre ele,
iar comportamentul sistemului n termeni de schimb de mesaje ntre obiecte. Scopul
metodei este construirea modelului business al organizaiei, care permite trecerea de la
modelul scenariilor de utilizare la modelul, ce determin obiectele separate participante n
realizarea funciilor business.
Baza conceptual a abordrii obiect-orientate este format de modelul obiectual, construit
conform principii de abstractizare, incapsulare, modularitate, ierarhizare, tipizare, paralelism
i stabilitate.
Noiunile de baz ale abordrii obiect-orientate sunt obiectul i clasa.
Un obiect nglobeaz date i operaii i reprezint o abstraciune a unei entiti din lumea
real. Obiectul are un comportament bine definit, desemnat de strile n care se poate afla i
de individualitatea proprie.
Clasa este o descriere a unei mulimi de obiecte caracterizate prin structur i comportament
similare. Programele sunt organizate ca ansamble de obiecte ce coopereaz ntre ele, fiecare
obiect reprezentnd instana unei clase; fiecare clas aparine unei ierarhii de clase n cadrul
creia clasele sunt legate prin relaii de motenire.
La baza abordrii obiect-orientate stau urmtoarele concepte:
abstractizarea;
incapsularea;
modularitatea;
ierarhizarea;
motenirea;
agregarea.
O abstraciune exprim toate caracteristicile eseniale ale unui obiect, care fac ca acesta s
se disting de alte obiecte; abstraciunea ofer o definire precis a granielor conceptuale ale
obiectului, din perspectiva unui privitor extern. n procesul de abstractizare atenia este
ndreptat exclusiv spre aspectul exterior al obiectului, adic spre comportarea lui, ignornd
implementarea acestei comportri. Cu alte cuvinte abstractizarea ne ajut s delimitm ferm
"CE face obiectul" de "CUM face obiectul ceea ce face".
Incapsularea este conceptul complementar abstractizrii. Dac rezultatul operaiei de
abstractizare pentru un anumit obiect este identificarea protocolului su, atunci incapsularea
are de a face cu selectarea unei implementri i tratarea acesteia ca pe un secret al
respectivei abstraciuni. Prin urmare, incapsularea este procesul n care are loc ascunderea
implementrii unui obiect fa de majoritatea clienilor si.
Altfel spus, incapsularea este procesul de compartimentare a elementelor care formeaz
structura i comportamentul unei abstraciuni; incapsularea servete la separarea interfeei
"contractuale" de implementarea acesteia.
Din definiia de mai sus rezult c un obiect este format din dou pri distincte:
interfaa (protocolul)

implementarea interfeei.

Abstractizarea este procesul prin care este definit interfaa obiectului, n timp ce

incapsularea definete reprezentarea (structura) obiectului mpreun cu implementarea

interfeei.
Clasele i obiectele obinute n urma abstractizrii i incapsulrii trebuie grupate i apoi
stocate ntr-o form fizic, denumit modul. Modulele pot fi privite ca un fel de containere
fizice n care declarm clasele rezultate n urma proiectrii la nivel logic. Asadar, modulele
formeaz arhitectura fizic a programului.
Modularizarea const n divizarea programului ntr-un numr de subuniti care pot fi
compilate separat, dar care sunt cuplate (conectate) ntre ele. Gradul de cuplaj ntre module
trebuie s fie mic, pentru ca modificrile aduse unui modul s afecteze ct mai puine alte
module.
Incapsularea i modularizarea reprezint procese similare dar care se desfoar la nivele
diferite: incapsularea se aplic la nivelul "microcosmosului" (obiectele), iar modularizarea la
nivelul "macrocosmosului" (programele).
Reguli utile de modularizare:

2. Structura fiecrui modul trebuie s fie suficient de simpl pentru a putea

fi complet neleas.
3. Implementarea unui modul trebuie s depind doar de interfeele altor
module. Cu alte cuvinte trebuie s fie posibil modificarea implementrii unui modul
fr a avea cunotine despre implementarea altor module i fr a afecta
comportarea celorlalte module.
4. Acele detalii ale sistemului, care se presupune c se vor modifica
independent vor fi plasate n module diferite.
5. Singurele legturi ntre module vor fi acelea a cror modificare este
improbabil.

6. Orice structur de date este incapsulat ntr-un modul; ea poate fi

accesat direct din interiorul modulului dar nu poate fi accesat din afara modulului
dect prin intermediul obiectelor i claselor coninute n acel modul.
Ierarhizarea reprezint o ordonare a abstraciunilor. Cele mai importante ierarhii n
paradigma obiectual sunt:
ierarhia de clase (relaie de tip "is a")

ierarhia de obiecte (relaie de tip "part of")

Motenirea (ierarhia de clase) definete o relaie ntre clase n care o clas mprtete
structura i comportarea definit n una sau mai multe clase (dup caz vorbim de motenire
simpl sau multipl). Relaia de motenire face diferena ntre programarea orientat pe
obiecte i cea bazat pe obiecte. Semantic, motenirea indic o relaie de tip "is a" ("este
un/o"). Prin urmare, mostenirea implica o ierarhie de tip generalizare/specializare, in care
clasa derivata specializeaza structura si comportamentul mai general al clasei din care a fost
derivata.
Agregarea (ierarhia de obiecte) este relaia ntre dou obiecte n care unul dintre obiecte
aparine celuilalt obiect. Agregarea red apartena unui obiect la un alt obiect. Semantic,
agregarea indic o relaie de tip "part of" ("parte din").
O calitate important a abordrii obiectuale const n consistena modelelor activitii
organizaiei i modelelor sistemului informaional proiectat de la etapa formulrii cerinelor
pn la etapa implementrii. Prin intermediul modelelor obiectuale poate fi urmrit
reflectarea entitilor reale ale domeniului obiectiv modelat (a organizaiei) n obiecte i clase
ale sistemului informaional.
Majoritatea metodelor existente de abordare obiectual includ limbajul de modelare i
descrierea procesului de modelare. Prin proces se nelege descrierea pailor, care trebuie

parcuri pentru realizarea proiectului. I n calitate de limbaj de modelare este utilizat limbajul
unificat UML, care include un set standard de diagrame pentru modelare.
n cadrul UML-ului descoperim 9 tipuri de diagrame: diagrama cazurilor de utilizare, diagrama
de secven, diagrama de colaborare, diagrama de clase (cea mai utilizat), diagrama de
stri, diagrama de componente, diagrama de construcie, diagrama de obiecte, diagrama de
activiti.
Abordarea obiect-orientat are urmtoarele avantaje:
Decompoziia obiectual permite crearea modelelor de dimensiuni mai mici prin
utilizarea unor mecanisme comune, care asigur economia necesar a mijloacelor de
exprimare. Abordarea orientat obiect sporete semnificativ nivelul de unificare a
procesului de elaborare i reutilizare a componentelor.
Decompoziia obiectual permite s se evite crearea unor modele complicate,
deoarece presupune dezvoltarea evoluional a modelului n baza unor subsisteme
relativ mici.
Modelul obiectual este unul firesc deoarece este bazat pe percepia uman a
lumii.
La dezavantaje trebuie de subliniat cheltuielile nalte de start. Este o abordare care nu ofer
rezultate imediate. Eficacitatea apare dup realizarea a dou-trei proiecte i acumularea de
componente reutilizabile.

6.2.4.

Compararea metodelor

Funciile (operaiile, aciunile, activitile), legate prin fluxuri de obiecte, sunt componentele
structurale principale ale modelelor funcionale (diagramele DFD sau SADT).
Un avantaj indiscutabil al modelelor funcionale este realizarea abordrii structurale pentru
proiectarea SI conform principiului top-down, cnd fiecare bloc funcional poate fi
descompus ntr-o mulime de subfuncii .a.m.d., realiznd proiectarea modular a SI. Pentru
modelele funcionale sunt caracteristice rigurozitatea procedural a decompoziiei SI i
prezentarea clar.
Abordarea funcional presupune crearea separat a modelelor obiect sub form de diagrame
ER obiect-proprietate-relaie. Pentru verificarea corectitudinii modelrii domeniului obiectiv
ntre modelul funcional i cel obiectual sunt stabilite relaii biunivoce.
Principalul dezavantaj al modelelor funcionale const n faptul, c procesele i datele exist
independent unele de altele n afara decompoziiei funcionale exist, ntr-un plan secundar,
structura datelor. Mai mult, nu sunt clare condiiile de ndeplinire a proceselor de prelucrare a
informaiilor, care pot s se schimbe dinamic.
Aceste dezavantaje sunt excluse n modelele obiect-orientate n care clasa de obiecte cu setul
de funcii asociat este componenta structural principal.
Pentru clasele de obiecte este caracteristic ierarhia generalizatoare, care permite motenirea
nu doar a atributelor (proprietilor) obiectelor clasei de nivel mai nalt, dar i a funciilor
(metodelor).
n cazul motenirii funciilor se poate face abstracie de o realizare concret a procedurilor
(tipuri abstracte de date), care difer pentru anumite subclase de situaii. Aceasta permite
apelarea unor astfel de module program folosind nume comune (polimorfism) i este posibil
utilizarea repetat a codului la modificarea resurselor program. n consecin, adaptabilitatea
sistemelor obiect-orientate este mult mai nalt dect n cazul abordrii funcionale.
Chiar i principiul proiectrii este modificat n abordarea obiect-orientat. Mai nti sunt
stabilite clasele obiectelor, iar n continuare n dependen de strile posibile ale obiectelor
(ciclului de via a obiectelor) sunt determinate metodele de procesare (procedurile
funcionale), ceea ce asigur o mai bun realizare a comportamentului dinamic al sistemului
informaional.

Pentru abordarea obiect-orientat au fost elaborate metode i create instrumente de

modelare grafic a domeniului obiectiv, generalizate n cadrul limbajului UML. Dar modelele
UML cedeaz modelelor funcionale din punctul de vedere al claritii.
Metoda modelrii domeniului obiectiv este aleas reieind din gradul de dinamism al
domeniului. Pentru situaiile cu un nivel mai nalt de reglementare sunt recomandate
modelele funcionale, iar pentru procese business cu un grad de adaptivitate mai nalt
(gestiunea fluxurilor de lucru, realizarea solicitrilor dinamice la depozite de date) modele
obiect-orientate. n unele cazuri, n cadrul aceluiai sistem pentru diferite clase de probleme
pot fi necesare diferite tipuri de modele, care s descrie acelai domeniu obiectiv. n acest caz
vor fi utilizate modele mixte ale domeniului.

6.3.

Metoda sintetic

Cum a fost subliniat mai sus, fiecare din metode permite soluionarea problemei construirii
descrierii formale a procedurilor de lucru ale sistemului cercetat. Toate metodele permit
elaborarea modelului as is i to be. n acelai timp, fiecare metod are nejunsuri
substaniale. ns neajunsurile utilizrii unei metode nu se afl n sfera descrierii proceselor
reale, ci n incompletitudinea abordrii metodice.
Metodele funcionale aduc o claritate mai mare referitor la funciile existente n organizaie,
metodele de realizare a acestora, iar calitatea descrierii sistemului crete odat cu creterea
nivelului de detalizare a obiectului studiat. Prin creterea calitii descrierii se are n vedere
obinerea unor modele, care permit o prognozare mai bun a comportamentului sistemului
real. La nivelul unor proceduri de lucru separate descrierea lor practic coiincide cu
implementarea fizic.
La nivelul general de descriere metodele funcionale permit interpretri neunivoce referitor la
alegerea interfeelor i mecanismelor sistemului, adic la stabilirea granielor sistemului. La
acest nivel abordarea obiect-orientat vine cu soluii mai bune, bazate pe noiunea scenariul
de utilizare. Momentul cheie este reprezentat de noiunea de scenariu de utilizare sub form
de sesiune de interaciune a utilizatorului cu sistemul, n rezultatul creia utilizatorul obine
ceva ce prezint valoare. Utilizarea criteriului valorii permite utilizatorului s exclud detaliile
secundare ale fluxului de lucru i s se concentreze asupra funciilor, care justific existena
sistemului. Totui, i n acest caz problema determinrii granielor sistemului, evidenierea
utilizatorilor externi este complicat.
Tehnologia fluxurilor de date, care este istoric prima tehnologie, rezolv uor problema
granielor, deoarece prin analiza fluxurilor informaionale permite s fie evideniate entitile
externe i determinat procesul intern principal. ns, lipsa proceselor explicite de conducere,
fluxurilor i orientrii pe evenimente impune cutarea unor tehnologii suplimentare
complementare.
Cea mai bun modalitate de eliminare a neajunsurilor menionate mai sus este formarea unei
metode sintetice, care s reuneasc avantajele metodelor studiate mai sus.
Ideea metodei sintetice const n utilizarea succesiv a abordrilor funcionale i obiectuale
innd n vizor posibilitaile de reinginerie a situaiei existente.
Vom studia utilizarea metodei sintetice pe exmplul elaborrii unui regulament administrativ. n
acest caz sunt evideniate urmtoarele etape:

1. Stabilirea granielor sistemului. La acest etap n rezultatul analizei fluxurilor

de date sunt identificate entitile externe i sistemul modelat.
2. Determinarea scenariilor de utilizare a sistemului. Folosind criteriul de utilitate
la aceast etap pentru fiecare entitate extern este construit setul de scenarii de
utilizare a sistemului.
3. Adugarea scenariilor de utilizare de sistem. Aici sunt determinate scenariile
necesare pentru realizarea obiectivelor sistemului, diferite de obiectivele utilizatorilor.

4. Construirea diagramei de activiti din scenariile de utilizare. Este construit

setul de aciuni ale sistemului, care conduc la realizarea scenariilor de utilizare.
5. Decompoziia funcional a diagramelor de activiti sub forma diagramelor de
context n metoda IDEF0.
6. Descrierea formal a activitilor funcionale separate sub forma regulamentului
administrativ (utiliznd diferite notaii).

1. ?



2.



3. ?
( )
( )
( )
4. ?

,



5.
IDEF0?


,

6. -

7. DFD






8. -

9.

7. Modelarea proceselor business n BPwin

Instrumente CASE pentru modelarea proceselor business. Mediul instrumental BPwin. Principiile de construire a
modelului IDEF0: diagrama de context, subiectul modelrii, obiectivul i punctul de vedere. Diagramele IDEF0:
diagrama de context, diagramele de decompoziie, diagramele arborelui nodurilor, diagramele de expunere (FEO)
Activiti (Activity). Sgei (Arrow). Tunelarea sgeilor. Numerotarea activitilor i diagramelor. Carcasa diagramei.
Agregarea i dezagregarea modelelor. Crearea rapoartelor.

Modelarea proceselor business, de regul, este realizat cu ajutorul mijloacelor CASE. Din
aceast categorie fac parte BPwin (PLATINUM technology), Silverrun (Silverrun technology),
Oracle Designer (Oracle), Rational Rose (Rational Software) .a. Vom analiza n continuare
posibilitile funcionale ale instrumentelor de modelare structural a proceselor business pe
exemplul mediului instrumental BPwin.
BPwin susine trei metodologii de modelare: modelarea funcional (IDEF0), descrierea
proceselor business (IDEF3) i digramele fluxurilor de date (DFD).

7.1.

Mediul instrumental BPwin

BPwin are o interfa a utilizatorului relativ simpl i intuitiv neleas. La lansarea BPwin este
afiat panoul principal al instrumentelor, palitra instrumentelor (forma creia depinde de
notaia selectat) i, n partea stng, navigatorul modelului Model Explorer (fig. 7.1).

Fig. 7.1. Mediul integrat de construire a modelului BPwin

La construirea unui model nou va fi lansat un dialog n cadrul cruia trebuie de indicat dac va
fi creat un model absolut nou sau modelul va fi deschis dintr-un fiier sau depozitul
ModelMart. Va fi introdus numele modelului i aleas metodologia n care va fi construit
modelul (fig. 7.2).
Cum a fost menionat mai sus, BPwin susine trei metodologii IDEF0, IDEF3 i DFD, fiecare
soluionnd probleme specifice. n BPwin pot fi construite modele mixte, adic pot fi prezente
instantaneu diagrame IDEF0, IDEF3 i DFD. Componena panoului instrumentelor se va
schimba n mod automat la trecerea de la o notaie la alta.

Fig. 7.2. Dialogul de creare a modelului

Un model BPwin este privit ca un set de activiti, fiecare din care opereaz cu un anumit set
de date. Activitile sunt notate prin dreptughiuri, datele prin sgei. Dac se acioneaz
butonul din dreapta a mouse-ului pe un obiect al modelului va apare meniul de context,
fiecare punct al cruia corespunde editorului unei proprieti a obiectului.

7.2.

Construirea modelului IDEF0

La etapele de debut ale crerii SI este necesar s nelegem cum funcioneaz organizaia,
pentru care va fi implementat sistemul. Conductorul organizaiei cunoate lucrul la nivel
general, dar nu este n stare s intre n detalii pentru fiecare colaborator. Un colaborator tie
tot ce este legat de locul su de lucru, dar poate s nu cunoasc ce fac colegii. Din aceast
cauz pentru descrierea modului de activitate a organizaiei trebuie construit modelul adecvat
domeniului obiectiv i care va include toate cunotinele participanilor n procesele business
ale organizaiei.
IDEF0 este un limbaj comod de modelare a proceselor business n care sistemul este
reprezentat ca set de activiti sau funcii interdependente. Aceast orientare exclusiv
funcional este principial funciile sistemului sunt analizate independent de obiectele cu
care opereaz. Aceasta permite o modelare mai corect a logicii i interaciunii proceselor.
Modelarea n IDEF0 ncepe prin crearea diagramei de context diagrama celui mai abstract
nivel de descriere a sistemului n totalitate, care include definiia subiectului modelrii,
obiectivele i punctul de vedere aspura modelului (viewpoint).
Prin subiect se nelege nsi sistemul i este necesar s se stabileasc exact din ce este
format sistemul i ce se afl n afara lui. Cu alte cuvinte, s se determine care elemente vor fi
considerate mai departe componente ale sistemului, i care vor fi considerate drept aciuni
externe. O influen semnifcativ asupra determinrii subiectului va avea poziia din care este
abordat sistemul i obiectivele modelrii ntrebri la care trebuie s dea rspuns modelul
construit. Altfel spus, n debut trebuie de stabilit domeniul modelrii. Descrierea domeniului a sistemului n totalitate i a componentelor sistemului reprezint baza construirii modelului.
Chiar dac se permite c n timpul modelrii domeniul poate fi corectat, el trebuie identificat
din start, deoarece anume domeniul stabilete direcia modelrii. La determinarea domeniului

se va ine cont de lrgimea i adncimea lui. Lrgimea presupune determinarea granielor

modelului care vor fi componentele incluse n sistem i care vor rmne n afara lui.
Adncimea stabilete nivelul de detaliere la care nivel de concretizare a componentelor se
va considera modelul finalizat. La determinarea adncimii trebuie s se in cont de limitele
de timp eforturile necesare cresc n progresie geometric cu creterea adncimii. Odat cu
determinarea granielor sistemului se va considera c nu vor mai fi introduse obiecte noi n
sistemul modelat.

7.2.1.

Obiectivul modelrii i punctul de vedere

Obiectivul modelrii este identificat din rspunsurile la urmtoarele ntrebri:

Din care cauz acest proces trebuie modelat?
Ce trebuie s afieze modelul?
Ce poate obine clientul?
Prin punct de vedere nelegem perspectiva din care a fost studiat sistemul la construirea
modelului. Dei la construirea modelului se iau n consideraie prerile diferitor persoane, toi
trebuie s aib un punct de vedere comun referitor la model. Punctul de vedere trebuie s
corespund obiectivelor i granielor modelrii. De obicei, este ales punctul de vedere al
persoanei responsabile de activitile de modelare n totalitate.
Modelul IDEF0 presupune existena unui obiectiv formulat clar, a unui subiect unic al
modelrii i a unui punct de vedere unic. Pentru introducerea domeniului, obiectivului i a
punctului de vedere se va selecta punctul din meniu Model/Model Properties, care apeleaz
dialogul Model Properties (fig. 7.3). n pagina Purpose trebuie de introdus obiectivul i punctul
de vedere, iar n pagina Definition definiia modelului i descrierea domeniului.

Fig. 7.3. Dialogul de desemnare a proprietilor modelului

n pagina Status a aceluiai dialog poate fi descris statutul modelului (varianta maculator, de
lucru, final, etc.), data crerii i a ultimei editri (urmrire automat dup data de sistem). n
pagina Source sunt descrise sursele informaionale pentru construirea modelului (de exemplu,
Chestionarea experilor domeniului obiectiv i analiza documentaiei). Pagina General
servete pentru introducerea numelui proiectului i a modelului, numelui autorului i cadrului
temporal al modelului AS-IS sau TO-BE.
De obicei la nceput este construit modelul cum are loc organizarea activitilor AS-IS (cum
este). Analiza modelului funcional permite s se stabileasc locurile slabe, s se determine n
ce vor consta avantajele noilor procese business i ct de adnci vor fi modificrile propuse.
Detalizarea proceselor business permite identificarea neajunsurilor organizaiei chiar acolo
unde la prima vedere totul este corect. Neajunsurile identificate cu ajutorul modelului AS-IS

pot fi corectate prin crearea modelului TO-BE (cum va fi) modelul de organizare nou a
proceselor business.
Tehnologia proiectrii SI presupune mai nti crearea modelului AS-IS, analiza lui i
perfecionarea proceselor business, adic crearea modelului TO-BE, i numai n baza
modelului TO-BE va fi construit modelul datelor, prototipul i apoi varianta final a SI.
Adesea modelul curent AS-IS i modelul viitor TO-BE se deosebesc foarte mult, n rezultat
trecerea de la starea iniial la cea final nu este evident. n aceste cazuri este necesar un
model intermediar, care va descrie procesul trecerii de la starea iniial la cea final, iar
aceast trecere este la fel un proces business.
Rezultatele descrierii modelului pot fi obinute n raportul Model Report. Dialogul de
configurare a raportului conform modelului este apelat din punctul de meniu
Tools/Reports/Model Report. n dialogul de configurare vor fi bifate cmpurile necesare, n
acest timp n mod automat va fi afiat ordinea de extragere a informaiilor n raport (fig. 7.4).

Fig. 7.4. Fereastra de dialog pentru formarea raportului

n figura 7.5 este prezentat un raport, creat conform cmpurilor bifate n figura 7.4.

Fig. 7.5. Afiarea prealabil a raportului

Baza metodologiei IDEF0 este limbajul grafic de descriere a proceselor business. n notaia
IDEF0 modelul const dintr-un set de diagrame interdependente, ordonate ierarhic. Fiecare
diagram este o unitate de descriere a sistemului i este plasat pe o pagin separat.

7.2.2.

Tipuri de diagrame

Modelul poate include patru tipuri de diagrame:

diagrama de context (n fiecare model poate exista doar o singur diagram de
context);
diagramele de decompoziie;
diagramele arborelui nodurilor;
diagramele pentru expoziie (FEO).
Diagrama de context este rdcina structurii arborescente a diagramelor i prezint
descrierea general a sistemului i interaciunea lui cu mediul extern. Dup descrierea la nivel
general are loc mprirea sistemului n fragmente mari. Acest proces se numete
decompoziie funcional, iar diagramele, care descriu fiecare fragment i interaciunea
fragmentelor, se numesc diagrame ale decompoziiei. Dup decompoziia diagramei de
context are loc decompoziia fiecrui fragment mare n fragmente mai mici i tot aa, pn la
atingerea nivelului necesar de concretizare a descrierii. Dup fiecare ciclu de decompoziie au
loc sesiuni de expertizare experii domeniului obiectiv analizeaz corespondena proceselor
business reale cu diagramele create. Abaterile depistate sunt corectate i doar la momentul
lipsei observaiilor se va trece la urmtorul ciclu de decompoziie. Astfel este realizat
corespondena dintre model i procesele business reale la fiecare nivel al modelului. Sintaxa
descrierii sistemului n totalitate i a fiecrui fragment este aceeai pentru ntreg modelul.
Diagrama arborelui nodurilor indic dependena ierarhic a activitilor, ns nu
interdependena lor. Astfel de diagrame ntr-un model pot fi orict de multe, deoarece
arborele poate fi construit la orice adncime i nu obligator ncepnd cu rdcina.

Diagramele pentru expoziie (FEO) sunt construite pentru a ilustra fragmente separate ale
modelului, puncte de vedere alternative sau n scopuri speciale.
Activitatea (Activity) semnific procese, funcii sau lucrri nominalizate, care au loc ntr-un
anumit interval de timp i produc rezultate descifrabile. Activitile sunt notate prin
dreptunghiuri. Toate activitile trebuie s fie denumite i definite. Numele unei activiti este
o combinaie de cuvinte, care semnific aciune (de exemplu, Funcionare companie,
Recepie comenzi .a.m.d.). Activitatea cu denumirea Funcionare companie poate avea,
de exemplu, urmtoarea definiie: Acest model este un model de studiu, care descrie cum
funcioneaz compania. La crearea modelului nou (opiunea meniului File/New) n mod
automat este creat diagrama de context cu o singur activitate, care reprezint sistemul n
totalitate (fig. 7.6).

Fig. 7.6. Exemplu de diagram de context

Pentru introducerea numelui activitii se va aciona butonul din dreapta a mouse-ului, se va
alege opiunea de meniu Name Editor i n fereastra de dialog se va introduce numele
actvitii. Pentru descrierea altor proprieti ale activitii servete dialogul Activity Properties
(fig. 7.7).

Fig. 7.7. Editorul proprietilor unei activiti

Diagramele de decompoziie conin activiti care se afl n relaie de paternitate cu
activitatea descompus, adic sunt activiti-fiice (au o activitate printe comun). Pentru
crearea diagramei de decompoziie se va aciona butonul din panoul de instrumente. Va fi
afiat fereastra de dialog Activity Box Count (fig. 7.8) n care trebuie de indicat notaia
diagramei noi i numrul de activiti din aceast diagram.

Fig. 7.8. Fereastra de dialog Activity Box Count

Alegem aici notaia IDEF0 i acionm OK. Apare diagrama de decompoziie (fig. 7.9).
Numrul permis de activiti este de la 2 la 8. Nu are sens s descompunem o activitate ntr-o
alt (singur) activitate. Diagramele cu mai mult de 8 activiti sunt suprancrcate i dificil

de citit. Pentru claritate i o nelegere mai bun a proceselor modelate se recomand s

utilizm de la 3 la 6 blocuri ntr-o diagram.

Fig. 7.9. Exemplu de diagram de decompoziie

Dac numrul activitilor este insuficient, este posibil adugarea unei activiti ntr-o
diagram, prin clik pe butonul din panoul instrumentelor, apoi ntr-un loc liber pe diagram.
Activitile ntr-o diagram de decompoziie sunt plasate pe diagonala stnga-sus - dreaptajos. Aceast ordine se numete ordine de dominare. Conform acestui principiu de plasare, n
colul stnga-sus este plasat cea mai important activitate sau activitatea executat prima
n timp. Relaia este recursiv pentru celelate activiti. Aceast plasare faciliteaz citirea
diagramelor, plus c pe o astfel de plasare este bazat noiunea de interdependen a
activitilor.
Fiecare activitate din diagrama de decompoziie poate fi la rndul su descompus. Pe
diagrama de decompoziie activitile sunt numerotate n mod automat de la stnga la
dreapta. Numrul activitii este afiat n colul dreapta-jos. n colul stnga-sus este afiat o
mic linie diagonal, care indic c aceast activitate nu a fost descompus. Astfel, n figura
7.9 nu a fost descompus nc nici o activitate.
Sgeile (Arrow) descriu interaciunile activitilor i reprezint anumite informaii, exprimate
prin substantive (de exemplu, Reguli i proceduri, Sistem contabil", Adresri telefonice).

7.2.3.

Tipuri de sgei

n IDEF0 exist 5 tipuri de sgei:

Intrare (Input) material sau informaie, utilizate sau transformate de activitate n scopul

obinerii unui rezultat (ieire). Activitatea poate s nu aib nici o sgeat de intrare. Fiecare
tip de sgeat este asociat unei laturi selectate a dreptunghiului activitate (intr sau iese).

Sgeata intrare este desenat intrnd n latura din stnga a activitii. La descrierea
proceselor tehnologice (pentru ele a fost gndit IDEF0) nu apar probleme legate de
determinarea intrrilor. ntr-adevr, Adresri telefonice este ceva prelucrat de procesul
" ", pentru obinerea rezultatului. ns n cazul n care sgeile nu
sunt obiecte fizice, ci date, nu este totul att de evident. De exemplu, pentru activitatea
Primirea pacientului cartela pacientului poate fi att la intrare, ct i la ieire, iar calitatea
acestor date nu se modific. Cu alte cuvinte, n exemplul nostru, pentru ca sgeile s
ndrepteasc destinaia, trebuie s fie exact definite, adic s indice (pentru ieiri) c datele
ntra-adevr au fost prelucrate (Cartela completat a pacientului). n unele cazuri este dificil
de stabilit dac datele sunt intrri sau controluri. n aceste cazuri poate fi util informaia
dac datele sunt sau nu prelucrate/modificate de activitate. Dac da, atunci este mai probabil
c avem intrri, n caz contrar - control.
Control reguli, strategii, proceduri sau standarde, cu respectarea crora are loc activitatea.
Fiecare activitate trebuie s posede minimum o sget control. Sgeata control este desenat
intrnd n latura orizontal de sus a dreptunghiului activitii. n figura 7.6 sgeata "
" este control pentru " ". Controlul influieneaz
activitatea dar nu este transformat de ea. Dac scopul activitii este de a modifica o
procedur sau o strategie, atunci o astfel de procedur sau strategie va fi pentru activitate
intrare. n cazul apariiei unor incertitudini legate de statutul sgeii (control sau intrare) se
recomand s fie desenat sgeata control.
Ieire (Output) material sau informaie, produse de activitate. Orice activitate trebuie s
posede cel puin o sgeat ieire . O activitate fr rezultat nu are sens i nu trebuie

modelat. Sgeata ieire este desenat pornind de la latura vertical dreapta a activitii. n
figura 7.6 sgeile " " i " " sunt ieiri pentru activitatea
" ".
Mecanism (Mechanism) resursele, care ndeplinesc activitatea, de exemplu personalul
ntreprinderii, mainile unelte, dispozitivele etc. Sgeata mecanism este desenat intrnd n
latura orizontal de jos a activitii. n figura 7.6 sgeata " " este
mecanism pentru activitatea " ". Analistul de sistem poate s nu
includ sgeile mecanism n model.
Apel (Call) sgeat special, care face referire la alt model al activitii. Sgeata apel este
desenat ieind din latura orizontal de jos a activitii. n figura 7.10 sgeata "
" este apel pentru activitatea " ". Sgeata apel este
utilizat pentru a indica, c o activitate oarecare este ndeplinit n afara sistemului modelat.
n BPwin sgeile apel sunt utilizate n mecanismul de agregare sau dezagregare a modelelor.

Fig. 7.10. Sgeata apel, care apare la dezagregarea modelului

Sgei de grani. ntr-o diagram de context sgeile sunt utilizate pentru descrierea
interaciunii sistemului cu mediul nconjurtor. Ele pot ncepe la grania diagramei i pot s se
termine la activitate sau invers. Aceste sgei se numesc de grani. Pentru introducerea unei
sgei de grani intrare se va proceda dup cum urmeaz:
se va aciona butonul cu simbolul ,

n palitra de instrumente cursorul va fi deplasat spre partea stng a ecranului

pn va aprea nceputul unei liniue de haurare;
se va face clik simplu pe aceast liniu (de unde iese sgeata) i nc unul n
partea stnga a activitii din partea intrrii (unde se va termina sgeata);
ne ntoarcem n palitra instrumentelor i alegem opiunea editare sgeat
cu butonul din dreapta a mouse-ului facem clik pe linia sgeii, n meniul pop-up
alegem Name i adugm numele sgeii n pagina Name a dialogului IDEF0 Arrow
Properties.
Sgeile control, intrare, mecanism i ieire sunt introduse n mod analogic. Numele sgeilor
noi (fig. 7.11) sunt introduse n mod automat n Arrow Dictionary.

Fig. 7.11. Fereastra de dialog IDEF0 Arrow Properties

7.2.4.

Codurile ICOM

Diagrama de decompoziie este destinat detalizrii activitii. Spre deosebire de modelele,

care reflect structura organizaiei, activitatea ntr-o diagram de nivel siperior n IDEF0 nu
este un element de control cu activitile de la nivele mai joase. Activitile de la nivele mai
joase reprezint aceleai momente ca i activitile de nivel nalt, dar cu un grad mai mare de
detaliere. n rezultat, graniele unei activiti de nivel superior reprezint acelai lucru ca i
graniele diagramei de decompoziie. ICOM (abrevierea de la Input, Control, Output i
Mechanism) sunt codurile destinate identificrii sgeilor de grani. Un cod ICOM conine
prefixul, care corespunde tipului sgeii (I, C, O sau M) i numrul de ordine.
BPwin introduce codurile n mod automat. Pentru afiarea codurilor ICOM trebuie actualizat
opiunea ICOM codes a paginii Display a ferestrei de dialog Model Properties (meniul
Model/Model Properties, fig. 7.12).
Dicionarul sgeilor este editat folosind editorul special Arrow Dictionary Editor, n care are
loc identificarea sgeii i este introdus comentariul asociat ei (fig. 7.13). Dicionarul sgeilor
rezolv o problem foarte important. Analistul creeaz diagrame pentru a desfura
sesiunea de expertizare, adic s discute diagrama cu un specialist din domeniul obiectiv. n
orice domeniu obiectiv sunt create argouri (jargon) profesionale, frecvent expresiile jargon au
un sens vag i sunt contientizate n mod diferit de experi diferii. n acelai timp analistul
autorul diagramelor este obligat s utilizeze expresii pe nelesul experilor. Deoarece
definiiile formale adesea sunt complicate pentru acceptare, analistul este nevoit s utilizeze
n diagrame argoul profesional, iar pentru excluderea unor posibile tratri neunivoce, n
dicionarul sgeilor fiecare noiune poate fi definit extins, la necesitate formal.

Fig. 7.12. Activarea opiunii ICOM codes pe pagina Display

Fig. 7.13. Editarea dicionarului sgeilor

Coninutul dicionarului sgeilor poate fi imprimat sub form de raport (meniul Tools/
Report /Arrow Report...), vom obine n acest caz dicionarul explicativ al termenilor
domeniului obiectiv, utilizai n model.

7.2.5.

Sgei libere i sgei legate

Sgeile de grani nelegate (libere, unconnected border arrow). La decompoziia

activitii sgeile, care intr i care ies (cu excepia sgeii apel) apar in mod automat pe
diagrama de decompoziie (migrarea sgeilor), dar nu ating activitile. Aceste sgei se
numesc nelegate i sunt tratate de BPwin ca eroare sintactic.
n figura 7.14 este prezentat un fragment al diagramei de decompoziie cu sgei nelegate,
generate de BPwin la decompoziia activitii " " (fig.
7.9). Pentru legarea sgeilor de intrare, control sau mecanism trebuie de trecut n regimul de
editare a sgeilor, se face clik pe partea terminal a sgeii apoi pe segmentul respectiv al
activitii. Pentru legarea sgeii de ieire trebuie de trecut n regimul de editare a sgeilor,
se face clik pe segmentul de ieire al activitii apoi pe sgeat.

Fig. 7.14. Exemplu de sgei nelegate

Sgei interne. Pentru legarea reciproc a activitilor sunt utilizate sgei interne, adic
sgei, care nu ating graniele diagramei, pornind de la o activitate i terminndu-se la alta.
Pentru desenarea unei sgei interne n regim de editare a sgeilor se va face clik pe
segmentul (de exemplu, ieirea) unei activiti apoi pe segmentul (de exemplu, intrarea) altei
activiti. n IDEF0 exist cinci tipuri de legturi pentru activiti.
Legare de intrare (output-input), cnd sgeata de ieire a unei activiti superioare este
direcionat spre intrarea unei activiti inferioare (de exemplu, n fig. 7.15 sgeata
" " leag activitile " "
i " ").

Fig. 7.15. Legarea de intrare

Legare de control (output-control), cnd ieirea unei activiti superioare este

direcionat ctre controlul unei activiti inferioare. Legarea de control indic dominarea
activitii superioare. Datele sau obiectele de la ieirea activitii superioare nu pot fi
modificate n cadrul unei astfel de activiti inferioare. n figura 7.16 sgeata "
" leag activitile " " i "
".

Fig. 7.16. Legarea de control

Conexiune invers la intrare (output-input feedback), cnd ieirea unei activiti
inferioare este aplicat la intrarea unei activiti superioare. Aceast legtur, de obicei, este
utilizat pentru descrierea ciclurilor. n figura 7.17 sgeata " "
leag activitile " " i "
".

Fig. 7.17. Conexiune invers la intrare

Conexiune invers la control (output-control feedback), cnd ieirea unei activiti

inferioare este aplicat la controlul unei activiti superioare (sgeata "
", fig. 7.18). Conexiunea invers la control adesea subliniaz efecacitatea
procesului business. n figura 7.18 volumul vnzrilor poate fi sporit prin reglarea direct a
proceselor de asamblare i testare a calculatoarelor (ieirea activitii "
").

Fig. 7.18. Conexiunea invers la control

Legtura ieire-mecanism (output-mechanism), cnd ieirea unei activiti este aplicat
la mecanismul altei activiti. Aceast legtur este utilizat mai rar i semnific faptul, c o
activitate pregtete resurse, necesare pentru derularea altei activiti (fig. 7.19).

Fig. 7.19. Legtura ieire-mecanism

Sgei evidente. O sget evident are drept surs o singur (i numai una) activitate i
destinaie de asemenea o singur (i numai una) activitate.
Sgei de ramificare i de fuzionare. Unele i aceleai date sau obiecte, generate de o
singur activitate, pot fi utilizate instantaneu n alte cteva activiti. Pe de alt parte,
sgeile generate de activiti diferite, pot reprezenta aceleai (sau omogene) date sau
obiecte, care mai apoi sunt utilizate sau prelucrate n acelai loc. Pentru modelarea acestor
situaii sunt utilizate sgei de ramificare i sgei de fuzionare. Pentru a ramifica o sgeat n
regim de editare a sgeii se face clik pe fragmentul sgeii i pe segmentul respectiv al
activitii. Pentru fuzionarea a dou sgei de ieire n regim de editare a sgeii se face mai

nti clik pe segmentul ieirii activitii, apoi pe fragmentul respectiv al sgeii.

Sensul sgeilor de ramificare i de fuzionare se transmite prin atribuirea unui nume pentru
fiecare ramur de sgeat. Exist anumite reguli de atribuire a numelor. Ca exemplu vom lua
sgeile de ramificare. Dac sgeata a fost numit pn la ramificare, iar dup ramificare nici
una din ramuri nu a fost denumit, se consider c fiecare ramur modeleaz aceleai date
sau obiecte, ca i pn la ramificare (fig. 7.20).

Fig. 7.20. Exemplu de atribuire a numelui pentru sgei ramificate

Dac sgeat avea denumire pn la ramificare, iar dup ramificare una din ramuri este de
asemenea denumit, se consider c aceste ramuri corespund denumirii. Dac n acest caz
una din ramuri a rmas fr nume, se consider c ea modeleaz aceleai date sau obiecte,
ca i ramura pn la ramificare (fig. 7.21).

Fig. 7.21. Exemplu de denumire a sgeii ramificate

Nu este admis situaia n care sgeata nu este denumit pn la ramificare, iar dup

ramificare una din ramuri este fr nume. BPwin determin astfel de sgei ca eroare
sintactic.
Regulile de atribuire a numelor sgeilor de fuzionare sunt analogice eroare va fi considerat
sgeata care dup fuzionare nu are nume, iar pn la fuzionare nu avea nume una din ramuri.
Pentru denumirea unei ramuri separate a sgeilor de ramificare i de fuzionare pe diagram
va fi selectat doar o ramur, dup care va fi apelat editorul numelui i va fi atribuit un nume
sgeii. Acest nume va corespunde doar sgeii selectate.

7.2.6.

Tunelarea sgeilor

Sgeile de grani noi, introduse ntr-o diagram de decompoziie de nivel inferior sunt
reprezentate n paranteze ptrate i nu vor apare n mod automat n diagramele de nivel mai
nalt (fig. 7.22).

Fig. 7.22. Sgeat nerezolvat (unresolved)

Pentru ridicarea lor se va face clik dreapta pe parantezele ptrate ale sgeii de grani i n
meniul de context se va selecta opiunea Arrow Tunnel (fig. 7.23).

Fig. 7.23. Alegerea opiunii din meniul de context

Fig. 7.24. Fereastra de dialog Border Arrow Editor

Va fi afiat fereastra de dialog Border Arrow Editor (fig. 7.24). Dac acionm butonul Resolve
Border Arrow, sgeata va migra pe diagrama de nivel superior, iar dac butonul Change To
Tunnel sgeat va fi tunelat i nu va ajunge pe alt diagram. O sgeat tunelat este
reprezentat cu paranteze rotunde la capt (fig. 7.25)

Fig. 7.25. Tipuri de tunelare a sgeilor

Tunelarea este utilizat pentru afiarea sgeilor puin importante. Dac ntr-o diagram de
nivel inferior trebuie reprezentate date sau obiecte puin importante, care nu sunt prelucrate
sau nu sunt utilizate de activiti la nivelul curent, ele trebuie expediate la nivelul superior (la
diagrama printe). Dac aceste date nu sunt utilizate nici n diagrama printe, atunci vor fi
expediate mai sus .a.m.d. n rezultat, o sgeat puin important va fi prezent la toate
nivelele i va complica citirea tutror diagramelor. Ieirea const n tunelarea acestei sgei la
cel mai inferior nivel. Aceast tunelare se numete nu-n-diagrama-printe.
Un alt exemplu de tunelare poate fi situaia n care o sgeat de tip mecanism migreaz de la
nivelul superior la nivelul inferior, i la nivelul inferior acest mecanism este utilizat n acelai
mod pentru toate activitile fr excepie. (Se presupune, c nu trebuie de detalizat sgeata
mecanismului, adic sgeata mecanismului pe activitatea-fiic a fost denumit pn la
ramificare, iar dup ramificare ramurile nu au nume proprii). n acest caz sgeata
mecanismului la nivelul inferior poate fi eliminat, dup ce n daigrama printe ea poate fi
tunelat, iar n comentariul sgeii sau n dicionar putem indica, c mecanismul va fi utilizat
n toate activitile diagramei-fiice de decompoziie. Aceast tunelare se numete nu-nactivitatea-fiic (fig. 7.25).

7.2.7.

Numirea activitilor i diagramelor

Toate activitile au nume. Numele const din prefix i un numr. Pot fi utilizate prefixe de
lungime arbitrar, dar de obicei este utilizat prefixul A. Diagrama de context (rdcin) are
numele A0. ctivitile decompoziiei diagramei A0 au numele A1, A2, A3 .a.m.d. Activitile
decompoziiei unui nivel inferior au numele activitii printe i numrul de ordine ordinar, de
exemplu decompoziiile lui A3 vor ave numele A31, A32, A33 .a.m.d. Activitile formeaz o
ierarhie n care fiecare activitate poate avea o activitate printe i cteva activiti fiice,
formnd un arbore. Acest arbore se numete arborele nodurilor, iar numerotarea de mai sus
numerotare pe noduri. Diagramele IDEF0 au o numerotare dubl. Mai nti, diagramele au
numr conform nodului. Diagrama de context are ntotdeauna numrul A-0, decompoziia
diagramei de context numrul A0, restul diagramelor decompoziiei numere conform
nodului (de exemplu, A1, A2, A21, A213 etc.). BPwin susine modul automat de numerotare pe
noduri. n rezultatul expertizelor diagramele por fi precizate i modificate, adic pot exista
deiferite versiuni ale unei diagrame de decompoziie (din punctul de vedere al plasrii n
arborele nodurilor).
BPwin permite existena n model a unei singure diagrame de decompoziie a nodului dat.
Versiunile precedente pot fi pstrate sub form de copii pe hrtie sau ca diagrame FEO. (Din
pcate, la crearea diagramellor FEO lipsete posibilitatea roll-back, adic dintr-o diagram

poate fi obinut decompoziia FEO, dar invers nu). n orice caz, trebuie s putem diferenia
diferite versiuni ale aceleeai diagrame. Pentru aceasta exist un numr special C-number,
care trebuie atribuit modelului n mod manual. C-number este o linie de simboluri oarecare,
dar se recomand respectarea standardului n care numrul const dintr-un prefix (simboluri,
iniialele autorului diagramei) i numrul de ordine (va fi urmrit n mod manual, de exemplu,
BV00048).

7.2.8.

Diagramele arborelui nodurilor i FEO

Diagramele arborelui nodurilor reprezint ierarhia atcivitilor modelului i ofer o vedere

asupra intregului model, dar nu conine legturile reciproce ntre activiti (fig. 7.26) Procesul
crerii modelului activitilor este iterativ, ca rezultat activitile pot fi deplasate n cadrul
arborelui nodurilor. Pentru claritate i pentru a verifica corectitudinea decompoziiei este
necesar ca dup fiecare modificare s fie creat diagrama arborelui nodurilor. BPwin are un
mecanism puternic de navigare prin model Model Explorer, care permite afiarea ierarhiei
activitilor i a diagramelor ntr-o form comod i compact.

Fig. 7.26. Diagrama arborelui nodurilor

Pentru crearea diagramei arborelui nodurilor n meniu va fi selectat opiunea Diagram/Add
Node Tree (fig. 7.27). Va fi afiat fereastra de dialog pentru formarea diagramei arborelui
nodurilor Node Tree Definition (fig. 7.28, 7.29).

Fig. 7.27. Alegerea opiunii pentru crearea

diagramei arborelui nodurilor

Fig. 7.28. Fereastra de ajustare a

diagramei arborelui nodurilor (pasul 1)

Fig. 7.29. Fereastra de ajustare a

diagramei arborelui nodurilor (pasul 2)

n dialogul Node Tree Definition trebuie de indicat adncimea Number of Levels (valoarea
implicit este 3) i rdcina arborelui (valoarea implicit este activitatea printe a diagramei
curente). n mod implicit nivelul de jos al decompoziiei este afiat n form de list, restul
activitilor n form de dreptunghiuri. Pentru afiarea ntregului arbore n form de
dreptunghiuri trebuie de eliminat bifa opiunii Bullet Last Level. Atunci cnd este creat
arborele nodurilor trebuie de indicat numele diagramei deoarece, dac n mai multe diagrame
va fi utilizat una i aceeai activitate n calitate de rdcin tuturor aceste diagrame se va
conferi unul i acelai numr (numrul nodului + sufixul N, de exemplu A0N) i n lista
diagramelor deschise (opiunea meniului Window) deosebirea ntre ele va putea fi fcut doar
dup nume.
Diagramele numai pentru expunere (FEO) sunt utilizate adesea n model pentru a ilustra
alte puncte de vedere, pentru reflectarea unor detalii separate, care nu sunt susinute de
sintaxa IDEF0. Diagramele FEO permit s fie nclcat orice regul sintactic, deoarece n
esen sunt doar simple tablouri copii ale diagramelor standard i nu particip la analiza

sintaxei. Pentru crearea unei diagrame FEO va fi aleas opiunea meniului Diagram/Add FEO
Diagram. Va fi afiat fereastra de dialog Add New FEO Diagram n care trebuie de indicat
numele diagramei FEO i tipul diagramei printe (fig. 7.30).

Fig. 7.30.

Fereastra de dialog pentru crearea unei diagrame FEO noi

Numrul unei diagrame noi este generat n mod automat (numrul diagramei printe conform
nodului + sufixul F, de exempplu A1F).

7.2.9.

Chenarul diagramei

n figura 7.31 este prezentat un exemplu tipic de diagram de decompoziie cu chenarul de

grani, numit chenarul diagramei.
Chenarul are un titlu (partea de sus a chenarului) i un subsol (partea de jos). Titlul chenarului
este utilizat pentru urmrirea (referirea) diagramei n procesul de modelare. Partea de jos este
utilizat pentru identificare i poziionare n ierarhia diagramei.
Sensul elementelor chenarului este prezentat n tabelele 7.1 i 7.2.
Cmp
Used At
Autor, Date,
Rev, Project
Notes
123456789 10
Status
Working
Draft
Recommended
Publication
Reader
Date
Context

Tabelul 7.1. Cmpurile titlului chenarului (de la stnga la dreapta)

Sens
Este utilizat pentru a indica activitatea printe, dac n diagrama curent se fcea
referin prin utilizarea sgeii apel
Numele autorului diagramei, data crerii i numele proiectului, b cadrul cruia a fost
creat diagrama. REV data ultimei revizuiri a diagramei
Este utilizat pentru sesiunile de expertizare. Expertul va indica (pe copia pe hrtie a
diagramei) numrul de observaii, tind cifra din list de fiecare dat cnd introduce o
observaie nou
Statutul reflect etapa crerii diagramei, conform etapelor de publicare
Diagram nou, diagram noit cardinal sau autor nou al diagramei
Diagrama a trecut expertizarea primar i este gata pentru discuii ulterioare
Diagrama i toate documentele asociate au trecut expertiza. Modificri noi nu sunt
ateptate
Diagrama este gata pentru imprimarea final i publicare
Numele cititorului (expertului)
Data citirii (expertizei)
Schema plasrii activitilor n diagrama de nivel superior. Activitatea printe este
prezentat printr-un dreptunghi nnegrit, restul de culoare deschis. Pe diagrama de
context (A-0) va fi prezent inscripia TOP. n colul stnga jos este indicat numrul
(conform nodului) al diagramei printe:

Tabelul 7.2. Cmpurile subsolului chenarului (de la dreapta la stnga)

Cmp
Sens
Node
Numrul nodului diagramei (numrul activitii printe)
Title
Numele diagramei. Implicit numele activitii printe
Numb C-Number, numr unic al versiunii diagramei
er
Page
Numrul paginii, poate fi utilizat ca numr de pagin la formarea
mapei

Fig. 7.31. Exemplu diagram de decompoziie cu chenar

Valorile cmpurilor sunt atribuite n fereastra de dialog Diagram Properties (meniul
Diagram /Diagram Properties) figura 7.32.

Fig. 7.32. Fereastra de dialog Diagram Properties

7.3.

Fuzionarea i separarea modelelor

Posibilitatea fuzionrii i separrii modelelor permite lucrul colectiv n proiect. Managerul

proiectului poate construi decompoziia nivelului superior i solicita analitii s continue
descompunerea fiecrei ramuri al arborelui n form de modele separate. Dup finalizarea
activitilor ramurilor separate toate submodelele pot fi reunite ntr-un model unitar. Pe de
alt parte, o ramur separat a modelului poate fi extras pentru a fi utilizat n calitate de
model independent, pentru perfecionare sau arhivare.
Pentru fuzionarea i separarea modelelor n BPwin sunt utilizate sgeile apel. Pentru
fuzionare este necesar s fie ndeplinite urmtoarele condiii:
Ambele modele reunite trebuie s fie deschise n BPwin.
Numele modelului-surs, reunit cu modelul-scop, trebuie s coiincid cu numele
sgeii de apelare a activitii n modelul-scop.
Sgeata apel trebuie s plece dintr-o activitate nedescompus (activitatea
trebuie s posede o liniu diagonal n colul stnga sus, fig. 7.33).

 Numele activitii de context a modelului-surs reunit i a activitii din

modelul-scop, la care reunim modelul-surs, trebuie s coiincid.
Modelul-surs trebuie s aib minimum o diagram de decompoziie.

Fig. 7.33. Sgeata de apelare a activitii " " a

modelului-scop
Pentru fuzionarea modelelor se va face clik dreapta cu mouse-ul pe activitatea cu sgeata
apel n modelul-scop i n meniul pop-up se va selecta opiunea Merge Model.
Este afiat o fereastr de dialog n care se va indica opiunea de reunire a modelului (fig.
7.34). La fuzionarea modelelor se vor reuni i dicionarele sgeilor i activitilor. n cazul n
care definiiile coiincid este posibil rescrierea lor sau acceptarea definiiilor din modelulsurs. Acelai lucru este valabil i pentru numele sgeilor, depozitele de date i referinele
externe. Depozitele de date i referinele externe obiecte ale diagramelor fluxurilor de date,
DFD, vor fi studiate mai jos.

Fig. 7.34. Fereastra de dialog Continue with merge

Dup confirmarea reunirii (butonul OK) modelul-surs este adugat modelului-scop, sgeata
apel dispare, iar activitatea de la care pleca sgeata apel, devine decompozabil la aceasta
se va reuni diagrama de decompoziie a primului nivel al modelului-surs. Sgeile, asociate
activitii din diagrama modelului-scop nu migreaz n mod automat n decompoziie, ci vor fi
reflectate ca nerezolvabile. Ele trebuie tunelate manual.
n procesul de reunire modelul-surs rmne neschimbat, iar n modelul-scop este inclus
copia modelului-surs. Nu trebuie confundat fuzionarea modelelor cu sincronizarea lor. Dac
modelul-surs va fi modificat ulterior, schimbrile introduse nu vor nimeri automat n ramura
respectiv a modelului-scop.
Desprirea modelelor are loc n mod analogic. Pentru desprirea unei ramuri de la model se
va face clik dreapta cu mouse-ul pe activitatea descompus (activitatea nu are liniu
diagonal de haurare n colul stnga sus) i n meniul pop-up se va selecta opiunea Split
Model. n fereastra de dialog afiat Split Options se va indica numele modelului creat. Dup
confirmarea despririi modelului n modelul vechi activitatea respectiv va deveni
nedescompus (liniua diagonal n colul stnga sus), va fi creat sgeata apel, numele ei va

coiincide cu numele modelului nou, i, n final va fi creat modelul nou n care numele
activitii de context va coiincide cu numele activitii de la care a fost rupt decompoziia.

7.4.

Crearea rapoartelor n BPwin

BPwin posed un instrument puternic de generare a rapoartelor. Rapoartele pentru un model

concret sunt apelate din opiunea Report a meniului. Exist 7 tipuri de rapoarte:

1. Model Report. Include informaii despre contextul modelului numele

modelului, punctul de vedere, domeniul, scopul, numele autorului, data crerii .a.
2. Diagram Report. Raport pentru o diagram concret. Include lista obiectelor
(activiti, sgei, depozite de date, referine externe .a.).
3. Diagram Object Report. Cel mai complet raport al modelului. Poate include lista
complet a obiectelor modelului (activiti, sgei cu indicarea tipului lor etc.) i
proprietile definite de utilizator.
4. Activity Cost Report. Raport cu rezultatele analizei costurilor. Va fi studiat mai
jos.

5. Arrow Report. Raport despre sgei. Poate include informaii din dicionarul
sgeilor, activitatea-surs, activitatea-destinaie a sgeii i informaii privind
fuzionarea i desprirea sgeilor.
6. Data Usage Report. Raport despre rezultatele legrii modelului proceselor i
modelului datelor (mai jos).
7. Model Consistency Report. Raport, care include lista erorilor sintactice ale
modelului

8. Modelarea proceselor n BPwin (partea 2)

Analiza costurilor: obiectul chetuielilor, generatorul (inductorul) chetuielilor, centrul chetuielilor. Proprieti, definite de
utilizator (UDP). Diagramele fluxurilor de date (Data Flow Diagramming): activiti, entiti externe (referine), fluxuri
de activiti, depozite de date. Metoda de descriere a proceselor IDEF3: activiti, legturi, obiectele referinelor,
intersecii. Modelarea imitaional: surse i stocuri, fire de ateptare, procese.

8.1.

Analiza costurilor

Dup cum a fost menionat anterior, mai nti este construit modelul activitilor existente n
organizaie AS-IS (cum este). Apoi are loc analiza proceselor business, fluxurile de date sunt
redirecionate, iar obiectele - perfecionate, n rezultat este construit modelul TO-BE. De obicei,
sunt construite mai multe modele TO-BE, dintre care, n conformitate cu un anumit criteriu,
este ales cel mai bun. Problema const n faptul, c exist mai multe criterii i nu este simplu
s fie ales cel mai important. Pentru a determina calitatea modelului creat, din punctul de
vedere al eficacitii proceselor business, este necesar un sistem de metrici, or calitatea
trebuie estimat cantitativ.
BPwin pune la dispoziia analitilor dou instrumente de estimare a modelului analiza
costurilor, bazate pe activiti (Activity Based Costing, ABC), i proprietile definite de
utilizator (User Defined Properties, UDP).
Analiza costurilor, bazate pe activiti ABC este o tehnologie de identificare i cercetare a
costurilor de implementare a unei funcii (activiti). Ca date iniiale pentru metoda ABC
servesc cheltuielile pentru resurse (materiale, personal .a.m.d.). n comparaie cu metodele
tradiionale de estimare a cheltuielilor, n care adesea producia creat n cantiti mici este
subestimat, iar cea n cantiti mari - supraestimat, ABC asigur o calculare mai exact a
costului produciei, bazat pe costul executrii fiecrei operaii tehnologice, care are loc la
obinerea produselor. Analiza costurilor este un acord cu privire la contabilizarea cheltuielilor
asociate activitilor, n scopul de a determina costul total al procesului. Analiza costurilor se
bazeaz pe modelul activitilor, deoarece o estimare cantitativ nu este posibil fr o
nelegere detaliat a modului de funcionare a companiei. De obicei ABC este utilizat pentru
a nelege proveniena cheltuielilor la ieire i a facilita alegerea modelului necesar al
activitilor, atunci cnd are loc reorganizarea activitii companiei (Business Process
Reengineering, BPR). Prin metoda ABC poate fi stabilit costul real al produsului, determinate
cheltuielile pentru susinerea clientului, identificate cele mai costisitoare activiti (cele care
trebuie perfecionate n primul rnd), iar managerii s fie asigurai cu instrumente performante
de estimare a modificrilor propuse.
Pentru utilizarea metodei ABC trebuie s fie nceplinite urmtoarele condiii:
modelul activitilor respect regulile sintactice IDEF0,
modelul reflect afacerea (este corect),
modelul este complet (include tot domeniul cercetat),
modelul este stabil (experitzarea nu genereaz modificri).
Cu alte cuvinte, modelul este de tip secvenial i finalizat.
Noiunile principale ale metodei ABC sunt:

obiect de costuri cauza care genereaz executarea acitivitii (de obicei ieirea
principal a activitii). Costul activitilor este costul total al obiectelor de costuri (ex.
"Asamblarea i testarea calculatoarelor", fig. 8.1);
generator (inductor) de costuri caracteristici ale intrrilor i controlului

activitii ("Comenzi ale clienilor", "Reguli de asamblare i testare", "Personalul seciei

de producere", fig. 8.1);

centre de costuri, care pot fi tratate ca articole ale cheltuielilor.

Fig.8.1. Ilustrarea termenilor metodei ABC

La lansarea procedurii de analiz a costurilor n BPwin trebuie introduse unitile de msur
pentru timp i bani. Pentru aceasta va fi afiat fereastra de dialog Model Properties (meniul
Model), pagina ABC Units (fig. 8.2).

Fig. 8.2. Introducerea unitilor de msur a timpului i valutei

Dac n list lipsete valuta necesar (de exemplu, lei), ea poate fi adugat suplimentar.
Marja de valori pentru atributul timp n lista Unit of measurment este de la secunde pn la
ani.
n continuare vor fi descrise centrele de costuri (cost centers). Pentru aceasta va fi apelat
fereastra de dialog Cost Center Editor din meniul Model (fig. 8.3).

Fig. 8.3. Fereastra de dialog Cost Center Editor

n fereastra Definition fiecare centru de cost trebuie descris detaliat. Lista centrelor de cost
este ordonat. Ordinea poate fi modificat utiliznd sgeile, plasate n stnga listei. Ordonarea
centrelor de cost faciliteaz atribuirea costurilor activitilor i are sens atunci cnd sunt
utilizate rapoarte standardizate unice n diferite modele. Dei BPwin salveaz informaiile
raportului stadard n fiierul BPWINRPT.INI, informaiile despre centrele de cost i UDP sunt
pstrate sub form de referine, adic sunt pstrate numerele centrelor, nu denumirile. Din
aceast cauz, dac este necesar de utilizat unul i acelai raport stadard n modele diferite,
listele centrelor de cost n aceste modele trebuie s fie identice.
Pentru a seta valoarea costului unei activiti (pentru orice activitate din diagrama de
decompoziie) facei clic dreapta pe activitate i din meniul pop-up, alegei Cost (fig. 8.4). n
fereastra de dialog Activity Cost este introdus frecvena acestei activiti n cadrul procesului
global (fereastra Frequency) i durata (Duration). Apoi, selectai unul din centrele de cost din
list i n fereastra Cost setai valoarea costului. n mod similar, sunt setate sumele alocate
pentru fiecare centru de cost, adic va fi setat costul fiecrei activiti pentru fiecare articol de
cheltuieli. Pentru introducerea unor centre de cost suplimentare va fi folosit fereastra de
dialog Cost Center Editor, apelat direct din dialogul Activity Properties/Cost.

Fig. 8.4. Setarea costului unei activiti din Activity Properties/Cost

Costurile totale pentru o activitate sunt calculate ca suma costurilor tuturor centrelor de cost.
La calcularea costurilor unei activiti superioare (printe) mai nti este calculat produsul
costurilor activitii descendent (fiice) cu frecvena activitii (de cte ori are loc activitatea n

cadrul unei execuii a activitii printe), dup care rezultatele sunt adunate. Dac pentru toate
activitile modelului este setat regimul Compute from Decompositions (fig. 8.4), aceste
calcule vor fi efectuate n mod automat pentru ntreaga ierarhie a activitilor de jos n sus (fig.
8.5).

Fig. 8.5. Calcularea costurilor activitii printe

Acest principiu, relativ simplu, este corect dac activitile sunt ndeplinite secvenial.
Posibiliti incorporate ale BPwin permit elaborarea unor modele simplificate, ns sunt extrem
de utile, ale costurilor pentru estimarea preliminar. Dac schema ndeplinirii activitilor este
mai complicat (de exemplu, activiti alternative), se poate refuza la calcule i seta manual
sumele de totalizare pentru fiecare activitate (Override Decompositions). n acest caz
rezultatele calculelor de la nivelele iinferioare ale decompoziiei vor fi ignorate, iar n calcule la
nivelele superioare va fi utilizat suma introdus manual. La orice nivel rezultatele calculelor
vor fi pstrate independent de regimul selectat, din care cauz la setarea opiunii Override
Decompositions, calculul de jos n sus se va produce n mod obinuit.
Pentru o analiz mai fin poate fi utilizat instrumentul specializat EasyABC (ABC Technology,
Inc.). BPwin are o interfa bidirecional cu EasyABC. Pentru exportul datelor n EasyABC va fi
selectat opiunea de meniu File/Export/Node Tree, n Export Node Tree vor fi setate
configurrile respective i va fi exportat arborele nodurilor ntr-un fiier textual (.txt). Fiierul de
export poate fi importat n EasyABC. Dup realizarea calculelor necesare datele rezultante pot
fi importate din EasyABC n BPwin. Pentru aceasta se va parcurge n meniu File/Import/Costs i
n fereastra de dialog Import Activity Costs vor fi selectate setrile necesare.
Rezultatele analizei costurilor pot influena n mod substanial ordinea de execuie a
activitilor. Presupunem, c pentru estimarea calitii unui produs sunt necesare urmtoarele
trei activiti:
inspecie vizual cost 50 ruble;
pornire de prob cost 150 rub.;
testare la stand cost 300 rub.
De asemenea presupunem, c ordinea activitilor este lipsit de importan, iar probabilitatea
de detectare a rebutului este aceeai (50%) pentru fiecare activitate. Fie c vor fi verificate 8
uniti. Dac activitile vor derula n ordinea de descretere a costurilor, atunci cheltuielile
pentru obinerea produsului finit vor fi: 300 rub.(testare la stand)*8+150 rub.(pornire de
prob)*4+50 rub.(inspecie vizual)*2=3100 rub.
Alte vor fi cheltuielile, dac activitile vor avea loc n ordinea de cretere a costurilor: 50 rub.
(inspecie vizual) *8 +150 rub. (pornire de prob) *4 + 300 rub. (testare la stand) *2 = 1600
rub.
Reiese, c pentru minimizarea cheltuielilor activitile trebuie executate n ordinea de cretere
a costurilor.
Rezultatele analizei costurilor sunt afiate ntr-un raport special BPwin, configurarea cruia are
loc n fereastra de dialog Cost Report (meniul Tools/Reports/Activity Cost Report, fig. 8.6).

Raportul permite documentarea numelui, numrului, definirea activitilor i costul activitilor,

att totale, ct i separate pe centre de costuri.

Fig. 8.6. Fereastra de dialog pentru configurarea raportului privind costul activitilor
Rezultatele vor fi afiate i direct pe diagrame. n colul stnga-jos al dreptunghiului activitii
poate fi afiat sau costul (implicit), sau durata, sau frecvena de execuie a activitii.
Configurarea are loc n dialogul Model Properties (meniul Model/Model Properties), pagina
Display (ABC Data, ABC Units).

8.2.

Proprieti definite de utilizator

Metoda ABC permite estimarea caracteristicilor temporale i de cost ale unui sistem. Dac
aceasta nu este suficient, exist posibilitatea introducerii unor metrici proprii proprieti
definite de utilizator - User Defined Properties (UDP). UDP permite efectuarea unor analize
suplimentare, dar fr calcule de totalizare.
Pentru descrierea UDP servete fereastra de dialog User-Defined Property Editor (meniul
Model/UDP Definition Editor, fig. 8.7). n partea de sus a dialogului se va introduce numele UDP,
n lista de selectare Datatype va fi descris tipul proprietii. Pot fi setate 18 tipuri de UDP,
inclusiv comenzi de administrare i masive, pe categorii. Pentru introducerea categoriei va fi
setat numele categoriei n fereastra New Keyword i va fi acionat butonul Add Category. Pentru
atribuirea proprietii unei categorii se va selecta UDP din list, apoi categoria din lista
categoriilor i se va aciona butonul Update. O categorie poate include mai multe proprieti,
iar a proprietate poate face parte din mai multe categorii. Proprietatea de tip List poate conine
un masiv de valori predefinite. Pentru stabilirea domeniului de valori UDP de tip List va fi setat
valoarea proprietii n fereastra New Keyword i acionat butonul Add Member. Valorile din
list pot fi redactate i eliminate.

Fig. 8.7. Dialogul de descriere a UDP

Fiecrei activiti se poate de pus n coresponden un set UDP. Pentru aceasta se va aciona
cu butonul dreapta pe activitate i se va selecta punctul meniului UDP. n pagina UDP Values a
dialogului IDEF0 Activity Properties pot fi setate valorile UDP. Rezultatul setrilor poate fi
analizat n raportul Diagram Object Report (meniul Tools/Report/Diagram Object Report, fig.
8.8).

Fig. 8.8. Configurarea Diagram Object Report

8.3.

Diagramele fluxurilor de date

Diagramele fluxurilor de date (Data Flow Diagramming) sunt mijlocul principal de modelare a
cerinelor funcionale ale sistemului proiectat. Cerinele sunt reprezentate sub form de
ierarhie a proceselor, legate prin fluxurile de date. Digramele fluxurilor de date arat modul n
care fiecare proces transform intrrile sale n ieiri i reflect relaiile ntre aceste procese.
Diagramele DFD sunt utilizate cu succes n calitate de complement al modelului IDEF0 pentru
descrierea managementului documentelor i prelucrrii informaiei. Ca i IDEF0, DFD prezint

sistemul modelat sub forma unei reele de activiti intercorelate. Componentele principale ale
DFD sunt procesele sau activitile, entitile externe, fluxurile i depozitele de date
(repozitoriile).
Pentru construirea diagramelor n BPwin este utilizat notaia Gane-Sarson.
Modelul IDEF0 poate fi complementat cu o diagram DFD n procesul decompoziiei prin
acionarea butonului radio DFD din fereastra de dialog Activity Box Count. n panoul
instrumental vor aprea butoane noi:
External Reference adugarea unei referine externe;
Data store adugarea unui depozit de date;
Diagram Dictionary Editor referin la alt pagin. Spre deosebire de IDEF0,
sgeata poate fi direcionat spre orice diagram (nu numai spre nivelul superior).
Sgeile DFD arat modul n care obiectele (inclusiv datele) se deplaseaz de la o activitate la
alta, spre deosebire de sgeile IDEF0, care reprezint legturi reciproce rigide. Aceast
reprezentare a fluxurilor mpreun cu depozitele de date i entitile externe fac modelele DFD
mai asemntoare cu caracteristicile fizice ale sistemului deplasarea, pstrarea, livrarea i
diseminarea obiectelor (fig. 8.9).
Dac n IDEF0 sistemul const din activiti interconectate, n DFD sistemul este privit ca set de
obiecte. Diagrama de context include adesea activitile i referinele externe. Activitile sunt
denumite, de obicei dup denumirea sistemului, de exemplu Sistem de prelucrare a
informaiei. Includerea ntr-o diagram contextual a referinelor externe nu anuleaz cerina
metodologiei de descriere clar a obiectivelor, domeniului i a punctului de vedere unitar
asupra sistemului modelat.

Fig. 8.9. Exemplu de diagram DFD

n DFD activitile (procesele) reprezint funciile sistemului, care transform intrrile n ieiri.
Dei activitile sunt prezentate prin dreptunghiuri cu colurile rotunjite, sensul lor coiincide cu
sensul activitilor din IDEF0 i IDEF3. Ca i procesele n IDEF3, activitile n DFD au intrri i
ieiri, dar nu au control i mecanisme, precum n IDEF0 (fig. 8.9).
Entitile externe reprezint intrrile sistemului i/sau ieirile sistemului. Sunt reprezentate prin
dreptughiuri cu umbre i, de obicei, sunt plasate la marginea diagramei (fig. 8.9, blocul
Sunete de la clieni). O entitate extern poate fi utilizat de mai multe ori n aceeai
diagram sau n cteva diagrame pentru a nu desena sgei prea lungi i complicate.
Fluxurile de activiti sunt reprezentate prin sgei i descriu deplasarea obiectelor n sistem.
Deoarece n DFD fiecare latur a activitii nu are o destinaie strict, precum n IDEF0,
sgeile pot intra n i iei din orice latur a dreptunghiului activitii. n DFD sunt utilizate
sgei bidirectionate pentru descrierea dialogului de tipul comand-rspuns ntre activiti,
ntre o activitate i o entitate extern sau ntre entitile externe (fig. 8.9).
Spre deosebire de sgei, care descriu obiectele n micare, depozitele de date descriu

obiectele n stare de repaus (fig. 8.10).

Fig. 8.10. Depozit de date

n sistemele materiale depozitele de date sunt reprezentate n locul n care obiectele ateapt
prelucrarea, de exemplu ntr-un fir de ateptare. n sistemele de prelucrare a informaiei
depozitele de date sunt mecanisme, care permite pstrarea datelor pentru procesele
urmtoare.
Sgeile pot s fuzioneze i s se ramifice, prin aceasta este posibil descrierea ramificrii
sgeilor.
Diagramele DFD pot fi construite utiliznd analiza structural tradiional, analogic IDEF0.
Numrul unei lucrri poate include un prefix (A), numrul activitii printe i numrul
obiectului. Numrul obiectului este numrul unic al activitii n diagram. De exemplu, o
activitatea poate avea numrul A.12.4. Depozitele de date i entitile externe de asemenea
posed numere unicale, indiferent de locul de plasare pe diagram. Fiecare depozit are prefixul
D i un numr unic, de exmpli D5. Analogic entitile externe, de exemplu E5.

8.4.

Descrierea proceselor n IDEF3

Prezena elementelor de notare a surselor, receptoarelor i depozitelor de date n diagramele

DFD permit o descriere mai eficient i mai clar a circuitului documentelor. Cu toate acestea,
pentru descrierea logicii interaciunii fluxurilor informaionale este mai potrivit notaia IDEF3,
numit de asemenea Workflow diagramming metodologia de modelare care utilizeaz o
descriere grafic a fluxurilor informaionale, relaiilor dintre procese de prelucrare a
informaiilor i obiecte - parte a acestor procese. Diagramele Workflow pot fi folosite la
modelarea proceselor-business pentru analiza nivelului de finalizare a procedurilor de
prelucrare a informaiei. Ele pot fi utilizate pentru a descrie scenariile de activitate a
angajailor, cum ar fi secvena de prelucrare a unei comenzi sau a unui eveniment, care trebuie
procesate ntr-un timp finit. Fiecare scenariu este nsoit de o descriere a procesului i poate fi
folosit pentru a documenta fiecare funcie.
IDEF3 este metoda, care are drept obiectiv principal de a permite analitilor s descrie situaia
n care procesele sunt ndeplinite ntr-o anumit ordine, precum i obiectele participante n
aceste procese.
Procedeul de descriere a setului de date n IDEF3 este parte a analizei structurale. Spre
deosebire de alte metode de descriere a proceselor IDEF3 nu limiteaz analistul prin restricii
sintactice rigide, restricii care pot coonduce la crearea unor modele incomplete sau
contradictorii.
IDEF3 poate fi utilizat de asemenea n calitate de metod de creare a proceselor. IDEF3
complementeaz IDEF0 i include tot necesarul pentru construirea unor modele, care ulterior
pot fi utilizate pentru analiza imitaional.
Fiecare activitate din IDEF3 descrie un oarecare scenariu al procesului business i poate fi parte
component a altei activiti. Deoarece un scenariu descrie obiectivul i cadrul modelului este
important ca o activitate s fie denumit folosind un substantiv verbal care indic un proces de
aciune, sau o fraz care conine un astfel de substantiv.
Punctul de vedere asupra modelului trebuie s fie documentat. De obicei va fi punctul de
vedere al persoanei responsabile de proiect n totalitate. De asemenea trebuie documentat
obiectivul modelului, adic ntrebrile la care modelul va da rspunsuri.
Diagrama este unitatea de baz n descrierea IDEF3. Construirea corect a unei diagrame are
o importan mare deoarece ele sunt destinate a fi citite de alte persoane, nu doar de autor.
Unitile de lucru - Unit of Work (UOW) denumite de asemenea activiti, sunt
componetele centrale ale unui model. n IDEF3 activitile sunt notate prin dreptunghiuri i au

nume sub form de substantiv verbal (care semnific un proces de aciune) singur sau ntr-o
fraz, i un numr (identificator). Alt substantiv n cadrul aceleeai fraze de obicei semnific
ieirea principal (rezultatul) activitii (de exemplu, Fabricarea componentei). Adesea
substantivul din cadrul numeleui unei activiti este modificat n procesul modelrii, deoarece
modelul poate fi redactat i perfectat. Identificatorul activitii este atribuit la creare i nu
poate fi schimbat. Chiar dac o activitate va fi eliminat, identificatorul ei nu va fi reutilizat
pentru alte lucrri. De obicei numrul unei activiti const din numrul activitii printe i
numrul de ordine din diagrama curent.
Legturile indic relaiile dintre activiti. Toate legturile din IDEF3 sunt unidirecionale
i pot avea orice direcie. Dar, de obicei, diagramele n IDEF3 vor fi construite n aa mod nct
legturile s fie direcionate dela stnga la dreapta. n IDEF3 exist trei tipuri de sgei, care
reprezint legturile (stilul sgeilor este stabilit din meniul Edit/Arrow Style):
Precedn (Precedence) - sgeat nentrerupt, care leag uniti de lucru (UOW). Este
desenat de la stnga la dreapta sau de sus n jos. Semnific c activitatea-surs trebuie s se
termine nainte ca activitatea-receptor s nceap.
Relaie (Relational Link) sgeat punctat, utilizat pentru reprezentarea unei legturi
ntre unitile de lucru (UOW), de asemenea i ntre uniti de lucru i obiectele referinelor.
Fluxuri de obiecte (Object Flow) sgeat cu cap dublu, utilizat pentru a reprezenta, c
obiectul este utilizat n mai mult de dou activiti, de exemplu, cnd un obiect este creat ntr-o
activitate i este untilizat n alta.
Legtura Preceden semnific, c activitatea-surs se termin naintea nceperii activitiiscop. Adesea rezultatul unei activiti-surs este un obiect, necesar pentru a lansa activitateascop. n acest caz sgeata, care semnific obiectul, va fi reprezentat cu cap dublu. Numele
sgeii trebuie s identifice clar obiectul reprezentat. Fluxul de obiecte au aceeai semantic ca
i sgeata preceden.

Relaia semnific c sgeata este alternativ pentru sgeata preceden sau fluxului de
obiecte n sensul desemnrii consecutivitii execuiei activitii activitatea-surs nu trebuie
n mod obligator s se ncheie, nainte ca activitatea-scop s nceap. Mai mult, activitateascop poate s se termine naintea ncheierii activitii-surs.
Finalizarea unei activiti poate fi semnal pentru nceperea mai multor activiti sau o activitate
poate atepta finalizarea ctorva activiti pentru a se ncepe. Pentru reflectarea logicii
interaciunii sgeilor la fuzionare sau ramificare sau pentru reflectarea unei mulimi de
evenimente, care pot sau trebuie s se termine naintea nceperii urmtoarei activiti, sunt
utilizate jonciunile (Junction). Exist intersecii de fuzionare (Fan-in Junction) i ramificare
(Fan-out Junction). Pentru introducerea unei jonciuni servete butonul (- adaug o jonciune)
din palitra instrumentelor. n dialogul Select Junction Type trebuie setat tipul jonciunii . Sensul
fiecrui tip este prezentat n tabelul 8.1.

Notar
ea

Denumirea
Asynchronous
AND
Synchronous
AND
Asynchronous
OR
Synchronous
OR
XOR

Sensul pentru cazul

fuzionrii sgeilor (Fan-in
Junction)
Toate procesele precedente
trebuie s fie ncheiate
Toate procesele precedente sunt
ncheiate simultan
Unul sau cteva procese
precedente trebuie s fie
ncheiate
Unul sau cteva procese
precedente sunt ncheiate
simultan
Numai un proces precedent este

Tabelul 8.1. Tipuri de jonciuni

Sensul pentru cazul
ramificrii sgeilor (Fan-out
Junction)
Toate procesele urmtoare
trebuie lansate
Toate procesele urmtoare sunt
lansate simultan
Unul sau cteva procese
urmtoare trebuie s fie lansate
Unul sau cteva procese
urmtoare sunt lansate simultan
Numai un proces urmtor este

(Exclusive
OR)

ncheiat

lansat

Toate jonciunile dintr-o diagram sunt numerotate, fiecare numr are prefixul J. Din dialogul
Junction Properties, apelat din meniul de context al jonciunii, opiunea Definition/Note,
proprietile unei jonciuni pot fi redactate. Spre deosebire de IDEF0 i DFD n IDEF3 sgeile
pot s se ramifice sau s se fuzioneze numai n jonciuni.
Un obiect de referire (Referent) n IDEF3 exprim o oarecare idee, concept sau date, care
nu pot fi legate cu o sgeat, intersecie sau activitate. Pentru introducerea unui obiect al

referinei servete butonul - (de adugat n diagram un referent) din palitra instrumentelor.
Referentul este notat sub form de dreptunghi, care seamn cu dreptunghiul activitii
.
Numele unui Referent este setat n dialogul Referent (opiunea Name a meniului de context). n
calitate de nume poate fi utilizat numele unei sgei oarecare dintr-o alt diagram sau numele
unei entiti din modelul datelor. Obiectele de referire trebuie s fie legate cu unitile de lucru
sau interseciile prin linii punctate. Versiunea oficial a IDEF3 include trei stiluri de obiecte de
referire necondiionate (unconditional), sincrone (synchronous) i asincrone
(asynchronous). BPwin susine doar obiectele de referire necondiionate.
La introducerea obiectelor de referire n afara numelui mai trebuie de indicat tipul lui. Tipurile
referenilor sunt prezentate n tabelul 8.2.
n IDEF3 decompoziia este utilizat pentru detalizarea activitilor. Metodologia IDEF3 termite
descompunerea multipl a unei activiti, adic o activitate poate avea o mulime de activiti
fiice. Aceasta permite ca ntr-un model s fie descrise fluxurile alternative. Posibilitatea
decompoziiei multiple impune cerine suplimentare la numerotarea activitilor. De exemplu,
numrul unei activiti va consta din numrul activitii printe, versiunii decopmpoziiei i
numrul activitii din diagrama curent.
Tabelul 8.2. Tipurile obiectelor de referire
Tip
Scopul descrierii
OBJECT
Descrie participarea unui obiect important ntr-o activitate
GOTO
Instrument pentru organizarea ciclurilor (ntr-o succesiune repetabil de
activiti), posibil n diagrama curent, dar nu obligator. Dac toate activitile
ciclului sunt prezente n diagrama curent , ciclul poate fi reprezentat printr-o
sgeat, care revine la activitatea de start. GOTO poate face referin la o
intersecie.
UOB (Unit of
Este utilizat atunci cnd este necesar s fie subliniat utilizarea multipl a unei
behaviour)
activiti, dar fr ciclu. De exemplu, activitatea Controlul calitii poate fi
utilizat n procesul Fabricarea componentei de cteva ori, dup fiecare
operaie unitar. De obicei, acest tip de referire nu este utilizat pentru
modelarea activitilor lansate n mod automat.
NOTE
Este utilizat pentru documentarea unei infirmaii importante, asociate unor
obiecte grafice din diagram. NOTE este o alternativ introducerii unui obiect
textual n diagram.
ELAB
Este utilizat pentru perfecionarea sau descrierea mai detalizat a graficelor.
(Elaboration)
De obicei este utilizat pentru descrierea detaliat a ramificrilor i fuzionarea
sgeilor la intersecii.
Considerm procesul decompoziiei unei diagrame IDEF3, care include interaciunea autorului
(analistul) i unul sau mai muli experi ai domeniului obiectiv.
naintea unei sesiuni de expertizare experilor domeniului obiectiv li se vor pune la dispoziie
scenariile documentate i graniele (cadrul) modelului pentru a putea fi nelese obiectivele
decompoziiei. De obicei, expertul domeniului obiectiv transmite analistului descrierea textual
a scenariului. Suplimentar poate exista documentaia, care descrie procesele ce prezint
interes. Din aceast informaie analistul trebuie s elaboreze lista preliminar a activitilor
(substantive verbale, care semnific proces) i al obiectelor (substantive, care semnific
rezultatul ndeplinirii activitii), necesare pentru activitile enumerate. n unele cazuri are

sens s fie creat modelul grafic pentru a fi prezentat expertului domeniului obiectiv.
n figura 8.11 este prezentat descrierea procesului Asamblarea calculatoarelor desktop n
metodologia IDEF3.
Deoarece diferite fragmente ale unui model IDEF3 pot fi create de diferite grupuri de analiti la
momente diferite de timp, IDEF3 include o simpl schem de numerotare a actvitilor n
cadrul ntregului model. Diferii analiti opereaz cu diferite intervale de numere, lucrnd
independent. Un exemplu de partajare a intervalelor de numere este prezenta n tabelul 8.3.
Tabelul 8.3. Intervale pentru numerele
activitilor
Analistul

Intervalul n IDEF3

Ivanov

1-999

Petrov

1000-1999

Sidorov

2000-2999

n rezultatul completrii diagramelor IDEF0 cu diagrame DFD i IDEF3 pot fi create modele
hibrid (mixte), care s descrie n cel mai corect mod toate aspectele activitii ntreprinderii.
Ierarhia activitilor ntr-un model mixt poate fi afiat n fereastra Model Explorer (fig. 8.12). n
notaia IDEF0 modelele sunt de culoare verde, n IDEF3 galben, n DFD azurii.

Fig. 8.11. Descrierea unui proces n IDEF3

Fig. 8.12. Prezentarea unui model mixt n Model Explorer

8.5.

Modelarea imitaional

Aspectele estimative ale modelrii domeniului obiectiv sunt legate de indicatorii de

performan ai proceselor automatizate.
Metoda modelrii funcionale permite optimizarea proceselor business dintr-o ntreprindere,
ns pentru optimizarea unor operaii tehnologice concrete ale modelului funcional aceast
metod poate fi insuficient. n aceste cazuri este recomandabil s se foloseasc metoda
modelrii imitaionale (simulrii).
Modelarea imitaional este o metod care permite construirea modelului, care ia n
consideraie timpul de execuie a operaiilor i asigur cele mai cuprinztoare mijloace de
analiz a dinamicii proceselor business. Modelele imitaionale (de simulare) descriu nu doar
fluxurile entitilor, informaiilor i controlului, dar i diferite metrici. Modelul obinut poate fi
lansat n timp i pot fi culese statistici asociate proceselor care au loc ca i cum totul s-ar
ntmpla n realitate. ntr-un model de simulare modificrile proceselor i a datelor sunt
asociate evenimentelor. Simularea pe model const n trecerea consecutiv de la un eveniment
la altul.
Legtura dintre modelele imitaionale i modelele proceselor const n posibilitatea
transformrii modelelor proceselor n modele imitaionale. Un model imitaional pune la
dispoziie mai multe informaii pentru analiza sistemului, iar rezultatele unei astfel de analize
pot cauza modificri n modelul proceselor.
Unul din cele mai eficace instrumente de modelare imitaional este sistemul ARENA, elaborat
de firma System Modeling Corporation. Sistemul permite construirea modelelor imitaionale,
realizarea unor simulri pe aceste modele i analiza rezultatelor obinute.
Un model imitaional include urmtoarele elemente de baz:
Create i Dispose . Create reprezint elementele de la care modelul primete
informaii sau obiecte. Dup sens ele sunt apropiate noiunilor referin extern din
DFD sau referent din IDEF3. Viteza sosirii datelor sau obiectelor este determinat prin
funcii statistice. Dispose este un dispozitiv de recepie a informaiei sau a obiectelor.
Queues. Noiunea de fir de ateptare este apropiat de noiune depozit de date
n DFD este locul, unde obiectele ateapt prelucrarea. Timpul de procesare a
obiectelor n diferite activiti poate fi diferit. n rezultat, n faa unor activiti se pot
colecta obiecte, care-i ateapt rndul. Frecvent, obiectivul modelrii imitaionale este

minimizarea lungimii medii a firului de ateptare.

Proces (Process) analogul activitilor n modelul proceselor. n modelarea
imitaional poate fi introdus productivitatea proceselor.
Construirea unui model const n introducerea din panoul de instrmente n spaiul de lucru a
modulelor Create, Dispose i Process. Legturile dintre module sunt setate n mod automat,
dar pot fi redefinite i manual. n continuare sunt setate proprietile modulelor. Pentru
simularea modelului trebuie introdus modulul Simulate i setai parametrii acestuia. Rezultatele
simulrilor sunt fixate n rapoarte generate automat.
BPwin nu posed instrumente proprii, care ar permite crearea modelelor imitaionale, ns
permite exportarea modelelor IDEF3 ntr-un instrument specializat n construirea acestor
modele. Pentru exportarea unui model vor fi setate proprietile, definite de utilizator UDP,
incluse n BPwin special pentru organizarea exportului.
Modelele funcionale i imitaionale sunt strns legate i se completeaz reciproc. Modelele
imitaionale pun la dispoziie mai multe informaii pentru analiza sistemelor, rezultatele creia
pot cauza modificarea proceselor. Se recomand s fie construit mai nti modelul funcional,
iar n baza lui modelul imitaional. modelul imitaional.

9. Resursele informaionale ale SI

Resursele informaionale ale SI. Resurse informaionale externe. Noiuni din clasificarea informaiei. Noiuni i cerine
principale din domeniul sistemului de codare a informaiei. Componena i coninutul operaiilor de proiectare a
clasificatoarelor. Sistemul de documentare. Resurse informaionale interne. Proiectarea formelor de ecran a
documentelor electronice. Baza informaional i metodele de organizare.

Resursele informaionale ale SI (asigurarea informaional) sunt un mijloc pentru soluionarea

urmtoarelor probleme:
reprezentarea ntr-un mod univoc i econom a informaiei n sistem (n baza
codrii obiectelor);
organizarea procedurilor de analiz i procesare a informaiei lund n
consideraie caracterul legturilor ntre obiecte (n baza clasificrii obiectelor);
organizarea interaciunii utilizatorilor cu sistemul ( n baza formelor de ecran de
intrare/ieire a datelor);
asigurarea utilizrii eficiente a informaiei n conturul gestiunii activitii
obiectului automatizrii (n baza sistemului unificat de documentare).

Resursele informaionale ale SI includ dou categorii de componente: resursele informaionale

externe (clasificatoare ale informaiei tehnico-economice, documente, materiale metodice i
instructive) i resursele informaionale interne (machete/forme de ecran pentru introducerea
datelor primare n calculator sau extragerea informaiei, structuri ale bazei informaionale : ale
fiierelor de intrare, de ieire, bazei de date).

Resursele informaionale trebuie s respecte urmtoarele cerine de ordin general:

suficien pentru a susine toate funciile automatizate ale obiectului;
utilizarea clasificatoarelor agreate de beneficiar;
pentru codarea informaiilor de intrare i ieire, utilizate la nivelul superior al
managementului, trebuie s fie utilizate clasificatoarele acestui nivel;
asigurarea compatibilitii cu resursele informaionale ale sistemelor, care
interacioneaz cu sistemul elaborat;
formele documentelor trebuie s respecte exigenele standardelor corporative
ale beneficiarului (sau sistemului unificat de documentare);
structura documentelor i a formelor ecran trebuie s corespund
caracteristicilor terminalelor de la posturile de lucru ale utilizatorilor finali;
graficul formrii i coninutul mesajelor informaionale, ca i abrevierile utilizate,
trebuie s fie unanim acceptate n domeniul obiectiv i coordonate cu beneficiarul;
n SI vor fi prevzute mijloace de verificare i control a informaiilor, de
actualizare a datelor masivelor informaionale, controlul integritii bazei

informaionale , proteciei contra accesului nesancionat.

Resursele informaionale pot fi definite ca set care include sistemul unificat de clasificare,
sistemul unificat de documentare i baza informaional.

9.1.

Resurse informaionale externe

9.1.1.

Noiuni din domeniul clasificrii informaiei tehnico-economice

n interiorul calculatorului i pentru transmiterea prin canalele de comunicaie informaia este

digitizat. Pentru aceasta informaia va fi mai nti ordonat (clasificat), apoi formalizat
(codificat) utiliznd clasificatorul respectiv.
Clasificarea este operaia i metoda logic prin care obiectele dintr-o mulime dat sunt
distribuite n submulimi numite clase n funcie de asemnrile i deosebirile dintre ele.
Compararea obiectelor se face dintr-un anumit punct de vedere, numit criteriu. Clasificarea
surprinde legturile naturale ntre categoriile obiectelor. Un obiect este orice element, proces,
fenomen material sau nematerial. Sistemul de calsificare permite gruparea obiectelor i
evidenierea anumitor clase, care vor fi caracterizate de o serie de caracteristici comune.
Setul de reguli, utilizat la mprirea obiectelor unei mulimi n submulimi se
numete sistem de clasificare.
n calitate de criteriu al clasificrii este folosit o proprietate sau o caracteristic a obiectului

clasificrii, care permite stabilirea asemnrii sau diferenierii lui de alte obiecte. De exemplu,
criteriul rolul ntreprinderii-partener n activitatea obiectului automatizrii permite separarea
tuturor ntreprinderilor n dou grupuri (dou submulimi): furnizori i consumatori. Mulimea
sau submulimea, obinut prin combinarea unei pri a obiectelor clasificate conform unui
criteriu sau conform mai multor criterii, este numit grup de clasificare.
Conform criteriul gradul de corespundere realitii exist clasificri:
naturale descrie clasele asa cum sunt n realitate;
artificiale red clasele aa cum sunt utile unor activiti.
Dup rigoarea criteriului de clasificare exist clasificare:
teoretic d clase reale i posibile;
empiric red numai clase reale.
I n funcie de natura obiectelor clasificarea poate fi:
exact plaseaz fiecare obiect al universului de clasificat ntr-o clas despre
fiecare putnd spune crei clase i aparine;
inexact deriv din imposibilitatea distinciei proprietii la obiect pentru a-l
putea plasa sigur ntr-o clas.
Dup numrul criteriilor exist clasificri monocriteriale i multicriteriale.
Clasificatorul este un document cu ajutorul cruia este realizat descrierea formalizat n
sistemele informaionale, descriere care include denumirea obiectelor, denumirea grupurilor de
clasificare i codurile lor.
Conform criteriul domeniul de aplicare exist clasificatoare internaionale , naionale

(sistemice), sectoriale i locale .

Clasificatoarele internaionale sunt parte a Sistemului de standarde economice internaionale

i sunt obligatorii la transferul informaiilor ntre diferite ri ale comunitii mondiale.
Clasificatoarele naionale sunt obligatorii pentru organizarea procesului de transfer i
procesarea informaiei ntre sistemele economice la nivelul unui stat n interiorul rii.
Clasificatoarele sectoriale sunt utilizate pentru executarea procedurii de prelucrare a
informaiei i transferul ei ntre organizaiile unei ramuri economice.
Clasificatoarele locale sunt utilizate n limitele unei organizaii.
Clasificarea este o operaie ce se aplic asupra obiectelor, noi strduindu-ne s obinem clase
reale sau cel puin posibile. Fiecrei clase obinute i se asociaz o noiune i respectiv un
nume. Sistemului de clase reale sau posibile i asociem un sistem de noiuni, respectiv de
nume. Sistemul de noiuni red aproximativ sistemul de clase reale sau posibile. Se impune s
nu fie confundate clasificarea obiectelor cu clasificarea noiunilor . Noiunile nu posed
proprietile obiectelor i deci asupra noiunilor nu se poate face aceeai clasificare.
Se pornete de la tipul ideal de clasificare care trebuie s indeplineasc urmtoarele condiii:
1. Orice obiect din universul supus clasificrii satisface principiul teriului exclus n
raport cu proprietile invocate. n acest sens oricare obiect din mulimea iniial ori
posed ori nu posed proprietatea considerat drept criteriu de mprire a obiectelor n
clase, a treia posibilitate fiind exclus.
2. Clasificarea este complet. Fiecare obiect din universul de clasificare este inclus
n una din clasele rezultate. Clasificarea nu las rest.
3. Clasele se exclud ntre ele. Nici-un obiect inclus ntr-o clas nu este inclus i n
alt clas. Nici-o clas nu include nici parial nici total alt clas. Nici-o clas nu este
inclus nici parial nici total n alt clas.
4. Suma claselor rezultate este identic cu universul de clasificat. Suma claselor

rezultate nu este nici mai mic nici mai mare dect mulimea iniial de obiecte care a
fost supus clasificrii.
n practica logic ne confruntm cu abateri astfel ca:
1. la regula teriului exclus ne ntlnim cu mulimile vagi;

2. la regula completitudinii clasificrii ne confruntm cu mulimile infinite;

3. la regula excluziunii claselor ntlnim cazurile nedefinite (intermediare);
4. regula identitii sumei claselor cu universul clasificat este alterat de problema
infinitului.
Un sistem de clasificare este caracterizat de urmtoarele proprieti:

Flexibilitatea sistemului de clasificare - posibilitatea de a permite includerea

de noi caracteristici, obiecte fr a distruge structura clasificatorului. Flexibilitatea
necesar este determinat de durata de via a sistemului.
Capacitatea - cel mai mare numr de grupuri de clasificare permise n acest
sistem de clasificare.
Gradul de ocupare este raportul dintre numrul real de grupuri i
capacitatea sistemului de clasificare.
Mai frecvent sunt utilizate dou categorii de sisteme de clasificare: clasificarea ierarhic i
clasificarea multidimensual.
La utilizarea metodei ierarhice de clasificare are loc divizarea succesiv a mulimii obiectelor n
grupuri de clasificare subordonate, depenedente. Schema de clasificare, obinut n baza
acestui proces are o structur ierarhic. n cadrul acestei structuri volumul iniial al obiectelor
clasificate este divizat n submulimi n conformitate cu un criteriu oarecare i este detalizat
pentru fiecare nivel ulterior de clasificare. Imaginea generalizat a sistemului de clasificare
ierarhic este prezentat n figura 9.1.

Fig. 9.1. Schema clasificrii ierarhice

Sistemele ierarhice de clasificare posed urmtoarele trsturi caracteristice:
Posibilitatea utilizrii unui numr nelimitat de criterii de clasificare;
Subordonarea criteriilor de clasificare, exprimat prin divizarea fiecrui grup de
clasificare, creat conform unui criteriu, ntr-o mulime de grupuri de clasificare n
conformitate cu un criteriu subordonat (de nivel mai jos).
Astfel, schemele de clasificare, construite n baza principiului ierarhic, au capacitate nelimitat,
valoarea creia depinde de adncimea clasificrii (numrul de nivele) i numrul de obiecte
care pot s fie incluse la fiecare nivel de clasificare. Numrul obiectelor unui nivel de clasificare
este determinat de baza codului numrul simbolurilor n alfabetul codului. De exemplu, dac

n calitate de alfabet sunt alese numerele zecimale din dou cifre, atunci la un nivel de
clasificare pot fi incluse maximum 100 de obiecte. Alegerea adncimii clasificrii i a structurii
codului depinde de caracterul obiectelor clasificrii i al problemelor, pentru soluionarea
crora este destinat clasificatorul.
La construirea unui sistem ierarhic de clasificare mai nti are loc alegerea mulimii obiectelor
clasificrii, pentru care este determinat setul complet de criterii de clasificare i subordonarea
lor reciproc, dup care are loc divizarea mulimii iniiale n grupuri de clasificare pentru fiecare
nivel.
Avantajele sistemului ierarhic constau n coerena logic, simplitatea construirii i comoditatea
procesrii logice i aritmetice.
Un dezavantaj important al metodei ierarhice const n rigiditatea schemei de clasificare.
Rigiditatea este generat de alegerea pre-stabilit a criteriilor i ordinea de utilizare a acestora
pe nivelele de clasificare. Aceasta conduce la faptul, c la modificarea componenei obiectelor
clasificrii, caracteristicilor sau caracterului problemelor soluionate cu ajutorul clasificatorului,
este necesar modificarea fundamental a sistemului de clasificare. Flexibilitatea acestui
sistem este asigurat doar prin introducerea unei redundane nalte n ramuri, ceea ce conduce
la diminuarea gradului de completare a structurii clasificatorului. Din aceast cauz, la
elaborarea clasificatoarelor trebuie s se in cont de faptul, c metoda ierarhic este preferat
pentru obiecte i probleme relativ stabile (din punctul de vedere al criteriilor de clasificare).
n figurile 9.2 i 9.3 sunt prezentate exemple de utilizare a clasificrii ierarhice a obiectelor unui
sistem informaional corporativ. Utilizarea acestor modele permite codificarea informaiei
asociat obiectelor respective, ca i utilizarea procedurilor de generalizare la procesarea
datelor (pentru analiza cheltuielilor aferente salariilor locul de lucru al angajatului, la analiza
cheltuielilor de producere grupuri de materiale: metal, componente achiziionate etc.).

Fig. 9.2. Structura organizaional a departamentului livrri

Fig. 9.3. Exemplu de clasifcator al resurselor materiale

Neajunsurile, semnalate n sistemul ierarhic, lipsesc n alte sisteme din categoria celor de
clasificare multidimensional.
Un sistem de clasificare multidimensional folosete simultan cteva criterii independente
n calitate de fundament al clsificrii. Exist dou categorii de sisteme de clasificare
multidimensional: tip faet i tip descriptor. Faeta este aspect al clasificrii, utilizat
pentru crearea grupurilor independente de clasificare. Descriptorul este un cuvnt-cheie, care
definete o oarecare noiune, care descrie obiectul i desemneaz apartenena acestui obiect
la o clas, la un grup etc.
Prin metod de clasificare tip faet nelegem divizarea paralel a unei mulimi de obiecte n
grupuri independente de clasificare [22]. n aceast metod nu exist scheme rigide sau
grupuri finale rigide create anticpat. Este elaborat doar un sistem de tabele ale criteriilor
obiectelor clasificrii, numite faete. Atunci cnd apare necesitatea crerii unui grup de
clasificare pentru soluionarea unei probleme concrete sunt alese criteriile necesare din cele
existente, care vor fi ordonate ntr-o anumit ordine. Forma general a clasificrii de tip faet
este prezentat n fig. 9.4.

Fig. 9.4. Schema criteriilor clasificrii de tip faet

n cadrul unei faete valorile criteriilor pot fi enumerate ntr-o oarecare ordine sau pot forma o
structur ierarhic complicat, dac exist subordonarea criteriilor selectate.
Avantajele acestui sistem de clasificare constau n capacitatea mare i nivelul nalt de
flexibilitate, deoarece la necesitate pot fi introduse faete noi i poate fi modificat locul lor n
cadrul formulei. La schimbarea caracterului problemelor sau caracteristicilor obiectelor
clasificrii sunt elaborate noi faete sau sunt complementate cu noi criterii faetele existente
fr restructurarea substanial a ntregului clasificator.
La neajunsuri poate fi menionat complexitatea structurii i gradul sczut de ocupare al
sistemului.
n sistemele moderne de clasificare sunt frecvent utilizate ambele metode de clasificare.
Aceasta diminueaz dezavantajele metodelor i extinde posibilitile utilizrii clasificatoarelor
n asigurarea informaional a gestiunii.
n calitate de exemplu de utilizare a schemelor mixte de clasificare n sistemele informaionale
corporative aducem urmtorul model de descriere a produciei unei ntreprinderi.

9.1.2.

Reguli de clasificare a produselor

Este adoptat clasificarea produselor finite conform urmtoarele nivele (clasificare ierarhic):
familia produselor;
grupul produselor;
seria produselor.
ns acest sistem de clasificare nu asigur identificarea tuturor produselor finite. Pentru fiecare
unitate de produs mai trebuie indicate urmtoarele atribute (faete):
codul seriei produsului;
parametrii de configurare;
proprieti.
Codul seriei este un cod alfa-numeric, care identific n mod univoc un produs finit. Parametrii
de configurare sunt proprieti, valoarea crora poate varia n dependen de necesitile
utilizatorului. Proprietile sunt caracteristici predefinite ale produselor, care nu pot s se
modifice pentru unul i acelai produs finit.
n fig. 9.5 sunt prezentate variante posibile ale codului seriei pentru diferite produse.
Valori ale faetei Parametri de configurare pentru o familie de produse finite sunt prezentate
n tabelul 9.1.

S
Fig. 9.5. Variante de serii de cod (elementele lips sunt de culoare gri)
Sistemele de clasificare prezentate sunt foarte potrivite pentru organizarea cutrilor n scopul
executrii operaiilor logice i aritmetice de procesare a informaie pe calculator, dar rezolv
doar parial problema cutrilor contextuale a informaiei pentru adoptarea deciziilor
manageriale.
Tabelul 9.1. Valori ale faetei "Parametri de configurare"
Produse finite i
modificri
Senzor de presiune
diferenial
Senzor de presiune
absolut,
manometru, vid,
presiune-vid

Caractersitici
Generale pentru ntrega familie
siguran intrinsec
anti-explozie
materiale de performan
climatic
eroarea maxim admis
limita superioar de
msurare
codul semnalui de ieire

Speciale pentru modele separate

Presiune maxim
admisibil

Parametru msurat

componena setului de

montare

Pentru cutarea contextual a indicatorilor i documentelor este utilizat un limbaj informaional

de tip descriptor, caracterizat de un set de termeni (descriptori) i de relaii ntre termeni.
Coninutul documentelor sau indicatorilor poate fi reflectat suficient de exact i complet cu
ajutorul liste de cuvinte-cheie descriptori. Descriptorul este un termen al limbajului natural
(cuvnt sau fraz), utilizat la descrierea documentelor sau indicatorilor, care are sens
independent i, dac valoarea sa nu este modificat, este indivizibil.
Pentru asigurarea exactitii i univocitii cutrii cu ajutorul limbajului de tip descriptor vor fi
mai nti identificate toate relaiile permanente dintre termeni: relaii de tip i gen, de
sinonimie, omonimie i polisemie, ca i relaiile asociative.
Toate relaiile identificate vor fi descrise n dicionarul sistemic al noiunilor tezaurul, care
este elaborat n scopul indexrii documentelor, indicatorilor i interpelrilor informaionale.

9.1.3.

Codificarea informaiei tehnico-economice

Pentru formalizarea total a informaiei clasificarea simpl nu este suficient, din care cauz
are loc urmtoarea procedur, numit codificare. Codificarea este procesul de atribuire a unor
notaii convenionale obiectelor i grupurilor de clasificare n conformitate cu sistemul de
codificare ales. Codificarea realizeaz transformarea informaiei, exprimate ntr-un sistem de
simboluri, n alt sistem, adic convertirea reprezentrii unei nregistrri dintr-un limbaj natural
ntr-o reprezentare folosind codurile. Ca parte integrat a prelucrrii informaiilor cu ajutorul
calculatorului, codificarea urmrete transpunerea informaiei din forma ei primar ntr-o form
accesibil calculatorului. Mecanismul codificrii trebuie s fie simplu, astfel nct s poat fi
automatizat eficient.
Sistemul de codificare este setul de reguli pentru notarea obiectelor i grupurilor cu
utilizarea codurilor. Codul este notaia convenional a obiectului sau grupului n form de
simbol sau grup de simboluri n conformitate cu sistemul adoptat. Codul este bazat pe un
alfabet determinat (mulime de simboluri). Numrul de simboluri al acestei mulimi se numete
baza codului. Exist alfabete numerice, literale i mixte (alfanumerice).
Strict matematic codificarea este definit dup cum urmeaz.
Notm prin S = {s1, s2,, sp} mulimea simbolurilor primare de informaie. Dup caz, S poate
fi mulimea caracterelor ce se pot tipri, o mulime de cuvinte dintr-un anumit limbaj sau dintro limb, o submulime finit de numere, etc.
Notm prin A = {a1, a2,, ap} alfabetul codificrii, n care elementele ai le vom numi litere.
Cu ajutorul literelor alfabetului A, elementele mulimii S vor fi reprezentate ntr-o nou form,
forma codificat. Vom nota prin An mulimea tuturor cuvintelor de lungime n formate cu litere
din A: An = {w|w = ai1, ai2,, ain, aij A, i, j = 1n}. Prin A+ vom nota mulimea tuturor
cuvintelor ce se pot forma cu litere din A: A+ = A A2 A3... An ...

Definiie. O aplicaie injectiv C : S A+ se numete codificare a simbolurilor din S sau cod.

Un cod pentru care toate cuvintele de cod au aceeai lungime n se numete uniform, iar n se
numete lungimea codului. I n acest caz avem C : S An. Codurile care nu sunt uniforme se
numesc coduri neuniforme.
Un cod este caracterizat cu ajutorul urmtorilor parametri:
lungime;
baza codificrii;
structura repartizarea simbolurilor pe criterii i obiecte ale clasificrii;
gradul de informativitate - raportul dintre numrul total de criterii i lungimea
codului
coeficientul de redundan raportul dintre numrul maxim de obiecte posibil a
fi codificate i numrul real al obiectelor.
Metodele de codificare trebuie s respecte anumite cerine:
codul trenuie s realizeze identificarea obiectului n limitele mulimii date de
obiecte ale clasificrii;
se recomand utilizarea literelor i cifrelor n calitate de alfabet al codului;
se va stabili un compromis acceptabil ntre lungimea minim a codului i
redundan suficient pentru codificarea obiectelor noi fr modificarea structurii
clasificatorului.
Metodele de codificare pot avea caracter independent metode de codificare de tip
nregistrare, sau pot fi bazate pe o clasificare prealabil a obiectelor metode de codificare
clasificaionale.

Exist dou tipuri de metode de tip nregistrare: numr de ordine i serii de numere de ordine.
n primul caz n calitate de cod servesc numerele naturale. Fiecare obiect al mulimii clasificate
este codificat prin atribuirea numrului de ordine curent. Aceast metod de codificare asigur
o durat lung de via a clasificatorului, avnd o redundan nesemnificativ. Este foarte
simplu, utilizeaz cele mai scurte coduri i asigur univocitatea fiecrui obiect al clasificrii.
Suplimentar, este asigurat cel mai simplu mod de atribuire a codurilor obiectelor noi, care apar
pe parcursul mentenanei clasificatorului. Un dezavantaj semnificativ al acestei metode este
lipsa informaiilor referitoare la proprietile obiectlui.
n metoda utilizrii seriilor de numere de ordine n calitate de coduri servesc numerele naturale
cu fixarea anumitor serii ale acestor numere (intervale de numere naturale) dup obiectele
clasificrii, care prezint caracteristici comune. Pentru fiecare serie, n afara codurilor
obiectelor existente, este preconizat un anumit numr de coduri de rezerv.
Metodele clasificaionale sunt utilizate pentru reflectarea interdependenelor clasificaionale
ale obiectelor i grupurilor de obiecte, i sunt folosite pentru procesarea logic complex a
informaiilor economice. n dependen de sistemul de clasificare, utilizat pentru ordonarea
obiectelor, grupul sistemului de codificare clasificaional poate fi divizat n dou subgrupuri:
sistemele de codificare secvenial i de codificare paralel.
Sistemele de codificare secvenial sunt bazate pe clasificarea prealabil ierarhic. Codul
obiectului clasificrii este format utiliznd codurile grupurilor repartizate succesiv (adiacente),
obinute n rezultatul codificrii ierarhice. n acest caz, codul unui grup inferior este format prin
adugarea numrului respectiv de ranguri la codul grupului superior.
Sistemele de codificare paralel sunt bazate pe sistemul de clasificare tip faet, iar
codurile grupurilor sunt formate independent unele de altele. Sunt posibile dou variante de
formare a codurilor obiectelor:

1. Fiecare faet i caracteristic n interiorul faetei au coduri proprii, incluse n

codul obiectului. Aceast variant este utilizat n cazul n care obiectele sunt
caracterizate folosind numere diferite de criterii. La formarea codului unui obiect vor fi
utilizate doar criteriile necesare.
2. Pentru determinarea grupurilor de obiecte este ales un set fix de criterii i
stabilit o ordine strict a criteriilor.
Avantajele metodei paralele constau n flexibilitatea structurii codului, datorat independenei
criteriilor, din codurile crora este construit codul obiectului clasificrii. Metoda permite
utilizarea doar a caracteristicilor (criteriilor necesare) obiectului, ceea ce permite minimizarea
lungimii codului. Poate fi realizat gruparea obiectelor conform oricror combinaii ale
criteriilor. Este uor de adaptat pentru procesarea pe calculator a informaiei. Folosind codul
este uor de stabilit setul de caracteristici ale obiectului. Setul de criterii poate fi uor extins.
Este o proprietate a metodei de codicare paralel foarte important la soluionarea
problemelor tehnico-economice, componena crora sufer modificri frecvente.

9.1.4.

Sistemul unificat de documentare

Sistemul de documentare este componenta principal a resurselor informaionale externe,

utilizat n procesul de management al obiectelor economice.
Prin document nelegem un set determinat de informaii, utilizat pentru soluionarea
problemelor tehnico-economice, nscris pe un suport material ntr-un format prestabilit.
Sistemul de documentare este un set de documente legate reciproc, utilizate n mod regulat n
procesul de management al unui obiect economic. Diversitatea tipurilor de documente
reprezint trstura caracteristic a unui sistem de documentare.
Caracteristic pentru sistemele de documentare din sistemele informaionale neautomatizate
este numrul mare de diferite forme de documente, volumul uria al fluxurilor de documente
confuze, redundana excesiv a informaiilor i activitilor de procesare a acestora i nivelul

sczut al corectitudinii rezultatelor. n scopul simplificrii sistemului de documentare sunt

utilizate urmtoarele dou abordri:
unificarea i standardizarea documentelor;

introducerea tehnologiilor de calculator (fr hrtie), bazate pe documentele

electronice.
Unificarea documentelor este realizat prin introducerea unor forme comune de documente. n
consecin, este realizat uniformizarea denumirilor indicatorilor, unitilor de msur i
termenilor, ajungndu-se la sistemul unificat de documentare.
Sistemul unificat de documentare (SUD) este un complex de documente interdependente,
organizate n mod raional, care respect aceleai cerine i reguli i ofer informaiile necesare
pentru a administra o entitate economic. Pe niveluri de management, acestea sunt mprite
n sisteme de documentare intersectorial, sectorial i local.
Orice tip de SUD trebuie s respecte urmtoarele cerine:
documentele, care fac parte dintr-un SUD trebuie s fie elaborate lund n
consideraie utilizarea lor n diferite sisteme informaionale, care interacioneaz;
un SUD trebuie s conin informaii complete necesare pentru gestiunea
optimal a obiectului pentru care este elaborat;
SUD trebuie s fie orientat spre utilizarea tehnicii de calcul pentru colectarea,
procesarea i transferul informaiei;
SUD trebuie s asigure compatibilitatea informaional pe diferite nivele;
toate documentele unui SUD, ca i toate rechizitele-criterii din ele, trebuie s fie
codificate utiliznd clasificatoare internaionale, sistemice sau locale.

9.2.

Resurse informaionale interne

I n categoria resurselor informaionale interne sunt incluse machetele (formele de ecran)

pentru introducerea datelor primare n calculator sau extragerea informaiei rezultante i
structurile bazei informaionale : fiierele de intrare, de ieire, bazele de date.

9.2.1.

Proiectarea formelor de ecran

Forma electronic a unui document este o pagin (un formular) cu cmpurile goale, pentru a fi
completate de utilizator. Formele admit tipuri diferite pentru informaia de intrare i includ
butoane de control, butoane de tip radio sau boxe de bifare, meniuri pop-up etc.
Formele documentelor electronice sunt create utiliznd resurse program speciale. n figura 9.6
sunt prezentate elementele-tip principale ale unui document electronic, utilizarea crora poate
fi ntlnit n majoritatea instrumentelor CASE.

Fig. 9.6. Elementele unui document electronic

Ca neajunsuri pentru documentele electronice poate fi menionat cadrul juridic insuficient
privind aprobarea sau semnarea lor.
Tehnologia procesrii documentelor electronice solicit utilizarea unor resurse program
specializate programe de management al documentelor, adesea incluse n SI corporative.
Proiectarea formelor documentelor electronice sau construirea ablonului unei forme
folosind resurse program ndeplinirea urmtorilor pai:

crearea structurii documentului electronic pregtirea imaginii exterioare

utiliznd instrumente grafice de proiectare;
determinarea coninutului formei documentului electronic, adic alegerea
modului n care vor fi completate cmpurile. Cmpurile pot fi completate manual sau
prin alegerea valorilor dintr-o list, meniu, baz de date;
identificarea listei machetelor formelor de ecran pentru fiecare lucrare
va fi analizat enunul problemei unde apar listele documentelor de intrare cu informaii
operative sau constante i documentele cu informaiile rezultante;

identificarea coninutului machetelor are loc n baza analizei rechizitelor

documentelor primare cu informaii operative sau constante i documentele rezultante.

Totul se va finaliza cu programarea machetelor formelor de ecran elaborate i aprobarea lor.

9.2.2.

Baza informaional i metodele de organizare

Baza informaional este o colecie de date, organizat ntr-un anumit fel i pstrat n
memoria sistemului de calcul sub form de fiiere, utilizate pentru satisfacerea necesitilor
informaionale ale proceselor de management i problemelor soluionate.
Fiierele bazei informaionale pot fi clasificate conform urmtoarelor criterii:
etapa procesrii de intrare, de baz i rezultante;

 tipul suportului de memorie - suport intermediardischete i benzi

magnetice, suport principaldisc rigid, discuri magnitooptice etc.;

componena informaiei fiiere cu informaii operative i cu informaii

constante;

destinaia conform tipului subsistemelor funcionale;

organizarea logic structur liniar sau ierarhic a nregistrrilor, relaionale,
tabelare;
organizarea fizic fiiere cu acces secvenial, indexate i cu acces direct.
Fiierele de intrare sunt create din documentele primare de introducere a datelor sau n
rezultatul actualizrii fiierelor principale.
Fiierele rezultante sunt destinate extragerii informaiilor (imprimarea) sau transmiterea prin
canale de comunicaie.
n categoria fiierelor principale, pstrate n baza informaional, sunt incluse fiierele de baz,
de lucru, intermediare, de serviciu i de arhiv.
Fiierele de baz posed o structur uniform a nregistrrilor i pot conine nregistrri cu
informaii operative sau convenional-constante. Fiierele operative pot fi create n baza unui
fiier de intrare (sau mai multe) i reflect informaia unui document primar (sau mai multe).
Fiierele cu informaii convenional-constante pot include informaii de ajutor, informaii
privind preurile, tabelare i alte forme de informaii, care se modific pe parcursul unui an nu
mai mult de 40%, sau cu coeficientul de stabilitate mai mare de 0,6.
Fiierle cu informaii de ajutor reflect toate caracteristicile elementelor producerii materiale
(fonduri, materiale, materie prim, resurse de munc etc.). De obicei, dicionarele conin
informaiile clasificatoarelor i date suplimentare despre elementele sferei materiale, de
exemplu date despre preuri. Fiierele normative-de preuri includ date privind cheltuielile,
costurile operaiilor i preurile serviciilor. Fiierele tabelare includ indicatorii economici,
considerai constani pentru perioade ndelungate de timp.
Fiierele de lucru sunt create pentru soluionarea unor probleme concrete pe baza fiierelor
principale prin selectarea unor pri de informaii din diferite fiiere principale n scopul
diminurii timpului de procesare a datelor.
Fiierele intermediare se deosebesc de fiierele de lucru prin faptul, c ele sunt create n
rezultatul soluionrii problemelor economice, sunt pstrate cu scopul utilizrii ulterioare
pentru soluionarea altor probleme. Dac frecvena de adresare la aceste fiiere, ca i la
fiierele de lucru, este mare, ele pot fi trecute n categoria fiierelor principale.
Fiierele de serviciu sunt destinate pentru accelerarea cutrii informaiei n fiierele principale
i includ dicionarele, fiierele indexate i cataloagele.
Fiierele de arhiv includ date retrospective din fiierele principale, utilizate pentru
soluionarea unor probleme analitice, cum ar fi prognozarea. Pot fi de asemenea utilizate
pentru restabilirea bazei informaionale n cazul unor accidente.

9.2.3.

Cerine i metode de organizare a pstrrii fiierelor

Organizarea pstrrii fiierelor n baza informaional trebuie s respecte urmtoarele cerine:

completitudinea informaiilor pstrate, necesar pentru ndeplinirea tuturor
funciilor de management i soluionare a problemelor economice;
integritatea informaiilor pstrate;
sincronizarea procesului de actualizare pentru toate copiile datelor;

 flexibilitatea sistemului, adic adaptarea bazei informaionale la necesitile

informaionale variabile;
realizabilitate, care asigur nivelul solicitat al complexitii structurii bazei
informaionale;
relevan prin care se subnelege capacitatea sistemului de a realiza cutarea i
a pune la dispoziie informaii, care s corespund exact solicitrilor utilizatorilor;
comoditatea interfeei limbajului de formare a interpelrilor;
diferenierea drepturilor de acces.
Exist urmtoarele metode de organizare a bazei informaionale:
set de fiiere locale, meninute de pachete funcionale de programe aplicative;

baz de date integrat, bazat pe utilizarea unor instrumente program

universale de ncrcare, pstrare, cutare i introducere a datelor, adic sisteme de
gestiune a bazelor de date (SGBD).
Datorit specializrii structurii datelor pentru o problem concret fiierele locale asigur, de
obicei, o vitez mai mare de prelucrare a datelor. ns neajunsurile fiierelor locale, legate de
gradul nalt de redundan a datelor, iar n rezultat i probleme legate de sincronizare,
anuleaz toate avantajele menionate. Din aceast cauz organizarea fiierelor locale poate fi
recomandat doar n aplicaii specializate, care solicit viteze foarte mari.
Baza informaional integrat, adic baza de date (BD) este un set de date
interdependente, pstrate mpreun, cu o redundan minim, care permite utilizarea datelor
pentru o mulime de aplicaii.
Centralizarea managementului datelor cu ajutorul SGBD asigur compatibilitatea acestor date,
diminuarea redundanei sintactice i semantice, conformitatea datelor strii reale a obiectului,
partajarea pstrrii datelor ntre utilizatori i posibilitatea conectrii unor noi utilizatori. ns
centralizarea gestiunii i integrarea datelor creaz probleme de alt caracter: necesitatea
sporirii controlului datelor introduse, asigurarea consensului ntre utilizatori privind
componena i structura datelor, diferenierea accesului i confidenialitatea datelor.

10.

Modelarea resurselor informaionale

Modelarea datelor. Metoda IDEFI. Reprezentarea modelelor datelor cu ajutorul instrumentului

ERwin. Interfaa ERwin. Nivelele reprezentrii modelului. Crearea modelului logic: nivele;
entiti i atribute; legturi; tipuri de entiti i ierarhia motenirii; chei, normalizarea datelor;
domenii. Crearea modelului fizic: nivele; tabele; reguli de validare i valori implicite; indeci;
trighere i proceduri; proiectarea depozitelor de date; calcularea volumului bazei de date;
proiectarea direct i invers. Generarea codului prii client n ERwin: atribute extinse;
generarea codului n Visual Basic. Crearea rapoartelor. Generarea dicionarelor.

10.1.

Modelarea datelor

Baza informaional este una din prile principale ale resurselor informaionale. Dup cum a
fost definit anterior, baza informaional este setul de date, organizat ntr-un mod anumit i
pstrat n memoria sistemului de calcul sub form de fiiere, cu ajutorul crora sunt
satisfcute necesitile informaionale ale managementului i problemelor soluionate.
Elaborarea bazei de date are loc folosind modelarea datelor. Scopul modelrii datelor const
n punerea la dispoziia dezvoltatorului SI a schemei conceptuale a bazei de date sub forma
unui model sau cteva modele locale, care pot fi uor reflectate n orice sistem de baze de
date. Diagramele entitate relaie (ERD) sunt cel mai rspndit instrument de modelare a
datelor. Cu ajutorul ERD sunt detalizate depozitele de date n diagramele DFD, documentate
aspectele informaionale ale sistemului, inclusiv identificarea obiectelor, importante pentru
domeniul obiectiv (entitile), proprietilor acestor obiecte (atributelor) i legturilor lor cu
alte obiecte (relaii).

10.1.1.

ERD: noiuni de baz

Entitatea (Entity) este mulimea exemplarelor obiectelor reale sau abstracte (persoane,
evenimente, stri, idei, obiecte etc.), care posed aceleai atribute sau caracteristici. Orice
obiect al sistemului poate fi reprezentat printr-o singur entitate, identificat n mod unic.
Numele entitii nu va fi legat de un exemplar (instan) concret al obiectului, ci va reflecta
tipul sau clasa lui (de exemplu AEROPORT, dar nu VNUCOVO).
Fiecare entitate va poseda un identificator unic. Fiecare exemplar al entitii va fi identificat
n mod univoc i se va deosebi de alte exemplare ale acestui tip de entitate. Fiecare entitate
va poseda anumite proprieti:
nume unic; un nume va fi interpretat ntotdeauna n acelai mod; o interpretare
nu poate fi aplicat pentru diferite nume, dac acestea nu sunt pseudonime;
s posede unul sau cteva atribute, care sau aparin entitii, sau sunt
motenite;
s posede unul sau cteva atribute, care identific n mod univoc fiecare
exemplar al entitii.
O entitate poate avea un numr arbitrar de relaii cu alte entiti ale modelului.

Relaia (Legtura, Relationship) este o asociere (creia i-a fost atribuit un nume) ntre dou
entiti, relevant pentru domeniul obiectiv considerat. Relaia este asocierea ntre entiti n
care fiecare instan (exemplar) a unei entiti este asociat cu un numr arbitrar (inclusiv
zero) de instane (exemplare) ale celeilalte entiti, i invers.
Atributul (Attribute) este o caracteristic a entitii, relevant pentru domeniul obiectiv i
utilizat la calificarea, identificarea, clasificarea, caracterizarea cantitativ sau exprimarea
strii entitii. Atributul reprezint tipul de caracteristici sau proprieti, asociate cu o mulime
de obiecte reale sau abstracte (persoane, locuri, evenimente, stri, idei, obiecte etc.). O
instan (un exemplar) a atributului este o anumit caracteristic a unui element separat
al mulimii. Instana atributului este identificat de tipul i valoarea caracteristicii, i se
numete valoare a atributului. Pe o diagram entitate-relaie atributele sunt associate
unor entiti concrete. Astfel, o instan a entitii trebuie s posede o unic valoare pentru
atributul asociat.

10.1.2.

Metoda IDEF1

IDEF iniial nsemna ICAM Definition, proiect iniiat n 1970 la Wright-Patterson Air Force Base
n Ohio de ctre Dennis E. Wisnosky, Dan Shunk L. i alii i finalizat n anii 1980. Ulterior,
standardele IEEE redenumesc IDEF in "Integration DEFinition". Proiectele ICAM i Integrated
Information Support System (IISS) au avut drept obiectiv principal crearea unui mediu de
prelucrare a informaiilor, care s poat fi rulat n medii eterogene de calcul fizic.
La momentul lansrii proiectului ICAM existau numeroase modele, majoritatea incompatibile,
de stocare a datelor modelul secvenial (VSAM), ierarhic (IMS), reea (TOTAL i CODASYL,
Cincom i IDMS, Cullinet). Modelul relaional era n curs de dezvoltare ca o modalitate
promitoare de gndire despre structurarea datelor pentru un acces facil, eficient, i precis.
Sistemele de baze de date relationale nu erau nc un standard general de gestionare a
datelor.
Biroul de programe ICAM a considerat important crearea unui mod "neutru" de descriere a
datelor unui sistem informatic de mari dimensiuni. Literatura de specialitate a sugerat c
metodele au fost necesare pentru organizarea prelucrrii datelor independent de modul n
care acestea sunt stocate fizic. Astfel, limbajul IDEF1 a fost creat pentru a permite o descriere
neutr a structurilor de date, care ar putea fi aplicat indiferent de metoda de depozitare sau
metoda de accesare a fiierelor.
IDEF1 se bazeaz pe modele cunoscute de organizare a datelor ntr-un sistem informaional:
Modelul Evolving Natural Language Information Model (ENALIM), dezvoltat de
G.M. Nijssen (Control Data Corporation), cunoscut i sub numele de NIAM sau the

Object-Role Model (ORM);

Modelul de organizare a datelor de tip reea, numit popular CODASYL, propus
de Charles Bachman (Honeywell Information Systems);

Modelul ierarhic, implementat de IBM, IMS, dezvoltat de R.R. Brown (Rockwell

International);
Modelul relaional, propus E.F. Codd (IBM);
Modelul entitate-relaie (E-R), elaborat de Peter Chen (UCLA).
Experiena ulterioar a artat c deplasarea cerinelor informatice n modelele bazelor de
date a fost mai dificil dect se credea iniial. Cel mai valoros aport al tehnicii de modelare a
informaiei IDEF1 a fost capacitatea sa de a reprezenta date independent de modul n care
aceste date vor fi stocate i folosite. Aceasta a pus la dispoziia dezvoltatorilor de sisteme
informaionale un mod de reprezentare a cerinelor privind datele n timpul identificrii

cerinelor viitorului sistem. Rezultatul a fost reducerea "nepotrivirilor" cerinelor privind

datele cu capacitile i limitrile SGBD-urilor, chiar dac trecerea de la modelul IDEF1 la
modelul BD s-a dovedit a fi dificil.

10.1.3.

Metoda IDEF1X

Metoda IDEF1 se bazeaz pe abordarea, propus de Peter Chen, care permite construirea
unui model al datelor echivalent modelului relaional n forma normal trei. Perfecionarea
metodei IDEF1 a condus la crearea versiunii IDEF1X, elaborate n scopul sporirii simplitii i
posibilitilor de automatizare. Diagramele IDEF1X sunt utilizate ntr-o serie de instrumente
CASE, cum ar fi ERwin, Design/IDEF.
n IDEF1X entitatea este independent de identificatori sau simplu independent, dac
fiecare exemplar al entitii poate fi identificat n mod univoc fr a defini relaiile lui cu alte
entiti. Entitatea se numete dependent de identificatori sau simplu dependent, dac
identificarea univoc a unui exemplar al entitii depinde de relaia lui cu o alt entitate (fig.
10.1 i 10.2).

Fig. 10.1. Entiti independente de identificare

Fig. 10.2. Entiti dependente de identificare

Fiecrei entiti i se atrbuie un nume i un numr unice, separate prin "/" i plasate de
asupra blocului.
Relaia este definit suplimentar prin cardinalul relaiei (numrul tuplurilor coninute n
respectiva relaie) sau numrul de instae ale entitii-descendent, care pot fi create de
fiecare instan a entitii-printe. n IDEF1X pot fi urmtoarele cazuri:
fiecare instan a entitii-printe poate fi legat de zero, unul sau mai multe
instane ale entitii-descendent;

 fiecare instan a entitii-printe trebuie s fie legat de cel puin o instan a

entitii-descendent;
fiecare instan a entitii-printe trebuie s fie legat de cel mult o instan a
entitii-descendent;
fiecare instan a entitii-printe este legat de un numr fix de instane ale
entitii-descendent.
n cazul n care o instan de entitate-descendent este determinat n mod univoc prin
legtura sa cu entitatea-printe, relaia este numit identificatoare (Authenticator), n caz
contrar - neidentificatoare.
Legtura (relaia) este notat printr-o linie ntre entitatea-printe i entitatea-descendent cu
un punct bine pronunat la sfritul liniei la entitatea-descendent (fig. 10.3). Cardinalul
relaiei poate lua urmtoarele valori: N zero, unu sau mai multe, Z zero sau unu, P unu
sau mai multe. Valoarea implicit este N.

Fig. 10.3. Notarea grafic a cardinalului unei relaii

O legtur identificatoare dintre entitatea-printe i entitatea-descendent este notat cu o
linie continu. Entitatea-descendent ntr-o legtur identificatoare este o relaie dependent
de identificator. Entitatea-printe ntr-o legtur identificatoare poate fi att relaie
independent ct i dependent de identificator (este determinat de legturile entitiiprinte cu alte entiti).
O legtur neidentificatoare este reprezentat cu ajutorul unei linii punctate (fig. 10.4).
Entitatea-descendent ntr-o relaie neidentificatoare se numete independent de
identificator, dac nu este entitate-descendent ntr-o oarecare legtur identificatoare.

Fig. 10.4. Legtur neidentificatoare

Atributele sunt reprezentate sub forma unei liste de nume n interiorul blocului entitii.
Atributele, care determin cheia primar, sunt plasate n partea de sus a listei i sunt
separate de alte atribute printr-o linie orizontal (fig. 10.4).
Entitile pot de asemenea avea chei strine (Foreign Key), care pot fi utilizate n calitate de
parte sau ntreg al cheii primare sau a unui atribut non-cheie. Pentru notarea unei chei strine
se vor utiliza literele FK n paranteze (fig. 10.4).

10.2.

Modelarea datelor n ERwin

n ERwin exist dou nivele de prezentare a modelelor logic i fizic.

La nivelul logic datele sunt prezentate analogic cum exist n lumea real i pot fi numite
tot aa cum sunt numite n realitate, de exmplu Client, Departament sau Nume angajat.
La nivel logic obiectele modelului sunt numite entiti i atribute. Modelul logic al datelor
poate fi construit n baza unui alt model logic, de exemplu n baza modelului proceselor.
Modelul logic al datelor este universal i nu este sub nici o form legat de realizarea concret
a SGBD.
Modelul fizic al datelor din contra, depinde de SGBD, fiind de facto reflectarea catalogului
de sistem. ntr-un model fizic este inclus informaia despre toate obiectele BD. Deoarece nu
exist standarde referitoare la obiectele BD (de exemplu, nu exist standard referitor la
tipurile de date), modelul fizic depinde de realizarea concret a SGBD. n consecin, unui
model logic i pot corespunde cteva modele fizice diferite. Dac ntr-un model logic nu
import tipul de date al unui atribut, ntr-un model fizic este important s fie descris toat
informaia privind obiectele fizice concrete tabele, coloane, indeci, proceduri etc.

10.2.1.

Documentarea modelului

Unele SGBD-uri au anumite restricii privind denumirea obiectelor (de exemplu, limitarea
lungimii numelui tabelelor sau interzicerea utilizrii simbolurilor speciale). Adesea
dezvoltatorii de SI utilizeaz versiuni nelocalizate de SGBD. Asta nseamn, c obiectele BD
pot fi denumite prin cuvinte scurte, care conin doar simboluri latine fr a utiliza simbolurile
speciale (adic un tabel poate fi denumit printr-un singur cuvnt, nu printr-o propoziie).
Suplimentar, proiectanii BD fac abuz de denumiri tehnice, n rezultat tabelele i coloanele
au denumiri de tipul RTD_324 sau CUST_A12, etc. Structura obinut n rezultat poate fi
neleas doar de specialiti (iar cel mai frecvent doar de autorii modelului), ea nu poate fi
discutat cu experii domeniului obiectiv. Separarea modelului n logic i fizic permite
soluionarea acestor probleme. La nivel fizic obiectele BD pot s se numeasc conform
exigenelor SGBD. La nivel logic acestor obiecte pot fi atribuite sinonime nume mai pe
nelesul nespecialitilor, cu utilizarea altor alfabete i a simbolurilor speciale. De exemplu,
tabelului CUST_A112 i poate corespunde entitatea Client constant. Aceast coresponden
asigur o mai bun documentare a modelului i permite discutarea structurii datelor cu
experii domeniului obiectiv.

10.2.2.

Scalabilitatea

Crearea modelului datelor ncepe, de obicei, cu elaborarea modelului logic. Dup descrierea
modelului logic proiectantul poate alege SGBD adecvat, iar ERwin va crea n mod automat
modelul fizic corespunztor. n baza modelului fizic ERwin poate genera catalogul de sistem al
SGBD sau scriptul respectiv SQL. Acest proces se numete proiectare direct (Forward
Engineering). Prin aceast este asigurat scalabilitatea: crend un model logic al datelor pot
fi generate modele fizice pentru orice SGBD susinut de ERwin. Pe de alt parte, ERwin
permite, reieind din coninutul catalogului de sistem sau scriptul SQL, restabilirea modelului
fizic i logic al datelor (Reverse Engineering). n baza modelului logic obinut poate fi generat
modelul fizic pentru un alt SGBD, dup care poate fi creat catalogul de sistem al acestuia. n
consecin, ERwin permite soluionarea problemei transportabilitii structurii de date de pe
un server pe altul. De exemplu, poate fi transportat structura de date din Oracle n Informix
(sau invers) sau s fie transportat structura fiierelor dbf ntr-un SGBD relaional, prin
aceasta simplificnd problema trecerii de la un SI de tip server de fiiere (file-server) la
model-server. ns, trecerea formal de la o structur cu fiiere plate la un SGBD relaional
de obicei nu este eficace. Pentru a obine avantaje de la trecerea la tehnologia client-server
trebuie de modificat structura datelor.
Pentru comutarea ntre modelul logic i modelul fizic al datelor servete lista cu dou opiuni
din parte central a panoului de iinstrumente ERwin (fig. 10.5).

Fig. 10.5. Comutarea ntre modelul logic i modelul fizic

Dac la comutare modelul fizic nu exist nc, el va fi creat n mod automat.

10.2.3.

Interfaa ERwin

Interfaa ERwin este realizat n stilul aplicaiilor Windows, este simpl i intuitiv neleas.
Vom analiza succint funciile principale ale ERwin pentru afiarea modelului.
Fiecrui nivel de afiare a modelului i corespunde panoul instrumental propriu. La nivel logic
panoul de instrumente include urmtoarele butoane:
butonul indicatorului de mouse (regimul mouse) n acest regim focusul poate
fi pus pe un obiect al modelului;
butonul pentru introducerea unei entiti;
butonul categoriei (categoria sau relaia categorial este un tip special de
legtur ntre entiti, care va fi prezentat mai jos);
butonul de introducere a unui bloc de text;
butonul pentru deplasarea atributelor n cadrul unei entiti sau ntre entiti;
butonul pentru crearea legturilor: identificatoare, muli-la-muli i
neidentificatoare.
La nivel fizic panoul de instrumente include:
n locul butonului categoriilor butonul pentru introducerea vederilor (view);
n locul butonului legturii muli-la-muli butonul pentru legarea vederilor.
Pentru crearea modelelor datelor pot fi utilizate dou notaii: IDEF1X i IE (Information
Engineering). n continuare vom utiliza notaia IDEF1X.
n ERwin exist cteva nivele de afiare a diagramelor: nivelul entitilor, nivelul atributelor,
nivelul definiiilor, nivelul cheilor primare i nivelul pictogramelor. Comutarea ntre primele
trei poate fi realizat prin utilizarea butoanelor panoului instrumental, iar la celelalte cu
ajutorul meniului de context, care apare cnd facem click dreapta n orice loc de pe
diagram, neocupat de, obiectele modelului. n meniul de context va fi selectat opiunea
Display Level (fig. 10.6), iar apoi nivelul necesar de afiare.

Fig. 10.6. Alegerea nivelului de afiare a diagramei

10.3.

Crearea modelului logic al datelor

10.3.1.

Nivelele modelului logic

n dependen de admcimea prezentrii informaiei despre date exist trei nivele ale
modelului logic:
diagrama entitate-relaie (Entity Relationship Diagram, ERD);

modelul datelor, bazat pe chei (Key Based model, KB);

modelul atributiv complet (Fully Attributed model, FA).
Diagrama entitate-relaie (Entity Relationship Diagram, ERD) reprezint modelul de nivel
superior al datelor. El include entitile i legturile reciproce, care reflect regulile business
principale ale domeniului obiectiv. Aceaste diagrame nu sunt prea detalizate, includ doar
entitile principale i legturile ntre ele, entiti care satisfac cerinele principale ale
sistemului informaional. O diagram entitate-relaie poate include relai de tipul muli-lamuli i s nu includ descrierea cheilor. Ca regul, ERD sunt utilizate pentru prezentarea i
discutarea structurilor de date cu experii domeniului obiectiv.
Modelul datelor, bazat pe chei, permite prezentarea mai amnunit a datelor. Include
descrierea tuturor entitilor i a cheilor primare, i este destinat prezentrii strutucrii de
date i a cheilor, care corespund domeniului obiectiv.
Modelul atributiv complet este cea mai detalizat prezentare a structurilor de date:
prezint datele n forma normal trei i include toate entitile, atributele i legturile.

10.3.2.

Entiti i atribute

Componentele principale ale unei diagrame ERwin sunt entitile, atributele i legturile.
Fiecare entitate este o mulime de obiecte individuale asemntoare, numite exemplare
(instane). Fiecare instan este individual i trebuie s difere de restul entitilor. Atributul
exprim a anumit prorpietate a obiectului. Din punctul de vedere al BD (modelul fizic)
entitii i corespunde un tabel, instanei entitii o linie a tabelului, iar atributului o
coloan a tabelului.
Pentru construirea modelului datelor trebuie identificate entitile i atributele, adic s se
determine care informaii vor fi pstrate ntr-o entitate sau atribut anume. Entitatea poate fi
definit ca obiect, eveniment sau concept, informaia despre care trebuie pstrat.Entitile
trebuie s posede denumiri cu valoare clar a sensului, s fie denumite prin substantiv la
singular, s nu poarte denumiri tehnice i s fie suficient de importante pentru a fi

modelate. Denumirea entitilor la singular faciliteaz citirea modelului. De facto, numele

unei entiti este determinat de numele instanei acesteia. Ca exemplu poate servi entitate
Client (nu Clieni!) cu atributele Numrul clientului, Numele clientului i Adresa clientului. La nivelul
fizic al modeluluiacestei entiti i poate corespunde tabelul Customer cu coloanele
Customer_number, Customer_name i Customer_address. Fiecare entitate trebuie s fie definit
total cu ajutorul descrierii textuale. Pentru introducerea unor comentarii i definiii
suplimentare pot fi utlizate proprietile definite de utilizator (UDP).
Fiecare atribut pstreaz informaii despre o anumit caracteristic a enititii, iar fiecare
instan trebuie s fie unic. Un atribut sau un grup de atribute, care identific identitatea, se
numete cheie primar.
Denumirea adecvat a unui atribut este foarte important. Numele unui atribut va fi la
singular i va avea o semnificaie clar. Respectarea acestei reguli permite soluionarea
parial a problemei normalizrii datelor chiar la etapa idenrificrii atributelor. De exemplu,
crearea atributului Telefoanele angajatului pentru entitatea Angajat contrazice cerinelor
normalizrii, deoarece atributul trebuie s fie atomar, adic s nu conin valori multiple.
Conform sintaxei IDEF1X numele atributului trebuie s fie unic n cadrul modelului (nu numai
pentru entitate!). n mod implicit, la ncercarea de introducere a unui nume deja existent
ERwin va atribui un alt nume.
Fiecare atribut trebuie definit, vor fi excluse definiiile circulare, de exemplu, cnd termenul 1
este definit prin termenul 2, 2 prin 3, iar 3 prin 1.
Adesea este necesar s se creeze atribute derivate, adic atribute, valoarea crora poate fi
calculat din alte atribute. Un exemplu de atribut derivat poate servi Vrst angajat, care
poate fi calculat din atributul Zi de natere . Acest atribut poate duce la conflicte, ntr-adevr,
n cazul n care timpul nu este actualizat, valoarea atributului Vrst angajat ar putea fi
contrar valorii atributului Zi de natere . Atributele derivate reprezint erori de normalizare,
dar ele sunt introduse pentru a mbunti performanele sistemului, pentru a exclude
calculele, care n practic pot fi dificile.

10.3.3.

Relaia

Relaia (legtura) este o coresponden logic ntre entiti. Pentru numirea unei relaii
trebuie utilizat un verb sau o fraz verbal. Numele relaiei nu este afiat pe diagram. La

nivel logic pot fi stabilite relaii care identific legtura unul-la-mai-muli, legtura mulila-mai-muli i legtura neindentificatoare unul-la-mai-muli.

n IDEF1X exist entiti dependente i independente. Tipul unei entiti este determinat de
relaia cu alte identiti. O relaie identificatoare are loc ntre o entitate independent
(extremitatea printeasc a relaiei) i una dependent (extremitatea fiic a relaiei). Atunci
cnd are loc desenarea unei relaii identificatoare, ERwin n mod automat transform
entitatea-fiic n una dependent. Identitatea dependent este reprezentat printr-un
dreptunghi cu colurile rotunjite. Instana unei entiti dependente este determinat doar de
relaia cu entitatea printe. La setarea unei relaii identificatoare atributele cheii primare a
entitii printe sunt transmise automat n componena chieii primare a entitii fiice. Aceast
operaie de complementare a atributelor identitii fiice la crearea realaiei se numete
migrarea atributelor. n entitatea fiic atributele noi sunt marcate ca chei strine FK.
La setarea unei relaii neidentificatoare identitatea fiic rmne independent, iar atributele
cheii primare a entitii printe migreaz n componena componentelor non-chei ale entitii
printe. O relaie neidentificatoare este utilizat pentru legarea indentitilor independente.
O relaie identificatoare este reprezentat n diagram printr-o linie continu cu un punct gras
la extrema fiic, iar o relaie neidentificatoare printr-o linie punctat (fig. 10.6).

Cardinalul relaiei (Cardinality) este utilizat pentru a reprezenta raportul dintre numrul de

instane ale entitii printe la numrul de instane ale entitii fiice.

Exist patru tipuri de entiti:
cazul general n care o instan a entitii printe corespunde la 0, 1 sau mai
multe instane ale entitii fiice (nu este marcat prin simbol);
cu simbolul P este etichetat cazul n care unei instane a entitii printe i
corespunde una sau mai multe instane ale entitii fiice (este exclus valoarea zero);
cu simbolul Z este etichetat cazul n care unei instane a entitii printe i
corespunde zero sau o instan a entitii fiice (mai multe valori sunt excluse);
cu un numr este etichetat cazul corespondenei exacte, cnd unei instane a
entitii printe i corespunde un numr prestabilit de instane a entitii fiice.

Numele relaiei (Verb Phrase) este o fraz, care caracterizeaz relaia dintre entitile printe
i fiu. Pentru relaia unul-la-mai-muli, identificatoare sau nu, este sificient s fie indicat
numele, care caracterizeaz relaia de la entitatea printe la entitatea fiic (Parent-to-Child).
Pentru relaia muli-la-muli trebuie de indicat att numele Parent-to-Child, ct i Child-toParent.

10.3.4.

Tipurile entitilor i ierarhia motenirii

Relaia stabilete dac o identitate este independent sau dependent. Exist cteva tipuri
de entiti dependente.
Caracteristic este identitatea fiic dependent, legat doar cu o indentitate printe i
conform sensului pstreaz informaii despre caracteristicile entitii printe (fig. 10.7).

Fig. 10.7. Exemplu de entitate caracteristic "Hobby"

Asociativ este identitatea, legat cu cteva indentiti printe. O astfel de identitate
pstreaz informaii despre relaiile dintre entiti.
Nominativ este identitatea caz particular al unei entiti asociative, care nu posed
atribute proprii (doar atributele entitilor printe, care au migrat n calitate de cheie strin).
Categorial este identitatea fiic n ierarhia motenirii.

Ierarhia motenirii (sau ierarhia categoriilor) este un tip special al reuniunii entitilor, care
mprtesc caracteristici comune. De exemplu, ntr-o organizaie lucreaz angajai titulari i
cumularzi. Din proprietile lor comune poate fi creat o entitate generalizatoare (strmo)
Colaborator (fig. 10.8), pentru a reprezenta informaiile comune pentru toate categoriile de
angajai. Informaia specific fiecrui tip poate fi plasat n entitile categoriale (urmaii)
Titular i Cumulard.

Fig. 10.8. Ierarhia motenirii. Categorie incomplet

De obicei ierarhia motenirii este creat atunci cnd cteva entiti au atribute de sens
comune sau cnd entitile au relaii de sens comune (de exemplu, dac Titular i Cumulard
ar poseda o relaie comun dup sens lucreaz n cu entitatea Organizaia), sau atunci
cnd aceasta este dictat de regulile business.
Pentru fiecare categorie poate fi indicat discriminatorul atribut al strmoului, care
stabilete cum poate fi fcut distincia ntre entitile categoriale (atributul Tipul din fig.
10.8).
Exist dou tipuri de ierarhii ale categoriilor complete i incomplete. ntr-o categorie
complet unei instane a strmoului (entitatea Colaborator, fig. 10.9) n mod obligator i
corespunde o instan dintr-un urma, adic n exemplu nostru colaboratorul n mod obligator
este sau cumulard, sau consultant, sau titular.

Fig. 10.9. Ierarhia motenirii. Categorie complet

Dac o categorie nu a fost nc construit definitiv i n strmo pot exista instane, care nu
au instane corespondente n urmai, o astfel de categorie va fi incomplet. n fig. 10.8 este
prezentat o categorie incomplet - colaboratorul poate fi nu numai titular sau cumulard, dar
i consultant, ns entitatea Consultant nc nu a fost introdus n ierarhia motenirii.

10.3.5.

Chei

Fiecare instan a unei entiti trebuie s fie unic i s difere de alte atribute.
Cheia primar (primary key) este atrbutul sau grupul de atribute, care identific n mod
univoc o instana a entitii. Atributele unei chei primare ntr-o diagram nu solicit notare
special sunt acele atrbuite, care se afl n lista atributelor deasupra liniei orizontale (fig.

10.9).
O entitate poate poseda cteva atribute sau seturi de atribute pretendente la rolul de cheie
primar. Aceti pretendeni sunt numii chei poteniale sau candidat (candidate key).
O cheie este numit compus dac este format din cteva atribute. Cheile primare compuse
nu solicit notare special este lista atributelor, plasate mai sus de linia orizontal.
Examinm candidaii la rolul de cheie primar a entitii Colaborator (fig. 1.10).

Fig. 10.10. Determinarea cheii primare pentru entitatea Colaborator

I n calitate de chei poteiale pot fi:

1. Cod de pontaj
2. Numr paaport
3. Nume+prenume
Pentru a deveni cheie primar o cheie candidat trebuie s posede urmtoarele proprieti:
Unicitatea. Dou instane nu trebuie s aib aceleai valori pentru o posibil cheie. numrul
potenial 3 (nume + prenume) este un candidat slab, deoarece n organizaie pot lucra tizi
complei.
Compactitatea. O cheie compus posibil nu trebuie s conin nici un atribut a crui
eliminare nu ar conduce la pierderea unicitii. Pentru a asigura unicitatea candidatului 3 l
vom completa cu atributele Data naterii i Culoarea prului. Dac regulile business
stabilesc, c combinaia atributelor Nume+Prenume+Data naterii este suficient pentru a
identifica n mod unic angajaii, atunci Culoarea prului este de prisos, adic cheia
Nume+Prenume+Data naterii+Culoarea prului nu este compact.
La alegerea cheilor primare vor fi mai preferate cheile simple, adic cheile, care conin un
numr mai mic de atribute. n exemplul de mai sus cheile nr. 1 i nr. 2 sunt preferate cheii nr.
3.
Atributele unei chei nu trebuie s conin valori nule. Valorile atributelor nu se vor schimba pe
tot timpul existenei unei instane. O colaboratoare poate s se cstoreasc i s-i schimbe
att numele, ct i paaportul. Din aceast cauz cheile nr. 2 i nr. 3 nu sunt bune pentru
rolul de cheie primar.
Fiecare entitate trebuie s posede cel puin o cheie candidat. Multe entiti au doar o singur
cheie candidat. O astfel de cheie devine primar. Alte entiti pot avea mai multe chei
candidat. n acest caz una din ele devine cheie primar, iar restul chei alternative.
O cheie alternativ(Alternate Key) este cheia candidat, care nu a devenit primar.

10.3.6.

Normalizarea datelor

Normalizarea datelor este procesul de verificare i reorganizare a entitilor i atributelor n

scopul satisfacerii cerinelor modelului relaional al datelor. Normalizarea permite s se

garanteze, c fiecare atribut a fost determinat pentru entitatea sa, c sunt diminuate n mod

semnificativ cerinele privind capacitatea memoriei, c sunt eliminate anomaliile n

organizarea pstrrii datelor. n rezultatul normalizrii trebuie creat o structur de date, n
care informaia despre un anumit fapt este pstrat ntr-un singur loc. Procesul normalizrii
const n transformarea succesiv i reducerea structurii datelor la forme normale cerine
formalizate privind organizarea datelor. Sunt cunoscute 6 forme normale. n practic ne
limitm la forma normal 3.
ERwin nu propune un algoritm complet de normalizare i nu realizeaz automat normalizarea,
ns posibilitile lui faciliteaz crearea unui model normalizat al datelor. Interzicerea atribuirii
numelor neunicale pentru atribute (setarea opiunii Unique Name) faciliteaz respectarea
reguluii un fapt ntr-un singur loc. Numele rolurilor atributelor cheilor strine i unificarea
atributelor contribuie de asemenea la facilitarea construirii modelului normalizat.

10.3.7.

Domenii

Un domeniu este definit ca set de valori din care sunt luate valorile atributelor. Fiecare
atribut poate fi definit numai pe un domeniu, dar pentru fiecare domeniu poate fi definit o
mulime de atribute. n noiunea domen este inclus nu doar tipul datelor, dar i plaja de valori
ale datelor. De exemplu, poate fi definit domeniul Vrst numr ntreg pozitiv, i s
definim atributul Vrst colaborator, care aparine acestui domeniu.
n ERwin un domeniu poate fi definit o singur dat i poate fi utilizat att n modelul logic,
ct i n modelul fizic.
Domeniile permit facilitarea lucrului cu datele att pentru dezvoltatori la etapa proiectrii, ct
i pentru administratorii BD la etapa exploatrii sistemului. La nivelul logic domeniile pot fi
descrise fr a apela la proprieti fizice concrete. La nivelul fizic domeniile obin n mod
automat propieti specifice, care pot fi modificate manual. De exemplu, domeniul Vrst
poate avea la nivel logic tipul Number, iar la nivelul fizic coloanelor domeniului li se va atribui
tipul INTEGER.
Un domeniu poate fi descris, i pot fi asociate comentarii sau proprieti, definite de utilizator.

10.4.

Crearea modelului fizic al datelor

Modelul fizic conine toat informaia, necesar pentru realizarea unei baze de date concrete.
Exist dou nivele distincte ale modelului fizic:
modelul transformaional;

modelul SGBD.

Modelul transformaional conine informaii pentru realizarea unui proiect separat, care poate
fi parte a ntregului sistem informaional i descrie o submulime a domeniului obiectiv. Acest
model permite proiectanilor i administratorilor BD s neleag mai bine, care obiecte ale
BD sunt pstrate n dicionarul datelor i s verifice gradul n care modelul fizic satisface
ceerinele SI.
Modelul SGBD este generat n mod automat din modelul transformaional i reflect exact
catalogul de sistem al SGBD.
Nivelul fizic la care este prezentat modelul depinde de serverul selectat. ERwin susine peste
20 de tipuri (relaionale i nu numai) de BD.
n mod implicit ERwin genereaz nume de tabele i indeci conform ablonului n baza
numelor entitilor respective i cheilor modelului logic, care pot fi ulterior corectate manual.
Numele tabelelor i coloanelor vor fi generate n mod implicit n baza numelor entitilor i
atributelor modelului logic.

10.4.1.

Reguli de validare i valori implicite

ERwin susine reguli de validare pentru coloane i valori, atribuite n mod implicit coloanelor.

Regula de validare specific o list de valori valide pentru o anumit coloan i/sau reguli
de verificare a valorilor admisibile. n lista de valori admisibile pot fi introduse valori noi.
ERwin poate genera reguli de validare n conformitate cu sintaxa SGBD-ului selectat, lund n
consideraie graniele diapazonului sau lista de valori.
Valoarea implicit este valoarea, care trebuie introdus ntr-o coloan, dac o alt valoare
nu a fost introdus n mod explicit n timpul introducerii datelor. Valorile implicite pot fi
atribuite oricrei coloane sau domeniu. Lista valorilor poate fi redactat.
Dup crearea unei reguli de validare i valorilor implicite ele pot fi atribuite unei coloane sau
domeniu (sau mai multe).

10.4.2.

Idici

ntr-o BD datele de obicei sunt pstrate n ordinea n care au fost introduse n tabel. Multe
SGBD relaionale au o organizare pe pagini conform creia tabelul poate fi pstrat fragmentat
n diferite pri ale discului, liniile tabelului fiind plasate n pagini ntr-un mod neordonat.
Aceast modalitate permite introducerea rapid a datelor noi, ns cutarea datelor devine
complicat.
Pentru soluionarea cutrii, SGBD-urile utilizeaz obiecte, numite indeci. Un index conine
informaii sortate pe coloan sau pe mai multe coloane i indic liniile n care este pstrat o
valoare concret a coloanei. Deoarece valorile ntr-un index sunt pstrate ntr-o anumit
ordine la cutare va fi procesat un volum mult mai mic de informaii, ceea ce conduce la
diminuarea semnificativ a timpului de execuie a unei interpelri. Se recomand crearea
unui index pentru coloanele n care au loc cutri fracvente.
La generarea schemei bazei de date fizice ERwin creaz un indice n mod automat n baza
cheii primare a fiecrui tabel, de semenea n baza tuturor cheilor alternative i strine,
deoarece aceste coloane sunt utilizate cel mai frecvent la cutri. Exist posibilitatea de a
refuza generarea implicit a indicilor i de creare a indicilor proprii. Aceast posibilitate este
binevenit pentru administratorii BD, care n scopul sporirii eficacitii cutrilor trebuie s
analizeze interpelrile cele mai frecvente i, n baza analizei, s creeze indici proprii.

10.4.3.

Triggere i proceduri stocate

Triggerele i procedurile stocate sunt blocuri de cod SQL, care posed nume, compilate
anterior i pstrate pe server pentru dinamizarea procesrii interpelrile, validarea datelor i
execuia altor funcii frecvente. Pstrarea i executarea codului de ctre server permite
crearea unui cod o singur dat, fr a-l repeta n fiecare aplicaie, care interacioneaz cu
SGBD-ul. Prin aceasta este economisit timpul pentru scrierea i mentenana programelor,
este garantat integritatea datelor, regulile business sunt susinute, indiferent de aplicaia
client solicitant. Triggerele i procedurile stocate nu vor fi transferate prin reea de la
aplicaia client, ceea ce diminueaz semnificativ traficul.
Procedura stocat este un set, care posed nume, de instruciuni SQL compilate n
prealabil, care poate fi apelat de o aplicaie client sau de o alt procedur stocat.
Trigger-ele sunt destinate dinamizrii prelucrrii sistemelor relaionale de baze de date. Se
bazeaz pe noiunea de eveniment condiie aciune, respectiv pe reguli ce in de cele trei
componente ale principiului de mai sus. Acestea sunt reguli active, definite iniial n
domeniul bazelor de date active. Un sistem activ de baz de date ofer proiectantului unei
aplicaii posibilitatea de a monitoriza apariia unor tipuri specifice de evenimente care se
porduc n BD. Aceste evenimente sunt de obicei modificri ale datelor, dar pot fi i menionri
(invocri) de proceduri i funcii, sau chiar producerea de evenimente generate de tactul
sistemului. Cnd se produce un eveniment, o regul activ determin evaluarea unei condiii.
Dac rezultatul este adevrat, se execut aciunea regulei. Regulile active sunt pentru
corectarea nclcrii restriciilor, gestiunea fiierelor-jurnal, etc.
Triger-ul integritii referenial este un trigger special, utilizat pentru asigurarea
integritii datelor a dou tabele, legate reciproc. Dac o linie este inserat, modificat sau
eliminat dintr-un tabel, triger-ul integritii refereniale va informa SGBD-ul ce va trebuie s

fac cu acele linii din alte tabele, linii ale cror valoarea cheii strine coiincide cu valoarea
chieii primare a liniei inserate, modificate sau eliminate.
ERwin utilizeaz abloane pentru generarea trigger-ilor script-uri speciale, care utilizeaz
macroinstruciuni. La generarea codului unui trigger macroinstruciunile sunt substituite de
numele tabelelor, coloanelor, variabilelor i alte fragmente de cod, conform sintaxei SGBD.
abloanele triger-elor integritii refereniale, generate implicit de ERwin, pot fi modificate.
Pentru crearea i editarea procedurilor stocate ERwin pune la dispoziie editoare speciale,
analogice editoarelor utilizate la crearea trigger-elor. Spre deosebire de triggere, o procedur
stocat nu este executat ca rspuns la un eveniment, ci este apelat dintr-un alt program,
care transmite serverului numele procedurii. Procedura stocat este mai flexibil dect
trigger-ul, deoarece poate apela alte proceduri stocate. Procedurii apelate i pot fi transmii
parametri, iar ea poate returna parametri, valori sau mesaje.

10.4.4.

Proiectarea depozitelor de date

Depozitele de date pstreaz informaii, care nu sunt modificate (sau foarte rar sunt
modificate). Depozitele sunt orientate pentru executarea interpelrilor analitice, care asist
adoptarea deciziilor de conductori i manageri. La proiectarea depozitelor de date trebuie
respectate urmtoarele cerine:
depozitul va avea o structur neleas de utilizator;
vor fi evideniate datele statice, care sunt modificate conform orarului (zilnic,
sptmnal, semestrial);
vor fi simplificate cerinele privind interpelrile pentru excluderea interpelrilor,
care solicit declaraii SQL multiple n SGBD relaionale tradiionale;
va fi asigurat asistarea interpelrilor SQL complexe, care solicit procesarea a
milioane de nregistrri.
Observm, c SGBD-urile relaionale difer substanial de depozitele de date. Normalizarea
datelor n SGBD-urile relaionale conduce la crearea mai multor tabele legate reciproc.
Executarea interpelrilor complexe conduce inevitabil la jonciunea mai multor tabele, ceea
ce sporete substanial timpul de rspuns. Proiectarea depozitelor de date presupune crearea
unor structuri denormalizate de date, orientate n primul rnd la productivitate nalt de
executare a interpelrilor analitice. Normalizarea face modelul depozitului prea complicat,
dificil de neles i reduce viteza de execuie. Pentru proiectarea eficient a depozitelor de
date ERwin folosete modelul n-dimensional - o metodologie de proiectare, special conceput
pentru dezvoltarea de depozite de date. Modelarea n-dimensional este similar cu
modelarea relaiilor i entitilor din modelul relaional, dar are un scop diferit. Modelul
relaional este axat pe integritatea i eficiena introducerii de date. Model n - dimensional se
concentreaz n primul rnd pe interogrile complexe.
n modelarea n dimensional este adoptat standardul modelului, numit stea, care asigur
o vitez mare de executare a unei interpelri prin intermediul denormalizrii i separrii
datelor. Este imposibil de creat o structur universal de date, care s asigure o vitez mare a
procesare a oricrei iinterpelri, din care cauz schema ste este construit pentru
asigurarea productivitii maxime la ndeplinirea celei mai importante interpelri (sau grup de
interpelri).
Schema stea de obicei conine un tabel mare, numit tabel a faptelor, plasat n centru. El
este nconjurat de tabele mai mici, numite tabele dimensionale, legate de tabelul faptelor
prin legturi radiale.
Pentru crearea unei baze de date cu schema stea vor fi analizate regulile business ale
domeniului obiectiv n scopul identificrii interpelrii centrale. Datele, care vor asigura
executarea acestei interpelri, trebuie plasate n tabelul central. La proiectarea depozitelor de
date este important s se identifice sursa datelor, metoda de extragere, transformare i
filtrare a datelor, naintea importrii lor n depozit. Cunoaterea sursei permite actualizarea
periodic i verificarea calitii datelor

10.4.5.

Calcularea volumului BD

La un anumit interval de timp dup lansarea n exploatare a sistemului informaional ERwin

permite calcularea volumului aproximativ al BD, al tabelelor, indicilor i altor obiecte.
Calculele sunt produse n baza urmtorilor parametri: numrul iniial de linii, numrul
maximal de linii, creterea numrului de linii ntr-o lun.

10.4.6.

Proiectarea direct i invers

Se numete proiectare direct procesul generrii schemei fizice a BD din modelul logic. La
generarea schemei fizice ERwin include trigger-ele integritii refereniale, procedurile
stocate, indicii, constrngerile i alte posibiliti, accesibile la definirea tabelelor SGBD-ului
selectat.
Se numete proiectare invers procesul generrii modelului logic din modelul fizic al BD.
Proiectarea invers este utilizat la convertirea bazei de date dintr-un SGBD n altul. Dup
crearea modelului logic al BD folosind metoda proiectrii inverse se poate realiza proiectarea
direct i trece pe un alt server.
n afara regimului de proiectare direct i indirect ERwin asigur sincronizarea modelului
logic cu catalogul de sistem al SGBD pe durata ntregului ciclu de creare a SI.

10.4.7.

Generarea codului prii client n ERwin

ERwin susine nu doar proiectarea cerverului BD, dar i generarea automat a aplicaiei client
n mediile de dezvoltare MS Visual Basic i Power Builder. Tehnologia generrii const n
atribuirea, la etapa elabrrii modelului fizic al datelor, fiecrei coloane a atributelor extinse,
care conin informaii despre proprietile obiectelor aplicaiei client (inclusiv i vizuale),
obiecte ce vor reflecta informaia pstrat n coloana respectiv. Aceast informaie este
nscris n fiierului modelului. n baza informaiilor din atributele extinse sunt generate
formele de ecran. Codul obinut poate fi compilat i executat fr implementare suplimentar
manual.
n modelul ERwin al unei coloane poate fi setate proprieti descrise i nominalizate:
regulile de validare (verificarea valorilor);
valorile iniiale, setate implicit;

stilul obiectului vizual (buton radio, text-box .a.);

formatul de afiare.

Pentru descrierea fiecrei proprieti n ERwin exist editoarele respective.

10.4.8.

Crearea rapoartelor i generarea dicionarelor

Pentru generarea rapoartelor este folosit instrumentul Report Browser. Exist o serie de
rapoarte predefinite, care perimit prezentarea informaiei despre obiectele principale ale
modelului datelor (logic i fozic). Cu ajutorul unui editor special rapoartele pot fi modificate
sau pot fi create rapoarte proprii. Fiecare raport poate fi configurat n mod individual, datele
pot fi ordonate i filtrate. Report Browser permite salvarea rezultatelor crerii rapoartelor,
imprimarea i exportul n formate rspndite.
Pentru gestiunea proiectelor mari ERwin are un instrument special - ERwin Dictionary, care
asigur lucrul colectiv cu diagramele i permite salvarea i documentarea versiunilor
modelelor datelor. ERwin Dictionary reprezint o baz de date special, care rezolv
problema pstrrii i documentrii modelelor, ns nu respect n totalitate cerinele lucrului
n echip.

11.

Proiectarea SI folosind UML

Exist mai multe tehnologii i instrumente care permit realizarea unor proiecte optimale (ntrun anumit sens) pornind de la etapa de analiz i finaliznd cu crearea codului program al

sistemului. n cele mai multe cazuri, aceste tehnologii impun cerine foarte stricte pentru
procesul de dezvoltare i resursele utilizate, iar ncercrile de a le adapta pentru proiecte
specifice nu au succes. Aceste tehnologii sunt materializate n instrumente CASE de nivel
superior sau CASE pentru ciclul de via complet (upper CASE tools sau full life-cycle CASE
tools). Ele nu permit optimizarea activitii la nivelul elementelor individuale ale proiectului,
i, ca rezultat, muli dezvoltatori aleg unelte de nivel inferior (lower CASE tools). Ca i
consecin, dezvoltatorii se confrunt cu o nou provocare - organizarea interaciunii ntre
diferite echipe de realizare a proiectului.
Limbajul unificat de modelare obiect-orientat Unified Modeling Language (UML) a fost
propus ca mijloc de a ajunge la un compromis ntre aceste dou abordri. Exist un numr
suficient de instrumente care s sprijine UML, folosind ciclul de via al sistemelor
informatice, i, n acelai timp, UML este suficient de flexibil pentru a configura i menine
specificul echipelor de dezvoltatori.
Un impuls puternic pentru dezvoltarea acestui domeniu al tehnologiei informaiei a dat
rspndirea limbajelor de programare orientat-obiect la sfritul anilor 1980 - nceputul
anilor 1990. Dezvoltatorii doreau s existe un singur limbaj de modelare, care s incorporeze
toat fora abordrii obiect-orientate i s ofere un model clar al sistemului, model care
reflect toate aspectele sale semnificative. La mijlocul anilor nouzeci ai secolului trecut lideri
evideni n acest domeniu au devenit metodele Booch (Grady Booch), OMT-2 (Jim Rumbaugh)
i OOSE - Object-Oriented Software Engineering (Ivar Jacobson). ns aceste trei metode
aveau puncte forte i puncte slabe: OOSE era mai bun n faza de analiz a domeniului
problemei i a cerinelor de sistem, OMT-2 era preferat n etapele de analiz i proiectare,
Booch - pentru proiectare i implementare.
Crearea limbajului UML a nceput n octombrie 1994, cnd Jim Rumbaugh i Grady Booch de
la Rational Software Corporation au purces la combinarea tehnicilor OMT i Booch. n toamna
anului 1995 a fost prezentat prima versiune a metodologiei combinate, pe care au numit-o
metoda Unified 0.8. Dup aderarea (la sfritul anului 1995) la Rational Software Corporation
a lui Ivar Jacobson mpreun cu firma sa Objectory, eforturile celor trei fondatori ai celei mai
populare metodologii orientate obiect au fost canalizate ctre crearea UML.
I n prezent consoriul utilizatorilor UML Partners include reprezentani ai multor gigani din
domeniul tehnologiei informaiei ca Software Rational, Microsoft, IBM, Hewlett-Packard,
Oracle, DEC, Unisys, IntelliCorp, Tehnologie Platinum.
UML este un limbaj de modelare orientat-obiect, cu urmtoarele caracteristici principale:
este un limbaj de modelare vizual care asigur dezvoltarea de modele
reprezentative pentru interaciunea cu clienii i dezvoltatorii SI;
include mecanisme de extensibilitate i de specializare a conceptelor de baz
ale limbajului.
UML este notaia standard pentru modelarea vizual a sistemelor software, adoptat de ctre
consoriul Object Management Group (OMG) n toamna anului 1997, iar astzi este susinut
de mai multe produse CASE orientate-obiect.
UML include un set interior de instrumente de modelare ("nucleul"), care este acceptat n mai
multe metode i mijloace de modelare. Utilizatorii limbajului au urmtoarele posibiliti:
s construiasc modele bazate pe nucleu, fr utilizarea mecanismelor de
extensie pentru cele mai multe aplicaii tipice;
s adauge la necesitate noi elemente i simboluri, n cazul n care acestea nu
exist n nucleu, sau s specializeze componente, sistemul de notaie i restriciile
pentru domenii specifice.

11.1.

Diagramele UML

La proiectarea sistemelor informatice folosind UML sunt utilzate dou puncte de vedere
necesare unei descrieri suficiente a realitii:

1. punctul de vedere structural

2. punctul de vedere comportamental (behavioral).
n standardul UML sunt definite urmtoarele diagrame, pe cele dou categorii:

a. pentru descrierea structural:

Diagrama Claselor;

Diagrama Obiectelor;

Diagrama Componentelor;

Deployment Diagram.
b. pentru descrierea comportamental:

Diagrama Use Case;

Diagrama Activitilor;

Diagrama Strilor;

Diagrama de secvene;

Diagrama de Colaborare.
Deoarece UML a fost studiat n cursul AMSI, n continuare vor fi amintite succint doar
diagramele cele mai utile pentru un analist.

11.1.1.

Diagrama Use Case

Diagrama Use Case este tipul de diagram din care reiese modul de utilizare a sistemului
informatic - modul n care utilizatorii interacioneaz cu acesta (n coresponden direct cu
task-urile acestor utilizatori). Utilizarea Use Case diagram nu este absolut necesar pentru a
scrie o specificaie cu Use Case-uri dar este util pentru a crea o imagine general asupra
sistemului. Elementele utilizate i notaiile lor sunt prezentate n tabelul 11.1.
Tab. 11.1. Elementele unei diagrame Use Case i notaiile lor
Elemen
t

Descriere

Actor

Un actor este un utilizator al sistemului, inclusiv un alt sistem

informatic, care interacioneaz cu sistemul analizat.

Use
Case

Use Case-urile se reprezint sub forma unei elipse n interiorul creia

este scris numele Use Case-ului respectiv.

Asocier
e

Asocierea este utilizat pentru a indica legtura dintre un Actor i un

Use Case, n sensul c actorul particip ntr-un fel oarecare n Use
Case.

Notaie

Un exemplu simplu de utilizare a diagramei este urmtorul:

Fig. 11.1. Exemplu de diagram Use Case

ntre actori i use case-uri pot s existe relaii

 de generalizare - un actor sau un use case poate fi asimilat unei clase de

actori

de specializare - un actor sau un use case poate fi asimilat unei clase de use
case-uri.

Fig. 11.2. Exemplu de relaie de specializare

Relaia de tip extensie ntre use case-uri. Relaiile de tip extensie (i implicit Use Caseurile de extensie) se folosesc atunci cnd se modeleaz un comportament opional sau
excepional, care nu condiioneaz finalitatea Use Case-ului de baz. De exemplu, un
utilizator poate, n cazuri excepionale s aleag s depun o reclamaie dup efectuarea
unei comenzi (fig. 11.3).

Fig. 11.3. Exemplu de relaie de tip extensie

Relaia de tip includere. Relaia de tip includere se folosete atunci cnd Use Case-ul
inclus nu este o parte esenial a fluxului din Use Case-ul de baz sau este un
comportament care se repet n mai multe Use Case-uri. De pild autentificarea n sistem,
dei condiioneaz introducerea unei comenzi, nu este specific introducerii comenzii i de
asemenea, poate fi folosit n mai multe Use Case-uri (fig. 11.4):

Fig. 11.4. Exemplu de relaie de tip includere

11.1.2.

Diagrama de Activitate

Activity Diagram reprezint o modalitate de modelare vizual a fluxurilor. Cu ajutorul

Activity Diagram pot fi modelate foarte bine Use Case-urile, dar, n aceeai msur, aceste
diagrame pot fi folosite pentru modelarea proceselor de business (fr legtur cu sistemul
informatic). n privina notaiilor, acestea sunt foarte asemntoare cu cele din Statechart
Diagram deoarece Activity Diagram nu sunt altceva dect o variaie a Statechart Diagram.
Elementele utilizate i notaiile lor sunt urmtoarele prezentate n tabelul 11.2.
Element
Activitate
Aciune
Stare
iniial
Stare final
Tranziie

Decizie

Condiie
(guard)

Bara de
sincronizar
e

Culoar
(swimlane)

Tab. 11.2. Elementele unei Activity Diagram i notaiile lor

Descriere
Notaie
Prin activitate vom desemna ntreaga activitate
modelat prin diagram (format dintr-o succesiune de
aciuni). Aceasta corespunde unui task de business.
Teoretic, aciunile sunt numite Activity States i
reprezint aciuni desfurate n cadrul unui task, sau,
privite altfel, aciuni ale unui obiect.
Reprezint punctul de intrare n activitatea respectiv.
Punctul iniial este unic i din el pornete ntotdeauna o
singur tranziie.
Reprezint punctul de ieire din activitate. Pot fi mai
multe puncte de ieire dintr-o activitate.
La ncheierea unei aciuni se trece ntotdeauna la o alt
aciune sau la starea final. Tranziia reprezint
trecerea de la o aciune la alta.
Printr-o decizie (sau punct de decizie) se modeleaz un
punct din cadrul fluxului unde se face o alegere, pe o
anumit ramur din flux. n acest caz tranzaciile de
ieire trebuie s fie de tip condiie. Aceeai notaie se
folosete i pentru reunirea fluxurilor dup o decizie
precedent (caz n care nu mai sunt necesare
condiiile).
Este un tip special de tranziie, utilizat la fiecare dintre
ieirile posibile dintr-o decizie. Se marcheaz ca un text
pe sgeat i arat condiia care trebuie ndeplinit
pentru a urma acel flux.
Este folosit pentru cazurile n care anumite aciuni se
pot desfura n paralel. ntr-un asemenea punct poate
avea loc fie separarea fluxurilor, fie reunirea lor, dup o
separare anterioar. Reunirea a dou fluxuri nseamn,
de fapt, introducerea unei condiii, prin care o activitate
nu poate ncepe dect dup terminarea activitilor
finale din fluxurile ce trebuie sincronizate (de aici
termenul de sincronizare).
Culoarele sunt reprezentri care permit separarea
activitilor din flux dup criteriul responsabilitii
realizrii activitii.

Punctele de decizie sunt puncte din fluxul de activiti n care se face o anumit alegere
ntre mai multe variante posibile. Un caz simplu este ilustrat n figura 11.5.

Fig. 11.5. Exemplu de punct de decizie

Trebuie observat c tranziiile care ies dintr-un punct de decizie sunt de tip guard au nscris
ntre paranteze ptrate o condiie. Notaia utilizat pentru punctul de decizie poate fi folosit
i pentru reconectarea fluxurilor (merge point), aa cum se poate vedea n figura 11.6.

Fig. 11.6. Exemplu de reconectare a fluxurilor

Aciunile paralele (asincrone) sunt aciuni care se pot desfura simultan. De obicei ele
nu depind una de cealalt. Paralelizarea aciunilor se reprezint pe diagram n felul urmtor:

Fig. 11.7. Exemplu de paralelizare a aciunilor

Aceast reprezentare ne arat c aciunile Verificare stoc i Verificare bonitate client sunt
declanate de apariia unei comenzi de la client i c aceste aciuni sunt independente ntre
ele (nceperea uneia nu depinde de rezultatul celeilalte). Revenirea la fluxul unic (cu aciuni
sincronizate) se face n felul urmtor:

Fig. 11.8. Revenirea la fluxul unic

Reprezentare ne arat c livrarea la client depinde de finalizarea aciunilor independente
"Verificare stoc" i "Verificare bonitate client", astfel c aciunea "Livrare la client" nu poate
ncepe dect dup finalizarea ambelor aciuni. Pentru a aduga pe diagrame informaia
privind responsabilitatea executrii aciunilor se folosesc elementele denumite swimlanes,
plasndu-se fiecare aciune pe "culoarul" actorului care execut acea aciune (fig. 11.9).

Fig. 11.9. Plasarea pe culoare a aciunilor

11.1.3.

Statechart Diagram

Diagramele de tip Statechart sunt utilizate pentru a specifica posibilele stri prin care poate
trece un obiect i modul n care se poate trece de la o stare la alta (modelare work-flow-uri,
modelare fluxuri de documente, diagrame de stri). Trecerea de la o stare la alta este
determinat de tranzaciile intermediare - acestea corespund Aciunilor pe care le-am ntlnit
la Activity Diagram (pn la urm, Statechart Diagram reprezint un alt mod de a vedea un
flux ce poate fi modelat exclusiv prin Activity Diagram, inventat pentru a exprima mai
elocvent trecerile de la o stare la alta).
De exemplu, o comand primit de la un client poate fi iniial n stare de ateptare, pentru ca
un operator s verifice bonitatea clientului i stocul i s accepte comanda. Dup acceptare,
se poate produce livrarea produselor comandate i comanda trece n starea de comand
livrat dup care urmeaz facturarea i nchiderea comenzii. Elementele utilizate i notaiile
lor sunt prezentate n tabelul 11.3.
Tab. 11.3. Elementele unei Statechart Diagram i notaiile lor
Notaie

Element

Descriere

Stare

Indic starea n care se gsete obiectul la un moment

dat.

Stare
iniial
Stare final
Tranziie

Reprezint punctul de intrare sau punctul n care

obiectul este iniiat. Punctul iniial este unic.
Reprezint punctul de final cnd starea obiectului nu
se mai modific.
Tranziia reprezint trecerea de la o stare la alta,
provocat de apariia unui anumit eveniment.

n afara elementelor specifice enumerate mai sus se pot folosi punctele de decizie i aciunile
paralele (asincrone) la Activity Diagram. n figura 11.10 este exemplificat folosirea
elementelor specifice Statechart Diagram, pentru cazul unei comenzi.

Fig. 11.10. Folosirea elementelor Statechart Diagram

11.1.4.

Diagrama Claselor

Un limbaj de programare pune la dispoziia programatorului un numr de tipuri predefinite,

care ns, n mod frecvent, nu corespund tuturor conceptelor necesare programului. ntr-un
limbaj obiect-orientat astfel de concepte se implementeaza prin intermediul claselor. O clas
este un tip de dat definit de utilizator. O declarare a unei clase definete un tip nou care
reunete date i funcii. Acest tip nou poate fi folosit pentru a declara obiecte de acest tip. Un
obiect este un exemplar (instan) a unei clase.
Corpul clasei conine definiii de date membre ale clasei i definiii sau declaraii (prototipuri)
de funcii membre ale clasei, desprite prin unul sau mai muli specificatori de acces. Un
specificator de acces poate fi unul din cuvintele cheie: public, private, protected.
Specificatorii private i protected asigur o protecie de acces la datele sau funciile membre
ale clasei respective, iar specificatorul public permite accesul la acestea i din afara clasei.
Efectul unui specificator de acces dureaz pn la urmtorul specificator de acces. Implicit,
dac nu se declar nici un specificator de acces, datele sau funciile membre sunt de tip
private.
Cu alte cuvinte, clasa este elementul de baz al unui sistem orientat-obiect. Clasa este o
descriere a seturilor omogene de obiecte cu proprieti intrinseci - atribute, operaii, relaii i
semantic.

n cadrul modelului fiecrei clase i este atribuit un nume unic, care permite s se fac
distincia de alte clase. Dac este utilizat un nume compus (la nceputul numelui se adaug
numele pachetului, care include clasa), numele clasei trebuie s fie unic n pachet.
Atributul reprezint o proprietate a clasei i poate lua mai multe valori. Setul de valori
admisibile ale atributului formeaz domeniul de valori. Atributul are un nume i reprezint o
proprietate a entitii simulate comun pentru toate obiectele din acea clas. O clasa poate
avea orice numr de atribute.

Operaia reprezint realizarea funciei, care poate fi solicitat de la orice obiect al calsei.
Operaia arat ce se poate face cu obiectul. Executarea unei operaii este adesea asociat cu
procesarea i modificarea valorilor atributelor sau schimbarea strii obiectului.
Class diagram este un tip de diagram utilizat pentru descrierea structurii statice, adic a
entitilor sau claselor existente ntr-un sistem. Acest tip de diagram este utilizat cel mai
adesea de ctre dezvoltatori pentru specificarea claselor dar poate fi foarte util i pentru
specificarea structurii unor sisteme sau subsisteme dintr-un business real. Elementele
utilizate i notaiile lor sunt prezentate n tabelul 11.4.
Tab. 11.4. Elementele unei Class Diagram i notaiile lor
Element
Descriere
Notaie
O clas este reprezentat printr-un dreptunghi cu trei
compartimente: n cel de sus se trece numele clasei, n
Clas
mijloc se trec atributele clasei iar jos se trec operaiile
specifice clasei.
Indic faptul c o clas motenete caracteristicile unei clase
Motenire
printe.
Asocierea este o relaie generic ntre dou clase. Aceste
relaii pot fi de tipurile pot defini i regulile numerice de
Asociere
asociere (unu la unu, unu la mai muli, mai muli la mai
muli).
Dependen O clas depinde de o alt clas, n sensul c utilizeaz acea

clas ca i atribut al su, se folosete relaia de dependen.

Agregare

Indic o relaie de tip ntreg-parte. n aceast relaie, clasa

copil poate exista i fr clasa printe.

Compozii
e

Deriv din agregare dar se utilizeaz atunci cnd o clas

copil nu poate exista dect n cazul existenei clasei printe.

n figura 11.11 este exemplificat reprezentarea grafic a clasei Comand n notaia UML.

Fig. 11.11. Reprezentarea clasei n UML

Atunci cnd diagrama este folosit pentru a modela structuri de business se pot folosi
tipurile de date specifice businessului, de exemplu: minut, dat calendaristic, etc (fig.
11.12).

Fig. 11.12. Date specific businessului

Motenirea este o relaie prin care se indic faptul c o clas motenete caracteristicile
clasei printe (fig. 11.13). n plus, clasa copil poate avea propriile caracteristici.

Fig. 11.13. Relaia Motenire

Asocierea arat existena unei relaii ntre clase. n exemplul de mai jos, ntre Persoan i
Autovehicul exist urmtoarea relaie: o Persoan poate avea zero, unul sau mai multe
Autovehicule (fig. 11.14).

Fig. 11.14. Relaia Asociere

Un tip special de asociere este indicat printr-o clas de asociere. Altfel spus, relaia n sine
este o clas (fig. 11.15). n exemplul de mai jos, relaia dintre Articol i Lista de preuri este
de tip mai muli la mai muli: un Articol poate s apar pe mai multe Liste i o List poate
avea mai multe Articole. Pe Liste diferite Articolele pot avea preuri diferite.

Fig. 11.15. Exemplu n care Relaia este o clas

Dependena indic faptul c o clas depinde de alt clas, n sensul n care o funcie
oarecare depinde de un parametru al su (fig. 11.16).

Fig. 11.16. Dependena claselor

Agregarea indic faptul c o clas printe are elemente de tipul clasei copil. n exemplul de
mai jos ara poate avea mai multe Judee dar, n acelai timp, un Jude poate exista chiar i
n cazul n care clasa ara nu exist.

Fig. 11.17. Relaia Agregare

ntr-o relaie de tip compoziie clasa copil nu poate exista dect dac exist o instan a
clasei printe. n exemplul de mai jos instana clasei Comisie exist atta timp ct exist
instana clasei Examen.

Fig. 11.18. Relaia Compoziie

11.2.

Etapele proiectrii SI cu ajutorul UML

UML ofer suport pentru toate etapele ciclului de via al SI i prevede n acest scop o serie
de instrumente grafice sub form de diagrame.
La etapa crerii modelului conceptual pentru a descrie activitatea ntreprinderii sunt utilizate
modelele Use Case i diagramele de activitate, pentru descrierea obiectelor business modelul obiectelor business i diagramele de secvene.
La etapa crerii modelului logic al SI descrierea specificaiilor sistemului este dat n form
de modele i descrieri ale cazurilor de utilizare, iar proiectarea unitar este realizat folosind
diagrame de clase, diagrame de secven i diagrame de stare.
La etapa crerii modelului fizic proiectarea unitar este realizat folosind diagramele de
clase, diagramele de componente i diagramele de desfurare (deployment diagrams).
Fig. 11.19 exemplific relaia dintre diferite tipuri de diagrame UML. Vrful de sgeat poate
fi interpretat ca relaia "este sursa de date de intrare pentru ... ". De exemplu , diagrama
cazurilor de utilizare este o surs de date pentru diagramele de activitate i de secvene).
Aceast schem este o ilustrare relevant a naturii iterative a modelrii folosind UML.

Fig. 11.19. Relaia dintre diagramele UML

11.2.1.

Crearea modelului conceptual

Modelul cazurilor de utilizare descrie procesele business din punctul de vedere al unui
utilizator extern, reflect perspectiva organizaiei din exterior.
Proiectarea sistemului ncepe cu studiul i modelarea activitilor organizaiei. La aceast
etap sunt introduse i reflectate n model o serie de concepte caracteristice abordrii
orientate-obiect: Actor, Precedent (Caz de utilizare), Clas, Asociere, Generalizare, Agregare.
n figura 11.20 este prezentat modelul cazurilor de utilizare pentru un centru medical.

Fig. 11.20. Exemplu de model Use Case

Destinaia SI din figura 11.20 const n automatizarea utilizrii nregistrrilor clinice (cartela
medical) despre pacieni. Se presupune c pn la automatizare toat evidena se face
manual de ctre personalul centrului. Fig. 11.20 ofer un model general al centrului ca o
diagrama a cazurilor de utilizare. Precedentul "Deservirea pacientului" este realizat printr-o
varietate de alte cazuri mai limitate (fig. 11.21), care reflect detaliile funcionrii centrului.

Fig. 11.21. Modelul cazurilor de utilizare detalizat

Pentru a fi incluse n diagram cazurile de utilizare selectate trebuie s corepspund
urmtoarelor criterii:

s descrie ceea CE trebuie de fcut i nu CUM;

s descrie aciunile din punctul de vedere al EXECUTORULUI;

s returneze un anumit mesaj EXECUTORULUI;

secvena de aciuni n cadrul unui caz de utilizare trebuie s fie un

lan indivizibil.
Reieind din scopul crerii sistemului pentru cercetarea si modelarea ulterioar vor fi
selectate doar cazurile de utilizare de legate de utilizarea inregistrrilor clinice.
Procesul executrii unui precedent este descris folosind diagramele de activitate, care includ
executorii (actorii) i secvena de execuie a proceselor business conexe (fig. 11.22).

Fig. 11.22. Diagrama activitilor pentru precedentul Acordare asiten medical

Dei acordarea asistenei medicale presupune o gam larg de aciuni ale executanilor,
pentru problema noastr sunt relevante doar procesele schimbului de informaii ntre
executori, i anume acestea sunt reflectate n modelele create. Din aceast cauz diagrama
reflect procesul de evaluare a strii pacientului pe baza informaiilor disponibile.
Cmpul comun al diagramei de activitate este mprit n mai multe "culoare de not",
fiecare dintre care conine o descriere a aciunilor unui actor. Principalele elemente ale
diagramei de activitate sunt notaia strii ("start" , "finalizare") , aciunii (ovale) i
momentului sincronizrii activitilor.
Diagrama permite descrierea aciunilor, att a unui specialist extern, ct i a unui specialist
din cadrul centrului.
Etapa se ncheie cu elaborarea diagramelor de activitate pentru toate precedentele business
selectate. Evident, la etapele ulterioare de analiz i proiectare va fi identificate anumite
detalii importante n descrierea activitilor obiectului de automatizare. Din aceast cauz
modelele elaborate la aceast etap vor fi corectate de mai multe ori.
Modelul obiectelor business prezint executarea proceselor business ale organizaiei de
ctre executorii interni. Principalele componente ale modelelor obiectelor business sunt
actori interni i externi, precum i entitile business, care arat tot ce folosesc actorii interni
pentru realizarea proceselor business. Un exemplu de model al obiectelor business pentru
precedentul "Rspuns la solicitare" este prezentat n Fig. 11.23.

Fig.11.23. Model al obiectelor business pentru precedentul "Rspuns la solicitare"

n aceast diagram a aprut un nou personaj Solicitantul. De fapt, solicitri privind starea
pacientului pot veni de la mai muli actori: un avocat, o companie de asigurri, personalul
tehnic i chiar pacientul nsui. Astfel, termenul "solicitant" este utilizat pentru
reprezentarea generalizat a tuturor acestor actori, n descrierea precedentului "Rspunsul
la solicitare" (Fig. 11.24). "Solicitantul" devine o superclasa pentru conceptele generalizate
(subclase).

Fig. 11.24. Generalizarea claselor

Pentru descrierea detaliat a execuiei proceselor business sunt utilizate diagramele de
secvene (Fig. 11.25).

Fig. 11.25. Diagrama de secvene pentru precedentul "Rspuns la solicitare"

Elementele principale ale diagramei de secvene sunt notaiile obiectelor (dreptunghiuri),
liniile verticale, care semnific trecerea timpului i sgeile, care corespund executrii
aciunilor de ctre obiecte.
Rezultatul acestei etape sunt descrierile coordonate cu beneficiarul i suficient de detaliate
ale aciunilor specialitilor orgnizaiei, care implementeaz SI, necesare pentru a asigura
ndeplinirea funciilor sale.
Crearea modelului conceptual al datelor are loc n baza informaiilor, identificate la etapele
modelrii business. n figura 11.26 sub forma diagramei claselor este prezentat modelul
datelor pentru obiectul nregistrri clinice.

Fig. 11.26. Modelul conceptual al datelor pentru obiectul nregistrri clinice

Modelul arat c nregistrrile clinice includ (agregheaz) anumite blocuri. Suplimentar,

clasele "SetMinDate" i "PlanTratament" pot fi incluse n fiecare nregistrare clinic ntr-un
singur exemplar, iar blocurile "RezultateleAnalize", "PrescriereMedic" i "DerulareTratament"
pot fi repetate de mai multe ori.
Arhiva const ntr-o varietate de nregistrri clinice (agregheaz nregistrrile clinice), dar
poate fi i vid (goal).
Deoarece pacientul poate urma n prealabil tratatul la alte instituii sau repetat n centru,
apar categorii suplimentare (subclase) ale nregistrrilor clinice: nregistrri externe,
nregistrri interne vechi , nregistrri interne noi.
Aceast etap ncheie procedura de modelare business i permite punerea la dispoziia
echipei proiectanilor ntr-un format acceptat reciproc a informaiilor necesare pentru
crearea sistemului. Diagramele elaborate sunt punctul de plecare n procesele de proiectare
a bazelor de date i componentelor program ale sistemului, asigur coordonarea
activitiilor business analitilor i dezvoltatorilor n procesul lucrului ulterior de creare a
sistemului. Aceste diagrame, evident, vor suferi modificri n timpul de proiectrii, ns
aceste modificri vor fi nregistrate ntr-un format familiar pentru ntreaga echip i vor fi
reflectate n mod automat n modelele ulterioare.

11.2.2.

Elaborarea cerinelor sistemului

La etapa formrii cerinelor, este mai nti necesar s fie stabilit domeniul de aplicabilite a
sistemului i s se obin o imagine exact a viitoarelor capabiliti ale sistemului.
Drept baz la formarea cerinelor servete modelul precedentelor (cazurilor de
utilizare) sistemice, care reflect modul n care are loc ndeplinirea obligaiunilor concrete
de ctre executorii interni i externi atunci cnd folosesc sistemul informatic.
n calitate de surs de date pentru crearea modelului cazurilor de utilizare sistemice servesc
modelele busines, dezvoltate la etapa precedent. ns, la crearea modelui este util ca n
prealabil s fie elaborate descrierile detaliate ale precedentelor, care includ definiiile
datelor utilizate i modul exact de executare a precedentelor. Descrierea are loc n
conformitate cu abloanele din organizaie, care includ de obicei urmtoarele
compartimente:

titlul (numele precedentului, responsabilul de executare, data crerii

ablonului/introducerii modificrilor);

descrirea succint a precedentului;

constrngerile;

precondiii (starea necesar a sistemului sau condiiile n care

trebuie s fie efectuat precedentul);

postconditie (strile posibile ale sistemului dup efectuarea

precedentul);

ipoteze;

secvena principal de activiti;

secvene alternative de activiti i condiii de iniiere a acestora;

punctele de extensie i includere a precedentelor.

n cadrul procesului de creare a modelului precedentelor sistemice are loc transformarea i
deplasarea componentelor modelelor business pe diagrame noi. Transformrile tipice
conform tehnologiei Rational Unified Process sunt prezentate n tabelul 11.5.
Tabelul 11.5. Transformrile conform Rational Unified Process
Elementele modelului precedentelor
Elementele modelului business
sistemice
Precedente business
Subsisteme
Executori externi
Executori
Executori interni
Executori sau precedente

Procese, executate de executori interni

Precedente

n figura 11.27 este prezentat modelul precedentelor sistemice pentru precedentul business
Acordare asisten medical. Reieind din scopul crerii sistemului n modelul
precedentelor sistemice sunt reflectate doar activitile executorilor, legate de acordarea
accesului i actualizarea nregistrrilor clinice.

Fig. 11.27. Exemplu de model al precedentelor sistemice

Funciile descrise de model sunt caracteristice doar pentru un tip de activitate acordarea
asistenei medicale, i, n linii generale, nu sunt utilizate n alte tipuri de activiti ale
Centrului. Aceast permite icluderea funciilor selectate ntr-un subsistem al sistemului
informatic proiectat.
Executorul intern Personalul Centrului (fig. 11.22) i procesul manual executat de acesta
a fost transformat n precedentul de sistem Acordare acces (fig. 11.27).
Executorii externi (de ex., Productorii de echipamente medicale interacioneaz direct cu
sistemul proiectat- sunt transformai n utilizatori.
n model au fost reflectate dou tipuri de legturi ntre precedente (elipsele cu umbre):

uses un precedent n procesul execuiei sale ndeplinete

obligator un oarecare bloc de aciuni, care formeaz un alt precedent;

extends precedentele sunt asemntoare, ns unul poart o

ncrctur funcional mai mare.
Precedentul Verificare drepturi a aprut pentru prima data n diagram i este realizat prin
mijloacele sistemului elaborat. Din aceast cauz pentru acest Use Case trebuie creat
diagrama secvenelor, care descrie modul n care are loc execuia lui (fig. 11.28).

Fig. 11.28. Diagrama secvenelor pentru Use Case Verificare drepturi

Ca i rezultat, n sistemul proiectat apar dou obiecte noi modulul program Managerul
protecie i blocul informaional Setul de drepturi.
Astfel, rezultatul elaborrii modelului precedentelor de sistem va include nu doar
enumerarea exhaustiv a funciilor, care vor fi realizate n sistem, dar i descrierea detaliat
a modalitii de realizare a acestor funcii.
Analiza cerinelor i proiectarea prealabil a sistemului presupune soluionarea urmtoarelor
probleme:

stabilirea proiectului sistemului, care va ndeplini toate cerinele

business;

elaborarea unui proiect preliminare comun pentru toate echipele de

dezvoltatori (proiectanii BD, programatorii, arhitecii de sistem, etc.).

n calitate de instrumentul principal aici vor servi diagramele claselor sistemului, care sunt
construite n baza modelului precedentelor de sistem. n acelai timp n cadrul acestei etape
vor fi precizate diagramele de secvene ale unor precedente, ceea ce va conduce la
modificarea listei de obiecte i a diagramelor claselor. Aceasta este o reflectare natural
folosind instrumentele UML a procesului iterativ de elaborare a sistemului.
Diagramele claselor sistemului sunt suplimentate cu obiectele modelului precedentelor de
sistem. Ele conin descrierea acestor obiecte sub form de clase i a interaciunii claselor.
Diagrama claselor, care descrie procedura proteciei datelor, este prezentat n figura 11.29.

Fig. 11.29. Diagrama claselor Protecia accesului

Rezultat al acestei etape a proiectrii este descrierea realtiv detaliat a funciilor sistemului
proiectat, precum i informaiile care trebuie s fie utilizate n BD i modulele program.
Deoarece diagramele de clase sunt construite n baza modelelor business elaborate anterior
, apare ncrederea c sistemul dezvoltat va respecta ntr-adevr cerinele iniiale ale
clientului.
n acelai timp , datorit sintaxei sale , diagramele de clase sunt un bun mijloc de
structurare i de prezentare a cerinelor funcionale, interfeelor i datelor pentru
elementele sistemului proiectat.

11.2.3.

Elaborarea modelelor BD i aplicaiilor

I n cadrul acestei etape are loc reflectarea elementelor modelelor claselor, construite
anterior, n elemente ale modelului BD i modulelor program:

clasele sunt reprezentate prin tabele;

atributele prin coloane ale tabelelor;
tipurile prin tipuri de date ale SGBD utilizat;
asocierile prin legturi ntre tabele (asocierile de tip muli-lamuli sunt transformate n asocieri de tip unul-la-muli prin crearea tabelelor
suplimentare de legtur);

modulele program sunt transformate n clase separate cu metode i

atribute definite i legate de date (din BD).
Deoarece modelele bazei de date i modulelor program sunt construite n baza unui model
logic unic, legarea acestor proiecte este asigurat n mod automat (fig. 11.30).

Fig. 11.30. Legtura ntre proiectele BD i aplicaiilor

n modelul BD sunt reflectate doar clasele permanente din care sunt eliminate atributele
lips n coloane (de exemplu, atributul Volumul total de vnzri, care este obinut prin
adunare a coninutului cmpurilor respective ale BD). Unele atribute (de exemplu, ADRESA)
pot fi transformate ntr-o mulime de coloane (INDICELE POTAL, STRADA, BLOC, ORA,
ARA).
Pentru fiecare clas simpl n modelul BD este construit un table separate, care include
coloanele corespunztoare atributelor clasei.
Reprezentarea n tabele a claselor subtipurilor este realizat folosind una din standard:

un tabel pentru fiecare clas;

un tabel pentru fiecare superclas;

un tabel pentru fiecare ierarhie;

n primul caz pentru fiecare clas este construit un tabel propriu, apoi sunt introduse
legturile necesare ntre aceste tabele. n cel de-al doilea caz este creat un tabel pentru o
superclas, dup care n fiecare tabel al unei subclase sunt introduse coloane suplimentare
pentru fiecare atribut al superclasei. n al treilea caz este creat un tabel unic, care include
att atributele superclasei, ct i tuturor subclaselor (fig. 11.31). Pentru evidenierea
tabelelor iniiale ale subclaselor n tabelul rezultant sunt introduse una sau mai multe
coloane suplimentare (n fig. 11.31 indicat prin font cursiv).

Fig. 11.31. Ttransformarea unei ierarhii n tabel

Pentru elaborarea proiectului BD este utilizat un profil special al UML - Profile for Database
Design, care include urmtoarele componente principale ale diagramelor:

tabel set de nregistrri ale BD pentru un anumit obiect;


coloan element al tabelului, acre conine valoarea unui din
atrbutele tabelului;

cheie primar (PK) atribut care identific n mod univoc o linie a

tabelului;

cheie extern (FK) un atribut sau un grup de atribute ale unui

tabel, care pot fi utilizate n calitate de cheie primar a unui alt tabel;

relaie obligatorie - relaia dintre dou tabele n care tabelul copil

exist numai n legtur cu printele;

conexiune opional - legtura ntre tabele, n care fiecare tabel

poate exista independent de celelalte;

imagine - un tabel virtual care are toate proprietile unui tabel

obinuit, dar nu este stocat permanent n baza de date;

procedur stocat funcie de prelucrare a datelor realizat pe

serverul BD;

domeniu - set de valori admisibile pentru o coloan a tabelului.

n figura 11.32 un fragment al tabelului BD dou tabele, care corespund claselor Pacient
i Set minim de date. Legtura ntre ele este obligatory, deoarece Set minim de date nu
poate exista fr Pacient.

Fig. 11.32. Fragment al modelului BD

Pe diagrame sunt indicate caracteristici suplimentare ale tabelelor i coloanelor:

constrngeri determin valorile admisibile ale datelor unei coloane

sau ale unei operaii asupra datelor (cheie (PK, FK) constrngere, care determin
tipul cheii i coloana ei; verificare (Check) constrngere, care stabilete regula de
verificare a datelor; unicitate (Unique) - constrngere, care determin c o coloan
conine date irepetabile);
Ieirea etapei este descrierea detaliat a proiectului BD i a aplicaiilor.

11.2.4.

Proiectarea realizrii fizice a sistemului

La aceast etap modelele BD i aplicaiilor sunt suplimentate cu notaiile amplsrii lor pe

mijloacele tehnice. n figura 11.33 este prezentat mprirea tabelului Pacient n trei
extent (Tablespace) conform primei litere din numele pacientului.

Fig. 11.33. Fragment al diagramei de desfurare

Proiectarea unui SI complex are loc prin descompunerea sistemului n pri componente,
analiza i crearea subsistemului pentru fiecare component n parte. Sunt utilizate dou
abordri de descompunere a SI n subsisteme: structural (sau funcional) i obiectual (pe
componente).
Din punctul de vedere al proiectrii SI esena decompoziiei funcionale poate fi exprimat
prin formula Program = Date + Algoritmi. n acest caz structura sistemului este descris
folosind schemele-bloc, nodurile crora reprezint centre de procesare (funcii), iar
legturile dintre noduri sunt reprezentate prin deplasarea datelor.
n cazul decompoziiei obiectuale n sistem sunt evideniate entitile active obiectele
(sau componentele), care interacioneaz prin schimb de mesaje, ndeplinind funciile
(metodele) respective ale obiectului.
n primul caz se recomand utilizarea notaiilor IDEF, n cel de-al doilea utilizarea UML.
n acelai timp, la alegerea metodologiei de creare a SI trebuie de luat n consideraie, c
modelele vizuale sunt utilizate tot mai larg n tehnologiile contemporane de management a
procesului de proiectare a SI, complexitatea, scalabilitatea i funcionalitatea crora crete
constant. Modelele vizuale sunt uor de adaptat pentru soluionarea unor probleme, care
apar frecvent la crearera sistemelor informatice, de exemplu: rerepartizarea fizic a
calculelor i datelor, asigurarea paralelismului, replicarea BD, acces securizat, optimizarea
balansrii sarcinii SI, rezisten la cderi .a. Modelele vizualizate cu ajutorul mijloacelor
UML permit desfurarea unei cooperri productive ntre reprezentanii beneficiarului,
utilizatorii i echipa dezvoltatorilor SI. Ele asigur claritate n prezentarea soluiilor
arhitecturale selectate i permit nelegerea n ntreaga totalitate a SI elaborat.

12.

Studiu de caz Compania MED

1. Studiu de caz Compania MED