Proiectarea Unui Sistem Informatic

Lucrarea de laborator Nr.
2
Tema: Formularea problemei i analiza domeniului de studiu
Obiective urmrite:
Prezentarea organizaiei i definirea corect a obiectului/domeniului supus studiului;
Analiza i expunerea corect a structurii sistemului informaional n care urmeaz s fie

implementat sistemul informatic;
Analiza proceselor de activitate corespunztor fiecrui nivel funcional al organizaiei;
Studiul, analiza i prezentarea sistemului informaional actual al ntreprinderii;
Evidenierea rolului sistemului informaional n activitatea organizaiei;
Construirea organigramei.
Cerine:
1. Prezentarea domeniului/firmei/instituiei/organizaiei studiate.
a. Descrierea organizaiei;
b. Prezentarea sistemului informaional al organizaiei.
2. Specificarea principalelor (sub)sisteme informaionale.
a. Evidenierea corespondenei: component a organizaiei (birou, departament,
compartiment, oficiu, director) i subsistem informaional;
b. Prezentarea nivelului de informaizare/automatizare a proceselor de prelucare a
datelor;
c. Descrierea aplicaiilor i a componentelor hardware utilizate deja n procesele de
activitate ale sistemului informaional (n cazul n care sunt deja utilizate sisteme
informatice se vor descrie acestea).
3. Prezentarea structurii organizaionale.
a. Descrierea componentelor organizatorice (componenta financiar-contabil, componenta
pentru managementul resurselor umane, componenta pentru managementul resurselor
materiale, componenta de eviden a produciei/serviciilor, componenta de eviden a
vnzrilor, componenta de gestiune a comenzilor etc.) i a responsabilitilor acestora;
b. Evidenierea principalelor roluri n activitatea fiecrei componente organizatorice;
c. Construirea organigramei.
Noiuni necesare a fi cunoscute pentru realizarea lucrrii:

Printre componentele funcionale de baz ale ntreprinderii pot fi menionate:
componenta de administrare (responsabil de luarea deciziilor) a ntreprinderii;
componenta de cercetare i dezvoltare tehnologic;
componenta de aprovizionare, responsabil de achiziia resurselor materiale consumate n

ntreprindere;
componenta de producere responsabil de crearea produciei/serviciilor ntreprinderii;
componenta de desfacere, responsabil de vnzarea produselor ntreprinderii;
componenta de depozitare, responsabil de pstrarea produciei (uneori poate coincide cu

componenta de desfacere);
componenta personal, responsabil de selectarea personalului i managementul resurselor

umane ale ntreprinderii;
componenta finaciar-contabil, responsabil de planificarea i gestiunea resurselor financiare

ale ntreprinderii [1].
Aceste, componente funcionale menionate, vor sta la baza evidenierii subsistemelor
informaionale ale ntreprinderii.

Rezultatul organizrii structurale (gruparea funciilor, activitilor, atribuiilor i sarcinilor n
baza anumitor criterii) n cadrul unei organizaii reprezint structurarea organizatoric a acesteia.
Structura organizatoric a unei organizaii reprezint ansamblul persoanelor i ale entitilor
organizatorice constituite astfel nct s asigure realizarea obiectivelor organizaiei. n cadrul
structurii organizatorice pot fi evideniate dou substructuri principale: structura managerial
(corespunztoare sistemului de conducere) i structura de producie (corespunztoare sistemului
operaional). Postul reprezint cea mai simpl subdiviziune organizatoric i se definete ca
ansamblul obiectivelor, sarcinilor, competenelor i responsabilitilor, care revin spre exercitare unui
salariat al organizaiei. Totalitatea posturilor cu aceleai caracteristici principale formeaz o funcie.
Se deosebesc dou tipuri principale de funcii: manageriale i de execuie.
Organigrama este reprezentarea schematica a structurii organizatorice a unei ntreprinderi, a
unei institutii, a subordonrii compartimentelor acestora, a tipurilor de legturi ntre aceste
compartimente. n mod obinuit organigrama este alctuit din dreptunghiuri ce reprezinta posturi de
conducere sau compartimente i din linii care reflect legturile organizatorice.
Observaie: Organigramele pot fi construite pentru:
- ntreaga organizaie - organigrame generale sau de ansamblu, n care se reprezinta grafic structura
organizatorica a intregii unitati economice;
- pentru o careva component a organizaiei - organigrame pariale care reflect detaliat un
compartiment sau o grupa de compartimente ale structurii organizatorice respective.
Principalele reguli necesare a fi respectate la construirea organigramelor:
a)
marimile dreptunghiurilor i grosimile contururilor acestora se coreleaza cu obiectul, sarcinile,

autoritatea si responsabilitatea implicate, cu alte cuvinte patrulaterele pentru servicii trebuie
sa fie mai mari si cu contururile mai groasee decat cele pentru birouri etc;
b)
situarea in organigrama a dreptunghiurilor si liniilor trebuie sa reflecte raportul de

subordonare ierarhica, toate posturile si compartimentele care alcatuiesc un nivel ierarhic
inscriindu-se pe aceeasi orizontala;
c)
organigramele
complexe,
indeosebi
cele
care
exprima
mai
multe
tipuri
de
relatii
organizatorice, trebuie sa cuprinda legende cu semnificatia simbolurilor utilizate.

Observaie: Pentru a construi organigrama poate fi utilizat orice editor grafic sau unul special care are
deja elementele ncorporate, precum MS Visio.
Exemple de artefacte specifice lucrrii de laborator nr.2:

1) Pentru componentele funcionale enumrate mai sus poate fi construit o astfel de
organigram (Fig. 3.):
Director general
Director marketing
Director comercial
Director executiv
Seviciul economie,
finante si evidenta
contabila
Sectie planificare si
marketing
Sectie receptie
produse
Sectie evidenta
resurse umane
Contabilitate
Sectie logistica si
transportari
Sectie
aprovizionare
Sectia IT
Sectie vanzari
Sectie evidenta
operativa
Sectie certificare
Depozit
Fig. 3. Exemplu de organigram

2) Exemplu de organigram pentru o ntreprindere care comercializeaz produse (Fig. 4 i Fig.
5):
Administrare
(Director)
Marketig, aprovizionare
si dezvoltare
(Manager responsabil de
dezvoltarea activitatii)
Vanzari
(Vanzator si asistent
al vanzatorului)
Managementul
resurselor umane
(Manager resurse
umane)
Contabilitate si finante
(Contabil sef, ajutor
contabil )
Depozit
(Administratorul
depozitului)
Fig. 4. Exemplu organigram
Director
Serviciul juridic si
resurse umane
Serviciul comercial
Sectia vanzari
Serviciul promovare
Serviciul financiarcontabil
Depozit
Fig. 5. Exemplu organigram
Sarcini propuse pentru rezolvare:

1. Construii organigrama pentru urmtoarele componente funcionale: Rector, care are doi
subordonai Prorector stiine i Prorector relaii externe. Prorectorul pe tiine are n
subordine 3 decani Decan tiine Economice, Decan tiine Juridice i Decan tiine
Politice. Prorector relaii externe are ca subordonai Manager relaii cu studenii i
Manager relaii cu publicul.
2. Construii organigrama pentru urmtoarea descriere: direcia general Resurse umane are n
subordine patru subdiviziuni departamentul juridic, departamentul financiar-contabil,
departamentul tehnologiilor informaionale i departamentul achiziii publice.
Lucrarea de laborator Nr.3

Tema: Cercetarea unui subsistem/sistem informaional i
prezentarea ariei de ntindere a acestuia
Obiective urmrite:
Delimitarea subsistemelor informaionale ale organizaiei, conform componentelor funcionale;
Evidenierea corect a surselor de date a sistemului informaional, a locurilor i modalitilor

de prelucrare a datelor, a locurilor de stocare a datelor;
Descrierea algoritmilor de obinere a informaiilor, n baza datelor disponibile, destinaia

informaiilor generate de sistemul informaional.
Cerine:
1. Delimitarea ariei de ntindere pentru subsistemul analizat.
a) Delimitarea sistemului informaional (n cazul n care ntreprinderea nu este mare). Pentru
ntreprinderile mari, cu multiple componente organizatorice se va alege pentru analiz
detaliat un subsistem informaional, corespunztor unei componente organizatorice;
b) Evidenierea i expunerea referitor la subsistemul decizional, de management i a celui
operaional;
c) Stabilirea entitilor externe aflate n legtur cu sistemul (subsistemul) analizat.
2. Descrierea activitii subsistemului informaional.
a) Identificarea i descrierea proceselor de prelucrare (urmrind prelucrrile manuale sau cu
ajutorul calculatorului, de unde sunt preluate datele, la ce operaii de calcul sunt supuse, cum
sunt preluate, ce interogri se realizeaz etc.);
b) Analiza intrrilor i analiza ieirilor (fluxurile informaionale i documentele care circul n
domeniu). Pentru documente se va descrie structura i componena acestora.

n cadrul acestei lucrri vor fi identificate procesele de activitate zilnice ale subsistemului
operaional i ale celui de management, din sistemul informaional. Un proces de activitate
(business proces) este o colecie de actitiviti structurate i relaionate care produc un produs sau
serviciu specific (raspunznd unei nevoi) pentru un client particular sau pentru clieni n general.
Acesta poate fi vizualizat adesea cu ajutorul unei diagrame de flux ca i secvena activitilor,
cuprinznd i noduri decizionale.
Competitivitatea unei organizatii depinde mult de gradul de structurare, optimizare i

relaionare dintre procesele organizaiei. Cnd managementul doreste costuri mai mici de producie,
perioade mai scurte de livrare, o calitate crescuta a produselor, va fi necesar s modifice procesele.
Astfel, activitatea unei organizaii poate fi mprtita pe procese. Iar ntregul, numit
organizaie/companie se bazeaz pe o hart a proceselor. Procesele descriu ceea ce trebuie fcut,
cum trebuie fcut i de cine trebuie fcut [12].
Noiunea de analiz a proceselor de activitate presupune:
Obinerea unei nelegeri lucrative privind procesele de business
nelegerea cerinelor grupurilor interesate
Determinarea scopului i obiectivelor fiecarui proces
Identificarea problemelor asociate proceselor i determinarea cauzelor acestora
Dezvoltarea opiunilor de mbuntire a proceselor
Iniierea aciunilor de mbuntire a proceselor.
Deasemenea analiza proceselor de business include i definirea modului n care organizaia
adopt o activitate i modul n care se mbuntesc procesele.
n continuare se vor descrie fluxurile informaionale specifice acestor procese de activitate,
sursa i destinaia acestora. Se vor specifica informaiile (rapoartele) i sursele acestora.
Se vor identifica i descrie principalele funcii decizionale specifice organizaiei analizate. Vor fi
descrise principalele fluxuri informaionale i sursele acestora.

1) Exemplu de descriere a unui document specific domeniului analizat (se va descrie ce reprezint
factura i bonul fiscal pentru ntreprinderea care comercializeaz produse):
a)Factura se ntocmete, n cel putin dou exemplare, pentru livrarile de bunuri i/sau prestrile
de servicii efectuate. Acest document servete ca:
act pe baza cruia se efectueaz procesul de decontare a bunurilor livrate;
act de nsoire a bunurilor pe timpul transportului;
act de ncrcare n gestiunea cumparatorului;
act justificativ de nregistrare n contabilitatea furnizorului i a cumpratorului.
Factura trebuie s cuprind, n mod obligatoriu, cel puin urmtoarele date:
numarul de ordine, n baza uneia sau mai multor serii, care s identifice factura n mod
unic;
data emiterii facturii;
denumirea, adresa i codul de nregistrare ale persoanei juridice care emite factura;
denumirea, adresa i codul de nregistrare ale cumparatorului de bunuri sau servicii;
denumirea i cantitatea bunurilor livrate sau denumirea serviciilor prestate;
data la care au fost livrate bunurile sau au fost prestate serviciile, cu exceptia cazului n care
factura este emis nainte de data livrrii/ prestrii sau ncasrii avansului;
baza de impozitare a bunurilor i serviciilor, pentru fiecare cota de TVA, scutire sau
operaiune netaxabila, preul unitar, exclusiv TVA, precum i rabaturile, reduceri de pre etc.
La furnizor, factura circul:
la compartimentul desfacere, n vederea nregistrarii n evidenele operative i pentru

