Proiectarea sistemelor informaionale

CONINUT
1.

INTRODUCERE ...................................................................................................................................................... 3

1.1.

NOIUNI DE BAZ DIN PROIECTAREA SISTEMELOR INFORMAIONALE ........................... 3

1.1.1.
1.1.2.
1.1.3.
1.1.4.
1.2.

ETAPELE PROCESULUI DE CREARE A SI ............................................................................................... 8

1.2.1.
1.2.2.
1.2.3.
1.3.

FORMAREA CERINELOR ......................................................................................................................................... 9

PROIECTAREA ......................................................................................................................................................... 9
REALIZAREA I TESTAREA.................................................................................................................................... 10

METODOLOGII DE REALIZARE A SISTEMELOR INFORMATICE ............................................... 11

1.3.1.
1.3.2.
1.3.3.
1.3.4.
2.

OBIECTUL I METODELE CURSULUI ....................................................................................................................... 3

SISTEME INFORMAIONALE I SISTEME INFORMATICE ........................................................................................ 3
CLASIFICRI ........................................................................................................................................................... 5
SCURT ISTORIC ...................................................................................................................................................... 7

CONINUTUL METODOLOGIILOR DE REALIZARE A SISTEMELOR INFORMATICE ................................................ 11

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

CICLUL DE VIA A PRODUSELOR PROGRAM ..................................................................................... 13

2.1.

MODELE ALE CICLULUI DE VIA ......................................................................................................... 14

2.1.1.
2.1.2.
2.1.3.
2.2.

PROCESELE CICLULUI DE VIA ........................................................................................................... 18

2.2.1.
2.2.2.
2.2.3.
2.2.4.
3.

MODELUL CASCAD .............................................................................................................................................. 14

MODELUL SPIRAL................................................................................................................................................ 15
ALTE MODELE ........................................................................................................................................................ 16

PROCESELE CONFORM ISO/IEC 12207 ........................................................................................................... 18

CONINUTUL PROCESELOR PRIMARE ................................................................................................................... 19
PROCESELE CONFORM ISO/IEC 15288 ........................................................................................................... 20
ALTE STANDARDE I REGLEMENTRI .................................................................................................................. 21

ORGANIZAREA PROCESELOR DE DEZVOLTARE A SISTEMELOR INFORMAIONALE ......... 23

3.1.

PROIECTAREA CANONIC A SI .............................................................................................................. 23

3.1.1.
3.1.2.
3.1.3.
3.1.4.
3.1.5.
3.2.

PROIECTAREA TIP ........................................................................................................................................ 31

3.2.1.
3.2.2.
3.2.3.
4.

ETAPELE PROIECTRII CANONICE ........................................................................................................................ 23

ANALIZA SITUAIEI I IDENTIFICAREA CERINELOR SISTEMULUI NOU ............................................................ 24
ELABORAREA CONCEPIEI SI I SARCINII TEHNICE ........................................................................................ 27
PROIECTUL TEHNIC............................................................................................................................................... 29
DOCUMENTAIA .................................................................................................................................................... 31

SOLUIA PROIECT TIP .......................................................................................................................................... 32

ETAPELE REALIZRII............................................................................................................................................. 33
MODELE DE COMPONENTE ................................................................................................................................... 34

ANALIZA I MODELAREA SPAIULUI FUNCIONAL AL IMPLEMENTRII SI ....................... 35

4.1.

MODELUL BUSINESS COMPLET AL COMPANIEI ............................................................................. 35

4.2.

ABLOANELE MODELRII BUSINESS ORGANIZAIONALE ....................................................... 38

4.2.1.

ABLONUL PENTRU ELABORAREA MISIUNII ........................................................................................................ 38

4.2.2.
4.2.3.

ABLOANE PENTRU FORMAREA AFACERILOR ...................................................................................................... 40

ABLONUL DE DESCRIERE FLUX-PROCES............................................................................................................ 43

4.3.

CONSTRUIREA MODELULUI ORGANIZAIONAL-FUNCIONAL AL COMPANIEI .............. 43

4.4.

MIJLOACE INSTRUMENTALE PENTRU MODELAREA ORGANIZAIONAL .......................... 49

5.

SPECIFICAREA CERINELOR FUNCIONALE........................................................................................ 50

5.1.

MODELE DE FLUX PROCESUALE ............................................................................................................. 50

5.2.

ELEMENTELE DE BAZ ALE ABORDRII PROCESUALE................................................................ 52

5.3.

SELECTAREA I CLASIFICAREA PROCESELOR ................................................................................ 53

5.3.1.
5.3.2.
5.3.3.
5.3.4.
5.3.5.

TIPURI DE PROCESE BUSINESS............................................................................................................................ 53

PROCESELE DE BAZ ............................................................................................................................................ 54
PROCESELE DE MANAGEMENT .............................................................................................................................. 55
PROCESELE DE ASIGURARE.................................................................................................................................. 57
MODELUL BUSINESS DE REFERIN .................................................................................................................... 58

5.4.

ANALIZA ACTIVITII NTREPRINDERII ......................................................................................... 58

5.5.

REZULTATELE ETAPEI DE ANALIZ ...................................................................................................... 61

6.

METODOLOGIA MODELRII DOMENIULUI OBIECTIV ..................................................................... 61

6.1.

MODELUL STRUCTURAL AL DOMENIULUI OBIECTIV ................................................................... 62

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

METODOLOGII ORIENTATE PE FUNCII I ORIENTATE PE OBIECTE ................................. 65

6.2.1.
6.2.2.
6.2.3.
6.2.4.
6.3.
7.

STRUCTURA OBIECTUAL ..................................................................................................................................... 63

STRUCTURA FUNCIONAL .................................................................................................................................. 63
STRUCTURA MANAGEMENTULUI ........................................................................................................................... 64
STRUCTURA ORGANIZAIONAL .......................................................................................................................... 64
STRUCTURA TEHNIC ........................................................................................................................................... 64

METODOLOGIA IDEF0......................................................................................................................................... 66
METODA FLUXURILOR DE DATE ........................................................................................................................... 68
METODA OBIECT-ORIENTAT .............................................................................................................................. 70
COMPARAREA METODELOR ................................................................................................................................... 72

METODA SINTETIC ..................................................................................................................................... 73

MODELAREA PROCESELOR BUSINESS N BPWIN ............................................................................. 75

7.1.

MEDIUL INSTRUMENTAL BPWIN ........................................................................................................... 75

7.2.

CONSTRUIREA MODELULUI IDEF0 ....................................................................................................... 76

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.

OBIECTIVUL MODELRII ....................................................................................................................................... 77

TIPURI DE DIAGRAME ........................................................................................................................................... 79
TIPURI DE SGEI ................................................................................................................................................ 82
CODURILE ICOM ................................................................................................................................................. 84
SGEILE LIBERE I LEGATE................................................................................................................................ 85
TUNELAREA SGEILOR ....................................................................................................................................... 90
NUMEROTAREA ACTIVITILOR I DIAGRAMELOR.............................................................................................. 91
DIAGRAMELE ARBORELUI NODURILOR I FEO................................................................................................... 92
CHENARUL DIAGRAMEI ......................................................................................................................................... 94

7.3.

REUNIREA I DESPRIREA MODELELOR ........................................................................................ 96

7.4.

CREAREA RAPOARTELOR N BPWIN .................................................................................................... 97

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: formarea cerinelor, proiectarea conceptual,
specificarea aplicaiilor, modelarea, integrarea i testarea. Metode de ingineria software n
proiectarea SI.
1.1.1. Obiectul i metodele cursului
Suportul de curs este direcionat spre studierea metodelor moderne i mijloacelor de proiectare a
sistemelor informaionale (SI), inclusiv instrumentele CASE. Vor fi studiate componena i
structura claselor SI ca obiecte de proiectare, tehnologiile moderne de proiectare a SI i metodele
de motivare a eficienei utilizrii lor, lista i coninutul etapelor proiectrii SI, particularitile
etapelor n dependen de tehnologia proiectrii, scopurile i obiectivele cercetrilor preproiect,
netodele de modelare a proceselor informaionale, clasificri i caracteristici generale ale
instrumentelor CASE moderne.
Baza tiinific a cursului este format din metodologiile analizei de sistem i modelrii, care
permit soluionarea urmtoarelor probleme:
asigurarea funcionalitilor solicitate ale sistemului i adaptarea la condiiile variabile de
funcionare;
proiectarea obiectelor, realizate n sistem;
realizarea 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, i anume:
topologia reelei, configurarea resurselor tehnice, arhitectura folosit, procesare paralel,
procesare distribuit a datelor .a.m.d.
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 obiinute, 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 de decizie (S.D.),
Sistemul informaional (S.I.),
Sistemul condus sau operaional (S.O.).

