Capitolul 7 Procesul de Proiectare in Analiza Si Diagnoza Sistemelor

7
Procesul de proiectare n analiza

i diagnoza sistemelor
Procesul de proiectare constitue una din cele mai importante etape n

analiza de sistem, n care se fructific n mod creativ informaiile obinute n faza
de investigare i are ca obiectiv principal, obinerea unui proiect al sistemului. n
acest proces se pot utiliza diferite tehnici n funcie de natura problemei, de
resursele tehnice, financiare i de timp avute la dispoziie. n aceast etap este
necesar un control al proiectului pe parcursul desfurrii lui, n scopul obinerii
performanelor dorite de utilizator. Proiectul sistemului reprezint rezultatul unei
analize atente i a interpretrii modelelor sistemului actual, n scopul de a le folosi
ulterior n luarea deciziilor privind implementarea unui nou sistem, mai
performant.
7.1 Obiectivele i principiile proiectrii
Analistul de sistem interpreteaz modelul conform experienei i capacitii
lui i elaboreaz pe baza acestuia proiectul logic i proiectul fizic al sistemului.
Principalele obiective avute n vedere n procesul de proiectare sunt:
a) Definirea sistemului. Aceast faz se dezvolt n timpul studiului de
fezabilitate cnd sunt definite obiectivele, funciile, restriciile precum i intrrile
necesare pentru obinerea prin diferite transformri a ieirilor dorite. n etapele
urmtoare de analiz preliminar i detaliat se face o aprofundare a definirii
sistemului prin lrgirea ariei de investigare asupra lui.
b) Stabilirea cheilor proprii pentru proiectare urmrete a nu se pierde
perspectiva de ansamblu asupra proiectului. Aceste chei pot prevedea de exemplu
ca:
activitile cu caracter general s se execute naintea celor specifice;
activitile logice s se desfoare naintea celor fizice;
alegerea sistemului de proiectare s fie adecvat unui sistem complex
(modularitate, ierarhizare, orientare pe obiecte);
c) Crearea unui cadru general asupra proiectului sistemului urmrete:
stabilirea pailor logici pentru proiectare (intrri, ieiri, prelucrri,
regsiri i raportri) i precizarea instrumentelor pentru realizarea lor;
Analiza, diagnoza i evaluarea sistemelor din economie
respectarea principiului major al proiectrii n sensul c sistemul se

proiecteaz de la ieire la intrare. Acest lucru apare necesar datorit
faptului c:
- informaiile de la ieire se bazeaz pe cele de la intrare;
- informaiile ce trebuiesc selectate i memorate sunt cele necesre
prelucrrilor i ieirilor urmrindu-se n acest fel i o reducere a
volumui de informaii.
La sfritul fazei de analiz analistul are o imagine clar asupra
funcionrii sistemului (actual sau a celui ce va fi construit); are definite cererile i
dispune de un concept-cadru general de proiectare, pe baza cruia se poate trece la
proiectarea logic i fizic a sistemului.
Proiectarea logic furnizeaz un set de specificaii logice care precizeaz
ce funcii trebuiesc executate de ctre noul sistem i care vor sta la baza
fundamentrii deciziilor de proiectare. Ea rspunde la ntrebarea ce e de fcut ?.
Proiectarea fizic furnizeaz specificaiile de realizare i implementare ale
proiectului fizic, preciznd cum se vor realiza funciile sistemului innd seama de
resursele disponibile. Indiferent de metodele de proiectare utilizate, la baza ei stau
opt principii comune i anume:
1. Economicitatea, are drept scop realizarea unui proiect ct mai compact
cu un numr ct mai mic de module, obiecte, date, procese care s satisfac
obiectivele i s respecte principiul rentabilitii.
2. Simplitatea, presupune realizarea soluiei proiectului n modul cel mai
simplu posibil, innd seama de resursele disponibile, pe de-o parte, i de eficiena
estimat a soluiei, pe de alt parte.
3. Structurarea, implic descompunerea sistemului n subsisteme n scopul
realizrii unei bune partiionri, a nesuprapunerii scopurilor, i a corelrii
obiectivelor locale, astfel nct s fie soluionat problema global n ansamblul ei.
4. Cutia neagr (black-box), impune considerarea i tratarea fiecrui
subsistem numai pe baza intrrilor i a ieirilor sale (a interfeelor) prin care
interacioneaz cu sistemele nvecinate. Modul intern de funcionare a fiecruia nu
are importan asupra structurii i funcionrii celorlalte subsisteme, deci trebuie
avut n vedere doar interfaa.
5. Claritatea n urmrirea funcionrii proiectului i a ajustrii cu uurin a
lui la eventuale perturbaii din mediu. n acest scop se utilizeaz pentru proiectare
tehnicile analizei structurate top-down, bottom-up sau tehnica orientrii pe obiecte
care permit o adaptare rapid la schimbri.
6. Transportabilitatea - urmrete ca proiectul s fie astfel executat nct
s nu fie dependent de mediu (suportul de execuie), adic s poat fi transportat cu
uurin pe oricare alt mediu.
7. Transparena - proiectul trebuie astfel conceput nct modul de lucru cu
sistemul la care el se refer s nu necesite alte informaii dect cele clasice,
instruciunile de utilizare fiind reduse la minimum.
8. Confortabilitatea presupune realizarea unui proiect prietenos,
existena unei interfee ntre sistem i utilizator, care s faciliteze adaptarea rapid a
Procesul de proiectare n analiza i diagnoza sistemelor
utilizatorului, precum i crearea unei stri de confort operatorului n timpul folosirii

sistemului.
Aceste principii reprezint mai degrab un ghid dect o obligativitate care
trebuie s stea la baza elaborrii oricrui proiect. Respectarea acestora se poate
realiza dac exist o permanent comunicare ntre analiti, proiectani,
programatori, utilizatori att n etapele premergtoare elaborrii proiectului, ct i
pe parcursul realizrii lui. Aceasta se realizeaz prin ntruniri la care particip
diversele grupuri implicate n proiectare i utilizatorii proiectului. Este necesar s
se adopte n acest context un spirit deschis, analistului de sistem revenindu-i rolul
de a media i de a pune de acord toate prile implicate.
7.2 Proiectarea logic n analiza i diagnoza sistemelor
O tendin evident n ultimii ani n domeniul analizei i diagnozei sistemelor,
arat c aplicaiile au devenit mai complexe, resursele de manoper mai specializate i
cerinele utilizatorului mai precise. n acest context analistul de sistem trebuie s-i
adapteze munca de proiectare n raport cu aceste tendine pentru a contribui efectiv la
mbuntirea performanelor sistemului. Un proiect poate fi reprezentat printr-o reea
de activiti care urmresc realizarea produsului ntr-un anumit interval de timp limitat.
Aceste limitri apar datorit unor restricii de timp, de buget, de perturbaii din mediu
(care pot conduce ca proiectul s nu mai satisfac cererile pieei) datorit schimbrilor
rapide pe plan tehnologic (componente electronice, tipuri de calculatoare etc.).
Pentru a micora aceste limitri se recurge la:
simplificarea proiectului lsnd mai multe atribuii beneficiarului;
scurtarea ciclului de realizare prin antrenarea mai multor resurse
umane pentru a evita uzura moral proiectului;
utilizarea de prototipuri ce simuleaz ieirile i prin a cror testare se
realizez o mbuntire a proiectului.
Proiectarea logic, indiferent de forma pe care o mbrac, respect cele trei
legi ale informaiilor i anume:
1. Legea conservrii informaiei ce precizeaz c ieirea unui proces este
generat de suma intrrilor.
2. Legea utilizrii eficiente a informaiei necesare potrivit creia fiecare
intrare ntr-un proces trebuie s aib o contribuie la ieire, n caz contrar intrarea
nu este necesar.
3. Legea succesiunii logice a datelor care afirm c ieirile procesului sunt
utilizabile numai dup ce au fost prelucrate toate intrrile. Dac o ieire apare
naintea aplicrii unei intrri, nseamn c ea nu este dependent de aceast intrare,
deci este inutil.
Principiile generale de proiectare se aplic n cazul specificaiilor logice direct
asupra modelelor. Astfel: economicitatea, impune includerea sub aspect logic a unor
procese asemntoare ntr-unul singur; structurarea, presupune reducerea numrului
de procese considerate numai la cele care sunt n realitate legate nemijlocit ntre ele;

transportabilitatea, nseamn c analistul termin proiectarea logic la un nivel la care
sunt necesare informaii reale detaliate despre mediul de funcionare specific
sistemului etc.
Deoarece modelele reprezint chiar o parte a proiectului logic, ele trebuie s
fie corect construite i interpretate. n acest sens, modelele trebuie s reprezinte
funciile specifice ale sistemului, termenii folosii trebuie s fie adecvai naturii
sistemului, iar modelele trebuie s conin tranzaciile specifice sistemului (adugri,
tergeri, modificri, rapoarte, etc.).
Proiectarea logic necesit cunoaterea acestor aspecte pentru a putea supune
proiectul logic la un al doilea set de teste i de a reflecta asupra unor ntrebri cum ar
fi:
Sunt tratate toate tipurile de tranzacii specifice sistemului ?
Se poate restabili/restaura sistemul n urma unor erori pe care astfel de
sisteme este posibil s le fac ?
Poate s reziste sistemul la tipurile de aciuni pe care mediul su le poate
genera ?
Prin aceste ntrebri, care se refer la situaii generale i nu necesit
cunoaterea detaliat a mediului real, analistul verific dac toate componentele
funcionale sunt prezente pentru tipul de sistem proiectat. Pentru situaii deosebite,
proiectul logic specific doar c exist o procedur care afecteaz proiectarea fizic, iar
implicaiile de a nu avea o astfel de procedur se pot evalua mai trziu.
7.2.1 Proiectarea logic bazat pe model
Proiectarea logic bazat pe model presupune parcurgerea urmtoarelor
activiti:
Analiza sistemului n scopul acumulrii de date privind funciile
sistemului i a obiectivelor lui;
Construirea unui set de modele logice n funcie de natura proiectului;
Analizarea modelelor n scopul eliminrii greelilor i a
contradiciilor, a evitrii nerespectrii unor principii de proiectare, a
nlturrii elementelor ineficiente;
Refacerea i reexaminarea modelului care st la baza elaborrii
proiectului pn cnd nu se mai pot obine mbuntiri majore.
Proiectarea logic bazat pe model are n vedere construirea unui prototip
care se testeaz. Printr-o abordare iterativ modelul este perfecionat. Procesul de
elaborare a prototipului este bazat pe logica top-down. Perfecionarea lui are loc
prin urmrirea funcionrii ntregului model de la nceput pn la sfrit.
Atunci cnd proiectul pentru sistemul propus prezint un caracter de
noutate, sau cnd modelele avute la dispozie sunt mai puin familiare
utilizatorului, se recurge la dezvoltarea unei pri a sistemului prin tehnica
prototipului.
Putem defini prototipul ca o versiune a produsului final, care este succesiv

