Sunteți pe pagina 1din 32

SISTEME INFORMATICE DE GESTIUNE

Unitatea de nvare 1

Tipologia,arhitecturasi
proceselededezvoltare
asistemelor
informaticedegestiune

1.1 Obiectivele unitii de nvare


1. Dobndirea cunotinelor privind tipologia i arhitectura sistemelor informatice de
gestiune.
2. nsuirea noiunilor teoretice fundamentale aferente proceselor de dezvoltare a
sistemelor informatice de gestiune.
3. Dobndirea cunotinelor privind modele ale procesului de dezvoltare.
4. Dobndirea cunotinelor despre metodele de proiectare a sistemelor informatice de
gestiune i evoluia acestora.
5. nsuirea principiilor de baz aplicabile n realizarea sistemelor informatice de
gestiune.

1.2 Tipologia i arhitectura sistemelor informatice de


gestiune
1.2.1 Sisteme informaionale i sisteme informatice
Sistemul informaional al organizaiei cuprinde:
ansamblul de informaii organizate;
evenimentele care au efecte asupra acestora;
persoanele care acioneaz asupra informaiilor sau le utilizeaz cu finaliti de

gestiune;
procedurile urmate;
resursele puse n lucru.

Sistemul informaional face obiectul crerii, modificrii, managementului, auditrii, ca


orice alt component a organizaiei i poate fi evaluat din perspectiva contribuiei pe care o
are la atingerea obiectivelor acesteia.
Sistemul informatic de gestiune reprezint o soluie informatic pentru sarcinile,

lucrrile, problemele (unei poriuni a) sistemului informaional, apt de a funciona pe o


anumit platform (o configuraie de echipamente i software de exploatare i gestionare
a acestora), folosind un anume software de aplicaie.

Figura Error! No text of specified style in document..1 Sistemele informatice de gestiune i


sistemul informaional al organizaiei

1.2.2 Relaia dintre sistemul informaional i sistemul informatic de


gestiune
1. sistemul informatic de gestiune are rolul de infrastructur a
sistemului informaional: setul de informaii ce fac obiectul prelucrrii i
memorrii, procedurile i procesele urmate, personalul implicat sunt n
totalitate determinate de sistemul informaional, fiind expresia modului specific
n care acesta i ndeplinete funciile n cadrul organizaiei; sistemul informatic
de gestiune nu face dect s asigure funcionarea sistemului informaional n
aceti parametri;
2. sistemului informaional al organizaiei comunic cu sistemele
informatice de gestiune, crora le transmite informaii i solicitri i de la
care primete rezultate, pe care le ncorporeaz i le utilizeaz mai departe;

3. sistemele informatice comunic ntre ele, transmindu-i reciproc date i


solicitri;
4. particularitile tehnice de funcionare a sistemelor informatice antreneaz
inserarea n sistemul informaional a unor prelucrri specifice, dintre
care cele mai frecvente sunt procedurile de asigurare a proteciei,
confidenialitii i securitii datelor;

5. tehnologiile folosite n sistemele informatice pot aduce noi


potenialiti i oportuniti pentru organizaie, ceea ce determin

schimbri la nivelul proceselor de gestiune i, inevitabil, ale sistemului


informaional, unul dintre cele mai relevante exemple de acest tip fiind
comerul electronic n toate formele sale;
6. software-ul de baz i configuraia de echipamente folosite de sistemele
informatice pot fi comune sau diferite, parial sau n totalitate; cu alte cuvinte,
sistemele informatice de gestiune funcioneaz pe platforme omogene sau
eterogene, ceea ce ridic o problem suplimentar, aceea a tranzitrii datelor
i a solicitrilor de la o platform la alta;

7. sistemul informaional evolueaz pentru a rspunde schimbrilor survenite


n organizarea i realizarea activitilor din organizaie, a modificrilor n
orientrile strategice i de management etc; aceast evoluie antreneaz fie
modificri i adaptri corespunztoare ale sistemelor informatice de gestiune
aflate n funciune, fie nlocuirea acestora cu altele noi, corespunztoare noilor
cerine;
8. sistemele informatice trebuie s se adapteze la evoluia platformei
sau platformelor noi generaii i versiuni ale sistemului sau sistemelor de
operare, ale sistemului sau sistemelor de gestiune a bazelor de date, nlocuirea
unor echipamente, modificri n configuraia sistemelor de comunicaie.
Aceast adaptare nu trebuie s fie sesizabil de ctre sistemul informaional al
organizaiei dect ca o mbuntire a performanelor de exploatare, fr a
afecta funcionalitile i coerena datelor deja memorate.

1.2.3 Managementul afacerii i tehnologia informaiei


n prezent, u n avantaj concurenial semnificativ este asigurat prin utilizarea unui
puternic suport informaional, bazat pe cele mai noi instrumente ale tehnologiei informaiei
(TI).
Modul de desfurare a afacerii n cadrul oricrei organizaii este influenat prin
aciunea conjugat a mai multor factori, cum ar fi:
globalizarea;
competiia de nivel nalt;
informaia, devenit resurs organizaional cheie;
derularea activitii n condiiile companiei virtuale;
comerul electronic;
existena, n cadrul firmei, a personalului specializat n procesarea datelor i
analiz (knowledge worker);
un nou tip de relaie cu banca, prin care se obin servicii i produse noi, ca
urmare a promovrii noilor soluii TI etc.
TI ofer soluii pentru reingineria modului de organizare a afacerii cu scopul meninerii
competitivitii.
Reingineria presupune regndirea i reproiectarea proceselor d e afaceri, pentru
obinerea de mbuntiri substaniale privind costurile, calitatea, viteza de reacie a
decidenilor. Reingineria aplicat modului de a face afaceri este influenat i gsete,
totodat, rspunsuri n noile soluii TI.

n elaborarea strategiei de afaceri este necesar asimilarea urmtoarelor premise:


n conducerea i controlul activitii organizaiei, sistemul informatic furnizeaz
informaii eseniale;
sistemele informatice sunt deschise i flexibile;
promovarea soluiilor TI susine organizaia n consolidarea i dezvoltarea
afacerii (de exemplu, comerul electronic, e-banking etc);
sistemul informatic ofer informaiile necesare controlului, ndeplinirii i
adaptrii planurilor operaionale i strategice ale organizaiei;
organizaia trebuie s cunoasc i s controleze riscurile asociate implementrii
noilor tehnologii i adaptrii sistemului informatic la noile cerine;
stabilirea unor standarde privind metodologiile i elementele TI - hardware i
software de utilizat n dezvoltarea sistemului informatic.

Figura Error! No text of specified style in document..2.Tipuri de sisteme informatice i


utilizatorii acestora

Sistemul informatic se structureaz astfel nct s corespund necesitilor mai multor

grupuri de utilizatori (Figura Error! No text of specified style in document..2).


Nivelurile managementului strategic i tactic se caracterizeaz prin solicitarea de
informaii:
ad hoc, neanticipate, determinate de un anumit context creat, n care
managerul este obligat s-i fundamenteze decizia;
sintetizate, dup o selecie i o sintetizare treptate;
previzionale, permind anticiparea tendinelor de evoluie a procesului condus;
externe, care s defineasc mediul economic, financiar, concurenial al
companiei.
n cazul managementului operaional, cruia i sunt caracteristice deciziile structurate,
informaiile oferite sunt:
de rutin;
detaliate, privind modul de derulare a activitii dintr-o arie de responsabilitate;
interne;
punctuale;
cu caracter istoric;
cu o frecven bine definit de obinere, momentul furnizrii informaiilor fiind
prestabilit.

n contextul tuturor acestor elemente, sistemul informatic de gestiune include:


ansamblul informaiilor interne i externe, formale sau informale utilizate n
cadrul organizaiei, precum i datele care au stat la baza obinerii lor;
software-ul necesar procesrii datelor i difuzrii informaiilor n cadrul
organizaiei (software de aplicaie sau produse program);
procedurile i tehnicile de obinere (pe baza datelor primare) i de difuzare a
informaiilor;
platforma hardware i software necesar prelucrrii datelor i diseminrii
informaiilor;
documentaii destinate personalului specializat n culegerea, transmiterea,
stocarea i prelucrarea datelor.

1.2.4 Clasificarea sistemelor informatice


Sistemele informatice pot fi clasificate n funcie de diverse criterii.

Dup aria de cuprindere:

Subsisteme informatice acoperind arii distincte, definite pe criterii funcionale n


cadrul organizaiei:
subsistemul produciei;
subsistemul comercial;
subsistemul resurselor umane.
subsistemul contabilitii;
subsistemul financiar etc.;