Fig. 1.1. Structura unei organizaii

Sistemul informatic face legtura ntre sistemul condus (SO) i sistemul de conducere (SD),
fiind subordonat acestuia. Sistemul informatic este un ansamblu structurat de elemente
intercorelate funcional pentru automatizarea procesului de obinere a informaiilor i pentru
fundamentarea deciziilor.
Pentru ca o organizaie s-si satisfac necesarul de informaie, are nevoie de un sistem
informaional. Sistemul informaional este un ansamblu om-main care n baza cunotinelor din
domeniul de activitate al organizaiei achiziioneaz, stocheaz, proceseaz i prezint informaii
la nivel intra i extra organizaional. Sistemul informatic este inclus n cadrul SI, presupunnd
partea automatizat a acestuia.
Sistemul informaional este ansamblul de oameni, echipamente, produse program, procese i
date destinate s furnizeze informaii active sistemului decizional, informaii necesare n
elaborarea de soluii pentru problemele cu care se confrunt organizaia. Sistemul informaional
face legatura ntre sistemul de conducere i sistemul condus i este subordonat sistemului de
conducere.
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 difuzare
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 sistemele operaional i decizional precum i informaiile ce

provin din mediul extern;
s prelucreze informaiile la cererea sistemelor operaional i 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 ntr-o 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 (atenie!), dac acceptm includerea n
sfera sistemului informatic a activitii de conducere a proceselor tehnologice cu ajutorul
calculatoarelor 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 sistemului informational.
Caracteristicile sistemului informatic:
orice sistem trebuie s conin ca element central o baz de date (BD), n care s fie
stocate date intercorelate intre ele provenind de la surse interne i externe;
informaiile furnizate de sistem trebuie obigatoriu s fie autentice, exacte, iar suportul de
prezentare s varieze de la un nivel de conducere la altul;

sistemul trebuie s nglobeze o varietate de modele matematice, tehnico-economice

(modele de optimizare, modele de simulare, modele de eficien), etc.;
sistemul trebuie conceput ca un sistem om-main oferind astfel posibilitatea unei
interaciuni imediate ntre utilizator i sistem;
sistemul trebuie s prezinte un grad ct mai ridicat de integrare sub urmtoarele dou
aspecte: integrare intern i integrare extern.

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 pstrate, SI se mpart n factografice i de procesare a documentelor.
Sistemele factografice sunt destinate pstrrii i procesrii datelor 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, referate i
texte. 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 informaionale 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 sarcini cu calcule numerice i prelucrarea unor cantiti mari de date.
Ca exemplu, pot fi menionate SI de planificare a produciei sau a comenzilor, sistemele de
eviden contabil.
Sistemele de asistare a procesului 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
companii 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 modulele
SIC sunt prezentate n tabelul 1.1.
Tabelul 1.1. Destinaia funcional a modulelor SIC
Subsistemul
marketing

Subsistemele
producere

Subsistemele
eviden
financiar

Subsistemul
evidena
resurselor
umane

Alte subsisteme

Cercetarea pieei
i prognoza
vnzrilor

Planificarea volumelor
de lucru i elaborarea
planurilor calendaristice

Administrarea
portofoliului de
comenzi

Analiza i prognoza
necesitilor n
resurse umane

Controlul activitii
companiei

Gestiunea
vnzrilor

Controlul operativ i
gestiunea produciei

Managementul
politicii de creditare

Meninerea arhivei
de personal

Depistarea
problemelor
operative

Recomandri
privind produsele
noi

Analiza modului de
funcionare a
echipamentelor

Elaborarea planului
financiar

Analiza i stabilrea Participare la formarea

preurilor
comenzilor clienilor

Analiza financiar i
prognozarea

Evidena
comenzilor

Gestiunea bugetului,
evidena contabil i
calcularea salariului

Gestiunea stocurilor

Analiza i
planificarea
pregtirii cadrelor

Analiza situaiilor de
gestiune operativ
i strategic
Asigurare elaborare
soluii strategice

Analiza situaiei curente a pieei sistemelor informaionale demonstreaz o tendin stabil de

cretere a cererii n SI corporative. n special, se observ o cretere substanial la sisteme
integrate, automatizarea unor funcii separate fiind considerat etap trecut de multe organizaii.
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 locale

Sisteme integrate
mici

Concorde XAL
Exact
NS-2000
Platinum
PRO/MIS
Scala
SunSystems
-
1C-

Sisteme integrate medii

Microsoft-Business
Solutions - Navision,
Axapta
J D Edwards
(Robertson & Blums)
MFG-Pro (QAD/BMS)
SyteLine
(COKA/SYMIX)

Sisteme integrate
mari (corporative)

SAP/R3 (SAP AG)

Baan (Baan)
BPCS (ITS/SSA)
OEBS (Oracle EBusiness Suite)

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 i materiale). Aceste sisteme realizeaz legtura ntre
companie i mediul extern. La acest nivel sarcinile, obiectivele, sursele de informaii i algoritmii
de procesare sunt cunoscui apriori i n mare msur sunt bine structurai.
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:
compararea indicatorilor cureni cu cei istorici,
elaborarea unor rapoarte periodice 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.
SI de nivel strategic sprijin managementul superior n rezolvarea problemelor nestructurate, n
planificarea pe termen lung. Sarcina principal a acestor sisteme este s asigure posibilitatea
comparrii schimbrilor care au loc n mediul extern cu potenialul firmei, s asiste procesul de
luare 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 BD (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 ntreprinderi 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 practic lipsete 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 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 a 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 i drepturile 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.
Astfel a aprut necesitatea stringent de formare a unei metodologii noi n proiectarea sistemelor
informaionale. Scopul acestei metodologii este de a reglementa procesul de proiectare a SI i de a
asiguara gestionarea acestui proces, pentru a garanta conformitatea cu cerinele referitoare att la
sistem, precum i la caracteristicile procesului de dezvoltare. Principalele obiective, care trebuie
atinse prin noua metodologie, sunt urmtoarele:

s se asigure crearea de SI corporative, n concordan cu scopurile i obiectivele

organizaiei, precum i cu cerinele pentru 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, adic utilizarea n SI 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.

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), procesarea paralel

sau distribuit a datelor, 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 urmtoarele:
funcionalitatea dorit a sistemului i adaptabilitate la schimbarea condiiilor de funcionare;
productivitate solicitat;
timp de rspuns acceptabil;
fiabilitate i lipsa cderilor;
nivel suficient de securitate;
simplitate n utilizare i ntreinere.
Conform metodologiei moderne, procesul crerii 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, 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 (Computer Aided Software Engineering).
Procesul de creare a SI include o serie de etape (stadii), limitate n timp i care au drept finalitate
crearea unui produs concret model, program, documentaie etc.
Sunt evideniate urmtoarele etape de creare a SI: formarea cerinelor sistemului, proiectarea,
realizarea, testarea, implementarea, exploatarea i mentenana. Ultimile dou etape sunt n afara
prezentului curs.
1.2.1. Formarea cerinelor
Etapa de nceput const n 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. Acest moment fundamental
al metodologiei asigur obiectivitatea procesului de identificare a cerinelor. Mulimea modelelor de
descriere a cerinelor este apoi transformat ntr-un sistem de modele, care descriu proiectul
conceptual al SI. Sunt formate modelele arhitecturale ale SI, cerinele referitoare la asigurarea
program i informaional. Urmeaz formarea arhitecturii resurselor program i resurselor
informaionale, determinarea bazelor de date i identificarea modulelor program, formarea
modelului de cerine fa de programe i crearea acestora, testarea i integrarea.
Scopul etapelor de nceput, care au loc la faza de analiz a activitii organizaiei, 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.
Formarea 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 sunt prezente. Dar adesea
aceste sisteme nu satisfac clienii, solicit o mulime de perfecionri, ceea ce conduce la creterea
brusc a cheltuielilor. Cauz princial a acestei situaii este identificarea incorect sau incomplet a
cerinelor la etapa de analiz.
1.2.2. Proiectarea
La etapa proiectrii sunt create, n primul rnd, modelele datelor. 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
(descrierilor) tuturor modulelelor 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. n cadrul proiectrii
modulelor sunt stabilite interfeele programelor: formatul meniului, forma ferestrelor, tastele
fierbini i apelurile associate, etc.
Ieirile etapei de proiectare sunt:
schema bazei de date (prin utilizarea modelului entitate-relaie (ER), creat la etapa de
analiz);
specificaiile modulelor sistemului (construite n baza modelelor funciilor).
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 alese mecanismele de
coordonare i actualizare utilizate;
omogenitatea BD: omogen - serverele BD de la acelai productor sau eterogen? n
ultimul caz, care va fi modalitatea (produsele program) de asigurare 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.3. Realizarea i testarea
La etapa de realizare (implementare) are loc crearea programelor, instalarea resurselor tenice,
elaborarea documentaiei de exploatare.
Etapa de testare 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 dintre 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 al sistemului n regim standard
de lucru i permite determinarea valorii timpului mediu de bun funcionare. n setul de teste la
stabilitate sunt incluse teste, care imit sarcina de vrf la care poate fi supus sistemul.
Apoi ntreg setul de module este supus testelor de sistem testarea pentru acceptarea intern a
produsului, care indic nivelul lui de calitate. Aici sunt incluse teste de funcionalitate i de
fiabilitate.
Ultima testare o reprezint testarea de acceptare (de primire-predare). 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.3.