rafinat i fcut mai eficient. Procesul de proiectare pe baz de "prototip" (figura
7.1, /45/) are urmtoarele caracteristici:
- este iterativ ntruct se are n vedere o rafinare repetitiv a proiectului;
este nedeterminist deoarece nu exist un plan fixat de activiti ce
trebuie executate;
- este condus de utilizatori datorit necesitii de a preciza ce pri
funcioneaz mai bine i care sunt aspectele vizate.
Principalul scop vizat de prototip este de a reduce gradul de incertitudine al
proiectului i de a avea un control mai bun asupra funcionrii lui.
Avantajele crerii i utilizrii prototipurilor sunt:
creterea comunicrii n termenii utilizatorului, ntre analist i
proiectant pentru dezvoltarea noului sistem;
mai uoar posibilitate de modificare a proiectului, acesta oferind
faciliti de experimentare; uneori ntreg sistemul poate fi realizat prin
modificri i ajustri ale prototipului;
adaptarea mai bun la mediile nedeterministe i captarea interesului
utilizatorului care particip direct la fazele de proiectare;
eliminarea erorilor majore ale proiectrii nc din faza de nceput i
posibilitatea ca subsistemul resursurselor informaionale s-i exercite
controlul mai eficient prin cunoaterea interfeei cu celelalte
subsisteme;
posibilitatea utilizrii lui pentru redefinirea i mbuntirea viitorului
sistem.
Dezavantajele rezult din:
creterea duratei de realizare a proiectului i a costurilor datorit
dialogului permanent ntre utilizator, proiectant i analist n scopul
refacerii prototipului;
posibilitatea neimplementrii prototipului, n cazul n care rezultatele
obinute sunt departe de cele scontate.
Analistul de sistem, n calitate de conductor al proiectului, trebuie s
poat rspunde la urmtoarele ntrebri:
1. Ce aspecte legate de meninerea resursei informaionale sunt adecvate a
fi realizate prin tehnica prototipului ?
2. Ce tehnici vor fi utilizate i cum se va realiza prototipul ?

ANALIST
Specificatii
Specificatii finale
A PROIECT LOGIC
Date
Prototip
Criterii de
proiectare
Plan
prototip
Identifica
specificatii
functionale
B Specificatii-prototip
Schimbari
44
Finalizare
prototip
Rafineaza
prototip
UTILIZATOR
ANALIST
ANALIST
ANALIST
Caracteristici
prototip
Specificatii
Comentarii
critice
Avizare
Dispune
de
prototip
UTILIZATOR
ANALIST
Specificatii
finale
Caracteristici noi
Cerinte
UTILIZATOR
Comentarii-critici
PROGRAMATORI
Fig.7.1 Procesul de elaborare a prototipului
Principalele tehnici utilizate pentru construirea de prototipuri sunt:

a) proiectarea bazat pe scenarii, prin care se determin cerinele
utilizatorilor n funcie de anumite scenarii propuse. Aceast tehnic se recomand
atunci cnd anumite ieiri sunt cerute pentru intrri specifice i tinde s fie condus
prin formate de ecrane. De aceea, uneori, ea se numete "generatoare de ecrane" sau
"manager de dialog";
b) utilizarea de limbaje speciale, denumite generatoare de aplicaii, au ca
principal scop generarea rapid a unor aplicaii pe baza recomandrilor formulate de
utilizatori;
c) soft reutilizabil, se folosete atunci cnd aplicaiile noi au aceeai structur
cu alte probleme de dimensiuni mai mici care au fost rezolvate i pentru care exist un
set de rutine incluse n soft. Exist cteva generatoare de aplicaii care lucreaz n acest
mod, n special cele bazate pe meniuri, fiecare meniu selectat referindu-se la o
subrutin;
d) tehnica simplificrii ipotezelor are ca scop reducerea ciclului de
dezvoltare a softului i urgentarea aplicrii acestuia de ctre utilizator. n acest
sens, analistul i programatorul consider unele ipoteze simplificatoare, bine
documentate, referitoare la munca dificil de programare, care fac posibil
dezvoltarea rapid a softului;
e) tehnica bazat pe limbaje de specificaii executabile este orientat pe

limbaje care documenteaz ceea ce este necesar (cerut) fr a programa procedurile i
fr a preciza cum se vor realiza acestea.
Limbajele de specificaii executabile, ca de exemplu GIST, RSP, OBJ,
PSLAIR1, USE construiesc modele ale proceselor care pot fi apoi interpretate n mod
direct de soft la implementarea procesului.
Succesiunea de prototipuri construite poate servi ca tehnic de analiz a
cerinelor utilizatorului, dar i ca documentare pentru procesul de analiz-nvare
necesar pentru nelegerea aplicaiei de ctre analist.
Adeseori se renun la tehnica prototip cnd problema de proiectare este
clasic i se poate utiliza un soft pentru utilizatorul final. E necesar ns ca
utilizatorul final s controleze softul n toate fazele lui. Avnd n vedere specificul
aplicaiei el va opta pentru un soft tradiional, sau i va dezvolta propriul soft. n
faza a doua, el alege mediul de dezvoltare (un centru informatic, un calculator
personal, un terminal). O a treia decizie este de a alege un pachet pentru analiza
statistic a datelor obinute sau un limbaj natural de interogare a bazei de date.
Principalele situaii asupra crora utilizatorul i d avizul sunt:
a) generarea datelor de intrare;
b) interogarea bazei de date;
c) modelarea datelor;
d) analize statistice ale rezultatelor obinute.
Cnd utilizatorul final controleaz softul n toate stadiile dezvoltrii lui el
se familiarizeaz cu instrumentele pentru mnuirea lui pe de-o parte, iar pe de alt
parte, se diminueaz costurile legate de unitatea de resurs informaional i de
utilizarea ei.
Conceptul de soft pentru utilizatorul final este redat n figura 7.2. /45/.
Utilizator
specificaii
Utilizare
specificaii
asisten instruvechi
mente de
A Specificaii
specificaii
utilizator
dezvoltare specificai
noi
Utilizator
cerere
Apeleaz
la IRU
pentru
Utilizator
Specificaii
Programare
IRU
2
Rezultate
Interpretare
specificaii
Utilizator
Comentarii
Specificaii
Baza de date a firmei
Fig. 7.2 Dezvoltarea softului pentru utilizatorul final

7.2.2 Proiectarea logic bazat pe componente
Aceast tehnic se utilizeaz n cazul proiectelor constituite din
componente de sine stttoare. Fiecare component poate fi abordat separat, fr
ca ntreg modelul s funcioneze (aceste componente pot fi intrri, ieiri, date,
prelucrri etc.). O astfel de abordare se folosete de obicei n realizarea proiectelor
pentru care prile componente se pot stabili prin experien i fiecare component
poate s funcioneze ntr-un mod relativ independent de celelalte.
Proiectarea bazat pe componente nu este n mod necesar o abordare "bottomup" (abordare ascendent). Lista componentelor ce trebuie selectate depinde de
experiena analistului acumulat despre sistemele standard din domeniul studiat.
Proiectarea examineaz urmtoarele componente:
a) Ieirile trebuie s fie aprobate de utilizator i apoi se dezvolt
structura lor logic. Se are n vedere ca toate ieirile dorite s existe
atunci cnd e nevoie de ele;
b) Intrrile - se definesc dup ce a fost stabilit structura logic pentru
intrri. Este necesar ca intrrile s fie corecte i introduse la momentul
oportun;
c) Datele - trebuiesc definite i clasificate ntr-un mod logic i ntr-o
structur conform cu obiectivelor cerute;
d) Procesele - trebuiesc evideniate toate procesele ce transform intrrile
n ieirile dorite;
e) Limitele sistemului - trebuiesc astfel alese nct s ofere siguran fa
de infiltrrile i pierderile nedorite de date.
Proiectarea intrrilor se refer nu numai la regulile de economicitate,
simplitate, flexibilitate, rapiditate n modul lor de completare, dar i la felul n care
ele satisfac o serie de cerine i anume:
- fiecare intrare s fie disponibil la momentul n care este utilizat n
calcul (dac nu, operatorul este tentat s inventeze o intrare);
- fiecare intrare s fie corect, iar dac nu, s se precizeze tipurile de
erori ce pot apare legate de ea;
- fiecare intrare s fie disponibil n structura necesar prelucrrilor.
Proiectarea ieirilor se face pornind de la obiective. Ieirile pot conine
diferite tipuri de date, rapoarte, fiiere de date, grafice, tabele, formulare
completate, ecrane etc. Pentru a obine ieirile dorite, trebuie proiectat structura
datelor, adic baza de date a crei utilizare aduce o serie de faciliti, cum ar fi:
minimizeaz resursele umane, materiale i financiare;
utilizeaz un limbaj de interogare orientat;
evit creterea costurilor resurselor materiale i umane.
Proiectarea datelor se ocup de organizarea i accesul la date n dou
moduri:
- intrinsec, cnd accesul este dictat de suportul datelor;
extrinsec, cnd accesul la date se face dup o regul independent de

suportul datelor.
Memorarea datelor se face n baze de date de diferite tipuri, n funcie de
modul cum vor fi prelucrate i utilizate acestea. La proiectarea structurii datelor
este bine ca ele s aib un format standard.
O consideraie important a proiectrii datelor o reprezint dependena logic
i are n vedere ca proiectarea structurii de date s se fac astfel nct elementele lor s
se coreleze logic i funcional. Acest aspect al proiectrii este cunoscut sub numele de
normalizare i const n reducerea descrierii datelor la o descriere "normal", utiliznd
un format standard.
Proiectarea prelucrrilor ia n considerare tipurile de prelucrri necesare
pentru a obine ieirile dorite din intrrile proiectate. Aspectele de proiectare
vizeaz n acest caz:
- prelucrrile de date ce rmn neschimbate;
- ct de rapid poate fi calculat ieirea pentru ca ea s fie util;
- proiectarea interfeei ntre utilizator i datele de care acesta are nevoie.
Proiectarea trebuie fcut astfel nct fiecare proces s funcioneze corect i
s produc rezultatele dorite din intrrile proiectate, ntr-un timp limitat.
n acest scop trebuie considerate urmtoarele aspecte:
determinarea cerinelor care se pot obine i a celor ce nu pot fi obinute
prin prelucrarea datelor cu caracter stabil. Este preferabil s se estimeze
liste acoperitoare de activiti pentru a evita reproiectarea bazei de date
de fiecare dat cnd este necesar o nou activitate;
formularea precis a cerinelor, nelegerea i determinarea exact a
prelucrrilor necesare pentru evitarea calculelor inutile i pentru obinerea
rapid a ieirilor dorite;
stabilirea posibilitii ca fiecare ieire poate fi calculat efectiv din
intrrile disponibile, i n timp util. Aceast consideraie este dificil de
stabilit n timpul proiectrii logice;
proiectarea interfeei dintre utilizatori i date astfel nct s faciliteze
specificarea doleanelor utilizatorului ntr-o form ct mai prietenoas.
O preocupare important n proiectarea procesului este de a se stabili modul
de folosire a condiiilor de eroare i de securitate a datelor la grania sistemului.
n proiectarea prelucrrilor se ine seama de intrri, de procedurile de
calcul pentru obinerea ieirilor dorite, de tipul de actualizri.
Proiectarea granielor ia n considerare punctele prin care intr i ies
datele. Trebuie n acest caz s se aib n vedere dou aspecte i anume:
a) protejarea sistemului pentru a nu intra date eronate n sistem, sau care
nu sunt utile, iar datele corecte s nu ias dect n scopurile dorite
folosindu-se n acest scop chei, parole de acces;
b) integritatea datelor care se realizeaz prin verificri asupra intrrilor i
ieirilor.

