V. Beșliu, P.

Chirev

Îndrumar metodic la executarea lucrărilor de laborator

Disciplina ”Poiectare Sisteme Informaționale”
(Standarde, instrumente, indicatii metodice si soliții propuse)
Modificat: v.06.10.202020

Chisinau
2020
Cuprins:

Scopul îndrumarului metodic.......................................3

Mdelarea Funcțională. Modelarea Proceselor-Busines

în standardele de modelare
IDEF................................................................................4

Lucrarea de laborator № 1………………..…….……9

Lucrarea de laborator № 2 …………..……………....13
Lucrarea de laborator № 3 …………..……………....18
Lucrarea de laborator № 4 …………………………..31
Lucrarea de laborator № 5 …………………..…..….50
Lucrarea de laborator № 6 ………………………....61
Lucrarea de laborator № 7 …………………………67
Lucrarea de Laboratorul № 8……………………….82
Proiectul de Curs …………………………………..,92
Anexa 1……………………………………………….93
Anexa 2………………………………………………..96
Referințe selective………………………..…………...96
 Îndrumar metodic la executarea Lucrărilor de
laborator
Poiectare Sisteme Informaționale
1. Scopul îndrumarului metodic.
Formare la studenți abilități pentru proiectarea uniui
Sistem Informațional prin parcurgere de către student a
etapelor de: determinarea domeniului de interes,
evidențierea ramurii din domeniu, scoaterea în evidență a
obiectului ce va fi informatizat, analiza și descrierea
detaliată a obiectului ce va fi informatizat, identificarea
misiunii obiectului, crearea modelului funcțional As-Is,
elaborarea concepției noului sistem, descrierea și
modelarea proceselor busines, elaborarea cerințelor față
de sistem crearea modelului funcțional To-Be și
elaborarea Sarcinii Tenice pentru creare Sistemului
Informațional nou, planificarea lucrările de elaborare
proiect și calcularea costurilor de elaborare a proiectului
propus.
Se presupune că studentul, care a însușit cursul
”Proiectare Sisteme informaționale”, prin efectuarea
lucrărilor de laborator va parcurge etapele de proiectare a
unui sistem informațional în conformitate cu cerințele
standardului ISO 12207 (vezi Tema 6. Metode de
proiectare), va aplica unul din modele ale ciclului de
viață (vezi Tema 2. Ciclul de viață a Sistemului
Informațional) și va aplica standardele în modelarea
sistemelor informaționale (vezi Tema 4. Standarde
 pentru modelarea antreprizei și Tema 5. Bazele
Modelării Sistemelor Informaționale. Conotațiile
IDEF).
În procesul efectuării lucrărilor de laborator studentul va
parcurge următoarele Etape de proiectare a unui sistem
informațional:
Etapa 1. Studiul obiectului și a SI existent, definirea
cerințelor noului sistem, modelarea ToBe a SI
• Determinarea domeniului de interes;
• Studierea obiectului automatizării;
• Cercetarea SI și motivarea necesității creării unui
sistem nou;
• Studiul fezabilității Sistemului Informațional
• formarea cerințelor față de sistemul nou;
Etapa 2. Elaborarea Concepției SI
• Studii și executarea lucrărilor de cercetare necesare;
• Stabilirea scopului creării SI, determinarea actorilor
principali și funcțiile lor;
• Elaborarea modelului fucțional As-Is al obiectului
informatizat
• Elaborarea Concepției, discutate în grupul de lucru,
format din reprezentanții beneficiarului și
executorului;
• Elaborarea modelului fucțional To-Be al obiectului
informatizat
Etapa 3. Elaborare Sarcină Tehnică pentru crearea
unui Sistem Informațional
• La elaborarea Sarcinii Tehnice conform modelului
fucțional To-Be al obiectului informatizat vor fi
soluționate următoarele probleme:
• Elaborarea și fundamentarea cerințelor privind
modificare/creare subsisteme;
• Elaborarea și fundamentarea cerințelor privind baza
informațională, resursele matematice, resursele
program și tehnice (inclusiv, mijloacele de
comunicare și trasmitere date);
• Identificarea cerințelor generale ale sistemului
proiectat;
• Determinarea listei lucrărilor, resurselor necesare și a
executorilor pentru crearea sistemului;
• determinarea etapelor creării sistemului și termenilor
de execuție a acestora;
• Modelarea funcțională To-Be al obiectului
informatizării
• Modelarea proceselor busines al obiectului
informatizat conform modelului fucțional To-Be al
obiectului informatizat
• Modelarea fluxuri de date (DFD).
• Elaborarea Bazei de Date
• Calcularea costurilor pentru crearea sistemului și
determinarea nivelului de eficiență economică la
implementarea lui
• Elaborarea raportului despre lucrările îndeplinit
 Pentru îdeplinirea lucrărilor studentul trebuie să-și
aleagă Obiectul informatizării pentru care va fi elaborat și
implementat sistemul Informațional. Este recomandat ca
în acest scop să fie selectată tema tezei de Licență.
Efectuând lucrările de laborator propuse, în final studentul
va avea Sarcina Tehnică și lista lucrărilor/sarcinilor
necesare a fi executate pentru elaborarea sistemului
informational în cadrul Tezei de Licență.

Pentru efectuarea Lucrărilor de laborator sunt

propuse materiale theoretic, standardele și
instrumentele utilizate cu care trebuie să se
familiarizeze studentul. Standardele metodilogiei
IDEF, aplicația AllFusion Process Modeler 7.1 SP2,
BPwin și aplicația AllFusion Process Modeler 9.6.0
ERWin.

2. Familiarizarea cu metodologia IDEF

Metodele IDEF (Integration DEFinition), Conotațiile

IDEF0, DFD, IDEF1x, IDEF3, (TEMA 5. Bazele
Modelării Sistemelor Informaționale). Integration
DEFinition este o familie de limbaje de modelare în
domeniul sistemelor şi ingineriei software. Acestea
acoperă o gamă largă de utilizări, de la modelarea
funcţională modelare date, simulare, analiza/proiectarea
proces-orientată şi achiziţie de cunoştinţe. Metoda oferă o
abordare ştiinţifică pentru modelarea funcțională și a
proceselor. Metoda ghidează utilizatorul, printr-o
abordare disciplinată, de încredere acumulată din
experienţa experţilor. Metode evidenţiază, de asemenea,
obiecte de importantă, relaţiile şi constrângerile, şi
exclude informaţiile irelevante şi detaliile inutile. Metoda
este concepute pentru a îmbunătăţi performanţa (calitatea
şi productivitatea) atât de către persoane fizice cat şi
echipe implicate în activităţile de dezvoltare sisteme.
Metoda Integrarea Definition (IDEF), un produs-
cheie al efortului IICE (Information Integrator Content
Edition), oferă tehnici uşor de utilizat şi limbaje standard
de comunicare care promovează o bună disciplină de
inginerie. Metode IDEF îmbunătăţesc, de asemenea,
capacitatea de reacţie într-un mediu rapid si continuu
schimbător, ajutând utilizatorii să:
• înţeleagă corect mediul curent.
• propună schimbări.
• testeze soluţii alternative.
• prezică impactul schimbărilor.
• pună în aplicare cu succes schimbările.
Metodele IDEF sunt, de asemenea, proiectate să
funcţioneze împreună ca un set conceptual integrat de
metode care se pot conecta ca piesele unui puzzle pentru a
sprijini procesul de dezvoltare a întregului. Fiecare
standard IDEF abordează un aspect unic sau punct de
vedere al întreprinderii de inginerie. Atunci când
metodele individuale IDEF sunt aplicate împreună, ele
pot contribui la atingerea unuia dintre obiectivele cheie
ale ingineriei concurente luând în considerare mai mulţi
factori al ciclului de viaţă la începutul procesului de
proiectare. Realizarea acestui obiectiv facilitează creșterea
beneficiilor integrarii, flexibilitatii si reactivității
intreprinderii. La baza proiectării Sistemelor
Informaționale stă modelarea domeniului obiectiv. Pentru
a realiza un proiect al unui Sistem Informațional adecvat
domeniului obiectiv (sub forma unor aplicații) este
necesar să avem o imagine integră și o abordare sistemică
a domeniului obiectiv, elaborarea modelului care reflectă
toate aspectele funcționării viitorului Sistem
Informațional. În acest caz, prin noțiunea de model al
domeniului obiectiv vom considera sistemul, care imită
structura sau funcționarea domeniului obiectiv cercetat și
care respectă cerința de bază – corespunde acestui
domeniu.
Pentru modelarea domeniului obiectiv v-om aplica
metodele notațiilor din familia IDEF și DFD:
 IDEF0 - modelarea funcţională (sau a activităţii)
 IDEF1x - modelarea datelor
 IDEF3 - captarea descrierilor proceselor
 IDEF4 - proiectarea orientata obiect

Obiectivul este construirea schemei funcționale a

obiectului cercetat, schemă care descrie toate procesele
relevante cu exactitate suficientă pentru modelarea
univocă a Sistemului Informațional.
Elaborarea schemei funcționale a obiectului cercetat se
poate realiza cu ajutorul următoarelor metotde:
Metoda funcțională în notațiile IDEF.
Standardele IDEF care vor fi utilizate sunt:
 IDEF0 - modelarea funcţională (sau a activităţii)
 IDEF1x - modelarea datelor
 IDEF3 - modelarea proceselor
 Metoda fluxurilor de date în notația DFD
Instrumentele ce pot realiza aceste modele pot fi realizate
cu ajutorul instrumentelor CASE cum ap fi AllFusion
Process Modeler (în continuare BPwin, și Erwin),
instrumente ce susțin notațiile IDEF0, IDEF3, DFD și
IDEF1x.

3. Lucrarea de laborator № 1
Tema: Analiza domeniului de studiu. Elaborarea
Concepției Sistemului informațional
Timp rezervat: 4 ore
Scopul lucrării:
Scopul lucrării este de a analiza un sistem informaţional
real sau imaginar folosind elementele studiate la curs,
conform standardului ISO 12207 (Suport de curs PSI,
Tema 6.2, Etape de proiectare Sisteme Informaționale,
Etapa 1- Studiul SI existent și definirea cerințelor noului
sistem și Etapa 2- Elaborarea Concepției SI)
Prima dintre competenţele individuale pe care studenții
trebuie să o dobândească pentru a avea calificarea de
Analist – programator, se referă la capacitatea acestora de
a Caracteriza diferite tipuri de sisteme informatice, având
ca şi criterii de performanţă- identificarea rolului şi
obiectivelor sistemului informatic în cadrul sistemul
informaţional.
Sudenții vor lucra individual folosind, surse bibliografice
diverse, cunoștințe de pe net etc., de remarcat că
activitatea se poate organiza şi în grupuri.
Sarcini de lucru:
- descrierea domeniului;
- importanța temei;
- studiul sistemelor deja existente;
- compararea sistemelor;
- scopurile și obiectivele Sistemului informațional.
Folosind ca surse bibliografice, internetul, alte cărţi
sau publicaţii privind sistemele informaţionale şi situaţiile
concrete ale organizaţiilor, studenții trebuie să
îndeplinească cerinţele enumerate mai jos:
Studentul trebuie să organizeze toate aceste realizări
sub forma unui Proiect de curs care să îndeplinească
cerinţele din Ghidul pentru realizarea Proiectului de curs
din Anexa 1.
1. Realizaţi o diagramă în care să fie evidenţiate toate
serviciile din cadrul organizaţiei pentru care va fi
creat Sistemul Informațional grupate pe cele trei
sisteme (operaţional, decizional, informaţional).
2. Identificaţi fluxurile informaţionale care circulă între
sistemele organizaţiei studiate.
3. Identificaţi tipurile de suport pe care sunt stocate
informaţiile vehiculate şi modul lor de transfer de la
un sistem la altul.
4. În funcţie de modul în care sunt prelucrate fluxurile
informaţionale, stabiliţi tipul de sistem informaţional
din organizaţia analizată.
5. Realizaţi o listă de verificare pentru principalele
calităţi pe care ar trebui să le aibă un sistem
informaţional în care să existe o rubrică de observaţii
în care să justificaţi îndeplinirea/neîndeplinirea
respectivei calităţi.
6. Evidenţiaţi componente ale sistemului informaţional
al organizaţiei studiate, care ar putea fi automatizate.
7. Realizaţi o listă de inventariere a necesarului pentru
fiecare componentă a sistemului informatic pe care
urmează să-l realizaţi.
8. Întocmiţi un tabel cu funcţiile sistemului
informaţional care vi se par esenţiale pentru sistemul
informatic pe care va trebui să-l construiţi.
9. Stabiliţi obiectivele principale și/sau derivate care
stau la baza implimentării unui sistem informatic în
organizația dată.
10. Identificaţi o problemă a sistemului informaţional al
organizaţiei pentru care nu există o soluţie
algoritmică clară.
11. Descrieţi metodele și componentele cu care aţi putea
rezolva problema identificată anterior (punctul 10).
 12. Realizaţi o listă de verificarea a caracteristicilor