Metodologii de realizare a sistemelor informatice

Realizarea sistemelor informatice reprezint o aciune complex, care mbin un numr mare de
activiti: analiz, proiectare, implementare, exploatare [2]. n plus, reclam resurse umane,
materiale i financiare nsemnate, pe o perioad considerabil de timp. Folosirea eficient a acestor
resurse, n scopul obinerii unui sistem informatic 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 [2]:
modalitatea de abordare a sistemelor pentru elucidarea raportului dintre variaiile
sistemului i dinamismul su;
regulile de formalizare a datelor i proceselor de prelucrare;
instrumentele pentru concepia, realizarea i elaborarea documentaiei;
modalitatea de derulare a proiectului i aciunile specifice fiecrei etape (ciclul de viat);
definirea modului de lucru, rolului analitilor i proiectanilor i a raportului dintre ei;
modalitile de administrare a proiectului (planificare, programare, urmrire).
Totodat, metodologiile au rolul de a indica modul de desfurare a acestui proces, stabilind [2]:
componentele procesului de realizare a sistemului informatic (etape, subetape, activiti,
operaii) i coninutul lor;
fluxul parcurgerii (executrii) 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 industrieiFranta), IE (James Martin), SSADM (Marea Britanie);
metodologii orientate obiect: OMT (General Electric -SUA), OOD (Michael Jackson);
metodologii pentru conducerea proiectelor de sisteme informatice: SDM / S, METHOD/ 1
Arthur Andersen, NAVIGATOR (Ernst & Young - James Martin).
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 sisteme, programatorii i alte categorii de persoane implicate, realizeaz procesele de analiz a
sistemului informaional-decizional existent, de proiectare i de introducere a sistemului nou.
Metoda are un caracter general, n cadrul ei aplicndu-se anumite tehnici de lucru [2].
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 orientat-obiect [2]. 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 nivele 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 [1]:
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, orientate-informaii, aprute ca urmare a
popularizrii puternice a ingineriei informaiei a lui JAMES MARTIN, dar i a diagramelor
entitate-relaie ale lui CHEN [3];
metode orientate-obiect.
1.3.3. Caracteristici eseniale ale principalelor metode
Informaia este vzut de DeMarco n 1982, ca fiind posibil de abordat prin 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 [1].
Funciile scot n eviden n mod limitat ceea ce face sistemul. El poate fi vzut i ca un proces,
ntruct elementele sistemului despre care se pstreaz datele de rigoare sunt supuse unor
transformrii funcionale, prin intermediul proceselor [1].
Comportamentul este invocat pentru a reda o alt modalitate de percepie a sistemului, influena
evenimentelor i proprietilor sistemului, i sugereaz dinamica lui [1].
Dintre autorii remarcabili care au abordat descompunerea funcional i enumerm pe civa
cum ar fi DeMarco, Yourdon i Constantine, Jackson, Page-Jones, Marco&Gowan, Warnier-Orr,
Dahl. 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-proces) analitii efectueaz reprezentarea lumii reale prin
simboluri care reprezint fluxul datelor, transformrile datelor, stocarea datelor, entiti externe,
etc. Metoda orientat-proces are un mare grad de asemnare cu descompunerea funcional.
n cadrul metodei orientate spre informaii (orientate-date) dou realizri importante n domeniu
au dat tonul unei orientri n abordarea sistemelor: modelarea datelor cu ajutorul diagramelor
entitate-relaie, de ctre Peter P. Chen (1976) i ingineria informaiei, n viziunea lui James Martin.
Metoda orientat-obiect constituie o categorie particular a metodelor de dezvoltare software, care
privesc construirea sistemelor 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 CASE-ului (Proiectarea Sistemelor/Programelor asistat de calculator 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, constituindu-se sistemele distribuite. Obiectivul principal al CASE-ului l constituie
punerea n practic a produselor-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
CASE a acordat atenia cuvenit analizei, proiectrii i programrii orientate pe obiecte [1].
Majoritatea produselor soft au fost construite n mod artizanal, fr posibilitatea testrii complete a
lor, fiind nsoite de o documentaie slab. 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 realizate pentru a ncuraja abordarea logicii
structurale i pentru folosirea calculatorului ca un mod de tezaurizare a lucrrilor 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 [1]:
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 pe care le presupun 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 din diagramele 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/aplicaiei care se proiecteaz. 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 [1].

ntrebri de control
1.

Care este tipul datelor prelucrate n SI factorafice?

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. Stadiile ciclului de via. Standarde.
Metodologia proiectrii sistemelor informaionale descrie procesul crerii i mentenanei sistemelor

prin intermediul ciclului de via a SI, prezentndu-l ca o succesiune de etape i procese, care sunt
executate n cadrul etapelor. Pentru fiecare etap este determinat componena i succesiunea
lucrrilor executate, rezultatele la ieire, metodele i mijloacele necesare pentru ndeplinirea
lucrrilor, rolurile i responsabilitile participanilor .a.m.d. Aceast descriere formal a vieii SI
permite planificarea i organizarea procesului de elaborare colectiv i asigur administrarea
acestui proces.
Ciclul de via poate fi privit ca un ir de evenimente, care se produc n procesul crerii i
exploatrii sistemului.

2.1.

Modele ale ciclului de via

Modelul ciclului de via reflect diferite stri ale sistemului, pornind de la momentul apariiei
necesitii de elaborare a sistemului dat pn la retragerea lui din exploatare. Modelul ciclului de
via poate fi privit ca structura, 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 i modele iterative cu variante
succesive.
2.1.1. Modelul cascad
Modelul cascad (fig. 2.1) stabilete executarea consecitiv 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 de la prima etap i este elaborat design-ul
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 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 n faza urmtoare. Fiecare unitate este
dezvoltat i testat (testare uniti, autonom), 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 se coordoneaz, 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 PP prin activiti de mentenan.
Printre avantajele modelului cascad, se pot meniona:

Documentaia i proiectarea structurii sunt un avantaj dac apar noi membri n echip;
Este un model uor de utilizat i simplu;
Fiecare faz are un rezultat ateptat, datorat rigiditii modelului;
Etapele sunt ndeplinite individual, secvenial (uor de urmrit);

Este recomandat pentru proiectele mici, n care cerinele sunt foarte bine nelese.
Printre dezavantajele acestui tip de model, se numr:

Culegerea specificaiilor n etapa de Cerine este foarte important pentru a proiecta i

implementa produsul corespunztor. Cu toate acestea, cerinele pot fi adugate i dup
finalul acestei etape, fapt ce influeneaz n mod negativ dezvoltarea;
Problemele din cadrul unei etape nu sunt niciodat 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 nou adugate;
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 sa de
flexibilitate la schimbri ale cerinelor. Este focalizat pe analiza riscurilor n mod incremental,
repetnd modelul cascad ntr-o serie de cicluri, ca n figura 2.3.

Fig. 2.3. Modelul spiral

2. Dezvoltarea produsului: proiectarea de detaliu, testarea unitar, 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.
3. Planificarea urmtorului ciclu: evaluarea de ctre client, planificarea dezvoltrii i a
livrrii ctre client. Urmtorul prototip este dezvoltat conform urmtorilor pai:
Evaluarea prototipului precedent n termeni de puncte forte, 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 presupunere 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 n V (V model), modelul ESA ( European Space Agency), Dezvoltarea
Agile, Dezvoltare pe baz de prototip (Prototyping) etc.
Modelul n 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
iteraii din modelul cascad; etapele se deruleaz deci secvenial, urmnd V-ul de la
stnga la dreapta;
cele reprezentate prin linii orizontale, care indic faptul c o parte din rezultatele etapei
din care pleac sgeata sunt utilizate direct n etapa int. De exemplu, la terminarea
etapei de proiectare arhitectural, cazurile de teste 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 i/sau de
interpretare a specificaiilor. n acest ultim caz, limbajele logico-funcionale sunt n mod sigur
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. n 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 prototipare 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 cu proiectarea, este lansat
un prototip pentru a nelege cerinele. Acesta este dezvoltat 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 in cadrul sistemelor mari si complicate, pentru care este
dificil intelegerea cerintelor de la inceput. In astfel de situatii, accesul clientului la prototip
furnizeaza un aport substantial in intelegerea si definirea specificatiilor.
Avantajele acestui model sunt:

Utilizatorii sunt implicai direct n dezvoltare;

Susine tendina utilizatorilor de a-i modifica cerinele pe parcursul ciclului de
implementare;
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:

2.2.

Poate crete complexitatea SI, care se poate extinde dincolo de limitele stabilite iniial;
Analiza insuficient a proiectului ca un 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.

Procesele ciclului de via

Fiecare etap de creare a SI include executarea unor anumite lucrri procese al 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 constau din cinci procese, care formeaz partea de baz a ciclului de
via a produselor program. Partea primar 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 de achizitor, organizaia care achiziioneaz un sistem,
un PP sau un serviciu soft;
o aprovizionare definete activitile de furnizor, organizaie care livreaz sistemul, PP
sau presteaz serviciul solicitat de achizitor;
o dezvoltare - definete activitile de dezvoltator, organizaia care definete 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
meninere 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

o
o
o
o

independent), pentru verificarea produselor program n profunzime, n funcie de