Verificrile de la intrare se refer la:
- domeniul numeric;
- verificri de ncadrare ntr-un intreval;
- verificri de introducere a unor erori mai greu controlabile prin
utilizarea unei cifre de control;
- verificri ale codului de acces.
Verificrile de la ieire, se refer la :
- corectitudinea destinaiei;
- locul unde se vor memora datele;
- crearea unor copii suficiente pentru a asigura securitatea datelor;
- nlturarea proliferarii datelor nvechite.
Proiectarea unor granie rezonabile include i luarea msurilor pentru
asigurarea unor dubluri i regenerri periodice, precum i a unor proceduri de
salvare a sistemului.
Proiectarea pe componente trebuie s in seama de ntreg sistemul
proiectat i de modul n care vor fi interconectate componentele i se vor influena
reciproc.
7.2.3 Proiectarea logic orientat pe obiecte

Acest tip de proiectare are la baz o filozofie care a aprut n anii 80 n
Norvegia, scopul acesteia fiind n esen o mai clar nelegere a cererilor
beneficiarului, proiectarea mai clar a produselor program, o mai uoar ntreinere
a acestora. Apariia ei a fost facilitat de dezvoltrile n plan hardware, realizrile
n domeniul limbajelor de programare, progresele realizate n domeniul metodelor,
tehnicilor de proiectare i realizare a produselor program.
Proiectarea orientat pe obiecte se bazeaz pe un mod de gndire abstract
asupra problemelor reale. Spre deosebire de metodele clasice de analiz i
proiectare, ea const n analiza unor obiecte reale, proiectarea unor obiecte model a
realitii i implementarea lor.
Avantajele utilizrii acestei tehnici sunt:
reutilizri multiple ale produsului proiectat;
mai mare stabilitate a produsului n sensul posibilitii de a reaciona
mai bine la perturbaii;
proiectarea este gndit n termenul utilizrii obiectelor i nu a datelor,
ceea ce-i asigur o calitate mai bun i rapiditate n realizarea ei;
mai bun i rapid comunicare ntre profesioniti i utilizatori;
asigurarea unui ciclu de via mai dinamic al proiectelor;
asigurarea independenei proiectrii de mediul unde se implementeaz.
Proiectarea orientat pe obiecte are la baz analiza i modelarea pe obiecte

i evit neconcordanele ce pot s apar n abordrile clasice ntre proiectare i
analiz. n proiectarea orientat pe obiecte se definesc urmtoarele componente:
ce clase se implementeaz i aceasta se decide de analiza orientat pe
structura obiectelor;
ce structur de date va utiliza fiecare clas, ce operaii ofer fiecare
clas i care vor fi metodele utilizate pentru implementarea lor;
cum se va implementa conceptul de motenire a claselor i cum va
afecta el clasele i metodele;
ce interfa de utilizator este necesar.
n figurile urmtoare (7.3, 7.4, 7.5), se pot sesiza diferenele pentru crearea
unui ordin de plat n analiza clasic, structurat i pe obiecte.
determinarea
cantitii
creare
ordin
de plat
selectare
furnizor
Fig. 7.3 Crearea unui ordin de plat n analiza clasic
ordin de
plat
pentru
merge la
furnizor
livreaz
produs
Fig. 7.4 Crearea unui ordin de plat n analiza structurat

Diagrama de tranziie a strilor indic operaiile multiple ce se utilizeaz
pentru fiecare tip de obiect i clas corespunztoare (figura 7.5).
Proiectantul consider operaia de plat a ordinului i o proiecteaz
convertind tipul de obiect n clase i operaiile n metode. Obiectul ordin de plat
devine o clas cu acelai nume. Fiecare stare de tranziie se transpune ntr-o
operaie.
cerin
creare
trimitere
ateptare
completare
expirat
revizuire
anulare
plat
plat amnat
arhivare
Fig. 7.5 Diagram de tranziie a strilor pentru crearea ordinului de plat
Proiectantul specific pentru fiecare operaie una sau mai multe metode.
De exemplu, n operaia: creare ordin de plat proiectantul specific metoda de
calcul a totalului: obinerea preului unui produs prin adresarea unei cereri clasei
produselor unde este memorat i preul sau adresarea unei alte cereri clasei de
preuri, cnd acestea nu exist n clasa de produse.
Proiectarea bazat pe obiecte trebuie s identifice clasele si
responsabilitile lor nainte de a ncepe proiectarea n interiorul claselor.
Responsabiliteatea unei clase presupune capacitatea ei de a rspunde
corect la cererile pe care le primete i pe care le poate rezolva.
Fiecare clas este o unitate de sine stttoare care ndeplinete
responsabilitile fr a cunoate cauzele i efectele ce au generat cererile. Dac o
clas are responsabilitatea de a reaciona la o cerere, ea o poate face n dou moduri
utiliznd o metod proprie sau transfernd-o altei clase numit colaborator.
ntruct creativitatea uman depete posibilitile oricrui calculator,
pentru a conecta aceast creativitate cu proiectarea orientat pe obiecte se foloseste
metoda CRC (Card Responsability Class) a lui Cunningham /29/. Metoda const n
utilizarea unor fie n care se nscriu: numele clasei, responsabilitile ei, lista cu
colaboratorii utilizai de clas. n cadrul unor reuniuni la care particip proiectani,

manageri i utilizatori se completeaz aceste fie.
Fiecare persoan joac rolul unei clase i are n fa o fi pe care o
completeaz prin discuii n cadrul grupului rspunznd la o serie de ntrebri "ce
se ntmpl dac". Grupul n ansamblu simuleaz comportarea unui sistem.
Coninutul fielor se schimb de mai multe ori n acest proces. Dac o clas are
prea multe responsabiliti se poate trece la mprirea ei n subclase sau la
transferarea acestor responsabiliti altor clase. Proiectarea se ncheie cnd nu se
mai pot imagina ntrebri de acest tip. Proiectarea n grup este uurat de utilizarea
unui vocabular unic i de crearea unui dicionar.
Cererile pot fi considerate ca provenind de la o clas client, iar
responsabilittile corespunztoare cererilor aparin unei clase numite server. Se
introduce noiunea de contract, care reprezint un set de cereri pe care clientul le
face serverului, el fiind obligat de a rspunde la aceste cereri (figura 7.6).
client
server
contract
Fig. 7.6 Contractul unei clase deservite de server
Responsabilitatea reprezint o activitate pe care trebuie s o fac un obiect

pentru alt obiect, folosind n acest scop o metod.
Contractul leag o singur cerere de responsabilitatea corespondent dar
mai muli clieni pot avea acelai contract (figura 7.7).
client
server
client
Fig. 7.7 Clase cu acelai contract

n ceea ce privete responsabilitile, acestea pot fi de mai multe feluri:
- responsabilitai publice ce pot fi cerute de orice obiect ;
- responsabiliti private ce reprezint o parte a modului de lucru intern al
obiectului i pot fi cerute doar de anumite obiecte.
De exemplu: actualizarea unei bnci de date, verificarea unui cod de
siguran, solicitarea unei parole.
O clas poate avea mai multe contracte i o aceeai clas poate juca n
acelai timp att rolul de clas-client ct i de clas-server (figura 7.8).
client
clas client si server
server
clas
Fig. 7.8 Clas cu mai multe contracte i clas client i server
Subsistemele conin grupuri de clase cu responsabiliti diferite care

colaboreaz ntre ele pentru a ndeplini responsabilitaile grupului. Dac o clas
conine n interiorul ei subtipuri de clase ea este privit din exterior ca unic i
distinct, avnd propriile ei contracte. De exemplu, clasa imprimantelor are n
interiorul ei subtipurile laser i matricial (figura 7.9).
subsistem 1
subsistem 2
clas
clas
clas
Fig. 7.9 Subtipuri de clase n interiorul unei clase
Din exterior nu exist diferene ntre subsistem i clas, ele sunt obiecte
ncapsulate i au contracte pentru a furniza un serviciu cerut.
Modelul funcional este caractristic fazei de proiectare, iar construirea lui

presupune:
- identificarea valorilor pentru variabilele de intrare i ieire;
- stabilirea dependenelor funcionale;
- descrierea funciilor i a restriciilor;
- specificarea criteriului de optimizare.
Modelul funcional este reprezentat n cazul metodei OMT prin diagrama
de flux de date. O astfel de diagram ilustreaz modul grafic de funcionare al
modelului prin utilizarea unei anumite simbolistici pentru a reprezenta: procesele
(cercuri/elipse), fluxurile de date (sgei), fiierele (drepte paralele), furnizorii i
beneficiarii fluxurilor de date (dreptunghiuri).
Procesele din modelele funcionale reprezint de fapt operaiile din modelele
obiect i arat modul n care sunt legate obiectele din punct de vedere al funcionalitii
lor.
n cazul unei linii de asamblare, diagrama de flux de date la primul nivel de
rezoluie este redat n figura 7.10.
Definirea
posturilor i a
activitilor
Selectare
post
Parametrii
Posturi
Activiti
Alocare
activiti
candidate
Determinare
a activitilor
candidate
Activiti candidate
Recalcularea
momentelor 5
de ncepere
Fig. 7.10 Diagrama de flux a liniei de asamblare
Proiectarea orientat pe obiecte asigur o serie de faciliti i anume:

- independena claselor de obiecte;
- memorarea datelor i a metodelor prin care se realizeaz operaiile
asupra datelor;
- reutilizri multiple ale claselor;

-
utilizarea datelor ncapsulate cu prelucrrile doar de metodele clasei