descris anterior şi justificaţi îndeplinirea sau
neîndeplinirea acestora.
Realizaţi o diagramă în care să fie evidenţiate metodele şi
tehnicile de rezolvare a problemelor după criteriile
enumerate în suportul de curs.
Rezultatele obținute la efectuarea aceste Lucrări de
laborator sunt reflectate îtru-un raport sumar pentru
Lucrările de laborator 1 și 2. Raportul trebuie să conțină:
- Studiul SI existent și definirea cerințelor noului sistem
1. definirea caracteristicilor generale ale (unității de
informatizare) obiectului social-economic;
2. studiul activităților de bază desfășurate in sistemul
obiectului social-economic;
3. studiul sistemului de conducere a obiectului;
4. studiul sistemului informațional existent;
5. identificarea metodelor și mijloacelor tehnice ce vor fi
aplicate la proiectare.
6. Determinarea cerințelor față de sistemul informațional
ce va fi proiectat
- Concepţia SI trebuie să conţine capitolele
1. Introducere;
2. Generalităţi;
3. Spaţiul juridico-normativ al funcţionării sistemului;
4. Spaţiul funcţional al sistemului;
5. Structura organizaţională a sistemului;
6. Documentele sistemului;
7. Spaţiul informaţional al sistemului;
 8. Spaţiul tehnologic al sistemului;
9. Asigurarea securităţii informaţionale;
10. Încheiere.
4. Lucrarea de laborator №. 2
Tema: Elaborarea Specificațiilor Tehnice (Caietul de
Sarcini) necesare pentru realizarea unui sistem informatic
conform standardului ISO 12207 (vezi Tema 6.2. Etape
de proiectare, etapa 3 ”Sarcina tehnică” manualul
”Proiectare Sisteme Informaționale”)
Timp rezervat: 4 ore
Scopul lucrării: Elaborarea Caietului de Sarcini
La efectuarea acestei lucrări de laborator v-or fi utilizate
rezultatetele obținute la realizarea lucrării de laborator
№1. Caietul de Sarcini fa fi elabotat în conformitate cu
cerințele standardului ISO 12207 (Tema 6.2. Etape de
proiectare, etapa 3 ”Sarcina tehnică” manualul
”Proiectare Sisteme Informaționale”). Caietul de sarcini
trebuie să conțină următoarele compartimente:
1. Generalități
2. Destinația și scopurile creării sau modernizării
Sistemului Informațional
3. Descrierea obiectului automatizării.
4. Cerințe funcționale față de sistem.
5. Componența și conținutul lucrărilor pentru crearea
sistemului.
6. Modul de testare / verificare și predare / primire a
sistemului.
 7. . Cerințe referitoare la componența și conținutul
lucrărilor de pregătire a obiectului automatizării
pentru lansarea în exploatare a Sistemilui
Informațional proiectat.
8. Cerințe privind documentația. Sistemilui
Informațional proiectat.
9. Lista documentelor legale și normatve ce
reglementează activitatea obiectului social-economic
pentru care se proiectează sistemul dat.
Conținutul compartimenelor:
1. Generalități
- denumirea completă a sistemului și abrevierea,
- codul (numărul) temei sau al contractului,
- denumirea organizației executoare și a beneficiarului,
rechizitele lor,
- lista documentelor în baza cărora este creat sistemul,
- data de începere și finalizare a lucrărilor,
- informații despre surse și modalitatea de finanțare,
- ordinea de perfectare și prezentare a rezultatelor creării
SI, părților sistemului sau a unor module separate.

2. Descrierea obiectului automatizării

- Descrierea generală a obiectului automatizării,
- Determinarea misiunii și Domeniului Obiectiv de
activitate a Companiei,
- Elaborarea ”Diagramei Structurale” a Companiei
(utiliți o aplicație de modelae vizuală a structurii
obiectului social/economic),
- Determinarea obiectelor pentru care va fi utilizat
sistemul (limitele sistemului),
- informații despre condițiile de exploatare și
caracteristicile sitemului.

3. Destinația și scopul creării (modernizării)

sistemului Informatic
- Categoria activităților de automatizare
- Lista obiectelor pentru care va fi utilizat sistemul
- Denumirea și valorile solicitate ale indicatorilor
tehnici, tehnologici, economici etc., care vor fi atinși
odată cu implementarea sistemului.

4. Cerințe referitoare la sistem

Cerințe privind sistemul în totalitate:
- Cerințe referitoare la structura și modul de funcționare
a sistemului (lista subsistemelor, nivelele ierarhice,
gradul de centralizare, modul de schimb
informațional, regimurile de funcționare, interacțiunea
cu alte sisteme, perspectivele de dezvoltare)
- Cerințe privind personalul (roluri, calificarea, regimul
de lucru, organizarea instruirii, utilizatorii)
- Indicatori asociați destinației sistemului
(adaptabilitatea la modificările sistemului de
conducere și a valorilor parametrilor, scalabilitatea)
- Cerințe privind fiabilitatea, securitatea, ergonomia,
transportabilitatea, exploatarea, deservirea tehnică și
 reparația, protecția contra unor influențe externe,
drepturi de autor, standardizare și unificare

Cerințe funcționale pentru subsistemele componente:

- Lista activităților automatizate
- Cadrul temporal de realizare a fiecărei funcții
- Cerințe privind calitatea realizării fiecărei funcții,
forma de prezentare a ieșirilor, exactitatea și
autencitatea datelor
- Lista și criteriile de stabilire a căderilor (refuz
serviciu)
Cerințe față de resursele necesare:
- Matematice - componența și sfera utilizării modelelor
și metodelor matematice, algoritmilor existenți și noi,
- Informaționale - componența, structura și organizarea
datelor, schimbul intern de date, compatibilitatea
informațională cu alte sisteme, clasificatoarele
utilizate, SGBD, controlul datelor și folosirea
masivelor de date, procedurile de conferire a
valabilității juridice documentelor la ieșire,
- Lingvistice - limbajele de programare, limbile de
interacțiune a utilizatorilor cu sistemul, sistemele de
codare, limbajele pentru intrări/ieșiri,
- Program - independența de platformă, calitatea și
metodele de control, utilizarea fondurilor de algoritmi
și programe,
- Tehnice,
- Metrologice,
- Organizaționale - structura și funcțiile
departamentelor de exploatare, protecția contra unor
acțiuni eronate,
- Metodice - documentația normativ-tehnică.
5. Componența și conținutul lucrărilor de creare a
sistemului
 Lista stadiilor și a etapelor
 Termenii de execuție
 Lista orgaizațiilor executoare
 Modalitatea și ordinea expertizării documentației
tehnice
 Programul de asigurare a fiabilității
 Programul de asigurare metrologică
6. Modul de testare, verificare și predare/primire a
sistemului
 Tipurile, componența, volumul și metodele de testare
 Cerințe generale privind acceptarea lucrărilor pe etape
 Statutul comisiei de primire
7. Cerințe referitoare la componența și conținutul
lucrărilor de pregătire a obiectului automatizării
pentru lansarea în exploatare a SI
 Transformarea informațiilor de intrare în formă
mașinolizibilă
 Modificările introduse în obiectul automatizării
 Termenii și modalitatea de selectare și instruire a
personalului
8. Cerințe privind documentația
  Lista documentelor elaborate
 Lista documentelor pe suporți magnetici.
9. Acte normatve și legale
 Lista actelor normative ce reglementează activitatea
socio-economică a obiectului de informatizare.
Rezultatele obținute la efectuarea aceste Lucrări de
laborator sunt reflectate îtru-un raport comun pentru
Lucrările de laborator 1 și 2.

5. Lucrare de laborator № 3
Modelarea antreprizei. Concepția IDEF (Tema 5,
manualul ”Proiectare Sisteme Informaționale”).
Modelarea funcțională a antreprizei (IDEF0).
Familiarizarea cu standardul IDEF0 și mediul de
modelare AllFusion Process Modeler (BPwin)
Timp rezervat: 4 ore.
În recomandările noastre o să utilizăm ca instrumente
CASE aplicația AllFusion Process Modeler (BPwin) care
suportă standadele IDEF0, IDEF3, DFD, ABC și aplicația
ERwin care suportă standardul IDEF1x.
Procesul de modelare:
În procesul de modelare în mediul BPwin este posibil de
a trece de la notația IDEF0 la notația IDEF3 sau la notația
DFD la orișice ramură a modelului și permite creare
modele mixte. Lucrările în mediul AllFusion Process
Modeler (BPwin) se încep cu procedura de creare a unui
model nou, unde trebuie de indicat numele (Name) și
tipul modelului, model functional sau modelul proceselor
sau modelul fluxului de date (Type) (figura 1).

Figura 1. Creare a unui model nou.

În funcție de tipul modelului ales va fi efectuată
modelarea prin decompoziția funcțională sau a proceselor
obiectului. Dacă va fia ales tipul Business Process
(IDEF0), atunci în modelul creat va fi efectuată
decompoziția funcțională în notația IDEF0, acest model
functional vas ta la baza creării modelului proceselor în
notația IDEF3. Modelul proceselor va servi ca bază la
modelarea fluxurilor de date în conotația DFD. Alegerea
tipului de model se efectuează în funcție de etapele
modelării.
După ce dăm nume modelului și alegem tipul modelului
butonăm ”OK” și BPWin imediat ne va propunem să
atribuim parametrii modelului (figura 2)

Figura 2. Atribuim parametrii modelului

 General— autorul modelului;

 Numbering — formatul de numerotare a lucrărilor și a
diagramelor și ordinea de reflectare în diagrame;
 Display — lista elementelor ce vor fi reflectate în
diagrame;
 Layout — parametrii de amplasare;
 ABC Units — unitățile pentru efectuarea ”Analiz
Business Costs”;
 Page Setup — parametrii paginii;
 Header/Footer — parametrii colontitului de sus sau
de jos.
După ce atribuim parametrii modelului, butonăm”OK” și
se va afișa pagina master (Fig. 3a) compusă din cinci părți
(exemplu pagina Master Fig.3b):
U SED AT: AU TH OR: Sudent TI/SI D ATE: 02.02.2017 W OR KING R EADER D ATE C ON TEXT:
PR OJ ECT: INSTRU IR E R EV: 02.02.2017 D RAFT
R ECOMMEND ED
TOP
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLICATION

1,00 A0

N OD E: TITLE: N UMBER:

A-0

Figura 3a. Pagina ”Master”.

 Figura 3b. Exemplu Ppagina ”Master”.
1 - (Model Explorer) - reflectă structura modelului
(diagrame existente și ierarhia lor);
2- partea principală (Drawing Area)- aici sunt reflectate
blocurile, cu care se lucrează;
3,4, 5 – bare de cu instrumente  - Menu Bar, BPWin
Toolbar, Standard Toolbar,
Bara de instrumente  Model Toolbox.
În Bara de instrumente găsim instrumente pentru crearea
diferitor elemente grafice ale modelului. Setul de
instrumente se schimbă în funcție de tipul selectat al
diagramei.
Tabelul 1. Tipul și funcția butoanelor în bara de
instrumente.

Iconiță Denumire buton Funcția butonului

buton
Pointer Tool Transformă cursorul în
săgeată pentru a putea
însera obiectele de pe
diagramă

IEDF0
Activity Box Tool Înserarea pe diagramă a
unei noi lucrări

DFD

IDEF3
Precedence Arrow Înserarea pe diagramă a
Tool unor noi arcuri (săgeți)
Legarea arcului de
Squiggle Tool
denumirea lui
Înserarea unui text pe
Text Tool
diagramă
Activarea ferestrei de
management a
Diagram diagramelor pentru
Dictionary Editor vizualizare diagramelor
existente și trecere la
diagrama selectată
 Trecerea între diagrama
Go to Sibling
standatd, arborele nodal și
Diagram
diagrama FEO
Go to Parent Trecere către diagrama
Diagram parentală
Go to Child Trecere către diagrama
Diagram fiică
External Înserare pe diagramă a
-DFD
Reference Tool unui entități externe
Înserare pe diagramă a
-DFD Data store Tool
unui depozitoriu de date
Înserare pe diagramă a
- Junction Tool unui interjecții
IDEF3
Înserare pe diagramă a
- Referent Tool unui referințe
IDEF3

Diagrama creată conține diagrama de context cu un singur

bloc funcțional (cutia neagră) în notația care a fost
selectată la etapa creării modelului (în cazul dat IDEF0).
În continuare trebuie de dat denumirea a acestui bloc
funcțional (denumirea proiectului) și după necesități de
indicat proprietățile funcționale. Pentru aceasta activăm
fereastra de dialog Activity Properties (Fig.4) - dubluclic
cu butonl stâng al mausului pe blocul funțional (pe cutia
neagră).
 Fihgura 4. Fereastra de dialog Activity Properties.

În continuare trebuie de creat arcurile (săgețile) de

interconexiune. Pentru aceasta activăm din Model
Toolbox iconița (Precedence Arrow Tool), cursorul se
transformă întro cruculiță, apăsați pe locul de unde trebuie
să pornească conexsiunea și apoi pe locul unde trebui să
ajungă conexiunea (BPWin va colora cu negru aceste
locuri în momentul ce cursorul va fi pe aceste suprafețe).
Pentu a da denumirea unei conexiuni (arc) selectați din
Model Toolbox iconița (Pointer Tool) și apoi faceți
dubluclic pe arcul dorit, va apărea o ferestruică de dialog
”Arrow Properties”. În câmpul ”Arrow Name” înscrieți
denumirea conexiunii.