proiect;
validarea - definete activitile (pentru achizitor, furnizor, sau o o persoan
independent), pentru validarea (atestarea) produselor program;
revizuirea comun - definete activitile de evaluare a strii i produselor unei
activiti;
auditarea - definete activitile pentru stabilirea conformitii cu cerinele, planurile
i clauzele contractuale;
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 structurii 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
(executor)

Aciuni

Intrare

Ieire

Achiziie
(achizitor)

Iniierea
Pregtirea cererii de
oferte (licitaie)
Pregtirea i
actualizarea
contractului
Monitorizarea
furnizorului
Acceptarea i
completarea

Decizia privind
lansarea lucrrilor de
implementare a SI
Rezultatele analizei
activitii
achizitorului
Rezultatele analizei
pieei produselor
program
Planul de
furnizare/dezvoltare
Test complex al SI

Studiu de fezbilitate privind

oportunitatea implementrii
Sarcina tehnic pentru
crearea SI
Contract de furnizare/ creare
a SI
Actele de primire a etapelor
lucrrilor
Actul testrilor de
primire/predare

Furnizare
(dezvoltatorul/
furnizorul))

Iniierea
Pregtirea
rspunsului la
cererea de oferte
Pregtirea
contractului

Caietul de sarcini
Decizia conducerii de
participare
Rezultatele licitaiei
Sarcina tehnic
Planul de

Decizia de participare
Oferta comercial/ cerere de
participare la licitaie
Contract de furnizare/ creare
a SI
Planul de management al

Dezvoltare
(dezvoltatorul)

Planificarea executrii
management al
Executare i control
proiectului
Verificare i evaluare SI elaborat i
Furnizarea SI
documentat

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 meninerii
softului

ST pentru elaborarea
sistemului
ST pentru elaborarea
sistemului, modelul
ciclului de via
Subsistemele SI
Specificaiile
componentelor soft
Arhitectura
produselor program
Materialele
proiectrii de
deataliu a produselor
program
Planul de integrare,
testele
Arhitectura SI,
produselor program,
documentaia SI,
testele

proiectului
Realizarea/corectarea
Actul testrilor de
primire/predare
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
iinformaionale. 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;
o management investiional;
o managementul ciclului de via a produselor program;
o managementul resurselor;
o managementul calitii.
3. Procesele proiectului:
o planificarea proiectului;
o estimarea proiectului;
o controlul proiectului;
o administrarea riscurilor;
o managementul configuraiei;

o
o

managementul fluxurilor informaionale;

adoptarea deciziilor.

4. Procesele tehnice:
o identificarea cerinelor;
o analiza cerinelor;
o elaborarea arhitecturii;
o implementarea;
o integrarea;
o verificare;
o transmiterea ctre beneficiar;
o validarea (atestarea);
o exploatarea;
o meninerea;
o 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

Etap

Descriere

Elaborarea
concepiei

Analiza necesitilor, formularea concepiei i alegerea soluiilor de

proiect

Proiectarea

Elaborarea proiectului tehnic al sistemului

Realizarea

Construirea sistemulu

Exploatarea

Lansarea n exploatare i utilizarea sistemului

Mentenana

Asigurarea funcionrii sistemului

Retragerea din uz

Terminarea utilizrii, demontarea, trecerea n arhiv a sistemului

2.2.4. Alte standarde i reglementri

n afara celor dou standarde internaionale, adoptate i de Republica Moldova, exist un ir de
standarde de fact (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.
Printre cele mai cunoscute standarde pot fi evideniate urmtoarele:

GOST 34.601-90 stabilete stadiile i etapele crearii 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 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.

3. Organizarea proceselor de dezvoltare a sistemelor informaionale

Proiectarea canonic a SI. 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.
n dependen de nivelul de utilizare a soluiilor tip, metodele de proiectare a sistemelor
informaionale se mpart n:
metode canonice;
metode tip.
Proiectarea canonic presupune elaborarea sistemelor fr utilizarea unor soluii gata (de la zero)
sau mijloace instrumentale speciale, care s permit integrarea execuiei operaiilor elementare.
Altfel spus, proiectarea canonic reflect particularitile proiectrii manuale (originale,
individuale) 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 lucrri, module programetc.). Pentru realizarea proiectrii tip
exist dou abordri: proiectare orientat pe parametri i 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
permit configurarea soluiilor de proiectare prin modificarea setrilor din modulele de 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, executate de
organizaiile participante, 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 elaborare 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 Conducere.

Etapa 3. Sarcina tehnic

Etapa elaborrii Sarcinii tehnice (ST) include activiti de elaborare prin iteraii a versiunilor ST,
discutarea i perfectarea lor, coordonarea cu i aprobarea de Conducere.
Etapa 4. Proiectarea de detaliu
Activitile componente ale acestei etape sunt:
elaborarea soluiilor de preproiect pentru sistem i prile sistemului;
elaborarea documentaiei de detaliu pentru sisten i prile lui.
Etapa 5. Proiectul tehnic
Include activitile:
elaborarea soluiilor de proiect pentru sistem i prile sistemului;
elaborarea documentaiei de proiect pentru sistem i prile lui;
elaborarea i perfectarea documentaiei de furnizare a componentelor;
elaborarea 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 resurse
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 [2].
Cercetarea sistemului existent const n [2]:
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 locului n sfera serviciilor i/sau sfera produciei;
cunoaterea relaiilor de cooperare cu ali ageni economici;
cunoaterea specificului activitii de baz (producie, servicii);
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 prin [2]:

Pe baza statutului de funcionare a organizaiei se studiaz:

o activitile i sarcinile din cadrul acestor funciuni;
o atribuiile ce revin compartimentelor;
o modul de realizare a activitilor funcionale din cadrul unitii economice.

n cazul activitii de producie se prezint:

o fluxul de producie, amplasarea locurilor de munc, depozitelor etc.;
o tipurile de produse, structura lor, ciclurile de realizare;
o modul de organizare a produciei, stocarea produciei, transporturile interne,
controlul de calitate;
o resursele existente:
capaciti;
asigurarea tehnic;
proiectarea de produse noi;
norme tehnice;
o asigurarea cu materiale necesare;
o sistemul existent de programare a produciei.

Studiul sistemului de conducere se refer la [2]:

identificarea caracteristicilor sistemului de conducere existent;
sistemul de indicatori cantitativi i valorici;
organizarea conducerii;
caracteristicile rezultate din statutul de funcionare a societii, tipuri de decizii, modul de
lucru a deciziilor.
Studiul sistemului informaional presupune [2]:
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 [2].
Formarea cerinelor sistemului nou este 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 [1].
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 ecrane, 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
sprijinire a sistemului, coninutul depozitelor i rapoartele existente n CASE, ecrane i
rapoarte rezultate din prototipurile sistemului, .a [1].
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 [9],
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, este prea mare, 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 independente sau
interconectate, 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 a sistemului;
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.
La elaborarea ST vor fi soluionate urmtoarele probleme:
stabilirea scopului crerii SI, determinarea subsistemelor i a funciilor;
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;
determinarea listei lucrrilor de creare a sistemului i a 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)

Nr
crt

Compartiment

Coninut

1 Generaliti

denumirea complet a sistemului i abrevierea

codul (numrul) temei sau al contractului
denumirea organizaiei executoare i a beneficiarului,
rechizitele lor
lista documentelor n baza crora este creat sistemul
data de ncepere i finalizare a lucrrilor
informaii despre surse i modalitatea de finanare
ordinea de perfectare i prezentare a rezultatelor crerii
SI, prilor sistemului sau a unor module separate

2 Destinaia i scopurile crerii

(modernizrii) sistemului

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

3 Descrierea obiectului
automatizrii

informaii succinte despre obiectul automatizrii

informaii despre condiiile de exploatare i caracteristicile
mediului ambiant

4 Cerine referitoare la sistem

Cerine privind sistemul n totalitate:

o 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)
o 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):
o lista activitilor automatizate
o 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
o metrologice
o organizaionale (structura i funciile departamentelor
de exploatare, protecia contra unor aciuni eronate)
o metodice (documentaia normativ-tehnic)
5 Componena i coninutul
lucrrilor de creare a
sistemului

lista stadiilor i a etapelor

termenii de execuie
lista orgaizaiilor executoare
modalitatea i ordinea expertizrii documentaiei tehnice
programul de asigurare a fiabilitii
programul de asigurare metrologic

6 Modul de testare, verificare i

primire a sistemului

tipurile, componena, volumul i metodele de testare

cerine generale privind acceptarea lucrrilor pe etape
statutul comisiei de primire

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

transformarea informaiilor de intrare n form

mainolizibil
modificrile introduse n obiectul automatizrii
termenii i modalitatea de selectare i instruire a
personalului

8 Cerine privind documentaia

lista documentelor elaborate

lista documentelor pe supori magnetici

9 Surse informaionale

documente i materiale informaionale, n baza crora a

fost elaborat ST i sistemul

Proiectul de detaliu 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 proiectrii
detaliate poate fi exclus din lista lucrrilor.
De obicei, la etapa proiectrii de detaliu 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 prncipalelor 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 de detaliu) este elaborat Proiectul Tehnic al SI (etapa 5).
3.1.4. Proiectul tehnic
Proiectul Tehnic al sistemului informaional 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

Nr
crt

Compartiment

Coninut

1 Not explicativ

cadrul justificativ pentru elaborarea sistemului

lista organizaiilor executoare
caracteristica succint a obiectului cu lista indicatorilor tehnicoeconomici principali de funcionare i legtuarile cu alte obiecte
informaii succinte privind soluiile principale de proiect

2 Structura funcional i
organizaional a
sistemului

justificarea subsistemelor, lista i destinaia lor

lista lucrrilor ndeplininte n cadrul fiiecrui subsistem,
caracteristica succint i coninutul lucrrilor
schema legturilor informaionale ntre subsisteme i lucrri n
cadrul unui subsistem

3 Enunul problemei i
algoritmii de soluionare

natur organizaional i economic a problemei (denumirea,

scopul, rezumat, metoda, periodicitate 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
propuneri privind unificarea documentaiei

6 Resursele matematice

justificarea structurii resurselor matematice

justificarea alegerii mediului de programare
lista resuselor program de sistem

7 Complexul de mijloace
tehnice

descrierea i motivarea schemei procesului tehnologic de

prelucrare a datelor

5 Albumul cu formele
documentelor

justificarea alegerii structurii complexului tehnic i

grupurilior funcionale ale acestuia
motivarea cerinelor privind echipamentele speciale
setul de aciuni pentru asigurarea fiabilitii funcionrii
echipamentelor

8 Calculul eficienei
economice a sistemului

devizul de cheltuieli pentru exploatarea sistemului

calculul eficienei economice anuale obinute din optimizarea
structurii organizaiei, diminuarea costurilor i a pierderilor,
mbuntirea deciziilor administrative

9 Msuri privind pregtirea

obiectului pentru
implementarea
sistemului

lista msurilor organizaionale pentru perfecionarea

proceselor business
lista lucrrilor pentru implementarea sistemului, care sunt
necesare la etapa proiectrii tehnice, cu indicarea termenilor
i responsabililor

10 Borderoul documentelor
3.1.5. Documentaia
La finalizarea etapei proiectrii tehnice sunt documentate 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 meninerea 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 obiectului automatizrii, testrile pot fi
autonome sau complexe. Testrile autonome (de detaliu) includ unele prti 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

Compartimentul dat 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; studiul de caz Proiectarea sistemului informaional al unei ntreprinderi de
comercializare en-gross a medicamentelor).

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 tip 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 lucrri, module program etc.). Pentru realizarea componentelor
identificate la etapa decompoziiei sunt alese soluiile proiect tip, existente pe pia, care vor fi
adaptate la particularitile concrete ale organizaiei.
3.2.1. Soluia 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:
determinarea criteriilor de estimare a susceptibilitii 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 a pachetului;
caracteristici de exploatare a pachetului;
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 lucruatt cu cu modelul SI tip, ct i cu modelul orgnaizaiei concrete.
n depozitul (repozitoriu) cu metainformaii SI tip conine modelul obiectului automatizrii n baza
cruia are loc configurarea produsului program. n consecin, abordarea model-orientat
presupune, nainte de toate, construirea modelului obiectului automatizrii utiliznd instrumente
program speciale (de exemplu, SAP Business Engineering Workbench (BEW), BAAN Enterprise
Modeler).
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) a SI, modele tip pentru diferite clase de SI,
modelele SI ale unor organizaii concrete.

3.2.2. Etapele realizrii

Modelul de baz al SI din depozit include descrierea funciilor bisiness, proceselor business,
obiectlor business, regulilor business, structurii organizaionale, pentru care pot fi utilizate
modulele SI tip.
Modelele tip descriu configuraiile SI pentru ramuri sau tipuri de producie concrete.
Modelul unei ntreprinderi concrete este construit sau prin alegerea unor fragmente ale modelului
de baz sau modelului tip conform praticularitile 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 busines 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 de jos nivel
al modelului funciilor business. Pentru descrierea proceselor este utilizat modelul de control al
evenimentelor ( - 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 buciness.
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. Pentru a estima conformitatea PP cu aceste cerine poate fi utlizat metoda de estimare
a pachetelor program, descris mai sus. Dup alegerea PP n baza modelelor de referin are loc
construirea modelului preliminar a SI, n care sunt reflectate toate particularitile realizrii SI
pentru ntreprindere 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 (de exemplu, ABAP n SAP,
Tools n BAAN).
Realizarea unui proiect tip presupune executarea urmtoarelor operaii:
instalarea 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

Avantaje

utilizarea abordrii modulare

pentru proiectarea i

Dezavantaje

cheltuieli mari de timp pentru racordarea

elementelor eterogene ca rezultat al

Biblioteci de
programe
orientate pe
metode
SPT pe
subsisteme
Pachete de
programe
aplicative

documentare SI

SPT pe obiecte
Proiecte SI de
ramur

nivel nalt de integrare a

elementelor
permite realizarea proiectrii
modulare, adaptarea
parametric a componentelor
program pentru diferite
obiecte de gestiune
asigur diminuarea
cheltuielilor
documentare bun a
proceselor de prelucrare a
iinformaiei

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

incompatibilitii 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

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

3.2.3. 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

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 ingineering. Analiza organizaional conform acestei metode are loc conform
unei scheme bine determinate cu utilizarea modelului business complet al companiei. Compania este
considerat sistem social economic deschis, creat pentru atingerea anumitor obiective, element al
setului de super-sisteme 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 al companiei
ncepe cu descrierea modelului interaciunii 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 este:
1. Activitile desfurate de ctre societate n scopul ndeplinirii funciei pentru care a fost
nfiinat, oferind clienilor produse sau servicii;
2. Mecanismul prin care societatea i realizeaz scopurile i obiectivele.

Misiunea companiei pentru satisfacerea necesitilor solcial-relevante ale pieei este definit ca un
compromis ntre interesele pieei i 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). Determinarea misiunii permite crearea arborelului obiectivelor
companiei - liste ierarhice de precizare si detalizare a misiunii.
n baza arborelui scopurilor este format arborele strategiilor - liste ierarhice de precizare si
detalizare a procedeelor de atingere a scopurilor. La nivel corporativ sunt dezvoltate strategiile de
cretere, integrare i investiii. Blocul strategiilor business determin strategiile de producere i
strategice, 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 potrivite, 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 business potenialului companiei set de
activiti comerciale, direcionate spre satisfacerea necesitilor unor segmente concrete ale pieei.
n continuare, reieind din particularitile canalelor de distribuire 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, la rndul su, determin funciile companiei list de funcii business, funcii
de management i procurare, 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 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 realizarea 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,
etc.). Detalizarea de mai departe a matricei (pn la nivelul de responsabilitate a angajailor) va
permite obinerea responsabilitilor funcionale ale personalului, care, mpreun cu o descriere a
drepturilor, obligaiunilor, mputernicirilor va permite elaborarea pachetului de instruciuni fie de
post.
Descrierea potenialului business, funcionalitilor i matricelor de responsabilitate reprezint
descrierea static a companiei. n acest descriere procesle, 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.
Dezvoltarea (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 rapoartelor 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.).
Ca i structur, 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.
n acest caz se produce descrierea scopuri-procese a companiei, care permite s fie obinute
rspunsuri la ntrebrile: ce-de ce-unde-cum-cine-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-undecine-cum-cnd-cui-ct (fig. 4.3).