respective;
Exist o complexitate a structurii datelor datorit procesului de ncapsulare;
pentru fiecare relaie datele pot fi interschimbate, adic se poate utiliza acelai tabel
pentru structuri de date diferite. Neredundana datelor i a metodelor este realizat
prin ncapsulare i respectiv prin motenire, permindu-se reutilizri multiple ale
acestora.
Proiectarea orientat pe obiecte are o serie de avantaje din care menionm:
- elimin neconcordanele ntre fazele de analiz, proiectare i
implementare, care apar frecvent n celelalte tipuri de proiectare;
- posibilitatea unor realizri multiple ale obiectelor i chiar a sistemelor
proiectate;
- asigur realizarea proiectului ntr-o perioad mai scurt i de calitate mai
bun, datorit concepiei bazate pe utilizarea obiectelor i nu a datelor;
- reduce la maximum dependena sistemului proiectat de mediul n care se
implementeaz;
- faciliteaz colaborarea ntre manageri, proiectani, specialiti, utilizatori
etc.
n ultima perioad, proiectarea bazat pe obiecte are o aplicabilitate practic
tot mai larg datorit acestor avantaje i a faptului c furnizeaz elementele de referin
necesare construirii unor proiecte complexe de conducere a sistemelor care apeleaz la
rezultatele de vrf ale informaticii.
7.3 Rolul specificaiilor logice n proiectarea fizic a sistemului
Proiectul logic obinut pe baz de model, componente sau obiecte trebuie
s rspund la urmtoarele cerine:
sistemul proiectat prin obiectivele sale s satisfac cererile
utilizatorului;
elementele din mediul sistemului surprinse n modelul logic trebuie
transmise cu corectitudine proiectului fizic.
Rezultatele proiectului logic cuprind o serie de recomandri privind:
- proiectarea fiierelor, a granielor n care funcioneaz sistemul, a
cheltuielilor necesare pentru realizarea proiectului fizic i a duratei
proiectului;
- tipul bazelor de date necesare, a programelor ce trebuiesc achiziionate,
a mijloacelor de codificare ce trebuiesc folosite pentru a asigura
securitatea datelor;
- tipul algoritmilor ce vor fi folosii pentru prelucrarea informaiilor din
bazele de date, astfel nct s fie atinse obiectivele i subobiectivele
sistemului;
- succesiunea temporal a unor operaii;
- modul de conversaie a programului cu utilizatorul;

- gradul de accesibilitate a meniurilor;
- instruirea utilizatorului.
Specificaiile logice trebuie s ndeplineasc mai multe condiii i anume:
- s concure la buna ntreinere i operare a sistemului cnd acesta este
implementat;
- s fie utile managerilor sistemului n instruirea personalului i n
planificarea funciilor;
- implementarea cu succes a sistemului depinde de descrierea corect a
funciilor logice din specificaie;
- evaluarea sistemului este determinat de exprimarea cerinelor
formulate de utilizator.
Specificaiile sistemului logic trebuie n plus s respecte urmtoarele
cerine:
- s fie clare i s aib o relaie valid cu modelul pe care l reprezint;
- s reprezinte complet modelele;
- s fie flexibile i uor implementabile.
Specificaiile logice reprezint un rezumat important al activitii de proiectare
logic a sistemului care reflect i viziunea analistului asupra sistemului investigat. Ele
se adreseaz conductorilor proiectului, proiectanilor precum i executanilor
simpli.
Specificaiile logice au drept scopuri:
- interpretarea datelor culese i a modelelor obinute ntr-o form utilizabil
i inteligibil, mai uor de neles, n vederea proiectrii sistemului n
funcie de structura i funcionarea logic a acestuia;
- exprimarea cerinelor analistului, managerilor, utilizatorilor i ale
proiectanilor sub forma unui portofoliu a muncii lor, care indic
personalitatea analistului (competen, calificare, instruire, ambiie);
- consolidarea i unificarea gndirii, a scopurilor i a opiniilor
participanilor prin armonizarea divergenelor care apar, n vederea
stabilirii direciilor de proiectare;
- comunicarea cerinelor i a scopurilor exprimate tuturor celor care au
responsabiliti n proiectarea noului sistem.
Importana specificaiilor rezult din rolul acestora n conducerea i
ntreinerea resursei informaionale: implementarea, funcionarea, conducerea i
evaluarea sistemului.
Implementarea sistemului const n punerea n practic a specificaiilor
logice i are n vedere:
- corelarea modulelor din punct de vedere a funciilor logice realizate
(invocri, utilizri);
- crearea interfeei dintre module conform standardelor de intrare/ieire;
- ordinea n care modulele sunt codificate, testate i implementate;

-
calitatea datelor i destinaia rapoartelor;

cerinele fiierelor i ale bazei de date (numr, coninut, tipuri de date,
tipuri de acces tipuri de nregistrri etc.);
- ordonanarea activitilor de implementare, instalare i de instruire
specifice sistemului considerat.
n timp ce specificaiile logice arat cum depind unul de altul elementele
sistemului, specificaiile fizice, obinute din cele logice n faza urmtoare, arat efectiv,
cum este realizat codificarea programelor, cum sunt create fiierele i rapoartele, cum
sunt preluate i conduse informaiile n cadrul sistemului. Proiectul fizic deriv direct
din specificaiile logice ale sistemului.
Funcionarea sistemului depinde de specificaiile logice, care evideniaz
anumite aspecte de natur logic ale funciilor sistemului (legturi ntre intrri i ieiri,
consideraii asupra volumului de date i a frecvenei lor, decizii de actualizare i de
ntreinere, modul de operare), precum i de specificaiile fizice care n mod cert sunt
mai importante pentru operatori.
Conducerea sistemului are n vedere preocupri care deriv tot din
specificaiile logice. Consideraiile referitoare la personal (definirea activitilor,
organigrama de structur a personalului pe departamente, standarde de performan
etc.), instruire (prioriti de instruire, tipul instruirii, succesiunea instruirii) i
planificare (prioriti de ntreinere i actualizare, participarea utilizatorilor, cerine de
avizare), depind n mod evident de structura logic a sistemului.
Interpretarea i transpunerea corect a specificaiilor logice pot s convearg
cu ateptrile scontate pentru viitor, n ciclul de via al noului sistem, referitoare la
ntreinere, noile interfee ale sistemului, realocarea de funcii n cadrul firmei etc.,
nsoite de reorganizarea corespunztoare i calificat de personal.
Evaluarea sistemului se face pe baza specificaiilor logice i fizice.
Specificaiile fizice au n vedere volumul, frecvena, acurateea i eroarea informaiilor.
Specificaiile logice conin rareori indicatori necesari pentru evaluarea sistemului, ns
arat modul n care sunt corelate elementele resursei de informare i evideniaz unde
i cnd funcioneaz aceste legturi.
De exemplu, dac specificaiile arat c prelucrarea poate s nceap numai
dup ce s-a strns un numr suficient de mare de facturi, acest fapt ne ajut s
observm ct de bine este satisfcut acest criteriu i cnd este rezonabil testarea
pentru prelucrarea facturilor.
De asemenea, detaliile legturilor logice, cum ar fi succesiunea de intrri-ieiri
sau de invocri de module, ne ajut s descoperim de unde provine ineficiena.
Utilizarea specificaiilor logice mbrac forme diferite n funcie de specificul
muncii persoanelor care le folosesc. Astfel:
managerul proiectului consider specificaiile logice ca pe nite standarde
care trebuie urmrite i care se completeaz odat cu implementarea fizic
i le utilizeaz ca s specifice structura obiectivelor de implementat.
Managerul de proiect vede specificaiile ca pe un document n continu
evoluie n timpul fazei de analiz, iar dup aceasta, ca pe un model
structurat de desfurare a muncii. Schimbarea specificaiilor necesit

acordul lui, iar costul crete dac schimbarea se produce ntr-un stadiu
mai avansat;
proiectantul sistemului le folosete pentru precizarea funciilor care
trebuie ndeplinite prin proiectare i a standardelor conform crora se
efectueaz i se evalueaz proiectarea. De asemenea, sesizeaz obiectivele
majore ale managementului resursei de informare i transform
specificaiile logice n specificaii fizice pe baza unei bogate experiene n
domeniul hard i soft;
implementatorii sistemului (analiti, programatori, instructori) le au n
vedere ntr-un mod independent de codificare i testare, pentru generarea
datelor de intrare i pentru obinerea scopurilor funcionale ale
procedurilor;
managerul de sistem le folosete pentru stabilirea responsabilitilor, a
standardelor logice ale performanelor i a procedurilor de verificare.
Managerul trebuie s menin sistemul n funciune avnd n vedere
specificaiile logice i fizice. El stabilete cine este responsabil, n ce mod
i pentru ce activitate, pentru a detecta eventualele erori i pentru a putea
evalua corect performanele sistemului.
ntreinerea resursei informaionale are n vedere o serie de activiti specifice
cum ar fi:
- creterea, prin crearea de noi elemente (de exemplu, adugarea de module
noi pentru testarea parolelor);
- restaurarea unor elemente (de exemplu, eliminarea posibilitilor de
intrare neautorizat n sistem prin implementarea unor parole hard);
- nlocuirea unor elemente cu altele mai performante (de exemplu,
includerea parolelor ntr-o subrutin mrind astfel viteza de acces);
- regenerarea unor elemente devenite inutilizabile (de exemplu, recrearea
tabelei de parole dac ea a devenit public).
Specificaiile logice sunt evaluate pe baza urmtoarelor criterii: claritate
(prevenirea unor interpretri incorecte), validitate (s se afle ntr-o relaie corect cu
resursa de informare i modelele pe care le dezvolt), completitudine fa de modele,
nivelul de organizare (concordan cu obiectivele sistemului), flexibilitate (o
schimbare n implementare s nu necesite reproiectarea lor), transparen pentru
utilizatori, uurina implementrii, multitudinea de variante prezentate cu evidenierea
aspectelor legate de cost-beneficii, mecanismul de alegere, efectul alegerilor etc.
Avizarea specificaiilor logice de ctre utilizator permite trecerea la etapa de
elaborare a proiectului fizic i necesit urmtorii pai: revizuirea proiectului n vederea
aprobrii coninutului specificaiilor (se face o prezentare cu mijloace audio-vizuale la
care particip utilizatorii, analitii, managerii), parcurgerea punct cu punct a
proiectului ntr-o edin tehnic la care particip numai proiectanii n vederea

nelegerii coninutului su, a gsirii i eliminrii erorilor, semnarea specificaiilor
logice de ctre executant i beneficiar n vederea demarrii proiectului fizic.
Specificaiile logice se adreseaz tuturor nivelelor implicate n procesul de proiectare a
sistemului i odat cu avizarea lor, lucrarea poate fi cosiderat ncheiat din punctul de
vedere al analistului. Aprobarea specificaiilor logice implic trei etape:
1) revederea critic a proiectului;
2) parcurgerea proiectului de ctre proiectani;
3) semnarea proiectului.
Proiectarea logic este independent de condiiile particulare ale problemei
rezolvate, ea nu ine seama de durata i succesiunea operaiilor, de formatul datelor
i al rapoartelor, de limbajul de programare utilizat. Proiectarea logic se execut
naintea celei fizice i prentmpin execuia unor proiecte fizice amnunite care
apoi s nu mai fie necesare.
7.4 Proiectarea fizic a sistemului
Proiectul fizic este cel ce precizeaz modul de rezolvare a proiectului logic,
respectiv:
- formatul datelor, adic modul de prezentare a datelor pentru utilizatori
n ceea ce privete intrrile, ct si ieirile (ecrane, formulare);
- forma rapoartelor;
- funciile administratorului bazei de date;
- fluxul fizic al sistemului;
- specificaiile de program, dac este cazul;
- dicionarul de date ce cuprinde numele cmpurilor de date, descrierea
acestor cmpuri i a regulilor de calcul, posibilele valori ale cmpurilor
i mrimea lor, tipurile de date i programele ce vor utiliza aceste date;
- specificaiile de sistem;
- ordonanarea n timp a desfurrii proiectului;
- controlul privind intrrile, comunicrile ntre date, memorarea datelor,
precum i prelucrrile asupra datelor pentru a obine ieirile dorite.
Legturile proiectrii logice cu proiectarea fizic sunt directe i se
realizeaz prin intermediul specificaiilor logice n urmtoarele domenii de
proiectare fizic: ecranele i formatele de intrare, rapoartele de ieire, bazele de
date, procedurile de securitate i control, procesoarele.
a) Proiectarea formularelor de intrare (input)
Proiectarea logic precizeaz sursa de informaii i structura logic a datelor
pentru fiecare proces. Pentru fiecare punct n care un flux de date intersecteaz
frontiera sistemului, proiectantul fizic are de creat un formular sau un format. Datele
intr n sistem prin intermediul unor documente, formulare sau terminale, structura
logic a datelor dictnd formatul fizic.
Proiectarea formularelor i a ecranelor se face pe baza respectrii principiilor