Figura 5. diagrama de context (exemplu).

În continuare după ce am reflectat toate conexiunile de

intrare și de ieșire și le am atribuit respectiv denumiri
facem următorul pas:

decompoziția sistemului informațional pe subsisteme

(decompoziția diagramei de context) în blocuri
funcționale. Pentru aceasta în Model Toolbox activăm
iconița  Go to Child Diagram  și apoi butonăm pe
lucrarea care vrem să-i facem decompoziție. Se va afișa o
ferestră Activity Box Count (figura. 6) în care trebuie să
alegem notația modelului și cantitatea de blocuri
funcționale sau procese în care va fi descompus blocul
selectat (cantitatea de diagrame fiică)

Figura 6. Crearea diagramelor ”fiică”

După ce creăm diagramele ”fiică” BPWin automat crează

numărul de blocuri (lucrări) indicate mai sus și va
amplasa pe marginea stângă a paginii ”Master” (figura
7). În continuare trebuie de efectuat legăturile între
săgețile de intrae/ieșire cu lucrări (blocuri funcționale). În
caz de necesitate mai pot fi adăuga și alte intrăr/ieșiri
(săgeți). In continuare cu aceleași instrumente facem
interconexiunile între blocurile funcționale, atribuim
denumire acestor conexiuni.
Decompozițile în adâncime (de nivelul doi, trei sau ma
jos) se efectuează în acelaș mod.
 Figura 7. Decompoziția ”Diagramei de Context”
(exemplu).

În unele cazuri, v-om avea nevoie ca o săgeată să o

conectăm la mai multe blocuri funcționale. După ce am
conectat o săgeată la un Bloc Functional, selectăm
Arrow Tool din bara meniului și butonăm pe lucrarea
respectivă (figura. 8)
 Figura 8. Conexiunea unei săgeți la mai multe lucrări.

Pentru a conecta această săgeată al treilea bloc funțional,

butonăm pe segmental dorit.

Figura 9. Conexiunea unei săgeți la mai multe lucrări.

În exemplul nostru noi v-om efectua conexiunile și la alte

blocuri funcționale.
Figura 10a. Conexiunea unei săgeți la mai multe lucrări.

Figura 10b. Conexiunea unei săgeți la mai multe lucrări.

 Figura 12. Decompoziția ”Diagramei de Context”,
exemplu.

6. Lucrare de laborator № 4
Modelarea funcțională
Sarcina № 1. Determinarea contextului de funcționare.
Elaborarea diagramei de context în notația IDEF0
Sarcina № 2. Decompoziția funcțională de nivelul unu în
notația IDEF0. Elaborarea diagramei.
Sarcina № 3. Decompoziția funcțională de nivelul doi în
notația IDEF0. Elaborarea diagramelor
Timp rezervat: 6 ore.
Scopul lucrării:
• De a alege domeniul obiectiv (obiectul de
informatizare);
 Descrierera obiectului de informatizare (aria de
activitate, cu ce se ocupă obiectul, descrierea
proceselor principale ce au loc în activitatea obiectului
de informatizare);
 Determinarea contextului de funcționare. Elaborarea
diagramei de context în notația IDEF0;
 Decompoziția funcțională a obiectului de
informatizare de nivelul unu în notația IDEF0,
elaborarea diagramei;
 Decompoziția fumcțională de nivelul doi (și trei după
necesitate) în notația IDEF0, elaborarea diagramelor.

REMARCĂ
1. Pentru reflectarea proceselor de executare a
Lucrărilor de laborator 4, 5, 6 și 8 este luat ca
exemplu activitatea unei companii de asamblare a
echipamentelor electronice ( ca ex. -PC, Laptop)
2. Varianta pentru sarcina individuală a studentului se
coordonează cu profesorul.
3. Toate diagramele în notațiile IDEF0, IDEF3 și DFD
vor fi elaborate în mediul AllFusion Process
Modeler. Este obligatoriu de completat toate spațiile
din diagrame.

În acestă lucrăre de laborator va fi modelată

activitățile din sarcina individuală a studentului.
Orice activitate sau set de activități în care sunt
 utilizate resurse pentru transformarea intrărilor în
ieșiri poate fi considerată proces. Pentru o activitate
rezultativă organizațiile trebuie să definească și să
administreze multiple procese interdependente și care
interacționează între ele și cu mediul exterior.
Frecvent ieșirea (rezultatul) unui proces se utilizează
ca intrare pentru alte procese.
Ca rezultat al modelării Busines -Proceselor companiei
obținem ”Modelul Proceselor-Busines” care poate fi de
trei tipuri:
 modelul AS-IS (cum este) – modelul existent al
Busines -Proceselor companiei
 modelul TO-BE (cum va fi) – modelul unei organizări
ideale a Busines -Proceselor companie.
 mpdelul SHOULD-BE (cum trebuie să fie) – model
ideal, dar nu reflectă organizarea reală a Busines
-Proceselor companiei.
În lucrările de laborator vor fi create modelul AS-IS sau
modelul TO-BE, în funcție de starea obiectului ce va fi
informatizat. 

6.1. Sarcina № 1.
Determinarea contextului de funcționare. Elaborarea
diagramei de context în notația IDEF0
Înainte de a începe construirea diagramelor de modelare a
companiei este recomandat de a studia detaliat domeniul
obiectului pentru care va fi elaborat proiectul Sistemului
Informațional.
În exemplul nostrum v-a fi modelată compania de
asamblare a calculatoarelor (PC-uri și Notebook-uri),
compania nu produce ansamble și subansamble, doar
efectuează asamblarea, testarea produselr asamblate și
vânzrea lor angro.
Identificarea activităților principale ale companiei:
1. Colaboratorii cerceteaza cerințele pieții în calculatoare
și laptopuri;
2. Vânzătorii recepționează comenzi de la clienți;
3. Colaboratorii selectează comenzile conform tipurilor
de calculatoare;
4. Speciali;tii serviciului Marcketing cercetează piața
furnizorilor de ansamble și subamsamble;
5. Agenții secției de achiziții comandă și procură
ansamble și subansamble necesare pentru asamblarea
calculatoarelor;
6. Economiștii planifică producerea produselor pe
termen scurt și pe termen lung;
7. Contabilitatea efectuează elaborare sinecostului și
costul de livrare a produselor finite;
8. colaboratorii asamblează și testează calculatoarele;
9. Specialiștii serviciului tehnic asigură deservirea pe
garanții;
10. Magazinierii efectuează evidența produselor finite la
depozit, evidența vânzîrilor, evidența stocurilor de
subansamble;
11. vânzătorii împachetează produsele finite conform
comenzilor primite de la clienți;
12. colaboratorii livrează clientului comanda respectivă;
13. colaboratorii efectuează evidența contabilă, evidența
muncii, perfectează comanda, eliberează conturi de
plată, urmărește achitările conform facturilor.

Construcția unui model funcțional în notația IDEF0 se

începe cu definirea contextului modelării care include
subiectul modelării, scopul modelării și puntul de vedere
asupra modelului.
Ca subiect al modelării se înțelege Sistemul în sine, în
acest caz trebuie să pecizâm ce intră în noțiunea Sistem,
ce este în afara Sistemului - deci care sunt limitele
Sistemului și care elemente vor fi considerate ca elemente
din mediul exterior al Sistemului.
Scopul modelării.- Nu poate fi construit un model fără a
avea un scop bine formulat (determinat). Scopul trebuie
să răspundă cel puțin la următoarele întrebări:
 De ce trebuie să fie modelat acest proces?
 Ce trebuie să fie arătat în model?
 Ce v-a primi cititorul modelului?

Punctul de vedere. Punctul de vedere este percepția

omului care vede Sistemul din aspectul dorit de modelare.
Este știut faptul că la studiul subiectul modelării și la
crearea modelului sunt antrenați mai mulți specialiști din
diferiter domenii (analiști pe ramură, informaticeni,
tenicieni, economiști) care pot avea diferite viziuni asupra
funcționării și asupra proceselor, modelul trebuie să fie
construit dintr-un punc de vedere comun acceptat de toți
participanții la proiect. Punctul de vedere trebuie să
corespundă scopului modelării și în procesul modelării nu
trebuie să ne abatem de la punctul de vedere ales.
În lucrearea noastră subiectul modelării - este
”Compania” și anume activitățile și procesele ce se
petrec în interiorul Companiei.
Scopul modelării - construirea modelului
funcțional și proceselor ce se vor petrece în Companie la
realizarea obiectivelor Companiei ( modelul To-Be).
Punctul de vedere -este viziunea directorului Companiei
ca persoană care cunoaște în general toată structura
funcțională a Companiei.
Dacă am definit contextul modelării putem
începe construirea diagramei de context (”cutia neagră”).
Unde se indică ce avem la intrare și ce avem la ieșire fără
a detaliza componentela sale (blocurile funcționalde).
Această diagramă (figura 13) este constituită numai dintr-
n singur bloc care va reflecta întreaga Companie. 
 U SED AT: AU TH OR : R adu Bas arabeanul D ATE: 03.02.2016 W OR KIN G R EADER D ATE C ON TEXT:
PR OJEC T: Modelare Busines Proces e R EV: 04.02.2016 D RAFT
R ECOMMEND ED
TOP
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLICATION

reglamentãri (control)

întrãri
iesiri
Ansamblare Calculatoare

0lei 0

mecanisme

N OD E: TITLE:
Ansamblare Calculatoare N UMBER :

A-0

Figura 13. Diagrama de conrext a Companiei

Întrări (I) –aici se vor reflecta informația sau materialele