eventualele reclamaii ale clienilor;
la compartimentul financiar-contabil, pentru nregistrarea n contabilitate.
La cumparator, factura circul:
la depozitul, care primete produsul i este responsabil de pstrarea acestuia;
la
compartimentul
financiar-contabil,
pentru
acceptarea
plaii,
precum
pentru
inregistrarea n contabilitate.
Factura poate fi tiparita pe orice format de foaie.
b) Bonul fiscal este emis de casa de marcat i trebuie sa aib nscrise cel puin urmtoarele date:
denumirea, adresa i codul fiscal ale agentului economic emitent;
logotipul i seria aparatului de marcat;
numrul de ordine al bonului, data i ora emiterii;
denumirea bunurilor sau serviciilor livrate, cantitile, preurile unitare, valoarea i cota de
TVA aplicat;
valoarea totala a bonului, valoarea aferenta TVA i valoarea altor taxe necuprinse n baza de
impozitare a TVA.
Bonul fiscal trebuie sa fie nmnat n mod obligatoriu clienilor, odat cu bunurile vndute.
Neemiterea bonurilor fiscale constituie contravenie.
2) Exemplu pentru stabilirea entitilor externe ale unui sistem informaional (se va exemplifica
pentru subsistemul de depozitare a vaccinurilor, dintr-o instituie medical). Sunt descrise
entitile externe i fluxurile de intrare i ieire n/din sistem.
Tabelul 1. Prezentarea surselor, destinaiei i fluxurilor de date pentru sistem
Nr.
crt.
1.
Entitatea extern
Intrri de la entitatea
extern n sistem
Sistemul de eviden
contabil
Ieiri din sistem ctre entitatea

extern
Foaia de drum i factura de intrare
nregistrat;
Rapoarte statistice i informaii de

diferite tipuri (expirri, deteriorri
vaccinuri)
Factura de ieire nregistrat
2.
Secia achiziii publice
Informaii referitoare la
noi intrri de produse
Informaii referitoare la iepuizarea

de stocuri
3.
Donatorul
Foaia de drum i factura
Foaia de drum semnat i cu

nscrierile necesare
4.
Instituia medical
Lista vaccinurilor
solicitate
Factura de ieire, nregistart

preventiv la secia contabilitate
3) Studierea sistemului informaional. Identificarea proceselor de prelucrare. Exemplu pentru

identificarea proceselor de prelucrare, specifice activitilor sistemului pentru eviden a
vaccinurilor, analiza intrrilor, analiza ieirilor:
Tabelul 2. Prezentarea proceselor, a intrrilor i a ieirilor de date pentru fiecare proces de

prelucrare
Proces
1.Recepionarea
informaiei
despre noi intrri
Descrierea succint a
Intrri n
operaiunilor de prelucrare
proces
1. nregistrarea unei noi intrri

2. Pstrarea informaiei n dosarul de
Informaie intrare
Informaia
nou
nregistrat i
intrare;
2. Recepionarea/descrcarea i
verificarea integritii ambalajului
(cutii, lzi etc.) vaccinurilor;
3. Semnarea documentului de insoire
Formulele sau
relaiile de calcul
semnat
eviden a depozitului
1. Prezentarea documentului de
Ieiri din proces
Factur de intrare
Factur de intrare i
i foaia de
foaia de drum
drum/parcurs
completat cu dou
(Documentaia
atribute noi
standard care
(data/ora) i
nsoete
observaii (n 3
vaccinurile)
exemplare)
1.Valoarea=cantitate
a*pret unitar
(foaia de drum i factura),

nregistrarea datei, orei efecturii
2.nregistrarea
recepionrii
2.Suma=valoarea+T
livrrii i nscrierea observaiilor
VA+ Accize
(dac sunt);
vaccinurilor
4. Returnarea facturii i a foii de drum
3.Suma total=suma
semnate;
sumelor
5. Verificarea prezenei standardelor

corespunztoare vaccinului;
6. nregistrarea facturii n baza creia
s-a fcut recepionarea i
transmiterea vaccinurilor pentru
pstrare.
3.Asigurarea
pstrrii
vaccinurilor n
condiiile impuse
1. Verificarea vaccinurilor: dac
Factur de intrare
1.Lista deteriorrilor
corespund codurile de bare, cantitile
i foaia de
i neajunsurilor
specificate n factur;
drum/parcurs
2. nregistrarea vaccinurilor n
registrul de eviden conform facturii;
nregistrat
(Documentaia
standard care
3. nregistrarea numrului de
nsoete
deteriorri i neajunsuri;
vaccinurile)
2.Factura este
transmis seciei de
eviden contabil
pentru nregistrare i
pstrare
4. nregistrarea locului/zonei de
pstrare a vaccinurilor cu respectarea
condiiilor necesare de pstrare.
4.Evidena
calitii
vaccinurilor
1. Verificarea periodic a strii
Date deteriorri
Raport deteriorri
1.Valoare
vaccinurilor i nregistrarea
sau expirri
sau/i expirri
pierderi=cantitate
noncalitilor i a expirrii vaccinurilor;
nregistrate de
vaccinuri
rebut*pret unitar
2. nregistrarea i raportarea, n cazul

n care se nregistreaz, a expirrilor
sau deteriorrilor vaccinurilor (acestea
urmeaz a fi distruse);
operatorul
depozitului n
urma verificrii
2.Suma
strii vaccinurilor
pierderi=suma
valorilor pierderilor
3. Transmiterea spre distrugere a
vaccinurilor ce nu satifac anumite

cerine, cu documentarea acestui fapt.
1. Recepionarea solicitrilor;
5.Recepionarea
listelor de
2. Formarea livrrii vaccinurilor
Lista vaccinurilor
Factura de ieire i
1.Valoarea=cantitate
solicitate
foaia de drum sau
a*pret unitar
foaia de parcurs
solicitanilor;
solicitri i
3. Generarea documentului de ieire
2.Suma=valoarea+T
controlul formrii
corespunztoare livrrii;
VA+ Accize
livrrilor pentru
solicitani
4. nregistrarea divergenelor dintre

solicitare i livrare (daca exist).
3.Suma total=suma
sumelor
1. nregistrarea ieirii cu anexarea
Factura de ieire
Factura de ieire i
instructajului de pstrare i folosire a
i foaia de drum
foaia de drum
6.Evidena
medicamentelor; pachetul de
nesemnata (n 3
semnata (n 3
eliberrii
documente standard;
exemplare)
exemplare)
partidelor
2. Transmiterea unui exemplar al
Date referitoare
Informaie iepuizare
la inventariere
stocuri
facturii de ieire solicitantului i unul

seciei de aviden contabil.
7.Inventarierea
stocurilor de
vaccinuri i
1. Inventarierea stocurilor din depozit;

2. Stabilirea necesarului de vaccinuri;
generaea noilor
3. Generarea documentului cu
solicitri
solicitri, n cazul iepuizrii stocului.
donatorilor

1. Identificai i descriei procesele de activitate specifice seciei de producere a crenvutelor.
Evideniai intrrile i ieirile de date/informaii corespunztoare fiecrui proces.
2. Sistemul informaional de eviden a vnzrilor conine urmtoarele procese de activitate:
Recepionarea i analiza comenzilor, Recepionarea i distribuirea produciei (conform
comenzilor),
Facturarea
comenzilor,
Evidena
transportrii
produciei
clienilor.
Datele
referitoare la producia distribuit clienilor se nregistreaz i pstreaz n sistem, n locul de

stocare Date comenzi. Drept entiti externe vor fi Secia de eviden a comenzilor, Secia
producere, Secia contabilitate, Client. Descriei procesele de prelucrare detaliat.

Tema: Modelarea grafic a sistemului informaional al organizaiei/
subdiviziunii
Obiective urmrite:
Evidenierea grafic corect a surselor de date pentru sistemul informaional, a locurilor i

modalitilor de prelucrare a datelor, a locurilor de stocare a datelor;
Descrierea algoritmilor de obinere a informaiilor, n baza datelor disponibile, destinaia

informaiilor generate de sistemul informaional;
Prezentarea grafic a circulaiei datelor n sistemul informaional i pentru obinerea

informaiilor;
Utilizarea corect a sistemelor de notaii recomandate la poiectarea grafic a sistemelor

informaionale;
Utilizarea corect a mediilor soft pentru construirea modelelor sistemelor informaionale;
Analiza i interpretarea modelelor construite. Corectarea i adaptarea, la necesitate, ale

acestor modele.
Cerine:
1. Modelarea grafic a sistemului informaional supus analizei, folosind diagramele
fluxurilor de date.
a) Construirea diagramei de context pentru sistemul informaional;
b) Detalierea diagramei de context i evidenierea principalelor componente ale sistemului
informaional;
c) Construirea diagramei fluxurilor de date logice (cu evidenierea funciilor) sau/i fizice (cu
evidenierea entitilor interne) pentru sistemul informaional analizat.
2. Evidenierea noiunilor domeniului analizat. Construirea modelului conceptual al
datelor.

Informaiile pot fi reprezentate prin fluxuri de date, care sunt necesare pentru funcionarea
proceselor. Documentele sunt generate n cadrul proceselor i se mai spune c documentele parcurg
fluxul de date. Oamenii sunt direct implicai ntr-un flux de prelucrare a datelor: creaz
documentele necesare, le analizeaz, iau decizii, controleaz prelucrarea datelor etc.
10
n baza informaiilor sistematizate i descrise anterior (n lucrarea de laborator 3) se va

construi ierarhia de diagrame a fluxurilor de date, respectnd principiul descompunerii problemei n
subprobleme. Astfel, se va construi o diagram de context, o diagram de nivel 0, care prezint
principalele componente (subsisteme) ale sistemului informaional analizat i detalierea fiecrei
componete a sistemului informaional prin construirea diagramelor fluxurilor de date logice i/sau
fizice.
Sintaxa diagramelor fluxurilor de date (DFD) [1, 2, 3]:
Tabelul 3. Notaii grafice specifice DFD
Simbol
Notaia Yourdon-DeMarco
Semnificaie
Notaia GaneSarson
- se folosete pentru a reprezenta grafic un
proces care transform un flux de intrare ntrun flux de ieire. Deasemenea, se folosete
pentru
prezenta
subsistemul.
grafic
Etichetele
sistemul
din
sau
interiorul
simbolului sunt diferite pentru cazul cnd este

prezentat
sistemul
(exemplu:
sistem
de
eviden a comenzilor) sau procesul (exemplu:

recepionarea i nregistrarea comenzilor).
- se folosete pentru a prezenta grafic un loc
de stocare a datelor (datele se pstreaz pn
la o utilizare ulterioar). Eticheta din interiorul
simbolului trebuie s reflecte ct mai exact
coninutul datelor care se ptreaz n acest loc
de stocare.
-
flux
de
date
datelor/informaiilor
reflect
ntre
transferul
diverse
entiti.
Eticheta de pe fluxul de date poate s reflecte