Subsisteme inter-organizaionale, concepute s asigure fluxuri informaionale


ntre:
organizaie i partenerii si (furnizori, clieni, banc etc): e-banking,
comer electronic etc.;
firma-mam i subdiviziunile sale organizatorice.

Ariile funcionale i fluxurile informaionale menionate pot fi tratate independent sau


integrat. Pentru acestea din urm, se disting:
sistemele integrate de gestionare a resurselor (ERP Enterprise Resource
Planning);
sistemele de e-business.

Dup natura activitilor susinute:

Sisteme destinate conducerii (MSS - Management Support Systems), care


cuprind:
sisteme destinate conducerii curente (MIS Management Information
Systems);
sisteme suport pentru decizii (DSS Decision Support Systems),
probabilistice ori deterministe, de optimizare ori descriptive;
sisteme informatice executive (EIS Executive Information Systems).
Sisteme destinate nivelului operaional:
sisteme destinate activitii de birou (OAS Office Automation
Systems);

sisteme pentru procesarea tranzaciilor (TPS Transaction Processing


Systems);
sisteme pentru controlul proceselor (PCS Process Control Systems).
Sisteme destinate gestiunii cunotinelor (KWS Knowledge Work Systems)

1.2.5 Arhitectura sistemelor informatice de gestiune


Termenul arhitectur se refer, n acest context, la aspectele de structurare i de
organizare general. Este necesar, n primul rnd, distincia ntre arhitectura sistemului
informatic i arhitectura software-ului aplicativ, care este doar o parte din acesta. n al
doilea rnd, complexitatea celor dou face s nu poat fi abordate dintr-o singur
perspectiv. n consecin, att pentru unul ct i pentru cellalt, exist, inevitabil, mai
multe arhitecturi, care nu sunt altceva dect reprezentri ale aceluiai produs, din puncte
de vedere diferite. Pentru a putea ntreprinde o asemenea delimitare, este necesar s se
recurg la abstractizare. Modelarea este, n informatic, modalitatea cea mai folosit n acest
scop. n consecin, pentru acelai software aplicativ, respectiv acelai sistem informatic, se
definesc mai multe modele arhitecturale, care nu pot compune, dect mpreun, imaginea
complet a acestuia.
n literatura de specialitate, sistemele informatice de gestiune sunt abordate:
a) din perspectiva informaiei i a suportului acesteia;
b) din perspectiva funciei asociate sistemul.
n primul caz, sistemele informatice de gestiune reprezint ansamblul informaiilor
utilizate n cadrul firmei, a mijloacelor i procedurilor de identificare, culegere, stocare i
prelucrare a informaiilor.
n cea de a doua abordare, se analizeaz scopul acestora: furnizarea informaiei
solicitate de utilizator n forma dorit i la momentul oportun, n vederea fundamentrii
deciziilor.
Sistemele informatice de gestiune (SIG) presupun definirea domeniilor de gestiune, a

datelor, modelelor, regulilor de gestiune.


Domeniile de gestiune corespund fiecreia dintre activitile omogene
desfurate n cadrul organizaiei - cercetare-dezvoltare, comercial, de producie, de
personal, financiar-contabil cu luarea n considerare a interaciunilor dintre ele.
Abordarea acestor domenii se realizeaz ntr-o viziune ierarhic, pe urmtoarele niveluri:
Tranzacional, n cadrul cruia se efectueaz operaii elementare;
Operaional, unde se desfoar operaii curente; deciziile luate la acest
nivel sunt curente, de rutin;
Tactic, corespunznd activitilor de control i deciziilor pe termen scurt;
Strategic, caracteristic deciziilor pe termen lung i/sau care angajeaz global
organizaia.
Datele reprezint materia prim a oricrui sistem informatic de gestiune. Prin
excelen, SIG sunt sisteme care trateaz intensiv volume mari i foarte mari de date.
Modelele de gestiune regrupeaz procedurile proprii unui domeniu (de exemplu,
modelul contabil, specific domeniului financiar-contabil; tehnologia de fabricaie, specific
domeniului produciei; modelul vnzrilor, specific domeniului comercial etc.).

Regulile de gestiune cuprind normele, condiiile, limitrile fixate i aplicate de


conducerea organizaiei, respectiv a domeniului respectiv, pentru desfurarea activitilor
curente.
Prin noiunea de domeniu, se ajunge la conceptul de subsistem informatic de
gestiune, determinat pe criterii funcionale, pe care se grefeaz celelalte dou concepte:
modelul de gestiune i regulile de gestiune.
Sistemele informatice de gestiune actuale aplic principiul prelurii unice a datelor i
prelucrrii multiple a acestora n concordan cu nevoile informaionale specifice fiecrui
utilizator. Pentru contabilitate, spre exemplu, datele din fiecare document primar sunt
preluate i actualizeaz baza de date unic, din care sunt, pe msura necesitilor, extrase
i prelucrate datele necesare att pentru lucrrile specifice contabilitii financiare
(Consultare 2 - Figura Error! No text of specified style in document..3) ct i pentru
contabilitatea de gestiune (Consultare 1 -Figura Error! No text of specified style in
document..3).

Figura Error! No text of specified style in document..3. Structura generic a SIG pentru
contabilitate

n realizarea unui sistem informatic, se poate opta pentru una din urmtoarele soluii
arhitecturale:
sistem informatic centralizat;
sistem informatic descentralizat.

Sistemul informatic centralizat se caracterizeaz prin faptul c ntregul proces de


stocare i prelucrare a datelor, precum i de dezvoltare a sistemului, se realizeaz la nivelul
unui singur sistem electronic de calcul (de regul, un mainframe), care stocheaz o baz de
date unic, precum i ansamblul programelor de aplicaie. Utilizatorii interacioneaz cu
sistemul prin intermediul terminalelor de lucru.
Avantajele centralizrii sunt reprezentate de:
controlul efectiv asupra utilizrii i dezvoltrii software-ului;
controlul asupra securitii i integritii datelor;
partajarea resurselor i a datelor ntre utilizatori;
eliminarea riscului incompatibilitii hardware i software n cadrul sistemului;

promovarea cu uurin a standardelor (tehnice, de proiectare, procedurale


etc) la nivelul ntregului sistem;
asigurarea serviciilor solicitate de ctre utilizatori prin puterea de calcul a
sistemului central (mainframe-ul).

Dezavantaje ale centralizrii pot fi:


cderea sistemului de calcul blocheaz toi utilizatorii;
alterarea datelor i a programelor, voit sau accidental, afecteaz toi
utilizatorii;
sistemul se poate dovedi lent i inflexibil la nevoile utilizatorilor, adesea fiind
insuficient adaptat nevoilor locale sau de grup ale utilizatorilor;
poate nregistra un timp mare de rspuns, n cazul unor solicitri simultane ale
mai multor utilizatori.

n cazul sistemelor informatice descentralizate, elementele software i puterea de


calcul sunt dispersate n diferite locaii ( site-uri) ale organizaiei. Prelucrarea se realizeaz
pe calculatoare personale independente sau n cadrul unor reele locale.
Avantajele descentralizrii:
datele sunt stocate i prelucrate local;
aplicaiile sunt mai bine adaptate nevoilor locale;
defeciuni ale bazei de date la nivelul unei locaii nu afecteaz celelalte locaii;
configuraia sistemului poate fi gndit n funcie de nevoile diferitelor
departamente din cadrul organizaiei sau chiar a utilizatorilor locali;
mai marea autonomie i motivare la nivelul utilizatorului local.
Dezavantajele descentralizrii:
riscuri mari legate de incompatibiliti hardware i software ntre diferite locaii;
apariia inerent a unor duplicri ale datelor i aplicaiilor n diferite locaii;
dificultatea realizrii unor proiecte complexe la nivel local;
riscul de fragmentare a politicii TI;
costuri mai mari n comparaie cu sistemul centralizat.
Tendina actual este net orientat ctre descentralizare, care trebuie s se realizeze
astfel nct:
ntreaga responsabilitate i autoritate pentru funciile descentralizate ale SI s
aparin managementului local;
s se asigure alinierea la standardele utilizate la nivelul SI global al
organizaiei;
la nivel central, s se asigure:
- elaborarea strategiei la nivelul ntregului SI al organizaiei;
- managementul comunicaiilor n cadrul reelei locale ale organizaiei;
- administrarea datelor;
- refacerea n caz de defeciuni ale echipamentelor.
Astzi, arhitectura promovat n realizarea sistemelor descentralizate este
arhitectura client- server, caracterizat prin faptul c aplicaiile i datele puse la
dispoziia utilizatorilor sunt dispersate pe diferitele componente hardware n funcie de
numrul utilizatorilor care trebuie s aib acces i de puterea de calcul necesar.
Componentele hardware sunt reprezentate de:
staii de lucru (calculatoare personale), folosite de utilizatori individuali;
servere departamentale, partajate de utilizatori caracterizai prin aceleai nevoi
de prelucrare;
server central, partajat de toi utilizatorii.