ce vor fi procesate de această lucrare (bloc).
Ieșire (O) – informația sau materialele care sunt produse
de această activitate (bloc).
Reglamentări (Control) – proceduri, reguli, strategii,
standarde și norme de care reglamentată această activitate
(bloc).
Mecanisme (M) – resursele ce asigură executarea
lucrărilor (angajații, echipamete, baze de date și altele.
Pentru Compania din exemplu vor fi (vezi figura 14):

Conexiunile (Acurile) de intrare:

 Comenzile clienților – lista calculatoarelor și a
notebook și completația lor cerute de clienți;
 Ansamble și subansamble de la furnizori;
 Informații (propuneri comerciale) de la furnizori,
 Informații despre cererea pieții

Conexiunile (Arcurile) de ieșire:

 Produsele finite – calculatoarele și notebookuri
asamblate,
 Cereri pentri furnizori – lista ansamblelor,
subansmblelr și materialelor necesare Companiei,
 Achităriile facturilor furnizorilor – achitări pentru
ansamble subansmble și materiale necesare
Companiei,
 Materiale de marketing a produselor proprii - price-
list, publicitate.

Conexiunile (Arcurile) de control (reglemantare):

 Cadrul legal – diverse acte legislative ce
reglamentează activitatea Companiei,
 Reguli și proceduri - Reguli și proceduri care
reglamentează procesele de producere (reguli de
asamblare, reguli de testare, norme de asamblare
produse, standade interne a produselor asamblate,
 procedura relațiilor cu clienții, norme de protecția
muncii)
Conexiunile (Arcurile) mecanismelor:
 Resursele umane, (ingineri în IT, programatori,
marketologi, economiști)
 Sistema de evidență contabilă,
 Sistema de evidență a contratelor,
 Echipamente tehnice,
 Unități de transport.
U SED AT: AUTH OR : Radu B as arabeanul DATE: 03.02.2016 W OR KIN G R EAD ER DATE C ONTEXT:
PROJEC T: Modelare Busines Procese REV: 04.02.2016 D RAFT
R EC OMMENDED
TOP
N OTES: 1 2 3 4 5 6 7 8 9 10 PUBLICATION

carul legal
norme de asamblare
reguli de asamblare reguli de testare

procedura relatiilor cu clientii standade interne

Comenzile clientilor Cereri pentri furnizori

propuneri comerciale de la furnizori produse finite

Ansamble si subansamble Ansamblare Calculatoare Achitãriile facturilor furnizorilor

Informatii despre cererea pietii

0lei 0
Materiale de marketing
Resursele umane

Echipamente tehnice
evidentã contabilã

unitãti de transport
evidentã a contratelor

N ODE: TITLE: N UMBER:

Ansamblare Calculatoare
A-0

Figura 14. Diagrama de context rezultativă a

Companiei.

Conținutul raportului:
  Denumirea subiectului ales;
 Descrierera domeniului obiectiv (aria de activitate,
cu ce se ocupă obiectul, care sunt procesele
principale ce se petrec în activitatea obiectului);
 Descrierera contextului;
 Diagrama de context.
6.2. Sarcina № 2.
Decompoziția funcțională de nivelul unu în notația
IDEF0.
Scopul lucrării:
De a identifica activitățile ce se petrec în funcționarea
obiectului ce va fi informatizată și de a efectua
decompoziția funcțională de nivelul unu în notația
IDEF0.
În sarcina precedentă a fost determinat contextul
funcționării (activității) obiectului și fost construită
diagrama de conext, constitută numai dintr-un bloc
general care reflectă activitatea Companiei în general (la
macro) fără detalizarea componentelor funcționale ale
Companiei. În această lucrare v-om evidenția care sunt
funcționalitățile și subdiviziunile principale ale
Companiei ce asigură funcționalitatea ei și v-om construi
diagrame de decompoziție de nivelul unu în notația
IDEF0. 
Decompoziția înseamnă partajarea unei activități
complexe în părți componente care interacționează între
ele în scopul îndeplinirii Misiunii obiectului de
informatizare. 
În sarcina precedentă au fost identificate procedurile
principale care asigură procesul de producere
calculatoare și lăptopuri.
Activitățile busines principale ale companiei:
1. Colaboratorii cerceteaza cerințele pieții în
calculatoare și laptopuri;
2. Vânzătorii recepționează comenzi de la clienți;
3. Colaboratorii selectează comenzile conform
tipurilor de calculatoare;
4. Speciali;tii serviciului Marcketing cercetează piața
furnizorilor de ansamble și subamsamble;
5. Agenții secției de achiziții comandă și procură
ansamble și subansamble necesare pentru
asamblarea calculatoarelor;
6. Economiștii planifică producerea produselor pe
termen scurt și pe termen lung;
7. Contabilitatea efectuează elaborare sinecostului și
costul de livrare a produselor finite;
8. colaboratorii asamblează și testează calculatoarele;
9. Specialiștii serviciului tehnic asigură deservirea pe
garanții;
10. Magazinierii efectuează evidența produselor finite
la depozit, evidența vânzîrilor, evidența stocurilor
de subansamble;
11. vânzătorii împachetează produsele finite conform
comenzilor primite de la clienți;
12. colaboratorii livrează clientului comanda
respectivă;
 13. colaboratorii efectuează evidența contabilă,
evidența muncii, perfectează comanda, eliberează
conturi de plată, urmărește achitările conform
facturilor.
14. colaboratorii perfectează comanda, eliberează
conturi de plată, urmărește achitările conform
conturilor.

Aceste activități le vom grupa pentru a evidenția

subdiviziunile principale ala Companiei ce asigură
funcționarea ei. 

Managementul finanțe și contabilitate

1. colaboratorii efectuează evidența contabilă și evidența
muncii,
2. colaboratorii perfectează comanda, eliberează conturi
de plată, urmărește achitările conform conturilor.
3. colaboratorii efectuează evidența produselor finite la
depozit, evidența vânzîrilor, evidența stocurilor de
subansamble;
4. colaboratorii efectuează elaborare sinecostului și
costul de livrare a produselor finite;
5. colaboratorii planifică producerea produselor pe
termen scurt și pe termen lung;

Marketing și vânzări
 1. colaboratorii cerceteaza cerințele pieții în
calculatoare și laptopuri;
2. colaboratorii cercetează piața furnizorilor de
ansamble și subamsamble;
3. vânzătorii recepționează comenzi de la clienți;

Organizare Producere (Ansamblare și testare)

1. colaboratorii selectează comenzile conform
tipurilor de calculatoare;
2. colaboratorii asamblează și testează calculatoarele;
3. colaboratorii asigură deservirea pe garanții;

Achiziții și Livrări
1. colaboratorii împachetează produsele finite conform
comenzilor primite de la clienți;
2. colaboratorii livrează clientului comanda respectivă;
3. colaboratorii secției de achiziții comandă și procură
ansamble și subansamble necesare pentru asamblarea
calculatoarelor;
În așa mod am evidențiat 4 subdivizi principale ala
Companiei ce asigură funcționalitatea ei și în așa mod v-
om face prima decompoziție: 

 Managementul finanțe și contabilitate

 Marketing și vânzări,
 Organizare Producer (Ansamblare și testare),
 Achiziții și Livrări.
Pentru a efectua decompoziția activăm iconița  ”Go to
Child Diagram” și apoi butonăm pe lucrarea care vrem
să-i facem decompoziția. Se va afișa o ferestră Activity
Box Count (fig. 15) în care trebuie să alegem notația
modelului (în cazul nostru IDEF0) și numărul de blocuri
funcționale în care va fi efectuată decompoziția (numărul
de diagrame fiică, în cazul nostru 4), procedăm ca în
Laboratorul N1

figura. 15. Fereastra de dialog la Decompoziția de nivelul

unu.
U SED AT: AU TH OR : R adu Basarabeanul D ATE: 05. 02. 2016 W OR KI N G R EAD ER D ATE C ON TEXT:
PR OJEC T: Modelare Bus ines Proces e R EV: 05. 02. 2016 D RA FT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A-0
C1 C2 C3 C4 C5 C6
U nnamed Arrow / 15 reguli de asamblare c arul legal reguli de t es tare norme de asamblare s tandade int erne

C om enzile c lient ilor U nnamed Arrow / 17

I1 0lei 1 O1

U nnamed Arrow / 18 C ereri pentri f urnizori

I2 O2
0lei 2

U nnamed Arrow / 19 U nnamed Arrow / 20

I3 O3

0lei 3

U nnamed Arrow / 21 Mat eriale de marketing

I4 O4

0lei 4

U nnamed Arrow / 16 ev identã cont abilã ev identã a contrat elor Ec hipament e t ehnic e unit ãti de trans port

M1 M2 M3 M4 M5
N OD E: TITLE:
Ansamblare Calculatoare N UMBER :

A0

Figura 16. Decompoziție de nivelul unu

În continuare atribuim denumiri pentru blocurile

funcționale, conectăm săgețile de intrare (I, C, M, și O)
din diagrama de context cu blocurile funcționale
respective. În continuare Interconectă blocurile
funcționale în conformitate cu ciclul tehnologic la
executarea proceselor de producere, atribuim denumire
săgeților de interconectare sau de ieșire și obținem
diagrama finală de nivelul unu.
USED AT: AUTHOR: Radu Basarabeanul DATE: 05.02.2016 WORKING READER DATE CONTEXT:
PROJECT: Model are Busi nes Procese REV: 05.02.2016 DRAFT
RECOM MENDED
NOTES: 1 2 3 4 5 6 7 8 9 10 PUBLICATION A-0
C1 C3 C2 C4 C5 C6
proceduri relatii cu cli entii
carul legal

Com enzile cli enti lor regul i de testare norme de asambl are

I1
Mnagment cereri pentru furni zori
O1
0lei 1 regul i de asambl are standade i nterne

propuneri de la furnizori
I2 Marketing si M ateriale de m arketing
O4
informatii despre cerea pi eti i vânzãri
I4
0l ei 2

ansambl e si subansambl e
Ansamblare
I3 si testare
0l ei 3
evidentã a contratel or

Achizitii produse fini te

O2
si Livrãri li vrãri
O3
0lei 4

evidentã contabil ã unitãti de transport

Echipamente tehnice

resurse umane

M1 M2 M3 M4 M5
NODE: TITLE:
Ansamblare Calculatoare NUMBER:

Figura 17. Atribuim denumiri pentru blocuri și

conectăm săgețile marginale.

Trebuie de menționat că un bloc funcțional obligatoriu are

cele patru conexiuni I - Intrări, C - Control, M –
Mecanisme de realizare, și O – (output) Ieșire (rezultatul
procesării).
U SED AT: AU TH OR: R adu Basarabeanul D ATE : 24.01.2016 W OR KING R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 10.02.2016 D RAFT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A-0

r eguli r e latii cu clie ntii s tandar de r eguli de as am blar e

inte r ne r egulide te star e nor m e de as am blar e
Cadr ul Le gal

Infor m atii bancar e ce re i pe ntr u fur nizori

ofe r te fur nizor i Em isie fact ur i

manageme ntul
com en zi de la clien ti companiei
noi cer inte
achitãri factu ri
0 lei 1 plas ar e
m ate riale m ark e ting
com en zi
planuri
marketing Inf. com e nz i plas ate
m ar ke ting piatã
si vânzãri
0 lei 2
inf.plas ar e produs e
com en zi finite
ans am ble/s ubansam ble ansamblare produs e s i
si testare s er vicii

0 lei 3
achizitii
inf. pr odus e si livrare
as am blate s uplinir e e le m ente
Achizitii s toc 0 lei 4 ach zitionate
e le m ente produs e
finite

r es urs e um ane
contabilitate
e vide nt ã e ch ipam ente te hnice unitãti de
contrac te tr ansport
N OD E: TITLE :
Asamblare PC, lãptopuri si tablete N UMBER :

A0

Figura 18. Blocuri Funcționale. Diagrama decompoziție

de nivelul unu.

6.3. Sarcina № 3.
Decompoziția funcțională de nivelul doi în notația
IDEF0.
Din diagram de decompoziție de nivelul unu
(Figura 18) se vede că blocul functional A2 - Marketing
și Vânzări și A3 - Asamblare și Testare au mai multe
interconexiuni, asta vorbește de faptul că în aceste blocuri
se petrec mai mule procese, și este necesar de a adânci
gradul de decompoziție la următorul nivel - nivelul doi.
U SED AT: AU TH OR : R adu Bas arabe anul D ATE : 24. 01. 20 16 W OR KIN G R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 05. 02. 20 16 D RA FT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A0

s tandarde in terne regili relat ii cu noi c erint e

c lien tii

planuri
M arke ting
ofer te f ur nizor i infor matie pata
Piata e xternã e xte rnã
0 lei 1

m ate riale m ark e ting

Analiza Pietii
0 lei 3

r ezultatul
analize i
m ar ke ting piatã infor m atie
M arche ting piata
Piata inte rnã inte r nã Elaborare
r ecom andãri
com enzi de la clie nti 0 lei 2 Re comandãri
0 lei 4

e vide nt ã
contabilitate
co ntracte

N OD E: TITLE : N UMBER :
marketing si vânzãri
A2

Figura 19. Decompozitia de nivelul doi a funcționalului

Marketing și Vânzări.

În procesul de analiză a proceselor ce se petrec la testarea

pieții externe și interne sau evidențiat 4 blocuri
funcționale –vezi figura 19.
Analogic efectuăm decompoziția pentru Blocul
Funcțional ”Asamblare și testare”
USED AT: AU THOR: Radu Basarabeanul DATE: 05.02. 2016 W OR KI NG READER DATE CONTEXT:
PR OJECT: Proiec t are SI REV: 05.02. 2016 DRAFT
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10 PU BLICATION A0

regulide t estare reguli de asamblare s tandarde internenorme de asamblare

Unnamed Arrow / 32

rec om andãri
0 lei 1
noi c erint e

produs e

0 lei 2

ans ambe/subansamble

0 lei 3

s uplinire s toc

0 lei 4

echipamente tehnic e c ontabilitat e res urs e umane

NODE: TITLE: N UMBER:

ansamblare si testare
A3

Figura 20. Decompozitie de nivelul doi a funcționalului

”asamblare și testare”.

În procesul de analiză a proceselor ce se petrec la

asamblarea produselor sau evidențiat 4 blocuri funcționale
- vezi figura 21.

U SED AT: AU TH OR : R adu Bas arabeanul D ATE : 05.02. 2016 W OR KIN G R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 05.02. 2016 D RA FT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A0

r eguli de s tandar de U nnamed Arrow / 32

as am blar e inte r ne

r egulide te star e
nor m e de
r ecom andãri as am blar e
Asamblare
PC
0 lei 1

PC asam blate
ans ambe /s ubans am ble
noi cerinte
Asamblare Testare
laptopuri produse
0 lei 3
0 lei 2 produs e
finite
s uplinir e s toc
laptopuri Elaborare conditii
as am blate
de garantie
0 lei 4
ce rt ificat
r ebut garantie

e chipam ente tehnice contabilitate r es urs e um ane

N OD E: TITLE :
ansamblare si testare N UMBER :

A3

Figura 21. Diagrama de decompozitie de nivelul doi

”asamblare și testare”.
Rezultatele obținute la efectuarea aceste Lucrări de
laborator sunt reflectate îtru-un raport.

7. Lucrarea de laborator № 5. 

Modelarea proceselor business și decompoziția
proceselor busuness în standardul IDEF3.
Elaborarea diagramelor proceselor business.
Scopul lucrării: Modelarea proceselor busines a
activităților din cadrul lucrării № 3 în standardul IDEF3,
construire diagrame a proceselor busines.
Timp necesar: 4 ore

7.1. Familiarizarea cu standardul IDEF3

IDEF3 – metodologie de modelare ce utilizează

descrierea grafică a proceselor busines ce se derulează
într-o consecutivitate definită (Tema 5), descrie
interconexiunile între procesele de prelucraere a datelor
(informației) care sunt părți componente ale acestor
procese. IDEF3 le oferă posibilități analiștilor de a
descrie obiectele, atunci când procesele se execută intr-o
consecutivitate bine determinată, procese care asigură
buna desfășurare a activității obiectului. 
Modelele în standardul IDEF3- conțin unități de lucru
(UoW) ”lucrări”, ”conexsiuni”, ”interjecții” și
”obiecte” de referință. 
Lucrarea (Unit of Work, activity). Se reprezintă printr-n
dreptunghi cu ungiuri ascuțite (drepte) (figira 22) și are un
nume exprimat printr-un substantiv verbal, ce arată
procesul de acțiuni, la singular ori în cadrul unei fraze, are
un număr (identificator); (de exemplu, «fabricare
produs»). Laturile lucrării au celeași drepturi. În fiecare
latură poate intra sau ieși numai câte o săgeată.
 Figura 22. Lucrarea în IDEF3
Conexsiunile. Conexiunile arată care sunt relațiile între
”lucrări”. Toate conexiunile în notația IDEF3 sunt
unidirecționale și pot fi direcționate în orișice direcție dar
de obicei diagramele în IEDF3 se construiesc așa ca
săgețile să fie orientate de la stânga spre dreapta. Trebuie
de menționat că în notația IDEF3 sunt posibile trei feluri
de (conexiuni) săgeți: 

Imaginea
Denumire Descriere
săgeții
O săgeată continuuă, ce
conectează lucrarările
(UOW). Se desenează de
Săgeată
la stânga spre dreapta sau
(conexiune)
de sus în jos. Ea arată că
predcesoară
lucrarea - inițială (sursă)
(Precedence)
trebuie să fie finalizată
înainte de a se începe
lucrarea – scop.
Fluxsuri de O săgeată cu două vârfuri
obiecte (Object la un capăt, este utilizată
Flow) pentru a descrie faptul că
 obiectul se folosește în cel
puțin două unități de lucru
- de exemplu când obiectul
e naștere într-o lucrare și
este utilizată în altă lucrae.
O săgeată cu linia punctiră,
ce este filosită la relatarea
conexiunilor unităților de
Conexiune
lucru (UOW), la fel ca și
relațională
legăturile dintre obiectele
(Relational
de referință. Aceste
Link)
conexiui se determină de
analistul ce crează această
diagram.

Joncțiuni (Junction). Terminația unei lucrări poate fi

semnal pentru începutul mai multori, sau pentru a lansa o
lucrare ce se află în așteptarea terminației mai multori
lucrări. Intersecțiile se utilizează pentru a reflecta logica
interconexiunilor săgeților (la unirea lor sau la ramificarea
lor) și pentru a reflecta multitudinea evenimentelor care
pot sau trebuie să fie finisate înainte de a se începe
următoarea lucrarea. Putem evidenția joncțiuni pentru
unirea săgeților (Fan-in Junction) și intersecții pentru
ramificarea lor (Fan-out Junction). Trebuie de menționat
că aceisi joncțiune nu poate fi concomitent utilizată și
pentru unire săgeți și pentru ramificare săgeți.
Tipuri de joncțiuni:
  
Sensul intersecției Sensul intersecției
Simbolul în cazul – contopire la ramificare
Denumire
joncțiunii conexiuni conexiuni
(Fan-in Junction) (Fan-out Junction)
Toate procesele Toate procesele
Asincron «&» precedente trebuie să următoare trebuie să
AND fie terminate fie lansaste

Toate procesele Toate procesele

asincron «&» precedente trebuie să următoare trebuie să
(Synchronous se termine fie lansaste
AND) concomitent concomintent

Unul sau mai multe

asincron Unul sau mai multe
procese ce
«sau» procese precedente
uremează trebuie să
(Asynchronou trebuie să se termine
fie lansate
s OR)
Unul sau mai multe Unul sau mai multe
Sincron
procese precedente procese ce
«Sau»
trebuie să se termine uremează trebuie să
(Synchronous
concomitent fie lansate
OR)
concomitent
Exclusiv Numai un proces Numai unul din
(exclude precedent trebuie să procesele viitoare
«sau») fie terminat trebuie să fie lansat
XOR
 (Exclusive
OR)

Obiectul de referință. Obiectul de referință în notația

IDEF3 exprimă o idee, o concepție sau date care nu pot fi
conectate cu o sageată, cu o joncțiune sau cu o lucrare.
Obiectele de referință în model sunt utilizate pentru a
atenționa cictitorul despre careva aspecte importante ale
modelului. Când relatăm obiectul de referință trebuie de
indicat și tipul obiectului de referință (figura 23).

Obiectului de referință (Fifura 23).

7.2. Descrierea proceselor business și

modelare lor
În această lucrare de Laborator noi v-om selecta o lucrare
din diagramele IDEF0 și o să o studiem detaliat cu
ajutorul metodologiei IDEF3. La decompoziția lucrărilor
IDEF0 (și DFD) trebuie de ținut cont că săgețile pe aceste
diagrame (IDEF0 și DFD) arată fluxurile de informații
sau a obiectelor, transmise de la o lucrare către altă
lucrare. În diagramele IDEF3 săgețile pot indica numai
consecutivitatea exectuării acestor lucrări, deci ele au un
alt înțeles în comparație cu săgețile din IDEF0 sau DFD.
Ca urmare a acestui fapt în procesul de decompoziție a
lucrărilor din IEDF0 sau DFD în diagramele IDEF3
săgețile nu migrează spre diagramele de un nivel mai jos.
Dacă este necesar de a arăta obiectele din diagrama
maternă trebuie de utilizat ”obiectele de referință”.

7.2.1. O să efectuăm studiul activității

”Asamblare și testare”, blocul funcțional
А3.
Executatrea acestei lucrări se începe odată cu procesul
”plasare comenzi” la asamblare. Prima acțiune se începe
cu:
- verificarea dacă sunt destule ”asamble și
subansamble” și
- se ”comandă asamble și subansamble” de
la depozit (elementele ce lipsesc).
În continuare se pregătesc asamblele și subansamblele
pentru asamblare (scoatere din cutii, dcuparea capace de
le fișele de inrare și ieșire...). În continuare se începe
procesul de asamblare:
- Instalare plăcii de bază în carcasă și
instalarea procesorului pe placa de bază,
Instalate (RAM) memorie opoerativă,
Instalare Hard-Disk.
Aceste acțiuni se efectuează pentru fiecare PC și nu
depind de configutația calculatorului. În continuare în
dependență de comanda clientului pot fi instalate:
- DVD, TV- tuner, Card-ryder.
Cu aceasta se termină asamblarea calculatotului. La
următoarea operație:
- se instalează Sistemul de Operare,
- la solicitarea clientului pot fi instalate și
alte aplicații soft.
Ultima acțiune la această etapă este perfectarea raporturi
”Raport PC asamblate” și ”Raport rezultate
asamblare”.
7.2.2. Elaborarea diagramei proceselor business
în notația IDEF3.
Pentru aceasta înserăm pe diagrama A3
activitatea ”Asamblare și testare” butonăm
iconița "Go to Child Diagram" selectăm
notația standardului IDEF3 (vezi figura. 24.
Fereastra de dialog la Decompoziția).
USED AT: AU TH OR: R adu Bas arabeanul DATE: 09. 02. 2016 W ORKING R EADER DATE C ONTEXT:
PR OJEC T: Proiec t are SI REV: 09. 02. 2016 DRAFT
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A3

0 lei

0 lei

0 lei

0 lei

NOD E: TITLE: N UMBER :

Asamblare PC
A31.1

Figura 24. Decompoziția proceselor business a activității

”Asamblare PC” în notația IDEF3 nivelul unu.

În Diagrama de decompoziție” fiică” oricând pot fi

adăugate noi lucrări, din această cauză când alegem
numărul lucrărilor putem indica un număr de lucrări
arbitrar. La crearea diagramei ”fiică” aplicația BPWin nu
transferă săgețile marginale din diagrama maternă, ele
trebuie înlocuite cu blocuri ”obiecte de referință”:
”plasare comenzi”, ”asamble și subansamble”,
”comanda asamble și subansamble” ”Raport PC
asamblate” și ”Raport rezultate asamblare”.
– pentru asta activăm iconița ”R” (Referent) de pe bara de
instrumente și în ferestruica de dialog indicăm ”Arrow” și
alegem din lista denumirilor de săgeți conexiunea
necesară (fig. 3.4.).

Fig. 25. Ferestruica de dialog Referent.

În continuare construim consecutiv lucrările și
conexiunile între lucrări în ordinea desfășurării
proceselor de asamblare și obținem diagrama finală (Fig
3.5)
U SED AT: AU TH OR: R adu Bas arabeanul D ATE : 09. 02.2016 W OR KING R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec tare SI R EV: 10. 02.2016 D RA FT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A3

plas ar e reguli de
com enzi 0 lei as am blare nor m e de
com anda as am blare com ponente ce lipse s c
ans am be /s ubans am ble
la depozit
0 lei 2
V e rificar e
0 lei
Ans am ble/ 0 lei 0 lei
s ubans am ble X 0 lei
Ins talare plãcã
pre gãtire Ins talate Ins talar e
1 asam blele / de bazã (RAM)
J1 subans am ble le s i proce sor
Hard-Dis k
7 10
com ponen te ne ce sar e 3 9

Raport PC
As am blate
0 lei 0 lei
Ins talare Ins talar e
DV D Aplicatii
4 14 0 lei
0 lei Per fe ctare
0 lei
O ins talare Ins talare
X X r apor t
TV- tune r O SO 15

J2
11 13
J8 J9
0 lei
J10 Rapor t
ins talar e as am blar e
Card-ryde r norm e d e
12 r eguli de as am blar e
as am blare

N OD E: TITLE: N UMBER :
Asamblare PC
A3.1.1

Figura 26. Diagrama de decompoziție IDEF3 nivelul unu.

Să analizăm care sunt particularitățile principale a acestei

diagrame:
După ce efectuăm lucrarea ”verifică prezența
Asabmbe/subansamble” sunt posibile două acțiuni - ori
comandăm la depozt elementele ce lupsesc ori, dacă sunt
toate elementele necesare se execută lucrarea ”pregătire
Ansamble/Subansabmle”- din această cauză noi am
inclus joncțiunea ” Sincron «Sau» (Synchronous
OR). Lucrările ”pregătire Ansamble/Subansabmle” și
”instalare placa de bază și procesor” se interconectează

cu săgeata ”Fluxuri de obiecte” . Asta indică

că între lucrări se transmit obiecte. Lucrările ulterioare se

interconectează cu săgeata ”conexiune

predcesoară (Precedence)” deoarece ele arată
conscutivitatea acțiunilor asupra acelorași obiecte. După
instalarea Hard-Discului este posibil instalarea DVD,
ТВ-tuner, Card-reader sau alte componente. Pentru
aceasta am utilizat joncțiunea ”asincron «sau»
(Asynchronous OR)”. Aceiași joncțiune construim și după
terminarea lucrării. În continuare după ce instalăm SO
(Sistemul Operațional), la cererea clientului, pot fi
instalate și alte Aplicații soft, sau dacă nu, se perfectează
Rapoartele. Pentru aceasta noi am utilizat joncțiunea
Exclusiv (exclude «sau») XOR (Exclusive OR), după
cum știm, după joncțiunea poate fi numai joncțiunea
, din această cauză înaintea lucrării ”Perfectare
Raport” am utilizat aceiași joncțiune.

Conținutul Raportului:
Rezultatele obținute la efectuarea acestei Lucrări de
laborator sunt reflectate îtru-un raport cu următorul
conținut.
 descrierea detaliată a lucrării ce trebuie descompusă
 descrierea proceselor budsines și consecutivitatea lor
 identificarea și descrierea condiționărilor la
executarea proceselor
 elaborare Diagramelor de decompoziție.
8. Laboratorul № 6. 
Modelarea Fluxurilor de Date. Construirea
diagramelor fluxurilor de date
Scopul lucrării:
Identificarea fluxurilor de date a unui proces din cadrul
lucrărilor precedente și modelarea lor în notația DFD
Timp rezervat: 4 ore
8.1. familiarizarea cu notația DFD
Diagramele fluxurilor de date (Data Flow Diagram, DFD,
Tema 5) sunt utilizate pentru descrierea circulație
documentelor și cosecutivității de procesarea a
informației. Standardul DFD ca și standardul IDEF0
reprezintă sistemul modelat ca o rețea de lucrări
interconectate. Aceste diagrame pofi ca completare a
diagramelor din notația IDEF0 pentru a relata mai clar
procesele curente de circulație a documentelor în
sistemele corporative de procesare a informației. Scopul
principal al diagramelor – este de a arăta cum fiecare
lucrare transformă informația de intrare în informația de
ieșire, precum și care sunt relațiile între aceste lucrări. O
diagram în notația DFD- trebuie să conțină: lucrări,
entități externe, conexiuni (fluxuri de date) și
repozitorii.
Lucrările. Sunt rprezentate prin dreptunghiuri cu colțurile
rotungite (figura 27),
 Figura 27. reprezentare Lucrări.

sensul lor este identic cu sensul lucrărilor în notațiile

IDEF0 și IDEF3. Precum lucrările din notația IDEF3, și
lucrările din notația DFD, au intrări și ieșiri dar nu suportă
conexiuni de control și mecanisme așa cum în IDEF0.
Toate laturile lucrărilor au același drepturi (sunt egale).
În orișice lucrare pot intra și ieși mai multe conexiuni.
Entități externe. Entitățile externe reflectă intrările în
sistemă și/sau ieșirile din sistemă. Una și aceiași entitate
externă poate avea concomitent atât întrări (având rolul
de furnizor) cât și să recepționeze ieșiri (funcționând în
rolul de receptor) Entitățile externe sunt obiecte materiale
de exemplu: beneficiar, client, personal, furnizor, depozit.
Entitate externă însemnă că ea se află în afara sistemului
analizat. Entitate externă este reprezentată printr-un
drepungi cu umbre pe marginile exterioare ale laturilor
(Fig. 28).

Figura 28. Entitate externă

Conexiuni (fluxuri de date). Conexiunile indică mișcarea
obiectelor de la lucrare la lucrare, de aici reiesă că
diagrama i notația DFD nu are săgeți marginale.
Conexiunile pot fi bidirecționale (fig. 29). 

Figura 29. Conexiune

bidirecțională

Repozitorii. Repozitoriul este un dispozitiv pentru

pastrarea informației care permite de a înscrie informația
și de a extrage informație în orișice moment, mai mult ca
atât metodele de înscriere și de extragere pot fi diferite
(fig 30.). Repozitoriul de fapt este un model al viitoarei
Baze de Date deci informația ce se păstrează în
Repozitoriu trebuie să corespundă cerințelor modelului
(Entity-Relationship Diagram).

Figura 30. Repozitoriul în DFD

8.2. Decompoziția unor lucrări din IDEF0 în
standardul DFD. 
Pentru a efectua decopoziția lucrărilor din notația IDEF0
în notația DFD trebuie să efectuăm unele acțiuni cum ar
fi:
 De a înlătura toate săgețile marginale pe diagrama
DFD;
 De construit entitățile externe în loc de săgețile
marginale și repozitoriile de informație;
 De construit săgețile interne ce se încep de la entitățile
externe ce înlocuesc săgețile marginale;
 Săgețile pe diagrama în notația IDEF0 de tunelat.

Totodată trebuie de menționat, că este dificil de respectsat

strict regulile notației DFD, și din această cauză, BPWin
ne permite să construim în diagramele DFD săgeți
marginale.

Decompoziția în notația DFD a activității ”Aachziții și

Livrare”. 
O să efectăm decompoziția lucrării ”Aachziții și Livrare”
din diagrama de decompoziție A0 – vezi Figura 19.
Lucrare de Laborator 2. În această lucrare A4 noi v-om
evidenția lucrările din diagrama ”fiică” și anume:

 Achiziție ansamble/subansamble și compnente – va

efectua acțiunile legate de selectarea celor ma
 convenabili furnizori, plasare cerere de livrare
componente.
 Păstrare ansamble/subansamble, compnente și a
calculatoarele asamblate.
 Livrarea produselor finite – toate acțiunile pentru
livrare- împachetare, perfectarea documentelorși
livrarea produselor către clienți.
Selectăm lucrarea ”Aachziții și Livrare” din diagrama de
decompoziție A0 – vezi Figura 2.6. Lucrare de Laborator
2, activăm iconița "Go to Child Diagram" din bara de
instrumente și selectăm notația DFD.

U SED AT: AU TH OR: R adu Bas arabeanul D ATE: 10.02. 2016 W OR KI NG R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec tare SI R EV: 10.02. 2016 D RA FT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A0

regul i relat ii c u c lientii s tandarde interne

0 lei 1

produs e f inite

0 lei 2 produs e s i s erv ic ii

elem ente
achzit ionate
0 lei 3
Ac hizitii elem ente
s uplinire s toc
produs e f inite

0 lei 4

res urs e um ane c ontabilitat e ev identã c ontrac te unit ãti de trans port

N ODE: TITLE:
achizitii si livrare N UMBER:

A4

Figura 31. Diagrama ”fiică” inițială în notația DFD.

 La crearea diagramei ”fiică” aplicația BPWin
transferă săgețile marginale din diagrama ”mamă”,
cum am menționat mai sus ele se înlătură și se
înlocuesc ”entități externe” - butonul "External
Reference Tool" din bara de instrumente, în
ferestruica de dialog ce a apărut selectăm butonul
”Arrow” și alegem listă denumirile ce apsarțin acestor
săgețiна панели инструментов, в появившемся
окне выбрать переключатель "Arrow" и выбрать из
списка нужное название (imaginea. 4.6):

Figura 32. Ferestruica de dialog ”External Reference”

În continuare amplasăm lucrările”fiică”, le conectăm cu

entitățile externe.
 reguli relatii cu clientii standarde interne

Unnamed A rrow / 64
Unnamed Arrow / 65

0 lei 1
elemente achz itionate
Unnamed A rrow / 66 Acizitii
componente

A chizitii elemente
0 lei 2

depozitare
componente
si PC-uri
livrare produse si
0 lei 3
servic ii
livrare inf .plas are comenz i
produse
finite
suplinire stoc
produs e f inite

res urse umane contabilitate ev identã contracte unitãti de transport

NODE: TITLE: NUMBER:

achizitii si livrare
A4

Figura 33. Diagrama”fiică” în notația DFD

9. Laboratorul № 7.
Modelarea datelor în standardul IDEF1x
Timp rezervat: 4 ore
9.1. Familiarizarea cu standardul IDEF1x
(Tema 5)
Bazele aplicației AllFusion ERwin Data Modeler.
CA ERwin Data Modeler ( ERwin) – instrument din
tehnologiile CASE- instrument pentru proectarea Bazelor
de Date, instrument care permite de a crea, documenta și
monitoriza Baze de Date, repozitorii și galerii de date.
Lucrul cu aplicația se începe cu crearea unui model nou,
pentru care trebuie de selectat tipul modelului (Logical;
Physical; sau Logical/Physical) și SGBD -ul preferat din
ferestruica ”Database” și versiunea ei ”Version” (figura
34).

Figura 34. Crearea unui Model nou.

ERwin ne permite de a crea model la nivelul logic, sau

model la nivelul fizic sau modelul combinat (Logical;
Physical; sau Logical/Physical)
Modelul de nivel logic – este o abordare abstractă a
datelor (informației) în acest model datele sunt prezentate
așa cum sunt în realitate, și pot fi numite cu denumirea lor
reală (”Furnizor”, ”Client”, ”Secție”, ”Comandă”).
Obiectele de pe acest model se numesc ”entități” și
”atribute”. Modelul logic al datelor este universal și nu
este legat de aplicarea unei SGBD reale.
Modelul de nivel fizic - depinde de SGBD-ul concret
selectat. În modelul fizic se conțin informații despre toate
subiectele Bazei de Date. modelul fizic depinde de
SGBD-ul ales în care noi vrem să creăm Baza de Date.
La nivelul logic ERwin suportă notațiile IE și IDEF1X, la
nivelul fizic susține trei notații- IE, IDEF1X și DM. În
continuare noi v-om modela lurarea noastră în notația
IDEF1X.
Trecerea de la modelul logic la modelul fizic se
efectuează prin ferestriuca de dialog din bara de
instrumrnte (figura 35).

Figura 35. Trecerea de la modelul logic la modelul fizic

Nivelul logic al modelului

Pentru a construi un model la nivelul logic utilizăm bara
de instrumente Toolbox cu instrumentele din această bară
noi construim ”entități” și ”conexiunile” dintre ele (Figura
36):

Figura 36. Bara Toolbox

imaginea
Funcția iconiței.
iconiței
 Crearea unei Entități noi. Pentru a crea o
entitate nouă butonăm pe iconiță și apoi pe un
locul liber pe câmpul modelului.
Crearea categoriilor. Pentru a relata o
conexiune ctegorizată butonăm Iconița, apoi
butonăm entitatea ”mamă” și în continuare
butonăm entitatea – fiică.
Crearea unei conexiuni ”idendificatoare”.
Pentru a conecta două entități cu o conexiune
”idendificatoare” butonăm Iconița, apoi
butonăm entitatea ”mamă” și în continuare
butonăm entitatea – fiică.

Creare conexiune ”mai mulți la mai mulți”.

Crearea unei conexiuni ”neidendificatoare”.

După ce am construit entitățile creăm ”atributele ” pentru

fiecare entitate. Pentru aceasta sunt două posibilități: i)
dublu clic pe entitate sau, ii) în meniul de context
selectăm punctul  Attributes (Figura 37).
 Figura 37. Ferestruica atributelor entității selectate.

