Sunteți pe pagina 1din 53

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.

Noiuni necesare a fi cunoscute pentru realizarea lucrrii:


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.

Exemple de artefacte specifice lucrrii de laborator nr.3:


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

Sarcini propuse pentru rezolvare:


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.

Lucrarea de laborator Nr.4


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.

Noiuni necesare a fi cunoscute pentru realizarea lucrrii:


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.

Exemple de artefacte specifice lucrrii de laborator nr.4:


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

Sarcini propuse pentru rezolvare:


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

Lucrarea de laborator Nr.5


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

Noiuni necesare a fi cunoscute pentru realizarea lucrrii:


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

Lucrarea de laborator Nr.6


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.

Noiuni necesare a fi cunoscute pentru realizarea lucrrii:


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.

Exemple de artefacte specifice lucrrii de laborator nr.6:


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.

Sarcini propuse pentru rezolvare:


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

Lucrarea de laborator Nr.7


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.

Noiuni necesare a fi cunoscute pentru realizarea lucrrii:


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

Exemple de artefacte specifice lucrrii de laborator nr.7:


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

Sarcini propuse pentru rezolvare:


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

Lucrarea de laborator Nr.8


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

Noiuni necesare a fi cunoscute pentru realizarea lucrrii:


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.

Exemple de artefacte specifice lucrrii de laborator nr.8:


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

Sarcini propuse pentru rezolvare:


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

Lucrarea de laborator Nr.9


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.

Noiuni necesare a fi cunoscute pentru realizarea lucrrii:


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.

Exemple de artefacte specifice lucrrii de laborator nr.9:


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

Lucrarea de laborator Nr.10


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

Noiuni necesare a fi cunoscute pentru realizarea lucrrii:


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.

Exemple de artefacte specifice lucrrii de laborator nr.10:


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

Sarcini propuse pentru rezolvare:


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

Noiuni necesare a fi cunoscute pentru realizarea lucrrii:


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.

Exemple de artefacte specifice lucrrii de laborator nr.12:


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]:

Sarcini propuse pentru rezolvare:


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