Software-ul exploatat n cadrul organizaiei este reprezentat de:


Aplicaiile la nivelul clienilor, care:
ruleaz pe staia de lucru pus la dispoziia clientului;
exploateaz date stocate pe calculatorul clientului;
sunt reprezentate, n principal, de: procesoare de tabele, procesoare de
texte, aplicaii exploatnd baze de date.
Aplicaii departamentale; acestea:
ruleaz pe serverul departamental;
exploateaz la nivelul departamentului, datele stocate pe serverul
acestuia;
sunt partajate de utilizatorii aceluiai departament;
Aplicaii la nivelul organizaiei, care:
ruleaz pe serverul central;
exploateaz datele de interes general, stocate pe serverul central;
sunt partajate de utilizatorii mai multor departamente;
necesit putere mare de prelucrare.

1.2.6 Sisteme i subsisteme


Din punct de vedere funcional, sistemul informatic se descompune n subsisteme,
fiecare dintre acestea acoperind un domeniu.
La rndul su, fiecare subsistem se decupeaz n aplicaii aferente activitilor
distincte derulate n cadrul domeniului. De exemplu, subsistemul informatic pentru domeniul
comercial se va descompune n aplicaii
distincte pentru: aprovizionare, desfacere,
marketing.
Procesul de descompunere continu i, pentru fiecare aplicaie, se vor defini proceduri
realiznd funciuni distincte (de exemplu, proceduri pentru dirijarea prelucrrilor, proceduri
pentru actualizarea i consultarea bazei de date). La rndul lor, procedurile se descompun n
module. Acestea cuprind secvene de cod corespunztoare unei funcii distincte n cadrul
procedurii. De exemplu, o procedur de actualizare a bazei de date va cuprinde: un modul
pentru adugare de nregistrri, un modul de modificare a nregistrrilor, un modul de
tergere a nregistrrilor.
n definirea arhitecturii unui SIG se recurge la una dintre urmtoarele strategii:
abordarea descendent sau top-down, centrat pe descompunerea SIG n
elemente de complexitate mai redus, alctuind o structur funcionalierarhic;
abordarea ascendent sau bottom-up, centrat pe compunerea de
subsisteme dezvoltate independent pe fiecare domeniu de gestiune, de unde i
riscul de a nu fi posibil o bun integrare a aplicaiilor la nivel de organizaie;
abordarea mixt, care reprezint o combinare a celor dou menionate
anterior; n acest demers, se opteaz pentru o prim definire a componentelor
sistemului informatic, aplicnd strategia descendent, urmat de conceprea i
realizarea fiecreia dintre aceste componente conform strategiei ascendente.
Indiferent de varianta selecionat, trebuie s se ia n considerare c SIG trebuie s se
poat adapta, n timp, la schimbrile ce vor surveni n exigenele interne ori impuse din
mediul economic exterior, cu att mai mult cu ct dinamismul mediului economic-social le
face foarte probabile. O astfel de abordare conduce la definirea de arhitecturi deschise
pentru sistemele informatice.

1.3 Procese de dezvoltare a sistemelor informatice de


gestiune
1.3.1 Ciclul de via al sistemului
Introducerea unui SIG nu se rezum la apariia de noi programe aplicative i, eventual,
de noi echipamente. Apariia sa antreneaz inevitabil modificri n procesele de business, n
gama, profilul i sarcinile alocate posturilor de lucru, n organizarea activitii i, nu de puine
ori, n comportamentul fa de clieni i de ceilali parteneri.
La fel de valabil este i percepia invers i anume recurgerea la sisteme informatice
noi sau la modificarea acestora ca suport al adaptrii organizaiei la provocrile i
oportunitile aprute n mediul socio-economic, n evoluie permanent i din ce n ce mai
rapid.
Indiferent de natura lor, identificarea necesitii acestor schimbri i a modului n care
urmeaz a fi realizate aparin managementului organizaiei. Pornind de la problemele pe
care conducerea organizaiei dorete s le rezolve i, n funcie de ceea ce exist n materie
de organizare, resurse, echipamente i aplicaii n funciune, se identific obiectivele
urmrite, principalii utilizatori i informaiile de care trebuie s dispun acetia, limitrile,
restriciile sau cerinele tehnice i, n raport cu toate acestea, modul de realizare: printr-un
sistem nou sau prin modificarea sistemului existent.
Din perspectiva organizaiei, un sistem nou se poate obine prin achiziie sau prin
dezvoltare.
Achiziia este aplicabil dac pe pia exist o ofert de software aplicativ de uz
general cu funcionalitile dorite. Acesta este un pachet de programe deja disponibil,
destinat, de la bun nceput cumprrii i utilizrii de ctre (ct) mai muli clieni. Asemenea
produse se adreseaz domeniilor comune oricror afaceri sau specifice unei anumite
industrii, cum sunt calculul salariilor, urmrirea stocurilor, contabilitatea financiar .a.m.d.
Ceea ce are de fcut organizaia, n aceast situaie, este s obin o list ct mai
complet a ofertelor de pe pia i s aleag acel produs i acel furnizor de software care
rspund cel mai bine cerinelor sale n materie de lucrri i operaii tratate, condiii i limite
de funcionare, pre, costuri de instalare i exploatare .a.m.d. Furnizorul poate fi chiar
dezvoltatorul software-ului sau un ter agreat.
Recurgerea la un produs program de uz general impune, naintea nceperii exploatrii
propriu-zise, un proces de parametrizare i adaptare la organizaie dar, n acelai timp,
antreneaz i alinierea sistemului informaional al organizaiei la viziunea i regulile dup
care opereaz acesta, ceea ce trebuie avut n vedere i examinat cu atenie naintea oricrei
decizii de achiziie.
Dezvoltarea conduce la obinerea unui sistem "personalizat*", conceput i construit
conform nevoilor i condiiilor specifice organizaiei. Are avantajul de a fi adaptat din start
acestora, dar costurile i durata de obinere vor fi mai mari. Modificarea unui sistem existent
poate fi fcut numai prin dezvoltare.
Dup obinere, sistemul este lansat i ncepe s fie utilizat n mod curent.
Lansarea n exploatare numit, de asemenea, introducere n producie, asigur
amplasarea echipamentelor i a reelelor de comunicaie (dac este cazul), instalarea
software-ului de aplicaie n structurile adecvate, crearea i ncrcarea iniial a bazei sau
bazelor de date, instruirea utilizatorilor, testarea sistemului n condiiile reale de utilizare etc.
Exploatarea curent denot perioada n care sistemul este folosit n cadrul
organizaiei pentru efectuarea prelucrrilor i obinerea rezultatelor urmrite prin
*

Se mai folosete, n acest caz i sintagma "sistem pe msur".

introducerea sa. Deine, n ansamblul existenei sistemului, durata cea mai mare i ia sfrit
odat cu scoaterea definitiv din funciune i nlocuirea cu un alt sistem.
n cursul exploatrii curente apar situaii care solicit intervenii de meninere n
funciune a sistemului. Acestea sunt determinate de dou cauze principale:
erori nesesizate n procesul dezvoltrii, care trebuie eliminate;
schimbri survenite n timp, la care sistemul trebuie s se adapteze, cum sunt
cele produse de evoluia tehnologiilor folosite (echipamente i programe).

Figura Error! No text of specified style in document..4 Ciclul de via al sistemelor


informatice de gestiune cuprinde urmtoarele stadii: definirea necesitii/oportunitii, obinerea,
introducerea n exploatare, exploatarea curent i meninerea n funciune.

1.3.2 Activiti de baz n dezvoltare


Diversitatea condiiilor n care are loc dezvoltarea unui sistem informatic de gestiune
are consecine directe asupra activitilor necesare pentru realizarea sa.
Dincolo de aceast diveristate, exist un set comun de procese de baz,
corespunztoare logicii de realizare a sistemului ca produs uman: definirea cerinelor pe
care trebuie s le satisfac sistemul, proiectarea, construcia i testarea.

Figura Error! No text of specified style in document..5 Activitile de baz dezvoltarea


sistemelor informatice de gestiune