În Ferestra atributelor entității avem posibilitate de a

vizualiza și redacta informația despre atributele create și
de a crea noi atribute. Tot aici indicăm care atribut are
statutulde cheie primară. Pentru a crea un atribut nou
activăm butonul ” New”. În fereastra de dialog ce a apărut
( Figura 38) putem: - selecta tipul atributului (BLOB,
data/ora, număr, rând), - ai da un nume atributului
(Attribute Name) și numele coloniței (Column Name),
care va reprezenta atributul la nivelul fizic (Figura 38).
 Figura 38. Creare atribute.

După ce construim entitățile efectuăm conexiunile între

ele. La crearea unei conexiuni ”idendificatoare” atributele
ce au statut de cheie primară a entității ”mamă” migrează
în componeța cheiei primare a entității ”fiică”, iar la
Crearea unei conexiuni ”neidendificatoare” migrează, pur
și simplu, în componența atributelor entitatății ”fiică”.

La determinarea statutului unei conexiuni, sau de ai

modifica statutul trebuie de făcut dublu clik pe conexiune
sau de ales din meniul de context punctul  Relationship
Properties (figura 39). Aici în registrul opțiunilor dacă
selectăm opțiunea  General putem atribui numele
conexiunii (în direcția”mamă – Fiică” și direcția ”fiică –
mamă”), nivelul puteri conexiunii (zero, una sau mai
multe; una și mai multe (Р); zero sau una (Z); fixă (un
număr concret), putem schmba tipul conexiunii. Tot aici
în opțiunea RI Action putem atribui”limita integrității”.

figura 39. Fereastra ”Relationship”.

Nivelul fizic al modelului de date.

Dacă trecem de la nivelul logic la nivelul fizic atunci în
mod automat se va crea schema fizică a Bazei de Date
(figura 40)
 Figura 40. Schema fizică a Bazei de Date create în mod
automat.

Ea poate fi completată, redactată sau a fi modificată.

Principiul de lucru la crearea schemei fizice este analogic
cu principiul de lucru la crearea schemei logice.

După ce am creat schema fizică a BD putem genera

scripturile pentri SGBD - ul ales. Pentru aceasta utilizăm
punctul meniu Tools -> Forward Engineering/Schema
Generation (Fig. 41).
Figura 41. Ferestra pentru a genera SQL-scripturi pentru
un SGBD predestinate.

Aici putem indica care scripturi trebuie de generat, de

previzualiza scripturile și de ai genera (ERwin va efectua
conexiune cu SGBD-ul selectat și în mod automat va
genera SQL-scripturi).

Această lucrare de Laborator poate fi acceptată numai în

combinație cu Lucrarea de Laborator № 6 - "Elaborarea
modelului logic al ”Domeniului Obiectiv".

9.2. "Elaborarea modelului logic al

Domeniului Obiectiv".
Elaborarea modelului logic al Domeniului Obiectiv ales
în notația IDEF1x.
În această lucrare trebuie de elaborate modelul logic al
Domeniului Obiectiv în notația IDEF1x cu instrumentul
CASE- ERwin Data Modeler, schema logică a datelor
Domeniului Obiectiv – Business-procesele care au fost
modelate în Lucrările de Laborator precedente. 
IDEF1X este bazat pe abordarea lui Chen și permite
modelarea datelor ce corespunde Bazei de Date
relaționale în a treia formă normală. Notația Chen și
procesul de construire a diagramelor a fost studiat în
cursul ”organizarea Bazelor de Date” și noi în cadrul
acestei lucrări v-om stidia numai diferențele dintre ele. 
Entitate (Entity) – obiect real sau imaginar ce are o
însemnată importanță pentru Domeniul Obiectiv. Fiecare
Entitate trebuie să aibă o denumire, exprimată printr-un
substantiv la singular. Fiecare Entitate trebuie să posede
un identificator unic. Fiecare Entitate trebuie să se
identifice univoc și să se deosebească de alte entități de
tipul dat.
Atribut (Attribute) – orișce caracteristică a entitășii, este
importantă pentru Domeniul Obiectiv cercerat și ea
servește pentru: calificare, identificare, clasificare,
caracteristica cantitativă sau exprimarea stării entității.
Denumirea atributului trebuie să fie exprimată printr-un
substantiv la singular.
Conexiune (relație) (Relationship) – asociația nominativă
între două entități al Domeniul Obiectiv cercerat.
În notația IDEF1X entitățile se împart în trei categorii
dependente, independente de identificatori sau simplu
independentă, dacă fiecare exemplar poate fi univoc
identificată fără a determina relațiile cu alte entități.
Entitatea independentă grafic este reprezentată pritr-un
dreptungi obișnuit, pe când Entitatea dependentă grafic
este reprezentată printr-un drepunghi cu colțurile
rotungite.
În notația IDEF1X există următoarele puteri de conexiuni
(relații):
 Puterea N - fiecare exemplar al entității -
parentală poate avea 0 (zero), unu sau mai mult
de cât un exemplar interconectat cu un exemplar
entitate-moștenită (fără a specifica);
 Puterea Р - fiecare exemplar de entitate -
parentală trebuie să aibă nu mai puțin de un
exemplar de entitate-moștenită conectat cu
exemplarul entității – parentală;
 Puterea Z - fiecare exemplar de entitate -
parentală trebuie să aibă nu mai mult de un
exemplar entitate-moștenită conectată cu entitate
– parentală.
 Un număr concret - fiecare exemplar de entitate -
parentală trebuie să fie conectat cu un număr fix
de entitate-moștenită.
 În ERwin la crearea conexiunui identificatoare
atributele cheiei primare a entității parentale în mod
automat se transferă în componeța cheiei primare a
entității-moștenită. Aceasta se numește migrația
atributelor. În entitate-moștenită aceste atribute se
identifică ca chie externă (FK). La crearea
conexiunui neidentificatoare atributele cheiei
primare a entității- parentale în mod cautomat se
transferă în câmpul atributelor non-cheie a entității-
moștenită.

Modelulul logic al datelor companiei de asamblare și

realizarea calculatoarelo PC și a notedook –uri. În cazul
acestei companii v-om elabora modelul logic al
procesului de ”asamblare calculatoare”. Pentru a crea
”Modelul logic al datelor” trebuie să parcurgem
următorii pași:

Pașii pentru crearea modelului logic

1. Identificarea cerințelor de business,
2. Analiza cerințelor de business,
3. Crearea modelului conceptual al datelor.
Aprobarea lui de către reprezentanții Companiei,
4. Crearea noului model logic de date care include
urmatoarele:
• Selectarea BD țintă (pt. generare scripturi pt.
schema fizică)
 • Crearea unui document cu abrevieri standard pt.
obiectele logice/fizice
• Crearea domeniilor
• Crearea regulilor
• Crearea valorilor implicite
• Crearea entităților și adaugarea definiții
• Asignarea tipurilor de date/domeniilor pt atribute
• Adăugarea de restricții CHECK/reguli sau valori
implicite
• Crearea de chei primare sau unice
• Crearea indecșilor
• Dacă e necesara, crearea subtipurilor și
supertipurilor (moștenire)
• Identificarea relațiilor între entități și crearea
cheilor externe
• Validarea modelului de date
• Aprobarea modelului logic
Crearea entități și adăugare definiții
Pentru a crea modelul logic tre. să cream entitățile
obiectului cercetat. Pentru domenul cercetat v-om
idendifica următoarele entități:
 client - persoană, ce procură calculatoare,
 comandă – lista calculatoarelor care sunt
procurate de client,
 calculator,
 ansamble - elemente, din care sunt asamblate
calculatoarele,
  colaborator – specialistul companiei, ce
asamblează un calculator concret,

Să identificăm care sunt relațiile dintre aceste entități:

 client - comandă. Un client poate plasa mai multe
comenzi. Tre. de menționat că dacă un client este în
baza de date atunci el a plasat măcar o comandă. Asta
ne arată că puterea conexiunii este - Р. Conexiune
identificatoare, de oarece comandă fără client nu
poate exista;
 comandă - calculator. În cadrul unei comenzi clientul
poate comanda mai multe calculatoare, dar ca
minimum în comandă tre. să fie măcar un calculator.
Asta ne arată că puterea conexiunii este - Р.
Conexiune identificatoare, de oare ce calculator fără
comandă nu poate exista;
 calculator - ansamble. Într-un calculator sunt mai
multe compnente diferite, unul și acelaș tip de
componete poate fi parte a diferitor calculatoare.
Puterea conexiunii este mulți la – mulți. În IDEF1X
astfel tip de conexiuni nu există pentru a rezolva
situația întroducem noțiunea de entitate asociativă –
Configurația.
 Putere conexiunii între entitățile Calculator și
Configurația este P. Deoarece orișice Calculatur
obligatoriu are o Configurație, puterea conexiunii
între entitățile Ansamble și Configurația este - N,
putem avea cazul că unele componete încă nu sunt
 instalate în nici un calculator. Conexiunea în ambele
cazuri este identificatoare pentru că nu poate exista
Configurația calculatorului fără legătura directă cu
calculatorul și cu ansamble;
 ansamble – tip de elemente. Este evident că numărul
de tipuri de ansamble care pot fi instalate este limitat
dar sunt des utilizate, v-om întroduce o entitate nouă -
tipul de ansamble. Puterea conexiunii este - Р.
Conexiunea este identificatoare;
 calculator - colaborator. Fiecare Calculator este
asmblat de un specialist. Unii dintre ei pot asambla
mai multe Calculatoare. Puterea Conexiunii – N.
Tipul conexiunii este neidentificatoare, pentru că
exemplarul entității Calculator deja poate există dar el
nu este încă legat de nici un specialist. Anume din
aceste considerente în proprietățile acestei conexiuni
noi am ales comutatorul "Nulls Allowed" (pe
diagramă un romb din patea entității parentale
specialist.

CLIENT COMANDĂ CA LCULATOR CONFIGURATIA

S P ECIALIST T IP ASAMBLE A SAMBLE

 Figura 42. Modelul logic al datelor a Companiei de
asamblare Calculatore și Notebook-uri.

10. Lucrare de lsaborator Nr.8

Planificarea proiectului. Estimare costuri
Timp rezervat: 4 ore.
De studiat temele 12 și 13 din manual

10.1. Familiarizarea cu metoda Decompoziția lucrărilor

proiectului. Tema 12 Managmentul Proiectelor.
(Procesele din fazele proiectului)
Ghidul Cunoaștințelor de Bază pentru Managementul
unui Proiect (PMBOK® Guide) - Ediția a cincea oferă
linii directoare pentru gestionarea proiectelor individuale
și definește conceptele legate de gestionarea proiectelor.
De asemenea, descrie ciclul de viață al managementului
proiectului și procesele aferente, precum și ciclul de viață
al proiectului.

Figura 43. Ffaze de dezvoltare al proiectului

Confor acestui ghid orișce proiect are 5 faze de dezvoltare
al proiectului ce sunt formate din Grupuri de procese
cunoscute sub numele de Project Management Process
Groups (sau Grupuri de proces):
• Procese de Inițiere. Aceste procese efectuate pentru
a defni un nou proiect sau o nouă fază a unui proiect
existent, prin obținerea autorizației pentru a începe
proiectul sau faza.
• Procese de planificare. Acele procese necesare
pentru a stabili sfera de aplicare a proiectului, pentru
a rafina obiectivele și pentru a defini cursul acțiunilor
necesare pentru atingerea obiectivelor pe care
proiectul a fost întreprins pentru a le atinge.
• Procese de Executarea. Aceste procese efectuate
pentru finalizarea lucrărilor definite în planul de
management al proiectului pentru a satisface
specificațiile proiectului.
• Procese de Monitorizarea și controlul. Acele
procese necesare pentru a urmări, revizui și regla
progresul și performanța proiectului; identificați
domeniile în care sunt necesare modificări ale
planului; și inițiați modificările corespunzătoare.
• Procese de închiderea . Aceste procese efectuate
pentru a fnaliza toate activitățile din toate grupurile
de proces pentru a închide formal proiectul sau faza.

Pentru a stabili sarcinile prioritare ale proiectului în

conformitate cu obiectivele de dezvoltare ale
 organizației, managerul de proiect efectuază
decompoziția lucrărilor proiectului.
Una dintre principalele abordări ale decompoziției
lucrărilor de proiect este metoda Work Breakdown
Structure (WBS).
WBS este un instrument pentru împărțirea tuturor
activităților proiectului în: pachete de lucru gestionabile,
definite, care permit atingerea unui nivel de detaliu al
informațiilor furnizate care răspund nevoilor proiectuuil.
WBS vă permite să definiți lucrările de proiect în termenii
ciclului de viață al proiectului.
WBS este o metodă în metodologia clasică de
gestionare a proiectelor și inginerie de sisteme, structura
de decompziție a lucrărilor (WBS) este o metodă care
descompune un proiect într-o ierarhie de: rezultate, sarcini
și subsarcini.
Este un instrument util care definește o estimare detaliată
a lucrărilor, costurile lucrărilor și a timpului necesar
pentru efectuarea lucrărilor și oferă îndrumări pentru
elaborarea și controlul programului de dezvoltare.
În esență, folosirea unei structuri de descompnere a
lucrărilor vă permite să aruncați o privire de sus în jos
asupra proiectului dvs. și să o includeți în sarcinile și
subtasco-urile care vor putea finaliza.
Este o modalitate simplă, de organizare și înțelegere a
scopului proiectului dvs. în componente mai mici și ușor
de gestionat.
 Denumire
proiect

Faza 1 Faza 2 Faza 3 Faza 4 Faza 5

3.1 4.1
1.1 1.2 2.1 2.2

4.1.1 4.1.2
1.1.1 2.2.1 2.2.2 3.1.1
4.1.1.1 4.1.2.1

Figura 43. Graful Decompoziției lucrărilor unui proiect

Structura decompziței lucrărilor (WBS) este un grafic

(fig. 43) care prezintă rezultatele și componentele
proiectului; este folosit pentru a oferi claritate cu privire
la ceea ce proiectul trebuie să furnizeze și ăn ce ordine.
WBS este creat ca o ierarhie a lucrurilor pe care
proiectul le va produce și organizează activitatea unei
echipe în bucăți manevrabile.
Ierarhia are de obicei de la două până la patru niveluri.
Acesta clarifică exact ce se va livra la sfârșitul proiectului
și arată modul în care aceste livrări se raportează între ele.
WBS este nucleul pentru patru procese primare și unul
secundar:
a. definirea muncii
b. planificarea resurselor
c. estimarea costurilor
d. bugetarea,
e. identificarea riscului
Lucrările planificate sunt cuprinse până la cel mai jos
nivel de componente WBS, care se numesc pachete de
lucru.
Un pachet de lucru poate fi utilizat pentru a grupa
activitățile în care munca este programată și estimată,
monitorizată și controlată.
În contextul WBS, munca se referă la produse de lucru
sau la livrări care sunt rezultatul activității și nu la
activitatea în sine.
Reguli pentru crearea WBS
• Regula 100%:
- Una dintre cele mai importante reguli în WBS este
regula 100%, care prevede că toate activitățile proiectului
ar trebui înregistrate în WBS (acțiunile care nu există în
WBS nu pot fi planificate și nu există în proiect).
Regula de 100% se aplică și la toate nivelele - astfel,
acțiunile la un nivel reprezentând descompunerea
activităților de la un nivel imediat superior (activitatea
părintească) ar trebui să reprezinte 100% din aceasta.
• Divizarea pe nivele:
- Dacă proiectul va fi dezvoltat în conformitate cu PLC
(Project Life Cicle), etapele vor fi la primul nivel al
WBS.
- La nivelul următor al WBS, sunt identificate
principalele componente ale proiectului.
- Aceste componente ar trebui deja definite și
documentate.
- Dacă există deja un nivel de fază, atunci trebuie să
grupăm componentele și să le raportăm la fazele
corespunzătoare.
• Nivelul de detaliere.
Una dintre problemele cu care se confruntă managerul
de proiect în procesul de creare a WBS este
profuzimena de detaliere a lucrării (decompoziția
lucrării):
- regula celor 8 - 80 de ore - spune că nicio lucrare nu
trebuie să depășească activitatea totală de 80 de ore pentru
realizarea ei;
Nici o lucrare nu trebuie să dureze mai mult decât
perioada de raportare în cadrul proiectului. !!!
• Dimensiunea structurii WBS
Structura WBS nu trebuie să depășească 100-200 de
elemente terminale (elementul terminal este cel mai
scăzut element - activitate - care nu poate fi împărțit).
Dacă este necesar mai mult de un element terminal, sunt
utilizate subproiecte.
WBS nu trebuie să aibă mai mult de 3-4 niveluri, fiecare
nivel nu mai mult de 5-9 elemente.
Aceste sugestii decurg din faptul că:
- posibilitatea memoriei umane pe termen scurt
este limitată la 5-9 elemente;
- Dacă este stabilit un timp fix pentru planificarea
proiectului, cu cât sunt mai multe terminale, cu
atât mai puțin timp este alocat fiecărui individ;
 • - Cu cât sunt mai multe elemente terminale, cu atât
vor fi mai dependente.

10.2. Decompoziția lucrărilor proiectului, creare

WBS.
Pentru creare unui WBS ]n present sunt peste 250 de
aplicații, este dificil de da o recomandare univocă, dar
cele mai populare la moment pot fi numite:
- Edraw Max Breakdown Structure Software
- 2-plan Desktop 
- WBS Schedule Pro
- WBS Tool
- MindView's WBS Software
Studentul este liber să aleagă aplicația de creare WBS.
În exemplul nostru sunt prezentate graful WBS dupa
aplicația WBS Schedule Pro (fig.44a, b, c)
și graful WBS dupa aplicația MatchWare MindView 7.
(fig.45a,b)
 10.3. Estimarea Costurilor unui proiect
Estimarea Costurilor unui proiect reprezintă procesul de
dezvoltare a unei aproximări a resurselor bănești
necesare pentru finalizarea activităților proiectului.
Scopul cheie al acestui proces este de a determina
costul necesar pentru finalizarea lucrărilor de proiect.

Figura 13.2. Estimare Costuri: intrări, instrumente, tehnici

și rezultate

10.3.1. Sistemul de calculație a costurilor pe activități

(ABC costing)
De studia Tema 13 din manual
Metoda ABC se distinge de metodele traditionale de
calculație a costurilor prin faptul că repartizează intai
costurile pe activitati, si apoi, in functie de o cheie de
repartizare stabilita pentru fiecare activitate, asigura
repartizarea costurilor asupra fiecarui produs finit sau
serviciu care a utilizat respectiva activitate

Metoda consta în:

- Identificarea activitatilor care sunt necesare obținerii
produsului/serviciului ( de exemplu : proiectare,
asamblare, testare);
- Determinarea costurilor acestor activitati : directe si
indirecte;
- Determinarea pentru fiecare activitate a unei chei (baze)
de repartizare a costurilor. Aceste chei alocă costurile
activităților pe baza de consum sau în funcție de cererea
pentru respectiva activitate.
- Identificarea produselor finite sau serviciilor rezultate.
- Repartizarea costurilor activităților către aceste produse
finite sau servicii utilizând cheile de repartizare anterior
determinate.
Modelul general de calculaţie a costurilor produselor,
lucrărilor executate sau a serviciilor prestate se exprimă
cu relaţia:
În care:
Cu - cost unitar al produsului;
Cd - costuri directe încorporabile;
Ci - costuri indirecte
încorporabile repartizate asupra
produsului respectiv;
Q - cantitatea de produse.

Înainte de a începe să lucrați la o estimare trebuie să

înțelegeți obiectivele strategice ale proiectului și
obiectivele dvs. din perspectiva afacerii. S-ar putea să
planificați să obțineți cât mai mult profit posibil, să
explorați noi tehnologii sau să obțineți un client excelent,
chiar dacă proiectul poate deveni pierderi.
Astfel, puteți pune în estimare o marjă ridicată sau puteți
rămâne la limita profitabilității și puteți accepta anumite
riscuri financiare. În orice caz, este necesară o estimare
precisă pentru a ține proiectul sub control.
În dezvoltarea de software, este vorba în principal de
costul timpului pentru oamenii care lucrează la un proiect
și nu este ușor de estimat, deoarece este greu să ne
imaginăm toate aspectele suficient de exact.
Estimare de jos în sus
Este întotdeauna o provocare să estimăm cât timp are
nevoie o echipă pentru a finaliza un proiect în general.
În același timp, în majoritatea cazurilor, este posibil să se
perceapă scopul unei sarcini mici și să se creeze o
estimare a timpului pentru aceasta.
Astfel, dacă proiectul dvs. este mare, ar trebui să îl
împărțiți mai întâi în sarcini mai mici. Un astfel de plan
format din sarcini mici se numește structură de
decompoziție a lucrului (Work Breakdown Structure)
Decompoziția este vitală nu numai pentru estimarea
timpului și a costurilor, dar pentru multe alte activități de
management de proiect.
Rezumând astfel de prognoze atomice de timp, puteți
obține costul total al proiectului după aplicarea ratei orare.
Aceasta este o tehnică populară estimare de jos în sus.

Estimare sarcinilor individuale

În ceea ce privește sarcinile individuale, există câteva
abordări pentru estimarea acestora:
-Estimare prin analogie
- Estimare prin parametri
- Estimarea în trei puncte

Estimare prin analogie

Analogul de estimare este determinarea unei estimări
bazate pe sarcini similare din proiectele finalizate
anterior.
Estimarea parametrică
Estimarea parametrică este o tehnică care permite
estimarea costului unei sarcini prin scalarea
caracteristicilor altor sarcini din proiecte bine cunoscute.
De exemplu, să presupunem că dezvoltarea unei scheme
de baze de date pentru proiectul A a durat o săptămână.
Dacă noul dvs. proiect este de două ori mai sofisticat,
puteți presupune că aceeași sarcină va necesita două
săptămâni.
Estimarea în trei puncte
Această metodă implică pregătirea unor estimări
optimiste, pesimiste și cel mai probabil. Apoi, estimarea
finală poate fi primită fie ca
distribuție triunghiulară: E = (a + m + b) / 3
sau distribuția beta: E = (a + 4m + b) / 6

a = cea mai bună estimare

m = estimarea cea mai probabilă
b = estimarea celor mai gravă
Este de menționat faptul că această tehnică se folosesște
adesea împreună cu celelalte două descrise mai sus.

În general, estimarea sarcinilor individuale și apoi

sumarea acestora funcționează destul de bine.
Cu toate acestea, există câteva puncte de luat în
considerare înainte de a trimite o ofertă către clientul dvs.

- Complexitatea generală a proiectului crește exponențial

odată cu numărul de caracteristici din proiect.
În proiectele mari, există multe dependențe și
interconectări între diferite componente. Cere mai multă
muncă, aduce mai multe contingențe și necesită procese
mai ample de asigurare a calității.

- Există riscuri în fiecare proiect și este bine să aveți un

plan de răspuns la riscuri. Gândiți-vă cum le veți atenua și
ce vă poate costa.

- Când planificați un proiect, este probabil să uitați să

luați în considerare câteva detalii. Deci, fiți pesimist în
ceea ce privește domeniul de aplicare pe care îl puteți
vedea. În totdeauna trebuie să presupunem că există
lucruri pe care nu le vedem.

- Planificați timp semnificativ pentru asigurarea calității și

adresarea feedback-ului clienților și includeți acest lucru
în estimarea dvs.
Exemplu de estimare cost unui Web-cite

Pentru estimarea costului unui Web-cite sunt destule

instrumente one-line.

În exemplul nostru vom utiliza

https://www.webfx.com/web-design/website-design-cost-
calculator.html - PROJECT QUOTE CALCULATOR
De la proiectan se cere să urmeze indicașiile și să
completeze datel despre proiectul său
Butonăm ”see pricing”- obținem tabelul Quote Details,
Mai jos avem butonul Get exact quote
11. Elaborarea Proiectul de Curs. 2-ore
Proiectul de curs trebuie să conțină:
a) Lucrarea de laborator № 1. Analiza domeniului de
studiu.
b) Lucrarea de laborator №.2. Caietul de Sarcini;
c) Lucrarea de laborator № 4:
 - Sarcina № 1. Determinarea contextului de