o denumire a unui flux logic de date, dar i un
flux fizic de date.
- simbol utilizat pentru a prezenta entitatea
extern, care reprezint obiecte amplasate
nafara hotarelor sistemului. Entitatea extern
reprezint
sursa
datelor
sau
destinaia
informaiilor sistemului. Drept etichet se va

folosi un substantiv la singular, chiar dac
acele
obiecte-externe
(exemplu:
casier,
chiar
sunt
dac
mai
multe
casieri
nregistreaz vnzrile de produse dintrun

magazin).
11
Astfel, se construiete modelul funcional al sistemului informaional, model specific etapei de

analiz.
Tot la aceast etap se construiete modelul conceptual al datelor (care prezint grafic
noiunile/entitile domeniului - o descriere concis a datelor utilizatorului, incluznd descrierea
detaliat a tipurilor de date, a relaiilor i restriciilor acestora). Modelul conceptual al datelor are la
baz stabilirea corect a entitilor de date, a atributelor acestora i a relaiilor dintre entiti.
Acest model este bazat pe sintaxa diagramei entitate-relaie (DER), studiat detaliat n cadrul
disciplinei Baze de date.

1) Exemplu de diagram de context (se va exemplifica pentru subsistemul de depozitare a
vaccinurilor, dintr-o instituie medical, descris n laboratorul nr.3). Diagrama de context are
topoligie de tip stea, n centru fiind prezentat sistemul, iar n jur entitile externe i fluxurile
informaionale care ies i intr din/n sistem.
Secia achiziii
publice
Informaii referitoare
la noi intrri
Sistem de
eviden
contabila
Informaii referitoare la
iepuizarea de stocuri si
necesitatea de noi procurari
Foaia de drum semnat i
cu nscrierile necesare
Factura de iesire
Factura de intrare inregistrata;
Rapoarte statistice i informaii
(expirri, deteriorri vaccinuri)
SISTEM DE
EVIDEN A
VACCINURILOR
Factura de ieire,
nregistart
Donator
Foaia de drum cu factura de
intrare nregistrat
Lista vaccinurilor
solicitate
Instituie
medical
Fig. 6. Exemplu de diagram de context

2. Exemplu de diagram a fluxurilor de date care detaliaz procesul de eviden a vnzrilor de
medicamente (Fig. 7).
12
Date medicamente intrate
Manager aprovizionare
Date stocuri disponibile
Date stocuri
medicamente
3. Formarea stocurilor de produse
Date necesare
inregistrarii noilor stocuri
Loc de stocare
comun a datelor
referitoare la
medicamente
Cerere situatie stocuri
5.
Raportare
situatie
vanzari
4. Predarea
medicamentelor din
depozit
Cerere date
Date pentru raport
Detalii aprovizionare cu medicamente

Date medicamente
Date vanzari
1. Inregistrarea
comenzii de
medicamente
Date vanzare
Informatii
Cerere
situatie conturi raport
Detalii pentru informare

Cerere date
Date
medicamente
Contabilitate
Date comanda
2. Informarea
clientului
Date pentru
crearea vanzarii
Farmacist
Informatii
medicament
Fig. 7. Exemplu de DFD detaliat

1. Prezentai grafic, folosind DFD, urmtoarea descriere: sistemul informaional pentru gestiunea
produciei ntreprinderii primete:
a. informaiile referitoare la materia prim primit, de la secia achiziii;
b. informaiile referitoare la comenzile de producie de la secia evidena comenzilor.
Ca rezultat al realizrii produciei, producia, mpreun cu informaiile referitoare la tipul,
cantitile de produse etc. se transmit seciei vnzare i expediere. Ce tip de DFD ai
realizat?
2. Sistemul informaional de eviden a vnzrilor conine urmtoarele procese de activitate:
Recepionarea i analiza comenzilor, Recepionarea i distribuirea produciei (conform
comenzilor),
Facturarea
comenzilor,
Evidena
transportrii
produciei
clienilor.
Datele
referitoare la producia distribuit clienilor se nregistreaz i pstreaz n sistem, n locul de

stocare Date comenzi. Drept entiti externe vor fi Secia de eviden a comenzilor, Secia
producere, Secia contabilitate, Client. Construii diagrama fluxurilor de date, adugnd
fluxurile de date corespunztoare, care se transmit ntre procese, locul de stocare i entitile
externe.
3. Construii diagrama fluxurilor de date care va prezenta grafic circuitul urmtoarelor fluxuri de
date: clientul transmite date referitoare la comenzile solicitate departamentului de eviden a
comenzilor ale unui depozit en-gros. Acest departament nregistreaz comenzile i consult
departamentul aprovizionare cu produse. n cazul n care acetia dispun de produsele
13
solicitate, departamentul de eviden le transmite informaia despre produsele solicitate de

client i departamentul de aprovizionare creaz comanda i o pregtete pentru livrare
clientului, preventiv nregistrnd datele despre livrare, ntr-un loc de stocare a datelor.
Informaia, care conine detaliile referitoare la livrare (factura) se transmite clientului.
Evideniai:
entitatea extern sistemului informaional
procesele de prelucrare a datelor din sistemul informaional
fluxurile informaionale
locurile de pstrare a datelor.
4. Construii ierarhia de diagrame ale fluxurilor de date pentru examinarea cunotinelor

studenilor la o disciplin. n acest proces sunt implicate trei entiti: profesor, student i
decanat. Drept subprocese pot fi evideniate: generarea testelor de evaluare, repartizarea
testelor i rezolvarea acestora, colectarea i evaluarea rspunsurilor, nregistrarea notelor (n
matricol i borderou). Mapa cu teste, iniial fr raspunsuri, iar apoi cu rspunsuri i
evaluarea, va servi drept loc de stocare a datelor. Informaia referitoare la reuita studenilor
(borderoul completat) se va transmite decanatului.
5. Aceeai problem abordat la alt nivel: modelai activitatea sistemului informaional
Evidena/evaluarea reuitei studenilor. Pot fi evideniate procesele: 1. Evidena datelor
personale a studenilor nmatriculai, 2. Colectare i prelucrare date reuit, 3. Generare
informaii reuit la nivelul facultii, 4. Stocarea/pstrarea datelor. Procesul de eviden a
datelor personale poate conine subprocesele de: 1.1. nregistrare/Modificare date student;
1.2. Generare liste studeni ce satisfac anumite criterii (careva grupe, careva specialitate, de o
careva vrst etc.). Procesul de colectare i prelucrare a datelor se descompune n alte
subprocese: 2.1. nregistrare/Modificare date reuit la nivel de facultate; 2.2. Generare liste
studeni n baza criteriilor (note pozitive, note negative, dup grupe etc.); 2.3. Pstrarea i
transmiterea informaiilor. Vor fi evideniate dou entiti externe profesor va nregistra
datele referitoare la reuita studenilor i secvretariat decanat care va primi raportul final
referitor la reuita studenilor pe ntreaga facultate, iar n baza raportului va emite ordine,
decizii etc.
14

Tema: Argumentarea necesitii modernizrii sistemului
informaional existent, prin implementarea sistemului informatic
Obiective urmrite:
Contientizarea necesitii modernizrii i mbuntirii aiunilor proceselor de activitate din
sistemele informaionale sau sistemele informatice deja exploatate;
Evidenierea corect a viitorilor utilizatori ai sistemului informatic;
Gsirea i descrierea corect a problemelor care vor fi soluionate odat cu implementarea
sistemului informatic.
Cerine:
1. Motivarea necesitii realizrii i implementrii sistemului informatic.
2. Destinaia sistemului informatic, descris conform urmtorului model (Tabelul 4):
Tabelul 4. Structura recomandat pentru descrierea necesitii SI
Denumirea sistemului informatic

Destinaia (pentru ce este necesar)
Utilizatorii SI
Ce probleme vor fi soluionate la implementarea SI

De cele mai multe ori motivaia implementrii unui sistem informatic nou sau modernizarea
unui sistem informatic existent, reiese din necesitatea transformrii sistemului informaional al
organizaiei. La un moment dat aceast necesitate ajunge o prioritate pentru conducerea organizaiei,
deoarece:
n interiorul organizaiei informaia nu circul: suficient de repede sau este transmis neclar
sau nu ajunge n toate punctele necesare (ctre tot personalul implicat n fluxul informaional
respectiv).
Rspunsul organizatiei spre partenerii externi este: lent sau imprecis sau nesatisfctor (nu
exist proceduri implementate pentru toate situaiile sau procedurile nu sunt aplicabile din
lipsa informatiilor in timp real).
Urmrirea activitii se realizeaz anevoios; rapoartele de activitate ale angajatilor ctre
superiori ajung cu ntrziere i nu se pot lua decizii n timp real pe baza lor.
15
n lipsa informaiilor complete i corelate, n timp real, conducerea obine cu greu rapoarte de
sintez i de evoluie ale activitii organizaiei.
Pentru a crea premisele unai implementri reusite, n procesul de analiza trebuie nu numai s
fie indentificat starea actuala a organizatiei beneficiare, dar i s se dea raspunsuri i soluii fezabile
la probleme asemntoare celor enunate mai sus.
n funcie de modul n care se exploateaz sistemul informatic, utilizatorii pot fi mprii n
urmtoarele clase:
Utilizatorii obinuii, care pot s obin informaiile dorite fr s aib cunotine de programare,
prin comenzi cunoscute i eventual rspunznd la diferitele opiuni pe care le indic sistemul la un
moment dat (Ex.: secretar, manager, casier, director, contabil etc.).
Administratorul de sistem, care acord utilizatorilor drepturi de acces la baza de date sau la
pri ale ei, stabilete condiiile pentru asigurarea securitii i integritii datelor, modific structura
bazei de date, atunci cnd este nevoie, asigur ntreinerea sistemului informatic, fcnd periodic
copii i reconstruind baza de date n cazul n care au aprut erori datorate componentelor soft, hard
sau utilizrii i rspunde, n general, de modul de utilizare al sistemului informatic.
16

Tema: Formularea i specificarea cerinelor fa de SI
Obiective urmrite:
Cunoaterea coninutului i structurii Sarcinii tehnice (Caietului de sarcini) pentru un

sistem informatic;
Delimitarea cerinelor dup tipul lor;
Evidenierea i formularea clar a cerinelor fa de un sistem informatic;
Ierarhizarea cerinelor conform prioritilor.
Cerine:
1. Specificarea cerinelor funcionale i nonfuncionale fa de sistemul informatic care
urmeaz s fie implementat n sistemul informaional.
a) Specificarea cerinelor conform urmtoarei structuri (Tabelul 5):
Tabelul 5. Structura recomandat pentru descrierea cerinelor fa de SI
Nr. cerinei
Definirea cerinei
Descriere succint
(numrul ce
(Cerina se formuleaz ct
(Cerina se descrie n form liber,
(nalt/medie/joas
identific n mod
mai scurt posibil)
sub form de text)
Reflect importana cerinei. Se
unic cerina)
Prioritatea
folosete pentru definirea ordinii

de realizare a acesteia)
b) Separarea cerinelor dup tip:

-
Lista cerinelor funcionale vor fi formulate innd cont de prioritate (n ordine

descresctoare) i se va specifica utilizatorul (actorul) SI (cine i n ce cazuri va folosi SI);
Lista cerinelor nefuncionale: se va ine cont de cerinele fa de flexibilitate, calitate,

securitate, usurinta n utilizare i accesibilitate, standarde, i constrngerile tehnologice
etc.