Definirea cerinelor
Cerinele descriu comportamentul dorit al viitorului sistem, prin specificarea serviciilor
pe care acesta urmeaz s le asigure i al condiiilor i restriciilor de funcionare.
Definirea cerinelor este procesul n care beneficiarii sistemului i echipa de dezvoltare
stabilesc mpreun i convin asupra produsului care urmeaz a fi realizat. Din perspectiva
beneficiarilor, se pot distinge dou categorii de cerine: de business i de utilizare.
Teoretic, proiectarea, construcia i testarea ar trebui s respecte n totalitate
specificaia definit i aprobat mpreun cu beneficiarul, pentru a obine software-ul i
sistemul dorite. Practic a demonstrat ns c aceast aseriune, n care specificaia este
complet i rmne valabil pn la obinerea i livrarea sistemului, este nerealist.
Principalele motive ale acestei stri de fapt sunt urmtoarele:
cererile se modific n timp ce are loc proiectarea, construcia i tastarea
sistemului, din cauza schimbrilor survenite n mediul socio-economic n care
opereaz organizaia, n obiectivele managementului, n legislaia n vigoare,
.a.m.d.;
cererile formulate iniial sunt incomplete sau nu reflect nevoile reale ale
utilizatorilor, deoarece acetia nu realizeaz, dect dup ce iau contact cu
viitorul sistem sau cu o parte a acestuia, noile condiii de funcionare,
posibilitile i oportunitile oferite;
cererile nu sunt corect interpretate i nelese din cauza dificultilor de
comunicare dintre utilizatori i echipa de dezvoltare: semnificaia precis a
termenilor i conceptelor de specialitate folosii de fiecare dintre pri poate s
scape celeilalte, din cauza formaiei i experienei lor profesionale diferite.
Constituind fundamentul viitorului sistem i confruntndu-se cu dificultile obiective
menionate, definirea cerinelor este considerat un proces critic pentru dezvoltarea
sistemelor informatice iar gestionarea sistematic, coordonat i controlat a dinamicii
cerinelor i ajustrii software-ului n curs de realizare la acestea contureaz un domeniu
distinct de preocupare managementul cerinelor.

Proiectarea
Proiectarea are menirea de a defini o soluie informatic care s rspund cerinelor
utilizatorilor. Aceasta nseamn transpunerea cerinelor ntr-un ansamblu de uniti de
program (sau de programe) i de date folosite de ctre acestea, care s fie executabile pe
tipul de platform i configuraia avute n vedere.
Definirea cerinelor este procesul prin care viitorul sistem informatic sau software-ul de
aplicaie este descris sub aspectul comportamentului pe care ar trebui s-l aib fa de
utilizatori i fa de restul sistemelor, de toate tipurile, pe care le va utiliza sau cu care va

interaciona. n continuarea sa, proiectarea determin i descrie ce elemente de natur


informatic, aflate deci n interiorul sistemului, sunt necesare pentru a asigura acest
comportament. Prin urmare, definirea cerinelor i proiectarea realizeaz, mpreun,
conceperea sistemului (Figura Error! No text of specified style in document..5).

Construirea
Construirea (numit de asemenea, implementare), pornete de la elementele definite
n cursul proiectrii i asigur crearea programelor de calculator i a procedurile informatice
necesare, pn la forma final, cea executabil.
Scrierea programelor este departe de a fi o munc mecanic. naintea formulrii n
structurile sintactice cerute de limbajul de programare folosit, orice situaie, orice aciune,
orice funcionalitate trebuie gndit, rafinat n cele mai mici detalii. Ceea ce la nivelul
proiectrii face obiectul unei fraze sau aseriuni, poate genera, la nivelul scrierii programului,
mai multe module, avnd fiecare zeci sau sute de linii de cod. Acest efort de detaliere, de
rafinare, de definire este, de asemenea, de natura proiectrii, dar pe un alt nivel i la o alt
scar.
Trecerea n forma executabil a textului de program surs este automatizat, fiind
efectuat de programe de calculator specializate i, n funcie de mediul informatic utilizat,
trebuie cerut explicit sau se poate realiza implicit, n total transparen pentru cel care
lucreaz.

Testarea
Testarea este cea care face validarea proiectrii i se afl, n consecin, n aceeai
situaie: pentru a fi realizat, trebuie conceput n prealabil, i aceasta n strict corelaie cu
modul n care s-a proiectat funcionarea sistemului, de la nivelul cel mai general pn la cel
mai detaliat.
Disfuncionaltile i erorile constatate la testare sunt nlturate prin modificarea
adecvat a programelor surs, dup care noile programe sunt aduse din nou n forma
executabil i verificate i acest ciclu se repet pn cnd se ajunge la funcionarea dorit.
Identificarea sursei erorilor i disfuncionalitilor i nlturarea lor presupune revenirea
la oricare dintre nivelele de proiectare, inclusiv la programele surs i implic un efort
creator, care conduce la ajustarea, la amelioarea proiectului.
Dup ce programele surs au fost testate i corectate (puse la punct), se genereaz
formatul executabil final, ce se livreaz alturi de documentaia de utilizare i de exploatare
a sistemului.

1.3.3 Activiti suport


Demersul concret de dezvoltare a sistemului, care utilizeaz i consum resurse,
trebuie s fie gestionat, pentru a se asigura ncadrarea n limitele de timp i cheltuieli fixate
i obinerea unui produs de calitate. Exist, prin urmare, un proces complementar, de
management al proiectului. La acesta se adaug o serie de alte procese, cu rolul de a
susine dezvoltarea sistemului: managementul calitii, verificarea i validarea, gestiunea
configuraiei, documentarea.
Managementul proiectului cuprinde suita de activiti necesare constituirii echipei
de dezvoltare, stabilirii setului de metrici utilizat pentru cuantificarea i evaluarea efortului de
dezvoltare a sistemului, planificrii i urmririi curente a derulrii proiectului. Pricipalele

aspecte urmrite privesc asigurarea i utilizarea resurselor umane, financiare i materiale,


ncadrarea n termene, monitorizarea i diminuarea, respectiv, eliminarea riscurilor
Managementul calitii are menirea de a asigura o ct mai bun calitate a
software-ului produs. n acest scop, se recurge la definirea unui set de proceduri
organizaionale i standarde privitoare la activitile efectuate i la rezultatele intermediare i
finale furnizate de echipa de dezvoltare, i, bineneles, la urmrirea permanent a
respectrii acestora i, dac este necesar, a operrii ajustrilor necesare.
Validarea i verificarea, ca proces, include dou aspecte eseniale pentru realizarea
software-ului de aplicaie: faptul c n cursul proiectrii i construciei se respect cerinele
formulate iniial (validarea) i faptul c aceste cerine i software-ul realizat pe baza lor
corespund nevoilor sau ateptrilor reale ale viitorilor utilizatori (verificarea). Exist, aadar,
o diferen net ntre semnificaia celor doi termeni care apar n denumirea procesului i, nu
mai puin, n modul concret n care se efectueaz i n implicaiile pe care le au asupra
rezultatului final.
Gestionarea configuraiei se concentreaz asupra evoluiei software-ului de
aplicaie, respectiv a variantelor i versiunilor interne i a versiunilor livrate utilizatorilor.
Pentru facilitarea construirii, se recurge la descompunerea sistemului n pri de ntindere i
complexitate limitate, abordate succesiv sau n paralel, de grupuri diferite din cadrul echipei
de dezvoltare. Erorile sau deficienele constatate n urma testrilor unitare i de integrare
sunt corectate sau eliminate, obinndu-se noi versiuni sau variante, care intr din nou n
testare i integrare. Produsul final sau pri mai mari ale acestuia se obin prin asamblarea
acestor uniti, dup care sunt supuse testrii i controalelor de calitate. Acele componente
care au erori sau deficiene sunt remediate, obinnd noi versiuni sau variante, care
particip din nou la asamblare. Prin urmare, o nou versiune apare n urma efecturii de
corecii, n urma adugrii de noi funcionaliti sau ca o consecin a modificrii cerinelor
(i, prin urmare, i a proiectului sau unei pri a acestuia). De asemenea, pot fi produse
versiuni distincte atunci cnd anumite componente sau ntregul sistem urmeaz a fi
exploatate pe platforme informatice diferite. Rezultatul obinut prin asamblarea anumitor
versiuni ale componentelor constituie, la rndul su, o nou versiune a sistemului sau a unui
subsistem, livrabil ctre utilizator sau cu caracter intern, de lucru. Cum aceste versiuni pot
fi numeroase i pot aprea cu frecven mare, este necesar o gestionare strict a lor, ceea
ce face obiectul acestui proces, cu att mai mult cu ct evoluia continu i n cursul
exploatrii curente, prin interveniile de ntreinere sau meninere n funciune.
Documentarea este procesul consacrat elaborrii i meninerii la zi a documentaiei
privitoare la sistem. Exist dou categorii majore de documentaie: cea intern, destinat
membrilor echipei de dezvoltare i, ulterior, de ntreinere, care cuprinde toate detaliile
tehnice privitoare la conceperea i realizarea sistemului i cea de utilizare (manualele
produsului software), care ofer toate detaliile necesare instalrii, folosirii n realizarea
lucrrilor curente i administrrii sale la beneficiar. Dei uneori neglijat, documentaia este
una dintre piesele eseniale, att pentru dezvoltare, ct i pentru operarea curent. Formele
i momentele n care se realizeaz sunt diverse i, pentru obinerea unui nivel adecvat de
calitate, pot face obiectul unor reguli i standarde interne.