funcționare. Elaborarea diagramei de context în
notația IDEF0.
- Sarcina № 2. Decompoziția funcțională de nivelul
unu în notația IDEF0. Elaborarea diagramei.
- Sarcina № 3. Decompoziția funcțională de nivelul
doi în notația IDEF0. Elaborarea diagramelor
d) Lucrarea de laborator № 5, punctul 7.2.
Identificare și descrierea proceselor business
pentru obiectul de informatizare. Modelare
proceselor busines.
e) Lucrarea de laborator №6. Modelarea Fluxurilor
de Date în notația DFD. Punctul 8.2.
Decompoziția unor lucrări din IDEF0 în
standardul DFD. 
f) Lucrare de laborator № 7. Punctul 9.2 ”Elaborarea
modelului logic al Domeniului Obiectiv".
g) Lucrare de laborator № 8.

În cadrul Proiectul de Curs suplimentar trebuie sî fie

elaborată:
-”Diagrama organizațională” a Companiei, model
arboriscent sau model matricial.

REMARCĂ.
În caz de necessitate Proiectul de Curs poate fi suplinit
cu: diagrame elaborate în alte limbaje de modelare cum ar
fi:
 Event Process Chain (EPC), instrumente: Edraw
Max, ARIS Expres
 Process Interchange Format (PIF),
 Color Petri Net (CPN), instrumente: CPN Tools