Analiznd descrierea sistemului informaional expus se poate recurge la formularea cerinelor
fa de sistemul informatic, care urmeaz s fie dezvoltat i implementat n sistemul informaional
cercetat. Cerinele sunt servicii pe care le dorete clientul de la SI, constrngerile de operare i
dezvoltare a acestuia. O cerin poate fi formulat foarte abstract sau poate reprezenta o specificaie
matematic detaliat.
17
Cerinele naintate unui SI, pot fi clasificate n cerine funcionale i nefuncionale [6]:
Cerinele funcionale reprezint enumrarea serviciilor pe care ar trebui s le ofere SI diferitor

tipuri de utilizatori. Altfel spus, aceste cerine descriu comportamentul SI i operaiile/funciile
ndeplinite de acesta. Deasemenea ar trebui s se specifice cum sistemul va reaciona la
introducerea anumitor tipuri de date sau cum se va comporta (va rspunde) n diferite situaii,
extreme de exploatare. n unele cazuri se poate specifica ce nu ar trebui s fac sistemul.
Cerinele nefuncionale descriu caracteristicile SI i ale mediului acestuia, dar nici ntrun caz
comportamentul acestuia. Pot fi menionate restricii referitoare la activitatea SI i la funciile
ndeplinite de acesta. Acest tip de cerine cuprind restricii asupra duratelor, restricii
referitoare la procesul dezvoltrii SI, standarde etc. Deasemenea aici mai pot fi adugate
cerine referitoare la domeniul studiat i unde va fi implementat SI. n lista cerinelor
nefuncionale pot fi incluse cerine fa de securitate, componentele hard, etapa de
implementare, pstrarea datelor, viteza de acces la date, fiabilitatea SI, documentaia SI etc.
(vezi:
Structura
sarcinii
tehnice,
http://lex.justice.md/viewdoc.php?action=view&view=doc&id=316454&lang=1).
OBS: Conform The guide to the Business Analysis Body of Knowledge elaborat de International
Institute of Business Analysis cerinele pot fi divizate n: cerine funcionale, cerine nefuncionale i
cerine fa de implementare.
n unele cazuri este dificil delimitarea celor dou tipuri de cerine (de exemplu clientul cere ca
sistemul s fie sigur i atunci aceste cerine pot fi incluse n lista cerinelor de siguran cerine
nefuncionale sau dac acestea se specific mai detaliat la cerine funcionale deoarece ele vor
conduce la implementarea n SI a funciilor responsabile de autentificare i autorizare a aciunilor
utilizatorului). n aceste cazuri se recomand utilizarea standardelor i reglementrilor tehnice
specifice domeniului.
Cerinele se formuleaz ct mai clar
posibil, deoarece de cele mai multe ori stau la baza
organizrii unei licitaii sau a unui tender (adic trebuie s fie uor de neles i interpretat) sau pot
sta la baza ncheierii unui contract de dezvoltare a unui SI (n acest caz ele trebuie definite ct mai
detaliat). Deasemenea cerinele sunt necesare pentru a verifica dup etapa de elaborare (testare)
dac sunt sau nu ndeplinite.

1) Exemplu de cerine funcionale:
a. Casierul trebuie s poat cuta n BD a SI detalii referitoare la un careva produs;
b. SI trebuie s ofere posibilitatea casierului de a vizualiza comod detaliile produselor;
c. SI trebuie s-i permit operatorului de la depozit nregistrarea intrrilor tuturor
vaccinurilor;
d. SI trebuie s-i permit operatorului depozitului nregistarea vaccinurilor deteriorate
(sau nregistrarea vaccinurilor care vor fi transmise pentru distrugere).
2) Exemplu de cerine nefuncionale:
18
a. Cerine fa de confidenialitate (securitate): Sistemul nu trebuie s ofere/afieze alte

date, referitoare la client, dect numele i prenumele acestuia;
b. Cerin fa de documentaia utilizat: Procesul de dezvoltare i setul de documente
vor fi realizate n baza RT 38370656-002:2006;
c. Cerine fa de interfaa-utilizator:
i. Etichetele prezente n formularele aplicaieie, trebuie s fie aliniate pe stnga,
pentru o uoar citire a datelor prezentate.
ii. Sistemul trebuie s ofere consisten pentru toate ecranele i caracteristici
comune specifice tuturor componentelor SI.
iii. Design-ul aplicaiei trebuie s includ link-uri nainte i napoi ntre
pagini/formulare. Trebuie s existe o pagina/un formular iniial, care ar realiza
legtura dintre toate celelalte pagini/formulare.
d. Cerin fa de comoditatea folosirii:
iv. Textul din formularul utilizat pentru nregistrarea vnzrilor trebuie s se
citeasc de la distana de 1m.
v. n meniul principal al aplicaiei destinate managerului de depozit, trebuie s fie
opiunea Raport, n care s fie accesibile opiunile Vizualizare i Tipar;
e. Cerin fa de operabilitate: Introducerile de date, n cmpuri, vor fi verificate (dac
aceasta este posibil: vrsta cuprins ntre 0-120 ani etc.) la ieirea din elementul de
control. Dac introducerea de date este necesar s fie verificat n totalitate (exist
cmpuri dependente) aceast se va face la prsirea ecranului sau formularului.

1. Formulai cerine funcionale i nefuncionale fa de o aplicaie web necesar pentru preluarea
comenzilor on-line de la potenialii clieni ai unui magazin de calculatoare.
2. Evideniai cerinele funcionale i nefuncionale care ar putea fi formulate fa de de sistemul
informatic Bancomat.
3. Formulai cerine funcionale i nefuncionale fa de un sistem informatic care trebuie dezvoltat n
cadul unui magazin alimentar, pentru evidena vnzrilor acestui magazin. Evideniai funciile
pentru componenta de la nivel operaional (de nregistrare a vnzrilor), pentru componenta de
management (analiza vnzrilor) i componenta de administrare a sistemului informatic.
19

Tema: Proiectarea arhitecturii fizice i logice a sistemului
informatic
Obiective urmrite:
S interpreteze corect cerinele formulate n lucrarea de laborator anterioar;
S analizeze tehnologiile disponibile pentru dezvoltarea aplicaiilor sistemului informatic;
S propun soluii corecte pentru arhitectura SI: arhitectura componentei hardware i a celei
software care este structura, organizarea i interaciunea componentelor (entitilor mari)
SI.
Cerine:
1. Soluia pentru SI.
a) Nivelul implementrii SI (la nivel de loc de lucru, funcie, birou, departament etc.), numrul
i tipul utilizatorilor;
b) Tipul SI: sistemul va fi implementat la un PC sau ntr-o reea de calculatoare (topologia,
tipul, numrul PC-urilor i serverelor), va cuprinde unul/mai multe procese ale unei
ntreprinderi sau unul/mai multe procese din cteva ntreprinderi etc., nivelele, conform
organigramei la care va fi implementat SI;
c) Descrierea componentelor tehnice necesare elaborrii SI;
d) Descrierea produselor soft necesare dezvoltrii componentei soft a SI (SO, SGBD, limbaje
de programare, tehnologii etc.).
Soluia poate fi descris utiliznd urmtoarea matrice (numit matrice-candidat. Candidatul se
refer la o careva component funcional, care are rol de informare, din cadrul organizaiei
analizate) (Tabelul 6):
Tabelul 6. Structur recomandat pentru descrierea soluiei SI
Caracteristici
Componentcandidat 1
Componentcandidat 2
Componentcandidat 3
Component a sistemului informatic

O scurt descriere a acelei pri a sistemului
informaional care urmeaz a fi informatizat n
Candidatul menionat
Beneficii
O scurt descriere a beneficiilor pe care le-ar avea
organizaia, prin automatizarea proceselor de activitate
din candidatul menionat
Servere i staii de lucru

O descriere a componentelor de reea necesare:
20
servere i staii lucru - pentru a fi posibil

informatizarea componetei propuse
Instrumente software necesare

Instrumente software necesare pentru a proiecta i
construi componenta-candidat (de exemplu: sistemul
de gestiune al bazelor de date, sisteme de operare,
limbaje de modelare i de programare etc). Aceast
caracteristic, n general, nu se aplic n cazul n care pachete
de aplicaii software trebuie s fie achiziionate (i nu
dezvoltate de echipa de dezvoltare)
Aplicaii software
O descriere a software-ului care urmeaz s fie
achiziionat, construit, accesat sau o combinaie a
acestor tehnici (achiziionat i adaptat, accesat i
reconstruit etc.)
Metode de prelucrare a datelor

Metodele implementate n procesele de prelucrare a
datelor vor fi automate, parial automate sau mixte
Dispozitive de ieire i ce ieiri implic

aceste dispozitive
O descriere a dispozitivelor de ieire, care ar putea fi
utilizate, cerine speciale pentru ieiri (de exemplu:
reea, formulare pretiprite etc) i cerine care ar putea
fi impuse la generarea ieirilor (de exemplu,
constrngeri de timp)
Dispozitive de intrare i tipurile de intrri pe

care le implic aceste dispozitive
O descriere a metodelor care ar putea fi utilizate la
intrare, a dispozitivelor de intrare (de exemplu:
tastatura, mouse-ul, scaner-ul etc), cerine speciale
care ar trebui respectate la intrarea datelor (de
exemplu: formulare noi sau revizuite din care ar putea
fi preluate datele de intrare, frecvena de intrare a
datelor etc.)
Dispozitive de stocare i ce implic acestea

O scurt descriere a faptului cum datele vor fi stocate,
cum datele vor fi accesate din locurile de stocare, ce
suporturi de stocare ar putea fi folosite, care ar putea fi
capacitatea de stocare necesar i modul n care vor fi
organizate datele
2. Proiectarea arhitecturii SI.

a) Evidenierea principalelor componente ale SI;
b) Prezentarea grafic a arhitecturii hardware-lui (topologia fizic) i software-lui SI.

Arhitectura unui sistem informatic se refer la hardware-ul i software-ul folosit pentru a
furniza produsul la consumatorul final de servicii. Arhitectura este o descriere a modelului i a
coninutului unui sistem informatic.
21
Dac cerinele exprim ceea ce va trebui s fac SI, atunci proiectarea trebuie s descrie cum
va face SI lucrurile specificate n cerine.
Sistemele
informatice
sunt
structurate
pe
subsisteme
(vizeaz
careva
funcie
organizaiei), aplicaii (vizeaz activiti), uniti funcionale (au la baz proceduri de prelucrare
logice, pentru care se pot scrie coduri de program).
Unitile funcionale pot fi:
Automate
Semiautomate (se pregtesc, apoi se finalizeaz prin prelucrri automate)
Manuale (pregtesc prelucrrile automate)
Orice component a SI presupune intrri, prelucrri i ieiri, iar relaiile dintre componente se
realizeaz prin intermediul unei baze informaionale, care exist i n sistemul informaional, dar n
condiiile informatizrii, va fi reflectat n colecii omogene de date ce pot fi organizate n baze de
date sau fiiere.
Exemplu: Sistem/subsistem informatic pentru Sistemul contabil al ntreprinderii: aplicatie
calcularea salariului, o alta aplicaie n acest subsistem evidena mijloacelor fixe i ale resurelor
materiale, evidena contractelor ncheiate...; unitate funcional calcularea salariului brut sau net
pentru angajai (salariul net=salariul brut impozite fondul social asigurarea medical alte
reineri). Aceste calcule pot fi algoritmizate.
Modelele elaborate la etapa de analiz sunt studiate pentru a fi posibil prezentarea
arhitecturii SI (hard i soft), a funciilor, a structurii datelor, a interfeelor de dialog. Grafic arhitectura
se prezint astfel:
Sistemul
informatic
(produsul
final)
Hardware
Software
Functii
Date
Comportament
Fig. 8. Componentele sistemului informatic, grafic