1.3.4 Nivele de abstractizare n dezvoltarea sistemelor informatice


de gestiune

Un software de aplicaie constituie o soluie bazat pe tehnologii ale informaiei pentru


un anume grup de cerine formulate de ctre utilizator.
Indiferent de natura utilizatorului individualizat sau generic (aa cum este cazul
produselor de tip pachet), termenii cu care opereaz cerinele - de genul clieni, produse,
comenzi, facturi, pli, conturi, debitri, creditri etc - aparin unui anumit domeniu, activiti
sau profesii, care formeaz spaiul problemei. Conceptele, termenii, scopurile, procesele
de prelucrare sunt extrem de variate i depind de domeniul n care opereaz organizaia i
de specificitatea acesteia: spre exemplu, cu totul altele vor fi problemele cu care se
confrunt o banc dect cele aferente unui spaiu comercial de mari dimensiuni sau ale unei
companii aeriene.
Rezolvarea pe care software-ul o aduce acestor cerine opereaz cu concepte, termeni
i "obiecte" total diferite de genul baze de date, table, chei primare i externe, interogri,
uniti de program, evenimente declanatoare .a.m.d. specifice tehnologiilor informatice
i de comunicaie folosite, care formeaz spaiul soluiei. Soluia livrat trebuie s
funcioneze pe o anumit platform informatic. Platformele sunt diverse, avnd fiecare
propriile particulariti, limitri, restricii i compatibiliti, care trebuie luate n considerare i
ncorporate n software-ul aplicativ livrat.
Cele dou spaii sunt net diferite, att din punct de vedere al conceptelor folosite, ct
i al comportamentului i funcionrii. Golul semantic dintre ele este acoperit de ctre echipa
de dezvoltare printr-un demers intelectual de punere n coresponden, de traducere a
fiecrui element din spaiul problemei, evocat de cerine, n termenii i structurile specifice
spaiului soluiei.
Utilizatorul formuleaz cerinele fa de viitorul sistem n termeni specifici activitii sau
sarcinilor sale profesionale. Aceti termeni difer de la un domeniu de activitate la altul.
Pentru o diversitate practic nelimitat de activiti, domenii i profesii, spaiul soluiei este
unic, fiind acela al tehnologiilor informatice. Este necesar, prin urmare, s se obin o
reprezentare uniform a cerinelor, n care detaliile i particularitile fiecrui domeniu i
activitate s fie exprimate printr-un set similar i limitat de concepte. Reprezentarea astfel
obinut este denumit conceptual, n sensul c ignor orice detaliu de tehnologie a
informaiei, cu excepia prezenei subnelese, implicite a recurgerii la aceasta.
Reprezentarea conceptual este o abstractizare a realitii de la utilizator. Pentru
fiecare sistem i caz n parte va exista cte o reprezentare specific, particular, proprie, dar
toate acestea recurg la acelai set de concepte i tehnici. O asemenea expresie abstractizat
formeaz modelul conceptual al viitorului sistem.
Trecnd n domeniul soluiei, vom regsi i aici o mare diversitate de elemente de
tehnologie informaional. Exist, la nivel fizic, mai multe platforme, aducnd fiecare
propriile caracteristici, particulariti, puncte forte i puncte slabe, de care trebuie inut
seama la realizarea sistemului. n spaiul acestor particulariti, gradul de complexitate adus
de interaciunile dintre programe i componente software este foarte ridicat, ceea ce face
foarte dificil i riscant tentativa de a trece direct la realizarea software-ului urmrit. Soluia
rezid, i n acest caz, n abstractizare. Elementele i detaliile diverselor tehnologii ale
informaiei sunt reduse la un set uniform i limitat de concepte i reprezentri. Aceast
abstractizare este denumit, mai curnd din raiuni istorice, logic, iar expresia soluiei
informatice definit, conceput pe acest nivel pentru software-ul aplicativ urmrit constituie
modelul logic al acestuia.

Figura Error! No text of specified style in document..6 Abstractizarea cerinelor i a


caracteristicilor tehnologiilor informatice simplific trecerea de la spaiul problemei la spaiul soluiei

Deoarece att reprezentarea conceptual ct i cea logic recurg la seturi limitate i


predeterminate de concepte i tehnici, punerea lor n coresponden este uurat i, ceea ce
este mai important, poate fi dirijat de reguli studiate n cadru general i care s ofere un
grad ridicat de siguran privitor la corectitudinea traducerii, a tranzitrii de la una la
cealalt.
Conceperea se face parcurgnd aceste trei nivele de abstractizare n ordinea
conceptual logic fizic iar rezultatele obinute formeaz modele ale viitorului sistem.

Figura Error! No text of specified style in document..7 Suita stadiilor urmate n


dezvoltarea sistemelor informatice de gestiune

Cerinele formulate pentru viitorul sistem sunt reprezentate n modelul conceptual. Din
acesta deriv, prin transformare i detaliere, modelul logic al sistemului. Urmeaz adaptarea
modelului logic la particularitile platformei/platformelor adoptate pentru realizare i
execuie i dezvoltarea detaliilor necesare pentru construcia sistemului.
Definirea cerinelor este, din aceast perspectiv, procesul dedicat modelrii
conceptuale a viitorului sistem. Nivelele logic i fizic delimiteaz dou stadii succesive ale
proiectrii, numite, respectiv, proiectare general i proiectare de detaliu. Proiectarea
general mai este denumit "de ansamblu" iar proiectarea de detaliu mai este denumit
"tehnic".

1.3.5 Date i prelucrri


Funcionalitile oferite utilizatorilor reprezint, din punct de vedere al sistemului
informatic, prelucrri pentru a cror efectuare sunt necesare anumite date.
Practica a demonstrat c este mult mai util prevederea, de la bun nceput, a unei
configuraii a datelor care s ofere o reprezentare fidel a ariei de business ce face obiectul
su, independent de exigenele particulare ale uneia sau alteia dintre prelucrri. Acest lucru
este cu att mai adevrat cu ct s-a constat c cerinele de prelucrare se modific frecvent,
n mod obiectiv, n timp ce structura datelor, fiind dependent numai de natura activitii sau
activitilor organizaiei, rmne stabil i se modific doar atunci cnd business-ul se
schimb. n aceast viziune, datele se delimiteaz de prelucrri.
Datele i prelucrrile sunt studiate i modelate separat, n paralel, pe fiecare
dintre cele trei nivele - conceptual, logic i fizic - cu puncte periodice de confruntare i
corelare.
Modelarea datelor vizeaz coninutul i structura memoriei sistemului, definite la
nivel conceptual i transpus apoi n formele cerute de constituirea sa informatic, pe
nivelele logic i fizic.
Modelul conceptual al datelor are menirea de a prezenta conceptele cu care se
opereaz n domeniul problemei, legturile semantice ce se stabilesc ntre acestea,
proprietile sau caracteristicile prin care sunt descrise i caracterizate, regulile de gestiune
aplicate.
Modelul logic al datelor descrie structurile de memorare informatic a datelor,
stabilite n funcie de tipul tehnologiilor de gestionare i de prelucrare avute n vedere.
Modelul fizic al datelor d reprezentarea structurii finale a bazei sau bazelor de
date n termenii SGBD folosit, dup ce aceasta a fost adaptat la caracteristicile de volum i
periodicitate ale operaiilor de actualizare i consultare la care va participa efectiv.
Modelarea prelucrrilor urmeaz un traseu asemntor, cu deosebirea c aici opereaz
n primul rnd principiul descompunerii i recompunerii, pe o scal ce pornete de la lucrrile
umane de informatizat i se ncheie cu delimitarea i definirea unitilor de program
executabil, a amplasrii i interaciunilor dintre acestea.
Modelul conceptual al prelucrrilor descrie funcionarea urmrit n domeniul
problemei, cu specificarea lucrrilor ce vor fi preluate sau asistate de viitorul sistem
informatic i a resurselor materiale i umane mobilizate n acest scop.
Modelul logic al prelucrrilor prezint modul n care este conceput din
perspectiv informatic efectuarea lucrrilor stabilite pe nivelul precedent. Aceasta conduce
la descopunerea fiecrei utilizri unitare i coerente a sistemului de ctre personalul
organizaiei n uniti de prelucrare coerente informatic.