4.0.1
 NIST Process-Specification Language,
 Enterprise data model,
 Business Intelligence Model
 Unified modeling languag (UML),

Tipul diagramelor și cantitatea lor este determinate de

necesitatea detalizării și dezvăluirii specificului sistemului
informational ce va fi elaborat

Anexe
ANEXA 1. Ghid pentru realizarea proiectului de curs
Prezentul ghid descrie exigenţele legate de
elaborarea proiectului de curs, el este realizat cu scopul de
a oferi informaţii complete în vederea îndeplinirii
criteriilor minimale de valoare şi calitate. Ghidul este un
document de lucru care se adresează:
a. studenților, cu informaţii complete privind modul de
realizare a părţii scrise a proiectului de curs;
b. profesorilor, ca instrument de îndrumare sistematică a
elevilor, dar şi ca suport pentru instituirea unor criterii
unitare de evaluare;
Formatul proiectului 
Proiectul trebuie să cuprindă următoarele părţi:
1. PAGINA DE TITLU
2. CUPRINS
3. LISTA CU ABREVIERI (opţional)
4. ARGUMENT
5. CONŢINUTUL
6. BIBLIOGRAFIA
7. ANEXE
8. GLOSAR DE TERMENI (opţional)  

Proiectul va fi redactat pe computer pe un format de hârtie