de structur (ecranele i formularele trebuie corelate logic pentru a satisface cerinele
de structur), transparen (completarea acestora trebuie s fie evident), simplitate
(codificrile simple sunt preferate celor complicate), "prietenie" (s ajute n cazul
apariiei unor erori).
b) Proiectarea raportului
Crearea unui raport folositor, care s informeze corect, este dificil deoarece
specificaiile logice corespunztoare sunt de regul incomplete, nu specific suportul
de raportare, ceea ce necesit eforturi suplimentare pentru ajustarea datelor la un
anumit suport.
Astfel, dac este disponibil un generator de rapoarte, proiectantul fizic este
limitat de formatul standard pentru tabele, iar dac raportul se codific manual,
proiectantul fizic poate s schimbe cerinele logice pentru a se ncadra mai bine n
pagin. De asemenea, rapoartele pe ecrane standard pot fi inhibate, iar proiectul logic
trebuie s conin comunicarea cu utilizatorul i unele funcii de control. Atunci cnd
sunt necesare suporturi de output speciale (imprimante, ecrane, dischete), acestea cresc
costul proiectului i reprezint decizii dificile de proiectare fizic, iar proiectarea logic
poate deveni infezabil.
c) Proiectarea bazei de date este un domeniu complex n care apar multe
probleme a cror rezolvare necesit decizii de proiectare fizic.
Managerul bazei de date este de obicei un program care controleaz
accesul la date n cadrul aplicaiei, scutind programatorii de necesitatea definirii
tipurilor i a structurii datelor n cadrul programelor. Managerul poate s permit
utilizatorilor s-i salveze unele probleme i soluiile de rezolvare a acestora pentru
reutilizare, editare, includere ntr-un raport, sau s le distribuie altor utilizatori
printr-o reea de pot electronic.
Administratorul bazei de date controleaz modul n care sunt definite
cmpurile, nregistrrile, fiierele i revizuiete aceste definiri mpreun cu
programatorii i cu analitii de sistem n vederea perfecionrii bazei de date.
Deoarece bazele de date sunt normalizate, redundana este minim i deseori
este eliminat necesitatea actualizrii programelor la fiecare schimbare a sistemului
fizic. Mediul bazei de date face de asemenea posibil accesarea direct a datelor de
ctre utilizatori, iar generatoarele de rapoarte fac legtura ntre cerinele logice i
limitele fizice ale sistemului.
Dei mediile bazelor de date sunt cel puin parial computerizate, conceptul de
control de date impus de un administrator de date poate fi folosit chiar n medii
manuale. Un aspect al acestuia l constituie managementul formularelor care are
preocupri privind coninutul, formatul, revizuirea i eliminarea formularelor
demodate, proiectarea i ntreinerea unui repertoar de formulare etc.
Un aspect final n proiectarea bazei de date include proiectarea sau
specificarea echipamentelor fizice necesare pentru stocarea i accesarea datelor
(discuri, dischete, benzi).

d) Proiectarea securitii i controlului
Pe msur ce fluxul de date intr, circul i apoi prsete sistemul,
consideraiile de frontier devin probleme de proiectare fizic i necesit:
- crearea i ntreinerea unei liste de pasword-uri i coduri de acces;
- dezvoltarea, ntreinerea i testarea unor planuri de restabilire manual i
automat a sistemului dup dezastre;
- elaborarea unor algoritmi simpli, robuti, uor de folosit pentru
ntreinerea integritii fiierelor;
- dezvoltarea unor proceduri care s asigure c datele nu pot fi accesate sau
folosite dect de cei care au acest drept etc.
Astfel de probleme reprezint scopurile unor subsisteme care pot fi proiectate
independent de obiectivele sitemului.
De exemplu, subsistemul de management al bazei de date, permite
administratorului bazei de date ca printr-un terminal on-line, s specifice i s
modifice domeniul de verificare a datelor de intrare.Deseori ns, cerinele fizice
specifice unui sistem pot s impun crearea i utilizarea unui subsistem unic de
securitate i control.
e) Proiectarea procesoarelor
Procesoarele sunt proceduri software sau manuale. Un procesor este
echivalentul fizic al unui proces logic i prin urmare, fiecare proces logic se va regsi
ca un procesor n cadrul proiectului fizic final al sistemului. Procesele pot fi din punct
de vedere logic identice ns procesoarele pot s difere foarte mult, de exemplu, din
punct de vedere al vitezei de prelucrare. Decizia de a avea un astfel de procesor se face
n timpul proiectrii logice, iar decizia referitoare la ce fel de procesor s se
construiasc, aparine proiectrii fizice i depinde de tehnologia existent, de timpul i
de banii disponibili.
Deoarece proiectarea logic nu poate s anticipeze cu precizie frecvena,
costul, volumul i viteza prelucrrii informaiilor, estimarea necesarului de echipament
nu se poate face numai pe baza ei, consideraiile reale aprnd n timpul proiectrii
fizice.
Dac implementarea sistemului este imposibil, exist dou alternative:
1) Anularea ntregii activiti, ceea ce conduce la pierderi de 10-15% din
bugetul proiectului (contravaloarea proiectului logic) sau mai mari, dac s-au
materializat mai din vreme unele decizii de proiectare fizic referitoare n special la
angajarea unor resurse care s-au dovedit inutile n timpul implementrii. Experiena
ctigat poate fi folosit n viitor pentru proiecte similare.
2) Refacerea proiectului logic ce se poate face prin:
- limitarea graniei de investigare la domeniile strict necesare pentru
implementare.
- reproiectarea logic a sistemului astfel nct implementarea s fie mult
mai practic.
- reverificarea proiectului logic pentru obinerea unor simplificri
funcionale, reducerea complexitii i mbuntirea structurii n scopul
evitrii unei proiectri fizice complexe, nerealizabile.
7.5 Managementul proiectului

Managementul proiectului vizeaz efortul grupului conductor de a realiza
produse viabile i n timp util, avnd n vedere funcionarea proiectului n medii
turbulente i cu resurse limitate. Analitii de sistem sunt de obicei conductorii
proiectului, ei fiind implicai n acest fel n toate fazele lui.
Managementul
proiectului presupune parcurgerea mai multor etape i anume: planificarea
proiectului; organizarea si conducerea lui; alocarea resurselor; analiza cost
beneficiu; controlul proiectului; redactarea documentaiei.
7.5.1 Planificarea, organizarea, conducerea i controlul proiectului
a) Planificarea proiectului implic selectarea proiectului din punct de
vedere financiar, uman, a resurselor tehnice, a manoperei, a timpului disponibil.
Planificarea resurselor financiare implic o estimare a costurilor directe
i indirecte n timp, deci o previziune a lor, ceea ce nu este ntotdeauna perfect
realizabil.
Planificarea resurselor umane pentru proiectare se realizeaz cu ajutorul
graficelor de tip GANTT pentru evaluarea efortului de analiz, proiectare,
programare, testare.
Planificarea resurselor tehnice ale unui proiect presupune programarea
hardului i softului necesar pentru realizarea lui (diagrame Gantt figura 7.11).
Faze de activiti
instruire
planificare faciliti
programare
selectare furnizori
raport intermediar
proiectare
analiz
planificare
Fig. 7.11 Diagrama Gantt
timp

Pentru o mai bun planificare i ordonanare (succesiune n timp i n
spaiu a activitilor ce stau la baza proiectului i estimarea timpului necesar
realizrii lui se poate folosi metoda drumului critic, stabilindu-se pentru fiecare
activitate termenul cel mai devreme i cel mai trziu de ncepere i de terminare,
inndu-se seama de condiionri.
Planificarea manoperei pentru proiect se face pornind de la diagramele de
structur a activitilor, a ntocmirii listei de activiti ce vor fi selectate i a
diagramei GANTT corespunztoare lor. Planificarea proiectului se ncheie cu
atribuirea activitilor la persoanele corespunztor calificate. Aceast atribuire
depinde de: a) mrimea proiectului; b) metodologiile utilizate; c) mijloacele
speciale solicitate; d) disponibilitatea resurselor aferente; e) timpul avut la
dispoziie; f) consideraii de testare i implementare a proiectului.
Planificarea timpului afectat proiectului se poate face n diferite moduri
sub form de matrici, de grafice GANTT innd seama de scopul i limitele
proiectului, de numrul de activiti din cadrul lui.
n esen planul proiectului cuprinde: a) obiectivul global; b) definirea
limitelor subobiectivelor; c) lista de activiti derivate din obiective; d) rezumatul
proiectului ce conine cererile de resurse, ipotezele asupra activitilor sistemului
proiectat n perioada de dezvoltare, testare, instalare, ntreinere; e) metodologiile
de dezvoltare a sistemului.
b) Organizarea i conducerea proiectului
Organizarea i conducerea proiectului se realizeaz prin rapoarte i
ntruniri.
Rapoartele se adreseaz subsistemului resursei informaionale i ele pot
evidenia progresele nregistrate n desfurarea proiectului comparnd rezultatele
planificate cu cele efectiv realizate.
ntrunirile au n vedere revizuirea proiectului logic i fizic al sistemului
proiectat. Aceste ntruniri se refer la analiza strii proiectului, la contactele cu
beneficiarii pentru actualizarea doleanelor lor, la prezentarea de demonstraii n
scopul revizuirii proiectrii logice i fizice a modulelor subsistemelor, pentru
instruirea utilizatorilor i familiarizarea lor cu eventualele schimbri survenite n
proiect.
ntrunirile se pot desfura ntr-o varietate de forme n timpul realizrii
proiectului i pot avea ca obiective:
analiza strii proiectului n vederea scrierii documentaiei;
informarea beneficiarului privind stadiul dezvoltrii proiectului, costurile

i termenele actuale, deciziile de proiectare care pot afecta costurile i
termenele;
aspecte de natur tehnic privind fazele de lucru i responsabilitile, n

special dac planul iniial al proiectului a fost schimbat;
prezentarea unor explicaii privind: constatri rezultate din investigare,