Modelul fizic al prelucrrilor d expresie transpunerii unitilor logice de prelucrare


n spaiul platformei de dezvoltare i de exploatare, lund n considerare caracteristicile
limbajului de programare folosit, aspectele de modularizare i de distribuire fizic a
prelucrrilor .a.m.d.
Aceast viziune, axat pe existena a dou tipuri de componente memoria, respectiv
datele stocate informatic i prelucrrile care recurg la ea sau o menin la zi nu este unica
practicat. O a doua viziune, de dat mai recent, apeleaz la un singur tip de component
obiectul (informatic) - care reunete, n spatele unei bariere virtual impenetrabile, un
anumit grup de date i prelucrri cu ajutorul crora reacioneaz la stimuli. Aceast viziune a
preluat numele componentei sale definitorii, fiind referit prin sintagma abordare obiectual
sau bazat pe obiecte.
Abordarea obiectual a sistemelor informatice de gestiune este studiat la o alt
disciplin, n cadrul ciclului de materat.

1.3.6 Modele ale procesului de dezvoltare a sistemelor informatice


n cutarea unor soluii de accelerare a dezvoltrii sistemelor informatice i a
ameliorrii continue a managementului acestora, n paralel cu acumularea de experien i
cu evoluia conceptelor i instrumentelor puse n lucru, au fost propuse mai multe modele de
proces. Aceste modele sunt abstractizri care avanseaz o anumit modalitate de definire i
derulare n timp a activitilor necesare dezvoltrii sistemelor. naintea prezentrii ctorva
dintre cele mai utilizate, sunt necesare dou precizri:
nu exist un model ideal: n faa diversitii enorme de situaii i solicitri ce
apar n practic, trebuie ales modelul care se potrivete cel mai bine fiecrui
caz n parte;
modelele pot fi combinate, scopul fiind acela de a obine rapid, cu riscuri i
costuri ct mai reduse, sistemele ateptate de utilizatori i nu acela de a
respecta riguros demersul propus de un model sau altul.

1.3.6.1 Modelul n cascad


Modelul n cascad (Waterfall Model) a fost elaborat de W.W. Royce la nceputul
anilor 70. Este un model frecvent invocat n literatura de specialitate, caracterizat prin
parcurgerea secvenial a fazelor ciclului de via, faze care la rndul lor sunt formate din
activiti, iar acestea din urm din subactiviti.

Figura Error! No text of specified style in document..8 Modelul n cascad

Modelul prezint urmtoarele avantaje:


controlul total al fazelor, datorit modului de ordonare a acestora;
uor de nsuit de ctre membrii echipelor de analiz i proiectare;
fiecare faz se ncheie cu o verificare a soluiei oferite i asigur o
documentaie prezentnd soluia elaborat.
n timp au fost propuse variante mbuntite ale modelului:
modelul cu revenire la pasul anterior (waterfall model with back flow);
modelul cu reluare de la faza iniial (Da Capo Waterfall Model).
n versiuni mai noi ale modelului n cascad, primele faze grupeaz activiti specifice
gestiunii proiectului aceste elemente lipsind n modelul iniial.
Modelul prezint urmtoarele avantaje:
controlul total al fazelor, datorit modului de ordonare a acestora;
uor de nsuit de ctre membrii echipelor de analiz i proiectare;
fiecare faz se ncheie cu o verificare a soluiei oferite i asigur o
documentaie prezentnd soluia elaborat.
n timp au fost propuse variante mbuntite ale modelului:
modelul cu revenire la pasul anterior (waterfall model with back flow);
modelul cu reluare de la faza iniial (Da Capo Waterfall Model).

1.3.6.2 Modelul n V
Modelul n V este o variant a modelului cascad care aduce elemente calitative noi
importante. Un element caracteristic al modelului este introducerea conceptelor de sistem i
component (subsisteme) aplicndu-se teste explicite pentru creterea controlului asupra
modului n care se desfoar etapele. Fazele plasate n partea superioar a modelului se
caracterizeaz prin implicarea direct a viitorului utilizator.
Braul stng al diagramei, parcurs descendent, reunete fazele n cadrul crora se
realizeaz, pas cu pas, proiectarea i realizarea sistemului informatic. Detalierea
activitilor de proiectare, codificare i asamblare a componentelor se realizeaz gradual.
Braul drept al diagramei cuprinde reprezentarea fazelor asigurnd asamblarea
progresiv a componentelor sistemului pe msura testrii lor individuale, pn la obinerea
sistemului global i acceptarea acestuia de ctre beneficiar.
n cadrul modelului se remarc realizarea distinciei dintre verificare i validare. Prima
se refer la testarea sistemului n diversele stadii pe care le parcurge, iar validarea
urmrete s identifice n ce msur sistemul corespunde cerinelor iniiale, ceea ce
constituie un punct slab al modelului datorit ntrzierii cu care se produce aceast
validare.

Figura Error! No text of specified style in document..9 Modelul n V

1.3.6.3 Modelul incremental


Modelul incremental este o alt variant a modelului cascad care promoveaz ideea
proiectrii i realizrii independente a componentelor dup definirea arhitecturii globale a
sistemului informatic. Proiectarea i realizarea se realizeaz astfel n conformitate cu
principiile metodelor top - down. Sistemul va putea fi livrat beneficiarului i etapizat pe
msura realizrii componentelor (n funcie de prioritile formulate de beneficiar) dar
ntr-o astfel de abordare pot aprea dificulti legate de integrarea componentelor n
sistemul final.

Figura Error! No text of specified style in document..10 Modelul incremental

n figura Error! No text of specified style in document..10, unde este prezentat


schematic modelul, se observ faptul c primele dou etape definirea cerinelor i
analiza sunt identice cu cele dou etape de nceput ale modelului cascad, ns din
momentul definirii arhitecturii SI fiecare component i urmeaz propriul ciclu de via.
Spre deosebire de modelul n V care presupunea integrarea componentelor, testarea i
validarea acestuia, de aceast dat se ofer i posibilitatea livrrii independente a
componentelor SI ctre beneficiar fr a se exclude i posibilitatea livrrii SI final avnd
toate componentele integrate.

1.3.6.4 Modelul spiral

Figura Error! No text of specified style in document..11 Modelul n spiral

Modelul spiral, elaborat de Barry Boehm, se bazeaz pe acelai principiu ca i


modelul evolutiv. Modelul presupune construirea mai multor prototipuri succesive n
condiiile realizrii unei analize a riscului pe fiecare nivel. Fazele de dezvoltare sunt
reluate la fiecare iteraie n aceeai succesiune i presupun:
1.
2.
3.
4.

analiza riscurilor;
realizarea unui prototip;
simularea i testarea prototipului;
determinarea cerinelor n urma rezultatelor testrii;

5. validarea cerinelor;
6. planificarea ciclului urmtor.
Ultimul ciclu conduce la realizarea versiunii finale a sistemului informatic.
n centrul spiralei este plasat cunoaterea cerinelor i estimarea costurilor la nivel
preliminar. Evoluia SIG urmeaz desfurarea spiralei nregistrnd acumulri succesive ale
costurilor i este marcat de succesiunea prototipurilor, fiecare dintre acestea valorificnd
acumulrile realizate al nivelul prototipului anterior. Interaciunea dintre faze nu este
reliefat direct atta timp ct modelul prevede o succesiune continu a rafinrii legate de
decizii pe care riscurile proiectului le asociaz cu urmtoarea detaliere.
Modelul evideniaz atenia acordat planificrii, cutrii de soluii alternative,
evalurii riscurilor i validrii soluiilor pentru fiecare prototip, vzut ca un stadiu distinct n
realizarea sistemului informatic.
Prototipul este folosit att pentru identificarea ct i pentru validarea cererilor
utilizatorilor, pentru verificarea soluiei de proiectare i constituirea bazei dezvoltrii
ulterioare a proiectului de sistem informatic. Apelarea la prototip se explic prin aceea c un
model funcional este mai uor de neles de ctre viitorul utilizator dect un set de diagrame
nsoite de documentaie.
Prototipul funcional presupune proiectarea sistemului, realizarea primului prototip
funcional, verificarea msurii n care rspunde cererilor formulate de utilizator i rafinarea
acestei prime soluii, prin dezvoltri viitoare care adaug noi funcionaliti pn la obinerea
variantei finale a sistemului.

