Capitolul 7 Procesul de Proiectare in Analiza Si Diagnoza Sistemelor

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;

7

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


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 ?


Identificaspecificatiifunctionale

1

Planprototip

ANALIST

2

ANALIST

Rafineazaprototip

A PROIECT LOGIC

Criterii deproiectare

Schimbari Specificatii

Specificatii-prototipBDatePrototip

Specificatii

3 44

UTILIZATORANALISTANALIST

5

UTILIZATORANALIST

Avizare

UTILIZATORCerinte

Caracteristiciprototip

Comentariicritice

Caracteristici noi

Comentarii-critici

Specificatii finale

PROGRAMATORI

Specificatiifinale

Dispunede

prototip

Finalizareprototip

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 Utilizare instru-

mente de dezvoltare

1

Interpretare specificaii

2

Apeleaz la IRU pentru

3

A Specificaii utilizator

Utilizator

cerere asisten

specificaii

specificaii

specificaii specificai

Specificaii

Specificaii

vechi

noi

Rezultate

B Baza de date a firmei

Utilizator Utilizator

Comentarii

Programare IRU

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 "bottom-up" (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

selectare furnizor

creare ordin

de plat

Fig. 7.3 Crearea unui ordin de plat n analiza clasic

ordin de plat furnizor

produs

livreaz pentru

merge la

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.

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

cerin creare

trimitere

completare ateptare

expirat

anulare plat

revizuire

plat amnat arhivare

Fig. 7.5 Diagram de tranziie a strilor pentru crearea ordinului de plat


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

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

contract

Fig. 7.6 Contractul unei clase deservite de server

client

client

server

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

Din exterior nu exist diferene ntre subsistem i clas, ele sunt obiecte ncapsulate i au contracte pentru a furniza un serviciu cerut.

server

clas

client clas client si server

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

clas clas clas

subsistem 2

subsistem 1

Fig. 7.9 Subtipuri de clase n interiorul unei clase


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

Parametrii

Definirea posturilor i a activitilor

1 Selectare post 2

Determinarea activitilor

candidate3

Alocare activiti candidate

4

Recalcularea momentelor de ncepere

5 Activiti candidate

Activiti

Posturi

Fig. 7.10 Diagrama de flux a liniei de asamblare


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

I F M A M

instruire

programare selectare furnizori

raport intermediar

planificare

Faze de activiti

timp

analiz proiectare

planificare faciliti

Fig. 7.11 Diagrama Gantt


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.

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.

mediul sistemului

monitorizareaproiectului

evaluarea proiectului

ieiri ieiri

percepere schimbri schimbri

proiectul activitilor

proiectul de luare a

deciziilor

proiectul politicilor

directive planuri noi

planificate

Fig. 7.12 Sistemul de control al 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).


ORGANIZAREPERSONAL

DIRECTIONARE

CONTROL

PLANIFICARE

Planificarea manoperei,a calificarilor si a

proiectului

Politici de instruireProiectarea munciiDezvoltarea sistemuluiMetodologii

FeedbackMobilitatea personaluluiLeadership

Motivarea,Atribuirea lucrarilor,Leadership

Selectarea, instruireasi redistribuireapersonalului

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.

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.

proiectare logic

proiectarefizic

implementare meninere timp

costuri

Fig. 7.14 Costurile legate de fazele proiectului


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 ntr-un 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

1 120 000 0 -120 000 0,9500 -114 000 -114 000

2 80 000 40 000 -40 000 0,9025 -36 100 -150 100

3 10 000 90 000 80 000 0,8573 68 684 -81 516

4 10 000 90 000 80 000 0,8145 65 160 -16 356

5 10 000 90 000 80 000 0,7737 61 896 45 540

6 10 000 90 000 80 000 0,7351 58 808 104 348

7 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

1 100 000 0 -100 000 0,9500 -95 000 -95 000

2 100 000 30 000 -70 000 0,9025 -63 175 -158 175

3 20 000 120 000 100 000 0,8573 85 730 -72 445

4 20 000 120 000 100 000 0,8145 81 450 9 005

5 20 000 120 000 100 000 0,7737 74 370 86 375

6 20 000 120 000 100 000 0,7351 73 510 159 885

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


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.

Utilizator

Proiectare logic Proiectare fizic

1 2

Cereri pentru servicii

Cereri logice

Cereri procedurale

Documentare hardAchiziie

hard

4 Implemen

-tare i instalare

6

Manuale de operare

Utilizator

Cerinele utilizatorul

Utilizator Cereri

ptdezvoltare

i procurare

soft

5 Msuri tehnice

Fig. 7.15 Sistemul de redactare a documenaiei proiectului

3 Dezvoltare proceduri

CAPITOLUL 7 - Procesul de proiectare n analiza i diagnoza sistemelor7.1 Obiectivele i principiile proiectrii7.2 Proiectarea logic n analiza i diagnoza sistemelor7.2.1 Proiectarea logic bazat pe model7.2.2 Proiectarea logic bazat pe componente7.2.3 Proiectarea logic orientat pe obiecte

7.3 Rolul specificaiilor logice n proiectarea fizic a sistemului7.4 Proiectarea fizic a sistemului7.5 Managementul proiectului7.5.1 Planificarea, organizarea, conducerea i controlul proiectului7.5.2 Managementul resurselor umane ale proiectului7.5.3 Analiza cost- beneficiu7.5.4 Elaborarea documentaiei proiectului

Date post:	08-Jan-2016
Category:	Documents
Upload:	george-bogdan
View:	12 times
Download:	0 times

Capitolul 7 Procesul de Proiectare in Analiza Si Diagnoza Sistemelor

Documents