proiectarea logic i fizic, modulele, subsistemele i sistemele care au
fost realizate;
revizuirea unor aspecte tehnice ale proiectului;
instruirea utilizatorilor i familiarizarea lor cu eventualele modificri ale
sistemului;
semnarea documentelor i livrarea oficial a sistemului proiectat pentru
utilizatori.
c) Controlul proiectului
Este necesar un control al desfurrii proiectului, ntruct pot apare
schimbri pe parcursul lui. Metodele utilizate pentru a face fa la aceste schimbri
sunt: a) redirecionarea proiectului, b) diminuarea stagnrilor aprute, c)
conducerea ntreinerii proiectului ntr-o form viabil.
Controlul proiectului poate fi privit ca un sistem cu nvare n timp (figura
7.12).
n aceast figur se observ comportarea proiectului n timp i modificarea
planului proiectului, potrivit politicilor executate de subsistemul resursei
informaionale i de cel de conducere. Schimbrile se fac n funcie de plan i de
politici, urmrindu-se astfel o redirecionare a obiectivelor proiectului.
mediul
sistemului
percepere
schimbri
proiectul
activitilor
ieiri
monitorizarea
proiectului
ieiri
planificate
evaluarea
proiectului
schimbri
directive
proiectul de
luare a
deciziilor
planuri noi
proiectul
politicilor
Fig. 7.12 Sistemul de control al proiectului
Stagnrile proiectului au n vedere patru categorii de situaii:

1. Stagnri provocate de clieni, care apar datorit perturbaiilor din
mediu, iar sursele acestora nu pot fi ntotdeauna anticipate. n acest caz clienii pot
cere schimbri de specificaii ale proiectului sau de ordonanare a lui n timp.
2. Stagnri provocate de probleme de productivitate greit nelese. Ele
apar datorit faptului c planificarea softului este destul de rudimentar. Este
necesar s se fac o anticipare a productivitii de ctre conductorii proiectului.

Nu este permis o ncrcare excesiv a conductorilor proiectului sau o insuficient
instruire a lor, deoarece acestea pot afecta bunul mers al ntregului proiect.
3. Problema politicilor greit direcionate poate conduce la o abandonare
prematur a proiectului, o scdere a prioritii lui, o ntrziere a accesului la resurse
importante, o scdere a flexibilitii lui. n general problema politicilor trebuie s
cuprind semnale de avertizare, dar ele pot fi uneori incorect recepionate de
unitatea de resurs informaional.
4. O planificare greit poate conduce la apariia unei stagnri a
proiectului i ea poate fi generat de unele cauze cum ar fi: a) ntrzieri n livrarea
hardului; b) absenteismul personalului implicat; c) planificri necorespunztoare;
d) existena unor bugete fictive.
Exist patru abordri de care se poate ine seama pentru a micora aceste
stagnri:
1. Ignorarea lor. Aceast politic d rezultate n mediile placide, deoarece
controlul este plasat n feedback.
2. Redirecionarea conducerii prin excepie ncearc s corecteze
problemele referitoare la politicile inflexibile. Aceast cale de abordare d rezultate
bune n medii puternic perturbate. Problemele ce apar sunt sesizate nainte de a fi
grave, deci este posibil corectarea lor, dar n acest caz viteza de corecie trebuie s
fie foarte rapid.
3. Conducerea pentru meninerea proiectului implic, att cunoaterea
modului de funcionare a proiectului, ct i a metodei prin care acesta poate fi
pstrat ntr-o form viabil.
4. Schimbarea planului proiectului implic executarea acestei aciuni de
fiecare dat cnd apare o nou stagnare.
7.5.2 Managementul resurselor umane ale proiectului
Aceast activitate are n vedere urmtoarele aspecte:
cum se selecteaz personalul pentru proiectare;
cum se instruiete acest personal;
cum s se pun de acord motivaiile personalului cu proiectul la care
particip;
cum s direcionm i s controlm munca programatorilor.
Cele cinci componente ale managementului proiectului: planificarea,
organizarea, conducerea, direcionarea i controlul conin toate aceste aspecte ale
resurselor umane (fig.7.13).

Politici de instruire
Proiectarea muncii
Dezvoltarea sistemului
Metodologii
ORGANIZARE
PERSONAL
Selectarea, instruirea
si redistribuirea
personalului
Planificarea manoperei,
a calificarilor si a
proiectului
PLANIFICARE
DIRECTIONARE
Motivarea,
Atribuirea lucrarilor,
Leadership
CONTROL
Feedback
Mobilitatea personalului
Leadership
Fig. 7.13 - Aspecte ale resurselor umane n managementul proiectului
Selectarea personalului este condiionat de existena unor resurse umane

suficiente i se face n funcie de calificarea, de factorii de personalitate, precum i
de aptitudinile celor implicai n munca de proiectare, de coeziunea lor n cadrul
lucrului n echipe.
Motivaia i instruirea personalului sunt legate de construirea unui proiect
viabil i valid. Motivarea influeneaz comportamentul salariailor i este alctuit din
dou categorii de factori:
motive personale, interne, resimite ca expresie a nevoilor umane i care

pot genera anumite tensiuni;
stimulente sau factorii motivaionali, care sunt externe persoanelor i fac

parte din mediul de munc creat de manageri n scopul orientrii i
ncurajrii salariailor spre o munc eficient.
Sarcina managerului, n calitate de lider de proiect, este de a identifica i
activa motivele reale ale salariailor pe baza crora s proiecteze un sistem eficient de
motivare a personalului, n vederea asigurrii unei munci performante.
Instruirea trebuie s fac parte din planul de pregtire profesional i de
planificare a carierelor pe termen lung, liderul de proiect tiind ce instruire necesit
fiecare muncitor. Cursurile referitoare la tehnicile noi de dezvoltare a sistemelor,
limbajele de programare, management, contabilitate, finane .a. pot fi mai valoroase
pentru firm ns ele sunt vzute de salariai i ca recompense importante. Instruirea
motiveaz salariaii deoarece le asigur creterea accesului la tehnolgiile nalte care se
schimb rapid i pe care doresc s le cunoasc.
Conductorul proiectului trebuie s dovedeasc abilitate n sesizarea
feedback-ului performanelor, s aib acces la cele mai noi tehnologii, s

instruiasc personalul din subordine n raport cu schimbrile acestor tehnologii i
s asigure un climat favorabil desfurrii muncii n echip.
Asigurarea unei concordane a motivaiei personalului cu proiectul la
care particip. Mobilitatea conductorilor proiectului rezult din nivelul lor de
pregtire i din experienele lor anterioare. Proiectele pe termen scurt creeaz
uneori probleme ntre conductori i cei care particip la execuia lor, n sensul c
acetia din urm i vd ntrerupt continuitatea muncii lor. De aceea este necesar
explicarea importanei proiectului, a posibilitii valorificrii acestei experiene i
n alte proiecte viitoare. Direcionarea i conducerea diferitelor echipe de lucru nu
poate fi realizat dect de persoane care au cunotine la un astfel de nivel, care s
le permit realizarea unei coordonri eficiente.
Un alt aspect important al managementului resurselor umane l reprezint
modul n care trebuie s fie direcionat i controlat munca programatorilor.
Deoarece proiectele necesit ntr-o mare msur munc de programare este necesar i
important o revizuire a principiilor de management n special n ceea ce privete
supravegherea programatorilor.
n timp ce analitii descompun problemele n elemente i caut soluii prin
proiectarea unor structuri mai bune cu aceste elemente, programatorii elaboreaz
programe pe baza unor scheme logice i n consecin au nevoie de acces la tehnologia
de programare existent. Deoarece exist o ofert limitat de tehnologie, programatorii
sunt dornici s nvee i s o depeasc, nevoile de asociere ale programatorilor n
aceast competiie reducndu-se simitor. Din acest punct de vedere se poate spune c
un management bun al programatorilor trebuie s se concentreze asupra tehnologiilor
i s evite munca n echip a acestora. O alternativ ar fi ca managerii s-i ajute pe
programatori s dezvolte relaii profesionale ntre ei. Ambele puncte de vedere nu sunt
corecte deoarece managementul proiectului necesit att munca n echip ct i
expertize tehnice, n proporii pe care managerul de proiect dorete s le afle. n plus,
conform tendinei recente de implicare a utilizatorului n dezvoltarea propriului sistem,
liderul de proiect poate s determine personalul utilizatorului s lucreze pentru proiect
i chiar s-i acorde unele responsabiliti n executarea proiectului.
Dac se folosete tehnica prototipului, programatorii trebuie s fie
supravegheai, iar utilizatorul trebuie s fie instruit astfel nct s stpneasc concepte
de calculatoare i de programare care s-i permit s poarte discuii cu programatorii.
7.5.3 Analiza cost- beneficiu
Analiza cost- beneficiu ine seama de costurile directe i indirecte.
Costurile directe sunt legate de: volumul de munc necesar, de
achiziionarea sau nchirierea instrumentelor pentru proiectare neconsumabile (hard
si soft) i consumabile (hrtie, dischete, cerneal etc.), de dezvoltarea produsului
proiectat.
Costurile indirecte sunt cele mai puin vizibile i se refer la: costuri de
instruire a personalului care va utiliza proiectul, costuri de reinstruire periodic a
lui, costuri de publicitate, precum i costuri de promovare a personalului.
Costurile intangibile vizeaz costul instructorilor i a timpului n care
personalul i ntrerupe munca pentru a fi instruii, utilizarea suboptim n perioada
imediat dup instruire care reduce productivitatea i crete costurile, costurile de
oportunitate etc. Costurile intangibile (nemsurabile) trebuie s fie luate n calcul la
estimarea costului total al proiectului, care se face n cadrul raportului de investigaie
detaliat. De multe ori costurile intangibile sunt ignorate sau subestimate,
considerndu-se doar estimrile costurilor directe i a celor indirecte, fapt ce conduce
la diminuarea substanial a costului real al proiectului.
Costurile legate de diferitele faze ale proiectului sunt redate n schema din
figura 7.14.
n analiza cost beneficiu trebuie considerat i oportunitatea nfiinrii unui
departament informatic (subsistem al sistemului informaional) n funcie de:
costurile totale de nfiinare, beneficiul adus, de raportul cost-beneficiu .a.
costuri
proiectare
logic
proiectare implementare
fizic
meninere
timp
Fig. 7.14 Costurile legate de fazele proiectului
Analiza cost-beneficiu a proiectului se face innd seama de o serie de

indicatori i anume: valoarea net actual, rata de recuperare a investiiilor i
valoarea adugat.
Valoarea net actual reprezint diferena ntre beneficii i cheltuieli
corectat cu rata inflaiei. n cazul elaborrii unui proiect punctul de rentabilitate
apare n general dup doi ani.