Modelele care se construiesc n cadrul etapei de proiectare sunt dependente de platforma
tehnic pe care va fi implement sistemul soft. Arhitectura hardware (diagrama) se va construi n baza
cunotinelor obinute la disciplina Reele de calculatoare. Deasemenea se va realiza i prezenta
repartizarea componentelor sistemului soft la componentele fizice ale SI, adic care element de calcul
- ce subsistem va gzdui.
22

1. Exemplu de diagram pentru arhitectura SI ntr-o ntreprindere care comercializeaz nclminte:
componentele principale.
Manager dezvoltare vanzari
Contabil
Asistent
App pentru gestiunea clientilor si comenzilor
vanzator
App pentru evidenta
App pentru evidenta fluxurilor
vanzarilor
financiare
Serverul central
cu date
App pentru gestiunea datelor

angajati
App pentru evidenta

stocurilor
de marfuri
Administrator
depozit
App pentru vizualizarea informatiilor

Manager
resurse umane
Director
Fig. 9. Exemplu de diagram de arhitectur

1. Construii diagrama care reflect arhitectura componentelor hard i soft pentru urmtoarea
descriere: Sistemul informatic va fi implementat pe o reea de 3 calculatoare. Topologia reelei va fi
de tip stea, n centru fiind amplasat serverul pe care este amplasat baza de date a SI. Pe un
calculator va fi instalat aplicaia care va fi utilizat de casier pentru nregistrarea vnzrilor, pe cel
de-al doilea calculator va fi instalat aplicaia care va fi utilizat de administrator pentru nregistrarea
datelor referitoare la produsele magazinului, propuse spre vnzare, iar pe cel de-al treilea calculator
va fi instalat aplicaia care va fi utilizat de managerul responsabil de vnzri pentru generarea
rapoartelor, n scopul lurii deciziilor.
2. Construii diagrama care reflect arhitectura componentelor hard i soft al unui SI care va fi
implementat n cadrul contabilitii. Modulul Evidena salarizrii personalului va fi instalat pe
calculatorul contabilului responsabil de salariu, modulul Evidena resurselor ntreprinderii va sta pe
calculatorul contabilului responsabil de resursele ntreprinderii (materiale, tehnice etc.), modulul
Evidena tranzaciilor va fi instalat pe calculatorul contabilului responsabil de evidena tuturor
23
tranzaciilor ncheiate de ntreprindere, iar modulul Monitorizare i raportare va fi instalat pe

calculatorul contabilului-ef. BD a SI va fi implementat pe server, care va avea conexiune cu toate
cele 4 calculatoare.
24

Tema: Proiectarea sistemului informatic
Obiective urmrite:
S efectueze specificarea corect a cerinelor funcionale fa de SI, innd cont de

componentele SI;
S cunoasc notaiile grafice care pot fi utilizate pentru specificarea cerinelor n cadrul etapei
de proiectare a SI;
S identifice corect entitile externe pentru SI, procesele de prelucrare ale datelor din SI,
locurile de stocare a datelor, fluxurile de date analiznd sistemul informaional descris n
lucrrile de laborator anterioare;
S proiecteze interfee (ecrane, meniuri, formulare) care vor realiza dialogul corect dintre
utilizator i SI;
S proiecteze interefe care realizeaz legtura cu alte sisteme informatice i aplicaii.
Cerine:
Proiectarea grafic a SI:
a) Evidenierea principalelor entiti externe (utilizatori) a SI i a schimbului de date dintre
entitile externe i SI. Construirea diagramei de context a SI.
b)
Construirea
ierarhiei
de
diagrame
care
realizeaz
descompunerea
sistemului
soft
subcomponente, uniti funcionale pentru care uor pot fi descrise datele de intrare, algoritmul
de prelucrare a acestor date, fluxurile de ieire;
c) Modelarea comportamentului SI. Descrierea accesrilor SI (denumire tranzacie, nume tabel(e),
tipul accesului la date (citire, nscriere, rennoire), tipul utilizatorului). Descrierea scenariilor de
acces la datele SI (corespunztoare principalilor utilizatori ai SI);
d) Proiectarea formularelor pentru culegerea datelor, a interfeelor de dialog sistem-utilizator:
meniuri, submeniuri, formulare de selecie.
e) Proiectarea rapoartelor/informaiilor de ieire specifice SI, care conin att date dintr-un tabel,
ct i date grupate din mai multe tabele (se admit exemplificri cu inserarea cererilor de tip
select).
25

Pentru specificarea cerinelor i evidenierea grafic a funcionalitilor SI deasemenea pot fi
utilizate DFD (semantica a fost descris n laboratorul 2). i n acest caz poate fi construit o ierarhie
de diagrame: prima prezint contextul, iar diagramele urmtoare detaliaz diagrama construit la
anterior. La rafinarea unui careva nivel proiectantul realizeaz descompunerea funcional explicit i
rafinarea datelor. Modelele grafice (de obicei cele de nivel inferior) se recomand s fie completate cu
descriere textual. n acest scop:
Vor fi rafinate funciile pentru a fi posibil elaborarea codurilor de program;
Se va descrie modul de transformare al datelor de intrare n flux de ieire - algoritmul

de prelucrare al datelor. Se va descrie fiecare funcie i subfuncie, n mod narativ
(metod recomandat) sau folosind schemele logice.
Modelarea comportamentului soft-ului (din SI) reprezint o consecin a evenimentelor

parvenite din mediul SI, din exteriorul acestuia. Un careva utilizator (care are un rol n utilizarea SI)
acceseaz sistemul (de exemplu pentru introducerea datelor), sau altfel spus interacioneaz cu SI.
Pentru a modela comportamentul SI se vor identifica evenimentele externe care pot declana
modificarea comportamentului SI i se va descrie reacia (comportamentul) sistemului la aceste
evenimente.
Interfaa reprezint conexiunea care realizeaz legtura ntre dou sisteme sau componente.
Orice sistem necesit una sau mai multe interfee. Interfee pot fi de mai multe tipuri:
interfaa-utilizator - care include cel puin un utilizator uman, responsabil de accesarea
sistemului i rspunsurile sistemului la solicitrile utilizatorului;
interfaa pentru sau cu alte sisteme externe;
interfaa pentru sau cu dispozitive hardware externe ale sistemului.
Utilizatorul, alte sisteme sau periferice aflate n legtur cu sistemul cercetat sunt numite pri
cointeresate [10]. Identificarea interfeelor este necesar pentru a determina corect hotarele
sistemului informatic, serviciile care sunt oferite altor sisteme, care sunt datele de intrare i cele de
ieire.
Proiectarea interfeelor care realizeaz dialogul sistem-utilizator se reduce la crearea
prototipurilor imaginilor care vor aprea pe ecranul calculatorului, la diferite momente de exploatare a
SI. Se va urmri crearea unui mediu de comunicare eficient ntre utilizatorul uman i sistemul
informatic. Interfaa cu utilizatorul reprezint componenta esenial a percepiei valorii produsului
software de ctre utilizator. Pentru crearea prototipului interfeei-utilizator:
se va alege un set specific de principii de proiectare,
se vor identifica componentele (obiectele) de interfa i se va defini aezarea acestora pe

ecran,
se vor identifica aciunile posibile de a fi iniiate de pe interfa.

Interfaa destinat utilizatorului, de obicei se realizeaz iterativ crend preventiv o prim
versiune a prototipului, apoi va fi evaluat de ctre utilizatorul SI. In cazul n care aceasta necesit
26
mbuntiri i modificari, se va realiza urmtoarea versiune, procesul repetndu-se pn cnd se va

obine o versiune acceptat de utilizatorii SI.

1. Exemplu de diagram de context: bancomat (Fig. 10).
Date card, PIN,
detalii tranzactie
Date, informatii
deservire
SI Bancomat
Clent
Informatii tranzactie
Sistem de
evidenta bancar
Protocol deservire,
date validitare
tranzactie
Fig. 10. Exemplu de diagram de context

2. Exemplu de diagrama a fluxurilor de date care detaliaz diagrama de context:
-
sunt evideniate principalele procese ce activitate;
se respect etichetarea;
procesele 1, 2 face legtura cu tabelul carduri_clenti al BD;
procesele 3, 4 face legtura cu tabelul conturi_clieni (Fig. 11).

Detalii card
Clent
1.
Verificare
card
Date validitate
card
PIN
PIN incorect
2.
Verificare PIN
Card valabil
Suma tranzactie
3.
Validare suma
Nr.card
Situatie card
Sistem de
evidenta bancar
PIN
Corectitudine PIN
Confirmare
Protocol
reinnoire
deservire
protocol
5.
Reinnoire
protocol
deservire
client
Situatie cont
Date suma ceruta
Detalii validare tranzactie

Informatie
eliberare numerar
4.
Eliberare
numerar
Detalii tranzactie
Fig. 11. Exemplu de diagram a dluxurilor de date care prezint principale procese ale sistemului
3. Exemplu de diagram a fluxurilor de date care detaliaz activitatea unui proces (n baza procesului
Validare sum) (Fig. 12):
27
2.
Verificare PIN
Card valabil
Suma tranzactie
Clent
3.1.
Acceptare
suma
Sistem de
evidenta bancar
(conturi)
Detalii tranzactie
Suma
zilnica
depasita
Informatie
3.2.
Verificare
limita zilnica
Situatie suma zilnica

Date suma zilnica
Suma zilnica nedepasita
3.4.
Generare
notificare
Suma
insuficienta
3.3.
Verificare
situatie cont
Situatie suma cont

Date suma disponibila
Fig. 12. Exemplu de DFD de nivel 1, care detaliaz o component a unui sistem
4. Exemplu de formular de selecie (propus utilizatorului Operator depozit la lansarea aplicaiei)
(Fig. 13):
Fig. 13. Exemplu de formular

5. Exemplu de formular folosit pentru introducerea datelor de utilizatatorul Operator depozit:
Acest formular este format dintr-un formular de baz i un subformular, prin intermediul
cruia vor fi introduse detalii referitoare la livrrile de produse farmaceutice de la furnizor
ctre depozit. Deasemenea din acest formular este posibil vizualizarea, sub form de raport,
a tutoror datelor referitoare la intrarea curent.
Fig. 14. Exemplu de formular
28
Scenariul de lucru pentru formularul nregistrare Intrri:

a.
La deschiderea formularului principal (care se deschide la lansarea aplicaiei, ex.5), se

va alege din meniu opiunea Procesare date.
b.
Din lista de opiuni prezente (butoane) se va selecta butonul Intrri.
c.
La apariia formularului, acesta se completeaz cu date, conform structurii descrise