Fig. 4.3. Modelul business complet al companiei

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).

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 prin analiza structurii interne a companiei. Pentru descrierea modelului
interaciunii companiei cu mediul exterior (definiia misiunii companiei pe pia) 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 compensatorii 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 compromise
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 este direcionat businessul 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 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) de consumatori (segmentele pieei). Cu ajutorul matricei proieciilor (fig. 4.7) este
stabilit corespondena ntregrupurile de produse i segmentele pieei i sunt determinate afacerile
companiei (la intersecia liniilor i coloanelor celeulele matricei).

Fig. 4.7. ablonul formrii afacerilor (matricea proieciilor)

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 formarea 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 diferitor executori, 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 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 necesare. Reproducerea produselor are loc
datorit prelucrrii resurselor n ciclul de producie de baz. Componentele sale formeaz businessfunciile necesare furnizarea resurselor, producia i distribuia produselor n locul de vnzare.
Pentru gestiunea procesului de reproducere este format colecia de componente de management,
care genereaz un set de funcii de management. Pentru a menine procesele de reproducere i de
management sunt formate seturi de funcii de sprijin aferente (de securitate, echipare tehnic,
profilactic i reparaii, etc). Aceast abordare ne permite de a descrie organizaia, cu ajutorul unui
set universal de registre de management (obiective, strategii, produse, funcii, uniti
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 al 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).
n modelul iniial (de nceput) sunt utilizate doar cteve 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 funcie 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 organizaional-structural 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 rus, 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 informasionale 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
suplimentare 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, proiecile i modelel flux ale proceselor business potfi vizualizate n diferite moduri.
Pentru clasificatoare liste i arbori (grafuri orientate), pentru proiecii liste legate i matrice
transpuse, iar pentru modelele de flux ale proceselor business diagrame IDEF0 (IDEF3) i
descriere textual, ceea ce faciliteaz nelegerea problemelor de ctre participani. Construirea
modelelor de flux are loc sub forme obinuite tabelare.
n model este posibil formarea unui numr nelimitat de clasificatoare, proiecii i medele de flux,
s ca rezultat, rapoarte i documente pentru descrierea i crearea regulamentelor de activitate.
Prezena n BIG-Master a ctorva instrumente 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.

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

Elaborare 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 n cadrul realizrii 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 economiei 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 al abordrii funcionale sunt:
partiionarea tehnologiilor de executare a lucrului pe segmente separate, adesea
independente ntre ele, executate de diferite subdiviziuni;
lipsa unei descrieri integre a tehnologiilor;
dificultatea reunirii 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 utilizatorilor;
diminuarea nivelelor de luare a deciziilor;
combinarea principiului managementului pe obiecte cu organizarea lucrului b grup;
atenie sporit la asigurarea calitii;
automatizarea tehnologiilor de exectuare a proceselor business.
n conformitate cu 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 trebui s defineasc i s administreze multiple procese interdependente i care

interacioneaz. Frecvent ieirea unui proces formeaz intrarea altui proces. Identificarea i
managementul sistematic 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 procesele 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 trebuie s fie
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 este creat modelul
cum este. Proelucrarea 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 propriectarilor proceselor
business, n rezultat procesele nseteaz s fie orfani, sunt create condiii pentru dexvoltarea i
implementarea sistemelor de stimulare i responsabilitate pentru rezultatele finale, sunt
determinate momentele i procedurile de transferare a responsabilitii. Analiza i evaluarea
proceselor business permite s abordm justificarea standardelor de performan a proceselor,
riscurilor admisibile i un spaiu de libertate la luarea deciziilor, 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 procrsele business ale companiei au loc n cadrul structurii organizaionale a
ntreprinderii, care descrie competenele i relaiile funcionale.
Managementul activitilor curente are loc pe dou direcii managementul domeniilor funcionale,
care susin mulimea proceselor business unificate, divizate pe operaii, i managementul proceselor
business integrate, obiectivul cruia este rutarea i coordonarea proceselor unificate pentru
ndeplinirea comenzilor operative ale clienilor i a proiectelor proprii ale organzaiei (fig. 5.1).
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 prezentarea 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.

Fig. 5.1. Schema managementului activitii companiei

Ca i concluzie, orientarea pe 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 legate, obiectivele finale ale 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 (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 mersul i rezultatele procesului n
totalitate. El trebuie s cunoasc procesul business, s urmreasc ndeplinirea i s perfecioneze
eficacitate 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 lucrul coordonat al 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 nicele de ierarhie. 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.
Manager situaional specialist de calificare nalt, care poate ndeplini independent pn la 90%
din volumul de lucru.
O sarcin important a abordrii procesuale este formare echipelor procesuale. Pregtirea i
formarea echipei include:
cursuri de instruire;
formare practic (training) pentru asimilarea metodelor, metodicilor .a.;
testare compatibilitate psihologic;
testarea aptitudinilor practice.
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 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 de afaceri
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

Minimum dou probleme trebuie soluionate la descrierea procesual:

1. Identificarea ntregului sistem de domenii funcionale i a proceselor companiei, ca i
legturile reciproce ntre procese.
2. Selectare proceselor integrate cheie i descrierea lor la nivelul fluxurilor.
Fiecare activitate a companiei este realizat ca proces, care are consumatorul su: extern clientul
sau inetrn 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, necesar, de exemplu, 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 verigi 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 (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 efectivitate 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, comand 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 descries 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 ai 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 deciziei administrative. Deciziile administrative pot fi luate
referitor 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, c orice activitate managerial se
desfoar n conformitate 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);
executorii tehnici (colectarea informaiilor, evidena, comunicaiile).
Conform unor abordri recente, pentru procesul de managemeng sunt evideniate dou tipuri de
procese, asociate respectiv de 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 valor 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 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 fluxurile 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 este un set de funcii legate logic. Pentru fiecare funcie
este specifica 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 a 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, economico-financiar, de producere.
Informaii privind politica de eviden i raportare.
2. 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.

Tabelul 5.1. Registrul informaiilor de intrare

(Denumirea
ntreprinderii)

(Denumirea subdiviiunii)

Caracterul prelucrrii documentelor

Nr. Denumirea i
destinaia
documentului

Cine
prelucreaz

Complexitatea Periodicitatea,
regulamentul

De la cine a venit

Cum a fost
obinut

Tabelul 5.2. Registrul informaiilor de interne

(Denumirea ntreprinderii)

(Denumirea subdiviziunii)

Nr. Denumirea i destinaia Cine

documentului
prelucreaz

Cui va fi
transmis

Caracterul prelucrrii documentelor

Complexitatea Periodicitatea,
regulamentul

Cum a fost
obinut

Tabelul 5.3. Registrul informaiilor de ieire

(Denumirea ntreprinderii)

(Denumirea subdiviziunii) Caracterul prelucrrii documentelor

Nr. Denumirea i destinaia

documentului

Cine
prelucreaz

Destinatar Complexitatea Periodicitatea, Cum a fost

regulamentul obinut

Listele cu ntrebri pentru interviuri i sondaje sunt alctuite pentru fiecare dapartament 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.
Obirctivele departamentului.
Succesivitatea aciunilor pentru ndeplinirea lucrrilor.
Care sunt tipurile de organizaii externe (bnci, clieni, furnizori etc.) cu care interacioneaz
departamentul i care subt achimburile 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 adesea de la scopurile i normele declarate oficial sau contravin activitilor
efective.
Structura fluxurilor informaional poate fi stabilit folosind formularele documentelor i configuraia

reelelor de calculatoare i a bazelor de date. ns structura microproceselor reale, executate de

persoanl n contactele informaionale (n mare parte nedocumentate) rmne necunoscut.
Rspunsuri la aceste ntrebri poate oferi o diagnosticare structural-funcional, 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, procedure);
clasificarea direciilor (problemelor soluionate), obiectivelor funcionrii;
clasificarea elementelor fluxurilor informaionale;
cercetarea activitii personalului organizaiei;
studierea repartizrii (n timp i frecven) a caracteristicilor organizaionale: procedure,
contacte, direcii de activitate, elemente ale fluxurilor informaionale individual i n
combinaie pentru categorii de lucrtori, tipuri de procedure i direciile lor (conform
rezultatelor i logicii studiului);
identificare 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 zile 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 procesului 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 Denumirea procesului business
1.