Analiza costurilor trebuie s in seama de: momentul cnd vor fi
recuperate costurile proiectului, momentul n care va fi nregistrat cea mai mare
cheltuial, precum i de influena inflaiei asupra proiectului.
Rata de recuperare a investiiilor este cuantificat prin indicatorul care
arat rata de ctig pe toat perioada de exploatare a investiiei. Ea se compar cu
dobnda perceput de bnci, fr a introduce corecii de inflaie.
R = ( beneficiu - cost ) / cost
Dac indicatorul R este mai mic dect dobnda se renun la investiie.
Valoarea adugat de sistemul informaional la produsele firmei ine
seama de:
a). determinarea componentelor firmei i a modului cum sistemul
informaional afecteaz aceste componente;
b) ataarea la valoarea produsului a valorii provenite de la sistemul
informaional.
Valoarea produsului modificat de introducerea sistemului informaional
este legat de: fiabilitate, calitate, accesul la informaii, cheltuielile de
achiziionare i are un impact direct asupra fundamentrii deciziilor. n acest scop
se folosesc modele statice i dinamice.
Modelele dinamice, de tipul modelrii logice bazate pe inteligena
artificial sau de tipul tehnicii Delphi, au avantajul c fac predicii asupra modului
de luare a deciziilor i refac apoi aceste predicii pn se ajunge la soluii
acceptabile.
Analiza funciilor prin punctaje se utilizeaz pentru a evalua complexitatea
sistemelor informaionale prin atribuirea de punctaje pentru intrri, prelucrri i
ieiri.
Componentele de baz ale fundamentrii unei decizii economice referitoare la
continuarea sau nu a proiectului includ: costul total (fluxul de lichiditi bneti),
beneficiul total (consecinele), ratele de cost i beneficiu (rata de recuperare a
investiiei), precum i costurile i beneficiile intangibile (imaginea firmei, confortul n
utilizarea produsului, poziia i relaiile organizatorice).
n analiza costurilor trebuie s se in seama att de momentul n care
proiectul necesit cea mai mare cheltuial, ct i de momentul n care vor fi recuperate
cheltuielile totale actualizate n raport cu rata inflaiei.
Costurile i beneficiile proiectului urmeaz curbe diferite n timp i trebuie
corectate cu rata inflaiei pentru a putea fi comparate la momente specifice. n general,
beneficiile apar dup doi ani ns principala condiie care trebuie ndeplinit este ca
valoarea actual a beneficiilor s depeasc valoarea net actual a costurilor ntrun punct de rentabilitate cuprins ntre doi i cinci ani. Deseori o cerin mai restrictiv
este impus asupra intervalului n care apare punctul de rentabilitate.
a) Tehnica de analiz cost-beneficiu bazat pe valoarea net actual

Aceast tehnica consider numai costurile i beneficiile tangibile. Valoarea
net actual ne arat valoarea efectului n timp i totodat dac aceast valoare
depete costurile sau, cu alte cuvinte, dac banii sunt cheltuii eficient pentru a
obine beneficii.
Tehnica bazat pe valoarea net actual poate fi completat cu analiza
senzitivitii punctului de rentabilitate n funcie de cheltuielile specifice considerate.
Acest tip de analiz are n vedere eficacitatea investiiei i poate s rspund
unor probleme de risc cum ar fi:
stabilirea perioadei n care vor fi recuperate costurile proiectului pentru o
rat a inflaiei dat;
care este rata inflaiei pentru recuperarea costurilor proiectului ntr-o
anumit perioad;
n ce moment i care este cheltuiala maxim necesar nregistrat;
implicaiile estimrii incorecte a inflaiei asupra proiectului.
Exemplu:
S considerm un proiect pentru care costurile de proiectare sunt estimate la
120 000$ n primul an, la 80 000$ n anul doi, iar n anii urmtori celelalte costuri sunt
de 10 000$ pe fiecare an. Producia va ncepe n anul doi, cu beneficii estimate la 40
000$ pentru acest an i la 90 000$ n fiecare an, ncepnd din anul trei.
Considernd o rat anual de devalorizare a dolarului de 5%, tehnica de
analiz cost-beneficiu bazat pe valoarea net actual cumulat indic un punct de
rentabilitate n anul cinci pentru proiectul analizat (tabel 7-1).
Aceste rezultate indic faptul c proiectul prezint o valoare pozitiv a
profitului cumulat ncepnd cu anul cinci al ciclului de dezvoltare, fiind ineficient n
primii patru ani.
Tehnica bazat pe valoarea net actual poate fi completat cu analiza
senzitivitii punctului de rentabilitate n funcie de cheltuielile specifice considerate.
Acest tip de analiz are n vedere eficacitatea investiiei i poate s rspund
unor probleme de risc cum ar fi:
stabilirea perioadei n care vor fi recuperate costurile proiectului pentru o

rat a inflaiei dat;
care este rata inflaiei pentru recuperarea costurilor proiectului ntr-o

anumit perioad;
n ce moment i care este cheltuiala maxim necesar nregistrat;
implicaiile estimrii incorecte a inflaiei asupra proiectului.

Valoarea net actual cumulat a proiectului
Tabel 7.1
An
Costuri
Beneficii
Valoare
net
Rat
devalorizare
5%
Valoare
actual
Valoare
actual
cumulat
120 000
-120 000
0,9500
-114 000
-114 000
80 000
40 000
-40 000
0,9025
-36 100
-150 100
10 000
90 000
80 000
0,8573
68 684
-81 516
10 000
90 000
80 000
0,8145
65 160
-16 356
10 000
90 000
80 000
0,7737
61 896
45 540
10 000
90 000
80 000
0,7351
58 808
104 348
10 000
90 000
80 000
0,6983
55 864
160 212
Spre exemplu, s presupunem o ntrziere a lucrrilor proiectului n primul an,

n valoare de 20 000$, care se vor executa n anul urmtor n care preurile produselor
realizate vor scdea, iar beneficiul va fi redus cu 10 000$. De asemenea, printr-o
suplimentare anual a cheltuielilor de perfecionare i reclam cu 10 000$ se estimeaz
obinerea unui beneficiu anual suplimentar de 30 000$. Rezultatele obinute pentru
acest caz sunt ilustrate n tabelul 7.2.
Valoarea net actual cumulat a proiectului cu ipoteze modificate
Tabel 7.2
An
Costuri
Beneficii
Valoare
net
Rat
devalorizare
5%
Valoare
actual
Valoare
actual
cumulat
100 000
-100 000
0,9500
-95 000
-95 000
100 000
30 000
-70 000
0,9025
-63 175
-158 175
20 000
120 000
100 000
0,8573
85 730
-72 445
20 000
120 000
100 000
0,8145
81 450
9 005
20 000
120 000
100 000
0,7737
74 370
86 375
20 000
120 000
100 000
0,7351
73 510
159 885
20 000
120 000
100 000
0,6983
69 830
229 715
Din rezultatele prezentate n tabelul 7.2 se observ c ipotezele fcute au

condus la devansarea punctului de rentabilitate cu un an mai devreme, ns valoarea
maxim nregistrat a cheltuielilor a crescut la 158 175$ n anul doi i a sczut pentru
ceilali ani.
b)Tehnica de analiz cost-beneficiu bazat pe eficiena cheltuielilor
Aceast tehnic are n vedere eficiena cheltuielilor ocazionate de realizarea
proiectului, care se poate cuantifica astfel:
(Beneficiu - Cost) / Cost > Rp
unde, indicatorul Rp reprezint valoarea predeterminat pentru rata de recuperare a
investiiei.
Dac banii pot fi cheltuii mai eficient n alte moduri, atunci este posibil s se
renune la finanarea investiiei privind realizarea proiectului.
n general, analitii ncearc s stabileasc dac fondurile necesare pentru
realizarea unui proiect conduc la creterea beneficiilor cu eficien maxim, pe baza
comparaiilor cu dobnzile bancare, cu rata de recuperare a investiiilor pentru proiecte
similare, sau cu rata general de recuperare a investiiilor la nivel de firm pe o
anumit perioad din trecut.
Spre exemplu, rata de recuperare a investiiei pe primii cinci ani, pentru primul
caz, se calculeaz astfel:
R = (310 000 - 230 000) / 230 000 0,345
iar rata de recuperare anual a investiiei Ri, va fi:
Ri = (1,345)1/5 - 1 0,0611
Cu alte cuvinte, investind fondurile cu cel puin 6,11% se poate asigura o
utilizare eficient a acestora pe perioada de cinci ani.
Desigur, extinderea perioadei poate s schimbe valoarea acestui indicator.
Astfel, pentru o perioad de ase ani, se obine:
R = (400 000 - 240 000) / 240 000 0,66
iar rata anual de recuperare a investiiei va fi:
Ri = (1,66)1/6 - 1 0,0881
sau de 8,81% profit anual pe perioada de ase ani.
Deoarece majoritatea proiectelor bazate pe soft au o via real util de 3-6
ani, decizia conducerii n ceea ce privete eficiena acestei investiii va fi dificil.