1.3.6.5 Dezvoltarea rapid


Dezvoltarea rapid (RAD Rapid Application Development) a fost definit la nceputul
anilor '90, n intenia de a oferi o alternativ la abordrile structurate. Denumirea ce i-a fost
atribuit evideniaz orientarea sa de esen: obinerea de software aplicativ care s
corespund cerinelor utilizatorilor, ntr-un interval ct mai scurt de timp.
Pentru atingerea acestui scop, se aplic un demers ce combin abordarea iterativ,
prototipurile i instrumentele sau mediile de proiectare i dezvoltare asistat de calculator
(CASE Computer Aided Software Engineering).
Prototipurile sunt folosite esenialmente pentru captarea cerinelor viitorului sistem.
Dezvoltarea se face incremental, prin iteraii succesive, fiecare dintre acestea fiind de
durat ct mai mic ntre o zi i trei sptmni.
Una dintre premisele de baz ale acestei abordri const n participarea activ a
utilizatorilor la dezvoltarea sistemului. n acest scop, se organizeaz sesiuni mixte de
proiectare JAD Joint Application Development - la care particip utilizatorii i echipa de
dezvoltare, n care se dezbat, se rafineaz i se accept rezultatele i produsele fiecrei
iteraii.
Pentru limitarea i controlul duratei de dezvoltare, procesul recurge la o organizare
bazat pe o structur numit timebox un interval strict, n cursul cruia trebuie obinut un
rezultat (parte din produs) executabil i livrabil. Un timebox este precedat de o sesiune
mixt de definire i planificare a funcionalitilor i este urmat de o sesiune de evaluare a
rezultatului. Iteraiile au loc n interiorul "cutiei" i se bazeaz pe un mediu de dezvoltare de
prototipuri evolutive.
Ciclul de dezvoltare parcurge patru etape:
planificarea cerinelor;
proiectarea funcional;
construirea;

instalarea la utilizator.

Figura Error! No text of specified style in document..12 Modelul de dezvoltare rapid

Prima etap, numit de asemenea "de definire a conceptelor", urmrete s delimiteze


aria de cuprindere a sistemului i s identifice, n cadrul acesteia, funciile de business
vizate, procesele de prelucrare, entitile structurale de baz i interaciunile dintre ele.
Durata este cuprins ntre una i patru sptmni i se realizeaz cu participarea
utilizatorilor cheie.
Proiectarea funcional urmrete s detalieze i s precizeze cerinele sistemului. n
acest scop, se organizeaz mai multe sesiuni mixte de proiectare, cu participarea echipei de
dezvoltare i a utilizatorilor. Durata etapei este de trei pn la cinci sptmni i furnizeaz,
ca rezultat, o reprezentare a cerinelor, compus dintr-un model al datelor, o list a regulilor
de gestiune, machete de ecran i nlnuiri ale acestora pentru prelucrrile eseniale. Tot n
aceast etap se stabilete modul n care va fi testat sistemul.
Construirea asigur dezvoltarea software-ului n cicluri iterative. Dup ce este creat,
prototipul se testeaz n maniera fixat n cursul proiectrii funcionale. Urmeaz una sau
mai multe reuniuni ale dezvoltatorilor i utilizatorilor, n urma crora se evideniaz, de
comun acord, funcionalitile adiionale necesare, dup care se iniiaz o nou iteraie de
dezvoltare. Se continu n acest mod, pn la obinerea software-ului n forma sa final.
Instalarea la utilizator cuprinde paii i activitile uzuale acestei etape.

1.3.7 Evoluia metodelor de proiectare


Complexitatea problemelor ridicate de realizarea sistemelor informatice a condus, nc
din anii 60, la definirea de metode de dezvoltare (numite frecvent i metode de proiectare).
n termenii cei mai generali, o metod preconizeaz un ansamblu de modele prin care
se definete viitorul sistem, ordonate conform unor reguli i principii, mai mult sau mai puin
detaliate, acompaniate de recomandri i restricii n elaborarea lor i o anumit etapizare i
ealonare n timp a ntregii activiti, astfel nct s se ajung cu un grad ct mare de
siguran i cu costuri ct mai reduse la un sistem funcional. Multe dintre metodele
existene, n special cele din ultimele decade, beneficiaz i de instrumente informatice
dedicate, care preiau o parte dintre sarcinile de rutin, sprijin elaborarea modelelor, asigur
gestionarea lor n condiii de coeren i, deseori, au capacitatea de generare automat a
unei pri a programelor, n unul sau mai multe limbaje i medii de dezvoltare diferite.
Recurgerea la metode de proiectare prezint mai multe avantaje:
introduc o anumit disciplin de lucru;

definesc produsele intermediare ale fiecrei activiti sau subactiviti


artefactele procesului;
permit amplasarea de puncte de control pentru evaluarea progresului
nregistrat i evaluarea nivelului de risc.

n timp, s-au conturat mai multe curente de gndire care au promovat i dezvoltat
diverse metode de proiectare.
O clasificare bazat pe cronologie include:
metode timpurii, metode nestructurate specifice perioadei 50 60;
metode orientate spre ieiri (sfritul anilor 60) caracterizate prin faptul c
proiectarea sistemului informatic avea ca punct de plecare ieirile pe care
acesta trebuia s le asigure: rapoarte, grafice etc. Pe baza ieirilor
identificate se determinau apoi datele de intrare i prelucrrile;
metode orientate spre procese, utilizate n deceniul apte, prezentnd
drept caracteristic utilizarea diagramelor fluxurilor de date;
metode orientate spre date, specifice anilor 80, prezentnd ca element
caracteristic utilizarea diagramelor entitate-relaie;
metode orientate obiect promovate n anii 90 caracterizate prin
promovarea conceptului de obiect care ncapsuleaz date i metode.
O alt clasificare, bazat pe paradigma conform creia este perceput sistemul,
evideniaz:
metode ierarhice (generaia I a metodelor de proiectare);
metode sistemice (generaia a II-a);
metode obiectuale, numite i metode orientate obiect (generaia a III-a).
Metodele ierarhice au la baz analiza funcional a ntreprinderii. Astfel, sistemul
informatic cuprinde n arhitectura sa subsisteme definite la nivel de funcii ale ntreprinderii.
Cum fiecare funcie este subdivizat ierarhic n subfuncii, iar acestea la rndul lor, se
descompun succesiv pn la definirea unor componente elementare uor de programat,
arhitectura SI va urma aceast ierarhie, fiecare component a sa acoperind o subdiviziune
funcional.
Avantajele metodelor ierarhice constau n simplitate i o bun adaptare la cerinele
formulate de utilizator.
Dezavantajele pornesc de la concentrarea efortului de analiz i proiectare asupra
prelucrrilor n condiiile n care, tocmai acestea sunt cele mai expuse la modificri n timp.
Metodele sistemice se bazeaz pe aplicarea teoriei sistemelor n descrierea
funcionrii ntreprinderii. Sistemul informatic este abordat sub dou aspecte
complementare datele i prelucrrile analizate i modelate independent, reunirea celor
dou modele realizndu-se ct mai trziu cu putin.
Spre deosebire de metodele ierarhice, metodele sistemice acord prioritate datelor
fa de prelucrri i respect cele trei niveluri de abstractizare introduse de raportul
ANSI/SPARC: conceptual, logic, fizic.
Avantajele metodelor sistemice decurg din promovarea tehnologiei bazelor de date.
Dezavantajele sunt datorate deficienelor care pot aprea n modelarea prelucrrilor i a
riscului apariiei unor discordane ntre modelele datelor i prelucrrilor.
Metodele obiectuale sau bazate pe obiecte au fost formulate la nceputul anilor
80. Dup o perioad iniial, n cursul creia s-au propus mai multe metode diferite, s-a
ajuns la o selecie a celor mai bune practici, larg acceptat, pornind de la care s-a definit un