Vnzri: n reea, engros

2.

Planul de achiziii

3.

Plasare comenzii de producere

4.

Producere proprie

5.

Achiziii de materii prime

6.

Pli

7.

Alte

Formular posbil pentru descrierea operaiilor procesului business:

Operaie Executor Frecvena Documente de intrare
Document de ieire (document creat)
(documente justificative)

Formular posbil pentru descrierea documentelor procesului business:

Document creat (document la Operaie Cine creeaz
ieire)
(executorul)

Frecvena 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).

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. Mtoda 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 modelareaa domeniului obiectiv. Pentru a realiza

un proiect al SI adecvat domeniului obiectiv (sub forma unor programe, care lucreaz corect)
este necesar s avem o imagine integr, sistemic a modelului, care s reflecte toate
aspectelefuncionrii noului sistem informaional. n acest caz, prin noiunea de model al
domeniului obiectiv vor 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 efecturii
lucrrilor de proiectare i s fie obinut un proiect mai efectiv i mai calitativ. Fr modelaria
domeniului obiectiv este mare probabilitatea unui numr mare de erori la soluionarea problemelor
strategice, care vor conduce la pierderi i cheltuieli suplimentare pentru lichidarea erorilor.
Reieind din aceste considerente, toate tehnologiile de proiectare moderne sunt bazate pe
tehnologia modelrii domeniului obiectiv.
Modelele domeniului obiectiv vor 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 n SI;
asigurarea posibilitii de a evalua efectivitatea realizrii modelului domeniului obiectivn
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 al funcionrii domeniului obiectiv.
Aspectul structural presupune construirea:
structurii obiectuale, care reflect componena obiectelor materiale i informaionale ale
domeniului obiectiv, care interacioneaz n cadrul proceselor;
structurii funcionale, care reflect 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 modelelor domeniului obiectiv sunt utilizate metode
grafice, care trebuie s garanteze prezntarea 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 asociat problema alegerii limbajului de prezentare a soluiilor de proiect,
care s permit atragerea a 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. Notaia este sintaxa
limbajului de modelare. 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 pentru
identificarea soluiilor de proiect suficient de formalizate i univoce, care vor fi realizate sub forma
unor seturi de programe sistem integru de resurse program.
Imaginile grefice reprezint forma cea mai
Imaginea grafic este adesea forma cea mai cuprinztoare de prezentare. n acest caz, proiectanii

ar trebui s fie contieni de faptul c metodele grafice de documentare nu pot descompune n

totalitate soluiile de proiect de la enunul problemei pn la programe de calculator. Dificulti
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 eficien a
proceselor automatizate, la care pot fi plasai:
timpul de soluionare a problemelor;
preurile de cost pentru procesare datelor;
fiabilitatea proceselor;
indicatori indireci de eficin, cum sunt volumul produciei, productivitatea muncii, rulajul
capitalului, rentabiltatea etc.
Pentru calcularea indicatorilor de eficien 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, modelel 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, untii 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 este specificat componena claselor de obiecte, sunt 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 un fel de convertor al intrrilor n ieiri. Secvena de funcii legate reciproc
pe intrri i ieiri se numete proces business. O funcia 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 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 fubnciilor 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 ptocesului 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 terminarea 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 apeleaz execuia
unei funcii noi, din aceast cauz pentru fiecare stare a obiectului trebuie s fie specificate aceste
apeluri. n aa mod, evenimentele au rolul de legtura 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 procesuluintr-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 reuniunea 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 managemnt.
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 tehnice 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.
Modelele descrise ale domeniului obieciv sunt direcionate spre proiectarea unor componente
separate ale SI: date, module program funcionale, module program de gestiune, interfee ale
utilizatorilor, structuri ale complexului tehnic. Pentru o proiectare mai calitativ a acestor
componente 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: obiecte-funcii, funcii-evenimente, uniti organizaionale-funcii, uniti
organizaionale-obiecte, uniti organizaionale-mijloace tehnice .a.m.d. ns aceste matrice
sunt greu de neles i nu reflect particularitile realizrii interaciunilor.
Pentru o reflectare corect a interaciunilor componentelor SI este important realizarea modelrii
concomitente a acestor componente, n special din punctul de vedere al obiectelor i funciilor.
Metodologia analizei structurale de sistem ajut semnificativ n rezolvarea acestor probleme.
Analiza structural este numit 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 succesive la rezultat.
Analiza structural se bazeaz pe dou principii fundamentale - "dezbina 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 n mod semnificativ sporesc nivelul de nelegere a sistemelor complexe. Mai
jos sunt prezentate definiiile unor noiuni-cheie din domeniul analizei structurale.
Operaie aciune elementare (indivizibil), excutat la un singur loc de lucru.
Funcie set de operaii, gruoate n funcie 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 orientate pe funcii i orientate pe obiecte

Procesul modelrii business 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 orientate pe obiect.
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 reaprtizarea ntre obiecte a
responsabilitilor pentru aciunile executate n cadrul organizaiei.
Metodele funcionale, dintre care cea mai cunoscut este metoda IDEF, consier 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.
Din punctul de vedere al modelrii afacerii 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 salb 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. Metodologia IDEF0
Poate fi considerat etapa urmtoare de dezvoltare a binecunoscutului limbaj 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 metodei este constrirea schemei funcionale a sistemului cercetat, care descrie toate
procesele relevante cu exactiatea suficient pentru modelarea univoc a activitii sistemului.
La baza metodologiei se afl patru noiuni funcdamentale: blocul funcional, arcul de interfa,
decompoziia i glosarul.
Blobul funcional (Activity Box) reprezint o funcie concret (oarecare) a sistemului cercetat.
Comform 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 Management (Gestiune, en. 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 tec.) 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.
Conforma 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 ua din diferene principale ale standardului IDEF0 de
alte metodologii 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 i 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 determinat de acest element. Acest set se numete glosar i descrie
entitatea elementului dat. Glosarul completeaz armonios 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 detalizare i cercetarea unor elemente separate, care nu sunt necesare reieind din
punctul de vedere ales. Alegerea corect a punctului de vedere diminueaz cheltuielile temporale
pentru construirea modelului final.
n procesul de decompoziie 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 bolcului 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
continuarea 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) sunb 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 include 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 doemnii 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 subdiviziunii?
o Care sunt funciile i n ce ordine ele sunt executate n cadrul subdiviziunii?
o Cine este reaponsabil de executare unei funcii anume?
o Care este rezultatul activitii subdiviziunii (ieirea)?
n baza documentelor existente i n rezultatul chestionrii este creat proiectul modelului
(Model Draft)

Difuzarea draftului modelului pentru informare, coordonare i comentare. La aceast etap are loc

discutarea proiectului modelului de ct mai multe persoane competente (n termeni IDEF0 cititori).
Fiecare diagram este criticat i comentat n scris, dup care este ntoars autorului. Autorul, de
asemenea n scris, accept sau nu critica, motivnd neacceptarea, i ntoarce cernovicul corectat pentru
discuii ulterioare. Acest ciclu continu pn la momentul n care autorii i cititorii vor ajunge la consens.

Aprobarea oficial a modelului este responsabilitatea conductorului grupului de lucru i are

loc la momentul atingerii consensului ntre autori i cititori. Modelul final reprezint o
imagine coordonat privind ntreprinderea (sistemul) din punctul de vedere i obiectivul
stabilit.