Dac banii pot fi cheltuii mai eficient n alte moduri, atunci este posibil s se
renune la finanarea investiiei privind realizarea proiectului.
n general, analitii ncearc s stabileasc dac fondurile necesare pentru
realizarea unui proiect conduc la creterea beneficiilor cu eficien maxim, pe baza
comparaiilor cu dobnzile bancare, cu rata de recuperare a investiiilor pentru proiecte
similare, sau cu rata general de recuperare a investiiilor la nivel de firm pe o
anumit perioad din trecut.
c) Tehnica de analiz cost-beneficiu bazat pe valoarea adugat
O alt abordare se bazeaz pe analiza valorii adugate care examineaz
diagramele fluxurilor de date i ncearc s determine valoarea specific pe care o
adaug sistemul informaional la produsele firmei n fiecare pas de prelucrare. Valorile
specifice adugate se refer la creterea vitezei, o mai mare acuratee, creterea
ncrederii n deciziile luate, reducerea erorilor i mbuntirea calitii datelor,
creterea vitezei de acces la mai multe date etc.
Conceptul de valoare adugat are n vedere urmtoarele aspecte:
determinarea componentelor care dau valoare produselor firmei i a
modului n care resursa informaional le poate influena;
atribuirea unor valori n funcie de intensitatea acestor influene i
calcularea valorii adugate datorate schimbrilor n resursa
informaional.
Un sistem informaional adaug valoare, fie dac prin prelucrarea
informaiilor pe care le primete din mediu le crete sau le maximizeaz calitatea,
acurateea, oportunitatea, consistena, completitudinea i gradul de ncredere, fie dac
poate s faciliteze accesul clientului la fiecare produs, schimbul efectiv (produsul s fie
complet controlat de ctre client) i ntreinerea produsului.
Sistemul informaional are implicaii directe i n procesele de control i de
fundamentare i luare a deciziilor, cu consecine pozitive n procesul de management.
El ajut la identificarea i definirea mai precis a problemelor i a contextului n care
trebuie adoptate deciziile, precum i n activitile predecizionale de motivare a
deciziilor i de stabilire a regulilor i a procedurilor de luare a deciziilor. Sistemul
faciliteaz colectarea datelor i dezvoltarea modelelor statice i dinamice, utilizate att
ca suport pentru proiectare ct i pentru evaluarea i selectarea alternativelor.
Un rol important l are n elaborarea deciziilor, n realizarea aciunilor
selectate, n evaluarea eficacitii alternativelor selectate i a procesului general de
luare a deciziilor.
Valoarea total adugat depinde de evaluarea probabilistic a fiecrei faze a
proceselor. n esen, abordarea prin valoarea-adugat const n examinarea
diagramei fluxului de date i stabilirea unei pri din valoarea total adugat pentru
fiecare proces pe baza unor probabiliti, care depind de experiena i intuiia
analistului privind comportamentul datelor i al oamenilor.
Datorit naturii lor intuitive, calculele valorii-adugate sunt reluate frecvent n
timpul proiectrii logice. n fazele de nceput se folosesc doar diagrame de nivel nalt
i se fixeaz cifre brute pentru fiecare proces, care se rafineaz n timpul proiectrii
odat cu procesele.
Aceast abordare poate fi utilizat n toate fazele proiectrii logice i nu se
limiteaz doar la proiectarea unei fezabiliti economice iniiale.
Observaii:
Abordrile valoare-adugat i cost-beneficiu sunt dou modaliti diferite de
a calcula valoarea unui proiect; teoretic, ele reflect aceeai realitate, ns practic ele
joac roluri diferite.
Analiza cost-beneficiu se folosete la nceputul activitii de proiectare. Odat
cu creterea complexitii proiectelor este din ce n ce mai dificil s se fac estimri
rezonabile ale costurilor i beneficiilor, n special ale celor intangibile care devin din ce
n ce mai importante.
Abordarea valoare-adugat depinde de asemenea ntr-o oarecare msur de
imprecizia acestor cifre, ns ea nu se bazeaz pe costurile proiectului n sine, ci se
concentreaz asupra analizei raionale a proiectului, inspectnd proiectul logic i
presupunnd c problemele tehnice sunt rezolvabile. n felul acesta este mai oportun
i mai puin "pseudo-precis".
Conceptul de valoare-adugat poate fi combinat cu o analiz cost-beneficiu
pentru a demonstra c anumite aspecte ale efortului de proiectare nu merit s fie
fcute sau, dimpotriv, vor avea beneficii importante.
Analiza valorii-adugate se
concentreaz de asemenea asupra tranzaciilor dintre subsisteme, analiza economic
cost-beneficiu tinznd s fie ignorat.
n timpul fazelor de proiectare fizic se pot introduce corecii ale costurilor i
se pot examina n detaliu procesele pentru a asocia cifre mai exacte prilor care au
constituit cauza erorilor.
Valoarea unei investiii, pentru proiecte de complexitate crescut, poate s fie
modificat i n funcie de consecinele pe care le are asupra unor factori cum ar fi:
imaginea firmei, poziia firmei pe pia, eficiena conducerii, calitatea i organizarea
muncii, profesionalismul, relaiile cu salariaii, furnizorii i beneficiarii etc.
7.5.4 Elaborarea documentaiei proiectului
La terminarea fiecrei faze de dezvoltare a proiectului, directorul de proiect
redacteaz un raport care detaliaz activitile, constatrile i rezultatele acelei faze,
precum i planurile pentru fazele urmtoare, document ce va fi supus spre avizare de
ctre beneficiar.
Documentaia se elaboreaz la momente specifice n timpul realizrii
proiectului, fie ca urmare a directivelor managerului, fie conform cu prevederile
metodologiilor de dezvoltare utilizate, care n general sunt proceduri bazate pe
documentaie.
Documentaia poate fi considerat ca un fiier de istoric a ceea ce s-a fcut i
s-a ntmplat n timpul realizrii proiectului.

Aceast activitate are urmtoarele obiective:
stabilirea obligaiilor contractuale pentru clieni;
alctuirea unei puni de comunicare ntre fazele proiectului;
punerea de acord a clienilor cu cerinele unitii informaionale;
asigur parcurgerea pailor stabilii prin metodologia de proiectare a
sistemului;
stabilirea unei proceduri de proiectare i evaluare a performanelor
proiectului.
Documentaia de proiectare poate fi reprezentat prin hri de flux, hri de
structur, raportul de investigaie preliminar, specificaii logice care constitue
puncte de reper n caz de avarie. Documentaia proiectului ca sistem de conducere
este redat n figura 7.15 /45/.
n mod obinuit, documentaia proiectului, exceptnd unele metodologii
speciale de dezvoltare a sistemului, trebuie s conin:
- cererile pentru servicii;
- sumarul proiectului (domeniu, restricii, obiective);
- planul proiectului iniial, a celui revizuit i analiza cost-beneficiu;
- proiectul logic al sistemului (investigarea preliminar i detaliat,
modelele de baz i specificaile logice);
- proiectul fizic al sistemului (sistemul de programe i diagramele de
structur);
- documentaia de testare (datele i procedurile de testare);
- documentaia sistemului (ghidul utilizatorului, manuale de referin de
instalare i de ntreinere);
- specificaii privind dimensionarea sistemului;
- specificaii privind intrrile/ieirile sistemului (ecrane, documente,
rapoarte, fiiere);
- documentaia pentru administratorul bazei de date;
- proceduri de evaluare a sistemului;
- cereri de oferte privind achiziionarea de soft i hard;
- formulare pentru avizarea final.
Utilizator
Cereri
procedurale
Cereri pentru
servicii
Proiectare Cereri Proiectare

logice
logic
fizic
4 Documentare
Achiziie
hard
hard
6
Implemen
-tare i
instalare
Manuale
de operare
Cerinele
utilizatorul
Utilizator
3
Dezvoltare
proceduri
Cereri
pt
dezvoltare
i
procurare
soft
Msuri
tehnice
Utilizator
Fig. 7.15 Sistemul de redactare a documenaiei proiectului
Documentele elaborate la terminarea fazelor include i un raport final care

conine:
1) Sumarul proiectului n care se specific cheltuielile, produsele livrate i unele
consideraii de conducere a proiectului;
2) Starea execuiei proiectului prin care se indic: starea operaional a
componentelor proiectului; activitile ce trebuie executate n continuare;
rezultatele testrii; necesitatea continurii finanrii unitii de resurse
informaionale;
3) Precizri privind modul de funcionare a proiectului: cerine de actualizare;
estimri de eficien i eficacitate;
4) Terminarea proiectului implic: redistribuirea personalului; evaluarea eficienei
proiectului; consideraii privind arhivarea lui; consideratii de marketing n
scopul vnzrii proiectului i la ali beneficiari.
Prezentarea proiectului trebuie fcut ntr-un climat favorabil, cu
participarea prilor implicate i a clienilor. Se vor prezenta probleme de interes
major pentru utilizatori i perspectivele proiectului. Utilizarea unor mijloace
atractive de prezentare i distribuirea documentului final naintea ntrunirii
contribuie la succesul prezentrii i avizrii proiectului.
Etapa de proiectare constitue nucleul cel mai important din ciclul de via
al sistemului, n care se pune n eviden pe de o parte, nelegerea critic a
funcionrii sistemul i, pe de alt parte, creativitea echipei de analiti n vederea
nbuntirii performanelor lui viitoare. Fazele de testare i implementare vor
confirma validitatea soluiilor de proiectare propuse.

Capitolul 7 Procesul de Proiectare in Analiza Si Diagnoza Sistemelor

Încărcat de

Informații document

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

Capitolul 7 Procesul de Proiectare in Analiza Si Diagnoza Sistemelor

Încărcat de

Drepturi de autor:

Formate disponibile

7

Procesul de proiectare n analiza

Procesul de proiectare constitue una din cele mai importante etape n

Analiza, diagnoza i evaluarea sistemelor din economie

respectarea principiului major al proiectrii n sensul c sistemul se

Procesul de proiectare n analiza i diagnoza sistemelor

utilizatorului, precum i crearea unei stri de confort operatorului n timpul folosirii

Analiza, diagnoza i evaluarea sistemelor din economie

Procesul de proiectare n analiza i diagnoza sistemelor

Putem defini prototipul ca o versiune a produsului final, care este succesiv

Analiza, diagnoza i evaluarea sistemelor din economie

Fig.7.1 Procesul de elaborare a prototipului

Principalele tehnici utilizate pentru construirea de prototipuri sunt:

Procesul de proiectare n analiza i diagnoza sistemelor

e) tehnica bazat pe limbaje de specificaii executabile este orientat pe

Baza de date a firmei

Fig. 7.2 Dezvoltarea softului pentru utilizatorul final

Analiza, diagnoza i evaluarea sistemelor din economie

Procesul de proiectare n analiza i diagnoza sistemelor

extrinsec, cnd accesul la date se face dup o regul independent de

Analiza, diagnoza i evaluarea sistemelor din economie

7.2.3 Proiectarea logic orientat pe obiecte

Procesul de proiectare n analiza i diagnoza sistemelor

Proiectarea orientat pe obiecte are la baz analiza i modelarea pe obiecte

Fig. 7.3 Crearea unui ordin de plat n analiza clasic

Fig. 7.4 Crearea unui ordin de plat n analiza structurat

Analiza, diagnoza i evaluarea sistemelor din economie

Procesul de proiectare n analiza i diagnoza sistemelor

colaboratorii utilizai de clas. n cadrul unor reuniuni la care particip proiectani,

Responsabilitatea reprezint o activitate pe care trebuie s o fac un obiect

Fig. 7.7 Clase cu acelai contract

Analiza, diagnoza i evaluarea sistemelor din economie

clas client si server

Fig. 7.8 Clas cu mai multe contracte i clas client i server

Subsistemele conin grupuri de clase cu responsabiliti diferite care

Fig. 7.9 Subtipuri de clase n interiorul unei clase

Procesul de proiectare n analiza i diagnoza sistemelor

Modelul funcional este caractristic fazei de proiectare, iar construirea lui

Fig. 7.10 Diagrama de flux a liniei de asamblare

Proiectarea orientat pe obiecte asigur o serie de faciliti i anume:

Analiza, diagnoza i evaluarea sistemelor din economie

utilizarea datelor ncapsulate cu prelucrrile doar de metodele clasei

Procesul de proiectare n analiza i diagnoza sistemelor

- modul de conversaie a programului cu utilizatorul;

Analiza, diagnoza i evaluarea sistemelor din economie

calitatea datelor i destinaia rapoartelor;

Procesul de proiectare n analiza i diagnoza sistemelor

structurat de desfurare a muncii. Schimbarea specificaiilor necesit

Analiza, diagnoza i evaluarea sistemelor din economie

Procesul de proiectare n analiza i diagnoza sistemelor

Proiectarea formularelor i a ecranelor se face pe baza respectrii principiilor

Analiza, diagnoza i evaluarea sistemelor din economie

Procesul de proiectare n analiza i diagnoza sistemelor

7.5 Managementul proiectului

Fig. 7.11 Diagrama Gantt

Analiza, diagnoza i evaluarea sistemelor din economie

analiza strii proiectului n vederea scrierii documentaiei;

informarea beneficiarului privind stadiul dezvoltrii proiectului, costurile

aspecte de natur tehnic privind fazele de lucru i responsabilitile, n

Procesul de proiectare n analiza i diagnoza sistemelor

prezentarea unor explicaii privind: constatri rezultate din investigare,

Fig. 7.12 Sistemul de control al proiectului

Stagnrile proiectului au n vedere patru categorii de situaii:

Analiza, diagnoza i evaluarea sistemelor din economie