(nume furnizor, data intrare, numrul documentului de intarare, nume productor,
produs, unitate de msur, cantitate, pre per unitate. Cmpul corespunztor codului
furnizorului i codului productorului se vor autoincrementa (identific n mod unic
nregistrarea), n scopul nlturrii dublrii valorii cmpului. Cmpurile corespunztoare
nomenclatoarelor se vor completa prin alegerea opiunii necesare, care vor aprea sub
form de list. Cmpul cantitate se va completa manual de ctre operatorul
depozitului.
d.
Se navigheaz n formular n baza butoanelor speciale de navigare.
e.
Atunci cnd nu se mai dorete introducerea datelor se apas butonul nchide.
6. Exemplu de descriere raport Vizualizarea stocurilor depozitului la un moment dat de timp.

Acest raport a fost creat pentru:
verificarea disponibilitii produselor;
verificarea cantitilor produselor farmaceutice n depozit la o careva dat.
Utilizator: Operatorul depozitului.
Continut:
Se vor grupa produsele farmaceutice i vizualizate restul detaliilor referitoare la

produsele din depozit;
Se va calcula valoarea produselor disponibile n cadrul depozitului;
Vizualizarea stocurilor se face cu scopul rennoirii acestuia n caz de necesitate.
Raportul se va genera pentru ziua curent i produsele disponibile la moment. Raportul va

putea fi vizualizat prin afiarea la ecran sau prin tiprirea la imprimant (la alegere). Raportul
va fi generat ori de cte ori va fi necesar (la cerere).
Sursa datelor: se vor accesa tabelele produsFarmaceutic, Intrare, Ieire, pentru extragerea
datelor.
Prototipul raportului:
Produs
Furnizor
Producator
Data de
intrare
Cantitate
UM
Pre
Valoare
unitar
Total:
n forma principal, va fi posibil crearea acestui raport prin intermediul butonului:
Raport la
moment
29

1. Construii diagrama fluxurilor de date care modeleaz urmtoarele procese ale unui SI:
agentul bancar deschide contul unui client, preventiv dispunnd de datele personale ale clientului i
are acces la gestiunea depozitelor clientului. Cu acest proces mai este legat o entitate extern
alt banc. Clientul poate accesa verificare situaie cont (on-line), transferuri fonduri (tot prin
intermediul interfeei web) altor bnci sau persoane juridice i funcia retragere numerar, prin
intermediul ATM/POS. n BD a SI vor fi minim 3 tabele: cont, client i tranzacie. Suplimentar,
construii diagrama de context corespunztoare acestei descrieri i diagrama ER ce definete
structura tabelelor BD a SI.
2. Modelai subsistemul Eliberare asigurare folosind notaiile descrise anterior. Entiti
externe: client asigurat, specialist evaluator, BD conturi. Procese: nregistrarea reclamaiei (clientul
completeaz ancheta), revizuirea reclamaiei clientului, determinarea (calculul) rambursrii,
nregistrarea soluiei reclamaiei i generarea raportului (s-a achitat pentru reclamaie, ce sum,
cnd, cine a fost responsabil de gestiunea procesului etc.), analiza reclamaiei (de ctre client) i
pstrarea reclamaiei (n BD conturi). n subsistem se vor pstra date referitoare la evaluri.
ncercai, n mod similar s gsii procesele, entitile externe, fluxurile de date, locurile de stocare
pentru subsistemul Asigurarea clienilor i Evidena plilor poliei i s prezentai grafic modelul.
3. Schiai formularul care ar putea fi utilizat de operatorul care nregistreaz n SI de
eviden a colectrilor de lapte date referitoare la cantitile de lapte colectate de la locuitorii unei
careva localiti. Valorile cmpurilor referitoare la Localitatea, Numele, Prenumele vor fi selectate din
listele propuse (se vor introduce preventiv n BD). Formularul de baz trebuie s conin data
colectrii, localitatea, iar subformularul nume, prenume, cantitate. Trebuie s fie inclus un
cmp care s calculeze cantitate total colectat per localitate. Pe formular trebuie s fie accesibile
butoanele Salvare, Generare chitan, Ieire.
4. Schiai coninutul informaiei (n baza problemei 5 coninutul chitanei), care ar putea fi
generat i tiprit pentru gospodarul care a adus laptele i care primete plata pentru laptele adus
(cu presupunerea c nu se face estimarea procentului de grasime din lapte
- aceasta se face n
laboratorul fabricii de lactate, iar preul per litru este stabilit de fabric).
5. Descriei scenariul (paii) de accesare a aplicaiei n cazul cumprrii produselor prin
intermediul resurselor Internet. S se prevad cazul cnd cumprarea i achitarea ajunge cu bine la
sfrit i, deasemenea, s se descrie soluia pentru cazul (cazurile) cnd apar careva situaii
neprevzute pe parcusul efecturii cumprturii.
6. Modelai, folosind DFD, urmtoarea descriere: administratorul unui depozit cu produse
alimentare, dup ce a creat comanda clientului, genereaz factura pentru nregistrarea ieirii de
produse din depozit. eful de depozit lunar (i la necesitate) vizualizeaz (i tiprete) raportul
referitor la stocul de produse disponibil n depozit. Descriei pe pai aciunile celor doi utilizatori,
menionnd reaciile i aciunile SI.
30

Tema: Proiectarea structurii BD
Obiective urmrite:
S construiasc corect diagrama entitate-relaie (ER);
S se descrie structura tabelelor BD corespunztoare datelor SI.
Cerine:
1. Construirea modelului logic al datelor (dac va fi necesar se va normaliza BD). Diagrama entitaterelaie care definete structura BD specifice SI ce se proiecteaz;
2. Descrierea structurii fiecrui tabel din baza de date;
3. Validarea modelului datelor obinut.

Construirea diagramei entitate-relaie este important pentru o vizualizare ct mai clar a
ansamblului de entiti din baza de date. Pentru definirea structurii BD se va utiliza diagrama
entitate-relaie, iar paii realizai vor fi cei descrii n cadrul disciplinei Baze de date.

1. Exemplu de diagram Entitate-Relaie, care poate fi utilizat pentru implementarea bazei de
date Clientul comand produse BD care poate fi implementat ntr-un sistem informatic de
eviden a comenzilor de produse a clienilor:
Client
PK
ElementComanda
Comanda
nrClient
PK
nrComanda
numeClient
prenumeClient
adresa
FK1
dataComanda
nrClient
PK
PK,FK1
nrElemComanda
nrComanda
FK2
cantitateProdus
nrProdus
Produs
PK
nrProdus
descriereProdus
pretUnProdus
Fig. 15. Diagrama entitate-relaie pentru BD Comenzi produse de la clieni

(unde: PK cheie primar, FK cmp de legtur, multiplicitatea: unu
muli).
2. Exemplu de desriere a structurii tabelului Productor:
31
TABELUL productor (de tip NOMENCLATOR)
codProductor nu trebuie s depeasc 5 cifre;
numeProductor nu trebuie sa depaseasca 20 caractere; prima litera a atributului trebuie sa

fie scrisa cu majuscula, iar n continuare poate s urmeze litere mari sau mici;
adresa nu trebuie s depeasca 20 caractere; prima litera a atributului trebuie sa fie scris cu
majuscula, iar apoi pot urma diferite simboluri;
numarTelefon nu trebuie sa depaseasca 12 cifre.
32

Tema: Modelarea logicii/a algoritmilor de prelucrare a datelor
Obiective urmrite:
Cunoaterea metodelor de descriere a algoritmilor;
Elaborarea i descrierea logic corect a algoritmilor funciilor fiecrei aplicaii din sistemul
informatic;
Validarea corectitudinii algoritmilor elaborai.
Cerine:
1. Descrierea structurilor de date de intrare pentru fiecare funcionalitate menionat;
2. Descrierea algoritmilor de transformare a datelor de intrare n fluxuri de ieire: sortri, filtrri,
sumri, agregri, aplicarea diverselor formule de calcul. Pentru descrierea algoritmilor se vor
folosi schemele logice sau limbajul pseudocod;
3. Enumrarea tabelor BD care vor fi accesate i a operaiilor realizate (adaugare date, nscriere
date, tergere date, modificare date, extragere date etc.).

Algoritmii, dup cum a fost menionat, se recomand s fie descrii textual, n limbaj
pseudocod, nerespectnd sintaxa unui careva limbaj de programare. Algoritmul se descrie secvenial.
Orice programator trebuie s neleag aceast descriere pentru a codifica corect.
Prin algoritm se nelege o succesiune finit de operaii. Acesta presupune executarea unor
calcule ntr-o anumit ordine. Se mai poate considera c un algoritm este o secven finit de
propoziii ale unui limbaj de descriere a algoritmilor.
n descrierea algoritmilor se folosesc mai multe limbaje de descriere, dintre care cele mai des
folosite sunt:
- limbajul schemelor logice;
- limbajul Pseudocod.
Schema logic este un mijloc de descriere a algoritmilor prin reprezentare grafic. Regulile
de calcul ale algoritmului sunt descrise prin blocuri (figuri geometrice) reprezentnd operaiile (paii)
algoritmului, iar ordinea lor de aplicare (succesiunea operaiilor) este indicat prin sgei. Fiecrui tip
de operaie i este consacrat o figur geometric (un bloc tip) n interiorul creia se va nscrie
operaia din pasul respectiv.
33
Prin execuia unui algoritm descris printr-o schem logic se nelege efectuarea tuturor
operaiilor precizate prin blocurile schemei logice, n ordinea indicat de sgei.
Limbajul Pseudocod este un limbaj inventat n scopul proiectrii algoritmilor i este format
din propoziii asemntoare propoziiilor limbii romne, care corespund structurilor de calcul folosite
n construirea algoritmilor. Atunci cnd algoritmii sunt descrii n limbaj pseudocod se vor folosi
propoziii curente din limba romn. Fiecare propoziie a limbajului precizeaz o anumit regul de
calcul. Algoritmii care se vor descrie ar trebui s fie ct mai generali (s rezolve o clas de probleme
de acelai tip), s dea rezultate ntr-un anumit timp (finit, adic s se termine oricare ar fi datele de
intrare) i, de asemenea, s asigure unicitatea rezultatelor ori de cte ori se dau aceleai date de
intrare. Aceste trei caracteristici generalitate, finitudine i unicitate trebuie respectate ori de cte ori
este scris un algoritm, indiferent de forma (scheme logice sau limbaj Pseudocod) n care este
prezentat acesta.
Scanlan [11] a artat c studenii neleg mai bine algoritmii prezentai n flowcharturi (sau
scheme logice) dect pe cei prezentai n pseudocod-uri.
Algoritmii, se recomand s fie descrii grafic sau textual, n limbaj pseudocod, nerespectnd
sintaxa unui careva limbaj de programare. Algoritmul se descrie secvenial. Orice programator trebuie
s neleag aceast descriere pentru a codifica corect.

1. Exemplu de descriere a accesrilor tabelelor BD, pentru funcionalitatea Onorarea comenzii ctre
client (Vezi tabelul 7):
Tabelul 7. Descrierea accesrilor tabelelor BD
Tipul accesului
la date
Denumire operaiune
Denumire tabel
Explicaii
1. Creare document
nsoitor al comenzii
Ieire
Se creaz o
noua
nregistrare
(CREATE)
Atributul dataIeire ia valoarea

care coincide cu data nregistrat
de sistem, iar celelalte atribute
vor fi completate cu date ale
comenzii curente
2. Verificare
disponibilitate produs
farmaceutic i cantitate
produs
produsFarmaceu
tic
Citire date
(READ)
Se citete denumirea i cantitatea

produsului specificat, se verific
disponibilitatea acestuia i
cantitatea existent n stoc
3. Adugare detalii la
comand/ieire
detaliiIeire
Adugare date
(INSERT)
Se completeaz factura cu linii de

factura (o linie corespunde unei
nregistrri detaliiIeire)
4. Actualizare stocuri
produse farmaceutice
produsFarmaceu
tic
Rennoire date
(UPDATE)
Se scade din valoarea curent a

atributului cantitate produs/Stoc
cantitatea eliberat clientului
5. Se salveaz factura
sau se terge factura
Ieire
Salvare sau
tergere
Se tiprete documentul sau n

cazul refuzului (cnd nu exist un
careva produs n cantitatea
solicitat) e terge acesta
34
2. Schema logic pentru funcionalitatea Onorarea comenzii ctre client (se va precuta cazul cnd
comanda a fost preluat de la client i salvat n BD):
Start
Selecteaza
comanda
Creaza factura
pentru comanda
Valideaza
produsul si
cantitatea
Accepta
comanda fara
produs?
Consulta clientul
referitor la
inexistenta
produsului
BD
Produsul
exista?
Nu
Da
Consulta clientul
referitor la
cantitate
disponibila
Nu
Anuleaza/amana
comanda si sterge
factura
Nu
Accepta
comanda cu
cantitatea
existenta?
Da
Nu
Cantitate
comandata <=
Stoc
Da
Da
Tipareste/
Salveaza factura
Stop
Stoc=Stoc-cantitateComandata
Factura
Reinnoieste date
stoc
Fig. 15. Descrierea fluxului logic, utiliznd schema logic, pentru funcionalitatea Onorare comand client

1. Descriei accesrile tabelelor BD i logica/algoritmul pentru funcionalitatea Preluarea comenzilor
de la client i funcionalitatea Evidena stocurilor de mrfuri.
35
Lucrarea de laborator nr. 11

Tema: Produse CASE pentru planificarea i managementul
proiectelor SI
Obiective urmrite:
S cunoasc produse soft care pot fi utilizate pentru planificarea proiectelor SI;
S cunoasc utilitatea produselor CASE la planificarea proiectelor SI;
S posede abiliti de folosire a produsului Microsoft Project la planificarea proiectelor pentru

sisteme soft i sisteme informatice.
Cerine:
1. Cunoaterea produselor MS Visio (non-CASE) i MS Project, folosite pentru planificarea grafic
a proiectelor pentru sistemele soft i informatice.
2. Avantajele folosirii mediului MS Project la crearea planului proiectului.
36
Lucrarea de laborator nr. 12

Tema: Planificarea iniial a proiectului SI
Obiective urmrite:
S formuleze clar obiectivele proiectului (cu respectarea caracteristicilor SMART);
S determine corect activitile necesare a fi ntreprinse pentru dezvoltarea SI;
S evalueze corect necesarul de resurse pentru realizarea proiectului descris n lucrrile de

laborator 2 i 3;
S estimeze (maxim posibil) corect duratele de realizare a diferitor activiti i a ntregului

proiect;
S poat construi i interpreta corect diagrama Gantt i modelul-reea corespunztoare

proiectului de dezvoltare a SI.
Cerine:
1. Formularea obiectivelor principale ale proiectului.
2. Fixarea datelor generale ale proiectului (denumirea, autorul etc.).
3. Definirea graficului de activitate a echipei proiectului. Abateri de la calendarul standard (dac
este necesar).
4. Specificarea listei de activiti necesare a fi realizate pentru dezvoltarea SI (pot fi grupate n
procese, etape).
5. Fixarea datelor de nceput i sfrit ale activitilor, determinarea duratelor activitilor.
6. Specificarea necesarului de resurse pentru realizarea proiectului (umane, materiale, tehnice,
de tip cost).
7. Alocarea/repartizarea de resurse fiecrei activiti.
8. Calcularea cheltuielilor proiectului (a bugetului).
9. Stabilirea relaiilor dintre activiti. Construirea diagamei de tip reea (PERT).
10. Construirea diagramei Gantt.
11. Gestiunea
resurselor
(monitorizarea
repartizrii
corecte
resurselor
corespunztor
activitilor).
Observaie: Planul calendaristic de realizare a proiectului poate fi realizat manual, folosind editoare
grafice i cele ale textului, dar poate fi realizat n MS Project, mediu CASE folosit n planificarea
calendaristic a activitilor proiectelor.
37

Pentru a ndeplini aciunile/transformrile necesare asupra sistemului informatic n
decursul
ciclului su de via, organizaia creeaz i controleaz proiecte [6]. Proiectele au anumite limite,
termene i scop.
Scopul proiectului este legat cu scopul sistemului informatic n ntregime, sau cu prile sale
componente.
Orice sistem se poate diviza n sisteme mai mici i n acelai timp poate fi parte a altui sistem
informatic de proporii mai mari.
Const din
Sistem
informatic
Responsabil
deProiect
Sistem
informatic

Proiectul
Proiectul
Proiect
SMART este un acronim al caracteristicilor considerate eseniale pentru corecta formulare a

unui obiectiv. Obiectivele formulate pot fi generale sau specifice.
Aceste caracteristici sunt urmtoarele:
S specific;
M msurabil;
A (de) atins/abordabil;
R relevant;
T ncadrat n timp.
Comisia European, n Manualul privind Managementul Ciclului Proiectului, utilizeaz criteriile
SMART doar n ceea ce privete formularea indicatorilor de msurare a atingerii obiectivelor propuse.
Cum indicatorii sunt legai de obiective, ns trebuie s reflecte o imagine real a gradului de atingere
a acestora, este normal deci s apar diferene de concept.
Specific nseamn c un obiectiv indic exact ceea ce se dorete a se obine. Un obiectiv
specific este foarte clar exprimat, nu las loc de ndoieli. Un obiectiv specific difer n primul rnd de
unul general. El vizeaz rezultate concrete, iar nu rezultate n general.
Msurabil nseamn c un obiectiv poate fi cuantificat, fie cantitativ, fie calitativ. Un
obiectiv msurabil este cel care permite stabilirea cu exactitate a faptului c a fost atins ori nu sau n
ce msur a fost atins. De asemenea, un obiectiv msurabil permite monitorizarea progresului
atingerii lui.
Exemplu de obiectiv general: "organizarea unui training pentru participanii la proiectul X".
Exemplu de obiectiv specific: "organizarea unui training pe tema scrierii documentaiei tehnice pentru
38
cele dou persoane responsabile de documentarea (scrierea documentaiei tehnice) implicate n

proiectul X".
Se poate vedea, n exemplul de mai sus, c, prin compararea situaiei de la un moment dat cu
obiectivul, se poate msura dac a fost atins ori nu sau n ce msur a fost atins (Ex: 50%, daca la
training a participat doar o persoan).
Abordabil/de Atins/reAlizabil nseamn c un obiectiv poate fi ntr-adevr atins. n acest
sens, trebuie luate n considerare mai multe aspecte:
- prin definirea obiectivului nu se propune realizarea a ceva imposibil de atins n condiiile
date. De exemplu: trainingul va fi ineficient dac va dura doar 45 minute;
- obiectivul n cauz, poate fi atins n condiiile proiectului, de ctre organizaia sau persoana
care este responsabil de realizarea lui. n acest sens, trebuie inut cont de resursele existente,
capacitatea organizaiei, timpul disponibil necesar.
Relevant nseamn c realizarea obiectivului contribuie la impactul vizat de proiect.
Realizarea unui obiectiv trebuie s contribuie n mod nemijlocit la atingerea unui obiectiv mai mare,
mai general. n acest sens, el trebuie s vizeze un anumit impact. De exemplu instruirea celor 2
persoane responsabile de documentarea proiectelor soft va avea impact asupra numrului mai mare
de documentare a proiectelor realizate de organizaie. Dac impactul obiectivului ar fi ca organizaia
s creasc numrul de proiecte care ar fi documentate de alte persoane, care activeaz n alte
organizaii, atunci obiectivul "organizarea unui training pe tema scrierii documentaiei tehnice pentru
cele dou persoane responsabile de documentarea (scrierea documentaiei tehnice) implicate n
proiectul X" nu ar fi relevant, deoarece cei doi angajai nu ar trebui s mai scrie documentaie
tehnic.
ncadrat n Timp nseamn c obiectivul conine i data pn la care este prevzut a se
realiza. Exemplu: "organizarea n perioada 7-10 octombrie 2013 a unui training pe tema scrierii
documentaiei
tehnice
pentru
cele
dou
persoane
responsabile
de
documentarea
(scrierea
documentaiei tehnice) implicate n proiectul X" reprezint un obiectiv ncadrat n timp.

Ciclul de via al unui sistem informatic const dintr-un ir de etape la care sistemul software
este planificat, proiectat, creat, implementat, exploatat, meninut i anulat. Ciclul de via este strns
legat de cerinele formulate fa de SI.
Activiti
Procese
P2
P1
P3
P5
P1
Etapa 1
P1
P6
P4
P8
P9
P9
Etapa 2
Etapa 3
Etapa N
Sistemul informatic
Ciclul de via
La ndeplinirea proceselor ciclului de via al SI pot fi evideniate urmtoarele roluri de baz:

- managerul proiectului;
39
- reprezentantul beneficiarului;
- consultantul juridic;
- analistul proceselor de activitate (business proces);
- managerul elaborrii SI;
- proiectantul proceselor de activitate;
- analistul de sistem;
- arhitectul sistemului;
- proiectantul sistemului;
- proiectantul interfeei pentru utilizator;
- programatorul;
- integratorul;
- persoana responsabil de testare (inginer al calitii);
- elaboratorul testelor;
- scriitorul documentaiei tehnice;
- managerul implementrii produsului software;
- administratorul de sistem;
- administratorul bazelor de date;
- managerul exploatrii;
- utilizatorul produsului software;
- managerul mentenanei produsului software;
- specialistul dirijrii configuraiei;
- analistul serviciului de mentenan;
- persoana de testare a serviciului de mentenan.
Observaie: La realizarea proiectelor concrete, se admite completarea componenei rolurilor,
predeterminate de prezenta reglementare tehnic, precum i ndeplinirea a ctorva roluri de ctre un
singur executant.

1. Exemplu pentru coninutul activitilor unui proiect de dezvoltare a SI (avnd la baz modelul
cascad de dezvoltare):
Obiective generale:
__________________________
Obiective specifice:
__________________________
Rezultate care se doresc a fi obtinute:
___________________________
Pentru un proiect mediu sau complex evaluarea duratei activitatilor ar fi:
START
1. Formularea cerintelor iniiale i elaborarea strategiilor: aproximativ 1-2 saptamani.
2. Analiza: aproximativ 3 luni.
40
Intervievarea expertilor din cadrul intreprinderii 1-2 saptamani (aprox. 2 zile pentru
fiecare expert din cadrul organizaiei; dar cel puin 2 experti);
Cercetarea domeniului pentru care se alcatuieste SI 2 saptamani;
Analiza Sistemelor Informationale i construirea structurii organizationale a

intreprinderii 2 saptamani;
Cercetarea sistemelor informatice care deja se exploateaza 1 saptamana;
Alcatuirea dictionarului de termini 1 saptamn;
Alcatuirea definitiva a documentatiei necesare tuturor etapelor urmatoare 1-2

saptamani;
Alcatuirea sarcinii tehnice de la 2-3 zile;
Alcatuirea planului calendaristic ale activitatilor din cadrul proiectului de la 12 zile;
Stabilirea necesarului de resurse 2-5 zile;
Alcatuirea si incheierea contractelor n care se prevede proiectarea, realizarea i
implementarea sistemului 2-5 zile.
3. Proiectarea de la 4 luni.
Elaborarea modelelor datelor (arhitectura BD, ERD) de la 3 saptamani;
Elaborarea arhitecturii programelor (descrierea componentelor si a legaturilor dintre

ele) de la 2 saptamani;
Elaborarea modelului interfetelor (structura si forma ecranelor si ale rapoartelor) de la

3 saptamani;
Elaborarea modelului proceselor sistemului (DFD si descrierea sarcinilor sistemului din

cadrul etapei de implementare si exploatare) de la 2 saptamani;
Elaborarea cerintelor tehnice fata de partea soft si hard ale serverelor si ale locurilor de
activitate (pentru cei ce testeaza si pentru clienti) 1 saptamana.
4. Realizarea de la 7 luni (una dintre cele mai complicate etape).
Codificarea componentelor de la 3 luni (depinde de numarul componentelor ce

automatizeaza anumite procese);
Testarea de la 1 luna (se recomand aprox. 30% din timpul rezervat etapei
realizarii);
Generarea BD, tabelelor, cererilor 1-3 luni;
Completarea preventiva cu date a sistemului pentru cercetari si testari 1 saptamana;
Asamblatea si testarea de ansamblu a sistemului de la 1 luna;
Pregatirea documentatiei de sistem (descrierea sistemului, ghidul utilizatorului si ghidul

administratorului cu toate anexele) de la 1 luna;
Procurarea i instalarea componentelor hardware (n cazul n care clientul nu dispune

de ele sau n rezultatul analizei s-a estimat nlocuirea componentelor vechi cu altele
noi) de la 1 lun.
5. Implementarea (unei componente de sistem) de la 1 luna.
Instalarea sistemului la locul de munca a utilizatorului si administratorului 1

saptamana;
Insotirea clientului in timpul culegerii datelor 1-2 saptamani;
41
Inlaturarea riscurilor care apar la exploatare pana la 1 saptamana;
Instruirea clientilor si a administratorilor pana la o saptamana;
Pregatirea si intarirea documentatiei de predare-primire a sistemului 1-3 zile.
6. Exploatarea i ntreinerea SI (se ncheie contracte separate).

STOP.
Observaie: Mai pot fi incluse activiti ce in de planificarea i managementul riscurilor, analize de
fezabilitate a proiectului etc. Deasemenea planul poate fi construit avnd la baz modelul spiral sau
incremental de dezvoltare a SI.
2. Exemplu al listei activitilor propus de Microsoft [8]:

1. Construii diagrama Gantt i PERT pentru urmtoarele activiti. Alocai resursele necesare
ndeplinirii activitilor:
Denumirea activitii
Data de nceput
Data de sfrit
1. Elaborarea planului proiectului
17.02.2014
20.02.2014
2. Prezentarea planului
21.02.2014
3.1. Formularea iniial a cerinelor
24.02.2014
28.02.2014
3.2. Specificarea (inclusiv grafic) a cerinelor
03.03.2014
04.03.2014
3. Definirea cerinelor
42
3.3. Adaptarea planului dezvoltrii
03.03.2014
04.03.2014
3.3. Elaborarea sarcinii tehnice
05.03.2014
07.03.2014
3.4. Prezentarea sarcinii tehnice
10.03.2014
4.1. Planificarea instruirii utilizatorilor
11.03.2014
12.03.2014
4.2. Proiectarea logicii
13.03.2014
18.03.2014
4.3. Proiectarea BD
13.03.2014
17.03.2014
4.4. Proiectarea arhitecturii fizice a SI
18.03.2014
19.03.2014
4.4. Proiectarea interfeelor de dialog
19.03.2014
21.03.2014
4.5. Prezentarea proiectului tehnic
24.03.2014
5.1. Programarea front-end-ului
25.03.2014
11.04.2014
5.2. Programarea back-end-ului
25.04.2014
15.04.2014
5.3. Elaborarea planului de testare a soft-ului
16.04.2014
17.04.2014
5.4. Procurarea i instalarea componentelor
16.04.2014
18.04.2014
5.5. Elaborarea ghidului utilizatorului
21.04.2014
23.04.2014
5.6. Elaborarea documentaiei de instalare i operare
21.04.2014
23.04.2014
6.1. Testarea i rapoarte ale testrii
24.04.2014
25.04.2014
6.2. Planificarea final a instruirii utilizatorilor
29.04.2014
30.04.2014
6.3. Elaborarea listei de acceptri ale verificrilor
29.04.2014
30.04.2014
6.4. Elaborarea versiunii finale a ghidului
01.05.2014
02.05.2014
6.5. Instalarea softului i instruirea administratorilor
05.05.2014
06.05.2014
6.6. Predarea produsilui
07.05.2014
08.05.2014
09.05.2014
4. Proiectarea SI
5. Realizarea SI
hardware a SI
6. Integrarea i testarea
utilizatorului
7. Elaborarea planului de ntreinere. ntreinerea i

exploatarea SI.
43
BIBLIOGRAFIE
1. Oprea Dumitru Analiza si proiectarea Sistemelor Informationale economice, ed. POLIROM ,
IASI, 1999
2. A. M. Vendrov
CASE tehnologhii. Sovremennie metodi i sredstva proectirovania IS, http: //
www.citforum.ru/database/case
3. N.Morariu Proiectarea Sistemelor Informatice
http://www.scribd.com/doc/27955265/Proiectarea-Sistemelor-Informatice
4. Dorin Bocu Iniiere n Ingineria Sistemelor Soft, ed. Albastr, Cluj-Napoca, 2001
5. Ilie Vaduva, V. Baltac, V. Florescu etc. Ingineria programarii, vol.1, vol.2, Ed. Academiei
Romane, Bucuresti 1995, 1996
6. "Procesele ciclului de via al software-ului", RT 38370656 - 002:2006, 23.06.2006, Monitorul
Oficial Nr. 95-97, art Nr: 335
7. ..
. "", 1995, 3
8. http://office.microsoft.com/en-us/templates/software-development-project-planTC001018453.aspx
9. www.docme.ru/doc/733/konspekt-ais-2009
10. The guide to the Business Analysis Body of Knowledge, elaborat de International Institute of
Business Analysis, 2008
11. Scanlan, D. A., Structured Flowcharts Outperform Pseudocode: An Experimental Comparison,
IEEE Software, 6, 5, p.28-36, 1989.
12. Stoica M., Sisteme informaionale economice, ed. ASE, Bucureti, 2005
44
ANEXA 1

1. ISO/IEC
12207:1995.

2. ISO/IEC 9126-1:2000. . .
1:
3. ISO/IEC 9126-1-3: 1998. -
1.
; 2. 3. ( )
4. ISO/IEC
9126:1991.

5. ISO/IEC 12119:1994. . .

6. ISO/IEC 14598-1:1997. . .
1:
7. ISO/IEC 14598-4:1999. . .

8. ISO/IEC 15288: 2000. .
9. ISO 687:1983. . .
10. ISO
6592:1985.

11. ISO 6592:1986. .
12. ISO 9127:1987. .
13. ISO 9294:1990. TO. .
14. ISO 15846:1998. . .

15. MIL-STD-498:1994.
16. ISO TR 9127:1988. -

17. ISO 14102:1995. -
CASE
18. IEEE 1063-1993.
19. IEEE 1074-1995.
20. ANSI/IEEE
828
1990.
21. ANSI/IEEE 829 - 1983.
45
22. ANSI/IEEE 983 - 1986.
23. ANSI/IEEE 1008 - 1986.

24. ANSI/IEEE 1012 - 1986. () (verification)
(validation)
25. ANSI/IEEE 1042 - 1993.

26. ANSI/IEEE 1063:1993.
27. ANSI/IEEE 1219 - 1992. .
28. ISO 8402:1994. .
29. ISO 9000-3:1997.
. 3. ISO 9001
, , .
46
ANEXA 2
Documente care reglementeaz dezvoltarea sistemelor soft i informatice
valabile n RM
1. RT 38370656 - 002:2006
2. STAS 34.602.89, STAS 19.201.78
3. STAS 19.202.78
4. STAS 19.402.78
5. STAS 19.502.78
6. M 50-34. 698-90
7. STAS 19.301.79
8. STAS 34.xxx
9. STAS 24.xxx
10. STAS 19.xxx
11. STAS 34.602-89 STI
12. STAS 34.603-92 STI
13. STAS 24.204-80 SDSA
14. STAS 24.211-80 SDSA
15. STAS 24.209-80 SDSA
16. STAS 24.210-80 SDSA
17. STAS 24.205-80 SDSA
18. STAS 24.206-80 SDSA
19. STAS 24.207-80 SDSA
20. STAS 24.208-80 SDSA
47
ANEXA 3
Exemplu n slide-uri
Sursa: http://www.slideshare.net/MsLemard/data-flow-diagrams-8280780
48
49
50
51
52
53

Proiectarea Unui Sistem Informatic

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Proiectarea Unui Sistem Informatic

Încărcat de

Drepturi de autor:

Formate disponibile

Lucrarea de laborator Nr.

Prezentarea organizaiei i definirea corect a obiectului/domeniului supus studiului;

Analiza i expunerea corect a structurii sistemului informaional n care urmeaz s fie

Analiza proceselor de activitate corespunztor fiecrui nivel funcional al organizaiei;

Studiul, analiza i prezentarea sistemului informaional actual al ntreprinderii;

Evidenierea rolului sistemului informaional n activitatea organizaiei;

Noiuni necesare a fi cunoscute pentru realizarea lucrrii:

componenta de administrare (responsabil de luarea deciziilor) a ntreprinderii;

componenta de cercetare i dezvoltare tehnologic;

componenta de aprovizionare, responsabil de achiziia resurselor materiale consumate n

componenta de producere responsabil de crearea produciei/serviciilor ntreprinderii;

componenta de desfacere, responsabil de vnzarea produselor ntreprinderii;

componenta de depozitare, responsabil de pstrarea produciei (uneori poate coincide cu

componenta personal, responsabil de selectarea personalului i managementul resurselor

componenta finaciar-contabil, responsabil de planificarea i gestiunea resurselor financiare

informaionale ale ntreprinderii.

marimile dreptunghiurilor i grosimile contururilor acestora se coreleaza cu obiectul, sarcinile,

situarea in organigrama a dreptunghiurilor si liniilor trebuie sa reflecte raportul de

organizatorice, trebuie sa cuprinda legende cu semnificatia simbolurilor utilizate.

Exemple de artefacte specifice lucrrii de laborator nr.2:

Fig. 3. Exemplu de organigram

Fig. 4. Exemplu organigram

Fig. 5. Exemplu organigram

Sarcini propuse pentru rezolvare:

Lucrarea de laborator Nr.3

Delimitarea subsistemelor informaionale ale organizaiei, conform componentelor funcionale;

Evidenierea corect a surselor de date a sistemului informaional, a locurilor i modalitilor

Descrierea algoritmilor de obinere a informaiilor, n baza datelor disponibile, destinaia

Noiuni necesare a fi cunoscute pentru realizarea lucrrii:

Competitivitatea unei organizatii depinde mult de gradul de structurare, optimizare i

Exemple de artefacte specifice lucrrii de laborator nr.3:

act pe baza cruia se efectueaz procesul de decontare a bunurilor livrate;

act de nsoire a bunurilor pe timpul transportului;

act de ncrcare n gestiunea cumparatorului;

act justificativ de nregistrare n contabilitatea furnizorului i a cumpratorului.

Factura trebuie s cuprind, n mod obligatoriu, cel puin urmtoarele date:

data emiterii facturii;

denumirea, adresa i codul de nregistrare ale cumparatorului de bunuri sau servicii;

denumirea i cantitatea bunurilor livrate sau denumirea serviciilor prestate;

La furnizor, factura circul:

la compartimentul desfacere, n vederea nregistrarii n evidenele operative i pentru

la compartimentul financiar-contabil, pentru nregistrarea n contabilitate.

La cumparator, factura circul:

la depozitul, care primete produsul i este responsabil de pstrarea acestuia;

denumirea, adresa i codul fiscal ale agentului economic emitent;

logotipul i seria aparatului de marcat;

numrul de ordine al bonului, data i ora emiterii;

Ieiri din sistem ctre entitatea

Rapoarte statistice i informaii de

Secia achiziii publice

Informaii referitoare la iepuizarea

Foaia de drum i factura

Foaia de drum semnat i cu

Factura de ieire, nregistart

3) Studierea sistemului informaional. Identificarea proceselor de prelucrare. Exemplu pentru

Tabelul 2. Prezentarea proceselor, a intrrilor i a ieirilor de date pentru fiecare proces de

1. nregistrarea unei noi intrri

Ieiri din proces

(foaia de drum i factura),

livrrii i nscrierea observaiilor

5. Verificarea prezenei standardelor

1. Verificarea vaccinurilor: dac

corespund codurile de bare, cantitile