Simplitatea limbajului grafic IDEF0 fac lizibil modelul i pentru persoane fr o pragtire anterioar
special i care nu au participat n elaborarea modelului. Instrumentele IDEF0 sunt utlie i pentru
demonstraii i prezentri. n baza modelului elaborat pot fi organizate proiecte noi, focalizate pe
modificare 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 trei noiuni principale: fluxuri de date,
procese (lucrri) 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 direia de deplasare a informaiei.
Destinaia procesului (lucrrii) 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.
Numrul poate fi utilizat mpreun cu numrul diagramei pentru a obine indicile uncal al
procesului n cadrul ntregului model.
Depozitul de date (repozitoriul) permite determinarea 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 trabuie 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 cataloagele 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 lucrrilor, ndeplinite de procese: mulimea tuturor
minispecificaiilor este specificaia total a sistemului.
Procesul de construire a 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 va 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 utilizate de procesul principal. De exemplu, pentru procesul
principal evidena petiiilor cetenilor, entitatea extern 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 denumire entitii externe,
evenimentul, tipul lui (ordinar/tipic pentru sistem sai excepional, adic reaqlizat n condiii
speciale) i reaia sistemului.
La pasul urmtor are loc decompoziia procesului principal ntr-un set de procese care reciproc
legate, care fac schim de fluxuri 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 rspunde urmtoarelor 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 va 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 maisimpl 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 interciune 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 amintim:
posbilitatea determinrii univoce a entitilor externe, analiznd fluxurile de informaii din
sistem i din afara lui;
posbilitatea 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 veder al DFD nu se deosebesc prin nimic de cele obinuite; lipsa nuiunii 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, care este
construit conform urmtoarelor principii:
abstractizare;
incapsulare;
modularitate;
ierarhi;
tipizare;
paralelism;
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
1. Structura fiecrui modul trebuie s fie suficient de simpl pentru a putea fi complet
neleas.
2. 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.
3. Acele detalii ale sistemului, care se presupune c se vor modifica independent vor fi plasate
n module diferite.
4. Singurele legturi ntre module vor fi acelea a cror modificare este improbabil.

5. 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. 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 micprin utilizarea
unor mecanisme comune, care asigur economia necesar a mojloacelor 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, actiunile, lucrrile), legate pe diagrame 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 obiectorientate este mult mai nalt dect n cazul abordrii funcionale.
Chiar i principiul proectrii este modificat n abordarea obiect-orientat. Mai nti sunt stabilite
clasele obiectelor, iar n continuare n dependen de strile posbile 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
ggrafic 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 problem 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).

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 mijloacelor instrumentale 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 palitrei 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 prezentate sub form de dreptughiuri, datele sub form de sgei. Dac se
acioneaz butonul din stnga 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 procesle 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 sibiect 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 ca i componente ale sistemului, i care vor fi considerate drept aciuni externe. O
influien seminifcativ asupra determinrii subiectului sistemului va avea poziia din care este
abordat sistemul i obiectivele modelrii ntrebri la care trebuie s dea rspuns modelul
construit. Altfes 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 ca 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 detaliere 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

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 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 n
modelul IDEF0 n BPwin 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 al aceluiai dialog poate fi descris statutul modelului (varianta maculator, de
lucru, final, etc.), data crerii i a ultimii 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 i 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 va
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 funcionalitatea pare evident. 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 prpocesul 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 selectate 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 noaia 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 mai departe, pn la atingerea nivelului necesar de
concretizare a descrierii. Dup fiecare ciclu de decompoziie au loc sesiuni de expertizare experii
domeniului obiectiv identific 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 inic 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 nsepnd cu rdcina.
Diagramele pentru expoziie (FEO) sunt construite pentru a ilustra fragmente separate ale
modelului, puncte de vedere alternative sau n scopuri speciale.
Activitile (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 reprzint 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 dialogActivity Box Count

Alegem aici notaia IDEF0 i acionm OK. Apare diagrama de decompoziie (fig. 7.9). Intervalul
permis de activiti este de la 2 la 8. Nu are sens s descompunem o activitate ntr-o singur
activitate. Diagramele mai mult de 8 activiti sunt suprasaturate 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 palitrei instrumentelor, apoi ntr-un loc liber pe diagram.
Activitile ntr-o diagram de decompoziie sunt plasate pe diagonale stnga-sus dreapta-jos.

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 (v. mai jos).
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, care sunt utilizate sau transformate de activitate n
scopul obinerii unui rezultat (ieire). Activitateai poate s nu aib nici o sgeat de intrare. Fiecare
tip de sgeat este asociat unei laturi deteminate 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 determinare 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 iintrare, 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). Frecvent este dificil de stabilit dac datele sunt intrri sau controluri. n acest caz
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 a sget control. Sgeata control este desenat
intrnd n latuare 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 sctivitii 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 ieind din 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 activitate oarecare este ndeplinit n afara sistemului modelat. N BPwin sgeile apel
sunt utilizate n mecanismul de agragare 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 cele mai pe nelesul experilor expresii. Deoarece definiiile formale adesea
sunt complicate pentru acceptate, 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. Sgeile libere i legate

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

sgeile, care intr i care ies (cu excepia sgeii apel) apr 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 a 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 diaggramei, pornind de la 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 lucrri.
Legare de intrare (output-input), cnd sgeata de ieire a unei activiti superioare (n
continuare simplu, ieire) 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 raglarea direct a proceselor de asamblare i

testare a calculatoarelor (ieirea activitii " ").

Fig. 7.18. Conexiunea invers la control

Legtura ieire-mecaninsm (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 adunare. 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 adunare. Pentru a ramifica o sgeat n regim de editare a sgeii se face
clik pe fragmentul sgeii i pe segmentul respectiv al activitii. Pentru adunarea 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 adunare 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 adunare sunt analogice eroare va fi considerat
sgeata care dup adunare nu are nume, iar pn la adunare nu avea nume una din ramuri.
Pentru denumirea unei ramuri separate a sgeilor de ramificare i de adunare 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 bu trebuie de detalizat sgeata
mecanismului, adic sgeata mecanismului pe activitatea-fiic a fost denumit pn la ramificare,
iar dup ramificare remurile 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-n-activitatea-fiic (fig. 7.25).
7.2.7. Numerotarea activitilor i diagramelor

Toate activitile sunt numerotate. Numrul 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
numrul A0. ctivitile decompoziiei diagramei A0 au numrul A1, A2, A3 .a.m.d. Activitile
decompoziiei unui nivel inferior au numrul activitii printe i numrul de ordine ordinar, de
exemplu decompoziiile lui A3 vor ave numerele 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 n nodul 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 cadul arborelui
nodurilor. Pentru claritate i pentru a verifica corectitudinea decompoziiei este necesar ca dup
fiecare modificare s fie creat diaggrama arborelui nodurilor. BPwin are un mecanism puternic de
navigare prin model Model Explorer, care permite afiarea ierarhiei activitilor i a digramelor
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.
Tabelul 7.1. Cmpurile titlului chenarului (de la stnga la dreapta)
Cmp

Sens

Used At

Este utilizat pentru a indica activitatea printe, dac n diagrama curent se fcea referin
prin utilizarea sgeii apel

Autor, Date,
Rev, Project

Numele autorului diagramei, data crerii i numele proiectului, b cadrul cruia a fost
creat diagrama. REV data ultimei revizuiri a diagramei

Notes
123456789 10

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

Status

Statutul reflect etapa crerii diagramei, conform etapelor de publicare

Working

Diagram nou, diagram noit cardinal sau autor nou al diagramei

Draft

Diagrama a trecut expertizarea primar i este gata pentru discuii ulterioare

Recommended

Diagrama i toate documentele asociate au trecut expertiza. Modificri noi nu sunt

ateptate

Publication

Diagrama este gata pentru imprimarea final i publicare

Reader

Numele cititorului (expertului)

Date

Data citirii (expertizei)

Context

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

Number C-Number, numr unic al versiunii diagramei

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.

Reunirea i desprirea modelelor

Posibilitatea reunirii i despririi 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 reunirea i desprirea modelelor n BPwin sunt utilizate sgeile apel. Pentru reunire 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 reunirea 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 reunirea modelelor se vor reuni i dicionarele sgeilor i activitilor. n cazul n care definiiile
coiincid este posibil rescrierea lor sau acceptarea definiiilor din modelul-surs. 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 reunirea modelelor cu sincronizarea lor. Dac modelulsurs 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
veder, 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 n informaii privind reunirea 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