A4 portret sau vedere după cum o cere conţinutul, la un
rând şi jumătate distanţă, în Times New Roman, mărimea
fontului fiind de 12 pt. Paginile vor fi numerotate cu cifre
arabe, în partea de jos-centru a fiecărei pagini. Fiecare
capitol va fi început pe o nouă pagină, dar nu şi
subcapitolele şi subpunctele. Capitolele vor fi numerotate
cu numere arabe (1, 2, 3, etc.), la fel şi subcapitolele (1.1,
1.2, 1.3, etc.) şi subpunctele (1.1.1, 1.1.2, sau 1.2.1, 1.2.2,
etc). Titlul capitolelor, subcapitolelor şi subpunctelor vor
fi scrise în bold cu font mai mare de 12 pt. (titlul
capitolelor va fi cules cu majuscule). Este obligatorie
folosirea diacriticelor.
Pagina de titlu va conţine următoarele informaţii:
 1. numele universității (se va folosi şi sigla) cules cu
bold şi 20 pt
2. titlul proiectului ales de student, centrat, cules cu
bold şi 26 pt.
3. nivelul de susţinere (proiect de curs)
4. numele profesorului îndrumător
5. numele studentului, sau studenților care fac parte
din echipa de realizare a proiectului
6. Localitatea şi anul realizării
Cuprinsul va conţine numele capitolelor, subcapitolelor
şi subpunctelor, respectiv bibliografia şi anexele, cu
indicarea paginaţiei corespunzătoare din text.

Lista cu abrevieri va conţine abrevierile des folosite,

dacă este cazul.

 Argumentul. După realizarea lucrării fiecare

autor/echipă va concepe un text de 2-2,5 pagini
care să descrie modul în care a fost abordată
realizarea proiectului de către student sau echipă
cu evidenţierea contribuţiilor personale şi a
importanţei lucrării elaborate.
 Conţinutul portofoliul trebuie să atingă toate
sarcinile impuse de către profesor.

Foarte important! Fiecare profesor poate îmbunătăţi

acest ghid!
Anexa 2. Aplicații utilizate la efectuarea
lucrărilor de laborator
Aplicația AllFusion Process Modeler 7.1 SP2
(BPwin, ERwin)
 instrument pentru modelare, analiză, documentare,
și optimizare Business - Procese.
poate fi descărcată de pe adresa: https://utm-
my.sharepoint.com/personal/pavel_chirev_ati_utm_md/
_layouts/15/onedrive.aspx?id=%2F
 la instalare  se va cere ”lycence key”,  care pot fi
încercate din liste de mai jos.

TS6DW-QC5HF-MV4P4-WJBGD-URTSA
LS4VQ-PCHG3-LDWPC-TG7DV-SQ4DA
TS4VQ-TCLGX-LDWPC-THKHE-LQ3YA
826VY-TCKH3-ND6QC-XH7PV-CR3WA
PA5VU-P4HH7-MD2PU-VHFKV-ARKUA
3N6DW-QL4HF-MV4P4-WHXJE-NRTWA
6J4DN-P4GGX-KVUN4-SG7CV-AQT2A

Aplicația AllFusion Process Modeler (Erwin- 9.6.0))

http://rmdmdownloads.ca.com/akdlm/ERwin/EvalCE/
ERwin.exe
http://download.freedownloadmanager.org/Windows-
PC/CA-ERwin-Data-Modeler/FREE-9.6.00.4430.htm

Referințe Selective:
1. Unelte şi tehnici de dezvoltare a sistemelor,
Prof.dr.ing. Liviu Roşca
2. AllFusion Process Modeler. 2002 Computer
Associates International, Inc. (CA)
3. CA ERwin Data Modeler. Implementation Guide.
Release 9.64.00
4. IDEF1X Introduction. Derek Asirvadem. 1993-
2013 Software Gems Pty Ltd.
5. The IDEF3 Process description language:
http://www.idef.com/, pp 21-
pp 51 (process schematics only, not
including object schematics.)
6. Donald S. Le Vie, Jr. Understanding Data
Flow Diagrams
7. Michael Grüninger and Christopher
Menzel. The Process
Specification Language (PSL) Theory and
Applications
8. Paulo Merson. Data Model as an
Architectural View. Technical note
CMU/SEI-2009-TN-024, October 2009
9. WBS Schedule Pro. User's Guide. Critical Tools, Inc.
2016