cadru unificat de modelare denumit UML Unified Modeling Language i un proces unificat
corespunztor.
Caracteristic acestor metode este faptul c SIG este conceptualizat ca un ansamblu
de obiecte autonome, care se organizeaz i coopereaz ntre ele. Pentru prima dat,
datele i prelucrrile (metodele) se gsesc n cadrul aceleiai structuri, denumite obiect.
Fiecrui obiect i este caracteristic un anumit comportament, definit prin ansamblul
operaiilor pe care le poate realiza. Datele i prelucrrile sunt ncapsulate n cadrul
obiectului.
Avantajele metodelor obiectuale decurg din posibilitatea reutilizrii componentelor
de program, n mod direct sau prin mecanisme mai mult sau mai puin evoluate de
motenire i din posibilitatea compunerii, simple i sigure, de obiecte complexe prin
asamblarea obiectelor existente.
Dezavantajele acestor metode decurg din faptul c nu ntotdeauna reprezentarea sub
form de obiecte este natural, adecvat sau avantajoas.

1.3.8 Principii de baz n realizarea sistemelor informatice de


gestiune
Desfurarea unei activiti riguroase i performante de modelare i dezvoltare de
sisteme informatice de gestiune impune respectarea urmtoarelor principii:
1. abordarea global a problemei de rezolvat;
2. utilizarea unei metodologii unitare n proiectarea i realizarea sistemului informatic;

3. aplicarea celor mai moderne abordri n modelarea i dezvoltarea sistemului


informatic;
4. structurarea sistemului informatic innd seama de organigrama firmei;
5. participarea nemijlocit a viitorului beneficiar la activitile de analiz, proiectare i
implementare a sistemului informatic, n vederea formulrii clare a cerinelor utilizatorului,
necesare proiectrii i validarea ealonat a soluiilor propuse de proiectant;
6. respectarea cadrului legislativ; fiind vorba de sisteme informatice de gestiune,
devine obligatorie realizarea evidenelor, calcularea indicatorilor i ntocmirea lucrrilor de
sintez n conformitate cu reglementrile aflate n vigoare;

7. realizarea unor sisteme informatice corespunztoare resurselor disponibile la


utilizator;
8. ntruct, prin natura sa, aplicaiile sunt adaptabile, schimbrile trebuie anticipate i
controlate;
9. compromisurile sunt inerente n dezvoltarea de software; ele trebuie explicitate i
documentate.
Studiile de specialitate au ncercat s evidenieze factorii de succes n dezvoltarea
proiectelor software. Raportul Standish, spre exemplu, plaseaz ca primi factori de succes:
implicarea utilizatorului final;
sprijinul managementului executiv;
claritatea cerinelor;
planificarea.

1.4 Sinteza noiunilor studiate


Tipologia i arhitectura sistemelor informatice de gestiune

Sistemul informaional al organizaiei reprezint ansamblul de informaii


organizate, evenimente, persoane, proceduri i resurse alocate.
Sistemul informatic de gestiune este definit ca o soluie informatic pentru
sarcinile, lucrrile, problemele (unei poriuni a) sistemului informaional, conceput pentru a
funciona pe o anumit platform, folosind un anume software de aplicaie.
Tehnologia informaiei (TI) nglobeaz componente hardware, software, de
comunicaii, de reele, de automatizarea a lucrrilor de birou, baze de date, orice alte
echipamente i componente software necesare prelucrrii informaiei.
Criterii de clasificare a sistemelor informatice:
aria de cuprindere;
natura activitilor susinute.
Arhitectura sistemului informatic se refer la aspectele de structurare i de
organizare general i reprezint soluia generic de prelucrare a datelor.
Sistemele informatice de gestiune (SIG) presupun definirea domeniilor de
gestiune, a datelor, modelelor, regulilor de gestiune.
Soluii arhitecturale de realizare a unui sistem informatic pot fi:
sistem informatic centralizat;
sistem informatic descentralizat.
n definirea arhitecturii unui SIG se poate recurge la una dintre urmtoarele
strategii:
descendent sau top-down;
ascendent sau bottom-up;
mixt.
Cele trei componente majore care formeaz un sistemul informatic sunt:
intrrile;
prelucrrile;
ieirile.
Procese de dezvoltare a sistemelor informatice de gestiune

Ciclul de via al unui SIG cuprinde urmtoarele stadii:

definirea necesitii/oportunitii;
obinerea;
introducerea n exploatare;
exploatarea curent;
meninerea n funciune.

definirea cerinelor;
proiectarea;
construirea;
testarea.

managementul proiectului;
managementul calitii;
verificarea i validarea;
gestiunea configuraiei;

Activiti de baz n dezvoltarea SIG:

Activiti suport n dezvoltarea SIG:

documentarea.

Nivele de abstractizare n dezvoltarea SIG:


conceptual;
logic;
fizic.
Datele i prelucrrile sunt studiate i modelate separat, n paralel, pe fiecare dintre
cele trei nivele - conceptual, logic i fizic -, cu puncte periodice de confruntare i corelare.

Modele ale procesului de dezvoltare a SIG:

modelul n cascad;
modelul n V;
modelul incremental;
modelul spiral;
dezvoltarea rapid RAD.

Clasificarea metodelor de proiectare:


Cronologic:
metode timpurii;
metode orientate spre ieiri;
metode orientate spre procese;
metode orientate spre date;
metode orientate obiect.
n funcie de paradigma conform creia este perceput sistemul:
metode ierarhice (generaia I a metodelor de proiectare);
metode sistemice (generaia a II-a);
metode obiectuale numite i metode orientate obiect (generaia a III-a).

Principii de baz n realizarea sistemelor informatice de gestiune:

abordarea global a problemei de rezolvat;


utilizarea unei metodologii unitare n proiectarea i realizarea SIG;
aplicarea celor mai moderne abordri n modelarea i dezvoltarea SIG;
structurarea SIG innd seama de organigrama firmei;
participarea nemijlocit a viitorului beneficiar la activitile de analiz,
proiectare i implementare a SIG;
respectarea cadrului legislativ;
realizarea unor SIG corespunztoare resurselor disponibile la utilizator;
anticiparea i controlul schimbrilor;
documentarea tuturor soluiilor integrate n SIG.

1.5 Teste de autoevaluare


1. Precizai care dintre urmtoarele afirmaii este fals:
a) Sistemul informaional al unei organizaii include sisteme informatice de
gestiune (SIG).
b) SIG are rol de infrastructur pentru sistemul informaional.
c) Sistemul informaional nu comunic cu SIG.
d) Adaptarea SIG la evoluia platformei pe care funcioneaz nu trebuie s
afecteze coerena datelor.
e) SIG comunic ntre ele, transmindu-i reciproc date i solicitri.

2. Precizai care dintre urmtoarele afirmaii este adevrat:


a) Dezvoltarea unui SIG adaptat nevoilor specifice unei organizaii nu genereaz
costuri suplimentare.
b) Introducerea unui SIG nu antreneaz modificri n organizarea activitii unei
organizaii.
c) Strategie ascendent sau bottom-up este centrat pe descompunerea de
subsisteme dezvoltate independent pe fiecare domeniu de gestiune.
d) Aplicaiile software departamentale ruleaz pe serverul central al organizaiei.
e) Reingineria modului de organizare a afacerii presupune reproiectarea
proceselor de afaceri.
3. Precizai care dintre elementele enumerate mai jos nu face parte din ciclul de via al
sistemelor informatice de gestiune:
a) definirea necesitii/oportunitii;
b) corelarea facilitilor cu funciunile SIG ale clienilor i furnizorilor;
c) obinerea;
d) introducerea n exploatare;
e) meninerea n funciune.
4. Regulile de gestiune specifice unui SIG:
a) se definesc la finalul proceselor de dezvoltare a SIG;
b) descriu desfurarea activitii numai n subsistemul de gestiune a stocurilor;
c) se stabilesc doar de manageri;
d) cuprind normele, condiiile, limitrile fixate i aplicate de conducerea
organizaiei, respectiv a domeniului aferent SIG, pentru desfurarea
activitilor curente;
e) sunt luate n considerare n momentul introducerii n exploatare a SIG.
5. Determinai care dintre elementele enunate nu se regasesc printre factorii de succes
menionai n raportul Standish:
a) implicarea utilizatorului final;
b) sprijinul managementului executiv;
c) claritatea cerinelor;
d) planificarea;
e) ergonomia locului de munc.

1.6 Bibliografie
Zaharie, D., Roca, I. (2002), Proiectarea obiectual a sistemelor informatice", ed. Dual
Tech, Bucureti
Anica-Popa, L.-E. (2005), Conducerea intreprinderii prin costuri: recursul la modelele
contabilitatii manageriale: cazul metodei ABC-Activity Based Costing, Editura Economica,
Bucureti

Rspunsuri grile:
1-c
2-e
3-b
4-d
5-e

S-ar putea să vă placă și